From jared.kofron@REDACTED Sat Feb 1 00:16:02 2014 From: jared.kofron@REDACTED (Jared Kofron) Date: Fri, 31 Jan 2014 15:16:02 -0800 Subject: [erlang-questions] Documentation on Binding a C library to Erlang In-Reply-To: References: Message-ID: Also, I highly recommend finding a good NIF library to read the code for - it will be way, way more clear if you do so. IIRC there's a good NIF library for interacting with sqlite3 that is very readable and will give you an idea of what a practical implementation looks like. It might be this one? https://github.com/mmzeeman/esqlite On Fri, Jan 31, 2014 at 1:42 PM, Steve Vinoski wrote: > > > > On Fri, Jan 31, 2014 at 4:35 PM, kraythe . wrote: > >> Greetings, I am a newbie to erlang. I am interested in binding a c >> library that I have as source (that I have written) to Erlang. In Java I >> would use JNI. In Erlang I don't know. Can anyone point me at where the >> docs are for this? Especially a tutorial. Google has been unrevealing and i >> have been through hundreds of dead ends. >> > > If you really want the C library running together with the Erlang VM, > you'll write either a set of native implemented functions (NIFs) or a > linked-in driver. See the links below. > > http://www.erlang.org/doc/tutorial/nif.html > http://www.erlang.org/doc/man/erl_nif.html > http://www.erlang.org/doc/apps/erts/driver.html > http://www.erlang.org/doc/man/erl_driver.html > > --steve > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sat Feb 1 00:31:14 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 1 Feb 2014 00:31:14 +0100 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <8F68CDF4-7FFF-4CD8-8088-9ED4E0DFDB39@gmail.com> References: <2EA8BDCE-8F74-4339-98BE-2A7C6BD3EEBB@gmail.com> <8F68CDF4-7FFF-4CD8-8088-9ED4E0DFDB39@gmail.com> Message-ID: <140360A8-F43E-45AD-B818-0CD040921EB6@gmail.com> I leave that question as an exercice to the reader. -- Anthony Ramine Le 31 janv. 2014 ? 23:45, Stefan Strigler a ?crit : > Pun intended? > > On 31.01.2014, at 23:30, Anthony Ramine wrote: > >> For those wondering, the syntax is: >> >> F = fun Fact(0) -> 1; Fact(N) when N > 0 -> N * Fact(N - 1) end, > ^^^^^^^^^^ >> F(6). >> >> Regards, >> >> -- >> Anthony Ramine >> >> Le 31 janv. 2014 ? 22:51, Kenneth Lundin a ?crit : >> >>> - Funs can now be given names >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > From steven.charles.davis@REDACTED Sat Feb 1 01:49:22 2014 From: steven.charles.davis@REDACTED (Steve Davis) Date: Fri, 31 Jan 2014 16:49:22 -0800 (PST) Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: References: Message-ID: <0efe9f39-53c8-41a0-8590-65e1e29d4796@googlegroups.com> On Thursday, January 30, 2014 10:19:45 AM UTC-6, kraythe wrote: > > Ok right up front, I'm a Java Guru > Awesome, I've always wanted to meet one. > *Scala: * > *Erlang:* > *Pros:* > > 1. Built for concurrency. Can handle dozens of hardware nodes, > > Wait, doesn't that depend how much they need to talk? *Cons:* > > 1. The tools are, well frankly, garbage. > > Of course the ones you are looking for are. You have to suppose you don't need the tools you think you need. > > 1. Rebar is crytptic and just the pet project of a guy on GIT. > > I guess that's why it's not in the OTP releases. > > 1. Compared to Gradle, Maven and even (though I don't care for it > much) SBT, rebar is ... lacking. I want to spend time working on my > business logic, not fighting tools. There are plugins for eclipse and > intellij but they have minimal functionality and i keep reverting back to > vim. > > As a "java guy" too (not by choice :-), I don't think e.g. maven is free from overhead by any stretch of the imagination... I have never found the real need for an IDE for Erlang. A good text editor has always been quite enough. > > 1. Much harder to staff than Scala because it is not Java based. > > Scala is not java, and I don't see the evidence for what you are saying about staffing yet. BTW: It's my understanding that Erlang has a far better production track record than Scala (by maybe a decade) > > 1. Fewer general purpose libraries and no major central repositories. > I don't want to write code to create JSON, that isnt part of my business > scope. I will pick that one of the shelf If i can. > > Wait, either pick someone else's effort, or if that's not good enough I'd suggest that it's better to have to spend a day or two implementing something obvious and defined than struggling with some "api" that makes no sense owing to the hidden side-effects introduced by someone else's lame thinking. In this case, I'd humbly ask you to re-imagine what "business scope" means in your question. > > 1. Records as the only structured data type is ... annoying. > > And yet, nobody has improved upon them yet (though I do await frames with great anticipation) The problem I have is I can't find the perfect solution. Erlang is > compelling but also is Scala. > > Opinions? > Opinions, yes :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenji@REDACTED Sat Feb 1 06:30:53 2014 From: kenji@REDACTED (Kenji Rikitake) Date: Sat, 1 Feb 2014 14:30:53 +0900 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: Message-ID: <20140201053053.GA9640@k2r.org> I believe quite a few pieces of software depends on the (now old) version number scheme of Erlang/OTP - R[Major-Version][AB][Minor-Version]. This has been changed and may break some. (See OTP-11615 on 17.0-rc1 readme) FYI kerl depended on the old version number scheme, so I've written a fix: https://github.com/spawngrid/kerl/pull/61 (already merged: thx Yurii Rashkovskii!) Checking the version number parsing functions especially on Erlang/OTP release/build engineering tools will be needed. FYI Kenji Rikitake And as always, many thanks to Kenneth and the OTP Release Team! ++> Kenneth Lundin [2014-01-31 22:51:45 +0100]: > Erlang/OTP 17.0-rc1 has been released. From mjtruog@REDACTED Sat Feb 1 07:06:16 2014 From: mjtruog@REDACTED (Michael Truog) Date: Fri, 31 Jan 2014 22:06:16 -0800 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <20140201053053.GA9640@k2r.org> References: <20140201053053.GA9640@k2r.org> Message-ID: <52EC8ED8.9010504@gmail.com> There is an autoconf macro here, that could help people using autoconf: https://github.com/CloudI/CloudI/blob/develop/src/m4/ax_erlang_otp_version.m4 On 01/31/2014 09:30 PM, Kenji Rikitake wrote: > I believe quite a few pieces of software depends on the (now old) version > number scheme of Erlang/OTP - R[Major-Version][AB][Minor-Version]. This has > been changed and may break some. (See OTP-11615 on 17.0-rc1 readme) > > FYI kerl depended on the old version number scheme, so I've written a fix: > https://github.com/spawngrid/kerl/pull/61 > (already merged: thx Yurii Rashkovskii!) > > Checking the version number parsing functions especially on Erlang/OTP > release/build engineering tools will be needed. > > FYI > Kenji Rikitake > And as always, many thanks to Kenneth and the OTP Release Team! > > ++> Kenneth Lundin [2014-01-31 22:51:45 +0100]: >> Erlang/OTP 17.0-rc1 has been released. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From sina.samv@REDACTED Sat Feb 1 00:21:10 2014 From: sina.samv@REDACTED (Sina Samavati) Date: Sat, 1 Feb 2014 02:51:10 +0330 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: Message-ID: Good work! I'm curious to know why the version scheme is changed. Thanks On Sat, Feb 1, 2014 at 1:21 AM, Kenneth Lundin wrote: > Erlang/OTP 17.0-rc1 has been released. > > This is an alpha release, which will be followed by a planned beta release > about a month later and a final > OTP 17.0 product release in the end of March 26, 2014. > Between the alpha and beta and final release there will be new updates of > the master branch with corrections > and minor new features. Occasionally there might be new tags which we in > that > case will communicate and ask you to test. > > Erlang/OTP 17.0 is a new major release with new features, quite a few > (characteristics) improvements, > as well as some incompatibilities. See the README file and the documentation > for more details. > > We would like to ask you to download and test the alpha release and send us > your feedback as soon as possible, > so that we can make the necessary corrections before OTP 17.0-rc2 and OTP > 17.0, respectively. > The release contains many changes; thus, some unexpected incompatibilities > or issues may have slipped through > our tests. Please try to build and run your current products/applications > and let us know about any problems. > > Note! The new datatype MAP is not properly documented yet but the EEP 43 > http://www.erlang.org/eeps/eep-0043.html > will provide a good start. Also note that it is a limited implementation of > maps implemented so far: > > - no variable keys are allowed > - native code can not be generated for modules using maps > > Some other highlights of the release are: > > - Maps, a new dictionary data type (experimental) > - A more natural mapping from ASN.1 OCTET STRING and BIT STRING to > Erlang types, > and other ASN.1 improvements and optimizations > - The {active, N} socket option for TCP, UDP, and SCTP > - A new (optional) scheduler utilization balancing mechanism > - Migration of memory carriers has been enabled by default on all ERTS > internal > memory allocators > - Increased garbage collection tenure rate > - Experimental "dirty schedulers" functionality > - Funs can now be given names > - Miscellaneous unicode support enhancements > - A new, semantic version scheme for OTP and its applications > > You can find the README file with more detailed info at > > http://www.erlang.org/download/otp_src_17.0-rc1.readme > > You can download the full source distribution from > > http://www.erlang.org/download/otp_src_17.0-rc1.tar.gz > http://www.erlang.org/download/otp_src_17.0-rc1.readme (this file) > > Note: To unpack the TAR archive you need a GNU TAR compatible program. > > For installation instructions please read the README that is part of the > distribution. > > You can also find this release at the official Erlang/OTP Git-repository at > Github here: > > https://github.com/erlang/otp tagged *OTP_17.0-rc1* > > > The Windows binary distribution can be downloaded from > > http://www.erlang.org/download/otp_win32_17.0-rc1.exe > http://www.erlang.org/download/otp_win64_17.0-rc1.exe > > > On-line documentation can be found at http://www.erlang.org/doc/. > You can also download the complete HTML documentation or the Unix manual > files > > http://www.erlang.org/download/otp_doc_html_17.0-rc1.tar.gz > http://www.erlang.org/download/otp_doc_man_17.0-rc1.tar.gz > > We also want to thank those that sent us patches, suggestions and bug > reports. > > The Erlang/OTP Team at Ericsson > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Sina Samavati Software engineer https://github.com/s1n4 https://twitter.com/sinasamavati From k.petrauskas@REDACTED Sat Feb 1 10:40:59 2014 From: k.petrauskas@REDACTED (Karolis Petrauskas) Date: Sat, 1 Feb 2014 11:40:59 +0200 Subject: [erlang-questions] "erlang-src" package upgrade breaks "syntax_tools" and rebar builds In-Reply-To: References: Message-ID: I had the same problem. Part of the problems disapeared after uninstalling erlang-src. But other problems remained. Rebar build was unable to find xmerl.hrl. I haven't investigated if some other applications are broken also. I solved the issue by installing esl-erlang package instead of erlang. Karolis On Fri, Jan 31, 2014 at 4:23 PM, Roger Lipscombe wrote: > This morning, I let apt-get upgrade install a new "erlang-src" > package. This has broken rebar. Specifically, I get the error message: > > ERROR: compile failed while processing /home/roger/Source/rebar/rebar: > {'EXIT',{undef,[{epp_dodger,parse_file,["src/rebar_core.erl"],[]}, > {rebar_erlc_compiler,compile_priority,1, > [{file,"src/rebar_erlc_compiler.erl"}, > {line,470}]}, > > That is: rebar fails to compile other things, but (here) is also seen > failing to compile itself. > > Upon investigation, I discover that I have both > "/usr/lib/erlang/lib/syntax_tools-1.6.12" and > "/usr/lib/erlang/lib/syntax_tools-1.6.13". The "-1.6.12" directory > contains "ebin", but no "src", and the "-1.6.13" directory contains > "src", but no "ebin". > > It would appear that my installation is using the newer one, and > failing to find the .beam files. > > So, some questions: > > 1. How do I (on Linux Mint 15, so basically Ubuntu) figure out which > APT repository the .deb file came from? This so that I can lay blame > appropriately. > 2. I'd like to roll back the "erlang-src" package that broke this, but > it appears to have the same version number as the previous one both > are "1:16.b.3". Any idea how I do this? > 3. Can I simply delete the offending, newer, directory? > 4. If not, how do I get the binaries for "-1.6.13"? > 5. Or: how do I compile the source to do that myself? > > My feeling is that Erlang Solutions have repackaged "erlang-src", and > somehow bumped the version number so that it got upgraded (not that I > can tell the difference), but that, for some reason, I'm not seeing > the corresponding "erlang-syntax-tools" upgrade, which would contain > the "ebin" directory. > > Help? > > Thanks, > Roger. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vladdu55@REDACTED Sat Feb 1 11:17:08 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Sat, 1 Feb 2014 11:17:08 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <52EC8ED8.9010504@gmail.com> References: <20140201053053.GA9640@k2r.org> <52EC8ED8.9010504@gmail.com> Message-ID: Hi! Erlide is another tools that needs to understand the version numbers, so I'd like to ask if there is a spec for the new scheme. Is it 100% semantic versioning? regards, Vlad On Sat, Feb 1, 2014 at 7:06 AM, Michael Truog wrote: > There is an autoconf macro here, that could help people using autoconf: > https://github.com/CloudI/CloudI/blob/develop/src/m4/ax_ > erlang_otp_version.m4 > > > On 01/31/2014 09:30 PM, Kenji Rikitake wrote: > >> I believe quite a few pieces of software depends on the (now old) version >> number scheme of Erlang/OTP - R[Major-Version][AB][Minor-Version]. This >> has >> been changed and may break some. (See OTP-11615 on 17.0-rc1 readme) >> >> FYI kerl depended on the old version number scheme, so I've written a fix: >> https://github.com/spawngrid/kerl/pull/61 >> (already merged: thx Yurii Rashkovskii!) >> >> Checking the version number parsing functions especially on Erlang/OTP >> release/build engineering tools will be needed. >> >> FYI >> Kenji Rikitake >> And as always, many thanks to Kenneth and the OTP Release Team! >> >> ++> Kenneth Lundin [2014-01-31 22:51:45 >> +0100]: >> >>> Erlang/OTP 17.0-rc1 has been released. >>> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Sat Feb 1 12:09:43 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Sat, 1 Feb 2014 15:09:43 +0400 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: Message-ID: Small notice. As apple is doing everything to make compilation hard, I had to compile with following keys: CC=clang CXX=clang++ LDD=clang ./configure --prefix=/usr/local/Cellar/erlang/R17.0 --enable-dirty-schedulers --with-dynamic-trace=dtrace --enable-smp-support --enable-kernel-poll --enable-vm-probes --enable-m64-build and also I had to move /usr/bin/xcrun to /usr/bin/xcrun-orig and replace original apple file with following bash script: #!/bin/bash $@ without this manipulation I couldn't even configure erlang under Mac OS X 10.8.5 ------ Right after compilation I have problems: flussonic max$ ./rebar clean ERROR: Failed to extract name from /Users/max/Sites/flussonic/deps/lhttpc/src/lhttpc.app.src: {27, file_io_server, invalid_unicode} Line 27 of lhttpc.app.src is: %%% @author Oscar Hellstr?m It is umlaut in documentation. How should this be handled? -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Sat Feb 1 12:11:01 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Sat, 1 Feb 2014 15:11:01 +0400 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: Message-ID: The same problem with lager.erl: {"don't choke on latin-1", fun() -> %% XXX if this test fails, check that this file is encoded latin-1, not utf-8! gen_event:add_handler(lager_event, lager_file_backend, [{"test.log", info}, {lager_default_formatter}]), lager:log(error, self(),"~ts", ["L???N-?"]), {ok, Bin} = file:read_file("test.log"), Pid = pid_to_list(self()), Res = re:split(Bin, " ", [{return, list}, {parts, 5}]), ?assertMatch([_, _, "[error]", Pid, [76,195,134,195,157,195,142,78,45,195,175,$\n]], Res) end }, Line lager:log(error, self(),"~ts", ["L???N-?"]), cannot even compile -------------- next part -------------- An HTML attachment was scrubbed... URL: From sevenjp@REDACTED Sat Feb 1 12:17:47 2014 From: sevenjp@REDACTED (=?UTF-8?Q?Jo=C3=A3o_Neves?=) Date: Sat, 1 Feb 2014 12:17:47 +0100 Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: References: <89DAA09F-64B0-4565-A73C-784B5E8EB4C6@feuerlabs.com> <8883B14026CD4CB38E71BEB9DFE5BF67@srstrong.com> Message-ID: I'd like to add that since you're taking the dive into Emacs-land, I *highly* recommend that you setup EDTS (https://github.com/tjarvstrand/edts) to get some nice stuff like autocompletion, automatic running of EUnit tests, per-project settings (like which version of Erlang you want to work with) and a bunch of other niceties. Makes for a smoother transition if you come from the Java world with all the tools the IDEs give you. -- Jo?o Neves 2014-01-31 kraythe . : > Well I think after seeing the arguments and the response of the community > I am trending seriously towards Erlang. I will probably make the mental > investment to learn and become good with emacs. And then move on from > there. I may still have a ton of questions. I would still, for example, > love to know who to 'reload' my application once it is started. > > > On Fri, Jan 31, 2014 at 12:24 AM, kraythe . wrote: > >> Well I think after seeing the arguments and the response of the community >> I am trending seriously towards Erlang. I will probably make the mental >> investment to learn and become good with emacs. And then move on from >> there. I may still have a ton of questions. I would still, for example, >> love to know who to 'reload' my application once it is started. >> >> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* >> *Author of: Hardcore Java (2003) and Maintainable Java (2012)* >> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 >> * >> >> >> On Thu, Jan 30, 2014 at 10:29 PM, Richard A. O'Keefe wrote: >> >>> >>> On 31/01/2014, at 7:49 AM, Steve Strong wrote: >>> > On Thursday, 30 January 2014 at 19:10, kraythe . wrote: >>> >> 1) Code completion. Sorry but I can't be bothered to type the same >>> flipping method name in its entirety 40 times. >>> >>> >>> There are three causes for "completion" in languages like >>> Prolog and Erlang: >>> >>> (a) Definitions with multiple clauses. >>> Your editor should be able to turn "add a clause" into a >>> single command. >>> >>> (b) Recursion. >>> Your editor should be able to turn "add a recursive call" >>> into a single command (basically the same as (a), just >>> different stuff wrapped around it). >>> >>> A programming style using higher order procedures can >>> eliminate a lot of this. >>> >>> (c) Repetitive patterns of code. >>> >>> A programming style using higher order procedures can >>> eliminate a lot of this. >>> >>> There's a thing I find myself saying more and more often: >>> >>> Why can't I see the structure? >>> >>> I was reviewing a page or two of Prolog code for someone the >>> other day. By the end of three hours, I'd made some progress, >>> but I was troubled. The code was clean, but it wasn't OBVIOUS. >>> What finally dawned on me would have been instantly obvious to >>> a real functional programmer: the code was an interweaving of >>> a "compute argmax of a partial function over a finite domain" >>> and "here is this partial function". Actually introducing the >>> higher order function in question let me explore several ways >>> of implementing that *without* any effect on the rest of the >>> code. Breaking the specific partial function out and naming >>> it let me see that memoising *that* function -- which hadn't >>> previously existed -- stood an excellent chance of reducing >>> the overall cost of the algorithm down *hugely*. >>> >>> So I say, if you find yourself _wanting_ a method name to >>> appear 40 times in a day's work, you are doing something >>> badly wrong. >>> >>> For another data point, as part of building up my Smalltalk >>> skills, I used to pick up Java code and rewrite it in Smalltalk. >>> There were two invariable results: first, the code would >>> shrink by about a factor of six, and second, it would become >>> painfully obvious that the original code was really really >>> bad design, and that in a *good* OO design, most of the >>> classes wouldn't just shrink, they'd disappear. A good part >>> of this is down to Smalltalk's support for and extensive use >>> of higher order functions from day 1. >>> >>> > >>> > 3) Syntax coloring. (VIM color codes a file so that is there, emacs I >>> don't know AT ALL.) >>> To which Steve Strong replied >>> > I don?t know of any editor that doesn?t do this - >>> > even github displays syntax colouring on erlang files. >>> >>> My own text editor doesn't do syntax colouring. >>> Frankly, I hate syntax colouring. I could give you >>> a long rant about why. One big issue is that the >>> name is a lie. It's *lexical* colouring; the colour >>> depends on what kind of token something is. But I >>> can *see* that. If you offered me an editor where >>> calls to functions whose definitions had been edited >>> recently were brightly coloured, or where the functions >>> imported from a particular module were brightly coloured, >>> or where slicing was used to colour the places where a >>> particular variable could be *changed* and *used*, I'd >>> find that really really helpful. Why waste colour >>> telling me something that is already obvious at a glance? >>> I once came across a compiler (written in Finland) where >>> several passes had had to be woven together because of >>> the language it was written in, so they had coloured >>> each declaration and statement according to which pass >>> it was logically part of. Now _that's_ good use of colour! >>> >>> > >>> >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgolovan@REDACTED Sat Feb 1 12:41:56 2014 From: sgolovan@REDACTED (Sergei Golovan) Date: Sat, 1 Feb 2014 15:41:56 +0400 Subject: [erlang-questions] "erlang-src" package upgrade breaks "syntax_tools" and rebar builds In-Reply-To: References: Message-ID: Hi Roger, On Fri, Jan 31, 2014 at 6:23 PM, Roger Lipscombe wrote: > This morning, I let apt-get upgrade install a new "erlang-src" > package. This has broken rebar. Specifically, I get the error message: > > ERROR: compile failed while processing /home/roger/Source/rebar/rebar: > {'EXIT',{undef,[{epp_dodger,parse_file,["src/rebar_core.erl"],[]}, > {rebar_erlc_compiler,compile_priority,1, > [{file,"src/rebar_erlc_compiler.erl"}, > {line,470}]}, > > That is: rebar fails to compile other things, but (here) is also seen > failing to compile itself. > > Upon investigation, I discover that I have both > "/usr/lib/erlang/lib/syntax_tools-1.6.12" and > "/usr/lib/erlang/lib/syntax_tools-1.6.13". The "-1.6.12" directory > contains "ebin", but no "src", and the "-1.6.13" directory contains > "src", but no "ebin". > > It would appear that my installation is using the newer one, and > failing to find the .beam files. Yes, code search really looking only for a directory under /usr/lib/erlang/lib and doesn't try to look inside, so if you install erlang broken into small packages, they must be consistent (though their dependencies should make it just work). > > So, some questions: > > 1. How do I (on Linux Mint 15, so basically Ubuntu) figure out which > APT repository the .deb file came from? This so that I can lay blame > appropriately. You can run apt-cache policy erlang-src and see which version is installed and from where it came. Could you show the output of apt-cache policy erlang-src apt-cache policy erlang-syntax-tools apt-cache policy erlang-base (or erlang-base-hipe, whichever is installed) > 2. I'd like to roll back the "erlang-src" package that broke this, but > it appears to have the same version number as the previous one both > are "1:16.b.3". Any idea how I do this? In fact, syntax-tools 1.6.13 appeared only in Erlang R16B03-1 (1:16.b.3.1-something in Debian-Ubuntu-Mint notation). The problem is that this version exists only in Debian stable, and hasn't come into Ubuntu and Mint yet, so I'm curious which repository you're using. And erlang-src 1:16.b.3.1-* should not be able to install with the earlier erlang-syntax-tools (1:16.b.3-*). So, I'm curious how could it happen. > 3. Can I simply delete the offending, newer, directory? You definitely can. > 4. If not, how do I get the binaries for "-1.6.13"? I guess, from the repository where you got erlang-src. Though, let's see the output from apt-cache policy first. > 5. Or: how do I compile the source to do that myself? > > My feeling is that Erlang Solutions have repackaged "erlang-src", and > somehow bumped the version number so that it got upgraded (not that I > can tell the difference), but that, for some reason, I'm not seeing > the corresponding "erlang-syntax-tools" upgrade, which would contain > the "ebin" directory. Erlang Solutions build one monolithic package, so I don't think that you've installed it. Cheers! -- Sergei Golovan From essen@REDACTED Sat Feb 1 12:48:27 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 01 Feb 2014 12:48:27 +0100 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: Message-ID: <52ECDF0B.3000602@ninenines.eu> Files are utf-8 by default now, you gotta add the following comment at the top of the files that require latin-1 to make them work like before. %% -*- coding: latin-1 -*- On 02/01/2014 12:11 PM, Max Lapshin wrote: > The same problem with lager.erl: > > {"don't choke on latin-1", > fun() -> > %% XXX if this test fails, check that this file > is encoded latin-1, not utf-8! > gen_event:add_handler(lager_event, > lager_file_backend, [{"test.log", info}, {lager_default_formatter}]), > lager:log(error, self(),"~ts", ["L???N-?"]), > {ok, Bin} = file:read_file("test.log"), > Pid = pid_to_list(self()), > Res = re:split(Bin, " ", [{return, list}, > {parts, 5}]), > ?assertMatch([_, _, "[error]", Pid, > [76,195,134,195,157,195,142,78,45,195,175,$\n]], Res) > end > }, > > Line > > lager:log(error, self(),"~ts", ["L???N-?"]), > > cannot even compile > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From essen@REDACTED Sat Feb 1 13:00:56 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 01 Feb 2014 13:00:56 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: <20140201053053.GA9640@k2r.org> <52EC8ED8.9010504@gmail.com> Message-ID: <52ECE1F8.8070208@ninenines.eu> The README says: OTP-11615 == otp == A new version scheme for OTP as well as all applications in OTP has been introduced. Versions will be handled similar to semantic versioning. The version number MAJOR.MINOR.PATCH will be changed as follows: -- MAJOR -- Increased when major changes, including incompatibilities, have been made. -- MINOR -- Increased when new functionality has been added. -- PATCH -- Increased when pure bug fixes have been made. Versions with even more parts may in exceptional cases exist. On 02/01/2014 11:17 AM, Vlad Dumitrescu wrote: > Hi! > > Erlide is another tools that needs to understand the version numbers, so > I'd like to ask if there is a spec for the new scheme. Is it 100% > semantic versioning? > > regards, > Vlad > > > On Sat, Feb 1, 2014 at 7:06 AM, Michael Truog > wrote: > > There is an autoconf macro here, that could help people using autoconf: > https://github.com/CloudI/__CloudI/blob/develop/src/m4/ax___erlang_otp_version.m4 > > > > On 01/31/2014 09:30 PM, Kenji Rikitake wrote: > > I believe quite a few pieces of software depends on the (now > old) version > number scheme of Erlang/OTP - > R[Major-Version][AB][Minor-__Version]. This has > been changed and may break some. (See OTP-11615 on 17.0-rc1 readme) > > FYI kerl depended on the old version number scheme, so I've > written a fix: > https://github.com/spawngrid/__kerl/pull/61 > > (already merged: thx Yurii Rashkovskii!) > > Checking the version number parsing functions especially on > Erlang/OTP > release/build engineering tools will be needed. > > FYI > Kenji Rikitake > And as always, many thanks to Kenneth and the OTP Release Team! > > ++> Kenneth Lundin > [2014-01-31 22:51:45 +0100]: > > Erlang/OTP 17.0-rc1 has been released. > > _________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/__listinfo/erlang-questions > > > > _________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/__listinfo/erlang-questions > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From n.oxyde@REDACTED Sat Feb 1 14:33:38 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 1 Feb 2014 14:33:38 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <52ECE1F8.8070208@ninenines.eu> References: <20140201053053.GA9640@k2r.org> <52EC8ED8.9010504@gmail.com> <52ECE1F8.8070208@ninenines.eu> Message-ID: A claim that the versioning scheme is "similar" to some specification has just as much weight to me than a claim saying Internet Explorer?s HTML is "similar" to the HTML defined in the W3 specs. Is it semantic versioning, or is it not? To me it isn?t. Heck, 17.0 isn?t even a valid semantic version. -- Anthony Ramine Le 1 f?vr. 2014 ? 13:00, Lo?c Hoguin a ?crit : > The README says: > > OTP-11615 == otp == > > A new version scheme for OTP as well as all applications in > OTP has been introduced. Versions will be handled similar to > semantic versioning. The version number MAJOR.MINOR.PATCH > will be changed as follows: > > -- MAJOR -- Increased when major changes, including > incompatibilities, have been made. > > -- MINOR -- Increased when new functionality has been added. > > -- PATCH -- Increased when pure bug fixes have been made. > > Versions with even more parts may in exceptional cases exist. > > On 02/01/2014 11:17 AM, Vlad Dumitrescu wrote: >> Hi! >> >> Erlide is another tools that needs to understand the version numbers, so >> I'd like to ask if there is a spec for the new scheme. Is it 100% >> semantic versioning? >> >> regards, >> Vlad >> >> >> On Sat, Feb 1, 2014 at 7:06 AM, Michael Truog > > wrote: >> >> There is an autoconf macro here, that could help people using autoconf: >> https://github.com/CloudI/__CloudI/blob/develop/src/m4/ax___erlang_otp_version.m4 >> >> >> >> On 01/31/2014 09:30 PM, Kenji Rikitake wrote: >> >> I believe quite a few pieces of software depends on the (now >> old) version >> number scheme of Erlang/OTP - >> R[Major-Version][AB][Minor-__Version]. This has >> been changed and may break some. (See OTP-11615 on 17.0-rc1 readme) >> >> FYI kerl depended on the old version number scheme, so I've >> written a fix: >> https://github.com/spawngrid/__kerl/pull/61 >> >> (already merged: thx Yurii Rashkovskii!) >> >> Checking the version number parsing functions especially on >> Erlang/OTP >> release/build engineering tools will be needed. >> >> FYI >> Kenji Rikitake >> And as always, many thanks to Kenneth and the OTP Release Team! >> >> ++> Kenneth Lundin > > [2014-01-31 22:51:45 +0100]: >> >> Erlang/OTP 17.0-rc1 has been released. >> >> _________________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/__listinfo/erlang-questions >> >> >> >> _________________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/__listinfo/erlang-questions >> >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From n.oxyde@REDACTED Sat Feb 1 14:36:24 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 1 Feb 2014 14:36:24 +0100 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: Message-ID: All worked out of the box with no peculiar configure script. Are you sure your setup isn?t broken? -- Anthony Ramine Le 1 f?vr. 2014 ? 12:09, Max Lapshin a ?crit : > Small notice. > > As apple is doing everything to make compilation hard, I had to compile with following keys: > > CC=clang CXX=clang++ LDD=clang ./configure --prefix=/usr/local/Cellar/erlang/R17.0 --enable-dirty-schedulers --with-dynamic-trace=dtrace --enable-smp-support --enable-kernel-poll --enable-vm-probes --enable-m64-build > > and also I had to move /usr/bin/xcrun to /usr/bin/xcrun-orig and replace original apple file with following bash script: > > #!/bin/bash > $@ > > without this manipulation I couldn't even configure erlang under Mac OS X 10.8.5 > > > > ------ > > Right after compilation I have problems: > > flussonic max$ ./rebar clean > ERROR: Failed to extract name from /Users/max/Sites/flussonic/deps/lhttpc/src/lhttpc.app.src: {27, > file_io_server, > invalid_unicode} > > Line 27 of lhttpc.app.src is: > > %%% @author Oscar Hellstr?m > > > It is umlaut in documentation. > > How should this be handled? > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From pablo.platt@REDACTED Sat Feb 1 14:44:55 2014 From: pablo.platt@REDACTED (pablo platt) Date: Sat, 1 Feb 2014 15:44:55 +0200 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: Message-ID: DTLS will not be part of R17? On Sat, Feb 1, 2014 at 3:36 PM, Anthony Ramine wrote: > All worked out of the box with no peculiar configure script. Are you sure > your setup isn't broken? > > -- > Anthony Ramine > > Le 1 f?vr. 2014 ? 12:09, Max Lapshin a ?crit : > > > Small notice. > > > > As apple is doing everything to make compilation hard, I had to compile > with following keys: > > > > CC=clang CXX=clang++ LDD=clang ./configure > --prefix=/usr/local/Cellar/erlang/R17.0 --enable-dirty-schedulers > --with-dynamic-trace=dtrace --enable-smp-support --enable-kernel-poll > --enable-vm-probes --enable-m64-build > > > > and also I had to move /usr/bin/xcrun to /usr/bin/xcrun-orig and replace > original apple file with following bash script: > > > > #!/bin/bash > > $@ > > > > without this manipulation I couldn't even configure erlang under Mac OS > X 10.8.5 > > > > > > > > ------ > > > > Right after compilation I have problems: > > > > flussonic max$ ./rebar clean > > ERROR: Failed to extract name from > /Users/max/Sites/flussonic/deps/lhttpc/src/lhttpc.app.src: {27, > > > file_io_server, > > > invalid_unicode} > > > > Line 27 of lhttpc.app.src is: > > > > %%% @author Oscar Hellstr?m > > > > > > It is umlaut in documentation. > > > > How should this be handled? > > > > > > > > > > _______________________________________________ > > 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 roger@REDACTED Sat Feb 1 15:27:22 2014 From: roger@REDACTED (Roger Lipscombe) Date: Sat, 1 Feb 2014 14:27:22 +0000 Subject: [erlang-questions] "erlang-src" package upgrade breaks "syntax_tools" and rebar builds In-Reply-To: References: Message-ID: (reposting to the list) On 1 February 2014 11:41, Sergei Golovan wrote: > You can run apt-cache policy erlang-src and see which version is > installed and from where it came. Could you show the output of > apt-cache policy erlang-src > apt-cache policy erlang-syntax-tools > apt-cache policy erlang-base (or erlang-base-hipe, whichever is installed) All of them report "http://packages.erlang-solutions.com/debian/ raring/contrib amd64 Packages" for 1:16.b.whatever; and Ubuntu raring for 1:15.b.1; I've got 1:16.b.3 installed of everything (except erlang-src, which I removed; see below). Thanks for pointing out apt-cache policy; didn't know about that command. >> 3. Can I simply delete the offending, newer, directory? > > You definitely can. I ran "dpkg -r erlang-src", which fixed the problem, at least until apt-get decides to "repair" it. > Erlang Solutions build one monolithic package, so I don't think that > you've installed it. Erlang Solutions build both. From https://www.erlang-solutions.com/downloads/download-erlang-otp: "The esl-erlang package is a file containg the complete installation: it includes the Erlang/OTP platform and all of its applications. The erlang package is a frontend to a number of smaller packages. Currently we support both erlang and esl-erlang." I've just done another "apt-get update; apt-get upgrade", and there's a whole heap of new packages (1:16.b.3-3), which appear to have fixed the problem; so it looks like I got caught mid-push, or the version number got messed up earlier. Either way, it all seems good now. Thanks, Roger. On 1 February 2014 11:41, Sergei Golovan wrote: > Hi Roger, > > On Fri, Jan 31, 2014 at 6:23 PM, Roger Lipscombe wrote: >> This morning, I let apt-get upgrade install a new "erlang-src" >> package. This has broken rebar. Specifically, I get the error message: >> >> ERROR: compile failed while processing /home/roger/Source/rebar/rebar: >> {'EXIT',{undef,[{epp_dodger,parse_file,["src/rebar_core.erl"],[]}, >> {rebar_erlc_compiler,compile_priority,1, >> [{file,"src/rebar_erlc_compiler.erl"}, >> {line,470}]}, >> >> That is: rebar fails to compile other things, but (here) is also seen >> failing to compile itself. >> >> Upon investigation, I discover that I have both >> "/usr/lib/erlang/lib/syntax_tools-1.6.12" and >> "/usr/lib/erlang/lib/syntax_tools-1.6.13". The "-1.6.12" directory >> contains "ebin", but no "src", and the "-1.6.13" directory contains >> "src", but no "ebin". >> >> It would appear that my installation is using the newer one, and >> failing to find the .beam files. > > Yes, code search really looking only for a directory under > /usr/lib/erlang/lib and doesn't try to look inside, so if you install > erlang broken into small packages, they must be consistent (though > their dependencies should make it just work). > >> >> So, some questions: >> >> 1. How do I (on Linux Mint 15, so basically Ubuntu) figure out which >> APT repository the .deb file came from? This so that I can lay blame >> appropriately. > > You can run apt-cache policy erlang-src and see which version is > installed and from where it came. Could you show the output of > apt-cache policy erlang-src > apt-cache policy erlang-syntax-tools > apt-cache policy erlang-base (or erlang-base-hipe, whichever is installed) > >> 2. I'd like to roll back the "erlang-src" package that broke this, but >> it appears to have the same version number as the previous one both >> are "1:16.b.3". Any idea how I do this? > > In fact, syntax-tools 1.6.13 appeared only in Erlang R16B03-1 > (1:16.b.3.1-something in Debian-Ubuntu-Mint notation). The problem is > that this version exists only in Debian stable, and hasn't come into > Ubuntu and Mint yet, so I'm curious which repository you're using. And > erlang-src 1:16.b.3.1-* should not be able to install with the earlier > erlang-syntax-tools (1:16.b.3-*). So, I'm curious how could it happen. > >> 3. Can I simply delete the offending, newer, directory? > > You definitely can. > >> 4. If not, how do I get the binaries for "-1.6.13"? > > I guess, from the repository where you got erlang-src. Though, let's > see the output from apt-cache policy first. > >> 5. Or: how do I compile the source to do that myself? >> >> My feeling is that Erlang Solutions have repackaged "erlang-src", and >> somehow bumped the version number so that it got upgraded (not that I >> can tell the difference), but that, for some reason, I'm not seeing >> the corresponding "erlang-syntax-tools" upgrade, which would contain >> the "ebin" directory. > > Erlang Solutions build one monolithic package, so I don't think that > you've installed it. > > Cheers! > -- > Sergei Golovan From vladdu55@REDACTED Sat Feb 1 15:57:23 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Sat, 1 Feb 2014 15:57:23 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: <20140201053053.GA9640@k2r.org> <52EC8ED8.9010504@gmail.com> <52ECE1F8.8070208@ninenines.eu> Message-ID: I agree with this. Actually, the version in the boot script is just "17", when it should probably be "17.0.0-rc1". Regards, Vlad On 1 Feb 2014 14:33, "Anthony Ramine" wrote: > A claim that the versioning scheme is "similar" to some specification has > just as much weight to me than a claim saying Internet Explorer's HTML is > "similar" to the HTML defined in the W3 specs. > > Is it semantic versioning, or is it not? To me it isn't. Heck, 17.0 isn't > even a valid semantic version. > > -- > Anthony Ramine > > Le 1 f?vr. 2014 ? 13:00, Lo?c Hoguin a ?crit : > > > The README says: > > > > OTP-11615 == otp == > > > > A new version scheme for OTP as well as all applications in > > OTP has been introduced. Versions will be handled similar to > > semantic versioning. The version number MAJOR.MINOR.PATCH > > will be changed as follows: > > > > -- MAJOR -- Increased when major changes, including > > incompatibilities, have been made. > > > > -- MINOR -- Increased when new functionality has been added. > > > > -- PATCH -- Increased when pure bug fixes have been made. > > > > Versions with even more parts may in exceptional cases exist. > > > > On 02/01/2014 11:17 AM, Vlad Dumitrescu wrote: > >> Hi! > >> > >> Erlide is another tools that needs to understand the version numbers, so > >> I'd like to ask if there is a spec for the new scheme. Is it 100% > >> semantic versioning? > >> > >> regards, > >> Vlad > >> > >> > >> On Sat, Feb 1, 2014 at 7:06 AM, Michael Truog >> > wrote: > >> > >> There is an autoconf macro here, that could help people using > autoconf: > >> > https://github.com/CloudI/__CloudI/blob/develop/src/m4/ax___erlang_otp_version.m4 > >> < > https://github.com/CloudI/CloudI/blob/develop/src/m4/ax_erlang_otp_version.m4 > > > >> > >> > >> On 01/31/2014 09:30 PM, Kenji Rikitake wrote: > >> > >> I believe quite a few pieces of software depends on the (now > >> old) version > >> number scheme of Erlang/OTP - > >> R[Major-Version][AB][Minor-__Version]. This has > >> been changed and may break some. (See OTP-11615 on 17.0-rc1 > readme) > >> > >> FYI kerl depended on the old version number scheme, so I've > >> written a fix: > >> https://github.com/spawngrid/__kerl/pull/61 > >> > >> (already merged: thx Yurii Rashkovskii!) > >> > >> Checking the version number parsing functions especially on > >> Erlang/OTP > >> release/build engineering tools will be needed. > >> > >> FYI > >> Kenji Rikitake > >> And as always, many thanks to Kenneth and the OTP Release Team! > >> > >> ++> Kenneth Lundin >> > [2014-01-31 22:51:45 +0100]: > >> > >> Erlang/OTP 17.0-rc1 has been released. > >> > >> _________________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/__listinfo/erlang-questions > >> > >> > >> > >> _________________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/__listinfo/erlang-questions > >> > >> > >> > >> > >> > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > >> > > > > -- > > Lo?c Hoguin > > http://ninenines.eu > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Sat Feb 1 16:32:32 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Sat, 1 Feb 2014 10:32:32 -0500 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: Message-ID: My experiences match Anthony's -- I grabbed the tarball on Mavericks, unpacked, configured, and ran make, no problems at all. --steve On Sat, Feb 1, 2014 at 8:36 AM, Anthony Ramine wrote: > All worked out of the box with no peculiar configure script. Are you sure > your setup isn't broken? > > -- > Anthony Ramine > > Le 1 f?vr. 2014 ? 12:09, Max Lapshin a ?crit : > > > Small notice. > > > > As apple is doing everything to make compilation hard, I had to compile > with following keys: > > > > CC=clang CXX=clang++ LDD=clang ./configure > --prefix=/usr/local/Cellar/erlang/R17.0 --enable-dirty-schedulers > --with-dynamic-trace=dtrace --enable-smp-support --enable-kernel-poll > --enable-vm-probes --enable-m64-build > > > > and also I had to move /usr/bin/xcrun to /usr/bin/xcrun-orig and replace > original apple file with following bash script: > > > > #!/bin/bash > > $@ > > > > without this manipulation I couldn't even configure erlang under Mac OS > X 10.8.5 > > > > > > > > ------ > > > > Right after compilation I have problems: > > > > flussonic max$ ./rebar clean > > ERROR: Failed to extract name from > /Users/max/Sites/flussonic/deps/lhttpc/src/lhttpc.app.src: {27, > > > file_io_server, > > > invalid_unicode} > > > > Line 27 of lhttpc.app.src is: > > > > %%% @author Oscar Hellstr?m > > > > > > It is umlaut in documentation. > > > > How should this be handled? > > > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Sat Feb 1 16:37:57 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Sat, 1 Feb 2014 19:37:57 +0400 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: Message-ID: I have not Mavericks, but previous version of OS X and there are big problems here with compiling anything =) -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.goertzen@REDACTED Sat Feb 1 16:58:01 2014 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Sat, 1 Feb 2014 09:58:01 -0600 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: Message-ID: Excellent! I have been using maps from Egil's branch for a while now and map pattern matching has proven to be very useful. Going back to not having maps would be *very* hard. Regarding dirty schedulers: - Just to confirm my understanding: When I use the dirty scheduler API I can write NIFs that grind the CPU or wait on IO for minutes at a time, right? - When using the API you have to indicate if you are IO or CPU bound. What is the consequence of getting that wrong (ie, you are CPU bound when you said you would be IO bound or vice versa.) - Are dirty schedulers a stepping stone to native processes? For what I use Erlang for, R17 is probably the biggest release in the 9 years or so that I have been watching Erlang. Fine work, and many thanks. Cheers, Dan. On Fri, Jan 31, 2014 at 3:51 PM, Kenneth Lundin wrote: > Erlang/OTP 17.0-rc1 has been released. > > This is an alpha release, which will be followed by a planned beta release > about a month later and a final > OTP 17.0 product release in the end of March 26, 2014. > Between the alpha and beta and final release there will be new updates of > the master branch with corrections > and minor new features. Occasionally there might be new tags which we in > that > case will communicate and ask you to test. > > Erlang/OTP 17.0 is a new major release with new features, quite a few > (characteristics) improvements, > as well as some incompatibilities. See the README file and the > documentation for more details. > > We would like to ask you to download and test the alpha release and send > us your feedback as soon as possible, > so that we can make the necessary corrections before OTP 17.0-rc2 and OTP > 17.0, respectively. > The release contains many changes; thus, some unexpected incompatibilities > or issues may have slipped through > our tests. Please try to build and run your current products/applications > and let us know about any problems. > > Note! The new datatype MAP is not properly documented yet but the EEP 43 > http://www.erlang.org/eeps/eep-0043.html > will provide a good start. Also note that it is a limited implementation > of maps implemented so far: > > - no variable keys are allowed > - native code can not be generated for modules using maps > > Some other highlights of the release are: > > - Maps, a new dictionary data type (experimental) > - A more natural mapping from ASN.1 OCTET STRING and BIT STRING to > Erlang types, > and other ASN.1 improvements and optimizations > - The {active, N} socket option for TCP, UDP, and SCTP > - A new (optional) scheduler utilization balancing mechanism > - Migration of memory carriers has been enabled by default on all ERTS > internal > memory allocators > - Increased garbage collection tenure rate > - Experimental "dirty schedulers" functionality > - Funs can now be given names > - Miscellaneous unicode support enhancements > - A new, semantic version scheme for OTP and its applications > > You can find the README file with more detailed info at > > http://www.erlang.org/download/otp_src_17.0-rc1.readme > > You can download the full source distribution from > > http://www.erlang.org/download/otp_src_17.0-rc1.tar.gz > http://www.erlang.org/download/otp_src_17.0-rc1.readme (this file) > > Note: To unpack the TAR archive you need a GNU TAR compatible program. > > For installation instructions please read the README that is part of the > distribution. > > You can also find this release at the official Erlang/OTP Git-repository > at Github here: > > https://github.com/erlang/otp tagged *OTP_17.0-rc1* > > > The Windows binary distribution can be downloaded from > > http://www.erlang.org/download/otp_win32_17.0-rc1.exe > http://www.erlang.org/download/otp_win64_17.0-rc1.exe > > > On-line documentation can be found at http://www.erlang.org/doc/. > You can also download the complete HTML documentation or the Unix manual > files > > http://www.erlang.org/download/otp_doc_html_17.0-rc1.tar.gz > http://www.erlang.org/download/otp_doc_man_17.0-rc1.tar.gz > > We also want to thank those that sent us patches, suggestions and bug > reports. > > The Erlang/OTP Team at Ericsson > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.goertzen@REDACTED Sat Feb 1 17:00:37 2014 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Sat, 1 Feb 2014 10:00:37 -0600 Subject: [erlang-questions] SNMP agent: modifying vacm, community, etc In-Reply-To: References: Message-ID: I will look into that. The SNMP app uses its own database by default; there must be a config switch to use mnesia as I have definitely seen references to it in the source code. Thanks, Dan. On Fri, Jan 31, 2014 at 9:44 AM, Attila Rajmund Nohl < attila.r.nohl@REDACTED> wrote: > 2014-01-30 Daniel Goertzen : > > I am working on an snmp agent and trying to figure out the 'proper' way > to > > locally edit tables like vacm, community, usm, etc. > > > > 1. One approach is to keep modifying config files through the > snmpa_config > > module and then call configure() on the appropriate mib module to reload > the > > config. > > > > 2. Another approach is to try to do everything through the appropriate > mib > > module, but in general they only provide add and delete operations (I > need > > to be able to see what is there). > > You might want to read directly the mnesia tables to get the > configured targets. Of course, this is not nice. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Sat Feb 1 17:28:53 2014 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Sat, 1 Feb 2014 17:28:53 +0100 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: Message-ID: > I have not Mavericks, but previous version of OS X and there are big > problems here with compiling anything =) > FWIW, I am using 10.8.5 too (Mountain Lion) and the installation went ok, with no issues at all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Sat Feb 1 17:34:06 2014 From: erlang@REDACTED (Joe Armstrong) Date: Sat, 1 Feb 2014 17:34:06 +0100 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: Message-ID: On Fri, Jan 31, 2014 at 10:51 PM, Kenneth Lundin wrote: > Erlang/OTP 17.0-rc1 has been released. > Fantastic - great - this is a major change to Erlang. I've written an article that documents the biggest changes. Big changes to Erlang http://joearms.github.com/2014/02/01/big-changes-to-erlang.html Cheers /Joe > This is an alpha release, which will be followed by a planned beta release > about a month later and a final > OTP 17.0 product release in the end of March 26, 2014. > Between the alpha and beta and final release there will be new updates of > the master branch with corrections > and minor new features. Occasionally there might be new tags which we in > that > case will communicate and ask you to test. > > Erlang/OTP 17.0 is a new major release with new features, quite a few > (characteristics) improvements, > as well as some incompatibilities. See the README file and the > documentation for more details. > > We would like to ask you to download and test the alpha release and send > us your feedback as soon as possible, > so that we can make the necessary corrections before OTP 17.0-rc2 and OTP > 17.0, respectively. > The release contains many changes; thus, some unexpected incompatibilities > or issues may have slipped through > our tests. Please try to build and run your current products/applications > and let us know about any problems. > > Note! The new datatype MAP is not properly documented yet but the EEP 43 > http://www.erlang.org/eeps/eep-0043.html > will provide a good start. Also note that it is a limited implementation > of maps implemented so far: > > - no variable keys are allowed > - native code can not be generated for modules using maps > > Some other highlights of the release are: > > - Maps, a new dictionary data type (experimental) > - A more natural mapping from ASN.1 OCTET STRING and BIT STRING to > Erlang types, > and other ASN.1 improvements and optimizations > - The {active, N} socket option for TCP, UDP, and SCTP > - A new (optional) scheduler utilization balancing mechanism > - Migration of memory carriers has been enabled by default on all ERTS > internal > memory allocators > - Increased garbage collection tenure rate > - Experimental "dirty schedulers" functionality > - Funs can now be given names > - Miscellaneous unicode support enhancements > - A new, semantic version scheme for OTP and its applications > > You can find the README file with more detailed info at > > http://www.erlang.org/download/otp_src_17.0-rc1.readme > > You can download the full source distribution from > > http://www.erlang.org/download/otp_src_17.0-rc1.tar.gz > http://www.erlang.org/download/otp_src_17.0-rc1.readme (this file) > > Note: To unpack the TAR archive you need a GNU TAR compatible program. > > For installation instructions please read the README that is part of the > distribution. > > You can also find this release at the official Erlang/OTP Git-repository > at Github here: > > https://github.com/erlang/otp tagged *OTP_17.0-rc1* > > > The Windows binary distribution can be downloaded from > > http://www.erlang.org/download/otp_win32_17.0-rc1.exe > http://www.erlang.org/download/otp_win64_17.0-rc1.exe > > > On-line documentation can be found at http://www.erlang.org/doc/. > You can also download the complete HTML documentation or the Unix manual > files > > http://www.erlang.org/download/otp_doc_html_17.0-rc1.tar.gz > http://www.erlang.org/download/otp_doc_man_17.0-rc1.tar.gz > > We also want to thank those that sent us patches, suggestions and bug > reports. > > The Erlang/OTP Team at Ericsson > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex@REDACTED Sat Feb 1 17:38:56 2014 From: alex@REDACTED (Aleksandar Radulovic) Date: Sat, 1 Feb 2014 17:38:56 +0100 Subject: [erlang-questions] CZMQ licensing In-Reply-To: References: Message-ID: Hey Pieter, On Fri, Jan 31, 2014 at 12:55 PM, Pieter Hintjens wrote: > > Ps. native Erlang ZMTP would be fantastic. We've done this in Java and > .NET, and it's been very positive for those communities. > I've implemented [1] a native ZMTP protocol in Erlang. It currently supports 13/ZMTP and 15/ZMTP and I've been thinking of implementing 20/ZMTP sometime soon. It was implemented (only) for laughs and to prove to some people at work how easy it would be to do it in Erlang. [1] https://github.com/a13x/ezmtp Cheers, alex -- a lex 13 x http://a13x.net | @a13xnet -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Sat Feb 1 17:40:43 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Sat, 1 Feb 2014 11:40:43 -0500 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: Message-ID: On Sat, Feb 1, 2014 at 10:58 AM, Daniel Goertzen wrote: > Excellent! > > I have been using maps from Egil's branch for a while now and map pattern > matching has proven to be very useful. Going back to not having maps would > be *very* hard. > > Regarding dirty schedulers: > > - Just to confirm my understanding: When I use the dirty scheduler API I > can write NIFs that grind the CPU or wait on IO for minutes at a time, > right? > Yes, the dirty schedulers don't run any jobs that aren't specifically marked as dirty, nor do they steal from regular schedulers if they're idle. Please test this long-running job aspect and let us know if you hit any problems. Be aware of the following: 1) Dirty jobs are queued on dirty run queues, where there's one run queue for each dirty scheduler type (CPU or I/O). If you have so many long-running jobs that all your dirty scheduler threads are busy, new dirty jobs will sit in the appropriate run queue until a dirty scheduler thread becomes available. 2) You can't have more dirty CPU schedulers than normal schedulers, to keep them from interfering too much with normal schedulers. In RC1 there's no support for changing the number of dirty CPU schedulers online at run-time, but I believe I'll have that available in time for RC2. 3) You can have as many dirty I/O schedulers as you like, but just like the async thread pool, this number is fixed at boot time and will not have support for changing the number online at run-time like dirty CPU schedulers will. Basically the dirty I/O schedulers come up at boot time and stay up. 4) Dirty schedulers in RC1 do not suspend when multi-scheduling is blocked. (But that's OK as nobody in their right mind blocks multi-scheduling for real apps on purpose anyway.) Hopefully I'll have this working in time for RC2. 5) Currently, dirty schedulers are tied together with SMP support. In a future release this restriction will be removed, so that you can have dirty schedulers even if normal SMP schedulers are not configured at build time. 6) In the future, drivers and BIFs will also be able to use dirty schedulers, but this isn't part of RC1, and likely won't be in RC2 either. - When using the API you have to indicate if you are IO or CPU bound. What > is the consequence of getting that wrong (ie, you are CPU bound when you > said you would be IO bound or vice versa.) > If you have a lot of dirty I/O schedulers and you put CPU-bound jobs on them, you might interfere with normal schedulers, but to what extent I don't know. If you put I/O-bound jobs on dirty CPU schedulers, and they take up those threads for a long time waiting for I/O, it might cause your CPU-bound jobs to back up in the dirty CPU scheduler run queue. > - Are dirty schedulers a stepping stone to native processes? > I'd say yes, but Rickard Green is the best one to answer that. Either way, see http://www.erlang-factory.com/upload/presentations/377/RickardGreen-NativeInterface.pdffor more info. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.goertzen@REDACTED Sat Feb 1 18:33:39 2014 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Sat, 1 Feb 2014 11:33:39 -0600 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: Message-ID: Thank you for all the details. I think I have a handle on how dirty schedulers work now. You mentioned that you are working on non-SMP support for dirty schedules. I note that enif_send() currently requires SMP when used from a non-NIF calling thread; would that requirement also be dropped by your work or is that a completely separate area of code? I run Erlang on smaller single core embedded systems and I currently have to explicitly force use of SMP to make my nifs work (erlang picks the non-SMP scheduler by default on single core systems). Not a big deal for my case, but it could cause portability problems for other NIF-using apps (app developed on multicore system breaks on single core system without extra VM flags) Cheers, Dan. On Sat, Feb 1, 2014 at 10:40 AM, Steve Vinoski wrote: > > > > On Sat, Feb 1, 2014 at 10:58 AM, Daniel Goertzen < > daniel.goertzen@REDACTED> wrote: > >> Excellent! >> >> I have been using maps from Egil's branch for a while now and map pattern >> matching has proven to be very useful. Going back to not having maps would >> be *very* hard. >> >> Regarding dirty schedulers: >> >> - Just to confirm my understanding: When I use the dirty scheduler API I >> can write NIFs that grind the CPU or wait on IO for minutes at a time, >> right? >> > > Yes, the dirty schedulers don't run any jobs that aren't specifically > marked as dirty, nor do they steal from regular schedulers if they're idle. > Please test this long-running job aspect and let us know if you hit any > problems. > > Be aware of the following: > > 1) Dirty jobs are queued on dirty run queues, where there's one run queue > for each dirty scheduler type (CPU or I/O). If you have so many > long-running jobs that all your dirty scheduler threads are busy, new dirty > jobs will sit in the appropriate run queue until a dirty scheduler thread > becomes available. > > 2) You can't have more dirty CPU schedulers than normal schedulers, to > keep them from interfering too much with normal schedulers. In RC1 there's > no support for changing the number of dirty CPU schedulers online at > run-time, but I believe I'll have that available in time for RC2. > > 3) You can have as many dirty I/O schedulers as you like, but just like > the async thread pool, this number is fixed at boot time and will not have > support for changing the number online at run-time like dirty CPU > schedulers will. Basically the dirty I/O schedulers come up at boot time > and stay up. > > 4) Dirty schedulers in RC1 do not suspend when multi-scheduling is > blocked. (But that's OK as nobody in their right mind blocks > multi-scheduling for real apps on purpose anyway.) Hopefully I'll have this > working in time for RC2. > > 5) Currently, dirty schedulers are tied together with SMP support. In a > future release this restriction will be removed, so that you can have dirty > schedulers even if normal SMP schedulers are not configured at build time. > > 6) In the future, drivers and BIFs will also be able to use dirty > schedulers, but this isn't part of RC1, and likely won't be in RC2 either. > > - When using the API you have to indicate if you are IO or CPU bound. >> What is the consequence of getting that wrong (ie, you are CPU bound when >> you said you would be IO bound or vice versa.) >> > > If you have a lot of dirty I/O schedulers and you put CPU-bound jobs on > them, you might interfere with normal schedulers, but to what extent I > don't know. If you put I/O-bound jobs on dirty CPU schedulers, and they > take up those threads for a long time waiting for I/O, it might cause your > CPU-bound jobs to back up in the dirty CPU scheduler run queue. > > >> - Are dirty schedulers a stepping stone to native processes? >> > > I'd say yes, but Rickard Green is the best one to answer that. Either way, > see > http://www.erlang-factory.com/upload/presentations/377/RickardGreen-NativeInterface.pdffor more info. > > --steve > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustav.simonsson@REDACTED Sat Feb 1 18:41:15 2014 From: gustav.simonsson@REDACTED (Gustav Simonsson) Date: Sat, 1 Feb 2014 18:41:15 +0100 Subject: [erlang-questions] Potential bug in OTP_17.0-rc1 when converting map to binary and back Message-ID: Hi, After the announcement of OTP_17.0-rc1 I compiled the source and started playing with maps and proper. After testing a bunch of stuff like maps:to_list(maps:from_list(List)) I replicated a classic proper example to verify binary_to_term(term_to_binary(T)). ======================================== ======================================== -module(t). -include_lib("proper/include/proper.hrl"). -compile([export_all]). prop_term_binary() -> ?FORALL(T, term(), T =:= binary_to_term(term_to_binary(T)) ). ======================================== ======================================== proper:quickcheck(t:prop_term_binary(), [{numtests, 10000}]). (alot of dots ...) OK: Passed 10000 test(s). All is well. Then, I created this property: prop_maps2() -> ?FORALL({PL}, {list({term(), term()})}, begin PropList1 = lists:ukeysort(1, PL), Map1 = maps:from_list(PropList1), Map1 =:= binary_to_term(term_to_binary(Map1)) end ). ======================================== ======================================== 18:33:05 batman ~/projects/erl_maps> erl Erlang/OTP 17 [RELEASE CANDIDATE 1] [erts-6.0] [source-fdcdaca] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] Eshell V6.0 (abort with ^G) 1> c(t). {ok,t} 2> proper:quickcheck(t:prop_maps2(), [{numtests, 10000}]). .................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................! Failed: After 4066 test(s). {[{[-3.916167101796315,5,-14.383620880842821,25,-11,-5,4,-10.251333004157411,-80,21,-11.9643845075958,-10,-16,-5,'\005?V?\027>T??23??n?',-4,<<229>>],6},{<<105,172,229,134,160,163,53,135,179,161,236,42,39,31:5>>,{-11.676717778419862,17.707585198254716,33,'\206\003-f\f\003?\236R',<<192,123,148,228,7:3>>,[],{[]},-9,-7,-6,{9,'\200m?',<<1:3>>,{},3.823878214590697},-20.191151612002688}},{-8,<<97,213,88,122,106,212,110,126,3:2>>},{[[[],[],14.928837856623751,{}],{},[]],{'\222?&?\203\204\217?\000u\206?\235!m',-19.469218108368914,'',[],{[10.946799426461407,[[-3.6593067623424336]],[],'?~\225\n?\207m\\'],[{}]},-56,-1.7371040930562214,3,9,-2,'\037E?8?,????@?@?U\221??','?)\004???F?',[]}},{<<112,8:4>>,'P?B\026\032zE:?\230d'},{20,'U?%V??'},{{8,-5,'?[?m\206?Y(\023\002?\200\201\f',5.860510875770583,-11.499743607476358,-14,78.9417958106197,23,-32},[]},{78.81062902366494,[16,'\n?\'?9O????\d',20,-28.505106763693114,'?\232?`?kB??\035???',9.491181213276489,-4.446055020279977,2,'??','???)?Q\026g',[],{22,[-49.87040520039398,{},20,'(??A\037?\v\203\031(M"??H?']},'?}??^',-190.16730030976382,{},-9]},{{-2,9,-15,'?\212m?\017\227',130,7.406083792942151,47.91530575448283,17,-56,-27,1.1696130495141,8,<<10,97,84,1,210,239,179,245,75,99,204,64,4:3>>,'','\024??\020b?\201>L'},{20,-8.728673595127718,5.131028941847757,{},-22.264422165841957,[[]]}},{-0.805323038965695,['?t]\002?B???]\236\207Jq&Gk',-23,'??\232{\016??g\016???\017?\036??\t','??',-23.674996673031742,3,5.511692289051506,-14,-18.02109289321752,0.7818131441815134]},{{[11.68346635783379,'??\225\032\232? ,?|\022 \205L\205',0,[{<<123:7>>}],-2.4217323982351866,1.1404903952928618,{[{}],{},'?n?\032?\b?+\e <;?f???'},12.184525559260809,-10.00845000093209,-13,[56],{}],'??',-4,26.708298789331433,4,<<255,6,0:1>>,'?',10,2.3535448113644706,'?',-112.15429185940658,4.322599970691285,20.556338272619058},{[-9.047222745894432,-6,[]]}},{{-10.004049310388854,'U','4p{J?k?p?\235',24,'??G??\034\020??','??qb8O??\b\220',-19,-45.108220054002054,'[q\022\fx\t\037a\005x?',-15,2.9443008897224243,<<4,150,219,33,213,112,8,171,0,154,124,45:7>>,-12.217387380533854,'\r@ '},{{{{}},{},0.9613990232005811,['.O\003\017?&?\txB-DV???',{}]},-5,7,-9,[{}],'[??\222;\205\r7?,6)?I\222?[','\213??xDp?',2,22,-62.085919420904354}},{[5,<<142,163,209,185,37,35:6>>,{'??\213??',{[],[],<<173,3:2>>},'',[]},-18.799834786170464],10.169565402950454}]} Shrinking .......Segmentation fault (core dumped) ======================================== ======================================== Erlang version: git tag OTP_17.0-rc1 OS: Ubuntu server 13.10 Arch: Intel(R) Core(TM) i7-3770T Please let me know if you need a core and/or more details. It should be easy to replicate given the above code though on various archs. Cheers, Gustav Simonsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim@REDACTED Sat Feb 1 19:07:56 2014 From: tim@REDACTED (Tim Stewart) Date: Sat, 01 Feb 2014 13:07:56 -0500 Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: References: Message-ID: <52ED37FC.8040703@stoo.org> Hello, On 01/31/2014 01:03 PM, Attila Rajmund Nohl wrote: > 2014-01-30 kraythe .: > [...] >> >The tools are, well frankly, garbage. Sorry, in 2014 to be pushed back to >> >coding with VIM and makefiles is primitive. Rebar is crytptic and just the >> >pet project of a guy on GIT. Compared to Gradle, Maven and even (though I >> >don't care for it much) SBT, rebar is ... lacking. I want to spend time >> >working on my business logic, not fighting tools. There are plugins for >> >eclipse and intellij but they have minimal functionality and i keep >> >reverting back to vim. > In some sense you're right, in some sense not. In a previous project > our "integration build" was quite slow, when behaviors were modified, > everything was recompiled because our Makefiles lacked proper > dependencies. So some automatic dependecy generator would be nice (I > don't know what rebar does). On the other hand in the normal The compile module (http://erlang.org/doc/man/compile.html) supports generating Makefile rules to track header dependencies via the `makedep' option. You can also invoke this via erlc's `-M' option. This may not be the solution to Attila's integration build dependency problems, but I feel it is worth mentioning in the context of this thread. -TimS -- Tim Stewart tim@REDACTED From baliulia@REDACTED Sat Feb 1 19:09:49 2014 From: baliulia@REDACTED (=?UTF-8?B?SWduYXMgVnnFoW5pYXVza2Fz?=) Date: Sat, 01 Feb 2014 19:09:49 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: <20140201053053.GA9640@k2r.org> <52EC8ED8.9010504@gmail.com> <52ECE1F8.8070208@ninenines.eu> Message-ID: <52ED386D.9020802@gmail.com> First of all, excited to hear about the RC! Anyway, I agree with everyone that the version numbering change is a bit fishy. As already mentioned, this is a major backwards incompatible change for everything that tries to parse the release version. Secondly, as Anthony pointed out, it is indeed not Semantic Versioning at all if it's anything like "17.0-rc1". Perhaps a middle ground solution would be to e.g. stick with something like. R[A|B]-- with, say the and parts being optional. In that way you can increment the versions using semantic versioning, but still stay as backwards compatible as possible (e.g. simple parsers that parse based on lexicographic order or only look at the major version will stay happy). -- Ignas From kostis@REDACTED Sat Feb 1 19:37:39 2014 From: kostis@REDACTED (Kostis Sagonas) Date: Sat, 01 Feb 2014 19:37:39 +0100 Subject: [erlang-questions] Potential bug in OTP_17.0-rc1 when converting map to binary and back In-Reply-To: References: Message-ID: <52ED3EF3.9070802@cs.ntua.gr> On 02/01/2014 06:41 PM, Gustav Simonsson wrote: > After the announcement of OTP_17.0-rc1 I compiled the source and started > playing with maps and proper. > > After testing a bunch of stuff like maps:to_list(maps:from_list(List)) I > replicated a classic proper example to verify > binary_to_term(term_to_binary(T)). > .... > 2> proper:quickcheck(t:prop_maps2(), [{numtests, 10000}]). > ............ ............................................... > Shrinking .......Segmentation fault (core dumped) > .... > Please let me know if you need a core and/or more details. > It should be easy to replicate given the above code though on various archs. Indeed, this is very easy to replicate. On my first attempt, I got equally unlucky as Simon and OTP seg faulted when PropEr attempted to shrink the offending test case. On my second attempt, I had better luck and shrinking worked: Eshell V6.0 (abort with ^G) 1> proper:quickcheck(t:prop_maps2(), 10000). ...... ..... Failed: After 2090 test(s). {[{{{},'m?\030??',[],[[]],[]},{'\031?DZ',75.25615709172015,9}},{{<<47,42,83,2:2>>},[{11.611456128457124,{[]},[],-7.568651682554733}]},{'?\204H?????',[[],[],[],-10,80,{},[]]},{{'?\211l\030x\220?\224?'},[-14.081931069838275,1,['\236J?',0],3,3.8086424574055755]},{{[],[{},[[{}]]],{},{}},{-7.668921456100702,-0.8537275447686942,0.2046413634772726,8.71091095449412,'X7??\237\030',{-11,{{}},-0.95809288292835,[{{}},'?u?']},-5.604771642421137}},{{[{},22.021800217282916],-2,7.289863377212738,'?]?\d',10.348710823806195},{{[[{},[5.428258856857506],[],'O\030:',-2]],22.20548610862955,102}}},{[1.730805378918121,'\201\226o\032',-5,-4,0.21576771814263207],<<145,249,4,86,26,4:3>>}]} Shrinking ...................(19 time(s)) {[{{{},'m?\030??',[],[[]],[]},{'\031?DZ',75.25615709172015,9}},{{<<47,42,83,2:2>>},[{11.611456128457124,{[]},[],-7.568651682554733}]},{'\037\204H?>w6?',[[],[],[],-8,80,{},[]]},{{'?\211l\030x\220?\224?'},[-14.081931069838275,1,['z\003-',0],3,3.8086424574055755]},{'\v?6\002',{-7.668921456100702,-0.8537275447686942,0.2046413634772726,8.71091095449412,'X7??\237\030',{-11,{{}},-0.95809288292835,[{{}},'?u?']},-5.604771642421137}},{{[{},22.021800217282916],-2,7.289863377212738,'?]?\d',10.348710823806195},{{[[{},[5.428258856857506],[],'O\030:',-2]],22.20548610862955,102}}},{[1.730805378918121,'\030\023%\020',-5,-4,0.21576771814263207],<<145,249,4,49,26,4:3>>}]} false false PropEr can be obtained from: http://proper.softlab.ntua.gr/ Kostis From g@REDACTED Sat Feb 1 20:11:03 2014 From: g@REDACTED (Garrett Smith) Date: Sat, 1 Feb 2014 13:11:03 -0600 Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: <52ED37FC.8040703@stoo.org> References: <52ED37FC.8040703@stoo.org> Message-ID: I would add one more feature of Erlang that I don't think has been mentioned: the community is one of the best you will find in all of software. To illustrate, please refer to this email thread, which I came across: https://groups.google.com/forum/#!topic/erlang-programming/t3jbMyKPLdw Here you have someone who is asking very honest questions about Erlang vis-a-vis other languages. In many communities, this sort of question, while not intended to do so, would spark a series of flame wars and religious zealotry. But this question, on the Erlang list, brought forth some of the most brilliant and thoughtful contributions to important problems in software I've ever seen. What is this worth in your comparison of languages? As an aside, I think this particular email thread, which I came across, should be printed without editing as a pamphlet and handed out at user groups and software conferences as a treatise on core principles of language and tool design and civil discourse. If others are willing to join me, I would consider shaving my head and wearing brightly colors robes and do this. Garrett On Sat, Feb 1, 2014 at 12:07 PM, Tim Stewart wrote: > Hello, > > > On 01/31/2014 01:03 PM, Attila Rajmund Nohl wrote: >> >> 2014-01-30 kraythe .: >> [...] >>> >>> >The tools are, well frankly, garbage. Sorry, in 2014 to be pushed back >>> > to >>> >coding with VIM and makefiles is primitive. Rebar is crytptic and just >>> > the >>> >pet project of a guy on GIT. Compared to Gradle, Maven and even (though >>> > I >>> >don't care for it much) SBT, rebar is ... lacking. I want to spend time >>> >working on my business logic, not fighting tools. There are plugins for >>> >eclipse and intellij but they have minimal functionality and i keep >>> >reverting back to vim. >> >> In some sense you're right, in some sense not. In a previous project >> our "integration build" was quite slow, when behaviors were modified, >> everything was recompiled because our Makefiles lacked proper >> dependencies. So some automatic dependecy generator would be nice (I >> don't know what rebar does). On the other hand in the normal > > > The compile module (http://erlang.org/doc/man/compile.html) supports > generating Makefile rules to track header dependencies via the `makedep' > option. You can also invoke this via erlc's `-M' option. > > This may not be the solution to Attila's integration build dependency > problems, but I feel it is worth mentioning in the context of this thread. > > -TimS > > -- > Tim Stewart > tim@REDACTED > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vinoski@REDACTED Sat Feb 1 20:37:32 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Sat, 1 Feb 2014 14:37:32 -0500 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: Message-ID: On Sat, Feb 1, 2014 at 12:33 PM, Daniel Goertzen wrote: > Thank you for all the details. I think I have a handle on how dirty > schedulers work now. > > You mentioned that you are working on non-SMP support for dirty schedules. > I note that enif_send() currently requires SMP when used from a non-NIF > calling thread; would that requirement also be dropped by your work or is > that a completely separate area of code? > Good question -- I haven't looked into that at all, but I can discuss it with Rickard (or maybe if he sees this he can just answer here). I would guess this specific restriction won't be lifted, but I think using enif_send from a dirty scheduler thread shouldn't be a problem. Looking at the enif_send code just now, I suspect it won't work if you try using it from an RC1 dirty scheduler thread. I'll put that on the list for RC2. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam@REDACTED Sat Feb 1 17:44:24 2014 From: adam@REDACTED (Adam Bloomston) Date: Sat, 1 Feb 2014 11:44:24 -0500 Subject: [erlang-questions] R16B03-1 + Redhat with latest openssl RPMs = EC crypto issues still occurring Message-ID: Hello All, Erlang/OTP latest release (R16B03-1) is still having issues with crypto on Redhat based installs using the latest SSL packages. Setup: * Amazon EC2 instance; AMI: RHEL-6.4_GA-x86_64-10-Hourly2 (ami-a25415cb) * All packages first upgraded via "sudo yum upgrade -y" * Pre-requisities installed via: "sudo yum install -y gcc gcc-c++ make autoconf libxslt fop ncurses-devel openssl-devel *openjdk-devel unixODBC unixODBC-devel" * openssl-devel-1.0.1e-16.el6_5.4.x86_64 * Installing Erlang/OTP R16B03-1 from source using http://www.erlang.org/download/otp_src_R16B03-1.tar.gz Installation of Erlang/OTP R16B03-1 with latest RHEL packages above still produces an error for crypto package: --------------------------- $ ./configure && make && sudo make install [...] $ erl Erlang R16B03-1 (erts-5.10.4) [source] [64-bit] [async-threads:10] [hipe] [kernel-poll:false] Eshell V5.10.4 (abort with ^G) 1> m(crypto). ** exception error: undefined function crypto:module_info/0 in function c:m/1 (c.erl, line 503) 2> =ERROR REPORT==== 1-Feb-2014::08:46:05 === Unable to load crypto library. Failed with error: "load_failed, Failed to load NIF library: '/usr/local/lib/erlang/lib/crypto-3.2/priv/lib/crypto.so: undefined symbol: EC_GROUP_new_curve_GF2m'" OpenSSL might not be installed on this system. =ERROR REPORT==== 1-Feb-2014::08:46:05 === The on_load function for module crypto returned {error, {load_failed, "Failed to load NIF library: '/usr/local/lib/erlang/lib/crypto-3.2/priv/lib/crypto.so: undefined symbol: EC_GROUP_new_curve_GF2m'"}} --------------------------- Installation with argument CFLAGS="-DOPENSSL_NO_EC=1" passed to configure in order to disable EC solves this issue: --------------------------- $ ./configure CFLAGS="-DOPENSSL_NO_EC=1" && make && sudo make install $ erl Erlang R16B03-1 (erts-5.10.4) [source] [64-bit] [async-threads:10] [hipe] [kernel-poll:false] Eshell V5.10.4 (abort with ^G) 1> m(crypto). Module crypto compiled: Date: January 23 2014, Time: 17.03 Compiler options: [{d,'CRYPTO_VSN',"3.2"}, {outdir,"/net/isildur/ldisk/daily_build/r16b03-1_prebuild_opu_o.2014-01-23_17/otp_src_R16B03-1/lib/crypto/src/../ebin"}, warnings_as_errors,warn_obsolete_guard,debug_info] Object file: /usr/local/lib/erlang/lib/crypto-3.2/ebin/crypto.beam Exports: [...] --------------------------- Note that installation with environment variable set prior to calling configure does not work (took me a while to figure this out since I'm not that familiar with configure/make): --------------------------- $ CFLAGS="-DOPENSSL_NO_EC=1"; ./configure && make && sudo make install [...] $ erl Erlang R16B03-1 (erts-5.10.4) [source] [64-bit] [async-threads:10] [hipe] [kernel-poll:false] Eshell V5.10.4 (abort with ^G) 1> m(crypto). ** exception error: undefined function crypto:module_info/0 in function c:m/1 (c.erl, line 503) 2> =ERROR REPORT==== 1-Feb-2014::11:40:33 === Unable to load crypto library. Failed with error: "load_failed, Failed to load NIF library: '/usr/local/lib/erlang/lib/crypto-3.2/priv/lib/crypto.so: undefined symbol: EC_GROUP_new_curve_GF2m'" OpenSSL might not be installed on this system. =ERROR REPORT==== 1-Feb-2014::11:40:33 === The on_load function for module crypto returned {error, {load_failed, "Failed to load NIF library: '/usr/local/lib/erlang/lib/crypto-3.2/priv/lib/crypto.so: undefined symbol: EC_GROUP_new_curve_GF2m'"}} --------------------------- Any questions, please let me know. If you would like me to provide more verbose logs I can easily rerun steps above. Best, Adam Sources: * http://imperialwicket.com/aws-install-erlang-otp-on-amazon-linux * http://docs.basho.com/riak/latest/ops/building/installing/erlang/#Installing-on-GNU-Linux * https://github.com/RoadRunnr/otp/blob/master/HOWTO/INSTALL.md#How-to-Build-and-Install-ErlangOTP_Prebuilt-Source-Release * https://groups.google.com/forum/#!topic/erlang-programming/wW6Uuz4VO2w -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.nijhof@REDACTED Sat Feb 1 18:30:18 2014 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Sat, 1 Feb 2014 18:30:18 +0100 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: Message-ID: Hi Joe (and the rest of the list), Ok right up front, I'm not a Guru, I have only been working with Erlang for about 7 happy months :-) I have a question about the "Records are dead - long live maps" statement you make in your post. One of the nice things I like about records is is that they are a "typed" collection of key->value pairs. When I pass a record around I can look up the definition and know what I can and cannot do with it, and also see what a function expects. Also pattern matching purely on the record type is a great initial filter. When I look at maps they look more like a proplist replacement, something that is just as flexible (more so I guess) but with better usage? So the question really is, how do you see maps replacing records? Would we add a map_type property to the map to distinguish between different maps? Or purely on it's data structure it self? If this is a silly question then I am happy to read about it in one of your awesome rants. -Mark On Sat, Feb 1, 2014 at 5:34 PM, Joe Armstrong wrote: > > > > On Fri, Jan 31, 2014 at 10:51 PM, Kenneth Lundin > wrote: > >> Erlang/OTP 17.0-rc1 has been released. >> > > Fantastic - great - this is a major change to Erlang. > > I've written an article that documents the biggest changes. > > Big changes to Erlang > http://joearms.github.com/2014/02/01/big-changes-to-erlang.html > > Cheers > > /Joe > > > >> This is an alpha release, which will be followed by a planned beta >> release about a month later and a final >> OTP 17.0 product release in the end of March 26, 2014. >> Between the alpha and beta and final release there will be new updates of >> the master branch with corrections >> and minor new features. Occasionally there might be new tags which we in >> that >> case will communicate and ask you to test. >> >> Erlang/OTP 17.0 is a new major release with new features, quite a few >> (characteristics) improvements, >> as well as some incompatibilities. See the README file and the >> documentation for more details. >> >> We would like to ask you to download and test the alpha release and send >> us your feedback as soon as possible, >> so that we can make the necessary corrections before OTP 17.0-rc2 and OTP >> 17.0, respectively. >> The release contains many changes; thus, some unexpected >> incompatibilities or issues may have slipped through >> our tests. Please try to build and run your current products/applications >> and let us know about any problems. >> >> Note! The new datatype MAP is not properly documented yet but the EEP 43 >> http://www.erlang.org/eeps/eep-0043.html >> will provide a good start. Also note that it is a limited implementation >> of maps implemented so far: >> >> - no variable keys are allowed >> - native code can not be generated for modules using maps >> >> Some other highlights of the release are: >> >> - Maps, a new dictionary data type (experimental) >> - A more natural mapping from ASN.1 OCTET STRING and BIT STRING to >> Erlang types, >> and other ASN.1 improvements and optimizations >> - The {active, N} socket option for TCP, UDP, and SCTP >> - A new (optional) scheduler utilization balancing mechanism >> - Migration of memory carriers has been enabled by default on all >> ERTS internal >> memory allocators >> - Increased garbage collection tenure rate >> - Experimental "dirty schedulers" functionality >> - Funs can now be given names >> - Miscellaneous unicode support enhancements >> - A new, semantic version scheme for OTP and its applications >> >> You can find the README file with more detailed info at >> >> http://www.erlang.org/download/otp_src_17.0-rc1.readme >> >> You can download the full source distribution from >> >> http://www.erlang.org/download/otp_src_17.0-rc1.tar.gz >> http://www.erlang.org/download/otp_src_17.0-rc1.readme (this file) >> >> Note: To unpack the TAR archive you need a GNU TAR compatible program. >> >> For installation instructions please read the README that is part of the >> distribution. >> >> You can also find this release at the official Erlang/OTP Git-repository >> at Github here: >> >> https://github.com/erlang/otp tagged *OTP_17.0-rc1* >> >> >> The Windows binary distribution can be downloaded from >> >> http://www.erlang.org/download/otp_win32_17.0-rc1.exe >> http://www.erlang.org/download/otp_win64_17.0-rc1.exe >> >> >> On-line documentation can be found at http://www.erlang.org/doc/. >> You can also download the complete HTML documentation or the Unix manual >> files >> >> http://www.erlang.org/download/otp_doc_html_17.0-rc1.tar.gz >> http://www.erlang.org/download/otp_doc_man_17.0-rc1.tar.gz >> >> We also want to thank those that sent us patches, suggestions and bug >> reports. >> >> The Erlang/OTP Team at Ericsson >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Mark Nijhof t: @MarkNijhof s: marknijhof -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Sat Feb 1 21:14:13 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Sat, 1 Feb 2014 15:14:13 -0500 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: Message-ID: <20140201201412.GA48745@ferdmbp.local> I agree here. I do not see maps replacing records. I do not want to see them replacing records either. Maps should be a replacement of data structures like dicts and gb_trees, in my opinion, but I still prefer records within a module module, where I feel their restrictiveness is welcome, for two main reasons: 1. crash early in live code upgrades, despite, I'm sure, a lot of people disagreeing with me. A badly planned upgrade should die rather than leading to corrupted state. If you're crashing in your record conversion, be thankful you're not running with bad state introducing subtle bugs (and shameful of not having planned your upgrade better, in a way!) 2. The module isolation inherent to records makes people think at a protocol level and with their API much, much better than the common pattern of saying "screw it", sharing the state around, and breaking abstraction all over. I like how it constrains the programmer to think of what should be passed around in messages, and that maps may remove that "think hard" part of the problem. APIs are hard, and the restrictions record bring forth are welcome to me. Maps should be especially nice and enable more complex dictionary manipulations, nested key/val mapping, and so on, and in terseness of operations. More elegantly, they could be a decent fix to 'use ETS to optimize K/V operations', although they won't benefit from the same parallel access. I plan to explain this and possibly revisit some code snippets from the Learn You Some Erlang site in an add-on chapter, and also show what I wouldn't change. Regards, Fred. On 02/01, Mark Nijhof wrote: > Hi Joe (and the rest of the list), > > Ok right up front, I'm not a Guru, I have only been working with Erlang for > about 7 happy months :-) > > I have a question about the "Records are dead - long live maps" statement > you make in your post. One of the nice things I like about records is is > that they are a "typed" collection of key->value pairs. When I pass a > record around I can look up the definition and know what I can and cannot > do with it, and also see what a function expects. Also pattern matching > purely on the record type is a great initial filter. When I look at maps > they look more like a proplist replacement, something that is just as > flexible (more so I guess) but with better usage? > > So the question really is, how do you see maps replacing records? Would we > add a map_type property to the map to distinguish between different maps? > Or purely on it's data structure it self? > > If this is a silly question then I am happy to read about it in one of your > awesome rants. > > -Mark From max.lapshin@REDACTED Sat Feb 1 21:29:56 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Sun, 2 Feb 2014 00:29:56 +0400 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <20140201201412.GA48745@ferdmbp.local> References: <20140201201412.GA48745@ferdmbp.local> Message-ID: Fred, your ideas are right, of course, but you forget that right now records doesn't have any infrastructure for code upgrade. The only way is to make {state, Field1, Field2, ....} mapping by hands. -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sat Feb 1 21:37:45 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 1 Feb 2014 21:37:45 +0100 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: <20140201201412.GA48745@ferdmbp.local> Message-ID: <1205C54E-23DF-4CEF-BCE6-972E8C9AB890@gmail.com> Nothing forbid you from using a new record altogether, with a different name. -- Anthony Ramine Le 1 f?vr. 2014 ? 21:29, Max Lapshin a ?crit : > The only way is to make {state, Field1, Field2, ....} mapping by hands. > From mononcqc@REDACTED Sat Feb 1 21:38:44 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Sat, 1 Feb 2014 15:38:44 -0500 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: <20140201201412.GA48745@ferdmbp.local> Message-ID: <20140201203843.GB48745@ferdmbp.local> I'm aware of that, yes. I tend to do it in one of a few ways: 1. Always add new fields to the end of the record to ensure not conflating fields in existence. Use element(#record.field, Record) to access existing fields of the old one, and list_to_tuple/tuple_to_list to add the new elements at the end. 2. Do it explicitly by opening everything up. It's easy to do with something as crappy as a copy/paste, then modifying the entries. It sucks, but it's explicit, not risky, and doesn't break DRY principles. It's the one you mentioned. 3. Be lucky and make it possible to just restart the process in the first place. Ultimately, I prefer something that crashes loudly on failed updates than not. I tend to change the internal state of production code rarely enough to prefer the benefits of records most of the time with the update weirdness happening once in a long while. Different developers are of course allowed to feel differently about the issue! Regards, Fred. On 02/02, Max Lapshin wrote: > Fred, your ideas are right, of course, but you forget that right now > records doesn't have any infrastructure for code upgrade. > > The only way is to make {state, Field1, Field2, ....} mapping by hands. From klaus_trainer@REDACTED Sat Feb 1 21:46:44 2014 From: klaus_trainer@REDACTED (Klaus Trainer) Date: Sat, 01 Feb 2014 21:46:44 +0100 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: <20140201201412.GA48745@ferdmbp.local> Message-ID: <52ED5D34.3000208@posteo.de> > Fred, your ideas are right, of course, but you forget that right now > records doesn't have any infrastructure for code upgrade. Of course there are mechanisms that help you upgrading your records. For instance, in OTP you have the `Module:code_change/3` gen_server callback, where you can conveniently change record definitions. Regarding sharing records e.g. in a multi-node setup, see the second point Fred made about API design previously. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From tristan.sloughter@REDACTED Sat Feb 1 21:53:41 2014 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Sat, 01 Feb 2014 12:53:41 -0800 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <20140201201412.GA48745@ferdmbp.local> References: <20140201201412.GA48745@ferdmbp.local> Message-ID: <1391288021.12937.78129741.0FD3BB73@webmail.messagingengine.com> +10000 I find the idea of maps replacing records very confusing. The compile time static nature of records is very useful, even if it doesn't pertain to every situation you want a random access key/value data structure. A record as Fred mentions makes you think about the type and the API from the module more. And will you be able to define types on keys with maps for static analysis like with records? Tristna On Sat, Feb 1, 2014, at 12:14 PM, Fred Hebert wrote: > I agree here. I do not see maps replacing records. I do not want to see > them replacing records either. > > Maps should be a replacement of data structures like dicts and gb_trees, > in my opinion, but I still prefer records within a module module, where > I feel their restrictiveness is welcome, for two main reasons: > > 1. crash early in live code upgrades, despite, I'm sure, a > lot of people disagreeing with me. > > A badly planned upgrade should die rather than leading to corrupted > state. If you're crashing in your record conversion, be thankful > you're not running with bad state introducing subtle bugs (and > shameful of not having planned your upgrade better, in a way!) > > 2. The module isolation inherent to records makes people think at a > protocol level and with their API much, much better than the common > pattern of saying "screw it", sharing the state around, and breaking > abstraction all over. I like how it constrains the programmer to think > of what should be passed around in messages, and that maps may remove > that "think hard" part of the problem. > > APIs are hard, and the restrictions record bring forth are welcome to > me. > > Maps should be especially nice and enable more complex dictionary > manipulations, nested key/val mapping, and so on, and in terseness of > operations. More elegantly, they could be a decent fix to 'use ETS to > optimize K/V operations', although they won't benefit from the same > parallel access. > > I plan to explain this and possibly revisit some code snippets from the > Learn You Some Erlang site in an add-on chapter, and also show what I > wouldn't change. > > Regards, > Fred. > > On 02/01, Mark Nijhof wrote: > > Hi Joe (and the rest of the list), > > > > Ok right up front, I'm not a Guru, I have only been working with Erlang for > > about 7 happy months :-) > > > > I have a question about the "Records are dead - long live maps" statement > > you make in your post. One of the nice things I like about records is is > > that they are a "typed" collection of key->value pairs. When I pass a > > record around I can look up the definition and know what I can and cannot > > do with it, and also see what a function expects. Also pattern matching > > purely on the record type is a great initial filter. When I look at maps > > they look more like a proplist replacement, something that is just as > > flexible (more so I guess) but with better usage? > > > > So the question really is, how do you see maps replacing records? Would we > > add a map_type property to the map to distinguish between different maps? > > Or purely on it's data structure it self? > > > > If this is a silly question then I am happy to read about it in one of your > > awesome rants. > > > > -Mark > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Tristan Sloughter tristan.sloughter@REDACTED From essen@REDACTED Sat Feb 1 22:08:59 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 01 Feb 2014 22:08:59 +0100 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: Message-ID: <52ED626B.6040005@ninenines.eu> I think for most users and most use cases maps will completely take over records. Reason 1: Records today are already only usable inside a single module. Records need to be defined. This means that if you want your record to be available across more than one module you need to either duplicate the definition or put it in an include file. But doing this means that you're leaking out the record definition all across your application, which makes changing said definition harder (and code upgrades almost impossible to get right). A good practice deriving from that is to make sure records never leave one module, or at the very least that they never get accessed from outside that module (using -opaque). That makes records workable, but limits their usefulness. Reason 2: Upgrading a process state that uses records is terrifying. Well here's a good explanation of why it's terrifying and sucks horribly: http://erlang.org/pipermail/erlang-questions/2014-February/076765.html For maps at worst you just do M#{ new_field => default_value } and are done with it. Reason 3: Records are cumbersome to use. Many hate the record syntax. Many also would prefer to avoid the record definition entirely when prototyping some code. And they should! Maps aren't slowing down your work the way records do. And guess what. Most of the time the prototype of an Erlang process is good enough for production use. You lose Dialyzer. That's the big drawback. But most processes' state is smallish so mistakes are hard to make and quickly found anyway. Some will also argue that records are FAST and maps aren't. But for most processes it doesn't matter. And I will even go as far as saying that this isn't necessarily true. Records allocate fully at creation, maps only when needed. You can easily only set keys that are different from the defaults in the map, keep it small and potentially beating records entirely. These are the three main reasons I think maps will take over. Personally I will probably still use records for most processes' state because I like Dialyzer, might consider using records where speed is a huge requirement (after careful measurements) but anywhere else? Maps. Maps all the way, baby. Maps will also completely beat proplists to death, burn their brackets and eat their hearts. I don't think I need to explain why. Seeing maps used in place of records will probably not make everyone happy. Oh well. They might even say you're WRONG (madness!) to use them in this or that scenario, and insistently ask WHY you are doing something so CRAZY. But you know. Whatever works. On 02/01/2014 06:30 PM, Mark Nijhof wrote: > Hi Joe (and the rest of the list), > > Ok right up front, I'm not a Guru, I have only been working with Erlang > for about 7 happy months :-) > > I have a question about the "Records are dead - long live maps" > statement you make in your post. One of the nice things I like about > records is is that they are a "typed" collection of key->value pairs. > When I pass a record around I can look up the definition and know what I > can and cannot do with it, and also see what a function expects. Also > pattern matching purely on the record type is a great initial filter. > When I look at maps they look more like a proplist replacement, > something that is just as flexible (more so I guess) but with better usage? > > So the question really is, how do you see maps replacing records? Would > we add a map_type property to the map to distinguish between different > maps? Or purely on it's data structure it self? > > If this is a silly question then I am happy to read about it in one of > your awesome rants. > > -Mark > > > > > On Sat, Feb 1, 2014 at 5:34 PM, Joe Armstrong > wrote: > > > > > On Fri, Jan 31, 2014 at 10:51 PM, Kenneth Lundin > > wrote: > > Erlang/OTP 17.0-rc1 has been released. > > > Fantastic - great - this is a major change to Erlang. > > I've written an article that documents the biggest changes. > > Big changes to Erlang > http://joearms.github.com/2014/02/01/big-changes-to-erlang.html > > Cheers > > /Joe > > This is an alpha release, which will be followed by a planned > beta release about a month later and a final > OTP 17.0 product release in the end of March 26, 2014. > Between the alpha and beta and final release there will be new > updates of the master branch with corrections > and minor new features. Occasionally there might be new tags > which we in that > case will communicate and ask you to test. > > Erlang/OTP 17.0 is a new major release with new features, quite > a few (characteristics) improvements, > as well as some incompatibilities. See the README file and the > documentation for more details. > > We would like to ask you to download and test the alpha release > and send us your feedback as soon as possible, > so that we can make the necessary corrections before OTP > 17.0-rc2 and OTP 17.0, respectively. > The release contains many changes; thus, some unexpected > incompatibilities or issues may have slipped through > our tests. Please try to build and run your current > products/applications and let us know about any problems. > > Note! The new datatype MAP is not properly documented yet but > the EEP 43 http://www.erlang.org/eeps/eep-0043.html > will provide a good start. Also note that it is a limited > implementation of maps implemented so far: > > - no variable keys are allowed > - native code can not be generated for modules using maps > > Some other highlights of the release are: > > - Maps, a new dictionary data type (experimental) > - A more natural mapping from ASN.1 OCTET STRING and BIT > STRING to Erlang types, > and other ASN.1 improvements and optimizations > - The {active, N} socket option for TCP, UDP, and SCTP > - A new (optional) scheduler utilization balancing mechanism > - Migration of memory carriers has been enabled by default > on all ERTS internal > memory allocators > - Increased garbage collection tenure rate > - Experimental "dirty schedulers" functionality > - Funs can now be given names > - Miscellaneous unicode support enhancements > - A new, semantic version scheme for OTP and its applications > > You can find the README file with more detailed info at > > http://www.erlang.org/download/otp_src_17.0-rc1.readme > > You can download the full source distribution from > > http://www.erlang.org/download/otp_src_17.0-rc1.tar.gz > http://www.erlang.org/download/otp_src_17.0-rc1.readme (this file) > > Note: To unpack the TAR archive you need a GNU TAR compatible > program. > > For installation instructions please read the README that is > part of the distribution. > > You can also find this release at the official Erlang/OTP > Git-repository at Github here: > > https://github.com/erlang/otp tagged *OTP_17.0-rc1* > > > The Windows binary distribution can be downloaded from > > http://www.erlang.org/download/otp_win32_17.0-rc1.exe > http://www.erlang.org/download/otp_win64_17.0-rc1.exe > > > On-line documentation can be found at http://www.erlang.org/doc/. > You can also download the complete HTML documentation or the > Unix manual files > > http://www.erlang.org/download/otp_doc_html_17.0-rc1.tar.gz > http://www.erlang.org/download/otp_doc_man_17.0-rc1.tar.gz > > We also want to thank those that sent us patches, suggestions > and bug reports. > > The Erlang/OTP Team at Ericsson > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > Mark Nijhof > t: @MarkNijhof > s: marknijhof > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From essen@REDACTED Sat Feb 1 22:16:02 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 01 Feb 2014 22:16:02 +0100 Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: References: <52ED37FC.8040703@stoo.org> Message-ID: <52ED6412.9000600@ninenines.eu> On 02/01/2014 08:11 PM, Garrett Smith wrote: > As an aside, I think this particular email thread, which I came > across, should be printed without editing as a pamphlet and handed out > at user groups and software conferences as a treatise on core > principles of language and tool design and civil discourse. If others > are willing to join me, I would consider shaving my head and wearing > brightly colors robes and do this. I probably don't have to tell you that you can count me in. :) -- Lo?c Hoguin http://ninenines.eu From baliulia@REDACTED Sat Feb 1 22:19:36 2014 From: baliulia@REDACTED (=?UTF-8?B?SWduYXMgVnnFoW5pYXVza2Fz?=) Date: Sat, 01 Feb 2014 22:19:36 +0100 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <20140201201412.GA48745@ferdmbp.local> References: <20140201201412.GA48745@ferdmbp.local> Message-ID: <52ED64E8.3080905@gmail.com> The main problem I see with records is that it is impossible to use pretty much any generic functions on them, hence you either get massive code duplication or lots of parse-transforms. Trivial things such as converting a record to a dict or filtering out a field can only be achieved via parse-transforms, which is ridiculous. What good is a data structure if it can't be handled easily? Also, how readable are your logs when there's a record involved? "Foo crashed when state was {state, foo, bar, undefined, undefined, 1, 2, undefined}" is not very helpful usually. [And, yes, I know you can workaround all of this.] IMHO the trivial static guarantee of "yep, that field exists" (which is all that you get without Dialyzer) is not worth the pain induced by everything else. -- Ignas From jose.valim@REDACTED Sat Feb 1 22:20:34 2014 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Sat, 1 Feb 2014 22:20:34 +0100 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <1391288021.12937.78129741.0FD3BB73@webmail.messagingengine.com> References: <20140201201412.GA48745@ferdmbp.local> <1391288021.12937.78129741.0FD3BB73@webmail.messagingengine.com> Message-ID: I don't think maps are meant to replace *all* use case of records. Maps are meant to replace *bad* use case of records. Before maps if you simply wanted to load data from a database you didn't really have a suitable option. Tuples are unsuitable for anything with more than a couple fields, records are too rigid/verbose, dicts don't allow pattern matching and so on. Many of those use cases ended-up using records and that generated friction. With maps we have a better structure to address those cases and hopefully people will complain less about records... exactly because their rigidness will now be treated as a feature rather than a dread. An example is the file:read_file_info/1 function. It would be much better returning a map than a record that you have to import. Note that I am not saying this change should happen, it is just an example. I think Robert once said "if you want to share records, sit down until the feeling passes". Maybe now it can be changed to "sit down and write it as a map". $0.02 poorer, *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer On Sat, Feb 1, 2014 at 9:53 PM, Tristan Sloughter < tristan.sloughter@REDACTED> wrote: > +10000 > > I find the idea of maps replacing records very confusing. The compile > time static nature of records is very useful, even if it doesn't pertain > to every situation you want a random access key/value data structure. > > A record as Fred mentions makes you think about the type and the API > from the module more. > > And will you be able to define types on keys with maps for static > analysis like with records? > > Tristna > > On Sat, Feb 1, 2014, at 12:14 PM, Fred Hebert wrote: > > I agree here. I do not see maps replacing records. I do not want to see > > them replacing records either. > > > > Maps should be a replacement of data structures like dicts and gb_trees, > > in my opinion, but I still prefer records within a module module, where > > I feel their restrictiveness is welcome, for two main reasons: > > > > 1. crash early in live code upgrades, despite, I'm sure, a > > lot of people disagreeing with me. > > > > A badly planned upgrade should die rather than leading to corrupted > > state. If you're crashing in your record conversion, be thankful > > you're not running with bad state introducing subtle bugs (and > > shameful of not having planned your upgrade better, in a way!) > > > > 2. The module isolation inherent to records makes people think at a > > protocol level and with their API much, much better than the common > > pattern of saying "screw it", sharing the state around, and breaking > > abstraction all over. I like how it constrains the programmer to think > > of what should be passed around in messages, and that maps may remove > > that "think hard" part of the problem. > > > > APIs are hard, and the restrictions record bring forth are welcome to > > me. > > > > Maps should be especially nice and enable more complex dictionary > > manipulations, nested key/val mapping, and so on, and in terseness of > > operations. More elegantly, they could be a decent fix to 'use ETS to > > optimize K/V operations', although they won't benefit from the same > > parallel access. > > > > I plan to explain this and possibly revisit some code snippets from the > > Learn You Some Erlang site in an add-on chapter, and also show what I > > wouldn't change. > > > > Regards, > > Fred. > > > > On 02/01, Mark Nijhof wrote: > > > Hi Joe (and the rest of the list), > > > > > > Ok right up front, I'm not a Guru, I have only been working with > Erlang for > > > about 7 happy months :-) > > > > > > I have a question about the "Records are dead - long live maps" > statement > > > you make in your post. One of the nice things I like about records is > is > > > that they are a "typed" collection of key->value pairs. When I pass a > > > record around I can look up the definition and know what I can and > cannot > > > do with it, and also see what a function expects. Also pattern matching > > > purely on the record type is a great initial filter. When I look at > maps > > > they look more like a proplist replacement, something that is just as > > > flexible (more so I guess) but with better usage? > > > > > > So the question really is, how do you see maps replacing records? > Would we > > > add a map_type property to the map to distinguish between different > maps? > > > Or purely on it's data structure it self? > > > > > > If this is a silly question then I am happy to read about it in one of > your > > > awesome rants. > > > > > > -Mark > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > -- > Tristan Sloughter > tristan.sloughter@REDACTED > _______________________________________________ > 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 Feb 1 22:23:30 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 01 Feb 2014 22:23:30 +0100 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: <20140201201412.GA48745@ferdmbp.local> <1391288021.12937.78129741.0FD3BB73@webmail.messagingengine.com> Message-ID: <52ED65D2.8080907@ninenines.eu> On 02/01/2014 10:20 PM, Jos? Valim wrote: > An example is the file:read_file_info/1 function. It would be much > better returning a map than a record that you have to import. Note that > I am not saying this change should happen, it is just an example. Can always make a file:read_info/1 function. There was file:file_info/1 before, this wouldn't be the first time. :) -- Lo?c Hoguin http://ninenines.eu From wallentin.dahlberg@REDACTED Sat Feb 1 22:49:59 2014 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Sat, 1 Feb 2014 22:49:59 +0100 Subject: [erlang-questions] [erlang-bugs] Potential bug in OTP_17.0-rc1 when converting map to binary and back In-Reply-To: <52ED3EF3.9070802@cs.ntua.gr> References: <52ED3EF3.9070802@cs.ntua.gr> Message-ID: Woho! Good catch with proper! Have I run proper on Maps? - Nope. Should I have done it - properly. =) I wrote the Maps code for external format encoding/decoding before the big rewrite of trappable binary_to_term - term_to_binary. We had some clashes when merging and it is entirely possible that we messed things up. It is also entirely possible I messed up well before the merge. I'll have a look at it. Thanks for reporting! // Bj?rn-Egil 2014-02-01 Kostis Sagonas : > On 02/01/2014 06:41 PM, Gustav Simonsson wrote: > >> After the announcement of OTP_17.0-rc1 I compiled the source and started >> playing with maps and proper. >> >> After testing a bunch of stuff like maps:to_list(maps:from_list(List)) I >> replicated a classic proper example to verify >> binary_to_term(term_to_binary(T)). >> > > .... > >> 2> proper:quickcheck(t:prop_maps2(), [{numtests, 10000}]). >> ............ ............................................... >> >> Shrinking .......Segmentation fault (core dumped) >> .... >> >> Please let me know if you need a core and/or more details. >> It should be easy to replicate given the above code though on various >> archs. >> > > > Indeed, this is very easy to replicate. On my first attempt, I got > equally unlucky as Simon and OTP seg faulted when PropEr attempted to > shrink the offending test case. On my second attempt, I had better luck and > shrinking worked: > > > Eshell V6.0 (abort with ^G) > 1> proper:quickcheck(t:prop_maps2(), 10000). > ...... ..... > Failed: After 2090 test(s). > {[{{{},'m?\030??',[],[[]],[]},{'\031?DZ',75.25615709172015, > 9}},{{<<47,42,83,2:2>>},[{11.611456128457124,{[]},[],-7. > 568651682554733}]},{'?\204H?????',[[],[],[],-10,80,{},[]]},{ > {'?\211l\030x\220?\224?'},[-14.081931069838275,1,['\236J?' > ,0],3,3.8086424574055755]},{{[],[{},[[{}]]],{},{}},{-7.668921456100702,-0. > 8537275447686942,0.2046413634772726,8.71091095449412,'X7??\237\030', > {-11,{{}},-0.95809288292835,[{{}},'?u?']},-5.604771642421137}},{{[{},22. > 021800217282916],-2,7.289863377212738,'?]?\d',10. > 348710823806195},{{[[{},[5.428258856857506],[],'O\030:',- > 2]],22.20548610862955,102}}},{[1.730805378918121,'\201\226o\032',-5,-4,0. > 21576771814263207],<<145,249,4,86,26,4:3>>}]} > > Shrinking ...................(19 time(s)) > {[{{{},'m?\030??',[],[[]],[]},{'\031?DZ',75.25615709172015, > 9}},{{<<47,42,83,2:2>>},[{11.611456128457124,{[]},[],-7. > 568651682554733}]},{'\037\204H?>w6?',[[],[],[],-8,80,{}, > []]},{{'?\211l\030x\220?\224?'},[-14.081931069838275,1,['z\ > 003-',0],3,3.8086424574055755]},{'\v?6\002',{-7.668921456100702,-0. > 8537275447686942,0.2046413634772726,8.71091095449412,'X7??\237\030', > {-11,{{}},-0.95809288292835,[{{}},'?u?']},-5.604771642421137}},{{[{},22. > 021800217282916],-2,7.289863377212738,'?]?\d',10. > 348710823806195},{{[[{},[5.428258856857506],[],'O\030:',- > 2]],22.20548610862955,102}}},{[1.730805378918121,'\030\023%\020',-5,-4,0. > 21576771814263207],<<145,249,4,49,26,4:3>>}]} > false > > false > > > PropEr can be obtained from: http://proper.softlab.ntua.gr/ > > Kostis > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Sat Feb 1 23:23:02 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Sat, 1 Feb 2014 23:23:02 +0100 Subject: [erlang-questions] 0MQ libraries In-Reply-To: References: <2029482514.52715.1391158061241.JavaMail.zimbra@tpip.net> Message-ID: Like Erik writes, you don't know how what you lost. At best you can try to mitigate it. It is definitely one of the things I would ask Pieter about how he solves in C/C++. On Fri, Jan 31, 2014 at 6:05 PM, Garrett Smith wrote: > On Fri, Jan 31, 2014 at 2:47 AM, Andreas Schultz > wrote: > > Hi, > > > > ----- Original Message ----- > >> Yes - Google didn't suggest this. > >> > >> Did anybody do any performance measurements on this? > > > > Not yet, didn't have time for it :-( > > I don't know if this is helpful or not to the question of > benchmarking, but I've created a very simple behavior to compare > erlang-czmq with erlzmq: > > https://github.com/gar1t/erlang-czmq/blob/master/src/zmq_gen_benchmark.erl > > There are two flavors of this - one for each library being benchmarked: > > https://github.com/gar1t/erlang-czmq/blob/master/src/erlzmq_benchmark.erl > > https://github.com/gar1t/erlang-czmq/blob/master/src/czmq_benchmark.erl > > In your Berlin workshop (tempted to travel for this :), if this topic > comes up, maybe this could be helpful to run some quick tests. I'm > very happy to help with this in any way! > > Garrett > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rvg.mailing@REDACTED Sat Feb 1 23:58:51 2014 From: rvg.mailing@REDACTED (Rudolph van Graan) Date: Sat, 01 Feb 2014 22:58:51 +0000 (GMT) Subject: [erlang-questions] R17 with Mac Ports and OS X 10.9 Message-ID: <431e6a0b-2850-4fe8-913b-313d7265882f@me.com> Hi, Here is a hacked Portfile for R17 that helped me get the new version running. Hope it helps someone. I commented the sections that installs the documentation, so if someone wants to help with that bit :) R -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile.r17rc01 Type: application/octet-stream Size: 7463 bytes Desc: not available URL: From rvg.mailing@REDACTED Sun Feb 2 00:00:24 2014 From: rvg.mailing@REDACTED (Rudolph van Graan) Date: Sat, 01 Feb 2014 23:00:24 +0000 (GMT) Subject: [erlang-questions] R17 maps and accessor syntax Message-ID: <48944134-ab6b-4bc6-9d2e-d72a1ca97b1e@me.com> Hi, EEP43 says: For accessing single values in maps, let us use an de-association: V = M#{ K }. 11> B = #{key1 => 124, key2 => 111, key3 => 444}. #{key1 => 124,key2 => 111,key3 => 444} 12> B#{ key1 }. * 1: syntax error before: ?}' Am I doing something wrong? R -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablo.platt@REDACTED Sun Feb 2 00:10:21 2014 From: pablo.platt@REDACTED (pablo platt) Date: Sun, 2 Feb 2014 01:10:21 +0200 Subject: [erlang-questions] DTLS client/server In-Reply-To: References: <-2812677860635758685@unknownmsgid> Message-ID: I didn't see anything about DTLS in the R17 RC1 release notes. Will this be included in the final R17 release? On Thu, Dec 12, 2013 at 3:17 PM, pablo platt wrote: > Thanks > > > On Thu, Dec 12, 2013 at 2:55 PM, Ingela Andin wrote: > >> >> Hi! >> >> 2013/12/12 pablo platt >> >>> Hi >>> >>> >>> Will it be possible to use DTLS for DTLS-SRTP when it will be released? >>> http://tools.ietf.org/html/rfc5764 >>> >>> >>> DTLS-SRTP requires sending use_srtp in extended hello and exchanging SRTP keys. >>> >>> DTLS-SRTP also requires that RTP and STUN messages are forwarded to the app. >>> >>> >>> Will there be support out of the box for such extension? >>> >>> >> No this will not work out of the box. But once DTLS is in place it could >> be a fairly easy user contribution ;) >> >> >> Regards Ingela Erlang/OTP Team Ericssson AB >> >> >>> >>> On Fri, Oct 18, 2013 at 5:07 AM, pablo platt wrote: >>> >>>> A preview in a few weeks will be great. >>>> >>>> Thanks >>>> >>>> >>>> On Fri, Oct 18, 2013 at 12:12 AM, Ingela Andin wrote: >>>> >>>>> Hi! >>>>> >>>>> >>>>> 2013/10/17 pablo platt >>>>> >>>>>> Is there a chance for release preview of DTLS before the R17 release >>>>>> on February? >>>>>> >>>>>> >>>>> Alas, I still do not have anything releasable that is runnable. I >>>>> have had to work with some other stuff in between. >>>>> But I think previews can be possible. I have a rather large step in >>>>> the pipeline that I probably can release in a few weeks >>>>> as it then can be merged to maint. This step will include some code >>>>> from Andreas that implements basic stuff. But >>>>> the internal structure of the code is quite different and the API is >>>>> not totally set yet. >>>>> >>>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge@REDACTED Sun Feb 2 00:16:06 2014 From: serge@REDACTED (Serge Aleynikov) Date: Sat, 1 Feb 2014 18:16:06 -0500 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: Message-ID: It doesn't look like the new map type is supported in erl_interface (and likely jinterface): 1> M = #{ a => 10, b => 20 }. #{a => 10,b => 20} 2> term_to_binary(M). <<131,116,0,0,0,2,100,0,1,97,100,0,1,98,97,10,97,20>> 3> io:format("~c\n", [116]). t ok $ grep 't' lib/erl_interface/include/* Is this an oversight? Serge On Fri, Jan 31, 2014 at 4:51 PM, Kenneth Lundin wrote: > Erlang/OTP 17.0-rc1 has been released. > > This is an alpha release, which will be followed by a planned beta release > about a month later and a final > OTP 17.0 product release in the end of March 26, 2014. > Between the alpha and beta and final release there will be new updates of > the master branch with corrections > and minor new features. Occasionally there might be new tags which we in > that > case will communicate and ask you to test. > > Erlang/OTP 17.0 is a new major release with new features, quite a few > (characteristics) improvements, > as well as some incompatibilities. See the README file and the > documentation for more details. > > We would like to ask you to download and test the alpha release and send > us your feedback as soon as possible, > so that we can make the necessary corrections before OTP 17.0-rc2 and OTP > 17.0, respectively. > The release contains many changes; thus, some unexpected incompatibilities > or issues may have slipped through > our tests. Please try to build and run your current products/applications > and let us know about any problems. > > Note! The new datatype MAP is not properly documented yet but the EEP 43 > http://www.erlang.org/eeps/eep-0043.html > will provide a good start. Also note that it is a limited implementation > of maps implemented so far: > > - no variable keys are allowed > - native code can not be generated for modules using maps > > Some other highlights of the release are: > > - Maps, a new dictionary data type (experimental) > - A more natural mapping from ASN.1 OCTET STRING and BIT STRING to > Erlang types, > and other ASN.1 improvements and optimizations > - The {active, N} socket option for TCP, UDP, and SCTP > - A new (optional) scheduler utilization balancing mechanism > - Migration of memory carriers has been enabled by default on all ERTS > internal > memory allocators > - Increased garbage collection tenure rate > - Experimental "dirty schedulers" functionality > - Funs can now be given names > - Miscellaneous unicode support enhancements > - A new, semantic version scheme for OTP and its applications > > You can find the README file with more detailed info at > > http://www.erlang.org/download/otp_src_17.0-rc1.readme > > You can download the full source distribution from > > http://www.erlang.org/download/otp_src_17.0-rc1.tar.gz > http://www.erlang.org/download/otp_src_17.0-rc1.readme (this file) > > Note: To unpack the TAR archive you need a GNU TAR compatible program. > > For installation instructions please read the README that is part of the > distribution. > > You can also find this release at the official Erlang/OTP Git-repository > at Github here: > > https://github.com/erlang/otp tagged *OTP_17.0-rc1* > > > The Windows binary distribution can be downloaded from > > http://www.erlang.org/download/otp_win32_17.0-rc1.exe > http://www.erlang.org/download/otp_win64_17.0-rc1.exe > > > On-line documentation can be found at http://www.erlang.org/doc/. > You can also download the complete HTML documentation or the Unix manual > files > > http://www.erlang.org/download/otp_doc_html_17.0-rc1.tar.gz > http://www.erlang.org/download/otp_doc_man_17.0-rc1.tar.gz > > We also want to thank those that sent us patches, suggestions and bug > reports. > > The Erlang/OTP Team at Ericsson > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.nijhof@REDACTED Sat Feb 1 22:21:43 2014 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Sat, 1 Feb 2014 22:21:43 +0100 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <52ED626B.6040005@ninenines.eu> References: <52ED626B.6040005@ninenines.eu> Message-ID: Thanks for the replies so far! Interesting to see that people don't like using records past module boundaries, we extensively use them that way (which might change with the new map feature). In our solution we have a few "data types" that get passed around to different processes to do things, and also we use something like a message bus to have subscribe/unsubscribe functionality for which we use records as messages. For us this works really well, proven by the countless refactorings being done (inside processes but also complete restructuring of how processes are tied together). Now I am not saying you are wrong obviously, but thought it was worth putting this "other" experience in the group as well. -Mark On Sat, Feb 1, 2014 at 10:08 PM, Lo?c Hoguin wrote: > I think for most users and most use cases maps will completely take over > records. > > Reason 1: Records today are already only usable inside a single module. > > Records need to be defined. This means that if you want your record to be > available across more than one module you need to either duplicate the > definition or put it in an include file. But doing this means that you're > leaking out the record definition all across your application, which makes > changing said definition harder (and code upgrades almost impossible to get > right). > > A good practice deriving from that is to make sure records never leave one > module, or at the very least that they never get accessed from outside that > module (using -opaque). That makes records workable, but limits their > usefulness. > > Reason 2: Upgrading a process state that uses records is terrifying. > > Well here's a good explanation of why it's terrifying and sucks horribly: > http://erlang.org/pipermail/erlang-questions/2014-February/076765.html > > For maps at worst you just do M#{ new_field => default_value } and are > done with it. > > Reason 3: Records are cumbersome to use. > > Many hate the record syntax. Many also would prefer to avoid the record > definition entirely when prototyping some code. And they should! Maps > aren't slowing down your work the way records do. And guess what. Most of > the time the prototype of an Erlang process is good enough for production > use. > > You lose Dialyzer. That's the big drawback. But most processes' state is > smallish so mistakes are hard to make and quickly found anyway. > > Some will also argue that records are FAST and maps aren't. But for most > processes it doesn't matter. And I will even go as far as saying that this > isn't necessarily true. Records allocate fully at creation, maps only when > needed. You can easily only set keys that are different from the defaults > in the map, keep it small and potentially beating records entirely. > > > > These are the three main reasons I think maps will take over. Personally I > will probably still use records for most processes' state because I like > Dialyzer, might consider using records where speed is a huge requirement > (after careful measurements) but anywhere else? Maps. Maps all the way, > baby. > > Maps will also completely beat proplists to death, burn their brackets and > eat their hearts. I don't think I need to explain why. > > Seeing maps used in place of records will probably not make everyone > happy. Oh well. They might even say you're WRONG (madness!) to use them in > this or that scenario, and insistently ask WHY you are doing something so > CRAZY. But you know. Whatever works. > > > On 02/01/2014 06:30 PM, Mark Nijhof wrote: > >> Hi Joe (and the rest of the list), >> >> Ok right up front, I'm not a Guru, I have only been working with Erlang >> for about 7 happy months :-) >> >> I have a question about the "Records are dead - long live maps" >> statement you make in your post. One of the nice things I like about >> records is is that they are a "typed" collection of key->value pairs. >> When I pass a record around I can look up the definition and know what I >> can and cannot do with it, and also see what a function expects. Also >> pattern matching purely on the record type is a great initial filter. >> When I look at maps they look more like a proplist replacement, >> something that is just as flexible (more so I guess) but with better >> usage? >> >> So the question really is, how do you see maps replacing records? Would >> we add a map_type property to the map to distinguish between different >> maps? Or purely on it's data structure it self? >> >> If this is a silly question then I am happy to read about it in one of >> your awesome rants. >> >> -Mark >> >> >> >> >> On Sat, Feb 1, 2014 at 5:34 PM, Joe Armstrong > > wrote: >> >> >> >> >> On Fri, Jan 31, 2014 at 10:51 PM, Kenneth Lundin >> > wrote: >> >> Erlang/OTP 17.0-rc1 has been released. >> >> >> Fantastic - great - this is a major change to Erlang. >> >> I've written an article that documents the biggest changes. >> >> Big changes to Erlang >> http://joearms.github.com/2014/02/01/big-changes-to-erlang.html >> >> Cheers >> >> /Joe >> >> This is an alpha release, which will be followed by a planned >> beta release about a month later and a final >> OTP 17.0 product release in the end of March 26, 2014. >> Between the alpha and beta and final release there will be new >> updates of the master branch with corrections >> and minor new features. Occasionally there might be new tags >> which we in that >> case will communicate and ask you to test. >> >> Erlang/OTP 17.0 is a new major release with new features, quite >> a few (characteristics) improvements, >> as well as some incompatibilities. See the README file and the >> documentation for more details. >> >> We would like to ask you to download and test the alpha release >> and send us your feedback as soon as possible, >> so that we can make the necessary corrections before OTP >> 17.0-rc2 and OTP 17.0, respectively. >> The release contains many changes; thus, some unexpected >> incompatibilities or issues may have slipped through >> our tests. Please try to build and run your current >> products/applications and let us know about any problems. >> >> Note! The new datatype MAP is not properly documented yet but >> the EEP 43 http://www.erlang.org/eeps/eep-0043.html >> will provide a good start. Also note that it is a limited >> implementation of maps implemented so far: >> >> - no variable keys are allowed >> - native code can not be generated for modules using maps >> >> Some other highlights of the release are: >> >> - Maps, a new dictionary data type (experimental) >> - A more natural mapping from ASN.1 OCTET STRING and BIT >> STRING to Erlang types, >> and other ASN.1 improvements and optimizations >> - The {active, N} socket option for TCP, UDP, and SCTP >> - A new (optional) scheduler utilization balancing mechanism >> - Migration of memory carriers has been enabled by default >> on all ERTS internal >> memory allocators >> - Increased garbage collection tenure rate >> - Experimental "dirty schedulers" functionality >> - Funs can now be given names >> - Miscellaneous unicode support enhancements >> - A new, semantic version scheme for OTP and its applications >> >> You can find the README file with more detailed info at >> >> http://www.erlang.org/download/otp_src_17.0-rc1.readme >> >> You can download the full source distribution from >> >> http://www.erlang.org/download/otp_src_17.0-rc1.tar.gz >> http://www.erlang.org/download/otp_src_17.0-rc1.readme (this >> file) >> >> Note: To unpack the TAR archive you need a GNU TAR compatible >> program. >> >> For installation instructions please read the README that is >> part of the distribution. >> >> You can also find this release at the official Erlang/OTP >> Git-repository at Github here: >> >> https://github.com/erlang/otp tagged *OTP_17.0-rc1* >> >> >> The Windows binary distribution can be downloaded from >> >> http://www.erlang.org/download/otp_win32_17.0-rc1.exe >> http://www.erlang.org/download/otp_win64_17.0-rc1.exe >> >> >> On-line documentation can be found at http://www.erlang.org/doc/. >> You can also download the complete HTML documentation or the >> Unix manual files >> >> http://www.erlang.org/download/otp_doc_html_17.0-rc1.tar.gz >> http://www.erlang.org/download/otp_doc_man_17.0-rc1.tar.gz >> >> We also want to thank those that sent us patches, suggestions >> and bug reports. >> >> The Erlang/OTP Team at Ericsson >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> >> -- >> Mark Nijhof >> t: @MarkNijhof >> s: marknijhof >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- > Lo?c Hoguin > http://ninenines.eu > -- Mark Nijhof t: @MarkNijhof s: marknijhof -------------- next part -------------- An HTML attachment was scrubbed... URL: From ph@REDACTED Sun Feb 2 00:24:26 2014 From: ph@REDACTED (Pieter Hintjens) Date: Sun, 2 Feb 2014 00:24:26 +0100 Subject: [erlang-questions] CZMQ licensing In-Reply-To: References: Message-ID: Nice! On Sat, Feb 1, 2014 at 5:38 PM, Aleksandar Radulovic wrote: > Hey Pieter, > > On Fri, Jan 31, 2014 at 12:55 PM, Pieter Hintjens wrote: >> >> Ps. native Erlang ZMTP would be fantastic. We've done this in Java and >> .NET, and it's been very positive for those communities. > > > I've implemented [1] a native ZMTP protocol in Erlang. It currently supports > 13/ZMTP and 15/ZMTP and I've been thinking of implementing 20/ZMTP sometime > soon. > > It was implemented (only) for laughs and to prove to some people at work how > easy it would be to do it in Erlang. > > [1] https://github.com/a13x/ezmtp > > Cheers, > alex > -- > a lex 13 x > http://a13x.net | @a13xnet From ph@REDACTED Sun Feb 2 00:29:23 2014 From: ph@REDACTED (Pieter Hintjens) Date: Sun, 2 Feb 2014 00:29:23 +0100 Subject: [erlang-questions] 0MQ libraries In-Reply-To: References: <2029482514.52715.1391158061241.JavaMail.zimbra@tpip.net> Message-ID: Yes, if there is a connection break, there can be lost data (as far as I'm aware). If applications need guarantees of delivery in such cases, they layer those on top using a variety of mechanisms, which depend on the type of work being done. On Sat, Feb 1, 2014 at 11:23 PM, Jesper Louis Andersen wrote: > Like Erik writes, you don't know how what you lost. At best you can try to > mitigate it. It is definitely one of the things I would ask Pieter about how > he solves in C/C++. > > > On Fri, Jan 31, 2014 at 6:05 PM, Garrett Smith wrote: >> >> On Fri, Jan 31, 2014 at 2:47 AM, Andreas Schultz >> wrote: >> > Hi, >> > >> > ----- Original Message ----- >> >> Yes - Google didn't suggest this. >> >> >> >> Did anybody do any performance measurements on this? >> > >> > Not yet, didn't have time for it :-( >> >> I don't know if this is helpful or not to the question of >> benchmarking, but I've created a very simple behavior to compare >> erlang-czmq with erlzmq: >> >> https://github.com/gar1t/erlang-czmq/blob/master/src/zmq_gen_benchmark.erl >> >> There are two flavors of this - one for each library being benchmarked: >> >> https://github.com/gar1t/erlang-czmq/blob/master/src/erlzmq_benchmark.erl >> >> https://github.com/gar1t/erlang-czmq/blob/master/src/czmq_benchmark.erl >> >> In your Berlin workshop (tempted to travel for this :), if this topic >> comes up, maybe this could be helpful to run some quick tests. I'm >> very happy to help with this in any way! >> >> Garrett >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From wallentin.dahlberg@REDACTED Sun Feb 2 01:29:48 2014 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Sun, 2 Feb 2014 01:29:48 +0100 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: Message-ID: Not really an oversight .. Not everything is included in the release candidate =) .. perhaps for rc2. The idea is to have it in place for 17.0.0 production release. 2014-02-02 Serge Aleynikov : > It doesn't look like the new map type is supported in erl_interface (and > likely jinterface): > > 1> M = #{ a => 10, b => 20 }. > #{a => 10,b => 20} > 2> term_to_binary(M). > <<131,116,0,0,0,2,100,0,1,97,100,0,1,98,97,10,97,20>> > 3> io:format("~c\n", [116]). > t > ok > > $ grep 't' lib/erl_interface/include/* > > Is this an oversight? > > Serge > > > On Fri, Jan 31, 2014 at 4:51 PM, Kenneth Lundin wrote: > >> Erlang/OTP 17.0-rc1 has been released. >> >> This is an alpha release, which will be followed by a planned beta >> release about a month later and a final >> OTP 17.0 product release in the end of March 26, 2014. >> Between the alpha and beta and final release there will be new updates of >> the master branch with corrections >> and minor new features. Occasionally there might be new tags which we in >> that >> case will communicate and ask you to test. >> >> Erlang/OTP 17.0 is a new major release with new features, quite a few >> (characteristics) improvements, >> as well as some incompatibilities. See the README file and the >> documentation for more details. >> >> We would like to ask you to download and test the alpha release and send >> us your feedback as soon as possible, >> so that we can make the necessary corrections before OTP 17.0-rc2 and OTP >> 17.0, respectively. >> The release contains many changes; thus, some unexpected >> incompatibilities or issues may have slipped through >> our tests. Please try to build and run your current products/applications >> and let us know about any problems. >> >> Note! The new datatype MAP is not properly documented yet but the EEP 43 >> http://www.erlang.org/eeps/eep-0043.html >> will provide a good start. Also note that it is a limited implementation >> of maps implemented so far: >> >> - no variable keys are allowed >> - native code can not be generated for modules using maps >> >> Some other highlights of the release are: >> >> - Maps, a new dictionary data type (experimental) >> - A more natural mapping from ASN.1 OCTET STRING and BIT STRING to >> Erlang types, >> and other ASN.1 improvements and optimizations >> - The {active, N} socket option for TCP, UDP, and SCTP >> - A new (optional) scheduler utilization balancing mechanism >> - Migration of memory carriers has been enabled by default on all >> ERTS internal >> memory allocators >> - Increased garbage collection tenure rate >> - Experimental "dirty schedulers" functionality >> - Funs can now be given names >> - Miscellaneous unicode support enhancements >> - A new, semantic version scheme for OTP and its applications >> >> You can find the README file with more detailed info at >> >> http://www.erlang.org/download/otp_src_17.0-rc1.readme >> >> You can download the full source distribution from >> >> http://www.erlang.org/download/otp_src_17.0-rc1.tar.gz >> http://www.erlang.org/download/otp_src_17.0-rc1.readme (this file) >> >> Note: To unpack the TAR archive you need a GNU TAR compatible program. >> >> For installation instructions please read the README that is part of the >> distribution. >> >> You can also find this release at the official Erlang/OTP Git-repository >> at Github here: >> >> https://github.com/erlang/otp tagged *OTP_17.0-rc1* >> >> >> The Windows binary distribution can be downloaded from >> >> http://www.erlang.org/download/otp_win32_17.0-rc1.exe >> http://www.erlang.org/download/otp_win64_17.0-rc1.exe >> >> >> On-line documentation can be found at http://www.erlang.org/doc/. >> You can also download the complete HTML documentation or the Unix manual >> files >> >> http://www.erlang.org/download/otp_doc_html_17.0-rc1.tar.gz >> http://www.erlang.org/download/otp_doc_man_17.0-rc1.tar.gz >> >> We also want to thank those that sent us patches, suggestions and bug >> reports. >> >> The Erlang/OTP Team at Ericsson >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wallentin.dahlberg@REDACTED Sun Feb 2 01:33:33 2014 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Sun, 2 Feb 2014 01:33:33 +0100 Subject: [erlang-questions] R17 maps and accessor syntax In-Reply-To: <48944134-ab6b-4bc6-9d2e-d72a1ca97b1e@me.com> References: <48944134-ab6b-4bc6-9d2e-d72a1ca97b1e@me.com> Message-ID: Single value access is not implemented so that won't work. // Bj?rn-Egil 2014-02-02 Rudolph van Graan : > Hi, > > EEP43 says: > > For accessing single values in maps, let us use an de-association: > > V = M#{ K }. > > 11> B = #{key1 => 124, key2 => 111, key3 => 444}. > #{key1 => 124,key2 => 111,key3 => 444} > > 12> B#{ key1 }. > * 1: syntax error before: '}' > > Am I doing something wrong? > > > R > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peerst@REDACTED Sun Feb 2 14:03:03 2014 From: peerst@REDACTED (Peer Stritzinger) Date: Sun, 2 Feb 2014 14:03:03 +0100 Subject: [erlang-questions] Documentation on Binding a C library to Erlang References: Message-ID: Besides what Steve suggested I'd recommend writing a port (going the "not really wanting the C library running with the VM" path). Ports are external processes which comunicate via I/O. This is a bit slower than the other posibilities butit has a huge advantage: if your port program crashes, your Erlang node will live on its easy to have a supervisor restart your Port. This will keep your fault tolerance. When writing a C port program, I usually use a very simplistic protocol (framing with {packet, 2} or {packet, 4} ) which keeps especially the C code easy. It easier to pack everything C friendly in binaries than decode general Erlang terms in the port. Since when my C code will be restarted when it crashes it accomodates a C style with lots of assert() macros in it (which are enabled in production). Also be aware: NIFs look easier than linked in drivers but are actually hard to do right. Problem is that a long running NIF blocks the Erlang scheduler it runs on. This counteracts often the faster performance of the C code and results in a less responsive system. Cheers, -- Peer On 2014-01-31 21:42:02 +0000, Steve Vinoski said: > > > > On Fri, Jan 31, 2014 at 4:35 PM, kraythe . wrote: > Greetings, I am a newbie to erlang. I am interested in binding a c > library that I have as source (that I have written) to Erlang. In Java > I would use JNI. In Erlang I don't know. Can anyone point me at where > the docs are for this? Especially a tutorial. Google has been > unrevealing and i have been through hundreds of dead ends.? > > If you really want the C library running together with the Erlang VM, > you'll write either a set of native implemented functions (NIFs) or a > linked-in driver. See the links below. > > http://www.erlang.org/doc/tutorial/nif.html > http://www.erlang.org/doc/man/erl_nif.html > http://www.erlang.org/doc/apps/erts/driver.html > http://www.erlang.org/doc/man/erl_driver.html > > --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From peerst@REDACTED Sun Feb 2 14:55:02 2014 From: peerst@REDACTED (Peer Stritzinger) Date: Sun, 2 Feb 2014 14:55:02 +0100 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. References: <52ED626B.6040005@ninenines.eu> Message-ID: On 2014-02-01 21:08:59 +0000, Lo?c Hoguin said: > I think for most users and most use cases maps will completely take over > records. I really hope you are not right with this (but I fear that you might be). Erlang with maps for everything will be a poorer language. > Reason 2: Upgrading a process state that uses records is terrifying. Upgrading a process state *should* terrify you a bit, because it has the potential of undetected corruption of state. > Well here's a good explanation of why it's terrifying and sucks > horribly: > http://erlang.org/pipermail/erlang-questions/2014-February/076765.html For me thats exactly the opposite. > For maps at worst you just do M#{ new_field => default_value } and are > done with it. Or not if you broke your state. > Reason 3: Records are cumbersome to use. > > Many hate the record syntax. Many also would prefer to avoid the record > definition entirely when prototyping some code. And they should! Maps > aren't slowing down your work the way records do. And guess what. Most > of the time the prototype of an Erlang process is good enough for > production use. I neither hate the record syntax nor has ever defining a state record slowed my down. Maps being used by everyone as state is the worst case scenario I can think of. > You lose Dialyzer. That's the big drawback. But most processes' state is > smallish so mistakes are hard to make and quickly found anyway. If a state is smallish (as it should be most of the time) then it can't be added to that often in updates (otherwise it would soon be no longer smallish). So updates will be a rare occasion and therefor them being a bit complicated won't hur much. And for a rarely changing smallish state having to declare the record can't be that much overhead. > These are the three main reasons I think maps will take over. Personally > I will probably still use records for most processes' state Good to hear :-) > Maps will also completely beat proplists to death, burn their brackets > and eat their hearts. I don't think I need to explain why. Id be not so extreme dismembering proplists, but mostly agree on this. Cheers, -- Peer -------------- next part -------------- An HTML attachment was scrubbed... URL: From james@REDACTED Sun Feb 2 15:23:33 2014 From: james@REDACTED (james) Date: Sun, 02 Feb 2014 14:23:33 +0000 Subject: [erlang-questions] 0MQ libraries In-Reply-To: References: Message-ID: <52EE54E5.6000608@mansionfamily.plus.com> On 31/01/2014 07:12, Joe Armstrong wrote: > Pieter suggest looking at > > ... > https://github.com/zeromq/libzmq/blob/master/tests/test_stream.cpp > > These implement the wire-line protocol on top of tcp rather than > through the > 0mz library so its easier to see whats going on. > Isn't that dangerous if there is a significant difference in the desired license? The zmtp license is more liberal. From erlang@REDACTED Sun Feb 2 18:02:56 2014 From: erlang@REDACTED (Joe Armstrong) Date: Sun, 2 Feb 2014 18:02:56 +0100 Subject: [erlang-questions] 0MQ libraries In-Reply-To: <52EE54E5.6000608@mansionfamily.plus.com> References: <52EE54E5.6000608@mansionfamily.plus.com> Message-ID: I'm slightly confused here. I was thinking of implementing http://rfc.zeromq.org/spec:23 The text in RFC says This Specification is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; The words "with this program" do not make sense - there is no program. Just a spec of what you see on the wire. How can I receive a copy of a program when there is no program? Then the text is copyrighted and licensed in three different ways. Do I have to do a darkroom implementation and swear on the bones of my dearly lamented Aunty Doreen that I have never read the C++ code on the zero MQ site? I just want to read the spec and implement it. This is presumably why it has been published. RFCs accepted by ISOC are described in https://www.rfc-editor.org/copyright.23Jan01.html In their wisdom ISOC do not license RFCs - but they retain a copyright. I would be very happy to a see a change in the ZMQ RFCs in line with what ISOC does. Cheers /Joe On Sun, Feb 2, 2014 at 3:23 PM, james wrote: > On 31/01/2014 07:12, Joe Armstrong wrote: > >> Pieter suggest looking at >> >> ... >> >> https://github.com/zeromq/libzmq/blob/master/tests/test_stream.cpp >> >> These implement the wire-line protocol on top of tcp rather than through >> the >> 0mz library so its easier to see whats going on. >> >> Isn't that dangerous if there is a significant difference in the desired > license? > > The zmtp license is more liberal. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zkessin@REDACTED Sun Feb 2 20:56:23 2014 From: zkessin@REDACTED (Zachary Kessin) Date: Sun, 02 Feb 2014 21:56:23 +0200 Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: References: Message-ID: <52EEA2E7.5050009@gmail.com> > 1. The tools are, well frankly, garbage. Sorry, in 2014 to be pushed > back to coding with VIM and makefiles is primitive. Rebar is > crytptic and just the pet project of a guy on GIT. Compared to > Gradle, Maven and even (though I don't care for it much) SBT, > rebar is ... lacking. I want to spend time working on my business > logic, not fighting tools. There are plugins for eclipse and > intellij but they have minimal functionality and i keep reverting > back to vim. > Actually the tools are quite good, you are just looking at the wrong set of tools. Yes Make in one form or another has been around forever (1977) but to my mind that means that it actually does the job well, and has had all the weird bugs found and pushed out years ago. It is quite good at doing the minimal amount of work that is required at any given time and will use as many cores as you have around. Rebar has a few weird issues but is generally pretty good. Most of the hard core Erlang folks seem to use Emacs and many of the tools are setup to work there. That being said there are a group of tools that you probably haven't even looked at that are quite powerful and are worth your time, these include Dialyzer, Wrangler, PropEr or QuickCheck, and Concuerror. If you define tools to be a fancy IDE then Erlang is lacking, but if you define tools as stuff that helps you ship code then Erlang has some amazing tools. -- Zachary Kessin Mostly Erlang Podcast Skype: zachkessin Twitter: @zkessin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: zkessin.vcf Type: text/x-vcard Size: 264 bytes Desc: not available URL: From kraythe@REDACTED Sun Feb 2 22:33:23 2014 From: kraythe@REDACTED (kraythe .) Date: Sun, 2 Feb 2014 15:33:23 -0600 Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: References: <52ED37FC.8040703@stoo.org> Message-ID: The community is what eventually made my decision. The same thread on the scala forum .... didn't go well. :( I am taking the hit and learning emacs. Tryign to get EDTS working and so on. Except I want to be proficient at base emacs before I go adding tools. But its starting the adventure now. I have decided to implement the server in erlang. Working on my first NIF now for some heavy math work. *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* *Author of: Hardcore Java (2003) and Maintainable Java (2012)* *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 * On Sat, Feb 1, 2014 at 1:11 PM, Garrett Smith wrote: > I would add one more feature of Erlang that I don't think has been > mentioned: the community is one of the best you will find in all of > software. > > To illustrate, please refer to this email thread, which I came across: > > https://groups.google.com/forum/#!topic/erlang-programming/t3jbMyKPLdw > > Here you have someone who is asking very honest questions about Erlang > vis-a-vis other languages. In many communities, this sort of question, > while not intended to do so, would spark a series of flame wars and > religious zealotry. But this question, on the Erlang list, brought > forth some of the most brilliant and thoughtful contributions to > important problems in software I've ever seen. > > What is this worth in your comparison of languages? > > As an aside, I think this particular email thread, which I came > across, should be printed without editing as a pamphlet and handed out > at user groups and software conferences as a treatise on core > principles of language and tool design and civil discourse. If others > are willing to join me, I would consider shaving my head and wearing > brightly colors robes and do this. > > Garrett > > > On Sat, Feb 1, 2014 at 12:07 PM, Tim Stewart wrote: > > Hello, > > > > > > On 01/31/2014 01:03 PM, Attila Rajmund Nohl wrote: > >> > >> 2014-01-30 kraythe .: > >> [...] > >>> > >>> >The tools are, well frankly, garbage. Sorry, in 2014 to be pushed back > >>> > to > >>> >coding with VIM and makefiles is primitive. Rebar is crytptic and just > >>> > the > >>> >pet project of a guy on GIT. Compared to Gradle, Maven and even > (though > >>> > I > >>> >don't care for it much) SBT, rebar is ... lacking. I want to spend > time > >>> >working on my business logic, not fighting tools. There are plugins > for > >>> >eclipse and intellij but they have minimal functionality and i keep > >>> >reverting back to vim. > >> > >> In some sense you're right, in some sense not. In a previous project > >> our "integration build" was quite slow, when behaviors were modified, > >> everything was recompiled because our Makefiles lacked proper > >> dependencies. So some automatic dependecy generator would be nice (I > >> don't know what rebar does). On the other hand in the normal > > > > > > The compile module (http://erlang.org/doc/man/compile.html) supports > > generating Makefile rules to track header dependencies via the `makedep' > > option. You can also invoke this via erlc's `-M' option. > > > > This may not be the solution to Attila's integration build dependency > > problems, but I feel it is worth mentioning in the context of this > thread. > > > > -TimS > > > > -- > > Tim Stewart > > tim@REDACTED > > > > _______________________________________________ > > 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 send2philip@REDACTED Sun Feb 2 22:38:47 2014 From: send2philip@REDACTED (Philip Clarke) Date: Sun, 2 Feb 2014 21:38:47 +0000 Subject: [erlang-questions] what does suspend do ? Message-ID: Hi, I have been doing some profiling using fprof on my system. Using fprof I see that ets:select is calling suspend. I suspect that I have found a bottleneck where I have an ets table with write_concurrency defined and there are lots of processes doing reads thousands of times per second. But my question is more general to profiling. What exactly does suspend do ? I suspect it may be an indication that my process has run out of reductions and is preempted by the scheduler ? Could anyone confirm please ? Just in case it is useful, here is the relevant part of my fprof analysis file. {[{{mymodule,get_values,1}, 6, 2992.735, 31.313}], { {ets,select,2}, 6, 2992.735, 31.313}, % [{suspend, 92, 1707.908, 0.000}, {{lists,sum,1}, 6, 1251.655, 0.709}, {garbage_collect, 7, 1.859, 1.859}]}. {[{{ets,select,2}, 6, 1251.655, 0.709}], { {lists,sum,1}, 6, 1251.655, 0.709}, % [{{lists,sum,2}, 6, 1250.946, 0.047}]}. {[{{lists,sum,1}, 6, 1250.946, 0.047}, {{lists,sum,2}, 20647, 0.000, 1241.206}], { {lists,sum,2}, 20653, 1250.946, 1241.253}, % [{suspend, 10, 9.693, 0.000}, {{lists,sum,2}, 20647, 0.000, 1241.206}]}. Thanks Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: From kraythe@REDACTED Sun Feb 2 22:41:08 2014 From: kraythe@REDACTED (kraythe .) Date: Sun, 2 Feb 2014 15:41:08 -0600 Subject: [erlang-questions] Help with EDTS for a Emacs and Erlang newbie? Message-ID: I am trying to get EDTS working and I am having some issues that i hope you guys can help with. I cloned the repo under .emacs-edts/edts did a make and all was fine. When I run it, however, emacs reports an error "Cannot open load file: face-remap" I have the following config: *.bash_profile * alias edts='emacs -q -l ~/.emacs-edts/init.el ' *.emacs-eds/init.d* ;;; This is the configuration for running emacs with EDTS ;;; see: https://github.com/tjarvstrand/edts for more info ;;; Can be invoked with a bash alias like the following: ;;; alias edts='emacs -q -l ~/.emacs-edts' (setq user-emacs-directory "~/.emacs-edts/") (transient-mark-mode 1) ;; Enable Mark Block Highlingting (show-paren-mode 1) ;; Setup backups strategy. (setq version-control t ;; Use version numbers for backups. kept-new-versions 10 ;; Number of newest versions to keep. kept-old-versions 0 ;; Number of oldest versions to keep. delete-old-versions t ;; Don't ask to delete excess backup versions. backup-by-copying t) ;; Copy all files, don't rename them. ;; Default and per-save backups go here: (setq backup-directory-alist '(("" . "~/.emacs-backup/per-save"))) (defun force-backup-of-buffer () ;; Make a special "per session" backup at the first save of each emacs session. (when (not buffer-backed-up) ;; Override the default parameters for per-session backups. (let ((backup-directory-alist '(("" . "~/.emacs.d/per-session"))) (kept-new-versions 3)) (backup-buffer))) ;; Make a "per save" backup on each save. The first save results in ;; both a per-session and a per-save backup, to keep the numbering ;; of per-save backups consistent. (let ((buffer-backed-up nil)) (backup-buffer))) ;; Setup Erlang mode (setq load-path (cons "/usr/local/lib/erlang/lib/tools-2.6.13/emacs/" load-path)) (setq erlang-root-dir "/usr/local/lib/erlang") (setq exec-path (cons "/usr/local/lib/erlang/bin" exec-path)) (require 'erlang-start) (add-to-list 'load-path "~/.emacs-edts/edts/") (require 'edts-start) Can anyone advise me on how to solve this? My goal is to be able to use the command 'edts' to start emacs in edts mode and still retain non-edts mode for other uses of emacs. Thanks in advance. *Robert Simmons Jr. MSc.* *Author of: Hardcore Java (2003) and Maintainable Java (2012)* *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustav.simonsson@REDACTED Sun Feb 2 23:04:37 2014 From: gustav.simonsson@REDACTED (Gustav Simonsson) Date: Sun, 2 Feb 2014 23:04:37 +0100 Subject: [erlang-questions] Help with EDTS for a Emacs and Erlang newbie? In-Reply-To: References: Message-ID: Hi, Just tried myself with the init file you pasted (only change was I used dir .emacs.d/edts instead of .emacs-edts/edts) and it loads correctly. What version of emacs are you using? What OS? I found a page which seems to indicate face-remap can be used with emacs 23, could it be your version is older? Cheers, Gustav Simonsson On Sun, Feb 2, 2014 at 10:41 PM, kraythe . wrote: > I am trying to get EDTS working and I am having some issues that i hope > you guys can help with. I cloned the repo under .emacs-edts/edts did a make > and all was fine. When I run it, however, emacs reports an error "Cannot > open load file: face-remap" I have the following config: > > *.bash_profile * > alias edts='emacs -q -l ~/.emacs-edts/init.el ' > > *.emacs-eds/init.d* > ;;; This is the configuration for running emacs with EDTS > ;;; see: https://github.com/tjarvstrand/edts for more info > ;;; Can be invoked with a bash alias like the following: > ;;; alias edts='emacs -q -l ~/.emacs-edts' > > (setq user-emacs-directory "~/.emacs-edts/") > (transient-mark-mode 1) ;; Enable Mark Block Highlingting > (show-paren-mode 1) > > ;; Setup backups strategy. > (setq version-control t ;; Use version numbers for backups. > kept-new-versions 10 ;; Number of newest versions to keep. > kept-old-versions 0 ;; Number of oldest versions to keep. > delete-old-versions t ;; Don't ask to delete excess backup versions. > backup-by-copying t) ;; Copy all files, don't rename them. > ;; Default and per-save backups go here: > (setq backup-directory-alist '(("" . "~/.emacs-backup/per-save"))) > > (defun force-backup-of-buffer () > ;; Make a special "per session" backup at the first save of each emacs > session. > (when (not buffer-backed-up) > ;; Override the default parameters for per-session backups. > (let ((backup-directory-alist '(("" . "~/.emacs.d/per-session"))) > (kept-new-versions 3)) > (backup-buffer))) > ;; Make a "per save" backup on each save. The first save results in > ;; both a per-session and a per-save backup, to keep the numbering > ;; of per-save backups consistent. > (let ((buffer-backed-up nil)) > (backup-buffer))) > > ;; Setup Erlang mode > (setq load-path (cons "/usr/local/lib/erlang/lib/tools-2.6.13/emacs/" > load-path)) > (setq erlang-root-dir "/usr/local/lib/erlang") > (setq exec-path (cons "/usr/local/lib/erlang/bin" exec-path)) > (require 'erlang-start) > > (add-to-list 'load-path "~/.emacs-edts/edts/") > (require 'edts-start) > > Can anyone advise me on how to solve this? My goal is to be able to use > the command 'edts' to start emacs in edts mode and still retain non-edts > mode for other uses of emacs. > > Thanks in advance. > > *Robert Simmons Jr. MSc.* > *Author of: Hardcore Java (2003) and Maintainable Java (2012)* > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 > * > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From per@REDACTED Sun Feb 2 23:26:49 2014 From: per@REDACTED (Per Hedeland) Date: Sun, 2 Feb 2014 23:26:49 +0100 (CET) Subject: [erlang-questions] R16B03-1 + Redhat with latest openssl RPMs = EC crypto issues still occurring In-Reply-To: Message-ID: <201402022226.s12MQn1g073756@pluto.hedeland.org> Adam Bloomston wrote: > >Note that installation with environment variable set prior to calling >configure does not work (took me a while to figure this out since I'm not >that familiar with configure/make): > >--------------------------- > >$ CFLAGS="-DOPENSSL_NO_EC=1"; ./configure && make && sudo make install That commandline does not set CFLAGS as an environment variable (unless you have done 'export CFLAGS' earlier in the same shell), only as a shell variable - not visible to 'configure'. You probably want to drop the semicolon: $ CFLAGS="-DOPENSSL_NO_EC=1" ./configure && make && sudo make install - which sets CFLAGS as an environment variable for the following command (i.e. configure) only. Whether configure actually pays attention to it is another thing (I believe it does), but at least it has the possibility. --Per Hedeland From adam@REDACTED Mon Feb 3 00:57:08 2014 From: adam@REDACTED (Adam Bloomston) Date: Sun, 2 Feb 2014 18:57:08 -0500 Subject: [erlang-questions] R16B03-1 + Redhat with latest openssl RPMs = EC crypto issues still occurring In-Reply-To: <201402022226.s12MQn1g073756@pluto.hedeland.org> References: <201402022226.s12MQn1g073756@pluto.hedeland.org> Message-ID: Thanks for the tip Peter. When I look back at Andreas Schultz post I see he had specified it as you put it, i.e. without a semicolon. I mistakenly read it as having a semicolon. Best, Adam On Sun, Feb 2, 2014 at 5:26 PM, Per Hedeland wrote: > Adam Bloomston wrote: > > > >Note that installation with environment variable set prior to calling > >configure does not work (took me a while to figure this out since I'm not > >that familiar with configure/make): > > > >--------------------------- > > > >$ CFLAGS="-DOPENSSL_NO_EC=1"; ./configure && make && sudo make install > > That commandline does not set CFLAGS as an environment variable (unless > you have done 'export CFLAGS' earlier in the same shell), only as a > shell variable - not visible to 'configure'. You probably want to drop the > semicolon: > > $ CFLAGS="-DOPENSSL_NO_EC=1" ./configure && make && sudo make install > > - which sets CFLAGS as an environment variable for the following command > (i.e. configure) only. Whether configure actually pays attention to it > is another thing (I believe it does), but at least it has the > possibility. > > --Per Hedeland > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.irvine@REDACTED Mon Feb 3 01:17:58 2014 From: chuck.irvine@REDACTED (Charles Irvine) Date: Sun, 02 Feb 2014 18:17:58 -0600 Subject: [erlang-questions] getting "Can not link the wx driver, wx will NOT be useable" making 17.0-rc1 Message-ID: On os-x 10.9.1 I?m getting "Can not link the wx driver, wx will NOT be useable? when making Erlang 17.0-rc1. I downloaded the latest version of wxWidgets from github and built it with: $ ./configure --with-cocoa --prefix=/usr/local --with-macosx-version-min=10.9 --disable-shared $ make $ sudo make install I downloaded the R17 of Erlang from Github and built it with: $ ./configure --enable-shared-zlib $ make $ sudo make install Upon invocation of ?configure?: I got: checking if we can link wxwidgets programs... no configure: WARNING: Can not link wx program are all developer packages installed? Upon make invocation, I got: Can not link the wx driver, wx will NOT be useable So now my GUI components won?t be working. Any help is greatly appreciated!! Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Mon Feb 3 03:08:35 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 3 Feb 2014 15:08:35 +1300 Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: References: <89DAA09F-64B0-4565-A73C-784B5E8EB4C6@feuerlabs.com> <8883B14026CD4CB38E71BEB9DFE5BF67@srstrong.com> Message-ID: <2AF9E186-6684-4787-8368-6E019C8113C8@cs.otago.ac.nz> On 31/01/2014, at 11:40 PM, Vlad Dumitrescu wrote: > --- > Why does automating something have anything to do with that thing being textual or graphical? vim runs in a console, but also as gVim (graphical). The same can be said about emacs and XEmacs. gVim is still a textual interface. XEmacs is not "Emacs using X11" but a fork of Emacs; the latest stable release of XEmacs appears to be 2009. The fact that emacs uses a GUI does not make the thing that is being edited "graphical". > Whether we want it or not, to the human brain images are lower level than text or speech. If you mean that recognising a line is lower level than recognising "a line", that's true, but it's hardly relevant. Have you ever seen Penrose's notation? (http://en.wikipedia.org/wiki/Penrose_graphical_notation) A diagram like this is composed from shapes recognised by our low level visual processing systems, but the meaning of the diagram is *not* immediate. It takes rather more training and practice than I've had to be able to read these things; at my present stage of understanding I would find a page of text _easier_ to read. The (first edition of) the book that explains how to *use* Eclipse is bigger than the listing of my emacs-like editor PLUS the listing of the C compiler I originally used to write it PLUS the listing of the UNIX kernel it originally ran on PLUS the manuals. > We can't read text files directly, we interpret the graphical representation of that text, be it on a console or a window. Some people can handle abstractions in their heads more easily than others. The latter category will need help, possibly in the form of tools to visualize the code (or whatever). Diagrams are *also* abstractions. In fact they are even *more* abstract than text. > > In my opinion, what a programming environment brings to the table is multiple ways to look at the code, to quickly see what is going on. I think Joe agrees with you, except that Joe places a heavy emphasis on - something that has precise definition - explicit and straightforward semantics - that he can understand. > colleague or two to look at it. > > Taking a TeX example, wouldn't you find it helpful to have a window alongside your editor that show in real time how the document is rendered, without the need to run "tex mydoc.tex | pdfview&" (or whatever) yourself once in a while? Actually, we _have_ that. It's called TeXShop. > > Or in Erlang (and doing some wishful thinking), wouldn't it be useful if one could actually _see_ in real time the network of processes in a node, how they are linked/monitoring each other, how they communicate, which ones are growing large or seem deadlocked, zoom out for a bird-eye view or in for details? Let's take a form of diagram that is widely agreed to be straightforward. A box represents a class; an arrow from X to Y represents "X inherits directly from Y". I have a Smalltalk system of my own. When you compile a program, it spits out a "map" file, which includes a list of classes at the top using indentation to show inheritance. This can be turned automatically into a ".dot" file for display using GraphViz or any of several other programs that read ".dot" files. The one that's actually _useful_ is the text file, because there doesn't seem to be any good way to display nearly 800 classes in one diagram. Heck, the collection hierarchy alone has 176 classes; try getting just _that_ in one display. One of the other Smalltalk systems I use has a "show the hierarchy of the class I'm browsing" button that actually generates UML. It is a pain in the posterior, because you can't actually *see* very much, and that's even with your attention limited to something with only a handful of ancestors and/or descendants. There is a beautiful little paper by Alan Blackwell, "Correction: a picture is worth 84.1 words" (http://www.cl.cam.ac.uk/~afb21/publications/Student-ESP.html) The references of that paper are pretty good. Now, visualising the process structure would be nice, except that someone *did* this using UbiGraph and the result was as dismaying as it was cool. Erlang lets you have *lots* of processes, and that's just what doesn't suit a diagram. > As a user, one shouldn't need to understand how the environment works (you think Eclipse is complex, I think Emacs is; it's a matter of what we are accustomed to). We can measure the complexity of an environment in itself without reference to what we are accustomed to. The text editor I normally use takes less than 15 000 raw lines of C (less than 8 000 SLOC); executables and help files come to 173 kB on disc. That _has_ to be less complex than Emacs.app, which is 161 MB on disc. And that _has_ to be less complex than Eclipse for C/C++ where the smallest download seems to be 141 MB compressed. And the really annoying thing is that the actual text editing support in Eclipse is far more limited than that in the 173 kB program! > Of course, this changes when I need to do something that the environment doesn't support. But even so, there is always the fallback of doing it as if no IDE was available, so I don't think that having an IDE can make things worse. In one sense, what makes things worse is indeed not having an IDE, but _having_ to have an IDE. In another sense, using an IDE can indeed result in worse code. It's actually quite easy to write a component correctly. The problem is interfaces. Nancy Leveson has a very nice little avionics example (FLAPS-EXTENDED) where the machine- checked interface remains exactly the same but the semantics on one side changes. The only way I know to deal with this is to frequently put *both* some clients *and* some suppliers of an interface on screen *at the same time* so that I can review them. An IDE _can_ do this, and in fact Smalltalk systems are especially good at that. But the more screen space the IDE takes up for _being_ an IDE (in Smalltalk, about 50%; in Eclipse, it's worse) the harder it is to actually do this. > Knuth could do this amazing thing with TeX (practically no bugs) for all the reasons you stated, but also because he set very strict boundaries for what TeX is and can do. Basically, he not only froze the specifications, he set them in stone. If that would have been enough, would there have been a need for XeTeX, pdfTeX, laTeX and other tools that extend and improve the basic TeX? Yes. And those things were only made *possible* by the existence of the stable core. When Knuth wrote TeX, PDF did not yet exist. In fact, Postscript did not yet exist. When Knuth wrote TeX, Unicode did not yet exist. LaTeX is basically a set of macros sitting on top of TeX that depends utterly on TeX underneath, and it's clearly not "needed". (ConTeXt http://en.wikipedia.org/wiki/ConTeXt would be LaTeX's principal rival.) This is rather like saying "if having a C++ standard was a good idea, why would TBB or MCSTL exist?" And the answer is that TBB and MCSTL wouldn't be any _use_ if there weren't a stable C++ underneath. > Would it have been possible to keep the bug levels as low if these extensions and improvements had been part of the core TeX? You are right: that is an excellent argument for keeping a small stable core. But weren't you just arguing _against_ that? For some reason text interfaces seem to be better specified and more stable than GUI interfaces. Every release of Word I have to relearn the interface; while I have LaTeX documents from 1984 I can still use. From my own experience of the TeX family, it's a lot easier to get an everyday understanding of HTML+CSS than it is TeX, but every time I've needed something less quotidian, I have found the *documentation* of the TeX family to be better than the *documentation* of say CSS. (For example, when I read the book about CSS by its inventors http://www.amazon.com/Cascading-Style-Sheets-Designing-Web/dp/020141998X I was frustrated to find no more semantics than was in the W3C specifications, which was to say, not enough to let me figure out how to get what I wanted. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 120px-Penrose_bianchi_identity.svg.png Type: image/png Size: 3549 bytes Desc: not available URL: From mjtruog@REDACTED Mon Feb 3 07:10:12 2014 From: mjtruog@REDACTED (Michael Truog) Date: Sun, 02 Feb 2014 22:10:12 -0800 Subject: [erlang-questions] [ANN] CloudI 1.3.1 Released! Message-ID: <52EF32C4.5040906@gmail.com> Download 1.3.1 from http://sourceforge.net/projects/cloudi/files/latest/download (checksums at the bottom of this email) What is CloudI? A Cloud at the lowest level! CloudI (http://cloudi.org/) is a "universal integrator" using an Erlang core, with its actor model, to pursue efficiency, fault-tolerance and scalability. The CloudI API provides a minimal interface to communicate among actors that are called services, so programming language agnostic, database agnostic, and messaging bus agnostic integration can occur. CloudI currently integrates with the programming languages Erlang, C/C++, Java, Python, and Ruby, the databases PostgreSQL, elasticsearch, Cassandra, MySQL, couchdb, memcached, and tokyotyrant, the messaging bus ZeroMQ and the internal CloudI service bus. HTTP is also supported for easy integration with cowboy and elli. If anyone is willing to get involved, don't hesitate to contact me or start looking at the code. There is an old game server (a MUD known as SillyMUD) which has CloudI integration at https://github.com/okeuday/sillymud . If you want to play it, it is currently hosted at https://cloudi.org/sillymud/client.html . It takes awhile for it to load with SSL but is quite snappy afterwards. You will need websockets support in your browser, so you probably want to use chromium. Thanks for the various feedback/issues/bugs that have been reported. The details for this release are below: February 1, 2014 Version 1.3.1 (beta) released. * Added a demo of CloudI scaling a game server (a MUD) that is 20+ years old (see https://github.com/okeuday/sillymud) * Added the service configuration option count_process_dynamic to dynamically adjust the number of service processes based on the incoming service request rate * The hibernate service configuration option can provide rate based service hibernation now * The C++ CloudI API can provide backtrace information from CloudI::API::backtrace() when configured using --with-cxx-backtrace * A few of the new internal service functions: * cloudi_service_api:service_subscriptions/2 * cloudi_service:recv_asyncs/4 * cloudi_service:source_subscriptions/2 * cloudi_service:context_options/1 * cloudi_service:environment_transform/1 * cloudi:trans_id_age/1 * The cloudi module can use lazy destination refresh methods and works best if you update the destination data with the cloudi:destinations_refresh/2 function * Latency of the following services was reduced: * cloudi_service_http_cowboy * cloudi_service_http_elli * cloudi_service_tcp * Fixed cloudi_service_quorum and added a byzantine mode * Added the cloudi_service_router internal service * The cloudi_service_filesystem can refresh its data after a configured time period * Now CloudI has separate repositories for each CloudI Erlang application if you want only internal service support with simple rebar integration (see https://github.com/CloudI/cloudi_core#readme) * The service Erlang application is provided to make service creation a bit less complex (see https://github.com/CloudI/service) * The automatic loading of an internal service can be disabled with the automatic_loading service configuration option set to false (see the hello_world5 example to understand why) * Service configuration now can use a proplist format, if you dislike the tuple format (see https://github.com/CloudI/CloudI/blob/master/examples/hello_world5/apps/hello_world5/src/hello_world5_app.erl#L57 or https://github.com/CloudI/CloudI/blob/master/src/lib/cloudi_core/src/cloudi_service_api.erl#L186) * Various bugfixes, small additions, and documentation improvements Please mention any problems, issues, or ideas! Thanks, Michael SHA256 CHECKSUMS 74c4cad74536f2a8f62c8efab7c4c4f5e2277f8151cc9b827df25e17d48c2d6d cloudi-1.3.1.tar.bz2 8b4c23bffbb4cc5c10155e10496e85d14c91a22352cf27803ccb0b2aa94422d7 cloudi-1.3.1.tar.gz From paulperegud@REDACTED Mon Feb 3 07:57:02 2014 From: paulperegud@REDACTED (Paul Peregud) Date: Mon, 3 Feb 2014 07:57:02 +0100 Subject: [erlang-questions] what does suspend do ? In-Reply-To: References: Message-ID: Not sure about suspend, but you might be hitting locks a lot. Compile erlang with lcnt - those suspends maybe just a result of optimistic spinning on locks. On Feb 2, 2014 10:38 PM, "Philip Clarke" wrote: > Hi, > > I have been doing some profiling using fprof on my system. > Using fprof I see that ets:select is calling suspend. > > I suspect that I have found a bottleneck where I have an ets table with > write_concurrency defined and there are lots of processes doing reads > thousands of times per second. But my question is more general to > profiling. > > What exactly does suspend do ? I suspect it may be an indication that my > process has run out of reductions and is preempted by the scheduler ? > Could anyone confirm please ? > > Just in case it is useful, here is the relevant part of my fprof analysis > file. > > {[{{mymodule,get_values,1}, 6, 2992.735, 31.313}], > { {ets,select,2}, 6, 2992.735, 31.313}, > % > [{suspend, 92, 1707.908, 0.000}, > {{lists,sum,1}, 6, 1251.655, 0.709}, > {garbage_collect, 7, 1.859, 1.859}]}. > > {[{{ets,select,2}, 6, 1251.655, 0.709}], > { {lists,sum,1}, 6, 1251.655, 0.709}, > % > [{{lists,sum,2}, 6, 1250.946, 0.047}]}. > > {[{{lists,sum,1}, 6, 1250.946, 0.047}, > {{lists,sum,2}, 20647, 0.000, 1241.206}], > { {lists,sum,2}, 20653, 1250.946, 1241.253}, > % > [{suspend, 10, 9.693, 0.000}, > {{lists,sum,2}, 20647, 0.000, > 1241.206}]}. > > Thanks > Philip > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kraythe@REDACTED Mon Feb 3 09:12:40 2014 From: kraythe@REDACTED (kraythe .) Date: Mon, 3 Feb 2014 02:12:40 -0600 Subject: [erlang-questions] Help with EDTS for a Emacs and Erlang newbie? In-Reply-To: References: Message-ID: Thanks, I upgraded to latest version with macports. *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* *Author of: Hardcore Java (2003) and Maintainable Java (2012)* *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 * On Mon, Feb 3, 2014 at 1:56 AM, Gustav Simonsson wrote: > Ah, failed paste of the reference, meant to link this page: > http://www.gnu.org/software/emacs/history.html > > > On Mon, Feb 3, 2014 at 8:55 AM, Gustav Simonsson < > gustav.simonsson@REDACTED> wrote: > >> Hi, >> >> >> 22.1.1 is from 2007 [1], this is most likely the cause for the missing >> face-remap. >> >> I'm suspecting there may be other dependencies in many Erlang tools which >> requires a later version of Emacs. >> >> I'd recommend upgrading to version 24; there should be ready packages for >> all major OS/distros. >> >> Cheers, >> Gustav >> >> 1. http://erlang.org/pipermail/erlang-questions/2014-February/076789.html >> >> >> On Mon, Feb 3, 2014 at 6:26 AM, kraythe . wrote: >> >>> I am using >>> GNU Emacs 22.1.1 >>> >>> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* >>> *Author of: Hardcore Java (2003) and Maintainable Java (2012)* >>> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 >>> * >>> >>> >>> On Sun, Feb 2, 2014 at 4:04 PM, Gustav Simonsson < >>> gustav.simonsson@REDACTED> wrote: >>> >>>> Hi, >>>> >>>> Just tried myself with the init file you pasted (only change was I used >>>> dir .emacs.d/edts >>>> instead of .emacs-edts/edts) and it loads correctly. >>>> >>>> What version of emacs are you using? What OS? >>>> >>>> I found a page which seems to indicate face-remap can be used with >>>> emacs 23, could it be your version is older? >>>> >>>> Cheers, >>>> Gustav Simonsson >>>> >>>> >>>> On Sun, Feb 2, 2014 at 10:41 PM, kraythe . wrote: >>>> >>>>> I am trying to get EDTS working and I am having some issues that i >>>>> hope you guys can help with. I cloned the repo under .emacs-edts/edts did a >>>>> make and all was fine. When I run it, however, emacs reports an error >>>>> "Cannot open load file: face-remap" I have the following config: >>>>> >>>>> *.bash_profile * >>>>> alias edts='emacs -q -l ~/.emacs-edts/init.el ' >>>>> >>>>> *.emacs-eds/init.d* >>>>> ;;; This is the configuration for running emacs with EDTS >>>>> ;;; see: https://github.com/tjarvstrand/edts for more info >>>>> ;;; Can be invoked with a bash alias like the following: >>>>> ;;; alias edts='emacs -q -l ~/.emacs-edts' >>>>> >>>>> (setq user-emacs-directory "~/.emacs-edts/") >>>>> (transient-mark-mode 1) ;; Enable Mark Block Highlingting >>>>> (show-paren-mode 1) >>>>> >>>>> ;; Setup backups strategy. >>>>> (setq version-control t ;; Use version numbers for backups. >>>>> kept-new-versions 10 ;; Number of newest versions to keep. >>>>> kept-old-versions 0 ;; Number of oldest versions to keep. >>>>> delete-old-versions t ;; Don't ask to delete excess backup >>>>> versions. >>>>> backup-by-copying t) ;; Copy all files, don't rename them. >>>>> ;; Default and per-save backups go here: >>>>> (setq backup-directory-alist '(("" . "~/.emacs-backup/per-save"))) >>>>> >>>>> (defun force-backup-of-buffer () >>>>> ;; Make a special "per session" backup at the first save of each >>>>> emacs session. >>>>> (when (not buffer-backed-up) >>>>> ;; Override the default parameters for per-session backups. >>>>> (let ((backup-directory-alist '(("" . "~/.emacs.d/per-session"))) >>>>> (kept-new-versions 3)) >>>>> (backup-buffer))) >>>>> ;; Make a "per save" backup on each save. The first save results in >>>>> ;; both a per-session and a per-save backup, to keep the numbering >>>>> ;; of per-save backups consistent. >>>>> (let ((buffer-backed-up nil)) >>>>> (backup-buffer))) >>>>> >>>>> ;; Setup Erlang mode >>>>> (setq load-path (cons "/usr/local/lib/erlang/lib/tools-2.6.13/emacs/" >>>>> load-path)) >>>>> (setq erlang-root-dir "/usr/local/lib/erlang") >>>>> (setq exec-path (cons "/usr/local/lib/erlang/bin" exec-path)) >>>>> (require 'erlang-start) >>>>> >>>>> (add-to-list 'load-path "~/.emacs-edts/edts/") >>>>> (require 'edts-start) >>>>> >>>>> Can anyone advise me on how to solve this? My goal is to be able to >>>>> use the command 'edts' to start emacs in edts mode and still retain >>>>> non-edts mode for other uses of emacs. >>>>> >>>>> Thanks in advance. >>>>> >>>>> *Robert Simmons Jr. MSc.* >>>>> *Author of: Hardcore Java (2003) and Maintainable Java (2012)* >>>>> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 >>>>> * >>>>> >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Mon Feb 3 09:26:18 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Mon, 3 Feb 2014 09:26:18 +0100 Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: <52EEA2E7.5050009@gmail.com> References: <52EEA2E7.5050009@gmail.com> Message-ID: <1391415978.4825.7.camel@sekic1152.release> These are opinions, not facts. The benefits of Make are mentioned below. Here is a look at a drawback: http://miller.emu.id.au/pmiller/books/rmch/ (Recursive Make Considered Harmful) bengt On Sun, 2014-02-02 at 21:56 +0200, Zachary Kessin wrote: > > > 1. The tools are, well frankly, garbage. Sorry, in 2014 to be > > pushed back to coding with VIM and makefiles is primitive. > > Rebar is crytptic and just the pet project of a guy on GIT. > > Compared to Gradle, Maven and even (though I don't care for > > it much) SBT, rebar is ... lacking. I want to spend time > > working on my business logic, not fighting tools. There are > > plugins for eclipse and intellij but they have minimal > > functionality and i keep reverting back to vim. > Actually the tools are quite good, you are just looking at the wrong > set of tools. Yes Make in one form or another has been around forever > (1977) but to my mind that means that it actually does the job well, > and has had all the weird bugs found and pushed out years ago. It is > quite good at doing the minimal amount of work that is required at any > given time and will use as many cores as you have around. Rebar has a > few weird issues but is generally pretty good. > > Most of the hard core Erlang folks seem to use Emacs and many of the > tools are setup to work there. > > That being said there are a group of tools that you probably haven't > even looked at that are quite powerful and are worth your time, these > include Dialyzer, Wrangler, PropEr or QuickCheck, and Concuerror. > > If you define tools to be a fancy IDE then Erlang is lacking, but if > you define tools as stuff that helps you ship code then Erlang has > some amazing tools. > > -- > Zachary Kessin > Mostly Erlang Podcast > Skype: zachkessin > Twitter: @zkessin > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From dmkolesnikov@REDACTED Mon Feb 3 09:45:26 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Mon, 3 Feb 2014 10:45:26 +0200 Subject: [erlang-questions] what does suspend do ? In-Reply-To: References: Message-ID: Hello, This is suspension for garbage collection. - Dmitry On 02 Feb 2014, at 23:38, Philip Clarke wrote: > Hi, > > I have been doing some profiling using fprof on my system. > Using fprof I see that ets:select is calling suspend. > > I suspect that I have found a bottleneck where I have an ets table with write_concurrency defined and there are lots of processes doing reads thousands of times per second. But my question is more general to profiling. > > What exactly does suspend do ? I suspect it may be an indication that my process has run out of reductions and is preempted by the scheduler ? > Could anyone confirm please ? > > Just in case it is useful, here is the relevant part of my fprof analysis file. > > {[{{mymodule,get_values,1}, 6, 2992.735, 31.313}], > { {ets,select,2}, 6, 2992.735, 31.313}, % > [{suspend, 92, 1707.908, 0.000}, > {{lists,sum,1}, 6, 1251.655, 0.709}, > {garbage_collect, 7, 1.859, 1.859}]}. > > {[{{ets,select,2}, 6, 1251.655, 0.709}], > { {lists,sum,1}, 6, 1251.655, 0.709}, % > [{{lists,sum,2}, 6, 1250.946, 0.047}]}. > > {[{{lists,sum,1}, 6, 1250.946, 0.047}, > {{lists,sum,2}, 20647, 0.000, 1241.206}], > { {lists,sum,2}, 20653, 1250.946, 1241.253}, % > [{suspend, 10, 9.693, 0.000}, > {{lists,sum,2}, 20647, 0.000, 1241.206}]}. > > Thanks > Philip > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From zkessin@REDACTED Mon Feb 3 09:49:08 2014 From: zkessin@REDACTED (Zachary Kessin) Date: Mon, 03 Feb 2014 10:49:08 +0200 Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: <1391415978.4825.7.camel@sekic1152.release> References: <52EEA2E7.5050009@gmail.com> <1391415978.4825.7.camel@sekic1152.release> Message-ID: <52EF5804.9080107@gmail.com> I tend to use Rebar, it works and I don't think it has ever taken me more than 5 minutes to setup rebar for a project. (Generally I just copy my rebar config file from a different project). As for the paper you mentioned I will admit I am not enough of an expert on make to comment on the issues it raises, or even if they are still true 15 years later. Rebar is also not that cryptic, it is just a file with some erlang terms in it that define the build. --Zach On 2/3/14, 10:26 AM, Bengt Kleberg wrote: > These are opinions, not facts. > > The benefits of Make are mentioned below. Here is a look at a drawback: > http://miller.emu.id.au/pmiller/books/rmch/ > (Recursive Make Considered Harmful) > > > bengt > > On Sun, 2014-02-02 at 21:56 +0200, Zachary Kessin wrote: >>> 1. The tools are, well frankly, garbage. Sorry, in 2014 to be >>> pushed back to coding with VIM and makefiles is primitive. >>> Rebar is crytptic and just the pet project of a guy on GIT. >>> Compared to Gradle, Maven and even (though I don't care for >>> it much) SBT, rebar is ... lacking. I want to spend time >>> working on my business logic, not fighting tools. There are >>> plugins for eclipse and intellij but they have minimal >>> functionality and i keep reverting back to vim. >> Actually the tools are quite good, you are just looking at the wrong >> set of tools. Yes Make in one form or another has been around forever >> (1977) but to my mind that means that it actually does the job well, >> and has had all the weird bugs found and pushed out years ago. It is >> quite good at doing the minimal amount of work that is required at any >> given time and will use as many cores as you have around. Rebar has a >> few weird issues but is generally pretty good. >> >> Most of the hard core Erlang folks seem to use Emacs and many of the >> tools are setup to work there. >> >> That being said there are a group of tools that you probably haven't >> even looked at that are quite powerful and are worth your time, these >> include Dialyzer, Wrangler, PropEr or QuickCheck, and Concuerror. >> >> If you define tools to be a fancy IDE then Erlang is lacking, but if >> you define tools as stuff that helps you ship code then Erlang has >> some amazing tools. >> >> -- >> Zachary Kessin >> Mostly Erlang Podcast >> Skype: zachkessin >> Twitter: @zkessin >> _______________________________________________ >> 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 -- Zachary Kessin Mostly Erlang Podcast Skype: zachkessin Twitter: @zkessin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: zkessin.vcf Type: text/x-vcard Size: 264 bytes Desc: not available URL: From ingela.andin@REDACTED Mon Feb 3 09:56:02 2014 From: ingela.andin@REDACTED (Ingela Andin) Date: Mon, 3 Feb 2014 09:56:02 +0100 Subject: [erlang-questions] DTLS client/server In-Reply-To: References: <-2812677860635758685@unknownmsgid> Message-ID: Hi Pablo! Progress of DTLS will be included in R17, I will however not have time enough to make it a fully supported feature. Other high priority things have competed with it for my time. I am working with it at the moment but time flies and the only thing I can promise is that there will be some more pieces in place. Regards Ingela Erlang/OTP Team - Ericsson AB 2014-02-02 pablo platt : > I didn't see anything about DTLS in the R17 RC1 release notes. > Will this be included in the final R17 release? > > > On Thu, Dec 12, 2013 at 3:17 PM, pablo platt wrote: > >> Thanks >> >> >> On Thu, Dec 12, 2013 at 2:55 PM, Ingela Andin wrote: >> >>> >>> Hi! >>> >>> 2013/12/12 pablo platt >>> >>>> Hi >>>> >>>> >>>> Will it be possible to use DTLS for DTLS-SRTP when it will be released? >>>> http://tools.ietf.org/html/rfc5764 >>>> >>>> >>>> DTLS-SRTP requires sending use_srtp in extended hello and exchanging SRTP keys. >>>> >>>> DTLS-SRTP also requires that RTP and STUN messages are forwarded to the app. >>>> >>>> >>>> >>>> Will there be support out of the box for such extension? >>>> >>>> >>> No this will not work out of the box. But once DTLS is in place it could >>> be a fairly easy user contribution ;) >>> >>> >>> Regards Ingela Erlang/OTP Team Ericssson AB >>> >>> >>>> >>>> On Fri, Oct 18, 2013 at 5:07 AM, pablo platt wrote: >>>> >>>>> A preview in a few weeks will be great. >>>>> >>>>> Thanks >>>>> >>>>> >>>>> On Fri, Oct 18, 2013 at 12:12 AM, Ingela Andin >>>> > wrote: >>>>> >>>>>> Hi! >>>>>> >>>>>> >>>>>> 2013/10/17 pablo platt >>>>>> >>>>>>> Is there a chance for release preview of DTLS before the R17 release >>>>>>> on February? >>>>>>> >>>>>>> >>>>>> Alas, I still do not have anything releasable that is runnable. I >>>>>> have had to work with some other stuff in between. >>>>>> But I think previews can be possible. I have a rather large step in >>>>>> the pipeline that I probably can release in a few weeks >>>>>> as it then can be merged to maint. This step will include some code >>>>>> from Andreas that implements basic stuff. But >>>>>> the internal structure of the code is quite different and the API is >>>>>> not totally set yet. >>>>>> >>>>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Mon Feb 3 10:01:21 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Mon, 3 Feb 2014 10:01:21 +0100 Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: <2AF9E186-6684-4787-8368-6E019C8113C8@cs.otago.ac.nz> References: <89DAA09F-64B0-4565-A73C-784B5E8EB4C6@feuerlabs.com> <8883B14026CD4CB38E71BEB9DFE5BF67@srstrong.com> <2AF9E186-6684-4787-8368-6E019C8113C8@cs.otago.ac.nz> Message-ID: Hello Richard, Thanks for the long and interesting answer. TL;DR: There's a lot of fine semantics regarding the things at stake here and I'm not arguing that "graphical beats textual", but that "'graphical' appeals to different parts of the brain than 'textual' and which one works better for an individual is a personal matter". I don't believe there is something intrinsic to 'graphical' that makes it bad. Also, "graphical" is not the same as "having a GUI"; I got them mixed up too in my message. A program can have a good (or bad) user interface regardless of this interface being textual or graphical. On Mon, Feb 3, 2014 at 3:08 AM, Richard A. O'Keefe wrote: > > On 31/01/2014, at 11:40 PM, Vlad Dumitrescu wrote: > > Why does automating something have anything to do with that thing being > textual or graphical? vim runs in a console, but also as gVim (graphical). > The same can be said about emacs and XEmacs. > > gVim is still a textual interface. > XEmacs is not "Emacs using X11" but a fork of Emacs; > the latest stable release of XEmacs appears to be 2009. > > The fact that emacs uses a GUI does not make the thing that > is being edited "graphical". > Here is the first semantic point: you are absolutely right. Then why call Eclipse "graphical"? It still edits text! If the thing with Eclipse is that it has a lot of graphical ornaments around the text, then my point was that Emacs has toolbars and status bars and such too. The amount of it can be trimmed in Eclipse and it can be increased in Emacs, if one wants to. > The (first edition of) the book that explains how to *use* > Eclipse is bigger than the listing of my emacs-like editor > PLUS the listing of the C compiler I originally used to > write it PLUS the listing of the UNIX kernel it originally > ran on PLUS the manuals. > I'm not sure why that would be relevant. Just because Eclipse might be difficult to understand/explain doesn't make all possible similar tools bad. Also, I don't know how large a book about using emacs is/would be (at the same detail level as in the Eclipse book). There's a lot of functionality in both, it has to take some place to describe and explain it. [[As an aside, books nowadays are way too thick and I believe it's because authors get payed in proportion with the number of pages. I may be wrong, but books were thinner and more to the point in the past. So maybe they aren't a good comparison item.]] > In my opinion, what a programming environment brings to the table is > multiple ways to look at the code, to quickly see what is going on. > > I think Joe agrees with you, except that Joe places a heavy > emphasis on > - something that has precise definition > - explicit and straightforward semantics > - that he can understand. > I think so too. Only the last point has the potential to signify that pure text beats a GUI, and it's a personal thing. > Or in Erlang (and doing some wishful thinking), wouldn't it be useful if > one could actually _see_ in real time the network of processes in a node, > how they are linked/monitoring each other, how they communicate, which ones > are growing large or seem deadlocked, zoom out for a bird-eye view or in > for details? > > > Let's take a form of diagram that is widely agreed > to be straightforward. A box represents a class; > an arrow from X to Y represents "X inherits directly > from Y". > > I have a Smalltalk system of my own. When you compile > a program, it spits out a "map" file, which includes a > list of classes at the top using indentation to show > inheritance. This can be turned automatically into a ".dot" > file for display using GraphViz or any of several other > programs that read ".dot" files. > > The one that's actually _useful_ is the text file, because > there doesn't seem to be any good way to display nearly > 800 classes in one diagram. Heck, the collection hierarchy > alone has 176 classes; try getting just _that_ in one display. > And there is a good way to display this hierarchy in textual form on a single page? That would be the equivalent... There are tools that can show large diagrams in a way that works much better (for example, by using a hyperbolic mapping where the current item is large and in the middle and the less related other items are to it, the smaller and more to the periphery they are. Panning in the diagram brings other items in focus). There's a lot of research on this, see for example http://www.visualcomplexity.com/vc/. Just because the simplest diagrams aren't good enough doesn't mean that any diagram is bad. > Now, visualising the process structure would be nice, except > that someone *did* this using UbiGraph and the result was > as dismaying as it was cool. Erlang lets you have *lots* of > processes, and that's just what doesn't suit a diagram. > See above. The breakthrough would be to be able to detect which processes are important to show and when. See for example https://code.google.com/p/gource/ on how a project's VCS history can be visualized -- imagine a similar thing where the focus is on processes that are active, they are kept in the middle and larger, the links light up when messages are sent, all dynamically as one goes back and forth in time.. > As a user, one shouldn't need to understand how the environment works (you > think Eclipse is complex, I think Emacs is; it's a matter of what we are > accustomed to). > > We can measure the complexity of an environment in itself > without reference to what we are accustomed to. > The text editor I normally use takes less than 15 000 raw > lines of C (less than 8 000 SLOC); executables and help > files come to 173 kB on disc. > That _has_ to be less complex than Emacs.app, which is > 161 MB on disc. > And that _has_ to be less complex than Eclipse for C/C++ > where the smallest download seems to be 141 MB compressed. > And the really annoying thing is that the actual text > editing support in Eclipse is far more limited than that > in the 173 kB program! > Why is the size or complexity of the code relevant? I can have short and simple code that implements a program with very weird commands and interaction patterns. I can have a huge complex program with a nice and understandable or discoverable way to use it. > Of course, this changes when I need to do something that the > environment doesn't support. But even so, there is always the fallback of > doing it as if no IDE was available, so I don't think that having an IDE > can make things worse. > > In one sense, what makes things worse is indeed not having > an IDE, but _having_ to have an IDE. > I understand what you mean. If I use Emacs and I customize it with fancy commands that help my workflow and become dependent on them -- isn't that the same problem as with depending on Eclipse? Emacs _is_ an IDE. One can choose only to use the editor, but so can one do with Eclipse too. > In another sense, using an IDE can indeed result in worse > code. <...snip...> An IDE _can_ do this, and in fact Smalltalk > systems are especially good at that. But the more screen > space the IDE takes up for _being_ an IDE (in Smalltalk, > about 50%; in Eclipse, it's worse) the harder it is to actually > do this. > Again, many IDEs have ways to remove the toolbars and menus while editing (usually called zen-mode). One doesn't have to have all the blinking windows open at the same time. Soem IDEs are better at that than others, of course. > Knuth could do this amazing thing with TeX (practically no bugs) for all > the reasons you stated, but also because he set very strict boundaries for > what TeX is and can do. Basically, he not only froze the specifications, he > set them in stone. If that would have been enough, would there have been a > need for XeTeX, pdfTeX, laTeX and other tools that extend and improve the > basic TeX? > > Yes. And those things were only made *possible* by the existence of > the stable core. > What I mean is that implementing a bug-free core is much easier than implementing all the functionality on top of it just as bug-free. There might be other pieces of code around that are just as bug-free, only that people didn't extract them as standalone entities. For example, core LISP interpreters can fall in that category - I bet it's been a long time since emacs had a bug related to the interpreter proper. > Would it have been possible to keep the bug levels as low if these > extensions and improvements had been part of the core TeX? > > You are right: that is an excellent argument for keeping a small > stable core. But weren't you just arguing _against_ that? > No I'm not. I just don't think that the reason that TeX is practically bug-free has anything to do with it being a backend tool. > For some reason text interfaces seem to be better specified and > more stable than GUI interfaces. Every release of Word I have > to relearn the interface; while I have LaTeX documents from 1984 > I can still use. > Unfortunately, new and shiny GUIs are used as selling points for new versions of a software, partly to hide the fact that an upgrade might not be necessary at all. This is not an inherent problem for the GUIs, I can imagine that if Emacs was a Microsoft product, we would have new spelling on the commands on each version :-) best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangud@REDACTED Mon Feb 3 10:29:12 2014 From: dangud@REDACTED (Dan Gudmundsson) Date: Mon, 3 Feb 2014 10:29:12 +0100 Subject: [erlang-questions] getting "Can not link the wx driver, wx will NOT be useable" making 17.0-rc1 In-Reply-To: References: Message-ID: Take a look in lib/wx/config.log Search for the failed message and try to figure out why it failed. Is this with the newest xcode and clang? /Dan On Mon, Feb 3, 2014 at 1:17 AM, Charles Irvine wrote: > On os-x 10.9.1 I'm getting "Can not link the wx driver, wx will NOT be > useable" when making Erlang 17.0-rc1. > > I downloaded the latest version of wxWidgets from github and built it with: > > $ ./configure --with-cocoa --prefix=/usr/local > --with-macosx-version-min=10.9 --disable-shared > $ make > $ sudo make install > > I downloaded the R17 of Erlang from Github and built it with: > > $ ./configure --enable-shared-zlib > $ make > $ sudo make install > > Upon invocation of "configure": I got: > > checking if we can link wxwidgets programs... no > configure: WARNING: Can not link wx program are all developer packages > installed? > > > Upon make invocation, I got: > > Can not link the wx driver, wx will NOT be useable > > So now my GUI components won't be working. Any help is greatly > appreciated!! > > Chuck > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Mon Feb 3 10:35:21 2014 From: ulf@REDACTED (Ulf Wiger) Date: Mon, 3 Feb 2014 10:35:21 +0100 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: <20140201201412.GA48745@ferdmbp.local> Message-ID: <91F3AC2C-7959-47B1-8825-9D08888AD132@feuerlabs.com> On 1 Feb 2014, at 21:29, Max Lapshin wrote: > Fred, your ideas are right, of course, but you forget that right now records doesn't have any infrastructure for code upgrade. > > The only way is to make {state, Field1, Field2, ....} mapping by hands. Actually, there *is* a framework for this, although I can?t say if anyone actually uses it. See e.g. https://github.com/uwiger/parse_trans/blob/master/examples/test_exprecs_vsns.erl -module(test_exprecs_vsns). -export([f/0]). -export_records([r]). -compile({parse_transform, exprecs}). -record(r, {a,b,c}). -record(r__1_2, {a,b}). -record(r__1_1, {a,b,c,d}). f() -> io:fwrite("'#info-r'(fields) -> ~p~n", ['#info-r'(fields)]), io:fwrite("'#info-r__1_1'(fields)' -> ~p (not exported)~n", ['#info-r__1_1'(fields)]), io:fwrite("'#info-r__1_2'(fields)' -> ~p (not exported)~n", ['#info-r__1_2'(fields)]), io:fwrite("'#convert-'(\"1_1\", {r,1,2,3,4}) -> ~p~n", ['#convert-'("1_1", {r,1,2,3,4})]), io:fwrite("'#convert-'(\"1_2\", {r,1,2}) -> ~p~n", ['#convert-'("1_2", {r,1,2})]). ** Test run: Eshell V5.9.2 (abort with ^G) 1> c(test_exprecs_vsns). {ok,test_exprecs_vsns} 2> test_exprecs_vsns:f(). '#info-r'(fields) -> [a,b,c] '#info-r__1_1'(fields)' -> [a,b,c,d] (not exported) '#info-r__1_2'(fields)' -> [a,b] (not exported) '#convert-'("1_1", {r,1,2,3,4}) -> {{r,1,2,3},[{d,4}]} '#convert-'("1_2", {r,1,2}) -> {{r,1,2,undefined},[]} ok ** Explanation: The record ?r? is ?exported?, meaning that exprecs generates accessor functions for it. Old versions of the record definition are kept, but renamed as r__1_1, r__1_2, etc., respectively. When old versions are present, exprecs will generate a ?#convert-?(OldVsn, Record) function that returns a record on the current format, together with a list of element that are no longer present. Note that it doesn?t _convert_ elements; it simply maps them by name. I probably should document this... BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From vances@REDACTED Mon Feb 3 11:02:17 2014 From: vances@REDACTED (Vance Shipley) Date: Mon, 3 Feb 2014 15:32:17 +0530 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: <20140201201412.GA48745@ferdmbp.local> <1391288021.12937.78129741.0FD3BB73@webmail.messagingengine.com> Message-ID: <20140203100217.GA357@aluminium.local> On Sat, Feb 01, 2014 at 10:20:34PM +0100, Jos? Valim wrote: } I don't think maps are meant to replace *all* use case of records. I'm trying to imagine how mnesia would work without records. -- -Vance From vladdu55@REDACTED Mon Feb 3 11:06:25 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Mon, 3 Feb 2014 11:06:25 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <52ED386D.9020802@gmail.com> References: <20140201053053.GA9640@k2r.org> <52EC8ED8.9010504@gmail.com> <52ECE1F8.8070208@ninenines.eu> <52ED386D.9020802@gmail.com> Message-ID: Hi! I assume that the philosophy behind the version numbering of OTP hasn't changed, only the format of it. However, a specification of how to interpret version changes would be very helpful. As Anthony stated, it is important how similar it is to semantic versioning. * Will version changes in applications propagate to the OTP level, like for semantic versioning? * If yes above: OTP contains besides the core applications even tools and libs that are loosely related. Will all applications be treated the same, for example will a new major version of, say, eunit require updating the major version of OTP? * Will parts beyond the normal x.y.z be treated like in SemVer? I.e. version X-rc1 sorts before X. Will there be "+something" parts too? best regards, Vlad On Sat, Feb 1, 2014 at 7:09 PM, Ignas Vy?niauskas wrote: > First of all, excited to hear about the RC! > > Anyway, I agree with everyone that the version numbering change is a bit > fishy. > > As already mentioned, this is a major backwards incompatible change for > everything that tries to parse the release version. > Secondly, as Anthony pointed out, it is indeed not Semantic Versioning > at all if it's anything like "17.0-rc1". > > Perhaps a middle ground solution would be to e.g. stick with something > like. > > R[A|B]-- > > with, say the and parts being optional. > > In that way you can increment the versions using semantic versioning, > but still stay as backwards compatible as possible (e.g. simple parsers > that parse based on lexicographic order or only look at the major > version will stay happy). > > -- > Ignas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Mon Feb 3 11:32:47 2014 From: ulf@REDACTED (Ulf Wiger) Date: Mon, 3 Feb 2014 11:32:47 +0100 Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: References: <89DAA09F-64B0-4565-A73C-784B5E8EB4C6@feuerlabs.com> <8883B14026CD4CB38E71BEB9DFE5BF67@srstrong.com> <2AF9E186-6684-4787-8368-6E019C8113C8@cs.otago.ac.nz> Message-ID: <557A846C-F621-44E7-80FB-F67D39C17BF2@feuerlabs.com> On 3 Feb 2014, at 10:01, Vlad Dumitrescu wrote: > There are tools that can show large diagrams in a way that works much better (for example, by using a hyperbolic mapping where the current item is large and in the middle and the less related other items are to it, the smaller and more to the periphery they are. Panning in the diagram brings other items in focus). There's a lot of research on this, see for example http://www.visualcomplexity.com/vc/. Just because the simplest diagrams aren't good enough doesn't mean that any diagram is bad. I think this is the crux of the matter. It all comes down to abstractions, and also whether textual abstractions and graphical abstractions complement each other. As an Erlang programmer, I got involved in the discussion about using graphical tools to aid Erlang development already in 1996. I was by no means the first: people had already been experimenting with Erlang and SDL. The finding with SDL was that it maps easily to Erlang, but didn?t add that much value, as Erlang-as-text had roughly the same, if not greater, abstraction power. The question I was asked to answer was how we could use UML tools for Erlang development. The conclusion was that we shouldn?t use them at all, since the ones we studied at the time mainly helped with automating the production of OO-specific boilerplate, which lacked a counterpart in Erlang. The things that would have been nice to visualize in Erlang, the UML tools could not help with. What they did bring that developers did *not* need, was the need to understand which parts of the visual model were useful and which should be avoided, and how to translate back and forth between different abstractions. Some years later, I found myself in the same kind of debate (it never really ended), but regarding another modeling tool. Surprisingly that time, the expert that the company sent to convince me turned out to be a closet Erlang fan, and agreed with me that the ?modeling language? actually had - at best - comparable expressive power to Erlang, but sufficiently different that using the tool would require an unnecessary lateral move, translating modeling code to Erlang that could have been written just as concisely in Erlang to begin with. In one of my previous jobs, I was later asked to participate in a debate about modeling. Joe and I were to represent the ?anti-modeling side?. We were both perplexed, since we didn?t view ourselves as anti-modeling at all, but rather argued that we do *a great deal* of modeling - just not using a graphical modeling tool, and specifically not using UML. As an example of what I viewed as powerful modeling in textual form, I went through an example from Conal Eliot?s FRAN [1], a handful of lines of Haskell code that described how to take a 3D model of a teapot, replicate the pot and animate each with individual parameters. I can?t say that it drove my point home, but I still think it was a good example. The key point about models is not that they are graphical, but that they are well-defined and appropriate - and actually aid understanding rather than confound it! I also used as an example a page from a manual on Executable UML, where a one-line expression was modeled graphically - a diagram that took up the entire page! The one-liner was easy to understand; the graphical model was practically impossible to understand. Basically, the manual ilustrated that the pictorial language of UML, albeit both verbose and redundant, did not have the expressive power to concisely describe the semantics in question, so a text-based language was used to fill the gap. I have nothing against this. What I object to is the insistence to present the graphical model anyway, even if it brought nothing to the table but confusion. Of course, had the purpose been to illustrate this very fact, it would have been helpful. Perhaps it was and I just missed it? Of course, nothing either Joe or I said ended the debate - nor did anything the other side said. BR, Ulf W [1] http://haskell.cs.yale.edu/wp-content/uploads/2011/02/icfp97.pdf Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dch@REDACTED Mon Feb 3 11:38:53 2014 From: dch@REDACTED (Dave Cottlehuber) Date: Mon, 3 Feb 2014 11:38:53 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: <20140201053053.GA9640@k2r.org> <52EC8ED8.9010504@gmail.com> <52ECE1F8.8070208@ninenines.eu> <52ED386D.9020802@gmail.com> Message-ID: It's great to see an improved version scheme being implemented, and I'm also interested in the responses to questions already raised. Can the OTP team make it standard/easy to extract these numbers externally for compatibility testing, whether in rebar, erlang.mk or other Makefile/autoconf based systems? I'm sure I am not the only person who hacked stuff up for this! Something like `erlang:system_info(compat_rel).` would be ideal - yielding a simple string representation of the number, and removing the need to run sed or whatever to tidy it up afterwards. If this is not available (e.g. in older OTP releases) we can fall back on `erlang:system_info(otp_release).` which provides all the info but needs subsequent parsing. A+ Dave From vladdu55@REDACTED Mon Feb 3 12:19:12 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Mon, 3 Feb 2014 12:19:12 +0100 Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: <557A846C-F621-44E7-80FB-F67D39C17BF2@feuerlabs.com> References: <89DAA09F-64B0-4565-A73C-784B5E8EB4C6@feuerlabs.com> <8883B14026CD4CB38E71BEB9DFE5BF67@srstrong.com> <2AF9E186-6684-4787-8368-6E019C8113C8@cs.otago.ac.nz> <557A846C-F621-44E7-80FB-F67D39C17BF2@feuerlabs.com> Message-ID: On Mon, Feb 3, 2014 at 11:32 AM, Ulf Wiger wrote: > > On 3 Feb 2014, at 10:01, Vlad Dumitrescu wrote: > > There are tools that can show large diagrams in a way that works much > better (for example, by using a hyperbolic mapping where the current item > is large and in the middle and the less related other items are to it, the > smaller and more to the periphery they are. Panning in the diagram brings > other items in focus). There's a lot of research on this, see for example > http://www.visualcomplexity.com/vc/. Just because the simplest diagrams > aren't good enough doesn't mean that any diagram is bad. > > > I think this is the crux of the matter. > > It all comes down to abstractions, and also whether textual abstractions > and graphical abstractions complement each other. > > Yes, indeed. And also a matter of what purpose the respective model/representation has. As a matter of fact, one of the most useful examples of using a diagram in my experience relies on it being messy! For a complex system where one wants to see the dependencies between the different classes/packages/objects/modules, the impact that the resulting messy diagram is huge -- as is the comparison with a cleaner one after the necessary refactorings. This is something that would be much more difficult to represent as text. When color coding a text, for example syntax highlighting or just emphasizing the functions in a module, that isn't pure text anymore. Nor is it really graphics either. Now if I annotate text with arrows, where do we get? > As an Erlang programmer, I got involved in the discussion about using > graphical tools to aid Erlang development already in 1996. I was by no > means the first: people had already been experimenting with Erlang and SDL. > The finding with SDL was that it maps easily to Erlang, but didn't add that > much value, as Erlang-as-text had roughly the same, if not greater, > abstraction power. > > Erlang programs where SDL would apply are naturally structured in small units around each process. One has to make a special effort to write spaghetti-like code, where the textual cross-references are hidden and obfuscated and where SDL would help a little more (because it trims irrelevant noise). For other languages, the norm leans towards spaghetti, but that's not the tools' fault. They just fill an ecological niche. I assume that the language creators didn't make it weird on purpose, so that they can sell expensive tools later... but that's another discussion. regards, Vlad > The question I was asked to answer was how we could use UML tools for > Erlang development. The conclusion was that we shouldn't use them at all, > since the ones we studied at the time mainly helped with automating the > production of OO-specific boilerplate, which lacked a counterpart in > Erlang. The things that would have been nice to visualize in Erlang, the > UML tools could not help with. What they did bring that developers did > *not* need, was the need to understand which parts of the visual model were > useful and which should be avoided, and how to translate back and forth > between different abstractions. > > Some years later, I found myself in the same kind of debate (it never > really ended), but regarding another modeling tool. Surprisingly that time, > the expert that the company sent to convince me turned out to be a closet > Erlang fan, and agreed with me that the 'modeling language' actually had - > at best - comparable expressive power to Erlang, but sufficiently different > that using the tool would require an unnecessary lateral move, translating > modeling code to Erlang that could have been written just as concisely in > Erlang to begin with. > > In one of my previous jobs, I was later asked to participate in a debate > about modeling. Joe and I were to represent the "anti-modeling side". We > were both perplexed, since we didn't view ourselves as anti-modeling at > all, but rather argued that we do *a great deal* of modeling - just not > using a graphical modeling tool, and specifically not using UML. > > As an example of what I viewed as powerful modeling in textual form, I > went through an example from Conal Eliot's FRAN [1], a handful of lines of > Haskell code that described how to take a 3D model of a teapot, replicate > the pot and animate each with individual parameters. I can't say that it > drove my point home, but I still think it was a good example. The key point > about models is not that they are graphical, but that they are well-defined > and appropriate - and actually aid understanding rather than confound it! > > I also used as an example a page from a manual on Executable UML, where a > one-line expression was modeled graphically - a diagram that took up the > entire page! The one-liner was easy to understand; the graphical model was > practically impossible to understand. Basically, the manual ilustrated that > the pictorial language of UML, albeit both verbose and redundant, did not > have the expressive power to concisely describe the semantics in question, > so a text-based language was used to fill the gap. > > I have nothing against this. What I object to is the insistence to present > the graphical model anyway, even if it brought nothing to the table but > confusion. Of course, had the purpose been to illustrate this very fact, it > would have been helpful. Perhaps it was and I just missed it? > > Of course, nothing either Joe or I said ended the debate - nor did > anything the other side said. > > BR, > Ulf W > > [1] http://haskell.cs.yale.edu/wp-content/uploads/2011/02/icfp97.pdf > > Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. > http://feuerlabs.com > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Mon Feb 3 13:29:56 2014 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 3 Feb 2014 13:29:56 +0100 Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: <557A846C-F621-44E7-80FB-F67D39C17BF2@feuerlabs.com> References: <89DAA09F-64B0-4565-A73C-784B5E8EB4C6@feuerlabs.com> <8883B14026CD4CB38E71BEB9DFE5BF67@srstrong.com> <2AF9E186-6684-4787-8368-6E019C8113C8@cs.otago.ac.nz> <557A846C-F621-44E7-80FB-F67D39C17BF2@feuerlabs.com> Message-ID: On Mon, Feb 3, 2014 at 11:32 AM, Ulf Wiger wrote: > > On 3 Feb 2014, at 10:01, Vlad Dumitrescu wrote: > > There are tools that can show large diagrams in a way that works much > better (for example, by using a hyperbolic mapping where the current item > is large and in the middle and the less related other items are to it, the > smaller and more to the periphery they are. Panning in the diagram brings > other items in focus). There's a lot of research on this, see for example > http://www.visualcomplexity.com/vc/. Just because the simplest diagrams > aren't good enough doesn't mean that any diagram is bad. > > > I think this is the crux of the matter. > > It all comes down to abstractions, and also whether textual abstractions > and graphical abstractions complement each other. > > As an Erlang programmer, I got involved in the discussion about using > graphical tools to aid Erlang development already in 1996. I was by no > means the first: people had already been experimenting with Erlang and SDL. > The finding with SDL was that it maps easily to Erlang, but didn't add that > much value, as Erlang-as-text had roughly the same, if not greater, > abstraction power. > > The question I was asked to answer was how we could use UML tools for > Erlang development. The conclusion was that we shouldn't use them at all, > since the ones we studied at the time mainly helped with automating the > production of OO-specific boilerplate, which lacked a counterpart in > Erlang. The things that would have been nice to visualize in Erlang, the > UML tools could not help with. What they did bring that developers did > *not* need, was the need to understand which parts of the visual model were > useful and which should be avoided, and how to translate back and forth > between different abstractions. > > Some years later, I found myself in the same kind of debate (it never > really ended), but regarding another modeling tool. Surprisingly that time, > the expert that the company sent to convince me turned out to be a closet > Erlang fan, and agreed with me that the 'modeling language' actually had - > at best - comparable expressive power to Erlang, but sufficiently different > that using the tool would require an unnecessary lateral move, translating > modeling code to Erlang that could have been written just as concisely in > Erlang to begin with. > > In one of my previous jobs, I was later asked to participate in a debate > about modeling. Joe and I were to represent the "anti-modeling side". We > were both perplexed, since we didn't view ourselves as anti-modeling at > all, but rather argued that we do *a great deal* of modeling - just not > using a graphical modeling tool, and specifically not using UML. > I remember it well. The strange things was the almost uniform acceptance of the idea that models had to manipulated with some kind of GUI interface and have a graphical interface. I'd always viewed type descriptions as models - and UML as a set of abstract types - but this view was not popular. Text models are incredibly powerful. Maxwell's equations describe classical electrodynamic in four textual equations. In some domains pictures are great - show me a photo of a rose, a plan of house, or a set of equations describing the motions of the planets. No one descriptive method is best. /Joe > > As an example of what I viewed as powerful modeling in textual form, I > went through an example from Conal Eliot's FRAN [1], a handful of lines of > Haskell code that described how to take a 3D model of a teapot, replicate > the pot and animate each with individual parameters. I can't say that it > drove my point home, but I still think it was a good example. The key point > about models is not that they are graphical, but that they are well-defined > and appropriate - and actually aid understanding rather than confound it! > > I also used as an example a page from a manual on Executable UML, where a > one-line expression was modeled graphically - a diagram that took up the > entire page! The one-liner was easy to understand; the graphical model was > practically impossible to understand. Basically, the manual ilustrated that > the pictorial language of UML, albeit both verbose and redundant, did not > have the expressive power to concisely describe the semantics in question, > so a text-based language was used to fill the gap. > > I have nothing against this. What I object to is the insistence to present > the graphical model anyway, even if it brought nothing to the table but > confusion. Of course, had the purpose been to illustrate this very fact, it > would have been helpful. Perhaps it was and I just missed it? > > Of course, nothing either Joe or I said ended the debate - nor did > anything the other side said. > > BR, > Ulf W > > [1] http://haskell.cs.yale.edu/wp-content/uploads/2011/02/icfp97.pdf > > 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 watson.timothy@REDACTED Mon Feb 3 13:33:38 2014 From: watson.timothy@REDACTED (Tim Watson) Date: Mon, 3 Feb 2014 12:33:38 +0000 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <91F3AC2C-7959-47B1-8825-9D08888AD132@feuerlabs.com> References: <20140201201412.GA48745@ferdmbp.local> <91F3AC2C-7959-47B1-8825-9D08888AD132@feuerlabs.com> Message-ID: <1AD92EB8-A303-4BE5-B081-C8E69CB8A5F8@gmail.com> On 3 Feb 2014, at 09:35, Ulf Wiger wrote: > Actually, there *is* a framework for this, although I can?t say if anyone actually uses it. I do! :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Mon Feb 3 13:39:15 2014 From: ulf@REDACTED (Ulf Wiger) Date: Mon, 3 Feb 2014 13:39:15 +0100 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <1AD92EB8-A303-4BE5-B081-C8E69CB8A5F8@gmail.com> References: <20140201201412.GA48745@ferdmbp.local> <91F3AC2C-7959-47B1-8825-9D08888AD132@feuerlabs.com> <1AD92EB8-A303-4BE5-B081-C8E69CB8A5F8@gmail.com> Message-ID: <686CF86E-D32E-4F36-8F66-BF7870B4F4E6@feuerlabs.com> On 3 Feb 2014, at 13:33, Tim Watson wrote: > On 3 Feb 2014, at 09:35, Ulf Wiger wrote: >> Actually, there *is* a framework for this, although I can?t say if anyone actually uses it. > > I do! :) Holy cow - a user! I am impressed. :) BR, Ulf W (I guess I really have to document it now?) Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From karol.urbanski@REDACTED Mon Feb 3 13:44:03 2014 From: karol.urbanski@REDACTED (Karol Urbanski) Date: Mon, 3 Feb 2014 13:44:03 +0100 Subject: [erlang-questions] "erlang-src" package upgrade breaks "syntax_tools" and rebar builds In-Reply-To: References: Message-ID: <20140203124402.GA653@dex.erlang-solutions.com> On Sat, Feb 01, 2014 at 02:27:22PM +0000, Roger Lipscombe wrote: > "The esl-erlang package is a file containg the complete installation: > it includes the Erlang/OTP platform and all of its applications. The > erlang package is a frontend to a number of smaller packages. > Currently we support both erlang and esl-erlang." > > I've just done another "apt-get update; apt-get upgrade", and there's > a whole heap of new packages (1:16.b.3-3), which appear to have fixed > the problem; so it looks like I got caught mid-push, or the version > number got messed up earlier. > > Either way, it all seems good now. > > Thanks, > Roger. Hi, we had a small mixup with the version numbers due to rushing the patch release. I'm glad to hear it works fine now, and sorry for the inconvenience! Best regards, Karol Urbanski From watson.timothy@REDACTED Mon Feb 3 14:24:46 2014 From: watson.timothy@REDACTED (Tim Watson) Date: Mon, 3 Feb 2014 13:24:46 +0000 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <686CF86E-D32E-4F36-8F66-BF7870B4F4E6@feuerlabs.com> References: <20140201201412.GA48745@ferdmbp.local> <91F3AC2C-7959-47B1-8825-9D08888AD132@feuerlabs.com> <1AD92EB8-A303-4BE5-B081-C8E69CB8A5F8@gmail.com> <686CF86E-D32E-4F36-8F66-BF7870B4F4E6@feuerlabs.com> Message-ID: <5C87E40A-FF30-433C-AB0C-0832561A37CF@gmail.com> On 3 Feb 2014, at 12:39, Ulf Wiger wrote: > Holy cow - a user! > Hahahahaha! :D From vladdu55@REDACTED Mon Feb 3 14:44:28 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Mon, 3 Feb 2014 14:44:28 +0100 Subject: [erlang-questions] printed maps look confusing Message-ID: Hi! The default format for printing maps puts no space after the comma, but only around the =>. The result looks confusing to me. #{2 => 3,4 => 5} 3 and 4 look more related than 2 and 3 or 4 and 5. Fixing this is a bit more job than adding a space, unless one wants to add them to lists and tuples too. Removing the spaces around the arrow doesn't look too nice either. I can write a patch, but what is the best solution? regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Mon Feb 3 14:58:49 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 03 Feb 2014 14:58:49 +0100 Subject: [erlang-questions] printed maps look confusing In-Reply-To: References: Message-ID: <52EFA099.7020204@ninenines.eu> Removing the spaces doesn't work at all. Example: #{<<"hello">>=><<"bye">>} Adding a space after the comma is OK but when pretty printing over lines of 80 characters it's going to make things a lot worse. The current solution sounds best to me. Just gotta get used to it. On 02/03/2014 02:44 PM, Vlad Dumitrescu wrote: > Hi! > > The default format for printing maps puts no space after the comma, but > only around the =>. The result looks confusing to me. > > #{2 => 3,4 => 5} > > 3 and 4 look more related than 2 and 3 or 4 and 5. > > Fixing this is a bit more job than adding a space, unless one wants to > add them to lists and tuples too. Removing the spaces around the arrow > doesn't look too nice either. > > I can write a patch, but what is the best solution? > > regards, > Vlad > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From egil@REDACTED Mon Feb 3 15:06:19 2014 From: egil@REDACTED (=?UTF-8?B?QmrDtnJuLUVnaWwgRGFobGJlcmc=?=) Date: Mon, 3 Feb 2014 15:06:19 +0100 Subject: [erlang-questions] printed maps look confusing In-Reply-To: <52EFA099.7020204@ninenines.eu> References: <52EFA099.7020204@ninenines.eu> Message-ID: <52EFA25B.6060900@erlang.org> On 2014-02-03 14:58, Lo?c Hoguin wrote: > Removing the spaces doesn't work at all. Example: > > #{<<"hello">>=><<"bye">>} > > Adding a space after the comma is OK but when pretty printing over > lines of 80 characters it's going to make things a lot worse. > > The current solution sounds best to me. Just gotta get used to it. The current behaviour mimics records pretty-printing: Eshell V6.0 (abort with ^G) 1> rr(file). [file_descriptor,file_info] 2> file:read_file_info("README.md"). {ok,#file_info{size = 3026,type = regular, access = read_write, atime = {{2014,1,28},{15,17,52}}, mtime = {{2013,12,17},{16,23,55}}, ctime = {{2013,12,17},{16,23,55}}, mode = 33204,links = 1,major_device = 64515, minor_device = 0,inode = 927942,uid = 573,gid = 10}} // Bj?rn-Egil > > On 02/03/2014 02:44 PM, Vlad Dumitrescu wrote: >> Hi! >> >> The default format for printing maps puts no space after the comma, but >> only around the =>. The result looks confusing to me. >> >> #{2 => 3,4 => 5} >> >> 3 and 4 look more related than 2 and 3 or 4 and 5. >> >> Fixing this is a bit more job than adding a space, unless one wants to >> add them to lists and tuples too. Removing the spaces around the arrow >> doesn't look too nice either. >> >> I can write a patch, but what is the best solution? >> >> regards, >> Vlad >> >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > From vladdu55@REDACTED Mon Feb 3 15:08:29 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Mon, 3 Feb 2014 15:08:29 +0100 Subject: [erlang-questions] printed maps look confusing In-Reply-To: <52EFA099.7020204@ninenines.eu> References: <52EFA099.7020204@ninenines.eu> Message-ID: You're right I forgot about binaries. [[ should we use guillemets for binaries? ?"hello"? :-) That would even shorten the output a bit ]] I'm a little worried about how the output in large logs. @Bj?rn-Egil: I don't use pretty printing of records, so I missed that connection. I would probably have reacted to that too. Anyway, maybe it's not a big deal. regards, Vlad On Mon, Feb 3, 2014 at 2:58 PM, Lo?c Hoguin wrote: > Removing the spaces doesn't work at all. Example: > > #{<<"hello">>=><<"bye">>} > > Adding a space after the comma is OK but when pretty printing over lines > of 80 characters it's going to make things a lot worse. > > The current solution sounds best to me. Just gotta get used to it. > > > On 02/03/2014 02:44 PM, Vlad Dumitrescu wrote: > >> Hi! >> >> The default format for printing maps puts no space after the comma, but >> only around the =>. The result looks confusing to me. >> >> #{2 => 3,4 => 5} >> >> 3 and 4 look more related than 2 and 3 or 4 and 5. >> >> Fixing this is a bit more job than adding a space, unless one wants to >> add them to lists and tuples too. Removing the spaces around the arrow >> doesn't look too nice either. >> >> I can write a patch, but what is the best solution? >> >> regards, >> Vlad >> >> >> >> >> >> _______________________________________________ >> 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 max.lapshin@REDACTED Mon Feb 3 15:11:01 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 3 Feb 2014 18:11:01 +0400 Subject: [erlang-questions] printed maps look confusing In-Reply-To: References: <52EFA099.7020204@ninenines.eu> Message-ID: It is a very bad thing to use for pretty-print letters that you cannot use in copy-paste. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Mon Feb 3 15:15:46 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Mon, 3 Feb 2014 15:15:46 +0100 Subject: [erlang-questions] printed maps look confusing In-Reply-To: References: <52EFA099.7020204@ninenines.eu> Message-ID: Yes, I hope you noticed the smilie. If guillemets could have been accessed from keyboards, they would be useful. /Vlad On Mon, Feb 3, 2014 at 3:11 PM, Max Lapshin wrote: > It is a very bad thing to use for pretty-print letters that you cannot use > in copy-paste. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidnwelton@REDACTED Mon Feb 3 15:41:38 2014 From: davidnwelton@REDACTED (David Welton) Date: Mon, 3 Feb 2014 15:41:38 +0100 Subject: [erlang-questions] Tracing traffic between nodes Message-ID: Hi, After a bit of muddling around with the dbg man page and application, I don't see an easy way to accomplish what I would like to accomplish: trace all messages between two nodes - everything that they send back and forth to one another, but not internally. Any ideas? Thank you, -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From bengt.kleberg@REDACTED Mon Feb 3 15:50:49 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Mon, 3 Feb 2014 15:50:49 +0100 Subject: [erlang-questions] Tracing traffic between nodes In-Reply-To: References: Message-ID: <1391439049.4825.34.camel@sekic1152.release> Greetings, These are opinions, not facts. Please look at www.erlang.org/doc/man/ttb.html since you have a distributed system. It might not do what you want, but it should fit your needs better than dbg. bengt a On Mon, 2014-02-03 at 15:41 +0100, David Welton wrote: > Hi, > > After a bit of muddling around with the dbg man page and application, > I don't see an easy way to accomplish what I would like to accomplish: > trace all messages between two nodes - everything that they send back > and forth to one another, but not internally. > > Any ideas? > > Thank you, From ph@REDACTED Mon Feb 3 15:57:15 2014 From: ph@REDACTED (Pieter Hintjens) Date: Mon, 3 Feb 2014 15:57:15 +0100 Subject: [erlang-questions] 0MQ libraries In-Reply-To: References: <52EE54E5.6000608@mansionfamily.plus.com> Message-ID: Hi Joe, Our use of the GPLv3 has often confused and annoyed people who haven't really understood how standards development works (or fails to work). It is not negotiable, nor is it going to change, by my very deliberate design. If you want a full explanation, it's here: http://www.digistan.org/text:rationale However to suggest or believe that the copyright license on the RFC affects implementations is false. (You can affect implementations via patent or trademark licenses, however. The GPLv3 is neither of these). > In their wisdom ISOC do not license RFCs - but they retain a copyright. On the contrary, the ISOC page you point to has a long and detailed license. One of its provisions is "you may not fork this spec". That's a vulnerability I'm not happy with. Forking is essential, as is remixability. All specs must be licensed in one way or another, just like any creative work, otherwise you cannot share them freely. Lack of a license means "standard copyright" which means "cannot share". The text is copyrighted by its various contributors, and licensed under the GPLv3. This means: if you make a derived work of the text you must publish that derived work under GPLv3. Is an implementation derived? No, of course it is not. We're speaking of copyright law. There is no copyright on knowledge or information, only the creative expression of it. There's no legal link between a spec and the implementation unless one resorts to patent law, or trademark law (e.g. "Bluetooth" is licensed to stacks that pass the test suites.) If you copied large parts of the spec into e.g. another spec, or a book, or to another site, then you would have a derived work. There are other share-alike licenses used for texts. I used the GPLv3. It could have been cc-by-sa-nc. That would still affect only the written spec and not implementations. The policy is explained at http://rfc.zeromq.org/main:intellectual-property-policy. If you read the source code of an implementation and use that to make a new one, you may be copying, or not. If you copy parts of the code, you must have a license, or be the owner. If you are just "inspired", that is fine. It comes down to convincing a judge you did or did not copy parts of the code. The spec is _irrelevant_ to this issue. Please don't blame the RFC license for that confusion. There's one addition, which is that contributors accept the relicensing of RFCs to the IETF. That applies only to texts developed on that website, and not forks (which are licensed purely as GPLv3). Additionally the right side-bar on every RFC says, "Note on use of the GPL: we use this license to cover the specification text itself, not implementations. You can license your own code under any license you wish. If you make derived versions of this specification, you must share them under the GPL. The goal of this is to prevent private extensions of our specifications." We developed this policy in 2007 at Digistan, it was reviewed by standards lawyers, who helped design it, and it has been successful in preventing private forks of our standards. -Pieter On Sun, Feb 2, 2014 at 6:02 PM, Joe Armstrong wrote: > I'm slightly confused here. > > I was thinking of implementing http://rfc.zeromq.org/spec:23 > > The text in RFC says > > This Specification is distributed in the hope that it will be useful, but > WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY > or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for > more details. You should have received a copy of the GNU General Public > License along with this program; > > The words "with this program" do not make sense - there is no program. Just > a spec of > what you see on the wire. How can I receive a copy of a program when there > is no program? > > Then the text is copyrighted and licensed in three different ways. > > Do I have to do a darkroom implementation and swear on the bones of my > dearly lamented Aunty Doreen that I have never read the C++ code on the zero > MQ site? > > I just want to read the spec and implement it. This is presumably why it has > been published. > > RFCs accepted by ISOC are described in > > https://www.rfc-editor.org/copyright.23Jan01.html > > In their wisdom ISOC do not license RFCs - but they retain a copyright. > > I would be very happy to a see a change in the ZMQ RFCs in line with what > ISOC does. > > Cheers > > /Joe > > > > > > > > On Sun, Feb 2, 2014 at 3:23 PM, james wrote: >> >> On 31/01/2014 07:12, Joe Armstrong wrote: >>> >>> Pieter suggest looking at >>> >>> ... >>> >>> https://github.com/zeromq/libzmq/blob/master/tests/test_stream.cpp >>> >>> These implement the wire-line protocol on top of tcp rather than through >>> the >>> 0mz library so its easier to see whats going on. >>> >> Isn't that dangerous if there is a significant difference in the desired >> license? >> >> The zmtp license is more liberal. >> > From mjtruog@REDACTED Mon Feb 3 16:11:29 2014 From: mjtruog@REDACTED (Michael Truog) Date: Mon, 03 Feb 2014 07:11:29 -0800 Subject: [erlang-questions] 0MQ libraries In-Reply-To: References: <52EE54E5.6000608@mansionfamily.plus.com> Message-ID: <52EFB1A1.9070700@gmail.com> On 02/03/2014 06:57 AM, Pieter Hintjens wrote: > We developed this policy in 2007 at Digistan, it was reviewed by > standards lawyers, who helped design it, and it has been successful in > preventing private forks of our standards. Doesn't http://www.crossroads.io/ continue to be a fork of your standards done by one of the original programmers of ZeroMQ? From ph@REDACTED Mon Feb 3 16:13:43 2014 From: ph@REDACTED (Pieter Hintjens) Date: Mon, 3 Feb 2014 16:13:43 +0100 Subject: [erlang-questions] 0MQ libraries In-Reply-To: <52EFB1A1.9070700@gmail.com> References: <52EE54E5.6000608@mansionfamily.plus.com> <52EFB1A1.9070700@gmail.com> Message-ID: Software != RFCs Isn't that clear? Where is that confusion coming from. The libraries are NOT the standards. They do not touch, in copyright terms. There are dozens of stacks that implement ZMTP or something like it. This is irrelevant to the license on the RFCs. The license only affects *derived* works. What am I not explaining here? -Pieter On Mon, Feb 3, 2014 at 4:11 PM, Michael Truog wrote: > On 02/03/2014 06:57 AM, Pieter Hintjens wrote: >> >> We developed this policy in 2007 at Digistan, it was reviewed by >> standards lawyers, who helped design it, and it has been successful in >> preventing private forks of our standards. > > Doesn't http://www.crossroads.io/ continue to be a fork of your standards > done by one of the original programmers of ZeroMQ? > From vances@REDACTED Mon Feb 3 16:15:35 2014 From: vances@REDACTED (Vance Shipley) Date: Mon, 3 Feb 2014 20:45:35 +0530 Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: References: <2AF9E186-6684-4787-8368-6E019C8113C8@cs.otago.ac.nz> <557A846C-F621-44E7-80FB-F67D39C17BF2@feuerlabs.com> Message-ID: <20140203151535.GB357@aluminium.local> On Mon, Feb 03, 2014 at 01:29:56PM +0100, Joe Armstrong wrote: } The strange things was the almost uniform acceptance of the idea that } models had to manipulated with some kind of GUI interface and have a } graphical interface. The staff we onboard from school universally expect to be able to spend almost all of their time with a mouse in their hands, or at least reaching for it quite frequently. They expect the environment to present them with options at any juncture, all they have to do is answer the multiple choice questions correctly. They don't want to have to read too much nor have to search around for things. Everything should be found on the desktop. They have never read a technical book. As someone who started programming on remote Unix systems over 1200 baud modems I have developed a different set of expectations. The first thing I learned was 'man man' and then found everything else by RTFM. As someone else pointed out the fact that 'make' is still with us decades on demonstrates that it solves real world problems quite adequately. The same is true of sed, awk, grep, vim, etc, etc. If modern tools spare you from ever having to learn how to construct command pipelines as part of your workflow are you really better off? However the kids aren't wrong either. There should be progress and maybe workflows based around autotools, make and vim/emacs haven't delivered advancements in pace with the rest of the world (although they work a helluva lot better now than the 90s). It is a reasonable expectation to have contextual help and code visualizations. While I don't find Eclipse or IDEA adding much value for myself there are graphical tools I do want. Real graphical tools. I do a lot of work with communicating finite state machines. I like to see these as state diagrams. Message sequence charts (MSC) are another viewpoint we use a lot. I have over the years developed some techniques to generate these graphical representations from my own Erlang programs. In 2001 I experimented with parsing my modules into Abstract Forms and wrote a program which found the state transitions in gen_fsm behaviours. It output Graphviz DOT files which could then be viewed and manipulated in other tools. OTP ships with the 'et' tool which can create MSCs from executing programs. The 'observer' presents supervision trees on a running system as a directed graph. These are all actual graphical tools which I find add to my understanding of my work in significant ways. Unfortunately these tools are "assembly required". What I would really like, and in fact have been working on lately, is an editable version of the supervision tree and state diagram viewpoints. If I click on the blue box symbol I use for a supervisor I should be able to set it's properties (restart stategy, MaxR, MaxT, etc.) directly. If I double click on it a text editor is opened allowing me to change the code. It should be possible to drag supervisor, gen_server, gen_fsm, etc. objects from the palette onto the canvas and construct a new project quickly as a supervision tree. It would create the project with all of the template modules. I don't see any IDEs doing these sort of things for me in any language, but there are probably some aspects of this someone will hold up. Even so I don't think these are the things the new generation are actually using. Having said all that another observation is that real graphical Service Creation Environment (SCE) type tools have historically never delivered on expectations. The reason for this is that the people whose hopes and dreams were dashed after investing in SCE were under the impression that with a fully graphical environment they wouldn't need programmers. The reality is that even if you take away all the text it's still programming. -- -Vance From ph@REDACTED Mon Feb 3 16:17:12 2014 From: ph@REDACTED (Pieter Hintjens) Date: Mon, 3 Feb 2014 16:17:12 +0100 Subject: [erlang-questions] 0MQ libraries In-Reply-To: References: <52EE54E5.6000608@mansionfamily.plus.com> <52EFB1A1.9070700@gmail.com> Message-ID: Please read http://en.wikipedia.org/wiki/Derivative_work if the distinction between RFCs and their implementations isn't clear. Thanks Pieter On Mon, Feb 3, 2014 at 4:13 PM, Pieter Hintjens wrote: > Software != RFCs > > Isn't that clear? Where is that confusion coming from. The libraries > are NOT the standards. They do not touch, in copyright terms. > > There are dozens of stacks that implement ZMTP or something like it. > This is irrelevant to the license on the RFCs. > > The license only affects *derived* works. > > What am I not explaining here? > > -Pieter > > On Mon, Feb 3, 2014 at 4:11 PM, Michael Truog wrote: >> On 02/03/2014 06:57 AM, Pieter Hintjens wrote: >>> >>> We developed this policy in 2007 at Digistan, it was reviewed by >>> standards lawyers, who helped design it, and it has been successful in >>> preventing private forks of our standards. >> >> Doesn't http://www.crossroads.io/ continue to be a fork of your standards >> done by one of the original programmers of ZeroMQ? >> From ph@REDACTED Mon Feb 3 16:35:27 2014 From: ph@REDACTED (Pieter Hintjens) Date: Mon, 3 Feb 2014 16:35:27 +0100 Subject: [erlang-questions] 0MQ libraries In-Reply-To: References: <52EE54E5.6000608@mansionfamily.plus.com> <52EFB1A1.9070700@gmail.com> Message-ID: Sorry to sound abrupt... I skipped lunch, need to run to the bathroom, and make a cup of tea, so all my emails are turning out kind of feisty. The GPLv3 construct is meant to encourage forking (to allow the fork+merge model of development we're starting to accept as mainstream in software), and to ensure that happens safely. There's zero leakage from the RFC license to the software. Thanks -Pieter From zkessin@REDACTED Mon Feb 3 17:19:40 2014 From: zkessin@REDACTED (Zachary Kessin) Date: Mon, 03 Feb 2014 18:19:40 +0200 Subject: [erlang-questions] Tools was The quest for the perfect programming language for massive concurrency. In-Reply-To: <20140203151535.GB357@aluminium.local> References: <2AF9E186-6684-4787-8368-6E019C8113C8@cs.otago.ac.nz> <557A846C-F621-44E7-80FB-F67D39C17BF2@feuerlabs.com> <20140203151535.GB357@aluminium.local> Message-ID: <52EFC19C.1010004@gmail.com> On 2/3/14, 5:15 PM, Vance Shipley wrote: > I do a lot of work with communicating finite state machines. I like > to see these as state diagrams. Message sequence charts (MSC) are another > viewpoint we use a lot. I have over the years developed some techniques > to generate these graphical representations from my own Erlang programs. > In 2001 I experimented with parsing my modules into Abstract Forms and > wrote a program which found the state transitions in gen_fsm behaviours. > It output Graphviz DOT files which could then be viewed and manipulated > in other tools. OTP ships with the 'et' tool which can create MSCs from > executing programs. The 'observer' presents supervision trees on a > running system as a directed graph. These are all actual graphical tools > which I find add to my understanding of my work in significant ways. > Well this does bring up a good point, if there are tools like this that would be helpful then lets talk about what types of tools people might find useful and how to create them. I like the idea of a tool that can take a gen_fsm and generate a visual diagram of the states and the transforms. Maybe even do something like the Webmachine debugger where you could have something that would plot how a FSM moves threw its states to understand what is going on. Erlang has some great tools, but that is no reason why we can't have more -- Zachary Kessin Mostly Erlang Podcast Skype: zachkessin Twitter: @zkessin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: zkessin.vcf Type: text/x-vcard Size: 264 bytes Desc: not available URL: From davidnwelton@REDACTED Mon Feb 3 17:53:47 2014 From: davidnwelton@REDACTED (David Welton) Date: Mon, 3 Feb 2014 17:53:47 +0100 Subject: [erlang-questions] Tracing traffic between nodes In-Reply-To: <1391439049.4825.34.camel@sekic1152.release> References: <1391439049.4825.34.camel@sekic1152.release> Message-ID: The tricky thing seems to be that - if I'm interpreting things correctly - there is no information on who we have received something from. This looks like it might work with an Erlang remote node: watch(RemoteNode) -> dbg:start(), Self = node(), {ok, _TPid1} = dbg:tracer(process, {fun({trace, _Pid, send, What, {Process, Node}}, _Acc) when Node == Self orelse Node == RemoteNode -> io:format("{~p, ~p} ! ~p~n", [Process, Node, What]); (_, _Acc) -> ok end, []}), {ok, RemoteNode} = dbg:n(RemoteNode), dbg:p(all, [s]). But probably not with a C node. Maybe the best thing is wireshark or something like that, and a bit of code to dump the erlang messages from that... -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From semmler@REDACTED Mon Feb 3 19:20:26 2014 From: semmler@REDACTED (Niklas Semmler) Date: Mon, 3 Feb 2014 18:20:26 +0000 Subject: [erlang-questions] Simple Logging Message-ID: Hi there, What does it take to get a simple logger running? - multiple logfiles - path = "./log/" - log errors, warnings(!) but no progress reports I tried the following configuration: [{sasl, [ {sasl_error_logger, false}, {errlog_type, error}, {error_logger_mf_dir,"./log"}, {error_logger_mf_maxbytes, 10485760}, {error_logger_mf_maxfiles, 2} ]}]. I get errors and progress reports, but no warning or info messages. Stackoverflow says log_mf_h ignores errlog_type. http://stackoverflow.com/questions/5649332/sasl-stores-progress-report-despite-errlog-type-error But I don't find a way to fix this. I know there is the option to write my own gen_event handler, but I don't feel firm enough in Erlang to do that just yet. Existing handlers performed poorly. How can I implement this simple logger? -- Niklas PS: Lager is unfortunately not an option as I have to avoid any unnecessary dependencies. From jesper.louis.andersen@REDACTED Mon Feb 3 21:51:29 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 3 Feb 2014 21:51:29 +0100 Subject: [erlang-questions] Simple Logging In-Reply-To: References: Message-ID: On Mon, Feb 3, 2014 at 7:20 PM, Niklas Semmler wrote: > PS: Lager is unfortunately not an option as I have to avoid any > unnecessary dependencies. You really want lager for this. What is the rationale for avoiding an unnecessary dependency? -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From semmler@REDACTED Mon Feb 3 22:29:08 2014 From: semmler@REDACTED (Niklas Semmler) Date: Mon, 3 Feb 2014 21:29:08 +0000 Subject: [erlang-questions] Simple Logging In-Reply-To: References: Message-ID: <1CF062E5-FF57-4BF1-AAFF-42DC41ECD7F0@kth.se> The code I am working on is supposed to be integrated with a bigger system later on. As far as I know the other system uses native logging. That's why I want to avoid Lager. I would rather work out my own get_event.. -- Niklas On Feb 3, 2014, at 9:51 PM, Jesper Louis Andersen wrote: > On Mon, Feb 3, 2014 at 7:20 PM, Niklas Semmler wrote: > >> PS: Lager is unfortunately not an option as I have to avoid any >> unnecessary dependencies. > > > You really want lager for this. What is the rationale for avoiding an > unnecessary dependency? > > > -- > J. From jesper.louis.andersen@REDACTED Mon Feb 3 22:58:32 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 3 Feb 2014 22:58:32 +0100 Subject: [erlang-questions] Simple Logging In-Reply-To: <1CF062E5-FF57-4BF1-AAFF-42DC41ECD7F0@kth.se> References: <1CF062E5-FF57-4BF1-AAFF-42DC41ECD7F0@kth.se> Message-ID: On Mon, Feb 3, 2014 at 10:29 PM, Niklas Semmler wrote: > The code I am working on is supposed to be integrated with a bigger system > later on. As far as I know the other system uses native logging. I'd use the error_logger framework then. First of all, it is generic and lager as well as the native logger plugs into that framework with a gen_event. Just call error_logger:error_report/1 and friends. It will decouple logging from the rest of the system. For low-level debugging, look into skipping log statements. Go for using 'dbg' instead, since it is often more effective. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Mon Feb 3 23:06:28 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Tue, 4 Feb 2014 00:06:28 +0200 Subject: [erlang-questions] Simple Logging In-Reply-To: <1CF062E5-FF57-4BF1-AAFF-42DC41ECD7F0@kth.se> References: <1CF062E5-FF57-4BF1-AAFF-42DC41ECD7F0@kth.se> Message-ID: <77BDC2DA-33D9-41FD-9F5C-2F6E09767649@gmail.com> Hello, You are looking for +W flag, e.g. erl +W i should make a trick for you. +W w | i Sets the mapping of warning messages for error_logger. Messages sent to the error logger using one of the warning routines can be mapped either to errors (default), warnings (+W w), or info reports (+W i). The current mapping can be retrieved using error_logger:warning_map/0. See error_logger(3) for further information. However, I would still advice to use lagger. It is compatible with error_logger framework and nicely cooperates with legacy code. Long time ago, I?ve passed through your dilemma, as the result. I?ve end-up with lagger. BTW, I am also confused with goldrush dependencies in lager. I guess it is used to manage flow control to std io. - Dmitry On 03 Feb 2014, at 23:29, Niklas Semmler wrote: > The code I am working on is supposed to be integrated with a bigger system later on. As far as I know the other system uses native logging. > > That's why I want to avoid Lager. I would rather work out my own get_event.. > > -- Niklas > > On Feb 3, 2014, at 9:51 PM, Jesper Louis Andersen wrote: > >> On Mon, Feb 3, 2014 at 7:20 PM, Niklas Semmler wrote: >> >>> PS: Lager is unfortunately not an option as I have to avoid any >>> unnecessary dependencies. >> >> >> You really want lager for this. What is the rationale for avoiding an >> unnecessary dependency? >> >> >> -- >> J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Tue Feb 4 01:27:43 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 4 Feb 2014 13:27:43 +1300 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: <52ED626B.6040005@ninenines.eu> Message-ID: <0BE620F3-A447-44D3-B691-C17A7C4C5C87@cs.otago.ac.nz> With respect to losing Dialyzer, one of the design principles behind frames was that you *shouldn't* lose that. (Eventually.) I've already explained why I am disappointed that we're getting maps instead of frames, but in fairness I must say that I think the Dialyzer probably _can_ be extended to cover maps being used in a record-like way. Don't expect it to happen overnight, though. From ok@REDACTED Tue Feb 4 03:22:54 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 4 Feb 2014 15:22:54 +1300 Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: <1391415978.4825.7.camel@sekic1152.release> References: <52EEA2E7.5050009@gmail.com> <1391415978.4825.7.camel@sekic1152.release> Message-ID: <8BA1A397-2B31-4F4E-937C-282C39CF1DE2@cs.otago.ac.nz> On 3/02/2014, at 9:26 PM, Bengt Kleberg wrote: > These are opinions, not facts. > > The benefits of Make are mentioned below. Here is a look at a drawback: > http://miller.emu.id.au/pmiller/books/rmch/ > (Recursive Make Considered Harmful) That's not a drawback of *make*, it's a drawback of *recursive* make (where a Makefile has a whole bunch of cd x; make commands in it). That article actually is very upbeat about Make as such. From ok@REDACTED Tue Feb 4 06:48:32 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 4 Feb 2014 18:48:32 +1300 Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: References: <89DAA09F-64B0-4565-A73C-784B5E8EB4C6@feuerlabs.com> <8883B14026CD4CB38E71BEB9DFE5BF67@srstrong.com> <2AF9E186-6684-4787-8368-6E019C8113C8@cs.otago.ac.nz> Message-ID: On 3/02/2014, at 10:01 PM, Vlad Dumitrescu wrote: > Hello Richard, > TL;DR: There's a lot of fine semantics regarding the things at stake here and I'm not arguing that "graphical beats textual", but that "'graphical' appeals to different parts of the brain than 'textual' and which one works better for an individual is a personal matter". But note that the "personal matter" depends on training and experience also. > I don't believe there is something intrinsic to 'graphical' that makes it bad. There are issues such as - density of relevant information - accessibility of information I have begun using some annotations in my Smalltalk system. Says that this method exists for compatibility with another Smalltalk system. Don't blame ME for the interface. Says that this method exists in order to support the construction of some other METHOD and should not be considered as part of a stable interface. (If METHOD is changed, this might change or go.) Says that this method is semantically a composition of two other methods but done a different way that saves space or time or both or done when the composition is legal but the parts would not be. How does something like UML handle relationships like these? By *textual* annotations on lines. Or it would if UML were good at handling relationships between methods... I've only just begun exploring this space. Already it is clear that some refinement is possible. When I look at other systems, I see A standard things B nonstandard things that seem like a good idea C nonstandard things that I don't really feel any need for, but what the heck D nonstandard things that stink. E useful ideas which badly need redesign. For B and C I need to give credit where it's due. There should be a distinction between B and C. For D, it's hard to annotate something that's not _there_, but I've been feeling the need to have *something* that tools can trivially find to say why a particular class or method is not there. For an example of E, the way that Squeak and Pharo handle joining a bunch of strings inspired me, but it inspired me to do it quite differently. So I want to express a relationship between some methods I do NOT have and some methods I DO have. So now we have relationships like METHOD1 in this system solves the same problem that METHOD2 in SYSTEM2 does but better because REASON. Text? No worries. Pictures? Not so good. What is the reason for the composition? Is it #space (to avoid garbage creation), or #time (to save time), or #legality (e.g. to avoid mutating a collection while iterating over it) or #concurrency or what? Like I said, I've only just begun exploring what I think of as the "discourse structure" of code; I'm sure there is a lot more to be found, and the freedom to think in terms of n-ary relationships rather than binary relations annotated with a <> is important. > Also, "graphical" is not the same as "having a GUI"; I got them mixed up too in my message. A program can have a good (or bad) user interface regardless of this interface being textual or graphical. If I understood him, Joe's point was not so much about how information is displayed to a user but about how accessible it is to lightweight *tools*. If there is an easy to drive programmable interface to the data model, I imagine Joe has no objection if there is a graphical human interface as well for those that want it. Take as an example Microsoft Excel. On Windows, you can control it programmatically using Visual Basic for Applications, or could. You can probably do it through PowerShell, which is pretty capable. In MacOS X, you do it through AppleScript. (You can probably do it through FScript as well.) But I can't get at it the *same* way on both systems. > Here is the first semantic point: you are absolutely right. Then why call Eclipse "graphical"? It still edits text! So, % open -a Eclipse After a l o n g time, I am staring at a window containing a circle containing picture of a desk globe a circle containing a 4-pointed star a circle containing a blue cube, a green pyramid, and an orange ball a circle containing a notebook with a green tick a circle with a piece of ribbon in it. a purple disc with the word "eclipse" over it and a white fuzzy penumbra. Did someone actually think this was *clever*? It turns out these things mean Overview What's new Samples Tutorial Workbench nothing whatever respectively. A picture is sometimes worth 0.001 words. > If the thing with Eclipse is that it has a lot of graphical ornaments around the text, There's Joe's issue and my issue. I think Joe's issue was availability or not of a simple text-based *alternative* that can be used by mortals. From my perspective, Eclipse is about two decimal orders of magnitude harder to use than Emacs. > then my point was that Emacs has toolbars and status bars and such too. No it doesn't, not unless you want it to. Just verified: it uses one line at the bottom for the minibuffer and one line above that for the status line. In an 80 column by 60 line window I can easily spare 2 lines. > The (first edition of) the book that explains how to *use* > Eclipse is bigger than the listing of my emacs-like editor > PLUS the listing of the C compiler I originally used to > write it PLUS the listing of the UNIX kernel it originally > ran on PLUS the manuals. > > I'm not sure why that would be relevant. The relevance is that - Eclipse *looks* dauntingly complex when you sit down in front of it, - when you turn to the reference book for help, it turns out that it really *is* dauntingly complex. Eclipse all by itself is more complex to understand than the *whole* of the software stack I used when doing my PhD, and - it is hard to approach that complexity incrementally because there are *lots* of things you apparently have to do to do anything. I *was* able to learn everything I needed to know about XCode from a book and from the Apple documentation. I'm able to use -- even to extend -- Smalltalk IDEs and I still have fond memories of using and extending Interlisp-D. I was at one time familiar with the sources of three Emacs clones. But Eclipse has utterly defeated me. I am never going to be able to learn it by myself. > Just because Eclipse might be difficult to understand/explain doesn't make all possible similar tools bad. Agreed. I can at least do basic things in NetBeans, but even then, I'd much rather not. > Also, I don't know how large a book about using emacs is/would be (at the same detail level as in the Eclipse book). It's not hard to find out. The Emacs manuals are free. The Emacs user manual is considerably smaller than the Eclipse user book. > There's a lot of functionality in both, it has to take some place to describe and explain it. For me the daunting complexity is not "a lot of functionality", it's the complexity of the interface for *getting started*. > >> In my opinion, what a programming environment brings to the table is multiple ways to look at the code, to quickly see what is going on. > I think Joe agrees with you, except that Joe places a heavy > emphasis on > - something that has precise definition > - explicit and straightforward semantics > - that he can understand. > > I think so too. Only the last point has the potential to signify that pure text beats a GUI, and it's a personal thing. Potential? The question is not the *potential* but the *present actuality*, which is that textual systems _do_ (by and large) have more explicit definitions. Too many GUI designers seem to take the view "It's a GUI. How can it be hard?" > > The one that's actually _useful_ is the text file, because > there doesn't seem to be any good way to display nearly > 800 classes in one diagram. Heck, the collection hierarchy > alone has 176 classes; try getting just _that_ in one display. > > And there is a good way to display this hierarchy in textual form on a single page? That would be the equivalent... No, it's *not* the equivalent. The equivalent of a picture that needs to be scrolled around a large wall is a text file that needs scrolling in one direction only. For a human being. For a program, the important thing is that - it is trivial to generate the picture from the text - but not the other way around. > > There are tools that can show large diagrams in a way that works much better (for example, by using a hyperbolic mapping where the current item is large and in the middle and the less related other items are to it, the smaller and more to the periphery they are. Sorry, that just does not work in this case. The things I need to see together are not close in that sense. > Panning in the diagram brings other items in focus). There's a lot of research on this, see for example http://www.visualcomplexity.com/vc/. Just because the simplest diagrams aren't good enough doesn't mean that any diagram is bad. It doesn't mean that a more complex diagram is any good either. In this case, for my purposes, it isn't. Remember, the goal is not "DISPLAY SOMETHING", it is "EXTRACT INFORMATION FROM SOMETHING". Data visualisation is actually one of my interests. I have seen *way* too many really cute "infographics" that turned out to be incomprehensible or inaccurate. (I have a copy of Gephi and had serious difficulties with its user interface.) There are some superb data visualisations, but it isn't _easy_ to design them. > Now, visualising the process structure would be nice, except > that someone *did* this using UbiGraph and the result was > as dismaying as it was cool. Erlang lets you have *lots* of > processes, and that's just what doesn't suit a diagram. > > See above. The breakthrough would be to be able to detect which processes are important to show and when. Yes, that would be nice. Do you have some idea of how to do that? > See for example https://code.google.com/p/gource/ on how a project's VCS history can be visualized I have seen that before. To me, it's a textbook example of "cute, but what actual GOOD does it do me?" If I want to learn something from version control logs, I'm *not* going to look at a Gource movie, I'm going to analyse the logs in textual form. Not idle chatter. I have a project of my own for which I *have* analysed the logs to spot patterns. Plain old black and white 2D graphs displayed what I had found perfectly well. The trick was to GET ACCESS TO THE DATA in such a way that A SIMPLE PROGRAM CAN PROCESS IT. > -- imagine a similar thing where the focus is on processes that are active, they are kept in the middle and larger, the links light up when messages are sent, all dynamically as one goes back and forth in time.. If it's just like the one I saw a while back using Ubigraph, or if it's like Gource, the answer is that it will be as cute as a basket of kittens in party hats, but won't actually be any use for analysis. I am reminded of a prominent secular theologian (that's one of those strange people who says there is no god THEREFORE let us do religion). My father went to one of his lectures, and afterwards me one of his own students who had also gone. Student. Wasn't X a *wonderful* speaker? Dad. Yes. But what did he *say*? Student. (Silence.) > >> As a user, one shouldn't need to understand how the environment works (you think Eclipse is complex, I think Emacs is; it's a matter of what we are accustomed to). > We can measure the complexity of an environment in itself > without reference to what we are accustomed to. > The text editor I normally use takes less than 15 000 raw > lines of C (less than 8 000 SLOC); executables and help > files come to 173 kB on disc. > That _has_ to be less complex than Emacs.app, which is > 161 MB on disc. > And that _has_ to be less complex than Eclipse for C/C++ > where the smallest download seems to be 141 MB compressed. > And the really annoying thing is that the actual text > editing support in Eclipse is far more limited than that > in the 173 kB program! > > Why is the size or complexity of the code relevant? (a) Because a small program *can't* have as a dauntingly complex an interface as a large one. (b) Because a small program *can't* have as many internal interactions as a large one (the user's mental model of what the program is up to will be less inaccurate). (c) Because a large program will, as a rule, have more bugs than a small one, and the relationship is non-linear. > I can have short and simple code that implements a program with very weird commands and interaction patterns. I can have a huge complex program with a nice and understandable or discoverable way to use it. You *can*, but as a rule you *don't*. >> > I understand what you mean. If I use Emacs and I customize it with fancy commands that help my workflow and become dependent on them -- isn't that the same problem as with depending on Eclipse? No, the question is not "what do *I* depend on" but "what am I requiring *OTHER* people to depend on". > Emacs _is_ an IDE. This really does miss the point, which is that software developed *using* Emacs is textual. If Joe develops something using Emacs, I can read *ALL* of it using TextEdit or pico or whatever. Now I've never succeeded in building anything with Eclipse, but I *can* say that if I build something with XCode, there's information hidden in all sorts of strange places, and I've had serious difficulty importing old projects into a newer XCode. Heck, I've had serious difficulty importing other people's projects into the *same* version of XCode, thanks to important information about the project that was only accessible using the GUI. > > > What I mean is that implementing a bug-free core is much easier than implementing all the functionality on top of it just as bug-free. Agreed, and getting the other functionality on top bug-free pretty much *depends* on there being a small comprehensible core. > No I'm not. I just don't think that the reason that TeX is practically bug-free has anything to do with it being a backend tool. Let's be clear about causality here. I think you are saying NOT BECAUSE(backend(TeX), reliable(TeX)) and I am saying BECAUSE(reliable(TeX), backend(TeX)) Let me put it this way. There was a time when I was seriously considering a move from (La)TeX to another document formatter with simpler cleaner markup. I read the manual cover to cover several times, started playing with it, and found it produced good-looking output. But when I ran lint over it, a lot of the lint warnings turned out to be genuine, and within a day I had found a number of ways to crash it. So I dropped the idea of writing front end scripts to generate input for that processor. For me, BECAUSE(NOT reliable(XXXX), NOT backend(XXXX)) From vladdu55@REDACTED Tue Feb 4 09:04:27 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Tue, 4 Feb 2014 09:04:27 +0100 Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: References: <89DAA09F-64B0-4565-A73C-784B5E8EB4C6@feuerlabs.com> <8883B14026CD4CB38E71BEB9DFE5BF67@srstrong.com> <2AF9E186-6684-4787-8368-6E019C8113C8@cs.otago.ac.nz> Message-ID: Hi Richard, There's a lot of interesting stuff in your post, as always, and most of it I agree 100% but I have this nagging feeling that there's a misunderstanding between us and we're not talking about the same things. In short, the things you enumerate as advantages of a textual program and the drawbacks of the graphical ones aren't all related to the textual/graphical attribute of the program. That Excel can't be scripted in the same language in all environments has nothing to do with it having a GUI. That Eclipse starts with a "welcome" page that can be confusing, that has nothing to do with GUIs either. Of course, if we are comparing (say) Emacs in console mode and Eclipse, then we can pick on this kind of detail. What I tried to compare was what could be done with one or other kind of interface. Most things can be done just as well with either; some things work better with one of them, depending of the way the user's brain is wired: I, for example, have easier to work with images/icons/color coding/visual structure. Others, like you, prefer plain text. Excellent! I'm not bashing textual interfaces just because I happen to have other ways that work better for me in certain cases. Everyone I know draws pen-and-paper diagrams and sketches and charts and finds them useful. If they are useful when drawn by hand, they are useful when drawn by a program. If existing programs are drawing incomprehensible diagrams, it doesn't mean that the right diagram would be just as useless. If more research was done on things that are actually helping people rather than on things that look good on resumes, then I think we would have much better tools. Likewise, if more thought went to creating a GUI that is actually helping people rather than cramming more cool features into that program, then we'd have much better GUIs. These shortcomings are not intrinsic to a kind of tool or program or interface, so I think we should try to keep them apart. best regards, Vlad On Tue, Feb 4, 2014 at 6:48 AM, Richard A. O'Keefe wrote: > > On 3/02/2014, at 10:01 PM, Vlad Dumitrescu wrote: > > > Hello Richard, > > TL;DR: There's a lot of fine semantics regarding the things at stake > here and I'm not arguing that "graphical beats textual", but that > "'graphical' appeals to different parts of the brain than 'textual' and > which one works better for an individual is a personal matter". > > But note that the "personal matter" depends on training and experience > also. > > > I don't believe there is something intrinsic to 'graphical' that makes > it bad. > > There are issues such as > - density of relevant information > - accessibility of information > > I have begun using some annotations in my Smalltalk system. > > > Says that this method exists for compatibility > with another Smalltalk system. Don't blame ME > for the interface. > > > Says that this method exists in order to support > the construction of some other METHOD and should > not be considered as part of a stable interface. > (If METHOD is changed, this might change or go.) > > > Says that this method is semantically a composition > of two other methods but done a different way that > saves space or time or both or done when the > composition is legal but the parts would not be. > > How does something like UML handle relationships like these? > By *textual* annotations on lines. > Or it would if UML were good at handling relationships between > methods... > > I've only just begun exploring this space. Already it is > clear that some refinement is possible. > > > When I look at other systems, I see > A standard things > B nonstandard things that seem like a good idea > C nonstandard things that I don't really feel > any need for, but what the heck > D nonstandard things that stink. > E useful ideas which badly need redesign. > > For B and C I need to give credit where it's due. > There should be a distinction between B and C. > For D, it's hard to annotate something that's not > _there_, but I've been feeling the need to have > *something* that tools can trivially find to say > why a particular class or method is not there. > For an example of E, the way that Squeak and Pharo > handle joining a bunch of strings inspired me, but > it inspired me to do it quite differently. So I want > to express a relationship between some methods I do NOT > have and some methods I DO have. > > So now we have relationships like > METHOD1 in this system solves the same > problem that METHOD2 in SYSTEM2 does > but better because REASON. > Text? No worries. > Pictures? Not so good. > > > > What is the reason for the composition? > Is it #space (to avoid garbage creation), > or #time (to save time), > or #legality (e.g. to avoid mutating a collection > while iterating over it) > or #concurrency > or what? > > Like I said, I've only just begun exploring what I think > of as the "discourse structure" of code; I'm sure there > is a lot more to be found, and > > the freedom to think in terms of n-ary > relationships rather than binary relations > annotated with a <> is important. > > > > Also, "graphical" is not the same as "having a GUI"; I got them mixed up > too in my message. A program can have a good (or bad) user interface > regardless of this interface being textual or graphical. > > If I understood him, Joe's point was not so much about how > information is displayed to a user but about how accessible > it is to lightweight *tools*. If there is an easy to drive > programmable interface to the data model, I imagine Joe > has no objection if there is a graphical human interface as well > for those that want it. > > Take as an example Microsoft Excel. > > On Windows, you can control it programmatically using Visual > Basic for Applications, or could. You can probably do it > through PowerShell, which is pretty capable. In MacOS X, > you do it through AppleScript. (You can probably do it > through FScript as well.) But I can't get at it the *same* > way on both systems. > > > Here is the first semantic point: you are absolutely right. Then why > call Eclipse "graphical"? It still edits text! > > So, > % open -a Eclipse > After a l o n g time, I am staring at a window containing > > a circle containing picture of a desk globe > a circle containing a 4-pointed star > a circle containing a blue cube, a green pyramid, > and an orange ball > a circle containing a notebook with a green tick > a circle with a piece of ribbon in it. > a purple disc with the word "eclipse" over it and > a white fuzzy penumbra. > > Did someone actually think this was *clever*? > > It turns out these things mean > > Overview > What's new > Samples > Tutorial > Workbench > nothing whatever > > respectively. A picture is sometimes worth 0.001 words. > > > If the thing with Eclipse is that it has a lot of graphical ornaments > around the text, > > There's Joe's issue and my issue. > I think Joe's issue was availability or not of a simple text-based > *alternative* that can be used by mortals. > From my perspective, Eclipse is about two decimal orders of > magnitude harder to use than Emacs. > > > then my point was that Emacs has toolbars and status bars and such too. > > No it doesn't, not unless you want it to. > Just verified: it uses one line at the bottom for the minibuffer > and one line above that for the status line. In an 80 column by > 60 line window I can easily spare 2 lines. > > > The (first edition of) the book that explains how to *use* > > Eclipse is bigger than the listing of my emacs-like editor > > PLUS the listing of the C compiler I originally used to > > write it PLUS the listing of the UNIX kernel it originally > > ran on PLUS the manuals. > > > > I'm not sure why that would be relevant. > > The relevance is that > - Eclipse *looks* dauntingly complex when you sit down in > front of it, > - when you turn to the reference book for help, it turns > out that it really *is* dauntingly complex. > Eclipse all by itself is more complex to understand than > the *whole* of the software stack I used when doing my > PhD, and > - it is hard to approach that complexity incrementally > because there are *lots* of things you apparently have > to do to do anything. > > I *was* able to learn everything I needed to know about XCode > from a book and from the Apple documentation. I'm able to > use -- even to extend -- Smalltalk IDEs and I still have > fond memories of using and extending Interlisp-D. I was at > one time familiar with the sources of three Emacs clones. > But Eclipse has utterly defeated me. I am never going to be > able to learn it by myself. > > > Just because Eclipse might be difficult to understand/explain doesn't > make all possible similar tools bad. > > Agreed. I can at least do basic things in NetBeans, but even then, > I'd much rather not. > > > Also, I don't know how large a book about using emacs is/would be (at > the same detail level as in the Eclipse book). > > It's not hard to find out. The Emacs manuals are free. The Emacs > user manual is considerably smaller than the Eclipse user book. > > > There's a lot of functionality in both, it has to take some place to > describe and explain it. > > For me the daunting complexity is not "a lot of functionality", > it's the complexity of the interface for *getting started*. > > > >> In my opinion, what a programming environment brings to the table is > multiple ways to look at the code, to quickly see what is going on. > > I think Joe agrees with you, except that Joe places a heavy > > emphasis on > > - something that has precise definition > > - explicit and straightforward semantics > > - that he can understand. > > > > I think so too. Only the last point has the potential to signify that > pure text beats a GUI, and it's a personal thing. > > Potential? The question is not the *potential* but the > *present actuality*, which is that textual systems _do_ > (by and large) have more explicit definitions. Too many > GUI designers seem to take the view "It's a GUI. How can > it be hard?" > > > > > The one that's actually _useful_ is the text file, because > > there doesn't seem to be any good way to display nearly > > 800 classes in one diagram. Heck, the collection hierarchy > > alone has 176 classes; try getting just _that_ in one display. > > > > And there is a good way to display this hierarchy in textual form on a > single page? That would be the equivalent... > > No, it's *not* the equivalent. The equivalent of a picture > that needs to be scrolled around a large wall is a text file > that needs scrolling in one direction only. For a human > being. For a program, the important thing is that > > - it is trivial to generate the picture from the text > - but not the other way around. > > > > There are tools that can show large diagrams in a way that works much > better (for example, by using a hyperbolic mapping where the current item > is large and in the middle and the less related other items are to it, the > smaller and more to the periphery they are. > > Sorry, that just does not work in this case. The things I need > to see together are not close in that sense. > > > Panning in the diagram brings other items in focus). There's a lot of > research on this, see for example http://www.visualcomplexity.com/vc/. > Just because the simplest diagrams aren't good enough doesn't mean that any > diagram is bad. > > It doesn't mean that a more complex diagram is any good either. > In this case, for my purposes, it isn't. > > Remember, the goal is not "DISPLAY SOMETHING", it is > "EXTRACT INFORMATION FROM SOMETHING". > > Data visualisation is actually one of my interests. > I have seen *way* too many really cute "infographics" > that turned out to be incomprehensible or inaccurate. > (I have a copy of Gephi and had serious difficulties > with its user interface.) > > There are some superb data visualisations, but it isn't > _easy_ to design them. > > > Now, visualising the process structure would be nice, except > > that someone *did* this using UbiGraph and the result was > > as dismaying as it was cool. Erlang lets you have *lots* of > > processes, and that's just what doesn't suit a diagram. > > > > See above. The breakthrough would be to be able to detect which > processes are important to show and when. > > Yes, that would be nice. Do you have some idea of how to do that? > > > See for example https://code.google.com/p/gource/ on how a project's > VCS history can be visualized > > I have seen that before. > To me, it's a textbook example of "cute, but what actual > GOOD does it do me?" > If I want to learn something from version control logs, > I'm *not* going to look at a Gource movie, > I'm going to analyse the logs in textual form. > > Not idle chatter. I have a project of my own for which I > *have* analysed the logs to spot patterns. Plain old > black and white 2D graphs displayed what I had found > perfectly well. The trick was to GET ACCESS TO THE DATA > in such a way that A SIMPLE PROGRAM CAN PROCESS IT. > > > -- imagine a similar thing where the focus is on processes that are > active, they are kept in the middle and larger, the links light up when > messages are sent, all dynamically as one goes back and forth in time.. > > If it's just like the one I saw a while back using Ubigraph, > or if it's like Gource, the answer is that it will be as cute > as a basket of kittens in party hats, but won't actually be > any use for analysis. > > I am reminded of a prominent secular theologian (that's one of > those strange people who says there is no god THEREFORE let us > do religion). My father went to one of his lectures, and > afterwards me one of his own students who had also gone. > Student. Wasn't X a *wonderful* speaker? > Dad. Yes. But what did he *say*? > Student. (Silence.) > > > > >> As a user, one shouldn't need to understand how the environment works > (you think Eclipse is complex, I think Emacs is; it's a matter of what we > are accustomed to). > > We can measure the complexity of an environment in itself > > without reference to what we are accustomed to. > > The text editor I normally use takes less than 15 000 raw > > lines of C (less than 8 000 SLOC); executables and help > > files come to 173 kB on disc. > > That _has_ to be less complex than Emacs.app, which is > > 161 MB on disc. > > And that _has_ to be less complex than Eclipse for C/C++ > > where the smallest download seems to be 141 MB compressed. > > And the really annoying thing is that the actual text > > editing support in Eclipse is far more limited than that > > in the 173 kB program! > > > > Why is the size or complexity of the code relevant? > > (a) Because a small program *can't* have as a dauntingly > complex an interface as a large one. > (b) Because a small program *can't* have as many > internal interactions as a large one (the user's > mental model of what the program is up to will be > less inaccurate). > (c) Because a large program will, as a rule, have more > bugs than a small one, and the relationship is > non-linear. > > > I can have short and simple code that implements a program with very > weird commands and interaction patterns. I can have a huge complex program > with a nice and understandable or discoverable way to use it. > > You *can*, but as a rule you *don't*. > >> > > I understand what you mean. If I use Emacs and I customize it with fancy > commands that help my workflow and become dependent on them -- isn't that > the same problem as with depending on Eclipse? > > No, the question is not "what do *I* depend on" but > "what am I requiring *OTHER* people to depend on". > > > Emacs _is_ an IDE. > > This really does miss the point, which is that software > developed *using* Emacs is textual. If Joe develops something > using Emacs, I can read *ALL* of it using TextEdit or pico or > whatever. > > Now I've never succeeded in building anything with Eclipse, > but I *can* say that if I build something with XCode, there's > information hidden in all sorts of strange places, and I've > had serious difficulty importing old projects into a newer > XCode. Heck, I've had serious difficulty importing other > people's projects into the *same* version of XCode, thanks > to important information about the project that was only > accessible using the GUI. > > > > > > What I mean is that implementing a bug-free core is much easier than > implementing all the functionality on top of it just as bug-free. > > Agreed, and getting the other functionality on top bug-free pretty > much *depends* on there being a small comprehensible core. > > > No I'm not. I just don't think that the reason that TeX is practically > bug-free has anything to do with it being a backend tool. > > Let's be clear about causality here. > I think you are saying > NOT BECAUSE(backend(TeX), reliable(TeX)) > and I am saying > BECAUSE(reliable(TeX), backend(TeX)) > > Let me put it this way. There was a time when I was seriously > considering a move from (La)TeX to another document formatter > with simpler cleaner markup. I read the manual cover to cover > several times, started playing with it, and found it produced > good-looking output. But when I ran lint over it, a lot of the > lint warnings turned out to be genuine, and within a day I had > found a number of ways to crash it. So I dropped the idea of > writing front end scripts to generate input for that processor. > For me, > BECAUSE(NOT reliable(XXXX), NOT backend(XXXX)) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Tue Feb 4 10:28:25 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Tue, 04 Feb 2014 09:28:25 +0000 Subject: [erlang-questions] Meaning of the 'local' option atom in systools:make_script/2 Message-ID: <52F0B2B9.5040605@llaisdy.com> Dear All What is the meaning of the 'local' option atom in systools:make_script/2? My understanding of the erlang documentation [1] is that, if 'local' is given, make_script will find paths to the application directories on the current file system, and it will use those paths in the release script. Nothing is copied into the release directory structure. A release built with 'local' will only be portable to another system if that system has exactly the same applications at exactly the same paths. If I would like the release to be portable, I should omit 'local' and make sure all required applications are in a lib/ directory in the release directory structure. This seems to be more-or-less what "Erlang and OTP in Action" says [2], but "Learn You Some Erlang" seems to say the exact opposite [3]. So my questions are: 1. Do I understand the documentation correctly? 2. If I omit 'local' will make_scripts/2 fetch the required erlang applications and put them in lib/, or must I do that myself? With thanks and best wishes Ivan ** [1] erlang documentation http://www.erlang.org/doc/man/systools.html#make_script-2 In the generated boot script all application directories are structured as App-Vsn/ebin and assumed to be located in $ROOT/lib, where $ROOT is the root directory of the installed release. If the local option is supplied, the actual directories where the applications were found are used instead. This is a useful way to test a generated boot script locally. ** [2] Erlang and OTP in Action (2011) Ch 10. Packaging, services and deployment, p. 250 1> systools:make_script("simple_cache", [local]). ok The local option ... stipulates that absolute paths to all applications are written in the script and boot files --- meaning that if you try to start a system using this boot file, all application code must reside in exactly the same place it did when the boot file was created. The local option is good for testing, but it isn't very portable and may not be suitable for production. Without the local option, the generated script and boot files expect that all applications are located in a directory called lib, pointed out by a system variable $ROOT. This is suitable for a release that you want to be able to install on different host machines that don't necessarily have the same paths. ** [3] Learn You Some Erlang (2013) Ch 21. Release is the Word, p. 340 1> systools:make_script("erlcount-1.0", [local]). ok Here, the local option means that we want the release to be possible to run from anywhere, and not just the current install. -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From erlang@REDACTED Tue Feb 4 10:29:35 2014 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 4 Feb 2014 10:29:35 +0100 Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: References: <89DAA09F-64B0-4565-A73C-784B5E8EB4C6@feuerlabs.com> <8883B14026CD4CB38E71BEB9DFE5BF67@srstrong.com> <2AF9E186-6684-4787-8368-6E019C8113C8@cs.otago.ac.nz> Message-ID: On Tue, Feb 4, 2014 at 9:04 AM, Vlad Dumitrescu wrote: > Hi Richard, > > There's a lot of interesting stuff in your post, as always, and most of it > I agree 100% but I have this nagging feeling that there's a > misunderstanding between us and we're not talking about the same things. > > In short, the things you enumerate as advantages of a textual program and > the drawbacks of the graphical ones aren't all related to the > textual/graphical attribute of the program. That Excel can't be scripted in > the same language in all environments has nothing to do with it having a > GUI. That Eclipse starts with a "welcome" page that can be confusing, that > has nothing to do with GUIs either. > > Of course, if we are comparing (say) Emacs in console mode and Eclipse, > then we can pick on this kind of detail. What I tried to compare was what > could be done with one or other kind of interface. Most things can be done > just as well with either; some things work better with one of them, > depending of the way the user's brain is wired: I, for example, have easier > to work with images/icons/color coding/visual structure. Others, like you, > prefer plain text. Excellent! I'm not bashing textual interfaces just > because I happen to have other ways that work better for me in certain > cases. > > Everyone I know draws pen-and-paper diagrams and sketches and charts and > finds them useful. If they are useful when drawn by hand, they are useful > when drawn by a program. If existing programs are drawing incomprehensible > diagrams, it doesn't mean that the right diagram would be just as useless. > > If more research was done on things that are actually helping people > rather than on things that look good on resumes, then I think we would have > much better tools. Likewise, if more thought went to creating a GUI that is > actually helping people rather than cramming more cool features into that > program, then we'd have much better GUIs. These shortcomings are not > intrinsic to a kind of tool or program or interface, so I think we should > try to keep them apart. > Agree 100% I have a idea of what I'd like - I've been thinking about this for many years I'd like to see two windows. In window one I type my program. There is a single button under the window. The button has an icon of Sherlock Holmes on it. I press the Sherlock button. Sherlock analyses my text fragment comparing it to all the programs in the entire universe that have ever been written - in the second window it says "this program is very similar to ..." or "this is a new idea ..." "did you know that XXX is working on this at this very moment ..." I've experiment with this is several forms - I want to find "the most similar thing to the given thing" - this is an extremely difficult problem. I write code because it is quicker to write the code from scratch than finding out if somebody else has written it. Almost invariably if I can find that somebody else has written some code, it does not do precisely what I want - but a near miss would be good enough. If I could understand it I could modify it to suit my needs. We need mechanisms merge code, but the problem is we don't know where the code is that needs to be merged. If I publish a program, people will cut-and-paste from this code forming new code. Changes made in the cut-and-paste code will not back propagate into the original code. One algorithm I've played with is least-compression-difference. A and B are similar if the size(compress(A)) is almost the same as size(compress(A ++ B)) I guess the similarity detection algorithms and sliding checksums used in rsync would be useful, or Bayesian inference or Latent Dirchlet allocation. I also dislike files and directories. They are totally useless for organizing information. When I've typed my small program into a text box, I have to store it in a file - but what should the file name be, and in which directory? How will I find it again later? As for editors the best I have found is org-mode in emacs - outline editors are great - since they support two levels of abstraction. Editing content, and editing structure. Emacs is great at paragraph editing, but not good at structure editing. I can't easily flip the order of this and the last paragraph. I guess I could write a macro for this, but it would be nice if it did this out of the box. org-mode solves a lot of these problems. One day IDEs might help me think - I think some kind of synergy between a text editor, a search engine and a IRC thingy would be good. IRC is great - if I knew who to talk to and where they hang out. Computers should serve our needs - not like it is today where we serve their needs. /Joe > > best regards, > Vlad > > On Tue, Feb 4, 2014 at 6:48 AM, Richard A. O'Keefe wrote: > >> >> On 3/02/2014, at 10:01 PM, Vlad Dumitrescu wrote: >> >> > Hello Richard, >> > TL;DR: There's a lot of fine semantics regarding the things at stake >> here and I'm not arguing that "graphical beats textual", but that >> "'graphical' appeals to different parts of the brain than 'textual' and >> which one works better for an individual is a personal matter". >> >> But note that the "personal matter" depends on training and experience >> also. >> >> > I don't believe there is something intrinsic to 'graphical' that makes >> it bad. >> >> There are issues such as >> - density of relevant information >> - accessibility of information >> >> I have begun using some annotations in my Smalltalk system. >> >> >> Says that this method exists for compatibility >> with another Smalltalk system. Don't blame ME >> for the interface. >> >> >> Says that this method exists in order to support >> the construction of some other METHOD and should >> not be considered as part of a stable interface. >> (If METHOD is changed, this might change or go.) >> >> >> Says that this method is semantically a composition >> of two other methods but done a different way that >> saves space or time or both or done when the >> composition is legal but the parts would not be. >> >> How does something like UML handle relationships like these? >> By *textual* annotations on lines. >> Or it would if UML were good at handling relationships between >> methods... >> >> I've only just begun exploring this space. Already it is >> clear that some refinement is possible. >> >> >> When I look at other systems, I see >> A standard things >> B nonstandard things that seem like a good idea >> C nonstandard things that I don't really feel >> any need for, but what the heck >> D nonstandard things that stink. >> E useful ideas which badly need redesign. >> >> For B and C I need to give credit where it's due. >> There should be a distinction between B and C. >> For D, it's hard to annotate something that's not >> _there_, but I've been feeling the need to have >> *something* that tools can trivially find to say >> why a particular class or method is not there. >> For an example of E, the way that Squeak and Pharo >> handle joining a bunch of strings inspired me, but >> it inspired me to do it quite differently. So I want >> to express a relationship between some methods I do NOT >> have and some methods I DO have. >> >> So now we have relationships like >> METHOD1 in this system solves the same >> problem that METHOD2 in SYSTEM2 does >> but better because REASON. >> Text? No worries. >> Pictures? Not so good. >> >> >> >> What is the reason for the composition? >> Is it #space (to avoid garbage creation), >> or #time (to save time), >> or #legality (e.g. to avoid mutating a collection >> while iterating over it) >> or #concurrency >> or what? >> >> Like I said, I've only just begun exploring what I think >> of as the "discourse structure" of code; I'm sure there >> is a lot more to be found, and >> >> the freedom to think in terms of n-ary >> relationships rather than binary relations >> annotated with a <> is important. >> >> >> > Also, "graphical" is not the same as "having a GUI"; I got them mixed >> up too in my message. A program can have a good (or bad) user interface >> regardless of this interface being textual or graphical. >> >> If I understood him, Joe's point was not so much about how >> information is displayed to a user but about how accessible >> it is to lightweight *tools*. If there is an easy to drive >> programmable interface to the data model, I imagine Joe >> has no objection if there is a graphical human interface as well >> for those that want it. >> >> Take as an example Microsoft Excel. >> >> On Windows, you can control it programmatically using Visual >> Basic for Applications, or could. You can probably do it >> through PowerShell, which is pretty capable. In MacOS X, >> you do it through AppleScript. (You can probably do it >> through FScript as well.) But I can't get at it the *same* >> way on both systems. >> >> > Here is the first semantic point: you are absolutely right. Then why >> call Eclipse "graphical"? It still edits text! >> >> So, >> % open -a Eclipse >> After a l o n g time, I am staring at a window containing >> >> a circle containing picture of a desk globe >> a circle containing a 4-pointed star >> a circle containing a blue cube, a green pyramid, >> and an orange ball >> a circle containing a notebook with a green tick >> a circle with a piece of ribbon in it. >> a purple disc with the word "eclipse" over it and >> a white fuzzy penumbra. >> >> Did someone actually think this was *clever*? >> >> It turns out these things mean >> >> Overview >> What's new >> Samples >> Tutorial >> Workbench >> nothing whatever >> >> respectively. A picture is sometimes worth 0.001 words. >> >> > If the thing with Eclipse is that it has a lot of graphical ornaments >> around the text, >> >> There's Joe's issue and my issue. >> I think Joe's issue was availability or not of a simple text-based >> *alternative* that can be used by mortals. >> From my perspective, Eclipse is about two decimal orders of >> magnitude harder to use than Emacs. >> >> > then my point was that Emacs has toolbars and status bars and such too. >> >> No it doesn't, not unless you want it to. >> Just verified: it uses one line at the bottom for the minibuffer >> and one line above that for the status line. In an 80 column by >> 60 line window I can easily spare 2 lines. >> >> > The (first edition of) the book that explains how to *use* >> > Eclipse is bigger than the listing of my emacs-like editor >> > PLUS the listing of the C compiler I originally used to >> > write it PLUS the listing of the UNIX kernel it originally >> > ran on PLUS the manuals. >> > >> > I'm not sure why that would be relevant. >> >> The relevance is that >> - Eclipse *looks* dauntingly complex when you sit down in >> front of it, >> - when you turn to the reference book for help, it turns >> out that it really *is* dauntingly complex. >> Eclipse all by itself is more complex to understand than >> the *whole* of the software stack I used when doing my >> PhD, and >> - it is hard to approach that complexity incrementally >> because there are *lots* of things you apparently have >> to do to do anything. >> >> I *was* able to learn everything I needed to know about XCode >> from a book and from the Apple documentation. I'm able to >> use -- even to extend -- Smalltalk IDEs and I still have >> fond memories of using and extending Interlisp-D. I was at >> one time familiar with the sources of three Emacs clones. >> But Eclipse has utterly defeated me. I am never going to be >> able to learn it by myself. >> >> > Just because Eclipse might be difficult to understand/explain doesn't >> make all possible similar tools bad. >> >> Agreed. I can at least do basic things in NetBeans, but even then, >> I'd much rather not. >> >> > Also, I don't know how large a book about using emacs is/would be (at >> the same detail level as in the Eclipse book). >> >> It's not hard to find out. The Emacs manuals are free. The Emacs >> user manual is considerably smaller than the Eclipse user book. >> >> > There's a lot of functionality in both, it has to take some place to >> describe and explain it. >> >> For me the daunting complexity is not "a lot of functionality", >> it's the complexity of the interface for *getting started*. >> > >> >> In my opinion, what a programming environment brings to the table is >> multiple ways to look at the code, to quickly see what is going on. >> > I think Joe agrees with you, except that Joe places a heavy >> > emphasis on >> > - something that has precise definition >> > - explicit and straightforward semantics >> > - that he can understand. >> > >> > I think so too. Only the last point has the potential to signify that >> pure text beats a GUI, and it's a personal thing. >> >> Potential? The question is not the *potential* but the >> *present actuality*, which is that textual systems _do_ >> (by and large) have more explicit definitions. Too many >> GUI designers seem to take the view "It's a GUI. How can >> it be hard?" >> >> > >> > The one that's actually _useful_ is the text file, because >> > there doesn't seem to be any good way to display nearly >> > 800 classes in one diagram. Heck, the collection hierarchy >> > alone has 176 classes; try getting just _that_ in one display. >> > >> > And there is a good way to display this hierarchy in textual form on a >> single page? That would be the equivalent... >> >> No, it's *not* the equivalent. The equivalent of a picture >> that needs to be scrolled around a large wall is a text file >> that needs scrolling in one direction only. For a human >> being. For a program, the important thing is that >> >> - it is trivial to generate the picture from the text >> - but not the other way around. >> > >> > There are tools that can show large diagrams in a way that works much >> better (for example, by using a hyperbolic mapping where the current item >> is large and in the middle and the less related other items are to it, the >> smaller and more to the periphery they are. >> >> Sorry, that just does not work in this case. The things I need >> to see together are not close in that sense. >> >> > Panning in the diagram brings other items in focus). There's a lot of >> research on this, see for example http://www.visualcomplexity.com/vc/. >> Just because the simplest diagrams aren't good enough doesn't mean that any >> diagram is bad. >> >> It doesn't mean that a more complex diagram is any good either. >> In this case, for my purposes, it isn't. >> >> Remember, the goal is not "DISPLAY SOMETHING", it is >> "EXTRACT INFORMATION FROM SOMETHING". >> >> Data visualisation is actually one of my interests. >> I have seen *way* too many really cute "infographics" >> that turned out to be incomprehensible or inaccurate. >> (I have a copy of Gephi and had serious difficulties >> with its user interface.) >> >> There are some superb data visualisations, but it isn't >> _easy_ to design them. >> >> > Now, visualising the process structure would be nice, except >> > that someone *did* this using UbiGraph and the result was >> > as dismaying as it was cool. Erlang lets you have *lots* of >> > processes, and that's just what doesn't suit a diagram. >> > >> > See above. The breakthrough would be to be able to detect which >> processes are important to show and when. >> >> Yes, that would be nice. Do you have some idea of how to do that? >> >> > See for example https://code.google.com/p/gource/ on how a project's >> VCS history can be visualized >> >> I have seen that before. >> To me, it's a textbook example of "cute, but what actual >> GOOD does it do me?" >> If I want to learn something from version control logs, >> I'm *not* going to look at a Gource movie, >> I'm going to analyse the logs in textual form. >> >> Not idle chatter. I have a project of my own for which I >> *have* analysed the logs to spot patterns. Plain old >> black and white 2D graphs displayed what I had found >> perfectly well. The trick was to GET ACCESS TO THE DATA >> in such a way that A SIMPLE PROGRAM CAN PROCESS IT. >> >> > -- imagine a similar thing where the focus is on processes that are >> active, they are kept in the middle and larger, the links light up when >> messages are sent, all dynamically as one goes back and forth in time.. >> >> If it's just like the one I saw a while back using Ubigraph, >> or if it's like Gource, the answer is that it will be as cute >> as a basket of kittens in party hats, but won't actually be >> any use for analysis. >> >> I am reminded of a prominent secular theologian (that's one of >> those strange people who says there is no god THEREFORE let us >> do religion). My father went to one of his lectures, and >> afterwards me one of his own students who had also gone. >> Student. Wasn't X a *wonderful* speaker? >> Dad. Yes. But what did he *say*? >> Student. (Silence.) >> >> > >> >> As a user, one shouldn't need to understand how the environment works >> (you think Eclipse is complex, I think Emacs is; it's a matter of what we >> are accustomed to). >> > We can measure the complexity of an environment in itself >> > without reference to what we are accustomed to. >> > The text editor I normally use takes less than 15 000 raw >> > lines of C (less than 8 000 SLOC); executables and help >> > files come to 173 kB on disc. >> > That _has_ to be less complex than Emacs.app, which is >> > 161 MB on disc. >> > And that _has_ to be less complex than Eclipse for C/C++ >> > where the smallest download seems to be 141 MB compressed. >> > And the really annoying thing is that the actual text >> > editing support in Eclipse is far more limited than that >> > in the 173 kB program! >> > >> > Why is the size or complexity of the code relevant? >> >> (a) Because a small program *can't* have as a dauntingly >> complex an interface as a large one. >> (b) Because a small program *can't* have as many >> internal interactions as a large one (the user's >> mental model of what the program is up to will be >> less inaccurate). >> (c) Because a large program will, as a rule, have more >> bugs than a small one, and the relationship is >> non-linear. >> >> > I can have short and simple code that implements a program with very >> weird commands and interaction patterns. I can have a huge complex program >> with a nice and understandable or discoverable way to use it. >> >> You *can*, but as a rule you *don't*. >> >> >> > I understand what you mean. If I use Emacs and I customize it with >> fancy commands that help my workflow and become dependent on them -- isn't >> that the same problem as with depending on Eclipse? >> >> No, the question is not "what do *I* depend on" but >> "what am I requiring *OTHER* people to depend on". >> >> > Emacs _is_ an IDE. >> >> This really does miss the point, which is that software >> developed *using* Emacs is textual. If Joe develops something >> using Emacs, I can read *ALL* of it using TextEdit or pico or >> whatever. >> >> Now I've never succeeded in building anything with Eclipse, >> but I *can* say that if I build something with XCode, there's >> information hidden in all sorts of strange places, and I've >> had serious difficulty importing old projects into a newer >> XCode. Heck, I've had serious difficulty importing other >> people's projects into the *same* version of XCode, thanks >> to important information about the project that was only >> accessible using the GUI. >> > >> > >> > What I mean is that implementing a bug-free core is much easier than >> implementing all the functionality on top of it just as bug-free. >> >> Agreed, and getting the other functionality on top bug-free pretty >> much *depends* on there being a small comprehensible core. >> >> > No I'm not. I just don't think that the reason that TeX is practically >> bug-free has anything to do with it being a backend tool. >> >> Let's be clear about causality here. >> I think you are saying >> NOT BECAUSE(backend(TeX), reliable(TeX)) >> and I am saying >> BECAUSE(reliable(TeX), backend(TeX)) >> >> Let me put it this way. There was a time when I was seriously >> considering a move from (La)TeX to another document formatter >> with simpler cleaner markup. I read the manual cover to cover >> several times, started playing with it, and found it produced >> good-looking output. But when I ran lint over it, a lot of the >> lint warnings turned out to be genuine, and within a day I had >> found a number of ways to crash it. So I dropped the idea of >> writing front end scripts to generate input for that processor. >> For me, >> BECAUSE(NOT reliable(XXXX), NOT backend(XXXX)) >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Tue Feb 4 10:50:31 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Tue, 4 Feb 2014 10:50:31 +0100 Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: References: <89DAA09F-64B0-4565-A73C-784B5E8EB4C6@feuerlabs.com> <8883B14026CD4CB38E71BEB9DFE5BF67@srstrong.com> <2AF9E186-6684-4787-8368-6E019C8113C8@cs.otago.ac.nz> Message-ID: Hi Joe, On Tue, Feb 4, 2014 at 10:29 AM, Joe Armstrong wrote: > I'd like to see two windows. > > In window one I type my program. There is a single button under the window. > The button has an icon of Sherlock Holmes on it. > > I press the Sherlock button. > > Sherlock analyses my text fragment comparing it to all the programs in the > entire universe > that have ever been written - in the second window it says > "this program is very similar to ..." or "this is a new idea ..." > "did you know that XXX is working on this at this very moment ..." > > I've experiment with this is several forms - I want to find "the most > similar thing to > the given thing" - this is an extremely difficult problem. > Well there is such a thing, kind of. I don't know how well it works in practice. It's called Code Recommenders and they have a database gathered from available repositories of code that is used to suggest what to write next base on what others do after code similar to the one already in the editor. It's Java only and for the kind of code that is needed to write Java UI (repetitive and with a lot of boilerplate) it works ok. For "normal" code it's less useful, of course. > One day IDEs might help me think - I think some kind of synergy between > a text editor, a search engine and a IRC thingy would be good. > Yes, that's the idea. > IRC is great - if I knew who to talk to and where they hang out. > Hmm, so one would advertise topics of interest and get suggestions for matching people and which rooms thay are in? > Computers should serve our needs - not like it is today where we serve > their needs. > I think that very few engineers do this on purpose, but this world's current economy, there is no incentive for a business to make a perfect product that will require no maintenance and will last forever. So we do the least viable thing that gets us on the market and keeps us there. Who cares that in the end the cost and amount of effort are much larger? regards, Vlad /Joe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sedrik@REDACTED Tue Feb 4 10:56:03 2014 From: sedrik@REDACTED (Fredrik Andersson) Date: Tue, 4 Feb 2014 10:56:03 +0100 Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: References: <89DAA09F-64B0-4565-A73C-784B5E8EB4C6@feuerlabs.com> <8883B14026CD4CB38E71BEB9DFE5BF67@srstrong.com> <2AF9E186-6684-4787-8368-6E019C8113C8@cs.otago.ac.nz> Message-ID: This whole search discussion reminded me of http://www.haskell.org/hoogle/which is a search engine for Haskell code that takes type information into consideration as well. Seeing something similar integrated into erldocs would be nice. On Tue, Feb 4, 2014 at 10:50 AM, Vlad Dumitrescu wrote: > Hi Joe, > > On Tue, Feb 4, 2014 at 10:29 AM, Joe Armstrong wrote: > >> I'd like to see two windows. >> >> In window one I type my program. There is a single button under the >> window. >> The button has an icon of Sherlock Holmes on it. >> >> I press the Sherlock button. >> >> Sherlock analyses my text fragment comparing it to all the programs in >> the entire universe >> that have ever been written - in the second window it says >> "this program is very similar to ..." or "this is a new idea ..." >> "did you know that XXX is working on this at this very moment ..." >> >> I've experiment with this is several forms - I want to find "the most >> similar thing to >> the given thing" - this is an extremely difficult problem. >> > > Well there is such a thing, kind of. I don't know how well it works in > practice. It's called Code Recommenders and they have a database gathered > from available repositories of code that is used to suggest what to write > next base on what others do after code similar to the one already in the > editor. It's Java only and for the kind of code that is needed to write > Java UI (repetitive and with a lot of boilerplate) it works ok. For > "normal" code it's less useful, of course. > > >> One day IDEs might help me think - I think some kind of synergy between >> a text editor, a search engine and a IRC thingy would be good. >> > > Yes, that's the idea. > > >> IRC is great - if I knew who to talk to and where they hang out. >> > > Hmm, so one would advertise topics of interest and get suggestions for > matching people and which rooms thay are in? > > >> Computers should serve our needs - not like it is today where we serve >> their needs. >> > > I think that very few engineers do this on purpose, but this world's > current economy, there is no incentive for a business to make a perfect > product that will require no maintenance and will last forever. So we do > the least viable thing that gets us on the market and keeps us there. Who > cares that in the end the cost and amount of effort are much larger? > > regards, > Vlad > > /Joe >> >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Tue Feb 4 11:33:52 2014 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Tue, 4 Feb 2014 11:33:52 +0100 Subject: [erlang-questions] Google Summer of Code 2014 with the BEAM Community Message-ID: Hello everyone, Last year we have created the BEAM Community organization meant to host different projects that run on the Erlang VM. We had 6 students working on different projects during the summer, like Elixir, Disco, Mongoose IM and others. The Google Summer of Code 2014 has just announced they are looking for organizations to participate in this year edition. Historically, Google has given higher preference for umbrella organizations and therefore we will participate this year again! The BEAM Community website for 2014 is online: http://beamcommunity.github.io/ The first step is to gather a set of projects that are interested in taking part of the BEAM Community. So if you run a project in the Erlang VM and you are interested in mentoring a student during the summer, please send me an e-mail! At this stage, all we need is the project name and a list of ideas / proposals for students to work on. You can use the ideas from last year as inspiration / template . We are planning to host 6 projects, the same amount as last year and the deadline for joining us / putting up your list of ideas is 11th February. Google's deadline is 14th february but we need some time to put everything together. The full program timetable can be found online too ! If you have any questions, please feel free to ask. You may also ask projects that took part last year if you are interested on how the program works. I'm looking forward to another great summer! *Jos? Valim www.plataformatec.com.br Founder and Lead Developer* -------------- next part -------------- An HTML attachment was scrubbed... URL: From semmler@REDACTED Tue Feb 4 11:53:21 2014 From: semmler@REDACTED (Niklas Semmler) Date: Tue, 4 Feb 2014 10:53:21 +0000 Subject: [erlang-questions] Simple Logging In-Reply-To: <77BDC2DA-33D9-41FD-9F5C-2F6E09767649@gmail.com> References: <1CF062E5-FF57-4BF1-AAFF-42DC41ECD7F0@kth.se> <77BDC2DA-33D9-41FD-9F5C-2F6E09767649@gmail.com> Message-ID: <18E49F56-6491-4BE3-81FC-310AA90FF92D@kth.se> Hi again, sorry for the confusion previously. I did not use the +W flag. I attached a minimal example below. I did now use the +W flags and got surprising results. Only the first report in the start/0 function is reported. Independent of whether it is a error/warning/info_report. However it's name as appearing in "rb:list()" depend on the flag. For example "+W w" and first line is a "error_report" -> the message is named "warning report" no "+W" and first line is a "info_report" -> the message is named "error report" @Jesper: As you can see I was using the error_logger from the start. Thanks for the dbg reference though. I will read up on it. Is there anything obvious I miss? Is there a problem in my flags and configuration file combination? Thanks for your help so far! -- Niklas --- Example BEGIN --- start() -> io:format("~s~n", [error_logger:warning_map()]), error_logger:error_report("Error"), error_logger:warning_report("Warning"), error_logger:info_report("Info"), erlang:halt(). [{sasl, [ {sasl_error_logger, false}, {errlog_type, error}, {error_logger_mf_dir,"./log"}, {error_logger_mf_maxbytes, 10485760}, {error_logger_mf_maxfiles, 2} ]}]. ERLC_FLAGS=-W ERL_FLAGS=-boot start_sasl -config log.config [+W w i] compile: erlc $(ERLC_FLAGS) foo.erl run: erl $(ERL_FLAGS) foo.beam log: erl $(ERL_FLAGS) -s rb start '[{report_dir,"./log/"}]' --- Example END --- On Feb 3, 2014, at 11:06 PM, Dmitry Kolesnikov wrote: > Hello, > > You are looking for +W flag, e.g. erl +W i should make a trick for you. > > +W w | i > Sets the mapping of warning messages for error_logger. Messages sent to the error logger using one of the warning routines can be mapped either to errors (default), warnings (+W w), or info reports (+W i). The current mapping can be retrieved using error_logger:warning_map/0. See error_logger(3) for further information. > > > However, I would still advice to use lagger. It is compatible with error_logger framework and nicely cooperates with legacy code. Long time ago, I?ve passed through your dilemma, as the result. I?ve end-up with lagger. > > BTW, I am also confused with goldrush dependencies in lager. I guess it is used to manage flow control to std io. > > - Dmitry > > On 03 Feb 2014, at 23:29, Niklas Semmler wrote: > >> The code I am working on is supposed to be integrated with a bigger system later on. As far as I know the other system uses native logging. >> >> That's why I want to avoid Lager. I would rather work out my own get_event.. >> >> -- Niklas >> >> On Feb 3, 2014, at 9:51 PM, Jesper Louis Andersen wrote: >> >>> On Mon, Feb 3, 2014 at 7:20 PM, Niklas Semmler wrote: >>> >>>> PS: Lager is unfortunately not an option as I have to avoid any >>>> unnecessary dependencies. >>> >>> >>> You really want lager for this. What is the rationale for avoiding an >>> unnecessary dependency? >>> >>> >>> -- >>> J. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > From dmkolesnikov@REDACTED Tue Feb 4 12:26:10 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Tue, 4 Feb 2014 13:26:10 +0200 Subject: [erlang-questions] Simple Logging In-Reply-To: <18E49F56-6491-4BE3-81FC-310AA90FF92D@kth.se> References: <1CF062E5-FF57-4BF1-AAFF-42DC41ECD7F0@kth.se> <77BDC2DA-33D9-41FD-9F5C-2F6E09767649@gmail.com> <18E49F56-6491-4BE3-81FC-310AA90FF92D@kth.se> Message-ID: Hello, I think you have multiple issue here: 1. semantic of error_logger:xxx_report(?) requires a list of terms. In your case, ?Error? is handles as list of integer. Probably you should do error_logger:error_report([{tag, ?Error"}]) or similar. 2. erlang:halt immediately terminates the machine. It do not have any chance to flush report to error log. Just put a timeout 1 - 2 sec before halt(). 3. erl $(ERL_FLAGS) foo.beam would not run the file. May be you should erl $(ERL_FLAGS) foo:start(). - Dmitry On 04 Feb 2014, at 12:53, Niklas Semmler wrote: > Hi again, > > sorry for the confusion previously. I did not use the +W flag. I attached a minimal example below. > > I did now use the +W flags and got surprising results. Only the first report in the start/0 function is reported. Independent of whether it is a error/warning/info_report. However it's name as appearing in "rb:list()" depend on the flag. For example > > "+W w" and first line is a "error_report" -> the message is named "warning report" > no "+W" and first line is a "info_report" -> the message is named "error report" > > @Jesper: As you can see I was using the error_logger from the start. Thanks for the dbg reference though. I will read up on it. > > Is there anything obvious I miss? Is there a problem in my flags and configuration file combination? > > Thanks for your help so far! > -- Niklas > > > --- Example BEGIN --- > start() -> > io:format("~s~n", [error_logger:warning_map()]), > error_logger:error_report("Error"), > error_logger:warning_report("Warning"), > error_logger:info_report("Info"), > erlang:halt(). > > [{sasl, [ > {sasl_error_logger, false}, > {errlog_type, error}, > {error_logger_mf_dir,"./log"}, > {error_logger_mf_maxbytes, 10485760}, > {error_logger_mf_maxfiles, 2} > ]}]. > > ERLC_FLAGS=-W > ERL_FLAGS=-boot start_sasl -config log.config [+W w i] > > compile: erlc $(ERLC_FLAGS) foo.erl > run: erl $(ERL_FLAGS) foo.beam > > log: erl $(ERL_FLAGS) -s rb start '[{report_dir,"./log/"}]' > > --- Example END --- > > On Feb 3, 2014, at 11:06 PM, Dmitry Kolesnikov wrote: > >> Hello, >> >> You are looking for +W flag, e.g. erl +W i should make a trick for you. >> >> +W w | i >> Sets the mapping of warning messages for error_logger. Messages sent to the error logger using one of the warning routines can be mapped either to errors (default), warnings (+W w), or info reports (+W i). The current mapping can be retrieved using error_logger:warning_map/0. See error_logger(3) for further information. >> >> >> However, I would still advice to use lagger. It is compatible with error_logger framework and nicely cooperates with legacy code. Long time ago, I?ve passed through your dilemma, as the result. I?ve end-up with lagger. >> >> BTW, I am also confused with goldrush dependencies in lager. I guess it is used to manage flow control to std io. >> >> - Dmitry >> >> On 03 Feb 2014, at 23:29, Niklas Semmler wrote: >> >>> The code I am working on is supposed to be integrated with a bigger system later on. As far as I know the other system uses native logging. >>> >>> That's why I want to avoid Lager. I would rather work out my own get_event.. >>> >>> -- Niklas >>> >>> On Feb 3, 2014, at 9:51 PM, Jesper Louis Andersen wrote: >>> >>>> On Mon, Feb 3, 2014 at 7:20 PM, Niklas Semmler wrote: >>>> >>>>> PS: Lager is unfortunately not an option as I have to avoid any >>>>> unnecessary dependencies. >>>> >>>> >>>> You really want lager for this. What is the rationale for avoiding an >>>> unnecessary dependency? >>>> >>>> >>>> -- >>>> J. >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> > From k.petrauskas@REDACTED Tue Feb 4 12:47:56 2014 From: k.petrauskas@REDACTED (Karolis Petrauskas) Date: Tue, 4 Feb 2014 13:47:56 +0200 Subject: [erlang-questions] "erlang-src" package upgrade breaks "syntax_tools" and rebar builds In-Reply-To: <20140203124402.GA653@dex.erlang-solutions.com> References: <20140203124402.GA653@dex.erlang-solutions.com> Message-ID: Hello, I still have problems using erlang package provided by esl. I am using Kubuntu 13.10 and have the following line in /etc/apt/sources.list.d/erlang-solutions.list: deb http://binaries.erlang-solutions.com/debian saucy contrib When running `sudo apt-get install erlang-src` I'm getting: The following packages have unmet dependencies: erlang-src : Depends: erlang-base (>= 1:16.b.3-3) but 1:16.b.3 is to be installed or erlang-base-hipe (>= 1:16.b.3-3) The command `sudo apt-get install --reinstall erlang-base` installs "erlang-base 1:16.b.3". I have cleaned by apt cache and updated the apt sources. Karolis On Mon, Feb 3, 2014 at 2:44 PM, Karol Urbanski wrote: > On Sat, Feb 01, 2014 at 02:27:22PM +0000, Roger Lipscombe wrote: >> "The esl-erlang package is a file containg the complete installation: >> it includes the Erlang/OTP platform and all of its applications. The >> erlang package is a frontend to a number of smaller packages. >> Currently we support both erlang and esl-erlang." >> >> I've just done another "apt-get update; apt-get upgrade", and there's >> a whole heap of new packages (1:16.b.3-3), which appear to have fixed >> the problem; so it looks like I got caught mid-push, or the version >> number got messed up earlier. >> >> Either way, it all seems good now. >> >> Thanks, >> Roger. > > Hi, > > we had a small mixup with the version numbers due to rushing the patch > release. I'm glad to hear it works fine now, and sorry for the > inconvenience! > > Best regards, > Karol Urbanski > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From carlsson.richard@REDACTED Tue Feb 4 12:54:52 2014 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Tue, 04 Feb 2014 12:54:52 +0100 Subject: [erlang-questions] beta release of merl - metaprogramming in Erlang Message-ID: <52F0D50C.6080700@gmail.com> So, I finally got around to releasing Merl to Github, under an Apache 2 license: https://github.com/richcarl/merl I talked about it two years ago in San Francisco: http://www.youtube.com/watch?v=RA7QcMNBKfg Slides here: http://www.erlang-factory.com/conference/ErlangUserConference2012/speakers/RichardCarlsson See the edoc overview for documentation, and the examples/ subdirectory for example code. Currently missing: I'd like to have a good API for working with a "module" as an ADT, easily adding and removing definitions and querying the current state, and also reading an existing module from file or as an AST in a parse transform. The file "examples/merl_build.erl" is a start, but I don't have time right now to work more on that. Useful sources of inspiration for such an API are https://github.com/yariv/erlyweb/blob/master/src/smerl/smerl.erl and https://github.com/uwiger/parse_trans. /Richard From swetha.2112@REDACTED Tue Feb 4 14:05:05 2014 From: swetha.2112@REDACTED (Swetha Raj) Date: Tue, 4 Feb 2014 18:35:05 +0530 Subject: [erlang-questions] Install Erlang on Solaris11 Message-ID: Hi All, I am trying to install Erlang on Solaris11 and i am getting the below error when i run 'sudo gmake install' test -d /usr/local/bin || /usr/bin/ginstall -c -d /usr/local/bin /usr/bin/ginstall -c -d /usr/local/lib/erlang /usr/bin/ginstall: cannot change permissions of `/usr/local/lib/erlang': No such file or directory gmake: *** [install.dirs] Error 1 bash-4.1# I followed the steps in this post http://www.dev-eth0.de/couchdb-on-opensolaris-part-1-erlang/ but it did not help Can you let me know what could be the issue ?? Thanks, Swetha -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Tue Feb 4 14:33:26 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 4 Feb 2014 05:33:26 -0800 (PST) Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: References: <89DAA09F-64B0-4565-A73C-784B5E8EB4C6@feuerlabs.com> <8883B14026CD4CB38E71BEB9DFE5BF67@srstrong.com> <2AF9E186-6684-4787-8368-6E019C8113C8@cs.otago.ac.nz> Message-ID: <1391520806.51966.YahooMailNeo@web140103.mail.bf1.yahoo.com> Maybe you could start out with a plagiarism detection program, feed it an appropriate corpus of data (like github?) and take it from there.? Best, Thomas On Tuesday, February 4, 2014 10:29 AM, Joe Armstrong wrote: > > > > >On Tue, Feb 4, 2014 at 9:04 AM, Vlad Dumitrescu wrote: > >Hi Richard, >> >> >> >>There's a lot of interesting stuff in your post, as always, and most of it I agree 100% but I have this nagging feeling that there's a misunderstanding between us and we're not talking about the same things.? >> >> >>In short, the things you enumerate as advantages of a textual program and the drawbacks of the graphical ones aren't all related to the textual/graphical attribute of the program. That Excel can't be scripted in the same language in all environments has nothing to do with it having a GUI. That Eclipse starts with a "welcome" page that can be confusing, that has nothing to do with GUIs either.? >> >> >>Of course, if we are comparing (say) Emacs in console mode and Eclipse, then we can pick on this kind of detail. What I tried to compare was what could be done with one or other kind of interface. Most things can be done just as well with either; some things work better with one of them, depending of the way the user's brain is wired: I, for example, have easier to work with images/icons/color coding/visual structure. Others, like you, prefer plain text. Excellent! I'm not bashing textual interfaces just because I happen to have other ways that work better for me in certain cases. >> >> >>Everyone I know draws pen-and-paper diagrams and sketches and charts and finds them useful. If they are useful when drawn by hand, they are useful when drawn by a program. If existing programs are drawing incomprehensible diagrams, it doesn't mean that the right diagram would be just as useless. >> >> >>If more research was done on things that are actually helping people rather than on things that look good on resumes, then I think we would have much better tools. Likewise, if more thought went to creating a GUI that is actually helping people rather than cramming more cool features into that program, then we'd have much better GUIs. These shortcomings are not intrinsic to a kind of tool or program or interface, so I think we should try to keep them apart. >> > > >Agree 100% > > >I have a idea of what I'd like - I've been thinking about this for many years > > >I'd like to see two windows. > > >In window one I type my program. There is a single button under the window. >The button has an icon of Sherlock Holmes on it. > > >I press the Sherlock button. > > >Sherlock analyses my text fragment comparing it to all the programs in the entire universe >that have ever been written - in the second window it says? >"this program is very similar to ..." or "this is a new idea ..."? >"did you know that XXX is working on this at this very moment ..." > > >I've experiment with this is several forms - I want to find "the most similar thing to >the given thing" - this is an extremely difficult problem. > > >I write code because it is quicker to write the code from scratch than finding out >if somebody else has written it. > > >Almost invariably if I can find that somebody else has written some code, it >does not do precisely what I want - but a near miss would be good enough. >If I could understand it I could modify it to suit my needs. > > >We need mechanisms merge code, but the problem is we don't know where the code >is that needs to be merged. > > >If I publish a program, people will cut-and-paste from this code forming new code. >Changes made in the cut-and-paste code will not back propagate into the original code.? > > >One algorithm I've played with is least-compression-difference. > > >A and B are similar if the size(compress(A)) is almost the same as size(compress(A ++ B)) >I guess the similarity detection ?algorithms and sliding checksums used in rsync >would be useful, or Bayesian inference or Latent Dirchlet allocation. > > >I also dislike files and directories. They are totally useless for organizing information. > > >When I've typed my small program into a text box, I have to store it in >a file - but what should the file name be, and in which directory? How >will I find it again later? > > >As for editors the best I have found is org-mode in emacs - outline editors >are great - since they support two levels of abstraction. Editing content, >and editing structure. > > >Emacs is great at paragraph editing, but not good at structure editing. >I can't easily flip the order of this and the last paragraph. I guess I could >write a macro for this, but it would be nice if it did this out of the box. >org-mode solves a lot of these problems. > > >One day IDEs might help me think - I think some kind of synergy between >a text editor, a search engine and a IRC thingy would be good. > > >IRC is great - if I knew who to talk to and where they hang out. > > >Computers should serve our needs - not like it is today where we serve >their needs. > > >/Joe > > > > > > > > > > > > > > > > > > > > > > > > >? > >> >>best regards, >> >>Vlad >> >> >>On Tue, Feb 4, 2014 at 6:48 AM, Richard A. O'Keefe wrote: >> >> >>>On 3/02/2014, at 10:01 PM, Vlad Dumitrescu wrote: >>> >>>> Hello Richard, >>> >>>> TL;DR: There's a lot of fine semantics regarding the things at stake here and I'm not arguing that "graphical beats textual", but that "'graphical' appeals to different parts of the brain than 'textual' and which one works better for an individual is a personal matter". >>> >>>But note that the "personal matter" depends on training and experience >>>also. >>> >>> >>>> I don't believe there is something intrinsic to 'graphical' that makes it bad. >>> >>>There are issues such as >>>?- density of relevant information >>>?- accessibility of information >>> >>>I have begun using some annotations in my Smalltalk system. >>> >>>? ? ? ? >>>? ? ? ? ? ? Says that this method exists for compatibility >>>? ? ? ? ? ? with another Smalltalk system. ?Don't blame ME >>>? ? ? ? ? ? for the interface. >>> >>>? ? ? ? >>>? ? ? ? ? ? Says that this method exists in order to support >>>? ? ? ? ? ? the construction of some other METHOD and should >>>? ? ? ? ? ? not be considered as part of a stable interface. >>>? ? ? ? ? ? (If METHOD is changed, this might change or go.) >>> >>>? ? ? ? >>>? ? ? ? ? ? Says that this method is semantically a composition >>>? ? ? ? ? ? of two other methods but done a different way that >>>? ? ? ? ? ? saves space or time or both or done when the >>>? ? ? ? ? ? composition is legal but the parts would not be. >>> >>>How does something like UML handle relationships like these? >>>By *textual* annotations on lines. >>>Or it would if UML were good at handling relationships between >>>methods... >>> >>>I've only just begun exploring this space. ?Already it is >>>clear that some refinement is possible. >>> >>> >>>? ?When I look at other systems, I see >>>? ? ? ? A standard things >>>? ? ? ? B nonstandard things that seem like a good idea >>>? ? ? ? C nonstandard things that I don't really feel >>>? ? ? ? ? any need for, but what the heck >>>? ? ? ? D nonstandard things that stink. >>>? ? ? ? E useful ideas which badly need redesign. >>> >>>For B and C I need to give credit where it's due. >>>There should be a distinction between B and C. >>>For D, it's hard to annotate something that's not >>>_there_, but I've been feeling the need to have >>>*something* that tools can trivially find to say >>>why a particular class or method is not there. >>>For an example of E, the way that Squeak and Pharo >>>handle joining a bunch of strings inspired me, but >>>it inspired me to do it quite differently. ?So I want >>>to express a relationship between some methods I do NOT >>>have and some methods I DO have. >>> >>>So now we have relationships like >>>? ? ? ? METHOD1 in this system solves the same >>>? ? ? ? problem that METHOD2 in SYSTEM2 does >>>? ? ? ? but better because REASON. >>>Text? ?No worries. >>>Pictures? ?Not so good. >>> >>> >>> >>>What is the reason for the composition? >>>Is it #space (to avoid garbage creation), >>>? ?or #time ?(to save time), >>>? ?or #legality (e.g. to avoid mutating a collection >>>? ? ? ? ? ? ? ? ?while iterating over it) >>>? ?or #concurrency >>>? ?or what? >>> >>>Like I said, I've only just begun exploring what I think >>>of as the "discourse structure" of code; I'm sure there >>>is a lot more to be found, and >>> >>>? ? ? ? the freedom to think in terms of n-ary >>>? ? ? ? relationships rather than binary relations >>>? ? ? ? annotated with a <> is important. >>> >>> >>> >>>> Also, "graphical" is not the same as "having a GUI"; I got them mixed up too in my message. A program can have a good (or bad) user interface regardless of this interface being textual or graphical. >>> >>>If I understood him, Joe's point was not so much about how >>>information is displayed to a user but about how accessible >>>it is to lightweight *tools*. ?If there is an easy to drive >>>programmable interface to the data model, I imagine Joe >>>has no objection if there is a graphical human interface as well >>>for those that want it. >>> >>>Take as an example Microsoft Excel. >>> >>>On Windows, you can control it programmatically using Visual >>>Basic for Applications, or could. ?You can probably do it >>>through PowerShell, which is pretty capable. ?In MacOS X, >>>you do it through AppleScript. ?(You can probably do it >>>through FScript as well.) ?But I can't get at it the *same* >>>way on both systems. >>> >>> >>>> Here is the first semantic point: you are absolutely right. Then why call Eclipse "graphical"? It still edits text! >>> >>>So, >>>? ? ? ? % open -a Eclipse >>>After a l o n g time, I am staring at a window containing >>> >>>? ? ? ? a circle containing picture of a desk globe >>>? ? ? ? a circle containing a 4-pointed star >>>? ? ? ? a circle containing a blue cube, a green pyramid, >>>? ? ? ? ? and an orange ball >>>? ? ? ? a circle containing a notebook with a green tick >>>? ? ? ? a circle with a piece of ribbon in it. >>>? ? ? ? a purple disc with the word "eclipse" over it and >>>? ? ? ? ? a white fuzzy penumbra. >>> >>>Did someone actually think this was *clever*? >>> >>>It turns out these things mean >>> >>>? ? ? ? Overview >>>? ? ? ? What's new >>>? ? ? ? Samples >>>? ? ? ? Tutorial >>>? ? ? ? Workbench >>>? ? ? ? nothing whatever >>> >>>respectively. ?A picture is sometimes worth 0.001 words. >>> >>> >>>> If the thing with Eclipse is that it has a lot of graphical ornaments around the text, >>> >>>There's Joe's issue and my issue. >>>I think Joe's issue was availability or not of a simple text-based >>>*alternative* that can be used by mortals. >>>From my perspective, Eclipse is about two decimal orders of >>>magnitude harder to use than Emacs. >>> >>> >>>> then my point was that Emacs has toolbars and status bars and such too. >>> >>>No it doesn't, not unless you want it to. >>>Just verified: it uses one line at the bottom for the minibuffer >>>and one line above that for the status line. ?In an 80 column by >>>60 line window I can easily spare 2 lines. >>> >>> >>>> The (first edition of) the book that explains how to *use* >>>> Eclipse is bigger than the listing of my emacs-like editor >>>> PLUS the listing of the C compiler I originally used to >>>> write it PLUS the listing of the UNIX kernel it originally >>>> ran on PLUS the manuals. >>>> >>>> I'm not sure why that would be relevant. >>> >>>The relevance is that >>>?- Eclipse *looks* dauntingly complex when you sit down in >>>? ?front of it, >>>?- when you turn to the reference book for help, it turns >>>? ?out that it really *is* dauntingly complex. >>>? ?Eclipse all by itself is more complex to understand than >>>? ?the *whole* of the software stack I used when doing my >>>? ?PhD, and >>>?- it is hard to approach that complexity incrementally >>>? ?because there are *lots* of things you apparently have >>>? ?to do to do anything. >>> >>>I *was* able to learn everything I needed to know about XCode >>>from a book and from the Apple documentation. ?I'm able to >>>use -- even to extend -- Smalltalk IDEs and I still have >>>fond memories of using and extending Interlisp-D. ?I was at >>>one time familiar with the sources of three Emacs clones. >>>But Eclipse has utterly defeated me. ?I am never going to be >>>able to learn it by myself. >>> >>> >>>> Just because Eclipse might be difficult to understand/explain doesn't make all possible similar tools bad. >>> >>>Agreed. ?I can at least do basic things in NetBeans, but even then, >>>I'd much rather not. >>> >>> >>>> Also, I don't know how large a book about using emacs is/would be (at the same detail level as in the Eclipse book). >>> >>>It's not hard to find out. ?The Emacs manuals are free. ?The Emacs >>>user manual is considerably smaller than the Eclipse user book. >>> >>> >>>> There's a lot of functionality in both, it has to take some place to describe and explain it. >>> >>>For me the daunting complexity is not "a lot of functionality", >>>it's the complexity of the interface for *getting started*. >>> >>>> >>>>> In my opinion, what a programming environment brings to the table is multiple ways to look at the code, to quickly see what is going on. >>>> I think Joe agrees with you, except that Joe places a heavy >>>> emphasis on >>>> ?- something that has precise definition >>>> ?- explicit and straightforward semantics >>>> ?- that he can understand. >>>> >>>> I think so too. Only the last point has the potential to signify that pure text beats a GUI, and it's a personal thing. >>> >>>Potential? ?The question is not the *potential* but the >>>*present actuality*, which is that textual systems _do_ >>>(by and large) have more explicit definitions. ?Too many >>>GUI designers seem to take the view "It's a GUI. ?How can >>>it be hard?" >>> >>> >>>> >>>> The one that's actually _useful_ is the text file, because >>>> there doesn't seem to be any good way to display nearly >>>> 800 classes in one diagram. ?Heck, the collection hierarchy >>>> alone has 176 classes; try getting just _that_ in one display. >>>> >>>> And there is a good way to display this hierarchy in textual form on a single page? That would be the equivalent... >>> >>>No, it's *not* the equivalent. ?The equivalent of a picture >>>that needs to be scrolled around a large wall is a text file >>>that needs scrolling in one direction only. ?For a human >>>being. ?For a program, the important thing is that >>> >>>?- it is trivial to generate the picture from the text >>>?- but not the other way around. >>> >>>> >>>> There are tools that can show large diagrams in a way that works much better (for example, by using a hyperbolic mapping where the current item is large and in the middle and the less related other items are to it, the smaller and more to the periphery they are. >>> >>>Sorry, that just does not work in this case. ?The things I need >>>to see together are not close in that sense. >>> >>> >>>> Panning in the diagram brings other items in focus). There's a lot of research on this, see for example http://www.visualcomplexity.com/vc/. Just because the simplest diagrams aren't good enough doesn't mean that any diagram is bad. >>> >>>It doesn't mean that a more complex diagram is any good either. >>>In this case, for my purposes, it isn't. >>> >>>Remember, the goal is not "DISPLAY SOMETHING", it is >>>"EXTRACT INFORMATION FROM SOMETHING". >>> >>>Data visualisation is actually one of my interests. >>>I have seen *way* too many really cute "infographics" >>>that turned out to be incomprehensible or inaccurate. >>>(I have a copy of Gephi and had serious difficulties >>>with its user interface.) >>> >>>There are some superb data visualisations, but it isn't >>>_easy_ to design them. >>> >>> >>>> Now, visualising the process structure would be nice, except >>>> that someone *did* this using UbiGraph and the result was >>>> as dismaying as it was cool. ?Erlang lets you have *lots* of >>>> processes, and that's just what doesn't suit a diagram. >>>> >>>> See above. The breakthrough would be to be able to detect which processes are important to show and when. >>> >>>Yes, that would be nice. ?Do you have some idea of how to do that? >>> >>> >>>> See for example https://code.google.com/p/gource/ on how a project's VCS history can be visualized >>> >>>I have seen that before. >>>To me, it's a textbook example of "cute, but what actual >>>GOOD does it do me?" >>>If I want to learn something from version control logs, >>>I'm *not* going to look at a Gource movie, >>>I'm going to analyse the logs in textual form. >>> >>>Not idle chatter. ?I have a project of my own for which I >>>*have* analysed the logs to spot patterns. ?Plain old >>>black and white 2D graphs displayed what I had found >>>perfectly well. ?The trick was to GET ACCESS TO THE DATA >>>in such a way that A SIMPLE PROGRAM CAN PROCESS IT. >>> >>> >>>> -- imagine a similar thing where the focus is on processes that are active, they are kept in the middle and larger, the links light up when messages are sent, all dynamically as one goes back and forth in time.. >>> >>>If it's just like the one I saw a while back using Ubigraph, >>>or if it's like Gource, the answer is that it will be as cute >>>as a basket of kittens in party hats, but won't actually be >>>any use for analysis. >>> >>>I am reminded of a prominent secular theologian (that's one of >>>those strange people who says there is no god THEREFORE let us >>>do religion). ?My father went to one of his lectures, and >>>afterwards me one of his own students who had also gone. >>>? ? ? ? Student. ?Wasn't X a *wonderful* speaker? >>>? ? ? ? Dad. ? ? ?Yes. ?But what did he *say*? >>>? ? ? ? Student. ?(Silence.) >>> >>> >>>> >>>>> As a user, one shouldn't need to understand how the environment works (you think Eclipse is complex, I think Emacs is; it's a matter of what we are accustomed to). >>>> We can measure the complexity of an environment in itself >>>> without reference to what we are accustomed to. >>>> The text editor I normally use takes less than 15 000 raw >>>> lines of C (less than 8 000 SLOC); executables and help >>>> files come to 173 kB on disc. >>>> That _has_ to be less complex than Emacs.app, which is >>>> 161 MB on disc. >>>> And that _has_ to be less complex than Eclipse for C/C++ >>>> where the smallest download seems to be 141 MB compressed. >>>> And the really annoying thing is that the actual text >>>> editing support in Eclipse is far more limited than that >>>> in the 173 kB program! >>>> >>>> Why is the size or complexity of the code relevant? >>> >>>(a) Because a small program *can't* have as a dauntingly >>>? ? complex an interface as a large one. >>>(b) Because a small program *can't* have as many >>>? ? internal interactions as a large one (the user's >>>? ? mental model of what the program is up to will be >>>? ? less inaccurate). >>>(c) Because a large program will, as a rule, have more >>>? ? bugs than a small one, and the relationship is >>>? ? non-linear. >>> >>> >>>> I can have short and simple code that implements a program with very weird commands and interaction patterns. I can have a huge complex program with a nice and understandable or discoverable way to use it. >>> >>>You *can*, but as a rule you *don't*. >>> >>>>> >>>> I understand what you mean. If I use Emacs and I customize it with fancy commands that help my workflow and become dependent on them -- isn't that the same problem as with depending on Eclipse? >>> >>>No, the question is not "what do *I* depend on" but >>>"what am I requiring *OTHER* people to depend on". >>> >>>> Emacs _is_ an IDE. >>> >>>This really does miss the point, which is that software >>>developed *using* Emacs is textual. ?If Joe develops something >>>using Emacs, I can read *ALL* of it using TextEdit or pico or >>>whatever. >>> >>>Now I've never succeeded in building anything with Eclipse, >>>but I *can* say that if I build something with XCode, there's >>>information hidden in all sorts of strange places, and I've >>>had serious difficulty importing old projects into a newer >>>XCode. ?Heck, I've had serious difficulty importing other >>>people's projects into the *same* version of XCode, thanks >>>to important information about the project that was only >>>accessible using the GUI. >>> >>>> >>>> >>>> ?What I mean is that implementing a bug-free core is much easier than implementing all the functionality on top of it just as bug-free. >>> >>>Agreed, and getting the other functionality on top bug-free pretty >>>much *depends* on there being a small comprehensible core. >>> >>> >>>> No I'm not. I just don't think that the reason that TeX is practically bug-free has anything to do with it being a backend tool. >>> >>>Let's be clear about causality here. >>>I think you are saying >>>? ? ? ? NOT BECAUSE(backend(TeX), reliable(TeX)) >>>and I am saying >>>? ? ? ? BECAUSE(reliable(TeX), backend(TeX)) >>> >>>Let me put it this way. ?There was a time when I was seriously >>>considering a move from (La)TeX to another document formatter >>>with simpler cleaner markup. ?I read the manual cover to cover >>>several times, started playing with it, and found it produced >>>good-looking output. ?But when I ran lint over it, a lot of the >>>lint warnings turned out to be genuine, and within a day I had >>>found a number of ways to crash it. ?So I dropped the idea of >>>writing front end scripts to generate input for that processor. >>>For me, >>>? ? ? ? BECAUSE(NOT reliable(XXXX), NOT backend(XXXX)) >>> >>> >>> >> > > >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.benner@REDACTED Tue Feb 4 14:39:59 2014 From: sylvain.benner@REDACTED (Sylvain Benner) Date: Tue, 4 Feb 2014 05:39:59 -0800 (PST) Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: References: <89DAA09F-64B0-4565-A73C-784B5E8EB4C6@feuerlabs.com> <8883B14026CD4CB38E71BEB9DFE5BF67@srstrong.com> Message-ID: If you are familiar with Vim I recommend installing the evil-mode right away, it is the one of the most complete Vim key bindings emulation. You will feel like home with it and you will be one of the happy Emacs/Vim strange kind of user (monster?!) which can enjoy the best* text editor on this planet: Emacs+Vim. Annnnnnd you will be able to enjoy the best* programming environment for Erlang: EDTS [1] which is of course written partly in Erlang :-) For example, EDTS evaluates eunit tests as you modify them and show the result visually in the buffer by underlining the test name in green en red, put the cursor on the test name and you have your failed assertion. And this is just a small example of what EDTS does. cheers, syl20bnr [1] https://github.com/tjarvstrand/edts * very personal opinion there :-) Le vendredi 31 janvier 2014 01:25:17 UTC-5, kraythe a ?crit : > > Well I think after seeing the arguments and the response of the community > I am trending seriously towards Erlang. I will probably make the mental > investment to learn and become good with emacs. And then move on from > there. I may still have a ton of questions. I would still, for example, > love to know who to 'reload' my application once it is started. > > > On Fri, Jan 31, 2014 at 12:24 AM, kraythe . > > wrote: > >> Well I think after seeing the arguments and the response of the community >> I am trending seriously towards Erlang. I will probably make the mental >> investment to learn and become good with emacs. And then move on from >> there. I may still have a ton of questions. I would still, for example, >> love to know who to 'reload' my application once it is started. >> >> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* >> *Author of: Hardcore Java (2003) and Maintainable Java (2012)* >> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 >> * >> >> >> On Thu, Jan 30, 2014 at 10:29 PM, Richard A. O'Keefe >> > wrote: >> >>> >>> On 31/01/2014, at 7:49 AM, Steve Strong wrote: >>> > On Thursday, 30 January 2014 at 19:10, kraythe . wrote: >>> >> 1) Code completion. Sorry but I can't be bothered to type the same >>> flipping method name in its entirety 40 times. >>> >>> >>> There are three causes for "completion" in languages like >>> Prolog and Erlang: >>> >>> (a) Definitions with multiple clauses. >>> Your editor should be able to turn "add a clause" into a >>> single command. >>> >>> (b) Recursion. >>> Your editor should be able to turn "add a recursive call" >>> into a single command (basically the same as (a), just >>> different stuff wrapped around it). >>> >>> A programming style using higher order procedures can >>> eliminate a lot of this. >>> >>> (c) Repetitive patterns of code. >>> >>> A programming style using higher order procedures can >>> eliminate a lot of this. >>> >>> There's a thing I find myself saying more and more often: >>> >>> Why can't I see the structure? >>> >>> I was reviewing a page or two of Prolog code for someone the >>> other day. By the end of three hours, I'd made some progress, >>> but I was troubled. The code was clean, but it wasn't OBVIOUS. >>> What finally dawned on me would have been instantly obvious to >>> a real functional programmer: the code was an interweaving of >>> a "compute argmax of a partial function over a finite domain" >>> and "here is this partial function". Actually introducing the >>> higher order function in question let me explore several ways >>> of implementing that *without* any effect on the rest of the >>> code. Breaking the specific partial function out and naming >>> it let me see that memoising *that* function -- which hadn't >>> previously existed -- stood an excellent chance of reducing >>> the overall cost of the algorithm down *hugely*. >>> >>> So I say, if you find yourself _wanting_ a method name to >>> appear 40 times in a day's work, you are doing something >>> badly wrong. >>> >>> For another data point, as part of building up my Smalltalk >>> skills, I used to pick up Java code and rewrite it in Smalltalk. >>> There were two invariable results: first, the code would >>> shrink by about a factor of six, and second, it would become >>> painfully obvious that the original code was really really >>> bad design, and that in a *good* OO design, most of the >>> classes wouldn't just shrink, they'd disappear. A good part >>> of this is down to Smalltalk's support for and extensive use >>> of higher order functions from day 1. >>> >>> > >>> > 3) Syntax coloring. (VIM color codes a file so that is there, emacs I >>> don't know AT ALL.) >>> To which Steve Strong replied >>> > I don?t know of any editor that doesn?t do this - >>> > even github displays syntax colouring on erlang files. >>> >>> My own text editor doesn't do syntax colouring. >>> Frankly, I hate syntax colouring. I could give you >>> a long rant about why. One big issue is that the >>> name is a lie. It's *lexical* colouring; the colour >>> depends on what kind of token something is. But I >>> can *see* that. If you offered me an editor where >>> calls to functions whose definitions had been edited >>> recently were brightly coloured, or where the functions >>> imported from a particular module were brightly coloured, >>> or where slicing was used to colour the places where a >>> particular variable could be *changed* and *used*, I'd >>> find that really really helpful. Why waste colour >>> telling me something that is already obvious at a glance? >>> I once came across a compiler (written in Finland) where >>> several passes had had to be woven together because of >>> the language it was written in, so they had coloured >>> each declaration and statement according to which pass >>> it was logically part of. Now _that's_ good use of colour! >>> >>> > >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.benner@REDACTED Tue Feb 4 14:44:42 2014 From: sylvain.benner@REDACTED (Sylvain Benner) Date: Tue, 4 Feb 2014 05:44:42 -0800 (PST) Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: References: <89DAA09F-64B0-4565-A73C-784B5E8EB4C6@feuerlabs.com> <8883B14026CD4CB38E71BEB9DFE5BF67@srstrong.com> Message-ID: <8a44af42-761e-485f-bbf2-2e3980d8a433@googlegroups.com> Oops seems that I missed 2 full pages of discussion... EDTS has already been mentioned. Le mardi 4 f?vrier 2014 08:39:59 UTC-5, Sylvain Benner a ?crit : > > If you are familiar with Vim I recommend installing the evil-mode right > away, it is the one of the most complete Vim key bindings emulation. You > will feel like home with it and you will be one of the happy Emacs/Vim > strange kind of user (monster?!) which can enjoy the best* text editor on > this planet: Emacs+Vim. > > Annnnnnd you will be able to enjoy the best* programming environment for > Erlang: EDTS [1] which is of course written partly in Erlang :-) > For example, EDTS evaluates eunit tests as you modify them and show the > result visually in the buffer by underlining the test name in green en red, > put the cursor on the test name and you have your failed assertion. And > this is just a small example of what EDTS does. > > cheers, > syl20bnr > > [1] https://github.com/tjarvstrand/edts > * very personal opinion there :-) > > > Le vendredi 31 janvier 2014 01:25:17 UTC-5, kraythe a ?crit : >> >> Well I think after seeing the arguments and the response of the community >> I am trending seriously towards Erlang. I will probably make the mental >> investment to learn and become good with emacs. And then move on from >> there. I may still have a ton of questions. I would still, for example, >> love to know who to 'reload' my application once it is started. >> >> >> On Fri, Jan 31, 2014 at 12:24 AM, kraythe . wrote: >> >>> Well I think after seeing the arguments and the response of the >>> community I am trending seriously towards Erlang. I will probably make the >>> mental investment to learn and become good with emacs. And then move on >>> from there. I may still have a ton of questions. I would still, for >>> example, love to know who to 'reload' my application once it is started. >>> >>> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* >>> *Author of: Hardcore Java (2003) and Maintainable Java (2012)* >>> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 >>> * >>> >>> >>> On Thu, Jan 30, 2014 at 10:29 PM, Richard A. O'Keefe < >>> o...@REDACTED> wrote: >>> >>>> >>>> On 31/01/2014, at 7:49 AM, Steve Strong wrote: >>>> > On Thursday, 30 January 2014 at 19:10, kraythe . wrote: >>>> >> 1) Code completion. Sorry but I can't be bothered to type the same >>>> flipping method name in its entirety 40 times. >>>> >>>> >>>> There are three causes for "completion" in languages like >>>> Prolog and Erlang: >>>> >>>> (a) Definitions with multiple clauses. >>>> Your editor should be able to turn "add a clause" into a >>>> single command. >>>> >>>> (b) Recursion. >>>> Your editor should be able to turn "add a recursive call" >>>> into a single command (basically the same as (a), just >>>> different stuff wrapped around it). >>>> >>>> A programming style using higher order procedures can >>>> eliminate a lot of this. >>>> >>>> (c) Repetitive patterns of code. >>>> >>>> A programming style using higher order procedures can >>>> eliminate a lot of this. >>>> >>>> There's a thing I find myself saying more and more often: >>>> >>>> Why can't I see the structure? >>>> >>>> I was reviewing a page or two of Prolog code for someone the >>>> other day. By the end of three hours, I'd made some progress, >>>> but I was troubled. The code was clean, but it wasn't OBVIOUS. >>>> What finally dawned on me would have been instantly obvious to >>>> a real functional programmer: the code was an interweaving of >>>> a "compute argmax of a partial function over a finite domain" >>>> and "here is this partial function". Actually introducing the >>>> higher order function in question let me explore several ways >>>> of implementing that *without* any effect on the rest of the >>>> code. Breaking the specific partial function out and naming >>>> it let me see that memoising *that* function -- which hadn't >>>> previously existed -- stood an excellent chance of reducing >>>> the overall cost of the algorithm down *hugely*. >>>> >>>> So I say, if you find yourself _wanting_ a method name to >>>> appear 40 times in a day's work, you are doing something >>>> badly wrong. >>>> >>>> For another data point, as part of building up my Smalltalk >>>> skills, I used to pick up Java code and rewrite it in Smalltalk. >>>> There were two invariable results: first, the code would >>>> shrink by about a factor of six, and second, it would become >>>> painfully obvious that the original code was really really >>>> bad design, and that in a *good* OO design, most of the >>>> classes wouldn't just shrink, they'd disappear. A good part >>>> of this is down to Smalltalk's support for and extensive use >>>> of higher order functions from day 1. >>>> >>>> > >>>> > 3) Syntax coloring. (VIM color codes a file so that is there, emacs I >>>> don't know AT ALL.) >>>> To which Steve Strong replied >>>> > I don?t know of any editor that doesn?t do this - >>>> > even github displays syntax colouring on erlang files. >>>> >>>> My own text editor doesn't do syntax colouring. >>>> Frankly, I hate syntax colouring. I could give you >>>> a long rant about why. One big issue is that the >>>> name is a lie. It's *lexical* colouring; the colour >>>> depends on what kind of token something is. But I >>>> can *see* that. If you offered me an editor where >>>> calls to functions whose definitions had been edited >>>> recently were brightly coloured, or where the functions >>>> imported from a particular module were brightly coloured, >>>> or where slicing was used to colour the places where a >>>> particular variable could be *changed* and *used*, I'd >>>> find that really really helpful. Why waste colour >>>> telling me something that is already obvious at a glance? >>>> I once came across a compiler (written in Finland) where >>>> several passes had had to be woven together because of >>>> the language it was written in, so they had coloured >>>> each declaration and statement according to which pass >>>> it was logically part of. Now _that's_ good use of colour! >>>> >>>> > >>>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Tue Feb 4 15:04:56 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 4 Feb 2014 06:04:56 -0800 (PST) Subject: [erlang-questions] beta release of merl - metaprogramming in Erlang In-Reply-To: <52F0D50C.6080700@gmail.com> References: <52F0D50C.6080700@gmail.com> Message-ID: <1391522696.42483.YahooMailNeo@web140106.mail.bf1.yahoo.com> I chortled at the homoiconic languages slide. Then chortled again at seeing you have nearly grasped in your hands the holy grail of programming: compiling power point. Anecdote time. I looked at another point of the curve you're describing: I extended the erlang parser with syntax tree fragments and holes wherein to plug the fragments (fragments could have holes too of course). The idea was that you could specify in "Template Erlang" that, say, this function takes 0,1 or more extra arguments using something like @, Lisp macros, or that you can add clauses to this case, or that you can plug in an expression right here, etc. There were various plug-in points throughout the syntax tree. Fragments could be all major syntactic elements, like functions, attributes, clauses, expressions, patterns, and so on. The main gains of that approach compared to what (after a quick read) looks like textual templating in Merl appears to be guaranteed syntactic well-formedness and possibly adding a little bit more "type checking" to make sure that fragments and holes fit. In retrospect I'm not sure Template Erlang was worth the effort since it felt a bit too unwieldy in practice. Text templates might be quite sufficient in practice (and easier to use). Best, Thomas On Tuesday, February 4, 2014 12:55 PM, Richard Carlsson wrote: So, I finally got around to releasing Merl to Github, under an Apache 2 >license: >? https://github.com/richcarl/merl > >I talked about it two years ago in San Francisco: >? http://www.youtube.com/watch?v=RA7QcMNBKfg > >Slides here: > >http://www.erlang-factory.com/conference/ErlangUserConference2012/speakers/RichardCarlsson > >See the edoc overview for documentation, and the examples/ subdirectory >for example code. > >Currently missing: I'd like to have a good API for working with a >"module" as an ADT, easily adding and removing definitions and querying >the current state, and also reading an existing module from file or as >an AST in a parse transform. The file "examples/merl_build.erl" is a >start, but I don't have time right now to work more on that. Useful >sources of inspiration for such an API are >https://github.com/yariv/erlyweb/blob/master/src/smerl/smerl.erl and >https://github.com/uwiger/parse_trans. > >? /Richard >_______________________________________________ >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 Tue Feb 4 15:11:12 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Tue, 4 Feb 2014 15:11:12 +0100 Subject: [erlang-questions] r17 beam compatibility Message-ID: Hi, This is difficult to test comprehensively, so I wil ask: Are there any changes in the BEAM format in R16 and R17, so that one can't run these newer beams on R15? I know it's not a very good idea, but I might be forced to do that... Or I will have to work around the problem somehow. regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Tue Feb 4 15:17:59 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 4 Feb 2014 15:17:59 +0100 Subject: [erlang-questions] beta release of merl - metaprogramming in Erlang In-Reply-To: <52F0D50C.6080700@gmail.com> References: <52F0D50C.6080700@gmail.com> Message-ID: <45CAB6D1-97CD-4203-966D-447D57828A9D@gmail.com> Shameless plug, but kinda related, you might appreciate this Richard. https://github.com/nox/otp/commit/b734fc412ad9ea8d1b5d810127c058936955461e Implemented this a few years ago, it?s not finished but I may work again on it if people like it or want to see it finished. Merl looks fun but I really really hate epp-like macros and code in strings, I guess it does work in the end though. -- Anthony Ramine Le 4 f?vr. 2014 ? 12:54, Richard Carlsson a ?crit : > So, I finally got around to releasing Merl to Github, under an Apache 2 license: > https://github.com/richcarl/merl > > I talked about it two years ago in San Francisco: > http://www.youtube.com/watch?v=RA7QcMNBKfg > > Slides here: > http://www.erlang-factory.com/conference/ErlangUserConference2012/speakers/RichardCarlsson > > See the edoc overview for documentation, and the examples/ subdirectory for example code. > > Currently missing: I'd like to have a good API for working with a "module" as an ADT, easily adding and removing definitions and querying the current state, and also reading an existing module from file or as an AST in a parse transform. The file "examples/merl_build.erl" is a start, but I don't have time right now to work more on that. Useful sources of inspiration for such an API are https://github.com/yariv/erlyweb/blob/master/src/smerl/smerl.erl and https://github.com/uwiger/parse_trans. > > /Richard > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From magnus@REDACTED Tue Feb 4 15:21:00 2014 From: magnus@REDACTED (Magnus Henoch) Date: Tue, 04 Feb 2014 14:21:00 +0000 Subject: [erlang-questions] r17 beam compatibility In-Reply-To: (Vlad Dumitrescu's message of "Tue, 4 Feb 2014 15:11:12 +0100") References: Message-ID: Vlad Dumitrescu writes: > Hi, > > This is difficult to test comprehensively, so I wil ask: Are there any > changes in the BEAM format in R16 and R17, so that one can't run these > newer beams on R15? > > I know it's not a very good idea, but I might be forced to do that... Or I > will have to work around the problem somehow. According to the comments in genop.tab, there are five new opcodes in R16, but none in 17.0: https://github.com/erlang/otp/blob/OTP_17.0-rc1/lib/compiler/src/genop.tab#L528-L538 Regards, Magnus From magnus@REDACTED Tue Feb 4 15:27:28 2014 From: magnus@REDACTED (Magnus Henoch) Date: Tue, 04 Feb 2014 14:27:28 +0000 Subject: [erlang-questions] r17 beam compatibility In-Reply-To: (Magnus Henoch's message of "Tue, 04 Feb 2014 14:21:00 +0000") References: Message-ID: Magnus Henoch writes: > Vlad Dumitrescu writes: > >> Hi, >> >> This is difficult to test comprehensively, so I wil ask: Are there any >> changes in the BEAM format in R16 and R17, so that one can't run these >> newer beams on R15? >> >> I know it's not a very good idea, but I might be forced to do that... Or I >> will have to work around the problem somehow. > > According to the comments in genop.tab, there are five new opcodes in > R16, but none in 17.0: > > https://github.com/erlang/otp/blob/OTP_17.0-rc1/lib/compiler/src/genop.tab#L528-L538 ... though on closer inspection, it seems like that comment is misleading: those opcodes were added in 17.0, which suggests that code compiled with R16 should run on R15, and code compiled with R17 should run on R15 as long as it doesn't use maps. Regards, Magnus From essen@REDACTED Tue Feb 4 15:30:21 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 04 Feb 2014 15:30:21 +0100 Subject: [erlang-questions] Google Summer of Code 2014 with the BEAM Community In-Reply-To: References: Message-ID: <52F0F97D.2000303@ninenines.eu> Hello, Perhaps I've been too busy last year or something but what happened to the 2013 projects? I'm not even sure what most of them were, and I don't think I've heard of one even being merged/released. I remember looking at the mailing list at some point just before the end and had no clue what the reports were talking about either. Any chance this year it could be a little more transparent for people who can't invest all their time in following it? As it stands now I have no idea if any project benefited from it. Perhaps this is something that could be useful for my projects, but it doesn't really sound like it right now. On 02/04/2014 11:33 AM, Jos? Valim wrote: > Hello everyone, > > Last year we have created the BEAM Community organization meant to host > different projects that run on the Erlang VM. We had 6 students working > on different projects during the summer, like Elixir, Disco, Mongoose IM > and others. > > The Google Summer of Code 2014 has just announced they are looking for > organizations to participate in this year edition. Historically, Google > has given higher preference for umbrella organizations and therefore we > will participate this year again! > > The BEAM Community website for 2014 is online: > http://beamcommunity.github.io/ > > The first step is to gather a set of projects that are interested in > taking part of the BEAM Community. So if you run a project in the Erlang > VM and you are interested in mentoring a student during the summer, > please send me an e-mail! At this stage, all we need is the project name > and a list of ideas / proposals for students to work on. You can use the > ideas from last year as inspiration / template > . > > We are planning to host 6 projects, the same amount as last year and the > deadline for joining us / putting up your list of ideas is 11th > February. Google's deadline is 14th february but we need some time to > put everything together. The full program timetable can be found online > too ! > > If you have any questions, please feel free to ask. > You may also ask projects that took part last year if you are interested > on how the program works. > > I'm looking forward to another great summer! > > > * > *Jos? Valim* > www.plataformatec.com.br > Founder and Lead Developer > * > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From carlsson.richard@REDACTED Tue Feb 4 15:36:09 2014 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Tue, 04 Feb 2014 15:36:09 +0100 Subject: [erlang-questions] beta release of merl - metaprogramming in Erlang In-Reply-To: <45CAB6D1-97CD-4203-966D-447D57828A9D@gmail.com> References: <52F0D50C.6080700@gmail.com> <45CAB6D1-97CD-4203-966D-447D57828A9D@gmail.com> Message-ID: <52F0FAD9.9050402@gmail.com> On 2014-02-04 15:17 , Anthony Ramine wrote: > Shameless plug, but kinda related, you might appreciate this Richard. > > https://github.com/nox/otp/commit/b734fc412ad9ea8d1b5d810127c058936955461e > > Implemented this a few years ago, it?s not finished but I may work again on it if people like it or want to see it finished. > > Merl looks fun but I really really hate epp-like macros and code in strings, I guess it does work in the end though. > Looks nice. I had long considered doing something Meta-ML-like for Erlang, but wanted to start with something simple that didn't need a modified parser (not even macros or transforms at the simplest level), and then work my way up. The advantage is that it works today, without forking OTP or pushing an EEP to add metasyntax to R18. :-) Note for anyone trying Merl: it doesn't work with R16B03 due to the broken syntax tools in that release. Use R16B03-1 instead. /Richard From n.oxyde@REDACTED Tue Feb 4 15:38:39 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 4 Feb 2014 15:38:39 +0100 Subject: [erlang-questions] beta release of merl - metaprogramming in Erlang In-Reply-To: <52F0FAD9.9050402@gmail.com> References: <52F0D50C.6080700@gmail.com> <45CAB6D1-97CD-4203-966D-447D57828A9D@gmail.com> <52F0FAD9.9050402@gmail.com> Message-ID: It also have some caveats, if we really want to make use of it: - I don?t have an idea of an obvious syntax for extracting the attributes - I need multiple escape operators to do stuff like case E of ``Clauses end - I need to abuse yecc to be able to do <|form| SomeForm |> Glad you find it interesting though! -- Anthony Ramine Le 4 f?vr. 2014 ? 15:36, Richard Carlsson a ?crit : > On 2014-02-04 15:17 , Anthony Ramine wrote: >> Shameless plug, but kinda related, you might appreciate this Richard. >> >> https://github.com/nox/otp/commit/b734fc412ad9ea8d1b5d810127c058936955461e >> >> Implemented this a few years ago, it?s not finished but I may work again on it if people like it or want to see it finished. >> >> Merl looks fun but I really really hate epp-like macros and code in strings, I guess it does work in the end though. >> > > Looks nice. I had long considered doing something Meta-ML-like for Erlang, but wanted to start with something simple that didn't need a modified parser (not even macros or transforms at the simplest level), and then work my way up. The advantage is that it works today, without forking OTP or pushing an EEP to add metasyntax to R18. :-) > > Note for anyone trying Merl: it doesn't work with R16B03 due to the broken syntax tools in that release. Use R16B03-1 instead. > > /Richard > From mangalaman93@REDACTED Tue Feb 4 15:50:05 2014 From: mangalaman93@REDACTED (aman mangal) Date: Tue, 4 Feb 2014 20:20:05 +0530 Subject: [erlang-questions] Google Summer of Code 2014 with the BEAM Community In-Reply-To: <52F0F97D.2000303@ninenines.eu> References: <52F0F97D.2000303@ninenines.eu> Message-ID: Hi, I worked on Erlang Package Manager (epax) during GSoC 2013 and I am still working on it. I could not write code as rigorously as I was working during GSoC. I will speeden up a little bit and we will launch the first version soon. You can find the project on github http://github.com/mangalaman93/epax& original repo http://github.com/mangalaman93/epax. My mentors Eric Merritt and Jordan Wilberding will review the code before we launch the first version. Also, I am wondering if there can be a standard page where we can put a list of all such projects beginning with GSoC 2013. I can do this after contacting everybody else and put up such a page on github. I am sure other 5 participants are also continuing with their projects. We can also add projects other than GSoC which are currently ongoing and require more contributors. I am always in search of one and contribute more to Erlang community when I am free. Aman Mangal 4th year Undergraduate Student Department of Computer Science & Engineering IIT Bombay www.cse.iitb.ac.in/~amanmangal On Tue, Feb 4, 2014 at 8:00 PM, Lo?c Hoguin wrote: > Hello, > > Perhaps I've been too busy last year or something but what happened to the > 2013 projects? I'm not even sure what most of them were, and I don't think > I've heard of one even being merged/released. I remember looking at the > mailing list at some point just before the end and had no clue what the > reports were talking about either. > > Any chance this year it could be a little more transparent for people who > can't invest all their time in following it? > > As it stands now I have no idea if any project benefited from it. Perhaps > this is something that could be useful for my projects, but it doesn't > really sound like it right now. > > > On 02/04/2014 11:33 AM, Jos? Valim wrote: > >> Hello everyone, >> >> Last year we have created the BEAM Community organization meant to host >> different projects that run on the Erlang VM. We had 6 students working >> on different projects during the summer, like Elixir, Disco, Mongoose IM >> and others. >> >> The Google Summer of Code 2014 has just announced they are looking for >> organizations to participate in this year edition. Historically, Google >> has given higher preference for umbrella organizations and therefore we >> will participate this year again! >> >> The BEAM Community website for 2014 is online: >> http://beamcommunity.github.io/ >> >> The first step is to gather a set of projects that are interested in >> taking part of the BEAM Community. So if you run a project in the Erlang >> VM and you are interested in mentoring a student during the summer, >> please send me an e-mail! At this stage, all we need is the project name >> and a list of ideas / proposals for students to work on. You can use the >> ideas from last year as inspiration / template >> > github.com/blob/master/2013/Home.md>. >> >> >> We are planning to host 6 projects, the same amount as last year and the >> deadline for joining us / putting up your list of ideas is 11th >> February. Google's deadline is 14th february but we need some time to >> put everything together. The full program timetable can be found online >> too ! >> >> >> If you have any questions, please feel free to ask. >> You may also ask projects that took part last year if you are interested >> on how the program works. >> >> I'm looking forward to another great summer! >> >> >> * >> *Jos? Valim* >> www.plataformatec.com.br >> Founder and Lead Developer >> * >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeakk@REDACTED Tue Feb 4 16:03:21 2014 From: freeakk@REDACTED (Michael Uvarov) Date: Tue, 04 Feb 2014 16:03:21 +0100 Subject: [erlang-questions] Google Summer of Code 2014 with the BEAM Community In-Reply-To: <52F0F97D.2000303@ninenines.eu> References: <52F0F97D.2000303@ninenines.eu> Message-ID: Hi, Message Archive Management was merged into MongooseIM and will be included into next release. On February 4, 2014 3:30:21 PM CET, "Lo?c Hoguin" wrote: >Hello, > >Perhaps I've been too busy last year or something but what happened to >the 2013 projects? I'm not even sure what most of them were, and I >don't >think I've heard of one even being merged/released. I remember looking >at the mailing list at some point just before the end and had no clue >what the reports were talking about either. > >Any chance this year it could be a little more transparent for people >who can't invest all their time in following it? > >As it stands now I have no idea if any project benefited from it. >Perhaps this is something that could be useful for my projects, but it >doesn't really sound like it right now. > >On 02/04/2014 11:33 AM, Jos? Valim wrote: >> Hello everyone, >> >> Last year we have created the BEAM Community organization meant to >host >> different projects that run on the Erlang VM. We had 6 students >working >> on different projects during the summer, like Elixir, Disco, Mongoose >IM >> and others. >> >> The Google Summer of Code 2014 has just announced they are looking >for >> organizations to participate in this year edition. Historically, >Google >> has given higher preference for umbrella organizations and therefore >we >> will participate this year again! >> >> The BEAM Community website for 2014 is online: >> http://beamcommunity.github.io/ >> >> The first step is to gather a set of projects that are interested in >> taking part of the BEAM Community. So if you run a project in the >Erlang >> VM and you are interested in mentoring a student during the summer, >> please send me an e-mail! At this stage, all we need is the project >name >> and a list of ideas / proposals for students to work on. You can use >the >> ideas from last year as inspiration / template >> >. >> >> We are planning to host 6 projects, the same amount as last year and >the >> deadline for joining us / putting up your list of ideas is 11th >> February. Google's deadline is 14th february but we need some time to >> put everything together. The full program timetable can be found >online >> too ! >> >> If you have any questions, please feel free to ask. >> You may also ask projects that took part last year if you are >interested >> on how the program works. >> >> I'm looking forward to another great summer! >> >> >> * >> *Jos? Valim* >> www.plataformatec.com.br >> Founder and Lead Developer >> * >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > >-- >Lo?c Hoguin >http://ninenines.eu >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Tue Feb 4 16:17:17 2014 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Tue, 4 Feb 2014 16:17:17 +0100 Subject: [erlang-questions] Google Summer of Code 2014 with the BEAM Community In-Reply-To: <52F0F97D.2000303@ninenines.eu> References: <52F0F97D.2000303@ninenines.eu> Message-ID: > > Any chance this year it could be a little more transparent for people who > can't invest all their time in following it? > Our first goal is to ensure a good environment and experience for the students. The second goal is to ensure the projects and their contributors can learn something with the student work and possibly merge it back. We have weekly reports in the mailing list to keep track of those goals, so they are mostly meant for the community active in the participating projects. Given everyone participating already reserves a good amount of their free time to organize and mentor students, help to make the students work more transparent for the community as a whole is definitely welcome. Maybe you could help by compiling some sort of bi-weekly e-mail? Other ideas are also welcome! As it stands now I have no idea if any project benefited from it. Perhaps > this is something that could be useful for my projects, but it doesn't > really sound like it right now. All projects last year were pleased with the results. You can ping them for a more detailed list of pros and cons. There is also plenty of reports from other organizations out there. I can speak in particular about Elixir results. We have merged part of the student work: 1. The student worked on pretty printing for Elixir along the community. In particular, the community had already started work on pretty printing, however it was based Wadler's work for Haskell (a lazy language) and the performance was not optimal for Elixir. The student ported the work to an OCaml based implementation as described in the "Strictly Pretty" paper by Christian Lindig; 2. The remaining of the student work went into an interactive/debugging tool and some of it was merged back as well. He's continued working on the project as part of his thesis; Keep in mind though the focus of the Summer of Code is the student. A good project is first useful for the student and second for the maintainers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Tue Feb 4 16:20:59 2014 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Tue, 4 Feb 2014 16:20:59 +0100 Subject: [erlang-questions] Google Summer of Code 2014 with the BEAM Community In-Reply-To: References: <52F0F97D.2000303@ninenines.eu> Message-ID: > > Also, I am wondering if there can be a standard page where we can put a > list of all such projects beginning with GSoC 2013. I can do this after > contacting everybody else and put up such a page on github. I am sure other > 5 participants are also continuing with their projects. We can also add > projects other than GSoC which are currently ongoing and require more > contributors. I am always in search of one and contribute more to Erlang > community when I am free. > Hello Aman! This is a great idea. We can definitely keep an archive of the previous projects on the website. I have added you on gtalk and you have my e-mail. I will also start a discussion on the beam-community mailing list. Let me know if there is anything I can do to help you get in touch with last year students and the previous projects. Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Tue Feb 4 16:54:04 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Tue, 4 Feb 2014 16:54:04 +0100 Subject: [erlang-questions] r17 beam compatibility In-Reply-To: References: Message-ID: Ok, thanks. Good thing you reminded me where to look! :) regards, Vlad On Tue, Feb 4, 2014 at 3:27 PM, Magnus Henoch wrote: > Magnus Henoch writes: > > > Vlad Dumitrescu writes: > > > >> Hi, > >> > >> This is difficult to test comprehensively, so I wil ask: Are there any > >> changes in the BEAM format in R16 and R17, so that one can't run these > >> newer beams on R15? > >> > >> I know it's not a very good idea, but I might be forced to do that... > Or I > >> will have to work around the problem somehow. > > > > According to the comments in genop.tab, there are five new opcodes in > > R16, but none in 17.0: > > > > > https://github.com/erlang/otp/blob/OTP_17.0-rc1/lib/compiler/src/genop.tab#L528-L538 > > ... though on closer inspection, it seems like that comment is > misleading: those opcodes were added in 17.0, which suggests that code > compiled with R16 should run on R15, and code compiled with R17 should > run on R15 as long as it doesn't use maps. > > Regards, > Magnus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From egil@REDACTED Tue Feb 4 17:12:51 2014 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Tue, 4 Feb 2014 17:12:51 +0100 Subject: [erlang-questions] r17 beam compatibility In-Reply-To: References: Message-ID: <52F11183.8090303@erlang.org> On 2014-02-04 15:27, Magnus Henoch wrote: > Magnus Henoch writes: > >> Vlad Dumitrescu writes: >> >>> Hi, >>> >>> This is difficult to test comprehensively, so I wil ask: Are there any >>> changes in the BEAM format in R16 and R17, so that one can't run these >>> newer beams on R15? >>> >>> I know it's not a very good idea, but I might be forced to do that... Or I >>> will have to work around the problem somehow. >> According to the comments in genop.tab, there are five new opcodes in >> R16, but none in 17.0: >> >> https://github.com/erlang/otp/blob/OTP_17.0-rc1/lib/compiler/src/genop.tab#L528-L538 > ... though on closer inspection, it seems like that comment is > misleading: those opcodes were added in 17.0, which suggests that code > compiled with R16 should run on R15, and code compiled with R17 should > run on R15 as long as it doesn't use maps. Very true. We had devbranches where we had maps on R16 and those commits were also used in this Maps dev. Apparently I only changed the comment for the loader in ops.tab .. > > Regards, > Magnus > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From erlangprogram@REDACTED Tue Feb 4 18:15:01 2014 From: erlangprogram@REDACTED (Samuel X) Date: Tue, 4 Feb 2014 12:15:01 -0500 Subject: [erlang-questions] erlang diameter dictionary In-Reply-To: References: Message-ID: Hi Anders, Thanks for your reply, Your suggestions are valuable. I am still playing with some trial code. So need to worry about name space convention for now. I think I did recompile everything with rebar (clean then compile). But I didn't continue with the rfc4006 dictionary. I redefined my CCR/CCA messages and received something back from peer with success code 2001. However I got decoding error. I debugged the decoding process. Something makes me confused. After splitting all AVPS, other AVPs are parsed ok, except two. One is like this, simple enum data: < Avps = [ {diameter_avp,1023,10415,true,false, <<0,0,0,0>>, undefined,undefined,undefined,7}, I think I defined the dictionary properly. For instance, the generated dictionary erlang file has the 1023 definition: avp_name(1023, undefined) -> {'Bearer-Control-Mode', 'Enumerated'}; avp_header('Bearer-Control-Mode') -> {1023, 64, undefined}; {avp_types, [{"Bearer-Control-Mode", 1023, "Enumerated", "M"}, But when I debug the Mod:decode_avps step by step, I don't see it try to step into the proper avp_name mapping and throw the error {5001, {diameter_avp,1023,10415,true,false, <<0,0,0,0>>, undefined,undefined,undefined,7}}, I saw it tried to parse with avp_name(443, undefined) -> {'Subscription-Id', 'Grouped'}; Do I misunderstand anything in diameter library? What I did wrong to cause this? How should I better understand the encode/decode process in diameter library? Could you please give me some suggestions? Thanks a lot! Samuel On Mon, Jan 27, 2014 at 4:52 AM, Anders Svensson wrote: > Hi Samuel. > > > How are you? > > Still kicking, thanks. :) > > > I have a question about modifying diameter dictionary. For example, for > > diameter CCR message, if I want to change "Service-Context-Id" from > > mandatory to non mandatory property so I don't have to fill this > property in > > the CCR message, I changed the file rfc4006_cc.dia as following: > > > > 1. Service-Context-Id 461 UTF8String - > > 2. Change from {Service-Context-id} to [Service-Context-Id] and move it > > below {CC-Request-Number} in CCR message definition > > Easy enough to do but if you send a CCR without Service-Context-Id to > a node expecting an RFC 4006 CCR then the request is likely to be > rejected. 1.3.3 of RFC 6733 requires a new Command Code when making > this specific modification. > > > Then I used diameterc to generate new erlang files accordingly. The files > > look good and I was able to compile. By the way, I include the diameter > > library source code from OTP release R16B03 into the project, just in > order > > to debug the diameter easily. > > > > I filled the CCR message as below: > > Just a couple of pointers before getting to the actual issue ... > > > CCR = #diameter_rfc4006_cc_CCR{ > > It's not a good idea to use diameter as a prefix here in case diameter > itself ships with a this dictionary one day. > > > 'Session-Id' = diameter:session_id(?L(who)), > > 'Auth-Application-Id' = 16777238, > > 'CC-Request-Type' = > > ?'DIAMETER_RFC4006_CC_CC-REQUEST-TYPE_INITIAL_REQUEST', > > These long macro names are truly hideous, at least if you like to be > able to maintain readable line lengths. (78 characters in my book.) At > best I'd redefine those I want to use. > > Eg. -define(INITIAL, > ?'DIAMETER_RFC4006_CC_CC-REQUEST-TYPE_INITIAL_REQUEST'). > > > 'CC-Request-Number' = 0 > > }, > > diameter:call(Name, ?APP_CCR_ALIAS, CCR, []). > > > > When I run from the erlang shell R16B03, I got the encoding error like > this: > > > > why: {diameter_codec,encode, > > {{mandatory_avp_missing,'CC-Request-Type','CCR'}, > > I suspect you haven't recompiled your source file after modifying the > dictionary. Records are just tuples, and fields in the record notation > are mapped to tuple indices using the record definition known to the > source in question. If the source creating the record above has the > "old" definition then the fields set as CC-Request-Type and > CC-Request-Number will be in the positions in which the "new" > dictionary module expects to find CC-Request-Number and > Service-Context-Id, leading to the "missing" CC-Request-Type error. > > That is, you need to recompile any source that includes a generated > hrl, in addition to loading the new dictionary module. > > > [{diameter_gen_rfc4006_cc,encode_avps,2, > > [{file, > > > > "/usr/lib/erlang/lib/diameter-1.5/include/diameter_gen.hrl"}, > > {line,59}]}, > > {diameter_codec,e,2, > > [{file,"src/diameter_codec.erl"},{line,120}]}, > > {diameter_codec,encode,2, > > [{file,"src/diameter_codec.erl"},{line,71}]}, > > {diameter_traffic,encode,3, > > [{file,"src/diameter_traffic.erl"},{line,1481}]}, > > {diameter_traffic,send_R,6, > > [{file,"src/diameter_traffic.erl"},{line,1320}]}, > > {diameter_traffic,'-send_request/4-fun-0-',6, > > [{file,"src/diameter_traffic.erl"},{line,1094}]}]}} > > who: <0.62.0> > > what: {diameter_codec,encode, > > [diameter_gen_rfc4006_cc, > > {diameter_packet, > > {diameter_header,1,undefined,undefined,undefined, > > 398339147,398339147,undefined,undefined,undefined, > > undefined}, > > undefined, > > {diameter_rfc4006_cc_CCR, > > ["who",";","1452024187",";","1",";","nonode@REDACTED > "], > > "centos","example.com","example.com",16777238, > > undefined,1,0, > > ["centos"], > > > > > > [],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[], > > []}, > > undefined,[],undefined}]} > > {error,encode} > > > > I don't really understand why getting this error or the error > information is > > a little bit confusing me. > > Am I doing right to modify the dictionary file? What is the proper way > to do > > that? > > Nothing wrong with the modification, aside from the fact that you're > straying from RFC 4006 Credit-Control as I mentioned above. > > > What is best way of debugging the diameter library? Can you give me some > > hints? > > In this case it's just confusion over record definitions I think, and > these are always confusing until you realize that different code might > have different record definitions. You can see the record being > encoded by tracing on diameter_codec:encode/2 for example, which would > show the unexpected positions of CC-Request-Type and CC-Request-Number > relative to your dictionary definition. > > /Anders, Erlang/OTP > > > > > > > Thanks a lot! > > > > Samuel > > > > > > On Sat, Mar 23, 2013 at 7:11 AM, Anders Svensson > > wrote: > >> > >> On Fri, Mar 22, 2013 at 7:52 PM, S X wrote: > >> > Hi Anders, > >> > > >> > Sorry, I think I understand now. You told me the solution. Just use '[ > >> > ]'. > >> > > >> > Anyhow, many thanks! > >> > > >> > By the way, since 3588 is obsolete, can I use 6733 while compile other > >> > dictionaries? > >> > >> Yes. /Anders > >> > >> > >> > > >> > Thanks! > >> > > >> > Samuel > >> > > >> > > >> > On Fri, Mar 22, 2013 at 2:46 PM, S X wrote: > >> >> > >> >> Hi Anders, > >> >> > >> >> Thanks for your quick response. But I still don't get why the DH is > >> >> being > >> >> interpreted as a list of Destination-Host values ( Is it because the > >> >> define > >> >> "avp_arity('CCR', 'Destination-Host') -> {0, 1};"). > >> >> > >> >> And if it is treated as a list, how come it has a length greater than > >> >> 1, I > >> >> just set it once in prepare_request. > >> >> > >> >> What should I do to correct it? Or which document should I read more > >> >> carefully to understand this properly? > >> >> > >> >> Thanks a lot! > >> >> > >> >> Samuel > >> >> > >> >> > >> >> On Fri, Mar 22, 2013 at 1:27 PM, Anders Svensson < > anders.otp@REDACTED> > >> >> wrote: > >> >>> > >> >>> Hi Samuel > >> >>> > >> >>> On Fri, Mar 22, 2013 at 5:55 PM, S X > wrote: > >> >>> > Thanks a lot, Anders, > >> >>> > > >> >>> > I think I overlooked what the meaning of the configurable ID tag > (4) > >> >>> > in > >> >>> > the > >> >>> > dia file is , which is supposed to be the important application ID > >> >>> > to > >> >>> > be > >> >>> > used in the configuration. Your suggestion about the prefix is > also > >> >>> > right. > >> >>> > But now I am just learning erlang diameter library. > >> >>> > > >> >>> > I just try to follow the sample RAR message style, and am still > >> >>> > having > >> >>> > issue > >> >>> > with sending CCR message. The client configuration now is: > >> >>> > > >> >>> > -define(SERVICE(Name), [{'Origin-Host', ?L(Name) ++ ".example.com > "}, > >> >>> > {'Origin-Realm', "example.com"}, > >> >>> > {'Vendor-Id', 193}, > >> >>> > {'Product-Name', "Client"}, > >> >>> > {'Auth-Application-Id', > >> >>> > [?DIAMETER_APP_ID_CCRA]}, > >> >>> > {application, [{alias, ?APP_CCR_ALIAS}, > >> >>> > {dictionary, > >> >>> > ?DIAMETER_DICT_CCRA}, > >> >>> > {module, > client_cb_ccra}]}]). > >> >>> > > >> >>> > Try to send CCR message: > >> >>> > > >> >>> > call(Name) -> > >> >>> > SId = diameter:session_id(?L(Name)), > >> >>> > CCR = #diameter_base_rfc4006_cc_CCR{ > >> >>> > 'Session-Id' = SId, > >> >>> > 'Service-Context-Id' = "Test", > >> >>> > 'CC-Request-Type' = > >> >>> > ?'DIAMETER_BASE_RFC4006_CC_CC-REQUEST-TYPE_INITIAL_REQUEST', > >> >>> > 'CC-Request-Number' = 0, > >> >>> > 'Auth-Application-Id' = ?DIAMETER_APP_ID_CCRA, > >> >>> > 'User-Name' = "Me"}, > >> >>> > diameter:call(Name, ?APP_CCR_ALIAS, CCR, []). > >> >>> > > >> >>> > > >> >>> > In the client callback module: > >> >>> > > >> >>> > prepare_request(#diameter_packet{msg = Rec}, _, {_, Caps}) -> > >> >>> > #diameter_caps{origin_host = {OH, DH}, > >> >>> > origin_realm = {OR, DR}} > >> >>> > = Caps, > >> >>> > > >> >>> > {send, Rec#diameter_base_rfc4006_cc_CCR{'Origin-Host' = OH, > >> >>> > 'Origin-Realm' = OR, > >> >>> > 'Destination-Host' = DH, > >> >>> > 'Destination-Realm' = DR}}. > >> >>> > > >> >>> > I got the error about AVP property: > >> >>> > > >> >>> > =ERROR REPORT==== 22-Mar-2013::00:17:31 === > >> >>> > why: {diameter_codec,encode, > >> >>> > {{repeated_avp_excessive_arity,'Destination-Host',1, > >> >>> > "server.example.com",'CCR'}, > >> >>> > >> >>> This is because Destination-Host is optional in CCR and AVP's are > >> >>> encoded differently in a message record depending on whether or not > >> >>> there can be exactly one occurrence: if so then the field value > should > >> >>> be the AVP value, if not then a list of AVP values. That is, your > CCR > >> >>> record should have > >> >>> > >> >>> 'Destination-Host' = [DH], > >> >>> > >> >>> in this case. > >> >>> > >> >>> > [{diameter_gen_base_rfc4006_cc,encode_avps,2, > >> >>> > > >> >>> > [{file,"diameter_gen_base_rfc4006_cc.erl"},{line,47}]}, > >> >>> > > >> >>> > {diameter_codec,e,2,[{file,"diameter_codec.erl"},{line,112}]}, > >> >>> > {diameter_codec,encode,2, > >> >>> > [{file,"diameter_codec.erl"},{line,63}]}, > >> >>> > {diameter_traffic,encode,3, > >> >>> > [{file,"diameter_traffic.erl"},{line,1437}]}, > >> >>> > {diameter_traffic,send_R,6, > >> >>> > [{file,"diameter_traffic.erl"},{line,1276}]}, > >> >>> > {diameter_traffic,'-send_request/4-fun-0-',4, > >> >>> > [{file,"diameter_traffic.erl"},{line,1050}]}]}} > >> >>> > who: <0.180.0> > >> >>> > what: {diameter_codec,encode, > >> >>> > [diameter_gen_base_rfc4006_cc, > >> >>> > {diameter_packet, > >> >>> > > {diameter_header,1,undefined,undefined,undefined, > >> >>> > > >> >>> > 1330492780,1330492780,undefined,undefined,undefined, > >> >>> > undefined}, > >> >>> > undefined, > >> >>> > {diameter_base_rfc4006_cc_CCR, > >> >>> > > >> >>> > ["client",";","1425429748",";","2",";","nonode@REDACTED"], > >> >>> > > >> >>> > "client.example.com","example.com","example.com",4, > >> >>> > > >> >>> > "Test",1,0,"server.example.com","Me",[],[],[],[],[],[], > >> >>> > [],[],[],[],[],[],[],[],[],[],[],[]}, > >> >>> > undefined,[],undefined}]} > >> >>> > > >> >>> > My understanding is that the client callback prepare_request sets > >> >>> > the > >> >>> > "Destination-Host" (retrievd via the CER/A done at earilier stage) > >> >>> > in > >> >>> > the > >> >>> > CCR message. So I should set it right. But seems I still > >> >>> > misunderstand > >> >>> > something. Does the error information > "repeated_avp_excessive_arity" > >> >>> > mean " > >> >>> > 0-1 Zero or one instance of the AVP MAY be present in the message. > >> >>> > It > >> >>> > is > >> >>> > >> >>> Yes, exactly. In your case your DH is being interpreted as list of > >> >>> Destination-Host values, and "excessive arity" is a result of that > >> >>> list having length greater than 1. > >> >>> > >> >>> /Anders, Erlang/OTP > >> >>> > >> >>> > >> >>> > considered an error if there is more than one instance of the AVP" > >> >>> > according > >> >>> > to rfc4006 spec? The erlang error message is not that > >> >>> > straightforward, > >> >>> > really confusing newbies:). > >> >>> > > >> >>> > Do you have any hints? (I hope I could provide some ramp up steps > >> >>> > for > >> >>> > other > >> >>> > people to learn with erlang diameter library after making it > >> >>> > work^_^) > >> >>> > > >> >>> > Many thanks, > >> >>> > > >> >>> > Samuel > >> >>> > > >> >>> > > >> >>> > > >> >>> > On Thu, Mar 21, 2013 at 8:59 AM, Anders Svensson > >> >>> > > >> >>> > wrote: > >> >>> >> > >> >>> >> On Thu, Mar 21, 2013 at 2:55 AM, S X > >> >>> >> wrote: > >> >>> >> > Hello, > >> >>> >> > > >> >>> >> > Sorry, I still have some problems with sending CCR/CCA > messages. > >> >>> >> > I > >> >>> >> > didn't > >> >>> >> > quite get how to configure multiple diameter applications > though > >> >>> >> > it > >> >>> >> > seems > >> >>> >> > clear when I read the diameter protocol. > >> >>> >> > > >> >>> >> > Based on the sample diameter code, I made the following > changes, > >> >>> >> > diameter_gen_base_rfc4006_cc is the dictionary generated with > >> >>> >> > rfc4006_cc.dia: > >> >>> >> > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Client > >> >>> >> > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ > >> >>> >> > > >> >>> >> > -define(SVC_NAME, ?MODULE). > >> >>> >> > -define(APP_ALIAS, ?MODULE). > >> >>> >> > -define(CALLBACK_MOD, client_cb). > >> >>> >> > -define(DIAMETER_DICT_CCRA, diameter_gen_base_rfc4006_cc). > >> >>> >> > > >> >>> >> > -define(L, atom_to_list). > >> >>> >> > > >> >>> >> > -define(SERVICE(Name), [{'Origin-Host', ?L(Name) ++ > >> >>> >> > ".example.com"}, > >> >>> >> > {'Origin-Realm', "example.com"}, > >> >>> >> > {'Vendor-Id', 0}, > >> >>> >> > {'Product-Name', "Client"}, > >> >>> >> > {'Auth-Application-Id', > >> >>> >> > [?DIAMETER_APP_ID_COMMON]}, > >> >>> >> > {application, [{alias, ?APP_ALIAS}, > >> >>> >> > {dictionary, > >> >>> >> > ?DIAMETER_DICT_CCRA}, > >> >>> >> > {module, > >> >>> >> > ?CALLBACK_MOD}]}]). > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Server > >> >>> >> > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ > >> >>> >> > > >> >>> >> > -define(DIAMETER_DICT_CCRA, diameter_gen_base_rfc4006_cc). > >> >>> >> > > >> >>> >> > init(State) -> > >> >>> >> > SvcName = ?MODULE, > >> >>> >> > SvcOpts = [{'Origin-Host', atom_to_list(SvcName) ++ > >> >>> >> > ".example.com"}, > >> >>> >> > {'Origin-Realm', "example.com"}, > >> >>> >> > {'Vendor-Id', 193}, > >> >>> >> > {'Product-Name', "Server"}, > >> >>> >> > {'Auth-Application-Id', > >> >>> >> > [?DIAMETER_APP_ID_COMMON]}, > >> >>> >> > {application, [{alias, ?MODULE}, > >> >>> >> > {dictionary, > ?DIAMETER_DICT_CCRA}, > >> >>> >> > {module, server_cb}]}], > >> >>> >> > TransportOpts = [{transport_module, diameter_tcp}, > >> >>> >> > {transport_config, [{reuseaddr, true}, > >> >>> >> > {ip, {127,0,0,1}}, {port, 3868}]}], > >> >>> >> > diameter:start(), > >> >>> >> > diameter:start_service(SvcName, SvcOpts), > >> >>> >> > diameter:add_transport(SvcName, {listen, TransportOpts}), > >> >>> >> > erlang:display("Set up diameter server completed!"), > >> >>> >> > {ok, State}. > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > I changed the callbacks client_cb and server_cb to handle > CCR/CCA > >> >>> >> > messages. > >> >>> >> > > >> >>> >> > > >> >>> >> > However, I got the following errors "app_not_configured". It > >> >>> >> > seems > >> >>> >> > the > >> >>> >> > configuration for applications is incorrect. How should I > >> >>> >> > configure > >> >>> >> > the > >> >>> >> > service properly? My understanding is I want to reuse CER/CEA > as > >> >>> >> > default > >> >>> >> > authorization application, but the erlang diameter doesn't > >> >>> >> > explain > >> >>> >> > how > >> >>> >> > to do > >> >>> >> > it. Or my understanding is incorrect at all. > >> >>> >> > >> >>> >> The problem is a mismatch between the application and > capabilities > >> >>> >> configuration in your SvcOpts: the 'Auth-Application-Id' tuple > >> >>> >> specifies the Application Id's that are advertised in the > outgoing > >> >>> >> CER/CEA (that diameter itself sends) while 'applications' > specifies > >> >>> >> corresponding dictionary modules. In your case, advertising the > >> >>> >> common > >> >>> >> application (0) during capabilities exchange but backing it up > with > >> >>> >> a > >> >>> >> dictionary that implement CC (4) is what causes things to go > south. > >> >>> >> > >> >>> >> What you want is something like this: > >> >>> >> > >> >>> >> {'Auth-Application-Id', [0,4]}, > >> >>> >> {application, [{alias, cc}, > >> >>> >> {dictionary, diameter_gen_base_rfc4006}, > >> >>> >> {module, [server_cb, cc]}], > >> >>> >> {application, [{alias, base}, > >> >>> >> {dictionary, diameter_gen_base_rfc6733}, > >> >>> >> {module, [server_cb, base]}]} > >> >>> >> > >> >>> >> That is, advertise both application with the Auth-Application-Id > >> >>> >> config and configure corresponding dictionaries with > 'application' > >> >>> >> config. You might prefer two different callback modules (instead > of > >> >>> >> an > >> >>> >> extra argument) but the point is to match your advertised > >> >>> >> capabilities > >> >>> >> with your configured dictionaries. > >> >>> >> > >> >>> >> On a side note, you shouldn't use a diameter prefix on your own > >> >>> >> dictionaries, so as not to collide with something diameter does > in > >> >>> >> the > >> >>> >> future. > >> >>> >> > >> >>> >> /Anders, Erlang/OTP > >> >>> >> > >> >>> >> > > >> >>> >> > =ERROR REPORT==== 20-Mar-2013::21:40:50 === > >> >>> >> > ** Generic server <0.3841.0> terminating > >> >>> >> > ** Last message in was {diameter, > >> >>> >> > {recv, > >> >>> >> > > >> >>> >> > <<1,0,0,124,128,0,1,1,0,0,0,0,101,222,1,72, > >> >>> >> > > >> >>> >> > 101,222,1,72,0,0,1,8,64,0,0,26,99,108,105, > >> >>> >> > > >> >>> >> > 101,110,116,46,101,120,97,109,112,108,101, > >> >>> >> > > >> >>> >> > 46,99,111,109,0,0,0,0,1,40,64,0,0,19,101, > >> >>> >> > > >> >>> >> > 120,97,109,112,108,101,46,99,111,109,0,0,0, > >> >>> >> > > >> >>> >> > 1,1,64,0,0,14,0,1,127,0,0,1,0,0,0,0,1,10,64, > >> >>> >> > > >> >>> >> > 0,0,12,0,0,0,193,0,0,1,13,0,0,0,14,67,108, > >> >>> >> > > >> >>> >> > 105,101,110,116,0,0,0,0,1,2,64,0,0,12,0,0,0, > >> >>> >> > 0>>}} > >> >>> >> > ** When Server state == > >> >>> >> > {state,recv_CER,accept,<0.3840.0>,<0.3842.0>, > >> >>> >> > diameter_gen_base_rfc3588, > >> >>> >> > {diameter_service,<0.50.0>, > >> >>> >> > > >> >>> >> > {diameter_caps,"server.example.com", > >> >>> >> > "example.com", > >> >>> >> > [{127,0,0,1}], > >> >>> >> > 193,"Server",[],[], > >> >>> >> > [0], > >> >>> >> > [],[],[],[],[]}, > >> >>> >> > [{diameter_app,server, > >> >>> >> > > >> >>> >> > diameter_gen_base_rfc4006_cc, > >> >>> >> > [server_cb], > >> >>> >> > server,4,false, > >> >>> >> > [{answer_errors,report}, > >> >>> >> > > >> >>> >> > {request_errors,answer_3xxx}]}]}, > >> >>> >> > false,exit} > >> >>> >> > ** Reason for termination == > >> >>> >> > ** {{badmatch,{error,{app_not_configured,0}}}, > >> >>> >> > [{diameter_peer_fsm,recv_CER,2, > >> >>> >> > > >> >>> >> > [{file,"src/diameter_peer_fsm.erl"},{line,849}]}, > >> >>> >> > {diameter_peer_fsm,build_answer,3, > >> >>> >> > > >> >>> >> > [{file,"src/diameter_peer_fsm.erl"},{line,680}]}, > >> >>> >> > {diameter_peer_fsm,send_answer,3, > >> >>> >> > > >> >>> >> > [{file,"src/diameter_peer_fsm.erl"},{line,647}]}, > >> >>> >> > {diameter_peer_fsm,handle_info,2, > >> >>> >> > > >> >>> >> > [{file,"src/diameter_peer_fsm.erl"},{line,292}]}, > >> >>> >> > > >> >>> >> > {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,607}]}, > >> >>> >> > > >> >>> >> > > {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]} > >> >>> >> > > >> >>> >> > > >> >>> >> > Could you give me some hints on this issue? The erlang debugger > >> >>> >> > is > >> >>> >> > not > >> >>> >> > easy > >> >>> >> > to use and call stack information is hard to read (when I show > >> >>> >> > the > >> >>> >> > trace > >> >>> >> > window, all the buttons for step/next/continue become > invisible). > >> >>> >> > The > >> >>> >> > diameter guidance explains the concept but no clear steps about > >> >>> >> > configuration. > >> >>> >> > > >> >>> >> > > >> >>> >> > Many thanks! > >> >>> >> > > >> >>> >> > Samuel > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > On Tue, Mar 12, 2013 at 12:10 PM, S X > > >> >>> >> > wrote: > >> >>> >> >> > >> >>> >> >> Hello, Anders & Andre, > >> >>> >> >> > >> >>> >> >> Thanks a lot for your quick responses and suggestions, which > >> >>> >> >> help > >> >>> >> >> me > >> >>> >> >> start > >> >>> >> >> to exploring Erlang world ^_^ > >> >>> >> >> > >> >>> >> >> I was able to generate based on the file rfc4006_cc.dia under > >> >>> >> >> the > >> >>> >> >> diameter/examples/dict folders. And understand a bit why and > how > >> >>> >> >> Erlang > >> >>> >> >> diameter protocol dictionaries are organized and maintained. > >> >>> >> >> > >> >>> >> >> Many thanks and talk to you later! > >> >>> >> >> > >> >>> >> >> Samuel > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> On Tue, Mar 12, 2013 at 7:44 AM, Anders Svensson > >> >>> >> >> > >> >>> >> >> wrote: > >> >>> >> >>> > >> >>> >> >>> Btw, there's an RFC 4006 dictionary (and a few more) under > >> >>> >> >>> diameter/examples/dict in the repo. > >> >>> >> >>> > >> >>> >> >>> /Anders, Erlang/OTP > >> >>> >> >>> > >> >>> >> >>> On Tue, Mar 12, 2013 at 10:32 AM, Andr? Graf > >> >>> >> >>> > >> >>> >> >>> wrote: > >> >>> >> >>> > Hello S(?) > >> >>> >> >>> > > >> >>> >> >>> > You have to come up with your own .dia file if the message > >> >>> >> >>> > types > >> >>> >> >>> > are > >> >>> >> >>> > not covered in the .dia files provided by Erlang. Your own > >> >>> >> >>> > .dia > >> >>> >> >>> > file > >> >>> >> >>> > will typically include the '@inherits > >> >>> >> >>> > diameter_gen_base_rfc3588' > >> >>> >> >>> > clause which imports the basic avp's from rfc3588. You then > >> >>> >> >>> > have > >> >>> >> >>> > to > >> >>> >> >>> > provide the missing avp's for your CCR/CCA message types, > and > >> >>> >> >>> > also > >> >>> >> >>> > define these messages. Thanks to the format of a .dia file > it > >> >>> >> >>> > is > >> >>> >> >>> > pretty much copy-pasting from the rfc4006. Once your .dia > >> >>> >> >>> > file > >> >>> >> >>> > is > >> >>> >> >>> > ready, you use diameterc to generate the .erl and .hrl > file. > >> >>> >> >>> > > >> >>> >> >>> > Hope that helped! > >> >>> >> >>> > > >> >>> >> >>> > BR/Andr? > >> >>> >> >>> > > >> >>> >> >>> > > >> >>> >> >>> > > >> >>> >> >>> > On 12 March 2013 04:58, S X > wrote: > >> >>> >> >>> >> Hello, > >> >>> >> >>> >> > >> >>> >> >>> >> I am new to Erlang and Diameter protocol. Wish someone > could > >> >>> >> >>> >> provide > >> >>> >> >>> >> some > >> >>> >> >>> >> suggestions on how to utilize the diameter library > properly > >> >>> >> >>> >> in > >> >>> >> >>> >> Erlang. > >> >>> >> >>> >> > >> >>> >> >>> >> For example, I want to send/receive some Gx messages, like > >> >>> >> >>> >> CCR > >> >>> >> >>> >> (Credit > >> >>> >> >>> >> Control Request), CCA(Credit Control Answer messages. But > I > >> >>> >> >>> >> notice > >> >>> >> >>> >> that > >> >>> >> >>> >> there are some predefined messages in erlang diameter > >> >>> >> >>> >> library. > >> >>> >> >>> >> As > >> >>> >> >>> >> my > >> >>> >> >>> >> understanding, should use the utility diameterc to > generate > >> >>> >> >>> >> erlang > >> >>> >> >>> >> header/source files based on dia files. There are few dia > >> >>> >> >>> >> files > >> >>> >> >>> >> under > >> >>> >> >>> >> otp/lib/diameter/src/dict folder, like acct_rfc6733.dia, > >> >>> >> >>> >> base_rfc3588.dia, > >> >>> >> >>> >> relay.dia, base_accounting.dia, base_rfc6733.dia. Those > >> >>> >> >>> >> files > >> >>> >> >>> >> don't > >> >>> >> >>> >> have > >> >>> >> >>> >> the definitions for Gx. > >> >>> >> >>> >> > >> >>> >> >>> >> How should I generate or where can I obtain dia files > which > >> >>> >> >>> >> have > >> >>> >> >>> >> support for > >> >>> >> >>> >> CCR/CCA message format? Are the dia files proprietary or > >> >>> >> >>> >> manufacturer > >> >>> >> >>> >> specific? Can I generate with the 3GPP spec? What are the > >> >>> >> >>> >> proper > >> >>> >> >>> >> steps? > >> >>> >> >>> >> > >> >>> >> >>> >> Thanks a lot! > >> >>> >> >>> >> > >> >>> >> >>> >> S > >> >>> >> >>> >> > >> >>> >> >>> >> > >> >>> >> >>> >> _______________________________________________ > >> >>> >> >>> >> 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 karol.urbanski@REDACTED Tue Feb 4 18:46:20 2014 From: karol.urbanski@REDACTED (Karol Urbanski) Date: Tue, 4 Feb 2014 18:46:20 +0100 Subject: [erlang-questions] "erlang-src" package upgrade breaks "syntax_tools" and rebar builds In-Reply-To: References: <20140203124402.GA653@dex.erlang-solutions.com> Message-ID: <20140204174620.GA2327@dex.erlang-solutions.com> Hi, are you on 64 bits? It looks like there was a problem building the repository indexes for saucy64. I've just rebuilt them, hopefully that fixes your issue. Best regards, Karol Urbanski On Tue, Feb 04, 2014 at 01:47:56PM +0200, Karolis Petrauskas wrote: > Hello, > > I still have problems using erlang package provided by esl. I am using > Kubuntu 13.10 and have the following line in > /etc/apt/sources.list.d/erlang-solutions.list: > > deb http://binaries.erlang-solutions.com/debian saucy contrib > > When running `sudo apt-get install erlang-src` I'm getting: > > The following packages have unmet dependencies: > erlang-src : Depends: erlang-base (>= 1:16.b.3-3) but 1:16.b.3 is > to be installed or > erlang-base-hipe (>= 1:16.b.3-3) > > The command `sudo apt-get install --reinstall erlang-base` installs > "erlang-base 1:16.b.3". > > I have cleaned by apt cache and updated the apt sources. > > Karolis > > On Mon, Feb 3, 2014 at 2:44 PM, Karol Urbanski > wrote: > > On Sat, Feb 01, 2014 at 02:27:22PM +0000, Roger Lipscombe wrote: > >> "The esl-erlang package is a file containg the complete installation: > >> it includes the Erlang/OTP platform and all of its applications. The > >> erlang package is a frontend to a number of smaller packages. > >> Currently we support both erlang and esl-erlang." > >> > >> I've just done another "apt-get update; apt-get upgrade", and there's > >> a whole heap of new packages (1:16.b.3-3), which appear to have fixed > >> the problem; so it looks like I got caught mid-push, or the version > >> number got messed up earlier. > >> > >> Either way, it all seems good now. > >> > >> Thanks, > >> Roger. > > > > Hi, > > > > we had a small mixup with the version numbers due to rushing the patch > > release. I'm glad to hear it works fine now, and sorry for the > > inconvenience! > > > > Best regards, > > Karol Urbanski > > _______________________________________________ > > 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 k.petrauskas@REDACTED Tue Feb 4 20:12:47 2014 From: k.petrauskas@REDACTED (Karolis Petrauskas) Date: Tue, 4 Feb 2014 21:12:47 +0200 Subject: [erlang-questions] "erlang-src" package upgrade breaks "syntax_tools" and rebar builds In-Reply-To: <20140204174620.GA2327@dex.erlang-solutions.com> References: <20140203124402.GA653@dex.erlang-solutions.com> <20140204174620.GA2327@dex.erlang-solutions.com> Message-ID: Hi, Yes I am on 64 bits. Thanks, it works fine now! Karolis On Tue, Feb 4, 2014 at 7:46 PM, Karol Urbanski wrote: > Hi, > > are you on 64 bits? It looks like there was a problem building the > repository indexes for saucy64. I've just rebuilt them, hopefully that > fixes your issue. > > Best regards, > Karol Urbanski > > On Tue, Feb 04, 2014 at 01:47:56PM +0200, Karolis Petrauskas wrote: >> Hello, >> >> I still have problems using erlang package provided by esl. I am using >> Kubuntu 13.10 and have the following line in >> /etc/apt/sources.list.d/erlang-solutions.list: >> >> deb http://binaries.erlang-solutions.com/debian saucy contrib >> >> When running `sudo apt-get install erlang-src` I'm getting: >> >> The following packages have unmet dependencies: >> erlang-src : Depends: erlang-base (>= 1:16.b.3-3) but 1:16.b.3 is >> to be installed or >> erlang-base-hipe (>= 1:16.b.3-3) >> >> The command `sudo apt-get install --reinstall erlang-base` installs >> "erlang-base 1:16.b.3". >> >> I have cleaned by apt cache and updated the apt sources. >> >> Karolis >> >> On Mon, Feb 3, 2014 at 2:44 PM, Karol Urbanski >> wrote: >> > On Sat, Feb 01, 2014 at 02:27:22PM +0000, Roger Lipscombe wrote: >> >> "The esl-erlang package is a file containg the complete installation: >> >> it includes the Erlang/OTP platform and all of its applications. The >> >> erlang package is a frontend to a number of smaller packages. >> >> Currently we support both erlang and esl-erlang." >> >> >> >> I've just done another "apt-get update; apt-get upgrade", and there's >> >> a whole heap of new packages (1:16.b.3-3), which appear to have fixed >> >> the problem; so it looks like I got caught mid-push, or the version >> >> number got messed up earlier. >> >> >> >> Either way, it all seems good now. >> >> >> >> Thanks, >> >> Roger. >> > >> > Hi, >> > >> > we had a small mixup with the version numbers due to rushing the patch >> > release. I'm glad to hear it works fine now, and sorry for the >> > inconvenience! >> > >> > Best regards, >> > Karol Urbanski >> > _______________________________________________ >> > 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 dch@REDACTED Tue Feb 4 22:34:50 2014 From: dch@REDACTED (Dave Cottlehuber) Date: Tue, 4 Feb 2014 22:34:50 +0100 Subject: [erlang-questions] building R14B04 64-bit in OSX 10.9.1 Mavericks with clang Message-ID: No matter what incantations I try, I just can?t get this to work.brew, kerl, all fail, even the mighty otp_build and configure can?t pull this rabbit out of the hat. Sample logs, although many variants were tried in vain: ? ? ./otp_build autoconf There?s a curious sed error in otp_build which looks unrelated: === running autoconf in lib/test_server/src sed: RE error: illegal byte sequence But we forge on heedless: ? ? ./configure --prefix=/usr/local/Cellar/erlang/R14B04 --enable-kernel-poll \ ? ? ? ? --enable-threads --enable-dynamic-ssl-lib --enable-shared-zlib \ ? ? ? ? --enable-smp-support --enable-hipe \ ? ? ? ? --enable-darwin-64bit --enable-m64-build Which produces a suspect build system name: ? ? configure: creating ./config.status ? ? config.status: creating emulator/i386-apple-darwin13.0.0/Makefile It fails each time at: Undefined symbols for architecture x86_64: ? "_bp_sched2ix", referenced from: ? ? ? _load_nif_2 in erl_nif.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[3]: *** [/ramdisk/otp-OTP_R14B04/bin/i386-apple-darwin13.0.0/beam.smp] Error 1 make[2]: *** [opt] Error 2 make[1]: *** [smp] Error 2 make: *** [emulator] Error 2 full logs at https://gist.github.com/dch/5a864bc0631022d58f57 Removing the --enable-darwin-64bit and --enable-m64-build doesn?t help much either: Undefined symbols for architecture i386: ? "_bp_sched2ix", referenced from: ? ? ? _load_nif_2 in erl_nif.o ld: symbol(s) not found for architecture i386 Is this even possible now? Should I try installing gcc42 instead & hope for the best? -- Dave Cottlehuber Sent from my PDP11 From paul.joseph.davis@REDACTED Tue Feb 4 22:59:24 2014 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Tue, 4 Feb 2014 15:59:24 -0600 Subject: [erlang-questions] building R14B04 64-bit in OSX 10.9.1 Mavericks with clang In-Reply-To: References: Message-ID: I'm pretty sure you only want one of the --enable-darwin-64bit or --enable-m64-build, not both. I haven't personally built on OS X 10.9 but I haven't heard anything similar from people who have. On Tue, Feb 4, 2014 at 3:34 PM, Dave Cottlehuber wrote: > No matter what incantations I try, I just can't get this to work.brew, kerl, all fail, even the mighty otp_build and configure can't pull this rabbit out of the hat. Sample logs, although many variants were tried in vain: > > ./otp_build autoconf > > There's a curious sed error in otp_build which looks unrelated: > > === running autoconf in lib/test_server/src > sed: RE error: illegal byte sequence > > But we forge on heedless: > > ./configure --prefix=/usr/local/Cellar/erlang/R14B04 --enable-kernel-poll \ > --enable-threads --enable-dynamic-ssl-lib --enable-shared-zlib \ > --enable-smp-support --enable-hipe \ > --enable-darwin-64bit --enable-m64-build > > Which produces a suspect build system name: > > configure: creating ./config.status > config.status: creating emulator/i386-apple-darwin13.0.0/Makefile > > It fails each time at: > > Undefined symbols for architecture x86_64: > "_bp_sched2ix", referenced from: > _load_nif_2 in erl_nif.o > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see invocation) > make[3]: *** [/ramdisk/otp-OTP_R14B04/bin/i386-apple-darwin13.0.0/beam.smp] Error 1 > make[2]: *** [opt] Error 2 > make[1]: *** [smp] Error 2 > make: *** [emulator] Error 2 > > full logs at https://gist.github.com/dch/5a864bc0631022d58f57 > > > Removing the --enable-darwin-64bit and --enable-m64-build doesn't help much either: > > Undefined symbols for architecture i386: > "_bp_sched2ix", referenced from: > _load_nif_2 in erl_nif.o > ld: symbol(s) not found for architecture i386 > > Is this even possible now? Should I try installing gcc42 instead & hope for the best? > > -- > Dave Cottlehuber > Sent from my PDP11 > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From paul.joseph.davis@REDACTED Tue Feb 4 23:02:23 2014 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Tue, 4 Feb 2014 16:02:23 -0600 Subject: [erlang-questions] building R14B04 64-bit in OSX 10.9.1 Mavericks with clang In-Reply-To: References: Message-ID: I asked Brian Mitchell and he says that R14 is known to not work with Clang but it works fine building it with gcc-4.2 on OS X 10.9. On Tue, Feb 4, 2014 at 3:59 PM, Paul Davis wrote: > I'm pretty sure you only want one of the --enable-darwin-64bit or > --enable-m64-build, not both. I haven't personally built on OS X 10.9 > but I haven't heard anything similar from people who have. > > On Tue, Feb 4, 2014 at 3:34 PM, Dave Cottlehuber wrote: >> No matter what incantations I try, I just can't get this to work.brew, kerl, all fail, even the mighty otp_build and configure can't pull this rabbit out of the hat. Sample logs, although many variants were tried in vain: >> >> ./otp_build autoconf >> >> There's a curious sed error in otp_build which looks unrelated: >> >> === running autoconf in lib/test_server/src >> sed: RE error: illegal byte sequence >> >> But we forge on heedless: >> >> ./configure --prefix=/usr/local/Cellar/erlang/R14B04 --enable-kernel-poll \ >> --enable-threads --enable-dynamic-ssl-lib --enable-shared-zlib \ >> --enable-smp-support --enable-hipe \ >> --enable-darwin-64bit --enable-m64-build >> >> Which produces a suspect build system name: >> >> configure: creating ./config.status >> config.status: creating emulator/i386-apple-darwin13.0.0/Makefile >> >> It fails each time at: >> >> Undefined symbols for architecture x86_64: >> "_bp_sched2ix", referenced from: >> _load_nif_2 in erl_nif.o >> ld: symbol(s) not found for architecture x86_64 >> clang: error: linker command failed with exit code 1 (use -v to see invocation) >> make[3]: *** [/ramdisk/otp-OTP_R14B04/bin/i386-apple-darwin13.0.0/beam.smp] Error 1 >> make[2]: *** [opt] Error 2 >> make[1]: *** [smp] Error 2 >> make: *** [emulator] Error 2 >> >> full logs at https://gist.github.com/dch/5a864bc0631022d58f57 >> >> >> Removing the --enable-darwin-64bit and --enable-m64-build doesn't help much either: >> >> Undefined symbols for architecture i386: >> "_bp_sched2ix", referenced from: >> _load_nif_2 in erl_nif.o >> ld: symbol(s) not found for architecture i386 >> >> Is this even possible now? Should I try installing gcc42 instead & hope for the best? >> >> -- >> Dave Cottlehuber >> Sent from my PDP11 >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions From mallen@REDACTED Tue Feb 4 23:39:29 2014 From: mallen@REDACTED (Mark Allen) Date: Tue, 4 Feb 2014 16:39:29 -0600 Subject: [erlang-questions] building R14B04 64-bit in OSX 10.9.1 Mavericks with clang In-Reply-To: References: Message-ID: This is how my tool erlbrew builds Erlang on OS X 10.9 https://github.com/mrallen1/erlbrew/blob/master/erlbrew#L122-L124 There's something about hipe and clang that just doesn't build properly; we don't need hipe for our particular implementations (we code on OS X, test; stage and run production on Linux) I think if you add --disable-hipe to your recipe, it should work without gcc4.2 Mark On 2/4/14 4:02 PM, "Paul Davis" wrote: >I asked Brian Mitchell and he says that R14 is known to not work with >Clang but it works fine building it with gcc-4.2 on OS X 10.9. > >On Tue, Feb 4, 2014 at 3:59 PM, Paul Davis >wrote: >> I'm pretty sure you only want one of the --enable-darwin-64bit or >> --enable-m64-build, not both. I haven't personally built on OS X 10.9 >> but I haven't heard anything similar from people who have. >> >> On Tue, Feb 4, 2014 at 3:34 PM, Dave Cottlehuber >>wrote: >>> No matter what incantations I try, I just can't get this to work.brew, >>>kerl, all fail, even the mighty otp_build and configure can't pull this >>>rabbit out of the hat. Sample logs, although many variants were tried >>>in vain: >>> >>> ./otp_build autoconf >>> >>> There's a curious sed error in otp_build which looks unrelated: >>> >>> === running autoconf in lib/test_server/src >>> sed: RE error: illegal byte sequence >>> >>> But we forge on heedless: >>> >>> ./configure --prefix=/usr/local/Cellar/erlang/R14B04 >>>--enable-kernel-poll \ >>> --enable-threads --enable-dynamic-ssl-lib --enable-shared-zlib >>>\ >>> --enable-smp-support --enable-hipe \ >>> --enable-darwin-64bit --enable-m64-build >>> >>> Which produces a suspect build system name: >>> >>> configure: creating ./config.status >>> config.status: creating emulator/i386-apple-darwin13.0.0/Makefile >>> >>> It fails each time at: >>> >>> Undefined symbols for architecture x86_64: >>> "_bp_sched2ix", referenced from: >>> _load_nif_2 in erl_nif.o >>> ld: symbol(s) not found for architecture x86_64 >>> clang: error: linker command failed with exit code 1 (use -v to see >>>invocation) >>> make[3]: *** >>>[/ramdisk/otp-OTP_R14B04/bin/i386-apple-darwin13.0.0/beam.smp] Error 1 >>> make[2]: *** [opt] Error 2 >>> make[1]: *** [smp] Error 2 >>> make: *** [emulator] Error 2 >>> >>> full logs at https://gist.github.com/dch/5a864bc0631022d58f57 >>> >>> >>> Removing the --enable-darwin-64bit and --enable-m64-build doesn't help >>>much either: >>> >>> Undefined symbols for architecture i386: >>> "_bp_sched2ix", referenced from: >>> _load_nif_2 in erl_nif.o >>> ld: symbol(s) not found for architecture i386 >>> >>> Is this even possible now? Should I try installing gcc42 instead & >>>hope for the best? >>> >>> -- >>> Dave Cottlehuber >>> Sent from my PDP11 >>> _______________________________________________ >>> 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 brian@REDACTED Tue Feb 4 23:38:14 2014 From: brian@REDACTED (Brian Mitchell) Date: Tue, 4 Feb 2014 17:38:14 -0500 Subject: [erlang-questions] building R14B04 64-bit in OSX 10.9.1 Mavericks with clang In-Reply-To: References: Message-ID: I'd add that I've only tested R14 releases with hipe disabled and apple's gcc-4.2 build. You can install apple's GCC via homebrew (brew install apple-gcc42) or by directly downloading the .pkg that formula references (see https://github.com/Homebrew/homebrew/blob/master/Library/Formula/apple-gcc42.rb). I believe Apple also hosts a few downloads but I can't confirm which ones hold the necessary files. >From there simply set CC=gcc-4.2 during configuration and things should work. On Tue, Feb 4, 2014 at 5:02 PM, Paul Davis wrote: > I asked Brian Mitchell and he says that R14 is known to not work with > Clang but it works fine building it with gcc-4.2 on OS X 10.9. > > On Tue, Feb 4, 2014 at 3:59 PM, Paul Davis wrote: >> I'm pretty sure you only want one of the --enable-darwin-64bit or >> --enable-m64-build, not both. I haven't personally built on OS X 10.9 >> but I haven't heard anything similar from people who have. >> >> On Tue, Feb 4, 2014 at 3:34 PM, Dave Cottlehuber wrote: >>> No matter what incantations I try, I just can't get this to work.brew, kerl, all fail, even the mighty otp_build and configure can't pull this rabbit out of the hat. Sample logs, although many variants were tried in vain: >>> >>> ./otp_build autoconf >>> >>> There's a curious sed error in otp_build which looks unrelated: >>> >>> === running autoconf in lib/test_server/src >>> sed: RE error: illegal byte sequence >>> >>> But we forge on heedless: >>> >>> ./configure --prefix=/usr/local/Cellar/erlang/R14B04 --enable-kernel-poll \ >>> --enable-threads --enable-dynamic-ssl-lib --enable-shared-zlib \ >>> --enable-smp-support --enable-hipe \ >>> --enable-darwin-64bit --enable-m64-build >>> >>> Which produces a suspect build system name: >>> >>> configure: creating ./config.status >>> config.status: creating emulator/i386-apple-darwin13.0.0/Makefile >>> >>> It fails each time at: >>> >>> Undefined symbols for architecture x86_64: >>> "_bp_sched2ix", referenced from: >>> _load_nif_2 in erl_nif.o >>> ld: symbol(s) not found for architecture x86_64 >>> clang: error: linker command failed with exit code 1 (use -v to see invocation) >>> make[3]: *** [/ramdisk/otp-OTP_R14B04/bin/i386-apple-darwin13.0.0/beam.smp] Error 1 >>> make[2]: *** [opt] Error 2 >>> make[1]: *** [smp] Error 2 >>> make: *** [emulator] Error 2 >>> >>> full logs at https://gist.github.com/dch/5a864bc0631022d58f57 >>> >>> >>> Removing the --enable-darwin-64bit and --enable-m64-build doesn't help much either: >>> >>> Undefined symbols for architecture i386: >>> "_bp_sched2ix", referenced from: >>> _load_nif_2 in erl_nif.o >>> ld: symbol(s) not found for architecture i386 >>> >>> Is this even possible now? Should I try installing gcc42 instead & hope for the best? >>> >>> -- >>> Dave Cottlehuber >>> Sent from my PDP11 >>> _______________________________________________ >>> 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 kjw0188@REDACTED Wed Feb 5 03:10:03 2014 From: kjw0188@REDACTED (Kelly Wong) Date: Tue, 4 Feb 2014 18:10:03 -0800 Subject: [erlang-questions] Mongoose IM Documentation Message-ID: Hello, I'm trying to setup Mongoose IM, but for the life of me can't find any documentation for it. Can anyone point me in the right direction? Thanks, Kelly Wong -------------- next part -------------- An HTML attachment was scrubbed... URL: From czinkos@REDACTED Wed Feb 5 09:45:14 2014 From: czinkos@REDACTED (Zsolt Czinkos) Date: Wed, 5 Feb 2014 09:45:14 +0100 Subject: [erlang-questions] json handling map functions in erlang 17 Message-ID: Hi, I've read about some json handling functions in Joe Armstrong's book (Programming Erlang, 2nd Edition, Page 84): maps:to_json/1, maps:from_json/1 and maps:safe_from_json/1. Now, In erlang shell, I see this. No such functions. > maps:module_info(exports). [{fold,3}, {map,2}, {size,1}, {without,2}, {module_info,0}, {module_info,1}, {values,1}, {update,3}, {remove,2}, {put,3}, {new,0}, {merge,2}, {keys,1}, {is_key,2}, {from_list,1}, {get,2}, {find,2}, {to_list,1}] Are these json functions planned to be released in final 17.0? Thanks, Zsolt From michael.eugene.turner@REDACTED Wed Feb 5 12:22:41 2014 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Wed, 5 Feb 2014 20:22:41 +0900 Subject: [erlang-questions] Any advice to a Java webhost company about Erlang hosting? Message-ID: I've need Java hosting. Legacy code in some cases, Unobtainium in Erlang for others. I've got Java hosting. I like the guy who does it. He's been doing it a long time. He's good at it. He's responsive. But he's hurting because of cloud services. He needs a new angle. I google on Erlang hosting. First link: somebody asking "where are the Erlang hosts?" Answer: sorry. http://stackoverflow.com/questions/5244703/hosting-for-erlang-application ... followed by a couple of recommendations to my host's competition for VPS and whatever. It looks like there's still a need to be filled - snap-together Erlang hosting - and some people looking for their next move in web hosting. This might be it. I guess in the case of Java web hosts, Erjang would be a place to start. Any suggestions? I can't exactly make a career of this at the moment, it's just an idea, but if it could eventually help somebody, and help get me Erlang's advantages .... 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 From vladdu55@REDACTED Wed Feb 5 12:26:18 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 5 Feb 2014 12:26:18 +0100 Subject: [erlang-questions] Any advice to a Java webhost company about Erlang hosting? In-Reply-To: References: Message-ID: Hi! http://appfog.com is advertising that it supports Erlang. Last time I checked, for some months ago, it wasn't available yet (but it was advertised). Check it out. regards, Vlad On Wed, Feb 5, 2014 at 12:22 PM, Michael Turner < michael.eugene.turner@REDACTED> wrote: > I've need Java hosting. Legacy code in some cases, Unobtainium in > Erlang for others. > > I've got Java hosting. I like the guy who does it. He's been doing it > a long time. He's good at it. He's responsive. But he's hurting > because of cloud services. He needs a new angle. > > I google on Erlang hosting. First link: somebody asking "where are the > Erlang hosts?" Answer: sorry. > > > http://stackoverflow.com/questions/5244703/hosting-for-erlang-application > > ... followed by a couple of recommendations to my host's competition > for VPS and whatever. > > It looks like there's still a need to be filled - snap-together Erlang > hosting - and some people looking for their next move in web hosting. > This might be it. I guess in the case of Java web hosts, Erjang would > be a place to start. Any suggestions? > > I can't exactly make a career of this at the moment, it's just an > idea, but if it could eventually help somebody, and help get me > Erlang's advantages .... > > 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 > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Wed Feb 5 12:28:32 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Wed, 5 Feb 2014 13:28:32 +0200 Subject: [erlang-questions] Any advice to a Java webhost company about Erlang hosting? In-Reply-To: References: Message-ID: Hi, AWS EC2 - Dmitry On 05 Feb 2014, at 13:26, Vlad Dumitrescu wrote: > Hi! > > http://appfog.com is advertising that it supports Erlang. Last time I checked, for some months ago, it wasn't available yet (but it was advertised). Check it out. > > regards, > Vlad > > > > On Wed, Feb 5, 2014 at 12:22 PM, Michael Turner wrote: > I've need Java hosting. Legacy code in some cases, Unobtainium in > Erlang for others. > > I've got Java hosting. I like the guy who does it. He's been doing it > a long time. He's good at it. He's responsive. But he's hurting > because of cloud services. He needs a new angle. > > I google on Erlang hosting. First link: somebody asking "where are the > Erlang hosts?" Answer: sorry. > > http://stackoverflow.com/questions/5244703/hosting-for-erlang-application > > ... followed by a couple of recommendations to my host's competition > for VPS and whatever. > > It looks like there's still a need to be filled - snap-together Erlang > hosting - and some people looking for their next move in web hosting. > This might be it. I guess in the case of Java web hosts, Erjang would > be a place to start. Any suggestions? > > I can't exactly make a career of this at the moment, it's just an > idea, but if it could eventually help somebody, and help get me > Erlang's advantages .... > > 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 > _______________________________________________ > 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 Feb 5 12:31:22 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 05 Feb 2014 12:31:22 +0100 Subject: [erlang-questions] Any advice to a Java webhost company about Erlang hosting? In-Reply-To: References: Message-ID: <52F2210A.4090905@ninenines.eu> Pardon my ignorance but what does a Java hosting company do exactly compared to just getting a server? I ask because for my small Erlang apps I just have a 3?/month dedicated and have next to no admin to do once a quick initial setup as I just push releases to it (the machine doesn't have nor need Erlang installed). Supporting medium to big Erlang apps would require something closer to a basic "cloud" but same story past that point, just push the releases and be done with it. On 02/05/2014 12:22 PM, Michael Turner wrote: > I've need Java hosting. Legacy code in some cases, Unobtainium in > Erlang for others. > > I've got Java hosting. I like the guy who does it. He's been doing it > a long time. He's good at it. He's responsive. But he's hurting > because of cloud services. He needs a new angle. > > I google on Erlang hosting. First link: somebody asking "where are the > Erlang hosts?" Answer: sorry. > > http://stackoverflow.com/questions/5244703/hosting-for-erlang-application > > ... followed by a couple of recommendations to my host's competition > for VPS and whatever. > > It looks like there's still a need to be filled - snap-together Erlang > hosting - and some people looking for their next move in web hosting. > This might be it. I guess in the case of Java web hosts, Erjang would > be a place to start. Any suggestions? > > I can't exactly make a career of this at the moment, it's just an > idea, but if it could eventually help somebody, and help get me > Erlang's advantages .... > > 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 > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From vances@REDACTED Wed Feb 5 13:44:28 2014 From: vances@REDACTED (Vance Shipley) Date: Wed, 5 Feb 2014 18:14:28 +0530 Subject: [erlang-questions] Any advice to a Java webhost company about Erlang hosting? In-Reply-To: <52F2210A.4090905@ninenines.eu> References: <52F2210A.4090905@ninenines.eu> Message-ID: On Feb 5, 2014 5:01 PM, "Lo?c Hoguin" wrote: > > Pardon my ignorance but what does a Java hosting company do exactly compared to just getting a server? When I hear "Java hosting" or "Erlang hosting" I think of cloud environments which provide JVM or BEAM virtual machines (emulators) where you aren't bothered by operating systems. You pay for instances of the VMs and transactional bandwidth. This is what Google AppEngine provides for Java, Python and Go. I've developed cloud services using Go on Appengine and it was wonderfully clean and simple. One future for Erlang may be the LING VM from http://erlangonxen.com which runs directly on the Xen hypervisor which is wicked cool. I've got big hope for this. But in practice I'm sure that it means Linux VMs with Erlang/OTP preinstalled. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.eugene.turner@REDACTED Wed Feb 5 14:28:57 2014 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Wed, 5 Feb 2014 22:28:57 +0900 Subject: [erlang-questions] Any advice to a Java webhost company about Erlang hosting? In-Reply-To: References: <52F2210A.4090905@ninenines.eu> Message-ID: > Pardon my ignorance but what does a Java hosting company do exactly compared to just getting a server? I love it when people say "just" about things like this. I'd like to get them slightly drunk and make them a bet: for every minute /under/ the amount they estimate that setup will take, I'll pay them $5. For every minute /over/ their estimate, /I/ get $5. I'd probably be able to retire early just by going to hacker meetups and offering to buy a round for everybody at a bar nearby. > wonderfully clean and simple. Yes. Please. 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 Wed, Feb 5, 2014 at 9:44 PM, Vance Shipley wrote: > > On Feb 5, 2014 5:01 PM, "Lo?c Hoguin" wrote: >> >> Pardon my ignorance but what does a Java hosting company do exactly >> compared to just getting a server? > > When I hear "Java hosting" or "Erlang hosting" I think of cloud environments > which provide JVM or BEAM virtual machines (emulators) where you aren't > bothered by operating systems. You pay for instances of the VMs and > transactional bandwidth. This is what Google AppEngine provides for Java, > Python and Go. I've developed cloud services using Go on Appengine and it > was wonderfully clean and simple. > > One future for Erlang may be the LING VM from http://erlangonxen.com which > runs directly on the Xen hypervisor which is wicked cool. I've got big hope > for this. > > But in practice I'm sure that it means Linux VMs with Erlang/OTP > preinstalled. From ivan@REDACTED Wed Feb 5 14:49:42 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Wed, 5 Feb 2014 13:49:42 +0000 Subject: [erlang-questions] Any advice to a Java webhost company about Erlang hosting? In-Reply-To: References: <52F2210A.4090905@ninenines.eu> Message-ID: <085117A3-808F-49A3-B865-CD38DE79910B@llaisdy.com> Isn't (part of) the point of erlang releases that you don't need erlang pre-installed? Ivan -- festina lente > On 5 Feb 2014, at 12:44, Vance Shipley wrote: > > > On Feb 5, 2014 5:01 PM, "Lo?c Hoguin" wrote: > > > > Pardon my ignorance but what does a Java hosting company do exactly compared to just getting a server? > > When I hear "Java hosting" or "Erlang hosting" I think of cloud environments which provide JVM or BEAM virtual machines (emulators) where you aren't bothered by operating systems. You pay for instances of the VMs and transactional bandwidth. This is what Google AppEngine provides for Java, Python and Go. I've developed cloud services using Go on Appengine and it was wonderfully clean and simple. > > One future for Erlang may be the LING VM from http://erlangonxen.com which runs directly on the Xen hypervisor which is wicked cool. I've got big hope for this. > > But in practice I'm sure that it means Linux VMs with Erlang/OTP preinstalled. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Wed Feb 5 14:55:33 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Wed, 5 Feb 2014 15:55:33 +0200 Subject: [erlang-questions] Any advice to a Java webhost company about Erlang hosting? In-Reply-To: <085117A3-808F-49A3-B865-CD38DE79910B@llaisdy.com> References: <52F2210A.4090905@ninenines.eu> <085117A3-808F-49A3-B865-CD38DE79910B@llaisdy.com> Message-ID: Hello, The release is extremely great feature, from my perspective. You can product ?self? deployable packages with help of bash magic. This makes not needs to have Erlang pre-installend on any of the target machines. - Dmitry On 05 Feb 2014, at 15:49, Ivan Uemlianin wrote: > Isn't (part of) the point of erlang releases that you don't need erlang pre-installed? > > Ivan > > -- > festina lente > > > On 5 Feb 2014, at 12:44, Vance Shipley wrote: > >> >> On Feb 5, 2014 5:01 PM, "Lo?c Hoguin" wrote: >> > >> > Pardon my ignorance but what does a Java hosting company do exactly compared to just getting a server? >> >> When I hear "Java hosting" or "Erlang hosting" I think of cloud environments which provide JVM or BEAM virtual machines (emulators) where you aren't bothered by operating systems. You pay for instances of the VMs and transactional bandwidth. This is what Google AppEngine provides for Java, Python and Go. I've developed cloud services using Go on Appengine and it was wonderfully clean and simple. >> >> One future for Erlang may be the LING VM from http://erlangonxen.com which runs directly on the Xen hypervisor which is wicked cool. I've got big hope for this. >> >> But in practice I'm sure that it means Linux VMs with Erlang/OTP preinstalled. >> _______________________________________________ >> 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 sean@REDACTED Wed Feb 5 14:57:51 2014 From: sean@REDACTED (Sean Cribbs) Date: Wed, 5 Feb 2014 14:57:51 +0100 Subject: [erlang-questions] Any advice to a Java webhost company about Erlang hosting? In-Reply-To: References: <52F2210A.4090905@ninenines.eu> <085117A3-808F-49A3-B865-CD38DE79910B@llaisdy.com> Message-ID: I'm sure Tristan and Geoff will tell you, there is a buildpack that makes it pretty easy to deploy Erlang applications on Heroku. It doesn't build releases, but it does builds and deploys your project directly from a "git push", which is pretty awesome. https://github.com/archaelus/heroku-buildpack-erlang On Wed, Feb 5, 2014 at 2:55 PM, Dmitry Kolesnikov wrote: > Hello, > > The release is extremely great feature, from my perspective. > You can product ?self? deployable packages with help of bash magic. > This makes not needs to have Erlang pre-installend on any of the target > machines. > > - Dmitry > > On 05 Feb 2014, at 15:49, Ivan Uemlianin wrote: > > Isn't (part of) the point of erlang releases that you don't need erlang > pre-installed? > > Ivan > > -- > festina lente > > > On 5 Feb 2014, at 12:44, Vance Shipley wrote: > > > On Feb 5, 2014 5:01 PM, "Lo?c Hoguin" wrote: > > > > Pardon my ignorance but what does a Java hosting company do exactly > compared to just getting a server? > > When I hear "Java hosting" or "Erlang hosting" I think of cloud > environments which provide JVM or BEAM virtual machines (emulators) where > you aren't bothered by operating systems. You pay for instances of the VMs > and transactional bandwidth. This is what Google AppEngine provides for > Java, Python and Go. I've developed cloud services using Go on Appengine > and it was wonderfully clean and simple. > > One future for Erlang may be the LING VM from http://erlangonxen.comwhich runs directly on the Xen hypervisor which is wicked cool. I've got > big hope for this. > > But in practice I'm sure that it means Linux VMs with Erlang/OTP > preinstalled. > > _______________________________________________ > 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 > > -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.nijhof@REDACTED Wed Feb 5 15:07:19 2014 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Wed, 5 Feb 2014 15:07:19 +0100 Subject: [erlang-questions] Any advice to a Java webhost company about Erlang hosting? In-Reply-To: References: <52F2210A.4090905@ninenines.eu> <085117A3-808F-49A3-B865-CD38DE79910B@llaisdy.com> Message-ID: That build pack seems out of date, I looked at this for a little while back for a personal little thing but I think it was for r15. Is there an updated fork, or does it just work? -Mark On Wed, Feb 5, 2014 at 2:57 PM, Sean Cribbs wrote: > I'm sure Tristan and Geoff will tell you, there is a buildpack that makes > it pretty easy to deploy Erlang applications on Heroku. It doesn't build > releases, but it does builds and deploys your project directly from a "git > push", which is pretty awesome. > > https://github.com/archaelus/heroku-buildpack-erlang > > > On Wed, Feb 5, 2014 at 2:55 PM, Dmitry Kolesnikov wrote: > >> Hello, >> >> The release is extremely great feature, from my perspective. >> You can product "self" deployable packages with help of bash magic. >> This makes not needs to have Erlang pre-installend on any of the target >> machines. >> >> - Dmitry >> >> On 05 Feb 2014, at 15:49, Ivan Uemlianin wrote: >> >> Isn't (part of) the point of erlang releases that you don't need erlang >> pre-installed? >> >> Ivan >> >> -- >> festina lente >> >> >> On 5 Feb 2014, at 12:44, Vance Shipley wrote: >> >> >> On Feb 5, 2014 5:01 PM, "Lo?c Hoguin" wrote: >> > >> > Pardon my ignorance but what does a Java hosting company do exactly >> compared to just getting a server? >> >> When I hear "Java hosting" or "Erlang hosting" I think of cloud >> environments which provide JVM or BEAM virtual machines (emulators) where >> you aren't bothered by operating systems. You pay for instances of the VMs >> and transactional bandwidth. This is what Google AppEngine provides for >> Java, Python and Go. I've developed cloud services using Go on Appengine >> and it was wonderfully clean and simple. >> >> One future for Erlang may be the LING VM from http://erlangonxen.comwhich runs directly on the Xen hypervisor which is wicked cool. I've got >> big hope for this. >> >> But in practice I'm sure that it means Linux VMs with Erlang/OTP >> preinstalled. >> >> _______________________________________________ >> 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 >> >> > > > -- > Sean Cribbs > Software Engineer > Basho Technologies, Inc. > http://basho.com/ > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Mark Nijhof t: @MarkNijhof s: marknijhof -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Wed Feb 5 15:08:09 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 5 Feb 2014 15:08:09 +0100 Subject: [erlang-questions] r17 debugger doesn't support maps yet Message-ID: Hi, I hope this is already known, but the debugger crashes when interpreting modules with maps. best regards, Vlad {{badmatch, {dbg_iload, {unknown_expr, {map,18, [{map_field_assoc,18,{integer,18,2},{integer,18,3}}, {map_field_assoc,18,{integer,18,4},{integer,18,5}}]}}}}, [{dbg_iserver,handle_call,3, [{file, "c:/Apps/erlide/org.erlide.kernel.debugger/src/dbg_iserver.erl"}, {line,228}]}, {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,585}]}, {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]} -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Wed Feb 5 15:10:36 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Wed, 5 Feb 2014 16:10:36 +0200 Subject: [erlang-questions] Any advice to a Java webhost company about Erlang hosting? In-Reply-To: References: <52F2210A.4090905@ninenines.eu> <085117A3-808F-49A3-B865-CD38DE79910B@llaisdy.com> Message-ID: <4C897AAA-CFFE-47F1-952D-AE102F215EB0@gmail.com> Yes, I was following the Heroku progress. It looks awesome to me. But we are still stack with old, good AWS EC2... - Dmitry On 05 Feb 2014, at 15:57, Sean Cribbs wrote: > I'm sure Tristan and Geoff will tell you, there is a buildpack that makes it pretty easy to deploy Erlang applications on Heroku. It doesn't build releases, but it does builds and deploys your project directly from a "git push", which is pretty awesome. > > https://github.com/archaelus/heroku-buildpack-erlang > > > On Wed, Feb 5, 2014 at 2:55 PM, Dmitry Kolesnikov wrote: > Hello, > > The release is extremely great feature, from my perspective. > You can product ?self? deployable packages with help of bash magic. > This makes not needs to have Erlang pre-installend on any of the target machines. > > - Dmitry > > On 05 Feb 2014, at 15:49, Ivan Uemlianin wrote: > >> Isn't (part of) the point of erlang releases that you don't need erlang pre-installed? >> >> Ivan >> >> -- >> festina lente >> >> >> On 5 Feb 2014, at 12:44, Vance Shipley wrote: >> >>> >>> On Feb 5, 2014 5:01 PM, "Lo?c Hoguin" wrote: >>> > >>> > Pardon my ignorance but what does a Java hosting company do exactly compared to just getting a server? >>> >>> When I hear "Java hosting" or "Erlang hosting" I think of cloud environments which provide JVM or BEAM virtual machines (emulators) where you aren't bothered by operating systems. You pay for instances of the VMs and transactional bandwidth. This is what Google AppEngine provides for Java, Python and Go. I've developed cloud services using Go on Appengine and it was wonderfully clean and simple. >>> >>> One future for Erlang may be the LING VM from http://erlangonxen.com which runs directly on the Xen hypervisor which is wicked cool. I've got big hope for this. >>> >>> But in practice I'm sure that it means Linux VMs with Erlang/OTP preinstalled. >>> _______________________________________________ >>> 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 > > > > > -- > Sean Cribbs > Software Engineer > Basho Technologies, Inc. > http://basho.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed Feb 5 15:28:53 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 05 Feb 2014 15:28:53 +0100 Subject: [erlang-questions] Any advice to a Java webhost company about Erlang hosting? In-Reply-To: References: <52F2210A.4090905@ninenines.eu> Message-ID: <52F24AA5.6030804@ninenines.eu> On 02/05/2014 02:28 PM, Michael Turner wrote: >> Pardon my ignorance but what does a Java hosting company do exactly compared to just getting a server? > > I love it when people say "just" about things like this. I'd like to > get them slightly drunk and make them a bet: for every minute /under/ > the amount they estimate that setup will take, I'll pay them $5. For > every minute /over/ their estimate, /I/ get $5. I'd probably be able > to retire early just by going to hacker meetups and offering to buy a > round for everybody at a bar nearby. Perhaps instead of trying to be a smartass you could actually have answered the question so people get a better idea what a Java hosting company actually does? Not everyone has Java production experience here. I only know Erlang myself. With Erlang, the only dependency you need on top of the base system is openssl. Then you can use releases just fine. Of course, openssl is already installed when you rent a server because it's an openssh dependency. So you pretty much have nothing to install. So the only setup you actually need to do is customize the environment like you want to, which you have to do regardless of the hosting solution. For example changing a few sysctl values, opening ports or creating a couple users. Things a script does just fine, if you need to automate it. Past initial setup, you do have to upgrade the server yourself, but this only takes me at most a few minutes per upgrade with Arch Linux, because this is a rolling release and I already did the same operation for my laptop so I already know if there's something other than pacman -Syu that needs to be done. And since this is just a base system + openssl, the updates are actually very few. If I have ten servers, then I just use cssh or similar and do the ten servers in one go so the time it takes to handle more servers is barely more than the time it takes to handle one. Hence my question. What do Java hosting companies do and what benefits do you have going with a company compared to doing it yourself? I do not think there is any benefit to going with an Erlang hosting company unless it provides some sort of elastic cloud along with advanced tools to quickly manage or inspect the running nodes. For example a way to remove a node from receiving external requests temporarily to inspect its state and debug an issue without having to fight for resources or risk inconveniencing users. But that's only needed by medium to big systems, plenty of smaller applications couldn't care less about it. -- Lo?c Hoguin http://ninenines.eu From dmkolesnikov@REDACTED Wed Feb 5 15:33:16 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Wed, 5 Feb 2014 16:33:16 +0200 Subject: [erlang-questions] Any advice to a Java webhost company about Erlang hosting? In-Reply-To: <52F24AA5.6030804@ninenines.eu> References: <52F2210A.4090905@ninenines.eu> <52F24AA5.6030804@ninenines.eu> Message-ID: <6453EAAD-8BCA-43B7-87AB-8A9D46FE0323@gmail.com> Hello, One small correction here. You do not need openssl as dependencies if you disable dynamic-ssl while building OTP. In this case release becomes self-containing (unless you are using some other features like jinterface, wx, etc). - Dmitry On 05 Feb 2014, at 16:28, Lo?c Hoguin wrote: > On 02/05/2014 02:28 PM, Michael Turner wrote: >>> Pardon my ignorance but what does a Java hosting company do exactly compared to just getting a server? >> >> I love it when people say "just" about things like this. I'd like to >> get them slightly drunk and make them a bet: for every minute /under/ >> the amount they estimate that setup will take, I'll pay them $5. For >> every minute /over/ their estimate, /I/ get $5. I'd probably be able >> to retire early just by going to hacker meetups and offering to buy a >> round for everybody at a bar nearby. > > Perhaps instead of trying to be a smartass you could actually have answered the question so people get a better idea what a Java hosting company actually does? Not everyone has Java production experience here. > > I only know Erlang myself. With Erlang, the only dependency you need on top of the base system is openssl. Then you can use releases just fine. Of course, openssl is already installed when you rent a server because it's an openssh dependency. So you pretty much have nothing to install. > > So the only setup you actually need to do is customize the environment like you want to, which you have to do regardless of the hosting solution. For example changing a few sysctl values, opening ports or creating a couple users. Things a script does just fine, if you need to automate it. > > Past initial setup, you do have to upgrade the server yourself, but this only takes me at most a few minutes per upgrade with Arch Linux, because this is a rolling release and I already did the same operation for my laptop so I already know if there's something other than pacman -Syu that needs to be done. And since this is just a base system + openssl, the updates are actually very few. > > If I have ten servers, then I just use cssh or similar and do the ten servers in one go so the time it takes to handle more servers is barely more than the time it takes to handle one. > > Hence my question. What do Java hosting companies do and what benefits do you have going with a company compared to doing it yourself? > > I do not think there is any benefit to going with an Erlang hosting company unless it provides some sort of elastic cloud along with advanced tools to quickly manage or inspect the running nodes. For example a way to remove a node from receiving external requests temporarily to inspect its state and debug an issue without having to fight for resources or risk inconveniencing users. But that's only needed by medium to big systems, plenty of smaller applications couldn't care less about it. > > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From psidrinal@REDACTED Wed Feb 5 15:37:59 2014 From: psidrinal@REDACTED (Raphael Korsoski) Date: Wed, 5 Feb 2014 15:37:59 +0100 Subject: [erlang-questions] printed maps look confusing In-Reply-To: References: <52EFA099.7020204@ninenines.eu> Message-ID: Guillemets are available to most X/Gnome users even on (int'l) American keyboards, but I guess Windows and unusual desktops in *nix environments put an end to that. In most linux distros, guillemets are available as 2-mod-z (Alt-Gr-z) and 2-mod-x (Alt-Gr-x) on qwerty/Scholes keyboards. I'm thinking about APL, though, and feel that perhaps ASCII is still good enough. There are some unicode symbols I wouldn't mind using in code, but the example with APL kind of scares me.... On Wed, Feb 5, 2014 at 3:37 PM, Raphael Korsoski wrote: > Guillemets are available to most X/Gnome users even on (int'l) American > keyboards, but I guess Windows and unusual desktops in *nix environments > put an end to that. > > In most linux distros, guillemets are available as 2-mod-z (Alt-Gr-z) and > 2-mod-x (Alt-Gr-x) on qwerty/Scholes keyboards. > > I'm thinking about APL, though, and feel that perhaps ASCII is still good > enough. There are some unicode symbols I wouldn't mind using in code, but > the example with APL kind of scares me.... > > > On Mon, Feb 3, 2014 at 3:15 PM, Vlad Dumitrescu wrote: > >> Yes, I hope you noticed the smilie. If guillemets could have been >> accessed from keyboards, they would be useful. >> >> /Vlad >> >> >> On Mon, Feb 3, 2014 at 3:11 PM, Max Lapshin wrote: >> >>> It is a very bad thing to use for pretty-print letters that you cannot >>> use in copy-paste. >>> >>> >>> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidnwelton@REDACTED Wed Feb 5 15:51:06 2014 From: davidnwelton@REDACTED (David Welton) Date: Wed, 5 Feb 2014 15:51:06 +0100 Subject: [erlang-questions] Tracing traffic between nodes In-Reply-To: References: <1391439049.4825.34.camel@sekic1152.release> Message-ID: This is surprisingly difficult. It seems that if there are two Erlang nodes, my code would probably work. If there's a C node involved, it seems that replacing message sends/receives in the C code with something that does the proper logging is the best bet, as I don't think the Erlang runtime environment is up to the task: it simply does not know where messages come from. Wireshark has an Erlang distribution parser, which is pretty cool, but because of cacheing of atoms, it's not something you can just start up and have work, either, in terms of having a log of what was actually sent where. -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From michael.eugene.turner@REDACTED Wed Feb 5 16:03:49 2014 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Thu, 6 Feb 2014 00:03:49 +0900 Subject: [erlang-questions] Any advice to a Java webhost company about Erlang hosting? In-Reply-To: <52F24AA5.6030804@ninenines.eu> References: <52F2210A.4090905@ninenines.eu> <52F24AA5.6030804@ninenines.eu> Message-ID: On Wed, Feb 5, 2014 at 11:28 PM, Lo?c Hoguin wrote: > On 02/05/2014 02:28 PM, Michael Turner wrote: >>> >>> Pardon my ignorance but what does a Java hosting company do exactly >>> compared to just getting a server? >> >> >> I love it when people say "just" about things like this. I'd like to >> get them slightly drunk and make them a bet: for every minute /under/ >> the amount they estimate that setup will take, I'll pay them $5. For >> every minute /over/ their estimate, /I/ get $5. I'd probably be able >> to retire early just by going to hacker meetups and offering to buy a >> round for everybody at a bar nearby. > > > Perhaps instead of trying to be a smartass you could actually have answered > the question so people get a better idea what a Java hosting company > actually does? Not everyone has Java production experience here. Neither do I, actually. I was asking out of curiosity, since he did mention this business problem. The actual service is this: http://www.metawerx.net/ I don't even know if it's typical -- but he's in Australia, I'm in Japan, and I like the rough time-zone alignment for purposes of support. > Hence my question. What do Java hosting companies do and what benefits do > you have going with a company compared to doing it yourself? It gives me access to someone who has long experience specializing in something I know almost nothing about, and who apparently feels a sense of obligation about making stuff work for his customers. I've struggled with a couple of other hosting companies (on other tasks, not Java-related) where tech support was wretchedly bad, from people who were ignorant, ultimately leaving me to figure things out on my own, and who tried to cover up their ignorance when it was pointed out. This is, if nothing else, a refreshing change. I'm sorry I gave such offense with my idea of how to make money from techie overestimates of task completion times. You're welcome to use it to make money yourself, since I have no business-model patent on it. I'm sure you'll make at least $60 on your first night. -michael turner From n.oxyde@REDACTED Wed Feb 5 16:08:29 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 5 Feb 2014 16:08:29 +0100 Subject: [erlang-questions] r17 debugger doesn't support maps yet In-Reply-To: References: Message-ID: <8D5202FA-4888-4D7C-9416-CDF4CB5EF2BE@gmail.com> https://github.com/erlang/otp/pull/213 -- Anthony Ramine Le 5 f?vr. 2014 ? 15:08, Vlad Dumitrescu a ?crit : > Hi, > > I hope this is already known, but the debugger crashes when interpreting modules with maps. > > best regards, > Vlad > > {{badmatch, > {dbg_iload, > {unknown_expr, > {map,18, > [{map_field_assoc,18,{integer,18,2},{integer,18,3}}, > {map_field_assoc,18,{integer,18,4},{integer,18,5}}]}}}}, > [{dbg_iserver,handle_call,3, > [{file, > "c:/Apps/erlide/org.erlide.kernel.debugger/src/dbg_iserver.erl"}, > {line,228}]}, > {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,585}]}, > {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]} > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ivan@REDACTED Wed Feb 5 16:09:37 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Wed, 5 Feb 2014 15:09:37 +0000 Subject: [erlang-questions] Any advice to a Java webhost company about Erlang hosting? In-Reply-To: <52F24AA5.6030804@ninenines.eu> References: <52F2210A.4090905@ninenines.eu> <52F24AA5.6030804@ninenines.eu> Message-ID: <14D406AC-CD25-4061-B55C-32CF2EDA1FD2@llaisdy.com> Come to think of it I think the RELEASE people (and @erlangsolutions) are working on some kind of erlang-centric cloud orchestration webapp thing. They presented about it last December at a workshop in London just after #codemesh. https://www.erlang-solutions.com/about/news/erlang-solutions-hosts-release-project-workshop-6-december Ivan -- festina lente > On 5 Feb 2014, at 14:28, Lo?c Hoguin wrote: > > On 02/05/2014 02:28 PM, Michael Turner wrote: >>> Pardon my ignorance but what does a Java hosting company do exactly compared to just getting a server? >> >> I love it when people say "just" about things like this. I'd like to >> get them slightly drunk and make them a bet: for every minute /under/ >> the amount they estimate that setup will take, I'll pay them $5. For >> every minute /over/ their estimate, /I/ get $5. I'd probably be able >> to retire early just by going to hacker meetups and offering to buy a >> round for everybody at a bar nearby. > > Perhaps instead of trying to be a smartass you could actually have answered the question so people get a better idea what a Java hosting company actually does? Not everyone has Java production experience here. > > I only know Erlang myself. With Erlang, the only dependency you need on top of the base system is openssl. Then you can use releases just fine. Of course, openssl is already installed when you rent a server because it's an openssh dependency. So you pretty much have nothing to install. > > So the only setup you actually need to do is customize the environment like you want to, which you have to do regardless of the hosting solution. For example changing a few sysctl values, opening ports or creating a couple users. Things a script does just fine, if you need to automate it. > > Past initial setup, you do have to upgrade the server yourself, but this only takes me at most a few minutes per upgrade with Arch Linux, because this is a rolling release and I already did the same operation for my laptop so I already know if there's something other than pacman -Syu that needs to be done. And since this is just a base system + openssl, the updates are actually very few. > > If I have ten servers, then I just use cssh or similar and do the ten servers in one go so the time it takes to handle more servers is barely more than the time it takes to handle one. > > Hence my question. What do Java hosting companies do and what benefits do you have going with a company compared to doing it yourself? > > I do not think there is any benefit to going with an Erlang hosting company unless it provides some sort of elastic cloud along with advanced tools to quickly manage or inspect the running nodes. For example a way to remove a node from receiving external requests temporarily to inspect its state and debug an issue without having to fight for resources or risk inconveniencing users. But that's only needed by medium to big systems, plenty of smaller applications couldn't care less about it. > > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vladdu55@REDACTED Wed Feb 5 16:10:06 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 5 Feb 2014 16:10:06 +0100 Subject: [erlang-questions] r17 debugger doesn't support maps yet In-Reply-To: <8D5202FA-4888-4D7C-9416-CDF4CB5EF2BE@gmail.com> References: <8D5202FA-4888-4D7C-9416-CDF4CB5EF2BE@gmail.com> Message-ID: Ah, great, I missed it when checking the list! /Vlad On Wed, Feb 5, 2014 at 4:08 PM, Anthony Ramine wrote: > https://github.com/erlang/otp/pull/213 > > -- > Anthony Ramine > > Le 5 f?vr. 2014 ? 15:08, Vlad Dumitrescu a ?crit : > >> Hi, >> >> I hope this is already known, but the debugger crashes when interpreting modules with maps. >> >> best regards, >> Vlad >> >> {{badmatch, >> {dbg_iload, >> {unknown_expr, >> {map,18, >> [{map_field_assoc,18,{integer,18,2},{integer,18,3}}, >> {map_field_assoc,18,{integer,18,4},{integer,18,5}}]}}}}, >> [{dbg_iserver,handle_call,3, >> [{file, >> "c:/Apps/erlide/org.erlide.kernel.debugger/src/dbg_iserver.erl"}, >> {line,228}]}, >> {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,585}]}, >> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]} >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > From erlangsiri@REDACTED Wed Feb 5 16:15:56 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Wed, 5 Feb 2014 16:15:56 +0100 Subject: [erlang-questions] Meaning of the 'local' option atom in systools:make_script/2 In-Reply-To: <52F0B2B9.5040605@llaisdy.com> References: <52F0B2B9.5040605@llaisdy.com> Message-ID: Hi Ivan! First, be aware that systools:make_script/[1,2] does not fetch any erlang applications or create any kind of a release package, it only creates .script and .boot from the given .rel file. .script is a text file and .boot is a binary version of the same. The .boot file is used when starting an erlang node to give the initial information about which applications to start and where to find them. >From the same .rel file, I have run make_script, once with 'local' and once without it. Running diff on the two generated .script files does only give results like this: 14c12 < {path,["/ldisk/siri/git/otp/lib/kernel/ebin"]}, --- > {path,["$ROOT/lib/kernel-3.0/ebin"]}, So, what does it mean? It means that if I use 'local', then I can start my erlang node with the created .boot and it will pick all applications from the exact same place as the erlang node from which I executed systools:make_script. This is mostly intended for testing! A .boot file created without 'local' is intended to use in a "real" release, which could e.g. be created with systools:make_tar etc. The point beeing that you can create your .script/.boot at build time, without the knowledge about the installation destination. It is assumed that the installation is structured in a standard OTP way with all applications under a $ROOT/lib (this can, however, be omitted by using the 'variables' option to make_script - see documentation). When starting the erlang node with this .boot file, $ROOT will be replaced with the real root dir of the installation. Regards /siri 2014-02-04 Ivan Uemlianin : > Dear All > > What is the meaning of the 'local' option atom in systools:make_script/2? > > My understanding of the erlang documentation [1] is that, if 'local' is > given, make_script will find paths to the application directories on the > current file system, and it will use those paths in the release script. > Nothing is copied into the release directory structure. A release built > with 'local' will only be portable to another system if that system has > exactly the same applications at exactly the same paths. If I would like > the release to be portable, I should omit 'local' and make sure all > required applications are in a lib/ directory in the release directory > structure. > > This seems to be more-or-less what "Erlang and OTP in Action" says [2], > but "Learn You Some Erlang" seems to say the exact opposite [3]. > > So my questions are: > > 1. Do I understand the documentation correctly? > > 2. If I omit 'local' will make_scripts/2 fetch the required erlang > applications and put them in lib/, or must I do that myself? > > With thanks and best wishes > > Ivan > > > ** [1] erlang documentation > > http://www.erlang.org/doc/man/systools.html#make_script-2 > > In the generated boot script all application directories are > structured as App-Vsn/ebin and assumed to be located in $ROOT/lib, > where $ROOT is the root directory of the installed release. If the > local option is supplied, the actual directories where the > applications were found are used instead. This is a useful way to > test a generated boot script locally. > > > ** [2] Erlang and OTP in Action (2011) > > Ch 10. Packaging, services and deployment, p. 250 > > 1> systools:make_script("simple_cache", [local]). > ok > > The local option ... stipulates that absolute paths to all > applications are written in the script and boot files --- meaning > that if you try to start a system using this boot file, all > application code must reside in exactly the same place it did when > the boot file was created. The local option is good for testing, > but it isn't very portable and may not be suitable for production. > > Without the local option, the generated script and boot files > expect that all applications are located in a directory called lib, > pointed out by a system variable $ROOT. This is suitable for a > release that you want to be able to install on different host > machines that don't necessarily have the same paths. > > > ** [3] Learn You Some Erlang (2013) > > Ch 21. Release is the Word, p. 340 > > 1> systools:make_script("erlcount-1.0", [local]). > ok > > Here, the local option means that we want the release to be > possible to run from anywhere, and not just the current install. > > > > -- > ============================================================ > Ivan A. Uemlianin PhD > Llaisdy > Speech Technology Research and Development > > ivan@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > github.com/llaisdy > www.linkedin.com/in/ivanuemlianin > > festina lente > ============================================================ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Wed Feb 5 16:29:53 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Wed, 5 Feb 2014 15:29:53 +0000 Subject: [erlang-questions] Meaning of the 'local' option atom in systools:make_script/2 In-Reply-To: References: <52F0B2B9.5040605@llaisdy.com> Message-ID: Dear Siri Thanks! So it looks like answer #1 is yes; answer #2 is I should fetch the required apps and put them in lib *before* running make_script. Best wishes Ivan -- festina lente > On 5 Feb 2014, at 15:15, Siri Hansen wrote: > > Hi Ivan! > > First, be aware that systools:make_script/[1,2] does not fetch any erlang applications or create any kind of a release package, it only creates .script and .boot from the given .rel file. .script is a text file and .boot is a binary version of the same. The .boot file is used when starting an erlang node to give the initial information about which applications to start and where to find them. > > From the same .rel file, I have run make_script, once with 'local' and once without it. Running diff on the two generated .script files does only give results like this: > > 14c12 > < {path,["/ldisk/siri/git/otp/lib/kernel/ebin"]}, > --- > > {path,["$ROOT/lib/kernel-3.0/ebin"]}, > > So, what does it mean? It means that if I use 'local', then I can start my erlang node with the created .boot and it will pick all applications from the exact same place as the erlang node from which I executed systools:make_script. This is mostly intended for testing! > > A .boot file created without 'local' is intended to use in a "real" release, which could e.g. be created with systools:make_tar etc. The point beeing that you can create your .script/.boot at build time, without the knowledge about the installation destination. It is assumed that the installation is structured in a standard OTP way with all applications under a $ROOT/lib (this can, however, be omitted by using the 'variables' option to make_script - see documentation). When starting the erlang node with this .boot file, $ROOT will be replaced with the real root dir of the installation. > > Regards > /siri > > > > 2014-02-04 Ivan Uemlianin : >> Dear All >> >> What is the meaning of the 'local' option atom in systools:make_script/2? >> >> My understanding of the erlang documentation [1] is that, if 'local' is given, make_script will find paths to the application directories on the current file system, and it will use those paths in the release script. Nothing is copied into the release directory structure. A release built with 'local' will only be portable to another system if that system has exactly the same applications at exactly the same paths. If I would like the release to be portable, I should omit 'local' and make sure all required applications are in a lib/ directory in the release directory structure. >> >> This seems to be more-or-less what "Erlang and OTP in Action" says [2], but "Learn You Some Erlang" seems to say the exact opposite [3]. >> >> So my questions are: >> >> 1. Do I understand the documentation correctly? >> >> 2. If I omit 'local' will make_scripts/2 fetch the required erlang applications and put them in lib/, or must I do that myself? >> >> With thanks and best wishes >> >> Ivan >> >> >> ** [1] erlang documentation >> >> http://www.erlang.org/doc/man/systools.html#make_script-2 >> >> In the generated boot script all application directories are >> structured as App-Vsn/ebin and assumed to be located in $ROOT/lib, >> where $ROOT is the root directory of the installed release. If the >> local option is supplied, the actual directories where the >> applications were found are used instead. This is a useful way to >> test a generated boot script locally. >> >> >> ** [2] Erlang and OTP in Action (2011) >> >> Ch 10. Packaging, services and deployment, p. 250 >> >> 1> systools:make_script("simple_cache", [local]). >> ok >> >> The local option ... stipulates that absolute paths to all >> applications are written in the script and boot files --- meaning >> that if you try to start a system using this boot file, all >> application code must reside in exactly the same place it did when >> the boot file was created. The local option is good for testing, >> but it isn't very portable and may not be suitable for production. >> >> Without the local option, the generated script and boot files >> expect that all applications are located in a directory called lib, >> pointed out by a system variable $ROOT. This is suitable for a >> release that you want to be able to install on different host >> machines that don't necessarily have the same paths. >> >> >> ** [3] Learn You Some Erlang (2013) >> >> Ch 21. Release is the Word, p. 340 >> >> 1> systools:make_script("erlcount-1.0", [local]). >> ok >> >> Here, the local option means that we want the release to be >> possible to run from anywhere, and not just the current install. >> >> >> >> -- >> ============================================================ >> Ivan A. Uemlianin PhD >> Llaisdy >> Speech Technology Research and Development >> >> ivan@REDACTED >> www.llaisdy.com >> llaisdy.wordpress.com >> github.com/llaisdy >> www.linkedin.com/in/ivanuemlianin >> >> festina lente >> ============================================================ >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Wed Feb 5 16:36:28 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Wed, 5 Feb 2014 16:36:28 +0100 Subject: [erlang-questions] Meaning of the 'local' option atom in systools:make_script/2 In-Reply-To: References: <52F0B2B9.5040605@llaisdy.com> Message-ID: 1) yes 2) you don't need to fetch required apps *before* run make_script. In order to run make_script you only need the erlang node to have a path to where your applications are located (or use the 'path' option to make_script). You do however need to have your applications under $ROOT/lib/ before you start your erlang node with the generated .boot file. /siri 2014-02-05 Ivan Uemlianin : > Dear Siri > > Thanks! > > So it looks like answer #1 is yes; answer #2 is I should fetch the > required apps and put them in lib *before* running make_script. > > Best wishes > > Ivan > > -- > festina lente > > > On 5 Feb 2014, at 15:15, Siri Hansen wrote: > > Hi Ivan! > > First, be aware that systools:make_script/[1,2] does not fetch any erlang > applications or create any kind of a release package, it only creates > .script and .boot from the given .rel file. > .script is a text file and .boot is a binary version of > the same. The .boot file is used when starting an erlang node to give the > initial information about which applications to start and where to find > them. > > From the same .rel file, I have run make_script, once with 'local' and > once without it. Running diff on the two generated .script files does only > give results like this: > > 14c12 > < {path,["/ldisk/siri/git/otp/lib/kernel/ebin"]}, > --- > > {path,["$ROOT/lib/kernel-3.0/ebin"]}, > > So, what does it mean? It means that if I use 'local', then I can start my > erlang node with the created .boot and it will pick all > applications from the exact same place as the erlang node from which I > executed systools:make_script. This is mostly intended for testing! > > A .boot file created without 'local' is intended to use in a "real" > release, which could e.g. be created with systools:make_tar etc. The point > beeing that you can create your .script/.boot at build time, without the > knowledge about the installation destination. It is assumed that the > installation is structured in a standard OTP way with all applications > under a $ROOT/lib (this can, however, be omitted by using the 'variables' > option to make_script - see documentation). When starting the erlang node > with this .boot file, $ROOT will be replaced with the real root dir of the > installation. > > Regards > /siri > > > > 2014-02-04 Ivan Uemlianin : > >> Dear All >> >> What is the meaning of the 'local' option atom in systools:make_script/2? >> >> My understanding of the erlang documentation [1] is that, if 'local' is >> given, make_script will find paths to the application directories on the >> current file system, and it will use those paths in the release script. >> Nothing is copied into the release directory structure. A release built >> with 'local' will only be portable to another system if that system has >> exactly the same applications at exactly the same paths. If I would like >> the release to be portable, I should omit 'local' and make sure all >> required applications are in a lib/ directory in the release directory >> structure. >> >> This seems to be more-or-less what "Erlang and OTP in Action" says [2], >> but "Learn You Some Erlang" seems to say the exact opposite [3]. >> >> So my questions are: >> >> 1. Do I understand the documentation correctly? >> >> 2. If I omit 'local' will make_scripts/2 fetch the required erlang >> applications and put them in lib/, or must I do that myself? >> >> With thanks and best wishes >> >> Ivan >> >> >> ** [1] erlang documentation >> >> http://www.erlang.org/doc/man/systools.html#make_script-2 >> >> In the generated boot script all application directories are >> structured as App-Vsn/ebin and assumed to be located in $ROOT/lib, >> where $ROOT is the root directory of the installed release. If the >> local option is supplied, the actual directories where the >> applications were found are used instead. This is a useful way to >> test a generated boot script locally. >> >> >> ** [2] Erlang and OTP in Action (2011) >> >> Ch 10. Packaging, services and deployment, p. 250 >> >> 1> systools:make_script("simple_cache", [local]). >> ok >> >> The local option ... stipulates that absolute paths to all >> applications are written in the script and boot files --- meaning >> that if you try to start a system using this boot file, all >> application code must reside in exactly the same place it did when >> the boot file was created. The local option is good for testing, >> but it isn't very portable and may not be suitable for production. >> >> Without the local option, the generated script and boot files >> expect that all applications are located in a directory called lib, >> pointed out by a system variable $ROOT. This is suitable for a >> release that you want to be able to install on different host >> machines that don't necessarily have the same paths. >> >> >> ** [3] Learn You Some Erlang (2013) >> >> Ch 21. Release is the Word, p. 340 >> >> 1> systools:make_script("erlcount-1.0", [local]). >> ok >> >> Here, the local option means that we want the release to be >> possible to run from anywhere, and not just the current install. >> >> >> >> -- >> ============================================================ >> Ivan A. Uemlianin PhD >> Llaisdy >> Speech Technology Research and Development >> >> ivan@REDACTED >> www.llaisdy.com >> llaisdy.wordpress.com >> github.com/llaisdy >> www.linkedin.com/in/ivanuemlianin >> >> festina lente >> ============================================================ >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Wed Feb 5 16:54:17 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 5 Feb 2014 10:54:17 -0500 Subject: [erlang-questions] Any advice to a Java webhost company about Erlang hosting? In-Reply-To: References: <52F2210A.4090905@ninenines.eu> <085117A3-808F-49A3-B865-CD38DE79910B@llaisdy.com> Message-ID: <20140205155416.GA62889@ferdair.local> The buildpack at https://github.com/archaelus/heroku-buildpack-erlang works with every release from R15B to R17B pre. The old one under Heroku's own github account is deprecated and points to the one above. Which OTP release to be used will be picked based on the .preferred_otp_version file in your repository. Regards, Fred. On 02/05, Mark Nijhof wrote: > That build pack seems out of date, I looked at this for a little while back > for a personal little thing but I think it was for r15. Is there an updated > fork, or does it just work? > > -Mark > > > On Wed, Feb 5, 2014 at 2:57 PM, Sean Cribbs wrote: > > > I'm sure Tristan and Geoff will tell you, there is a buildpack that makes > > it pretty easy to deploy Erlang applications on Heroku. It doesn't build > > releases, but it does builds and deploys your project directly from a "git > > push", which is pretty awesome. > > > > https://github.com/archaelus/heroku-buildpack-erlang > > > > > > On Wed, Feb 5, 2014 at 2:55 PM, Dmitry Kolesnikov wrote: > > > >> Hello, > >> > >> The release is extremely great feature, from my perspective. > >> You can product "self" deployable packages with help of bash magic. > >> This makes not needs to have Erlang pre-installend on any of the target > >> machines. > >> > >> - Dmitry > >> > >> On 05 Feb 2014, at 15:49, Ivan Uemlianin wrote: > >> > >> Isn't (part of) the point of erlang releases that you don't need erlang > >> pre-installed? > >> > >> Ivan > >> > >> -- > >> festina lente > >> > >> > >> On 5 Feb 2014, at 12:44, Vance Shipley wrote: > >> > >> > >> On Feb 5, 2014 5:01 PM, "Lo?c Hoguin" wrote: > >> > > >> > Pardon my ignorance but what does a Java hosting company do exactly > >> compared to just getting a server? > >> > >> When I hear "Java hosting" or "Erlang hosting" I think of cloud > >> environments which provide JVM or BEAM virtual machines (emulators) where > >> you aren't bothered by operating systems. You pay for instances of the VMs > >> and transactional bandwidth. This is what Google AppEngine provides for > >> Java, Python and Go. I've developed cloud services using Go on Appengine > >> and it was wonderfully clean and simple. > >> > >> One future for Erlang may be the LING VM from http://erlangonxen.comwhich runs directly on the Xen hypervisor which is wicked cool. I've got > >> big hope for this. > >> > >> But in practice I'm sure that it means Linux VMs with Erlang/OTP > >> preinstalled. > >> > >> _______________________________________________ > >> 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 > >> > >> > > > > > > -- > > Sean Cribbs > > Software Engineer > > Basho Technologies, Inc. > > http://basho.com/ > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > -- > Mark Nijhof > t: @MarkNijhof > s: marknijhof > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From mark.nijhof@REDACTED Wed Feb 5 16:59:13 2014 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Wed, 5 Feb 2014 16:59:13 +0100 Subject: [erlang-questions] Any advice to a Java webhost company about Erlang hosting? In-Reply-To: <20140205155416.GA62889@ferdair.local> References: <52F2210A.4090905@ninenines.eu> <085117A3-808F-49A3-B865-CD38DE79910B@llaisdy.com> <20140205155416.GA62889@ferdair.local> Message-ID: Cool! Thanks Fred! On Wed, Feb 5, 2014 at 4:54 PM, Fred Hebert wrote: > The buildpack at https://github.com/archaelus/heroku-buildpack-erlang > works with every release from R15B to R17B pre. The old one under > Heroku's own github account is deprecated and points to the one above. > > Which OTP release to be used will be picked based on the > .preferred_otp_version file in your repository. > > Regards, > Fred. > > On 02/05, Mark Nijhof wrote: > > That build pack seems out of date, I looked at this for a little while > back > > for a personal little thing but I think it was for r15. Is there an > updated > > fork, or does it just work? > > > > -Mark > > > > > > On Wed, Feb 5, 2014 at 2:57 PM, Sean Cribbs wrote: > > > > > I'm sure Tristan and Geoff will tell you, there is a buildpack that > makes > > > it pretty easy to deploy Erlang applications on Heroku. It doesn't > build > > > releases, but it does builds and deploys your project directly from a > "git > > > push", which is pretty awesome. > > > > > > https://github.com/archaelus/heroku-buildpack-erlang > > > > > > > > > On Wed, Feb 5, 2014 at 2:55 PM, Dmitry Kolesnikov < > dmkolesnikov@REDACTED>wrote: > > > > > >> Hello, > > >> > > >> The release is extremely great feature, from my perspective. > > >> You can product "self" deployable packages with help of bash magic. > > >> This makes not needs to have Erlang pre-installend on any of the > target > > >> machines. > > >> > > >> - Dmitry > > >> > > >> On 05 Feb 2014, at 15:49, Ivan Uemlianin wrote: > > >> > > >> Isn't (part of) the point of erlang releases that you don't need > erlang > > >> pre-installed? > > >> > > >> Ivan > > >> > > >> -- > > >> festina lente > > >> > > >> > > >> On 5 Feb 2014, at 12:44, Vance Shipley wrote: > > >> > > >> > > >> On Feb 5, 2014 5:01 PM, "Lo?c Hoguin" wrote: > > >> > > > >> > Pardon my ignorance but what does a Java hosting company do exactly > > >> compared to just getting a server? > > >> > > >> When I hear "Java hosting" or "Erlang hosting" I think of cloud > > >> environments which provide JVM or BEAM virtual machines (emulators) > where > > >> you aren't bothered by operating systems. You pay for instances of > the VMs > > >> and transactional bandwidth. This is what Google AppEngine provides > for > > >> Java, Python and Go. I've developed cloud services using Go on > Appengine > > >> and it was wonderfully clean and simple. > > >> > > >> One future for Erlang may be the LING VM from > http://erlangonxen.comwhich runs directly on the Xen hypervisor which is > wicked cool. I've got > > >> big hope for this. > > >> > > >> But in practice I'm sure that it means Linux VMs with Erlang/OTP > > >> preinstalled. > > >> > > >> _______________________________________________ > > >> 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 > > >> > > >> > > > > > > > > > -- > > > Sean Cribbs > > > Software Engineer > > > Basho Technologies, Inc. > > > http://basho.com/ > > > > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > > > -- > > Mark Nijhof > > t: @MarkNijhof > > s: marknijhof > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > -- Mark Nijhof t: @MarkNijhof s: marknijhof -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Wed Feb 5 17:42:28 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Wed, 5 Feb 2014 16:42:28 +0000 Subject: [erlang-questions] Meaning of the 'local' option atom in systools:make_script/2 In-Reply-To: References: <52F0B2B9.5040605@llaisdy.com> Message-ID: Thanks. Will try it out. Ivan -- festina lente > On 5 Feb 2014, at 15:36, Siri Hansen wrote: > > 1) yes > > 2) you don't need to fetch required apps *before* run make_script. In order to run make_script you only need the erlang node to have a path to where your applications are located (or use the 'path' option to make_script). You do however need to have your applications under $ROOT/lib/ before you start your erlang node with the generated .boot file. > > /siri > > > 2014-02-05 Ivan Uemlianin : >> Dear Siri >> >> Thanks! >> >> So it looks like answer #1 is yes; answer #2 is I should fetch the required apps and put them in lib *before* running make_script. >> >> Best wishes >> >> Ivan >> >> -- >> festina lente >> >> >>> On 5 Feb 2014, at 15:15, Siri Hansen wrote: >>> >>> Hi Ivan! >>> >>> First, be aware that systools:make_script/[1,2] does not fetch any erlang applications or create any kind of a release package, it only creates .script and .boot from the given .rel file. .script is a text file and .boot is a binary version of the same. The .boot file is used when starting an erlang node to give the initial information about which applications to start and where to find them. >>> >>> From the same .rel file, I have run make_script, once with 'local' and once without it. Running diff on the two generated .script files does only give results like this: >>> >>> 14c12 >>> < {path,["/ldisk/siri/git/otp/lib/kernel/ebin"]}, >>> --- >>> > {path,["$ROOT/lib/kernel-3.0/ebin"]}, >>> >>> So, what does it mean? It means that if I use 'local', then I can start my erlang node with the created .boot and it will pick all applications from the exact same place as the erlang node from which I executed systools:make_script. This is mostly intended for testing! >>> >>> A .boot file created without 'local' is intended to use in a "real" release, which could e.g. be created with systools:make_tar etc. The point beeing that you can create your .script/.boot at build time, without the knowledge about the installation destination. It is assumed that the installation is structured in a standard OTP way with all applications under a $ROOT/lib (this can, however, be omitted by using the 'variables' option to make_script - see documentation). When starting the erlang node with this .boot file, $ROOT will be replaced with the real root dir of the installation. >>> >>> Regards >>> /siri >>> >>> >>> >>> 2014-02-04 Ivan Uemlianin : >>>> Dear All >>>> >>>> What is the meaning of the 'local' option atom in systools:make_script/2? >>>> >>>> My understanding of the erlang documentation [1] is that, if 'local' is given, make_script will find paths to the application directories on the current file system, and it will use those paths in the release script. Nothing is copied into the release directory structure. A release built with 'local' will only be portable to another system if that system has exactly the same applications at exactly the same paths. If I would like the release to be portable, I should omit 'local' and make sure all required applications are in a lib/ directory in the release directory structure. >>>> >>>> This seems to be more-or-less what "Erlang and OTP in Action" says [2], but "Learn You Some Erlang" seems to say the exact opposite [3]. >>>> >>>> So my questions are: >>>> >>>> 1. Do I understand the documentation correctly? >>>> >>>> 2. If I omit 'local' will make_scripts/2 fetch the required erlang applications and put them in lib/, or must I do that myself? >>>> >>>> With thanks and best wishes >>>> >>>> Ivan >>>> >>>> >>>> ** [1] erlang documentation >>>> >>>> http://www.erlang.org/doc/man/systools.html#make_script-2 >>>> >>>> In the generated boot script all application directories are >>>> structured as App-Vsn/ebin and assumed to be located in $ROOT/lib, >>>> where $ROOT is the root directory of the installed release. If the >>>> local option is supplied, the actual directories where the >>>> applications were found are used instead. This is a useful way to >>>> test a generated boot script locally. >>>> >>>> >>>> ** [2] Erlang and OTP in Action (2011) >>>> >>>> Ch 10. Packaging, services and deployment, p. 250 >>>> >>>> 1> systools:make_script("simple_cache", [local]). >>>> ok >>>> >>>> The local option ... stipulates that absolute paths to all >>>> applications are written in the script and boot files --- meaning >>>> that if you try to start a system using this boot file, all >>>> application code must reside in exactly the same place it did when >>>> the boot file was created. The local option is good for testing, >>>> but it isn't very portable and may not be suitable for production. >>>> >>>> Without the local option, the generated script and boot files >>>> expect that all applications are located in a directory called lib, >>>> pointed out by a system variable $ROOT. This is suitable for a >>>> release that you want to be able to install on different host >>>> machines that don't necessarily have the same paths. >>>> >>>> >>>> ** [3] Learn You Some Erlang (2013) >>>> >>>> Ch 21. Release is the Word, p. 340 >>>> >>>> 1> systools:make_script("erlcount-1.0", [local]). >>>> ok >>>> >>>> Here, the local option means that we want the release to be >>>> possible to run from anywhere, and not just the current install. >>>> >>>> >>>> >>>> -- >>>> ============================================================ >>>> Ivan A. Uemlianin PhD >>>> Llaisdy >>>> Speech Technology Research and Development >>>> >>>> ivan@REDACTED >>>> www.llaisdy.com >>>> llaisdy.wordpress.com >>>> github.com/llaisdy >>>> www.linkedin.com/in/ivanuemlianin >>>> >>>> festina lente >>>> ============================================================ >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric@REDACTED Wed Feb 5 18:05:53 2014 From: eric@REDACTED (Eric Moritz) Date: Wed, 5 Feb 2014 12:05:53 -0500 Subject: [erlang-questions] Any advice to a Java webhost company about Erlang hosting? In-Reply-To: <4C897AAA-CFFE-47F1-952D-AE102F215EB0@gmail.com> References: <52F2210A.4090905@ninenines.eu> <085117A3-808F-49A3-B865-CD38DE79910B@llaisdy.com> <4C897AAA-CFFE-47F1-952D-AE102F215EB0@gmail.com> Message-ID: I'm a non-Heroku employee and I vouch for the ease of deploying Erlang on Heroku. The current build pack is here: https://github.com/archaelus/heroku-buildpack-erlang it is up to R16B03. You're also free to set a custom buildpack via the `heroku` CLI which can be a fork of your project. The build pack is just a collection of bash scripts that are run inside an LXC container so you can customize it to your hearts content. For instance Tristan added a "make dialyzer" command to his build pack to crash the build if dialyzer fails: https://github.com/tsloughter/heroku-buildpack-erlang-dialyzer/blob/master/bin/compile The caveat with Heroku is nodes can't communicate with each other so distributed Erlang isn't available. On Wed, Feb 5, 2014 at 9:10 AM, Dmitry Kolesnikov wrote: > Yes, I was following the Heroku progress. It looks awesome to me. > But we are still stack with old, good AWS EC2... > > - Dmitry > > On 05 Feb 2014, at 15:57, Sean Cribbs wrote: > > I'm sure Tristan and Geoff will tell you, there is a buildpack that makes > it pretty easy to deploy Erlang applications on Heroku. It doesn't build > releases, but it does builds and deploys your project directly from a "git > push", which is pretty awesome. > > https://github.com/archaelus/heroku-buildpack-erlang > > > On Wed, Feb 5, 2014 at 2:55 PM, Dmitry Kolesnikov wrote: > >> Hello, >> >> The release is extremely great feature, from my perspective. >> You can product "self" deployable packages with help of bash magic. >> This makes not needs to have Erlang pre-installend on any of the target >> machines. >> >> - Dmitry >> >> On 05 Feb 2014, at 15:49, Ivan Uemlianin wrote: >> >> Isn't (part of) the point of erlang releases that you don't need erlang >> pre-installed? >> >> Ivan >> >> -- >> festina lente >> >> >> On 5 Feb 2014, at 12:44, Vance Shipley wrote: >> >> >> On Feb 5, 2014 5:01 PM, "Lo?c Hoguin" wrote: >> > >> > Pardon my ignorance but what does a Java hosting company do exactly >> compared to just getting a server? >> >> When I hear "Java hosting" or "Erlang hosting" I think of cloud >> environments which provide JVM or BEAM virtual machines (emulators) where >> you aren't bothered by operating systems. You pay for instances of the VMs >> and transactional bandwidth. This is what Google AppEngine provides for >> Java, Python and Go. I've developed cloud services using Go on Appengine >> and it was wonderfully clean and simple. >> >> One future for Erlang may be the LING VM from http://erlangonxen.comwhich runs directly on the Xen hypervisor which is wicked cool. I've got >> big hope for this. >> >> But in practice I'm sure that it means Linux VMs with Erlang/OTP >> preinstalled. >> >> _______________________________________________ >> 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 >> >> > > > -- > Sean Cribbs > Software Engineer > Basho Technologies, Inc. > http://basho.com/ > > > > _______________________________________________ > 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 Feb 5 18:20:19 2014 From: g@REDACTED (Garrett Smith) Date: Wed, 5 Feb 2014 11:20:19 -0600 Subject: [erlang-questions] Any advice to a Java webhost company about Erlang hosting? In-Reply-To: References: <52F2210A.4090905@ninenines.eu> <085117A3-808F-49A3-B865-CD38DE79910B@llaisdy.com> <4C897AAA-CFFE-47F1-952D-AE102F215EB0@gmail.com> Message-ID: CloudBees supports running arbitrary stacks of software on our platform. Erlang isn't a big customer ask as we are primary Java focused (though Erlang runs all throughout our backend for managing the system). The Erlang support atm is not that visible - but I'd be very happy to work with you personally to your apps working well. Ping me off life if you're interested. Garrett On Wed, Feb 5, 2014 at 11:05 AM, Eric Moritz wrote: > I'm a non-Heroku employee and I vouch for the ease of deploying Erlang on > Heroku. The current build pack is here: > > https://github.com/archaelus/heroku-buildpack-erlang it is up to R16B03. > > You're also free to set a custom buildpack via the `heroku` CLI which can be > a fork of your project. > > The build pack is just a collection of bash scripts that are run inside an > LXC container so you can customize it to your hearts content. > > For instance Tristan added a "make dialyzer" command to his build pack to > crash the build if dialyzer fails: > https://github.com/tsloughter/heroku-buildpack-erlang-dialyzer/blob/master/bin/compile > > The caveat with Heroku is nodes can't communicate with each other so > distributed Erlang isn't available. > > > On Wed, Feb 5, 2014 at 9:10 AM, Dmitry Kolesnikov > wrote: >> >> Yes, I was following the Heroku progress. It looks awesome to me. >> But we are still stack with old, good AWS EC2... >> >> - Dmitry >> >> On 05 Feb 2014, at 15:57, Sean Cribbs wrote: >> >> I'm sure Tristan and Geoff will tell you, there is a buildpack that makes >> it pretty easy to deploy Erlang applications on Heroku. It doesn't build >> releases, but it does builds and deploys your project directly from a "git >> push", which is pretty awesome. >> >> https://github.com/archaelus/heroku-buildpack-erlang >> >> >> On Wed, Feb 5, 2014 at 2:55 PM, Dmitry Kolesnikov >> wrote: >>> >>> Hello, >>> >>> The release is extremely great feature, from my perspective. >>> You can product "self" deployable packages with help of bash magic. >>> This makes not needs to have Erlang pre-installend on any of the target >>> machines. >>> >>> - Dmitry >>> >>> On 05 Feb 2014, at 15:49, Ivan Uemlianin wrote: >>> >>> Isn't (part of) the point of erlang releases that you don't need erlang >>> pre-installed? >>> >>> Ivan >>> >>> -- >>> festina lente >>> >>> >>> On 5 Feb 2014, at 12:44, Vance Shipley wrote: >>> >>> >>> On Feb 5, 2014 5:01 PM, "Lo?c Hoguin" wrote: >>> > >>> > Pardon my ignorance but what does a Java hosting company do exactly >>> > compared to just getting a server? >>> >>> When I hear "Java hosting" or "Erlang hosting" I think of cloud >>> environments which provide JVM or BEAM virtual machines (emulators) where >>> you aren't bothered by operating systems. You pay for instances of the VMs >>> and transactional bandwidth. This is what Google AppEngine provides for >>> Java, Python and Go. I've developed cloud services using Go on Appengine >>> and it was wonderfully clean and simple. >>> >>> One future for Erlang may be the LING VM from http://erlangonxen.com >>> which runs directly on the Xen hypervisor which is wicked cool. I've got big >>> hope for this. >>> >>> But in practice I'm sure that it means Linux VMs with Erlang/OTP >>> preinstalled. >>> >>> _______________________________________________ >>> 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 >>> >> >> >> >> -- >> 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 > From gumm@REDACTED Wed Feb 5 18:57:03 2014 From: gumm@REDACTED (Jesse Gumm) Date: Wed, 5 Feb 2014 11:57:03 -0600 Subject: [erlang-questions] Any advice to a Java webhost company about Erlang hosting? In-Reply-To: References: <52F2210A.4090905@ninenines.eu> <085117A3-808F-49A3-B865-CD38DE79910B@llaisdy.com> <4C897AAA-CFFE-47F1-952D-AE102F215EB0@gmail.com> Message-ID: > Ping me off life I believe that's called the ping of death. (I'm here all night folks) > > On Wed, Feb 5, 2014 at 11:05 AM, Eric Moritz wrote: > > I'm a non-Heroku employee and I vouch for the ease of deploying Erlang on > > Heroku. The current build pack is here: > > > > https://github.com/archaelus/heroku-buildpack-erlang it is up to R16B03. > > > > You're also free to set a custom buildpack via the `heroku` CLI which can be > > a fork of your project. > > > > The build pack is just a collection of bash scripts that are run inside an > > LXC container so you can customize it to your hearts content. > > > > For instance Tristan added a "make dialyzer" command to his build pack to > > crash the build if dialyzer fails: > > https://github.com/tsloughter/heroku-buildpack-erlang-dialyzer/blob/master/bin/compile > > > > The caveat with Heroku is nodes can't communicate with each other so > > distributed Erlang isn't available. > > > > > > On Wed, Feb 5, 2014 at 9:10 AM, Dmitry Kolesnikov < dmkolesnikov@REDACTED> > > wrote: > >> > >> Yes, I was following the Heroku progress. It looks awesome to me. > >> But we are still stack with old, good AWS EC2... > >> > >> - Dmitry > >> > >> On 05 Feb 2014, at 15:57, Sean Cribbs wrote: > >> > >> I'm sure Tristan and Geoff will tell you, there is a buildpack that makes > >> it pretty easy to deploy Erlang applications on Heroku. It doesn't build > >> releases, but it does builds and deploys your project directly from a "git > >> push", which is pretty awesome. > >> > >> https://github.com/archaelus/heroku-buildpack-erlang > >> > >> > >> On Wed, Feb 5, 2014 at 2:55 PM, Dmitry Kolesnikov < dmkolesnikov@REDACTED> > >> wrote: > >>> > >>> Hello, > >>> > >>> The release is extremely great feature, from my perspective. > >>> You can product "self" deployable packages with help of bash magic. > >>> This makes not needs to have Erlang pre-installend on any of the target > >>> machines. > >>> > >>> - Dmitry > >>> > >>> On 05 Feb 2014, at 15:49, Ivan Uemlianin wrote: > >>> > >>> Isn't (part of) the point of erlang releases that you don't need erlang > >>> pre-installed? > >>> > >>> Ivan > >>> > >>> -- > >>> festina lente > >>> > >>> > >>> On 5 Feb 2014, at 12:44, Vance Shipley wrote: > >>> > >>> > >>> On Feb 5, 2014 5:01 PM, "Lo?c Hoguin" wrote: > >>> > > >>> > Pardon my ignorance but what does a Java hosting company do exactly > >>> > compared to just getting a server? > >>> > >>> When I hear "Java hosting" or "Erlang hosting" I think of cloud > >>> environments which provide JVM or BEAM virtual machines (emulators) where > >>> you aren't bothered by operating systems. You pay for instances of the VMs > >>> and transactional bandwidth. This is what Google AppEngine provides for > >>> Java, Python and Go. I've developed cloud services using Go on Appengine > >>> and it was wonderfully clean and simple. > >>> > >>> One future for Erlang may be the LING VM from http://erlangonxen.com > >>> which runs directly on the Xen hypervisor which is wicked cool. I've got big > >>> hope for this. > >>> > >>> But in practice I'm sure that it means Linux VMs with Erlang/OTP > >>> preinstalled. > >>> > >>> _______________________________________________ > >>> 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 > >>> > >> > >> > >> > >> -- > >> 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 > > > _______________________________________________ > 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 Feb 5 19:14:30 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 5 Feb 2014 19:14:30 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation Message-ID: Hi all, It's been almost a full day since the last controversial issue was discussed here and I feel it's time for a new one (well, it's actually old). The default indentation used by the erlang-mode uses a mix of tabs and spaces. Whatever side one is in the "tabs vs spaces" war, mixing them is the common enemy! Not everybody uses emacs, nor should they be forced to. This means that creating a patch might take less time than adjusting the whitespace afterwards, which feels a horrible waste of time and energy. Of course, we the non-emacs-using hackers of the OTP code might be in a crushing minority, and then the issue will get closed quickly. I feel however that I need to try to change this. I have abstained before from submitting small fixes just because of this (instead I sold the idea to someone else, but that doesn't always work). So my question is: are enough people bothered by this issue? If yes, can we try to agree on a solution? Such changes are best done in connection with a release. best regards, Vlad From g@REDACTED Wed Feb 5 19:16:29 2014 From: g@REDACTED (Garrett Smith) Date: Wed, 5 Feb 2014 12:16:29 -0600 Subject: [erlang-questions] Any advice to a Java webhost company about Erlang hosting? In-Reply-To: References: <52F2210A.4090905@ninenines.eu> <085117A3-808F-49A3-B865-CD38DE79910B@llaisdy.com> <4C897AAA-CFFE-47F1-952D-AE102F215EB0@gmail.com> Message-ID: Hmm - this concept feels like it's opened up a whole new metaphysical concept. Not sure what it means, but it somehow feels eternal, recursive. On Wed, Feb 5, 2014 at 11:57 AM, Jesse Gumm wrote: >> Ping me off life > > I believe that's called the ping of death. > > (I'm here all night folks) > >> >> On Wed, Feb 5, 2014 at 11:05 AM, Eric Moritz >> wrote: >> > I'm a non-Heroku employee and I vouch for the ease of deploying Erlang >> > on >> > Heroku. The current build pack is here: >> > >> > https://github.com/archaelus/heroku-buildpack-erlang it is up to R16B03. >> > >> > You're also free to set a custom buildpack via the `heroku` CLI which >> > can be >> > a fork of your project. >> > >> > The build pack is just a collection of bash scripts that are run inside >> > an >> > LXC container so you can customize it to your hearts content. >> > >> > For instance Tristan added a "make dialyzer" command to his build pack >> > to >> > crash the build if dialyzer fails: >> > >> > https://github.com/tsloughter/heroku-buildpack-erlang-dialyzer/blob/master/bin/compile >> > >> > The caveat with Heroku is nodes can't communicate with each other so >> > distributed Erlang isn't available. >> > >> > >> > On Wed, Feb 5, 2014 at 9:10 AM, Dmitry Kolesnikov >> > >> > wrote: >> >> >> >> Yes, I was following the Heroku progress. It looks awesome to me. >> >> But we are still stack with old, good AWS EC2... >> >> >> >> - Dmitry >> >> >> >> On 05 Feb 2014, at 15:57, Sean Cribbs wrote: >> >> >> >> I'm sure Tristan and Geoff will tell you, there is a buildpack that >> >> makes >> >> it pretty easy to deploy Erlang applications on Heroku. It doesn't >> >> build >> >> releases, but it does builds and deploys your project directly from a >> >> "git >> >> push", which is pretty awesome. >> >> >> >> https://github.com/archaelus/heroku-buildpack-erlang >> >> >> >> >> >> On Wed, Feb 5, 2014 at 2:55 PM, Dmitry Kolesnikov >> >> >> >> wrote: >> >>> >> >>> Hello, >> >>> >> >>> The release is extremely great feature, from my perspective. >> >>> You can product "self" deployable packages with help of bash magic. >> >>> This makes not needs to have Erlang pre-installend on any of the >> >>> target >> >>> machines. >> >>> >> >>> - Dmitry >> >>> >> >>> On 05 Feb 2014, at 15:49, Ivan Uemlianin wrote: >> >>> >> >>> Isn't (part of) the point of erlang releases that you don't need >> >>> erlang >> >>> pre-installed? >> >>> >> >>> Ivan >> >>> >> >>> -- >> >>> festina lente >> >>> >> >>> >> >>> On 5 Feb 2014, at 12:44, Vance Shipley wrote: >> >>> >> >>> >> >>> On Feb 5, 2014 5:01 PM, "Lo?c Hoguin" wrote: >> >>> > >> >>> > Pardon my ignorance but what does a Java hosting company do exactly >> >>> > compared to just getting a server? >> >>> >> >>> When I hear "Java hosting" or "Erlang hosting" I think of cloud >> >>> environments which provide JVM or BEAM virtual machines (emulators) >> >>> where >> >>> you aren't bothered by operating systems. You pay for instances of the >> >>> VMs >> >>> and transactional bandwidth. This is what Google AppEngine provides >> >>> for >> >>> Java, Python and Go. I've developed cloud services using Go on >> >>> Appengine >> >>> and it was wonderfully clean and simple. >> >>> >> >>> One future for Erlang may be the LING VM from http://erlangonxen.com >> >>> which runs directly on the Xen hypervisor which is wicked cool. I've >> >>> got big >> >>> hope for this. >> >>> >> >>> But in practice I'm sure that it means Linux VMs with Erlang/OTP >> >>> preinstalled. >> >>> >> >>> _______________________________________________ >> >>> 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 >> >>> >> >> >> >> >> >> >> >> -- >> >> 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 >> > >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions From andrew@REDACTED Wed Feb 5 19:27:27 2014 From: andrew@REDACTED (Andrew Thompson) Date: Wed, 5 Feb 2014 13:27:27 -0500 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: Message-ID: <20140205182727.GL9655@hijacked.us> On Wed, Feb 05, 2014 at 07:14:30PM +0100, Vlad Dumitrescu wrote: > Hi all, > > It's been almost a full day since the last controversial issue was > discussed here and I feel it's time for a new one (well, it's actually > old). > > The default indentation used by the erlang-mode uses a mix of tabs and > spaces. Whatever side one is in the "tabs vs spaces" war, mixing them > is the common enemy! As a vim user, I find the emacs indent mode for erlang incredibly annoying to 'fake' by hand. I'd love to see the tabs die as mixing tabs and spaces makes erlang files a horrible mess when your tabstop is not 8. Andrew From g@REDACTED Wed Feb 5 19:35:48 2014 From: g@REDACTED (Garrett Smith) Date: Wed, 5 Feb 2014 12:35:48 -0600 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <20140205182727.GL9655@hijacked.us> References: <20140205182727.GL9655@hijacked.us> Message-ID: On Wed, Feb 5, 2014 at 12:27 PM, Andrew Thompson wrote: > On Wed, Feb 05, 2014 at 07:14:30PM +0100, Vlad Dumitrescu wrote: >> Hi all, >> >> It's been almost a full day since the last controversial issue was >> discussed here and I feel it's time for a new one (well, it's actually >> old). >> >> The default indentation used by the erlang-mode uses a mix of tabs and >> spaces. Whatever side one is in the "tabs vs spaces" war, mixing them >> is the common enemy! > > As a vim user, I find the emacs indent mode for erlang incredibly > annoying to 'fake' by hand. I'd love to see the tabs die as mixing tabs > and spaces makes erlang files a horrible mess when your tabstop is not > 8. I'm curious what the argument *for* mixed tabs and spaces is. It is to save precious disk space? Garrett P.S. I agree, going two to three days without religious material on the Erlang list is, well, it's just hard to go back now. From essen@REDACTED Wed Feb 5 19:39:29 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 05 Feb 2014 19:39:29 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> Message-ID: <52F28561.4030109@ninenines.eu> On 02/05/2014 07:35 PM, Garrett Smith wrote: > On Wed, Feb 5, 2014 at 12:27 PM, Andrew Thompson wrote: >> On Wed, Feb 05, 2014 at 07:14:30PM +0100, Vlad Dumitrescu wrote: >>> Hi all, >>> >>> It's been almost a full day since the last controversial issue was >>> discussed here and I feel it's time for a new one (well, it's actually >>> old). >>> >>> The default indentation used by the erlang-mode uses a mix of tabs and >>> spaces. Whatever side one is in the "tabs vs spaces" war, mixing them >>> is the common enemy! >> >> As a vim user, I find the emacs indent mode for erlang incredibly >> annoying to 'fake' by hand. I'd love to see the tabs die as mixing tabs >> and spaces makes erlang files a horrible mess when your tabstop is not >> 8. > > I'm curious what the argument *for* mixed tabs and spaces is. It is to > save precious disk space? The argument isn't very interesting, intent is much more so. It all comes from one guy who figured a way to troll everyone alive at the time plus all future generations forever, and succeeded. -- Lo?c Hoguin http://ninenines.eu From ulf@REDACTED Wed Feb 5 19:40:27 2014 From: ulf@REDACTED (Ulf Wiger) Date: Wed, 5 Feb 2014 19:40:27 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: Message-ID: <25B05620-DEDB-47F4-AF46-5C3E573DCA7C@feuerlabs.com> One thing for emacs users (or those who need to deal with them) to do is to insert the following at the top of each erlang module: %% -*- erlang-indent-level: 4; indent-tabs-mode: nil -*- (Perhaps others have suggestions for the ultimate settings here) BR, Ulf W On 5 Feb 2014, at 19:14, Vlad Dumitrescu wrote: > Hi all, > > It's been almost a full day since the last controversial issue was > discussed here and I feel it's time for a new one (well, it's actually > old). > > The default indentation used by the erlang-mode uses a mix of tabs and > spaces. Whatever side one is in the "tabs vs spaces" war, mixing them > is the common enemy! > > Not everybody uses emacs, nor should they be forced to. This means > that creating a patch might take less time than adjusting the > whitespace afterwards, which feels a horrible waste of time and > energy. > > Of course, we the non-emacs-using hackers of the OTP code might be in > a crushing minority, and then the issue will get closed quickly. I > feel however that I need to try to change this. I have abstained > before from submitting small fixes just because of this (instead I > sold the idea to someone else, but that doesn't always work). > > So my question is: are enough people bothered by this issue? If yes, > can we try to agree on a solution? Such changes are best done in > connection with a release. > > best regards, > Vlad > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From g@REDACTED Wed Feb 5 19:41:25 2014 From: g@REDACTED (Garrett Smith) Date: Wed, 5 Feb 2014 12:41:25 -0600 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <52F28561.4030109@ninenines.eu> References: <20140205182727.GL9655@hijacked.us> <52F28561.4030109@ninenines.eu> Message-ID: On Wed, Feb 5, 2014 at 12:39 PM, Lo?c Hoguin wrote: > On 02/05/2014 07:35 PM, Garrett Smith wrote: >> >> On Wed, Feb 5, 2014 at 12:27 PM, Andrew Thompson >> wrote: >>> >>> On Wed, Feb 05, 2014 at 07:14:30PM +0100, Vlad Dumitrescu wrote: >>>> >>>> Hi all, >>>> >>>> It's been almost a full day since the last controversial issue was >>>> discussed here and I feel it's time for a new one (well, it's actually >>>> old). >>>> >>>> The default indentation used by the erlang-mode uses a mix of tabs and >>>> spaces. Whatever side one is in the "tabs vs spaces" war, mixing them >>>> is the common enemy! >>> >>> >>> As a vim user, I find the emacs indent mode for erlang incredibly >>> annoying to 'fake' by hand. I'd love to see the tabs die as mixing tabs >>> and spaces makes erlang files a horrible mess when your tabstop is not >>> 8. >> >> >> I'm curious what the argument *for* mixed tabs and spaces is. It is to >> save precious disk space? > > > The argument isn't very interesting, intent is much more so. It all comes > from one guy who figured a way to troll everyone alive at the time plus all > future generations forever, and succeeded. So this is actually an opportunity, over the course of 6 - 12 hours per day, to check one's arrogance and hubris - to be a more humble and modest person? I can see an advantage here. From vladdu55@REDACTED Wed Feb 5 19:57:37 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 5 Feb 2014 19:57:37 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <25B05620-DEDB-47F4-AF46-5C3E573DCA7C@feuerlabs.com> References: <25B05620-DEDB-47F4-AF46-5C3E573DCA7C@feuerlabs.com> Message-ID: On Wed, Feb 5, 2014 at 7:40 PM, Ulf Wiger wrote: > > One thing for emacs users (or those who need to deal with them) to do is to insert the following at the top of each erlang module: > > %% -*- erlang-indent-level: 4; indent-tabs-mode: nil -*- > > (Perhaps others have suggestions for the ultimate settings here) That (or whatever we agree on) would help a lot. The heavy question is - is it reasonable to change accordingly all OTP source files? Maybe just before setting the final 17.0.0 tag (or some other convenient moment)? By the way, there is another golden rule that the OTP sources are challenging: trailing spaces on lines... Here I think that the problem are the emacs templates, as almost all cases I've seen are in comments. regards, Vlad From egil@REDACTED Wed Feb 5 20:00:27 2014 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Wed, 5 Feb 2014 20:00:27 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> Message-ID: <52F28A4B.5070709@erlang.org> This is a war worth winning but it feels like every battle has been a loss so far .. As a member of the OTP-team and the *only* vim user, I can say that the rest of OTP has utter disinterest to change the current format. (or so it seems anyway =) I guess Emacs does not allow indentation to be anything other than horrible. Every time I've brought it up there is whining about some precious little elisp file that can't handle the change. I've gotten harassed on the number of '%' comment characters I'm supposed to use for different context .. otherwise Emacs just explodes .. or something. Ok, so perhaps I'm being a bit dramatic here =) The truth is that a lot of code in otp is emacs:ified - that is the convention. I think it's bad - but i've managed. Tabs are problematic because code-rendering tools for reviewing code has a lot of issues with it. *We should remove them*, but I'll guess hell will freeze over well before that happens. // Bj?rn-Egil On 2014-02-05 19:35, Garrett Smith wrote: > On Wed, Feb 5, 2014 at 12:27 PM, Andrew Thompson wrote: >> On Wed, Feb 05, 2014 at 07:14:30PM +0100, Vlad Dumitrescu wrote: >>> Hi all, >>> >>> It's been almost a full day since the last controversial issue was >>> discussed here and I feel it's time for a new one (well, it's actually >>> old). >>> >>> The default indentation used by the erlang-mode uses a mix of tabs and >>> spaces. Whatever side one is in the "tabs vs spaces" war, mixing them >>> is the common enemy! >> As a vim user, I find the emacs indent mode for erlang incredibly >> annoying to 'fake' by hand. I'd love to see the tabs die as mixing tabs >> and spaces makes erlang files a horrible mess when your tabstop is not >> 8. > I'm curious what the argument *for* mixed tabs and spaces is. It is to > save precious disk space? > > Garrett > > P.S. I agree, going two to three days without religious material on > the Erlang list is, well, it's just hard to go back now. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From g@REDACTED Wed Feb 5 20:03:32 2014 From: g@REDACTED (Garrett Smith) Date: Wed, 5 Feb 2014 13:03:32 -0600 Subject: [erlang-questions] Chicago Erlang meetup tonight Message-ID: In case anyone's in Chicago tonight and isn't afraid of a little snow, this will be an epic meeting of gigantically epic proportion! http://www.meetup.com/ErlangChicago/events/162319042/ And if you're not in the area, there's still time to catch that plane! Garrett From raould@REDACTED Wed Feb 5 20:04:18 2014 From: raould@REDACTED (Raoul Duke) Date: Wed, 5 Feb 2014 11:04:18 -0800 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <52F28A4B.5070709@erlang.org> References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> Message-ID: > I guess Emacs does not allow indentation to be anything other than horrible. > Every time I've brought it up there is whining about some precious little > elisp file that can't handle the change. > I've gotten harassed on the number of '%' comment characters I'm supposed to > use for different context .. otherwise Emacs just explodes .. or something. > Ok, so perhaps I'm being a bit dramatic here =) personally i found this funny and poignant and great. i am an emacs user, but i am not am emacs bigot. i'm a usability bigot. so i love it when things like this come up and people point out what is stupid wrong about the emacs-emperor-with-no-clothes. From moxford@REDACTED Wed Feb 5 20:08:47 2014 From: moxford@REDACTED (Mike Oxford) Date: Wed, 5 Feb 2014 11:08:47 -0800 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> Message-ID: Convert it all to tabs; there's no sane reason for mixing them. For emacs users: %% -*- erlang-indent-level: 4; indent-tabs-mode: nil -*- For vi users: modify $HOME/.vimrc to set the width you want /thread And toilet-paper is to be placed on the spool with the loose end out over the top and near the user so it does not lay flat against the wall. On Wed, Feb 5, 2014 at 11:04 AM, Raoul Duke wrote: > > I guess Emacs does not allow indentation to be anything other than > horrible. > > Every time I've brought it up there is whining about some precious little > > elisp file that can't handle the change. > > I've gotten harassed on the number of '%' comment characters I'm > supposed to > > use for different context .. otherwise Emacs just explodes .. or > something. > > Ok, so perhaps I'm being a bit dramatic here =) > > personally i found this funny and poignant and great. i am an emacs > user, but i am not am emacs bigot. i'm a usability bigot. so i love it > when things like this come up and people point out what is stupid > wrong about the emacs-emperor-with-no-clothes. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.sabil@REDACTED Wed Feb 5 20:08:38 2014 From: ali.sabil@REDACTED (Ali Sabil) Date: Wed, 5 Feb 2014 20:08:38 +0100 Subject: [erlang-questions] Missing counterpart to maps:without/2 Message-ID: Hi everyone, I was looking at the maps module in R17 and noticed that a counterpart to maps:without/2 was missing, and the same would be true for maps:filter/2. Any reasons for not including these functions? Thanks, Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus@REDACTED Wed Feb 5 20:13:01 2014 From: magnus@REDACTED (Magnus Henoch) Date: Wed, 05 Feb 2014 19:13:01 +0000 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <25B05620-DEDB-47F4-AF46-5C3E573DCA7C@feuerlabs.com> (Ulf Wiger's message of "Wed, 5 Feb 2014 19:40:27 +0100") References: <25B05620-DEDB-47F4-AF46-5C3E573DCA7C@feuerlabs.com> Message-ID: Ulf Wiger writes: > One thing for emacs users (or those who need to deal with them) to do is to insert the following at the top of each erlang module: > > %% -*- erlang-indent-level: 4; indent-tabs-mode: nil -*- > > (Perhaps others have suggestions for the ultimate settings here) As of Emacs 23, you can specify settings for an entire directory tree by creating a .dir-locals.el file in the top directory. It needs to be in Lisp format, so pay attention to dots and parentheses: ((erlang-mode (erlang-indent-level . 4) (show-trailing-whitespace . t) ;; http://www.emacswiki.org/emacs/TabsSpacesBoth (indent-tabs-mode . nil))) Regards, Magnus From g@REDACTED Wed Feb 5 20:18:09 2014 From: g@REDACTED (Garrett Smith) Date: Wed, 5 Feb 2014 13:18:09 -0600 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <52F28A4B.5070709@erlang.org> References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> Message-ID: It seems to me that this problem is easily solved by inverting the interests: - Fix erlang-mode to default to all spaces - OTP team includes the appropriate Emacs code headers in the source files (or the dot file in the source root directory as Magnus just pointed out) and leave them horribly formatted, per their preference Does this not trivially solve the world's Erlang indent problems? Garrett On Wed, Feb 5, 2014 at 1:00 PM, Bj?rn-Egil Dahlberg wrote: > This is a war worth winning but it feels like every battle has been a loss > so far .. > > As a member of the OTP-team and the *only* vim user, I can say that the rest > of OTP has utter disinterest to change the current format. (or so it seems > anyway =) > > I guess Emacs does not allow indentation to be anything other than horrible. > > Every time I've brought it up there is whining about some precious little > elisp file that can't handle the change. > > I've gotten harassed on the number of '%' comment characters I'm supposed to > use for different context .. otherwise Emacs just explodes .. or something. > > Ok, so perhaps I'm being a bit dramatic here =) > > The truth is that a lot of code in otp is emacs:ified - that is the > convention. I think it's bad - but i've managed. > > Tabs are problematic because code-rendering tools for reviewing code has a > lot of issues with it. *We should remove them*, but I'll guess hell will > freeze over well before that happens. > > // Bj?rn-Egil > > > On 2014-02-05 19:35, Garrett Smith wrote: >> >> On Wed, Feb 5, 2014 at 12:27 PM, Andrew Thompson >> wrote: >>> >>> On Wed, Feb 05, 2014 at 07:14:30PM +0100, Vlad Dumitrescu wrote: >>>> >>>> Hi all, >>>> >>>> It's been almost a full day since the last controversial issue was >>>> discussed here and I feel it's time for a new one (well, it's actually >>>> old). >>>> >>>> The default indentation used by the erlang-mode uses a mix of tabs and >>>> spaces. Whatever side one is in the "tabs vs spaces" war, mixing them >>>> is the common enemy! >>> >>> As a vim user, I find the emacs indent mode for erlang incredibly >>> annoying to 'fake' by hand. I'd love to see the tabs die as mixing tabs >>> and spaces makes erlang files a horrible mess when your tabstop is not >>> 8. >> >> I'm curious what the argument *for* mixed tabs and spaces is. It is to >> save precious disk space? >> >> Garrett >> >> P.S. I agree, going two to three days without religious material on >> the Erlang list is, well, it's just hard to go back now. >> _______________________________________________ >> 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 raould@REDACTED Wed Feb 5 20:24:20 2014 From: raould@REDACTED (Raoul Duke) Date: Wed, 5 Feb 2014 11:24:20 -0800 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> Message-ID: > - Fix erlang-mode to default to all spaces > > - OTP team includes the appropriate Emacs code headers in the source > files (or the dot file in the source root directory as Magnus just > pointed out) and leave them horribly formatted, per their preference > > Does this not trivially solve the world's Erlang indent problems? i think the general problem is that whatever will be enforced is enforced by the writer, not by the consumer. formatting should ideally always be subjective and subjectively controlled. so i can see things *how i want* (dammit) and *so can you* (even if you swing a different way when it comes to formatting). the problem is that tools don't take this perspective, so simple things like diff end up spitting out horrible answers under such conditions. so everybody assumes that we *must* have it be pushed / agreed upon. all wrong wrong wrong personally i believe. the tools have to change. the computers have to serve the people, not the other way around. so any language should have a fundamental markup version of itself, say some xml schema, and everything is done under the covers in that format. then when presented to the user it is converted to their subjective preferred rendering style. From vladdu55@REDACTED Wed Feb 5 20:24:28 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 5 Feb 2014 20:24:28 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> Message-ID: On Wed, Feb 5, 2014 at 8:18 PM, Garrett Smith wrote: > It seems to me that this problem is easily solved by inverting the interests: > > - Fix erlang-mode to default to all spaces > > - OTP team includes the appropriate Emacs code headers in the source > files (or the dot file in the source root directory as Magnus just > pointed out) and leave them horribly formatted, per their preference > > Does this not trivially solve the world's Erlang indent problems? Unfortunately, no. If I make a patch without emacs, my editor will still use something else than a mix of tabs and spaces, so it will have to be OTP-ified by hand (copying indentation from other lines) or by running it through emacs just for that. Which, in a funny turn of events, brings me to a question related to the previous "holy war": can emacs open, reindent and save files in bach mode? That would indeed help! (even if one would still have to install emacs). /Vlad > > Garrett > > On Wed, Feb 5, 2014 at 1:00 PM, Bj?rn-Egil Dahlberg wrote: >> This is a war worth winning but it feels like every battle has been a loss >> so far .. >> >> As a member of the OTP-team and the *only* vim user, I can say that the rest >> of OTP has utter disinterest to change the current format. (or so it seems >> anyway =) >> >> I guess Emacs does not allow indentation to be anything other than horrible. >> >> Every time I've brought it up there is whining about some precious little >> elisp file that can't handle the change. >> >> I've gotten harassed on the number of '%' comment characters I'm supposed to >> use for different context .. otherwise Emacs just explodes .. or something. >> >> Ok, so perhaps I'm being a bit dramatic here =) >> >> The truth is that a lot of code in otp is emacs:ified - that is the >> convention. I think it's bad - but i've managed. >> >> Tabs are problematic because code-rendering tools for reviewing code has a >> lot of issues with it. *We should remove them*, but I'll guess hell will >> freeze over well before that happens. >> >> // Bj?rn-Egil >> >> >> On 2014-02-05 19:35, Garrett Smith wrote: >>> >>> On Wed, Feb 5, 2014 at 12:27 PM, Andrew Thompson >>> wrote: >>>> >>>> On Wed, Feb 05, 2014 at 07:14:30PM +0100, Vlad Dumitrescu wrote: >>>>> >>>>> Hi all, >>>>> >>>>> It's been almost a full day since the last controversial issue was >>>>> discussed here and I feel it's time for a new one (well, it's actually >>>>> old). >>>>> >>>>> The default indentation used by the erlang-mode uses a mix of tabs and >>>>> spaces. Whatever side one is in the "tabs vs spaces" war, mixing them >>>>> is the common enemy! >>>> >>>> As a vim user, I find the emacs indent mode for erlang incredibly >>>> annoying to 'fake' by hand. I'd love to see the tabs die as mixing tabs >>>> and spaces makes erlang files a horrible mess when your tabstop is not >>>> 8. >>> >>> I'm curious what the argument *for* mixed tabs and spaces is. It is to >>> save precious disk space? >>> >>> Garrett >>> >>> P.S. I agree, going two to three days without religious material on >>> the Erlang list is, well, it's just hard to go back now. >>> _______________________________________________ >>> 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 g@REDACTED Wed Feb 5 20:27:41 2014 From: g@REDACTED (Garrett Smith) Date: Wed, 5 Feb 2014 13:27:41 -0600 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> Message-ID: On Wed, Feb 5, 2014 at 1:24 PM, Vlad Dumitrescu wrote: > On Wed, Feb 5, 2014 at 8:18 PM, Garrett Smith wrote: >> It seems to me that this problem is easily solved by inverting the interests: >> >> - Fix erlang-mode to default to all spaces >> >> - OTP team includes the appropriate Emacs code headers in the source >> files (or the dot file in the source root directory as Magnus just >> pointed out) and leave them horribly formatted, per their preference >> >> Does this not trivially solve the world's Erlang indent problems? > > Unfortunately, no. If I make a patch without emacs, my editor will > still use something else than a mix of tabs and spaces, so it will > have to be OTP-ified by hand (copying indentation from other lines) or > by running it through emacs just for that. > > Which, in a funny turn of events, brings me to a question related to > the previous "holy war": can emacs open, reindent and save files in > bach mode? That would indeed help! (even if one would still have to > install emacs). This seems like a problem that can be confined to the OTP team and process, which is I think is a pretty small subset of all erlang-mode users, no? And changing erlang-mode to default to spaces doesn't make this worse does it? Garrett From vladdu55@REDACTED Wed Feb 5 20:33:56 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 5 Feb 2014 20:33:56 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> Message-ID: On Wed, Feb 5, 2014 at 8:27 PM, Garrett Smith wrote: > On Wed, Feb 5, 2014 at 1:24 PM, Vlad Dumitrescu wrote: >> On Wed, Feb 5, 2014 at 8:18 PM, Garrett Smith wrote: >>> It seems to me that this problem is easily solved by inverting the interests: >>> - Fix erlang-mode to default to all spaces >>> - OTP team includes the appropriate Emacs code headers in the source >>> files (or the dot file in the source root directory as Magnus just >>> pointed out) and leave them horribly formatted, per their preference >>> >>> Does this not trivially solve the world's Erlang indent problems? >> >> Unfortunately, no. If I make a patch without emacs, my editor will >> still use something else than a mix of tabs and spaces, so it will >> have to be OTP-ified by hand (copying indentation from other lines) or >> by running it through emacs just for that. >> >> Which, in a funny turn of events, brings me to a question related to >> the previous "holy war": can emacs open, reindent and save files in >> bach mode? That would indeed help! (even if one would still have to >> install emacs). > > This seems like a problem that can be confined to the OTP team and > process, which is I think is a pretty small subset of all erlang-mode > users, no? And changing erlang-mode to default to spaces doesn't make > this worse does it? You are right, it's better like you suggested and definitely a step in the right direction. But I think that most Erlang projects are more lenient regarding whitespace mismatches in patches (being much smaller) and thus the project where it hurts the most to be non-compliant is not going to be affected. Yet. /Vlad From mononcqc@REDACTED Wed Feb 5 20:49:07 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 5 Feb 2014 14:49:07 -0500 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <20140205182727.GL9655@hijacked.us> References: <20140205182727.GL9655@hijacked.us> Message-ID: <20140205194906.GB62889@ferdair.local> I tended to solve that problem by opening a file, automatically substituting a tab by 8 spaces (:%s/\t/ /g) and doing the opposite at the end of my editing session (:%s/ /\t/g). Nobody on the OTP team has yelled at me so far, so I kept doing that whenever I played around that code base. -Fred. On 02/05, Andrew Thompson wrote: > On Wed, Feb 05, 2014 at 07:14:30PM +0100, Vlad Dumitrescu wrote: > > Hi all, > > > > It's been almost a full day since the last controversial issue was > > discussed here and I feel it's time for a new one (well, it's actually > > old). > > > > The default indentation used by the erlang-mode uses a mix of tabs and > > spaces. Whatever side one is in the "tabs vs spaces" war, mixing them > > is the common enemy! > > As a vim user, I find the emacs indent mode for erlang incredibly > annoying to 'fake' by hand. I'd love to see the tabs die as mixing tabs > and spaces makes erlang files a horrible mess when your tabstop is not > 8. > > Andrew > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From kraythe@REDACTED Wed Feb 5 21:21:51 2014 From: kraythe@REDACTED (kraythe .) Date: Wed, 5 Feb 2014 14:21:51 -0600 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> Message-ID: Actually the solution to this age old debate was proposed to me by a friend of mine and its genius on a number of levels but isn't implemented anywhere. The reality is that for most languages whitespace is irrelevant so it shouldn't be the code holding the indentation but the user's preference file. Imagine a source code repository where there is NO irrelevant whitespace in the code base. For java, for example, there would be literally only one single line of code. Now when you check out you have a preference file that says you want tabs or spaces or mixed and also defines the other formatting you prefer. When you check out the system reformats the code according to your specs dynamically. When you commit, it strips your code of whitespace before comparing. Now that would rock. Not just for tabs but the other code holy wars like drop braces and so onl *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* *Author of: Hardcore Java (2003) and Maintainable Java (2012)* *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 * On Wed, Feb 5, 2014 at 2:21 PM, kraythe . wrote: > Actually the solution to this age old debate was proposed to me by a > friend of mine and its genius on a number of levels but isn't implemented > anywhere. The reality is that for most languages whitespace is irrelevant > so it shouldn't be the code holding the indentation but the user's > preference file. Imagine a source code repository where there is NO > irrelevant whitespace in the code base. For java, for example, there would > be literally only one single line of code. Now when you check out you have > a preference file that says you want tabs or spaces or mixed and also > defines the other formatting you prefer. When you check out the system > reformats the code according to your specs dynamically. When you commit, it > strips your code of whitespace before comparing. > > Now that would rock. Not just for tabs but the other code holy wars like > drop braces and so onl > > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* > *Author of: Hardcore Java (2003) and Maintainable Java (2012)* > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 > * > > > On Wed, Feb 5, 2014 at 1:33 PM, Vlad Dumitrescu wrote: > >> On Wed, Feb 5, 2014 at 8:27 PM, Garrett Smith wrote: >> > On Wed, Feb 5, 2014 at 1:24 PM, Vlad Dumitrescu >> wrote: >> >> On Wed, Feb 5, 2014 at 8:18 PM, Garrett Smith wrote: >> >>> It seems to me that this problem is easily solved by inverting the >> interests: >> >>> - Fix erlang-mode to default to all spaces >> >>> - OTP team includes the appropriate Emacs code headers in the source >> >>> files (or the dot file in the source root directory as Magnus just >> >>> pointed out) and leave them horribly formatted, per their preference >> >>> >> >>> Does this not trivially solve the world's Erlang indent problems? >> >> >> >> Unfortunately, no. If I make a patch without emacs, my editor will >> >> still use something else than a mix of tabs and spaces, so it will >> >> have to be OTP-ified by hand (copying indentation from other lines) or >> >> by running it through emacs just for that. >> >> >> >> Which, in a funny turn of events, brings me to a question related to >> >> the previous "holy war": can emacs open, reindent and save files in >> >> bach mode? That would indeed help! (even if one would still have to >> >> install emacs). >> > >> > This seems like a problem that can be confined to the OTP team and >> > process, which is I think is a pretty small subset of all erlang-mode >> > users, no? And changing erlang-mode to default to spaces doesn't make >> > this worse does it? >> >> You are right, it's better like you suggested and definitely a step in >> the right direction. But I think that most Erlang projects are more >> lenient regarding whitespace mismatches in patches (being much >> smaller) and thus the project where it hurts the most to be >> non-compliant is not going to be affected. Yet. >> >> /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 Feb 5 21:27:35 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 5 Feb 2014 21:27:35 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> Message-ID: On Wed, Feb 5, 2014 at 9:21 PM, kraythe . wrote: > Actually the solution to this age old debate was proposed to me by a friend > of mine and its genius on a number of levels but isn't implemented anywhere. > The reality is that for most languages whitespace is irrelevant so it > shouldn't be the code holding the indentation but the user's preference > file. Imagine a source code repository where there is NO irrelevant > whitespace in the code base. For java, for example, there would be literally > only one single line of code. Now when you check out you have a preference > file that says you want tabs or spaces or mixed and also defines the other > formatting you prefer. When you check out the system reformats the code > according to your specs dynamically. When you commit, it strips your code of > whitespace before comparing. Absolutely, this would fix it. But we don't have tools that can handle that yet and I fear that implementing those and convincing people to use them would take longer than agreeing on a saner alternative for whitespace. regards, Vlad > Now that would rock. Not just for tabs but the other code holy wars like > drop braces and so onl > > Robert Simmons Jr. MSc. - Lead Java Architect @ EA > Author of: Hardcore Java (2003) and Maintainable Java (2012) > LinkedIn: http://www.linkedin.com/pub/robert-simmons/40/852/a39 > > > On Wed, Feb 5, 2014 at 2:21 PM, kraythe . wrote: >> >> Actually the solution to this age old debate was proposed to me by a >> friend of mine and its genius on a number of levels but isn't implemented >> anywhere. The reality is that for most languages whitespace is irrelevant >> so it shouldn't be the code holding the indentation but the user's >> preference file. Imagine a source code repository where there is NO >> irrelevant whitespace in the code base. For java, for example, there would >> be literally only one single line of code. Now when you check out you have a >> preference file that says you want tabs or spaces or mixed and also defines >> the other formatting you prefer. When you check out the system reformats the >> code according to your specs dynamically. When you commit, it strips your >> code of whitespace before comparing. >> >> Now that would rock. Not just for tabs but the other code holy wars like >> drop braces and so onl >> >> Robert Simmons Jr. MSc. - Lead Java Architect @ EA >> Author of: Hardcore Java (2003) and Maintainable Java (2012) >> LinkedIn: http://www.linkedin.com/pub/robert-simmons/40/852/a39 >> >> >> On Wed, Feb 5, 2014 at 1:33 PM, Vlad Dumitrescu >> wrote: >>> >>> On Wed, Feb 5, 2014 at 8:27 PM, Garrett Smith wrote: >>> > On Wed, Feb 5, 2014 at 1:24 PM, Vlad Dumitrescu >>> > wrote: >>> >> On Wed, Feb 5, 2014 at 8:18 PM, Garrett Smith wrote: >>> >>> It seems to me that this problem is easily solved by inverting the >>> >>> interests: >>> >>> - Fix erlang-mode to default to all spaces >>> >>> - OTP team includes the appropriate Emacs code headers in the source >>> >>> files (or the dot file in the source root directory as Magnus just >>> >>> pointed out) and leave them horribly formatted, per their preference >>> >>> >>> >>> Does this not trivially solve the world's Erlang indent problems? >>> >> >>> >> Unfortunately, no. If I make a patch without emacs, my editor will >>> >> still use something else than a mix of tabs and spaces, so it will >>> >> have to be OTP-ified by hand (copying indentation from other lines) or >>> >> by running it through emacs just for that. >>> >> >>> >> Which, in a funny turn of events, brings me to a question related to >>> >> the previous "holy war": can emacs open, reindent and save files in >>> >> bach mode? That would indeed help! (even if one would still have to >>> >> install emacs). >>> > >>> > This seems like a problem that can be confined to the OTP team and >>> > process, which is I think is a pretty small subset of all erlang-mode >>> > users, no? And changing erlang-mode to default to spaces doesn't make >>> > this worse does it? >>> >>> You are right, it's better like you suggested and definitely a step in >>> the right direction. But I think that most Erlang projects are more >>> lenient regarding whitespace mismatches in patches (being much >>> smaller) and thus the project where it hurts the most to be >>> non-compliant is not going to be affected. Yet. >>> >>> /Vlad >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From g@REDACTED Wed Feb 5 21:28:24 2014 From: g@REDACTED (Garrett Smith) Date: Wed, 5 Feb 2014 14:28:24 -0600 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> Message-ID: On Wed, Feb 5, 2014 at 2:21 PM, kraythe . wrote: > Actually the solution to this age old debate was proposed to me by a friend > of mine and its genius on a number of levels but isn't implemented anywhere. > The reality is that for most languages whitespace is irrelevant so it > shouldn't be the code holding the indentation but the user's preference > file. Imagine a source code repository where there is NO irrelevant > whitespace in the code base. For java, for example, there would be literally > only one single line of code. Now when you check out you have a preference > file that says you want tabs or spaces or mixed and also defines the other > formatting you prefer. When you check out the system reformats the code > according to your specs dynamically. When you commit, it strips your code of > whitespace before comparing. > > Now that would rock. Not just for tabs but the other code holy wars like > drop braces and so onl Heh, not bad. I wonder how something like this might evolve. Garrett From vladdu55@REDACTED Wed Feb 5 21:37:19 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 5 Feb 2014 21:37:19 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> Message-ID: On Wed, Feb 5, 2014 at 9:28 PM, Garrett Smith wrote: > On Wed, Feb 5, 2014 at 2:21 PM, kraythe . wrote: >> Actually the solution to this age old debate was proposed to me by a friend >> of mine and its genius on a number of levels but isn't implemented anywhere. >> The reality is that for most languages whitespace is irrelevant so it >> shouldn't be the code holding the indentation but the user's preference >> file. Imagine a source code repository where there is NO irrelevant >> whitespace in the code base. For java, for example, there would be literally >> only one single line of code. Now when you check out you have a preference >> file that says you want tabs or spaces or mixed and also defines the other >> formatting you prefer. When you check out the system reformats the code >> according to your specs dynamically. When you commit, it strips your code of >> whitespace before comparing. > > Heh, not bad. I wonder how something like this might evolve. Actually, if you have two scripts that add/remove whitespace (for now I'd keep the newlines so that diff gives better results) you could hook them into git's pre-commit and post-checkout hooks. I don't know which other VCS allow this. Of course, this will require everybody to have converters for all languages (one doesn't know what might be in a repository). Maybe git could have special hooks that are actually stored in the repository, so one can get them from there? regards, Vlad From mallen@REDACTED Wed Feb 5 21:46:35 2014 From: mallen@REDACTED (Mark Allen) Date: Wed, 5 Feb 2014 14:46:35 -0600 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> Message-ID: The golang "go fmt" command parses the programmatic AST and returns human readable text formatted to a configurable style sheet. They also have "go fix" which parses the AST and dynamically replaces opcodes/sequences with upgraded opcodes/sequences when moving from version 1.X.X -> 1.X.Y It's kind of cool, but the pre-defined golang style is tabs only for indentation (no spaces) which drives me insane, but at least its consistent. Mark On 2/5/14 2:28 PM, "Garrett Smith" wrote: >On Wed, Feb 5, 2014 at 2:21 PM, kraythe . wrote: >> Actually the solution to this age old debate was proposed to me by a >>friend >> of mine and its genius on a number of levels but isn't implemented >>anywhere. >> The reality is that for most languages whitespace is irrelevant so it >> shouldn't be the code holding the indentation but the user's preference >> file. Imagine a source code repository where there is NO irrelevant >> whitespace in the code base. For java, for example, there would be >>literally >> only one single line of code. Now when you check out you have a >>preference >> file that says you want tabs or spaces or mixed and also defines the >>other >> formatting you prefer. When you check out the system reformats the code >> according to your specs dynamically. When you commit, it strips your >>code of >> whitespace before comparing. >> >> Now that would rock. Not just for tabs but the other code holy wars like >> drop braces and so onl > >Heh, not bad. I wonder how something like this might evolve. > >Garrett >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions From essen@REDACTED Wed Feb 5 21:47:18 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 05 Feb 2014 21:47:18 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> Message-ID: <52F2A356.9040406@ninenines.eu> One line? That's the worst solution ever. You break every tool ever, and even make *cat* and *less* useless (pun intended). Code is text, so keep it readable without requiring any special crappy editor. On 02/05/2014 09:21 PM, kraythe . wrote: > Actually the solution to this age old debate was proposed to me by a > friend of mine and its genius on a number of levels but isn't > implemented anywhere. The reality is that for most languages whitespace > is irrelevant so it shouldn't be the code holding the indentation but > the user's preference file. Imagine a source code repository where there > is NO irrelevant whitespace in the code base. For java, for example, > there would be literally only one single line of code. Now when you > check out you have a preference file that says you want tabs or spaces > or mixed and also defines the other formatting you prefer. When you > check out the system reformats the code according to your specs > dynamically. When you commit, it strips your code of whitespace before > comparing. > > Now that would rock. Not just for tabs but the other code holy wars like > drop braces and so onl > > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* > /Author of: Hardcore Java (2003) and Maintainable Java (2012)/ > /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/ > > > On Wed, Feb 5, 2014 at 2:21 PM, kraythe . > wrote: > > Actually the solution to this age old debate was proposed to me by a > friend of mine and its genius on a number of levels but isn't > implemented anywhere. The reality is that for most languages > whitespace is irrelevant so it shouldn't be the code holding the > indentation but the user's preference file. Imagine a source code > repository where there is NO irrelevant whitespace in the code base. > For java, for example, there would be literally only one single line > of code. Now when you check out you have a preference file that says > you want tabs or spaces or mixed and also defines the other > formatting you prefer. When you check out the system reformats the > code according to your specs dynamically. When you commit, it strips > your code of whitespace before comparing. > > Now that would rock. Not just for tabs but the other code holy wars > like drop braces and so onl > > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* > /Author of: Hardcore Java (2003) and Maintainable Java (2012)/ > /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/ > > > On Wed, Feb 5, 2014 at 1:33 PM, Vlad Dumitrescu > wrote: > > On Wed, Feb 5, 2014 at 8:27 PM, Garrett Smith > wrote: > > On Wed, Feb 5, 2014 at 1:24 PM, Vlad Dumitrescu > > wrote: > >> On Wed, Feb 5, 2014 at 8:18 PM, Garrett Smith > wrote: > >>> It seems to me that this problem is easily solved by > inverting the interests: > >>> - Fix erlang-mode to default to all spaces > >>> - OTP team includes the appropriate Emacs code headers in > the source > >>> files (or the dot file in the source root directory as > Magnus just > >>> pointed out) and leave them horribly formatted, per their > preference > >>> > >>> Does this not trivially solve the world's Erlang indent > problems? > >> > >> Unfortunately, no. If I make a patch without emacs, my > editor will > >> still use something else than a mix of tabs and spaces, so > it will > >> have to be OTP-ified by hand (copying indentation from other > lines) or > >> by running it through emacs just for that. > >> > >> Which, in a funny turn of events, brings me to a question > related to > >> the previous "holy war": can emacs open, reindent and save > files in > >> bach mode? That would indeed help! (even if one would still > have to > >> install emacs). > > > > This seems like a problem that can be confined to the OTP > team and > > process, which is I think is a pretty small subset of all > erlang-mode > > users, no? And changing erlang-mode to default to spaces > doesn't make > > this worse does it? > > You are right, it's better like you suggested and definitely a > step in > the right direction. But I think that most Erlang projects are more > lenient regarding whitespace mismatches in patches (being much > smaller) and thus the project where it hurts the most to be > non-compliant is not going to be affected. Yet. > > /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 > -- Lo?c Hoguin http://ninenines.eu From raould@REDACTED Wed Feb 5 21:48:47 2014 From: raould@REDACTED (Raoul Duke) Date: Wed, 5 Feb 2014 12:48:47 -0800 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <52F2A356.9040406@ninenines.eu> References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> Message-ID: > One line? That's the worst solution ever. You break every tool ever, and > even make *cat* and *less* useless (pun intended). > Code is text, so keep it readable without requiring any special crappy > editor. yes and no. these are the problems and solutions we have to trade off. what is the lesser evil in the long run? probably people disagree. From essen@REDACTED Wed Feb 5 22:18:45 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 05 Feb 2014 22:18:45 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> Message-ID: <52F2AAB5.8000003@ninenines.eu> On 02/05/2014 09:48 PM, Raoul Duke wrote: >> One line? That's the worst solution ever. You break every tool ever, and >> even make *cat* and *less* useless (pun intended). >> Code is text, so keep it readable without requiring any special crappy >> editor. > > yes and no. these are the problems and solutions we have to trade off. > what is the lesser evil in the long run? probably people disagree. ??? There is no evil, this is at most a minor annoyance that comes with pointless debates shrouded by blind religious beliefs. The answer is always "submit code the way the project owner wants you to" and no amount of debating is going to change that, ever. It's not even just tabs vs spaces, plenty other minor things are the author's choice, including number of columns, newline characters, source code encoding, but also major things like mandatory documentation or tests and backward compatibility. There is no one true way of doing things, for this or for anything else. It's just a matter of choice. -- Lo?c Hoguin http://ninenines.eu From wallentin.dahlberg@REDACTED Wed Feb 5 22:22:56 2014 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Wed, 5 Feb 2014 22:22:56 +0100 Subject: [erlang-questions] json handling map functions in erlang 17 In-Reply-To: References: Message-ID: I have not read Joes final book on the matter (several drafts though) .. and I've told him, twice I think, that there will *not* be any maps to json BIFs to in the maps module. It does not belong in the standard library. I do touch on the subject in the EEP ( https://github.com/erlang/eep/blob/master/eeps/eep-0043.md) under "protocol construction". However, it is encouraged that erlang json libraries make use of maps. =) // Bj?rn-Egil 2014-02-05 Zsolt Czinkos : > Hi, > > I've read about some json handling functions in Joe Armstrong's book > (Programming Erlang, 2nd Edition, Page 84): maps:to_json/1, > maps:from_json/1 and maps:safe_from_json/1. > > Now, In erlang shell, I see this. No such functions. > > > maps:module_info(exports). > [{fold,3}, > {map,2}, > {size,1}, > {without,2}, > {module_info,0}, > {module_info,1}, > {values,1}, > {update,3}, > {remove,2}, > {put,3}, > {new,0}, > {merge,2}, > {keys,1}, > {is_key,2}, > {from_list,1}, > {get,2}, > {find,2}, > {to_list,1}] > > Are these json functions planned to be released in final 17.0? > > Thanks, > > Zsolt > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Wed Feb 5 22:23:37 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Wed, 5 Feb 2014 16:23:37 -0500 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> Message-ID: On Wed, Feb 5, 2014 at 2:27 PM, Garrett Smith wrote: > > This seems like a problem that can be confined to the OTP team and > process, which is I think is a pretty small subset of all erlang-mode > users, no? And changing erlang-mode to default to spaces doesn't make > this worse does it? erlang-mode allows the use of spaces for indentation just fine. If the emacs-lisp variable indent-tabs-mode is set to t, you get tabs, or if nil, you get spaces -- this is pretty much universal across all Emacs programming language modes. My ~/.emacs defaults indent-tabs-mode to nil, but I have custom file-open hooks for Erlang and C that search for tabs at the beginnings of lines when I open a source file, and if found, set indent-tabs-mode to t for that buffer only so that any edits there match the existing style for that file. --steve P.S. I'd like the bikeshed to be grey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tristan.sloughter@REDACTED Wed Feb 5 22:26:36 2014 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Wed, 05 Feb 2014 13:26:36 -0800 Subject: [erlang-questions] json handling map functions in erlang 17 In-Reply-To: References: Message-ID: <1391635596.5460.79809801.6D5BA85F@webmail.messagingengine.com> I ported jsx to maps [1]https://github.com/tsloughter/jsx/tree/maps But I haven't rebased against the latest jsx in a while... -- Tristan Sloughter tristan.sloughter@REDACTED On Wed, Feb 5, 2014, at 01:22 PM, Bj?rn-Egil Dahlberg wrote: I have not read Joes final book on the matter (several drafts though) .. and I've told him, twice I think, that there will *not* be any maps to json BIFs to in the maps module. It does not belong in the standard library. I do touch on the subject in the EEP ([2]https://github.com/erlang/eep/blob/master/eeps/eep-0043.md) under "protocol construction". However, it is encouraged that erlang json libraries make use of maps. =) // Bj?rn-Egil 2014-02-05 Zsolt Czinkos <[3]czinkos@REDACTED>: Hi, I've read about some json handling functions in Joe Armstrong's book (Programming Erlang, 2nd Edition, Page 84): maps:to_json/1, maps:from_json/1 and maps:safe_from_json/1. Now, In erlang shell, I see this. No such functions. > maps:module_info(exports). [{fold,3}, {map,2}, {size,1}, {without,2}, {module_info,0}, {module_info,1}, {values,1}, {update,3}, {remove,2}, {put,3}, {new,0}, {merge,2}, {keys,1}, {is_key,2}, {from_list,1}, {get,2}, {find,2}, {to_list,1}] Are these json functions planned to be released in final 17.0? Thanks, Zsolt _______________________________________________ erlang-questions mailing list [4]erlang-questions@REDACTED [5]http://erlang.org/mailman/listinfo/erlang-questions _______________________________________________ erlang-questions mailing list [6]erlang-questions@REDACTED [7]http://erlang.org/mailman/listinfo/erlang-questions References 1. https://github.com/tsloughter/jsx/tree/maps 2. https://github.com/erlang/eep/blob/master/eeps/eep-0043.md 3. mailto:czinkos@REDACTED 4. mailto:erlang-questions@REDACTED 5. http://erlang.org/mailman/listinfo/erlang-questions 6. mailto:erlang-questions@REDACTED 7. http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Wed Feb 5 22:32:05 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 5 Feb 2014 22:32:05 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <52F2AAB5.8000003@ninenines.eu> References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> Message-ID: On Wed, Feb 5, 2014 at 10:18 PM, Lo?c Hoguin wrote: > > There is no evil, this is at most a minor annoyance that comes with > pointless debates shrouded by blind religious beliefs. > > The answer is always "submit code the way the project owner wants you to" > and no amount of debating is going to change that, ever. > > It's not even just tabs vs spaces, plenty other minor things are the > author's choice, including number of columns, newline characters, source > code encoding, but also major things like mandatory documentation or tests > and backward compatibility. All true, except that as a project owner I want to make it as easy as possible for people to contribute. As it is now, people who don't use emacs have to do a more tedious work just to match whitespace... I don't like that kind of useless work and it makes me less motivated to submit patches. If it's deemed that we are a minority not worth considering changing the defaults, then fine. At least it's an explicit choice and we know exactly what is going on. If the debate uncovers some workarounds that make the pain less painful (pun intended), then even better. regards, Vlad From raould@REDACTED Wed Feb 5 22:32:39 2014 From: raould@REDACTED (Raoul Duke) Date: Wed, 5 Feb 2014 13:32:39 -0800 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <52F2AAB5.8000003@ninenines.eu> References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> Message-ID: > The answer is always "submit code the way the project owner wants you to" > and no amount of debating is going to change that, ever. > > It's not even just tabs vs spaces, plenty other minor things are the > author's choice, including number of columns, newline characters, source > code encoding, but also major things like mandatory documentation or tests > and backward compatibility. > > There is no one true way of doing things, for this or for anything else. > It's just a matter of choice. this is an amusing way to use the term "choice". choice would be better if both "sides", the author and the reader, could have things the way they want, rather than any one being a dictator. and it is technically possible, if not politically. probably all computer programming languages (at least, that i care about :-) have an ast form. hell, one could look toward xslt or something for ideas (talk about evil! ;-). From vladdu55@REDACTED Wed Feb 5 22:36:10 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 5 Feb 2014 22:36:10 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> Message-ID: > If the debate uncovers some workarounds that make the pain less > painful (pun intended), then even better. I just found out that we could do something like this to reindent files: emacs -batch sample.erl --eval '(indent-region (point-min) (point-max) nil)' -f save-buffer /Vlad From kraythe@REDACTED Wed Feb 5 22:45:05 2014 From: kraythe@REDACTED (kraythe .) Date: Wed, 5 Feb 2014 15:45:05 -0600 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> Message-ID: I have long favored the enforcement of coding style at the repository level. Then it doesnt matter if someone accidentally reformats their local copy, the checkin will reformat it accordingly. I dont think people will ever agree on the "right" format in something that is inherently a matter of taste. I like tight code with only 2 char indents and as much on the screen at once. Another guy I know loves drop braces with a brace on the next line (for java, C, etc). Neither of us is wrong. If the repo checkin had a reformatter, it wouldn't matter. *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* *Author of: Hardcore Java (2003) and Maintainable Java (2012)* *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 * On Wed, Feb 5, 2014 at 3:36 PM, Vlad Dumitrescu wrote: > > If the debate uncovers some workarounds that make the pain less > > painful (pun intended), then even better. > > I just found out that we could do something like this to reindent files: > > emacs -batch sample.erl --eval '(indent-region (point-min) (point-max) > nil)' -f save-buffer > > /Vlad > _______________________________________________ > 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 Wed Feb 5 22:46:33 2014 From: mjtruog@REDACTED (Michael Truog) Date: Wed, 05 Feb 2014 13:46:33 -0800 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <25B05620-DEDB-47F4-AF46-5C3E573DCA7C@feuerlabs.com> References: <25B05620-DEDB-47F4-AF46-5C3E573DCA7C@feuerlabs.com> Message-ID: <52F2B139.8000802@gmail.com> On 02/05/2014 10:40 AM, Ulf Wiger wrote: > One thing for emacs users (or those who need to deal with them) to do is to insert the following at the top of each erlang module: > > %% -*- erlang-indent-level: 4; indent-tabs-mode: nil -*- > > (Perhaps others have suggestions for the ultimate settings here) The ULTIMATE modeline settings should be: %-*-Mode:erlang;coding:utf-8;tab-width:4;c-basic-offset:4;indent-tabs-mode:()-*- % ex: set ft=erlang fenc=utf-8 sts=4 ts=4 sw=4 et: latin1 would need to be used for the older Erlang source code that requires it (probably all of OTP) which unfortunately makes the emacs modeline more than 80 characters. Having both an emacs and a vi modeline can keep both sets of users happy. It is typical to avoid tabs and prefer spaces, so it would be nice to have that be standard, since the OTP code is becoming unreadable due to characters that don't matter (due to not making a decision, you are still deciding to allow both tabs and spaces). Tab stops were never standard and only really relate to typewriters historically (who uses those for Erlang?). > > > BR, > Ulf W > > On 5 Feb 2014, at 19:14, Vlad Dumitrescu wrote: > >> Hi all, >> >> It's been almost a full day since the last controversial issue was >> discussed here and I feel it's time for a new one (well, it's actually >> old). >> >> The default indentation used by the erlang-mode uses a mix of tabs and >> spaces. Whatever side one is in the "tabs vs spaces" war, mixing them >> is the common enemy! >> >> Not everybody uses emacs, nor should they be forced to. This means >> that creating a patch might take less time than adjusting the >> whitespace afterwards, which feels a horrible waste of time and >> energy. >> >> Of course, we the non-emacs-using hackers of the OTP code might be in >> a crushing minority, and then the issue will get closed quickly. I >> feel however that I need to try to change this. I have abstained >> before from submitting small fixes just because of this (instead I >> sold the idea to someone else, but that doesn't always work). >> >> So my question is: are enough people bothered by this issue? If yes, >> can we try to agree on a solution? Such changes are best done in >> connection with a release. >> >> best regards, >> Vlad >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. > http://feuerlabs.com > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > . > From essen@REDACTED Wed Feb 5 22:46:34 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 05 Feb 2014 22:46:34 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> Message-ID: <52F2B13A.7010807@ninenines.eu> On 02/05/2014 10:32 PM, Vlad Dumitrescu wrote: > If the debate uncovers some workarounds that make the pain less > painful (pun intended), then even better. Have you read the previous threads? Numerous solutions were posted. Here's a quick one for vim users: http://erlang.org/pipermail/erlang-questions/2009-February/041719.html And even better if you want it to also look good and close enough to get your patch accepted: http://stackoverflow.com/questions/4085411/vim-indent-like-emacs (Values may be slightly different for erlang-mode, I don't have this configured yet on this laptop.) You can even use direnv to set an alias only for the erlang/otp folder on your machine that would use a special configuration file that includes those settings, so that you don't have to worry about it at all. (And if you don't like the direnv solution, there's a few others, including ones that only require vim.) -- Lo?c Hoguin http://ninenines.eu From vladdu55@REDACTED Wed Feb 5 22:57:04 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 5 Feb 2014 22:57:04 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <52F2B13A.7010807@ninenines.eu> References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> <52F2B13A.7010807@ninenines.eu> Message-ID: On Wed, Feb 5, 2014 at 10:46 PM, Lo?c Hoguin wrote: > On 02/05/2014 10:32 PM, Vlad Dumitrescu wrote: >> >> If the debate uncovers some workarounds that make the pain less >> painful (pun intended), then even better. > > > Have you read the previous threads? Numerous solutions were posted. Here's a > quick one for vim users: Yep. I don't use vim either. For me it's SublimeText or Eclipse. The batch emacs should work fine, but it's still just a workaround. /Vlad > http://erlang.org/pipermail/erlang-questions/2009-February/041719.html > > And even better if you want it to also look good and close enough to get > your patch accepted: > > http://stackoverflow.com/questions/4085411/vim-indent-like-emacs > > (Values may be slightly different for erlang-mode, I don't have this > configured yet on this laptop.) > > You can even use direnv to set an alias only for the erlang/otp folder on > your machine that would use a special configuration file that includes those > settings, so that you don't have to worry about it at all. (And if you don't > like the direnv solution, there's a few others, including ones that only > require vim.) > > > -- > Lo?c Hoguin > http://ninenines.eu From n.oxyde@REDACTED Wed Feb 5 22:58:28 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 5 Feb 2014 22:58:28 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: Message-ID: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> Hello Vlad, My strategy with regard to indentation is to just expand all tabs on all the lines I edit or add to the code. And I just absolutely don?t care about it not being consistent with the mixed tabs and spaces around it. With a correct tabstop (8 and only 8), it doesn?t matter anyway. Regards, -- Anthony Ramine Le 5 f?vr. 2014 ? 19:14, Vlad Dumitrescu a ?crit : > Hi all, > > It's been almost a full day since the last controversial issue was > discussed here and I feel it's time for a new one (well, it's actually > old). > > The default indentation used by the erlang-mode uses a mix of tabs and > spaces. Whatever side one is in the "tabs vs spaces" war, mixing them > is the common enemy! > > Not everybody uses emacs, nor should they be forced to. This means > that creating a patch might take less time than adjusting the > whitespace afterwards, which feels a horrible waste of time and > energy. > > Of course, we the non-emacs-using hackers of the OTP code might be in > a crushing minority, and then the issue will get closed quickly. I > feel however that I need to try to change this. I have abstained > before from submitting small fixes just because of this (instead I > sold the idea to someone else, but that doesn't always work). > > So my question is: are enough people bothered by this issue? If yes, > can we try to agree on a solution? Such changes are best done in > connection with a release. > > best regards, > Vlad > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From steven.charles.davis@REDACTED Thu Feb 6 02:29:40 2014 From: steven.charles.davis@REDACTED (Steve Davis) Date: Wed, 5 Feb 2014 17:29:40 -0800 (PST) Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: Message-ID: <6711e03a-ceb2-4094-83b5-a412b005e3df@googlegroups.com> Seems this eternal debate always revolves around the user's choice of text file viewers (note: plural). Maybe a better way to resolve this annoying and persistent question is to ask: "what is the correct binary format for a text file?". If there's a clear answer to that, then we could say that any viewer that doesn't deal with that format "prettily" is flouting the spec. 2c. /s On Wednesday, February 5, 2014 12:14:30 PM UTC-6, Vlad Dumitrescu wrote: > > Hi all, > > It's been almost a full day since the last controversial issue was > discussed here and I feel it's time for a new one (well, it's actually > old). > > The default indentation used by the erlang-mode uses a mix of tabs and > spaces. Whatever side one is in the "tabs vs spaces" war, mixing them > is the common enemy! > > Not everybody uses emacs, nor should they be forced to. This means > that creating a patch might take less time than adjusting the > whitespace afterwards, which feels a horrible waste of time and > energy. > > Of course, we the non-emacs-using hackers of the OTP code might be in > a crushing minority, and then the issue will get closed quickly. I > feel however that I need to try to change this. I have abstained > before from submitting small fixes just because of this (instead I > sold the idea to someone else, but that doesn't always work). > > So my question is: are enough people bothered by this issue? If yes, > can we try to agree on a solution? Such changes are best done in > connection with a release. > > best regards, > Vlad > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangprogram@REDACTED Thu Feb 6 03:56:13 2014 From: erlangprogram@REDACTED (Samuel X) Date: Wed, 5 Feb 2014 21:56:13 -0500 Subject: [erlang-questions] erlang diameter dictionary In-Reply-To: References: Message-ID: Hi Anders, I found the reason why the diameter library won't parse the avp with code 1023. Since the message pattern is avp_name(Code, Vid), After I manually modified the generated dictionary erlang source file by setting the Vid then it can match the pattern and parse. However, I don't get why the diameterc utility doesn't fill this Vid field while compiling a dictionary. In the dictionary, I define @vendor 10415 IETF. But why the Vid set as undefined like this in the generated erl file: avp_name(1023, undefined) -> Can you give me some suggestions how to set this properly in a dictionary file to get the proper avp pattern? Or the diameter library document has the steps. Thanks a lot! Samuel On Tue, Feb 4, 2014 at 12:15 PM, Samuel X wrote: > Hi Anders, > > Thanks for your reply, Your suggestions are valuable. I am still playing > with some trial code. So need to worry about name space convention for now. > > I think I did recompile everything with rebar (clean then compile). But I > didn't continue with the rfc4006 dictionary. > > I redefined my CCR/CCA messages and received something back from peer with > success code 2001. However I got decoding error. I debugged the decoding > process. Something makes me confused. > > After splitting all AVPS, other AVPs are parsed ok, except two. One is > like this, simple enum data: > > < Avps = [ {diameter_avp,1023,10415,true,false, > <<0,0,0,0>>, > undefined,undefined,undefined,7}, > > I think I defined the dictionary properly. For instance, the generated > dictionary erlang file has the 1023 definition: > > avp_name(1023, undefined) -> > {'Bearer-Control-Mode', 'Enumerated'}; > > avp_header('Bearer-Control-Mode') -> > {1023, 64, undefined}; > > {avp_types, > [{"Bearer-Control-Mode", 1023, "Enumerated", > "M"}, > > > But when I debug the Mod:decode_avps step by step, I don't see it try to > step into the proper avp_name mapping and throw the error > {5001, > {diameter_avp,1023,10415,true,false, > <<0,0,0,0>>, > undefined,undefined,undefined,7}}, > > I saw it tried to parse with avp_name(443, undefined) -> > {'Subscription-Id', 'Grouped'}; > > > Do I misunderstand anything in diameter library? What I did wrong to cause > this? How should I better understand the encode/decode process in diameter > library? > > Could you please give me some suggestions? > > Thanks a lot! > > Samuel > > > > On Mon, Jan 27, 2014 at 4:52 AM, Anders Svensson wrote: > >> Hi Samuel. >> >> > How are you? >> >> Still kicking, thanks. :) >> >> > I have a question about modifying diameter dictionary. For example, for >> > diameter CCR message, if I want to change "Service-Context-Id" from >> > mandatory to non mandatory property so I don't have to fill this >> property in >> > the CCR message, I changed the file rfc4006_cc.dia as following: >> > >> > 1. Service-Context-Id 461 UTF8String - >> > 2. Change from {Service-Context-id} to [Service-Context-Id] and move it >> > below {CC-Request-Number} in CCR message definition >> >> Easy enough to do but if you send a CCR without Service-Context-Id to >> a node expecting an RFC 4006 CCR then the request is likely to be >> rejected. 1.3.3 of RFC 6733 requires a new Command Code when making >> this specific modification. >> >> > Then I used diameterc to generate new erlang files accordingly. The >> files >> > look good and I was able to compile. By the way, I include the diameter >> > library source code from OTP release R16B03 into the project, just in >> order >> > to debug the diameter easily. >> > >> > I filled the CCR message as below: >> >> Just a couple of pointers before getting to the actual issue ... >> >> > CCR = #diameter_rfc4006_cc_CCR{ >> >> It's not a good idea to use diameter as a prefix here in case diameter >> itself ships with a this dictionary one day. >> >> > 'Session-Id' = diameter:session_id(?L(who)), >> > 'Auth-Application-Id' = 16777238, >> > 'CC-Request-Type' = >> > ?'DIAMETER_RFC4006_CC_CC-REQUEST-TYPE_INITIAL_REQUEST', >> >> These long macro names are truly hideous, at least if you like to be >> able to maintain readable line lengths. (78 characters in my book.) At >> best I'd redefine those I want to use. >> >> Eg. -define(INITIAL, >> ?'DIAMETER_RFC4006_CC_CC-REQUEST-TYPE_INITIAL_REQUEST'). >> >> > 'CC-Request-Number' = 0 >> > }, >> > diameter:call(Name, ?APP_CCR_ALIAS, CCR, []). >> > >> > When I run from the erlang shell R16B03, I got the encoding error like >> this: >> > >> > why: {diameter_codec,encode, >> > {{mandatory_avp_missing,'CC-Request-Type','CCR'}, >> >> I suspect you haven't recompiled your source file after modifying the >> dictionary. Records are just tuples, and fields in the record notation >> are mapped to tuple indices using the record definition known to the >> source in question. If the source creating the record above has the >> "old" definition then the fields set as CC-Request-Type and >> CC-Request-Number will be in the positions in which the "new" >> dictionary module expects to find CC-Request-Number and >> Service-Context-Id, leading to the "missing" CC-Request-Type error. >> >> That is, you need to recompile any source that includes a generated >> hrl, in addition to loading the new dictionary module. >> >> > [{diameter_gen_rfc4006_cc,encode_avps,2, >> > [{file, >> > >> > "/usr/lib/erlang/lib/diameter-1.5/include/diameter_gen.hrl"}, >> > {line,59}]}, >> > {diameter_codec,e,2, >> > [{file,"src/diameter_codec.erl"},{line,120}]}, >> > {diameter_codec,encode,2, >> > [{file,"src/diameter_codec.erl"},{line,71}]}, >> > {diameter_traffic,encode,3, >> > [{file,"src/diameter_traffic.erl"},{line,1481}]}, >> > {diameter_traffic,send_R,6, >> > [{file,"src/diameter_traffic.erl"},{line,1320}]}, >> > {diameter_traffic,'-send_request/4-fun-0-',6, >> > [{file,"src/diameter_traffic.erl"},{line,1094}]}]}} >> > who: <0.62.0> >> > what: {diameter_codec,encode, >> > [diameter_gen_rfc4006_cc, >> > {diameter_packet, >> > {diameter_header,1,undefined,undefined,undefined, >> > >> 398339147,398339147,undefined,undefined,undefined, >> > undefined}, >> > undefined, >> > {diameter_rfc4006_cc_CCR, >> > >> ["who",";","1452024187",";","1",";","nonode@REDACTED"], >> > "centos","example.com","example.com",16777238, >> > undefined,1,0, >> > ["centos"], >> > >> > >> > [],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[], >> > []}, >> > undefined,[],undefined}]} >> > {error,encode} >> > >> > I don't really understand why getting this error or the error >> information is >> > a little bit confusing me. >> > Am I doing right to modify the dictionary file? What is the proper way >> to do >> > that? >> >> Nothing wrong with the modification, aside from the fact that you're >> straying from RFC 4006 Credit-Control as I mentioned above. >> >> > What is best way of debugging the diameter library? Can you give me some >> > hints? >> >> In this case it's just confusion over record definitions I think, and >> these are always confusing until you realize that different code might >> have different record definitions. You can see the record being >> encoded by tracing on diameter_codec:encode/2 for example, which would >> show the unexpected positions of CC-Request-Type and CC-Request-Number >> relative to your dictionary definition. >> >> /Anders, Erlang/OTP >> >> >> >> > >> > Thanks a lot! >> > >> > Samuel >> > >> > >> > On Sat, Mar 23, 2013 at 7:11 AM, Anders Svensson >> > wrote: >> >> >> >> On Fri, Mar 22, 2013 at 7:52 PM, S X wrote: >> >> > Hi Anders, >> >> > >> >> > Sorry, I think I understand now. You told me the solution. Just use >> '[ >> >> > ]'. >> >> > >> >> > Anyhow, many thanks! >> >> > >> >> > By the way, since 3588 is obsolete, can I use 6733 while compile >> other >> >> > dictionaries? >> >> >> >> Yes. /Anders >> >> >> >> >> >> > >> >> > Thanks! >> >> > >> >> > Samuel >> >> > >> >> > >> >> > On Fri, Mar 22, 2013 at 2:46 PM, S X >> wrote: >> >> >> >> >> >> Hi Anders, >> >> >> >> >> >> Thanks for your quick response. But I still don't get why the DH is >> >> >> being >> >> >> interpreted as a list of Destination-Host values ( Is it because the >> >> >> define >> >> >> "avp_arity('CCR', 'Destination-Host') -> {0, 1};"). >> >> >> >> >> >> And if it is treated as a list, how come it has a length greater >> than >> >> >> 1, I >> >> >> just set it once in prepare_request. >> >> >> >> >> >> What should I do to correct it? Or which document should I read more >> >> >> carefully to understand this properly? >> >> >> >> >> >> Thanks a lot! >> >> >> >> >> >> Samuel >> >> >> >> >> >> >> >> >> On Fri, Mar 22, 2013 at 1:27 PM, Anders Svensson < >> anders.otp@REDACTED> >> >> >> wrote: >> >> >>> >> >> >>> Hi Samuel >> >> >>> >> >> >>> On Fri, Mar 22, 2013 at 5:55 PM, S X >> wrote: >> >> >>> > Thanks a lot, Anders, >> >> >>> > >> >> >>> > I think I overlooked what the meaning of the configurable ID tag >> (4) >> >> >>> > in >> >> >>> > the >> >> >>> > dia file is , which is supposed to be the important application >> ID >> >> >>> > to >> >> >>> > be >> >> >>> > used in the configuration. Your suggestion about the prefix is >> also >> >> >>> > right. >> >> >>> > But now I am just learning erlang diameter library. >> >> >>> > >> >> >>> > I just try to follow the sample RAR message style, and am still >> >> >>> > having >> >> >>> > issue >> >> >>> > with sending CCR message. The client configuration now is: >> >> >>> > >> >> >>> > -define(SERVICE(Name), [{'Origin-Host', ?L(Name) ++ ". >> example.com"}, >> >> >>> > {'Origin-Realm', "example.com"}, >> >> >>> > {'Vendor-Id', 193}, >> >> >>> > {'Product-Name', "Client"}, >> >> >>> > {'Auth-Application-Id', >> >> >>> > [?DIAMETER_APP_ID_CCRA]}, >> >> >>> > {application, [{alias, ?APP_CCR_ALIAS}, >> >> >>> > {dictionary, >> >> >>> > ?DIAMETER_DICT_CCRA}, >> >> >>> > {module, >> client_cb_ccra}]}]). >> >> >>> > >> >> >>> > Try to send CCR message: >> >> >>> > >> >> >>> > call(Name) -> >> >> >>> > SId = diameter:session_id(?L(Name)), >> >> >>> > CCR = #diameter_base_rfc4006_cc_CCR{ >> >> >>> > 'Session-Id' = SId, >> >> >>> > 'Service-Context-Id' = "Test", >> >> >>> > 'CC-Request-Type' = >> >> >>> > ?'DIAMETER_BASE_RFC4006_CC_CC-REQUEST-TYPE_INITIAL_REQUEST', >> >> >>> > 'CC-Request-Number' = 0, >> >> >>> > 'Auth-Application-Id' = ?DIAMETER_APP_ID_CCRA, >> >> >>> > 'User-Name' = "Me"}, >> >> >>> > diameter:call(Name, ?APP_CCR_ALIAS, CCR, []). >> >> >>> > >> >> >>> > >> >> >>> > In the client callback module: >> >> >>> > >> >> >>> > prepare_request(#diameter_packet{msg = Rec}, _, {_, Caps}) -> >> >> >>> > #diameter_caps{origin_host = {OH, DH}, >> >> >>> > origin_realm = {OR, DR}} >> >> >>> > = Caps, >> >> >>> > >> >> >>> > {send, Rec#diameter_base_rfc4006_cc_CCR{'Origin-Host' = OH, >> >> >>> > 'Origin-Realm' = OR, >> >> >>> > 'Destination-Host' = DH, >> >> >>> > 'Destination-Realm' = DR}}. >> >> >>> > >> >> >>> > I got the error about AVP property: >> >> >>> > >> >> >>> > =ERROR REPORT==== 22-Mar-2013::00:17:31 === >> >> >>> > why: {diameter_codec,encode, >> >> >>> > {{repeated_avp_excessive_arity,'Destination-Host',1, >> >> >>> > "server.example.com",'CCR'}, >> >> >>> >> >> >>> This is because Destination-Host is optional in CCR and AVP's are >> >> >>> encoded differently in a message record depending on whether or not >> >> >>> there can be exactly one occurrence: if so then the field value >> should >> >> >>> be the AVP value, if not then a list of AVP values. That is, your >> CCR >> >> >>> record should have >> >> >>> >> >> >>> 'Destination-Host' = [DH], >> >> >>> >> >> >>> in this case. >> >> >>> >> >> >>> > [{diameter_gen_base_rfc4006_cc,encode_avps,2, >> >> >>> > >> >> >>> > [{file,"diameter_gen_base_rfc4006_cc.erl"},{line,47}]}, >> >> >>> > >> >> >>> > {diameter_codec,e,2,[{file,"diameter_codec.erl"},{line,112}]}, >> >> >>> > {diameter_codec,encode,2, >> >> >>> > [{file,"diameter_codec.erl"},{line,63}]}, >> >> >>> > {diameter_traffic,encode,3, >> >> >>> > [{file,"diameter_traffic.erl"},{line,1437}]}, >> >> >>> > {diameter_traffic,send_R,6, >> >> >>> > [{file,"diameter_traffic.erl"},{line,1276}]}, >> >> >>> > {diameter_traffic,'-send_request/4-fun-0-',4, >> >> >>> > >> [{file,"diameter_traffic.erl"},{line,1050}]}]}} >> >> >>> > who: <0.180.0> >> >> >>> > what: {diameter_codec,encode, >> >> >>> > [diameter_gen_base_rfc4006_cc, >> >> >>> > {diameter_packet, >> >> >>> > >> {diameter_header,1,undefined,undefined,undefined, >> >> >>> > >> >> >>> > 1330492780,1330492780,undefined,undefined,undefined, >> >> >>> > undefined}, >> >> >>> > undefined, >> >> >>> > {diameter_base_rfc4006_cc_CCR, >> >> >>> > >> >> >>> > ["client",";","1425429748",";","2",";","nonode@REDACTED"], >> >> >>> > >> >> >>> > "client.example.com","example.com","example.com",4, >> >> >>> > >> >> >>> > "Test",1,0,"server.example.com","Me",[],[],[],[],[],[], >> >> >>> > [],[],[],[],[],[],[],[],[],[],[],[]}, >> >> >>> > undefined,[],undefined}]} >> >> >>> > >> >> >>> > My understanding is that the client callback prepare_request sets >> >> >>> > the >> >> >>> > "Destination-Host" (retrievd via the CER/A done at earilier >> stage) >> >> >>> > in >> >> >>> > the >> >> >>> > CCR message. So I should set it right. But seems I still >> >> >>> > misunderstand >> >> >>> > something. Does the error information >> "repeated_avp_excessive_arity" >> >> >>> > mean " >> >> >>> > 0-1 Zero or one instance of the AVP MAY be present in the >> message. >> >> >>> > It >> >> >>> > is >> >> >>> >> >> >>> Yes, exactly. In your case your DH is being interpreted as list of >> >> >>> Destination-Host values, and "excessive arity" is a result of that >> >> >>> list having length greater than 1. >> >> >>> >> >> >>> /Anders, Erlang/OTP >> >> >>> >> >> >>> >> >> >>> > considered an error if there is more than one instance of the >> AVP" >> >> >>> > according >> >> >>> > to rfc4006 spec? The erlang error message is not that >> >> >>> > straightforward, >> >> >>> > really confusing newbies:). >> >> >>> > >> >> >>> > Do you have any hints? (I hope I could provide some ramp up >> steps >> >> >>> > for >> >> >>> > other >> >> >>> > people to learn with erlang diameter library after making it >> >> >>> > work^_^) >> >> >>> > >> >> >>> > Many thanks, >> >> >>> > >> >> >>> > Samuel >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > On Thu, Mar 21, 2013 at 8:59 AM, Anders Svensson >> >> >>> > >> >> >>> > wrote: >> >> >>> >> >> >> >>> >> On Thu, Mar 21, 2013 at 2:55 AM, S X >> >> >>> >> wrote: >> >> >>> >> > Hello, >> >> >>> >> > >> >> >>> >> > Sorry, I still have some problems with sending CCR/CCA >> messages. >> >> >>> >> > I >> >> >>> >> > didn't >> >> >>> >> > quite get how to configure multiple diameter applications >> though >> >> >>> >> > it >> >> >>> >> > seems >> >> >>> >> > clear when I read the diameter protocol. >> >> >>> >> > >> >> >>> >> > Based on the sample diameter code, I made the following >> changes, >> >> >>> >> > diameter_gen_base_rfc4006_cc is the dictionary generated with >> >> >>> >> > rfc4006_cc.dia: >> >> >>> >> > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Client >> >> >>> >> > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ >> >> >>> >> > >> >> >>> >> > -define(SVC_NAME, ?MODULE). >> >> >>> >> > -define(APP_ALIAS, ?MODULE). >> >> >>> >> > -define(CALLBACK_MOD, client_cb). >> >> >>> >> > -define(DIAMETER_DICT_CCRA, diameter_gen_base_rfc4006_cc). >> >> >>> >> > >> >> >>> >> > -define(L, atom_to_list). >> >> >>> >> > >> >> >>> >> > -define(SERVICE(Name), [{'Origin-Host', ?L(Name) ++ >> >> >>> >> > ".example.com"}, >> >> >>> >> > {'Origin-Realm', "example.com"}, >> >> >>> >> > {'Vendor-Id', 0}, >> >> >>> >> > {'Product-Name', "Client"}, >> >> >>> >> > {'Auth-Application-Id', >> >> >>> >> > [?DIAMETER_APP_ID_COMMON]}, >> >> >>> >> > {application, [{alias, ?APP_ALIAS}, >> >> >>> >> > {dictionary, >> >> >>> >> > ?DIAMETER_DICT_CCRA}, >> >> >>> >> > {module, >> >> >>> >> > ?CALLBACK_MOD}]}]). >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Server >> >> >>> >> > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ >> >> >>> >> > >> >> >>> >> > -define(DIAMETER_DICT_CCRA, diameter_gen_base_rfc4006_cc). >> >> >>> >> > >> >> >>> >> > init(State) -> >> >> >>> >> > SvcName = ?MODULE, >> >> >>> >> > SvcOpts = [{'Origin-Host', atom_to_list(SvcName) ++ >> >> >>> >> > ".example.com"}, >> >> >>> >> > {'Origin-Realm', "example.com"}, >> >> >>> >> > {'Vendor-Id', 193}, >> >> >>> >> > {'Product-Name', "Server"}, >> >> >>> >> > {'Auth-Application-Id', >> >> >>> >> > [?DIAMETER_APP_ID_COMMON]}, >> >> >>> >> > {application, [{alias, ?MODULE}, >> >> >>> >> > {dictionary, >> ?DIAMETER_DICT_CCRA}, >> >> >>> >> > {module, server_cb}]}], >> >> >>> >> > TransportOpts = [{transport_module, diameter_tcp}, >> >> >>> >> > {transport_config, [{reuseaddr, true}, >> >> >>> >> > {ip, {127,0,0,1}}, {port, 3868}]}], >> >> >>> >> > diameter:start(), >> >> >>> >> > diameter:start_service(SvcName, SvcOpts), >> >> >>> >> > diameter:add_transport(SvcName, {listen, TransportOpts}), >> >> >>> >> > erlang:display("Set up diameter server completed!"), >> >> >>> >> > {ok, State}. >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > I changed the callbacks client_cb and server_cb to handle >> CCR/CCA >> >> >>> >> > messages. >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > However, I got the following errors "app_not_configured". It >> >> >>> >> > seems >> >> >>> >> > the >> >> >>> >> > configuration for applications is incorrect. How should I >> >> >>> >> > configure >> >> >>> >> > the >> >> >>> >> > service properly? My understanding is I want to reuse CER/CEA >> as >> >> >>> >> > default >> >> >>> >> > authorization application, but the erlang diameter doesn't >> >> >>> >> > explain >> >> >>> >> > how >> >> >>> >> > to do >> >> >>> >> > it. Or my understanding is incorrect at all. >> >> >>> >> >> >> >>> >> The problem is a mismatch between the application and >> capabilities >> >> >>> >> configuration in your SvcOpts: the 'Auth-Application-Id' tuple >> >> >>> >> specifies the Application Id's that are advertised in the >> outgoing >> >> >>> >> CER/CEA (that diameter itself sends) while 'applications' >> specifies >> >> >>> >> corresponding dictionary modules. In your case, advertising the >> >> >>> >> common >> >> >>> >> application (0) during capabilities exchange but backing it up >> with >> >> >>> >> a >> >> >>> >> dictionary that implement CC (4) is what causes things to go >> south. >> >> >>> >> >> >> >>> >> What you want is something like this: >> >> >>> >> >> >> >>> >> {'Auth-Application-Id', [0,4]}, >> >> >>> >> {application, [{alias, cc}, >> >> >>> >> {dictionary, diameter_gen_base_rfc4006}, >> >> >>> >> {module, [server_cb, cc]}], >> >> >>> >> {application, [{alias, base}, >> >> >>> >> {dictionary, diameter_gen_base_rfc6733}, >> >> >>> >> {module, [server_cb, base]}]} >> >> >>> >> >> >> >>> >> That is, advertise both application with the Auth-Application-Id >> >> >>> >> config and configure corresponding dictionaries with >> 'application' >> >> >>> >> config. You might prefer two different callback modules >> (instead of >> >> >>> >> an >> >> >>> >> extra argument) but the point is to match your advertised >> >> >>> >> capabilities >> >> >>> >> with your configured dictionaries. >> >> >>> >> >> >> >>> >> On a side note, you shouldn't use a diameter prefix on your own >> >> >>> >> dictionaries, so as not to collide with something diameter does >> in >> >> >>> >> the >> >> >>> >> future. >> >> >>> >> >> >> >>> >> /Anders, Erlang/OTP >> >> >>> >> >> >> >>> >> > >> >> >>> >> > =ERROR REPORT==== 20-Mar-2013::21:40:50 === >> >> >>> >> > ** Generic server <0.3841.0> terminating >> >> >>> >> > ** Last message in was {diameter, >> >> >>> >> > {recv, >> >> >>> >> > >> >> >>> >> > <<1,0,0,124,128,0,1,1,0,0,0,0,101,222,1,72, >> >> >>> >> > >> >> >>> >> > 101,222,1,72,0,0,1,8,64,0,0,26,99,108,105, >> >> >>> >> > >> >> >>> >> > 101,110,116,46,101,120,97,109,112,108,101, >> >> >>> >> > >> >> >>> >> > 46,99,111,109,0,0,0,0,1,40,64,0,0,19,101, >> >> >>> >> > >> >> >>> >> > 120,97,109,112,108,101,46,99,111,109,0,0,0, >> >> >>> >> > >> >> >>> >> > 1,1,64,0,0,14,0,1,127,0,0,1,0,0,0,0,1,10,64, >> >> >>> >> > >> >> >>> >> > 0,0,12,0,0,0,193,0,0,1,13,0,0,0,14,67,108, >> >> >>> >> > >> >> >>> >> > 105,101,110,116,0,0,0,0,1,2,64,0,0,12,0,0,0, >> >> >>> >> > 0>>}} >> >> >>> >> > ** When Server state == >> >> >>> >> > {state,recv_CER,accept,<0.3840.0>,<0.3842.0>, >> >> >>> >> > diameter_gen_base_rfc3588, >> >> >>> >> > {diameter_service,<0.50.0>, >> >> >>> >> > >> >> >>> >> > {diameter_caps,"server.example.com", >> >> >>> >> > "example.com", >> >> >>> >> > [{127,0,0,1}], >> >> >>> >> > 193,"Server",[],[], >> >> >>> >> > [0], >> >> >>> >> > [],[],[],[],[]}, >> >> >>> >> > [{diameter_app,server, >> >> >>> >> > >> >> >>> >> > diameter_gen_base_rfc4006_cc, >> >> >>> >> > [server_cb], >> >> >>> >> > server,4,false, >> >> >>> >> > [{answer_errors,report}, >> >> >>> >> > >> >> >>> >> > {request_errors,answer_3xxx}]}]}, >> >> >>> >> > false,exit} >> >> >>> >> > ** Reason for termination == >> >> >>> >> > ** {{badmatch,{error,{app_not_configured,0}}}, >> >> >>> >> > [{diameter_peer_fsm,recv_CER,2, >> >> >>> >> > >> >> >>> >> > [{file,"src/diameter_peer_fsm.erl"},{line,849}]}, >> >> >>> >> > {diameter_peer_fsm,build_answer,3, >> >> >>> >> > >> >> >>> >> > [{file,"src/diameter_peer_fsm.erl"},{line,680}]}, >> >> >>> >> > {diameter_peer_fsm,send_answer,3, >> >> >>> >> > >> >> >>> >> > [{file,"src/diameter_peer_fsm.erl"},{line,647}]}, >> >> >>> >> > {diameter_peer_fsm,handle_info,2, >> >> >>> >> > >> >> >>> >> > [{file,"src/diameter_peer_fsm.erl"},{line,292}]}, >> >> >>> >> > >> >> >>> >> > >> {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,607}]}, >> >> >>> >> > >> >> >>> >> > >> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]} >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > Could you give me some hints on this issue? The erlang >> debugger >> >> >>> >> > is >> >> >>> >> > not >> >> >>> >> > easy >> >> >>> >> > to use and call stack information is hard to read (when I show >> >> >>> >> > the >> >> >>> >> > trace >> >> >>> >> > window, all the buttons for step/next/continue become >> invisible). >> >> >>> >> > The >> >> >>> >> > diameter guidance explains the concept but no clear steps >> about >> >> >>> >> > configuration. >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > Many thanks! >> >> >>> >> > >> >> >>> >> > Samuel >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > On Tue, Mar 12, 2013 at 12:10 PM, S X < >> erlangprogram@REDACTED> >> >> >>> >> > wrote: >> >> >>> >> >> >> >> >>> >> >> Hello, Anders & Andre, >> >> >>> >> >> >> >> >>> >> >> Thanks a lot for your quick responses and suggestions, which >> >> >>> >> >> help >> >> >>> >> >> me >> >> >>> >> >> start >> >> >>> >> >> to exploring Erlang world ^_^ >> >> >>> >> >> >> >> >>> >> >> I was able to generate based on the file rfc4006_cc.dia under >> >> >>> >> >> the >> >> >>> >> >> diameter/examples/dict folders. And understand a bit why and >> how >> >> >>> >> >> Erlang >> >> >>> >> >> diameter protocol dictionaries are organized and maintained. >> >> >>> >> >> >> >> >>> >> >> Many thanks and talk to you later! >> >> >>> >> >> >> >> >>> >> >> Samuel >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> On Tue, Mar 12, 2013 at 7:44 AM, Anders Svensson >> >> >>> >> >> >> >> >>> >> >> wrote: >> >> >>> >> >>> >> >> >>> >> >>> Btw, there's an RFC 4006 dictionary (and a few more) under >> >> >>> >> >>> diameter/examples/dict in the repo. >> >> >>> >> >>> >> >> >>> >> >>> /Anders, Erlang/OTP >> >> >>> >> >>> >> >> >>> >> >>> On Tue, Mar 12, 2013 at 10:32 AM, Andr? Graf >> >> >>> >> >>> >> >> >>> >> >>> wrote: >> >> >>> >> >>> > Hello S(?) >> >> >>> >> >>> > >> >> >>> >> >>> > You have to come up with your own .dia file if the message >> >> >>> >> >>> > types >> >> >>> >> >>> > are >> >> >>> >> >>> > not covered in the .dia files provided by Erlang. Your own >> >> >>> >> >>> > .dia >> >> >>> >> >>> > file >> >> >>> >> >>> > will typically include the '@inherits >> >> >>> >> >>> > diameter_gen_base_rfc3588' >> >> >>> >> >>> > clause which imports the basic avp's from rfc3588. You >> then >> >> >>> >> >>> > have >> >> >>> >> >>> > to >> >> >>> >> >>> > provide the missing avp's for your CCR/CCA message types, >> and >> >> >>> >> >>> > also >> >> >>> >> >>> > define these messages. Thanks to the format of a .dia >> file it >> >> >>> >> >>> > is >> >> >>> >> >>> > pretty much copy-pasting from the rfc4006. Once your .dia >> >> >>> >> >>> > file >> >> >>> >> >>> > is >> >> >>> >> >>> > ready, you use diameterc to generate the .erl and .hrl >> file. >> >> >>> >> >>> > >> >> >>> >> >>> > Hope that helped! >> >> >>> >> >>> > >> >> >>> >> >>> > BR/Andr? >> >> >>> >> >>> > >> >> >>> >> >>> > >> >> >>> >> >>> > >> >> >>> >> >>> > On 12 March 2013 04:58, S X >> wrote: >> >> >>> >> >>> >> Hello, >> >> >>> >> >>> >> >> >> >>> >> >>> >> I am new to Erlang and Diameter protocol. Wish someone >> could >> >> >>> >> >>> >> provide >> >> >>> >> >>> >> some >> >> >>> >> >>> >> suggestions on how to utilize the diameter library >> properly >> >> >>> >> >>> >> in >> >> >>> >> >>> >> Erlang. >> >> >>> >> >>> >> >> >> >>> >> >>> >> For example, I want to send/receive some Gx messages, >> like >> >> >>> >> >>> >> CCR >> >> >>> >> >>> >> (Credit >> >> >>> >> >>> >> Control Request), CCA(Credit Control Answer messages. >> But I >> >> >>> >> >>> >> notice >> >> >>> >> >>> >> that >> >> >>> >> >>> >> there are some predefined messages in erlang diameter >> >> >>> >> >>> >> library. >> >> >>> >> >>> >> As >> >> >>> >> >>> >> my >> >> >>> >> >>> >> understanding, should use the utility diameterc to >> generate >> >> >>> >> >>> >> erlang >> >> >>> >> >>> >> header/source files based on dia files. There are few dia >> >> >>> >> >>> >> files >> >> >>> >> >>> >> under >> >> >>> >> >>> >> otp/lib/diameter/src/dict folder, like acct_rfc6733.dia, >> >> >>> >> >>> >> base_rfc3588.dia, >> >> >>> >> >>> >> relay.dia, base_accounting.dia, base_rfc6733.dia. Those >> >> >>> >> >>> >> files >> >> >>> >> >>> >> don't >> >> >>> >> >>> >> have >> >> >>> >> >>> >> the definitions for Gx. >> >> >>> >> >>> >> >> >> >>> >> >>> >> How should I generate or where can I obtain dia files >> which >> >> >>> >> >>> >> have >> >> >>> >> >>> >> support for >> >> >>> >> >>> >> CCR/CCA message format? Are the dia files proprietary or >> >> >>> >> >>> >> manufacturer >> >> >>> >> >>> >> specific? Can I generate with the 3GPP spec? What are the >> >> >>> >> >>> >> proper >> >> >>> >> >>> >> steps? >> >> >>> >> >>> >> >> >> >>> >> >>> >> Thanks a lot! >> >> >>> >> >>> >> >> >> >>> >> >>> >> S >> >> >>> >> >>> >> >> >> >>> >> >>> >> >> >> >>> >> >>> >> _______________________________________________ >> >> >>> >> >>> >> 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 erlangprogram@REDACTED Thu Feb 6 05:16:51 2014 From: erlangprogram@REDACTED (Samuel X) Date: Wed, 5 Feb 2014 23:16:51 -0500 Subject: [erlang-questions] erlang diameter dictionary In-Reply-To: References: Message-ID: Hi Anders, I found the answer in the diameter documentation. Now I feel I should know how to use the library after debugging it. The main reason for those naive questions is because I am not familiar with the diameter protocol. Thanks a lot for your help and time! Samuel On Wed, Feb 5, 2014 at 9:56 PM, Samuel X wrote: > Hi Anders, > > I found the reason why the diameter library won't parse the avp with code > 1023. > Since the message pattern is avp_name(Code, Vid), > After I manually modified the generated dictionary erlang source file by > setting the Vid then it can match the pattern and parse. > > However, I don't get why the diameterc utility doesn't fill this Vid field > while compiling a dictionary. > In the dictionary, I define @vendor 10415 IETF. > > But why the Vid set as undefined like this in the generated erl file: > > avp_name(1023, undefined) -> > > Can you give me some suggestions how to set this properly in a dictionary > file to get the proper avp pattern? Or the diameter library document has > the steps. > > Thanks a lot! > > Samuel > > > > On Tue, Feb 4, 2014 at 12:15 PM, Samuel X wrote: > >> Hi Anders, >> >> Thanks for your reply, Your suggestions are valuable. I am still playing >> with some trial code. So need to worry about name space convention for now. >> >> I think I did recompile everything with rebar (clean then compile). But I >> didn't continue with the rfc4006 dictionary. >> >> I redefined my CCR/CCA messages and received something back from peer >> with success code 2001. However I got decoding error. I debugged the >> decoding process. Something makes me confused. >> >> After splitting all AVPS, other AVPs are parsed ok, except two. One is >> like this, simple enum data: >> >> < Avps = [ {diameter_avp,1023,10415,true,false, >> <<0,0,0,0>>, >> undefined,undefined,undefined,7}, >> >> I think I defined the dictionary properly. For instance, the generated >> dictionary erlang file has the 1023 definition: >> >> avp_name(1023, undefined) -> >> {'Bearer-Control-Mode', 'Enumerated'}; >> >> avp_header('Bearer-Control-Mode') -> >> {1023, 64, undefined}; >> >> {avp_types, >> [{"Bearer-Control-Mode", 1023, "Enumerated", >> "M"}, >> >> >> But when I debug the Mod:decode_avps step by step, I don't see it try to >> step into the proper avp_name mapping and throw the error >> {5001, >> {diameter_avp,1023,10415,true,false, >> <<0,0,0,0>>, >> undefined,undefined,undefined,7}}, >> >> I saw it tried to parse with avp_name(443, undefined) -> >> {'Subscription-Id', 'Grouped'}; >> >> >> Do I misunderstand anything in diameter library? What I did wrong to >> cause this? How should I better understand the encode/decode process in >> diameter library? >> >> Could you please give me some suggestions? >> >> Thanks a lot! >> >> Samuel >> >> >> >> On Mon, Jan 27, 2014 at 4:52 AM, Anders Svensson wrote: >> >>> Hi Samuel. >>> >>> > How are you? >>> >>> Still kicking, thanks. :) >>> >>> > I have a question about modifying diameter dictionary. For example, for >>> > diameter CCR message, if I want to change "Service-Context-Id" from >>> > mandatory to non mandatory property so I don't have to fill this >>> property in >>> > the CCR message, I changed the file rfc4006_cc.dia as following: >>> > >>> > 1. Service-Context-Id 461 UTF8String - >>> > 2. Change from {Service-Context-id} to [Service-Context-Id] and move it >>> > below {CC-Request-Number} in CCR message definition >>> >>> Easy enough to do but if you send a CCR without Service-Context-Id to >>> a node expecting an RFC 4006 CCR then the request is likely to be >>> rejected. 1.3.3 of RFC 6733 requires a new Command Code when making >>> this specific modification. >>> >>> > Then I used diameterc to generate new erlang files accordingly. The >>> files >>> > look good and I was able to compile. By the way, I include the diameter >>> > library source code from OTP release R16B03 into the project, just in >>> order >>> > to debug the diameter easily. >>> > >>> > I filled the CCR message as below: >>> >>> Just a couple of pointers before getting to the actual issue ... >>> >>> > CCR = #diameter_rfc4006_cc_CCR{ >>> >>> It's not a good idea to use diameter as a prefix here in case diameter >>> itself ships with a this dictionary one day. >>> >>> > 'Session-Id' = diameter:session_id(?L(who)), >>> > 'Auth-Application-Id' = 16777238, >>> > 'CC-Request-Type' = >>> > ?'DIAMETER_RFC4006_CC_CC-REQUEST-TYPE_INITIAL_REQUEST', >>> >>> These long macro names are truly hideous, at least if you like to be >>> able to maintain readable line lengths. (78 characters in my book.) At >>> best I'd redefine those I want to use. >>> >>> Eg. -define(INITIAL, >>> ?'DIAMETER_RFC4006_CC_CC-REQUEST-TYPE_INITIAL_REQUEST'). >>> >>> > 'CC-Request-Number' = 0 >>> > }, >>> > diameter:call(Name, ?APP_CCR_ALIAS, CCR, []). >>> > >>> > When I run from the erlang shell R16B03, I got the encoding error like >>> this: >>> > >>> > why: {diameter_codec,encode, >>> > {{mandatory_avp_missing,'CC-Request-Type','CCR'}, >>> >>> I suspect you haven't recompiled your source file after modifying the >>> dictionary. Records are just tuples, and fields in the record notation >>> are mapped to tuple indices using the record definition known to the >>> source in question. If the source creating the record above has the >>> "old" definition then the fields set as CC-Request-Type and >>> CC-Request-Number will be in the positions in which the "new" >>> dictionary module expects to find CC-Request-Number and >>> Service-Context-Id, leading to the "missing" CC-Request-Type error. >>> >>> That is, you need to recompile any source that includes a generated >>> hrl, in addition to loading the new dictionary module. >>> >>> > [{diameter_gen_rfc4006_cc,encode_avps,2, >>> > [{file, >>> > >>> > "/usr/lib/erlang/lib/diameter-1.5/include/diameter_gen.hrl"}, >>> > {line,59}]}, >>> > {diameter_codec,e,2, >>> > [{file,"src/diameter_codec.erl"},{line,120}]}, >>> > {diameter_codec,encode,2, >>> > [{file,"src/diameter_codec.erl"},{line,71}]}, >>> > {diameter_traffic,encode,3, >>> > [{file,"src/diameter_traffic.erl"},{line,1481}]}, >>> > {diameter_traffic,send_R,6, >>> > [{file,"src/diameter_traffic.erl"},{line,1320}]}, >>> > {diameter_traffic,'-send_request/4-fun-0-',6, >>> > [{file,"src/diameter_traffic.erl"},{line,1094}]}]}} >>> > who: <0.62.0> >>> > what: {diameter_codec,encode, >>> > [diameter_gen_rfc4006_cc, >>> > {diameter_packet, >>> > {diameter_header,1,undefined,undefined,undefined, >>> > >>> 398339147,398339147,undefined,undefined,undefined, >>> > undefined}, >>> > undefined, >>> > {diameter_rfc4006_cc_CCR, >>> > >>> ["who",";","1452024187",";","1",";","nonode@REDACTED"], >>> > "centos","example.com","example.com",16777238, >>> > undefined,1,0, >>> > ["centos"], >>> > >>> > >>> > [],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[], >>> > []}, >>> > undefined,[],undefined}]} >>> > {error,encode} >>> > >>> > I don't really understand why getting this error or the error >>> information is >>> > a little bit confusing me. >>> > Am I doing right to modify the dictionary file? What is the proper way >>> to do >>> > that? >>> >>> Nothing wrong with the modification, aside from the fact that you're >>> straying from RFC 4006 Credit-Control as I mentioned above. >>> >>> > What is best way of debugging the diameter library? Can you give me >>> some >>> > hints? >>> >>> In this case it's just confusion over record definitions I think, and >>> these are always confusing until you realize that different code might >>> have different record definitions. You can see the record being >>> encoded by tracing on diameter_codec:encode/2 for example, which would >>> show the unexpected positions of CC-Request-Type and CC-Request-Number >>> relative to your dictionary definition. >>> >>> /Anders, Erlang/OTP >>> >>> >>> >>> > >>> > Thanks a lot! >>> > >>> > Samuel >>> > >>> > >>> > On Sat, Mar 23, 2013 at 7:11 AM, Anders Svensson >> > >>> > wrote: >>> >> >>> >> On Fri, Mar 22, 2013 at 7:52 PM, S X wrote: >>> >> > Hi Anders, >>> >> > >>> >> > Sorry, I think I understand now. You told me the solution. Just use >>> '[ >>> >> > ]'. >>> >> > >>> >> > Anyhow, many thanks! >>> >> > >>> >> > By the way, since 3588 is obsolete, can I use 6733 while compile >>> other >>> >> > dictionaries? >>> >> >>> >> Yes. /Anders >>> >> >>> >> >>> >> > >>> >> > Thanks! >>> >> > >>> >> > Samuel >>> >> > >>> >> > >>> >> > On Fri, Mar 22, 2013 at 2:46 PM, S X >>> wrote: >>> >> >> >>> >> >> Hi Anders, >>> >> >> >>> >> >> Thanks for your quick response. But I still don't get why the DH is >>> >> >> being >>> >> >> interpreted as a list of Destination-Host values ( Is it because >>> the >>> >> >> define >>> >> >> "avp_arity('CCR', 'Destination-Host') -> {0, 1};"). >>> >> >> >>> >> >> And if it is treated as a list, how come it has a length greater >>> than >>> >> >> 1, I >>> >> >> just set it once in prepare_request. >>> >> >> >>> >> >> What should I do to correct it? Or which document should I read >>> more >>> >> >> carefully to understand this properly? >>> >> >> >>> >> >> Thanks a lot! >>> >> >> >>> >> >> Samuel >>> >> >> >>> >> >> >>> >> >> On Fri, Mar 22, 2013 at 1:27 PM, Anders Svensson < >>> anders.otp@REDACTED> >>> >> >> wrote: >>> >> >>> >>> >> >>> Hi Samuel >>> >> >>> >>> >> >>> On Fri, Mar 22, 2013 at 5:55 PM, S X >>> wrote: >>> >> >>> > Thanks a lot, Anders, >>> >> >>> > >>> >> >>> > I think I overlooked what the meaning of the configurable ID >>> tag (4) >>> >> >>> > in >>> >> >>> > the >>> >> >>> > dia file is , which is supposed to be the important application >>> ID >>> >> >>> > to >>> >> >>> > be >>> >> >>> > used in the configuration. Your suggestion about the prefix is >>> also >>> >> >>> > right. >>> >> >>> > But now I am just learning erlang diameter library. >>> >> >>> > >>> >> >>> > I just try to follow the sample RAR message style, and am still >>> >> >>> > having >>> >> >>> > issue >>> >> >>> > with sending CCR message. The client configuration now is: >>> >> >>> > >>> >> >>> > -define(SERVICE(Name), [{'Origin-Host', ?L(Name) ++ ". >>> example.com"}, >>> >> >>> > {'Origin-Realm', "example.com"}, >>> >> >>> > {'Vendor-Id', 193}, >>> >> >>> > {'Product-Name', "Client"}, >>> >> >>> > {'Auth-Application-Id', >>> >> >>> > [?DIAMETER_APP_ID_CCRA]}, >>> >> >>> > {application, [{alias, ?APP_CCR_ALIAS}, >>> >> >>> > {dictionary, >>> >> >>> > ?DIAMETER_DICT_CCRA}, >>> >> >>> > {module, >>> client_cb_ccra}]}]). >>> >> >>> > >>> >> >>> > Try to send CCR message: >>> >> >>> > >>> >> >>> > call(Name) -> >>> >> >>> > SId = diameter:session_id(?L(Name)), >>> >> >>> > CCR = #diameter_base_rfc4006_cc_CCR{ >>> >> >>> > 'Session-Id' = SId, >>> >> >>> > 'Service-Context-Id' = "Test", >>> >> >>> > 'CC-Request-Type' = >>> >> >>> > ?'DIAMETER_BASE_RFC4006_CC_CC-REQUEST-TYPE_INITIAL_REQUEST', >>> >> >>> > 'CC-Request-Number' = 0, >>> >> >>> > 'Auth-Application-Id' = ?DIAMETER_APP_ID_CCRA, >>> >> >>> > 'User-Name' = "Me"}, >>> >> >>> > diameter:call(Name, ?APP_CCR_ALIAS, CCR, []). >>> >> >>> > >>> >> >>> > >>> >> >>> > In the client callback module: >>> >> >>> > >>> >> >>> > prepare_request(#diameter_packet{msg = Rec}, _, {_, Caps}) -> >>> >> >>> > #diameter_caps{origin_host = {OH, DH}, >>> >> >>> > origin_realm = {OR, DR}} >>> >> >>> > = Caps, >>> >> >>> > >>> >> >>> > {send, Rec#diameter_base_rfc4006_cc_CCR{'Origin-Host' = OH, >>> >> >>> > 'Origin-Realm' = OR, >>> >> >>> > 'Destination-Host' = DH, >>> >> >>> > 'Destination-Realm' = DR}}. >>> >> >>> > >>> >> >>> > I got the error about AVP property: >>> >> >>> > >>> >> >>> > =ERROR REPORT==== 22-Mar-2013::00:17:31 === >>> >> >>> > why: {diameter_codec,encode, >>> >> >>> > >>> {{repeated_avp_excessive_arity,'Destination-Host',1, >>> >> >>> > "server.example.com",'CCR'}, >>> >> >>> >>> >> >>> This is because Destination-Host is optional in CCR and AVP's are >>> >> >>> encoded differently in a message record depending on whether or >>> not >>> >> >>> there can be exactly one occurrence: if so then the field value >>> should >>> >> >>> be the AVP value, if not then a list of AVP values. That is, your >>> CCR >>> >> >>> record should have >>> >> >>> >>> >> >>> 'Destination-Host' = [DH], >>> >> >>> >>> >> >>> in this case. >>> >> >>> >>> >> >>> > [{diameter_gen_base_rfc4006_cc,encode_avps,2, >>> >> >>> > >>> >> >>> > [{file,"diameter_gen_base_rfc4006_cc.erl"},{line,47}]}, >>> >> >>> > >>> >> >>> > {diameter_codec,e,2,[{file,"diameter_codec.erl"},{line,112}]}, >>> >> >>> > {diameter_codec,encode,2, >>> >> >>> > [{file,"diameter_codec.erl"},{line,63}]}, >>> >> >>> > {diameter_traffic,encode,3, >>> >> >>> > [{file,"diameter_traffic.erl"},{line,1437}]}, >>> >> >>> > {diameter_traffic,send_R,6, >>> >> >>> > [{file,"diameter_traffic.erl"},{line,1276}]}, >>> >> >>> > {diameter_traffic,'-send_request/4-fun-0-',4, >>> >> >>> > >>> [{file,"diameter_traffic.erl"},{line,1050}]}]}} >>> >> >>> > who: <0.180.0> >>> >> >>> > what: {diameter_codec,encode, >>> >> >>> > [diameter_gen_base_rfc4006_cc, >>> >> >>> > {diameter_packet, >>> >> >>> > >>> {diameter_header,1,undefined,undefined,undefined, >>> >> >>> > >>> >> >>> > 1330492780,1330492780,undefined,undefined,undefined, >>> >> >>> > undefined}, >>> >> >>> > undefined, >>> >> >>> > {diameter_base_rfc4006_cc_CCR, >>> >> >>> > >>> >> >>> > ["client",";","1425429748",";","2",";","nonode@REDACTED"], >>> >> >>> > >>> >> >>> > "client.example.com","example.com","example.com",4, >>> >> >>> > >>> >> >>> > "Test",1,0,"server.example.com","Me",[],[],[],[],[],[], >>> >> >>> > [],[],[],[],[],[],[],[],[],[],[],[]}, >>> >> >>> > undefined,[],undefined}]} >>> >> >>> > >>> >> >>> > My understanding is that the client callback prepare_request >>> sets >>> >> >>> > the >>> >> >>> > "Destination-Host" (retrievd via the CER/A done at earilier >>> stage) >>> >> >>> > in >>> >> >>> > the >>> >> >>> > CCR message. So I should set it right. But seems I still >>> >> >>> > misunderstand >>> >> >>> > something. Does the error information >>> "repeated_avp_excessive_arity" >>> >> >>> > mean " >>> >> >>> > 0-1 Zero or one instance of the AVP MAY be present in the >>> message. >>> >> >>> > It >>> >> >>> > is >>> >> >>> >>> >> >>> Yes, exactly. In your case your DH is being interpreted as list of >>> >> >>> Destination-Host values, and "excessive arity" is a result of that >>> >> >>> list having length greater than 1. >>> >> >>> >>> >> >>> /Anders, Erlang/OTP >>> >> >>> >>> >> >>> >>> >> >>> > considered an error if there is more than one instance of the >>> AVP" >>> >> >>> > according >>> >> >>> > to rfc4006 spec? The erlang error message is not that >>> >> >>> > straightforward, >>> >> >>> > really confusing newbies:). >>> >> >>> > >>> >> >>> > Do you have any hints? (I hope I could provide some ramp up >>> steps >>> >> >>> > for >>> >> >>> > other >>> >> >>> > people to learn with erlang diameter library after making it >>> >> >>> > work^_^) >>> >> >>> > >>> >> >>> > Many thanks, >>> >> >>> > >>> >> >>> > Samuel >>> >> >>> > >>> >> >>> > >>> >> >>> > >>> >> >>> > On Thu, Mar 21, 2013 at 8:59 AM, Anders Svensson >>> >> >>> > >>> >> >>> > wrote: >>> >> >>> >> >>> >> >>> >> On Thu, Mar 21, 2013 at 2:55 AM, S X >>> >> >>> >> wrote: >>> >> >>> >> > Hello, >>> >> >>> >> > >>> >> >>> >> > Sorry, I still have some problems with sending CCR/CCA >>> messages. >>> >> >>> >> > I >>> >> >>> >> > didn't >>> >> >>> >> > quite get how to configure multiple diameter applications >>> though >>> >> >>> >> > it >>> >> >>> >> > seems >>> >> >>> >> > clear when I read the diameter protocol. >>> >> >>> >> > >>> >> >>> >> > Based on the sample diameter code, I made the following >>> changes, >>> >> >>> >> > diameter_gen_base_rfc4006_cc is the dictionary generated with >>> >> >>> >> > rfc4006_cc.dia: >>> >> >>> >> > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Client >>> >> >>> >> > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ >>> >> >>> >> > >>> >> >>> >> > -define(SVC_NAME, ?MODULE). >>> >> >>> >> > -define(APP_ALIAS, ?MODULE). >>> >> >>> >> > -define(CALLBACK_MOD, client_cb). >>> >> >>> >> > -define(DIAMETER_DICT_CCRA, diameter_gen_base_rfc4006_cc). >>> >> >>> >> > >>> >> >>> >> > -define(L, atom_to_list). >>> >> >>> >> > >>> >> >>> >> > -define(SERVICE(Name), [{'Origin-Host', ?L(Name) ++ >>> >> >>> >> > ".example.com"}, >>> >> >>> >> > {'Origin-Realm', "example.com"}, >>> >> >>> >> > {'Vendor-Id', 0}, >>> >> >>> >> > {'Product-Name', "Client"}, >>> >> >>> >> > {'Auth-Application-Id', >>> >> >>> >> > [?DIAMETER_APP_ID_COMMON]}, >>> >> >>> >> > {application, [{alias, ?APP_ALIAS}, >>> >> >>> >> > {dictionary, >>> >> >>> >> > ?DIAMETER_DICT_CCRA}, >>> >> >>> >> > {module, >>> >> >>> >> > ?CALLBACK_MOD}]}]). >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Server >>> >> >>> >> > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ >>> >> >>> >> > >>> >> >>> >> > -define(DIAMETER_DICT_CCRA, diameter_gen_base_rfc4006_cc). >>> >> >>> >> > >>> >> >>> >> > init(State) -> >>> >> >>> >> > SvcName = ?MODULE, >>> >> >>> >> > SvcOpts = [{'Origin-Host', atom_to_list(SvcName) ++ >>> >> >>> >> > ".example.com"}, >>> >> >>> >> > {'Origin-Realm', "example.com"}, >>> >> >>> >> > {'Vendor-Id', 193}, >>> >> >>> >> > {'Product-Name', "Server"}, >>> >> >>> >> > {'Auth-Application-Id', >>> >> >>> >> > [?DIAMETER_APP_ID_COMMON]}, >>> >> >>> >> > {application, [{alias, ?MODULE}, >>> >> >>> >> > {dictionary, >>> ?DIAMETER_DICT_CCRA}, >>> >> >>> >> > {module, server_cb}]}], >>> >> >>> >> > TransportOpts = [{transport_module, diameter_tcp}, >>> >> >>> >> > {transport_config, [{reuseaddr, >>> true}, >>> >> >>> >> > {ip, {127,0,0,1}}, {port, 3868}]}], >>> >> >>> >> > diameter:start(), >>> >> >>> >> > diameter:start_service(SvcName, SvcOpts), >>> >> >>> >> > diameter:add_transport(SvcName, {listen, TransportOpts}), >>> >> >>> >> > erlang:display("Set up diameter server completed!"), >>> >> >>> >> > {ok, State}. >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> > I changed the callbacks client_cb and server_cb to handle >>> CCR/CCA >>> >> >>> >> > messages. >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> > However, I got the following errors "app_not_configured". It >>> >> >>> >> > seems >>> >> >>> >> > the >>> >> >>> >> > configuration for applications is incorrect. How should I >>> >> >>> >> > configure >>> >> >>> >> > the >>> >> >>> >> > service properly? My understanding is I want to reuse >>> CER/CEA as >>> >> >>> >> > default >>> >> >>> >> > authorization application, but the erlang diameter doesn't >>> >> >>> >> > explain >>> >> >>> >> > how >>> >> >>> >> > to do >>> >> >>> >> > it. Or my understanding is incorrect at all. >>> >> >>> >> >>> >> >>> >> The problem is a mismatch between the application and >>> capabilities >>> >> >>> >> configuration in your SvcOpts: the 'Auth-Application-Id' tuple >>> >> >>> >> specifies the Application Id's that are advertised in the >>> outgoing >>> >> >>> >> CER/CEA (that diameter itself sends) while 'applications' >>> specifies >>> >> >>> >> corresponding dictionary modules. In your case, advertising the >>> >> >>> >> common >>> >> >>> >> application (0) during capabilities exchange but backing it up >>> with >>> >> >>> >> a >>> >> >>> >> dictionary that implement CC (4) is what causes things to go >>> south. >>> >> >>> >> >>> >> >>> >> What you want is something like this: >>> >> >>> >> >>> >> >>> >> {'Auth-Application-Id', [0,4]}, >>> >> >>> >> {application, [{alias, cc}, >>> >> >>> >> {dictionary, diameter_gen_base_rfc4006}, >>> >> >>> >> {module, [server_cb, cc]}], >>> >> >>> >> {application, [{alias, base}, >>> >> >>> >> {dictionary, diameter_gen_base_rfc6733}, >>> >> >>> >> {module, [server_cb, base]}]} >>> >> >>> >> >>> >> >>> >> That is, advertise both application with the >>> Auth-Application-Id >>> >> >>> >> config and configure corresponding dictionaries with >>> 'application' >>> >> >>> >> config. You might prefer two different callback modules >>> (instead of >>> >> >>> >> an >>> >> >>> >> extra argument) but the point is to match your advertised >>> >> >>> >> capabilities >>> >> >>> >> with your configured dictionaries. >>> >> >>> >> >>> >> >>> >> On a side note, you shouldn't use a diameter prefix on your own >>> >> >>> >> dictionaries, so as not to collide with something diameter >>> does in >>> >> >>> >> the >>> >> >>> >> future. >>> >> >>> >> >>> >> >>> >> /Anders, Erlang/OTP >>> >> >>> >> >>> >> >>> >> > >>> >> >>> >> > =ERROR REPORT==== 20-Mar-2013::21:40:50 === >>> >> >>> >> > ** Generic server <0.3841.0> terminating >>> >> >>> >> > ** Last message in was {diameter, >>> >> >>> >> > {recv, >>> >> >>> >> > >>> >> >>> >> > <<1,0,0,124,128,0,1,1,0,0,0,0,101,222,1,72, >>> >> >>> >> > >>> >> >>> >> > 101,222,1,72,0,0,1,8,64,0,0,26,99,108,105, >>> >> >>> >> > >>> >> >>> >> > 101,110,116,46,101,120,97,109,112,108,101, >>> >> >>> >> > >>> >> >>> >> > 46,99,111,109,0,0,0,0,1,40,64,0,0,19,101, >>> >> >>> >> > >>> >> >>> >> > 120,97,109,112,108,101,46,99,111,109,0,0,0, >>> >> >>> >> > >>> >> >>> >> > 1,1,64,0,0,14,0,1,127,0,0,1,0,0,0,0,1,10,64, >>> >> >>> >> > >>> >> >>> >> > 0,0,12,0,0,0,193,0,0,1,13,0,0,0,14,67,108, >>> >> >>> >> > >>> >> >>> >> > 105,101,110,116,0,0,0,0,1,2,64,0,0,12,0,0,0, >>> >> >>> >> > 0>>}} >>> >> >>> >> > ** When Server state == >>> >> >>> >> > {state,recv_CER,accept,<0.3840.0>,<0.3842.0>, >>> >> >>> >> > diameter_gen_base_rfc3588, >>> >> >>> >> > {diameter_service,<0.50.0>, >>> >> >>> >> > >>> >> >>> >> > {diameter_caps,"server.example.com", >>> >> >>> >> > "example.com", >>> >> >>> >> > [{127,0,0,1}], >>> >> >>> >> > 193,"Server",[],[], >>> >> >>> >> > [0], >>> >> >>> >> > [],[],[],[],[]}, >>> >> >>> >> > [{diameter_app,server, >>> >> >>> >> > >>> >> >>> >> > diameter_gen_base_rfc4006_cc, >>> >> >>> >> > [server_cb], >>> >> >>> >> > server,4,false, >>> >> >>> >> > [{answer_errors,report}, >>> >> >>> >> > >>> >> >>> >> > {request_errors,answer_3xxx}]}]}, >>> >> >>> >> > false,exit} >>> >> >>> >> > ** Reason for termination == >>> >> >>> >> > ** {{badmatch,{error,{app_not_configured,0}}}, >>> >> >>> >> > [{diameter_peer_fsm,recv_CER,2, >>> >> >>> >> > >>> >> >>> >> > [{file,"src/diameter_peer_fsm.erl"},{line,849}]}, >>> >> >>> >> > {diameter_peer_fsm,build_answer,3, >>> >> >>> >> > >>> >> >>> >> > [{file,"src/diameter_peer_fsm.erl"},{line,680}]}, >>> >> >>> >> > {diameter_peer_fsm,send_answer,3, >>> >> >>> >> > >>> >> >>> >> > [{file,"src/diameter_peer_fsm.erl"},{line,647}]}, >>> >> >>> >> > {diameter_peer_fsm,handle_info,2, >>> >> >>> >> > >>> >> >>> >> > [{file,"src/diameter_peer_fsm.erl"},{line,292}]}, >>> >> >>> >> > >>> >> >>> >> > >>> {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,607}]}, >>> >> >>> >> > >>> >> >>> >> > >>> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]} >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> > Could you give me some hints on this issue? The erlang >>> debugger >>> >> >>> >> > is >>> >> >>> >> > not >>> >> >>> >> > easy >>> >> >>> >> > to use and call stack information is hard to read (when I >>> show >>> >> >>> >> > the >>> >> >>> >> > trace >>> >> >>> >> > window, all the buttons for step/next/continue become >>> invisible). >>> >> >>> >> > The >>> >> >>> >> > diameter guidance explains the concept but no clear steps >>> about >>> >> >>> >> > configuration. >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> > Many thanks! >>> >> >>> >> > >>> >> >>> >> > Samuel >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> > On Tue, Mar 12, 2013 at 12:10 PM, S X < >>> erlangprogram@REDACTED> >>> >> >>> >> > wrote: >>> >> >>> >> >> >>> >> >>> >> >> Hello, Anders & Andre, >>> >> >>> >> >> >>> >> >>> >> >> Thanks a lot for your quick responses and suggestions, which >>> >> >>> >> >> help >>> >> >>> >> >> me >>> >> >>> >> >> start >>> >> >>> >> >> to exploring Erlang world ^_^ >>> >> >>> >> >> >>> >> >>> >> >> I was able to generate based on the file rfc4006_cc.dia >>> under >>> >> >>> >> >> the >>> >> >>> >> >> diameter/examples/dict folders. And understand a bit why >>> and how >>> >> >>> >> >> Erlang >>> >> >>> >> >> diameter protocol dictionaries are organized and maintained. >>> >> >>> >> >> >>> >> >>> >> >> Many thanks and talk to you later! >>> >> >>> >> >> >>> >> >>> >> >> Samuel >>> >> >>> >> >> >>> >> >>> >> >> >>> >> >>> >> >> On Tue, Mar 12, 2013 at 7:44 AM, Anders Svensson >>> >> >>> >> >> >>> >> >>> >> >> wrote: >>> >> >>> >> >>> >>> >> >>> >> >>> Btw, there's an RFC 4006 dictionary (and a few more) under >>> >> >>> >> >>> diameter/examples/dict in the repo. >>> >> >>> >> >>> >>> >> >>> >> >>> /Anders, Erlang/OTP >>> >> >>> >> >>> >>> >> >>> >> >>> On Tue, Mar 12, 2013 at 10:32 AM, Andr? Graf >>> >> >>> >> >>> >>> >> >>> >> >>> wrote: >>> >> >>> >> >>> > Hello S(?) >>> >> >>> >> >>> > >>> >> >>> >> >>> > You have to come up with your own .dia file if the >>> message >>> >> >>> >> >>> > types >>> >> >>> >> >>> > are >>> >> >>> >> >>> > not covered in the .dia files provided by Erlang. Your >>> own >>> >> >>> >> >>> > .dia >>> >> >>> >> >>> > file >>> >> >>> >> >>> > will typically include the '@inherits >>> >> >>> >> >>> > diameter_gen_base_rfc3588' >>> >> >>> >> >>> > clause which imports the basic avp's from rfc3588. You >>> then >>> >> >>> >> >>> > have >>> >> >>> >> >>> > to >>> >> >>> >> >>> > provide the missing avp's for your CCR/CCA message >>> types, and >>> >> >>> >> >>> > also >>> >> >>> >> >>> > define these messages. Thanks to the format of a .dia >>> file it >>> >> >>> >> >>> > is >>> >> >>> >> >>> > pretty much copy-pasting from the rfc4006. Once your .dia >>> >> >>> >> >>> > file >>> >> >>> >> >>> > is >>> >> >>> >> >>> > ready, you use diameterc to generate the .erl and .hrl >>> file. >>> >> >>> >> >>> > >>> >> >>> >> >>> > Hope that helped! >>> >> >>> >> >>> > >>> >> >>> >> >>> > BR/Andr? >>> >> >>> >> >>> > >>> >> >>> >> >>> > >>> >> >>> >> >>> > >>> >> >>> >> >>> > On 12 March 2013 04:58, S X >>> wrote: >>> >> >>> >> >>> >> Hello, >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> I am new to Erlang and Diameter protocol. Wish someone >>> could >>> >> >>> >> >>> >> provide >>> >> >>> >> >>> >> some >>> >> >>> >> >>> >> suggestions on how to utilize the diameter library >>> properly >>> >> >>> >> >>> >> in >>> >> >>> >> >>> >> Erlang. >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> For example, I want to send/receive some Gx messages, >>> like >>> >> >>> >> >>> >> CCR >>> >> >>> >> >>> >> (Credit >>> >> >>> >> >>> >> Control Request), CCA(Credit Control Answer messages. >>> But I >>> >> >>> >> >>> >> notice >>> >> >>> >> >>> >> that >>> >> >>> >> >>> >> there are some predefined messages in erlang diameter >>> >> >>> >> >>> >> library. >>> >> >>> >> >>> >> As >>> >> >>> >> >>> >> my >>> >> >>> >> >>> >> understanding, should use the utility diameterc to >>> generate >>> >> >>> >> >>> >> erlang >>> >> >>> >> >>> >> header/source files based on dia files. There are few >>> dia >>> >> >>> >> >>> >> files >>> >> >>> >> >>> >> under >>> >> >>> >> >>> >> otp/lib/diameter/src/dict folder, like acct_rfc6733.dia, >>> >> >>> >> >>> >> base_rfc3588.dia, >>> >> >>> >> >>> >> relay.dia, base_accounting.dia, base_rfc6733.dia. Those >>> >> >>> >> >>> >> files >>> >> >>> >> >>> >> don't >>> >> >>> >> >>> >> have >>> >> >>> >> >>> >> the definitions for Gx. >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> How should I generate or where can I obtain dia files >>> which >>> >> >>> >> >>> >> have >>> >> >>> >> >>> >> support for >>> >> >>> >> >>> >> CCR/CCA message format? Are the dia files proprietary or >>> >> >>> >> >>> >> manufacturer >>> >> >>> >> >>> >> specific? Can I generate with the 3GPP spec? What are >>> the >>> >> >>> >> >>> >> proper >>> >> >>> >> >>> >> steps? >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> Thanks a lot! >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> S >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> >>> >> >>> >> 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 kino@REDACTED Thu Feb 6 06:35:51 2014 From: kino@REDACTED (satoshi kinoshita) Date: Thu, 6 Feb 2014 14:35:51 +0900 Subject: [erlang-questions] crash while garbing - OTP-7132 Message-ID: Does any one know some more detail information for OTP-7132? --- http://www.erlang.org/doc/apps/erts/notes.html#id114389 ---- The emulator could under rare circumstances crash while garbage collecting. Own Id: OTP-7132 ---------------------------------------------------------------- We're still using R11B-5 and having a crash while doing GC on a process. Though erl_crash.dump is reporting almost 2GB was used for "processes", top/vmstat is just reporting less than 1GB for beam.smp. It is also strange to me that sum of heap and OldHeap for all processes are less than 100M, but processes_used is almost 1.6G. I don't know OTP-7132 is related. Any information will be appreciated. Thanks, Kinoshita -------------------------------------------------------------------- % { grep +heap: erl_crash.dump |cut -d' ' -f2 |tr "\n" +; echo 0; }|bc 46165303 % { grep OldHeap: erl_crash.dump |cut -d' ' -f2 |tr "\n" +; echo 0; }|bc 52591961 --------------------------------------------------------------------------------- =erl_crash_dump:0.1 Thu Jan 30 17:42:24 2014 Slogan: eheap_alloc: Cannot allocate 191315400 bytes of memory (of type "heap"). System version: Erlang (BEAM) emulator version 5.5.5 [source] [smp:8] [async-threads:64] [hipe] [kernel-poll:true] Compiled: Mon Jan 21 18:01:53 2008 Atoms: 9703 =memory total: 1843551840 processes: 1640736600 processes_used: 1626764688 system: 202815240 atom: 433065 atom_used: 428224 binary: 159095424 code: 4043588 ets: 21895748 =hash_table:atom_tab size: 6421 used: 5001 objs: 9703 depth: 8 ... =proc:<0.29953.0> State: Garbing Name: mgs_db_mgse Spawned as: proc_lib:init_p/5 Spawned by: <0.23670.0> Started: Thu Sep 1 22:58:50 2011 Message queue length: 0 Number of heap fragments: 332 Heap fragment data: 34968 Link list: [<0.23670.0>, {from,<0.28232.7497>,#Ref<0.0.29467.224716>}] Reductions: 3060681751 Stack+heap: 38263080 OldHeap: 47828850 Heap unused: 116 OldHeap unused: 47828850 Program counter: 0xb5d7b7bc (mnesia_locker:receive_wlocks/4 + 64) CP: 0xb5939d50 (mnesia_tm:execute_transaction/5 + 340) -------------- next part -------------- An HTML attachment was scrubbed... URL: From michal.piotrowski@REDACTED Thu Feb 6 08:18:52 2014 From: michal.piotrowski@REDACTED (Michal Piotrowski) Date: Thu, 6 Feb 2014 08:18:52 +0100 Subject: [erlang-questions] Mongoose IM Documentation In-Reply-To: References: Message-ID: Hello Kelly, There are some examples on our github: https://github.com/esl/MongooseIM. The default installation of MongooseIM works with mnesia as a database. What exactly do you need to know? BTW, the config file is in most cases compatible with the one in ejabberd 2.1.x. Best regards Michal Piotrowski michal.piotrowski@REDACTED On 05 Feb 2014, at 03:10, Kelly Wong wrote: > Hello, > > I'm trying to setup Mongoose IM, but for the life of me can't find any documentation for it. Can anyone point me in the right direction? > > Thanks, > Kelly Wong > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Thu Feb 6 08:19:14 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 6 Feb 2014 08:19:14 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> Message-ID: <1391671154.4877.3.camel@sekic1152.release> Greetings, These are opinions, not facts. The editors I use have a way to change the size of a tabstop. The word processors I use have a way to change the size of each tabstop level. If 8 was the correct number these possibilities would not be present. bengt On Wed, 2014-02-05 at 22:58 +0100, Anthony Ramine wrote: > Hello Vlad, > > My strategy with regard to indentation is to just expand all tabs on all the lines I edit or add to the code. And I just absolutely don?t care about it not being consistent with the mixed tabs and spaces around it. > > With a correct tabstop (8 and only 8), it doesn?t matter anyway. > > Regards, > From bengt.kleberg@REDACTED Thu Feb 6 08:21:08 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 6 Feb 2014 08:21:08 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <52F2B139.8000802@gmail.com> References: <25B05620-DEDB-47F4-AF46-5C3E573DCA7C@feuerlabs.com> <52F2B139.8000802@gmail.com> Message-ID: <1391671269.4877.5.camel@sekic1152.release> Greetings, These are opinions, not facts. How do we know that tab stops where never standard? bengt On Wed, 2014-02-05 at 13:46 -0800, Michael Truog wrote: > On 02/05/2014 10:40 AM, Ulf Wiger wrote: > > One thing for emacs users (or those who need to deal with them) to do is to insert the following at the top of each erlang module: > > > > %% -*- erlang-indent-level: 4; indent-tabs-mode: nil -*- > > > > (Perhaps others have suggestions for the ultimate settings here) > The ULTIMATE modeline settings should be: > %-*-Mode:erlang;coding:utf-8;tab-width:4;c-basic-offset:4;indent-tabs-mode:()-*- > % ex: set ft=erlang fenc=utf-8 sts=4 ts=4 sw=4 et: > > latin1 would need to be used for the older Erlang source code that requires it (probably all of OTP) which unfortunately makes the emacs modeline more than 80 characters. Having both an emacs and a vi modeline can keep both sets of users happy. > > It is typical to avoid tabs and prefer spaces, so it would be nice to have that be standard, since the OTP code is becoming unreadable due to characters that don't matter (due to not making a decision, you are still deciding to allow both tabs and spaces). Tab stops were never standard and only really relate to typewriters historically (who uses those for Erlang?). > > > > > > > BR, > > Ulf W > > > > On 5 Feb 2014, at 19:14, Vlad Dumitrescu wrote: > > > >> Hi all, > >> > >> It's been almost a full day since the last controversial issue was > >> discussed here and I feel it's time for a new one (well, it's actually > >> old). > >> > >> The default indentation used by the erlang-mode uses a mix of tabs and > >> spaces. Whatever side one is in the "tabs vs spaces" war, mixing them > >> is the common enemy! > >> > >> Not everybody uses emacs, nor should they be forced to. This means > >> that creating a patch might take less time than adjusting the > >> whitespace afterwards, which feels a horrible waste of time and > >> energy. > >> > >> Of course, we the non-emacs-using hackers of the OTP code might be in > >> a crushing minority, and then the issue will get closed quickly. I > >> feel however that I need to try to change this. I have abstained > >> before from submitting small fixes just because of this (instead I > >> sold the idea to someone else, but that doesn't always work). > >> > >> So my question is: are enough people bothered by this issue? If yes, > >> can we try to agree on a solution? Such changes are best done in > >> connection with a release. > >> > >> best regards, > >> Vlad > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > > Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. > > http://feuerlabs.com > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > . > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bengt.kleberg@REDACTED Thu Feb 6 08:25:43 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 6 Feb 2014 08:25:43 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> Message-ID: <1391671543.4877.9.camel@sekic1152.release> Greetings, These are opinions, not facts. I think that formatting code as it goes into the repository is a good thing. What are the arguments against it? bengt On Wed, 2014-02-05 at 15:45 -0600, kraythe . wrote: > I have long favored the enforcement of coding style at the repository > level. Then it doesnt matter if someone accidentally reformats their > local copy, the checkin will reformat it accordingly. I dont think > people will ever agree on the "right" format in something that is > inherently a matter of taste. I like tight code with only 2 char > indents and as much on the screen at once. Another guy I know loves > drop braces with a brace on the next line (for java, C, etc). Neither > of us is wrong. If the repo checkin had a reformatter, it wouldn't > matter. > > Robert Simmons Jr. MSc. - Lead Java Architect @ EA > Author of: Hardcore Java (2003) and Maintainable Java (2012) > LinkedIn: http://www.linkedin.com/pub/robert-simmons/40/852/a39 > > > On Wed, Feb 5, 2014 at 3:36 PM, Vlad Dumitrescu > wrote: > > If the debate uncovers some workarounds that make the pain > less > > painful (pun intended), then even better. > > > I just found out that we could do something like this to > reindent files: > > emacs -batch sample.erl --eval '(indent-region (point-min) > (point-max) > nil)' -f save-buffer > > /Vlad > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bengt.kleberg@REDACTED Thu Feb 6 08:30:54 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 6 Feb 2014 08:30:54 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <52F2AAB5.8000003@ninenines.eu> References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> Message-ID: <1391671854.4877.14.camel@sekic1152.release> Greetings, These are opinions, not facts. It is correct that the project owner has decides what goes into the project. Why would it be a bad idea for this owner to automatically format every thing that is checked in? On the plus side (s)he would be able to accept more code this way and appear nicer to would be contributers. bengt On Wed, 2014-02-05 at 22:18 +0100, Lo?c Hoguin wrote: > On 02/05/2014 09:48 PM, Raoul Duke wrote: > >> One line? That's the worst solution ever. You break every tool ever, and > >> even make *cat* and *less* useless (pun intended). > >> Code is text, so keep it readable without requiring any special crappy > >> editor. > > > > yes and no. these are the problems and solutions we have to trade off. > > what is the lesser evil in the long run? probably people disagree. > > ??? > > There is no evil, this is at most a minor annoyance that comes with > pointless debates shrouded by blind religious beliefs. > > The answer is always "submit code the way the project owner wants you > to" and no amount of debating is going to change that, ever. > > It's not even just tabs vs spaces, plenty other minor things are the > author's choice, including number of columns, newline characters, source > code encoding, but also major things like mandatory documentation or > tests and backward compatibility. > > There is no one true way of doing things, for this or for anything else. > It's just a matter of choice. > From bengt.kleberg@REDACTED Thu Feb 6 08:36:15 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 6 Feb 2014 08:36:15 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> Message-ID: <1391672175.4877.19.camel@sekic1152.release> Greetings, These are opinions, not facts. Go is a cool language in many places. This is one place. The use of one tab for one level of indention is logical. The indention level is 1, so why have another amount of characters? The only reason I have heard for X =/= 1 is that 1 space is too narrow. So, use 1 tab. All editors that I use can make 1 tab take up whatever width I like for indentation. bengt On Wed, 2014-02-05 at 14:46 -0600, Mark Allen wrote: > The golang "go fmt" command parses the programmatic AST and returns human > readable text formatted to a configurable style sheet. They also have "go > fix" which parses the AST and dynamically replaces opcodes/sequences with > upgraded opcodes/sequences when moving from version 1.X.X -> 1.X.Y > > It's kind of cool, but the pre-defined golang style is tabs only for > indentation (no spaces) which drives me insane, but at least its > consistent. > > Mark > > On 2/5/14 2:28 PM, "Garrett Smith" wrote: > > >On Wed, Feb 5, 2014 at 2:21 PM, kraythe . wrote: > >> Actually the solution to this age old debate was proposed to me by a > >>friend > >> of mine and its genius on a number of levels but isn't implemented > >>anywhere. > >> The reality is that for most languages whitespace is irrelevant so it > >> shouldn't be the code holding the indentation but the user's preference > >> file. Imagine a source code repository where there is NO irrelevant > >> whitespace in the code base. For java, for example, there would be > >>literally > >> only one single line of code. Now when you check out you have a > >>preference > >> file that says you want tabs or spaces or mixed and also defines the > >>other > >> formatting you prefer. When you check out the system reformats the code > >> according to your specs dynamically. When you commit, it strips your > >>code of > >> whitespace before comparing. > >> > >> Now that would rock. Not just for tabs but the other code holy wars like > >> drop braces and so onl > > > >Heh, not bad. I wonder how something like this might evolve. > > > >Garrett > >_______________________________________________ > >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 valentin@REDACTED Thu Feb 6 08:49:36 2014 From: valentin@REDACTED (Valentin Micic) Date: Thu, 6 Feb 2014 09:49:36 +0200 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <1391671854.4877.14.camel@sekic1152.release> References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> <1391671854.4877.14.camel@sekic1152.release> Message-ID: Dear Bengt, I'd like to ask you a question? when you say: "These are opinions, not facts." Do you mean it in a way that "what follows are my opinions and not facts"? Or do you mean that views expressed by an email that you're quoting are (in your opinion) opinions and not facts? Or both? And, if you do not mind indulging me for a moment -- why do you think it is necessary to put forward such a preamble? Kind reagards V/ On 06 Feb 2014, at 9:30 AM, Bengt Kleberg wrote: > Greetings, > > These are opinions, not facts. > > It is correct that the project owner has decides what goes into the > project. Why would it be a bad idea for this owner to automatically > format every thing that is checked in? > > On the plus side (s)he would be able to accept more code this way and > appear nicer to would be contributers. > > > bengt > > On Wed, 2014-02-05 at 22:18 +0100, Lo?c Hoguin wrote: >> On 02/05/2014 09:48 PM, Raoul Duke wrote: >>>> One line? That's the worst solution ever. You break every tool ever, and >>>> even make *cat* and *less* useless (pun intended). >>>> Code is text, so keep it readable without requiring any special crappy >>>> editor. >>> >>> yes and no. these are the problems and solutions we have to trade off. >>> what is the lesser evil in the long run? probably people disagree. >> >> ??? >> >> There is no evil, this is at most a minor annoyance that comes with >> pointless debates shrouded by blind religious beliefs. >> >> The answer is always "submit code the way the project owner wants you >> to" and no amount of debating is going to change that, ever. >> >> It's not even just tabs vs spaces, plenty other minor things are the >> author's choice, including number of columns, newline characters, source >> code encoding, but also major things like mandatory documentation or >> tests and backward compatibility. >> >> There is no one true way of doing things, for this or for anything else. >> It's just a matter of choice. >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From mjtruog@REDACTED Thu Feb 6 09:23:47 2014 From: mjtruog@REDACTED (Michael Truog) Date: Thu, 06 Feb 2014 00:23:47 -0800 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <1391671269.4877.5.camel@sekic1152.release> References: <25B05620-DEDB-47F4-AF46-5C3E573DCA7C@feuerlabs.com> <52F2B139.8000802@gmail.com> <1391671269.4877.5.camel@sekic1152.release> Message-ID: <52F34693.1000501@gmail.com> On 02/05/2014 11:21 PM, Bengt Kleberg wrote: > Greetings, > > These are opinions, not facts. > > How do we know that tab stops where never standard? We know by reading about tab stops: http://en.wikipedia.org/wiki/Tab_stop "Tab stops are set manually, ..." > > > bengt > > On Wed, 2014-02-05 at 13:46 -0800, Michael Truog wrote: >> On 02/05/2014 10:40 AM, Ulf Wiger wrote: >>> One thing for emacs users (or those who need to deal with them) to do is to insert the following at the top of each erlang module: >>> >>> %% -*- erlang-indent-level: 4; indent-tabs-mode: nil -*- >>> >>> (Perhaps others have suggestions for the ultimate settings here) >> The ULTIMATE modeline settings should be: >> %-*-Mode:erlang;coding:utf-8;tab-width:4;c-basic-offset:4;indent-tabs-mode:()-*- >> % ex: set ft=erlang fenc=utf-8 sts=4 ts=4 sw=4 et: >> >> latin1 would need to be used for the older Erlang source code that requires it (probably all of OTP) which unfortunately makes the emacs modeline more than 80 characters. Having both an emacs and a vi modeline can keep both sets of users happy. >> >> It is typical to avoid tabs and prefer spaces, so it would be nice to have that be standard, since the OTP code is becoming unreadable due to characters that don't matter (due to not making a decision, you are still deciding to allow both tabs and spaces). Tab stops were never standard and only really relate to typewriters historically (who uses those for Erlang?). >> >>> >>> >>> BR, >>> Ulf W >>> >>> On 5 Feb 2014, at 19:14, Vlad Dumitrescu wrote: >>> >>>> Hi all, >>>> >>>> It's been almost a full day since the last controversial issue was >>>> discussed here and I feel it's time for a new one (well, it's actually >>>> old). >>>> >>>> The default indentation used by the erlang-mode uses a mix of tabs and >>>> spaces. Whatever side one is in the "tabs vs spaces" war, mixing them >>>> is the common enemy! >>>> >>>> Not everybody uses emacs, nor should they be forced to. This means >>>> that creating a patch might take less time than adjusting the >>>> whitespace afterwards, which feels a horrible waste of time and >>>> energy. >>>> >>>> Of course, we the non-emacs-using hackers of the OTP code might be in >>>> a crushing minority, and then the issue will get closed quickly. I >>>> feel however that I need to try to change this. I have abstained >>>> before from submitting small fixes just because of this (instead I >>>> sold the idea to someone else, but that doesn't always work). >>>> >>>> So my question is: are enough people bothered by this issue? If yes, >>>> can we try to agree on a solution? Such changes are best done in >>>> connection with a release. >>>> >>>> best regards, >>>> Vlad >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. >>> http://feuerlabs.com >>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> . >>> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From bengt.kleberg@REDACTED Thu Feb 6 09:33:04 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 6 Feb 2014 09:33:04 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <52F34693.1000501@gmail.com> References: <25B05620-DEDB-47F4-AF46-5C3E573DCA7C@feuerlabs.com> <52F2B139.8000802@gmail.com> <1391671269.4877.5.camel@sekic1152.release> <52F34693.1000501@gmail.com> Message-ID: <1391675584.4877.34.camel@sekic1152.release> Greetings, These are my opinions, not facts. So you mean that tabstops on a typewriter where never standard because they where set manually. OK, fair enough. How is that pertinent to indenting computer source code? bengt On Thu, 2014-02-06 at 00:23 -0800, Michael Truog wrote: > On 02/05/2014 11:21 PM, Bengt Kleberg wrote: > > Greetings, > > > > These are opinions, not facts. > > > > How do we know that tab stops where never standard? > We know by reading about tab stops: > http://en.wikipedia.org/wiki/Tab_stop > "Tab stops are set manually, ..." > > > > > > > bengt > > > > On Wed, 2014-02-05 at 13:46 -0800, Michael Truog wrote: > >> On 02/05/2014 10:40 AM, Ulf Wiger wrote: > >>> One thing for emacs users (or those who need to deal with them) to do is to insert the following at the top of each erlang module: > >>> > >>> %% -*- erlang-indent-level: 4; indent-tabs-mode: nil -*- > >>> > >>> (Perhaps others have suggestions for the ultimate settings here) > >> The ULTIMATE modeline settings should be: > >> %-*-Mode:erlang;coding:utf-8;tab-width:4;c-basic-offset:4;indent-tabs-mode:()-*- > >> % ex: set ft=erlang fenc=utf-8 sts=4 ts=4 sw=4 et: > >> > >> latin1 would need to be used for the older Erlang source code that requires it (probably all of OTP) which unfortunately makes the emacs modeline more than 80 characters. Having both an emacs and a vi modeline can keep both sets of users happy. > >> > >> It is typical to avoid tabs and prefer spaces, so it would be nice to have that be standard, since the OTP code is becoming unreadable due to characters that don't matter (due to not making a decision, you are still deciding to allow both tabs and spaces). Tab stops were never standard and only really relate to typewriters historically (who uses those for Erlang?). > >> > >>> > >>> > >>> BR, > >>> Ulf W > >>> > >>> On 5 Feb 2014, at 19:14, Vlad Dumitrescu wrote: > >>> > >>>> Hi all, > >>>> > >>>> It's been almost a full day since the last controversial issue was > >>>> discussed here and I feel it's time for a new one (well, it's actually > >>>> old). > >>>> > >>>> The default indentation used by the erlang-mode uses a mix of tabs and > >>>> spaces. Whatever side one is in the "tabs vs spaces" war, mixing them > >>>> is the common enemy! > >>>> > >>>> Not everybody uses emacs, nor should they be forced to. This means > >>>> that creating a patch might take less time than adjusting the > >>>> whitespace afterwards, which feels a horrible waste of time and > >>>> energy. > >>>> > >>>> Of course, we the non-emacs-using hackers of the OTP code might be in > >>>> a crushing minority, and then the issue will get closed quickly. I > >>>> feel however that I need to try to change this. I have abstained > >>>> before from submitting small fixes just because of this (instead I > >>>> sold the idea to someone else, but that doesn't always work). > >>>> > >>>> So my question is: are enough people bothered by this issue? If yes, > >>>> can we try to agree on a solution? Such changes are best done in > >>>> connection with a release. > >>>> > >>>> best regards, > >>>> Vlad > >>>> _______________________________________________ > >>>> erlang-questions mailing list > >>>> erlang-questions@REDACTED > >>>> http://erlang.org/mailman/listinfo/erlang-questions > >>> Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. > >>> http://feuerlabs.com > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 essen@REDACTED Thu Feb 6 09:38:10 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 06 Feb 2014 09:38:10 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <1391671854.4877.14.camel@sekic1152.release> References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> <1391671854.4877.14.camel@sekic1152.release> Message-ID: <52F349F2.2060800@ninenines.eu> You can't reasonably do it when merging. You would have to amend each commit individually with the whitespace fixes. Then you would have to test again, because your whitespace program may have broken your own program. Plus this doesn't help your code get merged at all. If you submit code with broken whitespace, then tools will also display this whitespace change. You can of course hide whitespace changes, but the problem is that whitespace does matter in some places, so you're basically hiding potentially important information by doing that. I also highly doubt that "the owner would be able to accept more code". Like I said before, this is a minor annoyance at best. He wouldn't appear nicer either, because he has to spend extra time on each PR, meaning they get merged slower, which is a bigger annoyance than telling people to fix the whitespace they broke. The contributor can quickly see if they broke whitespace after submitting the PR on github by looking at the diff tab. I'm always surprised when people submit a PR with obviously broken whitespace and do nothing about it until I point it out. Contributors aren't the ones who are going to maintain the code. They just write and forget. Therefore they should be the ones who make sure that what they submit is well-formed so as to not become an inconvenience to the project owner, who is going to maintain their code for them for free. On 02/06/2014 08:30 AM, Bengt Kleberg wrote: > Greetings, > > These are opinions, not facts. > > It is correct that the project owner has decides what goes into the > project. Why would it be a bad idea for this owner to automatically > format every thing that is checked in? > > On the plus side (s)he would be able to accept more code this way and > appear nicer to would be contributers. > > > bengt > > On Wed, 2014-02-05 at 22:18 +0100, Lo?c Hoguin wrote: >> On 02/05/2014 09:48 PM, Raoul Duke wrote: >>>> One line? That's the worst solution ever. You break every tool ever, and >>>> even make *cat* and *less* useless (pun intended). >>>> Code is text, so keep it readable without requiring any special crappy >>>> editor. >>> >>> yes and no. these are the problems and solutions we have to trade off. >>> what is the lesser evil in the long run? probably people disagree. >> >> ??? >> >> There is no evil, this is at most a minor annoyance that comes with >> pointless debates shrouded by blind religious beliefs. >> >> The answer is always "submit code the way the project owner wants you >> to" and no amount of debating is going to change that, ever. >> >> It's not even just tabs vs spaces, plenty other minor things are the >> author's choice, including number of columns, newline characters, source >> code encoding, but also major things like mandatory documentation or >> tests and backward compatibility. >> >> There is no one true way of doing things, for this or for anything else. >> It's just a matter of choice. >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From bengt.kleberg@REDACTED Thu Feb 6 09:12:51 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 6 Feb 2014 09:12:51 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> <1391671854.4877.14.camel@sekic1152.release> Message-ID: <1391674371.4877.31.camel@sekic1152.release> Greetings, These are my opinions, not facts. Thank you for the feedback. Hopefully the new version makes things clearer. If not, please do not hesitate to help me make it better. The opinions statement that I start my email with has become necessary since some people on erlang-questions explained in a belligerent way that they had previously never seen opinions expressed as something that might be mistaken for facts. They surely where from a part of the Internet that I have never seen, but it takes only a little sentence to make them happy. bengt On Thu, 2014-02-06 at 09:49 +0200, Valentin Micic wrote: > Dear Bengt, > > I'd like to ask you a question? when you say: > > "These are opinions, not facts." > > Do you mean it in a way that "what follows are my opinions and not facts"? > Or do you mean that views expressed by an email that you're quoting are (in your opinion) opinions and not facts? > Or both? > > And, if you do not mind indulging me for a moment -- why do you think it is necessary to put forward such a preamble? > > Kind reagards > > V/ > > > On 06 Feb 2014, at 9:30 AM, Bengt Kleberg wrote: > > > Greetings, > > > > These are opinions, not facts. > > > > It is correct that the project owner has decides what goes into the > > project. Why would it be a bad idea for this owner to automatically > > format every thing that is checked in? > > > > On the plus side (s)he would be able to accept more code this way and > > appear nicer to would be contributers. > > > > > > bengt > > > > On Wed, 2014-02-05 at 22:18 +0100, Lo?c Hoguin wrote: > >> On 02/05/2014 09:48 PM, Raoul Duke wrote: > >>>> One line? That's the worst solution ever. You break every tool ever, and > >>>> even make *cat* and *less* useless (pun intended). > >>>> Code is text, so keep it readable without requiring any special crappy > >>>> editor. > >>> > >>> yes and no. these are the problems and solutions we have to trade off. > >>> what is the lesser evil in the long run? probably people disagree. > >> > >> ??? > >> > >> There is no evil, this is at most a minor annoyance that comes with > >> pointless debates shrouded by blind religious beliefs. > >> > >> The answer is always "submit code the way the project owner wants you > >> to" and no amount of debating is going to change that, ever. > >> > >> It's not even just tabs vs spaces, plenty other minor things are the > >> author's choice, including number of columns, newline characters, source > >> code encoding, but also major things like mandatory documentation or > >> tests and backward compatibility. > >> > >> There is no one true way of doing things, for this or for anything else. > >> It's just a matter of choice. > >> > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > From bengt.kleberg@REDACTED Thu Feb 6 09:50:56 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 6 Feb 2014 09:50:56 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <52F349F2.2060800@ninenines.eu> References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> <1391671854.4877.14.camel@sekic1152.release> <52F349F2.2060800@ninenines.eu> Message-ID: <1391676657.4877.38.camel@sekic1152.release> Greetings, These are my opinions, not fact. It is unfortunate that formatting before check in it is not a viable way. To be honest I do not follow your reasons, but I accept them. I thought that since it is used in Go it would be possible for other languages as well. bengt On Thu, 2014-02-06 at 09:38 +0100, Lo?c Hoguin wrote: > You can't reasonably do it when merging. You would have to amend each > commit individually with the whitespace fixes. Then you would have to > test again, because your whitespace program may have broken your own > program. > > Plus this doesn't help your code get merged at all. If you submit code > with broken whitespace, then tools will also display this whitespace > change. You can of course hide whitespace changes, but the problem is > that whitespace does matter in some places, so you're basically hiding > potentially important information by doing that. > > I also highly doubt that "the owner would be able to accept more code". > Like I said before, this is a minor annoyance at best. > > He wouldn't appear nicer either, because he has to spend extra time on > each PR, meaning they get merged slower, which is a bigger annoyance > than telling people to fix the whitespace they broke. > > The contributor can quickly see if they broke whitespace after > submitting the PR on github by looking at the diff tab. I'm always > surprised when people submit a PR with obviously broken whitespace and > do nothing about it until I point it out. > > Contributors aren't the ones who are going to maintain the code. They > just write and forget. Therefore they should be the ones who make sure > that what they submit is well-formed so as to not become an > inconvenience to the project owner, who is going to maintain their code > for them for free. > > On 02/06/2014 08:30 AM, Bengt Kleberg wrote: > > Greetings, > > > > These are opinions, not facts. > > > > It is correct that the project owner has decides what goes into the > > project. Why would it be a bad idea for this owner to automatically > > format every thing that is checked in? > > > > On the plus side (s)he would be able to accept more code this way and > > appear nicer to would be contributers. > > > > > > bengt > > > > On Wed, 2014-02-05 at 22:18 +0100, Lo?c Hoguin wrote: > >> On 02/05/2014 09:48 PM, Raoul Duke wrote: > >>>> One line? That's the worst solution ever. You break every tool ever, and > >>>> even make *cat* and *less* useless (pun intended). > >>>> Code is text, so keep it readable without requiring any special crappy > >>>> editor. > >>> > >>> yes and no. these are the problems and solutions we have to trade off. > >>> what is the lesser evil in the long run? probably people disagree. > >> > >> ??? > >> > >> There is no evil, this is at most a minor annoyance that comes with > >> pointless debates shrouded by blind religious beliefs. > >> > >> The answer is always "submit code the way the project owner wants you > >> to" and no amount of debating is going to change that, ever. > >> > >> It's not even just tabs vs spaces, plenty other minor things are the > >> author's choice, including number of columns, newline characters, source > >> code encoding, but also major things like mandatory documentation or > >> tests and backward compatibility. > >> > >> There is no one true way of doing things, for this or for anything else. > >> It's just a matter of choice. > >> > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > From ali.sabil@REDACTED Thu Feb 6 10:10:18 2014 From: ali.sabil@REDACTED (Ali Sabil) Date: Thu, 6 Feb 2014 10:10:18 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <1391676657.4877.38.camel@sekic1152.release> References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> <1391671854.4877.14.camel@sekic1152.release> <52F349F2.2060800@ninenines.eu> <1391676657.4877.38.camel@sekic1152.release> Message-ID: A first step would be to have something like gofmt for Erlang. On Thu, Feb 6, 2014 at 9:50 AM, Bengt Kleberg wrote: > Greetings, > > These are my opinions, not fact. > > It is unfortunate that formatting before check in it is not a viable > way. To be honest I do not follow your reasons, but I accept them. > I thought that since it is used in Go it would be possible for other > languages as well. > > > bengt > > On Thu, 2014-02-06 at 09:38 +0100, Lo?c Hoguin wrote: > > You can't reasonably do it when merging. You would have to amend each > > commit individually with the whitespace fixes. Then you would have to > > test again, because your whitespace program may have broken your own > > program. > > > > Plus this doesn't help your code get merged at all. If you submit code > > with broken whitespace, then tools will also display this whitespace > > change. You can of course hide whitespace changes, but the problem is > > that whitespace does matter in some places, so you're basically hiding > > potentially important information by doing that. > > > > I also highly doubt that "the owner would be able to accept more code". > > Like I said before, this is a minor annoyance at best. > > > > He wouldn't appear nicer either, because he has to spend extra time on > > each PR, meaning they get merged slower, which is a bigger annoyance > > than telling people to fix the whitespace they broke. > > > > The contributor can quickly see if they broke whitespace after > > submitting the PR on github by looking at the diff tab. I'm always > > surprised when people submit a PR with obviously broken whitespace and > > do nothing about it until I point it out. > > > > Contributors aren't the ones who are going to maintain the code. They > > just write and forget. Therefore they should be the ones who make sure > > that what they submit is well-formed so as to not become an > > inconvenience to the project owner, who is going to maintain their code > > for them for free. > > > > On 02/06/2014 08:30 AM, Bengt Kleberg wrote: > > > Greetings, > > > > > > These are opinions, not facts. > > > > > > It is correct that the project owner has decides what goes into the > > > project. Why would it be a bad idea for this owner to automatically > > > format every thing that is checked in? > > > > > > On the plus side (s)he would be able to accept more code this way and > > > appear nicer to would be contributers. > > > > > > > > > bengt > > > > > > On Wed, 2014-02-05 at 22:18 +0100, Lo?c Hoguin wrote: > > >> On 02/05/2014 09:48 PM, Raoul Duke wrote: > > >>>> One line? That's the worst solution ever. You break every tool > ever, and > > >>>> even make *cat* and *less* useless (pun intended). > > >>>> Code is text, so keep it readable without requiring any special > crappy > > >>>> editor. > > >>> > > >>> yes and no. these are the problems and solutions we have to trade > off. > > >>> what is the lesser evil in the long run? probably people disagree. > > >> > > >> ??? > > >> > > >> There is no evil, this is at most a minor annoyance that comes with > > >> pointless debates shrouded by blind religious beliefs. > > >> > > >> The answer is always "submit code the way the project owner wants you > > >> to" and no amount of debating is going to change that, ever. > > >> > > >> It's not even just tabs vs spaces, plenty other minor things are the > > >> author's choice, including number of columns, newline characters, > source > > >> code encoding, but also major things like mandatory documentation or > > >> tests and backward compatibility. > > >> > > >> There is no one true way of doing things, for this or for anything > else. > > >> It's just a matter of choice. > > >> > > > > > > _______________________________________________ > > > 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 vladdu55@REDACTED Thu Feb 6 10:12:30 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 6 Feb 2014 10:12:30 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <52F349F2.2060800@ninenines.eu> References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> <1391671854.4877.14.camel@sekic1152.release> <52F349F2.2060800@ninenines.eu> Message-ID: On Thu, Feb 6, 2014 at 9:38 AM, Lo?c Hoguin wrote: > The contributor can quickly see if they broke whitespace after submitting > the PR on github by looking at the diff tab. I'm always surprised when > people submit a PR with obviously broken whitespace and do nothing about it > until I point it out. As an interesting anecdote, yesterday I managed somehow to produce a patch that looked good on github, but not in emacs... So unfortunately it seems that checking GH might not be enough (at least not when not using emacs in the first place). regards, Vlad From bengt.kleberg@REDACTED Thu Feb 6 10:21:25 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 6 Feb 2014 10:21:25 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> <1391671854.4877.14.camel@sekic1152.release> <52F349F2.2060800@ninenines.eu> <1391676657.4877.38.camel@sekic1152.release> Message-ID: <1391678485.4877.42.camel@sekic1152.release> Greetings, These are my opinions, not facts. We have erl_tidy:file/2 that ought to be a good starting point to mimic gofmt. bengt On Thu, 2014-02-06 at 10:10 +0100, Ali Sabil wrote: > A first step would be to have something like gofmt for Erlang. > > > On Thu, Feb 6, 2014 at 9:50 AM, Bengt Kleberg > wrote: > Greetings, > > These are my opinions, not fact. > > It is unfortunate that formatting before check in it is not a > viable > way. To be honest I do not follow your reasons, but I accept > them. > I thought that since it is used in Go it would be possible for > other > languages as well. > > > bengt > > On Thu, 2014-02-06 at 09:38 +0100, Lo?c Hoguin wrote: > > You can't reasonably do it when merging. You would have to > amend each > > commit individually with the whitespace fixes. Then you > would have to > > test again, because your whitespace program may have broken > your own > > program. > > > > Plus this doesn't help your code get merged at all. If you > submit code > > with broken whitespace, then tools will also display this > whitespace > > change. You can of course hide whitespace changes, but the > problem is > > that whitespace does matter in some places, so you're > basically hiding > > potentially important information by doing that. > > > > I also highly doubt that "the owner would be able to accept > more code". > > Like I said before, this is a minor annoyance at best. > > > > He wouldn't appear nicer either, because he has to spend > extra time on > > each PR, meaning they get merged slower, which is a bigger > annoyance > > than telling people to fix the whitespace they broke. > > > > The contributor can quickly see if they broke whitespace > after > > submitting the PR on github by looking at the diff tab. I'm > always > > surprised when people submit a PR with obviously broken > whitespace and > > do nothing about it until I point it out. > > > > Contributors aren't the ones who are going to maintain the > code. They > > just write and forget. Therefore they should be the ones who > make sure > > that what they submit is well-formed so as to not become an > > inconvenience to the project owner, who is going to maintain > their code > > for them for free. > > > > On 02/06/2014 08:30 AM, Bengt Kleberg wrote: > > > Greetings, > > > > > > These are opinions, not facts. > > > > > > It is correct that the project owner has decides what goes > into the > > > project. Why would it be a bad idea for this owner to > automatically > > > format every thing that is checked in? > > > > > > On the plus side (s)he would be able to accept more code > this way and > > > appear nicer to would be contributers. > > > > > > > > > bengt > > > > > > On Wed, 2014-02-05 at 22:18 +0100, Lo?c Hoguin wrote: > > >> On 02/05/2014 09:48 PM, Raoul Duke wrote: > > >>>> One line? That's the worst solution ever. You break > every tool ever, and > > >>>> even make *cat* and *less* useless (pun intended). > > >>>> Code is text, so keep it readable without requiring any > special crappy > > >>>> editor. > > >>> > > >>> yes and no. these are the problems and solutions we have > to trade off. > > >>> what is the lesser evil in the long run? probably people > disagree. > > >> > > >> ??? > > >> > > >> There is no evil, this is at most a minor annoyance that > comes with > > >> pointless debates shrouded by blind religious beliefs. > > >> > > >> The answer is always "submit code the way the project > owner wants you > > >> to" and no amount of debating is going to change that, > ever. > > >> > > >> It's not even just tabs vs spaces, plenty other minor > things are the > > >> author's choice, including number of columns, newline > characters, source > > >> code encoding, but also major things like mandatory > documentation or > > >> tests and backward compatibility. > > >> > > >> There is no one true way of doing things, for this or for > anything else. > > >> It's just a matter of choice. > > >> > > > > > > _______________________________________________ > > > 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 lukas@REDACTED Thu Feb 6 10:31:01 2014 From: lukas@REDACTED (Lukas Larsson) Date: Thu, 6 Feb 2014 10:31:01 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <52F349F2.2060800@ninenines.eu> References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> <1391671854.4877.14.camel@sekic1152.release> <52F349F2.2060800@ninenines.eu> Message-ID: On Thu, Feb 6, 2014 at 9:38 AM, Lo?c Hoguin wrote: > > Plus this doesn't help your code get merged at all. If you submit code > with broken whitespace, then tools will also display this whitespace > change. You can of course hide whitespace changes, but the problem is that > whitespace does matter in some places, so you're basically hiding > potentially important information by doing that. > > This is in my opinion the reason why it would be a very bad thing to do a huge commit that changes the current whitespace format of a project to another. It is already very hard to figure out what change could have caused a bug without having to deal with whitespace changes in the middle of a diff. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Thu Feb 6 10:34:13 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Thu, 6 Feb 2014 10:34:13 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> <1391671854.4877.14.camel@sekic1152.release> <52F349F2.2060800@ninenines.eu> Message-ID: On Thu, Feb 6, 2014 at 10:31 AM, Lukas Larsson wrote: > On Thu, Feb 6, 2014 at 9:38 AM, Lo?c Hoguin wrote: > >> >> Plus this doesn't help your code get merged at all. If you submit code >> with broken whitespace, then tools will also display this whitespace >> change. You can of course hide whitespace changes, but the problem is that >> whitespace does matter in some places, so you're basically hiding >> potentially important information by doing that. >> >> This is in my opinion the reason why it would be a very bad thing to do a > huge commit that changes the current whitespace format of a project to > another. It is already very hard to figure out what change could have > caused a bug without having to deal with whitespace changes in the middle > of a diff. > well then commit a whitespace change diff, then the change you really wanted to make. It of course requires to have a standard defined at first :) - benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Thu Feb 6 10:38:17 2014 From: lukas@REDACTED (Lukas Larsson) Date: Thu, 6 Feb 2014 10:38:17 +0100 Subject: [erlang-questions] crash while garbing - OTP-7132 In-Reply-To: References: Message-ID: The commit comment for this change is quite telling: https://github.com/erlang/otp/commit/b628ebe21a7b449eea27ada811dfbb007afe6d0b If you suspect that this could be the culprit maybe you could try to backport the patch? Also keep in mind that the =memory section lists it in bytes while =proc sections list heap in words. Lukas On Thu, Feb 6, 2014 at 6:35 AM, satoshi kinoshita wrote: > Does any one know some more detail information for OTP-7132? > > > --- http://www.erlang.org/doc/apps/erts/notes.html#id114389 ---- > The emulator could under rare circumstances crash while garbage collecting. > > Own Id: OTP-7132 > ---------------------------------------------------------------- > > We're still using R11B-5 and having a crash while doing GC on a process. > Though erl_crash.dump is reporting almost 2GB was used for "processes", > > top/vmstat is just reporting less than 1GB for beam.smp. > > It is also strange to me that sum of heap and OldHeap for all processes > are less than 100M, but processes_used is almost 1.6G. > > I don't know OTP-7132 is related. Any information will be appreciated. > > Thanks, > Kinoshita > > > -------------------------------------------------------------------- > % { grep +heap: erl_crash.dump |cut -d' ' -f2 |tr "\n" +; echo 0; }|bc > 46165303 > % { grep OldHeap: erl_crash.dump |cut -d' ' -f2 |tr "\n" +; echo 0; }|bc > 52591961 > > > --------------------------------------------------------------------------------- > =erl_crash_dump:0.1 > Thu Jan 30 17:42:24 2014 > Slogan: eheap_alloc: Cannot allocate 191315400 bytes of memory (of type "heap"). > > System version: Erlang (BEAM) emulator version 5.5.5 [source] [smp:8] [async-threads:64] [hipe] [kernel-poll:true] > Compiled: Mon Jan 21 18:01:53 2008 > Atoms: 9703 > =memory > total: 1843551840 > processes: 1640736600 > > processes_used: 1626764688 > system: 202815240 > atom: 433065 > atom_used: 428224 > binary: 159095424 > code: 4043588 > ets: 21895748 > =hash_table:atom_tab > size: 6421 > used: 5001 > objs: 9703 > depth: 8 > > ... > > =proc:<0.29953.0> > State: Garbing > Name: mgs_db_mgse > Spawned as: proc_lib:init_p/5 > Spawned by: <0.23670.0> > Started: Thu Sep 1 22:58:50 2011 > Message queue length: 0 > Number of heap fragments: 332 > > Heap fragment data: 34968 > Link list: [<0.23670.0>, {from,<0.28232.7497>,#Ref<0.0.29467.224716>}] > Reductions: 3060681751 > Stack+heap: 38263080 > OldHeap: 47828850 > Heap unused: 116 > OldHeap unused: 47828850 > > Program counter: 0xb5d7b7bc (mnesia_locker:receive_wlocks/4 + 64) > CP: 0xb5939d50 (mnesia_tm:execute_transaction/5 + 340) > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Thu Feb 6 10:39:55 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Thu, 6 Feb 2014 10:39:55 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> <1391671854.4877.14.camel@sekic1152.release> <52F349F2.2060800@ninenines.eu> Message-ID: On Thu, Feb 6, 2014 at 10:12 AM, Vlad Dumitrescu wrote: > On Thu, Feb 6, 2014 at 9:38 AM, Lo?c Hoguin wrote: > > The contributor can quickly see if they broke whitespace after submitting > > the PR on github by looking at the diff tab. I'm always surprised when > > people submit a PR with obviously broken whitespace and do nothing about > it > > until I point it out. > > As an interesting anecdote, yesterday I managed somehow to produce a > patch that looked good on github, but not in emacs... So unfortunately > it seems that checking GH might not be enough (at least not when not > using emacs in the first place). > > > There are also differences between a `git diff` and github display sometimes... For myself I am surprised by the number of project owner not describing the standard they are following but expecting that others are following it. Which create frustration on each parts. This why the gofmt tool or pep8 (even if I hate this one) are good. They allows a lot of people using the same language to follow the same guidelines. And provides tools to automatically fix them when needed. it removes a lot of frustration from each parts. - benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Thu Feb 6 10:40:24 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 6 Feb 2014 10:40:24 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> <1391671854.4877.14.camel@sekic1152.release> <52F349F2.2060800@ninenines.eu> Message-ID: <1391679624.4877.46.camel@sekic1152.release> Greetings, These are my opinions, not facts. So Erlang is sensitive to indention to the point of causing bugs. I did not know that. bengt On Thu, 2014-02-06 at 10:31 +0100, Lukas Larsson wrote: > On Thu, Feb 6, 2014 at 9:38 AM, Lo?c Hoguin > wrote: > > Plus this doesn't help your code get merged at all. If you > submit code with broken whitespace, then tools will also > display this whitespace change. You can of course hide > whitespace changes, but the problem is that whitespace does > matter in some places, so you're basically hiding potentially > important information by doing that. > > This is in my opinion the reason why it would be a very bad thing to > do a huge commit that changes the current whitespace format of a > project to another. It is already very hard to figure out what change > could have caused a bug without having to deal with whitespace changes > in the middle of a diff. From lukas@REDACTED Thu Feb 6 10:41:06 2014 From: lukas@REDACTED (Lukas Larsson) Date: Thu, 6 Feb 2014 10:41:06 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> <1391671854.4877.14.camel@sekic1152.release> <52F349F2.2060800@ninenines.eu> Message-ID: On Thu, Feb 6, 2014 at 10:34 AM, Benoit Chesneau wrote: > On Thu, Feb 6, 2014 at 10:31 AM, Lukas Larsson wrote: > >> On Thu, Feb 6, 2014 at 9:38 AM, Lo?c Hoguin wrote: >> >>> >>> Plus this doesn't help your code get merged at all. If you submit code >>> with broken whitespace, then tools will also display this whitespace >>> change. You can of course hide whitespace changes, but the problem is that >>> whitespace does matter in some places, so you're basically hiding >>> potentially important information by doing that. >>> >>> This is in my opinion the reason why it would be a very bad thing to do >> a huge commit that changes the current whitespace format of a project to >> another. It is already very hard to figure out what change could have >> caused a bug without having to deal with whitespace changes in the middle >> of a diff. >> > > well then commit a whitespace change diff, then the change you really > wanted to make. It of course requires to have a standard defined at first :) > > For single commits this would work, but will not work when I want to do "git diff OTP_R14B03..OTP_17.0-rc1" -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Thu Feb 6 10:43:27 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 6 Feb 2014 10:43:27 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> <1391671854.4877.14.camel@sekic1152.release> <52F349F2.2060800@ninenines.eu> Message-ID: On Thu, Feb 6, 2014 at 10:31 AM, Lukas Larsson wrote: > On Thu, Feb 6, 2014 at 9:38 AM, Lo?c Hoguin wrote: >> >> Plus this doesn't help your code get merged at all. If you submit code >> with broken whitespace, then tools will also display this whitespace change. >> You can of course hide whitespace changes, but the problem is that >> whitespace does matter in some places, so you're basically hiding >> potentially important information by doing that. >> > This is in my opinion the reason why it would be a very bad thing to do a > huge commit that changes the current whitespace format of a project to > another. It is already very hard to figure out what change could have caused > a bug without having to deal with whitespace changes in the middle of a > diff. Yes, if such a thing would be done, the best time is as a separate commit right before a release, this will minimize the number of merges/rebases with mixed styles of indentation. Of course, as Lukas points out, if diffing with older code, then you have a problem. Anyway, I have a suggestion for a workaround at https://gist.github.com/vladdu/8841089. Put those files in your ~/bin (which should be on $PATH), edit them to match your system and style and you can reindent files simply by running "erl-indent /path/to/myfile.erl". It still requires to have emacs installed, but I can live with that. The downside is that if you want to use only spaces, then the whole file will be changed to use them. The really big downside is that with this tool there will be even less incitament to change the indentation style... regards, Vlad From bchesneau@REDACTED Thu Feb 6 10:44:07 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Thu, 6 Feb 2014 10:44:07 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> <1391671854.4877.14.camel@sekic1152.release> <52F349F2.2060800@ninenines.eu> Message-ID: On Thu, Feb 6, 2014 at 10:41 AM, Lukas Larsson wrote: > On Thu, Feb 6, 2014 at 10:34 AM, Benoit Chesneau wrote: > >> On Thu, Feb 6, 2014 at 10:31 AM, Lukas Larsson wrote: >> >>> On Thu, Feb 6, 2014 at 9:38 AM, Lo?c Hoguin wrote: >>> >>>> >>>> Plus this doesn't help your code get merged at all. If you submit code >>>> with broken whitespace, then tools will also display this whitespace >>>> change. You can of course hide whitespace changes, but the problem is that >>>> whitespace does matter in some places, so you're basically hiding >>>> potentially important information by doing that. >>>> >>>> This is in my opinion the reason why it would be a very bad thing to do >>> a huge commit that changes the current whitespace format of a project to >>> another. It is already very hard to figure out what change could have >>> caused a bug without having to deal with whitespace changes in the middle >>> of a diff. >>> >> >> well then commit a whitespace change diff, then the change you really >> wanted to make. It of course requires to have a standard defined at first :) >> >> For single commits this would work, but will not work when I want to do > "git diff OTP_R14B03..OTP_17.0-rc1" > Ah sure, but I never heard of any good solution to fix the past in one pass. Imo slowly fixing step by step, changees by changes would be enough. At list the large diff expose the issue for those who care. - benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Thu Feb 6 10:45:24 2014 From: lukas@REDACTED (Lukas Larsson) Date: Thu, 6 Feb 2014 10:45:24 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <1391679624.4877.46.camel@sekic1152.release> References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> <1391671854.4877.14.camel@sekic1152.release> <52F349F2.2060800@ninenines.eu> <1391679624.4877.46.camel@sekic1152.release> Message-ID: On Thu, Feb 6, 2014 at 10:40 AM, Bengt Kleberg wrote: > Greetings, > > These are my opinions, not facts. > > So Erlang is sensitive to indention to the point of causing bugs. I did > not know that. > > It is not the indentation but changes to whitespace in strings that could cause issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron.l.france@REDACTED Thu Feb 6 10:45:54 2014 From: aaron.l.france@REDACTED (Aaron France) Date: Thu, 6 Feb 2014 10:45:54 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: Message-ID: <20140206094554.GA2115@xenocorp> UNSUBSCRIBE On Wed, Feb 05, 2014 at 07:14:30PM +0100, Vlad Dumitrescu wrote: > Hi all, > > It's been almost a full day since the last controversial issue was > discussed here and I feel it's time for a new one (well, it's actually > old). > > The default indentation used by the erlang-mode uses a mix of tabs and > spaces. Whatever side one is in the "tabs vs spaces" war, mixing them > is the common enemy! > > Not everybody uses emacs, nor should they be forced to. This means > that creating a patch might take less time than adjusting the > whitespace afterwards, which feels a horrible waste of time and > energy. > > Of course, we the non-emacs-using hackers of the OTP code might be in > a crushing minority, and then the issue will get closed quickly. I > feel however that I need to try to change this. I have abstained > before from submitting small fixes just because of this (instead I > sold the idea to someone else, but that doesn't always work). > > So my question is: are enough people bothered by this issue? If yes, > can we try to agree on a solution? Such changes are best done in > connection with a release. > > best regards, > Vlad > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From kenneth.lundin@REDACTED Thu Feb 6 11:31:55 2014 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Thu, 6 Feb 2014 11:31:55 +0100 Subject: [erlang-questions] Tracing traffic between nodes In-Reply-To: References: <1391439049.4825.34.camel@sekic1152.release> Message-ID: If you have a C-node built with Erl_interface you have an environment named DEBUG_LEVEL or something that will log messages to and from the Cnode. /Kenneth On Wed, Feb 5, 2014 at 3:51 PM, David Welton wrote: > This is surprisingly difficult. It seems that if there are two Erlang > nodes, my code would probably work. If there's a C node involved, it > seems that replacing message sends/receives in the C code with > something that does the proper logging is the best bet, as I don't > think the Erlang runtime environment is up to the task: it simply does > not know where messages come from. > > Wireshark has an Erlang distribution parser, which is pretty cool, but > because of cacheing of atoms, it's not something you can just start up > and have work, either, in terms of having a log of what was actually > sent where. > > -- > David N. Welton > > http://www.welton.it/davidw/ > > http://www.dedasys.com/ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean@REDACTED Thu Feb 6 11:35:01 2014 From: sean@REDACTED (Sean Cribbs) Date: Thu, 6 Feb 2014 11:35:01 +0100 Subject: [erlang-questions] async_accept Message-ID: Does anyone know offhand what is the meaning of integer returned in the {ok, _} return value of prim_inet:async_accept/2? It's not documented clearly. -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vances@REDACTED Thu Feb 6 11:46:20 2014 From: vances@REDACTED (Vance Shipley) Date: Thu, 6 Feb 2014 16:16:20 +0530 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> Message-ID: <20140206104620.GB5403@aluminium.local> On Wed, Feb 5, 2014 at 9:21 PM, kraythe . wrote: } Actually the solution to this age old debate was proposed to me by a friend } of mine and its genius on a number of levels but isn't implemented anywhere. } The reality is that for most languages whitespace is irrelevant so it } shouldn't be the code holding the indentation but the user's preference } file. Imagine a source code repository where there is NO irrelevant } whitespace in the code base. For java, for example, there would be literally } only one single line of code. Now when you check out you have a preference } file that says you want tabs or spaces or mixed and also defines the other } formatting you prefer. When you check out the system reformats the code } according to your specs dynamically. When you commit, it strips your code of } whitespace before comparing. I was inspired by my loathe of emacs indentation to consider how to solve the style problems completely. My solution goes a step further than what is proposed above. I would keep only the Abstract Syntax in the repository. The repository tools (git, svn, etc.) would be extended to run the appropriate tool (syntax_tools) on checkout/commit. Each user could have any presentation they wanted. If you like your ';' before the case clause you get that style 'cause that's what your tools are configured for. All style debates would be ended. On Wed, Feb 05, 2014 at 09:27:35PM +0100, Vlad Dumitrescu wrote: } Absolutely, this would fix it. But we don't have tools that can handle } that yet and I fear that implementing those and convincing people to } use them would take longer than agreeing on a saner alternative for } whitespace. When I first suggested this I was quickly reminded that all preprocessor information would be lost. There would be no macros and no comments. But didn't you solve that problem in Erlide Vlad? I remember looking and seeing where you were doing preservation of macros and comments when working with abstract syntax. -- -Vance http://erlang.org/pipermail/erlang-questions/2004-November/013620.html From bchesneau@REDACTED Thu Feb 6 11:51:50 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Thu, 6 Feb 2014 11:51:50 +0100 Subject: [erlang-questions] ANN: Ybot-0.3.5 chat bot released In-Reply-To: References: Message-ID: About Ybot do you plan at some point to introduce a compatibility layer with hubot? It would be cool if we could reuse the hubot scripts with ybot. Maybe that has already been done? - benoit On Wed, Aug 14, 2013 at 8:54 PM, Alex toyer wrote: > Hello, > > Today i released Ybot-0.3.5. Ybot it char bot written with erlang. > > Ybot supports now following transports: > > * IRC > > * XMPP > > * Campfire. > > * HTTP. > > * HipChat. > > * Flowdock. > > * Skype. > > * Talkerapp. > > And 2 write - only transports: > > * SMTP > > * Twitter > > ChangeLog: > > * Documentation for all transports. > > * Twitter now compatible with twitter api v.1.1 > > * Exception at the start of XMPP connection was fixed. > > * Web admin fully (frontend/backend) remade, all js libraries were > removed besides Angular.js > > Ybot at github - https://github.com/0xAX/Ybot > > Plugins for Ybot - https://github.com/0xAX/ybot-contrib > > -- > best regards, > > twitter: @0xAX > github: 0xAX > > _______________________________________________ > 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 Thu Feb 6 12:14:02 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 6 Feb 2014 12:14:02 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <20140206104620.GB5403@aluminium.local> References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <20140206104620.GB5403@aluminium.local> Message-ID: On Thu, Feb 6, 2014 at 11:46 AM, Vance Shipley wrote: > I was inspired by my loathe of emacs indentation to consider how to > solve the style problems completely. My solution goes a step further > than what is proposed above. I would keep only the Abstract Syntax > in the repository. The repository tools (git, svn, etc.) would be > extended to run the appropriate tool (syntax_tools) on checkout/commit. > Each user could have any presentation they wanted. If you like your > ';' before the case clause you get that style 'cause that's what your > tools are configured for. All style debates would be ended. This would be the ideal solution. However it requires that ALL tools know haw to handle this, including for example github or another cloud-based source code handling tool. Also, this assumes that all code that is checked in is parseable, which is not always the case. > On Wed, Feb 05, 2014 at 09:27:35PM +0100, Vlad Dumitrescu wrote: > } Absolutely, this would fix it. But we don't have tools that can handle > } that yet and I fear that implementing those and convincing people to > } use them would take longer than agreeing on a saner alternative for > } whitespace. > > When I first suggested this I was quickly reminded that all preprocessor > information would be lost. There would be no macros and no comments. > > But didn't you solve that problem in Erlide Vlad? I remember looking > and seeing where you were doing preservation of macros and comments > when working with abstract syntax. Yes, we have to use a scanner/parser that exactly mirrors the structure of the code as written, with comments and macros. The assumption is that the macros are well-behaved, which isn't always true. Not even the OTP code was free of such macros last time I checked (R15, I think), but at least now the ?line macros have been deprecated. If a scanner/parser is used only to mirror the structure of the code, then it's possible to implement it relatively easy. If the resulting tree has to match the structure of the code after macro expansion too, then it's not possible in the general case. The latter applies to erlide, where we need to feed the code structure to other tools, so we are only doing it in "best effort" style and there's still more work to do. regards, Vlad From bengt.kleberg@REDACTED Thu Feb 6 12:23:29 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 6 Feb 2014 12:23:29 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> <1391671854.4877.14.camel@sekic1152.release> <52F349F2.2060800@ninenines.eu> <1391679624.4877.46.camel@sekic1152.release> Message-ID: <1391685809.4877.50.camel@sekic1152.release> Greetings, These are my opinions, not facts. Thank you for the clarification. I agree, if a formatter started to format inside strings then it could introduce bugs. Any tool (say a compiler) that does that kind of changes would be dangerous. It would be a bug, but still a problem. bengt On Thu, 2014-02-06 at 10:45 +0100, Lukas Larsson wrote: > On Thu, Feb 6, 2014 at 10:40 AM, Bengt Kleberg > wrote: > Greetings, > > These are my opinions, not facts. > > > So Erlang is sensitive to indention to the point of causing > bugs. I did > not know that. > > > > It is not the indentation but changes to whitespace in strings that > could cause issues. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bengt.kleberg@REDACTED Thu Feb 6 12:27:43 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 6 Feb 2014 12:27:43 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> <1391671854.4877.14.camel@sekic1152.release> <52F349F2.2060800@ninenines.eu> Message-ID: <1391686064.4877.54.camel@sekic1152.release> Greetings, These are my opinions, not facts. Does your "erl-indent" program format according to the current OTP style guide? It would be very good if that was the case. bengt On Thu, 2014-02-06 at 10:43 +0100, Vlad Dumitrescu wrote: > On Thu, Feb 6, 2014 at 10:31 AM, Lukas Larsson wrote: > > On Thu, Feb 6, 2014 at 9:38 AM, Lo?c Hoguin wrote: > >> > >> Plus this doesn't help your code get merged at all. If you submit code > >> with broken whitespace, then tools will also display this whitespace change. > >> You can of course hide whitespace changes, but the problem is that > >> whitespace does matter in some places, so you're basically hiding > >> potentially important information by doing that. > >> > > This is in my opinion the reason why it would be a very bad thing to do a > > huge commit that changes the current whitespace format of a project to > > another. It is already very hard to figure out what change could have caused > > a bug without having to deal with whitespace changes in the middle of a > > diff. > > Yes, if such a thing would be done, the best time is as a separate > commit right before a release, this will minimize the number of > merges/rebases with mixed styles of indentation. Of course, as Lukas > points out, if diffing with older code, then you have a problem. > > Anyway, I have a suggestion for a workaround at > https://gist.github.com/vladdu/8841089. Put those files in your ~/bin > (which should be on $PATH), edit them to match your system and style > and you can reindent files simply by running "erl-indent > /path/to/myfile.erl". It still requires to have emacs installed, but I > can live with that. > > The downside is that if you want to use only spaces, then the whole > file will be changed to use them. The really big downside is that with > this tool there will be even less incitament to change the indentation > style... > > regards, > Vlad > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vladdu55@REDACTED Thu Feb 6 12:35:13 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 6 Feb 2014 12:35:13 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <1391686064.4877.54.camel@sekic1152.release> References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> <1391671854.4877.14.camel@sekic1152.release> <52F349F2.2060800@ninenines.eu> <1391686064.4877.54.camel@sekic1152.release> Message-ID: On 6 Feb 2014 12:27, "Bengt Kleberg" wrote: > > Greetings, > > These are my opinions, not facts. > > Does your "erl-indent" program format according to the current OTP style > guide? It would be very good if that was the case. It uses erlang - mode to indent. I certainly assume that it uses the style recommended by otp. Not all otp source files are idempotent under the indentation, so it might mean that not all are following the otp style. /vlad > > bengt > > On Thu, 2014-02-06 at 10:43 +0100, Vlad Dumitrescu wrote: > > On Thu, Feb 6, 2014 at 10:31 AM, Lukas Larsson wrote: > > > On Thu, Feb 6, 2014 at 9:38 AM, Lo?c Hoguin wrote: > > >> > > >> Plus this doesn't help your code get merged at all. If you submit code > > >> with broken whitespace, then tools will also display this whitespace change. > > >> You can of course hide whitespace changes, but the problem is that > > >> whitespace does matter in some places, so you're basically hiding > > >> potentially important information by doing that. > > >> > > > This is in my opinion the reason why it would be a very bad thing to do a > > > huge commit that changes the current whitespace format of a project to > > > another. It is already very hard to figure out what change could have caused > > > a bug without having to deal with whitespace changes in the middle of a > > > diff. > > > > Yes, if such a thing would be done, the best time is as a separate > > commit right before a release, this will minimize the number of > > merges/rebases with mixed styles of indentation. Of course, as Lukas > > points out, if diffing with older code, then you have a problem. > > > > Anyway, I have a suggestion for a workaround at > > https://gist.github.com/vladdu/8841089. Put those files in your ~/bin > > (which should be on $PATH), edit them to match your system and style > > and you can reindent files simply by running "erl-indent > > /path/to/myfile.erl". It still requires to have emacs installed, but I > > can live with that. > > > > The downside is that if you want to use only spaces, then the whole > > file will be changed to use them. The really big downside is that with > > this tool there will be even less incitament to change the indentation > > style... > > > > 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 andrzej.sliwa@REDACTED Thu Feb 6 13:22:11 2014 From: andrzej.sliwa@REDACTED (=?utf-8?Q?Andrzej_=C5=9Aliwa?=) Date: Thu, 6 Feb 2014 13:22:11 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> <1391671854.4877.14.camel@sekic1152.release> <52F349F2.2060800@ninenines.eu> <1391686064.4877.54.camel@sekic1152.release> Message-ID: Here is my script for re-indent:?https://github.com/andrzejsliwa/vimfiles/blob/master/emacs_indent.sh I used it before switch to Emacs. it also using emacs in batch mode, and trying guess correct path to emacs-mode (for linux and macosx) this script was base for reformat in intellij-erlang for emacs way formatting. Best Regards, Andrzej On 6 Feb 2014 at 12:35:28, Vlad Dumitrescu (vladdu55@REDACTED) wrote: On 6 Feb 2014 12:27, "Bengt Kleberg" wrote: > > Greetings, > > These are my opinions, not facts. > > Does your "erl-indent" program format according to the current OTP style > guide? It would be very good if that was the case. It uses erlang - mode to indent. I certainly assume that it uses the style recommended by otp. Not all otp source files are idempotent under the indentation, so it might mean that not all are following the otp style. /vlad > > bengt > > On Thu, 2014-02-06 at 10:43 +0100, Vlad Dumitrescu wrote: > > On Thu, Feb 6, 2014 at 10:31 AM, Lukas Larsson wrote: > > > On Thu, Feb 6, 2014 at 9:38 AM, Lo?c Hoguin wrote: > > >> > > >> Plus this doesn't help your code get merged at all. If you submit code > > >> with broken whitespace, then tools will also display this whitespace change. > > >> You can of course hide whitespace changes, but the problem is that > > >> whitespace does matter in some places, so you're basically hiding > > >> potentially important information by doing that. > > >> > > > This is in my opinion the reason why it would be a very bad thing to do a > > > huge commit that changes the current whitespace format of a project to > > > another. It is already very hard to figure out what change could have caused > > > a bug without having to deal with whitespace changes in the middle of a > > > diff. > > > > Yes, if such a thing would be done, the best time is as a separate > > commit right before a release, this will minimize the number of > > merges/rebases with mixed styles of indentation. Of course, as Lukas > > points out, if diffing with older code, then you have a problem. > > > > Anyway, I have a suggestion for a workaround at > > https://gist.github.com/vladdu/8841089. Put those files in your ~/bin > > (which should be on $PATH), edit them to match your system and style > > and you can reindent files simply by running "erl-indent > > /path/to/myfile.erl". It still requires to have emacs installed, but I > > can live with that. > > > > The downside is that if you want to use only spaces, then the whole > > file will be changed to use them. The really big downside is that with > > this tool there will be even less incitament to change the indentation > > style... > > > > 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 _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Thu Feb 6 13:28:29 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Thu, 6 Feb 2014 07:28:29 -0500 Subject: [erlang-questions] async_accept In-Reply-To: References: Message-ID: On Thu, Feb 6, 2014 at 5:35 AM, Sean Cribbs wrote: > Does anyone know offhand what is the meaning of integer returned in the > {ok, _} return value of prim_inet:async_accept/2? It's not documented > clearly. > It's essentially a reference, but it's generated from a counter internal to the inet driver so it's not an actual Erlang reference. It's the value of the 3rd element of the inet_async message you get when a connection arrives, allowing you to match those messages with the async_accept calls that caused them: For example: 1> prim_inet:async_accept(L,-1). {ok,3} 2> flush(). {inet_async,#Port<0.586>,3,{ok,#Port<0.587>}} The value 3 here is the reference. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Thu Feb 6 13:29:33 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 6 Feb 2014 13:29:33 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <1391671154.4877.3.camel@sekic1152.release> References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> Message-ID: <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> I hate tabs because tools without settings, and default settings of most historical tools, render tabs with 8 spaces. Thus this is the de facto standard. -- Anthony Ramine Le 6 f?vr. 2014 ? 08:19, Bengt Kleberg a ?crit : > The editors I use have a way to change the size of a tabstop. The word > processors I use have a way to change the size of each tabstop level. If > 8 was the correct number these possibilities would not be present. From bengt.kleberg@REDACTED Thu Feb 6 13:43:16 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 6 Feb 2014 13:43:16 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> Message-ID: <1391690596.4877.59.camel@sekic1152.release> Greetings, These are my opinions, not facts. It is strange that you hate tabs when it is the tools that are doing it wrong. Please try to not kill the messenger... bengt On Thu, 2014-02-06 at 13:29 +0100, Anthony Ramine wrote: > I hate tabs because tools without settings, and default settings of most historical tools, render tabs with 8 spaces. Thus this is the de facto standard. > From bchesneau@REDACTED Thu Feb 6 13:46:55 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Thu, 6 Feb 2014 13:46:55 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <1391690596.4877.59.camel@sekic1152.release> References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> Message-ID: On Thu, Feb 6, 2014 at 1:43 PM, Bengt Kleberg wrote: > Greetings, > > These are my opinions, not facts. > > It is strange that you hate tabs when it is the tools that are doing it > wrong. Please try to not kill the messenger... > > > starting to be horribly annoyed by your top post that force me to read the context and your header ""' Greetings, These are my opinions, not facts. """ please answer in the context or give the context in your top post... - benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Thu Feb 6 13:47:30 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 6 Feb 2014 13:47:30 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <1391690596.4877.59.camel@sekic1152.release> References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> Message-ID: <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> We can?t use tabs for indentation in Erlang because indentation in Erlang is not fixed. I?m now out of this debate because this constant ? These are my opinions, not facts. ? is driving me insane. -- Anthony Ramine Le 6 f?vr. 2014 ? 13:43, Bengt Kleberg a ?crit : > Greetings, > > These are my opinions, not facts. > > It is strange that you hate tabs when it is the tools that are doing it > wrong. Please try to not kill the messenger... > > > bengt > > On Thu, 2014-02-06 at 13:29 +0100, Anthony Ramine wrote: >> I hate tabs because tools without settings, and default settings of most historical tools, render tabs with 8 spaces. Thus this is the de facto standard. >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bengt.kleberg@REDACTED Thu Feb 6 13:48:19 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 6 Feb 2014 13:48:19 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <52F2A356.9040406@ninenines.eu> <52F2AAB5.8000003@ninenines.eu> <1391671854.4877.14.camel@sekic1152.release> <52F349F2.2060800@ninenines.eu> <1391686064.4877.54.camel@sekic1152.release> Message-ID: <1391690899.4877.64.camel@sekic1152.release> Greetings, These are my opinions, not facts. "erl-indent" can only be used on the OTP files that follow the style guide they recommend. Even if that is just a few it is better than the current cut-and-paste of tabs and spaces that I have to do in all files. Thank you for the tool. bengt On Thu, 2014-02-06 at 12:35 +0100, Vlad Dumitrescu wrote: > > On 6 Feb 2014 12:27, "Bengt Kleberg" > wrote: > > > > Greetings, > > > > These are my opinions, not facts. > > > > Does your "erl-indent" program format according to the current OTP > style > > guide? It would be very good if that was the case. > > It uses erlang - mode to indent. I certainly assume that it uses the > style recommended by otp. > > Not all otp source files are idempotent under the indentation, so it > might mean that not all are following the otp style. > > /vlad > > > > > bengt > > > > On Thu, 2014-02-06 at 10:43 +0100, Vlad Dumitrescu wrote: > > > On Thu, Feb 6, 2014 at 10:31 AM, Lukas Larsson > wrote: > > > > On Thu, Feb 6, 2014 at 9:38 AM, Lo?c Hoguin > wrote: > > > >> > > > >> Plus this doesn't help your code get merged at all. If you > submit code > > > >> with broken whitespace, then tools will also display this > whitespace change. > > > >> You can of course hide whitespace changes, but the problem is > that > > > >> whitespace does matter in some places, so you're basically > hiding > > > >> potentially important information by doing that. > > > >> > > > > This is in my opinion the reason why it would be a very bad > thing to do a > > > > huge commit that changes the current whitespace format of a > project to > > > > another. It is already very hard to figure out what change could > have caused > > > > a bug without having to deal with whitespace changes in the > middle of a > > > > diff. > > > > > > Yes, if such a thing would be done, the best time is as a separate > > > commit right before a release, this will minimize the number of > > > merges/rebases with mixed styles of indentation. Of course, as > Lukas > > > points out, if diffing with older code, then you have a problem. > > > > > > Anyway, I have a suggestion for a workaround at > > > https://gist.github.com/vladdu/8841089. Put those files in your > ~/bin > > > (which should be on $PATH), edit them to match your system and > style > > > and you can reindent files simply by running "erl-indent > > > /path/to/myfile.erl". It still requires to have emacs installed, > but I > > > can live with that. > > > > > > The downside is that if you want to use only spaces, then the > whole > > > file will be changed to use them. The really big downside is that > with > > > this tool there will be even less incitament to change the > indentation > > > style... > > > > > > regards, > > > Vlad > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > From essen@REDACTED Thu Feb 6 13:57:52 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 06 Feb 2014 13:57:52 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> Message-ID: <52F386D0.6080502@ninenines.eu> Don't try to squeeze a top/bottom posting holy war in the middle of a tabs vs space debate! On 02/06/2014 01:46 PM, Benoit Chesneau wrote: > > > > On Thu, Feb 6, 2014 at 1:43 PM, Bengt Kleberg > > wrote: > > Greetings, > > These are my opinions, not facts. > > It is strange that you hate tabs when it is the tools that are doing it > wrong. Please try to not kill the messenger... > > > > > starting to be horribly annoyed by your top post that force me to read > the context and your header > > ""' > Greetings, > > These are my opinions, not facts. > """ > > please answer in the context or give the context in your top post... > > - benoit > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From bengt.kleberg@REDACTED Thu Feb 6 14:49:37 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 6 Feb 2014 13:49:37 +0000 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release>, Message-ID: ________________________________ From: Benoit Chesneau [bchesneau@REDACTED] Sent: Thursday, 06 February 2014 1:46 PM To: Bengt Kleberg Cc: erlang-questions Subject: Re: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation Greetings, It is unfortunate that you do not find enough context in my post. I strive to give it. Could you be so kind and elaborate what I missed out when I wrote the context "It is strange that you hate tabs when it is the tools that are doing it wrong." ? As to why I do not answer in context I can explain. I take "in the context" to mean inserting spurious lines here and there through out the original email. A very bad experience of that have put me off. The writer would edit the original email, removing things he deemed unimportant, and then answer the resulting mess as unhelpfully as possible. The helpfulness sort of made sense given how badly mangled the original email had become. Unpleasant. However, now that the only person ever to become upset enough to actually write to me about how I write opinions as if they are facts, has decided that it is even worse to have to read that my opinions are my opinions, I will stop doing that. bengt On Thu, Feb 6, 2014 at 1:43 PM, Bengt Kleberg > wrote: Greetings, These are my opinions, not facts. It is strange that you hate tabs when it is the tools that are doing it wrong. Please try to not kill the messenger... starting to be horribly annoyed by your top post that force me to read the context and your header ""' Greetings, These are my opinions, not facts. """ please answer in the context or give the context in your top post... - benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Thu Feb 6 14:59:07 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 6 Feb 2014 13:59:07 +0000 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release>, <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> Message-ID: Greetings, If you are driven insane when I write that my opinions are my opinions, and you are sufficiently angered to write me about it when I do not make such a claim, I do not see how I can make you happy. I will go back to how I used to do it before. Sorry to say I do not understand how your statement "indention in Erlang is not fixed" rules out using tabs for indention. Can tabs only be used when indention is fixed? Fixed to what? bengt ________________________________________ From: Anthony Ramine [n.oxyde@REDACTED] Sent: Thursday, 06 February 2014 1:47 PM To: Bengt Kleberg Cc: erlang-questions Subject: Re: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation We can?t use tabs for indentation in Erlang because indentation in Erlang is not fixed. I?m now out of this debate because this constant ? These are my opinions, not facts. ? is driving me insane. -- Anthony Ramine Le 6 f?vr. 2014 ? 13:43, Bengt Kleberg a ?crit : > Greetings, > > These are my opinions, not facts. > > It is strange that you hate tabs when it is the tools that are doing it > wrong. Please try to not kill the messenger... > > > bengt > > On Thu, 2014-02-06 at 13:29 +0100, Anthony Ramine wrote: >> I hate tabs because tools without settings, and default settings of most historical tools, render tabs with 8 spaces. Thus this is the de facto standard. >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ingham.k@REDACTED Thu Feb 6 16:38:58 2014 From: ingham.k@REDACTED (Igor Karymov) Date: Thu, 6 Feb 2014 07:38:58 -0800 (PST) Subject: [erlang-questions] " Understanding the Erlang Scheduler" free webinar In-Reply-To: <2042267675.317180.1389349849302.JavaMail.zimbra@erlang-solutions.com> References: <1158284076.317092.1389349587206.JavaMail.zimbra@erlang-solutions.com> <2042267675.317180.1389349849302.JavaMail.zimbra@erlang-solutions.com> Message-ID: Hi guys! A bit of feedback here. Looks like you choose not a suitable platform for this webinar. Just take a look on system requirements: http://support.citrixonline.com/webinar/all_files/G2W010003 How about linux users here? I guess that a biggest part of target audience of this webinar are linux users. ???????, 10 ?????? 2014 ?., 14:30:49 UTC+4 ???????????? Andra ???????: > > Understanding the Erlang Scheduler > Thursday, February 6, 2014 - 4PM GMT > > In Erlang there are different types of concurrent entities, processes, > ports etc., each of which can have millions of instances, that have to be > mapped out to make optimal usage of the hardware. The Erlang scheduler is a > master piece in software engineering, but how does it actually go about > scheduling the processes you create in your programs? > > This webinar will provide an overview of all the different types and > explain, how the Erlang VM decides what should run where and when. > > In this webinar you'll learn about : > > * Run queues > * The differences between processes, ports and timers > * How the next thing to execute is chosen and > * Load balancing > > http://www2.erlang-solutions.com/l/23452/2014-01-03/2xqk7 > > About the speaker: > Lukas Larsson first came in contact with Erlang 2004 while studying in > G?teborg. After finishing his studies he has been working with Erlang at > Erlang Solutions for about 7 years in many different industries. > > For the last couple of years he's been a consultant at the Erlang/OTP team > at Ericsson AB, mainly working on the development of the Erlang VM. > > > -- > Andra Dinu > Community & Social > > ERLANG SOLUTIONS LTD > New Loom House > 101 Back Church Lane > London, E1 1LU > United Kingdom > > Tel +44(0)2076550344 > Mob +44(0)7983484387 > > www.erlang-solutions.com > > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ddosia@REDACTED Thu Feb 6 16:50:54 2014 From: ddosia@REDACTED (Daniil Churikov) Date: Thu, 6 Feb 2014 07:50:54 -0800 (PST) Subject: [erlang-questions] " Understanding the Erlang Scheduler" free webinar In-Reply-To: References: <1158284076.317092.1389349587206.JavaMail.zimbra@erlang-solutions.com> <2042267675.317180.1389349849302.JavaMail.zimbra@erlang-solutions.com> Message-ID: <423cc05e-b280-43fc-99ee-c5c18eefaf11@googlegroups.com> Same problem here. Btw, never seen suitable platform, any webinar so far is unique pain if you use linux. Here good idea for startup: make webinar platform, which would be accessible on any modern browser w/o java-flash-plugins dance or User-Agent string manipulation. Thank you! ???????, 6 ??????? 2014 ?., 19:38:58 UTC+4 ???????????? Igor Karymov ???????: > > Hi guys! A bit of feedback here. Looks like you choose not a suitable > platform for this webinar. Just take a look on system requirements: > http://support.citrixonline.com/webinar/all_files/G2W010003 > How about linux users here? I guess that a biggest part of target audience > of this webinar are linux users. > > ???????, 10 ?????? 2014 ?., 14:30:49 UTC+4 ???????????? Andra ???????: >> >> Understanding the Erlang Scheduler >> Thursday, February 6, 2014 - 4PM GMT >> >> In Erlang there are different types of concurrent entities, processes, >> ports etc., each of which can have millions of instances, that have to be >> mapped out to make optimal usage of the hardware. The Erlang scheduler is a >> master piece in software engineering, but how does it actually go about >> scheduling the processes you create in your programs? >> >> This webinar will provide an overview of all the different types and >> explain, how the Erlang VM decides what should run where and when. >> >> In this webinar you'll learn about : >> >> * Run queues >> * The differences between processes, ports and timers >> * How the next thing to execute is chosen and >> * Load balancing >> >> http://www2.erlang-solutions.com/l/23452/2014-01-03/2xqk7 >> >> About the speaker: >> Lukas Larsson first came in contact with Erlang 2004 while studying in >> G?teborg. After finishing his studies he has been working with Erlang at >> Erlang Solutions for about 7 years in many different industries. >> >> For the last couple of years he's been a consultant at the Erlang/OTP >> team at Ericsson AB, mainly working on the development of the Erlang VM. >> >> >> -- >> Andra Dinu >> Community & Social >> >> ERLANG SOLUTIONS LTD >> New Loom House >> 101 Back Church Lane >> London, E1 1LU >> United Kingdom >> >> Tel +44(0)2076550344 >> Mob +44(0)7983484387 >> >> www.erlang-solutions.com >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-q...@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtsiour@REDACTED Thu Feb 6 16:53:32 2014 From: gtsiour@REDACTED (Yiannis Tsiouris) Date: Thu, 06 Feb 2014 17:53:32 +0200 Subject: [erlang-questions] " Understanding the Erlang Scheduler" free webinar In-Reply-To: <423cc05e-b280-43fc-99ee-c5c18eefaf11@googlegroups.com> References: <1158284076.317092.1389349587206.JavaMail.zimbra@erlang-solutions.com> <2042267675.317180.1389349849302.JavaMail.zimbra@erlang-solutions.com> <423cc05e-b280-43fc-99ee-c5c18eefaf11@googlegroups.com> Message-ID: <52F3AFFC.9060309@softlab.ntua.gr> On 02/06/2014 05:50 PM, Daniil Churikov wrote: > Same problem here. Btw, never seen suitable platform, any webinar so far is > unique pain if you use linux. Here good idea for startup: make webinar > platform, which would be accessible on any modern browser w/o > java-flash-plugins dance or User-Agent string manipulation. Thank you! > > ???????, 6 ??????? 2014 ?., 19:38:58 UTC+4 ???????????? Igor Karymov ???????: > > Hi guys! A bit of feedback here. Looks like you choose not a suitable > platform for this webinar. Just take a look on system requirements: > http://support.citrixonline.com/webinar/all_files/G2W010003 > > How about linux users here? I guess that a biggest part of target audience > of this webinar are linux users. > I have the same issue here! :-/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From martynasp@REDACTED Thu Feb 6 16:55:00 2014 From: martynasp@REDACTED (Martynas Pumputis) Date: Thu, 6 Feb 2014 16:55:00 +0100 Subject: [erlang-questions] " Understanding the Erlang Scheduler" free webinar In-Reply-To: <423cc05e-b280-43fc-99ee-c5c18eefaf11@googlegroups.com> References: <1158284076.317092.1389349587206.JavaMail.zimbra@erlang-solutions.com> <2042267675.317180.1389349849302.JavaMail.zimbra@erlang-solutions.com> <423cc05e-b280-43fc-99ee-c5c18eefaf11@googlegroups.com> Message-ID: http://support.citrixonline.com/en_US/gotomeeting/all_files/GTM130019#Linux , although "Organizers must have the Web Viewer (beta) enabled in order to provide attendees the ability to join via their web browsers." On Thu, Feb 6, 2014 at 4:50 PM, Daniil Churikov wrote: > Same problem here. Btw, never seen suitable platform, any webinar so far is > unique pain if you use linux. Here good idea for startup: make webinar > platform, which would be accessible on any modern browser w/o > java-flash-plugins dance or User-Agent string manipulation. Thank you! > > ???????, 6 ??????? 2014 ?., 19:38:58 UTC+4 ???????????? Igor Karymov > ???????: >> >> Hi guys! A bit of feedback here. Looks like you choose not a suitable >> platform for this webinar. Just take a look on system requirements: >> http://support.citrixonline.com/webinar/all_files/G2W010003 >> How about linux users here? I guess that a biggest part of target audience >> of this webinar are linux users. >> >> ???????, 10 ?????? 2014 ?., 14:30:49 UTC+4 ???????????? Andra ???????: >>> >>> Understanding the Erlang Scheduler >>> Thursday, February 6, 2014 - 4PM GMT >>> >>> In Erlang there are different types of concurrent entities, processes, >>> ports etc., each of which can have millions of instances, that have to be >>> mapped out to make optimal usage of the hardware. The Erlang scheduler is a >>> master piece in software engineering, but how does it actually go about >>> scheduling the processes you create in your programs? >>> >>> This webinar will provide an overview of all the different types and >>> explain, how the Erlang VM decides what should run where and when. >>> >>> In this webinar you'll learn about : >>> >>> * Run queues >>> * The differences between processes, ports and timers >>> * How the next thing to execute is chosen and >>> * Load balancing >>> >>> http://www2.erlang-solutions.com/l/23452/2014-01-03/2xqk7 >>> >>> About the speaker: >>> Lukas Larsson first came in contact with Erlang 2004 while studying in >>> G?teborg. After finishing his studies he has been working with Erlang at >>> Erlang Solutions for about 7 years in many different industries. >>> >>> For the last couple of years he's been a consultant at the Erlang/OTP >>> team at Ericsson AB, mainly working on the development of the Erlang VM. >>> >>> >>> -- >>> Andra Dinu >>> Community & Social >>> >>> ERLANG SOLUTIONS LTD >>> New Loom House >>> 101 Back Church Lane >>> London, E1 1LU >>> United Kingdom >>> >>> Tel +44(0)2076550344 >>> Mob +44(0)7983484387 >>> >>> www.erlang-solutions.com >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-q...@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From ivan@REDACTED Thu Feb 6 16:56:27 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Thu, 06 Feb 2014 15:56:27 +0000 Subject: [erlang-questions] " Understanding the Erlang Scheduler" free webinar In-Reply-To: <423cc05e-b280-43fc-99ee-c5c18eefaf11@googlegroups.com> References: <1158284076.317092.1389349587206.JavaMail.zimbra@erlang-solutions.com> <2042267675.317180.1389349849302.JavaMail.zimbra@erlang-solutions.com> <423cc05e-b280-43fc-99ee-c5c18eefaf11@googlegroups.com> Message-ID: <52F3B0AB.5010501@llaisdy.com> Webinars are a Windows thing aren't they? On 06/02/2014 15:50, Daniil Churikov wrote: > Same problem here. Btw, never seen suitable platform, any webinar so far > is unique pain if you use linux. Here good idea for startup: make > webinar platform, which would be accessible on any modern browser w/o > java-flash-plugins dance or User-Agent string manipulation. Thank you! > > ???????, 6 ??????? 2014 ?., 19:38:58 UTC+4 ???????????? Igor Karymov > ???????: > > Hi guys! A bit of feedback here. Looks like you choose not a > suitable platform for this webinar. Just take a look on system > requirements: > http://support.citrixonline.com/webinar/all_files/G2W010003 > > How about linux users here? I guess that a biggest part of target > audience of this webinar are linux users. > > ???????, 10 ?????? 2014 ?., 14:30:49 UTC+4 ???????????? Andra ???????: > > Understanding the Erlang Scheduler > Thursday, February 6, 2014 - 4PM GMT > > In Erlang there are different types of concurrent entities, > processes, ports etc., each of which can have millions of > instances, that have to be mapped out to make optimal usage of > the hardware. The Erlang scheduler is a master piece in software > engineering, but how does it actually go about scheduling the > processes you create in your programs? > > This webinar will provide an overview of all the different types > and explain, how the Erlang VM decides what should run where and > when. > > In this webinar you'll learn about : > > * Run queues > * The differences between processes, ports and timers > * How the next thing to execute is chosen and > * Load balancing > > http://www2.erlang-solutions.com/l/23452/2014-01-03/2xqk7 > > > About the speaker: > Lukas Larsson first came in contact with Erlang 2004 while > studying in G?teborg. After finishing his studies he has been > working with Erlang at Erlang Solutions for about 7 years in > many different industries. > > For the last couple of years he's been a consultant at the > Erlang/OTP team at Ericsson AB, mainly working on the > development of the Erlang VM. > > > -- > Andra Dinu > Community & Social > > ERLANG SOLUTIONS LTD > New Loom House > 101 Back Church Lane > London, E1 1LU > United Kingdom > > Tel +44(0)2076550344 > Mob +44(0)7983484387 > > www.erlang-solutions.com > > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From g@REDACTED Thu Feb 6 17:02:28 2014 From: g@REDACTED (Garrett Smith) Date: Thu, 6 Feb 2014 10:02:28 -0600 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> Message-ID: This has been a very productive thread. If I may try to summarize, for posterity: - Mixed tabs and spaces present challenges for programmer using different editors and contributing to projects with varied or poorly defined white space standards - There are a number of possible solutions to this problem, many of which have been mentioned here - The cost of discussing this problem is so much higher than cost of actually dealing with it - even in cases where a programmer has to manually copy and past formatted lines to preserve a source file's dark, twisted and immortal formatting - it's *still much easier* than talking about how to fix the underlying problem I feel a certain liberation knowing this. These are my opinions, which are facts. Garrett On Thu, Feb 6, 2014 at 7:59 AM, Bengt Kleberg wrote: > Greetings, > > If you are driven insane when I write that my opinions are my opinions, and you are sufficiently angered to write me about it when I do not make such a claim, I do not see how I can make you happy. > I will go back to how I used to do it before. > > Sorry to say I do not understand how your statement "indention in Erlang is not fixed" rules out using tabs for indention. Can tabs only be used when indention is fixed? Fixed to what? > > > bengt > ________________________________________ > From: Anthony Ramine [n.oxyde@REDACTED] > Sent: Thursday, 06 February 2014 1:47 PM > To: Bengt Kleberg > Cc: erlang-questions > Subject: Re: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation > > We can't use tabs for indentation in Erlang because indentation in Erlang is not fixed. > > I'm now out of this debate because this constant << These are my opinions, not facts. >> is driving me insane. > > -- > Anthony Ramine > > Le 6 f?vr. 2014 ? 13:43, Bengt Kleberg a ?crit : > >> Greetings, >> >> These are my opinions, not facts. >> >> It is strange that you hate tabs when it is the tools that are doing it >> wrong. Please try to not kill the messenger... >> >> >> bengt >> >> On Thu, 2014-02-06 at 13:29 +0100, Anthony Ramine wrote: >>> I hate tabs because tools without settings, and default settings of most historical tools, render tabs with 8 spaces. Thus this is the de facto standard. >>> >> >> _______________________________________________ >> 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 mabrek@REDACTED Thu Feb 6 17:08:12 2014 From: mabrek@REDACTED (Anton Lebedevich) Date: Thu, 06 Feb 2014 20:08:12 +0400 Subject: [erlang-questions] " Understanding the Erlang Scheduler" free webinar In-Reply-To: References: <1158284076.317092.1389349587206.JavaMail.zimbra@erlang-solutions.com> <2042267675.317180.1389349849302.JavaMail.zimbra@erlang-solutions.com> Message-ID: <52F3B36C.1090002@gmail.com> try mobile apps. Android client works well On 02/06/2014 07:38 PM, Igor Karymov wrote: > Hi guys! A bit of feedback here. Looks like you choose not a suitable > platform for this webinar. Just take a look on system requirements: > http://support.citrixonline.com/webinar/all_files/G2W010003 > How about linux users here? I guess that a biggest part of target > audience of this webinar are linux users. > > ???????, 10 ?????? 2014 ?., 14:30:49 UTC+4 ???????????? Andra ???????: > > Understanding the Erlang Scheduler > Thursday, February 6, 2014 - 4PM GMT > > In Erlang there are different types of concurrent entities, > processes, ports etc., each of which can have millions of instances, > that have to be mapped out to make optimal usage of the hardware. > The Erlang scheduler is a master piece in software engineering, but > how does it actually go about scheduling the processes you create in > your programs? > > This webinar will provide an overview of all the different types and > explain, how the Erlang VM decides what should run where and when. > > In this webinar you'll learn about : > > * Run queues > * The differences between processes, ports and timers > * How the next thing to execute is chosen and > * Load balancing > > http://www2.erlang-solutions.com/l/23452/2014-01-03/2xqk7 > > > About the speaker: > Lukas Larsson first came in contact with Erlang 2004 while studying > in G?teborg. After finishing his studies he has been working with > Erlang at Erlang Solutions for about 7 years in many different > industries. > > For the last couple of years he's been a consultant at the > Erlang/OTP team at Ericsson AB, mainly working on the development of > the Erlang VM. > > > -- > Andra Dinu > Community & Social > > ERLANG SOLUTIONS LTD > New Loom House > 101 Back Church Lane > London, E1 1LU > United Kingdom > > Tel +44(0)2076550344 > Mob +44(0)7983484387 > > www.erlang-solutions.com > > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From bchesneau@REDACTED Thu Feb 6 17:12:37 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Thu, 6 Feb 2014 17:12:37 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> Message-ID: On Thu, Feb 6, 2014 at 5:02 PM, Garrett Smith wrote: > This has been a very productive thread. If I may try to summarize, for > posterity: > > - Mixed tabs and spaces present challenges for programmer using > different editors and contributing to projects with varied or poorly > defined white space standards > > - There are a number of possible solutions to this problem, many of > which have been mentioned here > > - The cost of discussing this problem is so much higher than cost of > actually dealing with it - even in cases where a programmer has to > manually copy and past formatted lines to preserve a source file's > dark, twisted and immortal formatting - it's *still much easier* than > talking about how to fix the underlying problem > > I feel a certain liberation knowing this. > > These are my opinions, which are facts. > > I learnt today that I hate any opinions which are facts. This is a fact. - benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Thu Feb 6 17:19:24 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Thu, 6 Feb 2014 17:19:24 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> Message-ID: On Thu, Feb 6, 2014 at 5:12 PM, Benoit Chesneau wrote: > > > I learnt today that I hate any opinions which are facts. This is a fact. > + not -------------- next part -------------- An HTML attachment was scrubbed... URL: From gianfranco.alongi@REDACTED Thu Feb 6 17:24:31 2014 From: gianfranco.alongi@REDACTED (Gianfranco Alongi) Date: Thu, 6 Feb 2014 17:24:31 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> Message-ID: Please, as fun as this is, try to respect the reason for the mail list and have in mind that people may be subscribed to different lists. It should not be necessary to clear out mail list messages because they are of topic and not add anything to any Erlang related discussion. On Thu, Feb 6, 2014 at 5:19 PM, Benoit Chesneau wrote: > > > > On Thu, Feb 6, 2014 at 5:12 PM, Benoit Chesneau wrote: > >> >> >> I learnt today that I hate any opinions which are facts. This is a fact. >> > > + not > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrzej.sliwa@REDACTED Thu Feb 6 17:24:55 2014 From: andrzej.sliwa@REDACTED (=?utf-8?Q?Andrzej_=C5=9Aliwa?=) Date: Thu, 6 Feb 2014 17:24:55 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> Message-ID: I know that discussions sometimes are really hard but we should respect other opinions even if we not agree with them.? Everybody have full right to keeps own opinion and also should respect others points of view. The good arguments in dicussions are something which I love to hear. I really enjoy approach of ?let it fail? also in real life? with respect to giving somebody chance to change his mind later. I think there is no space in discussions for ?hate? feelings? we could unlike opinions, not agree with them, but I think ?hate" is really to strong statement. ?? On 6 Feb 2014 at 17:13:20, Benoit Chesneau (bchesneau@REDACTED) wrote: On Thu, Feb 6, 2014 at 5:02 PM, Garrett Smith wrote: This has been a very productive thread. If I may try to summarize, for posterity: - Mixed tabs and spaces present challenges for programmer using different editors and contributing to projects with varied or poorly defined white space standards - There are a number of possible solutions to this problem, many of which have been mentioned here - The cost of discussing this problem is so much higher than cost of actually dealing with it - even in cases where a programmer has to manually copy and past formatted lines to preserve a source file's dark, twisted and immortal formatting - it's *still much easier* than talking about how to fix the underlying problem I feel a certain liberation knowing this. These are my opinions, which are facts. I learnt today that I hate any opinions which are facts. This is a fact. - benoit _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Thu Feb 6 17:30:38 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Thu, 6 Feb 2014 17:30:38 +0100 Subject: [erlang-questions] json handling map functions in erlang 17 In-Reply-To: References: Message-ID: On Wed, Feb 5, 2014 at 10:22 PM, Bj?rn-Egil Dahlberg wrote: > I have not read Joes final book on the matter (several drafts > though) .. and I've told him, twice I think, that there will *not* > be any maps to json BIFs to in the maps module. It does not belong > in the standard library. Thank you very much Egil! I'm sure there are others who welcome that decision, and I'd like to voice my gratitude for _not_ introducing JSON at that layer. > I do touch on the subject in the EEP > (https://github.com/erlang/eep/blob/master/eeps/eep-0043.md) under > "protocol construction". > > However, it is encouraged that erlang json libraries make use of > maps. =) From bchesneau@REDACTED Thu Feb 6 17:34:31 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Thu, 6 Feb 2014 17:34:31 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> Message-ID: On Thu, Feb 6, 2014 at 5:29 PM, Benoit Chesneau wrote: > On Thu, Feb 6, 2014 at 5:24 PM, Andrzej ?liwa wrote: >> >> I know that discussions sometimes are really hard but we should respect other opinions even if we not agree with them. >> Everybody have full right to keeps own opinion and also should respect others points of view. The good arguments in dicussions are something which I love to hear. >> >> I really enjoy approach of ?let it fail? also in real life? with respect to giving somebody chance to change his mind later. >> >> I think there is no space in discussions for ?hate? feelings? we could unlike opinions, not agree with them, but I think ?hate" is really to strong statement. > > > hate: a very strong feeling of dislike > > This exactly what I wanted to express. > Also if you if you missed the "not", It was attached to facts. And was a blink. But you failed to understand it locked in your politically correctness trap. - benoit. From bchesneau@REDACTED Thu Feb 6 17:29:16 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Thu, 6 Feb 2014 17:29:16 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> Message-ID: On Thu, Feb 6, 2014 at 5:24 PM, Andrzej ?liwa wrote: > > I know that discussions sometimes are really hard but we should respect other opinions even if we not agree with them. > Everybody have full right to keeps own opinion and also should respect others points of view. The good arguments in dicussions are something which I love to hear. > > I really enjoy approach of ?let it fail? also in real life? with respect to giving somebody chance to change his mind later. > > I think there is no space in discussions for ?hate? feelings? we could unlike opinions, not agree with them, but I think ?hate" is really to strong statement. hate: a very strong feeling of dislike This exactly what I wanted to express. - benoit > > > > On 6 Feb 2014 at 17:13:20, Benoit Chesneau (bchesneau@REDACTED) wrote: > > > > > On Thu, Feb 6, 2014 at 5:02 PM, Garrett Smith wrote: >> >> This has been a very productive thread. If I may try to summarize, for >> posterity: >> >> - Mixed tabs and spaces present challenges for programmer using >> different editors and contributing to projects with varied or poorly >> defined white space standards >> >> - There are a number of possible solutions to this problem, many of >> which have been mentioned here >> >> - The cost of discussing this problem is so much higher than cost of >> actually dealing with it - even in cases where a programmer has to >> manually copy and past formatted lines to preserve a source file's >> dark, twisted and immortal formatting - it's *still much easier* than >> talking about how to fix the underlying problem >> >> I feel a certain liberation knowing this. >> >> These are my opinions, which are facts. >> > > I learnt today that I hate any opinions which are facts. This is a fact. > > - benoit > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From fly@REDACTED Thu Feb 6 18:08:37 2014 From: fly@REDACTED (Fred Youhanaie) Date: Thu, 06 Feb 2014 17:08:37 +0000 Subject: [erlang-questions] " Understanding the Erlang Scheduler" free webinar In-Reply-To: References: <1158284076.317092.1389349587206.JavaMail.zimbra@erlang-solutions.com> <2042267675.317180.1389349849302.JavaMail.zimbra@erlang-solutions.com> Message-ID: <52F3C195.2060109@anydata.co.uk> On 06/02/14 15:38, Igor Karymov wrote: > Hi guys! A bit of feedback here. Looks like you choose not a suitable > platform for this webinar. Just take a look on system requirements: > http://support.citrixonline.com/webinar/all_files/G2W010003 > How about linux users here? I guess that a biggest part of target audience > of this webinar are linux users. It's not the same as the live session with a chance to ask questions, however, if you wait a day or two, they will provide the recording of the webinar here: https://www.erlang-solutions.com/resources/webinars It was good - well worth watching it again :-) Cheers Fred From maruthavanan_s@REDACTED Thu Feb 6 19:24:42 2014 From: maruthavanan_s@REDACTED (Maruthavanan Subbarayan) Date: Thu, 6 Feb 2014 13:24:42 -0500 Subject: [erlang-questions] Common Tests and config files Message-ID: Hi, I have a application that I want to pass different config files, one for production and one for running tests. sh-3.2# cat $PROJECT/test/app.config [{sample_app, [{test, test}]}]. I have also tried using{sample_app, [{test, test}]}. and this is my test case, located in $PROJECT/test/sample_app_SUITE.erl directory my_test_case(_Config) -> Result = application:load(sample_app), Environment = application:get_all_env(sample_app), ct:pal("Loaded Environment:~p", [Result]), ct:pal("Loaded variables:~p", [Environment]), ok. My source code as of now has nothing. When I run "./rebar ct" and look into log files I see the below result ---------------------------------------------------- 2014-02-06 23:41:37.328 Loaded Environment:ok ---------------------------------------------------- 2014-02-06 23:41:37.329 Loaded variables:[{included_applications,[]}] I tried without rebar too ct_run -noshell -pa "/WorkArea/sample/ebin" "/WorkArea/sample/rebar/rebar/ebin" "/WorkArea/sample/rebar" "/WorkArea/sample/." -name test@REDACTED -logdir "/WorkArea/sample/logs" -env TEST_DIR "/WorkArea/sample/test" -config test/app.config -dir test >> /WorkArea/sample/logs/raw.log Why my app.config variables are not merge and what should I do to get those impacted in environment variables before a test starts? Am I missing out something? Note: I am able to get the config variable over a file when I use erl -config -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Thu Feb 6 23:12:43 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 7 Feb 2014 11:12:43 +1300 Subject: [erlang-questions] printed maps look confusing In-Reply-To: References: <52EFA099.7020204@ninenines.eu> Message-ID: <395E92F1-8F7D-4F3B-AC79-7EAF842EB7ED@cs.otago.ac.nz> On 6/02/2014, at 3:37 AM, Raphael Korsoski wrote: > Guillemets are available to most X/Gnome users even on (int'l) American keyboards, but I guess Windows and unusual desktops in *nix environments put an end to that. On my Mac, it's a single keystroke to switch to the French keyboard and a single keystroke back. In the text editor I use, Meta-: << and Meta-: >> give me guillemets. > I'm thinking about APL, though, and feel that perhaps ASCII is still good enough. There are some unicode symbols I wouldn't mind using in code, but the example with APL kind of scares me.... Take a look at J. I think you'll find that "APL-in-ASCII" is scarier than plain APL. From felixgallo@REDACTED Thu Feb 6 23:35:18 2014 From: felixgallo@REDACTED (Felix Gallo) Date: Thu, 6 Feb 2014 14:35:18 -0800 Subject: [erlang-questions] Maps & records: binding directly to bitstring comprehensions Message-ID: I live in a world of pain wherein I receive 4K binary blob packets with a tightly packed schema that changes every few weeks. One way to handle it is, e.g., (field names changed to anonymize the guilty): -define(PACKET, <>). (and then, in my state machine...) s_connected(P = ?PACKET) -> io:format("Moisture: ~p~n", [Moisture]), %% twitch [...] and conversely mold_together_a_packet(Version, Flavor, Moisture, IsDelicious, ...) -> ?PACKET. or if I wanted to put some modicum of discipline on that thing maybe something like: -define(OUTGOINGPACKET, [Version, Flavor, Moisture, IsDelicious, ...]). mod_together_a_packet(?OUTGOINGPACKET) -> ?PACKET. both of these things seem iffy and super messed up because I have to define each field separately each in two different macros, and also the namespace pollution is bad. Maybe I'm doing it wrong, but those seem to me like the best of a set of bad ways to do it. Yet, it seems like the language knows enough to be *able* to bind a bitstring comprehension directly to a record, and probably will know enough soon to bind it directly to a map. e.g., <> = P and also <> = P and also the science fictional: SchemaType = #{ Version: 8, Flavor: 3, Moisture: 5, ... }, %% assumes insert ordering on maps instead of term ordering because I prefer it that way <> = P, M#{ Flavor } = 5, <>. disclaimer: not a programming language theorist. anyway, it would be super great if something like this were to exist; or, if there's something better than the nasty macro magic I ended up using that is a second place finisher in the absence of this, I'd love to know what it is. F. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Fri Feb 7 01:04:43 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 7 Feb 2014 13:04:43 +1300 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <1391672175.4877.19.camel@sekic1152.release> References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <1391672175.4877.19.camel@sekic1152.release> Message-ID: On 6/02/2014, at 8:36 PM, Bengt Kleberg wrote: > The use of one tab for one level of indention is logical. The indention > level is 1, so why have another amount of characters? The only reason I > have heard for X =/= 1 is that 1 space is too narrow. So, use 1 tab. All > editors that I use can make 1 tab take up whatever width I like for > indentation. Sadly, there are tools other than editors. Having to hunt them down, trying to reconfigure them ALL, and failing, is why I refuse to mess with the defaults. Sadly, there are more editors out there than vi(m) and (x)emacs, and they do not all understand each other's way of recording the tab width. (Did anyone out there ever have to deal with code written using VED? Or Macintosh editors that kept info like that in resource forks?) I owe you people a debt of thanks. My text editor now has a quick-and-easy "untabify buffer" command. I wouldn't have bothered without this thread. From kino@REDACTED Fri Feb 7 02:31:37 2014 From: kino@REDACTED (satoshi kinoshita) Date: Fri, 7 Feb 2014 10:31:37 +0900 Subject: [erlang-questions] erlang-questions Digest, Vol 151, Issue 14 In-Reply-To: References: Message-ID: > Also keep in mind that the =memory section lists it in bytes while =proc > sections list heap in words. > > Lukas Hi Lukas, Thank you for the information. Then sum of heaps of all processes are less than 100M words. That is less than 400M bytes(I'm using R11B-5 32bit beam). I'm afraid there is a still big gap between this and processes_used 1.6G in erl_crash.dump. Maybe I'm misunderstanding something:). Thanks a lot, Kinoshita ------------------------------------------------------------------------------------------------------------- On Thu, Feb 6, 2014 at 6:35 AM, satoshi kinoshita wrote: > Does any one know some more detail information for OTP-7132? > > > --- http://www.erlang.org/doc/apps/erts/notes.html#id114389 ---- > The emulator could under rare circumstances crash while garbage collecting. > > Own Id: OTP-7132 > ------------------------------ > > ---------------------------------- > > > > We're still using R11B-5 and having a crash while doing GC on a process. > > Though erl_crash.dump is reporting almost 2GB was used for "processes", > > > > top/vmstat is just reporting less than 1GB for beam.smp. > > > > It is also strange to me that sum of heap and OldHeap for all processes > > are less than 100M, but processes_used is almost 1.6G. > > > > I don't know OTP-7132 is related. Any information will be appreciated. > > > > Thanks, > > Kinoshita > > > > > > -------------------------------------------------------------------- > > % { grep +heap: erl_crash.dump |cut -d' ' -f2 |tr "\n" +; echo 0; }|bc > > 46165303 > > % { grep OldHeap: erl_crash.dump |cut -d' ' -f2 |tr "\n" +; echo 0; }|bc > > 52591961 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Fri Feb 7 05:51:28 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 7 Feb 2014 17:51:28 +1300 Subject: [erlang-questions] The quest for the perfect programming language for massive concurrency. In-Reply-To: References: <89DAA09F-64B0-4565-A73C-784B5E8EB4C6@feuerlabs.com> <8883B14026CD4CB38E71BEB9DFE5BF67@srstrong.com> <2AF9E186-6684-4787-8368-6E019C8113C8@cs.otago.ac.nz> Message-ID: <6B03F71A-52AC-4646-A3F9-900D85AE0787@cs.otago.ac.nz> On 4/02/2014, at 9:04 PM, Vlad Dumitrescu wrote: > Hi Richard, > > There's a lot of interesting stuff in your post, as always, and most of it I agree 100% but I have this nagging feeling that there's a misunderstanding between us and we're not talking about the same things. Let's go right back to what Joe wrote: What I want in a programming environment would take a book to describe. For starters, I would like it to be precisely documented. Let me say that this is one of my pet peeves. If there _had_ been precise documentation for XCode 4, Apple might have been inclined to make XCode 5 more compatible with it. As it is, I have a helpful book for XCode 4 that is, um, less helpful for XCode 5. Maybe this deserves a slogan: "If we don't document an interface we can smile while breaking it." It should be textual not GUI based - THE REASON FOR THIS IS AUTOMATION - I cannot easily automate things if they are GUI based. I can automate things if they are text based. Also It's very difficult to describe what to do in a GUI - the descriptions need pictures to tell you what to do. Slogan: "A picture may be *worth* a thousand words but it *costs* ten thousand." > In short, the things you enumerate as advantages of a textual program and the drawbacks of the graphical ones aren't all related to the textual/graphical attribute of the program. That Excel can't be scripted in the same language in all environments has nothing to do with it having a GUI. In a sense you are right. After all, Microsoft *did* supply Visual Basic for Applications on Macintoshes, right up to the point where Apple switched to X86 and it became *easier* for Microsoft to do this. The problem is that when the update without VBA was forced on me, I *never* received *any* documentation for how to drive it from AppleScript. Nor did I receive any links to it. Apparently there *was* an AppleScript/Excel reference manual, but it's no longer at its old address and other people seem to be looking for it too. (I loved this quote: "The Microsoft Office scripting dictionaries are just horribly designed. They violate pretty much every convention for scripting dictionaries that Apple specifies.") R to the rescue! (But wait: that's a textual interface!) Here are the criteria again: * automation * [my addition] tolerably portable automation across all supported platforms * clear and adequate definition of the interface * ease of explaining to others what to do Now Excel only supports automation to the extent that it supports an *alternative* to the GUI. The documentation -- and I eventually discovered an obsolete copy of the reference manual, who knows what will break? -- presents a *textual* interface for automation. As a matter of fact, now that I have that, I can see that it is definitely easier to explain to other programmers what sort of AppleScript to write than to send them a video of me doing it with the GUI. > That Eclipse starts with a "welcome" page that can be confusing, that has nothing to do with GUIs either. Yes it does. Joe was talking about programming environments. Eclipse is one. I am saying that "is graphical" does not mean "is good for communication", and that's a superb example of a *graphical* *user* *interface* that fails horribly at communication *because* it is graphic. Only the (textual!) tooltips make it possible to do *anything* with that page. > What I tried to compare was what could be done with one or other kind of interface. Most things can be done just as well with either; some things work better with one of them, depending of the way the user's brain is wired: Remember the criteria? It wasn't originally about *users*, it was about *automation*. GUIs are hard to automate, not least because Microsoft seem to redesign their UI for each release. > I, for example, have easier to work with images/icons/color coding/visual structure. Others, like you, prefer plain text. I don't know nearly enough about usability. This much I do know, there are three very different things: - how FAST someone can perform a task - how ACCURATELY they can perform the task - how much they ENJOY performing the task. These are not just conceptually distinct; they are in practice sufficiently independent that when someone says "I have easier to work with X than Y" I haven't the least idea what they actually mean. > Excellent! I'm not bashing textual interfaces just because I happen to have other ways that work better for me in certain cases. Then why _are_ you writing? I guess I am just a bad writer. I did say that I was trying to support what I took Joe's position to be. > Everyone I know draws pen-and-paper diagrams and sketches and charts and finds them useful. If they are useful when drawn by hand, they are useful when drawn by a program. If existing programs are drawing incomprehensible diagrams, it doesn't mean that the right diagram would be just as useless. I would soften Joe's position a bit. I don't mind if a programming environment *does* have an optional GUI. What I mind is if all the design work has gone into making the GUI look flashy and buzzwordy while the scripting interface is unstable, bloated, or defunct. Oh, let me close with a GUI feature I which I *do* enjoy. If you use XCode, and you select Build|Analyze, you get these really cool relevance chains tying together the lines that combine to produce a probable bug. I *really* enjoy that. (But I don't believe it helps me program faster or more accurately.) From ok@REDACTED Fri Feb 7 06:10:42 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 7 Feb 2014 18:10:42 +1300 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> Message-ID: On 6/02/2014, at 9:21 AM, kraythe . wrote: > Actually the solution to this age old debate was proposed to me by a friend of mine and its genius on a number of levels but isn't implemented anywhere. The reality is that for most languages whitespace is irrelevant so it shouldn't be the code holding the indentation but the user's preference file. Imagine a source code repository where there is NO irrelevant whitespace in the code base. For java, for example, there would be literally only one single line of code. Now when you check out you have a preference file that says you want tabs or spaces or mixed and also defines the other formatting you prefer. When you check out the system reformats the code according to your specs dynamically. When you commit, it strips your code of whitespace before comparing. The IDE I use on the rare occasions that I write C# does something not entirely unlike that. There is a bunch of flags you can set; each comes with an example for each alternative and you pick the one you want. It then shows you the source code in the style you like. I have no idea how it does this. Of course there are languages (Occam, Haskell, Clean, Python, ...) where leading white space _does_ matter, and there are plenty of languages (Fortran, C, APL, AWK, ...) where line breaks matter a lot. I suppose I can mention Interlisp-D again? An idea that had the Xerox PARC people jumping up and down and hugging themselves in the 80s was A program is not a listing it's a data base. Source code was saved in files that were sort of readable, but the system built indices and didn't necessarily read them from beginning to end. Come to think of it, Smalltalk keeps the source code on disc as a base data base + a log of changes, keeps changes as a data structure internally, and can be set to reindent the source code before showing it to you (and note that this is not, per se, a change). Even the ANSI standard format for Smalltalk source code is not really meant for people to read and write, and as for SIXX, ... This isn't quite the same as the proposal above, because these systems _did_ keep white space in the data base that wasn't strictly necessary, but they didn't/don't _depend_ on it for what they show you. Of course this is *wonderful*, but only as long as the only tools you want to use are the ones built into the IDE or readily scriptable in it. Interlisp was/Smalltalk is good at navel-gazing, but each Smalltalk is, *sigh*, different... From bengt.kleberg@REDACTED Fri Feb 7 07:32:12 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Fri, 7 Feb 2014 07:32:12 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <1391672175.4877.19.camel@sekic1152.release> Message-ID: <1391754733.4846.4.camel@sekic1152.release> Greetings, Would it be correct to say that this solution trades the possibilities of user configurable tab width when available, for the certainty of being able to use even those programs that have a hard coded tab width? bengt On Fri, 2014-02-07 at 13:04 +1300, Richard A. O'Keefe wrote: > On 6/02/2014, at 8:36 PM, Bengt Kleberg wrote: > > The use of one tab for one level of indention is logical. The indention > > level is 1, so why have another amount of characters? The only reason I > > have heard for X =/= 1 is that 1 space is too narrow. So, use 1 tab. All > > editors that I use can make 1 tab take up whatever width I like for > > indentation. > > Sadly, there are tools other than editors. > Having to hunt them down, trying to reconfigure them ALL, > and failing, is why I refuse to mess with the defaults. > > Sadly, there are more editors out there than vi(m) and (x)emacs, > and they do not all understand each other's way of recording the > tab width. (Did anyone out there ever have to deal with code > written using VED? Or Macintosh editors that kept info like that > in resource forks?) > > I owe you people a debt of thanks. > My text editor now has a quick-and-easy "untabify buffer" command. > I wouldn't have bothered without this thread. > From bengt.kleberg@REDACTED Fri Feb 7 07:48:43 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Fri, 7 Feb 2014 06:48:43 +0000 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> , Message-ID: Greetings, I think you have a correct thread summary here below. Perhaps the thing that Lukas mentioned, ie that any formatter must be good enough top not introduce bugs, should also be added? And maybe Rickards (later) email about the need to set tabs to the right amount of spaces, when it is configurable, if you need to use programs that have the tab width hard coded? bengt ________________________________________ From: Garrett Smith [g@REDACTED] Sent: Thursday, 06 February 2014 5:02 PM To: Bengt Kleberg Cc: erlang-questions Subject: Re: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation This has been a very productive thread. If I may try to summarize, for posterity: - Mixed tabs and spaces present challenges for programmer using different editors and contributing to projects with varied or poorly defined white space standards - There are a number of possible solutions to this problem, many of which have been mentioned here - The cost of discussing this problem is so much higher than cost of actually dealing with it - even in cases where a programmer has to manually copy and past formatted lines to preserve a source file's dark, twisted and immortal formatting - it's *still much easier* than talking about how to fix the underlying problem I feel a certain liberation knowing this. These are my opinions, which are facts. Garrett On Thu, Feb 6, 2014 at 7:59 AM, Bengt Kleberg wrote: > Greetings, > > If you are driven insane when I write that my opinions are my opinions, and you are sufficiently angered to write me about it when I do not make such a claim, I do not see how I can make you happy. > I will go back to how I used to do it before. > > Sorry to say I do not understand how your statement "indention in Erlang is not fixed" rules out using tabs for indention. Can tabs only be used when indention is fixed? Fixed to what? > > > bengt > ________________________________________ > From: Anthony Ramine [n.oxyde@REDACTED] > Sent: Thursday, 06 February 2014 1:47 PM > To: Bengt Kleberg > Cc: erlang-questions > Subject: Re: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation > > We can't use tabs for indentation in Erlang because indentation in Erlang is not fixed. > > I'm now out of this debate because this constant << These are my opinions, not facts. >> is driving me insane. > > -- > Anthony Ramine > > Le 6 f?vr. 2014 ? 13:43, Bengt Kleberg a ?crit : > >> Greetings, >> >> These are my opinions, not facts. >> >> It is strange that you hate tabs when it is the tools that are doing it >> wrong. Please try to not kill the messenger... >> >> >> bengt >> >> On Thu, 2014-02-06 at 13:29 +0100, Anthony Ramine wrote: >>> I hate tabs because tools without settings, and default settings of most historical tools, render tabs with 8 spaces. Thus this is the de facto standard. >>> >> >> _______________________________________________ >> 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 kraythe@REDACTED Fri Feb 7 08:25:03 2014 From: kraythe@REDACTED (kraythe .) Date: Fri, 7 Feb 2014 01:25:03 -0600 Subject: [erlang-questions] Trying to learn the Erlang Way Message-ID: I am a newbie to erlang so please excuse the newbie questions. To learn the language I have a use case, simply to take a vector C which defines the center of a sphere with radius R and then cull a list of vectors and return only the vectors in the sphere. A simple math problem the most efficient method is to calculate the difference in C and a vector V and if any component is greater than R then the vector can't be in the sphere, if not then we have to do the expensive sort magnitude calculation. To this end I have created a simple set of functions: -module(vector3d). -author("rsimmons"). %% API -export([subtract/2, magnitude/1, scale/2, cull/3]). %% Subtract the second vector from the first subtract({X1, Y1, Z1}, {X2, Y2, Z2}) -> {(X1 - X2), (Y1 - Y2), (Z1 - Z2)}. %% Compute the magnitude of the vector magnitude({X, Y, Z}) -> math:sqrt((X * X) + (Y * Y) + (Z * Z)). %% Determines if any coordinate in the given vector is bigger than the passed in value V. coordinateGreaterThan(V, {X, Y, Z}) when X > V; Y > V; Z > V -> true; coordinateGreaterThan(_, _) -> false. %% Culls the list of vectors X to only those that are in the sphere devined by vector C as a center and R as a radius. cull(C, R, Vectors) when is_number(R), is_tuple(C) -> cull(C, R, Vectors, []). cull(C, R, Culled, []) -> Culled; cull(C, R, Culled, [Head|Tail]) -> D = subtract(C, Head), case coordinateIsGreaterThan(R, Head) of true -> cull(C, R, Culled, Tail); false -> cullOnMagnitude(C, R, D, Culled, Head, Tail) end. cullOnMagnitude(C, R, D, Culled, Head, Tail) when is_tuple(D), is_number(R) -> M = magnitude(D), if M > R -> cull(C, R, Culled, Tail); true -> cull(C, R, [Head | Culled], Tail) end. When I load these into a file and compile them I get the following result: 16> c(vector3d). vector3d.erl:53: function coordinateIsGreaterThan/2 undefined vector3d.erl:45: Warning: function coordinateGreaterThan/2 is unused vector3d.erl:50: Warning: variable 'C' is unused vector3d.erl:50: Warning: variable 'R' is unused Note that there are some other methods in this file so the line numbers will vary. My questions are: 1) Why is it saying my coordinateIsGreaterThan/2 method is undefined when I can see it here and then to say it is unused in the next line? That seems contradictory? 2) Is this in the direction of the "erlang way" to do things? 3) I understand the variables not being used but it seems odd to me from the java language world to not define the names for the variables. Is this normal in erlang? Thanks in advance. *Robert Simmons Jr. MSc.* *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Fri Feb 7 08:27:28 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 7 Feb 2014 08:27:28 +0100 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: Message-ID: Hi, On Fri, Feb 7, 2014 at 8:25 AM, kraythe . wrote: > coordinateGreaterThan(V, {X, Y, Z}) when X > V; Y > V; Z > V -> true; > coordinateGreaterThan(_, _) -> false. > > %% Culls the list of vectors X to only those that are in the sphere devined > by vector C as a center and R as a radius. > cull(C, R, Vectors) when is_number(R), is_tuple(C) -> cull(C, R, Vectors, > []). > cull(C, R, Culled, []) -> Culled; > cull(C, R, Culled, [Head|Tail]) -> > D = subtract(C, Head), > case coordinateIsGreaterThan(R, Head) of > true -> cull(C, R, Culled, Tail); > > 1) Why is it saying my coordinateIsGreaterThan/2 method is undefined when I > can see it here and then to say it is unused in the next line? That seems > contradictory? Look carefully and see that you define "coordinateGreaterThan" and call "coordinateIsGreaterThan". regards, Vlad From sergej.jurecko@REDACTED Fri Feb 7 08:30:44 2014 From: sergej.jurecko@REDACTED (=?UTF-8?Q?Sergej_Jure=C4=8Dko?=) Date: Fri, 7 Feb 2014 08:30:44 +0100 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: Message-ID: Use https://github.com/rustyio/sync so you don't have to manually recompile your code Sergej On Fri, Feb 7, 2014 at 8:27 AM, Vlad Dumitrescu wrote: > Hi, > > On Fri, Feb 7, 2014 at 8:25 AM, kraythe . wrote: > > coordinateGreaterThan(V, {X, Y, Z}) when X > V; Y > V; Z > V -> true; > > coordinateGreaterThan(_, _) -> false. > > > > %% Culls the list of vectors X to only those that are in the sphere > devined > > by vector C as a center and R as a radius. > > cull(C, R, Vectors) when is_number(R), is_tuple(C) -> cull(C, R, Vectors, > > []). > > cull(C, R, Culled, []) -> Culled; > > cull(C, R, Culled, [Head|Tail]) -> > > D = subtract(C, Head), > > case coordinateIsGreaterThan(R, Head) of > > true -> cull(C, R, Culled, Tail); > > > > 1) Why is it saying my coordinateIsGreaterThan/2 method is undefined > when I > > can see it here and then to say it is unused in the next line? That seems > > contradictory? > > Look carefully and see that you define "coordinateGreaterThan" and > call "coordinateIsGreaterThan". > > 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 Fri Feb 7 08:42:25 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 7 Feb 2014 08:42:25 +0100 Subject: [erlang-questions] OTP-compliant patches Message-ID: Hi, Just so that I make sure I understand correctly, in the light of the flame war that I recently started :-\ The documentation says > Make sure your changes follow the coding and indentation style of the code surrounding your > changes. (At some point in the future, there will be a style guide, either included in the > documentation or on some web site, but it is not ready yet.) So if the local indentation is not what erlang-mode would give, then I still have to manually adjust it to match what already was there. Is that correct? Since I've had some diff look ok in emacs but not on github (or the other way around, I don't remember exactly), which one is the reference in case of mismatch? best regards, Vlad From gumm@REDACTED Fri Feb 7 08:56:51 2014 From: gumm@REDACTED (Jesse Gumm) Date: Fri, 7 Feb 2014 01:56:51 -0600 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: Message-ID: Hi, In response to (3), the way to get around this is to prefix unused variables with underscores. So binding _C and then not using it would then not trigger a warning. It's rather common to do it this way in multiple clauses where you want to show each argument rather than just using _ alone. -Jesse -- Jesse Gumm Owner, Sigma Star Systems 414.940.4866 || sigma-star.com || @jessegumm On Feb 7, 2014 1:25 AM, "kraythe ." wrote: > I am a newbie to erlang so please excuse the newbie questions. To learn > the language I have a use case, simply to take a vector C which defines the > center of a sphere with radius R and then cull a list of vectors and return > only the vectors in the sphere. A simple math problem the most efficient > method is to calculate the difference in C and a vector V and if any > component is greater than R then the vector can't be in the sphere, if not > then we have to do the expensive sort magnitude calculation. > > To this end I have created a simple set of functions: > -module(vector3d). > -author("rsimmons"). > > %% API > -export([subtract/2, magnitude/1, scale/2, cull/3]). > > %% Subtract the second vector from the first > subtract({X1, Y1, Z1}, {X2, Y2, Z2}) -> {(X1 - X2), (Y1 - Y2), (Z1 - Z2)}. > > %% Compute the magnitude of the vector > magnitude({X, Y, Z}) -> math:sqrt((X * X) + (Y * Y) + (Z * Z)). > > %% Determines if any coordinate in the given vector is bigger than the > passed in value V. > coordinateGreaterThan(V, {X, Y, Z}) when X > V; Y > V; Z > V -> true; > coordinateGreaterThan(_, _) -> false. > > %% Culls the list of vectors X to only those that are in the sphere > devined by vector C as a center and R as a radius. > cull(C, R, Vectors) when is_number(R), is_tuple(C) -> cull(C, R, Vectors, > []). > cull(C, R, Culled, []) -> Culled; > cull(C, R, Culled, [Head|Tail]) -> > D = subtract(C, Head), > case coordinateIsGreaterThan(R, Head) of > true -> cull(C, R, Culled, Tail); > false -> cullOnMagnitude(C, R, D, Culled, Head, Tail) > end. > > cullOnMagnitude(C, R, D, Culled, Head, Tail) when is_tuple(D), > is_number(R) -> > M = magnitude(D), > if M > R -> cull(C, R, Culled, Tail); > true -> cull(C, R, [Head | Culled], Tail) > end. > > When I load these into a file and compile them I get the following result: > > 16> c(vector3d). > vector3d.erl:53: function coordinateIsGreaterThan/2 undefined > vector3d.erl:45: Warning: function coordinateGreaterThan/2 is unused > vector3d.erl:50: Warning: variable 'C' is unused > vector3d.erl:50: Warning: variable 'R' is unused > > Note that there are some other methods in this file so the line numbers > will vary. My questions are: > > 1) Why is it saying my coordinateIsGreaterThan/2 method is undefined when > I can see it here and then to say it is unused in the next line? That seems > contradictory? > 2) Is this in the direction of the "erlang way" to do things? > 3) I understand the variables not being used but it seems odd to me from > the java language world to not define the names for the variables. Is this > normal in erlang? > > Thanks in advance. > > *Robert Simmons Jr. MSc.* > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 > * > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrtndimitrov@REDACTED Fri Feb 7 09:06:03 2014 From: mrtndimitrov@REDACTED (Martin Koroudjiev) Date: Fri, 07 Feb 2014 10:06:03 +0200 Subject: [erlang-questions] Erlang Solutions webinar "Understanding the Erlang Scheduler" Message-ID: <52F493EB.9040206@gmail.com> Hello, Unfortunately I missed it. Is it recorded anywhere? Thanks, Martin From vladdu55@REDACTED Fri Feb 7 09:29:12 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 7 Feb 2014 09:29:12 +0100 Subject: [erlang-questions] Indentation of multiline strings Message-ID: Hi, I got a question about a file that was indented in a strange way by the script I put together, and thus by the erlang-mode indenter, and the problem is related to multiline strings. I can't see any such strings in lib/tools/emacs/test.erl.*, and when looking at the erlang-indent functions it looks like it works line by line, meaning that there is no way that multiline strings will get handled properly. But I may be wrong, as it's been a long time since reading lisp code. What is the official position regarding indenting multiline strings? If the emacs indentation code is broken, it means one can't reindent files without risking trouble... regards, Vlad From zehongzheng2008@REDACTED Fri Feb 7 10:19:30 2014 From: zehongzheng2008@REDACTED (=?GBK?B?08O7pw==?=) Date: Fri, 7 Feb 2014 17:19:30 +0800 (CST) Subject: [erlang-questions] What is the difference between maps and dict in R17 Message-ID: <16eb8541.5280.1440ba50d11.Coremail.zehongzheng2008@163.com> Both of maps and dict are used as map, so when and where to use maps? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Fri Feb 7 10:35:22 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 7 Feb 2014 10:35:22 +0100 Subject: [erlang-questions] erl_scan:scan_dot issue Message-ID: Hi, This is something from at least R13, the git repository only goes that far. erl_scan:scan_dot contains these clauses scan_dot([$\n=C|Cs], St, Line, Col, Toks, Ncs) -> Attrs = attributes(Line, Col, St, Ncs++[C]), {ok,[{dot,Attrs}|Toks],Cs,Line+1,new_column(Col, 1)}; scan_dot([C|Cs], St, Line, Col, Toks, Ncs) when ?WHITE_SPACE(C) -> Attrs = attributes(Line, Col, St, Ncs++[C]), {ok,[{dot,Attrs}|Toks],Cs,Line,incr_column(Col, 2)}; Why is whitespace conflated with the dot in the token? I have an old version of the scanner that doesn't have these clauses and when I am now trying to use the OTP scanner, there are errors all over the place because of that.... best regards, Vlad From jarimatti.valkonen@REDACTED Fri Feb 7 08:39:56 2014 From: jarimatti.valkonen@REDACTED (Jarimatti Valkonen) Date: Fri, 7 Feb 2014 09:39:56 +0200 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> Message-ID: <74B30216-713A-41B2-9F79-84D55E4C92C8@saunalahti.fi> Richard A. O'Keefe kirjoitti 7.2.2014 kello 7.10: > I suppose I can mention Interlisp-D again? > An idea that had the Xerox PARC people jumping up and down > and hugging themselves in the 80s was > > A program is not a listing > > it's a data base. > > [snip] > Of course this is *wonderful*, but only as long as the only > tools you want to use are the ones built into the IDE or > readily scriptable in it. Interlisp was/Smalltalk is good > at navel-gazing, but each Smalltalk is, *sigh*, different... I've been having this idea in my head about something similar to a Smalltalk system browser, but for Erlang. Useful? I doubt it, but at least it would be an interesting experiment. A source editor is doable, but making it work on a live system is left as an exercise to the reader. :) Is anyone aware of anything similar? And yes, I don't see this solving the tab/space indentation discussion. From dmkolesnikov@REDACTED Fri Feb 7 12:09:58 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Fri, 7 Feb 2014 13:09:58 +0200 Subject: [erlang-questions] dets "undocumented" feature? Message-ID: <9827FC66-6095-4B7B-8254-53CB665CB857@gmail.com> Hello, I was constantly having a trouble with dets:open_file interface. open_file(Name, Args) -> {ok, Name} | {error, Reason} Name = atom() Using atom() as dets identifier is not always practical, however I see the major reasons behind it. Recently I?ve discovered that following statements works perfectly: {ok, R1} = dets:open_file(erlang:make_ref(), [{file, "/tmp/myfile"}, {access, read}]). This is ?long seemed? solution. When I need to temporary open dets file for reading. do you have any insides? how safe is that to put into production? Best Regards, Dmitry From donpedrothird@REDACTED Fri Feb 7 12:21:23 2014 From: donpedrothird@REDACTED (Evgeny M) Date: Fri, 7 Feb 2014 03:21:23 -0800 (PST) Subject: [erlang-questions] dets "undocumented" feature? In-Reply-To: <9827FC66-6095-4B7B-8254-53CB665CB857@gmail.com> References: <9827FC66-6095-4B7B-8254-53CB665CB857@gmail.com> Message-ID: <00985efd-4a95-49e2-bf23-98ba3d77bc10@googlegroups.com> Name = term() %%http://www.erlang.org/doc/man/dets.html#type-tab_name ???????, 7 ??????? 2014 ?., 15:09:58 UTC+4 ???????????? Dmitry Kolesnikov ???????: > > Hello, > > I was constantly having a trouble with dets:open_file interface. > > open_file(Name, Args) -> {ok, Name} | {error, Reason} > Name = atom() > > Using atom() as dets identifier is not always practical, however I see the > major reasons behind it. > > Recently I?ve discovered that following statements works perfectly: > > {ok, R1} = dets:open_file(erlang:make_ref(), [{file, "/tmp/myfile"}, > {access, read}]). > This is ?long seemed? solution. When I need to temporary open dets file > for reading. > > do you have any insides? how safe is that to put into production? > > Best Regards, > Dmitry > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Fri Feb 7 12:25:56 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Fri, 7 Feb 2014 13:25:56 +0200 Subject: [erlang-questions] dets "undocumented" feature? In-Reply-To: <00985efd-4a95-49e2-bf23-98ba3d77bc10@googlegroups.com> References: <9827FC66-6095-4B7B-8254-53CB665CB857@gmail.com> <00985efd-4a95-49e2-bf23-98ba3d77bc10@googlegroups.com> Message-ID: <79C416D4-13BE-4B90-9A8A-C824CB2A13A5@gmail.com> Ah, this is R16 feature! Thanks! - Dmitry On 07 Feb 2014, at 13:21, Evgeny M wrote: > Name = term() %%http://www.erlang.org/doc/man/dets.html#type-tab_name > > ???????, 7 ??????? 2014 ?., 15:09:58 UTC+4 ???????????? Dmitry Kolesnikov ???????: > Hello, > > I was constantly having a trouble with dets:open_file interface. > > open_file(Name, Args) -> {ok, Name} | {error, Reason} > Name = atom() > > Using atom() as dets identifier is not always practical, however I see the major reasons behind it. > > Recently I?ve discovered that following statements works perfectly: > > {ok, R1} = dets:open_file(erlang:make_ref(), [{file, "/tmp/myfile"}, {access, read}]). > This is ?long seemed? solution. When I need to temporary open dets file for reading. > > do you have any insides? how safe is that to put into production? > > Best Regards, > Dmitry > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas@REDACTED Fri Feb 7 12:20:19 2014 From: andreas@REDACTED (Andreas Schumacher) Date: Fri, 7 Feb 2014 12:20:19 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. Message-ID: <52F4C173.8050408@erlang.org> We changed the version scheme for two reasons: For the first, we abandoned the R-version scheme, since it has a meaning inside Ericsson that differs from how we used it; that caused some confusion. Secondly, we adapted a version scheme that allows us to bookkeep fine-grained patches on arbitrary OTP versions to our customers with support agreements. The new version scheme is *not* semantic versioning; although, it has been inspired by it. We do not want to use semantic versioning (as defined by http://semver.org/) out of the box since it does not fit our needs. Most importantly, we must be able branch out from any old version and also be able to do so multiple times. This is not possible when limited to only using MAJOR.MINOR.PATCH as version numbers. For example, if we have released 17.0, 17.0.1, and 17.0.2 we may have to release a patch based on 17.0.1. In this case it will be given the version 17.0.1.1. A new MAJOR release is denoted with .0, where is incremented by one at the delivery of a new major release, which may contain potential incompatibilities. A pre-release is denoted with .0-rc, where starts with 1 at the delivery of the first pre-release, and is incremented by one for each subsequent pre-release. "-rc0" will be used during development up to the first release candidate. Pre-releases -rc sort before . Apart from -rc, there are no plans for other special parts; although that might change if the need arises. A MINOR and/or PATCH (bug-fix) release is denoted with .., where: - is set to 0 when is incremented and is incremented by one when new (minor) functionality is released. is used even when == 0. - is set to 0 when or is incremented, and incremented by one when only bug fixes are released. is not used when == 0, unless [support patches] patches are based on that version; see below. Everything in a version V0 = .. is included in a version V1 = .. if V1 is greater than V0. V1 > V0 if Y1 > Y0 || (Y1 == Y0 && Z1 > Z0). The OTP major release and the complete OTP version can be retrieved from erlang code using the following: 1> erlang:system_info(otp_release). "17" 2> erlang:system_info(otp_correction_package). "17.0-rc1" NOTE: The name of the argument "otp_correction_package" will be changed to "otp_version." In addition, a corresponding flag "otp_version" will be added to the erl command, in order to allow the extraction of the complete version number from command line tools. Version changes in applications imply a version change on OTP level, but they are not propagated one-to-one; especially, a change of the major version of an application does not necessarily imply a change of the major version at the OTP level. The mapping is a case-by-case decision that depends on the application, the type of functionality, impacts on backward compatibility, etc. It is basically only the releases of the form .. that are of interest for the Erlang open source community. However, from OTP 17.0 we will only deliver source code releases [even to our customers with support agreements]; and thus, even traces of support-patch release-versions on top of those regular releases are going to be visible in the public Erlang/OTP Git repository. The following is a brief description of the format of those patch releases: When branching out, we add ".1" at the end of .., unless this version number has already been used. If it has already been used, we search for an unused version number by adding more and more ".0" between the version we are branching from, and the ".1" that we add at the end. For example, 17.0.1.1, 17.0.1.0.1, 17.0.1.0.0.1, and 17.0.1.0.0.0.1 are all versions of modifications based on version 17.0.1. When basing a patch or a feature on an already branched version that do not require any new branching, we increase the last part of the version. When versions have more than the ordinary three parts MAJOR.MINOR.PATCH, you cannot draw any conclusions about the specific modifications in the version, but you can see what the modifications are based on. The Erlang/OTP Team at Ericsson From donpedrothird@REDACTED Fri Feb 7 12:47:05 2014 From: donpedrothird@REDACTED (Evgeny M) Date: Fri, 7 Feb 2014 03:47:05 -0800 (PST) Subject: [erlang-questions] dets "undocumented" feature? In-Reply-To: <79C416D4-13BE-4B90-9A8A-C824CB2A13A5@gmail.com> References: <9827FC66-6095-4B7B-8254-53CB665CB857@gmail.com> <00985efd-4a95-49e2-bf23-98ba3d77bc10@googlegroups.com> <79C416D4-13BE-4B90-9A8A-C824CB2A13A5@gmail.com> Message-ID: It works at least from R15B1 ???????, 7 ??????? 2014 ?., 15:25:56 UTC+4 ???????????? Dmitry Kolesnikov ???????: > > Ah, this is R16 feature! Thanks! > > - Dmitry > > On 07 Feb 2014, at 13:21, Evgeny M > > wrote: > > Name = term() %%http://www.erlang.org/doc/man/dets.html#type-tab_name > > ???????, 7 ??????? 2014 ?., 15:09:58 UTC+4 ???????????? Dmitry Kolesnikov > ???????: >> >> Hello, >> >> I was constantly having a trouble with dets:open_file interface. >> >> open_file(Name, Args) -> {ok, Name} | {error, Reason} >> Name = atom() >> >> Using atom() as dets identifier is not always practical, however I see >> the major reasons behind it. >> >> Recently I?ve discovered that following statements works perfectly: >> >> {ok, R1} = dets:open_file(erlang:make_ref(), [{file, "/tmp/myfile"}, >> {access, read}]). >> This is ?long seemed? solution. When I need to temporary open dets file >> for reading. >> >> do you have any insides? how safe is that to put into production? >> >> Best Regards, >> Dmitry >> _______________________________________________ >> erlang-questions mailing list >> erlang-q...@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Feb 7 12:55:53 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 07 Feb 2014 12:55:53 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <52F4C173.8050408@erlang.org> References: <52F4C173.8050408@erlang.org> Message-ID: <52F4C9C9.2040601@ninenines.eu> Sounds good. One question though. Does that mean the current cycle of having a major release every year will be changed, or should we still more or less expect a new major at the beginning of the year and three or four minor releases after that? I hope that having source code only and a proper PATCH number will allow much faster release of fixes when a release is significantly broken (like for example the R16B03's syntax_tools application issue -- R16B03-1 took a long time to get released). On 02/07/2014 12:20 PM, Andreas Schumacher wrote: > We changed the version scheme for two reasons: For the first, we > abandoned the R-version scheme, since it has a meaning inside Ericsson > that differs from how we used it; that caused some confusion. Secondly, > we adapted a version scheme that allows us to bookkeep fine-grained > patches on arbitrary OTP versions to our customers with support agreements. > > The new version scheme is *not* semantic versioning; although, it has > been inspired by it. We do not want to use semantic versioning (as > defined by http://semver.org/) out of the box since it does not fit our > needs. Most importantly, we must be able branch out from any old version > and also be able to do so multiple times. This is not possible when > limited to only using MAJOR.MINOR.PATCH as version numbers. For example, > if we have released 17.0, 17.0.1, and 17.0.2 we may have to release a > patch based on 17.0.1. In this case it will be given the version 17.0.1.1. > > A new MAJOR release is denoted with .0, where is incremented by > one at the delivery of a new major release, which may contain potential > incompatibilities. > > A pre-release is denoted with .0-rc, where starts with 1 at > the delivery of the first pre-release, and is incremented by one for > each subsequent pre-release. "-rc0" will be used during development up > to the first release candidate. Pre-releases -rc sort before . > Apart from -rc, there are no plans for other special parts; > although that might change if the need arises. > > A MINOR and/or PATCH (bug-fix) release is denoted with .., where: > - is set to 0 when is incremented and is incremented by one when > new (minor) > functionality is released. is used even when == 0. > - is set to 0 when or is incremented, and incremented by one > when only bug > fixes are released. is not used when == 0, unless [support > patches] patches are based on that version; see below. > > Everything in a version V0 = .. is included in a version V1 = > .. if V1 is greater than V0. V1 > V0 if Y1 > Y0 || (Y1 == Y0 > && Z1 > Z0). > > The OTP major release and the complete OTP version can be retrieved from > erlang code using the following: > > 1> erlang:system_info(otp_release). > "17" > 2> erlang:system_info(otp_correction_package). > "17.0-rc1" > > NOTE: The name of the argument "otp_correction_package" will be changed > to "otp_version." In addition, a corresponding flag "otp_version" will > be added to the erl command, in order to allow the extraction of the > complete version number from command line tools. > > Version changes in applications imply a version change on OTP level, but > they are not propagated one-to-one; especially, a change of the major > version of an application does not necessarily imply a change of the > major version at the OTP level. The mapping is a case-by-case decision > that depends on the application, the type of functionality, impacts on > backward compatibility, etc. > > It is basically only the releases of the form .. that are of > interest for the Erlang open source community. However, from OTP 17.0 we > will only deliver source code releases [even to our customers with > support agreements]; and thus, even traces of support-patch > release-versions on top of those regular releases are going to be > visible in the public Erlang/OTP Git repository. The following is a > brief description of the format of those patch releases: > > When branching out, we add ".1" at the end of .., unless this > version number has already been used. If it has already been used, we > search for an unused version number by adding more and more ".0" between > the version we are branching from, and the ".1" that we add at the end. > For example, 17.0.1.1, 17.0.1.0.1, 17.0.1.0.0.1, and 17.0.1.0.0.0.1 are > all versions of modifications based on version 17.0.1. > > When basing a patch or a feature on an already branched version that do > not require any new branching, we increase the last part of the version. > > When versions have more than the ordinary three parts MAJOR.MINOR.PATCH, > you cannot > draw any conclusions about the specific modifications in the version, > but you can see what the modifications are based on. > > The Erlang/OTP Team at Ericsson > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Lo?c Hoguin http://ninenines.eu From vladdu55@REDACTED Fri Feb 7 12:58:46 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 7 Feb 2014 12:58:46 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <52F4C173.8050408@erlang.org> References: <52F4C173.8050408@erlang.org> Message-ID: Thank you very much for the versioning specification. It makes it all much clearer. Just a couple of details are still fuzzy for me: - release candidates will exist only for major relesess, right? - for patch releases, can we at least assume that there are no changes at the languageand beam level, that it that X.Y.Z.1.0.0.1 will be able to compile with the X.0 compiler and execute on a X.Y runtime (even if the results aren't the right ones in the latter case because of what was fixed in the patch)? best regards, Vlad On Fri, Feb 7, 2014 at 12:20 PM, Andreas Schumacher wrote: > We changed the version scheme for two reasons: For the first, we abandoned > the R-version scheme, since it has a meaning inside Ericsson that differs > from how we used it; that caused some confusion. Secondly, we adapted a > version scheme that allows us to bookkeep fine-grained patches on arbitrary > OTP versions to our customers with support agreements. > > The new version scheme is *not* semantic versioning; although, it has been > inspired by it. We do not want to use semantic versioning (as defined by > http://semver.org/) out of the box since it does not fit our needs. Most > importantly, we must be able branch out from any old version and also be > able to do so multiple times. This is not possible when limited to only > using MAJOR.MINOR.PATCH as version numbers. For example, if we have released > 17.0, 17.0.1, and 17.0.2 we may have to release a patch based on 17.0.1. In > this case it will be given the version 17.0.1.1. > > A new MAJOR release is denoted with .0, where is incremented by one > at the delivery of a new major release, which may contain potential > incompatibilities. > > A pre-release is denoted with .0-rc, where starts with 1 at the > delivery of the first pre-release, and is incremented by one for each > subsequent pre-release. "-rc0" will be used during development up to the > first release candidate. Pre-releases -rc sort before . Apart from > -rc, there are no plans for other special parts; although that might > change if the need arises. > > A MINOR and/or PATCH (bug-fix) release is denoted with .., where: > - is set to 0 when is incremented and is incremented by one when new > (minor) > functionality is released. is used even when == 0. > - is set to 0 when or is incremented, and incremented by one > when only bug > fixes are released. is not used when == 0, unless [support > patches] patches are based on that version; see below. > > Everything in a version V0 = .. is included in a version V1 = > .. if V1 is greater than V0. V1 > V0 if Y1 > Y0 || (Y1 == Y0 && > Z1 > Z0). > > The OTP major release and the complete OTP version can be retrieved from > erlang code using the following: > > 1> erlang:system_info(otp_release). > "17" > 2> erlang:system_info(otp_correction_package). > "17.0-rc1" > > NOTE: The name of the argument "otp_correction_package" will be changed to > "otp_version." In addition, a corresponding flag "otp_version" will be added > to the erl command, in order to allow the extraction of the complete version > number from command line tools. > > Version changes in applications imply a version change on OTP level, but > they are not propagated one-to-one; especially, a change of the major > version of an application does not necessarily imply a change of the major > version at the OTP level. The mapping is a case-by-case decision that > depends on the application, the type of functionality, impacts on backward > compatibility, etc. > > It is basically only the releases of the form .. that are of > interest for the Erlang open source community. However, from OTP 17.0 we > will only deliver source code releases [even to our customers with support > agreements]; and thus, even traces of support-patch release-versions on top > of those regular releases are going to be visible in the public Erlang/OTP > Git repository. The following is a brief description of the format of those > patch releases: > > When branching out, we add ".1" at the end of .., unless this > version number has already been used. If it has already been used, we search > for an unused version number by adding more and more ".0" between the > version we are branching from, and the ".1" that we add at the end. For > example, 17.0.1.1, 17.0.1.0.1, 17.0.1.0.0.1, and 17.0.1.0.0.0.1 are all > versions of modifications based on version 17.0.1. > > When basing a patch or a feature on an already branched version that do not > require any new branching, we increase the last part of the version. > > When versions have more than the ordinary three parts MAJOR.MINOR.PATCH, you > cannot > draw any conclusions about the specific modifications in the version, but > you can see what the modifications are based on. > > The Erlang/OTP Team at Ericsson > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From max.lapshin@REDACTED Fri Feb 7 13:03:34 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Fri, 7 Feb 2014 16:03:34 +0400 Subject: [erlang-questions] Erlang on Tilera: 40 Gbps throughput Message-ID: I want to thank all people who are making Erlang fast and really cool. Latests tests on bunch of Tilera cards gave 40 gbit/s throughput through flussonic (former erlyvideo) streaming server. On this speed flussonic is not only pushing segments to sockets, but also makes session accounting, calculates bytes, track users, write logs to different databases, periodically rechecks authorization, etc. So it is not a dumb proxy, it does some work on all 36 cores. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Fri Feb 7 13:04:26 2014 From: ulf@REDACTED (Ulf Wiger) Date: Fri, 7 Feb 2014 13:04:26 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <52F4C173.8050408@erlang.org> References: <52F4C173.8050408@erlang.org> Message-ID: <62E05066-21C3-434F-A725-D5B8614DA945@feuerlabs.com> On 07 Feb 2014, at 12:20, Andreas Schumacher wrote: > We changed the version scheme for two reasons [?] Hi Andreas, I?m happy to see that you have returned from the Dark Side. ;-) Welcome to the Erlang list. We also have cookies... BR, Ulf W -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas@REDACTED Fri Feb 7 13:24:23 2014 From: andreas@REDACTED (Andreas Schumacher) Date: Fri, 7 Feb 2014 13:24:23 +0100 Subject: [erlang-questions] FW: Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <58912684E2630B45963406CF7D8C52581C3423A4@ESESSMB103.ericsson.se> References: <52F4C173.8050408@erlang.org> <52F4C9C9.2040601@ninenines.eu> <58912684E2630B45963406CF7D8C52581C3423A4@ESESSMB103.ericsson.se> Message-ID: <52F4D077.3030900@erlang.org> The change of version scheme does not (necessarily) imply a change of the release cycle. The current plan is to release 17.0 in March and up to three additional OTP 17-based minor releases this year. When OTP 18.0 will be released has not been decided, yet. Indded, one of the (long-term) ambitions with moving to source code releases and an improved patch handling is to allow for a faster release procedure. Andreas > -----Original Message----- > From: Lo?c Hoguin [mailto:essen@REDACTED] > Sent: den 7 februari 2014 12:56 > To: Andreas Schumacher; erlang-questions@REDACTED > Subject: Re: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. > > Sounds good. > > One question though. Does that mean the current cycle of having a major > release every year will be changed, or should we still more or less > expect a new major at the beginning of the year and three or four minor > releases after that? > > I hope that having source code only and a proper PATCH number will allow > much faster release of fixes when a release is significantly broken > (like for example the R16B03's syntax_tools application issue -- > R16B03-1 took a long time to get released). > > On 02/07/2014 12:20 PM, Andreas Schumacher wrote: >> We changed the version scheme for two reasons: For the first, we >> abandoned the R-version scheme, since it has a meaning inside Ericsson >> that differs from how we used it; that caused some confusion. Secondly, >> we adapted a version scheme that allows us to bookkeep fine-grained >> patches on arbitrary OTP versions to our customers with support agreements. >> >> The new version scheme is *not* semantic versioning; although, it has >> been inspired by it. We do not want to use semantic versioning (as >> defined by http://semver.org/) out of the box since it does not fit our >> needs. Most importantly, we must be able branch out from any old version >> and also be able to do so multiple times. This is not possible when >> limited to only using MAJOR.MINOR.PATCH as version numbers. For example, >> if we have released 17.0, 17.0.1, and 17.0.2 we may have to release a >> patch based on 17.0.1. In this case it will be given the version 17.0.1.1. >> >> A new MAJOR release is denoted with .0, where is incremented by >> one at the delivery of a new major release, which may contain potential >> incompatibilities. >> >> A pre-release is denoted with .0-rc, where starts with 1 at >> the delivery of the first pre-release, and is incremented by one for >> each subsequent pre-release. "-rc0" will be used during development up >> to the first release candidate. Pre-releases -rc sort before . >> Apart from -rc, there are no plans for other special parts; >> although that might change if the need arises. >> >> A MINOR and/or PATCH (bug-fix) release is denoted with .., where: >> - is set to 0 when is incremented and is incremented by one when >> new (minor) >> functionality is released. is used even when == 0. >> - is set to 0 when or is incremented, and incremented by one >> when only bug >> fixes are released. is not used when == 0, unless [support >> patches] patches are based on that version; see below. >> >> Everything in a version V0 = .. is included in a version V1 = >> .. if V1 is greater than V0. V1 > V0 if Y1 > Y0 || (Y1 == Y0 >> && Z1 > Z0). >> >> The OTP major release and the complete OTP version can be retrieved from >> erlang code using the following: >> >> 1> erlang:system_info(otp_release). >> "17" >> 2> erlang:system_info(otp_correction_package). >> "17.0-rc1" >> >> NOTE: The name of the argument "otp_correction_package" will be changed >> to "otp_version." In addition, a corresponding flag "otp_version" will >> be added to the erl command, in order to allow the extraction of the >> complete version number from command line tools. >> >> Version changes in applications imply a version change on OTP level, but >> they are not propagated one-to-one; especially, a change of the major >> version of an application does not necessarily imply a change of the >> major version at the OTP level. The mapping is a case-by-case decision >> that depends on the application, the type of functionality, impacts on >> backward compatibility, etc. >> >> It is basically only the releases of the form .. that are of >> interest for the Erlang open source community. However, from OTP 17.0 we >> will only deliver source code releases [even to our customers with >> support agreements]; and thus, even traces of support-patch >> release-versions on top of those regular releases are going to be >> visible in the public Erlang/OTP Git repository. The following is a >> brief description of the format of those patch releases: >> >> When branching out, we add ".1" at the end of .., unless this >> version number has already been used. If it has already been used, we >> search for an unused version number by adding more and more ".0" between >> the version we are branching from, and the ".1" that we add at the end. >> For example, 17.0.1.1, 17.0.1.0.1, 17.0.1.0.0.1, and 17.0.1.0.0.0.1 are >> all versions of modifications based on version 17.0.1. >> >> When basing a patch or a feature on an already branched version that do >> not require any new branching, we increase the last part of the version. >> >> When versions have more than the ordinary three parts MAJOR.MINOR.PATCH, >> you cannot >> draw any conclusions about the specific modifications in the version, >> but you can see what the modifications are based on. >> >> The Erlang/OTP Team at Ericsson >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions From desired.mta@REDACTED Fri Feb 7 13:29:38 2014 From: desired.mta@REDACTED (=?UTF-8?B?TW90aWVqdXMgSmFrxaF0eXM=?=) Date: Fri, 07 Feb 2014 13:29:38 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <52F4C173.8050408@erlang.org> References: <52F4C173.8050408@erlang.org> Message-ID: <52F4D1B2.6030701@gmail.com> 2014.02.07 12:20, Andreas Schumacher ra??: > > The OTP major release and the complete OTP version can be retrieved from > erlang code using the following: > > 1> erlang:system_info(otp_release). > "17" > 2> erlang:system_info(otp_correction_package). > "17.0-rc1" > > NOTE: The name of the argument "otp_correction_package" will be changed > to "otp_version." In addition, a corresponding flag "otp_version" will > be added to the erl command, in order to allow the extraction of the > complete version number from command line tools. Any plans to support ?OTP_RELEASE and ?OTP_VERSION? This would give us ability to portably* create portable applications. Regards, Motiejus [*]: now these constants are set by build system (rebar, Makefiles). From hm@REDACTED Fri Feb 7 13:37:43 2014 From: hm@REDACTED (=?ISO-8859-1?Q?H=E5kan_Mattsson?=) Date: Fri, 7 Feb 2014 13:37:43 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <52F4C173.8050408@erlang.org> References: <52F4C173.8050408@erlang.org> Message-ID: On Fri, Feb 7, 2014 at 12:20 PM, Andreas Schumacher wrote: > A new MAJOR release is denoted with .0, where is incremented by one > at the delivery of a new major release, which may contain potential > incompatibilities. > The OTP major release and the complete OTP version can be retrieved from > erlang code using the following: > > 1> erlang:system_info(otp_release). > "17" Should be "17.0"? /H?kan From jesper.louis.andersen@REDACTED Fri Feb 7 13:38:39 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 7 Feb 2014 13:38:39 +0100 Subject: [erlang-questions] What is the difference between maps and dict in R17 In-Reply-To: <16eb8541.5280.1440ba50d11.Coremail.zehongzheng2008@163.com> References: <16eb8541.5280.1440ba50d11.Coremail.zehongzheng2008@163.com> Message-ID: In the long run, maps may probably subsume dict and gb_trees. In the short term they won't since maps currently is not optimized for a large number of keys. On Fri, Feb 7, 2014 at 10:19 AM, ?? wrote: > Both of maps and dict are used as map, so when and where to use maps? > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Fri Feb 7 13:39:00 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 7 Feb 2014 07:39:00 -0500 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <52F4D1B2.6030701@gmail.com> References: <52F4C173.8050408@erlang.org> <52F4D1B2.6030701@gmail.com> Message-ID: <20140207123900.GH48745@ferdmbp.local> Always be wary of these macros, because custom releases set by users can pick and match versions of applications from multiple releases and build a new release to develop from, and then spin off more and more releases. In this case, the macros are suddenly worthless or not representative of the true dependency you are expressing -- the one on individual application versions within an OTP release. On 02/07, Motiejus Jak?tys wrote: > 2014.02.07 12:20, Andreas Schumacher ra??: > > > > The OTP major release and the complete OTP version can be retrieved from > > erlang code using the following: > > > > 1> erlang:system_info(otp_release). > > "17" > > 2> erlang:system_info(otp_correction_package). > > "17.0-rc1" > > > > NOTE: The name of the argument "otp_correction_package" will be changed > > to "otp_version." In addition, a corresponding flag "otp_version" will > > be added to the erl command, in order to allow the extraction of the > > complete version number from command line tools. > > Any plans to support ?OTP_RELEASE and ?OTP_VERSION? > > This would give us ability to portably* create portable applications. > > Regards, > Motiejus > > [*]: now these constants are set by build system (rebar, Makefiles). > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From desired.mta@REDACTED Fri Feb 7 13:44:32 2014 From: desired.mta@REDACTED (=?UTF-8?B?TW90aWVqdXMgSmFrxaF0eXM=?=) Date: Fri, 07 Feb 2014 13:44:32 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <20140207123900.GH48745@ferdmbp.local> References: <52F4C173.8050408@erlang.org> <52F4D1B2.6030701@gmail.com> <20140207123900.GH48745@ferdmbp.local> Message-ID: <52F4D530.3020409@gmail.com> 2014.02.07 13:39, Fred Hebert ra??: > In this case, the macros are suddenly worthless or not representative > of the true dependency you are expressing -- the one on individual > application versions within an OTP release. I understand the argument; if that happens, we would end up with a User-Agent mess. Thankfully, there are not many Erlang vendors these days. However, the same argument applies to erlang:system_info(otp_release) and erlang:system_info(otp_version). Having these values in macros just make this information more easily available. So I would say: all or nothing? Motiejus From jesper.louis.andersen@REDACTED Fri Feb 7 13:47:22 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 7 Feb 2014 13:47:22 +0100 Subject: [erlang-questions] Maps & records: binding directly to bitstring comprehensions In-Reply-To: References: Message-ID: On Thu, Feb 6, 2014 at 11:35 PM, Felix Gallo wrote: > I live in a world of pain wherein I receive 4K binary blob packets with a > tightly packed schema that changes every few weeks. For what it is worth, this is the root cause of the problem. If you have a packet format that changes this often, you are probably better off improving the packet encoding scheme than trying to parse it and adapt. You need a format which has more framing so it can be parsed by recursively stripping off more and more information. That is, you can decode the packet partially and skip sections your parser doesn't understand yet. Also beware coding complexity. If data is never placed at rest on disk, then struggling to compress data with an intricate scheme is not going to buy you anything since there tend to be enough bandwidth for these kind of things. Decoding is going to dwarf everything else[0]. I would probably just wait a bit until the format settles and then go implement it there. [0] This describes almost everything that is wrong with JSON. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Feb 7 13:56:57 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 07 Feb 2014 13:56:57 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <52F4D530.3020409@gmail.com> References: <52F4C173.8050408@erlang.org> <52F4D1B2.6030701@gmail.com> <20140207123900.GH48745@ferdmbp.local> <52F4D530.3020409@gmail.com> Message-ID: <52F4D819.3040804@ninenines.eu> On 02/07/2014 01:44 PM, Motiejus Jak?tys wrote: > 2014.02.07 13:39, Fred Hebert ra??: >> In this case, the macros are suddenly worthless or not representative >> of the true dependency you are expressing -- the one on individual >> application versions within an OTP release. > > I understand the argument; if that happens, we would end up with a > User-Agent mess. Thankfully, there are not many Erlang vendors these days. > > However, the same argument applies to erlang:system_info(otp_release) > and erlang:system_info(otp_version). Having these values in macros just > make this information more easily available. > > So I would say: all or nothing? These shouldn't be used the way you describe. It's not about Erlang vendors, it's about what users put in their releases. If someone uses your project in their release, and also had to update, say, the ssl application to fix a bug (this happens all the time!), your project may suddenly break. Instead you should use this value: 1> App = kernel. kernel 2> application:get_key(App, vsn). {ok,"2.16.3"} -- Lo?c Hoguin http://ninenines.eu From desired.mta@REDACTED Fri Feb 7 14:08:16 2014 From: desired.mta@REDACTED (=?UTF-8?B?TW90aWVqdXMgSmFrxaF0eXM=?=) Date: Fri, 07 Feb 2014 14:08:16 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <52F4D819.3040804@ninenines.eu> References: <52F4C173.8050408@erlang.org> <52F4D1B2.6030701@gmail.com> <20140207123900.GH48745@ferdmbp.local> <52F4D530.3020409@gmail.com> <52F4D819.3040804@ninenines.eu> Message-ID: <52F4DAC0.1070305@gmail.com> 2014.02.07 13:56, Lo?c Hoguin ra??: > > These shouldn't be used the way you describe. It's not about Erlang > vendors, it's about what users put in their releases. If someone uses > your project in their release, and also had to update, say, the ssl > application to fix a bug (this happens all the time!), your project may > suddenly break. OK. > Instead you should use this value: > > 1> App = kernel. > kernel > 2> application:get_key(App, vsn). > {ok,"2.16.3"} This is valid, but works when it is possible and not crazily expensive to do this at runtime. My use case is a library which has -callback support. Should we generate behaviours using behaviour_info/1 or -callback (pre-R15 or R15+)? Sure, we can take the cowboy approach (pun intended): do not support legacy OTP versions. But what if I can and want to, and that's the only thing keeping users with R13B04 away from my library? Our current solution: put an ifdef in the file which exports the headers. Now that macro has to be set by the build system. On the other hand, when thinking about it, I cannot come up with another example where having the macro would be that necessary during compile time. There are not many useful constructs since R15B. Motiejus From dch@REDACTED Fri Feb 7 14:15:29 2014 From: dch@REDACTED (Dave Cottlehuber) Date: Fri, 7 Feb 2014 14:15:29 +0100 Subject: [erlang-questions] building R14B04 64-bit in OSX 10.9.1 Mavericks with clang In-Reply-To: References: Message-ID: Thanks Mark, Your tool (and more importantly the associated patches for R14B04) work like a treat and I can build using clang. With a bit of kludging and ./Install work it now works with `kerl` activation too. Many thanks. A+ Dave From vladdu55@REDACTED Fri Feb 7 14:20:26 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 7 Feb 2014 14:20:26 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <52F4DAC0.1070305@gmail.com> References: <52F4C173.8050408@erlang.org> <52F4D1B2.6030701@gmail.com> <20140207123900.GH48745@ferdmbp.local> <52F4D530.3020409@gmail.com> <52F4D819.3040804@ninenines.eu> <52F4DAC0.1070305@gmail.com> Message-ID: On Fri, Feb 7, 2014 at 2:08 PM, Motiejus Jak?tys wrote: > This is valid, but works when it is possible and not crazily expensive > to do this at runtime. My use case is a library which has -callback > support. Should we generate behaviours using behaviour_info/1 or > -callback (pre-R15 or R15+)? Sure, we can take the cowboy approach (pun > intended): do not support legacy OTP versions. But what if I can and > want to, and that's the only thing keeping users with R13B04 away from > my library? So what would really be useful to have is a macro (and maybe runtime function on the compiler) that specifies the "source code level". This way one doesn't have to keep track of which versions have relevant changes at the language level. I'd find those useful too (the runtime value is useful if compiling code from strings/binaries without preprocessing). regards, Vlad From essen@REDACTED Fri Feb 7 14:23:31 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 07 Feb 2014 14:23:31 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <52F4DAC0.1070305@gmail.com> References: <52F4C173.8050408@erlang.org> <52F4D1B2.6030701@gmail.com> <20140207123900.GH48745@ferdmbp.local> <52F4D530.3020409@gmail.com> <52F4D819.3040804@ninenines.eu> <52F4DAC0.1070305@gmail.com> Message-ID: <52F4DE53.6080302@ninenines.eu> On 02/07/2014 02:08 PM, Motiejus Jak?tys wrote: >> Instead you should use this value: >> >> 1> App = kernel. >> kernel >> 2> application:get_key(App, vsn). >> {ok,"2.16.3"} > > This is valid, but works when it is possible and not crazily expensive > to do this at runtime. Well it *is* cheap and you can also keep it in your state as the only time it may change is during a release upgrade. > My use case is a library which has -callback > support. Should we generate behaviours using behaviour_info/1 or > -callback (pre-R15 or R15+)? Sure, we can take the cowboy approach (pun > intended): do not support legacy OTP versions. But what if I can and > want to, and that's the only thing keeping users with R13B04 away from > my library? Cowboy does R15B01+. Not even R15B. The reason is that many things simply do not work at all in R15B and lower, regardless of -callback use. R15B01 is only slightly better as there are still various ssl issues, and to be honest I got a couple test case failing that I still need to look at, and depending on what I find I may be forced to just drop that version. The code compiling on an older version is great, but not enough to determine that your code actually works with it. You could always take the approach the OTP team does. Support current version + 2 versions back. Since R17 is coming soon, that means you can drop R14 without worrying about it. R14 people can always use an older version of your application. -- Lo?c Hoguin http://ninenines.eu From vinoski@REDACTED Fri Feb 7 14:38:02 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Fri, 7 Feb 2014 08:38:02 -0500 Subject: [erlang-questions] Indentation of multiline strings In-Reply-To: References: Message-ID: On Fri, Feb 7, 2014 at 3:29 AM, Vlad Dumitrescu wrote: > Hi, > > I got a question about a file that was indented in a strange way by > the script I put together, and thus by the erlang-mode indenter, and > the problem is related to multiline strings. > > I can't see any such strings in lib/tools/emacs/test.erl.*, and when > looking at the erlang-indent functions it looks like it works line by > line, meaning that there is no way that multiline strings will get > handled properly. But I may be wrong, as it's been a long time since > reading lisp code. > Emacs erlang-mode doesn't get some multi-line entities like strings and binaries right. See this message and the associated thread: http://erlang.org/pipermail/erlang-bugs/2013-August/003729.html The fix isn't trivial, and for those of us who use emacs, these entities appear so rarely in practice that manually indenting them properly takes little effort. > What is the official position regarding indenting multiline strings? > If the emacs indentation code is broken, it means one can't reindent > files without risking trouble... You're trying to automate something that until now has not been automated, at least not in public view to the best of my knowledge, so you're going to hit problems like these. From what I've seen, users currently tend to indent these problem areas manually so that they appear the way they would if erlang-mode got them right. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Fri Feb 7 14:49:40 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Fri, 7 Feb 2014 08:49:40 -0500 Subject: [erlang-questions] OTP-compliant patches In-Reply-To: References: Message-ID: On Fri, Feb 7, 2014 at 2:42 AM, Vlad Dumitrescu wrote: > Hi, > > Just so that I make sure I understand correctly, in the light of the > flame war that I recently started :-\ > > The documentation says > > > Make sure your changes follow the coding and indentation style of the > code surrounding your > > changes. (At some point in the future, there will be a style guide, > either included in the > > documentation or on some web site, but it is not ready yet.) > > So if the local indentation is not what erlang-mode would give, then I > still have to manually adjust it to match what already was there. Is > that correct? > IMO yes, that's correct. BTW this approach is typical of most software projects -- I recall being taken to task for breaking this rule way back in 1987, a lesson I've never forgotten. > Since I've had some diff look ok in emacs but not on github (or the > other way around, I don't remember exactly), which one is the > reference in case of mismatch? > Of course, the typical reason for edits looking incorrect on github is using spaces where you need tabs for vice versa. Unfortunately, some files use a mixture of tabs and spaces, with some lines using tabs for leading whitespace and others using only spaces. My approach of dynamically setting the emacs indent-tabs-mode variable locally in the buffer based on searching the file for leading tabs upon opening it often works but isn't foolproof, since localized areas of the file might use spaces rather than tabs or vice versa. The only way I'm aware of to be fully sure that I'm respecting existing whitespace practices in the files I edit is to visually check the diffs. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From sedrik@REDACTED Fri Feb 7 14:53:22 2014 From: sedrik@REDACTED (Fredrik Andersson) Date: Fri, 7 Feb 2014 14:53:22 +0100 Subject: [erlang-questions] erl_tidy and specs Message-ID: Hi all In light of the recent indentation flamewar I thought about looking for something that could become our version of go fmt and stumbled across erl_tidy (http://erlang.org/doc/man/erl_tidy.html). Now it looks good but seems to be old as it does not handle specs correctly. Given the following file. -module(spec_error). -export([spec_error_fun/0]). -spec spec_error_fun() -> ok. spec_error_fun() -> ok. after calling erl_tidy:dir() in the directory where it resides I get the following. -module(spec_error). -export([spec_error_fun/0]). -spec({{spec_error_fun, 0}, [{type, 5, 'fun', [{type, 5, product, []}, {atom, 5, ok}]}]}). spec_error_fun() -> ok. Is this expected or is it a bug? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sedrik@REDACTED Fri Feb 7 14:53:47 2014 From: sedrik@REDACTED (Fredrik Andersson) Date: Fri, 7 Feb 2014 14:53:47 +0100 Subject: [erlang-questions] erl_tidy and specs In-Reply-To: References: Message-ID: Oh, btw. this is on R15B03 On Fri, Feb 7, 2014 at 2:53 PM, Fredrik Andersson wrote: > Hi all > > In light of the recent indentation flamewar I thought about looking for > something that could become our version of go fmt and stumbled across > erl_tidy (http://erlang.org/doc/man/erl_tidy.html). > > Now it looks good but seems to be old as it does not handle specs > correctly. > > Given the following file. > -module(spec_error). > > -export([spec_error_fun/0]). > > -spec spec_error_fun() -> ok. > spec_error_fun() -> > ok. > > after calling erl_tidy:dir() in the directory where it resides I get the > following. > > -module(spec_error). > > -export([spec_error_fun/0]). > > -spec({{spec_error_fun, 0}, > [{type, 5, 'fun', > [{type, 5, product, []}, {atom, 5, ok}]}]}). > > spec_error_fun() -> ok. > > Is this expected or is it a bug? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas@REDACTED Fri Feb 7 14:58:51 2014 From: andreas@REDACTED (Andreas Schumacher) Date: Fri, 7 Feb 2014 14:58:51 +0100 Subject: [erlang-questions] FW: Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <58912684E2630B45963406CF7D8C52581C3423AB@ESESSMB103.ericsson.se> References: <52F4C173.8050408@erlang.org> <58912684E2630B45963406CF7D8C52581C3423AB@ESESSMB103.ericsson.se> Message-ID: <52F4E69B.5050901@erlang.org> Right now, release candidates are only planned for major releases. For patch releases: In theory, you can not assume that there are no changes to the language and beam level in a patch release. In practice, you may want to assume it; AFAIK, there hasn't been such a change in a patch release. Andreas On 02/07/2014 01:10 PM, Andreas Schumacher wrote: > > -----Original Message----- > From: Vlad Dumitrescu [mailto:vladdu55@REDACTED] > Sent: den 7 februari 2014 12:59 > To: Andreas Schumacher > Cc: erlang-questions > Subject: Re: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. > > Thank you very much for the versioning specification. It makes it all > much clearer. > > Just a couple of details are still fuzzy for me: > > - release candidates will exist only for major relesess, right? > > - for patch releases, can we at least assume that there are no changes > at the languageand beam level, that it that X.Y.Z.1.0.0.1 will be able > to compile with the X.0 compiler and execute on a X.Y runtime (even if > the results aren't the right ones in the latter case because of what > was fixed in the patch)? > > best regards, > Vlad > > > On Fri, Feb 7, 2014 at 12:20 PM, Andreas Schumacher wrote: >> We changed the version scheme for two reasons: For the first, we abandoned >> the R-version scheme, since it has a meaning inside Ericsson that differs >> from how we used it; that caused some confusion. Secondly, we adapted a >> version scheme that allows us to bookkeep fine-grained patches on arbitrary >> OTP versions to our customers with support agreements. >> >> The new version scheme is *not* semantic versioning; although, it has been >> inspired by it. We do not want to use semantic versioning (as defined by >> http://semver.org/) out of the box since it does not fit our needs. Most >> importantly, we must be able branch out from any old version and also be >> able to do so multiple times. This is not possible when limited to only >> using MAJOR.MINOR.PATCH as version numbers. For example, if we have released >> 17.0, 17.0.1, and 17.0.2 we may have to release a patch based on 17.0.1. In >> this case it will be given the version 17.0.1.1. >> >> A new MAJOR release is denoted with .0, where is incremented by one >> at the delivery of a new major release, which may contain potential >> incompatibilities. >> >> A pre-release is denoted with .0-rc, where starts with 1 at the >> delivery of the first pre-release, and is incremented by one for each >> subsequent pre-release. "-rc0" will be used during development up to the >> first release candidate. Pre-releases -rc sort before . Apart from >> -rc, there are no plans for other special parts; although that might >> change if the need arises. >> >> A MINOR and/or PATCH (bug-fix) release is denoted with .., where: >> - is set to 0 when is incremented and is incremented by one when new >> (minor) >> functionality is released. is used even when == 0. >> - is set to 0 when or is incremented, and incremented by one >> when only bug >> fixes are released. is not used when == 0, unless [support >> patches] patches are based on that version; see below. >> >> Everything in a version V0 = .. is included in a version V1 = >> .. if V1 is greater than V0. V1 > V0 if Y1 > Y0 || (Y1 == Y0 && >> Z1 > Z0). >> >> The OTP major release and the complete OTP version can be retrieved from >> erlang code using the following: >> >> 1> erlang:system_info(otp_release). >> "17" >> 2> erlang:system_info(otp_correction_package). >> "17.0-rc1" >> >> NOTE: The name of the argument "otp_correction_package" will be changed to >> "otp_version." In addition, a corresponding flag "otp_version" will be added >> to the erl command, in order to allow the extraction of the complete version >> number from command line tools. >> >> Version changes in applications imply a version change on OTP level, but >> they are not propagated one-to-one; especially, a change of the major >> version of an application does not necessarily imply a change of the major >> version at the OTP level. The mapping is a case-by-case decision that >> depends on the application, the type of functionality, impacts on backward >> compatibility, etc. >> >> It is basically only the releases of the form .. that are of >> interest for the Erlang open source community. However, from OTP 17.0 we >> will only deliver source code releases [even to our customers with support >> agreements]; and thus, even traces of support-patch release-versions on top >> of those regular releases are going to be visible in the public Erlang/OTP >> Git repository. The following is a brief description of the format of those >> patch releases: >> >> When branching out, we add ".1" at the end of .., unless this >> version number has already been used. If it has already been used, we search >> for an unused version number by adding more and more ".0" between the >> version we are branching from, and the ".1" that we add at the end. For >> example, 17.0.1.1, 17.0.1.0.1, 17.0.1.0.0.1, and 17.0.1.0.0.0.1 are all >> versions of modifications based on version 17.0.1. >> >> When basing a patch or a feature on an already branched version that do not >> require any new branching, we increase the last part of the version. >> >> When versions have more than the ordinary three parts MAJOR.MINOR.PATCH, you >> cannot >> draw any conclusions about the specific modifications in the version, but >> you can see what the modifications are based on. >> >> The Erlang/OTP Team at Ericsson >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions From vladdu55@REDACTED Fri Feb 7 15:09:25 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 7 Feb 2014 15:09:25 +0100 Subject: [erlang-questions] Indentation of multiline strings In-Reply-To: References: Message-ID: Hi Steve, On Fri, Feb 7, 2014 at 2:38 PM, Steve Vinoski wrote: > On Fri, Feb 7, 2014 at 3:29 AM, Vlad Dumitrescu wrote: >> What is the official position regarding indenting multiline strings? >> If the emacs indentation code is broken, it means one can't reindent >> files without risking trouble... > > > You're trying to automate something that until now has not been automated, > at least not in public view to the best of my knowledge, so you're going to > hit problems like these. From what I've seen, users currently tend to indent > these problem areas manually so that they appear the way they would if > erlang-mode got them right. Well, yes, I am trying to provide tools that will help people focus on what is important instead of having to remember which files can be reindented and which one can't (for example). Tools that work as expected, without nasty effects that may only be noticed later. The kind of tools that Joe and others asked for. If people are happy doing this kind of manual work, please let me know so that I can work on something more useful, but please don't say later that "the tools are crap". In order to be able to do that, there has to be a specification, so that people know what to expect. In this particular case, that specification would be an official indentation and formatting guide, that in practice would become the standard way of doing it. The current situation is that the emacs implementation is that specification (for indenting), except that it has some cases where it doesn't work. There are also some Erlang pretty printers (erl_prettypr, erl_tidy), but these have their problems too as they rely on the code to be parsable and I don't know how much their output matches that of the emacs indenter and with each other. Wouldn't it be nice if there was an implementation independent specification? I am willing to put one together. This will make it much easier to make sure that the erlang support for different editors and IDEs is formatting the code in the same way and we can take the opportunity to specify (and maybe even implement) all the edge cases that emacs gets wrong. regards, Vlad From kraythe@REDACTED Fri Feb 7 15:47:36 2014 From: kraythe@REDACTED (kraythe .) Date: Fri, 7 Feb 2014 08:47:36 -0600 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: Message-ID: Man I feel silly. but then I am fighting a chest cold. I guess this happens easier when you don't have completion or highlighting that I am used to in an IDE. *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* *Author of: Hardcore Java (2003) and Maintainable Java (2012)* *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 * On Fri, Feb 7, 2014 at 1:27 AM, Vlad Dumitrescu wrote: > Hi, > > On Fri, Feb 7, 2014 at 8:25 AM, kraythe . wrote: > > coordinateGreaterThan(V, {X, Y, Z}) when X > V; Y > V; Z > V -> true; > > coordinateGreaterThan(_, _) -> false. > > > > %% Culls the list of vectors X to only those that are in the sphere > devined > > by vector C as a center and R as a radius. > > cull(C, R, Vectors) when is_number(R), is_tuple(C) -> cull(C, R, Vectors, > > []). > > cull(C, R, Culled, []) -> Culled; > > cull(C, R, Culled, [Head|Tail]) -> > > D = subtract(C, Head), > > case coordinateIsGreaterThan(R, Head) of > > true -> cull(C, R, Culled, Tail); > > > > 1) Why is it saying my coordinateIsGreaterThan/2 method is undefined > when I > > can see it here and then to say it is unused in the next line? That seems > > contradictory? > > Look carefully and see that you define "coordinateGreaterThan" and > call "coordinateIsGreaterThan". > > regards, > Vlad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.goertzen@REDACTED Fri Feb 7 15:49:37 2014 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Fri, 7 Feb 2014 08:49:37 -0600 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: Message-ID: Regarding #2 You are using both "if" and "case" expressions for the same situation: case coordinateIsGreaterThan(R, Head) of true -> cull(C, R, Culled, Tail); false -> cullOnMagnitude(C, R, D, Culled, Head, Tail) end ... if M > R -> cull(C, R, Culled, Tail); true -> cull(C, R, [Head | Culled], Tail) end Many people find "case" easier to understand and less error prone than "if", and in this situation you can easily use "case" instead: case M > R of true -> cull(C, R, Culled, Tail); false -> cull(C, R, [Head | Culled], Tail) end "if" does have its uses, but "case" fits my needs 99% of the time. Other than that I think your code looks fine. Cheers, Dan. On Fri, Feb 7, 2014 at 1:25 AM, kraythe . wrote: > I am a newbie to erlang so please excuse the newbie questions. To learn > the language I have a use case, simply to take a vector C which defines the > center of a sphere with radius R and then cull a list of vectors and return > only the vectors in the sphere. A simple math problem the most efficient > method is to calculate the difference in C and a vector V and if any > component is greater than R then the vector can't be in the sphere, if not > then we have to do the expensive sort magnitude calculation. > > To this end I have created a simple set of functions: > -module(vector3d). > -author("rsimmons"). > > %% API > -export([subtract/2, magnitude/1, scale/2, cull/3]). > > %% Subtract the second vector from the first > subtract({X1, Y1, Z1}, {X2, Y2, Z2}) -> {(X1 - X2), (Y1 - Y2), (Z1 - Z2)}. > > %% Compute the magnitude of the vector > magnitude({X, Y, Z}) -> math:sqrt((X * X) + (Y * Y) + (Z * Z)). > > %% Determines if any coordinate in the given vector is bigger than the > passed in value V. > coordinateGreaterThan(V, {X, Y, Z}) when X > V; Y > V; Z > V -> true; > coordinateGreaterThan(_, _) -> false. > > %% Culls the list of vectors X to only those that are in the sphere > devined by vector C as a center and R as a radius. > cull(C, R, Vectors) when is_number(R), is_tuple(C) -> cull(C, R, Vectors, > []). > cull(C, R, Culled, []) -> Culled; > cull(C, R, Culled, [Head|Tail]) -> > D = subtract(C, Head), > case coordinateIsGreaterThan(R, Head) of > true -> cull(C, R, Culled, Tail); > false -> cullOnMagnitude(C, R, D, Culled, Head, Tail) > end. > > cullOnMagnitude(C, R, D, Culled, Head, Tail) when is_tuple(D), > is_number(R) -> > M = magnitude(D), > if M > R -> cull(C, R, Culled, Tail); > true -> cull(C, R, [Head | Culled], Tail) > end. > > When I load these into a file and compile them I get the following result: > > 16> c(vector3d). > vector3d.erl:53: function coordinateIsGreaterThan/2 undefined > vector3d.erl:45: Warning: function coordinateGreaterThan/2 is unused > vector3d.erl:50: Warning: variable 'C' is unused > vector3d.erl:50: Warning: variable 'R' is unused > > Note that there are some other methods in this file so the line numbers > will vary. My questions are: > > 1) Why is it saying my coordinateIsGreaterThan/2 method is undefined when > I can see it here and then to say it is unused in the next line? That seems > contradictory? > 2) Is this in the direction of the "erlang way" to do things? > 3) I understand the variables not being used but it seems odd to me from > the java language world to not define the names for the variables. Is this > normal in erlang? > > Thanks in advance. > > *Robert Simmons Jr. MSc.* > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 > * > > _______________________________________________ > 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 Fri Feb 7 15:52:55 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 7 Feb 2014 09:52:55 -0500 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: Message-ID: <20140207145254.GC62889@ferdair.local> It's not exactly helpful right now, but I would recommend you use what is more or less the standard way to write Erlang functions (methods are for other languages!) and use the following format: coordinate_greater_than(V, {X, Y, Z}) when .... This generally makes it easier to spot variables from functions and in my opinion makes the code a bit more readable, whether you use syntax highlighting or not. There's this old document from Ericsson on Erlang style guidelines: http://www.erlang.se/doc/programming_rules.shtml Some of them are more fluid than others and debatable, but they're very good guidelines to read and absorb no matter what. Regards, Fred. On 02/07, kraythe . wrote: > Man I feel silly. but then I am fighting a chest cold. I guess this happens > easier when you don't have completion or highlighting that I am used to in > an IDE. > > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* > *Author of: Hardcore Java (2003) and Maintainable Java (2012)* > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 > * > > > On Fri, Feb 7, 2014 at 1:27 AM, Vlad Dumitrescu wrote: > > > Hi, > > > > On Fri, Feb 7, 2014 at 8:25 AM, kraythe . wrote: > > > coordinateGreaterThan(V, {X, Y, Z}) when X > V; Y > V; Z > V -> true; > > > coordinateGreaterThan(_, _) -> false. > > > > > > %% Culls the list of vectors X to only those that are in the sphere > > devined > > > by vector C as a center and R as a radius. > > > cull(C, R, Vectors) when is_number(R), is_tuple(C) -> cull(C, R, Vectors, > > > []). > > > cull(C, R, Culled, []) -> Culled; > > > cull(C, R, Culled, [Head|Tail]) -> > > > D = subtract(C, Head), > > > case coordinateIsGreaterThan(R, Head) of > > > true -> cull(C, R, Culled, Tail); > > > > > > 1) Why is it saying my coordinateIsGreaterThan/2 method is undefined > > when I > > > can see it here and then to say it is unused in the next line? That seems > > > contradictory? > > > > Look carefully and see that you define "coordinateGreaterThan" and > > call "coordinateIsGreaterThan". > > > > regards, > > Vlad > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vinoski@REDACTED Fri Feb 7 16:27:43 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Fri, 7 Feb 2014 10:27:43 -0500 Subject: [erlang-questions] Indentation of multiline strings In-Reply-To: References: Message-ID: On Fri, Feb 7, 2014 at 9:09 AM, Vlad Dumitrescu wrote: > Hi Steve, > > On Fri, Feb 7, 2014 at 2:38 PM, Steve Vinoski wrote: > > On Fri, Feb 7, 2014 at 3:29 AM, Vlad Dumitrescu > wrote: > >> What is the official position regarding indenting multiline strings? > >> If the emacs indentation code is broken, it means one can't reindent > >> files without risking trouble... > > > > > > You're trying to automate something that until now has not been > automated, > > at least not in public view to the best of my knowledge, so you're going > to > > hit problems like these. From what I've seen, users currently tend to > indent > > these problem areas manually so that they appear the way they would if > > erlang-mode got them right. > > Well, yes, I am trying to provide tools that will help people focus on > what is important instead of having to remember which files can be > reindented and which one can't (for example). Tools that work as > expected, without nasty effects that may only be noticed later. The > kind of tools that Joe and others asked for. If people are happy doing > this kind of manual work, please let me know so that I can work on > something more useful, but please don't say later that "the tools are > crap". > It's not for me to decide whether people in general are happy or not with the current state of affairs. Rather, I'm just trying to answer your questions given my understanding of the current state of the emacs erlang-mode indentation capabilities, which I think is more informed than most, and also explain my own approach to patching Erlang/OTP code. My replies contain no explicit or implicit criticism of your work. In order to be able to do that, there has to be a specification, so > that people know what to expect. In this particular case, that > specification would be an official indentation and formatting guide, > that in practice would become the standard way of doing it. The > current situation is that the emacs implementation is that > specification (for indenting), except that it has some cases where it > doesn't work. There are also some Erlang pretty printers > (erl_prettypr, erl_tidy), but these have their problems too as they > rely on the code to be parsable and I don't know how much their output > matches that of the emacs indenter and with each other. > Understood -- this is just another way of saying what I said originally, which is that "you're trying to automate something that until now has not been automated." > Wouldn't it be nice if there was an implementation independent > specification? I am willing to put one together. This will make it > much easier to make sure that the erlang support for different editors > and IDEs is formatting the code in the same way and we can take the > opportunity to specify (and maybe even implement) all the edge cases > that emacs gets wrong. Yes, I understand the goal, and I provided my answers to your previous questions based on that understanding. I think it would be beneficial if we had a standard Erlang indentation tool independent of emacs, for exactly the reasons you mention. I'm quite happy to help as much as I can to achieve that goal. For me personally, it would relieve me of having to manually work around the incorrect indentation that users of editors other than emacs sometimes put in the sources (hi haters). First, let's assume there's general agreement in the community that emacs erlang-mode is the de facto standard for erlang code formatting, and is thus the starting point for developing a formatting specification. I believe you're basing your work on this assumption, Vlad, and if so I agree with that approach, but if not please correct me. Some might object to using erlang-mode as the starting point on the basis that other editors sometimes have a hard time formatting code the same way erlang-mode does, but I believe most of the OTP team and most of the Erlang community uses emacs and erlang-mode, so I view it as the most practical starting point. To create a formatting specification, I recommend that if you haven't done so already, start collecting cases like the multiline string and binary cases where erlang-mode fails, and report them as bugs against erlang-mode. Obviously this applies to anyone who wishes to help. To resolve those bugs, we may need to form a small group that can decide how erlang-mode should format the problematic cases. A good choice for volunteers here are the primary erlang-mode maintainer and some willing subset of those who have recently contributed code and patches to erlang-mode. As one of those people, I'm willing to help with that, and also willing to help resolve the bugs in erlang-mode so it conforms to the specification you're putting together. I assume that during this effort someone -- probably you Vlad, but I know of other parties also interested -- would be writing a new tool that also conforms to the formatting specification. Having such a tool would give us at least two independent implementations of the spec. The resulting spec would then become part of Erlang/OTP and would be administered and maintained by the OTP team, same as the rest of the code, and it would have tests to prevent regressions. Bugs and extensions would be handled via the normal patch process. What am I missing? --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Fri Feb 7 16:33:08 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 7 Feb 2014 16:33:08 +0100 Subject: [erlang-questions] erl_tidy and specs In-Reply-To: References: Message-ID: <4E2E1725-EE2B-47B1-A377-D605E4B2CC2D@gmail.com> Yeah it is expected. Syntax_tools pretty-printing of Dialyzer-related attributes could be improved, but it requires a lot of new functions, as they are currently dumbed down to tuples. -- Anthony Ramine Le 7 f?vr. 2014 ? 14:53, Fredrik Andersson a ?crit : > Hi all > > In light of the recent indentation flamewar I thought about looking for something that could become our version of go fmt and stumbled across erl_tidy (http://erlang.org/doc/man/erl_tidy.html). > > Now it looks good but seems to be old as it does not handle specs correctly. > > Given the following file. > -module(spec_error). > > -export([spec_error_fun/0]). > > -spec spec_error_fun() -> ok. > spec_error_fun() -> > ok. > > after calling erl_tidy:dir() in the directory where it resides I get the following. > > -module(spec_error). > > -export([spec_error_fun/0]). > > -spec({{spec_error_fun, 0}, > [{type, 5, 'fun', > [{type, 5, product, []}, {atom, 5, ok}]}]}). > > spec_error_fun() -> ok. > > Is this expected or is it a bug? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From g@REDACTED Fri Feb 7 16:35:54 2014 From: g@REDACTED (Garrett Smith) Date: Fri, 7 Feb 2014 09:35:54 -0600 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: Message-ID: On Fri, Feb 7, 2014 at 8:47 AM, kraythe . wrote: > Man I feel silly. but then I am fighting a chest cold. I guess this happens > easier when you don't have completion or highlighting that I am used to in > an IDE. Viva Eclipse! But seriously, every programmer knows the feeling of at once being certain something's wrong with the compiler/VM and then realizing the obviousness of his or her mistake. You'll pick up quickly where to look for the common sources of these. Fred's comments on function naming are spot on - lower camel case is almost never ever seen in Erlang and really stands out in a bad and distracting way. I know this sounds religious, and it is, but it's the True Religion, so it's fine. Having very, very focused functions helps a lot both in writing a program (it forces the programmer to make things obvious in code, which is very hard to do but an excellent way to prove you understand exactly what problems you're solving) and to debug a program (it's hard for problems to lurk in obvious code). This blog post says what I mean: http://www.gar1t.com/blog/solving-embarrassingly-obvious-problems-in-erlang.html It's also True Religion, so it's fine. [1] In cases where you really need to step through code (I think these are rare, especially if you follow the obviousness rule) the function tracing tools in Erlang are fantastic. Reid Draper happened to have just presented a great tracing tool called redbug at the Chicago Erlang User Group this Wednesday: https://github.com/massemanet/eper/blob/master/src/redbug.erl I've historically used e2's e2_debug module: https://github.com/gar1t/e2/blob/master/src/e2_debug.erl I'll might switch to redbug because it stops tracing automatically after a period of time or number of traces, which is super great for use in production systems. e2_debug is fine for local dev however -- and it's output is IMO much easier to read. While you can use the Erlang visual debugger to step through code, I personally find this time consuming and awkward and prefer to trace. Problems in Erlang often come down to unexpected patterns that sneak into a call chain, which are easy to spot through tracing. Best of luck! Garrett [1] There is one stylistic change that I would recommend, vis-a-vis that blog post, which is to *selectively* use variables to pull important, side effecty operations out of nested function calls so that they appear earlier in the function (western style top-down, left-right reading) and get named results (via variable binding). So, e.g. do_something_next(do_something_first()) Becomes: FirstResult = do_something_first() do_something_next(FirstResult) God names are essential - these are terrible names, but you get the idea. Do this only when it makes the code more obvious. Richard O'Keefe pointed this out to me originally and, of course, he's right. From n.oxyde@REDACTED Fri Feb 7 16:36:14 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 7 Feb 2014 16:36:14 +0100 Subject: [erlang-questions] OTP-compliant patches In-Reply-To: References: Message-ID: <030DFA5B-67EC-4154-A778-45E488036DE7@gmail.com> Note that I always (at least that?s my intent) use spaces in my patches and have never been told anything. -- Anthony Ramine Le 7 f?vr. 2014 ? 14:49, Steve Vinoski a ?crit : > > > > On Fri, Feb 7, 2014 at 2:42 AM, Vlad Dumitrescu wrote: > Hi, > > Just so that I make sure I understand correctly, in the light of the > flame war that I recently started :-\ > > The documentation says > > > Make sure your changes follow the coding and indentation style of the code surrounding your > > changes. (At some point in the future, there will be a style guide, either included in the > > documentation or on some web site, but it is not ready yet.) > > So if the local indentation is not what erlang-mode would give, then I > still have to manually adjust it to match what already was there. Is > that correct? > > IMO yes, that's correct. BTW this approach is typical of most software projects -- I recall being taken to task for breaking this rule way back in 1987, a lesson I've never forgotten. > > Since I've had some diff look ok in emacs but not on github (or the > other way around, I don't remember exactly), which one is the > reference in case of mismatch? > > Of course, the typical reason for edits looking incorrect on github is using spaces where you need tabs for vice versa. Unfortunately, some files use a mixture of tabs and spaces, with some lines using tabs for leading whitespace and others using only spaces. My approach of dynamically setting the emacs indent-tabs-mode variable locally in the buffer based on searching the file for leading tabs upon opening it often works but isn't foolproof, since localized areas of the file might use spaces rather than tabs or vice versa. The only way I'm aware of to be fully sure that I'm respecting existing whitespace practices in the files I edit is to visually check the diffs. > > --steve > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vinoski@REDACTED Fri Feb 7 16:42:23 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Fri, 7 Feb 2014 10:42:23 -0500 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: Message-ID: On Fri, Feb 7, 2014 at 9:47 AM, kraythe . wrote: > Man I feel silly. but then I am fighting a chest cold. I guess this > happens easier when you don't have completion or highlighting that I am > used to in an IDE. > If you're using emacs for this, take a moment to learn dynamic abbreviation (dabbrev) expansion: https://www.gnu.org/software/emacs/manual/html_node/emacs/Dynamic-Abbrevs.html M-/ is your friend, not just for erlang code but for pretty much everything in emacs. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Feb 7 16:48:38 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 07 Feb 2014 16:48:38 +0100 Subject: [erlang-questions] Indentation of multiline strings In-Reply-To: References: Message-ID: <52F50056.7090106@ninenines.eu> One small comment. On 02/07/2014 04:27 PM, Steve Vinoski wrote: > I believe most of the OTP team Yes, all except one I think. > most of the Erlang community uses emacs and erlang-mode That might not be true anymore, and as Erlang gets increasingly popular it will be less and less true. Most new people I see just stick to their favorite editor. Most people I interact with don't use emacs, they use vim or sublime2. A poll could be interesting. -- Lo?c Hoguin http://ninenines.eu From n.oxyde@REDACTED Fri Feb 7 16:51:41 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 7 Feb 2014 16:51:41 +0100 Subject: [erlang-questions] erl_scan:scan_dot issue In-Reply-To: References: Message-ID: <79274261-F047-4F6B-812D-38A2DB6BA3EC@gmail.com> That surprised me too but I found that quite logical when you think about how to distinguish ?dot? from ?.?. Why don?t you just include these clauses in your own scanner? -- Anthony Ramine Le 7 f?vr. 2014 ? 10:35, Vlad Dumitrescu a ?crit : > Hi, > > This is something from at least R13, the git repository only goes that far. > > erl_scan:scan_dot contains these clauses > > scan_dot([$\n=C|Cs], St, Line, Col, Toks, Ncs) -> > Attrs = attributes(Line, Col, St, Ncs++[C]), > {ok,[{dot,Attrs}|Toks],Cs,Line+1,new_column(Col, 1)}; > scan_dot([C|Cs], St, Line, Col, Toks, Ncs) when ?WHITE_SPACE(C) -> > Attrs = attributes(Line, Col, St, Ncs++[C]), > {ok,[{dot,Attrs}|Toks],Cs,Line,incr_column(Col, 2)}; > > Why is whitespace conflated with the dot in the token? I have an old > version of the scanner that doesn't have these clauses and when I am > now trying to use the OTP scanner, there are errors all over the place > because of that.... > > best regards, > Vlad > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From kraythe@REDACTED Fri Feb 7 16:53:44 2014 From: kraythe@REDACTED (kraythe .) Date: Fri, 7 Feb 2014 09:53:44 -0600 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: Message-ID: Well I am not a programming newbie. ;-) Just an erlang newbie. If I had a dollar for every silly "is" mistake I have made, Id be rich. At any rate thanks for the advice. I think naming is not necessarily a religious thing, or it shouldn't be. It is very valid to adapt the standards of the source language. Thats what annoys me when people write Java code like C code. Anyway back to the subject at hand. The algorithm is set but now I am at another quandary Lets say these vectors represent a position in space of particular objects in a simulation. The process of culling the vectors based on the sphere is entirely a vector problem but what the user calling cull/3 really needs to know is which objects are not culled from the list, not just which vectors are not culled. Now in Java I could do a number of things if I wanted to keep the cull algorithm as it is. I could return the list of integers containing the original indexes of the vectors in the list that were culled and use that to filter out which objects need to be considered for the simulation step. I.e: List survivors = cull(C, R, Candidates); for(final Integer index : survivors) handleSurvivor(Candidates.get(index)); Now the question is what is the erlang way to do this? Thanks in advance. *Robert Simmons Jr. MSc.* *Author of: Hardcore Java (2003) and Maintainable Java (2012)* *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 * On Fri, Feb 7, 2014 at 9:35 AM, Garrett Smith wrote: > On Fri, Feb 7, 2014 at 8:47 AM, kraythe . wrote: > > Man I feel silly. but then I am fighting a chest cold. I guess this > happens > > easier when you don't have completion or highlighting that I am used to > in > > an IDE. > > Viva Eclipse! > > But seriously, every programmer knows the feeling of at once being > certain something's wrong with the compiler/VM and then realizing the > obviousness of his or her mistake. You'll pick up quickly where to > look for the common sources of these. > > Fred's comments on function naming are spot on - lower camel case is > almost never ever seen in Erlang and really stands out in a bad and > distracting way. I know this sounds religious, and it is, but it's the > True Religion, so it's fine. > > Having very, very focused functions helps a lot both in writing a > program (it forces the programmer to make things obvious in code, > which is very hard to do but an excellent way to prove you understand > exactly what problems you're solving) and to debug a program (it's > hard for problems to lurk in obvious code). > > This blog post says what I mean: > > > http://www.gar1t.com/blog/solving-embarrassingly-obvious-problems-in-erlang.html > > It's also True Religion, so it's fine. [1] > > In cases where you really need to step through code (I think these are > rare, especially if you follow the obviousness rule) the function > tracing tools in Erlang are fantastic. Reid Draper happened to have > just presented a great tracing tool called redbug at the Chicago > Erlang User Group this Wednesday: > > https://github.com/massemanet/eper/blob/master/src/redbug.erl > > I've historically used e2's e2_debug module: > > https://github.com/gar1t/e2/blob/master/src/e2_debug.erl > > I'll might switch to redbug because it stops tracing automatically > after a period of time or number of traces, which is super great for > use in production systems. e2_debug is fine for local dev however -- > and it's output is IMO much easier to read. > > While you can use the Erlang visual debugger to step through code, I > personally find this time consuming and awkward and prefer to trace. > Problems in Erlang often come down to unexpected patterns that sneak > into a call chain, which are easy to spot through tracing. > > Best of luck! > > Garrett > > [1] There is one stylistic change that I would recommend, vis-a-vis > that blog post, which is to *selectively* use variables to pull > important, side effecty operations out of nested function calls so > that they appear earlier in the function (western style top-down, > left-right reading) and get named results (via variable binding). So, > e.g. > > do_something_next(do_something_first()) > > Becomes: > > FirstResult = do_something_first() > do_something_next(FirstResult) > > God names are essential - these are terrible names, but you get the idea. > > Do this only when it makes the code more obvious. > > Richard O'Keefe pointed this out to me originally and, of course, he's > right. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gleber.p@REDACTED Fri Feb 7 17:01:39 2014 From: gleber.p@REDACTED (Gleb Peregud) Date: Fri, 7 Feb 2014 17:01:39 +0100 Subject: [erlang-questions] erl_tidy and specs In-Reply-To: <4E2E1725-EE2B-47B1-A377-D605E4B2CC2D@gmail.com> References: <4E2E1725-EE2B-47B1-A377-D605E4B2CC2D@gmail.com> Message-ID: The fact that Go team created and popularized "go fmt" from the very-very beginning was an awesome move! I would really like to be able to read the code which is always sanely and consistently formatted. If someone had time to improve erl_tidy and OTP team would promote it more, I would so very happy. On Fri, Feb 7, 2014 at 4:33 PM, Anthony Ramine wrote: > Yeah it is expected. Syntax_tools pretty-printing of Dialyzer-related attributes could be improved, but it requires a lot of new functions, as they are currently dumbed down to tuples. > > -- > Anthony Ramine > > Le 7 f?vr. 2014 ? 14:53, Fredrik Andersson a ?crit : > >> Hi all >> >> In light of the recent indentation flamewar I thought about looking for something that could become our version of go fmt and stumbled across erl_tidy (http://erlang.org/doc/man/erl_tidy.html). >> >> Now it looks good but seems to be old as it does not handle specs correctly. >> >> Given the following file. >> -module(spec_error). >> >> -export([spec_error_fun/0]). >> >> -spec spec_error_fun() -> ok. >> spec_error_fun() -> >> ok. >> >> after calling erl_tidy:dir() in the directory where it resides I get the following. >> >> -module(spec_error). >> >> -export([spec_error_fun/0]). >> >> -spec({{spec_error_fun, 0}, >> [{type, 5, 'fun', >> [{type, 5, product, []}, {atom, 5, ok}]}]}). >> >> spec_error_fun() -> ok. >> >> Is this expected or is it a bug? >> _______________________________________________ >> 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 vladdu55@REDACTED Fri Feb 7 17:07:05 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 7 Feb 2014 17:07:05 +0100 Subject: [erlang-questions] erl_scan:scan_dot issue In-Reply-To: <79274261-F047-4F6B-812D-38A2DB6BA3EC@gmail.com> References: <79274261-F047-4F6B-812D-38A2DB6BA3EC@gmail.com> Message-ID: I am now using erl_scan and the problem is that I had assumed that the text representing the dot is always of length 1, which is no longer the case. I have added a layer that converts, but now I must remember to use this layer instead of erl_scan... Anyway, I don't think that the whitespace must be part of the dot token. It is use to recognize it, of course, but the scanner worked without problems without this up to R12 or R13. So what I wondered is if there is a reason for the change. regards, Vlad On Fri, Feb 7, 2014 at 4:51 PM, Anthony Ramine wrote: > That surprised me too but I found that quite logical when you think about how to distinguish 'dot' from '.'. > > Why don't you just include these clauses in your own scanner? > > -- > Anthony Ramine > > Le 7 f?vr. 2014 ? 10:35, Vlad Dumitrescu a ?crit : > >> Hi, >> >> This is something from at least R13, the git repository only goes that far. >> >> erl_scan:scan_dot contains these clauses >> >> scan_dot([$\n=C|Cs], St, Line, Col, Toks, Ncs) -> >> Attrs = attributes(Line, Col, St, Ncs++[C]), >> {ok,[{dot,Attrs}|Toks],Cs,Line+1,new_column(Col, 1)}; >> scan_dot([C|Cs], St, Line, Col, Toks, Ncs) when ?WHITE_SPACE(C) -> >> Attrs = attributes(Line, Col, St, Ncs++[C]), >> {ok,[{dot,Attrs}|Toks],Cs,Line,incr_column(Col, 2)}; >> >> Why is whitespace conflated with the dot in the token? I have an old >> version of the scanner that doesn't have these clauses and when I am >> now trying to use the OTP scanner, there are errors all over the place >> because of that.... >> >> best regards, >> Vlad >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > From vinoski@REDACTED Fri Feb 7 17:17:08 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Fri, 7 Feb 2014 11:17:08 -0500 Subject: [erlang-questions] Indentation of multiline strings In-Reply-To: <52F50056.7090106@ninenines.eu> References: <52F50056.7090106@ninenines.eu> Message-ID: On Fri, Feb 7, 2014 at 10:48 AM, Lo?c Hoguin wrote: > One small comment. > > > On 02/07/2014 04:27 PM, Steve Vinoski wrote: > >> I believe most of the OTP team >> > > Yes, all except one I think. > > > most of the Erlang community uses emacs and erlang-mode >> > > That might not be true anymore, and as Erlang gets increasingly popular it > will be less and less true. Most new people I see just stick to their > favorite editor. Most people I interact with don't use emacs, they use vim > or sublime2. A poll could be interesting. Another consideration I forgot to mention is that I assume that a goal of the formatting specification and any tools that implement it would be that they would be capable of reformatting most of the existing OTP code such that the only changes would be whitespace changes, e.g. turning tabs into spaces or removing trailing whitespace. This assumption is based on the notion of being able to format code before commit in a way that avoids non-whitespace changes that are irrelevant to the functionality of the patch. If this assumption is valid, then given that most of the OTP code was likely written in emacs and formatted with erlang-mode, it's best to use it as the starting point. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Fri Feb 7 17:19:49 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 7 Feb 2014 17:19:49 +0100 Subject: [erlang-questions] Indentation of multiline strings In-Reply-To: References: Message-ID: On Fri, Feb 7, 2014 at 4:27 PM, Steve Vinoski wrote: > First, let's assume there's general agreement in the community that emacs > erlang-mode is the de facto standard for erlang code formatting, and is thus > the starting point for developing a formatting specification. I believe > you're basing your work on this assumption, Vlad, and if so I agree with > that approach, but if not please correct me. That's correct. > Some might object to using > erlang-mode as the starting point on the basis that other editors sometimes > have a hard time formatting code the same way erlang-mode does, but I > believe most of the OTP team and most of the Erlang community uses emacs and > erlang-mode, so I view it as the most practical starting point. Other editors will still have to implement a formatter/indenter. I think the issues they have today are mostly related to mixing tabs and spaces, but since Anthony said that his patches only have spaces and there were no issues, that would simplify it. > To create a formatting specification, I recommend that if you haven't done > so already, start collecting cases like the multiline string and binary > cases where erlang-mode fails, and report them as bugs against erlang-mode. > Obviously this applies to anyone who wishes to help. I think that I will start by specifying how erlang-mode indents today. That would be mostly a case of looking at the test file in the sources and extract the data by inspection. The vision is to not only specify an indenter, but even a pretty printer. Here I must credit Tuncer for starting a discussion with me for a couple of weeks ago. > To resolve those bugs, we may need to form a small group that can decide how > erlang-mode should format the problematic cases. A good choice for > volunteers here are the primary erlang-mode maintainer and some willing > subset of those who have recently contributed code and patches to > erlang-mode. As one of those people, I'm willing to help with that, and also > willing to help resolve the bugs in erlang-mode so it conforms to the > specification you're putting together. Great, thanks! > I assume that during this effort someone -- probably you Vlad, but I know of > other parties also interested -- would be writing a new tool that also > conforms to the formatting specification. Having such a tool would give us > at least two independent implementations of the spec. Yes, it would be useful to have an Erlang-based tool too. I can use it from erlide, so I don't need to write anything in Java. /Vlad From vladdu55@REDACTED Fri Feb 7 17:21:28 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 7 Feb 2014 17:21:28 +0100 Subject: [erlang-questions] Indentation of multiline strings In-Reply-To: References: <52F50056.7090106@ninenines.eu> Message-ID: On Fri, Feb 7, 2014 at 5:17 PM, Steve Vinoski wrote: > Another consideration I forgot to mention is that I assume that a goal of > the formatting specification and any tools that implement it would be that > they would be capable of reformatting most of the existing OTP code such > that the only changes would be whitespace changes, e.g. turning tabs into > spaces or removing trailing whitespace. This assumption is based on the > notion of being able to format code before commit in a way that avoids > non-whitespace changes that are irrelevant to the functionality of the > patch. If this assumption is valid, then given that most of the OTP code was > likely written in emacs and formatted with erlang-mode, it's best to use it > as the starting point. Yes, absolutely. An indenter is a formatter that is not allowed to break/collate lines, so I think the same basic rules apply. /Vlad From felixgallo@REDACTED Fri Feb 7 17:24:55 2014 From: felixgallo@REDACTED (Felix Gallo) Date: Fri, 7 Feb 2014 08:24:55 -0800 Subject: [erlang-questions] Maps & records: binding directly to bitstring comprehensions In-Reply-To: References: Message-ID: Jesper, your instinct are correct as usual. Unfortunately the protocol designers live upstream in a different group over which I have no control, and are incentivized to take the Facebook mantra of "move fast and break things" to heart. Maybe to rephrase the question: if I have a binary with, say, 850 fields representing, in essence, a tightly packed data structure often containing heirarchical elements, and I wish to both be able to decompose this, and also to recompose it, and I'd like to use records or maps to enforce as much cleanliness as possible, what's the best practice, and is there something we can do to while the EEP43 concrete is still wet? F. On Fri, Feb 7, 2014 at 4:47 AM, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > > On Thu, Feb 6, 2014 at 11:35 PM, Felix Gallo wrote: > >> I live in a world of pain wherein I receive 4K binary blob packets with a >> tightly packed schema that changes every few weeks. > > > For what it is worth, this is the root cause of the problem. If you have a > packet format that changes this often, you are probably better off > improving the packet encoding scheme than trying to parse it and adapt. You > need a format which has more framing so it can be parsed by recursively > stripping off more and more information. That is, you can decode the packet > partially and skip sections your parser doesn't understand yet. > > Also beware coding complexity. If data is never placed at rest on disk, > then struggling to compress data with an intricate scheme is not going to > buy you anything since there tend to be enough bandwidth for these kind of > things. Decoding is going to dwarf everything else[0]. > > I would probably just wait a bit until the format settles and then go > implement it there. > > [0] This describes almost everything that is wrong with JSON. > > -- > J. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Fri Feb 7 17:36:19 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Fri, 7 Feb 2014 08:36:19 -0800 (PST) Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <52F4C173.8050408@erlang.org> References: <52F4C173.8050408@erlang.org> Message-ID: <1391790979.26271.YahooMailNeo@web140106.mail.bf1.yahoo.com> " ? ?1> erlang:system_info(otp_release). ? ? "17" ? ? 2> erlang:system_info(otp_correction_package). ? ? "17.0-rc1" NOTE: The name of the argument "otp_correction_package" will be changed? to "otp_version."" Any possibility of changing the naming conventions to something more easily memorized? ?For example, otp_major_release ("17") vs otp_release ("17.0-rc1"). (Presumably, the second one is the one people will usually want to know?)? Not to say I'm committed to what I just proposed, but I just know I shall evermore have to consult the manual to get otp_release and otp_version straight. (Also, consider if there ever were to be a second supplier of erlang. Wouldn't it be better to use option names that do not include "otp" to get this information?) Best, Thomas On Friday, February 7, 2014 12:36 PM, Andreas Schumacher wrote: We changed the version scheme for two reasons: For the first, we >abandoned the R-version scheme, since it has a meaning inside Ericsson >that differs from how we used it; that caused some confusion. Secondly, >we adapted a version scheme that allows us to bookkeep fine-grained >patches on arbitrary OTP versions to our customers with support agreements. > >The new version scheme is *not* semantic versioning; although, it has >been inspired by it. We do not want to use semantic versioning (as >defined by http://semver.org/) out of the box since it does not fit our >needs. Most importantly, we must be able branch out from any old version >and also be able to do so multiple times. This is not possible when >limited to only using MAJOR.MINOR.PATCH as version numbers. For example, >if we have released 17.0, 17.0.1, and 17.0.2 we may have to release a >patch based on 17.0.1. In this case it will be given the version 17.0.1.1. > >A new MAJOR release is denoted with .0, where is incremented by >one at the delivery of a new major release, which may contain potential >incompatibilities. > >A pre-release is denoted with .0-rc, where starts with 1 at >the delivery of the first pre-release, and is incremented by one for >each subsequent pre-release. "-rc0" will be used during development up >to the first release candidate. Pre-releases -rc sort before . >Apart from -rc, there are no plans for other special parts; >although that might change if the need arises. > >A MINOR and/or PATCH (bug-fix) release is denoted with .., where: >- is set to 0 when is incremented and is incremented by one when >new (minor) >? functionality is released. is used even when == 0. >- is set to 0 when or is incremented, and incremented by one >when only bug >? fixes are released. is not used when == 0, unless [support >patches] patches are based on that version; see below. > >Everything in a version V0 = .. is included in a version V1 = >.. if V1 is greater than V0. V1 > V0 if Y1 > Y0 || (Y1 == Y0 >&& Z1 > Z0). > >The OTP major release and the complete OTP version can be retrieved from >erlang code using the following: > >? ? 1> erlang:system_info(otp_release). >? ? "17" >? ? 2> erlang:system_info(otp_correction_package). >? ? "17.0-rc1" > >NOTE: The name of the argument "otp_correction_package" will be changed >to "otp_version." In addition, a corresponding flag "otp_version" will >be added to the erl command, in order to allow the extraction of the >complete version number from command line tools. > >Version changes in applications imply a version change on OTP level, but >they are not propagated one-to-one; especially, a change of the major >version of an application does not necessarily imply a change of the >major version at the OTP level. The mapping is a case-by-case decision >that depends on the application, the type of functionality, impacts on >backward compatibility, etc. > >It is basically only the releases of the form .. that are of >interest for the Erlang open source community. However, from OTP 17.0 we >will only deliver source code releases [even to our customers with >support agreements]; and thus, even traces of support-patch >release-versions on top of those regular releases are going to be >visible in the public Erlang/OTP Git repository. The following is a >brief description of the format of those patch releases: > >When branching out, we add ".1" at the end of .., unless this >version number has already been used. If it has already been used, we >search for an unused version number by adding more and more ".0" between >the version we are branching from, and the ".1" that we add at the end. >For example, 17.0.1.1, 17.0.1.0.1, 17.0.1.0.0.1, and 17.0.1.0.0.0.1 are >all versions of modifications based on version 17.0.1. > >When basing a patch or a feature on an already branched version that do >not require any new branching, we increase the last part of the version. > >When versions have more than the ordinary three parts MAJOR.MINOR.PATCH, >you cannot >draw any conclusions about the specific modifications in the version, >but you can see what the modifications are based on. > >The Erlang/OTP Team at Ericsson > >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kraythe@REDACTED Fri Feb 7 17:45:25 2014 From: kraythe@REDACTED (kraythe .) Date: Fri, 7 Feb 2014 10:45:25 -0600 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: Message-ID: So now the fixed code is: %% Subtract the second vector from the first subtract({X1, Y1, Z1}, {X2, Y2, Z2}) -> {(X1 - X2), (Y1 - Y2), (Z1 - Z2)}. %% Compute the magnitude of the vector magnitude({X, Y, Z}) -> math:sqrt((X * X) + (Y * Y) + (Z * Z)). %% Compute whether the vector with components X, Y and Z has greater magnitude then the passed scalar M. %% Note that this method avoids the expensive sqrt operation. is_magnitude_greater(M, {X, Y, Z}) when is_number(M), is_number(X), is_number(Y), is_number(Z) -> Msq = M * M, Magsq = (X * X) + (Y * Y) + (Z * Z), Msq > Magsq. %% Determines if any coordinate in the given vector is bigger than the passed in value M has_coordinate_greater_than(V, {X, Y, Z}) when X > V; Y > V; Z > V -> true; has_coordinate_greater_than(V, Coordinate) when is_number(V), is_tuple(Coordinate) -> false. %% Culls the list of vectors X to only those that are in the sphere devined by vector C as a center and R as a radius. cull(C, R, Vectors) when is_number(R), is_tuple(C), is_list(Vectors) -> cull(C, R, Vectors, []). cull(C, R, [], Culled) -> Culled; cull(C, R, [Head|Tail], Culled) -> D = subtract(C, Head), case has_coordinate_greater_than(R, Head) of true -> cull(C, R, Tail, Culled); false -> cull(C, R, D, Head, Tail, Culled) end. cull(C, R, D, Head, Tail, Culled) when is_tuple(D), is_number(R) -> case is_magnitude_greater(R, D) of true -> cull(C, R, Tail, [Head | Culled]); false -> cull(C, R, Tail, Culled) end. Now the question is the resolution of the followup question of how to integrate this in a solution. Do we return a list of trues and falses and zip that with the objects to form a candidate list? How would you do it? *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* *Author of: Hardcore Java (2003) and Maintainable Java (2012)* *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 * On Fri, Feb 7, 2014 at 9:53 AM, kraythe . wrote: > Well I am not a programming newbie. ;-) Just an erlang newbie. If I had a > dollar for every silly "is" mistake I have made, Id be rich. At any rate > thanks for the advice. I think naming is not necessarily a religious thing, > or it shouldn't be. It is very valid to adapt the standards of the source > language. Thats what annoys me when people write Java code like C code. > > Anyway back to the subject at hand. The algorithm is set but now I am at > another quandary Lets say these vectors represent a position in space of > particular objects in a simulation. The process of culling the vectors > based on the sphere is entirely a vector problem but what the user calling > cull/3 really needs to know is which objects are not culled from the > list, not just which vectors are not culled. Now in Java I could do a > number of things if I wanted to keep the cull algorithm as it is. I could > return the list of integers containing the original indexes of the vectors > in the list that were culled and use that to filter out which objects need > to be considered for the simulation step. I.e: > > List survivors = cull(C, R, Candidates); > for(final Integer index : survivors) > handleSurvivor(Candidates.get(index)); > > Now the question is what is the erlang way to do this? > > Thanks in advance. > > *Robert Simmons Jr. MSc.* > *Author of: Hardcore Java (2003) and Maintainable Java (2012)* > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 > * > > > On Fri, Feb 7, 2014 at 9:35 AM, Garrett Smith wrote: > >> On Fri, Feb 7, 2014 at 8:47 AM, kraythe . wrote: >> > Man I feel silly. but then I am fighting a chest cold. I guess this >> happens >> > easier when you don't have completion or highlighting that I am used to >> in >> > an IDE. >> >> Viva Eclipse! >> >> But seriously, every programmer knows the feeling of at once being >> certain something's wrong with the compiler/VM and then realizing the >> obviousness of his or her mistake. You'll pick up quickly where to >> look for the common sources of these. >> >> Fred's comments on function naming are spot on - lower camel case is >> almost never ever seen in Erlang and really stands out in a bad and >> distracting way. I know this sounds religious, and it is, but it's the >> True Religion, so it's fine. >> >> Having very, very focused functions helps a lot both in writing a >> program (it forces the programmer to make things obvious in code, >> which is very hard to do but an excellent way to prove you understand >> exactly what problems you're solving) and to debug a program (it's >> hard for problems to lurk in obvious code). >> >> This blog post says what I mean: >> >> >> http://www.gar1t.com/blog/solving-embarrassingly-obvious-problems-in-erlang.html >> >> It's also True Religion, so it's fine. [1] >> >> In cases where you really need to step through code (I think these are >> rare, especially if you follow the obviousness rule) the function >> tracing tools in Erlang are fantastic. Reid Draper happened to have >> just presented a great tracing tool called redbug at the Chicago >> Erlang User Group this Wednesday: >> >> https://github.com/massemanet/eper/blob/master/src/redbug.erl >> >> I've historically used e2's e2_debug module: >> >> https://github.com/gar1t/e2/blob/master/src/e2_debug.erl >> >> I'll might switch to redbug because it stops tracing automatically >> after a period of time or number of traces, which is super great for >> use in production systems. e2_debug is fine for local dev however -- >> and it's output is IMO much easier to read. >> >> While you can use the Erlang visual debugger to step through code, I >> personally find this time consuming and awkward and prefer to trace. >> Problems in Erlang often come down to unexpected patterns that sneak >> into a call chain, which are easy to spot through tracing. >> >> Best of luck! >> >> Garrett >> >> [1] There is one stylistic change that I would recommend, vis-a-vis >> that blog post, which is to *selectively* use variables to pull >> important, side effecty operations out of nested function calls so >> that they appear earlier in the function (western style top-down, >> left-right reading) and get named results (via variable binding). So, >> e.g. >> >> do_something_next(do_something_first()) >> >> Becomes: >> >> FirstResult = do_something_first() >> do_something_next(FirstResult) >> >> God names are essential - these are terrible names, but you get the idea. >> >> Do this only when it makes the code more obvious. >> >> Richard O'Keefe pointed this out to me originally and, of course, he's >> right. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cabo@REDACTED Fri Feb 7 17:21:01 2014 From: cabo@REDACTED (Carsten Bormann) Date: Fri, 7 Feb 2014 17:21:01 +0100 Subject: [erlang-questions] Indentation of multiline strings In-Reply-To: <52F50056.7090106@ninenines.eu> References: <52F50056.7090106@ninenines.eu> Message-ID: On 07 Feb 2014, at 16:48, Lo?c Hoguin wrote: >> most of the Erlang community uses emacs and erlang-mode Every community goes through this as the members get more diverse. It?s probably worth to learn from other communities here. Most developer communities have learned the hard way that any occurrence of a tab character (ASCII HT) in source code is evil. Emacs can be taught to stop inserting them in a single line: (setq-default indent-tabs-mode nil) ; for general good taste Put this in your .emacs, and life will be so much brighter. (There are equivalent settings for all other useful source code editors out there, but I only can speak for Emacs.) Yes, there is all this old code out there with those smelly HT characters. It will fix itself over the course of a couple decades. (Don?t try to untabify everything at once.) Gr??e, Carsten PS.: Yes, I know why those HT characters really are there. An LA36 dot matrix printing terminal at 300 baud is considerably faster skipping indentation with HT characters in use. I do think we have outgrown them. From bob@REDACTED Fri Feb 7 17:56:07 2014 From: bob@REDACTED (Robert Wilkinson) Date: Fri, 7 Feb 2014 17:56:07 +0100 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: Message-ID: <20140207165606.GB26892@fourtheye.org> On Fri, Feb 07, 2014 at 09:35:54AM -0600, Garrett Smith wrote: > On Fri, Feb 7, 2014 at 8:47 AM, kraythe . wrote: > > Man I feel silly. but then I am fighting a chest cold. I guess this happens > > easier when you don't have completion or highlighting that I am used to in > > an IDE. > > [1] There is one stylistic change that I would recommend, vis-a-vis > that blog post, which is to *selectively* use variables to pull > important, side effecty operations out of nested function calls so > that they appear earlier in the function (western style top-down, > left-right reading) and get named results (via variable binding). So, > e.g. > > do_something_next(do_something_first()) > > Becomes: > > FirstResult = do_something_first() > do_something_next(FirstResult) > > God names are essential - these are terrible names, but you get the idea. All Hail Eris !! Though some prefer Yahweh, Osiris or Shiva? Bob From n.oxyde@REDACTED Fri Feb 7 17:59:18 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 7 Feb 2014 17:59:18 +0100 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: Message-ID: <5C0F2E9D-669F-43BB-AFEF-B17E29CCA996@gmail.com> Hello, Good luck with your learning. Replied inline. Regards, -- Anthony Ramine Le 7 f?vr. 2014 ? 17:45, kraythe . a ?crit : > So now the fixed code is: > > %% Subtract the second vector from the first > subtract({X1, Y1, Z1}, {X2, Y2, Z2}) -> {(X1 - X2), (Y1 - Y2), (Z1 - Z2)}. The parentheses are not required here but you seem to like to use them with arithmetic, won't argue against that. > %% Compute the magnitude of the vector > magnitude({X, Y, Z}) -> math:sqrt((X * X) + (Y * Y) + (Z * Z)). > > %% Compute whether the vector with components X, Y and Z has greater magnitude then the passed scalar M. > %% Note that this method avoids the expensive sqrt operation. > is_magnitude_greater(M, {X, Y, Z}) when is_number(M), is_number(X), is_number(Y), is_number(Z) -> > Msq = M * M, > Magsq = (X * X) + (Y * Y) + (Z * Z), > Msq > Magsq. All the guards here are useless as M * M will crash with badarith if M isn?t a number. > %% Determines if any coordinate in the given vector is bigger than the passed in value M > has_coordinate_greater_than(V, {X, Y, Z}) when X > V; Y > V; Z > V -> true; > has_coordinate_greater_than(V, Coordinate) when is_number(V), is_tuple(Coordinate) -> false. You can make that function in one clause: has_coordinate_greater_than(V, {X, Y, Z}) -> X > V orelse Y > V orelse Z > V. As an aside, your second clause would traditionally be written as: has_coordinate_greater_than(_, {_, _, _}) -> false or, to document better the code sometimes: has_coordinate_greater_than(_V, {_X, _Y, _Z}) -> false > %% Culls the list of vectors X to only those that are in the sphere devined by vector C as a center and R as a radius. > cull(C, R, Vectors) when is_number(R), is_tuple(C), is_list(Vectors) -> cull(C, R, Vectors, []). > cull(C, R, [], Culled) -> Culled; > cull(C, R, [Head|Tail], Culled) -> > D = subtract(C, Head), > case has_coordinate_greater_than(R, Head) of > true -> cull(C, R, Tail, Culled); > false -> cull(C, R, D, Head, Tail, Culled) > end. > cull(C, R, D, Head, Tail, Culled) when is_tuple(D), is_number(R) -> > case is_magnitude_greater(R, D) of > true -> cull(C, R, Tail, [Head | Culled]); > false -> cull(C, R, Tail, Culled) > end. Newlines are usually inserted between different functions. In cull/6, I would pass Head last, generally new arguments are always inserted last in recursive functions to make the code more efficient and avoid moving around register values in the VM. > Now the question is the resolution of the followup question of how to integrate this in a solution. Do we return a list of trues and falses and zip that with the objects to form a candidate list? How would you do it? Given that your function returns a boolean per value in the given list, why does it work on a list to begin with? Why doesn?t it take just one vector? From kraythe@REDACTED Fri Feb 7 18:26:57 2014 From: kraythe@REDACTED (kraythe .) Date: Fri, 7 Feb 2014 11:26:57 -0600 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: <5C0F2E9D-669F-43BB-AFEF-B17E29CCA996@gmail.com> References: <5C0F2E9D-669F-43BB-AFEF-B17E29CCA996@gmail.com> Message-ID: Good question Anthony! The reason is that this math in my simulation will be run thousands of times per second on the cluster and it is very possible that the culling of the vectors will need to be factored out into a port or NIF for speed reasons. So I would prefer, if possible, to implement the culling in one spot that could be, later, refactored. Also it makes a good academic discussion for me to discover the erlang mindset. :) *Robert Simmons Jr. MSc.* *Author of: Hardcore Java (2003) and Maintainable Java (2012)* *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 * On Fri, Feb 7, 2014 at 10:59 AM, Anthony Ramine wrote: > Hello, > > Good luck with your learning. > > Replied inline. > > Regards, > > -- > Anthony Ramine > > Le 7 f?vr. 2014 ? 17:45, kraythe . a ?crit : > > > So now the fixed code is: > > > > %% Subtract the second vector from the first > > subtract({X1, Y1, Z1}, {X2, Y2, Z2}) -> {(X1 - X2), (Y1 - Y2), (Z1 - > Z2)}. > > The parentheses are not required here but you seem to like to use them > with arithmetic, won't argue against that. > > > %% Compute the magnitude of the vector > > magnitude({X, Y, Z}) -> math:sqrt((X * X) + (Y * Y) + (Z * Z)). > > > > %% Compute whether the vector with components X, Y and Z has greater > magnitude then the passed scalar M. > > %% Note that this method avoids the expensive sqrt operation. > > is_magnitude_greater(M, {X, Y, Z}) when is_number(M), is_number(X), > is_number(Y), is_number(Z) -> > > Msq = M * M, > > Magsq = (X * X) + (Y * Y) + (Z * Z), > > Msq > Magsq. > > All the guards here are useless as M * M will crash with badarith if M > isn't a number. > > > %% Determines if any coordinate in the given vector is bigger than the > passed in value M > > has_coordinate_greater_than(V, {X, Y, Z}) when X > V; Y > V; Z > V -> > true; > > has_coordinate_greater_than(V, Coordinate) when is_number(V), > is_tuple(Coordinate) -> false. > > You can make that function in one clause: > > has_coordinate_greater_than(V, {X, Y, Z}) -> > X > V orelse Y > V orelse Z > V. > > As an aside, your second clause would traditionally be written as: > > has_coordinate_greater_than(_, {_, _, _}) -> false > > or, to document better the code sometimes: > > has_coordinate_greater_than(_V, {_X, _Y, _Z}) -> false > > > %% Culls the list of vectors X to only those that are in the sphere > devined by vector C as a center and R as a radius. > > cull(C, R, Vectors) when is_number(R), is_tuple(C), is_list(Vectors) -> > cull(C, R, Vectors, []). > > cull(C, R, [], Culled) -> Culled; > > cull(C, R, [Head|Tail], Culled) -> > > D = subtract(C, Head), > > case has_coordinate_greater_than(R, Head) of > > true -> cull(C, R, Tail, Culled); > > false -> cull(C, R, D, Head, Tail, Culled) > > end. > > cull(C, R, D, Head, Tail, Culled) when is_tuple(D), is_number(R) -> > > case is_magnitude_greater(R, D) of > > true -> cull(C, R, Tail, [Head | Culled]); > > false -> cull(C, R, Tail, Culled) > > end. > > Newlines are usually inserted between different functions. > > In cull/6, I would pass Head last, generally new arguments are always > inserted last in recursive functions to make the code more efficient and > avoid moving around register values in the VM. > > > Now the question is the resolution of the followup question of how to > integrate this in a solution. Do we return a list of trues and falses and > zip that with the objects to form a candidate list? How would you do it? > > Given that your function returns a boolean per value in the given list, > why does it work on a list to begin with? Why doesn't it take just one > vector? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eriksoe@REDACTED Fri Feb 7 19:13:46 2014 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Fri, 7 Feb 2014 19:13:46 +0100 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: Message-ID: If you hadn't mentioned M-/, I would have :-) No more excuses for being lazy wrt. naming. Den 07/02/2014 16.42 skrev "Steve Vinoski" : > > > > On Fri, Feb 7, 2014 at 9:47 AM, kraythe . wrote: > >> Man I feel silly. but then I am fighting a chest cold. I guess this >> happens easier when you don't have completion or highlighting that I am >> used to in an IDE. >> > > If you're using emacs for this, take a moment to learn dynamic > abbreviation (dabbrev) expansion: > > > https://www.gnu.org/software/emacs/manual/html_node/emacs/Dynamic-Abbrevs.html > > M-/ is your friend, not just for erlang code but for pretty much > everything in emacs. > > --steve > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah@REDACTED Fri Feb 7 19:28:26 2014 From: noah@REDACTED (Noah Diewald) Date: Fri, 07 Feb 2014 12:28:26 -0600 Subject: [erlang-questions] erl_tidy and specs In-Reply-To: References: <4E2E1725-EE2B-47B1-A377-D605E4B2CC2D@gmail.com> Message-ID: <878utmkcad.fsf@diewald.me> I think that "go fmt" was a direct result of having acme editor users on the team. The formatting in acme is always done by an external program. I tend to make fmt shell tools for all the languages I use. For erlang I actually use an emacs batch command. It would be nice to have something less clunky but my current setup is works. gleber.p@REDACTED writes: > The fact that Go team created and popularized "go fmt" from the > very-very beginning was an awesome move! I would really like to be > able to read the code which is always sanely and consistently > formatted. If someone had time to improve erl_tidy and OTP team would > promote it more, I would so very happy. > > On Fri, Feb 7, 2014 at 4:33 PM, Anthony Ramine wrote: >> Yeah it is expected. Syntax_tools pretty-printing of Dialyzer-related attributes could be improved, but it requires a lot of new functions, as they are currently dumbed down to tuples. >> >> -- >> Anthony Ramine >> >> Le 7 f?vr. 2014 ? 14:53, Fredrik Andersson a ?crit : >> >>> Hi all >>> >>> In light of the recent indentation flamewar I thought about looking for something that could become our version of go fmt and stumbled across erl_tidy (http://erlang.org/doc/man/erl_tidy.html). >>> >>> Now it looks good but seems to be old as it does not handle specs correctly. >>> >>> Given the following file. >>> -module(spec_error). >>> >>> -export([spec_error_fun/0]). >>> >>> -spec spec_error_fun() -> ok. >>> spec_error_fun() -> >>> ok. >>> >>> after calling erl_tidy:dir() in the directory where it resides I get the following. >>> >>> -module(spec_error). >>> >>> -export([spec_error_fun/0]). >>> >>> -spec({{spec_error_fun, 0}, >>> [{type, 5, 'fun', >>> [{type, 5, product, []}, {atom, 5, ok}]}]}). >>> >>> spec_error_fun() -> ok. >>> >>> Is this expected or is it a bug? >>> _______________________________________________ >>> 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 eriksoe@REDACTED Fri Feb 7 19:31:45 2014 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Fri, 7 Feb 2014 19:31:45 +0100 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: Message-ID: I think I'd use lists:filter there, at least until I had indications that it cost speed. Also, I suspect there are some abs() calls missing in the has_coordinate_greater_than() function - or have I misunderstood? Den 07/02/2014 17.45 skrev "kraythe ." : > So now the fixed code is: > > %% Subtract the second vector from the first > subtract({X1, Y1, Z1}, {X2, Y2, Z2}) -> {(X1 - X2), (Y1 - Y2), (Z1 - Z2)}. > > %% Compute the magnitude of the vector > magnitude({X, Y, Z}) -> math:sqrt((X * X) + (Y * Y) + (Z * Z)). > > %% Compute whether the vector with components X, Y and Z has greater > magnitude then the passed scalar M. > %% Note that this method avoids the expensive sqrt operation. > is_magnitude_greater(M, {X, Y, Z}) when is_number(M), is_number(X), > is_number(Y), is_number(Z) -> > Msq = M * M, > Magsq = (X * X) + (Y * Y) + (Z * Z), > Msq > Magsq. > > %% Determines if any coordinate in the given vector is bigger than the > passed in value M > has_coordinate_greater_than(V, {X, Y, Z}) when X > V; Y > V; Z > V -> > true; > has_coordinate_greater_than(V, Coordinate) when is_number(V), > is_tuple(Coordinate) -> false. > > %% Culls the list of vectors X to only those that are in the sphere > devined by vector C as a center and R as a radius. > cull(C, R, Vectors) when is_number(R), is_tuple(C), is_list(Vectors) -> > cull(C, R, Vectors, []). > cull(C, R, [], Culled) -> Culled; > cull(C, R, [Head|Tail], Culled) -> > D = subtract(C, Head), > case has_coordinate_greater_than(R, Head) of > true -> cull(C, R, Tail, Culled); > false -> cull(C, R, D, Head, Tail, Culled) > end. > cull(C, R, D, Head, Tail, Culled) when is_tuple(D), is_number(R) -> > case is_magnitude_greater(R, D) of > true -> cull(C, R, Tail, [Head | Culled]); > false -> cull(C, R, Tail, Culled) > end. > > Now the question is the resolution of the followup question of how to > integrate this in a solution. Do we return a list of trues and falses and > zip that with the objects to form a candidate list? How would you do it? > > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* > *Author of: Hardcore Java (2003) and Maintainable Java (2012)* > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 > * > > > On Fri, Feb 7, 2014 at 9:53 AM, kraythe . wrote: > >> Well I am not a programming newbie. ;-) Just an erlang newbie. If I had a >> dollar for every silly "is" mistake I have made, Id be rich. At any rate >> thanks for the advice. I think naming is not necessarily a religious thing, >> or it shouldn't be. It is very valid to adapt the standards of the source >> language. Thats what annoys me when people write Java code like C code. >> >> Anyway back to the subject at hand. The algorithm is set but now I am at >> another quandary Lets say these vectors represent a position in space of >> particular objects in a simulation. The process of culling the vectors >> based on the sphere is entirely a vector problem but what the user calling >> cull/3 really needs to know is which objects are not culled from the >> list, not just which vectors are not culled. Now in Java I could do a >> number of things if I wanted to keep the cull algorithm as it is. I could >> return the list of integers containing the original indexes of the vectors >> in the list that were culled and use that to filter out which objects need >> to be considered for the simulation step. I.e: >> >> List survivors = cull(C, R, Candidates); >> for(final Integer index : survivors) >> handleSurvivor(Candidates.get(index)); >> >> Now the question is what is the erlang way to do this? >> >> Thanks in advance. >> >> *Robert Simmons Jr. MSc.* >> *Author of: Hardcore Java (2003) and Maintainable Java (2012)* >> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 >> * >> >> >> On Fri, Feb 7, 2014 at 9:35 AM, Garrett Smith wrote: >> >>> On Fri, Feb 7, 2014 at 8:47 AM, kraythe . wrote: >>> > Man I feel silly. but then I am fighting a chest cold. I guess this >>> happens >>> > easier when you don't have completion or highlighting that I am used >>> to in >>> > an IDE. >>> >>> Viva Eclipse! >>> >>> But seriously, every programmer knows the feeling of at once being >>> certain something's wrong with the compiler/VM and then realizing the >>> obviousness of his or her mistake. You'll pick up quickly where to >>> look for the common sources of these. >>> >>> Fred's comments on function naming are spot on - lower camel case is >>> almost never ever seen in Erlang and really stands out in a bad and >>> distracting way. I know this sounds religious, and it is, but it's the >>> True Religion, so it's fine. >>> >>> Having very, very focused functions helps a lot both in writing a >>> program (it forces the programmer to make things obvious in code, >>> which is very hard to do but an excellent way to prove you understand >>> exactly what problems you're solving) and to debug a program (it's >>> hard for problems to lurk in obvious code). >>> >>> This blog post says what I mean: >>> >>> >>> http://www.gar1t.com/blog/solving-embarrassingly-obvious-problems-in-erlang.html >>> >>> It's also True Religion, so it's fine. [1] >>> >>> In cases where you really need to step through code (I think these are >>> rare, especially if you follow the obviousness rule) the function >>> tracing tools in Erlang are fantastic. Reid Draper happened to have >>> just presented a great tracing tool called redbug at the Chicago >>> Erlang User Group this Wednesday: >>> >>> https://github.com/massemanet/eper/blob/master/src/redbug.erl >>> >>> I've historically used e2's e2_debug module: >>> >>> https://github.com/gar1t/e2/blob/master/src/e2_debug.erl >>> >>> I'll might switch to redbug because it stops tracing automatically >>> after a period of time or number of traces, which is super great for >>> use in production systems. e2_debug is fine for local dev however -- >>> and it's output is IMO much easier to read. >>> >>> While you can use the Erlang visual debugger to step through code, I >>> personally find this time consuming and awkward and prefer to trace. >>> Problems in Erlang often come down to unexpected patterns that sneak >>> into a call chain, which are easy to spot through tracing. >>> >>> Best of luck! >>> >>> Garrett >>> >>> [1] There is one stylistic change that I would recommend, vis-a-vis >>> that blog post, which is to *selectively* use variables to pull >>> important, side effecty operations out of nested function calls so >>> that they appear earlier in the function (western style top-down, >>> left-right reading) and get named results (via variable binding). So, >>> e.g. >>> >>> do_something_next(do_something_first()) >>> >>> Becomes: >>> >>> FirstResult = do_something_first() >>> do_something_next(FirstResult) >>> >>> God names are essential - these are terrible names, but you get the idea. >>> >>> Do this only when it makes the code more obvious. >>> >>> Richard O'Keefe pointed this out to me originally and, of course, he's >>> right. >>> >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.brandon.clark@REDACTED Fri Feb 7 19:17:55 2014 From: a.brandon.clark@REDACTED (Brandon Clark) Date: Fri, 7 Feb 2014 10:17:55 -0800 Subject: [erlang-questions] Erlang term to ASCII Message-ID: I have 2 production systems, one Erlang and one not, both maintaining copies of a large, deeply-nested Erlang data structure. I need to set up a monitoring script to confirm that both systems are holding identical copies of the data structure. The non-Erlang system is holding an ASCII rendering of the data structure. Computing an MD5 sum of this string is easy. If I can get the Erlang system to convert its data structure to a string, I can have it compute an MD5 sum as well and the monitoring is simply a matter of comparing hashes. I'm stuck on the process of converting the Erlang term to a string. Str = io_lib:format("~p", [Data]) gives me what I want, except that it includes newlines and indentation that I can't expect the non-Erlang system to have. Str = io_lib:format("~w", [Data]) eliminates the newlines and indentation but renders the textual components of Data as lists of integers, guaranteeing the result won't match the non-Erlang system. So the question is, how do I get a "~p"-style rendering of an arbitrarily-large Erlang term *without* newlines and indentation? Thank you! ~Brandon Clark -------------- next part -------------- An HTML attachment was scrubbed... URL: From eriksoe@REDACTED Fri Feb 7 19:57:35 2014 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Fri, 7 Feb 2014 19:57:35 +0100 Subject: [erlang-questions] Erlang term to ASCII In-Reply-To: References: Message-ID: Regexp substitution? :-) (That's the simple path, anyway.) Den 07/02/2014 19.33 skrev "Brandon Clark" : > I have 2 production systems, one Erlang and one not, both maintaining > copies of a large, deeply-nested Erlang data structure. I need to set up a > monitoring script to confirm that both systems are holding identical copies > of the data structure. > > The non-Erlang system is holding an ASCII rendering of the data structure. > Computing an MD5 sum of this string is easy. If I can get the Erlang > system to convert its data structure to a string, I can have it compute an > MD5 sum as well and the monitoring is simply a matter of comparing hashes. > > I'm stuck on the process of converting the Erlang term to a string. > > Str = io_lib:format("~p", [Data]) > > gives me what I want, except that it includes newlines and indentation > that I can't expect the non-Erlang system to have. > > Str = io_lib:format("~w", [Data]) > > eliminates the newlines and indentation but renders the textual components > of Data as lists of integers, guaranteeing the result won't match the > non-Erlang system. > > So the question is, how do I get a "~p"-style rendering of an > arbitrarily-large Erlang term *without* newlines and indentation? > > Thank you! > > ~Brandon Clark > > > _______________________________________________ > 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 Fri Feb 7 20:16:49 2014 From: bob@REDACTED (Bob Ippolito) Date: Fri, 7 Feb 2014 11:16:49 -0800 Subject: [erlang-questions] Erlang term to ASCII In-Reply-To: References: Message-ID: How is this other system maintaining the deeply-nested Erlang structure? How or why is it in text? How does it get rendered without newlines and indentation? Why not use a more predictable (less flexible) serialization format (erlang term format, JSON, protocol buffers, ?)? I do not think that this is the best approach. There are many possible representations of various tokens as Erlang source code and I would never trust two implementations to render it exactly the same way unless I wrote both of them. Some tokens that are going to be particularly problematic are lists of integers (which may or may not be rendered like strings, with various ways to escape), binaries (which may be rendered like strings or not), and floating point numbers. On Fri, Feb 7, 2014 at 10:17 AM, Brandon Clark wrote: > I have 2 production systems, one Erlang and one not, both maintaining > copies of a large, deeply-nested Erlang data structure. I need to set up a > monitoring script to confirm that both systems are holding identical copies > of the data structure. > > The non-Erlang system is holding an ASCII rendering of the data structure. > Computing an MD5 sum of this string is easy. If I can get the Erlang > system to convert its data structure to a string, I can have it compute an > MD5 sum as well and the monitoring is simply a matter of comparing hashes. > > I'm stuck on the process of converting the Erlang term to a string. > > Str = io_lib:format("~p", [Data]) > > gives me what I want, except that it includes newlines and indentation > that I can't expect the non-Erlang system to have. > > Str = io_lib:format("~w", [Data]) > > eliminates the newlines and indentation but renders the textual components > of Data as lists of integers, guaranteeing the result won't match the > non-Erlang system. > > So the question is, how do I get a "~p"-style rendering of an > arbitrarily-large Erlang term *without* newlines and indentation? > > Thank you! > > ~Brandon Clark > > > _______________________________________________ > 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 Fri Feb 7 20:25:12 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 07 Feb 2014 20:25:12 +0100 Subject: [erlang-questions] Erlang term to ASCII In-Reply-To: References: Message-ID: <52F53318.1020103@ninenines.eu> Str = io_lib:format("~9999999999999999999999999p", [Data]) Yep. On 02/07/2014 07:17 PM, Brandon Clark wrote: > I have 2 production systems, one Erlang and one not, both maintaining > copies of a large, deeply-nested Erlang data structure. I need to set > up a monitoring script to confirm that both systems are holding > identical copies of the data structure. > > The non-Erlang system is holding an ASCII rendering of the data > structure. Computing an MD5 sum of this string is easy. If I can get > the Erlang system to convert its data structure to a string, I can have > it compute an MD5 sum as well and the monitoring is simply a matter of > comparing hashes. > > I'm stuck on the process of converting the Erlang term to a string. > > Str = io_lib:format("~p", [Data]) > > gives me what I want, except that it includes newlines and indentation > that I can't expect the non-Erlang system to have. > > Str = io_lib:format("~w", [Data]) > > eliminates the newlines and indentation but renders the textual > components of Data as lists of integers, guaranteeing the result won't > match the non-Erlang system. > > So the question is, how do I get a "~p"-style rendering of an > arbitrarily-large Erlang term /without/ newlines and indentation? > > Thank you! > > ~Brandon Clark > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From ivan@REDACTED Fri Feb 7 21:25:26 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Fri, 7 Feb 2014 20:25:26 +0000 (GMT) Subject: [erlang-questions] .app(.src) and .appup(.src) files Message-ID: <8h4iNYRg.1391804726.2465430.ivan@llaisdy.com> Dear All Looking around at how erlang applications are laid out, especially the .app and .appup files. Some people have them in myapp/ebin/. Some people keep .src versions in myapp/src/ and copy them over to ebin when building the app. Some people are half-and-half. Tools make assumptions accordingly. I can see arguments on either side: keeping .src versions in src/ saves you putting ebin/ under version control; keeping the files in ebin/ simplifies the build process. Well, ok, I can see one argument on either side. Might the files ever be altered when they're moved from src/ to ebin/, or are they always just copied verbatim? I don't want to start an argument, I'd just like to make an informed choice. With thanks and best wishes Ivan From essen@REDACTED Fri Feb 7 21:43:48 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 07 Feb 2014 21:43:48 +0100 Subject: [erlang-questions] .app(.src) and .appup(.src) files In-Reply-To: <8h4iNYRg.1391804726.2465430.ivan@llaisdy.com> References: <8h4iNYRg.1391804726.2465430.ivan@llaisdy.com> Message-ID: <52F54584.6090901@ninenines.eu> src/appname.app.src typically doesn't contain the list of modules, which is filled in automatically when copying it to ebin/appname.app. That's the whole point of the .app.src really. I don't think tools do much more than that. I think rebar allows you to set {vsn, git} to automatically set a version based on the branch/tag/commit/.. but that's it. On 02/07/2014 09:25 PM, Ivan Uemlianin wrote: > > Dear All > > Looking around at how erlang applications are laid out, especially the > .app and .appup files. Some people have them in myapp/ebin/. Some > people keep .src versions in myapp/src/ and copy them over to ebin when > building the app. Some people are half-and-half. Tools make > assumptions accordingly. > > I can see arguments on either side: keeping .src versions in src/ saves > you putting ebin/ under version control; keeping the files in ebin/ > simplifies the build process. Well, ok, I can see one argument on > either side. > > Might the files ever be altered when they're moved from src/ to ebin/, > or are they always just copied verbatim? > > I don't want to start an argument, I'd just like to make an informed > choice. > > With thanks and best wishes > > Ivan > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From kraythe@REDACTED Fri Feb 7 22:01:49 2014 From: kraythe@REDACTED (kraythe .) Date: Fri, 7 Feb 2014 15:01:49 -0600 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: Message-ID: Yeah there needed to be some abs calls, I have added them since I posted. *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* *Author of: Hardcore Java (2003) and Maintainable Java (2012)* *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 * On Fri, Feb 7, 2014 at 12:31 PM, Erik S?e S?rensen wrote: > I think I'd use lists:filter there, at least until I had indications that > it cost speed. > Also, I suspect there are some abs() calls missing in the > has_coordinate_greater_than() function - or have I misunderstood? > Den 07/02/2014 17.45 skrev "kraythe ." : > >> So now the fixed code is: >> >> %% Subtract the second vector from the first >> subtract({X1, Y1, Z1}, {X2, Y2, Z2}) -> {(X1 - X2), (Y1 - Y2), (Z1 - Z2)}. >> >> %% Compute the magnitude of the vector >> magnitude({X, Y, Z}) -> math:sqrt((X * X) + (Y * Y) + (Z * Z)). >> >> %% Compute whether the vector with components X, Y and Z has greater >> magnitude then the passed scalar M. >> %% Note that this method avoids the expensive sqrt operation. >> is_magnitude_greater(M, {X, Y, Z}) when is_number(M), is_number(X), >> is_number(Y), is_number(Z) -> >> Msq = M * M, >> Magsq = (X * X) + (Y * Y) + (Z * Z), >> Msq > Magsq. >> >> %% Determines if any coordinate in the given vector is bigger than the >> passed in value M >> has_coordinate_greater_than(V, {X, Y, Z}) when X > V; Y > V; Z > V -> >> true; >> has_coordinate_greater_than(V, Coordinate) when is_number(V), >> is_tuple(Coordinate) -> false. >> >> %% Culls the list of vectors X to only those that are in the sphere >> devined by vector C as a center and R as a radius. >> cull(C, R, Vectors) when is_number(R), is_tuple(C), is_list(Vectors) -> >> cull(C, R, Vectors, []). >> cull(C, R, [], Culled) -> Culled; >> cull(C, R, [Head|Tail], Culled) -> >> D = subtract(C, Head), >> case has_coordinate_greater_than(R, Head) of >> true -> cull(C, R, Tail, Culled); >> false -> cull(C, R, D, Head, Tail, Culled) >> end. >> cull(C, R, D, Head, Tail, Culled) when is_tuple(D), is_number(R) -> >> case is_magnitude_greater(R, D) of >> true -> cull(C, R, Tail, [Head | Culled]); >> false -> cull(C, R, Tail, Culled) >> end. >> >> Now the question is the resolution of the followup question of how to >> integrate this in a solution. Do we return a list of trues and falses and >> zip that with the objects to form a candidate list? How would you do it? >> >> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* >> *Author of: Hardcore Java (2003) and Maintainable Java (2012)* >> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 >> * >> >> >> On Fri, Feb 7, 2014 at 9:53 AM, kraythe . wrote: >> >>> Well I am not a programming newbie. ;-) Just an erlang newbie. If I had >>> a dollar for every silly "is" mistake I have made, Id be rich. At any rate >>> thanks for the advice. I think naming is not necessarily a religious thing, >>> or it shouldn't be. It is very valid to adapt the standards of the source >>> language. Thats what annoys me when people write Java code like C code. >>> >>> Anyway back to the subject at hand. The algorithm is set but now I am at >>> another quandary Lets say these vectors represent a position in space of >>> particular objects in a simulation. The process of culling the vectors >>> based on the sphere is entirely a vector problem but what the user calling >>> cull/3 really needs to know is which objects are not culled from the >>> list, not just which vectors are not culled. Now in Java I could do a >>> number of things if I wanted to keep the cull algorithm as it is. I could >>> return the list of integers containing the original indexes of the vectors >>> in the list that were culled and use that to filter out which objects need >>> to be considered for the simulation step. I.e: >>> >>> List survivors = cull(C, R, Candidates); >>> for(final Integer index : survivors) >>> handleSurvivor(Candidates.get(index)); >>> >>> Now the question is what is the erlang way to do this? >>> >>> Thanks in advance. >>> >>> *Robert Simmons Jr. MSc.* >>> *Author of: Hardcore Java (2003) and Maintainable Java (2012)* >>> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 >>> * >>> >>> >>> On Fri, Feb 7, 2014 at 9:35 AM, Garrett Smith wrote: >>> >>>> On Fri, Feb 7, 2014 at 8:47 AM, kraythe . wrote: >>>> > Man I feel silly. but then I am fighting a chest cold. I guess this >>>> happens >>>> > easier when you don't have completion or highlighting that I am used >>>> to in >>>> > an IDE. >>>> >>>> Viva Eclipse! >>>> >>>> But seriously, every programmer knows the feeling of at once being >>>> certain something's wrong with the compiler/VM and then realizing the >>>> obviousness of his or her mistake. You'll pick up quickly where to >>>> look for the common sources of these. >>>> >>>> Fred's comments on function naming are spot on - lower camel case is >>>> almost never ever seen in Erlang and really stands out in a bad and >>>> distracting way. I know this sounds religious, and it is, but it's the >>>> True Religion, so it's fine. >>>> >>>> Having very, very focused functions helps a lot both in writing a >>>> program (it forces the programmer to make things obvious in code, >>>> which is very hard to do but an excellent way to prove you understand >>>> exactly what problems you're solving) and to debug a program (it's >>>> hard for problems to lurk in obvious code). >>>> >>>> This blog post says what I mean: >>>> >>>> >>>> http://www.gar1t.com/blog/solving-embarrassingly-obvious-problems-in-erlang.html >>>> >>>> It's also True Religion, so it's fine. [1] >>>> >>>> In cases where you really need to step through code (I think these are >>>> rare, especially if you follow the obviousness rule) the function >>>> tracing tools in Erlang are fantastic. Reid Draper happened to have >>>> just presented a great tracing tool called redbug at the Chicago >>>> Erlang User Group this Wednesday: >>>> >>>> https://github.com/massemanet/eper/blob/master/src/redbug.erl >>>> >>>> I've historically used e2's e2_debug module: >>>> >>>> https://github.com/gar1t/e2/blob/master/src/e2_debug.erl >>>> >>>> I'll might switch to redbug because it stops tracing automatically >>>> after a period of time or number of traces, which is super great for >>>> use in production systems. e2_debug is fine for local dev however -- >>>> and it's output is IMO much easier to read. >>>> >>>> While you can use the Erlang visual debugger to step through code, I >>>> personally find this time consuming and awkward and prefer to trace. >>>> Problems in Erlang often come down to unexpected patterns that sneak >>>> into a call chain, which are easy to spot through tracing. >>>> >>>> Best of luck! >>>> >>>> Garrett >>>> >>>> [1] There is one stylistic change that I would recommend, vis-a-vis >>>> that blog post, which is to *selectively* use variables to pull >>>> important, side effecty operations out of nested function calls so >>>> that they appear earlier in the function (western style top-down, >>>> left-right reading) and get named results (via variable binding). So, >>>> e.g. >>>> >>>> do_something_next(do_something_first()) >>>> >>>> Becomes: >>>> >>>> FirstResult = do_something_first() >>>> do_something_next(FirstResult) >>>> >>>> God names are essential - these are terrible names, but you get the >>>> idea. >>>> >>>> Do this only when it makes the code more obvious. >>>> >>>> Richard O'Keefe pointed this out to me originally and, of course, he's >>>> right. >>>> >>> >>> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Fri Feb 7 22:14:16 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Fri, 7 Feb 2014 21:14:16 +0000 (GMT) Subject: [erlang-questions] SOLVED -- Re: .app(.src) and .appup(.src) files In-Reply-To: <52F54AB7.4090205@ninenines.eu> Message-ID: Thanks! On 7/2/2014, "Lo?c Hoguin" wrote: >They could be generated but they would always end up being wrong and >wouldn't avoid you to work on them. > >On 02/07/2014 10:00 PM, Ivan Uemlianin wrote: >> >> Dear Lo??c >> >> Thanks for your answer. >> >> I've just this minute been reading the source of your erlang.mk! >> >> Is it right that with .appup files, there isn't the scope for that kind >> of automation? >> >> Best wishes >> >> Ivan >> >> >> On 7/2/2014, "Lo??c Hoguin" wrote: >> >>> src/appname.app.src typically doesn't contain the list of modules, which >>> is filled in automatically when copying it to ebin/appname.app. >>> >>> That's the whole point of the .app.src really. I don't think tools do >>> much more than that. I think rebar allows you to set {vsn, git} to >>> automatically set a version based on the branch/tag/commit/.. but that's it. >>> >>> On 02/07/2014 09:25 PM, Ivan Uemlianin wrote: >>>> >>>> Dear All >>>> >>>> Looking around at how erlang applications are laid out, especially the >>>> .app and .appup files. Some people have them in myapp/ebin/. Some >>>> people keep .src versions in myapp/src/ and copy them over to ebin when >>>> building the app. Some people are half-and-half. Tools make >>>> assumptions accordingly. >>>> >>>> I can see arguments on either side: keeping .src versions in src/ saves >>>> you putting ebin/ under version control; keeping the files in ebin/ >>>> simplifies the build process. Well, ok, I can see one argument on >>>> either side. >>>> >>>> Might the files ever be altered when they're moved from src/ to ebin/, >>>> or are they always just copied verbatim? >>>> >>>> I don't want to start an argument, I'd just like to make an informed >>>> choice. >>>> >>>> With thanks and best wishes >>>> >>>> Ivan >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> >>> -- >>> Lo????c Hoguin >>> http://ninenines.eu >>> > >-- >Lo??c Hoguin >http://ninenines.eu > From jesper.louis.andersen@REDACTED Fri Feb 7 22:15:37 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 7 Feb 2014 22:15:37 +0100 Subject: [erlang-questions] Maps & records: binding directly to bitstring comprehensions In-Reply-To: References: Message-ID: On Fri, Feb 7, 2014 at 5:24 PM, Felix Gallo wrote: > Jesper, your instinct are correct as usual. Unfortunately the protocol > designers live upstream in a different group over which I have no control, > and are incentivized to take the Facebook mantra of "move fast and break > things" to heart. One way would perhaps be to screw performance. Break the decoder into multiple small pieces and define an interpreter for the small pieces. Now, the definition is given by the input to the interpreter. It will be slow, but it will be easier to reconfigure. When things slow down, you can replace the interpreted variant with a faster code variant. The idea is that you only need to implement each new concept they cook up, but not each change. The basic idea is to have a grammar for the format and then employ a parser generator on the grammar. But you probably don't need the speed up front, only getting the definitions correct. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Fri Feb 7 22:25:31 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 7 Feb 2014 22:25:31 +0100 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: Message-ID: On Fri, Feb 7, 2014 at 5:45 PM, kraythe . wrote: > Now the question is the resolution of the followup question of how to > integrate this in a solution. Do we return a list of trues and falses and > zip that with the objects to form a candidate list? How would you do it? Look at lists:partition/2 then write your culler so it can be given as a predicate to partition. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustav.simonsson@REDACTED Fri Feb 7 22:32:41 2014 From: gustav.simonsson@REDACTED (Gustav Simonsson) Date: Fri, 7 Feb 2014 22:32:41 +0100 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: Message-ID: Time for Higher Order Functions Friday Evening (HOFFE)! I renamed and refactored the cull functions a bit to give a example of using higher order functions instead of manual recursion. To answer your other question about objects, one minimal example below is the spaceship object defined as a two tuple consisting of {Stuff, Vector}. In the example below I just put a atom in the stuff element, but it could as well be a complex term. It is ignored by the filtering function. Cheers, Gustav %% Subtract the second vector from the first subtract({X1, Y1, Z1}, {X2, Y2, Z2}) -> {(X1 - X2), (Y1 - Y2), (Z1 - Z2)}. %% Compute the magnitude of the vector magnitude({X, Y, Z}) -> math:sqrt((X * X) + (Y * Y) + (Z * Z)). %% Compute whether the vector with components X, Y and Z has greater magnitude then the passed scalar M. %% Note that this method avoids the expensive sqrt operation. is_magnitude_greater(M, {X, Y, Z}) -> Msq = M * M, Magsq = (X * X) + (Y * Y) + (Z * Z), Msq > Magsq. %% Determines if any coordinate in the given vector is bigger than the passed in value M has_coordinate_greater_than(V, {X, Y, Z}) -> X > V orelse Y > V orelse Z > V; has_coordinate_greater_than(_, _) -> false. %% Vector is in the sphere devined by vector C as a center and R as a radius. in_sphere(C, R, Vector) -> case has_coordinate_greater_than(R, Vector) of true -> false; false -> is_magnitude_greater(R, subtract(C, Vector)) end. cull(C, R, Vectors) -> lists:filter(fun(Vector) -> in_sphere(C, R, Vector) end, Vectors). cull_spaceships(C, R, Spaceships) -> InSphere = fun({_SpaceshipStuff, SpaceshipVector}) -> in_sphere(C, R, SpaceshipVector) end, lists:filter(InSphere, Spaceships). ======================================= 34> v:cull_spaceships({3,3,3}, 5, [{spaceship_stuff, {4,4,4}}]). [{spaceship_stuff,{4,4,4}}] On Fri, Feb 7, 2014 at 10:25 PM, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > > On Fri, Feb 7, 2014 at 5:45 PM, kraythe . wrote: > >> Now the question is the resolution of the followup question of how to >> integrate this in a solution. Do we return a list of trues and falses and >> zip that with the objects to form a candidate list? How would you do it? > > > Look at lists:partition/2 then write your culler so it can be given as a > predicate to partition. > > > -- > J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eriksoe@REDACTED Fri Feb 7 22:38:41 2014 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Fri, 7 Feb 2014 22:38:41 +0100 Subject: [erlang-questions] Maps & records: binding directly to bitstring comprehensions In-Reply-To: References: Message-ID: Indeed - I've found that Erlang is great for writing small interpreters for declarative specifications of domain logic. And a particularly good thing about that approach is when you can have one specification but multiple interpreters (encoder/decoder, evaluator/type checker, ...). Den 07/02/2014 22.16 skrev "Jesper Louis Andersen" < jesper.louis.andersen@REDACTED>: > > On Fri, Feb 7, 2014 at 5:24 PM, Felix Gallo wrote: > >> Jesper, your instinct are correct as usual. Unfortunately the protocol >> designers live upstream in a different group over which I have no control, >> and are incentivized to take the Facebook mantra of "move fast and break >> things" to heart. > > > One way would perhaps be to screw performance. Break the decoder into > multiple small pieces and define an interpreter for the small pieces. Now, > the definition is given by the input to the interpreter. It will be slow, > but it will be easier to reconfigure. When things slow down, you can > replace the interpreted variant with a faster code variant. The idea is > that you only need to implement each new concept they cook up, but not each > change. > > The basic idea is to have a grammar for the format and then employ a > parser generator on the grammar. But you probably don't need the speed up > front, only getting the definitions correct. > > > -- > J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjw0188@REDACTED Fri Feb 7 22:43:32 2014 From: kjw0188@REDACTED (Kelly Wong) Date: Fri, 7 Feb 2014 13:43:32 -0800 Subject: [erlang-questions] Mongoose IM Documentation In-Reply-To: References: Message-ID: Hi Michal, Thanks for the link. I'm trying to figure out what hooks I can set and when they're called. The end goal is to write a plugin that can send an Apple notification service message to a user who is not online. I was thinking I could write a plugin that intercepts messages to offline users. Is that the right way to go about things? Thanks, Kelly Wong On Wed, Feb 5, 2014 at 11:18 PM, Michal Piotrowski < michal.piotrowski@REDACTED> wrote: > Hello Kelly, > > There are some examples on our github: https://github.com/esl/MongooseIM. > The default installation of MongooseIM works with mnesia as a database. > What exactly do you need to know? > > BTW, the config file is in most cases compatible with the one in ejabberd > 2.1.x. > > Best regards > Michal Piotrowski > michal.piotrowski@REDACTED > > > On 05 Feb 2014, at 03:10, Kelly Wong wrote: > > Hello, > > I'm trying to setup Mongoose IM, but for the life of me can't find any > documentation for it. Can anyone point me in the right direction? > > Thanks, > Kelly Wong > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.brandon.clark@REDACTED Fri Feb 7 23:16:34 2014 From: a.brandon.clark@REDACTED (Brandon Clark) Date: Fri, 7 Feb 2014 14:16:34 -0800 Subject: [erlang-questions] Erlang term to ASCII In-Reply-To: References: Message-ID: The non-Erlang app is an in-house configuration management system. It stores configuration settings in a SQL database and produces the app.config file used by my Erlang app on demand via REST interface; the configuration is delivered as a string in the body of an HTTP response. My ultimate goal is to rework the Erlang app so that it fetches and applies most configuration updates automatically without restarting. For the near term, that means I have to cope with strings. In the long term, though, I have some sway over what the CMS does, provided I'm willing to get my hands dirty. ("Don't bring problems -- bring solutions.") I'm in favor of Erlang external terms and I think I can sell that solution with BERT and BERT-RPC. Regardless of how we transmit the data, we still need a way to confirm that both systems agree on what the data structure contains. The current favored solution is to ask both systems to compute a hash of their data. We can normalize the data any way we want in preparation for hashing as long as both sides do it in exactly the same way. Since the CMS is already pretty good at building Erlang terms as strings without newlines or indentation, I set out to find a way to make Erlang do the same thing. ~BC On Fri, Feb 7, 2014 at 11:16 AM, Bob Ippolito wrote: > How is this other system maintaining the deeply-nested Erlang structure? > How or why is it in text? How does it get rendered without newlines and > indentation? Why not use a more predictable (less flexible) serialization > format (erlang term format, JSON, protocol buffers, ...)? > > I do not think that this is the best approach. There are many possible > representations of various tokens as Erlang source code and I would never > trust two implementations to render it exactly the same way unless I wrote > both of them. Some tokens that are going to be particularly problematic are > lists of integers (which may or may not be rendered like strings, with > various ways to escape), binaries (which may be rendered like strings or > not), and floating point numbers. > > > > > On Fri, Feb 7, 2014 at 10:17 AM, Brandon Clark wrote: > >> I have 2 production systems, one Erlang and one not, both maintaining >> copies of a large, deeply-nested Erlang data structure. I need to set up a >> monitoring script to confirm that both systems are holding identical copies >> of the data structure. >> >> The non-Erlang system is holding an ASCII rendering of the data >> structure. Computing an MD5 sum of this string is easy. If I can get the >> Erlang system to convert its data structure to a string, I can have it >> compute an MD5 sum as well and the monitoring is simply a matter of >> comparing hashes. >> >> I'm stuck on the process of converting the Erlang term to a string. >> >> Str = io_lib:format("~p", [Data]) >> >> gives me what I want, except that it includes newlines and indentation >> that I can't expect the non-Erlang system to have. >> >> Str = io_lib:format("~w", [Data]) >> >> eliminates the newlines and indentation but renders the textual >> components of Data as lists of integers, guaranteeing the result won't >> match the non-Erlang system. >> >> So the question is, how do I get a "~p"-style rendering of an >> arbitrarily-large Erlang term *without* newlines and indentation? >> >> Thank you! >> >> ~Brandon Clark >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.brandon.clark@REDACTED Fri Feb 7 23:18:28 2014 From: a.brandon.clark@REDACTED (Brandon Clark) Date: Fri, 7 Feb 2014 14:18:28 -0800 Subject: [erlang-questions] Erlang term to ASCII In-Reply-To: <52F53318.1020103@ninenines.eu> References: <52F53318.1020103@ninenines.eu> Message-ID: Bob wins the moral victory. Lo?c wins the stuffed animal. :-) On Fri, Feb 7, 2014 at 11:25 AM, Lo?c Hoguin wrote: > Str = io_lib:format("~9999999999999999999999999p", [Data]) > > Yep. > > > On 02/07/2014 07:17 PM, Brandon Clark wrote: > >> I have 2 production systems, one Erlang and one not, both maintaining >> copies of a large, deeply-nested Erlang data structure. I need to set >> up a monitoring script to confirm that both systems are holding >> identical copies of the data structure. >> >> The non-Erlang system is holding an ASCII rendering of the data >> structure. Computing an MD5 sum of this string is easy. If I can get >> the Erlang system to convert its data structure to a string, I can have >> it compute an MD5 sum as well and the monitoring is simply a matter of >> comparing hashes. >> >> I'm stuck on the process of converting the Erlang term to a string. >> >> Str = io_lib:format("~p", [Data]) >> >> gives me what I want, except that it includes newlines and indentation >> that I can't expect the non-Erlang system to have. >> >> Str = io_lib:format("~w", [Data]) >> >> eliminates the newlines and indentation but renders the textual >> components of Data as lists of integers, guaranteeing the result won't >> match the non-Erlang system. >> >> So the question is, how do I get a "~p"-style rendering of an >> arbitrarily-large Erlang term /without/ newlines and indentation? >> >> Thank you! >> >> ~Brandon Clark >> >> >> >> _______________________________________________ >> 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 bob@REDACTED Fri Feb 7 23:49:29 2014 From: bob@REDACTED (Bob Ippolito) Date: Fri, 7 Feb 2014 14:49:29 -0800 Subject: [erlang-questions] Erlang term to ASCII In-Reply-To: References: Message-ID: Hashing of a string representation is probably not a great way to ensure that both systems agree on that structure. Even different versions of Erlang disagree on what exactly the representation of ~p should be for a given term, and I'm not talking about whitespace. It's simply not well suited for your purpose, even though it might appear to work for most of the cases you have now. You could write your own Erlang implementation of whatever the CMS does, but you're unlikely to implement it correctly by taking "~p" and then trying to normalize the output. You really should come up with a scheme to either hash the data structure itself (like Erlang's phash2 but portable to both sides of your system), or you should hash the output of a representation that has absolutely no flexibility in how data is encoded. Erlang's External Term Format is a lot closer, but there are still multiple valid ways to encode the same thing (particularly the atom cache table, using bigger encodings than necessary, etc.). On Fri, Feb 7, 2014 at 2:16 PM, Brandon Clark wrote: > The non-Erlang app is an in-house configuration management system. It > stores configuration settings in a SQL database and produces the app.config > file used by my Erlang app on demand via REST interface; the configuration > is delivered as a string in the body of an HTTP response. > > My ultimate goal is to rework the Erlang app so that it fetches and > applies most configuration updates automatically without restarting. For > the near term, that means I have to cope with strings. In the long term, > though, I have some sway over what the CMS does, provided I'm willing to > get my hands dirty. ("Don't bring problems -- bring solutions.") I'm in > favor of Erlang external terms and I think I can sell that solution with > BERT and BERT-RPC. > > Regardless of how we transmit the data, we still need a way to confirm > that both systems agree on what the data structure contains. The current > favored solution is to ask both systems to compute a hash of their data. > We can normalize the data any way we want in preparation for hashing as > long as both sides do it in exactly the same way. Since the CMS is already > pretty good at building Erlang terms as strings without newlines or > indentation, I set out to find a way to make Erlang do the same thing. > > ~BC > > > > > > > On Fri, Feb 7, 2014 at 11:16 AM, Bob Ippolito wrote: > >> How is this other system maintaining the deeply-nested Erlang structure? >> How or why is it in text? How does it get rendered without newlines and >> indentation? Why not use a more predictable (less flexible) serialization >> format (erlang term format, JSON, protocol buffers, ?)? >> >> I do not think that this is the best approach. There are many possible >> representations of various tokens as Erlang source code and I would never >> trust two implementations to render it exactly the same way unless I wrote >> both of them. Some tokens that are going to be particularly problematic are >> lists of integers (which may or may not be rendered like strings, with >> various ways to escape), binaries (which may be rendered like strings or >> not), and floating point numbers. >> >> >> >> >> On Fri, Feb 7, 2014 at 10:17 AM, Brandon Clark > > wrote: >> >>> I have 2 production systems, one Erlang and one not, both maintaining >>> copies of a large, deeply-nested Erlang data structure. I need to set up a >>> monitoring script to confirm that both systems are holding identical copies >>> of the data structure. >>> >>> The non-Erlang system is holding an ASCII rendering of the data >>> structure. Computing an MD5 sum of this string is easy. If I can get the >>> Erlang system to convert its data structure to a string, I can have it >>> compute an MD5 sum as well and the monitoring is simply a matter of >>> comparing hashes. >>> >>> I'm stuck on the process of converting the Erlang term to a string. >>> >>> Str = io_lib:format("~p", [Data]) >>> >>> gives me what I want, except that it includes newlines and indentation >>> that I can't expect the non-Erlang system to have. >>> >>> Str = io_lib:format("~w", [Data]) >>> >>> eliminates the newlines and indentation but renders the textual >>> components of Data as lists of integers, guaranteeing the result won't >>> match the non-Erlang system. >>> >>> So the question is, how do I get a "~p"-style rendering of an >>> arbitrarily-large Erlang term *without* newlines and indentation? >>> >>> Thank you! >>> >>> ~Brandon Clark >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moxford@REDACTED Sat Feb 8 01:20:03 2014 From: moxford@REDACTED (Mike Oxford) Date: Fri, 7 Feb 2014 16:20:03 -0800 Subject: [erlang-questions] Maps & records: binding directly to bitstring comprehensions In-Reply-To: References: Message-ID: Can you make them use protobufs? Or "hey, be more like the facebook that you love and use thrift like facebook does?" It gives you the framing that JLA was speaking of and still maintains a tight, compact binary format (probably even tighter than they're shipping already.) When they change the .proto/.thrift file you can just take that and generate your end. They can change it all over and work on your end is minimal when they rev. On Fri, Feb 7, 2014 at 1:38 PM, Erik S?e S?rensen wrote: > Indeed - I've found that Erlang is great for writing small interpreters > for declarative specifications of domain logic. And a particularly good > thing about that approach is when you can have one specification but > multiple interpreters (encoder/decoder, evaluator/type checker, ...). > Den 07/02/2014 22.16 skrev "Jesper Louis Andersen" < > jesper.louis.andersen@REDACTED>: > >> >> On Fri, Feb 7, 2014 at 5:24 PM, Felix Gallo wrote: >> >>> Jesper, your instinct are correct as usual. Unfortunately the protocol >>> designers live upstream in a different group over which I have no control, >>> and are incentivized to take the Facebook mantra of "move fast and break >>> things" to heart. >> >> >> One way would perhaps be to screw performance. Break the decoder into >> multiple small pieces and define an interpreter for the small pieces. Now, >> the definition is given by the input to the interpreter. It will be slow, >> but it will be easier to reconfigure. When things slow down, you can >> replace the interpreted variant with a faster code variant. The idea is >> that you only need to implement each new concept they cook up, but not each >> change. >> >> The basic idea is to have a grammar for the format and then employ a >> parser generator on the grammar. But you probably don't need the speed up >> front, only getting the definitions correct. >> >> >> -- >> J. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sat Feb 8 02:09:15 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 8 Feb 2014 02:09:15 +0100 Subject: [erlang-questions] erl_tidy and specs In-Reply-To: References: <4E2E1725-EE2B-47B1-A377-D605E4B2CC2D@gmail.com> Message-ID: Hello, No syntax tools code yet, but I?ve made some documentation about the various trees that need to be handled. https://github.com/erlang/otp/pull/230 Regards, -- Anthony Ramine Le 7 f?vr. 2014 ? 17:01, Gleb Peregud a ?crit : > The fact that Go team created and popularized "go fmt" from the > very-very beginning was an awesome move! I would really like to be > able to read the code which is always sanely and consistently > formatted. If someone had time to improve erl_tidy and OTP team would > promote it more, I would so very happy. > > On Fri, Feb 7, 2014 at 4:33 PM, Anthony Ramine wrote: >> Yeah it is expected. Syntax_tools pretty-printing of Dialyzer-related attributes could be improved, but it requires a lot of new functions, as they are currently dumbed down to tuples. >> >> -- >> Anthony Ramine >> >> Le 7 f?vr. 2014 ? 14:53, Fredrik Andersson a ?crit : >> >>> Hi all >>> >>> In light of the recent indentation flamewar I thought about looking for something that could become our version of go fmt and stumbled across erl_tidy (http://erlang.org/doc/man/erl_tidy.html). >>> >>> Now it looks good but seems to be old as it does not handle specs correctly. >>> >>> Given the following file. >>> -module(spec_error). >>> >>> -export([spec_error_fun/0]). >>> >>> -spec spec_error_fun() -> ok. >>> spec_error_fun() -> >>> ok. >>> >>> after calling erl_tidy:dir() in the directory where it resides I get the following. >>> >>> -module(spec_error). >>> >>> -export([spec_error_fun/0]). >>> >>> -spec({{spec_error_fun, 0}, >>> [{type, 5, 'fun', >>> [{type, 5, product, []}, {atom, 5, ok}]}]}). >>> >>> spec_error_fun() -> ok. >>> >>> Is this expected or is it a bug? >>> _______________________________________________ >>> 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 sina.samv@REDACTED Sat Feb 8 00:34:53 2014 From: sina.samv@REDACTED (Sina Samavati) Date: Sat, 08 Feb 2014 03:04:53 +0330 Subject: [erlang-questions] What is the difference between maps and dict in R17 In-Reply-To: <16eb8541.5280.1440ba50d11.Coremail.zehongzheng2008@163.com> (=?utf-8?B?IueUqAnmiLciJ3M=?= message of "Fri, 7 Feb 2014 17:19:30 +0800 (CST)") References: <16eb8541.5280.1440ba50d11.Coremail.zehongzheng2008@163.com> Message-ID: <87a9e2qyxu.fsf@gmail.com> ?? writes: > Both of maps and dict are used as map, so when and where to use maps? It *can* be an alternative for dict. Besides, dict is a data structure, map is a data type. -- Sina Samavati Software engineer https://github.com/s1n4 https://twitter.com/sinasamavati From sedrik@REDACTED Sat Feb 8 10:47:55 2014 From: sedrik@REDACTED (Fredrik Andersson) Date: Sat, 8 Feb 2014 10:47:55 +0100 Subject: [erlang-questions] erl_tidy and specs In-Reply-To: References: <4E2E1725-EE2B-47B1-A377-D605E4B2CC2D@gmail.com> Message-ID: Ok, sounds like a great area to improve on then. having an official formatter would solve many issues we have today. =) On Sat, Feb 8, 2014 at 2:09 AM, Anthony Ramine wrote: > Hello, > > No syntax tools code yet, but I've made some documentation about the > various trees that need to be handled. > > https://github.com/erlang/otp/pull/230 > > Regards, > > -- > Anthony Ramine > > Le 7 f?vr. 2014 ? 17:01, Gleb Peregud a ?crit : > > > The fact that Go team created and popularized "go fmt" from the > > very-very beginning was an awesome move! I would really like to be > > able to read the code which is always sanely and consistently > > formatted. If someone had time to improve erl_tidy and OTP team would > > promote it more, I would so very happy. > > > > On Fri, Feb 7, 2014 at 4:33 PM, Anthony Ramine > wrote: > >> Yeah it is expected. Syntax_tools pretty-printing of Dialyzer-related > attributes could be improved, but it requires a lot of new functions, as > they are currently dumbed down to tuples. > >> > >> -- > >> Anthony Ramine > >> > >> Le 7 f?vr. 2014 ? 14:53, Fredrik Andersson a ?crit > : > >> > >>> Hi all > >>> > >>> In light of the recent indentation flamewar I thought about looking > for something that could become our version of go fmt and stumbled across > erl_tidy (http://erlang.org/doc/man/erl_tidy.html). > >>> > >>> Now it looks good but seems to be old as it does not handle specs > correctly. > >>> > >>> Given the following file. > >>> -module(spec_error). > >>> > >>> -export([spec_error_fun/0]). > >>> > >>> -spec spec_error_fun() -> ok. > >>> spec_error_fun() -> > >>> ok. > >>> > >>> after calling erl_tidy:dir() in the directory where it resides I get > the following. > >>> > >>> -module(spec_error). > >>> > >>> -export([spec_error_fun/0]). > >>> > >>> -spec({{spec_error_fun, 0}, > >>> [{type, 5, 'fun', > >>> [{type, 5, product, []}, {atom, 5, ok}]}]}). > >>> > >>> spec_error_fun() -> ok. > >>> > >>> Is this expected or is it a bug? > >>> _______________________________________________ > >>> 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 ciprian.craciun@REDACTED Sat Feb 8 14:39:33 2014 From: ciprian.craciun@REDACTED (Ciprian Dorin Craciun) Date: Sat, 8 Feb 2014 15:39:33 +0200 Subject: [erlang-questions] 0MQ libraries In-Reply-To: References: Message-ID: (Sorry for "reviving" this thread, but only now I've managed to drain the mail queue.) :) On Fri, Jan 31, 2014 at 9:12 AM, Joe Armstrong wrote: > Why don't we just use gen_tcp and interact with 0MQ peers using the > wire-line protocol. Erlang is good at getting data in and out of sockets, > and good at parsing binary packets. > > I'm not suggesting implementing all the protocols and transports to start > with just the REQ - REP protocols of TCP > > [...] Implementing a pure Erlang ZeroMQ library that understands only TCP and some of the basic patterns (such as (X)REQ/REP, PULL/PUSH), as Joe has suggested, could easily be a weekend project (within some acceptable performance limits), as the wire protocol is almost trivial, and the routing logic for the mentioned patterns is simple. However ZeroMQ offers two orthogonal set of "abstractions": * the patterns, which can be natively implemented in Erlang; * the transports, some of which can't be implemented in pure Erlang (e.g. UNIX socket domains); * (let alone the other features such as HVM, and the new additions in 4.x); And the true power of ZeroMQ lies in the various ways we can combine the above features, all interoperable from one language to the other. Thus having a myriad of partial implementations would just break the ecosystem into isolated islands (like I guess happened with AMQP). However... > ( actually all I want to do is get Erlang talking to Julia - Julia speaks > 0MQ and I found that I > couldn't build the Erlang 0MQ bindings with the latest 0MQ - so I'm again > back to > "fixing stuff thats broken" in order to do what I want. For such a use-case, and other situations where a full ZeroMQ library is not needed, one could take the following shortcut: * he limits the usage to only (X)REQ/REP or PULL/PUSH, with only one frame per interaction (plus the "destination" one in case of XREP, and a "correlation" in case of parallel request / reply sessions); * he builds a simple C application which reads / writes on stdin / stdout messages in the well-supported format (maybe one per "destination", "correlation" and "payload") and translates that to a ZeroMQ `send` / `recv`; * he then just uses this executable with `open_port` with `packet` option; (which in fact it could be reused in other non-Erlang environments;) Of course if more about the application is known, one could make other "simplifications", like use only JSON without embedded newlines, and transform the protocol into one line per message (such an application could be used even from `sh`). Moreover such an application could be used at both ends, thus obtaining a poor-man's messaging solution. :) As such I would definitely see the need of both kind of ZeroMQ interfaces for Erlang (or other languages): a binding based one, and a "process" based one. Ciprian. From erlang@REDACTED Sat Feb 8 19:10:58 2014 From: erlang@REDACTED (Joe Armstrong) Date: Sat, 8 Feb 2014 19:10:58 +0100 Subject: [erlang-questions] 0MQ libraries In-Reply-To: References: Message-ID: On Sat, Feb 8, 2014 at 2:39 PM, Ciprian Dorin Craciun < ciprian.craciun@REDACTED> wrote: > (Sorry for "reviving" this thread, but only now I've managed to > drain the mail queue.) :) > > > On Fri, Jan 31, 2014 at 9:12 AM, Joe Armstrong wrote: > > Why don't we just use gen_tcp and interact with 0MQ peers using the > > wire-line protocol. Erlang is good at getting data in and out of sockets, > > and good at parsing binary packets. > > > > I'm not suggesting implementing all the protocols and transports to start > > with just the REQ - REP protocols of TCP > > > > [...] > > > Implementing a pure Erlang ZeroMQ library that understands only > TCP and some of the basic patterns (such as (X)REQ/REP, PULL/PUSH), as > Joe has suggested, could easily be a weekend project (within some > acceptable performance limits), as the wire protocol is almost > trivial, and the routing logic for the mentioned patterns is simple. > > > However ZeroMQ offers two orthogonal set of "abstractions": > * the patterns, which can be natively implemented in Erlang; > * the transports, some of which can't be implemented in pure > Erlang (e.g. UNIX socket domains); > * (let alone the other features such as HVM, and the new additions in > 4.x); > > And the true power of ZeroMQ lies in the various ways we can > combine the above features, all interoperable from one language to the > other. Thus having a myriad of partial implementations would just > break the ecosystem into isolated islands (like I guess happened with > AMQP). > > > However... > > > ( actually all I want to do is get Erlang talking to Julia - Julia speaks > > 0MQ and I found that I > > couldn't build the Erlang 0MQ bindings with the latest 0MQ - so I'm again > > back to > > "fixing stuff thats broken" in order to do what I want. > > For such a use-case, and other situations where a full ZeroMQ > library is not needed, one could take the following shortcut: > * he limits the usage to only (X)REQ/REP or PULL/PUSH, with only > one frame per interaction (plus the "destination" one in case of XREP, > and a "correlation" in case of parallel request / reply sessions); > * he builds a simple C application which reads / writes on stdin / > stdout messages in the well-supported format > (maybe one per "destination", "correlation" and "payload") and > translates that to a ZeroMQ `send` / `recv`; > * he then just uses this executable with `open_port` with `packet` > option; (which in fact it could be reused in other non-Erlang > environments;) > > Of course if more about the application is known, one could make > other "simplifications", like use only JSON without embedded newlines, > and transform the protocol into one line per message (such an > application could be used even from `sh`). Moreover such an > application could be used at both ends, thus obtaining a poor-man's > messaging solution. :) > > > As such I would definitely see the need of both kind of ZeroMQ > interfaces for Erlang (or other languages): a binding based one, and a > "process" based one. > Absolutely - I want to send message to 0MQ the "erlang way" To send a message to 0MQ I should say Zmq ! IoList and *not* call an erlang routine that is the equivalent of some C routine in the ZMQ libraries The Erlang Zmq ! Msg should pack data in the appropriate wire-line format and blast it onto the wire. Incoming messages should be parsed and sent to the appropriate message. The trick is to make an interface that makes ZMQ endpoints look and feel like erlang processes. We should not "know" that they are ZMQ endpoints. So socket closes should be converted to exit signals and so on. When we talk to Julia we have to perform a load of data conversions - an erlang list is [1,2,3] and a julia list is [1 2 3] somebody somewhere must do some conversion. I was thinking that Erlang could send julia data structures down the wire, and Julia could send Erlang structures down the wire since it's far easier to generate Julia in Erlang than parse it, and in Julia it will be easier to generate Erlang than parse it. JSON would be equally bad for both sides. /Joe > > Ciprian. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge@REDACTED Sat Feb 8 19:49:33 2014 From: serge@REDACTED (Serge Aleynikov) Date: Sat, 8 Feb 2014 13:49:33 -0500 Subject: [erlang-questions] 0MQ libraries In-Reply-To: References: Message-ID: Just to add a piece of history - I was an author of the original driver-based implementation of the Erlang ZMQ binding ( https://github.com/zeromq/erlzmq), which got more or less obsolete after Yurii Rashkovskii implemented his NIF-based version ( https://github.com/zeromq/erlzmq2). Concerning your question, I haven't had a use for this project for a while, but if there is anyone wishing to join the project and bring it up to date that would be great. Though I agree that a pure-Erlang wire-level implementation would be of greater interest. Serge On Thu, Jan 30, 2014 at 4:13 PM, Joe Armstrong wrote: > Is anybody working on upgrading the 0MQ libraries for erlang to > the latest version of 0QM. > > /Joe > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattevans123@REDACTED Sun Feb 9 00:01:58 2014 From: mattevans123@REDACTED (Matthew Evans) Date: Sat, 8 Feb 2014 18:01:58 -0500 Subject: [erlang-questions] Erlang term to ASCII In-Reply-To: References: , , , Message-ID: The way I did it recently was (a bit convoluted): LookingPrettierTerm = lists:flatten(io_lib:format("~p",[NastyTerm])), LookingEvenPrettierTerm = re:replace(LookingPrettierTerm, "\\s+", "", [global,{return,list}]), io:fwrite("Term looking pretty ~s~n",[LookingEvenPrettierTerm]), Date: Fri, 7 Feb 2014 14:49:29 -0800 From: bob@REDACTED To: a.brandon.clark@REDACTED CC: erlang-questions@REDACTED Subject: Re: [erlang-questions] Erlang term to ASCII Hashing of a string representation is probably not a great way to ensure that both systems agree on that structure. Even different versions of Erlang disagree on what exactly the representation of ~p should be for a given term, and I'm not talking about whitespace. It's simply not well suited for your purpose, even though it might appear to work for most of the cases you have now. You could write your own Erlang implementation of whatever the CMS does, but you're unlikely to implement it correctly by taking "~p" and then trying to normalize the output. You really should come up with a scheme to either hash the data structure itself (like Erlang's phash2 but portable to both sides of your system), or you should hash the output of a representation that has absolutely no flexibility in how data is encoded. Erlang's External Term Format is a lot closer, but there are still multiple valid ways to encode the same thing (particularly the atom cache table, using bigger encodings than necessary, etc.). On Fri, Feb 7, 2014 at 2:16 PM, Brandon Clark wrote: The non-Erlang app is an in-house configuration management system. It stores configuration settings in a SQL database and produces the app.config file used by my Erlang app on demand via REST interface; the configuration is delivered as a string in the body of an HTTP response. My ultimate goal is to rework the Erlang app so that it fetches and applies most configuration updates automatically without restarting. For the near term, that means I have to cope with strings. In the long term, though, I have some sway over what the CMS does, provided I'm willing to get my hands dirty. ("Don't bring problems -- bring solutions.") I'm in favor of Erlang external terms and I think I can sell that solution with BERT and BERT-RPC. Regardless of how we transmit the data, we still need a way to confirm that both systems agree on what the data structure contains. The current favored solution is to ask both systems to compute a hash of their data. We can normalize the data any way we want in preparation for hashing as long as both sides do it in exactly the same way. Since the CMS is already pretty good at building Erlang terms as strings without newlines or indentation, I set out to find a way to make Erlang do the same thing. ~BC On Fri, Feb 7, 2014 at 11:16 AM, Bob Ippolito wrote: How is this other system maintaining the deeply-nested Erlang structure? How or why is it in text? How does it get rendered without newlines and indentation? Why not use a more predictable (less flexible) serialization format (erlang term format, JSON, protocol buffers, ?)? I do not think that this is the best approach. There are many possible representations of various tokens as Erlang source code and I would never trust two implementations to render it exactly the same way unless I wrote both of them. Some tokens that are going to be particularly problematic are lists of integers (which may or may not be rendered like strings, with various ways to escape), binaries (which may be rendered like strings or not), and floating point numbers. On Fri, Feb 7, 2014 at 10:17 AM, Brandon Clark wrote: I have 2 production systems, one Erlang and one not, both maintaining copies of a large, deeply-nested Erlang data structure. I need to set up a monitoring script to confirm that both systems are holding identical copies of the data structure. The non-Erlang system is holding an ASCII rendering of the data structure. Computing an MD5 sum of this string is easy. If I can get the Erlang system to convert its data structure to a string, I can have it compute an MD5 sum as well and the monitoring is simply a matter of comparing hashes. I'm stuck on the process of converting the Erlang term to a string. Str = io_lib:format("~p", [Data]) gives me what I want, except that it includes newlines and indentation that I can't expect the non-Erlang system to have. Str = io_lib:format("~w", [Data]) eliminates the newlines and indentation but renders the textual components of Data as lists of integers, guaranteeing the result won't match the non-Erlang system. So the question is, how do I get a "~p"-style rendering of an arbitrarily-large Erlang term without newlines and indentation? Thank you! ~Brandon Clark _______________________________________________ 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 eriksoe@REDACTED Sun Feb 9 01:11:38 2014 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Sun, 9 Feb 2014 01:11:38 +0100 Subject: [erlang-questions] Erlang term to ASCII In-Reply-To: References: Message-ID: That wouldn't work for spaces in strings and binaries. You'd have to restrict it to /^\s+/. Den 09/02/2014 00.02 skrev "Matthew Evans" : > The way I did it recently was (a bit convoluted): > > LookingPrettierTerm = lists:flatten(io_lib:format("~p",[NastyTerm])), > LookingEvenPrettierTerm = re:replace(LookingPrettierTerm, "\\s+", "", > [global,{return,list}]), > io:fwrite("Term looking pretty ~s~n",[LookingEvenPrettierTerm]), > > > ------------------------------ > Date: Fri, 7 Feb 2014 14:49:29 -0800 > From: bob@REDACTED > To: a.brandon.clark@REDACTED > CC: erlang-questions@REDACTED > Subject: Re: [erlang-questions] Erlang term to ASCII > > Hashing of a string representation is probably not a great way to ensure > that both systems agree on that structure. Even different versions of > Erlang disagree on what exactly the representation of ~p should be for a > given term, and I'm not talking about whitespace. It's simply not well > suited for your purpose, even though it might appear to work for most of > the cases you have now. > > You could write your own Erlang implementation of whatever the CMS does, > but you're unlikely to implement it correctly by taking "~p" and then > trying to normalize the output. > > You really should come up with a scheme to either hash the data structure > itself (like Erlang's phash2 but portable to both sides of your system), or > you should hash the output of a representation that has absolutely no > flexibility in how data is encoded. Erlang's External Term Format is a lot > closer, but there are still multiple valid ways to encode the same thing > (particularly the atom cache table, using bigger encodings than necessary, > etc.). > > > On Fri, Feb 7, 2014 at 2:16 PM, Brandon Clark wrote: > > The non-Erlang app is an in-house configuration management system. It > stores configuration settings in a SQL database and produces the app.config > file used by my Erlang app on demand via REST interface; the configuration > is delivered as a string in the body of an HTTP response. > > My ultimate goal is to rework the Erlang app so that it fetches and > applies most configuration updates automatically without restarting. For > the near term, that means I have to cope with strings. In the long term, > though, I have some sway over what the CMS does, provided I'm willing to > get my hands dirty. ("Don't bring problems -- bring solutions.") I'm in > favor of Erlang external terms and I think I can sell that solution with > BERT and BERT-RPC. > > Regardless of how we transmit the data, we still need a way to confirm > that both systems agree on what the data structure contains. The current > favored solution is to ask both systems to compute a hash of their data. > We can normalize the data any way we want in preparation for hashing as > long as both sides do it in exactly the same way. Since the CMS is already > pretty good at building Erlang terms as strings without newlines or > indentation, I set out to find a way to make Erlang do the same thing. > > ~BC > > > > > > > On Fri, Feb 7, 2014 at 11:16 AM, Bob Ippolito wrote: > > How is this other system maintaining the deeply-nested Erlang structure? > How or why is it in text? How does it get rendered without newlines and > indentation? Why not use a more predictable (less flexible) serialization > format (erlang term format, JSON, protocol buffers, ...)? > > I do not think that this is the best approach. There are many possible > representations of various tokens as Erlang source code and I would never > trust two implementations to render it exactly the same way unless I wrote > both of them. Some tokens that are going to be particularly problematic are > lists of integers (which may or may not be rendered like strings, with > various ways to escape), binaries (which may be rendered like strings or > not), and floating point numbers. > > > > > On Fri, Feb 7, 2014 at 10:17 AM, Brandon Clark wrote: > > I have 2 production systems, one Erlang and one not, both maintaining > copies of a large, deeply-nested Erlang data structure. I need to set up a > monitoring script to confirm that both systems are holding identical copies > of the data structure. > > The non-Erlang system is holding an ASCII rendering of the data structure. > Computing an MD5 sum of this string is easy. If I can get the Erlang > system to convert its data structure to a string, I can have it compute an > MD5 sum as well and the monitoring is simply a matter of comparing hashes. > > I'm stuck on the process of converting the Erlang term to a string. > > Str = io_lib:format("~p", [Data]) > > gives me what I want, except that it includes newlines and indentation > that I can't expect the non-Erlang system to have. > > Str = io_lib:format("~w", [Data]) > > eliminates the newlines and indentation but renders the textual components > of Data as lists of integers, guaranteeing the result won't match the > non-Erlang system. > > So the question is, how do I get a "~p"-style rendering of an > arbitrarily-large Erlang term *without* newlines and indentation? > > Thank you! > > ~Brandon Clark > > > _______________________________________________ > 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 mabrek@REDACTED Sun Feb 9 11:39:18 2014 From: mabrek@REDACTED (Anton Lebedevich) Date: Sun, 9 Feb 2014 14:39:18 +0400 Subject: [erlang-questions] Simple Logging In-Reply-To: References: Message-ID: You might need to setup kernel error_logger in addition to sasl_error_logger. On Mon, Feb 3, 2014 at 10:20 PM, Niklas Semmler wrote: > Hi there, > > What does it take to get a simple logger running? > - multiple logfiles > - path = "./log/" > - log errors, warnings(!) but no progress reports > > I tried the following configuration: > [{sasl, [ > {sasl_error_logger, false}, > {errlog_type, error}, > {error_logger_mf_dir,"./log"}, > {error_logger_mf_maxbytes, 10485760}, > {error_logger_mf_maxfiles, 2} > ]}]. > > I get errors and progress reports, but no warning or info messages. Stackoverflow says log_mf_h ignores errlog_type. > http://stackoverflow.com/questions/5649332/sasl-stores-progress-report-despite-errlog-type-error > > But I don't find a way to fix this. I know there is the option to write my own gen_event handler, but I don't feel firm enough in Erlang to do that just yet. Existing handlers performed poorly. > > How can I implement this simple logger? > > -- Niklas > > PS: Lager is unfortunately not an option as I have to avoid any unnecessary dependencies. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From erlang@REDACTED Sun Feb 9 14:04:31 2014 From: erlang@REDACTED (Joe Armstrong) Date: Sun, 9 Feb 2014 14:04:31 +0100 Subject: [erlang-questions] 0MQ libraries In-Reply-To: References: Message-ID: On Sat, Feb 8, 2014 at 7:49 PM, Serge Aleynikov wrote: > Just to add a piece of history - I was an author of the original > driver-based implementation of the Erlang ZMQ binding ( > https://github.com/zeromq/erlzmq), which got more or less obsolete after > Yurii Rashkovskii implemented his NIF-based version ( > https://github.com/zeromq/erlzmq2). > > Concerning your question, I haven't had a use for this project for a > while, but if there is anyone wishing to join the project and bring it up > to date that would be great. Though I agree that a pure-Erlang wire-level > implementation would be of greater interest. > I'm only interested in the pure erlang solution. NIFs worry me. They break the guarantees, they muck up the scheduler and so on. They should only be used when you've tried very very very vary hard not to use them. In the problem I want to solve I don't expect communication to be a bottleneck. I'd like a 100% correct Erlang reference implementation of 0MQ. This (if done) might have the interesting side effect that it could be used (say with quick check) test the C-implementations of 0MQ. Cheers /Joe > > Serge > > > On Thu, Jan 30, 2014 at 4:13 PM, Joe Armstrong wrote: > >> Is anybody working on upgrading the 0MQ libraries for erlang to >> the latest version of 0QM. >> >> /Joe >> >> _______________________________________________ >> 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 Sun Feb 9 14:45:23 2014 From: g@REDACTED (Garrett Smith) Date: Sun, 9 Feb 2014 07:45:23 -0600 Subject: [erlang-questions] 0MQ libraries In-Reply-To: References: Message-ID: On Sun, Feb 9, 2014 at 7:04 AM, Joe Armstrong wrote: > > > > On Sat, Feb 8, 2014 at 7:49 PM, Serge Aleynikov wrote: >> >> Just to add a piece of history - I was an author of the original >> driver-based implementation of the Erlang ZMQ binding >> (https://github.com/zeromq/erlzmq), which got more or less obsolete after >> Yurii Rashkovskii implemented his NIF-based version >> (https://github.com/zeromq/erlzmq2). >> >> Concerning your question, I haven't had a use for this project for a >> while, but if there is anyone wishing to join the project and bring it up to >> date that would be great. Though I agree that a pure-Erlang wire-level >> implementation would be of greater interest. > > > I'm only interested in the pure erlang solution. NIFs worry me. They break > the guarantees, they muck > up the scheduler and so on. They should only be used when you've tried very > very very vary hard > not to use them. > > In the problem I want to solve I don't expect communication to be a > bottleneck. > > I'd like a 100% correct Erlang reference implementation of 0MQ. This (if > done) might have the interesting > side effect that it could be used (say with quick check) test the > C-implementations of 0MQ. +1 on the pure Erlang implementation. Additionally, for those interested in using ZeroMQ with Erlang today, the CZMQ bindings are *not* NIF based - they run as a C port in a separate OS process with no chance of taking the VM down. CZMQ is an API wrapper for ZeroMQ that makes it easier to keep up-to-date with ZeroMQ changes. CZMQ also provides some very nice security features including message encryption. Again, the link for those interested: https://github.com/zeromq/czmq I'd be happy to move this along if people show interest, in particular the docs, tutorials, etc. While the code is running in a pre-production/test environment, it's so far stable for what's there. To get started, I recommend looking over the tests and playing around in the Erlang shell. I'm giving a talk on this library in San Francisco on March 6: http://www.erlang-factory.com/conference/show/conference-6/home/ (Web site doesn't provide talk links unfortunately - just search for CZMQ) Garrett From g@REDACTED Sun Feb 9 14:47:20 2014 From: g@REDACTED (Garrett Smith) Date: Sun, 9 Feb 2014 07:47:20 -0600 Subject: [erlang-questions] 0MQ libraries In-Reply-To: References: Message-ID: On Sun, Feb 9, 2014 at 7:45 AM, Garrett Smith wrote: > Additionally, for those interested in using ZeroMQ with Erlang today, > the CZMQ bindings are *not* NIF based - they run as a C port in a > separate OS process with no chance of taking the VM down. CZMQ is an > API wrapper for ZeroMQ that makes it easier to keep up-to-date with > ZeroMQ changes. CZMQ also provides some very nice security features > including message encryption. > > Again, the link for those interested: > > https://github.com/zeromq/czmq Correction, this is the Erlang CZMQ binding: https://github.com/gar1t/erlang-czmq Garrett From antoine.koener@REDACTED Sun Feb 9 19:40:48 2014 From: antoine.koener@REDACTED (Antoine Koener) Date: Sun, 9 Feb 2014 19:40:48 +0100 Subject: [erlang-questions] Mongoose IM Documentation In-Reply-To: References: Message-ID: <432C4313-C420-4439-A659-05869111DED1@gmail.com> Hello Kelly: You may look at the code in "ejabberd_sm.erl" file, and specifically to this hook: ejabberd_hooks:run(offline_message_hook, LServer, [From, To, Packet]); Thus modules: mod_offline.erl and mod_offline_odbc.erl should get you started. Hope it helps :-) Le 7 f?vr. 2014 ? 22:43, Kelly Wong a ?crit : > Hi Michal, > > Thanks for the link. I'm trying to figure out what hooks I can set and when they're called. The end goal is to write a plugin that can send an Apple notification service message to a user who is not online. I was thinking I could write a plugin that intercepts messages to offline users. Is that the right way to go about things? > > Thanks, > Kelly Wong > > > On Wed, Feb 5, 2014 at 11:18 PM, Michal Piotrowski wrote: > Hello Kelly, > > There are some examples on our github: https://github.com/esl/MongooseIM. > The default installation of MongooseIM works with mnesia as a database. > What exactly do you need to know? > > BTW, the config file is in most cases compatible with the one in ejabberd 2.1.x. > > Best regards > Michal Piotrowski > michal.piotrowski@REDACTED > > > On 05 Feb 2014, at 03:10, Kelly Wong wrote: > >> Hello, >> >> I'm trying to setup Mongoose IM, but for the life of me can't find any documentation for it. Can anyone point me in the right direction? >> >> Thanks, >> Kelly Wong >> _______________________________________________ >> 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 ce.rfjacob@REDACTED Sun Feb 9 14:07:51 2014 From: ce.rfjacob@REDACTED (Rimon Farouk) Date: Sun, 9 Feb 2014 15:07:51 +0200 Subject: [erlang-questions] ASN.1 multiple records Message-ID: Dears; I've succeeded in reading ASN.1 binary files containing single message, but how can i read an ASN.1 binary file containing multiple messages? I cannot find sufficient resources for Erlang dealing with ASN.1 files. Kindly help. Thanks a lot ... Best regards ... Rimon -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.irvine@REDACTED Mon Feb 10 03:11:16 2014 From: chuck.irvine@REDACTED (Charles Irvine) Date: Sun, 09 Feb 2014 20:11:16 -0600 Subject: [erlang-questions] Maps single value access not implemented Message-ID: <8AC108D6-C490-499C-A755-FE85D0BA96C3@icloud.com> I am wanting to experiment with Maps in R17, but just discovered that accessing a single value from a map is not yet implemented. I find this surprising. Isn?t this a most fundamental feature of a map data structure? From sina.samv@REDACTED Mon Feb 10 03:39:33 2014 From: sina.samv@REDACTED (Sina Samavati) Date: Mon, 10 Feb 2014 06:09:33 +0330 Subject: [erlang-questions] Maps single value access not implemented In-Reply-To: <8AC108D6-C490-499C-A755-FE85D0BA96C3@icloud.com> (Charles Irvine's message of "Sun, 09 Feb 2014 20:11:16 -0600") References: <8AC108D6-C490-499C-A755-FE85D0BA96C3@icloud.com> Message-ID: <87iosnvggq.fsf@gmail.com> Charles Irvine writes: > I am wanting to experiment with Maps in R17, but just discovered that > accessing a single value from a map is not yet implemented. I find > this surprising. Isn?t this a most fundamental feature of a map data > structure? Yes, this is. Note that the latest version is *17.0-rc1* which means it is a _pre-release_. We will probably see the complete implementation of Maps[1] in 17.0-rc2. [1]: http://www.erlang.org/eeps/eep-0043.html -- Sina Samavati Software engineer https://github.com/s1n4 https://twitter.com/sinasamavati From ok@REDACTED Mon Feb 10 05:30:22 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 10 Feb 2014 17:30:22 +1300 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: Message-ID: <88514DA0-DC79-4E67-9A11-ADC077BA13E6@cs.otago.ac.nz> The first thing I note is that there is no need for you ever to use square root. [Jon L. Bentley mentions this trick of avoiding the square root in one of his books.] \sqrt{x^2 + y^2 + z^z} \le r if and only if x^2 + y^2 + z^2 \le r^2 in_sphere({X0,Y0,Z0,R}, {X,Y,Z}) -> (DX = abs(X - X0)) =< R andalso (DY = abs(Y - Y0)) =< R andalso (DZ = abs(Z - Z0)) =< R andalso DX*DX + DY*DY + DZ*DZ =< R*R. Unpack, precompute: in_sphere(X0, Y0, Z0, R, R2, {X,Y,Z}) -> (DX = abs(X - X0)) =< R andalso (DY = abs(Y - Y0)) =< R andalso (DZ = abs(Z - Z0)) =< R andalso DX*DX + DY*DY + DZ*DZ =< R*R. cull({X0,Y0,Z0}, R, Vectors) -> R2 = R*R, [V || V <- Vectors, in_sphere(X0, Y0, Z0, R, R2, V)]. If your task (like selecting elements from a list) fits what a list comprehension can express clearly, you should normally use a list comprehension rather than your own recursive function, just because it is so much easier to see at a glance what is going on. On 7/02/2014, at 8:25 PM, kraythe . wrote: > I am a newbie to erlang so please excuse the newbie questions. To learn the language I have a use case, simply to take a vector C which defines the center of a sphere with radius R and then cull a list of vectors and return only the vectors in the sphere. A simple math problem the most efficient method is to calculate the difference in C and a vector V and if any component is greater than R then the vector can't be in the sphere, if not then we have to do the expensive sort magnitude calculation. > > To this end I have created a simple set of functions: > -module(vector3d). > -author("rsimmons"). > > %% API > -export([subtract/2, magnitude/1, scale/2, cull/3]). > > %% Subtract the second vector from the first > subtract({X1, Y1, Z1}, {X2, Y2, Z2}) -> {(X1 - X2), (Y1 - Y2), (Z1 - Z2)}. > > %% Compute the magnitude of the vector > magnitude({X, Y, Z}) -> math:sqrt((X * X) + (Y * Y) + (Z * Z)). > > %% Determines if any coordinate in the given vector is bigger than the passed in value V. > coordinateGreaterThan(V, {X, Y, Z}) when X > V; Y > V; Z > V -> true; > coordinateGreaterThan(_, _) -> false. > > %% Culls the list of vectors X to only those that are in the sphere devined by vector C as a center and R as a radius. > cull(C, R, Vectors) when is_number(R), is_tuple(C) -> cull(C, R, Vectors, []). > cull(C, R, Culled, []) -> Culled; > cull(C, R, Culled, [Head|Tail]) -> > D = subtract(C, Head), > case coordinateIsGreaterThan(R, Head) of > true -> cull(C, R, Culled, Tail); > false -> cullOnMagnitude(C, R, D, Culled, Head, Tail) > end. > > cullOnMagnitude(C, R, D, Culled, Head, Tail) when is_tuple(D), is_number(R) -> > M = magnitude(D), > if M > R -> cull(C, R, Culled, Tail); > true -> cull(C, R, [Head | Culled], Tail) > end. > > When I load these into a file and compile them I get the following result: > > 16> c(vector3d). > vector3d.erl:53: function coordinateIsGreaterThan/2 undefined > vector3d.erl:45: Warning: function coordinateGreaterThan/2 is unused > vector3d.erl:50: Warning: variable 'C' is unused > vector3d.erl:50: Warning: variable 'R' is unused > > Note that there are some other methods in this file so the line numbers will vary. My questions are: > > 1) Why is it saying my coordinateIsGreaterThan/2 method is undefined when I can see it here and then to say it is unused in the next line? Because, asYouMightHavePredicted, itIsHardToRead wordsJammedTogetherLikeThis. You *define* (coordinate)(Greater)(Than)/2 but you *call* (coordinate)(Is)(Greater)(Than)/2. If you separated the words so that you could read them like text -- which is indeed the usual Erlang style, thisIsNotJava -- it would be easier to see the presence of "is" in coordinate_is_greater_than or the absence of "is" in coordinate_greater_than. > 3) I understand the variables not being used but it seems odd to me from the java language world to not define the names for the variables. Is this normal in erlang? There is a big difference between "I have to have _some_ variable name in here so I've slapped something in and I don't care what it is" and "OOPS! I _meant_ to use this name but accidentally left out a line." In fact this happened to me in this reply. In in_sphere/6, I had introduced R2, but forgot to replace R*R by R2. Erlang warned me that R2 was unused. I *needed* that warning. It is not unusual for compilers, even for imperative languages like Java (yes, it is OO, but OO is a subclass of imperative) to warn about variables whose values are not used. See the "-Wunused..." command line options for GCC, for example. Those warnings are available because they very often indicate an error. I would expect good Java programmers to use checking tools at least as good as FindBugs. "DLS: Dead store to local variable (DLS_DEAD_LOCAL_STORE)" is one of the things FindBugs checks for. "This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used." So it is normal in Erlang to use A_Normal_Variable_Name when you intend the value to be used _ when you intend the value NOT to be used _Flagged_Variable_Name when you intend the value NOT to be used and want to be clear about what it is you are not using. Turn to the definition > magnitude({X, Y, Z}) -> math:sqrt((X * X) + (Y * Y) + (Z * Z)). That has a style problem: the obfuscatory excess parentheses. magnitude({X,Y,Z}) -> math:sqrt(X*X + Y*Y + Z*Z). It also has a numeric problem. There's a reason why C has the hypot() function. It's a crying shame that Erlang doesn't have it. If you are willing to live with avoidable problems of X*X+Y*Y+Z*Z, then as noted above you can avoid sqrt by comparing against R*R. What are those problems? Overflow when overflow is not necessary; underflow (and possible flush to zero) when underflow is not necessary. Yes, it is possible to find X,Y,Z,R such that in real arithmetic sqrt(X*X+Y*Y+Z*Z) > R but in floating point arithmetic X*X+Y*Y+Z*Z is zero. This has nothing to do with Erlang and everything to do with floating point arithmetic. But wait! Did I say this has nothing to do with Erlang? Wrong! If DX, DY, DZ, and R are *integers*, then DX*DX + DY*DY + DZ*DZ =< R*R will NOT overflow in Erlang, it will just give you precisely correct answers. If in your problem, your co-ordinates and radii are integers, Erlang lets you stop worrying IF you avoid the square root. With the square root eliminated, it's not clear that the early exit checks pay for themselves. You might find that in_sphere(X0, Y0, Z0, R, R2, {X,Y,Z}) -> DX = X - X0, DY = Y - Y0, DZ = Z - Z0, DX*DX + DY*DY + DZ*DZ =< R*R. is as fast as you need. By the way, can I suggest _not_ using the word 'cull'. It is usually easier to understand if you focus on the description of the elements you DO want (that is, what to KEEP) rather than the description of the elements you DON'T want. Again, this is real: I got confused in exactly this way by your code. In English, when we "cull", we specify which animals are to *go* (cull the sick and deformed), not the ones we want to *keep*. Cull "cull" from your programming vocabulary. A better name in this case would be something like filter_points_in_sphere(Sphere, Points) -> Filtered_Points. Why "filter"? When you filter coffee, the coffee is what you *keep*, so natural language does not mislead us, and "filter" is the conventional name in functional programming generally and Erlang specifically for "KEEP selected elements of this list". From ok@REDACTED Mon Feb 10 05:35:44 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 10 Feb 2014 17:35:44 +1300 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: Message-ID: <6F37D98B-2673-4876-BEE6-A918225AD241@cs.otago.ac.nz> On 8/02/2014, at 3:47 AM, kraythe . wrote: > Man I feel silly. but then I am fighting a chest cold. I guess this happens easier when you don't have completion or highlighting that I am used to in an IDE. Did you try typing Erlang IDE into the search box in a web browser? Top of the list, http://www.erlang.org/faq/tools.html has a section (7.7) on IDEs. The three I see mentioned a lot are - distel (Emacs) - ErlIDE (Eclipse) - IntelliJ IDEA syntax colouring is certainly available for Vim and BBEdit as well. I was pleasantly surprised to see that there's an Erlang plugin for NetBeans, called ErlyBird (http://sourceforge.net/projects/erlybird/) which specifically offers syntax checking, syntax highlighting, auto-completion, pretty formatter, occurrences mark, brace matching, indentation, code folding, function navigator, go to declaration, project management, shell console From ok@REDACTED Mon Feb 10 05:59:53 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 10 Feb 2014 17:59:53 +1300 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: Message-ID: <71D26997-BBC2-41F7-BCAB-592E45D28609@cs.otago.ac.nz> On 8/02/2014, at 4:53 AM, kraythe . wrote: > Anyway back to the subject at hand. The algorithm is set but now I am at another quandary Lets say these vectors represent a position in space of particular objects in a simulation. The process of culling the vectors based on the sphere is entirely a vector problem but what the user calling cull/3 really needs to know is which objects are not culled from the list, not just which vectors are not culled. Now in Java I could do a number of things if I wanted to keep the cull algorithm as it is. I could return the list of integers containing the original indexes of the vectors in the list that were culled and use that to filter out which objects need to be considered for the simulation step. The word "cull" really grates. And all those negations *really* confused me *all over again*. I wrote a lengthy and helpful description of how to get the points that were accepted and the points that were rejected as two lists, because that was the only way I could interpret your question to make sense in Erlang. But on repeated re-reading it became clear that you were asking for something else. There is no such thing in Erlang as object identity. The distinction you are drawing between the "points" and the "objects" simply doesn't exist. It so happens that if you use a list comprehension like [P || P <- Points, some_predicate(P)] the elements of the result *will* be (references to) the same implementation-level webs of chunks of memory that were in the original list, not copies. But nothing other than performance depends on this. A list of integers such as you ask for could be obtained, but it would be very little use to you, because Erlang lists are *LINKED LISTS*, not *INDEXED ARRAYS*. Finding the nth element of a list takes O(n) time, and that could not be changed without making lists much less useful. From bengt.kleberg@REDACTED Mon Feb 10 08:01:12 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Mon, 10 Feb 2014 08:01:12 +0100 Subject: [erlang-questions] Indentation of multiline strings In-Reply-To: References: Message-ID: <1392015672.4926.23.camel@sekic1152.release> Greetings, One reason against a standalone formatter is that it could introduce bugs in the code. That this is only a problem with a standalone formatter is probably based upon that nobody would use a editor based formatter and then not compile/test after wards. To make a stand alone formatter with better level of confidence I suggest using Erlang/OTP tools to create one of the intermediate level formats (Core Erlang, "parse trees", the simplest/quickest/...) that removes formatting. If this is done before and after the standalone formatting, and the result is the same, then no bugs have been introduced. bengt On Fri, 2014-02-07 at 17:19 +0100, Vlad Dumitrescu wrote: > On Fri, Feb 7, 2014 at 4:27 PM, Steve Vinoski wrote: > > First, let's assume there's general agreement in the community that emacs > > erlang-mode is the de facto standard for erlang code formatting, and is thus > > the starting point for developing a formatting specification. I believe > > you're basing your work on this assumption, Vlad, and if so I agree with > > that approach, but if not please correct me. > > That's correct. > > > Some might object to using > > erlang-mode as the starting point on the basis that other editors sometimes > > have a hard time formatting code the same way erlang-mode does, but I > > believe most of the OTP team and most of the Erlang community uses emacs and > > erlang-mode, so I view it as the most practical starting point. > > Other editors will still have to implement a formatter/indenter. I > think the issues they have today are mostly related to mixing tabs and > spaces, but since Anthony said that his patches only have spaces and > there were no issues, that would simplify it. > > > To create a formatting specification, I recommend that if you haven't done > > so already, start collecting cases like the multiline string and binary > > cases where erlang-mode fails, and report them as bugs against erlang-mode. > > Obviously this applies to anyone who wishes to help. > > I think that I will start by specifying how erlang-mode indents today. > That would be mostly a case of looking at the test file in the sources > and extract the data by inspection. The vision is to not only specify > an indenter, but even a pretty printer. Here I must credit Tuncer for > starting a discussion with me for a couple of weeks ago. > > > To resolve those bugs, we may need to form a small group that can decide how > > erlang-mode should format the problematic cases. A good choice for > > volunteers here are the primary erlang-mode maintainer and some willing > > subset of those who have recently contributed code and patches to > > erlang-mode. As one of those people, I'm willing to help with that, and also > > willing to help resolve the bugs in erlang-mode so it conforms to the > > specification you're putting together. > > Great, thanks! > > > I assume that during this effort someone -- probably you Vlad, but I know of > > other parties also interested -- would be writing a new tool that also > > conforms to the formatting specification. Having such a tool would give us > > at least two independent implementations of the spec. > > Yes, it would be useful to have an Erlang-based tool too. I can use it > from erlide, so I don't need to write anything in Java. > /Vlad > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From essen@REDACTED Mon Feb 10 10:01:43 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 10 Feb 2014 10:01:43 +0100 Subject: [erlang-questions] Maps single value access not implemented In-Reply-To: <87iosnvggq.fsf@gmail.com> References: <8AC108D6-C490-499C-A755-FE85D0BA96C3@icloud.com> <87iosnvggq.fsf@gmail.com> Message-ID: <52F89577.6000405@ninenines.eu> On 02/10/2014 03:39 AM, Sina Samavati wrote: > Charles Irvine writes: > >> I am wanting to experiment with Maps in R17, but just discovered that >> accessing a single value from a map is not yet implemented. I find >> this surprising. Isn?t this a most fundamental feature of a map data >> structure? > > Yes, this is. No it's not. Personally I find it completely unnecessary. Look at how records are used, people tend to match everything they need in the function head because it makes the code clearer. It'll be the same with maps. It'd really only be useful in the shell because there's no function heads there. > Note that the latest version is *17.0-rc1* which means it is a _pre-release_. > We will probably see the complete implementation of Maps[1] in 17.0-rc2. No it will not be complete. Variables as key will most likely not be ready for R17. Large maps will also be slow. What you have now is pretty much what you will get, as the focus is on stabilizing what's done so far, rather than risk shipping breaking bugs. -- Lo?c Hoguin http://ninenines.eu From abdoo.mahran@REDACTED Mon Feb 10 10:18:23 2014 From: abdoo.mahran@REDACTED (Abd El-Fattah Mahran) Date: Mon, 10 Feb 2014 11:18:23 +0200 Subject: [erlang-questions] ASN.1 multiple records In-Reply-To: References: Message-ID: Dear Rimon, Consider you have SDCDR.asn and ASN1 configuration file SDCDR.asn1config *** Compile .asn File* asn1ct:compile("SDCDR", [ber_bin, optimize, verbose, driver, undec_rest]). *** Compile .asn File with configuration file .asn1config* asn1ct:compile("SDCDR", [ber_bin, optimize, verbose, driver, asn1config, undec_rest]). *** Steps For decoding .asn file* {ok, F} = file:read_file("SDPCDR_sdp01a.ASN"). rr('SDCDR'). {ok, {lifeCycleChange, LifeCycleChange}, Rest} = 'SDCDR':decode('SDPCallDataRecord', F). *** Use Rest Variable to get the Rest of the data.* {ok, {accountAdjustment, AccountAdjustment}, Rest1} = 'SDCDR':decode('SDPCallDataRecord', Rest). Thanks, best regards, On Sun, Feb 9, 2014 at 3:07 PM, Rimon Farouk wrote: > Dears; > > I've succeeded in reading ASN.1 binary files containing single message, > but how can i read an ASN.1 binary file containing multiple messages? > I cannot find sufficient resources for Erlang dealing with ASN.1 files. > Kindly help. > > Thanks a lot ... > Best regards ... > Rimon > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Thanks Best Regards, Abd El-Fattah Mahran http://www.linkedin.com/in/abdoomahran -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Mon Feb 10 12:51:37 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 10 Feb 2014 15:51:37 +0400 Subject: [erlang-questions] Maps single value access not implemented In-Reply-To: <52F89577.6000405@ninenines.eu> References: <8AC108D6-C490-499C-A755-FE85D0BA96C3@icloud.com> <87iosnvggq.fsf@gmail.com> <52F89577.6000405@ninenines.eu> Message-ID: In the shell we have the same problems with unwrapping {ok, Value} tuples, so nothing unusual. Just new piece of shell inconvenience with better code behaviour. -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Mon Feb 10 12:53:29 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 10 Feb 2014 12:53:29 +0100 Subject: [erlang-questions] Maps single value access not implemented In-Reply-To: <8AC108D6-C490-499C-A755-FE85D0BA96C3@icloud.com> References: <8AC108D6-C490-499C-A755-FE85D0BA96C3@icloud.com> Message-ID: maps:get/2. -- Anthony Ramine Le 10 f?vr. 2014 ? 03:11, Charles Irvine a ?crit : > I am wanting to experiment with Maps in R17, but just discovered that accessing a single value from a map is not yet implemented. I find this surprising. Isn?t this a most fundamental feature of a map data structure? > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From sina.samv@REDACTED Mon Feb 10 13:10:14 2014 From: sina.samv@REDACTED (Sina Samavati) Date: Mon, 10 Feb 2014 15:40:14 +0330 Subject: [erlang-questions] Maps single value access not implemented In-Reply-To: <52F89577.6000405@ninenines.eu> (=?utf-8?Q?=22Lo=C3=AFc?= Hoguin"'s message of "Mon, 10 Feb 2014 10:01:43 +0100") References: <8AC108D6-C490-499C-A755-FE85D0BA96C3@icloud.com> <87iosnvggq.fsf@gmail.com> <52F89577.6000405@ninenines.eu> Message-ID: <87eh3bkw2h.fsf@gmail.com> Lo?c Hoguin writes: > On 02/10/2014 03:39 AM, Sina Samavati wrote: >> Charles Irvine writes: >> >>> I am wanting to experiment with Maps in R17, but just discovered that >>> accessing a single value from a map is not yet implemented. I find >>> this surprising. Isn?t this a most fundamental feature of a map data >>> structure? >> >> Yes, this is. > > No it's not. I should have said "This is proposed in EEP 43". > Personally I find it completely unnecessary. Look at how records are > used, people tend to match everything they need in the function head > because it makes the code clearer. It'll be the same with maps. It'd > really only be useful in the shell because there's no function heads > there. I absolutely agree on the idea pattern matching over Maps is clearer. If single value access won't be implemented, we will need a bunch of function helpers to play with Maps in shell (I don't know if such functions are implemented or not). >> Note that the latest version is *17.0-rc1* which means it is a _pre-release_. >> We will probably see the complete implementation of Maps[1] in 17.0-rc2. > > No it will not be complete. Variables as key will most likely not be > ready for R17. Large maps will also be slow. What you have now is > pretty much what you will get, as the focus is on stabilizing what's > done so far, rather than risk shipping breaking bugs. I feel much better with that. I guess something in *EEP 43* made Maps complex, I mean, we don't really need all those capabilities for Maps as proposed in _EEP 43_. For example (this is just a friendly feedback not a *complaint*), I think the '=>' operator is enough for both adding a new key and updating an existing key. Thanks for correcting me, Lo?c. -- Sina Samavati Software engineer https://github.com/s1n4 https://twitter.com/sinasamavati From essen@REDACTED Mon Feb 10 13:22:32 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 10 Feb 2014 13:22:32 +0100 Subject: [erlang-questions] Maps single value access not implemented In-Reply-To: <87eh3bkw2h.fsf@gmail.com> References: <8AC108D6-C490-499C-A755-FE85D0BA96C3@icloud.com> <87iosnvggq.fsf@gmail.com> <52F89577.6000405@ninenines.eu> <87eh3bkw2h.fsf@gmail.com> Message-ID: <52F8C488.1040001@ninenines.eu> On 02/10/2014 01:10 PM, Sina Samavati wrote: > I feel much better with that. I guess something in *EEP 43* made Maps complex, > I mean, we don't really need all those capabilities for Maps as proposed in > _EEP 43_. For example (this is just a friendly feedback not a *complaint*), > I think the '=>' operator is enough for both adding a new key and updating an > existing key. The := operator is *very important*. It pretty much means "crash if my code is messed up". This is essential. What makes maps complex is the variable as key in pattern matching. I'll let someone else explain why it's complex, this is above my pay grade. -- Lo?c Hoguin http://ninenines.eu From sina.samv@REDACTED Mon Feb 10 13:54:46 2014 From: sina.samv@REDACTED (Sina Samavati) Date: Mon, 10 Feb 2014 16:24:46 +0330 Subject: [erlang-questions] Maps single value access not implemented In-Reply-To: <52F8C488.1040001@ninenines.eu> (=?utf-8?Q?=22Lo=C3=AFc?= Hoguin"'s message of "Mon, 10 Feb 2014 13:22:32 +0100") References: <8AC108D6-C490-499C-A755-FE85D0BA96C3@icloud.com> <87iosnvggq.fsf@gmail.com> <52F89577.6000405@ninenines.eu> <87eh3bkw2h.fsf@gmail.com> <52F8C488.1040001@ninenines.eu> Message-ID: <87a9dzku09.fsf@gmail.com> Lo?c Hoguin writes: > On 02/10/2014 01:10 PM, Sina Samavati wrote: >> I feel much better with that. I guess something in *EEP 43* made Maps complex, >> I mean, we don't really need all those capabilities for Maps as proposed in >> _EEP 43_. For example (this is just a friendly feedback not a *complaint*), >> I think the '=>' operator is enough for both adding a new key and updating an >> existing key. > > The := operator is *very important*. It pretty much means "crash if my > code is messed up". This is essential. That's true from that perspective. >From another perspective: add or update it, I don't want you to shout at me "Hey, there's no such key", because it will or will not be used. That's it. -- Sina Samavati Software engineer https://github.com/s1n4 https://twitter.com/sinasamavati From essen@REDACTED Mon Feb 10 15:03:02 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 10 Feb 2014 15:03:02 +0100 Subject: [erlang-questions] Maps single value access not implemented In-Reply-To: <87a9dzku09.fsf@gmail.com> References: <8AC108D6-C490-499C-A755-FE85D0BA96C3@icloud.com> <87iosnvggq.fsf@gmail.com> <52F89577.6000405@ninenines.eu> <87eh3bkw2h.fsf@gmail.com> <52F8C488.1040001@ninenines.eu> <87a9dzku09.fsf@gmail.com> Message-ID: <52F8DC16.8030900@ninenines.eu> On 02/10/2014 01:54 PM, Sina Samavati wrote: > Lo?c Hoguin writes: > >> On 02/10/2014 01:10 PM, Sina Samavati wrote: >>> I feel much better with that. I guess something in *EEP 43* made Maps complex, >>> I mean, we don't really need all those capabilities for Maps as proposed in >>> _EEP 43_. For example (this is just a friendly feedback not a *complaint*), >>> I think the '=>' operator is enough for both adding a new key and updating an >>> existing key. >> >> The := operator is *very important*. It pretty much means "crash if my >> code is messed up". This is essential. > > That's true from that perspective. > From another perspective: add or update it, I don't want you to shout at me > "Hey, there's no such key", because it will or will not be used. That's it. There are some uses of maps where you don't care about whether the key already exists. But in all the places where today you would use a record incorrectly (over multiple modules/processes), the := is vital. -- Lo?c Hoguin http://ninenines.eu From sina.samv@REDACTED Mon Feb 10 15:39:37 2014 From: sina.samv@REDACTED (Sina Samavati) Date: Mon, 10 Feb 2014 18:09:37 +0330 Subject: [erlang-questions] Maps single value access not implemented In-Reply-To: <52F8DC16.8030900@ninenines.eu> (=?utf-8?Q?=22Lo=C3=AFc?= Hoguin"'s message of "Mon, 10 Feb 2014 15:03:02 +0100") References: <8AC108D6-C490-499C-A755-FE85D0BA96C3@icloud.com> <87iosnvggq.fsf@gmail.com> <52F89577.6000405@ninenines.eu> <87eh3bkw2h.fsf@gmail.com> <52F8C488.1040001@ninenines.eu> <87a9dzku09.fsf@gmail.com> <52F8DC16.8030900@ninenines.eu> Message-ID: <87ob2ff2vq.fsf@gmail.com> Lo?c Hoguin writes: > On 02/10/2014 01:54 PM, Sina Samavati wrote: >> Lo?c Hoguin writes: >> >>> On 02/10/2014 01:10 PM, Sina Samavati wrote: >>>> I feel much better with that. I guess something in *EEP 43* made Maps complex, >>>> I mean, we don't really need all those capabilities for Maps as proposed in >>>> _EEP 43_. For example (this is just a friendly feedback not a *complaint*), >>>> I think the '=>' operator is enough for both adding a new key and updating an >>>> existing key. >>> >>> The := operator is *very important*. It pretty much means "crash if my >>> code is messed up". This is essential. >> >> That's true from that perspective. >> From another perspective: add or update it, I don't want you to shout at me >> "Hey, there's no such key", because it will or will not be used. That's it. > > There are some uses of maps where you don't care about whether the key > already exists. But in all the places where today you would use a > record incorrectly (over multiple modules/processes), the := is vital. Maybe I'm wrong and my *opinion* isn't good at all, actually that's why I'm in this conversation, just to learn more. -- Sina Samavati Software engineer https://github.com/s1n4 https://twitter.com/sinasamavati From aschultz@REDACTED Mon Feb 10 16:12:36 2014 From: aschultz@REDACTED (Andreas Schultz) Date: Mon, 10 Feb 2014 16:12:36 +0100 (CET) Subject: [erlang-questions] 0MQ libraries In-Reply-To: References: Message-ID: <148425023.96524.1392045156883.JavaMail.zimbra@tpip.net> Hi Joe, gen_zmq is pure Erlang and talks to libzmq 2.0 implementations. Since newer limzmq versions are backward compatible, using it to talk to them should work. In case the gen_socket dependency worries you, that can easily be removed (only used for UNIX sockets). In fact I plan to remove that soonish. There is also rebar support pending in a review: https://github.com/RoadRunnr/gen_zmq/pull/1 Andreas ----- Original Message ----- > > > > On Sat, Feb 8, 2014 at 7:49 PM, Serge Aleynikov < serge@REDACTED > > wrote: > > > > Just to add a piece of history - I was an author of the original driver-based > implementation of the Erlang ZMQ binding ( https://github.com/zeromq/erlzmq > ), which got more or less obsolete after Yurii Rashkovskii implemented his > NIF-based version ( https://github.com/zeromq/erlzmq2 ). > > Concerning your question, I haven't had a use for this project for a while, > but if there is anyone wishing to join the project and bring it up to date > that would be great. Though I agree that a pure-Erlang wire-level > implementation would be of greater interest. > > I'm only interested in the pure erlang solution. NIFs worry me. They break > the guarantees, they muck > up the scheduler and so on. They should only be used when you've tried very > very very vary hard > not to use them. > > In the problem I want to solve I don't expect communication to be a > bottleneck. > > I'd like a 100% correct Erlang reference implementation of 0MQ. This (if > done) might have the interesting > side effect that it could be used (say with quick check) test the > C-implementations of 0MQ. > > Cheers > > /Joe > > > > > Serge > > > On Thu, Jan 30, 2014 at 4:13 PM, Joe Armstrong < erlang@REDACTED > wrote: > > > > Is anybody working on upgrading the 0MQ libraries for erlang to > the latest version of 0QM. > > /Joe > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- -- Dipl. Inform. Andreas Schultz email: as@REDACTED phone: +49-391-819099-224 mobil: +49-170-2226073 ------------------- enabling your networks ------------------- Travelping GmbH phone: +49-391-819099229 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: info@REDACTED GERMANY web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- From ce.rfjacob@REDACTED Mon Feb 10 14:33:48 2014 From: ce.rfjacob@REDACTED (Rimon Farouk) Date: Mon, 10 Feb 2014 15:33:48 +0200 Subject: [erlang-questions] ASN.1 multiple records In-Reply-To: References: Message-ID: Thanks a lot Abdu for your help :) you've given me the key actually :) 'SDCDR':decode('TypeName', Bytes) is returning {ok, DecodedValue} but not returning the Rest. To return the rest use: {DecodedValue, Rest, Length}='SDCDR':decode_disp('TypeName', Bytes) Thanks a lot ... Best regards ... Rimon. On Mon, Feb 10, 2014 at 11:18 AM, Abd El-Fattah Mahran < abdoo.mahran@REDACTED> wrote: > Dear Rimon, > > Consider you have SDCDR.asn and ASN1 configuration file SDCDR.asn1config > > > *** Compile .asn File* > asn1ct:compile("SDCDR", [ber_bin, optimize, verbose, driver, undec_rest]). > > *** Compile .asn File with configuration file .asn1config* > asn1ct:compile("SDCDR", [ber_bin, optimize, verbose, driver, asn1config, > undec_rest]). > > *** Steps For decoding .asn file* > {ok, F} = file:read_file("SDPCDR_sdp01a.ASN"). > > rr('SDCDR'). > {ok, {lifeCycleChange, LifeCycleChange}, Rest} = > 'SDCDR':decode('SDPCallDataRecord', F). > > *** Use Rest Variable to get the Rest of the data.* > {ok, {accountAdjustment, AccountAdjustment}, Rest1} = > 'SDCDR':decode('SDPCallDataRecord', Rest). > > > Thanks, > best regards, > > > On Sun, Feb 9, 2014 at 3:07 PM, Rimon Farouk wrote: > >> Dears; >> >> I've succeeded in reading ASN.1 binary files containing single message, >> but how can i read an ASN.1 binary file containing multiple messages? >> I cannot find sufficient resources for Erlang dealing with ASN.1 files. >> Kindly help. >> >> Thanks a lot ... >> Best regards ... >> Rimon >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > -- > Thanks > Best Regards, > Abd El-Fattah Mahran > http://www.linkedin.com/in/abdoomahran > > -- -------------------------------------- Rimon F. Jacob Mobile +20 10 666 16 234 -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Mon Feb 10 16:18:10 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 10 Feb 2014 19:18:10 +0400 Subject: [erlang-questions] Maps single value access not implemented In-Reply-To: <87ob2ff2vq.fsf@gmail.com> References: <8AC108D6-C490-499C-A755-FE85D0BA96C3@icloud.com> <87iosnvggq.fsf@gmail.com> <52F89577.6000405@ninenines.eu> <87eh3bkw2h.fsf@gmail.com> <52F8C488.1040001@ninenines.eu> <87a9dzku09.fsf@gmail.com> <52F8DC16.8030900@ninenines.eu> <87ob2ff2vq.fsf@gmail.com> Message-ID: I think that maps may be a good replacement for proplists that are everywhere used as map. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Mon Feb 10 16:49:57 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 10 Feb 2014 16:49:57 +0100 Subject: [erlang-questions] Maps single value access not implemented In-Reply-To: <87a9dzku09.fsf@gmail.com> References: <8AC108D6-C490-499C-A755-FE85D0BA96C3@icloud.com> <87iosnvggq.fsf@gmail.com> <52F89577.6000405@ninenines.eu> <87eh3bkw2h.fsf@gmail.com> <52F8C488.1040001@ninenines.eu> <87a9dzku09.fsf@gmail.com> Message-ID: On Mon, Feb 10, 2014 at 1:54 PM, Sina Samavati wrote: > From another perspective: add or update it, I don't want you to shout at me > "Hey, there's no such key", because it will or will not be used. That's it. > The reason := is in there is to catch errors. If you have a map M = #{ foo => 3 } and then accidentally write M#{ fou => 4 } The resulting map will be #{ foo := 3, fou := 4 } which is probably not what you want. The := operator makes such errors impossible. The other, more subtle, benefit is that if a map is updated with := only, then the keys can be shared among the different maps. This yields good space behavior in the long run. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sina.samv@REDACTED Mon Feb 10 16:56:30 2014 From: sina.samv@REDACTED (Sina Samavati) Date: Mon, 10 Feb 2014 19:26:30 +0330 Subject: [erlang-questions] Maps single value access not implemented In-Reply-To: (Max Lapshin's message of "Mon, 10 Feb 2014 19:18:10 +0400") References: <8AC108D6-C490-499C-A755-FE85D0BA96C3@icloud.com> <87iosnvggq.fsf@gmail.com> <52F89577.6000405@ninenines.eu> <87eh3bkw2h.fsf@gmail.com> <52F8C488.1040001@ninenines.eu> <87a9dzku09.fsf@gmail.com> <52F8DC16.8030900@ninenines.eu> <87ob2ff2vq.fsf@gmail.com> Message-ID: <87eh3bezbl.fsf@gmail.com> Max Lapshin writes: > I think that maps may be a good replacement for proplists that are > everywhere used as map. Absolutely. It's even better, pattern matching over Maps is one of the _things_ that makes it better than Proplists. But, there's still a thing that might make us unable to say "it's better", or even put Maps versus Proplists, that's duplicate keys. We cannot add the same key multiple times in Maps. -- Sina Samavati Software engineer https://github.com/s1n4 https://twitter.com/sinasamavati From sverker.eriksson@REDACTED Mon Feb 10 19:44:33 2014 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Mon, 10 Feb 2014 19:44:33 +0100 Subject: [erlang-questions] Is -on_load() still experimental? Anyone using it? In-Reply-To: References: Message-ID: <52F91E11.3080108@ericsson.com> On 01/28/2014 06:37 PM, Ferenc Holzhauser wrote: > Thanks. The behaviour is quite neatly described in the documentation. If > there is no intention to change it (which is probably the case by now) then > perhaps it is also an idea to remove the experimental warning or replace it > with a more appropriate one about correct use. The name of the directive is > deceptive enough to bring the unwary to ideas and eventually make them > break things. > > If well understood then it can be useful to trigger other things than NIF > loading but I also think that the documentation should generally discourage > that. > > We will keep on_load as experimental as there are a number of known weak points in current semantics which we therefore might want to change but do not have time to do for OTP 17.0: * Doing external call in on_load to the module itself leads to deadlock. This could be handled as a special case and let external calls in the process doing on_load reach the module itself. * At upgrade, other processes calling the module get suspended waiting for on_load. We could let them reach the "old" module until on_load_succeeds to not destroy realtime characteristics. * At upgrade, no rollback is done if on_load fails. If we instead delay the upgrade until after on_load succeeds the system will not be left in a "broken" state. /Sverker, Erlang/OTP From moxford@REDACTED Mon Feb 10 22:09:25 2014 From: moxford@REDACTED (Mike Oxford) Date: Mon, 10 Feb 2014 13:09:25 -0800 Subject: [erlang-questions] Alternatives to Elixir Message-ID: Ruby feels like VB. I don't like VB, thus, I don't like Ruby. I like what Elixir is attempting to do but the syntax makes me have flashbacks and want to puke. (Personal problem, I know.) Are there other, similar projects out there with a different spoonful of sugar to help it go down? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Mon Feb 10 22:13:16 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 10 Feb 2014 22:13:16 +0100 Subject: [erlang-questions] Alternatives to Elixir In-Reply-To: References: Message-ID: <52F940EC.6090303@ninenines.eu> Have you heard of that Erlang language? It makes a lot of people happy with its tiny spec, tight syntax and expliciteness. On 02/10/2014 10:09 PM, Mike Oxford wrote: > Ruby feels like VB. > > I don't like VB, thus, I don't like Ruby. > > I like what Elixir is attempting to do but the syntax makes me have > flashbacks and want to puke. (Personal problem, I know.) > > Are there other, similar projects out there with a different spoonful of > sugar to help it go down? -- Lo?c Hoguin http://ninenines.eu From moxford@REDACTED Mon Feb 10 22:16:58 2014 From: moxford@REDACTED (Mike Oxford) Date: Mon, 10 Feb 2014 13:16:58 -0800 Subject: [erlang-questions] Alternatives to Elixir In-Reply-To: <52F940EC.6090303@ninenines.eu> References: <52F940EC.6090303@ninenines.eu> Message-ID: Yep, think I've heard of it somewhere 'round these parts, but sometimes it's fun to play with other things on top of the VM. Maybe I'll look into LFE. On Mon, Feb 10, 2014 at 1:13 PM, Lo?c Hoguin wrote: > Have you heard of that Erlang language? It makes a lot of people happy > with its tiny spec, tight syntax and expliciteness. > > > On 02/10/2014 10:09 PM, Mike Oxford wrote: > >> Ruby feels like VB. >> >> I don't like VB, thus, I don't like Ruby. >> >> I like what Elixir is attempting to do but the syntax makes me have >> flashbacks and want to puke. (Personal problem, I know.) >> >> Are there other, similar projects out there with a different spoonful of >> sugar to help it go down? >> > > -- > Lo?c Hoguin > http://ninenines.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tristan.sloughter@REDACTED Mon Feb 10 22:17:46 2014 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Mon, 10 Feb 2014 13:17:46 -0800 Subject: [erlang-questions] Alternatives to Elixir In-Reply-To: References: <52F940EC.6090303@ninenines.eu> Message-ID: <1392067066.24052.81726281.533E2007@webmail.messagingengine.com> There is also Joxa, [1]http://joxa.org/ -- Tristan Sloughter tristan.sloughter@REDACTED On Mon, Feb 10, 2014, at 01:16 PM, Mike Oxford wrote: Yep, think I've heard of it somewhere 'round these parts, but sometimes it's fun to play with other things on top of the VM. Maybe I'll look into LFE. On Mon, Feb 10, 2014 at 1:13 PM, Lo?c Hoguin <[2]essen@REDACTED> wrote: Have you heard of that Erlang language? It makes a lot of people happy with its tiny spec, tight syntax and expliciteness. On 02/10/2014 10:09 PM, Mike Oxford wrote: Ruby feels like VB. I don't like VB, thus, I don't like Ruby. I like what Elixir is attempting to do but the syntax makes me have flashbacks and want to puke. (Personal problem, I know.) Are there other, similar projects out there with a different spoonful of sugar to help it go down? -- Lo?c Hoguin [3]http://ninenines.eu _______________________________________________ erlang-questions mailing list [4]erlang-questions@REDACTED [5]http://erlang.org/mailman/listinfo/erlang-questions References 1. http://joxa.org/ 2. mailto:essen@REDACTED 3. http://ninenines.eu/ 4. mailto:erlang-questions@REDACTED 5. http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Mon Feb 10 22:34:50 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 10 Feb 2014 22:34:50 +0100 Subject: [erlang-questions] Alternatives to Elixir In-Reply-To: References: <52F940EC.6090303@ninenines.eu> Message-ID: <98B9DFF5-E736-4572-8E23-89A3E126FC56@gmail.com> If you like Prolog, there is also Robert Virding?s Erlog: https://github.com/rvirding/erlog reflux(vb). reminds_of(ruby, vb). reminds_of(elixir, ruby). reflux(X) :- reminds_of(X, Y), reflux(Y). -- Anthony Ramine Le 10 f?vr. 2014 ? 22:16, Mike Oxford a ?crit : > Yep, think I've heard of it somewhere 'round these parts, but sometimes it's fun to play with other things on top of the VM. > Maybe I'll look into LFE. > > > On Mon, Feb 10, 2014 at 1:13 PM, Lo?c Hoguin wrote: > Have you heard of that Erlang language? It makes a lot of people happy with its tiny spec, tight syntax and expliciteness. > > > On 02/10/2014 10:09 PM, Mike Oxford wrote: > Ruby feels like VB. > > I don't like VB, thus, I don't like Ruby. > > I like what Elixir is attempting to do but the syntax makes me have > flashbacks and want to puke. (Personal problem, I know.) > > Are there other, similar projects out there with a different spoonful of > sugar to help it go down? > > -- > Lo?c Hoguin > http://ninenines.eu > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From gordon@REDACTED Mon Feb 10 22:35:44 2014 From: gordon@REDACTED (Gordon Guthrie) Date: Mon, 10 Feb 2014 21:35:44 +0000 Subject: [erlang-questions] Alternatives to Elixir In-Reply-To: References: <52F940EC.6090303@ninenines.eu> Message-ID: Joxa as well. On 10 Feb 2014 21:17, "Mike Oxford" wrote: > Yep, think I've heard of it somewhere 'round these parts, but sometimes > it's fun to play with other things on top of the VM. > Maybe I'll look into LFE. > > > On Mon, Feb 10, 2014 at 1:13 PM, Lo?c Hoguin wrote: > >> Have you heard of that Erlang language? It makes a lot of people happy >> with its tiny spec, tight syntax and expliciteness. >> >> >> On 02/10/2014 10:09 PM, Mike Oxford wrote: >> >>> Ruby feels like VB. >>> >>> I don't like VB, thus, I don't like Ruby. >>> >>> I like what Elixir is attempting to do but the syntax makes me have >>> flashbacks and want to puke. (Personal problem, I know.) >>> >>> Are there other, similar projects out there with a different spoonful of >>> sugar to help it go down? >>> >> >> -- >> 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 mjtruog@REDACTED Mon Feb 10 22:38:12 2014 From: mjtruog@REDACTED (Michael Truog) Date: Mon, 10 Feb 2014 13:38:12 -0800 Subject: [erlang-questions] Alternatives to Elixir In-Reply-To: References: Message-ID: <52F946C4.9090106@gmail.com> lfe http://lfe.github.io/ luerl https://github.com/rvirding/luerl erlog https://github.com/rvirding/erlog efene http://marianoguerra.com.ar/efene/ reia http://reia-lang.org/ There are probably others I have missed. On 02/10/2014 01:09 PM, Mike Oxford wrote: > Ruby feels like VB. > > I don't like VB, thus, I don't like Ruby. > > I like what Elixir is attempting to do but the syntax makes me have flashbacks and want to puke. (Personal problem, I know.) > > Are there other, similar projects out there with a different spoonful of sugar to help it go down? > > Thanks! > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From eriksoe@REDACTED Mon Feb 10 22:46:04 2014 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Mon, 10 Feb 2014 22:46:04 +0100 Subject: [erlang-questions] Alternatives to Elixir In-Reply-To: <98B9DFF5-E736-4572-8E23-89A3E126FC56@gmail.com> References: <52F940EC.6090303@ninenines.eu> <98B9DFF5-E736-4572-8E23-89A3E126FC56@gmail.com> Message-ID: +1 for content/form agreement :-) Den 10/02/2014 22.35 skrev "Anthony Ramine" : > If you like Prolog, there is also Robert Virding's Erlog: > > https://github.com/rvirding/erlog > > reflux(vb). > > reminds_of(ruby, vb). > reminds_of(elixir, ruby). > > reflux(X) :- > reminds_of(X, Y), > reflux(Y). > > -- > Anthony Ramine > > Le 10 f?vr. 2014 ? 22:16, Mike Oxford a ?crit : > > > Yep, think I've heard of it somewhere 'round these parts, but sometimes > it's fun to play with other things on top of the VM. > > Maybe I'll look into LFE. > > > > > > On Mon, Feb 10, 2014 at 1:13 PM, Lo?c Hoguin wrote: > > Have you heard of that Erlang language? It makes a lot of people happy > with its tiny spec, tight syntax and expliciteness. > > > > > > On 02/10/2014 10:09 PM, Mike Oxford wrote: > > Ruby feels like VB. > > > > I don't like VB, thus, I don't like Ruby. > > > > I like what Elixir is attempting to do but the syntax makes me have > > flashbacks and want to puke. (Personal problem, I know.) > > > > Are there other, similar projects out there with a different spoonful of > > sugar to help it go down? > > > > -- > > Lo?c Hoguin > > http://ninenines.eu > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gleber.p@REDACTED Mon Feb 10 22:51:55 2014 From: gleber.p@REDACTED (Gleb Peregud) Date: Mon, 10 Feb 2014 22:51:55 +0100 Subject: [erlang-questions] Alternatives to Elixir In-Reply-To: References: <52F940EC.6090303@ninenines.eu> <98B9DFF5-E736-4572-8E23-89A3E126FC56@gmail.com> Message-ID: Yhc - compiler of Haskell targeting BEAM: http://www.haskell.org/haskellwiki/Yhc/Erlang/Proof_of_concept On Mon, Feb 10, 2014 at 10:46 PM, Erik S?e S?rensen wrote: > +1 for content/form agreement :-) > > Den 10/02/2014 22.35 skrev "Anthony Ramine" : > >> If you like Prolog, there is also Robert Virding?s Erlog: >> >> https://github.com/rvirding/erlog >> >> reflux(vb). >> >> reminds_of(ruby, vb). >> reminds_of(elixir, ruby). >> >> reflux(X) :- >> reminds_of(X, Y), >> reflux(Y). >> >> -- >> Anthony Ramine >> >> Le 10 f?vr. 2014 ? 22:16, Mike Oxford a ?crit : >> >> > Yep, think I've heard of it somewhere 'round these parts, but sometimes >> > it's fun to play with other things on top of the VM. >> > Maybe I'll look into LFE. >> > >> > >> > On Mon, Feb 10, 2014 at 1:13 PM, Lo?c Hoguin wrote: >> > Have you heard of that Erlang language? It makes a lot of people happy >> > with its tiny spec, tight syntax and expliciteness. >> > >> > >> > On 02/10/2014 10:09 PM, Mike Oxford wrote: >> > Ruby feels like VB. >> > >> > I don't like VB, thus, I don't like Ruby. >> > >> > I like what Elixir is attempting to do but the syntax makes me have >> > flashbacks and want to puke. (Personal problem, I know.) >> > >> > Are there other, similar projects out there with a different spoonful of >> > sugar to help it go down? >> > >> > -- >> > Lo?c Hoguin >> > http://ninenines.eu >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From g@REDACTED Mon Feb 10 22:52:28 2014 From: g@REDACTED (Garrett Smith) Date: Mon, 10 Feb 2014 15:52:28 -0600 Subject: [erlang-questions] Alternatives to Elixir In-Reply-To: References: <52F940EC.6090303@ninenines.eu> <98B9DFF5-E736-4572-8E23-89A3E126FC56@gmail.com> Message-ID: Visual Basic to beam files... now *that's* a thought. Can we use Google Summer of Code for this? On Mon, Feb 10, 2014 at 3:46 PM, Erik S?e S?rensen wrote: > +1 for content/form agreement :-) > > Den 10/02/2014 22.35 skrev "Anthony Ramine" : >> >> If you like Prolog, there is also Robert Virding's Erlog: >> >> https://github.com/rvirding/erlog >> >> reflux(vb). >> >> reminds_of(ruby, vb). >> reminds_of(elixir, ruby). >> >> reflux(X) :- >> reminds_of(X, Y), >> reflux(Y). >> >> -- >> Anthony Ramine >> >> Le 10 f?vr. 2014 ? 22:16, Mike Oxford a ?crit : >> >> >> > Yep, think I've heard of it somewhere 'round these parts, but sometimes >> > it's fun to play with other things on top of the VM. >> > Maybe I'll look into LFE. >> > >> > >> > On Mon, Feb 10, 2014 at 1:13 PM, Lo?c Hoguin wrote: >> > Have you heard of that Erlang language? It makes a lot of people happy >> > with its tiny spec, tight syntax and expliciteness. >> > >> > >> > On 02/10/2014 10:09 PM, Mike Oxford wrote: >> > Ruby feels like VB. >> > >> > I don't like VB, thus, I don't like Ruby. >> > >> > I like what Elixir is attempting to do but the syntax makes me have >> > flashbacks and want to puke. (Personal problem, I know.) >> > >> > Are there other, similar projects out there with a different spoonful of >> > sugar to help it go down? >> > >> > -- >> > Lo?c Hoguin >> > http://ninenines.eu >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From jose.valim@REDACTED Mon Feb 10 22:57:46 2014 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Mon, 10 Feb 2014 22:57:46 +0100 Subject: [erlang-questions] Alternatives to Elixir In-Reply-To: References: <52F940EC.6090303@ninenines.eu> <98B9DFF5-E736-4572-8E23-89A3E126FC56@gmail.com> Message-ID: There is also scheme: http://the-concurrent-schemer.github.io/scm-doc/ On Monday, February 10, 2014, Gleb Peregud wrote: > Yhc - compiler of Haskell targeting BEAM: > http://www.haskell.org/haskellwiki/Yhc/Erlang/Proof_of_concept > > On Mon, Feb 10, 2014 at 10:46 PM, Erik S?e S?rensen > > wrote: > > +1 for content/form agreement :-) > > > > Den 10/02/2014 22.35 skrev "Anthony Ramine" > >: > > > >> If you like Prolog, there is also Robert Virding's Erlog: > >> > >> https://github.com/rvirding/erlog > >> > >> reflux(vb). > >> > >> reminds_of(ruby, vb). > >> reminds_of(elixir, ruby). > >> > >> reflux(X) :- > >> reminds_of(X, Y), > >> reflux(Y). > >> > >> -- > >> Anthony Ramine > >> > >> Le 10 f?vr. 2014 ? 22:16, Mike Oxford > > a ?crit : > >> > >> > Yep, think I've heard of it somewhere 'round these parts, but > sometimes > >> > it's fun to play with other things on top of the VM. > >> > Maybe I'll look into LFE. > >> > > >> > > >> > On Mon, Feb 10, 2014 at 1:13 PM, Lo?c Hoguin > > wrote: > >> > Have you heard of that Erlang language? It makes a lot of people happy > >> > with its tiny spec, tight syntax and expliciteness. > >> > > >> > > >> > On 02/10/2014 10:09 PM, Mike Oxford wrote: > >> > Ruby feels like VB. > >> > > >> > I don't like VB, thus, I don't like Ruby. > >> > > >> > I like what Elixir is attempting to do but the syntax makes me have > >> > flashbacks and want to puke. (Personal problem, I know.) > >> > > >> > Are there other, similar projects out there with a different spoonful > of > >> > sugar to help it go down? > >> > > >> > -- > >> > Lo?c Hoguin > >> > http://ninenines.eu > >> > > >> > _______________________________________________ > >> > erlang-questions mailing list > >> > erlang-questions@REDACTED > >> > http://erlang.org/mailman/listinfo/erlang-questions > >> > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Mon Feb 10 22:58:03 2014 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Mon, 10 Feb 2014 22:58:03 +0100 Subject: [erlang-questions] Alternatives to Elixir In-Reply-To: References: <52F940EC.6090303@ninenines.eu> <98B9DFF5-E736-4572-8E23-89A3E126FC56@gmail.com> Message-ID: There is also scheme: http://the-concurrent-schemer.github.io/scm-doc/ On Monday, February 10, 2014, Gleb Peregud > wrote: > Yhc - compiler of Haskell targeting BEAM: > http://www.haskell.org/haskellwiki/Yhc/Erlang/Proof_of_concept > > On Mon, Feb 10, 2014 at 10:46 PM, Erik S?e S?rensen > wrote: > > +1 for content/form agreement :-) > > > > Den 10/02/2014 22.35 skrev "Anthony Ramine" : > > > >> If you like Prolog, there is also Robert Virding's Erlog: > >> > >> https://github.com/rvirding/erlog > >> > >> reflux(vb). > >> > >> reminds_of(ruby, vb). > >> reminds_of(elixir, ruby). > >> > >> reflux(X) :- > >> reminds_of(X, Y), > >> reflux(Y). > >> > >> -- > >> Anthony Ramine > >> > >> Le 10 f?vr. 2014 ? 22:16, Mike Oxford a ?crit : > >> > >> > Yep, think I've heard of it somewhere 'round these parts, but > sometimes > >> > it's fun to play with other things on top of the VM. > >> > Maybe I'll look into LFE. > >> > > >> > > >> > On Mon, Feb 10, 2014 at 1:13 PM, Lo?c Hoguin > wrote: > >> > Have you heard of that Erlang language? It makes a lot of people happy > >> > with its tiny spec, tight syntax and expliciteness. > >> > > >> > > >> > On 02/10/2014 10:09 PM, Mike Oxford wrote: > >> > Ruby feels like VB. > >> > > >> > I don't like VB, thus, I don't like Ruby. > >> > > >> > I like what Elixir is attempting to do but the syntax makes me have > >> > flashbacks and want to puke. (Personal problem, I know.) > >> > > >> > Are there other, similar projects out there with a different spoonful > of > >> > sugar to help it go down? > >> > > >> > -- > >> > Lo?c Hoguin > >> > http://ninenines.eu > >> > > >> > _______________________________________________ > >> > erlang-questions mailing list > >> > erlang-questions@REDACTED > >> > http://erlang.org/mailman/listinfo/erlang-questions > >> > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Mon Feb 10 23:01:39 2014 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Mon, 10 Feb 2014 23:01:39 +0100 Subject: [erlang-questions] Alternatives to Elixir In-Reply-To: References: <52F940EC.6090303@ninenines.eu> <98B9DFF5-E736-4572-8E23-89A3E126FC56@gmail.com> Message-ID: VBFE - Visual Basic flavored Elixir is coming until the end of the year. It will be followed by E#, for those who are unhappy with the lack of a language that uses curly brackets to delimit code blocks in the Erlang VM. On Monday, February 10, 2014, Garrett Smith wrote: > Visual Basic to beam files... now *that's* a thought. > > Can we use Google Summer of Code for this? > > On Mon, Feb 10, 2014 at 3:46 PM, Erik S?e S?rensen > > wrote: > > +1 for content/form agreement :-) > > > > Den 10/02/2014 22.35 skrev "Anthony Ramine" > >: > >> > >> If you like Prolog, there is also Robert Virding's Erlog: > >> > >> https://github.com/rvirding/erlog > >> > >> reflux(vb). > >> > >> reminds_of(ruby, vb). > >> reminds_of(elixir, ruby). > >> > >> reflux(X) :- > >> reminds_of(X, Y), > >> reflux(Y). > >> > >> -- > >> Anthony Ramine > >> > >> Le 10 f?vr. 2014 ? 22:16, Mike Oxford > > a ?crit : > >> > >> > >> > Yep, think I've heard of it somewhere 'round these parts, but > sometimes > >> > it's fun to play with other things on top of the VM. > >> > Maybe I'll look into LFE. > >> > > >> > > >> > On Mon, Feb 10, 2014 at 1:13 PM, Lo?c Hoguin > > wrote: > >> > Have you heard of that Erlang language? It makes a lot of people happy > >> > with its tiny spec, tight syntax and expliciteness. > >> > > >> > > >> > On 02/10/2014 10:09 PM, Mike Oxford wrote: > >> > Ruby feels like VB. > >> > > >> > I don't like VB, thus, I don't like Ruby. > >> > > >> > I like what Elixir is attempting to do but the syntax makes me have > >> > flashbacks and want to puke. (Personal problem, I know.) > >> > > >> > Are there other, similar projects out there with a different spoonful > of > >> > sugar to help it go down? > >> > > >> > -- > >> > Lo?c Hoguin > >> > http://ninenines.eu > >> > > >> > _______________________________________________ > >> > erlang-questions mailing list > >> > erlang-questions@REDACTED > >> > http://erlang.org/mailman/listinfo/erlang-questions > >> > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Mon Feb 10 23:01:51 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 11 Feb 2014 11:01:51 +1300 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> , Message-ID: <1B8F4A98-A99F-414F-A05A-996CCAF56383@cs.otago.ac.nz> > ________________________________________ > From: Garrett Smith [g@REDACTED] > Sent: Thursday, 06 February 2014 5:02 PM > - Mixed tabs and spaces present challenges for programmer using > different editors and contributing to projects with varied or poorly > defined white space standards This is somewhat misleadingly phrased. Tabs do this all by themselves. For example, I once spent some time using a programming language where the IDE on Macs insisted that tabs were equivalent to 4 spaces and the Unix command line tools insisted that tabs were and could only be equivalent to 8 spaces, AND the language was indentation-sensitive. So remember, it's not "mixed tabs and spaces present challenges", it's "tabs present challenges". The fundamental problem is that by design, tabs have no common meaning other than "some amount of horizontal white space". From eriksoe@REDACTED Mon Feb 10 23:07:39 2014 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Mon, 10 Feb 2014 23:07:39 +0100 Subject: [erlang-questions] Alternatives to Elixir In-Reply-To: References: <52F940EC.6090303@ninenines.eu> <98B9DFF5-E736-4572-8E23-89A3E126FC56@gmail.com> Message-ID: If it ends up maturing Erlang's GUI bindings, then I'm all for it. :-) Heck, I might even contribute a line or two... (Not because of the street cred or the karmic implications, but because I'm me.) Den 10/02/2014 22.52 skrev "Garrett Smith" : > Visual Basic to beam files... now *that's* a thought. > > Can we use Google Summer of Code for this? > > On Mon, Feb 10, 2014 at 3:46 PM, Erik S?e S?rensen > wrote: > > +1 for content/form agreement :-) > > > > Den 10/02/2014 22.35 skrev "Anthony Ramine" : > >> > >> If you like Prolog, there is also Robert Virding's Erlog: > >> > >> https://github.com/rvirding/erlog > >> > >> reflux(vb). > >> > >> reminds_of(ruby, vb). > >> reminds_of(elixir, ruby). > >> > >> reflux(X) :- > >> reminds_of(X, Y), > >> reflux(Y). > >> > >> -- > >> Anthony Ramine > >> > >> Le 10 f?vr. 2014 ? 22:16, Mike Oxford a ?crit : > >> > >> > >> > Yep, think I've heard of it somewhere 'round these parts, but > sometimes > >> > it's fun to play with other things on top of the VM. > >> > Maybe I'll look into LFE. > >> > > >> > > >> > On Mon, Feb 10, 2014 at 1:13 PM, Lo?c Hoguin > wrote: > >> > Have you heard of that Erlang language? It makes a lot of people happy > >> > with its tiny spec, tight syntax and expliciteness. > >> > > >> > > >> > On 02/10/2014 10:09 PM, Mike Oxford wrote: > >> > Ruby feels like VB. > >> > > >> > I don't like VB, thus, I don't like Ruby. > >> > > >> > I like what Elixir is attempting to do but the syntax makes me have > >> > flashbacks and want to puke. (Personal problem, I know.) > >> > > >> > Are there other, similar projects out there with a different spoonful > of > >> > sugar to help it go down? > >> > > >> > -- > >> > Lo?c Hoguin > >> > http://ninenines.eu > >> > > >> > _______________________________________________ > >> > erlang-questions mailing list > >> > erlang-questions@REDACTED > >> > http://erlang.org/mailman/listinfo/erlang-questions > >> > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Mon Feb 10 23:12:28 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 10 Feb 2014 23:12:28 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <1B8F4A98-A99F-414F-A05A-996CCAF56383@cs.otago.ac.nz> References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> , <1B8F4A98-A99F-414F-A05A-996CCAF56383@cs.otago.ac.nz> Message-ID: <52F94ECC.1000704@ninenines.eu> On 02/10/2014 11:01 PM, Richard A. O'Keefe wrote: >> - Mixed tabs and spaces present challenges for programmer using >> different editors and contributing to projects with varied or poorly >> defined white space standards > > This is somewhat misleadingly phrased. > Tabs do this all by themselves. > > For example, I once spent some time using a programming > language where the IDE on Macs insisted that tabs were > equivalent to 4 spaces and the Unix command line tools > insisted that tabs were and could only be equivalent to > 8 spaces, AND the language was indentation-sensitive. > > So remember, it's not "mixed tabs and spaces present > challenges", it's "tabs present challenges". Tabs are perfectly fine for indentation. You had issues only because you were doing both indentation *and* alignment. If you don't align your code, it doesn't matter what the tab length is. Just like the CAP theorem, I posit the TIA theorem: tabs, indentation, alignment, choose two. -- Lo?c Hoguin http://ninenines.eu From mononcqc@REDACTED Mon Feb 10 23:19:17 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 10 Feb 2014 17:19:17 -0500 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <52F94ECC.1000704@ninenines.eu> References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> <1B8F4A98-A99F-414F-A05A-996CCAF56383@cs.otago.ac.nz> <52F94ECC.1000704@ninenines.eu> Message-ID: <20140210221916.GI48745@ferdmbp.local> The best part of your conjecture is that we can forget about tabs entirely and still have everything working fine. Sounds like a good deal. Regards, Fred. On 02/10, Lo?c Hoguin wrote: > On 02/10/2014 11:01 PM, Richard A. O'Keefe wrote: > >>- Mixed tabs and spaces present challenges for programmer using > >>different editors and contributing to projects with varied or poorly > >>defined white space standards > > > >This is somewhat misleadingly phrased. > >Tabs do this all by themselves. > > > >For example, I once spent some time using a programming > >language where the IDE on Macs insisted that tabs were > >equivalent to 4 spaces and the Unix command line tools > >insisted that tabs were and could only be equivalent to > >8 spaces, AND the language was indentation-sensitive. > > > >So remember, it's not "mixed tabs and spaces present > >challenges", it's "tabs present challenges". > > Tabs are perfectly fine for indentation. You had issues only because you > were doing both indentation *and* alignment. If you don't align your code, > it doesn't matter what the tab length is. > > Just like the CAP theorem, I posit the TIA theorem: tabs, indentation, > alignment, choose two. > > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From n.oxyde@REDACTED Mon Feb 10 23:19:57 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 10 Feb 2014 23:19:57 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <52F94ECC.1000704@ninenines.eu> References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> , <1B8F4A98-A99F-414F-A05A-996CCAF56383@cs.otago.ac.nz> <52F94ECC.1000704@ninenines.eu> Message-ID: Erlang/OTP already chose indentation and alignment: move_case_into_arg(#c_case{arg=#c_case{arg=OuterArg, clauses=[OuterCa0,OuterCb]}=Outer, clauses=InnerClauses}=Inner0, Sub) -> case is_failing_clause(OuterCb) of true -> #c_clause{pats=OuterPats0,guard=OuterGuard0, body=InnerArg0} = OuterCa0, %% %% case case of %% when -> %% %% ... %% end of %% %% end %% %% ==> %% %% case of %% when -> %% case of end %% %% end %% ScopeSub0 = sub_subst_scope(Sub#sub{t=[]}), {OuterPats,ScopeSub} = pattern_list(OuterPats0, ScopeSub0), OuterGuard = guard(OuterGuard0, ScopeSub), InnerArg = body(InnerArg0, ScopeSub), Inner = Inner0#c_case{arg=InnerArg,clauses=InnerClauses}, OuterCa = OuterCa0#c_clause{pats=OuterPats,guard=OuterGuard, body=Inner}, Outer#c_case{arg=OuterArg, clauses=[OuterCa,OuterCb]}; false -> impossible end; Following your TIA theorem, tabs need to go. -- Anthony Ramine Le 10 f?vr. 2014 ? 23:12, Lo?c Hoguin a ?crit : > On 02/10/2014 11:01 PM, Richard A. O'Keefe wrote: >>> - Mixed tabs and spaces present challenges for programmer using >>> different editors and contributing to projects with varied or poorly >>> defined white space standards >> >> This is somewhat misleadingly phrased. >> Tabs do this all by themselves. >> >> For example, I once spent some time using a programming >> language where the IDE on Macs insisted that tabs were >> equivalent to 4 spaces and the Unix command line tools >> insisted that tabs were and could only be equivalent to >> 8 spaces, AND the language was indentation-sensitive. >> >> So remember, it's not "mixed tabs and spaces present >> challenges", it's "tabs present challenges". > > Tabs are perfectly fine for indentation. You had issues only because you were doing both indentation *and* alignment. If you don't align your code, it doesn't matter what the tab length is. > > Just like the CAP theorem, I posit the TIA theorem: tabs, indentation, alignment, choose two. > > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From nem@REDACTED Mon Feb 10 23:22:17 2014 From: nem@REDACTED (Geoff Cant) Date: Mon, 10 Feb 2014 14:22:17 -0800 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <52F94ECC.1000704@ninenines.eu> References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> , <1B8F4A98-A99F-414F-A05A-996CCAF56383@cs.otago.ac.nz> <52F94ECC.1000704@ninenines.eu> Message-ID: On 2014-02-10, at 14:12 , Lo?c Hoguin wrote: > On 02/10/2014 11:01 PM, Richard A. O'Keefe wrote: >>> - Mixed tabs and spaces present challenges for programmer using >>> different editors and contributing to projects with varied or poorly >>> defined white space standards >> >> This is somewhat misleadingly phrased. >> Tabs do this all by themselves. >> >> For example, I once spent some time using a programming >> language where the IDE on Macs insisted that tabs were >> equivalent to 4 spaces and the Unix command line tools >> insisted that tabs were and could only be equivalent to >> 8 spaces, AND the language was indentation-sensitive. >> >> So remember, it's not "mixed tabs and spaces present >> challenges", it's "tabs present challenges". > > Tabs are perfectly fine for indentation. You had issues only because you were doing both indentation *and* alignment. If you don't align your code, it doesn't matter what the tab length is. > > Just like the CAP theorem, I posit the TIA theorem: tabs, indentation, alignment, choose two. > Is there an argument in favour of jettisoning alignment in favour of tabs? I favour alignment over tabs, and am happy to work on other people's code no matter how many spaces they want for indentation[1]. I have never once been glad that tabs-in-code let me choose my own indent level when viewing it - alignment has always been preferable as a mechanism for making code more readable. Opinionatedly, -- Geoff [1] If you pick 16, that's cool - I'll probably just fork your library. From ok@REDACTED Mon Feb 10 23:26:08 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 11 Feb 2014 11:26:08 +1300 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <74B30216-713A-41B2-9F79-84D55E4C92C8@saunalahti.fi> References: <20140205182727.GL9655@hijacked.us> <52F28A4B.5070709@erlang.org> <74B30216-713A-41B2-9F79-84D55E4C92C8@saunalahti.fi> Message-ID: <9AD678CC-9A7B-4D5D-9D0C-CE170A86AA58@cs.otago.ac.nz> On 7/02/2014, at 8:39 PM, Jarimatti Valkonen wrote: > I've been having this idea in my head about something similar to a Smalltalk system browser, but for Erlang. Useful? I doubt it, but at least it would be an interesting experiment. A source editor is doable, but making it work on a live system is left as an exercise to the reader. :) I had the same idea about Prolog at one point. For the benefit of people who haven't used Smalltalk, the basic browser interface is the "five pane browser". +---------+---------+---------+---------+ |list of |list of |list of |list of | |groups of|classes |groups of|methods | |classes |in group |methods |in group | +---------+---------+---------+---------+ |a bunch of buttons | +---------------------------------------+ |edit window for class description | |or class comment | |or method definition | |or for showing output of a tool such | |as a lint checker | | | +---------------------------------------+ A "class category" is roughly like an application in Erlang. A "class" is roughly like a module in Erlang. A "method category" is a named group of semantically related functions, e.g., methods for comparing, methods for printing, methods for iteration, &c. A "method" is roughly speaking a named function. There are several more or less specialised versions of this and you can have any number of them on screen tat the same time. Modern Smalltalks also have things we might call "package browsers" and/or "repository browsers" for locating, inspecting, and possibly installing add-on packages that are not loaded by default and might be held remotely. The "class categories" and "method categories" are programmer-selected names for groups of things that are managed by the programmer. These properties are available for query (and update!) by running code, but have no other effect on execution semantics. Methods may be further classified semantically by adding "pragmas" to their source; this may be reflected in the way the method's name is display, and is accessible as run-time data. This is a really good way to get to know an unfamiliar class one method or one facet (method category) at a time. It can be a pain in the backside when you are trying to understand the interactions of several methods at once. It can also be a bit awkward when you are trying to ensure that the definitions of a method in several classes are semantically consistent; then you want to slice by method rather than class. Fortunately, Smalltalk IDEs often have some sort of "method finder" that lets you find/pick a particular method name and get a list of all the classes that implement it. (It is really annoying the way VW closes that list as soon as you pick one element. Squeak gets that right.) I think perhaps there are two key ideas that could be adapted to the Erlang world: - programmer defined indexing terms for modules and for functions, so you could say "what are some modules or functions that are *about* this topic" whatever they might be named. Perhaps -index([ List of strings ]). before the first -export: relating to the module; after the last function: relating to the module; elsewhere: relating to the next function. - having multiple ways of viewing the code base, slicing by module or function or data type or whatever. elsewhere: E > > Is anyone aware of anything similar? > > And yes, I don't see this solving the tab/space indentation discussion. From ludovic@REDACTED Mon Feb 10 23:29:22 2014 From: ludovic@REDACTED (Ludovic Demblans) Date: Mon, 10 Feb 2014 23:29:22 +0100 Subject: [erlang-questions] Alternatives to Elixir In-Reply-To: <98B9DFF5-E736-4572-8E23-89A3E126FC56@gmail.com> References: <52F940EC.6090303@ninenines.eu> <98B9DFF5-E736-4572-8E23-89A3E126FC56@gmail.com> Message-ID: Wow this prolog thing is hard to grasp on a first sight ... does 'reminds_of(X,Y) binds Y 'ruby' if we pass 'elixir' as X in 'reflux(X)' ? Le Mon, 10 Feb 2014 22:34:50 +0100, Anthony Ramine a ?crit: > If you like Prolog, there is also Robert Virding?s Erlog: > > https://github.com/rvirding/erlog > > reflux(vb). > > reminds_of(ruby, vb). > reminds_of(elixir, ruby). > > reflux(X) :- > reminds_of(X, Y), > reflux(Y). > -- Utilisant le logiciel de courrier r?volutionnaire d'Opera : http://www.opera.com/mail/ From raould@REDACTED Mon Feb 10 23:56:21 2014 From: raould@REDACTED (Raoul Duke) Date: Mon, 10 Feb 2014 14:56:21 -0800 Subject: [erlang-questions] dyalizer? (was Re: Alternatives to Elixir) Message-ID: so do any of these work with dyalizer? :-) still hoping that somebody will contribute whatever is need so the dyalizer folks can incorporate it. as was said on the list before, it isn't expected that the core dyalizer folks do this work for whatever random languages exist out there. On Mon, Feb 10, 2014 at 1:38 PM, Michael Truog wrote: > lfe http://lfe.github.io/ > luerl https://github.com/rvirding/luerl > erlog https://github.com/rvirding/erlog > efene http://marianoguerra.com.ar/efene/ > reia http://reia-lang.org/ > > There are probably others I have missed. > > > On 02/10/2014 01:09 PM, Mike Oxford wrote: > > Ruby feels like VB. > > I don't like VB, thus, I don't like Ruby. > > I like what Elixir is attempting to do but the syntax makes me have > flashbacks and want to puke. (Personal problem, I know.) > > Are there other, similar projects out there with a different spoonful of > sugar to help it go down? > > 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 > From ok@REDACTED Tue Feb 11 00:00:55 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 11 Feb 2014 12:00:55 +1300 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <52F94ECC.1000704@ninenines.eu> References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> , <1B8F4A98-A99F-414F-A05A-996CCAF56383@cs.otago.ac.nz> <52F94ECC.1000704@ninenines.eu> Message-ID: <12E100E5-38AB-4C74-9A61-CC2A510DCFB5@cs.otago.ac.nz> On 11/02/2014, at 11:12 AM, Lo?c Hoguin wrote: > On 02/10/2014 11:01 PM, Richard A. O'Keefe wrote: >> >> So remember, it's not "mixed tabs and spaces present >> challenges", it's "tabs present challenges". > > Tabs are perfectly fine for indentation. You had issues only because you were doing both indentation *and* alignment. If you don't align your code, it doesn't matter what the tab length is. To the limited extent that I understand the distinction you are making between "indentation" and "alignment", I don't understand it. To me, indentation simply *is* "making some aspect of structure directly visible by mapping nesting depth to distance from the left margin". A 'character' which corresponds to an unpredictable and uncontrollable amount of white space simply isn't up to the job. (Yes, if you put an Emacs mode line into a file, tab width *is* predictable and controllable for that file, BUT ONLY IN Emacs.) If you mean that the indentation will be *logically* correct as far as a parser is concerned, fine. But it won't be *visually* correct. By the way, the IDE didn't, for all practical purposes, offer me any choice in the matter. From n.oxyde@REDACTED Tue Feb 11 00:03:16 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 11 Feb 2014 00:03:16 +0100 Subject: [erlang-questions] dyalizer? (was Re: Alternatives to Elixir) In-Reply-To: References: Message-ID: <445601AA-244D-4CC0-8F09-B1042763E210@gmail.com> The short way is to introduce a new compiler option +core_info which does like +debug_info but for Core?s AST and then make Dialyzer use that BEAM chunk if present. Dialyzer doesn?t actually analyse Erlang code, it takes the specs in it, compile to Core and does the analysis on Core. Thus any language targeting Core with semantics similar to Erlang should be able to benefit from Dialyzer. -- Anthony Ramine Le 10 f?vr. 2014 ? 23:56, Raoul Duke a ?crit : > so do any of these work with dyalizer? :-) > > still hoping that somebody will contribute whatever is need so the > dyalizer folks can incorporate it. as was said on the list before, it > isn't expected that the core dyalizer folks do this work for whatever > random languages exist out there. From essen@REDACTED Tue Feb 11 00:09:17 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 11 Feb 2014 00:09:17 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> , <1B8F4A98-A99F-414F-A05A-996CCAF56383@cs.otago.ac.nz> <52F94ECC.1000704@ninenines.eu> Message-ID: <52F95C1D.5040301@ninenines.eu> On 02/10/2014 11:22 PM, Geoff Cant wrote: > On 2014-02-10, at 14:12 , Lo?c Hoguin wrote: > >> On 02/10/2014 11:01 PM, Richard A. O'Keefe wrote: >>>> - Mixed tabs and spaces present challenges for programmer using >>>> different editors and contributing to projects with varied or poorly >>>> defined white space standards >>> >>> This is somewhat misleadingly phrased. >>> Tabs do this all by themselves. >>> >>> For example, I once spent some time using a programming >>> language where the IDE on Macs insisted that tabs were >>> equivalent to 4 spaces and the Unix command line tools >>> insisted that tabs were and could only be equivalent to >>> 8 spaces, AND the language was indentation-sensitive. >>> >>> So remember, it's not "mixed tabs and spaces present >>> challenges", it's "tabs present challenges". >> >> Tabs are perfectly fine for indentation. You had issues only because you were doing both indentation *and* alignment. If you don't align your code, it doesn't matter what the tab length is. >> >> Just like the CAP theorem, I posit the TIA theorem: tabs, indentation, alignment, choose two. >> > > Is there an argument in favour of jettisoning alignment in favour of tabs? > > I favour alignment over tabs, and am happy to work on other people's code no matter how many spaces they want for indentation[1]. I have never once been glad that tabs-in-code let me choose my own indent level when viewing it - alignment has always been preferable as a mechanism for making code more readable. One day not too long ago I decided to stop aligning entirely. Code is still as readable as before, and I don't have to spend any time worrying about prettifying the code (or fixing what the auto identation thing did). Nobody said my code is less readable because of it so far. I'm using tabs mostly for historical reasons, if I were to use spaces I still wouldn't align. -- Lo?c Hoguin http://ninenines.eu From essen@REDACTED Tue Feb 11 00:13:39 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 11 Feb 2014 00:13:39 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <12E100E5-38AB-4C74-9A61-CC2A510DCFB5@cs.otago.ac.nz> References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> , <1B8F4A98-A99F-414F-A05A-996CCAF56383@cs.otago.ac.nz> <52F94ECC.1000704@ninenines.eu> <12E100E5-38AB-4C74-9A61-CC2A510DCFB5@cs.otago.ac.nz> Message-ID: <52F95D23.7050207@ninenines.eu> On 02/11/2014 12:00 AM, Richard A. O'Keefe wrote: > > On 11/02/2014, at 11:12 AM, Lo?c Hoguin wrote: > >> On 02/10/2014 11:01 PM, Richard A. O'Keefe wrote: >>> >>> So remember, it's not "mixed tabs and spaces present >>> challenges", it's "tabs present challenges". >> >> Tabs are perfectly fine for indentation. You had issues only because you were doing both indentation *and* alignment. If you don't align your code, it doesn't matter what the tab length is. > > To the limited extent that I understand the distinction you are > making between "indentation" and "alignment", I don't understand it. > To me, indentation simply *is* "making some aspect of structure > directly visible by mapping nesting depth to distance from the > left margin". Indentation: myfunction(A, B, C, D, E) -> Alignment: myfunction(A, B, C, D, E) -> But also, skipping the indentation that would be to the left of these assignments... No alignment: A = 1, Bartender = 17, Car = 35, Alignment: A = 1, Bartender = 17, Car = 35, Hopefully it'll show up properly in the email. -- Lo?c Hoguin http://ninenines.eu From ferenc.holzhauser@REDACTED Tue Feb 11 00:15:48 2014 From: ferenc.holzhauser@REDACTED (Ferenc Holzhauser) Date: Tue, 11 Feb 2014 00:15:48 +0100 Subject: [erlang-questions] Is -on_load() still experimental? Anyone using it? In-Reply-To: <52F91E11.3080108@ericsson.com> References: <52F91E11.3080108@ericsson.com> Message-ID: Great information, thanks! Having this documented helps a lot when trying not to break things. BR, Ferenc On 10 February 2014 19:44, Sverker Eriksson wrote: > > On 01/28/2014 06:37 PM, Ferenc Holzhauser wrote: > >> Thanks. The behaviour is quite neatly described in the documentation. If >> there is no intention to change it (which is probably the case by now) >> then >> perhaps it is also an idea to remove the experimental warning or replace >> it >> with a more appropriate one about correct use. The name of the directive >> is >> deceptive enough to bring the unwary to ideas and eventually make them >> break things. >> >> If well understood then it can be useful to trigger other things than NIF >> loading but I also think that the documentation should generally >> discourage >> that. >> >> >> > We will keep on_load as experimental as there are a number of known weak > points in current semantics which we therefore might want to change but do > not have time to do for OTP 17.0: > > * Doing external call in on_load to the module itself leads to deadlock. > This could be handled as a special case and let external calls in the > process doing on_load reach the module itself. > > * At upgrade, other processes calling the module get suspended waiting for > on_load. We could let them reach the "old" module until on_load_succeeds to > not destroy realtime characteristics. > > * At upgrade, no rollback is done if on_load fails. If we instead delay > the upgrade until after on_load succeeds the system will not be left in a > "broken" state. > > > /Sverker, Erlang/OTP > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Tue Feb 11 00:40:21 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 11 Feb 2014 12:40:21 +1300 Subject: [erlang-questions] Erlang term to ASCII In-Reply-To: References: Message-ID: It seems to me that the basic issue is that - there is some subset of Erlang data ? Why do I say "subset"? ! Because there are things like funs and pids that do not have textual representations that read back - which the external system stores - and can convert to a string Erlang can read - and can hash (by first converting to a string) - but the built-in functions convert the same data to different strings - so the hash would be different. 1. Compute the hash directly from the data, not the string. Since MD5 is mentioned, this may not be practical. 2. Implement the same formatting algorithm in the CMS and Erlang. For example, quote all atoms, never generate ", ..., add no white space. Beware also of issues in formatting floating point numbers. Implementing your own algorithm also has the nice benefit of documenting precisely what subset of Erlang data is allowed. Will maps be allowed? What will you do to get a _canonical_ form for maps? 3. Use some other exchange format. Beware that the same issue can come up again. Two JSON writers might add different amounts or kinds of white space to the same term, or might sort slots of an object differently, or might display numbers differently (1000 vs 1.0e3, ...). Two XML writers might do different things, which is why Canonical XML exists. Whatever you choose, if there is any implementation freedom in the interface specification, you may need to make your own writer in Erlang or in the CMS or both. 4. Of course, Erlang being open source, you could always find the code that does ~p, clone it, and edit it. (Which is one way to do alternative 2, but probably harder.) From ok@REDACTED Tue Feb 11 01:12:48 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 11 Feb 2014 13:12:48 +1300 Subject: [erlang-questions] Indentation of multiline strings In-Reply-To: References: Message-ID: <4AD03252-3613-42C3-B9EB-E01EBCD86BA2@cs.otago.ac.nz> Emacs is not the only program that doesn't like multiline strings very much. One thing ANSI C89 added to Classic C was string pasting, so that you can write "this is a long string literal " "that extends across three lines " "and each line is visibly (part of) a string." Some people dislike this, possibly because it _only_ works for literals. I very much like the way it lets me indent parts of strings nicely. So it is possible to have a language in which you don't *need* multiline strings. Could we add this to Erlang? We don't need to! "this is a long string literal " ++ "that extends across three lines " ++ "and each line is visibly (part of) a string." is already legal Erlang, both in expressions and in patterns. So we can get *long* strings in Erlang without *multiline* strings. Speaking as a bear of very little brain, _I_ get confused when my eye falls on a an interior line of a multiline string, so I find the ++ style noticeably easier to read. There is the issue of converting multiline text to and from this form, but you already need to do something smart to handle embedded ", \, tabs, and/or control characters. From essen@REDACTED Tue Feb 11 01:16:48 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 11 Feb 2014 01:16:48 +0100 Subject: [erlang-questions] Indentation of multiline strings In-Reply-To: <4AD03252-3613-42C3-B9EB-E01EBCD86BA2@cs.otago.ac.nz> References: <4AD03252-3613-42C3-B9EB-E01EBCD86BA2@cs.otago.ac.nz> Message-ID: <52F96BF0.7040509@ninenines.eu> On 02/11/2014 01:12 AM, Richard A. O'Keefe wrote: > Emacs is not the only program that doesn't like multiline strings > very much. One thing ANSI C89 added to Classic C was string pasting, > so that you can write > > "this is a long string literal " > "that extends across three lines " > "and each line is visibly (part of) a string." > > Some people dislike this, possibly because it _only_ works for > literals. I very much like the way it lets me indent parts of > strings nicely. > > So it is possible to have a language in which you don't *need* > multiline strings. Could we add this to Erlang? Actually the example above is also legal in Erlang. You don't need to use ++ if you only have literals. It also works in binaries: << "this is a long string literal " "that extends across three lines " "and each line is visibly (part of) a string." >> -- Lo?c Hoguin http://ninenines.eu From ok@REDACTED Tue Feb 11 01:34:05 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 11 Feb 2014 13:34:05 +1300 Subject: [erlang-questions] Indentation of multiline strings In-Reply-To: <1392015672.4926.23.camel@sekic1152.release> References: <1392015672.4926.23.camel@sekic1152.release> Message-ID: It is now more years than I care to recall since I wrote the essay "Delenda est preprocessor." It is extremely hard for indent(1) to do a good job of C. Which is why it doesn't, really. For example, here is some legal C code. if (border) printf("\\hline"); rflag = border; for_each_element_child(e0, i, j, e1) printf(rflag ? "\\\\\n" : "\n"); rflag = true; cflag = false; for_each_element_child(e1, k, l, e2) if (cflag) printf(" & "); cflag = true; walk_paragraph("", e2, ""); end_each_element_child end_each_element_child if (border) printf("\\\\\\hline"); This is part of a program that turns slides marked up in SGML into LaTeX. It outputs the body of a table. for_each_element_child(Parent, I, J, Child) if_no_element_child end_each_element_child iterates over the children of Parent. The variable I counts all children. The variable J counts those children that are elements (as opposed to processing instructions, comments, PCDATA, unresolved entity references, &c). Child is bound to the corresponding child. Whenever such a Child is for, is executed. If Parent has no child that is an element, is executed; that part is optional. - If an indenter formats this with no knowledge of preprocessing, it will generate something unspeakably horrible. - If an indenter is smart enough to look inside the macros, it will produce something that makes sense, but since - for_each_element_child has four left curly braces - if_no_element_child has }} if (...) {{ - end_each_element child has four right curly braces the result will still not be something you want to read. - Only if an indenter can be told about *these* macros specifically will anything reasonable happen. - You really really REALLY do not want to do this stuff without such macros. You don't want to see how for_each_descendant(Ancestor, Descendant) end_each_descendant is implemented. You really don't. In practice, this means that the tolerably large amount of code I've written marching over SGML/XML documents -- and it may be C, but it's *still* simpler than XSLT! -- *cannot* be indented with indent(1) and still less can it be indented with emacs. What is the relevance of this to Erlang? Well, Erlang copied the C preprocessor, and must suffer the consequences. On 10/02/2014, at 8:01 PM, Bengt Kleberg wrote: > Greetings, > > One reason against a standalone formatter is that it could introduce > bugs in the code. That this is only a problem with a standalone > formatter is probably based upon that nobody would use a editor based > formatter and then not compile/test after wards. I do not believe that it IS "only a problem with a standalone formatter" and I for one always check the output of indent(1). > > To make a stand alone formatter with better level of confidence I > suggest using Erlang/OTP tools to create one of the intermediate level > formats (Core Erlang, "parse trees", the simplest/quickest/...) that > removes formatting. If this is done before and after the standalone > formatting, and the result is the same, then no bugs have been > introduced. I've always liked indenters that could cope with imperfect inputs. From anthonym@REDACTED Tue Feb 11 01:45:56 2014 From: anthonym@REDACTED (ANTHONY MOLINARO) Date: Mon, 10 Feb 2014 16:45:56 -0800 Subject: [erlang-questions] Performance analysis advice Message-ID: <00851615-E297-4982-A69E-DA5C2B2AB7B7@alumni.caltech.edu> Hi, I've been recently trying to find and eliminate bottlenecks in a web service. I had a few cases I knew were bottlenecks which I eliminated, and I've reached the point where I'm not sure what to look into next. The server is basically - webmachine - 3 backend services fronted by dispcount - each request is an erlang process which calls either 2 or 3 of the backend services in sequence, when a resource is unavailable the process will erlang:yield/0 and try again next time it is scheduled. - very little is done per request (or at least fprof doesn't show any hotspots). The current issue seems to a performance knee of some sort. As I add traffic to my test node I see CPU utilization spike at around 200 concurrent requests. It's a pretty dramatic knee, here's a sample of the data points (columns are timestamp, number of established connections 'netstat -n' and %cpu 'top -b'). 2014/02/11-00:34:02 0 8.0 2014/02/11-00:34:04 0 12.0 2014/02/11-00:34:06 14 95.8 2014/02/11-00:34:08 30 153.8 2014/02/11-00:34:10 34 169.7 2014/02/11-00:34:12 64 269.6 2014/02/11-00:34:14 58 311.5 2014/02/11-00:34:16 81 385.4 2014/02/11-00:34:18 94 463.3 2014/02/11-00:34:21 114 523.4 2014/02/11-00:34:23 114 595.0 2014/02/11-00:34:25 153 670.9 2014/02/11-00:34:27 149 777.2 2014/02/11-00:34:29 165 1359.5 2014/02/11-00:34:31 198 1529.3 2014/02/11-00:34:33 350 1517.4 2014/02/11-00:34:36 369 1523.2 2014/02/11-00:34:38 355 1525.3 It's a 16 core, so 1500% is pretty much maxed out. But notice the jump between 149 connections and 198 connections, it's almost double the CPU. I tried running the lock counting profiler during running and it looks like this lock id #tries #collisions collisions [%] time [us] duration [%] ----- --- ------- ------------ --------------- ---------- ------------- pollset 1 2369355 71578 3.0210 553249 0.7896 proc_main 154649 6315238 13325 0.2110 442908 0.6322 drv_ev_state 16 2311870 14609 0.6319 140019 0.1998 run_queue 16 9167097 55212 0.6023 117993 0.1684 proc_link 154649 2173804 3693 0.1699 111909 0.1597 proc_status 154649 5816882 3037 0.0522 106664 0.1522 proc_msgq 154649 3972636 3305 0.0832 56049 0.0800 process_table 1 444931 4711 1.0588 56042 0.0800 timeofday 1 1323351 6874 0.5194 22078 0.0315 atom_tab 1 1902423 22 0.0012 2187 0.0031 timer_wheel 1 582235 1186 0.2037 1322 0.0019 pollset_rm_list 1 1042209 2035 0.1953 942 0.0013 make_ref 1 373475 592 0.1585 458 0.0007 db_hash_slot 576 646402 203 0.0314 244 0.0003 alcu_allocator 9 18806 16 0.0851 212 0.0003 However, I'm not entirely sure how to interpret it, poll set seems have to do with scheduling, and I'm sure my use of yield is not recommended, but I don't think that would explain the knee I seem to be seeing. Anyway, I'm looking for any advice from others who might have some experience optimizing who might be able to point out what I'm doing wrong or point to libraries, talks, tools, documentation, or other things I might have missed. Thanks, -Anthony From mononcqc@REDACTED Tue Feb 11 02:04:57 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 10 Feb 2014 20:04:57 -0500 Subject: [erlang-questions] Performance analysis advice In-Reply-To: <00851615-E297-4982-A69E-DA5C2B2AB7B7@alumni.caltech.edu> References: <00851615-E297-4982-A69E-DA5C2B2AB7B7@alumni.caltech.edu> Message-ID: <20140211010457.GJ48745@ferdmbp.local> Hi Anthony, Glad to see someone using dispcount! Can I ask what are your pool sizes? Can the time increase correlate with the time you start getting busy or retrying a lot? I know that what you could be seeing is locking in dispcount itself. To allow fair redistribution of retries with dispcount, it makes use of erlang:now/0 which could easily be the problem you have there. See https://github.com/ferd/dispcount/blob/master/src/dispcount_watcher.erl#L148-149 I had never seen it be a problem before so I never optimized it away, but you could try subbing it with: dispatch_id(Num) -> erlang:phash2(local_unique(), Num) + 1. local_unique() -> Ct = case get('$dispcount_ct') of undefined -> put('$dispcount_ct', 1), 1; N -> put('$dispcount_ct', N+1), N+1 end, {Ct,self()}. That might be enough to keep giving even distribution, without needing external data (now()) -- the pid and counter could lead to enough uniqueness overall to work fine. If it goes well, let me know and I'll patch dispcount for this, and ask people I know who use it if they feel like giving it a try. Regards, Fred. On 02/10, ANTHONY MOLINARO wrote: > Hi, > > I've been recently trying to find and eliminate bottlenecks in a web service. I had a few cases I knew were bottlenecks which I eliminated, and I've reached the point where I'm not sure what to look into next. > > The server is basically > > - webmachine > - 3 backend services fronted by dispcount > - each request is an erlang process which calls either 2 or 3 of the backend services in sequence, when a resource is unavailable the process will erlang:yield/0 and try again next time it is scheduled. > - very little is done per request (or at least fprof doesn't show any hotspots). > > The current issue seems to a performance knee of some sort. As I add traffic to my test node I see CPU utilization spike at around 200 concurrent requests. It's a pretty dramatic knee, here's a sample of the data points (columns are timestamp, number of established connections 'netstat -n' and %cpu 'top -b'). > > 2014/02/11-00:34:02 0 8.0 > 2014/02/11-00:34:04 0 12.0 > 2014/02/11-00:34:06 14 95.8 > 2014/02/11-00:34:08 30 153.8 > 2014/02/11-00:34:10 34 169.7 > 2014/02/11-00:34:12 64 269.6 > 2014/02/11-00:34:14 58 311.5 > 2014/02/11-00:34:16 81 385.4 > 2014/02/11-00:34:18 94 463.3 > 2014/02/11-00:34:21 114 523.4 > 2014/02/11-00:34:23 114 595.0 > 2014/02/11-00:34:25 153 670.9 > 2014/02/11-00:34:27 149 777.2 > 2014/02/11-00:34:29 165 1359.5 > 2014/02/11-00:34:31 198 1529.3 > 2014/02/11-00:34:33 350 1517.4 > 2014/02/11-00:34:36 369 1523.2 > 2014/02/11-00:34:38 355 1525.3 > > It's a 16 core, so 1500% is pretty much maxed out. But notice the jump between 149 connections and 198 connections, it's almost double the CPU. > > I tried running the lock counting profiler during running and it looks like this > > lock id #tries #collisions collisions [%] time [us] duration [%] > ----- --- ------- ------------ --------------- ---------- ------------- > pollset 1 2369355 71578 3.0210 553249 0.7896 > proc_main 154649 6315238 13325 0.2110 442908 0.6322 > drv_ev_state 16 2311870 14609 0.6319 140019 0.1998 > run_queue 16 9167097 55212 0.6023 117993 0.1684 > proc_link 154649 2173804 3693 0.1699 111909 0.1597 > proc_status 154649 5816882 3037 0.0522 106664 0.1522 > proc_msgq 154649 3972636 3305 0.0832 56049 0.0800 > process_table 1 444931 4711 1.0588 56042 0.0800 > timeofday 1 1323351 6874 0.5194 22078 0.0315 > atom_tab 1 1902423 22 0.0012 2187 0.0031 > timer_wheel 1 582235 1186 0.2037 1322 0.0019 > pollset_rm_list 1 1042209 2035 0.1953 942 0.0013 > make_ref 1 373475 592 0.1585 458 0.0007 > db_hash_slot 576 646402 203 0.0314 244 0.0003 > alcu_allocator 9 18806 16 0.0851 212 0.0003 > > However, I'm not entirely sure how to interpret it, poll set seems have to do with scheduling, and I'm sure my use of yield is not recommended, but I don't think that would explain the knee I seem to be seeing. > > Anyway, I'm looking for any advice from others who might have some experience optimizing who might be able to point out what I'm doing wrong or point to libraries, talks, tools, documentation, or other things I might have missed. > > Thanks, > > -Anthony > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ok@REDACTED Tue Feb 11 02:10:30 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 11 Feb 2014 14:10:30 +1300 Subject: [erlang-questions] Alternatives to Elixir In-Reply-To: References: <52F940EC.6090303@ninenines.eu> <98B9DFF5-E736-4572-8E23-89A3E126FC56@gmail.com> Message-ID: <993598C5-D75E-4BC6-ADA2-7149580F106C@cs.otago.ac.nz> On 11/02/2014, at 11:01 AM, Jos? Valim wrote: > VBFE - Visual Basic flavored Elixir is coming until the end of the year. > > It will be followed by E#, for those who are unhappy with the lack of a language that uses curly brackets to delimit code blocks in the Erlang VM. E# already exists: it is the single-inheritance version of Eiffel for .NET, and it does not just curly braces for code blocks. From ok@REDACTED Tue Feb 11 02:12:13 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 11 Feb 2014 14:12:13 +1300 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <52F95C1D.5040301@ninenines.eu> References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> , <1B8F4A98-A99F-414F-A05A-996CCAF56383@cs.otago.ac.nz> <52F94ECC.1000704@ninenines.eu> <52F95C1D.5040301@ninenines.eu> Message-ID: On 11/02/2014, at 12:09 PM, Lo?c Hoguin wrote: > > One day not too long ago I decided to stop aligning entirely. Code is still as readable as before, and I don't have to spend any time worrying about prettifying the code (or fixing what the auto identation thing did). Nobody said my code is less readable because of it so far. Can you explain what you mean by "aligning"? From ok@REDACTED Tue Feb 11 02:17:05 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 11 Feb 2014 14:17:05 +1300 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <52F95D23.7050207@ninenines.eu> References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> , <1B8F4A98-A99F-414F-A05A-996CCAF56383@cs.otago.ac.nz> <52F94ECC.1000704@ninenines.eu> <12E100E5-38AB-4C74-9A61-CC2A510DCFB5@cs.otago.ac.nz> <52F95D23.7050207@ninenines.eu> Message-ID: Our message crossed. On 11/02/2014, at 12:13 PM, Lo?c Hoguin wrote: > > Indentation: > > myfunction(A, B, C, > D, E) -> > > Alignment: > > myfunction(A, B, C, > D, E) -> I don't call that "alignment", I call that "evil". As far as I am concerned, one of the core rules of good indentation is - the presence or absence of line breaks will depend on the size of names and constants - but the AMOUNT of indentation never will. Why? Because indentation is supposed to reveal STRUCTURE, not spelling. I would write this as my_function( A, B, C, D, E ) -> I know Lisp has traditionally used this style, but I decided decades ago that it was wrong, and I've never regretted it. > But also, skipping the indentation that would be to the left of these assignments... > > No alignment: > > A = 1, > Bartender = 17, > Car = 35, > > Alignment: > > A = 1, > Bartender = 17, > Car = 35, This I _do_ align, sometimes. It's not a case where I would ever have found tabs useful anyway. I also try to align blocks of related end-of-line comments so they start in the same column. For that I used to use tabs, but found it a pain. > > Hopefully it'll show up properly in the email. > > -- > Lo?c Hoguin > http://ninenines.eu From anthonym@REDACTED Tue Feb 11 02:34:09 2014 From: anthonym@REDACTED (ANTHONY MOLINARO) Date: Mon, 10 Feb 2014 17:34:09 -0800 Subject: [erlang-questions] Performance analysis advice In-Reply-To: <20140211010457.GJ48745@ferdmbp.local> References: <00851615-E297-4982-A69E-DA5C2B2AB7B7@alumni.caltech.edu> <20140211010457.GJ48745@ferdmbp.local> Message-ID: <5C3387FD-BDD3-41D5-8236-49423D1495B8@alumni.caltech.edu> Hi Fred, I'd actually been meaning to try dispcount out for some time, but only got to it recently when I was asked to look into optimizing this sub-system, since all our backends are thrift I ended up generalizing the cassanderl thrift layer and added my retry logic. Currently the pool sizes are 500, 500 and 200 (the one which is 200 is only hit on a small amount of requests, so even 200 is probably overkill). I tried upping the first 2 to 800 to see if I could get more throughput, but it did not seem to have an effect. I noticed the use of now(), and just replaced it with os:timestamp/0. I also did the same thing in a handful of places in webmachine. When I first did the lock counting the timeofday lock was 3-4x what it is now. I'll try out your function tomorrow and compare to the os:timestamp() version, I have a feeling it won't make too much difference as os:timestamp() is pretty fast (and as far as I know doesn't use the timeofday lock), but we'll see. The pollset lock really seems to be the one contending, but I'd have to dig into the emulator a bit to really understand if there's anything I can do there. I also feel I might be able to use some of the scheduler flags to good effect, but haven't quite figured out how yet :) I'm On Feb 10, 2014, at 5:04 PM, Fred Hebert wrote: > Hi Anthony, > > Glad to see someone using dispcount! > > Can I ask what are your pool sizes? Can the time increase correlate with > the time you start getting busy or retrying a lot? > > I know that what you could be seeing is locking in dispcount itself. To > allow fair redistribution of retries with dispcount, it makes use of > erlang:now/0 which could easily be the problem you have there. > > See https://github.com/ferd/dispcount/blob/master/src/dispcount_watcher.erl#L148-149 > > I had never seen it be a problem before so I never optimized it away, > but you could try subbing it with: > > dispatch_id(Num) -> > erlang:phash2(local_unique(), Num) + 1. > > local_unique() -> > Ct = case get('$dispcount_ct') of > undefined -> put('$dispcount_ct', 1), 1; > N -> put('$dispcount_ct', N+1), N+1 > end, > {Ct,self()}. > > That might be enough to keep giving even distribution, without needing > external data (now()) -- the pid and counter could lead to enough > uniqueness overall to work fine. > > If it goes well, let me know and I'll patch dispcount for this, and ask > people I know who use it if they feel like giving it a try. > > Regards, > Fred. > > On 02/10, ANTHONY MOLINARO wrote: >> Hi, >> >> I've been recently trying to find and eliminate bottlenecks in a web service. I had a few cases I knew were bottlenecks which I eliminated, and I've reached the point where I'm not sure what to look into next. >> >> The server is basically >> >> - webmachine >> - 3 backend services fronted by dispcount >> - each request is an erlang process which calls either 2 or 3 of the backend services in sequence, when a resource is unavailable the process will erlang:yield/0 and try again next time it is scheduled. >> - very little is done per request (or at least fprof doesn't show any hotspots). >> >> The current issue seems to a performance knee of some sort. As I add traffic to my test node I see CPU utilization spike at around 200 concurrent requests. It's a pretty dramatic knee, here's a sample of the data points (columns are timestamp, number of established connections 'netstat -n' and %cpu 'top -b'). >> >> 2014/02/11-00:34:02 0 8.0 >> 2014/02/11-00:34:04 0 12.0 >> 2014/02/11-00:34:06 14 95.8 >> 2014/02/11-00:34:08 30 153.8 >> 2014/02/11-00:34:10 34 169.7 >> 2014/02/11-00:34:12 64 269.6 >> 2014/02/11-00:34:14 58 311.5 >> 2014/02/11-00:34:16 81 385.4 >> 2014/02/11-00:34:18 94 463.3 >> 2014/02/11-00:34:21 114 523.4 >> 2014/02/11-00:34:23 114 595.0 >> 2014/02/11-00:34:25 153 670.9 >> 2014/02/11-00:34:27 149 777.2 >> 2014/02/11-00:34:29 165 1359.5 >> 2014/02/11-00:34:31 198 1529.3 >> 2014/02/11-00:34:33 350 1517.4 >> 2014/02/11-00:34:36 369 1523.2 >> 2014/02/11-00:34:38 355 1525.3 >> >> It's a 16 core, so 1500% is pretty much maxed out. But notice the jump between 149 connections and 198 connections, it's almost double the CPU. >> >> I tried running the lock counting profiler during running and it looks like this >> >> lock id #tries #collisions collisions [%] time [us] duration [%] >> ----- --- ------- ------------ --------------- ---------- ------------- >> pollset 1 2369355 71578 3.0210 553249 0.7896 >> proc_main 154649 6315238 13325 0.2110 442908 0.6322 >> drv_ev_state 16 2311870 14609 0.6319 140019 0.1998 >> run_queue 16 9167097 55212 0.6023 117993 0.1684 >> proc_link 154649 2173804 3693 0.1699 111909 0.1597 >> proc_status 154649 5816882 3037 0.0522 106664 0.1522 >> proc_msgq 154649 3972636 3305 0.0832 56049 0.0800 >> process_table 1 444931 4711 1.0588 56042 0.0800 >> timeofday 1 1323351 6874 0.5194 22078 0.0315 >> atom_tab 1 1902423 22 0.0012 2187 0.0031 >> timer_wheel 1 582235 1186 0.2037 1322 0.0019 >> pollset_rm_list 1 1042209 2035 0.1953 942 0.0013 >> make_ref 1 373475 592 0.1585 458 0.0007 >> db_hash_slot 576 646402 203 0.0314 244 0.0003 >> alcu_allocator 9 18806 16 0.0851 212 0.0003 >> >> However, I'm not entirely sure how to interpret it, poll set seems have to do with scheduling, and I'm sure my use of yield is not recommended, but I don't think that would explain the knee I seem to be seeing. >> >> Anyway, I'm looking for any advice from others who might have some experience optimizing who might be able to point out what I'm doing wrong or point to libraries, talks, tools, documentation, or other things I might have missed. >> >> Thanks, >> >> -Anthony >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions From noah@REDACTED Tue Feb 11 02:41:41 2014 From: noah@REDACTED (Noah Diewald) Date: Mon, 10 Feb 2014 19:41:41 -0600 Subject: [erlang-questions] Alternatives to Elixir In-Reply-To: <52F946C4.9090106@gmail.com> References: <52F946C4.9090106@gmail.com> Message-ID: <87k3d2ifxm.fsf@diewald.me> Mercury! http://mercurylang.org/ mjtruog@REDACTED writes: > lfe http://lfe.github.io/ > luerl https://github.com/rvirding/luerl > erlog https://github.com/rvirding/erlog > efene http://marianoguerra.com.ar/efene/ > reia http://reia-lang.org/ > > There are probably others I have missed. > > On 02/10/2014 01:09 PM, Mike Oxford wrote: >> Ruby feels like VB. >> >> I don't like VB, thus, I don't like Ruby. >> >> I like what Elixir is attempting to do but the syntax makes me have flashbacks and want to puke. (Personal problem, I know.) >> >> Are there other, similar projects out there with a different spoonful of sugar to help it go down? >> >> 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 From n.oxyde@REDACTED Tue Feb 11 02:51:04 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 11 Feb 2014 02:51:04 +0100 Subject: [erlang-questions] Performance analysis advice In-Reply-To: <20140211010457.GJ48745@ferdmbp.local> References: <00851615-E297-4982-A69E-DA5C2B2AB7B7@alumni.caltech.edu> <20140211010457.GJ48745@ferdmbp.local> Message-ID: I would first profile with make_ref/0 instead of now/0. No idea if that is actually better, but from reading the code it looks to me it does less while still retaining only one lock. At least it is still monotonic. Regards, -- Anthony Ramine Le 11 f?vr. 2014 ? 02:04, Fred Hebert a ?crit : > Hi Anthony, > > Glad to see someone using dispcount! > > Can I ask what are your pool sizes? Can the time increase correlate with > the time you start getting busy or retrying a lot? > > I know that what you could be seeing is locking in dispcount itself. To > allow fair redistribution of retries with dispcount, it makes use of > erlang:now/0 which could easily be the problem you have there. > > See https://github.com/ferd/dispcount/blob/master/src/dispcount_watcher.erl#L148-149 > > I had never seen it be a problem before so I never optimized it away, > but you could try subbing it with: > > dispatch_id(Num) -> > erlang:phash2(local_unique(), Num) + 1. > > local_unique() -> > Ct = case get('$dispcount_ct') of > undefined -> put('$dispcount_ct', 1), 1; > N -> put('$dispcount_ct', N+1), N+1 > end, > {Ct,self()}. > > That might be enough to keep giving even distribution, without needing > external data (now()) -- the pid and counter could lead to enough > uniqueness overall to work fine. > > If it goes well, let me know and I'll patch dispcount for this, and ask > people I know who use it if they feel like giving it a try. > > Regards, > Fred. > > On 02/10, ANTHONY MOLINARO wrote: >> Hi, >> >> I've been recently trying to find and eliminate bottlenecks in a web service. I had a few cases I knew were bottlenecks which I eliminated, and I've reached the point where I'm not sure what to look into next. >> >> The server is basically >> >> - webmachine >> - 3 backend services fronted by dispcount >> - each request is an erlang process which calls either 2 or 3 of the backend services in sequence, when a resource is unavailable the process will erlang:yield/0 and try again next time it is scheduled. >> - very little is done per request (or at least fprof doesn't show any hotspots). >> >> The current issue seems to a performance knee of some sort. As I add traffic to my test node I see CPU utilization spike at around 200 concurrent requests. It's a pretty dramatic knee, here's a sample of the data points (columns are timestamp, number of established connections 'netstat -n' and %cpu 'top -b'). >> >> 2014/02/11-00:34:02 0 8.0 >> 2014/02/11-00:34:04 0 12.0 >> 2014/02/11-00:34:06 14 95.8 >> 2014/02/11-00:34:08 30 153.8 >> 2014/02/11-00:34:10 34 169.7 >> 2014/02/11-00:34:12 64 269.6 >> 2014/02/11-00:34:14 58 311.5 >> 2014/02/11-00:34:16 81 385.4 >> 2014/02/11-00:34:18 94 463.3 >> 2014/02/11-00:34:21 114 523.4 >> 2014/02/11-00:34:23 114 595.0 >> 2014/02/11-00:34:25 153 670.9 >> 2014/02/11-00:34:27 149 777.2 >> 2014/02/11-00:34:29 165 1359.5 >> 2014/02/11-00:34:31 198 1529.3 >> 2014/02/11-00:34:33 350 1517.4 >> 2014/02/11-00:34:36 369 1523.2 >> 2014/02/11-00:34:38 355 1525.3 >> >> It's a 16 core, so 1500% is pretty much maxed out. But notice the jump between 149 connections and 198 connections, it's almost double the CPU. >> >> I tried running the lock counting profiler during running and it looks like this >> >> lock id #tries #collisions collisions [%] time [us] duration [%] >> ----- --- ------- ------------ --------------- ---------- ------------- >> pollset 1 2369355 71578 3.0210 553249 0.7896 >> proc_main 154649 6315238 13325 0.2110 442908 0.6322 >> drv_ev_state 16 2311870 14609 0.6319 140019 0.1998 >> run_queue 16 9167097 55212 0.6023 117993 0.1684 >> proc_link 154649 2173804 3693 0.1699 111909 0.1597 >> proc_status 154649 5816882 3037 0.0522 106664 0.1522 >> proc_msgq 154649 3972636 3305 0.0832 56049 0.0800 >> process_table 1 444931 4711 1.0588 56042 0.0800 >> timeofday 1 1323351 6874 0.5194 22078 0.0315 >> atom_tab 1 1902423 22 0.0012 2187 0.0031 >> timer_wheel 1 582235 1186 0.2037 1322 0.0019 >> pollset_rm_list 1 1042209 2035 0.1953 942 0.0013 >> make_ref 1 373475 592 0.1585 458 0.0007 >> db_hash_slot 576 646402 203 0.0314 244 0.0003 >> alcu_allocator 9 18806 16 0.0851 212 0.0003 >> >> However, I'm not entirely sure how to interpret it, poll set seems have to do with scheduling, and I'm sure my use of yield is not recommended, but I don't think that would explain the knee I seem to be seeing. >> >> Anyway, I'm looking for any advice from others who might have some experience optimizing who might be able to point out what I'm doing wrong or point to libraries, talks, tools, documentation, or other things I might have missed. >> >> Thanks, >> >> -Anthony >> _______________________________________________ >> 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 n.oxyde@REDACTED Tue Feb 11 03:10:06 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 11 Feb 2014 03:10:06 +0100 Subject: [erlang-questions] Performance analysis advice In-Reply-To: <00851615-E297-4982-A69E-DA5C2B2AB7B7@alumni.caltech.edu> References: <00851615-E297-4982-A69E-DA5C2B2AB7B7@alumni.caltech.edu> Message-ID: <010E516D-93CE-4244-8F7F-DF5C977DB515@gmail.com> Did you made any tweak to polling etc? This lock is owned by erl_poll. -- Anthony Ramine Le 11 f?vr. 2014 ? 01:45, ANTHONY MOLINARO a ?crit : > pollset 1 2369355 71578 3.0210 553249 0.7896 From ok@REDACTED Tue Feb 11 03:31:24 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 11 Feb 2014 15:31:24 +1300 Subject: [erlang-questions] Maps single value access not implemented In-Reply-To: <87a9dzku09.fsf@gmail.com> References: <8AC108D6-C490-499C-A755-FE85D0BA96C3@icloud.com> <87iosnvggq.fsf@gmail.com> <52F89577.6000405@ninenines.eu> <87eh3bkw2h.fsf@gmail.com> <52F8C488.1040001@ninenines.eu> <87a9dzku09.fsf@gmail.com> Message-ID: There are three different cases: - I want this field to be replaced. It MUST exist. - I want this field to be added. It must NOT exist. - I want this field to have this value and I DON'T CARE whether it existed before or not. Both of the first two cases are important for detecting errors. In the frames proposal, the *operation* was the same in all cases, as I thought the checks should be delegated to the Dialyzer. From sdl.web@REDACTED Tue Feb 11 06:19:29 2014 From: sdl.web@REDACTED (Leo Liu) Date: Tue, 11 Feb 2014 13:19:29 +0800 Subject: [erlang-questions] Can epp_dodge:parse accept a ram_file? Message-ID: In {ok, IoDevice} = file:open(Text, [ram]), epp_dodger:parse(IoDevice, 1, [{no_fail, true}]) where Text is a string, I am always getting: exception error: no function clause matching io:request({file_descriptor,ram_file,#Port<0.13034>}, {get_until,unicode,[],erl_scan,tokens,[1,[]]}) (io.erl, line 553) Ideas? Thanks, Leo Erlang/OTP 17 [RELEASE CANDIDATE 1] [erts-6.0] [source-0cbf6ec7] From bengt.kleberg@REDACTED Tue Feb 11 07:08:28 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 11 Feb 2014 07:08:28 +0100 Subject: [erlang-questions] Can epp_dodge:parse accept a ram_file? In-Reply-To: References: Message-ID: <1392098908.5096.4.camel@sekic1152.release> Greetings, The documentation for file:open/2 says that the ram option will give "an fd() which lets the file module operate on the data in-memory as if it is a file." We are not assured that epp_dodger:parse/3 will accept it. Your test seems to show that it does not. Have you tried the fd() from ram with the io module, too? bengt On Tue, 2014-02-11 at 13:19 +0800, Leo Liu wrote: > In > > {ok, IoDevice} = file:open(Text, [ram]), > epp_dodger:parse(IoDevice, 1, [{no_fail, true}]) > > where Text is a string, I am always getting: > > exception error: no function clause matching > io:request({file_descriptor,ram_file,#Port<0.13034>}, > {get_until,unicode,[],erl_scan,tokens,[1,[]]}) (io.erl, line 553) > > Ideas? > > Thanks, > Leo > > Erlang/OTP 17 [RELEASE CANDIDATE 1] [erts-6.0] [source-0cbf6ec7] > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bengt.kleberg@REDACTED Tue Feb 11 07:16:26 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 11 Feb 2014 07:16:26 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> , <1B8F4A98-A99F-414F-A05A-996CCAF56383@cs.otago.ac.nz> <52F94ECC.1000704@ninenines.eu> <12E100E5-38AB-4C74-9A61-CC2A510DCFB5@cs.otago.ac.nz> <52F95D23.7050207@ninenines.eu> Message-ID: <1392099386.5096.11.camel@sekic1152.release> Greetings, Is it not difficult to preserve alignment when using both variable width characters and fixed width characters tools? bengt On Tue, 2014-02-11 at 14:17 +1300, Richard A. O'Keefe wrote: > Our message crossed. > > On 11/02/2014, at 12:13 PM, Lo?c Hoguin wrote: > > > > Indentation: > > > > myfunction(A, B, C, > > D, E) -> > > > > Alignment: > > > > myfunction(A, B, C, > > D, E) -> > > I don't call that "alignment", I call that "evil". > As far as I am concerned, one of the core rules of > good indentation is > - the presence or absence of line breaks will > depend on the size of names and constants > - but the AMOUNT of indentation never will. > > Why? Because indentation is supposed to reveal > STRUCTURE, not spelling. > > I would write this as > > my_function( > A, B, C, D, E > ) -> > > I know Lisp has traditionally used this style, > but I decided decades ago that it was wrong, > and I've never regretted it. > > > But also, skipping the indentation that would be to the left of these assignments... > > > > No alignment: > > > > A = 1, > > Bartender = 17, > > Car = 35, > > > > Alignment: > > > > A = 1, > > Bartender = 17, > > Car = 35, > > This I _do_ align, sometimes. It's not a case where I would > ever have found tabs useful anyway. > > I also try to align blocks of related end-of-line comments > so they start in the same column. For that I used to use > tabs, but found it a pain. > > > > > > Hopefully it'll show up properly in the email. > > > > -- > > Lo?c Hoguin > > http://ninenines.eu > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bengt.kleberg@REDACTED Tue Feb 11 07:28:56 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 11 Feb 2014 07:28:56 +0100 Subject: [erlang-questions] Indentation of multiline strings In-Reply-To: References: <1392015672.4926.23.camel@sekic1152.release> Message-ID: <1392100136.5096.22.camel@sekic1152.release> Greetings, My comment that indention creating bugs "is only a problem with a standalone formatter is probably based upon ..." was based upon this list only mentioning standalone formatter when warning about bugs created by indention. Formatting imperfect inputs is is probably not a place where bugs introduced by the formatter is a problem. That code will be tested. bengt On Tue, 2014-02-11 at 13:34 +1300, Richard A. O'Keefe wrote: > It is now more years than I care to recall since I wrote > the essay "Delenda est preprocessor." > > It is extremely hard for indent(1) to do a good job of C. > Which is why it doesn't, really. > > For example, here is some legal C code. > > if (border) printf("\\hline"); > rflag = border; > for_each_element_child(e0, i, j, e1) > printf(rflag ? "\\\\\n" : "\n"); > rflag = true; > cflag = false; > for_each_element_child(e1, k, l, e2) > if (cflag) printf(" & "); > cflag = true; > walk_paragraph("", e2, ""); > end_each_element_child > end_each_element_child > if (border) printf("\\\\\\hline"); > > This is part of a program that turns slides marked up in SGML > into LaTeX. It outputs the body of a table. > > for_each_element_child(Parent, I, J, Child) > > if_no_element_child > > end_each_element_child > > iterates over the children of Parent. The variable I > counts all children. The variable J counts those children > that are elements (as opposed to processing instructions, > comments, PCDATA, unresolved entity references, &c). Child > is bound to the corresponding child. Whenever such a Child > is for, is executed. If Parent > has no child that is an element, is > executed; that part is optional. > > - If an indenter formats this with no knowledge of preprocessing, > it will generate something unspeakably horrible. > - If an indenter is smart enough to look inside the macros, it > will produce something that makes sense, but since > - for_each_element_child has four left curly braces > - if_no_element_child has }} if (...) {{ > - end_each_element child has four right curly braces > the result will still not be something you want to read. > - Only if an indenter can be told about *these* macros specifically > will anything reasonable happen. > - You really really REALLY do not want to do this stuff without > such macros. You don't want to see how > > for_each_descendant(Ancestor, Descendant) > > end_each_descendant > > is implemented. You really don't. > > In practice, this means that the tolerably large amount of code > I've written marching over SGML/XML documents -- and it may be > C, but it's *still* simpler than XSLT! -- *cannot* be indented > with indent(1) and still less can it be indented with emacs. > > What is the relevance of this to Erlang? > > Well, Erlang copied the C preprocessor, and must suffer the > consequences. > > On 10/02/2014, at 8:01 PM, Bengt Kleberg wrote: > > > Greetings, > > > > One reason against a standalone formatter is that it could introduce > > bugs in the code. That this is only a problem with a standalone > > formatter is probably based upon that nobody would use a editor based > > formatter and then not compile/test after wards. > > I do not believe that it IS "only a problem with a standalone > formatter" and I for one always check the output of indent(1). > > > > To make a stand alone formatter with better level of confidence I > > suggest using Erlang/OTP tools to create one of the intermediate level > > formats (Core Erlang, "parse trees", the simplest/quickest/...) that > > removes formatting. If this is done before and after the standalone > > formatting, and the result is the same, then no bugs have been > > introduced. > > I've always liked indenters that could cope with imperfect inputs. > > From anthonym@REDACTED Tue Feb 11 08:04:50 2014 From: anthonym@REDACTED (ANTHONY MOLINARO) Date: Mon, 10 Feb 2014 23:04:50 -0800 Subject: [erlang-questions] Performance analysis advice In-Reply-To: References: <00851615-E297-4982-A69E-DA5C2B2AB7B7@alumni.caltech.edu> <20140211010457.GJ48745@ferdmbp.local> Message-ID: <820F48CA-C73D-43C1-83D4-F57B6497F529@alumni.caltech.edu> I had already found that and changed to os:timestamp() instead of now(). The only danger is if repeated calls to os:timestamp() returned the same value. I'm not really seeing that but Fred's suggestion of storing a count in the process dictionary for a pid should also work and be guaranteed monotonic. -Anthony On Feb 10, 2014, at 5:51 PM, Anthony Ramine wrote: > I would first profile with make_ref/0 instead of now/0. > > No idea if that is actually better, but from reading the code it looks to me it does less while still retaining only one lock. At least it is still monotonic. > > Regards, > > -- > Anthony Ramine > > Le 11 f?vr. 2014 ? 02:04, Fred Hebert a ?crit : > >> Hi Anthony, >> >> Glad to see someone using dispcount! >> >> Can I ask what are your pool sizes? Can the time increase correlate with >> the time you start getting busy or retrying a lot? >> >> I know that what you could be seeing is locking in dispcount itself. To >> allow fair redistribution of retries with dispcount, it makes use of >> erlang:now/0 which could easily be the problem you have there. >> >> See https://github.com/ferd/dispcount/blob/master/src/dispcount_watcher.erl#L148-149 >> >> I had never seen it be a problem before so I never optimized it away, >> but you could try subbing it with: >> >> dispatch_id(Num) -> >> erlang:phash2(local_unique(), Num) + 1. >> >> local_unique() -> >> Ct = case get('$dispcount_ct') of >> undefined -> put('$dispcount_ct', 1), 1; >> N -> put('$dispcount_ct', N+1), N+1 >> end, >> {Ct,self()}. >> >> That might be enough to keep giving even distribution, without needing >> external data (now()) -- the pid and counter could lead to enough >> uniqueness overall to work fine. >> >> If it goes well, let me know and I'll patch dispcount for this, and ask >> people I know who use it if they feel like giving it a try. >> >> Regards, >> Fred. >> >> On 02/10, ANTHONY MOLINARO wrote: >>> Hi, >>> >>> I've been recently trying to find and eliminate bottlenecks in a web service. I had a few cases I knew were bottlenecks which I eliminated, and I've reached the point where I'm not sure what to look into next. >>> >>> The server is basically >>> >>> - webmachine >>> - 3 backend services fronted by dispcount >>> - each request is an erlang process which calls either 2 or 3 of the backend services in sequence, when a resource is unavailable the process will erlang:yield/0 and try again next time it is scheduled. >>> - very little is done per request (or at least fprof doesn't show any hotspots). >>> >>> The current issue seems to a performance knee of some sort. As I add traffic to my test node I see CPU utilization spike at around 200 concurrent requests. It's a pretty dramatic knee, here's a sample of the data points (columns are timestamp, number of established connections 'netstat -n' and %cpu 'top -b'). >>> >>> 2014/02/11-00:34:02 0 8.0 >>> 2014/02/11-00:34:04 0 12.0 >>> 2014/02/11-00:34:06 14 95.8 >>> 2014/02/11-00:34:08 30 153.8 >>> 2014/02/11-00:34:10 34 169.7 >>> 2014/02/11-00:34:12 64 269.6 >>> 2014/02/11-00:34:14 58 311.5 >>> 2014/02/11-00:34:16 81 385.4 >>> 2014/02/11-00:34:18 94 463.3 >>> 2014/02/11-00:34:21 114 523.4 >>> 2014/02/11-00:34:23 114 595.0 >>> 2014/02/11-00:34:25 153 670.9 >>> 2014/02/11-00:34:27 149 777.2 >>> 2014/02/11-00:34:29 165 1359.5 >>> 2014/02/11-00:34:31 198 1529.3 >>> 2014/02/11-00:34:33 350 1517.4 >>> 2014/02/11-00:34:36 369 1523.2 >>> 2014/02/11-00:34:38 355 1525.3 >>> >>> It's a 16 core, so 1500% is pretty much maxed out. But notice the jump between 149 connections and 198 connections, it's almost double the CPU. >>> >>> I tried running the lock counting profiler during running and it looks like this >>> >>> lock id #tries #collisions collisions [%] time [us] duration [%] >>> ----- --- ------- ------------ --------------- ---------- ------------- >>> pollset 1 2369355 71578 3.0210 553249 0.7896 >>> proc_main 154649 6315238 13325 0.2110 442908 0.6322 >>> drv_ev_state 16 2311870 14609 0.6319 140019 0.1998 >>> run_queue 16 9167097 55212 0.6023 117993 0.1684 >>> proc_link 154649 2173804 3693 0.1699 111909 0.1597 >>> proc_status 154649 5816882 3037 0.0522 106664 0.1522 >>> proc_msgq 154649 3972636 3305 0.0832 56049 0.0800 >>> process_table 1 444931 4711 1.0588 56042 0.0800 >>> timeofday 1 1323351 6874 0.5194 22078 0.0315 >>> atom_tab 1 1902423 22 0.0012 2187 0.0031 >>> timer_wheel 1 582235 1186 0.2037 1322 0.0019 >>> pollset_rm_list 1 1042209 2035 0.1953 942 0.0013 >>> make_ref 1 373475 592 0.1585 458 0.0007 >>> db_hash_slot 576 646402 203 0.0314 244 0.0003 >>> alcu_allocator 9 18806 16 0.0851 212 0.0003 >>> >>> However, I'm not entirely sure how to interpret it, poll set seems have to do with scheduling, and I'm sure my use of yield is not recommended, but I don't think that would explain the knee I seem to be seeing. >>> >>> Anyway, I'm looking for any advice from others who might have some experience optimizing who might be able to point out what I'm doing wrong or point to libraries, talks, tools, documentation, or other things I might have missed. >>> >>> Thanks, >>> >>> -Anthony >>> _______________________________________________ >>> 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 anthonym@REDACTED Tue Feb 11 08:11:14 2014 From: anthonym@REDACTED (ANTHONY MOLINARO) Date: Mon, 10 Feb 2014 23:11:14 -0800 Subject: [erlang-questions] Performance analysis advice In-Reply-To: <010E516D-93CE-4244-8F7F-DF5C977DB515@gmail.com> References: <00851615-E297-4982-A69E-DA5C2B2AB7B7@alumni.caltech.edu> <010E516D-93CE-4244-8F7F-DF5C977DB515@gmail.com> Message-ID: <08693ADC-D499-4EAF-95BB-D65D478A162E@alumni.caltech.edu> No, I haven't other than setting '+K true' (are there other tweaks)? One of my experiments tomorrow will be to set '+K false' to see if falling back to select doesn't use the pollset. I'm also planning to instrument the number of times I call erlang:yield/0 when I fail to get a resource. I know the documentation warns about using erlang:yield/0 but it does seem to do what I want, which is to try again in a little bit (I want to keep the connections open and retry up to a timeout, which should have the effect of also applying back pressure to upstream load balancers). Anyway, still looking for more suggestions on thing to look for. Thanks, -Anthony On Feb 10, 2014, at 6:10 PM, Anthony Ramine wrote: > Did you made any tweak to polling etc? This lock is owned by erl_poll. > > -- > Anthony Ramine > > Le 11 f?vr. 2014 ? 01:45, ANTHONY MOLINARO a ?crit : > >> pollset 1 2369355 71578 3.0210 553249 0.7896 > From sdl.web@REDACTED Tue Feb 11 07:28:04 2014 From: sdl.web@REDACTED (Leo Liu) Date: Tue, 11 Feb 2014 14:28:04 +0800 Subject: [erlang-questions] Can epp_dodge:parse accept a ram_file? References: <1392098908.5096.4.camel@sekic1152.release> Message-ID: On 2014-02-11 14:08 +0800, Bengt Kleberg wrote: > Greetings, Hi, > The documentation for file:open/2 says that the ram option will give > "an fd() which lets the file module operate on the data in-memory as > if it is a file." We are not assured that epp_dodger:parse/3 will > accept it. Your test seems to show that it does not. > > Have you tried the fd() from ram with the io module, too? I just did with io:get_chars/3 and io:read/2 but getting the same error anyways. > bengt Leo From bengt.kleberg@REDACTED Tue Feb 11 09:15:10 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 11 Feb 2014 09:15:10 +0100 Subject: [erlang-questions] Can epp_dodge:parse accept a ram_file? In-Reply-To: References: <1392098908.5096.4.camel@sekic1152.release> Message-ID: <1392106510.5096.29.camel@sekic1152.release> Greetings, Ages ago I did a string_io module that allowed epp_dodger:parse/1 to work on strings. Would that be of interest? bengt On Tue, 2014-02-11 at 14:28 +0800, Leo Liu wrote: > On 2014-02-11 14:08 +0800, Bengt Kleberg wrote: > > Greetings, > > Hi, > > > The documentation for file:open/2 says that the ram option will give > > "an fd() which lets the file module operate on the data in-memory as > > if it is a file." We are not assured that epp_dodger:parse/3 will > > accept it. Your test seems to show that it does not. > > > > Have you tried the fd() from ram with the io module, too? > > I just did with io:get_chars/3 and io:read/2 but getting the same error > anyways. > > > bengt > > Leo > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From n.oxyde@REDACTED Tue Feb 11 10:20:26 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 11 Feb 2014 10:20:26 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <1392099386.5096.11.camel@sekic1152.release> References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> , <1B8F4A98-A99F-414F-A05A-996CCAF56383@cs.otago.ac.nz> <52F94ECC.1000704@ninenines.eu> <12E100E5-38AB-4C74-9A61-CC2A510DCFB5@cs.otago.ac.nz> <52F95D23.7050207@ninenines.eu> <1392099386.5096.11.camel@sekic1152.release> Message-ID: No need to mix anything, it is hard to preserve in presence of any tab. -- Anthony Ramine Le 11 f?vr. 2014 ? 07:16, Bengt Kleberg a ?crit : > Greetings, > > Is it not difficult to preserve alignment when using both variable width > characters and fixed width characters tools? > > > bengt > > On Tue, 2014-02-11 at 14:17 +1300, Richard A. O'Keefe wrote: >> Our message crossed. >> >> On 11/02/2014, at 12:13 PM, Lo?c Hoguin wrote: >>> >>> Indentation: >>> >>> myfunction(A, B, C, >>> D, E) -> >>> >>> Alignment: >>> >>> myfunction(A, B, C, >>> D, E) -> >> >> I don't call that "alignment", I call that "evil". >> As far as I am concerned, one of the core rules of >> good indentation is >> - the presence or absence of line breaks will >> depend on the size of names and constants >> - but the AMOUNT of indentation never will. >> >> Why? Because indentation is supposed to reveal >> STRUCTURE, not spelling. >> >> I would write this as >> >> my_function( >> A, B, C, D, E >> ) -> >> >> I know Lisp has traditionally used this style, >> but I decided decades ago that it was wrong, >> and I've never regretted it. >> >>> But also, skipping the indentation that would be to the left of these assignments... >>> >>> No alignment: >>> >>> A = 1, >>> Bartender = 17, >>> Car = 35, >>> >>> Alignment: >>> >>> A = 1, >>> Bartender = 17, >>> Car = 35, >> >> This I _do_ align, sometimes. It's not a case where I would >> ever have found tabs useful anyway. >> >> I also try to align blocks of related end-of-line comments >> so they start in the same column. For that I used to use >> tabs, but found it a pain. >> >> >>> >>> Hopefully it'll show up properly in the email. >>> >>> -- >>> Lo?c Hoguin >>> http://ninenines.eu >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bengt.kleberg@REDACTED Tue Feb 11 10:41:51 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 11 Feb 2014 10:41:51 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> , <1B8F4A98-A99F-414F-A05A-996CCAF56383@cs.otago.ac.nz> <52F94ECC.1000704@ninenines.eu> <12E100E5-38AB-4C74-9A61-CC2A510DCFB5@cs.otago.ac.nz> <52F95D23.7050207@ninenines.eu> <1392099386.5096.11.camel@sekic1152.release> Message-ID: <1392111711.5096.41.camel@sekic1152.release> Greetings, I thought more of aligning difficulties given variable width characters and fixed width characters in different programs/tools. No tabs included. bengt On Tue, 2014-02-11 at 10:20 +0100, Anthony Ramine wrote: > No need to mix anything, it is hard to preserve in presence of any > tab. > > -- > Anthony Ramine > > Le 11 f?vr. 2014 ? 07:16, Bengt Kleberg a > ?crit : > > > Greetings, > > > > Is it not difficult to preserve alignment when using both variable > width > > characters and fixed width characters tools? > > > > > > bengt From fly@REDACTED Tue Feb 11 10:47:06 2014 From: fly@REDACTED (Fred Youhanaie) Date: Tue, 11 Feb 2014 09:47:06 +0000 Subject: [erlang-questions] Erlang Solutions webinar "Understanding the Erlang Scheduler" In-Reply-To: <52F493EB.9040206@gmail.com> References: <52F493EB.9040206@gmail.com> Message-ID: <52F9F19A.9030400@anydata.co.uk> On 07/02/14 08:06, Martin Koroudjiev wrote: > Hello, > > Unfortunately I missed it. Is it recorded anywhere? https://www.erlang-solutions.com/resources/webinars/understanding-erlang-scheduler Enjoy! f. From essen@REDACTED Tue Feb 11 10:50:20 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 11 Feb 2014 10:50:20 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <1392111711.5096.41.camel@sekic1152.release> References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> , <1B8F4A98-A99F-414F-A05A-996CCAF56383@cs.otago.ac.nz> <52F94ECC.1000704@ninenines.eu> <12E100E5-38AB-4C74-9A61-CC2A510DCFB5@cs.otago.ac.nz> <52F95D23.7050207@ninenines.eu> <1392099386.5096.11.camel@sekic1152.release> <1392111711.5096.41.camel@sekic1152.release> Message-ID: <52F9F25C.3050803@ninenines.eu> Alignment is *impossible* with fonts with variable width characters. And a few editors have such a font by default. That's a good point. If you do alignment, then your code will look bad for some people. On 02/11/2014 10:41 AM, Bengt Kleberg wrote: > Greetings, > > I thought more of aligning difficulties given variable width characters > and fixed width characters in different programs/tools. No tabs > included. > > > bengt > > On Tue, 2014-02-11 at 10:20 +0100, Anthony Ramine wrote: >> No need to mix anything, it is hard to preserve in presence of any >> tab. >> >> -- >> Anthony Ramine >> >> Le 11 f?vr. 2014 ? 07:16, Bengt Kleberg a >> ?crit : >> >>> Greetings, >>> >>> Is it not difficult to preserve alignment when using both variable >> width >>> characters and fixed width characters tools? >>> >>> >>> bengt > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From essen@REDACTED Tue Feb 11 10:53:10 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 11 Feb 2014 10:53:10 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> , <1B8F4A98-A99F-414F-A05A-996CCAF56383@cs.otago.ac.nz> <52F94ECC.1000704@ninenines.eu> <12E100E5-38AB-4C74-9A61-CC2A510DCFB5@cs.otago.ac.nz> <52F95D23.7050207@ninenines.eu> Message-ID: <52F9F306.3090100@ninenines.eu> On 02/11/2014 02:17 AM, Richard A. O'Keefe wrote: > Our message crossed. > > On 11/02/2014, at 12:13 PM, Lo?c Hoguin wrote: >> >> Indentation: >> >> myfunction(A, B, C, >> D, E) -> >> >> Alignment: >> >> myfunction(A, B, C, >> D, E) -> > > I don't call that "alignment", I call that "evil". > As far as I am concerned, one of the core rules of > good indentation is > - the presence or absence of line breaks will > depend on the size of names and constants > - but the AMOUNT of indentation never will. > > Why? Because indentation is supposed to reveal > STRUCTURE, not spelling. I agree. Unfortunately many people align there. > I would write this as > > my_function( > A, B, C, D, E > ) -> That certainly looks better. -- Lo?c Hoguin http://ninenines.eu From jesper.louis.andersen@REDACTED Tue Feb 11 10:56:54 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 11 Feb 2014 10:56:54 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <52F9F25C.3050803@ninenines.eu> References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> <1B8F4A98-A99F-414F-A05A-996CCAF56383@cs.otago.ac.nz> <52F94ECC.1000704@ninenines.eu> <12E100E5-38AB-4C74-9A61-CC2A510DCFB5@cs.otago.ac.nz> <52F95D23.7050207@ninenines.eu> <1392099386.5096.11.camel@sekic1152.release> <1392111711.5096.41.camel@sekic1152.release> <52F9F25C.3050803@ninenines.eu> Message-ID: The acme text editor (from plan9) uses a variable width font by default. There are several advantages to this, including easier to read text and better horizontal width of text. Let us see how it interprets tabs: "Tab intervals are set to the width of 4 (or the value of $tabstop) numeral zeros in the appropriate font." So a tab is interpreted as the length of 4 '0' characters in the font you have chosen. This makes it impossible to align data by default, which frankly is quite liberating. You stop caring about such stuff[0]. The general rule is that you can't make assumptions about how people will render data in a file. [0] I do have a monospaced font which I can switch to when it becomes necessary. On Tue, Feb 11, 2014 at 10:50 AM, Lo?c Hoguin wrote: > Alignment is *impossible* with fonts with variable width characters. And a > few editors have such a font by default. That's a good point. If you do > alignment, then your code will look bad for some people. > > > On 02/11/2014 10:41 AM, Bengt Kleberg wrote: > >> Greetings, >> >> I thought more of aligning difficulties given variable width characters >> and fixed width characters in different programs/tools. No tabs >> included. >> >> >> bengt >> >> On Tue, 2014-02-11 at 10:20 +0100, Anthony Ramine wrote: >> >>> No need to mix anything, it is hard to preserve in presence of any >>> tab. >>> >>> -- >>> Anthony Ramine >>> >>> Le 11 f?vr. 2014 ? 07:16, Bengt Kleberg a >>> ?crit : >>> >>> Greetings, >>>> >>>> Is it not difficult to preserve alignment when using both variable >>>> >>> width >>> >>>> characters and fixed width characters tools? >>>> >>>> >>>> bengt >>>> >>> >> _______________________________________________ >> 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 > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Tue Feb 11 11:35:14 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 11 Feb 2014 11:35:14 +0100 Subject: [erlang-questions] Alternatives to Elixir In-Reply-To: References: <52F940EC.6090303@ninenines.eu> <98B9DFF5-E736-4572-8E23-89A3E126FC56@gmail.com> Message-ID: It defines a relation. We have that X gives reflux if: 1) X reminds you of Y 2) Y gives you reflux. You can then ask the prolog system to search for all X satisfying the reflux condition and it will give you back several possible answers. One will be ruby, since it reminds you of vb and vb gives reflux. But that means elixir also gives reflux since it reminds you of ruby and ruby gives reflux. I would like to see more prolog-like features in Erlang btw :) On Mon, Feb 10, 2014 at 11:29 PM, Ludovic Demblans wrote: > Wow this prolog thing is hard to grasp on a first sight ... > > does 'reminds_of(X,Y) binds Y 'ruby' if we pass 'elixir' as X in > 'reflux(X)' ? > > Le Mon, 10 Feb 2014 22:34:50 +0100, Anthony Ramine a > ?crit: > > > If you like Prolog, there is also Robert Virding?s Erlog: >> >> https://github.com/rvirding/erlog >> >> reflux(vb). >> >> reminds_of(ruby, vb). >> reminds_of(elixir, ruby). >> >> reflux(X) :- >> reminds_of(X, Y), >> reflux(Y). >> >> > > -- > Utilisant le logiciel de courrier r?volutionnaire d'Opera : > http://www.opera.com/mail/ > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdl.web@REDACTED Tue Feb 11 13:57:35 2014 From: sdl.web@REDACTED (Leo Liu) Date: Tue, 11 Feb 2014 20:57:35 +0800 Subject: [erlang-questions] Can epp_dodge:parse accept a ram_file? References: <1392098908.5096.4.camel@sekic1152.release> <1392106510.5096.29.camel@sekic1152.release> Message-ID: On 2014-02-11 16:15 +0800, Bengt Kleberg wrote: > Ages ago I did a string_io module that allowed epp_dodger:parse/1 to > work on strings. Would that be of interest? Yes, where can I find it? Thanks, Leo From sina.samv@REDACTED Tue Feb 11 17:05:23 2014 From: sina.samv@REDACTED (Sina Samavati) Date: Tue, 11 Feb 2014 19:35:23 +0330 Subject: [erlang-questions] Can epp_dodge:parse accept a ram_file? References: Message-ID: <877g91my7w.fsf@gmail.com> Leo Liu writes: > In > > {ok, IoDevice} = file:open(Text, [ram]), > epp_dodger:parse(IoDevice, 1, [{no_fail, true}]) > > where Text is a string, I am always getting: > > exception error: no function clause matching > io:request({file_descriptor,ram_file,#Port<0.13034>}, > {get_until,unicode,[],erl_scan,tokens,[1,[]]}) (io.erl, line 553) In your snippet, IoDevice is '{file_descriptor, ram_file, #}', whereas the first argument of epp_dodger:parse/3 must be a Pid. Why don't create a temporary file? -- Sina Samavati Software engineer https://github.com/s1n4 https://twitter.com/sinasamavati From andra.dinu@REDACTED Tue Feb 11 19:21:50 2014 From: andra.dinu@REDACTED (Andra Dinu) Date: Tue, 11 Feb 2014 19:21:50 +0100 (CET) Subject: [erlang-questions] Erlang Factory SF Bay Area 6-7 March: Early Bird deadline extended until 14 February In-Reply-To: <446019900.1304950.1392142881746.JavaMail.zimbra@erlang-solutions.com> Message-ID: <1530026649.1304987.1392142910983.JavaMail.zimbra@erlang-solutions.com> Good News! We've extended the Early Bird deadline with 4 more days! We have had some requests for extended deadlines from people waiting for approvals from their superiors, so we figured: 'Why not do it for everyone? Let's give a nice Valentines' Day surprise to all Erlang lovers out there.' http://www.erlang-factory.com/conference/show/conference-6/home/#home -- Andra Dinu Community & Social ERLANG SOLUTIONS LTD New Loom House 101 Back Church Lane London, E1 1LU United Kingdom Tel +44(0)2076550344 Mob +44(0)7983484387 www.erlang-solutions.com From dmercer@REDACTED Tue Feb 11 21:12:57 2014 From: dmercer@REDACTED (David Mercer) Date: Tue, 11 Feb 2014 14:12:57 -0600 Subject: [erlang-questions] What is the difference between maps and dict in R17 In-Reply-To: References: <16eb8541.5280.1440ba50d11.Coremail.zehongzheng2008@163.com> Message-ID: <009601cf2765$a86400e0$f92c02a0$@gmail.com> Also, maps cannot have variable keys. Cheers, DBM From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Jesper Louis Andersen Sent: Friday, February 07, 2014 06:39 To: ?? Cc: Erlang (E-mail) Subject: Re: [erlang-questions] What is the difference between maps and dict in R17 In the long run, maps may probably subsume dict and gb_trees. In the short term they won't since maps currently is not optimized for a large number of keys. On Fri, Feb 7, 2014 at 10:19 AM, ?? wrote: Both of maps and dict are used as map, so when and where to use maps? _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From garazdawi@REDACTED Tue Feb 11 21:56:12 2014 From: garazdawi@REDACTED (Lukas Larsson) Date: Tue, 11 Feb 2014 21:56:12 +0100 Subject: [erlang-questions] What is the difference between maps and dict in R17 In-Reply-To: <009601cf2765$a86400e0$f92c02a0$@gmail.com> References: <16eb8541.5280.1440ba50d11.Coremail.zehongzheng2008@163.com> <009601cf2765$a86400e0$f92c02a0$@gmail.com> Message-ID: Maps does not have a syntax for variable keys, that does not mean that you cannot have variable keys. Using the maps module you can add and get any keys you want to a map. Lukas On Tue, Feb 11, 2014 at 9:12 PM, David Mercer wrote: > Also, maps cannot have variable keys. > > > > Cheers, > > > > DBM > > > > *From:* erlang-questions-bounces@REDACTED [mailto: > erlang-questions-bounces@REDACTED] *On Behalf Of *Jesper Louis Andersen > *Sent:* Friday, February 07, 2014 06:39 > *To:* ?? > *Cc:* Erlang (E-mail) > *Subject:* Re: [erlang-questions] What is the difference between maps and > dict in R17 > > > > In the long run, maps may probably subsume dict and gb_trees. In the short > term they won't since maps currently is not optimized for a large number of > keys. > > > > On Fri, Feb 7, 2014 at 10:19 AM, ?? wrote: > > Both of maps and dict are used as map, so when and where to use maps? > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > -- > J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zambal@REDACTED Tue Feb 11 22:38:09 2014 From: zambal@REDACTED (Vincent Siliakus) Date: Tue, 11 Feb 2014 22:38:09 +0100 Subject: [erlang-questions] purpose of enif_schedule_dirty_nif_finalizer Message-ID: I'm experimenting a bit with the new dirty scheduler functionality for NIFs and have already some working code, but I was wondering what the purpose is of enif_schedule_dirty_nif_finalizer and enif_dirty_nif_finalizer. I know documentation about dirty schedulers should be coming when OTP 17.0 is released, but maybe somebody can already give some pointers about how and why they should be used. thanks, vincent From vinoski@REDACTED Tue Feb 11 22:51:57 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Tue, 11 Feb 2014 16:51:57 -0500 Subject: [erlang-questions] purpose of enif_schedule_dirty_nif_finalizer In-Reply-To: References: Message-ID: On Tue, Feb 11, 2014 at 4:38 PM, Vincent Siliakus wrote: > I'm experimenting a bit with the new dirty scheduler functionality for > NIFs and have already some working code, but I was wondering what the > purpose is of enif_schedule_dirty_nif_finalizer and > enif_dirty_nif_finalizer. > > I know documentation about dirty schedulers should be coming when OTP > 17.0 is released, but maybe somebody can already give some pointers > about how and why they should be used. Below find the descriptions that are in the 17.0 documentation sources on github master. If you have further questions, let me know. BTW both descriptions are accompanied by this note: This function is available only when the emulator is configured with dirty schedulers enabled. This feature is currently disabled by default. To determine whether the dirty NIF API is available, native code can check to see if the C preprocessor macro ERL_NIF_DIRTY_SCHEDULER_SUPPORT is defined. Oh, and all of this is subject to change, of course, as this is an experimental feature of 17.0. --steve ERL_NIF_TERM enif_schedule_dirty_nif_finalizer(ErlNifEnv* env, ERL_NIF_TERM result, ERL_NIF_TERM (*fp)(ErlNifEnv* env, ERL_NIF_TERM result)) When a dirty NIF finishes executing, it must schedule a finalizer function to return its result to the original NIF caller. The dirty NIF passes result as the value it wants the finalizer to use as the return value. The fp argument is a pointer to the finalizer function. The NIF API provides the enif_dirty_nif_finalizer function that can be used as a finalizer that simply returns its result argument. You are also free to write your own custom finalizer that uses result to derive a different return value, or ignores result entirely and returns a completely different value. Without exception, all dirty NIFs must invoke enif_schedule_dirty_nif_finalizer to complete their execution. ERL_NIF_TERM enif_dirty_nif_finalizer(ErlNifEnv* env, ERL_NIF_TERM result) A convenience function that a dirty NIF can use as a finalizer that simply return its result argument as its return value. This function is provided for dirty NIFs with results that should be returned directly to the original caller. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Tue Feb 11 22:55:57 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 12 Feb 2014 10:55:57 +1300 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <1392099386.5096.11.camel@sekic1152.release> References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> , <1B8F4A98-A99F-414F-A05A-996CCAF56383@cs.otago.ac.nz> <52F94ECC.1000704@ninenines.eu> <12E100E5-38AB-4C74-9A61-CC2A510DCFB5@cs.otago.ac.nz> <52F95D23.7050207@ninenines.eu> <1392099386.5096.11.camel@sekic1152.release> Message-ID: On 11/02/2014, at 7:16 PM, Bengt Kleberg wrote: > Is it not difficult to preserve alignment when using both variable width > characters and fixed width characters tools? I understand the question to be: - some tools (group G) display program source code using monospaced fonts - some tools (group E) display program source code using proportional fonts - without any reference to TAB characters, - surely it is difficult to write neatly aligned files that display reasonable in both sets of tools? To which the answer is "yes, certainly." That's why I classified the tools as G(ood) and E(vil). If you don't care about lining things up in a tabular way to reveal common structure, then "blind" group E tools may work for you; you won't _have_ any alignment that you care to preserve, so group G tools will also work for you. If you want proportional fonts AND you want neat tabular formats, then you need some kind of "smart" group E tool. For example, you might want to write your code in Microsoft Word -- don't laugh, I've known it done -- using its facilities for managing tabulation, and have the code automatically extracted from the text, using a "code" style to mark the chunks you want. In that case, of course, you don't greatly care about alignment in the raw code, so don't worry about preserving it. From kraythe@REDACTED Tue Feb 11 23:17:38 2014 From: kraythe@REDACTED (kraythe .) Date: Tue, 11 Feb 2014 16:17:38 -0600 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: <71D26997-BBC2-41F7-BCAB-592E45D28609@cs.otago.ac.nz> References: <71D26997-BBC2-41F7-BCAB-592E45D28609@cs.otago.ac.nz> Message-ID: Richard, I appreciate your response and the effort you put into it. And I learned a lot from it. In this case I am learning the thinking mode of Erlang as it is different a bit from what I do to pay the bills. I have yet to get into list comprehensions in Erlang so that is on my ... well ... list. :) You have provided valuable insight. The main focus of the method is if I have a number of objects with a vector position in a simulation and I want to exclude considerations of interactions with objects outside the sphere of influence, I have to quickly discard the candidates that are not inside the sphere of influence. I originally thought to write a method that did just the vector math because I was wondering if that kind of math would have to ultimately be turned into something native. Even a delay of 1 second would be fatal to the simulation. The algorithm, however, shouldnt have to consider all candidates as the world is broken into spacial segments (cubes) such that the sphere could intersect with at maximum 8 neighboring cubes so I would only need to consider simulation objects within those 8 cube spaces when determining which elements were actually within the sphere of influence. I have been trying to devise a method of reducing the candidate set even further and am still working on that. Perhaps edge detection and cube boundary calculations but I don't want to spend more math doing that then I would simply excluding objects vector by vector. Anyway thanks for the reply, definitely some information that I can use in there. *Robert Simmons Jr. MSc.* On Sun, Feb 9, 2014 at 10:59 PM, Richard A. O'Keefe wrote: > > On 8/02/2014, at 4:53 AM, kraythe . wrote: > > Anyway back to the subject at hand. The algorithm is set but now I am at > another quandary Lets say these vectors represent a position in space of > particular objects in a simulation. The process of culling the vectors > based on the sphere is entirely a vector problem but what the user calling > cull/3 really needs to know is which objects are not culled from the list, > not just which vectors are not culled. Now in Java I could do a number of > things if I wanted to keep the cull algorithm as it is. I could return the > list of integers containing the original indexes of the vectors in the list > that were culled and use that to filter out which objects need to be > considered for the simulation step. > > The word "cull" really grates. > > And all those negations *really* confused me *all over again*. > I wrote a lengthy and helpful description of how to get the > points that were accepted and the points that were rejected > as two lists, because that was the only way I could interpret > your question to make sense in Erlang. But on repeated re-reading > it became clear that you were asking for something else. > > There is no such thing in Erlang as object identity. > The distinction you are drawing between the "points" and the > "objects" simply doesn't exist. > > It so happens that if you use a list comprehension like > [P || P <- Points, some_predicate(P)] > the elements of the result *will* be (references to) the same > implementation-level webs of chunks of memory that were in the > original list, not copies. But nothing other than performance > depends on this. > > A list of integers such as you ask for could be obtained, but it > would be very little use to you, because Erlang lists are *LINKED > LISTS*, not *INDEXED ARRAYS*. Finding the nth element of a list > takes O(n) time, and that could not be changed without making > lists much less useful. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmercer@REDACTED Tue Feb 11 23:40:46 2014 From: dmercer@REDACTED (David Mercer) Date: Tue, 11 Feb 2014 16:40:46 -0600 Subject: [erlang-questions] What is the difference between maps and dict in R17 In-Reply-To: References: <16eb8541.5280.1440ba50d11.Coremail.zehongzheng2008@163.com> <009601cf2765$a86400e0$f92c02a0$@gmail.com> Message-ID: <00b801cf277a$4e730d50$eb5927f0$@gmail.com> Thanks for that clarification. I had asked on Reddit whether they would be a viable replacement for dicts, and that had been the answer. Maybe I?ll try maps after all? Cheers, DBM From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Lukas Larsson Sent: Tuesday, February 11, 2014 14:56 To: Erlang (E-mail) Subject: Re: [erlang-questions] What is the difference between maps and dict in R17 Maps does not have a syntax for variable keys, that does not mean that you cannot have variable keys. Using the maps module you can add and get any keys you want to a map. Lukas On Tue, Feb 11, 2014 at 9:12 PM, David Mercer wrote: Also, maps cannot have variable keys. Cheers, DBM From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Jesper Louis Andersen Sent: Friday, February 07, 2014 06:39 To: ?? Cc: Erlang (E-mail) Subject: Re: [erlang-questions] What is the difference between maps and dict in R17 In the long run, maps may probably subsume dict and gb_trees. In the short term they won't since maps currently is not optimized for a large number of keys. On Fri, Feb 7, 2014 at 10:19 AM, ?? wrote: Both of maps and dict are used as map, so when and where to use maps? _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -- J. _______________________________________________ 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 Wed Feb 12 00:39:48 2014 From: sdl.web@REDACTED (Leo Liu) Date: Wed, 12 Feb 2014 07:39:48 +0800 Subject: [erlang-questions] Can epp_dodge:parse accept a ram_file? In-Reply-To: <877g91my7w.fsf@gmail.com> (Sina Samavati's message of "Tue, 11 Feb 2014 19:35:23 +0330") References: <877g91my7w.fsf@gmail.com> Message-ID: On 2014-02-12 00:05 +0800, Sina Samavati wrote: > In your snippet, IoDevice is '{file_descriptor, ram_file, #}', whereas the > first argument of epp_dodger:parse/3 must be a Pid. > Why don't create a temporary file? I already I have the Text so going through the file system is only a fallback when nothing better is found. epp_dodger:parse/3 makes use of io:parse_erl_form and it seems from the documentation it ought to work with ram_file. Leo From rickard@REDACTED Wed Feb 12 00:43:43 2014 From: rickard@REDACTED (Rickard Green) Date: Wed, 12 Feb 2014 00:43:43 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <1391790979.26271.YahooMailNeo@web140106.mail.bf1.yahoo.com> References: <52F4C173.8050408@erlang.org> <1391790979.26271.YahooMailNeo@web140106.mail.bf1.yahoo.com> Message-ID: On Fri, Feb 7, 2014 at 5:36 PM, Thomas Lindgren wrote: > > > " 1> erlang:system_info(otp_release). > "17" > 2> erlang:system_info(otp_correction_package). > "17.0-rc1" > > NOTE: The name of the argument "otp_correction_package" will be changed > to "otp_version."" > > Any possibility of changing the naming conventions to something more easily memorized? For example, otp_major_release ("17") vs otp_release ("17.0-rc1"). (Presumably, the second one is the one people will usually want to know?) > > Not to say I'm committed to what I just proposed, but I just know I shall evermore have to consult the manual to get otp_release and otp_version straight. The reason to why they are as they are, and in my opinion should remain so follow below. I should say that we've had lots of different opinions about this at OTP. A brief history of how OTP releases have been named. Prior to R13B, OTP release names used to be a number in between an R and a B (with a few exceptions that I'll for simplicity ignore since they won't effect the reasoning). At first the open-source community got access to the RB release and nothing more until RB was released. At some point we began publishing the latest patch level more frequently to the open-source community. If I remember correct, this was during the R10B release. In order to keep these open-source tar-balls apart we added a "-" behind the release name, where was an integer counter incremented for each tar-ball put up on the web-site. During R10B we published 11 tar-balls R10B, R10B-1, ..., R10B-10. One R10B plain without patches and 10 R10B with snapshots of different patch levels. Each and every one containing the latest R10B patch level when they were published. All of them containing the OTP *R10B* release at different patch levels. As of R13B we switched from publishing tar-balls at different patch-levels to actually introducing minor releases R13B01, R13B02, ... This was not just a switch in naming convention. We actually released new releases which is an important point. For example, the R13B01 release name was exposed in start scripts, etc. As of OTP 17 we kind of go back to how it used to be before R13B, but we drop the R and the B. When we publish new tar-balls (and tags in git) after the plain release it will not be a new release, but instead a snapshot of a patch level. A major point of doing this change is to get rid of these minor releases as true releases. I won't go into why since this text is long as it is anyway. Internally at Ericsson we have a sequence of patch numbers that we use in order to identify a specific patch. This sequence span all releases. When we publish a patch on an application of a specific release this patch number is incremented. For example, patch number 874 is a patch level on R11B and 916 is a patch level on R10B. The only conclusion you can draw from the patch level number is which patch was first published. In R10B we did not expose this patch level number but instead gave the tar-ball yet another number (-). As of OTP 17 we drop this patch level number sequence and start using one set of patch level numbers per release. The patch level is not expressed as an integer as it used to be, but instead as a version number ..[. ...], for example, 17.0.1. This way the patch level gives you a bit more information. You can for example see directly which OTP release it applies to. This patch level version number also replace the - tar-ball naming scheme. That is, the release that we soon are about to release is OTP 17, not OTP 17.0. OTP 17.0 is a patch level identifier that in this case happens to identify the OTP 17 plain release. When/If OTP 17.6.1 is published, it is still the OTP 17 release, but with a different patch level. Since you today can fetch stuff directly from git you may stumble across OTP patch levels that have not been publicly announced. If you build and install such a system. You can then later, by looking at the OTP patch level, get a feeling of how it relate to the publicly announced patch levels. Now to my point. If erlang:system_info(otp_release) is supposed to behave as it always have behaved (which I think it should) it should return the release name (as a string) and not the patch level. That is, it should during the following release return "17", and nothing else. Previously we have not had an erlang:system_info() argument giving you the patch level. The erlang:system_info(otp_correction_package)/erlang:system_info(otp_version) is a new argument, and is intended to give you the patch level that we currently are on. (See the documentation of otp_correction_package for further information) That is, when the OTP 17 plain release is published erlang:system_info(otp_correction_package)/erlang:system_info(otp_version) will return "17.0". When/if patch level 17.6.1 is published erlang:system_info(otp_release) will still return "17", but erlang:system_info(otp_correction_package)/erlang:system_info(otp_version) will return "17.6.1". Sorry for the long text. It was way shorter in my head :-/ > > > (Also, consider if there ever were to be a second supplier of erlang. Wouldn't it be better to use option names that do not include "otp" to get this information?) I think using the otp_ prefix is exactly what we want. If I start releasing Erlang/RG think I should badarg on erlang:system_info(otp_release), and return something useful from erlang:system_info(rg_release) instead. Regards, Rickard Green, Erlang/OTP, Ericsson AB From ok@REDACTED Wed Feb 12 01:06:27 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 12 Feb 2014 13:06:27 +1300 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: <71D26997-BBC2-41F7-BCAB-592E45D28609@cs.otago.ac.nz> Message-ID: Perhaps the most important piece of advice I can give you is that there is an existing Erlang program you might find useful: Wings3D. Quoting http://www.wings3d.com Wings 3D is an advanced subdivision modeler that is both powerful and easy to use. Wings 3D offers a wide range of modeling tools, a customizable interface, support for lights and materials, and a built-in AutoUV mapping facility. There is no support in Wings for animation. Wings 3D is written in Erlang, an open source, functional programming language distributed by Ericsson. It's actively maintained; release 1.5.2 came out in November last year. And it's open source. > I appreciate your response and the effort you put into it. And I learned a lot from it. In this case I am learning the thinking mode of Erlang as it is different a bit from what I do to pay the bills. I have yet to get into list comprehensions in Erlang so that is on my ... well ... list. :) You have provided valuable insight. In the simplest case, list comprehension is [ E1 || P <- E2, E3 ] which says for every element of E2, if that element matches P (binding any variables), and E3 comes out true, incorporate the value of E1 into the list we're building. Adding more "<-" parts gives you nested loops. The notation is based on mathematical notation for sets: { e | x ? s, f } "the set of all e such that x is an element of s satisfying f". Almost the only well known functional language that _doesn't_ have list comprehensions is SML. > > The main focus of the method is if I have a number of objects with a vector position in a simulation and I want to exclude considerations of interactions with objects outside the sphere of influence, I have to quickly discard the candidates that are not inside the sphere of influence. Then the collection of candidates needs to have some structure, such as an oct-tree. If you have the elements in a list, you have to do *something* with every element just to reach the last element. > I originally thought to write a method that did just the vector math because I was wondering if that kind of math would have to ultimately be turned into something native. With HiPE, you _get_ native code. If you give it suitable declarations, such as -type pt3() :: {float(),float(),float()}. -spec dot(pt3(), pt3()) -> float. dot({X1,Y1,Z1}, {X2,Y2,Z2}) -> X1*X2 + Y1*Y2 + Z1*Z2. [NOT TESTED] you get _reasonable_ native code. I think you probably want to get Wings3D and play with it for a bit to get an idea of what _can_ be done in Erlang. (What I found out is that I have no artistic talent whatsoever, even _with_ a computer and a fancy tool. Sigh.) There's also http://sourceforge.net/projects/rosen/ which I just found out about. "ROSEN means RObotic Simulation Erlang eNgine; it is a software library, written in Erlang, which simulates 3D environments and in particular autonomous mobile robots, each with its behaviour and interaction capabilities." I have no idea how good it is, but there's probably something there you can stealXXXXXlearn from. From anthonym@REDACTED Wed Feb 12 02:04:19 2014 From: anthonym@REDACTED (ANTHONY MOLINARO) Date: Tue, 11 Feb 2014 17:04:19 -0800 Subject: [erlang-questions] Performance analysis advice In-Reply-To: <08693ADC-D499-4EAF-95BB-D65D478A162E@alumni.caltech.edu> References: <00851615-E297-4982-A69E-DA5C2B2AB7B7@alumni.caltech.edu> <010E516D-93CE-4244-8F7F-DF5C977DB515@gmail.com> <08693ADC-D499-4EAF-95BB-D65D478A162E@alumni.caltech.edu> Message-ID: <13668B47-730E-4DB4-B2E1-2DF057654D5D@alumni.caltech.edu> So '+K false' seems to cause quite a bit less lock contention, although it doesn't remove the performance knee :( Here's with '+K true' lock id #tries #collisions collisions [%] time [us] duration [%] ----- --- ------- ------------ --------------- ---------- ------------- pollset 1 2439901 81002 3.3199 617130 0.8811 proc_main 159392 6402529 13807 0.2156 311906 0.4453 drv_ev_state 16 2373507 15719 0.6623 189350 0.2703 run_queue 16 9288814 58470 0.6295 136295 0.1946 process_table 1 457253 5411 1.1834 116726 0.1666 proc_link 159392 2182726 3669 0.1681 102834 0.1468 proc_status 159392 5879890 3079 0.0524 81224 0.1160 pix_lock 1024 1183 3 0.2536 75758 0.1082 proc_msgq 159392 4032954 3387 0.0840 35624 0.0509 timeofday 1 1403251 7160 0.5102 21584 0.0308 atom_tab 1 1948202 19 0.0010 2494 0.0036 timer_wheel 1 588379 1127 0.1915 1197 0.0017 pollset_rm_list 1 1116613 2220 0.1988 920 0.0013 db_hash_slot 576 642980 209 0.0325 578 0.0008 make_ref 1 372880 581 0.1558 554 0.0008 alcu_allocator 9 18660 18 0.0965 88 0.0001 and here's with '+K false' lock id #tries #collisions collisions [%] time [us] duration [%] ----- --- ------- ------------ --------------- ---------- ------------- proc_main 159151 6387799 13079 0.2047 626344 0.8941 proc_link 159151 2180755 3625 0.1662 132246 0.1888 run_queue 16 8997639 51163 0.5686 119858 0.1711 proc_status 159151 5837885 3160 0.0541 114003 0.1627 pix_lock 1024 1231 9 0.7311 96727 0.1381 proc_msgq 159151 4018925 3202 0.0797 83066 0.1186 process_table 1 452460 5544 1.2253 78856 0.1126 drv_ev_state 16 2454941 30392 1.2380 72814 0.1039 pollset 1 2424508 28413 1.1719 41359 0.0590 timeofday 1 870046 4161 0.4783 12728 0.0182 atom_tab 1 1950265 59 0.0030 6262 0.0089 timer_wheel 1 481116 958 0.1991 1148 0.0016 pollset_rm_list 1 784445 1383 0.1763 923 0.0013 db_hash_slot 576 645025 213 0.0330 462 0.0007 make_ref 1 370122 581 0.1570 378 0.0005 alcu_allocator 9 18229 10 0.0549 240 0.0003 async_enq_mtx 16 6505 1 0.0154 1 0.0000 Unfortunately, today was one of my meeting days so I didn't get to try more than this, but it is interesting to see the effect that +K has on locking. I think I'll try tracing during the knee (hopefully it won't be too much overhead) to see if I can figure out why I am still seeing the spike in CPU. -Anthony On Feb 10, 2014, at 11:11 PM, ANTHONY MOLINARO wrote: > No, I haven't other than setting '+K true' (are there other tweaks)? > > One of my experiments tomorrow will be to set '+K false' to see if falling back to select doesn't use the pollset. > > I'm also planning to instrument the number of times I call erlang:yield/0 when I fail to get a resource. I know the documentation warns about using erlang:yield/0 but it does seem to do what I want, which is to try again in a little bit (I want to keep the connections open and retry up to a timeout, which should have the effect of also applying back pressure to upstream load balancers). > > Anyway, still looking for more suggestions on thing to look for. > > Thanks, > > -Anthony > > > On Feb 10, 2014, at 6:10 PM, Anthony Ramine wrote: > >> Did you made any tweak to polling etc? This lock is owned by erl_poll. >> >> -- >> Anthony Ramine >> >> Le 11 f?vr. 2014 ? 01:45, ANTHONY MOLINARO a ?crit : >> >>> pollset 1 2369355 71578 3.0210 553249 0.7896 >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From n.oxyde@REDACTED Wed Feb 12 02:48:13 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 12 Feb 2014 02:48:13 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: <52F4C173.8050408@erlang.org> <1391790979.26271.YahooMailNeo@web140106.mail.bf1.yahoo.com> Message-ID: <49EC93AB-69A4-49AB-A2C0-4DA9F418E3F6@gmail.com> So OTP won?t follow semantic versioning, right? Just seeking confirmation about semver. Regards, -- Anthony Ramine Le 12 f?vr. 2014 ? 00:43, Rickard Green a ?crit : > As of OTP 17 we drop this patch level number sequence and start using > one set of patch level numbers per release. The patch level is not > expressed as an integer as it used to be, but instead as a version > number ..[. ...], for example, 17.0.1. This way the patch > level gives you a bit more information. You can for example see > directly which OTP release it applies to. This patch level version > number also replace the - tar-ball naming scheme. From cabo@REDACTED Tue Feb 11 23:51:59 2014 From: cabo@REDACTED (Carsten Bormann) Date: Tue, 11 Feb 2014 23:51:59 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> <1B8F4A98-A99F-414F-A05A-996CCAF56383@cs.otago.ac.nz> <52F94ECC.1000704@ninenines.eu> <12E100E5-38AB-4C74-9A61-CC2A510DCFB5@cs.otago.ac.nz> <52F95D23.7050207@ninenines.eu> <1392099386.5096.11.camel@sekic1152.release> <1392111711.5096.41.camel@sekic1152.release> <52F9F25C.3050803@ninenines.eu> Message-ID: On 11 Feb 2014, at 10:56, Jesper Louis Andersen wrote: > variable width font You can get alignment with that with a simple algorithm: For every sequence of two or more space characters, note the column of the end of the sequence (measured in characters), note the position (in escapement units) of the same column in the previous line, and align to that. Doesn?t always work perfectly, but except for pathological cases, preserves the meaning of most source codes laboriously aligned on fixed-width terminals. (Certainly was good enough for my Prolog programs in 1984. I?m not sure I still have the code that generated the troff input out of the Prolog.) Now get that code into Emacs :-) Gr??e, Carsten PS.: Elixir looks so much less like VB when set in Baskerville! Combine with prettify-symbols-mode... From co7eb@REDACTED Wed Feb 12 05:34:37 2014 From: co7eb@REDACTED (=?iso-8859-1?Q?Ivan_Carmenates_Garc=EDa?=) Date: Tue, 11 Feb 2014 23:34:37 -0500 Subject: [erlang-questions] ChicagoBoss 0.8.7 with PostgreSQL 9.2 Message-ID: <000001cf27ab$c28e99d0$47abcd70$@frcuba.co.cu> Hi all, I?m in the middle of some project and I have troubles connecting cb with postgreSQL I?m using the full and stable version of cb 0.8.7 because the new one isn?t possible for me to get from here. Rebar uses a peer protocol or something that is not a simple http request to connect to github, and I have many restrictions in my proxy, restrictions that I cannot solve because that is not up to me. So my point is if there is any way to solve this problem whether is updating the mysql dependency to another version that works with cb 0.8.7 and PostgreSQL 9.x at the same time or getting another version of the postgreSQL, I think the stable version of mysql that comes with cb 0.8.7 works only with postgreSQL 8.x, but that is an old version of it. I would rather to have the stable version of cb 0.8.9 that I think it will work with postgreSQL 9.2 but unfortunately I cannot get it, if someone would be so kind of get it for me with the entire cb 0.8.9 or some master stable version that supports postgreSQL 9.x with all it well functional deps (rebar get-deps) I will appreciate that. I accept any solution. Thanks in advantage, Best regards, Ivan. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.emz Type: application/octet-stream Size: 24192 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 27550 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oledata.mso Type: application/octet-stream Size: 26735 bytes Desc: not available URL: From moxford@REDACTED Wed Feb 12 07:27:14 2014 From: moxford@REDACTED (Mike Oxford) Date: Tue, 11 Feb 2014 22:27:14 -0800 Subject: [erlang-questions] Bitstring question Message-ID: D = <<33:6>> <<33:6>> I want to convert that 6 bit value (33) into a numeric value. Why does <<0:2, D>> not work? Why does <<0:2/bits, D:6/bits>> not work? Why does <> not work? Thanks in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Wed Feb 12 07:32:04 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Wed, 12 Feb 2014 08:32:04 +0200 Subject: [erlang-questions] Bitstring question In-Reply-To: References: Message-ID: <30BDC5A1-B0D0-474E-8BE3-1B9C97F878D0@gmail.com> Hello, Please see comments inline. Best Regards, Dmitry >-|-|-(*> > On 12.2.2014, at 8.27, Mike Oxford wrote: > > D = <<33:6>> > <<33:6>> D is length 6 bit > > I want to convert that 6 bit value (33) into a numeric value. > > Why does <<0:2, D>> not work? Type and size is not specified > Why does <<0:2/bits, D:6/bits>> not work? Expected size is 8 bits but your bit string is 6 > Why does <> not work? Integer is 32bit > > Thanks in advance! > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From moxford@REDACTED Wed Feb 12 07:36:59 2014 From: moxford@REDACTED (Mike Oxford) Date: Tue, 11 Feb 2014 22:36:59 -0800 Subject: [erlang-questions] Bitstring question In-Reply-To: <30BDC5A1-B0D0-474E-8BE3-1B9C97F878D0@gmail.com> References: <30BDC5A1-B0D0-474E-8BE3-1B9C97F878D0@gmail.com> Message-ID: << 0:2, D >> should concat the two. Erlang knows what D is. <<0:2/bits, D:6/bits>> should construct a single 8-bit value. <> should (IMO) be valid because the value (33) is within the range of /integer How would you convert it back out to 33? On Tue, Feb 11, 2014 at 10:32 PM, Dmitry Kolesnikov wrote: > Hello, > > Please see comments inline. > > Best Regards, > Dmitry >-|-|-(*> > > > > On 12.2.2014, at 8.27, Mike Oxford wrote: > > > > D = <<33:6>> > > <<33:6>> > D is length 6 bit > > > > I want to convert that 6 bit value (33) into a numeric value. > > > > Why does <<0:2, D>> not work? > Type and size is not specified > > Why does <<0:2/bits, D:6/bits>> not work? > Expected size is 8 bits but your bit string is 6 > > Why does <> not work? > Integer is 32bit > > > > > 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 k.petrauskas@REDACTED Wed Feb 12 07:41:29 2014 From: k.petrauskas@REDACTED (Karolis Petrauskas) Date: Wed, 12 Feb 2014 08:41:29 +0200 Subject: [erlang-questions] Bitstring question In-Reply-To: References: <30BDC5A1-B0D0-474E-8BE3-1B9C97F878D0@gmail.com> Message-ID: 1> D = <<33:6>>. <<33:6>> 3> E = <<0:2, D/bits>>. <<"!">> 5> <> = E. <<"!">> 6> F. 33 Karolis On Wed, Feb 12, 2014 at 8:36 AM, Mike Oxford wrote: > << 0:2, D >> should concat the two. Erlang knows what D is. > <<0:2/bits, D:6/bits>> should construct a single 8-bit value. > <> should (IMO) be valid because the value (33) is within the > range of /integer > > How would you convert it back out to 33? > > > On Tue, Feb 11, 2014 at 10:32 PM, Dmitry Kolesnikov > wrote: >> >> Hello, >> >> Please see comments inline. >> >> Best Regards, >> Dmitry >-|-|-(*> >> >> >> > On 12.2.2014, at 8.27, Mike Oxford wrote: >> > >> > D = <<33:6>> >> > <<33:6>> >> D is length 6 bit >> > >> > I want to convert that 6 bit value (33) into a numeric value. >> > >> > Why does <<0:2, D>> not work? >> Type and size is not specified >> > Why does <<0:2/bits, D:6/bits>> not work? >> Expected size is 8 bits but your bit string is 6 >> > Why does <> not work? >> Integer is 32bit >> >> > >> > Thanks in advance! >> > >> > >> > >> > _______________________________________________ >> > 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 moxford@REDACTED Wed Feb 12 08:01:44 2014 From: moxford@REDACTED (Mike Oxford) Date: Tue, 11 Feb 2014 23:01:44 -0800 Subject: [erlang-questions] Bitstring question In-Reply-To: References: <30BDC5A1-B0D0-474E-8BE3-1B9C97F878D0@gmail.com> Message-ID: Thank you! But ... 64> <<0:2*/bits*, D/bits>>. ** exception error: bad argument 65> <<0:2, D/bits>>. <<"!">> ?? Why does explicitly qualifying the 0:2 with /bits cause it to fail? On Tue, Feb 11, 2014 at 10:41 PM, Karolis Petrauskas wrote: > 1> D = <<33:6>>. > <<33:6>> > 3> E = <<0:2, D/bits>>. > <<"!">> > 5> <> = E. > <<"!">> > 6> F. > 33 > > Karolis > > On Wed, Feb 12, 2014 at 8:36 AM, Mike Oxford wrote: > > << 0:2, D >> should concat the two. Erlang knows what D is. > > <<0:2/bits, D:6/bits>> should construct a single 8-bit value. > > <> should (IMO) be valid because the value (33) is within the > > range of /integer > > > > How would you convert it back out to 33? > > > > > > On Tue, Feb 11, 2014 at 10:32 PM, Dmitry Kolesnikov < > dmkolesnikov@REDACTED> > > wrote: > >> > >> Hello, > >> > >> Please see comments inline. > >> > >> Best Regards, > >> Dmitry >-|-|-(*> > >> > >> > >> > On 12.2.2014, at 8.27, Mike Oxford wrote: > >> > > >> > D = <<33:6>> > >> > <<33:6>> > >> D is length 6 bit > >> > > >> > I want to convert that 6 bit value (33) into a numeric value. > >> > > >> > Why does <<0:2, D>> not work? > >> Type and size is not specified > >> > Why does <<0:2/bits, D:6/bits>> not work? > >> Expected size is 8 bits but your bit string is 6 > >> > Why does <> not work? > >> Integer is 32bit > >> > >> > > >> > Thanks in advance! > >> > > >> > > >> > > >> > _______________________________________________ > >> > 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 Wed Feb 12 08:05:52 2014 From: k.petrauskas@REDACTED (Karolis Petrauskas) Date: Wed, 12 Feb 2014 09:05:52 +0200 Subject: [erlang-questions] Bitstring question In-Reply-To: References: <30BDC5A1-B0D0-474E-8BE3-1B9C97F878D0@gmail.com> Message-ID: The "/bits" says, that the argument is bitstring. The "0:2" says, its an integer who's size is 2 bits. And "0" here is an integer, not a bitstring. Karolis On Wed, Feb 12, 2014 at 9:01 AM, Mike Oxford wrote: > Thank you! > But ... > > 64> <<0:2/bits, D/bits>>. > ** exception error: bad argument > 65> <<0:2, D/bits>>. > <<"!">> > > ?? Why does explicitly qualifying the 0:2 with /bits cause it to fail? > > > > > > > On Tue, Feb 11, 2014 at 10:41 PM, Karolis Petrauskas > wrote: >> >> 1> D = <<33:6>>. >> <<33:6>> >> 3> E = <<0:2, D/bits>>. >> <<"!">> >> 5> <> = E. >> <<"!">> >> 6> F. >> 33 >> >> Karolis >> >> On Wed, Feb 12, 2014 at 8:36 AM, Mike Oxford wrote: >> > << 0:2, D >> should concat the two. Erlang knows what D is. >> > <<0:2/bits, D:6/bits>> should construct a single 8-bit value. >> > <> should (IMO) be valid because the value (33) is within the >> > range of /integer >> > >> > How would you convert it back out to 33? >> > >> > >> > On Tue, Feb 11, 2014 at 10:32 PM, Dmitry Kolesnikov >> > >> > wrote: >> >> >> >> Hello, >> >> >> >> Please see comments inline. >> >> >> >> Best Regards, >> >> Dmitry >-|-|-(*> >> >> >> >> >> >> > On 12.2.2014, at 8.27, Mike Oxford wrote: >> >> > >> >> > D = <<33:6>> >> >> > <<33:6>> >> >> D is length 6 bit >> >> > >> >> > I want to convert that 6 bit value (33) into a numeric value. >> >> > >> >> > Why does <<0:2, D>> not work? >> >> Type and size is not specified >> >> > Why does <<0:2/bits, D:6/bits>> not work? >> >> Expected size is 8 bits but your bit string is 6 >> >> > Why does <> not work? >> >> Integer is 32bit >> >> >> >> > >> >> > Thanks in advance! >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > 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 moxford@REDACTED Wed Feb 12 08:09:46 2014 From: moxford@REDACTED (Mike Oxford) Date: Tue, 11 Feb 2014 23:09:46 -0800 Subject: [erlang-questions] Bitstring question In-Reply-To: References: <30BDC5A1-B0D0-474E-8BE3-1B9C97F878D0@gmail.com> Message-ID: interesting. So why doesn't bitstring concatenation work in this case? Should it? On Tue, Feb 11, 2014 at 11:05 PM, Karolis Petrauskas wrote: > The "/bits" says, that the argument is bitstring. > The "0:2" says, its an integer who's size is 2 bits. And "0" here is > an integer, not a bitstring. > > Karolis > > On Wed, Feb 12, 2014 at 9:01 AM, Mike Oxford wrote: > > Thank you! > > But ... > > > > 64> <<0:2/bits, D/bits>>. > > ** exception error: bad argument > > 65> <<0:2, D/bits>>. > > <<"!">> > > > > ?? Why does explicitly qualifying the 0:2 with /bits cause it to fail? > > > > > > > > > > > > > > On Tue, Feb 11, 2014 at 10:41 PM, Karolis Petrauskas > > wrote: > >> > >> 1> D = <<33:6>>. > >> <<33:6>> > >> 3> E = <<0:2, D/bits>>. > >> <<"!">> > >> 5> <> = E. > >> <<"!">> > >> 6> F. > >> 33 > >> > >> Karolis > >> > >> On Wed, Feb 12, 2014 at 8:36 AM, Mike Oxford wrote: > >> > << 0:2, D >> should concat the two. Erlang knows what D is. > >> > <<0:2/bits, D:6/bits>> should construct a single 8-bit value. > >> > <> should (IMO) be valid because the value (33) is within > the > >> > range of /integer > >> > > >> > How would you convert it back out to 33? > >> > > >> > > >> > On Tue, Feb 11, 2014 at 10:32 PM, Dmitry Kolesnikov > >> > > >> > wrote: > >> >> > >> >> Hello, > >> >> > >> >> Please see comments inline. > >> >> > >> >> Best Regards, > >> >> Dmitry >-|-|-(*> > >> >> > >> >> > >> >> > On 12.2.2014, at 8.27, Mike Oxford wrote: > >> >> > > >> >> > D = <<33:6>> > >> >> > <<33:6>> > >> >> D is length 6 bit > >> >> > > >> >> > I want to convert that 6 bit value (33) into a numeric value. > >> >> > > >> >> > Why does <<0:2, D>> not work? > >> >> Type and size is not specified > >> >> > Why does <<0:2/bits, D:6/bits>> not work? > >> >> Expected size is 8 bits but your bit string is 6 > >> >> > Why does <> not work? > >> >> Integer is 32bit > >> >> > >> >> > > >> >> > Thanks in advance! > >> >> > > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > 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 steve@REDACTED Wed Feb 12 08:16:33 2014 From: steve@REDACTED (Steve Strong) Date: Wed, 12 Feb 2014 08:16:33 +0100 Subject: [erlang-questions] Bitstring question In-Reply-To: References: Message-ID: <852E53BDDE4644F18B4676D1EF42A5E3@srstrong.com> I?d use: Eshell V5.10.3 (abort with ^G) 1> D = <<33:6>>. <<33:6>> 2> <> = D. <<33:6>> 3> E. 33 4> -- Steve Strong Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Wednesday, 12 February 2014 at 07:27, Mike Oxford wrote: > D = <<33:6>> > <<33:6>> > > I want to convert that 6 bit value (33) into a numeric value. > > Why does <<0:2, D>> not work? > Why does <<0:2/bits, D:6/bits>> not work? > Why does <> not work? > > Thanks in advance! > > > > _______________________________________________ > 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 k.petrauskas@REDACTED Wed Feb 12 08:16:58 2014 From: k.petrauskas@REDACTED (Karolis Petrauskas) Date: Wed, 12 Feb 2014 09:16:58 +0200 Subject: [erlang-questions] Bitstring question In-Reply-To: References: <30BDC5A1-B0D0-474E-8BE3-1B9C97F878D0@gmail.com> Message-ID: Bitstring concatenation would work, if both parts would be bitstrings, e.g. A = <<1:4>>, B = <<0:4>>, C = <>. In your case you tried to concatenate an integer with a bitstring. Nice description of bit syntax can be found in LYSE (http://learnyousomeerlang.com/starting-out-for-real#bit-syntax). I hope it helped :) Karolis On Wed, Feb 12, 2014 at 9:09 AM, Mike Oxford wrote: > interesting. So why doesn't bitstring concatenation work in this case? > Should it? > > > On Tue, Feb 11, 2014 at 11:05 PM, Karolis Petrauskas > wrote: >> >> The "/bits" says, that the argument is bitstring. >> The "0:2" says, its an integer who's size is 2 bits. And "0" here is >> an integer, not a bitstring. >> >> Karolis >> >> On Wed, Feb 12, 2014 at 9:01 AM, Mike Oxford wrote: >> > Thank you! >> > But ... >> > >> > 64> <<0:2/bits, D/bits>>. >> > ** exception error: bad argument >> > 65> <<0:2, D/bits>>. >> > <<"!">> >> > >> > ?? Why does explicitly qualifying the 0:2 with /bits cause it to fail? >> > >> > >> > >> > >> > >> > >> > On Tue, Feb 11, 2014 at 10:41 PM, Karolis Petrauskas >> > wrote: >> >> >> >> 1> D = <<33:6>>. >> >> <<33:6>> >> >> 3> E = <<0:2, D/bits>>. >> >> <<"!">> >> >> 5> <> = E. >> >> <<"!">> >> >> 6> F. >> >> 33 >> >> >> >> Karolis >> >> >> >> On Wed, Feb 12, 2014 at 8:36 AM, Mike Oxford wrote: >> >> > << 0:2, D >> should concat the two. Erlang knows what D is. >> >> > <<0:2/bits, D:6/bits>> should construct a single 8-bit value. >> >> > <> should (IMO) be valid because the value (33) is within >> >> > the >> >> > range of /integer >> >> > >> >> > How would you convert it back out to 33? >> >> > >> >> > >> >> > On Tue, Feb 11, 2014 at 10:32 PM, Dmitry Kolesnikov >> >> > >> >> > wrote: >> >> >> >> >> >> Hello, >> >> >> >> >> >> Please see comments inline. >> >> >> >> >> >> Best Regards, >> >> >> Dmitry >-|-|-(*> >> >> >> >> >> >> >> >> >> > On 12.2.2014, at 8.27, Mike Oxford wrote: >> >> >> > >> >> >> > D = <<33:6>> >> >> >> > <<33:6>> >> >> >> D is length 6 bit >> >> >> > >> >> >> > I want to convert that 6 bit value (33) into a numeric value. >> >> >> > >> >> >> > Why does <<0:2, D>> not work? >> >> >> Type and size is not specified >> >> >> > Why does <<0:2/bits, D:6/bits>> not work? >> >> >> Expected size is 8 bits but your bit string is 6 >> >> >> > Why does <> not work? >> >> >> Integer is 32bit >> >> >> >> >> >> > >> >> >> > Thanks in advance! >> >> >> > >> >> >> > >> >> >> > >> >> >> > _______________________________________________ >> >> >> > erlang-questions mailing list >> >> >> > erlang-questions@REDACTED >> >> >> > http://erlang.org/mailman/listinfo/erlang-questions >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > erlang-questions mailing list >> >> > erlang-questions@REDACTED >> >> > http://erlang.org/mailman/listinfo/erlang-questions >> >> > >> > >> > > > From bengt.kleberg@REDACTED Wed Feb 12 08:57:17 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Wed, 12 Feb 2014 08:57:17 +0100 Subject: [erlang-questions] Can epp_dodge:parse accept a ram_file? In-Reply-To: References: <1392098908.5096.4.camel@sekic1152.release> <1392106510.5096.29.camel@sekic1152.release> Message-ID: <1392191837.4873.9.camel@sekic1152.release> Now available at https://github.com/ebengt/erlang_string_io On Tue, 2014-02-11 at 20:57 +0800, Leo Liu wrote: > On 2014-02-11 16:15 +0800, Bengt Kleberg wrote: > > Ages ago I did a string_io module that allowed epp_dodger:parse/1 to > > work on strings. Would that be of interest? > > Yes, where can I find it? > > Thanks, > Leo > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From andreas@REDACTED Wed Feb 12 09:08:46 2014 From: andreas@REDACTED (Andreas Schumacher) Date: Wed, 12 Feb 2014 09:08:46 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <58912684E2630B45963406CF7D8C52581C3473C6@ESESSMB103.ericsson.se> References: <52F4C173.8050408@erlang.org> <1391790979.26271.YahooMailNeo@web140106.mail.bf1.yahoo.com> <49EC93AB-69A4-49AB-A2C0-4DA9F418E3F6@gmail.com> <58912684E2630B45963406CF7D8C52581C3473C6@ESESSMB103.ericsson.se> Message-ID: <52FB2C0E.90008@erlang.org> From the versioning clarification mail that I sent on behalf of the OTP team to the list on February 7: "The new version scheme is *not* semantic versioning; although, it has been inspired by it. We do not want to use semantic versioning (as defined by http://semver.org/) out of the box since it does not fit our needs." Andreas Schumacher Erlang/OTP, Ericsson AB > > -----Original Message----- > From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Anthony Ramine > Sent: den 12 februari 2014 02:48 > To: Rickard Green > Cc: erlang-questions@REDACTED > Subject: Re: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. > > So OTP won't follow semantic versioning, right? > > Just seeking confirmation about semver. > > Regards, > > -- > Anthony Ramine > > Le 12 f?vr. 2014 ? 00:43, Rickard Green a ?crit : > >> As of OTP 17 we drop this patch level number sequence and start using >> one set of patch level numbers per release. The patch level is not >> expressed as an integer as it used to be, but instead as a version >> number ..[. ...], for example, 17.0.1. This way the patch >> level gives you a bit more information. You can for example see >> directly which OTP release it applies to. This patch level version >> number also replace the - tar-ball naming scheme. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From sdl.web@REDACTED Wed Feb 12 10:23:13 2014 From: sdl.web@REDACTED (Leo Liu) Date: Wed, 12 Feb 2014 17:23:13 +0800 Subject: [erlang-questions] Can epp_dodge:parse accept a ram_file? References: <1392098908.5096.4.camel@sekic1152.release> <1392106510.5096.29.camel@sekic1152.release> <1392191837.4873.9.camel@sekic1152.release> Message-ID: On 2014-02-12 15:57 +0800, Bengt Kleberg wrote: > Now available at https://github.com/ebengt/erlang_string_io Thank you. Leo From moxford@REDACTED Wed Feb 12 10:48:08 2014 From: moxford@REDACTED (Mike Oxford) Date: Wed, 12 Feb 2014 01:48:08 -0800 Subject: [erlang-questions] Binary matching partials Message-ID: decode(Charset, <>, Acc) Match incoming stuff, 3 bytes at a time and put the remainder in T. No problem. If I get 5 bytes it has issues because it's not on the 3-byte boundary. Fine ... except ... I've tried... 1) Match less params...try <> then <>, <>, <> and so on. 2) Match against zeros <> 3) Match against various combinations of bit-widths and remainder/tails It seems as if it must match exactly, yet matching against the varying levels of parameters doesn't seem to work. I couldn't find anything on Google about this particular matching case. Thanks in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Wed Feb 12 10:59:51 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 12 Feb 2014 10:59:51 +0100 Subject: [erlang-questions] Binary matching partials In-Reply-To: References: Message-ID: Hi! I think that if your parameter is a binary, then whan you match something that isn't combining to an integer amount of bytes you have to add a bitstring tail. 2> <> = <<8>>. ** exception error: no match of right hand side value <<"\b">> 3> <> = <<8>>. ** exception error: no match of right hand side value <<"\b">> 4> <> = <<8>>. <<"\b">> regards, Vlad On Wed, Feb 12, 2014 at 10:48 AM, Mike Oxford wrote: > decode(Charset, <>, Acc) > > Match incoming stuff, 3 bytes at a time and put the remainder in T. No > problem. > > If I get 5 bytes it has issues because it's not on the 3-byte boundary. > Fine ... except ... > > I've tried... > > 1) Match less params...try <> then <>, <>, > <> and so on. > 2) Match against zeros <> > 3) Match against various combinations of bit-widths and remainder/tails > > It seems as if it must match exactly, yet matching against the varying > levels of parameters doesn't seem to work. > > I couldn't find anything on Google about this particular matching case. > > Thanks in advance! > > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From moxford@REDACTED Wed Feb 12 11:13:50 2014 From: moxford@REDACTED (Mike Oxford) Date: Wed, 12 Feb 2014 02:13:50 -0800 Subject: [erlang-questions] Binary matching partials In-Reply-To: References: Message-ID: Awesome... it wouldn't let me match against a value but your way with the _/bits works great. Thanks! On Wed, Feb 12, 2014 at 1:59 AM, Vlad Dumitrescu wrote: > Hi! > > I think that if your parameter is a binary, then whan you match > something that isn't combining to an integer amount of bytes you have > to add a bitstring tail. > > 2> <> = <<8>>. > ** exception error: no match of right hand side value <<"\b">> > 3> <> = <<8>>. > ** exception error: no match of right hand side value <<"\b">> > 4> <> = <<8>>. > <<"\b">> > > regards, > Vlad > > > On Wed, Feb 12, 2014 at 10:48 AM, Mike Oxford wrote: > > decode(Charset, <>, Acc) > > > > Match incoming stuff, 3 bytes at a time and put the remainder in T. No > > problem. > > > > If I get 5 bytes it has issues because it's not on the 3-byte boundary. > > Fine ... except ... > > > > I've tried... > > > > 1) Match less params...try <> then <>, <>, > > <> and so on. > > 2) Match against zeros <> > > 3) Match against various combinations of bit-widths and remainder/tails > > > > It seems as if it must match exactly, yet matching against the varying > > levels of parameters doesn't seem to work. > > > > I couldn't find anything on Google about this particular matching case. > > > > 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 ph@REDACTED Wed Feb 12 12:19:39 2014 From: ph@REDACTED (Pieter Hintjens) Date: Wed, 12 Feb 2014 12:19:39 +0100 Subject: [erlang-questions] 0MQ libraries In-Reply-To: <148425023.96524.1392045156883.JavaMail.zimbra@tpip.net> References: <148425023.96524.1392045156883.JavaMail.zimbra@tpip.net> Message-ID: gen_zmq => zeromq/ezmq, now an official project of the ZeroMQ community. https://github.com/zeromq/ezmq Nice work by Andreas! On Mon, Feb 10, 2014 at 4:12 PM, Andreas Schultz wrote: > Hi Joe, > > gen_zmq is pure Erlang and talks to libzmq 2.0 implementations. > Since newer limzmq versions are backward compatible, using it to > talk to them should work. > > In case the gen_socket dependency worries you, that can easily be > removed (only used for UNIX sockets). In fact I plan to remove that > soonish. > > There is also rebar support pending in a review: > > https://github.com/RoadRunnr/gen_zmq/pull/1 > > Andreas > > ----- Original Message ----- >> >> >> >> On Sat, Feb 8, 2014 at 7:49 PM, Serge Aleynikov < serge@REDACTED > >> wrote: >> >> >> >> Just to add a piece of history - I was an author of the original driver-based >> implementation of the Erlang ZMQ binding ( https://github.com/zeromq/erlzmq >> ), which got more or less obsolete after Yurii Rashkovskii implemented his >> NIF-based version ( https://github.com/zeromq/erlzmq2 ). >> >> Concerning your question, I haven't had a use for this project for a while, >> but if there is anyone wishing to join the project and bring it up to date >> that would be great. Though I agree that a pure-Erlang wire-level >> implementation would be of greater interest. >> >> I'm only interested in the pure erlang solution. NIFs worry me. They break >> the guarantees, they muck >> up the scheduler and so on. They should only be used when you've tried very >> very very vary hard >> not to use them. >> >> In the problem I want to solve I don't expect communication to be a >> bottleneck. >> >> I'd like a 100% correct Erlang reference implementation of 0MQ. This (if >> done) might have the interesting >> side effect that it could be used (say with quick check) test the >> C-implementations of 0MQ. >> >> Cheers >> >> /Joe >> >> >> >> >> Serge >> >> >> On Thu, Jan 30, 2014 at 4:13 PM, Joe Armstrong < erlang@REDACTED > wrote: >> >> >> >> Is anybody working on upgrading the 0MQ libraries for erlang to >> the latest version of 0QM. >> >> /Joe >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > -- > -- > Dipl. Inform. > Andreas Schultz > > email: as@REDACTED > phone: +49-391-819099-224 > mobil: +49-170-2226073 > > ------------------- enabling your networks ------------------- > > Travelping GmbH phone: +49-391-819099229 > Roentgenstr. 13 fax: +49-391-819099299 > D-39108 Magdeburg email: info@REDACTED > GERMANY web: http://www.travelping.com > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 > -------------------------------------------------------------- > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From michal.piotrowski@REDACTED Wed Feb 12 13:19:24 2014 From: michal.piotrowski@REDACTED (Michal Piotrowski) Date: Wed, 12 Feb 2014 13:19:24 +0100 Subject: [erlang-questions] Mongoose IM Documentation In-Reply-To: References: Message-ID: <88790ACE-DADD-45D1-97F0-2D19BA07E590@erlang-solutions.com> Hi Kelly, Sorry for such a late response. On our github we have an introduction to hooks. Take a look at: https://github.com/esl/MongooseIM/wiki/hooks-and-handlers. You should find there anything you need regarding hooks in MongooseIM, I think. If you have further questions please add my email to CC as I?m not checking the mailing list very often. You can also send email to ejabberd@REDACTED Best regards Michal Piotrowski michal.piotrowski@REDACTED On 07 Feb 2014, at 22:43, Kelly Wong wrote: > Hi Michal, > > Thanks for the link. I'm trying to figure out what hooks I can set and when they're called. The end goal is to write a plugin that can send an Apple notification service message to a user who is not online. I was thinking I could write a plugin that intercepts messages to offline users. Is that the right way to go about things? > > Thanks, > Kelly Wong > > > On Wed, Feb 5, 2014 at 11:18 PM, Michal Piotrowski wrote: > Hello Kelly, > > There are some examples on our github: https://github.com/esl/MongooseIM. > The default installation of MongooseIM works with mnesia as a database. > What exactly do you need to know? > > BTW, the config file is in most cases compatible with the one in ejabberd 2.1.x. > > Best regards > Michal Piotrowski > michal.piotrowski@REDACTED > > > On 05 Feb 2014, at 03:10, Kelly Wong wrote: > >> Hello, >> >> I'm trying to setup Mongoose IM, but for the life of me can't find any documentation for it. Can anyone point me in the right direction? >> >> Thanks, >> Kelly Wong >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Wed Feb 12 15:04:53 2014 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 12 Feb 2014 15:04:53 +0100 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: <71D26997-BBC2-41F7-BCAB-592E45D28609@cs.otago.ac.nz> Message-ID: On Tue, Feb 11, 2014 at 11:17 PM, kraythe . wrote: > Richard, > > I appreciate your response and the effort you put into it. And I learned a > lot from it. In this case I am learning the thinking mode of Erlang as it > is different a bit from what I do to pay the bills. I have yet to get into > list comprehensions in Erlang so that is on my ... well ... list. :) You > have provided valuable insight. > > The main focus of the method is if I have a number of objects with a > vector position in a simulation and I want to exclude considerations of > interactions with objects outside the sphere of influence, I have to > quickly discard the candidates that are not inside the sphere of influence. > I originally thought to write a method that did just the vector math > because I was wondering if that kind of math would have to ultimately be > turned into something native. Even a delay of 1 second would be fatal to > the simulation. > Isn't this what octrees are for? - You'd have to use a "cube of influence" - but as far as I know octrees can be used to rapidly partition objects in a 3-d space Take a look at this http://en.wikipedia.org/wiki/Octree /Joe > > The algorithm, however, shouldnt have to consider all candidates as the > world is broken into spacial segments (cubes) such that the sphere could > intersect with at maximum 8 neighboring cubes so I would only need to > consider simulation objects within those 8 cube spaces when determining > which elements were actually within the sphere of influence. I have been > trying to devise a method of reducing the candidate set even further and am > still working on that. Perhaps edge detection and cube boundary > calculations but I don't want to spend more math doing that then I would > simply excluding objects vector by vector. > > Anyway thanks for the reply, definitely some information that I can use in > there. > > *Robert Simmons Jr. MSc.* > > On Sun, Feb 9, 2014 at 10:59 PM, Richard A. O'Keefe wrote: > >> >> On 8/02/2014, at 4:53 AM, kraythe . wrote: >> > Anyway back to the subject at hand. The algorithm is set but now I am >> at another quandary Lets say these vectors represent a position in space of >> particular objects in a simulation. The process of culling the vectors >> based on the sphere is entirely a vector problem but what the user calling >> cull/3 really needs to know is which objects are not culled from the list, >> not just which vectors are not culled. Now in Java I could do a number of >> things if I wanted to keep the cull algorithm as it is. I could return the >> list of integers containing the original indexes of the vectors in the list >> that were culled and use that to filter out which objects need to be >> considered for the simulation step. >> >> The word "cull" really grates. >> >> And all those negations *really* confused me *all over again*. >> I wrote a lengthy and helpful description of how to get the >> points that were accepted and the points that were rejected >> as two lists, because that was the only way I could interpret >> your question to make sense in Erlang. But on repeated re-reading >> it became clear that you were asking for something else. >> >> There is no such thing in Erlang as object identity. >> The distinction you are drawing between the "points" and the >> "objects" simply doesn't exist. >> >> It so happens that if you use a list comprehension like >> [P || P <- Points, some_predicate(P)] >> the elements of the result *will* be (references to) the same >> implementation-level webs of chunks of memory that were in the >> original list, not copies. But nothing other than performance >> depends on this. >> >> A list of integers such as you ask for could be obtained, but it >> would be very little use to you, because Erlang lists are *LINKED >> LISTS*, not *INDEXED ARRAYS*. Finding the nth element of a list >> takes O(n) time, and that could not be changed without making >> lists much less useful. >> >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvi@REDACTED Wed Feb 12 17:55:58 2014 From: cvi@REDACTED (=?ISO-8859-1?Q?Christoffer_Vikstr=F6m?=) Date: Wed, 12 Feb 2014 17:55:58 +0100 Subject: [erlang-questions] Question on "selective receive" In-Reply-To: <000001cf1679$ee7199f0$cb54cdd0$@com> References: <003c01cf1501$29bc9890$7d35c9b0$@com> <000001cf1679$ee7199f0$cb54cdd0$@com> Message-ID: I think the "zero to inifinity" statement might need some clarification: The timeout is a 32-bit integer and if you try to set it higher it will fail with a bad receive timeout value. receive after 1 bsl 32 -1 -> ok end. will work. receive after 1 bsl 32 -> ok end. will not. Cheers! On Tue, Jan 21, 2014 at 8:25 AM, Avinash Dhumane < avinash_dhumane@REDACTED> wrote: > Just thought of sharing the information that Joe's book (pp 143-144, > under section "Receive with Timeout Value of Zero/Infinity") answers this > question. I had gone over these paragraphs several times in the past, but > it is only after confronted with a real life situation where these > constructs require application of mind that these small paragraphs > illumined their real meaning. > > > > Oh, Erlang - you're beauty!! > > > > *From:* erlang-questions-bounces@REDACTED [mailto: > erlang-questions-bounces@REDACTED] *On Behalf Of *Avinash Dhumane > *Sent:* 19 January 2014 15:58 > *To:* erlang-questions@REDACTED > *Subject:* [erlang-questions] Question on "selective receive" > > > > Can the timeout clause not have a guard too? > > > > If it can, what are the semantics of it? I mean, if the timeout occurs but > guard evaluates to false, what happens to receive? Does it continue to > block? > > > > If it cannot, why? > > > > Thanks > > Avinash > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kraythe@REDACTED Wed Feb 12 18:56:06 2014 From: kraythe@REDACTED (kraythe .) Date: Wed, 12 Feb 2014 11:56:06 -0600 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: <71D26997-BBC2-41F7-BCAB-592E45D28609@cs.otago.ac.nz> Message-ID: Ahh octtree is good if the objects are static and if your goal is to find an object in a large space. It is a reductive search algorithm. In this case all of the objects are in motion and I want to know my neigbors, not find object X in the space. Therefore a different approach is called for. Imagine thousands of particles flowing around in a medium and needing to determine their interactions based on vicinity, momentum, etc. From frame to frame the state of your tree would change and the cost would make the simulation impossible to render in realtime. Instead if the world is divided up into cubes that are larger than the sphere of influence and each cube knows about its neighbors then I can easily get a candidate list as long as the particles update the cube entity that they are in. As they move into a cube, they inform the cube that they have entered and as they leave the cube, they inform it of their exit. If I know the cube I am in, and I know my sphere of influence overlaps into another cube, I can immediately exclude all candidate not in either cube. If the cube has references to its neigbors, the solution is easy. 1) Determine if I overlap sphere into neighbors (simple math problem of the radius of my sphere and the boinds of the cube. 2) For all cubes I overlap, get members. 3) For all members determine which are inside my sphere. 4) Interract with elements in my sphere. Incidentally my current version of the code, Thanks to Richard's input, is: %% Subtract the second vector from the first subtract({X1, Y1, Z1}, {X2, Y2, Z2}) -> {(X1 - X2), (Y1 - Y2), (Z1 - Z2)}. %% Compute if the vector T is in the sphere with center at vector C and with radius R. in_sphere(C, R, T) -> {Dx, Dy, Dz} = subtract(C, T), Dx * Dx + Dy * Dy + Dz * Dz =< R * R. %% Calculate all entities in the sphere defined at center vector C with radius R and using Fpos which will extract the location to check from %% each entity in the list. The method Fpos must return a three tuple vector and take the entity as an argument. entities_in_sphere(C ,R, Entities, Fpos) -> [E || E <- Entities, in_sphere(C, R, Fpos(E))]. It also appears to run quite fast according to preliminary timer:tc tests but of course there is need for more massive testing of load. I may still have to use the type optimization richard pointed out. I am debating staying with integer arithmetic also. *Robert Simmons Jr. MSc. * On Wed, Feb 12, 2014 at 8:04 AM, Joe Armstrong wrote: > > > > On Tue, Feb 11, 2014 at 11:17 PM, kraythe . wrote: > >> Richard, >> >> I appreciate your response and the effort you put into it. And I learned >> a lot from it. In this case I am learning the thinking mode of Erlang as it >> is different a bit from what I do to pay the bills. I have yet to get into >> list comprehensions in Erlang so that is on my ... well ... list. :) You >> have provided valuable insight. >> >> The main focus of the method is if I have a number of objects with a >> vector position in a simulation and I want to exclude considerations of >> interactions with objects outside the sphere of influence, I have to >> quickly discard the candidates that are not inside the sphere of influence. >> I originally thought to write a method that did just the vector math >> because I was wondering if that kind of math would have to ultimately be >> turned into something native. Even a delay of 1 second would be fatal to >> the simulation. >> > > Isn't this what octrees are for? - You'd have to use a "cube of influence" > - but as far as I know octrees > can be used to rapidly partition objects in a 3-d space > > Take a look at this http://en.wikipedia.org/wiki/Octree > > /Joe > > >> >> The algorithm, however, shouldnt have to consider all candidates as the >> world is broken into spacial segments (cubes) such that the sphere could >> intersect with at maximum 8 neighboring cubes so I would only need to >> consider simulation objects within those 8 cube spaces when determining >> which elements were actually within the sphere of influence. I have been >> trying to devise a method of reducing the candidate set even further and am >> still working on that. Perhaps edge detection and cube boundary >> calculations but I don't want to spend more math doing that then I would >> simply excluding objects vector by vector. >> >> Anyway thanks for the reply, definitely some information that I can use >> in there. >> >> *Robert Simmons Jr. MSc.* >> >> On Sun, Feb 9, 2014 at 10:59 PM, Richard A. O'Keefe wrote: >> >>> >>> On 8/02/2014, at 4:53 AM, kraythe . wrote: >>> > Anyway back to the subject at hand. The algorithm is set but now I am >>> at another quandary Lets say these vectors represent a position in space of >>> particular objects in a simulation. The process of culling the vectors >>> based on the sphere is entirely a vector problem but what the user calling >>> cull/3 really needs to know is which objects are not culled from the list, >>> not just which vectors are not culled. Now in Java I could do a number of >>> things if I wanted to keep the cull algorithm as it is. I could return the >>> list of integers containing the original indexes of the vectors in the list >>> that were culled and use that to filter out which objects need to be >>> considered for the simulation step. >>> >>> The word "cull" really grates. >>> >>> And all those negations *really* confused me *all over again*. >>> I wrote a lengthy and helpful description of how to get the >>> points that were accepted and the points that were rejected >>> as two lists, because that was the only way I could interpret >>> your question to make sense in Erlang. But on repeated re-reading >>> it became clear that you were asking for something else. >>> >>> There is no such thing in Erlang as object identity. >>> The distinction you are drawing between the "points" and the >>> "objects" simply doesn't exist. >>> >>> It so happens that if you use a list comprehension like >>> [P || P <- Points, some_predicate(P)] >>> the elements of the result *will* be (references to) the same >>> implementation-level webs of chunks of memory that were in the >>> original list, not copies. But nothing other than performance >>> depends on this. >>> >>> A list of integers such as you ask for could be obtained, but it >>> would be very little use to you, because Erlang lists are *LINKED >>> LISTS*, not *INDEXED ARRAYS*. Finding the nth element of a list >>> takes O(n) time, and that could not be changed without making >>> lists much less useful. >>> >>> >>> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Wed Feb 12 20:42:07 2014 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 12 Feb 2014 20:42:07 +0100 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: <71D26997-BBC2-41F7-BCAB-592E45D28609@cs.otago.ac.nz> Message-ID: Interesting problem. How to you map your problem onto a process structure? Method 1 - let the process manage regions of space How about starting with 1000 parallel processes. Each one managing a point in a 10x10x10 grid in 3-d space. In pass one you compute which process "owns" each particle. Thereafter each process only manages the particles that it owns. Once it knows the velocity and position of each particle it can compute if the particle will leave the zone in the next time tick. In the case when a particle leaves a zone, you just send a message to the next zone controller process that you predict it will move to. I know that some games companies use this technique for large multi-user games written in Erlang. They use a 2D map of squares and each square is controlled by an Erlang processes. This scales nicely on a cluster, since moving off a map square just moves the computation to a new processes and possible a new node. Method 2 - let the processes manage a limited set of processes I guess if you didn't have too many particles you could have one process per particle. Each process could have a "gossip" set (the set of "nearby in space" processes) which send messages to it's neighbours as things happen. Or you could let one process handle 10 particles ... I guess it al depends on the numbers - I don't think you said how many particles there were etc. I always like to know some numbers - are we talking millions or thousands of particles? How many interactions/sec take place etc. In any case you'll have to model the problem in different ways and measure. Cheers /Joe On Wed, Feb 12, 2014 at 6:56 PM, kraythe . wrote: > Ahh octtree is good if the objects are static and if your goal is to find > an object in a large space. It is a reductive search algorithm. In this > case all of the objects are in motion and I want to know my neigbors, not > find object X in the space. Therefore a different approach is called for. > > Imagine thousands of particles flowing around in a medium and needing to > determine their interactions based on vicinity, momentum, etc. From frame > to frame the state of your tree would change and the cost would make the > simulation impossible to render in realtime. Instead if the world is > divided up into cubes that are larger than the sphere of influence and each > cube knows about its neighbors then I can easily get a candidate list as > long as the particles update the cube entity that they are in. As they move > into a cube, they inform the cube that they have entered and as they leave > the cube, they inform it of their exit. If I know the cube I am in, and I > know my sphere of influence overlaps into another cube, I can immediately > exclude all candidate not in either cube. If the cube has references to its > neigbors, the solution is easy. > > 1) Determine if I overlap sphere into neighbors (simple math problem of > the radius of my sphere and the boinds of the cube. > 2) For all cubes I overlap, get members. > 3) For all members determine which are inside my sphere. > 4) Interract with elements in my sphere. > > Incidentally my current version of the code, Thanks to Richard's input, > is: > > %% Subtract the second vector from the first > subtract({X1, Y1, Z1}, {X2, Y2, Z2}) -> {(X1 - X2), (Y1 - Y2), (Z1 - Z2)}. > > %% Compute if the vector T is in the sphere with center at vector C and > with radius R. > in_sphere(C, R, T) -> > {Dx, Dy, Dz} = subtract(C, T), > Dx * Dx + Dy * Dy + Dz * Dz =< R * R. > > %% Calculate all entities in the sphere defined at center vector C with > radius R and using Fpos which will extract the location to check from > %% each entity in the list. The method Fpos must return a three tuple > vector and take the entity as an argument. > entities_in_sphere(C ,R, Entities, Fpos) -> > [E || E <- Entities, in_sphere(C, R, Fpos(E))]. > > It also appears to run quite fast according to preliminary timer:tc tests > but of course there is need for more massive testing of load. I may still > have to use the type optimization richard pointed out. I am debating > staying with integer arithmetic also. > > > *Robert Simmons Jr. MSc. * > > > On Wed, Feb 12, 2014 at 8:04 AM, Joe Armstrong wrote: > >> >> >> >> On Tue, Feb 11, 2014 at 11:17 PM, kraythe . wrote: >> >>> Richard, >>> >>> I appreciate your response and the effort you put into it. And I learned >>> a lot from it. In this case I am learning the thinking mode of Erlang as it >>> is different a bit from what I do to pay the bills. I have yet to get into >>> list comprehensions in Erlang so that is on my ... well ... list. :) You >>> have provided valuable insight. >>> >>> The main focus of the method is if I have a number of objects with a >>> vector position in a simulation and I want to exclude considerations of >>> interactions with objects outside the sphere of influence, I have to >>> quickly discard the candidates that are not inside the sphere of influence. >>> I originally thought to write a method that did just the vector math >>> because I was wondering if that kind of math would have to ultimately be >>> turned into something native. Even a delay of 1 second would be fatal to >>> the simulation. >>> >> >> Isn't this what octrees are for? - You'd have to use a "cube of >> influence" - but as far as I know octrees >> can be used to rapidly partition objects in a 3-d space >> >> Take a look at this http://en.wikipedia.org/wiki/Octree >> >> /Joe >> >> >>> >>> The algorithm, however, shouldnt have to consider all candidates as the >>> world is broken into spacial segments (cubes) such that the sphere could >>> intersect with at maximum 8 neighboring cubes so I would only need to >>> consider simulation objects within those 8 cube spaces when determining >>> which elements were actually within the sphere of influence. I have been >>> trying to devise a method of reducing the candidate set even further and am >>> still working on that. Perhaps edge detection and cube boundary >>> calculations but I don't want to spend more math doing that then I would >>> simply excluding objects vector by vector. >>> >>> Anyway thanks for the reply, definitely some information that I can use >>> in there. >>> >>> *Robert Simmons Jr. MSc.* >>> >>> On Sun, Feb 9, 2014 at 10:59 PM, Richard A. O'Keefe wrote: >>> >>>> >>>> On 8/02/2014, at 4:53 AM, kraythe . wrote: >>>> > Anyway back to the subject at hand. The algorithm is set but now I am >>>> at another quandary Lets say these vectors represent a position in space of >>>> particular objects in a simulation. The process of culling the vectors >>>> based on the sphere is entirely a vector problem but what the user calling >>>> cull/3 really needs to know is which objects are not culled from the list, >>>> not just which vectors are not culled. Now in Java I could do a number of >>>> things if I wanted to keep the cull algorithm as it is. I could return the >>>> list of integers containing the original indexes of the vectors in the list >>>> that were culled and use that to filter out which objects need to be >>>> considered for the simulation step. >>>> >>>> The word "cull" really grates. >>>> >>>> And all those negations *really* confused me *all over again*. >>>> I wrote a lengthy and helpful description of how to get the >>>> points that were accepted and the points that were rejected >>>> as two lists, because that was the only way I could interpret >>>> your question to make sense in Erlang. But on repeated re-reading >>>> it became clear that you were asking for something else. >>>> >>>> There is no such thing in Erlang as object identity. >>>> The distinction you are drawing between the "points" and the >>>> "objects" simply doesn't exist. >>>> >>>> It so happens that if you use a list comprehension like >>>> [P || P <- Points, some_predicate(P)] >>>> the elements of the result *will* be (references to) the same >>>> implementation-level webs of chunks of memory that were in the >>>> original list, not copies. But nothing other than performance >>>> depends on this. >>>> >>>> A list of integers such as you ask for could be obtained, but it >>>> would be very little use to you, because Erlang lists are *LINKED >>>> LISTS*, not *INDEXED ARRAYS*. Finding the nth element of a list >>>> takes O(n) time, and that could not be changed without making >>>> lists much less useful. >>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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 kraythe@REDACTED Wed Feb 12 21:48:07 2014 From: kraythe@REDACTED (kraythe .) Date: Wed, 12 Feb 2014 14:48:07 -0600 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: <71D26997-BBC2-41F7-BCAB-592E45D28609@cs.otago.ac.nz> Message-ID: Joe, The problems of gaming are similar for sure but the scale here is much larger. But I can throw another monkey wrench into the mix. The motion of the particles are non-deterministic and can be acted upon by an external force. So each particle needs to have its own life and own process. What I had thought of doing is the following and i would be appreciative of the experience of you and the other erlang gurus in commenting on my proposals: I essentially thought to have each particle be its own process. Furthermore, the world would be divided up into 3d cubes, each of which is at least larger than the maximum radius of the sphere of influence. Each 3d cube would be a process as well and the. The particle process would track which cube it is in and the cubes would track which particles are in them. Then when the motion happens at each frame if the particle leaves a cube, it will send a message to that cube indicating it left and it will also send a message to the new cube that it entered. When determining the particles in the field, the particle would determine whether its sphere spanned multiple cubes and ask each cube which it overlaps to send it a message with the list of particles in the cube. Then it would apply our "in_sphere" test to determine the actual candidates to interact with and then execute those interractions. Points of debate for me are: 1) Should they be cubes dividing the space or another shape. If we use cubes, the maximum number of cubes a sphere could overlap would be 8 if the cubes are arranged in a regular pattern. Alternatively we could use an irregular pattern like a brick layer and then the max number of cubes to check is 5. Are there any other configurations that don't have any overlap of spatial partitioning and could reduce the number of candidate cells further without complicating the math badly. 2) is it worth it to cache, in some manner, the particles in the sphere of influence. I am leaning towards "no" because all will have to be checked to see if they moved out anyway and then the other candidates will have to be checked if they moved in. So there seems little reason to cache anything. 3) Is it worth it to manually move processes around cores as they transition to other areas of geometry (i.e. if the particle is on core 8 of machine 5 but its bounding cube is on core 2 of node 1 there could be inefficiency.) This question is largely a result of my newbieness to OTP and erlang I suppose. If we do move the actor around we will have to reconnect the "client" governing the particle motion to the new actor. Interesting problem huh? *Robert Simmons Jr. MSc. * On Wed, Feb 12, 2014 at 1:42 PM, Joe Armstrong wrote: > Interesting problem. > > How to you map your problem onto a process structure? > > Method 1 - let the process manage regions of space > > How about starting with 1000 parallel processes. Each one managing a point > in a 10x10x10 grid in 3-d space. > > In pass one you compute which process "owns" each particle. Thereafter > each process only manages the > particles that it owns. Once it knows the velocity and position of each > particle it can compute if the particle > will leave the zone in the next time tick. In the case when a particle > leaves a zone, you just send a message > to the next zone controller process that you predict it will move to. > > I know that some games companies use this technique for large multi-user > games written in Erlang. They use a 2D map of squares and each square is > controlled by an Erlang processes. This scales nicely on a cluster, since > moving off a map square just moves the computation to a new processes and > possible a > new node. > > Method 2 - let the processes manage a limited set of processes > > I guess if you didn't have too many particles you could have one process > per particle. Each process > could have a "gossip" set (the set of "nearby in space" processes) which > send messages to it's neighbours as things happen. Or you could let one > process handle 10 particles ... > > I guess it al depends on the numbers - I don't think you said how many > particles there were etc. > I always like to know some numbers - are we talking millions or thousands > of particles? How many > interactions/sec take place etc. > > In any case you'll have to model the problem in different ways and measure. > > Cheers > > /Joe > > > > > > On Wed, Feb 12, 2014 at 6:56 PM, kraythe . wrote: > >> Ahh octtree is good if the objects are static and if your goal is to find >> an object in a large space. It is a reductive search algorithm. In this >> case all of the objects are in motion and I want to know my neigbors, not >> find object X in the space. Therefore a different approach is called for. >> >> Imagine thousands of particles flowing around in a medium and needing to >> determine their interactions based on vicinity, momentum, etc. From frame >> to frame the state of your tree would change and the cost would make the >> simulation impossible to render in realtime. Instead if the world is >> divided up into cubes that are larger than the sphere of influence and each >> cube knows about its neighbors then I can easily get a candidate list as >> long as the particles update the cube entity that they are in. As they move >> into a cube, they inform the cube that they have entered and as they leave >> the cube, they inform it of their exit. If I know the cube I am in, and I >> know my sphere of influence overlaps into another cube, I can immediately >> exclude all candidate not in either cube. If the cube has references to its >> neigbors, the solution is easy. >> >> 1) Determine if I overlap sphere into neighbors (simple math problem of >> the radius of my sphere and the boinds of the cube. >> 2) For all cubes I overlap, get members. >> 3) For all members determine which are inside my sphere. >> 4) Interract with elements in my sphere. >> >> Incidentally my current version of the code, Thanks to Richard's input, >> is: >> >> %% Subtract the second vector from the first >> subtract({X1, Y1, Z1}, {X2, Y2, Z2}) -> {(X1 - X2), (Y1 - Y2), (Z1 - Z2)}. >> >> %% Compute if the vector T is in the sphere with center at vector C and >> with radius R. >> in_sphere(C, R, T) -> >> {Dx, Dy, Dz} = subtract(C, T), >> Dx * Dx + Dy * Dy + Dz * Dz =< R * R. >> >> %% Calculate all entities in the sphere defined at center vector C with >> radius R and using Fpos which will extract the location to check from >> %% each entity in the list. The method Fpos must return a three tuple >> vector and take the entity as an argument. >> entities_in_sphere(C ,R, Entities, Fpos) -> >> [E || E <- Entities, in_sphere(C, R, Fpos(E))]. >> >> It also appears to run quite fast according to preliminary timer:tc tests >> but of course there is need for more massive testing of load. I may still >> have to use the type optimization richard pointed out. I am debating >> staying with integer arithmetic also. >> >> >> *Robert Simmons Jr. MSc. * >> >> >> On Wed, Feb 12, 2014 at 8:04 AM, Joe Armstrong wrote: >> >>> >>> >>> >>> On Tue, Feb 11, 2014 at 11:17 PM, kraythe . wrote: >>> >>>> Richard, >>>> >>>> I appreciate your response and the effort you put into it. And I >>>> learned a lot from it. In this case I am learning the thinking mode of >>>> Erlang as it is different a bit from what I do to pay the bills. I have yet >>>> to get into list comprehensions in Erlang so that is on my ... well ... >>>> list. :) You have provided valuable insight. >>>> >>>> The main focus of the method is if I have a number of objects with a >>>> vector position in a simulation and I want to exclude considerations of >>>> interactions with objects outside the sphere of influence, I have to >>>> quickly discard the candidates that are not inside the sphere of influence. >>>> I originally thought to write a method that did just the vector math >>>> because I was wondering if that kind of math would have to ultimately be >>>> turned into something native. Even a delay of 1 second would be fatal to >>>> the simulation. >>>> >>> >>> Isn't this what octrees are for? - You'd have to use a "cube of >>> influence" - but as far as I know octrees >>> can be used to rapidly partition objects in a 3-d space >>> >>> Take a look at this http://en.wikipedia.org/wiki/Octree >>> >>> /Joe >>> >>> >>>> >>>> The algorithm, however, shouldnt have to consider all candidates as the >>>> world is broken into spacial segments (cubes) such that the sphere could >>>> intersect with at maximum 8 neighboring cubes so I would only need to >>>> consider simulation objects within those 8 cube spaces when determining >>>> which elements were actually within the sphere of influence. I have been >>>> trying to devise a method of reducing the candidate set even further and am >>>> still working on that. Perhaps edge detection and cube boundary >>>> calculations but I don't want to spend more math doing that then I would >>>> simply excluding objects vector by vector. >>>> >>>> Anyway thanks for the reply, definitely some information that I can use >>>> in there. >>>> >>>> *Robert Simmons Jr. MSc.* >>>> >>>> On Sun, Feb 9, 2014 at 10:59 PM, Richard A. O'Keefe wrote: >>>> >>>>> >>>>> On 8/02/2014, at 4:53 AM, kraythe . wrote: >>>>> > Anyway back to the subject at hand. The algorithm is set but now I >>>>> am at another quandary Lets say these vectors represent a position in space >>>>> of particular objects in a simulation. The process of culling the vectors >>>>> based on the sphere is entirely a vector problem but what the user calling >>>>> cull/3 really needs to know is which objects are not culled from the list, >>>>> not just which vectors are not culled. Now in Java I could do a number of >>>>> things if I wanted to keep the cull algorithm as it is. I could return the >>>>> list of integers containing the original indexes of the vectors in the list >>>>> that were culled and use that to filter out which objects need to be >>>>> considered for the simulation step. >>>>> >>>>> The word "cull" really grates. >>>>> >>>>> And all those negations *really* confused me *all over again*. >>>>> I wrote a lengthy and helpful description of how to get the >>>>> points that were accepted and the points that were rejected >>>>> as two lists, because that was the only way I could interpret >>>>> your question to make sense in Erlang. But on repeated re-reading >>>>> it became clear that you were asking for something else. >>>>> >>>>> There is no such thing in Erlang as object identity. >>>>> The distinction you are drawing between the "points" and the >>>>> "objects" simply doesn't exist. >>>>> >>>>> It so happens that if you use a list comprehension like >>>>> [P || P <- Points, some_predicate(P)] >>>>> the elements of the result *will* be (references to) the same >>>>> implementation-level webs of chunks of memory that were in the >>>>> original list, not copies. But nothing other than performance >>>>> depends on this. >>>>> >>>>> A list of integers such as you ask for could be obtained, but it >>>>> would be very little use to you, because Erlang lists are *LINKED >>>>> LISTS*, not *INDEXED ARRAYS*. Finding the nth element of a list >>>>> takes O(n) time, and that could not be changed without making >>>>> lists much less useful. >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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 gustav.simonsson@REDACTED Wed Feb 12 22:48:35 2014 From: gustav.simonsson@REDACTED (Gustav Simonsson) Date: Wed, 12 Feb 2014 22:48:35 +0100 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: <71D26997-BBC2-41F7-BCAB-592E45D28609@cs.otago.ac.nz> Message-ID: Apologies if this is completely wrong, but: Wouldn't one process for each particle, given thousands of particles, pose a potential overhead problem given the extra scheduling required between processes? I would be inclined to try one process for each 3d cube, as you mentioned, and also let that process keep track of all particles within its cube (maybe in a ETS table). Then, if a particle crosses over to another cube, the particle would be migrated from one process to another (via a message sent between the two cube processes). To answer your other points of debate: 1. This is a very interesting problem which for graphics from a first person point of view is well researched, but since this is for some backend serving a game/simulation it (I suppose) involves multiple players/entities, so we wouldn't want the 3D space to be asymmetrically partitioned if we could avoid it (atleast to start with). If it makes sense given the properties of the 3D space, particles and other objects/players you have, one way to reduce the maximum shapes overlapping with the sphere of influence to 4 is to partition the space into a set of symmetrical cuboids where the Z-axis of each cuboid goes from the minimum to the maximum of the space, and the X and Y sizes of the cuboids remain strictly larger than the diameter of the sphere (as you mentioned for the cube partitioning). 2. I guess the particles, whether they have their own process or are handled inside a cube (or cuboid!) process are in memory anyway, so I'd wait with caching anything until its time to optimize a working implementation. 3. The general advice is to save tweaking the BEAM schedulers and which scheduler a process runs in for the later stages of optimization. But for reference, you can bind a process to a specific scheduler [1] and also bind a scheduler to a specific CPU thread (logical processor) [2]. Cheers, Gustav [1] Use the {scheduler, N} option (undocumented) to erlang:spawn_opt/2,3,4,5. The number of schedulers can be found with erlang:system_info(schedulers) , and the scheduler for the calling process with erlang:system_info(scheduler_id). [2] Look at the +sbt options at http://www.erlang.org/doc/man/erl.html#emu_flags On Wed, Feb 12, 2014 at 9:48 PM, kraythe . wrote: > Joe, > > The problems of gaming are similar for sure but the scale here is much > larger. But I can throw another monkey wrench into the mix. The motion of > the particles are non-deterministic and can be acted upon by an external > force. So each particle needs to have its own life and own process. What I > had thought of doing is the following and i would be appreciative of the > experience of you and the other erlang gurus in commenting on my proposals: > > I essentially thought to have each particle be its own process. > Furthermore, the world would be divided up into 3d cubes, each of which is > at least larger than the maximum radius of the sphere of influence. Each 3d > cube would be a process as well and the. The particle process would track > which cube it is in and the cubes would track which particles are in them. > Then when the motion happens at each frame if the particle leaves a cube, > it will send a message to that cube indicating it left and it will also > send a message to the new cube that it entered. When determining the > particles in the field, the particle would determine whether its sphere > spanned multiple cubes and ask each cube which it overlaps to send it a > message with the list of particles in the cube. Then it would apply our > "in_sphere" test to determine the actual candidates to interact with and > then execute those interractions. > > Points of debate for me are: > 1) Should they be cubes dividing the space or another shape. If we use > cubes, the maximum number of cubes a sphere could overlap would be 8 if the > cubes are arranged in a regular pattern. Alternatively we could use an > irregular pattern like a brick layer and then the max number of cubes to > check is 5. Are there any other configurations that don't have any overlap > of spatial partitioning and could reduce the number of candidate cells > further without complicating the math badly. > 2) is it worth it to cache, in some manner, the particles in the sphere of > influence. I am leaning towards "no" because all will have to be checked to > see if they moved out anyway and then the other candidates will have to be > checked if they moved in. So there seems little reason to cache anything. > 3) Is it worth it to manually move processes around cores as they > transition to other areas of geometry (i.e. if the particle is on core 8 of > machine 5 but its bounding cube is on core 2 of node 1 there could be > inefficiency.) This question is largely a result of my newbieness to OTP > and erlang I suppose. If we do move the actor around we will have to > reconnect the "client" governing the particle motion to the new actor. > > Interesting problem huh? > > > *Robert Simmons Jr. MSc. * > > > On Wed, Feb 12, 2014 at 1:42 PM, Joe Armstrong wrote: > >> Interesting problem. >> >> How to you map your problem onto a process structure? >> >> Method 1 - let the process manage regions of space >> >> How about starting with 1000 parallel processes. Each one managing a >> point in a 10x10x10 grid in 3-d space. >> >> In pass one you compute which process "owns" each particle. Thereafter >> each process only manages the >> particles that it owns. Once it knows the velocity and position of each >> particle it can compute if the particle >> will leave the zone in the next time tick. In the case when a particle >> leaves a zone, you just send a message >> to the next zone controller process that you predict it will move to. >> >> I know that some games companies use this technique for large multi-user >> games written in Erlang. They use a 2D map of squares and each square is >> controlled by an Erlang processes. This scales nicely on a cluster, since >> moving off a map square just moves the computation to a new processes and >> possible a >> new node. >> >> Method 2 - let the processes manage a limited set of processes >> >> I guess if you didn't have too many particles you could have one process >> per particle. Each process >> could have a "gossip" set (the set of "nearby in space" processes) which >> send messages to it's neighbours as things happen. Or you could let one >> process handle 10 particles ... >> >> I guess it al depends on the numbers - I don't think you said how many >> particles there were etc. >> I always like to know some numbers - are we talking millions or thousands >> of particles? How many >> interactions/sec take place etc. >> >> In any case you'll have to model the problem in different ways and >> measure. >> >> Cheers >> >> /Joe >> >> >> >> >> >> On Wed, Feb 12, 2014 at 6:56 PM, kraythe . wrote: >> >>> Ahh octtree is good if the objects are static and if your goal is to >>> find an object in a large space. It is a reductive search algorithm. In >>> this case all of the objects are in motion and I want to know my neigbors, >>> not find object X in the space. Therefore a different approach is called >>> for. >>> >>> Imagine thousands of particles flowing around in a medium and needing >>> to determine their interactions based on vicinity, momentum, etc. From >>> frame to frame the state of your tree would change and the cost would make >>> the simulation impossible to render in realtime. Instead if the world is >>> divided up into cubes that are larger than the sphere of influence and each >>> cube knows about its neighbors then I can easily get a candidate list as >>> long as the particles update the cube entity that they are in. As they move >>> into a cube, they inform the cube that they have entered and as they leave >>> the cube, they inform it of their exit. If I know the cube I am in, and I >>> know my sphere of influence overlaps into another cube, I can immediately >>> exclude all candidate not in either cube. If the cube has references to its >>> neigbors, the solution is easy. >>> >>> 1) Determine if I overlap sphere into neighbors (simple math problem of >>> the radius of my sphere and the boinds of the cube. >>> 2) For all cubes I overlap, get members. >>> 3) For all members determine which are inside my sphere. >>> 4) Interract with elements in my sphere. >>> >>> Incidentally my current version of the code, Thanks to Richard's input, >>> is: >>> >>> %% Subtract the second vector from the first >>> subtract({X1, Y1, Z1}, {X2, Y2, Z2}) -> {(X1 - X2), (Y1 - Y2), (Z1 - >>> Z2)}. >>> >>> %% Compute if the vector T is in the sphere with center at vector C and >>> with radius R. >>> in_sphere(C, R, T) -> >>> {Dx, Dy, Dz} = subtract(C, T), >>> Dx * Dx + Dy * Dy + Dz * Dz =< R * R. >>> >>> %% Calculate all entities in the sphere defined at center vector C with >>> radius R and using Fpos which will extract the location to check from >>> %% each entity in the list. The method Fpos must return a three tuple >>> vector and take the entity as an argument. >>> entities_in_sphere(C ,R, Entities, Fpos) -> >>> [E || E <- Entities, in_sphere(C, R, Fpos(E))]. >>> >>> It also appears to run quite fast according to preliminary timer:tc >>> tests but of course there is need for more massive testing of load. I may >>> still have to use the type optimization richard pointed out. I am debating >>> staying with integer arithmetic also. >>> >>> >>> *Robert Simmons Jr. MSc. * >>> >>> >>> On Wed, Feb 12, 2014 at 8:04 AM, Joe Armstrong wrote: >>> >>>> >>>> >>>> >>>> On Tue, Feb 11, 2014 at 11:17 PM, kraythe . wrote: >>>> >>>>> Richard, >>>>> >>>>> I appreciate your response and the effort you put into it. And I >>>>> learned a lot from it. In this case I am learning the thinking mode of >>>>> Erlang as it is different a bit from what I do to pay the bills. I have yet >>>>> to get into list comprehensions in Erlang so that is on my ... well ... >>>>> list. :) You have provided valuable insight. >>>>> >>>>> The main focus of the method is if I have a number of objects with a >>>>> vector position in a simulation and I want to exclude considerations of >>>>> interactions with objects outside the sphere of influence, I have to >>>>> quickly discard the candidates that are not inside the sphere of influence. >>>>> I originally thought to write a method that did just the vector math >>>>> because I was wondering if that kind of math would have to ultimately be >>>>> turned into something native. Even a delay of 1 second would be fatal to >>>>> the simulation. >>>>> >>>> >>>> Isn't this what octrees are for? - You'd have to use a "cube of >>>> influence" - but as far as I know octrees >>>> can be used to rapidly partition objects in a 3-d space >>>> >>>> Take a look at this http://en.wikipedia.org/wiki/Octree >>>> >>>> /Joe >>>> >>>> >>>>> >>>>> The algorithm, however, shouldnt have to consider all candidates as >>>>> the world is broken into spacial segments (cubes) such that the sphere >>>>> could intersect with at maximum 8 neighboring cubes so I would only need to >>>>> consider simulation objects within those 8 cube spaces when determining >>>>> which elements were actually within the sphere of influence. I have been >>>>> trying to devise a method of reducing the candidate set even further and am >>>>> still working on that. Perhaps edge detection and cube boundary >>>>> calculations but I don't want to spend more math doing that then I would >>>>> simply excluding objects vector by vector. >>>>> >>>>> Anyway thanks for the reply, definitely some information that I can >>>>> use in there. >>>>> >>>>> *Robert Simmons Jr. MSc.* >>>>> >>>>> On Sun, Feb 9, 2014 at 10:59 PM, Richard A. O'Keefe >>>> > wrote: >>>>> >>>>>> >>>>>> On 8/02/2014, at 4:53 AM, kraythe . wrote: >>>>>> > Anyway back to the subject at hand. The algorithm is set but now I >>>>>> am at another quandary Lets say these vectors represent a position in space >>>>>> of particular objects in a simulation. The process of culling the vectors >>>>>> based on the sphere is entirely a vector problem but what the user calling >>>>>> cull/3 really needs to know is which objects are not culled from the list, >>>>>> not just which vectors are not culled. Now in Java I could do a number of >>>>>> things if I wanted to keep the cull algorithm as it is. I could return the >>>>>> list of integers containing the original indexes of the vectors in the list >>>>>> that were culled and use that to filter out which objects need to be >>>>>> considered for the simulation step. >>>>>> >>>>>> The word "cull" really grates. >>>>>> >>>>>> And all those negations *really* confused me *all over again*. >>>>>> I wrote a lengthy and helpful description of how to get the >>>>>> points that were accepted and the points that were rejected >>>>>> as two lists, because that was the only way I could interpret >>>>>> your question to make sense in Erlang. But on repeated re-reading >>>>>> it became clear that you were asking for something else. >>>>>> >>>>>> There is no such thing in Erlang as object identity. >>>>>> The distinction you are drawing between the "points" and the >>>>>> "objects" simply doesn't exist. >>>>>> >>>>>> It so happens that if you use a list comprehension like >>>>>> [P || P <- Points, some_predicate(P)] >>>>>> the elements of the result *will* be (references to) the same >>>>>> implementation-level webs of chunks of memory that were in the >>>>>> original list, not copies. But nothing other than performance >>>>>> depends on this. >>>>>> >>>>>> A list of integers such as you ask for could be obtained, but it >>>>>> would be very little use to you, because Erlang lists are *LINKED >>>>>> LISTS*, not *INDEXED ARRAYS*. Finding the nth element of a list >>>>>> takes O(n) time, and that could not be changed without making >>>>>> lists much less useful. >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 kraythe@REDACTED Wed Feb 12 23:04:39 2014 From: kraythe@REDACTED (kraythe .) Date: Wed, 12 Feb 2014 16:04:39 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? Message-ID: I am a newbie to Erlang so pardon if the question comes off as impertinent. However, as I read more into OTP and see the power it has, I am more and more irked by its name. The Open Telephony Platform seems to be a little limited and I wonder if it would put off people trying to adopt Erlang for other use cases. I am wondering wouldn't it be better to call it the Open Technology Platform? The same initials can be used, but the understanding would be that the platform would be a general purpose library (which it is) useful for many endeavors, not just writing a phone switch. Sure it might seem trivial but any marketing guy will tell you, naming is sometimes everything. So am I nuts here? *Robert Simmons Jr. MSc.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustav.simonsson@REDACTED Wed Feb 12 23:09:46 2014 From: gustav.simonsson@REDACTED (Gustav Simonsson) Date: Wed, 12 Feb 2014 23:09:46 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: Message-ID: Let's make it more appealing to startups and the agile folks: Organic Technology Paradigm shift. On Wed, Feb 12, 2014 at 11:04 PM, kraythe . wrote: > I am a newbie to Erlang so pardon if the question comes off as > impertinent. However, as I read more into OTP and see the power it has, I > am more and more irked by its name. The Open Telephony Platform seems to be > a little limited and I wonder if it would put off people trying to adopt > Erlang for other use cases. > > I am wondering wouldn't it be better to call it the Open Technology > Platform? The same initials can be used, but the understanding would be > that the platform would be a general purpose library (which it is) useful > for many endeavors, not just writing a phone switch. > > Sure it might seem trivial but any marketing guy will tell you, naming is > sometimes everything. So am I nuts here? > > > *Robert Simmons Jr. MSc.* > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean@REDACTED Wed Feb 12 23:15:54 2014 From: sean@REDACTED (Sean Cribbs) Date: Wed, 12 Feb 2014 16:15:54 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: Message-ID: The inimitable Garrett Smith has also provided us a (politically-incorrect) alternative: http://www.youtube.com/watch?v=rRbY3TMUcgQ You may know Garrett from his previous works, "MongoDB is Web-Scale" and "Node.js is Bad-ass Rockstar Tech". Take everything in the video with a grain of salt and sense of humor. :D On Wed, Feb 12, 2014 at 4:09 PM, Gustav Simonsson < gustav.simonsson@REDACTED> wrote: > Let's make it more appealing to startups and the agile folks: Organic > Technology Paradigm shift. > > > On Wed, Feb 12, 2014 at 11:04 PM, kraythe . wrote: > >> I am a newbie to Erlang so pardon if the question comes off as >> impertinent. However, as I read more into OTP and see the power it has, I >> am more and more irked by its name. The Open Telephony Platform seems to be >> a little limited and I wonder if it would put off people trying to adopt >> Erlang for other use cases. >> >> I am wondering wouldn't it be better to call it the Open Technology >> Platform? The same initials can be used, but the understanding would be >> that the platform would be a general purpose library (which it is) useful >> for many endeavors, not just writing a phone switch. >> >> Sure it might seem trivial but any marketing guy will tell you, naming is >> sometimes everything. So am I nuts here? >> >> >> *Robert Simmons Jr. MSc.* >> >> _______________________________________________ >> 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From valentin@REDACTED Wed Feb 12 23:18:27 2014 From: valentin@REDACTED (Valentin Micic) Date: Thu, 13 Feb 2014 00:18:27 +0200 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: Message-ID: <6D188087-8267-4A91-A616-A5FEAE999ACE@pixie.co.za> Are you sure that 'T' in OTP stands for "Telephony"? I've been under an impression it stood for "Telecommunications" or "Telecoms". And I agree -- it is trivial, and do not agree that naming is everything... otherwise, no-one sane will name a computer company after a fruit. V/ > > On Wed, Feb 12, 2014 at 11:04 PM, kraythe . wrote: > I am a newbie to Erlang so pardon if the question comes off as impertinent. However, as I read more into OTP and see the power it has, I am more and more irked by its name. The Open Telephony Platform seems to be a little limited and I wonder if it would put off people trying to adopt Erlang for other use cases. > > I am wondering wouldn't it be better to call it the Open Technology Platform? The same initials can be used, but the understanding would be that the platform would be a general purpose library (which it is) useful for many endeavors, not just writing a phone switch. > > Sure it might seem trivial but any marketing guy will tell you, naming is sometimes everything. So am I nuts here? > > Robert Simmons Jr. MSc. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjw0188@REDACTED Wed Feb 12 23:18:54 2014 From: kjw0188@REDACTED (Kelly Wong) Date: Wed, 12 Feb 2014 14:18:54 -0800 Subject: [erlang-questions] Mongoose IM Documentation In-Reply-To: <88790ACE-DADD-45D1-97F0-2D19BA07E590@erlang-solutions.com> References: <88790ACE-DADD-45D1-97F0-2D19BA07E590@erlang-solutions.com> Message-ID: Thanks, Antoine, I'll look into that module. Thanks Michal, I'll look at the wiki. It seems much more in depth than other tutorials I've found. Kelly On Wed, Feb 12, 2014 at 4:19 AM, Michal Piotrowski < michal.piotrowski@REDACTED> wrote: > Hi Kelly, > > Sorry for such a late response. On our github we have an introduction to > hooks. Take a look at: > https://github.com/esl/MongooseIM/wiki/hooks-and-handlers. You should > find there anything you need regarding hooks in MongooseIM, I think. > > If you have further questions please add my email to CC as I'm not > checking the mailing list very often. > You can also send email to ejabberd@REDACTED > > Best regards > Michal Piotrowski > michal.piotrowski@REDACTED > > > On 07 Feb 2014, at 22:43, Kelly Wong wrote: > > Hi Michal, > > Thanks for the link. I'm trying to figure out what hooks I can set and > when they're called. The end goal is to write a plugin that can send an > Apple notification service message to a user who is not online. I was > thinking I could write a plugin that intercepts messages to offline users. > Is that the right way to go about things? > > Thanks, > Kelly Wong > > > On Wed, Feb 5, 2014 at 11:18 PM, Michal Piotrowski < > michal.piotrowski@REDACTED> wrote: > >> Hello Kelly, >> >> There are some examples on our github: https://github.com/esl/MongooseIM. >> The default installation of MongooseIM works with mnesia as a database. >> What exactly do you need to know? >> >> BTW, the config file is in most cases compatible with the one in ejabberd >> 2.1.x. >> >> Best regards >> Michal Piotrowski >> michal.piotrowski@REDACTED >> >> >> On 05 Feb 2014, at 03:10, Kelly Wong wrote: >> >> Hello, >> >> I'm trying to setup Mongoose IM, but for the life of me can't find any >> documentation for it. Can anyone point me in the right direction? >> >> Thanks, >> Kelly Wong >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.meiklejohn@REDACTED Wed Feb 12 23:19:08 2014 From: christopher.meiklejohn@REDACTED (Christopher Meiklejohn) Date: Wed, 12 Feb 2014 17:19:08 -0500 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: Message-ID: <1F6F6570-C5F1-47B3-92F3-D87E0FA06B6F@gmail.com> May I propose an alternative? "Open Telecom Platform: An Unexpected Journey." - Chris On Feb 12, 2014, at 5:15 PM, Sean Cribbs wrote: > The inimitable Garrett Smith has also provided us a (politically-incorrect) alternative: http://www.youtube.com/watch?v=rRbY3TMUcgQ > > You may know Garrett from his previous works, "MongoDB is Web-Scale" and "Node.js is Bad-ass Rockstar Tech". > > Take everything in the video with a grain of salt and sense of humor. :D > > > On Wed, Feb 12, 2014 at 4:09 PM, Gustav Simonsson wrote: > Let's make it more appealing to startups and the agile folks: Organic Technology Paradigm shift. > > > On Wed, Feb 12, 2014 at 11:04 PM, kraythe . wrote: > I am a newbie to Erlang so pardon if the question comes off as impertinent. However, as I read more into OTP and see the power it has, I am more and more irked by its name. The Open Telephony Platform seems to be a little limited and I wonder if it would put off people trying to adopt Erlang for other use cases. > > I am wondering wouldn't it be better to call it the Open Technology Platform? The same initials can be used, but the understanding would be that the platform would be a general purpose library (which it is) useful for many endeavors, not just writing a phone switch. > > Sure it might seem trivial but any marketing guy will tell you, naming is sometimes everything. So am I nuts here? > > Robert Simmons Jr. MSc. > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tristan.sloughter@REDACTED Wed Feb 12 23:26:38 2014 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Wed, 12 Feb 2014 14:26:38 -0800 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <1F6F6570-C5F1-47B3-92F3-D87E0FA06B6F@gmail.com> References: <1F6F6570-C5F1-47B3-92F3-D87E0FA06B6F@gmail.com> Message-ID: <1392243998.19656.82717209.03EEEC1E@webmail.messagingengine.com> How about: RARTP, Reactive Async Real Time Platform -- Tristan Sloughter tristan.sloughter@REDACTED On Wed, Feb 12, 2014, at 02:19 PM, Christopher Meiklejohn wrote: May I propose an alternative? "Open Telecom Platform: An Unexpected Journey." - Chris On Feb 12, 2014, at 5:15 PM, Sean Cribbs <[1]sean@REDACTED> wrote: The inimitable Garrett Smith has also provided us a (politically-incorrect) alternative: [2]http://www.youtube.com/watch?v=rRbY3TMUcgQ You may know Garrett from his previous works, "MongoDB is Web-Scale" and "Node.js is Bad-ass Rockstar Tech". Take everything in the video with a grain of salt and sense of humor. :D On Wed, Feb 12, 2014 at 4:09 PM, Gustav Simonsson <[3]gustav.simonsson@REDACTED> wrote: Let's make it more appealing to startups and the agile folks: Organic Technology Paradigm shift. On Wed, Feb 12, 2014 at 11:04 PM, kraythe . <[4]kraythe@REDACTED> wrote: I am a newbie to Erlang so pardon if the question comes off as impertinent. However, as I read more into OTP and see the power it has, I am more and more irked by its name. The Open Telephony Platform seems to be a little limited and I wonder if it would put off people trying to adopt Erlang for other use cases. I am wondering wouldn't it be better to call it the Open Technology Platform? The same initials can be used, but the understanding would be that the platform would be a general purpose library (which it is) useful for many endeavors, not just writing a phone switch. Sure it might seem trivial but any marketing guy will tell you, naming is sometimes everything. So am I nuts here? Robert Simmons Jr. MSc. _______________________________________________ erlang-questions mailing list [5]erlang-questions@REDACTED [6]http://erlang.org/mailman/listinfo/erlang-questions _______________________________________________ erlang-questions mailing list [7]erlang-questions@REDACTED [8]http://erlang.org/mailman/listinfo/erlang-questions -- Sean Cribbs <[9]sean@REDACTED> Software Engineer Basho Technologies, Inc. [10]http://basho.com/ _______________________________________________ erlang-questions mailing list [11]erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions _______________________________________________ erlang-questions mailing list [12]erlang-questions@REDACTED [13]http://erlang.org/mailman/listinfo/erlang-questions References 1. mailto:sean@REDACTED 2. http://www.youtube.com/watch?v=rRbY3TMUcgQ 3. mailto:gustav.simonsson@REDACTED 4. mailto:kraythe@REDACTED 5. mailto:erlang-questions@REDACTED 6. http://erlang.org/mailman/listinfo/erlang-questions 7. mailto:erlang-questions@REDACTED 8. http://erlang.org/mailman/listinfo/erlang-questions 9. mailto:sean@REDACTED 10. http://basho.com/ 11. mailto:erlang-questions@REDACTED 12. mailto:erlang-questions@REDACTED 13. http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.j.stone.1@REDACTED Wed Feb 12 23:36:30 2014 From: andrew.j.stone.1@REDACTED (Andrew Stone) Date: Wed, 12 Feb 2014 17:36:30 -0500 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <1F6F6570-C5F1-47B3-92F3-D87E0FA06B6F@gmail.com> References: <1F6F6570-C5F1-47B3-92F3-D87E0FA06B6F@gmail.com> Message-ID: That sounds like a Dank Fire Idea! On Wed, Feb 12, 2014 at 5:19 PM, Christopher Meiklejohn < christopher.meiklejohn@REDACTED> wrote: > May I propose an alternative? "Open Telecom Platform: An Unexpected > Journey." > > - Chris > > On Feb 12, 2014, at 5:15 PM, Sean Cribbs wrote: > > The inimitable Garrett Smith has also provided us a > (politically-incorrect) alternative: > http://www.youtube.com/watch?v=rRbY3TMUcgQ > > You may know Garrett from his previous works, "MongoDB is Web-Scale" and > "Node.js is Bad-ass Rockstar Tech". > > Take everything in the video with a grain of salt and sense of humor. :D > > > On Wed, Feb 12, 2014 at 4:09 PM, Gustav Simonsson < > gustav.simonsson@REDACTED> wrote: > >> Let's make it more appealing to startups and the agile folks: Organic >> Technology Paradigm shift. >> >> >> On Wed, Feb 12, 2014 at 11:04 PM, kraythe . wrote: >> >>> I am a newbie to Erlang so pardon if the question comes off as >>> impertinent. However, as I read more into OTP and see the power it has, I >>> am more and more irked by its name. The Open Telephony Platform seems to be >>> a little limited and I wonder if it would put off people trying to adopt >>> Erlang for other use cases. >>> >>> I am wondering wouldn't it be better to call it the Open Technology >>> Platform? The same initials can be used, but the understanding would be >>> that the platform would be a general purpose library (which it is) useful >>> for many endeavors, not just writing a phone switch. >>> >>> Sure it might seem trivial but any marketing guy will tell you, naming >>> is sometimes everything. So am I nuts here? >>> >>> >>> *Robert Simmons Jr. MSc.* >>> >>> _______________________________________________ >>> 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 essen@REDACTED Wed Feb 12 23:56:07 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 12 Feb 2014 23:56:07 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: Message-ID: <52FBFC07.8010007@ninenines.eu> Historically OTP meant Open Telecom Platform. Today OTP means OTP. People don't use the name OTP as initials of anything. When they say OTP, they refer to a framework for building highly available fault tolerant distributed systems. The same situation exists with many other names. Few can tell you what SMTP, IMAP, HTTP, REST, SOAP, HTML, XML, JPEG, PNG and others stand for without looking it up and not making a mistake or three. And it doesn't matter, the abbreviated name is the one that is used by people, and it's the one that holds the meaning. Do you think "Joint Photographic Experts Group" is a good name for an image file format? I think not, but it doesn't matter, because people call it JPEG. And just like it, what OTP initially meant doesn't matter, because people refer to the framework as OTP, not as Open Telecom Platform. On 02/12/2014 11:04 PM, kraythe . wrote: > I am a newbie to Erlang so pardon if the question comes off as impertinent. > However, as I read more into OTP and see the power it has, I am more and > more irked by its name. The Open Telephony Platform seems to be a little > limited and I wonder if it would put off people trying to adopt Erlang for > other use cases. > > I am wondering wouldn't it be better to call it the Open Technology > Platform? The same initials can be used, but the understanding would be > that the platform would be a general purpose library (which it is) useful > for many endeavors, not just writing a phone switch. > > Sure it might seem trivial but any marketing guy will tell you, naming is > sometimes everything. So am I nuts here? > > > *Robert Simmons Jr. MSc.* > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From sina.samv@REDACTED Thu Feb 13 00:04:22 2014 From: sina.samv@REDACTED (Sina Samavati) Date: Thu, 13 Feb 2014 02:34:22 +0330 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <1F6F6570-C5F1-47B3-92F3-D87E0FA06B6F@gmail.com> (Christopher Meiklejohn's message of "Wed, 12 Feb 2014 17:19:08 -0500") References: <1F6F6570-C5F1-47B3-92F3-D87E0FA06B6F@gmail.com> Message-ID: <87y51gdjbd.fsf@gmail.com> Christopher Meiklejohn writes: > May I propose an alternative? "Open Telecom Platform: An Unexpected > Journey." It's a lovely name that can be awesome for articles/books. -- Sina Samavati Software engineer https://github.com/s1n4 https://twitter.com/sinasamavati From eriksoe@REDACTED Thu Feb 13 00:07:51 2014 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Thu, 13 Feb 2014 00:07:51 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: Message-ID: One True Paradigm ;-) (To make it appealing to, er, Erlang enthusiasts.) Den 12/02/2014 23.09 skrev "Gustav Simonsson" : > > Let's make it more appealing to startups and the agile folks: Organic Technology Paradigm shift. > > > On Wed, Feb 12, 2014 at 11:04 PM, kraythe . wrote: >> >> I am a newbie to Erlang so pardon if the question comes off as impertinent. However, as I read more into OTP and see the power it has, I am more and more irked by its name. The Open Telephony Platform seems to be a little limited and I wonder if it would put off people trying to adopt Erlang for other use cases. >> >> I am wondering wouldn't it be better to call it the Open Technology Platform? The same initials can be used, but the understanding would be that the platform would be a general purpose library (which it is) useful for many endeavors, not just writing a phone switch. >> >> Sure it might seem trivial but any marketing guy will tell you, naming is sometimes everything. So am I nuts here? >> >> Robert Simmons Jr. MSc. >> >> _______________________________________________ >> 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 sina.samv@REDACTED Thu Feb 13 00:17:46 2014 From: sina.samv@REDACTED (Sina Samavati) Date: Thu, 13 Feb 2014 02:47:46 +0330 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <52FBFC07.8010007@ninenines.eu> (=?utf-8?Q?=22Lo=C3=AFc?= Hoguin"'s message of "Wed, 12 Feb 2014 23:56:07 +0100") References: <52FBFC07.8010007@ninenines.eu> Message-ID: <87txc3ex9h.fsf@gmail.com> I agree with Lo?c. Also, I think renaming an (almost) old _thing_ is pretty *silly*. Lo?c Hoguin writes: > Historically OTP meant Open Telecom Platform. > > Today OTP means OTP. People don't use the name OTP as initials of > anything. When they say OTP, they refer to a framework for building > highly available fault tolerant distributed systems. > > The same situation exists with many other names. Few can tell you what > SMTP, IMAP, HTTP, REST, SOAP, HTML, XML, JPEG, PNG and others stand > for without looking it up and not making a mistake or three. And it > doesn't matter, the abbreviated name is the one that is used by > people, and it's the one that holds the meaning. Do you think "Joint > Photographic Experts Group" is a good name for an image file format? I > think not, but it doesn't matter, because people call it JPEG. > > And just like it, what OTP initially meant doesn't matter, because > people refer to the framework as OTP, not as Open Telecom Platform. > > On 02/12/2014 11:04 PM, kraythe . wrote: >> I am a newbie to Erlang so pardon if the question comes off as impertinent. >> However, as I read more into OTP and see the power it has, I am more and >> more irked by its name. The Open Telephony Platform seems to be a little >> limited and I wonder if it would put off people trying to adopt Erlang for >> other use cases. >> >> I am wondering wouldn't it be better to call it the Open Technology >> Platform? The same initials can be used, but the understanding would be >> that the platform would be a general purpose library (which it is) useful >> for many endeavors, not just writing a phone switch. >> >> Sure it might seem trivial but any marketing guy will tell you, naming is >> sometimes everything. So am I nuts here? >> >> >> *Robert Simmons Jr. MSc.* -- Sina Samavati Software engineer https://github.com/s1n4 https://twitter.com/sinasamavati From ok@REDACTED Thu Feb 13 00:22:10 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 13 Feb 2014 12:22:10 +1300 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <52FBFC07.8010007@ninenines.eu> References: <52FBFC07.8010007@ninenines.eu> Message-ID: On 13/02/2014, at 11:56 AM, Lo?c Hoguin wrote: > > The same situation exists with many other names. Few can tell you what SMTP, IMAP, HTTP, REST, SOAP, HTML, XML, JPEG, PNG and others stand for without looking it up and not making a mistake or three. Let's try. Simple Mail Transport Protocol Internet Message Access Protocol HyperText Transfer Protocol REpresentational State Transfer Simple Object Access Protocol to be honest, my first thought was Symbolic Optimal Assembly Program, but I don't suppose many people use IBM 650s these days. HyperText Markup Language eXtensible Markup Language Joint Photographic Experts Group Portable Network Graphics How did I do? (Really no lookup.) One reason it's worth knowing what the acronyms stand for is that they can stand for different things. It could be embarrassing to speak critically of XML to someone and then discover that they think it means "X-Men Legends". Or to speak about membership in the ACM and learn that they're thinking of the Academy of Country Music. A discussion of SOAP when one person is thinking "grotesque abuse of XML" and the other is thinking "cute assembler for strange old machine" is not going to be fruitful. OTP could be One Time Pad, Open Trading Protocol, Outline Test Plan, or any of an number of other things relatable to Erlang (and more that aren't). "We're using OTP to implement OTP using an OTP for authentication; here's our OTP for it." From hugo@REDACTED Thu Feb 13 09:12:50 2014 From: hugo@REDACTED (Hugo Mills) Date: Thu, 13 Feb 2014 08:12:50 +0000 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> Message-ID: <20140213081250.GT6490@carfax.org.uk> On Thu, Feb 13, 2014 at 12:22:10PM +1300, Richard A. O'Keefe wrote: > > On 13/02/2014, at 11:56 AM, Lo?c Hoguin wrote: > > > > > The same situation exists with many other names. Few can tell you what SMTP, IMAP, HTTP, REST, SOAP, HTML, XML, JPEG, PNG and others stand for without looking it up and not making a mistake or three. > > Let's try. > > Simple Mail Transport Protocol > Internet Message Access Protocol > HyperText Transfer Protocol > REpresentational State Transfer > Simple Object Access Protocol > to be honest, my first thought was > Symbolic Optimal Assembly Program, > but I don't suppose many people use IBM 650s > these days. Officially, it's just "SOAP" these days. It was originally from the phrase above, but they decided to keep the acronym and drop the underlying words, because it's not simple and it's not about object access. > HyperText Markup Language > eXtensible Markup Language > Joint Photographic Experts Group > Portable Network Graphics > > How did I do? (Really no lookup.) Good. 8.5/9 :) Hugo. -- === Hugo Mills: hugo@REDACTED carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- The makers of Steinway pianos would like me to tell you that --- this is a Bechstein. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 811 bytes Desc: Digital signature URL: From ph@REDACTED Thu Feb 13 09:13:12 2014 From: ph@REDACTED (Pieter Hintjens) Date: Thu, 13 Feb 2014 09:13:12 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> Message-ID: Garrett's video deserves an nomination for... something. I think we stopped naming languages with acronyms around 1968, and even then switched to mixed case for the survivors. Only aliens still use letters for language names (C#, F#, etc.) It's confusing to laymen what the difference is between Erlang and OTP. One imagines Ruby and Rails, except it's not that. I think the simplest plausible solution is to (a) stop using OTP as a confusing and needless synonym for Erlang, (b) create new layers on top that can have sexier names. -Pieter On Thu, Feb 13, 2014 at 12:22 AM, Richard A. O'Keefe wrote: > > On 13/02/2014, at 11:56 AM, Lo?c Hoguin wrote: > >> >> The same situation exists with many other names. Few can tell you what SMTP, IMAP, HTTP, REST, SOAP, HTML, XML, JPEG, PNG and others stand for without looking it up and not making a mistake or three. > > Let's try. > > Simple Mail Transport Protocol > Internet Message Access Protocol > HyperText Transfer Protocol > REpresentational State Transfer > Simple Object Access Protocol > to be honest, my first thought was > Symbolic Optimal Assembly Program, > but I don't suppose many people use IBM 650s > these days. > HyperText Markup Language > eXtensible Markup Language > Joint Photographic Experts Group > Portable Network Graphics > > How did I do? (Really no lookup.) > > One reason it's worth knowing what the acronyms stand > for is that they can stand for different things. It > could be embarrassing to speak critically of XML to > someone and then discover that they think it means > "X-Men Legends". Or to speak about membership in the > ACM and learn that they're thinking of the Academy of > Country Music. A discussion of SOAP when one person > is thinking "grotesque abuse of XML" and the other is > thinking "cute assembler for strange old machine" is > not going to be fruitful. > > OTP could be One Time Pad, Open Trading Protocol, > Outline Test Plan, or any of an number of other things > relatable to Erlang (and more that aren't). > "We're using OTP to implement OTP using an OTP for > authentication; here's our OTP for it." > > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From essen@REDACTED Thu Feb 13 09:46:34 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 13 Feb 2014 09:46:34 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> Message-ID: <52FC866A.1060906@ninenines.eu> On 02/13/2014 09:13 AM, Pieter Hintjens wrote: > I think we stopped naming languages with acronyms around 1968, and > even then switched to mixed case for the survivors. Only aliens still > use letters for language names (C#, F#, etc.) What about numbers? Go for example. > It's confusing to laymen what the difference is between Erlang and > OTP. One imagines Ruby and Rails, except it's not that. > > I think the simplest plausible solution is to (a) stop using OTP as a > confusing and needless synonym for Erlang, (b) create new layers on > top that can have sexier names. You are indeed confused. :) Erlang and OTP are pretty much what Ruby and Rails are, except OTP is a different kind of framework. You could run Erlang without OTP, or replacing it, except you don't win anything from doing that, unlike when you run Ruby on Rails without Ruby and Rails. -- Lo?c Hoguin http://ninenines.eu From n.oxyde@REDACTED Thu Feb 13 09:53:57 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 13 Feb 2014 09:53:57 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> Message-ID: Let?s also rename BEAM, because who needs a well-established name? Oh nevermind, the hipster renaming police already handled that one. Also while at it, let?s rename Erlang! Or not. -- Anthony Ramine Le 13 f?vr. 2014 ? 09:13, Pieter Hintjens a ?crit : > I think the simplest plausible solution is to (a) stop using OTP as a > confusing and needless synonym for Erlang, (b) create new layers on > top that can have sexier names. From ivan@REDACTED Thu Feb 13 09:54:40 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Thu, 13 Feb 2014 08:54:40 +0000 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> Message-ID: <52FC8850.2000902@llaisdy.com> On 13/02/2014 08:13, Pieter Hintjens wrote: > ... (a) stop using OTP as a > confusing and needless synonym for Erlang, ... Is that what OTP is used as? I thought OTP was a set (or framework, or platform) of libraries (behaviours, supervision, etc.) that facilitate the development of highly scalable and reliable applications (telecoms-grade scalability and reliability you might say). AFAIK it's open-source. Yes, let's rename it to something that more closely reflects what it really is. How about the "Open-source Telecoms-grade reliability and scalability Platform"? Ivan -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From vladdu55@REDACTED Thu Feb 13 10:34:59 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 13 Feb 2014 10:34:59 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <52FB2C0E.90008@erlang.org> References: <52F4C173.8050408@erlang.org> <1391790979.26271.YahooMailNeo@web140106.mail.bf1.yahoo.com> <49EC93AB-69A4-49AB-A2C0-4DA9F418E3F6@gmail.com> <58912684E2630B45963406CF7D8C52581C3473C6@ESESSMB103.ericsson.se> <52FB2C0E.90008@erlang.org> Message-ID: Hi! A couple of more questions about versins: - how can we find the otp_version without starting erlang? otp_release is in the start scripts, but I can't find anywhere "17.0-rc1"... - is 17.0.0 the same as 17.0? Is it a problem to use the extra ".0"? regards, Vlad On Wed, Feb 12, 2014 at 9:08 AM, Andreas Schumacher wrote: > From the versioning clarification mail that I sent on behalf of the OTP team > to the list on February 7: > > > "The new version scheme is *not* semantic versioning; although, it has been > inspired by it. We do not want to use semantic versioning (as defined by > http://semver.org/) out of the box since it does not fit our needs." > > Andreas Schumacher > Erlang/OTP, Ericsson AB > >> >> -----Original Message----- >> From: erlang-questions-bounces@REDACTED >> [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Anthony Ramine >> Sent: den 12 februari 2014 02:48 >> To: Rickard Green >> Cc: erlang-questions@REDACTED >> Subject: Re: [erlang-questions] Version numbering scheme change and the >> implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. >> >> So OTP won't follow semantic versioning, right? >> >> Just seeking confirmation about semver. >> >> Regards, >> >> -- >> Anthony Ramine >> >> Le 12 f?vr. 2014 ? 00:43, Rickard Green a ?crit : >> >>> As of OTP 17 we drop this patch level number sequence and start using >>> one set of patch level numbers per release. The patch level is not >>> expressed as an integer as it used to be, but instead as a version >>> number ..[. ...], for example, 17.0.1. This way the patch >>> level gives you a bit more information. You can for example see >>> directly which OTP release it applies to. This patch level version >>> number also replace the - tar-ball naming scheme. >> >> _______________________________________________ >> 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 n.oxyde@REDACTED Thu Feb 13 10:44:11 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 13 Feb 2014 10:44:11 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <52FB2C0E.90008@erlang.org> References: <52F4C173.8050408@erlang.org> <1391790979.26271.YahooMailNeo@web140106.mail.bf1.yahoo.com> <49EC93AB-69A4-49AB-A2C0-4DA9F418E3F6@gmail.com> <58912684E2630B45963406CF7D8C52581C3473C6@ESESSMB103.ericsson.se> <52FB2C0E.90008@erlang.org> Message-ID: <4C427930-EBE9-413D-946A-D2466DCB828E@gmail.com> My bad, missed that one. -- Anthony Ramine Le 12 f?vr. 2014 ? 09:08, Andreas Schumacher a ?crit : > From the versioning clarification mail that I sent on behalf of the OTP team to the list on February 7: From g@REDACTED Thu Feb 13 10:51:26 2014 From: g@REDACTED (Garrett Smith) Date: Thu, 13 Feb 2014 03:51:26 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <52FC8850.2000902@llaisdy.com> References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> Message-ID: Sigh. This *is* confusing. It just is. Lo?c you *cannot* use Erlang without OTP. The VM starts a system, which consists of applications, which are supervisory trees of gen_servers. Supervisors are gen_servers btw. If you think OTP is optional, look at the first two lines of kernel.erl: -module(kernel). -behaviour(supervisor). Historically, OTP libraries came after Erlang the language, of course, but this so called OTP "framework" is now endemic to Erlang. What sucks IMO is that OTP is treated as "advanced" by the community and by book authors. I understand the history of this, but there's a cost: programmers delay learning core Erlang principles of *applications* -- i.e. supervisor trees -- because it's not taught up. It's also incredibly complicated, if you don't use e2. The irony is that *advanced* Erlang programmers can get away programming outside the OTP guard rails. Beginners should not even consider doing this until they understand why OTP works and why they should deviate. e2 helps, a lot. The whole point of e2 is to simplify the correct use of OTP -- letting programmers *start* with applications, supervisors and gen_servers (in e2 they're called services and tasks -- simple huh). I know it's controversial, but it's controversial to those who have been teaching Erlang while this stuff was being baked. I don't run into new learners who object to starting with OTP using e2 (though maybe they're just being polite -- if you're out there and had problems learning with e2, please drop me a line, or yell at me here). I agree wholeheartedly with Pieter. It's just Erlang. Keeping the term OTP is a historic vestige. We're used to it, but it's a dead weight that adds only confusion. The Ruby / Rails comparison is not accurate. It's more like Rails 1.0 / Rails 2.0. Sadly though, I just don't see "OTP" going away because there's a trickle of noise from this list :| I make videos to cope. On Thu, Feb 13, 2014 at 2:54 AM, Ivan Uemlianin wrote: > On 13/02/2014 08:13, Pieter Hintjens wrote: >> >> ... (a) stop using OTP as a >> confusing and needless synonym for Erlang, ... > > > Is that what OTP is used as? I thought OTP was a set (or framework, or > platform) of libraries (behaviours, supervision, etc.) that facilitate the > development of highly scalable and reliable applications (telecoms-grade > scalability and reliability you might say). AFAIK it's open-source. > > Yes, let's rename it to something that more closely reflects what it really > is. How about the "Open-source Telecoms-grade reliability and scalability > Platform"? > > Ivan > > > -- > ============================================================ > Ivan A. Uemlianin PhD > Llaisdy > Speech Technology Research and Development > > ivan@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > github.com/llaisdy > www.linkedin.com/in/ivanuemlianin > > festina lente > ============================================================ > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ivan@REDACTED Thu Feb 13 10:59:43 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Thu, 13 Feb 2014 09:59:43 +0000 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> Message-ID: <52FC978F.7070303@llaisdy.com> On 13/02/2014 09:51, Garrett Smith wrote: > ... > What sucks IMO is that OTP is treated as "advanced" by the community > and by book authors. I understand the history of this, but there's a > cost: programmers delay learning core Erlang principles of > *applications* -- i.e. supervisor trees -- because it's not taught up. This I very much agree with. I think an Introduction to Erlang book that started with releases and applications would be a very good idea. > It's also incredibly complicated, if you don't use e2. http://e2project.org/ > > The irony is that *advanced* Erlang programmers can get away > programming outside the OTP guard rails. Beginners should not even > consider doing this until they understand why OTP works and why they > should deviate. > > e2 helps, a lot. > > The whole point of e2 is to simplify the correct use of OTP -- letting > programmers *start* with applications, supervisors and gen_servers (in > e2 they're called services and tasks -- simple huh). I know it's > controversial, but it's controversial to those who have been teaching > Erlang while this stuff was being baked. I don't run into new learners > who object to starting with OTP using e2 (though maybe they're just > being polite -- if you're out there and had problems learning with e2, > please drop me a line, or yell at me here). > > I agree wholeheartedly with Pieter. It's just Erlang. Keeping the term > OTP is a historic vestige. We're used to it, but it's a dead weight > that adds only confusion. > > The Ruby / Rails comparison is not accurate. It's more like Rails 1.0 > / Rails 2.0. > > Sadly though, I just don't see "OTP" going away because there's a > trickle of noise from this list :| > > I make videos to cope. > > On Thu, Feb 13, 2014 at 2:54 AM, Ivan Uemlianin wrote: >> On 13/02/2014 08:13, Pieter Hintjens wrote: >>> >>> ... (a) stop using OTP as a >>> confusing and needless synonym for Erlang, ... >> >> >> Is that what OTP is used as? I thought OTP was a set (or framework, or >> platform) of libraries (behaviours, supervision, etc.) that facilitate the >> development of highly scalable and reliable applications (telecoms-grade >> scalability and reliability you might say). AFAIK it's open-source. >> >> Yes, let's rename it to something that more closely reflects what it really >> is. How about the "Open-source Telecoms-grade reliability and scalability >> Platform"? >> >> Ivan >> >> >> -- >> ============================================================ >> Ivan A. Uemlianin PhD >> Llaisdy >> Speech Technology Research and Development >> >> ivan@REDACTED >> www.llaisdy.com >> llaisdy.wordpress.com >> github.com/llaisdy >> www.linkedin.com/in/ivanuemlianin >> >> festina lente >> ============================================================ >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From n.oxyde@REDACTED Thu Feb 13 11:42:09 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 13 Feb 2014 11:42:09 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> Message-ID: <21AD9393-44EF-4C42-A39D-B242D93ECEBE@gmail.com> Hello, Replied inline. Regards, -- Anthony Ramine Le 13 f?vr. 2014 ? 10:51, Garrett Smith a ?crit : > Sigh. This *is* confusing. It just is. > > Lo?c you *cannot* use Erlang without OTP. The VM starts a system, > which consists of applications, which are supervisory trees of > gen_servers. > > Supervisors are gen_servers btw. > > If you think OTP is optional, look at the first two lines of kernel.erl: > > -module(kernel). > -behaviour(supervisor). > > Historically, OTP libraries came after Erlang the language, of course, > but this so called OTP "framework" is now endemic to Erlang. You just proved it?s difficult to use Erlang without the stdlib. Erlang is still not OTP. In fact, the kernel module isn?t even a preloaded module, this means it is not a necessary thing to use Erlang. You could have your own Erlang/E2 if you wanted. > What sucks IMO is that OTP is treated as "advanced" by the community > and by book authors. I understand the history of this, but there's a > cost: programmers delay learning core Erlang principles of > *applications* -- i.e. supervisor trees -- because it's not taught up. > It's also incredibly complicated, if you don't use e2. > > The irony is that *advanced* Erlang programmers can get away > programming outside the OTP guard rails. Beginners should not even > consider doing this until they understand why OTP works and why they > should deviate. > > e2 helps, a lot. OTP is a set of building blocks for concurrent and distributed systems. Concurrency and distribution are advanced topics. Thus OTP is an advanced topic. > The whole point of e2 is to simplify the correct use of OTP -- letting > programmers *start* with applications, supervisors and gen_servers (in > e2 they're called services and tasks -- simple huh). I know it's > controversial, but it's controversial to those who have been teaching > Erlang while this stuff was being baked. I don't run into new learners > who object to starting with OTP using e2 (though maybe they're just > being polite -- if you're out there and had problems learning with e2, > please drop me a line, or yell at me here). e2 is a leaky abstraction which you need to deviate from when you need more complex stuff; let?s not add an infinity of layers on top of OTP. > I agree wholeheartedly with Pieter. It's just Erlang. Keeping the term > OTP is a historic vestige. We're used to it, but it's a dead weight > that adds only confusion. Erlang itself is dead weight to most in the industry, does that mean we should forgo Erlang altogether? > The Ruby / Rails comparison is not accurate. It's more like Rails 1.0 > / Rails 2.0. I have no idea how you would find this accurate. > Sadly though, I just don't see "OTP" going away because there's a > trickle of noise from this list :| How do you know there isn?t a silent majority who just doesn?t care or wouldn?t like the OTP team to spend time trying to rewrite history? That sounds quite a dismissal of the opposing opinion in this debate. In fact, I have to admit I wouldn?t have replied if not for that sentence. > I make videos to cope. I give value to historic facts and terminology to cope. From aaron.l.france@REDACTED Thu Feb 13 11:48:06 2014 From: aaron.l.france@REDACTED (Aaron France) Date: Thu, 13 Feb 2014 11:48:06 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <21AD9393-44EF-4C42-A39D-B242D93ECEBE@gmail.com> References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <21AD9393-44EF-4C42-A39D-B242D93ECEBE@gmail.com> Message-ID: <20140213104806.GD2928@xenocorp> This whole thread is a waste of time. What the hell has happened to this list? On Thu, Feb 13, 2014 at 11:42:09AM +0100, Anthony Ramine wrote: > Hello, > > Replied inline. > > Regards, > > -- > Anthony Ramine > > Le 13 f?vr. 2014 ? 10:51, Garrett Smith a ?crit : > > > Sigh. This *is* confusing. It just is. > > > > Lo?c you *cannot* use Erlang without OTP. The VM starts a system, > > which consists of applications, which are supervisory trees of > > gen_servers. > > > > Supervisors are gen_servers btw. > > > > If you think OTP is optional, look at the first two lines of kernel.erl: > > > > -module(kernel). > > -behaviour(supervisor). > > > > Historically, OTP libraries came after Erlang the language, of course, > > but this so called OTP "framework" is now endemic to Erlang. > > You just proved it?s difficult to use Erlang without the stdlib. Erlang is still not OTP. > > In fact, the kernel module isn?t even a preloaded module, this means it is not a necessary thing to use Erlang. You could have your own Erlang/E2 if you wanted. > > > What sucks IMO is that OTP is treated as "advanced" by the community > > and by book authors. I understand the history of this, but there's a > > cost: programmers delay learning core Erlang principles of > > *applications* -- i.e. supervisor trees -- because it's not taught up. > > It's also incredibly complicated, if you don't use e2. > > > > The irony is that *advanced* Erlang programmers can get away > > programming outside the OTP guard rails. Beginners should not even > > consider doing this until they understand why OTP works and why they > > should deviate. > > > > e2 helps, a lot. > > OTP is a set of building blocks for concurrent and distributed systems. > > Concurrency and distribution are advanced topics. > > Thus OTP is an advanced topic. > > > The whole point of e2 is to simplify the correct use of OTP -- letting > > programmers *start* with applications, supervisors and gen_servers (in > > e2 they're called services and tasks -- simple huh). I know it's > > controversial, but it's controversial to those who have been teaching > > Erlang while this stuff was being baked. I don't run into new learners > > who object to starting with OTP using e2 (though maybe they're just > > being polite -- if you're out there and had problems learning with e2, > > please drop me a line, or yell at me here). > > e2 is a leaky abstraction which you need to deviate from when you need more complex stuff; let?s not add an infinity of layers on top of OTP. > > > I agree wholeheartedly with Pieter. It's just Erlang. Keeping the term > > OTP is a historic vestige. We're used to it, but it's a dead weight > > that adds only confusion. > > Erlang itself is dead weight to most in the industry, does that mean we should forgo Erlang altogether? > > > The Ruby / Rails comparison is not accurate. It's more like Rails 1.0 > > / Rails 2.0. > > I have no idea how you would find this accurate. > > > Sadly though, I just don't see "OTP" going away because there's a > > trickle of noise from this list :| > > How do you know there isn?t a silent majority who just doesn?t care or wouldn?t like the OTP team to spend time trying to rewrite history? That sounds quite a dismissal of the opposing opinion in this debate. In fact, I have to admit I wouldn?t have replied if not for that sentence. > > > I make videos to cope. > > I give value to historic facts and terminology to cope. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From essen@REDACTED Thu Feb 13 12:01:33 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 13 Feb 2014 12:01:33 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> Message-ID: <52FCA60D.9020904@ninenines.eu> No I'm serious, you can use Erlang without OTP. When the VM starts it loads the boot file which contains instructions on what modules to preload, what applications to start and so on. Make an empty boot file and look at what happens, most likely it will complain about the lists module missing. Then add your own lists module and try again. It will also complain about no error logger being present. Etc. When the VM starts it creates process 0 that calls otp_ring0:start/2; don't let the name fool you, it's just an Erlang function that calls init:boot, which is the code that loads the boot file. The normal boot file then sets paths, loads all modules from kernel and stdlib and starts three additional processes: heart, error_logger and application_controller. But you don't actually need those. The smallest boot script, that literally only loads the boot file and then sits there doing nothing, is this: {script, {"Not OTP","1.2.3"}, [{path,["."]}, {primLoad, [lists]}]}. As you can see I only add "." to the paths to load beam files from, and that's where I put my lists module. This module could very well have been one I wrote myself, and it could literally contain only the functions required, but for the sake of the example I just took the one from my install. It's interesting because if you really want to you can have a very minimal VM that starts really fast (as has been proposed a few times to make rebar a little faster). Because the VM *does* starts *really* fast. % time erl -boot test -run init stop erl -boot test -run init stop 0.02s user 0.00s system 92% cpu 0.022 total You could also create your own framework and use it instead of OTP. Even better, you could do something like Wayland is doing with Xorg, have your own framework be started as the "master" and then make it start OTP and make them run side by side. It's only an interesting thought, of course, because it would take an immense amount of time to get it as reliable as OTP. On 02/13/2014 10:51 AM, Garrett Smith wrote: > Sigh. This *is* confusing. It just is. > > Lo?c you *cannot* use Erlang without OTP. The VM starts a system, > which consists of applications, which are supervisory trees of > gen_servers. > > Supervisors are gen_servers btw. > > If you think OTP is optional, look at the first two lines of kernel.erl: > > -module(kernel). > -behaviour(supervisor). > > Historically, OTP libraries came after Erlang the language, of course, > but this so called OTP "framework" is now endemic to Erlang. > > What sucks IMO is that OTP is treated as "advanced" by the community > and by book authors. I understand the history of this, but there's a > cost: programmers delay learning core Erlang principles of > *applications* -- i.e. supervisor trees -- because it's not taught up. > It's also incredibly complicated, if you don't use e2. > > The irony is that *advanced* Erlang programmers can get away > programming outside the OTP guard rails. Beginners should not even > consider doing this until they understand why OTP works and why they > should deviate. > > e2 helps, a lot. > > The whole point of e2 is to simplify the correct use of OTP -- letting > programmers *start* with applications, supervisors and gen_servers (in > e2 they're called services and tasks -- simple huh). I know it's > controversial, but it's controversial to those who have been teaching > Erlang while this stuff was being baked. I don't run into new learners > who object to starting with OTP using e2 (though maybe they're just > being polite -- if you're out there and had problems learning with e2, > please drop me a line, or yell at me here). > > I agree wholeheartedly with Pieter. It's just Erlang. Keeping the term > OTP is a historic vestige. We're used to it, but it's a dead weight > that adds only confusion. > > The Ruby / Rails comparison is not accurate. It's more like Rails 1.0 > / Rails 2.0. > > Sadly though, I just don't see "OTP" going away because there's a > trickle of noise from this list :| > > I make videos to cope. > > On Thu, Feb 13, 2014 at 2:54 AM, Ivan Uemlianin wrote: >> On 13/02/2014 08:13, Pieter Hintjens wrote: >>> >>> ... (a) stop using OTP as a >>> confusing and needless synonym for Erlang, ... >> >> >> Is that what OTP is used as? I thought OTP was a set (or framework, or >> platform) of libraries (behaviours, supervision, etc.) that facilitate the >> development of highly scalable and reliable applications (telecoms-grade >> scalability and reliability you might say). AFAIK it's open-source. >> >> Yes, let's rename it to something that more closely reflects what it really >> is. How about the "Open-source Telecoms-grade reliability and scalability >> Platform"? >> >> Ivan >> >> >> -- >> ============================================================ >> Ivan A. Uemlianin PhD >> Llaisdy >> Speech Technology Research and Development >> >> ivan@REDACTED >> www.llaisdy.com >> llaisdy.wordpress.com >> github.com/llaisdy >> www.linkedin.com/in/ivanuemlianin >> >> festina lente >> ============================================================ >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -- Lo?c Hoguin http://ninenines.eu From essen@REDACTED Thu Feb 13 12:03:49 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 13 Feb 2014 12:03:49 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <52FCA60D.9020904@ninenines.eu> References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> Message-ID: <52FCA695.7060106@ninenines.eu> Oops, one small fix. On 02/13/2014 12:01 PM, Lo?c Hoguin wrote: > No I'm serious, you can use Erlang without OTP. When the VM starts it > loads the boot file which contains instructions on what modules to > preload, what applications to start and so on. Make an empty boot file ^^^^^^^ I meant *load*. The VM will have a few modules preloaded regardless of the boot file. > and look at what happens, most likely it will complain about the lists > module missing. Then add your own lists module and try again. It will > also complain about no error logger being present. Etc. > > When the VM starts it creates process 0 that calls otp_ring0:start/2; > don't let the name fool you, it's just an Erlang function that calls > init:boot, which is the code that loads the boot file. The normal boot > file then sets paths, loads all modules from kernel and stdlib and > starts three additional processes: heart, error_logger and > application_controller. But you don't actually need those. > > The smallest boot script, that literally only loads the boot file and > then sits there doing nothing, is this: > > {script, {"Not OTP","1.2.3"}, [{path,["."]}, {primLoad, [lists]}]}. > > As you can see I only add "." to the paths to load beam files from, and > that's where I put my lists module. This module could very well have > been one I wrote myself, and it could literally contain only the > functions required, but for the sake of the example I just took the one > from my install. > > It's interesting because if you really want to you can have a very > minimal VM that starts really fast (as has been proposed a few times to > make rebar a little faster). Because the VM *does* starts *really* fast. > > % time erl -boot test -run init stop > erl -boot test -run init stop 0.02s user 0.00s system 92% cpu 0.022 total > > You could also create your own framework and use it instead of OTP. Even > better, you could do something like Wayland is doing with Xorg, have > your own framework be started as the "master" and then make it start OTP > and make them run side by side. > > It's only an interesting thought, of course, because it would take an > immense amount of time to get it as reliable as OTP. > > On 02/13/2014 10:51 AM, Garrett Smith wrote: >> Sigh. This *is* confusing. It just is. >> >> Lo?c you *cannot* use Erlang without OTP. The VM starts a system, >> which consists of applications, which are supervisory trees of >> gen_servers. >> >> Supervisors are gen_servers btw. >> >> If you think OTP is optional, look at the first two lines of kernel.erl: >> >> -module(kernel). >> -behaviour(supervisor). >> >> Historically, OTP libraries came after Erlang the language, of course, >> but this so called OTP "framework" is now endemic to Erlang. >> >> What sucks IMO is that OTP is treated as "advanced" by the community >> and by book authors. I understand the history of this, but there's a >> cost: programmers delay learning core Erlang principles of >> *applications* -- i.e. supervisor trees -- because it's not taught up. >> It's also incredibly complicated, if you don't use e2. >> >> The irony is that *advanced* Erlang programmers can get away >> programming outside the OTP guard rails. Beginners should not even >> consider doing this until they understand why OTP works and why they >> should deviate. >> >> e2 helps, a lot. >> >> The whole point of e2 is to simplify the correct use of OTP -- letting >> programmers *start* with applications, supervisors and gen_servers (in >> e2 they're called services and tasks -- simple huh). I know it's >> controversial, but it's controversial to those who have been teaching >> Erlang while this stuff was being baked. I don't run into new learners >> who object to starting with OTP using e2 (though maybe they're just >> being polite -- if you're out there and had problems learning with e2, >> please drop me a line, or yell at me here). >> >> I agree wholeheartedly with Pieter. It's just Erlang. Keeping the term >> OTP is a historic vestige. We're used to it, but it's a dead weight >> that adds only confusion. >> >> The Ruby / Rails comparison is not accurate. It's more like Rails 1.0 >> / Rails 2.0. >> >> Sadly though, I just don't see "OTP" going away because there's a >> trickle of noise from this list :| >> >> I make videos to cope. >> >> On Thu, Feb 13, 2014 at 2:54 AM, Ivan Uemlianin wrote: >>> On 13/02/2014 08:13, Pieter Hintjens wrote: >>>> >>>> ... (a) stop using OTP as a >>>> confusing and needless synonym for Erlang, ... >>> >>> >>> Is that what OTP is used as? I thought OTP was a set (or framework, or >>> platform) of libraries (behaviours, supervision, etc.) that >>> facilitate the >>> development of highly scalable and reliable applications (telecoms-grade >>> scalability and reliability you might say). AFAIK it's open-source. >>> >>> Yes, let's rename it to something that more closely reflects what it >>> really >>> is. How about the "Open-source Telecoms-grade reliability and >>> scalability >>> Platform"? >>> >>> Ivan >>> >>> >>> -- >>> ============================================================ >>> Ivan A. Uemlianin PhD >>> Llaisdy >>> Speech Technology Research and Development >>> >>> ivan@REDACTED >>> www.llaisdy.com >>> llaisdy.wordpress.com >>> github.com/llaisdy >>> www.linkedin.com/in/ivanuemlianin >>> >>> festina lente >>> ============================================================ >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From bchesneau@REDACTED Thu Feb 13 12:55:28 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Thu, 13 Feb 2014 12:55:28 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <52FCA60D.9020904@ninenines.eu> References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> Message-ID: On Thu, Feb 13, 2014 at 12:01 PM, Lo?c Hoguin wrote: > No I'm serious, you can use Erlang without OTP. maybe but who is doing it today? Or rather what are the selling points of just using Erlang without OTP? - benoit From valentin@REDACTED Thu Feb 13 12:56:15 2014 From: valentin@REDACTED (Valentin Micic) Date: Thu, 13 Feb 2014 13:56:15 +0200 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <52FC8850.2000902@llaisdy.com> References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> Message-ID: <24566921-E935-4854-AE6F-F13257703551@pixie.co.za> > > Yes, let's rename it to something that more closely reflects what it really is. How about the "Open-source Telecoms-grade reliability and scalability Platform"? "? That Will Reward You Greatly If You Know What You're Doing. Also It May Be Used To Drive Kids To School One Day, But Hey, Hold That Thought As We Don't Need It Today" From essen@REDACTED Thu Feb 13 13:05:00 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 13 Feb 2014 13:05:00 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> Message-ID: <52FCB4EC.8050209@ninenines.eu> On 02/13/2014 12:55 PM, Benoit Chesneau wrote: > On Thu, Feb 13, 2014 at 12:01 PM, Lo?c Hoguin wrote: >> No I'm serious, you can use Erlang without OTP. > > maybe but who is doing it today? Or rather what are the selling points > of just using Erlang without OTP? I believe I answered that in the conclusion to my email. Nobody does it today because it would take an immense amount of time and effort to essentially replicate OTP. But if I wanted to, for example, create a new concurrent language on top of the BEAM VM, that's exactly what I would do, as cleaning up the many inconsistencies in the API would definitely be worth the effort. Otherwise it's just a different syntax for Erlang. Or if I wanted to use Erlang for writing small administration scripts that's probably also what I would do, as the fast boot is a really important feature there. I'm sure you can come up with other ideas where doing that would be interesting. -- Lo?c Hoguin http://ninenines.eu From thomasl_erlang@REDACTED Thu Feb 13 13:11:04 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Thu, 13 Feb 2014 04:11:04 -0800 (PST) Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <52FC978F.7070303@llaisdy.com> References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FC978F.7070303@llaisdy.com> Message-ID: <1392293464.83809.YahooMailNeo@web140106.mail.bf1.yahoo.com> Regarding teaching erlang/OTP, I think this one is nice:? http://www.amazon.com/Erlang-OTP-Action-Martin-Logan/dp/1933988789/ref=sr_1_1?s=books&ie=UTF8&qid=1392292179&sr=1-1 Diving into OTP is a bit messy, but in the larger scheme of things it doesn't make sense to hide one of the main features of practical erlang programming. (I wouldn't mind a more elegant OTP on the other hand, but we're getting there.) By the way, since you mention e2, here's a little project to fast-forward the simple uses of applications and supervisors:?https://github.com/thomasl/gen_app Example: gen_app:app_sup(testapp, [{sup, my_sup}]). This starts a (dynamic) application testapp running a supervisor my_sup without children. You can also easily start more complex things like supervisor trees with various strategies, including the classic supervised gen_server, and much more. Note that what's often a couple of boilerplate modules are replaced by a few lines.? I'm currently debugging, pondering the API and looking at how to specify more complex cases like the ssl application in this framework. (PS. You will probably have to massage the Makefile a little bit to build, sorry. See the link for more.) Best, Thomas On Thursday, February 13, 2014 11:00 AM, Ivan Uemlianin wrote: On 13/02/2014 09:51, Garrett Smith wrote: >> ... >> What sucks IMO is that OTP is treated as "advanced" by the community >> and by book authors. I understand the history of this, but there's a >> cost: programmers delay learning core Erlang principles of >> *applications* -- i.e. supervisor trees -- because it's not taught up. > >This I very much agree with.? I think an Introduction to Erlang book >that started with releases and applications would be a very good idea. > >> It's also incredibly complicated, if you don't use e2. > >http://e2project.org/ > > >> >> The irony is that *advanced* Erlang programmers can get away >> programming outside the OTP guard rails. Beginners should not even >> consider doing this until they understand why OTP works and why they >> should deviate. >> >> e2 helps, a lot. >> >> The whole point of e2 is to simplify the correct use of OTP -- letting >> programmers *start* with applications, supervisors and gen_servers (in >> e2 they're called services and tasks -- simple huh). I know it's >> controversial, but it's controversial to those who have been teaching >> Erlang while this stuff was being baked. I don't run into new learners >> who object to starting with OTP using e2 (though maybe they're just >> being polite -- if you're out there and had problems learning with e2, >> please drop me a line, or yell at me here). >> >> I agree wholeheartedly with Pieter. It's just Erlang. Keeping the term >> OTP is a historic vestige. We're used to it, but it's a dead weight >> that adds only confusion. >> >> The Ruby / Rails comparison is not accurate. It's more like Rails 1.0 >> / Rails 2.0. >> >> Sadly though, I just don't see "OTP" going away because there's a >> trickle of noise from this list :| >> >> I make videos to cope. >> >> On Thu, Feb 13, 2014 at 2:54 AM, Ivan Uemlianin wrote: >>> On 13/02/2014 08:13, Pieter Hintjens wrote: >>>> >>>> ... (a) stop using OTP as a >>>> confusing and needless synonym for Erlang, ... >>> >>> >>> Is that what OTP is used as?? I thought OTP was a set (or framework, or >>> platform) of libraries (behaviours, supervision, etc.) that facilitate the >>> development of highly scalable and reliable applications (telecoms-grade >>> scalability and reliability you might say).? AFAIK it's open-source. >>> >>> Yes, let's rename it to something that more closely reflects what it really >>> is.? How about the "Open-source Telecoms-grade reliability and scalability >>> Platform"? >>> >>> Ivan >>> >>> >>> -- >>> ============================================================ >>> Ivan A. Uemlianin PhD >>> Llaisdy >>> Speech Technology Research and Development >>> >>>? ? ? ? ? ? ? ? ? ? ? ivan@REDACTED >>>? ? ? ? ? ? ? ? ? ? ? www.llaisdy.com >>>? ? ? ? ? ? ? ? ? ? ? ? ? llaisdy.wordpress.com >>>? ? ? ? ? ? ? ? github.com/llaisdy >>>? ? ? ? ? ? ? ? ? ? ? www.linkedin.com/in/ivanuemlianin >>> >>>? ? ? ? ? ? ? ? ? ? ? ? ? festina lente >>> ============================================================ >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions > > >-- >============================================================ >Ivan A. Uemlianin PhD >Llaisdy >Speech Technology Research and Development > >? ? ? ? ? ? ? ? ? ? ivan@REDACTED >? ? ? ? ? ? ? ? ? ? ? www.llaisdy.com >? ? ? ? ? ? ? ? ? ? ? ? ? llaisdy.wordpress.com >? ? ? ? ? ? ? github.com/llaisdy >? ? ? ? ? ? ? ? ? ? ? www.linkedin.com/in/ivanuemlianin > >? ? ? ? ? ? ? ? ? ? ? ? festina lente >============================================================ >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Thu Feb 13 13:12:53 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 13 Feb 2014 13:12:53 +0100 Subject: [erlang-questions] beginner: xmerl:export_simple/2 wihtout changing > into > Message-ID: <1392293573.4863.11.camel@sekic1152.release> Greetings, Is there a way to tell xmerl:export_simple/2 that I do not want to replace ">" with ">"? To generate HTML I use xmerl:export_simple( [{html, [], [Body]}], xmerl_xml ). where Body is {body, [], ["Some text with >"]} I need ">" in Body to remain ">". Is there some way to express this to xmerl? bengt From gordon@REDACTED Thu Feb 13 13:15:15 2014 From: gordon@REDACTED (Gordon Guthrie) Date: Thu, 13 Feb 2014 12:15:15 +0000 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <1392293464.83809.YahooMailNeo@web140106.mail.bf1.yahoo.com> References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FC978F.7070303@llaisdy.com> <1392293464.83809.YahooMailNeo@web140106.mail.bf1.yahoo.com> Message-ID: Personally, I go the Gnu/Linux way and try and always say Erlang/OTP and avoid saying Erlang. On 13 Feb 2014 12:11, "Thomas Lindgren" wrote: > Regarding teaching erlang/OTP, I think this one is nice: > > > http://www.amazon.com/Erlang-OTP-Action-Martin-Logan/dp/1933988789/ref=sr_1_1?s=books&ie=UTF8&qid=1392292179&sr=1-1 > > Diving into OTP is a bit messy, but in the larger scheme of things it > doesn't make sense to hide one of the main features of practical erlang > programming. (I wouldn't mind a more elegant OTP on the other hand, but > we're getting there.) > > By the way, since you mention e2, here's a little project to fast-forward > the simple uses of applications and supervisors: > https://github.com/thomasl/gen_app > > Example: > > gen_app:app_sup(testapp, [{sup, my_sup}]). > > This starts a (dynamic) application testapp running a supervisor my_supwithout children. You can also easily start more complex things like > supervisor trees with various strategies, including the classic supervised > gen_server, and much more. Note that what's often a couple of boilerplate > modules are replaced by a few lines. > > I'm currently debugging, pondering the API and looking at how to specify > more complex cases like the ssl application in this framework. > > (PS. You will probably have to massage the Makefile a little bit to build, > sorry. See the link for more.) > > Best, > Thomas > > > On Thursday, February 13, 2014 11:00 AM, Ivan Uemlianin < > ivan@REDACTED> wrote: > > On 13/02/2014 09:51, Garrett Smith wrote: > > ... > > What sucks IMO is that OTP is treated as "advanced" by the community > > and by book authors. I understand the history of this, but there's a > > cost: programmers delay learning core Erlang principles of > > *applications* -- i.e. supervisor trees -- because it's not taught up. > > This I very much agree with. I think an Introduction to Erlang book > that started with releases and applications would be a very good idea. > > > It's also incredibly complicated, if you don't use e2. > > http://e2project.org/ > > > > > > The irony is that *advanced* Erlang programmers can get away > > programming outside the OTP guard rails. Beginners should not even > > consider doing this until they understand why OTP works and why they > > should deviate. > > > > e2 helps, a lot. > > > > The whole point of e2 is to simplify the correct use of OTP -- letting > > programmers *start* with applications, supervisors and gen_servers (in > > e2 they're called services and tasks -- simple huh). I know it's > > controversial, but it's controversial to those who have been teaching > > Erlang while this stuff was being baked. I don't run into new learners > > who object to starting with OTP using e2 (though maybe they're just > > being polite -- if you're out there and had problems learning with e2, > > please drop me a line, or yell at me here). > > > > I agree wholeheartedly with Pieter. It's just Erlang. Keeping the term > > OTP is a historic vestige. We're used to it, but it's a dead weight > > that adds only confusion. > > > > The Ruby / Rails comparison is not accurate. It's more like Rails 1.0 > > / Rails 2.0. > > > > Sadly though, I just don't see "OTP" going away because there's a > > trickle of noise from this list :| > > > > I make videos to cope. > > > > On Thu, Feb 13, 2014 at 2:54 AM, Ivan Uemlianin > wrote: > >> On 13/02/2014 08:13, Pieter Hintjens wrote: > >>> > >>> ... (a) stop using OTP as a > >>> confusing and needless synonym for Erlang, ... > >> > >> > >> Is that what OTP is used as? I thought OTP was a set (or framework, or > >> platform) of libraries (behaviours, supervision, etc.) that facilitate > the > >> development of highly scalable and reliable applications (telecoms-grade > >> scalability and reliability you might say). AFAIK it's open-source. > >> > >> Yes, let's rename it to something that more closely reflects what it > really > >> is. How about the "Open-source Telecoms-grade reliability and > scalability > >> Platform"? > >> > >> Ivan > >> > >> > >> -- > >> ============================================================ > >> Ivan A. Uemlianin PhD > >> Llaisdy > >> Speech Technology Research and Development > >> > >> ivan@REDACTED > >> www.llaisdy.com > >> llaisdy.wordpress.com > >> github.com/llaisdy > >> www.linkedin.com/in/ivanuemlianin > >> > >> festina lente > >> ============================================================ > >> > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > > > -- > ============================================================ > Ivan A. Uemlianin PhD > Llaisdy > Speech Technology Research and Development > > ivan@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > github.com/llaisdy > www.linkedin.com/in/ivanuemlianin > > festina lente > ============================================================ > _______________________________________________ > 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 Thu Feb 13 13:20:41 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 13 Feb 2014 13:20:41 +0100 Subject: [erlang-questions] beginner: xmerl:export_simple/2 wihtout changing > into > In-Reply-To: <1392293573.4863.11.camel@sekic1152.release> References: <1392293573.4863.11.camel@sekic1152.release> Message-ID: <8565445F-D95D-4847-8755-DEC519F0603F@gmail.com> No. That would be invalid XML, not even well-formed, even. Why would an XML implementation allow you to generate ill-formed XML? -- Anthony Ramine Le 13 f?vr. 2014 ? 13:12, Bengt Kleberg a ?crit : > Greetings, > > Is there a way to tell xmerl:export_simple/2 that I do not want to > replace ">" with ">"? > > To generate HTML I use > xmerl:export_simple( [{html, [], [Body]}], xmerl_xml ). > where Body is {body, [], ["Some text with >"]} > > I need ">" in Body to remain ">". Is there some way to express this to > xmerl? > > > bengt > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bengt.kleberg@REDACTED Thu Feb 13 13:34:14 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 13 Feb 2014 13:34:14 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang Message-ID: <1392294854.4863.17.camel@sekic1152.release> Greetings, Is there an Erlang library that allows me to generate HTML from Erlang and that can stop ">" from turning into ">"? Previously I used xmerl:export_simple( [{html, [], [Body]}], xmerl_xml ). where Body could be {body, [], ["Some text with >"]}. xmerl will transform ">" into ">", but until now the HTML has worked well. Now I need to keep ">". bengt From n.oxyde@REDACTED Thu Feb 13 13:38:14 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 13 Feb 2014 13:38:14 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <1392294854.4863.17.camel@sekic1152.release> References: <1392294854.4863.17.camel@sekic1152.release> Message-ID: <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> Why do you want to do that? An HTML document with a single ? > ? in the middle of nowhere is not valid nor well-formed HTML. Why would an HTML tool do that? -- Anthony Ramine Le 13 f?vr. 2014 ? 13:34, Bengt Kleberg a ?crit : > Greetings, > > Is there an Erlang library that allows me to generate HTML from Erlang > and that can stop ">" from turning into ">"? > > Previously I used > xmerl:export_simple( [{html, [], [Body]}], xmerl_xml ). > where Body could be {body, [], ["Some text with >"]}. > xmerl will transform ">" into ">", but until now the HTML has worked > well. > > Now I need to keep ">". > > > bengt > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bengt.kleberg@REDACTED Thu Feb 13 13:43:39 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 13 Feb 2014 13:43:39 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> Message-ID: <1392295419.4863.18.camel@sekic1152.release> Javascript wants ">" in the HTML page. On Thu, 2014-02-13 at 13:38 +0100, Anthony Ramine wrote: > Why do you want to do that? > > An HTML document with a single ? > ? in the middle of nowhere is not valid nor well-formed HTML. > > Why would an HTML tool do that? > From magnus@REDACTED Thu Feb 13 13:50:04 2014 From: magnus@REDACTED (Magnus Henoch) Date: Thu, 13 Feb 2014 12:50:04 +0000 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> (Anthony Ramine's message of "Thu, 13 Feb 2014 13:38:14 +0100") References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> Message-ID: Anthony Ramine writes: > Why do you want to do that? > > An HTML document with a single ? > ? in the middle of nowhere is not valid nor well-formed HTML. It is in fact valid HTML. Try pasting the following into http://validator.w3.org/#validate_by_input : This is > the title This is > the body A standalone greater-than sign is also valid in XML. Regards, Magnus From bengt.kleberg@REDACTED Thu Feb 13 13:55:52 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 13 Feb 2014 13:55:52 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> Message-ID: <1392296152.4863.22.camel@sekic1152.release> Greetings, If ">" is valid XML, my follow up question is if there is a way to use xmerl to generate XML with ">" in it? bengt On Thu, 2014-02-13 at 12:50 +0000, Magnus Henoch wrote: > Anthony Ramine writes: > > > Why do you want to do that? > > > > An HTML document with a single ? > ? in the middle of nowhere is not valid nor well-formed HTML. > > It is in fact valid HTML. Try pasting the following into > http://validator.w3.org/#validate_by_input : > > > This is > the title > This is > the body > > A standalone greater-than sign is also valid in XML. > > Regards, > Magnus From n.oxyde@REDACTED Thu Feb 13 13:59:15 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 13 Feb 2014 13:59:15 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> Message-ID: <62792D12-B0CC-49B0-9DC8-D6F796277152@gmail.com> Mmmmh, right. Was thinking about <. That being said, code consuming HTML or XML shouldn?t see a difference, and not escaping could also introduce other bugs, as ]]> is not supposed to appear in content (in XML). This leads us to the original question, which was ? why do you need to do this? ?. -- Anthony Ramine Le 13 f?vr. 2014 ? 13:50, Magnus Henoch a ?crit : > Anthony Ramine writes: > >> Why do you want to do that? >> >> An HTML document with a single ? > ? in the middle of nowhere is not valid nor well-formed HTML. > > It is in fact valid HTML. Try pasting the following into > http://validator.w3.org/#validate_by_input : > > > This is > the title > This is > the body > > A standalone greater-than sign is also valid in XML. > > Regards, > Magnus From n.oxyde@REDACTED Thu Feb 13 14:00:27 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 13 Feb 2014 14:00:27 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <1392296152.4863.22.camel@sekic1152.release> References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> <1392296152.4863.22.camel@sekic1152.release> Message-ID: <579D258C-F9BB-417E-9F58-0A9F3DA1AED7@gmail.com> You can patch xmerl (and make it still escape > if preceded by ]]). Or you can fix your javascript code. -- Anthony Ramine Le 13 f?vr. 2014 ? 13:55, Bengt Kleberg a ?crit : > Greetings, > > If ">" is valid XML, my follow up question is if there is a way to use > xmerl to generate XML with ">" in it? > > > bengt > > On Thu, 2014-02-13 at 12:50 +0000, Magnus Henoch wrote: >> Anthony Ramine writes: >> >>> Why do you want to do that? >>> >>> An HTML document with a single ? > ? in the middle of nowhere is not valid nor well-formed HTML. >> >> It is in fact valid HTML. Try pasting the following into >> http://validator.w3.org/#validate_by_input : >> >> >> This is > the title >> This is > the body >> >> A standalone greater-than sign is also valid in XML. >> >> Regards, >> Magnus > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From andrzej.sliwa@REDACTED Thu Feb 13 14:00:15 2014 From: andrzej.sliwa@REDACTED (=?utf-8?Q?Andrzej_=C5=9Aliwa?=) Date: Thu, 13 Feb 2014 14:00:15 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <1392296152.4863.22.camel@sekic1152.release> References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> <1392296152.4863.22.camel@sekic1152.release> Message-ID: you should use html entity: > ? ?to display > in html http://www.htmlescape.net/htmlescape_tool.html On 13 Feb 2014 at 13:56:04, Bengt Kleberg (bengt.kleberg@REDACTED) wrote: Greetings, If ">" is valid XML, my follow up question is if there is a way to use xmerl to generate XML with ">" in it? bengt On Thu, 2014-02-13 at 12:50 +0000, Magnus Henoch wrote: > Anthony Ramine writes: > > > Why do you want to do that? > > > > An HTML document with a single ? > ? in the middle of nowhere is not valid nor well-formed HTML. > > It is in fact valid HTML. Try pasting the following into > http://validator.w3.org/#validate_by_input : > > > This is > the title > This is > the body > > A standalone greater-than sign is also valid in XML. > > Regards, > Magnus _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Thu Feb 13 14:09:17 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Thu, 13 Feb 2014 14:09:17 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> Message-ID: On Thu, Feb 13, 2014 at 1:25 PM, Carsten Bormann wrote: > On 13 Feb 2014, at 13:05, Lo?c Hoguin wrote: > >>>> No I'm serious, you can use Erlang without OTP. >>> >>> maybe but who is doing it today? Or rather what are the selling points >>> of just using Erlang without OTP? >> >> [...] >> Or if I wanted to use Erlang for writing small administration scripts that's probably also what I would do, as the fast boot is a really important feature there. > > It is such a jolly good idea that Joe spends a whole appendix in his book about doing just that. > (Appendix 3, "A Simple Execution Environment".) > > Gr??e, Carsten > But who is doing it today? The question stands. I mean OK, eventually you can just use Erlang without all the OTP (even if it requires a new boot script), but people don't come on erlang because of the language but due to OTP. And few knows you can use Erlang the other way. OTP is the selling point right now. (Not saying it should be) I also say Erlang/OTP and often I add to the one that ask that OTP is a framework, but then people are more puzzled than they were before. Maybe rust did the right things by clearly separating the language and the runtime from the standard library and other libs ? - benoit From andreas@REDACTED Thu Feb 13 14:11:02 2014 From: andreas@REDACTED (Andreas Schumacher) Date: Thu, 13 Feb 2014 14:11:02 +0100 Subject: [erlang-questions] FW: Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <58912684E2630B45963406CF7D8C52581C348431@ESESSMB103.ericsson.se> References: <52F4C173.8050408@erlang.org> <1391790979.26271.YahooMailNeo@web140106.mail.bf1.yahoo.com> <49EC93AB-69A4-49AB-A2C0-4DA9F418E3F6@gmail.com> <58912684E2630B45963406CF7D8C52581C3473C6@ESESSMB103.ericsson.se> <52FB2C0E.90008@erlang.org> <58912684E2630B45963406CF7D8C52581C348431@ESESSMB103.ericsson.se> Message-ID: <52FCC466.9060206@erlang.org> Re: otp_version: In addition to erlang:system_info(otp_correction_package), a corresponding flag "otp_version" - similar to [emulator] "version" - is going to be added to the erl command, in order to allow the extraction of the complete version number from command line tools. Other additions to extract the Erlang/OTP version have not been planned. Re: 17.0.0 =?= 17.0: Yes, they are the same. We could have used the extra ".0", but we chose not to. Andreas ---------- Andreas Schumacher, Erlang/OTP, Ericsson AB > > -----Original Message----- > From: Vlad Dumitrescu [mailto:vladdu55@REDACTED] > Sent: den 13 februari 2014 10:35 > To: Andreas Schumacher > Cc: Anthony Ramine; erlang-questions; Rickard Green > Subject: Re: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. > > Hi! > > A couple of more questions about versins: > > - how can we find the otp_version without starting erlang? otp_release is in the start scripts, but I can't find anywhere "17.0-rc1"... > - is 17.0.0 the same as 17.0? Is it a problem to use the extra ".0"? > > regards, > Vlad > > > On Wed, Feb 12, 2014 at 9:08 AM, Andreas Schumacher wrote: >> From the versioning clarification mail that I sent on behalf of the >> OTP team to the list on February 7: >> >> >> "The new version scheme is *not* semantic versioning; although, it has >> been inspired by it. We do not want to use semantic versioning (as >> defined by >> http://semver.org/) out of the box since it does not fit our needs." >> >> Andreas Schumacher >> Erlang/OTP, Ericsson AB >> >>> -----Original Message----- >>> From: erlang-questions-bounces@REDACTED >>> [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Anthony >>> Ramine >>> Sent: den 12 februari 2014 02:48 >>> To: Rickard Green >>> Cc: erlang-questions@REDACTED >>> Subject: Re: [erlang-questions] Version numbering scheme change and >>> the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. >>> >>> So OTP won't follow semantic versioning, right? >>> >>> Just seeking confirmation about semver. >>> >>> Regards, >>> >>> -- >>> Anthony Ramine >>> >>> Le 12 f?vr. 2014 ? 00:43, Rickard Green a ?crit : >>> >>>> As of OTP 17 we drop this patch level number sequence and start >>>> using one set of patch level numbers per release. The patch level is >>>> not expressed as an integer as it used to be, but instead as a >>>> version number ..[. ...], for example, 17.0.1. This way >>>> the patch level gives you a bit more information. You can for >>>> example see directly which OTP release it applies to. This patch >>>> level version number also replace the - tar-ball naming scheme. >>> _______________________________________________ >>> 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 Thu Feb 13 14:47:28 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 13 Feb 2014 08:47:28 -0500 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> Message-ID: <20140213134727.GH62889@ferdair.local> On 02/13, Garrett Smith wrote: > What sucks IMO is that OTP is treated as "advanced" by the community > and by book authors. I understand the history of this, but there's a > cost: programmers delay learning core Erlang principles of > *applications* -- i.e. supervisor trees -- because it's not taught up. > It's also incredibly complicated, if you don't use e2. > > The irony is that *advanced* Erlang programmers can get away > programming outside the OTP guard rails. Beginners should not even > consider doing this until they understand why OTP works and why they > should deviate. > To me that's often a required step. Plenty of programmers do not know or aren't comfortable with: - Pattern matching - Recursion - Higher Order Functions - Anonymous functions - Principles of concurrency - Principles of distribution - Prolog-like Syntax - Expression-based conditionals (case/if) - Single Assignment - Immutability (and the lack for while and for loops) - Not using objects And they can furthermore come with baggage regarding algorithms and data structures (usually mutable!) and code structure that makes it really hard to adapt. Picking to go OTP first, I believe, makes the implicit assumption that the reader or audience will be familiar with some of the things used in Erlang. If you don't make these assumptions, starting with OTP frankly reminds me of Java's Hello World to a first-time programmer: public class HelloWorld { public static void main(String[] args) { System.out.println("Hello, World"); } } New concepts to a new programmer may include: public, class, static, void, main function, String[] type, Function call syntax. At this point, for a reader unfamiliar with these terms, you either have to handwave it away and say "oh we'll see this later" or "you don't have the qualifications required for this text", in which case, the person *will* have to explore these concepts, either later in the text, or without you. I'm taking this to heart because I made the decision to show stuff from the ground up in LYSE for this specific reason: people who are unfamiliar with functional concepts may get one hell of an overload if they get to learn them while learning Prolog-y syntax, Concurrency, and a general development framework on top of it. It doesn't mean it's impossible or even a bad idea, but it's freaking harder to write for, and for me as a reader, to understand (my decisions are often validated by how I'd use my own work here, which is subject to bias, but yeah). Oh and I also like to take the approach where every feature is introduced as solving a specific problem -- that's how I try to get to reader to see it as important or worth looking into. How do you sell the idea of OTP without first encountering the problems it solves? Things write themselves more or less naturally when you start with mailboxes and say "hot damn this gets repeated a lot." There's a lot of validity in wanting to show people how to wrap their code into a functioning application, into libraries, and into supervision trees. It would probably save a lot of bad code or half-wrapped applications that discover OTP too late and then need a rewrite. I however have a hard time expecting to see the benefits when the target audience possibly doesn't know how to write a list lookup function recursively with the use of pattern matching in the first place, however. Maybe when the general public is more familiar with functional style, it will be easier to jump into OTP early. Until then, OTP *is* advanced for a large part of the population who doesn't have the functional prerequisites to feel at home in a language like Erlang at *any* level. Regards, Fred. From bengt.kleberg@REDACTED Thu Feb 13 15:10:59 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 13 Feb 2014 15:10:59 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <579D258C-F9BB-417E-9F58-0A9F3DA1AED7@gmail.com> References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> <1392296152.4863.22.camel@sekic1152.release> <579D258C-F9BB-417E-9F58-0A9F3DA1AED7@gmail.com> Message-ID: <1392300659.4863.28.camel@sekic1152.release> What would be fixed javascript for if (i > 0) { bengt On Thu, 2014-02-13 at 14:00 +0100, Anthony Ramine wrote: > You can patch xmerl (and make it still escape > if preceded by ]]). > > Or you can fix your javascript code. > From bengt.kleberg@REDACTED Thu Feb 13 15:12:41 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 13 Feb 2014 15:12:41 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> <1392296152.4863.22.camel@sekic1152.release> Message-ID: <1392300761.4863.30.camel@sekic1152.release> My problem is that Javascript in the HTML file look like this (when created by xmerl): if (i > 0) { and that does not run. bengt On Thu, 2014-02-13 at 14:00 +0100, Andrzej ?liwa wrote: > you should use html entity: > > > > to display > in html > > > http://www.htmlescape.net/htmlescape_tool.html > > On 13 Feb 2014 at 13:56:04, Bengt Kleberg (bengt.kleberg@REDACTED) > wrote: > > > Greetings, > > > > If ">" is valid XML, my follow up question is if there is a way to > > use > > xmerl to generate XML with ">" in it? > > > > > > bengt > > > > On Thu, 2014-02-13 at 12:50 +0000, Magnus Henoch wrote: > > > Anthony Ramine writes: > > > > > > > Why do you want to do that? > > > > > > > > An HTML document with a single ? > ? in the middle of nowhere is > > not valid nor well-formed HTML. > > > > > > It is in fact valid HTML. Try pasting the following into > > > http://validator.w3.org/#validate_by_input : > > > > > > > > > This is > the title > > > This is > the body > > > > > > A standalone greater-than sign is also valid in XML. > > > > > > Regards, > > > Magnus > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > From bengt.kleberg@REDACTED Thu Feb 13 15:13:56 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 13 Feb 2014 15:13:56 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <62792D12-B0CC-49B0-9DC8-D6F796277152@gmail.com> References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> <62792D12-B0CC-49B0-9DC8-D6F796277152@gmail.com> Message-ID: <1392300836.4863.31.camel@sekic1152.release> Javascript needs ">". On Thu, 2014-02-13 at 13:59 +0100, Anthony Ramine wrote: > Mmmmh, right. Was thinking about <. > > That being said, code consuming HTML or XML shouldn?t see a difference, and not escaping could also introduce other bugs, as ]]> is not supposed to appear in content (in XML). This leads us to the original question, which was ? why do you need to do this? ?. > From bengt.kleberg@REDACTED Thu Feb 13 15:18:04 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 13 Feb 2014 15:18:04 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <82AA0EB2-D8E8-4AD7-97B1-E2AF47A410E5@tzi.org> References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> <1392296152.4863.22.camel@sekic1152.release> <82AA0EB2-D8E8-4AD7-97B1-E2AF47A410E5@tzi.org> Message-ID: <1392301084.4863.35.camel@sekic1152.release> Thank you for a solution. I do not have the possibility to change Erlang/OTP. I can copy xmerl_lib.erl to my_xmerl_lib.erl and call that. There is a precedence, I already do this with slave.erl and others. bengt On Thu, 2014-02-13 at 14:01 +0100, Carsten Bormann wrote: > Fix this: > > otp/lib/xmerl/src/xmerl_lib.erl > > %% Escape special characters `<' and `&', flattening the text. > %% Also escapes `>', just for symmetry. > ? > export_text([$> | T], Cont) -> > ">" ++ export_text(T, Cont); > > > The ]]> is (very rarely) a valid concern in XML; I don?t think it ever is in HTML. > > Gr??e, Carsten > From dch@REDACTED Thu Feb 13 15:19:28 2014 From: dch@REDACTED (Dave Cottlehuber) Date: Thu, 13 Feb 2014 15:19:28 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <20140213134727.GH62889@ferdair.local> References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <20140213134727.GH62889@ferdair.local> Message-ID: On 13 February 2014 14:47, Fred Hebert wrote: > Oh and I also like to take the approach where every feature is > introduced as solving a specific problem -- that's how I try to get to > reader to see it as important or worth looking into. How do you sell the > idea of OTP without first encountering the problems it solves? Things > write themselves more or less naturally when you start with mailboxes > and say "hot damn this gets repeated a lot." > > There's a lot of validity in wanting to show people how to wrap their > code into a functioning application, into libraries, and into > supervision trees. It would probably save a lot of bad code or > half-wrapped applications that discover OTP too late and then need a > rewrite. > > I however have a hard time expecting to see the benefits when the target > audience possibly doesn't know how to write a list lookup function > recursively with the use of pattern matching in the first place, > however. Maybe when the general public is more familiar with functional > style, it will be easier to jump into OTP early. > > Until then, OTP *is* advanced for a large part of the population who > doesn't have the functional prerequisites to feel at home in a language > like Erlang at *any* level. > > Regards, > Fred. Thanks Fred, An insightful response. Where do you see behaviours in all this? The context is that I've recently advocated introducing behaviours very early on (not full gen_* behaviours), but just as a really simple step in learning erlang, same as adding tests, using typer & dialyzer, in helping enforce API contracts between modules. It seems to ease the shock of the first encounter with gen_server etc, removing a bit more of the black magic up front. A+ Dave From dszoboszlay@REDACTED Thu Feb 13 15:20:25 2014 From: dszoboszlay@REDACTED (=?utf-8?Q?Szoboszlay_D=C3=A1niel?=) Date: Thu, 13 Feb 2014 15:20:25 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <1392300836.4863.31.camel@sekic1152.release> References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> <62792D12-B0CC-49B0-9DC8-D6F796277152@gmail.com> <1392300836.4863.31.camel@sekic1152.release> Message-ID: What about wrapping the Javascript code in a section? The browser shall parse > as < in PCDATA before interpreting it as Javascript code. Daniel On Thu, 13 Feb 2014 15:13:56 +0100, Bengt Kleberg wrote: > Javascript needs ">". > > > On Thu, 2014-02-13 at 13:59 +0100, Anthony Ramine wrote: >> Mmmmh, right. Was thinking about <. >> >> That being said, code consuming HTML or XML shouldn?t see a difference, >> and not escaping could also introduce other bugs, as ]]> is not >> supposed to appear in content (in XML). This leads us to the original >> question, which was ? why do you need to do this? ?. >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vladdu55@REDACTED Thu Feb 13 15:21:01 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 13 Feb 2014 15:21:01 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> Message-ID: On Thu, Feb 13, 2014 at 2:09 PM, Benoit Chesneau wrote: > I also say Erlang/OTP and often I add to the one that ask that OTP is > a framework, but then people are more puzzled than they were before. > Maybe rust did the right things by clearly separating the language > and the runtime from the standard library and other libs ? I would say that OTP is to Erlang what OOP is to Java. You can write Java programs that are not object-oriented, but why choose Java for that in the first place? OTP is in my opinion a design philosophy that guides us when it comes to structuring and developing distributed fault-tolerant systems. It comes with library support that is intimately tied to the Erlang libraries: the most basic Erlang apps (kernel and stdlib) are also the ones that implement the OTP concepts. Even more, Erlang code is structured as applications, and an "application" is an OTP concept! I can only see meaning in trying to separate the language from OTP either as an academic exercise or in order to implement a different language on the beam runtime and the new concepts would collide implementation-wise with OTP. Or one wants to create OTP 2.0 without interference with 1.0. regards, Vlad From bengt.kleberg@REDACTED Thu Feb 13 15:25:43 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 13 Feb 2014 15:25:43 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> <62792D12-B0CC-49B0-9DC8-D6F796277152@gmail.com> <1392300836.4863.31.camel@sekic1152.release> Message-ID: <1392301543.4863.37.camel@sekic1152.release> This also sounds like a good idea. You would not happen to know how I could get "![PCDATA[" into xmerl tuples? bengt On Thu, 2014-02-13 at 15:20 +0100, Szoboszlay D?niel wrote: > What about wrapping the Javascript code in a section? > The browser shall parse > as < in PCDATA before interpreting it as > Javascript code. > > Daniel > > On Thu, 13 Feb 2014 15:13:56 +0100, Bengt Kleberg > wrote: > > > Javascript needs ">". > > > > > > On Thu, 2014-02-13 at 13:59 +0100, Anthony Ramine wrote: > >> Mmmmh, right. Was thinking about <. > >> > >> That being said, code consuming HTML or XML shouldn?t see a difference, > >> and not escaping could also introduce other bugs, as ]]> is not > >> supposed to appear in content (in XML). This leads us to the original > >> question, which was ? why do you need to do this? ?. > >> > > > > _______________________________________________ > > 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 carlsson.richard@REDACTED Thu Feb 13 15:31:12 2014 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Thu, 13 Feb 2014 15:31:12 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <1392300761.4863.30.camel@sekic1152.release> References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> <1392296152.4863.22.camel@sekic1152.release> <1392300761.4863.30.camel@sekic1152.release> Message-ID: <52FCD730.803@gmail.com> On 2014-02-13 15:12 , Bengt Kleberg wrote: > My problem is that Javascript in the HTML file look like this (when > created by xmerl): > > if (i > 0) { > > and that does not run. Out of curiosity, if it had been < instead, which of the following would work? if (i < 0) { if (i < 0) { If it is the first case, there is presumably a very specific rule for this, which doesn't do full handling of XML escape sequences on the source code level (since > didn't work). Which seems moronic, but wouldn't surprise me... If it's the second case, how is the script text really supposed to be handled by XML tools? As CDATA (then, how is it delimited?) or as normal XML text (and then how can the < be accepted by the parser, and why wasn't > converted to > before the Javascript parser got hold of the text)? /Richard From vinoski@REDACTED Thu Feb 13 15:33:07 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Thu, 13 Feb 2014 09:33:07 -0500 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <1392294854.4863.17.camel@sekic1152.release> References: <1392294854.4863.17.camel@sekic1152.release> Message-ID: On Thu, Feb 13, 2014 at 7:34 AM, Bengt Kleberg wrote: > Greetings, > > Is there an Erlang library that allows me to generate HTML from Erlang > and that can stop ">" from turning into ">"? > > Previously I used > xmerl:export_simple( [{html, [], [Body]}], xmerl_xml ). > where Body could be {body, [], ["Some text with >"]}. > xmerl will transform ">" into ">", but until now the HTML has worked > well. > > Now I need to keep ">". 1> yaws_api:ehtml_expand({body, [], [{p,[],"Some text with >"}]}). ["\n","<","body",[],">", [["\n","<","p",[],">","Some text with >",""]], ""] 2> lists:flatten(v(1)). "\n\n

Some text with >

" --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Thu Feb 13 15:33:23 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 13 Feb 2014 15:33:23 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <1392300836.4863.31.camel@sekic1152.release> References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> <62792D12-B0CC-49B0-9DC8-D6F796277152@gmail.com> <1392300836.4863.31.camel@sekic1152.release> Message-ID: Wow, just checked the HTML5 spec and you?re right. So did I sleep for ten years and what I said is only true for XML and XHTML (that it should work whether it is encoded or not), or did I live in an alternate universe all this time, where the HTML spec wasn?t inconsistent in its handling of entities? Sorry for the lost time, anyway. -- Anthony Ramine Le 13 f?vr. 2014 ? 15:13, Bengt Kleberg a ?crit : > Javascript needs ">". > > > On Thu, 2014-02-13 at 13:59 +0100, Anthony Ramine wrote: >> Mmmmh, right. Was thinking about <. >> >> That being said, code consuming HTML or XML shouldn?t see a difference, and not escaping could also introduce other bugs, as ]]> is not supposed to appear in content (in XML). This leads us to the original question, which was ? why do you need to do this? ?. >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From mononcqc@REDACTED Thu Feb 13 15:37:56 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 13 Feb 2014 09:37:56 -0500 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <20140213134727.GH62889@ferdair.local> Message-ID: <20140213143755.GI62889@ferdair.local> A lot of my comments will often boil down to "what I did in LYSE is what I think is best" -- which is kind of dumb and not useful, but makes sense (why would I take an approach I think is less optimal?). Behaviours on their own have a far lesser cognitive load than OTP as a whole. The question I have on this one is whether this will lead to idiomatic Erlang/OTP code in the long run, or whether this will breed a behaviour-heavy code base where people try to shoe in things such as abstract classes into behaviours, because let's face it, a programmer is going to grasp at all the straws he or she can grasp, learning by analogy, and the concepts are deceptively similar. (Interfaces an abstract classes are somewhat similar, and so abstract classes and behaviors are not very far apart!) My concerns shouldn't keep from one from trying to do what they think is best. Different readers and writers have different teaching and learning methods, and it's clear that Erlang books aren't a one-size-fits-all kind of deal. Over time, variety in learning material should yield a higher quality for all approaches. Whether people feel more at ease going through Joe's book, Francesco's & Simon's, Zach's, Simon's (Introducing Erlang), Eric's & Martin's, LYSE, webcasts, blog posts, talks, or diving into the source code of existing projects, or even just asking friends is unpredictable, and having a resource for every kind of person is hardly a way for failure. I don't think I've heard a lot of complaints about having too many resources to learn from in Java, C, or C++. If so, it's not on the level of "not enough resources in language X". It's also far less work for a community to shun or give less importance to a bad tutorial, than it is to come up with a new one, so filtering out to keep the most helpful material is likely a happy problem. Ultimately the decision of an approach is made by the person writing the tutorial. If you feel confident in introducing behaviours early, I'd say to try it and go for it, and see the results at a small scale, maybe. We can't really know without having someone trying it. Regards, Fred. On 02/13, Dave Cottlehuber wrote: > > Thanks Fred, > > An insightful response. Where do you see behaviours in all this? > > The context is that I've recently advocated introducing behaviours > very early on (not full gen_* behaviours), but just as a really simple > step in learning erlang, same as adding tests, using typer & dialyzer, > in helping enforce API contracts between modules. It seems to ease the > shock of the first encounter with gen_server etc, removing a bit more > of the black magic up front. > > A+ > Dave > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bengt.kleberg@REDACTED Thu Feb 13 15:43:46 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 13 Feb 2014 15:43:46 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <52FCD730.803@gmail.com> References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> <1392296152.4863.22.camel@sekic1152.release> <1392300761.4863.30.camel@sekic1152.release> <52FCD730.803@gmail.com> Message-ID: <1392302626.4863.45.camel@sekic1152.release> The use-case is not supposed to include XML. My Erlang server creates a log file. A python script generates HTML from the log file. I now consider generating the HTML directly from Erlang since I have to call upon another person to fix the python script every time the log file format changes. Only the log file format changes, the neccessary contents are still present in the Erlang server. My previous method of HTML generation has been to use xmerl. If I do that now then the Javascript part of the HTML will not run. bengt On Thu, 2014-02-13 at 15:31 +0100, Richard Carlsson wrote: > On 2014-02-13 15:12 , Bengt Kleberg wrote: > > My problem is that Javascript in the HTML file look like this (when > > created by xmerl): > > > > if (i > 0) { > > > > and that does not run. > > Out of curiosity, if it had been < instead, which of the following would > work? > > if (i < 0) { > > if (i < 0) { > > If it is the first case, there is presumably a very specific rule for > this, which doesn't do full handling of XML escape sequences on the > source code level (since > didn't work). Which seems moronic, but > wouldn't surprise me... > > If it's the second case, how is the script text really supposed to be > handled by XML tools? As CDATA (then, how is it delimited?) or as normal > XML text (and then how can the < be accepted by the parser, and why > wasn't > converted to > before the Javascript parser got hold of the > text)? > > /Richard > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From n.oxyde@REDACTED Thu Feb 13 15:46:52 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 13 Feb 2014 15:46:52 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> Message-ID: <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> Java without OOP is a different language. Erlang without OTP is still Erlang. -- Anthony Ramine Le 13 f?vr. 2014 ? 15:21, Vlad Dumitrescu a ?crit : > On Thu, Feb 13, 2014 at 2:09 PM, Benoit Chesneau wrote: >> I also say Erlang/OTP and often I add to the one that ask that OTP is >> a framework, but then people are more puzzled than they were before. >> Maybe rust did the right things by clearly separating the language >> and the runtime from the standard library and other libs ? > > I would say that OTP is to Erlang what OOP is to Java. You can write > Java programs that are not object-oriented, but why choose Java for > that in the first place? > > OTP is in my opinion a design philosophy that guides us when it comes > to structuring and developing distributed fault-tolerant systems. It > comes with library support that is intimately tied to the Erlang > libraries: the most basic Erlang apps (kernel and stdlib) are also the > ones that implement the OTP concepts. Even more, Erlang code is > structured as applications, and an "application" is an OTP concept! > > I can only see meaning in trying to separate the language from OTP > either as an academic exercise or in order to implement a different > language on the beam runtime and the new concepts would collide > implementation-wise with OTP. Or one wants to create OTP 2.0 without > interference with 1.0. > > regards, > Vlad > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ivan@REDACTED Thu Feb 13 15:46:54 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Thu, 13 Feb 2014 14:46:54 +0000 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <1392302626.4863.45.camel@sekic1152.release> References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> <1392296152.4863.22.camel@sekic1152.release> <1392300761.4863.30.camel@sekic1152.release> <52FCD730.803@gmail.com> <1392302626.4863.45.camel@sekic1152.release> Message-ID: <52FCDADE.6@llaisdy.com> Does all of the javascfript have to be generated dynamically from the erlang? Or could you have a static javascript file for most or all of it? Ivan On 13/02/2014 14:43, Bengt Kleberg wrote: > The use-case is not supposed to include XML. > > My Erlang server creates a log file. A python script generates HTML from > the log file. I now consider generating the HTML directly from Erlang > since I have to call upon another person to fix the python script every > time the log file format changes. Only the log file format changes, the > neccessary contents are still present in the Erlang server. > > My previous method of HTML generation has been to use xmerl. If I do > that now then the Javascript part of the HTML will not run. > > > bengt > > On Thu, 2014-02-13 at 15:31 +0100, Richard Carlsson wrote: >> On 2014-02-13 15:12 , Bengt Kleberg wrote: >>> My problem is that Javascript in the HTML file look like this (when >>> created by xmerl): >>> >>> if (i > 0) { >>> >>> and that does not run. >> >> Out of curiosity, if it had been < instead, which of the following would >> work? >> >> if (i < 0) { >> >> if (i < 0) { >> >> If it is the first case, there is presumably a very specific rule for >> this, which doesn't do full handling of XML escape sequences on the >> source code level (since > didn't work). Which seems moronic, but >> wouldn't surprise me... >> >> If it's the second case, how is the script text really supposed to be >> handled by XML tools? As CDATA (then, how is it delimited?) or as normal >> XML text (and then how can the < be accepted by the parser, and why >> wasn't > converted to > before the Javascript parser got hold of the >> text)? >> >> /Richard >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From bengt.kleberg@REDACTED Thu Feb 13 15:47:33 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 13 Feb 2014 15:47:33 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: References: Message-ID: <1392302853.4863.48.camel@sekic1152.release> Thank you, new idea. Perhaps I have another bug in my copy of the Javascript? Replacing all > with > also fixes that bug? I will look really carefully. bengt On Thu, 2014-02-13 at 18:35 +0400, ?????? ???????? wrote: > I'm sure, that embedded Javascript understands > and < instead > of > and < characters, so > > > > > > should work. > > > You may also try Mochiweb's HTML parser/serializer, which is much > simpler and faster, than xmerl > https://github.com/mochi/mochiweb/blob/master/src/mochiweb_html.erl > > > > Tree = {<<"html">>, [{<<"lang">>, <<"en">>}], > [...child tags...]}, > mochiweb_html:to_html(Tree). > > > But I'm not sure if it escapes special characters. From dszoboszlay@REDACTED Thu Feb 13 15:48:05 2014 From: dszoboszlay@REDACTED (=?utf-8?Q?Szoboszlay_D=C3=A1niel?=) Date: Thu, 13 Feb 2014 15:48:05 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <1392301543.4863.37.camel@sekic1152.release> References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> <62792D12-B0CC-49B0-9DC8-D6F796277152@gmail.com> <1392300836.4863.31.camel@sekic1152.release> <1392301543.4863.37.camel@sekic1152.release> Message-ID: I think it's not possible to add CDATA or PCDATA directives in out-of-the-box xmerl. But you can write your own callback module by simply copying xmerl_xml and changing '#text#'/1 slightly: '#text#'(Text) -> [""]. Cheers, Daniel On Thu, 13 Feb 2014 15:25:43 +0100, Bengt Kleberg wrote: > This also sounds like a good idea. You would not happen to know how I > could get "![PCDATA[" into xmerl tuples? > > > bengt > > On Thu, 2014-02-13 at 15:20 +0100, Szoboszlay D?niel wrote: >> What about wrapping the Javascript code in a section? >> The browser shall parse > as < in PCDATA before interpreting it as >> Javascript code. >> >> Daniel >> >> On Thu, 13 Feb 2014 15:13:56 +0100, Bengt Kleberg >> wrote: >> >> > Javascript needs ">". >> > >> > >> > On Thu, 2014-02-13 at 13:59 +0100, Anthony Ramine wrote: >> >> Mmmmh, right. Was thinking about <. >> >> >> >> That being said, code consuming HTML or XML shouldn?t see a >> difference, >> >> and not escaping could also introduce other bugs, as ]]> is not >> >> supposed to appear in content (in XML). This leads us to the original >> >> question, which was ? why do you need to do this? ?. >> >> >> > >> > _______________________________________________ >> > 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 davidnwelton@REDACTED Thu Feb 13 15:50:09 2014 From: davidnwelton@REDACTED (David Welton) Date: Thu, 13 Feb 2014 15:50:09 +0100 Subject: [erlang-questions] epgsql coordination? Message-ID: Is there anyone interested in trying to make a proper open source project of the Postgresql epgsql client, in the sense of coordinating efforts via a mailing list, merging patches, and not just forking the code willy-nilly? https://github.com/mabrek/epgsql/network -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From bengt.kleberg@REDACTED Thu Feb 13 15:54:46 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 13 Feb 2014 15:54:46 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <52FCDADE.6@llaisdy.com> References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> <1392296152.4863.22.camel@sekic1152.release> <1392300761.4863.30.camel@sekic1152.release> <52FCD730.803@gmail.com> <1392302626.4863.45.camel@sekic1152.release> <52FCDADE.6@llaisdy.com> Message-ID: <1392303286.4863.51.camel@sekic1152.release> Yes, the Javascript could be in a separate file that I would generate. Is it possible to do some sort of "-include()" from the HTML? bengt On Thu, 2014-02-13 at 14:46 +0000, Ivan Uemlianin wrote: > Does all of the javascfript have to be generated dynamically from the > erlang? Or could you have a static javascript file for most or all of it? > > Ivan > > > On 13/02/2014 14:43, Bengt Kleberg wrote: > > The use-case is not supposed to include XML. > > > > My Erlang server creates a log file. A python script generates HTML from > > the log file. I now consider generating the HTML directly from Erlang > > since I have to call upon another person to fix the python script every > > time the log file format changes. Only the log file format changes, the > > neccessary contents are still present in the Erlang server. > > > > My previous method of HTML generation has been to use xmerl. If I do > > that now then the Javascript part of the HTML will not run. > > > > > > bengt > > > > On Thu, 2014-02-13 at 15:31 +0100, Richard Carlsson wrote: > >> On 2014-02-13 15:12 , Bengt Kleberg wrote: > >>> My problem is that Javascript in the HTML file look like this (when > >>> created by xmerl): > >>> > >>> if (i > 0) { > >>> > >>> and that does not run. > >> > >> Out of curiosity, if it had been < instead, which of the following would > >> work? > >> > >> if (i < 0) { > >> > >> if (i < 0) { > >> > >> If it is the first case, there is presumably a very specific rule for > >> this, which doesn't do full handling of XML escape sequences on the > >> source code level (since > didn't work). Which seems moronic, but > >> wouldn't surprise me... > >> > >> If it's the second case, how is the script text really supposed to be > >> handled by XML tools? As CDATA (then, how is it delimited?) or as normal > >> XML text (and then how can the < be accepted by the parser, and why > >> wasn't > converted to > before the Javascript parser got hold of the > >> text)? > >> > >> /Richard > >> > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > From vladdu55@REDACTED Thu Feb 13 15:59:04 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 13 Feb 2014 15:59:04 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> Message-ID: On Thu, Feb 13, 2014 at 3:46 PM, Anthony Ramine wrote: > Java without OOP is a different language. > Erlang without OTP is still Erlang. IMHO the only difference is that OTP is implemented as a library and doesn't have dedicated language syntax. I make difference between OTP as design/system building guidelines and its implementation. The former is more like OOP for Java. The latter is more like the JDK. /Vlad > -- > Anthony Ramine > > Le 13 f?vr. 2014 ? 15:21, Vlad Dumitrescu a ?crit : > >> On Thu, Feb 13, 2014 at 2:09 PM, Benoit Chesneau wrote: >>> I also say Erlang/OTP and often I add to the one that ask that OTP is >>> a framework, but then people are more puzzled than they were before. >>> Maybe rust did the right things by clearly separating the language >>> and the runtime from the standard library and other libs ? >> >> I would say that OTP is to Erlang what OOP is to Java. You can write >> Java programs that are not object-oriented, but why choose Java for >> that in the first place? >> >> OTP is in my opinion a design philosophy that guides us when it comes >> to structuring and developing distributed fault-tolerant systems. It >> comes with library support that is intimately tied to the Erlang >> libraries: the most basic Erlang apps (kernel and stdlib) are also the >> ones that implement the OTP concepts. Even more, Erlang code is >> structured as applications, and an "application" is an OTP concept! >> >> I can only see meaning in trying to separate the language from OTP >> either as an academic exercise or in order to implement a different >> language on the beam runtime and the new concepts would collide >> implementation-wise with OTP. Or one wants to create OTP 2.0 without >> interference with 1.0. >> >> regards, >> Vlad >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > From carlsson.richard@REDACTED Thu Feb 13 15:59:39 2014 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Thu, 13 Feb 2014 15:59:39 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <20140213134727.GH62889@ferdair.local> Message-ID: <52FCDDDB.4060301@gmail.com> On 2014-02-13 15:19 , Dave Cottlehuber wrote: > Thanks Fred, > > An insightful response. Where do you see behaviours in all this? > > The context is that I've recently advocated introducing behaviours > very early on (not full gen_* behaviours), but just as a really simple > step in learning erlang, same as adding tests, using typer & dialyzer, > in helping enforce API contracts between modules. It seems to ease the > shock of the first encounter with gen_server etc, removing a bit more > of the black magic up front. Not Fred, but: First, -behaviour(...) declarations are quite low level in themselves, just being an API specification that the Erlang compiler happens to know how to check at compile time (if the module that defines the behaviour is present at that time). And an Erlang compiler could ignore the declaration without any real ill effects - it's just a help to discover errors. From that viewpoint, behaviour=interface. From the OTP viewpoint however, "behaviour" implies that along with the interface there is an associated library with generic functionality, typically implementing a process or set of processes, which you specialize by providing your API-conforming callback module. (Although these days, some who implement their own behaviours only use them for the interface part, and don't actually have a generic component.) This concept, is one of its main foundations of OTP (but is independent of the rest of OTP). The interface checking is sugar on top. /Richard From ivan@REDACTED Thu Feb 13 16:00:09 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Thu, 13 Feb 2014 15:00:09 +0000 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <1392303286.4863.51.camel@sekic1152.release> References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> <1392296152.4863.22.camel@sekic1152.release> <1392300761.4863.30.camel@sekic1152.release> <52FCD730.803@gmail.com> <1392302626.4863.45.camel@sekic1152.release> <52FCDADE.6@llaisdy.com> <1392303286.4863.51.camel@sekic1152.release> Message-ID: <52FCDDF9.2010602@llaisdy.com> Include an external js file into html like this: Ivan On 13/02/2014 14:54, Bengt Kleberg wrote: > Yes, the Javascript could be in a separate file that I would generate. > > Is it possible to do some sort of "-include()" from the HTML? > > > bengt > > On Thu, 2014-02-13 at 14:46 +0000, Ivan Uemlianin wrote: >> Does all of the javascfript have to be generated dynamically from the >> erlang? Or could you have a static javascript file for most or all of it? >> >> Ivan >> >> >> On 13/02/2014 14:43, Bengt Kleberg wrote: >>> The use-case is not supposed to include XML. >>> >>> My Erlang server creates a log file. A python script generates HTML from >>> the log file. I now consider generating the HTML directly from Erlang >>> since I have to call upon another person to fix the python script every >>> time the log file format changes. Only the log file format changes, the >>> neccessary contents are still present in the Erlang server. >>> >>> My previous method of HTML generation has been to use xmerl. If I do >>> that now then the Javascript part of the HTML will not run. >>> >>> >>> bengt >>> >>> On Thu, 2014-02-13 at 15:31 +0100, Richard Carlsson wrote: >>>> On 2014-02-13 15:12 , Bengt Kleberg wrote: >>>>> My problem is that Javascript in the HTML file look like this (when >>>>> created by xmerl): >>>>> >>>>> if (i > 0) { >>>>> >>>>> and that does not run. >>>> >>>> Out of curiosity, if it had been < instead, which of the following would >>>> work? >>>> >>>> if (i < 0) { >>>> >>>> if (i < 0) { >>>> >>>> If it is the first case, there is presumably a very specific rule for >>>> this, which doesn't do full handling of XML escape sequences on the >>>> source code level (since > didn't work). Which seems moronic, but >>>> wouldn't surprise me... >>>> >>>> If it's the second case, how is the script text really supposed to be >>>> handled by XML tools? As CDATA (then, how is it delimited?) or as normal >>>> XML text (and then how can the < be accepted by the parser, and why >>>> wasn't > converted to > before the Javascript parser got hold of the >>>> text)? >>>> >>>> /Richard >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From ali.sabil@REDACTED Thu Feb 13 16:00:21 2014 From: ali.sabil@REDACTED (Ali Sabil) Date: Thu, 13 Feb 2014 16:00:21 +0100 Subject: [erlang-questions] epgsql coordination? In-Reply-To: References: Message-ID: I would love to see that happen! On Thu, Feb 13, 2014 at 3:50 PM, David Welton wrote: > Is there anyone interested in trying to make a proper open source > project of the Postgresql epgsql client, in the sense of coordinating > efforts via a mailing list, merging patches, and not just forking the > code willy-nilly? > > https://github.com/mabrek/epgsql/network > > -- > David N. Welton > > http://www.welton.it/davidw/ > > http://www.dedasys.com/ > _______________________________________________ > 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 Thu Feb 13 16:03:54 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 13 Feb 2014 16:03:54 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> Message-ID: <28AAEE0D-905F-4681-B388-7C883CCBA7D3@gmail.com> That?s a *HUGE* difference. Erlang as a language is very small; OTP is a very complex piece of software, as is BEAM. The three shouldn?t be conflated. Java as a language is big and complex, because it has a lot of concepts directly inside the language. -- Anthony Ramine Le 13 f?vr. 2014 ? 15:59, Vlad Dumitrescu a ?crit : > On Thu, Feb 13, 2014 at 3:46 PM, Anthony Ramine wrote: >> Java without OOP is a different language. >> Erlang without OTP is still Erlang. > > IMHO the only difference is that OTP is implemented as a library and > doesn't have dedicated language syntax. I make difference between OTP > as design/system building guidelines and its implementation. The > former is more like OOP for Java. The latter is more like the JDK. > > /Vlad > >> -- >> Anthony Ramine >> >> Le 13 f?vr. 2014 ? 15:21, Vlad Dumitrescu a ?crit : >> >>> On Thu, Feb 13, 2014 at 2:09 PM, Benoit Chesneau wrote: >>>> I also say Erlang/OTP and often I add to the one that ask that OTP is >>>> a framework, but then people are more puzzled than they were before. >>>> Maybe rust did the right things by clearly separating the language >>>> and the runtime from the standard library and other libs ? >>> >>> I would say that OTP is to Erlang what OOP is to Java. You can write >>> Java programs that are not object-oriented, but why choose Java for >>> that in the first place? >>> >>> OTP is in my opinion a design philosophy that guides us when it comes >>> to structuring and developing distributed fault-tolerant systems. It >>> comes with library support that is intimately tied to the Erlang >>> libraries: the most basic Erlang apps (kernel and stdlib) are also the >>> ones that implement the OTP concepts. Even more, Erlang code is >>> structured as applications, and an "application" is an OTP concept! >>> >>> I can only see meaning in trying to separate the language from OTP >>> either as an academic exercise or in order to implement a different >>> language on the beam runtime and the new concepts would collide >>> implementation-wise with OTP. Or one wants to create OTP 2.0 without >>> interference with 1.0. >>> >>> regards, >>> Vlad >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> From ulf@REDACTED Thu Feb 13 16:08:01 2014 From: ulf@REDACTED (Ulf Wiger) Date: Thu, 13 Feb 2014 16:08:01 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> <62792D12-B0CC-49B0-9DC8-D6F796277152@gmail.com> <1392300836.4863.31.camel@sekic1152.release> <1392301543.4863.37.camel@sekic1152.release> Message-ID: <7E203DC5-0617-440B-BFB5-3E080271E514@feuerlabs.com> You don?t need to copy xmerl_xml. Simply write the following module. ==================================== -module(szoboszlay_xml). -export([?#text#?/1, ?#xml-inheritance#?]). ?#xml-inheritance#?() -> [xmerl_xml]. '#text#'(Text) -> ["?]. ==================================== And you?re done. ;-) BR, Ulf On 13 Feb 2014, at 15:48, Szoboszlay D?niel wrote: > I think it's not possible to add CDATA or PCDATA directives in out-of-the-box xmerl. But you can write your own callback module by simply copying xmerl_xml and changing '#text#'/1 slightly: > > '#text#'(Text) -> [""]. > > Cheers, > Daniel > > On Thu, 13 Feb 2014 15:25:43 +0100, Bengt Kleberg wrote: > >> This also sounds like a good idea. You would not happen to know how I >> could get "![PCDATA[" into xmerl tuples? >> >> >> bengt >> >> On Thu, 2014-02-13 at 15:20 +0100, Szoboszlay D?niel wrote: >>> What about wrapping the Javascript code in a section? >>> The browser shall parse > as < in PCDATA before interpreting it as >>> Javascript code. >>> >>> Daniel >>> >>> On Thu, 13 Feb 2014 15:13:56 +0100, Bengt Kleberg >>> wrote: >>> >>> > Javascript needs ">". >>> > >>> > >>> > On Thu, 2014-02-13 at 13:59 +0100, Anthony Ramine wrote: >>> >> Mmmmh, right. Was thinking about <. >>> >> >>> >> That being said, code consuming HTML or XML shouldn?t see a difference, >>> >> and not escaping could also introduce other bugs, as ]]> is not >>> >> supposed to appear in content (in XML). This leads us to the original >>> >> question, which was ? why do you need to do this? ?. >>> >> >>> > >>> > _______________________________________________ >>> > 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 From zoha.qamer@REDACTED Thu Feb 13 16:12:07 2014 From: zoha.qamer@REDACTED (Zoha Qamar) Date: Thu, 13 Feb 2014 20:12:07 +0500 Subject: [erlang-questions] Creating node problem In-Reply-To: References: Message-ID: Hi , I read the article from Erlang's web site http://erlang.org/doc/tutorial/erl_interface.html I wana ask is there way /library for integrating c++ with Erlang , other than tinch++ , because i am not getting it at all . Any build in library from Erlang's side for this purpose ?? On Fri, Jan 31, 2014 at 5:29 PM, Zoha Qamar wrote: > Yes i was silly , n was making them from ERlang emulator , later on i read > its from cmd.exe > > > On Fri, Jan 31, 2014 at 4:30 AM, Erik S?e S?rensen wrote: > >> Are you writing those commands in the Erlang shell? >> They don't go there - they're for the windows shell, for starting the >> Erlang one. >> Regards, >> Erik S?e S?rensen >> Den 29/01/2014 18.41 skrev "Zoha Qamar" : >> >>> >>> Dear all , >>> >>> >>> I making server and client node in Erlang emulator R16B3 , but i am keep >>> getting error on the first line , i am using win7 , 64bit my command is >>> >>> werl -name zoha@REDACTED >>> >>> or >>> >>> >>> werl -name zoha@REDACTED ( copying from host file of >>> window 's ) >>> >>> or its direct IP >>> >>> werl -name zoha@REDACTED >>> >>> but what ever i put Ip or host name , i keep getting error , >>> >>> * 1: syntax error before: zoha@REDACTED >>> or >>> >>> * 1: syntax error before: zoha@REDACTED >>> >>> or >>> >>> * 1: syntax error before: zoha@REDACTED >>> >>> >>> pls help me out where i am wrong any administration privilege issue , >>> firewall issue ?? >>> -- >>> "*Agar Tum Seedhay rastay pe ho aur kisi Mushkil ka samna nahe ker rahay >>> to >>> kuch dair k liyay socho k kahin tum kuch ghalt to nahe ker rahay kyon k >>> seedha rasta to mushkilaat se bhar pur hota hy*" *Hazrat Imam Ali (A.S) >>> * >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> > > > -- > "*Agar Tum Seedhay rastay pe ho aur kisi Mushkil ka samna nahe ker rahay to > kuch dair k liyay socho k kahin tum kuch ghalt to nahe ker rahay kyon k > seedha rasta to mushkilaat se bhar pur hota hy*" *Hazrat Imam Ali (A.S) * > > -- "*Agar Tum Seedhay rastay pe ho aur kisi Mushkil ka samna nahe ker rahay to kuch dair k liyay socho k kahin tum kuch ghalt to nahe ker rahay kyon k seedha rasta to mushkilaat se bhar pur hota hy*" *Hazrat Imam Ali (A.S) * -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidnwelton@REDACTED Thu Feb 13 16:29:32 2014 From: davidnwelton@REDACTED (David Welton) Date: Thu, 13 Feb 2014 16:29:32 +0100 Subject: [erlang-questions] epgsql coordination? In-Reply-To: References: Message-ID: Well, let's give it a go: https://github.com/epgsql/epgsql https://groups.google.com/forum/#!forum/epgsql On Thu, Feb 13, 2014 at 4:00 PM, Ali Sabil wrote: > I would love to see that happen! > > > On Thu, Feb 13, 2014 at 3:50 PM, David Welton > wrote: >> >> Is there anyone interested in trying to make a proper open source >> project of the Postgresql epgsql client, in the sense of coordinating >> efforts via a mailing list, merging patches, and not just forking the >> code willy-nilly? >> >> https://github.com/mabrek/epgsql/network >> >> -- >> David N. Welton >> >> http://www.welton.it/davidw/ >> >> http://www.dedasys.com/ >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From jocke@REDACTED Thu Feb 13 16:40:42 2014 From: jocke@REDACTED (=?ISO-8859-1?Q?Joacim_Greben=F6?=) Date: Thu, 13 Feb 2014 16:40:42 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? Message-ID: <20140213154044.B034437C205@mail.tail-f.com> s/OTP/SDK/g Den 13 feb 2014 15:59 skrev Vlad Dumitrescu : > > On Thu, Feb 13, 2014 at 3:46 PM, Anthony Ramine wrote: > > Java without OOP is a different language. > > Erlang without OTP is still Erlang. > > IMHO the only difference is that OTP is implemented as a library and > doesn't have dedicated language syntax. I make difference between OTP > as design/system building guidelines and its implementation. The > former is more like OOP for Java. The latter is more like the JDK. > > /Vlad > > > -- > > Anthony Ramine > > > > Le 13 f?vr. 2014 ? 15:21, Vlad Dumitrescu a ?crit : > > > >> On Thu, Feb 13, 2014 at 2:09 PM, Benoit Chesneau wrote: > >>> I also say Erlang/OTP and often I add to the one that ask that OTP is > >>> a framework, but then people are more puzzled than they were before. > >>> Maybe rust did the right things by? clearly separating the language > >>> and the runtime from the standard library and other libs ? > >> > >> I would say that OTP is to Erlang what OOP is to Java. You can write > >> Java programs that are not object-oriented, but why choose Java for > >> that in the first place? > >> > >> OTP is in my opinion a design philosophy that guides us when it comes > >> to structuring and developing distributed fault-tolerant systems. It > >> comes with library support that is intimately tied to the Erlang > >> libraries: the most basic Erlang apps (kernel and stdlib) are also the > >> ones that implement the OTP concepts. Even more, Erlang code is > >> structured as applications, and an "application" is an OTP concept! > >> > >> I can only see meaning in trying to separate the language from OTP > >> either as an academic exercise or in order to implement a different > >> language on the beam runtime and the new concepts would collide > >> implementation-wise with OTP. Or one wants to create OTP 2.0 without > >> interference with 1.0. > >> > >> regards, > >> Vlad > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From essen@REDACTED Thu Feb 13 16:42:13 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 13 Feb 2014 16:42:13 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <20140213154044.B034437C205@mail.tail-f.com> References: <20140213154044.B034437C205@mail.tail-f.com> Message-ID: <52FCE7D5.9000809@ninenines.eu> Good point. OTP is just Swedish for SDK. The name was perfect after all! On 02/13/2014 04:40 PM, Joacim Greben? wrote: > s/OTP/SDK/g > > Den 13 feb 2014 15:59 skrev Vlad Dumitrescu : >> >> On Thu, Feb 13, 2014 at 3:46 PM, Anthony Ramine wrote: >>> Java without OOP is a different language. >>> Erlang without OTP is still Erlang. >> >> IMHO the only difference is that OTP is implemented as a library and >> doesn't have dedicated language syntax. I make difference between OTP >> as design/system building guidelines and its implementation. The >> former is more like OOP for Java. The latter is more like the JDK. >> >> /Vlad >> >>> -- >>> Anthony Ramine >>> >>> Le 13 f?vr. 2014 ? 15:21, Vlad Dumitrescu a ?crit : >>> >>>> On Thu, Feb 13, 2014 at 2:09 PM, Benoit Chesneau wrote: >>>>> I also say Erlang/OTP and often I add to the one that ask that OTP is >>>>> a framework, but then people are more puzzled than they were before. >>>>> Maybe rust did the right things by clearly separating the language >>>>> and the runtime from the standard library and other libs ? >>>> >>>> I would say that OTP is to Erlang what OOP is to Java. You can write >>>> Java programs that are not object-oriented, but why choose Java for >>>> that in the first place? >>>> >>>> OTP is in my opinion a design philosophy that guides us when it comes >>>> to structuring and developing distributed fault-tolerant systems. It >>>> comes with library support that is intimately tied to the Erlang >>>> libraries: the most basic Erlang apps (kernel and stdlib) are also the >>>> ones that implement the OTP concepts. Even more, Erlang code is >>>> structured as applications, and an "application" is an OTP concept! >>>> >>>> I can only see meaning in trying to separate the language from OTP >>>> either as an academic exercise or in order to implement a different >>>> language on the beam runtime and the new concepts would collide >>>> implementation-wise with OTP. Or one wants to create OTP 2.0 without >>>> interference with 1.0. >>>> >>>> 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 > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From ali.sabil@REDACTED Thu Feb 13 16:43:19 2014 From: ali.sabil@REDACTED (Ali Sabil) Date: Thu, 13 Feb 2014 16:43:19 +0100 Subject: [erlang-questions] epgsql coordination? In-Reply-To: References: Message-ID: Does it make sense to have it shown as a fork? I would suggest pushing a new repo there instead of forking from davidw :) I will have some pull requests ready soon! On Thu, Feb 13, 2014 at 4:29 PM, David Welton wrote: > Well, let's give it a go: > > https://github.com/epgsql/epgsql > > https://groups.google.com/forum/#!forum/epgsql > > > > On Thu, Feb 13, 2014 at 4:00 PM, Ali Sabil wrote: > > I would love to see that happen! > > > > > > On Thu, Feb 13, 2014 at 3:50 PM, David Welton > > wrote: > >> > >> Is there anyone interested in trying to make a proper open source > >> project of the Postgresql epgsql client, in the sense of coordinating > >> efforts via a mailing list, merging patches, and not just forking the > >> code willy-nilly? > >> > >> https://github.com/mabrek/epgsql/network > >> > >> -- > >> David N. Welton > >> > >> http://www.welton.it/davidw/ > >> > >> http://www.dedasys.com/ > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > -- > David N. Welton > > http://www.welton.it/davidw/ > > http://www.dedasys.com/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.sabil@REDACTED Thu Feb 13 16:44:08 2014 From: ali.sabil@REDACTED (Ali Sabil) Date: Thu, 13 Feb 2014 16:44:08 +0100 Subject: [erlang-questions] epgsql coordination? In-Reply-To: References: Message-ID: Also it would be great if the branches were cleaned up, leaving only what's relevant On Thu, Feb 13, 2014 at 4:43 PM, Ali Sabil wrote: > Does it make sense to have it shown as a fork? I would suggest pushing a > new repo there instead of forking from davidw :) > > I will have some pull requests ready soon! > > > On Thu, Feb 13, 2014 at 4:29 PM, David Welton wrote: > >> Well, let's give it a go: >> >> https://github.com/epgsql/epgsql >> >> https://groups.google.com/forum/#!forum/epgsql >> >> >> >> On Thu, Feb 13, 2014 at 4:00 PM, Ali Sabil wrote: >> > I would love to see that happen! >> > >> > >> > On Thu, Feb 13, 2014 at 3:50 PM, David Welton >> > wrote: >> >> >> >> Is there anyone interested in trying to make a proper open source >> >> project of the Postgresql epgsql client, in the sense of coordinating >> >> efforts via a mailing list, merging patches, and not just forking the >> >> code willy-nilly? >> >> >> >> https://github.com/mabrek/epgsql/network >> >> >> >> -- >> >> David N. Welton >> >> >> >> http://www.welton.it/davidw/ >> >> >> >> http://www.dedasys.com/ >> >> _______________________________________________ >> >> erlang-questions mailing list >> >> erlang-questions@REDACTED >> >> http://erlang.org/mailman/listinfo/erlang-questions >> > >> > >> >> >> >> -- >> David N. Welton >> >> http://www.welton.it/davidw/ >> >> http://www.dedasys.com/ >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidnwelton@REDACTED Thu Feb 13 16:51:22 2014 From: davidnwelton@REDACTED (David Welton) Date: Thu, 13 Feb 2014 16:51:22 +0100 Subject: [erlang-questions] epgsql coordination? In-Reply-To: References: Message-ID: > Does it make sense to have it shown as a fork? I would suggest pushing a new repo there instead of forking from davidw :) I'm not sure how to accomplish that, and to be honest, it is a fork of my repository which I had forked from mabrek's. It'd be cleaner to post his as where it was forked from. I think the first order of business is to see if I can get the tests he had in there working 100%. With tests, it gets easier to move forward without too many worries... -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From kraythe@REDACTED Thu Feb 13 16:52:35 2014 From: kraythe@REDACTED (kraythe .) Date: Thu, 13 Feb 2014 09:52:35 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <20140213081250.GT6490@carfax.org.uk> References: <52FBFC07.8010007@ninenines.eu> <20140213081250.GT6490@carfax.org.uk> Message-ID: All that is true but all the documentation still refers to the long name and people will ask about the long name. When I came to erlang as a newbie I initially looked at OTP and thought that was just for telecom. Something like the whole canonical model movement in XSD. So there is a bit of miscommunication. This is just from the Erlang newbie's perspective. I have been programming professionally for some 20 years and even I had to dig deeper before I found out that OTP was actually just like the core lib in the JDK. *Robert Simmons Jr. MSc. * On Thu, Feb 13, 2014 at 2:12 AM, Hugo Mills wrote: > On Thu, Feb 13, 2014 at 12:22:10PM +1300, Richard A. O'Keefe wrote: > > > > On 13/02/2014, at 11:56 AM, Lo?c Hoguin wrote: > > > > > > > > The same situation exists with many other names. Few can tell you what > SMTP, IMAP, HTTP, REST, SOAP, HTML, XML, JPEG, PNG and others stand for > without looking it up and not making a mistake or three. > > > > Let's try. > > > > Simple Mail Transport Protocol > > Internet Message Access Protocol > > HyperText Transfer Protocol > > REpresentational State Transfer > > Simple Object Access Protocol > > to be honest, my first thought was > > Symbolic Optimal Assembly Program, > > but I don't suppose many people use IBM 650s > > these days. > > Officially, it's just "SOAP" these days. It was originally from the > phrase above, but they decided to keep the acronym and drop the > underlying words, because it's not simple and it's not about object > access. > > > HyperText Markup Language > > eXtensible Markup Language > > Joint Photographic Experts Group > > Portable Network Graphics > > > > How did I do? (Really no lookup.) > > Good. 8.5/9 :) > > Hugo. > > -- > === Hugo Mills: hugo@REDACTED carfax.org.uk | darksatanic.net | lug.org.uk === > PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk > --- The makers of Steinway pianos would like me to tell you that --- > this is a Bechstein. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kraythe@REDACTED Thu Feb 13 16:54:25 2014 From: kraythe@REDACTED (kraythe .) Date: Thu, 13 Feb 2014 09:54:25 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <52FBFC07.8010007@ninenines.eu> References: <52FBFC07.8010007@ninenines.eu> Message-ID: You would be surprised how many dorks in companies will fail you in an interview for not knowing the full acronym expansion. As a result the only one I had to look up was, in fact, OTP. *Robert Simmons Jr. MSc.* On Wed, Feb 12, 2014 at 4:56 PM, Lo?c Hoguin wrote: > Historically OTP meant Open Telecom Platform. > > Today OTP means OTP. People don't use the name OTP as initials of > anything. When they say OTP, they refer to a framework for building highly > available fault tolerant distributed systems. > > The same situation exists with many other names. Few can tell you what > SMTP, IMAP, HTTP, REST, SOAP, HTML, XML, JPEG, PNG and others stand for > without looking it up and not making a mistake or three. And it doesn't > matter, the abbreviated name is the one that is used by people, and it's > the one that holds the meaning. Do you think "Joint Photographic Experts > Group" is a good name for an image file format? I think not, but it doesn't > matter, because people call it JPEG. > > And just like it, what OTP initially meant doesn't matter, because people > refer to the framework as OTP, not as Open Telecom Platform. > > > On 02/12/2014 11:04 PM, kraythe . wrote: > >> I am a newbie to Erlang so pardon if the question comes off as >> impertinent. >> However, as I read more into OTP and see the power it has, I am more and >> more irked by its name. The Open Telephony Platform seems to be a little >> limited and I wonder if it would put off people trying to adopt Erlang for >> other use cases. >> >> I am wondering wouldn't it be better to call it the Open Technology >> Platform? The same initials can be used, but the understanding would be >> that the platform would be a general purpose library (which it is) useful >> for many endeavors, not just writing a phone switch. >> >> Sure it might seem trivial but any marketing guy will tell you, naming is >> sometimes everything. So am I nuts here? >> >> >> *Robert Simmons Jr. MSc.* >> >> >> >> >> _______________________________________________ >> 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 g@REDACTED Thu Feb 13 17:02:33 2014 From: g@REDACTED (Garrett Smith) Date: Thu, 13 Feb 2014 10:02:33 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <20140213134727.GH62889@ferdair.local> References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <20140213134727.GH62889@ferdair.local> Message-ID: On Thu, Feb 13, 2014 at 7:47 AM, Fred Hebert wrote: > On 02/13, Garrett Smith wrote: >> What sucks IMO is that OTP is treated as "advanced" by the community >> and by book authors. I understand the history of this, but there's a >> cost: programmers delay learning core Erlang principles of >> *applications* -- i.e. supervisor trees -- because it's not taught up. >> It's also incredibly complicated, if you don't use e2. >> >> The irony is that *advanced* Erlang programmers can get away >> programming outside the OTP guard rails. Beginners should not even >> consider doing this until they understand why OTP works and why they >> should deviate. >> > > To me that's often a required step. Plenty of programmers do not know or > aren't comfortable with: > > - Pattern matching > - Recursion > - Higher Order Functions > - Anonymous functions > - Principles of concurrency > - Principles of distribution > - Prolog-like Syntax > - Expression-based conditionals (case/if) > - Single Assignment > - Immutability (and the lack for while and for loops) > - Not using objects Fred, I completely agree with you and I should have be clearer. I'm not suggesting that the predominating material, which starts with lower level language constructs and moves up the complexity chain, is wrong. It's right. It's the way most languages are taught. Well, what's *right* is that everyone learns differently and there's lots of ways to approach a problem. I've just found that "OTP" is treated as the thing-you-learn later, which has tended to result in a lot Erlang developers who write non compliant OTP code, which basically means that processes aren't properly supervised. That's a raw deal for these folks. But the code you have to write to be OTP compliant is a bear. It's silly complicated. I've *figuratively* seen student's heads explode when OTP was introduced too soon. So you're 100% correct. I think if we can get a vey simply hello world app going, that's a full blown OTP application, we'd have the best of both worlds -- a simple starting point that elaborates the essential principles of supervised processes. The hello world task here is not nearly simple enough, but it's a *huge* improvement IMO over what you'd see using gen_server: http://e2project.org/quick_start.html It's an attempt to move things in what I think is an important directly. There's no doubt that people can learn effectively taking different angles at a problem -- and the exiting learning material, books, online resources, etc. are the reason we have an Erlang community today, at all. I didn't mean to take a shot at any of this. Garrett From g@REDACTED Thu Feb 13 17:07:33 2014 From: g@REDACTED (Garrett Smith) Date: Thu, 13 Feb 2014 10:07:33 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <20140213104806.GD2928@xenocorp> References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <21AD9393-44EF-4C42-A39D-B242D93ECEBE@gmail.com> <20140213104806.GD2928@xenocorp> Message-ID: On Thu, Feb 13, 2014 at 4:48 AM, Aaron France wrote: > This whole thread is a waste of time. There are some topics *in* this thread that I think are very important. For my part, I'm continually surprised and frustrated at Erlang's relatively low adoption, especially given it's merits. It's one of those crazy Universe ironies. I think steps that we, and Ericsson, can take to chip away at barriers to adoption, friction to learning, etc. are worth while. > What the hell has happened to this list? Now, now -- someone will post a juicy technical gem soon enough :) From g@REDACTED Thu Feb 13 17:14:44 2014 From: g@REDACTED (Garrett Smith) Date: Thu, 13 Feb 2014 10:14:44 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <52FCA60D.9020904@ninenines.eu> References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> Message-ID: On Thu, Feb 13, 2014 at 5:01 AM, Lo?c Hoguin wrote: > No I'm serious, you can use Erlang without OTP. When the VM starts it loads > the boot file which contains instructions on what modules to preload, what > applications to start and so on. Make an empty boot file and look at what > happens, most likely it will complain about the lists module missing. Then > add your own lists module and try again. It will also complain about no > error logger being present. Etc. Ah, I *knew* you were going to say this. Of course you're right, and I admit I was trolling you ever so slightly :) But come on, the point is in the public facing and predominating use of "OTP" to represent a "framework". If you have to disassemble the machinery of Erlang to get out from this so called framework, it ain't a framework. Garrett From kraythe@REDACTED Thu Feb 13 17:20:35 2014 From: kraythe@REDACTED (kraythe .) Date: Thu, 13 Feb 2014 10:20:35 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <28AAEE0D-905F-4681-B388-7C883CCBA7D3@gmail.com> References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <28AAEE0D-905F-4681-B388-7C883CCBA7D3@gmail.com> Message-ID: *Java as a language is big and complex, because it has a lot of concepts > directly inside the language.* Ahh but here you are wrong. Java itself is analogous to Erlang without OTP. you don't HAVE to use the JDK libraries beyond java.lang. You would be a bit crazy reproducing the wheel if you did so but it is not a requirement of writing java. In fact many Java controlled micro devices only allow a very small subset of the JDK to be used. So there is essentially no difference. So Elang is to Java as the Java Development Kit is to the Open Telecom Platform. And there is where we have the "marketing" disconnect. Its not about changing functionality or a triviality to be scoffed over. If we start with the premise that we want more developers to learn and use Erlang then we have to consider how the language and its nomenclature comes across to our audience. You don't name a language the Scalable High Integration Technology because the impression it leaves with adopters is ... unfortunate. So if you DON'T care about people adopting the language, then the discussion is academic and simply, as one reply put it, a waste of time. Of course if you don't care about adoption then you are wasting your time here because you wont be able to staff a development crew, replace developers that leave or push the language into an organization which isn't currently using it. If you DO care about people adopting the language you have to consider its marketing. If I many were to take Erlang to management and propose it for a product the management would see "Open Telecom Platform", object that the company isn't a telecom company and that Erlang is mainly for telecom and that would be the end of that. In fact, if you really care about adoption you are better off renaming it "Fred" than leaving it as "Open Telecom Platform". Naming matters and it is also pretty easy to fix. *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* *Author of: Hardcore Java (2003) and Maintainable Java (2012)* *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 * On Thu, Feb 13, 2014 at 9:03 AM, Anthony Ramine wrote: > That's a *HUGE* difference. Erlang as a language is very small; OTP is a > very complex piece of software, as is BEAM. The three shouldn't be > conflated. > > Java as a language is big and complex, because it has a lot of concepts > directly inside the language. > > -- > Anthony Ramine > > Le 13 f?vr. 2014 ? 15:59, Vlad Dumitrescu a ?crit : > > > On Thu, Feb 13, 2014 at 3:46 PM, Anthony Ramine > wrote: > >> Java without OOP is a different language. > >> Erlang without OTP is still Erlang. > > > > IMHO the only difference is that OTP is implemented as a library and > > doesn't have dedicated language syntax. I make difference between OTP > > as design/system building guidelines and its implementation. The > > former is more like OOP for Java. The latter is more like the JDK. > > > > /Vlad > > > >> -- > >> Anthony Ramine > >> > >> Le 13 f?vr. 2014 ? 15:21, Vlad Dumitrescu a ?crit > : > >> > >>> On Thu, Feb 13, 2014 at 2:09 PM, Benoit Chesneau > wrote: > >>>> I also say Erlang/OTP and often I add to the one that ask that OTP is > >>>> a framework, but then people are more puzzled than they were before. > >>>> Maybe rust did the right things by clearly separating the language > >>>> and the runtime from the standard library and other libs ? > >>> > >>> I would say that OTP is to Erlang what OOP is to Java. You can write > >>> Java programs that are not object-oriented, but why choose Java for > >>> that in the first place? > >>> > >>> OTP is in my opinion a design philosophy that guides us when it comes > >>> to structuring and developing distributed fault-tolerant systems. It > >>> comes with library support that is intimately tied to the Erlang > >>> libraries: the most basic Erlang apps (kernel and stdlib) are also the > >>> ones that implement the OTP concepts. Even more, Erlang code is > >>> structured as applications, and an "application" is an OTP concept! > >>> > >>> I can only see meaning in trying to separate the language from OTP > >>> either as an academic exercise or in order to implement a different > >>> language on the beam runtime and the new concepts would collide > >>> implementation-wise with OTP. Or one wants to create OTP 2.0 without > >>> interference with 1.0. > >>> > >>> 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 mabrek@REDACTED Thu Feb 13 17:23:40 2014 From: mabrek@REDACTED (Anton Lebedevich) Date: Thu, 13 Feb 2014 20:23:40 +0400 Subject: [erlang-questions] epgsql coordination? In-Reply-To: References: Message-ID: <52FCF18C.30504@gmail.com> On 02/13/2014 07:51 PM, David Welton wrote: >> Does it make sense to have it shown as a fork? I would suggest pushing a new repo there instead of forking from davidw :) > > I'm not sure how to accomplish that, and to be honest, it is a fork of > my repository which I had forked from mabrek's. It'd be cleaner to > post his as where it was forked from. > > I think the first order of business is to see if I can get the tests > he had in there working 100%. With tests, it gets easier to move > forward without too many worries... Timeout tests are broken in my fork (mabrek/epgsql) because I haven't implemented timeout support yet. Client side timeouts turned out to be quite complicated in asynchronous model. Maybe we need to steal ideas from semiocast/pgsql and use server-side timeouts? These tests pass in original (wg/epgsql) but timeout support is not complete there too (there are situations when connection could stuck after timeout). Regards, Anton Lebedevich. From vladdu55@REDACTED Thu Feb 13 17:26:02 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 13 Feb 2014 17:26:02 +0100 Subject: [erlang-questions] FW: Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <52FCC466.9060206@erlang.org> References: <52F4C173.8050408@erlang.org> <1391790979.26271.YahooMailNeo@web140106.mail.bf1.yahoo.com> <49EC93AB-69A4-49AB-A2C0-4DA9F418E3F6@gmail.com> <58912684E2630B45963406CF7D8C52581C3473C6@ESESSMB103.ericsson.se> <52FB2C0E.90008@erlang.org> <58912684E2630B45963406CF7D8C52581C348431@ESESSMB103.ericsson.se> <52FCC466.9060206@erlang.org> Message-ID: Hi Andreas, I would prefer to be able to check the version without starting erlang. Would it be possible to add a property to the start script? The "OTP APN 181 01" is useless anyway :-) /Vlad On Thu, Feb 13, 2014 at 2:11 PM, Andreas Schumacher wrote: > Re: otp_version: In addition to erlang:system_info(otp_correction_package), > a corresponding flag "otp_version" - similar to [emulator] "version" - is > going to be added to the erl command, in order to allow the extraction of > the complete version number from command line tools. Other additions to > extract the Erlang/OTP version have not been planned. > > Re: 17.0.0 =?= 17.0: Yes, they are the same. We could have used the extra > ".0", but we chose not to. > > Andreas > > ---------- > Andreas Schumacher, Erlang/OTP, Ericsson AB > >> >> -----Original Message----- >> From: Vlad Dumitrescu [mailto:vladdu55@REDACTED] >> Sent: den 13 februari 2014 10:35 >> To: Andreas Schumacher >> Cc: Anthony Ramine; erlang-questions; Rickard Green >> Subject: Re: [erlang-questions] Version numbering scheme change and the >> implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. >> >> Hi! >> >> A couple of more questions about versins: >> >> - how can we find the otp_version without starting erlang? otp_release is >> in the start scripts, but I can't find anywhere "17.0-rc1"... >> - is 17.0.0 the same as 17.0? Is it a problem to use the extra ".0"? >> >> regards, >> Vlad >> >> >> On Wed, Feb 12, 2014 at 9:08 AM, Andreas Schumacher >> wrote: >>> >>> From the versioning clarification mail that I sent on behalf of the >>> OTP team to the list on February 7: >>> >>> >>> "The new version scheme is *not* semantic versioning; although, it has >>> been inspired by it. We do not want to use semantic versioning (as >>> defined by >>> http://semver.org/) out of the box since it does not fit our needs." >>> >>> Andreas Schumacher >>> Erlang/OTP, Ericsson AB >>> >>>> -----Original Message----- >>>> From: erlang-questions-bounces@REDACTED >>>> [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Anthony >>>> Ramine >>>> Sent: den 12 februari 2014 02:48 >>>> To: Rickard Green >>>> Cc: erlang-questions@REDACTED >>>> Subject: Re: [erlang-questions] Version numbering scheme change and >>>> the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. >>>> >>>> So OTP won't follow semantic versioning, right? >>>> >>>> Just seeking confirmation about semver. >>>> >>>> Regards, >>>> >>>> -- >>>> Anthony Ramine >>>> >>>> Le 12 f?vr. 2014 ? 00:43, Rickard Green a ?crit : >>>> >>>>> As of OTP 17 we drop this patch level number sequence and start >>>>> using one set of patch level numbers per release. The patch level is >>>>> not expressed as an integer as it used to be, but instead as a >>>>> version number ..[. ...], for example, 17.0.1. This way >>>>> the patch level gives you a bit more information. You can for >>>>> example see directly which OTP release it applies to. This patch >>>>> level version number also replace the - tar-ball naming scheme. >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions > > From essen@REDACTED Thu Feb 13 17:28:42 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 13 Feb 2014 17:28:42 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <28AAEE0D-905F-4681-B388-7C883CCBA7D3@gmail.com> Message-ID: <52FCF2BA.1020104@ninenines.eu> On 02/13/2014 05:20 PM, kraythe . wrote: > Naming matters and it is also pretty easy to fix. Naming matters, yes. It being easy to fix, hell no. You're not even talking to the right people about it here. You'd need to convince Ericsson, and by that I don't mean the OTP team, but their bosses' bosses (and perhaps a few levels more) that changing the name of that small project they run (small compared to everything they do, of course) would be good for *them*. If you achieve that, you'd simply become a legend long remembered in the history books. -- Lo?c Hoguin http://ninenines.eu From n.oxyde@REDACTED Thu Feb 13 17:28:59 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 13 Feb 2014 17:28:59 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <28AAEE0D-905F-4681-B388-7C883CCBA7D3@gmail.com> Message-ID: Replied inline. -- Anthony Ramine Le 13 f?vr. 2014 ? 17:20, kraythe . a ?crit : > Ahh but here you are wrong. Java itself is analogous to Erlang without OTP. you don't HAVE to use the JDK libraries beyond java.lang. You would be a bit crazy reproducing the wheel if you did so but it is not a requirement of writing java. In fact many Java controlled micro devices only allow a very small subset of the JDK to be used. So there is essentially no difference. What? I never once wrote about the JDK, I wrote about *Java the language*, which spec is quite significant, how many keywords and different things are there in Java? Classes, interfaces, public methods, private methods, protected methods, static fields, static methods, etc, etc, etc, ad nauseam. This is *way larger* than Erlang the language. Java without OOP isn?t Java. Java without the JDK is still Java. > > Naming matters and it is also pretty easy to fix. It is certainly not easy to fix, how many documents, online and offline, would need to be rewritten? How many books to print? How many old timers to inform? How much time lost explaining more historical stuff in talks? From john@REDACTED Thu Feb 13 17:33:22 2014 From: john@REDACTED (John Kemp) Date: Thu, 13 Feb 2014 11:33:22 -0500 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <28AAEE0D-905F-4681-B388-7C883CCBA7D3@gmail.com> Message-ID: <796EBF0D-8EE3-446F-AEB0-DEF64701311F@jkemp.net> On Feb 13, 2014, at 11:20 AM, kraythe . wrote: > Java as a language is big and complex, because it has a lot of concepts directly inside the language. > > Ahh but here you are wrong. Java itself is analogous to Erlang without OTP. you don't HAVE to use the JDK libraries beyond java.lang. You would be a bit crazy reproducing the wheel if you did so but it is not a requirement of writing java. In fact many Java controlled micro devices only allow a very small subset of the JDK to be used. So there is essentially no difference. > > So Elang is to Java as the Java Development Kit is to the Open Telecom Platform. And there is where we have the "marketing" disconnect. Its not about changing functionality or a triviality to be scoffed over. If we start with the premise that we want more developers to learn and use Erlang then we have to consider how the language and its nomenclature comes across to our audience. You don't name a language the Scalable High Integration Technology because the impression it leaves with adopters is ... unfortunate. Why start with that premise instead of starting with the premise that developers should try to understand what is useful to them? That has nothing to do with marketing, and everything to do with software developers understanding their craft better. > > So if you DON'T care about people adopting the language, then the discussion is academic and simply, as one reply put it, a waste of time. Of course if you don't care about adoption then you are wasting your time here because you wont be able to staff a development crew, replace developers that leave or push the language into an organization which isn't currently using it. Who is ?you? in this case? Does the ?Erlang community? want to get the language adopted more? Perhaps. Why would that matter to the Erlang community - how do they benefit? Why should those who already know and benefit from Erlang not simply continue to do so? > > If you DO care about people adopting the language you have to consider its marketing. If I many were to take Erlang to management and propose it for a product the management would see "Open Telecom Platform", object that the company isn't a telecom company and that Erlang is mainly for telecom and that would be the end of that. In fact, if you really care about adoption you are better off renaming it "Fred" than leaving it as "Open Telecom Platform?. People reject languages for all kinds of strange reasons. And it?s the case that in many cases you can simply choose ?a language you like? and then *make* it work for what you want to do. After all, computers have particular resources available to them, and a language well-adapted to its environment should support adequate performance for most applications. The distinction between threading in Ruby and ?event-driven? in Node is largely meaningless, for example. The real questions are things like ?how well does your VM/compiler exploit computer hardware resources on the platform you?re using?. Most developers don?t understand this, so they argue about threads vs. processes vs. events without understanding what might actually be the critical differences regarding the performance they say they want. Naming won?t fix that. And management will never get that. You need people to understand what they are doing. Or not. After all, you can largely do what you like and apart from at the edges, it will likely work. - johnk > > Naming matters and it is also pretty easy to fix. > > Robert Simmons Jr. MSc. - Lead Java Architect @ EA > Author of: Hardcore Java (2003) and Maintainable Java (2012) > LinkedIn: http://www.linkedin.com/pub/robert-simmons/40/852/a39 > > > On Thu, Feb 13, 2014 at 9:03 AM, Anthony Ramine wrote: > That?s a *HUGE* difference. Erlang as a language is very small; OTP is a very complex piece of software, as is BEAM. The three shouldn?t be conflated. > > Java as a language is big and complex, because it has a lot of concepts directly inside the language. > > -- > Anthony Ramine > > Le 13 f?vr. 2014 ? 15:59, Vlad Dumitrescu a ?crit : > > > On Thu, Feb 13, 2014 at 3:46 PM, Anthony Ramine wrote: > >> Java without OOP is a different language. > >> Erlang without OTP is still Erlang. > > > > IMHO the only difference is that OTP is implemented as a library and > > doesn't have dedicated language syntax. I make difference between OTP > > as design/system building guidelines and its implementation. The > > former is more like OOP for Java. The latter is more like the JDK. > > > > /Vlad > > > >> -- > >> Anthony Ramine > >> > >> Le 13 f?vr. 2014 ? 15:21, Vlad Dumitrescu a ?crit : > >> > >>> On Thu, Feb 13, 2014 at 2:09 PM, Benoit Chesneau wrote: > >>>> I also say Erlang/OTP and often I add to the one that ask that OTP is > >>>> a framework, but then people are more puzzled than they were before. > >>>> Maybe rust did the right things by clearly separating the language > >>>> and the runtime from the standard library and other libs ? > >>> > >>> I would say that OTP is to Erlang what OOP is to Java. You can write > >>> Java programs that are not object-oriented, but why choose Java for > >>> that in the first place? > >>> > >>> OTP is in my opinion a design philosophy that guides us when it comes > >>> to structuring and developing distributed fault-tolerant systems. It > >>> comes with library support that is intimately tied to the Erlang > >>> libraries: the most basic Erlang apps (kernel and stdlib) are also the > >>> ones that implement the OTP concepts. Even more, Erlang code is > >>> structured as applications, and an "application" is an OTP concept! > >>> > >>> I can only see meaning in trying to separate the language from OTP > >>> either as an academic exercise or in order to implement a different > >>> language on the beam runtime and the new concepts would collide > >>> implementation-wise with OTP. Or one wants to create OTP 2.0 without > >>> interference with 1.0. > >>> > >>> 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 > > _______________________________________________ > 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 Feb 13 17:41:03 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 13 Feb 2014 11:41:03 -0500 Subject: [erlang-questions] FW: Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: <52F4C173.8050408@erlang.org> <1391790979.26271.YahooMailNeo@web140106.mail.bf1.yahoo.com> <49EC93AB-69A4-49AB-A2C0-4DA9F418E3F6@gmail.com> <58912684E2630B45963406CF7D8C52581C3473C6@ESESSMB103.ericsson.se> <52FB2C0E.90008@erlang.org> <58912684E2630B45963406CF7D8C52581C348431@ESESSMB103.ericsson.se> <52FCC466.9060206@erlang.org> Message-ID: <20140213164102.GJ62889@ferdair.local> ? erl -noshell -eval 'io:format("~s~n",[erlang:system_info(otp_correction_package)]),halt(0).' 17.0-rc1 It is objectively longer than having -V switch, loads more content, but gets the result you want as one command line option. Adding in the options '-noinput +A 0 -smp disable' to the command brings it below 0.15s on my VPS, usually below something noticeable. Maybe that will be enough. Regards, Fred. On 02/13, Vlad Dumitrescu wrote: > Hi Andreas, > > I would prefer to be able to check the version without starting > erlang. Would it be possible to add a property to the start script? > The "OTP APN 181 01" is useless anyway :-) > > /Vlad > > On Thu, Feb 13, 2014 at 2:11 PM, Andreas Schumacher wrote: > > Re: otp_version: In addition to erlang:system_info(otp_correction_package), > > a corresponding flag "otp_version" - similar to [emulator] "version" - is > > going to be added to the erl command, in order to allow the extraction of > > the complete version number from command line tools. Other additions to > > extract the Erlang/OTP version have not been planned. > > > > Re: 17.0.0 =?= 17.0: Yes, they are the same. We could have used the extra > > ".0", but we chose not to. > > > > Andreas > > > > ---------- > > Andreas Schumacher, Erlang/OTP, Ericsson AB > > > >> > >> -----Original Message----- > >> From: Vlad Dumitrescu [mailto:vladdu55@REDACTED] > >> Sent: den 13 februari 2014 10:35 > >> To: Andreas Schumacher > >> Cc: Anthony Ramine; erlang-questions; Rickard Green > >> Subject: Re: [erlang-questions] Version numbering scheme change and the > >> implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. > >> > >> Hi! > >> > >> A couple of more questions about versins: > >> > >> - how can we find the otp_version without starting erlang? otp_release is > >> in the start scripts, but I can't find anywhere "17.0-rc1"... > >> - is 17.0.0 the same as 17.0? Is it a problem to use the extra ".0"? > >> > >> regards, > >> Vlad > >> > >> > >> On Wed, Feb 12, 2014 at 9:08 AM, Andreas Schumacher > >> wrote: > >>> > >>> From the versioning clarification mail that I sent on behalf of the > >>> OTP team to the list on February 7: > >>> > >>> > >>> "The new version scheme is *not* semantic versioning; although, it has > >>> been inspired by it. We do not want to use semantic versioning (as > >>> defined by > >>> http://semver.org/) out of the box since it does not fit our needs." > >>> > >>> Andreas Schumacher > >>> Erlang/OTP, Ericsson AB > >>> > >>>> -----Original Message----- > >>>> From: erlang-questions-bounces@REDACTED > >>>> [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Anthony > >>>> Ramine > >>>> Sent: den 12 februari 2014 02:48 > >>>> To: Rickard Green > >>>> Cc: erlang-questions@REDACTED > >>>> Subject: Re: [erlang-questions] Version numbering scheme change and > >>>> the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. > >>>> > >>>> So OTP won't follow semantic versioning, right? > >>>> > >>>> Just seeking confirmation about semver. > >>>> > >>>> Regards, > >>>> > >>>> -- > >>>> Anthony Ramine > >>>> > >>>> Le 12 f?vr. 2014 ? 00:43, Rickard Green a ?crit : > >>>> > >>>>> As of OTP 17 we drop this patch level number sequence and start > >>>>> using one set of patch level numbers per release. The patch level is > >>>>> not expressed as an integer as it used to be, but instead as a > >>>>> version number ..[. ...], for example, 17.0.1. This way > >>>>> the patch level gives you a bit more information. You can for > >>>>> example see directly which OTP release it applies to. This patch > >>>>> level version number also replace the - tar-ball naming scheme. > >>>> > >>>> _______________________________________________ > >>>> 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 kraythe@REDACTED Thu Feb 13 17:44:31 2014 From: kraythe@REDACTED (kraythe .) Date: Thu, 13 Feb 2014 10:44:31 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <796EBF0D-8EE3-446F-AEB0-DEF64701311F@jkemp.net> References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <28AAEE0D-905F-4681-B388-7C883CCBA7D3@gmail.com> <796EBF0D-8EE3-446F-AEB0-DEF64701311F@jkemp.net> Message-ID: Cant agree with you John. In an organization you cant simply do what you want and shrug. If I tried that in any of the big organizations i have been involved with my optimal case is being fired. Perhaps if you own the company you can. But then that relegates Erlang to niche. Makes the old timers feel pretty superior but is a horrible waste of what appears to me to be a very useful language. Also if you go that tact there is no more point of arguing Erlang vs Scala or vs any language anymore. Erlang will become like Smalltalk. Useful and cool for the old timers but virtually IRRELEVANT in the IT industry. Furthermore, if you argue you don't care about adoption then the discussion is moot with you. What it will mean is whomever is on your development staff writing Erlang you better be open to paying them whatever they want and letting them get away with about anything because replacing them would be nearly impossible. Often many tech people cant see past "oooh list comprehensions !!!!!!" to the actual business behind it and without the business none of us get paid. That is not something you can take to management and sell. *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* *Author of: Hardcore Java (2003) and Maintainable Java (2012)* *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 * On Thu, Feb 13, 2014 at 10:33 AM, John Kemp wrote: > On Feb 13, 2014, at 11:20 AM, kraythe . wrote: > > *Java as a language is big and complex, because it has a lot of concepts >> directly inside the language.* > > > > Ahh but here you are wrong. Java itself is analogous to Erlang without > OTP. you don't HAVE to use the JDK libraries beyond java.lang. You would be > a bit crazy reproducing the wheel if you did so but it is not a requirement > of writing java. In fact many Java controlled micro devices only allow a > very small subset of the JDK to be used. So there is essentially no > difference. > > So Elang is to Java as the Java Development Kit is to the Open Telecom > Platform. And there is where we have the "marketing" disconnect. Its not > about changing functionality or a triviality to be scoffed over. If we > start with the premise that we want more developers to learn and use Erlang > then we have to consider how the language and its nomenclature comes across > to our audience. You don't name a language the Scalable High Integration > Technology because the impression it leaves with adopters is ... > unfortunate. > > > Why start with that premise instead of starting with the premise that > developers should try to understand what is useful to them? That has > nothing to do with marketing, and everything to do with software developers > understanding their craft better. > > > > So if you DON'T care about people adopting the language, then the > discussion is academic and simply, as one reply put it, a waste of time. Of > course if you don't care about adoption then you are wasting your time here > because you wont be able to staff a development crew, replace developers > that leave or push the language into an organization which isn't currently > using it. > > > Who is "you" in this case? Does the "Erlang community" want to get the > language adopted more? Perhaps. Why would that matter to the Erlang > community - how do they benefit? Why should those who already know and > benefit from Erlang not simply continue to do so? > > > If you DO care about people adopting the language you have to consider its > marketing. If I many were to take Erlang to management and propose it for a > product the management would see "Open Telecom Platform", object that the > company isn't a telecom company and that Erlang is mainly for telecom and > that would be the end of that. In fact, if you really care about adoption > you are better off renaming it "Fred" than leaving it as "Open Telecom > Platform". > > > People reject languages for all kinds of strange reasons. And it's the > case that in many cases you can simply choose "a language you like" and > then *make* it work for what you want to do. After all, computers have > particular resources available to them, and a language well-adapted to its > environment should support adequate performance for most applications. The > distinction between threading in Ruby and "event-driven" in Node is largely > meaningless, for example. The real questions are things like "how well does > your VM/compiler exploit computer hardware resources on the platform you're > using". Most developers don't understand this, so they argue about threads > vs. processes vs. events without understanding what might actually be the > critical differences regarding the performance they say they want. > > Naming won't fix that. And management will never get that. You need people > to understand what they are doing. Or not. After all, you can largely do > what you like and apart from at the edges, it will likely work. > > - johnk > > > Naming matters and it is also pretty easy to fix. > > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* > *Author of: Hardcore Java (2003) and Maintainable Java (2012)* > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 > * > > > On Thu, Feb 13, 2014 at 9:03 AM, Anthony Ramine wrote: > >> That's a *HUGE* difference. Erlang as a language is very small; OTP is a >> very complex piece of software, as is BEAM. The three shouldn't be >> conflated. >> >> Java as a language is big and complex, because it has a lot of concepts >> directly inside the language. >> >> -- >> Anthony Ramine >> >> Le 13 f?vr. 2014 ? 15:59, Vlad Dumitrescu a ?crit : >> >> > On Thu, Feb 13, 2014 at 3:46 PM, Anthony Ramine >> wrote: >> >> Java without OOP is a different language. >> >> Erlang without OTP is still Erlang. >> > >> > IMHO the only difference is that OTP is implemented as a library and >> > doesn't have dedicated language syntax. I make difference between OTP >> > as design/system building guidelines and its implementation. The >> > former is more like OOP for Java. The latter is more like the JDK. >> > >> > /Vlad >> > >> >> -- >> >> Anthony Ramine >> >> >> >> Le 13 f?vr. 2014 ? 15:21, Vlad Dumitrescu a >> ?crit : >> >> >> >>> On Thu, Feb 13, 2014 at 2:09 PM, Benoit Chesneau >> wrote: >> >>>> I also say Erlang/OTP and often I add to the one that ask that OTP is >> >>>> a framework, but then people are more puzzled than they were before. >> >>>> Maybe rust did the right things by clearly separating the language >> >>>> and the runtime from the standard library and other libs ? >> >>> >> >>> I would say that OTP is to Erlang what OOP is to Java. You can write >> >>> Java programs that are not object-oriented, but why choose Java for >> >>> that in the first place? >> >>> >> >>> OTP is in my opinion a design philosophy that guides us when it comes >> >>> to structuring and developing distributed fault-tolerant systems. It >> >>> comes with library support that is intimately tied to the Erlang >> >>> libraries: the most basic Erlang apps (kernel and stdlib) are also the >> >>> ones that implement the OTP concepts. Even more, Erlang code is >> >>> structured as applications, and an "application" is an OTP concept! >> >>> >> >>> I can only see meaning in trying to separate the language from OTP >> >>> either as an academic exercise or in order to implement a different >> >>> language on the beam runtime and the new concepts would collide >> >>> implementation-wise with OTP. Or one wants to create OTP 2.0 without >> >>> interference with 1.0. >> >>> >> >>> 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 >> > > _______________________________________________ > 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 Thu Feb 13 17:49:50 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 13 Feb 2014 17:49:50 +0100 Subject: [erlang-questions] FW: Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <20140213164102.GJ62889@ferdair.local> References: <52F4C173.8050408@erlang.org> <1391790979.26271.YahooMailNeo@web140106.mail.bf1.yahoo.com> <49EC93AB-69A4-49AB-A2C0-4DA9F418E3F6@gmail.com> <58912684E2630B45963406CF7D8C52581C3473C6@ESESSMB103.ericsson.se> <52FB2C0E.90008@erlang.org> <58912684E2630B45963406CF7D8C52581C348431@ESESSMB103.ericsson.se> <52FCC466.9060206@erlang.org> <20140213164102.GJ62889@ferdair.local> Message-ID: On Thu, Feb 13, 2014 at 5:41 PM, Fred Hebert wrote: > ? erl -noshell -eval 'io:format("~s~n",[erlang:system_info(otp_correction_package)]),halt(0).' > 17.0-rc1 > > It is objectively longer than having -V switch, loads more content, but > gets the result you want as one command line option. Adding in the > options '-noinput +A 0 -smp disable' to the command brings it below > 0.15s on my VPS, usually below something noticeable. Thanks, but my use case is to have a number of erlang installations and detect which version each is (looking at the directory name doesn't always help). 0.15s*5 is noticeable and it's not that fast on all filesystems (think clearcase)... Of course, I have this workaround as backup. The issue is that the information was available before, but is going away now with the new version scheme. regards, Vlad From mahesh@REDACTED Thu Feb 13 17:52:16 2014 From: mahesh@REDACTED (Mahesh Paolini-Subramanya) Date: Thu, 13 Feb 2014 17:52:16 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <28AAEE0D-905F-4681-B388-7C883CCBA7D3@gmail.com> Message-ID: Marketing matters - true. So lets look at the reality of the market. Every java project that gets worked on probably creates an ongoing demand for, int(X/5 + 3) new java developers, where X is the number of developers on the original project (1). From an economics perspective, this translates to a market where ?- it pays to write applications in java (they may break, but you can probably find people to help fix it) ?- it pays to be a java consulting firm (you have no trouble finding clients) - it pays to learn java (?cos you?ll get hired by a consulting firm for a pittance, no matter how terrible you are?) In short, the Markets for Java are constantly expanding - new projects being worked on, leading to new developers coming in the mix, etc. On the other hand, every project that gets written in Erlang probably (and typically) creates an ongoing demand for rem(1/Y) + 1 developers, where Y is the number of DevOps people you already have.. From an economics perspective, this translates to a market where ?- it pays to write applications in erlang (they don?t break, so you don?t really need to find people to hire) (2) ?- it DOESN?T pay to be an erlang consulting form (with apologies to ESL) In short, the markets for Erlang are *not* growing - there tends to be a fairly stable supply of developers moving from project to project, and the number of new?developers, while growing, is by no means growing rapidly - and thats largely because there is no *need* for large numbers of new developers. (And Garrett - thats the answer to why you don?t see more uptake) What does this have to do with marketing? Basically that kraythe may be on to something here. ?If we want a large uptake for erlang, it is *not* going to be because of the inherent quality. ?If anything, the very stability that erlang is diametrically opposed to its market expansion! In short, erlang needs to be sold on *other* merits, on polish, on gleam, on lustre, on coolness. Take a lesson from DeBeers?- sell the shine, not the content. Cheers (1) Maintenance, JDK management in production, bug fixes, support, and god-forbid, any issues in it being a distributed system (2) Ok. Yes, they break. But that doesn?t really matter, because in the Erlang world, ?good enough? is actually a feasible construct, and one that you can get away with. Its also one of the reason that so many of the erlang projects tend to be about 80% of the way there - because they?re Good Enough, and you?re productive enough that you don?t need to worry about the remaining 20%. ? Let It Crash actually works as a philosophy (and kids, don?t try that with Ruby. Or Assembler. Or C++. Or, well, anything not Erlang) Mahesh Paolini-Subramanya That tall bald Indian guy.. Google+? |?Blog?? |?Twitter? |?LinkedIn On February 13, 2014 at 5:20:47 PM, kraythe . (kraythe@REDACTED) wrote: Java as a language is big and complex, because it has a lot of concepts directly inside the language. ? Ahh but here you are wrong. Java itself is analogous to Erlang without OTP. you don't HAVE to use the JDK libraries beyond java.lang. You would be a bit crazy reproducing the wheel if you did so but it is not a requirement of writing java. In fact many Java controlled micro devices only allow a very small subset of the JDK to be used. So there is essentially no difference.? So Elang is to Java as the Java Development Kit is to the Open Telecom Platform. And there is where we have the "marketing" disconnect. Its not about changing functionality or a triviality to be scoffed over. If we start with the premise that we want more developers to learn and use Erlang then we have to consider how the language and its nomenclature comes across to our audience. You don't name a language the Scalable High Integration Technology because the impression it leaves with adopters is ... unfortunate.? So if you DON'T care about people adopting the language, then the discussion is academic and simply, as one reply put it, a waste of time. Of course if you don't care about adoption then you are wasting your time here because you wont be able to staff a development crew, replace developers that leave or push the language into an organization which isn't currently using it.? If you DO care about people adopting the language you have to consider its marketing. If I many were to take Erlang to management and propose it for a product the management would see "Open Telecom Platform", object that the company isn't a telecom company and that Erlang is mainly for telecom and that would be the end of that. ?In fact, if you really care about adoption you are better off renaming it "Fred" than leaving it as "Open Telecom Platform". Naming matters and it is also pretty easy to fix. Robert Simmons Jr. MSc. - Lead Java Architect @ EA Author of: Hardcore Java (2003) and Maintainable Java (2012) LinkedIn:?http://www.linkedin.com/pub/robert-simmons/40/852/a39 On Thu, Feb 13, 2014 at 9:03 AM, Anthony Ramine wrote: That?s a *HUGE* difference. Erlang as a language is very small; OTP is a very complex piece of software, as is BEAM. The three shouldn?t be conflated. Java as a language is big and complex, because it has a lot of concepts directly inside the language. -- Anthony Ramine Le 13 f?vr. 2014 ? 15:59, Vlad Dumitrescu a ?crit : > On Thu, Feb 13, 2014 at 3:46 PM, Anthony Ramine wrote: >> Java without OOP is a different language. >> Erlang without OTP is still Erlang. > > IMHO the only difference is that OTP is implemented as a library and > doesn't have dedicated language syntax. I make difference between OTP > as design/system building guidelines and its implementation. The > former is more like OOP for Java. The latter is more like the JDK. > > /Vlad > >> -- >> Anthony Ramine >> >> Le 13 f?vr. 2014 ? 15:21, Vlad Dumitrescu a ?crit : >> >>> On Thu, Feb 13, 2014 at 2:09 PM, Benoit Chesneau wrote: >>>> I also say Erlang/OTP and often I add to the one that ask that OTP is >>>> a framework, but then people are more puzzled than they were before. >>>> Maybe rust did the right things by ?clearly separating the language >>>> and the runtime from the standard library and other libs ? >>> >>> I would say that OTP is to Erlang what OOP is to Java. You can write >>> Java programs that are not object-oriented, but why choose Java for >>> that in the first place? >>> >>> OTP is in my opinion a design philosophy that guides us when it comes >>> to structuring and developing distributed fault-tolerant systems. It >>> comes with library support that is intimately tied to the Erlang >>> libraries: the most basic Erlang apps (kernel and stdlib) are also the >>> ones that implement the OTP concepts. Even more, Erlang code is >>> structured as applications, and an "application" is an OTP concept! >>> >>> I can only see meaning in trying to separate the language from OTP >>> either as an academic exercise or in order to implement a different >>> language on the beam runtime and the new concepts would collide >>> implementation-wise with OTP. Or one wants to create OTP 2.0 without >>> interference with 1.0. >>> >>> 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 _______________________________________________ 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 Thu Feb 13 17:52:28 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Thu, 13 Feb 2014 18:52:28 +0200 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <1392294854.4863.17.camel@sekic1152.release> References: <1392294854.4863.17.camel@sekic1152.release> Message-ID: <06E48267-3EB9-4EF5-8E60-66004DF36EC5@gmail.com> Hello, You can check my template engine based on whiskers.js notation http://github.com/fogfish/swirl Best Regards, Dmitry >-|-|-(*> > On 13.2.2014, at 14.34, Bengt Kleberg wrote: > > Greetings, > > Is there an Erlang library that allows me to generate HTML from Erlang > and that can stop ">" from turning into ">"? > > Previously I used > xmerl:export_simple( [{html, [], [Body]}], xmerl_xml ). > where Body could be {body, [], ["Some text with >"]}. > xmerl will transform ">" into ">", but until now the HTML has worked > well. > > Now I need to keep ">". > > > bengt > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From g@REDACTED Thu Feb 13 17:54:38 2014 From: g@REDACTED (Garrett Smith) Date: Thu, 13 Feb 2014 10:54:38 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <21AD9393-44EF-4C42-A39D-B242D93ECEBE@gmail.com> References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <21AD9393-44EF-4C42-A39D-B242D93ECEBE@gmail.com> Message-ID: On Thu, Feb 13, 2014 at 4:42 AM, Anthony Ramine wrote: > > Le 13 f?vr. 2014 ? 10:51, Garrett Smith a ?crit : > >> Sigh. This *is* confusing. It just is. >> >> Lo?c you *cannot* use Erlang without OTP. The VM starts a system, >> which consists of applications, which are supervisory trees of >> gen_servers. >> >> Supervisors are gen_servers btw. >> >> If you think OTP is optional, look at the first two lines of kernel.erl: >> >> -module(kernel). >> -behaviour(supervisor). >> >> Historically, OTP libraries came after Erlang the language, of course, >> but this so called OTP "framework" is now endemic to Erlang. > > You just proved it's difficult to use Erlang without the stdlib. Erlang is still not OTP. I didn't say that Erlang is OTP. My point is that treating "OTP" as something you learn outside of "Erlang" is not helpful. > In fact, the kernel module isn't even a preloaded module, this means it is not a necessary thing to use Erlang. You could have your own Erlang/E2 if you wanted. I'm not talking about esoteric details of how Erlang is bootstrapped. I'm not talking about what you *can* do with the libraries and tooling. I'm not talking about the language grammar, parsers, tool chain, etc. I'm talking about what nearly 100% of all humans use when the use Erlang, which is a facility for starting a system of OTP applications. *Practically speaking* OTP is *endemic*. And my point is that the OTP distinction is confusing and non-helpful, especially to learners. That you're resorting to technically pedantic points here I think reinforces what I'm saying. >> What sucks IMO is that OTP is treated as "advanced" by the community >> and by book authors. I understand the history of this, but there's a >> cost: programmers delay learning core Erlang principles of >> *applications* -- i.e. supervisor trees -- because it's not taught up. >> It's also incredibly complicated, if you don't use e2. >> >> The irony is that *advanced* Erlang programmers can get away >> programming outside the OTP guard rails. Beginners should not even >> consider doing this until they understand why OTP works and why they >> should deviate. >> >> e2 helps, a lot. > > OTP is a set of building blocks for concurrent and distributed systems. > > Concurrency and distribution are advanced topics. OTP doesn't help with concurrency and distribution. It's there to organize system start up and process life cycle. It's analogous to init and monitoring schemes in operating systems (e.g. systemd, runit, etc.) If you don't care about how your code is started and managed while it's running, you might not about "OTP" -- or you might be a guru rock star. In either case, you're not typical. > Thus OTP is an advanced topic. > >> The whole point of e2 is to simplify the correct use of OTP -- letting >> programmers *start* with applications, supervisors and gen_servers (in >> e2 they're called services and tasks -- simple huh). I know it's >> controversial, but it's controversial to those who have been teaching >> Erlang while this stuff was being baked. I don't run into new learners >> who object to starting with OTP using e2 (though maybe they're just >> being polite -- if you're out there and had problems learning with e2, >> please drop me a line, or yell at me here). > > e2 is a leaky abstraction which you need to deviate from when you need more complex stuff; let's not add an infinity of layers on top of OTP. All abstractions leak. And even with that, e2 actually is pretty tight. The *only* time I don't use e2 is when I don't want to introduce it as a library dependency (e.g. within another small library like a database driver, etc) Have you used e2? Did you run into a specific case that e2_process or e2_task didn't accommodate? And *one thin layer* layer on top of on an interface that is begging to be simplified is certainly not an infinity. >> I agree wholeheartedly with Pieter. It's just Erlang. Keeping the term >> OTP is a historic vestige. We're used to it, but it's a dead weight >> that adds only confusion. > > Erlang itself is dead weight to most in the industry, does that mean we should forgo Erlang altogether? > >> The Ruby / Rails comparison is not accurate. It's more like Rails 1.0 >> / Rails 2.0. > > I have no idea how you would find this accurate. > >> Sadly though, I just don't see "OTP" going away because there's a >> trickle of noise from this list :| > > How do you know there isn't a silent majority who just doesn't care or wouldn't like the OTP team to spend time trying to rewrite history? That sounds quite a dismissal of the opposing opinion in this debate. In fact, I have to admit I wouldn't have replied if not for that sentence. I haven't seen a call for rewriting history. The call is to stop using "OTP" as a meaningful term in the context of Erlang. You and Lo?c have accurately pointed out that it's *possible* to separate a couple layers within Erlang that coincide with this Erlang/OTP division. But it's not *practical* and the practice of treating OTP compliance as something-to-learn-later is bad for Erlang, IMO. I'd like to see an effort to simplify the code and process needed to write OTP compliant code. e2 is I think a reasonable first attempt at that. I would offer it as input to the process. >> I make videos to cope. > > I give value to historic facts and terminology to cope. But as long as you cope. It's the most important thing. Garrett From g@REDACTED Thu Feb 13 17:58:49 2014 From: g@REDACTED (Garrett Smith) Date: Thu, 13 Feb 2014 10:58:49 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> Message-ID: On Thu, Feb 13, 2014 at 8:59 AM, Vlad Dumitrescu wrote: > On Thu, Feb 13, 2014 at 3:46 PM, Anthony Ramine wrote: >> Java without OOP is a different language. >> Erlang without OTP is still Erlang. > > IMHO the only difference is that OTP is implemented as a library and > doesn't have dedicated language syntax. I make difference between OTP > as design/system building guidelines and its implementation. The > former is more like OOP for Java. The latter is more like the JDK. This Java/JDK distinction is exactly right. This is how I view the relationship between Erlang and OTP. And this is why I think we ought to stop using "OTP" altogether. When people talk about Java, they use "Java" even though it includes a monstrous amount of core code that can technically be separated. It's just "Java". Now, I'm on record using Java as a model of simplicity vis-a-vis Erlang. Great. I didn't see that one coming :/ From davidnwelton@REDACTED Thu Feb 13 18:07:48 2014 From: davidnwelton@REDACTED (David Welton) Date: Thu, 13 Feb 2014 18:07:48 +0100 Subject: [erlang-questions] epgsql coordination? In-Reply-To: <52FCF18C.30504@gmail.com> References: <52FCF18C.30504@gmail.com> Message-ID: The output I'm getting, after having run test_schema.sql is: pgsql_tests: all_test_ (connect_test(pgsql))...*failed* in function pgsql_tests:connect_only/2 (test/pgsql_tests.erl, line 711) **error:{badmatch,{error,invalid_password}} pgsql_tests: all_test_ (connect_to_db_test(pgsql))...*failed* in function pgsql_tests:connect_only/2 (test/pgsql_tests.erl, line 711) **error:{badmatch,{error,invalid_password}} pgsql_tests: all_test_ (connect_as_test(pgsql))...*failed* in function pgsql_tests:connect_only/2 (test/pgsql_tests.erl, line 711) **error:{badmatch,{error,invalid_password}} pgsql_tests: all_test_ (connect_with_ssl_test(pgsql))...*skipped* undefined *unexpected termination of test process* ::{ssl_negotiation_failed,ssl_not_started} ======================================================= Failed: 3. Skipped: 0. Passed: 4. One or more tests were cancelled. =ERROR REPORT==== 13-Feb-2014::18:07:13 === ** Generic server <0.57.0> terminating ** Last message in was {connect,"localhost","epgsql_test",[], [{port,5432}, {database,"epgsql_test_db1"}, {ssl,true}]} ** When Server state == {state,undefined,undefined,<<>>,undefined,undefined, {[],[]}, undefined,[],[],[],[],[],[],undefined, undefined} ** Reason for termination == ** {ssl_negotiation_failed,ssl_not_started} On Thu, Feb 13, 2014 at 5:23 PM, Anton Lebedevich wrote: > On 02/13/2014 07:51 PM, David Welton wrote: >>> Does it make sense to have it shown as a fork? I would suggest pushing a new repo there instead of forking from davidw :) >> >> I'm not sure how to accomplish that, and to be honest, it is a fork of >> my repository which I had forked from mabrek's. It'd be cleaner to >> post his as where it was forked from. >> >> I think the first order of business is to see if I can get the tests >> he had in there working 100%. With tests, it gets easier to move >> forward without too many worries... > > Timeout tests are broken in my fork (mabrek/epgsql) because I haven't > implemented timeout support yet. Client side timeouts turned out to be > quite complicated in asynchronous model. Maybe we need to steal ideas > from semiocast/pgsql and use server-side timeouts? > > These tests pass in original (wg/epgsql) but timeout support is not > complete there too (there are situations when connection could stuck > after timeout). > > Regards, > Anton Lebedevich. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From mononcqc@REDACTED Thu Feb 13 18:08:57 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 13 Feb 2014 12:08:57 -0500 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> Message-ID: <20140213170857.GK62889@ferdair.local> I have a hard time seeing how the next steps go. 0. Convince Ericsson 1. Rewrite libraries like OTP_Mibs to no longer bear the acronym OTP, and do so in a backwards compatible manner over 2 releases 2. Rewrite language docs to omit mentioning OTP, use a replacement term 3. Rewrite language tutorials online to omit mentioning OTP similarly 4. Make sure new books, tutorials, blog posts, etc. do not refer to OTP 5. Add in pointers somewhere easy to find that explain why stuff was OTP before and even had entire sections of books devoted to it but now we no longer mention the name 6. Live with the legacy of roughly 15 years of open source 'OTP' and 'Erlang/OTP' mentions and how it doesn't make sense anymore even though nothing changed in practice. 7. Ask manning to re-print Erlang and OTP in action as 'Erlang and its SDK go for a Picnic' 8. Have people ask why it's compared to a SDK when there's a lot fewer features than traditional SDKs, and point them to this thread. 9. Discuss renaming the Erlang SDK to something else for better marketing purposes since the adoption of Erlang didn't change and was possibly hurt during the confusion. I don't know. Sometimes you gotta live with your legacy. Regards, Fred. On 02/13, Garrett Smith wrote: > On Thu, Feb 13, 2014 at 8:59 AM, Vlad Dumitrescu wrote: > > On Thu, Feb 13, 2014 at 3:46 PM, Anthony Ramine wrote: > >> Java without OOP is a different language. > >> Erlang without OTP is still Erlang. > > > > IMHO the only difference is that OTP is implemented as a library and > > doesn't have dedicated language syntax. I make difference between OTP > > as design/system building guidelines and its implementation. The > > former is more like OOP for Java. The latter is more like the JDK. > > This Java/JDK distinction is exactly right. This is how I view the > relationship between Erlang and OTP. > > And this is why I think we ought to stop using "OTP" altogether. When > people talk about Java, they use "Java" even though it includes a > monstrous amount of core code that can technically be separated. It's > just "Java". > > Now, I'm on record using Java as a model of simplicity vis-a-vis > Erlang. Great. I didn't see that one coming :/ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From g@REDACTED Thu Feb 13 18:14:08 2014 From: g@REDACTED (Garrett Smith) Date: Thu, 13 Feb 2014 11:14:08 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <52FCF2BA.1020104@ninenines.eu> References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <28AAEE0D-905F-4681-B388-7C883CCBA7D3@gmail.com> <52FCF2BA.1020104@ninenines.eu> Message-ID: On Thu, Feb 13, 2014 at 10:28 AM, Lo?c Hoguin wrote: > On 02/13/2014 05:20 PM, kraythe . wrote: >> >> Naming matters and it is also pretty easy to fix. > > > Naming matters, yes. > > It being easy to fix, hell no. You're not even talking to the right people > about it here. You'd need to convince Ericsson, and by that I don't mean the > OTP team, but their bosses' bosses (and perhaps a few levels more) that > changing the name of that small project they run (small compared to > everything they do, of course) would be good for *them*. Dear Ericsson, Please change the name of "OTP Team" to "Erlang Team". Business cards, naturally, should be reprinted. Best regards, your humble troll, Garrett From n.oxyde@REDACTED Thu Feb 13 18:15:52 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 13 Feb 2014 18:15:52 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <21AD9393-44EF-4C42-A39D-B242D93ECEBE@gmail.com> Message-ID: <18266C01-84D2-46A6-85A2-F545B042CFDC@gmail.com> Replied online. -- Anthony Ramine Le 13 f?vr. 2014 ? 17:54, Garrett Smith a ?crit : > On Thu, Feb 13, 2014 at 4:42 AM, Anthony Ramine wrote: >> >> Le 13 f?vr. 2014 ? 10:51, Garrett Smith a ?crit : >> >>> Sigh. This *is* confusing. It just is. >>> >>> Lo?c you *cannot* use Erlang without OTP. The VM starts a system, >>> which consists of applications, which are supervisory trees of >>> gen_servers. >>> >>> Supervisors are gen_servers btw. >>> >>> If you think OTP is optional, look at the first two lines of kernel.erl: >>> >>> -module(kernel). >>> -behaviour(supervisor). >>> >>> Historically, OTP libraries came after Erlang the language, of course, >>> but this so called OTP "framework" is now endemic to Erlang. >> >> You just proved it's difficult to use Erlang without the stdlib. Erlang is still not OTP. > > I didn't say that Erlang is OTP. My point is that treating "OTP" as > something you learn outside of "Erlang" is not helpful. > >> In fact, the kernel module isn't even a preloaded module, this means it is not a necessary thing to use Erlang. You could have your own Erlang/E2 if you wanted. > > I'm not talking about esoteric details of how Erlang is bootstrapped. > I'm not talking about what you *can* do with the libraries and > tooling. I'm not talking about the language grammar, parsers, tool > chain, etc. > > I'm talking about what nearly 100% of all humans use when the use > Erlang, which is a facility for starting a system of OTP applications. > *Practically speaking* OTP is *endemic*. > > And my point is that the OTP distinction is confusing and non-helpful, > especially to learners. That you're resorting to technically pedantic > points here I think reinforces what I'm saying. Indeed that was pedantic. What isn?t is that Erlang is a language and OTP is a set of tools. That was the point, they are separate things. Just like studying Java doesn?t mean you will study the JDK. I can?t count the number of beginners? questions I replied to on the IRC channel that were related to Erlang *only* and where OTP knowledge would not have helped at all. >>> What sucks IMO is that OTP is treated as "advanced" by the community >>> and by book authors. I understand the history of this, but there's a >>> cost: programmers delay learning core Erlang principles of >>> *applications* -- i.e. supervisor trees -- because it's not taught up. >>> It's also incredibly complicated, if you don't use e2. >>> >>> The irony is that *advanced* Erlang programmers can get away >>> programming outside the OTP guard rails. Beginners should not even >>> consider doing this until they understand why OTP works and why they >>> should deviate. >>> >>> e2 helps, a lot. >> >> OTP is a set of building blocks for concurrent and distributed systems. >> >> Concurrency and distribution are advanced topics. > > OTP doesn't help with concurrency and distribution. It's there to > organize system start up and process life cycle. It's analogous to > init and monitoring schemes in operating systems (e.g. systemd, runit, > etc.) > > If you don't care about how your code is started and managed while > it's running, you might not about "OTP" -- or you might be a guru rock > star. In either case, you're not typical. It helps with startup, and concurrency, and distribution, cf. all the OTP generic behaviours. Talking about init systems, an OS kernel without a systemd-like is not very useful, we still don?t conflate the two. >> Thus OTP is an advanced topic. >> >>> The whole point of e2 is to simplify the correct use of OTP -- letting >>> programmers *start* with applications, supervisors and gen_servers (in >>> e2 they're called services and tasks -- simple huh). I know it's >>> controversial, but it's controversial to those who have been teaching >>> Erlang while this stuff was being baked. I don't run into new learners >>> who object to starting with OTP using e2 (though maybe they're just >>> being polite -- if you're out there and had problems learning with e2, >>> please drop me a line, or yell at me here). >> >> e2 is a leaky abstraction which you need to deviate from when you need more complex stuff; let's not add an infinity of layers on top of OTP. > > All abstractions leak. And even with that, e2 actually is pretty tight. > > The *only* time I don't use e2 is when I don't want to introduce it as > a library dependency (e.g. within another small library like a > database driver, etc) > > Have you used e2? Did you run into a specific case that e2_process or > e2_task didn't accommodate? > > And *one thin layer* layer on top of on an interface that is begging > to be simplified is certainly not an infinity. No, I didn?t use e2 because I don?t think the OTP behaviours are an interface that is begging to be simplified. >>> I agree wholeheartedly with Pieter. It's just Erlang. Keeping the term >>> OTP is a historic vestige. We're used to it, but it's a dead weight >>> that adds only confusion. >> >> Erlang itself is dead weight to most in the industry, does that mean we should forgo Erlang altogether? >> >>> The Ruby / Rails comparison is not accurate. It's more like Rails 1.0 >>> / Rails 2.0. >> >> I have no idea how you would find this accurate. >> >>> Sadly though, I just don't see "OTP" going away because there's a >>> trickle of noise from this list :| >> >> How do you know there isn't a silent majority who just doesn't care or wouldn't like the OTP team to spend time trying to rewrite history? That sounds quite a dismissal of the opposing opinion in this debate. In fact, I have to admit I wouldn't have replied if not for that sentence. > > I haven't seen a call for rewriting history. > > The call is to stop using "OTP" as a meaningful term in the context of > Erlang. You and Lo?c have accurately pointed out that it's *possible* > to separate a couple layers within Erlang that coincide with this > Erlang/OTP division. But it's not *practical* and the practice of > treating OTP compliance as something-to-learn-later is bad for Erlang, > IMO. > > I'd like to see an effort to simplify the code and process needed to > write OTP compliant code. e2 is I think a reasonable first attempt at > that. I would offer it as input to the process. Any renaming creates a disconnection with the previous literature. And I still don?t think OTP is a mess, the only thing missing to me is a way to continue work immediately after init (or from init with some kind of init_ack function to reply to the initial caller) without sending a message to itself. >>> I make videos to cope. >> >> I give value to historic facts and terminology to cope. > > But as long as you cope. It's the most important thing. > > Garrett From g@REDACTED Thu Feb 13 18:18:35 2014 From: g@REDACTED (Garrett Smith) Date: Thu, 13 Feb 2014 11:18:35 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <20140213170857.GK62889@ferdair.local> References: <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> Message-ID: On Thu, Feb 13, 2014 at 11:08 AM, Fred Hebert wrote: > I have a hard time seeing how the next steps go. > > 0. Convince Ericsson > 1. Rewrite libraries like OTP_Mibs to no longer bear the acronym OTP, > and do so in a backwards compatible manner over 2 releases > 2. Rewrite language docs to omit mentioning OTP, use a replacement term > 3. Rewrite language tutorials online to omit mentioning OTP similarly > 4. Make sure new books, tutorials, blog posts, etc. do not refer to OTP > 5. Add in pointers somewhere easy to find that explain why stuff was OTP > before and even had entire sections of books devoted to it but now we > no longer mention the name > 6. Live with the legacy of roughly 15 years of open source 'OTP' and > 'Erlang/OTP' mentions and how it doesn't make sense anymore even > though nothing changed in practice. > 7. Ask manning to re-print Erlang and OTP in action as 'Erlang and its > SDK go for a Picnic' > 8. Have people ask why it's compared to a SDK when there's a lot fewer > features than traditional SDKs, and point them to this thread. > 9. Discuss renaming the Erlang SDK to something else for better > marketing purposes since the adoption of Erlang didn't change and was > possibly hurt during the confusion. > > I don't know. Sometimes you gotta live with your legacy. *nods* - OTP isn't going anywhere. But I'd like to see more programmers write correct/OTP compliant code. I don't see that happening unless the interfaces to these core behaviors are simplified and we can start to introduce these very important (essential) concepts earlier in the learning process, and with less head explosions. Garrett From andreas@REDACTED Thu Feb 13 18:23:53 2014 From: andreas@REDACTED (Andreas Schumacher) Date: Thu, 13 Feb 2014 18:23:53 +0100 Subject: [erlang-questions] FW: Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <52FCC466.9060206@erlang.org> References: <52F4C173.8050408@erlang.org> <1391790979.26271.YahooMailNeo@web140106.mail.bf1.yahoo.com> <49EC93AB-69A4-49AB-A2C0-4DA9F418E3F6@gmail.com> <58912684E2630B45963406CF7D8C52581C3473C6@ESESSMB103.ericsson.se> <52FB2C0E.90008@erlang.org> <58912684E2630B45963406CF7D8C52581C348431@ESESSMB103.ericsson.se> <52FCC466.9060206@erlang.org> Message-ID: <52FCFFA9.7020109@erlang.org> Correction: I meant to write "Re: otp_version: In addition to erlang:system_info(otp_version) [where otp_version will replace otp_correction_package], a corresponding flag "otp_version" - similar to [emulator] "version" - is going to be added to the erl command [...]" Nevertheless, due to Vlad's and Dave Cottlehuber's request to be able to extract the complete OTP version externally, i.e. without starting erlang, we are still discussing other alternatives. Andreas On 02/13/2014 02:11 PM, Andreas Schumacher wrote: > Re: otp_version: In addition to > erlang:system_info(otp_correction_package), a corresponding flag > "otp_version" - similar to [emulator] "version" - is going to be added > to the erl command, in order to allow the extraction of the complete > version number from command line tools. Other additions to extract the > Erlang/OTP version have not been planned. > > Re: 17.0.0 =?= 17.0: Yes, they are the same. We could have used the > extra ".0", but we chose not to. > > Andreas > > ---------- > Andreas Schumacher, Erlang/OTP, Ericsson AB > >> >> -----Original Message----- >> From: Vlad Dumitrescu [mailto:vladdu55@REDACTED] >> Sent: den 13 februari 2014 10:35 >> To: Andreas Schumacher >> Cc: Anthony Ramine; erlang-questions; Rickard Green >> Subject: Re: [erlang-questions] Version numbering scheme change and >> the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. >> >> Hi! >> >> A couple of more questions about versins: >> >> - how can we find the otp_version without starting erlang? >> otp_release is in the start scripts, but I can't find anywhere >> "17.0-rc1"... >> - is 17.0.0 the same as 17.0? Is it a problem to use the extra ".0"? >> >> regards, >> Vlad >> >> >> On Wed, Feb 12, 2014 at 9:08 AM, Andreas Schumacher >> wrote: >>> From the versioning clarification mail that I sent on behalf of the >>> OTP team to the list on February 7: >>> >>> >>> "The new version scheme is *not* semantic versioning; although, it has >>> been inspired by it. We do not want to use semantic versioning (as >>> defined by >>> http://semver.org/) out of the box since it does not fit our needs." >>> >>> Andreas Schumacher >>> Erlang/OTP, Ericsson AB >>> >>>> -----Original Message----- >>>> From: erlang-questions-bounces@REDACTED >>>> [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Anthony >>>> Ramine >>>> Sent: den 12 februari 2014 02:48 >>>> To: Rickard Green >>>> Cc: erlang-questions@REDACTED >>>> Subject: Re: [erlang-questions] Version numbering scheme change and >>>> the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. >>>> >>>> So OTP won't follow semantic versioning, right? >>>> >>>> Just seeking confirmation about semver. >>>> >>>> Regards, >>>> >>>> -- >>>> Anthony Ramine >>>> >>>> Le 12 f?vr. 2014 ? 00:43, Rickard Green a ?crit : >>>> >>>>> As of OTP 17 we drop this patch level number sequence and start >>>>> using one set of patch level numbers per release. The patch level is >>>>> not expressed as an integer as it used to be, but instead as a >>>>> version number ..[. ...], for example, 17.0.1. This way >>>>> the patch level gives you a bit more information. You can for >>>>> example see directly which OTP release it applies to. This patch >>>>> level version number also replace the - tar-ball naming scheme. >>>> _______________________________________________ >>>> 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 mabrek@REDACTED Thu Feb 13 18:25:55 2014 From: mabrek@REDACTED (Anton Lebedevich) Date: Thu, 13 Feb 2014 21:25:55 +0400 Subject: [erlang-questions] epgsql coordination? In-Reply-To: References: <52FCF18C.30504@gmail.com> Message-ID: <52FD0023.1030406@gmail.com> Did you add lines mentioned in the beginning of test_schema.sql to pg_hba.conf ? You'll need to set up ssl authentification for you server using crt and keys from test_data/. On 02/13/2014 09:07 PM, David Welton wrote: > The output I'm getting, after having run test_schema.sql is: > > pgsql_tests: all_test_ (connect_test(pgsql))...*failed* > in function pgsql_tests:connect_only/2 (test/pgsql_tests.erl, line 711) > **error:{badmatch,{error,invalid_password}} > > > pgsql_tests: all_test_ (connect_to_db_test(pgsql))...*failed* > in function pgsql_tests:connect_only/2 (test/pgsql_tests.erl, line 711) > **error:{badmatch,{error,invalid_password}} > > > pgsql_tests: all_test_ (connect_as_test(pgsql))...*failed* > in function pgsql_tests:connect_only/2 (test/pgsql_tests.erl, line 711) > **error:{badmatch,{error,invalid_password}} > > > pgsql_tests: all_test_ (connect_with_ssl_test(pgsql))...*skipped* > undefined > *unexpected termination of test process* > ::{ssl_negotiation_failed,ssl_not_started} > > ======================================================= > Failed: 3. Skipped: 0. Passed: 4. > One or more tests were cancelled. > > =ERROR REPORT==== 13-Feb-2014::18:07:13 === > ** Generic server <0.57.0> terminating > ** Last message in was {connect,"localhost","epgsql_test",[], > [{port,5432}, > {database,"epgsql_test_db1"}, > {ssl,true}]} > ** When Server state == {state,undefined,undefined,<<>>,undefined,undefined, > {[],[]}, > undefined,[],[],[],[],[],[],undefined, > undefined} > ** Reason for termination == > ** {ssl_negotiation_failed,ssl_not_started} > > On Thu, Feb 13, 2014 at 5:23 PM, Anton Lebedevich wrote: >> On 02/13/2014 07:51 PM, David Welton wrote: >>>> Does it make sense to have it shown as a fork? I would suggest pushing a new repo there instead of forking from davidw :) >>> >>> I'm not sure how to accomplish that, and to be honest, it is a fork of >>> my repository which I had forked from mabrek's. It'd be cleaner to >>> post his as where it was forked from. >>> >>> I think the first order of business is to see if I can get the tests >>> he had in there working 100%. With tests, it gets easier to move >>> forward without too many worries... >> >> Timeout tests are broken in my fork (mabrek/epgsql) because I haven't >> implemented timeout support yet. Client side timeouts turned out to be >> quite complicated in asynchronous model. Maybe we need to steal ideas >> from semiocast/pgsql and use server-side timeouts? >> >> These tests pass in original (wg/epgsql) but timeout support is not >> complete there too (there are situations when connection could stuck >> after timeout). >> >> Regards, >> Anton Lebedevich. >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > From kraythe@REDACTED Thu Feb 13 18:29:34 2014 From: kraythe@REDACTED (kraythe .) Date: Thu, 13 Feb 2014 11:29:34 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <20140213170857.GK62889@ferdair.local> References: <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> Message-ID: I Guess my answers would be: 0) If there is a business case, you can convince them. Low adoption hurts their maintainability and staffing much more than it does for the startup or small company. They are a business, not a bunch of unreasonable oafs. 1) Why rewrite the libs if you use the same initials. I wouldn't worry about that. The programming world is replete with examples of such things. 2) and updating the docs will take ... 10 man hours? Do we not have search and replace capable tools? 3) Same answer as 2. 4) Dont need to "make sure" of anything. If the books want to be accurate they will use the new name, if not "shrug" thats their problem. Trust me someone on amazon will post "Its not called Open Telecom Platform since 2014, it stands for "Open Technology Platform". There are enough pedantic, basement living, people on the internet that will annoy authors into submission. 5) Small matter of documentation. "It used to be called X but was renamed to Y in 2014" 6) History is history. Those investigating the language will get it. It startedo ut being a telecoms thing and migrated to a general language. No problem. Live web sites can easily add in blurbs. Old articles will be out of date but not from the time frame of when they were written. No big deal. The sky isnt actually falling. 7) Obviously this one is just frothing. The man could update the next version of his book with more information, cool tricks, whatever and sell it as a second edition. 8) What "traditional SDK" are you referring to? The LISP standard lib? ;-) Java? C? Ruby? Haskell? Which one is the "normal" one? Normal is defined in the context of the language, not in the context of another language? In fact the vast majority of SDKs for java are third party to the JDK itself anyway. 9) Trying to crystal ball the future will only give you a headache. The key is to move from where yo are to a point where progress has been made and recursively loop on that algorithm, not be paralyzed by "what if .... ?" You may have been doing Erlang for ages and feel quite the man but the question really boils down to "what would you like for the future of Erlang to be?" If the answer to that in your mind is "A niche language that I can call myself a guru at and everyone looks at me quizzically and puts up with my eccentricity or dare say arrogance." then the current name and trend is fine. If the answer is, "A powerful general purpose programming language for developing applications using functional paradigms and widely accepted as being the solution to the next generation of software problems." Then marketing is important. I have told you my "green" impressions of OTP and you can dismiss them if it make you more comfortable but it wont change the fact that others will have those feelings and many will not get on the list and go further. They will simply move to Ruby, Scala, Node.js, Clojure, or something else. If our attitude is "I didn't want you in the community anyway!" then Erlang will be the next Smalltalk or Lisp. Of academic and little more than that in significance. *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* *Author of: Hardcore Java (2003) and Maintainable Java (2012)* *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 * On Thu, Feb 13, 2014 at 11:08 AM, Fred Hebert wrote: > I have a hard time seeing how the next steps go. > > 0. Convince Ericsson > 1. Rewrite libraries like OTP_Mibs to no longer bear the acronym OTP, > and do so in a backwards compatible manner over 2 releases > 2. Rewrite language docs to omit mentioning OTP, use a replacement term > 3. Rewrite language tutorials online to omit mentioning OTP similarly > 4. Make sure new books, tutorials, blog posts, etc. do not refer to OTP > 5. Add in pointers somewhere easy to find that explain why stuff was OTP > before and even had entire sections of books devoted to it but now we > no longer mention the name > 6. Live with the legacy of roughly 15 years of open source 'OTP' and > 'Erlang/OTP' mentions and how it doesn't make sense anymore even > though nothing changed in practice. > 7. Ask manning to re-print Erlang and OTP in action as 'Erlang and its > SDK go for a Picnic' > 8. Have people ask why it's compared to a SDK when there's a lot fewer > features than traditional SDKs, and point them to this thread. > 9. Discuss renaming the Erlang SDK to something else for better > marketing purposes since the adoption of Erlang didn't change and was > possibly hurt during the confusion. > > I don't know. Sometimes you gotta live with your legacy. > > Regards, > Fred. > > On 02/13, Garrett Smith wrote: > > On Thu, Feb 13, 2014 at 8:59 AM, Vlad Dumitrescu > wrote: > > > On Thu, Feb 13, 2014 at 3:46 PM, Anthony Ramine > wrote: > > >> Java without OOP is a different language. > > >> Erlang without OTP is still Erlang. > > > > > > IMHO the only difference is that OTP is implemented as a library and > > > doesn't have dedicated language syntax. I make difference between OTP > > > as design/system building guidelines and its implementation. The > > > former is more like OOP for Java. The latter is more like the JDK. > > > > This Java/JDK distinction is exactly right. This is how I view the > > relationship between Erlang and OTP. > > > > And this is why I think we ought to stop using "OTP" altogether. When > > people talk about Java, they use "Java" even though it includes a > > monstrous amount of core code that can technically be separated. It's > > just "Java". > > > > Now, I'm on record using Java as a model of simplicity vis-a-vis > > Erlang. Great. I didn't see that one coming :/ > > _______________________________________________ > > 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 Thu Feb 13 18:33:21 2014 From: g@REDACTED (Garrett Smith) Date: Thu, 13 Feb 2014 11:33:21 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <18266C01-84D2-46A6-85A2-F545B042CFDC@gmail.com> References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <21AD9393-44EF-4C42-A39D-B242D93ECEBE@gmail.com> <18266C01-84D2-46A6-85A2-F545B042CFDC@gmail.com> Message-ID: On Thu, Feb 13, 2014 at 11:15 AM, Anthony Ramine wrote: > Replied online. > > -- > Anthony Ramine > > Le 13 f?vr. 2014 ? 17:54, Garrett Smith a ?crit : > >> And my point is that the OTP distinction is confusing and non-helpful, >> especially to learners. That you're resorting to technically pedantic >> points here I think reinforces what I'm saying. > > Indeed that was pedantic. What isn't is that Erlang is a language and OTP is a set of tools. That was the point, they are separate things. Just like studying Java doesn't mean you will study the JDK. > > I can't count the number of beginners' questions I replied to on the IRC channel that were related to Erlang *only* and where OTP knowledge would not have helped at all. I'm happy to wind this thread down, but I have the slighted irritation that I haven't made myself clear. Yes, the OTP behaviors and the scheme for wiring code into init and process life cycle management are indeed separate from the language. In fact, *all* of the core applications and modules can be separated. And people on IRC can ask questions that don't touch on lots of things. What I'm talking about is how we communicate and present Erlang -- the name, the brand, the core concepts. Modules like inets, gen_tcp, proplists -- this list is very, very long -- are things you can do without depending on your application. Modules like gen_server and supervisor are things that you cannot, or at least should not, do without. If you don't use them, it's a bad idea, unless you're a guru rock star. I don't think this is general knowledge -- many Erlang programmers think of these essential OTP modules as optional, advanced things you can tack on later once you have graduated to that level. This is plain wrong, in *practice*, for people who want to write fault tolerant Erlang programs. So that's my beef. Now that I've said this like ten times in this thread, I'll let it be. From essen@REDACTED Thu Feb 13 18:40:17 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 13 Feb 2014 18:40:17 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> Message-ID: <52FD0381.9090105@ninenines.eu> On 02/13/2014 06:29 PM, kraythe . wrote: > someone on amazon will post "Its not called Open Telecom Platform since > 2014, it stands for "Open Technology Platform". I hope you don't seriously believe "Open Technology Platform" is any better. Instead of a few people mistakenly thinking OTP is a Telecom thing, you'll end up with everyone not understanding what the f OTP is. It's easy to tie what Telecoms do to what general IT does, it's all essentially the same thing, except it actually needs to work in Telecoms. But technology? That could mean anything from the wheel to creating life from scratch in a lab to intergallactic space travel. -- Lo?c Hoguin http://ninenines.eu From g@REDACTED Thu Feb 13 18:47:47 2014 From: g@REDACTED (Garrett Smith) Date: Thu, 13 Feb 2014 11:47:47 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> Message-ID: On Thu, Feb 13, 2014 at 11:29 AM, kraythe . wrote: > > I have told you my "green" impressions of OTP and you can dismiss them if it > make you more comfortable but it wont change the fact that others will have > those feelings and many will not get on the list and go further. They will > simply move to Ruby, Scala, Node.js, Clojure, or something else. If our > attitude is "I didn't want you in the community anyway!" then Erlang will be > the next Smalltalk or Lisp. Of academic and little more than that in > significance. Robert, you're completely on point here and there are many in the Erlang community who are in sync with you. I will say that, in defense of our more stodgy brethren [1], the sort of push you're seeing here has, I believe, contributed significantly to the quality of Erlang. You have to jump over some *very high* barriers to get things moved in this ecosystem. The upside is that the community doesn't spend a lot of cycles solving problems that aren't glaringly obvious. This "OTP" topic isn't a glaringly obvious problem to many people. The complexity of the gen_server and supervisor interfaces -- not glaringly obvious, apparently. Line numbers missing from stack traces, glaring. No maps, glaring. And look how long those took to land. But as a result, Erlang doesn't face the problems of feature bloat (I think of Ruby) and ongoing migration issues (I think of Python) that other languages face. I for one would gladly take the problems we're discussing here, which I think are relatively small, as a price for this much more useful conservative mindset that has produced today's Erlang. Eh, just my point of view. Garrett [1] Old guard, don't fret -- you're cool. Hard core old school cool. From kraythe@REDACTED Thu Feb 13 18:48:17 2014 From: kraythe@REDACTED (kraythe .) Date: Thu, 13 Feb 2014 11:48:17 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <52FD0381.9090105@ninenines.eu> References: <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> <52FD0381.9090105@ninenines.eu> Message-ID: So it seems the general sort of feeling is: "We don't really care about adoption or how things are presented to the development community as well. We call it Open Telecom Platform and if that means you can't sell a project to management in Erlang then we don't care. Adoption is not a priority of this community or Ericson in specific and thats that." Sort of makes me wonder what I am doing here and what I have spent the last 2 weeks of my free time doing. I could write my project in Lisp an achieve the same result and I already know Lisp fairly well. Honestly this whole thread is making me think back to the first thread I posted in this community and making me wonder if it would not be better to go down the road of Scala instead. Even though that community is not what Id call friendly, I can staff a Scala project with talented Java / Ruby / Node.js / Clojure people. With the general sense in the Erlang community I could hardly blame the developer that said "I'm not interested in your project because Erlang is useless to my resume." Hmm definitely food for thought. *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* *Author of: Hardcore Java (2003) and Maintainable Java (2012)* *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 * On Thu, Feb 13, 2014 at 11:40 AM, Lo?c Hoguin wrote: > On 02/13/2014 06:29 PM, kraythe . wrote: > >> someone on amazon will post "Its not called Open Telecom Platform since >> 2014, it stands for "Open Technology Platform". >> > > I hope you don't seriously believe "Open Technology Platform" is any > better. > > Instead of a few people mistakenly thinking OTP is a Telecom thing, you'll > end up with everyone not understanding what the f OTP is. > > It's easy to tie what Telecoms do to what general IT does, it's all > essentially the same thing, except it actually needs to work in Telecoms. > But technology? That could mean anything from the wheel to creating life > from scratch in a lab to intergallactic space travel. > > > -- > Lo?c Hoguin > http://ninenines.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Thu Feb 13 19:00:06 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Thu, 13 Feb 2014 18:00:06 +0000 Subject: [erlang-questions] release upgrades and code loading Message-ID: <52FD0826.2080305@llaisdy.com> Dear All I am just getting started with live release upgrades, using relx and following this tutorial: http://blog.troutwine.us/2013/09/13/trivial_otp_releases.html Everything seems to work as advertised, except sometimes I need to explicitly load the code into the running vm (i.e., using code_load_file/1) for the new stuff to take effect. The function release_handler:which_releases/0 reports the new release as active and permanent, but I can see from behaviour that old versions of certain modules are still running and handling data. I can't be much more specific I'm afraid. One example: one application uses cowboy. If a release upgrade changes a cowboy resource module, the new release version might still be running the old version of that module until I load_file and purge. Why might this be happening? Am I missing something in the packaging and upgrade process? Is there a better way I can write my modules? If the information above is too vague, what should I look out for next time this happens? With thanks and best wishes Ivan -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From mononcqc@REDACTED Thu Feb 13 19:05:20 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 13 Feb 2014 13:05:20 -0500 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> Message-ID: <20140213180519.GL62889@ferdair.local> Answers inline. On 02/13, kraythe . wrote: > I Guess my answers would be: > 0) If there is a business case, you can convince them. Low adoption hurts > their maintainability and staffing much more than it does for the startup > or small company. They are a business, not a bunch of unreasonable oafs. That may be doable. I'm not saying the opposite. > 1) Why rewrite the libs if you use the same initials. I wouldn't worry > about that. The programming world is replete with examples of such things. If we can use the same initials, then that's gained and removes a bunch of issues. > 2) and updating the docs will take ... 10 man hours? Do we not have search > and replace capable tools? > 3) Same answer as 2. Yes, but we do not have administration rights to mirrors, say http://erldocs.com/ and translations that can be hosted by the community. The work done with the OTP documentation goes further than the OTP team itself. > 4) Dont need to "make sure" of anything. If the books want to be accurate > they will use the new name, if not "shrug" thats their problem. Trust me > someone on amazon will post "Its not called Open Telecom Platform since > 2014, it stands for "Open Technology Platform". There are enough pedantic, > basement living, people on the internet that will annoy authors into > submission. That doesn't sound like a pleasant experience for everyone. Again, it's not an insurmountable challenge. It's just one more challenge. > 5) Small matter of documentation. "It used to be called X but was renamed > to Y in 2014" Documentation lives on way longer than expected. People still read and order reprints of the Erlang book published in 1994 (and 1996 for the second edition), some of which are translations. Many older versions of books are what is in libraries and whatnot, since Joe's first version in early 2000s. For people using these versions, you end up with inaccurate terminology regarding half the name of the language. It's a matter of documentation, but it's a matter of trying to do it right to reduce the amount of confusion. If people look for "Open Telecom Platform Erlang" it would be sweet to get the new documentation and content. Maybe it's easy, but it's still part of a roadmap. Alternatively, would 'Open Telecom Platform, a framework that is not just about telecoms' going to be more cumbersome in documentation? > 6) History is history. Those investigating the language will get it. It > startedo ut being a telecoms thing and migrated to a general language. No > problem. Live web sites can easily add in blurbs. Old articles will be out > of date but not from the time frame of when they were written. No big deal. > The sky isnt actually falling. I could see that being made as a decision, yes. > 7) Obviously this one is just frothing. The man could update the next > version of his book with more information, cool tricks, whatever and sell > it as a second edition. Yes. I like to insert a bit of non-serious content here and there. > 8) What "traditional SDK" are you referring to? The LISP standard lib? ;-) > Java? C? Ruby? Haskell? Which one is the "normal" one? Normal is defined in > the context of the language, not in the context of another language? In > fact the vast majority of SDKs for java are third party to the JDK itself > anyway. I went from this thread's usage of SDK as a similar point to OTP. Erlang/SDK if you will. If you want to keep it as Erlang/OTP, that can work, but needs to be significantly better than what it is right now to have an actually measurable impact. Otherwise, we're throwing stuff at the wall to see what sticks, with no proof that it actually helped anything. > 9) Trying to crystal ball the future will only give you a headache. The key > is to move from where yo are to a point where progress has been made and > recursively loop on that algorithm, not be paralyzed by "what if .... ?" > Non-serious content here also. Not to be taken seriously, but I wouldn't be surprised if it were to happen. > You may have been doing Erlang for ages and feel quite the man but the > question really boils down to "what would you like for the future of Erlang > to be?" If the answer to that in your mind is "A niche language that I can > call myself a guru at and everyone looks at me quizzically and puts up with > my eccentricity or dare say arrogance." then the current name and trend is > fine. If the answer is, "A powerful general purpose programming language > for developing applications using functional paradigms and widely accepted > as being the solution to the next generation of software problems." Then > marketing is important. Oh I love that one. I want Erlang to be adopted so much I wrote an entire book about it and put it online for free, without advertisement. This has taken over 3 years of my spare time, because I wanted Erlang to be more accessible. I invite you to visit it at http://learnyousomeerlang.com, and maybe buy an ebook or print copy if you feel like it would be nicer to read that way. If you prefer a free electronic copies, there are scripts on github to convert it to the kindle format, and a wget line in the FAQ to download a local copy. I also kept writing multiple blog posts at http://ferd.ca that guide and show more tutorials about Erlang, use cases, and tries to sell it as a language as a whole. The reason I'm answering to your suggestion negatively isn't that I don't want Erlang to succeed, it's that I do not believe that changing the meaning of 'OTP' from 'Open Telecom Platform' to 'Open Technology Platform' will have a noticeable impact. Some people do ask the question 'but I don't want to do telecoms', but in my experience, people's issues are the following, to a much higher degree: - The syntax is unfamiliar (or ugly) - It's difficult to work with single assignment, recursion, immutable algorithms (most of your algorithm books that rely on arrays with O(1) access to work fine are no longer going to be trivial to translate! That's huge!) - The tooling (rebar, relx, etc.) isn't up to par with other languages, even if it keeps getting better. - Lack of IDEs (that was your prime concern when you joined these lists) - Fighting the idea that "it will be hard to hire Erlang developers" to make it enter and stay in the enterprise. All of those criticism, in the years I've been in the Erlang community, have come up time and time again. They've also have come up orders of magnitude more often than OTP as a name, even if it does come up from time to time. I'm sorry I came up as harsh. I do want better adoption for Erlang and took months if not years of my free time working that way. I do not think renaming OTP is worth the effort, but I'll be glad to be proven wrong through bigger adoption if someone steps up and decides to do it. Now if you please, I'll go back to spending my lunch time working on an post-scripted chapter to the LYSE site introducing maps to people. Regards, Fred. From paul.joseph.davis@REDACTED Thu Feb 13 19:08:34 2014 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Thu, 13 Feb 2014 12:08:34 -0600 Subject: [erlang-questions] release upgrades and code loading In-Reply-To: <52FD0826.2080305@llaisdy.com> References: <52FD0826.2080305@llaisdy.com> Message-ID: Have you looked at the generated relup to make sure it includes the appropriate instructions for upgrade the modules in question? On Thu, Feb 13, 2014 at 12:00 PM, Ivan Uemlianin wrote: > Dear All > > I am just getting started with live release upgrades, using relx and > following this tutorial: > > http://blog.troutwine.us/2013/09/13/trivial_otp_releases.html > > Everything seems to work as advertised, except sometimes I need to > explicitly load the code into the running vm (i.e., using code_load_file/1) > for the new stuff to take effect. The function > release_handler:which_releases/0 reports the new release as active and > permanent, but I can see from behaviour that old versions of certain modules > are still running and handling data. > > I can't be much more specific I'm afraid. One example: one application uses > cowboy. If a release upgrade changes a cowboy resource module, the new > release version might still be running the old version of that module until > I load_file and purge. > > Why might this be happening? Am I missing something in the packaging and > upgrade process? Is there a better way I can write my modules? > > If the information above is too vague, what should I look out for next time > this happens? > > With thanks and best wishes > > Ivan > > > -- > ============================================================ > Ivan A. Uemlianin PhD > Llaisdy > Speech Technology Research and Development > > ivan@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > github.com/llaisdy > www.linkedin.com/in/ivanuemlianin > > festina lente > ============================================================ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From mfidelman@REDACTED Thu Feb 13 19:12:52 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Thu, 13 Feb 2014 13:12:52 -0500 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> Message-ID: <52FD0B24.50400@meetinghouse.net> kraythe . wrote: > I have told you my "green" impressions of OTP and you can dismiss them > if it make you more comfortable but it wont change the fact that > others will have those feelings and many will not get on the list and > go further. They will simply move to Ruby, Scala, Node.js, Clojure, or > something else. If our attitude is "I didn't want you in the community > anyway!" then Erlang will be the next Smalltalk or Lisp. Of academic > and little more than that in significance. Bah, humbug. As long as there's a need for industrial strength massive concurrency, and no serious alternative, it doesn't really matter what it's called. Anybody who tries to write a massively concurrent application in Ruby, Scala, Node.js, Cojure (or Java for that matter), gets what they deserve. Just one man's opinion, of course. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From erlang@REDACTED Thu Feb 13 19:15:54 2014 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 13 Feb 2014 19:15:54 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> Message-ID: On Thu, Feb 13, 2014 at 10:51 AM, Garrett Smith wrote: > Sigh. This *is* confusing. It just is. > > Lo?c you *cannot* use Erlang without OTP. The VM starts a system, > which consists of applications, which are supervisory trees of > gen_servers. > This is wrong - you can use Erlang without OTP. OTP loads 60 odd modules, starts a code server and some other stuff and *then* executes your code. You can "easily" roll your own system that uses far fewer modules and gets you up and running, but then you don't get the shell, the code loader and a load of other goodies. Appendix 3 of the 2'nd edition of Programming Erlang tells you *exactly* how to do this. To summarise Appendix 3 - I load 3 modules in 20ms instead of the 1.1s Erlang + OTP takes (on the same machine) then you're up and running, not OTP but a with a code loader and simple I/O system. Supervisors are *easily* made with a combination of links/monitors and trapping exits. OTP was designed for teams of programmers, so that they would all write their code the same way and use common tools for code loading, error logging, supervision and so on. There is absolutely nothing stopping you from supervising and restarting programs using spawn_link and trapping exits. The relationship between Erlang and OTP is like C and unix. Unix is an OS written in C. OTP is some middleware written in Erlang. > Supervisors are gen_servers btw. > > If you think OTP is optional, look at the first two lines of kernel.erl: > > -module(kernel). > -behaviour(supervisor). > But you don't need to load kernel.erl to run erlang programs - OTP needs to load kernel.erl My stand-alone system does not need this. The only *critical* modules are error_handler.erl and lists.erl > > Historically, OTP libraries came after Erlang the language, of course, > but this so called OTP "framework" is now endemic to Erlang. > Yes - there were two other middlewares *before* OTP > > What sucks IMO is that OTP is treated as "advanced" by the community > and by book authors. I understand the history of this, but there's a > cost: programmers delay learning core Erlang principles of > *applications* -- i.e. supervisor trees -- because it's not taught up. > It's also incredibly complicated, if you don't use e2. > It's not incredibly complicated :-) Applications and supervisor trees are not core concepts of Erlang - Erlang (the language) has not a clue what an application or a supervision tree is. Applications and supervisors are core concepts of OTP not Erlang. > > The irony is that *advanced* Erlang programmers can get away > programming outside the OTP guard rails. Beginners should not even > consider doing this until they understand why OTP works and why they > should deviate. > No - beginners should start with spawn and spawn_link then learn to trap exits and then learn that they can replace a lot of simple boilerplate code with the OTP equivalents. > > e2 helps, a lot. > > The whole point of e2 is to simplify the correct use of OTP -- letting > programmers *start* with applications, supervisors and gen_servers (in > e2 they're called services and tasks -- simple huh). I know it's > controversial, but it's controversial to those who have been teaching > Erlang while this stuff was being baked. I don't run into new learners > who object to starting with OTP using e2 (though maybe they're just > being polite -- if you're out there and had problems learning with e2, > please drop me a line, or yell at me here). > Actually you could layer e2 on top of a primitive bootstrap (read my book for details). > > I agree wholeheartedly with Pieter. It's just Erlang. Keeping the term > OTP is a historic vestige. We're used to it, but it's a dead weight > that adds only confusion. > I think the problem with the name OTP is that is embedded in a load of books and documentations. Change the names and you invalidate the documentation. Change the names and you lose backwards compatibility Cheers /Joe > > The Ruby / Rails comparison is not accurate. It's more like Rails 1.0 > / Rails 2.0. > > Sadly though, I just don't see "OTP" going away because there's a > trickle of noise from this list :| > > I make videos to cope. > > On Thu, Feb 13, 2014 at 2:54 AM, Ivan Uemlianin wrote: > > On 13/02/2014 08:13, Pieter Hintjens wrote: > >> > >> ... (a) stop using OTP as a > >> confusing and needless synonym for Erlang, ... > > > > > > Is that what OTP is used as? I thought OTP was a set (or framework, or > > platform) of libraries (behaviours, supervision, etc.) that facilitate > the > > development of highly scalable and reliable applications (telecoms-grade > > scalability and reliability you might say). AFAIK it's open-source. > > > > Yes, let's rename it to something that more closely reflects what it > really > > is. How about the "Open-source Telecoms-grade reliability and > scalability > > Platform"? > > > > Ivan > > > > > > -- > > ============================================================ > > Ivan A. Uemlianin PhD > > Llaisdy > > Speech Technology Research and Development > > > > ivan@REDACTED > > www.llaisdy.com > > llaisdy.wordpress.com > > github.com/llaisdy > > www.linkedin.com/in/ivanuemlianin > > > > festina lente > > ============================================================ > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kraythe@REDACTED Thu Feb 13 19:16:33 2014 From: kraythe@REDACTED (kraythe .) Date: Thu, 13 Feb 2014 12:16:33 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <20140213180519.GL62889@ferdair.local> References: <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> <20140213180519.GL62889@ferdair.local> Message-ID: I have read portions of your book and appreciate your insight. However, I think you underestimate the task here. Convincing developers may be difficult, but if they are good devs they might come around. Convincing management with control over budget and staffing when the naming is wrong? Nearly impossible. Thats why massive advertising companies have made billions off of just naming things correctly. All of the other concerns you posted are very legit and I have had and still do have many of them myself. But those concerns are at the tech level and only of minor interest to the manager wondering why would he staff for erlang and not scala or ruby? *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* *Author of: Hardcore Java (2003) and Maintainable Java (2012)* *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 * On Thu, Feb 13, 2014 at 12:05 PM, Fred Hebert wrote: > Answers inline. > > On 02/13, kraythe . wrote: > > I Guess my answers would be: > > 0) If there is a business case, you can convince them. Low adoption hurts > > their maintainability and staffing much more than it does for the startup > > or small company. They are a business, not a bunch of unreasonable oafs. > > That may be doable. I'm not saying the opposite. > > > 1) Why rewrite the libs if you use the same initials. I wouldn't worry > > about that. The programming world is replete with examples of such > things. > > If we can use the same initials, then that's gained and removes a bunch > of issues. > > > 2) and updating the docs will take ... 10 man hours? Do we not have > search > > and replace capable tools? > > 3) Same answer as 2. > > Yes, but we do not have administration rights to mirrors, say > http://erldocs.com/ and translations that can be hosted by the > community. > > The work done with the OTP documentation goes further than the OTP team > itself. > > > 4) Dont need to "make sure" of anything. If the books want to be accurate > > they will use the new name, if not "shrug" thats their problem. Trust me > > someone on amazon will post "Its not called Open Telecom Platform since > > 2014, it stands for "Open Technology Platform". There are enough > pedantic, > > basement living, people on the internet that will annoy authors into > > submission. > > That doesn't sound like a pleasant experience for everyone. Again, it's > not an insurmountable challenge. It's just one more challenge. > > > 5) Small matter of documentation. "It used to be called X but was renamed > > to Y in 2014" > > Documentation lives on way longer than expected. People still read and > order reprints of the Erlang book published in 1994 (and 1996 for the > second edition), some of which are translations. > > Many older versions of books are what is in libraries and whatnot, since > Joe's first version in early 2000s. For people using these versions, you > end up with inaccurate terminology regarding half the name of the > language. > > It's a matter of documentation, but it's a matter of trying to do it > right to reduce the amount of confusion. If people look for "Open > Telecom Platform Erlang" it would be sweet to get the new documentation > and content. > > Maybe it's easy, but it's still part of a roadmap. > > Alternatively, would 'Open Telecom Platform, a framework that is not > just about telecoms' going to be more cumbersome in documentation? > > > 6) History is history. Those investigating the language will get it. It > > startedo ut being a telecoms thing and migrated to a general language. No > > problem. Live web sites can easily add in blurbs. Old articles will be > out > > of date but not from the time frame of when they were written. No big > deal. > > The sky isnt actually falling. > > I could see that being made as a decision, yes. > > > 7) Obviously this one is just frothing. The man could update the next > > version of his book with more information, cool tricks, whatever and sell > > it as a second edition. > > Yes. I like to insert a bit of non-serious content here and there. > > > 8) What "traditional SDK" are you referring to? The LISP standard lib? > ;-) > > Java? C? Ruby? Haskell? Which one is the "normal" one? Normal is defined > in > > the context of the language, not in the context of another language? In > > fact the vast majority of SDKs for java are third party to the JDK itself > > anyway. > > I went from this thread's usage of SDK as a similar point to OTP. > Erlang/SDK if you will. If you want to keep it as Erlang/OTP, that can > work, but needs to be significantly better than what it is right now to > have an actually measurable impact. > > Otherwise, we're throwing stuff at the wall to see what sticks, with no > proof that it actually helped anything. > > > 9) Trying to crystal ball the future will only give you a headache. The > key > > is to move from where yo are to a point where progress has been made and > > recursively loop on that algorithm, not be paralyzed by "what if .... ?" > > > > Non-serious content here also. Not to be taken seriously, but I wouldn't > be surprised if it were to happen. > > > You may have been doing Erlang for ages and feel quite the man but the > > question really boils down to "what would you like for the future of > Erlang > > to be?" If the answer to that in your mind is "A niche language that I > can > > call myself a guru at and everyone looks at me quizzically and puts up > with > > my eccentricity or dare say arrogance." then the current name and trend > is > > fine. If the answer is, "A powerful general purpose programming language > > for developing applications using functional paradigms and widely > accepted > > as being the solution to the next generation of software problems." Then > > marketing is important. > > Oh I love that one. I want Erlang to be adopted so much I wrote an > entire book about it and put it online for free, without advertisement. > This has taken over 3 years of my spare time, because I wanted Erlang to > be more accessible. I invite you to visit it at > http://learnyousomeerlang.com, and maybe buy an ebook or print copy if > you feel like it would be nicer to read that way. If you prefer a free > electronic copies, there are scripts on github to convert it to the > kindle format, and a wget line in the FAQ to download a local copy. > > I also kept writing multiple blog posts at http://ferd.ca that guide and > show more tutorials about Erlang, use cases, and tries to sell it as a > language as a whole. > > The reason I'm answering to your suggestion negatively isn't that I > don't want Erlang to succeed, it's that I do not believe that changing > the meaning of 'OTP' from 'Open Telecom Platform' to 'Open Technology > Platform' will have a noticeable impact. > > Some people do ask the question 'but I don't want to do telecoms', but > in my experience, people's issues are the following, to a much higher > degree: > > - The syntax is unfamiliar (or ugly) > - It's difficult to work with single assignment, recursion, immutable > algorithms (most of your algorithm books that rely on arrays with O(1) > access to work fine are no longer going to be trivial to translate! > That's huge!) > - The tooling (rebar, relx, etc.) isn't up to par with other languages, > even if it keeps getting better. > - Lack of IDEs (that was your prime concern when you joined these lists) > - Fighting the idea that "it will be hard to hire Erlang developers" to > make it enter and stay in the enterprise. > > All of those criticism, in the years I've been in the Erlang community, > have come up time and time again. They've also have come up orders of > magnitude more often than OTP as a name, even if it does come up from > time to time. > > I'm sorry I came up as harsh. I do want better adoption for Erlang and > took months if not years of my free time working that way. I do not > think renaming OTP is worth the effort, but I'll be glad to be proven > wrong through bigger adoption if someone steps up and decides to do it. > > Now if you please, I'll go back to spending my lunch time working on an > post-scripted chapter to the LYSE site introducing maps to people. > > Regards, > Fred. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Thu Feb 13 19:16:52 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Thu, 13 Feb 2014 13:16:52 -0500 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <52FD0B24.50400@meetinghouse.net> References: <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> <52FD0B24.50400@meetinghouse.net> Message-ID: <52FD0C14.6060004@meetinghouse.net> Miles Fidelman wrote: > kraythe . wrote: >> I have told you my "green" impressions of OTP and you can dismiss >> them if it make you more comfortable but it wont change the fact that >> others will have those feelings and many will not get on the list and >> go further. They will simply move to Ruby, Scala, Node.js, Clojure, >> or something else. If our attitude is "I didn't want you in the >> community anyway!" then Erlang will be the next Smalltalk or Lisp. Of >> academic and little more than that in significance. > > Bah, humbug. As long as there's a need for industrial strength > massive concurrency, and no serious alternative, it doesn't really > matter what it's called. > > Anybody who tries to write a massively concurrent application in Ruby, > Scala, Node.js, Cojure (or Java for that matter), gets what they deserve. > > Just one man's opinion, of course. > For that matter, what's with this trend toward renaming things - all it does is confuse people (think Accenture vs. Anderson Consulting). -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From john@REDACTED Thu Feb 13 19:22:00 2014 From: john@REDACTED (John Kemp) Date: Thu, 13 Feb 2014 13:22:00 -0500 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <28AAEE0D-905F-4681-B388-7C883CCBA7D3@gmail.com> <796EBF0D-8EE3-446F-AEB0-DEF64701311F@jkemp.net> Message-ID: <52FD0D48.9010802@jkemp.net> On 02/13/2014 11:44 AM, kraythe . wrote: > Cant agree with you John. That's fine :) > In an organization you cant simply do what you > want and shrug. > If I tried that in any of the big organizations i have > been involved with my optimal case is being fired. If I need to "convince" someone about the tech I want to use then I either wouldn't use that tech and would use what they wanted instead, or I would quit. It's absolutely the case that if you are driven by "social context" (by that I mean, roughly, "other people's concerns") alone, you won't choose Erlang. Although I would often choose Erlang for myself, I would often choose another language if I had a programmer of that language to work with, and a tight deadline. In my opinion, professional software developers should choose the best tool for the job -- and the job often includes more than the problem at hand, true. I like to make satisfied customers. > Perhaps if you own > the company you can. But then that relegates Erlang to niche. Makes the > old timers feel pretty superior As I've said, you can *choose* whatever language you like, and barring the edge cases, you'll be able to build a workable, relatively scalable solution. > but is a horrible waste of what appears > to me to be a very useful language. Also if you go that tact there is no > more point of arguing Erlang vs Scala or vs any language anymore. Erlang > will become like Smalltalk. Useful and cool for the old timers but > virtually IRRELEVANT in the IT industry. Erlang makes efficient use of computing resources, specifically in distributed environments. It does several other clever things. It's also hard to learn (for some programmers) and doesn't come with a ready "market" of/for proficient software developers. But those who learn it tend to understand the problems which Erlang is good at solving. And they understand why the language choices made in Erlang might be made, in which case, they will often understand other languages better than average devlopers too. > > Furthermore, if you argue you don't care about adoption then the > discussion is moot with you. What I will continue to explain what I have observed about the advantages of Erlang to those who will listen :) > it will mean is whomever is on your > development staff writing Erlang you better be open to paying them > whatever they want and letting them get away with about anything because > replacing them would be nearly impossible. Unfortunately, I usually work with people who are not in position to understand why one might use Erlang. Imagine that you have been initiated into a secret group of people who will help give you an advantage in your software projects that so few have. How could you use those skills? > Often many tech people cant > see past "oooh list comprehensions !!!!!!" to the actual business behind > it and without the business none of us get paid. That is not something > you can take to management and sell. Why not learn instead of sell? - johnk > > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* > /Author of: Hardcore Java (2003) and Maintainable Java (2012)/ > /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/ > > > On Thu, Feb 13, 2014 at 10:33 AM, John Kemp > wrote: > > On Feb 13, 2014, at 11:20 AM, kraythe . > wrote: > >> /Java as a language is big and complex, because it has a >> lot of concepts directly inside the language./ >> >> Ahh but here you are wrong. Java itself is analogous to Erlang >> without OTP. you don't HAVE to use the JDK libraries beyond >> java.lang. You would be a bit crazy reproducing the wheel if you >> did so but it is not a requirement of writing java. In fact many >> Java controlled micro devices only allow a very small subset of >> the JDK to be used. So there is essentially no difference. >> >> So Elang is to Java as the Java Development Kit is to the Open >> Telecom Platform. And there is where we have the "marketing" >> disconnect. Its not about changing functionality or a triviality >> to be scoffed over. If we start with the premise that we want more >> developers to learn and use Erlang then we have to consider how >> the language and its nomenclature comes across to our audience. >> You don't name a language the Scalable High Integration Technology >> because the impression it leaves with adopters is ... unfortunate. > > Why start with that premise instead of starting with the premise > that developers should try to understand what is useful to them? > That has nothing to do with marketing, and everything to do with > software developers understanding their craft better. > >> >> So if you DON'T care about people adopting the language, then the >> discussion is academic and simply, as one reply put it, a waste of >> time. Of course if you don't care about adoption then you are >> wasting your time here because you wont be able to staff a >> development crew, replace developers that leave or push the >> language into an organization which isn't currently using it. > > Who is ?you? in this case? Does the ?Erlang community? want to get > the language adopted more? Perhaps. Why would that matter to the > Erlang community - how do they benefit? Why should those who already > know and benefit from Erlang not simply continue to do so? > >> >> If you DO care about people adopting the language you have to >> consider its marketing. If I many were to take Erlang to >> management and propose it for a product the management would see >> "Open Telecom Platform", object that the company isn't a telecom >> company and that Erlang is mainly for telecom and that would be >> the end of that. In fact, if you really care about adoption you >> are better off renaming it "Fred" than leaving it as "Open Telecom >> Platform?. > > People reject languages for all kinds of strange reasons. And it?s > the case that in many cases you can simply choose ?a language you > like? and then *make* it work for what you want to do. After all, > computers have particular resources available to them, and a > language well-adapted to its environment should support adequate > performance for most applications. The distinction between threading > in Ruby and ?event-driven? in Node is largely meaningless, for > example. The real questions are things like ?how well does your > VM/compiler exploit computer hardware resources on the platform > you?re using?. Most developers don?t understand this, so they argue > about threads vs. processes vs. events without understanding what > might actually be the critical differences regarding the performance > they say they want. > > Naming won?t fix that. And management will never get that. You need > people to understand what they are doing. Or not. After all, you can > largely do what you like and apart from at the edges, it will likely > work. > > - johnk > >> >> Naming matters and it is also pretty easy to fix. >> >> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* >> /Author of: Hardcore Java (2003) and Maintainable Java (2012)/ >> /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/ >> >> >> On Thu, Feb 13, 2014 at 9:03 AM, Anthony Ramine > > wrote: >> >> That?s a *HUGE* difference. Erlang as a language is very >> small; OTP is a very complex piece of software, as is BEAM. >> The three shouldn?t be conflated. >> >> Java as a language is big and complex, because it has a lot of >> concepts directly inside the language. >> >> -- >> Anthony Ramine >> >> Le 13 f?vr. 2014 ? 15:59, Vlad Dumitrescu > > a ?crit : >> >> > On Thu, Feb 13, 2014 at 3:46 PM, Anthony Ramine >> > wrote: >> >> Java without OOP is a different language. >> >> Erlang without OTP is still Erlang. >> > >> > IMHO the only difference is that OTP is implemented as a >> library and >> > doesn't have dedicated language syntax. I make difference >> between OTP >> > as design/system building guidelines and its implementation. The >> > former is more like OOP for Java. The latter is more like >> the JDK. >> > >> > /Vlad >> > >> >> -- >> >> Anthony Ramine >> >> >> >> Le 13 f?vr. 2014 ? 15:21, Vlad Dumitrescu >> > a ?crit : >> >> >> >>> On Thu, Feb 13, 2014 at 2:09 PM, Benoit Chesneau >> > wrote: >> >>>> I also say Erlang/OTP and often I add to the one that ask >> that OTP is >> >>>> a framework, but then people are more puzzled than they >> were before. >> >>>> Maybe rust did the right things by clearly separating >> the language >> >>>> and the runtime from the standard library and other libs ? >> >>> >> >>> I would say that OTP is to Erlang what OOP is to Java. You >> can write >> >>> Java programs that are not object-oriented, but why choose >> Java for >> >>> that in the first place? >> >>> >> >>> OTP is in my opinion a design philosophy that guides us >> when it comes >> >>> to structuring and developing distributed fault-tolerant >> systems. It >> >>> comes with library support that is intimately tied to the >> Erlang >> >>> libraries: the most basic Erlang apps (kernel and stdlib) >> are also the >> >>> ones that implement the OTP concepts. Even more, Erlang >> code is >> >>> structured as applications, and an "application" is an OTP >> concept! >> >>> >> >>> I can only see meaning in trying to separate the language >> from OTP >> >>> either as an academic exercise or in order to implement a >> different >> >>> language on the beam runtime and the new concepts would >> collide >> >>> implementation-wise with OTP. Or one wants to create OTP >> 2.0 without >> >>> interference with 1.0. >> >>> >> >>> 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 >> >> >> _______________________________________________ >> 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 kraythe@REDACTED Thu Feb 13 19:22:54 2014 From: kraythe@REDACTED (kraythe .) Date: Thu, 13 Feb 2014 12:22:54 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <52FD0C14.6060004@meetinghouse.net> References: <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> <52FD0B24.50400@meetinghouse.net> <52FD0C14.6060004@meetinghouse.net> Message-ID: Ahh well. I have had my say and stated my opinions more than once. So I can leave it there. It is, however, definitely food for thought about the direction I wish to go with my project. Not so much the issue of OTP as a name but the general impression of "adoption? bah humbug ... if they don't like it they all suck and we don't care." Sounds like a disaster of a business decision to me. Im not so sure its going to be easy to staff or finance a project on a language that has 1) tools that need work, 2) a limited trained staff 3) a community that cares little about language adoption. It could be that Erlang becomes another Lisp for me. A language I think rocks but is entirely impractical in the business world. *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* *Author of: Hardcore Java (2003) and Maintainable Java (2012)* *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 * On Thu, Feb 13, 2014 at 12:16 PM, Miles Fidelman wrote: > Miles Fidelman wrote: > >> kraythe . wrote: >> >>> I have told you my "green" impressions of OTP and you can dismiss them >>> if it make you more comfortable but it wont change the fact that others >>> will have those feelings and many will not get on the list and go further. >>> They will simply move to Ruby, Scala, Node.js, Clojure, or something else. >>> If our attitude is "I didn't want you in the community anyway!" then Erlang >>> will be the next Smalltalk or Lisp. Of academic and little more than that >>> in significance. >>> >> >> Bah, humbug. As long as there's a need for industrial strength massive >> concurrency, and no serious alternative, it doesn't really matter what it's >> called. >> >> Anybody who tries to write a massively concurrent application in Ruby, >> Scala, Node.js, Cojure (or Java for that matter), gets what they deserve. >> >> Just one man's opinion, of course. >> >> > For that matter, what's with this trend toward renaming things - all it > does is confuse people (think Accenture vs. Anderson Consulting). > > > > -- > 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 erlang@REDACTED Thu Feb 13 19:25:57 2014 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 13 Feb 2014 19:25:57 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> Message-ID: On Thu, Feb 13, 2014 at 2:09 PM, Benoit Chesneau wrote: > On Thu, Feb 13, 2014 at 1:25 PM, Carsten Bormann wrote: > > On 13 Feb 2014, at 13:05, Lo?c Hoguin wrote: > > > >>>> No I'm serious, you can use Erlang without OTP. > >>> > >>> maybe but who is doing it today? Or rather what are the selling points > >>> of just using Erlang without OTP? > >> > >> [...] > >> Or if I wanted to use Erlang for writing small administration scripts > that's probably also what I would do, as the fast boot is a really > important feature there. > > > > > It is such a jolly good idea that Joe spends a whole appendix in his > book about doing just that. > > (Appendix 3, "A Simple Execution Environment".) > Which boots in 20 ms (on the same machine OTP takes 1.1 seconds) Note that OTP was designed for systems that run for ever - not shell scripts. 1.1 seconds amortized over a few years is not a problem - so there is not attempt to optimize this. The 20ms that my stand-alone system takes *was* optimised for quick start and could be made even quicker - but this would require hard work. Cheers /Joe > > > > Gr??e, Carsten > > > > But who is doing it today? The question stands. I mean OK, eventually > you can just use Erlang without all the OTP (even if it requires a new > boot script), but people don't come on erlang because of the language > but due to OTP. And few knows you can use Erlang the other way. OTP > is the selling point right now. (Not saying it should be) > > I also say Erlang/OTP and often I add to the one that ask that OTP is > a framework, but then people are more puzzled than they were before. > Maybe rust did the right things by clearly separating the language > and the runtime from the standard library and other libs ? > > - benoit > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kraythe@REDACTED Thu Feb 13 19:28:51 2014 From: kraythe@REDACTED (kraythe .) Date: Thu, 13 Feb 2014 12:28:51 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <52FD0D48.9010802@jkemp.net> References: <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <28AAEE0D-905F-4681-B388-7C883CCBA7D3@gmail.com> <796EBF0D-8EE3-446F-AEB0-DEF64701311F@jkemp.net> <52FD0D48.9010802@jkemp.net> Message-ID: > > Why not learn instead of sell? Because the bank wont take "I learned Erlang this month" in lie of my car payment or mortgage. Because innovations are rarely created for the purposes of "learn, not sell." Erlang itself was created to Sell, be under no misunderstanding. If Ericson couldn't make a case to the "sellers" then the language wouldn't have powered their switch. Because capitalism and libertarianism work and communism and socialism eventually run out of other people's money. And because I don't want to be someone living on someone else's dime. I like to create, innovate, invent and get paid for it. That lets me provide a better life for my family. *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* *Author of: Hardcore Java (2003) and Maintainable Java (2012)* *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 * On Thu, Feb 13, 2014 at 12:22 PM, John Kemp wrote: > On 02/13/2014 11:44 AM, kraythe . wrote: > >> Cant agree with you John. >> > > That's fine :) > > > In an organization you cant simply do what you >> want and shrug. >> If I tried that in any of the big organizations i have >> been involved with my optimal case is being fired. >> > > If I need to "convince" someone about the tech I want to use then I either > wouldn't use that tech and would use what they wanted instead, or I would > quit. > > It's absolutely the case that if you are driven by "social context" (by > that I mean, roughly, "other people's concerns") alone, you won't choose > Erlang. > > Although I would often choose Erlang for myself, I would often choose > another language if I had a programmer of that language to work with, and a > tight deadline. > > In my opinion, professional software developers should choose the best > tool for the job -- and the job often includes more than the problem at > hand, true. I like to make satisfied customers. > > > Perhaps if you own >> the company you can. But then that relegates Erlang to niche. Makes the >> old timers feel pretty superior >> > > As I've said, you can *choose* whatever language you like, and barring the > edge cases, you'll be able to build a workable, relatively scalable > solution. > > > but is a horrible waste of what appears >> to me to be a very useful language. Also if you go that tact there is no >> more point of arguing Erlang vs Scala or vs any language anymore. Erlang >> will become like Smalltalk. Useful and cool for the old timers but >> virtually IRRELEVANT in the IT industry. >> > > Erlang makes efficient use of computing resources, specifically in > distributed environments. It does several other clever things. It's also > hard to learn (for some programmers) and doesn't come with a ready "market" > of/for proficient software developers. But those who learn it tend to > understand the problems which Erlang is good at solving. And they > understand why the language choices made in Erlang might be made, in which > case, they will often understand other languages better than average > devlopers too. > > > >> Furthermore, if you argue you don't care about adoption then the >> discussion is moot with you. What >> > > I will continue to explain what I have observed about the advantages of > Erlang to those who will listen :) > > > it will mean is whomever is on your >> development staff writing Erlang you better be open to paying them >> whatever they want and letting them get away with about anything because >> replacing them would be nearly impossible. >> > > Unfortunately, I usually work with people who are not in position to > understand why one might use Erlang. > > Imagine that you have been initiated into a secret group of people who > will help give you an advantage in your software projects that so few have. > How could you use those skills? > > > Often many tech people cant >> see past "oooh list comprehensions !!!!!!" to the actual business behind >> it and without the business none of us get paid. That is not something >> you can take to management and sell. >> > > Why not learn instead of sell? > > - johnk > >> >> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* >> /Author of: Hardcore Java (2003) and Maintainable Java (2012)/ >> /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/ >> >> >> >> On Thu, Feb 13, 2014 at 10:33 AM, John Kemp > > wrote: >> >> On Feb 13, 2014, at 11:20 AM, kraythe . > > wrote: >> >> /Java as a language is big and complex, because it has a >>> lot of concepts directly inside the language./ >>> >>> >>> Ahh but here you are wrong. Java itself is analogous to Erlang >>> without OTP. you don't HAVE to use the JDK libraries beyond >>> java.lang. You would be a bit crazy reproducing the wheel if you >>> did so but it is not a requirement of writing java. In fact many >>> Java controlled micro devices only allow a very small subset of >>> the JDK to be used. So there is essentially no difference. >>> >>> So Elang is to Java as the Java Development Kit is to the Open >>> Telecom Platform. And there is where we have the "marketing" >>> disconnect. Its not about changing functionality or a triviality >>> to be scoffed over. If we start with the premise that we want more >>> developers to learn and use Erlang then we have to consider how >>> the language and its nomenclature comes across to our audience. >>> You don't name a language the Scalable High Integration Technology >>> because the impression it leaves with adopters is ... unfortunate. >>> >> >> Why start with that premise instead of starting with the premise >> that developers should try to understand what is useful to them? >> That has nothing to do with marketing, and everything to do with >> software developers understanding their craft better. >> >> >>> So if you DON'T care about people adopting the language, then the >>> discussion is academic and simply, as one reply put it, a waste of >>> time. Of course if you don't care about adoption then you are >>> wasting your time here because you wont be able to staff a >>> development crew, replace developers that leave or push the >>> language into an organization which isn't currently using it. >>> >> >> Who is "you" in this case? Does the "Erlang community" want to get >> the language adopted more? Perhaps. Why would that matter to the >> Erlang community - how do they benefit? Why should those who already >> know and benefit from Erlang not simply continue to do so? >> >> >>> If you DO care about people adopting the language you have to >>> consider its marketing. If I many were to take Erlang to >>> management and propose it for a product the management would see >>> "Open Telecom Platform", object that the company isn't a telecom >>> company and that Erlang is mainly for telecom and that would be >>> the end of that. In fact, if you really care about adoption you >>> are better off renaming it "Fred" than leaving it as "Open Telecom >>> Platform". >>> >> >> People reject languages for all kinds of strange reasons. And it's >> the case that in many cases you can simply choose "a language you >> like" and then *make* it work for what you want to do. After all, >> computers have particular resources available to them, and a >> language well-adapted to its environment should support adequate >> performance for most applications. The distinction between threading >> in Ruby and "event-driven" in Node is largely meaningless, for >> example. The real questions are things like "how well does your >> VM/compiler exploit computer hardware resources on the platform >> you're using". Most developers don't understand this, so they argue >> about threads vs. processes vs. events without understanding what >> might actually be the critical differences regarding the performance >> they say they want. >> >> Naming won't fix that. And management will never get that. You need >> people to understand what they are doing. Or not. After all, you can >> largely do what you like and apart from at the edges, it will likely >> work. >> >> - johnk >> >> >>> Naming matters and it is also pretty easy to fix. >>> >>> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* >>> /Author of: Hardcore Java (2003) and Maintainable Java (2012)/ >>> /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/ >>> >>> >>> >>> On Thu, Feb 13, 2014 at 9:03 AM, Anthony Ramine >> > wrote: >>> >>> That's a *HUGE* difference. Erlang as a language is very >>> small; OTP is a very complex piece of software, as is BEAM. >>> The three shouldn't be conflated. >>> >>> Java as a language is big and complex, because it has a lot of >>> concepts directly inside the language. >>> >>> -- >>> Anthony Ramine >>> >>> Le 13 f?vr. 2014 ? 15:59, Vlad Dumitrescu >> > a ?crit : >>> >>> >>> > On Thu, Feb 13, 2014 at 3:46 PM, Anthony Ramine >>> > wrote: >>> >> Java without OOP is a different language. >>> >> Erlang without OTP is still Erlang. >>> > >>> > IMHO the only difference is that OTP is implemented as a >>> library and >>> > doesn't have dedicated language syntax. I make difference >>> between OTP >>> > as design/system building guidelines and its implementation. >>> The >>> > former is more like OOP for Java. The latter is more like >>> the JDK. >>> > >>> > /Vlad >>> > >>> >> -- >>> >> Anthony Ramine >>> >> >>> >> Le 13 f?vr. 2014 ? 15:21, Vlad Dumitrescu >>> > a ?crit : >>> >>> >> >>> >>> On Thu, Feb 13, 2014 at 2:09 PM, Benoit Chesneau >>> > wrote: >>> >>>> I also say Erlang/OTP and often I add to the one that ask >>> that OTP is >>> >>>> a framework, but then people are more puzzled than they >>> were before. >>> >>>> Maybe rust did the right things by clearly separating >>> the language >>> >>>> and the runtime from the standard library and other libs ? >>> >>> >>> >>> I would say that OTP is to Erlang what OOP is to Java. You >>> can write >>> >>> Java programs that are not object-oriented, but why choose >>> Java for >>> >>> that in the first place? >>> >>> >>> >>> OTP is in my opinion a design philosophy that guides us >>> when it comes >>> >>> to structuring and developing distributed fault-tolerant >>> systems. It >>> >>> comes with library support that is intimately tied to the >>> Erlang >>> >>> libraries: the most basic Erlang apps (kernel and stdlib) >>> are also the >>> >>> ones that implement the OTP concepts. Even more, Erlang >>> code is >>> >>> structured as applications, and an "application" is an OTP >>> concept! >>> >>> >>> >>> I can only see meaning in trying to separate the language >>> from OTP >>> >>> either as an academic exercise or in order to implement a >>> different >>> >>> language on the beam runtime and the new concepts would >>> collide >>> >>> implementation-wise with OTP. Or one wants to create OTP >>> 2.0 without >>> >>> interference with 1.0. >>> >>> >>> >>> 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 >>> >>> >>> _______________________________________________ >>> 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 tristan.sloughter@REDACTED Thu Feb 13 19:33:08 2014 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Thu, 13 Feb 2014 10:33:08 -0800 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> <52FD0B24.50400@meetinghouse.net> <52FD0C14.6060004@meetinghouse.net> Message-ID: <1392316388.11262.83083549.43ECED72@webmail.messagingengine.com> Yet provided no proof that changing the word Telecom would improve adoption or that it hurts adoption. Additionally no proof that causing adoption based on some name changes and marketing are a good thing. There was a boon in Erlang usage some 5 years ago that left a sour taste in many peoples mouths because it was incorrectly used for problems that both fit the language and those that didn't. Time is better spent building systems and tools than naming or trying to ride a wave of 'reactive' or 'async' or whatever else is the fad at the time. Sun did a great job with pushing Java into realms it wasn't built for. I want increased adoption, but for the right reasons. On Thu, Feb 13, 2014, at 10:22 AM, kraythe . wrote: Ahh well. I have had my say and stated my opinions more than once. So I can leave it there. It is, however, definitely food for thought about the direction I wish to go with my project. Not so much the issue of OTP as a name but the general impression of "adoption? bah humbug ... if they don't like it they all suck and we don't care." Sounds like a disaster of a business decision to me. Im not so sure its going to be easy to staff or finance a project on a language that has 1) tools that need work, 2) a limited trained staff 3) a community that cares little about language adoption. It could be that Erlang becomes another Lisp for me. A language I think rocks but is entirely impractical in the business world. Robert Simmons Jr. MSc. - Lead Java Architect @ EA Author of: Hardcore Java (2003) and Maintainable Java (2012) LinkedIn: [1]http://www.linkedin.com/pub/robert-simmons/40/852/a39 On Thu, Feb 13, 2014 at 12:16 PM, Miles Fidelman <[2]mfidelman@REDACTED> wrote: Miles Fidelman wrote: kraythe . wrote: I have told you my "green" impressions of OTP and you can dismiss them if it make you more comfortable but it wont change the fact that others will have those feelings and many will not get on the list and go further. They will simply move to Ruby, Scala, Node.js, Clojure, or something else. If our attitude is "I didn't want you in the community anyway!" then Erlang will be the next Smalltalk or Lisp. Of academic and little more than that in significance. Bah, humbug. As long as there's a need for industrial strength massive concurrency, and no serious alternative, it doesn't really matter what it's called. Anybody who tries to write a massively concurrent application in Ruby, Scala, Node.js, Cojure (or Java for that matter), gets what they deserve. Just one man's opinion, of course. For that matter, what's with this trend toward renaming things - all it does is confuse people (think Accenture vs. Anderson Consulting). -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra _______________________________________________ erlang-questions mailing list [3]erlang-questions@REDACTED [4]http://erlang.org/mailman/listinfo/erlang-questions _______________________________________________ erlang-questions mailing list [5]erlang-questions@REDACTED [6]http://erlang.org/mailman/listinfo/erlang-questions -- Tristan Sloughter tristan.sloughter@REDACTED References 1. http://www.linkedin.com/pub/robert-simmons/40/852/a39 2. mailto:mfidelman@REDACTED 3. mailto:erlang-questions@REDACTED 4. http://erlang.org/mailman/listinfo/erlang-questions 5. mailto:erlang-questions@REDACTED 6. http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Thu Feb 13 19:34:22 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Thu, 13 Feb 2014 18:34:22 +0000 Subject: [erlang-questions] release upgrades and code loading In-Reply-To: References: <52FD0826.2080305@llaisdy.com> Message-ID: <52FD102E.9040908@llaisdy.com> Dear Paul Thanks for your comment. Yes, in the relup file everythnig looks in place: load_object_code, brutal_purge, code_change up, resume, etc. Ivan On 13/02/2014 18:08, Paul Davis wrote: > Have you looked at the generated relup to make sure it includes the > appropriate instructions for upgrade the modules in question? > > On Thu, Feb 13, 2014 at 12:00 PM, Ivan Uemlianin wrote: >> Dear All >> >> I am just getting started with live release upgrades, using relx and >> following this tutorial: >> >> http://blog.troutwine.us/2013/09/13/trivial_otp_releases.html >> >> Everything seems to work as advertised, except sometimes I need to >> explicitly load the code into the running vm (i.e., using code_load_file/1) >> for the new stuff to take effect. The function >> release_handler:which_releases/0 reports the new release as active and >> permanent, but I can see from behaviour that old versions of certain modules >> are still running and handling data. >> >> I can't be much more specific I'm afraid. One example: one application uses >> cowboy. If a release upgrade changes a cowboy resource module, the new >> release version might still be running the old version of that module until >> I load_file and purge. >> >> Why might this be happening? Am I missing something in the packaging and >> upgrade process? Is there a better way I can write my modules? >> >> If the information above is too vague, what should I look out for next time >> this happens? >> >> With thanks and best wishes >> >> Ivan >> >> >> -- >> ============================================================ >> Ivan A. Uemlianin PhD >> Llaisdy >> Speech Technology Research and Development >> >> ivan@REDACTED >> www.llaisdy.com >> llaisdy.wordpress.com >> github.com/llaisdy >> www.linkedin.com/in/ivanuemlianin >> >> festina lente >> ============================================================ >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From paul.joseph.davis@REDACTED Thu Feb 13 19:36:12 2014 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Thu, 13 Feb 2014 12:36:12 -0600 Subject: [erlang-questions] release upgrades and code loading In-Reply-To: <52FD102E.9040908@llaisdy.com> References: <52FD0826.2080305@llaisdy.com> <52FD102E.9040908@llaisdy.com> Message-ID: Ah, then I haven't got much other than to suggest asking the relx group if they've seen similar. On Thu, Feb 13, 2014 at 12:34 PM, Ivan Uemlianin wrote: > Dear Paul > > Thanks for your comment. > > Yes, in the relup file everythnig looks in place: load_object_code, > brutal_purge, code_change up, resume, etc. > > Ivan > > > > On 13/02/2014 18:08, Paul Davis wrote: >> >> Have you looked at the generated relup to make sure it includes the >> appropriate instructions for upgrade the modules in question? >> >> On Thu, Feb 13, 2014 at 12:00 PM, Ivan Uemlianin wrote: >>> >>> Dear All >>> >>> I am just getting started with live release upgrades, using relx and >>> following this tutorial: >>> >>> http://blog.troutwine.us/2013/09/13/trivial_otp_releases.html >>> >>> Everything seems to work as advertised, except sometimes I need to >>> explicitly load the code into the running vm (i.e., using >>> code_load_file/1) >>> for the new stuff to take effect. The function >>> release_handler:which_releases/0 reports the new release as active and >>> permanent, but I can see from behaviour that old versions of certain >>> modules >>> are still running and handling data. >>> >>> I can't be much more specific I'm afraid. One example: one application >>> uses >>> cowboy. If a release upgrade changes a cowboy resource module, the new >>> release version might still be running the old version of that module >>> until >>> I load_file and purge. >>> >>> Why might this be happening? Am I missing something in the packaging and >>> upgrade process? Is there a better way I can write my modules? >>> >>> If the information above is too vague, what should I look out for next >>> time >>> this happens? >>> >>> With thanks and best wishes >>> >>> Ivan >>> >>> >>> -- >>> ============================================================ >>> Ivan A. Uemlianin PhD >>> Llaisdy >>> Speech Technology Research and Development >>> >>> ivan@REDACTED >>> www.llaisdy.com >>> llaisdy.wordpress.com >>> github.com/llaisdy >>> www.linkedin.com/in/ivanuemlianin >>> >>> festina lente >>> ============================================================ >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions > > > -- > ============================================================ > Ivan A. Uemlianin PhD > Llaisdy > Speech Technology Research and Development > > ivan@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > github.com/llaisdy > www.linkedin.com/in/ivanuemlianin > > festina lente > ============================================================ From n.oxyde@REDACTED Thu Feb 13 19:36:53 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 13 Feb 2014 19:36:53 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <28AAEE0D-905F-4681-B388-7C883CCBA7D3@gmail.com> <796EBF0D-8EE3-446F-AEB0-DEF64701311F@jkemp.net> <52FD0D48.9010802@jkemp.net> Message-ID: <3F63867E-19EC-43ED-8CB6-A595A120D6B1@gmail.com> Let's keep political opinions out of here, thank you. -- Anthony Ramine > Le 13 f?vr. 2014 ? 19:28, "kraythe ." a ?crit : > > Because capitalism and libertarianism work and communism and socialism eventually run out of other people's money. From sergej.jurecko@REDACTED Thu Feb 13 19:37:24 2014 From: sergej.jurecko@REDACTED (Sergej Jurecko) Date: Thu, 13 Feb 2014 19:37:24 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <28AAEE0D-905F-4681-B388-7C883CCBA7D3@gmail.com> <796EBF0D-8EE3-446F-AEB0-DEF64701311F@jkemp.net> <52FD0D48.9010802@jkemp.net> Message-ID: So... does anyone else miss the good old days of the erlang-questions mailing list? When it did not generate 100 emails a day with endless discussions about issues that are obviously never going to change? Sergej On Feb 13, 2014, at 7:28 PM, kraythe . wrote: > Why not learn instead of sell? > > Because the bank wont take "I learned Erlang this month" in lie of my car payment or mortgage. Because innovations are rarely created for the purposes of "learn, not sell." Erlang itself was created to Sell, be under no misunderstanding. If Ericson couldn't make a case to the "sellers" then the language wouldn't have powered their switch. Because capitalism and libertarianism work and communism and socialism eventually run out of other people's money. And because I don't want to be someone living on someone else's dime. I like to create, innovate, invent and get paid for it. That lets me provide a better life for my family. > > Robert Simmons Jr. MSc. - Lead Java Architect @ EA > Author of: Hardcore Java (2003) and Maintainable Java (2012) > LinkedIn: http://www.linkedin.com/pub/robert-simmons/40/852/a39 > > > On Thu, Feb 13, 2014 at 12:22 PM, John Kemp wrote: > On 02/13/2014 11:44 AM, kraythe . wrote: > Cant agree with you John. > > That's fine :) > > > In an organization you cant simply do what you > want and shrug. > If I tried that in any of the big organizations i have > been involved with my optimal case is being fired. > > If I need to "convince" someone about the tech I want to use then I either wouldn't use that tech and would use what they wanted instead, or I would quit. > > It's absolutely the case that if you are driven by "social context" (by that I mean, roughly, "other people's concerns") alone, you won't choose Erlang. > > Although I would often choose Erlang for myself, I would often choose another language if I had a programmer of that language to work with, and a tight deadline. > > In my opinion, professional software developers should choose the best tool for the job -- and the job often includes more than the problem at hand, true. I like to make satisfied customers. > > > Perhaps if you own > the company you can. But then that relegates Erlang to niche. Makes the > old timers feel pretty superior > > As I've said, you can *choose* whatever language you like, and barring the edge cases, you'll be able to build a workable, relatively scalable solution. > > > but is a horrible waste of what appears > to me to be a very useful language. Also if you go that tact there is no > more point of arguing Erlang vs Scala or vs any language anymore. Erlang > will become like Smalltalk. Useful and cool for the old timers but > virtually IRRELEVANT in the IT industry. > > Erlang makes efficient use of computing resources, specifically in distributed environments. It does several other clever things. It's also hard to learn (for some programmers) and doesn't come with a ready "market" of/for proficient software developers. But those who learn it tend to understand the problems which Erlang is good at solving. And they understand why the language choices made in Erlang might be made, in which case, they will often understand other languages better than average devlopers too. > > > > Furthermore, if you argue you don't care about adoption then the > discussion is moot with you. What > > I will continue to explain what I have observed about the advantages of Erlang to those who will listen :) > > > it will mean is whomever is on your > development staff writing Erlang you better be open to paying them > whatever they want and letting them get away with about anything because > replacing them would be nearly impossible. > > Unfortunately, I usually work with people who are not in position to understand why one might use Erlang. > > Imagine that you have been initiated into a secret group of people who will help give you an advantage in your software projects that so few have. How could you use those skills? > > > Often many tech people cant > see past "oooh list comprehensions !!!!!!" to the actual business behind > it and without the business none of us get paid. That is not something > you can take to management and sell. > > Why not learn instead of sell? > > - johnk > > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* > /Author of: Hardcore Java (2003) and Maintainable Java (2012)/ > /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/ > > > > On Thu, Feb 13, 2014 at 10:33 AM, John Kemp > wrote: > > On Feb 13, 2014, at 11:20 AM, kraythe . > wrote: > > /Java as a language is big and complex, because it has a > lot of concepts directly inside the language./ > > > Ahh but here you are wrong. Java itself is analogous to Erlang > without OTP. you don't HAVE to use the JDK libraries beyond > java.lang. You would be a bit crazy reproducing the wheel if you > did so but it is not a requirement of writing java. In fact many > Java controlled micro devices only allow a very small subset of > the JDK to be used. So there is essentially no difference. > > So Elang is to Java as the Java Development Kit is to the Open > Telecom Platform. And there is where we have the "marketing" > disconnect. Its not about changing functionality or a triviality > to be scoffed over. If we start with the premise that we want more > developers to learn and use Erlang then we have to consider how > the language and its nomenclature comes across to our audience. > You don't name a language the Scalable High Integration Technology > because the impression it leaves with adopters is ... unfortunate. > > Why start with that premise instead of starting with the premise > that developers should try to understand what is useful to them? > That has nothing to do with marketing, and everything to do with > software developers understanding their craft better. > > > So if you DON'T care about people adopting the language, then the > discussion is academic and simply, as one reply put it, a waste of > time. Of course if you don't care about adoption then you are > wasting your time here because you wont be able to staff a > development crew, replace developers that leave or push the > language into an organization which isn't currently using it. > > Who is ?you? in this case? Does the ?Erlang community? want to get > the language adopted more? Perhaps. Why would that matter to the > Erlang community - how do they benefit? Why should those who already > know and benefit from Erlang not simply continue to do so? > > > If you DO care about people adopting the language you have to > consider its marketing. If I many were to take Erlang to > management and propose it for a product the management would see > "Open Telecom Platform", object that the company isn't a telecom > company and that Erlang is mainly for telecom and that would be > the end of that. In fact, if you really care about adoption you > are better off renaming it "Fred" than leaving it as "Open Telecom > Platform?. > > People reject languages for all kinds of strange reasons. And it?s > the case that in many cases you can simply choose ?a language you > like? and then *make* it work for what you want to do. After all, > computers have particular resources available to them, and a > language well-adapted to its environment should support adequate > performance for most applications. The distinction between threading > in Ruby and ?event-driven? in Node is largely meaningless, for > example. The real questions are things like ?how well does your > VM/compiler exploit computer hardware resources on the platform > you?re using?. Most developers don?t understand this, so they argue > about threads vs. processes vs. events without understanding what > might actually be the critical differences regarding the performance > they say they want. > > Naming won?t fix that. And management will never get that. You need > people to understand what they are doing. Or not. After all, you can > largely do what you like and apart from at the edges, it will likely > work. > > - johnk > > > Naming matters and it is also pretty easy to fix. > > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* > /Author of: Hardcore Java (2003) and Maintainable Java (2012)/ > /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/ > > > > On Thu, Feb 13, 2014 at 9:03 AM, Anthony Ramine > wrote: > > That?s a *HUGE* difference. Erlang as a language is very > small; OTP is a very complex piece of software, as is BEAM. > The three shouldn?t be conflated. > > Java as a language is big and complex, because it has a lot of > concepts directly inside the language. > > -- > Anthony Ramine > > Le 13 f?vr. 2014 ? 15:59, Vlad Dumitrescu > a ?crit : > > > > On Thu, Feb 13, 2014 at 3:46 PM, Anthony Ramine > > wrote: > >> Java without OOP is a different language. > >> Erlang without OTP is still Erlang. > > > > IMHO the only difference is that OTP is implemented as a > library and > > doesn't have dedicated language syntax. I make difference > between OTP > > as design/system building guidelines and its implementation. The > > former is more like OOP for Java. The latter is more like > the JDK. > > > > /Vlad > > > >> -- > >> Anthony Ramine > >> > >> Le 13 f?vr. 2014 ? 15:21, Vlad Dumitrescu > > a ?crit : > > >> > >>> On Thu, Feb 13, 2014 at 2:09 PM, Benoit Chesneau > > wrote: > >>>> I also say Erlang/OTP and often I add to the one that ask > that OTP is > >>>> a framework, but then people are more puzzled than they > were before. > >>>> Maybe rust did the right things by clearly separating > the language > >>>> and the runtime from the standard library and other libs ? > >>> > >>> I would say that OTP is to Erlang what OOP is to Java. You > can write > >>> Java programs that are not object-oriented, but why choose > Java for > >>> that in the first place? > >>> > >>> OTP is in my opinion a design philosophy that guides us > when it comes > >>> to structuring and developing distributed fault-tolerant > systems. It > >>> comes with library support that is intimately tied to the > Erlang > >>> libraries: the most basic Erlang apps (kernel and stdlib) > are also the > >>> ones that implement the OTP concepts. Even more, Erlang > code is > >>> structured as applications, and an "application" is an OTP > concept! > >>> > >>> I can only see meaning in trying to separate the language > from OTP > >>> either as an academic exercise or in order to implement a > different > >>> language on the beam runtime and the new concepts would > collide > >>> implementation-wise with OTP. Or one wants to create OTP > 2.0 without > >>> interference with 1.0. > >>> > >>> 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 > > > _______________________________________________ > 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 erlang@REDACTED Thu Feb 13 19:41:57 2014 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 13 Feb 2014 19:41:57 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <28AAEE0D-905F-4681-B388-7C883CCBA7D3@gmail.com> Message-ID: On Thu, Feb 13, 2014 at 5:52 PM, Mahesh Paolini-Subramanya < mahesh@REDACTED> wrote: > Marketing matters - true. > Absolutely and if somebody would like to pony up a few million dollars for this or even a few million kronor we can get to work. Right now there is no budget for this - so what you get is what people freely provide. Most Erlang developers are using Erlang to gain a commercial advantage for their company so I can't imagine WhatsApp or Opscode ponying up $$$ to help their competitors catch up. They must be *overjoyed* that their competitors *don't* use Erlang. Erlang solutions do want more Erlang users - but they spend their marketing budget on the conferences. There is no commercial interest in stepping up the marketing. Erlang programmers would like there to be more erlang programming job opportunities (for job security) but they do not want to finance a marketing push. Somebody has to gain financially from a marketing push - but who is this? Cheers /Joe > So lets look at the reality of the market. > Every java project that gets worked on probably creates an ongoing demand > for, int(X/5 + 3) new java developers, where X is the number of developers > on the original project (1). > From an economics perspective, this translates to a market where > - it pays to write applications in java (they may break, but you can > probably find people to help fix it) > - it pays to be a java consulting firm (you have no trouble finding > clients) > - it pays to learn java ('cos you'll get hired by a consulting firm for a > pittance, no matter how terrible you are...) > In short, the Markets for Java are constantly expanding - new projects > being worked on, leading to new developers coming in the mix, etc. > > On the other hand, every project that gets written in Erlang probably (and > typically) creates an ongoing demand for rem(1/Y) + 1 developers, where Y > is the number of DevOps people you already have.. > From an economics perspective, this translates to a market where > - it pays to write applications in erlang (they don't break, so you don't > really need to find people to hire) (2) > - it DOESN'T pay to be an erlang consulting form (with apologies to ESL) > In short, the markets for Erlang are *not* growing - there tends to be a > fairly stable supply of developers moving from project to project, and the > number of *new* developers, while growing, is by no means growing rapidly > - and thats largely because there is no *need* for large numbers of new > developers. (And Garrett - thats the answer to why you don't see more > uptake) > > What does this have to do with marketing? > Basically that kraythe may be on to something here. If we want a large > uptake for erlang, it is *not* going to be because of the inherent quality. > If anything, the very stability that erlang is diametrically opposed to > its market expansion! > In short, erlang needs to be sold on *other* merits, on polish, on gleam, > on lustre, on coolness. Take a lesson from DeBeers - > sell the shine, not the content. > > Cheers > > > > (1) Maintenance, JDK management in production, bug fixes, support, and > god-forbid, any issues in it being a distributed system > (2) Ok. Yes, they break. But that doesn't really matter, because in the > Erlang world, "good enough" is actually a feasible construct, and one that > you can get away with. Its also one of the reason that so many of the > erlang projects tend to be about 80% of the way there - because they're > Good Enough, and you're productive enough that you don't need to worry > about the remaining 20%. Let It Crash actually works as a philosophy (and > kids, don't try that with Ruby. Or Assembler. Or C++. Or, well, anything > not Erlang) > > > > *Mahesh Paolini-Subramanya > That > tall bald Indian guy.. * > *Google+ | Blog > | Twitter > | LinkedIn > * > > On February 13, 2014 at 5:20:47 PM, kraythe . (kraythe@REDACTED) > wrote: > > *Java as a language is big and complex, because it has a lot of >> concepts directly inside the language.* > > > > Ahh but here you are wrong. Java itself is analogous to Erlang without > OTP. you don't HAVE to use the JDK libraries beyond java.lang. You would be > a bit crazy reproducing the wheel if you did so but it is not a requirement > of writing java. In fact many Java controlled micro devices only allow a > very small subset of the JDK to be used. So there is essentially no > difference. > > So Elang is to Java as the Java Development Kit is to the Open Telecom > Platform. And there is where we have the "marketing" disconnect. Its not > about changing functionality or a triviality to be scoffed over. If we > start with the premise that we want more developers to learn and use Erlang > then we have to consider how the language and its nomenclature comes across > to our audience. You don't name a language the Scalable High Integration > Technology because the impression it leaves with adopters is ... > unfortunate. > > So if you DON'T care about people adopting the language, then the > discussion is academic and simply, as one reply put it, a waste of time. Of > course if you don't care about adoption then you are wasting your time here > because you wont be able to staff a development crew, replace developers > that leave or push the language into an organization which isn't currently > using it. > > If you DO care about people adopting the language you have to consider its > marketing. If I many were to take Erlang to management and propose it for a > product the management would see "Open Telecom Platform", object that the > company isn't a telecom company and that Erlang is mainly for telecom and > that would be the end of that. In fact, if you really care about adoption > you are better off renaming it "Fred" than leaving it as "Open Telecom > Platform". > > Naming matters and it is also pretty easy to fix. > > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* > *Author of: Hardcore Java (2003) and Maintainable Java (2012)* > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 > * > > > On Thu, Feb 13, 2014 at 9:03 AM, Anthony Ramine wrote: > >> That's a *HUGE* difference. Erlang as a language is very small; OTP is a >> very complex piece of software, as is BEAM. The three shouldn't be >> conflated. >> >> Java as a language is big and complex, because it has a lot of concepts >> directly inside the language. >> >> -- >> Anthony Ramine >> >> Le 13 f?vr. 2014 ? 15:59, Vlad Dumitrescu a ?crit : >> >> > On Thu, Feb 13, 2014 at 3:46 PM, Anthony Ramine >> wrote: >> >> Java without OOP is a different language. >> >> Erlang without OTP is still Erlang. >> > >> > IMHO the only difference is that OTP is implemented as a library and >> > doesn't have dedicated language syntax. I make difference between OTP >> > as design/system building guidelines and its implementation. The >> > former is more like OOP for Java. The latter is more like the JDK. >> > >> > /Vlad >> > >> >> -- >> >> Anthony Ramine >> >> >> >> Le 13 f?vr. 2014 ? 15:21, Vlad Dumitrescu a >> ?crit : >> >> >> >>> On Thu, Feb 13, 2014 at 2:09 PM, Benoit Chesneau >> wrote: >> >>>> I also say Erlang/OTP and often I add to the one that ask that OTP is >> >>>> a framework, but then people are more puzzled than they were before. >> >>>> Maybe rust did the right things by clearly separating the language >> >>>> and the runtime from the standard library and other libs ? >> >>> >> >>> I would say that OTP is to Erlang what OOP is to Java. You can write >> >>> Java programs that are not object-oriented, but why choose Java for >> >>> that in the first place? >> >>> >> >>> OTP is in my opinion a design philosophy that guides us when it comes >> >>> to structuring and developing distributed fault-tolerant systems. It >> >>> comes with library support that is intimately tied to the Erlang >> >>> libraries: the most basic Erlang apps (kernel and stdlib) are also the >> >>> ones that implement the OTP concepts. Even more, Erlang code is >> >>> structured as applications, and an "application" is an OTP concept! >> >>> >> >>> I can only see meaning in trying to separate the language from OTP >> >>> either as an academic exercise or in order to implement a different >> >>> language on the beam runtime and the new concepts would collide >> >>> implementation-wise with OTP. Or one wants to create OTP 2.0 without >> >>> interference with 1.0. >> >>> >> >>> 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 >> > > _______________________________________________ > 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 mononcqc@REDACTED Thu Feb 13 19:41:59 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 13 Feb 2014 13:41:59 -0500 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> <20140213180519.GL62889@ferdair.local> Message-ID: <20140213184158.GM62889@ferdair.local> Again, I'd be happy to see that changing the name has a positive effect. For business, the biggest argument, I believe is indeed hiring before the name. There are not that many Erlang devs -- even your employer, EA, used to have an Erlang team, and as far as I know and heard from rumors, they shut down the team after having hiring problems, but this is third-hand information. Businesses that are willing to allow remote workers have more of a chance, but to be able to hire Erlang devs locally is quite a challenge. Nevermind finding an ops team ready to support the language and its platform. Back when I started Erlang, I thought the problem was accessibility, so I set up to work on LYSE. It probably helped a bit, but didn't solve all of it, far from it. Before then, the problem was having any book at all, conferences, a place for the community, etc. These have all been added. Then it was about how open (or little so) Erlang was, and it moved to github and then started accepting pull requests. That brought some speed to the language still, but hey, no popularity problem solved. We organized Spawnfests (coding contests) two years in a row to try and help until our team of volunteers ran out of time. That was okay, but not the whole thing. At some point the issue was needing a killer app. Eventually Erlang got to power facebook chat, EA's WorldPoker tournament software, CouchDB (which was even shipped with all Ubuntu CDs for a while, and on the BlackBerry SDK), Ubuntu One, Riak, Amazon software (SimpleDB), Heroku's router, videogame chat systems in at least 3 companies, Telecom systems for phone calls and SMS, real-time bidding stacks for advertisers (there's easily a dozen of them doing it), DNS servers, Whatsapp servers, and it's used for internal projects at Apple, and Klarna is a European bank that runs Erlang at its core, and Goldman Sachs has had long trials after some of the Erlang code they ran had left the company in the hands of employees. Turns out that even though all these corporations and apps have Erlang inside, that doesn't boost up adoption majorly either. There have also been talk about IDEs (which were never good enough), build tools (which were never good enough), more accessible documentation and other things (which were also never good enough, I guess). My point ultimately is that yes, the OTP name isn't really great. And it would probably help a few newcomers to have something that doesn't mention 'Telecom'. I definitely agree there. I don't think it's what limited the adoption in big corporations. It actually entered a crapload of big corporation and keeps getting in more of them. For the parts of these companies it's ingrained in, it's actually very hard to get rid of it because it does a good job and is cheap to operate. The problem has been in growing the usage within the confines of these corporations past the skunkworks. Erlang has been used in skunkworks projects or extremely domain-specific projects for a long, long time, but hasn't readily made it out of there. While it would help, I somehow just don't think the 'T' in 'OTP' is all that significant when it comes to management and staffing. I think what you're likely to hear is really "But we don't have developers using Erlang. Who is going to work on that? Can't we just use instead? That would be much simpler", nevermind the operations teams not always willing to go and deal with Erlang deploys, whether they are live or not. I encourage and wish the best of luck to the people who'll do the work in renaming OTP whenever that happens. I'll update LYSE's website accordingly if it gets in and hope for the best, but I won't hold my breath. Any progress is good progress, however, and I welcome it. Regards, Fred. On 02/13, kraythe . wrote: > I have read portions of your book and appreciate your insight. However, I > think you underestimate the task here. Convincing developers may be > difficult, but if they are good devs they might come around. Convincing > management with control over budget and staffing when the naming is wrong? > Nearly impossible. Thats why massive advertising companies have made > billions off of just naming things correctly. All of the other concerns you > posted are very legit and I have had and still do have many of them myself. > But those concerns are at the tech level and only of minor interest to the > manager wondering why would he staff for erlang and not scala or ruby? > > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* > *Author of: Hardcore Java (2003) and Maintainable Java (2012)* > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 > * > > > On Thu, Feb 13, 2014 at 12:05 PM, Fred Hebert wrote: > > > Answers inline. > > > > On 02/13, kraythe . wrote: > > > I Guess my answers would be: > > > 0) If there is a business case, you can convince them. Low adoption hurts > > > their maintainability and staffing much more than it does for the startup > > > or small company. They are a business, not a bunch of unreasonable oafs. > > > > That may be doable. I'm not saying the opposite. > > > > > 1) Why rewrite the libs if you use the same initials. I wouldn't worry > > > about that. The programming world is replete with examples of such > > things. > > > > If we can use the same initials, then that's gained and removes a bunch > > of issues. > > > > > 2) and updating the docs will take ... 10 man hours? Do we not have > > search > > > and replace capable tools? > > > 3) Same answer as 2. > > > > Yes, but we do not have administration rights to mirrors, say > > http://erldocs.com/ and translations that can be hosted by the > > community. > > > > The work done with the OTP documentation goes further than the OTP team > > itself. > > > > > 4) Dont need to "make sure" of anything. If the books want to be accurate > > > they will use the new name, if not "shrug" thats their problem. Trust me > > > someone on amazon will post "Its not called Open Telecom Platform since > > > 2014, it stands for "Open Technology Platform". There are enough > > pedantic, > > > basement living, people on the internet that will annoy authors into > > > submission. > > > > That doesn't sound like a pleasant experience for everyone. Again, it's > > not an insurmountable challenge. It's just one more challenge. > > > > > 5) Small matter of documentation. "It used to be called X but was renamed > > > to Y in 2014" > > > > Documentation lives on way longer than expected. People still read and > > order reprints of the Erlang book published in 1994 (and 1996 for the > > second edition), some of which are translations. > > > > Many older versions of books are what is in libraries and whatnot, since > > Joe's first version in early 2000s. For people using these versions, you > > end up with inaccurate terminology regarding half the name of the > > language. > > > > It's a matter of documentation, but it's a matter of trying to do it > > right to reduce the amount of confusion. If people look for "Open > > Telecom Platform Erlang" it would be sweet to get the new documentation > > and content. > > > > Maybe it's easy, but it's still part of a roadmap. > > > > Alternatively, would 'Open Telecom Platform, a framework that is not > > just about telecoms' going to be more cumbersome in documentation? > > > > > 6) History is history. Those investigating the language will get it. It > > > startedo ut being a telecoms thing and migrated to a general language. No > > > problem. Live web sites can easily add in blurbs. Old articles will be > > out > > > of date but not from the time frame of when they were written. No big > > deal. > > > The sky isnt actually falling. > > > > I could see that being made as a decision, yes. > > > > > 7) Obviously this one is just frothing. The man could update the next > > > version of his book with more information, cool tricks, whatever and sell > > > it as a second edition. > > > > Yes. I like to insert a bit of non-serious content here and there. > > > > > 8) What "traditional SDK" are you referring to? The LISP standard lib? > > ;-) > > > Java? C? Ruby? Haskell? Which one is the "normal" one? Normal is defined > > in > > > the context of the language, not in the context of another language? In > > > fact the vast majority of SDKs for java are third party to the JDK itself > > > anyway. > > > > I went from this thread's usage of SDK as a similar point to OTP. > > Erlang/SDK if you will. If you want to keep it as Erlang/OTP, that can > > work, but needs to be significantly better than what it is right now to > > have an actually measurable impact. > > > > Otherwise, we're throwing stuff at the wall to see what sticks, with no > > proof that it actually helped anything. > > > > > 9) Trying to crystal ball the future will only give you a headache. The > > key > > > is to move from where yo are to a point where progress has been made and > > > recursively loop on that algorithm, not be paralyzed by "what if .... ?" > > > > > > > Non-serious content here also. Not to be taken seriously, but I wouldn't > > be surprised if it were to happen. > > > > > You may have been doing Erlang for ages and feel quite the man but the > > > question really boils down to "what would you like for the future of > > Erlang > > > to be?" If the answer to that in your mind is "A niche language that I > > can > > > call myself a guru at and everyone looks at me quizzically and puts up > > with > > > my eccentricity or dare say arrogance." then the current name and trend > > is > > > fine. If the answer is, "A powerful general purpose programming language > > > for developing applications using functional paradigms and widely > > accepted > > > as being the solution to the next generation of software problems." Then > > > marketing is important. > > > > Oh I love that one. I want Erlang to be adopted so much I wrote an > > entire book about it and put it online for free, without advertisement. > > This has taken over 3 years of my spare time, because I wanted Erlang to > > be more accessible. I invite you to visit it at > > http://learnyousomeerlang.com, and maybe buy an ebook or print copy if > > you feel like it would be nicer to read that way. If you prefer a free > > electronic copies, there are scripts on github to convert it to the > > kindle format, and a wget line in the FAQ to download a local copy. > > > > I also kept writing multiple blog posts at http://ferd.ca that guide and > > show more tutorials about Erlang, use cases, and tries to sell it as a > > language as a whole. > > > > The reason I'm answering to your suggestion negatively isn't that I > > don't want Erlang to succeed, it's that I do not believe that changing > > the meaning of 'OTP' from 'Open Telecom Platform' to 'Open Technology > > Platform' will have a noticeable impact. > > > > Some people do ask the question 'but I don't want to do telecoms', but > > in my experience, people's issues are the following, to a much higher > > degree: > > > > - The syntax is unfamiliar (or ugly) > > - It's difficult to work with single assignment, recursion, immutable > > algorithms (most of your algorithm books that rely on arrays with O(1) > > access to work fine are no longer going to be trivial to translate! > > That's huge!) > > - The tooling (rebar, relx, etc.) isn't up to par with other languages, > > even if it keeps getting better. > > - Lack of IDEs (that was your prime concern when you joined these lists) > > - Fighting the idea that "it will be hard to hire Erlang developers" to > > make it enter and stay in the enterprise. > > > > All of those criticism, in the years I've been in the Erlang community, > > have come up time and time again. They've also have come up orders of > > magnitude more often than OTP as a name, even if it does come up from > > time to time. > > > > I'm sorry I came up as harsh. I do want better adoption for Erlang and > > took months if not years of my free time working that way. I do not > > think renaming OTP is worth the effort, but I'll be glad to be proven > > wrong through bigger adoption if someone steps up and decides to do it. > > > > Now if you please, I'll go back to spending my lunch time working on an > > post-scripted chapter to the LYSE site introducing maps to people. > > > > Regards, > > Fred. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From mark.nijhof@REDACTED Thu Feb 13 19:42:16 2014 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Thu, 13 Feb 2014 19:42:16 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <28AAEE0D-905F-4681-B388-7C883CCBA7D3@gmail.com> <796EBF0D-8EE3-446F-AEB0-DEF64701311F@jkemp.net> <52FD0D48.9010802@jkemp.net> Message-ID: huh what, I was too busy writing Erlang/OTP code :P On Thu, Feb 13, 2014 at 7:37 PM, Sergej Jurecko wrote: > So... > does anyone else miss the good old days of the erlang-questions mailing > list? When it did not generate 100 emails a day with endless discussions > about issues that are obviously never going to change? > > > > Sergej > > On Feb 13, 2014, at 7:28 PM, kraythe . wrote: > > Why not learn instead of sell? > > > Because the bank wont take "I learned Erlang this month" in lie of my car > payment or mortgage. Because innovations are rarely created for the > purposes of "learn, not sell." Erlang itself was created to Sell, be under > no misunderstanding. If Ericson couldn't make a case to the "sellers" then > the language wouldn't have powered their switch. Because capitalism and > libertarianism work and communism and socialism eventually run out of other > people's money. And because I don't want to be someone living on someone > else's dime. I like to create, innovate, invent and get paid for it. That > lets me provide a better life for my family. > > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* > *Author of: Hardcore Java (2003) and Maintainable Java (2012)* > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 > * > > > On Thu, Feb 13, 2014 at 12:22 PM, John Kemp wrote: > >> On 02/13/2014 11:44 AM, kraythe . wrote: >> >>> Cant agree with you John. >>> >> >> That's fine :) >> >> >> In an organization you cant simply do what you >>> want and shrug. >>> If I tried that in any of the big organizations i have >>> been involved with my optimal case is being fired. >>> >> >> If I need to "convince" someone about the tech I want to use then I >> either wouldn't use that tech and would use what they wanted instead, or I >> would quit. >> >> It's absolutely the case that if you are driven by "social context" (by >> that I mean, roughly, "other people's concerns") alone, you won't choose >> Erlang. >> >> Although I would often choose Erlang for myself, I would often choose >> another language if I had a programmer of that language to work with, and a >> tight deadline. >> >> In my opinion, professional software developers should choose the best >> tool for the job -- and the job often includes more than the problem at >> hand, true. I like to make satisfied customers. >> >> >> Perhaps if you own >>> the company you can. But then that relegates Erlang to niche. Makes the >>> old timers feel pretty superior >>> >> >> As I've said, you can *choose* whatever language you like, and barring >> the edge cases, you'll be able to build a workable, relatively scalable >> solution. >> >> >> but is a horrible waste of what appears >>> to me to be a very useful language. Also if you go that tact there is no >>> more point of arguing Erlang vs Scala or vs any language anymore. Erlang >>> will become like Smalltalk. Useful and cool for the old timers but >>> virtually IRRELEVANT in the IT industry. >>> >> >> Erlang makes efficient use of computing resources, specifically in >> distributed environments. It does several other clever things. It's also >> hard to learn (for some programmers) and doesn't come with a ready "market" >> of/for proficient software developers. But those who learn it tend to >> understand the problems which Erlang is good at solving. And they >> understand why the language choices made in Erlang might be made, in which >> case, they will often understand other languages better than average >> devlopers too. >> >> >> >>> Furthermore, if you argue you don't care about adoption then the >>> discussion is moot with you. What >>> >> >> I will continue to explain what I have observed about the advantages of >> Erlang to those who will listen :) >> >> >> it will mean is whomever is on your >>> development staff writing Erlang you better be open to paying them >>> whatever they want and letting them get away with about anything because >>> replacing them would be nearly impossible. >>> >> >> Unfortunately, I usually work with people who are not in position to >> understand why one might use Erlang. >> >> Imagine that you have been initiated into a secret group of people who >> will help give you an advantage in your software projects that so few have. >> How could you use those skills? >> >> >> Often many tech people cant >>> see past "oooh list comprehensions !!!!!!" to the actual business behind >>> it and without the business none of us get paid. That is not something >>> you can take to management and sell. >>> >> >> Why not learn instead of sell? >> >> - johnk >> >>> >>> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* >>> /Author of: Hardcore Java (2003) and Maintainable Java (2012)/ >>> /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/ >>> >>> >>> >>> On Thu, Feb 13, 2014 at 10:33 AM, John Kemp >> > wrote: >>> >>> On Feb 13, 2014, at 11:20 AM, kraythe . >> > wrote: >>> >>> /Java as a language is big and complex, because it has a >>>> lot of concepts directly inside the language./ >>>> >>>> >>>> Ahh but here you are wrong. Java itself is analogous to Erlang >>>> without OTP. you don't HAVE to use the JDK libraries beyond >>>> java.lang. You would be a bit crazy reproducing the wheel if you >>>> did so but it is not a requirement of writing java. In fact many >>>> Java controlled micro devices only allow a very small subset of >>>> the JDK to be used. So there is essentially no difference. >>>> >>>> So Elang is to Java as the Java Development Kit is to the Open >>>> Telecom Platform. And there is where we have the "marketing" >>>> disconnect. Its not about changing functionality or a triviality >>>> to be scoffed over. If we start with the premise that we want more >>>> developers to learn and use Erlang then we have to consider how >>>> the language and its nomenclature comes across to our audience. >>>> You don't name a language the Scalable High Integration Technology >>>> because the impression it leaves with adopters is ... unfortunate. >>>> >>> >>> Why start with that premise instead of starting with the premise >>> that developers should try to understand what is useful to them? >>> That has nothing to do with marketing, and everything to do with >>> software developers understanding their craft better. >>> >>> >>>> So if you DON'T care about people adopting the language, then the >>>> discussion is academic and simply, as one reply put it, a waste of >>>> time. Of course if you don't care about adoption then you are >>>> wasting your time here because you wont be able to staff a >>>> development crew, replace developers that leave or push the >>>> language into an organization which isn't currently using it. >>>> >>> >>> Who is "you" in this case? Does the "Erlang community" want to get >>> the language adopted more? Perhaps. Why would that matter to the >>> Erlang community - how do they benefit? Why should those who already >>> know and benefit from Erlang not simply continue to do so? >>> >>> >>>> If you DO care about people adopting the language you have to >>>> consider its marketing. If I many were to take Erlang to >>>> management and propose it for a product the management would see >>>> "Open Telecom Platform", object that the company isn't a telecom >>>> company and that Erlang is mainly for telecom and that would be >>>> the end of that. In fact, if you really care about adoption you >>>> are better off renaming it "Fred" than leaving it as "Open Telecom >>>> Platform". >>>> >>> >>> People reject languages for all kinds of strange reasons. And it's >>> the case that in many cases you can simply choose "a language you >>> like" and then *make* it work for what you want to do. After all, >>> computers have particular resources available to them, and a >>> language well-adapted to its environment should support adequate >>> performance for most applications. The distinction between threading >>> in Ruby and "event-driven" in Node is largely meaningless, for >>> example. The real questions are things like "how well does your >>> VM/compiler exploit computer hardware resources on the platform >>> you're using". Most developers don't understand this, so they argue >>> about threads vs. processes vs. events without understanding what >>> might actually be the critical differences regarding the performance >>> they say they want. >>> >>> Naming won't fix that. And management will never get that. You need >>> people to understand what they are doing. Or not. After all, you can >>> largely do what you like and apart from at the edges, it will likely >>> work. >>> >>> - johnk >>> >>> >>>> Naming matters and it is also pretty easy to fix. >>>> >>>> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* >>>> /Author of: Hardcore Java (2003) and Maintainable Java (2012)/ >>>> /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/ >>>> >>>> >>>> >>>> On Thu, Feb 13, 2014 at 9:03 AM, Anthony Ramine >>> > wrote: >>>> >>>> That's a *HUGE* difference. Erlang as a language is very >>>> small; OTP is a very complex piece of software, as is BEAM. >>>> The three shouldn't be conflated. >>>> >>>> Java as a language is big and complex, because it has a lot of >>>> concepts directly inside the language. >>>> >>>> -- >>>> Anthony Ramine >>>> >>>> Le 13 f?vr. 2014 ? 15:59, Vlad Dumitrescu >>> > a ?crit : >>>> >>>> >>>> > On Thu, Feb 13, 2014 at 3:46 PM, Anthony Ramine >>>> > wrote: >>>> >> Java without OOP is a different language. >>>> >> Erlang without OTP is still Erlang. >>>> > >>>> > IMHO the only difference is that OTP is implemented as a >>>> library and >>>> > doesn't have dedicated language syntax. I make difference >>>> between OTP >>>> > as design/system building guidelines and its implementation. >>>> The >>>> > former is more like OOP for Java. The latter is more like >>>> the JDK. >>>> > >>>> > /Vlad >>>> > >>>> >> -- >>>> >> Anthony Ramine >>>> >> >>>> >> Le 13 f?vr. 2014 ? 15:21, Vlad Dumitrescu >>>> > a ?crit : >>>> >>>> >> >>>> >>> On Thu, Feb 13, 2014 at 2:09 PM, Benoit Chesneau >>>> > wrote: >>>> >>>> I also say Erlang/OTP and often I add to the one that ask >>>> that OTP is >>>> >>>> a framework, but then people are more puzzled than they >>>> were before. >>>> >>>> Maybe rust did the right things by clearly separating >>>> the language >>>> >>>> and the runtime from the standard library and other libs ? >>>> >>> >>>> >>> I would say that OTP is to Erlang what OOP is to Java. You >>>> can write >>>> >>> Java programs that are not object-oriented, but why choose >>>> Java for >>>> >>> that in the first place? >>>> >>> >>>> >>> OTP is in my opinion a design philosophy that guides us >>>> when it comes >>>> >>> to structuring and developing distributed fault-tolerant >>>> systems. It >>>> >>> comes with library support that is intimately tied to the >>>> Erlang >>>> >>> libraries: the most basic Erlang apps (kernel and stdlib) >>>> are also the >>>> >>> ones that implement the OTP concepts. Even more, Erlang >>>> code is >>>> >>> structured as applications, and an "application" is an OTP >>>> concept! >>>> >>> >>>> >>> I can only see meaning in trying to separate the language >>>> from OTP >>>> >>> either as an academic exercise or in order to implement a >>>> different >>>> >>> language on the beam runtime and the new concepts would >>>> collide >>>> >>> implementation-wise with OTP. Or one wants to create OTP >>>> 2.0 without >>>> >>> interference with 1.0. >>>> >>> >>>> >>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 > > -- Mark Nijhof t: @MarkNijhof s: marknijhof -------------- next part -------------- An HTML attachment was scrubbed... URL: From tristan.sloughter@REDACTED Thu Feb 13 19:44:15 2014 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Thu, 13 Feb 2014 10:44:15 -0800 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <28AAEE0D-905F-4681-B388-7C883CCBA7D3@gmail.com> <796EBF0D-8EE3-446F-AEB0-DEF64701311F@jkemp.net> <52FD0D48.9010802@jkemp.net> Message-ID: <1392317055.13870.83089537.30BBF418@webmail.messagingengine.com> Because capitalism and libertarianism work and communism and socialism eventually run out of other people's money. And because I don't want to be someone living on someone else's dime. *Throw hands in the air* I'm done! -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Thu Feb 13 19:46:18 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Thu, 13 Feb 2014 13:46:18 -0500 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <28AAEE0D-905F-4681-B388-7C883CCBA7D3@gmail.com> <796EBF0D-8EE3-446F-AEB0-DEF64701311F@jkemp.net> <52FD0D48.9010802@jkemp.net> Message-ID: Your trolling game is quickly falling apart. Anybody know how to mute a single thread on this list? --steve On Thu, Feb 13, 2014 at 1:28 PM, kraythe . wrote: > Why not learn instead of sell? > > > Because the bank wont take "I learned Erlang this month" in lie of my car > payment or mortgage. Because innovations are rarely created for the > purposes of "learn, not sell." Erlang itself was created to Sell, be under > no misunderstanding. If Ericson couldn't make a case to the "sellers" then > the language wouldn't have powered their switch. Because capitalism and > libertarianism work and communism and socialism eventually run out of other > people's money. And because I don't want to be someone living on someone > else's dime. I like to create, innovate, invent and get paid for it. That > lets me provide a better life for my family. > > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* > *Author of: Hardcore Java (2003) and Maintainable Java (2012)* > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 > * > > > On Thu, Feb 13, 2014 at 12:22 PM, John Kemp wrote: > >> On 02/13/2014 11:44 AM, kraythe . wrote: >> >>> Cant agree with you John. >>> >> >> That's fine :) >> >> >> In an organization you cant simply do what you >>> want and shrug. >>> If I tried that in any of the big organizations i have >>> been involved with my optimal case is being fired. >>> >> >> If I need to "convince" someone about the tech I want to use then I >> either wouldn't use that tech and would use what they wanted instead, or I >> would quit. >> >> It's absolutely the case that if you are driven by "social context" (by >> that I mean, roughly, "other people's concerns") alone, you won't choose >> Erlang. >> >> Although I would often choose Erlang for myself, I would often choose >> another language if I had a programmer of that language to work with, and a >> tight deadline. >> >> In my opinion, professional software developers should choose the best >> tool for the job -- and the job often includes more than the problem at >> hand, true. I like to make satisfied customers. >> >> >> Perhaps if you own >>> the company you can. But then that relegates Erlang to niche. Makes the >>> old timers feel pretty superior >>> >> >> As I've said, you can *choose* whatever language you like, and barring >> the edge cases, you'll be able to build a workable, relatively scalable >> solution. >> >> >> but is a horrible waste of what appears >>> to me to be a very useful language. Also if you go that tact there is no >>> more point of arguing Erlang vs Scala or vs any language anymore. Erlang >>> will become like Smalltalk. Useful and cool for the old timers but >>> virtually IRRELEVANT in the IT industry. >>> >> >> Erlang makes efficient use of computing resources, specifically in >> distributed environments. It does several other clever things. It's also >> hard to learn (for some programmers) and doesn't come with a ready "market" >> of/for proficient software developers. But those who learn it tend to >> understand the problems which Erlang is good at solving. And they >> understand why the language choices made in Erlang might be made, in which >> case, they will often understand other languages better than average >> devlopers too. >> >> >> >>> Furthermore, if you argue you don't care about adoption then the >>> discussion is moot with you. What >>> >> >> I will continue to explain what I have observed about the advantages of >> Erlang to those who will listen :) >> >> >> it will mean is whomever is on your >>> development staff writing Erlang you better be open to paying them >>> whatever they want and letting them get away with about anything because >>> replacing them would be nearly impossible. >>> >> >> Unfortunately, I usually work with people who are not in position to >> understand why one might use Erlang. >> >> Imagine that you have been initiated into a secret group of people who >> will help give you an advantage in your software projects that so few have. >> How could you use those skills? >> >> >> Often many tech people cant >>> see past "oooh list comprehensions !!!!!!" to the actual business behind >>> it and without the business none of us get paid. That is not something >>> you can take to management and sell. >>> >> >> Why not learn instead of sell? >> >> - johnk >> >>> >>> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* >>> /Author of: Hardcore Java (2003) and Maintainable Java (2012)/ >>> /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/ >>> >>> >>> >>> On Thu, Feb 13, 2014 at 10:33 AM, John Kemp >> > wrote: >>> >>> On Feb 13, 2014, at 11:20 AM, kraythe . >> > wrote: >>> >>> /Java as a language is big and complex, because it has a >>>> lot of concepts directly inside the language./ >>>> >>>> >>>> Ahh but here you are wrong. Java itself is analogous to Erlang >>>> without OTP. you don't HAVE to use the JDK libraries beyond >>>> java.lang. You would be a bit crazy reproducing the wheel if you >>>> did so but it is not a requirement of writing java. In fact many >>>> Java controlled micro devices only allow a very small subset of >>>> the JDK to be used. So there is essentially no difference. >>>> >>>> So Elang is to Java as the Java Development Kit is to the Open >>>> Telecom Platform. And there is where we have the "marketing" >>>> disconnect. Its not about changing functionality or a triviality >>>> to be scoffed over. If we start with the premise that we want more >>>> developers to learn and use Erlang then we have to consider how >>>> the language and its nomenclature comes across to our audience. >>>> You don't name a language the Scalable High Integration Technology >>>> because the impression it leaves with adopters is ... unfortunate. >>>> >>> >>> Why start with that premise instead of starting with the premise >>> that developers should try to understand what is useful to them? >>> That has nothing to do with marketing, and everything to do with >>> software developers understanding their craft better. >>> >>> >>>> So if you DON'T care about people adopting the language, then the >>>> discussion is academic and simply, as one reply put it, a waste of >>>> time. Of course if you don't care about adoption then you are >>>> wasting your time here because you wont be able to staff a >>>> development crew, replace developers that leave or push the >>>> language into an organization which isn't currently using it. >>>> >>> >>> Who is "you" in this case? Does the "Erlang community" want to get >>> the language adopted more? Perhaps. Why would that matter to the >>> Erlang community - how do they benefit? Why should those who already >>> know and benefit from Erlang not simply continue to do so? >>> >>> >>>> If you DO care about people adopting the language you have to >>>> consider its marketing. If I many were to take Erlang to >>>> management and propose it for a product the management would see >>>> "Open Telecom Platform", object that the company isn't a telecom >>>> company and that Erlang is mainly for telecom and that would be >>>> the end of that. In fact, if you really care about adoption you >>>> are better off renaming it "Fred" than leaving it as "Open Telecom >>>> Platform". >>>> >>> >>> People reject languages for all kinds of strange reasons. And it's >>> the case that in many cases you can simply choose "a language you >>> like" and then *make* it work for what you want to do. After all, >>> computers have particular resources available to them, and a >>> language well-adapted to its environment should support adequate >>> performance for most applications. The distinction between threading >>> in Ruby and "event-driven" in Node is largely meaningless, for >>> example. The real questions are things like "how well does your >>> VM/compiler exploit computer hardware resources on the platform >>> you're using". Most developers don't understand this, so they argue >>> about threads vs. processes vs. events without understanding what >>> might actually be the critical differences regarding the performance >>> they say they want. >>> >>> Naming won't fix that. And management will never get that. You need >>> people to understand what they are doing. Or not. After all, you can >>> largely do what you like and apart from at the edges, it will likely >>> work. >>> >>> - johnk >>> >>> >>>> Naming matters and it is also pretty easy to fix. >>>> >>>> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* >>>> /Author of: Hardcore Java (2003) and Maintainable Java (2012)/ >>>> /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/ >>>> >>>> >>>> >>>> On Thu, Feb 13, 2014 at 9:03 AM, Anthony Ramine >>> > wrote: >>>> >>>> That's a *HUGE* difference. Erlang as a language is very >>>> small; OTP is a very complex piece of software, as is BEAM. >>>> The three shouldn't be conflated. >>>> >>>> Java as a language is big and complex, because it has a lot of >>>> concepts directly inside the language. >>>> >>>> -- >>>> Anthony Ramine >>>> >>>> Le 13 f?vr. 2014 ? 15:59, Vlad Dumitrescu >>> > a ?crit : >>>> >>>> >>>> > On Thu, Feb 13, 2014 at 3:46 PM, Anthony Ramine >>>> > wrote: >>>> >> Java without OOP is a different language. >>>> >> Erlang without OTP is still Erlang. >>>> > >>>> > IMHO the only difference is that OTP is implemented as a >>>> library and >>>> > doesn't have dedicated language syntax. I make difference >>>> between OTP >>>> > as design/system building guidelines and its implementation. >>>> The >>>> > former is more like OOP for Java. The latter is more like >>>> the JDK. >>>> > >>>> > /Vlad >>>> > >>>> >> -- >>>> >> Anthony Ramine >>>> >> >>>> >> Le 13 f?vr. 2014 ? 15:21, Vlad Dumitrescu >>>> > a ?crit : >>>> >>>> >> >>>> >>> On Thu, Feb 13, 2014 at 2:09 PM, Benoit Chesneau >>>> > wrote: >>>> >>>> I also say Erlang/OTP and often I add to the one that ask >>>> that OTP is >>>> >>>> a framework, but then people are more puzzled than they >>>> were before. >>>> >>>> Maybe rust did the right things by clearly separating >>>> the language >>>> >>>> and the runtime from the standard library and other libs ? >>>> >>> >>>> >>> I would say that OTP is to Erlang what OOP is to Java. You >>>> can write >>>> >>> Java programs that are not object-oriented, but why choose >>>> Java for >>>> >>> that in the first place? >>>> >>> >>>> >>> OTP is in my opinion a design philosophy that guides us >>>> when it comes >>>> >>> to structuring and developing distributed fault-tolerant >>>> systems. It >>>> >>> comes with library support that is intimately tied to the >>>> Erlang >>>> >>> libraries: the most basic Erlang apps (kernel and stdlib) >>>> are also the >>>> >>> ones that implement the OTP concepts. Even more, Erlang >>>> code is >>>> >>> structured as applications, and an "application" is an OTP >>>> concept! >>>> >>> >>>> >>> I can only see meaning in trying to separate the language >>>> from OTP >>>> >>> either as an academic exercise or in order to implement a >>>> different >>>> >>> language on the beam runtime and the new concepts would >>>> collide >>>> >>> implementation-wise with OTP. Or one wants to create OTP >>>> 2.0 without >>>> >>> interference with 1.0. >>>> >>> >>>> >>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 mark.nijhof@REDACTED Thu Feb 13 19:49:19 2014 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Thu, 13 Feb 2014 19:49:19 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <1392317055.13870.83089537.30BBF418@webmail.messagingengine.com> References: <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <28AAEE0D-905F-4681-B388-7C883CCBA7D3@gmail.com> <796EBF0D-8EE3-446F-AEB0-DEF64701311F@jkemp.net> <52FD0D48.9010802@jkemp.net> <1392317055.13870.83089537.30BBF418@webmail.messagingengine.com> Message-ID: I am a new comer to Erlang, I have worked with software only about 13 years professionally. I have never thought that the OTP name was weird, instead I learned where it came from. Infect I'll be leaning on the "telecom" part for this: https://leanpub.com/functionalerlang There is nothing wrong with showing where you come from, that helps understand certain tradeoffs made in the language and libraries. If this is something that stops people from looking further then I think you don't want those people anyway, because they will be bombarding the user group with questions that should be a Google/DuckDuckGo away. My 2 cents, -Mark On Thu, Feb 13, 2014 at 7:44 PM, Tristan Sloughter < tristan.sloughter@REDACTED> wrote: > > > Because capitalism and libertarianism work and communism and socialism > eventually run out of other people's money. And because I don't want to be > someone living on someone else's dime. > > > *Throw hands in the air* > > I'm done! > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Mark Nijhof t: @MarkNijhof s: marknijhof -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Thu Feb 13 19:54:26 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Thu, 13 Feb 2014 13:54:26 -0500 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> <52FD0B24.50400@meetinghouse.net> <52FD0C14.6060004@meetinghouse.net> Message-ID: <52FD14E2.7040705@meetinghouse.net> kraythe . wrote: > Ahh well. I have had my say and stated my opinions more than once. So > I can leave it there. It is, however, definitely food for thought > about the direction I wish to go with my project. Not so much the > issue of OTP as a name but the general impression of "adoption? bah > humbug ... if they don't like it they all suck and we don't care." > Sounds like a disaster of a business decision to me. > > Im not so sure its going to be easy to staff or finance a project on a > language that has 1) tools that need work, 2) a limited trained staff > 3) a community that cares little about language adoption. It could be > that Erlang becomes another Lisp for me. A language I think rocks but > is entirely impractical in the business world. > > > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* > /Author of: Hardcore Java (2003) and Maintainable Java (2012)/ > /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/ > This may be a silly observation, but... Is a man who bills himself as "Lead Java Architect" and an author of Java books, ever really going to be convinced to adopt another Erlang/OTP - whatever it's called, and however it's marketed? -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From moxford@REDACTED Thu Feb 13 19:54:47 2014 From: moxford@REDACTED (Mike Oxford) Date: Thu, 13 Feb 2014 10:54:47 -0800 Subject: [erlang-questions] release upgrades and code loading In-Reply-To: <52FD0826.2080305@llaisdy.com> References: <52FD0826.2080305@llaisdy.com> Message-ID: Is your brutal_purge on the PostPurge or the PrePurge? On Thu, Feb 13, 2014 at 10:00 AM, Ivan Uemlianin wrote: > Dear All > > I am just getting started with live release upgrades, using relx and > following this tutorial: > > http://blog.troutwine.us/2013/09/13/trivial_otp_releases.html > > Everything seems to work as advertised, except sometimes I need to > explicitly load the code into the running vm (i.e., using code_load_file/1) > for the new stuff to take effect. The function release_handler:which_releases/0 > reports the new release as active and permanent, but I can see from > behaviour that old versions of certain modules are still running and > handling data. > > I can't be much more specific I'm afraid. One example: one application > uses cowboy. If a release upgrade changes a cowboy resource module, the > new release version might still be running the old version of that module > until I load_file and purge. > > Why might this be happening? Am I missing something in the packaging and > upgrade process? Is there a better way I can write my modules? > > If the information above is too vague, what should I look out for next > time this happens? > > With thanks and best wishes > > Ivan > > > -- > ============================================================ > Ivan A. Uemlianin PhD > Llaisdy > Speech Technology Research and Development > > ivan@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > github.com/llaisdy > www.linkedin.com/in/ivanuemlianin > > festina lente > ============================================================ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Thu Feb 13 19:54:56 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Thu, 13 Feb 2014 10:54:56 -0800 (PST) Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> <20140213180519.GL62889@ferdair.local> Message-ID: <1392317696.43751.YahooMailNeo@web140106.mail.bf1.yahoo.com> OK, if the acronym drives your managers nuts, fork it, rename it (how about "Blue Gorilla", "Customer Yacht" or "Uhuru Scalable Mountain") and write in the docs that it's based on OTP?(tip: below the fold). I'm sure Erlang Solutions can sell your company Blue Gorilla training and contractors if you ask them.? Best, Thomas On Thursday, February 13, 2014 7:16 PM, kraythe . wrote: I have read portions of your book and appreciate your insight. However, I think you underestimate the task here. Convincing developers may be difficult, but if they are good devs they might come around. Convincing management with control over budget and staffing when the naming is wrong? Nearly impossible. Thats why massive advertising companies have made billions off of just naming things correctly. All of the other concerns you posted are very legit and I have had and still do have many of them myself. But those concerns are at the tech level and only of minor interest to the manager wondering why would he staff for erlang and not scala or ruby?? > > >Robert Simmons Jr. MSc. - Lead Java Architect @ EA >Author of: Hardcore Java (2003) and Maintainable Java (2012) >LinkedIn:?http://www.linkedin.com/pub/robert-simmons/40/852/a39 > > >On Thu, Feb 13, 2014 at 12:05 PM, Fred Hebert wrote: > >Answers inline. >> >> >>On 02/13, kraythe . wrote: >>> I Guess my answers would be: >>> 0) If there is a business case, you can convince them. Low adoption hurts >>> their maintainability and staffing much more than it does for the startup >>> or small company. They are a business, not a bunch of unreasonable oafs. >> >>That may be doable. I'm not saying the opposite. >> >> >>> 1) Why rewrite the libs if you use the same initials. I wouldn't worry >>> about that. The programming world is replete with examples of such things. >> >>If we can use the same initials, then that's gained and removes a bunch >>of issues. >> >> >>> 2) and updating the docs will take ... 10 man hours? Do we not have search >>> and replace capable tools? >>> 3) Same answer as 2. >> >>Yes, but we do not have administration rights to mirrors, say >>http://erldocs.com/ and translations that can be hosted by the >>community. >> >>The work done with the OTP documentation goes further than the OTP team >>itself. >> >> >>> 4) Dont need to "make sure" of anything. If the books want to be accurate >>> they will use the new name, if not "shrug" thats their problem. Trust me >>> someone on amazon will post "Its not called Open Telecom Platform since >>> 2014, it stands for "Open Technology Platform". There are enough pedantic, >>> basement living, people on the internet that will annoy authors into >>> submission. >> >>That doesn't sound like a pleasant experience for everyone. Again, it's >>not an insurmountable challenge. It's just one more challenge. >> >> >>> 5) Small matter of documentation. "It used to be called X but was renamed >>> to Y in 2014" >> >>Documentation lives on way longer than expected. People still read and >>order reprints of the Erlang book published in 1994 (and 1996 for the >>second edition), some of which are translations. >> >>Many older versions of books are what is in libraries and whatnot, since >>Joe's first version in early 2000s. For people using these versions, you >>end up with inaccurate terminology regarding half the name of the >>language. >> >>It's a matter of documentation, but it's a matter of trying to do it >>right to reduce the amount of confusion. If people look for "Open >>Telecom Platform Erlang" it would be sweet to get the new documentation >>and content. >> >>Maybe it's easy, but it's still part of a roadmap. >> >>Alternatively, would 'Open Telecom Platform, a framework that is not >>just about telecoms' going to be more cumbersome in documentation? >> >> >>> 6) History is history. Those investigating the language will get it. It >>> startedo ut being a telecoms thing and migrated to a general language. No >>> problem. Live web sites can easily add in blurbs. Old articles will be out >>> of date but not from the time frame of when they were written. No big deal. >>> The sky isnt actually falling. >> >>I could see that being made as a decision, yes. >> >> >>> 7) Obviously this one is just frothing. The man could update the next >>> version of his book with more information, cool tricks, whatever and sell >>> it as a second edition. >> >>Yes. I like to insert a bit of non-serious content here and there. >> >> >>> 8) What "traditional SDK" are you referring to? The LISP standard lib? ;-) >>> Java? C? Ruby? Haskell? Which one is the "normal" one? Normal is defined in >>> the context of the language, not in the context of another language? In >>> fact the vast majority of SDKs for java are third party to the JDK itself >>> anyway. >> >>I went from this thread's usage of SDK as a similar point to OTP. >>Erlang/SDK if you will. If you want to keep it as Erlang/OTP, that can >>work, but needs to be significantly better than what it is right now to >>have an actually measurable impact. >> >>Otherwise, we're throwing stuff at the wall to see what sticks, with no >>proof that it actually helped anything. >> >> >>> 9) Trying to crystal ball the future will only give you a headache. The key >>> is to move from where yo are to a point where progress has been made and >>> recursively loop on that algorithm, not be paralyzed by "what if .... ?" >>> >> >>Non-serious content here also. Not to be taken seriously, but I wouldn't >>be surprised if it were to happen. >> >> >>> You may have been doing Erlang for ages and feel quite the man but the >>> question really boils down to "what would you like for the future of Erlang >>> to be?" If the answer to that in your mind is "A niche language that I can >>> call myself a guru at and everyone looks at me quizzically and puts up with >>> my eccentricity or dare say arrogance." then the current name and trend is >>> fine. If the answer is, "A powerful general purpose programming language >>> for developing applications using functional paradigms and widely accepted >>> as being the solution to the next generation of software problems." Then >>> marketing is important. >> >>Oh I love that one. I want Erlang to be adopted so much I wrote an >>entire book about it and put it online for free, without advertisement. >>This has taken over 3 years of my spare time, because I wanted Erlang to >>be more accessible. I invite you to visit it at >>http://learnyousomeerlang.com, and maybe buy an ebook or print copy if >>you feel like it would be nicer to read that way. If you prefer a free >>electronic copies, there are scripts on github to convert it to the >>kindle format, and a wget line in the FAQ to download a local copy. >> >>I also kept writing multiple blog posts at http://ferd.ca that guide and >>show more tutorials about Erlang, use cases, and tries to sell it as a >>language as a whole. >> >>The reason I'm answering to your suggestion negatively isn't that I >>don't want Erlang to succeed, it's that I do not believe that changing >>the meaning of 'OTP' from 'Open Telecom Platform' to 'Open Technology >>Platform' will have a noticeable impact. >> >>Some people do ask the question 'but I don't want to do telecoms', but >>in my experience, people's issues are the following, to a much higher >>degree: >> >>- The syntax is unfamiliar (or ugly) >>- It's difficult to work with single assignment, recursion, immutable >>? algorithms (most of your algorithm books that rely on arrays with O(1) >>? access to work fine are no longer going to be trivial to translate! >>? That's huge!) >>- The tooling (rebar, relx, etc.) isn't up to par with other languages, >>? even if it keeps getting better. >>- Lack of IDEs (that was your prime concern when you joined these lists) >>- Fighting the idea that "it will be hard to hire Erlang developers" to >>? make it enter and stay in the enterprise. >> >>All of those criticism, in the years I've been in the Erlang community, >>have come up time and time again. They've also have come up orders of >>magnitude more often than OTP as a name, even if it does come up from >>time to time. >> >>I'm sorry I came up as harsh. I do want better adoption for Erlang and >>took months if not years of my free time working that way. I do not >>think renaming OTP is worth the effort, but I'll be glad to be proven >>wrong through bigger adoption if someone steps up and decides to do it. >> >>Now if you please, I'll go back to spending my lunch time working on an >>post-scripted chapter to the LYSE site introducing maps to people. >> >>Regards, >>Fred. >> > > >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahesh@REDACTED Thu Feb 13 19:57:08 2014 From: mahesh@REDACTED (Mahesh Paolini-Subramanya) Date: Thu, 13 Feb 2014 19:57:08 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <28AAEE0D-905F-4681-B388-7C883CCBA7D3@gmail.com> <796EBF0D-8EE3-446F-AEB0-DEF64701311F@jkemp.net> <52FD0D48.9010802@jkemp.net> Message-ID: ?Don?t Feed The Trolls? That is all Me, I?m off for some well-deserved mortadella and lambrusco? Mahesh Paolini-Subramanya That tall bald Indian guy.. Google+? |?Blog?? |?Twitter? |?LinkedIn On February 13, 2014 at 7:46:30 PM, Steve Vinoski (vinoski@REDACTED) wrote: Your trolling game is quickly falling apart. Anybody know how to mute a single thread on this list? --steve On Thu, Feb 13, 2014 at 1:28 PM, kraythe . wrote: Why not learn instead of sell? Because the bank wont take "I learned Erlang this month" in lie of my car payment or mortgage. Because innovations are rarely created for the purposes of "learn, not sell." Erlang itself was created to Sell, be under no misunderstanding. If Ericson couldn't make a case to the "sellers" then the language wouldn't have powered their switch. Because capitalism and libertarianism work and communism and socialism eventually run out of other people's money. And because I don't want to be someone living on someone else's dime. I like to create, innovate, invent and get paid for it. That lets me provide a better life for my family.? Robert Simmons Jr. MSc. - Lead Java Architect @ EA Author of: Hardcore Java (2003) and Maintainable Java (2012) LinkedIn:?http://www.linkedin.com/pub/robert-simmons/40/852/a39 On Thu, Feb 13, 2014 at 12:22 PM, John Kemp wrote: On 02/13/2014 11:44 AM, kraythe . wrote: Cant agree with you John. That's fine :) In an organization you cant simply do what you want and shrug. If I tried that in any of the big organizations i have been involved with my optimal case is being fired. If I need to "convince" someone about the tech I want to use then I either wouldn't use that tech and would use what they wanted instead, or I would quit. It's absolutely the case that if you are driven by "social context" (by that I mean, roughly, "other people's concerns") alone, you won't choose Erlang. Although I would often choose Erlang for myself, I would often choose another language if I had a programmer of that language to work with, and a tight deadline. In my opinion, professional software developers should choose the best tool for the job -- and the job often includes more than the problem at hand, true. I like to make satisfied customers. Perhaps if you own the company you can. But then that relegates Erlang to niche. Makes the old timers feel pretty superior As I've said, you can *choose* whatever language you like, and barring the edge cases, you'll be able to build a workable, relatively scalable solution. but is a horrible waste of what appears to me to be a very useful language. Also if you go that tact there is no more point of arguing Erlang vs Scala or vs any language anymore. Erlang will become like Smalltalk. Useful and cool for the old timers but virtually IRRELEVANT in the IT industry. Erlang makes efficient use of computing resources, specifically in distributed environments. It does several other clever things. It's also hard to learn (for some programmers) and doesn't come with a ready "market" of/for proficient software developers. But those who learn it tend to understand the problems which Erlang is good at solving. And they understand why the language choices made in Erlang might be made, in which case, they will often understand other languages better than average devlopers too. Furthermore, if you argue you don't care about adoption then the discussion is moot with you. What I will continue to explain what I have observed about the advantages of Erlang to those who will listen :) it will mean is whomever is on your development staff writing Erlang you better be open to paying them whatever they want and letting them get away with about anything because replacing them would be nearly impossible. Unfortunately, I usually work with people who are not in position to understand why one might use Erlang. Imagine that you have been initiated into a secret group of people who will help give you an advantage in your software projects that so few have. How could you use those skills? Often many tech people cant see past "oooh list comprehensions !!!!!!" to the actual business behind it and without the business none of us get paid. That is not something you can take to management and sell. Why not learn instead of sell? - johnk *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* /Author of: Hardcore Java (2003) and Maintainable Java (2012)/ /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/ On Thu, Feb 13, 2014 at 10:33 AM, John Kemp > wrote: ? ? On Feb 13, 2014, at 11:20 AM, kraythe . > wrote: ? ? ? ? ? ? /Java as a language is big and complex, because it has a ? ? ? ? ? ? lot of concepts directly inside the language./ ? ? Ahh but here you are wrong. Java itself is analogous to Erlang ? ? without OTP. you don't HAVE to use the JDK libraries beyond ? ? java.lang. You would be a bit crazy reproducing the wheel if you ? ? did so but it is not a requirement of writing java. In fact many ? ? Java controlled micro devices only allow a very small subset of ? ? the JDK to be used. So there is essentially no difference. ? ? So Elang is to Java as the Java Development Kit is to the Open ? ? Telecom Platform. And there is where we have the "marketing" ? ? disconnect. Its not about changing functionality or a triviality ? ? to be scoffed over. If we start with the premise that we want more ? ? developers to learn and use Erlang then we have to consider how ? ? the language and its nomenclature comes across to our audience. ? ? You don't name a language the Scalable High Integration Technology ? ? because the impression it leaves with adopters is ... unfortunate. ? ? Why start with that premise instead of starting with the premise ? ? that developers should try to understand what is useful to them? ? ? That has nothing to do with marketing, and everything to do with ? ? software developers understanding their craft better. ? ? So if you DON'T care about people adopting the language, then the ? ? discussion is academic and simply, as one reply put it, a waste of ? ? time. Of course if you don't care about adoption then you are ? ? wasting your time here because you wont be able to staff a ? ? development crew, replace developers that leave or push the ? ? language into an organization which isn't currently using it. ? ? Who is ?you? in this case? Does the ?Erlang community? want to get ? ? the language adopted more? Perhaps. Why would that matter to the ? ? Erlang community - how do they benefit? Why should those who already ? ? know and benefit from Erlang not simply continue to do so? ? ? If you DO care about people adopting the language you have to ? ? consider its marketing. If I many were to take Erlang to ? ? management and propose it for a product the management would see ? ? "Open Telecom Platform", object that the company isn't a telecom ? ? company and that Erlang is mainly for telecom and that would be ? ? the end of that. ?In fact, if you really care about adoption you ? ? are better off renaming it "Fred" than leaving it as "Open Telecom ? ? Platform?. ? ? People reject languages for all kinds of strange reasons. And it?s ? ? the case that in many cases you can simply choose ?a language you ? ? like? and then *make* it work for what you want to do. After all, ? ? computers have particular resources available to them, and a ? ? language well-adapted to its environment should support adequate ? ? performance for most applications. The distinction between threading ? ? in Ruby and ?event-driven? in Node is largely meaningless, for ? ? example. The real questions are things like ?how well does your ? ? VM/compiler exploit computer hardware resources on the platform ? ? you?re using?. Most developers don?t understand this, so they argue ? ? about threads vs. processes vs. events without understanding what ? ? might actually be the critical differences regarding the performance ? ? they say they want. ? ? Naming won?t fix that. And management will never get that. You need ? ? people to understand what they are doing. Or not. After all, you can ? ? largely do what you like and apart from at the edges, it will likely ? ? work. ? ? - johnk ? ? Naming matters and it is also pretty easy to fix. ? ? *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* ? ? /Author of: Hardcore Java (2003) and Maintainable Java (2012)/ ? ? /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/ ? ? On Thu, Feb 13, 2014 at 9:03 AM, Anthony Ramine > wrote: ? ? ? ? That?s a *HUGE* difference. Erlang as a language is very ? ? ? ? small; OTP is a very complex piece of software, as is BEAM. ? ? ? ? The three shouldn?t be conflated. ? ? ? ? Java as a language is big and complex, because it has a lot of ? ? ? ? concepts directly inside the language. ? ? ? ? -- ? ? ? ? Anthony Ramine ? ? ? ? Le 13 f?vr. 2014 ? 15:59, Vlad Dumitrescu > a ?crit : ? ? ? ? > On Thu, Feb 13, 2014 at 3:46 PM, Anthony Ramine ? ? ? ? > wrote: ? ? ? ? >> Java without OOP is a different language. ? ? ? ? >> Erlang without OTP is still Erlang. ? ? ? ? > ? ? ? ? > IMHO the only difference is that OTP is implemented as a ? ? ? ? library and ? ? ? ? > doesn't have dedicated language syntax. I make difference ? ? ? ? between OTP ? ? ? ? > as design/system building guidelines and its implementation. The ? ? ? ? > former is more like OOP for Java. The latter is more like ? ? ? ? the JDK. ? ? ? ? > ? ? ? ? > /Vlad ? ? ? ? > ? ? ? ? >> -- ? ? ? ? >> Anthony Ramine ? ? ? ? >> ? ? ? ? >> Le 13 f?vr. 2014 ? 15:21, Vlad Dumitrescu ? ? ? ? > a ?crit : ? ? ? ? >> ? ? ? ? >>> On Thu, Feb 13, 2014 at 2:09 PM, Benoit Chesneau ? ? ? ? > wrote: ? ? ? ? >>>> I also say Erlang/OTP and often I add to the one that ask ? ? ? ? that OTP is ? ? ? ? >>>> a framework, but then people are more puzzled than they ? ? ? ? were before. ? ? ? ? >>>> Maybe rust did the right things by ?clearly separating ? ? ? ? the language ? ? ? ? >>>> and the runtime from the standard library and other libs ? ? ? ? ? >>> ? ? ? ? >>> I would say that OTP is to Erlang what OOP is to Java. You ? ? ? ? can write ? ? ? ? >>> Java programs that are not object-oriented, but why choose ? ? ? ? Java for ? ? ? ? >>> that in the first place? ? ? ? ? >>> ? ? ? ? >>> OTP is in my opinion a design philosophy that guides us ? ? ? ? when it comes ? ? ? ? >>> to structuring and developing distributed fault-tolerant ? ? ? ? systems. It ? ? ? ? >>> comes with library support that is intimately tied to the ? ? ? ? Erlang ? ? ? ? >>> libraries: the most basic Erlang apps (kernel and stdlib) ? ? ? ? are also the ? ? ? ? >>> ones that implement the OTP concepts. Even more, Erlang ? ? ? ? code is ? ? ? ? >>> structured as applications, and an "application" is an OTP ? ? ? ? concept! ? ? ? ? >>> ? ? ? ? >>> I can only see meaning in trying to separate the language ? ? ? ? from OTP ? ? ? ? >>> either as an academic exercise or in order to implement a ? ? ? ? different ? ? ? ? >>> language on the beam runtime and the new concepts would ? ? ? ? collide ? ? ? ? >>> implementation-wise with OTP. Or one wants to create OTP ? ? ? ? 2.0 without ? ? ? ? >>> interference with 1.0. ? ? ? ? >>> ? ? ? ? >>> 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 ? ? _______________________________________________ ? ? 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 g@REDACTED Thu Feb 13 20:02:39 2014 From: g@REDACTED (Garrett Smith) Date: Thu, 13 Feb 2014 13:02:39 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> Message-ID: On Thu, Feb 13, 2014 at 12:15 PM, Joe Armstrong wrote: > > On Thu, Feb 13, 2014 at 10:51 AM, Garrett Smith wrote: >> >> Sigh. This *is* confusing. It just is. >> >> Lo?c you *cannot* use Erlang without OTP. The VM starts a system, >> which consists of applications, which are supervisory trees of >> gen_servers. > > This is wrong - you can use Erlang without OTP. > > OTP loads 60 odd modules, starts a code server and some other stuff and > *then* executes your code. > > You can "easily" roll your own system that uses far fewer modules and gets > you up > and running, but then you don't get the shell, the code loader and a load of > other goodies. > > Appendix 3 of the 2'nd edition of Programming Erlang tells you *exactly* how > to do this. > > To summarise Appendix 3 - I load 3 modules in 20ms instead of the 1.1s > Erlang + OTP takes (on the same machine) then you're up and running, not OTP > but a with a code loader and simple I/O system. Book ordered. The prospect of getting off the OTP facility is very appealing. If it's that trivial to get the same features without incurring the cost of those modules, I'm in. I think the needle could move here. Garrett From ivan@REDACTED Thu Feb 13 20:03:24 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Thu, 13 Feb 2014 19:03:24 +0000 Subject: [erlang-questions] release upgrades and code loading In-Reply-To: References: <52FD0826.2080305@llaisdy.com> Message-ID: <52FD16FC.10101@llaisdy.com> Dear Mike Thanks for your help. Here's a recent relup. After this upgrade, I had to manually code_load and purge app1: {"1.0.7", [{"1.0.6",[], [{load_object_code,{app1,"20140213.1",[app1]}}, {load_object_code,{app2,"20140213.1",[app2]}}, point_of_no_return, {suspend,[app1]}, {load,{app1,brutal_purge,brutal_purge}}, {code_change,up,[{app1,[from1to2]}]}, {resume,[app1]}, {suspend,[app2]}, {load,{app2,brutal_purge,brutal_purge}}, {code_change,up,[{app2,[from1to2]}]}, {resume,[app2]}]}], [{"1.0.6",[], [{load_object_code,{app1,"20140211.1",[app1]}}, {load_object_code,{app2,"20140207.1",[app2]}}, point_of_no_return, {suspend,[app1]}, {code_change,down,[{app1,[from2to1]}]}, {load,{app1,brutal_purge,brutal_purge}}, {resume,[app1]}, {suspend,[app2]}, {code_change,down,[{app2,[from2to1]}]}, {load,{app2,brutal_purge,brutal_purge}}, {resume,[app2]}]}]}. Best wishes Ivan On 13/02/2014 18:54, Mike Oxford wrote: > Is your brutal_purge on the PostPurge or the PrePurge? > > > On Thu, Feb 13, 2014 at 10:00 AM, Ivan Uemlianin > wrote: > > Dear All > > I am just getting started with live release upgrades, using relx and > following this tutorial: > > http://blog.troutwine.us/2013/__09/13/trivial_otp_releases.__html > > > Everything seems to work as advertised, except sometimes I need to > explicitly load the code into the running vm (i.e., using > code_load_file/1) for the new stuff to take effect. The function > release_handler:which___releases/0 reports the new release as active > and permanent, but I can see from behaviour that old versions of > certain modules are still running and handling data. > > I can't be much more specific I'm afraid. One example: one > application uses cowboy. If a release upgrade changes a cowboy > resource module, the new release version might still be running the > old version of that module until I load_file and purge. > > Why might this be happening? Am I missing something in the > packaging and upgrade process? Is there a better way I can write my > modules? > > If the information above is too vague, what should I look out for > next time this happens? > > With thanks and best wishes > > Ivan > > > -- > ==============================__============================== > Ivan A. Uemlianin PhD > Llaisdy > Speech Technology Research and Development > > ivan@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > github.com/llaisdy > www.linkedin.com/in/__ivanuemlianin > > > festina lente > ==============================__============================== > _________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/__listinfo/erlang-questions > > > -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From kraythe@REDACTED Thu Feb 13 20:04:43 2014 From: kraythe@REDACTED (kraythe .) Date: Thu, 13 Feb 2014 13:04:43 -0600 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <28AAEE0D-905F-4681-B388-7C883CCBA7D3@gmail.com> <796EBF0D-8EE3-446F-AEB0-DEF64701311F@jkemp.net> <52FD0D48.9010802@jkemp.net> Message-ID: Im not trying to troll anything. I stated my case, someone asked me a question and I answered it. If someone took offense, it wasn't intended. Now having stated my case I intend to drop it and do something more productive. :) I think we are all repeating ourselves here now so I intend to stop that now as it just wastes bandwidth. *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* *Author of: Hardcore Java (2003) and Maintainable Java (2012)* *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 * On Thu, Feb 13, 2014 at 12:57 PM, Mahesh Paolini-Subramanya < mahesh@REDACTED> wrote: > "Don't Feed The Trolls" > > That is all > > Me, I'm off for some well-deserved mortadella and lambrusco... > > > > *Mahesh Paolini-Subramanya > That > tall bald Indian guy.. * > *Google+ | Blog > | Twitter > | LinkedIn > * > > On February 13, 2014 at 7:46:30 PM, Steve Vinoski (vinoski@REDACTED) > wrote: > > Your trolling game is quickly falling apart. > > Anybody know how to mute a single thread on this list? > > --steve > > > On Thu, Feb 13, 2014 at 1:28 PM, kraythe . wrote: > >> Why not learn instead of sell? >> >> >> Because the bank wont take "I learned Erlang this month" in lie of my >> car payment or mortgage. Because innovations are rarely created for the >> purposes of "learn, not sell." Erlang itself was created to Sell, be under >> no misunderstanding. If Ericson couldn't make a case to the "sellers" then >> the language wouldn't have powered their switch. Because capitalism and >> libertarianism work and communism and socialism eventually run out of other >> people's money. And because I don't want to be someone living on someone >> else's dime. I like to create, innovate, invent and get paid for it. That >> lets me provide a better life for my family. >> >> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* >> *Author of: Hardcore Java (2003) and Maintainable Java (2012)* >> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 >> * >> >> >> On Thu, Feb 13, 2014 at 12:22 PM, John Kemp wrote: >> >>> On 02/13/2014 11:44 AM, kraythe . wrote: >>> >>>> Cant agree with you John. >>>> >>> >>> That's fine :) >>> >>> >>> In an organization you cant simply do what you >>>> want and shrug. >>>> If I tried that in any of the big organizations i have >>>> been involved with my optimal case is being fired. >>>> >>> >>> If I need to "convince" someone about the tech I want to use then I >>> either wouldn't use that tech and would use what they wanted instead, or I >>> would quit. >>> >>> It's absolutely the case that if you are driven by "social context" (by >>> that I mean, roughly, "other people's concerns") alone, you won't choose >>> Erlang. >>> >>> Although I would often choose Erlang for myself, I would often choose >>> another language if I had a programmer of that language to work with, and a >>> tight deadline. >>> >>> In my opinion, professional software developers should choose the best >>> tool for the job -- and the job often includes more than the problem at >>> hand, true. I like to make satisfied customers. >>> >>> >>> Perhaps if you own >>>> the company you can. But then that relegates Erlang to niche. Makes the >>>> old timers feel pretty superior >>>> >>> >>> As I've said, you can *choose* whatever language you like, and barring >>> the edge cases, you'll be able to build a workable, relatively scalable >>> solution. >>> >>> >>> but is a horrible waste of what appears >>>> to me to be a very useful language. Also if you go that tact there is no >>>> more point of arguing Erlang vs Scala or vs any language anymore. Erlang >>>> will become like Smalltalk. Useful and cool for the old timers but >>>> virtually IRRELEVANT in the IT industry. >>>> >>> >>> Erlang makes efficient use of computing resources, specifically in >>> distributed environments. It does several other clever things. It's also >>> hard to learn (for some programmers) and doesn't come with a ready "market" >>> of/for proficient software developers. But those who learn it tend to >>> understand the problems which Erlang is good at solving. And they >>> understand why the language choices made in Erlang might be made, in which >>> case, they will often understand other languages better than average >>> devlopers too. >>> >>> >>> >>>> Furthermore, if you argue you don't care about adoption then the >>>> discussion is moot with you. What >>>> >>> >>> I will continue to explain what I have observed about the advantages of >>> Erlang to those who will listen :) >>> >>> >>> it will mean is whomever is on your >>>> development staff writing Erlang you better be open to paying them >>>> whatever they want and letting them get away with about anything because >>>> replacing them would be nearly impossible. >>>> >>> >>> Unfortunately, I usually work with people who are not in position to >>> understand why one might use Erlang. >>> >>> Imagine that you have been initiated into a secret group of people who >>> will help give you an advantage in your software projects that so few have. >>> How could you use those skills? >>> >>> >>> Often many tech people cant >>>> see past "oooh list comprehensions !!!!!!" to the actual business behind >>>> it and without the business none of us get paid. That is not something >>>> you can take to management and sell. >>>> >>> >>> Why not learn instead of sell? >>> >>> - johnk >>> >>>> >>>> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* >>>> /Author of: Hardcore Java (2003) and Maintainable Java (2012)/ >>>> /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/ >>>> >>>> >>>> >>>> On Thu, Feb 13, 2014 at 10:33 AM, John Kemp >>> > wrote: >>>> >>>> On Feb 13, 2014, at 11:20 AM, kraythe . >>> > wrote: >>>> >>>> /Java as a language is big and complex, because it has a >>>>> lot of concepts directly inside the language./ >>>>> >>>>> >>>>> Ahh but here you are wrong. Java itself is analogous to Erlang >>>>> without OTP. you don't HAVE to use the JDK libraries beyond >>>>> java.lang. You would be a bit crazy reproducing the wheel if you >>>>> did so but it is not a requirement of writing java. In fact many >>>>> Java controlled micro devices only allow a very small subset of >>>>> the JDK to be used. So there is essentially no difference. >>>>> >>>>> So Elang is to Java as the Java Development Kit is to the Open >>>>> Telecom Platform. And there is where we have the "marketing" >>>>> disconnect. Its not about changing functionality or a triviality >>>>> to be scoffed over. If we start with the premise that we want more >>>>> developers to learn and use Erlang then we have to consider how >>>>> the language and its nomenclature comes across to our audience. >>>>> You don't name a language the Scalable High Integration Technology >>>>> because the impression it leaves with adopters is ... unfortunate. >>>>> >>>> >>>> Why start with that premise instead of starting with the premise >>>> that developers should try to understand what is useful to them? >>>> That has nothing to do with marketing, and everything to do with >>>> software developers understanding their craft better. >>>> >>>> >>>>> So if you DON'T care about people adopting the language, then the >>>>> discussion is academic and simply, as one reply put it, a waste of >>>>> time. Of course if you don't care about adoption then you are >>>>> wasting your time here because you wont be able to staff a >>>>> development crew, replace developers that leave or push the >>>>> language into an organization which isn't currently using it. >>>>> >>>> >>>> Who is "you" in this case? Does the "Erlang community" want to get >>>> the language adopted more? Perhaps. Why would that matter to the >>>> Erlang community - how do they benefit? Why should those who already >>>> know and benefit from Erlang not simply continue to do so? >>>> >>>> >>>>> If you DO care about people adopting the language you have to >>>>> consider its marketing. If I many were to take Erlang to >>>>> management and propose it for a product the management would see >>>>> "Open Telecom Platform", object that the company isn't a telecom >>>>> company and that Erlang is mainly for telecom and that would be >>>>> the end of that. In fact, if you really care about adoption you >>>>> are better off renaming it "Fred" than leaving it as "Open Telecom >>>>> Platform". >>>>> >>>> >>>> People reject languages for all kinds of strange reasons. And it's >>>> the case that in many cases you can simply choose "a language you >>>> like" and then *make* it work for what you want to do. After all, >>>> computers have particular resources available to them, and a >>>> language well-adapted to its environment should support adequate >>>> performance for most applications. The distinction between threading >>>> in Ruby and "event-driven" in Node is largely meaningless, for >>>> example. The real questions are things like "how well does your >>>> VM/compiler exploit computer hardware resources on the platform >>>> you're using". Most developers don't understand this, so they argue >>>> about threads vs. processes vs. events without understanding what >>>> might actually be the critical differences regarding the performance >>>> they say they want. >>>> >>>> Naming won't fix that. And management will never get that. You need >>>> people to understand what they are doing. Or not. After all, you can >>>> largely do what you like and apart from at the edges, it will likely >>>> work. >>>> >>>> - johnk >>>> >>>> >>>>> Naming matters and it is also pretty easy to fix. >>>>> >>>>> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* >>>>> /Author of: Hardcore Java (2003) and Maintainable Java (2012)/ >>>>> /LinkedIn: // >>>>> http://www.linkedin.com/pub/robert-simmons/40/852/a39/ >>>>> >>>>> >>>>> >>>>> On Thu, Feb 13, 2014 at 9:03 AM, Anthony Ramine >>>> > wrote: >>>>> >>>>> That's a *HUGE* difference. Erlang as a language is very >>>>> small; OTP is a very complex piece of software, as is BEAM. >>>>> The three shouldn't be conflated. >>>>> >>>>> Java as a language is big and complex, because it has a lot of >>>>> concepts directly inside the language. >>>>> >>>>> -- >>>>> Anthony Ramine >>>>> >>>>> Le 13 f?vr. 2014 ? 15:59, Vlad Dumitrescu >>>> > a ?crit : >>>>> >>>>> >>>>> > On Thu, Feb 13, 2014 at 3:46 PM, Anthony Ramine >>>>> > wrote: >>>>> >> Java without OOP is a different language. >>>>> >> Erlang without OTP is still Erlang. >>>>> > >>>>> > IMHO the only difference is that OTP is implemented as a >>>>> library and >>>>> > doesn't have dedicated language syntax. I make difference >>>>> between OTP >>>>> > as design/system building guidelines and its implementation. >>>>> The >>>>> > former is more like OOP for Java. The latter is more like >>>>> the JDK. >>>>> > >>>>> > /Vlad >>>>> > >>>>> >> -- >>>>> >> Anthony Ramine >>>>> >> >>>>> >> Le 13 f?vr. 2014 ? 15:21, Vlad Dumitrescu >>>>> > a ?crit : >>>>> >>>>> >> >>>>> >>> On Thu, Feb 13, 2014 at 2:09 PM, Benoit Chesneau >>>>> > wrote: >>>>> >>>> I also say Erlang/OTP and often I add to the one that ask >>>>> that OTP is >>>>> >>>> a framework, but then people are more puzzled than they >>>>> were before. >>>>> >>>> Maybe rust did the right things by clearly separating >>>>> the language >>>>> >>>> and the runtime from the standard library and other libs ? >>>>> >>> >>>>> >>> I would say that OTP is to Erlang what OOP is to Java. You >>>>> can write >>>>> >>> Java programs that are not object-oriented, but why choose >>>>> Java for >>>>> >>> that in the first place? >>>>> >>> >>>>> >>> OTP is in my opinion a design philosophy that guides us >>>>> when it comes >>>>> >>> to structuring and developing distributed fault-tolerant >>>>> systems. It >>>>> >>> comes with library support that is intimately tied to the >>>>> Erlang >>>>> >>> libraries: the most basic Erlang apps (kernel and stdlib) >>>>> are also the >>>>> >>> ones that implement the OTP concepts. Even more, Erlang >>>>> code is >>>>> >>> structured as applications, and an "application" is an OTP >>>>> concept! >>>>> >>> >>>>> >>> I can only see meaning in trying to separate the language >>>>> from OTP >>>>> >>> either as an academic exercise or in order to implement a >>>>> different >>>>> >>> language on the beam runtime and the new concepts would >>>>> collide >>>>> >>> implementation-wise with OTP. Or one wants to create OTP >>>>> 2.0 without >>>>> >>> interference with 1.0. >>>>> >>> >>>>> >>> regards, >>>>> >>> Vlad >>>>> >>>>> >>> _______________________________________________ >>>>> >>> erlang-questions mailing list >>>>> >>> erlang-questions@REDACTED >>>>> >>>>> >>>>> >>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >> >>>>> >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>> 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 >> >> > _______________________________________________ > 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 erlang@REDACTED Thu Feb 13 20:18:01 2014 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 13 Feb 2014 20:18:01 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FC8850.2000902@llaisdy.com> <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <28AAEE0D-905F-4681-B388-7C883CCBA7D3@gmail.com> <796EBF0D-8EE3-446F-AEB0-DEF64701311F@jkemp.net> <52FD0D48.9010802@jkemp.net> Message-ID: On Thu, Feb 13, 2014 at 7:28 PM, kraythe . wrote: > Why not learn instead of sell? > > > Because the bank wont take "I learned Erlang this month" in lie of my car > payment or mortgage. > Is their some X for which if you say "I learnt X this month" then a bank will give you money? Please tell me what X is > Because innovations are rarely created for the purposes of "learn, not > sell." Erlang itself was created to Sell, be under no misunderstanding. If > Ericson couldn't make a case to the "sellers" then the language wouldn't > have powered their switch. > Erlang was used to power the AXD301 (the breakthrough project) because all other projects had failed. It was a case of "last man standing" or "save me I'm drowning" Erlang spread outside Ericsson, because Ericsson banned it subsequently it became open source. > Because capitalism and libertarianism work and communism and socialism > eventually run out of other people's money. And because I don't want to be > someone living on someone else's dime. I like to create, innovate, invent > and get paid for it. That lets me provide a better life for my family. > Quite right - all other things being equal the companies that use Erlang as their core technology will bankrupt their competitors - Software Darwinism. Anyway companies sell products and don't give a damn what they are implemented in. When I buy a pen or pair of boot I don't care what programming language its implemented it. Programmers/managers/... are subject to a baggage of "my language is better than yours" noise - and it is just that - noise. "The proof of the pudding is in the eating" - what you have to do is 1) have a idea for a compelling product 2) build a prototype in some language 3) sell the idea/thing/prototype 4) make and sell the product 5) earn money from the product sales 6) have good luck Of these I guess 2) is the easiest /Joe > > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* > *Author of: Hardcore Java (2003) and Maintainable Java (2012)* > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 > * > > > On Thu, Feb 13, 2014 at 12:22 PM, John Kemp wrote: > >> On 02/13/2014 11:44 AM, kraythe . wrote: >> >>> Cant agree with you John. >>> >> >> That's fine :) >> >> >> In an organization you cant simply do what you >>> want and shrug. >>> If I tried that in any of the big organizations i have >>> been involved with my optimal case is being fired. >>> >> >> If I need to "convince" someone about the tech I want to use then I >> either wouldn't use that tech and would use what they wanted instead, or I >> would quit. >> >> It's absolutely the case that if you are driven by "social context" (by >> that I mean, roughly, "other people's concerns") alone, you won't choose >> Erlang. >> >> Although I would often choose Erlang for myself, I would often choose >> another language if I had a programmer of that language to work with, and a >> tight deadline. >> >> In my opinion, professional software developers should choose the best >> tool for the job -- and the job often includes more than the problem at >> hand, true. I like to make satisfied customers. >> >> >> Perhaps if you own >>> the company you can. But then that relegates Erlang to niche. Makes the >>> old timers feel pretty superior >>> >> >> As I've said, you can *choose* whatever language you like, and barring >> the edge cases, you'll be able to build a workable, relatively scalable >> solution. >> >> >> but is a horrible waste of what appears >>> to me to be a very useful language. Also if you go that tact there is no >>> more point of arguing Erlang vs Scala or vs any language anymore. Erlang >>> will become like Smalltalk. Useful and cool for the old timers but >>> virtually IRRELEVANT in the IT industry. >>> >> >> Erlang makes efficient use of computing resources, specifically in >> distributed environments. It does several other clever things. It's also >> hard to learn (for some programmers) and doesn't come with a ready "market" >> of/for proficient software developers. But those who learn it tend to >> understand the problems which Erlang is good at solving. And they >> understand why the language choices made in Erlang might be made, in which >> case, they will often understand other languages better than average >> devlopers too. >> >> >> >>> Furthermore, if you argue you don't care about adoption then the >>> discussion is moot with you. What >>> >> >> I will continue to explain what I have observed about the advantages of >> Erlang to those who will listen :) >> >> >> it will mean is whomever is on your >>> development staff writing Erlang you better be open to paying them >>> whatever they want and letting them get away with about anything because >>> replacing them would be nearly impossible. >>> >> >> Unfortunately, I usually work with people who are not in position to >> understand why one might use Erlang. >> >> Imagine that you have been initiated into a secret group of people who >> will help give you an advantage in your software projects that so few have. >> How could you use those skills? >> >> >> Often many tech people cant >>> see past "oooh list comprehensions !!!!!!" to the actual business behind >>> it and without the business none of us get paid. That is not something >>> you can take to management and sell. >>> >> >> Why not learn instead of sell? >> >> - johnk >> >>> >>> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* >>> /Author of: Hardcore Java (2003) and Maintainable Java (2012)/ >>> /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/ >>> >>> >>> >>> On Thu, Feb 13, 2014 at 10:33 AM, John Kemp >> > wrote: >>> >>> On Feb 13, 2014, at 11:20 AM, kraythe . >> > wrote: >>> >>> /Java as a language is big and complex, because it has a >>>> lot of concepts directly inside the language./ >>>> >>>> >>>> Ahh but here you are wrong. Java itself is analogous to Erlang >>>> without OTP. you don't HAVE to use the JDK libraries beyond >>>> java.lang. You would be a bit crazy reproducing the wheel if you >>>> did so but it is not a requirement of writing java. In fact many >>>> Java controlled micro devices only allow a very small subset of >>>> the JDK to be used. So there is essentially no difference. >>>> >>>> So Elang is to Java as the Java Development Kit is to the Open >>>> Telecom Platform. And there is where we have the "marketing" >>>> disconnect. Its not about changing functionality or a triviality >>>> to be scoffed over. If we start with the premise that we want more >>>> developers to learn and use Erlang then we have to consider how >>>> the language and its nomenclature comes across to our audience. >>>> You don't name a language the Scalable High Integration Technology >>>> because the impression it leaves with adopters is ... unfortunate. >>>> >>> >>> Why start with that premise instead of starting with the premise >>> that developers should try to understand what is useful to them? >>> That has nothing to do with marketing, and everything to do with >>> software developers understanding their craft better. >>> >>> >>>> So if you DON'T care about people adopting the language, then the >>>> discussion is academic and simply, as one reply put it, a waste of >>>> time. Of course if you don't care about adoption then you are >>>> wasting your time here because you wont be able to staff a >>>> development crew, replace developers that leave or push the >>>> language into an organization which isn't currently using it. >>>> >>> >>> Who is "you" in this case? Does the "Erlang community" want to get >>> the language adopted more? Perhaps. Why would that matter to the >>> Erlang community - how do they benefit? Why should those who already >>> know and benefit from Erlang not simply continue to do so? >>> >>> >>>> If you DO care about people adopting the language you have to >>>> consider its marketing. If I many were to take Erlang to >>>> management and propose it for a product the management would see >>>> "Open Telecom Platform", object that the company isn't a telecom >>>> company and that Erlang is mainly for telecom and that would be >>>> the end of that. In fact, if you really care about adoption you >>>> are better off renaming it "Fred" than leaving it as "Open Telecom >>>> Platform". >>>> >>> >>> People reject languages for all kinds of strange reasons. And it's >>> the case that in many cases you can simply choose "a language you >>> like" and then *make* it work for what you want to do. After all, >>> computers have particular resources available to them, and a >>> language well-adapted to its environment should support adequate >>> performance for most applications. The distinction between threading >>> in Ruby and "event-driven" in Node is largely meaningless, for >>> example. The real questions are things like "how well does your >>> VM/compiler exploit computer hardware resources on the platform >>> you're using". Most developers don't understand this, so they argue >>> about threads vs. processes vs. events without understanding what >>> might actually be the critical differences regarding the performance >>> they say they want. >>> >>> Naming won't fix that. And management will never get that. You need >>> people to understand what they are doing. Or not. After all, you can >>> largely do what you like and apart from at the edges, it will likely >>> work. >>> >>> - johnk >>> >>> >>>> Naming matters and it is also pretty easy to fix. >>>> >>>> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* >>>> /Author of: Hardcore Java (2003) and Maintainable Java (2012)/ >>>> /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/ >>>> >>>> >>>> >>>> On Thu, Feb 13, 2014 at 9:03 AM, Anthony Ramine >>> > wrote: >>>> >>>> That's a *HUGE* difference. Erlang as a language is very >>>> small; OTP is a very complex piece of software, as is BEAM. >>>> The three shouldn't be conflated. >>>> >>>> Java as a language is big and complex, because it has a lot of >>>> concepts directly inside the language. >>>> >>>> -- >>>> Anthony Ramine >>>> >>>> Le 13 f?vr. 2014 ? 15:59, Vlad Dumitrescu >>> > a ?crit : >>>> >>>> >>>> > On Thu, Feb 13, 2014 at 3:46 PM, Anthony Ramine >>>> > wrote: >>>> >> Java without OOP is a different language. >>>> >> Erlang without OTP is still Erlang. >>>> > >>>> > IMHO the only difference is that OTP is implemented as a >>>> library and >>>> > doesn't have dedicated language syntax. I make difference >>>> between OTP >>>> > as design/system building guidelines and its implementation. >>>> The >>>> > former is more like OOP for Java. The latter is more like >>>> the JDK. >>>> > >>>> > /Vlad >>>> > >>>> >> -- >>>> >> Anthony Ramine >>>> >> >>>> >> Le 13 f?vr. 2014 ? 15:21, Vlad Dumitrescu >>>> > a ?crit : >>>> >>>> >> >>>> >>> On Thu, Feb 13, 2014 at 2:09 PM, Benoit Chesneau >>>> > wrote: >>>> >>>> I also say Erlang/OTP and often I add to the one that ask >>>> that OTP is >>>> >>>> a framework, but then people are more puzzled than they >>>> were before. >>>> >>>> Maybe rust did the right things by clearly separating >>>> the language >>>> >>>> and the runtime from the standard library and other libs ? >>>> >>> >>>> >>> I would say that OTP is to Erlang what OOP is to Java. You >>>> can write >>>> >>> Java programs that are not object-oriented, but why choose >>>> Java for >>>> >>> that in the first place? >>>> >>> >>>> >>> OTP is in my opinion a design philosophy that guides us >>>> when it comes >>>> >>> to structuring and developing distributed fault-tolerant >>>> systems. It >>>> >>> comes with library support that is intimately tied to the >>>> Erlang >>>> >>> libraries: the most basic Erlang apps (kernel and stdlib) >>>> are also the >>>> >>> ones that implement the OTP concepts. Even more, Erlang >>>> code is >>>> >>> structured as applications, and an "application" is an OTP >>>> concept! >>>> >>> >>>> >>> I can only see meaning in trying to separate the language >>>> from OTP >>>> >>> either as an academic exercise or in order to implement a >>>> different >>>> >>> language on the beam runtime and the new concepts would >>>> collide >>>> >>> implementation-wise with OTP. Or one wants to create OTP >>>> 2.0 without >>>> >>> interference with 1.0. >>>> >>> >>>> >>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 essen@REDACTED Thu Feb 13 20:22:22 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 13 Feb 2014 20:22:22 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> <52FD0381.9090105@ninenines.eu> Message-ID: <52FD1B6E.7080903@ninenines.eu> On 02/13/2014 06:48 PM, kraythe . wrote: > So it seems the general sort of feeling is: "We don't really care about > adoption or how things are presented to the development community as well. > We call it Open Telecom Platform and if that means you can't sell a project > to management in Erlang then we don't care. Adoption is not a priority of > this community or Ericson in specific and thats that." I'm late in reading the thread and to be honest after reading this I couldn't care less anymore. I'll say this though: How the hell do you come up with "the community and Ericsson doesn't care about adoption" from a topic where you voice your concerns about the name being misleading? And why do you even mention Ericsson? You didn't even talk to them. And most importantly, what really matters? Adoption, or being able to write systems that actually work? Java has adoption, but everything is fundamentally broken. Is that really what you prefer? Being able to pay a dozen monkeys to piss awful code where one Erlang developer would have sufficed? Forcing said monkeys to take shifts at night to fix your system every other week where Erlang fixes itself automatically? And finally, do you prefer having a system with millions of lines of code that is essentially an unmaintanable mess with leaky abstractions all over the place, or a system with tens of thousands of lines of code with each "object" cleanly isolated in its own process? If you think adoption is most important, then you are clearly in the wrong place, not because the community doesn't want it, but because it doesn't want to *sacrifice* everything else just to get more people to use it. Especially when that sacrifice has no clear benefits, like with changing the name. And just so you know, Erlang *is* getting adopted, I have personally trained a hundred people this past year, many of them whose company just started doing Erlang or having done a couple small projects. There *is* adoption, it's just not in the same scale as Java, and never will, because you can't pay monkeys to piss Erlang code, while Java has a whole industry based on providing those code monkeys. -- Lo?c Hoguin http://ninenines.eu From moxford@REDACTED Thu Feb 13 20:24:05 2014 From: moxford@REDACTED (Mike Oxford) Date: Thu, 13 Feb 2014 11:24:05 -0800 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> <20140213180519.GL62889@ferdair.local> Message-ID: PHBs don't see the value. They don't see the payoff. They know what's worked for them before and what's "tried and true" and "the way things have always been done." Other languages are "safe." A sort of a "known quantity." Those EXACT same issues happen when trying to onboard Scala or Ruby. Judging from previous companies where they've try to hire Ruby devs ... the project got moved to another language because they couldn't find enough people with a Ruby background. And that was here in Silicon Valley. Ruby was a flash in the pan as an alternative to PHP (really, the first) and seems to be waning. But that's why R&D departments exist. To explore new ideas and see if they're worth having Corporate pursue. We're seeing a LOT more Erlang traction in the last 2-3 years. Whereas it was once completely unknown outside of a few small circles it's rapidly gaining notice and, IMO, we're on the upswell. There are a lot of projects using it and people (at least here in the Valley) are starting to take notice ... if they're not using it they at least "know someone who knows someone who has." As to "I'm not interested in your project because Erlang is useless on my resume" ... screw that guy. You wouldn't want him ANYWAYS. Completely wrong attitude. You're better off NOT having him. He's either into your project or not. If he's just out to build his resume ... meh. A players hire A players; B players hire C players. Make sure you're hiring an A player. Erlang, to most people, seem to be Erlang + OTP. To most people around here, as well, Java means Java+Spring. Sure, you can separate them but who cares? On Thu, Feb 13, 2014 at 10:16 AM, kraythe . wrote: > I have read portions of your book and appreciate your insight. However, I > think you underestimate the task here. Convincing developers may be > difficult, but if they are good devs they might come around. Convincing > management with control over budget and staffing when the naming is wrong? > Nearly impossible. Thats why massive advertising companies have made > billions off of just naming things correctly. All of the other concerns you > posted are very legit and I have had and still do have many of them myself. > But those concerns are at the tech level and only of minor interest to the > manager wondering why would he staff for erlang and not scala or ruby? > > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* > *Author of: Hardcore Java (2003) and Maintainable Java (2012)* > *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 > * > > > On Thu, Feb 13, 2014 at 12:05 PM, Fred Hebert wrote: > >> Answers inline. >> >> On 02/13, kraythe . wrote: >> > I Guess my answers would be: >> > 0) If there is a business case, you can convince them. Low adoption >> hurts >> > their maintainability and staffing much more than it does for the >> startup >> > or small company. They are a business, not a bunch of unreasonable oafs. >> >> That may be doable. I'm not saying the opposite. >> >> > 1) Why rewrite the libs if you use the same initials. I wouldn't worry >> > about that. The programming world is replete with examples of such >> things. >> >> If we can use the same initials, then that's gained and removes a bunch >> of issues. >> >> > 2) and updating the docs will take ... 10 man hours? Do we not have >> search >> > and replace capable tools? >> > 3) Same answer as 2. >> >> Yes, but we do not have administration rights to mirrors, say >> http://erldocs.com/ and translations that can be hosted by the >> community. >> >> The work done with the OTP documentation goes further than the OTP team >> itself. >> >> > 4) Dont need to "make sure" of anything. If the books want to be >> accurate >> > they will use the new name, if not "shrug" thats their problem. Trust me >> > someone on amazon will post "Its not called Open Telecom Platform since >> > 2014, it stands for "Open Technology Platform". There are enough >> pedantic, >> > basement living, people on the internet that will annoy authors into >> > submission. >> >> That doesn't sound like a pleasant experience for everyone. Again, it's >> not an insurmountable challenge. It's just one more challenge. >> >> > 5) Small matter of documentation. "It used to be called X but was >> renamed >> > to Y in 2014" >> >> Documentation lives on way longer than expected. People still read and >> order reprints of the Erlang book published in 1994 (and 1996 for the >> second edition), some of which are translations. >> >> Many older versions of books are what is in libraries and whatnot, since >> Joe's first version in early 2000s. For people using these versions, you >> end up with inaccurate terminology regarding half the name of the >> language. >> >> It's a matter of documentation, but it's a matter of trying to do it >> right to reduce the amount of confusion. If people look for "Open >> Telecom Platform Erlang" it would be sweet to get the new documentation >> and content. >> >> Maybe it's easy, but it's still part of a roadmap. >> >> Alternatively, would 'Open Telecom Platform, a framework that is not >> just about telecoms' going to be more cumbersome in documentation? >> >> > 6) History is history. Those investigating the language will get it. It >> > startedo ut being a telecoms thing and migrated to a general language. >> No >> > problem. Live web sites can easily add in blurbs. Old articles will be >> out >> > of date but not from the time frame of when they were written. No big >> deal. >> > The sky isnt actually falling. >> >> I could see that being made as a decision, yes. >> >> > 7) Obviously this one is just frothing. The man could update the next >> > version of his book with more information, cool tricks, whatever and >> sell >> > it as a second edition. >> >> Yes. I like to insert a bit of non-serious content here and there. >> >> > 8) What "traditional SDK" are you referring to? The LISP standard lib? >> ;-) >> > Java? C? Ruby? Haskell? Which one is the "normal" one? Normal is >> defined in >> > the context of the language, not in the context of another language? In >> > fact the vast majority of SDKs for java are third party to the JDK >> itself >> > anyway. >> >> I went from this thread's usage of SDK as a similar point to OTP. >> Erlang/SDK if you will. If you want to keep it as Erlang/OTP, that can >> work, but needs to be significantly better than what it is right now to >> have an actually measurable impact. >> >> Otherwise, we're throwing stuff at the wall to see what sticks, with no >> proof that it actually helped anything. >> >> > 9) Trying to crystal ball the future will only give you a headache. The >> key >> > is to move from where yo are to a point where progress has been made and >> > recursively loop on that algorithm, not be paralyzed by "what if .... ?" >> > >> >> Non-serious content here also. Not to be taken seriously, but I wouldn't >> be surprised if it were to happen. >> >> > You may have been doing Erlang for ages and feel quite the man but the >> > question really boils down to "what would you like for the future of >> Erlang >> > to be?" If the answer to that in your mind is "A niche language that I >> can >> > call myself a guru at and everyone looks at me quizzically and puts up >> with >> > my eccentricity or dare say arrogance." then the current name and trend >> is >> > fine. If the answer is, "A powerful general purpose programming language >> > for developing applications using functional paradigms and widely >> accepted >> > as being the solution to the next generation of software problems." Then >> > marketing is important. >> >> Oh I love that one. I want Erlang to be adopted so much I wrote an >> entire book about it and put it online for free, without advertisement. >> This has taken over 3 years of my spare time, because I wanted Erlang to >> be more accessible. I invite you to visit it at >> http://learnyousomeerlang.com, and maybe buy an ebook or print copy if >> you feel like it would be nicer to read that way. If you prefer a free >> electronic copies, there are scripts on github to convert it to the >> kindle format, and a wget line in the FAQ to download a local copy. >> >> I also kept writing multiple blog posts at http://ferd.ca that guide and >> show more tutorials about Erlang, use cases, and tries to sell it as a >> language as a whole. >> >> The reason I'm answering to your suggestion negatively isn't that I >> don't want Erlang to succeed, it's that I do not believe that changing >> the meaning of 'OTP' from 'Open Telecom Platform' to 'Open Technology >> Platform' will have a noticeable impact. >> >> Some people do ask the question 'but I don't want to do telecoms', but >> in my experience, people's issues are the following, to a much higher >> degree: >> >> - The syntax is unfamiliar (or ugly) >> - It's difficult to work with single assignment, recursion, immutable >> algorithms (most of your algorithm books that rely on arrays with O(1) >> access to work fine are no longer going to be trivial to translate! >> That's huge!) >> - The tooling (rebar, relx, etc.) isn't up to par with other languages, >> even if it keeps getting better. >> - Lack of IDEs (that was your prime concern when you joined these lists) >> - Fighting the idea that "it will be hard to hire Erlang developers" to >> make it enter and stay in the enterprise. >> >> All of those criticism, in the years I've been in the Erlang community, >> have come up time and time again. They've also have come up orders of >> magnitude more often than OTP as a name, even if it does come up from >> time to time. >> >> I'm sorry I came up as harsh. I do want better adoption for Erlang and >> took months if not years of my free time working that way. I do not >> think renaming OTP is worth the effort, but I'll be glad to be proven >> wrong through bigger adoption if someone steps up and decides to do it. >> >> Now if you please, I'll go back to spending my lunch time working on an >> post-scripted chapter to the LYSE site introducing maps to people. >> >> Regards, >> Fred. >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Thu Feb 13 20:25:21 2014 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 13 Feb 2014 20:25:21 +0100 Subject: [erlang-questions] Trying to learn the Erlang Way In-Reply-To: References: <71D26997-BBC2-41F7-BCAB-592E45D28609@cs.otago.ac.nz> Message-ID: On Wed, Feb 12, 2014 at 10:48 PM, Gustav Simonsson < gustav.simonsson@REDACTED> wrote: > Apologies if this is completely wrong, but: > > Wouldn't one process for each particle, given thousands of particles, pose > a potential overhead problem given the extra scheduling required between > processes? > > Without building a prototype and *measuring* I haven't a clue. "thousands" sounds small to me. Given 4GB of ram on my machine each process could have 4MB (if there were 1000 processes) which is *huge* compared to the minimum Erlang process size (300 bytes) and there will be several schedulers (on a multicore) so I wouldn't worry. /Joe > I would be inclined to try one process for each 3d cube, as you mentioned, > and also let that process keep track of all particles within its cube > (maybe in a ETS table). Then, if a particle crosses over to another cube, > the particle would be migrated from one process to another (via a message > sent between the two cube processes). > > To answer your other points of debate: > > 1. This is a very interesting problem which for graphics from a first > person point of view is well researched, but since this is for some backend > serving a game/simulation it (I suppose) involves multiple > players/entities, so we wouldn't want the 3D space to be asymmetrically > partitioned if we could avoid it (atleast to start with). > > If it makes sense given the properties of the 3D space, particles and > other objects/players you have, one way to reduce the maximum shapes > overlapping with the sphere of influence to 4 is to partition the space > into a set of symmetrical cuboids where the Z-axis of each cuboid goes from > the minimum to the maximum of the space, and the X and Y sizes of the > cuboids remain strictly larger than the diameter of the sphere (as you > mentioned for the cube partitioning). > > 2. I guess the particles, whether they have their own process or are > handled inside a cube (or cuboid!) process are in memory anyway, so I'd > wait with caching anything until its time to optimize a working > implementation. > > 3. The general advice is to save tweaking the BEAM schedulers and which > scheduler a process runs in for the later stages of optimization. But for > reference, you can bind a process to a specific scheduler [1] and also bind > a scheduler to a specific CPU thread (logical processor) [2]. > > > Cheers, > Gustav > > [1] Use the {scheduler, N} option (undocumented) to > erlang:spawn_opt/2,3,4,5. The number of schedulers can be found with > erlang:system_info(schedulers) > , and the scheduler for the calling process with > erlang:system_info(scheduler_id). > > [2] Look at the +sbt options at > http://www.erlang.org/doc/man/erl.html#emu_flags > > > > > On Wed, Feb 12, 2014 at 9:48 PM, kraythe . wrote: > >> Joe, >> >> The problems of gaming are similar for sure but the scale here is much >> larger. But I can throw another monkey wrench into the mix. The motion of >> the particles are non-deterministic and can be acted upon by an external >> force. So each particle needs to have its own life and own process. What I >> had thought of doing is the following and i would be appreciative of the >> experience of you and the other erlang gurus in commenting on my proposals: >> >> I essentially thought to have each particle be its own process. >> Furthermore, the world would be divided up into 3d cubes, each of which is >> at least larger than the maximum radius of the sphere of influence. Each 3d >> cube would be a process as well and the. The particle process would track >> which cube it is in and the cubes would track which particles are in them. >> Then when the motion happens at each frame if the particle leaves a cube, >> it will send a message to that cube indicating it left and it will also >> send a message to the new cube that it entered. When determining the >> particles in the field, the particle would determine whether its sphere >> spanned multiple cubes and ask each cube which it overlaps to send it a >> message with the list of particles in the cube. Then it would apply our >> "in_sphere" test to determine the actual candidates to interact with and >> then execute those interractions. >> >> Points of debate for me are: >> 1) Should they be cubes dividing the space or another shape. If we use >> cubes, the maximum number of cubes a sphere could overlap would be 8 if the >> cubes are arranged in a regular pattern. Alternatively we could use an >> irregular pattern like a brick layer and then the max number of cubes to >> check is 5. Are there any other configurations that don't have any overlap >> of spatial partitioning and could reduce the number of candidate cells >> further without complicating the math badly. >> 2) is it worth it to cache, in some manner, the particles in the sphere >> of influence. I am leaning towards "no" because all will have to be checked >> to see if they moved out anyway and then the other candidates will have to >> be checked if they moved in. So there seems little reason to cache anything. >> 3) Is it worth it to manually move processes around cores as they >> transition to other areas of geometry (i.e. if the particle is on core 8 of >> machine 5 but its bounding cube is on core 2 of node 1 there could be >> inefficiency.) This question is largely a result of my newbieness to OTP >> and erlang I suppose. If we do move the actor around we will have to >> reconnect the "client" governing the particle motion to the new actor. >> >> Interesting problem huh? >> >> >> *Robert Simmons Jr. MSc. * >> >> >> On Wed, Feb 12, 2014 at 1:42 PM, Joe Armstrong wrote: >> >>> Interesting problem. >>> >>> How to you map your problem onto a process structure? >>> >>> Method 1 - let the process manage regions of space >>> >>> How about starting with 1000 parallel processes. Each one managing a >>> point in a 10x10x10 grid in 3-d space. >>> >>> In pass one you compute which process "owns" each particle. Thereafter >>> each process only manages the >>> particles that it owns. Once it knows the velocity and position of each >>> particle it can compute if the particle >>> will leave the zone in the next time tick. In the case when a particle >>> leaves a zone, you just send a message >>> to the next zone controller process that you predict it will move to. >>> >>> I know that some games companies use this technique for large multi-user >>> games written in Erlang. They use a 2D map of squares and each square is >>> controlled by an Erlang processes. This scales nicely on a cluster, since >>> moving off a map square just moves the computation to a new processes and >>> possible a >>> new node. >>> >>> Method 2 - let the processes manage a limited set of processes >>> >>> I guess if you didn't have too many particles you could have one process >>> per particle. Each process >>> could have a "gossip" set (the set of "nearby in space" processes) which >>> send messages to it's neighbours as things happen. Or you could let one >>> process handle 10 particles ... >>> >>> I guess it al depends on the numbers - I don't think you said how many >>> particles there were etc. >>> I always like to know some numbers - are we talking millions or >>> thousands of particles? How many >>> interactions/sec take place etc. >>> >>> In any case you'll have to model the problem in different ways and >>> measure. >>> >>> Cheers >>> >>> /Joe >>> >>> >>> >>> >>> >>> On Wed, Feb 12, 2014 at 6:56 PM, kraythe . wrote: >>> >>>> Ahh octtree is good if the objects are static and if your goal is to >>>> find an object in a large space. It is a reductive search algorithm. In >>>> this case all of the objects are in motion and I want to know my neigbors, >>>> not find object X in the space. Therefore a different approach is called >>>> for. >>>> >>>> Imagine thousands of particles flowing around in a medium and needing >>>> to determine their interactions based on vicinity, momentum, etc. From >>>> frame to frame the state of your tree would change and the cost would make >>>> the simulation impossible to render in realtime. Instead if the world is >>>> divided up into cubes that are larger than the sphere of influence and each >>>> cube knows about its neighbors then I can easily get a candidate list as >>>> long as the particles update the cube entity that they are in. As they move >>>> into a cube, they inform the cube that they have entered and as they leave >>>> the cube, they inform it of their exit. If I know the cube I am in, and I >>>> know my sphere of influence overlaps into another cube, I can immediately >>>> exclude all candidate not in either cube. If the cube has references to its >>>> neigbors, the solution is easy. >>>> >>>> 1) Determine if I overlap sphere into neighbors (simple math problem of >>>> the radius of my sphere and the boinds of the cube. >>>> 2) For all cubes I overlap, get members. >>>> 3) For all members determine which are inside my sphere. >>>> 4) Interract with elements in my sphere. >>>> >>>> Incidentally my current version of the code, Thanks to Richard's input, >>>> is: >>>> >>>> %% Subtract the second vector from the first >>>> subtract({X1, Y1, Z1}, {X2, Y2, Z2}) -> {(X1 - X2), (Y1 - Y2), (Z1 - >>>> Z2)}. >>>> >>>> %% Compute if the vector T is in the sphere with center at vector C and >>>> with radius R. >>>> in_sphere(C, R, T) -> >>>> {Dx, Dy, Dz} = subtract(C, T), >>>> Dx * Dx + Dy * Dy + Dz * Dz =< R * R. >>>> >>>> %% Calculate all entities in the sphere defined at center vector C with >>>> radius R and using Fpos which will extract the location to check from >>>> %% each entity in the list. The method Fpos must return a three tuple >>>> vector and take the entity as an argument. >>>> entities_in_sphere(C ,R, Entities, Fpos) -> >>>> [E || E <- Entities, in_sphere(C, R, Fpos(E))]. >>>> >>>> It also appears to run quite fast according to preliminary timer:tc >>>> tests but of course there is need for more massive testing of load. I may >>>> still have to use the type optimization richard pointed out. I am debating >>>> staying with integer arithmetic also. >>>> >>>> >>>> *Robert Simmons Jr. MSc. * >>>> >>>> >>>> On Wed, Feb 12, 2014 at 8:04 AM, Joe Armstrong wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Tue, Feb 11, 2014 at 11:17 PM, kraythe . wrote: >>>>> >>>>>> Richard, >>>>>> >>>>>> I appreciate your response and the effort you put into it. And I >>>>>> learned a lot from it. In this case I am learning the thinking mode of >>>>>> Erlang as it is different a bit from what I do to pay the bills. I have yet >>>>>> to get into list comprehensions in Erlang so that is on my ... well ... >>>>>> list. :) You have provided valuable insight. >>>>>> >>>>>> The main focus of the method is if I have a number of objects with a >>>>>> vector position in a simulation and I want to exclude considerations of >>>>>> interactions with objects outside the sphere of influence, I have to >>>>>> quickly discard the candidates that are not inside the sphere of influence. >>>>>> I originally thought to write a method that did just the vector math >>>>>> because I was wondering if that kind of math would have to ultimately be >>>>>> turned into something native. Even a delay of 1 second would be fatal to >>>>>> the simulation. >>>>>> >>>>> >>>>> Isn't this what octrees are for? - You'd have to use a "cube of >>>>> influence" - but as far as I know octrees >>>>> can be used to rapidly partition objects in a 3-d space >>>>> >>>>> Take a look at this http://en.wikipedia.org/wiki/Octree >>>>> >>>>> /Joe >>>>> >>>>> >>>>>> >>>>>> The algorithm, however, shouldnt have to consider all candidates as >>>>>> the world is broken into spacial segments (cubes) such that the sphere >>>>>> could intersect with at maximum 8 neighboring cubes so I would only need to >>>>>> consider simulation objects within those 8 cube spaces when determining >>>>>> which elements were actually within the sphere of influence. I have been >>>>>> trying to devise a method of reducing the candidate set even further and am >>>>>> still working on that. Perhaps edge detection and cube boundary >>>>>> calculations but I don't want to spend more math doing that then I would >>>>>> simply excluding objects vector by vector. >>>>>> >>>>>> Anyway thanks for the reply, definitely some information that I can >>>>>> use in there. >>>>>> >>>>>> *Robert Simmons Jr. MSc.* >>>>>> >>>>>> On Sun, Feb 9, 2014 at 10:59 PM, Richard A. O'Keefe < >>>>>> ok@REDACTED> wrote: >>>>>> >>>>>>> >>>>>>> On 8/02/2014, at 4:53 AM, kraythe . wrote: >>>>>>> > Anyway back to the subject at hand. The algorithm is set but now I >>>>>>> am at another quandary Lets say these vectors represent a position in space >>>>>>> of particular objects in a simulation. The process of culling the vectors >>>>>>> based on the sphere is entirely a vector problem but what the user calling >>>>>>> cull/3 really needs to know is which objects are not culled from the list, >>>>>>> not just which vectors are not culled. Now in Java I could do a number of >>>>>>> things if I wanted to keep the cull algorithm as it is. I could return the >>>>>>> list of integers containing the original indexes of the vectors in the list >>>>>>> that were culled and use that to filter out which objects need to be >>>>>>> considered for the simulation step. >>>>>>> >>>>>>> The word "cull" really grates. >>>>>>> >>>>>>> And all those negations *really* confused me *all over again*. >>>>>>> I wrote a lengthy and helpful description of how to get the >>>>>>> points that were accepted and the points that were rejected >>>>>>> as two lists, because that was the only way I could interpret >>>>>>> your question to make sense in Erlang. But on repeated re-reading >>>>>>> it became clear that you were asking for something else. >>>>>>> >>>>>>> There is no such thing in Erlang as object identity. >>>>>>> The distinction you are drawing between the "points" and the >>>>>>> "objects" simply doesn't exist. >>>>>>> >>>>>>> It so happens that if you use a list comprehension like >>>>>>> [P || P <- Points, some_predicate(P)] >>>>>>> the elements of the result *will* be (references to) the same >>>>>>> implementation-level webs of chunks of memory that were in the >>>>>>> original list, not copies. But nothing other than performance >>>>>>> depends on this. >>>>>>> >>>>>>> A list of integers such as you ask for could be obtained, but it >>>>>>> would be very little use to you, because Erlang lists are *LINKED >>>>>>> LISTS*, not *INDEXED ARRAYS*. Finding the nth element of a list >>>>>>> takes O(n) time, and that could not be changed without making >>>>>>> lists much less useful. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 moxford@REDACTED Thu Feb 13 20:35:03 2014 From: moxford@REDACTED (Mike Oxford) Date: Thu, 13 Feb 2014 11:35:03 -0800 Subject: [erlang-questions] release upgrades and code loading In-Reply-To: <52FD16FC.10101@llaisdy.com> References: <52FD0826.2080305@llaisdy.com> <52FD16FC.10101@llaisdy.com> Message-ID: [{"1.0.6",[], [{load_object_code,{app1,"*201**40213.1*",[app1]}}, {load_object_code,{app2,"*20140**213.1*",[app2]}}, Replacing a version with itself? On Thu, Feb 13, 2014 at 11:03 AM, Ivan Uemlianin wrote: > Dear Mike > > Thanks for your help. > > Here's a recent relup. After this upgrade, I had to manually code_load > and purge app1: > > {"1.0.7", > [{"1.0.6",[], > [{load_object_code,{app1,"20140213.1",[app1]}}, > {load_object_code,{app2,"20140213.1",[app2]}}, > point_of_no_return, > {suspend,[app1]}, > {load,{app1,brutal_purge,brutal_purge}}, > {code_change,up,[{app1,[from1to2]}]}, > {resume,[app1]}, > {suspend,[app2]}, > {load,{app2,brutal_purge,brutal_purge}}, > {code_change,up,[{app2,[from1to2]}]}, > {resume,[app2]}]}], > [{"1.0.6",[], > [{load_object_code,{app1,"20140211.1",[app1]}}, > {load_object_code,{app2,"20140207.1",[app2]}}, > point_of_no_return, > {suspend,[app1]}, > {code_change,down,[{app1,[from2to1]}]}, > {load,{app1,brutal_purge,brutal_purge}}, > {resume,[app1]}, > {suspend,[app2]}, > {code_change,down,[{app2,[from2to1]}]}, > {load,{app2,brutal_purge,brutal_purge}}, > {resume,[app2]}]}]}. > > Best wishes > > Ivan > > > > On 13/02/2014 18:54, Mike Oxford wrote: > >> Is your brutal_purge on the PostPurge or the PrePurge? >> >> >> On Thu, Feb 13, 2014 at 10:00 AM, Ivan Uemlianin > > wrote: >> >> Dear All >> >> I am just getting started with live release upgrades, using relx and >> following this tutorial: >> >> http://blog.troutwine.us/2013/__09/13/trivial_otp_releases.__html >> >> >> >> Everything seems to work as advertised, except sometimes I need to >> explicitly load the code into the running vm (i.e., using >> code_load_file/1) for the new stuff to take effect. The function >> release_handler:which___releases/0 reports the new release as active >> >> and permanent, but I can see from behaviour that old versions of >> certain modules are still running and handling data. >> >> I can't be much more specific I'm afraid. One example: one >> application uses cowboy. If a release upgrade changes a cowboy >> resource module, the new release version might still be running the >> old version of that module until I load_file and purge. >> >> Why might this be happening? Am I missing something in the >> packaging and upgrade process? Is there a better way I can write my >> modules? >> >> If the information above is too vague, what should I look out for >> next time this happens? >> >> With thanks and best wishes >> >> Ivan >> >> >> -- >> ==============================__============================== >> >> Ivan A. Uemlianin PhD >> Llaisdy >> Speech Technology Research and Development >> >> ivan@REDACTED >> www.llaisdy.com >> llaisdy.wordpress.com >> github.com/llaisdy >> www.linkedin.com/in/__ivanuemlianin >> >> >> festina lente >> ==============================__============================== >> _________________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/__listinfo/erlang-questions >> >> >> >> > -- > ============================================================ > Ivan A. Uemlianin PhD > Llaisdy > Speech Technology Research and Development > > ivan@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > github.com/llaisdy > www.linkedin.com/in/ivanuemlianin > > festina lente > ============================================================ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Thu Feb 13 20:35:05 2014 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 13 Feb 2014 20:35:05 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> <20140213180519.GL62889@ferdair.local> Message-ID: On Thu, Feb 13, 2014 at 8:24 PM, Mike Oxford wrote: > PHBs don't see the value. They don't see the payoff. They know what's > worked for them before and what's "tried and true" and "the way things have > always been done." Other languages are "safe." A sort of a "known > quantity." Those EXACT same issues happen when trying to onboard Scala or > Ruby. Judging from previous companies where they've try to hire Ruby devs > ... the project got moved to another language because they couldn't find > enough people with a Ruby background. And that was here in Silicon Valley. > Ruby was a flash in the pan as an alternative to PHP (really, the first) > and seems to be waning. > Right - if you've heard of it you're no longer leading you're following. Ericsson from which Erlang emerged wants to lead not follow, and Ericsson does lead the world in providing mobile infrastructures, parts of which are programmed in Erlang. Following "safe" languages (Scala, Ruby) would be a lunatic strategy. Ericsson does do a lot software research - but I am not able to tell you in which areas (grin) > > But that's why R&D departments exist. To explore new ideas and see if > they're worth having Corporate pursue. > > Yes 100% /Joe > We're seeing a LOT more Erlang traction in the last 2-3 years. Whereas > it was once completely unknown outside of a few small circles it's rapidly > gaining notice and, IMO, we're on the upswell. There are a lot of projects > using it and people (at least here in the Valley) are starting to take > notice ... if they're not using it they at least "know someone who knows > someone who has." > > > As to "I'm not interested in your project because Erlang is useless on my > resume" ... screw that guy. You wouldn't want him ANYWAYS. Completely > wrong attitude. You're better off NOT having him. He's either into your > project or not. If he's just out to build his resume ... meh. A players > hire A players; B players hire C players. Make sure you're hiring an A > player. > > > Erlang, to most people, seem to be Erlang + OTP. To most people around > here, as well, Java means Java+Spring. Sure, you can separate them but who > cares? > > > On Thu, Feb 13, 2014 at 10:16 AM, kraythe . wrote: > >> I have read portions of your book and appreciate your insight. However, I >> think you underestimate the task here. Convincing developers may be >> difficult, but if they are good devs they might come around. Convincing >> management with control over budget and staffing when the naming is wrong? >> Nearly impossible. Thats why massive advertising companies have made >> billions off of just naming things correctly. All of the other concerns you >> posted are very legit and I have had and still do have many of them myself. >> But those concerns are at the tech level and only of minor interest to the >> manager wondering why would he staff for erlang and not scala or ruby? >> >> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* >> *Author of: Hardcore Java (2003) and Maintainable Java (2012)* >> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 >> * >> >> >> On Thu, Feb 13, 2014 at 12:05 PM, Fred Hebert wrote: >> >>> Answers inline. >>> >>> On 02/13, kraythe . wrote: >>> > I Guess my answers would be: >>> > 0) If there is a business case, you can convince them. Low adoption >>> hurts >>> > their maintainability and staffing much more than it does for the >>> startup >>> > or small company. They are a business, not a bunch of unreasonable >>> oafs. >>> >>> That may be doable. I'm not saying the opposite. >>> >>> > 1) Why rewrite the libs if you use the same initials. I wouldn't worry >>> > about that. The programming world is replete with examples of such >>> things. >>> >>> If we can use the same initials, then that's gained and removes a bunch >>> of issues. >>> >>> > 2) and updating the docs will take ... 10 man hours? Do we not have >>> search >>> > and replace capable tools? >>> > 3) Same answer as 2. >>> >>> Yes, but we do not have administration rights to mirrors, say >>> http://erldocs.com/ and translations that can be hosted by the >>> community. >>> >>> The work done with the OTP documentation goes further than the OTP team >>> itself. >>> >>> > 4) Dont need to "make sure" of anything. If the books want to be >>> accurate >>> > they will use the new name, if not "shrug" thats their problem. Trust >>> me >>> > someone on amazon will post "Its not called Open Telecom Platform since >>> > 2014, it stands for "Open Technology Platform". There are enough >>> pedantic, >>> > basement living, people on the internet that will annoy authors into >>> > submission. >>> >>> That doesn't sound like a pleasant experience for everyone. Again, it's >>> not an insurmountable challenge. It's just one more challenge. >>> >>> > 5) Small matter of documentation. "It used to be called X but was >>> renamed >>> > to Y in 2014" >>> >>> Documentation lives on way longer than expected. People still read and >>> order reprints of the Erlang book published in 1994 (and 1996 for the >>> second edition), some of which are translations. >>> >>> Many older versions of books are what is in libraries and whatnot, since >>> Joe's first version in early 2000s. For people using these versions, you >>> end up with inaccurate terminology regarding half the name of the >>> language. >>> >>> It's a matter of documentation, but it's a matter of trying to do it >>> right to reduce the amount of confusion. If people look for "Open >>> Telecom Platform Erlang" it would be sweet to get the new documentation >>> and content. >>> >>> Maybe it's easy, but it's still part of a roadmap. >>> >>> Alternatively, would 'Open Telecom Platform, a framework that is not >>> just about telecoms' going to be more cumbersome in documentation? >>> >>> > 6) History is history. Those investigating the language will get it. It >>> > startedo ut being a telecoms thing and migrated to a general language. >>> No >>> > problem. Live web sites can easily add in blurbs. Old articles will be >>> out >>> > of date but not from the time frame of when they were written. No big >>> deal. >>> > The sky isnt actually falling. >>> >>> I could see that being made as a decision, yes. >>> >>> > 7) Obviously this one is just frothing. The man could update the next >>> > version of his book with more information, cool tricks, whatever and >>> sell >>> > it as a second edition. >>> >>> Yes. I like to insert a bit of non-serious content here and there. >>> >>> > 8) What "traditional SDK" are you referring to? The LISP standard lib? >>> ;-) >>> > Java? C? Ruby? Haskell? Which one is the "normal" one? Normal is >>> defined in >>> > the context of the language, not in the context of another language? In >>> > fact the vast majority of SDKs for java are third party to the JDK >>> itself >>> > anyway. >>> >>> I went from this thread's usage of SDK as a similar point to OTP. >>> Erlang/SDK if you will. If you want to keep it as Erlang/OTP, that can >>> work, but needs to be significantly better than what it is right now to >>> have an actually measurable impact. >>> >>> Otherwise, we're throwing stuff at the wall to see what sticks, with no >>> proof that it actually helped anything. >>> >>> > 9) Trying to crystal ball the future will only give you a headache. >>> The key >>> > is to move from where yo are to a point where progress has been made >>> and >>> > recursively loop on that algorithm, not be paralyzed by "what if .... >>> ?" >>> > >>> >>> Non-serious content here also. Not to be taken seriously, but I wouldn't >>> be surprised if it were to happen. >>> >>> > You may have been doing Erlang for ages and feel quite the man but the >>> > question really boils down to "what would you like for the future of >>> Erlang >>> > to be?" If the answer to that in your mind is "A niche language that I >>> can >>> > call myself a guru at and everyone looks at me quizzically and puts up >>> with >>> > my eccentricity or dare say arrogance." then the current name and >>> trend is >>> > fine. If the answer is, "A powerful general purpose programming >>> language >>> > for developing applications using functional paradigms and widely >>> accepted >>> > as being the solution to the next generation of software problems." >>> Then >>> > marketing is important. >>> >>> Oh I love that one. I want Erlang to be adopted so much I wrote an >>> entire book about it and put it online for free, without advertisement. >>> This has taken over 3 years of my spare time, because I wanted Erlang to >>> be more accessible. I invite you to visit it at >>> http://learnyousomeerlang.com, and maybe buy an ebook or print copy if >>> you feel like it would be nicer to read that way. If you prefer a free >>> electronic copies, there are scripts on github to convert it to the >>> kindle format, and a wget line in the FAQ to download a local copy. >>> >>> I also kept writing multiple blog posts at http://ferd.ca that guide and >>> show more tutorials about Erlang, use cases, and tries to sell it as a >>> language as a whole. >>> >>> The reason I'm answering to your suggestion negatively isn't that I >>> don't want Erlang to succeed, it's that I do not believe that changing >>> the meaning of 'OTP' from 'Open Telecom Platform' to 'Open Technology >>> Platform' will have a noticeable impact. >>> >>> Some people do ask the question 'but I don't want to do telecoms', but >>> in my experience, people's issues are the following, to a much higher >>> degree: >>> >>> - The syntax is unfamiliar (or ugly) >>> - It's difficult to work with single assignment, recursion, immutable >>> algorithms (most of your algorithm books that rely on arrays with O(1) >>> access to work fine are no longer going to be trivial to translate! >>> That's huge!) >>> - The tooling (rebar, relx, etc.) isn't up to par with other languages, >>> even if it keeps getting better. >>> - Lack of IDEs (that was your prime concern when you joined these lists) >>> - Fighting the idea that "it will be hard to hire Erlang developers" to >>> make it enter and stay in the enterprise. >>> >>> All of those criticism, in the years I've been in the Erlang community, >>> have come up time and time again. They've also have come up orders of >>> magnitude more often than OTP as a name, even if it does come up from >>> time to time. >>> >>> I'm sorry I came up as harsh. I do want better adoption for Erlang and >>> took months if not years of my free time working that way. I do not >>> think renaming OTP is worth the effort, but I'll be glad to be proven >>> wrong through bigger adoption if someone steps up and decides to do it. >>> >>> Now if you please, I'll go back to spending my lunch time working on an >>> post-scripted chapter to the LYSE site introducing maps to people. >>> >>> Regards, >>> Fred. >>> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From felixgallo@REDACTED Thu Feb 13 20:39:43 2014 From: felixgallo@REDACTED (Felix Gallo) Date: Thu, 13 Feb 2014 11:39:43 -0800 Subject: [erlang-questions] httpc considered harmful Message-ID: I recently ran into a very scary issue that appears to be related to httpc. I was hitting a web API millions of times, with varying URLs; e.g., /users/9000000, /users/9000001, etc., at a rate of around 100-400 requests/sec, using httpc:request, each request spawned by a different worker: get_user(UserID) -> get_user_r(UserID, 10). get_user_r(UserID, 0) -> io:format("dying because ran out of retries on ~p~n",[UserID]); get_user_r(UserID, Retries) -> Url = lists:concat(["http://example.com/users/", UserID]), Filename = lists:concat(["users/-", UserID, ".json"]), io:format("requesting user: ~p~n", [UserID]), case httpc:request(Url) of {ok, Result} -> {_, _, Body} = Result, file:write_file(Filename, Body), userscrapemaster ! {ok, ClanID}; {error, Reason} -> io:format("error for user ~p: ~p~n",[UserID, Reason]), get_members_r(UserID, Retries - 1) A small (< 0.1%) but significant percentage of the time, the httpc:request call for completely different workers MIXED UP THEIR RESPONSES with other concurrent requests. For example, sometimes /users/5000 returned success but provided the body that /users/5001 should have returned, and /users/5001 returned the body that /users/5002 should have returned, and /users/5002 returned the body that /users/5000 should have returned. Or, /users/5009 returned the response for /users/5010, and vice versa. There appeared to be no obvious pattern except that all those calls were concurrent, and pragmatically I didn't have the time to go chasing into httpc to try to figure out where the state was getting scrambled, but as a test I moved the call over to lhttpc without changing the structure of the code otherwise, and the mixed responses went away. If I get some time I'll try to dig into httpc to understand what happened there, but as a warning to others: httpc looks like it has a hidden race condition or other bug, and lhttpc does not. F. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Thu Feb 13 20:51:37 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Thu, 13 Feb 2014 19:51:37 +0000 Subject: [erlang-questions] release upgrades and code loading In-Reply-To: References: <52FD0826.2080305@llaisdy.com> <52FD16FC.10101@llaisdy.com> Message-ID: <2102315A-8B47-4B18-A674-29B5C90C7C83@llaisdy.com> Sorry don't follow -- festina lente > On 13 Feb 2014, at 19:35, Mike Oxford wrote: > > [{"1.0.6",[], > [{load_object_code,{app1,"20140213.1",[app1]}}, > {load_object_code,{app2,"20140213.1",[app2]}}, > > Replacing a version with itself? > > > >> On Thu, Feb 13, 2014 at 11:03 AM, Ivan Uemlianin wrote: >> Dear Mike >> >> Thanks for your help. >> >> Here's a recent relup. After this upgrade, I had to manually code_load and purge app1: >> >> {"1.0.7", >> [{"1.0.6",[], >> [{load_object_code,{app1,"20140213.1",[app1]}}, >> {load_object_code,{app2,"20140213.1",[app2]}}, >> point_of_no_return, >> {suspend,[app1]}, >> {load,{app1,brutal_purge,brutal_purge}}, >> {code_change,up,[{app1,[from1to2]}]}, >> {resume,[app1]}, >> {suspend,[app2]}, >> {load,{app2,brutal_purge,brutal_purge}}, >> {code_change,up,[{app2,[from1to2]}]}, >> {resume,[app2]}]}], >> [{"1.0.6",[], >> [{load_object_code,{app1,"20140211.1",[app1]}}, >> {load_object_code,{app2,"20140207.1",[app2]}}, >> point_of_no_return, >> {suspend,[app1]}, >> {code_change,down,[{app1,[from2to1]}]}, >> {load,{app1,brutal_purge,brutal_purge}}, >> {resume,[app1]}, >> {suspend,[app2]}, >> {code_change,down,[{app2,[from2to1]}]}, >> {load,{app2,brutal_purge,brutal_purge}}, >> {resume,[app2]}]}]}. >> >> Best wishes >> >> Ivan >> >> >> >>> On 13/02/2014 18:54, Mike Oxford wrote: >>> Is your brutal_purge on the PostPurge or the PrePurge? >>> >>> >>> On Thu, Feb 13, 2014 at 10:00 AM, Ivan Uemlianin >> > wrote: >>> >>> Dear All >>> >>> I am just getting started with live release upgrades, using relx and >>> following this tutorial: >>> >>> http://blog.troutwine.us/2013/__09/13/trivial_otp_releases.__html >>> >>> >>> >>> Everything seems to work as advertised, except sometimes I need to >>> explicitly load the code into the running vm (i.e., using >>> code_load_file/1) for the new stuff to take effect. The function >>> release_handler:which___releases/0 reports the new release as active >>> >>> and permanent, but I can see from behaviour that old versions of >>> certain modules are still running and handling data. >>> >>> I can't be much more specific I'm afraid. One example: one >>> application uses cowboy. If a release upgrade changes a cowboy >>> resource module, the new release version might still be running the >>> old version of that module until I load_file and purge. >>> >>> Why might this be happening? Am I missing something in the >>> packaging and upgrade process? Is there a better way I can write my >>> modules? >>> >>> If the information above is too vague, what should I look out for >>> next time this happens? >>> >>> With thanks and best wishes >>> >>> Ivan >>> >>> >>> -- >>> ==============================__============================== >>> >>> Ivan A. Uemlianin PhD >>> Llaisdy >>> Speech Technology Research and Development >>> >>> ivan@REDACTED >>> www.llaisdy.com >>> llaisdy.wordpress.com >>> github.com/llaisdy >>> www.linkedin.com/in/__ivanuemlianin >>> >>> >>> festina lente >>> ==============================__============================== >>> _________________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/__listinfo/erlang-questions >>> >> >> -- >> ============================================================ >> Ivan A. Uemlianin PhD >> Llaisdy >> Speech Technology Research and Development >> >> ivan@REDACTED >> www.llaisdy.com >> llaisdy.wordpress.com >> github.com/llaisdy >> www.linkedin.com/in/ivanuemlianin >> >> festina lente >> ============================================================ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moxford@REDACTED Thu Feb 13 20:59:37 2014 From: moxford@REDACTED (Mike Oxford) Date: Thu, 13 Feb 2014 11:59:37 -0800 Subject: [erlang-questions] release upgrades and code loading In-Reply-To: <2102315A-8B47-4B18-A674-29B5C90C7C83@llaisdy.com> References: <52FD0826.2080305@llaisdy.com> <52FD16FC.10101@llaisdy.com> <2102315A-8B47-4B18-A674-29B5C90C7C83@llaisdy.com> Message-ID: It looks like you're trying to suspend version 20140213.1 and replace it with 20140213.1 (the same version.) On Thu, Feb 13, 2014 at 11:51 AM, Ivan Uemlianin wrote: > Sorry don't follow > > -- > festina lente > > > On 13 Feb 2014, at 19:35, Mike Oxford wrote: > > [{"1.0.6",[], > [{load_object_code,{app1,"*201**40213.1*",[app1]}}, > {load_object_code,{app2,"*20140**213.1*",[app2]}}, > > Replacing a version with itself? > > > > On Thu, Feb 13, 2014 at 11:03 AM, Ivan Uemlianin wrote: > >> Dear Mike >> >> Thanks for your help. >> >> Here's a recent relup. After this upgrade, I had to manually code_load >> and purge app1: >> >> {"1.0.7", >> [{"1.0.6",[], >> [{load_object_code,{app1,"20140213.1",[app1]}}, >> {load_object_code,{app2,"20140213.1",[app2]}}, >> point_of_no_return, >> {suspend,[app1]}, >> {load,{app1,brutal_purge,brutal_purge}}, >> {code_change,up,[{app1,[from1to2]}]}, >> {resume,[app1]}, >> {suspend,[app2]}, >> {load,{app2,brutal_purge,brutal_purge}}, >> {code_change,up,[{app2,[from1to2]}]}, >> {resume,[app2]}]}], >> [{"1.0.6",[], >> [{load_object_code,{app1,"20140211.1",[app1]}}, >> {load_object_code,{app2,"20140207.1",[app2]}}, >> point_of_no_return, >> {suspend,[app1]}, >> {code_change,down,[{app1,[from2to1]}]}, >> {load,{app1,brutal_purge,brutal_purge}}, >> {resume,[app1]}, >> {suspend,[app2]}, >> {code_change,down,[{app2,[from2to1]}]}, >> {load,{app2,brutal_purge,brutal_purge}}, >> {resume,[app2]}]}]}. >> >> Best wishes >> >> Ivan >> >> >> >> On 13/02/2014 18:54, Mike Oxford wrote: >> >>> Is your brutal_purge on the PostPurge or the PrePurge? >>> >>> >>> On Thu, Feb 13, 2014 at 10:00 AM, Ivan Uemlianin >> > wrote: >>> >>> Dear All >>> >>> I am just getting started with live release upgrades, using relx and >>> following this tutorial: >>> >>> http://blog.troutwine.us/2013/__09/13/trivial_otp_releases.__html >>> >>> >>> >>> Everything seems to work as advertised, except sometimes I need to >>> explicitly load the code into the running vm (i.e., using >>> code_load_file/1) for the new stuff to take effect. The function >>> release_handler:which___releases/0 reports the new release as active >>> >>> and permanent, but I can see from behaviour that old versions of >>> certain modules are still running and handling data. >>> >>> I can't be much more specific I'm afraid. One example: one >>> application uses cowboy. If a release upgrade changes a cowboy >>> resource module, the new release version might still be running the >>> old version of that module until I load_file and purge. >>> >>> Why might this be happening? Am I missing something in the >>> packaging and upgrade process? Is there a better way I can write my >>> modules? >>> >>> If the information above is too vague, what should I look out for >>> next time this happens? >>> >>> With thanks and best wishes >>> >>> Ivan >>> >>> >>> -- >>> ==============================__============================== >>> >>> Ivan A. Uemlianin PhD >>> Llaisdy >>> Speech Technology Research and Development >>> >>> ivan@REDACTED >>> www.llaisdy.com >>> llaisdy.wordpress.com >>> github.com/llaisdy >>> www.linkedin.com/in/__ivanuemlianin >>> >>> >>> festina lente >>> ==============================__============================== >>> _________________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/__listinfo/erlang-questions >>> >>> >>> >>> >> -- >> ============================================================ >> Ivan A. Uemlianin PhD >> Llaisdy >> Speech Technology Research and Development >> >> ivan@REDACTED >> www.llaisdy.com >> llaisdy.wordpress.com >> github.com/llaisdy >> www.linkedin.com/in/ivanuemlianin >> >> festina lente >> ============================================================ >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.joseph.davis@REDACTED Thu Feb 13 21:17:59 2014 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Thu, 13 Feb 2014 14:17:59 -0600 Subject: [erlang-questions] release upgrades and code loading In-Reply-To: References: <52FD0826.2080305@llaisdy.com> <52FD16FC.10101@llaisdy.com> <2102315A-8B47-4B18-A674-29B5C90C7C83@llaisdy.com> Message-ID: Mike, pretty sure its upgrading two apps to the same version. app1 is 20140211.1 -> 20140213.1 app2 is 20140207.1 -> 20140213.1 On Thu, Feb 13, 2014 at 1:59 PM, Mike Oxford wrote: > It looks like you're trying to suspend version 20140213.1 and replace it > with 20140213.1 (the same version.) > > > > On Thu, Feb 13, 2014 at 11:51 AM, Ivan Uemlianin wrote: >> >> Sorry don't follow >> >> -- >> festina lente >> >> >> On 13 Feb 2014, at 19:35, Mike Oxford wrote: >> >> [{"1.0.6",[], >> [{load_object_code,{app1,"20140213.1",[app1]}}, >> {load_object_code,{app2,"20140213.1",[app2]}}, >> >> Replacing a version with itself? >> >> >> >> On Thu, Feb 13, 2014 at 11:03 AM, Ivan Uemlianin wrote: >>> >>> Dear Mike >>> >>> Thanks for your help. >>> >>> Here's a recent relup. After this upgrade, I had to manually code_load >>> and purge app1: >>> >>> {"1.0.7", >>> [{"1.0.6",[], >>> [{load_object_code,{app1,"20140213.1",[app1]}}, >>> {load_object_code,{app2,"20140213.1",[app2]}}, >>> point_of_no_return, >>> {suspend,[app1]}, >>> {load,{app1,brutal_purge,brutal_purge}}, >>> {code_change,up,[{app1,[from1to2]}]}, >>> {resume,[app1]}, >>> {suspend,[app2]}, >>> {load,{app2,brutal_purge,brutal_purge}}, >>> {code_change,up,[{app2,[from1to2]}]}, >>> {resume,[app2]}]}], >>> [{"1.0.6",[], >>> [{load_object_code,{app1,"20140211.1",[app1]}}, >>> {load_object_code,{app2,"20140207.1",[app2]}}, >>> point_of_no_return, >>> {suspend,[app1]}, >>> {code_change,down,[{app1,[from2to1]}]}, >>> {load,{app1,brutal_purge,brutal_purge}}, >>> {resume,[app1]}, >>> {suspend,[app2]}, >>> {code_change,down,[{app2,[from2to1]}]}, >>> {load,{app2,brutal_purge,brutal_purge}}, >>> {resume,[app2]}]}]}. >>> >>> Best wishes >>> >>> Ivan >>> >>> >>> >>> On 13/02/2014 18:54, Mike Oxford wrote: >>>> >>>> Is your brutal_purge on the PostPurge or the PrePurge? >>>> >>>> >>>> On Thu, Feb 13, 2014 at 10:00 AM, Ivan Uemlianin >>> > wrote: >>>> >>>> Dear All >>>> >>>> I am just getting started with live release upgrades, using relx and >>>> following this tutorial: >>>> >>>> http://blog.troutwine.us/2013/__09/13/trivial_otp_releases.__html >>>> >>>> >>>> >>>> Everything seems to work as advertised, except sometimes I need to >>>> explicitly load the code into the running vm (i.e., using >>>> code_load_file/1) for the new stuff to take effect. The function >>>> release_handler:which___releases/0 reports the new release as active >>>> >>>> and permanent, but I can see from behaviour that old versions of >>>> certain modules are still running and handling data. >>>> >>>> I can't be much more specific I'm afraid. One example: one >>>> application uses cowboy. If a release upgrade changes a cowboy >>>> resource module, the new release version might still be running the >>>> old version of that module until I load_file and purge. >>>> >>>> Why might this be happening? Am I missing something in the >>>> packaging and upgrade process? Is there a better way I can write my >>>> modules? >>>> >>>> If the information above is too vague, what should I look out for >>>> next time this happens? >>>> >>>> With thanks and best wishes >>>> >>>> Ivan >>>> >>>> >>>> -- >>>> ==============================__============================== >>>> >>>> Ivan A. Uemlianin PhD >>>> Llaisdy >>>> Speech Technology Research and Development >>>> >>>> ivan@REDACTED >>>> www.llaisdy.com >>>> llaisdy.wordpress.com >>>> github.com/llaisdy >>>> www.linkedin.com/in/__ivanuemlianin >>>> >>>> >>>> festina lente >>>> ==============================__============================== >>>> _________________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/__listinfo/erlang-questions >>>> >>>> >>>> >>> >>> -- >>> ============================================================ >>> Ivan A. Uemlianin PhD >>> Llaisdy >>> Speech Technology Research and Development >>> >>> ivan@REDACTED >>> www.llaisdy.com >>> llaisdy.wordpress.com >>> github.com/llaisdy >>> www.linkedin.com/in/ivanuemlianin >>> >>> festina lente >>> ============================================================ >> >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From ivan@REDACTED Thu Feb 13 21:26:22 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Thu, 13 Feb 2014 20:26:22 +0000 Subject: [erlang-questions] release upgrades and code loading In-Reply-To: References: <52FD0826.2080305@llaisdy.com> <52FD16FC.10101@llaisdy.com> <2102315A-8B47-4B18-A674-29B5C90C7C83@llaisdy.com> Message-ID: Paul's interpretation is what I was trying to do with this upgrade. Ivan -- festina lente > On 13 Feb 2014, at 20:17, Paul Davis wrote: > > Mike, pretty sure its upgrading two apps to the same version. > > app1 is 20140211.1 -> 20140213.1 > app2 is 20140207.1 -> 20140213.1 > >> On Thu, Feb 13, 2014 at 1:59 PM, Mike Oxford wrote: >> It looks like you're trying to suspend version 20140213.1 and replace it >> with 20140213.1 (the same version.) >> >> >> >>> On Thu, Feb 13, 2014 at 11:51 AM, Ivan Uemlianin wrote: >>> >>> Sorry don't follow >>> >>> -- >>> festina lente >>> >>> >>> On 13 Feb 2014, at 19:35, Mike Oxford wrote: >>> >>> [{"1.0.6",[], >>> [{load_object_code,{app1,"20140213.1",[app1]}}, >>> {load_object_code,{app2,"20140213.1",[app2]}}, >>> >>> Replacing a version with itself? >>> >>> >>> >>>> On Thu, Feb 13, 2014 at 11:03 AM, Ivan Uemlianin wrote: >>>> >>>> Dear Mike >>>> >>>> Thanks for your help. >>>> >>>> Here's a recent relup. After this upgrade, I had to manually code_load >>>> and purge app1: >>>> >>>> {"1.0.7", >>>> [{"1.0.6",[], >>>> [{load_object_code,{app1,"20140213.1",[app1]}}, >>>> {load_object_code,{app2,"20140213.1",[app2]}}, >>>> point_of_no_return, >>>> {suspend,[app1]}, >>>> {load,{app1,brutal_purge,brutal_purge}}, >>>> {code_change,up,[{app1,[from1to2]}]}, >>>> {resume,[app1]}, >>>> {suspend,[app2]}, >>>> {load,{app2,brutal_purge,brutal_purge}}, >>>> {code_change,up,[{app2,[from1to2]}]}, >>>> {resume,[app2]}]}], >>>> [{"1.0.6",[], >>>> [{load_object_code,{app1,"20140211.1",[app1]}}, >>>> {load_object_code,{app2,"20140207.1",[app2]}}, >>>> point_of_no_return, >>>> {suspend,[app1]}, >>>> {code_change,down,[{app1,[from2to1]}]}, >>>> {load,{app1,brutal_purge,brutal_purge}}, >>>> {resume,[app1]}, >>>> {suspend,[app2]}, >>>> {code_change,down,[{app2,[from2to1]}]}, >>>> {load,{app2,brutal_purge,brutal_purge}}, >>>> {resume,[app2]}]}]}. >>>> >>>> Best wishes >>>> >>>> Ivan >>>> >>>> >>>> >>>>> On 13/02/2014 18:54, Mike Oxford wrote: >>>>> >>>>> Is your brutal_purge on the PostPurge or the PrePurge? >>>>> >>>>> >>>>> On Thu, Feb 13, 2014 at 10:00 AM, Ivan Uemlianin >>>> > wrote: >>>>> >>>>> Dear All >>>>> >>>>> I am just getting started with live release upgrades, using relx and >>>>> following this tutorial: >>>>> >>>>> http://blog.troutwine.us/2013/__09/13/trivial_otp_releases.__html >>>>> >>>>> >>>>> >>>>> Everything seems to work as advertised, except sometimes I need to >>>>> explicitly load the code into the running vm (i.e., using >>>>> code_load_file/1) for the new stuff to take effect. The function >>>>> release_handler:which___releases/0 reports the new release as active >>>>> >>>>> and permanent, but I can see from behaviour that old versions of >>>>> certain modules are still running and handling data. >>>>> >>>>> I can't be much more specific I'm afraid. One example: one >>>>> application uses cowboy. If a release upgrade changes a cowboy >>>>> resource module, the new release version might still be running the >>>>> old version of that module until I load_file and purge. >>>>> >>>>> Why might this be happening? Am I missing something in the >>>>> packaging and upgrade process? Is there a better way I can write my >>>>> modules? >>>>> >>>>> If the information above is too vague, what should I look out for >>>>> next time this happens? >>>>> >>>>> With thanks and best wishes >>>>> >>>>> Ivan >>>>> >>>>> >>>>> -- >>>>> ==============================__============================== >>>>> >>>>> Ivan A. Uemlianin PhD >>>>> Llaisdy >>>>> Speech Technology Research and Development >>>>> >>>>> ivan@REDACTED >>>>> www.llaisdy.com >>>>> llaisdy.wordpress.com >>>>> github.com/llaisdy >>>>> www.linkedin.com/in/__ivanuemlianin >>>>> >>>>> >>>>> festina lente >>>>> ==============================__============================== >>>>> _________________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/__listinfo/erlang-questions >>>>> >>>> >>>> -- >>>> ============================================================ >>>> Ivan A. Uemlianin PhD >>>> Llaisdy >>>> Speech Technology Research and Development >>>> >>>> ivan@REDACTED >>>> www.llaisdy.com >>>> llaisdy.wordpress.com >>>> github.com/llaisdy >>>> www.linkedin.com/in/ivanuemlianin >>>> >>>> festina lente >>>> ============================================================ >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> From roger@REDACTED Thu Feb 13 21:31:44 2014 From: roger@REDACTED (Roger Lipscombe) Date: Thu, 13 Feb 2014 12:31:44 -0800 Subject: [erlang-questions] cth_surefire and setup failures Message-ID: We're using cth_surefire to integrate our Common Test suites with Jenkins, and I think there's a problem with it. When init_per_testcase/2 fails, cth_surefire outputs elements for each of the tests in the suite. This causes Jenkins to assume that the tests were skipped deliberately. I believe that it ought to output instead, for these cases. Is my understanding of the expected JUnit XML correct? Does anyone have a workaround or patch? Should I write one? Thanks, Roger. From tuncer.ayaz@REDACTED Thu Feb 13 21:33:43 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Thu, 13 Feb 2014 21:33:43 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <52F4C173.8050408@erlang.org> References: <52F4C173.8050408@erlang.org> Message-ID: On Fri, Feb 7, 2014 at 12:20 PM, Andreas Schumacher wrote: > A pre-release is denoted with .0-rc, where starts with 1 > at the delivery of the first pre-release, and is incremented by one > for each subsequent pre-release. "-rc0" will be used during > development up to the first release candidate. Pre-releases > -rc sort before . Apart from -rc, there are no plans > for other special parts; although that might change if the need > arises. Have you considered avoiding -rc by using a scheme as follows: Next stable release: 17.0.0 Next major release release candidate one: 17.99.1 Isn't that simpler to deal with? > When branching out, we add ".1" at the end of .., unless > this version number has already been used. If it has already been > used, we search for an unused version number by adding more and more > ".0" between the version we are branching from, and the ".1" that we > add at the end. For example, 17.0.1.1, 17.0.1.0.1, 17.0.1.0.0.1, and > 17.0.1.0.0.0.1 are all versions of modifications based on version > 17.0.1. I can follow the rest of your email, but can you provide some real life examples for the case of inserting 0 upon branching? From tuncer.ayaz@REDACTED Thu Feb 13 21:35:03 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Thu, 13 Feb 2014 21:35:03 +0100 Subject: [erlang-questions] FW: Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: <52F4C173.8050408@erlang.org> <1391790979.26271.YahooMailNeo@web140106.mail.bf1.yahoo.com> <49EC93AB-69A4-49AB-A2C0-4DA9F418E3F6@gmail.com> <58912684E2630B45963406CF7D8C52581C3473C6@ESESSMB103.ericsson.se> <52FB2C0E.90008@erlang.org> <58912684E2630B45963406CF7D8C52581C348431@ESESSMB103.ericsson.se> <52FCC466.9060206@erlang.org> Message-ID: On Thu, Feb 13, 2014 at 5:26 PM, Vlad Dumitrescu wrote: > Hi Andreas, > > I would prefer to be able to check the version without starting > erlang. Would it be possible to add a property to the start script? That would indeed be useful. > The "OTP APN 181 01" is useless anyway :-) From essen@REDACTED Thu Feb 13 21:54:32 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 13 Feb 2014 21:54:32 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> Message-ID: <52FD3108.4000508@ninenines.eu> On 02/13/2014 08:02 PM, Garrett Smith wrote: > On Thu, Feb 13, 2014 at 12:15 PM, Joe Armstrong wrote: >> >> On Thu, Feb 13, 2014 at 10:51 AM, Garrett Smith wrote: >>> >>> Sigh. This *is* confusing. It just is. >>> >>> Lo?c you *cannot* use Erlang without OTP. The VM starts a system, >>> which consists of applications, which are supervisory trees of >>> gen_servers. >> >> This is wrong - you can use Erlang without OTP. >> >> OTP loads 60 odd modules, starts a code server and some other stuff and >> *then* executes your code. >> >> You can "easily" roll your own system that uses far fewer modules and gets >> you up >> and running, but then you don't get the shell, the code loader and a load of >> other goodies. >> >> Appendix 3 of the 2'nd edition of Programming Erlang tells you *exactly* how >> to do this. >> >> To summarise Appendix 3 - I load 3 modules in 20ms instead of the 1.1s >> Erlang + OTP takes (on the same machine) then you're up and running, not OTP >> but a with a code loader and simple I/O system. > > Book ordered. > > The prospect of getting off the OTP facility is very appealing. If > it's that trivial to get the same features without incurring the cost > of those modules, I'm in. > > I think the needle could move here. Getting something up and running is trivial and only takes a few minutes. Getting something with the same features as OTP but without the cost? I hope you got a lot of free time. Of course you can probably cut a certain amount of features out, few people use release upgrades for example. You can probably cut out the io server and other features related to distribution if you're making a single-node system. -- Lo?c Hoguin http://ninenines.eu From tuncer.ayaz@REDACTED Thu Feb 13 21:54:14 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Thu, 13 Feb 2014 21:54:14 +0100 Subject: [erlang-questions] ChicagoBoss 0.8.7 with PostgreSQL 9.2 In-Reply-To: <000001cf27ab$c28e99d0$47abcd70$@frcuba.co.cu> References: <000001cf27ab$c28e99d0$47abcd70$@frcuba.co.cu> Message-ID: On Wed, Feb 12, 2014 at 5:34 AM, Ivan Carmenates Garcia wrote: > > Hi all, > > I'm in the middle of some project and I have troubles connecting cb > with postgreSQL I'm using the full and stable version of cb 0.8.7 > because the new one isn't possible for me to get from here. Rebar > uses a peer protocol or something that is not a simple http request > to connect to github, and I have many restrictions in my proxy, > restrictions that I cannot solve because that is not up to me. So my I didn't try it myself, but I know people who use the following global git config to replace git:// with https:// whenever they fetch from a remote: $ git config --global url."https://".insteadOf "git://" If you have local repos you want to access via git://, you should be more specific: $ git config --global url."https://github".insteadOf "git://github" Also see the git-clone(1) and git-config(1) man pages: http://git-scm.com/docs/git-clone http://git-scm.com/docs/git-config > point is if there is any way to solve this problem whether is > updating the mysql dependency to another version that works with cb > 0.8.7 and PostgreSQL 9.x at the same time or getting another version > of the postgreSQL, I think the stable version of mysql that comes > with cb 0.8.7 works only with postgreSQL 8.x, but that is an old > version of it. > > I would rather to have the stable version of cb 0.8.9 that I think > it will work with postgreSQL 9.2 but unfortunately I cannot get it, > if someone would be so kind of get it for me with the entire cb > 0.8.9 or some master stable version that supports postgreSQL 9.x > with all it well functional deps (rebar get-deps) I will appreciate > that. If you're interested in overriding deps specified in sub-projects, you might want to follow https://github.com/rebar/rebar/issues/222. From mjtruog@REDACTED Thu Feb 13 22:32:56 2014 From: mjtruog@REDACTED (Michael Truog) Date: Thu, 13 Feb 2014 13:32:56 -0800 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> <52FD0381.9090105@ninenines.eu> Message-ID: <52FD3A08.8040302@gmail.com> I guess you need to decide for yourself whether you want to be a technology lemming, and simply chasing what technology is fashionable (the concern of "oh what would people say if they knew what OTP stands for"), or instead pursuing the right technology choice for the circumstances. Architects are suppose to be able to make critical decisions about technology, and that is what I assume you are paid to do. On 02/13/2014 09:48 AM, kraythe . wrote: > So it seems the general sort of feeling is: "We don't really care about adoption or how things are presented to the development community as well. We call it Open Telecom Platform and if that means you can't sell a project to management in Erlang then we don't care. Adoption is not a priority of this community or Ericson in specific and thats that." > > Sort of makes me wonder what I am doing here and what I have spent the last 2 weeks of my free time doing. I could write my project in Lisp an achieve the same result and I already know Lisp fairly well. > > Honestly this whole thread is making me think back to the first thread I posted in this community and making me wonder if it would not be better to go down the road of Scala instead. Even though that community is not what Id call friendly, I can staff a Scala project with talented Java / Ruby / Node.js / Clojure people. With the general sense in the Erlang community I could hardly blame the developer that said "I'm not interested in your project because Erlang is useless to my resume." > > Hmm definitely food for thought. > > > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* > /Author of: Hardcore Java (2003) and Maintainable Java (2012)/ > /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/ > > > On Thu, Feb 13, 2014 at 11:40 AM, Lo?c Hoguin > wrote: > > On 02/13/2014 06:29 PM, kraythe . wrote: > > someone on amazon will post "Its not called Open Telecom Platform since > 2014, it stands for "Open Technology Platform". > > > I hope you don't seriously believe "Open Technology Platform" is any better. > > Instead of a few people mistakenly thinking OTP is a Telecom thing, you'll end up with everyone not understanding what the f OTP is. > > It's easy to tie what Telecoms do to what general IT does, it's all essentially the same thing, except it actually needs to work in Telecoms. But technology? That could mean anything from the wheel to creating life from scratch in a lab to intergallactic space travel. > > > -- > Lo?c Hoguin > http://ninenines.eu > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Thu Feb 13 22:43:40 2014 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 13 Feb 2014 22:43:40 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> Message-ID: On Thu, Feb 13, 2014 at 8:02 PM, Garrett Smith wrote: > On Thu, Feb 13, 2014 at 12:15 PM, Joe Armstrong wrote: > > > > On Thu, Feb 13, 2014 at 10:51 AM, Garrett Smith wrote: > >> > >> Sigh. This *is* confusing. It just is. > >> > >> Lo?c you *cannot* use Erlang without OTP. The VM starts a system, > >> which consists of applications, which are supervisory trees of > >> gen_servers. > > > > This is wrong - you can use Erlang without OTP. > > > > OTP loads 60 odd modules, starts a code server and some other stuff and > > *then* executes your code. > > > > You can "easily" roll your own system that uses far fewer modules and > gets > > you up > > and running, but then you don't get the shell, the code loader and a > load of > > other goodies. > > > > Appendix 3 of the 2'nd edition of Programming Erlang tells you *exactly* > how > > to do this. > > > > To summarise Appendix 3 - I load 3 modules in 20ms instead of the 1.1s > > Erlang + OTP takes (on the same machine) then you're up and running, not > OTP > > but a with a code loader and simple I/O system. > > Book ordered. > > The prospect of getting off the OTP facility is very appealing. If > it's that trivial to get the same features without incurring the cost > of those modules, I'm in. > No - it is absolutely not trivial to get the same features as OTP. If you get the same features as OTP then you'll have to reimplement OTP. It is easy to get something that starts really quickly, loads code but which does *not* have all the OTP goodies. What *is* a problem is the blind adherence to OTP patterns when these are not appropriate. The problem is not so much that people follow the OTP design principles, but that they follow them in situations where it is inappropriate. Unfortunately it takes a while before you know which approach is best. You have to code up a solution to a problem with and without the OTP libraries. For example write a server using gen_server and without gen_server and see which is best. Note that most books start with how to write a server *without* gen_server. Writing a statefull server *without* gen_server is really easy: loop(State) -> receive {From, F} -> {Reply, State1} = F(State), From ! {self(), Reply}, loop(State1) end. With rpc(Pid, Q) -> Pid ! {self(), Q}, receive {Pid, Reply} -> Reply end The above code is basically all that gen_server does. gen_server just adds a few goodies to stop you shooting yourself in the foot. Now take pure libraries as an example - these are in pure Erlang, no registered process, no supervision. I've often seen these built together with the entire application infrastructure. If it's a pure library there is absolutely no reason to do application:start(blaa) etc. and make an application for this - unless (and this is a big unless) - unless you want to make a strictly compliant OTP application and dynamically unload and reload the code at run time. In the vast majority of cases this is totally unnecessary and letting the dynamic code loader do it's job will suffice. In the very rare case that you actually do want to strictly manage your code in an environment that is designed to *never* be stopped then you need the application structure - but this can be added at the very end of the development processes. Getting the process structure clear without regard to the OTP libraries is far more important. I've also see cases where code really does not fit the OTP behaviours, the code is ugly and unnatural - a clear sign that the underlying libraries should not be used. The entire OTP infrastructure was designed for enterprise systems that should *never* go down. It was NOT designed for shell scripting, programs where taking the service down for a quick reboot is not a problem. We can reboot an erlang system rather quickly (under 2 seconds, I guess) - If you can live with this then you can forget about release upgrades etc. Only very demanding systems need the release upgrade stuff. > > I think the needle could move here. > > I think that something like e2 with less ceremony than OTP would be great. There seems to be a gap: OTP => targeted for enterprise grade 24x7 stuff ?? => can take system out of service for a few seconds occasionally escripts => quick and dirty shell scripts The ??? is not well served. Something like e2 with a quick-start and packaging facility Using OTP with all the release/application/supervisor stuff is building enterprise grade software for non-enterprise grade applications - which really is using a battleship to crack a walnut. Problem is we don't have a simple nutcracker. Cheers /Joe > Garrett > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tristan.sloughter@REDACTED Thu Feb 13 22:49:58 2014 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Thu, 13 Feb 2014 13:49:58 -0800 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> Message-ID: <1392328198.23981.83158685.453F6BD0@webmail.messagingengine.com> Sounds similar to what I've thought worked as an analogy, but also feel threatens to get me beat up, that OTP is sort of to Erlang as J2EE is to Java. But way better in both time to get started and results :) On Thu, Feb 13, 2014, at 01:43 PM, Joe Armstrong wrote: On Thu, Feb 13, 2014 at 8:02 PM, Garrett Smith <[1]g@REDACTED> wrote: On Thu, Feb 13, 2014 at 12:15 PM, Joe Armstrong <[2]erlang@REDACTED> wrote: > > On Thu, Feb 13, 2014 at 10:51 AM, Garrett Smith <[3]g@REDACTED> wrote: >> >> Sigh. This *is* confusing. It just is. >> >> Lo?c you *cannot* use Erlang without OTP. The VM starts a system, >> which consists of applications, which are supervisory trees of >> gen_servers. > > This is wrong - you can use Erlang without OTP. > > OTP loads 60 odd modules, starts a code server and some other stuff and > *then* executes your code. > > You can "easily" roll your own system that uses far fewer modules and gets > you up > and running, but then you don't get the shell, the code loader and a load of > other goodies. > > Appendix 3 of the 2'nd edition of Programming Erlang tells you *exactly* how > to do this. > > To summarise Appendix 3 - I load 3 modules in 20ms instead of the 1.1s > Erlang + OTP takes (on the same machine) then you're up and running, not OTP > but a with a code loader and simple I/O system. Book ordered. The prospect of getting off the OTP facility is very appealing. If it's that trivial to get the same features without incurring the cost of those modules, I'm in. No - it is absolutely not trivial to get the same features as OTP. If you get the same features as OTP then you'll have to reimplement OTP. It is easy to get something that starts really quickly, loads code but which does *not* have all the OTP goodies. What *is* a problem is the blind adherence to OTP patterns when these are not appropriate. The problem is not so much that people follow the OTP design principles, but that they follow them in situations where it is inappropriate. Unfortunately it takes a while before you know which approach is best. You have to code up a solution to a problem with and without the OTP libraries. For example write a server using gen_server and without gen_server and see which is best. Note that most books start with how to write a server *without* gen_server. Writing a statefull server *without* gen_server is really easy: loop(State) -> receive {From, F} -> {Reply, State1} = F(State), From ! {self(), Reply}, loop(State1) end. With rpc(Pid, Q) -> Pid ! {self(), Q}, receive {Pid, Reply} -> Reply end The above code is basically all that gen_server does. gen_server just adds a few goodies to stop you shooting yourself in the foot. Now take pure libraries as an example - these are in pure Erlang, no registered process, no supervision. I've often seen these built together with the entire application infrastructure. If it's a pure library there is absolutely no reason to do application:start(blaa) etc. and make an application for this - unless (and this is a big unless) - unless you want to make a strictly compliant OTP application and dynamically unload and reload the code at run time. In the vast majority of cases this is totally unnecessary and letting the dynamic code loader do it's job will suffice. In the very rare case that you actually do want to strictly manage your code in an environment that is designed to *never* be stopped then you need the application structure - but this can be added at the very end of the development processes. Getting the process structure clear without regard to the OTP libraries is far more important. I've also see cases where code really does not fit the OTP behaviours, the code is ugly and unnatural - a clear sign that the underlying libraries should not be used. The entire OTP infrastructure was designed for enterprise systems that should *never* go down. It was NOT designed for shell scripting, programs where taking the service down for a quick reboot is not a problem. We can reboot an erlang system rather quickly (under 2 seconds, I guess) - If you can live with this then you can forget about release upgrades etc. Only very demanding systems need the release upgrade stuff. I think the needle could move here. I think that something like e2 with less ceremony than OTP would be great. There seems to be a gap: OTP => targeted for enterprise grade 24x7 stuff ?? => can take system out of service for a few seconds occasionally escripts => quick and dirty shell scripts The ??? is not well served. Something like e2 with a quick-start and packaging facility Using OTP with all the release/application/supervisor stuff is building enterprise grade software for non-enterprise grade applications - which really is using a battleship to crack a walnut. Problem is we don't have a simple nutcracker. Cheers /Joe Garrett _______________________________________________ erlang-questions mailing list [4]erlang-questions@REDACTED [5]http://erlang.org/mailman/listinfo/erlang-questions -- Tristan Sloughter tristan.sloughter@REDACTED References 1. mailto:g@REDACTED 2. mailto:erlang@REDACTED 3. mailto:g@REDACTED 4. mailto:erlang-questions@REDACTED 5. http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Thu Feb 13 22:34:05 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Thu, 13 Feb 2014 16:34:05 -0500 Subject: [erlang-questions] [off topic] Re: Time for OTP to be Renamed? In-Reply-To: References: <52FCA60D.9020904@ninenines.eu> <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <28AAEE0D-905F-4681-B388-7C883CCBA7D3@gmail.com> <796EBF0D-8EE3-446F-AEB0-DEF64701311F@jkemp.net> <52FD0D48.9010802@jkemp.net> Message-ID: <52FD3A4D.3000306@meetinghouse.net> Mahesh Paolini-Subramanya wrote: > ?Don?t Feed The Trolls? > > That is all > > Me, I?m off for some well-deserved mortadella and lambrusco? > > > *Talk about trolling *- some of us (probably a lot of us) are snowed in at the moment (possibly why we're bothering to feed trolls). Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From ivan@REDACTED Thu Feb 13 22:51:01 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Thu, 13 Feb 2014 21:51:01 +0000 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <52FD3108.4000508@ninenines.eu> References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FD3108.4000508@ninenines.eu> Message-ID: <0703D9B6-F81E-448F-BEDE-64207BEAA48C@llaisdy.com> Dear Lo?c Please pardon my hopping over from another thread. > On 13 Feb 2014, at 20:54, Lo?c Hoguin wrote: ... > ... few people use release upgrades for example... What are the good reasons for not using release upgrades? I am full of n00bish enthusiasm for them. Thanks Ivan -- festina lente From essen@REDACTED Thu Feb 13 22:54:40 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 13 Feb 2014 22:54:40 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <0703D9B6-F81E-448F-BEDE-64207BEAA48C@llaisdy.com> References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FD3108.4000508@ninenines.eu> <0703D9B6-F81E-448F-BEDE-64207BEAA48C@llaisdy.com> Message-ID: <52FD3F20.5040504@ninenines.eu> They are very hard to get right. Upgrading a live system is really difficult, even with OTP. There are many ways things can go wrong, from the new code breaking things to your state being partially lost (worse than losing all of it!) while upgrading it. It requires a lot of testing to get right, and as such is eating up a lot of time. A 2 minutes change can easily take you 2 hours to test and make sure the upgrade will actually work as intended. On 02/13/2014 10:51 PM, Ivan Uemlianin wrote: > Dear Lo?c > > Please pardon my hopping over from another thread. > >> On 13 Feb 2014, at 20:54, Lo?c Hoguin wrote: > ... >> ... few people use release upgrades for example... > > What are the good reasons for not using release upgrades? I am full of n00bish enthusiasm for them. > > Thanks > > Ivan > > > -- > festina lente > -- Lo?c Hoguin http://ninenines.eu From ivan@REDACTED Thu Feb 13 23:23:29 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Thu, 13 Feb 2014 22:23:29 +0000 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <52FD3F20.5040504@ninenines.eu> References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FD3108.4000508@ninenines.eu> <0703D9B6-F81E-448F-BEDE-64207BEAA48C@llaisdy.com> <52FD3F20.5040504@ninenines.eu> Message-ID: <9DB00C13-29C7-4EF4-952B-B8DB02719F51@llaisdy.com> Dear Lo?c Thanks. I need to do some detailed experiments with release packaging & upgrading. I can certainly see that upgrades affecting how state is represented might be simpler done offline. Best wishes Ivan -- festina lente > On 13 Feb 2014, at 21:54, Lo?c Hoguin wrote: > > They are very hard to get right. Upgrading a live system is really difficult, even with OTP. There are many ways things can go wrong, from the new code breaking things to your state being partially lost (worse than losing all of it!) while upgrading it. > > It requires a lot of testing to get right, and as such is eating up a lot of time. A 2 minutes change can easily take you 2 hours to test and make sure the upgrade will actually work as intended. > >> On 02/13/2014 10:51 PM, Ivan Uemlianin wrote: >> Dear Lo?c >> >> Please pardon my hopping over from another thread. >> >>> On 13 Feb 2014, at 20:54, Lo?c Hoguin wrote: >> ... >>> ... few people use release upgrades for example... >> >> What are the good reasons for not using release upgrades? I am full of n00bish enthusiasm for them. >> >> Thanks >> >> Ivan >> >> >> -- >> festina lente > > -- > Lo?c Hoguin > http://ninenines.eu From ok@REDACTED Thu Feb 13 23:51:00 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 14 Feb 2014 11:51:00 +1300 Subject: [erlang-questions] beginner: xmerl:export_simple/2 wihtout changing > into > In-Reply-To: <8565445F-D95D-4847-8755-DEC519F0603F@gmail.com> References: <1392293573.4863.11.camel@sekic1152.release> <8565445F-D95D-4847-8755-DEC519F0603F@gmail.com> Message-ID: On 14/02/2014, at 1:20 AM, Anthony Ramine wrote: > No. That would be invalid XML, not even well-formed, even. > > Why would an XML implementation allow you to generate ill-formed XML? Let's see. XML fifth edition. Rule 9: an attribute value may not contain a less than sign, but there is no problem with greater than signs. Rule 14: character data may not contain a less than sign and it may not contain the sequence ']]>', but there is no restriction on greater than signs that are NOT preceded by two right brackets. Rule 20: a CDATA section may not contain the sequence ']]>' and there is no way to escape any of those characters, so even _after_ parsing a CDATA section may not contain ']]>'. But there is no other restriction on greater than signs. In particular,

"Some text with >"

and "]]> would appear to be perfectly legal. However, - the general difficulty of ensuring that ]]> does not occur and the absence of a predefined name for ']' makes it a good idea to always replace > by > - any XML tool chain that makes a program *have* to be aware of a distinction between

"Some text with >"

and

"Some text with >"

is one that I would have to be paid millions of dollars to use. So in short, how could anyone possibly "need" to keep '>' as '>' rather than '>' or '>'? Not many people are aware of the illegality of ]]> in plain text. None of the XML parsers I use is aware of it. But it has always been illegal according to the XML specifications. From ph@REDACTED Fri Feb 14 00:14:44 2014 From: ph@REDACTED (Pieter Hintjens) Date: Fri, 14 Feb 2014 00:14:44 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <9DB00C13-29C7-4EF4-952B-B8DB02719F51@llaisdy.com> References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FD3108.4000508@ninenines.eu> <0703D9B6-F81E-448F-BEDE-64207BEAA48C@llaisdy.com> <52FD3F20.5040504@ninenines.eu> <9DB00C13-29C7-4EF4-952B-B8DB02719F51@llaisdy.com> Message-ID: I'm sorry for adding to a thread so long that the scroll bar on my browser broke and I had to revert to Mutt. The C language had for many years a separate set of tools called "libraries". At some stage a set of these became "standard" and were incorporated into the ANSI definition of the language. The libraries still exist, with their original weird names. However we don't speak of C / stdlib. We speak of C99, perhaps. It's not about killing OTP and/or changing its name to something sexier. It's about accepting that this is a standard part of the language and can be removed from the front of the stage. Simpler is almost always better. On Thu, Feb 13, 2014 at 11:23 PM, Ivan Uemlianin wrote: > Dear Lo?c > > Thanks. > > I need to do some detailed experiments with release packaging & upgrading. I can certainly see that upgrades affecting how state is represented might be simpler done offline. > > Best wishes > > Ivan > > -- > festina lente > > >> On 13 Feb 2014, at 21:54, Lo?c Hoguin wrote: >> >> They are very hard to get right. Upgrading a live system is really difficult, even with OTP. There are many ways things can go wrong, from the new code breaking things to your state being partially lost (worse than losing all of it!) while upgrading it. >> >> It requires a lot of testing to get right, and as such is eating up a lot of time. A 2 minutes change can easily take you 2 hours to test and make sure the upgrade will actually work as intended. >> >>> On 02/13/2014 10:51 PM, Ivan Uemlianin wrote: >>> Dear Lo?c >>> >>> Please pardon my hopping over from another thread. >>> >>>> On 13 Feb 2014, at 20:54, Lo?c Hoguin wrote: >>> ... >>>> ... few people use release upgrades for example... >>> >>> What are the good reasons for not using release upgrades? I am full of n00bish enthusiasm for them. >>> >>> Thanks >>> >>> Ivan >>> >>> >>> -- >>> festina lente >> >> -- >> Lo?c Hoguin >> http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From andrew.j.stone.1@REDACTED Fri Feb 14 00:28:45 2014 From: andrew.j.stone.1@REDACTED (Andrew Stone) Date: Thu, 13 Feb 2014 18:28:45 -0500 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FD3108.4000508@ninenines.eu> <0703D9B6-F81E-448F-BEDE-64207BEAA48C@llaisdy.com> <52FD3F20.5040504@ninenines.eu> <9DB00C13-29C7-4EF4-952B-B8DB02719F51@llaisdy.com> Message-ID: http://www.youtube.com/watch?v=C3JzbWVDzac On Thu, Feb 13, 2014 at 6:14 PM, Pieter Hintjens wrote: > I'm sorry for adding to a thread so long that the scroll bar on my > browser broke and I had to revert to Mutt. > > The C language had for many years a separate set of tools called > "libraries". At some stage a set of these became "standard" and were > incorporated into the ANSI definition of the language. The libraries > still exist, with their original weird names. However we don't speak > of C / stdlib. We speak of C99, perhaps. > > It's not about killing OTP and/or changing its name to something > sexier. It's about accepting that this is a standard part of the > language and can be removed from the front of the stage. > > Simpler is almost always better. > > > On Thu, Feb 13, 2014 at 11:23 PM, Ivan Uemlianin wrote: > > Dear Lo?c > > > > Thanks. > > > > I need to do some detailed experiments with release packaging & > upgrading. I can certainly see that upgrades affecting how state is > represented might be simpler done offline. > > > > Best wishes > > > > Ivan > > > > -- > > festina lente > > > > > >> On 13 Feb 2014, at 21:54, Lo?c Hoguin wrote: > >> > >> They are very hard to get right. Upgrading a live system is really > difficult, even with OTP. There are many ways things can go wrong, from the > new code breaking things to your state being partially lost (worse than > losing all of it!) while upgrading it. > >> > >> It requires a lot of testing to get right, and as such is eating up a > lot of time. A 2 minutes change can easily take you 2 hours to test and > make sure the upgrade will actually work as intended. > >> > >>> On 02/13/2014 10:51 PM, Ivan Uemlianin wrote: > >>> Dear Lo?c > >>> > >>> Please pardon my hopping over from another thread. > >>> > >>>> On 13 Feb 2014, at 20:54, Lo?c Hoguin wrote: > >>> ... > >>>> ... few people use release upgrades for example... > >>> > >>> What are the good reasons for not using release upgrades? I am full > of n00bish enthusiasm for them. > >>> > >>> Thanks > >>> > >>> Ivan > >>> > >>> > >>> -- > >>> festina lente > >> > >> -- > >> Lo?c Hoguin > >> http://ninenines.eu > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.j.stone.1@REDACTED Fri Feb 14 00:32:05 2014 From: andrew.j.stone.1@REDACTED (Andrew Stone) Date: Thu, 13 Feb 2014 18:32:05 -0500 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> <52FD3108.4000508@ninenines.eu> <0703D9B6-F81E-448F-BEDE-64207BEAA48C@llaisdy.com> <52FD3F20.5040504@ninenines.eu> <9DB00C13-29C7-4EF4-952B-B8DB02719F51@llaisdy.com> Message-ID: To clarify, that was not named at Pieter, just the general discussion about naming of a 20 year old framework. Also, my name is my name. On Thu, Feb 13, 2014 at 6:28 PM, Andrew Stone wrote: > http://www.youtube.com/watch?v=C3JzbWVDzac > > > On Thu, Feb 13, 2014 at 6:14 PM, Pieter Hintjens wrote: > >> I'm sorry for adding to a thread so long that the scroll bar on my >> browser broke and I had to revert to Mutt. >> >> The C language had for many years a separate set of tools called >> "libraries". At some stage a set of these became "standard" and were >> incorporated into the ANSI definition of the language. The libraries >> still exist, with their original weird names. However we don't speak >> of C / stdlib. We speak of C99, perhaps. >> >> It's not about killing OTP and/or changing its name to something >> sexier. It's about accepting that this is a standard part of the >> language and can be removed from the front of the stage. >> >> Simpler is almost always better. >> >> >> On Thu, Feb 13, 2014 at 11:23 PM, Ivan Uemlianin >> wrote: >> > Dear Lo?c >> > >> > Thanks. >> > >> > I need to do some detailed experiments with release packaging & >> upgrading. I can certainly see that upgrades affecting how state is >> represented might be simpler done offline. >> > >> > Best wishes >> > >> > Ivan >> > >> > -- >> > festina lente >> > >> > >> >> On 13 Feb 2014, at 21:54, Lo?c Hoguin wrote: >> >> >> >> They are very hard to get right. Upgrading a live system is really >> difficult, even with OTP. There are many ways things can go wrong, from the >> new code breaking things to your state being partially lost (worse than >> losing all of it!) while upgrading it. >> >> >> >> It requires a lot of testing to get right, and as such is eating up a >> lot of time. A 2 minutes change can easily take you 2 hours to test and >> make sure the upgrade will actually work as intended. >> >> >> >>> On 02/13/2014 10:51 PM, Ivan Uemlianin wrote: >> >>> Dear Lo?c >> >>> >> >>> Please pardon my hopping over from another thread. >> >>> >> >>>> On 13 Feb 2014, at 20:54, Lo?c Hoguin wrote: >> >>> ... >> >>>> ... few people use release upgrades for example... >> >>> >> >>> What are the good reasons for not using release upgrades? I am full >> of n00bish enthusiasm for them. >> >>> >> >>> Thanks >> >>> >> >>> Ivan >> >>> >> >>> >> >>> -- >> >>> festina lente >> >> >> >> -- >> >> Lo?c Hoguin >> >> http://ninenines.eu >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nem@REDACTED Fri Feb 14 00:56:43 2014 From: nem@REDACTED (Geoff Cant) Date: Thu, 13 Feb 2014 15:56:43 -0800 Subject: [erlang-questions] How many processes do you run in your BEAM? Message-ID: I'm curious how many processes people have luck with running in their BEAM vm. The Logplex cluster at work is running R16B02 with the following stats: (rq = run queue length, procs = number of processes, otp = version number - these figures are reported machine by machine every minute aggregated over 15 minutes) avg(rq) avg(procs) stdev(rq) stdev(procs) max(rq) max(procs) mode(otp) 97.792722 50676.159810 74.305638 185.676264 267 50963 R16B02 Are there known scaling limits for the schedulers? Are there guidelines for common problems (our avg(rq) becomes greater than some threshold, or as a ratio over avg(procs) it crosses a threshold)? Curiously, -- Geoff From rickard@REDACTED Fri Feb 14 01:43:23 2014 From: rickard@REDACTED (Rickard Green) Date: Fri, 14 Feb 2014 01:43:23 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: <52F4C173.8050408@erlang.org> Message-ID: >> When branching out, we add ".1" at the end of .., unless >> this version number has already been used. If it has already been >> used, we search for an unused version number by adding more and more >> ".0" between the version we are branching from, and the ".1" that we >> add at the end. For example, 17.0.1.1, 17.0.1.0.1, 17.0.1.0.0.1, and >> 17.0.1.0.0.0.1 are all versions of modifications based on version >> 17.0.1. > > I can follow the rest of your email, but can you provide some real > life examples for the case of inserting 0 upon branching? The version numbers above would be used if we need to publish four separate fixes and: - each one of them needs to be based on 17.0.1 - 17.0.2 has already been published - each fix is only allowed to include specific changes Another scenario could be that we need to publish a sequence of four fixes and: - the first fix needs to be based on 17.0.1 - 17.0.2 has already been published In this case we would use versions 17.0.1.1, 17.0.1.2, 17.0.1.3, and 17.0.1.4. >From time to time we have requirements like this, however, not to nearly as extreme as having to branch four times from the same version. Regards, Rickard Green, Erlang/OTP, Ericsson AB. From ok@REDACTED Fri Feb 14 02:01:00 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 14 Feb 2014 14:01:00 +1300 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> Message-ID: <0E0A3B89-000D-4CCA-8957-1770158CCA62@cs.otago.ac.nz> On 14/02/2014, at 1:50 AM, Magnus Henoch wrote: > Anthony Ramine writes: > >> Why do you want to do that? >> >> An HTML document with a single ? > ? in the middle of nowhere is not valid nor well-formed HTML. > > It is in fact valid HTML. Note that while is legal XML, is not. Now there's a rather unpleasant difference between HTML and XHTML here. The content model for must work. But in HTML, the content model is CDATA, which means that character and entity references are not allowed, or rather than things that *look* like character and entity references are just plain characters passed straight through. So in HTML, passes '&' 'g' 't' ';' through to the Javascript processor. But remember, ']]>' is *still* illegal, and so is ' and < but you *can't*. The basic issue here is that xmerl supports *XML*. Using xmerl to generate HTML (as opposed to XHTML) is not unlike trying to write C code using a program designed to make writing Javascript easy. This is compounded by the fact that a number of current browsers do not understand XHTML 1.1 and treat the CDATA sections are recognized by the XML processor and appear as nodes in the Document Object Model, see Section 1.3 of the DOM Level 1 Recommendation [DOM]. An alternative is to use external script and style documents. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Erik Naggum waxed vehement against the use of CDATA content models, and boy was he right. Joe English pointed out that is not legal in HTML, because it contains the ' element at that point, so you get ") so you have to write document.write("

", "Foo", "<"+"/h1>") Did I mention that the rules are subtly and importantly different in HTML 4 and HTML 5, to the point where a document can conform to HTML 5 but not HTML 4, not for structural but for lexical reasons? This whole area is a MESS and it is precisely the kind of mess that XML was supposed to get us out of. If people are going to generate HTML5, we need something where you can write {raw_text_element,Name,Attributes,Text} and have it *checked* that the "poison" sequences do not occur. From ok@REDACTED Fri Feb 14 03:02:37 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 14 Feb 2014 15:02:37 +1300 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <52FCD730.803@gmail.com> References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> <1392296152.4863.22.camel@sekic1152.release> <1392300761.4863.30.camel@sekic1152.release> <52FCD730.803@gmail.com> Message-ID: <1E4C719B-B0D4-48A8-96CC-D69D65531207@cs.otago.ac.nz> On 14/02/2014, at 3:31 AM, Richard Carlsson wrote: > Out of curiosity, if it had been < instead, which of the following would work? > > if (i < 0) { That should work in XHTML but not HTML. > > if (i < 0) { That should work in HTML but not XHTML. XHTML is an application of XML. It declares and we have [14] CharData ::= [^<&]* - ([*<&]* ']]>' [^<&]*) That is, a chunk of character data is any run of characters not containing '<' or '&' or ']]>'. The ampersand character (&) and the left angle bracket (<) MUST NOT appear in their literal form, except when used as markup delimiters, or within a comment, a processing instruction, or a CDATA section. If they are needed elsewhere, they MUST be escaped using either numeric character references or the strings "&" and "<" respectively. The right angle bracket (>) may be represented using the string ">", and MUST, for compatibility, be escaped using either ">" or a character reference when it appears in the string "]]>" in content, when that string is not marking the end of a CDATA section. #PCDATA may also contain entity references (<), character references (<), comments, > > If it is the first case, there is presumably a very specific rule for this, The legality of "i < 0" in XHTML falls out of general rules and the content model of the > > Ivan > > > On 13/02/2014 14:54, Bengt Kleberg wrote: > > Yes, the Javascript could be in a separate file that I would generate. > > > > Is it possible to do some sort of "-include()" from the HTML? > > > > > > bengt > > > > On Thu, 2014-02-13 at 14:46 +0000, Ivan Uemlianin wrote: > >> Does all of the javascfript have to be generated dynamically from the > >> erlang? Or could you have a static javascript file for most or all of it? > >> > >> Ivan > >> > >> > >> On 13/02/2014 14:43, Bengt Kleberg wrote: > >>> The use-case is not supposed to include XML. > >>> > >>> My Erlang server creates a log file. A python script generates HTML from > >>> the log file. I now consider generating the HTML directly from Erlang > >>> since I have to call upon another person to fix the python script every > >>> time the log file format changes. Only the log file format changes, the > >>> neccessary contents are still present in the Erlang server. > >>> > >>> My previous method of HTML generation has been to use xmerl. If I do > >>> that now then the Javascript part of the HTML will not run. > >>> > >>> > >>> bengt > >>> > >>> On Thu, 2014-02-13 at 15:31 +0100, Richard Carlsson wrote: > >>>> On 2014-02-13 15:12 , Bengt Kleberg wrote: > >>>>> My problem is that Javascript in the HTML file look like this (when > >>>>> created by xmerl): > >>>>> > >>>>> if (i > 0) { > >>>>> > >>>>> and that does not run. > >>>> > >>>> Out of curiosity, if it had been < instead, which of the following would > >>>> work? > >>>> > >>>> if (i < 0) { > >>>> > >>>> if (i < 0) { > >>>> > >>>> If it is the first case, there is presumably a very specific rule for > >>>> this, which doesn't do full handling of XML escape sequences on the > >>>> source code level (since > didn't work). Which seems moronic, but > >>>> wouldn't surprise me... > >>>> > >>>> If it's the second case, how is the script text really supposed to be > >>>> handled by XML tools? As CDATA (then, how is it delimited?) or as normal > >>>> XML text (and then how can the < be accepted by the parser, and why > >>>> wasn't > converted to > before the Javascript parser got hold of the > >>>> text)? > >>>> > >>>> /Richard > >>>> > >>>> _______________________________________________ > >>>> erlang-questions mailing list > >>>> erlang-questions@REDACTED > >>>> http://erlang.org/mailman/listinfo/erlang-questions > >>> > >>> _______________________________________________ > >>> erlang-questions mailing list > >>> erlang-questions@REDACTED > >>> http://erlang.org/mailman/listinfo/erlang-questions > >>> > >> > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > From ok@REDACTED Fri Feb 14 06:40:49 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 14 Feb 2014 18:40:49 +1300 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <1392355854.4859.13.camel@sekic1152.release> References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> <1392296152.4863.22.camel@sekic1152.release> <1392300761.4863.30.camel@sekic1152.release> <52FCD730.803@gmail.com> <1392302626.4863.45.camel@sekic1152.release> <52FCDADE.6@llaisdy.com> <1392303286.4863.51.camel@sekic1152.release> <52FCDDF9.2010602@llaisdy.com> <1392355854.4859.13.camel@sekic1152.release> Message-ID: <18E40BA2-EEC9-40B7-9646-808CFB0235D2@cs.otago.ac.nz> On 14/02/2014, at 6:30 PM, Bengt Kleberg wrote: > Including a Javascript file works. > It is not my first choice since I fear the amount of support issues > arising when people send the HTML file in email to somebody else. > Given a solution to that I will use this. This is _already_ the case with HTML files using jQuery or MathJax. If the src attribute is an *absolute* URL this will work; the HTML will move, the JavaScript will stay on your site, and the third parties will keep on getting it from a local cache or your site. From bengt.kleberg@REDACTED Fri Feb 14 06:42:20 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Fri, 14 Feb 2014 06:42:20 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <0E0A3B89-000D-4CCA-8957-1770158CCA62@cs.otago.ac.nz> References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> <0E0A3B89-000D-4CCA-8957-1770158CCA62@cs.otago.ac.nz> Message-ID: <1392356540.4859.17.camel@sekic1152.release> Perhaps it was coincidence, but using xmerl to write HTML has never failed me before. If xmerl can be made to handle Javascript I will continue to use it. It is a good fit to how I think. bengt On Fri, 2014-02-14 at 14:01 +1300, Richard A. O'Keefe wrote: > On 14/02/2014, at 1:50 AM, Magnus Henoch wrote: > > > Anthony Ramine writes: > > > >> Why do you want to do that? > >> > >> An HTML document with a single ? > ? in the middle of nowhere is not valid nor well-formed HTML. > > > > It is in fact valid HTML. > > Note that while > > is legal XML, > > is not. > > Now there's a rather unpleasant difference between HTML > and XHTML here. > > The content model for > must work. > But in HTML, the content model is CDATA, which means that > character and entity references are not allowed, or > rather than things that *look* like character and entity > references are just plain characters passed straight through. > So in HTML, > > passes '&' 'g' 't' ';' through to the Javascript processor. > > But remember, ']]>' is *still* illegal, and so is ' So you *want* to escape > and < but you *can't*. > > > The basic issue here is that xmerl supports *XML*. > Using xmerl to generate HTML (as opposed to XHTML) > is not unlike trying to write C code using a > program designed to make writing Javascript easy. > > This is compounded by the fact that a number of > current browsers do not understand XHTML 1.1 and > treat the > > > should work. > > > You may also try Mochiweb's HTML parser/serializer, which is much > simpler and faster, than xmerl > https://github.com/mochi/mochiweb/blob/master/src/mochiweb_html.erl > > > > Tree = {<<"html">>, [{<<"lang">>, <<"en">>}], > [...child tags...]}, > mochiweb_html:to_html(Tree). > > > But I'm not sure if it escapes special characters. From bengt.kleberg@REDACTED Fri Feb 14 07:04:32 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Fri, 14 Feb 2014 07:04:32 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> <62792D12-B0CC-49B0-9DC8-D6F796277152@gmail.com> <1392300836.4863.31.camel@sekic1152.release> Message-ID: <1392357872.4859.36.camel@sekic1152.release> I tried this with the official company browser(*) and it did not work: bengt (*) Firefox 17 On Thu, 2014-02-13 at 15:20 +0100, Szoboszlay D?niel wrote: > What about wrapping the Javascript code in a section? > The browser shall parse > as < in PCDATA before interpreting it as > Javascript code. > > Daniel > > On Thu, 13 Feb 2014 15:13:56 +0100, Bengt Kleberg > wrote: > > > Javascript needs ">". > > > > > > On Thu, 2014-02-13 at 13:59 +0100, Anthony Ramine wrote: > >> Mmmmh, right. Was thinking about <. > >> > >> That being said, code consuming HTML or XML shouldn?t see a difference, > >> and not escaping could also introduce other bugs, as ]]> is not > >> supposed to appear in content (in XML). This leads us to the original > >> question, which was ? why do you need to do this? ?. > >> > > > > _______________________________________________ > > 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 sdl.web@REDACTED Fri Feb 14 08:40:17 2014 From: sdl.web@REDACTED (Leo Liu) Date: Fri, 14 Feb 2014 15:40:17 +0800 Subject: [erlang-questions] Using erlang from the master branch Message-ID: Hi there, I am using erlang from the master branch (to get wx support on darwin and other goodies). Since the branch is updated frequently I would like to avoid having to install it every time. I add $ERL_TOP/bin to PATH in bash and things seem to work except when building projects with C extensions, for example compiling yaws would fail due to missing .h files. This seems like a common use pattern so I wonder if someone else has solved the problem before? Thanks, Leo From vladdu55@REDACTED Fri Feb 14 09:28:55 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 14 Feb 2014 09:28:55 +0100 Subject: [erlang-questions] IDE: call for feedback Message-ID: Hi all, This time I don't want to get into philosophical discussions, but to try to get some straight feedback. On Fri, Feb 14, 2014 at 6:22 AM, Richard A. O'Keefe wrote: >> - Lack of IDEs (that was your prime concern when you joined these lists) > > I bet the people who worked on Distel and ErlIDE, > amongst others, feel sick every time someone says there > is a lack of IDEs. Thank you for the appreciation, Richard! I can't speak about the developers for other IDEs (and there are several more, depending a bit on what one labels as IDE as opposed to "just some syntax support in an editor"), but I am working hard and doing my best to make erlide something that people will use and will want to use. I know we have users, so erlide can't be all wrong. They are however not as vocal as "the other team", so these discussions get a bit one-sided. To those that have tried erlide and found it inadequate: please let me know what you think is missing, what is bothering you about it, hopefully in not too vague terms (think: what kind of requirements would _you_ like to get?). You can answer at https://erlide.uservoice.com or as issues at https://github.com/erlide/erlide/issues (or here, but maybe not everybody is interested). To everybody else: if you have suggestions and ideas, please let me know about them. This is a much more constructive way of helping IDEs improve, by guiding us (all IDE developers) towards addressing the things that really matter to you. I am only one person working with this at the moment and there's a lot to do (currently there are around 500 open tickets), so not everybody will get an immediate answer, but I promise I do consider carefully all requests. It's not by far as fast as I (or you) would like, but it's going forward. Thank you very much in advance for your input and help! best regards, Vlad From dangud@REDACTED Fri Feb 14 09:30:45 2014 From: dangud@REDACTED (Dan Gudmundsson) Date: Fri, 14 Feb 2014 09:30:45 +0100 Subject: [erlang-questions] Using erlang from the master branch In-Reply-To: References: Message-ID: I just add the needed dirs and links into the src On Fri, Feb 14, 2014 at 8:40 AM, Leo Liu wrote: > Hi there, > > I am using erlang from the master branch (to get wx support on darwin > and other goodies). Since the branch is updated frequently I would like > to avoid having to install it every time. I add $ERL_TOP/bin to PATH in > bash and things seem to work except when building projects with C > extensions, for example compiling yaws would fail due to missing .h > files. > > This seems like a common use pattern so I wonder if someone else has > solved the problem before? > > Thanks, > Leo > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alavrik@REDACTED Fri Feb 14 09:33:27 2014 From: alavrik@REDACTED (Anton Lavrik) Date: Fri, 14 Feb 2014 00:33:27 -0800 Subject: [erlang-questions] httpc considered harmful In-Reply-To: References: Message-ID: On Thu, Feb 13, 2014 at 11:39 AM, Felix Gallo wrote: > I recently ran into a very scary issue that appears to be related to httpc. > > I was hitting a web API millions of times, with varying URLs; e.g., > /users/9000000, /users/9000001, etc., at a rate of around 100-400 > requests/sec, using httpc:request, each request spawned by a different > worker: > > get_user(UserID) -> > get_user_r(UserID, 10). > get_user_r(UserID, 0) -> > io:format("dying because ran out of retries on ~p~n",[UserID]); > get_user_r(UserID, Retries) -> > Url = lists:concat(["http://example.com/users/", UserID]), > Filename = lists:concat(["users/-", UserID, ".json"]), > io:format("requesting user: ~p~n", [UserID]), > case httpc:request(Url) of > {ok, Result} -> > {_, _, Body} = Result, > file:write_file(Filename, Body), > userscrapemaster ! {ok, ClanID}; > {error, Reason} -> > io:format("error for user ~p: ~p~n",[UserID, Reason]), > get_members_r(UserID, Retries - 1) > > A small (< 0.1%) but significant percentage of the time, the httpc:request > call for completely different workers MIXED UP THEIR RESPONSES with other > concurrent requests. > > For example, sometimes /users/5000 returned success but provided the body > that /users/5001 should have returned, and /users/5001 returned the body > that /users/5002 should have returned, and /users/5002 returned the body > that /users/5000 should have returned. Or, /users/5009 returned the > response for /users/5010, and vice versa. > > There appeared to be no obvious pattern except that all those calls were > concurrent, and pragmatically I didn't have the time to go chasing into > httpc to try to figure out where the state was getting scrambled, but as a > test I moved the call over to lhttpc without changing the structure of the > code otherwise, and the mixed responses went away. > > If I get some time I'll try to dig into httpc to understand what happened > there, but as a warning to others: httpc looks like it has a hidden race > condition or other bug, and lhttpc does not. > > I've seen exactly this problem under load as well. HTTP1.1, connection rate was higher, error rate was, I believe, much lower than yours. It was on R14. Switching to lhttpc helped. By the way, I remember someone else mentioning about this problem on the list a few years ago. Anton -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Fri Feb 14 09:52:44 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Fri, 14 Feb 2014 09:52:44 +0100 Subject: [erlang-questions] IDE: call for feedback In-Reply-To: References: Message-ID: <1392367965.4859.44.camel@sekic1152.release> Vlad, Is there anything in those 500 open tickets that is a stand-alone tool/program? I use Acme, not Erlide, but it would be nice to help with any Erlide tool/program that can also be used on its own. bengt On Fri, 2014-02-14 at 09:28 +0100, Vlad Dumitrescu wrote: > Hi all, > > This time I don't want to get into philosophical discussions, but to > try to get some straight feedback. > > On Fri, Feb 14, 2014 at 6:22 AM, Richard A. O'Keefe wrote: > >> - Lack of IDEs (that was your prime concern when you joined these lists) > > > > I bet the people who worked on Distel and ErlIDE, > > amongst others, feel sick every time someone says there > > is a lack of IDEs. > > Thank you for the appreciation, Richard! > > I can't speak about the developers for other IDEs (and there are > several more, depending a bit on what one labels as IDE as opposed to > "just some syntax support in an editor"), but I am working hard and > doing my best to make erlide something that people will use and will > want to use. I know we have users, so erlide can't be all wrong. They > are however not as vocal as "the other team", so these discussions get > a bit one-sided. > > To those that have tried erlide and found it inadequate: please let me > know what you think is missing, what is bothering you about it, > hopefully in not too vague terms (think: what kind of requirements > would _you_ like to get?). You can answer at > https://erlide.uservoice.com or as issues at > https://github.com/erlide/erlide/issues (or here, but maybe not > everybody is interested). > > To everybody else: if you have suggestions and ideas, please let me > know about them. > > This is a much more constructive way of helping IDEs improve, by > guiding us (all IDE developers) towards addressing the things that > really matter to you. > > I am only one person working with this at the moment and there's a lot > to do (currently there are around 500 open tickets), so not everybody > will get an immediate answer, but I promise I do consider carefully > all requests. It's not by far as fast as I (or you) would like, but > it's going forward. > > Thank you very much in advance for your input and help! > > best regards, > Vlad > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vladdu55@REDACTED Fri Feb 14 10:10:36 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 14 Feb 2014 10:10:36 +0100 Subject: [erlang-questions] IDE: call for feedback In-Reply-To: <1392367965.4859.44.camel@sekic1152.release> References: <1392367965.4859.44.camel@sekic1152.release> Message-ID: Hi Bengt, On Fri, Feb 14, 2014 at 9:52 AM, Bengt Kleberg wrote: > Is there anything in those 500 open tickets that is a stand-alone > tool/program? > I use Acme, not Erlide, but it would be nice to help with any Erlide > tool/program that can also be used on its own. Thanks for the offer! I don't think there are any standalone tools. The integration with Eclipse is tight and I don't expect there are many people that are interested in Erlang, know Java, know or want to learn the Eclipse APIs and have some spare time to do so. The tooling on the Erlang side is also depending on our own scanner and parser formats. I will keep this in mind and if there is something that could be developed standalone I will let you know. My vision is to have the core functionality of handling/sorting/changing/munging/filtering/etc source code as separate and independent from Eclipse, so that it can be used by any and all other IDEs. This is still rather far into the future, though, at the current rate of progress. best regards, Vlad From garazdawi@REDACTED Fri Feb 14 10:20:40 2014 From: garazdawi@REDACTED (Lukas Larsson) Date: Fri, 14 Feb 2014 10:20:40 +0100 Subject: [erlang-questions] Using erlang from the master branch In-Reply-To: References: Message-ID: Hello, I use the release folder, eg. export PATH=$ERL_TOP/release/powerpc-unknown-ose/bin:$PATH git pull origin master git clean -xfdq ./otp_build all -a (cd release/powerpc-unknown-ose/ && ./Install -minimal `pwd`) and then if you are feeling daring just do git pull origin master ./otp_build release -a whenever you want to have a new master or scratch it and do a full rebuild. Lukas On Fri, Feb 14, 2014 at 8:40 AM, Leo Liu wrote: > Hi there, > > I am using erlang from the master branch (to get wx support on darwin > and other goodies). Since the branch is updated frequently I would like > to avoid having to install it every time. I add $ERL_TOP/bin to PATH in > bash and things seem to work except when building projects with C > extensions, for example compiling yaws would fail due to missing .h > files. > > This seems like a common use pattern so I wonder if someone else has > solved the problem before? > > Thanks, > Leo > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Fri Feb 14 10:41:24 2014 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 14 Feb 2014 10:41:24 +0100 Subject: [erlang-questions] split Message-ID: I'm sitting here feeling very stupid, can anybody explain to me in terms that a child of five could understand what's going on here: Problem: I want to split a string on repeated occurrences of the string "abc" so split("123abcabc456") should return [<<"123">>,<<"456">>] So I thought I could use re for this: > re:split("123abcabc456", "(abc)+"). [<<"123">>,<<"abc">>,<<"456">>] The manual page says the matching split string is not included in the output - at least that what it appear to me to say. How in the name of the great blue-eyed slimy thing that hides under stones can I get rid of the additional <<"abc">> - this is totally not obvious to me. try again: > re:split("123abcabcabc456", "abc",[notempty]). [<<"123">>,<<>>,<<>>,<<"456">>] I was under the vague impression that <<>> *was* and empty string I knew I hated regular expressions, can't they be outlawed? /Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From aschultz@REDACTED Fri Feb 14 10:53:34 2014 From: aschultz@REDACTED (Andreas Schultz) Date: Fri, 14 Feb 2014 10:53:34 +0100 (CET) Subject: [erlang-questions] split In-Reply-To: References: Message-ID: <1181526876.140475.1392371614114.JavaMail.zimbra@tpip.net> Hi, ----- Original Message ----- > I'm sitting here feeling very stupid, can anybody explain to me in terms that > a child of five could understand what's going on here: REGEX are supposed to make you feel stupid all the time ;-) > Problem: I want to split a string on repeated occurrences of the string > "abc" > > so split("123abcabc456") should return [<<"123">>,<<"456">>] > > So I thought I could use re for this: > > > re:split("123abcabc456", "(abc)+"). > [<<"123">>,<<"abc">>,<<"456">>] Had to try a few things, but this works: > re:split("123abcabcabc456", "(?:abc)+"). [<<"123">>,<<"456">>] This also works: > re:split("123abcabcabc456", "(abc)+",[no_auto_capture]). [<<"123">>,<<"456">>] > The manual page says the matching split string is not included in the > output - at least that what it appear to me to say. > > How in the name of the great blue-eyed slimy thing that hides under stones > can I get rid of the additional <<"abc">> - this is totally not obvious to > me. > > try again: > > > re:split("123abcabcabc456", "abc",[notempty]). > [<<"123">>,<<>>,<<>>,<<"456">>] > > > I was under the vague impression that <<>> *was* and empty string [notempty] is not referring to returned string, but only to match. > I knew I hated regular expressions, can't they be outlawed? No, I like them ;-) > /Joe Andreas -- -- Dipl. Inform. Andreas Schultz From jesper.louis.andersen@REDACTED Fri Feb 14 11:04:58 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 14 Feb 2014 11:04:58 +0100 Subject: [erlang-questions] split In-Reply-To: References: Message-ID: Hi Joe, I hereby accuse you of abusing regular expressions where less will do: 3> [P || P <- binary:split(<<"123abcabc456">>, <<"abc">>, [global]), P /= <<>>]. [<<"123">>,<<"456">>] In Standard ML, there are two token-split operations, http://www.standardml.org/Basis/string.html#SIG:STRING.tokens:VAL the important notion being that the 'tokens' variant omits redundant whitespace (what you want) and 'fields' keeps the whitespace (what you want when parsing e.g., CSV files). The code in e(3) probably doesn't generate a lot of garbage. On Fri, Feb 14, 2014 at 10:41 AM, Joe Armstrong wrote: > I'm sitting here feeling very stupid, can anybody explain to me in terms > that > a child of five could understand what's going on here: > > Problem: I want to split a string on repeated occurrences of the string > "abc" > > so split("123abcabc456") should return [<<"123">>,<<"456">>] > > So I thought I could use re for this: > > > re:split("123abcabc456", "(abc)+"). > [<<"123">>,<<"abc">>,<<"456">>] > > > The manual page says the matching split string is not included in the > output - at least that what it appear to me to say. > > How in the name of the great blue-eyed slimy thing that hides under stones > can I get rid of the additional <<"abc">> - this is totally not obvious to > me. > > try again: > > > re:split("123abcabcabc456", "abc",[notempty]). > [<<"123">>,<<>>,<<>>,<<"456">>] > > > I was under the vague impression that <<>> *was* and empty string > > I knew I hated regular expressions, can't they be outlawed? > > > > /Joe > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Fri Feb 14 11:42:47 2014 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Fri, 14 Feb 2014 11:42:47 +0100 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <1E4C719B-B0D4-48A8-96CC-D69D65531207@cs.otago.ac.nz> References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> <1392296152.4863.22.camel@sekic1152.release> <1392300761.4863.30.camel@sekic1152.release> <52FCD730.803@gmail.com> <1E4C719B-B0D4-48A8-96CC-D69D65531207@cs.otago.ac.nz> Message-ID: <52FDF327.9070307@gmail.com> Thank you. So, to summarize, the interpretation of what's between the tags depends on whether you parse the text as XML or HTML. Some more googling shows that the following is a common idiom to allow the text to be parsed in both ways: The // keeps Javascript from seeing the CDATA start/end markers, HTML ignores them, and XML removes them and passes on everything in between as it is. I think the #xmlText{} record in xmerl (see xmerl.hrl) can be used here to wrap the contents of the tags depends on whether you parse the text as XML > or HTML. Some more googling shows that the following is a common idiom > to allow the text to be parsed in both ways: > > > > The // keeps Javascript from seeing the CDATA start/end markers, HTML > ignores them, and XML removes them and passes on everything in between > as it is. > > I think the #xmlText{} record in xmerl (see xmerl.hrl) can be used here > to wrap the contents of the should work. You may also try Mochiweb's HTML parser/serializer, which is much simpler and faster, than xmerl https://github.com/mochi/mochiweb/blob/master/src/mochiweb_html.erl Tree = {<<"html">>, [{<<"lang">>, <<"en">>}], [...child tags...]}, mochiweb_html:to_html(Tree). But I'm not sure if it escapes special characters. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rory.McKeown@REDACTED Thu Feb 13 19:05:56 2014 From: Rory.McKeown@REDACTED (McKeown, Rory (External)) Date: Thu, 13 Feb 2014 18:05:56 -0000 Subject: [erlang-questions] Time for OTP to be Renamed? Message-ID: <7589326DC369BE4EAACEB3A2EB92F8E3133F2471@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> Re Roberts Last message. Why call Java Java? it's a programming language, not an Island. Why call Linux Linux? it's an operating system, not some made up word. Why would anyone want to learn either when neither is named as what it is? Technology is confusing. But sometimes you have to accept a name is just a name. It's the first hurdle. Now please stop whining about this Rory P.S Please dont reply to this either. I want my mail box free of nonsense. I understand what it takes to be a famous Java programmer now NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named person(s). If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose. We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW From cabo@REDACTED Fri Feb 14 00:32:37 2014 From: cabo@REDACTED (Carsten Bormann) Date: Fri, 14 Feb 2014 00:32:37 +0100 Subject: [erlang-questions] beginner: xmerl:export_simple/2 wihtout changing > into > In-Reply-To: References: <1392293573.4863.11.camel@sekic1152.release> <8565445F-D95D-4847-8755-DEC519F0603F@gmail.com> Message-ID: > In particular, >

"Some text with >"

> and "]]> > would appear to be perfectly legal. Yes. > However, > - the general difficulty of ensuring that ]]> does not occur > and the absence of a predefined name for ']' makes it > a good idea to always replace > by > Well, at least it is the simple thing to do if you can?t match on ]]> and escape only those as ]]> > - any XML tool chain that makes a program *have* to be aware > of a distinction between >

"Some text with >"

> and

"Some text with >"

> is one that I would have to be paid millions of dollars to use. HTML is not an XML tool chain. (The original poster was trying to use xmerl to generate HTML.) HTML was not based on XML, but on the earlier SGML, and has some pretty weird reality for script elements, which cannot be directly expressed in XML (so you have to do weird things to generate something that is both HTML and XML/XHTML). > So in short, how could anyone possibly "need" to keep '>' > as '>' rather than '>' or '>?? Never for actual XML. > Not many people are aware of the illegality of ]]> in plain > text. None of the XML parsers I use is aware of it. But it > has always been illegal according to the XML specifications. If you know about CDATA sections, you should have made that conclusion? I would be very wary of an XML tool that doesn?t implement them. $ echo ' ]]> ' | xmllint - -:1: parser error : Sequence ']]>' not allowed in content ]]> ^ Gr??e, Carsten From devgutt@REDACTED Fri Feb 14 04:45:27 2014 From: devgutt@REDACTED (Gustavo Pires) Date: Thu, 13 Feb 2014 22:45:27 -0500 Subject: [erlang-questions] Time for OTP to be Renamed? Message-ID: I'm new in Erlang as well and I would like to share my feelings about the acronym OTP. This is actually a silly discussion but it was something that bothered me in the beginning, specially because I was not sure that, because of the name Telecom, this would be appropriate for my use case. The problem is, in the beginning, there is so many options that you could consider and Erlang isn't exactly in the mainstream or an easy bet. I could have chosen any language, just because many of them would solve my problem, but I fell in love with Erlang, most because of some chapters of LYSE (thanks Fred!) and the insightful and persuasive posts of Joe. Of course, I'm ashamed to consider dismissing a language only because of the name. But I assure you that was not because of the name _per se_, but because of the sensation that maybe Erlang is a language for Telecom only. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Fri Feb 14 14:38:34 2014 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Fri, 14 Feb 2014 14:38:34 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <52FE02AC.2080706@meetinghouse.net> References: <52FE02AC.2080706@meetinghouse.net> Message-ID: > Seems to me that scarcity is a GOOD thing for Erlang programmers. Java > coders are a dime a dozen (not necessarily good ones, mind you). Folks who > know Erlang are harder to find - should drive the price up. Scarcity means less jobs, less research, less money. This means developers won't be able to work with their favorite language or, if they do, they need to settle for the few available options/companies. > Short version: If I were hiring for a project that was inherently > concurrent, and required 24x7 operation - I'd be LOOKING for Erlang on a > resume. Someone who spent most of their time coding Java would be a > non-starter. The chances are, if a company is building a project that is inherently concurrent, they are doing it in Java, .NET, etc. So while people could look for developers with Erlang in their resume, they would ultimately be hired to work with *something other than Erlang*. And that would actually be a smart career move if you are main concern is money: http://www.itjobswatch.co.uk/default.aspx?page=1&sortby=3&orderby=1&q=Java+erlang&id=0&lid=2618 -------------- next part -------------- An HTML attachment was scrubbed... URL: From federico.carrone@REDACTED Fri Feb 14 14:56:42 2014 From: federico.carrone@REDACTED (Federico Carrone) Date: Fri, 14 Feb 2014 11:56:42 -0200 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: <52F9F306.3090100@ninenines.eu> References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> <1B8F4A98-A99F-414F-A05A-996CCAF56383@cs.otago.ac.nz> <52F94ECC.1000704@ninenines.eu> <12E100E5-38AB-4C74-9A61-CC2A510DCFB5@cs.otago.ac.nz> <52F95D23.7050207@ninenines.eu> <52F9F306.3090100@ninenines.eu> Message-ID: [image: Inline image 1] On Tue, Feb 11, 2014 at 6:53 AM, Lo?c Hoguin wrote: > On 02/11/2014 02:17 AM, Richard A. O'Keefe wrote: > >> Our message crossed. >> >> On 11/02/2014, at 12:13 PM, Lo?c Hoguin wrote: >> >>> >>> Indentation: >>> >>> myfunction(A, B, C, >>> D, E) -> >>> >>> Alignment: >>> >>> myfunction(A, B, C, >>> D, E) -> >>> >> >> I don't call that "alignment", I call that "evil". >> As far as I am concerned, one of the core rules of >> good indentation is >> - the presence or absence of line breaks will >> depend on the size of names and constants >> - but the AMOUNT of indentation never will. >> >> Why? Because indentation is supposed to reveal >> STRUCTURE, not spelling. >> > > I agree. Unfortunately many people align there. > > > I would write this as >> >> my_function( >> A, B, C, D, E >> ) -> >> > > That certainly looks better. > > > -- > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 108637 bytes Desc: not available URL: From thomasl_erlang@REDACTED Fri Feb 14 15:13:43 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Fri, 14 Feb 2014 06:13:43 -0800 (PST) Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> Message-ID: <1392387223.49806.YahooMailNeo@web140104.mail.bf1.yahoo.com> Agreed. Let's start worrying about erlang being too big when it's the size of Python. Or maybe PHP. I just can't see a problem with 10x more erlang projects (open source or otherwise), companies and developers.?Growing the erlang community is a good thing. (By the way, to allay any fears, erlang won't grow by dumbing down, but by solving some set of important problems better than the rest.) Best, Thomas On Friday, February 14, 2014 1:22 PM, Valentin Micic wrote: Seems to me that scarcity is a GOOD thing for Erlang programmers. Java coders are a dime a dozen (not necessarily good ones, mind you). ?Folks who know Erlang are harder to find - should drive the price up. >> > > >Am I the only one seeing how wrong this statement is? >Basic ECON-101 predicts that people buy more of the "stuff", when the "stuff" is cheaper, and, conversely, ?less of the "stuff" when the "stuff" is more expensive; thus, ?the obvious outcome cannot be a "GOOD for thing Erlang programmers", as they would eventually go extinct.? >Or let me rephrase it -- it may be a "GOOD thing for Erlang programmers" until a cheaper alternative is found.? > > >If Erlang is to be taken seriously, it has to be seen to have a value beyond (somewhat myopic) value derived by individual programming mercenaries.? > > >Within the ?organization I work for, we have used Erlang for every project since 2002 (and there's been many projects since, and many more to come). Currently we are on average 30% cheaper than our competitors (that are using Java, etc.) and,?mind you, ?still making a reasonable profit that allowed our organization to grow. > > > > > >>Short version: ?If I were hiring for a project that was inherently concurrent, and required 24x7 operation - I'd be LOOKING for Erlang on a resume. ?Someone who spent most of their time coding Java would be a non-starter. >> > >Indeed, for as long as this project may be realized with reduced cost, as a consequence of being more appropriate than Java equivalent. >But, also, the fact that one knows Erlang, does not mean that such a person knows how to put it to good use. > > >Kind reagards > > >V/ > >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From francesco@REDACTED Fri Feb 14 10:01:09 2014 From: francesco@REDACTED (Francesco Cesarini) Date: Fri, 14 Feb 2014 09:01:09 +0000 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <1392317696.43751.YahooMailNeo@web140106.mail.bf1.yahoo.com> References: <52FCB4EC.8050209@ninenines.eu> <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> <20140213180519.GL62889@ferdair.local> <1392317696.43751.YahooMailNeo@web140106.mail.bf1.yahoo.com> Message-ID: <52FDDB55.1020502@erlang-solutions.com> No, no no Thomas... You can not move away from OTP. It even has its official music video: http://www.youtube.com/watch?v=7VjYUnvnTog On a serious note, I flagged the issues about the T in Telecom when speaking at the Erlang User Conference in 2001. A company in France, working on a Jabber proxy, did not use OTP behaviors or even look at the documentation because they were not developing Telecom products. In the book I'm co-authoring on OTP, the word Telecom will get one mention. In the introduction, alongside a rant over why it is called that way. In the rest of the chapters, it will be an acronym. (BTW, dealing with management and those sitting on the budget on a daily basis, I agree in full with Robert. A marketing hat would at times help). Francesco On 13/02/2014 18:54, Thomas Lindgren wrote: > OK, if the acronym drives your managers nuts, fork it, rename it (how > about "Blue Gorilla", "Customer Yacht" or "Uhuru Scalable Mountain") > and write in the docs that it's based on OTP (tip: below the fold). > I'm sure Erlang Solutions can sell your company Blue Gorilla training > and contractors if you ask them. > > Best, > Thomas > > > On Thursday, February 13, 2014 7:16 PM, kraythe . > wrote: > > I have read portions of your book and appreciate your insight. > However, I think you underestimate the task here. Convincing > developers may be difficult, but if they are good devs they might > come around. Convincing management with control over budget and > staffing when the naming is wrong? Nearly impossible. Thats why > massive advertising companies have made billions off of just > naming things correctly. All of the other concerns you posted are > very legit and I have had and still do have many of them myself. > But those concerns are at the tech level and only of minor > interest to the manager wondering why would he staff for erlang > and not scala or ruby? > > *Robert Simmons Jr. MSc. - Lead Java Architect @ EA* > /Author of: Hardcore Java (2003) and Maintainable Java (2012)/ > /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/ > > > On Thu, Feb 13, 2014 at 12:05 PM, Fred Hebert > wrote: > > Answers inline. > > On 02/13, kraythe . wrote: > > I Guess my answers would be: > > 0) If there is a business case, you can convince them. Low > adoption hurts > > their maintainability and staffing much more than it does > for the startup > > or small company. They are a business, not a bunch of > unreasonable oafs. > > That may be doable. I'm not saying the opposite. > > > 1) Why rewrite the libs if you use the same initials. I > wouldn't worry > > about that. The programming world is replete with examples > of such things. > > If we can use the same initials, then that's gained and > removes a bunch > of issues. > > > 2) and updating the docs will take ... 10 man hours? Do we > not have search > > and replace capable tools? > > 3) Same answer as 2. > > Yes, but we do not have administration rights to mirrors, say > http://erldocs.com/ and translations that can be hosted by the > community. > > The work done with the OTP documentation goes further than the > OTP team > itself. > > > 4) Dont need to "make sure" of anything. If the books want > to be accurate > > they will use the new name, if not "shrug" thats their > problem. Trust me > > someone on amazon will post "Its not called Open Telecom > Platform since > > 2014, it stands for "Open Technology Platform". There are > enough pedantic, > > basement living, people on the internet that will annoy > authors into > > submission. > > That doesn't sound like a pleasant experience for everyone. > Again, it's > not an insurmountable challenge. It's just one more challenge. > > > 5) Small matter of documentation. "It used to be called X > but was renamed > > to Y in 2014" > > Documentation lives on way longer than expected. People still > read and > order reprints of the Erlang book published in 1994 (and 1996 > for the > second edition), some of which are translations. > > Many older versions of books are what is in libraries and > whatnot, since > Joe's first version in early 2000s. For people using these > versions, you > end up with inaccurate terminology regarding half the name of the > language. > > It's a matter of documentation, but it's a matter of trying to > do it > right to reduce the amount of confusion. If people look for "Open > Telecom Platform Erlang" it would be sweet to get the new > documentation > and content. > > Maybe it's easy, but it's still part of a roadmap. > > Alternatively, would 'Open Telecom Platform, a framework that > is not > just about telecoms' going to be more cumbersome in documentation? > > > 6) History is history. Those investigating the language will > get it. It > > startedo ut being a telecoms thing and migrated to a general > language. No > > problem. Live web sites can easily add in blurbs. Old > articles will be out > > of date but not from the time frame of when they were > written. No big deal. > > The sky isnt actually falling. > > I could see that being made as a decision, yes. > > > 7) Obviously this one is just frothing. The man could update > the next > > version of his book with more information, cool tricks, > whatever and sell > > it as a second edition. > > Yes. I like to insert a bit of non-serious content here and there. > > > 8) What "traditional SDK" are you referring to? The LISP > standard lib? ;-) > > Java? C? Ruby? Haskell? Which one is the "normal" one? > Normal is defined in > > the context of the language, not in the context of another > language? In > > fact the vast majority of SDKs for java are third party to > the JDK itself > > anyway. > > I went from this thread's usage of SDK as a similar point to OTP. > Erlang/SDK if you will. If you want to keep it as Erlang/OTP, > that can > work, but needs to be significantly better than what it is > right now to > have an actually measurable impact. > > Otherwise, we're throwing stuff at the wall to see what > sticks, with no > proof that it actually helped anything. > > > 9) Trying to crystal ball the future will only give you a > headache. The key > > is to move from where yo are to a point where progress has > been made and > > recursively loop on that algorithm, not be paralyzed by > "what if .... ?" > > > > Non-serious content here also. Not to be taken seriously, but > I wouldn't > be surprised if it were to happen. > > > You may have been doing Erlang for ages and feel quite the > man but the > > question really boils down to "what would you like for the > future of Erlang > > to be?" If the answer to that in your mind is "A niche > language that I can > > call myself a guru at and everyone looks at me quizzically > and puts up with > > my eccentricity or dare say arrogance." then the current > name and trend is > > fine. If the answer is, "A powerful general purpose > programming language > > for developing applications using functional paradigms and > widely accepted > > as being the solution to the next generation of software > problems." Then > > marketing is important. > > Oh I love that one. I want Erlang to be adopted so much I wrote an > entire book about it and put it online for free, without > advertisement. > This has taken over 3 years of my spare time, because I wanted > Erlang to > be more accessible. I invite you to visit it at > http://learnyousomeerlang.com > , and maybe buy an ebook or > print copy if > you feel like it would be nicer to read that way. If you > prefer a free > electronic copies, there are scripts on github to convert it > to the > kindle format, and a wget line in the FAQ to download a local > copy. > > I also kept writing multiple blog posts at http://ferd.ca > that guide and > show more tutorials about Erlang, use cases, and tries to sell > it as a > language as a whole. > > The reason I'm answering to your suggestion negatively isn't > that I > don't want Erlang to succeed, it's that I do not believe that > changing > the meaning of 'OTP' from 'Open Telecom Platform' to 'Open > Technology > Platform' will have a noticeable impact. > > Some people do ask the question 'but I don't want to do > telecoms', but > in my experience, people's issues are the following, to a much > higher > degree: > > - The syntax is unfamiliar (or ugly) > - It's difficult to work with single assignment, recursion, > immutable > algorithms (most of your algorithm books that rely on arrays > with O(1) > access to work fine are no longer going to be trivial to > translate! > That's huge!) > - The tooling (rebar, relx, etc.) isn't up to par with other > languages, > even if it keeps getting better. > - Lack of IDEs (that was your prime concern when you joined > these lists) > - Fighting the idea that "it will be hard to hire Erlang > developers" to > make it enter and stay in the enterprise. > > All of those criticism, in the years I've been in the Erlang > community, > have come up time and time again. They've also have come up > orders of > magnitude more often than OTP as a name, even if it does come > up from > time to time. > > I'm sorry I came up as harsh. I do want better adoption for > Erlang and > took months if not years of my free time working that way. I > do not > think renaming OTP is worth the effort, but I'll be glad to be > proven > wrong through bigger adoption if someone steps up and decides > to do it. > > Now if you please, I'll go back to spending my lunch time > working on an > post-scripted chapter to the LYSE site introducing maps to people. > > Regards, > Fred. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Erlang Solutions Ltd. http://www.erlang-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From hq@REDACTED Fri Feb 14 15:19:26 2014 From: hq@REDACTED (Adam Rutkowski) Date: Fri, 14 Feb 2014 15:19:26 +0100 Subject: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation In-Reply-To: References: <1BA8E4BA-A221-4A1A-A00C-9734ED6757CD@gmail.com> <1391671154.4877.3.camel@sekic1152.release> <025159A6-F09A-4DD1-B14F-D4B172103D8F@gmail.com> <1391690596.4877.59.camel@sekic1152.release> <3278A097-6003-490D-9689-07B11CEEF347@gmail.com> <1B8F4A98-A99F-414F-A05A-996CCAF56383@cs.otago.ac.nz> <52F94ECC.1000704@ninenines.eu> <12E100E5-38AB-4C74-9A61-CC2A510DCFB5@cs.otago.ac.nz> <52F95D23.7050207@ninenines.eu> <52F9F306.3090100@ninenines.eu> Message-ID: http://thisotplife.tumblr.com/post/76347337005/when-i-see-people-making-a-case-for-tabs-instead-of /A. On Fri, Feb 14, 2014 at 2:56 PM, Federico Carrone < federico.carrone@REDACTED> wrote: > [image: Inline image 1] > > > On Tue, Feb 11, 2014 at 6:53 AM, Lo?c Hoguin wrote: > >> On 02/11/2014 02:17 AM, Richard A. O'Keefe wrote: >> >>> Our message crossed. >>> >>> On 11/02/2014, at 12:13 PM, Lo?c Hoguin wrote: >>> >>>> >>>> Indentation: >>>> >>>> myfunction(A, B, C, >>>> D, E) -> >>>> >>>> Alignment: >>>> >>>> myfunction(A, B, C, >>>> D, E) -> >>>> >>> >>> I don't call that "alignment", I call that "evil". >>> As far as I am concerned, one of the core rules of >>> good indentation is >>> - the presence or absence of line breaks will >>> depend on the size of names and constants >>> - but the AMOUNT of indentation never will. >>> >>> Why? Because indentation is supposed to reveal >>> STRUCTURE, not spelling. >>> >> >> I agree. Unfortunately many people align there. >> >> >> I would write this as >>> >>> my_function( >>> A, B, C, D, E >>> ) -> >>> >> >> That certainly looks better. >> >> >> -- >> Lo?c Hoguin >> http://ninenines.eu >> _______________________________________________ >> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 108637 bytes Desc: not available URL: From mfidelman@REDACTED Fri Feb 14 15:27:46 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Fri, 14 Feb 2014 09:27:46 -0500 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> Message-ID: <52FE27E2.4020709@meetinghouse.net> Jos? Valim wrote: > > Seems to me that scarcity is a GOOD thing for Erlang programmers. > Java coders are a dime a dozen (not necessarily good ones, mind > you). Folks who know Erlang are harder to find - should drive the > price up. > > > Scarcity means less jobs, less research, less money. This means > developers won't be able to work with their favorite language or, if > they do, they need to settle for the few available options/companies. Obviously you don't understand the nature of supply and demand curves. (Check out the demand and prices for Cobol programmers these days, or analog engineers. For that matter, check out the demand for folks who understand microwaves - as soon as computer clock speeds started going up, there was a huge demand for folks who understood waveguide phenomenon - which had practically become a dead art; and then along came cell phones and WiFi). > > Short version: If I were hiring for a project that was inherently > concurrent, and required 24x7 operation - I'd be LOOKING for > Erlang on a resume. Someone who spent most of their time coding > Java would be a non-starter. > > > The chances are, if a company is building a project that is inherently > concurrent, they are doing it in Java, .NET, etc. So while people > could look for developers with Erlang in their resume, they would > ultimately be hired to work with *something other than Erlang*. And > that would actually be a smart career move if you are main concern is > money: > > http://www.itjobswatch.co.uk/default.aspx?page=1&sortby=3&orderby=1&q=Java+erlang&id=0&lid=2618 > Well, to me, a company that is building something that is inherently concurrent, in Java, is a company to run away from. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From jose.valim@REDACTED Fri Feb 14 16:01:30 2014 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Fri, 14 Feb 2014 16:01:30 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <52FE27E2.4020709@meetinghouse.net> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> Message-ID: > > Obviously you don't understand the nature of supply and demand curves. > (Check out the demand and prices for Cobol programmers these days, or > analog engineers. For that matter, check out the demand for folks who > understand microwaves - as soon as computer clock speeds started going up, > there was a huge demand for folks who understood waveguide phenomenon - > which had practically become a dead art; and then along came cell phones > and WiFi). > Cobol expertise and analog engineers are examples of skills that *were* on demand in the past. When I was at university, there was a running joke that if you want to be well paid, you should specialize in Fortran. That's not the case with Erlang. Instead there is a demand for *skills*. So while you are focusing that scarcity is good for the *current developers*, it is not good for the language nor the community because people with skills will move *elsewhere*. They will move to places where there are jobs and the jobs pay well. Just ask how many of the people subscribed to this very mailing list that are actually working with Python, Ruby, PHP, Java, etc in their day jobs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Fri Feb 14 16:10:28 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 14 Feb 2014 16:10:28 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> Message-ID: I am a fraud, I don?t actually do Erlang at work. -- Anthony Ramine Le 14 f?vr. 2014 ? 16:01, Jos? Valim a ?crit : > Just ask how many of the people subscribed to this very mailing list that are actually working with Python, Ruby, PHP, Java, etc in their day jobs. > From essen@REDACTED Fri Feb 14 16:11:25 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 14 Feb 2014 16:11:25 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> Message-ID: <52FE321D.6080404@ninenines.eu> On 02/14/2014 04:01 PM, Jos? Valim wrote: > Just ask how many of the people subscribed to this very mailing list that > are actually working with Python, Ruby, PHP, Java, etc in their day jobs. If they are doing that and have the skills required then they should let themselves known because there are not enough developers and many companies are looking for them and are willing to pay them well above what they currently earn. -- Lo?c Hoguin http://ninenines.eu From ivan@REDACTED Fri Feb 14 16:12:52 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Fri, 14 Feb 2014 15:12:52 +0000 Subject: [erlang-questions] Time for OTP to be Renamed? Message-ID: <096ED64B-133B-4653-85C0-BE95598E3886@llaisdy.com> Python was my day job. Now erlang is my day job. My pay has doubled. Ivan -- festina lente On 14 Feb 2014, at 15:01, Jos? Valim wrote: >> Obviously you don't understand the nature of supply and demand curves. (Check out the demand and prices for Cobol programmers these days, or analog engineers. For that matter, check out the demand for folks who understand microwaves - as soon as computer clock speeds started going up, there was a huge demand for folks who understood waveguide phenomenon - which had practically become a dead art; and then along came cell phones and WiFi). > > Cobol expertise and analog engineers are examples of skills that *were* on demand in the past. When I was at university, there was a running joke that if you want to be well paid, you should specialize in Fortran. That's not the case with Erlang. > > Instead there is a demand for *skills*. So while you are focusing that scarcity is good for the *current developers*, it is not good for the language nor the community because people with skills will move *elsewhere*. They will move to places where there are jobs and the jobs pay well. > > Just ask how many of the people subscribed to this very mailing list that are actually working with Python, Ruby, PHP, Java, etc in their day jobs. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard@REDACTED Fri Feb 14 16:18:59 2014 From: rickard@REDACTED (Rickard Green) Date: Fri, 14 Feb 2014 16:18:59 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: <52F4C173.8050408@erlang.org> Message-ID: fredagen den 14:e februari 2014 skrev Tuncer Ayaz : > On Fri, Feb 14, 2014 at 1:43 AM, Rickard Green wrote: > >>> When branching out, we add ".1" at the end of .., unless > >>> this version number has already been used. If it has already been > >>> used, we search for an unused version number by adding more and more > >>> ".0" between the version we are branching from, and the ".1" that we > >>> add at the end. For example, 17.0.1.1, 17.0.1.0.1, 17.0.1.0.0.1, and > >>> 17.0.1.0.0.0.1 are all versions of modifications based on version > >>> 17.0.1. > >> > >> I can follow the rest of your email, but can you provide some real > >> life examples for the case of inserting 0 upon branching? > > > > The version numbers above would be used if we need to publish four > > separate fixes and: > > - each one of them needs to be based on 17.0.1 > > - 17.0.2 has already been published > > - each fix is only allowed to include specific changes > > So, 'separate' in this case means 'independent' patches, and > therefore: Independent and aren't allowed to be mixed. > > - 17.0.1.0.1 is 17.0.1 + 1st separate patch after 17.0.2 release > > - 17.0.1.0.0.1 is 17.0.1 + 2nd separate patch released next > > - 17.0.1.1 is 17.0.1 + 1st 'normal' patch > > - 17.0.1.2 is 17.0.1 + 2nd 'normal' patch > > Is that correct? No, in the normal case the version number never get more parts than ... If the version number has more parts than this, we've been forced by external requirements to publish the patch. > > > Another scenario could be that we need to publish a sequence of four > > fixes and: > > - the first fix needs to be based on 17.0.1 > > - 17.0.2 has already been published > > In this case we would use versions 17.0.1.1, 17.0.1.2, 17.0.1.3, and > > 17.0.1.4. > > That makes sense. > > > From time to time we have requirements like this, however, not to > > nearly as extreme as having to branch four times from the same > > version. > > Sure, as long as as you don't priorize backport-ability over > refactoring :). > Regards, Rickard Green, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From v@REDACTED Fri Feb 14 16:27:11 2014 From: v@REDACTED (Valentin Micic) Date: Fri, 14 Feb 2014 17:27:11 +0200 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <096ED64B-133B-4653-85C0-BE95598E3886@llaisdy.com> References: <096ED64B-133B-4653-85C0-BE95598E3886@llaisdy.com> Message-ID: <2261C0A4-97D0-4816-B46C-CD3EC09769A2@pharos-avantgard.com> > Python was my day job. Now erlang is my day job. My pay has doubled. Just bear in mind that whilst money is necessary, it will never be sufficient to complete a human being. If you really thinking otherwise, consider yourself lucky. At least for a time being. V/ From abcde@REDACTED Fri Feb 14 16:24:05 2014 From: abcde@REDACTED (Kay) Date: Fri, 14 Feb 2014 16:24:05 +0100 Subject: [erlang-questions] Install R16B03-1 old version? Message-ID: <52FE3515.3090309@kommespaeter.de> I have download and install http://www.erlang.org/download/otp_src_R16B03-1.tar.gz from erlang.org. But install is R15B01, is this OK? From mfidelman@REDACTED Fri Feb 14 16:39:00 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Fri, 14 Feb 2014 10:39:00 -0500 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> Message-ID: <52FE3894.2000003@meetinghouse.net> Jos? Valim wrote: > > Obviously you don't understand the nature of supply and demand > curves. (Check out the demand and prices for Cobol programmers > these days, or analog engineers. For that matter, check out the > demand for folks who understand microwaves - as soon as computer > clock speeds started going up, there was a huge demand for folks > who understood waveguide phenomenon - which had practically become > a dead art; and then along came cell phones and WiFi). > > > Cobol expertise and analog engineers are examples of skills that > *were* on demand in the past. When I was at university, there was a > running joke that if you want to be well paid, you should specialize > in Fortran. That's not the case with Erlang. Actually, the demand for both Cobol and analog engineers is UP. It's absolutely amazing how much legacy Cobol is still around - and guess what, analog is pretty central to consumer electronics. > > Instead there is a demand for *skills*. So while you are focusing that > scarcity is good for the *current developers*, it is not good for the > language nor the community because people with skills will move > *elsewhere*. They will move to places where there are jobs and the > jobs pay well. > > Just ask how many of the people subscribed to this very mailing list > that are actually working with Python, Ruby, PHP, Java, etc in their > day jobs. > Actually, that's an interesting question - what languages ARE people using - of course I'd add Erlang to the list. I'll start.... For myself - not currently programming (doing systems engineering and business development) - when I get my hands dirty, it's more about maintaining some servers from a hosting business I used to run. The general gamut of stuff - more shell scripts than anything else. When I was getting paid to code I was a big fan of picking the right language for the job at hand: Z80 assembler language (embedded machine controllers) - back in the 1970s (today, for machine control, SCADA, and so forth, I'd probably go with ADA) Fortran for number crunching - 1970s and 1980s (today, SQL and Excel spreadsheets; probably go with SPSS or MATLAB for fancy stuff) Perl and PHP for ecommerce sites - 1990s (perl for the packages and CPAN goodness, later HTML, JavaScript - not sure what I'd use today, probably pick a framework and use whatever underlies it) R&D project for the US Army, focused on message-oriented middleware - HTML/JavaScript for the clients; Erlang for the protocol servers (never even considered anything else) - currently on the back burner (our funder lost their funding, our startup felt the pain) Last three times I was an employee, our coders worked in: - C and C++ - military simulators - C++ and Java - GIS applications - .NET - intelligent transportation systems Always wanted to do something in LISP and Smalltalk - but never an application that warranted those sets of capabilities. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From sdl.web@REDACTED Fri Feb 14 16:51:20 2014 From: sdl.web@REDACTED (Leo Liu) Date: Fri, 14 Feb 2014 23:51:20 +0800 Subject: [erlang-questions] httpc considered harmful References: Message-ID: On 2014-02-14 16:33 +0800, Anton Lavrik wrote: > I've seen exactly this problem under load as well. HTTP1.1, connection rate > was higher, error rate was, I believe, much lower than yours. It was on > R14. Switching to lhttpc helped. > > By the way, I remember someone else mentioning about this problem on the > list a few years ago. > > Anton May be a bug could be filed? Leo From jesper.louis.andersen@REDACTED Fri Feb 14 17:00:07 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 14 Feb 2014 17:00:07 +0100 Subject: [erlang-questions] httpc considered harmful In-Reply-To: References: Message-ID: On Fri, Feb 14, 2014 at 4:51 PM, Leo Liu wrote: > May be a bug could be filed? > There should. The problem is to make reproducible test case and figure out the scenario which makes the code answer like this... -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayan@REDACTED Fri Feb 14 17:00:31 2014 From: shayan@REDACTED (Shayan Pooya) Date: Fri, 14 Feb 2014 11:00:31 -0500 Subject: [erlang-questions] httpc considered harmful In-Reply-To: References: Message-ID: We had some issues with httpc in disco project. Using http/1.0 resolvedour issues. Our issues was due to the server closing the tcp connections and httpc sending the next http request on the same tcp connection. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Fri Feb 14 17:05:01 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Fri, 14 Feb 2014 17:05:01 +0100 Subject: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: <52F4C173.8050408@erlang.org> Message-ID: On Fri, Feb 14, 2014 at 4:18 PM, Rickard Green wrote: > > > fredagen den 14:e februari 2014 skrev Tuncer Ayaz: >> >> - 17.0.1.0.1 is 17.0.1 + 1st separate patch after 17.0.2 release >> >> - 17.0.1.0.0.1 is 17.0.1 + 2nd separate patch released next >> >> - 17.0.1.1 is 17.0.1 + 1st 'normal' patch >> >> - 17.0.1.2 is 17.0.1 + 2nd 'normal' patch >> >> Is that correct? > > > No, in the normal case the version number never get more parts than > ... If the version number has more parts than this, we've > been forced by external requirements to publish the patch. You're right, I shouldn't have used the word 'normal', and this was referring to the other unusual case described in your 'four sequential fixes' example. From andreas@REDACTED Fri Feb 14 17:10:39 2014 From: andreas@REDACTED (Andreas Schumacher) Date: Fri, 14 Feb 2014 17:10:39 +0100 Subject: [erlang-questions] FW: Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: <58912684E2630B45963406CF7D8C52581C34A4FA@ESESSMB103.ericsson.se> References: <52F4C173.8050408@erlang.org> <58912684E2630B45963406CF7D8C52581C34A4FA@ESESSMB103.ericsson.se> Message-ID: <52FE3FFF.7040506@erlang.org> We have not considered to avoid -rc [in favor of 17.99.1], nor do we intend to do so. Andreas Schumacher, Erlang/OTP, Ericsson AB > > -----Original Message----- > From: Tuncer Ayaz [mailto:tuncer.ayaz@REDACTED] > Sent: den 13 februari 2014 21:34 > To: Andreas Schumacher > Cc: erlang-questions@REDACTED > Subject: Re: [erlang-questions] Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. > > On Fri, Feb 7, 2014 at 12:20 PM, Andreas Schumacher wrote: > >> A pre-release is denoted with .0-rc, where starts with 1 at >> the delivery of the first pre-release, and is incremented by one for >> each subsequent pre-release. "-rc0" will be used during development up >> to the first release candidate. Pre-releases -rc sort before >> . Apart from -rc, there are no plans for other special parts; >> although that might change if the need arises. > Have you considered avoiding -rc by using a scheme as follows: > > Next stable release: 17.0.0 > Next major release release candidate one: 17.99.1 > > Isn't that simpler to deal with? > >> When branching out, we add ".1" at the end of .., unless this >> version number has already been used. If it has already been used, we >> search for an unused version number by adding more and more ".0" >> between the version we are branching from, and the ".1" that we add at >> the end. For example, 17.0.1.1, 17.0.1.0.1, 17.0.1.0.0.1, and >> 17.0.1.0.0.0.1 are all versions of modifications based on version >> 17.0.1. > I can follow the rest of your email, but can you provide some real life examples for the case of inserting 0 upon branching? From gleber.p@REDACTED Fri Feb 14 17:11:16 2014 From: gleber.p@REDACTED (Gleb Peregud) Date: Fri, 14 Feb 2014 17:11:16 +0100 Subject: [erlang-questions] How many processes do you run in your BEAM? In-Reply-To: References: Message-ID: We did run around 1.7MM processes handling around 850k concurrent TCP connections. Although it was in a stress test environment. 32 cores of the physical server were utilized 85% and more under the stress test. We had spikes in run queue lengths since most of the processes were "activated" with a single broadcast message. But in our case we were able to maintain sub 1s latency for all processes to finish processing of the broadcast message. On Fri, Feb 14, 2014 at 12:56 AM, Geoff Cant wrote: > I'm curious how many processes people have luck with running in their BEAM vm. > > The Logplex cluster at work is running R16B02 with the following stats: (rq = run queue length, procs = number of processes, otp = version number - these figures are reported machine by machine every minute aggregated over 15 minutes) > > avg(rq) avg(procs) stdev(rq) stdev(procs) max(rq) max(procs) mode(otp) > 97.792722 50676.159810 74.305638 185.676264 267 50963 R16B02 > > > Are there known scaling limits for the schedulers? Are there guidelines for common problems (our avg(rq) becomes greater than some threshold, or as a ratio over avg(procs) it crosses a threshold)? > > Curiously, > -- > Geoff > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From davidnwelton@REDACTED Fri Feb 14 17:58:47 2014 From: davidnwelton@REDACTED (David Welton) Date: Fri, 14 Feb 2014 17:58:47 +0100 Subject: [erlang-questions] epgsql coordination? In-Reply-To: <52FD0023.1030406@gmail.com> References: <52FCF18C.30504@gmail.com> <52FD0023.1030406@gmail.com> Message-ID: Hi, Yes, I had missed that, being in a hurry. It's unfortunate that those are necessary - having to change stuff as root just to run some tests does not encourage use of the test suite. On Thu, Feb 13, 2014 at 6:25 PM, Anton Lebedevich wrote: > Did you add lines mentioned in the beginning of test_schema.sql to > pg_hba.conf ? > You'll need to set up ssl authentification for you server using crt and > keys from test_data/. > > On 02/13/2014 09:07 PM, David Welton wrote: >> The output I'm getting, after having run test_schema.sql is: >> >> pgsql_tests: all_test_ (connect_test(pgsql))...*failed* >> in function pgsql_tests:connect_only/2 (test/pgsql_tests.erl, line 711) >> **error:{badmatch,{error,invalid_password}} >> >> >> pgsql_tests: all_test_ (connect_to_db_test(pgsql))...*failed* >> in function pgsql_tests:connect_only/2 (test/pgsql_tests.erl, line 711) >> **error:{badmatch,{error,invalid_password}} >> >> >> pgsql_tests: all_test_ (connect_as_test(pgsql))...*failed* >> in function pgsql_tests:connect_only/2 (test/pgsql_tests.erl, line 711) >> **error:{badmatch,{error,invalid_password}} >> >> >> pgsql_tests: all_test_ (connect_with_ssl_test(pgsql))...*skipped* >> undefined >> *unexpected termination of test process* >> ::{ssl_negotiation_failed,ssl_not_started} >> >> ======================================================= >> Failed: 3. Skipped: 0. Passed: 4. >> One or more tests were cancelled. >> >> =ERROR REPORT==== 13-Feb-2014::18:07:13 === >> ** Generic server <0.57.0> terminating >> ** Last message in was {connect,"localhost","epgsql_test",[], >> [{port,5432}, >> {database,"epgsql_test_db1"}, >> {ssl,true}]} >> ** When Server state == {state,undefined,undefined,<<>>,undefined,undefined, >> {[],[]}, >> undefined,[],[],[],[],[],[],undefined, >> undefined} >> ** Reason for termination == >> ** {ssl_negotiation_failed,ssl_not_started} >> >> On Thu, Feb 13, 2014 at 5:23 PM, Anton Lebedevich wrote: >>> On 02/13/2014 07:51 PM, David Welton wrote: >>>>> Does it make sense to have it shown as a fork? I would suggest pushing a new repo there instead of forking from davidw :) >>>> >>>> I'm not sure how to accomplish that, and to be honest, it is a fork of >>>> my repository which I had forked from mabrek's. It'd be cleaner to >>>> post his as where it was forked from. >>>> >>>> I think the first order of business is to see if I can get the tests >>>> he had in there working 100%. With tests, it gets easier to move >>>> forward without too many worries... >>> >>> Timeout tests are broken in my fork (mabrek/epgsql) because I haven't >>> implemented timeout support yet. Client side timeouts turned out to be >>> quite complicated in asynchronous model. Maybe we need to steal ideas >>> from semiocast/pgsql and use server-side timeouts? >>> >>> These tests pass in original (wg/epgsql) but timeout support is not >>> complete there too (there are situations when connection could stuck >>> after timeout). >>> >>> Regards, >>> Anton Lebedevich. >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> > -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From daniel.goertzen@REDACTED Fri Feb 14 17:59:28 2014 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Fri, 14 Feb 2014 10:59:28 -0600 Subject: [erlang-questions] ANN: nifpp-2.0 Message-ID: nifpp is a C++11 wrapper for the Erlang NIF API. I have updated nifpp to support v17 maps, and I have also removed the requirement to patch "erl_nif.h". A quick nifpp maps example... // create #{abc=>123, pqr=>456} std::map cppmap; cppmap["abc"] = 123; cppmap["pqr"] = 456; ERL_NIF_TERM t = nifpp::make(env, cppmap); See https://github.com/goertzenator/nifpp Nifpp enhances the Erlang NIF API for C++ by providing: - Overloaded get()/make() wrappers for the enif_get_xxx()/enif_make_xxx() C API. - get()/make() support for STL containers tuple, vector, array, list, deque, set, unordered_set, multiset, map, and unordered_map. - get()/make() support for nested containers. - A resource pointer type so that any type can be easily used as a NIF resource. Think of it as a std::shared_ptr that the emulator can hold references to. All feedback welcome, Dan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From baliulia@REDACTED Sat Feb 15 12:57:56 2014 From: baliulia@REDACTED (=?UTF-8?B?SWduYXMgVnnFoW5pYXVza2Fz?=) Date: Sat, 15 Feb 2014 12:57:56 +0100 Subject: [erlang-questions] disconnected nodes In-Reply-To: References: Message-ID: <52FF5644.8030907@gmail.com> Hi Ahmed, On 10/22/2012 06:13 PM, Ahmed Omar wrote: > Hi, We have a cluster of 20+ nodes running R14B04 on Linux Debian > Squeeze. Suddenly we started having problems where 4-5 would drop out > of the cluster and we would see this in the logs > > =ERROR REPORT==== 2012-10-18 10:49:26 === ** Node 'x@REDACTED' not > responding ** ** Removing (timedout) connection ** > > We made a crash dump of some of the nodes and found error_logger has > a queue of these messages > > {notify,{error,noproc, {emulator,"~s~n",["erts_poll_wait() failed: > ebadf (9)\n"]}}} > > Any hints? (other than changing net_kernel net_tick_time) > > Best Regards, Ahmed Sorry to bump this ancient thread, but have you perhaps found a cause for this? We're seeing the same thing during overloads. We're running R15B03 though and additionally to EBADFs get EINVAL failures, i.e.: erts_poll_wait() failed: einval How you maybe figured out anything specific causing the EBADFs? Thanks, Ignas From ph@REDACTED Sat Feb 15 13:01:27 2014 From: ph@REDACTED (Pieter Hintjens) Date: Sat, 15 Feb 2014 13:01:27 +0100 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <52FE3894.2000003@meetinghouse.net> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> Message-ID: On Fri, Feb 14, 2014 at 4:39 PM, Miles Fidelman wrote: > Actually, the demand for both Cobol and analog engineers is UP. Friend of mine was just laid off from a 15-year Cobol job. One can't make general conclusions from small samples. The argument that keeping technology elitist creates wealth is insane and should be laid to rest rapidly. Who here is building new businesses on LU6.2? Right. It was extremely enlightening last week, at a workshop with a medium sized Erlang shop. Opening statement: "We chose Erlang because it lets us build large distributed systems with a small team." Then two full days of, "oh, that's one more serious problem we're facing, caused by how Erlang does things." A technology either lives, by growing and merging with others, or it dies. Erlang is far from being a living technology and survives pretty much thanks to a single dominant customer and investor. It claims to be the best solution for distributed systems, yet is entirely homogeneous, which is also an insane contradiction. Distributed systems by definition must span space and time, or they are LegacyAsAService. Erlang's elitism and lack of broad appeal is the #1 threat to its long term survival. It is frankly the Algol 68 of the telco industry. Awesome language!! Yay!!! To measure market success in terms of "how much can a developer earn" is also so foolish I'm embarrassed to read such views. This is meant to be a list of clever people. For pity's sake. That's like claiming a protocol is valuable because it's so hard to implement. Wealth comes from building up. How can you build up if your basic layers aren't a commodity? There's a million times more wealth built on PHP than Erlang. Real wealth. Erlang needs to shed its telco ties, and get an independent steering committee, and create standards, and multiple implementations, and also reach out to other language communities through distribution protocols like ZMTP, and educate those communities, while also exploiting them and merging with them. Living systems are like the Borg; they grow by merger. Mock Java all you like. It's a hateful language in many ways. But Java programmers know how to work together. There are 6+ different Erlang stacks for ZeroMQ, all one-man projects, all lacking any community. -Pieter From askjuise@REDACTED Sat Feb 15 13:20:04 2014 From: askjuise@REDACTED (Alexander Petrovsky) Date: Sat, 15 Feb 2014 15:20:04 +0300 Subject: [erlang-questions] release upgrades and code loading In-Reply-To: References: <52FD0826.2080305@llaisdy.com> <52FD16FC.10101@llaisdy.com> <2102315A-8B47-4B18-A674-29B5C90C7C83@llaisdy.com> Message-ID: Ivan, by the way for generate appup files you can use genappup - http://www.echorussia.ru/erlang-releases.html 2014-02-13 23:26 GMT+03:00 Ivan Uemlianin : > Paul's interpretation is what I was trying to do with this upgrade. > > Ivan > > -- > festina lente > > > > On 13 Feb 2014, at 20:17, Paul Davis > wrote: > > > > Mike, pretty sure its upgrading two apps to the same version. > > > > app1 is 20140211.1 -> 20140213.1 > > app2 is 20140207.1 -> 20140213.1 > > > >> On Thu, Feb 13, 2014 at 1:59 PM, Mike Oxford wrote: > >> It looks like you're trying to suspend version 20140213.1 and replace it > >> with 20140213.1 (the same version.) > >> > >> > >> > >>> On Thu, Feb 13, 2014 at 11:51 AM, Ivan Uemlianin > wrote: > >>> > >>> Sorry don't follow > >>> > >>> -- > >>> festina lente > >>> > >>> > >>> On 13 Feb 2014, at 19:35, Mike Oxford wrote: > >>> > >>> [{"1.0.6",[], > >>> [{load_object_code,{app1,"20140213.1",[app1]}}, > >>> {load_object_code,{app2,"20140213.1",[app2]}}, > >>> > >>> Replacing a version with itself? > >>> > >>> > >>> > >>>> On Thu, Feb 13, 2014 at 11:03 AM, Ivan Uemlianin > wrote: > >>>> > >>>> Dear Mike > >>>> > >>>> Thanks for your help. > >>>> > >>>> Here's a recent relup. After this upgrade, I had to manually > code_load > >>>> and purge app1: > >>>> > >>>> {"1.0.7", > >>>> [{"1.0.6",[], > >>>> [{load_object_code,{app1,"20140213.1",[app1]}}, > >>>> {load_object_code,{app2,"20140213.1",[app2]}}, > >>>> point_of_no_return, > >>>> {suspend,[app1]}, > >>>> {load,{app1,brutal_purge,brutal_purge}}, > >>>> {code_change,up,[{app1,[from1to2]}]}, > >>>> {resume,[app1]}, > >>>> {suspend,[app2]}, > >>>> {load,{app2,brutal_purge,brutal_purge}}, > >>>> {code_change,up,[{app2,[from1to2]}]}, > >>>> {resume,[app2]}]}], > >>>> [{"1.0.6",[], > >>>> [{load_object_code,{app1,"20140211.1",[app1]}}, > >>>> {load_object_code,{app2,"20140207.1",[app2]}}, > >>>> point_of_no_return, > >>>> {suspend,[app1]}, > >>>> {code_change,down,[{app1,[from2to1]}]}, > >>>> {load,{app1,brutal_purge,brutal_purge}}, > >>>> {resume,[app1]}, > >>>> {suspend,[app2]}, > >>>> {code_change,down,[{app2,[from2to1]}]}, > >>>> {load,{app2,brutal_purge,brutal_purge}}, > >>>> {resume,[app2]}]}]}. > >>>> > >>>> Best wishes > >>>> > >>>> Ivan > >>>> > >>>> > >>>> > >>>>> On 13/02/2014 18:54, Mike Oxford wrote: > >>>>> > >>>>> Is your brutal_purge on the PostPurge or the PrePurge? > >>>>> > >>>>> > >>>>> On Thu, Feb 13, 2014 at 10:00 AM, Ivan Uemlianin >>>>> > wrote: > >>>>> > >>>>> Dear All > >>>>> > >>>>> I am just getting started with live release upgrades, using relx > and > >>>>> following this tutorial: > >>>>> > >>>>> http://blog.troutwine.us/2013/__09/13/trivial_otp_releases.__html > >>>>> > >>>>> > >>>>> > >>>>> Everything seems to work as advertised, except sometimes I need to > >>>>> explicitly load the code into the running vm (i.e., using > >>>>> code_load_file/1) for the new stuff to take effect. The function > >>>>> release_handler:which___releases/0 reports the new release as > active > >>>>> > >>>>> and permanent, but I can see from behaviour that old versions of > >>>>> certain modules are still running and handling data. > >>>>> > >>>>> I can't be much more specific I'm afraid. One example: one > >>>>> application uses cowboy. If a release upgrade changes a cowboy > >>>>> resource module, the new release version might still be running > the > >>>>> old version of that module until I load_file and purge. > >>>>> > >>>>> Why might this be happening? Am I missing something in the > >>>>> packaging and upgrade process? Is there a better way I can write > my > >>>>> modules? > >>>>> > >>>>> If the information above is too vague, what should I look out for > >>>>> next time this happens? > >>>>> > >>>>> With thanks and best wishes > >>>>> > >>>>> Ivan > >>>>> > >>>>> > >>>>> -- > >>>>> ==============================__============================== > >>>>> > >>>>> Ivan A. Uemlianin PhD > >>>>> Llaisdy > >>>>> Speech Technology Research and Development > >>>>> > >>>>> ivan@REDACTED > >>>>> www.llaisdy.com > >>>>> llaisdy.wordpress.com > >>>>> github.com/llaisdy > >>>>> www.linkedin.com/in/__ivanuemlianin > >>>>> > >>>>> > >>>>> festina lente > >>>>> ==============================__============================== > >>>>> _________________________________________________ > >>>>> erlang-questions mailing list > >>>>> erlang-questions@REDACTED > >>>>> http://erlang.org/mailman/__listinfo/erlang-questions > >>>>> > >>>> > >>>> -- > >>>> ============================================================ > >>>> Ivan A. Uemlianin PhD > >>>> Llaisdy > >>>> Speech Technology Research and Development > >>>> > >>>> ivan@REDACTED > >>>> www.llaisdy.com > >>>> llaisdy.wordpress.com > >>>> github.com/llaisdy > >>>> www.linkedin.com/in/ivanuemlianin > >>>> > >>>> festina lente > >>>> ============================================================ > >> > >> > >> _______________________________________________ > >> 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 > -- ?????????? ????????? / Alexander Petrovsky, Skype: askjuise Phone: +7 914 8 820 815 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Sat Feb 15 13:51:48 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Sat, 15 Feb 2014 12:51:48 +0000 Subject: [erlang-questions] release upgrades and code loading In-Reply-To: References: <52FD0826.2080305@llaisdy.com> <52FD16FC.10101@llaisdy.com> <2102315A-8B47-4B18-A674-29B5C90C7C83@llaisdy.com> Message-ID: Dear Alexander Thanks for yor comment. I shall look into what genappup does but two reasons against my using it are: I'm currently liking doing things explictly and manually, partly to learn; I've moved away from using rebar. Reading that page though, I realise I might have written some incorrect appups. (Will go and check) Best wishes Ivan -- festina lente > On 15 Feb 2014, at 12:20, Alexander Petrovsky wrote: > > Ivan, by the way for generate appup files you can use genappup - http://www.echorussia.ru/erlang-releases.html > > > 2014-02-13 23:26 GMT+03:00 Ivan Uemlianin : >> Paul's interpretation is what I was trying to do with this upgrade. >> >> Ivan >> >> -- >> festina lente >> >> >> > On 13 Feb 2014, at 20:17, Paul Davis wrote: >> > >> > Mike, pretty sure its upgrading two apps to the same version. >> > >> > app1 is 20140211.1 -> 20140213.1 >> > app2 is 20140207.1 -> 20140213.1 >> > >> >> On Thu, Feb 13, 2014 at 1:59 PM, Mike Oxford wrote: >> >> It looks like you're trying to suspend version 20140213.1 and replace it >> >> with 20140213.1 (the same version.) >> >> >> >> >> >> >> >>> On Thu, Feb 13, 2014 at 11:51 AM, Ivan Uemlianin wrote: >> >>> >> >>> Sorry don't follow >> >>> >> >>> -- >> >>> festina lente >> >>> >> >>> >> >>> On 13 Feb 2014, at 19:35, Mike Oxford wrote: >> >>> >> >>> [{"1.0.6",[], >> >>> [{load_object_code,{app1,"20140213.1",[app1]}}, >> >>> {load_object_code,{app2,"20140213.1",[app2]}}, >> >>> >> >>> Replacing a version with itself? >> >>> >> >>> >> >>> >> >>>> On Thu, Feb 13, 2014 at 11:03 AM, Ivan Uemlianin wrote: >> >>>> >> >>>> Dear Mike >> >>>> >> >>>> Thanks for your help. >> >>>> >> >>>> Here's a recent relup. After this upgrade, I had to manually code_load >> >>>> and purge app1: >> >>>> >> >>>> {"1.0.7", >> >>>> [{"1.0.6",[], >> >>>> [{load_object_code,{app1,"20140213.1",[app1]}}, >> >>>> {load_object_code,{app2,"20140213.1",[app2]}}, >> >>>> point_of_no_return, >> >>>> {suspend,[app1]}, >> >>>> {load,{app1,brutal_purge,brutal_purge}}, >> >>>> {code_change,up,[{app1,[from1to2]}]}, >> >>>> {resume,[app1]}, >> >>>> {suspend,[app2]}, >> >>>> {load,{app2,brutal_purge,brutal_purge}}, >> >>>> {code_change,up,[{app2,[from1to2]}]}, >> >>>> {resume,[app2]}]}], >> >>>> [{"1.0.6",[], >> >>>> [{load_object_code,{app1,"20140211.1",[app1]}}, >> >>>> {load_object_code,{app2,"20140207.1",[app2]}}, >> >>>> point_of_no_return, >> >>>> {suspend,[app1]}, >> >>>> {code_change,down,[{app1,[from2to1]}]}, >> >>>> {load,{app1,brutal_purge,brutal_purge}}, >> >>>> {resume,[app1]}, >> >>>> {suspend,[app2]}, >> >>>> {code_change,down,[{app2,[from2to1]}]}, >> >>>> {load,{app2,brutal_purge,brutal_purge}}, >> >>>> {resume,[app2]}]}]}. >> >>>> >> >>>> Best wishes >> >>>> >> >>>> Ivan >> >>>> >> >>>> >> >>>> >> >>>>> On 13/02/2014 18:54, Mike Oxford wrote: >> >>>>> >> >>>>> Is your brutal_purge on the PostPurge or the PrePurge? >> >>>>> >> >>>>> >> >>>>> On Thu, Feb 13, 2014 at 10:00 AM, Ivan Uemlianin > >>>>> > wrote: >> >>>>> >> >>>>> Dear All >> >>>>> >> >>>>> I am just getting started with live release upgrades, using relx and >> >>>>> following this tutorial: >> >>>>> >> >>>>> http://blog.troutwine.us/2013/__09/13/trivial_otp_releases.__html >> >>>>> >> >>>>> >> >>>>> >> >>>>> Everything seems to work as advertised, except sometimes I need to >> >>>>> explicitly load the code into the running vm (i.e., using >> >>>>> code_load_file/1) for the new stuff to take effect. The function >> >>>>> release_handler:which___releases/0 reports the new release as active >> >>>>> >> >>>>> and permanent, but I can see from behaviour that old versions of >> >>>>> certain modules are still running and handling data. >> >>>>> >> >>>>> I can't be much more specific I'm afraid. One example: one >> >>>>> application uses cowboy. If a release upgrade changes a cowboy >> >>>>> resource module, the new release version might still be running the >> >>>>> old version of that module until I load_file and purge. >> >>>>> >> >>>>> Why might this be happening? Am I missing something in the >> >>>>> packaging and upgrade process? Is there a better way I can write my >> >>>>> modules? >> >>>>> >> >>>>> If the information above is too vague, what should I look out for >> >>>>> next time this happens? >> >>>>> >> >>>>> With thanks and best wishes >> >>>>> >> >>>>> Ivan >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> ==============================__============================== >> >>>>> >> >>>>> Ivan A. Uemlianin PhD >> >>>>> Llaisdy >> >>>>> Speech Technology Research and Development >> >>>>> >> >>>>> ivan@REDACTED >> >>>>> www.llaisdy.com >> >>>>> llaisdy.wordpress.com >> >>>>> github.com/llaisdy >> >>>>> www.linkedin.com/in/__ivanuemlianin >> >>>>> >> >>>>> >> >>>>> festina lente >> >>>>> ==============================__============================== >> >>>>> _________________________________________________ >> >>>>> erlang-questions mailing list >> >>>>> erlang-questions@REDACTED >> >>>>> http://erlang.org/mailman/__listinfo/erlang-questions >> >>>>> >> >>>> >> >>>> -- >> >>>> ============================================================ >> >>>> Ivan A. Uemlianin PhD >> >>>> Llaisdy >> >>>> Speech Technology Research and Development >> >>>> >> >>>> ivan@REDACTED >> >>>> www.llaisdy.com >> >>>> llaisdy.wordpress.com >> >>>> github.com/llaisdy >> >>>> www.linkedin.com/in/ivanuemlianin >> >>>> >> >>>> festina lente >> >>>> ============================================================ >> >> >> >> >> >> _______________________________________________ >> >> 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 > > > > -- > ?????????? ????????? / Alexander Petrovsky, > > Skype: askjuise > Phone: +7 914 8 820 815 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Sat Feb 15 14:06:29 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 15 Feb 2014 14:06:29 +0100 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> Message-ID: <52FF6655.6030807@ninenines.eu> I do not think you are fully informed about Erlang. On 02/15/2014 01:01 PM, Pieter Hintjens wrote: > A technology either lives, by growing and merging with others, or it > dies. Erlang is far from being a living technology and survives pretty > much thanks to a single dominant customer and investor. It claims to > be the best solution for distributed systems, yet is entirely > homogeneous, which is also an insane contradiction. Distributed > systems by definition must span space and time, or they are > LegacyAsAService. Erlang comes with C-nodes and Java-nodes, you can plug pretty much anything you want in the cluster. At a previous client we have at some point used this to make PHP communicate with Erlang for example. And of course you also have a couple dozen more ways to tie any program with a node if you can't make them into nodes directly. It's really very easy to make anything talk to Erlang. > Erlang needs to shed its telco ties, and get an independent steering > committee Welcome to last year. Work in progress. Erlang doesn't really need to shed its telco ties though. Today Erlang is heavily used in databases and HTTP related products, which happen to have the same requirements as telco products. So what it actually needs is to be tied with telco, DB and HTTP related companies, which is pretty much what they are currently doing. > and create standards I don't see that relevant. It's just one way to do things. You cited PHP, yet PHP has no standards, it's just an accumulated pile of code. > and multiple implementations Again not seeing that relevant. But in case it is, Erlang has of course the normal BEAM VM, but also HiPE, ErLLVM, LING VM and probably others I don't know about. They range from partial implementations running in the BEAM VM to completely independent implementations. > also reach out to other language communities through distribution > protocols like ZMTP You mean like RabbitMQ? > and educate those communities, while also > exploiting them and merging with them. I don't really see that happening in other languages either. At least not more than Erlang; Erlang people already talk about Erlang at conferences or user groups meant for other languages. > Mock Java all you like. It's a hateful language in many ways. But Java > programmers know how to work together. There are 6+ different Erlang > stacks for ZeroMQ, all one-man projects, all lacking any community. Have you considered that perhaps there isn't that much interest in ZeroMQ in the Erlang community? It sounds to me that there are just 6 users and that their stack is just meant to fit their needs. Personally I wasn't aware of ZeroMQ's existence until about a year ago, and only because we randomly stumbled on you and Garrett in a bar in London. There *is* a culture in the Erlang community that often prevents one stack from being the definite solution, though. People often just hack something in two days, put it on github and then forget about it. Sometimes it's a fork of an old project, sometimes a new one. This is also the reason there is no canonical package index. Projects that do not suffer from this are very rare, notable exceptions being databases, HTTP and JSON. And by databases I mean actual databases, not drivers. Drivers are a mess of "works for me" forks. I think this happens in part because there isn't enough Erlang developers. When you are a team of 3 building a service for millions of users, you tend to focus on making it work. And that's okay, really. Perhaps Erlang doesn't have many programmers, but they still manage to handle an impressively high amount of traffic worldwide. The traffic/programmers ratio for Erlang is one of the highest there is. Hundreds of millions of people, if not billions, use products or services that run Erlang everyday, and that number keeps increasing rapidly despite the seemingly slow adoption. Erlang *is* changing for the better. The problem is how the average programmer sees Erlang. No amount of decisions can change this overnight. It's easy to fix a product; it's not easy to fix its image. -- Lo?c Hoguin http://ninenines.eu From vinoski@REDACTED Sat Feb 15 14:08:30 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Sat, 15 Feb 2014 08:08:30 -0500 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> Message-ID: On Sat, Feb 15, 2014 at 7:01 AM, Pieter Hintjens wrote: > It was extremely enlightening last week, at a workshop with a medium > sized Erlang shop. Opening statement: "We chose Erlang because it lets > us build large distributed systems with a small team." Then two full > days of, "oh, that's one more serious problem we're facing, caused by > how Erlang does things." > I'd like to hear the details of these serious problems, as I bet they're not nearly as dire as you make them out to be. I have decades of experience in distributed computing and have used a number of languages along the way, and for me Erlang remains the best of the bunch, by far. I think others here have similar personal stories. It has nothing to do with elitism, but rather, with achieving working maintainable solutions on time and within budget. A technology either lives, by growing and merging with others, or it > dies. Erlang is far from being a living technology and survives pretty > much thanks to a single dominant customer and investor. It claims to > be the best solution for distributed systems, yet is entirely > homogeneous, which is also an insane contradiction. Distributed > systems by definition must span space and time, or they are > LegacyAsAService. > Sorry Pieter, but much of this paragraph is ill-informed. For example, I've had more success building integration projects with Erlang than with anything else I've tried. Riak for example includes Erlang, C, C++, and Java code within it, all integrated, working together, and being used for different parts where it makes sense to use them, and it's used by many many people who aren't Erlang programmers and by companies big and small that don't employ them. The work I did before joining Basho involved C++ and Erlang primarily, with a number of standard and proprietary network protocols involved, and there were 7-8 Erlang programmers building more working code than the rest of the 40+ C++ devs. > How can you build up if your basic layers aren't a > commodity? There's a million times more wealth built on PHP than > Erlang. Real wealth. > And you've measured that PHP claim how? Pointers to factual sources of information, please. Hint: be sure to take the T word -- that dreaded Telecom industry -- into account when doing your wealth calculations. > Erlang needs to shed its telco ties, and get an independent steering > committee, and create standards, and multiple implementations, and > also reach out to other language communities through distribution > protocols like ZMTP, and educate those communities, while also > exploiting them and merging with them. Living systems are like the > Borg; they grow by merger. > There is a relatively recent industrial Erlang users group that includes major users of Erlang outside Ericsson and also includes the OTP team. It meets several times per year and has already had influence on helping open Erlang to a larger community. I love it when people from outside jump into this mailing list and have enough hubris to think that their mere appearance here marks a critical point in the lifecycle of Erlang, like they're some sort of prophet descended from on high, and that their dire warnings better be taken seriously NOW or we're all doomed for immediate extinction. And this is the second time it's happened within a week -- we must be doing something right! All this for a language that started life around 1985 and is currently surrounded by a community that's larger and more vibrant than ever, and by all accounts is growing, not shrinking. Mock Java all you like. It's a hateful language in many ways. But Java > programmers know how to work together. There are 6+ different Erlang > stacks for ZeroMQ, all one-man projects, all lacking any community. Have you considered that it's because the Erlang applications that need ZeroMQ-like facilities have better ways of solving the problem? --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Sat Feb 15 14:14:40 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Sat, 15 Feb 2014 08:14:40 -0500 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> Message-ID: <52FF6840.7080105@meetinghouse.net> Pieter Hintjens wrote: > On Fri, Feb 14, 2014 at 4:39 PM, Miles Fidelman > wrote: > >> Actually, the demand for both Cobol and analog engineers is UP. > Friend of mine was just laid off from a 15-year Cobol job. One can't > make general conclusions from small samples. Talk about small samples. How about this for a larger sample: http://eandt.theiet.org/news/2013/mar/cobol-skills.cfm (lede: "Dearth of COBOL programmers threatens business") Or Indeed.Com's salary survey: http://www.indeed.com/salary/Cobol-Developer.html > > The argument that keeping technology elitist creates wealth is insane > and should be laid to rest rapidly. Who here is building new > businesses on LU6.2? Right. Ask doctors why they specialize. > Erlang needs to shed its telco ties, and get an independent steering > committee, and create standards, and multiple implementations, and > also reach out to other language communities through distribution > protocols like ZMTP, and educate those communities, while also > exploiting them and merging with them. Living systems are like the > Borg; they grow by merger. Why? That's all theory. In practice: - it's been around, and in use for quite some time - it's in use in some very large applications - it's in use in multiple industries, and by some large players - there are some successful businesses that are built on top of Erlang (Basho comes to mind) - there's a demand for folks who know Erlang (actually, the demand is probably more for people who can build highly scalable high-availability systems) Excelling at a niche market is a great success strategy. FYI: Ada is a good parallel example. It was pushed, for years, by the biggest customer in the world, has standards bodies and multiple implementations. Yet it never has taken off as a major platform. On the other hand, it continues to have a significant market in mission-critical systems - SCADA, aircraft, oil & gas, industrial control. It's not going away anytime soon. I'd be a lot more worried about Erlang's future if there were anything remotely like it in the market (and I'm somewhat surprised that there isn't). It completely blows me away that there isn't another platform that's built ground-up to support massive concurrency and 24x7 operation. Guess 1st mover advantage counts for a lot. (Maybe Carl Hewitt's personality accounts for the Actor formalism's lack of widespread traction.) > > Mock Java all you like. It's a hateful language in many ways. But Java > programmers know how to work together. There are 6+ different Erlang > stacks for ZeroMQ, all one-man projects, all lacking any community. > > Who's mocking Java? I just don't have much use for it. On the other hand, the company I work for these days builds most stuff on top of .NET and Microsoft SQL - not what I'd chose, but it works. As to ZeroMQ - is that not more about market conditions? But I would expect you're in a better position to comment on that then most. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From john@REDACTED Sat Feb 15 14:42:54 2014 From: john@REDACTED (John Kemp) Date: Sat, 15 Feb 2014 08:42:54 -0500 Subject: [erlang-questions] Erland users group (was re: languages in use? [was: Time for OTP to be Renamed?]) In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> Message-ID: <52FF6EDE.1090205@jkemp.net> On 02/15/2014 08:08 AM, Steve Vinoski wrote: > On Sat, Feb 15, 2014 at 7:01 AM, Pieter Hintjens wrote: [...] > > Erlang needs to shed its telco ties, and get an independent steering > committee, and create standards, and multiple implementations, and > also reach out to other language communities through distribution > protocols like ZMTP, and educate those communities, while also > exploiting them and merging with them. Living systems are like the > Borg; they grow by merger. > > > There is a relatively recent industrial Erlang users group that includes > major users of Erlang outside Ericsson and also includes the OTP team. > It meets several times per year and has already had influence on helping > open Erlang to a larger community. I think Pieter does have a relevant point about this (standardization related to growth of the actual community). How does this "industrial Erlang users group" relate to that? Or the EEP process? Are these things related, and/or, should they be? Cheers, - johnk From vinoski@REDACTED Sat Feb 15 15:06:21 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Sat, 15 Feb 2014 09:06:21 -0500 Subject: [erlang-questions] Erland users group (was re: languages in use? [was: Time for OTP to be Renamed?]) In-Reply-To: <52FF6EDE.1090205@jkemp.net> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FF6EDE.1090205@jkemp.net> Message-ID: On Sat, Feb 15, 2014 at 8:42 AM, John Kemp wrote: > On 02/15/2014 08:08 AM, Steve Vinoski wrote: > > On Sat, Feb 15, 2014 at 7:01 AM, Pieter Hintjens wrote: >> > > [...] > > >> Erlang needs to shed its telco ties, and get an independent steering >> committee, and create standards, and multiple implementations, and >> also reach out to other language communities through distribution >> protocols like ZMTP, and educate those communities, while also >> exploiting them and merging with them. Living systems are like the >> Borg; they grow by merger. >> >> >> There is a relatively recent industrial Erlang users group that includes >> major users of Erlang outside Ericsson and also includes the OTP team. >> It meets several times per year and has already had influence on helping >> open Erlang to a larger community. >> > > I think Pieter does have a relevant point about this (standardization > related to growth of the actual community). > I'm guessing you've never been involved in a standards committee. Having spent years working on various standards, I can assure you they are intensely political and are pretty much just an enormous waste of time. (I was once involved in a heavily politicized standards effort with Pieter, in fact, and both of us were extremely frustrated with the whole thing.) I honestly can't see how bringing standards into the picture will help Erlang in any way. > How does this "industrial Erlang users group" relate to that? Or the EEP > process? Are these things related, and/or, should they be? See https://erlangcentral.org/industrial-erlang-user-group/ for more info on the IEUG. The group is relatively new. It's unrelated to EEPs, though I suppose if there were an EEP the group deemed important I guess it might choose to help push it along. In addition to helping provide funds for marketing Erlang, one area of work of the IEUG to date relates to how the OTP team works with the Erlang open source community. The OTP team looks to continually improve in that area, and the IEUG has advised them on that front and will continue to do so. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From john@REDACTED Sat Feb 15 15:27:08 2014 From: john@REDACTED (John Kemp) Date: Sat, 15 Feb 2014 09:27:08 -0500 Subject: [erlang-questions] Erland users group (was re: languages in use? [was: Time for OTP to be Renamed?]) In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FF6EDE.1090205@jkemp.net> Message-ID: <52FF793C.5090908@jkemp.net> On 02/15/2014 09:06 AM, Steve Vinoski wrote: [...] > There is a relatively recent industrial Erlang users group that > includes > major users of Erlang outside Ericsson and also includes the OTP > team. > It meets several times per year and has already had influence on > helping > open Erlang to a larger community. > > > I think Pieter does have a relevant point about this > (standardization related to growth of the actual community). > > > I'm guessing you've never been involved in a standards committee. Heh. I'm glad you are just guessing about that :) > Having > spent years working on various standards, I can assure you they are > intensely political and are pretty much just an enormous waste of time. From the point of someone _making_ the standard, I can see that, especially if the standard turns out not to get the widespread adoption that rewards the effort. I know that feeling. > (I was once involved in a heavily politicized standards effort with > Pieter, in fact, and both of us were extremely frustrated with the whole > thing.) I honestly can't see how bringing standards into the picture > will help Erlang in any way. Well, a mechanism for increased interest and adoption is one way. An organization that dispels any myth that Erlang/OTP is "controlled" by Ericsson might be another benefit. > > How does this "industrial Erlang users group" relate to that? Or the > EEP process? Are these things related, and/or, should they be? > > > See https://erlangcentral.org/industrial-erlang-user-group/ for more > info on the IEUG. > > The group is relatively new. It's unrelated to EEPs, though I suppose if > there were an EEP the group deemed important I guess it might choose to > help push it along. > > In addition to helping provide funds for marketing Erlang, one area of > work of the IEUG to date relates to how the OTP team works with the > Erlang open source community. The OTP team looks to continually improve > in that area, and the IEUG has advised them on that front and will > continue to do so. Thanks. Very helpful. - johnk > > --steve From ivan@REDACTED Sat Feb 15 15:29:25 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Sat, 15 Feb 2014 14:29:25 +0000 Subject: [erlang-questions] SOLVED (I think) Re: release upgrades and code loading In-Reply-To: References: <52FD0826.2080305@llaisdy.com> <52FD16FC.10101@llaisdy.com> <2102315A-8B47-4B18-A674-29B5C90C7C83@llaisdy.com> Message-ID: Dear Alexander Thanks very much for your intervention. Some of the appup files do not correctly list the app's updated modules. Presumably that is behind the wonky release upgrades. Best wishes Ivan -- festina lente > On 15 Feb 2014, at 12:20, Alexander Petrovsky wrote: > > Ivan, by the way for generate appup files you can use genappup - http://www.echorussia.ru/erlang-releases.html > > > 2014-02-13 23:26 GMT+03:00 Ivan Uemlianin : >> Paul's interpretation is what I was trying to do with this upgrade. >> >> Ivan >> >> -- >> festina lente >> >> >> > On 13 Feb 2014, at 20:17, Paul Davis wrote: >> > >> > Mike, pretty sure its upgrading two apps to the same version. >> > >> > app1 is 20140211.1 -> 20140213.1 >> > app2 is 20140207.1 -> 20140213.1 >> > >> >> On Thu, Feb 13, 2014 at 1:59 PM, Mike Oxford wrote: >> >> It looks like you're trying to suspend version 20140213.1 and replace it >> >> with 20140213.1 (the same version.) >> >> >> >> >> >> >> >>> On Thu, Feb 13, 2014 at 11:51 AM, Ivan Uemlianin wrote: >> >>> >> >>> Sorry don't follow >> >>> >> >>> -- >> >>> festina lente >> >>> >> >>> >> >>> On 13 Feb 2014, at 19:35, Mike Oxford wrote: >> >>> >> >>> [{"1.0.6",[], >> >>> [{load_object_code,{app1,"20140213.1",[app1]}}, >> >>> {load_object_code,{app2,"20140213.1",[app2]}}, >> >>> >> >>> Replacing a version with itself? >> >>> >> >>> >> >>> >> >>>> On Thu, Feb 13, 2014 at 11:03 AM, Ivan Uemlianin wrote: >> >>>> >> >>>> Dear Mike >> >>>> >> >>>> Thanks for your help. >> >>>> >> >>>> Here's a recent relup. After this upgrade, I had to manually code_load >> >>>> and purge app1: >> >>>> >> >>>> {"1.0.7", >> >>>> [{"1.0.6",[], >> >>>> [{load_object_code,{app1,"20140213.1",[app1]}}, >> >>>> {load_object_code,{app2,"20140213.1",[app2]}}, >> >>>> point_of_no_return, >> >>>> {suspend,[app1]}, >> >>>> {load,{app1,brutal_purge,brutal_purge}}, >> >>>> {code_change,up,[{app1,[from1to2]}]}, >> >>>> {resume,[app1]}, >> >>>> {suspend,[app2]}, >> >>>> {load,{app2,brutal_purge,brutal_purge}}, >> >>>> {code_change,up,[{app2,[from1to2]}]}, >> >>>> {resume,[app2]}]}], >> >>>> [{"1.0.6",[], >> >>>> [{load_object_code,{app1,"20140211.1",[app1]}}, >> >>>> {load_object_code,{app2,"20140207.1",[app2]}}, >> >>>> point_of_no_return, >> >>>> {suspend,[app1]}, >> >>>> {code_change,down,[{app1,[from2to1]}]}, >> >>>> {load,{app1,brutal_purge,brutal_purge}}, >> >>>> {resume,[app1]}, >> >>>> {suspend,[app2]}, >> >>>> {code_change,down,[{app2,[from2to1]}]}, >> >>>> {load,{app2,brutal_purge,brutal_purge}}, >> >>>> {resume,[app2]}]}]}. >> >>>> >> >>>> Best wishes >> >>>> >> >>>> Ivan >> >>>> >> >>>> >> >>>> >> >>>>> On 13/02/2014 18:54, Mike Oxford wrote: >> >>>>> >> >>>>> Is your brutal_purge on the PostPurge or the PrePurge? >> >>>>> >> >>>>> >> >>>>> On Thu, Feb 13, 2014 at 10:00 AM, Ivan Uemlianin > >>>>> > wrote: >> >>>>> >> >>>>> Dear All >> >>>>> >> >>>>> I am just getting started with live release upgrades, using relx and >> >>>>> following this tutorial: >> >>>>> >> >>>>> http://blog.troutwine.us/2013/__09/13/trivial_otp_releases.__html >> >>>>> >> >>>>> >> >>>>> >> >>>>> Everything seems to work as advertised, except sometimes I need to >> >>>>> explicitly load the code into the running vm (i.e., using >> >>>>> code_load_file/1) for the new stuff to take effect. The function >> >>>>> release_handler:which___releases/0 reports the new release as active >> >>>>> >> >>>>> and permanent, but I can see from behaviour that old versions of >> >>>>> certain modules are still running and handling data. >> >>>>> >> >>>>> I can't be much more specific I'm afraid. One example: one >> >>>>> application uses cowboy. If a release upgrade changes a cowboy >> >>>>> resource module, the new release version might still be running the >> >>>>> old version of that module until I load_file and purge. >> >>>>> >> >>>>> Why might this be happening? Am I missing something in the >> >>>>> packaging and upgrade process? Is there a better way I can write my >> >>>>> modules? >> >>>>> >> >>>>> If the information above is too vague, what should I look out for >> >>>>> next time this happens? >> >>>>> >> >>>>> With thanks and best wishes >> >>>>> >> >>>>> Ivan >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> ==============================__============================== >> >>>>> >> >>>>> Ivan A. Uemlianin PhD >> >>>>> Llaisdy >> >>>>> Speech Technology Research and Development >> >>>>> >> >>>>> ivan@REDACTED >> >>>>> www.llaisdy.com >> >>>>> llaisdy.wordpress.com >> >>>>> github.com/llaisdy >> >>>>> www.linkedin.com/in/__ivanuemlianin >> >>>>> >> >>>>> >> >>>>> festina lente >> >>>>> ==============================__============================== >> >>>>> _________________________________________________ >> >>>>> erlang-questions mailing list >> >>>>> erlang-questions@REDACTED >> >>>>> http://erlang.org/mailman/__listinfo/erlang-questions >> >>>>> >> >>>> >> >>>> -- >> >>>> ============================================================ >> >>>> Ivan A. Uemlianin PhD >> >>>> Llaisdy >> >>>> Speech Technology Research and Development >> >>>> >> >>>> ivan@REDACTED >> >>>> www.llaisdy.com >> >>>> llaisdy.wordpress.com >> >>>> github.com/llaisdy >> >>>> www.linkedin.com/in/ivanuemlianin >> >>>> >> >>>> festina lente >> >>>> ============================================================ >> >> >> >> >> >> _______________________________________________ >> >> 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 > > > > -- > ?????????? ????????? / Alexander Petrovsky, > > Skype: askjuise > Phone: +7 914 8 820 815 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahesh@REDACTED Sat Feb 15 16:28:49 2014 From: mahesh@REDACTED (Mahesh Paolini-Subramanya) Date: Sat, 15 Feb 2014 16:28:49 +0100 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <52FF6840.7080105@meetinghouse.net> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FF6840.7080105@meetinghouse.net> Message-ID: I've pointed this out before, but it really bears repeating - "Erlang-based systems are architected *differently*" - "Let it Crash" actually works - "Loose Coupling" actually works - "Edge Cases" can be dealt with lazily The thing is, the three items above all work together - each is useful in isolation, but when put together, the Gestalt is mighty powerful. Consider a typical erlang-based system, where an obscure condition (edge case!) gets triggered by a user, and clobbers the component in question. Thats OK - it crashes, like it is *supposed* to! Pretty much by definition, these systems are architected so that it is not only processes that are isolated, but the components that they reside in, the applications thereof, the nodes, etc., etc. ("loose coupling"!). Consequently, supervisors restart the component in question, and life goes on. Meanwhile, you (or the developer in question) tracks down the edge-case, and hot-loads a patch stat. Life, in short, is good. In contrast, virtually edge-cases were (and still are) the bane of virtually every non-erlang system that I've ever worked on. We'd spend *person-years* tracking down every possibility, and still watch the whole damn thing tumble to the ground because some *truly* horrible edge-case that we couldn't anticipate got triggered. And that, of course, doesn't even begin to get into the entertainment which is "Sunday Morning 2AM - its time to Shut The System Down to load the fix" And now to the snark part - some stuff that I've seen repeatedly here, and can't leave well enough alone "Nobody uses erlang" <--- Except for everybody that does "Its got only one dominant sponsor" <-- WTF does that even mean? Like Java has Oracle? "Erlang doesn't play well w/ therefore it is teh sux0r" <--- Ummm, maybe isn't particularly relevant for virtually everything you do in Erlang? Writing GUI components is terrible! Oh Noes! "Erlang needs standards" <-- Please tell me you don't mean "standards bodies". Please! "Erlang needs to shed its telco ties" <--- Huh? *What* telco ties? Yes, Ericcson. I got the point, and will raise you "99.99% of erlang devs and projects dont' give a s**t about Ericcson" "But Java programmers know how to work together." <-- I'll let that one just kind of stand there by itself. And finally, I really would like to point out, not everything gets better with the addition of a coffee-grinder attachment. Focused systems are wonderfully useful things in the world of integration and loose-coupling. Why, one of my favorite cross-platform tools is this wonderful thing called ZeroMQ, which doesn't really have a built-in database, built-in scripting tool, built-in web GUI, or frankly, much of anything other than the basics. And it rocks... Cheers On Sat, Feb 15, 2014 at 2:14 PM, Miles Fidelman wrote: > Pieter Hintjens wrote: > >> On Fri, Feb 14, 2014 at 4:39 PM, Miles Fidelman >> wrote: >> >> Actually, the demand for both Cobol and analog engineers is UP. >>> >> Friend of mine was just laid off from a 15-year Cobol job. One can't >> make general conclusions from small samples. >> > > Talk about small samples. > > How about this for a larger sample: > http://eandt.theiet.org/news/2013/mar/cobol-skills.cfm (lede: "Dearth of > COBOL programmers threatens business") > > Or Indeed.Com's salary survey: > http://www.indeed.com/salary/Cobol-Developer.html > > > >> The argument that keeping technology elitist creates wealth is insane >> and should be laid to rest rapidly. Who here is building new >> businesses on LU6.2? Right. >> > > Ask doctors why they specialize. > > > Erlang needs to shed its telco ties, and get an independent steering >> committee, and create standards, and multiple implementations, and >> also reach out to other language communities through distribution >> protocols like ZMTP, and educate those communities, while also >> exploiting them and merging with them. Living systems are like the >> Borg; they grow by merger. >> > > Why? That's all theory. In practice: > - it's been around, and in use for quite some time > - it's in use in some very large applications > - it's in use in multiple industries, and by some large players > - there are some successful businesses that are built on top of Erlang > (Basho comes to mind) > - there's a demand for folks who know Erlang (actually, the demand is > probably more for people who can build highly scalable high-availability > systems) > > Excelling at a niche market is a great success strategy. > > FYI: Ada is a good parallel example. It was pushed, for years, by the > biggest customer in the world, has standards bodies and multiple > implementations. Yet it never has taken off as a major platform. On the > other hand, it continues to have a significant market in mission-critical > systems - SCADA, aircraft, oil & gas, industrial control. It's not going > away anytime soon. > > I'd be a lot more worried about Erlang's future if there were anything > remotely like it in the market (and I'm somewhat surprised that there > isn't). It completely blows me away that there isn't another platform > that's built ground-up to support massive concurrency and 24x7 operation. > Guess 1st mover advantage counts for a lot. (Maybe Carl Hewitt's > personality accounts for the Actor formalism's lack of widespread traction.) > > >> Mock Java all you like. It's a hateful language in many ways. But Java >> programmers know how to work together. There are 6+ different Erlang >> stacks for ZeroMQ, all one-man projects, all lacking any community. >> >> >> Who's mocking Java? I just don't have much use for it. On the other > hand, the company I work for these days builds most stuff on top of .NET > and Microsoft SQL - not what I'd chose, but it works. > > As to ZeroMQ - is that not more about market conditions? But I would > expect you're in a better position to comment on that then most. > > > -- > 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 > -- *Mahesh Paolini-Subramanya That tall bald Indian guy..* *Google+ | Blog | Twitter | LinkedIn * -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Sat Feb 15 16:11:44 2014 From: mfidelman@REDACTED (mfidelman) Date: Sat, 15 Feb 2014 10:11:44 -0500 Subject: [erlang-questions] Erland users group (was re: languages in use? [was: Time for OTP to be Renamed?]) Message-ID:
-------- Original message --------
From: John Kemp
Date:02/15/2014 9:27 AM (GMT-05:00)
To: Steve Vinoski
Cc: erlang-questions@REDACTED
Subject: Re: [erlang-questions] Erland users group (was re: languages in use? [was: Time for OTP to be Renamed?])
On 02/15/2014 09:06 AM, Steve Vinoski wrote: Well, a mechanism for increased interest and adoption is one way. An organization that dispels any myth that Erlang/OTP is "controlled" by Ericsson might be another benefit _______________________________________________ Sun/Oracle - Java Microsoft - .NET Doesn't seem to have impeded adoption. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Sat Feb 15 16:11:44 2014 From: mfidelman@REDACTED (mfidelman) Date: Sat, 15 Feb 2014 10:11:44 -0500 Subject: [erlang-questions] Erland users group (was re: languages in use? [was: Time for OTP to be Renamed?]) Message-ID:
-------- Original message --------
From: John Kemp
Date:02/15/2014 9:27 AM (GMT-05:00)
To: Steve Vinoski
Cc: erlang-questions@REDACTED
Subject: Re: [erlang-questions] Erland users group (was re: languages in use? [was: Time for OTP to be Renamed?])
On 02/15/2014 09:06 AM, Steve Vinoski wrote: Well, a mechanism for increased interest and adoption is one way. An organization that dispels any myth that Erlang/OTP is "controlled" by Ericsson might be another benefit _______________________________________________ Sun/Oracle - Java Microsoft - .NET Doesn't seem to have impeded adoption. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john@REDACTED Sat Feb 15 17:07:49 2014 From: john@REDACTED (John Kemp) Date: Sat, 15 Feb 2014 11:07:49 -0500 Subject: [erlang-questions] Erland users group (was re: languages in use? [was: Time for OTP to be Renamed?]) In-Reply-To: References: Message-ID: <52FF90D5.5050908@jkemp.net> Your examples are, I think, instructive: On 02/15/2014 10:11 AM, mfidelman wrote: > > > > -------- Original message -------- > From: John Kemp > Date:02/15/2014 9:27 AM (GMT-05:00) > To: Steve Vinoski > Cc: erlang-questions@REDACTED > Subject: Re: [erlang-questions] Erland users group (was re: languages in > use? [was: Time for OTP to be Renamed?]) > > On 02/15/2014 09:06 AM, Steve Vinoski wrote: > > Well, a mechanism for increased interest and adoption is one way. An > organization that dispels any myth that Erlang/OTP is "controlled" by > Ericsson might be another benefit > _______________________________________________ > > Sun/Oracle - Java The demise of Sun's software business can possibly be largely attributed to their failure to adequately share control over Java (see IBM's Hotspot, and then later Dalvik). And I will note there was the JCP, J2ME and lots of other attempts. The language, far from fulfilling the promise of "write once, run anywhere", has instead become marked by proprietary, probably non-interoperable implementations instead (e.g. Dalvik VM has no relation to J2ME applications that were once -- relatively -- popular on other phones). Oracle being in control of Java (and MySQL) has led only to more forks due to the FUD created by a single company's potential control over the language specification. > Microsoft - .NET .NET adoption beyond the Windows platform has been largely nil (cough, Mono). .NET as a platform has succeeded because Microsoft itself provides excellent tools which enable all kinds of non-expert developers to create applications. And they are one of the only companies able to support a "tools" business - do they make a profit at it though.... I dunno? > > Doesn't seem to have impeded adoption. Instructive examples, yes. But neither of them completely analagous to Erlang, and by the way, only somewhat related to my question about IEUG. I don't believe either that standadization is necessary or is unnecessary for Erlang. I was simply interested in the relationship of IEUG to Erlang and its growth. Regards, - johnk > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From g@REDACTED Sat Feb 15 17:33:42 2014 From: g@REDACTED (Garrett Smith) Date: Sat, 15 Feb 2014 10:33:42 -0600 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] Message-ID: I think this group therapy session is going well. People have expressed important feelings and strong emotions. Others have practiced good listening and empathy skills. So, looking around the circle, I'm now wondering if it makes sense to try to summarize the problems we'd like to solve. Should we draft a petition to ask Ericsson to change the words behind OTP? Some think that's a problem. I'm not here to judge. Should we propose to move the distribution protocol of Erlang from to something like ZMTP? I don't hear many specific technical objections to Erlang distribution protocol(s) but, for the future of the language, maybe it's an important problem to look at. Should we wrest control of Erlang from Ericsson? For my part, the changes over the last few years that Ericsson has driven have been very positive for the technology and the community. But is this a case where a dictator is only feeding and clothing us, shabbily, to keep us from revolt? I don't know. It doesn't *feel* like a problem, or at least not a problem that demands a revolution. I do have a general angst that other languages could swallow up the community of programmers that Erlang is suited for. Go, Clojure, Scala, JavaScript/Node, etc. -- looming territorial threats? Drum beats through the fog? I don't know - this feels like *personal angst* that can be solved through late night sessions of programming with Erlang -- solving actual coding problems, putting solutions into production, demonstrating 10x productivity over your colleagues, etc. For my part, I do have a specific problem, which is that I've found it hard to get colleagues to pick up and use this language. And there are particular reasons for that. I've observed this process: there's a surge of interest, but then a fall off. Then back to their standard toolkit, sans Erlang. I don't know if this is a problem with Erlang -- it could simply be a function of cost/benefit. Erlang costs perhaps 3 - 6 months of degraded productivity for a programmer. That's a lot, but I don't think it's much different than with other languages. Then it's simply a matter of the benefit, or perceived benefit -- does it cover the cost? Regarding this problem of adoption, I can confidently say that there are pointless barriers and friction to adoption in Erlang. The whole topic of "how to build an application in Erlang" is *very* hard to divine and takes time, trial, and error. That's part of that 3 - 6 month learning curve, but it goes well beyond it. I know, I know. To those of you who think Erlang application design/architecture is super straight forward, easy to spot, easy to implement correctly -- please bear in mind that you are much smarter than a lot of other people. Please consider middle-of-the-curve programmers like me. If we can simplify and flatten the learning curve to writing canonical Erlang applications (and, today, this means OTP compliance), it will help adoption and help Erlang track in organizations. For me, this is a problem worth investing energy in, big time. That's why there's e2. Of course there are lots of angles to invest in: books, user groups, conferences, online resources, tools, help on mailing lists and IRC and so on. Oh yeah, and rebranding OTP *of course* essential to this [1]. But this is just my personal problem, which I've tried to articulate using lots of "I statements" [2]. It doesn't have to be everyone else's. I would suggest that we wind this group therapy thread down, soon, and direct our energies toward identifying specific, important, solvable problems that we *genuinely* think are worth solving. [1] http://www.youtube.com/watch?v=rRbY3TMUcgQ [2] http://en.wikipedia.org/wiki/I-message On Sat, Feb 15, 2014 at 9:11 AM, mfidelman wrote: > > > > -------- Original message -------- > From: John Kemp > Date:02/15/2014 9:27 AM (GMT-05:00) > To: Steve Vinoski > Cc: erlang-questions@REDACTED > Subject: Re: [erlang-questions] Erland users group (was re: languages in > use? [was: Time for OTP to be Renamed?]) > > On 02/15/2014 09:06 AM, Steve Vinoski wrote: > > Well, a mechanism for increased interest and adoption is one way. An > organization that dispels any myth that Erlang/OTP is "controlled" by > Ericsson might be another benefit > _______________________________________________ > > Sun/Oracle - Java > Microsoft - .NET > > Doesn't seem to have impeded adoption. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From mfidelman@REDACTED Sat Feb 15 18:02:23 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Sat, 15 Feb 2014 12:02:23 -0500 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: Message-ID: <52FF9D9F.9040004@meetinghouse.net> Garrett Smith wrote: > I think this group therapy session is going well. People have > expressed important feelings and strong emotions. Others have > practiced good listening and empathy skills. > > Actually, I think it's a reaction to the snowstorms hitting the US - getting sucked into an email discussion is an alternative to taking a walk outside. But maybe that's just me :-) Though... I really am interested in knowing what languages people here use in their "day jobs" - as someone else asked. Obviously, a lot of folks here use Erlang - most of the traffic on the list is about real erlang-questions (and answers) - signs of a pretty good community. But for the folks who've been jumping into this discussion, I'm kind of curious - are the folks complaining about lack of adoption, naming, standards, etc. active users, or kibitzers? Miles (waiting for the next storm to hit) -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mononcqc@REDACTED Sat Feb 15 18:08:45 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Sat, 15 Feb 2014 12:08:45 -0500 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: Message-ID: <20140215170843.GB589@ferdmbp.local> One very important thing that jumped to me while writing LYSE is that it takes *forever* before getting from "I'm writing stuff in the shell and a module" to "I have a program I can call from the command-line". Since the community has apparently settled on, rebar, relx, releases, etc. There's a crapload of learning to do before tying your hands to production prototype. See how Go's toolchain works there. I know this likely gets close to your comments from an earlier e-mail -- we could show OTP sooner to get started faster -- but my objections, I think, still stand. It could be interesting to see if a tool-based approach could help. Rebar templates to set things up, relx to build the release. Bundle-in tools (eper, recon, eflame, etc?), possibly. Hell, make a beginner project template that uses raw processes and a supervisor_bridge above them to get people going *with OTP* without first needing to understand it all. This later leaves place to replacing various parts of the project without needing a total rearchitecture of all connex services running. Package management and discoverability would likely help there too. Another one, and I think this is where we lose a lot of people, is algorithms. Anybody who uses Erlang to shuttle bytes around the place for the network will tend to have a far better time than someone who comes around and decides "I'll write a game and rely on math-heavy stuff". Or even more generally, "I'll write a thing that requires an algorithm that uses arrays and assumes O(1) updates". Then, you're directly screwed. Your A* that uses a loop and a table, your vector multiplication or whatever, they all go slower than expected. Maybe maps will help, maybe not. But to me there's no doubt that functional/immutable algorithms are definitely trickier to write given the literature. Outside of Okasaki's book (which is for MLs and Haskells first, so you need to learn them to translate in Erlang!), there is nearly no source of algorithms that are not in papers. Do we need an 'algorithms in Erlang' tutorial? Don't get me wrong -- I think once you're set up, the maintainability of Erlang programs is amazingly good. I've written long blog posts on this. I also think the structure of programs (like service-oriented, but within a node) is brilliant. But before you get there, there's a shitload of hurdles to get through, and few apps or exercises targeted at beginners to help build their chops or get a good general idea. More or less, the learning curve of Erlang is Vim-like or Emacs-like. Sadly, if you want to learn Erlang, you often get told to also learn Emacs on top of it. That makes for quite a steep curve, doesn't it? Regards, Fred. On 02/15, Garrett Smith wrote: > I think this group therapy session is going well. People have > expressed important feelings and strong emotions. Others have > practiced good listening and empathy skills. > > So, looking around the circle, I'm now wondering if it makes sense to > try to summarize the problems we'd like to solve. > > Should we draft a petition to ask Ericsson to change the words behind > OTP? Some think that's a problem. I'm not here to judge. > > Should we propose to move the distribution protocol of Erlang from to > something like ZMTP? I don't hear many specific technical objections > to Erlang distribution protocol(s) but, for the future of the > language, maybe it's an important problem to look at. > > Should we wrest control of Erlang from Ericsson? For my part, the > changes over the last few years that Ericsson has driven have been > very positive for the technology and the community. But is this a case > where a dictator is only feeding and clothing us, shabbily, to keep us > from revolt? I don't know. It doesn't *feel* like a problem, or at > least not a problem that demands a revolution. > > I do have a general angst that other languages could swallow up the > community of programmers that Erlang is suited for. Go, Clojure, > Scala, JavaScript/Node, etc. -- looming territorial threats? Drum > beats through the fog? I don't know - this feels like *personal angst* > that can be solved through late night sessions of programming with > Erlang -- solving actual coding problems, putting solutions into > production, demonstrating 10x productivity over your colleagues, etc. > > For my part, I do have a specific problem, which is that I've found it > hard to get colleagues to pick up and use this language. And there are > particular reasons for that. I've observed this process: there's a > surge of interest, but then a fall off. Then back to their standard > toolkit, sans Erlang. > > I don't know if this is a problem with Erlang -- it could simply be a > function of cost/benefit. Erlang costs perhaps 3 - 6 months of > degraded productivity for a programmer. That's a lot, but I don't > think it's much different than with other languages. Then it's simply > a matter of the benefit, or perceived benefit -- does it cover the > cost? > > Regarding this problem of adoption, I can confidently say that there > are pointless barriers and friction to adoption in Erlang. The whole > topic of "how to build an application in Erlang" is *very* hard to > divine and takes time, trial, and error. That's part of that 3 - 6 > month learning curve, but it goes well beyond it. > > I know, I know. To those of you who think Erlang application > design/architecture is super straight forward, easy to spot, easy to > implement correctly -- please bear in mind that you are much smarter > than a lot of other people. Please consider middle-of-the-curve > programmers like me. > > If we can simplify and flatten the learning curve to writing canonical > Erlang applications (and, today, this means OTP compliance), it will > help adoption and help Erlang track in organizations. > > For me, this is a problem worth investing energy in, big time. That's > why there's e2. Of course there are lots of angles to invest in: > books, user groups, conferences, online resources, tools, help on > mailing lists and IRC and so on. > > Oh yeah, and rebranding OTP *of course* essential to this [1]. > > But this is just my personal problem, which I've tried to articulate > using lots of "I statements" [2]. It doesn't have to be everyone > else's. > > I would suggest that we wind this group therapy thread down, soon, and > direct our energies toward identifying specific, important, solvable > problems that we *genuinely* think are worth solving. > > [1] http://www.youtube.com/watch?v=rRbY3TMUcgQ > > [2] http://en.wikipedia.org/wiki/I-message > > On Sat, Feb 15, 2014 at 9:11 AM, mfidelman wrote: > > > > > > > > -------- Original message -------- > > From: John Kemp > > Date:02/15/2014 9:27 AM (GMT-05:00) > > To: Steve Vinoski > > Cc: erlang-questions@REDACTED > > Subject: Re: [erlang-questions] Erland users group (was re: languages in > > use? [was: Time for OTP to be Renamed?]) > > > > On 02/15/2014 09:06 AM, Steve Vinoski wrote: > > > > Well, a mechanism for increased interest and adoption is one way. An > > organization that dispels any myth that Erlang/OTP is "controlled" by > > Ericsson might be another benefit > > _______________________________________________ > > > > Sun/Oracle - Java > > Microsoft - .NET > > > > Doesn't seem to have impeded adoption. > > > > _______________________________________________ > > 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 cabo@REDACTED Sat Feb 15 14:28:31 2014 From: cabo@REDACTED (Carsten Bormann) Date: Sat, 15 Feb 2014 14:28:31 +0100 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> Message-ID: On 15 Feb 2014, at 14:08, Steve Vinoski wrote: > Sorry Pieter, but much of this paragraph is ill-informed. On 15 Feb 2014, at 14:06, Lo?c Hoguin wrote: > I do not think you are fully informed about Erlang. Most people considering whether to choose some obscure platform are somewhere between not fully informed and ill-informed. I read Pieter?s message with interest, because it provides a rather learned sample of what the perceptions are. I?d suggest other people read it with the same point of view, and focus less on how to prove Pieter wrong on this mailing list, and more on ways forward to counteract the undesirable perceptions on a wider scale. Gr??e, Carsten From eric.pailleau@REDACTED Sat Feb 15 19:57:45 2014 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sat, 15 Feb 2014 19:57:45 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? Message-ID: <52FFB8A9.8020603@wanadoo.fr> Hi Erlangers, As far almost all Erlangers in the world posted on this subject :>) ... here is my humble opinion. Open Telecom Platform, yes a bit puzzling, but I have to admit that I found Erlang, many years ago, by searching a Telecom language on Internet. I felt in love immediately with Erlang, and spent weeks to understand in what OTP was built for Telecom ... But it was like to meet your wife in a dinner you did not want to go to. OTP is not mandatory for Erlang, but : OTP avoid to re-invent ,each time, the wheel. OTP give good libraries and tools. OTP give good practices, in libraries and documentation. OTP allow apps coming from several sources to run together and being managed the same way. OTP help to keep your applications running almost forever. So, now, until this mail thread, I almost forgot what T in OTP was meaning. And for me it is just now : Open Trustworthy Platform Regards From essen@REDACTED Sat Feb 15 21:31:22 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 15 Feb 2014 21:31:22 +0100 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> Message-ID: <52FFCE9A.6050802@ninenines.eu> On 02/15/2014 02:28 PM, Carsten Bormann wrote: > I?d suggest other people read it with the same point of view, and focus less on how to prove Pieter wrong on this mailing list, and more on ways forward to counteract the undesirable perceptions on a wider scale. To make a comparison, it generally goes like this: What's Go? -> Language from Google by the Unix people -> I know and like those, therefore Go must be good too, plus it looks similar to what I'm used to. What's Erlang? -> Language from Ericsson invented 25+ years ago -> Really? I'm not sure what Ericsson does... If it was invented 25 years ago and I haven't heard about it yet it must not be very good, plus it's not OO so it must not be very useful. You can't fix that. What you can fix about perception is actually minimal stuff. Like changing the name. Using release numbers that aren't from another planet. And so on. I like to bring up MongoDB when talking about Erlang's perception. MongoDB is the slow equivalent of /dev/null. Everyone knows that, even people who use it. Yet despite this it became very popular very fast. Why? Because they could pour money down the marketing hole (plus they are marketing geniuses, seriously, read up on it). They understood that what matters most initially is *not* perception, but simply being known. And that's the problem. Nobody knows Erlang. Perception matters very little, people talking about it is what matters. If one person tells you about Erlang and how awesome it is, you will just forget about it the next day. But if you keep bumping into people who tell you all about Erlang, not only the good but also the bad, you take notice. It's nothing new really. I'm sure there's a saying somewhere about how the worst isn't being hated but being ignored. This problem can be solved, but it requires either complete marketing geniuses (no offense but what ESL is doing is not genius) or a lot of money, preferrably both. -- Lo?c Hoguin http://ninenines.eu From ali.sabil@REDACTED Sat Feb 15 21:46:13 2014 From: ali.sabil@REDACTED (Ali Sabil) Date: Sat, 15 Feb 2014 21:46:13 +0100 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <52FFCE9A.6050802@ninenines.eu> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFCE9A.6050802@ninenines.eu> Message-ID: Not a lot of money necessarily, what you want is to create awareness around Erlang first, you want the people who hear about it or see it to remember it. This effectively builds up familiarity. When you are past that point you can start thinking about explaining the benefits and advantages. Unfortunately I think that we don't focus enough in this community on the 1st step and jump directly to the 2nd. On Saturday, February 15, 2014, Lo?c Hoguin wrote: > On 02/15/2014 02:28 PM, Carsten Bormann wrote: > >> I?d suggest other people read it with the same point of view, and focus >> less on how to prove Pieter wrong on this mailing list, and more on ways >> forward to counteract the undesirable perceptions on a wider scale. >> > > To make a comparison, it generally goes like this: > > What's Go? -> Language from Google by the Unix people -> I know and like > those, therefore Go must be good too, plus it looks similar to what I'm > used to. > > What's Erlang? -> Language from Ericsson invented 25+ years ago -> Really? > I'm not sure what Ericsson does... If it was invented 25 years ago and I > haven't heard about it yet it must not be very good, plus it's not OO so it > must not be very useful. > > You can't fix that. > > What you can fix about perception is actually minimal stuff. Like changing > the name. Using release numbers that aren't from another planet. And so on. > > I like to bring up MongoDB when talking about Erlang's perception. MongoDB > is the slow equivalent of /dev/null. Everyone knows that, even people who > use it. Yet despite this it became very popular very fast. Why? Because > they could pour money down the marketing hole (plus they are marketing > geniuses, seriously, read up on it). > > They understood that what matters most initially is *not* perception, but > simply being known. And that's the problem. Nobody knows Erlang. Perception > matters very little, people talking about it is what matters. If one person > tells you about Erlang and how awesome it is, you will just forget about it > the next day. But if you keep bumping into people who tell you all about > Erlang, not only the good but also the bad, you take notice. > > It's nothing new really. I'm sure there's a saying somewhere about how the > worst isn't being hated but being ignored. > > This problem can be solved, but it requires either complete marketing > geniuses (no offense but what ESL is doing is not genius) or a lot of > money, preferrably both. > > -- > 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 ph@REDACTED Sat Feb 15 22:56:43 2014 From: ph@REDACTED (Pieter Hintjens) Date: Sat, 15 Feb 2014 22:56:43 +0100 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> Message-ID: On Sat, Feb 15, 2014 at 2:28 PM, Carsten Bormann wrote: > I read Pieter's message with interest, because it provides a rather learned sample of what the perceptions are. Thank you, Carsten. That was the goal. -Pieter From ph@REDACTED Sat Feb 15 23:02:52 2014 From: ph@REDACTED (Pieter Hintjens) Date: Sat, 15 Feb 2014 23:02:52 +0100 Subject: [erlang-questions] Erland users group (was re: languages in use? [was: Time for OTP to be Renamed?]) In-Reply-To: <52FF793C.5090908@jkemp.net> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FF6EDE.1090205@jkemp.net> <52FF793C.5090908@jkemp.net> Message-ID: On Sat, Feb 15, 2014 at 3:27 PM, John Kemp wrote: >> Having >> spent years working on various standards, I can assure you they are >> intensely political and are pretty much just an enormous waste of time. > > From the point of someone _making_ the standard, I can see that, especially > if the standard turns out not to get the widespread adoption that rewards > the effort. I know that feeling. IME this isn't inherent in standards setting. After AMQP (the disaster), Steve and I worked on RestMS, which made no splash, yet was clean and elegant and used a different standards process (the Digistan model) that avoided any arguments. We have used that model again in the ZeroMQ RFCs, and there are no flamewars. Standards are really important. Both for the language (to ensure competing implementations don't lock in users) and for protocols (to ensure competition between suppliers). -Pieter From essen@REDACTED Sat Feb 15 23:22:37 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 15 Feb 2014 23:22:37 +0100 Subject: [erlang-questions] Sharing resource types between NIFs Message-ID: <52FFE8AD.2030507@ninenines.eu> Hello, I have been looking into this and after looking into the source it doesn't seem possible, but I might as well ask just in case. Say I am writing bindings for a big library. That library is cut into various components, and I would like to do similar on the Erlang side. Components are more or less dependent. Let's just say that component B uses component A. You can't do anything in B without A. They are both NIF resources pointing to things used by the library. Now if I try to create a NIF module for A and a NIF module for B, I need to access the resource type of A from the B NIF. I tried simply exporting a function from the A .so and use it from the B .so, the function returns the resource type as expected, however using it to retrieve the resource fails. Trying to do the same from A of course works. It's just trying to use the resource type of A from B that fails. I'm assuming this isn't possible? Thanks. -- Lo?c Hoguin http://ninenines.eu From mjtruog@REDACTED Sat Feb 15 23:31:34 2014 From: mjtruog@REDACTED (Michael Truog) Date: Sat, 15 Feb 2014 14:31:34 -0800 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> Message-ID: <52FFEAC6.50308@gmail.com> On 02/15/2014 04:01 AM, Pieter Hintjens wrote: > A technology either lives, by growing and merging with others, or it > dies. Erlang is far from being a living technology and survives pretty > much thanks to a single dominant customer and investor. It claims to > be the best solution for distributed systems, yet is entirely > homogeneous, which is also an insane contradiction. Distributed > systems by definition must span space and time, or they are > LegacyAsAService. You might also want to look at http://cloudi.org . It uses an Erlang core to provide fault-tolerance to C++/C, Java, Python, Ruby, and anything else that has a CloudI API implemented for it. Erlang provides a stable distributed system development platform that provides many avenues for integration, as shown by its successes, so your complaints show your ignorance. From valentin@REDACTED Sun Feb 16 00:25:36 2014 From: valentin@REDACTED (Valentin Micic) Date: Sun, 16 Feb 2014 01:25:36 +0200 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <52FFCE9A.6050802@ninenines.eu> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFCE9A.6050802@ninenines.eu> Message-ID: <4DF2857B-4A25-4CD2-B4C1-65D329B42580@pixie.co.za> > Nobody knows Erlang. Perception matters very little, people talking about it is what matters. Matters to whom? Let's not forget that we're talking about just a programming language and nothing more (ok, with an amazing run-time system, but still?) As a general principle, people buy software to solve problems. More often than not, they buy it from the people they can trust to be able to solve these problems. If these problems can be solved by Oracle, Microsoft and/or Google, they will opt to solve them that way (and hordes of consultants will ensure that -- not much we can do about it). However, once they realize (rarely as it may be) that problems cannot be solved through these avenues, they will look for alternatives. At this point, it matters very little which programming language one uses in order to solve the problem, for as long as problems get solved -- well, assuming that problem is of such a nature that it outweighs any fashionable risk-scaremongering usually resulting in "no one gets fired for buying IBM" mentality, and that you can ensure enough of knowledge transfer to eliminate run-over-by-the-bus syndrome (a.k.a. reputable vendor). It seems to me that any organization that is in a business of problem solving by means of software, eventually outgrow its alignment with problems related to its customer base, and start increasingly worrying more about their own problems (IPO, revenue growth, etc.) After all, Microsoft et al. do not like to be told how to run your business, and that creates an opportunity for people that do. Even if you program in Klingon. Kind reagards V/ From mfidelman@REDACTED Sun Feb 16 01:05:59 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Sat, 15 Feb 2014 19:05:59 -0500 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <52FFCE9A.6050802@ninenines.eu> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFCE9A.6050802@ninenines.eu> Message-ID: <530000E7.9080103@meetinghouse.net> Lo?c Hoguin wrote: > > To make a comparison, it generally goes like this: > > What's Go? -> Language from Google by the Unix people -> I know and > like those, therefore Go must be good too, plus it looks similar to > what I'm used to. > > What's Erlang? -> Language from Ericsson invented 25+ years ago -> > Really? I'm not sure what Ericsson does... If it was invented 25 years > ago and I haven't heard about it yet it must not be very good, plus > it's not OO so it must not be very useful. > > You can't fix that. > > What you can fix about perception is actually minimal stuff. Like > changing the name. Using release numbers that aren't from another > planet. And so on. > This is just plain silly. When folks chose a language/platform for a project, the reasons tend to be: 1. We're a shop. We've invested a lot in tooling, that's what our people know. Period. 2. Our deployment environment requires it (writing iPhone apps, you're writing in Objective-C, still writing for Blackberry, Java it is) 3. Our customers require it. 4. For large, complicated projects, there may be a formal technology assessment. (E.g, Boeing didn't just stick a finger in the air and say "let's use Ada for the avionics on the 777." They did a pretty extensive technology assessment as part of the systems engineering phase of design and development.) Sometimes, this goes further - as in "there's nothing that meets our requirements, we'll develop something" (e.g., Ericsson developed Erlang to fill a need). 5. It comes embedded in a key software component (similar to 4). E.g., we selected Riak as our database platform, it's written in Erlang. (Or RabbitMQ, or CouchDB, or ...) Older languages have inertia behind them. Nobody is talking about renaming C, or spending much money marketing it. (Or the gnu build system for that matter.) Newer languages gain traction when there's a new need - Java addressed the "write once, run everywhere" vision. Hasn't quite proven to be the holy grain, but it gained a lot of traction in the process. Erlang came into being to meet a very specific requirement at Ericsson, and did it well. Newer applications have come because both requirements and hardware have evolved - and Erlang is uniquely capable of addressing them. Anybody who's building a high-availability system that is massively concurrent in nature, and does even a modicum of technology assessment, is going to find Erlang. It's name, what OTP stands for, marketing, aren't going to make a difference one way or another. On the other hand, it's longevity, community, and ecosystem will make a difference - folks don't commit large amounts of dollars to something that isn't going to be around down the road. Erlang seems to do pretty well in these regards - at least to the point that some fairly large players have committed to Erlang on key projects, and some serious venture capitalists have invested in Erlang-based ventures (Couchbase, Basho come to mind). Again, name and marketing don't really have a lot to do with this (I offer the gnu build system and CPAN as examples). As to Go - it's a toy - Google or no Google, I don't see any systems being built in it (the jury is still out on Clojure - another Google project that has a clear rational and a lot more backing). One might also wonder why Plan9 and Inferno didn't get more traction as successors to Unix and C. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From essen@REDACTED Sun Feb 16 01:58:06 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sun, 16 Feb 2014 01:58:06 +0100 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <530000E7.9080103@meetinghouse.net> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFCE9A.6050802@ninenines.eu> <530000E7.9080103@meetinghouse.net> Message-ID: <53000D1E.5090200@ninenines.eu> On 02/16/2014 01:05 AM, Miles Fidelman wrote: > Lo?c Hoguin wrote: >> >> To make a comparison, it generally goes like this: >> >> What's Go? -> Language from Google by the Unix people -> I know and >> like those, therefore Go must be good too, plus it looks similar to >> what I'm used to. >> >> What's Erlang? -> Language from Ericsson invented 25+ years ago -> >> Really? I'm not sure what Ericsson does... If it was invented 25 years >> ago and I haven't heard about it yet it must not be very good, plus >> it's not OO so it must not be very useful. >> >> You can't fix that. >> >> What you can fix about perception is actually minimal stuff. Like >> changing the name. Using release numbers that aren't from another >> planet. And so on. Just in case this wasn't clear, I'm not saying changing the name or release numbers or whatever is a good idea. I'm saying it's minimal and thus not going to change anything. > This is just plain silly. You are talking about companies, I am talking about people. Erlang is already adopted in many companies, there are more companies using Erlang than there are Erlang developers. It is a grave mistake to focus on companies at this point. What's missing is Erlang developers to work for them and for new ones that might be interested in it. It's about people. -- Lo?c Hoguin http://ninenines.eu From mfidelman@REDACTED Sun Feb 16 03:40:39 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Sat, 15 Feb 2014 21:40:39 -0500 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <53000D1E.5090200@ninenines.eu> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFCE9A.6050802@ninenines.eu> <530000E7.9080103@meetinghouse.net> <53000D1E.5090200@ninenines.eu> Message-ID: <53002527.8040701@meetinghouse.net> Lo?c Hoguin wrote: > On 02/16/2014 01:05 AM, Miles Fidelman wrote: >> Lo?c Hoguin wrote: >>> >>> To make a comparison, it generally goes like this: >>> >>> What's Go? -> Language from Google by the Unix people -> I know and >>> like those, therefore Go must be good too, plus it looks similar to >>> what I'm used to. >>> >>> What's Erlang? -> Language from Ericsson invented 25+ years ago -> >>> Really? I'm not sure what Ericsson does... If it was invented 25 years >>> ago and I haven't heard about it yet it must not be very good, plus >>> it's not OO so it must not be very useful. >>> >>> You can't fix that. >>> >>> What you can fix about perception is actually minimal stuff. Like >>> changing the name. Using release numbers that aren't from another >>> planet. And so on. > > Just in case this wasn't clear, I'm not saying changing the name or > release numbers or whatever is a good idea. I'm saying it's minimal > and thus not going to change anything. Ahh... my apologies for misinterpreting. I think we agree on this. > >> This is just plain silly. > > You are talking about companies, I am talking about people. Erlang is > already adopted in many companies, there are more companies using > Erlang than there are Erlang developers. It is a grave mistake to > focus on companies at this point. What's missing is Erlang developers > to work for them and for new ones that might be interested in it. > > It's about people. > Can we explore this a bit? In two directions: - My sense is that a lot of the comments in this thread have been about the need to promote adoption of Erlang - which is really a business/company decision, not that of individual developers (at least in my experience, it's companies that make language/platform decisions, for business reasons). It sounds like you and I agree that adoption by companies is going along just fine - but I'm not sure that's what others are saying. - It strikes me that the comment that started this branch of discussion was something along the lines of "who needs Erlang on a resume?" - or words to that effect - which is, as you say, a developer issue. I wonder three things about your assertion that "what's missing is Erlang developers:" -- Is this true? How does supply and demand for Erlang developers look right now? (Anybody from Erlang consultancies able to comment here?) -- If yes, is this perhaps a good thing for Erlang developers? (This was my earlier assertion.) Supply, demand, prices, all of that. 20 years ago, one could command big bucks for building web sites - these days, not so much. -- Does promotion actually make a difference? In my experience, there are those who are committed to one particular language - doesn't matter what language - and nothing is going to get those folks to explore another language. And then there are real engineers, who pick the right tool for the job at hand - and my sense that any good engineer who's working on high-availability, high-concurrency systems either already knows about Erlang, or will find it pretty quickly when doing technology assessment for a project with requirements that are best suited for Erlang (mind you "good engineers" are not all that easy to come by, particularly when it comes to the kinds of big, complicated systems that Erlang is best suited to - but that's a far broader issue than finding coders with Erlang skills) -- On a related note: A lot of this comes down to computer science education. 40 years ago (I'm showing my age), a typical computer science curriculum included quite a bit of language design theory, and experience with a range of languages (anybody else remember using "Structure and Interpretation of Computer Programs" as a 1st-year text?) - these days, not so much. I see an awful lot of people who took a couple of courses in Java who think they're computer scientists - but ask them about "actors" or "lambda expressions" and you get a glazed expressions. (Real software engineers read lambda-the-ultimate.org ?) Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From drew.varner@REDACTED Sun Feb 16 05:10:48 2014 From: drew.varner@REDACTED (Drew Varner) Date: Sat, 15 Feb 2014 23:10:48 -0500 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <53000D1E.5090200@ninenines.eu> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFCE9A.6050802@ninenines.eu> <530000E7.9080103@meetinghouse.net> <53000D1E.5090200@ninenines.eu> Message-ID: Maybe it's just the US, but I find postings for Erlang jobs few and far between. I see plenty of Scala jobs that value Erlang experience, but where the primary role is to work in the language. - Drew > On Feb 15, 2014, at 7:58 PM, Lo?c Hoguin wrote: > >> On 02/16/2014 01:05 AM, Miles Fidelman wrote: >> Lo?c Hoguin wrote: >>> >>> To make a comparison, it generally goes like this: >>> >>> What's Go? -> Language from Google by the Unix people -> I know and >>> like those, therefore Go must be good too, plus it looks similar to >>> what I'm used to. >>> >>> What's Erlang? -> Language from Ericsson invented 25+ years ago -> >>> Really? I'm not sure what Ericsson does... If it was invented 25 years >>> ago and I haven't heard about it yet it must not be very good, plus >>> it's not OO so it must not be very useful. >>> >>> You can't fix that. >>> >>> What you can fix about perception is actually minimal stuff. Like >>> changing the name. Using release numbers that aren't from another >>> planet. And so on. > > Just in case this wasn't clear, I'm not saying changing the name or release numbers or whatever is a good idea. I'm saying it's minimal and thus not going to change anything. > >> This is just plain silly. > > You are talking about companies, I am talking about people. Erlang is already adopted in many companies, there are more companies using Erlang than there are Erlang developers. It is a grave mistake to focus on companies at this point. What's missing is Erlang developers to work for them and for new ones that might be interested in it. > > It's about people. > > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vances@REDACTED Sun Feb 16 09:15:22 2014 From: vances@REDACTED (Vance Shipley) Date: Sun, 16 Feb 2014 13:45:22 +0530 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <52FBFC07.8010007@ninenines.eu> <52FC8850.2000902@llaisdy.com> Message-ID: <20140216081522.GD96250@wavenets-mbp.motivity.ca> On Thu, Feb 13, 2014 at 07:15:54PM +0100, Joe Armstrong wrote: } OTP was designed for teams of programmers, so that they would all write } their code the same way and use common tools for code loading, error } logging, supervision and so on. And this is the power of the environment. At the end of the day this is the stuff that put it behind important business applications. This is how it got funded in Ericsson and how it got to be behind infrastructure at well known companies. This is why we're talking about, and using, Erlang today. Otherwise it would be cool and interesting in the same way that Limbo and Plan 9 were but nobody would be using it at work. } There is absolutely nothing stopping you from supervising and restarting } programs using spawn_link and trapping exits. Your boss may be stopping you. I certainly am in my organization. } - beginners should start with spawn and spawn_link then learn to trap } exits and then learn that they can replace a lot of simple boilerplate } code with the OTP equivalents. It is interesting that we start teaching Erlang by introducing send and receive and then as soon as we start writing applications we tell them never to do that again. It's not until you have mastered OTP that you can recognize where you can handle things better yourself. Most people never get there. Now mind you I'm not talking about scripts but actual applications which should run whenever the server is running. For that you want OTP and if you are putting a 'receive' statement in your program you are (probably) not writing OTP compliant code. -- Changing the name is not going to happen and makes no sense anyway. It's a simple message to say that the problems of the telephone industry are the same ones the software industry as a whole is facing now with as we consume cloud services and computers incorporate more and more cores. You could practically add another name and shift the focus to that. I don't see this as necessary but then I'm old school. -- -Vance From ph@REDACTED Sun Feb 16 09:43:16 2014 From: ph@REDACTED (Pieter Hintjens) Date: Sun, 16 Feb 2014 09:43:16 +0100 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <52FFEAC6.50308@gmail.com> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFEAC6.50308@gmail.com> Message-ID: On Sat, Feb 15, 2014 at 11:31 PM, Michael Truog wrote: > Erlang provides a stable > distributed system development platform that provides many avenues for > integration, as shown by its successes, so your complaints show your > ignorance. Good job on smacking down my ignorant complaints. I feel chastised and would slink back to silent observation of Erlang's slow demise at the hands of people who always know better. Except, I will take the bait. Cloudi looks valiant in a tragic fashion. A 1-person project still in beta that uses REST as its messaging carrier. How can I count the ways this will fail? Anyone looking for a HTTP-based cloud will use Open Stack, period. Anyone smart will be thinking of new designs based on much cheaper distributed messaging. People broadly either embrace risk (then won't use this), or hate risk (then won't use this). Erlang's unique status used to be, we understand distributed systems. Today that's changed. There are many other ways to make distributed systems, more cheaply, more successfully. Erlang either gets its cost model way down, or it dies. Quote me on that if you like. Our industry has no pity for excess friction, and you have competitors. I think this thread is really important. And the questions should not be "what is Erlang called", since that's trivial to solve (just stop saying "OTP" in polite company). The question should be, "where are there friction costs and how can we remove them?" My example of outreach to other languages is about friction costs. If it's trivial to integrate polyglot languages with Erlang, friction costs fall right away. Smacking down the ignorant won't remove friction costs. Cheers Pieter From vances@REDACTED Sun Feb 16 10:13:44 2014 From: vances@REDACTED (Vance Shipley) Date: Sun, 16 Feb 2014 14:43:44 +0530 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> <52FD0B24.50400@meetinghouse.net> <52FD0C14.6060004@meetinghouse.net> Message-ID: <20140216091344.GF96250@wavenets-mbp.motivity.ca> On Thu, Feb 13, 2014 at 12:22:54PM -0600, kraythe . wrote: } Not so much the issue of OTP as a name but the general impression of } "adoption? bah humbug ... if they don't like it they all suck and we } don't care." Sounds like a disaster of a business decision to me. Erlang has always been a very practical thing. It is a functional language, but not purely so. It's developers have always chosen the path which made sense for it's commercial use. It's not a language made to teach computer science courses, it's made to be as useful as possible to build real life commercial applications. It's rooted in industry. You're questioning the business decisions of a company which has been at this for over two decades. } Im not so sure its going to be easy to staff or finance a project on a } language that has 1) tools that need work, 2) a limited trained staff 3) a } community that cares little about language adoption. It could be that } Erlang becomes another Lisp for me. A language I think rocks but is } entirely impractical in the business world. My greatest wish is that any potential competitor of mine believes all of the FUD above. The truth is (my competitors shouldn't trust me, I'm probably lying) that Erlang/OTP is a very practical platform for many business applications. It provides a rapid development environment for reliable and scalable applications. It's battle hardened in the demanding communications service provider industry. If you're building cloud services or other massively concurrent applications you will get a lot of stuff for free. There is a barrier to entry here, but it's mostly a phycological one. Yes, you need to learn about functional programming and OTP however at the end of the day you're still much, much further ahead than if you start writing the code you are productive at today and reinvent (poorly) much of the functionality of OTP. A few months in and you have learned how to implement new business problems quickly and easily at scale. For the most part I don't hire people for what they already know (beyond computer literacy). I hire them because they've demonstrated an ability to learn. I'd rather take on someone who has learned a bit of many languages than the master of one. A good hire is someone who considers themselves a software engineer and not a Java(/whatever) coder. It's true that many employees will be concerned about their resumes and a few years of Erlang experience may not seem that marketable to them. In reality though these are the folks who have less value us. ... and speaking of Lisp, this is a great read: http://paulgraham.com/avg.html -- -Vance From jocke@REDACTED Sun Feb 16 10:40:52 2014 From: jocke@REDACTED (=?ISO-8859-1?Q?Joacim_Greben=F6?=) Date: Sun, 16 Feb 2014 10:40:52 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? Message-ID: <20140216094054.047E4240C1F1@mail.tail-f.com> The gen_server takes away all the fun. Den 16 feb 2014 09:15 skrev Vance Shipley : > > On Thu, Feb 13, 2014 at 07:15:54PM +0100, Joe Armstrong wrote: > }? OTP was designed for teams of programmers, so that they would all write > }? their code the same way and use common tools for code loading, error > }? logging, supervision and so on. > > And this is the power of the environment.? At the end of the day this is > the stuff that put it behind important business applications.? This is > how it got funded in Ericsson and how it got to be behind infrastructure > at well known companies.? This is why we're talking about, and using, > Erlang today.? Otherwise it would be cool and interesting in the same > way that Limbo and Plan 9 were but nobody would be using it at work. > > }? There is absolutely nothing stopping you from supervising and restarting > }? programs using spawn_link and trapping exits. > > Your boss may be stopping you.? I certainly am in my organization. > > }? - beginners should start with spawn and spawn_link then learn to trap > }? exits and then learn that they can replace a lot of simple boilerplate > }? code with the OTP equivalents. > > It is interesting that we start teaching Erlang by introducing send and > receive and then as soon as we start writing applications we tell them > never to do that again.? It's not until you have mastered OTP that you > can recognize where you can handle things better yourself.? Most people > never get there.? Now mind you I'm not talking about scripts but actual > applications which should run whenever the server is running.? For that > you want OTP and if you are putting a 'receive' statement in your program > you are (probably) not writing OTP compliant code. > > -- > > Changing the name is not going to happen and makes no sense anyway. > It's a simple message to say that the problems of the telephone industry > are the same ones the software industry as a whole is facing now with as > we consume cloud services and computers incorporate more and more cores. > > You could practically add another name and shift the focus to that.? I > don't see this as necessary but then I'm old school. > > -- > -Vance > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vances@REDACTED Sun Feb 16 10:52:31 2014 From: vances@REDACTED (Vance Shipley) Date: Sun, 16 Feb 2014 15:22:31 +0530 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <20140216094054.047E4240C1F1@mail.tail-f.com> References: <20140216094054.047E4240C1F1@mail.tail-f.com> Message-ID: <20140216095231.GG96250@wavenets-mbp.motivity.ca> On Sun, Feb 16, 2014 at 10:40:52AM +0100, Joacim Greben? wrote: } The gen_server takes away all the fun. It does, true. If you want to write pure Erlang and still play by the (OTP) rules you can use plain_fsm(*) or sys_fsm(+) or write it yourself. Not using OTP behaviours is just harder to get right and much less tested. (+) http://erlang.org/pipermail/erlang-questions/2004-February/011405.html (*) http://erlang.org/pipermail/erlang-questions/2005-April/015226.html -- -Vance From jocke@REDACTED Sun Feb 16 11:06:08 2014 From: jocke@REDACTED (=?ISO-8859-1?Q?Joacim_Greben=F6?=) Date: Sun, 16 Feb 2014 11:06:08 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? Message-ID: <20140216100609.6AA1A240C1F1@mail.tail-f.com> I would only use the gen_server iff I needed hot code loading/upgrading. In the real world, and in the majority of cases, that seldom is needed. IMHO and within my experience of course. Den 16 feb 2014 10:52 skrev Vance Shipley : > > On Sun, Feb 16, 2014 at 10:40:52AM +0100, Joacim Greben? wrote: > }? The gen_server takes away all the fun. > > It does, true.? If you want to write pure Erlang and still play > by the (OTP) rules you can use plain_fsm(*) or sys_fsm(+) or > write it yourself.? Not using OTP behaviours is just harder to > get right and much less tested. > > (+) http://erlang.org/pipermail/erlang-questions/2004-February/011405.html > (*) http://erlang.org/pipermail/erlang-questions/2005-April/015226.html > > -- > -Vance From essen@REDACTED Sun Feb 16 11:33:28 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sun, 16 Feb 2014 11:33:28 +0100 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <53002527.8040701@meetinghouse.net> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFCE9A.6050802@ninenines.eu> <530000E7.9080103@meetinghouse.net> <53000D1E.5090200@ninenines.eu> <53002527.8040701@meetinghouse.net> Message-ID: <530093F8.5090401@ninenines.eu> On 02/16/2014 03:40 AM, Miles Fidelman wrote: > - My sense is that a lot of the comments in this thread have been about > the need to promote adoption of Erlang - which is really a > business/company decision, not that of individual developers (at least > in my experience, it's companies that make language/platform decisions, > for business reasons). ... > any good engineer who's > working on high-availability, high-concurrency systems either already > knows about Erlang, or will find it pretty quickly when doing technology > assessment for a project with requirements that are best suited for > Erlang It's companies that make decisions, but it's developers that introduce companies to the different choices they have. There's indeed a fair amount of chances that someone working in HA at least heard about it. There's no real need to target them. Everyone else though? Ask any 9-to-5 developer if they heard of Erlang. You will get very few positive answers. And if you are the only one who heard about it in a company, then it's never going to be used even if it's the perfect tool for the job. Erlang can be used for anything server, not just HA. Erlang could replace PHP or Ruby or whatever and do so while also saving costs (less developers needed, less/smaller servers, etc). If only enough people even heard about it. The other thing is that Erlang lacks in (properly maintained) libraries. Getting Erlang known beyond what's it's historically good at is what needs to be done to fix this. Because if it's only used by HA people then you'll just get more process registries, pools, distributed frameworks and such. Which is great when you're building an HA system. But not so much when you need to output Excel files for accounting, or crop and resize an image, or send an SMS. Which is the kind of tasks that most developers spend their time doing. > -- Is this true? How does supply and demand for Erlang developers look > right now? (Anybody from Erlang consultancies able to comment here?) Right now I don't know but about a year ago I heard the number of 400 Erlang developers needed in the Bay area alone. I assume of course that this includes companies that would be interested in using Erlang if only there was developers to hire. US companies that do use Erlang today are forced either to look in Europe and elsewhere (Basho and Ubiquiti Networks do this AFAIK), or train their staff (that's what the evening school of Erlang was about). > -- On a related note: A lot of this comes down to computer science > education. Definitely. -- Lo?c Hoguin http://ninenines.eu From vances@REDACTED Sun Feb 16 11:40:38 2014 From: vances@REDACTED (Vance Shipley) Date: Sun, 16 Feb 2014 16:10:38 +0530 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <20140216100609.6AA1A240C1F1@mail.tail-f.com> References: <20140216100609.6AA1A240C1F1@mail.tail-f.com> Message-ID: <20140216104038.GH96250@wavenets-mbp.motivity.ca> On Sun, Feb 16, 2014 at 11:06:08AM +0100, Joacim Greben? wrote: } I would only use the gen_server iff I needed hot code loading/upgrading. } In the real world, and in the majority of cases, that seldom is needed. } } IMHO and within my experience of course. Lest other, less experienced, readers get the impression that it is that simple let me just provide this pointer: http://www.erlang.org/doc/design_principles/spec_proc.html To write a program which will work (properly) in an OTP compliant system, you must receive and handle a number of system messages. Without OTP compliance you have no supervision, debugging, release handling, observer and I don't know what else. You are free to do so but I wouldn't recommend this route for anyone else who hasn't mastered the environment. -- -Vance From ph@REDACTED Sun Feb 16 12:08:55 2014 From: ph@REDACTED (Pieter Hintjens) Date: Sun, 16 Feb 2014 12:08:55 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <20140215170843.GB589@ferdmbp.local> References: <20140215170843.GB589@ferdmbp.local> Message-ID: On Sat, Feb 15, 2014 at 6:08 PM, Fred Hebert wrote: > That makes for quite a steep curve, doesn't it? This is a core problem. It is an uncanny valley; before you can get those theoretical productivity gains you have to make large investments. We had this experience in the ZeroMQ community (where I take many of my lessons from), and the principal lesson was that although there are sufficient very smart people to help with the hardest problems, the real life comes from passers-by who learn rapidly in an easy environment, and get benefit from day one. Decreasing slices of these people then stick around and learn more and more. If you scare off the tourists, you cut the number of solid contributors sharply. This has killed many technically brilliant projects. Indeed, technical brilliance is one of the best ways to scare away contributors. Bumbling sincerity beats code quality any time of day. It's not snowing in Belgium. However, community building is the same problem in any country. Remove barriers, remove confusion, create competition, encourage people to work together instead of reinventing the same answers over and over. Create space for specialization and profit. Open up communications. Standardize obsessively. Spread ownership and decision making as widely as possible. The ex-cathedra model can't compete with the rabble in the marketplace. So Erlang's greatest challenge IMO is simply shifting away from the top down "we decide for you" model to one that is driven by users. If there's no shift in power by Erlang's current owners to a real community driven thinking process, the other options would be to fork the entire language and open it up, or allow it to die. To present this choice as (a) Ericsson or (b) Random Stupid Committee is a false dichotomy. The correct answer is (c) collective ownership and decision making with no single points of failure. It's no coincidence that the only sustainable organizational model for building distributed systems is itself a distributed system. Which the Erlang community isn't, today. IMO Erlang is trying to deny Conway's law. It's like trying to deny gravity. Face, let me introduce you to Ground. Let's see who wins. I'd love to learn Erlang, mainly because of the people who use it. However I'm lazy and modest in my investments and can't spend six months to see profit in a project. I won't use tools I can't improve myself. I won't join communities where I depend on others for decision making. No complaints here. Just observation and comment based on watching a tragic number of good projects die because people didn't raise their heads up and ask some basic questions about relevance to the market. -Pieter From jocke@REDACTED Sun Feb 16 12:28:43 2014 From: jocke@REDACTED (=?ISO-8859-1?Q?Joacim_Greben=F6?=) Date: Sun, 16 Feb 2014 12:28:43 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? Message-ID: <20140216112847.0E341240C1F1@mail.tail-f.com> I have read http://www.erlang.org/doc/design_principles/spec_proc.html over the years and only opted to implement parts of all the overhead, i.e. to get the part of OTP functionality I really need and no more. The gen_server is is top heavy and boring and remindes me of Java Enterprise Beans. Agile and fun is better than top heavy and boring. In the short run, and in the long run. But this is all me. Den 16 feb 2014 11:40 skrev Vance Shipley : > > On Sun, Feb 16, 2014 at 11:06:08AM +0100, Joacim Greben? wrote: > }? I would only use the gen_server iff I needed hot code loading/upgrading. > }? In the real world, and in the majority of cases, that seldom is needed. > }? > }? IMHO and within my experience of course. > > Lest other, less experienced, readers get the impression that it is that > simple let me just provide this pointer: > > ?? http://www.erlang.org/doc/design_principles/spec_proc.html > > To write a program which will work (properly) in an OTP compliant system, > you must receive and handle a number of system messages.? Without OTP > compliance you have no supervision, debugging, release handling, observer > and I don't know what else.? You are free to do so but I wouldn't recommend > this route for anyone else who hasn't mastered the environment. > > -- > -Vance From jesper.louis.andersen@REDACTED Sun Feb 16 12:28:46 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Sun, 16 Feb 2014 12:28:46 +0100 Subject: [erlang-questions] Erland users group (was re: languages in use? [was: Time for OTP to be Renamed?]) In-Reply-To: <52FF6EDE.1090205@jkemp.net> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FF6EDE.1090205@jkemp.net> Message-ID: On Sat, Feb 15, 2014 at 2:42 PM, John Kemp wrote: > How does this "industrial Erlang users group" relate to that? Or the EEP > process? Are these things related, and/or, should they be? Process changes work like super tankers. You don't turn around in 2 seconds. The "Industrial Erlang users group" is a welcome move toward a vision in which the Erlang community becomes more coherent and standardized. But it will be a long process and you need to have a bit of patience with what the process achieves. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jocke@REDACTED Sun Feb 16 12:41:58 2014 From: jocke@REDACTED (=?ISO-8859-1?Q?Joacim_Greben=F6?=) Date: Sun, 16 Feb 2014 12:41:58 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? Message-ID: <20140216114402.8130F240C4FB@mail.tail-f.com> Note. I love the Erlang SDK (just trying avoid the *TP word to see how it feels) and use it heavily. It is just the gen_server that takes away the fun. We need more fun and not less. Den 16 feb 2014 12:28 skrev =?ISO-8859-1?Q?Joacim_Greben=F6?= : > > I have read http://www.erlang.org/doc/design_principles/spec_proc.html over the years and only opted to implement parts of all the overhead, i.e. to get the part of OTP functionality I really need and no more. > > The gen_server is is top heavy and boring and remindes me of Java Enterprise Beans. > > Agile and fun is better than top heavy and boring. In the short run, and in the long run. > > But this is all me. > > Den 16 feb 2014 11:40 skrev Vance Shipley : > > > > On Sun, Feb 16, 2014 at 11:06:08AM +0100, Joacim Greben? wrote: > > }? I would only use the gen_server iff I needed hot code loading/upgrading. > > }? In the real world, and in the majority of cases, that seldom is needed. > > }? > > }? IMHO and within my experience of course. > > > > Lest other, less experienced, readers get the impression that it is that > > simple let me just provide this pointer: > > > > ?? http://www.erlang.org/doc/design_principles/spec_proc.html > > > > To write a program which will work (properly) in an OTP compliant system, > > you must receive and handle a number of system messages.? Without OTP > > compliance you have no supervision, debugging, release handling, observer > > and I don't know what else.? You are free to do so but I wouldn't recommend > > this route for anyone else who hasn't mastered the environment. > > > > -- > > -Vance > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From jesper.louis.andersen@REDACTED Sun Feb 16 12:48:39 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Sun, 16 Feb 2014 12:48:39 +0100 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFEAC6.50308@gmail.com> Message-ID: Let me add that distribution means one of two things: LAN distribution or WAN distribution. In the former case, the network can be considered ample bandwidth, low latency, only with mild duplication, packet loss, reordering characteristics and so on. On the other hand, the WAN situation is almost the opposite of that, except perhaps for the bandwidth part. Erlang solved the distribution for the LAN part pretty well, but the WAN part is vastly different. Yet I think that the Erlang tools are among the best for handling distribution. And I must say I, on a daily basis, can point to newly written code and go "Yes, that was solved, 15 years ago in Erlang... better". Erlangs unique status is not "we understand distributed systems" insofar as the other major points in Bjarne Deckers thesis[0]. It is the conglomerate of every decision which makes a language. This is also why a language like Go is awesome, but gives you programs written in a much different style than in Erlang. The problem with 6 different implementations of ZMQ mostly stems from a number of typical social problems in Erlang: * One developer is enough, so you will write the full system yourself. This is also the problem for Haskell, Clojure, Common Lisp, etc, but not Java, C#, ... * No separation of the protocol from the concurrency mechanisms in the code base. This means you can't plug-in other concurrency models with different guarantees, and so you are forced to reinvent the wheel. A really good example is the new pure-erlang-zmq implementation. But also the Erlang emysql driver has the same problem. Thus the different implementations are equal in the protocol handling parts, but they differ in how they handle concurrency on top. * We don't want a NIF. We do want a NIF. jiffy is a much faster JSON library than jsx, but jsx is written in pure Erlang. If you are going for speed, then surely jiffy is the best. If you are going for low-latency operation and proper preemption, then jsx wins. [0] rambled on this a couple of years ago. The links are 1 hop away from this http://jlouisramblings.blogspot.be/2012/10/ramblings-on-thesis-of-bjarne-dacker.html On Sun, Feb 16, 2014 at 9:43 AM, Pieter Hintjens wrote: > On Sat, Feb 15, 2014 at 11:31 PM, Michael Truog wrote: > > > Erlang provides a stable > > distributed system development platform that provides many avenues for > > integration, as shown by its successes, so your complaints show your > > ignorance. > > Good job on smacking down my ignorant complaints. I feel chastised and > would slink back to silent observation of Erlang's slow demise at the > hands of people who always know better. Except, I will take the bait. > > Cloudi looks valiant in a tragic fashion. A 1-person project still in > beta that uses REST as its messaging carrier. How can I count the ways > this will fail? Anyone looking for a HTTP-based cloud will use Open > Stack, period. Anyone smart will be thinking of new designs based on > much cheaper distributed messaging. People broadly either embrace risk > (then won't use this), or hate risk (then won't use this). > > Erlang's unique status used to be, we understand distributed systems. > Today that's changed. There are many other ways to make distributed > systems, more cheaply, more successfully. > > Erlang either gets its cost model way down, or it dies. Quote me on > that if you like. Our industry has no pity for excess friction, and > you have competitors. > > I think this thread is really important. And the questions should not > be "what is Erlang called", since that's trivial to solve (just stop > saying "OTP" in polite company). The question should be, "where are > there friction costs and how can we remove them?" > > My example of outreach to other languages is about friction costs. If > it's trivial to integrate polyglot languages with Erlang, friction > costs fall right away. > > Smacking down the ignorant won't remove friction costs. > > Cheers > Pieter > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james@REDACTED Sun Feb 16 14:11:18 2014 From: james@REDACTED (james) Date: Sun, 16 Feb 2014 13:11:18 +0000 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <52FE02AC.2080706@meetinghouse.net> References: <52FE02AC.2080706@meetinghouse.net> Message-ID: <5300B8F6.7050603@mansionfamily.plus.com> On 14/02/2014 11:49, Miles Fidelman wrote: > Seems to me that scarcity is a GOOD thing for Erlang programmers. Java > coders are a dime a dozen (not necessarily good ones, mind you). Folks > who know Erlang are harder to find - should drive the price up. That does not seem to be the case in London. From n.oxyde@REDACTED Sun Feb 16 14:24:40 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 16 Feb 2014 14:24:40 +0100 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <53002527.8040701@meetinghouse.net> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFCE9A.6050802@ninenines.eu> <530000E7.9080103@meetinghouse.net> <53000D1E.5090200@ninenines.eu> <53002527.8040701@meetinghouse.net> Message-ID: <38DD45A2-AE60-4D39-9F33-ECB6363B46FC@gmail.com> I don?t, being 26 years old. I do know the book though. It amuses me how many of the Java developers you decry also chastise academia and their ivory towers while my own experience tells me I would know virtually nothing about either programming language theory or compilers if I didn?t go to university. Heck, some of my courses were even taught by OCaml core contributors. That was just a small addendum from a former university student who was tired these days to read academia compared to something as useful as a Curling player without his broom. -- Anthony Ramine Le 16 f?vr. 2014 ? 03:40, Miles Fidelman a ?crit : > -- On a related note: A lot of this comes down to computer science education. 40 years ago (I'm showing my age), a typical computer science curriculum included quite a bit of language design theory, and experience with a range of languages (anybody else remember using "Structure and Interpretation of Computer Programs" as a 1st-year text?) - these days, not so much. I see an awful lot of people who took a couple of courses in Java who think they're computer scientists - but ask them about "actors" or "lambda expressions" and you get a glazed expressions. (Real software engineers read lambda-the-ultimate.org?) From mfidelman@REDACTED Sun Feb 16 14:56:54 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Sun, 16 Feb 2014 08:56:54 -0500 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> Message-ID: <5300C3A6.6000000@meetinghouse.net> Pieter Hintjens wrote: > On Sat, Feb 15, 2014 at 6:08 PM, Fred Hebert wrote: > >> That makes for quite a steep curve, doesn't it? > This is a core problem. It is an uncanny valley; before you can get > those theoretical productivity gains you have to make large > investments. That seems like a red herring to me. Is the learning curve really that steep? Yes, there can be a big hurdle involved in learning to think functionally - but that's language independent. Same again for thinking in terms of actors and massive concurrency rather than procedures, or objects and classes - again, that's language independent. Beyond that, most of the real learning time and investment for a new language involves learning libraries, the build system, and run-time environments: - going from "hello, world" in c, to building complete, deployable, maintainable systems involves quite a bit (what's the investment in learning the gnu build system?) - Java isn't appreciably better in that regard - and so forth And then there's all the brou ha ha about DevOps these days - building tool chains for rapid deployment of code that keep changing. Interpretive languages change the mix a bit - given that some steps are dropped out. Platforms also change things a bit. (E.g., start with a running copy of Apache, add a PHP script. Simplifies things a bit once you've learned the ins and outs of Apache.) It strikes me that Erlang might actually require less learning than many environments - in that OTP provides a platform for wiring together complex systems, and deploying them into a run-time environment that also solves a lot of problems for you. Yes you have to learn how they work, and how to use them - but then again, you don't have to re-invent them. > I'd love to learn Erlang, mainly because of the people who use it. > However I'm lazy and modest in my investments and can't spend six > months to see profit in a project. I won't use tools I can't improve > myself. I won't join communities where I depend on others for decision > making. Or maybe you don't work on problems where the cost/benefit equation makes it worth using Erlang? If your baseline is 'profit in six months,' you're working pretty small projects. For me, it's been at least a decade since I've worked anything where coding has started in less than 6 months after contract award - there's always a huge amount of system level design that goes first, including things like picking which platform to work with. The cost-benefit equation is VERY different when comparing, say: - a small e-commerce site - a large e-commerce site coupled to multi-vendor supply chain management - a transaction processing system - a telecom switch - avionics for a new passenger jet And with all but the first, long-term operation and maintenance considerations dwarf the time and dollars required to develop the system (or should - there are some great examples of spectacular failures that have eaten up billions of dollars before being cancelled - like the FBI case file system). For products (again, telecom switches come to mind), a lot of time and capital go in before a dollar of profit is seen. Somehow, I simply don't see Erlang being relevant if your decision criteria is "can't spend six months to see profit in a project." Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From n.oxyde@REDACTED Sun Feb 16 15:09:41 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 16 Feb 2014 15:09:41 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> Message-ID: <7A23EC4B-630D-4C04-AD93-039726E18332@gmail.com> Replied inline. -- Anthony Ramine Le 16 f?vr. 2014 ? 12:08, Pieter Hintjens a ?crit : > The ex-cathedra model can't compete with the rabble in the > marketplace. So Erlang's greatest challenge IMO is simply shifting > away from the top down "we decide for you" model to one that is driven > by users. > > If there's no shift in power by Erlang's current owners to a real > community driven thinking process, the other options would be to fork > the entire language and open it up, or allow it to die. > > To present this choice as (a) Ericsson or (b) Random Stupid Committee > is a false dichotomy. The correct answer is (c) collective ownership > and decision making with no single points of failure. > > It's no coincidence that the only sustainable organizational model for > building distributed systems is itself a distributed system. Which the > Erlang community isn't, today. Do you mean that truly evil OTP team who sometimes postpone *their very own patches* so that they can apply *mine*, even though I am just a *third-party* contributor with no company to take care of? The team do not decide for their users, they just ask them why do they want this or that change, and that?s a very very good thing. Also, what is a distributed community? > I'd love to learn Erlang, mainly because of the people who use it. > However I'm lazy and modest in my investments and can't spend six > months to see profit in a project. I won't use tools I can't improve > myself. I won't join communities where I depend on others for decision > making. That makes no sense, you won?t be part of decision making if you don?t join the community. How do you explain that I managed to make maps be merged later just with a single patch if they don?t take into account the outsiders from the community? There is also intrinsic value in learning a new tool, even if you won?t use it later. Let?s not even mention that you need more than six months to learn all the huge Java ecosystem. > No complaints here. Just observation and comment based on watching a > tragic number of good projects die because people didn't raise their > heads up and ask some basic questions about relevance to the market. Erlang is not going to die any time soon. From mfidelman@REDACTED Sun Feb 16 15:10:32 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Sun, 16 Feb 2014 09:10:32 -0500 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <20140216091344.GF96250@wavenets-mbp.motivity.ca> References: <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> <52FD0B24.50400@meetinghouse.net> <52FD0C14.6060004@meetinghouse.net> <20140216091344.GF96250@wavenets-mbp.motivity.ca> Message-ID: <5300C6D8.5080306@meetinghouse.net> Vance Shipley wrote: > On Thu, Feb 13, 2014 at 12:22:54PM -0600, kraythe . wrote: > } Not so much the issue of OTP as a name but the general impression of > } "adoption? bah humbug ... if they don't like it they all suck and we > } don't care." Sounds like a disaster of a business decision to me. > > Erlang has always been a very practical thing. It is a functional > language, but not purely so. It's developers have always chosen the > path which made sense for it's commercial use. It's not a language > made to teach computer science courses, it's made to be as useful as > possible to build real life commercial applications. It's rooted in > industry. You're questioning the business decisions of a company which > has been at this for over two decades. > > } Im not so sure its going to be easy to staff or finance a project on a > } language that has 1) tools that need work, 2) a limited trained staff 3) a > } community that cares little about language adoption. It could be that > } Erlang becomes another Lisp for me. A language I think rocks but is > } entirely impractical in the business world. > > My greatest wish is that any potential competitor of mine believes all > of the FUD above. > > The truth is (my competitors shouldn't trust me, I'm probably lying) that > Erlang/OTP is a very practical platform for many business applications. > I like the way you think! (On a lighter note: http://xkcd.com/1330/) -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mfidelman@REDACTED Sun Feb 16 15:37:15 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Sun, 16 Feb 2014 09:37:15 -0500 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <530093F8.5090401@ninenines.eu> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFCE9A.6050802@ninenines.eu> <530000E7.9080103@meetinghouse.net> <53000D1E.5090200@ninenines.eu> <53002527.8040701@meetinghouse.net> <530093F8.5090401@ninenines.eu> Message-ID: <5300CD1B.4030503@meetinghouse.net> Lo?c Hoguin wrote: > On 02/16/2014 03:40 AM, Miles Fidelman wrote: >> - My sense is that a lot of the comments in this thread have been about >> the need to promote adoption of Erlang - which is really a >> business/company decision, not that of individual developers (at least >> in my experience, it's companies that make language/platform decisions, >> for business reasons). > ... > > any good engineer who's > > working on high-availability, high-concurrency systems either already > > knows about Erlang, or will find it pretty quickly when doing > technology > > assessment for a project with requirements that are best suited for > > Erlang > > It's companies that make decisions, but it's developers that introduce > companies to the different choices they have. There's indeed a fair > amount of chances that someone working in HA at least heard about it. > There's no real need to target them. > > Everyone else though? Ask any 9-to-5 developer if they heard of > Erlang. You will get very few positive answers. And if you are the > only one who heard about it in a company, then it's never going to be > used even if it's the perfect tool for the job. Serious question: Is it really the "9-to-5" developer who makes this kind of choice, or even has much influence? In my experience it's more likely to be a systems architect, or CTO, or "chief technologist," or some such who makes serious platform-level choices (or the founders, when it comes to startups). And these are folks who, if any good, keep abreast of what technologies are available. On the other hand, the skill set of a firm's developers, and previous investment in tooling and code base influence such choices. (Which makes it easier for either a startup, or a major new effort to pick a new platform, than, say, a project that's adding features to the next generation of something built on .NET) > > Erlang can be used for anything server, not just HA. Erlang could > replace PHP or Ruby or whatever and do so while also saving costs > (less developers needed, less/smaller servers, etc). If only enough > people even heard about it. > > The other thing is that Erlang lacks in (properly maintained) > libraries. Getting Erlang known beyond what's it's historically good > at is what needs to be done to fix this. Because if it's only used by > HA people then you'll just get more process registries, pools, > distributed frameworks and such. Which is great when you're building > an HA system. But not so much when you need to output Excel files for > accounting, or crop and resize an image, or send an SMS. Which is the > kind of tasks that most developers spend their time doing. Now that is a serious issue. Erlang certainly can replace PHP or Ruby for a lot of things, IF there were good libraries - and that's an issue. On the other hand, it's not quite clear that the cost/benefits work out. Seems like it would depend on the kind of server: - new protocol that has to run across a global network of systems (let's say for distributed supply chain support) - definitely - mid-complexity web server (where PHP and Ruby seem to show up) - I'd be more likely to pick a platform, and whatever language it's written in would come along for the ride, and the platform choice would likely be driven by considerations of what's already in place (can you say ASP.Net?) - then again, PERL still shines here, mostly because of CPAN (Mind you, I would not complain a bit if someone where to write a good mail system and/or list manager in Erlang - but as long as there's Postfix and Sympa, not sure it's worth anybody's time to do so). And, while typing that last bullet, I begin to wonder - is it really libraries, or these days is it more "platform?" For example, when I think about large-scale data mining applications, I'm thinking more along the lines of: 1. SQL vs. NoSQL 2. Which database engine 3. What visualization tools The language(s) involved pretty much come along for the ride. In this regard, Erlang seems to do pretty well - what with CouchDB/CouchBase and Riak gaining a lot of traction on the backend. (For front-end GUIs, I expect Erlang will never be the tool for the job.) Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mononcqc@REDACTED Sun Feb 16 15:45:39 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Sun, 16 Feb 2014 09:45:39 -0500 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> Message-ID: <20140216144538.GD589@ferdmbp.local> Answers inline. On 02/16, Pieter Hintjens wrote: > On Sat, Feb 15, 2014 at 6:08 PM, Fred Hebert wrote: > > > That makes for quite a steep curve, doesn't it? > > This is a core problem. It is an uncanny valley; before you can get > those theoretical productivity gains you have to make large > investments. > > We had this experience in the ZeroMQ community (where I take many of > my lessons from), and the principal lesson was that although there are > sufficient very smart people to help with the hardest problems, the > real life comes from passers-by who learn rapidly in an easy > environment, and get benefit from day one. Decreasing slices of these > people then stick around and learn more and more. > This is fortunately an area people are actively working on. I know I've worked on Recon (http://ferd.github.io/recon/) to help debugging production systems. Tuncer Ayaz recently decumented most of rebar commands (`rebar -help') and worked speeding it up, and Basho has allocated people to work on it. An entire team of people have added work in Relx (https://github.com/erlware/relx) to make project building simpler. Kostis has been working on concurrency bug detection tools. Garrett has worked on e2 to make the learning curve overall smaller. Lo?c Hoguin has recently reworked all of his cowboy documentation, build tools, and examples to be simpler to used. That's just a few. The OTP team has been working to add maps in the language to make it more approachable, Steve Vinoski has put in work for dirty schedulers, making it safer to run C code in Erlang. The Industrial Erlang user group has been negotiating a new license, other than the EPL, to make adoption simpler. Erlang Solutions has started building and offering up-to-date packages for many platforms to make installation simpler: https://www.erlang-solutions.com/downloads You'll notice that all these contributions (most of which are not done by the core OTP team) aim to help existing Erlang developers, or ease adoption. There is work being done. It's quite frustrating to be part of people trying to make it better and seeing that it's always 'too hard' for beginners. If the problem is with the tooling, this is getting worked on. If the problem is with the model (functional, message passing), then that won't change without changing the definition of Erlang itself and removing most of the actual benefits the language offers. > If you scare off the tourists, you cut the number of solid > contributors sharply. This has killed many technically brilliant > projects. Indeed, technical brilliance is one of the best ways to > scare away contributors. Bumbling sincerity beats code quality any > time of day. > It beats them for contributions, but the last thing I want is bumbling sincerity messing up the schedulers, causing deadlocks and segfaults in production code. The OTP team block many contributions, but they also make sure a certain quality exists with code. Like anything it sometimes blocks or slows down valid contribution, but long term, the results haven't been too bad. > It's not snowing in Belgium. However, community building is the same > problem in any country. Remove barriers, remove confusion, create > competition, encourage people to work together instead of reinventing > the same answers over and over. Create space for specialization and > profit. Open up communications. Standardize obsessively. Spread > ownership and decision making as widely as possible. > > The ex-cathedra model can't compete with the rabble in the > marketplace. So Erlang's greatest challenge IMO is simply shifting > away from the top down "we decide for you" model to one that is driven > by users. > In the last few years: - Erlang development moved to Git and Github (from e-mails!) - Moved patch discussions to Github pull requests (while still supporting erlang-patches emails) - Erlang moved its pre-release views from a once-released preview to a nightly build equivalent anybody can check out - Added Unicode support to source files for a more international community - Consistently had more and more user contributions (averaging 50 user contribs per minor releases in R16, outside of the OTP team). Still rather low, but always better. - Modernized EEPs and have actually implemented a few (EEP-43 was OTP-submitted and OTP-implemented. EEP-37 was user-submitted and user-implemented. They'll make it in 17.0. See http://www.erlang.org/eeps/eep-0000.html) - Documented everything you need to do to help (https://github.com/erlang/otp/wiki#wiki-development) - Planned license changes from EPL to something more standard like MPL 2.0. > If there's no shift in power by Erlang's current owners to a real > community driven thinking process, the other options would be to fork > the entire language and open it up, or allow it to die. > The steps are being taken as shown above. You're still free to take it and fork it if you want: https://github.com/erlang/otp It's all open, except having a public-facing issue tracker, which would be fairly important. > To present this choice as (a) Ericsson or (b) Random Stupid Committee > is a false dichotomy. The correct answer is (c) collective ownership > and decision making with no single points of failure. > > It's no coincidence that the only sustainable organizational model for > building distributed systems is itself a distributed system. Which the > Erlang community isn't, today. > It is, partially. The OTP team often has a say in decisions because they're the ones with the highest concentration of know-how about system internals, and equipment to run tests to safeguard the platform's quality. The trend, though, is for a more and more open development. It's *not* moving towards a more closed model. It's in fact doing the opposite, and on a very encouraging motion. > IMO Erlang is trying to deny Conway's law. It's like trying to deny > gravity. Face, let me introduce you to Ground. Let's see who wins. > > I'd love to learn Erlang, mainly because of the people who use it. > However I'm lazy and modest in my investments and can't spend six > months to see profit in a project. I won't use tools I can't improve > myself. I won't join communities where I depend on others for decision > making. > > No complaints here. Just observation and comment based on watching a > tragic number of good projects die because people didn't raise their > heads up and ask some basic questions about relevance to the market. > > -Pieter In that context, I think the biggest problem may be the model. Are you experienced with functional code? Are you familiar with share-nothing concurrency? If not, there *will* be a required investment no matter what the language is. As mentioned in my previous post, the community could work and try to make the learning curve shorter, but it won't go away entirely. Things are incredibly nicer than a few years before (we had few tutorials, no support outside of Emacs, a closed development process, far less tooling, no way to pull in dependencies, no build tools outside of rolling your own makefiles, etc.). It's just that Erlang came from so far behind that even with years of work, it's still behind competition on many issues. It keeps moving forward, however, and seems to be catching up in speed. I'm optimistic about Erlang's future, because I have been here long enough (although I'm not in the old guard just yet), I can see a positive trend. Someone who's starting today will see lonely data points, where Erlang's is falling behind. In fact, it's catching up, even though plenty of work and help is required. Regards, Fred. From mfidelman@REDACTED Sun Feb 16 15:46:28 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Sun, 16 Feb 2014 09:46:28 -0500 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFEAC6.50308@gmail.com> Message-ID: <5300CF44.8050206@meetinghouse.net> Jesper Louis Andersen wrote: > > [0] rambled on this a couple of years ago. The links are 1 hop away > from this > http://jlouisramblings.blogspot.be/2012/10/ramblings-on-thesis-of-bjarne-dacker.html > > Nice piece. What's frightening about it is how closely those requirements also scream "Ada" - which seems to have become the language of choice for aviation software - both hard real-time fly-by-wire software and massively distributed systems for air traffic control. (Dare I say it, another language that "flys under the radar." :-) Talk about divergent solutions to similar requirements. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From tty.erlang@REDACTED Sun Feb 16 16:02:03 2014 From: tty.erlang@REDACTED (T Ty) Date: Sun, 16 Feb 2014 15:02:03 +0000 Subject: [erlang-questions] disconnected nodes In-Reply-To: References: Message-ID: Are you also using Mnesia ? On Mon, Oct 22, 2012 at 5:13 PM, Ahmed Omar wrote: > Hi, > We have a cluster of 20+ nodes running R14B04 on Linux Debian Squeeze. > Suddenly we started having problems where 4-5 would drop out of the > cluster and we would see this in the logs > > =ERROR REPORT==== 2012-10-18 10:49:26 === > ** Node 'x@REDACTED' not responding ** > ** Removing (timedout) connection ** > > We made a crash dump of some of the nodes and found error_logger has a > queue of these messages > > {notify,{error,noproc, > {emulator,"~s~n",["erts_poll_wait() failed: ebadf (9)\n"]}}} > > Any hints? (other than changing net_kernel net_tick_time) > > Best Regards, > Ahmed > > _______________________________________________ > 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 Feb 16 16:16:56 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 16 Feb 2014 16:16:56 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <20140216144538.GD589@ferdmbp.local> References: <20140215170843.GB589@ferdmbp.local> <20140216144538.GD589@ferdmbp.local> Message-ID: Hello, When 17.0 is out and things have calmed down, people who want to increase adoption of Erlang among developers can very well help me finish my Clang-like diagnostics project. It might not be that important, but Clang-level error messages can?t hurt. http://clang.llvm.org/diagnostics.html Feel free to ping me on IRC if you want more details about it. Regards, -- Anthony Ramine Le 16 f?vr. 2014 ? 15:45, Fred Hebert a ?crit : > As mentioned in my previous post, the community could work and try to > make the learning curve shorter, but it won't go away entirely. From g@REDACTED Sun Feb 16 18:44:54 2014 From: g@REDACTED (Garrett Smith) Date: Sun, 16 Feb 2014 11:44:54 -0600 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <20140215170843.GB589@ferdmbp.local> References: <20140215170843.GB589@ferdmbp.local> Message-ID: On Sat, Feb 15, 2014 at 11:08 AM, Fred Hebert wrote: > One very important thing that jumped to me while writing LYSE is that it > takes *forever* before getting from "I'm writing stuff in the shell and > a module" to "I have a program I can call from the command-line". I completely agree - and this is my number one personal pain point. I want to do this: $ make release and: $ make exe And have it just work! Maybe this is all there, but last I checked, the tools for making releases were not easy. I'm now inspired to spend some cycles on this. > Since the community has apparently settled on, rebar, relx, releases, > etc. There's a crapload of learning to do before tying your hands to > production prototype. See how Go's toolchain works there. Over time I've become ever increasingly antagonistic to rebar. Not trying to be a meanie poo poo head here -- but independent of its merits/demerits I don't see the harm in supporting alternatives. I've been erlang.mk and have really liked it. I don't know if this is the final landing point in my search for a build tool that works and across the various common use cases, but for what I've used it for (simple builds with dependencies) it works very well. I haven't spent any time with relx. I will. > I know this likely gets close to your comments from an earlier e-mail -- > we could show OTP sooner to get started faster -- but my objections, I > think, still stand. Indeed, I don't think this is either-or. In fact, learning from the top down requires learning language constructs along the way -- and learning from bottom up should not preclude a vision about end goals. I do think that getting a runnable artifact you can put into production is best done sooner than later. > It could be interesting to see if a tool-based approach could help. > Rebar templates to set things up, relx to build the release. Bundle-in > tools (eper, recon, eflame, etc?), possibly. I think definitely so. There's a general angst reflected in the Therapy Session Threads about scattered libraries and tools. But until we can get *something better* in the core distribution, I think that's just the way it goes. Regardless, the first step is to get something that's decent. rebar has emerged, somehow, as the defacto standard and if that's what the market wants, maybe it, or pieces or it, could be integrated into an officially supported tool chain. I don't know. I just want my damn builds to work and to get releases out without a day's effort. > Hell, make a beginner project template that uses raw processes and a > supervisor_bridge above them to get people going *with OTP* without > first needing to understand it all. This later leaves place to replacing > various parts of the project without needing a total rearchitecture of > all connex services running. I don't see this coming from today's OTP code. Usability was (clearly) never a priority for these modules. e2 tries to wrap this complexity and I think does a pretty reasonable job. It could be made easier, but I'm inclined to think at that point we're talking about another language -- or some serious parse transforms. e2 was originally meant to use parse transforms to really dig out from under the gen_server/supervisor-spec baggage. But the problem I ran into quickly is that there's only so far you can go in simplifying the "generic server" API. At a certain point, the programmer loses touch with the client/server connection, and you've created an abstraction that leaks way too often to be any good. So e2 is now just an API wrapper. But this is clearly not a priority, even remotely, for most Erlang programmers. I honestly don't understand it. If these APIs were easier to use, people would use them more often. They'd have canonical Erlang programs without a sense they're using some heavy weight framework (comparisons to J2EE? really?). > Package management and discoverability would likely help there too. > > Another one, and I think this is where we lose a lot of people, is > algorithms. Anybody who uses Erlang to shuttle bytes around the place > for the network will tend to have a far better time than someone who > comes around and decides "I'll write a game and rely on math-heavy > stuff". > > Or even more generally, "I'll write a thing that requires an algorithm > that uses arrays and assumes O(1) updates". Then, you're directly > screwed. Your A* that uses a loop and a table, your vector > multiplication or whatever, they all go slower than expected. > > Maybe maps will help, maybe not. But to me there's no doubt that > functional/immutable algorithms are definitely trickier to write given > the literature. Outside of Okasaki's book (which is for MLs and Haskells > first, so you need to learn them to translate in Erlang!), there is > nearly no source of algorithms that are not in papers. Do we need an > 'algorithms in Erlang' tutorial? Yeah - I think this is part of the journey into the realm of functional programming. It has its costs, but it has its benefits. There are many times when I wish I didn't have to think so damn hard about how to "do something". But nearly all of the time this is a benefit rather than a cost. For the performance sensitive code, I like the jump into C/C++ land. Heck, even using something like erlport and punting over to Python (which has some great native libraries like NumPy) is so easy and elegant in Erlang -- I see this as a real advantage. > Don't get me wrong -- I think once you're set up, the maintainability of > Erlang programs is amazingly good. I've written long blog posts on this. > I also think the structure of programs (like service-oriented, but > within a node) is brilliant. But before you get there, there's a > shitload of hurdles to get through, and few apps or exercises targeted > at beginners to help build their chops or get a good general idea. Sigh. Yes, it's discouraging that these points -- in particular the micro service architecture -- aren't talked about *way more often*. I actually don't think it's all that hard. I know, I've been pimping this e2 thing -- but seriously -- when you can write OTP compliant behaviors in with zero boilerplate, it's a *lot* easier, and even fun! I don't know what your thoughts are on the three hour tutorial that I run (did this in Toronto) -- but in that amount of time, we (I) build a full fledged, service oriented, OTP compliant app. I realize this three hour investment doesn't quality audience members to jump in and solve business critical problems in Erlang, but heck, they at least saw that you can build real applications using canonical Erlang patterns with a straight forward problem solving methodology. I *think* they saw this. I may be delusional. > More or less, the learning curve of Erlang is Vim-like or Emacs-like. > Sadly, if you want to learn Erlang, you often get told to also learn > Emacs on top of it. > > That makes for quite a steep curve, doesn't it? If it doesn't cost sacrifice important, flattening the curve will only help everyone. There's lots of friction points that we can smooth out -- but boy it'd be nice if others saw this as a problem too. But I'm not judging. Garrett From erlang@REDACTED Sun Feb 16 18:55:50 2014 From: erlang@REDACTED (Joe Armstrong) Date: Sun, 16 Feb 2014 18:55:50 +0100 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <530093F8.5090401@ninenines.eu> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFCE9A.6050802@ninenines.eu> <530000E7.9080103@meetinghouse.net> <53000D1E.5090200@ninenines.eu> <53002527.8040701@meetinghouse.net> <530093F8.5090401@ninenines.eu> Message-ID: On Sun, Feb 16, 2014 at 11:33 AM, Lo?c Hoguin wrote: > On 02/16/2014 03:40 AM, Miles Fidelman wrote: > >> - My sense is that a lot of the comments in this thread have been about >> the need to promote adoption of Erlang - which is really a >> business/company decision, not that of individual developers (at least >> in my experience, it's companies that make language/platform decisions, >> for business reasons). >> > ... > > > any good engineer who's > > working on high-availability, high-concurrency systems either already > > knows about Erlang, or will find it pretty quickly when doing technology > > assessment for a project with requirements that are best suited for > > Erlang > > It's companies that make decisions, but it's developers that introduce > companies to the different choices they have. There's indeed a fair amount > of chances that someone working in HA at least heard about it. There's no > real need to target them. > I'll just throw in another comment here: I (and expect other people who are active in the Erlang community) get a lot of requests for help: Roughly - they fall into two categories: a) I'm thinking of using Erlang but I need to persuade my boss - do you have any marketing material? b) I'm *using* erlang - I have this particular problem. Can you help? Who do you think I help? To requests of type a) I think - "Google" this has been asked many times before - go Google. It's not difficult to find marketing material on the net. If you type "Youtube + Erlang" you get 483,000 results - do you want me to write yet another article about Erlang so you get 482,001 results - I think not. Class b) questions are far more interesting - especially when they pose problems that are *difficult* to solve in Erlang since these point to areas where we might be able to improve the language. So what should I do? 1) Help people who have already decided to use Erlang to prove that the choice was correct, or 2) Try to get new people. Right now I choose to do 1) directly and 2) indirectly by giving lectures and writing books. There is a lot of evidence out there "on the net" that Erlang is pretty good for a range of problems so my suggestion is "go Goggle" do you own research, do you own measurements. Don't believe what other people say. If anybody wants to find out if Erlang is good they should gain personal experience. You can never persuade anybody else of anything, they must persuade themselves. /Joe > Everyone else though? Ask any 9-to-5 developer if they heard of Erlang. > You will get very few positive answers. And if you are the only one who > heard about it in a company, then it's never going to be used even if it's > the perfect tool for the job. > > Erlang can be used for anything server, not just HA. Erlang could replace > PHP or Ruby or whatever and do so while also saving costs (less developers > needed, less/smaller servers, etc). If only enough people even heard about > it. > > The other thing is that Erlang lacks in (properly maintained) libraries. > Getting Erlang known beyond what's it's historically good at is what needs > to be done to fix this. Because if it's only used by HA people then you'll > just get more process registries, pools, distributed frameworks and such. > Which is great when you're building an HA system. But not so much when you > need to output Excel files for accounting, or crop and resize an image, or > send an SMS. Which is the kind of tasks that most developers spend their > time doing. > > > -- Is this true? How does supply and demand for Erlang developers look >> right now? (Anybody from Erlang consultancies able to comment here?) >> > > Right now I don't know but about a year ago I heard the number of 400 > Erlang developers needed in the Bay area alone. I assume of course that > this includes companies that would be interested in using Erlang if only > there was developers to hire. > > US companies that do use Erlang today are forced either to look in Europe > and elsewhere (Basho and Ubiquiti Networks do this AFAIK), or train their > staff (that's what the evening school of Erlang was about). > > > -- On a related note: A lot of this comes down to computer science >> education. >> > > Definitely. > > > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Sun Feb 16 19:10:44 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Sun, 16 Feb 2014 13:10:44 -0500 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFCE9A.6050802@ninenines.eu> <530000E7.9080103@meetinghouse.net> <53000D1E.5090200@ninenines.eu> <53002527.8040701@meetinghouse.net> <530093F8.5090401@ninenines.eu> Message-ID: <5300FF24.20804@meetinghouse.net> Joe Armstrong wrote: > > > I (and expect other people who are active in the Erlang community) get > a lot of requests for help: > > Roughly - they fall into two categories: > > a) I'm thinking of using Erlang but I need to persuade my boss - do > you have any marketing material? > > b) I'm *using* erlang - I have this particular problem. Can you help? > > > Who do you think I help? > > To requests of type a) I think - "Google" this has been asked many > times before - go Google. > It's not difficult to find marketing material on the net. If you type > Really good point. FYI, I just did this a few minutes ago (spurred by this thread). Found some REALLY good stuff from the 2012 Game Developers Conference (talk about the right audience): Google: gdc erlang or: gdc erlang wooga Particularly of note: http://www.slideshare.net/eonblast/why-erlang-gdc-online-2012 http://www.slideshare.net/wooga/erlang-the-big-switch-in-social-games > > Class b) questions are far more interesting - especially when they > pose problems > that are *difficult* to solve in Erlang since these point to areas > where we might be able to > improve the language. > > So what should I do? > > 1) Help people who have already decided to use Erlang to prove that > the choice was correct, or > 2) Try to get new people. > > Right now I choose to do 1) directly and 2) indirectly by giving > lectures and writing books. > > Sounds right to me. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mjtruog@REDACTED Sun Feb 16 19:18:56 2014 From: mjtruog@REDACTED (Michael Truog) Date: Sun, 16 Feb 2014 10:18:56 -0800 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFEAC6.50308@gmail.com> Message-ID: <53010110.4010004@gmail.com> On 02/16/2014 12:43 AM, Pieter Hintjens wrote: > On Sat, Feb 15, 2014 at 11:31 PM, Michael Truog wrote: > >> >Erlang provides a stable >> >distributed system development platform that provides many avenues for >> >integration, as shown by its successes, so your complaints show your >> >ignorance. > Good job on smacking down my ignorant complaints. I feel chastised and > would slink back to silent observation of Erlang's slow demise at the > hands of people who always know better. Except, I will take the bait. > > Cloudi looks valiant in a tragic fashion. A 1-person project still in > beta that uses REST as its messaging carrier. How can I count the ways > this will fail? Anyone looking for a HTTP-based cloud will use Open > Stack, period. Anyone smart will be thinking of new designs based on > much cheaper distributed messaging. People broadly either embrace risk > (then won't use this), or hate risk (then won't use this). The only thing tragic about this conversation, so far, is your ignorance. CloudI exchanges binary data in a way that enforces RESTful development practices. CloudI is not HTTP-based, but instead allows you to integrate with whatever protocol you want. If you can't bother to learn about stuff, you will have problems with any technology, not just Erlang. From n.oxyde@REDACTED Sun Feb 16 19:28:52 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 16 Feb 2014 19:28:52 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> Message-ID: <14981A96-8C4C-43B6-AE71-D08360F028C9@gmail.com> I agree with most of what you said in your mail, except for the part I quoted. The generic behaviours in OTP are quite usable and what you call boilerplate, I call it being explicit about what is happening. Parse transforms would just confuse the hell out of any beginner, it obfuscates code and doesn?t help. In my opinion, e2 vs OTP all comes down to convention-over-configuration vs explicitness. I will take the explicitness anytime. -- Anthony Ramine Le 16 f?vr. 2014 ? 18:44, Garrett Smith a ?crit : > I don't see this coming from today's OTP code. Usability was (clearly) > never a priority for these modules. e2 tries to wrap this complexity > and I think does a pretty reasonable job. It could be made easier, but > I'm inclined to think at that point we're talking about another > language -- or some serious parse transforms. > > e2 was originally meant to use parse transforms to really dig out from > under the gen_server/supervisor-spec baggage. But the problem I ran > into quickly is that there's only so far you can go in simplifying the > "generic server" API. At a certain point, the programmer loses touch > with the client/server connection, and you've created an abstraction > that leaks way too often to be any good. So e2 is now just an API > wrapper. > > But this is clearly not a priority, even remotely, for most Erlang > programmers. I honestly don't understand it. If these APIs were easier > to use, people would use them more often. They'd have canonical Erlang > programs without a sense they're using some heavy weight framework > (comparisons to J2EE? really?). From jdavid.eisenberg@REDACTED Sun Feb 16 19:39:53 2014 From: jdavid.eisenberg@REDACTED (J David Eisenberg) Date: Sun, 16 Feb 2014 10:39:53 -0800 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] Message-ID: > Message: 6 > Date: Sat, 15 Feb 2014 12:08:45 -0500 > From: Fred Hebert > To: Garrett Smith > Cc: Erlang Questions > Subject: Re: [erlang-questions] What problem are we trying to solve > here? [was Erland users group [was re: languages in use? [was: Time > for OTP to be Renamed?]]] > Message-ID: <20140215170843.GB589@REDACTED> > Content-Type: text/plain; charset=us-ascii > [snip] > > Another one, and I think this is where we lose a lot of people, is > algorithms. Anybody who uses Erlang to shuttle bytes around the place > for the network will tend to have a far better time than someone who > comes around and decides "I'll write a game and rely on math-heavy > stuff". > > Or even more generally, "I'll write a thing that requires an algorithm > that uses arrays and assumes O(1) updates". Then, you're directly > screwed. Your A* that uses a loop and a table, your vector > multiplication or whatever, they all go slower than expected. > > Maybe maps will help, maybe not. But to me there's no doubt that > functional/immutable algorithms are definitely trickier to write given > the literature. Outside of Okasaki's book (which is for MLs and Haskells > first, so you need to learn them to translate in Erlang!), there is > nearly no source of algorithms that are not in papers. Do we need an > 'algorithms in Erlang' tutorial? > Yes, absolutely. Real-life example while wanting to rewrite a program in Erlang. I have a text file with 32 names. The last number on the line tells which position a name should occupy in an array (-1 means "to be determined by a later part of the algorithm using other data on the line") For instance: Nancy,3,2 Henry,4,-1 Marco,1,21 Vinh,1,5 In an imperative language like Java/Perl/etc., no problem -- as I've been using imperative languages for a decade or two. In Erlang, the algorithm is not at all obvious. ("When your only tool is recursion, everything looks like a list.") > Don't get me wrong -- I think once you're set up, the maintainability of > Erlang programs is amazingly good. I've written long blog posts on this. > I also think the structure of programs (like service-oriented, but > within a node) is brilliant. But before you get there, there's a > shitload of hurdles to get through, and few apps or exercises targeted > at beginners to help build their chops or get a good general idea. > Or, perhaps more to the point, to think functionally from the very beginning of analyzing a problem. Maybe a "functional programming cookbook" would be a good idea. > More or less, the learning curve of Erlang is Vim-like or Emacs-like. > Sadly, if you want to learn Erlang, you often get told to also learn > Emacs on top of it. > > That makes for quite a steep curve, doesn't it? > Luckily, I ignored that advice and use vim and/or a GUI text editor, whichever happens to be more convenient at the time. > Regards, > Fred. > From robert.virding@REDACTED Sun Feb 16 20:01:44 2014 From: robert.virding@REDACTED (Robert Virding) Date: Sun, 16 Feb 2014 20:01:44 +0100 (CET) Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> Message-ID: <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> This discussion of whether it is good or bad that Ericsson manages/releases Erlang often crops up. I feel there are 3 very strong reasons why it is good that they do: - The quality of the actual is very good, it is product quality. - The Erlang language has been kept very small and consistent - There is basically only one release which everyone uses so you avoid the problem of "it runs on R17 with Bills patches v0.3" Now I know that all these issues could be handled if Erlang was managed by some group/steering committee/whatever but it would be much more difficult. Especially the second one I think would be the first to go. I am reasonably certain that there would come quite a few suggestions for modifying/extending the language which would be very difficult to resist. Each one would be quite modest and reasonable but taken together the language would grow with lots of special cases and suddenly become large and unwieldy. And everyone on the committee/group would have their own special features which really must be included because EVERYONE will benefit. Look at PL1 or Common Lisp. Maybe I am being way to pessimistic here but I see the problems as real and being of the slippery slope type. From past experience it is much easier to add something than to remove it later, no matter hard bad it originally was. Also having the same group making the decisions and building the standard releases means that there can actually be order in the world. However you do it someone is going to get dissed for doing the wrong thing and will need a very thick skin. Robert ----- Original Message ----- > From: "Pieter Hintjens" > > On Sat, Feb 15, 2014 at 6:08 PM, Fred Hebert wrote: > > > That makes for quite a steep curve, doesn't it? > > This is a core problem. It is an uncanny valley; before you can get > those theoretical productivity gains you have to make large > investments. > > We had this experience in the ZeroMQ community (where I take many of > my lessons from), and the principal lesson was that although there are > sufficient very smart people to help with the hardest problems, the > real life comes from passers-by who learn rapidly in an easy > environment, and get benefit from day one. Decreasing slices of these > people then stick around and learn more and more. > > If you scare off the tourists, you cut the number of solid > contributors sharply. This has killed many technically brilliant > projects. Indeed, technical brilliance is one of the best ways to > scare away contributors. Bumbling sincerity beats code quality any > time of day. > > It's not snowing in Belgium. However, community building is the same > problem in any country. Remove barriers, remove confusion, create > competition, encourage people to work together instead of reinventing > the same answers over and over. Create space for specialization and > profit. Open up communications. Standardize obsessively. Spread > ownership and decision making as widely as possible. > > The ex-cathedra model can't compete with the rabble in the > marketplace. So Erlang's greatest challenge IMO is simply shifting > away from the top down "we decide for you" model to one that is driven > by users. > > If there's no shift in power by Erlang's current owners to a real > community driven thinking process, the other options would be to fork > the entire language and open it up, or allow it to die. > > To present this choice as (a) Ericsson or (b) Random Stupid Committee > is a false dichotomy. The correct answer is (c) collective ownership > and decision making with no single points of failure. > > It's no coincidence that the only sustainable organizational model for > building distributed systems is itself a distributed system. Which the > Erlang community isn't, today. > > IMO Erlang is trying to deny Conway's law. It's like trying to deny > gravity. Face, let me introduce you to Ground. Let's see who wins. > > I'd love to learn Erlang, mainly because of the people who use it. > However I'm lazy and modest in my investments and can't spend six > months to see profit in a project. I won't use tools I can't improve > myself. I won't join communities where I depend on others for decision > making. > > No complaints here. Just observation and comment based on watching a > tragic number of good projects die because people didn't raise their > heads up and ask some basic questions about relevance to the market. > > -Pieter > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From s.j.thompson@REDACTED Sun Feb 16 20:30:55 2014 From: s.j.thompson@REDACTED (Simon Thompson) Date: Sun, 16 Feb 2014 19:30:55 +0000 Subject: [erlang-questions] Announce: Software Engineering for Systems Developed in Functional Languages Message-ID: The 32nd CREST Open Workshop: Software Engineering for Systems Developed in Functional Languages Date: 24th - 25th March 2014 Venue: University College London, UK Through the kind support of the EPSRC in the form of a platform grant, we have funding to support the workshops, so registration is free (but there is a charge for registering and then *not* attending, since places are limited). Registration includes lunch on both days and light refreshments. Overview: Functional programming has become a mature practical tool for software development. Large complex functional programs require many of the software engineering techniques developed for other languages and paradigms, such as testing, slicing and refactoring. Some of these techniques, originally designed for imperative languages, such as amorphous slicing and refactoring may prove highly amendable to functional styles of programming. This workshop will bring together software engineers and functional programmers to concentrate on aspects of software engineering that can be extended, adapted and augmented for application to functional programs. Confirmed Speakers David Binkley, Computer Science Department, Loyola University Maryland, USA Sebastian Danicic, Department of Computing - Goldsmiths College London, UK Kevin Hammond, School of Computer Science, at the University of St. Andrews, UK Torben Hoffmann, Erlang Solutions, Denmark Yue Jia, CREST Centre, SSE Group, Department of Computer Science, UCL, UK Raghavan Komondoor, Indian Institute of Science, India Alan Mycroft, Computer Laboratory, University of Cambridge, UK Jerry Swan, Computing Science and Mathematics, University of Stirling, UK Don Syme, Microsoft Research, Cambridge, UK Simon Thompson, School of Computing, University of Kent, UK Dimitrios Vytiniotis, MSRC PPT group, Microsoft Research, Cambridge, UK More details and registration at: http://crest.cs.ucl.ac.uk/cow/32/ Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson@REDACTED | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt From erlang@REDACTED Sun Feb 16 20:56:57 2014 From: erlang@REDACTED (Joe Armstrong) Date: Sun, 16 Feb 2014 20:56:57 +0100 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> Message-ID: On Sat, Feb 15, 2014 at 1:01 PM, Pieter Hintjens wrote: > On Fri, Feb 14, 2014 at 4:39 PM, Miles Fidelman > wrote: > > > Actually, the demand for both Cobol and analog engineers is UP. > > Friend of mine was just laid off from a 15-year Cobol job. One can't > make general conclusions from small samples. > > The argument that keeping technology elitist creates wealth is insane > and should be laid to rest rapidly. Who here is building new > businesses on LU6.2? Right. > > It was extremely enlightening last week, at a workshop with a medium > sized Erlang shop. Opening statement: "We chose Erlang because it lets > us build large distributed systems with a small team." Then two full > days of, "oh, that's one more serious problem we're facing, caused by > how Erlang does things." > Could you be more explicit? What is that Erlang does that causes problems? It seems crazy that there are two days of discussion about this and the core Erlang group gets to hear nothing about this. I'm really keen to hear about problems users have, bit I'm not psychic. I can't read minds somebody has to tell us what the problems are. If you don't tell us about the problems we can't fix them. > > A technology either lives, by growing and merging with others, or it > dies. Technologies don't die once they get to a critical mass. They live forever. Cobol never died. It just stoped expanding. This happens when the cost of converting legacy code exceeds cost of developing new code. Erlang is far from being a living technology and survives pretty > much thanks to a single dominant customer and investor. It was actually banned by it's "single dominant customer" but survived anyway :-) What would happen if the single dominant customer lost interest is a matter of pure speculation. Things would happen :-) > It claims to > be the best solution for distributed systems, Where? > yet is entirely > homogeneous, Yes > which is also an insane contradiction. No > Distributed > systems by definition must span space and time, or they are > LegacyAsAService. > Ummm - problem is we haven't a clue how to do this. > > Erlang's elitism and lack of broad appeal is the #1 threat to its long > term survival. It is frankly the Algol 68 of the telco industry. > Awesome language!! Yay!!! > I don't understand the elitism jibe. I (and others) believe Erlang to be better at solving a particular class of problems that some other languages. If we say so, is this what you call elitism? or should we keep quiet? Erlang is really really bad at solving a boatload of problems, and we also say this. "Lack of broad appeal" is understandable. I guess " building apps for android" has "broad appeal" or "desktop applications" has board appeal. Making servers that "never stop" is never going to have broad appeal. The only thing we could ask for is "broad appeal in a niche" where the niche is "building non-stop servers". This is a bayesian concept - broad appeal "subject to the condition that you are building faulty tolerant servers" and in this niche I think we are well thought of. Many niche language do not have broad appeal - but are totally dominant in their niche. For example, postscript for printers :-) > To measure market success in terms of "how much can a developer earn" > is also so foolish I'm embarrassed to read such views. I agree This is meant > to be a list of clever people. For pity's sake. That's like claiming a > protocol is valuable because it's so hard to implement. But I never ever heard anybody claim that a protocol was valuable because it was difficult to implement. One the contrary, encodings like JSON are claimed to be valuable for exactly the opposite reason that they are easy to implement. > Wealth comes > from building up. How can you build up if your basic layers aren't a > commodity? There's a million times more wealth built on PHP than > Erlang. Real wealth. > > > Erlang needs to shed its telco ties, and get an independent steering > committee, and create standards, and multiple implementations, and > also reach out to other language communities through distribution > protocols like ZMTP, and educate those communities, while also > exploiting them and merging with them. Living systems are like the > Borg; they grow by merger. > Mock Java all you like. It's a hateful language in many ways. Who mocks Java? We say "for this class of programs we believe Erlang to better than Java and here is our evidence" Java is great for what it was designed to be good at (as is Erlang) - My smart card for public transport is a Java VM powered by induction currents, it's a miracle of technology, I'm not mocking this. > But Java > programmers know how to work together. Do they? What's the evidence for this? When I meet Java programmers all they seem to do is argue about which framework to use. People in general find it difficult to work with each other. I can't think of any reason why Erlang programmers would be less good at working together that X programmers (where X is any language you care to name). The ability to work with other people must be a property of the people involved and not the technology they work with, > There are 6+ different Erlang > stacks for ZeroMQ, all one-man projects, all lacking any community. > This is avery interesting comment. Why are there 6 stacks and not one? Possible reasons: 1) The 6 different developers didn't know about each other 2) They knew about each other but their stacks have different non-functional requirements 3) They wrote the stack for their own personal enlightenment and had no interest in it being widely used 4) Nobody uses the code That they lack community might mean that erlang programmers feel no pressing need to communicate with applications in other languages. When code starts getting widely used, new users start asking questions like "they are 6 stacks" which is best? - and then a shake-down occurs. This has happened previous with HTTP stacks - there used to be several - but they seem to have converged on one now. The fact there are 6 ZeroMQ stacks means this is "early days" and that this convergence on the best stack has not yet happened. I'm speculating here: At a guess 5% of all programmers are writing distributed applications. Of these 10% are writing cross-language applications. Most will use REST protocols. The number of people who want to connect Erlang to X via AeroMQ must be rather small and so we don't see any pressure to consolidate the libraries. Me, I'm interested in Connecting Erlang to Julia via ZeroMQ, but the real underlying problem has nothing to do with the plumbing problems, ie I'm not that excited about whether it's ZeroMQ of TCP but rather the *semantics* of the interface. In the Julia world there are things called arrays (of 64 bit signed integers) and int the Erlang world there are tuples and lists of big integers. So when we talk to each other we need to do some conversions, and it's very unclear how. ZeroMQ (or Erlang) or sockets, or UDP solves part of the problem, but what about the rest. Do we add an XML layer, or JSON, or ASN.1 or thrift. In the erlang world (and smalltalk) integers are integers - but in C they are (signed|unsigned, 8|1632|64) integers and life gets tricky. Another reflection: 6 implementations rather than one means 6 chances to get it right. It means diversity. It's kind of nice to go into a bar and find 6 different beers, rather than one, but it is confusing to a newcomer, and a stranger who walks into the bar and does not know what to order. This mail reply got long - it was triggered by Pieters comment about 6+ different implementations of ZeroMQ. I keep pondering this - it raises and interesting question. I am very guilty of not collaborating with other people and making my own implementations and I don't know if its a strength or a failing. The main reason I implement stuff myself is to learn how things work through my own personal experience, not though a lack of a desire to collaborate. I just don't really understand how things work if I haven't implemented them myself. Cheers /Joe > > -Pieter > _______________________________________________ > 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 Sun Feb 16 21:38:36 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Sun, 16 Feb 2014 21:38:36 +0100 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <5300CF44.8050206@meetinghouse.net> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFEAC6.50308@gmail.com> <5300CF44.8050206@meetinghouse.net> Message-ID: On Sun, Feb 16, 2014 at 3:46 PM, Miles Fidelman wrote: > Nice piece. > > What's frightening about it is how closely those requirements also scream > "Ada" - which seems to have become the language of choice for aviation > software - both hard real-time fly-by-wire software and massively > distributed systems for air traffic control. (Dare I say it, another > language that "flys under the radar." :-) > > Talk about divergent solutions to similar requirements. > I'll claim that they cover different areas. The key difference is hard vs soft real time. Where Ada can work with the former, Erlang relaxes the requirement to soft realtime and gains a lot of benefits by doing so. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Sun Feb 16 22:11:01 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Sun, 16 Feb 2014 16:11:01 -0500 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFEAC6.50308@gmail.com> <5300CF44.8050206@meetinghouse.net> Message-ID: <53012965.5030001@meetinghouse.net> Jesper Louis Andersen wrote: > > On Sun, Feb 16, 2014 at 3:46 PM, Miles Fidelman > > wrote: > > Nice piece. > > What's frightening about it is how closely those requirements > also scream "Ada" - which seems to have become the language of > choice for aviation software - both hard real-time fly-by-wire > software and massively distributed systems for air traffic > control. (Dare I say it, another language that "flys under the > radar." :-) > > Talk about divergent solutions to similar requirements. > > > I'll claim that they cover different areas. The key difference is hard > vs soft real time. Where Ada can work with the former, Erlang relaxes > the requirement to soft realtime and gains a lot of benefits by doing so. > Good point. "Let it crash" does take on a whole different meaning when dealing with aircraft and such. Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From baliulia@REDACTED Sun Feb 16 22:25:37 2014 From: baliulia@REDACTED (=?UTF-8?B?SWduYXMgVnnFoW5pYXVza2Fz?=) Date: Sun, 16 Feb 2014 22:25:37 +0100 Subject: [erlang-questions] disconnected nodes In-Reply-To: References: Message-ID: <53012CD1.7030605@gmail.com> On 02/16/2014 04:02 PM, T Ty wrote: > Are you also using Mnesia ? Nope. -- Ignas From eric.pailleau@REDACTED Sun Feb 16 21:51:02 2014 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sun, 16 Feb 2014 21:51:02 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] fix typo In-Reply-To: <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> Message-ID: <530124B6.4050204@wanadoo.fr> Le 16/02/2014 20:01, Robert Virding a ?crit : > Also having the same group making the decisions and building the standard releases means that there can actually be order in the world. I globally agree, but however, an annoying detail , the "What you could do" in development page remains desperately empty since beginning. Not really an emulation to create groups in the community and solve the "6+ different Erlang stacks for ZeroMQ, all one-man projects" problems. Either a lack of confidence in the community, or a deliberate will to only wait patches and bug detections on OTP team needs. may be this page could be simply removed... regards From chassoul@REDACTED Sun Feb 16 04:43:54 2014 From: chassoul@REDACTED (Jean Chassoul) Date: Sat, 15 Feb 2014 22:43:54 -0500 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <53002527.8040701@meetinghouse.net> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFCE9A.6050802@ninenines.eu> <530000E7.9080103@meetinghouse.net> <53000D1E.5090200@ninenines.eu> <53002527.8040701@meetinghouse.net> Message-ID: long live Carl Hewitt! On Sat, Feb 15, 2014 at 9:40 PM, Miles Fidelman wrote: > Lo?c Hoguin wrote: > >> On 02/16/2014 01:05 AM, Miles Fidelman wrote: >> >>> Lo?c Hoguin wrote: >>> >>>> >>>> To make a comparison, it generally goes like this: >>>> >>>> What's Go? -> Language from Google by the Unix people -> I know and >>>> like those, therefore Go must be good too, plus it looks similar to >>>> what I'm used to. >>>> >>>> What's Erlang? -> Language from Ericsson invented 25+ years ago -> >>>> Really? I'm not sure what Ericsson does... If it was invented 25 years >>>> ago and I haven't heard about it yet it must not be very good, plus >>>> it's not OO so it must not be very useful. >>>> >>>> You can't fix that. >>>> >>>> What you can fix about perception is actually minimal stuff. Like >>>> changing the name. Using release numbers that aren't from another >>>> planet. And so on. >>>> >>> >> Just in case this wasn't clear, I'm not saying changing the name or >> release numbers or whatever is a good idea. I'm saying it's minimal and >> thus not going to change anything. >> > > Ahh... my apologies for misinterpreting. I think we agree on this. > > > >> This is just plain silly. >>> >> >> You are talking about companies, I am talking about people. Erlang is >> already adopted in many companies, there are more companies using Erlang >> than there are Erlang developers. It is a grave mistake to focus on >> companies at this point. What's missing is Erlang developers to work for >> them and for new ones that might be interested in it. >> >> It's about people. >> >> > Can we explore this a bit? In two directions: > > - My sense is that a lot of the comments in this thread have been about > the need to promote adoption of Erlang - which is really a business/company > decision, not that of individual developers (at least in my experience, > it's companies that make language/platform decisions, for business > reasons). It sounds like you and I agree that adoption by companies is > going along just fine - but I'm not sure that's what others are saying. > > - It strikes me that the comment that started this branch of discussion > was something along the lines of "who needs Erlang on a resume?" - or words > to that effect - which is, as you say, a developer issue. I wonder three > things about your assertion that "what's missing is Erlang developers:" > -- Is this true? How does supply and demand for Erlang developers look > right now? (Anybody from Erlang consultancies able to comment here?) > -- If yes, is this perhaps a good thing for Erlang developers? (This was > my earlier assertion.) Supply, demand, prices, all of that. 20 years ago, > one could command big bucks for building web sites - these days, not so > much. > -- Does promotion actually make a difference? In my experience, there are > those who are committed to one particular language - doesn't matter what > language - and nothing is going to get those folks to explore another > language. And then there are real engineers, who pick the right tool for > the job at hand - and my sense that any good engineer who's working on > high-availability, high-concurrency systems either already knows about > Erlang, or will find it pretty quickly when doing technology assessment for > a project with requirements that are best suited for Erlang (mind you > "good engineers" are not all that easy to come by, particularly when it > comes to the kinds of big, complicated systems that Erlang is best suited > to - but that's a far broader issue than finding coders with Erlang skills) > -- On a related note: A lot of this comes down to computer science > education. 40 years ago (I'm showing my age), a typical computer science > curriculum included quite a bit of language design theory, and experience > with a range of languages (anybody else remember using "Structure and > Interpretation of Computer Programs" as a 1st-year text?) - these days, not > so much. I see an awful lot of people who took a couple of courses in Java > who think they're computer scientists - but ask them about "actors" or > "lambda expressions" and you get a glazed expressions. (Real software > engineers read lambda-the-ultimate.org ?) > > > > > 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 mononcqc@REDACTED Sun Feb 16 22:35:08 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Sun, 16 Feb 2014 16:35:08 -0500 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> Message-ID: <20140216213506.GE589@ferdmbp.local> On 02/16, Garrett Smith wrote: > > I don't see this coming from today's OTP code. Usability was (clearly) > never a priority for these modules. e2 tries to wrap this complexity > and I think does a pretty reasonable job. It could be made easier, but > I'm inclined to think at that point we're talking about another > language -- or some serious parse transforms. > This is really the only point I wanted to discuss in more depth in this list -- I think the rest is something we could discuss in person for a long time in March. Anyway, what I could see going is making a basic Erlang project where all you have is: - _app.erl - _sup.erl - _bridge.erl (supervisor_bridge middleman) - .erl The structure would be [app_sup] | [app_bridge] | [app] Only .erl is ran by the user and can be, by standard way, made to need a 'main/1' function running with content similar to an escript. The rest is generic and can even be provided as a library. With that approach, start the app by calling 'erl -bridgeapp '. Alternatively, have the script generate a release config that will do that stuff for you with a sys.config. What I like from this approach is that you get: - OTP's structure and library usage from the community (service-based approach) - Escript-like capability - Being able to 'have a main loop' - Run a release - The ability to progressively move your non-OTP code to OTP code without rewriting everything - You still need to use OTP to publish actual libraries to be fetched by common build tools, but can run your release as you wish There are gaps to bridge here and there (does the node shut down on the main loop ending?), but I think this kind of app could be fairly sweet to add to get started faster. It's similar to an escript in what you need to write, but path management and code distribution done through OTP is much nicer. Regards, Fred. From ok@REDACTED Sun Feb 16 23:11:05 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 17 Feb 2014 11:11:05 +1300 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: References: Message-ID: On 14/02/2014, at 3:35 AM, ?????? ???????? wrote: > I'm sure, that embedded Javascript understands > and < instead of > and < characters, so I have tried this in several browsers. It worked in none of them. From thomasl_erlang@REDACTED Sun Feb 16 23:57:57 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Sun, 16 Feb 2014 14:57:57 -0800 (PST) Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFEAC6.50308@gmail.com> Message-ID: <1392591477.29977.YahooMailNeo@web140105.mail.bf1.yahoo.com> "Erlang either gets its cost model way down, or it dies. Quote me on that if you like. Our industry has no pity for excess friction, and you have competitors." Very provocative, so please explain in greater detail.? Best, Thomas On Sunday, February 16, 2014 9:44 AM, Pieter Hintjens wrote: On Sat, Feb 15, 2014 at 11:31 PM, Michael Truog wrote: > >> Erlang provides a stable >> distributed system development platform that provides many avenues for >> integration, as shown by its successes, so your complaints show your >> ignorance. > >Good job on smacking down my ignorant complaints. I feel chastised and >would slink back to silent observation of Erlang's slow demise at the >hands of people who always know better. Except, I will take the bait. > >Cloudi looks valiant in a tragic fashion. A 1-person project still in >beta that uses REST as its messaging carrier. How can I count the ways >this will fail? Anyone looking for a HTTP-based cloud will use Open >Stack, period. Anyone smart will be thinking of new designs based on >much cheaper distributed messaging. People broadly either embrace risk >(then won't use this), or hate risk (then won't use this). > >Erlang's unique status used to be, we understand distributed systems. >Today that's changed. There are many other ways to make distributed >systems, more cheaply, more successfully. > >Erlang either gets its cost model way down, or it dies. Quote me on >that if you like. Our industry has no pity for excess friction, and >you have competitors. > >I think this thread is really important. And the questions should not >be "what is Erlang called", since that's trivial to solve (just stop >saying "OTP" in polite company). The question should be, "where are >there friction costs and how can we remove them?" > >My example of outreach to other languages is about friction costs. If >it's trivial to integrate polyglot languages with Erlang, friction >costs fall right away. > >Smacking down the ignorant won't remove friction costs. > >Cheers > >Pieter >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Mon Feb 17 00:11:10 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Sun, 16 Feb 2014 15:11:10 -0800 (PST) Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <53012965.5030001@meetinghouse.net> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFEAC6.50308@gmail.com> <5300CF44.8050206@meetinghouse.net> <53012965.5030001@meetinghouse.net> Message-ID: <1392592270.9891.YahooMailNeo@web140104.mail.bf1.yahoo.com> Why, Miles, the solutions are similar -- we just launch another one. Best, Thomas On Sunday, February 16, 2014 10:11 PM, Miles Fidelman wrote: Jesper Louis Andersen wrote: >> >> On Sun, Feb 16, 2014 at 3:46 PM, Miles Fidelman >> > wrote: >> >>? ? Nice piece. >> >>? ? What's frightening about it? is how closely those requirements >>? ? also scream "Ada"? - which seems to have become the language of >>? ? choice for aviation software - both hard real-time fly-by-wire >>? ? software and massively distributed systems for air traffic >>? ? control.? (Dare I say it, another language that "flys under the >>? ? radar." :-) >> >>? ? Talk about divergent solutions to similar requirements. >> >> >> I'll claim that they cover different areas. The key difference is hard >> vs soft real time. Where Ada can work with the former, Erlang relaxes >> the requirement to soft realtime and gains a lot of benefits by doing so. >> > >Good point.? "Let it crash" does take on a whole different meaning when >dealing with aircraft and such. > >Miles > >-- >In theory, there is no difference between theory and practice. >In practice, there is.? .... Yogi Berra > > >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Mon Feb 17 00:16:46 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Sun, 16 Feb 2014 18:16:46 -0500 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <1392591477.29977.YahooMailNeo@web140105.mail.bf1.yahoo.com> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFEAC6.50308@gmail.com> <1392591477.29977.YahooMailNeo@web140105.mail.bf1.yahoo.com> Message-ID: <530146DE.8060205@meetinghouse.net> Actually, I'm a bit curious about the paragraph before as well: Thomas Lindgren wrote: > > "Erlang either gets its cost model way down, or it dies. Quote me on > that if you like. Our industry has no pity for excess friction, and > you have competitors." > > Very provocative, so please explain in greater detail. > > Best, > Thomas > > On Sunday, February 16, 2014 9:44 AM, Pieter Hintjens > wrote: > > Erlang's unique status used to be, we understand distributed systems. > Today that's changed. There are many other ways to make distributed > systems, more cheaply, more successfully. > Please. Elaborate. With a few examples. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mfidelman@REDACTED Mon Feb 17 00:18:12 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Sun, 16 Feb 2014 18:18:12 -0500 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <1392592270.9891.YahooMailNeo@web140104.mail.bf1.yahoo.com> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFEAC6.50308@gmail.com> <5300CF44.8050206@meetinghouse.net> <53012965.5030001@meetinghouse.net> <1392592270.9891.YahooMailNeo@web140104.mail.bf1.yahoo.com> Message-ID: <53014734.5050301@meetinghouse.net> :-) Though, personally, I think I'll rely on Erlang on my servers, Ada when I'M flying on something. Cheers, Miles Thomas Lindgren wrote: > > Why, Miles, the solutions are similar -- we just launch another one. > > Best, > Thomas > > > > On Sunday, February 16, 2014 10:11 PM, Miles Fidelman > wrote: > > Jesper Louis Andersen wrote: > > > > On Sun, Feb 16, 2014 at 3:46 PM, Miles Fidelman > > > >> wrote: > > > > Nice piece. > > > > What's frightening about it is how closely those requirements > > also scream "Ada" - which seems to have become the language of > > choice for aviation software - both hard real-time fly-by-wire > > software and massively distributed systems for air traffic > > control. (Dare I say it, another language that "flys under the > > radar." :-) > > > > Talk about divergent solutions to similar requirements. > > > > > > I'll claim that they cover different areas. The key difference > is hard > > vs soft real time. Where Ada can work with the former, Erlang > relaxes > > the requirement to soft realtime and gains a lot of benefits by > doing so. > > > > Good point. "Let it crash" does take on a whole different meaning > when > dealing with aircraft and such. > > Miles > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From ok@REDACTED Mon Feb 17 00:40:53 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 17 Feb 2014 12:40:53 +1300 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <5300C3A6.6000000@meetinghouse.net> References: <20140215170843.GB589@ferdmbp.local> <5300C3A6.6000000@meetinghouse.net> Message-ID: <1966B476-53E3-42E2-9438-BD7A48EADB13@cs.otago.ac.nz> On 17/02/2014, at 2:56 AM, Miles Fidelman wrote: > That seems like a red herring to me. Is the learning curve really that steep? For me, - the language was NO effort to pick up - experience with other declarative languages helped a LOT (A* is pretty easy) - learning to think in terms of concurrency after decades of sequential is hard - it's a LOT easier to do concurrency in Erlang than in say Concurrent ML or Smalltalk BUT - picking up the tools is not so easy. What is the answer? It is documentation, documentation, documentation. Tutorials, how-tos, books (to the authors of Erlang books, humble thanks). For example, it was easier for me to write my own XML parser in C than to cope with libxml's documentation (if that's not too strong a word). From ludovic@REDACTED Mon Feb 17 00:55:19 2014 From: ludovic@REDACTED (ludovic@REDACTED) Date: Mon, 17 Feb 2014 00:55:19 +0100 Subject: [erlang-questions] Generic server and selective receives Message-ID: <01ea44277e59d63ec6d4975c9499d738@demblans.com> Hi, I would like some help to implement a message-buffer in erlang. This process can be sent messages, and stores them in mailbox. A buffer can have one client, or can have no client. When there's no client, I would prevent the process to do anything but accept a new client or timeout after a small amount of time. So I have two sets of receive clauses. Now, I would like to implement this as a gen_server. But I don't know how. The Idea is to timeout quickly if no message of the expected clauses-set comes. * I thought of a gen_fsm but it will crash if it's sent a message when in the "no client" state, right ? (Plus i may want to handle more receive clauses in the "no client" part) * I thougt about time calculations but it's seems too complicated for no reason ; I prefer use the simple gen_* timeouts. * I could keep my current implementation and adapt the module to fit in a supervision tree but I believe I willll miss common OTP features. So, I hope this is a common pattern and that someone will tell me a good solution. Thank you. -- lud This is my current implementation (but not the actual code). loop(#state{client_pid=undefined}) -> receive {set_client,Pid} -> loop(State#state{client_pid=Pid}) after 10000 -> io:fwrite("Terminating\n") end; loop(State=#state{client_pid=Client,mailbox=Mailbox}) -> receive {set_client,Pid} -> %% here we can change the client or set it to undefined loop(State#state{client_pid=Pid}); {message,M} -> Client ! you_have_messages, loop(State#state{mailbox=[M|Mailbox]}); %% A handful of other clauses ... ... ... after way more time than 1000 -> io:fwrite("Terminating too\n") end; Now i'll pray for this mail to be seen in the current huge amount of emails (and very intersting by the way) on the list. From ok@REDACTED Mon Feb 17 02:56:47 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 17 Feb 2014 14:56:47 +1300 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <52FE3894.2000003@meetinghouse.net> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> Message-ID: On 15/02/2014, at 4:39 AM, Miles Fidelman wrote: > Fortran for number crunching - 1970s and 1980s (today, SQL and Excel spreadsheets; probably go with SPSS or MATLAB for fancy stuff) Have you *seen* modern Fortran? Modules, user defined data types with parameters, array expressions, coarrays, and don't forget things like the OpenCL binding and the PGI CUDA Fortran compiler that lets you take advantage of GPUs. This is not your grandfather's Fortran. Joe Armstrong pointed me to Julia, which looks nice. From ok@REDACTED Mon Feb 17 03:07:48 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 17 Feb 2014 15:07:48 +1300 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> Message-ID: <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> On 17/02/2014, at 8:01 AM, Robert Virding wrote: > This discussion of whether it is good or bad that Ericsson manages/releases Erlang often crops up. For a comparison, I look at R. It's not owned by a business, but it _is_ managed by a core of bright dedicated people who keep on rolling out ever-better releases. The one thing that they have that Erlang doesn't is a *large* repository of 3rd-party libraries. Having a single place to look for stuff (linked right off the main page) is good for everyone. (There's a single place to *look*; there are mirrors for *downloading*, which is as simple as > install.packages(c("wigwam","goose","bridle")) That will - fetch the latest descriptions - download whatever needs downloading - unpack whatever needs unpacking - compile whatever support code needs compiling - put everything where it can be found - including documentation and examples. When we can do something like % erl -install cowboy won't that be nice? From kenji@REDACTED Mon Feb 17 03:52:42 2014 From: kenji@REDACTED (Kenji Rikitake) Date: Mon, 17 Feb 2014 11:52:42 +0900 Subject: [erlang-questions] Using erlang from the master branch In-Reply-To: References: Message-ID: <20140217025242.GA2005@k2r.org> Using kerl for building from git will help. https://github.com/spawngrid/kerl Kenji Rikitake ++> Leo Liu [2014-02-14 15:40:17 +0800]: > I am using erlang from the master branch (to get wx support on darwin > and other goodies). Since the branch is updated frequently I would like > to avoid having to install it every time. I add $ERL_TOP/bin to PATH in > bash and things seem to work except when building projects with C > extensions, for example compiling yaws would fail due to missing .h > files. > > This seems like a common use pattern so I wonder if someone else has > solved the problem before? > > Thanks, > Leo From ok@REDACTED Mon Feb 17 04:09:46 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 17 Feb 2014 16:09:46 +1300 Subject: [erlang-questions] Erland users group (was re: languages in use? [was: Time for OTP to be Renamed?]) In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FF6EDE.1090205@jkemp.net> <52FF793C.5090908@jkemp.net> Message-ID: <16E660B1-C9C4-415A-978E-695FB567EE03@cs.otago.ac.nz> On 16/02/2014, at 11:02 AM, Pieter Hintjens wrote: > IME this isn't inherent in standards setting. After AMQP (the > disaster), Steve and I worked on RestMS, which made no splash, yet was > clean and elegant and used a different standards process (the Digistan > model) that avoided any arguments. We have used that model again in > the ZeroMQ RFCs, and there are no flamewars. Would you be the Pieter Hintjens of whom it was written "it must be acknowledge that Digistan is the result of the vision and tireless (but tactful) energy of Pieter Hintjens"? I was involved in an attempt to produce an open revision of the Smalltalk standard; by the time I tried to submit my proposal for Processes (based on a consensus of about 8 implementations), the process was dead. > > Standards are really important. Both for the language (to ensure > competing implementations don't lock in users) and for protocols (to > ensure competition between suppliers). Look, I can see this when there *are* competing implementations. But how has the absence of a PHP standard impeded the acceptance or reduced the utility of PHP? Suppose there is a standard for a language. (Let's call it Objective-B.) And suppose there are two vendors. Let's call them Apricot and Wildebeest. What stops Apricot extending Objective-B faster than Wildebeest can keep up? What stops Apricot adding high-value libraries? These days, what stops Apricot insisting that applications submitted to the Apricot (Trading) Pit must be known to work with *their* compiler so you have to buy their compiler anyway? (If you don't like Objective-B, then there's B-flat from GogMaGog. Same story.) I wouldn't have spent years of my time contributing to the Prolog standard effort if I didn't think standards could be a good thing, especially where there are no rival standards. But they are neither necessary nor sufficient for the success or utility or even survival of a programming language. From ok@REDACTED Mon Feb 17 03:41:38 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 17 Feb 2014 15:41:38 +1300 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <52FF6840.7080105@meetinghouse.net> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FF6840.7080105@meetinghouse.net> Message-ID: <048AE900-3CEC-469E-B9B5-5983C08F6E8A@cs.otago.ac.nz> On 16/02/2014, at 2:14 AM, Miles Fidelman wrote: > How about this for a larger sample: > http://eandt.theiet.org/news/2013/mar/cobol-skills.cfm (lede: "Dearth of COBOL programmers threatens business") As someone who has used COBOL, who indeed has OpenCOBOL on his machine (and some CICS books I've never had a chance to put into practice), I have to say that 'Coughlan ... also believes a certain amount of "intellectual snobbery", due to the language not being mathematically based and created by ... Grace Hopper rather than academics, is at play." is *way* off the mark. COBOL is no more and no less "mathematically based" than most imperative programming languages. And it's news to me that C, C++, Objective C, Visual Basic.NET (we used to teach that, only stopped recently; I used to do it but after our then HoD took over, it was decided to stop), SQL, or PHP was "created by academics". Our own beloved Erlang was created _by_ an industrial company _for_ their industrial purposes, and it wasn't the first time they'd devised their own language either. The problem with COBOL is that it is just amazingly verbose, not to mention error-prone. Unfortunately, COBOL-to-X translators, except for the very very best, tend to produce programs in language X that are even more verbose, and far less understandable. (I haven't used one, but I've seen materials suggesting that there are some seriously good COBOL-to-X translators out there, but expect to spend serious money...) As for "students only really learn one language, normally Java or some Java derivative", we teach Python, Java, and C, and 3rd-year students are at least exposed to C++ or Objective C. Coughlan may be correct that students only *learn* one language, but they are *taught* more. The rather whiny tone of the article is one I've heard before (I wonder where). If businesses are worried about there not being enough COBOL programmers, the answer is for *them* to club together and *run some courses*. If anyone wants to do that in Dunedin, I would be happy to contribute some teaching time, if adequately recompensed. Oh, and since students already have scary student loans, these courses should be *free*. User pays: in this case it's the companies that are the users, not the students. > Or Indeed.Com's salary survey: > http://www.indeed.com/salary/Cobol-Developer.html which shows "Java J2EE Unix Developer" as offering higher average salary than most of the COBOL categories. From ok@REDACTED Mon Feb 17 03:53:26 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 17 Feb 2014 15:53:26 +1300 Subject: [erlang-questions] Erland users group (was re: languages in use? [was: Time for OTP to be Renamed?]) In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FF6EDE.1090205@jkemp.net> Message-ID: On 16/02/2014, at 3:06 AM, Steve Vinoski wrote: > I'm guessing you've never been involved in a standards committee. Having spent years working on various standards, I can assure you they are intensely political and are pretty much just an enormous waste of time. (I was once involved in a heavily politicized standards effort with Pieter, in fact, and both of us were extremely frustrated with the whole thing.) I honestly can't see how bringing standards into the picture will help Erlang in any way. Some standards are pretty useful. The C standard in particular was brilliant. (The C++ standard, as a document, is much harder to work with.) I'm part of the Prolog standard revision process. In that case, - one Prolog vendor sniffed "WE'RE the standard", then scrambled to join the bandwagon (they're dead now); - there was a phase when "ISO Prolog" was on all the developers' lips and used as justification for breaking backwards compatibility; - actual *detailed* compliance with the standard is more or less lacking, except for a few shining exceptions; - a major open source Prolog author has recently basically said "the hell with the standard and all backwards compatibility, I've going to make Prolog fit for web developers" despite the loudly expressed distress of several users who didn't see how the changes would actually help. The Prolog standard was very limited (there wasn't even a built in 'member' predicate) and this was largely because the 'intense politics' made it hard to get _anything_ done. One question I've been known to ask in my software engineering exam is to get students to estimate the cost of making a de facto standard. (I.e., not factoring in ECMA or IEEE or ISO or ANSI or BSI or DIN or whatever expenses.) There _was_ an attempt to produce a standard for Erlang; you can still find the formal specification on the web, but it hasn't been updated for years. From sdl.web@REDACTED Mon Feb 17 05:05:33 2014 From: sdl.web@REDACTED (Leo Liu) Date: Mon, 17 Feb 2014 12:05:33 +0800 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> (Richard A. O'Keefe's message of "Mon, 17 Feb 2014 15:07:48 +1300") References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> Message-ID: On 2014-02-17 10:07 +0800, Richard A. O'Keefe wrote: > For a comparison, I look at R. It's not owned by a business, > but it _is_ managed by a core of bright dedicated people who > keep on rolling out ever-better releases. > > The one thing that they have that Erlang doesn't is a *large* > repository of 3rd-party libraries. Having a single place > to look for stuff (linked right off the main page) is good for > everyone. (There's a single place to *look*; there are mirrors > for *downloading*, which is as simple as > > install.packages(c("wigwam","goose","bridle")) > That will > - fetch the latest descriptions > - download whatever needs downloading > - unpack whatever needs unpacking > - compile whatever support code needs compiling > - put everything where it can be found > - including documentation and examples. > > When we can do something like > > % erl -install cowboy > > won't that be nice? You nailed it, the single most important change that would make a major difference to erlang. The emacs community has a similar story. Now they have three major package archives: an official one and two provided by the community. In under 2 years, thousands of packages appeared. Now users need not deal with editing features or problems upfront and just package-install solutions. Leo From mfidelman@REDACTED Mon Feb 17 05:19:45 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Sun, 16 Feb 2014 23:19:45 -0500 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> Message-ID: <53018DE1.1090901@meetinghouse.net> Leo Liu wrote: > On 2014-02-17 10:07 +0800, Richard A. O'Keefe wrote: >> When we can do something like >> >> % erl -install cowboy >> >> won't that be nice? > You nailed it, the single most important change that would make a major > difference to erlang. > > Maybe a silly question, but what's the story with CEAN? Perl's CPAN repository really is the most amazing repository system I've seen (though packages.debian.org is no slouch either), and CEAN seems to be an attempt at something similar - but it's far from comprehensive, and it's not distributed/mirrored. Perhaps someone can share some history? -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From cao.xu@REDACTED Mon Feb 17 05:49:27 2014 From: cao.xu@REDACTED (rytong-caoxu) Date: Mon, 17 Feb 2014 12:49:27 +0800 Subject: [erlang-questions] httpc considered harmful In-Reply-To: References: Message-ID: I?ve reported the bug a few years ago: http://erlang.org/pipermail/erlang-bugs/2011-November/002647.html And the reason was explained in http://stackoverflow.com/questions/14473416/persistent-keepalive-http-client-implementation-of-erlang With pipeline(or earlier keepalive with problem), httpc client selects the response according to the requests? sending order, which may cause MIXED UP responses if the server fails to response some requests in the sending order. It seems that the bug has already been fixed, but not confirmed by myself. You can use HTTP/0.9 instead, or set the max keepalive queue length to be 1 to work around. ? 2014?2?14????3:39?Felix Gallo ??? > I recently ran into a very scary issue that appears to be related to httpc. > > I was hitting a web API millions of times, with varying URLs; e.g., /users/9000000, /users/9000001, etc., at a rate of around 100-400 requests/sec, using httpc:request, each request spawned by a different worker: > > get_user(UserID) -> > get_user_r(UserID, 10). > get_user_r(UserID, 0) -> > io:format("dying because ran out of retries on ~p~n",[UserID]); > get_user_r(UserID, Retries) -> > Url = lists:concat(["http://example.com/users/", UserID]), > Filename = lists:concat(["users/-", UserID, ".json"]), > io:format("requesting user: ~p~n", [UserID]), > case httpc:request(Url) of > {ok, Result} -> > {_, _, Body} = Result, > file:write_file(Filename, Body), > userscrapemaster ! {ok, ClanID}; > {error, Reason} -> > io:format("error for user ~p: ~p~n",[UserID, Reason]), > get_members_r(UserID, Retries - 1) > > A small (< 0.1%) but significant percentage of the time, the httpc:request call for completely different workers MIXED UP THEIR RESPONSES with other concurrent requests. > > For example, sometimes /users/5000 returned success but provided the body that /users/5001 should have returned, and /users/5001 returned the body that /users/5002 should have returned, and /users/5002 returned the body that /users/5000 should have returned. Or, /users/5009 returned the response for /users/5010, and vice versa. > > There appeared to be no obvious pattern except that all those calls were concurrent, and pragmatically I didn't have the time to go chasing into httpc to try to figure out where the state was getting scrambled, but as a test I moved the call over to lhttpc without changing the structure of the code otherwise, and the mixed responses went away. > > If I get some time I'll try to dig into httpc to understand what happened there, but as a warning to others: httpc looks like it has a hidden race condition or other bug, and lhttpc does not. > > F. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From vances@REDACTED Mon Feb 17 06:15:08 2014 From: vances@REDACTED (Vance Shipley) Date: Mon, 17 Feb 2014 10:45:08 +0530 Subject: [erlang-questions] Generic server and selective receives In-Reply-To: <01ea44277e59d63ec6d4975c9499d738@demblans.com> References: <01ea44277e59d63ec6d4975c9499d738@demblans.com> Message-ID: <20140217051508.GA88353@aluminium.local> On Mon, Feb 17, 2014 at 12:55:19AM +0100, ludovic@REDACTED wrote: } Now, I would like to implement this as a gen_server. But I don't know } how. The Idea is to timeout quickly if no message of the expected } clauses-set comes. } } * I thought of a gen_fsm but it will crash if it's sent a message when } in the "no client" state, right ? (Plus i may want to handle more } receive clauses in the "no client" part) In the example below it will crash if anything but a '{set_client, Pid}' event is received during the 'wait_for_client' state but until you define what it should do that is fine. If it should handle additional events add clauses to wait_for_client/2. } * I thougt about time calculations but it's seems too complicated for } no reason ; I prefer use the simple gen_* timeouts. It's not. } * I could keep my current implementation and adapt the module to fit } in a supervision tree but I believe I willll miss common OTP features. Unless you reimplement most of gen.erl you certainly will. -module(mbox_fsm). -behaviour(gen_fsm). -export([init/1, handle_event/3, handle_sync_event/4, handle_info/3, terminate/3, code_change/4]). -export([wait_for_client/2, wait_for_request/2]). -define(MAXTIME, 60000). -record(statedata, {client_pid, mailbox = [], timeout}). init(_Arg) -> process_flag(trap_exit, true), {ok, wait_for_client, #statedata{}, 10000}. wait_for_client({set_client, Pid}, StateData) -> NextStateData = StateData#statedata{client_pid = Pid}, {next_state, wait_for_request, NextStateData, ?MAXTIME}. wait_for_request({set_client, Pid}, #statedata{timeout = Then} = StateData) -> NextTimeout = ?MAXTIME - timer:now_diff(os:timestamp(), Then), NextStateData = StateData#statedata{client_pid = Pid, timeout = NextTimeout}, {next_state, wait_for_request, NextStateData, NextTimeout}; wait_for_request({message, M}, StateData#statedata{mailbox = Mailbox, timeout = Then}) -> NextTimeout = ?MAXTIME - timer:now_diff(os:timestamp(), Then), NextStateData = StateData#statedata{{mailbox = [M | Mailbox]}, {next_state, wait_for_request, NextStateData, NextTimeout}; % A handful of other clauses wait_for_request(timeout, StateData) -> {stop, timeout, StateData}. handle_info(Info, _StateName, StateData) -> {stop, Info, StateData}. terminate(_Reason, _StateName, _StateData) -> ok. code_change(_OldVsn, StateName, StateData, _Extra) -> {ok, StateName, StateData}. -- -Vance From sdl.web@REDACTED Mon Feb 17 06:19:06 2014 From: sdl.web@REDACTED (Leo Liu) Date: Mon, 17 Feb 2014 13:19:06 +0800 Subject: [erlang-questions] emacs wrapper for rebar Message-ID: Hi list, I have just put rebar.el? in github. I wonder if anyone is interested in testing it and provide some feedback. Should work with emacs 24.3 and trunk (24.3.50). For 24.1 and 24.2 please M-x package-install RET cl-lib RET Leo Footnotes: ? https://github.com/leoliu/rebar.el From ok@REDACTED Mon Feb 17 06:56:27 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 17 Feb 2014 18:56:27 +1300 Subject: [erlang-questions] R16B03-1 installation glitch Message-ID: <31322914-8CB6-43DE-A042-D6C477D2C787@cs.otago.ac.nz> I just downloaded the R16B03-1 source tarball, unpacked it, and did './configure'. Configure works out fairly quickly that this is a Mac OS X box (it's running 10.7.5, in fact). checking build system type... x86_64-apple-darwin11.4.2 checking host system type... x86_64-apple-darwin11.4.2 [Why does it prefer gcc to clang in this environment?] checking for sys/types.h... (cached) yes checking for uid_t in sys/types.h... rm: conftest.dSYM: is a directory ... checking whether gcc needs -traditional... rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory ... checking for egrep... grep -E checking for ANSI C header files... rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory ... checking for getconf... getconf checking for large file support CFLAGS... failed configure: WARNING: Check for large file support flags failed; getconf failed ... checking for ANSI C header files... rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory yes checking for sys/types.h... yes ... checking for IP version 6 support... yes checking for multicast support... rm: conftest.dSYM: is a directory (A) Is there any environment in which gcc -g creates whatever.dSYM and whatever.dSYM is _not_ a directory? (B) Apple's manual page for confstr(3) doesn't mention any supported values other than _CS_PATH. However, if you can get __DARWIN_C_LEVEL >= 200112, a bunch of _CS_POSIX_V6_{ILP32,LP64,LPBIG}_OFF{32,64,BIG}_{CFLAGS,LDFLAGS,LIBS} thingies become visible. They still don't work; confstr(3) says they are valid, but they're all empty strings. I don't believe Mac OS X has a compilation mode that _doesn't_ support large files; __darwin_off_t is unconditionally 64 bits. From siraaj@REDACTED Mon Feb 17 08:40:44 2014 From: siraaj@REDACTED (Siraaj Khandkar) Date: Mon, 17 Feb 2014 02:40:44 -0500 Subject: [erlang-questions] Generic server and selective receives In-Reply-To: <01ea44277e59d63ec6d4975c9499d738@demblans.com> References: <01ea44277e59d63ec6d4975c9499d738@demblans.com> Message-ID: <5301BCFC.7050006@khandkar.net> With gen_server, you have no choice but to handle a message. Once you have it, you can defer processing by stashing it in your process' state. If you want to reject messages when client_pid=undefined, then you may want to consider a protocol with receipt acknowledgements, notifying the sender if the message was accepted or discarded. On 2/16/14, 6:55 PM, ludovic@REDACTED wrote: > Hi, > > I would like some help to implement a message-buffer in erlang. This > process can be sent messages, and stores them in mailbox. A buffer can > have one client, or can have no client. When there's no client, I > would prevent the process to do anything but accept a new client or > timeout after a small amount of time. So I have two sets of receive > clauses. > > Now, I would like to implement this as a gen_server. But I don't know > how. The Idea is to timeout quickly if no message of the expected > clauses-set comes. > > * I thought of a gen_fsm but it will crash if it's sent a message when > in the "no client" state, right ? (Plus i may want to handle more > receive clauses in the "no client" part) > * I thougt about time calculations but it's seems too complicated for > no reason ; I prefer use the simple gen_* timeouts. > * I could keep my current implementation and adapt the module to fit > in a supervision tree but I believe I willll miss common OTP features. > > So, I hope this is a common pattern and that someone will tell me a > good solution. > > Thank you. > > -- lud > > This is my current implementation (but not the actual code). > > loop(#state{client_pid=undefined}) -> > receive > {set_client,Pid} -> > loop(State#state{client_pid=Pid}) > after 10000 -> > io:fwrite("Terminating\n") > end; > > loop(State=#state{client_pid=Client,mailbox=Mailbox}) -> > receive > {set_client,Pid} -> > %% here we can change the client or set it to undefined > loop(State#state{client_pid=Pid}); > {message,M} -> > Client ! you_have_messages, > loop(State#state{mailbox=[M|Mailbox]}); > %% A handful of other clauses > ... > ... > ... > after way more time than 1000 -> > io:fwrite("Terminating too\n") > end; > > > Now i'll pray for this mail to be seen in the current huge amount of > emails (and very intersting by the way) on the list. From bourinov@REDACTED Mon Feb 17 09:10:57 2014 From: bourinov@REDACTED (Max Bourinov) Date: Mon, 17 Feb 2014 09:10:57 +0100 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <048AE900-3CEC-469E-B9B5-5983C08F6E8A@cs.otago.ac.nz> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FF6840.7080105@meetinghouse.net> <048AE900-3CEC-469E-B9B5-5983C08F6E8A@cs.otago.ac.nz> Message-ID: Erlang is absolute genius within existing programming languages for server side programming for highly loaded systems. There is nothing else on the market that can replace Erlang (and there is no need for it). All those languages like java/.net etc makes absolutely no sense on really loaded servers. I strongly believe that if some people/teams/companies have difficulties with Erlang it only shows their misunderstanding or wrong usage or poor language knowledge etc. Or all above and maybe extra... There is nothing else to say. All insinuations about "Where Erlang in use or not?" are poor and have absolutely no reason to exist unless you want to know who uses Erlang and where, but it is a different question. Erlang is really in heavy use. And it really works amazing. Absolutely amazing!!! Best regards for all people involved in Erlang community! Joe Armstrong and Robert Wirding are my heroes! Max On Mon, Feb 17, 2014 at 3:41 AM, Richard A. O'Keefe wrote: > > On 16/02/2014, at 2:14 AM, Miles Fidelman wrote: > > How about this for a larger sample: > > http://eandt.theiet.org/news/2013/mar/cobol-skills.cfm (lede: "Dearth > of COBOL programmers threatens business") > > As someone who has used COBOL, who indeed has OpenCOBOL > on his machine (and some CICS books I've never had a > chance to put into practice), I have to say that > > 'Coughlan ... also believes a certain amount of > "intellectual snobbery", due to the language > not being mathematically based and created by > ... Grace Hopper rather than academics, is at > play." > > is *way* off the mark. COBOL is no more and no > less "mathematically based" than most imperative > programming languages. And it's news to me that C, > C++, Objective C, Visual Basic.NET (we used to teach > that, only stopped recently; I used to do it but > after our then HoD took over, it was decided to stop), > SQL, or PHP was "created by academics". > > Our own beloved Erlang was created _by_ an industrial > company _for_ their industrial purposes, and it wasn't > the first time they'd devised their own language either. > > The problem with COBOL is that it is just amazingly > verbose, not to mention error-prone. > > Unfortunately, COBOL-to-X translators, except for the > very very best, tend to produce programs in language > X that are even more verbose, and far less understandable. > (I haven't used one, but I've seen materials suggesting > that there are some seriously good COBOL-to-X translators > out there, but expect to spend serious money...) > > As for "students only really learn one language, > normally Java or some Java derivative", we teach > Python, Java, and C, and 3rd-year students are > at least exposed to C++ or Objective C. Coughlan > may be correct that students only *learn* one > language, but they are *taught* more. > > The rather whiny tone of the article is one I've heard > before (I wonder where). If businesses are worried > about there not being enough COBOL programmers, the > answer is for *them* to club together and *run some > courses*. If anyone wants to do that in Dunedin, I > would be happy to contribute some teaching time, if > adequately recompensed. Oh, and since students already > have scary student loans, these courses should be > *free*. User pays: in this case it's the companies > that are the users, not the students. > > > Or Indeed.Com's salary survey: > > http://www.indeed.com/salary/Cobol-Developer.html > > which shows "Java J2EE Unix Developer" as offering > higher average salary than most of the COBOL categories. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Mon Feb 17 09:14:34 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Mon, 17 Feb 2014 08:14:34 +0000 Subject: [erlang-questions] beginner: Generating HTML with ">" from Erlang In-Reply-To: <7E203DC5-0617-440B-BFB5-3E080271E514@feuerlabs.com> References: <1392294854.4863.17.camel@sekic1152.release> <6A4DD82E-D7C7-488E-822F-FF1FFC74FE5B@gmail.com> <62792D12-B0CC-49B0-9DC8-D6F796277152@gmail.com> <1392300836.4863.31.camel@sekic1152.release> <1392301543.4863.37.camel@sekic1152.release> , <7E203DC5-0617-440B-BFB5-3E080271E514@feuerlabs.com> Message-ID: Greetings, Thank you for this suggestion with ?#xml-inheritance#?/0. I changed ?#text#?/1 to 'script'/4, ignore all arguments and return the script as it was (with ">"). Works for me. bengt ________________________________________ From: erlang-questions-bounces@REDACTED [erlang-questions-bounces@REDACTED] on behalf of Ulf Wiger [ulf@REDACTED] Sent: Thursday, 13 February 2014 4:08 PM To: Szoboszlay D?niel Cc: erlang questions Subject: Re: [erlang-questions] beginner: Generating HTML with ">" from Erlang You don?t need to copy xmerl_xml. Simply write the following module. ==================================== -module(szoboszlay_xml). -export([?#text#?/1, ?#xml-inheritance#?]). ?#xml-inheritance#?() -> [xmerl_xml]. '#text#'(Text) -> ["?]. ==================================== And you?re done. ;-) BR, Ulf On 13 Feb 2014, at 15:48, Szoboszlay D?niel wrote: > I think it's not possible to add CDATA or PCDATA directives in out-of-the-box xmerl. But you can write your own callback module by simply copying xmerl_xml and changing '#text#'/1 slightly: > > '#text#'(Text) -> [""]. > > Cheers, > Daniel > > On Thu, 13 Feb 2014 15:25:43 +0100, Bengt Kleberg wrote: > >> This also sounds like a good idea. You would not happen to know how I >> could get "![PCDATA[" into xmerl tuples? >> >> >> bengt >> >> On Thu, 2014-02-13 at 15:20 +0100, Szoboszlay D?niel wrote: >>> What about wrapping the Javascript code in a section? >>> The browser shall parse > as < in PCDATA before interpreting it as >>> Javascript code. >>> >>> Daniel >>> >>> On Thu, 13 Feb 2014 15:13:56 +0100, Bengt Kleberg >>> wrote: >>> >>> > Javascript needs ">". >>> > >>> > >>> > On Thu, 2014-02-13 at 13:59 +0100, Anthony Ramine wrote: >>> >> Mmmmh, right. Was thinking about <. >>> >> >>> >> That being said, code consuming HTML or XML shouldn?t see a difference, >>> >> and not escaping could also introduce other bugs, as ]]> is not >>> >> supposed to appear in content (in XML). This leads us to the original >>> >> question, which was ? why do you need to do this? ?. >>> >> >>> > >>> > _______________________________________________ >>> > 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 _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From bengt.kleberg@REDACTED Mon Feb 17 09:26:14 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Mon, 17 Feb 2014 08:26:14 +0000 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <530000E7.9080103@meetinghouse.net> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFCE9A.6050802@ninenines.eu>,<530000E7.9080103@meetinghouse.net> Message-ID: Plan9 seemed like the obvious Unix successor about 25 years ago, but here we are still using Unix (now called Linux). As to why... The plural of anecdote is not fact, but I can tell you what we (Swedish UNIX Users Group) did around 1991-92. Different speakers came over from the US to our meetings and talked about Plan9 and 386BSD. Plan9 was more interesting, but you had to be at a university to get hold of it. 386BSD was just regular Unix, which made it better to some, but most important, anybody could have the source. Almost everybody decided to devote their time/interest/etc to BSD386, instead of Plan9. Then BSDi got sued and all those people moved to Linux. bengt ________________________________________ From: erlang-questions-bounces@REDACTED [erlang-questions-bounces@REDACTED] on behalf of Miles Fidelman [mfidelman@REDACTED] Sent: Sunday, 16 February 2014 1:05 AM To: erlang-questions@REDACTED Subject: Re: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] Lo?c Hoguin wrote: > > To make a comparison, it generally goes like this: > > What's Go? -> Language from Google by the Unix people -> I know and > like those, therefore Go must be good too, plus it looks similar to > what I'm used to. > > What's Erlang? -> Language from Ericsson invented 25+ years ago -> > Really? I'm not sure what Ericsson does... If it was invented 25 years > ago and I haven't heard about it yet it must not be very good, plus > it's not OO so it must not be very useful. > > You can't fix that. > > What you can fix about perception is actually minimal stuff. Like > changing the name. Using release numbers that aren't from another > planet. And so on. > This is just plain silly. When folks chose a language/platform for a project, the reasons tend to be: 1. We're a shop. We've invested a lot in tooling, that's what our people know. Period. 2. Our deployment environment requires it (writing iPhone apps, you're writing in Objective-C, still writing for Blackberry, Java it is) 3. Our customers require it. 4. For large, complicated projects, there may be a formal technology assessment. (E.g, Boeing didn't just stick a finger in the air and say "let's use Ada for the avionics on the 777." They did a pretty extensive technology assessment as part of the systems engineering phase of design and development.) Sometimes, this goes further - as in "there's nothing that meets our requirements, we'll develop something" (e.g., Ericsson developed Erlang to fill a need). 5. It comes embedded in a key software component (similar to 4). E.g., we selected Riak as our database platform, it's written in Erlang. (Or RabbitMQ, or CouchDB, or ...) Older languages have inertia behind them. Nobody is talking about renaming C, or spending much money marketing it. (Or the gnu build system for that matter.) Newer languages gain traction when there's a new need - Java addressed the "write once, run everywhere" vision. Hasn't quite proven to be the holy grain, but it gained a lot of traction in the process. Erlang came into being to meet a very specific requirement at Ericsson, and did it well. Newer applications have come because both requirements and hardware have evolved - and Erlang is uniquely capable of addressing them. Anybody who's building a high-availability system that is massively concurrent in nature, and does even a modicum of technology assessment, is going to find Erlang. It's name, what OTP stands for, marketing, aren't going to make a difference one way or another. On the other hand, it's longevity, community, and ecosystem will make a difference - folks don't commit large amounts of dollars to something that isn't going to be around down the road. Erlang seems to do pretty well in these regards - at least to the point that some fairly large players have committed to Erlang on key projects, and some serious venture capitalists have invested in Erlang-based ventures (Couchbase, Basho come to mind). Again, name and marketing don't really have a lot to do with this (I offer the gnu build system and CPAN as examples). As to Go - it's a toy - Google or no Google, I don't see any systems being built in it (the jury is still out on Clojure - another Google project that has a clear rational and a lot more backing). One might also wonder why Plan9 and Inferno didn't get more traction as successors to Unix and C. 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 From zkessin@REDACTED Mon Feb 17 09:42:03 2014 From: zkessin@REDACTED (Zachary Kessin) Date: Mon, 17 Feb 2014 10:42:03 +0200 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FF6840.7080105@meetinghouse.net> <048AE900-3CEC-469E-B9B5-5983C08F6E8A@cs.otago.ac.nz> Message-ID: <5301CB5B.30602@gmail.com> We did a podcast a while back on when not to use erlang, which I thought was very interesting http://mostlyerlang.com/2013/05/30/005-when-not-to-use-erlang/ There are definitely places where the Erlang Ecosystem is week, but they seem to be things people are working on --Zach On 2/17/14, 10:10 AM, Max Bourinov wrote: > Erlang is absolute genius within existing programming languages for > server side programming for highly loaded systems. There is nothing > else on the market that can replace Erlang (and there is no need for > it). All those languages like java/.net etc makes absolutely no sense > on really loaded servers. > > I strongly believe that if some people/teams/companies have > difficulties with Erlang it only shows their misunderstanding or wrong > usage or poor language knowledge etc. Or all above and maybe extra... > > There is nothing else to say. All insinuations about "Where Erlang in > use or not?" are poor and have absolutely no reason to exist unless > you want to know who uses Erlang and where, but it is a different > question. > > Erlang is really in heavy use. And it really works amazing. Absolutely > amazing!!! > > Best regards for all people involved in Erlang community! > > Joe Armstrong and Robert Wirding are my heroes! > > Max > > > On Mon, Feb 17, 2014 at 3:41 AM, Richard A. O'Keefe > wrote: > > > On 16/02/2014, at 2:14 AM, Miles Fidelman wrote: > > How about this for a larger sample: > > http://eandt.theiet.org/news/2013/mar/cobol-skills.cfm (lede: > "Dearth of COBOL programmers threatens business") > > As someone who has used COBOL, who indeed has OpenCOBOL > on his machine (and some CICS books I've never had a > chance to put into practice), I have to say that > > 'Coughlan ... also believes a certain amount of > "intellectual snobbery", due to the language > not being mathematically based and created by > ... Grace Hopper rather than academics, is at > play." > > is *way* off the mark. COBOL is no more and no > less "mathematically based" than most imperative > programming languages. And it's news to me that C, > C++, Objective C, Visual Basic.NET (we used to teach > that, only stopped recently; I used to do it but > after our then HoD took over, it was decided to stop), > SQL, or PHP was "created by academics". > > Our own beloved Erlang was created _by_ an industrial > company _for_ their industrial purposes, and it wasn't > the first time they'd devised their own language either. > > The problem with COBOL is that it is just amazingly > verbose, not to mention error-prone. > > Unfortunately, COBOL-to-X translators, except for the > very very best, tend to produce programs in language > X that are even more verbose, and far less understandable. > (I haven't used one, but I've seen materials suggesting > that there are some seriously good COBOL-to-X translators > out there, but expect to spend serious money...) > > As for "students only really learn one language, > normally Java or some Java derivative", we teach > Python, Java, and C, and 3rd-year students are > at least exposed to C++ or Objective C. Coughlan > may be correct that students only *learn* one > language, but they are *taught* more. > > The rather whiny tone of the article is one I've heard > before (I wonder where). If businesses are worried > about there not being enough COBOL programmers, the > answer is for *them* to club together and *run some > courses*. If anyone wants to do that in Dunedin, I > would be happy to contribute some teaching time, if > adequately recompensed. Oh, and since students already > have scary student loans, these courses should be > *free*. User pays: in this case it's the companies > that are the users, not the students. > > > Or Indeed.Com's salary survey: > > http://www.indeed.com/salary/Cobol-Developer.html > > which shows "Java J2EE Unix Developer" as offering > higher average salary than most of the COBOL categories. > > _______________________________________________ > 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 -- Zachary Kessin Mostly Erlang Podcast Skype: zachkessin Twitter: @zkessin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: zkessin.vcf Type: text/x-vcard Size: 264 bytes Desc: not available URL: From n.oxyde@REDACTED Mon Feb 17 10:11:37 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 17 Feb 2014 10:11:37 +0100 Subject: [erlang-questions] Generic server and selective receives In-Reply-To: <20140217051508.GA88353@aluminium.local> References: <01ea44277e59d63ec6d4975c9499d738@demblans.com> <20140217051508.GA88353@aluminium.local> Message-ID: You don?t have to reimplement ?gen? to implement a sys process, no. -- Anthony Ramine Le 17 f?vr. 2014 ? 06:15, Vance Shipley a ?crit : > Unless you reimplement most of gen.erl you certainly will. From davidnwelton@REDACTED Mon Feb 17 10:23:44 2014 From: davidnwelton@REDACTED (David Welton) Date: Mon, 17 Feb 2014 10:23:44 +0100 Subject: [erlang-questions] random thought: connecting to node, specify IP address Message-ID: Hi, For various reasons, we sometimes have nodes that come up with a long node name that does not nicely map onto the network - say, foo@REDACTED or foo@REDACTED that does not get a DNS entry. The nodes operate in somewhat unknown and unstable network situation, so we may not even know the IP address ahead of time. It'd be nice to be able to - at a later date - force a connection to those nodes by specifying an IP address in the connection code somewhere. Is something like this at all feasible? Thank you -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From ludovic@REDACTED Mon Feb 17 10:38:23 2014 From: ludovic@REDACTED (ludovic@REDACTED) Date: Mon, 17 Feb 2014 10:38:23 +0100 Subject: [erlang-questions] Fwd: Re: Generic server and selective receives Message-ID: Hi, Thank you for yours answers. With timer:no_diff/ is quite easy to handle "selective timeout" in a gen server so okay it could be a decent solution. The only problem is to have code to handle it in every callback that reset the timeout, this is okay. But I would not use a gen_fsm, because if you look at my first implementation, when there's no client the messages that are NOT {set_client, ...} are not discarded, they are stacked in the process mailbox for later use and this is expected. Le 2014-02-17 10:11, Anthony Ramine a ?crit?: > You don?t have to reimplement ?gen? to implement a sys process, no. As i may need to implement several processes with this kind of "client presence enforcement", implementing a sys process could be worth trying. (Plus i'll learn a lot). Have you got any link to a good tutorial/guide ? Thanks -- lud From bourinov@REDACTED Mon Feb 17 10:48:24 2014 From: bourinov@REDACTED (Max Bourinov) Date: Mon, 17 Feb 2014 10:48:24 +0100 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <5300C6D8.5080306@meetinghouse.net> References: <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> <52FD0B24.50400@meetinghouse.net> <52FD0C14.6060004@meetinghouse.net> <20140216091344.GF96250@wavenets-mbp.motivity.ca> <5300C6D8.5080306@meetinghouse.net> Message-ID: Why? Why does this thread exists? Best regards, Max On Sun, Feb 16, 2014 at 3:10 PM, Miles Fidelman wrote: > Vance Shipley wrote: > >> On Thu, Feb 13, 2014 at 12:22:54PM -0600, kraythe . wrote: >> } Not so much the issue of OTP as a name but the general impression of >> } "adoption? bah humbug ... if they don't like it they all suck and we >> } don't care." Sounds like a disaster of a business decision to me. >> >> Erlang has always been a very practical thing. It is a functional >> language, but not purely so. It's developers have always chosen the >> path which made sense for it's commercial use. It's not a language >> made to teach computer science courses, it's made to be as useful as >> possible to build real life commercial applications. It's rooted in >> industry. You're questioning the business decisions of a company which >> has been at this for over two decades. >> >> } Im not so sure its going to be easy to staff or finance a project on a >> } language that has 1) tools that need work, 2) a limited trained staff >> 3) a >> } community that cares little about language adoption. It could be that >> } Erlang becomes another Lisp for me. A language I think rocks but is >> } entirely impractical in the business world. >> >> My greatest wish is that any potential competitor of mine believes all >> of the FUD above. >> >> The truth is (my competitors shouldn't trust me, I'm probably lying) that >> Erlang/OTP is a very practical platform for many business applications. >> >> > I like the way you think! (On a lighter note: http://xkcd.com/1330/) > > > > > > -- > 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 jesper.louis.andersen@REDACTED Mon Feb 17 11:08:46 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 17 Feb 2014 11:08:46 +0100 Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <53012965.5030001@meetinghouse.net> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFEAC6.50308@gmail.com> <5300CF44.8050206@meetinghouse.net> <53012965.5030001@meetinghouse.net> Message-ID: On Sun, Feb 16, 2014 at 10:11 PM, Miles Fidelman wrote: > Good point. "Let it crash" does take on a whole different meaning when > dealing with aircraft and such. This is a different point as well! You have two axis: * soft vs hard realtime. Some systems require hard realtime and then your tools are limited to languages where you have explicit memory control, enabling you to avoid allocating memory and triggering garbage collection. In soft realtime systems, you have more leeway, and if built the way of the Erlang runtime system, you get really good soft realtime capability. * Proactive vs Reactive error handling. The idea of "let it crash" is definitively reactive, whereas static type systems, proofs, model checking, etc are means of proactive error handling. My claim however, is that you need "Let it crash" in Aircrafts as well if you want to have a stable aircraft. The model where you blindly attempt to eradicate every error from a program is bound to fail sooner or later. Usually "let it crash" in those situations is implemented in hardware by having multiple redundant systems. But rarely are systems exempt of failure. Even in a highly controlled environment. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Mon Feb 17 11:23:51 2014 From: spawn.think@REDACTED (Ahmed Omar) Date: Mon, 17 Feb 2014 11:23:51 +0100 Subject: [erlang-questions] disconnected nodes In-Reply-To: <53012CD1.7030605@gmail.com> References: <53012CD1.7030605@gmail.com> Message-ID: Hi Ignas, That issue was really long time ago, so I'm afraid I don't recall all details. What I remember is the issue disappeared suddenly, same way as it appeared. We had similar symptoms later of nodes dropping out of the cluster but I don't remember seeing the ebadf errors. (can't be sure) The reason for the later incidents, was usually high traffic between the nodes. That traffic could cause distribution buffer to reach limits and suspend processes trying to communicate with other processes on other nodes. ( http://erlang.org/doc/man/erlang.html#system_info_dist_buf_busy_limit) One quick work around for that would be to increase the limit using +zdbbl flag on startup. A more permanent solution would be to look into the traffic between the nodes and optimise there. Hope that helps somehow. Best Regards, - Ahmed Omar http://about.me/spawn.think/ On Sun, Feb 16, 2014 at 10:25 PM, Ignas Vy?niauskas wrote: > On 02/16/2014 04:02 PM, T Ty wrote: > > Are you also using Mnesia ? > > Nope. > > -- > Ignas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Mon Feb 17 11:58:18 2014 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 17 Feb 2014 11:58:18 +0100 Subject: [erlang-questions] Preloaded modules "lists" dependency In-Reply-To: <52FDF77B.4070907@ninenines.eu> References: <52FDF77B.4070907@ninenines.eu> Message-ID: Hello Lo?c, On Fri, Feb 14, 2014 at 12:01 PM, Lo?c Hoguin wrote: > > I realize that the lists module has BIFs so perhaps running a VM with a > changed lists module could create issues. I am not well versed enough to > know that for sure. > Right now the list of bifs and which modules they are in reside in $ERL_TOP/erts/emulator/beam/bifs.tab and is statically compiled into the VM. What happens is that when loading modules that list is checked to see if a function in that module is a BIF and the big code is linked instead. So if you want to change the lists (or ets for that matter) module you would have to create a solution for either in compile time removing those bifs or possibly figuring it out in runtime. It should be possible to do in a separate fork of Erlang/OTP to start with and if it proves to be generally useful I don't see why it wouldn't be possible to bring it upstream. On Fri, Feb 14, 2014 at 12:01 PM, Lo?c Hoguin wrote: > > Any chance of having that dependency removed eventually? There are 13 > occurrences of lists: in the preloaded modules. The functions used are > keyreplace, member, reverse, foldl, foreach. The first 3 are BIFs, the > other 2 aren't. Perhaps the first 3 could also be available from a > prim_lists module and the other two inlined? This way the VM doesn't > require any additional module to run, except of course error_logger but > that's only a requirement when you want to extend the basic functionality. > This is something that would be a lot easier to do and less complicated to make it into upstream. As long as there are tests that make sure nothing is broken over time. Lukas PS. Keep in mind that these are my personal opinions. DS -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Mon Feb 17 12:07:18 2014 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 17 Feb 2014 12:07:18 +0100 Subject: [erlang-questions] Preloaded modules "lists" dependency In-Reply-To: References: <52FDF77B.4070907@ninenines.eu> Message-ID: On Fri, Feb 14, 2014 at 1:46 PM, Max Lapshin wrote: > btw, why lists bifs are not nifs? They all can be implemented in classic > nif way: erlang implementation hidden by fast C nif. > > Because: 1. Nifs did not exist when most (maybe all) of them where written. 2. Nobody has felt that it is important to make a clean separation of stdlib and the VM. 3. BIFs can cheat :) maybe this is the most important reason. There are shortcuts that BIFS take that a NIF cannot. Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.virding@REDACTED Mon Feb 17 12:14:14 2014 From: robert.virding@REDACTED (Robert Virding) Date: Mon, 17 Feb 2014 12:14:14 +0100 (CET) Subject: [erlang-questions] languages in use? [was: Time for OTP to be Renamed?] In-Reply-To: <5301CB5B.30602@gmail.com> References: <52FE3894.2000003@meetinghouse.net> <52FF6840.7080105@meetinghouse.net> <048AE900-3CEC-469E-B9B5-5983C08F6E8A@cs.otago.ac.nz> <5301CB5B.30602@gmail.com> Message-ID: <37153750.1438599.1392635654170.JavaMail.zimbra@erlang-solutions.com> I would say that it is not just the erlang ecosystem (maybe) being weak which might limit where erlang is suitable, but the language itself imposes limitations on where it is useful. For example two areas where NOT to use Erlang: - Raw number crunching - while can do arithmetic it is not that fast at it and was never intended for it. With the Erlang you will get tomorrows weather report next month. - Problems where shared data is the best fit - there are applications where sharing data is the best fit, even when running very parallel. Erlang is not good at sharing. That said Erlang might be a very good choice for managing these types of applications where you hand over the low-level work to other languages/specialised hardware. Robert ----- Original Message ----- > From: "Zachary Kessin" > To: erlang-questions@REDACTED > Sent: Monday, 17 February, 2014 9:42:03 AM > Subject: Re: [erlang-questions] languages in use? [was: Time for OTP to be > Renamed?] > We did a podcast a while back on when not to use erlang, which I thought was > very interesting > http://mostlyerlang.com/2013/05/30/005-when-not-to-use-erlang/ > There are definitely places where the Erlang Ecosystem is week, but they seem > to be things people are working on > --Zach > On 2/17/14, 10:10 AM, Max Bourinov wrote: > > Erlang is absolute genius within existing programming languages for server > > side programming for highly loaded systems. There is nothing else on the > > market that can replace Erlang (and there is no need for it). All those > > languages like java/.net etc makes absolutely no sense on really loaded > > servers. > > > I strongly believe that if some people/teams/companies have difficulties > > with > > Erlang it only shows their misunderstanding or wrong usage or poor language > > knowledge etc. Or all above and maybe extra... > > > There is nothing else to say. All insinuations about "Where Erlang in use > > or > > not?" are poor and have absolutely no reason to exist unless you want to > > know who uses Erlang and where, but it is a different question. > > > Erlang is really in heavy use. And it really works amazing. Absolutely > > amazing!!! > > > Best regards for all people involved in Erlang community! > > > Joe Armstrong and Robert Wirding are my heroes! > > > Max > > > On Mon, Feb 17, 2014 at 3:41 AM, Richard A. O'Keefe < ok@REDACTED > > > wrote: > > > > On 16/02/2014, at 2:14 AM, Miles Fidelman wrote: > > > > > > > How about this for a larger sample: > > > > > > > http://eandt.theiet.org/news/2013/mar/cobol-skills.cfm (lede: "Dearth > > > > of > > > > COBOL programmers threatens business") > > > > > > As someone who has used COBOL, who indeed has OpenCOBOL > > > > > > on his machine (and some CICS books I've never had a > > > > > > chance to put into practice), I have to say that > > > > > > 'Coughlan ... also believes a certain amount of > > > > > > "intellectual snobbery", due to the language > > > > > > not being mathematically based and created by > > > > > > ... Grace Hopper rather than academics, is at > > > > > > play." > > > > > > is *way* off the mark. COBOL is no more and no > > > > > > less "mathematically based" than most imperative > > > > > > programming languages. And it's news to me that C, > > > > > > C++, Objective C, Visual Basic.NET (we used to teach > > > > > > that, only stopped recently; I used to do it but > > > > > > after our then HoD took over, it was decided to stop), > > > > > > SQL, or PHP was "created by academics". > > > > > > Our own beloved Erlang was created _by_ an industrial > > > > > > company _for_ their industrial purposes, and it wasn't > > > > > > the first time they'd devised their own language either. > > > > > > The problem with COBOL is that it is just amazingly > > > > > > verbose, not to mention error-prone. > > > > > > Unfortunately, COBOL-to-X translators, except for the > > > > > > very very best, tend to produce programs in language > > > > > > X that are even more verbose, and far less understandable. > > > > > > (I haven't used one, but I've seen materials suggesting > > > > > > that there are some seriously good COBOL-to-X translators > > > > > > out there, but expect to spend serious money...) > > > > > > As for "students only really learn one language, > > > > > > normally Java or some Java derivative", we teach > > > > > > Python, Java, and C, and 3rd-year students are > > > > > > at least exposed to C++ or Objective C. Coughlan > > > > > > may be correct that students only *learn* one > > > > > > language, but they are *taught* more. > > > > > > The rather whiny tone of the article is one I've heard > > > > > > before (I wonder where). If businesses are worried > > > > > > about there not being enough COBOL programmers, the > > > > > > answer is for *them* to club together and *run some > > > > > > courses*. If anyone wants to do that in Dunedin, I > > > > > > would be happy to contribute some teaching time, if > > > > > > adequately recompensed. Oh, and since students already > > > > > > have scary student loans, these courses should be > > > > > > *free*. User pays: in this case it's the companies > > > > > > that are the users, not the students. > > > > > > > Or Indeed.Com's salary survey: > > > > > > > http://www.indeed.com/salary/Cobol-Developer.html > > > > > > which shows "Java J2EE Unix Developer" as offering > > > > > > higher average salary than most of the COBOL categories. > > > > > > _______________________________________________ > > > > > > 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 > > -- > Zachary Kessin > Mostly Erlang Podcast > Skype: zachkessin > Twitter: @zkessin > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Mon Feb 17 12:24:32 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Mon, 17 Feb 2014 12:24:32 +0100 Subject: [erlang-questions] [erlide] user poll: supported versions Message-ID: Hi all! This is a question for all erlide users (but not only for them). Erlide uses Erlang as a backend and we try to use the same policy as OTP when it comes to older versions: the current major version plus the two most recent ones. When R17 is released, this means R16 and R15. Until now, it was possible to only have R14 installed and run erlide on it. The problem that I discovered is that in order to provide full support for unicode, I need to use erl_scan from R16+, which can't be compiled for R15 because it contains unicode. My question is: would it be a problem to require that erlide itself must run on R16 or newer? Projects can still be based on earlier releases. This will require in the worst case that you install R16 alongside your other versions. For most people this is a non-issue, but in some environments one doesn't have full freedom. best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Mon Feb 17 13:22:07 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Mon, 17 Feb 2014 04:22:07 -0800 (PST) Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: <20140216114402.8130F240C4FB@mail.tail-f.com> References: <20140216114402.8130F240C4FB@mail.tail-f.com> Message-ID: <1392639727.41404.YahooMailNeo@web140103.mail.bf1.yahoo.com> I like "Erlang SDK" better than "OTP" by the way, even if it feels a bit old fashioned. It gets the point across, at least. I've found gen_servers/gen_fsm/etc awkward when some sub-problem cries out for selective receive. Best, Thomas On Sunday, February 16, 2014 12:44 PM, Joacim Greben? wrote: Note. I love the Erlang SDK (just trying avoid the *TP word to see how it feels) and use it heavily. It is just the gen_server that takes away the fun. We need more fun and not less. > >Den 16 feb 2014 12:28 skrev =?ISO-8859-1?Q?Joacim_Greben=F6?= : >> >> I have read http://www.erlang.org/doc/design_principles/spec_proc.html over the years and only opted to implement parts of all the overhead, i.e. to get the part of OTP functionality I really need and no more. >> >> The gen_server is is top heavy and boring and remindes me of Java Enterprise Beans. >> >> Agile and fun is better than top heavy and boring. In the short run, and in the long run. >> >> But this is all me. >> >> Den 16 feb 2014 11:40 skrev Vance Shipley : >> > >> > On Sun, Feb 16, 2014 at 11:06:08AM +0100, Joacim Greben? wrote: >> > }? I would only use the gen_server iff I needed hot code loading/upgrading. >> > }? In the real world, and in the majority of cases, that seldom is needed. >> > }? >> > }? IMHO and within my experience of course. >> > >> > Lest other, less experienced, readers get the impression that it is that >> > simple let me just provide this pointer: >> > >> > ?? http://www.erlang.org/doc/design_principles/spec_proc.html >> > >> > To write a program which will work (properly) in an OTP compliant system, >> > you must receive and handle a number of system messages.? Without OTP >> > compliance you have no supervision, debugging, release handling, observer >> > and I don't know what else.? You are free to do so but I wouldn't recommend >> > this route for anyone else who hasn't mastered the environment. >> > >> > -- >> > -Vance >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Mon Feb 17 13:29:18 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 17 Feb 2014 07:29:18 -0500 Subject: [erlang-questions] let it crash erlang/ada [[was: Time for OTP to be Renamed?] In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFEAC6.50308@gmail.com> <5300CF44.8050206@meetinghouse.net> <53012965.5030001@meetinghouse.net> Message-ID: <5302009E.2040507@meetinghouse.net> Jesper Louis Andersen wrote: > > On Sun, Feb 16, 2014 at 10:11 PM, Miles Fidelman > > wrote: > > Good point. "Let it crash" does take on a whole different meaning > when dealing with aircraft and such. > > > This is a different point as well! You have two axis: > > * soft vs hard realtime. Some systems require hard realtime and then > your tools are limited to languages where you have explicit memory > control, enabling you to avoid allocating memory and triggering > garbage collection. In soft realtime systems, you have more leeway, > and if built the way of the Erlang runtime system, you get really good > soft realtime capability. > > * Proactive vs Reactive error handling. The idea of "let it crash" is > definitively reactive, whereas static type systems, proofs, model > checking, etc are means of proactive error handling. > > My claim however, is that you need "Let it crash" in Aircrafts as well > if you want to have a stable aircraft. The model where you blindly > attempt to eradicate every error from a program is bound to fail > sooner or later. Usually "let it crash" in those situations is > implemented in hardware by having multiple redundant systems. But > rarely are systems exempt of failure. Even in a highly controlled > environment. We've really strayed off-topic here, but.... My all-time favorite design for seriously mission-critical systems was the flight control system for the Space Shuttle. I'm not sure this is true of the later versions, but originally: - the flight control software ran on 5 parallel computers, that voted on results - 4 of the computers came from one contractor (hardware and software) - the 5th machine, just ran mission-critical code, with a completely separate design (both hardware and software) - I don't remember how the tie-breaking algorithm worked Cheers, Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From valentin@REDACTED Mon Feb 17 13:30:09 2014 From: valentin@REDACTED (Valentin Micic) Date: Mon, 17 Feb 2014 14:30:09 +0200 Subject: [erlang-questions] Time for OTP to be Renamed? In-Reply-To: References: <775FCB1F-BE68-46CB-9785-FFA065A11B78@gmail.com> <20140213170857.GK62889@ferdair.local> <52FD0B24.50400@meetinghouse.net> <52FD0C14.6060004@meetinghouse.net> <20140216091344.GF96250@wavenets-mbp.motivity.ca> <5300C6D8.5080306@meetinghouse.net> Message-ID: <6E5A66C4-83D5-48FF-BF95-8E7E9F674628@pixie.co.za> On 17 Feb 2014, at 11:48 AM, Max Bourinov wrote: > Why? Why does this thread exists? So we can get our trolling needs out of our systems and get on with useful stuff? ;-) V/ From pierrefenoll@REDACTED Mon Feb 17 13:30:46 2014 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Mon, 17 Feb 2014 13:30:46 +0100 Subject: [erlang-questions] Preloaded modules "lists" dependency In-Reply-To: References: <52FDF77B.4070907@ninenines.eu> Message-ID: Hey Lo?c, I don't mean to hijack the thread. Can we have more information on "Erlang2/OTP2"? Your guidelines and back-of-a-napkin experiments interest me greatly. Cheers, -- Pierre Fenoll On 17 February 2014 12:07, Lukas Larsson wrote: > On Fri, Feb 14, 2014 at 1:46 PM, Max Lapshin wrote: > >> btw, why lists bifs are not nifs? They all can be implemented in classic >> nif way: erlang implementation hidden by fast C nif. >> >> Because: > 1. Nifs did not exist when most (maybe all) of them where written. > 2. Nobody has felt that it is important to make a clean separation of > stdlib and the VM. > 3. BIFs can cheat :) maybe this is the most important reason. There are > shortcuts that BIFS take that a NIF cannot. > > Lukas > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sevenjp@REDACTED Mon Feb 17 13:39:07 2014 From: sevenjp@REDACTED (=?UTF-8?Q?Jo=C3=A3o_Neves?=) Date: Mon, 17 Feb 2014 13:39:07 +0100 Subject: [erlang-questions] let it crash erlang/ada [[was: Time for OTP to be Renamed?] In-Reply-To: <5302009E.2040507@meetinghouse.net> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFEAC6.50308@gmail.com> <5300CF44.8050206@meetinghouse.net> <53012965.5030001@meetinghouse.net> <5302009E.2040507@meetinghouse.net> Message-ID: SpaceX also does it and is a central part of their design: "Q: So, these flight computers on Dragon ? there are three on board, and that's for redundancy? A: There are actually six computers. They operate in pairs, so there are three computer units, each of which have two computers checking on each other. The reason we have three is when operating in proximity of ISS, we have to always have two computer strings voting on something on critical actions. We have three so we can tolerate a failure and still have two voting on each other. And that has nothing to do with radiation, that has to do with ensuring that we're safe when we're flying our vehicle in the proximity of the space station. I went into the lab earlier today, and we have 18 different processing units with computers in them. We have three main computers, but 18 units that have a computer of some kind, and all of them are triple computers ? everything is three processors. So we have like 54 processors on the spacecraft. It's a highly distributed design and very fault-tolerant and very robust." ( http://www.aviationweek.com/Blogs.aspx?plckBlogId=Blog:04ce340e-4b63-4d23-9695-d49ab661f385&plckPostId=Blog:04ce340e-4b63-4d23-9695-d49ab661f385Post:a8b87703-93f9-4cdf-885f-9429605e14df ) -- Jo?o Neves 2014-02-17 13:29 GMT+01:00 Miles Fidelman : > Jesper Louis Andersen wrote: > >> >> On Sun, Feb 16, 2014 at 10:11 PM, Miles Fidelman < >> mfidelman@REDACTED > wrote: >> >> Good point. "Let it crash" does take on a whole different meaning >> when dealing with aircraft and such. >> >> >> This is a different point as well! You have two axis: >> >> * soft vs hard realtime. Some systems require hard realtime and then your >> tools are limited to languages where you have explicit memory control, >> enabling you to avoid allocating memory and triggering garbage collection. >> In soft realtime systems, you have more leeway, and if built the way of the >> Erlang runtime system, you get really good soft realtime capability. >> >> * Proactive vs Reactive error handling. The idea of "let it crash" is >> definitively reactive, whereas static type systems, proofs, model checking, >> etc are means of proactive error handling. >> >> My claim however, is that you need "Let it crash" in Aircrafts as well if >> you want to have a stable aircraft. The model where you blindly attempt to >> eradicate every error from a program is bound to fail sooner or later. >> Usually "let it crash" in those situations is implemented in hardware by >> having multiple redundant systems. But rarely are systems exempt of >> failure. Even in a highly controlled environment. >> > > We've really strayed off-topic here, but.... > > My all-time favorite design for seriously mission-critical systems was the > flight control system for the Space Shuttle. I'm not sure this is true of > the later versions, but originally: > - the flight control software ran on 5 parallel computers, that voted on > results > - 4 of the computers came from one contractor (hardware and software) > - the 5th machine, just ran mission-critical code, with a completely > separate design (both hardware and software) > - I don't remember how the tie-breaking algorithm worked > > Cheers, > > Miles > > > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Mon Feb 17 13:44:16 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 17 Feb 2014 07:44:16 -0500 Subject: [erlang-questions] let it crash erlang/ada [[was: Time for OTP to be Renamed?] In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFEAC6.50308@gmail.com> <5300CF44.8050206@meetinghouse.net> <53012965.5030001@meetinghouse.net> <5302009E.2040507@meetinghouse.net> Message-ID: <53020420.7030607@meetinghouse.net> Interesting. What I find particularly notable about the Space Shuttle design is the notion of separate development of hardware and software - by different teams at different vendors - as a fault checking mechanism. I guess the core mathematics has to be the same (e.g., ballistic calculations), but beyond that, different code, running on different hardware, but they have to get to the same results, or something is wrong. More copies of the same hardware/software just means more copies of any bugs! Cheers, Miles Jo?o Neves wrote: > SpaceX also does it and is a central part of their design: > > "Q: So, these flight computers on Dragon ? there are three on board, > and that's for redundancy? > > A: There are actually six computers. They operate in pairs, so there > are three computer units, each of which have two computers checking on > each other. The reason we have three is when operating in proximity of > ISS, we have to always have two computer strings voting on something > on critical actions. We have three so we can tolerate a failure and > still have two voting on each other. And that has nothing to do with > radiation, that has to do with ensuring that we're safe when we're > flying our vehicle in the proximity of the space station. > > I went into the lab earlier today, and we have 18 different processing > units with computers in them. We have three main computers, but 18 > units that have a computer of some kind, and all of them are triple > computers ? everything is three processors. So we have like 54 > processors on the spacecraft. It's a highly distributed design and > very fault-tolerant and very robust." > > (http://www.aviationweek.com/Blogs.aspx?plckBlogId=Blog:04ce340e-4b63-4d23-9695-d49ab661f385&plckPostId=Blog:04ce340e-4b63-4d23-9695-d49ab661f385Post:a8b87703-93f9-4cdf-885f-9429605e14df) > > > -- > Jo?o Neves > > > 2014-02-17 13:29 GMT+01:00 Miles Fidelman >: > > Jesper Louis Andersen wrote: > > > On Sun, Feb 16, 2014 at 10:11 PM, Miles Fidelman > > >> wrote: > > Good point. "Let it crash" does take on a whole different > meaning > when dealing with aircraft and such. > > > This is a different point as well! You have two axis: > > * soft vs hard realtime. Some systems require hard realtime > and then your tools are limited to languages where you have > explicit memory control, enabling you to avoid allocating > memory and triggering garbage collection. In soft realtime > systems, you have more leeway, and if built the way of the > Erlang runtime system, you get really good soft realtime > capability. > > * Proactive vs Reactive error handling. The idea of "let it > crash" is definitively reactive, whereas static type systems, > proofs, model checking, etc are means of proactive error handling. > > My claim however, is that you need "Let it crash" in Aircrafts > as well if you want to have a stable aircraft. The model where > you blindly attempt to eradicate every error from a program is > bound to fail sooner or later. Usually "let it crash" in those > situations is implemented in hardware by having multiple > redundant systems. But rarely are systems exempt of failure. > Even in a highly controlled environment. > > > We've really strayed off-topic here, but.... > > My all-time favorite design for seriously mission-critical systems > was the flight control system for the Space Shuttle. I'm not sure > this is true of the later versions, but originally: > - the flight control software ran on 5 parallel computers, that > voted on results > - 4 of the computers came from one contractor (hardware and software) > - the 5th machine, just ran mission-critical code, with a > completely separate design (both hardware and software) > - I don't remember how the tie-breaking algorithm worked > > Cheers, > > Miles > > > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From jon@REDACTED Mon Feb 17 13:46:34 2014 From: jon@REDACTED (Jon Schneider) Date: Mon, 17 Feb 2014 12:46:34 -0000 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <53018DE1.1090901@meetinghouse.net> References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <53018DE1.1090901@meetinghouse.net> Message-ID: <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> > Perl's CPAN repository really is the most amazing repository system I've > seen Amazing at what ? In my experience it asks lots of questions about what options you want for a package I never feel confident answering. Can I revisit my choices ? There seem to be gadzillions of packages to do things like parse a date or an HTTP response and packages to do some of these seem to depend on more complicated packages. It seems to keep wanting to update itself. "should be a seamless upgrade". Sometimes it is. Lots of tests seem to fail. Sometimes it knows they're supposed to fail and sometimes you're left scratching your head. Many roads lead to perl 6 being built. I've head the displeasure of CPAN going back to the mid 90s and it's still a steaming heap as far as I'm concerned. I'm glad I stopped writing more than the very occasional bit of perl a long time ago. Jon From rvirding@REDACTED Mon Feb 17 13:58:34 2014 From: rvirding@REDACTED (Robert Virding) Date: Mon, 17 Feb 2014 13:58:34 +0100 Subject: [erlang-questions] Fwd: Re: Generic server and selective receives In-Reply-To: References: Message-ID: This section in the erlang documentation gives some explanation and examples: http://www.erlang.org/doc/design_principles/spec_proc.html You do have to careful and follow the rules, but it is surprisingly simple. Note that this does not give you a behaviour "just" a process which fits into the OTP environment, for example it will work as it should in supervision trees. Robert On 17 February 2014 10:38, wrote: > > > Hi, > > Thank you for yours answers. With timer:no_diff/ is quite easy to handle > "selective timeout" in a gen server so okay it could be a decent solution. > The only problem is to have code to handle it in every callback that reset > the timeout, this is okay. But I would not use a gen_fsm, because if you > look at my first implementation, when there's no client the messages that > are NOT {set_client, ...} are not discarded, they are stacked in the > process mailbox for later use and this is expected. > > > > Le 2014-02-17 10:11, Anthony Ramine a ?crit : > > You don?t have to reimplement ?gen? to implement a sys process, no. >> > > > As i may need to implement several processes with this kind of "client > presence enforcement", implementing a sys process could be worth trying. > (Plus i'll learn a lot). Have you got any link to a good tutorial/guide ? > > Thanks > > -- lud > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sevenjp@REDACTED Mon Feb 17 14:01:24 2014 From: sevenjp@REDACTED (=?UTF-8?Q?Jo=C3=A3o_Neves?=) Date: Mon, 17 Feb 2014 14:01:24 +0100 Subject: [erlang-questions] let it crash erlang/ada [[was: Time for OTP to be Renamed?] In-Reply-To: <53020420.7030607@meetinghouse.net> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFEAC6.50308@gmail.com> <5300CF44.8050206@meetinghouse.net> <53012965.5030001@meetinghouse.net> <5302009E.2040507@meetinghouse.net> <53020420.7030607@meetinghouse.net> Message-ID: Of course. Sadly the article is very light in technical terms (I suppose the main audience is non-technical people), so I can't really tell if they're doing the whole shebang with separate hardware and software stacks. It incurs in extra cost and complexity per launch (you may not get the same bug on both systems but you're probably sure as hell to have different bugs), and maybe the benefits aren't that great compared to having one exhaustively tested, understood, software and hardware stack so the cost-benefit relation is just not worth it - especially since one of SpaceX's stated goals is to provide "cheap" access to space. -- Jo?o Neves 2014-02-17 13:44 GMT+01:00 Miles Fidelman : > Interesting. > > What I find particularly notable about the Space Shuttle design is the > notion of separate development of hardware and software - by different > teams at different vendors - as a fault checking mechanism. > > I guess the core mathematics has to be the same (e.g., ballistic > calculations), but beyond that, different code, running on different > hardware, but they have to get to the same results, or something is wrong. > > More copies of the same hardware/software just means more copies of any > bugs! > > Cheers, > > Miles > > > Jo?o Neves wrote: > >> SpaceX also does it and is a central part of their design: >> >> "Q: So, these flight computers on Dragon ? there are three on board, and >> that's for redundancy? >> >> A: There are actually six computers. They operate in pairs, so there are >> three computer units, each of which have two computers checking on each >> other. The reason we have three is when operating in proximity of ISS, we >> have to always have two computer strings voting on something on critical >> actions. We have three so we can tolerate a failure and still have two >> voting on each other. And that has nothing to do with radiation, that has >> to do with ensuring that we're safe when we're flying our vehicle in the >> proximity of the space station. >> >> I went into the lab earlier today, and we have 18 different processing >> units with computers in them. We have three main computers, but 18 units >> that have a computer of some kind, and all of them are triple computers ? >> everything is three processors. So we have like 54 processors on the >> spacecraft. It's a highly distributed design and very fault-tolerant and >> very robust." >> >> (http://www.aviationweek.com/Blogs.aspx?plckBlogId=Blog: >> 04ce340e-4b63-4d23-9695-d49ab661f385&plckPostId=Blog: >> 04ce340e-4b63-4d23-9695-d49ab661f385Post:a8b87703- >> 93f9-4cdf-885f-9429605e14df) >> >> >> -- >> Jo?o Neves >> >> >> 2014-02-17 13:29 GMT+01:00 Miles Fidelman > mfidelman@REDACTED>>: >> >> >> Jesper Louis Andersen wrote: >> >> >> On Sun, Feb 16, 2014 at 10:11 PM, Miles Fidelman >> > >> > >> >> wrote: >> >> Good point. "Let it crash" does take on a whole different >> meaning >> when dealing with aircraft and such. >> >> >> This is a different point as well! You have two axis: >> >> * soft vs hard realtime. Some systems require hard realtime >> and then your tools are limited to languages where you have >> explicit memory control, enabling you to avoid allocating >> memory and triggering garbage collection. In soft realtime >> systems, you have more leeway, and if built the way of the >> Erlang runtime system, you get really good soft realtime >> capability. >> >> * Proactive vs Reactive error handling. The idea of "let it >> crash" is definitively reactive, whereas static type systems, >> proofs, model checking, etc are means of proactive error handling. >> >> My claim however, is that you need "Let it crash" in Aircrafts >> as well if you want to have a stable aircraft. The model where >> you blindly attempt to eradicate every error from a program is >> bound to fail sooner or later. Usually "let it crash" in those >> situations is implemented in hardware by having multiple >> redundant systems. But rarely are systems exempt of failure. >> Even in a highly controlled environment. >> >> >> We've really strayed off-topic here, but.... >> >> My all-time favorite design for seriously mission-critical systems >> was the flight control system for the Space Shuttle. I'm not sure >> this is true of the later versions, but originally: >> - the flight control software ran on 5 parallel computers, that >> voted on results >> - 4 of the computers came from one contractor (hardware and software) >> - the 5th machine, just ran mission-critical code, with a >> completely separate design (both hardware and software) >> - I don't remember how the tie-breaking algorithm worked >> >> Cheers, >> >> Miles >> >> >> >> >> -- In theory, there is no difference between theory and practice. >> In practice, there is. .... Yogi Berra >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> > > -- > 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 lukas@REDACTED Mon Feb 17 14:03:00 2014 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 17 Feb 2014 14:03:00 +0100 Subject: [erlang-questions] R16B03-1 installation glitch In-Reply-To: <31322914-8CB6-43DE-A042-D6C477D2C787@cs.otago.ac.nz> References: <31322914-8CB6-43DE-A042-D6C477D2C787@cs.otago.ac.nz> Message-ID: Hello, On Mon, Feb 17, 2014 at 6:56 AM, Richard A. O'Keefe wrote: > > [Why does it prefer gcc to clang in this environment?] Last time I heard clang produced code for beam_emu.c that was about 10-20% slower than gcc. Also compiling complicated files (I'm looking at you again beam_emu.c) is much slower in clang. > > (A) Is there any environment in which gcc -g creates whatever.dSYM > and whatever.dSYM is _not_ a directory? > probably not. As far as I understand the error you see is something that autoconf generates. I did not get the error just now when building from git with autoconf 2.69 on OS X Mavericks, so it might be something that 2.59 generates. Don't have an answer regarding bullet B. Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: From karchie@REDACTED Mon Feb 17 14:08:14 2014 From: karchie@REDACTED (Kevin Archie) Date: Mon, 17 Feb 2014 07:08:14 -0600 Subject: [erlang-questions] erlang-questions Digest, Vol 153, Issue 2 In-Reply-To: References: Message-ID: On Feb 16, 2014, at 1:05 AM, Miles Fidelman wrote: > As to Go - it's a toy - Google or no Google, I don't see any systems > being built in it (the jury is still out on Clojure - another Google > project that has a clear rational and a lot more backing). Not to pick nits (he says before starting to pick nits), but: Docker (http://docker.io) is in Go. I've been hearing 10x more in the last year about this one Go system than all Erlang projects combined. Okay, buzz intensity doesn't necessarily translate into success, but it's a very interesting project that solves real problems for us, and from what I hear, a lot of other people. I don't see any reason why it couldn't have been written in Erlang, but there it is, in Go. Also, I'm not aware of any connection between Clojure and Google, other than that ClojureScript uses the Google Closure JS compiler as an intermediate stage. Clojure took off from the grassroots, without any big corporate backing, and most of the language development is still done by the BDFL and his smallish consulting firm. (I'm a big fan of Clojure, but I don't think Docker could have been written in it. JVM underneath makes your language not a systems programming language.) - Kevin From essen@REDACTED Mon Feb 17 14:40:45 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 17 Feb 2014 14:40:45 +0100 Subject: [erlang-questions] Preloaded modules "lists" dependency In-Reply-To: References: <52FDF77B.4070907@ninenines.eu> Message-ID: <5302115D.2060308@ninenines.eu> On 02/17/2014 11:58 AM, Lukas Larsson wrote: > So if you want to change the lists (or ets for that matter) module you > would have to create a solution for either in compile time removing those > bifs or possibly figuring it out in runtime. Why not have this information as an attribute of the module itself? > It should be possible to do in a separate fork of Erlang/OTP to start with > and if it proves to be generally useful I don't see why it wouldn't be > possible to bring it upstream. This is probably a bit too complicated for me right now, compared to just working around it, but if I ever want to dig deep into the VM I'll remember it. One question though. What happens if I define a function that is implemented as a BIF (that is, for example, create an Erlang version of lists:keymember/3 in the lists source code), is it replaced with the BIF on load? >> Any chance of having that dependency removed eventually? There are 13 >> occurrences of lists: in the preloaded modules. The functions used are >> keyreplace, member, reverse, foldl, foreach. The first 3 are BIFs, the >> other 2 aren't. Perhaps the first 3 could also be available from a >> prim_lists module and the other two inlined? This way the VM doesn't >> require any additional module to run, except of course error_logger but >> that's only a requirement when you want to extend the basic functionality. >> > > This is something that would be a lot easier to do and less complicated to > make it into upstream. As long as there are tests that make sure nothing is > broken over time. Gotcha. Sounds like a good plan for a future week-end. -- Lo?c Hoguin http://ninenines.eu From sverker.eriksson@REDACTED Mon Feb 17 14:56:30 2014 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Mon, 17 Feb 2014 14:56:30 +0100 Subject: [erlang-questions] Sharing resource types between NIFs In-Reply-To: <52FFE8AD.2030507@ninenines.eu> References: <52FFE8AD.2030507@ninenines.eu> Message-ID: <5302150E.7040405@erix.ericsson.se> Having dependences between NIF modules (or drivers) on the native code level is not supported. How symbols are resolved (or not) between dynamic libraries is OS dependent (Windows). The runtime system can not keep track of such dependencies. For example, if module B makes a native call to a function in module A and module A has been unloaded...VM crash (or worse). I suggest you merge your dependent NIF code into one module. You can still have different modules on Erlang level and have them call a backend NIF module. That being said... ... the scenario you describe should work in current implementation. enif_get_resource() does not care where it is called from. /Sverker, Erlang/OTP On 02/15/2014 11:22 PM, Lo?c Hoguin wrote: > Hello, > > I have been looking into this and after looking into the source it > doesn't seem possible, but I might as well ask just in case. > > Say I am writing bindings for a big library. That library is cut into > various components, and I would like to do similar on the Erlang side. > Components are more or less dependent. Let's just say that component B > uses component A. You can't do anything in B without A. They are both > NIF resources pointing to things used by the library. > > Now if I try to create a NIF module for A and a NIF module for B, I > need to access the resource type of A from the B NIF. I tried simply > exporting a function from the A .so and use it from the B .so, the > function returns the resource type as expected, however using it to > retrieve the resource fails. > > Trying to do the same from A of course works. It's just trying to use > the resource type of A from B that fails. > > I'm assuming this isn't possible? > > Thanks. > From daniel.goertzen@REDACTED Mon Feb 17 15:07:52 2014 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Mon, 17 Feb 2014 08:07:52 -0600 Subject: [erlang-questions] Generic server and selective receives In-Reply-To: <01ea44277e59d63ec6d4975c9499d738@demblans.com> References: <01ea44277e59d63ec6d4975c9499d738@demblans.com> Message-ID: Take a look at plain_fsm: https://github.com/uwiger/plain_fsm/blob/master/doc/plain_fsm.md Dan. On Sun, Feb 16, 2014 at 5:55 PM, wrote: > Hi, > > I would like some help to implement a message-buffer in erlang. This > process can be sent messages, and stores them in mailbox. A buffer can > have one client, or can have no client. When there's no client, I > would prevent the process to do anything but accept a new client or > timeout after a small amount of time. So I have two sets of receive > clauses. > > Now, I would like to implement this as a gen_server. But I don't know > how. The Idea is to timeout quickly if no message of the expected > clauses-set comes. > > * I thought of a gen_fsm but it will crash if it's sent a message when > in the "no client" state, right ? (Plus i may want to handle more > receive clauses in the "no client" part) > * I thougt about time calculations but it's seems too complicated for > no reason ; I prefer use the simple gen_* timeouts. > * I could keep my current implementation and adapt the module to fit > in a supervision tree but I believe I willll miss common OTP features. > > So, I hope this is a common pattern and that someone will tell me a > good solution. > > Thank you. > > -- lud > > This is my current implementation (but not the actual code). > > loop(#state{client_pid=undefined}) -> > receive > {set_client,Pid} -> > loop(State#state{client_pid=Pid}) > after 10000 -> > io:fwrite("Terminating\n") > end; > > loop(State=#state{client_pid=Client,mailbox=Mailbox}) -> > receive > {set_client,Pid} -> > %% here we can change the client or set it to undefined > loop(State#state{client_pid=Pid}); > {message,M} -> > Client ! you_have_messages, > loop(State#state{mailbox=[M|Mailbox]}); > %% A handful of other clauses > ... > ... > ... > after way more time than 1000 -> > io:fwrite("Terminating too\n") > end; > > > Now i'll pray for this mail to be seen in the current huge amount of > emails (and very intersting by the way) on the list. > > _______________________________________________ > 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 Mon Feb 17 15:14:31 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 17 Feb 2014 15:14:31 +0100 Subject: [erlang-questions] Preloaded modules "lists" dependency In-Reply-To: References: <52FDF77B.4070907@ninenines.eu> Message-ID: <53021947.4070500@ninenines.eu> Thoughts and ideas are not worth a lot until they are tested so I will spare you most details for now. It's still a pretty long read. For the "Erlang2" part, there isn't much to say. Erlang is a language that is almost perfect. My conclusions about improving it are that there are very few things that can be improved, and they are mostly edge cases (shadowing would be a big one, and not being able to do (<< B:Len/binary, _/bits >>, Len) in a function clause would be another - but the latter is going to be solved soon as I gather). The rest of it, well, I came pretty much to the same conclusions as Joe, the only thing I would add is a basic form of metaprogramming. Basically you want to be able to do two things: compute some data at compile time, and run tests at compile time (and fail to compile if the tests fail). Optionally would allow you to do some conditional builds to work around issues with a specific version of Erlang. But no macros or other weird stuff that just make the code more complex for no good reasons. I'm no language expert and I'm not too interested in this part so don't expect anything from me on that point. If I ever attempt something it would just be a very basic wrapper on top of the current Erlang syntax to allow for compile-time stuff to happen (meaning: outside functions, and perhaps even outside modules entirely). The "OTP2" part interests me a lot more. One of my favorite ideas is to be able to define the whole supervision tree in a single module, and to have it feature more complex components like pools for example. It could come with a default pool implementation, with a well defined interface (from the point of view of the supervision tree) that allows it to be replaced with whichever one you want. So instead of having 10 modules describing your application, it could all be in a very visual format in a single module. I'm more interested in doing an "OTP2" that targets a different use than long running server applications though. As you might already know, I like video games, and I have tried a few quick prototypes of games with Erlang. I think there is a lot of potential, but the barrier of entry is very high. An "OTP2" geared toward games would help greatly. Games typically have a main loop. There's basically no way around that today because most graphic APIs aren't thread safe. SDL2 was released not too long ago for example, and it still isn't thread safe. But that's not a big problem, Erlang's concurrency can still play a big part. For example, by making the lists module parallelize processing of the list automatically past a certain threshold. Or providing efficient timer capabilities (because the timer module ain't it). And the processes that access the API can always be tied to scheduler 0 to avoid any issues. I started playing around making an SDL2 NIF this week-end. The first thing you instantly win is not having to worry about freeing resources (with a few gotchas of course, you can only have so much in memory). The GC does it for you! The second thing you instantly win is Erlang's pattern matching. The article I wrote about matching tic tac toe solutions directly instead of trying to write an algorithm is a good example of that. The code becomes small and clear and you can focus on actually building the game. Of course, for anything to come out of these experiments, I have to find a way to not get bored, which may prove difficult. Time will tell. On 02/17/2014 01:30 PM, Pierre Fenoll wrote: > Hey Lo?c, > > I don't mean to hijack the thread. > Can we have more information on "Erlang2/OTP2"? Your guidelines and > back-of-a-napkin experiments interest me greatly. > > > Cheers, > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From cian@REDACTED Mon Feb 17 15:16:52 2014 From: cian@REDACTED (Cian Synnott) Date: Mon, 17 Feb 2014 14:16:52 +0000 Subject: [erlang-questions] let it crash erlang/ada [[was: Time for OTP to be Renamed?] In-Reply-To: <53020420.7030607@meetinghouse.net> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFEAC6.50308@gmail.com> <5300CF44.8050206@meetinghouse.net> <53012965.5030001@meetinghouse.net> <5302009E.2040507@meetinghouse.net> <53020420.7030607@meetinghouse.net> Message-ID: On Mon, Feb 17, 2014 at 12:44 PM, Miles Fidelman wrote: > More copies of the same hardware/software just means more copies of any > bugs! > A famous direct example of this was the Ariane 5 disaster in 1996: "When the guidance system shut down, it passed control to an identical, redundant unit, which was there to provide backup in case of just such a failure. But the second unit had failed in the identical manner a few milliseconds before. And why not? It was running the same software." http://www.around.com/ariane.html Cian From essen@REDACTED Mon Feb 17 15:19:46 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 17 Feb 2014 15:19:46 +0100 Subject: [erlang-questions] Sharing resource types between NIFs In-Reply-To: <5302150E.7040405@erix.ericsson.se> References: <52FFE8AD.2030507@ninenines.eu> <5302150E.7040405@erix.ericsson.se> Message-ID: <53021A82.5030802@ninenines.eu> On 02/17/2014 02:56 PM, Sverker Eriksson wrote: > Having dependences between NIF modules (or drivers) on the native code > level is not supported. > How symbols are resolved (or not) between dynamic libraries is OS > dependent (Windows). > The runtime system can not keep track of such dependencies. For example, > if module B makes a native call to a function in module A and module A > has been unloaded...VM crash (or worse). > > I suggest you merge your dependent NIF code into one module. You can > still have different modules on Erlang level and have them call a > backend NIF module. Thanks, that's exactly what I ended up doing. > That being said... ... the scenario you describe should work in current > implementation. enif_get_resource() does not care where it is called from. Well it didn't work. :-) > /Sverker, Erlang/OTP > > > > > On 02/15/2014 11:22 PM, Lo?c Hoguin wrote: >> Hello, >> >> I have been looking into this and after looking into the source it >> doesn't seem possible, but I might as well ask just in case. >> >> Say I am writing bindings for a big library. That library is cut into >> various components, and I would like to do similar on the Erlang side. >> Components are more or less dependent. Let's just say that component B >> uses component A. You can't do anything in B without A. They are both >> NIF resources pointing to things used by the library. >> >> Now if I try to create a NIF module for A and a NIF module for B, I >> need to access the resource type of A from the B NIF. I tried simply >> exporting a function from the A .so and use it from the B .so, the >> function returns the resource type as expected, however using it to >> retrieve the resource fails. >> >> Trying to do the same from A of course works. It's just trying to use >> the resource type of A from B that fails. >> >> I'm assuming this isn't possible? >> >> Thanks. >> > > -- Lo?c Hoguin http://ninenines.eu From mfidelman@REDACTED Mon Feb 17 15:20:52 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 17 Feb 2014 09:20:52 -0500 Subject: [erlang-questions] "actor database" - architectural strategy question Message-ID: <53021AC4.8080303@meetinghouse.net> [Enough with the threads on Erlang angst for a while - time for some real questions :-) ] BACKGROUND: A lot of what I do is systems engineering, and a lot of that ends up in the realm of technology assessment - picking the right platform and tools for a particular system. My dablings in Erlang are largely in that category - I keep seeing it as potentially useful for a class of systems, keep experimenting with it, done a couple proof-of-concept efforts, but haven't built an operational system at scale with it (yet). The focus, so far, has been in modeling and simulation (I first discovered Erlang when chasing R&D contracts for a firm that built simulation engines for military trainers. I was flabbergasted to discover that everything was written in C++, every simulated entity was an object, with 4 main loops threading through every object, 20 times a second. Talk about spaghetti code. Coming from a data comm. protocol/network background - where we'd spawn a process for everything - I asked the obvious question, and was told that context switches would bring a 10,000 entity simulation to its knees. My instinctual response was "bullshit" - and went digging into the technology for massive concurrency, and discovered Erlang.) Anyway.... For years, I've been finding myself in situations, and on projects, that have a common characteristic of linked documents that change a lot - in the general arena of planning and workflow. Lots of people, each editing different parts of different documents - with changes rippling through the collection. Think linked spreadsheets, tiered project plans, multi-level engineering documents with lots of inter-dependencies. To be more concrete: systems engineering documents, large proposals, business planning systems, command and control systems. Add in requirements for disconnected operation that lead to distribution/replication requirements rather than keeping single, central copies of things (as the librarians like to say, "Lots of Copies Keeps Stuff Safe"). So far we've always taken conventional approaches - ranging from manual paper shuffling and xeroxing, to file servers with manual organization, to some of MS Office's document linking capabilities, to document databases and sharepoint. And played with some XML database technologies. But.... I keep thinking that there are a set of underlying functions that beg for better tools - something like a distributed CVS that's optimized for planning documents rather than software (or perhaps something like a modernized Lotus Notes). And I keep thinking that the obvious architectural model is to treat each document (maybe each page) as an actor ("smart documents" if you will), with communication through publish-subscribe mechanisms. Interact with a (copy of) a document, changes get pushed to groups of documents via a pub-sub mechanism. (Not unlike actor based simulation approaches.) And, of course, when I think actors, I think Erlang. The obvious conceptualization is "every document is an actor." At which point an obvious question comes up: How to handle long-term persistence, for large numbers of inactive entities. But... when I go looking for examples of systems that might be built this way, I keep finding that, even in Erlang-based systems, persistence is handled in fairly conventional ways: - One might think that CouchDB treats every document as an actor, but think again - Paulo Negri has given some great presentations on how Wooga implements large-scale social gaming - and they implement an actor per session - but when a user goes off-line they push state into a more conventional database (then initialize a gen_server from the database, when the user comes back online) At which point the phrase "actor-oriented database" keeps coming back to mind, with the obvious analogy to "object-oriented databases." I.e., something with the persistence and other characteristics of a database, where the contents are actors - with all the characteristics and functionality of those actors preserved while stored in the database. ON TO THE QUESTIONS: I have a pretty good understanding of how one would build things like simulations, or protocol servers, with Erlang - not so much how one might build something with long-term persistence - which leads to some questions (some, probably naive): 1. So far, I haven't seen anything that actually looks like an "actor-oriented database." Document databases implemented in Erlang, yes (e.g., CouchDB), but every example I find ultimately pushes persistent data into files or a more conventional database of some sort. Can anybody point to an example of something that looks more like "storing actors in a database?" - It strikes me that the core issues with doing so have to do with maintaining "aliveness" - i.e., dealing with addressability, routing messages to a stored actor, waking up after a timeout (i.e., the equivalent of triggers) 2. One obvious (if simplistic) thought: Does one really need to think in terms of a "database" at all - or might this problem be approached simply by creating each document as an Erlang process, and keeping it around forever? Most of what I've seen built in Erlang focuses on relatively short-lived actors - I'd be really interested in comments on: - limitations/issues in persisting 100s of 1000s, or maybe millions of actors, for extended periods of time (years, or decades) - are there any tools/models for migrating (swapping?) inactive processes dynamically to/from disk storage 3. What about backup for the state of a process? 'Let it crash' is great for servers supporting a reliable protocol, not so great for an actor that has internal state that has to be preserved (like a simulated tank, or a "smart document"). Pushing into a database is obvious, but... - are there any good models for saving/restoring state within a tree of supervised processes? - what about models for synchronizing state across replicated copies of processes running on different nodes? - what about backup/restore of entire Erlang VMs (including anything that might be swapped out onto disk) 4. For communications between/among actors: Erlang is obviously excellent for writing pub-sub engines (RabbitMQ and ejabberd come to mind), but what about pub-sub or multicast/broadcast models or messaging between Erlang processes? Are there any good libraries for defining/managing process groups, and doing multicast or broadcast messaging to/among a group of processes. Thank you very much for any pointers or thoughts. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From lukas@REDACTED Mon Feb 17 15:25:08 2014 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 17 Feb 2014 15:25:08 +0100 Subject: [erlang-questions] Preloaded modules "lists" dependency In-Reply-To: <5302115D.2060308@ninenines.eu> References: <52FDF77B.4070907@ninenines.eu> <5302115D.2060308@ninenines.eu> Message-ID: On Mon, Feb 17, 2014 at 2:40 PM, Lo?c Hoguin wrote: > On 02/17/2014 11:58 AM, Lukas Larsson wrote: > >> So if you want to change the lists (or ets for that matter) module you >> would have to create a solution for either in compile time removing those >> bifs or possibly figuring it out in runtime. >> > > Why not have this information as an attribute of the module itself? Don't know, probably was easier/quicker to do in the original implementation when there was no though of running Erlang without stdlib. On Mon, Feb 17, 2014 at 2:40 PM, Lo?c Hoguin wrote: > One question though. What happens if I define a function that is > implemented as a BIF (that is, for example, create an Erlang version of > lists:keymember/3 in the lists source code), is it replaced with the BIF on > load? > I would imagine it would behave as a nif, i.e. be replaced. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Mon Feb 17 15:33:03 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 17 Feb 2014 09:33:03 -0500 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <53018DE1.1090901@meetinghouse.net> <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> Message-ID: <53021D9F.7060605@meetinghouse.net> Jon Schneider wrote: >> Perl's CPAN repository really is the most amazing repository system I've >> seen > Amazing at what ? > > In my experience it asks lots of questions about what options you want for > a package I never feel confident answering. Can I revisit my choices ? > > There seem to be gadzillions of packages to do things like parse a date or > an HTTP response and packages to do some of these seem to depend on more > complicated packages. > > It seems to keep wanting to update itself. "should be a seamless upgrade". > Sometimes it is. > > Lots of tests seem to fail. Sometimes it knows they're supposed to fail > and sometimes you're left scratching your head. > > Many roads lead to perl 6 being built. > > I've head the displeasure of CPAN going back to the mid 90s and it's still > a steaming heap as far as I'm concerned. I'm glad I stopped writing more > than the very occasional bit of perl a long time ago. > My experience has been a bit different - though, admittedly I haven't built anything in Perl for maybe 10 years. (Mostly because I don't do a lot of website development these days, and when I do, PHP is a far cleaner language.) But, during a period when I was building a bunch of web sites, I was continuously amazed by how easy it was to: - find a perl module to do a particular job - type 1 instruction - watch everything get built, tested, and loaded, with all dependencies resolved (and automatically running regression tests is a really nice feature) - yes, sometimes it took a while, and sometimes things failed, but mostly things just worked These days, my main use comes from periodic upgrades to Sympa (really top-notch mailing list manager maintained by a consortium of French universities). It's all built in perl, and it uses cpan to update all its dependencies. (When things fail, it's usually Sympa's updater that fails - at which point I use cpan to install/update all the required modules and then things generally just work.) The only other thing I've found that comes close is "apt-get install foo" from a Debian package repository (or "apt-get update; apt-get upgrade"). Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From g@REDACTED Mon Feb 17 15:50:18 2014 From: g@REDACTED (Garrett Smith) Date: Mon, 17 Feb 2014 08:50:18 -0600 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <53021D9F.7060605@meetinghouse.net> References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <53018DE1.1090901@meetinghouse.net> <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> <53021D9F.7060605@meetinghouse.net> Message-ID: On Mon, Feb 17, 2014 at 8:33 AM, Miles Fidelman wrote: > Jon Schneider wrote: >>> >>> Perl's CPAN repository really is the most amazing repository system I've >>> seen >> >> Amazing at what ? >> >> In my experience it asks lots of questions about what options you want for >> a package I never feel confident answering. Can I revisit my choices ? >> >> There seem to be gadzillions of packages to do things like parse a date or >> an HTTP response and packages to do some of these seem to depend on more >> complicated packages. >> >> It seems to keep wanting to update itself. "should be a seamless upgrade". >> Sometimes it is. >> >> Lots of tests seem to fail. Sometimes it knows they're supposed to fail >> and sometimes you're left scratching your head. >> >> Many roads lead to perl 6 being built. >> >> I've head the displeasure of CPAN going back to the mid 90s and it's still >> a steaming heap as far as I'm concerned. I'm glad I stopped writing more >> than the very occasional bit of perl a long time ago. >> > My experience has been a bit different - though, admittedly I haven't built > anything in Perl for maybe 10 years. (Mostly because I don't do a lot of > website development these days, and when I do, PHP is a far cleaner > language.) > > But, during a period when I was building a bunch of web sites, I was > continuously amazed by how easy it was to: > - find a perl module to do a particular job > - type 1 instruction > - watch everything get built, tested, and loaded, with all dependencies > resolved (and automatically running regression tests is a really nice > feature) > - yes, sometimes it took a while, and sometimes things failed, but mostly > things just worked > > These days, my main use comes from periodic upgrades to Sympa (really > top-notch mailing list manager maintained by a consortium of French > universities). It's all built in perl, and it uses cpan to update all its > dependencies. (When things fail, it's usually Sympa's updater that fails - > at which point I use cpan to install/update all the required modules and > then things generally just work.) > > The only other thing I've found that comes close is "apt-get install foo" > from a Debian package repository (or "apt-get update; apt-get upgrade"). The use of github as a repository for Erlang libraries was never planned, but as I use it, I think I actually prefer it. It's very hard to manage packages. Very, very hard. Even with mature ecosystems like dpkg, rpm, pacman, where the tools have been mature for years now, there's a near constant battle against staleness and version incompatibility. This is compounded when you layer system independent packaging systems, e.g. PyPi, Ruby gems, CPAN, etc. Even with Erlang core itself, how many problems have been caused by package quirks on a particular OS? (E.g. Ubuntu Erlang has historically been notoriously unhealthy - I don't know if it's changed, but I always compile from source at this point.) Grabbing required source into a single directory and compiling everything, independent of shared system code, is, in my experience, much more reliable. And having six projects in github for a given domain (e.g. ZeroMQ) is hardly a misfeature IMO. As Joe pointed out, the multiple projects encourage independent evolution based on environmental pressure (programmer requirements) and, if it makes sense, can be be merged into a consolidated source (e.g. see the heroic efforts Jesper to merge the various MySQL driver branches). I think I'm going to call this a feature, not a bug. Garrett From jesper.louis.andersen@REDACTED Mon Feb 17 15:50:31 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 17 Feb 2014 15:50:31 +0100 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: <53021AC4.8080303@meetinghouse.net> References: <53021AC4.8080303@meetinghouse.net> Message-ID: A document is a trace of events. These events records edits to the document and when we play all of the events, we obtain the final document state. Infinite undo is possible by looking back and replaying with a point-in-time recovery option. An actor is a handler that can apply events to a state in order to obtain a new state. Events are persisted in an event log and WAL fashion. So even if the system dies, we can replay its state safely. Once in a while, living processes checkpoint their state to disk so they can boot up faster than having to replay from day 0. Multiple edits to the same document can be handled by operational transforms http://en.wikipedia.org/wiki/Operational_transformation Idle documents terminate themselves after a while by checkpointing themselves to disk. Documents register themselves into gproc and if there is no document present in gproc, you go to a manager and get it set up either from disk or by forming a new document. For easy storage, you can use a single table in a database for the log. On Mon, Feb 17, 2014 at 3:20 PM, Miles Fidelman wrote: > [Enough with the threads on Erlang angst for a while - time for some real > questions :-) ] > > BACKGROUND: > A lot of what I do is systems engineering, and a lot of that ends up in > the realm of technology assessment - picking the right platform and tools > for a particular system. My dablings in Erlang are largely in that > category - I keep seeing it as potentially useful for a class of systems, > keep experimenting with it, done a couple proof-of-concept efforts, but > haven't built an operational system at scale with it (yet). The focus, so > far, has been in modeling and simulation (I first discovered Erlang when > chasing R&D contracts for a firm that built simulation engines for military > trainers. I was flabbergasted to discover that everything was written in > C++, every simulated entity was an object, with 4 main loops threading > through every object, 20 times a second. Talk about spaghetti code. > Coming from a data comm. protocol/network background - where we'd spawn a > process for everything - I asked the obvious question, and was told that > context switches would bring a 10,000 entity simulation to its knees. My > instinctual response was "bullshit" - and went digging into the technology > for massive concurrency, and discovered Erlang.) > > Anyway.... For years, I've been finding myself in situations, and on > projects, that have a common characteristic of linked documents that change > a lot - in the general arena of planning and workflow. Lots of people, each > editing different parts of different documents - with changes rippling > through the collection. Think linked spreadsheets, tiered project plans, > multi-level engineering documents with lots of inter-dependencies. To be > more concrete: systems engineering documents, large proposals, business > planning systems, command and control systems. > > Add in requirements for disconnected operation that lead to > distribution/replication requirements rather than keeping single, central > copies of things (as the librarians like to say, "Lots of Copies Keeps > Stuff Safe"). > > So far we've always taken conventional approaches - ranging from manual > paper shuffling and xeroxing, to file servers with manual organization, to > some of MS Office's document linking capabilities, to document databases > and sharepoint. And played with some XML database technologies. > > But.... I keep thinking that there are a set of underlying functions that > beg for better tools - something like a distributed CVS that's optimized > for planning documents rather than software (or perhaps something like a > modernized Lotus Notes). > > And I keep thinking that the obvious architectural model is to treat each > document (maybe each page) as an actor ("smart documents" if you will), > with communication through publish-subscribe mechanisms. Interact with a > (copy of) a document, changes get pushed to groups of documents via a > pub-sub mechanism. (Not unlike actor based simulation approaches.) > > And, of course, when I think actors, I think Erlang. The obvious > conceptualization is "every document is an actor." > > At which point an obvious question comes up: How to handle long-term > persistence, for large numbers of inactive entities. > > But... when I go looking for examples of systems that might be built this > way, I keep finding that, even in Erlang-based systems, persistence is > handled in fairly conventional ways: > - One might think that CouchDB treats every document as an actor, but > think again > - Paulo Negri has given some great presentations on how Wooga implements > large-scale social gaming - and they implement an actor per session - but > when a user goes off-line they push state into a more conventional database > (then initialize a gen_server from the database, when the user comes back > online) > > At which point the phrase "actor-oriented database" keeps coming back to > mind, with the obvious analogy to "object-oriented databases." I.e., > something with the persistence and other characteristics of a database, > where the contents are actors - with all the characteristics and > functionality of those actors preserved while stored in the database. > > ON TO THE QUESTIONS: > I have a pretty good understanding of how one would build things like > simulations, or protocol servers, with Erlang - not so much how one might > build something with long-term persistence - which leads to some questions > (some, probably naive): > > 1. So far, I haven't seen anything that actually looks like an > "actor-oriented database." Document databases implemented in Erlang, yes > (e.g., CouchDB), but every example I find ultimately pushes persistent data > into files or a more conventional database of some sort. Can anybody point > to an example of something that looks more like "storing actors in a > database?" > - It strikes me that the core issues with doing so have to do with > maintaining "aliveness" - i.e., dealing with addressability, routing > messages to a stored actor, waking up after a timeout (i.e., the equivalent > of triggers) > > 2. One obvious (if simplistic) thought: Does one really need to think in > terms of a "database" at all - or might this problem be approached simply > by creating each document as an Erlang process, and keeping it around > forever? Most of what I've seen built in Erlang focuses on relatively > short-lived actors - I'd be really interested in comments on: > - limitations/issues in persisting 100s of 1000s, or maybe millions of > actors, for extended periods of time (years, or decades) > - are there any tools/models for migrating (swapping?) inactive processes > dynamically to/from disk storage > > 3. What about backup for the state of a process? 'Let it crash' is great > for servers supporting a reliable protocol, not so great for an actor that > has internal state that has to be preserved (like a simulated tank, or a > "smart document"). Pushing into a database is obvious, but... > - are there any good models for saving/restoring state within a tree of > supervised processes? > - what about models for synchronizing state across replicated copies of > processes running on different nodes? > - what about backup/restore of entire Erlang VMs (including anything that > might be swapped out onto disk) > > 4. For communications between/among actors: Erlang is obviously excellent > for writing pub-sub engines (RabbitMQ and ejabberd come to mind), but what > about pub-sub or multicast/broadcast models or messaging between Erlang > processes? Are there any good libraries for defining/managing process > groups, and doing multicast or broadcast messaging to/among a group of > processes. > > Thank you very much for any pointers or thoughts. > > 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 > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.irvine@REDACTED Mon Feb 17 15:59:07 2014 From: chuck.irvine@REDACTED (Charles Irvine) Date: Mon, 17 Feb 2014 08:59:07 -0600 Subject: [erlang-questions] noSQL DB driver / Maps Message-ID: It?s great to finally have access to the Maps data structure. I?ve been impatiently waiting since reading about them in Joe?s new book. Does anyone have any recommendations on the best noSQL database with conversion from JSON to Erlang Maps and vice versa? Thanks! From ali.sabil@REDACTED Mon Feb 17 16:16:35 2014 From: ali.sabil@REDACTED (Ali Sabil) Date: Mon, 17 Feb 2014 16:16:35 +0100 Subject: [erlang-questions] Preloaded modules "lists" dependency In-Reply-To: <53021947.4070500@ninenines.eu> References: <52FDF77B.4070907@ninenines.eu> <53021947.4070500@ninenines.eu> Message-ID: On Mon, Feb 17, 2014 at 3:14 PM, Lo?c Hoguin wrote: > Thoughts and ideas are not worth a lot until they are tested so I will > spare you most details for now. It's still a pretty long read. > > For the "Erlang2" part, there isn't much to say. Erlang is a language that > is almost perfect. My conclusions about improving it are that there are > very few things that can be improved, and they are mostly edge cases > (shadowing would be a big one, and not being able to do (<< B:Len/binary, > _/bits >>, Len) in a function clause would be another - but the latter is > going to be solved soon as I gather). The rest of it, well, I came pretty > much to the same conclusions as Joe, the only thing I would add is a basic > form of metaprogramming. Basically you want to be able to do two things: > compute some data at compile time, and run tests at compile time (and fail > to compile if the tests fail). Optionally would allow you to do some > conditional builds to work around issues with a specific version of Erlang. > But no macros or other weird stuff that just make the code more complex for > no good reasons. > > I'm no language expert and I'm not too interested in this part so don't > expect anything from me on that point. If I ever attempt something it would > just be a very basic wrapper on top of the current Erlang syntax to allow > for compile-time stuff to happen (meaning: outside functions, and perhaps > even outside modules entirely). > > The "OTP2" part interests me a lot more. One of my favorite ideas is to be > able to define the whole supervision tree in a single module, and to have > it feature more complex components like pools for example. It could come > with a default pool implementation, with a well defined interface (from the > point of view of the supervision tree) that allows it to be replaced with > whichever one you want. So instead of having 10 modules describing your > application, it could all be in a very visual format in a single module. > It's already possible as of today. Just pattern match on the init/1 arguments in the supervisor callback module: start_link() -> supervisor:start_link({local, ?MODULE}, ?MODULE, app). init(app) -> {ok, { {one_for_all, 5, 10}, [ {workers_sup, {supervisor, start_link, [?MODULE, workers_sup]}, permanent, infinity, supervisor, [?MODULE]} ] }}; init(workers_sup) -> {ok, { {simple_one_for_one, 5, 10}, [ {worker, {worker, start_link, []}, temporary, 5000, worker, [worker]} ] }}. > I'm more interested in doing an "OTP2" that targets a different use than > long running server applications though. As you might already know, I like > video games, and I have tried a few quick prototypes of games with Erlang. > I think there is a lot of potential, but the barrier of entry is very high. > An "OTP2" geared toward games would help greatly. Games typically have a > main loop. There's basically no way around that today because most graphic > APIs aren't thread safe. SDL2 was released not too long ago for example, > and it still isn't thread safe. But that's not a big problem, Erlang's > concurrency can still play a big part. For example, by making the lists > module parallelize processing of the list automatically past a certain > threshold. Or providing efficient timer capabilities (because the timer > module ain't it). And the processes that access the API can always be tied > to scheduler 0 to avoid any issues. > > I started playing around making an SDL2 NIF this week-end. The first thing > you instantly win is not having to worry about freeing resources (with a > few gotchas of course, you can only have so much in memory). The GC does it > for you! The second thing you instantly win is Erlang's pattern matching. > The article I wrote about matching tic tac toe solutions directly instead > of trying to write an algorithm is a good example of that. The code becomes > small and clear and you can focus on actually building the game. > > Of course, for anything to come out of these experiments, I have to find a > way to not get bored, which may prove difficult. Time will tell. > > > On 02/17/2014 01:30 PM, Pierre Fenoll wrote: > >> Hey Lo?c, >> >> I don't mean to hijack the thread. >> Can we have more information on "Erlang2/OTP2"? Your guidelines and >> back-of-a-napkin experiments interest me greatly. >> >> >> Cheers, >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Mon Feb 17 16:30:56 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 17 Feb 2014 16:30:56 +0100 Subject: [erlang-questions] Preloaded modules "lists" dependency In-Reply-To: References: <52FDF77B.4070907@ninenines.eu> <53021947.4070500@ninenines.eu> Message-ID: <53022B30.9030206@ninenines.eu> On 02/17/2014 04:16 PM, Ali Sabil wrote: > On Mon, Feb 17, 2014 at 3:14 PM, Lo?c Hoguin wrote: > >> Thoughts and ideas are not worth a lot until they are tested so I will >> spare you most details for now. It's still a pretty long read. >> >> For the "Erlang2" part, there isn't much to say. Erlang is a language that >> is almost perfect. My conclusions about improving it are that there are >> very few things that can be improved, and they are mostly edge cases >> (shadowing would be a big one, and not being able to do (<< B:Len/binary, >> _/bits >>, Len) in a function clause would be another - but the latter is >> going to be solved soon as I gather). The rest of it, well, I came pretty >> much to the same conclusions as Joe, the only thing I would add is a basic >> form of metaprogramming. Basically you want to be able to do two things: >> compute some data at compile time, and run tests at compile time (and fail >> to compile if the tests fail). Optionally would allow you to do some >> conditional builds to work around issues with a specific version of Erlang. >> But no macros or other weird stuff that just make the code more complex for >> no good reasons. >> >> I'm no language expert and I'm not too interested in this part so don't >> expect anything from me on that point. If I ever attempt something it would >> just be a very basic wrapper on top of the current Erlang syntax to allow >> for compile-time stuff to happen (meaning: outside functions, and perhaps >> even outside modules entirely). >> >> The "OTP2" part interests me a lot more. One of my favorite ideas is to be >> able to define the whole supervision tree in a single module, and to have >> it feature more complex components like pools for example. It could come >> with a default pool implementation, with a well defined interface (from the >> point of view of the supervision tree) that allows it to be replaced with >> whichever one you want. So instead of having 10 modules describing your >> application, it could all be in a very visual format in a single module. >> > > It's already possible as of today. Just pattern match on the init/1 > arguments in the supervisor callback module: > > start_link() -> > supervisor:start_link({local, ?MODULE}, ?MODULE, app). > > init(app) -> > {ok, { > {one_for_all, 5, 10}, [ > {workers_sup, {supervisor, start_link, [?MODULE, workers_sup]}, permanent, > infinity, supervisor, [?MODULE]} > ] > }}; > init(workers_sup) -> > {ok, { > {simple_one_for_one, 5, 10}, [ > {worker, {worker, start_link, []}, temporary, 5000, worker, [worker]} > ] > }}. You missed the "very visual format" part. Basically when I create an application I want to write the tree in that module. In the format of a tree. Indentation makes seeing how the processes relate to each other. Things like that. >> I'm more interested in doing an "OTP2" that targets a different use than >> long running server applications though. As you might already know, I like >> video games, and I have tried a few quick prototypes of games with Erlang. >> I think there is a lot of potential, but the barrier of entry is very high. >> An "OTP2" geared toward games would help greatly. Games typically have a >> main loop. There's basically no way around that today because most graphic >> APIs aren't thread safe. SDL2 was released not too long ago for example, >> and it still isn't thread safe. But that's not a big problem, Erlang's >> concurrency can still play a big part. For example, by making the lists >> module parallelize processing of the list automatically past a certain >> threshold. Or providing efficient timer capabilities (because the timer >> module ain't it). And the processes that access the API can always be tied >> to scheduler 0 to avoid any issues. >> >> I started playing around making an SDL2 NIF this week-end. The first thing >> you instantly win is not having to worry about freeing resources (with a >> few gotchas of course, you can only have so much in memory). The GC does it >> for you! The second thing you instantly win is Erlang's pattern matching. >> The article I wrote about matching tic tac toe solutions directly instead >> of trying to write an algorithm is a good example of that. The code becomes >> small and clear and you can focus on actually building the game. >> >> Of course, for anything to come out of these experiments, I have to find a >> way to not get bored, which may prove difficult. Time will tell. >> >> >> On 02/17/2014 01:30 PM, Pierre Fenoll wrote: >> >>> Hey Lo?c, >>> >>> I don't mean to hijack the thread. >>> Can we have more information on "Erlang2/OTP2"? Your guidelines and >>> back-of-a-napkin experiments interest me greatly. >>> >>> >>> Cheers, >>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> -- >> Lo?c Hoguin >> http://ninenines.eu >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -- Lo?c Hoguin http://ninenines.eu From mallen@REDACTED Mon Feb 17 16:46:52 2014 From: mallen@REDACTED (Mark Allen) Date: Mon, 17 Feb 2014 09:46:52 -0600 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <53018DE1.1090901@meetinghouse.net> <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> Message-ID: On 2/17/14 6:46 AM, "Jon Schneider" wrote: >I've head the displeasure of CPAN going back to the mid 90s and it's still >a steaming heap as far as I'm concerned. I'm glad I stopped writing more >than the very occasional bit of perl a long time ago. As a regular contributor to the steaming heap, I am glad to report that the CPAN client experience that you rightly found irksome is much improved in recent years. For example there is now a very lightweight and fast CPAN client that asks no questions to set up - https://metacpan.org/pod/release/MIYAGAWA/App-cpanminus-1.7001/bin/cpanm (And the default CPAN client that ships with Perl proper will ask no set up questions in Perl 5.20 due out in April/May.) As far as *services to library authors* go, CPAN is a wonderful resource - for example, within minutes of uploading my Perl code to CPAN, the CPANTS (CPAN Testing Service) executes my tests on multiple operating systems and multiple Perl interpreters and emails me exceptions. As someone who develops Perl in a very specific context (Perl 5.18 on Mac OS X) this is a really valuable service to understand how my code behaves on platforms and Perl interpreters different from my own. Cheers, Mark From mallen@REDACTED Mon Feb 17 16:58:06 2014 From: mallen@REDACTED (Mark Allen) Date: Mon, 17 Feb 2014 09:58:06 -0600 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <53018DE1.1090901@meetinghouse.net> <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> <53021D9F.7060605@meetinghouse.net> Message-ID: On 2/17/14 8:50 AM, "Garrett Smith" wrote: >Grabbing required source into a single directory and compiling >everything, independent of shared system code, is, in my experience, >much more reliable. I agree with you here to the extent that it effectively replicates an isolated development environment much like virtualenv or rvm provide for Python or Ruby. >I think I'm going to call this a feature, not a bug. TL;DR: When it's *obvious* there is a great Erlang implementation of X, github is fine. Otherwise, it is totally crappy. To encourage broader adoption, Erlang *does* need some kind of maintained package index that roughly consolidates the community's package preferences into something more meaningful than "I needed to support function X in Erlang and I found these 3 projects using Google." Because that's a crazy way to expect n00bs to find solutions to real problems they're having. I assure you as someone who "recently learned" Erlang - about 18 months ago - I cannot count the number of times I have started working on implementing a story for my $JOB and frittered away an hour or three searching Google and github.com looking for " Erlang" before I reinvent the wheel. The simple fact is that if you're not part of the "Erlang community" via this mailing list or what have you, you will at best find pointers to half completed abandon ware on Google code, obscure blog posts written three years ago and so forth. There have been several times when rather waste time implementing "WebService-X for Erlang" I just go ahead and use the official Python library hanging off a RabbitMQ consumer. Cheers, Mark From sergej.jurecko@REDACTED Mon Feb 17 17:30:19 2014 From: sergej.jurecko@REDACTED (Sergej Jurecko) Date: Mon, 17 Feb 2014 17:30:19 +0100 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: <53021AC4.8080303@meetinghouse.net> References: <53021AC4.8080303@meetinghouse.net> Message-ID: http://www.actordb.com/ Sergej On Feb 17, 2014, at 3:20 PM, Miles Fidelman wrote: > [Enough with the threads on Erlang angst for a while - time for some real questions :-) ] > > BACKGROUND: > A lot of what I do is systems engineering, and a lot of that ends up in the realm of technology assessment - picking the right platform and tools for a particular system. My dablings in Erlang are largely in that category - I keep seeing it as potentially useful for a class of systems, keep experimenting with it, done a couple proof-of-concept efforts, but haven't built an operational system at scale with it (yet). The focus, so far, has been in modeling and simulation (I first discovered Erlang when chasing R&D contracts for a firm that built simulation engines for military trainers. I was flabbergasted to discover that everything was written in C++, every simulated entity was an object, with 4 main loops threading through every object, 20 times a second. Talk about spaghetti code. Coming from a data comm. protocol/network background - where we'd spawn a process for everything - I asked the obvious question, and was told that context switches would bring a 10,000 entity simulation to its knees. My instinctual response was "bullshit" - and went digging into the technology for massive concurrency, and discovered Erlang.) > > Anyway.... For years, I've been finding myself in situations, and on projects, that have a common characteristic of linked documents that change a lot - in the general arena of planning and workflow. Lots of people, each editing different parts of different documents - with changes rippling through the collection. Think linked spreadsheets, tiered project plans, multi-level engineering documents with lots of inter-dependencies. To be more concrete: systems engineering documents, large proposals, business planning systems, command and control systems. > > Add in requirements for disconnected operation that lead to distribution/replication requirements rather than keeping single, central copies of things (as the librarians like to say, "Lots of Copies Keeps Stuff Safe"). > > So far we've always taken conventional approaches - ranging from manual paper shuffling and xeroxing, to file servers with manual organization, to some of MS Office's document linking capabilities, to document databases and sharepoint. And played with some XML database technologies. > > But.... I keep thinking that there are a set of underlying functions that beg for better tools - something like a distributed CVS that's optimized for planning documents rather than software (or perhaps something like a modernized Lotus Notes). > > And I keep thinking that the obvious architectural model is to treat each document (maybe each page) as an actor ("smart documents" if you will), with communication through publish-subscribe mechanisms. Interact with a (copy of) a document, changes get pushed to groups of documents via a pub-sub mechanism. (Not unlike actor based simulation approaches.) > > And, of course, when I think actors, I think Erlang. The obvious conceptualization is "every document is an actor." > > At which point an obvious question comes up: How to handle long-term persistence, for large numbers of inactive entities. > > But... when I go looking for examples of systems that might be built this way, I keep finding that, even in Erlang-based systems, persistence is handled in fairly conventional ways: > - One might think that CouchDB treats every document as an actor, but think again > - Paulo Negri has given some great presentations on how Wooga implements large-scale social gaming - and they implement an actor per session - but when a user goes off-line they push state into a more conventional database (then initialize a gen_server from the database, when the user comes back online) > > At which point the phrase "actor-oriented database" keeps coming back to mind, with the obvious analogy to "object-oriented databases." I.e., something with the persistence and other characteristics of a database, where the contents are actors - with all the characteristics and functionality of those actors preserved while stored in the database. > > ON TO THE QUESTIONS: > I have a pretty good understanding of how one would build things like simulations, or protocol servers, with Erlang - not so much how one might build something with long-term persistence - which leads to some questions (some, probably naive): > > 1. So far, I haven't seen anything that actually looks like an "actor-oriented database." Document databases implemented in Erlang, yes (e.g., CouchDB), but every example I find ultimately pushes persistent data into files or a more conventional database of some sort. Can anybody point to an example of something that looks more like "storing actors in a database?" > - It strikes me that the core issues with doing so have to do with maintaining "aliveness" - i.e., dealing with addressability, routing messages to a stored actor, waking up after a timeout (i.e., the equivalent of triggers) > > 2. One obvious (if simplistic) thought: Does one really need to think in terms of a "database" at all - or might this problem be approached simply by creating each document as an Erlang process, and keeping it around forever? Most of what I've seen built in Erlang focuses on relatively short-lived actors - I'd be really interested in comments on: > - limitations/issues in persisting 100s of 1000s, or maybe millions of actors, for extended periods of time (years, or decades) > - are there any tools/models for migrating (swapping?) inactive processes dynamically to/from disk storage > > 3. What about backup for the state of a process? 'Let it crash' is great for servers supporting a reliable protocol, not so great for an actor that has internal state that has to be preserved (like a simulated tank, or a "smart document"). Pushing into a database is obvious, but... > - are there any good models for saving/restoring state within a tree of supervised processes? > - what about models for synchronizing state across replicated copies of processes running on different nodes? > - what about backup/restore of entire Erlang VMs (including anything that might be swapped out onto disk) > > 4. For communications between/among actors: Erlang is obviously excellent for writing pub-sub engines (RabbitMQ and ejabberd come to mind), but what about pub-sub or multicast/broadcast models or messaging between Erlang processes? Are there any good libraries for defining/managing process groups, and doing multicast or broadcast messaging to/among a group of processes. > > Thank you very much for any pointers or thoughts. > > 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 mfidelman@REDACTED Mon Feb 17 17:47:25 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 17 Feb 2014 11:47:25 -0500 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: References: <53021AC4.8080303@meetinghouse.net> Message-ID: <53023D1D.80602@meetinghouse.net> Well thanks, and there are some interesting ideas there - particularly re. addressing, but... "A distributed SQL database with the scalability of a KV store." and uses sqlite as the back end Not quite what I'm looking for. Not really a "database of actors" in the way that, say Gemstone is an "Object oriented database" Sergej Jurecko wrote: > http://www.actordb.com/ > > > Sergej > > On Feb 17, 2014, at 3:20 PM, Miles Fidelman wrote: > >> [Enough with the threads on Erlang angst for a while - time for some >> real questions :-) ] >> >> BACKGROUND: >> A lot of what I do is systems engineering, and a lot of that ends up >> in the realm of technology assessment - picking the right platform >> and tools for a particular system. My dablings in Erlang are largely >> in that category - I keep seeing it as potentially useful for a class >> of systems, keep experimenting with it, done a couple >> proof-of-concept efforts, but haven't built an operational system at >> scale with it (yet). The focus, so far, has been in modeling and >> simulation (I first discovered Erlang when chasing R&D contracts for >> a firm that built simulation engines for military trainers. I was >> flabbergasted to discover that everything was written in C++, every >> simulated entity was an object, with 4 main loops threading through >> every object, 20 times a second. Talk about spaghetti code. Coming >> from a data comm. protocol/network background - where we'd spawn a >> process for everything - I asked the obvious question, and was told >> that context switches would bring a 10,000 entity simulation to its >> knees. My instinctual response was "bullshit" - and went digging >> into the technology for massive concurrency, and discovered Erlang.) >> >> Anyway.... For years, I've been finding myself in situations, and on >> projects, that have a common characteristic of linked documents that >> change a lot - in the general arena of planning and workflow. Lots of >> people, each editing different parts of different documents - with >> changes rippling through the collection. Think linked spreadsheets, >> tiered project plans, multi-level engineering documents with lots of >> inter-dependencies. To be more concrete: systems engineering >> documents, large proposals, business planning systems, command and >> control systems. >> >> Add in requirements for disconnected operation that lead to >> distribution/replication requirements rather than keeping single, >> central copies of things (as the librarians like to say, "Lots of >> Copies Keeps Stuff Safe"). >> >> So far we've always taken conventional approaches - ranging from >> manual paper shuffling and xeroxing, to file servers with manual >> organization, to some of MS Office's document linking capabilities, >> to document databases and sharepoint. And played with some XML >> database technologies. >> >> But.... I keep thinking that there are a set of underlying functions >> that beg for better tools - something like a distributed CVS that's >> optimized for planning documents rather than software (or perhaps >> something like a modernized Lotus Notes). >> >> And I keep thinking that the obvious architectural model is to treat >> each document (maybe each page) as an actor ("smart documents" if you >> will), with communication through publish-subscribe mechanisms. >> Interact with a (copy of) a document, changes get pushed to groups of >> documents via a pub-sub mechanism. (Not unlike actor based >> simulation approaches.) >> >> And, of course, when I think actors, I think Erlang. The obvious >> conceptualization is "every document is an actor." >> >> At which point an obvious question comes up: How to handle long-term >> persistence, for large numbers of inactive entities. >> >> But... when I go looking for examples of systems that might be built >> this way, I keep finding that, even in Erlang-based systems, >> persistence is handled in fairly conventional ways: >> - One might think that CouchDB treats every document as an actor, but >> think again >> - Paulo Negri has given some great presentations on how Wooga >> implements large-scale social gaming - and they implement an actor >> per session - but when a user goes off-line they push state into a >> more conventional database (then initialize a gen_server from the >> database, when the user comes back online) >> >> At which point the phrase "actor-oriented database" keeps coming back >> to mind, with the obvious analogy to "object-oriented databases." >> I.e., something with the persistence and other characteristics of a >> database, where the contents are actors - with all the >> characteristics and functionality of those actors preserved while >> stored in the database. >> >> ON TO THE QUESTIONS: >> I have a pretty good understanding of how one would build things like >> simulations, or protocol servers, with Erlang - not so much how one >> might build something with long-term persistence - which leads to >> some questions (some, probably naive): >> >> 1. So far, I haven't seen anything that actually looks like an >> "actor-oriented database." Document databases implemented in Erlang, >> yes (e.g., CouchDB), but every example I find ultimately pushes >> persistent data into files or a more conventional database of some >> sort. Can anybody point to an example of something that looks more >> like "storing actors in a database?" >> - It strikes me that the core issues with doing so have to do with >> maintaining "aliveness" - i.e., dealing with addressability, routing >> messages to a stored actor, waking up after a timeout (i.e., the >> equivalent of triggers) >> >> 2. One obvious (if simplistic) thought: Does one really need to think >> in terms of a "database" at all - or might this problem be approached >> simply by creating each document as an Erlang process, and keeping it >> around forever? Most of what I've seen built in Erlang focuses on >> relatively short-lived actors - I'd be really interested in comments on: >> - limitations/issues in persisting 100s of 1000s, or maybe millions >> of actors, for extended periods of time (years, or decades) >> - are there any tools/models for migrating (swapping?) inactive >> processes dynamically to/from disk storage >> >> 3. What about backup for the state of a process? 'Let it crash' is >> great for servers supporting a reliable protocol, not so great for an >> actor that has internal state that has to be preserved (like a >> simulated tank, or a "smart document"). Pushing into a database is >> obvious, but... >> - are there any good models for saving/restoring state within a tree >> of supervised processes? >> - what about models for synchronizing state across replicated copies >> of processes running on different nodes? >> - what about backup/restore of entire Erlang VMs (including anything >> that might be swapped out onto disk) >> >> 4. For communications between/among actors: Erlang is obviously >> excellent for writing pub-sub engines (RabbitMQ and ejabberd come to >> mind), but what about pub-sub or multicast/broadcast models or >> messaging between Erlang processes? Are there any good libraries for >> defining/managing process groups, and doing multicast or broadcast >> messaging to/among a group of processes. >> >> Thank you very much for any pointers or thoughts. >> >> 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 > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From ludovic@REDACTED Mon Feb 17 17:58:23 2014 From: ludovic@REDACTED (ludovic@REDACTED) Date: Mon, 17 Feb 2014 17:58:23 +0100 Subject: [erlang-questions] Generic server and selective receives In-Reply-To: References: <01ea44277e59d63ec6d4975c9499d738@demblans.com> Message-ID: <64d1f5778a00557d54602994508cb6d6@demblans.com> That's very interesting. Many thanks. Cheers, Ludovic Le 2014-02-17 15:07, Daniel Goertzen a ?crit?: > Take a look at plain_fsm: > > https://github.com/uwiger/plain_fsm/blob/master/doc/plain_fsm.md [2] > > Dan. > > On Sun, Feb 16, 2014 at 5:55 PM, wrote: > > > Links: > ------ > [1] http://erlang.org/mailman/listinfo/erlang-questions > [2] https://github.com/uwiger/plain_fsm/blob/master/doc/plain_fsm.md From bob@REDACTED Mon Feb 17 18:04:22 2014 From: bob@REDACTED (Bob Ippolito) Date: Mon, 17 Feb 2014 09:04:22 -0800 Subject: [erlang-questions] random thought: connecting to node, specify IP address In-Reply-To: References: Message-ID: The best way to handle this is to force the nodes to come up with a predictable name, not dependent on reverse DNS, such as foo@REDACTED For discovery, these nodes can register themselves to some central directory (dynamic DNS, database, etc.) or send periodic broadcast messages (mDNS or some bespoke broadcast scheme). On Monday, February 17, 2014, David Welton wrote: > Hi, > > For various reasons, we sometimes have nodes that come up with a long > node name that does not nicely map onto the network - say, > foo@REDACTED or foo@REDACTED that does not get a > DNS entry. The nodes operate in somewhat unknown and unstable network > situation, so we may not even know the IP address ahead of time. > > It'd be nice to be able to - at a later date - force a connection to > those nodes by specifying an IP address in the connection code > somewhere. > > Is something like this at all feasible? > > Thank you > -- > David N. Welton > > http://www.welton.it/davidw/ > > http://www.dedasys.com/ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mloftis@REDACTED Mon Feb 17 17:54:59 2014 From: mloftis@REDACTED (Michael Loftis) Date: Mon, 17 Feb 2014 08:54:59 -0800 Subject: [erlang-questions] Sharing resource types between NIFs In-Reply-To: <53021A82.5030802@ninenines.eu> References: <52FFE8AD.2030507@ninenines.eu> <5302150E.7040405@erix.ericsson.se> <53021A82.5030802@ninenines.eu> Message-ID: Windows IIRC, especially, can allocate memory so only certain DLL's can access it, I don't recall the details, or if this is the default or not. I think they call it "apartment model"? It's been a looooong time since I've been deep in on windows so I could be pretty far off the mark. On Mon, Feb 17, 2014 at 6:19 AM, Lo?c Hoguin wrote: > On 02/17/2014 02:56 PM, Sverker Eriksson wrote: >> >> Having dependences between NIF modules (or drivers) on the native code >> level is not supported. >> How symbols are resolved (or not) between dynamic libraries is OS >> dependent (Windows). >> The runtime system can not keep track of such dependencies. For example, >> if module B makes a native call to a function in module A and module A >> has been unloaded...VM crash (or worse). >> >> I suggest you merge your dependent NIF code into one module. You can >> still have different modules on Erlang level and have them call a >> backend NIF module. > > > Thanks, that's exactly what I ended up doing. > > >> That being said... ... the scenario you describe should work in current >> implementation. enif_get_resource() does not care where it is called from. > > > Well it didn't work. :-) > > >> /Sverker, Erlang/OTP >> >> >> >> >> On 02/15/2014 11:22 PM, Lo?c Hoguin wrote: >>> >>> Hello, >>> >>> I have been looking into this and after looking into the source it >>> doesn't seem possible, but I might as well ask just in case. >>> >>> Say I am writing bindings for a big library. That library is cut into >>> various components, and I would like to do similar on the Erlang side. >>> Components are more or less dependent. Let's just say that component B >>> uses component A. You can't do anything in B without A. They are both >>> NIF resources pointing to things used by the library. >>> >>> Now if I try to create a NIF module for A and a NIF module for B, I >>> need to access the resource type of A from the B NIF. I tried simply >>> exporting a function from the A .so and use it from the B .so, the >>> function returns the resource type as expected, however using it to >>> retrieve the resource fails. >>> >>> Trying to do the same from A of course works. It's just trying to use >>> the resource type of A from B that fails. >>> >>> I'm assuming this isn't possible? >>> >>> Thanks. >>> >> >> > > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > 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 sergej.jurecko@REDACTED Mon Feb 17 18:45:08 2014 From: sergej.jurecko@REDACTED (Sergej Jurecko) Date: Mon, 17 Feb 2014 18:45:08 +0100 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: <53023D1D.80602@meetinghouse.net> References: <53021AC4.8080303@meetinghouse.net> <53023D1D.80602@meetinghouse.net> Message-ID: <3A5499F3-F757-4E72-B3DA-BF6A9EFC995B@gmail.com> Each actor is isolated and independent. This is why using sqlite is completely scalable. I thought it would be quite clear that it fits your ideas well. So let me expand more on your questions. >>> >>> >>> 1. So far, I haven't seen anything that actually looks like an "actor-oriented database." Document databases implemented in Erlang, yes (e.g., CouchDB), but every example I find ultimately pushes persistent data into files or a more conventional database of some sort. Can anybody point to an example of something that looks more like "storing actors in a database?" >>> - It strikes me that the core issues with doing so have to do with maintaining "aliveness" - i.e., dealing with addressability, routing messages to a stored actor, waking up after a timeout (i.e., the equivalent of triggers) >>> Storing the actor state in an sql database gives you the most flexible data model. All the issues you listed are something actordb deals with. >>> 2. One obvious (if simplistic) thought: Does one really need to think in terms of a "database" at all - or might this problem be approached simply by creating each document as an Erlang process, and keeping it around forever? Most of what I've seen built in Erlang focuses on relatively short-lived actors - I'd be really interested in comments on: >>> - limitations/issues in persisting 100s of 1000s, or maybe millions of actors, for extended periods of time (years, or decades) >>> - are there any tools/models for migrating (swapping?) inactive processes dynamically to/from disk storage >>> ActorDB will keep an actor open while it is doing something. Once it stops doing stuff it is closed and remains untouched on disk until it is used again. >>> 3. What about backup for the state of a process? 'Let it crash' is great for servers supporting a reliable protocol, not so great for an actor that has internal state that has to be preserved (like a simulated tank, or a "smart document"). Pushing into a database is obvious, but... >>> - are there any good models for saving/restoring state within a tree of supervised processes? >>> - what about models for synchronizing state across replicated copies of processes running on different nodes? >>> - what about backup/restore of entire Erlang VMs (including anything that might be swapped out onto disk) >>> ActorDB will replicate state to multiple servers. >>> 4. For communications between/among actors: Erlang is obviously excellent for writing pub-sub engines (RabbitMQ and ejabberd come to mind), but what about pub-sub or multicast/broadcast models or messaging between Erlang processes? Are there any good libraries for defining/managing process groups, and doing multicast or broadcast messaging to/among a group of processes. >>> This is where a separation of code and data comes in. A use case that ActorDB could easily be expanded to do (without a lot of work). ActorDB handles the storage and persistence of state. The application programer implements his program logic in his own code. ActorDB could provide "triggers". For instance you have an actor (some gen_server) running on a node: - When it wants to store the result of some work, it stores it in his actor in ActorDB. - If it wants to send a message to one or many actors, he would create a write transaction to multiple actors. The transaction would do an insert to their "events" table. ActorDB would then callback your own code for every one of those actors and tell them there is work for them to do. This way no event is ever lost. - If you just want to send non-persistent messages to erlang processes you can use pg or pg2 modules and sidestep ActorDB. Or maybe it makes sense to support sending non-persistent messages through ActorDB and rely on it to route those messages to the right processes on the right nodes. Callbacks could be directly within erlang or externally connected with http or zeromq. So your app logic can be implemented in anything. Sergej -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Mon Feb 17 19:04:12 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 17 Feb 2014 13:04:12 -0500 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: References: <53021AC4.8080303@meetinghouse.net> Message-ID: <53024F1C.4060507@meetinghouse.net> Guys, please - I'm not looking at modeling "a document" - I'm looking at modeling 100s of copies of documents, each with local changes, that are currently being updated (say, my copy of a project plan); as well as families of related documents (say a schedule, a budget, progress reports). At any given time, I may make a marginal note, or an edit, or an edit - and I want that to propagate according to local rules. The best conceptual model I come up with is: each document is an actor, with a mailbox, and a multi-cast pub-sub mechanism for sending changes to a group of people who have copies of the document. (Think of a loose-leaf binder, and change pages coming through the mail). For that matter, think USENET news and NNTP - except with each message being addressible - instead of a thread as 100 messages, it becomes one message, plus 99 updates to that message, each processed by code within the 1st message. If I wanted to model this as a standard database, or serializing state into a traditional database, I wouldn't be asking the questions I asked. Can anybody talk to the questions I actually asked, about: - handling large numbers of actors that might persist for years, or decades (where actor = Erlang-style process) - backup up/restoring state of long-running actors that might crash - multi-cast messaging among actors Erlang is the closest I've found to an environment where this might be practical - but that remains an open question. So please - while appreciated, I'm really not looking for information about alternative conceptual models; I'm looking for hard information about how this conceptual model might be implemented in Erlang. Miles Michael Radford wrote: > I'd suggest taking a look at Riak, and also Basho's library riak-core. > With Riak and a bit of Erlang, you can easily model a document as a > sequence of change operations which are composed on-demand to present > the latest version. On top of that, you get mechanisms for maintaining > the database without any single point of failure, and for dealing with > simultaneous/competing changes from multiple users. > > For persisting actors, the nice thing about Erlang is that pretty much > whatever your actor's state is [*], you can store its term_to_binary > representation in whatever database you choose. [* except for > anonymous functions, which you can always turn into atoms as long as > they're not completely arbitrary.] > > On Mon, Feb 17, 2014 at 6:50 AM, Jesper Louis Andersen > wrote: >> A document is a trace of events. These events records edits to the document >> and when we play all of the events, we obtain the final document state. >> Infinite undo is possible by looking back and replaying with a point-in-time >> recovery option. An actor is a handler that can apply events to a state in >> order to obtain a new state. >> >> Events are persisted in an event log and WAL fashion. So even if the system >> dies, we can replay its state safely. Once in a while, living processes >> checkpoint their state to disk so they can boot up faster than having to >> replay from day 0. >> >> Multiple edits to the same document can be handled by operational transforms >> >> http://en.wikipedia.org/wiki/Operational_transformation >> >> Idle documents terminate themselves after a while by checkpointing >> themselves to disk. Documents register themselves into gproc and if there is >> no document present in gproc, you go to a manager and get it set up either >> from disk or by forming a new document. >> >> For easy storage, you can use a single table in a database for the log. >> >> >> On Mon, Feb 17, 2014 at 3:20 PM, Miles Fidelman >> wrote: >>> [Enough with the threads on Erlang angst for a while - time for some real >>> questions :-) ] >>> >>> BACKGROUND: >>> A lot of what I do is systems engineering, and a lot of that ends up in >>> the realm of technology assessment - picking the right platform and tools >>> for a particular system. My dablings in Erlang are largely in that category >>> - I keep seeing it as potentially useful for a class of systems, keep >>> experimenting with it, done a couple proof-of-concept efforts, but haven't >>> built an operational system at scale with it (yet). The focus, so far, has >>> been in modeling and simulation (I first discovered Erlang when chasing R&D >>> contracts for a firm that built simulation engines for military trainers. I >>> was flabbergasted to discover that everything was written in C++, every >>> simulated entity was an object, with 4 main loops threading through every >>> object, 20 times a second. Talk about spaghetti code. Coming from a data >>> comm. protocol/network background - where we'd spawn a process for >>> everything - I asked the obvious question, and was told that context >>> switches would bring a 10,000 entity simulation to its knees. My >>> instinctual response was "bullshit" - and went digging into the technology >>> for massive concurrency, and discovered Erlang.) >>> >>> Anyway.... For years, I've been finding myself in situations, and on >>> projects, that have a common characteristic of linked documents that change >>> a lot - in the general arena of planning and workflow. Lots of people, each >>> editing different parts of different documents - with changes rippling >>> through the collection. Think linked spreadsheets, tiered project plans, >>> multi-level engineering documents with lots of inter-dependencies. To be >>> more concrete: systems engineering documents, large proposals, business >>> planning systems, command and control systems. >>> >>> Add in requirements for disconnected operation that lead to >>> distribution/replication requirements rather than keeping single, central >>> copies of things (as the librarians like to say, "Lots of Copies Keeps Stuff >>> Safe"). >>> >>> So far we've always taken conventional approaches - ranging from manual >>> paper shuffling and xeroxing, to file servers with manual organization, to >>> some of MS Office's document linking capabilities, to document databases and >>> sharepoint. And played with some XML database technologies. >>> >>> But.... I keep thinking that there are a set of underlying functions that >>> beg for better tools - something like a distributed CVS that's optimized for >>> planning documents rather than software (or perhaps something like a >>> modernized Lotus Notes). >>> >>> And I keep thinking that the obvious architectural model is to treat each >>> document (maybe each page) as an actor ("smart documents" if you will), with >>> communication through publish-subscribe mechanisms. Interact with a (copy >>> of) a document, changes get pushed to groups of documents via a pub-sub >>> mechanism. (Not unlike actor based simulation approaches.) >>> >>> And, of course, when I think actors, I think Erlang. The obvious >>> conceptualization is "every document is an actor." >>> >>> At which point an obvious question comes up: How to handle long-term >>> persistence, for large numbers of inactive entities. >>> >>> But... when I go looking for examples of systems that might be built this >>> way, I keep finding that, even in Erlang-based systems, persistence is >>> handled in fairly conventional ways: >>> - One might think that CouchDB treats every document as an actor, but >>> think again >>> - Paulo Negri has given some great presentations on how Wooga implements >>> large-scale social gaming - and they implement an actor per session - but >>> when a user goes off-line they push state into a more conventional database >>> (then initialize a gen_server from the database, when the user comes back >>> online) >>> >>> At which point the phrase "actor-oriented database" keeps coming back to >>> mind, with the obvious analogy to "object-oriented databases." I.e., >>> something with the persistence and other characteristics of a database, >>> where the contents are actors - with all the characteristics and >>> functionality of those actors preserved while stored in the database. >>> >>> ON TO THE QUESTIONS: >>> I have a pretty good understanding of how one would build things like >>> simulations, or protocol servers, with Erlang - not so much how one might >>> build something with long-term persistence - which leads to some questions >>> (some, probably naive): >>> >>> 1. So far, I haven't seen anything that actually looks like an >>> "actor-oriented database." Document databases implemented in Erlang, yes >>> (e.g., CouchDB), but every example I find ultimately pushes persistent data >>> into files or a more conventional database of some sort. Can anybody point >>> to an example of something that looks more like "storing actors in a >>> database?" >>> - It strikes me that the core issues with doing so have to do with >>> maintaining "aliveness" - i.e., dealing with addressability, routing >>> messages to a stored actor, waking up after a timeout (i.e., the equivalent >>> of triggers) >>> >>> 2. One obvious (if simplistic) thought: Does one really need to think in >>> terms of a "database" at all - or might this problem be approached simply by >>> creating each document as an Erlang process, and keeping it around forever? >>> Most of what I've seen built in Erlang focuses on relatively short-lived >>> actors - I'd be really interested in comments on: >>> - limitations/issues in persisting 100s of 1000s, or maybe millions of >>> actors, for extended periods of time (years, or decades) >>> - are there any tools/models for migrating (swapping?) inactive processes >>> dynamically to/from disk storage >>> >>> 3. What about backup for the state of a process? 'Let it crash' is great >>> for servers supporting a reliable protocol, not so great for an actor that >>> has internal state that has to be preserved (like a simulated tank, or a >>> "smart document"). Pushing into a database is obvious, but... >>> - are there any good models for saving/restoring state within a tree of >>> supervised processes? >>> - what about models for synchronizing state across replicated copies of >>> processes running on different nodes? >>> - what about backup/restore of entire Erlang VMs (including anything that >>> might be swapped out onto disk) >>> >>> 4. For communications between/among actors: Erlang is obviously excellent >>> for writing pub-sub engines (RabbitMQ and ejabberd come to mind), but what >>> about pub-sub or multicast/broadcast models or messaging between Erlang >>> processes? Are there any good libraries for defining/managing process >>> groups, and doing multicast or broadcast messaging to/among a group of >>> processes. >>> >>> Thank you very much for any pointers or thoughts. >>> >>> 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 >> >> >> >> -- >> J. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From erlang@REDACTED Mon Feb 17 20:15:17 2014 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 17 Feb 2014 20:15:17 +0100 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: <53021AC4.8080303@meetinghouse.net> References: <53021AC4.8080303@meetinghouse.net> Message-ID: This sounds interesting. To start wit, I think swapping processes to disk is just an optimization. In theory you could just keep everything in RAM forever. I guess processes could keep their state in dictionaries (so you could roll them back) or ets tables (if you didn't want to roll them back). You would need some form of crash recovery so processes should write some state information to disk at suitable points in the program. What I think is a more serious problem is getting data into the system in the first place. I have done some experiments with document commenting and annotation systems and found it very difficult to convert things like word documents into a form that looks half decent in a user interface. I want to parse Microsoft word files and PDF etc. and display them in a format that is recognisable and not too abhorrent to the user. I also want to allow on-screen manipulation of documents (in a browser) - all of this seems to require a mess of Javascript (in the browser)and a mess of parsing programs inn the server. Before we can manipulate documents we must parse them and turn them into a format that can be manipulated. I think this is more difficult that the storing and manipulating documents problem. You'd also need support for full-text indexing, foreign language and multiple character sets and so on. Just a load of horrible messy small problems, but a significant barrier to importing large amounts of content into the system. You'd also need some quality control of the documents as they enter the system (to avoid rubbish in rubbish out), also to maintain the integrity of the documents. If you have any ideas of now to get large volumes of data into the system from proprietary formats (like ms word) I'd like to hear about it. Cheers /Joe On Mon, Feb 17, 2014 at 3:20 PM, Miles Fidelman wrote: > [Enough with the threads on Erlang angst for a while - time for some real > questions :-) ] > > BACKGROUND: > A lot of what I do is systems engineering, and a lot of that ends up in > the realm of technology assessment - picking the right platform and tools > for a particular system. My dablings in Erlang are largely in that > category - I keep seeing it as potentially useful for a class of systems, > keep experimenting with it, done a couple proof-of-concept efforts, but > haven't built an operational system at scale with it (yet). The focus, so > far, has been in modeling and simulation (I first discovered Erlang when > chasing R&D contracts for a firm that built simulation engines for military > trainers. I was flabbergasted to discover that everything was written in > C++, every simulated entity was an object, with 4 main loops threading > through every object, 20 times a second. Talk about spaghetti code. > Coming from a data comm. protocol/network background - where we'd spawn a > process for everything - I asked the obvious question, and was told that > context switches would bring a 10,000 entity simulation to its knees. My > instinctual response was "bullshit" - and went digging into the technology > for massive concurrency, and discovered Erlang.) > > Anyway.... For years, I've been finding myself in situations, and on > projects, that have a common characteristic of linked documents that change > a lot - in the general arena of planning and workflow. Lots of people, each > editing different parts of different documents - with changes rippling > through the collection. Think linked spreadsheets, tiered project plans, > multi-level engineering documents with lots of inter-dependencies. To be > more concrete: systems engineering documents, large proposals, business > planning systems, command and control systems. > > Add in requirements for disconnected operation that lead to > distribution/replication requirements rather than keeping single, central > copies of things (as the librarians like to say, "Lots of Copies Keeps > Stuff Safe"). > > So far we've always taken conventional approaches - ranging from manual > paper shuffling and xeroxing, to file servers with manual organization, to > some of MS Office's document linking capabilities, to document databases > and sharepoint. And played with some XML database technologies. > > But.... I keep thinking that there are a set of underlying functions that > beg for better tools - something like a distributed CVS that's optimized > for planning documents rather than software (or perhaps something like a > modernized Lotus Notes). > > And I keep thinking that the obvious architectural model is to treat each > document (maybe each page) as an actor ("smart documents" if you will), > with communication through publish-subscribe mechanisms. Interact with a > (copy of) a document, changes get pushed to groups of documents via a > pub-sub mechanism. (Not unlike actor based simulation approaches.) > > And, of course, when I think actors, I think Erlang. The obvious > conceptualization is "every document is an actor." > > At which point an obvious question comes up: How to handle long-term > persistence, for large numbers of inactive entities. > > But... when I go looking for examples of systems that might be built this > way, I keep finding that, even in Erlang-based systems, persistence is > handled in fairly conventional ways: > - One might think that CouchDB treats every document as an actor, but > think again > - Paulo Negri has given some great presentations on how Wooga implements > large-scale social gaming - and they implement an actor per session - but > when a user goes off-line they push state into a more conventional database > (then initialize a gen_server from the database, when the user comes back > online) > > At which point the phrase "actor-oriented database" keeps coming back to > mind, with the obvious analogy to "object-oriented databases." I.e., > something with the persistence and other characteristics of a database, > where the contents are actors - with all the characteristics and > functionality of those actors preserved while stored in the database. > > ON TO THE QUESTIONS: > I have a pretty good understanding of how one would build things like > simulations, or protocol servers, with Erlang - not so much how one might > build something with long-term persistence - which leads to some questions > (some, probably naive): > > 1. So far, I haven't seen anything that actually looks like an > "actor-oriented database." Document databases implemented in Erlang, yes > (e.g., CouchDB), but every example I find ultimately pushes persistent data > into files or a more conventional database of some sort. Can anybody point > to an example of something that looks more like "storing actors in a > database?" > - It strikes me that the core issues with doing so have to do with > maintaining "aliveness" - i.e., dealing with addressability, routing > messages to a stored actor, waking up after a timeout (i.e., the equivalent > of triggers) > > 2. One obvious (if simplistic) thought: Does one really need to think in > terms of a "database" at all - or might this problem be approached simply > by creating each document as an Erlang process, and keeping it around > forever? Most of what I've seen built in Erlang focuses on relatively > short-lived actors - I'd be really interested in comments on: > - limitations/issues in persisting 100s of 1000s, or maybe millions of > actors, for extended periods of time (years, or decades) > - are there any tools/models for migrating (swapping?) inactive processes > dynamically to/from disk storage > > 3. What about backup for the state of a process? 'Let it crash' is great > for servers supporting a reliable protocol, not so great for an actor that > has internal state that has to be preserved (like a simulated tank, or a > "smart document"). Pushing into a database is obvious, but... > - are there any good models for saving/restoring state within a tree of > supervised processes? > - what about models for synchronizing state across replicated copies of > processes running on different nodes? > - what about backup/restore of entire Erlang VMs (including anything that > might be swapped out onto disk) > > 4. For communications between/among actors: Erlang is obviously excellent > for writing pub-sub engines (RabbitMQ and ejabberd come to mind), but what > about pub-sub or multicast/broadcast models or messaging between Erlang > processes? Are there any good libraries for defining/managing process > groups, and doing multicast or broadcast messaging to/among a group of > processes. > > Thank you very much for any pointers or thoughts. > > 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 fly@REDACTED Mon Feb 17 20:26:57 2014 From: fly@REDACTED (Fred Youhanaie) Date: Mon, 17 Feb 2014 19:26:57 +0000 Subject: [erlang-questions] history of programming languages Message-ID: <53026281.9090209@anydata.co.uk> Somehow related to the recent long discussions on languages, tabs and spaces etc. :-)) http://thequickword.wordpress.com/2014/02/16/james-irys-history-of-programming-languages-illustrated-with-pictures-and-large-fonts/ enjoy! From vances@REDACTED Mon Feb 17 20:48:59 2014 From: vances@REDACTED (Vance Shipley) Date: Tue, 18 Feb 2014 01:18:59 +0530 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: References: <53021AC4.8080303@meetinghouse.net> Message-ID: The zip and xmerl applications are that is needed to turn OpenOffice native ODF into Erlang terms. All you need to do next is everything you need to do. ;) On Feb 18, 2014 12:45 AM, "Joe Armstrong" wrote: > This sounds interesting. To start wit, I think swapping processes to disk > is just an optimization. > In theory you could just keep everything in RAM forever. I guess processes > could keep their state in dictionaries (so you could roll them back) or ets > tables (if you didn't want to roll them back). > > You would need some form of crash recovery so processes should write some > state information > to disk at suitable points in the program. > > What I think is a more serious problem is getting data into the system in > the first place. > I have done some experiments with document commenting and annotation > systems and > found it very difficult to convert things like word documents into a form > that looks half > decent in a user interface. > > I want to parse Microsoft word files and PDF etc. and display them in a > format that is > recognisable and not too abhorrent to the user. I also want to allow > on-screen manipulation of > documents (in a browser) - all of this seems to require a mess of > Javascript (in the browser)and a mess of parsing programs inn the server. > > Before we can manipulate documents we must parse them and turn them into a > format > that can be manipulated. I think this is more difficult that the storing > and manipulating documents > problem. You'd also need support for full-text indexing, foreign language > and multiple character sets and so > on. Just a load of horrible messy small problems, but a significant > barrier to importing large amounts > of content into the system. > > You'd also need some quality control of the documents as they enter the > system (to avoid rubbish in rubbish out), also to maintain the integrity of > the documents. > > If you have any ideas of now to get large volumes of data into the system > from proprietary formats > (like ms word) I'd like to hear about it. > > Cheers > > /Joe > > > > > > On Mon, Feb 17, 2014 at 3:20 PM, Miles Fidelman < > mfidelman@REDACTED> wrote: > >> [Enough with the threads on Erlang angst for a while - time for some real >> questions :-) ] >> >> BACKGROUND: >> A lot of what I do is systems engineering, and a lot of that ends up in >> the realm of technology assessment - picking the right platform and tools >> for a particular system. My dablings in Erlang are largely in that >> category - I keep seeing it as potentially useful for a class of systems, >> keep experimenting with it, done a couple proof-of-concept efforts, but >> haven't built an operational system at scale with it (yet). The focus, so >> far, has been in modeling and simulation (I first discovered Erlang when >> chasing R&D contracts for a firm that built simulation engines for military >> trainers. I was flabbergasted to discover that everything was written in >> C++, every simulated entity was an object, with 4 main loops threading >> through every object, 20 times a second. Talk about spaghetti code. >> Coming from a data comm. protocol/network background - where we'd spawn a >> process for everything - I asked the obvious question, and was told that >> context switches would bring a 10,000 entity simulation to its knees. My >> instinctual response was "bullshit" - and went digging into the technology >> for massive concurrency, and discovered Erlang.) >> >> Anyway.... For years, I've been finding myself in situations, and on >> projects, that have a common characteristic of linked documents that change >> a lot - in the general arena of planning and workflow. Lots of people, each >> editing different parts of different documents - with changes rippling >> through the collection. Think linked spreadsheets, tiered project plans, >> multi-level engineering documents with lots of inter-dependencies. To be >> more concrete: systems engineering documents, large proposals, business >> planning systems, command and control systems. >> >> Add in requirements for disconnected operation that lead to >> distribution/replication requirements rather than keeping single, central >> copies of things (as the librarians like to say, "Lots of Copies Keeps >> Stuff Safe"). >> >> So far we've always taken conventional approaches - ranging from manual >> paper shuffling and xeroxing, to file servers with manual organization, to >> some of MS Office's document linking capabilities, to document databases >> and sharepoint. And played with some XML database technologies. >> >> But.... I keep thinking that there are a set of underlying functions that >> beg for better tools - something like a distributed CVS that's optimized >> for planning documents rather than software (or perhaps something like a >> modernized Lotus Notes). >> >> And I keep thinking that the obvious architectural model is to treat each >> document (maybe each page) as an actor ("smart documents" if you will), >> with communication through publish-subscribe mechanisms. Interact with a >> (copy of) a document, changes get pushed to groups of documents via a >> pub-sub mechanism. (Not unlike actor based simulation approaches.) >> >> And, of course, when I think actors, I think Erlang. The obvious >> conceptualization is "every document is an actor." >> >> At which point an obvious question comes up: How to handle long-term >> persistence, for large numbers of inactive entities. >> >> But... when I go looking for examples of systems that might be built this >> way, I keep finding that, even in Erlang-based systems, persistence is >> handled in fairly conventional ways: >> - One might think that CouchDB treats every document as an actor, but >> think again >> - Paulo Negri has given some great presentations on how Wooga implements >> large-scale social gaming - and they implement an actor per session - but >> when a user goes off-line they push state into a more conventional database >> (then initialize a gen_server from the database, when the user comes back >> online) >> >> At which point the phrase "actor-oriented database" keeps coming back to >> mind, with the obvious analogy to "object-oriented databases." I.e., >> something with the persistence and other characteristics of a database, >> where the contents are actors - with all the characteristics and >> functionality of those actors preserved while stored in the database. >> >> ON TO THE QUESTIONS: >> I have a pretty good understanding of how one would build things like >> simulations, or protocol servers, with Erlang - not so much how one might >> build something with long-term persistence - which leads to some questions >> (some, probably naive): >> >> 1. So far, I haven't seen anything that actually looks like an >> "actor-oriented database." Document databases implemented in Erlang, yes >> (e.g., CouchDB), but every example I find ultimately pushes persistent data >> into files or a more conventional database of some sort. Can anybody point >> to an example of something that looks more like "storing actors in a >> database?" >> - It strikes me that the core issues with doing so have to do with >> maintaining "aliveness" - i.e., dealing with addressability, routing >> messages to a stored actor, waking up after a timeout (i.e., the equivalent >> of triggers) >> >> 2. One obvious (if simplistic) thought: Does one really need to think in >> terms of a "database" at all - or might this problem be approached simply >> by creating each document as an Erlang process, and keeping it around >> forever? Most of what I've seen built in Erlang focuses on relatively >> short-lived actors - I'd be really interested in comments on: >> - limitations/issues in persisting 100s of 1000s, or maybe millions of >> actors, for extended periods of time (years, or decades) >> - are there any tools/models for migrating (swapping?) inactive processes >> dynamically to/from disk storage >> >> 3. What about backup for the state of a process? 'Let it crash' is great >> for servers supporting a reliable protocol, not so great for an actor that >> has internal state that has to be preserved (like a simulated tank, or a >> "smart document"). Pushing into a database is obvious, but... >> - are there any good models for saving/restoring state within a tree of >> supervised processes? >> - what about models for synchronizing state across replicated copies of >> processes running on different nodes? >> - what about backup/restore of entire Erlang VMs (including anything that >> might be swapped out onto disk) >> >> 4. For communications between/among actors: Erlang is obviously >> excellent for writing pub-sub engines (RabbitMQ and ejabberd come to mind), >> but what about pub-sub or multicast/broadcast models or messaging between >> Erlang processes? Are there any good libraries for defining/managing >> process groups, and doing multicast or broadcast messaging to/among a group >> of processes. >> >> Thank you very much for any pointers or thoughts. >> >> Miles Fidelman >> >> >> >> >> -- >> In theory, there is no difference between theory and practice. >> In practice, there is. .... Yogi Berra >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Mon Feb 17 21:15:40 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Mon, 17 Feb 2014 12:15:40 -0800 (PST) Subject: [erlang-questions] Preloaded modules "lists" dependency In-Reply-To: <53021947.4070500@ninenines.eu> References: <52FDF77B.4070907@ninenines.eu> <53021947.4070500@ninenines.eu> Message-ID: <1392668140.48109.YahooMailNeo@web140102.mail.bf1.yahoo.com> "The "OTP2" part interests me a lot more. One of my favorite ideas is to?be able to define the whole supervision tree in a single module, and to? have it feature more complex components like pools for example. It could? come with a default pool implementation, with a well defined interface? (from the point of view of the supervision tree) that allows it to be? replaced with whichever one you want. So instead of having 10 modules? describing your application, it could all be in a very visual format ..." On Monday, February 17, 2014 3:43 PM, Lo?c Hoguin wrote: Thoughts and ideas are not worth a lot until they are tested so I will >spare you most details for now. It's still a pretty long read. > >For the "Erlang2" part, there isn't much to say. Erlang is a language >that is almost perfect. My conclusions about improving it are that there >are very few things that can be improved, and they are mostly edge cases >(shadowing would be a big one, and not being able to do (<< >B:Len/binary, _/bits >>, Len) in a function clause would be another - >but the latter is going to be solved soon as I gather). The rest of it, >well, I came pretty much to the same conclusions as Joe, the only thing >I would add is a basic form of metaprogramming. Basically you want to be >able to do two things: compute some data at compile time, and run tests >at compile time (and fail to compile if the tests fail). Optionally >would allow you to do some conditional builds to work around issues with >a specific version of Erlang. But no macros or other weird stuff that >just make the code more complex for no good reasons. > >I'm no language expert and I'm not too interested in this part so don't >expect anything from me on that point. If I ever attempt something it >would just be a very basic wrapper on top of the current Erlang syntax >to allow for compile-time stuff to happen (meaning: outside functions, >and perhaps even outside modules entirely). > >The "OTP2" part interests me a lot more. One of my favorite ideas is to >be able to define the whole supervision tree in a single module, and to >have it feature more complex components like pools for example. It could >come with a default pool implementation, with a well defined interface >(from the point of view of the supervision tree) that allows it to be >replaced with whichever one you want. So instead of having 10 modules >describing your application, it could all be in a very visual format in >a single module. > >I'm more interested in doing an "OTP2" that targets a different use than >long running server applications though. As you might already know, I >like video games, and I have tried a few quick prototypes of games with >Erlang. I think there is a lot of potential, but the barrier of entry is >very high. An "OTP2" geared toward games would help greatly. Games >typically have a main loop. There's basically no way around that today >because most graphic APIs aren't thread safe. SDL2 was released not too >long ago for example, and it still isn't thread safe. But that's not a >big problem, Erlang's concurrency can still play a big part. For >example, by making the lists module parallelize processing of the list >automatically past a certain threshold. Or providing efficient timer >capabilities (because the timer module ain't it). And the processes that >access the API can always be tied to scheduler 0 to avoid any issues. > >I started playing around making an SDL2 NIF this week-end. The first >thing you instantly win is not having to worry about freeing resources >(with a few gotchas of course, you can only have so much in memory). The >GC does it for you! The second thing you instantly win is Erlang's >pattern matching. The article I wrote about matching tic tac toe >solutions directly instead of trying to write an algorithm is a good >example of that. The code becomes small and clear and you can focus on >actually building the game. > >Of course, for anything to come out of these experiments, I have to find >a way to not get bored, which may prove difficult. Time will tell. > >On 02/17/2014 01:30 PM, Pierre Fenoll wrote: >> Hey Lo?c, >> >> I don't mean to hijack the thread. >> Can we have more information on "Erlang2/OTP2"? Your guidelines and >> back-of-a-napkin experiments interest me greatly. >> >> >> Cheers, >> >> >> >> _______________________________________________ >> 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 > > > Take a look at this:?https://github.com/thomasl/gen_app Here is one application I just started: ? 1> gen_app:app_sup(om, [{sup, {sup, om, [om_ets_owner, om_repository_server, om_code_server]}). Which starts a (dynamic) application 'om' with a supervisor 'om' handling three gen_servers on localhost. Caveats: Somewhat inelegant notation so far, and you still need 'application' for the more complex cases. No pool handling at the moment either. But it's pretty compact. Best, Thomas PS. Apologies to those I've written to recently -- Yahoo is acting up, perhaps due to THE HUGE THREADS we're having, so I'm having some trouble reading my mail at the moment. Sporadically hanging client, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Mon Feb 17 21:22:11 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 17 Feb 2014 15:22:11 -0500 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: References: <53021AC4.8080303@meetinghouse.net> Message-ID: <53026F73.5080106@meetinghouse.net> Joe Armstrong wrote: > This sounds interesting. To start wit, I think swapping processes to > disk is just an optimization. > In theory you could just keep everything in RAM forever. I guess > processes could keep their state in dictionaries (so you could roll > them back) or ets tables (if you didn't want to roll them back). > > You would need some form of crash recovery so processes should write > some state information > to disk at suitable points in the program. Joe... can you offer any insight into the dynamics of Erlang, when running with large number of processes that have very long persistence? Somehow, it strikes me that 100,000 processes with 1MB of state, each running for years at a time, have a different dynamic than 100,000 processes, each representing a short-lived protocol transaction (say a web query). Coupled with a communications paradigm for identifying a group of processes and sending each of them the same message (e.g., 5000 people have a copy of a book, send all 5000 of them a set of errata; or send a message asking 'who has updates for section 3.2). In some sense, the conceptual model is: 1. I send you an empty notebook. 2. The notebook has an address and a bunch of message handling routines 3. I can send a page to the notebook, and the notebook inserts the page. 4. You can interact with the notebook - read it, annotate it, edit certain sections - if you make updates, the notebook can distribute updates to other copies - either through a P2P mechanism or a publish-subscribe mechanism. At a basic level, this maps really well onto the Actor formalism - every notebook is an actor, with it's own address. Updates, interactions, queries, etc. are simply messages. Since Erlang is about the only serious implementation of the Actor formalism, I'm trying to poke at the edge cases - particularly around long-lived actors. And who better to ask than you :-) In passing: Early versions of Smalltalk were actor-like, encapsulating state, methods, and process - but process kind of got dropped along the way. By contrast, it strikes me that Erlang focuses on everything being a process, and long-term persistence of state has taken a back seat. I'm trying to probe the edge cases. (I guess another way of looking at this is: to what extent is Erlang workable for writing systems based around the mobile agent paradigm?) > > What I think is a more serious problem is getting data into the system > in the first place. > I have done some experiments with document commenting and annotation > systems and > found it very difficult to convert things like word documents into a > form that looks half > decent in a user interface. Haven't actually thought a lot about that part of the problem. I'm thinking of documents that are more form-like in nature, or at least built up from smaller components - so it's not so much going from Word to an internal format, as much as starting with XML or JSON (or tuples), building up structure, and then adding presentation at the final step. XML -> Word is a lot easier than the reverse :-) On the other hand, I do have a bunch of applications in mind where parsing Word and/or PDF would be very helpful - notably stripping requirements out of specifications. (I can't tell you how much of my time I spend manually cutting and pasting from specifications into spreadsheets - for requirements tracking and such.) Again, presentation isn't that much of an issue - structural and semantic analysis is. But, while important, that's a separate set of problems - and there are some commercial products that do a reasonably good job. > I want to parse Microsoft word files and PDF etc. and display them in > a format that is > recognisable and not too abhorrent to the user. I also want to allow > on-screen manipulation of > documents (in a browser) - all of this seems to require a mess of > Javascript (in the browser)and a mess of parsing programs inn the server. > > Before we can manipulate documents we must parse them and turn them > into a format > that can be manipulated. I think this is more difficult that the > storing and manipulating documents > problem. You'd also need support for full-text indexing, foreign > language and multiple character sets and so > on. Just a load of horrible messy small problems, but a significant > barrier to importing large amounts > of content into the system. > > You'd also need some quality control of the documents as they enter > the system (to avoid rubbish in rubbish out), also to maintain the > integrity of the documents. Again, for this problem space, it's more about building up complex documents from small pieces, than carving up pre-existing documents. More like the combination of an IDE and a distributed CVS - where fully "compiled" documents are the final output. > > If you have any ideas of now to get large volumes of data into the > system from proprietary formats > (like ms word) I'd like to hear about it. > Me too :-) Though, I go looking for such things every once in a while, and: - there are quite a few PDF to XML parsers, but mostly commercial ones - there are a few PDF and Word "RFP stripping" products floating around, that are smart enough to actually analyze the content of structured documents (check out Meridian) - later versions of Word export XML, albeit poor XML - there are quite a few document analysis packages floating around, including ones that start from OCR images - but they generally focus on content (lexical analyis) and ignore structure (it's easier to scan a document and extract some measure of what it's about - e.g. for indexing purposes; it's a lot harder to find something that will extract the outline structure of a document) Cheers, Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mahesh@REDACTED Mon Feb 17 21:42:31 2014 From: mahesh@REDACTED (Mahesh Paolini-Subramanya) Date: Mon, 17 Feb 2014 15:42:31 -0500 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: <53026F73.5080106@meetinghouse.net> References: <53021AC4.8080303@meetinghouse.net> <53026F73.5080106@meetinghouse.net> Message-ID: ?Large number of processes with very long persistence? You *will* run into GC issues here, and of all kinds ? ?- design artifacts (?hmm, the number of lists that I manipulate increases relentlessly??) ? ?- misunderstanding (?But I passed the binary on, without manipulating it at all!?) ? ?- Bugs (Fred has a great writeup on this somewhere) ? Just keep in mind that in the end, you will almost certainly end up doing some form of manual GC activities. ?Again, the Heroku gang can probably provide a whole bunch of pointers on this? chees Mahesh Paolini-Subramanya That tall bald Indian guy.. Google+? |?Blog?? |?Twitter? |?LinkedIn On February 17, 2014 at 3:22:22 PM, Miles Fidelman (mfidelman@REDACTED) wrote: Joe Armstrong wrote: > This sounds interesting. To start wit, I think swapping processes to > disk is just an optimization. > In theory you could just keep everything in RAM forever. I guess > processes could keep their state in dictionaries (so you could roll > them back) or ets tables (if you didn't want to roll them back). > > You would need some form of crash recovery so processes should write > some state information > to disk at suitable points in the program. Joe... can you offer any insight into the dynamics of Erlang, when running with large number of processes that have very long persistence? Somehow, it strikes me that 100,000 processes with 1MB of state, each running for years at a time, have a different dynamic than 100,000 processes, each representing a short-lived protocol transaction (say a web query). Coupled with a communications paradigm for identifying a group of processes and sending each of them the same message (e.g., 5000 people have a copy of a book, send all 5000 of them a set of errata; or send a message asking 'who has updates for section 3.2). In some sense, the conceptual model is: 1. I send you an empty notebook. 2. The notebook has an address and a bunch of message handling routines 3. I can send a page to the notebook, and the notebook inserts the page. 4. You can interact with the notebook - read it, annotate it, edit certain sections - if you make updates, the notebook can distribute updates to other copies - either through a P2P mechanism or a publish-subscribe mechanism. At a basic level, this maps really well onto the Actor formalism - every notebook is an actor, with it's own address. Updates, interactions, queries, etc. are simply messages. Since Erlang is about the only serious implementation of the Actor formalism, I'm trying to poke at the edge cases - particularly around long-lived actors. And who better to ask than you :-) In passing: Early versions of Smalltalk were actor-like, encapsulating state, methods, and process - but process kind of got dropped along the way. By contrast, it strikes me that Erlang focuses on everything being a process, and long-term persistence of state has taken a back seat. I'm trying to probe the edge cases. (I guess another way of looking at this is: to what extent is Erlang workable for writing systems based around the mobile agent paradigm?) > > What I think is a more serious problem is getting data into the system > in the first place. > I have done some experiments with document commenting and annotation > systems and > found it very difficult to convert things like word documents into a > form that looks half > decent in a user interface. Haven't actually thought a lot about that part of the problem. I'm thinking of documents that are more form-like in nature, or at least built up from smaller components - so it's not so much going from Word to an internal format, as much as starting with XML or JSON (or tuples), building up structure, and then adding presentation at the final step. XML -> Word is a lot easier than the reverse :-) On the other hand, I do have a bunch of applications in mind where parsing Word and/or PDF would be very helpful - notably stripping requirements out of specifications. (I can't tell you how much of my time I spend manually cutting and pasting from specifications into spreadsheets - for requirements tracking and such.) Again, presentation isn't that much of an issue - structural and semantic analysis is. But, while important, that's a separate set of problems - and there are some commercial products that do a reasonably good job. > I want to parse Microsoft word files and PDF etc. and display them in > a format that is > recognisable and not too abhorrent to the user. I also want to allow > on-screen manipulation of > documents (in a browser) - all of this seems to require a mess of > Javascript (in the browser)and a mess of parsing programs inn the server. > > Before we can manipulate documents we must parse them and turn them > into a format > that can be manipulated. I think this is more difficult that the > storing and manipulating documents > problem. You'd also need support for full-text indexing, foreign > language and multiple character sets and so > on. Just a load of horrible messy small problems, but a significant > barrier to importing large amounts > of content into the system. > > You'd also need some quality control of the documents as they enter > the system (to avoid rubbish in rubbish out), also to maintain the > integrity of the documents. Again, for this problem space, it's more about building up complex documents from small pieces, than carving up pre-existing documents. More like the combination of an IDE and a distributed CVS - where fully "compiled" documents are the final output. > > If you have any ideas of now to get large volumes of data into the > system from proprietary formats > (like ms word) I'd like to hear about it. > Me too :-) Though, I go looking for such things every once in a while, and: - there are quite a few PDF to XML parsers, but mostly commercial ones - there are a few PDF and Word "RFP stripping" products floating around, that are smart enough to actually analyze the content of structured documents (check out Meridian) - later versions of Word export XML, albeit poor XML - there are quite a few document analysis packages floating around, including ones that start from OCR images - but they generally focus on content (lexical analyis) and ignore structure (it's easier to scan a document and extract some measure of what it's about - e.g. for indexing purposes; it's a lot harder to find something that will extract the outline structure of a document) Cheers, Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarimatti.valkonen@REDACTED Mon Feb 17 21:36:36 2014 From: jarimatti.valkonen@REDACTED (Jarimatti Valkonen) Date: Mon, 17 Feb 2014 22:36:36 +0200 Subject: [erlang-questions] let it crash erlang/ada [[was: Time for OTP to be Renamed?] In-Reply-To: References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFEAC6.50308@gmail.com> <5300CF44.8050206@meetinghouse.net> <53012965.5030001@meetinghouse.net> <5302009E.2040507@meetinghouse.net> <53020420.7030607@meetinghouse.net> Message-ID: <1D23F105-68E1-4992-A8C4-1563E5797D65@saunalahti.fi> Cian Synnott kirjoitti 17.2.2014 kello 16.16: > On Mon, Feb 17, 2014 at 12:44 PM, Miles Fidelman > wrote: >> More copies of the same hardware/software just means more copies of any >> bugs! >> > A famous direct example of this was the Ariane 5 disaster in 1996: > > "When the guidance system shut down, it passed control to an > identical, redundant unit, which was there to provide backup in case > of just such a failure. But the second unit had failed in the > identical manner a few milliseconds before. And why not? It was > running the same software." > > http://www.around.com/ariane.html Apologies, this is a bit off topic. On the other hand, having heterogenous implementations does not protect from invalid specifications or lack of proper testing. AFAIK the SRI used (from Ariane 4) worked exactly as specified, for Ariane 4. Too bad that the Ariane 5 has a different trajectory. So having different implementations with Ariane 4 specs in Ariane 5 would have also failed. http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html "o) In Ariane 4 flights using the same type of inertial reference system there has been no such failure because the trajectory during the first 40 seconds of flight is such that the particular variable related to horizontal velocity cannot reach, with an adequate operational margin, a value beyond the limit present in the software. p) Ariane 5 has a high initial acceleration and a trajectory which leads to a build-up of horizontal velocity which is five times more rapid than for Ariane 4. The higher horizontal velocity of Ariane 5 generated, within the 40-second timeframe, the excessive value which caused the inertial system computers to cease operation. q) The purpose of the review process, which involves all major partners in the Ariane 5 programme, is to validate design decisions and to obtain flight qualification. In this process, the limitations of the alignment software were not fully analysed and the possible implications of allowing it to continue to function during flight were not realised. r) The specification of the inertial reference system and the tests performed at equipment level did not specifically include the Ariane 5 trajectory data. Consequently the realignment function was not tested under simulated Ariane 5 flight conditions, and the design error was not discovered." br, Jarimatti From mfidelman@REDACTED Mon Feb 17 22:05:42 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 17 Feb 2014 16:05:42 -0500 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: References: <53021AC4.8080303@meetinghouse.net> <53024F1C.4060507@meetinghouse.net> Message-ID: <530279A6.2050206@meetinghouse.net> Ahh... thanks! Now I know what to look for as a start perusing the riak_core architectural documents. Re. a couple of your other points: Michael Radford wrote: > I was addressing exactly your second point: backing up and restoring actors. > > Since you brought up that point, it didn't sound like an "actor" in > your model is 1-1 with an Erlang process for all time. So OK, you can > checkpoint them and restart them. But what if you want the "actor" to > continue to "respond to messages" when any single machine crashes? > Maybe multiple Erlang processes on multiple machines can coordinate to > provide a highly available representation of your per-document actor. In some sense, I keep coming back to the model of paper documents - but just a little bit "smarter." - I have a copy of the same document at the office, at home, in my briefcase, someone else has a copy - updates can be distributed via copy machine and mail - with paper, if one of them gets lost or stolen, there are other copies, but you lose marginal notes - add a little "intelligence" and now copies can be synced (a la what we do with our smart phones and laptops) - with the sync logic embedded in the document rather than the environment (which is makes the actor-like rather than simply files or object-like) - which does address one approach to backup - things are mirrored, if a node crashes, there are other copies around, it's easy to restore state (the only time things get lost is if one is running disconnected and things crash) -- though it becomes pretty inefficient if the power fails, or you want to reboot the machine, or what have you > > For the same reason, it sounds like you need reliable messaging, so > that a locally-triggered change isn't lost if a machine crashes. So > you may need to persist the update messages in multiple places. I'm thinking that this is embedded in publish subscribe channels, with logs/archives. I keep coming back to a USENET/NNTP model for both messaging and replication. > > Finally, you also mentioned "copies of documents" with "local changes" > triggering changes in other copies of the documents. What if the > locally-triggered changes conflict? For this, I'm thinking that each document has an embedded change control system. Akin to having one's own copy of a git repository. (The Fossil distributed version control system is a really nice model for this.) > > For example, a budget with a total, where any user can add or remove > line items. To compute the current total, you need rules for resolving > conflicting additions and removals of the same line item. Since you > mentioned that these changes are "local" and you're sending messages > among the document actors, it sounded like you had something like this > in mind. Exactly. Which is one of the things that leads me to the actor model - embed the rules directly in each copy of the document, rather than in external logic. > > If any of these things are a concern for your application, I thought > you might find the ideas behind riak-core helpful at least. Thanks! I'm going off to look now! -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mononcqc@REDACTED Mon Feb 17 22:11:05 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 17 Feb 2014 16:11:05 -0500 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: References: <53021AC4.8080303@meetinghouse.net> <53026F73.5080106@meetinghouse.net> Message-ID: <20140217211104.GL589@ferdmbp.local> On 02/17, Mahesh Paolini-Subramanya wrote: > ? ?- Bugs (Fred has a great writeup on this somewhere) > ? > Just keep in mind that in the end, you will almost certainly end up doing some form of manual GC activities. ?Again, the Heroku gang can probably provide a whole bunch of pointers on this? > That would probably be the blog post on my investigations and optimizations in Logplex: https://blog.heroku.com/archives/2013/11/7/logplex-down-the-rabbit-hole Chess, Fred. From mjtruog@REDACTED Mon Feb 17 22:14:44 2014 From: mjtruog@REDACTED (Michael Truog) Date: Mon, 17 Feb 2014 13:14:44 -0800 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: References: <53021AC4.8080303@meetinghouse.net> <53026F73.5080106@meetinghouse.net> Message-ID: <53027BC4.7000203@gmail.com> You then have the choice of trying to tweak the GC with parameters to try and avoid consuming too much memory, but that only works if your throughput stays roughly the same (within what you expect), otherwise you then have to play with the GC settings again, based on a new throughput max... or, you can use a short-lived process to manipulate memory, such that the result is returned upon the short-lived process' death (the third option would be manually making garbage collection happen, which is dirty, but possible with http://www.erlang.org/doc/man/erlang.html#garbage_collect-0). So, using short-lived processes to facilitate the work of longer-lived processes is generally the solution to this problem. Making an Erlang process is cheap, and using a short-lived process to help the GC know what memory is old, is a simple way of handling the problem. If you use CloudI, the cloudi_service behaviour does this for you by default, when you receive service requests, with the request_pid_uses service configuration option (http://cloudi.org/api.html#2_services_add_config_opts)... so it is part of CloudI's service abstraction. On 02/17/2014 12:42 PM, Mahesh Paolini-Subramanya wrote: > "Large number of processes with very long persistence" > > You *will* run into GC issues here, and of all kinds > - design artifacts ("hmm, the number of lists that I manipulate increases relentlessly...") > - misunderstanding ("But I passed the binary on, without manipulating it at all!") > - Bugs (Fred has a great writeup on this somewhere) > Just keep in mind that in the end, you will almost certainly end up doing some form of manual GC activities. Again, the Heroku gang can probably provide a whole bunch of pointers on this... > > chees > * > *Mahesh Paolini-Subramanya * > That tall bald Indian guy.. > * > * > Google+ | Blog | Twitter | LinkedIn > * > > On February 17, 2014 at 3:22:22 PM, Miles Fidelman (mfidelman@REDACTED ) wrote: > >> Joe Armstrong wrote: >> > This sounds interesting. To start wit, I think swapping processes to >> > disk is just an optimization. >> > In theory you could just keep everything in RAM forever. I guess >> > processes could keep their state in dictionaries (so you could roll >> > them back) or ets tables (if you didn't want to roll them back). >> > >> > You would need some form of crash recovery so processes should write >> > some state information >> > to disk at suitable points in the program. >> >> Joe... can you offer any insight into the dynamics of Erlang, when >> running with large number of processes that have very long persistence? >> Somehow, it strikes me that 100,000 processes with 1MB of state, each >> running for years at a time, have a different dynamic than 100,000 >> processes, each representing a short-lived protocol transaction (say a >> web query). >> >> Coupled with a communications paradigm for identifying a group of >> processes and sending each of them the same message (e.g., 5000 people >> have a copy of a book, send all 5000 of them a set of errata; or send a >> message asking 'who has updates for section 3.2). >> >> In some sense, the conceptual model is: >> 1. I send you an empty notebook. >> 2. The notebook has an address and a bunch of message handling routines >> 3. I can send a page to the notebook, and the notebook inserts the page. >> 4. You can interact with the notebook - read it, annotate it, edit >> certain sections - if you make updates, the notebook can distribute >> updates to other copies - either through a P2P mechanism or a >> publish-subscribe mechanism. >> >> At a basic level, this maps really well onto the Actor formalism - every >> notebook is an actor, with it's own address. Updates, interactions, >> queries, etc. are simply messages. >> >> Since Erlang is about the only serious implementation of the Actor >> formalism, I'm trying to poke at the edge cases - particularly around >> long-lived actors. And who better to ask than you :-) >> >> In passing: Early versions of Smalltalk were actor-like, encapsulating >> state, methods, and process - but process kind of got dropped along the >> way. By contrast, it strikes me that Erlang focuses on everything being >> a process, and long-term persistence of state has taken a back seat. >> I'm trying to probe the edge cases. (I guess another way of looking at >> this is: to what extent is Erlang workable for writing systems based >> around the mobile agent paradigm?) >> >> >> >> > >> > What I think is a more serious problem is getting data into the system >> > in the first place. >> > I have done some experiments with document commenting and annotation >> > systems and >> > found it very difficult to convert things like word documents into a >> > form that looks half >> > decent in a user interface. >> >> Haven't actually thought a lot about that part of the problem. I'm >> thinking of documents that are more form-like in nature, or at least >> built up from smaller components - so it's not so much going from Word >> to an internal format, as much as starting with XML or JSON (or tuples), >> building up structure, and then adding presentation at the final step. >> XML -> Word is a lot easier than the reverse :-) >> >> On the other hand, I do have a bunch of applications in mind where >> parsing Word and/or PDF would be very helpful - notably stripping >> requirements out of specifications. (I can't tell you how much of my >> time I spend manually cutting and pasting from specifications into >> spreadsheets - for requirements tracking and such.) Again, presentation >> isn't that much of an issue - structural and semantic analysis is. But, >> while important, that's a separate set of problems - and there are some >> commercial products that do a reasonably good job. >> >> > I want to parse Microsoft word files and PDF etc. and display them in >> > a format that is >> > recognisable and not too abhorrent to the user. I also want to allow >> > on-screen manipulation of >> > documents (in a browser) - all of this seems to require a mess of >> > Javascript (in the browser)and a mess of parsing programs inn the server. >> > >> > Before we can manipulate documents we must parse them and turn them >> > into a format >> > that can be manipulated. I think this is more difficult that the >> > storing and manipulating documents >> > problem. You'd also need support for full-text indexing, foreign >> > language and multiple character sets and so >> > on. Just a load of horrible messy small problems, but a significant >> > barrier to importing large amounts >> > of content into the system. >> > >> > You'd also need some quality control of the documents as they enter >> > the system (to avoid rubbish in rubbish out), also to maintain the >> > integrity of the documents. >> >> Again, for this problem space, it's more about building up complex >> documents from small pieces, than carving up pre-existing documents. >> More like the combination of an IDE and a distributed CVS - where fully >> "compiled" documents are the final output. >> >> > >> > If you have any ideas of now to get large volumes of data into the >> > system from proprietary formats >> > (like ms word) I'd like to hear about it. >> > >> >> Me too :-) Though, I go looking for such things every once in a while, and: >> - there are quite a few PDF to XML parsers, but mostly commercial ones >> - there are a few PDF and Word "RFP stripping" products floating around, >> that are smart enough to actually analyze the content of structured >> documents (check out Meridian) >> - later versions of Word export XML, albeit poor XML >> - there are quite a few document analysis packages floating around, >> including ones that start from OCR images - but they generally focus on >> content (lexical analyis) and ignore structure (it's easier to scan a >> document and extract some measure of what it's about - e.g. for indexing >> purposes; it's a lot harder to find something that will extract the >> outline structure of a document) >> >> >> Cheers, >> >> Miles >> >> >> -- >> In theory, there is no difference between theory and practice. >> In practice, there is. .... Yogi Berra >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > 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 Mon Feb 17 22:22:01 2014 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 17 Feb 2014 22:22:01 +0100 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: <53026F73.5080106@meetinghouse.net> References: <53021AC4.8080303@meetinghouse.net> <53026F73.5080106@meetinghouse.net> Message-ID: On Mon, Feb 17, 2014 at 9:22 PM, Miles Fidelman wrote: > Joe Armstrong wrote: > >> This sounds interesting. To start wit, I think swapping processes to >> disk is just an optimization. >> In theory you could just keep everything in RAM forever. I guess >> processes could keep their state in dictionaries (so you could roll them >> back) or ets tables (if you didn't want to roll them back). >> >> You would need some form of crash recovery so processes should write some >> state information >> to disk at suitable points in the program. >> > > Joe... can you offer any insight into the dynamics of Erlang, when > running with large number of processes that have very long persistence? > Somehow, it strikes me that 100,000 processes with 1MB of state, each > running for years at a time, have a different dynamic than 100,000 > processes, each representing a short-lived protocol transaction (say a web > query). > T > > Coupled with a communications paradigm for identifying a group of > processes and sending each of them the same message (e.g., 5000 people have > a copy of a book, send all 5000 of them a set of errata; or send a message > asking 'who has updates for section 3.2). > > In some sense, the conceptual model is: > 1. I send you an empty notebook. > 2. The notebook has an address and a bunch of message handling routines > 3. I can send a page to the notebook, and the notebook inserts the page. > 4. You can interact with the notebook - read it, annotate it, edit certain > sections - if you make updates, the notebook can distribute updates to > other copies - either through a P2P mechanism or a publish-subscribe > mechanism. > > At a basic level, this maps really well onto the Actor formalism - every > notebook is an actor, with it's own address. Updates, interactions, > queries, etc. are simply messages. > > Since Erlang is about the only serious implementation of the Actor > formalism, I'm trying to poke at the edge cases - particularly around > long-lived actors. And who better to ask than you :-) > > In passing: Early versions of Smalltalk were actor-like, encapsulating > state, methods, and process - but process kind of got dropped along the > way. By contrast, it strikes me that Erlang focuses on everything being a > process, and long-term persistence of state has taken a back seat. I'm > trying to probe the edge cases. (I guess another way of looking at this is: > to what extent is Erlang workable for writing systems based around the > mobile agent paradigm?) > > > > > >> What I think is a more serious problem is getting data into the system in >> the first place. >> I have done some experiments with document commenting and annotation >> systems and >> found it very difficult to convert things like word documents into a form >> that looks half >> decent in a user interface. >> > > Haven't actually thought a lot about that part of the problem. I'm > thinking of documents that are more form-like in nature, or at least built > up from smaller components - so it's not so much going from Word to an > internal format, as much as starting with XML or JSON (or tuples), building > up structure, and then adding presentation at the final step. XML -> Word > is a lot easier than the reverse :-) > > On the other hand, I do have a bunch of applications in mind where parsing > Word and/or PDF would be very helpful - notably stripping requirements out > of specifications. (I can't tell you how much of my time I spend manually > cutting and pasting from specifications into spreadsheets - for > requirements tracking and such.) Again, presentation isn't that much of an > issue - structural and semantic analysis is. But, while important, that's > a separate set of problems - and there are some commercial products that do > a reasonably good job. > > > I want to parse Microsoft word files and PDF etc. and display them in a >> format that is >> recognisable and not too abhorrent to the user. I also want to allow >> on-screen manipulation of >> documents (in a browser) - all of this seems to require a mess of >> Javascript (in the browser)and a mess of parsing programs inn the server. >> >> Before we can manipulate documents we must parse them and turn them into >> a format >> that can be manipulated. I think this is more difficult that the storing >> and manipulating documents >> problem. You'd also need support for full-text indexing, foreign language >> and multiple character sets and so >> on. Just a load of horrible messy small problems, but a significant >> barrier to importing large amounts >> of content into the system. >> >> You'd also need some quality control of the documents as they enter the >> system (to avoid rubbish in rubbish out), also to maintain the integrity of >> the documents. >> > > Again, for this problem space, it's more about building up complex > documents from small pieces, than carving up pre-existing documents. More > like the combination of an IDE and a distributed CVS - where fully > "compiled" documents are the final output. > > > >> If you have any ideas of now to get large volumes of data into the system >> from proprietary formats >> (like ms word) I'd like to hear about it. >> >> > Me too :-) Though, I go looking for such things every once in a while, > and: > - there are quite a few PDF to XML parsers, but mostly commercial ones > - there are a few PDF and Word "RFP stripping" products floating around, > that are smart enough to actually analyze the content of structured > documents (check out Meridian) > - later versions of Word export XML, albeit poor XML > - there are quite a few document analysis packages floating around, > including ones that start from OCR images - but they generally focus on > content (lexical analyis) and ignore structure (it's easier to scan a > document and extract some measure of what it's about - e.g. for indexing > purposes; it's a lot harder to find something that will extract the outline > structure of a document) > > > Cheers, > > Miles > > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Mon Feb 17 22:40:07 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 17 Feb 2014 16:40:07 -0500 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: References: <53021AC4.8080303@meetinghouse.net> <53026F73.5080106@meetinghouse.net> Message-ID: <530281B7.6060807@meetinghouse.net> Mahesh, Mahesh Paolini-Subramanya wrote: > ?Large number of processes with very long persistence? > > You *will* run into GC issues here, and of all kinds > - design artifacts (?hmm, the number of lists that I manipulate > increases relentlessly??) > - misunderstanding (?But I passed the binary on, without > manipulating it at all!?) > - Bugs (Fred has a great writeup on this somewhere) Very good points - though to a degree they sound more like dependency hell than traditional garbage collection to reclaim memory. Given the document-oriented view, I'm viewing garbage collection more in the sense of filing and archiving - the same way that paper documents migrate to filerooms then to archives; or email and computer files simply get buried deeper and deeper in one's file system; sometimes you buy a larger drive; sometimes stuff migrates to off-site backup - but you generally don't throw stuff away (though when working on multi-author documents, one always comes back to how many intermediate copies to retain "for the record" after the final version goes to print). In one sense, this ends up looking a lot like managing a git repository - more and more versions and branches accumulate, and so forth. And once starts thinking about storing only change logs. This is also what motivates my question about how to handle older, largely inactive processes. It's one thing to bury a file deeper and deeper in a file system - and still be able to find and access it (and these days, search for it). It's another to think about migrating an actor from RAM to disk, in a way that retains its ability to respond to the infrequent message. The other area I worry about is exponential growth in network traffic and cpu cycles - assuming that a lot of documents will never completely "die" - maybe an update will come in once week, or once a month, or they'll get searched every once in a while - as the number of processes increases, the amount of traffic will as well. > Just keep in mind that in the end, you will almost certainly end up > doing some form of manual GC activities. Again, the Heroku gang can > probably provide a whole bunch of pointers on this? > Can you say a bit more about what it is about Heroku that I should be looking at? At first glance, it seems like a very different environment than what we're talking about here (or are you thinking about manual housekeeping for the virtual environment?). And.. re. "Bugs (Fred has a great writeup on this somewhere)" - Fred who? (Maybe I can find it by googling!) Thanks Very Much, Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From erlang@REDACTED Mon Feb 17 22:46:33 2014 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 17 Feb 2014 22:46:33 +0100 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: <53026F73.5080106@meetinghouse.net> References: <53021AC4.8080303@meetinghouse.net> <53026F73.5080106@meetinghouse.net> Message-ID: On Mon, Feb 17, 2014 at 9:22 PM, Miles Fidelman wrote: > Joe Armstrong wrote: > >> This sounds interesting. To start wit, I think swapping processes to >> disk is just an optimization. >> In theory you could just keep everything in RAM forever. I guess >> processes could keep their state in dictionaries (so you could roll them >> back) or ets tables (if you didn't want to roll them back). >> >> You would need some form of crash recovery so processes should write some >> state information >> to disk at suitable points in the program. >> > > Joe... can you offer any insight into the dynamics of Erlang, when > running with large number of processes that have very long persistence? No - this area has not to my knowledge been investigated. The "use lots of processes" or "as many processes as necessary" has an implicit assumption that a) the processes are not very large and b) not very long lived. At the back of my mind I'm thinking of a) as "a few hundred KB resident size" and b) a few seconds to minutes. I'm *not* thinking MBs and years. The latter requirements fit into our "telecoms domain" - a few thousands to tens of thousands of computations living for "the length of a telephone call" ie (max) hours but not years. Some kind of "getting things out of memory and onto disk when not needed" layer is needed for your problem, > Somehow, it strikes me that 100,000 processes with 1MB of state, each > running for years at a time, have a different dynamic than 100,000 > processes, each representing a short-lived protocol transaction (say a web > query). > My first comment is, thanks for providing some numbers :-) I keep saying time and time again, don't ask questions without numbers. 100K processes with 1MB of state = 10^11 bytes so you'd need a really big machine to do this. Assuming say 8GB of memory and 1MB of state you'd have an upper limit of 8K processes. This assumes a regular spinning disk. I guess if you have a big SSD the story changes. So you either have to reduce the size of the state, or the number of processes. The state can (I suppose) be partitioned into a (small) index and a (larger) content. So I'd keep the index in memory and the content on disk (or cached). > > Coupled with a communications paradigm for identifying a group of > processes and sending each of them the same message (e.g., 5000 people have > a copy of a book, send all 5000 of them a set of errata; or send a message > asking 'who has updates for section 3.2). > Hopefully all 5000 people will not want the errata at the same time > > In some sense, the conceptual model is: > 1. I send you an empty notebook. > 2. The notebook has an address and a bunch of message handling routines > 3. I can send a page to the notebook, and the notebook inserts the page. > 4. You can interact with the notebook - read it, annotate it, edit certain > sections - if you make updates, the notebook can distribute updates to > other copies - either through a P2P mechanism or a publish-subscribe > mechanism. > > At a basic level, this maps really well onto the Actor formalism - every > notebook is an actor, with it's own address. Updates, interactions, > queries, etc. are simply messages. > > Since Erlang is about the only serious implementation of the Actor > formalism, I'm trying to poke at the edge cases - particularly around > long-lived actors. And who better to ask than you :-) > It's a very good question. I like questions that poke around at the edges of what is possible :-) > > In passing: Early versions of Smalltalk were actor-like, encapsulating > state, methods, and process - but process kind of got dropped along the > way. By contrast, it strikes me that Erlang focuses on everything being a > process, and long-term persistence of state has taken a back seat. Yes - I guess the real solution would be to change the scheduler to swap processes to disk after they had waited for more than (say) 10 minutes for a message, and resurrect them when they are sent a message. The idea that they might be swapped out for years hadn't occurred to me. > I'm trying to probe the edge cases. (I guess another way of looking at > this is: to what extent is Erlang workable for writing systems based around > the mobile agent paradigm?) Pass - at the moment you'd have to implement you own object layer to do this . I guess you could do this yourself by making send and receive library routines and making the state of a process explicit rather than implicit, then slicking everything into a large store (like riak). If you cache the active processes in memory this might behave well enough. > > > > >> What I think is a more serious problem is getting data into the system in >> the first place. >> I have done some experiments with document commenting and annotation >> systems and >> found it very difficult to convert things like word documents into a form >> that looks half >> decent in a user interface. >> > > Haven't actually thought a lot about that part of the problem. I'm > thinking of documents that are more form-like in nature, or at least built > up from smaller components - so it's not so much going from Word to an > internal format, as much as starting with XML or JSON (or tuples), building > up structure, and then adding presentation at the final step. XML -> Word > is a lot easier than the reverse :-) > > On the other hand, I do have a bunch of applications in mind where parsing > Word and/or PDF would be very helpful - notably stripping requirements out > of specifications. (I can't tell you how much of my time I spend manually > cutting and pasting from specifications into spreadsheets - for > requirements tracking and such.) Again, presentation isn't that much of an > issue - structural and semantic analysis is. But, while important, that's > a separate set of problems - and there are some commercial products that do > a reasonably good job. > > > I want to parse Microsoft word files and PDF etc. and display them in a >> format that is >> recognisable and not too abhorrent to the user. I also want to allow >> on-screen manipulation of >> documents (in a browser) - all of this seems to require a mess of >> Javascript (in the browser)and a mess of parsing programs inn the server. >> >> Before we can manipulate documents we must parse them and turn them into >> a format >> that can be manipulated. I think this is more difficult that the storing >> and manipulating documents >> problem. You'd also need support for full-text indexing, foreign language >> and multiple character sets and so >> on. Just a load of horrible messy small problems, but a significant >> barrier to importing large amounts >> of content into the system. >> >> You'd also need some quality control of the documents as they enter the >> system (to avoid rubbish in rubbish out), also to maintain the integrity of >> the documents. >> > > Again, for this problem space, it's more about building up complex > documents from small pieces, than carving up pre-existing documents. More > like the combination of an IDE and a distributed CVS - where fully > "compiled" documents are the final output. > > > >> If you have any ideas of now to get large volumes of data into the system >> from proprietary formats >> (like ms word) I'd like to hear about it. >> >> > Me too :-) Though, I go looking for such things every once in a while, > and: > - there are quite a few PDF to XML parsers, but mostly commercial ones > Suck - then you have to buy them to find out if they are any good > - there are a few PDF and Word "RFP stripping" products floating around, > that are smart enough to actually analyze the content of structured > documents (check out Meridian) > > - later versions of Word export XML, albeit poor XML > Which sucks > - there are quite a few document analysis packages floating around, > including ones that start from OCR images - but they generally focus on > content (lexical analyis) and ignore structure (it's easier to scan a > document and extract some measure of what it's about - e.g. for indexing > purposes; it's a lot harder to find something that will extract the outline > structure of a document) > > > Cheers, > > Miles > > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahesh@REDACTED Mon Feb 17 23:03:09 2014 From: mahesh@REDACTED (Mahesh Paolini-Subramanya) Date: Mon, 17 Feb 2014 17:03:09 -0500 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: <530281B7.6060807@meetinghouse.net> References: <53021AC4.8080303@meetinghouse.net> <53026F73.5080106@meetinghouse.net> <530281B7.6060807@meetinghouse.net> Message-ID: ?How to handle older largely inactive processes? ?What we do (did?) was to basically flush/hibernate the process. ?To generalize, if the process hasn?t ?done? anything in a while, save its state somewhere, and then hibernate (which has the added benefit of dealing with GC issues :-)? Mind you, there is a wealth of info buried in the phrase ?save its state somewhere?. ?This really, really?depends ?on how big, how scalable, how fault-tolerant, how geographic, how?.. you intend on getting. In short, it can range from ?write out a text file? to ?pay Riak gobs-o-money and have nodes worldwide?. YMMV ?Heroku gang? ?Large number of processes with very long persistence? > > You *will* run into GC issues here, and of all kinds > - design artifacts (?hmm, the number of lists that I manipulate > increases relentlessly??) > - misunderstanding (?But I passed the binary on, without > manipulating it at all!?) > - Bugs (Fred has a great writeup on this somewhere) Very good points - though to a degree they sound more like dependency hell than traditional garbage collection to reclaim memory. Given the document-oriented view, I'm viewing garbage collection more in the sense of filing and archiving - the same way that paper documents migrate to filerooms then to archives; or email and computer files simply get buried deeper and deeper in one's file system; sometimes you buy a larger drive; sometimes stuff migrates to off-site backup - but you generally don't throw stuff away (though when working on multi-author documents, one always comes back to how many intermediate copies to retain "for the record" after the final version goes to print). In one sense, this ends up looking a lot like managing a git repository - more and more versions and branches accumulate, and so forth. And once starts thinking about storing only change logs. This is also what motivates my question about how to handle older, largely inactive processes. It's one thing to bury a file deeper and deeper in a file system - and still be able to find and access it (and these days, search for it). It's another to think about migrating an actor from RAM to disk, in a way that retains its ability to respond to the infrequent message. The other area I worry about is exponential growth in network traffic and cpu cycles - assuming that a lot of documents will never completely "die" - maybe an update will come in once week, or once a month, or they'll get searched every once in a while - as the number of processes increases, the amount of traffic will as well. > Just keep in mind that in the end, you will almost certainly end up > doing some form of manual GC activities. Again, the Heroku gang can > probably provide a whole bunch of pointers on this? > Can you say a bit more about what it is about Heroku that I should be looking at? At first glance, it seems like a very different environment than what we're talking about here (or are you thinking about manual housekeeping for the virtual environment?). And.. re. "Bugs (Fred has a great writeup on this somewhere)" - Fred who? (Maybe I can find it by googling!) Thanks Very Much, Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Mon Feb 17 23:08:54 2014 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Mon, 17 Feb 2014 23:08:54 +0100 Subject: [erlang-questions] stdapp.mk - yet another Makefile for Erlang apps Message-ID: <53028876.5010004@gmail.com> I recently gave our build system a complete overhaul, and in the process created a generic GNU Makefile for building Erlang applications. (Yes, I took a quick look at erlang.mk, but it does a lot of stuff that we don't currently need, and doesn't do certain things we did need.) https://github.com/richcarl/stdapp.mk It currently only has rules for building, not for making releases or fetching application dependencies. We build some 200+ applications using this file (driven from a top-level Makefile). Only 10-15% of those apps need any additional build rules. External apps that we build include lager, nitrogen_core, yaws, erlguten and many other. Design goals have been to keep it straightforward, avoiding too much use of GNU magic and trying to make it possible to reuse at least parts of it with a non-GNU make. It currently needs gawk, though. MIT License, so feel free to use as-is or rip out whatever parts you may find useful. Feedback/improvements welcome. /Richard From g@REDACTED Mon Feb 17 23:15:39 2014 From: g@REDACTED (Garrett Smith) Date: Mon, 17 Feb 2014 16:15:39 -0600 Subject: [erlang-questions] stdapp.mk - yet another Makefile for Erlang apps In-Reply-To: <53028876.5010004@gmail.com> References: <53028876.5010004@gmail.com> Message-ID: Can we do an EUC or San Fran sprint-to-unite-all-Erlang-makefiles? On Mon, Feb 17, 2014 at 4:08 PM, Richard Carlsson wrote: > I recently gave our build system a complete overhaul, and in the process > created a generic GNU Makefile for building Erlang applications. (Yes, I > took a quick look at erlang.mk, but it does a lot of stuff that we don't > currently need, and doesn't do certain things we did need.) > > https://github.com/richcarl/stdapp.mk > > It currently only has rules for building, not for making releases or > fetching application dependencies. > > We build some 200+ applications using this file (driven from a top-level > Makefile). Only 10-15% of those apps need any additional build rules. > External apps that we build include lager, nitrogen_core, yaws, erlguten and > many other. > > Design goals have been to keep it straightforward, avoiding too much use of > GNU magic and trying to make it possible to reuse at least parts of it with > a non-GNU make. It currently needs gawk, though. > > MIT License, so feel free to use as-is or rip out whatever parts you may > find useful. Feedback/improvements welcome. > > /Richard > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From mallen@REDACTED Mon Feb 17 23:19:26 2014 From: mallen@REDACTED (Mark Allen) Date: Mon, 17 Feb 2014 16:19:26 -0600 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <53018DE1.1090901@meetinghouse.net> <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> <53021D9F.7060605@meetinghouse.net> Message-ID: On 2/17/14 1:51 PM, "Vixo" wrote: >My suggestion would be a manifest file of Erlang terms at the root level >of a GitHub page (they will *all* be on GitHub) that can be polled and >turned into a static site. The logical thing to do would be combine thus >with the revived erldocs site IMHO (as I have said to Francesco) I love this idea. I'm going to give this a think and maybe implement a prototype to do some testing of how it works. Thanks! Sometimes yak shaving discussions are kind of awesome. Mark From g@REDACTED Mon Feb 17 23:21:53 2014 From: g@REDACTED (Garrett Smith) Date: Mon, 17 Feb 2014 16:21:53 -0600 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <53018DE1.1090901@meetinghouse.net> <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> <53021D9F.7060605@meetinghouse.net> Message-ID: On Mon, Feb 17, 2014 at 4:19 PM, Mark Allen wrote: > On 2/17/14 1:51 PM, "Vixo" wrote: >>My suggestion would be a manifest file of Erlang terms at the root level >>of a GitHub page (they will *all* be on GitHub) that can be polled and >>turned into a static site. The logical thing to do would be combine thus >>with the revived erldocs site IMHO (as I have said to Francesco) > > I love this idea. I'm going to give this a think and maybe implement a > prototype to do some testing of how it works. > > Thanks! Sometimes yak shaving discussions are kind of awesome. Does this require that all of github be crawled? Would a github based index make sense? Complete with a liberal pull request policy? From mfidelman@REDACTED Mon Feb 17 23:26:51 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 17 Feb 2014 17:26:51 -0500 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: References: <53021AC4.8080303@meetinghouse.net> <53026F73.5080106@meetinghouse.net> <530281B7.6060807@meetinghouse.net> Message-ID: <53028CAB.3030609@meetinghouse.net> Just spent some time reading Fred's blog post (thanks Fred), and googling "Erlang garbage collection" - interesting stuff, and now I much better understand the concerns you raise! A follow-up if I might: Mahesh Paolini-Subramanya wrote: > ?How to handle older largely inactive processes? > What we do (did?) was to basically flush/hibernate the process. To > generalize, if the process hasn?t ?done? anything in a while, save its > state somewhere, and then hibernate (which has the added benefit of > dealing with GC issues :-) > Mind you, there is a wealth of info buried in the phrase ?save its > state somewhere?. This really, /really/ depends on how big, how > scalable, how fault-tolerant, how geographic, how?.. you intend on > getting. In short, it can range from ?write out a text file? to ?pay > Riak gobs-o-money and have nodes worldwide?. YMMV Can you say more about this? Context in which you are flushing/hibernating processes - and how your're saving state? Cheers, Miles > > ?Heroku gang? Heroku who happen to be doing erlang? > > cheers > > * > *Mahesh Paolini-Subramanya > * > That tall bald Indian guy.. > * > * > Google+ | > Blog | Twitter > | LinkedIn > > * > > On February 17, 2014 at 4:40:22 PM, Miles Fidelman > (mfidelman@REDACTED ) wrote: > >> Mahesh, >> >> Mahesh Paolini-Subramanya wrote: >> > ?Large number of processes with very long persistence? >> > >> > You *will* run into GC issues here, and of all kinds >> > - design artifacts (?hmm, the number of lists that I manipulate >> > increases relentlessly??) >> > - misunderstanding (?But I passed the binary on, without >> > manipulating it at all!?) >> > - Bugs (Fred has a great writeup on this somewhere) >> >> Very good points - though to a degree they sound more like dependency >> hell than traditional garbage collection to reclaim memory. >> >> Given the document-oriented view, I'm viewing garbage collection more in >> the sense of filing and archiving - the same way that paper documents >> migrate to filerooms then to archives; or email and computer files >> simply get buried deeper and deeper in one's file system; sometimes you >> buy a larger drive; sometimes stuff migrates to off-site backup - but >> you generally don't throw stuff away (though when working on >> multi-author documents, one always comes back to how many intermediate >> copies to retain "for the record" after the final version goes to print). >> >> In one sense, this ends up looking a lot like managing a git repository >> - more and more versions and branches accumulate, and so forth. And >> once starts thinking about storing only change logs. >> >> This is also what motivates my question about how to handle older, >> largely inactive processes. It's one thing to bury a file deeper and >> deeper in a file system - and still be able to find and access it (and >> these days, search for it). It's another to think about migrating an >> actor from RAM to disk, in a way that retains its ability to respond to >> the infrequent message. >> >> The other area I worry about is exponential growth in network traffic >> and cpu cycles - assuming that a lot of documents will never completely >> "die" - maybe an update will come in once week, or once a month, or >> they'll get searched every once in a while - as the number of processes >> increases, the amount of traffic will as well. >> >> > Just keep in mind that in the end, you will almost certainly end up >> > doing some form of manual GC activities. Again, the Heroku gang can >> > probably provide a whole bunch of pointers on this? >> > >> >> Can you say a bit more about what it is about Heroku that I should be >> looking at? At first glance, it seems like a very different environment >> than what we're talking about here (or are you thinking about manual >> housekeeping for the virtual environment?). >> >> And.. re. "Bugs (Fred has a great writeup on this somewhere)" - Fred >> who? (Maybe I can find it by googling!) >> >> Thanks Very Much, >> >> Miles >> >> -- >> In theory, there is no difference between theory and practice. >> In practice, there is. .... Yogi Berra >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mallen@REDACTED Mon Feb 17 23:28:53 2014 From: mallen@REDACTED (Mark Allen) Date: Mon, 17 Feb 2014 16:28:53 -0600 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <53018DE1.1090901@meetinghouse.net> <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> <53021D9F.7060605@meetinghouse.net> Message-ID: On 2/17/14 4:21 PM, "Garrett Smith" wrote: >> On 2/17/14 1:51 PM, "Vixo" wrote: >>>My suggestion would be a manifest file of Erlang terms at the root level >>>of a GitHub page (they will *all* be on GitHub) that can be polled and >>>turned into a static site. The logical thing to do would be combine thus >>>with the revived erldocs site IMHO (as I have said to Francesco) >Does this require that all of github be crawled? No. I'm pretty sure we can segment the crawl to only projects with some X threshold of Erlang. (I'll have a slice without so much rat in it. [0]) >Would a github based index make sense? Complete with a liberal pull >request policy? Most likely, yes, using github pages with a nice custom domain would be a Good Thing for this type of project. The code to do the crawl and build the index should be open source too, imo. Mark [0]: http://en.wikiquote.org/wiki/Monty_Python's_Flying_Circus#The_Money_Program me_.5B3.03.5D From gordon@REDACTED Mon Feb 17 23:33:18 2014 From: gordon@REDACTED (Gordon Guthrie) Date: Mon, 17 Feb 2014 22:33:18 +0000 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <53018DE1.1090901@meetinghouse.net> <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> <53021D9F.7060605@meetinghouse.net> Message-ID: This is what I sent to Francesco **************************************************************************************** *Building The Erlang Community* *Background* Erlang has long lacked a solid community core to act as a place where users can discover existing modules and include them in their projects. *rebar *now provides the standard mechanism to include external dependencies - this proposal is about making erldocs the standard place to discover community contributions. *Proposal 1* The proposal is that people who publish open source Erlang modules on GitHub be able to have them listed on erldocs. The process would be two part: - commit a page called *ERLDOCS.terms* to github in the root next to *README.md* - submit the URL to a page on erldocs - erldocs would sook the github page into a community section The structure of the *ERLDOCS.terms* file is simple tagged tuples, something like: *{name, "Starling"}.* *{license, "EPL"}.* *{description, "Unicode support for Erlang"}.* *{details, "A C-Port wrapped around the ICU library for unicode"}.* *{status, "production"}. % alpha | beta | production* *{rebar, {version, "1"}, {starling, {git, "git://**github.com/hypernumbers/starling.git **","master"}}}.* *Proposal 2* Dale Harvey originally intended that erldocs should include the ability for members of the community to annotate the official documents with examples, links to tutorials etc, etc. erldocs be so extended (by use of Disqus or other standard commenting systems) *Requirements For Success* Erldocs 'failed' last time out because the OTP team changed the way documents were generated, and Dale Harvey moved on from an Erlang shop to Mozilla. In order for this to work Erlang Solutions has to commit to: - erldocs being the official community repository for Erlang documentation - linked to directly from *erlang.org * - production of these documents needs to be integrated into the OTP Team's release schedule *Modalities* If Erlang Solutions so agree the next stage would be to approach a number of suppliers of top-notch Erlang open source and sign them up for launch. My working list would be: - Erlang Solutions - Basho - Erlware - Mats Cronquist - Richard Carlsson - Yaws - Mochiweb - Nitrogen - Cowboy - Web Machine - Hypernumbers There would need to be consultation with the launch group regarding the structure and elements of the term file. Once they were onboard and the production cycle had been tested - an open launch on the mailing list. **************************************************************************************** The key point is that a community is only a real community if you choose to join it. I was 'joined' to the Agner community (and there have been other attempts, Erlware, CEAN, etc) but they don't stick. Gordon On 17 February 2014 22:28, Mark Allen wrote: > On 2/17/14 4:21 PM, "Garrett Smith" wrote: > >> On 2/17/14 1:51 PM, "Vixo" wrote: > >>>My suggestion would be a manifest file of Erlang terms at the root level > >>>of a GitHub page (they will *all* be on GitHub) that can be polled and > >>>turned into a static site. The logical thing to do would be combine thus > >>>with the revived erldocs site IMHO (as I have said to Francesco) > > >Does this require that all of github be crawled? > > No. I'm pretty sure we can segment the crawl to only projects with some X > threshold of Erlang. (I'll have a slice without so much rat in it. [0]) > > >Would a github based index make sense? Complete with a liberal pull > >request policy? > > Most likely, yes, using github pages with a nice custom domain would be a > Good Thing for this type of project. The code to do the crawl and build > the index should be open source too, imo. > > Mark > > [0]: > http://en.wikiquote.org/wiki/Monty_Python's_Flying_Circus#The_Money_Program > me_.5B3.03.5D > > -- --- Gordon Guthrie CEO vixo.com @gordonguthrie +44 (0) 7776 251669 (in Bonnie Scotland!) vixo is made in Scotland from electrons -------------- next part -------------- An HTML attachment was scrubbed... URL: From demeshchuk@REDACTED Mon Feb 17 23:53:24 2014 From: demeshchuk@REDACTED (Dmitry Demeshchuk) Date: Mon, 17 Feb 2014 14:53:24 -0800 Subject: [erlang-questions] stdapp.mk - yet another Makefile for Erlang apps In-Reply-To: References: <53028876.5010004@gmail.com> Message-ID: Lo?c mentioned he was working on specing out erlang.mk v1.0. Might be worth running such a sprint before he finishes :) On Mon, Feb 17, 2014 at 2:15 PM, Garrett Smith wrote: > Can we do an EUC or San Fran sprint-to-unite-all-Erlang-makefiles? > > On Mon, Feb 17, 2014 at 4:08 PM, Richard Carlsson > wrote: > > I recently gave our build system a complete overhaul, and in the process > > created a generic GNU Makefile for building Erlang applications. (Yes, I > > took a quick look at erlang.mk, but it does a lot of stuff that we don't > > currently need, and doesn't do certain things we did need.) > > > > https://github.com/richcarl/stdapp.mk > > > > It currently only has rules for building, not for making releases or > > fetching application dependencies. > > > > We build some 200+ applications using this file (driven from a top-level > > Makefile). Only 10-15% of those apps need any additional build rules. > > External apps that we build include lager, nitrogen_core, yaws, erlguten > and > > many other. > > > > Design goals have been to keep it straightforward, avoiding too much use > of > > GNU magic and trying to make it possible to reuse at least parts of it > with > > a non-GNU make. It currently needs gawk, though. > > > > MIT License, so feel free to use as-is or rip out whatever parts you may > > find useful. Feedback/improvements welcome. > > > > /Richard > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Best regards, Dmitry Demeshchuk -------------- next part -------------- An HTML attachment was scrubbed... URL: From g@REDACTED Mon Feb 17 23:56:03 2014 From: g@REDACTED (Garrett Smith) Date: Mon, 17 Feb 2014 16:56:03 -0600 Subject: [erlang-questions] stdapp.mk - yet another Makefile for Erlang apps In-Reply-To: References: <53028876.5010004@gmail.com> Message-ID: Oh, nothing will stop Lo?c. Nothing. The best we can hope for is minimal bruising after said sprint. On Mon, Feb 17, 2014 at 4:53 PM, Dmitry Demeshchuk wrote: > Lo?c mentioned he was working on specing out erlang.mk v1.0. Might be worth > running such a sprint before he finishes :) > > > On Mon, Feb 17, 2014 at 2:15 PM, Garrett Smith wrote: >> >> Can we do an EUC or San Fran sprint-to-unite-all-Erlang-makefiles? >> >> On Mon, Feb 17, 2014 at 4:08 PM, Richard Carlsson >> wrote: >> > I recently gave our build system a complete overhaul, and in the process >> > created a generic GNU Makefile for building Erlang applications. (Yes, I >> > took a quick look at erlang.mk, but it does a lot of stuff that we don't >> > currently need, and doesn't do certain things we did need.) >> > >> > https://github.com/richcarl/stdapp.mk >> > >> > It currently only has rules for building, not for making releases or >> > fetching application dependencies. >> > >> > We build some 200+ applications using this file (driven from a top-level >> > Makefile). Only 10-15% of those apps need any additional build rules. >> > External apps that we build include lager, nitrogen_core, yaws, erlguten >> > and >> > many other. >> > >> > Design goals have been to keep it straightforward, avoiding too much use >> > of >> > GNU magic and trying to make it possible to reuse at least parts of it >> > with >> > a non-GNU make. It currently needs gawk, though. >> > >> > MIT License, so feel free to use as-is or rip out whatever parts you may >> > find useful. Feedback/improvements welcome. >> > >> > /Richard >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > Best regards, > Dmitry Demeshchuk From essen@REDACTED Tue Feb 18 00:00:00 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 18 Feb 2014 00:00:00 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <53018DE1.1090901@meetinghouse.net> <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> <53021D9F.7060605@meetinghouse.net> Message-ID: <53029470.8020702@ninenines.eu> On 02/17/2014 11:21 PM, Garrett Smith wrote: > Would a github based index make sense? Complete with a liberal pull > request policy? There is a package index for erlang.mk. Nobody ever sent a PR. Sure it doesn't have a Web interface yet but I don't think that's the real problem. -- Lo?c Hoguin http://ninenines.eu From essen@REDACTED Tue Feb 18 00:05:18 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 18 Feb 2014 00:05:18 +0100 Subject: [erlang-questions] stdapp.mk - yet another Makefile for Erlang apps In-Reply-To: References: <53028876.5010004@gmail.com> Message-ID: <530295AE.7040508@ninenines.eu> You know me! If you want things in erlang.mk, open a ticket, as I will look at them after I write down the things I want. (Feature-wise it's mostly small improvements, but it will all be standardized, which is the important part. Oh, except Windows support, I suppose that's a biggie.) It will take a few weeks though, the spec is also the upcoming user guide, and I expect it to be around 1000 lines. At my writing speed that's a lot of work days, and I'm writing the Cowboy REST guide at the same time. End of March maybe. On 02/17/2014 11:56 PM, Garrett Smith wrote: > Oh, nothing will stop Lo?c. Nothing. The best we can hope for is > minimal bruising after said sprint. > > On Mon, Feb 17, 2014 at 4:53 PM, Dmitry Demeshchuk wrote: >> Lo?c mentioned he was working on specing out erlang.mk v1.0. Might be worth >> running such a sprint before he finishes :) >> >> >> On Mon, Feb 17, 2014 at 2:15 PM, Garrett Smith wrote: >>> >>> Can we do an EUC or San Fran sprint-to-unite-all-Erlang-makefiles? >>> >>> On Mon, Feb 17, 2014 at 4:08 PM, Richard Carlsson >>> wrote: >>>> I recently gave our build system a complete overhaul, and in the process >>>> created a generic GNU Makefile for building Erlang applications. (Yes, I >>>> took a quick look at erlang.mk, but it does a lot of stuff that we don't >>>> currently need, and doesn't do certain things we did need.) >>>> >>>> https://github.com/richcarl/stdapp.mk >>>> >>>> It currently only has rules for building, not for making releases or >>>> fetching application dependencies. >>>> >>>> We build some 200+ applications using this file (driven from a top-level >>>> Makefile). Only 10-15% of those apps need any additional build rules. >>>> External apps that we build include lager, nitrogen_core, yaws, erlguten >>>> and >>>> many other. >>>> >>>> Design goals have been to keep it straightforward, avoiding too much use >>>> of >>>> GNU magic and trying to make it possible to reuse at least parts of it >>>> with >>>> a non-GNU make. It currently needs gawk, though. >>>> >>>> MIT License, so feel free to use as-is or rip out whatever parts you may >>>> find useful. Feedback/improvements welcome. >>>> >>>> /Richard >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> >> -- >> Best regards, >> Dmitry Demeshchuk > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From ludovic@REDACTED Tue Feb 18 00:12:29 2014 From: ludovic@REDACTED (Ludovic Demblans) Date: Tue, 18 Feb 2014 00:12:29 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> Message-ID: Hi, > % erl -install cowboy In my humble opinion, such a command is basically a tool who does a few things : lookup in a repository index a package named 'cowboy', fetch it, compile it in a place and update a file (like $HOME/.erlang) to add it to the path. Someone may have said it already in the millions mails of the list I couldn't read today, but the main problem would be "Who handles the repository index". I believe there are already such indexes, one for elixir and one called agner. Maybe others. IMHO if "the Erlang/OTP group at Ericsson" (as said on erlang.org) starts such an official packages index, writing a script to fetch the packages will take less than hour, rebar will be updated to handle this, and multiple tools will appear in the community. The main thing is to find who will be considered as an "official enough" index maintainers. (sorry for bad english ...) Ludovic Demblans Le Mon, 17 Feb 2014 05:05:33 +0100, Leo Liu a ?crit: > On 2014-02-17 10:07 +0800, Richard A. O'Keefe wrote: >> For a comparison, I look at R. It's not owned by a business, >> but it _is_ managed by a core of bright dedicated people who >> keep on rolling out ever-better releases. >> >> The one thing that they have that Erlang doesn't is a *large* >> repository of 3rd-party libraries. Having a single place >> to look for stuff (linked right off the main page) is good for >> everyone. (There's a single place to *look*; there are mirrors >> for *downloading*, which is as simple as >> > install.packages(c("wigwam","goose","bridle")) >> That will >> - fetch the latest descriptions >> - download whatever needs downloading >> - unpack whatever needs unpacking >> - compile whatever support code needs compiling >> - put everything where it can be found >> - including documentation and examples. >> >> When we can do something like >> >> % erl -install cowboy >> >> won't that be nice? > > You nailed it, the single most important change that would make a major > difference to erlang. > > The emacs community has a similar story. Now they have three major > package archives: an official one and two provided by the community. In > under 2 years, thousands of packages appeared. Now users need not deal > with editing features or problems upfront and just package-install > solutions. > > Leo > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Utilisant le logiciel de courrier r?volutionnaire d'Opera : http://www.opera.com/mail/ From desired.mta@REDACTED Tue Feb 18 00:19:43 2014 From: desired.mta@REDACTED (=?UTF-8?Q?Motiejus_Jak=C5=A1tys?=) Date: Tue, 18 Feb 2014 00:19:43 +0100 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: <53024F1C.4060507@meetinghouse.net> References: <53021AC4.8080303@meetinghouse.net> <53024F1C.4060507@meetinghouse.net> Message-ID: On Mon, Feb 17, 2014 at 7:04 PM, Miles Fidelman wrote: > > If I wanted to model this as a standard database, or serializing state into > a traditional database, I wouldn't be asking the questions I asked. Can > anybody talk to the questions I actually asked, about: > - handling large numbers of actors that might persist for years, or decades > (where actor = Erlang-style process) > - backup up/restoring state of long-running actors that might crash > - multi-cast messaging among actors Hi, Some time ago I was part of a team which created software to manage phone number migration between mobile operators. Say you want to change your cell phone provider (mandatory in EU and in many other countries). We were the entity responsible for that process. One portability request is one process. At any time we could have had up to 1M processes (practically it was much lower, but we used this number when designing the system). A "portability process" is a finite state machine with communication in SOAP between two or three parties with many internal state changes. A single process could last from a few hours up to few months (median ~3-4 days), each state up to 10-100KB of uncompressed text (mean ~15KB uncompressed). Having Erlang processes allowed very nice things like straightforward programming of state transitions during timeouts. Strict consistency requirements meant we had checkpoints in a key-value store for every operation for every process, which was managed globally. >From that checkpoints it was possible to re-create state replying all actions. We did not really manage to fully implement a proper addressing mechanism for non-volatile message sending. We invented our own PIDs which had some sort of address / node ownership information. The mechanism was complex and imperfect, nothing really to learn from. AMQP might be a good candidate though. Note that some of the details above are not exactly true (esp. numbers), because I can't remember all the details. A few remarks: 1. Do *not* store full state after you change it. Implement a diff mechanism on your abstract state tree (it's strictly defined, right?), test it using PropEr and use that. If you require fast recovery in case of crash, checkpoint is ok, but never drop the old state. You might dispute the state transition after months, go fix the bug and want to re-run a particular process transitions again next year... Ugh. 2. Long-lived processes (weeks+) are perfectly fine for Erlang VM. Just make sure to hibernate them after some minutes of inactivity. You can easily have hundreds of thousands, consume basically no CPU and just enough memory to keep the internal state. Regards, Motiejus -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Tue Feb 18 00:22:13 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 17 Feb 2014 18:22:13 -0500 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: References: <53021AC4.8080303@meetinghouse.net> <53026F73.5080106@meetinghouse.net> Message-ID: <530299A5.8030501@meetinghouse.net> [By the way folks - all the other threads going on be damned - this is a great community. Thank you all for the rapid and useful input to what is, as yet, a vaporous system concept!] Hi Joe, First off, thanks for the response! Following-up, inline: Joe Armstrong wrote: > > > > On Mon, Feb 17, 2014 at 9:22 PM, Miles Fidelman > > wrote: > > > Joe... can you offer any insight into the dynamics of Erlang, > when running with large number of processes that have very long > persistence? > > > No - this area has not to my knowledge been investigated. The "use > lots of processes" or "as many processes as necessary" has an implicit > assumption that a) the processes are not very large and > b) not very long lived. At the back of my mind I'm thinking of a) as > "a few hundred KB resident size" and > b) a few seconds to minutes. I'm *not* thinking MBs and years. The > latter requirements fit into our > "telecoms domain" - a few thousands to tens of thousands of > computations living for "the length of a telephone call" ie (max) > hours but not years. > > Some kind of "getting things out of memory and onto disk when not > needed" layer is needed for your problem, Ok. After reading what others have said about garbage collection, this is clearly issue number one that I'll need to address. At first glance, it strikes me that the hibernate BIF does at least part of what's needed - any thoughts/suggestions as to whether it might make sense to approach this by extending hibernate, vs. something at the application layer? And, if it makes sense to play with the BIF, any quick pointers to where I might find detailed documentation on how it's implemented? > > Somehow, it strikes me that 100,000 processes with 1MB of state, > each running for years at a time, have a different dynamic than > 100,000 processes, each representing a short-lived protocol > transaction (say a web query). > > > My first comment is, thanks for providing some numbers :-) I keep > saying time and time > again, don't ask questions without numbers. 100K processes with 1MB of > state = 10^11 bytes > so you'd need a really big machine to do this. Assuming say 8GB of > memory and 1MB of state > you'd have an upper limit of 8K processes. This assumes a regular > spinning disk. I guess if you have > a big SSD the story changes. > > So you either have to reduce the size of the state, or the number of > processes. The state can (I suppose) be partitioned into a (small) > index and a (larger) content. So I'd keep the index in memory and the > content > on disk (or cached). Which also brings us back to keeping most of the documents in some kind of hibernation, stored on disk, but ready to wake up if called on. > > Coupled with a communications paradigm for identifying a group of > processes and sending each of them the same message (e.g., 5000 > people have a copy of a book, send all 5000 of them a set of > errata; or send a message asking 'who has updates for section 3.2). > > > Hopefully all 5000 people will not want the errata at the same time Here's where I think pub-sub and replication. > > > In some sense, the conceptual model is: > 1. I send you an empty notebook. > 2. The notebook has an address and a bunch of message handling > routines > 3. I can send a page to the notebook, and the notebook inserts the > page. > 4. You can interact with the notebook - read it, annotate it, edit > certain sections - if you make updates, the notebook can > distribute updates to other copies - either through a P2P > mechanism or a publish-subscribe mechanism. > > At a basic level, this maps really well onto the Actor formalism - > every notebook is an actor, with it's own address. Updates, > interactions, queries, etc. are simply messages. > > Since Erlang is about the only serious implementation of the Actor > formalism, I'm trying to poke at the edge cases - particularly > around long-lived actors. And who better to ask than you :-) > > > It's a very good question. I like questions that poke around at the > edges of what is possible :-) > > > In passing: Early versions of Smalltalk were actor-like, > encapsulating state, methods, and process - but process kind of > got dropped along the way. By contrast, it strikes me that Erlang > focuses on everything being a process, and long-term persistence > of state has taken a back seat. > > > Yes - I guess the real solution would be to change the scheduler to > swap processes to disk after they had waited for more than (say) 10 > minutes for a message, and resurrect them when they are sent a message. Any thoughts on how to do this - perhaps in combination with extending the hibernate BIF? Cheers, Miles ------ nothing new below here -------- > > The idea that they might be swapped out for years hadn't occurred to me. > > I'm trying to probe the edge cases. (I guess another way of > looking at this is: to what extent is Erlang workable for writing > systems based around the mobile agent paradigm?) > > > Pass - at the moment you'd have to implement you own object layer to > do this . > I guess you could do this yourself by making send and receive library > routines and > making the state of a process explicit rather than implicit, then > slicking everything into > a large store (like riak). If you cache the active processes in memory > this might behave > well enough. > > > > > > > What I think is a more serious problem is getting data into > the system in the first place. > I have done some experiments with document commenting and > annotation systems and > found it very difficult to convert things like word documents > into a form that looks half > decent in a user interface. > > > Haven't actually thought a lot about that part of the problem. I'm > thinking of documents that are more form-like in nature, or at > least built up from smaller components - so it's not so much going > from Word to an internal format, as much as starting with XML or > JSON (or tuples), building up structure, and then adding > presentation at the final step. XML -> Word is a lot easier than > the reverse :-) > > On the other hand, I do have a bunch of applications in mind where > parsing Word and/or PDF would be very helpful - notably stripping > requirements out of specifications. (I can't tell you how much of > my time I spend manually cutting and pasting from specifications > into spreadsheets - for requirements tracking and such.) Again, > presentation isn't that much of an issue - structural and semantic > analysis is. But, while important, that's a separate set of > problems - and there are some commercial products that do a > reasonably good job. > > > I want to parse Microsoft word files and PDF etc. and display > them in a format that is > recognisable and not too abhorrent to the user. I also want to > allow on-screen manipulation of > documents (in a browser) - all of this seems to require a mess > of Javascript (in the browser)and a mess of parsing programs > inn the server. > > Before we can manipulate documents we must parse them and turn > them into a format > that can be manipulated. I think this is more difficult that > the storing and manipulating documents > problem. You'd also need support for full-text indexing, > foreign language and multiple character sets and so > on. Just a load of horrible messy small problems, but a > significant barrier to importing large amounts > of content into the system. > > You'd also need some quality control of the documents as they > enter the system (to avoid rubbish in rubbish out), also to > maintain the integrity of the documents. > > > Again, for this problem space, it's more about building up complex > documents from small pieces, than carving up pre-existing > documents. More like the combination of an IDE and a distributed > CVS - where fully "compiled" documents are the final output. > > > > If you have any ideas of now to get large volumes of data into > the system from proprietary formats > (like ms word) I'd like to hear about it. > > > Me too :-) Though, I go looking for such things every once in a > while, and: > - there are quite a few PDF to XML parsers, but mostly commercial ones > > > Suck - then you have to buy them to find out if they are any good > > - there are a few PDF and Word "RFP stripping" products floating > around, that are smart enough to actually analyze the content of > structured documents (check out Meridian) > > - later versions of Word export XML, albeit poor XML > > > Which sucks > > - there are quite a few document analysis packages floating > around, including ones that start from OCR images - but they > generally focus on content (lexical analyis) and ignore structure > (it's easier to scan a document and extract some measure of what > it's about - e.g. for indexing purposes; it's a lot harder to find > something that will extract the outline structure of a document) > > > Cheers, > > Miles > > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mfidelman@REDACTED Tue Feb 18 00:25:42 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 17 Feb 2014 18:25:42 -0500 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: References: <53021AC4.8080303@meetinghouse.net> <53024F1C.4060507@meetinghouse.net> Message-ID: <53029A76.4030205@meetinghouse.net> Ahh... an existence proof. VERY helpful. Thanks! Motiejus Jak?tys wrote: > > On Mon, Feb 17, 2014 at 7:04 PM, Miles Fidelman > > wrote: > > > > If I wanted to model this as a standard database, or serializing > state into > > a traditional database, I wouldn't be asking the questions I asked. Can > > anybody talk to the questions I actually asked, about: > > - handling large numbers of actors that might persist for years, or > decades > > (where actor = Erlang-style process) > > - backup up/restoring state of long-running actors that might crash > > - multi-cast messaging among actors > > Hi, > > Some time ago I was part of a team which created software to manage > phone number migration between mobile operators. Say you want to > change your cell phone provider (mandatory in EU and in many other > countries). We were the entity responsible for that process. > > One portability request is one process. At any time we could have had > up to 1M processes (practically it was much lower, but we used this > number when designing the system). A "portability process" is a finite > state machine with communication in SOAP between two or three parties > with many internal state changes. > > A single process could last from a few hours up to few months (median > ~3-4 days), each state up to 10-100KB of uncompressed text (mean ~15KB > uncompressed). > > Having Erlang processes allowed very nice things like straightforward > programming of state transitions during timeouts. > > Strict consistency requirements meant we had checkpoints in a > key-value store for every operation for every process, which was > managed globally. From that checkpoints it was possible to re-create > state replying all actions. > > We did not really manage to fully implement a proper addressing > mechanism for non-volatile message sending. We invented our own PIDs > which had some sort of address / node ownership information. The > mechanism was complex and imperfect, nothing really to learn from. > AMQP might be a good candidate though. > > Note that some of the details above are not exactly true (esp. > numbers), because I can't remember all the details. > > A few remarks: > 1. Do *not* store full state after you change it. Implement a diff > mechanism on your abstract state tree (it's strictly defined, right?), > test it using PropEr and use that. If you require fast recovery in > case of crash, checkpoint is ok, but never drop the old state. You > might dispute the state transition after months, go fix the bug and > want to re-run a particular process transitions again next year... Ugh. > 2. Long-lived processes (weeks+) are perfectly fine for Erlang VM. > Just make sure to hibernate them after some minutes of inactivity. You > can easily have hundreds of thousands, consume basically no CPU and > just enough memory to keep the internal state. > > Regards, > Motiejus > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From g@REDACTED Tue Feb 18 00:26:01 2014 From: g@REDACTED (Garrett Smith) Date: Mon, 17 Feb 2014 17:26:01 -0600 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <53018DE1.1090901@meetinghouse.net> <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> <53021D9F.7060605@meetinghouse.net> Message-ID: On Mon, Feb 17, 2014 at 9:58 AM, Mark Allen wrote: > On 2/17/14 8:50 AM, "Garrett Smith" wrote: >>Grabbing required source into a single directory and compiling >>everything, independent of shared system code, is, in my experience, >>much more reliable. > > I agree with you here Finally! > to the extent that it effectively replicates an > isolated development environment much like virtualenv or rvm provide for > Python or Ruby. Oh :( >>I think I'm going to call this a feature, not a bug. > > TL;DR: When it's *obvious* there is a great Erlang implementation of X, > github is fine. Otherwise, it is totally crappy. > > > To encourage broader adoption, Erlang *does* need some kind of maintained > package index that roughly consolidates the community's package > preferences into something more meaningful than "I needed to support > function X in Erlang and I found these 3 projects using Google." > > Because that's a crazy way to expect n00bs to find solutions to real > problems they're having. > > I assure you as someone who "recently learned" Erlang - about 18 months > ago - I cannot count the number of times I have started working on > implementing a story for my $JOB and frittered away an hour or three > searching Google and github.com looking for " Erlang" before I > reinvent the wheel. > > The simple fact is that if you're not part of the "Erlang community" via > this mailing list or what have you, you will at best find pointers to half > completed abandon ware on Google code, obscure blog posts written three > years ago and so forth. > > There have been several times when rather waste time implementing > "WebService-X for Erlang" I just go ahead and use the official Python > library hanging off a RabbitMQ consumer. Seriously, brilliantly put. Completely correct. The isolation of statically bound, compiled dependencies is a great technical advantage, but the murk and mire leading up to that is pointless friction. Now, there are some here who think these barriers are good and separate the talented brilliant, tasty, wheat from the dull, lazy, meager chaff. But we don't mind helping the special folk get along easier in Erlang land, do we? I like that github is the point of focus here - it reflects common practice and is an easy proving ground for new ideas. And some metadata tacked onto a repo is painless and evolvable. Once it solidifies, we can pass it along to Pieter to formalize as a standard. Garrett From darach@REDACTED Tue Feb 18 00:46:59 2014 From: darach@REDACTED (Darach Ennis) Date: Mon, 17 Feb 2014 23:46:59 +0000 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> Message-ID: Hi all, The node community got this right (despite scaling issues with npm) with an easy to use tool to discover, publish and consume modules or packages. The package format describes enough that it is easy to pin dependencies to specific versions of 3rd party packages and/or pull directly from github if/when you want to use a specific fork/branch/tag for some reason. As a recent convert to using Erlang/OTP every day it was disappointing to see many popular projects and packages are often not tagged, not versioned or simply resolved directly from a branch on github in a rebar.config or equivalent. Not good. For a large project using many 3rd party dependencies, some of which will invariably be unpinned it means each build is potentially dragging in versions of packages never-before-seen on each clean build. I've gone from really liking rebar when I was using Erlang/OTP primarily for fun to finding it offers a brittle foundation for building robust systems now that I'm using Erlang/OTP every day (which is otherwise jolly and pleasant). A means to easily publish, consume and discover packages out of the box would be fabulous. It would be better if it worked for not just Erlang/OTP but other beam hosted languages (eg: LFE, Elixir) for those that. It would be nice if it could work out of the box with erjang too. The easier folk can move from investigating Erlang to running with it in production through making sure package management and build tools are first class (or, as good as competing languages) the better IMHO. Apologies if I'm off-topic or the above points have been labored to death already... Cheers, Darach. On Mon, Feb 17, 2014 at 11:12 PM, Ludovic Demblans wrote: > Hi, > > % erl -install cowboy >> > > In my humble opinion, such a command is basically a tool who does a few > things : lookup in a repository index a package named 'cowboy', fetch it, > compile it in a place and update a file (like $HOME/.erlang) to add it to > the path. Someone may have said it already in the millions mails of the > list I couldn't read today, but the main problem would be "Who handles the > repository index". > > I believe there are already such indexes, one for elixir and one called > agner. Maybe others. IMHO if "the Erlang/OTP group at Ericsson" (as said on > erlang.org) starts such an official packages index, writing a script to > fetch the packages will take less than hour, rebar will be updated to > handle this, and multiple tools will appear in the community. The main > thing is to find who will be considered as an "official enough" index > maintainers. > > (sorry for bad english ...) > > Ludovic Demblans > > > > Le Mon, 17 Feb 2014 05:05:33 +0100, Leo Liu a ?crit: > > > On 2014-02-17 10:07 +0800, Richard A. O'Keefe wrote: >> >>> For a comparison, I look at R. It's not owned by a business, >>> but it _is_ managed by a core of bright dedicated people who >>> keep on rolling out ever-better releases. >>> >>> The one thing that they have that Erlang doesn't is a *large* >>> repository of 3rd-party libraries. Having a single place >>> to look for stuff (linked right off the main page) is good for >>> everyone. (There's a single place to *look*; there are mirrors >>> for *downloading*, which is as simple as >>> > install.packages(c("wigwam","goose","bridle")) >>> That will >>> - fetch the latest descriptions >>> - download whatever needs downloading >>> - unpack whatever needs unpacking >>> - compile whatever support code needs compiling >>> - put everything where it can be found >>> - including documentation and examples. >>> >>> When we can do something like >>> >>> % erl -install cowboy >>> >>> won't that be nice? >>> >> >> You nailed it, the single most important change that would make a major >> difference to erlang. >> >> The emacs community has a similar story. Now they have three major >> package archives: an official one and two provided by the community. In >> under 2 years, thousands of packages appeared. Now users need not deal >> with editing features or problems upfront and just package-install >> solutions. >> >> Leo >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > -- > Utilisant le logiciel de courrier r?volutionnaire d'Opera : > http://www.opera.com/mail/ > > _______________________________________________ > 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 Tue Feb 18 01:44:57 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 18 Feb 2014 01:44:57 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <53018DE1.1090901@meetinghouse.net> <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> <53021D9F.7060605@meetinghouse.net> Message-ID: <4E614EBF-45C6-461B-8B7A-191D251F1DCB@gmail.com> Hello, All these projects relied on GitHub for their own infrastructure. They all failed. Let?s stop. Please. Regards, -- Anthony Ramine Le 17 f?vr. 2014 ? 23:33, Gordon Guthrie a ?crit : > The proposal is that people who publish open source Erlang modules on GitHub be able to have them listed on earldoms. > > > > They key point is that a community is only a real community if you choose to join it. I was 'joined' to the Agner community (and there have been other attempts, Erlware, CEAN, etc) but they don't stick. From n.oxyde@REDACTED Tue Feb 18 01:52:50 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 18 Feb 2014 01:52:50 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> Message-ID: <68950A1B-BD93-43BC-8739-2F5A50F78626@gmail.com> My own opinion is that any Erlang package manager relying on GitHub for whatever more than hosting a simple Git repository is doomed to fail. Feel free to disprove me through making one. Companies make money around Erlang, if they want such a thing, money will need to be thrown at it for the infrastructure, there is just no way around it. If an index should be, the applications going into the main one are going to need some level of validation, otherwise it?s just a garbage bin which language zealots will use to tell the world we have 66,000 packages available. Validation means testing, continuous integration and all that entails. GitHub will not help you here. -- Anthony Ramine Le 18 f?vr. 2014 ? 00:12, Ludovic Demblans a ?crit : > "Who handles the repository index" From mjtruog@REDACTED Tue Feb 18 01:53:36 2014 From: mjtruog@REDACTED (Michael Truog) Date: Mon, 17 Feb 2014 16:53:36 -0800 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: <530299A5.8030501@meetinghouse.net> References: <53021AC4.8080303@meetinghouse.net> <53026F73.5080106@meetinghouse.net> <530299A5.8030501@meetinghouse.net> Message-ID: <5302AF10.10502@gmail.com> On 02/17/2014 03:22 PM, Miles Fidelman wrote: > Any thoughts on how to do this - perhaps in combination with extending the hibernate BIF? Most people use gen_server with hibernate in the return value from the callback (e.g., http://www.erlang.org/doc/man/gen_server.html#Module:handle_call-3). If you need something that is more complex, CloudI has a hibernate service configuration option that allows you to hibernate based on the incoming service request rate, so when the service request rate drops too low, the process hibernates whenever possible (http://cloudi.org/api.html#2_services_add_config_opts_hibernate). From bob@REDACTED Tue Feb 18 02:01:17 2014 From: bob@REDACTED (Bob Ippolito) Date: Mon, 17 Feb 2014 17:01:17 -0800 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <68950A1B-BD93-43BC-8739-2F5A50F78626@gmail.com> References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <68950A1B-BD93-43BC-8739-2F5A50F78626@gmail.com> Message-ID: It is important to have the ability to create private package indexes and repository mirrors for security/performance/redundancy. I don't think that making GitHub the de facto option for the public index and package hosting is a bad idea, as long as it's obvious how to use an alternative index. There are services that could be used to help power testing/CI that layer well on top of GitHub, such as Travis-CI. Rackspace is also known to donate time on their cloud for open source projects, although that would require some central administration. On Mon, Feb 17, 2014 at 4:52 PM, Anthony Ramine wrote: > My own opinion is that any Erlang package manager relying on GitHub for > whatever more than hosting a simple Git repository is doomed to fail. Feel > free to disprove me through making one. > > Companies make money around Erlang, if they want such a thing, money will > need to be thrown at it for the infrastructure, there is just no way around > it. If an index should be, the applications going into the main one are > going to need some level of validation, otherwise it?s just a garbage bin > which language zealots will use to tell the world we have 66,000 packages > available. > > Validation means testing, continuous integration and all that entails. > GitHub will not help you here. > > -- > Anthony Ramine > > Le 18 f?vr. 2014 ? 00:12, Ludovic Demblans a ?crit > : > > > "Who handles the repository index" > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Tue Feb 18 02:01:44 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 17 Feb 2014 20:01:44 -0500 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <68950A1B-BD93-43BC-8739-2F5A50F78626@gmail.com> References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <68950A1B-BD93-43BC-8739-2F5A50F78626@gmail.com> Message-ID: <5302B0F8.8090004@meetinghouse.net> Anthony Ramine wrote: > My own opinion is that any Erlang package manager relying on GitHub for whatever more than hosting a simple Git repository is doomed to fail. Feel free to disprove me through making one. > > Companies make money around Erlang, if they want such a thing, money will need to be thrown at it for the infrastructure, there is just no way around it. If an index should be, the applications going into the main one are going to need some level of validation, otherwise it?s just a garbage bin which language zealots will use to tell the world we have 66,000 packages available. > > Validation means testing, continuous integration and all that entails. GitHub will not help you here. > One observation: Seems to me that the more successful repositories (e.g. CPAN, Debian) are mirrors, supported by multiple organizations. Might be a model to emulate. Main site at Erlang solutions, multiple mirrors? One other thought: Maybe the OSU Open Source Lab might provide some infrastructure - they seem to host an awful lot of serious codebases. I expect they might have some experience and ideas to offer. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From darach@REDACTED Tue Feb 18 02:18:23 2014 From: darach@REDACTED (Darach Ennis) Date: Tue, 18 Feb 2014 01:18:23 +0000 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <5302B0F8.8090004@meetinghouse.net> References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <68950A1B-BD93-43BC-8739-2F5A50F78626@gmail.com> <5302B0F8.8090004@meetinghouse.net> Message-ID: A good example is Yahoo!. They've replaced a lot (over 400) of traditionally java-based projects with another language. They host their own internal package management service that mirrors vetted/approved open source projects based on public mirrors. So, they take the load off public mirrors and internal projects only use 'the right packages' (have appropriate license etc..). This also allows control when contributing back to the community (make sure contributions to open source are licensed, vetted, etc..). If anything this creates a commercial opportunity and may help subsidise any public infrastructure. On Tue, Feb 18, 2014 at 1:01 AM, Miles Fidelman wrote: > Anthony Ramine wrote: > >> My own opinion is that any Erlang package manager relying on GitHub for >> whatever more than hosting a simple Git repository is doomed to fail. Feel >> free to disprove me through making one. >> >> Companies make money around Erlang, if they want such a thing, money will >> need to be thrown at it for the infrastructure, there is just no way around >> it. If an index should be, the applications going into the main one are >> going to need some level of validation, otherwise it's just a garbage bin >> which language zealots will use to tell the world we have 66,000 packages >> available. >> >> Validation means testing, continuous integration and all that entails. >> GitHub will not help you here. >> >> > One observation: Seems to me that the more successful repositories (e.g. > CPAN, Debian) are mirrors, supported by multiple organizations. Might be a > model to emulate. Main site at Erlang solutions, multiple mirrors? > > One other thought: Maybe the OSU Open Source Lab might provide some > infrastructure - they seem to host an awful lot of serious codebases. I > expect they might have some experience and ideas to offer. > > > 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 sdl.web@REDACTED Tue Feb 18 03:25:52 2014 From: sdl.web@REDACTED (Leo Liu) Date: Tue, 18 Feb 2014 10:25:52 +0800 Subject: [erlang-questions] otp_src_R16B03-1.tar.gz tarball bad Message-ID: I have downloaded twice from two machines http://www.erlang.org/download/otp_src_R16B03-1.tar.gz and neither can be unpacked without an error. MD5 (otp_src_R16B03-1.tar.gz) = e5ece977375197338c1b93b3d88514f8 Could someone check the tar-ball is correct? Leo From g@REDACTED Tue Feb 18 03:36:03 2014 From: g@REDACTED (Garrett Smith) Date: Mon, 17 Feb 2014 20:36:03 -0600 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <68950A1B-BD93-43BC-8739-2F5A50F78626@gmail.com> References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <68950A1B-BD93-43BC-8739-2F5A50F78626@gmail.com> Message-ID: On Mon, Feb 17, 2014 at 6:52 PM, Anthony Ramine wrote: > My own opinion is that any Erlang package manager relying on GitHub for whatever more than hosting a simple Git repository is doomed to fail. Feel free to disprove me through making one. The magic here is that packages can be constructed, in real time, lazily, and reliably, on your workstation -- through a simple git repository. In time and space this exists today. > Companies make money around Erlang, if they want such a thing, money will need to be thrown at it for the infrastructure, there is just no way around it. If an index should be, the applications going into the main one are going to need some level of validation, otherwise it's just a garbage bin which language zealots will use to tell the world we have 66,000 packages available. What exists today is this garbage bin, as you call it. It does seem to work in some capacity. It might not fit your vision, but it's what exists. > Validation means testing, continuous integration and all that entails. GitHub will not help you here. $ git clone git@REDACTED:anthonyrules/super-cool-repo.git $ cd super-cool-repo $ make check $ sudo make install You can even create a Jenkins job that automates this... to make it official CI. My complaint over github is that it's *too* centralized. I'd vote for more chaos, where the *real* stuff is only found at warehouse raves in dark corners, on SD cards, traded for illicit substances and other unspeakables. Maybe I'll distribute e2 that way. "Did you get a taste of 1.1 RC3 in San Fran last night -- OMG that stuff is *amaaaazing*!" Garrett P.S I'm partly serious about the rave distro scheme. I think I share yours any others view that a single, centralized purveyor of source or packages or whatever is a terrible idea. Mirrors, or distributed git repos on table top SD cards FTW. From ok@REDACTED Tue Feb 18 04:43:02 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 18 Feb 2014 16:43:02 +1300 Subject: [erlang-questions] let it crash erlang/ada [[was: Time for OTP to be Renamed?] In-Reply-To: <53020420.7030607@meetinghouse.net> References: <52FE02AC.2080706@meetinghouse.net> <52FE27E2.4020709@meetinghouse.net> <52FE3894.2000003@meetinghouse.net> <52FFEAC6.50308@gmail.com> <5300CF44.8050206@meetinghouse.net> <53012965.5030001@meetinghouse.net> <5302009E.2040507@meetinghouse.net> <53020420.7030607@meetinghouse.net> Message-ID: <60D60EBF-A14F-4D4D-81C3-6781D1F32472@cs.otago.ac.nz> Hardware redundancy is a great way of handling hardware failures, as long as they don't have a common cause. An over-voltage might take out several devices. Discs have an uncanny tendency to fail close together. (http://www.johndcook.com/blog/2009/01/05/rai-failure-probabilities/) Triple Modular Redundancy goes back to von Neumann, 1956 (http://www.nunoalves.com/papers/IEEEpotentials10/IEEEpot10-transient.pdf) It's good at dealing with single transient errors (radiation hits part of one device but not the others). Independently developed versions of a software component are as a rule developed by people who tend to think in the same ways and make the same kinds of mistakes. From anthonym@REDACTED Tue Feb 18 05:25:09 2014 From: anthonym@REDACTED (ANTHONY MOLINARO) Date: Mon, 17 Feb 2014 20:25:09 -0800 Subject: [erlang-questions] Performance analysis advice In-Reply-To: References: <00851615-E297-4982-A69E-DA5C2B2AB7B7@alumni.caltech.edu> <010E516D-93CE-4244-8F7F-DF5C977DB515@gmail.com> <08693ADC-D499-4EAF-95BB-D65D478A162E@alumni.caltech.edu> <13668B47-730E-4DB4-B2E1-2DF057654D5D@alumni.caltech.edu> Message-ID: Hi Dmitry, Thanks, I'll try this out. I tried fprof and percept2 but unfortunately didn't have much luck sifting through the output. I'll try eep out, and I saw eflame mentioned in another message which I'll also check out. Unfortunately, I've mostly had to discover these things in a haphazard way as this email has been lost among the massive threads taking up everyones email energy ;). For the most part, I've tried to design the application to remove contention. At the moment message passing is completely minimal, but at around 200 concurrent connections CPU spikes, so something is going on. Unfortunately I haven't quite found the right tool or the right instrumentation to point out what the issue could be. I'm wondering if there is something with my network configuration or with webmachine/mochiweb which could cause the issue. I'll probably try some simple concurrent profiling of a hello world webmachine to see if it also runs into issues as a sanity check, then layer in some of my logic from there to see if I can replicate what I'm seeing in a simpler test. Thanks again for the pointer, -Anthony On Feb 17, 2014, at 1:30 AM, Dmitry Kolesnikov wrote: > Hello, > > Try to profile your application. > I found this utility very use-full to eliminate performance bottleneck in app. > https://github.com/virtan/eep > > You can slightly boost you application performance by > * compiling runtime and app into native > * adjusting flags -sbt ... -sws ... -swt ... > > However, none of above would help if you have bottleneck by design. Try to profile your system to see most busy processes. > > Best Regards, > Dmitry > > On 12 Feb 2014, at 03:04, ANTHONY MOLINARO wrote: > >> So '+K false' seems to cause quite a bit less lock contention, although it doesn't remove the performance knee :( >> >> Here's with '+K true' >> >> lock id #tries #collisions collisions [%] time [us] duration [%] >> ----- --- ------- ------------ --------------- ---------- ------------- >> pollset 1 2439901 81002 3.3199 617130 0.8811 >> proc_main 159392 6402529 13807 0.2156 311906 0.4453 >> drv_ev_state 16 2373507 15719 0.6623 189350 0.2703 >> run_queue 16 9288814 58470 0.6295 136295 0.1946 >> process_table 1 457253 5411 1.1834 116726 0.1666 >> proc_link 159392 2182726 3669 0.1681 102834 0.1468 >> proc_status 159392 5879890 3079 0.0524 81224 0.1160 >> pix_lock 1024 1183 3 0.2536 75758 0.1082 >> proc_msgq 159392 4032954 3387 0.0840 35624 0.0509 >> timeofday 1 1403251 7160 0.5102 21584 0.0308 >> atom_tab 1 1948202 19 0.0010 2494 0.0036 >> timer_wheel 1 588379 1127 0.1915 1197 0.0017 >> pollset_rm_list 1 1116613 2220 0.1988 920 0.0013 >> db_hash_slot 576 642980 209 0.0325 578 0.0008 >> make_ref 1 372880 581 0.1558 554 0.0008 >> alcu_allocator 9 18660 18 0.0965 88 0.0001 >> >> and here's with '+K false' >> >> lock id #tries #collisions collisions [%] time [us] duration [%] >> ----- --- ------- ------------ --------------- ---------- ------------- >> proc_main 159151 6387799 13079 0.2047 626344 0.8941 >> proc_link 159151 2180755 3625 0.1662 132246 0.1888 >> run_queue 16 8997639 51163 0.5686 119858 0.1711 >> proc_status 159151 5837885 3160 0.0541 114003 0.1627 >> pix_lock 1024 1231 9 0.7311 96727 0.1381 >> proc_msgq 159151 4018925 3202 0.0797 83066 0.1186 >> process_table 1 452460 5544 1.2253 78856 0.1126 >> drv_ev_state 16 2454941 30392 1.2380 72814 0.1039 >> pollset 1 2424508 28413 1.1719 41359 0.0590 >> timeofday 1 870046 4161 0.4783 12728 0.0182 >> atom_tab 1 1950265 59 0.0030 6262 0.0089 >> timer_wheel 1 481116 958 0.1991 1148 0.0016 >> pollset_rm_list 1 784445 1383 0.1763 923 0.0013 >> db_hash_slot 576 645025 213 0.0330 462 0.0007 >> make_ref 1 370122 581 0.1570 378 0.0005 >> alcu_allocator 9 18229 10 0.0549 240 0.0003 >> async_enq_mtx 16 6505 1 0.0154 1 0.0000 >> >> Unfortunately, today was one of my meeting days so I didn't get to try more than this, but it is interesting to see the effect that +K has on locking. >> >> I think I'll try tracing during the knee (hopefully it won't be too much overhead) to see if I can figure out why I am still seeing the spike in CPU. >> >> -Anthony >> >> On Feb 10, 2014, at 11:11 PM, ANTHONY MOLINARO wrote: >> >>> No, I haven't other than setting '+K true' (are there other tweaks)? >>> >>> One of my experiments tomorrow will be to set '+K false' to see if falling back to select doesn't use the pollset. >>> >>> I'm also planning to instrument the number of times I call erlang:yield/0 when I fail to get a resource. I know the documentation warns about using erlang:yield/0 but it does seem to do what I want, which is to try again in a little bit (I want to keep the connections open and retry up to a timeout, which should have the effect of also applying back pressure to upstream load balancers). >>> >>> Anyway, still looking for more suggestions on thing to look for. >>> >>> Thanks, >>> >>> -Anthony >>> >>> >>> On Feb 10, 2014, at 6:10 PM, Anthony Ramine wrote: >>> >>>> Did you made any tweak to polling etc? This lock is owned by erl_poll. >>>> >>>> -- >>>> Anthony Ramine >>>> >>>> Le 11 f?vr. 2014 ? 01:45, ANTHONY MOLINARO a ?crit : >>>> >>>>> pollset 1 2369355 71578 3.0210 553249 0.7896 >>>> >>> >>> _______________________________________________ >>> 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 Tue Feb 18 05:57:28 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 18 Feb 2014 17:57:28 +1300 Subject: [erlang-questions] R16B03-1 installation glitch In-Reply-To: References: <31322914-8CB6-43DE-A042-D6C477D2C787@cs.otago.ac.nz> Message-ID: <3FE41509-0897-4A27-9645-9C719BA9908A@cs.otago.ac.nz> System: Mac OS X 10.7.5 on an Intel Core 2 Duo. C compiler selected by configure: i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 After running configure, with results described in my previous message, I ran 'make'. ... make -f x86_64-apple-darwin11.4.2/Makefile TYPE=opt can't open x86_64-apple-darwin11.4.2/opt/smp/erl_compile_flags.h for writing at utils/make_compiler_flags line 65. ... m/beam_emu.c -o obj/x86_64-apple-darwin11.4.2/opt/smp/beam_emu.o beam/beam_emu.c: In function 'process_main': beam/beam_emu.c:1281: warning: cast from pointer to integer of different size In file included from beam/beam_emu.c:1291: x86_64-apple-darwin11.4.2/opt/smp/beam_hot.h:12: warning: cast from pointer to integer of different size x86_64-apple-darwin11.4.2/opt/smp/beam_hot.h:21: warning: cast from pointer to integer of different size x86_64-apple-darwin11.4.2/opt/smp/beam_hot.h:30: warning: cast from pointer to integer of different size x86_64-apple-darwin11.4.2/opt/smp/beam_hot.h:39: warning: cast from pointer to integer of different size x86_64-apple-darwin11.4.2/opt/smp/beam_hot.h:48: warning: cast from pointer to integer of different size x86_64-apple-darwin11.4.2/opt/smp/beam_hot.h:61: warning: cast from pointer to integer of different size x86_64-apple-darwin11.4.2/opt/smp/beam_hot.h:69: warning: cast from pointer to integer of different size x86_64-apple-darwin11.4.2/opt/smp/beam_hot.h:77: warning: cast from pointer to integer of different size x86_64-apple-darwin11.4.2/opt/smp/beam_hot.h:85: warning: cast from pointer to integer of different size x86_64-apple-darwin11.4.2/opt/smp/beam_hot.h:93: warning: cast from pointer to integer of different size x86_64-apple-darwin11.4.2/opt/smp/beam_hot.h:101: warning: cast from pointer to integer of different size ... [lots more] ... beam/beam_emu.c:1322: warning: cast from pointer to integer of different size beam/beam_emu.c:1322: warning: cast from pointer to integer of different size beam/beam_emu.c:1322: warning: cast from pointer to integer of different size beam/beam_emu.c:1351: warning: cast from pointer to integer of different size beam/beam_emu.c:1351: warning: cast from pointer to integer of different size beam/beam_emu.c:1351: warning: cast from pointer to integer of different size beam/beam_emu.c:1368: warning: cast from pointer to integer of different size beam/beam_emu.c:1368: warning: cast from pointer to integer of different size beam/beam_emu.c:1368: warning: cast from pointer to integer of different size ... [lots more] ... In file included from beam/beam_emu.c:4548: x86_64-apple-darwin11.4.2/opt/smp/beam_cold.h:13: warning: cast from pointer to integer of different size x86_64-apple-darwin11.4.2/opt/smp/beam_cold.h:23: warning: cast from pointer to integer of different size x86_64-apple-darwin11.4.2/opt/smp/beam_cold.h:32: warning: cast from pointer to integer of different size x86_64-apple-darwin11.4.2/opt/smp/beam_cold.h:41: warning: cast from pointer to integer of different size ... [lots more] ... drivers/unix/unix_efile.c: In function 'efile_fdatasync': drivers/unix/unix_efile.c:446: warning: implicit declaration of function 'fdatasync' ... beam/beam_emu.c: In function 'process_main': beam/beam_emu.c:1281: warning: cast from pointer to integer of different size In file included from beam/beam_emu.c:1291: x86_64-apple-darwin11.4.2/opt/plain/beam_hot.h:12: warning: cast from pointer to integer of different size x86_64-apple-darwin11.4.2/opt/plain/beam_hot.h:21: warning: cast from pointer to integer of different size x86_64-apple-darwin11.4.2/opt/plain/beam_hot.h:30: warning: cast from pointer to integer of different size x86_64-apple-darwin11.4.2/opt/plain/beam_hot.h:39: warning: cast from pointer to integer of different size ... [lots more] ... drivers/unix/unix_efile.c: In function 'efile_fdatasync': drivers/unix/unix_efile.c:446: warning: implicit declaration of function 'fdatasync' ... ../unix/run_erl.c:44:1: warning: "_XOPEN_SOURCE" redefined : warning: this is the location of the previous definition ../unix/run_erl.c: In function 'error_logf': ../unix/run_erl.c:1169: warning: implicit declaration of function 'vsyslog' ... Makefile:71: warning: overriding commands for target `clean' /home/cshome/o/ok/Downloads/otp_src_R16B03-1/make/otp_subdir.mk:28: warning: ignoring old commands for target `clean' ... erlc -W +debug_info +nowarn_shadow_vars +warn_missing_spec +warn_untyped_record -o../ebin hipe.erl ../../compiler/src/beam_disasm.hrl:34: Warning: record function has field(s) without type information ... erlc -W +debug_info +warn_unused_import +warn_exported_vars +warn_missing_spec -o../ebin hipe_icode_cfg.erl ../flow/cfg.inc:177: Warning: missing specification for function params/1 ../flow/cfg.inc:181: Warning: missing specification for function params_update/2 ... /o/ok/Downloads/otp_src_R16B03-1/lib/ic/priv/ Term.java Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. CLASSPATH=/home/cshome/o/ok/Downloads/otp_src_R16B03-1/lib/ic/java_src/:/home/cshome/o/ok/Downloads/otp_src_R16B03-1/lib/jinterface/priv/ javac -d /home/cshome/o/ok/Downloads/otp_src_R16B03-1/lib/ic/priv/ TermHolder.java Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. ... connect/ei_resolve.c: In function 'copy_hostent': connect/ei_resolve.c:207: warning: cast from pointer to integer of different size connect/ei_resolve.c:223: warning: cast from pointer to integer of different size connect/ei_resolve.c:253: warning: cast from pointer to integer of different size ... anlib: file: /home/cshome/o/ok/Downloads/otp_src_R16B03-1/lib/erl_interface/obj/x86_64-apple-darwin11.4.2/libei.a(decode_bignum.o) has no symbols ranlib: file: /home/cshome/o/ok/Downloads/otp_src_R16B03-1/lib/erl_interface/obj/x86_64-apple-darwin11.4.2/libei.a(decode_long.o) has no symbols ... [more like that] ... crypto.c: In function 'init': crypto.c:654: warning: 'CRYPTO_num_locks' is deprecated (declared at /usr/include/openssl/crypto.h:415) crypto.c:666: warning: 'CRYPTO_set_mem_functions' is deprecated (declared at /usr/include/openssl/crypto.h:447) crypto.c:670: warning: 'CRYPTO_set_locking_callback' is deprecated (declared at /usr/include/openssl/crypto.h:418) crypto.c:671: warning: 'CRYPTO_set_id_callback' is deprecated (declared at /usr/include/openssl/crypto.h:425) crypto.c:672: warning: 'CRYPTO_set_dynlock_create_callback' is deprecated (declared at /usr/include/openssl/crypto.h:438) crypto.c:673: warning: 'CRYPTO_set_dynlock_lock_callback' is deprecated (declared at /usr/include/openssl/crypto.h:439) crypto.c:674: warning: 'CRYPTO_set_dynlock_destroy_callback' is deprecated (declared at /usr/include/openssl/crypto.h:440) crypto.c: In function 'info_lib': crypto.c:750: warning: 'SSLeay_version' is deprecated (declared at /usr/include/openssl/crypto.h:382) ... [a tedious great many more like that] There is no fdatasync() in the Mac OS X documentation or in Apple's headers. There is SYS_fdatasync in syscall.h. The warnings in connect/ei_resolve.c refer to uses of align_buf(buffer, buflen) This is a macro, #define align_buf(buf,len) \ for (;(((unsigned)buf) & EI_ALIGNBYTES); (buf)++,len--) Changing (unsigned) to (uintptr_t) should make the warnings go away. I'm guessing that (UWord) might be the right thing to use here. Yes, I know that the code as written will in fact work on typical C systems; but why not silence the warning so real warnings stand out better? Some of the warnings in beam_emu.c seem to be due to StoreBifResult(n, res), sometimes via STORE_ARITH_RESULT. I'm wondering if this might be down to #define Goto(Rel) {Go = (int)(Rel); goto emulator_loop;} because in StoreBifResult, we find Goto(stb_next); three times, and there are three warning messages for each use, and stb_next is a pointer-to-BeamInstr, so it is definitely wider than an int. Here is the StoreBifResult macro: #define StoreBifResult(Dst, Result) \ do { \ BeamInstr* stb_next; \ Eterm stb_reg; \ stb_reg = Arg(Dst); \ I += (Dst) + 2; \ stb_next = (BeamInstr *) *I; \ CHECK_TERM(Result); \ switch (beam_reg_tag(stb_reg)) { \ case R_REG_DEF: \ r(0) = (Result); Goto(stb_next); \ case X_REG_DEF: \ xb(x_reg_offset(stb_reg)) = (Result); Goto(stb_next); \ default: \ yb(y_reg_offset(stb_reg)) = (Result); Goto(stb_next); \ } \ } while (0) where register BeamInstr *I; So I is a pointer to a BeamInstr. It is advanced by Dst+2 words. It is deferenced. This yields a UWord. That UWord is coerced to a pointer and saved in stb_reg. Eventually Goto does Go = (int)stb_reg; coercing the pointer to an int and treating it as an opcode. UWord (64 bits) -> BeamInstr * (64 bits) is not technically safe in ISO C, but in practice is OK. BeamInstr * (64 bits) to int (32) bits is not safe in principle or in practice. In _this_ case, it seems to be safe. It would have been nice to be warned to expect these messages, though. beam_cold.h: NextPF(#, next); -> Goto(*I) -> same issue. The obvious question is, since this _is_ gcc, why was the NO_JUMP_TABLE variant selected? From ok@REDACTED Tue Feb 18 06:14:30 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 18 Feb 2014 18:14:30 +1300 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <68950A1B-BD93-43BC-8739-2F5A50F78626@gmail.com> Message-ID: On 18/02/2014, at 3:36 PM, Garrett Smith wrote: > > $ git clone git@REDACTED:anthonyrules/super-cool-repo.git > $ cd super-cool-repo > $ make check > $ sudo make install Please. NO! I can do this inside VirtualBox, but generally sudo is poison. Anything that expects people to trust an unknown makefile not to do evil things while installing had better have some really *serious* security and authentication on it. One of the really great things about the R repository and package management is that it works *without* needing any special privileges. From sergej.jurecko@REDACTED Tue Feb 18 06:52:01 2014 From: sergej.jurecko@REDACTED (Sergej Jurecko) Date: Tue, 18 Feb 2014 06:52:01 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <4E614EBF-45C6-461B-8B7A-191D251F1DCB@gmail.com> References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <53018DE1.1090901@meetinghouse.net> <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> <53021D9F.7060605@meetinghouse.net> <4E614EBF-45C6-461B-8B7A-191D251F1DCB@gmail.com> Message-ID: <65EA3611-255D-47C2-87CD-B09667C2CD4F@gmail.com> homebrew for osx seems quite successful. Sergej On Feb 18, 2014, at 1:44 AM, Anthony Ramine wrote: > Hello, > > All these projects relied on GitHub for their own infrastructure. They all failed. Let?s stop. Please. > > Regards, > > -- > Anthony Ramine > > Le 17 f?vr. 2014 ? 23:33, Gordon Guthrie a ?crit : > >> The proposal is that people who publish open source Erlang modules on GitHub be able to have them listed on earldoms. >> >> >> >> They key point is that a community is only a real community if you choose to join it. I was 'joined' to the Agner community (and there have been other attempts, Erlware, CEAN, etc) but they don't stick. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From steve@REDACTED Tue Feb 18 08:18:40 2014 From: steve@REDACTED (Steve Strong) Date: Tue, 18 Feb 2014 08:18:40 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <68950A1B-BD93-43BC-8739-2F5A50F78626@gmail.com> Message-ID: Agree on avoiding the 'make install' step - we have numerous active projects, each of which has their own dependencies - quite often of different versions of the same library. Having dependencies as a sub directory of each project has worked very well; if globally installed, I suspect we'd be having version issues all the time. As an aside, I suspect my company would be happy to donate some EC2 server time if such a thing were needed. Cheers, Steve On 18 Feb 2014 06:14, "Richard A. O'Keefe" wrote: > > On 18/02/2014, at 3:36 PM, Garrett Smith wrote: > > > > $ git clone git@REDACTED:anthonyrules/super-cool-repo.git > > $ cd super-cool-repo > > $ make check > > $ sudo make install > > Please. NO! I can do this inside VirtualBox, but generally > sudo is poison. > > Anything that expects people to trust an unknown makefile not > to do evil things while installing had better have some > really *serious* security and authentication on it. > > One of the really great things about the R repository and > package management is that it works *without* needing any > special privileges. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gordon@REDACTED Tue Feb 18 09:02:49 2014 From: gordon@REDACTED (Gordon Guthrie) Date: Tue, 18 Feb 2014 08:02:49 +0000 Subject: [erlang-questions] Fwd: What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <68950A1B-BD93-43BC-8739-2F5A50F78626@gmail.com> Message-ID: ---------- Forwarded message ---------- From: Gordon Guthrie Date: 18 February 2014 08:02 Subject: Re: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] To: Anthony Ramine I'm not saying anything about the final state - but you need to start somewhere with A COMMUNITY THAT PEOPLE CAN JOIN... Even a listing of packages is a step forward from the current nonsense we have. Gordon On 18 February 2014 00:52, Anthony Ramine wrote: > My own opinion is that any Erlang package manager relying on GitHub for > whatever more than hosting a simple Git repository is doomed to fail. Feel > free to disprove me through making one. > > Companies make money around Erlang, if they want such a thing, money will > need to be thrown at it for the infrastructure, there is just no way around > it. If an index should be, the applications going into the main one are > going to need some level of validation, otherwise it's just a garbage bin > which language zealots will use to tell the world we have 66,000 packages > available. > > Validation means testing, continuous integration and all that entails. > GitHub will not help you here. > > -- > Anthony Ramine > > Le 18 f?vr. 2014 ? 00:12, Ludovic Demblans a ?crit > : > > > "Who handles the repository index" > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- --- Gordon Guthrie CEO vixo.com @gordonguthrie +44 (0) 7776 251669 (in Bonnie Scotland!) vixo is made in Scotland from electrons -- --- Gordon Guthrie CEO vixo.com @gordonguthrie +44 (0) 7776 251669 (in Bonnie Scotland!) vixo is made in Scotland from electrons -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas@REDACTED Tue Feb 18 09:23:43 2014 From: andreas@REDACTED (Andreas Schumacher) Date: Tue, 18 Feb 2014 09:23:43 +0100 Subject: [erlang-questions] Fwd: FW: otp_src_R16B03-1.tar.gz tarball bad In-Reply-To: <58912684E2630B45963406CF7D8C52581C358848@ESESSMB103.ericsson.se> References: <58912684E2630B45963406CF7D8C52581C358848@ESESSMB103.ericsson.se> Message-ID: <5303188F.2030701@erlang.org> I have just downloaded the tar-ball to a couple of machines. The checksum is correct and I do not have any problems to unpack (and build from) the downloaded tar-ball. What command/arguments to tar did you use and what error message did you get? Andreas -----Original Message----- From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Leo Liu Sent: den 18 februari 2014 03:26 To: erlang-questions@REDACTED Subject: [erlang-questions] otp_src_R16B03-1.tar.gz tarball bad I have downloaded twice from two machines http://www.erlang.org/download/otp_src_R16B03-1.tar.gz and neither can be unpacked without an error. MD5 (otp_src_R16B03-1.tar.gz) = e5ece977375197338c1b93b3d88514f8 Could someone check the tar-ball is correct? Leo _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From erlang@REDACTED Tue Feb 18 09:24:08 2014 From: erlang@REDACTED (Andreas Stenius) Date: Tue, 18 Feb 2014 09:24:08 +0100 Subject: [erlang-questions] [ANN] ErlyDTL v0.9.0 Message-ID: Hi, After some fluctuating stability around 0.8.1/0.8.2, release 0.9.0 [1] brings a set of improvements that has been tested not only by the test suite, but also in a couple of projects. News: - API changes. Added _file and _template suffixes to the compile functions to explicitly convey what is to be compiled. - Autoescape is now *enabled* by default. Use the relatively new auto_escape option if you want this disabled by default. - blocktrans blocks can now be translated to multiple locales in runtime. (thanks to @seriyps ) - trans and _(...) tags can now be translated to multiple locales at compile time. (thanks to@REDACTED ) - Don't want to save the compiled .beam file? Use {out_dir, false} compile time option (this was possible before as well, when no out_dir was specified, but that results in a warning). - The error reporting has been fixed for certain cases. Please note that going forward from version 0.8.0 or earlier will require some minor adjustments as there have been a few incompatible changes introduced in the return values of the API. We have adopted the style of that of the Erlang compiler application, with options for reporting and/or returning errors and warnings. See the readme for details. A big thank you to all who reported issues and sent pull requests. Best regards, Andreas Stenius [1] https://github.com/erlydtl/erlydtl/releases/tag/0.9.0 Ps. As I see there will be more frequent releases of ErlyDTL in the future, I will only announce "major" releases to erlang-questions. If you want to stay up-to-date on every release, please subscribe to the erlydtl-users@REDACTED mailing list (or follow us at https://github.com/erlydtl/erlydtl). -------------- next part -------------- An HTML attachment was scrubbed... URL: From ludovic@REDACTED Tue Feb 18 09:24:43 2014 From: ludovic@REDACTED (ludovic@REDACTED) Date: Tue, 18 Feb 2014 09:24:43 +0100 Subject: [erlang-questions] =?utf-8?q?What_problem_are_we_trying_to_solve_?= =?utf-8?q?here=3F_=5Bwas_Erland_users_group_=5Bwas_re=3A_languages_in_use?= =?utf-8?q?=3F_=5Bwas=3A_Time_for_OTP_to_be_Renamed=3F=5D=5D=5D?= In-Reply-To: <68950A1B-BD93-43BC-8739-2F5A50F78626@gmail.com> References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <68950A1B-BD93-43BC-8739-2F5A50F78626@gmail.com> Message-ID: <151f0a5f387b555b0929df792adcdf12@demblans.com> I could not agree more. I was not saying that being a famous person/group would be sufficient to be trust as an "official enough" index, this task requires a lot more work. CI, validations, multiple versions etc.. must be done as people said here. That's why I was talking about an index, and not a repository. BTW, github as a storage facility is pretty good :) Le 2014-02-18 01:52, Anthony Ramine a ?crit?: > My own opinion is that any Erlang package manager relying on GitHub > for whatever more than hosting a simple Git repository is doomed to > fail. Feel free to disprove me through making one. > > Companies make money around Erlang, if they want such a thing, money > will need to be thrown at it for the infrastructure, there is just no > way around it. If an index should be, the applications going into the > main one are going to need some level of validation, otherwise it?s > just a garbage bin which language zealots will use to tell the world > we have 66,000 packages available. > > Validation means testing, continuous integration and all that entails. > GitHub will not help you here. From kino@REDACTED Tue Feb 18 09:31:00 2014 From: kino@REDACTED (satoshi kinoshita) Date: Tue, 18 Feb 2014 17:31:00 +0900 Subject: [erlang-questions] memory usage gap in erl_crash.dump? Message-ID: This is a kind of repeating the same question I sent about 2 weeks ago. But please let me ask one of my old questions again. I'm using R11B-5 32 bit beam and got some crash dumps. Though "processes_used" is about 1.6G bytes the sum of Stack+heap and OldHeap sections of all processes in the same dump file is only about 100M words(=400M bytes). Does any one have any idea for this gap between 1.6G and 400M? I calculated the sum of all processes like below using, grep, cut, tr and bc. Thanks, Kinoshita ----------------------------------------------------------- [cloudian@REDACTED S002]$ head erl_crash.dump =erl_crash_dump:0.1 Thu Jan 30 17:42:24 2014 Slogan: eheap_alloc: Cannot allocate 191315400 bytes of memory (of type "heap"). System version: Erlang (BEAM) emulator version 5.5.5 [source] [smp:8] [async-threads:64] [hipe] [kernel-poll:true] Compiled: Mon Jan 21 18:01:53 2008 Atoms: 9703 =memory total: 1843551840 processes: 1640736600 processes_used: 1626764688 [cloudian@REDACTED S002]$ { grep +heap: erl_crash.dump |cut -d' ' -f2 |tr "\n" +; echo 0; }|bc 46165303 [cloudian@REDACTED S002]$ { grep OldHeap: erl_crash.dump |cut -d' ' -f2 |tr "\n" +; echo 0; }|bc 52591961 -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Tue Feb 18 09:34:11 2014 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 18 Feb 2014 09:34:11 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <53018DE1.1090901@meetinghouse.net> <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> <53021D9F.7060605@meetinghouse.net> Message-ID: Thank you Gordon,The absence of a decent package manager as disturbed me for a long time. I'd like to add a few thoughts I have on the matter. Excuse the rant - I feel rather strongly about this. This is written great haste. I have to give a lecture in 20 minutes. Here are some things I'd like to see: 1) A decent standardized Manifest. A manifest is just a list of files and a short description. It also has copyright and licensing information, and possible authentication checksums and proof signatures. Nothing fancy - but it needs a standard. I don't feel strong about the format or the content. but it MUST have a version number :-) 2) Packages should NOT be unpacked on the destination machine. Unpacking a package BREAKS an abstraction boundary. I feel VERY STRONGLY about this. I hate unpacking things and finding that they scatter thousands of files all over my disk. Here's a radical proposal. The top level package should be a PDF file. In 2001 ago I wrote this http://www.sics.se/~joe/erlpdf.pdf - Read it, download it, try it, think about it. This a simple program that packs a file inside a PDF container. It still works. It seems like the one line description on my sics web page did not cause a stir of interest in the program (which I thought was a fun idea) so I'll now publicize the idea a bit more. Q: Why should the top level package be a PDF file? A: Because the *first* thing I want to do is read the documentation. I won't even look at a program that has no documentation - it's a waste of time. Q: Why should the top level package not be unpacked? A: Because it breaks an abstraction boundary, make it difficult to delete things etc. I don't have to unpack a jar file to execute the program in it. I don't have to unpack a .exe file to execute it so WHY IN THE NAME OF THE GREAT SLIMY THING THAT LIVES UNDER STONES should I have to unpack an Erlang package to execute the code in it? When I want to use say (cowboy) I just want to execute the code - I don't want to see all the details of what going on inside the program - I don't want to know that it is made of loads of modules - I want to hide the details - this is called ABSTRACTION. They tell me that they teach OO programming these days - I thought the idea of an object was to HIDE THE DETAILS OF THE OBJECT INSIDE THE OBJECT - so why do people who have been brought up on OO programming insist on writing programs that scatter files all over my disk? Hide your mess in a single container. Pleeeeeese. Q: How do I install a program? A: Put the PDF in the directory ${HOME}/.erlang_programs/ Q: How do I delete the program? A: Remove a single file from ${HOME}/.erlang_programs/ Q: How do I develop the program? A: Unpack the PDF file *somewhere else* 3) How should we distribute programs? Why not just use Bit Torrent? - we can self-seed our code, and seed code we approve of That way popular code will be multiply seeded and unpopular code with wither and die. We could use Jespers Bit torrent client and adapt it a bit so it knows about Erlang packages. To do this we need a) Trackers (easy) b) an Index (needs a publishing protocol) c) clients Erlang solutions etc. can trackers. The code can be ANYWHERE YOU FEEL LIKE and not on github. Putting stuff on github is for collaboration purposes, not for distributing code. Use BitTorrent for this. Cheers /Joe On Mon, Feb 17, 2014 at 11:33 PM, Gordon Guthrie wrote: > This is what I sent to Francesco > > > **************************************************************************************** > > *Building The Erlang Community* > > *Background* > > Erlang has long lacked a solid community core to act as a place where > users can discover existing modules and include them in their projects. > > *rebar *now provides the standard mechanism to include external > dependencies - this proposal is about making erldocs the standard place to > discover community contributions. > > *Proposal 1* > > The proposal is that people who publish open source Erlang modules on > GitHub be able to have them listed on erldocs. > > The process would be two part: > > - > > commit a page called *ERLDOCS.terms* to github in the root next to > *README.md* > - > > submit the URL to a page on erldocs > - > > erldocs would sook the github page into a community section > > > The structure of the *ERLDOCS.terms* file is simple tagged tuples, > something like: > > *{name, "Starling"}.* > > *{license, "EPL"}.* > > *{description, "Unicode support for Erlang"}.* > > *{details, "A C-Port wrapped around the ICU library for unicode"}.* > > *{status, "production"}. % alpha | beta | production* > > *{rebar, {version, "1"}, {starling, {git, "git://**github.com/hypernumbers/starling.git > **","master"}}}.* > > *Proposal 2* > > Dale Harvey originally intended that erldocs should include the ability > for members of the community to annotate the official documents with > examples, links to tutorials etc, etc. > > erldocs be so extended (by use of Disqus or other standard commenting > systems) > > *Requirements For Success* > > Erldocs 'failed' last time out because the OTP team changed the way > documents were generated, and Dale Harvey moved on from an Erlang shop to > Mozilla. > > In order for this to work Erlang Solutions has to commit to: > > - > > erldocs being the official community repository for Erlang > documentation - linked to directly from *erlang.org > * > - > > production of these documents needs to be integrated into the OTP > Team's release schedule > > *Modalities* > > If Erlang Solutions so agree the next stage would be to approach a number > of suppliers of top-notch Erlang open source and sign them up for launch. > My working list would be: > > - > > Erlang Solutions > - > > Basho > - > > Erlware > - > > Mats Cronquist > - > > Richard Carlsson > - > > Yaws > - > > Mochiweb > - > > Nitrogen > - > > Cowboy > - > > Web Machine > - > > Hypernumbers > > > There would need to be consultation with the launch group regarding the > structure and elements of the term file. > > Once they were onboard and the production cycle had been tested - an open > launch on the mailing list. > > > **************************************************************************************** > > The key point is that a community is only a real community if you choose > to join it. I was 'joined' to the Agner community (and there have been > other attempts, Erlware, CEAN, etc) but they don't stick. > > Gordon > > > On 17 February 2014 22:28, Mark Allen wrote: > >> On 2/17/14 4:21 PM, "Garrett Smith" wrote: >> >> On 2/17/14 1:51 PM, "Vixo" wrote: >> >>>My suggestion would be a manifest file of Erlang terms at the root >> level >> >>>of a GitHub page (they will *all* be on GitHub) that can be polled and >> >>>turned into a static site. The logical thing to do would be combine >> thus >> >>>with the revived erldocs site IMHO (as I have said to Francesco) >> >> >Does this require that all of github be crawled? >> >> No. I'm pretty sure we can segment the crawl to only projects with some X >> threshold of Erlang. (I'll have a slice without so much rat in it. [0]) >> >> >Would a github based index make sense? Complete with a liberal pull >> >request policy? >> >> Most likely, yes, using github pages with a nice custom domain would be a >> Good Thing for this type of project. The code to do the crawl and build >> the index should be open source too, imo. >> >> Mark >> >> [0]: >> >> http://en.wikiquote.org/wiki/Monty_Python's_Flying_Circus#The_Money_Program >> me_.5B3.03.5D >> >> > > > -- > --- > Gordon Guthrie > CEO vixo.com > @gordonguthrie > +44 (0) 7776 251669 (in Bonnie Scotland!) > > vixo is made in Scotland from electrons > > _______________________________________________ > 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 Tue Feb 18 09:34:44 2014 From: sedrik@REDACTED (Fredrik Andersson) Date: Tue, 18 Feb 2014 09:34:44 +0100 Subject: [erlang-questions] [ANN] ErlyDTL v0.9.0 In-Reply-To: References: Message-ID: Congrats on the new release. A good thing to include in release messages is a short summary of what the project is about. On Tue, Feb 18, 2014 at 9:24 AM, Andreas Stenius wrote: > Hi, > > After some fluctuating stability around 0.8.1/0.8.2, release 0.9.0 [1] > brings a set of improvements that has been tested not only by the test > suite, but also in a couple of projects. > > News: > > - API changes. Added _file and _template suffixes to the compile > functions to explicitly convey what is to be compiled. > - Autoescape is now *enabled* by default. Use the relatively new > auto_escape option if you want this disabled by default. > - blocktrans blocks can now be translated to multiple locales in > runtime. (thanks to @seriyps ) > - trans and _(...) tags can now be translated to multiple locales at > compile time. (thanks to@REDACTED ) > - Don't want to save the compiled .beam file? Use {out_dir, false} compile > time option (this was possible before as well, when no out_dir was > specified, but that results in a warning). > - The error reporting has been fixed for certain cases. > > > Please note that going forward from version 0.8.0 or earlier will require > some minor adjustments as there have been a few incompatible changes > introduced in the return values of the API. We have adopted the style of > that of the Erlang compiler application, with options for reporting and/or > returning errors and warnings. See the readme for details. > > A big thank you to all who reported issues and sent pull requests. > > Best regards, > Andreas Stenius > > [1] https://github.com/erlydtl/erlydtl/releases/tag/0.9.0 > > Ps. > As I see there will be more frequent releases of ErlyDTL in the future, I > will only announce "major" releases to erlang-questions. If you want to > stay up-to-date on every release, please subscribe to the > erlydtl-users@REDACTED mailing list (or follow us at > https://github.com/erlydtl/erlydtl). > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Tue Feb 18 10:14:39 2014 From: erlang@REDACTED (Andreas Stenius) Date: Tue, 18 Feb 2014 10:14:39 +0100 Subject: [erlang-questions] [ANN] ErlyDTL v0.9.0 In-Reply-To: References: Message-ID: Thank you. And indeed it is a good idea to tell what it is all about (as I've pointed out to others myself as well). So, here is a one liner: ErlyDTL is a template engine with the main goal of being compatible with the Django template language. Cheers 2014-02-18 9:34 GMT+01:00 Fredrik Andersson : > Congrats on the new release. > > A good thing to include in release messages is a short summary of what the > project is about. > > > On Tue, Feb 18, 2014 at 9:24 AM, Andreas Stenius wrote: > >> Hi, >> >> After some fluctuating stability around 0.8.1/0.8.2, release 0.9.0 [1] >> brings a set of improvements that has been tested not only by the test >> suite, but also in a couple of projects. >> >> News: >> >> - API changes. Added _file and _template suffixes to the compile >> functions to explicitly convey what is to be compiled. >> - Autoescape is now *enabled* by default. Use the relatively new >> auto_escape option if you want this disabled by default. >> - blocktrans blocks can now be translated to multiple locales in >> runtime. (thanks to @seriyps ) >> - trans and _(...) tags can now be translated to multiple locales at >> compile time. (thanks to@REDACTED ) >> - Don't want to save the compiled .beam file? Use {out_dir, false} compile >> time option (this was possible before as well, when no out_dir was >> specified, but that results in a warning). >> - The error reporting has been fixed for certain cases. >> >> >> Please note that going forward from version 0.8.0 or earlier will require >> some minor adjustments as there have been a few incompatible changes >> introduced in the return values of the API. We have adopted the style of >> that of the Erlang compiler application, with options for reporting and/or >> returning errors and warnings. See the readme for details. >> >> A big thank you to all who reported issues and sent pull requests. >> >> Best regards, >> Andreas Stenius >> >> [1] https://github.com/erlydtl/erlydtl/releases/tag/0.9.0 >> >> Ps. >> As I see there will be more frequent releases of ErlyDTL in the future, I >> will only announce "major" releases to erlang-questions. If you want to >> stay up-to-date on every release, please subscribe to the >> erlydtl-users@REDACTED mailing list (or follow us at >> https://github.com/erlydtl/erlydtl). >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Tue Feb 18 10:15:31 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Tue, 18 Feb 2014 10:15:31 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <53018DE1.1090901@meetinghouse.net> <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> <53021D9F.7060605@meetinghouse.net> Message-ID: On Feb 17, 2014 11:33 PM, "Gordon Guthrie" wrote: > > This is what I sent to Francesco > > **************************************************************************************** > > Building The Erlang Community > > Background > > Erlang has long lacked a solid community core to act as a place where users can discover existing modules and include them in their projects. > > rebar now provides the standard mechanism to include external dependencies - this proposal is about making erldocs the standard place to discover community contributions. > > Proposal 1 > > The proposal is that people who publish open source Erlang modules on GitHub be able to have them listed on erldocs. > > The process would be two part: > > commit a page called ERLDOCS.terms to github in the root next to README.md > > submit the URL to a page on erldocs > > erldocs would sook the github page into a community section > > > The structure of the ERLDOCS.terms file is simple tagged tuples, something like: > > {name, "Starling"}. > > {license, "EPL"}. > > {description, "Unicode support for Erlang"}. > > {details, "A C-Port wrapped around the ICU library for unicode"}. > > {status, "production"}. % alpha | beta | production > > {rebar, {version, "1"}, {starling, {git, "git:// github.com/hypernumbers/starling.git","master"}}}. > > Proposal 2 > > Dale Harvey originally intended that erldocs should include the ability for members of the community to annotate the official documents with examples, links to tutorials etc, etc. > > erldocs be so extended (by use of Disqus or other standard commenting systems) > > Requirements For Success > > Erldocs 'failed' last time out because the OTP team changed the way documents were generated, and Dale Harvey moved on from an Erlang shop to Mozilla. > > In order for this to work Erlang Solutions has to commit to: > > erldocs being the official community repository for Erlang documentation - linked to directly from erlang.org > > production of these documents needs to be integrated into the OTP Team's release schedule > > Modalities > > If Erlang Solutions so agree the next stage would be to approach a number of suppliers of top-notch Erlang open source and sign them up for launch. My working list would be: > > Erlang Solutions > > Basho > > Erlware > > Mats Cronquist > > Richard Carlsson > > Yaws > > Mochiweb > > Nitrogen > > Cowboy > > Web Machine > > Hypernumbers > > > There would need to be consultation with the launch group regarding the structure and elements of the term file. > > Once they were onboard and the production cycle had been tested - an open launch on the mailing list. > > > **************************************************************************************** > > The key point is that a community is only a real community if you choose to join it. I was 'joined' to the Agner community (and there have been other attempts, Erlware, CEAN, etc) but they don't stick. > > Gordon > > Please don't build a community over a private company (github). I sure don't want to depends on Github to publish a doc. The doc system should be enough smart to handle multiple sources. This is what godoc is able to. Also readthedoc can be a good source of inspiration.... - benoit > On 17 February 2014 22:28, Mark Allen wrote: >> >> On 2/17/14 4:21 PM, "Garrett Smith" wrote: >> >> On 2/17/14 1:51 PM, "Vixo" wrote: >> >>>My suggestion would be a manifest file of Erlang terms at the root level >> >>>of a GitHub page (they will *all* be on GitHub) that can be polled and >> >>>turned into a static site. The logical thing to do would be combine thus >> >>>with the revived erldocs site IMHO (as I have said to Francesco) >> >> >Does this require that all of github be crawled? >> >> No. I'm pretty sure we can segment the crawl to only projects with some X >> threshold of Erlang. (I'll have a slice without so much rat in it. [0]) >> >> >Would a github based index make sense? Complete with a liberal pull >> >request policy? >> >> Most likely, yes, using github pages with a nice custom domain would be a >> Good Thing for this type of project. The code to do the crawl and build >> the index should be open source too, imo. >> >> Mark >> >> [0]: >> http://en.wikiquote.org/wiki/Monty_Python's_Flying_Circus#The_Money_Program >> me_.5B3.03.5D >> > > > > -- > --- > Gordon Guthrie > CEO vixo.com > @gordonguthrie > +44 (0) 7776 251669 (in Bonnie Scotland!) > > vixo is made in Scotland from electrons > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre.graf@REDACTED Tue Feb 18 10:20:18 2014 From: andre.graf@REDACTED (=?ISO-8859-1?Q?Andr=E9_Graf?=) Date: Tue, 18 Feb 2014 10:20:18 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <53018DE1.1090901@meetinghouse.net> <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> <53021D9F.7060605@meetinghouse.net> Message-ID: <530325D2.4090303@erl.io> I think the PHP community took a huge step when the tools 'composer' (PHP's rebar) and 'packagist.org' came out. The way packagist work is straight forward, you provide a repository url (Git/Svn/Hg) and it crawls the package that contains a composer.json file (could be a rebar.config, an *.app.src file, or something else, but common ground is needed here). The package is typically crawled once a day or if e.g a GitHub hook gets triggered. Package versions are managed on the repository side using tags. The combo Packagist/Composer is certainly not the holy grail, but it solves many problems, it is easy to use (for maintainers as well as for the users of the package), and it looks straightforward to be implemented in Erlang. ;) On 02/17/2014 11:21 PM, Garrett Smith wrote: > On Mon, Feb 17, 2014 at 4:19 PM, Mark Allen wrote: >> On 2/17/14 1:51 PM, "Vixo" wrote: >>> My suggestion would be a manifest file of Erlang terms at the root level >>> of a GitHub page (they will *all* be on GitHub) that can be polled and >>> turned into a static site. The logical thing to do would be combine thus >>> with the revived erldocs site IMHO (as I have said to Francesco) >> >> I love this idea. I'm going to give this a think and maybe implement a >> prototype to do some testing of how it works. >> >> Thanks! Sometimes yak shaving discussions are kind of awesome. > > Does this require that all of github be crawled? > > Would a github based index make sense? Complete with a liberal pull > request policy? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From n.oxyde@REDACTED Tue Feb 18 10:35:20 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 18 Feb 2014 10:35:20 +0100 Subject: [erlang-questions] R16B03-1 installation glitch In-Reply-To: References: <31322914-8CB6-43DE-A042-D6C477D2C787@cs.otago.ac.nz> Message-ID: Thus should be checked, preferably the test should be automated. I don?t see any obvious reason why Clang should be slower now it supports &&-label addresses. Regards, -- Anthony Ramine Le 17 f?vr. 2014 ? 14:03, Lukas Larsson a ?crit : > Last time I heard clang produced code for beam_emu.c that was about 10-20% slower than gcc. Also compiling complicated files (I'm looking at you again beam_emu.c) is much slower in clang. > From desired.mta@REDACTED Tue Feb 18 10:39:22 2014 From: desired.mta@REDACTED (=?UTF-8?Q?Motiejus_Jak=C5=A1tys?=) Date: Tue, 18 Feb 2014 10:39:22 +0100 Subject: [erlang-questions] (not) packing code to PDF [was: What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]]] Message-ID: On Tue, Feb 18, 2014 at 9:34 AM, Joe Armstrong wrote: > Here's a radical proposal. The top level package should be a PDF file. > > In 2001 ago I wrote this > > http://www.sics.se/~joe/erlpdf.pdf - Read it, download it, try it, think > about it. Does not render correctly in my document viewer (evince) and does not render at all in Iceweasel 25 embedded pdf viewer. > This a simple program that packs a file inside a PDF container. It still > works. <...> > Q: Why should the top level package be a PDF file? > A: Because the *first* thing I want to do is read the documentation. > I won't even look at a program that has no documentation - it's a waste > of time. I could agree if I really needed to*. But: 1. Not everything can be pre-compiled (nifs and port drivers come to mind) 2. This severely limits the documentation representation. What if my documentation is a rich Web Page which requires html5 to tickle my fancy? In PDF we are sort of limited to... PDF. A quick fix for 2014 onwards: we have OpenDocument and Office Open XML which are just zip files with many more tools to manipulate. Loading stuff from zip archives is something we already do (except nifs, yes). We just need a file extension. :: EAR :: Motiejus From n.oxyde@REDACTED Tue Feb 18 10:49:34 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 18 Feb 2014 10:49:34 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <530325D2.4090303@erl.io> References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <53018DE1.1090901@meetinghouse.net> <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> <53021D9F.7060605@meetinghouse.net> <530325D2.4090303@erl.io> Message-ID: <6F9CBF02-CE44-487E-84D0-16998E5DCC42@gmail.com> I stopped reading at ? GitHub ?. Do people realize it is a closed proprietary platform? What if I force push a new tag on my repos, btw? Automation, robust packaging and Git do not play together. Note that I have nothing against using Git to *host* things (but I do think tarballs are better and simpler to manage), I specifically said ? GitHub ?, your mail suggests using its proprietary API to do fancy stuff. -- Anthony Ramine Le 18 f?vr. 2014 ? 10:20, Andr? Graf a ?crit : > I think the PHP community took a huge step when the tools 'composer' > (PHP's rebar) and 'packagist.org' came out. The way packagist work is > straight forward, you provide a repository url (Git/Svn/Hg) and it > crawls the package that contains a composer.json file (could be a > rebar.config, an *.app.src file, or something else, but common ground is > needed here). The package is typically crawled once a day or if e.g a > GitHub hook gets triggered. Package versions are managed on the > repository side using tags. The combo Packagist/Composer is certainly > not the holy grail, but it solves many problems, it is easy to use (for > maintainers as well as for the users of the package), and it looks > straightforward to be implemented in Erlang. ;) > > > On 02/17/2014 11:21 PM, Garrett Smith wrote: >> On Mon, Feb 17, 2014 at 4:19 PM, Mark Allen wrote: >>> On 2/17/14 1:51 PM, "Vixo" wrote: >>>> My suggestion would be a manifest file of Erlang terms at the root level >>>> of a GitHub page (they will *all* be on GitHub) that can be polled and >>>> turned into a static site. The logical thing to do would be combine thus >>>> with the revived erldocs site IMHO (as I have said to Francesco) >>> >>> I love this idea. I'm going to give this a think and maybe implement a >>> prototype to do some testing of how it works. >>> >>> Thanks! Sometimes yak shaving discussions are kind of awesome. >> >> Does this require that all of github be crawled? >> >> Would a github based index make sense? Complete with a liberal pull >> request policy? >> _______________________________________________ >> 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 desired.mta@REDACTED Tue Feb 18 10:56:45 2014 From: desired.mta@REDACTED (=?UTF-8?Q?Motiejus_Jak=C5=A1tys?=) Date: Tue, 18 Feb 2014 10:56:45 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <6F9CBF02-CE44-487E-84D0-16998E5DCC42@gmail.com> References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <53018DE1.1090901@meetinghouse.net> <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> <53021D9F.7060605@meetinghouse.net> <530325D2.4090303@erl.io> <6F9CBF02-CE44-487E-84D0-16998E5DCC42@gmail.com> Message-ID: On Tue, Feb 18, 2014 at 10:49 AM, Anthony Ramine wrote: > What if I force push a new tag on my repos, btw? Automation, robust packaging and Git do not play together. I am contemplating doing this in all dependency specifications: {superlib, "0.0.2", { git, "git://github.com/superman/superlib.git", {tag, "0.0.2-g91dd0b9548d35f57bc8eb694d65d3f28c2a24e55"} } } Then are no problems with trust and automation (as long as backups exist). Motiejus From n.oxyde@REDACTED Tue Feb 18 11:07:06 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 18 Feb 2014 11:07:06 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <53018DE1.1090901@meetinghouse.net> <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> <53021D9F.7060605@meetinghouse.net> <530325D2.4090303@erl.io> <6F9CBF02-CE44-487E-84D0-16998E5DCC42@gmail.com> Message-ID: Why should I go through the pain of making a backup for a repos when I could use tarballs and not have to mess with commit hashes? How do I solve dependency conflicts when all I have is a couple a hashes? How do I sign stuff? -- Anthony Ramine > Le 18 f?vr. 2014 ? 10:56, Motiejus Jak?tys a ?crit : > > Then are no problems with trust and automation (as long as backups exist). From sdl.web@REDACTED Tue Feb 18 11:07:32 2014 From: sdl.web@REDACTED (Leo Liu) Date: Tue, 18 Feb 2014 18:07:32 +0800 Subject: [erlang-questions] Fwd: FW: otp_src_R16B03-1.tar.gz tarball bad In-Reply-To: <5303188F.2030701@erlang.org> (Andreas Schumacher's message of "Tue, 18 Feb 2014 09:23:43 +0100") References: <58912684E2630B45963406CF7D8C52581C358848@ESESSMB103.ericsson.se> <5303188F.2030701@erlang.org> Message-ID: On 2014-02-18 16:23 +0800, Andreas Schumacher wrote: > I have just downloaded the tar-ball to a couple of machines. The > checksum is correct and I do not have any problems to unpack (and > build from) the downloaded tar-ball. > > What command/arguments to tar did you use and what error message did > you get? > > Andreas I re-tried and it Worked. The real error in my home server probably came from corrupted download. Took 30m-1h from here. The other error was due to some stupidity of that server which I have only restricted privilege. Thanks, Leo From davidnwelton@REDACTED Tue Feb 18 11:57:07 2014 From: davidnwelton@REDACTED (David Welton) Date: Tue, 18 Feb 2014 11:57:07 +0100 Subject: [erlang-questions] random thought: connecting to node, specify IP address In-Reply-To: References: Message-ID: For the sake of argument, say that the Erlang node comes up before the machine has an IP address, or that the IP address changes over time... I'm not 100% sure things will work out that way, but they may well. It'd be nice to be able to get back in to the node if it "phones home" somehow. -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From kenji@REDACTED Tue Feb 18 12:26:12 2014 From: kenji@REDACTED (Kenji Rikitake) Date: Tue, 18 Feb 2014 20:26:12 +0900 Subject: [erlang-questions] random thought: connecting to node, specify IP address In-Reply-To: References: Message-ID: <20140218112612.GA13552@k2r.org> Or build your own private DNS zone infrastructure. If you need to do a dynamic register to the DNS, you've got to have one anyway. Unless you're trying to enforce DNSSEC there, this won't be a big hassle. Not depending on the DNS is a viable solution, nevertheless. Kenji Rikitake ++> Bob Ippolito [2014-02-17 09:04:22 -0800]: > The best way to handle this is to force the nodes to come up with a > predictable name, not dependent on reverse DNS, such as foo@REDACTED For > discovery, these nodes can register themselves to some central directory > (dynamic DNS, database, etc.) or send periodic broadcast messages (mDNS or > some bespoke broadcast scheme). > > On Monday, February 17, 2014, David Welton wrote: > > > Hi, > > > > For various reasons, we sometimes have nodes that come up with a long > > node name that does not nicely map onto the network - say, > > foo@REDACTED or foo@REDACTED that does not get a > > DNS entry. The nodes operate in somewhat unknown and unstable network > > situation, so we may not even know the IP address ahead of time. > > > > It'd be nice to be able to - at a later date - force a connection to > > those nodes by specifying an IP address in the connection code > > somewhere. > > > > Is something like this at all feasible? > > > > Thank you From kenji@REDACTED Tue Feb 18 12:36:41 2014 From: kenji@REDACTED (Kenji Rikitake) Date: Tue, 18 Feb 2014 20:36:41 +0900 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <6F9CBF02-CE44-487E-84D0-16998E5DCC42@gmail.com> References: <53018DE1.1090901@meetinghouse.net> <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> <53021D9F.7060605@meetinghouse.net> <530325D2.4090303@erl.io> <6F9CBF02-CE44-487E-84D0-16998E5DCC42@gmail.com> Message-ID: <20140218113641.GA13616@k2r.org> A practical issue: uploading to GitHub is *painfully slow* (< 200kbytes/sec) (I once had to upload 40GB and that was a four-day work from Japan. :-/) Another issue I've seen: git-tagging itself won't automatically resolve the conflict issues. Quite often you need to tag on an individual commit for "stashing" the later commits as a workaround. Git is OK. I even use it at home with gitosis. Maybe in some cases Mercurial, or even svn, would be more appropriate. I think depending on GitHub is not good, though. Just my JPY 2 worth, Kenji Rikitake ++> Anthony Ramine [2014-02-18 10:49:34 +0100]: > Note that I have nothing against using Git to *host* things (but I do think tarballs are better and simpler to manage), I specifically said ? GitHub ?, your mail suggests using its proprietary API to do fancy stuff. From tuncer.ayaz@REDACTED Tue Feb 18 12:48:36 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 18 Feb 2014 12:48:36 +0100 Subject: [erlang-questions] modular otp concerns Message-ID: I know that at least Bjoern-Egil has been investigating the possibility of splitting up otp.git into sub repos, and before anything is set into stone, I'd like to resolve one concern I have. What will happen to the default distribution and the bundled libraries? Is the plan to split it into core and extra? I'm concerned that if we follow that route, we would lose the ability to rely on pretty useful functionality available out of the box. For example, today it's very convenient that I can write an escript which: * interacts with the network (http, ssh, snmp, etc.) * compiles sources for various languages * creates or extracts tarballs or zip archives * inspects a (remote) node * much more... If anything, I'd like to see more functionality bundled, not less. We can create escript (zip) archives and bundle extra libs, but that's not always a good fit, especially not for scripts you want to keep in a project's repo. If the modular project structure will prevent that out of the box functionality, we would give up a crucial advantage otp.git has over other scriptable languages' default distros. We've all seen what this lead to in several linux distros that split out Perl's or Python's bundled libs. What are the exact plans? From tuncer.ayaz@REDACTED Tue Feb 18 12:51:10 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 18 Feb 2014 12:51:10 +0100 Subject: [erlang-questions] otp_build: default-enable silent-rules Message-ID: I'd like to vote for default-enabling silent-rules in OTP's build system. It's much easier to spot new warnings with silent rules enabled, and I don't know of a good reason to keep it opt-in. Are there any arguments to keep it default-disabled? @Anthony, any particular reason you chose CPP over CXX as the prefix for compiling C++ sources? Wouldn't CXX be more in line with prefixes like CC? If there are no objections, I can submit a patch to make both changes. From n.oxyde@REDACTED Tue Feb 18 12:59:09 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 18 Feb 2014 12:59:09 +0100 Subject: [erlang-questions] otp_build: default-enable silent-rules In-Reply-To: References: Message-ID: <1061F786-8033-415B-BB80-B0084B81F70C@gmail.com> I didn?t, it was CPP before, it is still CPP after. Cf. the commit which fixes wx silent rules. https://github.com/erlang/otp/commit/fb66fdcf7a03c2bc1c64ce35dc261865d12992ab -CPP_O = $(CPP) -c $(CXX_FLAGS) $(WX_CXX_FLAGS) $(COMMON_CFLAGS) +CPP_O = $(V_CPP) -c $(CXX_FLAGS) $(WX_CXX_FLAGS) $(COMMON_CFLAGS) lib/wx/c_src/Makefile.in:114:CPP_O = $(V_CPP) -c $(CXX_FLAGS) $(WX_CXX_FLAGS) $(COMMON_CFLAGS) That?s the only place V_CPP is used. Silent rules by default will also make omitted rules stand up more and be fixed faster. Regards, -- Anthony Ramine Le 18 f?vr. 2014 ? 12:51, Tuncer Ayaz a ?crit : > @Anthony, any particular reason you chose CPP over CXX as the prefix for > compiling C++ sources? Wouldn't CXX be more in line with prefixes like CC? From n.oxyde@REDACTED Tue Feb 18 13:00:16 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 18 Feb 2014 13:00:16 +0100 Subject: [erlang-questions] modular otp concerns In-Reply-To: References: Message-ID: <96B51306-2F93-4D81-A726-91EB950A08B0@gmail.com> Indeed, what are they? If volunteers are needed, count me in, I?ve always enjoyed fighting build systems and practicing Git surgery. -- Anthony Ramine Le 18 f?vr. 2014 ? 12:48, Tuncer Ayaz a ?crit : > What are the exact plans? From erlang@REDACTED Tue Feb 18 13:13:11 2014 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 18 Feb 2014 13:13:11 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <8CBFA302-A6B1-46A5-9102-E33E0F9FFC7B@gmail.com> References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <53018DE1.1090901@meetinghouse.net> <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> <53021D9F.7060605@meetinghouse.net> <8CBFA302-A6B1-46A5-9102-E33E0F9FFC7B@gmail.com> Message-ID: On Tue, Feb 18, 2014 at 9:45 AM, Dmitry Kolesnikov wrote: > Hello, > > 1) A decent standardized Manifest. > > The app file by itself is a good place to be manifest. > the env section might be expanded with following keys: > * url > * signature > * ... > > 2) Packages should NOT be unpacked on the destination machine. > > > What is wrong with erlang archive files? > I already said this, 27 lines after the point 2) heading. I'll repeat this: Q: Why should the top level package be a PDF file? A: Because the *first* thing I want to do is read the documentation. I won't even look at a program that has no documentation - it's a waste of time. /Joe > > - Dmitry > > On 18 Feb 2014, at 10:34, Joe Armstrong wrote: > > Thank you Gordon,The absence of a decent package manager as disturbed me > for a long time. > > I'd like to add a few thoughts I have on the matter. > > Excuse the rant - I feel rather strongly about this. This is written great > haste. > I have to give a lecture in 20 minutes. > > Here are some things I'd like to see: > > 1) A decent standardized Manifest. > > A manifest is just a list of files and a short description. It also > has copyright and licensing information, and possible authentication > checksums and proof signatures. > > Nothing fancy - but it needs a standard. > > I don't feel strong about the format or the content. but it MUST have > a version number :-) > > > > 2) Packages should NOT be unpacked on the destination machine. > > Unpacking a package BREAKS an abstraction boundary. I feel VERY > STRONGLY about this. I hate unpacking things and finding that they > scatter thousands of files all over my disk. > > Here's a radical proposal. The top level package should be a PDF file. > > In 2001 ago I wrote this > > http://www.sics.se/~joe/erlpdf.pdf - Read it, download it, try it, think > about it. > > This a simple program that packs a file inside a PDF container. It still > works. > It seems like the one line description on my sics web page did not cause a > stir of > interest in the program (which I thought was a fun idea) so I'll now > publicize the idea a bit more. > > > > > Q: Why should the top level package be a PDF file? > A: Because the *first* thing I want to do is read the documentation. > I won't even look at a program that has no documentation - it's a waste > of time. > > Q: Why should the top level package not be unpacked? > A: Because it breaks an abstraction boundary, make it difficult to delete > things etc. > > I don't have to unpack a jar file to execute the program in it. I > don't have to unpack a .exe file to execute it so WHY IN THE NAME OF > THE GREAT SLIMY THING THAT LIVES UNDER STONES should I have to unpack > an Erlang package to execute the code in it? > > When I want to use say (cowboy) I just want to execute the code - I > don't want to see all the details of what going on inside the program - > I don't want to know that it is made of loads of modules - I want to > hide the details - this is called ABSTRACTION. > > They tell me that they teach OO programming these days - I thought the > idea of an object > was to HIDE THE DETAILS OF THE OBJECT INSIDE THE OBJECT - so why do > people who have been brought up on OO programming insist on writing > programs that scatter files all over my disk? Hide your mess in a > single container. Pleeeeeese. > > Q: How do I install a program? > A: Put the PDF in the directory ${HOME}/.erlang_programs/ > > Q: How do I delete the program? > A: Remove a single file from ${HOME}/.erlang_programs/ > > Q: How do I develop the program? > A: Unpack the PDF file *somewhere else* > > > 3) How should we distribute programs? > > Why not just use Bit Torrent? - we can self-seed our code, and seed > code we approve of That way popular code will be multiply seeded and > unpopular code with wither and die. > > We could use Jespers Bit torrent client and adapt it a bit so it knows > about Erlang packages. > > To do this we need > > a) Trackers (easy) > b) an Index (needs a publishing protocol) > c) clients > > Erlang solutions etc. can trackers. > > The code can be ANYWHERE YOU FEEL LIKE and not on github. > > Putting stuff on github is for collaboration purposes, not for > distributing code. > Use BitTorrent for this. > > > > Cheers > > /Joe > > > > On Mon, Feb 17, 2014 at 11:33 PM, Gordon Guthrie wrote: > >> This is what I sent to Francesco >> >> >> **************************************************************************************** >> >> *Building The Erlang Community* >> >> *Background* >> >> Erlang has long lacked a solid community core to act as a place where >> users can discover existing modules and include them in their projects. >> >> *rebar *now provides the standard mechanism to include external >> dependencies - this proposal is about making erldocs the standard place to >> discover community contributions. >> >> *Proposal 1* >> >> The proposal is that people who publish open source Erlang modules on >> GitHub be able to have them listed on erldocs. >> >> The process would be two part: >> >> - >> >> commit a page called *ERLDOCS.terms* to github in the root next to >> *README.md* >> - >> >> submit the URL to a page on erldocs >> - >> >> erldocs would sook the github page into a community section >> >> >> The structure of the *ERLDOCS.terms* file is simple tagged tuples, >> something like: >> >> *{name, "Starling"}.* >> >> *{license, "EPL"}.* >> >> *{description, "Unicode support for Erlang"}.* >> >> *{details, "A C-Port wrapped around the ICU library for unicode"}.* >> >> *{status, "production"}. % alpha | beta | production* >> >> *{rebar, {version, "1"}, {starling, {git, "git://**github.com/hypernumbers/starling.git >> **","master"}}}.* >> >> *Proposal 2* >> >> Dale Harvey originally intended that erldocs should include the ability >> for members of the community to annotate the official documents with >> examples, links to tutorials etc, etc. >> >> erldocs be so extended (by use of Disqus or other standard commenting >> systems) >> >> *Requirements For Success* >> >> Erldocs 'failed' last time out because the OTP team changed the way >> documents were generated, and Dale Harvey moved on from an Erlang shop to >> Mozilla. >> >> In order for this to work Erlang Solutions has to commit to: >> >> - >> >> erldocs being the official community repository for Erlang >> documentation - linked to directly from *erlang.org >> * >> - >> >> production of these documents needs to be integrated into the OTP >> Team's release schedule >> >> *Modalities* >> >> If Erlang Solutions so agree the next stage would be to approach a number >> of suppliers of top-notch Erlang open source and sign them up for launch. >> My working list would be: >> >> - >> >> Erlang Solutions >> - >> >> Basho >> - >> >> Erlware >> - >> >> Mats Cronquist >> - >> >> Richard Carlsson >> - >> >> Yaws >> - >> >> Mochiweb >> - >> >> Nitrogen >> - >> >> Cowboy >> - >> >> Web Machine >> - >> >> Hypernumbers >> >> >> There would need to be consultation with the launch group regarding the >> structure and elements of the term file. >> >> Once they were onboard and the production cycle had been tested - an open >> launch on the mailing list. >> >> >> **************************************************************************************** >> >> The key point is that a community is only a real community if you choose >> to join it. I was 'joined' to the Agner community (and there have been >> other attempts, Erlware, CEAN, etc) but they don't stick. >> >> Gordon >> >> >> On 17 February 2014 22:28, Mark Allen wrote: >> >>> On 2/17/14 4:21 PM, "Garrett Smith" wrote: >>> >> On 2/17/14 1:51 PM, "Vixo" wrote: >>> >>>My suggestion would be a manifest file of Erlang terms at the root >>> level >>> >>>of a GitHub page (they will *all* be on GitHub) that can be polled and >>> >>>turned into a static site. The logical thing to do would be combine >>> thus >>> >>>with the revived erldocs site IMHO (as I have said to Francesco) >>> >>> >Does this require that all of github be crawled? >>> >>> No. I'm pretty sure we can segment the crawl to only projects with some X >>> threshold of Erlang. (I'll have a slice without so much rat in it. [0]) >>> >>> >Would a github based index make sense? Complete with a liberal pull >>> >request policy? >>> >>> Most likely, yes, using github pages with a nice custom domain would be a >>> Good Thing for this type of project. The code to do the crawl and build >>> the index should be open source too, imo. >>> >>> Mark >>> >>> [0]: >>> >>> http://en.wikiquote.org/wiki/Monty_Python's_Flying_Circus#The_Money_Program >>> me_.5B3.03.5D >>> >>> >> >> >> -- >> --- >> Gordon Guthrie >> CEO vixo.com >> @gordonguthrie >> +44 (0) 7776 251669 (in Bonnie Scotland!) >> >> vixo is made in Scotland from electrons >> >> _______________________________________________ >> 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 tuncer.ayaz@REDACTED Tue Feb 18 13:14:55 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 18 Feb 2014 13:14:55 +0100 Subject: [erlang-questions] modular otp concerns In-Reply-To: References: Message-ID: Here's my second concern I accidentally forgot to include in the original email: If you split libs into independent projects, how will you retain the ability to make project wide refactoring and API changes. Right now it's very practical that we can change erts or stdlib/kernel and adapt all of lib/*. From aaron.l.france@REDACTED Tue Feb 18 13:21:10 2014 From: aaron.l.france@REDACTED (Aaron France) Date: Tue, 18 Feb 2014 13:21:10 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <8CBFA302-A6B1-46A5-9102-E33E0F9FFC7B@gmail.com> Message-ID: <20140218122110.GA1876@xenocorp> On Tue, Feb 18, 2014 at 01:13:11PM +0100, Joe Armstrong wrote: > On Tue, Feb 18, 2014 at 9:45 AM, Dmitry Kolesnikov > wrote: > > > Hello, > > > > 1) A decent standardized Manifest. > > > > The app file by itself is a good place to be manifest. > > the env section might be expanded with following keys: > > * url > > * signature > > * ... > > > > 2) Packages should NOT be unpacked on the destination machine. > > > > > > What is wrong with erlang archive files? > > > > I already said this, 27 lines after the point 2) heading. > > I'll repeat this: > > Q: Why should the top level package be a PDF file? > > A: Because the *first* thing I want to do is read the documentation. > I won't even look at a program that has no documentation - it's a waste > of time. > > Then you mustn't use the vast, vast majority of Erlang projects. > > > /Joe > > > > > > - Dmitry > > > > On 18 Feb 2014, at 10:34, Joe Armstrong wrote: > > > > Thank you Gordon,The absence of a decent package manager as disturbed me > > for a long time. > > > > I'd like to add a few thoughts I have on the matter. > > > > Excuse the rant - I feel rather strongly about this. This is written great > > haste. > > I have to give a lecture in 20 minutes. > > > > Here are some things I'd like to see: > > > > 1) A decent standardized Manifest. > > > > A manifest is just a list of files and a short description. It also > > has copyright and licensing information, and possible authentication > > checksums and proof signatures. > > > > Nothing fancy - but it needs a standard. > > > > I don't feel strong about the format or the content. but it MUST have > > a version number :-) > > > > > > > > 2) Packages should NOT be unpacked on the destination machine. > > > > Unpacking a package BREAKS an abstraction boundary. I feel VERY > > STRONGLY about this. I hate unpacking things and finding that they > > scatter thousands of files all over my disk. > > > > Here's a radical proposal. The top level package should be a PDF file. > > > > In 2001 ago I wrote this > > > > http://www.sics.se/~joe/erlpdf.pdf - Read it, download it, try it, think > > about it. > > > > This a simple program that packs a file inside a PDF container. It still > > works. > > It seems like the one line description on my sics web page did not cause a > > stir of > > interest in the program (which I thought was a fun idea) so I'll now > > publicize the idea a bit more. > > > > > > > > > > Q: Why should the top level package be a PDF file? > > A: Because the *first* thing I want to do is read the documentation. > > I won't even look at a program that has no documentation - it's a waste > > of time. > > > > Q: Why should the top level package not be unpacked? > > A: Because it breaks an abstraction boundary, make it difficult to delete > > things etc. > > > > I don't have to unpack a jar file to execute the program in it. I > > don't have to unpack a .exe file to execute it so WHY IN THE NAME OF > > THE GREAT SLIMY THING THAT LIVES UNDER STONES should I have to unpack > > an Erlang package to execute the code in it? > > > > When I want to use say (cowboy) I just want to execute the code - I > > don't want to see all the details of what going on inside the program - > > I don't want to know that it is made of loads of modules - I want to > > hide the details - this is called ABSTRACTION. > > > > They tell me that they teach OO programming these days - I thought the > > idea of an object > > was to HIDE THE DETAILS OF THE OBJECT INSIDE THE OBJECT - so why do > > people who have been brought up on OO programming insist on writing > > programs that scatter files all over my disk? Hide your mess in a > > single container. Pleeeeeese. > > > > Q: How do I install a program? > > A: Put the PDF in the directory ${HOME}/.erlang_programs/ > > > > Q: How do I delete the program? > > A: Remove a single file from ${HOME}/.erlang_programs/ > > > > Q: How do I develop the program? > > A: Unpack the PDF file *somewhere else* > > > > > > 3) How should we distribute programs? > > > > Why not just use Bit Torrent? - we can self-seed our code, and seed > > code we approve of That way popular code will be multiply seeded and > > unpopular code with wither and die. > > > > We could use Jespers Bit torrent client and adapt it a bit so it knows > > about Erlang packages. > > > > To do this we need > > > > a) Trackers (easy) > > b) an Index (needs a publishing protocol) > > c) clients > > > > Erlang solutions etc. can trackers. > > > > The code can be ANYWHERE YOU FEEL LIKE and not on github. > > > > Putting stuff on github is for collaboration purposes, not for > > distributing code. > > Use BitTorrent for this. > > > > > > > > Cheers > > > > /Joe > > > > > > > > On Mon, Feb 17, 2014 at 11:33 PM, Gordon Guthrie wrote: > > > >> This is what I sent to Francesco > >> > >> > >> **************************************************************************************** > >> > >> *Building The Erlang Community* > >> > >> *Background* > >> > >> Erlang has long lacked a solid community core to act as a place where > >> users can discover existing modules and include them in their projects. > >> > >> *rebar *now provides the standard mechanism to include external > >> dependencies - this proposal is about making erldocs the standard place to > >> discover community contributions. > >> > >> *Proposal 1* > >> > >> The proposal is that people who publish open source Erlang modules on > >> GitHub be able to have them listed on erldocs. > >> > >> The process would be two part: > >> > >> - > >> > >> commit a page called *ERLDOCS.terms* to github in the root next to > >> *README.md* > >> - > >> > >> submit the URL to a page on erldocs > >> - > >> > >> erldocs would sook the github page into a community section > >> > >> > >> The structure of the *ERLDOCS.terms* file is simple tagged tuples, > >> something like: > >> > >> *{name, "Starling"}.* > >> > >> *{license, "EPL"}.* > >> > >> *{description, "Unicode support for Erlang"}.* > >> > >> *{details, "A C-Port wrapped around the ICU library for unicode"}.* > >> > >> *{status, "production"}. % alpha | beta | production* > >> > >> *{rebar, {version, "1"}, {starling, {git, "git://**github.com/hypernumbers/starling.git > >> **","master"}}}.* > >> > >> *Proposal 2* > >> > >> Dale Harvey originally intended that erldocs should include the ability > >> for members of the community to annotate the official documents with > >> examples, links to tutorials etc, etc. > >> > >> erldocs be so extended (by use of Disqus or other standard commenting > >> systems) > >> > >> *Requirements For Success* > >> > >> Erldocs 'failed' last time out because the OTP team changed the way > >> documents were generated, and Dale Harvey moved on from an Erlang shop to > >> Mozilla. > >> > >> In order for this to work Erlang Solutions has to commit to: > >> > >> - > >> > >> erldocs being the official community repository for Erlang > >> documentation - linked to directly from *erlang.org > >> * > >> - > >> > >> production of these documents needs to be integrated into the OTP > >> Team's release schedule > >> > >> *Modalities* > >> > >> If Erlang Solutions so agree the next stage would be to approach a number > >> of suppliers of top-notch Erlang open source and sign them up for launch. > >> My working list would be: > >> > >> - > >> > >> Erlang Solutions > >> - > >> > >> Basho > >> - > >> > >> Erlware > >> - > >> > >> Mats Cronquist > >> - > >> > >> Richard Carlsson > >> - > >> > >> Yaws > >> - > >> > >> Mochiweb > >> - > >> > >> Nitrogen > >> - > >> > >> Cowboy > >> - > >> > >> Web Machine > >> - > >> > >> Hypernumbers > >> > >> > >> There would need to be consultation with the launch group regarding the > >> structure and elements of the term file. > >> > >> Once they were onboard and the production cycle had been tested - an open > >> launch on the mailing list. > >> > >> > >> **************************************************************************************** > >> > >> The key point is that a community is only a real community if you choose > >> to join it. I was 'joined' to the Agner community (and there have been > >> other attempts, Erlware, CEAN, etc) but they don't stick. > >> > >> Gordon > >> > >> > >> On 17 February 2014 22:28, Mark Allen wrote: > >> > >>> On 2/17/14 4:21 PM, "Garrett Smith" wrote: > >>> >> On 2/17/14 1:51 PM, "Vixo" wrote: > >>> >>>My suggestion would be a manifest file of Erlang terms at the root > >>> level > >>> >>>of a GitHub page (they will *all* be on GitHub) that can be polled and > >>> >>>turned into a static site. The logical thing to do would be combine > >>> thus > >>> >>>with the revived erldocs site IMHO (as I have said to Francesco) > >>> > >>> >Does this require that all of github be crawled? > >>> > >>> No. I'm pretty sure we can segment the crawl to only projects with some X > >>> threshold of Erlang. (I'll have a slice without so much rat in it. [0]) > >>> > >>> >Would a github based index make sense? Complete with a liberal pull > >>> >request policy? > >>> > >>> Most likely, yes, using github pages with a nice custom domain would be a > >>> Good Thing for this type of project. The code to do the crawl and build > >>> the index should be open source too, imo. > >>> > >>> Mark > >>> > >>> [0]: > >>> > >>> http://en.wikiquote.org/wiki/Monty_Python's_Flying_Circus#The_Money_Program > >>> me_.5B3.03.5D > >>> > >>> > >> > >> > >> -- > >> --- > >> Gordon Guthrie > >> CEO vixo.com > >> @gordonguthrie > >> +44 (0) 7776 251669 (in Bonnie Scotland!) > >> > >> vixo is made in Scotland from electrons > >> > >> _______________________________________________ > >> 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 -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From tuncer.ayaz@REDACTED Tue Feb 18 13:23:22 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 18 Feb 2014 13:23:22 +0100 Subject: [erlang-questions] otp_build: default-enable silent-rules In-Reply-To: <1061F786-8033-415B-BB80-B0084B81F70C@gmail.com> References: <1061F786-8033-415B-BB80-B0084B81F70C@gmail.com> Message-ID: On Tue, Feb 18, 2014 at 12:59 PM, Anthony Ramine wrote: > I didn't, it was CPP before, it is still CPP after. > > Cf. the commit which fixes wx silent rules. > > https://github.com/erlang/otp/commit/fb66fdcf7 > > -CPP_O = $(CPP) -c $(CXX_FLAGS) $(WX_CXX_FLAGS) $(COMMON_CFLAGS) > +CPP_O = $(V_CPP) -c $(CXX_FLAGS) $(WX_CXX_FLAGS) $(COMMON_CFLAGS) > > lib/wx/c_src/Makefile.in:114:CPP_O > = $(V_CPP) -c $(CXX_FLAGS) $(WX_CXX_FLAGS) $(COMMON_CFLAGS) > > That's the only place V_CPP is used. So, you wouldn't mind changing the printed prefix to CXX, right? > Silent rules by default will also make omitted rules stand up more > and be fixed faster. And maybe annoy enough contributors that we can reach warning free builds :). From n.oxyde@REDACTED Tue Feb 18 13:30:20 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 18 Feb 2014 13:30:20 +0100 Subject: [erlang-questions] otp_build: default-enable silent-rules In-Reply-To: References: <1061F786-8033-415B-BB80-B0084B81F70C@gmail.com> Message-ID: <97D8B3DF-96D0-4803-9BC3-60CFC30341BA@gmail.com> Nope, wouldn?t mind that. This was a methodical change, didn?t think about variable names when doing it. -- Anthony Ramine Le 18 f?vr. 2014 ? 13:23, Tuncer Ayaz a ?crit : > So, you wouldn't mind changing the printed prefix to CXX, right? From erlang@REDACTED Tue Feb 18 13:38:09 2014 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 18 Feb 2014 13:38:09 +0100 Subject: [erlang-questions] (not) packing code to PDF [was: What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]]] In-Reply-To: References: Message-ID: On Tue, Feb 18, 2014 at 10:39 AM, Motiejus Jak?tys wrote: > On Tue, Feb 18, 2014 at 9:34 AM, Joe Armstrong wrote: > > Here's a radical proposal. The top level package should be a PDF file. > > > > In 2001 ago I wrote this > > > > http://www.sics.se/~joe/erlpdf.pdf - Read it, download it, try it, think > > about it. > > Does not render correctly in my document viewer (evince) and does not > render at all in Iceweasel 25 embedded pdf viewer. > That's strange It displays correctly in my evince (vsn 3.4.0) and also in adobe reader 9. I follow the PDF standard (At least I hope I do) so it should be ok. > > > This a simple program that packs a file inside a PDF container. It still > > works. > <...> > > Q: Why should the top level package be a PDF file? > > A: Because the *first* thing I want to do is read the documentation. > > I won't even look at a program that has no documentation - it's a > waste > > of time. > > I could agree if I really needed to*. But: > 1. Not everything can be pre-compiled (nifs and port drivers come to mind) > I was thinking of having pre-compiled binaries for different OSs here > 2. This severely limits the documentation representation. What if my > documentation is a rich Web Page which requires html5 to tickle my > fancy? In PDF we are sort of limited to... PDF. > You could put all the beam code/whatever in a > > A quick fix for 2014 onwards: we have OpenDocument and Office Open XML > which are just zip files with many more tools to manipulate. Loading > stuff from zip archives is something we already do (except nifs, yes). > We just need a file extension. > > Indeed - I just wanted the top level to be the documentation since that's what's I wanted to see first. You could put inside a jpeg file as an exif comment I guess and have pictures of earwigs for all I care. The point is that it's in a container that should not be unpacked. /Joe > :: EAR :: > > Motiejus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard@REDACTED Tue Feb 18 13:42:20 2014 From: rickard@REDACTED (Rickard Green) Date: Tue, 18 Feb 2014 13:42:20 +0100 Subject: [erlang-questions] FW: Version numbering scheme change and the implication / Re: [ANN] Erlang/OTP 17.0-rc1 has been released. In-Reply-To: References: <52F4C173.8050408@erlang.org> <1391790979.26271.YahooMailNeo@web140106.mail.bf1.yahoo.com> <49EC93AB-69A4-49AB-A2C0-4DA9F418E3F6@gmail.com> <58912684E2630B45963406CF7D8C52581C3473C6@ESESSMB103.ericsson.se> <52FB2C0E.90008@erlang.org> <58912684E2630B45963406CF7D8C52581C348431@ESESSMB103.ericsson.se> <52FCC466.9060206@erlang.org> <20140213164102.GJ62889@ferdair.local> Message-ID: We've decided not to add an erlang:system_info(otp_version), not to add an -otp_version command line argument to erl, and to remove the erlang:system_info(otp_correction_package) that is part of OTP 17.0-rc1. Instead we will add a text-file OTP_VERSION which will contain current OTP version. Info about the OTP_VERSION file will be documented in the documentation of erlang:system_info(otp_release) (see below). The upcoming documentation of erlang:system_info(otp_release) : Returns a string containing the OTP release number of the OTP release that the currently executing ERTS application is part of. As of OTP release 17, the OTP release number corresponds to the major OTP version number. The OTP version as a concept was introduced in OTP 17. There is no erlang:system_info() argument giving the exact OTP version. This since the exact OTP version in the general case is hard to determine. In an OTP source code tree as well as in an installed OTP development system, the OTP version can be read from the text file OTP_VERSION in the code:root_dir() directory. If the version read from the OTP_VERSION file in a development system has a ** suffix, the system has been patched using the '$ERL_TOP/otp_build patch_app' tool. In this case, the system consists of parts from multiple OTP versions. The version preceding the ** suffix corresponds to the OTP version of the base system that has been patched. On a target system (see the system principles documentation) no OTP_VERSION file will exist. This since one easily can create a target system where it is hard to even determine the base OTP version. Note that if a development system is updated by other means than '$ERL_TOP/otp_build patch_app', the OTP_VERSION file may erroneously identify an exact OTP version. Regards, RIckard Green, Erlang/OTP, Ericsson AB On Thu, Feb 13, 2014 at 5:49 PM, Vlad Dumitrescu wrote: > On Thu, Feb 13, 2014 at 5:41 PM, Fred Hebert wrote: >> ? erl -noshell -eval 'io:format("~s~n",[erlang:system_info(otp_correction_package)]),halt(0).' >> 17.0-rc1 >> >> It is objectively longer than having -V switch, loads more content, but >> gets the result you want as one command line option. Adding in the >> options '-noinput +A 0 -smp disable' to the command brings it below >> 0.15s on my VPS, usually below something noticeable. > > Thanks, but my use case is to have a number of erlang installations > and detect which version each is (looking at the directory name > doesn't always help). 0.15s*5 is noticeable and it's not that fast on > all filesystems (think clearcase)... Of course, I have this workaround > as backup. The issue is that the information was available before, but > is going away now with the new version scheme. > > regards, > Vlad > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From tuncer.ayaz@REDACTED Tue Feb 18 13:53:09 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 18 Feb 2014 13:53:09 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <20140218113641.GA13616@k2r.org> References: <53018DE1.1090901@meetinghouse.net> <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> <53021D9F.7060605@meetinghouse.net> <530325D2.4090303@erl.io> <6F9CBF02-CE44-487E-84D0-16998E5DCC42@gmail.com> <20140218113641.GA13616@k2r.org> Message-ID: On Tue, Feb 18, 2014 at 12:36 PM, Kenji Rikitake wrote: > A practical issue: uploading to GitHub is *painfully slow* > (< 200kbytes/sec) In one go with no retry or resume? Is it the same on different .jp networks? > (I once had to upload 40GB and that was a four-day work from Japan. :-/) > > Another issue I've seen: git-tagging itself won't automatically > resolve the conflict issues. Quite often you need to tag on an > individual commit for "stashing" the later commits as a workaround. > > Git is OK. I even use it at home with gitosis. Maybe in some cases > Mercurial, or even svn, would be more appropriate. > > I think depending on GitHub is not good, though. I've said it before in another package repo discussion, but I'd like to second the opinion that making use of a mirror network is crucial. Reliability and distributed availability are very important. According to mirrors.cpan.org, it is mirrored on 486 sites, and I think Erlang's FOSS projects qualify to be distributed in a mirror network, too. For FOSS projects it doesn't make sense to have a central package repo operated by a commercial entity. I don't know how CPAN is maintained, but it seems to have served them well and should be considered as inspiration. Finally, do not underestimate the importance of having an archive of old versions. > Just my JPY 2 worth, > Kenji Rikitake > > ++> Anthony Ramine [2014-02-18 10:49:34 +0100]: >> Note that I have nothing against using Git to *host* things (but I >> do think tarballs are better and simpler to manage), I specifically >> said ? GitHub ?, your mail suggests using its proprietary API to do >> fancy stuff From egil@REDACTED Tue Feb 18 14:00:59 2014 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Tue, 18 Feb 2014 14:00:59 +0100 Subject: [erlang-questions] Preloaded modules "lists" dependency In-Reply-To: <1392668140.48109.YahooMailNeo@web140102.mail.bf1.yahoo.com> References: <52FDF77B.4070907@ninenines.eu> <53021947.4070500@ninenines.eu> <1392668140.48109.YahooMailNeo@web140102.mail.bf1.yahoo.com> Message-ID: <5303598B.4050701@erlang.org> On 2014-02-17 21:15, Thomas Lindgren wrote: > > "The "OTP2" part interests me a lot more. One of my favorite ideas is to > be able to define the whole supervision tree in a single module, and to > have it feature more complex components like pools for example. It could > come with a default pool implementation, with a well defined interface > (from the point of view of the supervision tree) that allows it to be > replaced with whichever one you want. So instead of having 10 modules > describing your application, it could all be in a very visual format ..." I think these kind of enhancements is the ones that should be researched and written about. I would like to see either an extensive blog article, a white paper or an EUC / Factory presentation on different approaches or extensions to the existing OTP principals. I don't want to see code. I want to see how it would fit together, described using small words and visual aids. // Bj?rn-Egil > > > On Monday, February 17, 2014 3:43 PM, Lo?c Hoguin > wrote: > > Thoughts and ideas are not worth a lot until they are tested so I > will > spare you most details for now. It's still a pretty long read. > > For the "Erlang2" part, there isn't much to say. Erlang is a language > that is almost perfect. My conclusions about improving it are that > there > are very few things that can be improved, and they are mostly edge > cases > (shadowing would be a big one, and not being able to do (<< > B:Len/binary, _/bits >>, Len) in a function clause would be another - > but the latter is going to be solved soon as I gather). The rest > of it, > well, I came pretty much to the same conclusions as Joe, the only > thing > I would add is a basic form of metaprogramming. Basically you want > to be > able to do two things: compute some data at compile time, and run > tests > at compile time (and fail to compile if the tests fail). Optionally > would allow you to do some conditional builds to work around > issues with > a specific version of Erlang. But no macros or other weird stuff that > just make the code more complex for no good reasons. > > I'm no language expert and I'm not too interested in this part so > don't > expect anything from me on that point. If I ever attempt something it > would just be a very basic wrapper on top of the current Erlang > syntax > to allow for compile-time stuff to happen (meaning: outside > functions, > and perhaps even outside modules entirely). > > The "OTP2" part interests me a lot more. One of my favorite ideas > is to > be able to define the whole supervision tree in a single module, > and to > have it feature more complex components like pools for example. It > could > come with a default pool implementation, with a well defined > interface > (from the point of view of the supervision tree) that allows it to be > replaced with whichever one you want. So instead of having 10 modules > describing your application, it could all be in a very visual > format in > a single module. > > I'm more interested in doing an "OTP2" that targets a different > use than > long running server applications though. As you might already know, I > like video games, and I have tried a few quick prototypes of games > with > Erlang. I think there is a lot of potential, but the barrier of > entry is > very high. An "OTP2" geared toward games would help greatly. Games > typically have a main loop. There's basically no way around that > today > because most graphic APIs aren't thread safe. SDL2 was released > not too > long ago for example, and it still isn't thread safe. But that's > not a > big problem, Erlang's concurrency can still play a big part. For > example, by making the lists module parallelize processing of the > list > automatically past a certain threshold. Or providing efficient timer > capabilities (because the timer module ain't it). And the > processes that > access the API can always be tied to scheduler 0 to avoid any issues. > > I started playing around making an SDL2 NIF this week-end. The first > thing you instantly win is not having to worry about freeing > resources > (with a few gotchas of course, you can only have so much in > memory). The > GC does it for you! The second thing you instantly win is Erlang's > pattern matching. The article I wrote about matching tic tac toe > solutions directly instead of trying to write an algorithm is a good > example of that. The code becomes small and clear and you can > focus on > actually building the game. > > Of course, for anything to come out of these experiments, I have > to find > a way to not get bored, which may prove difficult. Time will tell. > > On 02/17/2014 01:30 PM, Pierre Fenoll wrote: > > Hey Lo?c, > > > > I don't mean to hijack the thread. > > Can we have more information on "Erlang2/OTP2"? Your guidelines and > > back-of-a-napkin experiments interest me greatly. > > > > > > Cheers, > > > > > > > > _______________________________________________ > > 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 > > > > Take a look at this: https://github.com/thomasl/gen_app > > Here is one application I just started: > > 1> gen_app:app_sup(om, [{sup, {sup, om, [om_ets_owner, > om_repository_server, om_code_server]}). > > Which starts a (dynamic) application 'om' with a supervisor 'om' > handling three gen_servers on localhost. > > Caveats: Somewhat inelegant notation so far, and you still need > 'application' for the more complex cases. No pool handling at the > moment either. But it's pretty compact. > > Best, > Thomas > > PS. Apologies to those I've written to recently -- Yahoo is acting up, > perhaps due to THE HUGE THREADS we're having, so I'm having some > trouble reading my mail at the moment. Sporadically hanging client, etc. > > > _______________________________________________ > 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 Feb 18 14:13:18 2014 From: sdl.web@REDACTED (Leo Liu) Date: Tue, 18 Feb 2014 21:13:18 +0800 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <20140218122110.GA1876@xenocorp> (Aaron France's message of "Tue, 18 Feb 2014 13:21:10 +0100") References: <8CBFA302-A6B1-46A5-9102-E33E0F9FFC7B@gmail.com> <20140218122110.GA1876@xenocorp> Message-ID: On 2014-02-18 20:21 +0800, Aaron France wrote: > Then you mustn't use the vast, vast majority of Erlang projects. Good projects come with good documentation because they are meant to be (re-)used. There are loads of rubbish erlang code out there. Maybe the community could outlaw them? Cheers Leo From essen@REDACTED Tue Feb 18 14:26:19 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 18 Feb 2014 14:26:19 +0100 Subject: [erlang-questions] Preloaded modules "lists" dependency In-Reply-To: <5303598B.4050701@erlang.org> References: <52FDF77B.4070907@ninenines.eu> <53021947.4070500@ninenines.eu> <1392668140.48109.YahooMailNeo@web140102.mail.bf1.yahoo.com> <5303598B.4050701@erlang.org> Message-ID: <53035F7B.7020904@ninenines.eu> On 02/18/2014 02:00 PM, Bj?rn-Egil Dahlberg wrote: > On 2014-02-17 21:15, Thomas Lindgren wrote: >> >> "The "OTP2" part interests me a lot more. One of my favorite ideas is to >> be able to define the whole supervision tree in a single module, and to >> have it feature more complex components like pools for example. It could >> come with a default pool implementation, with a well defined interface >> (from the point of view of the supervision tree) that allows it to be >> replaced with whichever one you want. So instead of having 10 modules >> describing your application, it could all be in a very visual format ..." > > I think these kind of enhancements is the ones that should be researched > and written about. > > I would like to see either an extensive blog article, a white paper or > an EUC / Factory presentation on different approaches or extensions to > the existing OTP principals. I don't want to see code. I want to see how > it would fit together, described using small words and visual aids. That will eventually happen, but experimenting with code is part of my thought process: 1- Think. *A LOT*. This can take anywhere from weeks to years. 2- Write down a tentative interface for how it would all work. 3- Repeat 1 and 2 until happy with the interface. 4- Implement a prototype using that interface. 5- Repeat 1, 2, 3 and 4 until happy with the interface AND prototype. 6- Release it. Part 2 eventually becomes the manual/guide/article/.. It evolves from short notes to a fully fledged reference over the course of the process. And yes, I am very slow using this process. Don't use it if you have deadlines. As far as "OTP2" is concerned I'm still mostly in part 1 with a few short attempts at 2. I'm having too much fun doing other things at the moment. -- Lo?c Hoguin http://ninenines.eu From davidnwelton@REDACTED Tue Feb 18 14:28:14 2014 From: davidnwelton@REDACTED (David Welton) Date: Tue, 18 Feb 2014 14:28:14 +0100 Subject: [erlang-questions] random thought: connecting to node, specify IP address In-Reply-To: <20140218112612.GA13552@k2r.org> References: <20140218112612.GA13552@k2r.org> Message-ID: > Or build your own private DNS zone infrastructure. If you need to do a > dynamic register to the DNS, you've got to have one anyway. Unless you're > trying to enforce DNSSEC there, this won't be a big hassle. Not depending on > the DNS is a viable solution, nevertheless. The fewer dependencies the better. Ideally I'd be able to do something like you can do in C: addr.s_addr = inet_addr("134.138.177.89"); if (erl_connect_xinit("idril", "cnode", "cnode@REDACTED", &addr, "secretcookie", 0) == -1) That seems to work out ok even if the addr does not match the node name's DNS lookup. -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From essen@REDACTED Tue Feb 18 14:30:14 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 18 Feb 2014 14:30:14 +0100 Subject: [erlang-questions] modular otp concerns In-Reply-To: References: Message-ID: <53036066.3060404@ninenines.eu> On 02/18/2014 12:48 PM, Tuncer Ayaz wrote: > I know that at least Bjoern-Egil has been investigating the possibility of > splitting up otp.git into sub repos, and before anything is set into > stone, I'd like to resolve one concern I have. I thought he was the only proponent of this in the OTP team? -- Lo?c Hoguin http://ninenines.eu From mfidelman@REDACTED Tue Feb 18 14:42:28 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Tue, 18 Feb 2014 08:42:28 -0500 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: <5302AF10.10502@gmail.com> References: <53021AC4.8080303@meetinghouse.net> <53026F73.5080106@meetinghouse.net> <530299A5.8030501@meetinghouse.net> <5302AF10.10502@gmail.com> Message-ID: <53036344.7010202@meetinghouse.net> Michael Truog wrote: > On 02/17/2014 03:22 PM, Miles Fidelman wrote: >> Any thoughts on how to do this - perhaps in combination with >> extending the hibernate BIF? > Most people use gen_server with hibernate in the return value from the > callback (e.g., > http://www.erlang.org/doc/man/gen_server.html#Module:handle_call-3). > If you need something that is more complex, CloudI has a hibernate > service configuration option that allows you to hibernate based on the > incoming service request rate, so when the service request rate drops > too low, the process hibernates whenever possible > (http://cloudi.org/api.html#2_services_add_config_opts_hibernate). Ok... see that. Thanks! And thanks to Motiejus Jak?tys for the existence proof, sizing info, (and the checkpointing scheme - not quoted): > > One portability request is one process. At any time we could have had > up to 1M processes (practically it was much lower, but we used this > number when designing the system). A "portability process" is a finite > state machine with communication in SOAP between two or three parties > with many internal state changes. > > A single process could last from a few hours up to few months (median > ~3-4 days), each state up to 10-100KB of uncompressed text (mean ~15KB > uncompressed). > The question about extending the hibernate BIF, and maybe playing with the scheduler, focuses on scaling further - to Joe Armstrong's comments that: > Some kind of "getting things out of memory and onto disk when not > needed" layer is needed for your problem, > and > Yes - I guess the real solution would be to change the scheduler to > swap processes to disk after they had waited for more than (say) 10 > minutes for a message, and resurrect them when they are sent a message. It strikes me that hibernate addresses a big piece of the problem - reducing footprint of inactive processes, while keeping them "alive" (i.e., able to receive messages, wake up, and all that) - and when called via proc_lib:hibernate, keeps exception handling and logging working. For scaling, the next step would be to swap out to disk - if that happens as a hibernate to disk, all the other functionality would stick around (as opposed to an application level write-state-to-disk). Hence the question re. internals of the hibernate BIF and the scheduler, and how one might think about wiring in a hibernate-to-disk function. Anyway... the overall approach is starting to look feasible! Thanks! Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mononcqc@REDACTED Tue Feb 18 14:57:29 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Tue, 18 Feb 2014 08:57:29 -0500 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: <53036344.7010202@meetinghouse.net> References: <53021AC4.8080303@meetinghouse.net> <53026F73.5080106@meetinghouse.net> <530299A5.8030501@meetinghouse.net> <5302AF10.10502@gmail.com> <53036344.7010202@meetinghouse.net> Message-ID: <20140218135728.GO62889@ferdair.local> On 02/18, Miles Fidelman wrote: > > For scaling, the next step would be to swap out to disk - if that happens as > a hibernate to disk, all the other functionality would stick around (as > opposed to an application level write-state-to-disk). Hence the question > re. internals of the hibernate BIF and the scheduler, and how one might > think about wiring in a hibernate-to-disk function. > Be aware of the implicit state that exists within an application: pending requests, messages in a mailbox, links and monitors being set up, code versions being in use, sockets and file descriptors, etc. These things can be backed up, but reloading them does not promise a workable process with an equivalent environment upon reloading. You either have to write code that can deal with that, or prevent code that cannot deal with it from being written. Nevermind the really hard problem of finding consistent snapshots if your actors interact together. For example, if I have processes A, B, C communicating with each other and influencing each other, I likely want to make sure that my snapshots of A, B, and C yield a snapshot that will load them all back up in a sane manner. This means that if A sent a message to B, then I have to make sure my snapshots of A and B are done both after A sent the message and after received (or ideally: handled) it, unless I'm ready to reload state with B possessing information A doesn't know about, even if it sent it. This may lead to duplicated messages on reception, or just be similar to state corruption. Again, it's a really, really hard problem (especially if processes crash while you're trying to get things snapshotted!), and there are algorithm to work around them. For a quick intro, see: - http://en.wikipedia.org/wiki/Snapshot_algorithm for a basic one, where you can possibly already spot a bunch of issues with trying to make it work. - http://www.cs.mcgill.ca/~lli22/575/mattern93efficient.pdf for more algorithms and explanations - 'consistent cut' is the term used for all algorithms related to finding that snapshotting sweet spot. Googling around for 'consistent cut' will yield plenty of good intro material. My personal opinion is that this stuff is really hard to get right. I hope for your sake that your processes do not interact with each other too much :) Regards, Fred. From lukas@REDACTED Tue Feb 18 14:58:36 2014 From: lukas@REDACTED (Lukas Larsson) Date: Tue, 18 Feb 2014 14:58:36 +0100 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: <53036344.7010202@meetinghouse.net> References: <53021AC4.8080303@meetinghouse.net> <53026F73.5080106@meetinghouse.net> <530299A5.8030501@meetinghouse.net> <5302AF10.10502@gmail.com> <53036344.7010202@meetinghouse.net> Message-ID: On Tue, Feb 18, 2014 at 2:42 PM, Miles Fidelman wrote: > For scaling, the next step would be to swap out to disk - if that happens > as a hibernate to disk, all the other functionality would stick around (as > opposed to an application level write-state-to-disk). Hence the question > re. internals of the hibernate BIF and the scheduler, and how one might > think about wiring in a hibernate-to-disk function. > > If I were to do something like this I would first try to only put the heap and referenced off heap binaries to disk. This should be the majority of the memory footprint and will allow all process meta data (links, monitors, registry etc etc) to remain unaffected. The question is what to do about the stack which could contain pointers to code that has been changed while the process was hibernated. Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Tue Feb 18 15:04:25 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Tue, 18 Feb 2014 15:04:25 +0100 Subject: [erlang-questions] atoms with newlines Message-ID: Hi! Multi-line strings are a pain but at least I can understand the reason for having them. I can't find any reasonable use of atoms with names including newlines and I wonder if we could do anything about them... best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From baliulia@REDACTED Tue Feb 18 15:09:47 2014 From: baliulia@REDACTED (=?UTF-8?B?SWduYXMgVnnFoW5pYXVza2Fz?=) Date: Tue, 18 Feb 2014 15:09:47 +0100 Subject: [erlang-questions] disconnected nodes In-Reply-To: References: <53012CD1.7030605@gmail.com> Message-ID: <530369AB.9070502@gmail.com> Hi again, Thanks for the response. On 02/17/2014 11:23 AM, Ahmed Omar wrote: > The reason for the later incidents, was usually high traffic between > the nodes. That traffic could cause distribution buffer to reach > limits and suspend processes trying to communicate with other > processes on other nodes. > (http://erlang.org/doc/man/erlang.html#system_info_dist_buf_busy_limit) > > One quick work around for that would be to increase the limit using > +zdbbl flag on startup. A more permanent solution would be to look > into the traffic between the nodes and optimise there. By high traffic do you mean amount of messages or actual volume? AFAIK, +zdbbl is more of a possible cure for volume and battling things like TCP incast. However, in our case the network utilization does not go over ~20%, so I don't think TCP incast is playing role here. The number of messages is quite large, though. I bumped it to 32MB in any case, can't hurt. -- Ignas From vladdu55@REDACTED Tue Feb 18 15:11:29 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Tue, 18 Feb 2014 15:11:29 +0100 Subject: [erlang-questions] modular otp concerns In-Reply-To: References: Message-ID: Hi, On Tue, Feb 18, 2014 at 12:48 PM, Tuncer Ayaz wrote: > I know that at least Bjoern-Egil has been investigating the possibility of > splitting up otp.git into sub repos, and before anything is set into > stone, I'd like to resolve one concern I have. > > What will happen to the default distribution and the bundled libraries? > > Is the plan to split it into core and extra? I'm concerned that if we > follow that route, we would lose the ability to rely on pretty useful > functionality available out of the box. For example, today it's very > convenient that I can write an escript which: > * interacts with the network (http, ssh, snmp, etc.) > * compiles sources for various languages > * creates or extracts tarballs or zip archives > * inspects a (remote) node > * much more... One thought about this: there are several levels of modularity that could be enabled, but as a first step I think that what could be separated are the telecom-specific libraries (asn1, cos*, megaco, diameter). Snmp is on the fence. I think that such a modularization should start with support in the language/libraries for modularity and an application repository. regards, Vlad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Tue Feb 18 15:27:56 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Tue, 18 Feb 2014 09:27:56 -0500 Subject: [erlang-questions] modular otp concerns In-Reply-To: References: Message-ID: On Tue, Feb 18, 2014 at 9:11 AM, Vlad Dumitrescu wrote: > Hi, > > On Tue, Feb 18, 2014 at 12:48 PM, Tuncer Ayaz wrote: > >> I know that at least Bjoern-Egil has been investigating the possibility of >> splitting up otp.git into sub repos, and before anything is set into >> stone, I'd like to resolve one concern I have. >> >> What will happen to the default distribution and the bundled libraries? >> >> Is the plan to split it into core and extra? I'm concerned that if we >> follow that route, we would lose the ability to rely on pretty useful >> functionality available out of the box. For example, today it's very >> convenient that I can write an escript which: >> * interacts with the network (http, ssh, snmp, etc.) >> * compiles sources for various languages >> * creates or extracts tarballs or zip archives >> * inspects a (remote) node >> * much more... > > > One thought about this: there are several levels of modularity that could > be enabled, but as a first step I think that what could be separated are > the telecom-specific libraries (asn1, cos*, megaco, diameter). Snmp is on > the fence. > The enterprise version of Riak, which isn't a telecom-specific system, uses snmp because some customers rely on it for monitoring and alerts. Surely other non-telco apps use snmp as well. public_key currently relies on asn1, so it can't go away just yet either. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Tue Feb 18 15:32:15 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Tue, 18 Feb 2014 15:32:15 +0100 Subject: [erlang-questions] modular otp concerns In-Reply-To: References: Message-ID: On Tue, Feb 18, 2014 at 3:27 PM, Steve Vinoski wrote: > On Tue, Feb 18, 2014 at 9:11 AM, Vlad Dumitrescu wrote: > >> On Tue, Feb 18, 2014 at 12:48 PM, Tuncer Ayaz wrote: >> >>> I know that at least Bjoern-Egil has been investigating the possibility >>> of >>> splitting up otp.git into sub repos, and before anything is set into >>> stone, I'd like to resolve one concern I have. >>> >>> One thought about this: there are several levels of modularity that >> could be enabled, but as a first step I think that what could be separated >> are the telecom-specific libraries (asn1, cos*, megaco, diameter). Snmp is >> on the fence. >> > > The enterprise version of Riak, which isn't a telecom-specific system, > uses snmp because some customers rely on it for monitoring and alerts. > Surely other non-telco apps use snmp as well. > > public_key currently relies on asn1, so it can't go away just yet either. > > Sure, that was only my list of things that could be considered as extras. Anyway, some applications are more enterprise-y than others and IMHO here is where a line could be drawn. /Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Tue Feb 18 15:37:29 2014 From: spawn.think@REDACTED (Ahmed Omar) Date: Tue, 18 Feb 2014 15:37:29 +0100 Subject: [erlang-questions] disconnected nodes In-Reply-To: <530369AB.9070502@gmail.com> References: <53012CD1.7030605@gmail.com> <530369AB.9070502@gmail.com> Message-ID: Hi Ignas, Yes I meant the "volume" or (number*size of the messages sent). In our case the messages were plenty of XMPP messages, which could be large. In your case, maybe it's different. P.S: Network utilisation might not be enough to judge, there might be some kind of microbrusts of traffic as described in this informative blog post by Scott Lystig Fritchie http://www.snookles.com/slf-blog/2012/01/05/tcp-incast-what-is-it/ Best Regards, - Ahmed Omar http://about.me/spawn.think/ On Tue, Feb 18, 2014 at 3:09 PM, Ignas Vy?niauskas wrote: > Hi again, > > Thanks for the response. > > On 02/17/2014 11:23 AM, Ahmed Omar wrote: > > The reason for the later incidents, was usually high traffic between > > the nodes. That traffic could cause distribution buffer to reach > > limits and suspend processes trying to communicate with other > > processes on other nodes. > > (http://erlang.org/doc/man/erlang.html#system_info_dist_buf_busy_limit) > > > > One quick work around for that would be to increase the limit using > > +zdbbl flag on startup. A more permanent solution would be to look > > into the traffic between the nodes and optimise there. > > By high traffic do you mean amount of messages or actual volume? > > AFAIK, +zdbbl is more of a possible cure for volume and battling things > like TCP incast. However, in our case the network utilization does not > go over ~20%, so I don't think TCP incast is playing role here. The > number of messages is quite large, though. > > I bumped it to 32MB in any case, can't hurt. > > -- > Ignas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Tue Feb 18 15:48:33 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Tue, 18 Feb 2014 16:48:33 +0200 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <53018DE1.1090901@meetinghouse.net> <616cb6cb3939f2335a00cae036fe92b4.squirrel@mail.jschneider.net> <53021D9F.7060605@meetinghouse.net> <8CBFA302-A6B1-46A5-9102-E33E0F9FFC7B@gmail.com> Message-ID: <46234867-5857-450B-A12B-B5837ABE7976@gmail.com> Hello, I would not mix documentation and binaries as a single PDF package. You need documentation while discovering packages, developing agains it's API. At different stages, you need different documentation such package bio, API, operation manual etc. Git Page is an interesting concept to expose documentation and code within same repository... Stand alone package is handy for production deployment but I'd like to have ability to inspect source code while developing. Best Regards, Dmitry >-|-|-(*> > On 18 Feb 2014, at 14:13, Joe Armstrong wrote: > > > > >> On Tue, Feb 18, 2014 at 9:45 AM, Dmitry Kolesnikov wrote: >> Hello, >> >>> 1) A decent standardized Manifest. >> >> The app file by itself is a good place to be manifest. >> the env section might be expanded with following keys: >> * url >> * signature >> * ... >> >>> 2) Packages should NOT be unpacked on the destination machine. >> >> >> What is wrong with erlang archive files? > > I already said this, 27 lines after the point 2) heading. > > I'll repeat this: > > Q: Why should the top level package be a PDF file? >> A: Because the *first* thing I want to do is read the documentation. >> I won't even look at a program that has no documentation - it's a waste of time. > > > > /Joe > >> >> >> - Dmitry >> >>> On 18 Feb 2014, at 10:34, Joe Armstrong wrote: >>> >>> Thank you Gordon,The absence of a decent package manager as disturbed me for a long time. >>> >>> I'd like to add a few thoughts I have on the matter. >>> >>> Excuse the rant - I feel rather strongly about this. This is written great haste. >>> I have to give a lecture in 20 minutes. >>> >>> Here are some things I'd like to see: >>> >>> 1) A decent standardized Manifest. >>> >>> A manifest is just a list of files and a short description. It also >>> has copyright and licensing information, and possible authentication >>> checksums and proof signatures. >>> >>> Nothing fancy - but it needs a standard. >>> >>> I don't feel strong about the format or the content. but it MUST have >>> a version number :-) >>> >>> >>> >>> 2) Packages should NOT be unpacked on the destination machine. >>> >>> Unpacking a package BREAKS an abstraction boundary. I feel VERY >>> STRONGLY about this. I hate unpacking things and finding that they >>> scatter thousands of files all over my disk. >>> >>> Here's a radical proposal. The top level package should be a PDF file. >>> >>> In 2001 ago I wrote this >>> >>> http://www.sics.se/~joe/erlpdf.pdf - Read it, download it, try it, think about it. >>> >>> This a simple program that packs a file inside a PDF container. It still works. >>> It seems like the one line description on my sics web page did not cause a stir of >>> interest in the program (which I thought was a fun idea) so I'll now publicize the idea a bit more. >>> >>> >>> >>> >>> Q: Why should the top level package be a PDF file? >>> A: Because the *first* thing I want to do is read the documentation. >>> I won't even look at a program that has no documentation - it's a waste of time. >>> >>> Q: Why should the top level package not be unpacked? >>> A: Because it breaks an abstraction boundary, make it difficult to delete things etc. >>> >>> I don't have to unpack a jar file to execute the program in it. I >>> don't have to unpack a .exe file to execute it so WHY IN THE NAME OF >>> THE GREAT SLIMY THING THAT LIVES UNDER STONES should I have to unpack >>> an Erlang package to execute the code in it? >>> >>> When I want to use say (cowboy) I just want to execute the code - I >>> don't want to see all the details of what going on inside the program - >>> I don't want to know that it is made of loads of modules - I want to >>> hide the details - this is called ABSTRACTION. >>> >>> They tell me that they teach OO programming these days - I thought the idea of an object >>> was to HIDE THE DETAILS OF THE OBJECT INSIDE THE OBJECT - so why do >>> people who have been brought up on OO programming insist on writing >>> programs that scatter files all over my disk? Hide your mess in a >>> single container. Pleeeeeese. >>> >>> Q: How do I install a program? >>> A: Put the PDF in the directory ${HOME}/.erlang_programs/ >>> >>> Q: How do I delete the program? >>> A: Remove a single file from ${HOME}/.erlang_programs/ >>> >>> Q: How do I develop the program? >>> A: Unpack the PDF file *somewhere else* >>> >>> >>> 3) How should we distribute programs? >>> >>> Why not just use Bit Torrent? - we can self-seed our code, and seed >>> code we approve of That way popular code will be multiply seeded and >>> unpopular code with wither and die. >>> >>> We could use Jespers Bit torrent client and adapt it a bit so it knows >>> about Erlang packages. >>> >>> To do this we need >>> >>> a) Trackers (easy) >>> b) an Index (needs a publishing protocol) >>> c) clients >>> >>> Erlang solutions etc. can trackers. >>> >>> The code can be ANYWHERE YOU FEEL LIKE and not on github. >>> >>> Putting stuff on github is for collaboration purposes, not for distributing code. >>> Use BitTorrent for this. >>> >>> >>> >>> Cheers >>> >>> /Joe >>> >>> >>> >>>> On Mon, Feb 17, 2014 at 11:33 PM, Gordon Guthrie wrote: >>>> This is what I sent to Francesco >>>> >>>> **************************************************************************************** >>>> >>>> Building The Erlang Community >>>> Background >>>> Erlang has long lacked a solid community core to act as a place where users can discover existing modules and include them in their projects. >>>> rebar now provides the standard mechanism to include external dependencies - this proposal is about making erldocs the standard place to discover community contributions. >>>> Proposal 1 >>>> The proposal is that people who publish open source Erlang modules on GitHub be able to have them listed on erldocs. >>>> The process would be two part: >>>> commit a page called ERLDOCS.terms to github in the root next to README.md >>>> submit the URL to a page on erldocs >>>> erldocs would sook the github page into a community section >>>> >>>> The structure of the ERLDOCS.terms file is simple tagged tuples, something like: >>>> {name, "Starling"}. >>>> {license, "EPL"}. >>>> {description, "Unicode support for Erlang"}. >>>> {details, "A C-Port wrapped around the ICU library for unicode"}. >>>> {status, "production"}. % alpha | beta | production >>>> {rebar, {version, "1"}, {starling, {git, "git://github.com/hypernumbers/starling.git","master"}}}. >>>> Proposal 2 >>>> Dale Harvey originally intended that erldocs should include the ability for members of the community to annotate the official documents with examples, links to tutorials etc, etc. >>>> erldocs be so extended (by use of Disqus or other standard commenting systems) >>>> Requirements For Success >>>> Erldocs 'failed' last time out because the OTP team changed the way documents were generated, and Dale Harvey moved on from an Erlang shop to Mozilla. >>>> In order for this to work Erlang Solutions has to commit to: >>>> erldocs being the official community repository for Erlang documentation - linked to directly from erlang.org >>>> production of these documents needs to be integrated into the OTP Team's release schedule >>>> Modalities >>>> If Erlang Solutions so agree the next stage would be to approach a number of suppliers of top-notch Erlang open source and sign them up for launch. My working list would be: >>>> Erlang Solutions >>>> Basho >>>> Erlware >>>> Mats Cronquist >>>> Richard Carlsson >>>> Yaws >>>> Mochiweb >>>> Nitrogen >>>> Cowboy >>>> Web Machine >>>> Hypernumbers >>>> >>>> There would need to be consultation with the launch group regarding the structure and elements of the term file. >>>> Once they were onboard and the production cycle had been tested - an open launch on the mailing list. >>>> >>>> **************************************************************************************** >>>> >>>> The key point is that a community is only a real community if you choose to join it. I was 'joined' to the Agner community (and there have been other attempts, Erlware, CEAN, etc) but they don't stick. >>>> >>>> Gordon >>>> >>>> >>>>> On 17 February 2014 22:28, Mark Allen wrote: >>>>> On 2/17/14 4:21 PM, "Garrett Smith" wrote: >>>>> >> On 2/17/14 1:51 PM, "Vixo" wrote: >>>>> >>>My suggestion would be a manifest file of Erlang terms at the root level >>>>> >>>of a GitHub page (they will *all* be on GitHub) that can be polled and >>>>> >>>turned into a static site. The logical thing to do would be combine thus >>>>> >>>with the revived erldocs site IMHO (as I have said to Francesco) >>>>> >>>>> >Does this require that all of github be crawled? >>>>> >>>>> No. I'm pretty sure we can segment the crawl to only projects with some X >>>>> threshold of Erlang. (I'll have a slice without so much rat in it. [0]) >>>>> >>>>> >Would a github based index make sense? Complete with a liberal pull >>>>> >request policy? >>>>> >>>>> Most likely, yes, using github pages with a nice custom domain would be a >>>>> Good Thing for this type of project. The code to do the crawl and build >>>>> the index should be open source too, imo. >>>>> >>>>> Mark >>>>> >>>>> [0]: >>>>> http://en.wikiquote.org/wiki/Monty_Python's_Flying_Circus#The_Money_Program >>>>> me_.5B3.03.5D >>>> >>>> >>>> >>>> -- >>>> --- >>>> Gordon Guthrie >>>> CEO vixo.com >>>> @gordonguthrie >>>> +44 (0) 7776 251669 (in Bonnie Scotland!) >>>> >>>> vixo is made in Scotland from electrons >>>> >>>> _______________________________________________ >>>> 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 zoha.qamer@REDACTED Tue Feb 18 16:12:11 2014 From: zoha.qamer@REDACTED (Zoha Qamar) Date: Tue, 18 Feb 2014 20:12:11 +0500 Subject: [erlang-questions] Distributed System Message-ID: Hi , I want to implement Clint-server System , which having once admin node and remaining nodes as clients . The main goal is to implement some protocol in which admin node can have access to the clients nodes 's application running on client node . Like for example admin node can start and stop the functions multiply which are running on my client nodes. I read TCP Socket Technique and Distributed Nodes on erlang , these two methods regarding this . which one is better to implement ? Or is there any other way to implement this ? -- "*Agar Tum Seedhay rastay pe ho aur kisi Mushkil ka samna nahe ker rahay to kuch dair k liyay socho k kahin tum kuch ghalt to nahe ker rahay kyon k seedha rasta to mushkilaat se bhar pur hota hy*" *Hazrat Imam Ali (A.S) * -------------- next part -------------- An HTML attachment was scrubbed... URL: From mangalaman93@REDACTED Tue Feb 18 16:22:41 2014 From: mangalaman93@REDACTED (aman mangal) Date: Tue, 18 Feb 2014 20:52:41 +0530 Subject: [erlang-questions] Distributed System In-Reply-To: References: Message-ID: I think if the size of the message you have to pass, is small (a few integers or so), you should use Erlang message passing across nodes. It *should* be more efficient, fault tolerant and easy to handle compared to TCP sockets. You can use *gproc* to register client processes and lookup them at admin node while sending messages. By the way, you can add *rpc* to that list which I have not used so much. Aman Mangal 4th year Undergraduate Student Department of Computer Science & Engineering IIT Bombay www.cse.iitb.ac.in/~amanmangal On Tue, Feb 18, 2014 at 8:42 PM, Zoha Qamar wrote: > > Hi , > > I want to implement Clint-server System , which having once admin node > and remaining nodes as clients . The main goal is to implement some > protocol in which admin node can have access to the clients nodes 's > application running on client node . Like for example admin node can start > and stop the functions multiply which are running on my client nodes. > > I read TCP Socket Technique and Distributed Nodes on erlang , these two > methods regarding this . which one is better to implement ? Or is there any > other way to implement this ? > -- > "*Agar Tum Seedhay rastay pe ho aur kisi Mushkil ka samna nahe ker rahay to > kuch dair k liyay socho k kahin tum kuch ghalt to nahe ker rahay kyon k > seedha rasta to mushkilaat se bhar pur hota hy*" *Hazrat Imam Ali (A.S) * > > > _______________________________________________ > 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 Tue Feb 18 16:28:39 2014 From: g@REDACTED (Garrett Smith) Date: Tue, 18 Feb 2014 09:28:39 -0600 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <20140215170843.GB589@ferdmbp.local> <2057935960.1423933.1392577304859.JavaMail.zimbra@erlang-solutions.com> <7EF08E60-95A0-41F5-A3EE-20E65E9BD245@cs.otago.ac.nz> <68950A1B-BD93-43BC-8739-2F5A50F78626@gmail.com> Message-ID: On Mon, Feb 17, 2014 at 11:14 PM, Richard A. O'Keefe wrote: > > On 18/02/2014, at 3:36 PM, Garrett Smith wrote: >> >> $ git clone git@REDACTED:anthonyrules/super-cool-repo.git >> $ cd super-cool-repo >> $ make check >> $ sudo make install > > Please. NO! I can do this inside VirtualBox, but generally > sudo is poison. I'm not suggesting this as the one and true way to manage Erlang software, goodness. If a Makefile is properly implemented, you should also be able to do this: $ make DESTDIR=pkg install as non-privileged user and effectively create an isolated image of the installed files. This is what package managers typically use. Even if the "install" (i.e. file copy) mechanism is implemented by something else, I'd hope to see a canonical Makefile wrapper (as is commonly provided with rebar). My point was only that packaging, testing, CI, etc. is certainly supported through a git based source distribution scheme. > Anything that expects people to trust an unknown makefile not > to do evil things while installing had better have some > really *serious* security and authentication on it. Certainly. I wouldn't trust anything unknown either. This is why, e.g. Arch packages are signed by their maintainers, who must be explicitly authorized as trusted. > One of the really great things about the R repository and > package management is that it works *without* needing any > special privileges. My preference with Erlang applications is to take the sources and create a stand along image, which can be installed anywhere on the system, either in a privileged location or locally. I don't like maintaining repositories of shared libraries in user home directories (e.g. .gem, .m2, and so on) as these introduce yet another painful dependency graph problem, and inevitably end up colliding in strange ways with system packages. This seems to be the prevailing pattern anyway, which might explain why the many efforts to spawn Erlang package repositories have not taken off. I might have missed something there though -- I know there's been a lot of activity in this area over the years. Garrett From g@REDACTED Tue Feb 18 16:47:21 2014 From: g@REDACTED (Garrett Smith) Date: Tue, 18 Feb 2014 09:47:21 -0600 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <8CBFA302-A6B1-46A5-9102-E33E0F9FFC7B@gmail.com> <20140218122110.GA1876@xenocorp> Message-ID: On Tue, Feb 18, 2014 at 7:13 AM, Leo Liu wrote: > On 2014-02-18 20:21 +0800, Aaron France wrote: >> Then you mustn't use the vast, vast majority of Erlang projects. > > Good projects come with good documentation because they are meant to be > (re-)used. There are loads of rubbish erlang code out there. Maybe the > community could outlaw them? I nominate you as the law keeper in this Wild West :) But if we wanted to think of this as an open ecosystem without this sort of control, I'd point the list to the outstanding Arch User Repository: https://aur.archlinux.org/ Here anyone can provide an Arch package, which is purely source. Consumers can use this to (easily) build packages (many of which pull from github or other source repos but not all) that can then be installed by a privileged user (this is just the way system packages work, if you're nervous, with good cause, use a container). Packages get votes, so you can see very easily how popular something is. If a package gets enough votes it might get picked up by a core package maintainer and land in the standard package ecosystem (mirrors). I think what's being kicked around here (Mark?) is a similar type of index, which crawls github (or part of it) to compile packages that have some well known metadata file. Maybe this could be a PDF :) Though I'd vote for an Erlang property file as per file:consult/1. Maybe this all exists today and I'm just too heads down in other things to have noticed. But if a single index with a voting scheme emerged as a de facto standard (i.e. actually *used* by people) we'd have an important missing piece in this ecosystem. At least if I'm understanding the problem correctly. This doesn't address the package artifact type, but I'm going on the assumption this would fall under the domain of Erlang releases. Naturally whatever artifacts are generated should work both as system software (i.e. installed by privileged users) and be consumable as dependencies by other Erlang applications. As I understand things, this is all part of the existing release scheme and is supported in varying degrees by current tools. Garrett From essen@REDACTED Tue Feb 18 17:01:01 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 18 Feb 2014 17:01:01 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <8CBFA302-A6B1-46A5-9102-E33E0F9FFC7B@gmail.com> <20140218122110.GA1876@xenocorp> Message-ID: <530383BD.2040101@ninenines.eu> On 02/18/2014 04:47 PM, Garrett Smith wrote: > emerged as a de facto standard (i.e. actually *used* by people) This is what makes these package manager discussions so odd. People keep talking about technical choices and how the perfect package manager they have wet dreams about so often would look like, and nobody asks the questions that matter: how do people deal with dependencies today? How can we improve the workflow? Do packages need to be separate (meaning you need to convince people to maintain them, how?) or can the library authors do it? How do you convince library authors to agree to it? Is their investment in this worth the reward? It doesn't matter what the technical solutions are until we have a clearer idea of what people want and would be willing to use. All package manager projects are bound to fail until these questions are answered. -- Lo?c Hoguin http://ninenines.eu From tuncer.ayaz@REDACTED Tue Feb 18 18:08:09 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 18 Feb 2014 18:08:09 +0100 Subject: [erlang-questions] modular otp concerns In-Reply-To: <53036066.3060404@ninenines.eu> References: <53036066.3060404@ninenines.eu> Message-ID: On Tue, Feb 18, 2014 at 2:30 PM, Lo?c Hoguin wrote: > On 02/18/2014 12:48 PM, Tuncer Ayaz wrote: >> >> I know that at least Bjoern-Egil has been investigating the possibility of >> splitting up otp.git into sub repos, and before anything is set into >> stone, I'd like to resolve one concern I have. > > > I thought he was the only proponent of this in the OTP team? I don't know, but there's https://github.com/erlang-labs. From tuncer.ayaz@REDACTED Tue Feb 18 18:15:46 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 18 Feb 2014 18:15:46 +0100 Subject: [erlang-questions] modular otp concerns In-Reply-To: References: Message-ID: On Tue, Feb 18, 2014 at 3:32 PM, Vlad Dumitrescu wrote: > On Tue, Feb 18, 2014 at 3:27 PM, Steve Vinoski wrote: >> >> On Tue, Feb 18, 2014 at 9:11 AM, Vlad Dumitrescu >> wrote: >>> >>> On Tue, Feb 18, 2014 at 12:48 PM, Tuncer Ayaz >>> wrote: >>>> >>>> I know that at least Bjoern-Egil has been investigating the >>>> possibility of splitting up otp.git into sub repos, and before >>>> anything is set into stone, I'd like to resolve one concern I >>>> have. >>>> >>> One thought about this: there are several levels of modularity >>> that could be enabled, but as a first step I think that what could >>> be separated are the telecom-specific libraries (asn1, cos*, >>> megaco, diameter). Snmp is on the fence. >> >> >> The enterprise version of Riak, which isn't a telecom-specific >> system, uses snmp because some customers rely on it for monitoring >> and alerts. Surely other non-telco apps use snmp as well. >> >> public_key currently relies on asn1, so it can't go away just yet >> either. >> > > Sure, that was only my list of things that could be considered as > extras. Anyway, some applications are more enterprise-y than others > and IMHO here is where a line could be drawn. I don't think any of the libs should be unbundled. I've seen projects split out components, deal with build/coordination issues, and after years add more and more stuff back to the core repo. With that said, if the otp team wants to unbundle libs, and has practical solutions for the two concerns, it'd be interesting to learn what problem unbundling will solve. IIRC, Bjoern-Egil has been doing otp releases, so he must know the pain points. From mfidelman@REDACTED Tue Feb 18 18:18:57 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Tue, 18 Feb 2014 12:18:57 -0500 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <530383BD.2040101@ninenines.eu> References: <8CBFA302-A6B1-46A5-9102-E33E0F9FFC7B@gmail.com> <20140218122110.GA1876@xenocorp> <530383BD.2040101@ninenines.eu> Message-ID: <53039601.9070203@meetinghouse.net> Lo?c Hoguin wrote: > On 02/18/2014 04:47 PM, Garrett Smith wrote: >> emerged as a de facto standard (i.e. actually *used* by people) > > This is what makes these package manager discussions so odd. People > keep talking about technical choices and how the perfect package > manager they have wet dreams about so often would look like, and > nobody asks the questions that matter: how do people deal with > dependencies today? How can we improve the workflow? Do packages need > to be separate (meaning you need to convince people to maintain them, > how?) or can the library authors do it? How do you convince library > authors to agree to it? Is their investment in this worth the reward? > > It doesn't matter what the technical solutions are until we have a > clearer idea of what people want and would be willing to use. All > package manager projects are bound to fail until these questions are > answered. > Really good points. One nice thing about Erlang packages - we're talking about a single language and run-time environment, not upstream code that has to be packaged for every linux distribution under the sun. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From egil@REDACTED Tue Feb 18 18:30:28 2014 From: egil@REDACTED (=?UTF-8?B?QmrDtnJuLUVnaWwgRGFobGJlcmc=?=) Date: Tue, 18 Feb 2014 18:30:28 +0100 Subject: [erlang-questions] modular otp concerns In-Reply-To: <53036066.3060404@ninenines.eu> References: <53036066.3060404@ninenines.eu> Message-ID: <530398B4.1080408@erlang.org> On 2014-02-18 14:30, Lo?c Hoguin wrote: > On 02/18/2014 12:48 PM, Tuncer Ayaz wrote: >> I know that at least Bjoern-Egil has been investigating the >> possibility of >> splitting up otp.git into sub repos, and before anything is set into >> stone, I'd like to resolve one concern I have. > > I thought he was the only proponent of this in the OTP team? > Hi there! The following is my take on this. Ok, so a modular OTP has be talked about in a context of a package manager (PM). The recent revival PM discussions on this ML has me a bit worried. I feel it lacks focus, everybody has an idea of they want and starts coding. That is fine but OTP can't commit to any of it at this point and I'll try to iron out why. I don't have all the details in my head so bear with me. If/when we split the OTP repository, and this split should be on the level where we have specific versions i.e. on application level. It has solve the issue of easy delivery of new patches and release on these specific applications. Some have voiced a concern that it will simply be to many repos and we should instead group them, i.e. Orber + cos* etc. I say fine, if so then those applications should have one version (and be a single application). One versioned entity per repository thank you. For our customers within Ericsson, we have to be able to patch a specific application on a specific level (no surprise there), and the norm has been to build binary deliverables that is delivered in clearcase. Due to increasing growth of supported platforms it is now unsustainable to provide binary deliveries for all these platforms along with different build settings. To support source patch-deliveries and to avoid a permutation explosion with tags in the main otp repo with releases and patches, we (or atlease I) would like to split the otp repository to a maintainable level. The application level is extraordinary good and a natural one. Application versions can be tagged directly in the application repo without specifying some globally defined patchlevel on the otp repo. A split has additional benefits such as decoupled release cycles and streamlining otp applications to look like any other application. We could also setup different maintainers for different, traditionally OTP only, applications on GitHub. This could ease development for those applications. Applications needs to understand dependencies. I've already stated that we want src-deliveries and this is key. We have nifs and drivers that is platform dependent but even prebuilding beam-files might be problematic since we could have different (older) erlang runtimes trying to load too new code. This means we at least have two types of dependencies, a build dependency (or requirement) for building the application and a runtime dependency for running the application. I would like to specify these dependencies in the .app.src file and specify that such files needs to be interpretable before compiling or sedding them. Alternatively, having yet another file: a manifest file. .. now i've been interrupted too many times writing this mail .. What I would like to say is, OTP wants a package manager to make a split viable and we have to have some control of a PM to be able to use it for delivering patches within Ericsson. Certain requirements has to be met, for instance cross compilation has to work flawlessly, and we need to be able to specify private sources to private users, i.e. no central tracker. Otherwise we have to roll our own system. All of this will be discussed internally at OTP between 17.0 - 18.0, so the timing of a PM discussion on the list is a bit off. =) // Bj?rn-Egil From mjtruog@REDACTED Tue Feb 18 18:46:44 2014 From: mjtruog@REDACTED (Michael Truog) Date: Tue, 18 Feb 2014 09:46:44 -0800 Subject: [erlang-questions] modular otp concerns In-Reply-To: <530398B4.1080408@erlang.org> References: <53036066.3060404@ninenines.eu> <530398B4.1080408@erlang.org> Message-ID: <53039C84.3040906@gmail.com> On 02/18/2014 09:30 AM, Bj?rn-Egil Dahlberg wrote: > If/when we split the OTP repository, and this split should be on the level where we have specific versions i.e. on application level. It has solve the issue of easy delivery of new patches and release on these specific applications. Some have voiced a concern that it will simply be to many repos and we should instead group them, i.e. Orber + cos* etc. I say fine, if so then those applications should have one version (and be a single application). One versioned entity per repository thank you. My main concern is: if the OTP repository is split, we still need the concept of a "version set", so a set of versions for all of OTP that are known to work together, just to help people avoid any potential for instability. With that concept in place, it shouldn't be a problem either way, and you are probably aware of the issue, but I wanted to mention it due to the added complexity that not having a "version set" concept can cause. If you don't have that concept, of versions grouped into a release, basically, then you run into a combinatorial problem during testing, which makes testing take longer (i.e., for all end-users). From tuncer.ayaz@REDACTED Tue Feb 18 18:54:54 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 18 Feb 2014 18:54:54 +0100 Subject: [erlang-questions] otp_build: default-enable silent-rules In-Reply-To: <97D8B3DF-96D0-4803-9BC3-60CFC30341BA@gmail.com> References: <1061F786-8033-415B-BB80-B0084B81F70C@gmail.com> <97D8B3DF-96D0-4803-9BC3-60CFC30341BA@gmail.com> Message-ID: On Tue, Feb 18, 2014 at 1:30 PM, Anthony Ramine wrote: > Nope, wouldn't mind that. > > This was a methodical change, didn't think about variable names when doing it. Okay, patch is on its way. > -- > Anthony Ramine > > Le 18 f?vr. 2014 ? 13:23, Tuncer Ayaz a ?crit : > >> So, you wouldn't mind changing the printed prefix to CXX, right? > From egil@REDACTED Tue Feb 18 19:02:17 2014 From: egil@REDACTED (=?UTF-8?B?QmrDtnJuLUVnaWwgRGFobGJlcmc=?=) Date: Tue, 18 Feb 2014 19:02:17 +0100 Subject: [erlang-questions] modular otp concerns In-Reply-To: <53039C84.3040906@gmail.com> References: <53036066.3060404@ninenines.eu> <530398B4.1080408@erlang.org> <53039C84.3040906@gmail.com> Message-ID: <5303A029.7040009@erlang.org> On 2014-02-18 18:46, Michael Truog wrote: > On 02/18/2014 09:30 AM, Bj?rn-Egil Dahlberg wrote: >> If/when we split the OTP repository, and this split should be on the >> level where we have specific versions i.e. on application level. It >> has solve the issue of easy delivery of new patches and release on >> these specific applications. Some have voiced a concern that it will >> simply be to many repos and we should instead group them, i.e. Orber >> + cos* etc. I say fine, if so then those applications should have one >> version (and be a single application). One versioned entity per >> repository thank you. > My main concern is: if the OTP repository is split, we still need the > concept of a "version set", so a set of versions for all of OTP that > are known to work together, just to help people avoid any potential > for instability. With that concept in place, it shouldn't be a > problem either way, and you are probably aware of the issue, but I > wanted to mention it due to the added complexity that not having a > "version set" concept can cause. If you don't have that concept, of > versions grouped into a release, basically, then you run into a > combinatorial problem during testing, which makes testing take longer > (i.e., for all end-users). > > I'm aware. The "set" you talk about would ideally be controlled by the application dependencies. But OTP releases would be the set you talk about though and a top repo, i.e. otp would control the set. I imagine that we would still have releases just like today with a set of applications that we have tested together. As for patches, those are tested with the dependencies specified, typically with those applications in the previous release. It would have the same stability as before. It is unfortunate that this debate got started now. I have actually zero time to spend on it .. i'll can do is watch it spin into another dimension. // Bj?rn-Egil From mfidelman@REDACTED Tue Feb 18 19:26:57 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Tue, 18 Feb 2014 13:26:57 -0500 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: References: <53021AC4.8080303@meetinghouse.net> <53026F73.5080106@meetinghouse.net> <530299A5.8030501@meetinghouse.net> <5302AF10.10502@gmail.com> <53036344.7010202@meetinghouse.net> Message-ID: <5303A5F1.3060703@meetinghouse.net> Fred Hebert wrote: > On 02/18, Miles Fidelman wrote: >> For scaling, the next step would be to swap out to disk - if that happens as >> a hibernate to disk, all the other functionality would stick around (as >> opposed to an application level write-state-to-disk). Hence the question >> re. internals of the hibernate BIF and the scheduler, and how one might >> think about wiring in a hibernate-to-disk function. >> > Be aware of the implicit state that exists within an application: > pending requests, messages in a mailbox, links and monitors being set > up, code versions being in use, sockets and file descriptors, etc. > > These things can be backed up, but reloading them does not promise a > workable process with an equivalent environment upon reloading. You > either have to write code that can deal with that, or prevent code that > cannot deal with it from being written. and Lukas Larsson wrote (in response to the same item): > If I were to do something like this I would first try to only put the > heap and referenced off heap binaries to disk. This should be the > majority of the memory footprint and will allow all process meta data > (links, monitors, registry etc etc) to remain unaffected. The question > is what to do about the stack which could contain pointers to code > that has been changed while the process was hibernated. > Fred: Are you suggesting that application state has to be preserved when hibernating a process today? I may be missing something, but I thought the point of hibernation was to reduce process footprint transparently. Lukas: I think that really zeros in on the question. Anybody know where I should start looking for documentation of the current hibernation mechanism? Thanks, Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mononcqc@REDACTED Tue Feb 18 19:38:05 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Tue, 18 Feb 2014 13:38:05 -0500 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: <5303A5F1.3060703@meetinghouse.net> References: <53021AC4.8080303@meetinghouse.net> <53026F73.5080106@meetinghouse.net> <530299A5.8030501@meetinghouse.net> <5302AF10.10502@gmail.com> <53036344.7010202@meetinghouse.net> <5303A5F1.3060703@meetinghouse.net> Message-ID: <20140218183803.GU62889@ferdair.local> On 02/18, Miles Fidelman wrote: > > Fred: Are you suggesting that application state has to be preserved when > hibernating a process today? I may be missing something, but I thought the > point of hibernation was to reduce process footprint transparently. No, I'm saying that as you hibernate a process that remains alive, it can keep using all these resources and have them allocated. Dump it to disk, deallocate everything in the VM, and then try to reload it, and this implicit state tracking that you had being done by the VM is no longer valid. From gordon@REDACTED Tue Feb 18 19:50:27 2014 From: gordon@REDACTED (Gordon Guthrie) Date: Tue, 18 Feb 2014 18:50:27 +0000 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <53039601.9070203@meetinghouse.net> References: <8CBFA302-A6B1-46A5-9102-E33E0F9FFC7B@gmail.com> <20140218122110.GA1876@xenocorp> <530383BD.2040101@ninenines.eu> <53039601.9070203@meetinghouse.net> Message-ID: Loic said: > This is what makes these package manager discussions so odd. People keep talking about technical choices and how the perfect package manager they have wet dreams about so often would look like, and nobody asks the questions that matter: how do people deal with dependencies today? How can we improve the workflow? Do packages need to be separate (meaning you need to convince people to maintain them, how?) or can the library authors do it? How do you convince library authors to agree to it? Is their investment in this worth the reward? > It doesn't matter what the technical solutions are until we have a clearer idea of what people want and would be willing to use. All package manager projects are bound to fail until these questions are answered. Spot on. Let me be a little clearer about what I was proposing. What Is The Problem? -------------------- There are lots of open source Erlang packages that I don't know about that I ought to be including in my project. How Do I Find Packages? ----------------------- Somebody tells me. I google and find a StackOverflow question that links to a package How Do People Create Open Source Erlang Now? -------------------------------------------- They create a public repository on GitHub. (Yes you can self-host your repository, you can use Mercurial or Bazaar or what ever, but as the Senator said when he failed to be re-elected "the people have spoken, the bastards".) How Do People Include Open Source Erlang? ----------------------------------------- rebar get-deps (yes there is relx and erlang.mk, but rebar get-deps is generally how people do it). How Are Dependency Clashes Resolved? ------------------------------------ If I want to use a package that depends on Cowboy 0.6.0 and another on that depends on Cowboy 0.8.1, tough. How Do People Ensure That The Software They Are Installing Is Secure And Safe? ------------------------------------------------------------------------------ Richard O'Keefe said: > Anything that expects people to trust an unknown makefile not to do evil things while installing had better have some really *serious* security and authentication on it. Bless! The problem, of course, is kids today! Even old 'started-programming-on-punch-cards in-the-70s' farts (comme moi) are 'drinkin beer, smokin fags and installing random software from the interwebs' - (haven't smoked a fag for 22 year, but I'm still a metaphorical 80-a-day man) I know, I know, its not big and its not clever... Commercially you inspect the package and snapshot it to your private GitHub repository and build and deploy from that. What Am I Proposing? -------------------- * a list of open source software - which is SEO-friendly and comes top of the search page - this is why I suggested merging it with the revived erldocs - mucho SEO juice * which the 'owners' of that software choose to join - commit a single Erlang term file to your repository > proof that you want to join - post the URL to a crawler robot > if the term file is there your page will be generated - a Jekyll site would be the easiest - keywords in URLs - titles/H1/H2/SEO stuff - tags/categories for free - it needs to be a community > the authors need to care about their reputation > you can't spam people into a 'community' * that generates instructions on how to incorporate that software in your project - probably mostly 'add this line to your rebar.config' - or 'add this line to your package.txt for erlang.mk' - or blah-blah relx blah-blah (don't know enough about it) * that has enough primitive social indicators to constitute a feedback loop - scrape stars, forks, commits, watches, date of last commit from GitHub? > or some sort of voting/reputation system (sounds like a pain in the arse to write) - and Disqus commenting (generate SEO keywords) What I Am Not Proposing? ------------------------ * something that scrapes and builds and verifies and cryptographically signs software packages. * a continuous build server that will produce verified builds for multiple architecture - you can use Travis-CI to do that for open source projects - you would want to pull their results in - good social signal * something that makes extensive us of GitHub apis The General Principles ---------------------- * small problem solved well * loose coupled - so it can evolve to address 'harder' problems Gordon On 18 February 2014 17:18, Miles Fidelman wrote: > Lo?c Hoguin wrote: > >> On 02/18/2014 04:47 PM, Garrett Smith wrote: >> >>> emerged as a de facto standard (i.e. actually *used* by people) >>> >> >> This is what makes these package manager discussions so odd. People keep >> talking about technical choices and how the perfect package manager they >> have wet dreams about so often would look like, and nobody asks the >> questions that matter: how do people deal with dependencies today? How can >> we improve the workflow? Do packages need to be separate (meaning you need >> to convince people to maintain them, how?) or can the library authors do >> it? How do you convince library authors to agree to it? Is their investment >> in this worth the reward? >> >> It doesn't matter what the technical solutions are until we have a >> clearer idea of what people want and would be willing to use. All package >> manager projects are bound to fail until these questions are answered. >> >> > Really good points. One nice thing about Erlang packages - we're talking > about a single language and run-time environment, not upstream code that > has to be packaged for every linux distribution under the sun. > > > > > -- > 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 > -- --- Gordon Guthrie CEO vixo.com @gordonguthrie +44 (0) 7776 251669 (in Bonnie Scotland!) vixo is made in Scotland from electrons -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Tue Feb 18 19:59:11 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 18 Feb 2014 19:59:11 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <8CBFA302-A6B1-46A5-9102-E33E0F9FFC7B@gmail.com> <20140218122110.GA1876@xenocorp> <530383BD.2040101@ninenines.eu> <53039601.9070203@meetinghouse.net> Message-ID: Yeah great, let?s depend on closed proprietary platforms. -- Anthony Ramine Le 18 f?vr. 2014 ? 19:50, Gordon Guthrie a ?crit : > * that has enough primitive social indicators to constitute a feedback loop > - scrape stars, forks, commits, watches, date of last commit from GitHub? > > or some sort of voting/reputation system (sounds like a pain in the arse to write) > - and Disqus commenting (generate SEO keywords) From tuncer.ayaz@REDACTED Tue Feb 18 19:58:36 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 18 Feb 2014 19:58:36 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <8CBFA302-A6B1-46A5-9102-E33E0F9FFC7B@gmail.com> <20140218122110.GA1876@xenocorp> <530383BD.2040101@ninenines.eu> <53039601.9070203@meetinghouse.net> Message-ID: On Tue, Feb 18, 2014 at 7:50 PM, Gordon Guthrie wrote: > How Are Dependency Clashes Resolved? > ------------------------------------ > > If I want to use a package that depends on Cowboy 0.6.0 and another > on that depends on Cowboy 0.8.1, tough. Related discussion: https://github.com/rebar/rebar/issues/222 Opinions welcome. From n.oxyde@REDACTED Tue Feb 18 20:03:50 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 18 Feb 2014 20:03:50 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <8CBFA302-A6B1-46A5-9102-E33E0F9FFC7B@gmail.com> <20140218122110.GA1876@xenocorp> <530383BD.2040101@ninenines.eu> <53039601.9070203@meetinghouse.net> Message-ID: <7FDBC067-05D3-4AD8-B8C0-589C3B9D4692@gmail.com> Easy. 1/ Push Cowboy maintainers to finally release 1.0.0 as they should since because it is used in production; 2/ Respect semver; 3/ Let the dependency solver realize it can use Cowboy 1.8.1 in place of Cowboy 1.6.0; 4/ Done. -- Anthony Ramine Le 18 f?vr. 2014 ? 19:50, Gordon Guthrie a ?crit : > How Are Dependency Clashes Resolved? > ------------------------------------ > > If I want to use a package that depends on Cowboy 0.6.0 and another on that depends on Cowboy 0.8.1, tough. From gordon@REDACTED Tue Feb 18 20:15:13 2014 From: gordon@REDACTED (Gordon Guthrie) Date: Tue, 18 Feb 2014 19:15:13 +0000 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <8CBFA302-A6B1-46A5-9102-E33E0F9FFC7B@gmail.com> <20140218122110.GA1876@xenocorp> <530383BD.2040101@ninenines.eu> <53039601.9070203@meetinghouse.net> Message-ID: I am not proposing to tie anything to GitHub But the fact remains that software developers have migrated on masse to GitHub, a propriety implementation of an open product On 18 Feb 2014 18:59, "Anthony Ramine" wrote: > Yeah great, let's depend on closed proprietary platforms. > > -- > Anthony Ramine > > Le 18 f?vr. 2014 ? 19:50, Gordon Guthrie a ?crit : > > > * that has enough primitive social indicators to constitute a feedback > loop > > - scrape stars, forks, commits, watches, date of last commit from > GitHub? > > > or some sort of voting/reputation system (sounds like a pain in > the arse to write) > > - and Disqus commenting (generate SEO keywords) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Tue Feb 18 20:16:48 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 18 Feb 2014 20:16:48 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <8CBFA302-A6B1-46A5-9102-E33E0F9FFC7B@gmail.com> <20140218122110.GA1876@xenocorp> <530383BD.2040101@ninenines.eu> <53039601.9070203@meetinghouse.net> Message-ID: <5AAEF060-3A01-4217-AD78-A62145AB10FE@gmail.com> I have nothing against GitHub as a host. -- Anthony Ramine Le 18 f?vr. 2014 ? 20:15, Gordon Guthrie a ?crit : > I am not proposing to tie anything to GitHub > > But the fact remains that software developers have migrated on masse to GitHub, a propriety implementation of an open product > > On 18 Feb 2014 18:59, "Anthony Ramine" wrote: > Yeah great, let?s depend on closed proprietary platforms. > > -- > Anthony Ramine > > Le 18 f?vr. 2014 ? 19:50, Gordon Guthrie a ?crit : > > > * that has enough primitive social indicators to constitute a feedback loop > > - scrape stars, forks, commits, watches, date of last commit from GitHub? > > > or some sort of voting/reputation system (sounds like a pain in the arse to write) > > - and Disqus commenting (generate SEO keywords) > From mfidelman@REDACTED Tue Feb 18 20:17:19 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Tue, 18 Feb 2014 14:17:19 -0500 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: <20140218183803.GU62889@ferdair.local> References: <53021AC4.8080303@meetinghouse.net> <53026F73.5080106@meetinghouse.net> <530299A5.8030501@meetinghouse.net> <5302AF10.10502@gmail.com> <53036344.7010202@meetinghouse.net> <5303A5F1.3060703@meetinghouse.net> <20140218183803.GU62889@ferdair.local> Message-ID: <5303B1BF.6040609@meetinghouse.net> Fred Hebert wrote: > On 02/18, Miles Fidelman wrote: >> Fred: Are you suggesting that application state has to be preserved when >> hibernating a process today? I may be missing something, but I thought the >> point of hibernation was to reduce process footprint transparently. > No, I'm saying that as you hibernate a process that remains alive, it > can keep using all these resources and have them allocated. Dump it to > disk, deallocate everything in the VM, and then try to reload it, and > this implicit state tracking that you had being done by the VM is no > longer valid. Ok.... just wanted to be clear we're on the same page. Thanks, Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From tuncer.ayaz@REDACTED Tue Feb 18 20:24:03 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 18 Feb 2014 20:24:03 +0100 Subject: [erlang-questions] modular otp concerns In-Reply-To: <5303A029.7040009@erlang.org> References: <53036066.3060404@ninenines.eu> <530398B4.1080408@erlang.org> <53039C84.3040906@gmail.com> <5303A029.7040009@erlang.org> Message-ID: On Tue, Feb 18, 2014 at 7:02 PM, Bj?rn-Egil Dahlberg wrote: > On 2014-02-18 18:46, Michael Truog wrote: >> >> On 02/18/2014 09:30 AM, Bj?rn-Egil Dahlberg wrote: >>> >>> If/when we split the OTP repository, and this split should be on >>> the level where we have specific versions i.e. on application >>> level. It has solve the issue of easy delivery of new patches and >>> release on these specific applications. Some have voiced a concern >>> that it will simply be to many repos and we should instead group >>> them, i.e. Orber + cos* etc. I say fine, if so then those >>> applications should have one version (and be a single >>> application). One versioned entity per repository thank you. >> >> My main concern is: if the OTP repository is split, we still need >> the concept of a "version set", so a set of versions for all of OTP >> that are known to work together, just to help people avoid any >> potential for instability. With that concept in place, it shouldn't >> be a problem either way, and you are probably aware of the issue, >> but I wanted to mention it due to the added complexity that not >> having a "version set" concept can cause. If you don't have that >> concept, of versions grouped into a release, basically, then you >> run into a combinatorial problem during testing, which makes >> testing take longer (i.e., for all end-users). >> >> > > I'm aware. The "set" you talk about would ideally be controlled by > the application dependencies. > > But OTP releases would be the set you talk about though and a top > repo, i.e. otp would control the set. I imagine that we would still > have releases just like today with a set of applications that we > have tested together. > > As for patches, those are tested with the dependencies specified, > typically with those applications in the previous release. It would > have the same stability as before. > > It is unfortunate that this debate got started now. I have actually > zero time to spend on it .. i'll can do is watch it spin into > another dimension. Sorry, Bjoern-Egil, and it's totally fine to postpone the discussion until after R17 is released. Let's just just pause and start a new discussion when R17 is out. BTW, your arguments for splitting up the repo sound reasonable. From lukas@REDACTED Tue Feb 18 20:38:07 2014 From: lukas@REDACTED (Lukas Larsson) Date: Tue, 18 Feb 2014 20:38:07 +0100 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: <5303A5F1.3060703@meetinghouse.net> References: <53021AC4.8080303@meetinghouse.net> <53026F73.5080106@meetinghouse.net> <530299A5.8030501@meetinghouse.net> <5302AF10.10502@gmail.com> <53036344.7010202@meetinghouse.net> <5303A5F1.3060703@meetinghouse.net> Message-ID: On Tue, Feb 18, 2014 at 7:26 PM, Miles Fidelman wrote: > Anybody know where I should start looking for documentation of the current > hibernation mechanism? > > read the source :) https://github.com/erlang/otp/blob/master/erts/emulator/beam/beam_emu.c#L5984 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wallentin.dahlberg@REDACTED Tue Feb 18 21:18:51 2014 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Tue, 18 Feb 2014 21:18:51 +0100 Subject: [erlang-questions] modular otp concerns In-Reply-To: References: <53036066.3060404@ninenines.eu> <530398B4.1080408@erlang.org> <53039C84.3040906@gmail.com> <5303A029.7040009@erlang.org> Message-ID: =) I have no illusions and don't stop a discussion on my account. I'm just saying I won't be part of it, and I'm guessing nor anyone else from OTP, until after 17.0. I'm just hoping someone is taking notes. 2014-02-18 20:24 GMT+01:00 Tuncer Ayaz : > On Tue, Feb 18, 2014 at 7:02 PM, Bj?rn-Egil Dahlberg wrote: > > On 2014-02-18 18:46, Michael Truog wrote: > >> > >> On 02/18/2014 09:30 AM, Bj?rn-Egil Dahlberg wrote: > >>> > >>> If/when we split the OTP repository, and this split should be on > >>> the level where we have specific versions i.e. on application > >>> level. It has solve the issue of easy delivery of new patches and > >>> release on these specific applications. Some have voiced a concern > >>> that it will simply be to many repos and we should instead group > >>> them, i.e. Orber + cos* etc. I say fine, if so then those > >>> applications should have one version (and be a single > >>> application). One versioned entity per repository thank you. > >> > >> My main concern is: if the OTP repository is split, we still need > >> the concept of a "version set", so a set of versions for all of OTP > >> that are known to work together, just to help people avoid any > >> potential for instability. With that concept in place, it shouldn't > >> be a problem either way, and you are probably aware of the issue, > >> but I wanted to mention it due to the added complexity that not > >> having a "version set" concept can cause. If you don't have that > >> concept, of versions grouped into a release, basically, then you > >> run into a combinatorial problem during testing, which makes > >> testing take longer (i.e., for all end-users). > >> > >> > > > > I'm aware. The "set" you talk about would ideally be controlled by > > the application dependencies. > > > > But OTP releases would be the set you talk about though and a top > > repo, i.e. otp would control the set. I imagine that we would still > > have releases just like today with a set of applications that we > > have tested together. > > > > As for patches, those are tested with the dependencies specified, > > typically with those applications in the previous release. It would > > have the same stability as before. > > > > It is unfortunate that this debate got started now. I have actually > > zero time to spend on it .. i'll can do is watch it spin into > > another dimension. > > Sorry, Bjoern-Egil, and it's totally fine to postpone the discussion > until after R17 is released. Let's just just pause and start a new > discussion when R17 is out. > > BTW, your arguments for splitting up the repo sound reasonable. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Tue Feb 18 21:30:18 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 19 Feb 2014 09:30:18 +1300 Subject: [erlang-questions] atoms with newlines In-Reply-To: References: Message-ID: <3D506AA6-D4E1-4887-B76B-51FA12BCF353@cs.otago.ac.nz> On 19/02/2014, at 3:04 AM, Vlad Dumitrescu wrote: > Multi-line strings are a pain but at least I can understand the reason for having them. I can't find any reasonable use of atoms with names including newlines and I wonder if we could do anything about them... Since list_to_atom/1 can create atoms containing newlines, then we had _better_ be able to print them somehow. There is no token pasting for quoted atoms. In Prolog, where _any_ atom can be declared as an operator, such a restriction is necessary. In Erlang, where the set of operators is fixed and quoted operators are not operators, there's no obvious reason why 'foo' 'bar' could not be read as a single atom. There's one thing about Erlang atom reading that may be an oversight, and is dangerously close to a bug: m% ./erl Erlang R16B03-1 (erts-5.10.4) [source] [64-bit] [smp:2:2] [async-threads:10] [hipe] [kernel-poll:false] Eshell V5.10.4 (abort with ^G) 1> 'foo\n\ 1> bar'. 'foo\n\nbar' I had expected that would - be rejected as a syntax error, or - be discarded like in C and Prolog. I did _not_ expect it to turn into . The current on-line documentation http://www.erlang.org/doc/reference_manual/data_types.html#id65925 has a table in section 2.14 showing the escape sequences. (It would be nice to have a forward reference in section 2.3.) That table is completely silent about \. Section 2.14 also fails to mention that the escape sequence are also accepted in character literals. Anyone reading section 2.2 would surmise that they were forbidden. I suggest there are two Erlang-specific notations: * $char The numeric code for the character char. Any of the escape sequences in section 2.14 may be used. * base#value ,,, From steve@REDACTED Tue Feb 18 22:24:05 2014 From: steve@REDACTED (Steve Strong) Date: Tue, 18 Feb 2014 22:24:05 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <8CBFA302-A6B1-46A5-9102-E33E0F9FFC7B@gmail.com> <20140218122110.GA1876@xenocorp> <530383BD.2040101@ninenines.eu> <53039601.9070203@meetinghouse.net> Message-ID: As a plan, I like it. Why? Because it's simple, and therefore it has a chance of working. If it gets done, and if it then gains traction, the fancier stuff (signing, cleverer version management etc) and removing proprietary dependencies (github) can be added over time. Cheers, Steve On 18 Feb 2014 19:50, "Gordon Guthrie" wrote: > Loic said: > > > This is what makes these package manager discussions so odd. People keep > talking about technical choices and how the perfect package manager they > have wet dreams about so often would look like, and nobody asks the > questions that matter: how do people deal with dependencies today? How can > we improve the workflow? Do packages need to be separate (meaning you need > to convince people to maintain them, how?) or can the library authors do > it? How do you convince library authors to agree to it? Is their investment > in this worth the reward? > > > It doesn't matter what the technical solutions are until we have a > clearer idea of what people want and would be willing to use. All package > manager projects are bound to fail until these questions are answered. > > Spot on. > > Let me be a little clearer about what I was proposing. > > What Is The Problem? > -------------------- > > There are lots of open source Erlang packages that I don't know about that > I ought to be including in my project. > > How Do I Find Packages? > ----------------------- > > Somebody tells me. > I google and find a StackOverflow question that links to a package > > How Do People Create Open Source Erlang Now? > -------------------------------------------- > > They create a public repository on GitHub. > > (Yes you can self-host your repository, you can use Mercurial or Bazaar or > what ever, but as the Senator said when he failed to be re-elected "the > people have spoken, the bastards".) > > How Do People Include Open Source Erlang? > ----------------------------------------- > > rebar get-deps > > (yes there is relx and erlang.mk, but rebar get-deps is generally how > people do it). > > How Are Dependency Clashes Resolved? > ------------------------------------ > > If I want to use a package that depends on Cowboy 0.6.0 and another on > that depends on Cowboy 0.8.1, tough. > > How Do People Ensure That The Software They Are Installing Is Secure And > Safe? > > ------------------------------------------------------------------------------ > > Richard O'Keefe said: > > > Anything that expects people to trust an unknown makefile not > to do evil things while installing had better have some > really *serious* security and authentication on it. > > Bless! > > The problem, of course, is kids today! Even old > 'started-programming-on-punch-cards in-the-70s' farts (comme moi) are > 'drinkin beer, smokin fags and installing random software from the > interwebs' - (haven't smoked a fag for 22 year, but I'm still a > metaphorical 80-a-day man) > > I know, I know, its not big and its not clever... > > Commercially you inspect the package and snapshot it to your private > GitHub repository and build and deploy from that. > > What Am I Proposing? > -------------------- > > * a list of open source software > - which is SEO-friendly and comes top of the search page > - this is why I suggested merging it with the revived erldocs - mucho > SEO juice > * which the 'owners' of that software choose to join > - commit a single Erlang term file to your repository > > proof that you want to join > - post the URL to a crawler robot > > if the term file is there your page will be generated > - a Jekyll site would be the easiest > - keywords in URLs > - titles/H1/H2/SEO stuff > - tags/categories for free > - it needs to be a community > > the authors need to care about their reputation > > you can't spam people into a 'community' > * that generates instructions on how to incorporate that software in your > project > - probably mostly 'add this line to your rebar.config' > - or 'add this line to your package.txt for erlang.mk' > - or blah-blah relx blah-blah (don't know enough about it) > * that has enough primitive social indicators to constitute a feedback loop > - scrape stars, forks, commits, watches, date of last commit from GitHub? > > or some sort of voting/reputation system (sounds like a pain in the > arse to write) > - and Disqus commenting (generate SEO keywords) > > What I Am Not Proposing? > ------------------------ > > * something that scrapes and builds and verifies and cryptographically > signs software packages. > * a continuous build server that will produce verified builds for multiple > architecture > - you can use Travis-CI to do that for open source projects - you would > want to pull their results in - good social signal > * something that makes extensive us of GitHub apis > > The General Principles > ---------------------- > > * small problem solved well > * loose coupled > - so it can evolve to address 'harder' problems > > Gordon > > > > On 18 February 2014 17:18, Miles Fidelman wrote: > >> Lo?c Hoguin wrote: >> >>> On 02/18/2014 04:47 PM, Garrett Smith wrote: >>> >>>> emerged as a de facto standard (i.e. actually *used* by people) >>>> >>> >>> This is what makes these package manager discussions so odd. People keep >>> talking about technical choices and how the perfect package manager they >>> have wet dreams about so often would look like, and nobody asks the >>> questions that matter: how do people deal with dependencies today? How can >>> we improve the workflow? Do packages need to be separate (meaning you need >>> to convince people to maintain them, how?) or can the library authors do >>> it? How do you convince library authors to agree to it? Is their investment >>> in this worth the reward? >>> >>> It doesn't matter what the technical solutions are until we have a >>> clearer idea of what people want and would be willing to use. All package >>> manager projects are bound to fail until these questions are answered. >>> >>> >> Really good points. One nice thing about Erlang packages - we're talking >> about a single language and run-time environment, not upstream code that >> has to be packaged for every linux distribution under the sun. >> >> >> >> >> -- >> 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 >> > > > > -- > --- > Gordon Guthrie > CEO vixo.com > @gordonguthrie > +44 (0) 7776 251669 (in Bonnie Scotland!) > > vixo is made in Scotland from electrons > > _______________________________________________ > 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 Tue Feb 18 22:33:55 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Tue, 18 Feb 2014 22:33:55 +0100 Subject: [erlang-questions] atoms with newlines In-Reply-To: <3D506AA6-D4E1-4887-B76B-51FA12BCF353@cs.otago.ac.nz> References: <3D506AA6-D4E1-4887-B76B-51FA12BCF353@cs.otago.ac.nz> Message-ID: On Tue, Feb 18, 2014 at 9:30 PM, Richard A. O'Keefe wrote: > > On 19/02/2014, at 3:04 AM, Vlad Dumitrescu wrote: > > Multi-line strings are a pain but at least I can understand the reason > for having them. I can't find any reasonable use of atoms with names > including newlines and I wonder if we could do anything about them... > > Since list_to_atom/1 can create atoms containing newlines, > then we had _better_ be able to print them somehow. > > Yes, I know, I was just a bit frustrated. Maybe it's a thing for Erlang2 o whatever... > There's one thing about Erlang atom reading that may be > an oversight, and is dangerously close to a bug: > > m% ./erl > Erlang R16B03-1 (erts-5.10.4) [source] [64-bit] [smp:2:2] > [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V5.10.4 (abort with ^G) > 1> 'foo\n\ > 1> bar'. > 'foo\n\nbar' > > I had expected that would > - be rejected as a syntax error, or > - be discarded like in C and Prolog. > > I did _not_ expect it to turn into . > > Actually, what I was referring to was that that last backslash isn't really needed at all. 'foo bar' is 'foo\nbar'. This is what I think is confusing. For strings too. regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Tue Feb 18 23:24:52 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Tue, 18 Feb 2014 17:24:52 -0500 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: References: <53021AC4.8080303@meetinghouse.net> <53026F73.5080106@meetinghouse.net> <530299A5.8030501@meetinghouse.net> <5302AF10.10502@gmail.com> <53036344.7010202@meetinghouse.net> <5303A5F1.3060703@meetinghouse.net> Message-ID: <5303DDB4.2000402@meetinghouse.net> Lukas Larsson wrote: > On Tue, Feb 18, 2014 at 7:26 PM, Miles Fidelman > > wrote: > > Anybody know where I should start looking for documentation of the > current hibernation mechanism? > > > read the source :) > https://github.com/erlang/otp/blob/master/erts/emulator/beam/beam_emu.c#L5984 > Or wait for happi's book on the ERTS. :-) -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From tuncer.ayaz@REDACTED Tue Feb 18 23:32:22 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 18 Feb 2014 23:32:22 +0100 Subject: [erlang-questions] modular otp concerns In-Reply-To: References: <53036066.3060404@ninenines.eu> <530398B4.1080408@erlang.org> <53039C84.3040906@gmail.com> <5303A029.7040009@erlang.org> Message-ID: On Tue, 18 Feb 2014 21:18:51 +0100, Bj?rn-Egil Dahlberg wrote: > =) I have no illusions and don't stop a discussion on my account. > I'm just saying I won't be part of it, and I'm guessing nor anyone > else from OTP, until after 17.0. I'm just hoping someone is taking > notes. To be honest, I don't think there's much to discuss without you being involved :). I was under the impression that this project may already be cooking, and could soon be revealed without a chance of community involvement, so I opened the thread. > 2014-02-18 20:24 GMT+01:00 Tuncer Ayaz : > >> On Tue, Feb 18, 2014 at 7:02 PM, Bj?rn-Egil Dahlberg wrote: >> > On 2014-02-18 18:46, Michael Truog wrote: >> >> >> >> On 02/18/2014 09:30 AM, Bj?rn-Egil Dahlberg wrote: >> >>> >> >>> If/when we split the OTP repository, and this split should be on >> >>> the level where we have specific versions i.e. on application >> >>> level. It has solve the issue of easy delivery of new patches and >> >>> release on these specific applications. Some have voiced a concern >> >>> that it will simply be to many repos and we should instead group >> >>> them, i.e. Orber + cos* etc. I say fine, if so then those >> >>> applications should have one version (and be a single >> >>> application). One versioned entity per repository thank you. >> >> >> >> My main concern is: if the OTP repository is split, we still need >> >> the concept of a "version set", so a set of versions for all of OTP >> >> that are known to work together, just to help people avoid any >> >> potential for instability. With that concept in place, it shouldn't >> >> be a problem either way, and you are probably aware of the issue, >> >> but I wanted to mention it due to the added complexity that not >> >> having a "version set" concept can cause. If you don't have that >> >> concept, of versions grouped into a release, basically, then you >> >> run into a combinatorial problem during testing, which makes >> >> testing take longer (i.e., for all end-users). >> >> >> >> >> > >> > I'm aware. The "set" you talk about would ideally be controlled by >> > the application dependencies. >> > >> > But OTP releases would be the set you talk about though and a top >> > repo, i.e. otp would control the set. I imagine that we would still >> > have releases just like today with a set of applications that we >> > have tested together. >> > >> > As for patches, those are tested with the dependencies specified, >> > typically with those applications in the previous release. It would >> > have the same stability as before. >> > >> > It is unfortunate that this debate got started now. I have actually >> > zero time to spend on it .. i'll can do is watch it spin into >> > another dimension. >> >> Sorry, Bjoern-Egil, and it's totally fine to postpone the discussion >> until after R17 is released. Let's just just pause and start a new >> discussion when R17 is out. >> >> BTW, your arguments for splitting up the repo sound reasonable. From essen@REDACTED Tue Feb 18 23:38:47 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 18 Feb 2014 23:38:47 +0100 Subject: [erlang-questions] modular otp concerns In-Reply-To: References: <53036066.3060404@ninenines.eu> <530398B4.1080408@erlang.org> <53039C84.3040906@gmail.com> <5303A029.7040009@erlang.org> Message-ID: <5303E0F7.1050707@ninenines.eu> On 02/18/2014 11:32 PM, Tuncer Ayaz wrote: > On Tue, 18 Feb 2014 21:18:51 +0100, Bj?rn-Egil Dahlberg wrote: > >> =) I have no illusions and don't stop a discussion on my account. >> I'm just saying I won't be part of it, and I'm guessing nor anyone >> else from OTP, until after 17.0. I'm just hoping someone is taking >> notes. > > To be honest, I don't think there's much to discuss without you being > involved :). I was under the impression that this project may already > be cooking, and could soon be revealed without a chance of community > involvement, so I opened the thread. Maps ruined it! Damn maps! -- Lo?c Hoguin http://ninenines.eu From tuncer.ayaz@REDACTED Tue Feb 18 23:49:24 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 18 Feb 2014 23:49:24 +0100 Subject: [erlang-questions] modular otp concerns In-Reply-To: <530398B4.1080408@erlang.org> References: <53036066.3060404@ninenines.eu> <530398B4.1080408@erlang.org> Message-ID: On Tue, Feb 18, 2014 at 6:30 PM, Bj?rn-Egil Dahlberg wrote: > On 2014-02-18 14:30, Lo?c Hoguin wrote: >> >> On 02/18/2014 12:48 PM, Tuncer Ayaz wrote: >>> >>> I know that at least Bjoern-Egil has been investigating the possibility >>> of >>> splitting up otp.git into sub repos, and before anything is set into >>> stone, I'd like to resolve one concern I have. >> >> >> I thought he was the only proponent of this in the OTP team? >> > > Hi there! > > The following is my take on this. > > Ok, so a modular OTP has be talked about in a context of a package > manager (PM). The recent revival PM discussions on this ML has me a > bit worried. I feel it lacks focus, everybody has an idea of they > want and starts coding. That is fine but OTP can't commit to any of > it at this point and I'll try to iron out why. I don't have all the > details in my head so bear with me. > > If/when we split the OTP repository, and this split should be on the > level where we have specific versions i.e. on application level. It > has solve the issue of easy delivery of new patches and release on > these specific applications. Some have voiced a concern that it will > simply be to many repos and we should instead group them, i.e. Orber > + cos* etc. I say fine, if so then those applications should have > one version (and be a single application). One versioned entity per > repository thank you. > > For our customers within Ericsson, we have to be able to patch a > specific application on a specific level (no surprise there), and > the norm has been to build binary deliverables that is delivered in > clearcase. Due to increasing growth of supported platforms it is now > unsustainable to provide binary deliveries for all these platforms > along with different build settings. > > To support source patch-deliveries and to avoid a permutation > explosion with tags in the main otp repo with releases and patches, > we (or atlease I) would like to split the otp repository to a > maintainable level. The application level is extraordinary good and > a natural one. Application versions can be tagged directly in the > application repo without specifying some globally defined patchlevel > on the otp repo. A split has additional benefits such as decoupled > release cycles and streamlining otp applications to look like any > other application. We could also setup different maintainers for > different, traditionally OTP only, applications on GitHub. This > could ease development for those applications. > > Applications needs to understand dependencies. I've already stated > that we want src-deliveries and this is key. We have nifs and > drivers that is platform dependent but even prebuilding beam-files > might be problematic since we could have different (older) erlang > runtimes trying to load too new code. This means we at least have > two types of dependencies, a build dependency (or requirement) for > building the application and a runtime dependency for running the > application. I would like to specify these dependencies in the > .app.src file and specify that such files needs to be interpretable > before compiling or sedding them. Alternatively, having yet another > file: a manifest file. > > .. now i've been interrupted too many times writing this mail .. > > What I would like to say is, OTP wants a package manager to make a > split viable and we have to have some control of a PM to be able to > use it for delivering patches within Ericsson. Certain requirements > has to be met, for instance cross compilation has to work > flawlessly, and we need to be able to specify private sources to > private users, i.e. no central tracker. Otherwise we have to roll > our own system. All of this will be discussed internally at OTP > between 17.0 - 18.0, so the timing of a PM discussion on the list is > a bit off. =) All of the above sounds to me like we should aim to extend the built-in .app functionality, and use that as a base for a bundled package manager in R18. We've discussed this multiple times, but we should do it properly and have one official tool that's used by otp.git and external_app.git. So, your "own system" should be suitable for use by non-Ericsson users too. As with the other discussion, it's okay to wait for the R17 release to happen first. The release isn't that far in the future anyway. From ok@REDACTED Tue Feb 18 23:49:55 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 19 Feb 2014 11:49:55 +1300 Subject: [erlang-questions] modular otp concerns In-Reply-To: References: Message-ID: <89DD9A4D-E3C0-47C1-8063-1949A8A4F1F0@cs.otago.ac.nz> > On Tue, Feb 18, 2014 at 9:11 AM, Vlad Dumitrescu wrote: > One thought about this: there are several levels of modularity that could be enabled, but as a first step I think that what could be separated are the telecom-specific libraries (asn1, cos*, megaco, diameter). Snmp is on the fence. What makes you think ASN.1 is telecom-specific? We're not doing it at the moment, but my Information Retrieval expert colleague once had to deal with documents stored in an ASN.1 format. As far as I know that collection still works that way. According to http://www.itu.int/dms_pub/itu-t/oth/0B/04/T0B040000422C01PDFE.pdf "ASN.1 is being increasingly used outside the telecommunication industry in areas such as security, transportation, Smart Grid, genetic research and many others. Logistics: . Electrical Smart Grid: . Information network: ." The web site for the Open Source ASN.1 Compiler asn1c says http://lionet.info/asn1c/basics.html "If you are using SSL (HTTPS) to access a bank or email account, be sure the ASN.1 is involved too; it describes the structure of the server's identity certificate for verification by your Internet browser." You never know what you're going to need... Let me advert once again to R. The CRAN archive has 5224 packages at the moment. I have only 244 of them installed (less than 5%). I probably _asked_ for about 80 of them, the rest being automatically installed dependencies. Tomorrow I may discover that I need one of the remaining 4980. If I am at home and we've used up our monthly quota (which happens) I am completely stuck. If I had the lot on a DVD, I'd be away laughing. If I'm at work, it's no harder to install over the internet than it is from a local file; apart from saying what I want I don't get involved. (I do not have to manually check package hashes, I don't have to remember to use https, I don't have to provide a superuser password.) But the packages are *there*, *documented*, *versioned*, and *tested*, and all of that testing gets redone whenever there is a new release. Considering what Erlang's used for, it doesn't matter very much if chunks of OTP are split off and pulled over the net when you need them (during initial testing). What *does* matter is that they are *managed* and *tested* and their documentation is *managed* and *reviewed* as a unit, so that you don't get the documentation for Erlang 19 with the code of Erlang version 17, &c. After unpacking R16B03-1 and building, otp_src_R16B03-1 is 330+ MB according to 'du'. I could fit more than 20 such unpacked releases on a cheap memory stick. The distribution, as a .tar.bz2 file, is j 58? MB; I could fit 125 of those on a memory stick. (Hmm. Wouldn't that be a cool gimmick for the next Erlang conference? Give attendees a memory stick with every available Erlang source release on it... Heck, when an Erlang speaker presents a conference on another topic, hand out sticks to everyone that wants them.) So what is the reason for distributing less than what's distributed now? go From ok@REDACTED Tue Feb 18 23:57:43 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 19 Feb 2014 11:57:43 +1300 Subject: [erlang-questions] atoms with newlines In-Reply-To: References: <3D506AA6-D4E1-4887-B76B-51FA12BCF353@cs.otago.ac.nz> Message-ID: <6B6D7CCC-E823-44A9-B7D9-7268C4CFAEC9@cs.otago.ac.nz> On 19/02/2014, at 10:33 AM, Vlad Dumitrescu wrote: > Eshell V5.10.4 (abort with ^G) > 1> 'foo\n\ > 1> bar'. > 'foo\n\nbar' > > I had expected that would > - be rejected as a syntax error, or > - be discarded like in C and Prolog. > > I did _not_ expect it to turn into . > > > Actually, what I was referring to was that that last backslash isn't really needed at all. No, the last backslash IS needed because I *don't* want the newline. In ISO Prolog I can write |p('foo\| |bar\| |zoo').'| where the vertical bars show record boundaries, and get the same effect as |p('foobarzoo').| You are concerned about atoms that include newline characters. I am concerned about atoms that for one reason or another need to be split over lines WITHOUT introducing newline characters. I just want \ to work sensibly and to be so documented. From ok@REDACTED Wed Feb 19 02:22:16 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 19 Feb 2014 14:22:16 +1300 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: <530299A5.8030501@meetinghouse.net> References: <53021AC4.8080303@meetinghouse.net> <53026F73.5080106@meetinghouse.net> <530299A5.8030501@meetinghouse.net> Message-ID: <1DDEC60A-2F93-4BF0-AA8D-4A897D2D91EB@cs.otago.ac.nz> On 18/02/2014, at 12:22 PM, Miles Fidelman wrote: > > Ok. After reading what others have said about garbage collection, this is clearly issue number one that I'll need to address. I think that issues 0, 1, and 2 are 0. With a distributed replicated collection of active documents, how are you going to correct errors without the system correcting them back? (This leads to questions of authentication and control.) 1. With a distributed set of *active* "documents", what stops divergent computations? (E.g., document X is created, then document Y is created with a rule "I am document X plus the letter Y" and then document X is revised to "I am document Y plus the letter X", and it's "To infinity and beyondYXYXYXYXYXYXYXYXYX..." time.) 2. Versioning and metadata. I think distributed GC can/should exploit versioning and metadata and must respect authentication and control. But that's just my NZD 0.01. From mfidelman@REDACTED Wed Feb 19 03:03:32 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Tue, 18 Feb 2014 21:03:32 -0500 Subject: [erlang-questions] "actor database" - architectural strategy question In-Reply-To: <1DDEC60A-2F93-4BF0-AA8D-4A897D2D91EB@cs.otago.ac.nz> References: <53021AC4.8080303@meetinghouse.net> <53026F73.5080106@meetinghouse.net> <530299A5.8030501@meetinghouse.net> <1DDEC60A-2F93-4BF0-AA8D-4A897D2D91EB@cs.otago.ac.nz> Message-ID: <530410F4.6070705@meetinghouse.net> Hi Richard, Richard A. O'Keefe wrote: > On 18/02/2014, at 12:22 PM, Miles Fidelman wrote: >> Ok. After reading what others have said about garbage collection, this is clearly issue number one that I'll need to address. Well, you're taking that a bit out of context - I was responding to this, along with some other comments about various garbage collection issues: > Some kind of "getting things out of memory and onto disk when not > needed" layer is needed for your problem, > > Ok. After reading what others have said about garbage collection, > this is clearly issue number one that I'll need to address. > > At first glance, it strikes me that the hibernate BIF does at least > part of what's needed - any thoughts/suggestions as to whether it > might make sense to approach this by extending hibernate, vs. > something at the application layer? And, if it makes sense to play > with the BIF, any quick pointers to where I might find detailed > documentation on how it's implemented? Referring to "getting things out of memory and onto disk when not needed" rather than garbage collection. But... in response to your comments > I think that issues 0, 1, and 2 are > > 0. With a distributed replicated collection of active > documents, how are you going to correct errors without > the system correcting them back? (This leads to > questions of authentication and control.) For the collaborative document applications, it's not clear that that correcting errors is necessary. It's more a version control issue. I'm thinking more of a document as akin to a program under version control - complete with branches, merges, tags, .... - I make some edits, someone else makes some edits, the changes propagate as messages - branching occurs. One can browse through different versions, change sets, etc. One can also define "releases" (e.g., the one that goes to press.) Add business rules that are document specific - such as who is allowed to generate a "define version" message - and one has a document management process for a specific replicated document. > > 1. With a distributed set of *active* "documents", > what stops divergent computations? > (E.g., document X is created, then document Y is created > with a rule "I am document X plus the letter Y" and then > document X is revised to "I am document Y plus the letter X", > and it's "To infinity and beyondYXYXYXYXYXYXYXYXYX..." time.) > > 2. Versioning and metadata. > > I think distributed GC can/should exploit versioning and metadata > and must respect authentication and control. Exactly! > > But that's just my NZD 0.01. Great minds think alike :-) Cheers, Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From vladimir.ralev@REDACTED Wed Feb 19 01:00:54 2014 From: vladimir.ralev@REDACTED (Vladimir Ralev) Date: Wed, 19 Feb 2014 02:00:54 +0200 Subject: [erlang-questions] Creating a diagnostic memory dump of live erlang VM Message-ID: Hello all, As a Java developer I really miss being able to create a "heap dump" of a live Erlang VM where I can see the objects in each process and the current process stack variables/trace. I realise there is no java-like heap in Erlang but there are the processes, mailboxes, stacks, file handles, sockets, ets and so on. In Java we can also use query tools to search the heaps for specific identifying strings/numbers/timestamps to find a graph of related objects. You can go find objects by type or find the stack variables for given thread. It would be very useful for understanding the system in production and diagnose issues. Would it be possible to have something like this in Erlang or it is fundamentally not allowed? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nem@REDACTED Wed Feb 19 06:20:28 2014 From: nem@REDACTED (Geoff Cant) Date: Tue, 18 Feb 2014 21:20:28 -0800 Subject: [erlang-questions] Creating a diagnostic memory dump of live erlang VM In-Reply-To: References: Message-ID: Provided you're prepared to take down the node, you can erlang:halt("crashdump") and you'll get a dump of memory, heaps, tables, ... - erl_crash.dump file. You can view this in a web browser with crashdump_viewer. Crashdump debugging is unfortunate, but extremely useful. I use it on all my production systems. -G > On 18/02/2014, at 16:00, Vladimir Ralev wrote: > > Hello all, > > As a Java developer I really miss being able to create a "heap dump" of a live Erlang VM where I can see the objects in each process and the current process stack variables/trace. I realise there is no java-like heap in Erlang but there are the processes, mailboxes, stacks, file handles, sockets, ets and so on. > > In Java we can also use query tools to search the heaps for specific identifying strings/numbers/timestamps to find a graph of related objects. You can go find objects by type or find the stack variables for given thread. It would be very useful for understanding the system in production and diagnose issues. > > Would it be possible to have something like this in Erlang or it is fundamentally not allowed? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vladdu55@REDACTED Wed Feb 19 10:14:18 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 19 Feb 2014 10:14:18 +0100 Subject: [erlang-questions] modular otp concerns In-Reply-To: <89DD9A4D-E3C0-47C1-8063-1949A8A4F1F0@cs.otago.ac.nz> References: <89DD9A4D-E3C0-47C1-8063-1949A8A4F1F0@cs.otago.ac.nz> Message-ID: On Tue, Feb 18, 2014 at 11:49 PM, Richard A. O'Keefe wrote: > > On Tue, Feb 18, 2014 at 9:11 AM, Vlad Dumitrescu > wrote: > > One thought about this: there are several levels of modularity that > could be enabled, but as a first step I think that what could be separated > are the telecom-specific libraries (asn1, cos*, megaco, diameter). Snmp is > on the fence. > > What makes you think ASN.1 is telecom-specific? > Sorry, it was just a reflection of me spending too many years in the telecomi industry :-) The orber support isn't specific to it either. The right word would have been "enterprise-y". regards, /Vlad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourinov@REDACTED Wed Feb 19 11:20:58 2014 From: bourinov@REDACTED (Max Bourinov) Date: Wed, 19 Feb 2014 11:20:58 +0100 Subject: [erlang-questions] modular otp concerns In-Reply-To: References: <89DD9A4D-E3C0-47C1-8063-1949A8A4F1F0@cs.otago.ac.nz> Message-ID: Hello Dear Erlangers! I (as Erlang programmer and architect) do not see a single reason to do something dramatic with BEAUTIFUL OTP. It is great as it is. Any extra stuff that might be needed for me is coming via rebar - another brilliant tool. So, everything about Erlang is just f****g amazing for me and my team! Last few days I saw proposals to: 1. Rename OTP - that is just makes no sense at all... 2. Question where there is a need in Erlang - ..... 3. Proposals to split?! Erlang and OTP... Could it be that I missed something very important in Erlang life while me and my team where coding in "old good" Erlang/OTP? Why don't I feel "the need" to change something in Erlang? OR Because of growing Erlang popularity new stream of devs bring "*great"*ideas out of php/java/rubby word to us? Best regards, Max skype: max.bourinov On Wed, Feb 19, 2014 at 10:14 AM, Vlad Dumitrescu wrote: > On Tue, Feb 18, 2014 at 11:49 PM, Richard A. O'Keefe wrote: > >> > On Tue, Feb 18, 2014 at 9:11 AM, Vlad Dumitrescu >> wrote: >> > One thought about this: there are several levels of modularity that >> could be enabled, but as a first step I think that what could be separated >> are the telecom-specific libraries (asn1, cos*, megaco, diameter). Snmp is >> on the fence. >> >> What makes you think ASN.1 is telecom-specific? >> > > Sorry, it was just a reflection of me spending too many years in the > telecomi industry :-) The orber support isn't specific to it either. The > right word would have been "enterprise-y". > > 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 bogdan@REDACTED Wed Feb 19 12:05:07 2014 From: bogdan@REDACTED (Bogdan B) Date: Wed, 19 Feb 2014 11:05:07 +0000 Subject: [erlang-questions] [ANN] 6 month contract in London Message-ID: I've received this today, if anyone is interested. > This is a 6 month contract with a competitive rate. As mentioned, my > client is a global mobile solutions provider with a development team of 50+ > in the UK alone. This role is within an R&D team who work on optimising > existing products; however, their main concern is developing prototypes for > new products in the company pipeline. > > > > Their offices are located near London Bridge. > >From what I've seen before 'competitive rate' means ?4-500/day. Mentioning this as I hate recruitment companies and squeezing as much as possible would be good. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Wed Feb 19 13:37:13 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 19 Feb 2014 13:37:13 +0100 Subject: [erlang-questions] modular otp concerns In-Reply-To: <89DD9A4D-E3C0-47C1-8063-1949A8A4F1F0@cs.otago.ac.nz> References: <89DD9A4D-E3C0-47C1-8063-1949A8A4F1F0@cs.otago.ac.nz> Message-ID: On Tue, Feb 18, 2014 at 11:49 PM, Richard A. O'Keefe wrote: [snip] > Considering what Erlang's used for, it doesn't matter > very much if chunks of OTP are split off and pulled > over the net when you need them (during initial testing). What counts is what we get in the default Erlang "platform" for use out of the box. This is especially important for escripts. Right now we can write escripts relying on many useful libs in the base install. Once you remove inets from the base install, you lose the ability to bootstrap your project with an escript. [snip] From mononcqc@REDACTED Wed Feb 19 13:49:48 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 19 Feb 2014 07:49:48 -0500 Subject: [erlang-questions] Creating a diagnostic memory dump of live erlang VM In-Reply-To: References: Message-ID: <20140219124947.GC45523@ferdmbp.local> Part of the information available in an Erlang crash dump can be obtained during runtime. The following strings will return system information seen in crash dumps: erlang:system_info(dist), (distribution information) erlang:system_info(info), (misc system info) erlang:system_info(loaded), (loaded module information) erlang:system_info(procs), (process heaps and stacktraces) You can print out this information (be careful because it can be freaking huge), and try to understand it by going through http://www.erlang.org/doc/apps/erts/crash_dump.html (the format isn't rxactly the same as a crashdump, but maybe the viewer can work, the one recommended by Geoff). Some info will be missing from this one to be a real crash dump: tables of refc binaries, atom tables, etc. For binaries, they can be inspected at run time by calling process_info(Pid, binary) and getting a list of all the refc binaries owned by a process. This, again, can have quite a heavy cost depending on how many processes (and binaries) you have. Otherwise, you'll need to crash a node. Regards, Fred. On 02/19, Vladimir Ralev wrote: > Hello all, > > As a Java developer I really miss being able to create a "heap dump" of a > live Erlang VM where I can see the objects in each process and the current > process stack variables/trace. I realise there is no java-like heap in > Erlang but there are the processes, mailboxes, stacks, file handles, > sockets, ets and so on. > > In Java we can also use query tools to search the heaps for specific > identifying strings/numbers/timestamps to find a graph of related objects. > You can go find objects by type or find the stack variables for given > thread. It would be very useful for understanding the system in production > and diagnose issues. > > Would it be possible to have something like this in Erlang or it is > fundamentally not allowed? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From tuncer.ayaz@REDACTED Wed Feb 19 13:59:02 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 19 Feb 2014 13:59:02 +0100 Subject: [erlang-questions] modular otp concerns In-Reply-To: References: <89DD9A4D-E3C0-47C1-8063-1949A8A4F1F0@cs.otago.ac.nz> Message-ID: On Wed, Feb 19, 2014 at 11:20 AM, Max Bourinov wrote: [snip] > 3. Proposals to split?! Erlang and OTP... > > Could it be that I missed something very important in Erlang life > while me and my team where coding in "old good" Erlang/OTP? > Why don't I feel "the need" to change something in Erlang? I can relate to that, but the OTP team is facing issues with patch management, as explained by Bjoern-Egil, where extracting lib/* into sub repos seems like one solution. To be clear, it's not a proposal by the community but a solution to a problem planned to be investigated by the OTP team after 17.0 is released. It's a non-trivial change, and has the potential to reduce the out of the box functionality, so that's why I opened the thread. From vladimir.ralev@REDACTED Wed Feb 19 13:25:09 2014 From: vladimir.ralev@REDACTED (Vladimir Ralev) Date: Wed, 19 Feb 2014 14:25:09 +0200 Subject: [erlang-questions] Creating a diagnostic memory dump of live erlang VM In-Reply-To: References: Message-ID: >From what I've seen the crashdump doesn't really have any of the objects in the memory. If I have a string stuck in some mailbox or even just state inside a gen_server process, can I see it? On Wed, Feb 19, 2014 at 7:20 AM, Geoff Cant wrote: > Provided you're prepared to take down the node, you can > erlang:halt("crashdump") and you'll get a dump of memory, heaps, tables, > ... - erl_crash.dump file. > > You can view this in a web browser with crashdump_viewer. > > Crashdump debugging is unfortunate, but extremely useful. I use it on all > my production systems. > > -G > > > On 18/02/2014, at 16:00, Vladimir Ralev > wrote: > > > > Hello all, > > > > As a Java developer I really miss being able to create a "heap dump" of > a live Erlang VM where I can see the objects in each process and the > current process stack variables/trace. I realise there is no java-like heap > in Erlang but there are the processes, mailboxes, stacks, file handles, > sockets, ets and so on. > > > > In Java we can also use query tools to search the heaps for specific > identifying strings/numbers/timestamps to find a graph of related objects. > You can go find objects by type or find the stack variables for given > thread. It would be very useful for understanding the system in production > and diagnose issues. > > > > Would it be possible to have something like this in Erlang or it is > fundamentally not allowed? > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangud@REDACTED Wed Feb 19 14:08:10 2014 From: dangud@REDACTED (Dan Gudmundsson) Date: Wed, 19 Feb 2014 14:08:10 +0100 Subject: [erlang-questions] Creating a diagnostic memory dump of live erlang VM In-Reply-To: References: Message-ID: Have you tried observer? Shows message boxes and gen_server states and more. On Wed, Feb 19, 2014 at 1:25 PM, Vladimir Ralev wrote: > From what I've seen the crashdump doesn't really have any of the objects > in the memory. If I have a string stuck in some mailbox or even just state > inside a gen_server process, can I see it? > > > On Wed, Feb 19, 2014 at 7:20 AM, Geoff Cant wrote: > >> Provided you're prepared to take down the node, you can >> erlang:halt("crashdump") and you'll get a dump of memory, heaps, tables, >> ... - erl_crash.dump file. >> >> You can view this in a web browser with crashdump_viewer. >> >> Crashdump debugging is unfortunate, but extremely useful. I use it on all >> my production systems. >> >> -G >> >> > On 18/02/2014, at 16:00, Vladimir Ralev >> wrote: >> > >> > Hello all, >> > >> > As a Java developer I really miss being able to create a "heap dump" of >> a live Erlang VM where I can see the objects in each process and the >> current process stack variables/trace. I realise there is no java-like heap >> in Erlang but there are the processes, mailboxes, stacks, file handles, >> sockets, ets and so on. >> > >> > In Java we can also use query tools to search the heaps for specific >> identifying strings/numbers/timestamps to find a graph of related objects. >> You can go find objects by type or find the stack variables for given >> thread. It would be very useful for understanding the system in production >> and diagnose issues. >> > >> > Would it be possible to have something like this in Erlang or it is >> fundamentally not allowed? >> > _______________________________________________ >> > 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 mononcqc@REDACTED Wed Feb 19 14:08:32 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 19 Feb 2014 08:08:32 -0500 Subject: [erlang-questions] Creating a diagnostic memory dump of live erlang VM In-Reply-To: References: Message-ID: <20140219130831.GV62889@ferdair.local> You can access these with process_info(Pid, messages) for the mailbox and sys:get_state(Pid) for the state, respectively. I also suggest taking a look at recon (http://ferd.github.io/recon/) to do live debugging in a system. Regards, Fred. On 02/19, Vladimir Ralev wrote: > From what I've seen the crashdump doesn't really have any of the objects in > the memory. If I have a string stuck in some mailbox or even just state > inside a gen_server process, can I see it? > > > On Wed, Feb 19, 2014 at 7:20 AM, Geoff Cant wrote: > > > Provided you're prepared to take down the node, you can > > erlang:halt("crashdump") and you'll get a dump of memory, heaps, tables, > > ... - erl_crash.dump file. > > > > You can view this in a web browser with crashdump_viewer. > > > > Crashdump debugging is unfortunate, but extremely useful. I use it on all > > my production systems. > > > > -G > > > > > On 18/02/2014, at 16:00, Vladimir Ralev > > wrote: > > > > > > Hello all, > > > > > > As a Java developer I really miss being able to create a "heap dump" of > > a live Erlang VM where I can see the objects in each process and the > > current process stack variables/trace. I realise there is no java-like heap > > in Erlang but there are the processes, mailboxes, stacks, file handles, > > sockets, ets and so on. > > > > > > In Java we can also use query tools to search the heaps for specific > > identifying strings/numbers/timestamps to find a graph of related objects. > > You can go find objects by type or find the stack variables for given > > thread. It would be very useful for understanding the system in production > > and diagnose issues. > > > > > > Would it be possible to have something like this in Erlang or it is > > fundamentally not allowed? > > > _______________________________________________ > > > 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 vladimir.ralev@REDACTED Wed Feb 19 14:22:39 2014 From: vladimir.ralev@REDACTED (Vladimir Ralev) Date: Wed, 19 Feb 2014 15:22:39 +0200 Subject: [erlang-questions] Creating a diagnostic memory dump of live erlang VM In-Reply-To: References: Message-ID: This observer http://www.erlang.org/doc/man/observer_app.html ? I can't see such functions in there? On Wed, Feb 19, 2014 at 3:08 PM, Dan Gudmundsson wrote: > Have you tried observer? > Shows message boxes and gen_server states and more. > > > > On Wed, Feb 19, 2014 at 1:25 PM, Vladimir Ralev wrote: > >> From what I've seen the crashdump doesn't really have any of the objects >> in the memory. If I have a string stuck in some mailbox or even just state >> inside a gen_server process, can I see it? >> >> >> On Wed, Feb 19, 2014 at 7:20 AM, Geoff Cant wrote: >> >>> Provided you're prepared to take down the node, you can >>> erlang:halt("crashdump") and you'll get a dump of memory, heaps, tables, >>> ... - erl_crash.dump file. >>> >>> You can view this in a web browser with crashdump_viewer. >>> >>> Crashdump debugging is unfortunate, but extremely useful. I use it on >>> all my production systems. >>> >>> -G >>> >>> > On 18/02/2014, at 16:00, Vladimir Ralev >>> wrote: >>> > >>> > Hello all, >>> > >>> > As a Java developer I really miss being able to create a "heap dump" >>> of a live Erlang VM where I can see the objects in each process and the >>> current process stack variables/trace. I realise there is no java-like heap >>> in Erlang but there are the processes, mailboxes, stacks, file handles, >>> sockets, ets and so on. >>> > >>> > In Java we can also use query tools to search the heaps for specific >>> identifying strings/numbers/timestamps to find a graph of related objects. >>> You can go find objects by type or find the stack variables for given >>> thread. It would be very useful for understanding the system in production >>> and diagnose issues. >>> > >>> > Would it be possible to have something like this in Erlang or it is >>> fundamentally not allowed? >>> > _______________________________________________ >>> > 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 vladimir.ralev@REDACTED Wed Feb 19 14:23:03 2014 From: vladimir.ralev@REDACTED (Vladimir Ralev) Date: Wed, 19 Feb 2014 15:23:03 +0200 Subject: [erlang-questions] Creating a diagnostic memory dump of live erlang VM In-Reply-To: <20140219130831.GV62889@ferdair.local> References: <20140219130831.GV62889@ferdair.local> Message-ID: That looks great. I will check it out. On Wed, Feb 19, 2014 at 3:08 PM, Fred Hebert wrote: > You can access these with process_info(Pid, messages) for the mailbox and > sys:get_state(Pid) for the state, respectively. > > I also suggest taking a look at recon (http://ferd.github.io/recon/) to > do live debugging in a system. > > Regards, > Fred. > > On 02/19, Vladimir Ralev wrote: > > From what I've seen the crashdump doesn't really have any of the objects > in > > the memory. If I have a string stuck in some mailbox or even just state > > inside a gen_server process, can I see it? > > > > > > On Wed, Feb 19, 2014 at 7:20 AM, Geoff Cant wrote: > > > > > Provided you're prepared to take down the node, you can > > > erlang:halt("crashdump") and you'll get a dump of memory, heaps, > tables, > > > ... - erl_crash.dump file. > > > > > > You can view this in a web browser with crashdump_viewer. > > > > > > Crashdump debugging is unfortunate, but extremely useful. I use it on > all > > > my production systems. > > > > > > -G > > > > > > > On 18/02/2014, at 16:00, Vladimir Ralev > > > wrote: > > > > > > > > Hello all, > > > > > > > > As a Java developer I really miss being able to create a "heap dump" > of > > > a live Erlang VM where I can see the objects in each process and the > > > current process stack variables/trace. I realise there is no java-like > heap > > > in Erlang but there are the processes, mailboxes, stacks, file handles, > > > sockets, ets and so on. > > > > > > > > In Java we can also use query tools to search the heaps for specific > > > identifying strings/numbers/timestamps to find a graph of related > objects. > > > You can go find objects by type or find the stack variables for given > > > thread. It would be very useful for understanding the system in > production > > > and diagnose issues. > > > > > > > > Would it be possible to have something like this in Erlang or it is > > > fundamentally not allowed? > > > > _______________________________________________ > > > > 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 dangud@REDACTED Wed Feb 19 14:40:07 2014 From: dangud@REDACTED (Dan Gudmundsson) Date: Wed, 19 Feb 2014 14:40:07 +0100 Subject: [erlang-questions] Creating a diagnostic memory dump of live erlang VM In-Reply-To: References: Message-ID: Yes, double click on a process in the Applications or Processes tab On Wed, Feb 19, 2014 at 2:22 PM, Vladimir Ralev wrote: > This observer http://www.erlang.org/doc/man/observer_app.html ? I can't > see such functions in there? > > > On Wed, Feb 19, 2014 at 3:08 PM, Dan Gudmundsson wrote: > >> Have you tried observer? >> Shows message boxes and gen_server states and more. >> >> >> >> On Wed, Feb 19, 2014 at 1:25 PM, Vladimir Ralev > > wrote: >> >>> From what I've seen the crashdump doesn't really have any of the objects >>> in the memory. If I have a string stuck in some mailbox or even just state >>> inside a gen_server process, can I see it? >>> >>> >>> On Wed, Feb 19, 2014 at 7:20 AM, Geoff Cant wrote: >>> >>>> Provided you're prepared to take down the node, you can >>>> erlang:halt("crashdump") and you'll get a dump of memory, heaps, tables, >>>> ... - erl_crash.dump file. >>>> >>>> You can view this in a web browser with crashdump_viewer. >>>> >>>> Crashdump debugging is unfortunate, but extremely useful. I use it on >>>> all my production systems. >>>> >>>> -G >>>> >>>> > On 18/02/2014, at 16:00, Vladimir Ralev >>>> wrote: >>>> > >>>> > Hello all, >>>> > >>>> > As a Java developer I really miss being able to create a "heap dump" >>>> of a live Erlang VM where I can see the objects in each process and the >>>> current process stack variables/trace. I realise there is no java-like heap >>>> in Erlang but there are the processes, mailboxes, stacks, file handles, >>>> sockets, ets and so on. >>>> > >>>> > In Java we can also use query tools to search the heaps for specific >>>> identifying strings/numbers/timestamps to find a graph of related objects. >>>> You can go find objects by type or find the stack variables for given >>>> thread. It would be very useful for understanding the system in production >>>> and diagnose issues. >>>> > >>>> > Would it be possible to have something like this in Erlang or it is >>>> fundamentally not allowed? >>>> > _______________________________________________ >>>> > 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 dave@REDACTED Wed Feb 19 15:46:58 2014 From: dave@REDACTED (David Goehrig) Date: Wed, 19 Feb 2014 09:46:58 -0500 Subject: [erlang-questions] random thought: connecting to node, specify IP address In-Reply-To: <20140218112612.GA13552@k2r.org> References: <20140218112612.GA13552@k2r.org> Message-ID: <8B7A9E9E-2770-446E-9A02-93A2076C94D7@nexttolast.com> I do just this... http://github.com/cthulhuology/docker-pdns For apps like RabbitMQ and Riak I use a FQDN based on the internal TLD. Works well and assuming you set your domain search in /etc/resolv.conf in your base image, cloud-init supplied hostnames just work. Dave -=-=- dave@REDACTED -=-=- > On Feb 18, 2014, at 6:26 AM, Kenji Rikitake wrote: > > Or build your own private DNS zone infrastructure. If you need to do a > dynamic register to the DNS, you've got to have one anyway. Unless you're > trying to enforce DNSSEC there, this won't be a big hassle. Not depending on > the DNS is a viable solution, nevertheless. > > Kenji Rikitake > > ++> Bob Ippolito [2014-02-17 09:04:22 -0800]: >> The best way to handle this is to force the nodes to come up with a >> predictable name, not dependent on reverse DNS, such as foo@REDACTED For >> discovery, these nodes can register themselves to some central directory >> (dynamic DNS, database, etc.) or send periodic broadcast messages (mDNS or >> some bespoke broadcast scheme). >> >>> On Monday, February 17, 2014, David Welton wrote: >>> >>> Hi, >>> >>> For various reasons, we sometimes have nodes that come up with a long >>> node name that does not nicely map onto the network - say, >>> foo@REDACTED or foo@REDACTED that does not get a >>> DNS entry. The nodes operate in somewhat unknown and unstable network >>> situation, so we may not even know the IP address ahead of time. >>> >>> It'd be nice to be able to - at a later date - force a connection to >>> those nodes by specifying an IP address in the connection code >>> somewhere. >>> >>> Is something like this at all feasible? >>> >>> Thank you > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From elbrujohalcon@REDACTED Wed Feb 19 16:17:15 2014 From: elbrujohalcon@REDACTED (Brujo Benavides @ Inaka) Date: Wed, 19 Feb 2014 12:17:15 -0300 Subject: [erlang-questions] Erlounge @ BA - Feb. 27th Message-ID: <4640B56A-BBB4-4871-B325-EE5B6F52D100@inaka.net> Hi everybody!! We're announcing a new Erlounge at Buenos Aires, Argentina! It will be held on February 27th - 7PM at Inaka's Offices: Darwin 1154 - 1?C (Sector F), Villa Crespo, Buenos Aires. We will be sharing some talks and of course some beers, too! We hope to see you here, if you?re around! Brujo Benavides elbrujohalcon@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.goertzen@REDACTED Wed Feb 19 16:32:12 2014 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Wed, 19 Feb 2014 09:32:12 -0600 Subject: [erlang-questions] maps: pattern-match absent key? Message-ID: Is there any possibility of getting maps:is_key() as a guard so missing keys can be detected more directly? Consider this case of filling defaults into a map before the final clause processes it: myfun(M) when not is_key(abc, M) -> myfun(M#{abc=>123}); myfun(M) when not is_key(def, M) -> myfun(M#{def=>456}); myfun(M) when not is_key(pqr, M) -> myfun(M#{abc=>789}); myfun(#{abc:=ABC, def:=DEF, pqr:=PQR}) -> do_stuff. I can't see how fail clauses could scale up to something like this. Now there are certainly other ways of solving the above problem (lists:foldl comes to mind), but I still think having is_key() as a guard would be valuable in certain situations. It feels about as useful as... f(X) when X/=123 -> do_stuff. ... which I don't do often, but it is good to know it is there when I need it. Dan. PS. I accidentally posted the original question to erlang-patches, moving to erlang-questions. On Tue, Feb 18, 2014 at 2:23 PM, Bj?rn-Egil Dahlberg < wallentin.dahlberg@REDACTED> wrote: > Yes, with fail clauses. > > f(#{ a := _ }) -> {a,present}; > f(_) -> {a,absent}. > > > > 2014-02-18 20:55 GMT+01:00 Daniel Goertzen : > >> Is there a way to pattern-match the absence of a key in a map? >> >> Dan. >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Wed Feb 19 16:57:38 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 19 Feb 2014 10:57:38 -0500 Subject: [erlang-questions] maps: pattern-match absent key? In-Reply-To: References: Message-ID: <20140219155736.GW62889@ferdair.local> It sounds to me like it would be much nicer to do something like this: 1> Default = #{abc => 123, def => 456, ghi => 789}. #{abc => 123,def => 456,ghi => 789} 2> maps:merge(Default, #{}). #{abc => 123,def => 456,ghi => 789} 3> maps:merge(Default, #{abc => <<"bin">>}). #{abc => <<"bin">>,def => 456,ghi => 789} 4> maps:merge(Default, #{abc => <<"bin">>, def => hello}). #{abc => <<"bin">>,def => hello,ghi => 789} According to the spec in EEP-43: maps:merge(M0 :: map(), M1 :: map()) -> M2 :: map(). Syntax equivalence: none Merges two maps into a single map. If two equal keys exists in both maps the value in map M0 will be superseded by the value in map M1. My recommendation is to not have to add a guard, and instead just use a map with all the default values and merge them in with yours. The default map has to be the first argument so that its values can be superseeded by the submitted maps. This is going to be both shorter, simpler, and likely more readable, without needing to call your "check my default value" function over every element up until it reaches a fixed point. Regards, Fred. On 02/19, Daniel Goertzen wrote: > Is there any possibility of getting maps:is_key() as a guard so missing > keys can be detected more directly? > > Consider this case of filling defaults into a map before the final clause > processes it: > > > myfun(M) when not is_key(abc, M) -> > myfun(M#{abc=>123}); > > myfun(M) when not is_key(def, M) -> > myfun(M#{def=>456}); > > myfun(M) when not is_key(pqr, M) -> > myfun(M#{abc=>789}); > > myfun(#{abc:=ABC, def:=DEF, pqr:=PQR}) -> > do_stuff. > > > I can't see how fail clauses could scale up to something like this. Now > there are certainly other ways of solving the above problem (lists:foldl > comes to mind), but I still think having is_key() as a guard would be > valuable in certain situations. It feels about as useful as... > > f(X) when X/=123 -> do_stuff. > > ... which I don't do often, but it is good to know it is there when I need > it. > > > Dan. > PS. I accidentally posted the original question to erlang-patches, moving > to erlang-questions. > > > On Tue, Feb 18, 2014 at 2:23 PM, Bj?rn-Egil Dahlberg < > wallentin.dahlberg@REDACTED> wrote: > > > Yes, with fail clauses. > > > > f(#{ a := _ }) -> {a,present}; > > f(_) -> {a,absent}. > > > > > > > > 2014-02-18 20:55 GMT+01:00 Daniel Goertzen : > > > >> Is there a way to pattern-match the absence of a key in a map? > >> > >> Dan. > >> > >> _______________________________________________ > >> erlang-patches mailing list > >> erlang-patches@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-patches > >> > >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From baliulia@REDACTED Wed Feb 19 17:48:52 2014 From: baliulia@REDACTED (=?UTF-8?B?SWduYXMgVnnFoW5pYXVza2Fz?=) Date: Wed, 19 Feb 2014 17:48:52 +0100 Subject: [erlang-questions] disconnected nodes In-Reply-To: References: <53012CD1.7030605@gmail.com> <530369AB.9070502@gmail.com> Message-ID: <5304E074.7080005@gmail.com> Just a heads up for anyone following this / people from the future who read this: It's not clear what exactly caused the EBADFs and EINVALs, but we were running R15B03 and it seems this was yet another instance of the old 'schedulers not being woken up' issue, as discussed e.g. here: http://erlang.org/pipermail/erlang-questions/2012-October/069585.html Essentially, after some time, only one scheduler (out of 16!) would be utilised and had an ever-growing insane run queue. Setting +sws proposal and +swt very_low seems to have resolved everything and now the run queue distribution is completely uniform. We will also be migrating to R16B ASAP. -- Ignas From overminddl1@REDACTED Wed Feb 19 18:53:03 2014 From: overminddl1@REDACTED (OvermindDL1) Date: Wed, 19 Feb 2014 10:53:03 -0700 Subject: [erlang-questions] [erlide] user poll: supported versions In-Reply-To: References: Message-ID: I do not mind requiring R16+, would give me another reason to upgrade from R15 at least. On Feb 17, 2014 4:25 AM, "Vlad Dumitrescu" wrote: > Hi all! > > This is a question for all erlide users (but not only for them). > > Erlide uses Erlang as a backend and we try to use the same policy as OTP > when it comes to older versions: the current major version plus the two > most recent ones. When R17 is released, this means R16 and R15. > > Until now, it was possible to only have R14 installed and run erlide on > it. The problem that I discovered is that in order to provide full support > for unicode, I need to use erl_scan from R16+, which can't be compiled for > R15 because it contains unicode. > > My question is: would it be a problem to require that erlide itself must > run on R16 or newer? Projects can still be based on earlier releases. This > will require in the worst case that you install R16 alongside your other > versions. > > For most people this is a non-issue, but in some environments one doesn't > have full freedom. > > 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 erlang@REDACTED Wed Feb 19 22:14:11 2014 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 19 Feb 2014 22:14:11 +0100 Subject: [erlang-questions] How to Name Concurrency Patterns Message-ID: Hello, I'm giving a course in distributed and parallel programming in Erlang ... Next week I'll be talking about common concurrency patterns, I was talking with the course adviser, and I rattled off the names of a few concurrency patterns that were well-known and easy to explain. I said I'll do PUB-SUB, pipeline, map-reduce, parallel map, and so on. At this stage the course adviser said that a) things like PUB-SUB would not be familiar to the students and that b) It would take more than 5-10 minutes to explain PUB_SUB. At this stage I thought "pity these patterns don't have well-known names". What I'd like is to make a catalog of "well-known" concurrency patterns. I'd like to name them, and describe them informally, and give the example code in Erlang. For example, here's how I might describe PUB-SUB. == PUB-SUB - There are a number of named channels - You can post messages to a channel ie Publish the message (the PUB) - You can subscribe to a channel (The SUB) - If you are currently subscribed to a channel you will be sent all messages sent to the channel. A rudimentary version of this is about 25 lines of Erlang. A full version with load balancing, removing bottlenecks etc. would be a lot longer, but that's not the point. The basic concurrent structure can be explained in a few lines and named. Pipeline is another example: The output of the first process is the input to the next process and so on... Now I start having problems. Suppose I want to generalize a regular map. To be precise. Suppose map(F, L) means [F(I) || I <- L] pmap(F, L) is parallel map (easy) all the F(I)'s are computed concurrently. pmap(F, L, Max) behaves like map(F,L) with at most Max F(I)'s computed concurrently. What should this be called? "Pool of workers" There seem to be things with well-known names "Load-balancer" "map-reduce" etc. Then there are things that we know of but that are not named. For example my DNS resolver has two DNS names DNS1 and DNS2. If DNS1 is broken the resolver tries DNS2 - what is concurrency pattern called (Pool of responders) or what? The other day I suggested that for fault tolerance it was much easier to let the client go to multiple machines rather than use an expensive load balancer and fail-over system on the server - but there was no convenient name to capture this idea. There sees to be no accepted terminology here - so I'd appreciate any suggestions you have as to the names of common currency patterns that you use together with definitions of what the names mean. Cheers /Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed Feb 19 22:41:24 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 19 Feb 2014 22:41:24 +0100 Subject: [erlang-questions] How to Name Concurrency Patterns In-Reply-To: References: Message-ID: <53052504.7060900@ninenines.eu> On 02/19/2014 10:14 PM, Joe Armstrong wrote: > > > Hello, I'm giving a course in distributed and parallel programming in > Erlang ... > > Next week I'll be talking about common concurrency patterns, I was > talking with the course adviser, and I rattled off the names of a few > concurrency patterns that were well-known and easy to explain. I said > I'll do PUB-SUB, pipeline, map-reduce, parallel map, and so on. > > At this stage the course adviser said that a) things like PUB-SUB > would not be familiar to the students and that b) It would take more > than 5-10 minutes to explain PUB_SUB. Your course adviser lacks imagination. It takes a few seconds to explain PUB-SUB. These things are PUB-SUB: * Twitter * Facebook * Mailing lists * IRC channel / group chat * Newsletter Most of these patterns can be explained with a fairly simple drawing. pipeline: data -> intermediary -> result map-reduce (I simplified, I'm no good at this ASCII stuff): data -> intermediary -\ data -> intermediary ---> result data -> intermediary -/ And so on. A good drawing and a few known examples are worth a million words. I would be interested to hear what name people suggest, but I'm afraid there's about as many concurrency patterns as there are possible combinations. I suggest calling the DNS pattern Howard and the load balancer-replacement pattern Clementine. -- Lo?c Hoguin http://ninenines.eu From dmkolesnikov@REDACTED Wed Feb 19 23:08:16 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Thu, 20 Feb 2014 00:08:16 +0200 Subject: [erlang-questions] How to Name Concurrency Patterns In-Reply-To: References: Message-ID: Hello, Long time ago, I was looking into async message queue patters. I found namomsg tutorial is very nice it depicts most common patterns http://tim.dysinger.net/posts/2013-09-16-getting-started-with-nanomsg.html Best Regards, Dmitry >-|-|-(*> > On 19 Feb 2014, at 23:14, Joe Armstrong wrote: > > > > Hello, I'm giving a course in distributed and parallel programming in > Erlang ... > > Next week I'll be talking about common concurrency patterns, I was > talking with the course adviser, and I rattled off the names of a few > concurrency patterns that were well-known and easy to explain. I said > I'll do PUB-SUB, pipeline, map-reduce, parallel map, and so on. > > At this stage the course adviser said that a) things like PUB-SUB > would not be familiar to the students and that b) It would take more > than 5-10 minutes to explain PUB_SUB. > > At this stage I thought "pity these patterns don't have well-known > names". > > What I'd like is to make a catalog of "well-known" concurrency > patterns. I'd like to name them, and describe them informally, and > give the example code in Erlang. > > For example, here's how I might describe PUB-SUB. > > == PUB-SUB > > - There are a number of named channels > - You can post messages to a channel ie Publish the message (the PUB) > - You can subscribe to a channel (The SUB) > - If you are currently subscribed to a channel you will be sent all messages > sent to the channel. > > A rudimentary version of this is about 25 lines of Erlang. A full > version with load balancing, removing bottlenecks etc. would be a lot > longer, but that's not the point. The basic concurrent structure can > be explained in a few lines and named. > > > Pipeline is another example: The output of the first process is the > input to the next process and so on... > > Now I start having problems. > > Suppose I want to generalize a regular map. > > To be precise. Suppose map(F, L) means [F(I) || I <- L] > > pmap(F, L) is parallel map (easy) all the F(I)'s are computed concurrently. > > pmap(F, L, Max) behaves like map(F,L) with at most Max F(I)'s computed concurrently. > > What should this be called? "Pool of workers" > > There seem to be things with well-known names "Load-balancer" "map-reduce" etc. > > Then there are things that we know of but that are not named. For > example my DNS resolver has two DNS names DNS1 and DNS2. If DNS1 is > broken the resolver tries DNS2 - what is concurrency pattern called > (Pool of responders) or what? > > The other day I suggested that for fault tolerance it was much easier > to let the client go to multiple machines rather than use an expensive > load balancer and fail-over system on the server - but there was no > convenient name to capture this idea. > > There sees to be no accepted terminology here - so I'd appreciate any > suggestions you have as to the names of common currency patterns that > you use together with definitions of what the names mean. > > Cheers > > /Joe > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From erlang@REDACTED Wed Feb 19 23:08:58 2014 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 19 Feb 2014 23:08:58 +0100 Subject: [erlang-questions] How to Name Concurrency Patterns In-Reply-To: <53052504.7060900@ninenines.eu> References: <53052504.7060900@ninenines.eu> Message-ID: On Wed, Feb 19, 2014 at 10:41 PM, Lo?c Hoguin wrote: > On 02/19/2014 10:14 PM, Joe Armstrong wrote: > >> >> >> Hello, I'm giving a course in distributed and parallel programming in >> Erlang ... >> >> Next week I'll be talking about common concurrency patterns, I was >> talking with the course adviser, and I rattled off the names of a few >> concurrency patterns that were well-known and easy to explain. I said >> I'll do PUB-SUB, pipeline, map-reduce, parallel map, and so on. >> >> At this stage the course adviser said that a) things like PUB-SUB >> would not be familiar to the students and that b) It would take more >> than 5-10 minutes to explain PUB_SUB. >> > > Your course adviser lacks imagination. It takes a few seconds to explain > PUB-SUB. These things are PUB-SUB: > > * Twitter > * Facebook > * Mailing lists > * IRC channel / group chat > * Newsletter > The idea is simple - but it could take *hours* to discuss possible implementations. Umm - are message eventually delivered in order? what happens during a failure etc. Do we make a log tree of publishers ... etc. my 5-10 minutes was for idea + simple code > > Most of these patterns can be explained with a fairly simple drawing. > > pipeline: data -> intermediary -> result > > map-reduce (I simplified, I'm no good at this ASCII stuff): > > data -> intermediary -\ > data -> intermediary ---> result > data -> intermediary -/ > > And so on. > > A good drawing and a few known examples are worth a million words. > Now that's trolling - what about Maxwell's equations? All of electrodynamics in four equations This is fun: https://en.wikipedia.org/wiki/Deferent_and_epicycle Ptolemy and his mates thought the planets moved in epicyles, they make wonderful drawings of this, and gave examples - trouble was they were all wrong. Good old Kepler put them right with a few equations. > I would be interested to hear what name people suggest, but I'm afraid > there's about as many concurrency patterns as there are possible > combinations. > Yes - but names like gen_server supervisor, gen_fsm are useful to express designs (to people who know OTP) but we need more well know names > > I suggest calling the DNS pattern Howard and the load balancer-replacement > pattern Clementine. > > ? > -- > Lo?c Hoguin > http://ninenines.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Wed Feb 19 23:10:39 2014 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 19 Feb 2014 23:10:39 +0100 Subject: [erlang-questions] How to Name Concurrency Patterns In-Reply-To: References: Message-ID: Very Nice More like this please. /Joe On Wed, Feb 19, 2014 at 11:08 PM, Dmitry Kolesnikov wrote: > Hello, > > Long time ago, I was looking into async message queue patters. > I found namomsg tutorial is very nice it depicts most common patterns > http://tim.dysinger.net/posts/2013-09-16-getting-started-with-nanomsg.html > > > > Best Regards, > Dmitry > >-|-|-(*> > > > On 19 Feb 2014, at 23:14, Joe Armstrong wrote: > > > > > > > > Hello, I'm giving a course in distributed and parallel programming in > > Erlang ... > > > > Next week I'll be talking about common concurrency patterns, I was > > talking with the course adviser, and I rattled off the names of a few > > concurrency patterns that were well-known and easy to explain. I said > > I'll do PUB-SUB, pipeline, map-reduce, parallel map, and so on. > > > > At this stage the course adviser said that a) things like PUB-SUB > > would not be familiar to the students and that b) It would take more > > than 5-10 minutes to explain PUB_SUB. > > > > At this stage I thought "pity these patterns don't have well-known > > names". > > > > What I'd like is to make a catalog of "well-known" concurrency > > patterns. I'd like to name them, and describe them informally, and > > give the example code in Erlang. > > > > For example, here's how I might describe PUB-SUB. > > > > == PUB-SUB > > > > - There are a number of named channels > > - You can post messages to a channel ie Publish the message (the PUB) > > - You can subscribe to a channel (The SUB) > > - If you are currently subscribed to a channel you will be sent all > messages > > sent to the channel. > > > > A rudimentary version of this is about 25 lines of Erlang. A full > > version with load balancing, removing bottlenecks etc. would be a lot > > longer, but that's not the point. The basic concurrent structure can > > be explained in a few lines and named. > > > > > > Pipeline is another example: The output of the first process is the > > input to the next process and so on... > > > > Now I start having problems. > > > > Suppose I want to generalize a regular map. > > > > To be precise. Suppose map(F, L) means [F(I) || I <- L] > > > > pmap(F, L) is parallel map (easy) all the F(I)'s are computed > concurrently. > > > > pmap(F, L, Max) behaves like map(F,L) with at most Max F(I)'s computed > concurrently. > > > > What should this be called? "Pool of workers" > > > > There seem to be things with well-known names "Load-balancer" > "map-reduce" etc. > > > > Then there are things that we know of but that are not named. For > > example my DNS resolver has two DNS names DNS1 and DNS2. If DNS1 is > > broken the resolver tries DNS2 - what is concurrency pattern called > > (Pool of responders) or what? > > > > The other day I suggested that for fault tolerance it was much easier > > to let the client go to multiple machines rather than use an expensive > > load balancer and fail-over system on the server - but there was no > > convenient name to capture this idea. > > > > There sees to be no accepted terminology here - so I'd appreciate any > > suggestions you have as to the names of common currency patterns that > > you use together with definitions of what the names mean. > > > > Cheers > > > > /Joe > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ph@REDACTED Wed Feb 19 23:19:46 2014 From: ph@REDACTED (Pieter Hintjens) Date: Wed, 19 Feb 2014 23:19:46 +0100 Subject: [erlang-questions] How to Name Concurrency Patterns In-Reply-To: References: Message-ID: Messaging patterns are not always the same as concurrency patterns, IMO. The main concurrency patterns I've seen are: - one ventilator sending jobs to multiple identical workers, with results coming back to one sink (map-reduce, possibly) - multiple clients talking to one broker talking to multiple service workers (service oriented architecture) - asynchronous objects, where each object is an independent actor thread (typical in some APIs) - full cluster, with each node connected to each other node - multiple listeners receiving information and then sending requests back to central services (e.g. stock trading platform) And the main messaging patterns are: - information distribution (publish-subscribe) - workload distribution (many variations) The ZeroMQ Guide has a whole set of patterns with names, including reliability patterns. On Wed, Feb 19, 2014 at 11:10 PM, Joe Armstrong wrote: > Very Nice > > More like this please. > > /Joe > > > On Wed, Feb 19, 2014 at 11:08 PM, Dmitry Kolesnikov > wrote: >> >> Hello, >> >> Long time ago, I was looking into async message queue patters. >> I found namomsg tutorial is very nice it depicts most common patterns >> http://tim.dysinger.net/posts/2013-09-16-getting-started-with-nanomsg.html >> >> >> >> Best Regards, >> Dmitry >> >-|-|-(*> >> >> > On 19 Feb 2014, at 23:14, Joe Armstrong wrote: >> > >> > >> > >> > Hello, I'm giving a course in distributed and parallel programming in >> > Erlang ... >> > >> > Next week I'll be talking about common concurrency patterns, I was >> > talking with the course adviser, and I rattled off the names of a few >> > concurrency patterns that were well-known and easy to explain. I said >> > I'll do PUB-SUB, pipeline, map-reduce, parallel map, and so on. >> > >> > At this stage the course adviser said that a) things like PUB-SUB >> > would not be familiar to the students and that b) It would take more >> > than 5-10 minutes to explain PUB_SUB. >> > >> > At this stage I thought "pity these patterns don't have well-known >> > names". >> > >> > What I'd like is to make a catalog of "well-known" concurrency >> > patterns. I'd like to name them, and describe them informally, and >> > give the example code in Erlang. >> > >> > For example, here's how I might describe PUB-SUB. >> > >> > == PUB-SUB >> > >> > - There are a number of named channels >> > - You can post messages to a channel ie Publish the message (the PUB) >> > - You can subscribe to a channel (The SUB) >> > - If you are currently subscribed to a channel you will be sent all >> > messages >> > sent to the channel. >> > >> > A rudimentary version of this is about 25 lines of Erlang. A full >> > version with load balancing, removing bottlenecks etc. would be a lot >> > longer, but that's not the point. The basic concurrent structure can >> > be explained in a few lines and named. >> > >> > >> > Pipeline is another example: The output of the first process is the >> > input to the next process and so on... >> > >> > Now I start having problems. >> > >> > Suppose I want to generalize a regular map. >> > >> > To be precise. Suppose map(F, L) means [F(I) || I <- L] >> > >> > pmap(F, L) is parallel map (easy) all the F(I)'s are computed >> > concurrently. >> > >> > pmap(F, L, Max) behaves like map(F,L) with at most Max F(I)'s computed >> > concurrently. >> > >> > What should this be called? "Pool of workers" >> > >> > There seem to be things with well-known names "Load-balancer" >> > "map-reduce" etc. >> > >> > Then there are things that we know of but that are not named. For >> > example my DNS resolver has two DNS names DNS1 and DNS2. If DNS1 is >> > broken the resolver tries DNS2 - what is concurrency pattern called >> > (Pool of responders) or what? >> > >> > The other day I suggested that for fault tolerance it was much easier >> > to let the client go to multiple machines rather than use an expensive >> > load balancer and fail-over system on the server - but there was no >> > convenient name to capture this idea. >> > >> > There sees to be no accepted terminology here - so I'd appreciate any >> > suggestions you have as to the names of common currency patterns that >> > you use together with definitions of what the names mean. >> > >> > Cheers >> > >> > /Joe >> > >> > _______________________________________________ >> > 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 mangalaman93@REDACTED Wed Feb 19 23:20:55 2014 From: mangalaman93@REDACTED (aman mangal) Date: Thu, 20 Feb 2014 03:50:55 +0530 Subject: [erlang-questions] How to Name Concurrency Patterns In-Reply-To: References: Message-ID: zeromq has a long list of queuing models- http://zguide.zeromq.org/page:all http://api.zeromq.org/4-0:zmq-socket Aman Mangal 4th year Undergraduate Student Department of Computer Science & Engineering IIT Bombay www.cse.iitb.ac.in/~amanmangal On Thu, Feb 20, 2014 at 3:40 AM, Joe Armstrong wrote: > Very Nice > > More like this please. > > /Joe > > > On Wed, Feb 19, 2014 at 11:08 PM, Dmitry Kolesnikov < > dmkolesnikov@REDACTED> wrote: > >> Hello, >> >> Long time ago, I was looking into async message queue patters. >> I found namomsg tutorial is very nice it depicts most common patterns >> http://tim.dysinger.net/posts/2013-09-16-getting-started-with-nanomsg.html >> >> >> >> Best Regards, >> Dmitry >> >-|-|-(*> >> >> > On 19 Feb 2014, at 23:14, Joe Armstrong wrote: >> > >> > >> > >> > Hello, I'm giving a course in distributed and parallel programming in >> > Erlang ... >> > >> > Next week I'll be talking about common concurrency patterns, I was >> > talking with the course adviser, and I rattled off the names of a few >> > concurrency patterns that were well-known and easy to explain. I said >> > I'll do PUB-SUB, pipeline, map-reduce, parallel map, and so on. >> > >> > At this stage the course adviser said that a) things like PUB-SUB >> > would not be familiar to the students and that b) It would take more >> > than 5-10 minutes to explain PUB_SUB. >> > >> > At this stage I thought "pity these patterns don't have well-known >> > names". >> > >> > What I'd like is to make a catalog of "well-known" concurrency >> > patterns. I'd like to name them, and describe them informally, and >> > give the example code in Erlang. >> > >> > For example, here's how I might describe PUB-SUB. >> > >> > == PUB-SUB >> > >> > - There are a number of named channels >> > - You can post messages to a channel ie Publish the message (the PUB) >> > - You can subscribe to a channel (The SUB) >> > - If you are currently subscribed to a channel you will be sent all >> messages >> > sent to the channel. >> > >> > A rudimentary version of this is about 25 lines of Erlang. A full >> > version with load balancing, removing bottlenecks etc. would be a lot >> > longer, but that's not the point. The basic concurrent structure can >> > be explained in a few lines and named. >> > >> > >> > Pipeline is another example: The output of the first process is the >> > input to the next process and so on... >> > >> > Now I start having problems. >> > >> > Suppose I want to generalize a regular map. >> > >> > To be precise. Suppose map(F, L) means [F(I) || I <- L] >> > >> > pmap(F, L) is parallel map (easy) all the F(I)'s are computed >> concurrently. >> > >> > pmap(F, L, Max) behaves like map(F,L) with at most Max F(I)'s computed >> concurrently. >> > >> > What should this be called? "Pool of workers" >> > >> > There seem to be things with well-known names "Load-balancer" >> "map-reduce" etc. >> > >> > Then there are things that we know of but that are not named. For >> > example my DNS resolver has two DNS names DNS1 and DNS2. If DNS1 is >> > broken the resolver tries DNS2 - what is concurrency pattern called >> > (Pool of responders) or what? >> > >> > The other day I suggested that for fault tolerance it was much easier >> > to let the client go to multiple machines rather than use an expensive >> > load balancer and fail-over system on the server - but there was no >> > convenient name to capture this idea. >> > >> > There sees to be no accepted terminology here - so I'd appreciate any >> > suggestions you have as to the names of common currency patterns that >> > you use together with definitions of what the names mean. >> > >> > Cheers >> > >> > /Joe >> > >> > _______________________________________________ >> > 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 Feb 19 23:22:53 2014 From: g@REDACTED (Garrett Smith) Date: Wed, 19 Feb 2014 16:22:53 -0600 Subject: [erlang-questions] Congrats WhatsApp Message-ID: Erlang based tech makes a wee splash: http://www.businessinsider.com/facebook-is-buying-whatsapp-2014-2 Can we finally approach them to sponsor a geostationary orbit Riak cluster to store mission critical comet proof data now? From demeshchuk@REDACTED Wed Feb 19 23:29:59 2014 From: demeshchuk@REDACTED (Dmitry Demeshchuk) Date: Wed, 19 Feb 2014 14:29:59 -0800 Subject: [erlang-questions] Congrats WhatsApp In-Reply-To: References: Message-ID: Sounds too crazy. That's gonna be, like, a week of WhatsApp team not drinking. Anyway, congratulations, guys! On Wed, Feb 19, 2014 at 2:22 PM, Garrett Smith wrote: > Erlang based tech makes a wee splash: > > http://www.businessinsider.com/facebook-is-buying-whatsapp-2014-2 > > Can we finally approach them to sponsor a geostationary orbit Riak > cluster to store mission critical comet proof data now? > _______________________________________________ > 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 essen@REDACTED Wed Feb 19 23:31:32 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 19 Feb 2014 23:31:32 +0100 Subject: [erlang-questions] Congrats WhatsApp In-Reply-To: References: Message-ID: <530530C4.4090708@ninenines.eu> Breaking news: Whatsapp moves to using HipHop, Thrift and for all its backend software. On 02/19/2014 11:22 PM, Garrett Smith wrote: > Erlang based tech makes a wee splash: > > http://www.businessinsider.com/facebook-is-buying-whatsapp-2014-2 > > Can we finally approach them to sponsor a geostationary orbit Riak > cluster to store mission critical comet proof data now? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From demeshchuk@REDACTED Wed Feb 19 23:32:49 2014 From: demeshchuk@REDACTED (Dmitry Demeshchuk) Date: Wed, 19 Feb 2014 14:32:49 -0800 Subject: [erlang-questions] Congrats WhatsApp In-Reply-To: <530530C4.4090708@ninenines.eu> References: <530530C4.4090708@ninenines.eu> Message-ID: And rewriting all the server code to PHP? On Wed, Feb 19, 2014 at 2:31 PM, Lo?c Hoguin wrote: > Breaking news: Whatsapp moves to using HipHop, Thrift and Facebook tech> for all its backend software. > > > On 02/19/2014 11:22 PM, Garrett Smith wrote: > >> Erlang based tech makes a wee splash: >> >> http://www.businessinsider.com/facebook-is-buying-whatsapp-2014-2 >> >> Can we finally approach them to sponsor a geostationary orbit Riak >> cluster to store mission critical comet proof data now? >> _______________________________________________ >> 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 > -- Best regards, Dmitry Demeshchuk -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed Feb 19 23:33:20 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 19 Feb 2014 23:33:20 +0100 Subject: [erlang-questions] Congrats WhatsApp In-Reply-To: References: <530530C4.4090708@ninenines.eu> Message-ID: <53053130.1080500@ninenines.eu> That's the HipHop part. I probably got the name slightly wrong. On 02/19/2014 11:32 PM, Dmitry Demeshchuk wrote: > And rewriting all the server code to PHP? > > > On Wed, Feb 19, 2014 at 2:31 PM, Lo?c Hoguin > wrote: > > Breaking news: Whatsapp moves to using HipHop, Thrift and worthless Facebook tech> for all its backend software. > > > On 02/19/2014 11:22 PM, Garrett Smith wrote: > > Erlang based tech makes a wee splash: > > http://www.businessinsider.__com/facebook-is-buying-__whatsapp-2014-2 > > > Can we finally approach them to sponsor a geostationary orbit Riak > cluster to store mission critical comet proof data now? > _________________________________________________ > 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 > > > > > > -- > Best regards, > Dmitry Demeshchuk -- Lo?c Hoguin http://ninenines.eu From demeshchuk@REDACTED Wed Feb 19 23:34:20 2014 From: demeshchuk@REDACTED (Dmitry Demeshchuk) Date: Wed, 19 Feb 2014 14:34:20 -0800 Subject: [erlang-questions] Congrats WhatsApp In-Reply-To: <53053130.1080500@ninenines.eu> References: <530530C4.4090708@ninenines.eu> <53053130.1080500@ninenines.eu> Message-ID: Oh, it really is, sorry: https://developers.facebook.com/blog/post/2010/02/02/hiphop-for-php--move-fast/ On Wed, Feb 19, 2014 at 2:33 PM, Lo?c Hoguin wrote: > That's the HipHop part. I probably got the name slightly wrong. > > > On 02/19/2014 11:32 PM, Dmitry Demeshchuk wrote: > >> And rewriting all the server code to PHP? >> >> >> On Wed, Feb 19, 2014 at 2:31 PM, Lo?c Hoguin > > wrote: >> >> Breaking news: Whatsapp moves to using HipHop, Thrift and > worthless Facebook tech> for all its backend software. >> >> >> On 02/19/2014 11:22 PM, Garrett Smith wrote: >> >> Erlang based tech makes a wee splash: >> >> http://www.businessinsider.__com/facebook-is-buying-__ >> whatsapp-2014-2 >> >> > whatsapp-2014-2> >> >> Can we finally approach them to sponsor a geostationary orbit Riak >> cluster to store mission critical comet proof data now? >> _________________________________________________ >> 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 >> >> >> >> >> >> >> -- >> Best regards, >> Dmitry Demeshchuk >> > > -- > Lo?c Hoguin > http://ninenines.eu > -- Best regards, Dmitry Demeshchuk -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Wed Feb 19 23:43:30 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Wed, 19 Feb 2014 17:43:30 -0500 Subject: [erlang-questions] How to Name Concurrency Patterns In-Reply-To: <53052504.7060900@ninenines.eu> References: <53052504.7060900@ninenines.eu> Message-ID: <53053392.4020305@meetinghouse.net> Lo?c Hoguin wrote: > On 02/19/2014 10:14 PM, Joe Armstrong wrote: >> >> >> Hello, I'm giving a course in distributed and parallel programming in >> Erlang ... >> >> Next week I'll be talking about common concurrency patterns, I was >> talking with the course adviser, and I rattled off the names of a few >> concurrency patterns that were well-known and easy to explain. I said >> I'll do PUB-SUB, pipeline, map-reduce, parallel map, and so on. >> >> At this stage the course adviser said that a) things like PUB-SUB >> would not be familiar to the students and that b) It would take more >> than 5-10 minutes to explain PUB_SUB. > > Your course adviser lacks imagination. It takes a few seconds to > explain PUB-SUB. These things are PUB-SUB: > > * Twitter > * Facebook > * Mailing lists > * IRC channel / group chat > * Newsletter I'd agree with that assessment (advisor lacking imagination). PUB-SUB is easy to describe, the name is based on a historically familiar model The other examples I'd use for pub-sub are: - RSS & Atom - cable tv channels - magazine For pipeline: Is it fair to expect students in a course that's looking at concurrency to already be somewhat familiar with Unix, and pipes? Then again, there are also the physical analogs - e.g., gas and oil pipelines; bucket brigades. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From ludovic@REDACTED Wed Feb 19 23:48:05 2014 From: ludovic@REDACTED (Ludovic Demblans) Date: Wed, 19 Feb 2014 23:48:05 +0100 Subject: [erlang-questions] How to Name Concurrency Patterns In-Reply-To: References: Message-ID: I have no idea but i suggest to look for names in people's real life. People can quickly recognize situations they see everyday. The Travelling salesman problem has nothing to do with selling something but it's easy to understand (at least the problem, maybe not the maths). Like, map(F,L) with maximum concurrent processes could be easily explained in terms of checking out at a supermarket :) (ok, not very sexy) My two cents. Le Wed, 19 Feb 2014 23:20:55 +0100, aman mangal a ?crit: > zeromq has a long list of queuing models- > > http://zguide.zeromq.org/page:all > http://api.zeromq.org/4-0:zmq-socket > > Aman Mangal > 4th year Undergraduate Student > Department of Computer Science & Engineering > IIT Bombay > www.cse.iitb.ac.in/~amanmangal > > > On Thu, Feb 20, 2014 at 3:40 AM, Joe Armstrong wrote: > >> Very Nice >> >> More like this please. >> >> /Joe >> >> >> On Wed, Feb 19, 2014 at 11:08 PM, Dmitry Kolesnikov < >> dmkolesnikov@REDACTED> wrote: >> >>> Hello, >>> >>> Long time ago, I was looking into async message queue patters. >>> I found namomsg tutorial is very nice it depicts most common patterns >>> http://tim.dysinger.net/posts/2013-09-16-getting-started-with-nanomsg.html >>> >>> >>> >>> Best Regards, >>> Dmitry >>> >-|-|-(*> >>> >>> > On 19 Feb 2014, at 23:14, Joe Armstrong wrote: >>> > >>> > >>> > >>> > Hello, I'm giving a course in distributed and parallel programming in >>> > Erlang ... >>> > >>> > Next week I'll be talking about common concurrency patterns, I was >>> > talking with the course adviser, and I rattled off the names of a few >>> > concurrency patterns that were well-known and easy to explain. I said >>> > I'll do PUB-SUB, pipeline, map-reduce, parallel map, and so on. >>> > >>> > At this stage the course adviser said that a) things like PUB-SUB >>> > would not be familiar to the students and that b) It would take more >>> > than 5-10 minutes to explain PUB_SUB. >>> > >>> > At this stage I thought "pity these patterns don't have well-known >>> > names". >>> > >>> > What I'd like is to make a catalog of "well-known" concurrency >>> > patterns. I'd like to name them, and describe them informally, and >>> > give the example code in Erlang. >>> > >>> > For example, here's how I might describe PUB-SUB. >>> > >>> > == PUB-SUB >>> > >>> > - There are a number of named channels >>> > - You can post messages to a channel ie Publish the message (the >>> PUB) >>> > - You can subscribe to a channel (The SUB) >>> > - If you are currently subscribed to a channel you will be sent >>> all >>> messages >>> > sent to the channel. >>> > >>> > A rudimentary version of this is about 25 lines of Erlang. A full >>> > version with load balancing, removing bottlenecks etc. would be a lot >>> > longer, but that's not the point. The basic concurrent structure can >>> > be explained in a few lines and named. >>> > >>> > >>> > Pipeline is another example: The output of the first process is the >>> > input to the next process and so on... >>> > >>> > Now I start having problems. >>> > >>> > Suppose I want to generalize a regular map. >>> > >>> > To be precise. Suppose map(F, L) means [F(I) || I <- L] >>> > >>> > pmap(F, L) is parallel map (easy) all the F(I)'s are computed >>> concurrently. >>> > >>> > pmap(F, L, Max) behaves like map(F,L) with at most Max F(I)'s >>> computed >>> concurrently. >>> > >>> > What should this be called? "Pool of workers" >>> > >>> > There seem to be things with well-known names "Load-balancer" >>> "map-reduce" etc. >>> > >>> > Then there are things that we know of but that are not named. For >>> > example my DNS resolver has two DNS names DNS1 and DNS2. If DNS1 is >>> > broken the resolver tries DNS2 - what is concurrency pattern called >>> > (Pool of responders) or what? >>> > >>> > The other day I suggested that for fault tolerance it was much easier >>> > to let the client go to multiple machines rather than use an >>> expensive >>> > load balancer and fail-over system on the server - but there was no >>> > convenient name to capture this idea. >>> > >>> > There sees to be no accepted terminology here - so I'd appreciate any >>> > suggestions you have as to the names of common currency patterns that >>> > you use together with definitions of what the names mean. >>> > >>> > Cheers >>> > >>> > /Joe >>> > >>> > _______________________________________________ >>> > 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 >> >> -- Utilisant le logiciel de courrier r?volutionnaire d'Opera : http://www.opera.com/mail/ From mfidelman@REDACTED Wed Feb 19 23:48:45 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Wed, 19 Feb 2014 17:48:45 -0500 Subject: [erlang-questions] How to Name Concurrency Patterns In-Reply-To: References: <53052504.7060900@ninenines.eu> Message-ID: <530534CD.1090608@meetinghouse.net> Joe Armstrong wrote: > > Ptolemy and his mates thought the planets moved in epicyles, they make > wonderful drawings > of this, and gave examples - trouble was they were all wrong. Good old > Kepler put them > right with a few equations. Of course the numerical algorithms used to produce navigational tables look suspiciously like cycles and epicycles :-) > > > I would be interested to hear what name people suggest, but I'm > afraid there's about as many concurrency patterns as there are > possible combinations. > > > Yes - but names like gen_server supervisor, gen_fsm are useful to > express designs (to people who know > OTP) but we need more well know names how about supervisor and finite state machine - pretty standard terminology > > I suggest calling the DNS pattern Howard and the load > balancer-replacement pattern Clementine. > > > ? > How about Fred (as in "Let Fred do it" - the generic autopilot), or George (as in "I'll love him, and hug him, and call him George.") :-) Cheers, Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From bob@REDACTED Wed Feb 19 23:51:07 2014 From: bob@REDACTED (Bob Ippolito) Date: Wed, 19 Feb 2014 14:51:07 -0800 Subject: [erlang-questions] Congrats WhatsApp In-Reply-To: <530530C4.4090708@ninenines.eu> References: <530530C4.4090708@ninenines.eu> Message-ID: When I was there, most of Facebook's interesting code was in C++ and Java. A bit of Python for management. Massive amounts of PHP for front-end and business logic type stuff. Native code for mobile stuff. They have some cool services built in Haskell these days too (and they have some great Haskell folks) but not so much in 2012. It's a very pragmatic shop. >From what I understood, Erlang didn't succeed there in the past because they had a hard time recruiting / training for Erlang and they didn't want to do all the work to make it mesh well with how they build and manage their other services. It was easier for them to rewrite and maintain in C++ than develop deep Erlang expertise. On Wed, Feb 19, 2014 at 2:31 PM, Lo?c Hoguin wrote: > Breaking news: Whatsapp moves to using HipHop, Thrift and Facebook tech> for all its backend software. > > > On 02/19/2014 11:22 PM, Garrett Smith wrote: > >> Erlang based tech makes a wee splash: >> >> http://www.businessinsider.com/facebook-is-buying-whatsapp-2014-2 >> >> Can we finally approach them to sponsor a geostationary orbit Riak >> cluster to store mission critical comet proof data now? >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- > Lo?c Hoguin > http://ninenines.eu > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed Feb 19 23:53:35 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 19 Feb 2014 23:53:35 +0100 Subject: [erlang-questions] How to Name Concurrency Patterns In-Reply-To: References: <53052504.7060900@ninenines.eu> Message-ID: <530535EF.2080300@ninenines.eu> On 02/19/2014 11:08 PM, Joe Armstrong wrote: > The idea is simple - but it could take *hours* to discuss possible > implementations. > Umm - are message eventually delivered in order? what happens during a > failure etc. Do we make > a log tree of publishers ... etc. It really sounds like you should actually say those open ended questions after showing a simple implementation, since you don't have the time to cover them. > Most of these patterns can be explained with a fairly simple drawing. > > pipeline: data -> intermediary -> result > > map-reduce (I simplified, I'm no good at this ASCII stuff): > > data -> intermediary -\ > data -> intermediary ---> result > data -> intermediary -/ > > And so on. > > A good drawing and a few known examples are worth a million words. > > > Now that's trolling - what about Maxwell's equations? All of > electrodynamics in > four equations > > This is fun: > > https://en.wikipedia.org/wiki/Deferent_and_epicycle > > Ptolemy and his mates thought the planets moved in epicyles, they make > wonderful drawings > of this, and gave examples - trouble was they were all wrong. Good old > Kepler put them > right with a few equations. For most purposes it's enough to say that the sun rises in the morning, it doesn't have to be precise. You don't start by teaching general relativity, you first make an observation, give a blurry picture of what happens, and then dig a little to learn something from it, and then you observe again and continue ad infinitum. Since you only have 5-10 minutes per pattern, you probably don't have enough time to do that more than once or twice, but it's still a starting point as it tells people where to look at to learn more. Of course the picture will be more or less blurry depending on who you talk to. Genius students can probably get it if you get deep from the start, while the duck will need the colorful drawing with big letters. I'll stop there as I am not helping you finding names by discussing this. Good luck! -- Lo?c Hoguin http://ninenines.eu From hugo@REDACTED Thu Feb 20 00:03:16 2014 From: hugo@REDACTED (Hugo Mills) Date: Wed, 19 Feb 2014 23:03:16 +0000 Subject: [erlang-questions] How to Name Concurrency Patterns In-Reply-To: References: Message-ID: <20140219230316.GH3351@carfax.org.uk> On Wed, Feb 19, 2014 at 10:14:11PM +0100, Joe Armstrong wrote: > Hello, I'm giving a course in distributed and parallel programming in > Erlang ... > > Next week I'll be talking about common concurrency patterns, I was > talking with the course adviser, and I rattled off the names of a few > concurrency patterns that were well-known and easy to explain. I said > I'll do PUB-SUB, pipeline, map-reduce, parallel map, and so on. > [snip] > > Pipeline is another example: The output of the first process is the > input to the next process and so on... > > Now I start having problems. > > Suppose I want to generalize a regular map. > > To be precise. Suppose map(F, L) means [F(I) || I <- L] > > pmap(F, L) is parallel map (easy) all the F(I)'s are computed concurrently. > > pmap(F, L, Max) behaves like map(F,L) with at most Max F(I)'s computed > concurrently. > > What should this be called? "Pool of workers" > > There seem to be things with well-known names "Load-balancer" "map-reduce" > etc. > > Then there are things that we know of but that are not named. For > example my DNS resolver has two DNS names DNS1 and DNS2. If DNS1 is > broken the resolver tries DNS2 - what is concurrency pattern called > (Pool of responders) or what? > > The other day I suggested that for fault tolerance it was much easier > to let the client go to multiple machines rather than use an expensive > load balancer and fail-over system on the server - but there was no > convenient name to capture this idea. > > There sees to be no accepted terminology here - so I'd appreciate any > suggestions you have as to the names of common currency patterns that > you use together with definitions of what the names mean. Not directly concurrency patterns, but on the face of it, it seems that there's an overlap with Roy Fielding's classification of distributed systems patterns[1] here. Hugo. [1] https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm -- === Hugo Mills: hugo@REDACTED carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- The last man on Earth sat in a room. Suddenly, there was a --- knock at the door. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 811 bytes Desc: Digital signature URL: From ok@REDACTED Thu Feb 20 00:10:01 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 20 Feb 2014 12:10:01 +1300 Subject: [erlang-questions] modular otp concerns In-Reply-To: References: <89DD9A4D-E3C0-47C1-8063-1949A8A4F1F0@cs.otago.ac.nz> Message-ID: <9FAEF0B6-DA32-4CF3-A016-3274BC8C8FA6@cs.otago.ac.nz> On 20/02/2014, at 1:37 AM, Tuncer Ayaz wrote: >> Considering what Erlang's used for, it doesn't matter >> very much if chunks of OTP are split off and pulled >> over the net when you need them (during initial testing). > > What counts is what we get in the default Erlang "platform" for use > out of the box. Complete agreement. What I was trying to say was that as long as it *looks* as though everything is there when you want it, it doesn't much matter how that's achieved. > This is especially important for escripts. Right now > we can write escripts relying on many useful libs in the base install. > Once you remove inets from the base install, you lose the ability to > bootstrap your project with an escript. Agreement again. That would be like shipping the present system but without the ability to read modules from disc. From darach@REDACTED Thu Feb 20 00:12:47 2014 From: darach@REDACTED (Darach Ennis) Date: Wed, 19 Feb 2014 23:12:47 +0000 Subject: [erlang-questions] How to Name Concurrency Patterns In-Reply-To: <530534CD.1090608@meetinghouse.net> References: <53052504.7060900@ninenines.eu> <530534CD.1090608@meetinghouse.net> Message-ID: There's a reasonable collection of resources here for parallel patterns: http://www.cs.uiuc.edu/homes/snir/PPP/ POSA2 probably has the most accessible and well known concurrency patterns: http://www.cs.wustl.edu/~schmidt/POSA/POSA2/ POSA4 has a reasonable set for distributed systems, at least the well known patterns: http://www.dre.vanderbilt.edu/~schmidt/POSA4-TOC.pdf Another good one is The Art of Multiprocessor Programming: http://www.amazon.com/Art-Multiprocessor-Programming-ebook/dp/B00245A4U0 Naming sucks though. An audience with Java/JVM experience may know of the LMAX Disruptor and maybe the coalescing ring buffer but that level of detail may be too audience specific. Or, being general, these are just queue variants. Forgetting the patterns for a minute. Making sure Amdahl, Little and Moore's laws are known and understood would be a good start. Possibly with explaining what being concurrent, parallel or simultaneous means. Good foundations irrespective of the terminology ultimately chosen... Cheers, Darach. On Wed, Feb 19, 2014 at 10:48 PM, Miles Fidelman wrote: > Joe Armstrong wrote: > >> >> Ptolemy and his mates thought the planets moved in epicyles, they make >> wonderful drawings >> of this, and gave examples - trouble was they were all wrong. Good old >> Kepler put them >> right with a few equations. >> > > Of course the numerical algorithms used to produce navigational tables > look suspiciously like cycles and epicycles :-) > > > >> >> I would be interested to hear what name people suggest, but I'm >> afraid there's about as many concurrency patterns as there are >> possible combinations. >> >> >> Yes - but names like gen_server supervisor, gen_fsm are useful to express >> designs (to people who know >> OTP) but we need more well know names >> > > how about supervisor and finite state machine - pretty standard terminology > > > >> I suggest calling the DNS pattern Howard and the load >> balancer-replacement pattern Clementine. >> >> >> ? >> >> How about Fred (as in "Let Fred do it" - the generic autopilot), or > George (as in "I'll love him, and hug him, and call him George.") :-) > > Cheers, > > Miles > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenji@REDACTED Thu Feb 20 01:31:11 2014 From: kenji@REDACTED (Kenji Rikitake) Date: Thu, 20 Feb 2014 09:31:11 +0900 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: References: <53021D9F.7060605@meetinghouse.net> <530325D2.4090303@erl.io> <6F9CBF02-CE44-487E-84D0-16998E5DCC42@gmail.com> <20140218113641.GA13616@k2r.org> Message-ID: <20140220003111.GA26268@k2r.org> ++> Tuncer Ayaz [2014-02-18 13:53:09 +0100]: > On Tue, Feb 18, 2014 at 12:36 PM, Kenji Rikitake wrote: > > A practical issue: uploading to GitHub is *painfully slow* > > (< 200kbytes/sec) > > In one go with no retry or resume? I broke the data into chunks. See this for the details: https://github.com/jj1bdx/tinymtdc-longbatch > Is it the same on different .jp networks? Not measured, but should be. I suspect it's traffic shaping, but who knows. > > I think depending on GitHub is not good, though. > > I've said it before in another package repo discussion, but I'd like > to second the opinion that making use of a mirror network is crucial. +1. CDN has become a must for a usable data replication service. > Reliability and distributed availability are very important. According > to mirrors.cpan.org, it is mirrored on 486 sites, and I think Erlang's > FOSS projects qualify to be distributed in a mirror network, too. For > FOSS projects it doesn't make sense to have a central package repo > operated by a commercial entity. I don't know how CPAN is maintained, but > it seems to have served them well and should be considered as > inspiration. Finally, do not underestimate the importance of having an > archive of old versions. Also +1. CPAN works very well. Kenji Rikitake From mjtruog@REDACTED Thu Feb 20 05:04:49 2014 From: mjtruog@REDACTED (Michael Truog) Date: Wed, 19 Feb 2014 20:04:49 -0800 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <20140220003111.GA26268@k2r.org> References: <53021D9F.7060605@meetinghouse.net> <530325D2.4090303@erl.io> <6F9CBF02-CE44-487E-84D0-16998E5DCC42@gmail.com> <20140218113641.GA13616@k2r.org> <20140220003111.GA26268@k2r.org> Message-ID: <53057EE1.9010102@gmail.com> On 02/19/2014 04:31 PM, Kenji Rikitake wrote: >>> I think depending on GitHub is not good, though. >> > >> >I've said it before in another package repo discussion, but I'd like >> >to second the opinion that making use of a mirror network is crucial. > +1. CDN has become a must for a usable data replication service. > Please try to keep in mind the possibility of using BitTorrent for data replication and raw throughput (Joe Armstrong already mentioned this as a direction). In my mind, BitTorrent /= CDN. From erlang@REDACTED Thu Feb 20 07:12:22 2014 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 20 Feb 2014 07:12:22 +0100 Subject: [erlang-questions] Congrats WhatsApp In-Reply-To: References: Message-ID: On Wed, Feb 19, 2014 at 11:22 PM, Garrett Smith wrote: > Erlang based tech makes a wee splash: > > http://www.businessinsider.com/facebook-is-buying-whatsapp-2014-2 I keep telling my students that Erlang is good for messaging, this might make a good example. I can hide it on in the footnotes on page 157 - hope it won't be perceived as excessive bragging :-) /Joe > > > Can we finally approach them to sponsor a geostationary orbit Riak > cluster to store mission critical comet proof data now? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Thu Feb 20 08:58:13 2014 From: ulf@REDACTED (Ulf Wiger) Date: Thu, 20 Feb 2014 08:58:13 +0100 Subject: [erlang-questions] How to Name Concurrency Patterns In-Reply-To: References: Message-ID: <59B774DA-FE13-4588-8263-310FA11E5D47@feuerlabs.com> Perhaps it should be called "concurrency-oriented patterns" instead? Strictly speaking, a pipe isn't about concurrency so much as serialization/chaining (and can be executed without any concurrency at all), but it's most likely used more often than not in conjunction with concurrency. A pattern I don't see mentioned often is what I might call 'orchestrator', where one process is assigned the responsibility for the overall 'script', dispatches tasks to workers and collects the results. I would say that pmap() is a simple orchestrator pattern, and a good opportunity to explain both supervision and selective receive. BR, Ulf W Ulf Wiger, Feuerlabs, Inc. http://www.feuerlabs.com > 19 feb 2014 kl. 22:14 skrev Joe Armstrong : > > > > Hello, I'm giving a course in distributed and parallel programming in > Erlang ... > > Next week I'll be talking about common concurrency patterns, I was > talking with the course adviser, and I rattled off the names of a few > concurrency patterns that were well-known and easy to explain. I said > I'll do PUB-SUB, pipeline, map-reduce, parallel map, and so on. > > At this stage the course adviser said that a) things like PUB-SUB > would not be familiar to the students and that b) It would take more > than 5-10 minutes to explain PUB_SUB. > > At this stage I thought "pity these patterns don't have well-known > names". > > What I'd like is to make a catalog of "well-known" concurrency > patterns. I'd like to name them, and describe them informally, and > give the example code in Erlang. > > For example, here's how I might describe PUB-SUB. > > == PUB-SUB > > - There are a number of named channels > - You can post messages to a channel ie Publish the message (the PUB) > - You can subscribe to a channel (The SUB) > - If you are currently subscribed to a channel you will be sent all messages > sent to the channel. > > A rudimentary version of this is about 25 lines of Erlang. A full > version with load balancing, removing bottlenecks etc. would be a lot > longer, but that's not the point. The basic concurrent structure can > be explained in a few lines and named. > > > Pipeline is another example: The output of the first process is the > input to the next process and so on... > > Now I start having problems. > > Suppose I want to generalize a regular map. > > To be precise. Suppose map(F, L) means [F(I) || I <- L] > > pmap(F, L) is parallel map (easy) all the F(I)'s are computed concurrently. > > pmap(F, L, Max) behaves like map(F,L) with at most Max F(I)'s computed concurrently. > > What should this be called? "Pool of workers" > > There seem to be things with well-known names "Load-balancer" "map-reduce" etc. > > Then there are things that we know of but that are not named. For > example my DNS resolver has two DNS names DNS1 and DNS2. If DNS1 is > broken the resolver tries DNS2 - what is concurrency pattern called > (Pool of responders) or what? > > The other day I suggested that for fault tolerance it was much easier > to let the client go to multiple machines rather than use an expensive > load balancer and fail-over system on the server - but there was no > convenient name to capture this idea. > > There sees to be no accepted terminology here - so I'd appreciate any > suggestions you have as to the names of common currency patterns that > you use together with definitions of what the names mean. > > Cheers > > /Joe > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From mabrek@REDACTED Thu Feb 20 09:26:16 2014 From: mabrek@REDACTED (Anton Lebedevich) Date: Thu, 20 Feb 2014 12:26:16 +0400 Subject: [erlang-questions] Creating a diagnostic memory dump of live erlang VM In-Reply-To: References: Message-ID: <5305BC28.4070906@gmail.com> On 02/19/2014 04:00 AM, Vladimir Ralev wrote: > Hello all, > > As a Java developer I really miss being able to create a "heap dump" of > a live Erlang VM where I can see the objects in each process and the > current process stack variables/trace. I realise there is no java-like > heap in Erlang but there are the processes, mailboxes, stacks, file > handles, sockets, ets and so on. Another thing which I missed a lot after converting from java to erlang is a thread dump. It turned out that it's possible to get all stacktraces for all processes (even with function arguments) via erlang:system_info(procs). It returns them as text so it's better to dump it to file immediately: file:write_file("/tmp/procs.txt",erlang:system_info(procs)). Format of these traces is quite interesting (undocumented) the best description I found is in the mailing list http://erlang.org/pipermail/erlang-questions/2012-November/070609.html Regards, Anton Lebedevich. From vladdu55@REDACTED Thu Feb 20 10:30:39 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 20 Feb 2014 10:30:39 +0100 Subject: [erlang-questions] Creating a diagnostic memory dump of live erlang VM In-Reply-To: <5305BC28.4070906@gmail.com> References: <5305BC28.4070906@gmail.com> Message-ID: Hi, On Thu, Feb 20, 2014 at 9:26 AM, Anton Lebedevich wrote: > Another thing which I missed a lot after converting from java to erlang > is a thread dump. It turned out that it's possible to get all > stacktraces for all processes (even with function arguments) via > erlang:system_info(procs). > > It returns them as text so it's better to dump it to file immediately: > file:write_file("/tmp/procs.txt",erlang:system_info(procs)). > > Format of these traces is quite interesting (undocumented) the best > description I found is in the mailing list > http://erlang.org/pipermail/erlang-questions/2012-November/070609.html I might just as well ask the obvious question: why is not this information available even as normal Erlang terms, so that one doesn't need to parse it? When writing a crash dump, it doesn't matter, but if it should be used at runtime it's a pain to parse it... This applies to the other results from system_info/1 that are dumped as text. regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From hm@REDACTED Thu Feb 20 12:45:37 2014 From: hm@REDACTED (=?ISO-8859-1?Q?H=E5kan_Mattsson?=) Date: Thu, 20 Feb 2014 12:45:37 +0100 Subject: [erlang-questions] Dialyzer and callbacks Message-ID: Where does dialyzer look for beam files containing behaviour_info(callbacks)? It does not seem like it cares about the code path. Neither -r, -pa nor ERL_LIBS seems to work. Putting the beam-files at stdlib/ebin does however work. A poor confused soul. /H?kan -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Thu Feb 20 13:12:46 2014 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 20 Feb 2014 13:12:46 +0100 Subject: [erlang-questions] Dialyzer and callbacks In-Reply-To: References: Message-ID: <5305F13E.4080300@cs.ntua.gr> On 02/20/2014 12:45 PM, H?kan Mattsson wrote: > Where does dialyzer look for beam files containing > behaviour_info(callbacks)? > > It does not seem like it cares about the code path. Neither -r, -pa nor > ERL_LIBS seems to work. Putting the beam-files at stdlib/ebin does > however work. > > A poor confused soul. [You managed to confuse me too, so I hope the following answer does not make the situation worse...] Dialyzer does not look at behaviour_info(callbacks) at all. Instead it looks for -callback ... attributes (i.e. type declarations). Take e.g. a look at the source code of gen_server: https://github.com/erlang/otp/blob/master/lib/stdlib/src/gen_server.erl You will find no behaviour_info/1 function declared there; modern Erlang code has callback declarations instead (from which the behaviour_info/1 function is automatically generated as shown below). Eshell V6.0 (abort with ^G) 1> gen_server:behaviour_info(callbacks). [{init,1}, {handle_call,3}, {handle_cast,2}, {handle_info,2}, {terminate,2}, {code_change,3}] Now, if your question is: where does Dialyzer look for a my_behav.beam file when it finds a -behaviour(my_behav). attribute in some file it analyzes, the answer is that either you also supply this file to the analysis or you make sure it's in the PLT (which might explain why you claim that it works when you put it in stdlib/ebin because presumably your PLT includes info about stdlib). Kostis From hans.bolinder@REDACTED Thu Feb 20 13:49:33 2014 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Thu, 20 Feb 2014 12:49:33 +0000 Subject: [erlang-questions] [erlang-bugs] Crash during compilation In-Reply-To: <525E605F.5010104@gmail.com> References: <759CF9F8-E280-4DB9-888F-EC66A66BA45B@gmail.com> <9EBA66D6-7EB2-4AD7-B393-C1C419EB2762@gmail.com> <3B6E17BB-DDD0-4C10-B0E1-265A002555F4@gmail.com>, <525E605F.5010104@gmail.com> Message-ID: <56466BD70414EA48969B4064696CF28C037AF0FB@ESESSMB207.ericsson.se> [Richard Carlsson:] > Confirmed. Seems like the function leave_file/2 in epp.erl propagates > the macro definitions from the include file, but not the 'uses' field of > the preprocessor state when it leaves the header file. Thanks! The bug will be fixed in Erlang/OTP 17.0. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From askjuise@REDACTED Thu Feb 20 14:31:03 2014 From: askjuise@REDACTED (Alexander Petrovsky) Date: Thu, 20 Feb 2014 16:31:03 +0300 Subject: [erlang-questions] Erlang release and config includes Message-ID: Hello! I have the problem on erlang release upgrade and config includes. I have the follow config structure of sys.config with app.config (that generated dynamically) include: /usr/local/lib/myapp/releases/1.0.8/sys.config: [ .... "/etc/myapp/app.config" ]. I added new application myapp2 into myapp, and want to upgrade myapp to new version (1.0.9). Firstly I add the settings for new application myapp2 in app.conf file, and then run upgrade the Erlang application: release_handler:unpack_release, release_handler:check_install_release, release_handler:install_release The new version of myapp (1.0.9) run the myapp2 application. myapp2 try read the settings and crash due badmatch error, i.e. no settings in config for myapp2. When I put settings for new application myapp2 into sys.config, all works without any problems. Looks like, release_handler doesn't re-read included config files. -- ?????????? ????????? / Alexander Petrovsky, Skype: askjuise Phone: +7 914 8 820 815 -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.mueller@REDACTED Thu Feb 20 14:31:36 2014 From: magnus.mueller@REDACTED (Magnus Mueller) Date: Thu, 20 Feb 2014 13:31:36 +0000 Subject: [erlang-questions] infrequent socket_closed_remotely errors with httpc Message-ID: Hello. We are struggling with a hard-to-reproduce problem with httpc were we sometimes encounter `{error,socket_closed_remotely}` when querying our simple webserver. Sometimes this happens with yaws as well. The error happens very infrequently and is thus hard to reproduce. Both the webserver and httpc run in the same VM (which might be the cause of the problem). Interestingly, the problem is more likely to occur if the system is under cpu-heavy load, e.g. when using stress[1]: stress --cpu 6 Did anybody of you encounter similar problems? We are running out of ideas and I could not yet come up with a small example to reproduce the issue. Magnus [1] https://web.archive.org/web/20130520190152/http://weather.ou.edu/~apw/projects/stress/ , the original website seems to be down. From sean@REDACTED Thu Feb 20 15:56:58 2014 From: sean@REDACTED (Sean Cribbs) Date: Thu, 20 Feb 2014 08:56:58 -0600 Subject: [erlang-questions] How to Name Concurrency Patterns In-Reply-To: <59B774DA-FE13-4588-8263-310FA11E5D47@feuerlabs.com> References: <59B774DA-FE13-4588-8263-310FA11E5D47@feuerlabs.com> Message-ID: On Thu, Feb 20, 2014 at 1:58 AM, Ulf Wiger wrote: > A pattern I don't see mentioned often is what I might call 'orchestrator', > where one process is assigned the responsibility for the overall 'script', > dispatches tasks to workers and collects the results. I would say that > pmap() is a simple orchestrator pattern, and a good opportunity to explain > both supervision and selective receive. > I was going to mention something like this, but didn't know what to call it; thanks Ulf! We have a bunch of them in Riak, gen_fsm processes that fanout requests to other processes and collect and coalesce the results. Here's some more patterns that should be blindingly obvious (and maybe they were already mentioned, or are too simple to mention): Client-Server (gen_server, e.g.) Proxy (one process mediating access to another) Registry (finding other processes or services) Monitor (less like a supervisor, more like just reporting on what's going on) -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Thu Feb 20 22:03:56 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 21 Feb 2014 10:03:56 +1300 Subject: [erlang-questions] How to Name Concurrency Patterns In-Reply-To: <59B774DA-FE13-4588-8263-310FA11E5D47@feuerlabs.com> References: <59B774DA-FE13-4588-8263-310FA11E5D47@feuerlabs.com> Message-ID: <23F84ACF-AE1D-4AC8-998C-F0EDFFAFFA7F@cs.otago.ac.nz> On 20/02/2014, at 8:58 PM, Ulf Wiger wrote: > Perhaps it should be called "concurrency-oriented patterns" instead? Strictly speaking, a pipe isn't about concurrency so much as serialization/chaining (and can be executed without any concurrency at all), Well, UNIX pipelines are a good way to introduce the issues of - unbounded buffer -vs- bounded buffer - multiple reads and/or multiple writers (two or more concurrent processes can write to the same pipe, chunks smaller than PIPE_BUF -- somewhat misleadingly named -- are atomic, bigger chunks maybe interleaved) (two or more concurrent processes can read from a pipe; presumably PIPE_BUF also applies to reading although I've never seen this stated) - flow control - why popen(cmd, mode) allows mode = "r" and "w" but not "r+" or "w+" > A pattern I don't see mentioned often is what I might call 'orchestrator', where one process is assigned the responsibility for the overall 'script', dispatches tasks to workers and collects the results. Turns out that's a sequential OOP pattern: http://codereview.stackexchange.com/questions/25435/sequential-execution-orchestrator-pattern Where do you draw the line (or indeed, is there any point in drawing a line) between this and Master/Worker? > I would say that pmap() is a simple orchestrator pattern, and a good opportunity to explain both supervision and selective receive. pmap is a simple master/worker case where all the workers are doing the same kind of job. From ok@REDACTED Thu Feb 20 22:10:23 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 21 Feb 2014 10:10:23 +1300 Subject: [erlang-questions] How to Name Concurrency Patterns In-Reply-To: References: <59B774DA-FE13-4588-8263-310FA11E5D47@feuerlabs.com> Message-ID: On 21/02/2014, at 3:56 AM, Sean Cribbs wrote: > Client-Server (gen_server, e.g.) > Proxy (one process mediating access to another) > Registry (finding other processes or services) > Monitor (less like a supervisor, more like just reporting on what's going on) Y'know, this really illustrate what Joe's problem is. "Monitor" is a well known concurrency pattern, but a different one: http://en.wikipedia.org/wiki/Concurrency_pattern links "Monitor pattern" to http://en.wikipedia.org/wiki/Monitor_(synchronization) which is Hoare monitors. This one sounds close to "Observer" except for being concurrent, and it would appear to involve something close to what Joe was calling PUB-SUB. From nem@REDACTED Thu Feb 20 22:21:18 2014 From: nem@REDACTED (Geoff Cant) Date: Thu, 20 Feb 2014 13:21:18 -0800 Subject: [erlang-questions] Creating a diagnostic memory dump of live erlang VM In-Reply-To: References: <5305BC28.4070906@gmail.com> Message-ID: I would love it if erl_crash.dump was written in the external term format. We started working on an erlang parser library for the existing text format at Heroku, but it's annoying work and I'm lazy. I would offer someone a holiday-card-of-their-choice to do it, but I'm behind on sending Fred and Steve theirs for last year. :) -- Geoff Cant On 2014-02-20, at 01:30 , Vlad Dumitrescu wrote: > Hi, > > On Thu, Feb 20, 2014 at 9:26 AM, Anton Lebedevich wrote: > Another thing which I missed a lot after converting from java to erlang > is a thread dump. It turned out that it's possible to get all > stacktraces for all processes (even with function arguments) via > erlang:system_info(procs). > > It returns them as text so it's better to dump it to file immediately: > file:write_file("/tmp/procs.txt",erlang:system_info(procs)). > > Format of these traces is quite interesting (undocumented) the best > description I found is in the mailing list > http://erlang.org/pipermail/erlang-questions/2012-November/070609.html > > I might just as well ask the obvious question: why is not this information available even as normal Erlang terms, so that one doesn't need to parse it? When writing a crash dump, it doesn't matter, but if it should be used at runtime it's a pain to parse it... This applies to the other results from system_info/1 that are dumped as text. > > regards, > Vlad From jay@REDACTED Thu Feb 20 23:57:00 2014 From: jay@REDACTED (Jay Nelson) Date: Thu, 20 Feb 2014 14:57:00 -0800 Subject: [erlang-questions] Generic server and selective receives Message-ID: I gave a talk at Vancouver Erlang Factory Lite in 2012: Managing processes without OTP, and how to make them OTP compliant http://www.erlang-factory.com/conference/Vancouver2012/speakers/JayNelson -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattevans123@REDACTED Fri Feb 21 04:47:58 2014 From: mattevans123@REDACTED (Matthew Evans) Date: Thu, 20 Feb 2014 22:47:58 -0500 Subject: [erlang-questions] Creating a diagnostic memory dump of live erlang VM In-Reply-To: References: , <5305BC28.4070906@gmail.com>, Message-ID: Hi, I took it on myself to write a little module. This will produce a crash report that will display most of the important data that can be loaded into the crash dump viewer. From Erlang run report:crash_report(). The crash dump goes to /tmp/erl_crash.dump and can be viewed from Erlang via your browser when you run crashdump_viewer:start(). from your Erlang shell. ========= -module(report). -export([crash_report/0]). crash_report() -> Date = erlang:list_to_binary(rfc1123_local_date()), Header = binary:list_to_bin([<<"=erl_crash_dump:0.2\n">>,Date,<<"\nSystem version: ">>]), Ets = ets_info(), Report = binary:list_to_bin([Header,erlang:list_to_binary(erlang:system_info(system_version)),erlang:system_info(info),erlang:system_info(procs),Ets,erlang:system_info(dist), <<"=loaded_modules\n">>,binary:replace(erlang:system_info(loaded),<<"\n">>,<<"\n=mod:">>,[global])]), file:write_file("/tmp/erl_crash.dump",Report). ets_info() -> binary:list_to_bin([ets_table_info(T)||T<-ets:all()]). ets_table_info(Table) -> Info = ets:info(Table), Owner = erlang:list_to_binary(erlang:pid_to_list(proplists:get_value(owner,Info))), TableN = erlang:list_to_binary(erlang:atom_to_list(proplists:get_value(name,Info))), Name = erlang:list_to_binary(erlang:atom_to_list(proplists:get_value(name,Info))), Objects = erlang:list_to_binary(erlang:integer_to_list(proplists:get_value(size,Info))), binary:list_to_bin([<<"=ets:">>,Owner,<<"\nTable: ">>,TableN,<<"\nName: ">>,Name,<<"\nObjects: ">>,Objects,<<"\n">>]). rfc1123_local_date() -> rfc1123_local_date(os:timestamp()).rfc1123_local_date({A,B,C}) -> rfc1123_local_date(calendar:now_to_local_time({A,B,C}));rfc1123_local_date({{YYYY,MM,DD},{Hour,Min,Sec}}) -> DayNumber = calendar:day_of_the_week({YYYY,MM,DD}), lists:flatten( io_lib:format("~s, ~2.2.0w ~3.s ~4.4.0w ~2.2.0w:~2.2.0w:~2.2.0w GMT", [httpd_util:day(DayNumber),DD,httpd_util:month(MM),YYYY,Hour,Min,Sec]));rfc1123_local_date(Epoch) when erlang:is_integer(Epoch) -> rfc1123_local_date(calendar:gregorian_seconds_to_datetime(Epoch+62167219200)). From: vladdu55@REDACTED Date: Thu, 20 Feb 2014 10:30:39 +0100 To: mabrek@REDACTED CC: erlang-questions@REDACTED Subject: Re: [erlang-questions] Creating a diagnostic memory dump of live erlang VM Hi, On Thu, Feb 20, 2014 at 9:26 AM, Anton Lebedevich wrote: Another thing which I missed a lot after converting from java to erlang is a thread dump. It turned out that it's possible to get all stacktraces for all processes (even with function arguments) via erlang:system_info(procs). It returns them as text so it's better to dump it to file immediately: file:write_file("/tmp/procs.txt",erlang:system_info(procs)). Format of these traces is quite interesting (undocumented) the best description I found is in the mailing list http://erlang.org/pipermail/erlang-questions/2012-November/070609.html I might just as well ask the obvious question: why is not this information available even as normal Erlang terms, so that one doesn't need to parse it? When writing a crash dump, it doesn't matter, but if it should be used at runtime it's a pain to parse it... This applies to the other results from system_info/1 that are dumped as text. 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 kenji@REDACTED Fri Feb 21 04:54:51 2014 From: kenji@REDACTED (Kenji Rikitake) Date: Fri, 21 Feb 2014 12:54:51 +0900 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <53057EE1.9010102@gmail.com> References: <530325D2.4090303@erl.io> <6F9CBF02-CE44-487E-84D0-16998E5DCC42@gmail.com> <20140218113641.GA13616@k2r.org> <20140220003111.GA26268@k2r.org> <53057EE1.9010102@gmail.com> Message-ID: <20140221035451.GA76118@k2r.org> Off-topic: some thoughts on BitTorrent: * Indeed the technology is good for replication. It's my fault I didn't mention it. * Many large organizations including my former workplaces prohibit P2P protocols by the security policies, and the reason is understandable once you face what sort of traffic is on the torrents. And that's one of the reasons why I've got an unintentional negative bias against BitTorrent. I think we can agree that we need more mirroring sites of various levels. Kenji Rikitake ++> Michael Truog [2014-02-19 20:04:49 -0800]: > On 02/19/2014 04:31 PM, Kenji Rikitake wrote: > >>> I think depending on GitHub is not good, though. > >> > > >> >I've said it before in another package repo discussion, but I'd like > >> >to second the opinion that making use of a mirror network is crucial. > > +1. CDN has become a must for a usable data replication service. > > > Please try to keep in mind the possibility of using BitTorrent for data replication and raw throughput (Joe Armstrong already mentioned this as a direction). In my mind, BitTorrent /= CDN. From jorgen@REDACTED Fri Feb 21 03:11:38 2014 From: jorgen@REDACTED (Jorgen Skogstad) Date: Fri, 21 Feb 2014 10:11:38 +0800 Subject: [erlang-questions] Re IOS/Android && OMADF && Erlang/JMS tapping into order data stream .. Message-ID: Kindest, Apologies if this is trivial for most of you - known about Erlang for a long time, but not gotten my hands dirty with hands on yet.. but that's about to change now I reckon. ;-) Was wondering whether there were anyone that have done something similar to what I am conceptualizing. Essentially want to take Oracle AIA order streams, and tapping into that data through AIA sensors, which passes order messages through to a foreign JMS provider. Was pondering then having Erlang on the receiving end processing that data in a parallel spawn() like manner given the transient nature of in-bound order data (e.g. process in real time as the order messages are committed), and managing that in-memory, with persistence ... building essentially the data/table structure that I want synchronized through to the mobile application. Hence for this section of the architecture - anyone had any luck doing something like that? Then, once that is done, was wondering whether I could use Erlang on IOS/Android to syncronize the data (automatically) when the device is online. That could be a bit of a challenge given the dynamic IP nature of the device I suspect, but perhaps dynDNS could help, but not thought that through. If that is too complex, then building a device sync service that pulls data from serverside mnesia/couchdb could be another avenue.. .. then likely be the approach of building a Oracle Mobile ADF application, that uses the local sync using something like the strategies outlined here: http://www.ateam-oracle.com/going-mobile-with-adf-implementing-data-caching-and-syncing-for-working-offline/ Guess that means that I could expose the Erland mnesia/couch as RESTful services through yaws, and then sync/update the local sqlLite db at times. Really no specific reason for why OMADF, but where I work we have that for $0, and this would just allow for a very simple and rapid concept cycle across IOS & Android. Any thoughts? --- With respect, J?rgen Skogstad -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdl.web@REDACTED Fri Feb 21 05:36:54 2014 From: sdl.web@REDACTED (Leo Liu) Date: Fri, 21 Feb 2014 12:36:54 +0800 Subject: [erlang-questions] emacs wrapper for rebar References: Message-ID: On 2014-02-17 13:19 +0800, Leo Liu wrote: > Footnotes: > ? https://github.com/leoliu/rebar.el In case someone is interested. Rebar.el can now read directly from eunit.coverdata and provide in buffer coverage annotation. See https://github.com/leoliu/rebar.el/commit/9ba8699ff6310721226b93341e62491ebfd0ee99 for details. Leo From shayan@REDACTED Fri Feb 21 06:34:13 2014 From: shayan@REDACTED (Shayan Pooya) Date: Fri, 21 Feb 2014 00:34:13 -0500 Subject: [erlang-questions] infrequent socket_closed_remotely errors with httpc In-Reply-To: References: Message-ID: On Thu, Feb 20, 2014 at 8:31 AM, Magnus Mueller wrote: > Hello. > > We are struggling with a hard-to-reproduce problem with httpc were we > sometimes encounter `{error,socket_closed_remotely}` when querying our > simple webserver. Sometimes this happens with yaws as well. > > The error happens very infrequently and is thus hard to reproduce. Both > the webserver and httpc run in the same VM (which might be the cause of the > problem). Interestingly, the problem is more likely to occur if the system > is under cpu-heavy load, e.g. when using stress[1]: > > stress --cpu 6 > > Did anybody of you encounter similar problems? We are running out of ideas > and I could not yet come up with a small example to reproduce the issue. > > Magnus > > [1] > https://web.archive.org/web/20130520190152/http://weather.ou.edu/~apw/projects/stress/, the original website seems to be down. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > There was a discussion about this last week ( http://erlang.org/pipermail/erlang-questions/2014-February/077370.html). We had a somehow similar issue in Disco, and we worked around it by switching back to HTTP/1.0. Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kino@REDACTED Fri Feb 21 07:14:25 2014 From: kino@REDACTED (satoshi kinoshita) Date: Fri, 21 Feb 2014 15:14:25 +0900 Subject: [erlang-questions] process_info Message-ID: Hi, I have a question about process_info(). For process <0,477,0> below, heap_size is 6765 words, stack_size is 12 words and memory is 40,149,752 bytes. Erlang doc says 'memory' includes stack, heap and internal structures. In this case, stack + heap is 4*(6765+12)=27,108 bytes. Does this mean most of memory usage(about 40M bytes) are used for "internal structures"? What is "internal structures"??? (I'm still using R11B-5 and I don't know it's specific to R11B-5 or not.) Thanks in advance, Kinoshita ------------------------------------------------------- (hss1@REDACTED)3> process_info(pid(0,477,0)). [{registered_name,mgs_db_mgse}, {current_function,{gen_server,loop,6}}, {initial_call,{proc_lib,init_p,5}}, {status,waiting}, {message_queue_len,0}, {messages,[]}, {links,[<0.436.0>]}, {dictionary,[{'$ancestors',[mgs_db_sup,<0.435.0>]}, {'$initial_call',{gen,init_it, [gen_server, <0.436.0>, <0.436.0>, {local,mgs_db_mgse}, mgs_db_mgse, [60,0,"mgsen-i+up"], []]}}]}, {trap_exit,false}, {error_handler,error_handler}, {priority,normal}, {group_leader,<0.434.0>}, {heap_size,6765}, {stack_size,12}, {reductions,237536590}, {garbage_collection,[{fullsweep_after,65535}]}] (hss1@REDACTED)4> process_info(pid(0,477,0),memory). {memory,40149752} ---http://www.erlang.org/documentation/doc-5.5.5/lib/kernel-2.11.5/doc/html/erlang.html-------------- {heap_size, Size} Size is the heap size of the process in words. {stack_size, Size} Size is the stack size of the process in words. {memory, Size} Size is the size of the process in bytes. This includes call stack, heap and internal structures. -------------- next part -------------- An HTML attachment was scrubbed... URL: From be.dmitry@REDACTED Fri Feb 21 08:40:19 2014 From: be.dmitry@REDACTED (Dmitry Belyaev) Date: Fri, 21 Feb 2014 18:40:19 +1100 Subject: [erlang-questions] emacs wrapper for rebar In-Reply-To: References: Message-ID: <7038c903-9758-4d3d-a92d-39096f7a3b66@email.android.com> Can this be plugged in EDTS? -- Best wishes, Dmitry Belyaev On 21 February 2014 3:36:54 PM AEDT, Leo Liu wrote: >On 2014-02-17 13:19 +0800, Leo Liu wrote: >> Footnotes: >> ? https://github.com/leoliu/rebar.el > >In case someone is interested. Rebar.el can now read directly from >eunit.coverdata and provide in buffer coverage annotation. See >https://github.com/leoliu/rebar.el/commit/9ba8699ff6310721226b93341e62491ebfd0ee99 >for details. > >Leo > >_______________________________________________ >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 Fri Feb 21 09:09:53 2014 From: sdl.web@REDACTED (Leo Liu) Date: Fri, 21 Feb 2014 16:09:53 +0800 Subject: [erlang-questions] emacs wrapper for rebar In-Reply-To: <7038c903-9758-4d3d-a92d-39096f7a3b66@email.android.com> (Dmitry Belyaev's message of "Fri, 21 Feb 2014 18:40:19 +1100") References: <7038c903-9758-4d3d-a92d-39096f7a3b66@email.android.com> Message-ID: On 2014-02-21 15:40 +0800, Dmitry Belyaev wrote: > Can this be plugged in EDTS? Sure. Leo From davidnwelton@REDACTED Fri Feb 21 10:45:26 2014 From: davidnwelton@REDACTED (David Welton) Date: Fri, 21 Feb 2014 10:45:26 +0100 Subject: [erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]] In-Reply-To: <20140221035451.GA76118@k2r.org> References: <530325D2.4090303@erl.io> <6F9CBF02-CE44-487E-84D0-16998E5DCC42@gmail.com> <20140218113641.GA13616@k2r.org> <20140220003111.GA26268@k2r.org> <53057EE1.9010102@gmail.com> <20140221035451.GA76118@k2r.org> Message-ID: Of the things I've used over the years to deal with packages, I think I've been the happiest with dpkg and friends, mostly because of the attention to detail of the package maintainers (not always, but often), and the desire to do things properly (not always, but often). Ruby Gems works ok as a way of packaging up stuff for that environment, technically, but is sometimes undercut by the rapidly moving world of Ruby where people simply pay less attention to compatibility issues as they race forward. So: like many things in the world of programming, it is both a technical and a social problem. The technical solution does not have to be perfect, but it is important to create a good culture around what gets packaged up and how. Rebar works ok, but were Erlang ever to get popular, I'm not sure github would continue to appreciate it. Ruby gems' downloads used to be hosted there, until github got tired of it and asked that they be moved elsewhere. One important question is whether people want a model with a bunch of shared, centralized installations of software (this is what Debian aims for with their packaging system), or whether each project that gets built includes everything it needs in its own little world. I suspect the latter is more suited to Erlang in any case. -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From torben.hoffmann@REDACTED Fri Feb 21 10:22:53 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Fri, 21 Feb 2014 10:22:53 +0100 Subject: [erlang-questions] How to Name Concurrency Patterns In-Reply-To: References: Message-ID: Hi, We (Jesper and me) are actually working on describing common concurrency patterns for Erlang. Still WIP, but I have attached one of them - Tuple Space Storage. We are using Object-Process Methodology for the diagrams - it is the only thing that I have found that allows me to describe Erlang architecture without throwing up. Don't even try to mention UML here! Others on the backlog: * Supervisor - you would be surprised how many moving parts this one has! * Manager/Worker - both a simple and a more complex one. * Pool as limited resource - more or less poolboy. * Pool as (cache|time limited resource|round-robin|best-of-2) - a number of those will be added later . The idea is to document some of the common concurrency patterns in Erlang and explain how error handling is addressed by the pattern. Main audience is people trying to learn what is going on. For most of you super Erlangers here it will be trivial information, but when one is trying to push Erlang into big companies it is necessary to have material like this that can explain what is going on in Erlang. As you can see from the attachment we are trying to follow a description style similar to what the OO world is using. But we are not aiming to translate all the patterns from the OO world - we want to document good concurrency patterns in Erlang. If people are interested in helping out I can open up the repo we have for this. Cheers, Torben -------------- next part -------------- A non-text attachment was scrubbed... Name: tuple_space_storage.pdf Type: application/pdf Size: 172327 bytes Desc: not available URL: -------------- next part -------------- erlang@REDACTED writes: > Hello, I'm giving a course in distributed and parallel programming in > Erlang ... > > Next week I'll be talking about common concurrency patterns, I was > talking with the course adviser, and I rattled off the names of a few > concurrency patterns that were well-known and easy to explain. I said > I'll do PUB-SUB, pipeline, map-reduce, parallel map, and so on. > > At this stage the course adviser said that a) things like PUB-SUB > would not be familiar to the students and that b) It would take more > than 5-10 minutes to explain PUB_SUB. > > At this stage I thought "pity these patterns don't have well-known > names". > > What I'd like is to make a catalog of "well-known" concurrency > patterns. I'd like to name them, and describe them informally, and > give the example code in Erlang. > > For example, here's how I might describe PUB-SUB. > > == PUB-SUB > > - There are a number of named channels > - You can post messages to a channel ie Publish the message (the PUB) > - You can subscribe to a channel (The SUB) > - If you are currently subscribed to a channel you will be sent all > messages > sent to the channel. > > A rudimentary version of this is about 25 lines of Erlang. A full > version with load balancing, removing bottlenecks etc. would be a lot > longer, but that's not the point. The basic concurrent structure can > be explained in a few lines and named. > > > Pipeline is another example: The output of the first process is the > input to the next process and so on... > > Now I start having problems. > > Suppose I want to generalize a regular map. > > To be precise. Suppose map(F, L) means [F(I) || I <- L] > > pmap(F, L) is parallel map (easy) all the F(I)'s are computed concurrently. > > pmap(F, L, Max) behaves like map(F,L) with at most Max F(I)'s computed > concurrently. > > What should this be called? "Pool of workers" > > There seem to be things with well-known names "Load-balancer" "map-reduce" > etc. > > Then there are things that we know of but that are not named. For > example my DNS resolver has two DNS names DNS1 and DNS2. If DNS1 is > broken the resolver tries DNS2 - what is concurrency pattern called > (Pool of responders) or what? > > The other day I suggested that for fault tolerance it was much easier > to let the client go to multiple machines rather than use an expensive > load balancer and fail-over system on the server - but there was no > convenient name to capture this idea. > > There sees to be no accepted terminology here - so I'd appreciate any > suggestions you have as to the names of common currency patterns that > you use together with definitions of what the names mean. > > Cheers > > /Joe > _______________________________________________ > 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 sverker.eriksson@REDACTED Fri Feb 21 12:00:11 2014 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Fri, 21 Feb 2014 12:00:11 +0100 Subject: [erlang-questions] process_info In-Reply-To: References: Message-ID: <530731BB.3070304@erix.ericsson.se> A process has two heaps, one "old" heap with long lived data and a "new" heap with more recently created data. 'heap_size' shows only the size of the new heap. Newer releases (my git repo goes back to R13B03) contain a 'total_heap_size' that also include the old heap. /Sverker, Erlang/OTP On 02/21/2014 07:14 AM, satoshi kinoshita wrote: > Hi, > > I have a question about process_info(). > > For process <0,477,0> below, > heap_size is 6765 words, > stack_size is 12 words and > memory is 40,149,752 bytes. > > Erlang doc says 'memory' includes stack, heap and internal structures. > In this case, stack + heap is 4*(6765+12)=27,108 bytes. > > Does this mean most of memory usage(about 40M bytes) are used > for "internal structures"? > > What is "internal structures"??? > > (I'm still using R11B-5 and I don't know it's specific to R11B-5 or not.) > > > Thanks in advance, > Kinoshita > > ------------------------------------------------------- > (hss1@REDACTED)3> process_info(pid(0,477,0)). > [{registered_name,mgs_db_mgse}, > {current_function,{gen_server,loop,6}}, > {initial_call,{proc_lib,init_p,5}}, > {status,waiting}, > {message_queue_len,0}, > {messages,[]}, > {links,[<0.436.0>]}, > {dictionary,[{'$ancestors',[mgs_db_sup,<0.435.0>]}, > {'$initial_call',{gen,init_it, > [gen_server, > <0.436.0>, > <0.436.0>, > {local,mgs_db_mgse}, > mgs_db_mgse, > [60,0,"mgsen-i+up"], > []]}}]}, > {trap_exit,false}, > {error_handler,error_handler}, > {priority,normal}, > {group_leader,<0.434.0>}, > {heap_size,6765}, > {stack_size,12}, > {reductions,237536590}, > {garbage_collection,[{fullsweep_after,65535}]}] > (hss1@REDACTED)4> process_info(pid(0,477,0),memory). > {memory,40149752} > > ---http://www.erlang.org/documentation/doc-5.5.5/lib/kernel-2.11.5/doc/html/erlang.html-------------- > > {heap_size, Size} > Size is the heap size of the process in words. > > {stack_size, Size} > Size is the stack size of the process in words. > > {memory, Size} > Size is the size of the process in bytes. This includes call > stack, heap and internal structures. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From jean.parpaillon@REDACTED Fri Feb 21 12:03:09 2014 From: jean.parpaillon@REDACTED (Jean Parpaillon) Date: Fri, 21 Feb 2014 12:03:09 +0100 Subject: [erlang-questions] C linkedin driver memory management Message-ID: <1392980589.31555.13.camel@malo.home> Hi all, I'm writing a C driver using the generic linked-in driver : https://github.com/squidfunk/generic-linked-in-driver/ This driver is interacting with GObject library, where objects are allocated and freed with custom functions (for instance g_error_free for GError objects). I am wondering what is the difference of using the following functions: - GObject free functions like g_error_free ? - erl_free ? - driver_free ? - glibc free ? Thanks a lot, -- Jean Parpaillon Open Source Consultant Phone: +33 6 30 10 92 86 im: jean.parpaillon@REDACTED skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en From ponmuthu.m@REDACTED Fri Feb 21 12:05:53 2014 From: ponmuthu.m@REDACTED (PONMUTHU.M) Date: Fri, 21 Feb 2014 03:05:53 -0800 (PST) Subject: [erlang-questions] help me to read proper input from commandline erl Message-ID: <1392980753756-4655367.post@n4.nabble.com> hi all, while get runtime command prompt variable via init:get_argument(name). i want to get a list . but in that " " are added while getting & assign to a varaible % erl -mylist [1,2,3,4] > {ok,[[List|_]|_]} = init:get_argument(mylist). {ok,[["[1,2,3,4]"]]} >List. "[1,2,3,4]" but expecting O/p as >List. [1,2,3,4] please help , because of this double qutoes am not able to do Head & Tail . -- View this message in context: http://erlang.2086793.n4.nabble.com/help-me-to-read-proper-input-from-commandline-erl-tp4655367.html Sent from the Erlang Questions mailing list archive at Nabble.com. From adg@REDACTED Fri Feb 21 12:46:49 2014 From: adg@REDACTED (Alfonso De Gregorio) Date: Fri, 21 Feb 2014 11:46:49 +0000 Subject: [erlang-questions] How to Name Concurrency Patterns In-Reply-To: References: Message-ID: On Fri, Feb 21, 2014 at 9:22 AM, Torben Hoffmann wrote: ... > We (Jesper and me) are actually working on describing common concurrency patterns for > Erlang. "Erlang Concurrency Patterns" sounds like a great topic for a book - and maybe it sounds also like a title. -- alfonso From bengt.kleberg@REDACTED Fri Feb 21 12:48:58 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Fri, 21 Feb 2014 12:48:58 +0100 Subject: [erlang-questions] help me to read proper input from commandline erl In-Reply-To: <1392980753756-4655367.post@n4.nabble.com> References: <1392980753756-4655367.post@n4.nabble.com> Message-ID: <1392983339.4862.7.camel@sekic1152.release> Greetings, What is the command line? (Ex: erl -mylist 1 2 3 4, or erl -mylist "1,2,3,4" or ?). bengt On Fri, 2014-02-21 at 03:05 -0800, PONMUTHU.M wrote: > hi all, > > while get runtime command prompt variable via init:get_argument(name). > > > i want to get a list . but in that " " are added while getting & assign > to a varaible > > > % erl -mylist [1,2,3,4] > > > {ok,[[List|_]|_]} = init:get_argument(mylist). > {ok,[["[1,2,3,4]"]]} > >List. > "[1,2,3,4]" > > > > but expecting O/p as > > >List. > [1,2,3,4] > > > please help , because of this double qutoes am not able to do Head & Tail . > > > > > -- > View this message in context: http://erlang.2086793.n4.nabble.com/help-me-to-read-proper-input-from-commandline-erl-tp4655367.html > Sent from the Erlang Questions mailing list archive at Nabble.com. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From egil@REDACTED Fri Feb 21 13:27:16 2014 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Fri, 21 Feb 2014 13:27:16 +0100 Subject: [erlang-questions] process_info In-Reply-To: <530731BB.3070304@erix.ericsson.se> References: <530731BB.3070304@erix.ericsson.se> Message-ID: <53074624.2040302@erlang.org> I want to stress that: NO, we don't use 40 MB for internal structures. By internal structure size we mean the size of the C struct for implementing the process (in 17.0-rc1 this is 792 bytes). In erlang:process_info(Pid, memory) we also include the size all heap-fragments, typically messages received that are not yet in any of the two "real" heaps. // Bj?rn-Egil, Erlang/OTP On 2014-02-21 12:00, Sverker Eriksson wrote: > A process has two heaps, one "old" heap with long lived data and a > "new" heap with more recently created data. > > 'heap_size' shows only the size of the new heap. > Newer releases (my git repo goes back to R13B03) contain > a 'total_heap_size' that also include the old heap. > > /Sverker, Erlang/OTP > > > On 02/21/2014 07:14 AM, satoshi kinoshita wrote: >> Hi, >> >> I have a question about process_info(). >> >> For process <0,477,0> below, >> heap_size is 6765 words, >> stack_size is 12 words and >> memory is 40,149,752 bytes. >> >> Erlang doc says 'memory' includes stack, heap and internal structures. >> In this case, stack + heap is 4*(6765+12)=27,108 bytes. >> >> Does this mean most of memory usage(about 40M bytes) are used >> for "internal structures"? >> >> What is "internal structures"??? >> >> (I'm still using R11B-5 and I don't know it's specific to R11B-5 or not.) >> >> >> Thanks in advance, >> Kinoshita >> >> ------------------------------------------------------- >> (hss1@REDACTED)3> process_info(pid(0,477,0)). >> [{registered_name,mgs_db_mgse}, >> {current_function,{gen_server,loop,6}}, >> {initial_call,{proc_lib,init_p,5}}, >> {status,waiting}, >> {message_queue_len,0}, >> {messages,[]}, >> {links,[<0.436.0>]}, >> {dictionary,[{'$ancestors',[mgs_db_sup,<0.435.0>]}, >> {'$initial_call',{gen,init_it, >> [gen_server, >> <0.436.0>, >> <0.436.0>, >> {local,mgs_db_mgse}, >> mgs_db_mgse, >> [60,0,"mgsen-i+up"], >> []]}}]}, >> {trap_exit,false}, >> {error_handler,error_handler}, >> {priority,normal}, >> {group_leader,<0.434.0>}, >> {heap_size,6765}, >> {stack_size,12}, >> {reductions,237536590}, >> {garbage_collection,[{fullsweep_after,65535}]}] >> (hss1@REDACTED)4> process_info(pid(0,477,0),memory). >> {memory,40149752} >> >> ---http://www.erlang.org/documentation/doc-5.5.5/lib/kernel-2.11.5/doc/html/erlang.html-------------- >> >> {heap_size, Size} >> Size is the heap size of the process in words. >> >> {stack_size, Size} >> Size is the stack size of the process in words. >> >> {memory, Size} >> Size is the size of the process in bytes. This includes call >> stack, heap and internal structures. >> >> >> >> _______________________________________________ >> 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 vladdu55@REDACTED Fri Feb 21 14:05:21 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 21 Feb 2014 14:05:21 +0100 Subject: [erlang-questions] v17 unicode support Message-ID: Hi! I'm not sure if I misunderstood something or if there is a problem in 17.0-rc1, but starting a shell normally gives Erlang/OTP 17 [RELEASE CANDIDATE 1] [erts-6.0] [smp:4:4] [async-threads:10] Eshell V6.0 (abort with ^G) 1> "?". [518] 2> erl_scan:string("\"?\""). {ok,[{string,1,[518]}],1} 3> lists:keyfind(encoding, 1, io:getopts()). {encoding,unicode} 4> $?. 518 while starting with "+pc unicode" gives the expected (for me) result. Erlang/OTP 17 [RELEASE CANDIDATE 1] [erts-6.0] [smp:4:4] [async-threads:10] Eshell V6.0 (abort with ^G) 1> "?". "?" 2> erl_scan:string("\"?\""). {ok,[{string,1,"?"}],1} 3> 3> lists:keyfind(encoding, 1, io:getopts()). {encoding,unicode} 4> $?. 518 Isn't 17.0 supposed to have the unicode support as default even in this context? regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattevans123@REDACTED Fri Feb 21 15:41:50 2014 From: mattevans123@REDACTED (Matthew Evans) Date: Fri, 21 Feb 2014 09:41:50 -0500 Subject: [erlang-questions] help me to read proper input from commandline erl In-Reply-To: <1392980753756-4655367.post@n4.nabble.com> References: <1392980753756-4655367.post@n4.nabble.com> Message-ID: Not sure if there's another way... List = "[1,2,3,4]". {ok,T,_} = erl_scan:string(String++"."). {ok,A} = erl_parse:parse_exprs(T). {value,Value,_} = erl_eval:exprs(A, erl_eval:new_bindings()). Value.[1,2,3,4] > Date: Fri, 21 Feb 2014 03:05:53 -0800 > From: ponmuthu.m@REDACTED > To: erlang-questions@REDACTED > Subject: [erlang-questions] help me to read proper input from commandline erl > > hi all, > > while get runtime command prompt variable via init:get_argument(name). > > > i want to get a list . but in that " " are added while getting & assign > to a varaible > > > % erl -mylist [1,2,3,4] > > > {ok,[[List|_]|_]} = init:get_argument(mylist). > {ok,[["[1,2,3,4]"]]} > >List. > "[1,2,3,4]" > > > > but expecting O/p as > > >List. > [1,2,3,4] > > > please help , because of this double qutoes am not able to do Head & Tail . > > > > > -- > View this message in context: http://erlang.2086793.n4.nabble.com/help-me-to-read-proper-input-from-commandline-erl-tp4655367.html > Sent from the Erlang Questions mailing list archive at Nabble.com. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger@REDACTED Fri Feb 21 17:14:07 2014 From: roger@REDACTED (Roger Lipscombe) Date: Fri, 21 Feb 2014 16:14:07 +0000 Subject: [erlang-questions] Decoding certificates using public_key:pkix_decode_cert/2 (and a bug in public_key_SUITE?) Message-ID: I'm attempting to verify the CN of a certificate, and I can't find any examples of how to do it. I think I've figured it out, and I'd like confirmation that I'm doing it right. Also, if I _am_ doing it right, I think I've found a bug in public_key_SUITE in the OTP sources, or I've found a mistake in the documentation. So, starting with a raw, DER-encoded certificate (I'm using the one from incorrect_countryname_pkix_cert/0, in otp/lib/public_key/test/public_key_SUITE.erl, if you want to follow along)... 1> rr(public_key). 2> RawCert = <<48, 130, 5, 186, ...>>. 3> OTPCert = public_key:pkix_decode_cert(RawCert, otp). 4> Subj = OTPCert#'OTPCertificate'.tbsCertificate#'OTPTBSCertificate'.subject. {rdnSequence,[[#'AttributeTypeAndValue'{type = {2,5,4,6}, value = "US"}], [#'AttributeTypeAndValue'{type = {2,5,4,8}, value = {utf8String,<<"AZ">>}}], [#'AttributeTypeAndValue'{type = {2,5,4,7}, value = {utf8String,<<"Scottsdale">>}}], [#'AttributeTypeAndValue'{type = {2,5,4,10}, value = {utf8String,<<"Special Domain Services, Inc.">>}}], [#'AttributeTypeAndValue'{type = {2,5,4,3}, value = {utf8String,<<"*.login.secureserver.net">>}}]]} Note that we've got a list of lists: {rdnSequence, [[A1], [A2], [A3]]}. This doesn't appear to agree with the documentation at http://erlang.org/doc/apps/public_key/cert_records.html, where (if I'm reading it correctly), we should be seeing {rdnSequence, [A1, A2, A3]}. Now, this ought to have been caught by the tests in public_key_SUITE.erl, because do_check_countryname/1 expects [A1, A2, A3], except that it silently passes if it fails to match ?'id-at-countryName'. And it does fail to match, because it never correctly matches _any_ of the items in the list. So, my questions: 0. (the most important) how do I get the CN out of a certificate? 1. Should rdnSequence be as described in the documentation (a list of #'AttributeTypeAndValue' records), or should it be as it is (a list of lists of #'AttributeTypeAndValue' records)? If the second, are they guaranteed to be single-item lists, or is there something more complex happening here? 2. Is my understanding correct? 3. Is there a bug in the test? 4. Or is there a bug in pkix_cert_decode? >From my reading of the ASN.1 specification of http://www.in2eps.com/fo-pkix/tk-fo-pkix-asn1.html#naming -- and I'm not very good at reading ASN.1 specs, to be honest -- it looks like the code's correct(*), but the documentation isn't. (*) It looks like a Name comprises a sequence of RelativeDistinguishedName; each of the RelativeDistinguishedName items in the example certificate is a singleton set. Or am I barking up completely the wrong tree here? Regards, Roger. From andrew@REDACTED Fri Feb 21 17:30:34 2014 From: andrew@REDACTED (Andrew Thompson) Date: Fri, 21 Feb 2014 11:30:34 -0500 Subject: [erlang-questions] Decoding certificates using public_key:pkix_decode_cert/2 (and a bug in public_key_SUITE?) In-Reply-To: References: Message-ID: <20140221163034.GC24036@hijacked.us> On Fri, Feb 21, 2014 at 04:14:07PM +0000, Roger Lipscombe wrote: > 0. (the most important) how do I get the CN out of a certificate? This is how I do it (and by extension how Riak does it): https://github.com/Vagabond/otp/compare/erlang:maint...adt-crl-fixes#diff-d6743cc877f70398dfa7d11d25033c20R502 I also was unable to find a better way to do it. Andrew From gordon@REDACTED Fri Feb 21 17:49:33 2014 From: gordon@REDACTED (Gordon Guthrie) Date: Fri, 21 Feb 2014 16:49:33 +0000 Subject: [erlang-questions] Why isn't Erlang more popular? Message-ID: Instead of us discussing it in private, I thought we should ask people who DONT use Erlang the same question that people have been knawing on on the list. So I have done as Ask HN on hacker news. Due to the ring-voting detection feature you will need to track it down yourself I won't provide a link Gordon -- --- Gordon Guthrie CEO vixo.com @gordonguthrie +44 (0) 7776 251669 (in Bonnie Scotland!) vixo is made in Scotland from electrons -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierrefenoll@REDACTED Fri Feb 21 17:50:34 2014 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Fri, 21 Feb 2014 17:50:34 +0100 Subject: [erlang-questions] Why isn't Erlang more popular? In-Reply-To: References: Message-ID: If I may, I collected these some time ago: https://github.com/fenollp/kju/blob/master/criticisms.md Cheers, -- Pierre Fenoll On 21 February 2014 17:49, Gordon Guthrie wrote: > Instead of us discussing it in private, I thought we should ask people who > DONT use Erlang the same question that people have been knawing on on the > list. > > So I have done as Ask HN on hacker news. > > Due to the ring-voting detection feature you will need to track it down > yourself I won't provide a link > > Gordon > > -- > --- > Gordon Guthrie > CEO vixo.com > @gordonguthrie > +44 (0) 7776 251669 (in Bonnie Scotland!) > > vixo is made in Scotland from electrons > > _______________________________________________ > 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 Feb 21 17:52:38 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 21 Feb 2014 17:52:38 +0100 Subject: [erlang-questions] Why isn't Erlang more popular? In-Reply-To: References: Message-ID: Seriously? You think HN is a good example of a community? -- Anthony Ramine Le 21 f?vr. 2014 ? 17:49, Gordon Guthrie a ?crit : > So I have done as Ask HN on hacker news. From tristan.sloughter@REDACTED Fri Feb 21 17:58:27 2014 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Fri, 21 Feb 2014 08:58:27 -0800 Subject: [erlang-questions] Why isn't Erlang more popular? In-Reply-To: References: Message-ID: <1393001907.4791.86205549.0E4266CE@webmail.messagingengine.com> The best. On Fri, Feb 21, 2014, at 08:52 AM, Anthony Ramine wrote: > Seriously? You think HN is a good example of a community? > > -- > Anthony Ramine > > Le 21 f?vr. 2014 ? 17:49, Gordon Guthrie a ?crit : > > > So I have done as Ask HN on hacker news. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Tristan Sloughter tristan.sloughter@REDACTED From n.oxyde@REDACTED Fri Feb 21 18:02:29 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 21 Feb 2014 18:02:29 +0100 Subject: [erlang-questions] Why isn't Erlang more popular? In-Reply-To: <1393001907.4791.86205549.0E4266CE@webmail.messagingengine.com> References: <1393001907.4791.86205549.0E4266CE@webmail.messagingengine.com> Message-ID: I would rather ask an union of unpasteurized cheese makers. Their opinion is as relevant and I would be able to eat delicious things while listening. -- Anthony Ramine Le 21 f?vr. 2014 ? 17:58, Tristan Sloughter a ?crit : > The best. From jesper.louis.andersen@REDACTED Fri Feb 21 18:12:54 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 21 Feb 2014 18:12:54 +0100 Subject: [erlang-questions] Why isn't Erlang more popular? In-Reply-To: References: Message-ID: I think a lot of these points are outright misguided. So we probably have some explaining to do. Others are really hard to avoid if you want compatibility backwards. I'd rather not see Haskell used as a gown standard because it is awfully bad in its infrastructure. On Feb 21, 2014 5:51 PM, "Pierre Fenoll" wrote: > If I may, I collected these some time ago: > https://github.com/fenollp/kju/blob/master/criticisms.md > > > Cheers, > -- > Pierre Fenoll > > > > On 21 February 2014 17:49, Gordon Guthrie wrote: > >> Instead of us discussing it in private, I thought we should ask people >> who DONT use Erlang the same question that people have been knawing on on >> the list. >> >> So I have done as Ask HN on hacker news. >> >> Due to the ring-voting detection feature you will need to track it down >> yourself I won't provide a link >> >> Gordon >> >> -- >> --- >> Gordon Guthrie >> CEO vixo.com >> @gordonguthrie >> +44 (0) 7776 251669 (in Bonnie Scotland!) >> >> vixo is made in Scotland from electrons >> >> _______________________________________________ >> 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 fly@REDACTED Fri Feb 21 18:14:43 2014 From: fly@REDACTED (Fred Youhanaie) Date: Fri, 21 Feb 2014 17:14:43 +0000 Subject: [erlang-questions] help me to read proper input from commandline erl In-Reply-To: References: <1392980753756-4655367.post@n4.nabble.com> Message-ID: <53078983.2070900@anydata.co.uk> A shorter alternative, though only by just one step, is to use erl_parse:parse_term(T) instead of parse_exprs and erl_eval:exprs. So the steps after the "erl -mylist [1,2,3]." command is (note the dot at the end of the argument) {ok, [[Arg]]} = init:get_argument(mylist). {ok, Tokens, _} = erl_scan:string(Arg). {ok, List} = erl_parse:parse_term(Tokens). See example in http://www.erlang.org/faq/how_do_i.html#id53476 Cheers Fred On 21/02/14 14:41, Matthew Evans wrote: > Not sure if there's another way... > List = "[1,2,3,4]". > {ok,T,_} = erl_scan:string(String++"."). > {ok,A} = erl_parse:parse_exprs(T). > {value,Value,_} = erl_eval:exprs(A, erl_eval:new_bindings()). > Value.[1,2,3,4] > >> Date: Fri, 21 Feb 2014 03:05:53 -0800 >> From: ponmuthu.m@REDACTED >> To: erlang-questions@REDACTED >> Subject: [erlang-questions] help me to read proper input from commandline erl >> >> hi all, >> >> while get runtime command prompt variable via init:get_argument(name). >> >> >> i want to get a list . but in that " " are added while getting & assign >> to a varaible >> >> >> % erl -mylist [1,2,3,4] >> >>> {ok,[[List|_]|_]} = init:get_argument(mylist). >> {ok,[["[1,2,3,4]"]]} >>> List. >> "[1,2,3,4]" >> >> >> >> but expecting O/p as >> >>> List. >> [1,2,3,4] >> >> >> please help , because of this double qutoes am not able to do Head & Tail . >> >> >> >> >> -- >> View this message in context: http://erlang.2086793.n4.nabble.com/help-me-to-read-proper-input-from-commandline-erl-tp4655367.html >> Sent from the Erlang Questions mailing list archive at Nabble.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 dch@REDACTED Fri Feb 21 18:39:10 2014 From: dch@REDACTED (Dave Cottlehuber) Date: Fri, 21 Feb 2014 18:39:10 +0100 Subject: [erlang-questions] help me to read proper input from commandline erl In-Reply-To: <53078983.2070900@anydata.co.uk> References: <1392980753756-4655367.post@n4.nabble.com> <53078983.2070900@anydata.co.uk> Message-ID: Depending how complicated your requirements are, consider using https://github.com/jcomellas/getopt I'm sure there are other libraries out there, this is the only one I had bookmarked. On 21 February 2014 18:14, Fred Youhanaie wrote: > A shorter alternative, though only by just one step, is to use > erl_parse:parse_term(T) instead of parse_exprs and erl_eval:exprs. > > So the steps after the "erl -mylist [1,2,3]." command is > (note the dot at the end of the argument) > > {ok, [[Arg]]} = init:get_argument(mylist). > {ok, Tokens, _} = erl_scan:string(Arg). > {ok, List} = erl_parse:parse_term(Tokens). > > See example in http://www.erlang.org/faq/how_do_i.html#id53476 > > Cheers > Fred > > > > On 21/02/14 14:41, Matthew Evans wrote: >> >> Not sure if there's another way... >> List = "[1,2,3,4]". >> {ok,T,_} = erl_scan:string(String++"."). >> {ok,A} = erl_parse:parse_exprs(T). >> {value,Value,_} = erl_eval:exprs(A, erl_eval:new_bindings()). >> Value.[1,2,3,4] >> >>> Date: Fri, 21 Feb 2014 03:05:53 -0800 >>> From: ponmuthu.m@REDACTED >>> To: erlang-questions@REDACTED >>> Subject: [erlang-questions] help me to read proper input from commandline >>> erl >>> >>> hi all, >>> >>> while get runtime command prompt variable via >>> init:get_argument(name). >>> >>> >>> i want to get a list . but in that " " are added while getting & >>> assign >>> to a varaible >>> >>> >>> % erl -mylist [1,2,3,4] >>> >>>> {ok,[[List|_]|_]} = init:get_argument(mylist). >>> >>> {ok,[["[1,2,3,4]"]]} >>>> >>>> List. >>> >>> "[1,2,3,4]" >>> >>> >>> >>> but expecting O/p as >>> >>>> List. >>> >>> [1,2,3,4] >>> >>> >>> please help , because of this double qutoes am not able to do Head & Tail >>> . >>> >>> >>> >>> >>> -- >>> View this message in context: >>> http://erlang.2086793.n4.nabble.com/help-me-to-read-proper-input-from-commandline-erl-tp4655367.html >>> Sent from the Erlang Questions mailing list archive at Nabble.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 >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From sevenjp@REDACTED Fri Feb 21 19:07:56 2014 From: sevenjp@REDACTED (=?UTF-8?Q?Jo=C3=A3o_Neves?=) Date: Fri, 21 Feb 2014 19:07:56 +0100 Subject: [erlang-questions] help me to read proper input from commandline erl In-Reply-To: References: <1392980753756-4655367.post@n4.nabble.com> <53078983.2070900@anydata.co.uk> Message-ID: Docopt-erl is also pretty nice since it lets you build your command line arguments by documenting them properly. :) https://github.com/plux/docopt-erl -- Jo?o Neves 2014-02-21 18:39 GMT+01:00 Dave Cottlehuber : > Depending how complicated your requirements are, consider using > > https://github.com/jcomellas/getopt > > I'm sure there are other libraries out there, this is the only one I > had bookmarked. > > On 21 February 2014 18:14, Fred Youhanaie wrote: > > A shorter alternative, though only by just one step, is to use > > erl_parse:parse_term(T) instead of parse_exprs and erl_eval:exprs. > > > > So the steps after the "erl -mylist [1,2,3]." command is > > (note the dot at the end of the argument) > > > > {ok, [[Arg]]} = init:get_argument(mylist). > > {ok, Tokens, _} = erl_scan:string(Arg). > > {ok, List} = erl_parse:parse_term(Tokens). > > > > See example in http://www.erlang.org/faq/how_do_i.html#id53476 > > > > Cheers > > Fred > > > > > > > > On 21/02/14 14:41, Matthew Evans wrote: > >> > >> Not sure if there's another way... > >> List = "[1,2,3,4]". > >> {ok,T,_} = erl_scan:string(String++"."). > >> {ok,A} = erl_parse:parse_exprs(T). > >> {value,Value,_} = erl_eval:exprs(A, erl_eval:new_bindings()). > >> Value.[1,2,3,4] > >> > >>> Date: Fri, 21 Feb 2014 03:05:53 -0800 > >>> From: ponmuthu.m@REDACTED > >>> To: erlang-questions@REDACTED > >>> Subject: [erlang-questions] help me to read proper input from > commandline > >>> erl > >>> > >>> hi all, > >>> > >>> while get runtime command prompt variable via > >>> init:get_argument(name). > >>> > >>> > >>> i want to get a list . but in that " " are added while getting & > >>> assign > >>> to a varaible > >>> > >>> > >>> % erl -mylist [1,2,3,4] > >>> > >>>> {ok,[[List|_]|_]} = init:get_argument(mylist). > >>> > >>> {ok,[["[1,2,3,4]"]]} > >>>> > >>>> List. > >>> > >>> "[1,2,3,4]" > >>> > >>> > >>> > >>> but expecting O/p as > >>> > >>>> List. > >>> > >>> [1,2,3,4] > >>> > >>> > >>> please help , because of this double qutoes am not able to do Head & > Tail > >>> . > >>> > >>> > >>> > >>> > >>> -- > >>> View this message in context: > >>> > http://erlang.2086793.n4.nabble.com/help-me-to-read-proper-input-from-commandline-erl-tp4655367.html > >>> Sent from the Erlang Questions mailing list archive at Nabble.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 > >> > > _______________________________________________ > > 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 wallentin.dahlberg@REDACTED Fri Feb 21 19:12:16 2014 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Fri, 21 Feb 2014 19:12:16 +0100 Subject: [erlang-questions] v17 unicode support In-Reply-To: References: Message-ID: I don't think that is desired. Start erlang with +pc unicode do a lists:seq(300,10000) .. // Bj?rn-Egil 2014-02-21 14:05 GMT+01:00 Vlad Dumitrescu : > Hi! > > I'm not sure if I misunderstood something or if there is a problem in > 17.0-rc1, but starting a shell normally gives > > Erlang/OTP 17 [RELEASE CANDIDATE 1] [erts-6.0] [smp:4:4] [async-threads:10] > Eshell V6.0 (abort with ^G) > 1> "?". > [518] > 2> erl_scan:string("\"?\""). > {ok,[{string,1,[518]}],1} > 3> lists:keyfind(encoding, 1, io:getopts()). > {encoding,unicode} > 4> $?. > 518 > > while starting with "+pc unicode" gives the expected (for me) result. > > Erlang/OTP 17 [RELEASE CANDIDATE 1] [erts-6.0] [smp:4:4] [async-threads:10] > Eshell V6.0 (abort with ^G) > 1> "?". > "?" > 2> erl_scan:string("\"?\""). > {ok,[{string,1,"?"}],1} > 3> > 3> lists:keyfind(encoding, 1, io:getopts()). > {encoding,unicode} > 4> $?. > 518 > > Isn't 17.0 supposed to have the unicode support as default even in this > context? > > 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 jay@REDACTED Fri Feb 21 20:07:11 2014 From: jay@REDACTED (Jay Nelson) Date: Fri, 21 Feb 2014 11:07:11 -0800 Subject: [erlang-questions] How to Name Concurrency Patterns Message-ID: I don?t have a good handle on naming, but I am giving a talk at Erlang Factory SF on concurrency patterns using ets tables as the implementation mechanism. The library is now called ?Erlang Patterns of Concurrency? and resides at https://github.com/duomark/epocxy (was recently renamed, so there may be references to dk_cxy around but they now resolve to epocxy) The documentation is a bit lacking and will be updated Real Soon Now, but it is a library you can include into an OTP application that provides convenient multicore data and control structures. Right now these include: 1) ets_buffers: Ring, FIFO and LIFO implemented as an ordered ets array 2) concurrency control: Spawn processes freely up to a limit, use inline execution as back pressure 3) generational caching: Two ets tables, no per object expiration, delete oldest generation There are plans for synchronization barriers and concurrent task queues. Comments are welcome, as are attendees at my talk which is scheduled first thing after the keynote on the first day. ?Eliminating Single Process Bottlenecks with ETS Concurrency Patterns" http://www.erlang-factory.com/conference/show/conference-6/home/#programme I have a strong bias against the misuse of worker pools* (find me and we can discuss over drinks at EF!) when concurrency control is what is desired. We have found that using ets for concurrent access allows a clean method for specifying architectural data structures and functional organization and have seen great speed ups without catastrophic failure under heavy loads. jay ??? *Worker pools should be used for limited resources with long init and fast transaction semantics, and not for other patterns. The message queue backup and catastrophic failure under overload, coupled with restart storms are devastating and should be avoided if possible. Concurrent task queues allow the number of workers to vary and provide a better view of pending and in process work load, plus they have the advantage of realtime adaptive distribution of work as opposed to the global assignment of work at the time of task arrival imposed by pools. Using a task queue also affords the option of using hard real time deadlines as an alternative to avoid server collapse, without any structural changes to the system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Fri Feb 21 20:34:21 2014 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Fri, 21 Feb 2014 20:34:21 +0100 Subject: [erlang-questions] beta release of merl - metaprogramming in Erlang In-Reply-To: <1391522696.42483.YahooMailNeo@web140106.mail.bf1.yahoo.com> References: <52F0D50C.6080700@gmail.com> <1391522696.42483.YahooMailNeo@web140106.mail.bf1.yahoo.com> Message-ID: <5307AA3D.8040206@gmail.com> I got some feedback from a happy user (hi Andreas!) who gave me permission to post this example of his to the list, to show off the improvements in readability when using merl compared to using the erl_syntax API directly: https://github.com/erlydtl/erlydtl/commit/577a665a80f9c211fee6a91523fc879e6b966dcc#diff-08c5c8e12b9ecb678434d3a9faa73630R1546 /Richard > On Tuesday, February 4, 2014 12:55 PM, Richard Carlsson > wrote: > > So, I finally got around to releasing Merl to Github, under an Apache 2 > license: > https://github.com/richcarl/merl > > I talked about it two years ago in San Francisco: > http://www.youtube.com/watch?v=RA7QcMNBKfg > > Slides here: > > http://www.erlang-factory.com/conference/ErlangUserConference2012/speakers/RichardCarlsson > > See the edoc overview for documentation, and the examples/ subdirectory > for example code. > > Currently missing: I'd like to have a good API for working with a > "module" as an ADT, easily adding and removing definitions and querying > the current state, and also reading an existing module from file or as > an AST in a parse transform. The file "examples/merl_build.erl" is a > start, but I don't have time right now to work more on that. Useful > sources of inspiration for such an API are > https://github.com/yariv/erlyweb/blob/master/src/smerl/smerl.erl > and > https://github.com/uwiger/parse_trans. > > /Richard > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From vladdu55@REDACTED Fri Feb 21 23:16:41 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 21 Feb 2014 23:16:41 +0100 Subject: [erlang-questions] v17 unicode support In-Reply-To: References: Message-ID: On Fri, Feb 21, 2014 at 7:12 PM, Bj?rn-Egil Dahlberg < wallentin.dahlberg@REDACTED> wrote: > I don't think that is desired. > Start erlang with +pc unicode > > do a lists:seq(300,10000) .. > > // Bj?rn-Egil > > Hmm, I see your point. On the other hand, this is just an artifact for the lists/strings duality and possibly another reason to make strings a separate type. If a value is a latin1 string, it will print nicely in the shell, but if it's utf8 it won't... regards, Vlad > > 2014-02-21 14:05 GMT+01:00 Vlad Dumitrescu : > >> Hi! >> >> I'm not sure if I misunderstood something or if there is a problem in >> 17.0-rc1, but starting a shell normally gives >> >> Erlang/OTP 17 [RELEASE CANDIDATE 1] [erts-6.0] [smp:4:4] >> [async-threads:10] >> Eshell V6.0 (abort with ^G) >> 1> "?". >> [518] >> 2> erl_scan:string("\"?\""). >> {ok,[{string,1,[518]}],1} >> 3> lists:keyfind(encoding, 1, io:getopts()). >> {encoding,unicode} >> 4> $?. >> 518 >> >> while starting with "+pc unicode" gives the expected (for me) result. >> >> Erlang/OTP 17 [RELEASE CANDIDATE 1] [erts-6.0] [smp:4:4] >> [async-threads:10] >> Eshell V6.0 (abort with ^G) >> 1> "?". >> "?" >> 2> erl_scan:string("\"?\""). >> {ok,[{string,1,"?"}],1} >> 3> >> 3> lists:keyfind(encoding, 1, io:getopts()). >> {encoding,unicode} >> 4> $?. >> 518 >> >> Isn't 17.0 supposed to have the unicode support as default even in this >> context? >> >> 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 loz.accs@REDACTED Sat Feb 22 10:14:08 2014 From: loz.accs@REDACTED (Maxim Velesyuk) Date: Sat, 22 Feb 2014 13:14:08 +0400 Subject: [erlang-questions] Erlang and syntax. Message-ID: For a long time I wonder why erlang syntax is not based on s-expressions? Did Creators debate on it, if yes, why had prolog-like syntax won? Often when I feel I need to change ast I remember how clumsy and uncomfortable parse transform is, so I overcome myself and make workarounds. But macros are still useful, programmers use parse transform when they have no other choice, and projects like merl appear. List and zip comprehensions could be implemented as macros, ets and mnesia query language is actually prefix-notation language with code quoting, even pattern matching and so long expected maps could be just a libraries. Take a look at c++ and java, how they suffer from inventing new syntax. Hopefully Erlang will not turn in such syntax-monster. It has syntax for many things, but it still not as flexible as it could be. This forwards me back to my first question, why? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vychodil.hynek@REDACTED Sat Feb 22 12:34:16 2014 From: vychodil.hynek@REDACTED (Hynek Vychodil) Date: Sat, 22 Feb 2014 12:34:16 +0100 Subject: [erlang-questions] Creating a diagnostic memory dump of live erlang VM In-Reply-To: References: <5305BC28.4070906@gmail.com> Message-ID: Hi, one of the greatest engineering rules is: If it works, don't touch it. And I'm far far away to teach anybody how to code but it itches. So I did some touches here ============ -module(report). -export([crash_report/0, crash_report/1, make_report/0]). crash_report() -> crash_report("/tmp/erl_crash.dump"). crash_report(FileName) -> file:write_file(FileName, make_report()). make_report() -> Date = rfc1123_local_date(), Header = iolist_to_binary([<<"=erl_crash_dump:0.2\n">>, Date, <<"\nSystem version: ">>]), Ets = ets_info(), [ Header, erlang:system_info(system_version), erlang:system_info(info), erlang:system_info(procs), Ets, erlang:system_info(dist), <<"=loaded_modules\n">>, binary:replace(erlang:system_info(loaded), <<"\n">>, <<"\n=mod:">>, [global]) ]. ets_info() -> [ets_table_info(T) || T<-ets:all()]. ets_table_info(Table) -> Info = ets:info(Table), Owner = pid_to_list(proplists:get_value(owner, Info)), Name = atom_to_list(proplists:get_value(name, Info)), Objects = integer_to_list(proplists:get_value(size, Info)), iolist_to_binary([ <<"=ets:">>, Owner, <<"\nTable: ">>, Name, <<"\nName: ">>, Name, <<"\nObjects: ">>, Objects, $\n ]). rfc1123_local_date() -> rfc1123_local_date(os:timestamp()). rfc1123_local_date({A, B, C}) -> rfc1123_local_date(calendar:now_to_local_time({A, B, C})); rfc1123_local_date({{YYYY, MM, DD}, {Hour, Min, Sec}}) -> DayNumber = calendar:day_of_the_week({YYYY, MM, DD}), io_lib:format( "~s, ~2.2.0w ~3.s ~4.4.0w ~2.2.0w:~2.2.0w:~2.2.0w GMT", [httpd_util:day(DayNumber), DD, httpd_util:month(MM), YYYY, Hour, Min, Sec] ); rfc1123_local_date(Epoch) when erlang:is_integer(Epoch) -> rfc1123_local_date(calendar:gregorian_seconds_to_datetime(Epoch+62167219200)). ========== No wonder they are telling Erlang has bad string support if they see code like previous. I think iolist is one of most powerful structures for manipulating strings and one of strengths of Erlang so we should use it and use it well. Converting list or iolist to binary over and over again is very bad idea. It is very slow and doesn't saves any memory until GC occurs. These two calls to iolist_to_binary/1 in code above is unnecessary but shows the idea. Call it early when make string which you are not intended to touch and is big enough to save memory but most importantly never ever call it again until you have a very good reason to do. It would make unnecessary copying. Let Erlang io subsystem do the rest. Sorry for this rant but it was itchy With best regards Hynek Vychodil On Fri, Feb 21, 2014 at 4:47 AM, Matthew Evans wrote: > Hi, > > I took it on myself to write a little module. This will produce a crash > report that will display most of the important data that can be loaded into > the crash dump viewer. From Erlang run report:crash_report(). > > The crash dump goes to /tmp/erl_crash.dump and can be viewed from Erlang > via your browser when you run crashdump_viewer:start(). from your Erlang > shell. > > ========= > > -module(report). > > -export([crash_report/0]). > > crash_report() -> > Date = erlang:list_to_binary(rfc1123_local_date()), > Header = > binary:list_to_bin([<<"=erl_crash_dump:0.2\n">>,Date,<<"\nSystem version: > ">>]), > Ets = ets_info(), > Report = > binary:list_to_bin([Header,erlang:list_to_binary(erlang:system_info(system_version)),erlang:system_info(info),erlang:system_info(procs),Ets,erlang:system_info(dist), > > <<"=loaded_modules\n">>,binary:replace(erlang:system_info(loaded),<<"\n">>,<<"\n=mod:">>,[global])]), > file:write_file("/tmp/erl_crash.dump",Report). > > ets_info() -> > binary:list_to_bin([ets_table_info(T)||T<-ets:all()]). > > ets_table_info(Table) -> > Info = ets:info(Table), > Owner = > erlang:list_to_binary(erlang:pid_to_list(proplists:get_value(owner,Info))), > TableN = > erlang:list_to_binary(erlang:atom_to_list(proplists:get_value(name,Info))), > Name = > erlang:list_to_binary(erlang:atom_to_list(proplists:get_value(name,Info))), > Objects = > erlang:list_to_binary(erlang:integer_to_list(proplists:get_value(size,Info))), > binary:list_to_bin([<<"=ets:">>,Owner,<<"\nTable: > ">>,TableN,<<"\nName: ">>,Name,<<"\nObjects: ">>,Objects,<<"\n">>]). > > rfc1123_local_date() -> > rfc1123_local_date(os:timestamp()). > rfc1123_local_date({A,B,C}) -> > rfc1123_local_date(calendar:now_to_local_time({A,B,C})); > rfc1123_local_date({{YYYY,MM,DD},{Hour,Min,Sec}}) -> > DayNumber = calendar:day_of_the_week({YYYY,MM,DD}), > lists:flatten( > io_lib:format("~s, ~2.2.0w ~3.s ~4.4.0w ~2.2.0w:~2.2.0w:~2.2.0w > GMT", > > [httpd_util:day(DayNumber),DD,httpd_util:month(MM),YYYY,Hour,Min,Sec])); > rfc1123_local_date(Epoch) when erlang:is_integer(Epoch) -> > > rfc1123_local_date(calendar:gregorian_seconds_to_datetime(Epoch+62167219200)). > > > ------------------------------ > From: vladdu55@REDACTED > Date: Thu, 20 Feb 2014 10:30:39 +0100 > To: mabrek@REDACTED > CC: erlang-questions@REDACTED > Subject: Re: [erlang-questions] Creating a diagnostic memory dump of live > erlang VM > > > Hi, > > On Thu, Feb 20, 2014 at 9:26 AM, Anton Lebedevich wrote: > > Another thing which I missed a lot after converting from java to erlang > is a thread dump. It turned out that it's possible to get all > stacktraces for all processes (even with function arguments) via > erlang:system_info(procs). > > It returns them as text so it's better to dump it to file immediately: > file:write_file("/tmp/procs.txt",erlang:system_info(procs)). > > Format of these traces is quite interesting (undocumented) the best > description I found is in the mailing list > http://erlang.org/pipermail/erlang-questions/2012-November/070609.html > > > I might just as well ask the obvious question: why is not this information > available even as normal Erlang terms, so that one doesn't need to parse > it? When writing a crash dump, it doesn't matter, but if it should be used > at runtime it's a pain to parse it... This applies to the other results > from system_info/1 that are dumped as text. > > 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 n.oxyde@REDACTED Sat Feb 22 12:43:42 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 22 Feb 2014 12:43:42 +0100 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: References: Message-ID: Erlang is made to be boring. Boring means that it needs to be brain dead easy to comprehend. Brain dead easy means no macros. Given the premise of the absence of macros, why should the language use S-expressions and be homoiconic? Why do you need to change the AST? That sounds like a constructed need from a bored developer looking for a problem. If you want better parse transforms, help me finish brackets for 19.0. https://github.com/nox/otp/commit/brackets I don?t see how could you compare C++ and Java to Erlang, certainly not on the front of syntax. Erlang is a tiny language. So to get back to the first question: because macros do not promote explicitness. Regards, -- Anthony Ramine Le 22 f?vr. 2014 ? 10:14, Maxim Velesyuk a ?crit : > For a long time I wonder why erlang syntax is not based on s-expressions? Did Creators debate on it, if yes, why had prolog-like syntax won? > > Often when I feel I need to change ast I remember how clumsy and uncomfortable parse transform is, so I overcome myself and make workarounds. > > But macros are still useful, programmers use parse transform when they have no other choice, and projects like merl appear. > > List and zip comprehensions could be implemented as macros, ets and mnesia query language is actually prefix-notation language with code quoting, even pattern matching and so long expected maps could be just a libraries. > > Take a look at c++ and java, how they suffer from inventing new syntax. Hopefully Erlang will not turn in such syntax-monster. It has syntax for many things, but it still not as flexible as it could be. > > This forwards me back to my first question, why? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vladdu55@REDACTED Sat Feb 22 12:58:40 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Sat, 22 Feb 2014 12:58:40 +0100 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: References: Message-ID: On 22 Feb 2014 12:43, "Anthony Ramine" wrote: > > Erlang is made to be boring. Boring means that it needs to be brain dead easy to comprehend. Brain dead easy means no macros. Sorry, but -define () macros can be just as confusing as lispy ones... I would gladly trade them away. /Vlad > Given the premise of the absence of macros, why should the language use S-expressions and be homoiconic? > > Why do you need to change the AST? That sounds like a constructed need from a bored developer looking for a problem. If you want better parse transforms, help me finish brackets for 19.0. > > https://github.com/nox/otp/commit/brackets > > I don't see how could you compare C++ and Java to Erlang, certainly not on the front of syntax. Erlang is a tiny language. > > So to get back to the first question: because macros do not promote explicitness. > > Regards, > > -- > Anthony Ramine > > Le 22 f?vr. 2014 ? 10:14, Maxim Velesyuk a ?crit : > > > For a long time I wonder why erlang syntax is not based on s-expressions? Did Creators debate on it, if yes, why had prolog-like syntax won? > > > > Often when I feel I need to change ast I remember how clumsy and uncomfortable parse transform is, so I overcome myself and make workarounds. > > > > But macros are still useful, programmers use parse transform when they have no other choice, and projects like merl appear. > > > > List and zip comprehensions could be implemented as macros, ets and mnesia query language is actually prefix-notation language with code quoting, even pattern matching and so long expected maps could be just a libraries. > > > > Take a look at c++ and java, how they suffer from inventing new syntax. Hopefully Erlang will not turn in such syntax-monster. It has syntax for many things, but it still not as flexible as it could be. > > > > This forwards me back to my first question, why? > > _______________________________________________ > > 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 mahesh@REDACTED Sat Feb 22 13:02:17 2014 From: mahesh@REDACTED (Mahesh Paolini-Subramanya) Date: Sat, 22 Feb 2014 07:02:17 -0500 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: References: Message-ID: An edge case does not necessarily negate an entire philosophy. e.g. "I dont' steal from others" ++ "Yup, that book of Post-Its came from my Office" Cheers On Sat, Feb 22, 2014 at 6:58 AM, Vlad Dumitrescu wrote: > > On 22 Feb 2014 12:43, "Anthony Ramine" wrote: > > > > Erlang is made to be boring. Boring means that it needs to be brain dead > easy to comprehend. Brain dead easy means no macros. > > Sorry, but -define () macros can be just as confusing as lispy ones... I > would gladly trade them away. > > /Vlad > > > Given the premise of the absence of macros, why should the language use > S-expressions and be homoiconic? > > > > Why do you need to change the AST? That sounds like a constructed need > from a bored developer looking for a problem. If you want better parse > transforms, help me finish brackets for 19.0. > > > > https://github.com/nox/otp/commit/brackets > > > > I don't see how could you compare C++ and Java to Erlang, certainly not > on the front of syntax. Erlang is a tiny language. > > > > So to get back to the first question: because macros do not promote > explicitness. > > > > Regards, > > > > -- > > Anthony Ramine > > > > Le 22 f?vr. 2014 ? 10:14, Maxim Velesyuk a ?crit : > > > > > For a long time I wonder why erlang syntax is not based on > s-expressions? Did Creators debate on it, if yes, why had prolog-like > syntax won? > > > > > > Often when I feel I need to change ast I remember how clumsy and > uncomfortable parse transform is, so I overcome myself and make workarounds. > > > > > > But macros are still useful, programmers use parse transform when they > have no other choice, and projects like merl appear. > > > > > > List and zip comprehensions could be implemented as macros, ets and > mnesia query language is actually prefix-notation language with code > quoting, even pattern matching and so long expected maps could be just a > libraries. > > > > > > Take a look at c++ and java, how they suffer from inventing new > syntax. Hopefully Erlang will not turn in such syntax-monster. It has > syntax for many things, but it still not as flexible as it could be. > > > > > > This forwards me back to my first question, why? > > > _______________________________________________ > > > 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 > > -- *Mahesh Paolini-Subramanya That tall bald Indian guy..* *Google+ | Blog | Twitter | LinkedIn * -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sat Feb 22 13:14:36 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 22 Feb 2014 13:14:36 +0100 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: References: Message-ID: <251B2AAD-AF14-4161-9CD5-DB75CFDEE28D@gmail.com> Sorry but no. I know I am reading a macro call with epp macros. I don?t know that in a language using s-expressions. And people use preprocessor macros rarely. -- Anthony Ramine Le 22 f?vr. 2014 ? 12:58, Vlad Dumitrescu a ?crit : > Sorry, but -define () macros can be just as confusing as lispy ones... I would gladly trade them away. > > From vladdu55@REDACTED Sat Feb 22 17:31:59 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Sat, 22 Feb 2014 17:31:59 +0100 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: <251B2AAD-AF14-4161-9CD5-DB75CFDEE28D@gmail.com> References: <251B2AAD-AF14-4161-9CD5-DB75CFDEE28D@gmail.com> Message-ID: On 22 Feb 2014 13:14, "Anthony Ramine" wrote: > > Sorry but no. I know I am reading a macro call with epp macros. I don't know that in a language using s-expressions. There's nothing to stop the syntax to require special names for macros, it doesn't have to be lisp. > And people use preprocessor macros rarely. You'd be surprised :-) /vlad > -- > Anthony Ramine > > Le 22 f?vr. 2014 ? 12:58, Vlad Dumitrescu a ?crit : > > > Sorry, but -define () macros can be just as confusing as lispy ones... I would gladly trade them away. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Sat Feb 22 17:39:51 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Sat, 22 Feb 2014 11:39:51 -0500 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: References: <251B2AAD-AF14-4161-9CD5-DB75CFDEE28D@gmail.com> Message-ID: <5308D2D7.8020203@meetinghouse.net> Dare I mention that there is LFE. Miles Fidelman Vlad Dumitrescu wrote: > > > On 22 Feb 2014 13:14, "Anthony Ramine" > wrote: > > > > Sorry but no. I know I am reading a macro call with epp macros. I > don?t know that in a language using s-expressions. > > There's nothing to stop the syntax to require special names for > macros, it doesn't have to be lisp. > > > And people use preprocessor macros rarely. > > You'd be surprised :-) > > /vlad > > > -- > > Anthony Ramine > > > > Le 22 f?vr. 2014 ? 12:58, Vlad Dumitrescu > a ?crit : > > > > > Sorry, but -define () macros can be just as confusing as lispy > ones... I would gladly trade them away. > > > > > > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From essen@REDACTED Sat Feb 22 18:46:00 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 22 Feb 2014 18:46:00 +0100 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: References: Message-ID: <5308E258.1070706@ninenines.eu> Hello, On 02/22/2014 10:14 AM, Maxim Velesyuk wrote: > Often when I feel I need to change ast I remember how clumsy and > uncomfortable parse transform is, so I overcome myself and make workarounds. Why do you even feel the need to change the AST? Don't do that. > But macros are still useful, programmers use parse transform when they > have no other choice, and projects like merl appear. Macros are not useful. Macros are what makes a perfectly readable program into the worst spaghetti code you have ever seen. Even EPP macros, which look pretty harmless as they have very limited capabilities, can make things a lot worse than it needs to be. Sure macros allow you to write less code. But I spend 90% of my time reading code, so I like programs that are optimized for my reading. If I always need to refer to some other source file or document to understand what the code is doing, then I am not going to be using your program very long. Macros make your programs worse than PHP and Java combined. > List and zip comprehensions could be implemented as macros, ets and > mnesia query language is actually prefix-notation language with code > quoting, even pattern matching and so long expected maps could be just a > libraries. And then one person creates maps, another creates frames, both with the same or similar syntax but with different semantics, both get used in the same system, and the code is completely unreadable. No thanks. > Take a look at c++ and java, how they suffer from inventing new syntax. > Hopefully Erlang will not turn in such syntax-monster. It has syntax for > many things, but it still not as flexible as it could be. > > This forwards me back to my first question, why? You don't need it. -- Lo?c Hoguin http://ninenines.eu From n.oxyde@REDACTED Sat Feb 22 19:55:05 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 22 Feb 2014 19:55:05 +0100 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: References: <251B2AAD-AF14-4161-9CD5-DB75CFDEE28D@gmail.com> Message-ID: <6BD3B989-5CE9-4086-8E36-F4F7282E4989@gmail.com> If it doesn't need to be Lisp, why does it need S-expressions? -- Anthony Ramine > Le 22 f?vr. 2014 ? 17:31, Vlad Dumitrescu a ?crit : > > There's nothing to stop the syntax to require special names for macros, it doesn't have to be lisp. From vladdu55@REDACTED Sat Feb 22 20:53:58 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Sat, 22 Feb 2014 20:53:58 +0100 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: <6BD3B989-5CE9-4086-8E36-F4F7282E4989@gmail.com> References: <251B2AAD-AF14-4161-9CD5-DB75CFDEE28D@gmail.com> <6BD3B989-5CE9-4086-8E36-F4F7282E4989@gmail.com> Message-ID: On Sat, Feb 22, 2014 at 7:55 PM, Anthony Ramine wrote: > If it doesn't need to be Lisp, why does it need S-expressions? > > Because Lisp is much more than its syntax, what we'll get instead is (surprise!) "lisp flavoured erlang" which could decide to have the syntax for macro names start with a ?, for example, making it clear what they are. I don't say it should, just that it is possible to enforce this kind of rule, to help reading the code. regards, Vlad > -- > Anthony Ramine > > > Le 22 f?vr. 2014 ? 17:31, Vlad Dumitrescu a ?crit : > > > > There's nothing to stop the syntax to require special names for macros, > it doesn't have to be lisp. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.charles.davis@REDACTED Sat Feb 22 21:22:09 2014 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sat, 22 Feb 2014 12:22:09 -0800 (PST) Subject: [erlang-questions] How to Name Concurrency Patterns In-Reply-To: References: Message-ID: Thank you Jay for this posting. It is a refreshing relief from "some other" threads on the list right now to see something both educational and _useful_. /s PS this doesn't feel like a "me too" spam response; since I hope it will encourage others to look more carefully at this work. On Friday, February 21, 2014 1:07:11 PM UTC-6, Jay Nelson wrote: > > I don?t have a good handle on naming, but I am giving a talk at Erlang > Factory SF > on concurrency patterns using ets tables as the implementation mechanism. > The library is now called ?Erlang Patterns of Concurrency? and resides at > https://github.com/duomark/epocxy (was recently renamed, so there may > be references to dk_cxy around but they now resolve to epocxy) > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Sat Feb 22 21:50:30 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 22 Feb 2014 21:50:30 +0100 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: References: <5308E258.1070706@ninenines.eu> Message-ID: <53090D96.9020802@ninenines.eu> On 02/22/2014 09:33 PM, Maxim Velesyuk wrote: > >Sure macros allow you to write less code. But I spend 90% of my time > reading code, so I like programs that are optimized for my reading. If I > always need to refer to some other source file or document to understand > what the code is doing, then I am not going to be using your program > very long. > > But when you see unknown function you still have no idea what it does > and you have to figure it out. Any abstraction works in same way. I beg to differ. file:read_file/1 is pretty obvious. So is lists:map/2. So is most of the functions you can read in your code. You don't need to know the internals of a function or even the full spec when you are reading code, you know that you are reading a file, or mapping a function over a list. When you have macros, you don't even have any idea whether what you are calling is a function or something else entirely. And when you have macros that are being used to create new syntax? Then it is completely alien to all the code around it. > >And then one person creates maps, another creates frames, both with > the same or similar syntax but with different semantics, both get used > in the same system, and the code is completely unreadable. No thanks. > > Macros are dangerous as much as powerful. If programmer does not use > them correctly its a programmer's fault. In the end who is the target > audience of a programming language for concurrent, fault tolerant > systems? Probably the programmer who understands what he does. Should > language designer force programmer to write code in 'correct' way? I > don't know, but valuable spaces and programming patterns appeared from > such ideas. Hello elitism! I mean, seriously? You aren't using Erlang because you are a better person. You are a better person because you are using Erlang, because it gives you the tools to do things that are difficult to do in other languages. Don't dismiss other people simply because they don't have the chance to work with Erlang. I will point out though that the target audience of any code, regardless of the language it is being written in, is the *reader*. It's not the programmer who wrote it. It's not the compiler. It's the many guys that will come afterward, read the code, fix bugs, maintain it. If your code is just using Erlang, then it's pretty easy for them to see what is going on. If you have changed all the rules using macros, then they need to learn more things before they can become productive with your code. They will not like you for it, especially if the production system is down and they have to fix the bug quickly. > >You don't need it. > > Who but the particular programmer can decide what does he need and what > doesn't ? You don't decide what you need. You need it. That's it. If you can do without and still meet your requirements and deadlines, then you don't need it, it's just luxury. Except in this case it's luxury similar to having snakeskin boots, you get what you want, but at the cost of the blood of the people that will come after you. -- Lo?c Hoguin http://ninenines.eu From chuck.irvine@REDACTED Sat Feb 22 22:02:54 2014 From: chuck.irvine@REDACTED (Charles Irvine) Date: Sat, 22 Feb 2014 15:02:54 -0600 Subject: [erlang-questions] bug: Can't have variables in keys? Message-ID: I suppose that this is a known bug?.. 9> X = x. x 10> #{X => y}. # 1: illegal use of variable ?X? in map From essen@REDACTED Sat Feb 22 22:06:23 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 22 Feb 2014 22:06:23 +0100 Subject: [erlang-questions] bug: Can't have variables in keys? In-Reply-To: References: Message-ID: <5309114F.7030906@ninenines.eu> On 02/22/2014 10:02 PM, Charles Irvine wrote: > I suppose that this is a known bug?.. > > 9> X = x. > x > 10> #{X => y}. > # 1: illegal use of variable ?X? in map It's a known current limitation. -- Lo?c Hoguin http://ninenines.eu From dottedmag@REDACTED Sat Feb 22 21:20:21 2014 From: dottedmag@REDACTED (Mikhail Gusarov) Date: Sat, 22 Feb 2014 21:20:21 +0100 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: References: <251B2AAD-AF14-4161-9CD5-DB75CFDEE28D@gmail.com> <6BD3B989-5CE9-4086-8E36-F4F7282E4989@gmail.com> Message-ID: "Much more" of Lisp, besides being a functional language (sans impurity in most Lisps) stems from code-data duality and macro system. Take it away and you'll gain nothing compared to Erlang as is. Best regards, Mikhail Gusarov. On Sat, Feb 22, 2014 at 8:53 PM, Vlad Dumitrescu wrote: > On Sat, Feb 22, 2014 at 7:55 PM, Anthony Ramine wrote: >> >> If it doesn't need to be Lisp, why does it need S-expressions? >> > > Because Lisp is much more than its syntax, what we'll get instead is > (surprise!) "lisp flavoured erlang" which could decide to have the syntax > for macro names start with a ?, for example, making it clear what they are. > I don't say it should, just that it is possible to enforce this kind of > rule, to help reading the code. > > regards, > Vlad > > >> >> -- >> Anthony Ramine >> >> > Le 22 f?vr. 2014 ? 17:31, Vlad Dumitrescu a ?crit : >> > >> > There's nothing to stop the syntax to require special names for macros, >> > it doesn't have to be lisp. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From loz.accs@REDACTED Sat Feb 22 21:33:08 2014 From: loz.accs@REDACTED (Maxim Velesyuk) Date: Sun, 23 Feb 2014 00:33:08 +0400 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: <5308E258.1070706@ninenines.eu> References: <5308E258.1070706@ninenines.eu> Message-ID: >Sure macros allow you to write less code. But I spend 90% of my time reading code, so I like programs that are optimized for my reading. If I always need to refer to some other source file or document to understand what the code is doing, then I am not going to be using your program very long. But when you see unknown function you still have no idea what it does and you have to figure it out. Any abstraction works in same way. >And then one person creates maps, another creates frames, both with the same or similar syntax but with different semantics, both get used in the same system, and the code is completely unreadable. No thanks. Macros are dangerous as much as powerful. If programmer does not use them correctly its a programmer's fault. In the end who is the target audience of a programming language for concurrent, fault tolerant systems? Probably the programmer who understands what he does. Should language designer force programmer to write code in 'correct' way? I don't know, but valuable spaces and programming patterns appeared from such ideas. >You don't need it. Who but the particular programmer can decide what does he need and what doesn't ? 2014-02-22 21:46 GMT+04:00 Lo?c Hoguin : > Hello, > > > On 02/22/2014 10:14 AM, Maxim Velesyuk wrote: > >> Often when I feel I need to change ast I remember how clumsy and >> uncomfortable parse transform is, so I overcome myself and make >> workarounds. >> > > Why do you even feel the need to change the AST? Don't do that. > > > But macros are still useful, programmers use parse transform when they >> have no other choice, and projects like merl appear. >> > > Macros are not useful. Macros are what makes a perfectly readable program > into the worst spaghetti code you have ever seen. Even EPP macros, which > look pretty harmless as they have very limited capabilities, can make > things a lot worse than it needs to be. > > Sure macros allow you to write less code. But I spend 90% of my time > reading code, so I like programs that are optimized for my reading. If I > always need to refer to some other source file or document to understand > what the code is doing, then I am not going to be using your program very > long. > > Macros make your programs worse than PHP and Java combined. > > > List and zip comprehensions could be implemented as macros, ets and >> mnesia query language is actually prefix-notation language with code >> quoting, even pattern matching and so long expected maps could be just a >> libraries. >> > > And then one person creates maps, another creates frames, both with the > same or similar syntax but with different semantics, both get used in the > same system, and the code is completely unreadable. No thanks. > > > Take a look at c++ and java, how they suffer from inventing new syntax. >> Hopefully Erlang will not turn in such syntax-monster. It has syntax for >> many things, but it still not as flexible as it could be. >> >> This forwards me back to my first question, why? >> > > You don't need it. > > -- > Lo?c Hoguin > http://ninenines.eu -------------- next part -------------- An HTML attachment was scrubbed... URL: From dottedmag@REDACTED Sat Feb 22 22:33:39 2014 From: dottedmag@REDACTED (Mikhail Gusarov) Date: Sat, 22 Feb 2014 22:33:39 +0100 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: References: <5308E258.1070706@ninenines.eu> Message-ID: > But when you see unknown function you still have no idea what it does and > you have to figure it out. Any abstraction works in same way. There is subtle difference: all functions conform to the function abstraction: function does not alter/capture names from calling namespace and function does not arbitrarily transfer control. Function is a simple abstraction: it accepts arguments and returns result. As a result, function abstraction allows one to selectively ignore parts of the code while reading it (which was the driving force behind structured programming). This luxury is not available to readers of programs in languages with macros (unhygienic ones), especially if those don't distinguish macros and functions syntactically. So, macros are new GOTO statements: they are powerful tool, but power results in harder-to-understand programs. Best regards, Mikhail Gusarov. From steven.charles.davis@REDACTED Sat Feb 22 23:39:06 2014 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sat, 22 Feb 2014 14:39:06 -0800 (PST) Subject: [erlang-questions] Why isn't Erlang more popular? In-Reply-To: References: Message-ID: <54fac462-e2ad-4dd9-b889-9f0ae84dd4dd@googlegroups.com> I strongly suspect that it is because erlang forces you to figure out the problem before you write code. In general, my observation is that people prefer to distract themselves with trivia and convince themselves of productivity, rather than figure out a real problem. This makes erlang appear hard for people - when in fact it's super-easy if you know exactly what you are trying to do. My 2c /s On Friday, February 21, 2014 10:49:33 AM UTC-6, Gordon Guthrie wrote: > > Instead of us discussing it in private, I thought we should ask people who > DONT use Erlang the same question that people have been knawing on on the > list. > > So I have done as Ask HN on hacker news. > > Due to the ring-voting detection feature you will need to track it down > yourself I won't provide a link > > Gordon > > -- > --- > Gordon Guthrie > CEO vixo.com > @gordonguthrie > +44 (0) 7776 251669 (in Bonnie Scotland!) > > vixo is made in Scotland from electrons > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Sat Feb 22 23:53:29 2014 From: mfidelman@REDACTED (Miles Fidelman) Date: Sat, 22 Feb 2014 17:53:29 -0500 Subject: [erlang-questions] Why isn't Erlang more popular? In-Reply-To: <54fac462-e2ad-4dd9-b889-9f0ae84dd4dd@googlegroups.com> References: <54fac462-e2ad-4dd9-b889-9f0ae84dd4dd@googlegroups.com> Message-ID: <53092A69.90004@meetinghouse.net> Following up on that... People either: - stick with a language/platform/environment they learned in school (or at some point) - use the language/platform/environment that is forced upon them by their environment (job, customers), or, and only if the above fail, - search for a language/platform/environment that addresses a problem they're trying to solve, and they way they think about that problem If you're working a problem that is well suited to concurrency, high availability, and functional expressions - you'll probably end up with Erlang. Otherwise.... Steve Davis wrote: > I strongly suspect that it is because erlang forces you to figure out > the problem before you write code. > > In general, my observation is that people prefer to distract > themselves with trivia and convince themselves of productivity, rather > than figure out a real problem. > > This makes erlang appear hard for people - when in fact it's > super-easy if you know exactly what you are trying to do. > > My 2c > > /s > > > On Friday, February 21, 2014 10:49:33 AM UTC-6, Gordon Guthrie wrote: > > Instead of us discussing it in private, I thought we should ask > people who DONT use Erlang the same question that people have been > knawing on on the list. > > So I have done as Ask HN on hacker news. > > Due to the ring-voting detection feature you will need to track it > down yourself I won't provide a link > > Gordon > > -- > --- > Gordon Guthrie > CEO vixo.com > @gordonguthrie > +44 (0) 7776 251669 (in Bonnie Scotland!) > > vixo is made in Scotland from electrons > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mjtruog@REDACTED Sun Feb 23 01:21:16 2014 From: mjtruog@REDACTED (Michael Truog) Date: Sat, 22 Feb 2014 16:21:16 -0800 Subject: [erlang-questions] hows the erlang web framework or library world evolving? In-Reply-To: References: <25dd42a4-00b3-49fd-a5a7-d493dc8169f5@googlegroups.com> Message-ID: <53093EFC.1010207@gmail.com> It appears like this email isn't one I received from the email list, so other people may not have received it since it was sent through the google group rather than the normal mailing list (http://erlang.org/pipermail/erlang-questions/2014-February/subject.html). (not sure why the google group method of sending emails isn't working properly, since I have both set up to deliver emails) http://cloudi.org uses CloudI to run the site with cowboy as the HTTP server (config at http://cloudi.org/config.html) On 02/22/2014 03:55 PM, Steve Davis wrote: > Smart question. You'd think there'd be 100 answers by now, right? > > On Thursday, February 20, 2014 5:05:25 AM UTC-6, johannes falcone wrote: > > anyone got a live erlang powered site I can see? > > > what data store are you using? > mnesia? > something else? > firebirdDB? postgresql? > > -- > Remember to send a copy to erlang (dot) questions (at) erlang (dot) org when posting. > --- > You received this message because you are subscribed to the Google Groups "Erlang Programming" group. > To unsubscribe from this group and stop receiving emails from it, send an email to erlang-programming+unsubscribe@REDACTED > To post to this group, send email to erlang-programming@REDACTED > Visit this group at http://groups.google.com/group/erlang-programming. > For more options, visit https://groups.google.com/groups/opt_out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sun Feb 23 01:27:53 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 23 Feb 2014 01:27:53 +0100 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: References: <5308E258.1070706@ninenines.eu> Message-ID: Exactly. You have no idea how many patches I wrote where I have absolutely no clue about the surrounding code. This wouldn?t be as feasible in a homoiconic language with macros where whatever can happen. -- Anthony Ramine Le 22 f?vr. 2014 ? 22:33, Mikhail Gusarov a ?crit : > As a result, function abstraction allows one to selectively ignore > parts of the code while reading it (which was the driving force behind > structured programming). This luxury is not available to readers of > programs in languages with macros (unhygienic ones), especially if > those don't distinguish macros and functions syntactically. From bengt.kleberg@REDACTED Sun Feb 23 07:45:30 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Sun, 23 Feb 2014 06:45:30 +0000 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: References: <5308E258.1070706@ninenines.eu> , Message-ID: <67hrq600t3hnbomdonkpb9g2.1393137927515@email.android.com> Greetings, It would be a major drawback to add unhygenic macros to a programming language. Bengt Sent from Moxier Mail (http://www.moxier.com) ----- Ursprungligt meddelande ----- Fr?n: Mikhail Gusarov Till: Maxim Velesyuk Kopia: "erlang-questions@REDACTED" Skickat: 22-02-2014 10:35 em ?mne: Re: [erlang-questions] Erlang and syntax. > But when you see unknown function you still have no idea what it does and > you have to figure it out. Any abstraction works in same way. There is subtle difference: all functions conform to the function abstraction: function does not alter/capture names from calling namespace and function does not arbitrarily transfer control. Function is a simple abstraction: it accepts arguments and returns result. As a result, function abstraction allows one to selectively ignore parts of the code while reading it (which was the driving force behind structured programming). This luxury is not available to readers of programs in languages with macros (unhygienic ones), especially if those don't distinguish macros and functions syntactically. So, macros are new GOTO statements: they are powerful tool, but power results in harder-to-understand programs. Best regards, Mikhail Gusarov. _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From marc@REDACTED Sun Feb 23 10:33:50 2014 From: marc@REDACTED (Marc Worrell) Date: Sun, 23 Feb 2014 10:33:50 +0100 Subject: [erlang-questions] hows the erlang web framework or library world evolving? In-Reply-To: <53093EFC.1010207@gmail.com> References: <25dd42a4-00b3-49fd-a5a7-d493dc8169f5@googlegroups.com> <53093EFC.1010207@gmail.com> Message-ID: <0B87E5CE-5FA3-4851-9619-28934A9415FC@worrell.nl> We made a list of some Zotonic powered sites at http://zotonic.com/showcase - Marc > On 23 feb. 2014, at 01:21, Michael Truog wrote: > > It appears like this email isn't one I received from the email list, so other people may not have received it since it was sent through the google group rather than the normal mailing list (http://erlang.org/pipermail/erlang-questions/2014-February/subject.html). (not sure why the google group method of sending emails isn't working properly, since I have both set up to deliver emails) > > http://cloudi.org uses CloudI to run the site with cowboy as the HTTP server > (config at http://cloudi.org/config.html) > >> On 02/22/2014 03:55 PM, Steve Davis wrote: >> Smart question. You'd think there'd be 100 answers by now, right? >> >>> On Thursday, February 20, 2014 5:05:25 AM UTC-6, johannes falcone wrote: >>> anyone got a live erlang powered site I can see? >>> >>> >>> what data store are you using? >>> mnesia? >>> something else? >>> firebirdDB? postgresql? >> -- >> Remember to send a copy to erlang (dot) questions (at) erlang (dot) org when posting. >> --- >> You received this message because you are subscribed to the Google Groups "Erlang Programming" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to erlang-programming+unsubscribe@REDACTED >> To post to this group, send email to erlang-programming@REDACTED >> Visit this group at http://groups.google.com/group/erlang-programming. >> For more options, visit https://groups.google.com/groups/opt_out. > > _______________________________________________ > 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 Sun Feb 23 14:22:37 2014 From: gumm@REDACTED (Jesse Gumm) Date: Sun, 23 Feb 2014 07:22:37 -0600 Subject: [erlang-questions] hows the erlang web framework or library world evolving? In-Reply-To: <53093EFC.1010207@gmail.com> References: <25dd42a4-00b3-49fd-a5a7-d493dc8169f5@googlegroups.com> <53093EFC.1010207@gmail.com> Message-ID: Yeah, I definitely didn't get it either. I asked a similar question on the Nitrogen mailing list a while back ( https://groups.google.com/forum/m/#!topic/nitrogenweb/rUxmq88TaK0) and got a handful of interesting responses. One guy uses it for powering home automation stuff, another for a financial exchange front end, others for games, another for registration for a university (that one, iirc, was sent privately to me rather than to the group). Personally, I use Nitrogen and Erlang to power my league and tournament management system, BracketPal (http://bracketpal.com). Some of these uses may not be right in erlang' high concurrency wheelhouse, but I find Nitrogen to be a highly productive environment for building interactive Web applications without having to write Javascript, which I find to be a massive plus. And getting this productivity boost knowing I have the OTP and Erlang's concurrency baked in to the environment is a huge plus. -- Jesse Gumm Owner, Sigma Star Systems 414.940.4866 || sigma-star.com || @jessegumm On Feb 22, 2014 6:21 PM, "Michael Truog" wrote: > It appears like this email isn't one I received from the email list, so > other people may not have received it since it was sent through the google > group rather than the normal mailing list ( > http://erlang.org/pipermail/erlang-questions/2014-February/subject.html). > (not sure why the google group method of sending emails isn't working > properly, since I have both set up to deliver emails) > > http://cloudi.org uses CloudI to run the site with cowboy as the HTTP > server > (config at http://cloudi.org/config.html) > > On 02/22/2014 03:55 PM, Steve Davis wrote: > > Smart question. You'd think there'd be 100 answers by now, right? > > On Thursday, February 20, 2014 5:05:25 AM UTC-6, johannes falcone wrote: >> >> anyone got a live erlang powered site I can see? >> >> >> what data store are you using? >> mnesia? >> something else? >> firebirdDB? postgresql? >> > -- > Remember to send a copy to erlang (dot) questions (at) erlang (dot) org > when posting. > --- > You received this message because you are subscribed to the Google Groups > "Erlang Programming" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to erlang-programming+unsubscribe@REDACTED > To post to this group, send email to erlang-programming@REDACTED > Visit this group at http://groups.google.com/group/erlang-programming. > For more options, visit https://groups.google.com/groups/opt_out. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duncan@REDACTED Sun Feb 23 21:10:30 2014 From: duncan@REDACTED (Duncan McGreggor) Date: Sun, 23 Feb 2014 14:10:30 -0600 Subject: [erlang-questions] hows the erlang web framework or library world evolving? In-Reply-To: <53093EFC.1010207@gmail.com> References: <25dd42a4-00b3-49fd-a5a7-d493dc8169f5@googlegroups.com> <53093EFC.1010207@gmail.com> Message-ID: I've been a big fan of YAWS since I saw the original performance announcement in 2006. More recently, several of us in the LFE community have been using it to create REST servers of great beauty and simplicity: https://github.com/lfe/yaws-rest-starter#development YAWS needs to be configured to know where to point, e.g.: appmods = And then you need to define an out/1 function in the module provided to YAWS above. Everything after that is entirely up to you. We couldn't be happier with the combination of simplicity, flexibility, and performance. Not to mention the total ease of use from LFE ;-) d On Sat, Feb 22, 2014 at 6:21 PM, Michael Truog wrote: > It appears like this email isn't one I received from the email list, so > other people may not have received it since it was sent through the google > group rather than the normal mailing list ( > http://erlang.org/pipermail/erlang-questions/2014-February/subject.html). > (not sure why the google group method of sending emails isn't working > properly, since I have both set up to deliver emails) > > http://cloudi.org uses CloudI to run the site with cowboy as the HTTP > server > (config at http://cloudi.org/config.html) > > On 02/22/2014 03:55 PM, Steve Davis wrote: > > Smart question. You'd think there'd be 100 answers by now, right? > > On Thursday, February 20, 2014 5:05:25 AM UTC-6, johannes falcone wrote: >> >> anyone got a live erlang powered site I can see? >> >> >> what data store are you using? >> mnesia? >> something else? >> firebirdDB? postgresql? >> > -- > Remember to send a copy to erlang (dot) questions (at) erlang (dot) org > when posting. > --- > You received this message because you are subscribed to the Google Groups > "Erlang Programming" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to erlang-programming+unsubscribe@REDACTED > To post to this group, send email to erlang-programming@REDACTED > Visit this group at http://groups.google.com/group/erlang-programming. > For more options, visit https://groups.google.com/groups/opt_out. > > > > _______________________________________________ > 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 Feb 23 22:05:13 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 24 Feb 2014 10:05:13 +1300 Subject: [erlang-questions] beta release of merl - metaprogramming in Erlang In-Reply-To: <52F0D50C.6080700@gmail.com> References: <52F0D50C.6080700@gmail.com> Message-ID: <073E8926-1CA9-4763-9B2E-127CB92E5694@cs.otago.ac.nz> On 5/02/2014, at 12:54 AM, Richard Carlsson wrote: > So, I finally got around to releasing Merl to Github NICE! Did you ever look at xoc? From ok@REDACTED Sun Feb 23 22:35:22 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 24 Feb 2014 10:35:22 +1300 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: References: Message-ID: On 23/02/2014, at 12:58 AM, Vlad Dumitrescu wrote: > On 22 Feb 2014 12:43, "Anthony Ramine" wrote: > > > > Erlang is made to be boring. Boring means that it needs to be brain dead easy to comprehend. Brain dead easy means no macros. > > Sorry, but -define () macros can be just as confusing as lispy ones... I would gladly trade them away. Don't forget: Erlang had been around and useful for some time before the preprocessor was added. I used to love the Lisp family. But it's not the only functional syntax. There are functional languages that make Perl look beautiful (O'CAML and F#: I'm thinking of you). There's SML, which would be pretty neat if it had list comprehensions. (Hello, SML? This is the 21st century calling! We have something like list comprehensions in C#. Isn't it about time you caught up?) There's Haskell and Clean. Compare ;; Scheme (define (dot Xs Ys) (let loop ((Xs Xs) (Ys Ys) (S 0)) (if (and (pair? Xs) (pair? Ys)) (loop (cdr Xs) (cdr Ys) (+ S (* (car Xs) (car Ys)))) S))) -- Haskell dot xs ys = loop xs ys 0 where loop (x:xs) (y:ys) s = loop xs ys (s+x*y) loop _ _ s = s %% Erlang dot(Xs, Ys) -> loop(Xs, Ys, 0). loop([X|Xs], [Y|Ys], S) -> loop(Xs, Ys, S + X*Y); loop(_, _, S) -> S. Does anyone else remember my proposal that would have had us write this as dot(Xs, Ys) -> (S where S = 0 then S+X*Y || X <- Xs & Y <- Ys). Historically, Prolog -> Strand-88 -> Erlang. I still don't understand why Erlang uses band bor bnot bsl bsr instead of Prolog's /\ \/ \ << >> (I understand why it can't _now_) and why Erlang reversed the sense of == and =:=. Erlang's syntax hits a "familiarity" sweet spot: - it uses infix operators like Pascal/C/Javascript (unlike Lisp) - it uses f(X, Y, Z) function calls like Pascal/C/Javascript (unlike Haskell) - it uses = for binding a value to a variable, which looks a bit like assignment to a C/Javascript programmer Or rather, it _did_ hit a sweet spot before records and the preprocessor were added. Even then, the preprocessor is aimed squarely at C programmers. -define macros may be (heck, they _are_) even more confusing than lispy ones, but they are confusing in a comfortingly familiar way. From carlsson.richard@REDACTED Sun Feb 23 22:41:12 2014 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Sun, 23 Feb 2014 22:41:12 +0100 Subject: [erlang-questions] beta release of merl - metaprogramming in Erlang In-Reply-To: <073E8926-1CA9-4763-9B2E-127CB92E5694@cs.otago.ac.nz> References: <52F0D50C.6080700@gmail.com> <073E8926-1CA9-4763-9B2E-127CB92E5694@cs.otago.ac.nz> Message-ID: <530A6AF8.1080800@gmail.com> On 2014-02-23 22:05, Richard A. O'Keefe wrote: > > On 5/02/2014, at 12:54 AM, Richard Carlsson wrote: > >> So, I finally got around to releasing Merl to Github > > NICE! Ta! > Did you ever look at xoc? Not that I know. Reference? From ok@REDACTED Sun Feb 23 22:43:33 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 24 Feb 2014 10:43:33 +1300 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: References: <5308E258.1070706@ninenines.eu> Message-ID: <9C757ACC-38F2-4279-A211-F1258B0A87FD@cs.otago.ac.nz> On 23/02/2014, at 10:33 AM, Mikhail Gusarov wrote: >> But when you see unknown function you still have no idea what it does and >> you have to figure it out. Any abstraction works in same way. > > There is subtle difference: all functions conform to the function > abstraction: function does not alter/capture names from calling > namespace and function does not arbitrarily transfer control. Function > is a simple abstraction: it accepts arguments and returns result. There is Lisp. And then there is Scheme. Scheme define-syntax macros do NOT alter/capture names from the calling namespace. They are said to be "hygienic." Thanks to throw/1, function calls CAN transfer control. (The Scheme analogue is call-with-current-continuation.) So a Scheme-flavoured-Erlang would conform to the claimed abstraction every bit as well as Erlang without any kind of macros. From ok@REDACTED Sun Feb 23 23:02:35 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 24 Feb 2014 11:02:35 +1300 Subject: [erlang-questions] beta release of merl - metaprogramming in Erlang In-Reply-To: <530A6AF8.1080800@gmail.com> References: <52F0D50C.6080700@gmail.com> <073E8926-1CA9-4763-9B2E-127CB92E5694@cs.otago.ac.nz> <530A6AF8.1080800@gmail.com> Message-ID: <43BB9808-0FBF-4E80-9BD3-B1F803B48C9F@cs.otago.ac.nz> On 24/02/2014, at 10:41 AM, Richard Carlsson wrote: >> Did you ever look at xoc? > > Not that I know. Reference? -------------------------------------------- An Extension-Oriented Compiler by Russell Stensby Cox PhD thesis submitted to MIT in September 2008. (EE&CS). Abstract: The thesis of this dissertation is that compilers can and should allow programmers to extend programming languages with new syntax, features, and restrictions by writing extension modules that act as plugins for the compiler. We call compilers designed around this idea extension-oriented. The central challenge in designing and building an extension-oriented compiler is the creation of extension interfaces that are simultaneously powerful, to allow effective extensions; convenient, to make these extensions easy to write; and composable, to make it possible to use independently-written extensions together. This dissertation proposes and evaluates extension-oriented syntax trees (XSTs) as a way to meet these challenges. The key interfaces to XSTs are grammar statements, a convenient, composable interface to extend the input parser; syntax patterns, a way to manipulate XSTs in terms of the original program syntax; canonicalizers, which put XSTs into a canonical form to extend the reach of syntax patterns; and attributes, a lazy computation mechanism to structure analyses on XSTs and allow extensions to cooperate. We have implemented these interfaces in a small procedural language called zeta. Using zeta, we have built an extension oriented compiler for C called xoc and then 13 extensions to C ranging in size from 16 lines to 245 lines. To evaluate XSTs and xoc, this dissertation examines two examples in detail: a reimplementation of the programming language Alef and a reimplementation of the Linux kernel checker Sparse. Both of these examples consist of a handful of small extensions used in concert. -------------------------------------------- The Systems Group here have an ongoing project on View-Oriented Parallel Programming, basically a Distributed Shared Memory approach to parallel programming. We were quite keen to use xoc to add syntactic support for this to C. I am still convinced it would be a great tool for the job. Sadly, zeta documentation is largely non-existent. In order to enable the PhD student I wanted to implement this to do so, I would have had to reverse engineer a Zeta manual from the implementation... Oddly enough, I have Masters student this year for whom xoc could have been the perfect tool, had Zeta been documented. The particularly interesting thing about xoc is not just that it lets people write extensions, but the thought that Russell Cox gave to making extensions *work together*, something that is not always straightforward with macros. From tty.erlang@REDACTED Sun Feb 23 23:07:09 2014 From: tty.erlang@REDACTED (T Ty) Date: Sun, 23 Feb 2014 22:07:09 +0000 Subject: [erlang-questions] Distributed System In-Reply-To: References: Message-ID: There might be an interesting new application (Wombat) on Erlang Factory San Francisco this March that might interest you. Usually I would advice using Erlang-2-Erlang communication as it is the easier and fasters means of getting a prototype going. After testing if you find it doesn't fit you can always change to plain sockets. On Tue, Feb 18, 2014 at 3:12 PM, Zoha Qamar wrote: > > Hi , > > I want to implement Clint-server System , which having once admin node > and remaining nodes as clients . The main goal is to implement some > protocol in which admin node can have access to the clients nodes 's > application running on client node . Like for example admin node can start > and stop the functions multiply which are running on my client nodes. > > I read TCP Socket Technique and Distributed Nodes on erlang , these two > methods regarding this . which one is better to implement ? Or is there any > other way to implement this ? > -- > "*Agar Tum Seedhay rastay pe ho aur kisi Mushkil ka samna nahe ker rahay to > kuch dair k liyay socho k kahin tum kuch ghalt to nahe ker rahay kyon k > seedha rasta to mushkilaat se bhar pur hota hy*" *Hazrat Imam Ali (A.S) * > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenji@REDACTED Mon Feb 24 01:52:58 2014 From: kenji@REDACTED (Kenji Rikitake) Date: Mon, 24 Feb 2014 09:52:58 +0900 Subject: [erlang-questions] 17.0 maps documentation? Message-ID: <20140224005258.GA74664@k2r.org> Any plan on when the maps on 17.0 will be documented in OTP distribution? On 17.0-rc1 I could not find it. Kenji Rikitake From kino@REDACTED Mon Feb 24 02:56:55 2014 From: kino@REDACTED (satoshi kinoshita) Date: Mon, 24 Feb 2014 10:56:55 +0900 Subject: [erlang-questions] Fwd: process_info In-Reply-To: References: <530731BB.3070304@erix.ericsson.se> Message-ID: I forgot to reply to the list. ---------- Forwarded message ---------- From: satoshi kinoshita Date: Mon, Feb 24, 2014 at 10:53 AM Subject: Re: [erlang-questions] process_info To: Sverker Eriksson On Fri, Feb 21, 2014 at 8:00 PM, Sverker Eriksson < sverker.eriksson@REDACTED> wrote: > A process has two heaps, one "old" heap with long lived data and a "new" > heap with more recently created data. > > 'heap_size' shows only the size of the new heap. > Newer releases (my git repo goes back to R13B03) contain > a 'total_heap_size' that also include the old heap. > > /Sverker, Erlang/OTP > > Thanks. I checked the same process running on R15B and confirmed that total_heap_size is matching very good with 'memory' size. thank you very much, kinoshita > On 02/21/2014 07:14 AM, satoshi kinoshita wrote: > > Hi, > > I have a question about process_info(). > > For process <0,477,0> below, > heap_size is 6765 words, > stack_size is 12 words and > memory is 40,149,752 bytes. > > Erlang doc says 'memory' includes stack, heap and internal structures. > In this case, stack + heap is 4*(6765+12)=27,108 bytes. > > Does this mean most of memory usage(about 40M bytes) are used > for "internal structures"? > > What is "internal structures"??? > > (I'm still using R11B-5 and I don't know it's specific to R11B-5 or not.) > > > Thanks in advance, > Kinoshita > > ------------------------------------------------------- > (hss1@REDACTED)3> process_info(pid(0,477,0)). > [{registered_name,mgs_db_mgse}, > {current_function,{gen_server,loop,6}}, > {initial_call,{proc_lib,init_p,5}}, > {status,waiting}, > {message_queue_len,0}, > {messages,[]}, > {links,[<0.436.0>]}, > {dictionary,[{'$ancestors',[mgs_db_sup,<0.435.0>]}, > {'$initial_call',{gen,init_it, > [gen_server, > <0.436.0>, > <0.436.0>, > {local,mgs_db_mgse}, > mgs_db_mgse, > [60,0,"mgsen-i+up"], > []]}}]}, > {trap_exit,false}, > {error_handler,error_handler}, > {priority,normal}, > {group_leader,<0.434.0>}, > {heap_size,6765}, > {stack_size,12}, > {reductions,237536590}, > {garbage_collection,[{fullsweep_after,65535}]}] > (hss1@REDACTED)4> process_info(pid(0,477,0),memory). > {memory,40149752} > > ---http://www.erlang.org/documentation/doc-5.5.5/lib/kernel-2.11.5/doc/html/erlang.html-------------- > > {heap_size, Size} > Size is the heap size of the process in words. > > {stack_size, Size} > Size is the stack size of the process in words. > > {memory, Size} > Size is the size of the process in bytes. This includes call > stack, heap and internal structures. > > > > > _______________________________________________ > erlang-questions mailing listerlang-questions@REDACTED://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kino@REDACTED Mon Feb 24 03:00:52 2014 From: kino@REDACTED (satoshi kinoshita) Date: Mon, 24 Feb 2014 11:00:52 +0900 Subject: [erlang-questions] process_info In-Reply-To: <53074624.2040302@erlang.org> References: <530731BB.3070304@erix.ericsson.se> <53074624.2040302@erlang.org> Message-ID: On Fri, Feb 21, 2014 at 9:27 PM, Bj?rn-Egil Dahlberg wrote: > I want to stress that: > NO, we don't use 40 MB for internal structures. > > By internal structure size we mean the size of the C struct for > implementing the process (in 17.0-rc1 this is 792 bytes). > In erlang:process_info(Pid, memory) we also include the size all > heap-fragments, typically messages received that are not yet in any of the > two "real" heaps. > > // Bj?rn-Egil, Erlang/OTP > Hi, I think I understand a bit better now:). The gap includes old_heap and other heap-fragments(which are not yet new or old heap yet). Thank you, Kinoshita -------------- next part -------------- An HTML attachment was scrubbed... URL: From wallentin.dahlberg@REDACTED Mon Feb 24 04:29:02 2014 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Mon, 24 Feb 2014 04:29:02 +0100 Subject: [erlang-questions] 17.0 maps documentation? In-Reply-To: <20140224005258.GA74664@k2r.org> References: <20140224005258.GA74664@k2r.org> Message-ID: It's coming. It is the very next thing on my todo list .. promise. =) Anyway this means it will not be in rc2 but will be in place for the release. Btw, I looked over the documentation for the other types which leads me to believe that I don't have to write that much anyway. =) // Bj?rn-Egil 2014-02-24 1:52 GMT+01:00 Kenji Rikitake : > Any plan on when the maps on 17.0 will be documented in OTP distribution? > On > 17.0-rc1 I could not find it. > > Kenji Rikitake > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duncan@REDACTED Sun Feb 23 23:35:21 2014 From: duncan@REDACTED (Duncan McGreggor) Date: Sun, 23 Feb 2014 16:35:21 -0600 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: <9C757ACC-38F2-4279-A211-F1258B0A87FD@cs.otago.ac.nz> References: <5308E258.1070706@ninenines.eu> <9C757ACC-38F2-4279-A211-F1258B0A87FD@cs.otago.ac.nz> Message-ID: On Sun, Feb 23, 2014 at 3:43 PM, Richard A. O'Keefe wrote: > > On 23/02/2014, at 10:33 AM, Mikhail Gusarov wrote: > > >> But when you see unknown function you still have no idea what it does > and > >> you have to figure it out. Any abstraction works in same way. > > > > There is subtle difference: all functions conform to the function > > abstraction: function does not alter/capture names from calling > > namespace and function does not arbitrarily transfer control. Function > > is a simple abstraction: it accepts arguments and returns result. > > There is Lisp. And then there is Scheme. > > Scheme define-syntax macros do NOT alter/capture names from > the calling namespace. They are said to be "hygienic." > > Thanks to throw/1, function calls CAN transfer control. > (The Scheme analogue is call-with-current-continuation.) > > So a Scheme-flavoured-Erlang would conform to the claimed > abstraction every bit as well as Erlang without any kind of > macros. > LFE has come up a couple of times (yay!), but as for an Erlang Scheme, there is this: https://github.com/the-concurrent-schemer/scm Also, I believe that Joxa is a Lisp-1 (though it does have unhygenic macros). d > > > _______________________________________________ > 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 Mon Feb 24 10:44:18 2014 From: erlang@REDACTED (Andreas Stenius) Date: Mon, 24 Feb 2014 10:44:18 +0100 Subject: [erlang-questions] Library application and it's dependencies Message-ID: Hi, As I've been integrating merl into ErlyDTL, I've come across a practical issue [1]. How do I best package/refer to dependencies from a library application, to make it transparent for users? I seem unable to find a way to do this cleanly which doesn't require the users to adapt their code path. I would like to hear what your opinions are on the matter (hoping I'm missing something obvious). Cheers, Andreas [1] https://github.com/erlydtl/erlydtl/issues/123#issuecomment-35867811 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ponmuthu.m@REDACTED Mon Feb 24 07:34:28 2014 From: ponmuthu.m@REDACTED (PONMUTHU.M) Date: Sun, 23 Feb 2014 22:34:28 -0800 (PST) Subject: [erlang-questions] like erlang all default modules are accessable from anywhere !! Message-ID: <1393223668768-4655374.post@n4.nabble.com> hi, like erlang all default modules are accessable from anywhere, i want my beam files also should be run in linux & windows what kind of path & varaibale havw to set . please guide me ! -- View this message in context: http://erlang.2086793.n4.nabble.com/like-erlang-all-default-modules-are-accessable-from-anywhere-tp4655374.html Sent from the Erlang Questions mailing list archive at Nabble.com. From jesper.louis.andersen@REDACTED Mon Feb 24 12:29:50 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 24 Feb 2014 12:29:50 +0100 Subject: [erlang-questions] like erlang all default modules are accessable from anywhere !! In-Reply-To: <1393223668768-4655374.post@n4.nabble.com> References: <1393223668768-4655374.post@n4.nabble.com> Message-ID: On Mon, Feb 24, 2014 at 7:34 AM, PONMUTHU.M wrote: > like erlang all default modules are accessable from anywhere, i want my > beam files also should be run in linux & windows what kind of path & > varaibale havw to set . > Look at the ERL_LIBS environment variable: erl -man erl erl -man code Alternatively, look at using -pa and -pz as options to 'erl' in order to add new paths to the code load path. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From desired.mta@REDACTED Mon Feb 24 17:06:46 2014 From: desired.mta@REDACTED (=?UTF-8?Q?Motiejus_Jak=C5=A1tys?=) Date: Mon, 24 Feb 2014 17:06:46 +0100 Subject: [erlang-questions] Library application and it's dependencies In-Reply-To: References: Message-ID: On Mon, Feb 24, 2014 at 10:44 AM, Andreas Stenius wrote: > Hi, > > As I've been integrating merl into ErlyDTL, I've come across a practical > issue [1]. > > How do I best package/refer to dependencies from a library application, to > make it transparent for users? > > I seem unable to find a way to do this cleanly which doesn't require the > users to adapt their code path. > > I would like to hear what your opinions are on the matter (hoping I'm > missing something obvious). Don't know if this exactly applies to erlydtl, but these are how projects in rebar handle parse_transforms in dependencies: 1. merl has to be in rebar.config of erlydtl's 2. In deps 'erlydtl' is specified _before_ any application which wants to use it. 2. {erl_first_files, ["src/my_transform_by_merl.erl"]} in rebar.config of erlydtl. -- Motiejus Jak?tys From askjuise@REDACTED Mon Feb 24 19:58:49 2014 From: askjuise@REDACTED (Alexander Petrovsky) Date: Mon, 24 Feb 2014 21:58:49 +0300 Subject: [erlang-questions] httpc and lhttpc streaming, again Message-ID: Hello! Right now for reading twitter stream I use httpc:request, and I would to know, can I use for this purpose lhttpc. Does lhttpc support streaming like httpc? -- ?????????? ????????? / Alexander Petrovsky, Skype: askjuise Phone: +7 914 8 820 815 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Mon Feb 24 20:52:17 2014 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Mon, 24 Feb 2014 20:52:17 +0100 Subject: [erlang-questions] [ANN] BEAM Community was accepted into Google Summer of Code 2014 Message-ID: Hello everyone, This is just a heads up that the BEAM Community has been accepted into Google Summer of Code 2014. If you know students that are interested in taking part of the Summer of Code and are interested in the Erlang VM, please recommend them to take a look at the BEAM Community organization: http://beamcommunity.github.io/ Those who are willing to follow the projects more closely are recommended to join the BEAM Community mailing list, where future announcements and discussions will happen. Thank you! *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Mon Feb 24 21:05:14 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Tue, 25 Feb 2014 00:05:14 +0400 Subject: [erlang-questions] httpc and lhttpc streaming, again In-Reply-To: References: Message-ID: Yes, lhttpc supports streaming for download and upload. It works. On Mon, Feb 24, 2014 at 10:58 PM, Alexander Petrovsky wrote: > Hello! > > Right now for reading twitter stream I use httpc:request, and I would to > know, can I use for this purpose lhttpc. Does lhttpc support streaming like > httpc? > > > -- > ?????????? ????????? / Alexander Petrovsky, > > Skype: askjuise > Phone: +7 914 8 820 815 > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Mon Feb 24 21:17:38 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Mon, 24 Feb 2014 21:17:38 +0100 Subject: [erlang-questions] Library application and it's dependencies In-Reply-To: References: Message-ID: On Mon, Feb 24, 2014 at 5:06 PM, Motiejus Jakstys wrote: > 2. {erl_first_files, ["src/my_transform_by_merl.erl"]} in > rebar.config of erlydtl. You can consider it a rebar bug, if you have to manually list parse transforms in erl_first_files. If that's the case, give the (hopefully soon to be merged) https://github.com/rebar/rebar/pull/129 a try. From tuncer.ayaz@REDACTED Mon Feb 24 21:21:15 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Mon, 24 Feb 2014 21:21:15 +0100 Subject: [erlang-questions] erl_syntax[_lib] error handling Message-ID: erl_syntax and erl_syntax_lib seem to favor throwing exceptions over returning error terms. I found this hard to use due to the missing documenation of what exceptions can be thrown by each function. Only erl_syntax_lib:analyze_application/1 documents one exception it might throw, and the documentation for other funs just states the following: "An exception is thrown if..." The only way to handle erl_syntax[_lib] errors I've seen so far is to catch all exceptions, but that can filter/suppress any kind of exception. What's the recommended way to handle erl_syntax[_lib] errors? From torben.hoffmann@REDACTED Mon Feb 24 21:16:37 2014 From: torben.hoffmann@REDACTED (Torben Hoffmann) Date: Mon, 24 Feb 2014 21:16:37 +0100 Subject: [erlang-questions] How to Name Concurrency Patterns In-Reply-To: References: Message-ID: adg@REDACTED writes: > On Fri, Feb 21, 2014 at 9:22 AM, Torben Hoffmann > wrote: > ... >> We (Jesper and me) are actually working on describing common concurrency patterns for >> Erlang. > > "Erlang Concurrency Patterns" sounds like a great topic for a book - > and maybe it sounds also like a title. > Let's see how many patterns we end up with and what people think of them. Could be that it is only a 50-pager book... :-) Cheers, Torben > -- alfonso -- Torben Hoffmann CTO Erlang Solutions Ltd. Tel: +45 25 14 05 38 http://www.erlang-solutions.com From siraaj@REDACTED Tue Feb 25 00:38:43 2014 From: siraaj@REDACTED (Siraaj Khandkar) Date: Mon, 24 Feb 2014 18:38:43 -0500 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: References: Message-ID: <530BD803.3000103@khandkar.net> On 2/23/14, 4:35 PM, Richard A. O'Keefe wrote: > > On 23/02/2014, at 12:58 AM, Vlad Dumitrescu wrote: >> On 22 Feb 2014 12:43, "Anthony Ramine" wrote: >>> >>> Erlang is made to be boring. Boring means that it needs to be brain dead easy to comprehend. Brain dead easy means no macros. >> >> Sorry, but -define () macros can be just as confusing as lispy ones... I would gladly trade them away. > > Don't forget: Erlang had been around and useful for some time > before the preprocessor was added. > > I used to love the Lisp family. > But it's not the only functional syntax. > There are functional languages that make Perl look beautiful > (O'CAML and F#: I'm thinking of you). > There's SML, which would be pretty neat if it had list > comprehensions. (Hello, SML? This is the 21st century > calling! We have something like list comprehensions in C#. > Isn't it about time you caught up?) > There's Haskell and Clean. > Compare > > ;; Scheme > > (define (dot Xs Ys) > (let loop ((Xs Xs) (Ys Ys) (S 0)) > (if (and (pair? Xs) (pair? Ys)) > (loop (cdr Xs) (cdr Ys) (+ S (* (car Xs) (car Ys)))) > S))) > > -- Haskell > > dot xs ys = loop xs ys 0 > where loop (x:xs) (y:ys) s = loop xs ys (s+x*y) > loop _ _ s = s > > %% Erlang > > dot(Xs, Ys) -> > loop(Xs, Ys, 0). > > loop([X|Xs], [Y|Ys], S) -> > loop(Xs, Ys, S + X*Y); > loop(_, _, S) -> > S. I fail to see the ugliness in: let dot xs ys = let rec loop = function | x::xs, y::ys, s -> loop (xs, ys, s + x * y) | _, _, s -> s in loop (xs, ys, 0) > > Does anyone else remember my proposal that would have had us > write this as > > dot(Xs, Ys) -> > (S where S = 0 then S+X*Y || X <- Xs & Y <- Ys). Where is S coming from here? > > Historically, Prolog -> Strand-88 -> Erlang. > I still don't understand why Erlang uses band bor bnot bsl bsr > instead of Prolog's /\ \/ \ << >> (I understand why it can't > _now_) and why Erlang reversed the sense of == and =:=. > > Erlang's syntax hits a "familiarity" sweet spot: > - it uses infix operators like Pascal/C/Javascript > (unlike Lisp) > - it uses f(X, Y, Z) function calls like Pascal/C/Javascript > (unlike Haskell) > - it uses = for binding a value to a variable, which looks > a bit like assignment to a C/Javascript programmer > > Or rather, it _did_ hit a sweet spot before records and > the preprocessor were added. Even then, the preprocessor > is aimed squarely at C programmers. -define macros may > be (heck, they _are_) even more confusing than lispy ones, > but they are confusing in a comfortingly familiar way. From ok@REDACTED Tue Feb 25 02:36:22 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 25 Feb 2014 14:36:22 +1300 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: <530BD803.3000103@khandkar.net> References: <530BD803.3000103@khandkar.net> Message-ID: On 25/02/2014, at 12:38 PM, Siraaj Khandkar wrote: > I fail to see the ugliness in: > > let dot xs ys = > let rec loop = function > | x::xs, y::ys, s -> loop (xs, ys, s + x * y) > | _, _, s -> s > in > loop (xs, ys, 0) F# syntax is based on CAML. CAML syntax is based on an early revision of ML before the major cleanup that produced SML. (Not unlike the way C perpetuated a blunder that had already been fixed in its ancestor BCPL.) Already in this example it shows up. There are two functions. They have to be declared differently. There are two kinds of lambda expression: fun Pat+ [when Guard] -> Expr may have multiple *arguments* but not multiple *clauses*, while function [|] Pat [when Guard] -> Expr { | Pat [when Guard] -> Expr }... may have multiple *clauses* but not multiple *arguments*. The calls to loop have parentheses around the arguments (to make a tuple, because a function with multiple clauses can't have multiple arguments), but the pattern matches _don't_ have the parentheses. By the way, tuples-without- parentheses are why O'CAML has to use semicolons to separate list elements, unlike practically everything else where commas are used. The outer function 'dot' is declared using a let-binding value_name {parameter}... = expr which allows multiple *arguments* but not multiple *clauses*, which is why the inner function 'loop' *has* to use a lambda-expression. In contrast, here's the same thing in SML. fun dot xs ys = let fun loop (x::xs) (y::ys) s = loop xs ys (s+x*y) | loop _ _ s = s in loop xs ys 0 end In SML, functions can have BOTH multiple arguments and multiple clauses. >> Does anyone else remember my proposal that would have had us >> write this as >> >> dot(Xs, Ys) -> >> (S where S = 0 then S+X*Y || X <- Xs & Y <- Ys). > > Where is S coming from here? From the 'where' part. It's ( where ,... || ) and a is = [then ]. 'let P = E0 in E1' and 'E1 where P = E0' are traditional alternatives in functional programming. It's a cross between Lisp's DO (the part and the part) and comprehensions (the part). From fritchie@REDACTED Tue Feb 25 03:48:24 2014 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Mon, 24 Feb 2014 20:48:24 -0600 Subject: [erlang-questions] Creating a diagnostic memory dump of live erlang VM In-Reply-To: Message of "Wed, 19 Feb 2014 07:49:48 EST." <20140219124947.GC45523@ferdmbp.local> Message-ID: <25456.1393296504@snookles.snookles.com> Hi, all. Basho uses a tool with Riak for gathering post-mortem analysis info without the "mortem" part. That code has been stable for the last year or more, so it hasn't incorporated info & techniques from Fred's nifty diagnostic library. (Yet.) https://github.com/basho/cluster_info And there's also bits to gather these reports from several/all nodes in an Erlang cluster and write them all to the same HTML file. I've used a simple 2-node Riak cluster to generate a report with a single "riak-admin cluster-info" command. It can be found at: http://www.snookles.com/scotttmp/cluster_info.2node.html It's about 1.7MBytes, please be nice to my home HTTP server. :-) There's also a framework for adding application-custom reporting modules. The riak_core & riak_kv applications take (small) advantage of this feature, e.g. https://github.com/basho/riak_core/blob/develop/src/riak_core_cinfo_core.erl https://github.com/basho/riak_kv/blob/develop/src/riak_kv_cinfo.erl The license is Apache Public License v2. I hope that it's liberal enough for any & all to use/modify/study to suit their purposes. Or to study and mutter "Heck, no." ^_^ -Scott From Martin.Henzl@REDACTED Tue Feb 25 09:43:41 2014 From: Martin.Henzl@REDACTED (Henzl, Martin) Date: Tue, 25 Feb 2014 08:43:41 +0000 Subject: [erlang-questions] Cryptographic hardware Message-ID: <7FA433C5E9082444B36E43AF5A18EF0A037285FC@FR44EX3009.global.ds.honeywell.com> Hello, is there any chance that Erlang will support specialized hardware for cryptographic operations and key storage, such as smart cards or security tokens? Currently the private key for SSL must be stored on disk, which is not very secure. Regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Tue Feb 25 13:48:49 2014 From: erlang@REDACTED (Andreas Stenius) Date: Tue, 25 Feb 2014 13:48:49 +0100 Subject: [erlang-questions] Library application and it's dependencies In-Reply-To: References: Message-ID: Thanks for the replies. I'll play around with those options for a bit, see where it lands. 2014-02-24 21:17 GMT+01:00 Tuncer Ayaz : > On Mon, Feb 24, 2014 at 5:06 PM, Motiejus Jakstys wrote: > > > 2. {erl_first_files, ["src/my_transform_by_merl.erl"]} in > > rebar.config of erlydtl. > > You can consider it a rebar bug, if you have to manually list parse > transforms in erl_first_files. If that's the case, give the (hopefully > soon to be merged) https://github.com/rebar/rebar/pull/129 a try. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lego12239@REDACTED Tue Feb 25 14:08:52 2014 From: lego12239@REDACTED (Oleg) Date: Tue, 25 Feb 2014 17:08:52 +0400 Subject: [erlang-questions] list comprehensions speed Message-ID: <20140225130851.GA11738@localhost> Hello. I'm erlang newbie. Don't beat me, please :-), if this question is obvious. I have a list of key-value pairs: A=[{"name1", 1}, {"name2", 77}, {"name3", 33}, {"name4", 234}]. What is faster: [ Value || {Name, Value} <- A, string:equal(Name, "name3")]. Or: get_value(Key, []) -> []. get_value(Key, [H|T]) -> {Name, Value} = H, case string:equal(Name, Key) of true -> [Value]; false -> get_value(Key, T) end. start() -> get_value("name3", A). From desired.mta@REDACTED Tue Feb 25 15:24:35 2014 From: desired.mta@REDACTED (=?UTF-8?B?TW90aWVqdXMgSmFrxaF0eXM=?=) Date: Tue, 25 Feb 2014 15:24:35 +0100 Subject: [erlang-questions] list comprehensions speed In-Reply-To: <20140225130851.GA11738@localhost> References: <20140225130851.GA11738@localhost> Message-ID: <530CA7A3.10105@gmail.com> 2014.02.25 14:08, Oleg ra??: > Hello. > > I'm erlang newbie. Don't beat me, please :-), if this question is obvious. Hi, these questions are best to just test. It's simple: > timer:tc(fun million_list_comprehensions/0). > timer:tc(fun million_get_values/0). You will get a 2-tuple. First element in that tuple will give function execution time in microseconds. Things to have in mind: 1. Put it to module and compile it, do not run from the shell. 2. Make sure to make a loop so it runs more than 10ms (so it actually shows something). 3. Run more than one test for each clause. Have fun! Motiejus From Hal.Snyder@REDACTED Tue Feb 25 15:26:31 2014 From: Hal.Snyder@REDACTED (Snyder, Hal) Date: Tue, 25 Feb 2014 08:26:31 -0600 Subject: [erlang-questions] list comprehensions speed In-Reply-To: <530CA7A3.10105@gmail.com> Message-ID: 4. And tell us what you find out. :-) On 2/25/14 8:24 AM, "Motiejus Jak?tys" wrote: >2014.02.25 14:08, Oleg ra??: >> Hello. >> >> I'm erlang newbie. Don't beat me, please :-), if this question is >>obvious. > >Hi, > >these questions are best to just test. It's simple: > >> timer:tc(fun million_list_comprehensions/0). >> timer:tc(fun million_get_values/0). > >You will get a 2-tuple. First element in that tuple will give function >execution time in microseconds. > >Things to have in mind: >1. Put it to module and compile it, do not run from the shell. >2. Make sure to make a loop so it runs more than 10ms (so it actually >shows something). >3. Run more than one test for each clause. > >Have fun! > >Motiejus >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions From ivan@REDACTED Tue Feb 25 15:28:18 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Tue, 25 Feb 2014 14:28:18 +0000 Subject: [erlang-questions] list comprehensions speed In-Reply-To: <20140225130851.GA11738@localhost> References: <20140225130851.GA11738@localhost> Message-ID: <530CA882.3030101@llaisdy.com> There's also lists:keyfind/3 you could try http://www.erlang.org/doc/man/lists.html#keyfind-3 I think the lists are written in C, so they should be fast. Ivan On 25/02/2014 13:08, Oleg wrote: > Hello. > > I'm erlang newbie. Don't beat me, please :-), if this question is obvious. > > I have a list of key-value pairs: > > A=[{"name1", 1}, {"name2", 77}, {"name3", 33}, {"name4", 234}]. > > What is faster: > > [ Value || {Name, Value} <- A, string:equal(Name, "name3")]. > > Or: > > get_value(Key, []) -> > []. > get_value(Key, [H|T]) -> > {Name, Value} = H, > case string:equal(Name, Key) of > true -> > [Value]; > false -> > get_value(Key, T) > end. > > start() -> > get_value("name3", A). > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From sean@REDACTED Tue Feb 25 15:28:58 2014 From: sean@REDACTED (Sean Cribbs) Date: Tue, 25 Feb 2014 09:28:58 -0500 Subject: [erlang-questions] list comprehensions speed In-Reply-To: <20140225130851.GA11738@localhost> References: <20140225130851.GA11738@localhost> Message-ID: I would do neither of those, there's a BIF just for this purpose: lists:keyfind("name3", 1, A) One could also use the slower, but perhaps easier to understand proplists (lists:keyfind/3 is more general): proplists:get_value("name3", A) If you are not reading the keys for those pairs from the outside world (a file, the network, etc), I'd use atoms instead of strings (just remove the quotes). On Tue, Feb 25, 2014 at 8:08 AM, Oleg wrote: > Hello. > > I'm erlang newbie. Don't beat me, please :-), if this question is obvious. > > I have a list of key-value pairs: > > A=[{"name1", 1}, {"name2", 77}, {"name3", 33}, {"name4", 234}]. > > What is faster: > > [ Value || {Name, Value} <- A, string:equal(Name, "name3")]. > > Or: > > get_value(Key, []) -> > []. > get_value(Key, [H|T]) -> > {Name, Value} = H, > case string:equal(Name, Key) of > true -> > [Value]; > false -> > get_value(Key, T) > end. > > start() -> > get_value("name3", A). > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Tue Feb 25 15:29:32 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Tue, 25 Feb 2014 14:29:32 +0000 Subject: [erlang-questions] list comprehensions speed In-Reply-To: <530CA882.3030101@llaisdy.com> References: <20140225130851.GA11738@localhost> <530CA882.3030101@llaisdy.com> Message-ID: <530CA8CC.6050408@llaisdy.com> Sorry, typo: > I think the functions in the lists module are written in C, so they should be fast. On 25/02/2014 14:28, Ivan Uemlianin wrote: > There's also lists:keyfind/3 you could try > > http://www.erlang.org/doc/man/lists.html#keyfind-3 > > I think the lists are written in C, so they should be fast. > > Ivan > > > On 25/02/2014 13:08, Oleg wrote: >> Hello. >> >> I'm erlang newbie. Don't beat me, please :-), if this question is >> obvious. >> >> I have a list of key-value pairs: >> >> A=[{"name1", 1}, {"name2", 77}, {"name3", 33}, {"name4", 234}]. >> >> What is faster: >> >> [ Value || {Name, Value} <- A, string:equal(Name, "name3")]. >> >> Or: >> >> get_value(Key, []) -> >> []. >> get_value(Key, [H|T]) -> >> {Name, Value} = H, >> case string:equal(Name, Key) of >> true -> >> [Value]; >> false -> >> get_value(Key, T) >> end. >> >> start() -> >> get_value("name3", A). >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From jesper.louis.andersen@REDACTED Tue Feb 25 15:30:13 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 25 Feb 2014 15:30:13 +0100 Subject: [erlang-questions] list comprehensions speed In-Reply-To: <20140225130851.GA11738@localhost> References: <20140225130851.GA11738@localhost> Message-ID: On Tue, Feb 25, 2014 at 2:08 PM, Oleg wrote: > Hello. > Hi Oleg! > > I'm erlang newbie. Don't beat me, please :-), if this question is obvious. > > I have a list of key-value pairs: > > A=[{"name1", 1}, {"name2", 77}, {"name3", 33}, {"name4", 234}]. > > What is faster: > > The way you can figure this out is by following three basic rules: 1. use timer:tc/1 to measure the execution time. 2. Remember to do it in a module which is compiled. The shell interprets. 3. Remember to only measure what you want to measure! https://gist.github.com/jlouis/9209794 has an example. Note that for a 4-element list, the executiion speed doesn't really matter that much. For a 1000 element list, the speed of `lists:keyfind/3` begins to show itself. The reason is that keyfind is a BIF and is implemented in C. Also, like motiejus wrote, you should probably run more than a single run in order to figure out what the best number of rounds are. And remember to call the garbage_collector in between to clean up a bit. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eriksoe@REDACTED Tue Feb 25 15:40:31 2014 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Tue, 25 Feb 2014 15:40:31 +0100 Subject: [erlang-questions] list comprehensions speed In-Reply-To: <20140225130851.GA11738@localhost> References: <20140225130851.GA11738@localhost> Message-ID: Others have given good answers. For completeness, I thought I'd mention this: Your example [ Value || {Name, Value} <- A, string:equal(Name, "name3")]. could be simplified to: [ Value || {"name3", Value} <- A]. Note that both result in a list. Huh. Question to the list: I realize that I don't know how string:equal() differs from using '=:='... The docs don't tell explicitly. Is there a difference? Den 25/02/2014 15.13 skrev "Oleg" : > Hello. > > I'm erlang newbie. Don't beat me, please :-), if this question is obvious. > > I have a list of key-value pairs: > > A=[{"name1", 1}, {"name2", 77}, {"name3", 33}, {"name4", 234}]. > > What is faster: > > [ Value || {Name, Value} <- A, string:equal(Name, "name3")]. > > Or: > > get_value(Key, []) -> > []. > get_value(Key, [H|T]) -> > {Name, Value} = H, > case string:equal(Name, Key) of > true -> > [Value]; > false -> > get_value(Key, T) > end. > > start() -> > get_value("name3", A). > _______________________________________________ > 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 Feb 25 15:43:18 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 25 Feb 2014 15:43:18 +0100 Subject: [erlang-questions] list comprehensions speed In-Reply-To: <20140225130851.GA11738@localhost> References: <20140225130851.GA11738@localhost> Message-ID: <530CAC06.7060706@ninenines.eu> On 02/25/2014 02:08 PM, Oleg wrote: > Hello. > > I'm erlang newbie. Don't beat me, please :-), if this question is obvious. > > I have a list of key-value pairs: > > A=[{"name1", 1}, {"name2", 77}, {"name3", 33}, {"name4", 234}]. > > What is faster: > > [ Value || {Name, Value} <- A, string:equal(Name, "name3")]. This walks through the whole list regardless of "name3" being found yet, and might return more than one value. > Or: > > get_value(Key, []) -> > []. > get_value(Key, [H|T]) -> > {Name, Value} = H, > case string:equal(Name, Key) of > true -> > [Value]; > false -> > get_value(Key, T) > end. > > start() -> > get_value("name3", A). This returns immediately when "name3" is found. It also only returns the first "name3" it finds. This is potentially million times faster depending on the size of the list. As others have pointed out, this is more or less lists:keyfind/3, that I advise you to use. -- Lo?c Hoguin http://ninenines.eu From g@REDACTED Tue Feb 25 16:12:17 2014 From: g@REDACTED (Garrett Smith) Date: Tue, 25 Feb 2014 16:12:17 +0100 Subject: [erlang-questions] list comprehensions speed In-Reply-To: <20140225130851.GA11738@localhost> References: <20140225130851.GA11738@localhost> Message-ID: On Tue, Feb 25, 2014 at 2:08 PM, Oleg wrote: > Hello. > > I'm erlang newbie. Don't beat me, please :-) This is list is typically very docile -- but, for example, if you propose that Ericsson rename list comprehensions to "enumeration generators" to to appeal to Java programmers, well, brace yourself. > I have a list of key-value pairs: > > A=[{"name1", 1}, {"name2", 77}, {"name3", 33}, {"name4", 234}]. > > What is faster: > > [ Value || {Name, Value} <- A, string:equal(Name, "name3")]. > > Or: > > get_value(Key, []) -> > []. > get_value(Key, [H|T]) -> > {Name, Value} = H, > case string:equal(Name, Key) of > true -> > [Value]; > false -> > get_value(Key, T) > end. > > start() -> > get_value("name3", A). I have questions like this all the time. I use this thing to answer my own questions: https://github.com/gar1t/erlang-bench As I've stated emphatically before, these stats, like all stats, lie. *But* they are at least some attempt to measure and test. This particular test I think is similar to what you're looking for: https://github.com/gar1t/erlang-bench/blob/master/name-lookup.escript As Sean Cribbs pointed out, lists:keyfind/2 has super powers. I don't know at under what conditions it makes sense to move from its blazing fast O(N) scans to log(N) hash/tree lookups. Of course this can be tested. As Lo?c Hoguin has pointed out, with zeal, performance characteristics tend to change under system load. I haven't seen what he's seen specifically, but he's very emphatic. And as Richard O'Keefe has pointed out, focus on getting your program to work correctly before worrying about performance. And as Joe Armstrong has pointed out, performance considerations comes after correctness *and* maintainability, except for known performance bottlenecks where it pays to make a compromise. I'd say, get in the habit of answering your own questions when it comes to "speed" -- I suggest playing around with erlang-bench, as it's super fun :) If you come up something interesting as an erlang-bench script, please pass it along as a pull request. Best of luck with your Erlang adventures! Garrett From thomasl_erlang@REDACTED Tue Feb 25 16:22:45 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 25 Feb 2014 07:22:45 -0800 (PST) Subject: [erlang-questions] list comprehensions speed In-Reply-To: <530CA882.3030101@llaisdy.com> References: <20140225130851.GA11738@localhost> <530CA882.3030101@llaisdy.com> Message-ID: <1393341765.18569.YahooMailNeo@web140103.mail.bf1.yahoo.com> As a related point, I wouldn't mind if, say, Hipe or that forthcoming BEAM/JIT compiler generated code similar to C for these sorts of functions. (It would at least be quite interesting if someone investigated codegen for tight-ish loops further. MSc thesis, anyone?)? Basically, less code in C please ... Best, Thomas On Tuesday, February 25, 2014 3:28 PM, Ivan Uemlianin wrote: There's also lists:keyfind/3 you could try > >? http://www.erlang.org/doc/man/lists.html#keyfind-3 > >I think the lists are written in C, so they should be fast. > >Ivan > > >On 25/02/2014 13:08, Oleg wrote: >>? ? Hello. >> >> I'm erlang newbie. Don't beat me, please :-), if this question is obvious. >> >> I have a list of key-value pairs: >> >> A=[{"name1", 1}, {"name2", 77}, {"name3", 33}, {"name4", 234}]. >> >> What is faster: >> >> [ Value || {Name, Value} <- A, string:equal(Name, "name3")]. >> >> Or: >> >> get_value(Key, []) -> >>? ? []. >> get_value(Key, [H|T]) -> >>? ? {Name, Value} = H, >>? ? case string:equal(Name, Key) of >>? ? ? true -> >>? ? ? ? [Value]; >>? ? ? false -> >>? ? ? ? get_value(Key, T) >>? ? end. >> >> start() -> >>? ? get_value("name3", A). >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > >-- >============================================================ >Ivan A. Uemlianin PhD >Llaisdy >Speech Technology Research and Development > >? ? ? ? ? ? ? ? ? ? ivan@REDACTED >? ? ? ? ? ? ? ? ? ? ? www.llaisdy.com >? ? ? ? ? ? ? ? ? ? ? ? ? llaisdy.wordpress.com >? ? ? ? ? ? ? github.com/llaisdy >? ? ? ? ? ? ? ? ? ? ? www.linkedin.com/in/ivanuemlianin > >? ? ? ? ? ? ? ? ? ? ? ? festina lente > >============================================================ >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From egil@REDACTED Tue Feb 25 17:29:28 2014 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Tue, 25 Feb 2014 17:29:28 +0100 Subject: [erlang-questions] list comprehensions speed In-Reply-To: <1393341765.18569.YahooMailNeo@web140103.mail.bf1.yahoo.com> References: <20140225130851.GA11738@localhost> <530CA882.3030101@llaisdy.com> <1393341765.18569.YahooMailNeo@web140103.mail.bf1.yahoo.com> Message-ID: <530CC4E8.4070601@erlang.org> On 2014-02-25 16:22, Thomas Lindgren wrote: > As a related point, I wouldn't mind if, say, Hipe or that forthcoming > BEAM/JIT compiler generated code similar to C for these sorts of > functions. (It would at least be quite interesting if someone > investigated codegen for tight-ish loops further. MSc thesis, anyone?) > > Basically, less code in C please ... I think that is the whole point with a tracing jit =) "Tight-ish" loops gets traced and compiled to native code. Erlangs compiler can only do so much since remote module calls can't be inlined .. the loader could do it but that would in essence move a lot of the compiler to the loader. A jit will solve this with tracing. For all you C lovers .. C can absolutely be fast but "erlang functions implemented in C" has to do pretty much the same work with boxing/unboxing as the VM has to. The gain is less(no) instruction dispatching and it may do clever memory allocation which will speed things up .. but it also can destroy Erlangs soft-real-time properties. Implement your code in Erlang. // Bj?rn-Egil > > Best, > Thomas > > > On Tuesday, February 25, 2014 3:28 PM, Ivan Uemlianin > wrote: > > There's also lists:keyfind/3 you could try > > http://www.erlang.org/doc/man/lists.html#keyfind-3 > > I think the lists are written in C, so they should be fast. > > Ivan > > > On 25/02/2014 13:08, Oleg wrote: > > Hello. > > > > I'm erlang newbie. Don't beat me, please :-), if this question > is obvious. > > > > I have a list of key-value pairs: > > > > A=[{"name1", 1}, {"name2", 77}, {"name3", 33}, {"name4", 234}]. > > > > What is faster: > > > > [ Value || {Name, Value} <- A, string:equal(Name, "name3")]. > > > > Or: > > > > get_value(Key, []) -> > > []. > > get_value(Key, [H|T]) -> > > {Name, Value} = H, > > case string:equal(Name, Key) of > > true -> > > [Value]; > > false -> > > get_value(Key, T) > > end. > > > > start() -> > > get_value("name3", A). > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > ============================================================ > Ivan A. Uemlianin PhD > Llaisdy > Speech Technology Research and Development > > ivan@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > github.com/llaisdy > www.linkedin.com/in/ivanuemlianin > > festina lente > > ============================================================ > _______________________________________________ > 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 lego12239@REDACTED Tue Feb 25 17:33:40 2014 From: lego12239@REDACTED (Oleg) Date: Tue, 25 Feb 2014 20:33:40 +0400 Subject: [erlang-questions] list comprehensions speed In-Reply-To: <7BA27C97-EEF4-4C07-A4C4-B52DA9E41697@gmail.com> References: <20140225130851.GA11738@localhost> <7BA27C97-EEF4-4C07-A4C4-B52DA9E41697@gmail.com> Message-ID: <20140225163340.GA5965@localhost> On Tue, Feb 25, 2014 at 04:22:05PM +0200, Dmitry Kolesnikov wrote: > Hello, > > [ Value || {Name, Value} <- A, Name =:= "name3"]. If we can use =:= for the string matching, why does string module contain equal()? > is faster ;-) > > - Dmitry > From lego12239@REDACTED Tue Feb 25 17:42:32 2014 From: lego12239@REDACTED (Oleg) Date: Tue, 25 Feb 2014 20:42:32 +0400 Subject: [erlang-questions] list comprehensions speed In-Reply-To: References: <20140225130851.GA11738@localhost> Message-ID: <20140225164232.GB5965@localhost> On Tue, Feb 25, 2014 at 09:28:58AM -0500, Sean Cribbs wrote: > I would do neither of those, there's a BIF just for this purpose: > > lists:keyfind("name3", 1, A) > > One could also use the slower, but perhaps easier to understand proplists > (lists:keyfind/3 is more general): > > proplists:get_value("name3", A) > > If you are not reading the keys for those pairs from the outside world (a > file, the network, etc), I'd use atoms instead of strings (just remove the > quotes). Keys and values come from user input. From lego12239@REDACTED Tue Feb 25 18:06:07 2014 From: lego12239@REDACTED (Oleg) Date: Tue, 25 Feb 2014 21:06:07 +0400 Subject: [erlang-questions] list comprehensions speed In-Reply-To: References: <20140225130851.GA11738@localhost> Message-ID: <20140225170607.GC5965@localhost> On Tue, Feb 25, 2014 at 03:30:13PM +0100, Jesper Louis Andersen wrote: > On Tue, Feb 25, 2014 at 2:08 PM, Oleg wrote: > > > Hello. > > > > Hi Oleg! > > > > > > I'm erlang newbie. Don't beat me, please :-), if this question is obvious. > > > > I have a list of key-value pairs: > > > > A=[{"name1", 1}, {"name2", 77}, {"name3", 33}, {"name4", 234}]. > > > > What is faster: > > > > > The way you can figure this out is by following three basic rules: > > 1. use timer:tc/1 to measure the execution time. > 2. Remember to do it in a module which is compiled. The shell interprets. > 3. Remember to only measure what you want to measure! > > https://gist.github.com/jlouis/9209794 Wow. lists:keyfind/3 much faster! Thank you all for answers. From erlang@REDACTED Tue Feb 25 18:44:58 2014 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 25 Feb 2014 18:44:58 +0100 Subject: [erlang-questions] list comprehensions speed In-Reply-To: References: <20140225130851.GA11738@localhost> Message-ID: On Tue, Feb 25, 2014 at 4:12 PM, Garrett Smith wrote: > On Tue, Feb 25, 2014 at 2:08 PM, Oleg wrote: > > Hello. > > > > I'm erlang newbie. Don't beat me, please :-) > > This is list is typically very docile -- but, for example, if you > propose that Ericsson rename list comprehensions to "enumeration > generators" to to appeal to Java programmers, well, brace yourself. > > > I have a list of key-value pairs: > > > > A=[{"name1", 1}, {"name2", 77}, {"name3", 33}, {"name4", 234}]. > > > > What is faster: > > > > [ Value || {Name, Value} <- A, string:equal(Name, "name3")]. > > > > Or: > > > > get_value(Key, []) -> > > []. > > get_value(Key, [H|T]) -> > > {Name, Value} = H, > > case string:equal(Name, Key) of > > true -> > > [Value]; > > false -> > > get_value(Key, T) > > end. > > > > start() -> > > get_value("name3", A). > > I have questions like this all the time. I use this thing to answer my > own questions: > > https://github.com/gar1t/erlang-bench > > As I've stated emphatically before, these stats, like all stats, lie. > *But* they are at least some attempt to measure and test. > > This particular test I think is similar to what you're looking for: > > https://github.com/gar1t/erlang-bench/blob/master/name-lookup.escript > > As Sean Cribbs pointed out, lists:keyfind/2 has super powers. I don't > know at under what conditions it makes sense to move from its blazing > fast O(N) scans to log(N) hash/tree lookups. Of course this can be > tested. > > As Lo?c Hoguin has pointed out, with zeal, performance characteristics > tend to change under system load. I haven't seen what he's seen > specifically, but he's very emphatic. > > And as Richard O'Keefe has pointed out, focus on getting your program > to work correctly before worrying about performance. > > And as Joe Armstrong has pointed out, performance considerations comes > after correctness *and* maintainability, except for known performance > bottlenecks where it pays to make a compromise. > Yes - try the following: Repeat 10 times before meals, and before going to bed. " I must program as inefficiently and beautifully as possible" If the symptoms persist and you feel the need to program efficiently take a cold shower and a brisk bracing walk. Your job is to write beautiful and clear code. It is the compiler writers job to turn clear and beautiful code in quickly executing code. It is the language designers job to design languages that will make it difficult for you to shoot yourself in the foot. If you write clear code and you think it should run quickly and it does not do not optimise the code - tell the compiler writer to fix the compiler/run-time. We will get 1000+ core machines within a few years - they are so bloody fast that we are having problems thinking of what we can use the CPU cycles for so please don't write efficient programs - otherwise we won't need the 1K core machines :-) /Joe > > I'd say, get in the habit of answering your own questions when it > comes to "speed" -- I suggest playing around with erlang-bench, as > it's super fun :) > > If you come up something interesting as an erlang-bench script, please > pass it along as a pull request. > > Best of luck with your Erlang adventures! > > Garrett > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierrefenoll@REDACTED Tue Feb 25 18:44:50 2014 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Tue, 25 Feb 2014 18:44:50 +0100 Subject: [erlang-questions] list comprehensions speed In-Reply-To: <20140225163340.GA5965@localhost> References: <20140225130851.GA11738@localhost> <7BA27C97-EEF4-4C07-A4C4-B52DA9E41697@gmail.com> <20140225163340.GA5965@localhost> Message-ID: On 25 February 2014 17:33, Oleg wrote: > If we can use =:= for the string matching, why does string module contain > equal()? > No idea why the API is such. But here is the definition of string:equal/2: https://github.com/erlang/otp/blob/maint/lib/stdlib/src/string.erl#L68-L76 Cheers, -- Pierre Fenoll -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Tue Feb 25 18:46:35 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Tue, 25 Feb 2014 19:46:35 +0200 Subject: [erlang-questions] list comprehensions speed In-Reply-To: <20140225163340.GA5965@localhost> References: <20140225130851.GA11738@localhost> <7BA27C97-EEF4-4C07-A4C4-B52DA9E41697@gmail.com> <20140225163340.GA5965@localhost> Message-ID: <47B0B609-1DDC-49B3-9821-3EF814ADE173@gmail.com> Becase "name3" is not a string. This is a list. string:equals() is made for abstraction to maintain compatibility. Best Regards, Dmitry >-|-|-(*> > On 25 Feb 2014, at 18:33, Oleg wrote: > >> On Tue, Feb 25, 2014 at 04:22:05PM +0200, Dmitry Kolesnikov wrote: >> Hello, >> >> [ Value || {Name, Value} <- A, Name =:= "name3"]. > > If we can use =:= for the string matching, why does string module contain equal()? > >> is faster ;-) >> >> - Dmitry > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From tuncer.ayaz@REDACTED Tue Feb 25 20:38:17 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 25 Feb 2014 20:38:17 +0100 Subject: [erlang-questions] utils/make_compiler_flags error Message-ID: Does anybody else see the following error when building a fresh otp.git master (98776a4) tree? can't open x86_64-unknown-linux-gnu/opt/plain/erl_compile_flags.h for writing at utils/make_compiler_flags line 65. From vinoski@REDACTED Tue Feb 25 21:06:00 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Tue, 25 Feb 2014 15:06:00 -0500 Subject: [erlang-questions] [erlang-bugs] utils/make_compiler_flags error In-Reply-To: References: Message-ID: On Tue, Feb 25, 2014 at 2:38 PM, Tuncer Ayaz wrote: > Does anybody else see the following error when building a fresh > otp.git master (98776a4) tree? > > can't open x86_64-unknown-linux-gnu/opt/plain/erl_compile_flags.h for > writing at utils/make_compiler_flags line 65. > Yes. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Tue Feb 25 22:06:43 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 26 Feb 2014 10:06:43 +1300 Subject: [erlang-questions] list comprehensions speed In-Reply-To: <20140225130851.GA11738@localhost> References: <20140225130851.GA11738@localhost> Message-ID: <34431E86-8DED-4145-AE54-F88F37418854@cs.otago.ac.nz> On 26/02/2014, at 2:08 AM, Oleg wrote: [which is faster?] You have the code. Why not benchmark it yourself? > Hello. > > I'm erlang newbie. Don't beat me, please :-), if this question is obvious. > > I have a list of key-value pairs: > > A=[{"name1", 1}, {"name2", 77}, {"name3", 33}, {"name4", 234}]. > > What is faster: > > [ Value || {Name, Value} <- A, string:equal(Name, "name3")]. Let's start by observing the string:equal(S, S) -> true; string:equal(_, _) -> false. so this is just [Value || {"name3",Value} <- A] > > Or: > > get_value(Key, []) -> > []. > get_value(Key, [H|T]) -> > {Name, Value} = H, > case string:equal(Name, Key) of > true -> > [Value]; > false -> > get_value(Key, T) > end. And this is just get_value(Key, [{Key,Value}|_]) -> [Value]; get_value(Key, [{_, _ }|T]) -> get_value(Key, T); get_value(_, [] ) -> []. Now I can see that the two approaches do different things. The list comprehension always searches the whole list. get_value/2, however, stops as soon as it finds a match. As a specific example, List = [{"foo",1},{"foo",2}], [Value || {"foo",Value} <- List] answers [1,2] but get_value("foo", List) answers [1]. From ok@REDACTED Tue Feb 25 22:22:45 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 26 Feb 2014 10:22:45 +1300 Subject: [erlang-questions] list comprehensions speed In-Reply-To: <20140225163340.GA5965@localhost> References: <20140225130851.GA11738@localhost> <7BA27C97-EEF4-4C07-A4C4-B52DA9E41697@gmail.com> <20140225163340.GA5965@localhost> Message-ID: On 26/02/2014, at 5:33 AM, Oleg wrote: > If we can use =:= for the string matching, why does string module contain equal()? (1) Abstraction. (2) To have a function that you can pass around. There's a nasty little gotcha in Erlang, which I've never been able to see the point of. In Lisp, I can use #'EQUAL to get the equality function. " SML, " " " op = " " " " " " Haskell, " " " (==) " " " " " In Erlang, there is nothing I can use. You might expect that fun erlang:'=:='/2 or even fun =:= would do the trick. But it doesn't. If you have a function that takes a two-argument "match" predicate, and you want to pass =:= to it, you must have a "real" function. Off-hand, Erlang is the only functional programming language I can recall using in which the built-in operators are NOT built-in functions. From essen@REDACTED Tue Feb 25 22:46:15 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 25 Feb 2014 22:46:15 +0100 Subject: [erlang-questions] list comprehensions speed In-Reply-To: References: <20140225130851.GA11738@localhost> <7BA27C97-EEF4-4C07-A4C4-B52DA9E41697@gmail.com> <20140225163340.GA5965@localhost> Message-ID: <530D0F27.4080808@ninenines.eu> On 02/25/2014 10:22 PM, Richard A. O'Keefe wrote: > > On 26/02/2014, at 5:33 AM, Oleg wrote: > >> If we can use =:= for the string matching, why does string module contain equal()? > > (1) Abstraction. > (2) To have a function that you can pass around. > There's a nasty little gotcha in Erlang, which I've > never been able to see the point of. > > In Lisp, I can use #'EQUAL to get the equality function. > " SML, " " " op = " " " " " > " Haskell, " " " (==) " " " " " > In Erlang, there is nothing I can use. > > You might expect that fun erlang:'=:='/2 or even > fun =:= would do the trick. But it doesn't. If > you have a function that takes a two-argument "match" > predicate, and you want to pass =:= to it, you must > have a "real" function. I'm not sure what you mean by that? 1> F = fun erlang:'=:='/2. #Fun 2> F(1, 1). true -- Lo?c Hoguin http://ninenines.eu From essen@REDACTED Tue Feb 25 22:56:21 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 25 Feb 2014 22:56:21 +0100 Subject: [erlang-questions] byte_size/1 vs variable access Message-ID: <530D1185.8030705@ninenines.eu> Hello, Been wondering something pretty much insignificant recently. When I need the size of a binary I tend to create a variable, say: DataSize = byte_size(Data) and then I reuse this variable in the function. But considering byte_size/1 is O(1) I am wondering if perhaps that's a little pointless. Is it even worth creating a variable for this? Is perhaps the variable optimized out? Perhaps accessing a variable contents and calling byte_size/1 are equivalent operations? Or the GC that will follow is not worth what little is saved by creating a variable in the first place? If someone could shed some light on this perhaps I could stop creating variables like this and simplify my code a little more. Thank you. -- Lo?c Hoguin http://ninenines.eu From bob@REDACTED Tue Feb 25 23:01:32 2014 From: bob@REDACTED (Bob Ippolito) Date: Tue, 25 Feb 2014 14:01:32 -0800 Subject: [erlang-questions] byte_size/1 vs variable access In-Reply-To: <530D1185.8030705@ninenines.eu> References: <530D1185.8030705@ninenines.eu> Message-ID: I don't know about performance implications, but I've found that it's often necessary to work around limitations of bit matching syntax. Here's an example: 1> Foo = <<"asdf">>, FooSize = byte_size(Foo). 4 2> <> = <<"asdfghi">>. * 1: illegal bit size 3> <> = <<"asdfghi">>. <<"asdfghi">> On Tue, Feb 25, 2014 at 1:56 PM, Lo?c Hoguin wrote: > Hello, > > Been wondering something pretty much insignificant recently. > > When I need the size of a binary I tend to create a variable, say: > > DataSize = byte_size(Data) > > and then I reuse this variable in the function. > > But considering byte_size/1 is O(1) I am wondering if perhaps that's a > little pointless. Is it even worth creating a variable for this? Is perhaps > the variable optimized out? Perhaps accessing a variable contents and > calling byte_size/1 are equivalent operations? Or the GC that will follow > is not worth what little is saved by creating a variable in the first place? > > If someone could shed some light on this perhaps I could stop creating > variables like this and simplify my code a little more. > > Thank you. > > -- > 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 ingela.andin@REDACTED Tue Feb 25 23:18:42 2014 From: ingela.andin@REDACTED (Ingela Andin) Date: Tue, 25 Feb 2014 23:18:42 +0100 Subject: [erlang-questions] Cryptographic hardware In-Reply-To: <7FA433C5E9082444B36E43AF5A18EF0A037285FC@FR44EX3009.global.ds.honeywell.com> References: <7FA433C5E9082444B36E43AF5A18EF0A037285FC@FR44EX3009.global.ds.honeywell.com> Message-ID: Hi! Both keys and certificates can be inputed as binaries (DER encoded blobs). Regards Ingela Erlang/OTP team - Ericsson AB 2014-02-25 9:43 GMT+01:00 Henzl, Martin : > Hello, > > > > is there any chance that Erlang will support specialized hardware for > cryptographic operations and key storage, such as smart cards or security > tokens? Currently the private key for SSL must be stored on disk, which is > not very secure. > > > > Regards, > > Martin > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Tue Feb 25 23:24:26 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 26 Feb 2014 11:24:26 +1300 Subject: [erlang-questions] list comprehensions speed In-Reply-To: References: <20140225130851.GA11738@localhost> Message-ID: <2B8002B1-E467-4DD1-B7D7-3EE2780D3AFB@cs.otago.ac.nz> On 26/02/2014, at 6:44 AM, Joe Armstrong wrote: > > > Your job is to write beautiful and clear code. > > It is the compiler writers job to turn clear and beautiful code in quickly executing code. > > It is the language designers job to design languages that will make it difficult for > you to shoot yourself in the foot. We all have experiences that stick in our minds. Here's one of mine. I wanted to have a tokeniser for Prolog written in Prolog. (At the time I was planning to write my own Prolog system so that I could have it on machines other than a DEC-10, PDP-11, or VAX.) So I wrote something fairly clear and straightforward and tested it and it worked. Then I spent a day hacking on it, throwing in every trick I could think of to make it faster. And it ran SLOWER. Just last week, I was looking at someone else's code in a programming language other than Erlang, and there was an obvious way to make it faster. So I used that technique. And it ran SLOWER. In that case, it turned out that the compiler by default generated pretty bad code for arithmetic expressions and if you told it to optimise arithmetic expressions, the result was a 30% speedup. I refrain from naming the language or the compiler, because the compiler shouldn't have been pessimising arithmetic expression evaluation in the first place. The real reason I want to improve that program is that I have already shown the author a refactoring he doesn't like which I think can give at least an O(N) speedup -- as well as making the program shorter and clearer -- but I needed good base benchmarks to be convincing. > > If you write clear code and you think it should run quickly and it does not do not > optimise the code - tell the compiler writer to fix the compiler/run-time. > > We will get 1000+ core machines within a few years Chips with 256 cores exist now. Intel have a lab one. Kalray will sell you a 256-core chip now: http://www.kalray.eu/products/mppa-manycore/mppa-256/ Their "Coolidge" processor with 1024 cores is roadmapped for 2015. That's next year, people. From ok@REDACTED Tue Feb 25 23:26:57 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 26 Feb 2014 11:26:57 +1300 Subject: [erlang-questions] list comprehensions speed In-Reply-To: <530D0F27.4080808@ninenines.eu> References: <20140225130851.GA11738@localhost> <7BA27C97-EEF4-4C07-A4C4-B52DA9E41697@gmail.com> <20140225163340.GA5965@localhost> <530D0F27.4080808@ninenines.eu> Message-ID: <9C3A61E4-7804-4E49-8E4A-012C3E8A020B@cs.otago.ac.nz> On 26/02/2014, at 10:46 AM, Lo?c Hoguin wrote: > > I'm not sure what you mean by that? > > 1> F = fun erlang:'=:='/2. > #Fun > 2> F(1, 1). > true Colour me stupid. When did that come in? From carlsson.richard@REDACTED Tue Feb 25 23:31:21 2014 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Tue, 25 Feb 2014 23:31:21 +0100 Subject: [erlang-questions] list comprehensions speed In-Reply-To: <9C3A61E4-7804-4E49-8E4A-012C3E8A020B@cs.otago.ac.nz> References: <20140225130851.GA11738@localhost> <7BA27C97-EEF4-4C07-A4C4-B52DA9E41697@gmail.com> <20140225163340.GA5965@localhost> <530D0F27.4080808@ninenines.eu> <9C3A61E4-7804-4E49-8E4A-012C3E8A020B@cs.otago.ac.nz> Message-ID: <530D19B9.9090804@gmail.com> On 2014-02-25 23:26, Richard A. O'Keefe wrote: > > On 26/02/2014, at 10:46 AM, Lo?c Hoguin wrote: >> >> I'm not sure what you mean by that? >> >> 1> F = fun erlang:'=:='/2. >> #Fun >> 2> F(1, 1). >> true > > > Colour me stupid. > > When did that come in? Around the time when we made Core Erlang. /RC From drew.varner@REDACTED Tue Feb 25 23:35:22 2014 From: drew.varner@REDACTED (Drew Varner) Date: Tue, 25 Feb 2014 17:35:22 -0500 Subject: [erlang-questions] Cryptographic hardware In-Reply-To: References: <7FA433C5E9082444B36E43AF5A18EF0A037285FC@FR44EX3009.global.ds.honeywell.com> Message-ID: <3F975DD5-482B-4AED-9E48-74ECCA25CD92@redops.org> Martin, It sounds like you are trying to use a hardware security module with Erlang. I?ve looked at this also. I believe there are two common paths, and they both involve interfacing with external libraries. The first is to connect to the device via PKCS#11, which seems to be the most common. Some HSM vendors support access via OpenSSL?s engine interface. Let me know if you develop something along these lines that is open source. Cheers, Drew On Feb 25, 2014, at 5:18 PM, Ingela Andin wrote: > Hi! > > Both keys and certificates can be inputed as binaries (DER encoded blobs). > > Regards Ingela Erlang/OTP team - Ericsson AB > > > 2014-02-25 9:43 GMT+01:00 Henzl, Martin : > Hello, > > > > is there any chance that Erlang will support specialized hardware for cryptographic operations and key storage, such as smart cards or security tokens? Currently the private key for SSL must be stored on disk, which is not very secure. > > > > Regards, > > Martin > > > _______________________________________________ > 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 yoursurrogategod@REDACTED Wed Feb 26 03:36:32 2014 From: yoursurrogategod@REDACTED (yoursurrogategod@REDACTED) Date: Tue, 25 Feb 2014 21:36:32 -0500 Subject: [erlang-questions] Wrong neural net inputs? Message-ID: <36EAAE5B-C939-4383-ABDD-E660B5CE7189@gmail.com> Hi, I'm reading the handbook of neuroevolution through erlang. I got to chapter 2 and figure 2.7. I'm a little confused. It seems that O1 and O2 are mixed up as to which is from what neuron and when I try to calculate (1,1), the result that I get is 1, when it should be -1. Am I totally wrong? Or is there an error in the book? Sent from my iPhone From siraaj@REDACTED Wed Feb 26 04:35:47 2014 From: siraaj@REDACTED (Siraaj Khandkar) Date: Tue, 25 Feb 2014 22:35:47 -0500 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: References: <530BD803.3000103@khandkar.net> Message-ID: <530D6113.20009@khandkar.net> On 2/24/14, 8:36 PM, Richard A. O'Keefe wrote: > > On 25/02/2014, at 12:38 PM, Siraaj Khandkar wrote: >> I fail to see the ugliness in: >> >> let dot xs ys = >> let rec loop = function >> | x::xs, y::ys, s -> loop (xs, ys, s + x * y) >> | _, _, s -> s >> in >> loop (xs, ys, 0) > > F# syntax is based on CAML. The above example is in OCaml, on which F# syntax was initially based on, not directly on Caml (which preceded OCaml). http://ocaml.org/learn/history.html > CAML syntax is based on an early revision of ML > before the major cleanup that produced SML. Yes. > (Not unlike the way C perpetuated a blunder > that had already been fixed in its ancestor BCPL.) > > Already in this example it shows up. > There are two functions. > They have to be declared differently. They _can_ but don't _have_ to be. I chose to write it that way to match your examples most closely. Personally, I would rather write it as: let dot xs ys = let rec loop xs ys s = match xs, ys with | [], [] -> s | x::xs, y::ys -> loop xs ys (s + x * y) | _, _ -> assert false in loop xs ys 0 or better yet, using stdlib: let dot = List.fold_left2 (fun s x y -> s + x * y) 0 > > There are two kinds of lambda expression: > > fun Pat+ [when Guard] -> Expr > > may have multiple *arguments* but not multiple *clauses*, > while > > function [|] Pat [when Guard] -> Expr > { | Pat [when Guard] -> Expr }... > > may have multiple *clauses* but not multiple *arguments*. > > The calls to loop have parentheses around the arguments > (to make a tuple, because a function with multiple clauses > can't have multiple arguments), but the pattern matches > _don't_ have the parentheses. This describes the form, but does not make any judgements. Why is that so terrible? I don't see the problem. Sure, I can entertain the idea that having an additional form can be seen as less than perfectly symmetric, but it is still far from the extreme negativity that you cast when speaking of OCaml (saying it is uglier than Perl is about as extreme as it gets). There's never a situation where one _has_ to use the form "function" over "fun", it is provided merely as an alternative that you _may_ find convenient at times. > By the way, tuples-without- > parentheses are why O'CAML has to use semicolons to > separate list elements, unlike practically everything else > where commas are used. "unlike practically everything else" is a really weak statement on an Erlang mailing list ;) > The outer function 'dot' is declared using a let-binding > value_name {parameter}... = expr > which allows multiple *arguments* but not multiple > *clauses*, which is why the inner function 'loop' > *has* to use a lambda-expression. Again, it doesn't *have* to, but sometimes it is convenient. Though, frankly, I'm not fully satisfied with function declaration in any language that I'm familiar with so far. I mostly lean toward the way it is done in OCaml, because it reinforces the idea that a function is no different from any other value, so you bind it to a name in exactly the same way (let name = expr), where as in SML there's a distinction between (val name = expr) and (fun name arg1 .. argn = expr). Ideally, I'd probably keep only the "fun" lambda expression form (and add clauses), because why should there ever be a distinction between a function declaration and a lambda expression? A named function is just a lambda attached to a name, after all... And, before you bring it up as a gold standard, I find Haskell's way quite unsatisfactory as well. Primarily in two ways: 1) all bindings are _implicitly_ recursive and 2) no shadowing (which I know, from other discussions, that you hate, but that is a preference...). > In contrast, here's the same thing in SML. > > fun dot xs ys = > let fun loop (x::xs) (y::ys) s = loop xs ys (s+x*y) > | loop _ _ s = s > in loop xs ys 0 > end > > In SML, functions can have BOTH multiple arguments and > multiple clauses. But not guards... As a user of both languages, I generally agree - SML is the more elegantly designed language [1]. It was designed to be so, where as OCaml evolved more organically (much like Erlang has), as a tool for implementation of Coq, without a formal definition, but nonetheless rigorously worked out theory behind the language additions. There has been a lot of interesting progress in both, the OCaml language and ecosystem, since the last time you seriously looked at it (which I can only imagine must have been a while): - recursive modules - private types (which differ from abstract types by allowing reading but still not constructing the representation) - locally abstract types (which allow "shared secrets", that Harper said were only possible in SML [2]) - first-class modules - GADTs! - a really awesome package manager [3] More here: http://caml.inria.fr/pub/docs/manual-ocaml-400/manual021.html [1]: Though I do find some things unpleasant, mainly the lack of syntactic distinction between constructors and identifiers. [2]: http://existentialtype.wordpress.com/2012/12/03/exceptions-are-shared-secrets [3]: https://opam.ocaml.org >>> Does anyone else remember my proposal that would have had us >>> write this as >>> >>> dot(Xs, Ys) -> >>> (S where S = 0 then S+X*Y || X <- Xs & Y <- Ys). >> >> Where is S coming from here? > > From the 'where' part. It's > ( where ,... || ) > and a is > = [then ]. > > 'let P = E0 in E1' and 'E1 where P = E0' are traditional > alternatives in functional programming. > > It's a cross between Lisp's DO (the part and the > part) and comprehensions (the part). I really like the idea of being able to express "X <- Xs & Y <- Ys", but, even with the explanation, I still find the left hand side quite unintuitive. From corticalcomputer@REDACTED Wed Feb 26 05:13:03 2014 From: corticalcomputer@REDACTED (Gene Sher) Date: Tue, 25 Feb 2014 23:13:03 -0500 Subject: [erlang-questions] Wrong neural net inputs? In-Reply-To: <36EAAE5B-C939-4383-ABDD-E660B5CE7189@gmail.com> References: <36EAAE5B-C939-4383-ABDD-E660B5CE7189@gmail.com> Message-ID: Hi, I think you found a small error. I've looked at the numbers and it does seem to be an oversight. Thanks, I'll have it corrected. Best regards, -Gene On Tue, Feb 25, 2014 at 9:36 PM, yoursurrogategod@REDACTED < yoursurrogategod@REDACTED> wrote: > Hi, > > I'm reading the handbook of neuroevolution through erlang. I got to > chapter 2 and figure 2.7. I'm a little confused. It seems that O1 and O2 > are mixed up as to which is from what neuron and when I try to calculate > (1,1), the result that I get is 1, when it should be -1. > > Am I totally wrong? Or is there an error in the book? > > Sent from my iPhone > _______________________________________________ > 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 Wed Feb 26 06:06:11 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 26 Feb 2014 18:06:11 +1300 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: <530D6113.20009@khandkar.net> References: <530BD803.3000103@khandkar.net> <530D6113.20009@khandkar.net> Message-ID: <4F318D7A-5326-4B28-AC39-AEB81CB14C06@cs.otago.ac.nz> On 26/02/2014, at 4:35 PM, Siraaj Khandkar wrote: Let's put it this way: the issues I discussed were (a) verified using the latest available O'CAML manual and (b) amongst but far from the only features of O'CAML that had me unable to bear to use it. O'CAML has always been famed for the excellent performance of its compiler, and I used to cherish a daydream of using its preprocessing facilities to give it a syntax I liked.. F# has a number of merits -- which is why I have it on my machine -- including native threads and some very interesting innovations. It actually has two syntaxes. The syntax is, however, very complex. >> There are two kinds of lambda expression: >> >> fun Pat+ [when Guard] -> Expr >> >> may have multiple *arguments* but not multiple *clauses*, >> while >> >> function [|] Pat [when Guard] -> Expr >> { | Pat [when Guard] -> Expr }... >> >> may have multiple *clauses* but not multiple *arguments*. >> >> The calls to loop have parentheses around the arguments >> (to make a tuple, because a function with multiple clauses >> can't have multiple arguments), but the pattern matches >> _don't_ have the parentheses. > > This describes the form, but does not make any judgements. Why is that > so terrible? I don't see the problem. Surely nobody expects a syntax to be _capable_ of making judgements. I don't understand you here. The problem is having two different ways to do the same kind of thing, both of them crippled, and neither having a name that reminds you of the direction of its crippling. Back when I was trying to write O'CAML, I banged my head on this over and over again: I wanted to write one simple function with - no tuples, - multiple arguments, and - multiple clauses. Here's a simple little Erlang function: fun (a, b) -> 1 ; (a, _) -> 2 ; (_, b) -> 3 ; (_, _) -> 4 end Writing that is not simple in O'CAML, and there doesn't seem to be any *REASON* for the restrictions. > Sure, I can entertain the idea that having an additional form can be > seen as less than perfectly symmetric, We're not talking about "less than perfect", we are talking about *unmotivated crippling*. We're talking about having to remember than 'fun' does multi-arg but not multi-case and 'function' does multi-case but not multi-arg. (If 'function' were spelled 'matchfun' it would then *obvious* which one was like 'match' and which wasn't.) > There's never a > situation where one _has_ to use the form "function" over "fun", it is > provided merely as an alternative that you _may_ find convenient at > times. No, 'function' is not "merely an alternative". 'fun' and 'function' do _different_ things, and neither of them does a full job. Let's look back at that little Erlang function. The closest I can come in O'CAML is fun x y -> match x with | A -> match y with | B -> 1 | _ -> 2 | _ -> match y with | B -> 3 | _ -> 4 If I'm going to have to twist my head around something complicated in a language, I'd rather it was something like type families than pointlessly restrictive syntax. > > Though, frankly, I'm not fully satisfied with function declaration in > any language that I'm familiar with so far. I mostly lean toward the way > it is done in OCaml, because it reinforces the idea that a function is > no different from any other value, so you bind it to a name in exactly > the same way (let name = expr), where as in SML there's a distinction > between (val name = expr) and (fun name arg1 .. argn = expr). But in SML nothing stops you writing val f = fun ... -> ... if you want to. Turning your own words against you, 'fun' in SML is "merely an alternative syntax that you may find convenient". > And, before you bring it up as a gold standard, I find Haskell's way > quite unsatisfactory as well. Primarily in two ways: 1) all bindings are > _implicitly_ recursive and 2) no shadowing (which I know, from other > discussions, that you hate, but that is a preference...). The implicit recursive bit -- which is what we also have in Erlang -- is in practice what I always want, and it is strongly connected with the free order of function definitions -- which we also have in Erlang. _Not_ having to have a weird special form for declaring a group of mutually recursive functions is one of the things that had me running from SML to Haskell (and Erlang!). > There has been a lot of interesting progress in both, the OCaml > language and ecosystem, since the last time you seriously looked at it > (which I can only imagine must have been a while): There are some incredibly interesting tools I would like to use that are written in O'CAML. I even went to the trouble of setting up a special VirtualBox VM running a specific version of Linux to run one of them. That was last year. > > - recursive modules > - private types (which differ from abstract types by allowing reading > but still not constructing the representation) > - locally abstract types (which allow "shared secrets", that Harper > said were only possible in SML [2]) > - first-class modules > - GADTs! > - a really awesome package manager [3] Those are all nice things, although I note that the Goedel programming language had GADTs back in the 1980s -- mainly because John Lloyd couldn't think of a reason _not_ to offer them. He wasn't aware of the type inference issues they cause, but since Goedel did type checking, not type inference, that wouldn't have been a problem anyway. I have kept going back to O'CAML because of the fantastic things that have been done with it, but I have really really bad memories of GODI. If OPAM lets me forget about GODI, I may try O'CAML again. >>>> (S where S = 0 then S+X*Y || X <- Xs & Y <- Ys). >>> >>> Where is S coming from here? >> >> From the 'where' part. It's >> ( where ,... || ) >> and a is >> = [then ]. >> >> 'let P = E0 in E1' and 'E1 where P = E0' are traditional >> alternatives in functional programming. >> >> It's a cross between Lisp's DO (the part and the >> part) and comprehensions (the part). > > I really like the idea of being able to express "X <- Xs & Y <- Ys", > but, even with the explanation, I still find the left hand side quite > unintuitive. Familiarity again. First, multiple generators in parallel is a straight steal from Clean. Second, where was back in Landin's "The next 700 programming languages" paper and has appeared in several programming languages since ISWIM. The proposed syntax has (Expression where Matches) as a special case. Having used both 'let' and 'where' in Haskell, I find that roots a b c = (-b + sqrt discrim)/(2*a) where discrim = b^2 - 4*a*c reads better than roots a bc = let discrim = b^2 - 4*a*c in (-b + sqrt discrim)/(2*a) In Haskell, 'let' and 'where' do slightly different things ('let' is local to an expression, 'where' goes with a group of guarded alternatives in the same clause). I tried (let [while ] [|| ] in ) but found that it was more awkward. What really matters is that we _could_ have a form that does for fold+map+filter what list comprehensions do for map+filter. From magnus.mueller@REDACTED Wed Feb 26 08:46:45 2014 From: magnus.mueller@REDACTED (Magnus Mueller) Date: Wed, 26 Feb 2014 07:46:45 +0000 Subject: [erlang-questions] infrequent socket_closed_remotely errors with httpc In-Reply-To: References: Message-ID: Switching to HTTP/1.0 seems to work around our issue as well. This is not really satisfying, but should work for our use case. Magnus ---------------------------------------------- Von: Shayan Pooya [mailto:shayan@REDACTED] Gesendet: Freitag, 21. Februar 2014 06:34 An: Magnus Mueller Cc: erlang-questions@REDACTED; Johannes Wei?l; Sebastian Egner Betreff: Re: [erlang-questions] infrequent socket_closed_remotely errors with httpc On Thu, Feb 20, 2014 at 8:31 AM, Magnus Mueller wrote: Hello. We are struggling with a hard-to-reproduce problem with httpc were we sometimes encounter `{error,socket_closed_remotely}` when querying our simple webserver. Sometimes this happens with yaws as well. The error happens very infrequently and is thus hard to reproduce. Both the webserver and httpc run in the same VM (which might be the cause of the problem). Interestingly, the problem is more likely to occur if the system is under cpu-heavy load, e.g. when using stress[1]: ? ? stress --cpu 6 Did anybody of you encounter similar problems? We are running out of ideas and I could not yet come up with a small example to reproduce the issue. Magnus [1] https://web.archive.org/web/20130520190152/http://weather.ou.edu/~apw/projects/stress/ , the original website seems to be down. _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions There was a discussion about this last week (http://erlang.org/pipermail/erlang-questions/2014-February/077370.html). We had a somehow similar issue in Disco, and we worked around it by switching back to HTTP/1.0. Regards. From vychodil.hynek@REDACTED Wed Feb 26 10:29:25 2014 From: vychodil.hynek@REDACTED (Hynek Vychodil) Date: Wed, 26 Feb 2014 10:29:25 +0100 Subject: [erlang-questions] atoms with newlines In-Reply-To: <6B6D7CCC-E823-44A9-B7D9-7268C4CFAEC9@cs.otago.ac.nz> References: <3D506AA6-D4E1-4887-B76B-51FA12BCF353@cs.otago.ac.nz> <6B6D7CCC-E823-44A9-B7D9-7268C4CFAEC9@cs.otago.ac.nz> Message-ID: I fully agree with Richard. Backslash is escape character and it should escape next character so this newline should be omitted. It is definitely bug and unexpected behavior. With best regards Hynek Vychodil On Tue, Feb 18, 2014 at 11:57 PM, Richard A. O'Keefe wrote: > > On 19/02/2014, at 10:33 AM, Vlad Dumitrescu wrote: > > Eshell V5.10.4 (abort with ^G) > > 1> 'foo\n\ > > 1> bar'. > > 'foo\n\nbar' > > > > I had expected that would > > - be rejected as a syntax error, or > > - be discarded like in C and Prolog. > > > > I did _not_ expect it to turn into . > > > > > > Actually, what I was referring to was that that last backslash isn't > really needed at all. > > No, the last backslash IS needed because I *don't* want > the newline. In ISO Prolog I can write > |p('foo\| > |bar\| > |zoo').'| > where the vertical bars show record boundaries, > and get the same effect as > |p('foobarzoo').| > > You are concerned about atoms that include newline characters. > I am concerned about atoms that for one reason or another > need to be split over lines WITHOUT introducing newline characters. > > I just want \ to work sensibly and to be so documented. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valentin@REDACTED Wed Feb 26 10:56:14 2014 From: valentin@REDACTED (Valentin Micic) Date: Wed, 26 Feb 2014 11:56:14 +0200 Subject: [erlang-questions] atoms with newlines In-Reply-To: References: <3D506AA6-D4E1-4887-B76B-51FA12BCF353@cs.otago.ac.nz> <6B6D7CCC-E823-44A9-B7D9-7268C4CFAEC9@cs.otago.ac.nz> Message-ID: If this is *really* necessary, wouldn't it be less confusing (or even more consistent) to consider: 1> 'foo' \ 1> 'bar'. foobar 2> whereas: 3> 'foo 3>bar' 'foo\nbar' 4> includes a new line -- as already does. Kind regards V/ On 26 Feb 2014, at 11:29 AM, Hynek Vychodil wrote: > I fully agree with Richard. Backslash is escape character and it should escape next character so this newline should be omitted. It is definitely bug and unexpected behavior. > > With best regards > Hynek Vychodil > > > On Tue, Feb 18, 2014 at 11:57 PM, Richard A. O'Keefe wrote: > > On 19/02/2014, at 10:33 AM, Vlad Dumitrescu wrote: > > Eshell V5.10.4 (abort with ^G) > > 1> 'foo\n\ > > 1> bar'. > > 'foo\n\nbar' > > > > I had expected that would > > - be rejected as a syntax error, or > > - be discarded like in C and Prolog. > > > > I did _not_ expect it to turn into . > > > > > > Actually, what I was referring to was that that last backslash isn't really needed at all. > > No, the last backslash IS needed because I *don't* want > the newline. In ISO Prolog I can write > |p('foo\| > |bar\| > |zoo').'| > where the vertical bars show record boundaries, > and get the same effect as > |p('foobarzoo').| > > You are concerned about atoms that include newline characters. > I am concerned about atoms that for one reason or another > need to be split over lines WITHOUT introducing newline characters. > > I just want \ to work sensibly and to be so documented. > > > > _______________________________________________ > 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 lcastro@REDACTED Wed Feb 26 11:34:25 2014 From: lcastro@REDACTED (Laura M. Castro) Date: Wed, 26 Feb 2014 11:34:25 +0100 Subject: [erlang-questions] Call For Papers: Erlang Workshop 2014 Message-ID: Hello all, Please find below the First Call for Papers for the Thirteenth ACM SIGPLAN Erlang Workshop. Apologies for any duplicates you may receive. CALL FOR PAPERS =============== Thirteenth ACM SIGPLAN Erlang Workshop ----------------------------------------------------------- G?teborg, Sweden, September 5, 2014 Satellite event of the 19th ACM SIGPLAN International Conference on Functional Programming (ICFP 2014) September 1-3, 2014 http://www.erlang.org/workshop/2014 Erlang is a concurrent, distributed functional programming language aimed at systems with requirements of massive concurrency, soft real time response, fault tolerance, and high availability. It has been available as open source for 15 years, creating a community that actively contributes to its already existing rich set of libraries and applications. Originally created for telecom applications, its usage has spread to other domains including e-commerce, banking, databases, and computer telephony and messaging. Erlang programs are today among the largest applications written in any functional programming language. These applications offer new opportunities to evaluate functional programming and functional programming methods on a very large scale and suggest new problems for the research community to solve. This workshop will bring together the open source, academic, and industrial programming communities of Erlang. It will enable participants to familiarize themselves with recent developments on new techniques and tools tailored to Erlang, novel applications, draw lessons from users' experiences and identify research problems and common areas relevant to the practice of Erlang and functional programming. We invite three types of submissions. 1. Technical papers describing language extensions, critical discussions of the status quo, formal semantics of language constructs, program analysis and transformation, virtual machine extensions and compilation techniques, implementations and interfaces of Erlang in/with other languages, and new tools (profilers, tracers, debuggers, testing frameworks, etc.). The maximum length for technical papers is restricted to 12 pages. 2. Practice and application papers describing uses of Erlang in the "real-world", Erlang libraries for specific tasks, experiences from using Erlang in specific application domains, reusable programming idioms and elegant new ways of using Erlang to approach or solve a particular problem. The maximum length for the practice and application papers is restricted to 12 pages. Note that this is a maximum length; we welcome shorter papers also, and the program committee will evaluate all papers on an equal basis independent of their lengths. 3. Poster presentations describing topics related to the workshop goals. Each includes a maximum of 2 pages of the abstract and summary. Presentations in this category will be given an hour of shared simultaneous demonstration time. Workshop Co-Chairs ------------------ Laura M. Castro, University of A Coru?a, Spain Hans Svensson, QuviQ AB, Sweden Program Committee ----------------------------- (Note: the Workshop Co-Chairs are also committee members) Jesper L. Andersen, Erlang Solutions Ltd., UK Richard Carlsson, Klarna AB, Sweden Lars-?ke Fredlund, Universidad Polit?cnica de Madrid, Spain Fr?d H?bert, Heroku, USA Kostis Sagonas, Uppsala University, Sweden & NTUA, Greece Simon Thompson, University of Kent, UK Steve Vinoski, Basho Technologies, USA Philip Wadler, University of Edinburgh, UK Important Dates ----------------------- Submissions due: Sunday, 11 May, 2014 Author notification: Friday, 6 June, 2014 Final copy due: Sunday, 22 June, 2014 Workshop date: September 5, 2014 Instructions to authors -------------------------------- Papers must be submitted online via EasyChair (via the "Erlang2014" event). The submission page is https://www.easychair.org/conferences/?conf=erlang2014 Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Each submission must adhere to SIGPLAN's republication policy. Violation risks summary rejection of the offending submission. Accepted papers will be published by the ACM and will appear in the ACM Digital Library. Paper submissions will be considered for poster submission in the case they are not accepted as full papers. Venue & Registration Details ------------------------------------------ For registration, please see the ICFP 2014 web site at: http://icfpconference.org/icfp2014/ Related Links -------------------- ICFP 2014 web site: http://www.icfpconference.org/icfp2014/ Past ACM SIGPLAN Erlang workshops: http://www.erlang.org/workshop/ Open Source Erlang: http://www.erlang.org/ EasyChair submission site: https://www.easychair.org/conferences/?conf=erlang2014 Author Information for SIGPLAN Conferences: http://www.sigplan.org/authorInformation.htm Atendee Information for SIGPLAN Events: http://www.sigplan.org/Resources/Policies/Anti-harassment -- Laura M. Castro Department of Computer Science Universidade da Coru?a (Spain) http://www.madsgroup.org/staff/laura From bjorn@REDACTED Wed Feb 26 12:36:54 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 26 Feb 2014 12:36:54 +0100 Subject: [erlang-questions] [erlang-bugs] utils/make_compiler_flags error In-Reply-To: References: Message-ID: On Tue, Feb 25, 2014 at 8:38 PM, Tuncer Ayaz wrote: > Does anybody else see the following error when building a fresh > otp.git master (98776a4) tree? > > can't open x86_64-unknown-linux-gnu/opt/plain/erl_compile_flags.h for > writing at utils/make_compiler_flags line 65. Thanks for noticing this! As far as I can tell, this annoying error message is harmless. The script is executed everytime the Makefile is run, and the first time the directories have not been created yet, so it fails. The second time the Makefile is run (when doing the actual build), the script will succeed silently. It is too late for the rc2 release, but we will try to fix for the final 17.0 release. If anyone wants to fix it, patches are welcome. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bjorn@REDACTED Wed Feb 26 12:46:49 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 26 Feb 2014 12:46:49 +0100 Subject: [erlang-questions] byte_size/1 vs variable access In-Reply-To: <530D1185.8030705@ninenines.eu> References: <530D1185.8030705@ninenines.eu> Message-ID: On Tue, Feb 25, 2014 at 10:56 PM, Lo?c Hoguin wrote: > But considering byte_size/1 is O(1) I am wondering if perhaps that's a > little pointless. Is it even worth creating a variable for this? Is perhaps > the variable optimized out? Perhaps accessing a variable contents and > calling byte_size/1 are equivalent operations? Or the GC that will follow is > not worth what little is saved by creating a variable in the first place? > > If someone could shed some light on this perhaps I could stop creating > variables like this and simplify my code a little more. > There is definitely more overhead calling a BIF than accessing a variable. That said, I doubt that you will be able to notice the difference in a real program. So I suggest that you write in the way that you find most readable. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From n.oxyde@REDACTED Wed Feb 26 13:26:12 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 26 Feb 2014 13:26:12 +0100 Subject: [erlang-questions] [erlang-bugs] utils/make_compiler_flags error In-Reply-To: References: Message-ID: <2FE8322F-CADD-4589-B6F2-826D50279048@gmail.com> That bug was already reported and Lukas Larsson had written a fix: https://github.com/garazdawi/otp/tree/lukas/erts/make_deps_fixes Regards, -- Anthony Ramine Le 26 f?vr. 2014 ? 12:36, Bj?rn Gustavsson a ?crit : > On Tue, Feb 25, 2014 at 8:38 PM, Tuncer Ayaz wrote: >> Does anybody else see the following error when building a fresh >> otp.git master (98776a4) tree? >> >> can't open x86_64-unknown-linux-gnu/opt/plain/erl_compile_flags.h for >> writing at utils/make_compiler_flags line 65. > > Thanks for noticing this! > > As far as I can tell, this annoying error message is harmless. > The script is executed everytime the Makefile is run, and the first > time the directories have not been created yet, so it fails. The second > time the Makefile is run (when doing the actual build), the script will > succeed silently. > > It is too late for the rc2 release, but we will try to fix for the > final 17.0 release. > > If anyone wants to fix it, patches are welcome. > > /Bjorn > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From essen@REDACTED Wed Feb 26 13:42:29 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 26 Feb 2014 13:42:29 +0100 Subject: [erlang-questions] byte_size/1 vs variable access In-Reply-To: References: <530D1185.8030705@ninenines.eu> Message-ID: <530DE135.9040507@ninenines.eu> Thanks. Is there any optimization when it's done inside a function clause guard? For example say, 5 of my 6 clauses need to check byte_size(Bin) to decide what to do. I am reading some code I wrote a few days ago and I see I instinctively used a single clause, creating a variable to hold the size and then used a if inside it. Perhaps the compiler is doing something about it in this case? I know it doesn't matter 99% of the time, but I got one or two modules that deal with binaries where the smallest improvement means I can handle a bunch more traffic. To be honest it would be really nice if the compiler would automatically create a variable when it sees me use byte_size/1 more than once as I can then stop writing all this extra code. And I'm guessing it could probably do the same with length/1 and others. On 02/26/2014 12:46 PM, Bj?rn Gustavsson wrote: > On Tue, Feb 25, 2014 at 10:56 PM, Lo?c Hoguin wrote: > >> But considering byte_size/1 is O(1) I am wondering if perhaps that's a >> little pointless. Is it even worth creating a variable for this? Is perhaps >> the variable optimized out? Perhaps accessing a variable contents and >> calling byte_size/1 are equivalent operations? Or the GC that will follow is >> not worth what little is saved by creating a variable in the first place? >> >> If someone could shed some light on this perhaps I could stop creating >> variables like this and simplify my code a little more. >> > > There is definitely more overhead calling a BIF than accessing a variable. > > That said, I doubt that you will be able to notice the difference in a > real program. > So I suggest that you write in the way that you find most readable. > > /Bjorn > -- Lo?c Hoguin http://ninenines.eu From bjorn@REDACTED Wed Feb 26 14:30:47 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 26 Feb 2014 14:30:47 +0100 Subject: [erlang-questions] byte_size/1 vs variable access In-Reply-To: <530DE135.9040507@ninenines.eu> References: <530D1185.8030705@ninenines.eu> <530DE135.9040507@ninenines.eu> Message-ID: On Wed, Feb 26, 2014 at 1:42 PM, Lo?c Hoguin wrote: > Thanks. > > Is there any optimization when it's done inside a function clause guard? For > example say, 5 of my 6 clauses need to check byte_size(Bin) to decide what > to do. I am reading some code I wrote a few days ago and I see I > instinctively used a single clause, creating a variable to hold the size and > then used a if inside it. Perhaps the compiler is doing something about it > in this case? No. The compiler currently does not do much optimizations of guards. > I know it doesn't matter 99% of the time, but I got one or two modules that > deal with binaries where the smallest improvement means I can handle a bunch > more traffic. To be honest it would be really nice if the compiler would > automatically create a variable when it sees me use byte_size/1 more than > once as I can then stop writing all this extra code. And I'm guessing it > could probably do the same with length/1 and others. > Is any of that code open-source? I occasionally look through BEAM assembly code looking for things that the BEAM compiler could handle better. Pointers to real-world code that is performance critical are appreciated. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From eriksoe@REDACTED Wed Feb 26 14:30:53 2014 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Wed, 26 Feb 2014 14:30:53 +0100 Subject: [erlang-questions] byte_size/1 vs variable access In-Reply-To: <530DE135.9040507@ninenines.eu> References: <530D1185.8030705@ninenines.eu> <530DE135.9040507@ninenines.eu> Message-ID: As far as I recall, guards aren't handled cleverly - common parts do not result in shared code. Regarding GC: Variables are on the stack and are released as soon as their lifetime is done, so any extra GC-effect caused by the heap growing into the stack sooner would presumably be small except if the variable in question had a lifetime across a recursive call. I guess you'd have to measure... Den 26/02/2014 13.42 skrev "Lo?c Hoguin" : > Thanks. > > Is there any optimization when it's done inside a function clause guard? > For example say, 5 of my 6 clauses need to check byte_size(Bin) to decide > what to do. I am reading some code I wrote a few days ago and I see I > instinctively used a single clause, creating a variable to hold the size > and then used a if inside it. Perhaps the compiler is doing something about > it in this case? > > I know it doesn't matter 99% of the time, but I got one or two modules > that deal with binaries where the smallest improvement means I can handle a > bunch more traffic. To be honest it would be really nice if the compiler > would automatically create a variable when it sees me use byte_size/1 more > than once as I can then stop writing all this extra code. And I'm guessing > it could probably do the same with length/1 and others. > > On 02/26/2014 12:46 PM, Bj?rn Gustavsson wrote: > >> On Tue, Feb 25, 2014 at 10:56 PM, Lo?c Hoguin wrote: >> >> But considering byte_size/1 is O(1) I am wondering if perhaps that's a >>> little pointless. Is it even worth creating a variable for this? Is >>> perhaps >>> the variable optimized out? Perhaps accessing a variable contents and >>> calling byte_size/1 are equivalent operations? Or the GC that will >>> follow is >>> not worth what little is saved by creating a variable in the first place? >>> >>> If someone could shed some light on this perhaps I could stop creating >>> variables like this and simplify my code a little more. >>> >>> >> There is definitely more overhead calling a BIF than accessing a variable. >> >> That said, I doubt that you will be able to notice the difference in a >> real program. >> So I suggest that you write in the way that you find most readable. >> >> /Bjorn >> >> > -- > 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 Feb 26 14:39:00 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 26 Feb 2014 14:39:00 +0100 Subject: [erlang-questions] byte_size/1 vs variable access In-Reply-To: References: <530D1185.8030705@ninenines.eu> <530DE135.9040507@ninenines.eu> Message-ID: <530DEE74.1000601@ninenines.eu> What I want is to write the most readable code possible and that the compiler makes it run as fast as possible, using hints that could be provided in the form of compiler flags (possibly local to a module). It's pretty much already what the compiler is doing with other things. I understand I can't defer everything to the compiler, but considering Erlang is immutable it shouldn't be too hard to automate that kind of optimization, and be allowed to write tighter and cleaner code while still having these tiny improvements. On 02/26/2014 02:23 PM, Aidan Hobson Sayers wrote: > If your performance is on a knife edge such that var lookup vs bif call > is important then perhaps you wouldn't want the compiler to blindly > perform this optimisation? > E.g. if your first clause happens in (say) 99% of cases and the compiler > tries to be clever, you're doing > - bif call > - variable store > - variable access > when maybe you'd rather it do the multiple bif calls if it had to > because 99% of the time it only needs to do one. > > But that would depend on how much faster var access is compared to the > bif call. If it's 2x faster you definitely don't want the 'optimisation' > above all the time. If it's 1000x faster then you want this optimisation > for the 99% of the time case above...but not if the first clause happens > 99.999% of the time. > > As with all things performance, benchmarks are the only solution. > > Aidan > > > On 26 February 2014 12:42, Lo?c Hoguin > wrote: > > Thanks. > > Is there any optimization when it's done inside a function clause > guard? For example say, 5 of my 6 clauses need to check > byte_size(Bin) to decide what to do. I am reading some code I wrote > a few days ago and I see I instinctively used a single clause, > creating a variable to hold the size and then used a if inside it. > Perhaps the compiler is doing something about it in this case? > > I know it doesn't matter 99% of the time, but I got one or two > modules that deal with binaries where the smallest improvement means > I can handle a bunch more traffic. To be honest it would be really > nice if the compiler would automatically create a variable when it > sees me use byte_size/1 more than once as I can then stop writing > all this extra code. And I'm guessing it could probably do the same > with length/1 and others. > > > On 02/26/2014 12:46 PM, Bj?rn Gustavsson wrote: > > On Tue, Feb 25, 2014 at 10:56 PM, Lo?c Hoguin > > wrote: > > But considering byte_size/1 is O(1) I am wondering if > perhaps that's a > little pointless. Is it even worth creating a variable for > this? Is perhaps > the variable optimized out? Perhaps accessing a variable > contents and > calling byte_size/1 are equivalent operations? Or the GC > that will follow is > not worth what little is saved by creating a variable in the > first place? > > If someone could shed some light on this perhaps I could > stop creating > variables like this and simplify my code a little more. > > > There is definitely more overhead calling a BIF than accessing a > variable. > > That said, I doubt that you will be able to notice the > difference in a > real program. > So I suggest that you write in the way that you find most readable. > > /Bjorn > > > -- > 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 essen@REDACTED Wed Feb 26 14:46:34 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 26 Feb 2014 14:46:34 +0100 Subject: [erlang-questions] byte_size/1 vs variable access In-Reply-To: References: <530D1185.8030705@ninenines.eu> <530DE135.9040507@ninenines.eu> Message-ID: <530DF03A.8030401@ninenines.eu> On 02/26/2014 02:30 PM, Bj?rn Gustavsson wrote: > On Wed, Feb 26, 2014 at 1:42 PM, Lo?c Hoguin wrote: >> Thanks. >> >> Is there any optimization when it's done inside a function clause guard? For >> example say, 5 of my 6 clauses need to check byte_size(Bin) to decide what >> to do. I am reading some code I wrote a few days ago and I see I >> instinctively used a single clause, creating a variable to hold the size and >> then used a if inside it. Perhaps the compiler is doing something about it >> in this case? > > No. The compiler currently does not do much optimizations of guards. Shame. >> I know it doesn't matter 99% of the time, but I got one or two modules that >> deal with binaries where the smallest improvement means I can handle a bunch >> more traffic. To be honest it would be really nice if the compiler would >> automatically create a variable when it sees me use byte_size/1 more than >> once as I can then stop writing all this extra code. And I'm guessing it >> could probably do the same with length/1 and others. >> > > Is any of that code open-source? I occasionally look > through BEAM assembly code looking for things > that the BEAM compiler could handle better. Pointers > to real-world code that is performance critical > are appreciated. That particular byte_size/1 related code isn't online yet. I am finishing it up. I do have two very performance critical modules online, one that I optimized to death and then some, here: https://github.com/extend/cowboy/blob/master/src/cowboy_protocol.erl It uses a single binary match context for the whole thing (as far as I can tell, anyway). And one where I simply reimplemented my own supervisor here: https://github.com/extend/ranch/blob/master/src/ranch_conns_sup.erl If you can make any of these faster than they currently are, then I believe you will make happy a big part of the Erlang community. -- Lo?c Hoguin http://ninenines.eu From mononcqc@REDACTED Wed Feb 26 14:50:42 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 26 Feb 2014 08:50:42 -0500 Subject: [erlang-questions] byte_size/1 vs variable access In-Reply-To: <530DEE74.1000601@ninenines.eu> References: <530D1185.8030705@ninenines.eu> <530DE135.9040507@ninenines.eu> <530DEE74.1000601@ninenines.eu> Message-ID: <20140226135040.GC62889@ferdair.local> Everything is immutable, but it is not side-effect free. Twot hings to consider: - Only allowing it in guards to avoid side-effects that could be triggered at the wrong moment. If you allow it with any code, then multiple function calls being moved around can change the number of messages sent or received within that function - Messing up tracing of function calls where the file and the resulting code no longer match, breaking expectations. On 02/26, Lo?c Hoguin wrote: > What I want is to write the most readable code possible and that the > compiler makes it run as fast as possible, using hints that could be > provided in the form of compiler flags (possibly local to a module). It's > pretty much already what the compiler is doing with other things. > > I understand I can't defer everything to the compiler, but considering > Erlang is immutable it shouldn't be too hard to automate that kind of > optimization, and be allowed to write tighter and cleaner code while still > having these tiny improvements. > > On 02/26/2014 02:23 PM, Aidan Hobson Sayers wrote: > >If your performance is on a knife edge such that var lookup vs bif call > >is important then perhaps you wouldn't want the compiler to blindly > >perform this optimisation? > >E.g. if your first clause happens in (say) 99% of cases and the compiler > >tries to be clever, you're doing > > - bif call > > - variable store > > - variable access > >when maybe you'd rather it do the multiple bif calls if it had to > >because 99% of the time it only needs to do one. > > > >But that would depend on how much faster var access is compared to the > >bif call. If it's 2x faster you definitely don't want the 'optimisation' > >above all the time. If it's 1000x faster then you want this optimisation > >for the 99% of the time case above...but not if the first clause happens > >99.999% of the time. > > > >As with all things performance, benchmarks are the only solution. > > > >Aidan > > > > > >On 26 February 2014 12:42, Lo?c Hoguin >> wrote: > > > > Thanks. > > > > Is there any optimization when it's done inside a function clause > > guard? For example say, 5 of my 6 clauses need to check > > byte_size(Bin) to decide what to do. I am reading some code I wrote > > a few days ago and I see I instinctively used a single clause, > > creating a variable to hold the size and then used a if inside it. > > Perhaps the compiler is doing something about it in this case? > > > > I know it doesn't matter 99% of the time, but I got one or two > > modules that deal with binaries where the smallest improvement means > > I can handle a bunch more traffic. To be honest it would be really > > nice if the compiler would automatically create a variable when it > > sees me use byte_size/1 more than once as I can then stop writing > > all this extra code. And I'm guessing it could probably do the same > > with length/1 and others. > > > > > > On 02/26/2014 12:46 PM, Bj?rn Gustavsson wrote: > > > > On Tue, Feb 25, 2014 at 10:56 PM, Lo?c Hoguin > > > wrote: > > > > But considering byte_size/1 is O(1) I am wondering if > > perhaps that's a > > little pointless. Is it even worth creating a variable for > > this? Is perhaps > > the variable optimized out? Perhaps accessing a variable > > contents and > > calling byte_size/1 are equivalent operations? Or the GC > > that will follow is > > not worth what little is saved by creating a variable in the > > first place? > > > > If someone could shed some light on this perhaps I could > > stop creating > > variables like this and simplify my code a little more. > > > > > > There is definitely more overhead calling a BIF than accessing a > > variable. > > > > That said, I doubt that you will be able to notice the > > difference in a > > real program. > > So I suggest that you write in the way that you find most readable. > > > > /Bjorn > > > > > > -- > > 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 > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From essen@REDACTED Wed Feb 26 15:11:26 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 26 Feb 2014 15:11:26 +0100 Subject: [erlang-questions] byte_size/1 vs variable access In-Reply-To: <20140226135040.GC62889@ferdair.local> References: <530D1185.8030705@ninenines.eu> <530DE135.9040507@ninenines.eu> <530DEE74.1000601@ninenines.eu> <20140226135040.GC62889@ferdair.local> Message-ID: <530DF60E.70200@ninenines.eu> I do not believe there's an issue for the two I mentioned, byte_size/1 and length/1. The only difference is creating an extra variable to hold the result of the first call, and reusing that afterwards. If the first call doesn't fail, then all subsequent calls are guaranteed to succeed, so it doesn't mess up the stacktrace. As far as tracing goes, it could have the same behavior as inlined functions. It of course wouldn't be enabled by default either. On 02/26/2014 02:50 PM, Fred Hebert wrote: > Everything is immutable, but it is not side-effect free. Twot hings to > consider: > > - Only allowing it in guards to avoid side-effects that could be > triggered at the wrong moment. If you allow it with any code, then > multiple function calls being moved around can change the number of > messages sent or received within that function > - Messing up tracing of function calls where the file and the resulting > code no longer match, breaking expectations. > > On 02/26, Lo?c Hoguin wrote: >> What I want is to write the most readable code possible and that the >> compiler makes it run as fast as possible, using hints that could be >> provided in the form of compiler flags (possibly local to a module). It's >> pretty much already what the compiler is doing with other things. >> >> I understand I can't defer everything to the compiler, but considering >> Erlang is immutable it shouldn't be too hard to automate that kind of >> optimization, and be allowed to write tighter and cleaner code while still >> having these tiny improvements. >> >> On 02/26/2014 02:23 PM, Aidan Hobson Sayers wrote: >>> If your performance is on a knife edge such that var lookup vs bif call >>> is important then perhaps you wouldn't want the compiler to blindly >>> perform this optimisation? >>> E.g. if your first clause happens in (say) 99% of cases and the compiler >>> tries to be clever, you're doing >>> - bif call >>> - variable store >>> - variable access >>> when maybe you'd rather it do the multiple bif calls if it had to >>> because 99% of the time it only needs to do one. >>> >>> But that would depend on how much faster var access is compared to the >>> bif call. If it's 2x faster you definitely don't want the 'optimisation' >>> above all the time. If it's 1000x faster then you want this optimisation >>> for the 99% of the time case above...but not if the first clause happens >>> 99.999% of the time. >>> >>> As with all things performance, benchmarks are the only solution. >>> >>> Aidan >>> >>> >>> On 26 February 2014 12:42, Lo?c Hoguin >> > wrote: >>> >>> Thanks. >>> >>> Is there any optimization when it's done inside a function clause >>> guard? For example say, 5 of my 6 clauses need to check >>> byte_size(Bin) to decide what to do. I am reading some code I wrote >>> a few days ago and I see I instinctively used a single clause, >>> creating a variable to hold the size and then used a if inside it. >>> Perhaps the compiler is doing something about it in this case? >>> >>> I know it doesn't matter 99% of the time, but I got one or two >>> modules that deal with binaries where the smallest improvement means >>> I can handle a bunch more traffic. To be honest it would be really >>> nice if the compiler would automatically create a variable when it >>> sees me use byte_size/1 more than once as I can then stop writing >>> all this extra code. And I'm guessing it could probably do the same >>> with length/1 and others. >>> >>> >>> On 02/26/2014 12:46 PM, Bj?rn Gustavsson wrote: >>> >>> On Tue, Feb 25, 2014 at 10:56 PM, Lo?c Hoguin >>> > wrote: >>> >>> But considering byte_size/1 is O(1) I am wondering if >>> perhaps that's a >>> little pointless. Is it even worth creating a variable for >>> this? Is perhaps >>> the variable optimized out? Perhaps accessing a variable >>> contents and >>> calling byte_size/1 are equivalent operations? Or the GC >>> that will follow is >>> not worth what little is saved by creating a variable in the >>> first place? >>> >>> If someone could shed some light on this perhaps I could >>> stop creating >>> variables like this and simplify my code a little more. >>> >>> >>> There is definitely more overhead calling a BIF than accessing a >>> variable. >>> >>> That said, I doubt that you will be able to notice the >>> difference in a >>> real program. >>> So I suggest that you write in the way that you find most readable. >>> >>> /Bjorn >>> >>> >>> -- >>> 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 >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -- Lo?c Hoguin http://ninenines.eu From erlang@REDACTED Wed Feb 26 20:20:25 2014 From: erlang@REDACTED (Andreas Stenius) Date: Wed, 26 Feb 2014 20:20:25 +0100 Subject: [erlang-questions] Library application and it's dependencies In-Reply-To: References: Message-ID: > > [...] > 2014-02-24 21:17 GMT+01:00 Tuncer Ayaz : > > You can consider it a rebar bug, if you have to manually list parse >> transforms in erl_first_files. If that's the case, give the (hopefully >> soon to be merged) https://github.com/rebar/rebar/pull/129 a try. >> > > The issue seems a bit deeper than that. The thing is, that merl has some rather unusual compile rules for compiling the parse transform, in that it compiles it twice, and for the second pass, it applies itself during compile. So, is there any way to tell rebar to use a projects make file rather than simply compiling erl files and "hoping" for the best; especially when there is no rebar.config for the project. (@tuncer ?) I was considering that it would be possible to achieve the same build using a rebar config file using hooks and stuff, but then I suppose it would need to live in the merl repo.. ? feels like that would defeat the purpose a bit, if I need to tweak the dependency project to make it work with rebar.. or I'm not familiar enough with rebar, which is more than likely ;) Either that, or I could add merl as a git subproject, and hook it up that way, integrating the merl build into the erlydtl one, so that the merl beam files and includes would be available from erlydtl's path.. but that's a rather kludgy way of doing things.. hmm. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Wed Feb 26 20:45:29 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 26 Feb 2014 20:45:29 +0100 Subject: [erlang-questions] Library application and it's dependencies In-Reply-To: References: Message-ID: On Wed, Feb 26, 2014 at 8:20 PM, Andreas Stenius wrote: >> [...] >> 2014-02-24 21:17 GMT+01:00 Tuncer Ayaz: >> >>> You can consider it a rebar bug, if you have to manually list parse >>> transforms in erl_first_files. If that's the case, give the (hopefully >>> soon to be merged) https://github.com/rebar/rebar/pull/129 a try. >> >> > > The issue seems a bit deeper than that. The thing is, that merl has > some rather unusual compile rules for compiling the parse transform, > in that it compiles it twice, and for the second pass, it applies > itself during compile. > > So, is there any way to tell rebar to use a projects make file > rather than simply compiling erl files and "hoping" for the best; > especially when there is no rebar.config for the project. (@tuncer?) As long as the project follows otp project structure conventions and doesn't require extra configuration (defaults are okay), you don't need rebar.config. > I was considering that it would be possible to achieve the same > build using a rebar config file using hooks and stuff, but then I > suppose it would need to live in the merl repo.. ? feels like that > would defeat the purpose a bit, if I need to tweak the dependency > project to make it work with rebar.. or I'm not familiar enough with > rebar, which is more than likely ;) > > Either that, or I could add merl as a git subproject, and hook it up > that way, integrating the merl build into the erlydtl one, so that > the merl beam files and includes would be available from erlydtl's > path.. but that's a rather kludgy way of doing things.. hmm. Have you tried {pre_hooks, [{'compile', "make -C deps/merl"}]}? I didn't test that, but I'd expect something like that to work. From erlang@REDACTED Wed Feb 26 21:07:12 2014 From: erlang@REDACTED (Andreas Stenius) Date: Wed, 26 Feb 2014 21:07:12 +0100 Subject: [erlang-questions] Library application and it's dependencies In-Reply-To: References: Message-ID: 2014-02-26 20:45 GMT+01:00 Tuncer Ayaz : > On Wed, Feb 26, 2014 at 8:20 PM, Andreas Stenius wrote: > >> [...] > >> 2014-02-24 21:17 GMT+01:00 Tuncer Ayaz: > >> > >>> You can consider it a rebar bug, if you have to manually list parse > >>> transforms in erl_first_files. If that's the case, give the (hopefully > >>> soon to be merged) https://github.com/rebar/rebar/pull/129 a try. > >> > >> > > > > The issue seems a bit deeper than that. The thing is, that merl has > > some rather unusual compile rules for compiling the parse transform, > > in that it compiles it twice, and for the second pass, it applies > > itself during compile. > > > > So, is there any way to tell rebar to use a projects make file > > rather than simply compiling erl files and "hoping" for the best; > > especially when there is no rebar.config for the project. (@tuncer?) > > As long as the project follows otp project structure conventions > and doesn't require extra configuration (defaults are okay), you don't > need rebar.config. > Well, yes, but in this case, there was some special treatments needed.. > > > I was considering that it would be possible to achieve the same > > build using a rebar config file using hooks and stuff, but then I > > suppose it would need to live in the merl repo.. ? feels like that > > would defeat the purpose a bit, if I need to tweak the dependency > > project to make it work with rebar.. or I'm not familiar enough with > > rebar, which is more than likely ;) > > > > Either that, or I could add merl as a git subproject, and hook it up > > that way, integrating the merl build into the erlydtl one, so that > > the merl beam files and includes would be available from erlydtl's > > path.. but that's a rather kludgy way of doing things.. hmm. > > Have you tried {pre_hooks, [{'compile', "make -C deps/merl"}]}? > I didn't test that, but I'd expect something like that to work. > That, in combination with listing the merl dep as `raw` seems to have worked (looked good in my very limited envrionment, awaiting responses [1]). Thanks for the tip :) (although, I used "make -C $REBAR_DEPS_DIR/merl all", as the deps dir could be anywhere, really..) [1] https://github.com/erlydtl/erlydtl/issues/123#issuecomment-36169576 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Wed Feb 26 21:30:22 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 27 Feb 2014 09:30:22 +1300 Subject: [erlang-questions] atoms with newlines In-Reply-To: References: <3D506AA6-D4E1-4887-B76B-51FA12BCF353@cs.otago.ac.nz> <6B6D7CCC-E823-44A9-B7D9-7268C4CFAEC9@cs.otago.ac.nz> Message-ID: <19A12F28-802B-4F7C-8DF4-F5D6E7B6134C@cs.otago.ac.nz> On 26/02/2014, at 10:56 PM, Valentin Micic wrote: > If this is *really* necessary, wouldn't it be less confusing (or even more consistent) to consider: > > 1> 'foo' \ > 1> 'bar'. > foobar > > whereas: > > 3> 'foo > 3>bar' > 'foo\nbar' > > includes a new line -- as already does. No, and on two grounds. First, backslash escapes are not a special notation confined to Erlang. They are supported in a wide variety of languages. Not just the "usual suspects" in the C family. There's Python, for example. And logic programming languages and functional languages too: >>> print "a\ ... b"; ab -- Python > "a\ - b";; val it : string = "ab" -- F# and O'CAML ?- X = 'a\ | b'. X = ab. -- Prolog and Mercury So having backslash+newline *silently accepted* and do *exactly the opposite of what people expect* cannot be a good thing. We already have two ways to get a newline into an Erlang string or atom: a bare newline or a \n escape. We really do NOT need a third, especially one that is basically an implementation accident. It would be excusable to make backslash+newline an always-reported syntax error. People would get a nasty surprise, but at least they wouldn't silently get the wrong value in their program. In fact I think that *every* \ combination that is not explicitly documented should be reported as a syntax error. Second, it is currently the case that backslash has a special meaning in Erlang *ONLY* inside quoted literals (counting $\t as a quoted literal). Your "less confusing (or even more consistent)" proposal introduces a new thing that *looks* like an operator but *isn't* one. It is difficult to see how that is less confusing than following common practice or more consistent with anything. From valentin@REDACTED Thu Feb 27 01:33:06 2014 From: valentin@REDACTED (Valentin Micic) Date: Thu, 27 Feb 2014 02:33:06 +0200 Subject: [erlang-questions] atoms with newlines In-Reply-To: <19A12F28-802B-4F7C-8DF4-F5D6E7B6134C@cs.otago.ac.nz> References: <3D506AA6-D4E1-4887-B76B-51FA12BCF353@cs.otago.ac.nz> <6B6D7CCC-E823-44A9-B7D9-7268C4CFAEC9@cs.otago.ac.nz> <19A12F28-802B-4F7C-8DF4-F5D6E7B6134C@cs.otago.ac.nz> Message-ID: On 26 Feb 2014, at 10:30 PM, Richard A. O'Keefe wrote: > > On 26/02/2014, at 10:56 PM, Valentin Micic wrote: > >> If this is *really* necessary, wouldn't it be less confusing (or even more consistent) to consider: >> >> 1> 'foo' \ >> 1> 'bar'. >> foobar >> >> whereas: >> >> 3> 'foo >> 3>bar' >> 'foo\nbar' >> >> includes a new line -- as already does. > > No, and on two grounds. > > First, backslash escapes are not a special notation > confined to Erlang. They are supported in a wide > variety of languages. Not just the "usual suspects" > in the C family. There's Python, for example. And > logic programming languages and functional languages too: >>>> print "a\ > ... b"; > ab -- Python > >> "a\ > - b";; > val it : string = "ab" -- F# and O'CAML I do see your point (and feel your frustration), however, you are using a logical fallacy to reinforce your argument as you making an appeal to authority -- others are using it, thus it has to be right. Also, even if we assume that your argument may be valid for a particular context, say, strings in Python, it would not make much sense to consider it in this situation, for you know very well that strings and atoms are not the same thing. > ?- X = 'a\ > | b'. > X = ab. -- Prolog and Mercury > > So having backslash+newline *silently accepted* and > do *exactly the opposite of what people expect* cannot > be a good thing. Using similar reasoning people may also expect that: A = 1, A = A + 1 should not crash a program (as it doesn't in other programming languages), yet in Erlang it does. It may not be what people want, expect or like if they are new to Erlang, but it is a part of the language and it behaves consistently -- it always causes crash. By the same token, having a rule which allows atoms to contain "special" characters if one enclose them within a pair of apostrophes, cannot be considered consistent if a single backslash followed by a new-line character has yet another special meaning, e.g. elimination of the new-line character (*) I think that the current implementation is consistent with its intent -- allowing atoms that contain special characters and having a new-line in this context treated as a special character. One may question if a backslash ( \ ) followed by an action of pressing the enter key, should produce the same result as pressing the enter key without preceding backslash -- namely, both cases producing a single '\n'; but this was not what you've been complaining about, so I would not like to enter that conversation. > We already have two ways to get a newline into an Erlang > string or atom: a bare newline or a \n escape. We really > do NOT need a third, especially one that is basically an > implementation accident. I think you are making an assumption this was "an implementation accident". I am making an assumption that this was a well considered and deliberate effort. In both cases we are talking about assumptions, why present them as facts then? > > It would be excusable to make backslash+newline an > always-reported syntax error. People would get a nasty > surprise, but at least they wouldn't silently get the > wrong value in their program. In fact I think that > *every* \ combination that is not explicitly > documented should be reported as a syntax error. Why is it that you're ignoring the fact that the intent behind usage of apostrophes in atom construction is documented. Also, if you place a new-line during the construction of an atom without apostrophes, the syntax error will be indeed reported. > > Second, it is currently the case that backslash has a > special meaning in Erlang *ONLY* inside quoted literals > (counting $\t as a quoted literal). Your "less confusing > (or even more consistent)" proposal introduces a new > thing that *looks* like an operator but *isn't* one. As opposed to not introducing a new operator, but definitely behaving like there was one (e.g. one that eliminates new-line character altogether)? > It is difficult to see how that is less confusing than > following common practice or more consistent with anything. Sorry to hear that. Let's agree to disagree. Kind reagards V/ (*) In my view, it is nothing more than a historical incident (or a whim of someone in a position of authority a long time ago) that yielded an elimination of new-line character when preceded by a backslash, whilst in any other case it is a backslash that is eliminated. For example: \" results in a double quote -- backslash is eliminated; \\ results in a backslash (having first backslash eliminated); \002 results in a integer value of two -- backslash is eliminated; \n results in integer value of 0x0a -- backslash is eliminated; Why should then a sequence such: "This is a test \ 0x0a string" (Where 0x0a represents an explicit new-line, as typed using a keyboard -- basically an Enter key) Result in a string "This is test string" with both backslash and new-line eliminated. And yet: "This is a test\n string" Would result in insertion of a new-line character: This is a test string How is this not confusing, let alone inconsistent? Common practice notwithstanding. From ok@REDACTED Thu Feb 27 03:02:20 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 27 Feb 2014 15:02:20 +1300 Subject: [erlang-questions] atoms with newlines In-Reply-To: References: <3D506AA6-D4E1-4887-B76B-51FA12BCF353@cs.otago.ac.nz> <6B6D7CCC-E823-44A9-B7D9-7268C4CFAEC9@cs.otago.ac.nz> <19A12F28-802B-4F7C-8DF4-F5D6E7B6134C@cs.otago.ac.nz> Message-ID: <9395A238-F3F4-476A-B9D5-A0AF417A46BB@cs.otago.ac.nz> On 27/02/2014, at 1:33 PM, Valentin Micic wrote: > > I do see your point (and feel your frustration), however, you are using a logical fallacy to reinforce your argument as you making an appeal to authority -- others are using it, thus it has to be right. You have completely misunderstood. In this debate, I have *NEVER* argued that any treatment of \n is *RIGHT* and I have *NEVER* appealed to authority. I am making a purely PRAGMATIC argument: BECAUSE We can already insert a newline character into the value of a quoted atom or quoted string using either a bare newline or \n or \^ THEREFORE Having \ do so as well does not add much to utility. (It's not *WRONG*, just *USELESS*.) BECAUSE Many Erlang programmers have experience in other languages and those other languages use \ for a seamless join AND The present behaviour is not documented in the reference manual so that those programmers will not have their expectations corrected by documentation THEREFORE many Erlang programmers will be SURPRISED by the actual behaviour of Erlang. BECAUSE The backslash newline combination is silently accepted by the compiler THEREFORE The unpleasant surprise will be when the code is tested, if then, not when the code is edited or compiled. Contrast Erlang with Common Lisp here. I have never argued that \ should vanish in Common Lisp, because Common Lisp has documented the behaviour of \ very clearly. (In section 2.1.4.6 and 2.1.4.5 and 2.4.5.) It doesn't matter how many other languages do what; Common Lisp is explicit about what *IT* does. Oh, and Common Lisp doesn't _need_ string pasting because it has #.(concatenate "foo" "bar") . BECAUSE It is useful to be able to write a string or a quoted atom that extends over multiple lines without thereby being forced to include newline characters in the value denoted THEREFORE it would be useful to adopt some convention such as C's to allow unwanted newlines to be elided. This is not an appeal to AUTHORITY, it is an appeal to UTILITY. It's worth pointing out here that (O'CAML, F#) and the C family do slightly different things. After \, O'CAML and F# will ignore leading spaces and tabs; the C family will not. Some Prolog systems support \c as well as \, the \c having been ultimately inspired by the \c feature of echo(1). I really don't see any appeal to authority here. > Also, even if we assume that your argument may be valid for a particular context, say, strings in Python, it would not make much sense to consider it in this situation, for you know very well that strings and atoms are not the same thing. Yes, but ***SO WHAT***? Strings and atoms are not the same thing in Prolog or Mercury either. What of that? They may both be _notated_ similarly. It is not the case that Erlang does something sensible with \ in strings and something stupid with \ in atoms. It does the *SAME* thing in both contexts, and it is equally dangerous in both. > Using similar reasoning people may also expect that: > > A = 1, > A = A + 1 > > should not crash a program This claim is invalid, because my reasoning makes an *essential* appeal to the fact that the behaviour of backslash+newline is *UNDOCUMENTED* in Erlang. The behaviour here is *DOCUMENTED*. See the difference? [Skipping] > > I think you are making an assumption this was "an implementation accident". Yes, I am. BECAUSE IT IS NOT DOCUMENTED! > > I am making an assumption that this was a well considered and deliberate effort. Why would a "well considered and deliberate effort" - provide a redundant way to do something we have *THREE* other ways to do - deliberately create a hazard - FAIL TO DOCUMENT the decision? > In both cases we are talking about assumptions, why present them as facts then? When did I do that? > >> >> It would be excusable to make backslash+newline an >> always-reported syntax error. People would get a nasty >> surprise, but at least they wouldn't silently get the >> wrong value in their program. In fact I think that >> *every* \ combination that is not explicitly >> documented should be reported as a syntax error. > > Why is it that you're ignoring the fact that the intent behind usage of apostrophes in atom construction is documented. Because I am *NOT* ignoring that, and you have no grounds for suggesting otherwise. > Also, if you place a new-line during the construction of an atom without apostrophes, the syntax error will be indeed reported. So what? That's totally off-topic. In fact ifa =:= b ... is *NOT* a syntax error and *WON'T* be reported. It just isn't one atom, that's all. > >> >> Second, it is currently the case that backslash has a >> special meaning in Erlang *ONLY* inside quoted literals >> (counting $\t as a quoted literal). Your "less confusing >> (or even more consistent)" proposal introduces a new >> thing that *looks* like an operator but *isn't* one. > > As opposed to not introducing a new operator, but definitely behaving like there was one (e.g. one that eliminates new-line character altogether)? There are no operators inside strings or atoms. Backslash+newline is not described as or treated as or thought as in any way resembling an operator in languages that define it. A backlash+newline that stands for the empty sequence is no more an operator than a backslash+newline that stands for a non-empty sequence. (If you have a programming language with byte strings, a Unicode escape \u2022 might stand for more than one byte. It wouldn't be an operator either.) >> (*) In my view, it is nothing more than a historical incident (or a whim of someone in a position of authority a long time ago) that yielded an elimination of new-line character when preceded by a backslash, whilst in any other case it is a backslash that is eliminated. What? In a sequence like \t, neither character is eliminated. The *whole* escape sequence is replaced by another character sequence. > For example: > > \" results in a double quote -- backslash is eliminated; > \\ results in a backslash (having first backslash eliminated); > \002 results in a integer value of two -- backslash is eliminated; Only if you want to say that the 0, the second 0, and the 2 are also "eliminated". > \n results in integer value of 0x0a -- backslash is eliminated; And so is the n. "Elimination" just is not a helpful way to talk about the replacement of (entire) escape sequences by other character sequences (which might or might not have unit length). "Elimination" *would* be a useful way to talk about single-escape processing in Common Lisp. But Erlang is not Lisp. (LFE is another matter.) > > Why should then a sequence such: > > "This is a test \ 0x0a > string" Remember my demand that UNDOCUMENTED escape sequences (like backslash+space or backslash+tab) should be explicit compile-time errors. If backslash+space or backslash+tab were to be documented as doing something, no matter how useless, then that is would they would do. Until then, this should be a compile-time error. > Result in a string "This is test string" with both backslash and new-line eliminated. It should not. (The only newline I see is the one after 0x0a, and nobody is saying _that_ should go.) > And yet: > > "This is a test\n string" > > Would result in insertion of a new-line character: Because that's what backslash+n is defined to do. Escape processing in quoted literals replaces with which might contain no characters, 1 character, or many characters. Whatever the replacement is, is whatever the documentation says it is. Undefined escape sequences should be errors. In fact, in R16B03-1, most undefined escape sequences *are* errors. Here's an example of the trouble that unchecked undocumented escape sequences can get you into. In R16B03-1, "\x{20}" uses a documented escape sequence to get a space character " ". Trying it in an older release gave me "x{20}". From valentin@REDACTED Thu Feb 27 11:09:57 2014 From: valentin@REDACTED (Valentin Micic) Date: Thu, 27 Feb 2014 12:09:57 +0200 Subject: [erlang-questions] atoms with newlines In-Reply-To: <9395A238-F3F4-476A-B9D5-A0AF417A46BB@cs.otago.ac.nz> References: <3D506AA6-D4E1-4887-B76B-51FA12BCF353@cs.otago.ac.nz> <6B6D7CCC-E823-44A9-B7D9-7268C4CFAEC9@cs.otago.ac.nz> <19A12F28-802B-4F7C-8DF4-F5D6E7B6134C@cs.otago.ac.nz> <9395A238-F3F4-476A-B9D5-A0AF417A46BB@cs.otago.ac.nz> Message-ID: On 27 Feb 2014, at 4:02 AM, Richard A. O'Keefe wrote: > > On 27/02/2014, at 1:33 PM, Valentin Micic wrote: >> >> I do see your point (and feel your frustration), however, you are using a logical fallacy to reinforce your argument as you making an appeal to authority -- others are using it, thus it has to be right. > > You have completely misunderstood. Suppose you're right, and I did misunderstand you. Where would that leave this debate? I can go ahead and reply "bullet-by-bullet" (arguably from a position of someone that made a wrong conclusion due to the misunderstanding of the original argument), however, considering that there are more "typing to be done" around issues with no direct reference to the original argument, this will only take us further away from the topic. Alternatively, I may have (or at least believe that I have) understood you just fine, which may compel me to assert my position vis-a-vis your clarifications, but that will just as well drawn the original topic. In my view, the moment one has to "clarify" what he/she has said, the nature of debate is changing and I sincerely apologize for making statements that compelled you to clarify your position (as you've done below by shouting NEVER, BECAUSE, THEREFORE and AND). My (I desire) last word on the original topic is that the atom construction rules as implemented in Erlang make sense to me, and since no-one else have complained about it (*), this may lead me to believe that this rule made sense to other people as well. If this assumption is correct, it would be reasonable to expect that some of the people may have even taken an advantage of this behaviour. And if that is the case, how would change that you're suggesting affect them?(**) With this in mind I've made my suggestion, to which you've objected to on two counts, etc. (see, now I have to clarify my position). Kind regards V/ (*) I may be wrong, but I cannot recall seeing a similar complaint (**) Contrast that to possibly one program (possibly not in a production at this point) that you may have to change to solve your problem. Now, that would be a very pragmatic thing to do. > In this debate, > I have *NEVER* argued that any treatment of \n is *RIGHT* and > I have *NEVER* appealed to authority. > > I am making a purely PRAGMATIC argument: > > BECAUSE > We can already insert a newline character into the > value of a quoted atom or quoted string using > either a bare newline or \n or \^ > THEREFORE > Having \ do so as well does not add > much to utility. (It's not *WRONG*, just *USELESS*.) > > BECAUSE > Many Erlang programmers have experience in other languages > and those other languages use \ for a seamless > join > AND > The present behaviour is not documented in the > reference manual so that those programmers will not have > their expectations corrected by documentation > THEREFORE > many Erlang programmers will be SURPRISED by the actual > behaviour of Erlang. > > BECAUSE > The backslash newline combination is silently accepted > by the compiler > THEREFORE > The unpleasant surprise will be when the code is tested, > if then, not when the code is edited or compiled. > > Contrast Erlang with Common Lisp here. > I have never argued that \ should vanish in > Common Lisp, because Common Lisp has documented the > behaviour of \ very clearly. (In section 2.1.4.6 and > 2.1.4.5 and 2.4.5.) It doesn't matter how many other > languages do what; Common Lisp is explicit about what > *IT* does. > > Oh, and Common Lisp doesn't _need_ string pasting because > it has #.(concatenate "foo" "bar") . > > BECAUSE > It is useful to be able to write a string or a quoted > atom that extends over multiple lines without thereby > being forced to include newline characters in the > value denoted > THEREFORE > it would be useful to adopt some convention such as > C's to allow unwanted newlines to be elided. > > This is not an appeal to AUTHORITY, it is an appeal to > UTILITY. > > It's worth pointing out here that (O'CAML, F#) and the > C family do slightly different things. After > \, O'CAML and F# will ignore leading spaces > and tabs; the C family will not. Some Prolog systems > support \c as well as \, the \c having been > ultimately inspired by the \c feature of echo(1). > > I really don't see any appeal to authority here. > >> Also, even if we assume that your argument may be valid for a particular context, say, strings in Python, it would not make much sense to consider it in this situation, for you know very well that strings and atoms are not the same thing. > > Yes, but ***SO WHAT***? Strings and atoms are not the same > thing in Prolog or Mercury either. What of that? They may > both be _notated_ similarly. > > It is not the case that Erlang does something sensible with > \ in strings and something stupid with \ > in atoms. It does the *SAME* thing in both contexts, and > it is equally dangerous in both. > >> Using similar reasoning people may also expect that: >> >> A = 1, >> A = A + 1 >> >> should not crash a program > > This claim is invalid, because my reasoning makes an > *essential* appeal to the fact that the behaviour of > backslash+newline is *UNDOCUMENTED* in Erlang. > > The behaviour here is *DOCUMENTED*. > > See the difference? > > [Skipping] >> >> I think you are making an assumption this was "an implementation accident". > > Yes, I am. BECAUSE IT IS NOT DOCUMENTED! >> >> I am making an assumption that this was a well considered and deliberate effort. > > Why would a "well considered and deliberate effort" > - provide a redundant way to do something we have *THREE* > other ways to do > - deliberately create a hazard > - FAIL TO DOCUMENT the decision? > >> In both cases we are talking about assumptions, why present them as facts then? > > When did I do that? >> >>> >>> It would be excusable to make backslash+newline an >>> always-reported syntax error. People would get a nasty >>> surprise, but at least they wouldn't silently get the >>> wrong value in their program. In fact I think that >>> *every* \ combination that is not explicitly >>> documented should be reported as a syntax error. >> >> Why is it that you're ignoring the fact that the intent behind usage of apostrophes in atom construction is documented. > > Because I am *NOT* ignoring that, and you have no grounds > for suggesting otherwise. > >> Also, if you place a new-line during the construction of an atom without apostrophes, the syntax error will be indeed reported. > > So what? That's totally off-topic. In fact > ifa =:= b ... > is *NOT* a syntax error and *WON'T* be reported. > It just isn't one atom, that's all. > >> >>> >>> Second, it is currently the case that backslash has a >>> special meaning in Erlang *ONLY* inside quoted literals >>> (counting $\t as a quoted literal). Your "less confusing >>> (or even more consistent)" proposal introduces a new >>> thing that *looks* like an operator but *isn't* one. >> >> As opposed to not introducing a new operator, but definitely behaving like there was one (e.g. one that eliminates new-line character altogether)? > > There are no operators inside strings or atoms. > Backslash+newline is not described as or treated as or thought as > in any way resembling an operator in languages that define it. > A backlash+newline that stands for the empty sequence is no more > an operator than a backslash+newline that stands for a non-empty > sequence. (If you have a programming language with > byte strings, a Unicode escape \u2022 might stand for more than > one byte. It wouldn't be an operator either.) > >>> (*) In my view, it is nothing more than a historical incident (or a whim of someone in a position of authority a long time ago) that yielded an elimination of new-line character when preceded by a backslash, whilst in any other case it is a backslash that is eliminated. > > What? In a sequence like \t, neither character is eliminated. > The *whole* escape sequence is replaced by another character > sequence. > >> For example: >> >> \" results in a double quote -- backslash is eliminated; >> \\ results in a backslash (having first backslash eliminated); >> \002 results in a integer value of two -- backslash is eliminated; > > Only if you want to say that the 0, the second 0, and the 2 are > also "eliminated". > >> \n results in integer value of 0x0a -- backslash is eliminated; > > And so is the n. "Elimination" just is not a helpful way to > talk about the replacement of (entire) escape sequences by > other character sequences (which might or might not have unit > length). > > "Elimination" *would* be a useful way to talk about > single-escape processing in Common Lisp. But Erlang is not Lisp. > (LFE is another matter.) >> >> Why should then a sequence such: >> >> "This is a test \ 0x0a >> string" > > Remember my demand that UNDOCUMENTED escape sequences > (like backslash+space or backslash+tab) should be explicit > compile-time errors. If backslash+space or backslash+tab > were to be documented as doing something, no matter how > useless, then that is would they would do. Until then, > this should be a compile-time error. > > >> Result in a string "This is test string" with both backslash and new-line eliminated. > > It should not. (The only newline I see is the one after 0x0a, > and nobody is saying _that_ should go.) > >> And yet: >> >> "This is a test\n string" >> >> Would result in insertion of a new-line character: > > Because that's what backslash+n is defined to do. > > Escape processing in quoted literals > replaces with > which might contain no characters, 1 character, or many > characters. Whatever the replacement is, is whatever > the documentation says it is. > > Undefined escape sequences should be errors. > In fact, in R16B03-1, most undefined escape sequences > *are* errors. > > Here's an example of the trouble that unchecked > undocumented escape sequences can get you into. > In R16B03-1, "\x{20}" uses a documented escape > sequence to get a space character " ". Trying it in > an older release gave me "x{20}". > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From eric.pailleau@REDACTED Thu Feb 27 14:44:02 2014 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Thu, 27 Feb 2014 14:44:02 +0100 Subject: [erlang-questions] atoms with newlines In-Reply-To: References: <3D506AA6-D4E1-4887-B76B-51FA12BCF353@cs.otago.ac.nz> <6B6D7CCC-E823-44A9-B7D9-7268C4CFAEC9@cs.otago.ac.nz> <19A12F28-802B-4F7C-8DF4-F5D6E7B6134C@cs.otago.ac.nz> <9395A238-F3F4-476A-B9D5-A0AF417A46BB@cs.otago.ac.nz> Message-ID: <530F4122.9090400@wanadoo.fr> 1> "aaaa" 1> "bbbb" 1> . "aaaabbbb" consecutive strings are concatenated by parser, without ++ operator, while 2> 'aaaa' 2> 'bbbb' 2> . * 2: syntax error before: bbbb atoms are not. Maybe not very homogeneous... By the way, I do not really see the need to include \n in atoms... Regards From jesper.louis.andersen@REDACTED Thu Feb 27 16:27:37 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 27 Feb 2014 16:27:37 +0100 Subject: [erlang-questions] [Heads up!] Emysql driver is on a roller-coaster of changes Message-ID: Hi e-q@, The Emysql driver got some TLC today, and the last couple of days. If you use it, I would like that test out v0.4.1 or master. I tried very hard to not break backwards compatibility, but I might have failed. If you hate my patches, there is tags for each older release, so you should be able to pick up an older version. Changes: * I have genuinely started to sort calls into "Public API" and "Private API". This means I am trying to constrain the API down to just a few calls. This is easier to maintain, and it is also less susceptible to errors and mistakes. * All the conversion routines in `emysql_util` are now available from `emysql`. I am trying to make a single-module interface to the application so you don't need to know what is internals and not. * Using `emysql_util` is deprecated. But the guarantee is backwards compatibility until v1.0.0 * The issue-tracker now has tasks to work on, if you feel inclined to help out. In general, the TCP handling is a mess. And so is the protocol handling. But it will take a bit of time until I figure out how to handle those parts of the code base and revamp them into something more correct. I suspect there is some speed to be gained by rewriting the code into clean naive Erlang. Finally: If you have any lingering patches you would like to see added, don't hide! Though I admit I changed a lot so reintegrating them might take some time. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth.lundin@REDACTED Thu Feb 27 16:33:16 2014 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Thu, 27 Feb 2014 16:33:16 +0100 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc2 has been released. Message-ID: Erlang/OTP 17.0-rc2 has been released. This is a beta release, which will be followed by the final OTP 17.0 product release in the beginning of April. Between this beta and the final release there will be new updates of the master branch with corrections and minor new features. Occasionally there might be new tags which we in that case will communicate and ask you to test. Erlang/OTP 17.0 is a new major release with new features, quite a few (characteristics) improvements, as well as some incompatibilities. See the README file and the documentation for more details. We would like to ask you to download and test the beta release and send us your feedback as soon as possible, so that we can make the necessary corrections before OTP 17.0. The release contains many changes and a few potential incompatibilities. Please try to build and run your current products/applications and let us know about any problems. One known, but previously insufficiently documented incompatibility that we would like to highlight is: OTP-11719 == erts == *The default encoding of Erlang files has been changed from ISO-8859-1 to UTF-8. The encoding of XML files has also been changed to UTF-8.* Please verify that your source code compiles with Erlang/OTP 17. If your (ISO-8559-1 / Latin-1 encoded) source code files contain characters that are outside of the bit 7-bit ASCII character set, you will receive a compiler error similar to the following: tst.erl:1: cannot parse file, giving up tst.erl:1: no module definition tst.erl:1: cannot translate from UTF-8 In this case, you need to apply one of the following alternatives to each (impacted) file: Alternative 1: Encode the file in UTF-8 (instead of Latin-1). If the file is going to be compiled with both OTP 17 and previous versions, insert a comment stating the encoding at the beginning of the file: %% -*- coding: utf-8 -*- Alternative 2: Leave the file encoded as Latin-1 and insert a comment stating the encoding at the beginning of the file: %% -*- coding: latin-1 -*- For detailed information, see the STDLIB User's Guide, 2 Using Unicode in Erlang The 17.0 release contains many changes; thus, some unexpected incompatibilities or issues may have slipped through our tests. Please try to build and run your current products/applications and let us know about any problems. Note! The new datatype MAP is not properly documented yet but the EEP 43 https://www.erlang.org/eeps/eep-0043.html will provide a good start. Also note that it is a limited implementation of maps implemented so far: - no variable keys are allowed - native code can not be generated for modules using maps Some other highlights of the release are: - Erlang/OTP has been ported to the realtime operating system OSE. - Maps, a new dictionary data type (experimental) - A more natural mapping from ASN.1 OCTET STRING and BIT STRING to Erlang types, and other ASN.1 improvements and optimizations - The {active, N} socket option for TCP, UDP, and SCTP - A new (optional) scheduler utilization balancing mechanism - Migration of memory carriers has been enabled by default on all ERTS internal memory allocators - Increased garbage collection tenure rate - Experimental "dirty schedulers" functionality - Funs can now be given names - Miscellaneous unicode support enhancements - A new, semantic version scheme for OTP and its applications You can find the README file with more detailed info at http://www.erlang.org/download/otp_src_17.0-rc2.readme You can download the full source distribution from http://www.erlang.org/download/otp_src_17.0-rc2.tar.gz Note: To unpack the TAR archive you need a GNU TAR compatible program. For installation instructions pleaseErlang/OTP 17.0-rc2 has been released. read the README that is part of the distribution. You can also find this release at the official Erlang/OTP Git-repository at Github here: https://github.com/erlang/otp tagged *OTP_17.0-rc2* The Windows binary distribution can be downloaded from http://www.erlang.org/download/otp_win32_17.0-rc2.exe http://www.erlang.org/download/otp_win64_17.0-rc2.exe You can also download the complete HTML documentation or the Unix manual files http://www.erlang.org/download/otp_doc_html_17.0-rc2.tar.gz http://www.erlang.org/download/otp_doc_man_17.0-rc2.tar.gz We also want to thank those that sent us patches, suggestions and bug reports. The Erlang/OTP Team at Ericsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From sevenjp@REDACTED Thu Feb 27 16:42:49 2014 From: sevenjp@REDACTED (=?UTF-8?Q?Jo=C3=A3o_Neves?=) Date: Thu, 27 Feb 2014 16:42:49 +0100 Subject: [erlang-questions] [Heads up!] Emysql driver is on a roller-coaster of changes In-Reply-To: References: Message-ID: 2014-02-27 16:27 GMT+01:00 Jesper Louis Andersen < jesper.louis.andersen@REDACTED>: > Hi e-q@, > > The Emysql driver got some TLC today, and the last couple of days. If you > use it, I would like that test out v0.4.1 or master. I tried very hard to > not break backwards compatibility, but I might have failed. > > If you hate my patches, there is tags for each older release, so you > should be able to pick up an older version. > > Changes: > > * I have genuinely started to sort calls into "Public API" and "Private > API". This means I am trying to constrain the API down to just a few calls. > This is easier to maintain, and it is also less susceptible to errors and > mistakes. > Shameless self-promotion, but I'd love to see iota ( https://github.com/jpgneves/iota) being used for this in the wild if it would be appropriate. If not, do let me know your thoughts so I know what I could improve or do differently. :) > * All the conversion routines in `emysql_util` are now available from > `emysql`. I am trying to make a single-module interface to the application > so you don't need to know what is internals and not. > * Using `emysql_util` is deprecated. But the guarantee is backwards > compatibility until v1.0.0 > * The issue-tracker now has tasks to work on, if you feel inclined to help > out. > > In general, the TCP handling is a mess. And so is the protocol handling. > But it will take a bit of time until I figure out how to handle those parts > of the code base and revamp them into something more correct. I suspect > there is some speed to be gained by rewriting the code into clean naive > Erlang. > > Finally: If you have any lingering patches you would like to see added, > don't hide! Though I admit I changed a lot so reintegrating them might take > some time. > > -- > J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Jo?o Neves -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Thu Feb 27 16:56:29 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 27 Feb 2014 19:56:29 +0400 Subject: [erlang-questions] Cowboy: is it possible to detect that request is http and redirect to https? Message-ID: I've configured cowboy server to listen on port 443. User is typing: http://server:443/ and see white screen. Is it possible somehow to detect that it is plain http going to ssl port and redirect it to https? -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Thu Feb 27 16:57:56 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 27 Feb 2014 16:57:56 +0100 Subject: [erlang-questions] Cowboy: is it possible to detect that request is http and redirect to https? In-Reply-To: References: Message-ID: <530F6084.6050704@ninenines.eu> The very first argument to init/3 gives you something like {tcp, http} or {ssl, http} or {ssl, spdy}, etc. On 02/27/2014 04:56 PM, Max Lapshin wrote: > > I've configured cowboy server to listen on port 443. > > User is typing: http://server:443/ and see white screen. > > Is it possible somehow to detect that it is plain http going to ssl port > and redirect it to https? > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From max.lapshin@REDACTED Thu Feb 27 17:00:24 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 27 Feb 2014 20:00:24 +0400 Subject: [erlang-questions] Cowboy: is it possible to detect that request is http and redirect to https? In-Reply-To: <530F6084.6050704@ninenines.eu> References: <530F6084.6050704@ninenines.eu> Message-ID: No, it will not get called, because ranch is going to interpret incoming traffic as SSL, but it is plain HTTP. On Thu, Feb 27, 2014 at 7:57 PM, Lo?c Hoguin wrote: > The very first argument to init/3 gives you something like {tcp, http} or > {ssl, http} or {ssl, spdy}, etc. > > > On 02/27/2014 04:56 PM, Max Lapshin wrote: > >> >> I've configured cowboy server to listen on port 443. >> >> User is typing: http://server:443/ and see white screen. >> >> Is it possible somehow to detect that it is plain http going to ssl port >> and redirect it to https? >> >> >> >> _______________________________________________ >> 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 Thu Feb 27 17:05:30 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 27 Feb 2014 17:05:30 +0100 Subject: [erlang-questions] Cowboy: is it possible to detect that request is http and redirect to https? In-Reply-To: References: <530F6084.6050704@ninenines.eu> Message-ID: <530F624A.7070702@ninenines.eu> Oh I see, I misunderstood the question. I am guessing the connection stops in ssl:ssl_accept/1 which fails the handshake. I am not sure how you would handle something like this personally. Perhaps you can recv the first few bytes before ssl_accept, check them and unrecv if they aren't plain HTTP? But that would only (possibly) work if you have gen_tcp first and then upgrade that socket to SSL. On 02/27/2014 05:00 PM, Max Lapshin wrote: > No, it will not get called, because ranch is going to interpret incoming > traffic as SSL, but it is plain HTTP. > > > > On Thu, Feb 27, 2014 at 7:57 PM, Lo?c Hoguin > wrote: > > The very first argument to init/3 gives you something like {tcp, > http} or {ssl, http} or {ssl, spdy}, etc. > > > On 02/27/2014 04:56 PM, Max Lapshin wrote: > > > I've configured cowboy server to listen on port 443. > > User is typing: http://server:443/ and see white screen. > > Is it possible somehow to detect that it is plain http going to > ssl port > and redirect it to https? > > > > _________________________________________________ > 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 xelalex_maker@REDACTED Thu Feb 27 14:54:28 2014 From: xelalex_maker@REDACTED (Alexander Klein) Date: Thu, 27 Feb 2014 14:54:28 +0100 Subject: [erlang-questions] Difference between erl_receive and erl_receive_msg Message-ID: <530F4394.4040501@web.de> Hello, today I tried to connect Erlang to a C-backend I'm just writing: On the Erlang-side I create a port ... Port=open_port({spawn,"./a.out"},[binary,nouse_stdio,{packet,4}]). ... to which I can send some data ... port_command(Port,term_to_binary(120)). ... and decode the data on the C-side with: status = erl_receive ( 3, buffer, BUFFER ); /* a few lines snipped */ input = erl_decode ( buffer ); This approach works quite well, so far. Trying to decode with erl_receive_msg, however, never worked, since this function would throw an error immediately. On the other hand, the latter is the method used in the example on page 343 of the book by Cesarini & Thompson. The only thing that's different to the example is the fact that I don't do any of the erl_connect...-stuff used there, because the backend isn't supposed to be used by any other nodes, anyway. What am I missing? Kind regards, Alex From max.lapshin@REDACTED Thu Feb 27 17:43:00 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 27 Feb 2014 20:43:00 +0400 Subject: [erlang-questions] Cowboy: is it possible to detect that request is http and redirect to https? In-Reply-To: <530F624A.7070702@ninenines.eu> References: <530F6084.6050704@ninenines.eu> <530F624A.7070702@ninenines.eu> Message-ID: Yes, such smart things by guessing if first bytes are http or ssl. But there is no gen_tcp:unrecv :( -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Thu Feb 27 17:46:22 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 27 Feb 2014 17:46:22 +0100 Subject: [erlang-questions] Cowboy: is it possible to detect that request is http and redirect to https? In-Reply-To: References: <530F6084.6050704@ninenines.eu> <530F624A.7070702@ninenines.eu> Message-ID: <530F6BDE.20102@ninenines.eu> Sure there is, it's just undocumented. Try it, gen_tcp:unrecv(Socket, Data). On 02/27/2014 05:43 PM, Max Lapshin wrote: > Yes, such smart things by guessing if first bytes are http or ssl. > > But there is no gen_tcp:unrecv :( -- Lo?c Hoguin http://ninenines.eu From zoha.qamer@REDACTED Thu Feb 27 18:10:40 2014 From: zoha.qamer@REDACTED (Zoha Qamar) Date: Thu, 27 Feb 2014 12:10:40 -0500 Subject: [erlang-questions] Problem in NIF on windows Message-ID: Hi , I want to run NIf library on windows , for that i need to compile c code from this path as per the erlang documentation windows> cl -LD -MD -Fe complex6_nif.dll complex.c complex6_nif.c where do i need to run this command ? In cmd i run this but its giviing error for cl -LD and all -- "*Agar Tum Seedhay rastay pe ho aur kisi Mushkil ka samna nahe ker rahay to kuch dair k liyay socho k kahin tum kuch ghalt to nahe ker rahay kyon k seedha rasta to mushkilaat se bhar pur hota hy*" *Hazrat Imam Ali (A.S) * -------------- next part -------------- An HTML attachment was scrubbed... URL: From siraaj@REDACTED Thu Feb 27 18:30:33 2014 From: siraaj@REDACTED (Siraaj Khandkar) Date: Thu, 27 Feb 2014 12:30:33 -0500 Subject: [erlang-questions] Erlang and syntax. In-Reply-To: <4F318D7A-5326-4B28-AC39-AEB81CB14C06@cs.otago.ac.nz> References: <530BD803.3000103@khandkar.net> <530D6113.20009@khandkar.net> <4F318D7A-5326-4B28-AC39-AEB81CB14C06@cs.otago.ac.nz> Message-ID: <530F7639.5050602@khandkar.net> On 2/26/14, 12:06 AM, Richard A. O'Keefe wrote: >>> There are two kinds of lambda expression: >>> >>> fun Pat+ [when Guard] -> Expr >>> >>> may have multiple *arguments* but not multiple *clauses*, >>> while >>> >>> function [|] Pat [when Guard] -> Expr >>> { | Pat [when Guard] -> Expr }... >>> >>> may have multiple *clauses* but not multiple *arguments*. >>> >>> The calls to loop have parentheses around the arguments >>> (to make a tuple, because a function with multiple clauses >>> can't have multiple arguments), but the pattern matches >>> _don't_ have the parentheses. >> >> This describes the form, but does not make any judgements. Why is that >> so terrible? I don't see the problem. > > Surely nobody expects a syntax to be _capable_ of making judgements. > I don't understand you here. Sorry for poor choice of words, I meant to say that you've described the facts but did not explain why you feel it is problematic (which at this point you already did). > > The problem is having two different ways to do the same kind of > thing, both of them crippled, and neither having a name that > reminds you of the direction of its crippling. > > Back when I was trying to write O'CAML, I banged my head > on this over and over again: I wanted to write one simple > function with > - no tuples, Why the aversion to tuples? Are you planning to partially apply it? Because if so, it is not something you can do in Erlang to begin with... Erlang functions take a fixed number of arguments, which is practically equivalent to taking tuples. > - multiple arguments, and > - multiple clauses. > > Here's a simple little Erlang function: > > fun (a, b) -> 1 > ; (a, _) -> 2 > ; (_, b) -> 3 > ; (_, _) -> 4 > end > > Writing that is not simple in O'CAML, and > there doesn't seem to be any *REASON* for the restrictions. The two alternatives are very simple, see bellow. >> Sure, I can entertain the idea that having an additional form can be >> seen as less than perfectly symmetric, > > We're not talking about "less than perfect", we are talking > about *unmotivated crippling*. We're talking about having > to remember than 'fun' does multi-arg but not multi-case > and 'function' does multi-case but not multi-arg. > (If 'function' were spelled 'matchfun' it would then > *obvious* which one was like 'match' and which wasn't.) > >> There's never a >> situation where one _has_ to use the form "function" over "fun", it is >> provided merely as an alternative that you _may_ find convenient at >> times. > > No, 'function' is not "merely an alternative". > 'fun' and 'function' do _different_ things, and > neither of them does a full job. I agree that it is not fully satisfying, I would _much_ rather have only the "fun" form with clauses (and I don't actually know the history of this choice of syntax). But again, I just don't feel this outweighs all the other great aspects of the language, especially when "match" can easily fill-in for the deficiencies of "fun". See bellow. > > Let's look back at that little Erlang function. > The closest I can come in O'CAML is > > fun x y -> > match x with > | A -> match y with > | B -> 1 > | _ -> 2 > | _ -> match y with > | B -> 3 > | _ -> 4 Do you need partial application? If yes, then this: fun t t' -> match t, t' with | A, B -> 1 | A, _ -> 2 | _, B -> 3 | _, _ -> 4 if no, it is even simpler: function | A, B -> 1 | A, _ -> 2 | _, B -> 3 | _, _ -> 4 Exactly as is, your version would not work, because it is ambiguous where the second case of x belongs (as a second case of x or the 3rd case of 1st y match?). The solution would be to use parenthesis of begin...end, but it is even better to just flatten the whole thing, as I did above. Also, the indentation depth is a bit excessive, but that's a personal thing, of course. >> Though, frankly, I'm not fully satisfied with function declaration in >> any language that I'm familiar with so far. I mostly lean toward the way >> it is done in OCaml, because it reinforces the idea that a function is >> no different from any other value, so you bind it to a name in exactly >> the same way (let name = expr), where as in SML there's a distinction >> between (val name = expr) and (fun name arg1 .. argn = expr). > > But in SML nothing stops you writing > > val f = fun ... -> ... > Since "fun" is not a lambda expression, you must mean this: val f = fn ... => ...; >> And, before you bring it up as a gold standard, I find Haskell's way >> quite unsatisfactory as well. Primarily in two ways: 1) all bindings are >> _implicitly_ recursive and 2) no shadowing (which I know, from other >> discussions, that you hate, but that is a preference...). > > The implicit recursive bit -- which is what we also have in > Erlang -- is in practice what I always want, and it is strongly > connected with the free order of function definitions -- which > we also have in Erlang. In Erlang it is far less surprising, because it only appears in module-level function definitions, not for just any name binding. $ erl 1> 1> X = X. * 2: variable 'X' is unbound 2> $ ghci Prelude> Prelude> let x = x Prelude> Prelude> x Never returns! > _Not_ having to have a weird special form for declaring > a group of mutually recursive functions is one of the > things that had me running from SML to Haskell (and Erlang!). Being a bear of very little brain, I want mutual recursion to be explicit and "let rec" and "and" are a miniscule syntactic price to pay for the aid in reasoning that it gives to the reader (_and_ writer for that matter, since you get compiler feedback). >> There has been a lot of interesting progress in both, the OCaml >> language and ecosystem, since the last time you seriously looked at it >> (which I can only imagine must have been a while): > > There are some incredibly interesting tools I would like to use > that are written in O'CAML. I even went to the trouble of > setting up a special VirtualBox VM running a specific version > of Linux to run one of them. That was last year. Everything works for me on Mac as well as Ubuntu. The only things I could not get to build on a Mac were IDE for Why3 and GUI for Unison (though it I think there's a packaged binary available online somewhere). >> - recursive modules >> - private types (which differ from abstract types by allowing reading >> but still not constructing the representation) >> - locally abstract types (which allow "shared secrets", that Harper >> said were only possible in SML [2]) >> - first-class modules >> - GADTs! >> - a really awesome package manager [3] > > Those are all nice things, although I note that the Goedel > programming language had GADTs back in the 1980s -- mainly > because John Lloyd couldn't think of a reason _not_ to > offer them. He wasn't aware of the type inference issues > they cause, but since Goedel did type checking, not type > inference, that wouldn't have been a problem anyway. > > I have kept going back to O'CAML because of the fantastic > things that have been done with it, but I have really really > bad memories of GODI. If OPAM lets me forget about GODI, > I may try O'CAML again. Indeed, OPAM is quite an improvement. I'm not sure that I can even spell GoDdy anymore :) >>>>> (S where S = 0 then S+X*Y || X <- Xs & Y <- Ys). >>>> >>>> Where is S coming from here? >>> >>> From the 'where' part. It's >>> ( where ,... || ) >>> and a is >>> = [then ]. >>> >>> 'let P = E0 in E1' and 'E1 where P = E0' are traditional >>> alternatives in functional programming. >>> >>> It's a cross between Lisp's DO (the part and the >>> part) and comprehensions (the part). >> >> I really like the idea of being able to express "X <- Xs & Y <- Ys", >> but, even with the explanation, I still find the left hand side quite >> unintuitive. > > Familiarity again. > > First, multiple generators in parallel is a straight > steal from Clean. > Second, > where > was back in Landin's "The next 700 programming languages" paper > and has appeared in several programming languages since ISWIM. > > The proposed syntax has (Expression where Matches) > as a special case. "where" as an alternative to "let" is quite nice and I like the way it works in Haskell. What I found unintuitive in your proposal is the initialization of the accumulator and the usage of "then". Having looked at it long-enough though, it is kind of growing on me, but certainly was strange at first :) > Having used both 'let' and 'where' in > Haskell, I find that > > roots a b c = (-b + sqrt discrim)/(2*a) > where discrim = b^2 - 4*a*c > > reads better than > > roots a bc = > let discrim = b^2 - 4*a*c > in (-b + sqrt discrim)/(2*a) > > In Haskell, 'let' and 'where' do slightly different things > ('let' is local to an expression, 'where' goes with a > group of guarded alternatives in the same clause). > > I tried (let [while ] [|| ] > in ) > but found that it was more awkward. > > What really matters is that we _could_ have a form that does > for fold+map+filter what list comprehensions do for map+filter. From rtrlists@REDACTED Thu Feb 27 19:11:03 2014 From: rtrlists@REDACTED (Robert Raschke) Date: Thu, 27 Feb 2014 18:11:03 +0000 Subject: [erlang-questions] Difference between erl_receive and erl_receive_msg In-Reply-To: <530F4394.4040501@web.de> References: <530F4394.4040501@web.de> Message-ID: >From memory, I think your interpretation is correct. The _msg function expects an Erlang message from the distribution layer, not just a simple binary term. For that you'd need to promote your "simple" C code to be a proper C node. That's not too difficult and brings further benefits, like being able to rpc into Erlang from C. Robby On Feb 27, 2014 4:13 PM, "Alexander Klein" wrote: > Hello, > > today I tried to connect Erlang to a C-backend I'm just writing: > > On the Erlang-side I create a port ... > > Port=open_port({spawn,"./a.out"},[binary,nouse_stdio,{packet,4}]). > > ... to which I can send some data ... > > port_command(Port,term_to_binary(120)). > > ... and decode the data on the C-side with: > > status = erl_receive ( 3, buffer, BUFFER ); > /* a few lines snipped */ > input = erl_decode ( buffer ); > > This approach works quite well, so far. > > Trying to decode with erl_receive_msg, however, never worked, since this > function would throw an error immediately. > > On the other hand, the latter is the method used in the example on page > 343 of the book by Cesarini & Thompson. > > The only thing that's different to the example is the fact that I don't do > any of the erl_connect...-stuff used there, because the backend isn't > supposed to be used by any other nodes, anyway. > > What am I missing? > > Kind regards, > > Alex > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Thu Feb 27 19:22:30 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Thu, 27 Feb 2014 10:22:30 -0800 (PST) Subject: [erlang-questions] [ANN] emdoc-1.0 Message-ID: <1393525350.60465.YahooMailNeo@web140106.mail.bf1.yahoo.com> So you want to get better internal documentation but you haven't gone into edoc yet. Why not use markdown instead? https://github.com/thomasl/emdoc It made my own code docs look nicer, anyway. Pull requests welcome. Best, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergej.jurecko@REDACTED Thu Feb 27 19:24:04 2014 From: sergej.jurecko@REDACTED (Sergej Jurecko) Date: Thu, 27 Feb 2014 19:24:04 +0100 Subject: [erlang-questions] Problem in NIF on windows In-Reply-To: References: Message-ID: <88D3FB3A-F6D3-4550-922C-2ED2B4342810@gmail.com> Use rebar. Install git for windows, add erlang to PATH, compile rebar for windows, then compile your library with that rebar. If you are not using any external dependencies rebar will most likely be able to compile it without any windows specific configuration. Sergej On Feb 27, 2014, at 6:10 PM, Zoha Qamar wrote: > > Hi , > > I want to run NIf library on windows , for that i need to compile c code from this path as per the erlang documentation > > windows> cl -LD -MD -Fe complex6_nif.dll complex.c complex6_nif.c > where do i need to run this command ? In cmd i run this but its giviing error for cl -LD and all > > > -- > "*Agar Tum Seedhay rastay pe ho aur kisi Mushkil ka samna nahe ker rahay to > kuch dair k liyay socho k kahin tum kuch ghalt to nahe ker rahay kyon k > seedha rasta to mushkilaat se bhar pur hota hy*" *Hazrat Imam Ali (A.S) * > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From mallen@REDACTED Thu Feb 27 19:54:25 2014 From: mallen@REDACTED (Mark Allen) Date: Thu, 27 Feb 2014 12:54:25 -0600 Subject: [erlang-questions] [ANN] emdoc-1.0 In-Reply-To: <1393525350.60465.YahooMailNeo@web140106.mail.bf1.yahoo.com> References: <1393525350.60465.YahooMailNeo@web140106.mail.bf1.yahoo.com> Message-ID: Excited to see this and use this. Thanks. Mark From: Thomas Lindgren > Reply-To: Thomas Lindgren > Date: Thursday, February 27, 2014 12:22 PM To: erlang-questions > Subject: [erlang-questions] [ANN] emdoc-1.0 So you want to get better internal documentation but you haven't gone into edoc yet. Why not use markdown instead? https://github.com/thomasl/emdoc It made my own code docs look nicer, anyway. Pull requests welcome. Best, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean@REDACTED Thu Feb 27 20:02:09 2014 From: sean@REDACTED (Sean Cribbs) Date: Thu, 27 Feb 2014 13:02:09 -0600 Subject: [erlang-questions] [ANN] emdoc-1.0 In-Reply-To: References: <1393525350.60465.YahooMailNeo@web140106.mail.bf1.yahoo.com> Message-ID: There's also edown: https://github.com/esl/edown On Thu, Feb 27, 2014 at 12:54 PM, Mark Allen wrote: > Excited to see this and use this. > > Thanks. > > Mark > > From: Thomas Lindgren > Reply-To: Thomas Lindgren > Date: Thursday, February 27, 2014 12:22 PM > To: erlang-questions > Subject: [erlang-questions] [ANN] emdoc-1.0 > > So you want to get better internal documentation but you haven't gone into > edoc yet. Why not use markdown instead? > > https://github.com/thomasl/emdoc > > It made my own code docs look nicer, anyway. Pull requests welcome. > > Best, > Thomas > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Thu Feb 27 22:51:01 2014 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 27 Feb 2014 22:51:01 +0100 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc2 has been released. In-Reply-To: References: Message-ID: Great The build process is a lot cleaner now - very nice, I pleased to see you got rid of loads of messy output messages during the build. /Joe On Thu, Feb 27, 2014 at 4:33 PM, Kenneth Lundin wrote: > Erlang/OTP 17.0-rc2 has been released. > > This is a beta release, which will be followed by the final OTP 17.0 > product release in the beginning of April. > > Between this beta and the final release there will be new updates of the > master branch with corrections and minor new features. Occasionally there > might be new tags which we in that case will communicate and ask you to > test. > > Erlang/OTP 17.0 is a new major release with new features, quite a few > (characteristics) improvements, as well as some incompatibilities. See the > README file and the documentation for more details. > > We would like to ask you to download and test the beta release and send us > your feedback as soon as possible, so that we can make the necessary > corrections before OTP 17.0. > > The release contains many changes and a few potential incompatibilities. > Please try to build and run your current products/applications and let us > know about any problems. > > One known, but previously insufficiently documented incompatibility that > we would like to highlight is: > > OTP-11719 == erts == > > *The default encoding of Erlang files has been changed from ISO-8859-1 to > UTF-8. The encoding of XML files has also been changed to UTF-8.* > > Please verify that your source code compiles with Erlang/OTP 17. If your > (ISO-8559-1 / Latin-1 encoded) source code files contain characters that > are outside of the bit 7-bit ASCII character set, you will receive a > compiler error similar to the following: > > tst.erl:1: cannot parse file, giving up > tst.erl:1: no module definition > tst.erl:1: cannot translate from UTF-8 > > In this case, you need to apply one of the following alternatives to each > (impacted) file: > > Alternative 1: Encode the file in UTF-8 (instead of Latin-1). If the file > is going to be compiled with both OTP 17 and previous versions, insert a > comment stating the encoding at the beginning of the file: > > %% -*- coding: utf-8 -*- > > Alternative 2: Leave the file encoded as Latin-1 and insert a comment > stating the encoding at the beginning of the file: > > %% -*- coding: latin-1 -*- > > For detailed information, see the STDLIB User's Guide, 2 Using Unicode > in Erlang > > The 17.0 release contains many changes; thus, some unexpected > incompatibilities or issues may have slipped through our tests. Please try > to build and run your current products/applications and let us know about > any problems. > > Note! The new datatype MAP is not properly documented yet but the EEP 43 > https://www.erlang.org/eeps/eep-0043.html will provide a good start. Also > note that it is a limited implementation of maps implemented so far: > > - no variable keys are allowed > - native code can not be generated for modules using maps > > Some other highlights of the release are: > > - Erlang/OTP has been ported to the realtime operating system OSE. > - Maps, a new dictionary data type (experimental) > - A more natural mapping from ASN.1 OCTET STRING and BIT STRING to > Erlang types, and other ASN.1 improvements and optimizations > - The {active, N} socket option for TCP, UDP, and SCTP > - A new (optional) scheduler utilization balancing mechanism > - Migration of memory carriers has been enabled by default on all ERTS > internal memory allocators > - Increased garbage collection tenure rate > - Experimental "dirty schedulers" functionality > - Funs can now be given names > - Miscellaneous unicode support enhancements > - A new, semantic version scheme for OTP and its applications > > You can find the README file with more detailed info at > http://www.erlang.org/download/otp_src_17.0-rc2.readme > > You can download the full source distribution from > http://www.erlang.org/download/otp_src_17.0-rc2.tar.gz > > Note: To unpack the TAR archive you need a GNU TAR compatible program. For > installation instructions pleaseErlang/OTP 17.0-rc2 has been released. read > the README that is part of the distribution. > > You can also find this release at the official Erlang/OTP Git-repository > at Github here: https://github.com/erlang/otp tagged *OTP_17.0-rc2* > > The Windows binary distribution can be downloaded from > > http://www.erlang.org/download/otp_win32_17.0-rc2.exe > http://www.erlang.org/download/otp_win64_17.0-rc2.exe > > You can also download the complete HTML documentation or the Unix manual > files http://www.erlang.org/download/otp_doc_html_17.0-rc2.tar.gz > http://www.erlang.org/download/otp_doc_man_17.0-rc2.tar.gz > > We also want to thank those that sent us patches, suggestions and bug > reports. > > The Erlang/OTP Team at Ericsson > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Thu Feb 27 22:51:25 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 28 Feb 2014 10:51:25 +1300 Subject: [erlang-questions] atoms with newlines In-Reply-To: <530F4122.9090400@wanadoo.fr> References: <3D506AA6-D4E1-4887-B76B-51FA12BCF353@cs.otago.ac.nz> <6B6D7CCC-E823-44A9-B7D9-7268C4CFAEC9@cs.otago.ac.nz> <19A12F28-802B-4F7C-8DF4-F5D6E7B6134C@cs.otago.ac.nz> <9395A238-F3F4-476A-B9D5-A0AF417A46BB@cs.otago.ac.nz> <530F4122.9090400@wanadoo.fr> Message-ID: On 28/02/2014, at 2:44 AM, PAILLEAU Eric wrote: > Maybe not very homogeneous... > > By the way, I do not really see the need to include \n in atoms... The current thread is about *NOT* including \n in atoms. An atom in Erlang may be up to 255 characters long. If you are trying to keep your source files to a reasonable width limit, this means that 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\ AAAAAAAAAAAAAAAAAAAAAAA' has to be broken up across multiple lines. Except that you can't, because there is currently no way NOT to include a newline in an atom literal. There is also no Atom1 ++ Atom2. The NAME_MAX limit is typically 255 on the machines I use. Being able to write _any_ simple file name as an Erlang atom is often handy. > From eric.pailleau@REDACTED Thu Feb 27 23:14:51 2014 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Thu, 27 Feb 2014 23:14:51 +0100 Subject: [erlang-questions] atoms with newlines In-Reply-To: References: <3D506AA6-D4E1-4887-B76B-51FA12BCF353@cs.otago.ac.nz> <6B6D7CCC-E823-44A9-B7D9-7268C4CFAEC9@cs.otago.ac.nz> <19A12F28-802B-4F7C-8DF4-F5D6E7B6134C@cs.otago.ac.nz> <9395A238-F3F4-476A-B9D5-A0AF417A46BB@cs.otago.ac.nz> <530F4122.9090400@wanadoo.fr> Message-ID: <530FB8DB.5080101@wanadoo.fr> Hi, Richard, I understood the thread. I only wondering why \n is allowed in atoms, in general. I agree that the parser should considere 'aaaa' 'bbbb' the same manner "aaaa" "bbbb" and concatenate... This would solve your problem... I suppose you have certainly thought to this unsatisfactory solution : A = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" "AAAAAAAAAAAAAAAAAAAAAAA". list_to_atom(A). regards Le 27/02/2014 22:51, Richard A. O'Keefe a ?crit : > > On 28/02/2014, at 2:44 AM, PAILLEAU Eric wrote: >> Maybe not very homogeneous... >> >> By the way, I do not really see the need to include \n in atoms... > > The current thread is about *NOT* including \n in atoms. > > An atom in Erlang may be up to 255 characters long. > If you are trying to keep your source files to a reasonable > width limit, this means that > > 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\ > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\ > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\ > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\ > AAAAAAAAAAAAAAAAAAAAAAA' > > has to be broken up across multiple lines. > > Except that you can't, because there is currently no way > NOT to include a newline in an atom literal. > > There is also no Atom1 ++ Atom2. > > The NAME_MAX limit is typically 255 on the machines I use. > Being able to write _any_ simple file name as an Erlang > atom is often handy. > >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From jesper.louis.andersen@REDACTED Fri Feb 28 00:06:34 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 28 Feb 2014 00:06:34 +0100 Subject: [erlang-questions] Breaking backwards compatibility in Release 17.0-rc2 Message-ID: Release 17.0 brings two changes which prove to take some work getting around. 1. utf-8 is now the default encoding. This is a rather insignificant change. The source code which uses latin1 can be fixed by one of three ways: * Tell the compiler the file is latin1. This won't work going forward but works now. * Change the file to utf-8. This won't work going backward a long way. But it will work going backwards for a bit. * Change the file to ASCII. This works both backward and forward as long as we want. This is a benign problem. I have tried compiling some projects and it turns out there are numerous repositories which needs fixing now. But the fix is rather simple. 2. Dialyzer dislikes queue(), dict(), ... Dialyzer now prefers using queue:queue() and the like. This is *definitely* the right thing to support as it is much more consistent with the rest of the system and doesn't treat certain types as magically introduced types. -module(z). -export([f/1]). -spec f(queue:queue()) -> queue:queue(). f(Q) -> queue:in(3, Q). Which is nice, but this doesn't work on R16B03: z.erl:5: referring to built-in type queue as a remote type; please take out the module name z.erl:5: referring to built-in type queue as a remote type; please take out the module name So here, I have no way of getting my source code to work with both R16 and 17.0 easily. There is no transition period so-to-speak. Many projects run with warnings-as-errors and they are in trouble: * They can't compile * They can remove the warnings-as-errors but this defeats the purpose * They will have warnings spewed out over the console all the time In the case of crypto:hash/2, we had somewhat the same situation. Prominent projects like Yaws, and lesser projects like Emysql has EPP macros in place as well as detection in order to figure out what to do. Or you can disable the warnings in this case specifically for this. But can I do the same with wrong type specs? Also, this workaround is done in almost every project out there, which is darn irritating. I don't know what we need to solve this. At one point, I would really like to have a set of feature flags http://www.lispworks.com/documentation/HyperSpec/Body/v_featur.htm , ZFS, ... where you have a way to compile-time scrutinize what your environment supports. Another way to solve it is the variant Go uses, namely "build constraints" http://golang.org/pkg/go/build/#pkg-overview which will mention under which circumstances to include a file as a part of an application. This would allow for easy handling of crypto:hash/2, but I do note it will fail on the dialyzer problem. It looks like the only sane way to solve that is to allow both queue() and queue:queue() as aliases for a major release and then proceed to remove queue(). Am I completely wrong here? I can accept languages evolve and that Release 17 has maps which will be used and break a lot of software for R16 quickly. But I also feel we should have some way of having a process so there is a way to handle this gracefully going forward. It is natural for libraries and languages to evolve and break compatibility. Yet, it should be easy to handle for programmers. There is much time wasted, which could be used better were there a nice solution. Thoughts? -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From darach@REDACTED Fri Feb 28 00:34:42 2014 From: darach@REDACTED (Darach Ennis) Date: Thu, 27 Feb 2014 23:34:42 +0000 Subject: [erlang-questions] Breaking backwards compatibility in Release 17.0-rc2 In-Reply-To: References: Message-ID: Hi Jesper, all, Feature flags would be ideal if/when breaking changes are required if only to resolve issues with having to relax warnings-as-errors which, as you say, is not good for those of us who prefer to be warning free. But, feature flags introduce a maintenance concern if flags hang around for too many releases. They should give offer time enough for code being actively maintained to catch up, whilst being short-lived enough that the language can evolve. One of the first behavioural changes I quickly adopted when moving from casual to daily erlang use was to enable all warnings and treat warnings as errors. Cheers, Darach. On Thu, Feb 27, 2014 at 11:06 PM, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > Release 17.0 brings two changes which prove to take some work getting > around. > > 1. utf-8 is now the default encoding. > > This is a rather insignificant change. The source code which uses latin1 > can be fixed by one of three ways: > > * Tell the compiler the file is latin1. This won't work going forward but > works now. > * Change the file to utf-8. This won't work going backward a long way. But > it will work going backwards for a bit. > * Change the file to ASCII. This works both backward and forward as long > as we want. > > This is a benign problem. I have tried compiling some projects and it > turns out there are numerous repositories which needs fixing now. But the > fix is rather simple. > > 2. Dialyzer dislikes queue(), dict(), ... > > Dialyzer now prefers using queue:queue() and the like. This is > *definitely* the right thing to support as it is much more consistent with > the rest of the system and doesn't treat certain types as magically > introduced types. > > -module(z). > > -export([f/1]). > > -spec f(queue:queue()) -> queue:queue(). > f(Q) -> queue:in(3, Q). > > Which is nice, but this doesn't work on R16B03: > > z.erl:5: referring to built-in type queue as a remote type; please take > out the module name > z.erl:5: referring to built-in type queue as a remote type; please take > out the module name > > So here, I have no way of getting my source code to work with both R16 and > 17.0 easily. There is no transition period so-to-speak. Many projects run > with warnings-as-errors and they are in trouble: > > * They can't compile > * They can remove the warnings-as-errors but this defeats the purpose > * They will have warnings spewed out over the console all the time > > In the case of crypto:hash/2, we had somewhat the same situation. > Prominent projects like Yaws, and lesser projects like Emysql has EPP > macros in place as well as detection in order to figure out what to do. Or > you can disable the warnings in this case specifically for this. But can I > do the same with wrong type specs? Also, this workaround is done in almost > every project out there, which is darn irritating. > > I don't know what we need to solve this. At one point, I would really like > to have a set of feature flags > > http://www.lispworks.com/documentation/HyperSpec/Body/v_featur.htm , ZFS, > ... > > where you have a way to compile-time scrutinize what your environment > supports. Another way to solve it is the variant Go uses, namely "build > constraints" > > http://golang.org/pkg/go/build/#pkg-overview > > which will mention under which circumstances to include a file as a part > of an application. This would allow for easy handling of crypto:hash/2, but > I do note it will fail on the dialyzer problem. It looks like the only sane > way to solve that is to allow both queue() and queue:queue() as aliases for > a major release and then proceed to remove queue(). > > Am I completely wrong here? I can accept languages evolve and that Release > 17 has maps which will be used and break a lot of software for R16 quickly. > But I also feel we should have some way of having a process so there is a > way to handle this gracefully going forward. It is natural for libraries > and languages to evolve and break compatibility. Yet, it should be easy to > handle for programmers. There is much time wasted, which could be used > better were there a nice solution. > > Thoughts? > > -- > J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthonym@REDACTED Fri Feb 28 01:08:36 2014 From: anthonym@REDACTED (ANTHONY MOLINARO) Date: Thu, 27 Feb 2014 16:08:36 -0800 Subject: [erlang-questions] Breaking backwards compatibility in Release 17.0-rc2 In-Reply-To: References: Message-ID: I also have felt this pain with the transition from behaviour_info to callbacks for behaviours. Ideally, the preprocessor would define a macro along the lines of ?MODULE, ?MODULE_STRING, ?FILE, ?LINE, and ?MACHINE which is the full list according to http://www.erlang.org/doc/reference_manual/macros.html. If there was one additional macro call ?RELEASE with the major release, then it would be possible to conditionally compile at least dialyzer stuff (I don't know about the file encoding, I guess it would depend on whether the check is done during the preprocessor or at a later step). This would probably prevent the proliferation of different compile macros which seem to crop up as every individual library adds their own based on a rebar or makefile check. -Anthony On Feb 27, 2014, at 3:06 PM, Jesper Louis Andersen wrote: > Release 17.0 brings two changes which prove to take some work getting around. > > 1. utf-8 is now the default encoding. > > This is a rather insignificant change. The source code which uses latin1 can be fixed by one of three ways: > > * Tell the compiler the file is latin1. This won't work going forward but works now. > * Change the file to utf-8. This won't work going backward a long way. But it will work going backwards for a bit. > * Change the file to ASCII. This works both backward and forward as long as we want. > > This is a benign problem. I have tried compiling some projects and it turns out there are numerous repositories which needs fixing now. But the fix is rather simple. > > 2. Dialyzer dislikes queue(), dict(), ... > > Dialyzer now prefers using queue:queue() and the like. This is *definitely* the right thing to support as it is much more consistent with the rest of the system and doesn't treat certain types as magically introduced types. > > -module(z). > > -export([f/1]). > > -spec f(queue:queue()) -> queue:queue(). > f(Q) -> queue:in(3, Q). > > Which is nice, but this doesn't work on R16B03: > > z.erl:5: referring to built-in type queue as a remote type; please take out the module name > z.erl:5: referring to built-in type queue as a remote type; please take out the module name > > So here, I have no way of getting my source code to work with both R16 and 17.0 easily. There is no transition period so-to-speak. Many projects run with warnings-as-errors and they are in trouble: > > * They can't compile > * They can remove the warnings-as-errors but this defeats the purpose > * They will have warnings spewed out over the console all the time > > In the case of crypto:hash/2, we had somewhat the same situation. Prominent projects like Yaws, and lesser projects like Emysql has EPP macros in place as well as detection in order to figure out what to do. Or you can disable the warnings in this case specifically for this. But can I do the same with wrong type specs? Also, this workaround is done in almost every project out there, which is darn irritating. > > I don't know what we need to solve this. At one point, I would really like to have a set of feature flags > > http://www.lispworks.com/documentation/HyperSpec/Body/v_featur.htm , ZFS, ... > > where you have a way to compile-time scrutinize what your environment supports. Another way to solve it is the variant Go uses, namely "build constraints" > > http://golang.org/pkg/go/build/#pkg-overview > > which will mention under which circumstances to include a file as a part of an application. This would allow for easy handling of crypto:hash/2, but I do note it will fail on the dialyzer problem. It looks like the only sane way to solve that is to allow both queue() and queue:queue() as aliases for a major release and then proceed to remove queue(). > > Am I completely wrong here? I can accept languages evolve and that Release 17 has maps which will be used and break a lot of software for R16 quickly. But I also feel we should have some way of having a process so there is a way to handle this gracefully going forward. It is natural for libraries and languages to evolve and break compatibility. Yet, it should be easy to handle for programmers. There is much time wasted, which could be used better were there a nice solution. > > Thoughts? > > -- > J. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablo.platt@REDACTED Fri Feb 28 01:14:57 2014 From: pablo.platt@REDACTED (pablo platt) Date: Fri, 28 Feb 2014 02:14:57 +0200 Subject: [erlang-questions] DTLS client/server In-Reply-To: References: <-2812677860635758685@unknownmsgid> Message-ID: Hi Andreas, It seems that DLTS won't be ready for R17. Is your implementation stable to use in production? Do I need to prefix your ssl app so it won't interfere with the otp ssl app? Can you explain how to use it? > For udp, lib/ssl/src/ssl_udp.erl already exists and > [{versions, ['dtlsv1.2', dtlsv1]}, {cb_info, ssl_udp}] in your ssl options > should work > Do I use ssl_udp like a normal udp socket? Do I need to extend it to support dtls-srtp? http://tools.ietf.org/html/rfc5764 > DTLS-SRTP requires sending use_srtp in extended hello and exchanging SRTP > keys. > DTLS-SRTP also requires that RTP and STUN messages are forwarded to the > app. > Thanks On Mon, Feb 3, 2014 at 10:56 AM, Ingela Andin wrote: > Hi Pablo! > > Progress of DTLS will be included in R17, I will however not have time > enough to make it a fully supported feature. > Other high priority things have competed with it for my time. I am working > with it at the moment but time flies and > the only thing I can promise is that there will be some more pieces in > place. > > Regards Ingela Erlang/OTP Team - Ericsson AB > > > 2014-02-02 pablo platt : > > I didn't see anything about DTLS in the R17 RC1 release notes. >> Will this be included in the final R17 release? >> >> >> On Thu, Dec 12, 2013 at 3:17 PM, pablo platt wrote: >> >>> Thanks >>> >>> >>> On Thu, Dec 12, 2013 at 2:55 PM, Ingela Andin wrote: >>> >>>> >>>> Hi! >>>> >>>> 2013/12/12 pablo platt >>>> >>>>> Hi >>>>> >>>>> >>>>> Will it be possible to use DTLS for DTLS-SRTP when it will be released? >>>>> http://tools.ietf.org/html/rfc5764 >>>>> >>>>> >>>>> DTLS-SRTP requires sending use_srtp in extended hello and exchanging SRTP keys. >>>>> >>>>> DTLS-SRTP also requires that RTP and STUN messages are forwarded to the app. >>>>> >>>>> >>>>> >>>>> >>>>> Will there be support out of the box for such extension? >>>>> >>>>> >>>> No this will not work out of the box. But once DTLS is in place it >>>> could be a fairly easy user contribution ;) >>>> >>>> >>>> Regards Ingela Erlang/OTP Team Ericssson AB >>>> >>>> >>>>> >>>>> On Fri, Oct 18, 2013 at 5:07 AM, pablo platt wrote: >>>>> >>>>>> A preview in a few weeks will be great. >>>>>> >>>>>> Thanks >>>>>> >>>>>> >>>>>> On Fri, Oct 18, 2013 at 12:12 AM, Ingela Andin < >>>>>> ingela.andin@REDACTED> wrote: >>>>>> >>>>>>> Hi! >>>>>>> >>>>>>> >>>>>>> 2013/10/17 pablo platt >>>>>>> >>>>>>>> Is there a chance for release preview of DTLS before the R17 >>>>>>>> release on February? >>>>>>>> >>>>>>>> >>>>>>> Alas, I still do not have anything releasable that is runnable. I >>>>>>> have had to work with some other stuff in between. >>>>>>> But I think previews can be possible. I have a rather large step in >>>>>>> the pipeline that I probably can release in a few weeks >>>>>>> as it then can be merged to maint. This step will include some code >>>>>>> from Andreas that implements basic stuff. But >>>>>>> the internal structure of the code is quite different and the API is >>>>>>> not totally set yet. >>>>>>> >>>>>>> Regards Ingela Erlang/OTP team - Ericsson AB >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Feb 28 01:20:56 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 28 Feb 2014 01:20:56 +0100 Subject: [erlang-questions] Breaking backwards compatibility in Release 17.0-rc2 In-Reply-To: References: Message-ID: <530FD668.2090505@ninenines.eu> My plans are the following: *master* officially supports only RB and RB for building. If supporting RB is too annoying (for example R14 vs R15 -callback), then RB support is quickly dropped from master. (Of course, if master can support even RB, then it is supported.) *RB branches* are branches created for older versions of Erlang that were dropped from master. Two scenarios may happen. * If making master compatible with that version of Erlang can be automated with a small script (a few regexpes, for example similar to s/binary_to_integer/list_to_integer(binary_to_list/g), then they can continue to follow master and receive new features. When releasing a new version, a special tag would be created with the Erlang version clearly indicated, for example 1.2.3-R16. * Otherwise, it's handled like an API breaking version and only important bug fixes get backported. Before tagging a new release, you simply have to run tests across all versions (which you should do anyway). If building fails then, a new branch is required. Branches need to be updated for the upcoming release and tests ran for them too. It can almost all be automated. People who follow master understand that things may break already, so they are not a concern. The good thing of all that is that you can now always write code using the latest features of the VM, and only have to worry about older Erlang releases when you increment your version. The bad thing is that the code for older Erlang releases might not be as Dialyzer friendly or as optimal as it could be. But at least it compiles. None of this requires any change in how the OTP team currently does things, and it is completely future proof. On 02/28/2014 12:06 AM, Jesper Louis Andersen wrote: > Release 17.0 brings two changes which prove to take some work getting > around. > > 1. utf-8 is now the default encoding. > > This is a rather insignificant change. The source code which uses latin1 > can be fixed by one of three ways: > > * Tell the compiler the file is latin1. This won't work going forward > but works now. > * Change the file to utf-8. This won't work going backward a long way. > But it will work going backwards for a bit. > * Change the file to ASCII. This works both backward and forward as long > as we want. > > This is a benign problem. I have tried compiling some projects and it > turns out there are numerous repositories which needs fixing now. But > the fix is rather simple. > > 2. Dialyzer dislikes queue(), dict(), ... > > Dialyzer now prefers using queue:queue() and the like. This is > *definitely* the right thing to support as it is much more consistent > with the rest of the system and doesn't treat certain types as magically > introduced types. > > -module(z). > > -export([f/1]). > > -spec f(queue:queue()) -> queue:queue(). > f(Q) -> queue:in(3, Q). > > Which is nice, but this doesn't work on R16B03: > > z.erl:5: referring to built-in type queue as a remote type; please take > out the module name > z.erl:5: referring to built-in type queue as a remote type; please take > out the module name > > So here, I have no way of getting my source code to work with both R16 > and 17.0 easily. There is no transition period so-to-speak. Many > projects run with warnings-as-errors and they are in trouble: > > * They can't compile > * They can remove the warnings-as-errors but this defeats the purpose > * They will have warnings spewed out over the console all the time > > In the case of crypto:hash/2, we had somewhat the same situation. > Prominent projects like Yaws, and lesser projects like Emysql has EPP > macros in place as well as detection in order to figure out what to do. > Or you can disable the warnings in this case specifically for this. But > can I do the same with wrong type specs? Also, this workaround is done > in almost every project out there, which is darn irritating. > > I don't know what we need to solve this. At one point, I would really > like to have a set of feature flags > > http://www.lispworks.com/documentation/HyperSpec/Body/v_featur.htm , > ZFS, ... > > where you have a way to compile-time scrutinize what your environment > supports. Another way to solve it is the variant Go uses, namely "build > constraints" > > http://golang.org/pkg/go/build/#pkg-overview > > which will mention under which circumstances to include a file as a part > of an application. This would allow for easy handling of crypto:hash/2, > but I do note it will fail on the dialyzer problem. It looks like the > only sane way to solve that is to allow both queue() and queue:queue() > as aliases for a major release and then proceed to remove queue(). > > Am I completely wrong here? I can accept languages evolve and that > Release 17 has maps which will be used and break a lot of software for > R16 quickly. But I also feel we should have some way of having a process > so there is a way to handle this gracefully going forward. It is natural > for libraries and languages to evolve and break compatibility. Yet, it > should be easy to handle for programmers. There is much time wasted, > which could be used better were there a nice solution. > > Thoughts? > > -- > J. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From ok@REDACTED Fri Feb 28 01:22:12 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 28 Feb 2014 13:22:12 +1300 Subject: [erlang-questions] atoms with newlines In-Reply-To: <530FB8DB.5080101@wanadoo.fr> References: <3D506AA6-D4E1-4887-B76B-51FA12BCF353@cs.otago.ac.nz> <6B6D7CCC-E823-44A9-B7D9-7268C4CFAEC9@cs.otago.ac.nz> <19A12F28-802B-4F7C-8DF4-F5D6E7B6134C@cs.otago.ac.nz> <9395A238-F3F4-476A-B9D5-A0AF417A46BB@cs.otago.ac.nz> <530F4122.9090400@wanadoo.fr> <530FB8DB.5080101@wanadoo.fr> Message-ID: On 28/02/2014, at 11:14 AM, PAILLEAU Eric wrote: > I only wondering why \n is allowed in atoms, in general. Why should \177 be allowed but not \n? Just because SOME atoms are meant for people to read and write does not mean that ALL atoms are. > This would solve your problem... There are two problems. One is the problem of writing long atom names unreadably. The other is the way that backslash+newline is accepted but does the opposite of what you are likely to expect. > I suppose you have certainly thought to this unsatisfactory solution : > > A = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" > "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" > "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" > "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" > "AAAAAAAAAAAAAAAAAAAAAAA". > list_to_atom(A). That does not work in patterns, and it doesn't work in data structures stored in files in Erlang syntax. Maybe this is one of the things that release 17 could fix... From kenji@REDACTED Fri Feb 28 02:13:02 2014 From: kenji@REDACTED (Kenji Rikitake) Date: Fri, 28 Feb 2014 10:13:02 +0900 Subject: [erlang-questions] Building 17.0-rc2 (and R16B03-1) with wxWidgets on OS X 10.9.2 64bit Re: [ANN] Erlang/OTP 17.0-rc2 has been released. In-Reply-To: References: Message-ID: <20140228011302.GA38638@k2r.org> I've written a memo for building 17.0-rc2 (and R16B03-1) with wxWidgets on OS X 10.9.2 (with --enable-darwin-64bit): https://gist.github.com/jj1bdx/9262726 See also http://blog.equanimity.nl/blog/2014/02/09/erlang-r17-rc1-on-osx-with-wx-and-a-working-observer/ Note that on OS X Cocoa environment wx:demo() still looks unstable, while observer:start() works OK. This is a huge advantage. Note 2: on FreeBSD 10.0-STABLE amd64 with wxgtk 2.8.12 (from Ports) works just fine on 17.0-rc2. Thanks Kenneth and the OTP team for 17.0-rc2! Kenji Rikitake ++> Kenneth Lundin [2014-02-27 16:33:16 +0100]: > Erlang/OTP 17.0-rc2 has been released. From sdl.web@REDACTED Fri Feb 28 03:02:49 2014 From: sdl.web@REDACTED (Leo Liu) Date: Fri, 28 Feb 2014 10:02:49 +0800 Subject: [erlang-questions] Building 17.0-rc2 (and R16B03-1) with wxWidgets on OS X 10.9.2 64bit Re: [ANN] Erlang/OTP 17.0-rc2 has been released. References: <20140228011302.GA38638@k2r.org> Message-ID: On 2014-02-28 09:13 +0800, Kenji Rikitake wrote: > I've written a memo for building 17.0-rc2 (and R16B03-1) with wxWidgets on OS X > 10.9.2 (with --enable-darwin-64bit): > > https://gist.github.com/jj1bdx/9262726 Seems it is getting easier to build on Mac: 1. brew install wxmac --disable-monolithic Note: --disable-monolithic is to become the default in Homebrew 2. ./configure && make && make install install-docs and I have erlang 17 64bit running. Leo From sdl.web@REDACTED Fri Feb 28 03:13:01 2014 From: sdl.web@REDACTED (Leo Liu) Date: Fri, 28 Feb 2014 10:13:01 +0800 Subject: [erlang-questions] [ANN] emdoc-1.0 References: <1393525350.60465.YahooMailNeo@web140106.mail.bf1.yahoo.com> Message-ID: On 2014-02-28 03:02 +0800, Sean Cribbs wrote: > There's also edown: https://github.com/esl/edown Any plan to merge it with edoc? Leo From kenji@REDACTED Fri Feb 28 03:30:10 2014 From: kenji@REDACTED (Kenji Rikitake) Date: Fri, 28 Feb 2014 11:30:10 +0900 Subject: [erlang-questions] Building 17.0-rc2 (and R16B03-1) with wxWidgets on OS X 10.9.2 64bit Re: [ANN] Erlang/OTP 17.0-rc2 has been released. In-Reply-To: References: <20140228011302.GA38638@k2r.org> Message-ID: <20140228023010.GA39070@k2r.org> I failed on `brew install wxmac` but looks like the `--disable-monolithic` will be the key (as reported in various Web resources.) I'll quote your article in my Gist. Thanks. Kenji Rikitake ++> Leo Liu [2014-02-28 10:02:49 +0800]: > On 2014-02-28 09:13 +0800, Kenji Rikitake wrote: > > I've written a memo for building 17.0-rc2 (and R16B03-1) with wxWidgets on OS X > > 10.9.2 (with --enable-darwin-64bit): > > > > https://gist.github.com/jj1bdx/9262726 > > Seems it is getting easier to build on Mac: > > 1. brew install wxmac --disable-monolithic > Note: --disable-monolithic is to become the default in Homebrew > > 2. ./configure && make && make install install-docs > > and I have erlang 17 64bit running. > > Leo From kenji@REDACTED Fri Feb 28 03:44:37 2014 From: kenji@REDACTED (Kenji Rikitake) Date: Fri, 28 Feb 2014 11:44:37 +0900 Subject: [erlang-questions] "Remote" types in Erlang (Re: Breaking backwards compatibility in Release 17.0-rc2) In-Reply-To: References: Message-ID: <20140228024437.GB39070@k2r.org> While I agree with the need of feature flags or the run time environment version identifier macros, I think the following Dialyzer type issue needs transitional solution between R16 and 17 and a separate attention from the OTP team. I've been just facing this issue while I'm writing pieces of code for coming Erlang Factory. I should also say that orddict() was not among the "magically introduced types" in R16B03-1; I had to steal the definition from lib/stdlib/src/orddict.erl in R16B03-1. Kenji Rikitake ++> Jesper Louis Andersen [2014-02-28 00:06:34 +0100]: > Release 17.0 brings two changes which prove to take some work getting > around. [snip] > 2. Dialyzer dislikes queue(), dict(), ... > > Dialyzer now prefers using queue:queue() and the like. This is *definitely* > the right thing to support as it is much more consistent with the rest of > the system and doesn't treat certain types as magically introduced types. > > -module(z). > > -export([f/1]). > > -spec f(queue:queue()) -> queue:queue(). > f(Q) -> queue:in(3, Q). > > Which is nice, but this doesn't work on R16B03: > > z.erl:5: referring to built-in type queue as a remote type; please take out > the module name > z.erl:5: referring to built-in type queue as a remote type; please take out > the module name > > So here, I have no way of getting my source code to work with both R16 and > 17.0 easily. There is no transition period so-to-speak. Many projects run > with warnings-as-errors and they are in trouble: > > * They can't compile > * They can remove the warnings-as-errors but this defeats the purpose > * They will have warnings spewed out over the console all the time > > In the case of crypto:hash/2, we had somewhat the same situation. Prominent > projects like Yaws, and lesser projects like Emysql has EPP macros in place > as well as detection in order to figure out what to do. Or you can disable > the warnings in this case specifically for this. But can I do the same with > wrong type specs? Also, this workaround is done in almost every project out > there, which is darn irritating. > > I don't know what we need to solve this. At one point, I would really like > to have a set of feature flags > > http://www.lispworks.com/documentation/HyperSpec/Body/v_featur.htm , ZFS, > ... > > where you have a way to compile-time scrutinize what your environment > supports. Another way to solve it is the variant Go uses, namely "build > constraints" > > http://golang.org/pkg/go/build/#pkg-overview > > which will mention under which circumstances to include a file as a part of > an application. This would allow for easy handling of crypto:hash/2, but I > do note it will fail on the dialyzer problem. It looks like the only sane > way to solve that is to allow both queue() and queue:queue() as aliases for > a major release and then proceed to remove queue(). > > Am I completely wrong here? I can accept languages evolve and that Release > 17 has maps which will be used and break a lot of software for R16 quickly. > But I also feel we should have some way of having a process so there is a > way to handle this gracefully going forward. It is natural for libraries > and languages to evolve and break compatibility. Yet, it should be easy to > handle for programmers. There is much time wasted, which could be used > better were there a nice solution. > > Thoughts? > > -- > J. From vladdu55@REDACTED Fri Feb 28 09:36:51 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 28 Feb 2014 09:36:51 +0100 Subject: [erlang-questions] Breaking backwards compatibility in Release 17.0-rc2 In-Reply-To: References: Message-ID: Hi, I've been hit by this too, as I have a patched debugger that I need to compile on older versions too and there are issues with unicode/maps/named funs. Unfortunately, there might be cases where code will still have to be duplicated, because macros can only wrap full forms. >From a brief look att epp.erl, it feels like adding a ?OTP_RELEASE or ?OTP_VERSION predefined macro would be easy and the only possible problem is if there are user-defined macros with the same name. predef_macros(File) -> Machine = list_to_atom(erlang:system_info(machine)), {ok, Release0} = file:read_file(code:root_dir()++"/OTP_VERSION"), Release = string:strip(Release0, right, $\n), ... {{atom,'OTP_RELEASE'}, {none,[{string,1,Release}]}}, ... By the way, wouldn't it be useful to have an erlang:system_info() that reads the file and strips the 'ok' and the whitespace? best regards, Vlad On Fri, Feb 28, 2014 at 1:08 AM, ANTHONY MOLINARO < anthonym@REDACTED> wrote: > I also have felt this pain with the transition from behaviour_info to > callbacks for behaviours. Ideally, the preprocessor would define a macro > along the lines of ?MODULE, ?MODULE_STRING, ?FILE, ?LINE, and ?MACHINE > which is the full list according to > http://www.erlang.org/doc/reference_manual/macros.html. > > If there was one additional macro call ?RELEASE with the major release, > then it would be possible to conditionally compile at least dialyzer stuff > (I don't know about the file encoding, I guess it would depend on whether > the check is done during the preprocessor or at a later step). This would > probably prevent the proliferation of different compile macros which seem > to crop up as every individual library adds their own based on a rebar or > makefile check. > > -Anthony > > On Feb 27, 2014, at 3:06 PM, Jesper Louis Andersen < > jesper.louis.andersen@REDACTED> wrote: > > Release 17.0 brings two changes which prove to take some work getting > around. > > 1. utf-8 is now the default encoding. > > This is a rather insignificant change. The source code which uses latin1 > can be fixed by one of three ways: > > * Tell the compiler the file is latin1. This won't work going forward but > works now. > * Change the file to utf-8. This won't work going backward a long way. But > it will work going backwards for a bit. > * Change the file to ASCII. This works both backward and forward as long > as we want. > > This is a benign problem. I have tried compiling some projects and it > turns out there are numerous repositories which needs fixing now. But the > fix is rather simple. > > 2. Dialyzer dislikes queue(), dict(), ... > > Dialyzer now prefers using queue:queue() and the like. This is > *definitely* the right thing to support as it is much more consistent with > the rest of the system and doesn't treat certain types as magically > introduced types. > > -module(z). > > -export([f/1]). > > -spec f(queue:queue()) -> queue:queue(). > f(Q) -> queue:in(3, Q). > > Which is nice, but this doesn't work on R16B03: > > z.erl:5: referring to built-in type queue as a remote type; please take > out the module name > z.erl:5: referring to built-in type queue as a remote type; please take > out the module name > > So here, I have no way of getting my source code to work with both R16 and > 17.0 easily. There is no transition period so-to-speak. Many projects run > with warnings-as-errors and they are in trouble: > > * They can't compile > * They can remove the warnings-as-errors but this defeats the purpose > * They will have warnings spewed out over the console all the time > > In the case of crypto:hash/2, we had somewhat the same situation. > Prominent projects like Yaws, and lesser projects like Emysql has EPP > macros in place as well as detection in order to figure out what to do. Or > you can disable the warnings in this case specifically for this. But can I > do the same with wrong type specs? Also, this workaround is done in almost > every project out there, which is darn irritating. > > I don't know what we need to solve this. At one point, I would really like > to have a set of feature flags > > http://www.lispworks.com/documentation/HyperSpec/Body/v_featur.htm , ZFS, > ... > > where you have a way to compile-time scrutinize what your environment > supports. Another way to solve it is the variant Go uses, namely "build > constraints" > > http://golang.org/pkg/go/build/#pkg-overview > > which will mention under which circumstances to include a file as a part > of an application. This would allow for easy handling of crypto:hash/2, but > I do note it will fail on the dialyzer problem. It looks like the only sane > way to solve that is to allow both queue() and queue:queue() as aliases for > a major release and then proceed to remove queue(). > > Am I completely wrong here? I can accept languages evolve and that Release > 17 has maps which will be used and break a lot of software for R16 quickly. > But I also feel we should have some way of having a process so there is a > way to handle this gracefully going forward. It is natural for libraries > and languages to evolve and break compatibility. Yet, it should be easy to > handle for programmers. There is much time wasted, which could be used > better were there a nice solution. > > Thoughts? > > -- > J. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arif@REDACTED Fri Feb 28 09:45:59 2014 From: arif@REDACTED (arif@REDACTED) Date: Fri, 28 Feb 2014 00:45:59 -0800 Subject: [erlang-questions] system_info in R17.0-rc02 Message-ID: I can get erlang:system_info(otp_release) to give "17", but erlang:system_info(otp_correction_package) seems to balk. I remember there was mention on the list that otp_correction_package may get changed to otp_version, but that doesn't work either. The erlang.erl source file still has otp_release and otp_correction_package as the possible parameters in the specification of the system_info function. Am I doing something wrong? Thanks and best regards From vladdu55@REDACTED Fri Feb 28 10:01:16 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 28 Feb 2014 10:01:16 +0100 Subject: [erlang-questions] Breaking backwards compatibility in Release 17.0-rc2 In-Reply-To: References: Message-ID: I realized just now that the macros would only help me partially, as compiling with the 17.0 compiler will produce a beam that won't run on R15... I will have to find a different solution or to abandon the patched version. Anyway, a patch for the ?OTP_VERSION is available at https://github.com/vladdu/otp/compare/erlang:master...version_macro. Of course, maybe the name is not the right one and there's documentation to add, if this is a change that is wanted. regards, Vlad On Fri, Feb 28, 2014 at 9:36 AM, Vlad Dumitrescu wrote: > Hi, > > I've been hit by this too, as I have a patched debugger that I need to > compile on older versions too and there are issues with unicode/maps/named > funs. Unfortunately, there might be cases where code will still have to be > duplicated, because macros can only wrap full forms. > > From a brief look att epp.erl, it feels like adding a ?OTP_RELEASE or > ?OTP_VERSION predefined macro would be easy and the only possible problem > is if there are user-defined macros with the same name. > > predef_macros(File) -> > Machine = list_to_atom(erlang:system_info(machine)), > {ok, Release0} = file:read_file(code:root_dir()++"/OTP_VERSION"), > Release = string:strip(Release0, right, $\n), > ... > {{atom,'OTP_RELEASE'}, {none,[{string,1,Release}]}}, > ... > > By the way, wouldn't it be useful to have an erlang:system_info() that > reads the file and strips the 'ok' and the whitespace? > > best regards, > Vlad > > > On Fri, Feb 28, 2014 at 1:08 AM, ANTHONY MOLINARO < > anthonym@REDACTED> wrote: > >> I also have felt this pain with the transition from behaviour_info to >> callbacks for behaviours. Ideally, the preprocessor would define a macro >> along the lines of ?MODULE, ?MODULE_STRING, ?FILE, ?LINE, and ?MACHINE >> which is the full list according to >> http://www.erlang.org/doc/reference_manual/macros.html. >> >> If there was one additional macro call ?RELEASE with the major release, >> then it would be possible to conditionally compile at least dialyzer stuff >> (I don't know about the file encoding, I guess it would depend on whether >> the check is done during the preprocessor or at a later step). This would >> probably prevent the proliferation of different compile macros which seem >> to crop up as every individual library adds their own based on a rebar or >> makefile check. >> >> -Anthony >> >> On Feb 27, 2014, at 3:06 PM, Jesper Louis Andersen < >> jesper.louis.andersen@REDACTED> wrote: >> >> Release 17.0 brings two changes which prove to take some work getting >> around. >> >> 1. utf-8 is now the default encoding. >> >> This is a rather insignificant change. The source code which uses latin1 >> can be fixed by one of three ways: >> >> * Tell the compiler the file is latin1. This won't work going forward but >> works now. >> * Change the file to utf-8. This won't work going backward a long way. >> But it will work going backwards for a bit. >> * Change the file to ASCII. This works both backward and forward as long >> as we want. >> >> This is a benign problem. I have tried compiling some projects and it >> turns out there are numerous repositories which needs fixing now. But the >> fix is rather simple. >> >> 2. Dialyzer dislikes queue(), dict(), ... >> >> Dialyzer now prefers using queue:queue() and the like. This is >> *definitely* the right thing to support as it is much more consistent with >> the rest of the system and doesn't treat certain types as magically >> introduced types. >> >> -module(z). >> >> -export([f/1]). >> >> -spec f(queue:queue()) -> queue:queue(). >> f(Q) -> queue:in(3, Q). >> >> Which is nice, but this doesn't work on R16B03: >> >> z.erl:5: referring to built-in type queue as a remote type; please take >> out the module name >> z.erl:5: referring to built-in type queue as a remote type; please take >> out the module name >> >> So here, I have no way of getting my source code to work with both R16 >> and 17.0 easily. There is no transition period so-to-speak. Many projects >> run with warnings-as-errors and they are in trouble: >> >> * They can't compile >> * They can remove the warnings-as-errors but this defeats the purpose >> * They will have warnings spewed out over the console all the time >> >> In the case of crypto:hash/2, we had somewhat the same situation. >> Prominent projects like Yaws, and lesser projects like Emysql has EPP >> macros in place as well as detection in order to figure out what to do. Or >> you can disable the warnings in this case specifically for this. But can I >> do the same with wrong type specs? Also, this workaround is done in almost >> every project out there, which is darn irritating. >> >> I don't know what we need to solve this. At one point, I would really >> like to have a set of feature flags >> >> http://www.lispworks.com/documentation/HyperSpec/Body/v_featur.htm , >> ZFS, ... >> >> where you have a way to compile-time scrutinize what your environment >> supports. Another way to solve it is the variant Go uses, namely "build >> constraints" >> >> http://golang.org/pkg/go/build/#pkg-overview >> >> which will mention under which circumstances to include a file as a part >> of an application. This would allow for easy handling of crypto:hash/2, but >> I do note it will fail on the dialyzer problem. It looks like the only sane >> way to solve that is to allow both queue() and queue:queue() as aliases for >> a major release and then proceed to remove queue(). >> >> Am I completely wrong here? I can accept languages evolve and that >> Release 17 has maps which will be used and break a lot of software for R16 >> quickly. But I also feel we should have some way of having a process so >> there is a way to handle this gracefully going forward. It is natural for >> libraries and languages to evolve and break compatibility. Yet, it should >> be easy to handle for programmers. There is much time wasted, which could >> be used better were there a nice solution. >> >> Thoughts? >> >> -- >> J. >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Feb 28 10:09:06 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 28 Feb 2014 10:09:06 +0100 Subject: [erlang-questions] Breaking backwards compatibility in Release 17.0-rc2 In-Reply-To: References: Message-ID: <53105232.6090807@ninenines.eu> A macro for ?OTP_RELEASE or ?OTP_VERSION makes *absolutely no sense*. There are no guarantees that people are going to compile on a fresh Erlang release. If I create a release named PONIES, this will not help at all when I then use the compiler app I included to compile some stuff at runtime. Something a little better is ?COMPILER_VERSION, but people might also run a custom compiler code with a custom version number, so that's a no go either. On 02/28/2014 09:36 AM, Vlad Dumitrescu wrote: > Hi, > > I've been hit by this too, as I have a patched debugger that I need to > compile on older versions too and there are issues with > unicode/maps/named funs. Unfortunately, there might be cases where code > will still have to be duplicated, because macros can only wrap full forms. > > From a brief look att epp.erl, it feels like adding a ?OTP_RELEASE or > ?OTP_VERSION predefined macro would be easy and the only possible > problem is if there are user-defined macros with the same name. > > predef_macros(File) -> > Machine = list_to_atom(erlang:system_info(machine)), > {ok, Release0} = file:read_file(code:root_dir()++"/OTP_VERSION"), > Release = string:strip(Release0, right, $\n), > ... > {{atom,'OTP_RELEASE'}, {none,[{string,1,Release}]}}, > ... > > By the way, wouldn't it be useful to have an erlang:system_info() that > reads the file and strips the 'ok' and the whitespace? > > best regards, > Vlad > > > On Fri, Feb 28, 2014 at 1:08 AM, ANTHONY MOLINARO > > wrote: > > I also have felt this pain with the transition from behaviour_info > to callbacks for behaviours. Ideally, the preprocessor would define > a macro along the lines of ?MODULE, ?MODULE_STRING, ?FILE, ?LINE, > and ?MACHINE which is the full list according to > http://www.erlang.org/doc/reference_manual/macros.html. > > If there was one additional macro call ?RELEASE with the major > release, then it would be possible to conditionally compile at least > dialyzer stuff (I don't know about the file encoding, I guess it > would depend on whether the check is done during the preprocessor or > at a later step). This would probably prevent the proliferation of > different compile macros which seem to crop up as every individual > library adds their own based on a rebar or makefile check. > > -Anthony > > On Feb 27, 2014, at 3:06 PM, Jesper Louis Andersen > > wrote: > >> Release 17.0 brings two changes which prove to take some work >> getting around. >> >> 1. utf-8 is now the default encoding. >> >> This is a rather insignificant change. The source code which uses >> latin1 can be fixed by one of three ways: >> >> * Tell the compiler the file is latin1. This won't work going >> forward but works now. >> * Change the file to utf-8. This won't work going backward a long >> way. But it will work going backwards for a bit. >> * Change the file to ASCII. This works both backward and forward >> as long as we want. >> >> This is a benign problem. I have tried compiling some projects and >> it turns out there are numerous repositories which needs fixing >> now. But the fix is rather simple. >> >> 2. Dialyzer dislikes queue(), dict(), ... >> >> Dialyzer now prefers using queue:queue() and the like. This is >> *definitely* the right thing to support as it is much more >> consistent with the rest of the system and doesn't treat certain >> types as magically introduced types. >> >> -module(z). >> >> -export([f/1]). >> >> -spec f(queue:queue()) -> queue:queue(). >> f(Q) -> queue:in(3, Q). >> >> Which is nice, but this doesn't work on R16B03: >> >> z.erl:5: referring to built-in type queue as a remote type; please >> take out the module name >> z.erl:5: referring to built-in type queue as a remote type; please >> take out the module name >> >> So here, I have no way of getting my source code to work with both >> R16 and 17.0 easily. There is no transition period so-to-speak. >> Many projects run with warnings-as-errors and they are in trouble: >> >> * They can't compile >> * They can remove the warnings-as-errors but this defeats the purpose >> * They will have warnings spewed out over the console all the time >> >> In the case of crypto:hash/2, we had somewhat the same situation. >> Prominent projects like Yaws, and lesser projects like Emysql has >> EPP macros in place as well as detection in order to figure out >> what to do. Or you can disable the warnings in this case >> specifically for this. But can I do the same with wrong type >> specs? Also, this workaround is done in almost every project out >> there, which is darn irritating. >> >> I don't know what we need to solve this. At one point, I would >> really like to have a set of feature flags >> >> http://www.lispworks.com/documentation/HyperSpec/Body/v_featur.htm >> , ZFS, ... >> >> where you have a way to compile-time scrutinize what your >> environment supports. Another way to solve it is the variant Go >> uses, namely "build constraints" >> >> http://golang.org/pkg/go/build/#pkg-overview >> >> which will mention under which circumstances to include a file as >> a part of an application. This would allow for easy handling of >> crypto:hash/2, but I do note it will fail on the dialyzer problem. >> It looks like the only sane way to solve that is to allow both >> queue() and queue:queue() as aliases for a major release and then >> proceed to remove queue(). >> >> Am I completely wrong here? I can accept languages evolve and that >> Release 17 has maps which will be used and break a lot of software >> for R16 quickly. But I also feel we should have some way of having >> a process so there is a way to handle this gracefully going >> forward. It is natural for libraries and languages to evolve and >> break compatibility. Yet, it should be easy to handle for >> programmers. There is much time wasted, which could be used better >> were there a nice solution. >> >> Thoughts? >> >> -- >> J. >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From dch@REDACTED Fri Feb 28 10:19:43 2014 From: dch@REDACTED (Dave Cottlehuber) Date: Fri, 28 Feb 2014 10:19:43 +0100 Subject: [erlang-questions] Building 17.0-rc2 (and R16B03-1) with wxWidgets on OS X 10.9.2 64bit Re: [ANN] Erlang/OTP 17.0-rc2 has been released. In-Reply-To: <20140228023010.GA39070@k2r.org> References: <20140228011302.GA38638@k2r.org> <20140228023010.GA39070@k2r.org> Message-ID: I updated the homebrew recipe and made a gist; https://gist.github.com/dch/9267866 ``` brew update brew install wxmac --disable-monolithic brew install --with-wx --no-docs -v --devel erlang ``` or directly from the gist: ``` brew install wxmac --disable-monolithic && brew install --with-wx --no-docs -v --devel https://gist.githubusercontent.com/dch/9267866/raw/erlang.rb ``` If I get a couple of +1 back, I'll send it to homebrew as a PR. Huge thanks to Dan & OTP team, this compatibility for observer & friends has been a long time coming! On 28 February 2014 03:30, Kenji Rikitake wrote: > I failed on `brew install wxmac` but looks like the `--disable-monolithic` > will be the key (as reported in various Web resources.) I'll quote your > article in my Gist. Thanks. > Kenji Rikitake > > ++> Leo Liu [2014-02-28 10:02:49 +0800]: > > On 2014-02-28 09:13 +0800, Kenji Rikitake wrote: > > > I've written a memo for building 17.0-rc2 (and R16B03-1) with > wxWidgets on OS X > > > 10.9.2 (with --enable-darwin-64bit): > > > > > > https://gist.github.com/jj1bdx/9262726 > > > > Seems it is getting easier to build on Mac: > > > > 1. brew install wxmac --disable-monolithic > > Note: --disable-monolithic is to become the default in Homebrew > > > > 2. ./configure && make && make install install-docs > > > > and I have erlang 17 64bit running. > > > > Leo > _______________________________________________ > 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 Fri Feb 28 10:45:34 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 28 Feb 2014 10:45:34 +0100 Subject: [erlang-questions] Breaking backwards compatibility in Release 17.0-rc2 In-Reply-To: <53105232.6090807@ninenines.eu> References: <53105232.6090807@ninenines.eu> Message-ID: On Fri, Feb 28, 2014 at 10:09 AM, Lo?c Hoguin wrote: > A macro for ?OTP_RELEASE or ?OTP_VERSION makes *absolutely no sense*. > There are no guarantees that people are going to compile on a fresh Erlang > release. If I create a release named PONIES, this will not help at all when > I then use the compiler app I included to compile some stuff at runtime. > > Something a little better is ?COMPILER_VERSION, but people might also run > a custom compiler code with a custom version number, so that's a no go > either. > > It would make sense for me, that's why I considered it. However, I agree that my use case is special and is probably not enough to support this addition by itself. Since I have a patched debugger for erlide and I don't know which version will users run their code on, I need to provide separate debuggers for all supported versions and I am going to compile the code on fresh releases. This isn't a problem until there are incompatibilities. I suppose that the debugger is stable enough that I could maintain different patched variants for the different versions, but it's still work that could be used for other features/improvements/fixes. regards, Vlad > > On 02/28/2014 09:36 AM, Vlad Dumitrescu wrote: > >> Hi, >> >> I've been hit by this too, as I have a patched debugger that I need to >> compile on older versions too and there are issues with >> unicode/maps/named funs. Unfortunately, there might be cases where code >> will still have to be duplicated, because macros can only wrap full forms. >> >> From a brief look att epp.erl, it feels like adding a ?OTP_RELEASE or >> ?OTP_VERSION predefined macro would be easy and the only possible >> problem is if there are user-defined macros with the same name. >> >> predef_macros(File) -> >> Machine = list_to_atom(erlang:system_info(machine)), >> {ok, Release0} = file:read_file(code:root_dir()++"/OTP_VERSION"), >> Release = string:strip(Release0, right, $\n), >> ... >> {{atom,'OTP_RELEASE'}, {none,[{string,1,Release}]}}, >> ... >> >> By the way, wouldn't it be useful to have an erlang:system_info() that >> reads the file and strips the 'ok' and the whitespace? >> >> best regards, >> Vlad >> >> >> On Fri, Feb 28, 2014 at 1:08 AM, ANTHONY MOLINARO >> > wrote: >> >> I also have felt this pain with the transition from behaviour_info >> to callbacks for behaviours. Ideally, the preprocessor would define >> a macro along the lines of ?MODULE, ?MODULE_STRING, ?FILE, ?LINE, >> and ?MACHINE which is the full list according to >> http://www.erlang.org/doc/reference_manual/macros.html. >> >> If there was one additional macro call ?RELEASE with the major >> release, then it would be possible to conditionally compile at least >> dialyzer stuff (I don't know about the file encoding, I guess it >> would depend on whether the check is done during the preprocessor or >> at a later step). This would probably prevent the proliferation of >> different compile macros which seem to crop up as every individual >> library adds their own based on a rebar or makefile check. >> >> -Anthony >> >> On Feb 27, 2014, at 3:06 PM, Jesper Louis Andersen >> > > wrote: >> >> Release 17.0 brings two changes which prove to take some work >>> getting around. >>> >>> 1. utf-8 is now the default encoding. >>> >>> This is a rather insignificant change. The source code which uses >>> latin1 can be fixed by one of three ways: >>> >>> * Tell the compiler the file is latin1. This won't work going >>> forward but works now. >>> * Change the file to utf-8. This won't work going backward a long >>> way. But it will work going backwards for a bit. >>> * Change the file to ASCII. This works both backward and forward >>> as long as we want. >>> >>> This is a benign problem. I have tried compiling some projects and >>> it turns out there are numerous repositories which needs fixing >>> now. But the fix is rather simple. >>> >>> 2. Dialyzer dislikes queue(), dict(), ... >>> >>> Dialyzer now prefers using queue:queue() and the like. This is >>> *definitely* the right thing to support as it is much more >>> consistent with the rest of the system and doesn't treat certain >>> types as magically introduced types. >>> >>> -module(z). >>> >>> -export([f/1]). >>> >>> -spec f(queue:queue()) -> queue:queue(). >>> f(Q) -> queue:in(3, Q). >>> >>> Which is nice, but this doesn't work on R16B03: >>> >>> z.erl:5: referring to built-in type queue as a remote type; please >>> take out the module name >>> z.erl:5: referring to built-in type queue as a remote type; please >>> take out the module name >>> >>> So here, I have no way of getting my source code to work with both >>> R16 and 17.0 easily. There is no transition period so-to-speak. >>> Many projects run with warnings-as-errors and they are in trouble: >>> >>> * They can't compile >>> * They can remove the warnings-as-errors but this defeats the purpose >>> * They will have warnings spewed out over the console all the time >>> >>> In the case of crypto:hash/2, we had somewhat the same situation. >>> Prominent projects like Yaws, and lesser projects like Emysql has >>> EPP macros in place as well as detection in order to figure out >>> what to do. Or you can disable the warnings in this case >>> specifically for this. But can I do the same with wrong type >>> specs? Also, this workaround is done in almost every project out >>> there, which is darn irritating. >>> >>> I don't know what we need to solve this. At one point, I would >>> really like to have a set of feature flags >>> >>> http://www.lispworks.com/documentation/HyperSpec/Body/v_featur.htm >>> , ZFS, ... >>> >>> where you have a way to compile-time scrutinize what your >>> environment supports. Another way to solve it is the variant Go >>> uses, namely "build constraints" >>> >>> http://golang.org/pkg/go/build/#pkg-overview >>> >>> which will mention under which circumstances to include a file as >>> a part of an application. This would allow for easy handling of >>> crypto:hash/2, but I do note it will fail on the dialyzer problem. >>> It looks like the only sane way to solve that is to allow both >>> queue() and queue:queue() as aliases for a major release and then >>> proceed to remove queue(). >>> >>> Am I completely wrong here? I can accept languages evolve and that >>> Release 17 has maps which will be used and break a lot of software >>> for R16 quickly. But I also feel we should have some way of having >>> a process so there is a way to handle this gracefully going >>> forward. It is natural for libraries and languages to evolve and >>> break compatibility. Yet, it should be easy to handle for >>> programmers. There is much time wasted, which could be used better >>> were there a nice solution. >>> >>> Thoughts? >>> >>> -- >>> J. >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> >> _______________________________________________ >> 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 davidnwelton@REDACTED Fri Feb 28 13:36:17 2014 From: davidnwelton@REDACTED (David Welton) Date: Fri, 28 Feb 2014 13:36:17 +0100 Subject: [erlang-questions] Jinterface, Android, and epmd Message-ID: Hi, I'm wondering if anyone has any ideas regarding a problem we are facing. It appears that Erlang's JInterface requires the local machine to have an epmd daemon running, which, for an Android system, is neither pleasant nor clean: http://www.isotope11.com/blog/android-and-erlang-interop-with-jinterface Are there any other workarounds? Say, implementing just enough of epmd to route what needs routing to the one local node? Thank you -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From carlsson.richard@REDACTED Fri Feb 28 13:48:23 2014 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Fri, 28 Feb 2014 13:48:23 +0100 Subject: [erlang-questions] [ANN] Erlang/OTP 17.0-rc2 has been released. In-Reply-To: References: Message-ID: <53108597.6020401@gmail.com> On 2014-02-27 16:33 , Kenneth Lundin wrote: > OTP-11719 == erts == > > *The default encoding of Erlang files has been changed from ISO-8859-1 > to UTF-8. The encoding of XML files has also been changed to UTF-8.* > > Please verify that your source code compiles with Erlang/OTP 17. If your > (ISO-8559-1 / Latin-1 encoded) source code files contain characters that > are outside of the bit 7-bit ASCII character set, you will receive a > compiler error similar to the following: > > tst.erl:1: cannot parse file, giving up > tst.erl:1: no module definition > tst.erl:1: cannot translate from UTF-8 > > In this case, you need to apply one of the following alternatives to > each (impacted) file: > > Alternative 1: Encode the file in UTF-8 (instead of Latin-1). If the > file is going to be compiled with both OTP 17 and previous versions, > insert a comment stating the encoding at the beginning of the file: > > %% -*- coding: utf-8 -*- > > Alternative 2: Leave the file encoded as Latin-1 and insert a comment > stating the encoding at the beginning of the file: > > %% -*- coding: latin-1 -*- I expected to have an erlc flag that would tell epp which encoding to default to in case there is no info in the files. Or did I miss it? Having to edit hundreds of files owned by many different development teams before I can get this through the compiler is a non-starter. (It seems that adding more options to epp requires a new function. May I suggest open/1 that takes a list [{file,...}, ...].) /Richard From fly@REDACTED Fri Feb 28 14:07:55 2014 From: fly@REDACTED (Fred Youhanaie) Date: Fri, 28 Feb 2014 13:07:55 +0000 Subject: [erlang-questions] Jinterface, Android, and epmd In-Reply-To: References: Message-ID: <53108A2B.7040903@anydata.co.uk> On 28/02/14 12:36, David Welton wrote: > Hi, > > I'm wondering if anyone has any ideas regarding a problem we are facing. > > It appears that Erlang's JInterface requires the local machine to have > an epmd daemon running, which, for an Android system, is neither > pleasant nor clean: > > http://www.isotope11.com/blog/android-and-erlang-interop-with-jinterface > > Are there any other workarounds? Say, implementing just enough of > epmd to route what needs routing to the one local node? You won't be the first to do it :-) http://erlang.org/pipermail/erlang-questions/2013-November/076016.html I also remember seeing an implementation of epmd in erlang, but I can't find the link! Cheers Fred From davidnwelton@REDACTED Fri Feb 28 14:12:16 2014 From: davidnwelton@REDACTED (David Welton) Date: Fri, 28 Feb 2014 14:12:16 +0100 Subject: [erlang-questions] Jinterface, Android, and epmd In-Reply-To: References: Message-ID: > JInterface relies on erlang distribution protocol, thus empd is mandatory. > The workaround is either use ports or raw sockets for communication. > > Why do you say that empd is not good? Having to run a separate, native code process is added complexity and overhead. I wonder if there's anyone who has implemented just enough of epmd as a library that could be integrated in an Android app.... Looks like there is, according to Fred's message. Let's see if that can be tracked down. -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From davidnwelton@REDACTED Fri Feb 28 14:13:41 2014 From: davidnwelton@REDACTED (David Welton) Date: Fri, 28 Feb 2014 14:13:41 +0100 Subject: [erlang-questions] jinterface and epmd In-Reply-To: References: Message-ID: Hi, Did you ever release this anywhere? This would be very useful for Android apps attempting to integrate with Erlang. Thank you On Fri, Nov 15, 2013 at 11:23 AM, Minin Maxim wrote: > Hello, > > i have a little question about jinterface - the communication between an > erlang app and an java app (on two different machines) needs epmd on both > machines. In my environment there are no possibility to install epmd on the > java-machine. That's why I rewrote epmd in java. It can be started as > singlton in jvm and acts as normal epmd. Is anyone interested on that > solution and what is the best way to pull this implementation to otp > standard lib (if there is one)? > > Thanks > Maxim Minin > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From Maxim.Minin@REDACTED Fri Feb 28 15:12:01 2014 From: Maxim.Minin@REDACTED (Minin Maxim) Date: Fri, 28 Feb 2014 15:12:01 +0100 Subject: [erlang-questions] jinterface and epmd Message-ID: Hi, No, I didn't - nobody was interesting in my library until now. I can release it on github next Sunday or Monday. But you don't really want to use it for android apps - if you communicate from java to erlang over erlang messaging system, you have to share cookies between nodes. It can be very dangerous :) In my case I use this lib to communicate between server components on different machines in a security environment. Regards Maxim -----Urspr?ngliche Nachricht----- Von: David Welton [mailto:davidnwelton@REDACTED] Gesendet: Freitag, 28. Februar 2014 14:14 An: Minin Maxim; Lorenzo Bartoli Cc: erlang-questions@REDACTED Betreff: Re: [erlang-questions] jinterface and epmd Hi, Did you ever release this anywhere? This would be very useful for Android apps attempting to integrate with Erlang. Thank you On Fri, Nov 15, 2013 at 11:23 AM, Minin Maxim wrote: > Hello, > > i have a little question about jinterface - the communication between > an erlang app and an java app (on two different machines) needs epmd > on both machines. In my environment there are no possibility to > install epmd on the java-machine. That's why I rewrote epmd in java. > It can be started as singlton in jvm and acts as normal epmd. Is > anyone interested on that solution and what is the best way to pull > this implementation to otp standard lib (if there is one)? > > Thanks > Maxim Minin > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From andreas@REDACTED Fri Feb 28 15:39:37 2014 From: andreas@REDACTED (Andreas Schumacher) Date: Fri, 28 Feb 2014 15:39:37 +0100 Subject: [erlang-questions] FW: Breaking backwards compatibility in Release 17.0-rc2 In-Reply-To: <58912684E2630B45963406CF7D8C52581C363BC5@ESESSMB103.ericsson.se> References: <58912684E2630B45963406CF7D8C52581C363BC5@ESESSMB103.ericsson.se> Message-ID: <53109FA9.8030403@erlang.org> Re: 1. utf-8 is now default encoding The first bullet should only be: "Tell the compiler the file is latin-1." That is, this is supposed to work going forward. Andreas On 02/28/2014 01:05 PM, Andreas Schumacher wrote: > > *From:*erlang-questions-bounces@REDACTED > [mailto:erlang-questions-bounces@REDACTED] *On Behalf Of *Jesper > Louis Andersen > *Sent:* den 28 februari 2014 00:07 > *To:* Erlang (E-mail) > *Subject:* [erlang-questions] Breaking backwards compatibility in > Release 17.0-rc2 > > Release 17.0 brings two changes which prove to take some work getting > around. > > 1. utf-8 is now the default encoding. > > This is a rather insignificant change. The source code which uses > latin1 can be fixed by one of three ways: > > * Tell the compiler the file is latin1. This won't work going forward > but works now. > > * Change the file to utf-8. This won't work going backward a long way. > But it will work going backwards for a bit. > > * Change the file to ASCII. This works both backward and forward as > long as we want. > > This is a benign problem. I have tried compiling some projects and it > turns out there are numerous repositories which needs fixing now. But > the fix is rather simple. > > 2. Dialyzer dislikes queue(), dict(), ... > > Dialyzer now prefers using queue:queue() and the like. This is > *definitely* the right thing to support as it is much more consistent > with the rest of the system and doesn't treat certain types as > magically introduced types. > > -module(z). > > -export([f/1]). > > -spec f(queue:queue()) -> queue:queue(). > > f(Q) -> queue:in(3, Q). > > Which is nice, but this doesn't work on R16B03: > > z.erl:5: referring to built-in type queue as a remote type; please > take out the module name > > z.erl:5: referring to built-in type queue as a remote type; please > take out the module name > > So here, I have no way of getting my source code to work with both R16 > and 17.0 easily. There is no transition period so-to-speak. Many > projects run with warnings-as-errors and they are in trouble: > > * They can't compile > > * They can remove the warnings-as-errors but this defeats the purpose > > * They will have warnings spewed out over the console all the time > > In the case of crypto:hash/2, we had somewhat the same situation. > Prominent projects like Yaws, and lesser projects like Emysql has EPP > macros in place as well as detection in order to figure out what to > do. Or you can disable the warnings in this case specifically for > this. But can I do the same with wrong type specs? Also, this > workaround is done in almost every project out there, which is darn > irritating. > > I don't know what we need to solve this. At one point, I would really > like to have a set of feature flags > > http://www.lispworks.com/documentation/HyperSpec/Body/v_featur.htm , > ZFS, ... > > where you have a way to compile-time scrutinize what your environment > supports. Another way to solve it is the variant Go uses, namely > "build constraints" > > http://golang.org/pkg/go/build/#pkg-overview > > which will mention under which circumstances to include a file as a > part of an application. This would allow for easy handling of > crypto:hash/2, but I do note it will fail on the dialyzer problem. It > looks like the only sane way to solve that is to allow both queue() > and queue:queue() as aliases for a major release and then proceed to > remove queue(). > > Am I completely wrong here? I can accept languages evolve and that > Release 17 has maps which will be used and break a lot of software for > R16 quickly. But I also feel we should have some way of having a > process so there is a way to handle this gracefully going forward. It > is natural for libraries and languages to evolve and break > compatibility. Yet, it should be easy to handle for programmers. There > is much time wasted, which could be used better were there a nice > solution. > > Thoughts? > > -- > J. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ludovic@REDACTED Fri Feb 28 17:55:59 2014 From: ludovic@REDACTED (lud) Date: Fri, 28 Feb 2014 17:55:59 +0100 Subject: [erlang-questions] ETS ordering Message-ID: Hi, I need some help setting up ETS tables for an application : I would like to store users' sell-orders and buy-orders in an ETS Table. I would like them to be ordered. (tl;dr please see last paragraph.) Tuples must contain the following values : - Whose order it is - 'buy' or 'sell' - The quantity - The product id - The price So, as an example : {jack,buy,6,apple,36.00} {william,buy,20,apple,23.00} {joe,buy,8,apple,35.00} {averell,buy,1,apple,100.00} (prices are per unit) If some user wants to sell 20 apples a minimum price of 20.00, the three orders match, but I would like to iterate from highest price to lower. I want the user to get the maximum profit, so the records must come in this ordering : {jack,buy,6,apple,36.00} {joe,buy,8,apple,35.00} {william,buy,20,apple,23.00} I will sell 20 apples : 6 to jack, 8 to joe and 6 to william. When I want to buy, I would like the sell orders to come in the opposite ordering : cheapest first ! So i've thought of having two tables, buy-orders on one side, sell-orders on the other. I could use ordered_set table type and ets:select/3 to fold over the matchspec results in order. For buy orders, I can store negative prices so higher prices come first. My main question is on the key : do you think it's okay/good to have tuples with compound keys such as the following in buy_orders table ? {{ItemTypeID,Price,OrderID},Quantity,BuyerID} {{apple, -36.00, 1}, 6, jack} {{apple, -35.00, 2}, 8, joe} {{apple, -23.00, 3}, 20, william} I must have OrderID (which is a dummy value) because there is no ordered_bag table type and users may sell/buy same items at the same price, and one user could sell/buy the same item at two different prices (e.g. testing the market). Thank you From jesper.louis.andersen@REDACTED Fri Feb 28 18:03:22 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 28 Feb 2014 18:03:22 +0100 Subject: [erlang-questions] ETS ordering In-Reply-To: References: Message-ID: On Fri, Feb 28, 2014 at 5:55 PM, lud wrote: > {{ItemTypeID,Price,OrderID},Quantity,BuyerID} > This is a common trick which can often be used to satisfy these kinds of things. I use it quite often. However, given your situation, you may want to take the plunge and move the whole thing to mnesia. It gives you a lot of added power which you can avoid reimplementing yourself. Even if you don't need that extra power now, you need to figure out if it is necessary later. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Fri Feb 28 18:07:05 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 28 Feb 2014 18:07:05 +0100 Subject: [erlang-questions] Breaking backwards compatibility in Release 17.0-rc2 In-Reply-To: <530FD668.2090505@ninenines.eu> References: <530FD668.2090505@ninenines.eu> Message-ID: On Fri, Feb 28, 2014 at 1:20 AM, Lo?c Hoguin wrote: > My plans are the following Solving it with git is one option. Another option is to extend erlang.mkand/or rebar to support build-constraints. Many of these upgrade-problems can then be solved by looking up the appropriate version of, e.g., crypto and then compiling the right factoring-module to handle it in your code base. This will work for crypto:hash/2 style upgrades, but it will not do for changes to -callback, queue:queue() or the like. There, only the git option remain and it will be pain to dance around in your projects. I am not proposing anything here. I am trying to get a feeling for how people intend to solve this. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew@REDACTED Fri Feb 28 18:10:24 2014 From: andrew@REDACTED (Andrew Thompson) Date: Fri, 28 Feb 2014 12:10:24 -0500 Subject: [erlang-questions] Breaking backwards compatibility in Release 17.0-rc2 In-Reply-To: References: <530FD668.2090505@ninenines.eu> Message-ID: <20140228171024.GG24036@hijacked.us> What about simply having one major release where both are valid, then one release where it is deprecated and then after that remove it. For projects which support the 'last two major versions', which seems to be the sanest way, that would allow them to migrate. Andrew From ttom.kelly@REDACTED Fri Feb 28 19:54:08 2014 From: ttom.kelly@REDACTED (tom kelly) Date: Fri, 28 Feb 2014 18:54:08 +0000 Subject: [erlang-questions] Missing compile warning Message-ID: Hi List, Here's a stripped down & renamed version of some code I just copied from our system. I may have been staring at this for too long but I've convinced myself that the second function clause in both of these functions can never be executed because they are both covered by the first function clause: -module(no_warn). -compile(export_all). -record(my_rec,{field1, field2}). my_function1(#my_rec{field1 = {tag, _}, field2 = f2}) -> 1; my_function1(#my_rec{field1 = {tag, 1}, field2 = f2}) -> 2; % line 7 my_function1(_) -> 3. my_function2(#my_rec{field1 = {tag, _}}) -> 1; my_function2(#my_rec{field1 = {tag, 1}}) -> 2; % line11 my_function2(_) -> 3. Except, that when I compile this (R16B03-1) the compiler only warns me about one of them: no_warn.erl:11: Warning: this clause cannot match because a previous clause at line 10 always matches Surely line 7 should give an identical warning? Or do I need to go lie down for a little while? //TTom. -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.j.thompson@REDACTED Fri Feb 28 20:20:36 2014 From: s.j.thompson@REDACTED (Simon Thompson) Date: Fri, 28 Feb 2014 19:20:36 +0000 Subject: [erlang-questions] SBLP 2014 - Call for Papers References: <032E6DC4-F39A-494C-A691-ACE9E9692659@kent.ac.uk> Message-ID: <983E88D4-EB58-43E7-81A7-C1C1A8DB2D59@kent.ac.uk> CALL FOR PAPERS 18th Brazilian Symposium on Programming Languages (SBLP 2014) A member of CBSoft joint conference http://www.ic.ufal.br/evento/cbsoft2014/ to be held in Maceio, Brazil. SBLP happens on Thursday, Oct 2nd, and Friday, Oct 3rd. CBSoft dates are September 28, 2014 to October 3, 2014 This CFP is also available at the webpage of the event: http://www.ic.ufal.br/evento/cbsoft2014/en/call-for-papers-sblp.html IMPORTANT DATES Paper abstract submission: May 2nd, 2014 Full paper submission: May 9th, 2014 Notification of acceptance: June 13th, 2014 Final papers due: July 4th, 2014 INTRODUCTION The 18th Brazilian Symposium on Programming Languages, SBLP 2014, will be held in Maceio, a beautiful city in the Northeastern part of Brazil. The conference will happen on October 2nd, and October 3rd, 2014. SBLP provides a venue for researchers and practitioners interested in the fundamental principles and innovations in the design and implementation of programming languages and systems. SBLP 2014 invites authors to contribute with technical papers related (but not limited) to: * Program generation and transformation, including domain-specific languages and model-driven development in the context of programming languages. * Programming paradigms and styles, including functional, object-oriented, aspect-oriented, scripting languages, real-time, service-oriented, multithreaded, parallel, and distributed programming. * Formal semantics and theoretical foundations, including denotational, operational, algebraic and categorical. * Program analysis and verification, including type systems, static analysis and abstract interpretation. * Programming language design and implementation, including new programming models, programming language environments, compilation and interpretation techniques. SUBMISSIONS Contributions should be written in Portuguese or English. Papers should fall into one of two different categories: full papers, with at most 15 pages, or short papers, with at most 5 pages. Accepted papers written in English will be published in a volume of Lecture Notes in Computer Science (LNCS), by Springer. For this reason, all papers must be prepared using the LNCS template, available at http://www.springer.com/computer/lncs?SGWID=0-164-6-793341-0. We encourage the submission of short papers reporting partial results of on-going master dissertations or doctoral theses. Submissions should be done through the SBLP 2014 page at EasyChair, which is available at http://www.easychair.org/conferences/?conf=sblp2014. As in previous editions, a journal's special issue, with selected papers from accepted contributions, is anticipated. Selected papers from the 2003 to the 2008 editions of SBLP were published in special issues of the Journal of Universal Computer Science, by Springer. The post-proceedings of SBLP from 2009 to 2012, also with selected papers from the conference, have been published as special issues of Science of Computer Programming, by Elsevier. KEYNOTE SPEAKERS Louis-Noel Pouchet, University of California Los Angeles Fabrice Rastello, INRIA PROGRAMME CHAIR Fernando Magno Quintao Pereira, UFMG PROGRAMME COMMITTEE Alberto Pardo, Universidad de la Rep?blica Alex Garcia, IME Alvaro Moreira, Federal University of Rio Grande do Sul Andre Rauber Du Bois, Federal University of Pelotas Carlos Camar?o, Federal University of Minas Gerais Christiano Braga, Fluminense Federal University Fabio Mascarenhas, Federal University of Rio de Janeiro Fabrice Rastello, INRIA Fernando Pereira, Federal University of Minas Gerais Fernando Castor, Federal University of Pernambuco Francisco Carvalho-Junior, Federal University of Ceara Hans-Wolfgang Loidl, Heriot-Watt University Jeremy Singer University of Glasgow Jo?o Saraiva, University of Minho Joao F. Ferreira, Teesside University Louis-Noel Pouchet, University of California, Los Angeles Lucilia Figueiredo, Federal University of Ouro Preto Luis Barbosa, University of Minho Manuel A. Martins, University of Aveiro Marcello Bonsangue, Leiden University Marcelo Maia, Federal University of Uberl?ndia Marcelo D'Amorim, Federal University of Pernambuco Mariza Bigonha, Federal University of Minas Gerais Martin Musicante, Federal University of Rio Grande do Norte Noemi Rodriguez, PUC-Rio Peter Mosses, Swansea University Rafael Lins, Federal University of Pernambuco Renato Cerqueira, PUC-Rio Roberto Bigonha, Federal University of Minas Gerais Roberto Ierusalimschy PUC-Rio Rodrigo Geraldo, Federal University of Ouro Preto Sandro Rigo, State University of Campinas S?rgio Medeiros, Federal University of Rio Grande do Norte Simon Thompson, University of Kent Varmo Vene, University of Tartu Zongyan Qiu Peking University 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 Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson@REDACTED | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt From vladdu55@REDACTED Fri Feb 28 21:59:49 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 28 Feb 2014 21:59:49 +0100 Subject: [erlang-questions] Breaking backwards compatibility in Release 17.0-rc2 In-Reply-To: <20140228171024.GG24036@hijacked.us> References: <530FD668.2090505@ninenines.eu> <20140228171024.GG24036@hijacked.us> Message-ID: On Fri, Feb 28, 2014 at 6:10 PM, Andrew Thompson wrote: > What about simply having one major release where both are valid, then > one release where it is deprecated and then after that remove it. For > projects which support the 'last two major versions', which seems to be > the sanest way, that would allow them to migrate. > > Are you referring to unicode source files? This is almost exactly how it is handled: R16 made it possible to have utf8 encoded sources, but latin1 was default; 17.0 makes utf8 the default; 18.0 will probably deprecate latin1 support and I suppose latin1 support will stop in 19.0. Or maybe it will stop in 18.0 already, given that the unicode support will be complete (even atoms). I think the only big problem is when a project uses third party libraries that would need to be recompiled. Sometimes the source for the older versions might even not be available. regards, Vlad > Andrew > _______________________________________________ > 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 Fri Feb 28 22:08:03 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 28 Feb 2014 22:08:03 +0100 Subject: [erlang-questions] Missing compile warning In-Reply-To: References: Message-ID: Hi! On Fri, Feb 28, 2014 at 7:54 PM, tom kelly wrote: > -module(no_warn). > -compile(export_all). > > -record(my_rec,{field1, field2}). > > my_function1(#my_rec{field1 = {tag, _}, field2 = f2}) -> 1; > my_function1(#my_rec{field1 = {tag, 1}, field2 = f2}) -> 2; % line 7 > my_function1(_) -> 3. > > my_function2(#my_rec{field1 = {tag, _}}) -> 1; > my_function2(#my_rec{field1 = {tag, 1}}) -> 2; % line11 > my_function2(_) -> 3. > Looks like a bug to me, especially since changing the first clause to my_function1(#my_rec{field1 = {tag, _}, field2 = _}) -> 1; gives a warning for the first function too. regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Feb 28 22:46:03 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 28 Feb 2014 22:46:03 +0100 Subject: [erlang-questions] Breaking backwards compatibility in Release 17.0-rc2 In-Reply-To: <20140228171024.GG24036@hijacked.us> References: <530FD668.2090505@ninenines.eu> <20140228171024.GG24036@hijacked.us> Message-ID: <5311039B.7000601@ninenines.eu> On 02/28/2014 06:10 PM, Andrew Thompson wrote: > What about simply having one major release where both are valid, then > one release where it is deprecated and then after that remove it. For > projects which support the 'last two major versions', which seems to be > the sanest way, that would allow them to migrate. In theory it is a great solution. In practice it is meaningless, as it is not safe from errors from the OTP team. Unexpected incompatibilities or simply bugs may be (and are) introduced in any release. The OTP team is already trying to avoid breaking things when possible (utf-8), but sometimes this is not possible (-callback), perhaps because it couldn't be planned long enough, and sometimes they unexpectedly introduce bugs (SSL ciphers). There is no good solution, things will always break as long as they're evolving. Taking care of these errors is not much extra work either, because if you are saying you support R15B+, then you better test your project using all these supported releases one by one (throw in maint and master too, it helps seeing issues coming and prevent OTP from breaking your project as you can provide feedback or act upon it long before release). I am using this small script, personally: https://github.com/extend/cowboy/blob/master/all.sh In less than 10 minutes I know what works and what breaks across all supported versions. If I made the mistake of using binary_to_integer/1, then I see it immediately. If something changed in master and breaks my code, then I see it immediately too. (There still are some tests failing due to the utf-8 change, I haven't pushed the "fix" yet, for example.) If I were to have a specific branch for a version of Erlang then I would just have to do a small modification to that script. When I add Windows support then same deal. I will probably end up with a 100-lines script to run tests across all supported platforms and versions, plus a 20-lines script per RB branch to convert the master code to code that works on that specific version of Erlang. It's very manageable, and not only will I know for sure the code works fine on all versions, but I will also be able to deal with issues that may arise in OTP and either provide feedback quickly or fix it in my source in time for release. As this is something that I am now doing across many of my projects, this is definitely something that may land in erlang.mk in the future. -- Lo?c Hoguin http://ninenines.eu From anthonym@REDACTED Fri Feb 28 22:56:12 2014 From: anthonym@REDACTED (ANTHONY MOLINARO) Date: Fri, 28 Feb 2014 13:56:12 -0800 Subject: [erlang-questions] Breaking backwards compatibility in Release 17.0-rc2 In-Reply-To: <53105232.6090807@ninenines.eu> References: <53105232.6090807@ninenines.eu> Message-ID: <73763065-E08D-4FB7-800F-C4743BF23C68@alumni.caltech.edu> Yeah, looking at it, the -ifdef macro really only works with a single token, so you have to provide it externally, which is a bummer because it would have been really nice to do something like -ifdef (?OTP_RELEASE > 15). -callback... -else. -behaviour_info? -endif. Or -ifdef (?OTP_RELEASE < 17). -spec f(queue()) -> queue(). -else. -spec f(queue:queue()) -> queue:queue(). -endif. gcc has the pretty cool __GNUC_PREREQ (MAJOR, MINOR) macro which you can use certain features, but I have a feeling there would be opposition to make preprocessing do more stuff (plus even that macro appears to not help if you are compiling on say clang). -Anthony On Feb 28, 2014, at 1:09 AM, Lo?c Hoguin wrote: > A macro for ?OTP_RELEASE or ?OTP_VERSION makes *absolutely no sense*. There are no guarantees that people are going to compile on a fresh Erlang release. If I create a release named PONIES, this will not help at all when I then use the compiler app I included to compile some stuff at runtime. > > Something a little better is ?COMPILER_VERSION, but people might also run a custom compiler code with a custom version number, so that's a no go either. > > On 02/28/2014 09:36 AM, Vlad Dumitrescu wrote: >> Hi, >> >> I've been hit by this too, as I have a patched debugger that I need to >> compile on older versions too and there are issues with >> unicode/maps/named funs. Unfortunately, there might be cases where code >> will still have to be duplicated, because macros can only wrap full forms. >> >> From a brief look att epp.erl, it feels like adding a ?OTP_RELEASE or >> ?OTP_VERSION predefined macro would be easy and the only possible >> problem is if there are user-defined macros with the same name. >> >> predef_macros(File) -> >> Machine = list_to_atom(erlang:system_info(machine)), >> {ok, Release0} = file:read_file(code:root_dir()++"/OTP_VERSION"), >> Release = string:strip(Release0, right, $\n), >> ... >> {{atom,'OTP_RELEASE'}, {none,[{string,1,Release}]}}, >> ... >> >> By the way, wouldn't it be useful to have an erlang:system_info() that >> reads the file and strips the 'ok' and the whitespace? >> >> best regards, >> Vlad >> >> >> On Fri, Feb 28, 2014 at 1:08 AM, ANTHONY MOLINARO >> > wrote: >> >> I also have felt this pain with the transition from behaviour_info >> to callbacks for behaviours. Ideally, the preprocessor would define >> a macro along the lines of ?MODULE, ?MODULE_STRING, ?FILE, ?LINE, >> and ?MACHINE which is the full list according to >> http://www.erlang.org/doc/reference_manual/macros.html. >> >> If there was one additional macro call ?RELEASE with the major >> release, then it would be possible to conditionally compile at least >> dialyzer stuff (I don't know about the file encoding, I guess it >> would depend on whether the check is done during the preprocessor or >> at a later step). This would probably prevent the proliferation of >> different compile macros which seem to crop up as every individual >> library adds their own based on a rebar or makefile check. >> >> -Anthony >> >> On Feb 27, 2014, at 3:06 PM, Jesper Louis Andersen >> > > wrote: >> >>> Release 17.0 brings two changes which prove to take some work >>> getting around. >>> >>> 1. utf-8 is now the default encoding. >>> >>> This is a rather insignificant change. The source code which uses >>> latin1 can be fixed by one of three ways: >>> >>> * Tell the compiler the file is latin1. This won't work going >>> forward but works now. >>> * Change the file to utf-8. This won't work going backward a long >>> way. But it will work going backwards for a bit. >>> * Change the file to ASCII. This works both backward and forward >>> as long as we want. >>> >>> This is a benign problem. I have tried compiling some projects and >>> it turns out there are numerous repositories which needs fixing >>> now. But the fix is rather simple. >>> >>> 2. Dialyzer dislikes queue(), dict(), ... >>> >>> Dialyzer now prefers using queue:queue() and the like. This is >>> *definitely* the right thing to support as it is much more >>> consistent with the rest of the system and doesn't treat certain >>> types as magically introduced types. >>> >>> -module(z). >>> >>> -export([f/1]). >>> >>> -spec f(queue:queue()) -> queue:queue(). >>> f(Q) -> queue:in(3, Q). >>> >>> Which is nice, but this doesn't work on R16B03: >>> >>> z.erl:5: referring to built-in type queue as a remote type; please >>> take out the module name >>> z.erl:5: referring to built-in type queue as a remote type; please >>> take out the module name >>> >>> So here, I have no way of getting my source code to work with both >>> R16 and 17.0 easily. There is no transition period so-to-speak. >>> Many projects run with warnings-as-errors and they are in trouble: >>> >>> * They can't compile >>> * They can remove the warnings-as-errors but this defeats the purpose >>> * They will have warnings spewed out over the console all the time >>> >>> In the case of crypto:hash/2, we had somewhat the same situation. >>> Prominent projects like Yaws, and lesser projects like Emysql has >>> EPP macros in place as well as detection in order to figure out >>> what to do. Or you can disable the warnings in this case >>> specifically for this. But can I do the same with wrong type >>> specs? Also, this workaround is done in almost every project out >>> there, which is darn irritating. >>> >>> I don't know what we need to solve this. At one point, I would >>> really like to have a set of feature flags >>> >>> http://www.lispworks.com/documentation/HyperSpec/Body/v_featur.htm >>> , ZFS, ... >>> >>> where you have a way to compile-time scrutinize what your >>> environment supports. Another way to solve it is the variant Go >>> uses, namely "build constraints" >>> >>> http://golang.org/pkg/go/build/#pkg-overview >>> >>> which will mention under which circumstances to include a file as >>> a part of an application. This would allow for easy handling of >>> crypto:hash/2, but I do note it will fail on the dialyzer problem. >>> It looks like the only sane way to solve that is to allow both >>> queue() and queue:queue() as aliases for a major release and then >>> proceed to remove queue(). >>> >>> Am I completely wrong here? I can accept languages evolve and that >>> Release 17 has maps which will be used and break a lot of software >>> for R16 quickly. But I also feel we should have some way of having >>> a process so there is a way to handle this gracefully going >>> forward. It is natural for libraries and languages to evolve and >>> break compatibility. Yet, it should be easy to handle for >>> programmers. There is much time wasted, which could be used better >>> were there a nice solution. >>> >>> Thoughts? >>> >>> -- >>> J. >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > -- > Lo?c Hoguin > http://ninenines.eu From ludovic@REDACTED Fri Feb 28 23:48:01 2014 From: ludovic@REDACTED (Ludovic Demblans) Date: Fri, 28 Feb 2014 23:48:01 +0100 Subject: [erlang-questions] ETS ordering In-Reply-To: References: Message-ID: Hi, So I feel reassured, thank you. I know (a bit) mnesia but I don't need much functionality and I may want have a table per each sell point, I don't want to deal with different record-name/table-name in mnesia at the moment. I can go to mnesia quickly anyway because I use it already on the same project. But I looked a bit and I've found messages on this list stating that the best thing to do is to fetch all the matching records in a list and then sorting it. In LYSE (mafiapp) Fred fetchs records into a dict and then work on this dict. So, what functionalities of mnesia could help dealing with ordering ? I've found some ordering related stuff in the docs for the qlc module but as you may have noticed, english read/write could be hard somehow. Anyway ETS should be enough to implement a simple prototype. Thanks again ! -- lud Le Fri, 28 Feb 2014 18:03:22 +0100, Jesper Louis Andersen a ?crit: > On Fri, Feb 28, 2014 at 5:55 PM, lud wrote: > >> {{ItemTypeID,Price,OrderID},Quantity,BuyerID} >> > > This is a common trick which can often be used to satisfy these kinds of > things. I use it quite often. > > However, given your situation, you may want to take the plunge and move > the > whole thing to mnesia. It gives you a lot of added power which you can > avoid reimplementing yourself. Even if you don't need that extra power > now, > you need to figure out if it is necessary later. > > > -- Utilisant le logiciel de courrier r?volutionnaire d'Opera : http://www.opera.com/mail/ From ludovic@REDACTED Fri Feb 28 23:49:49 2014 From: ludovic@REDACTED (Ludovic Demblans) Date: Fri, 28 Feb 2014 23:49:49 +0100 Subject: [erlang-questions] Breaking backwards compatibility in Release 17.0-rc2 In-Reply-To: <530FD668.2090505@ninenines.eu> References: <530FD668.2090505@ninenines.eu> Message-ID: Le Fri, 28 Feb 2014 01:20:56 +0100, Lo?c Hoguin a ?crit: > My plans are the following: > > *master* officially supports only RB and RB for building. If > supporting RB is too annoying (for example R14 vs R15 -callback), > then RB support is quickly dropped from master. (Of course, if > master can support even RB, then it is supported.) I can't support R'N'B. I hope every one here is glad to know such a fact. From eriksoe@REDACTED Fri Feb 28 23:57:55 2014 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Fri, 28 Feb 2014 23:57:55 +0100 Subject: [erlang-questions] jinterface and epmd In-Reply-To: References: Message-ID: Hi - I think we at the Erjang project might be interested :-) How complete is it? Regards, Erik S?e S?rensen Den 15/11/2013 11.23 skrev "Minin Maxim" : > Hello, > > i have a little question about jinterface - the communication between an > erlang app and an java app (on two different machines) needs epmd on both > machines. In my environment there are no possibility to install epmd on > the java-machine. That's why I rewrote epmd in java. It can be started > as singlton in jvm and acts as normal epmd. Is anyone interested on that > solution and what is the best way to pull this implementation to otp > standard lib (if there is one)? > > Thanks > Maxim Minin > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: