From essen@REDACTED Tue Jan 1 00:39:26 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Tue, 01 Jan 2013 00:39:26 +0100 Subject: [erlang-questions] Elevator demo Message-ID: <50E2222E.3080906@ninenines.eu> Hello 2013, Just a quick link targeted mostly to people who teach Erlang or those who want to demonstrate its features. Last September Scott gave me the code he had for an old Ericsson elevator training application that shows an application with a bug, and an upgrade available to perform a release upgrade to fix the bug live. As these are elevators, the bug (doors opening at every floor) can be quickly seen fixed since the elevators will continue moving until their destination without the bug triggering anymore once you did the upgrade. You can find the source here: https://github.com/extend/elevators It should work for R15. Probably does for R14 too, but I didn't test it. As this is an old demo it uses gs, but I will port the code to wx for R16 once it is released if nobody did it before. Patches are welcome. Also if you know more about the history behind this application, I'm interested and will put these infos in the README file. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From erlang@REDACTED Tue Jan 1 12:41:32 2013 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 1 Jan 2013 12:41:32 +0100 Subject: [erlang-questions] Elevator demo In-Reply-To: <50E2222E.3080906@ninenines.eu> References: <50E2222E.3080906@ninenines.eu> Message-ID: On Tue, Jan 1, 2013 at 12:39 AM, Lo?c Hoguin wrote: > Hello 2013, > > Just a quick link targeted mostly to people who teach Erlang or those who > want to demonstrate its features. > > Last September Scott gave me the code he had for an old Ericsson elevator > training application that shows an application with a bug, and an upgrade > available to perform a release upgrade to fix the bug live. As these are > elevators, the bug (doors opening at every floor) can be quickly seen fixed > since the elevators will continue moving until their destination without > the bug triggering anymore once you did the upgrade. > > Cool - this would be a nice example to run in a web browser, just a bit of websocket magic javascript and svg. I think (incidentally) that the problem should be posed as a protocol problem. ie it is the students job to create a process that implements a "lift controller" this is sent messages like {floor, 5, pressed, up} {lift, 3, pressed, 5} ... (meaning the up button was press on floor 5, the 5 button was pressed inside lift 3) and should respond by sending messages like {lift,3,go,up} ... etc. This would make a very nice teaching/learning example - ... I shall do this if I get time. /Joe > You can find the source here: > > https://github.com/extend/**elevators > > It should work for R15. Probably does for R14 too, but I didn't test it. > > As this is an old demo it uses gs, but I will port the code to wx for R16 > once it is released if nobody did it before. > > Patches are welcome. Also if you know more about the history behind this > application, I'm interested and will put these infos in the README file. > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > 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 n.oxyde@REDACTED Tue Jan 1 13:43:19 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 1 Jan 2013 13:43:19 +0100 Subject: [erlang-questions] Frames proposal In-Reply-To: References: <3A1E3ECD-6E4B-42AB-94AA-13BC32CE090E@gmail.com> <1356799940.34463.YahooMailNeo@web120704.mail.ne1.yahoo.com> Message-ID: <7282F10E-DCBC-45EE-9562-11603BDFC1F4@gmail.com> You should read Richard O'Keefe's post "EEP20: Split the atoms!" on his blog: http://www.erlang.org/eeps/eep-0020.html -- Anthony Ramine Le 29 d?c. 2012 ? 18:30, Max Lapshin a ?crit : > What is the idea to make atoms collectable? > > They are designed as a limited number of domain specific words. You cannot deal with endless amount of domain language, it is always finite. So atoms are also finite. From chandrashekhar.mullaparthi@REDACTED Tue Jan 1 18:47:54 2013 From: chandrashekhar.mullaparthi@REDACTED (Chandru) Date: Tue, 1 Jan 2013 17:47:54 +0000 Subject: [erlang-questions] Meet up in Cambridge, UK Message-ID: Hi all, Is there any interest for a meet up to discuss all things Erlang in Cambridge, UK? I'm happy to organise it if there is enough interest. cheers Chandru From rustompmody@REDACTED Tue Jan 1 19:10:30 2013 From: rustompmody@REDACTED (Rustom Mody) Date: Tue, 1 Jan 2013 23:40:30 +0530 Subject: [erlang-questions] erlang inside emacs issues Message-ID: If I start erlang in a shell and give control-C I get a break menu, one option being (c)ontinue. Give the c and erlang continues properly. Inside emacs however 2 Ctrl-Cs seem to behave like one presenting me a break menu. Give a 'c' there an emacs hangs until one goes to a shell, find the erlang process and kill it. What am I doing wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From olopierpa@REDACTED Tue Jan 1 22:23:17 2013 From: olopierpa@REDACTED (Pierpaolo Bernardi) Date: Tue, 1 Jan 2013 22:23:17 +0100 Subject: [erlang-questions] erlang inside emacs issues In-Reply-To: References: Message-ID: Ctrl-c is bound to the emacs command which means "pass the next keystroke to the inferior process". That's the reason why you use ctrl-c to send uninterpreted to erlang. 2013/1/1, Rustom Mody : > If I start erlang in a shell and give control-C I get a break menu, one > option being (c)ontinue. Give the c and erlang continues properly. > > Inside emacs however 2 Ctrl-Cs seem to behave like one presenting me a > break menu. > > Give a 'c' there an emacs hangs until one goes to a shell, find the erlang > process and kill it. > > What am I doing wrong? > -- Inviato dal mio dispositivo mobile From jvalduvieco@REDACTED Wed Jan 2 00:43:09 2013 From: jvalduvieco@REDACTED (Joan Valduvieco Llopart) Date: Wed, 2 Jan 2013 00:43:09 +0100 Subject: [erlang-questions] process manager, R16, and 64-bit Macs In-Reply-To: References: <50BE791E.1050202@simonstl.com> <50BF1EA5.3040201@erlang.org> <50BF30A6.3030608@erlang.org> <50BF33FC.5080608@ninenines.eu> <50CB93B8.1070203@ninenines.eu> Message-ID: Ok, Fixed. Probably your filesystem is case sensitive, mine is not. ;) Joan 2012/12/30 Michel Rijnders > Hi, > > I had to change line 66 of the first file from: > > ENV.append 'LDFLAGS', '-framework Appkit' if build.include? 'with-wxgtk' > > to (note the uppercase K in "AppKit"): > > ENV.append 'LDFLAGS', '-framework AppKit' if build.include? 'with-wxgtk' > > To get it to work for me (OS X 10.8.2, XCode 4.5.2). > > Cheers, > Michel > > On Wed, Dec 26, 2012 at 1:19 AM, Joan Valduvieco Llopart < > jvalduvieco@REDACTED> wrote: > >> Hi all, >> I managed to add wxgtk Formula to Homebrew and to make some modifications >> to erlang Formula allowing Erlang GUI tools to work on Mountain Lion. >> You can find my changes here: >> >> https://github.com/jvalduvieco/homebrew/compare/master...erlang-wxgtk >> >> gists with complete files: >> >> https://gist.github.com/4376548 >> https://gist.github.com/4376555 >> >> If you want to use these formula just replace original Homebrew formula >> (in /usr/local/Library/Formula/) with mine and run: >> >> brew uninstall erlang >> brew install -vd --with-wxgtk erlang >> >> I'll submit a pull request to mxcl as soon as I get some positive >> feedback. Now it just works for me. >> >> Thanks, >> Joan >> >> >> 2012/12/18 Joan Valduvieco Llopart >> >>> Sure! >>> I'll try. Installing brew right now.. ;) >>> >>> Joan >>> >>> >>> 2012/12/14 Lo?c Hoguin >>> >>>> On 12/05/2012 01:17 PM, Joan Valduvieco Llopart wrote: >>>> >>>>> I am using observer with mountain lion with wxgtk + xquartz without a >>>>> glitch. :) >>>>> I have a macports repo with my packages. >>>>> https://github.com/**jvalduvieco/macports >>>>> >>>> >>>> Any chance you could port this to homebrew? From what I hear most >>>> people who use Macs use homebrew so you doing this would be a tremendous >>>> help for the community and for the OTP team. >>>> >>>> -- >>>> Lo?c Hoguin >>>> >>>> Erlang Cowboy >>>> Nine Nines >>>> http://ninenines.eu >>>> >>> >>> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > -- > My other car is a cdr. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From evrenweb@REDACTED Wed Jan 2 12:26:17 2013 From: evrenweb@REDACTED (Evren Bayraktar) Date: Wed, 2 Jan 2013 13:26:17 +0200 Subject: [erlang-questions] Special Characters problem Message-ID: Hi everyone, I'm working on ejabberd. < , > characters are recieved on real time conversation but they escape when I trying to write message on mysql database. lists:flatten(io_lib:format("from=~s&to=~s&message=~s&status=~b&time_create=~b", [FromS, ToS, BodyS, Status, unix_timestamp() I'm using this lists functions. When I write 5 > 4 on chat client, it sended but after then I tried to get this messages from archive database, it looks only 5. "> 4 " are missing.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Wed Jan 2 12:35:21 2013 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 2 Jan 2013 12:35:21 +0100 Subject: [erlang-questions] Special Characters problem In-Reply-To: References: Message-ID: Hi! On Wed, Jan 2, 2013 at 12:26 PM, Evren Bayraktar wrote: > lists:flatten(io_lib:format("from=~s&to=~s&message=~s&status=~b&time_create=~b", > [FromS, ToS, BodyS, Status, unix_timestamp() > I would guess that the message's body (and maybe even the other strings) should be escaped or quoted (by using ~w instead of ~s), probably the parser for the resulting string can't handle the spaces and the '>'. You should in any case sanitize the input, otherwise you will have problems with code injection, imagine a message saying "Hello&status=closed&time_create=..." (or worse). best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.bolinder@REDACTED Wed Jan 2 14:48:31 2013 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Wed, 2 Jan 2013 13:48:31 +0000 Subject: [erlang-questions] parsetools 2.0.7 esyntax - Call to missing or unexported function erl_parse:*/* Message-ID: <56466BD70414EA48969B4064696CF28C026311@ESESSMB207.ericsson.se> ________________________________________ Hi, > I stumbled upon some missing functions inside the syntax.yrl file of the parsetools > application. > > esyntax.yrl:164: Call to missing or unexported function erl_parse:erlang_bif/2 > esyntax.yrl:202: Call to missing or unexported function erl_parse:is_term/1 > esyntax.yrl:271: Call to missing or unexported function erl_parse:erlang_guard_bif/2 > esyntax.yrl:283: Call to missing or unexported function erl_parse:erlang_guard_test/2 > > What is the purpose of this file? Should these errors be fixed? ignored? etc? I think the file can be removed. I'll do that in R16B. > I fixed a few dialyzer warnings for leex and yecc. I agree that the return value of file:close/1 should be tested. Of some reason it has been practice not to do it, probably because it "always" returns 'ok'. There are hundreds of calls to file:close/1 in Erlang/OTP, and just a few of them test the return value. Maybe it'd be easier to fix them all at once. I'll put it on the to-do list. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From kostis@REDACTED Wed Jan 2 15:41:11 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 02 Jan 2013 16:41:11 +0200 Subject: [erlang-questions] parsetools 2.0.7 esyntax - Call to missing or unexported function erl_parse:*/* In-Reply-To: <56466BD70414EA48969B4064696CF28C026311@ESESSMB207.ericsson.se> References: <56466BD70414EA48969B4064696CF28C026311@ESESSMB207.ericsson.se> Message-ID: <50E44707.601@cs.ntua.gr> On 01/02/2013 03:48 PM, Hans Bolinder wrote: > >> I fixed a few dialyzer warnings for leex and yecc. > > I agree that the return value of file:close/1 should be tested. Of > some reason it has been practice not to do it, probably because it > "always" returns 'ok'. There are hundreds of calls to file:close/1 in > Erlang/OTP, and just a few of them test the return value. Maybe it'd be > easier to fix them all at once. I'll put it on the to-do list. I would strongly suggest that you start running dialyzer with the option -Wunmatched_returns on, at least on selected OTP applications like erts, kernel and stdlib. Among other things, it reports all cases where "complex" return values like tuples and lists are ignored in function calls and it catches all cases like the ones of the file module. A couple of weeks ago, I've submitted some patches that correct some of the warnings for stdlib and kernel. These are currently cooking in pu. Your job will be easier once these are integrated. Kostis From antoine.koener@REDACTED Wed Jan 2 15:55:34 2013 From: antoine.koener@REDACTED (Antoine Koener) Date: Wed, 2 Jan 2013 15:55:34 +0100 Subject: [erlang-questions] Special Characters problem In-Reply-To: References: Message-ID: Is 'single character >' allowed in xmpp since it is xml ? Should have been > On Wednesday, January 2, 2013, Vlad Dumitrescu wrote: > Hi! > > On Wed, Jan 2, 2013 at 12:26 PM, Evren Bayraktar > > wrote: > >> lists:flatten(io_lib:format("from=~s&to=~s&message=~s&status=~b&time_create=~b", >> [FromS, ToS, BodyS, Status, unix_timestamp() >> > > I would guess that the message's body (and maybe even the other strings) > should be escaped or quoted (by using ~w instead of ~s), probably the > parser for the resulting string can't handle the spaces and the '>'. > > You should in any case sanitize the input, otherwise you will have > problems with code injection, imagine a message saying > "Hello&status=closed&time_create=..." (or worse). > > best regards, > Vlad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rustompmody@REDACTED Wed Jan 2 16:05:07 2013 From: rustompmody@REDACTED (Rustom Mody) Date: Wed, 2 Jan 2013 20:35:07 +0530 Subject: [erlang-questions] erlang inside emacs issues In-Reply-To: References: Message-ID: On Wed, Jan 2, 2013 at 2:53 AM, Pierpaolo Bernardi wrote: > Ctrl-c is bound to the emacs command which means "pass the next > keystroke to the inferior process". That's the reason why you use > ctrl-c to send uninterpreted to erlang. > > Well the two keystrokes is hardly the problem ! That erlang hangs emacs is what I am asking about :D On a related note surely C-c C-g should have been setup to send C-g to erlang shell? For now I have hacked up this elisp for this However I find it hard to believe that I am the first one to want this --------------------------------------- (defun inf-ctl-g () (interactive) (comint-send-string (current-buffer) (make-string 1 ?\C-g))) (add-hook 'erlang-shell-mode-hook (lambda () (define-key erlang-shell-mode-map (kbd "C-c C-g") 'inf-ctl-g))) -------------- next part -------------- An HTML attachment was scrubbed... URL: From johanclaesson@REDACTED Wed Jan 2 16:32:06 2013 From: johanclaesson@REDACTED (Johan Claesson) Date: Wed, 02 Jan 2013 16:32:06 +0100 Subject: [erlang-questions] erlang inside emacs issues In-Reply-To: (Rustom Mody's message of "Wed, 2 Jan 2013 20:35:07 +0530") References: Message-ID: <87d2xny51l.fsf@bredband.net> I think the problem is that emacs is waiting for the erlang process to print something. Normally erlang will always print a promt when you hit return but not while in the BREAK menu. As a workaround you should be able to stop emacs from waiting with C-g. But a nicer alternative is to make emacs not wait for erlang output in the first place. Insert this in your .emacs: (add-hook 'erlang-shell-mode-hook (lambda () (add-hook 'comint-output-filter-functions 'jcl-stop-echo t t))) (defun jcl-stop-echo (ignored) (remove-hook 'comint-output-filter-functions 'jcl-stop-echo t) (setq comint-process-echoes nil) (insert "io:setopts([{echo, false}]).") (comint-send-input nil t)) I agree about the C-g stuff and i have almost exactly the same hack :). Regards, /Johan Rustom Mody writes: > On Wed, Jan 2, 2013 at 2:53 AM, Pierpaolo Bernardi wrote: > >> Ctrl-c is bound to the emacs command which means "pass the next >> keystroke to the inferior process". That's the reason why you use >> ctrl-c to send uninterpreted to erlang. >> >> Well the two keystrokes is hardly the problem ! > That erlang hangs emacs is what I am asking about :D > > On a related note surely C-c C-g should have been setup to send C-g to > erlang shell? > > For now I have hacked up this elisp for this > However I find it hard to believe that I am the first one to want this > > --------------------------------------- > (defun inf-ctl-g () > (interactive) > (comint-send-string (current-buffer) (make-string 1 ?\C-g))) > > (add-hook 'erlang-shell-mode-hook > (lambda () > (define-key erlang-shell-mode-map (kbd "C-c C-g") 'inf-ctl-g))) > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From stfairy@REDACTED Wed Jan 2 17:09:43 2013 From: stfairy@REDACTED (Xiao Jia) Date: Thu, 3 Jan 2013 00:09:43 +0800 Subject: [erlang-questions] Unicorn-style load balancing in Erlang? Message-ID: >From http://www.erlang.org/doc/man/gen_tcp.html#accept-1: > It is worth noting that the accept call does not have to be issued > from the socket owner process. Using version 5.5.3 and higher of > the emulator, multiple simultaneous accept calls can be issued > from different processes, which allows for a pool of acceptor > processes handling incoming connections. Does it mean that we can have Unicorn-style load balancing in Erlang? If so, are there any existing servers or libraries making use of this feature? For those who are not familiar with Unicorn [1], it is a traditional UNIX prefork web server. Load balancing between worker processes is done by the OS kernel. All workers share a common set of listener sockets and does non-blocking accept() on them. The kernel will decide which worker process to give a socket to and workers will sleep if there is nothing to accept(). btw, I also posted this question on StackOverflow [2] but no active responses there :-( [1]: http://unicorn.bogomips.org/ [2]: http://stackoverflow.com/questions/14121987/unicorn-style-load-balancing-in-erlang --- Regards, Xiao Jia From francesco@REDACTED Wed Jan 2 18:14:15 2013 From: francesco@REDACTED (Francesco Cesarini) Date: Wed, 02 Jan 2013 17:14:15 +0000 Subject: [erlang-questions] Elevator demo In-Reply-To: <50E2222E.3080906@ninenines.eu> References: <50E2222E.3080906@ninenines.eu> Message-ID: <50E46AE7.1000204@erlang-solutions.com> The Elevator example was implemented by Hakan Huss in the late 90s at Erlang Systems. It was part of the 5-day Erlang Literacy course aimed at test and support staff of the GPRS project. It has been used to demonstrate how Quick Check can test elevator systems, and featured in a few academic papers. /F On 31/12/2012 23:39, Lo?c Hoguin wrote: > Hello 2013, > > Just a quick link targeted mostly to people who teach Erlang or those > who want to demonstrate its features. > > Last September Scott gave me the code he had for an old Ericsson > elevator training application that shows an application with a bug, > and an upgrade available to perform a release upgrade to fix the bug > live. As these are elevators, the bug (doors opening at every floor) > can be quickly seen fixed since the elevators will continue moving > until their destination without the bug triggering anymore once you > did the upgrade. > > You can find the source here: > > https://github.com/extend/elevators > > It should work for R15. Probably does for R14 too, but I didn't test it. > > As this is an old demo it uses gs, but I will port the code to wx for > R16 once it is released if nobody did it before. > > Patches are welcome. Also if you know more about the history behind > this application, I'm interested and will put these infos in the > README file. > -- Erlang Solutions Ltd. http://www.erlang-solutions.com From anthonym@REDACTED Wed Jan 2 18:28:16 2013 From: anthonym@REDACTED (Anthony Molinaro) Date: Wed, 2 Jan 2013 09:28:16 -0800 Subject: [erlang-questions] Any tcp related changes in R15B* that might cause this? In-Reply-To: <50CF35FF.6020101@erix.ericsson.se> References: <20121206193809.GC27411@alumni.caltech.edu> <15C0D662-A77C-4858-AD93-3306E72317F6@erlang-solutions.com> <20121212182632.GB72594@alumni.caltech.edu> <20121212234803.GA75710@alumni.caltech.edu> <20121213002455.GA75861@alumni.caltech.edu> <20121213183830.GA81730@alumni.caltech.edu> <20121214211117.GA86501@alumni.caltech.edu> <50CF35FF.6020101@erix.ericsson.se> Message-ID: <20130102172816.GA24637@alumni.caltech.edu> Hi, The holidays went and interrupted everything, so I'm sorry about the late response. It's unclear if the commit dc5f7190 did it or not, but sometime between R14B04 and R15B02 the behavior did change. I've not isolated it outside of mochiweb, but I don't think its a mochiweb problem. Here's the pull request which contains the short program I used to reproduce with mochiweb (and work around the new behavior) https://github.com/mochi/mochiweb/pull/91 I'll see if I can't isolate it to just OTP sometime in the next couple of days. -Anthony On Mon, Dec 17, 2012 at 04:10:55PM +0100, Sverker Eriksson wrote: > Have I understood it correctly so far if I say that my commit > dc5f7190 seems to cause a > > {tcp_error,Port,emsgsize} > > while earlier versions caused a > > {http,Port,{http_error,"..."}} > > > for the same scenario with some sort of very long http lines? > > /Sverker, Erlang/OTP > > Anthony Molinaro wrote: > >On Fri, Dec 14, 2012 at 11:32:11AM -0500, Steve Vinoski wrote: > >>Hi Anthony, based on your example, it looks like a follow-up commit that > >>modified some of the changes introduced by my patch introduced the issue > >>you're seeing: commit dc5f7190. You might want to report it over on > >>erlang-bugs. > > > >Nice catch, I guess that it's actually not enough to return error > >for backward compatibility ;) > > > >I think the main thing I'm still not sure of is if the decode_packet changes > >are actually the cause. I was able to call decode_packet with long headers > >and not actually see an issue. > > > >This > > > >erlang:decode_packet ( httph, > > list_to_binary ([ "X-Random: ", > > [$a || _ <- lists:seq(1,10000)], > > "\r\n\r\n" > > ]), > > []). > > > >Returns the same thing in both R14B04 and R15B02. And as far as I am able > >to tell that is the only call made to decode_packet in mochiweb. > > > >I think the actual error is around recvbuf sizing (mochiweb uses 8192 as > >the default, so 10000 is definitely larger than that, however, the standard > >libraries must be doing something different as now it returns emsgsize > >where it did no in the past). I really wish there was a way to search > >commits on github as then I could search for recvbuf or something like > >that to see what might have changed. > > > >Before I go over to bugs I'll probably try to detangle mochiweb enough > >to create a small reproducible test case. > > > >I also have a pull request into mochiweb which prevents the crash but > >has the annoying behavior at the moment that it returns an error to the > >client about disconnecting version the 400 error it returned before. > > > >https://github.com/mochi/mochiweb/pull/91 > > > >But since the standard library seems to be the one closing the socket > >there's not much that can be done other than the fix I put in place. > > > >Thanks for your help Steve, > > > >-Anthony > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- ------------------------------------------------------------------------ Anthony Molinaro From vinoski@REDACTED Wed Jan 2 18:34:56 2013 From: vinoski@REDACTED (Steve Vinoski) Date: Wed, 2 Jan 2013 12:34:56 -0500 Subject: [erlang-questions] Any tcp related changes in R15B* that might cause this? In-Reply-To: <20130102172816.GA24637@alumni.caltech.edu> References: <20121206193809.GC27411@alumni.caltech.edu> <15C0D662-A77C-4858-AD93-3306E72317F6@erlang-solutions.com> <20121212182632.GB72594@alumni.caltech.edu> <20121212234803.GA75710@alumni.caltech.edu> <20121213002455.GA75861@alumni.caltech.edu> <20121213183830.GA81730@alumni.caltech.edu> <20121214211117.GA86501@alumni.caltech.edu> <50CF35FF.6020101@erix.ericsson.se> <20130102172816.GA24637@alumni.caltech.edu> Message-ID: Hi Anthony and Sverker, as I mentioned in a previous email, using Anthony's test case a few weeks ago I bisected between R14B04 and HEAD and found commit dc5f7190 to be the first commit where the test case fails. --steve On Wed, Jan 2, 2013 at 12:28 PM, Anthony Molinaro < anthonym@REDACTED> wrote: > Hi, > > The holidays went and interrupted everything, so I'm sorry about the > late response. > It's unclear if the commit dc5f7190 did it or not, but sometime between > R14B04 and R15B02 the behavior did change. I've not isolated it outside > of mochiweb, but I don't think its a mochiweb problem. > > Here's the pull request which contains the short program I used to > reproduce with mochiweb (and work around the new behavior) > > https://github.com/mochi/mochiweb/pull/91 > > I'll see if I can't isolate it to just OTP sometime in the next > couple of days. > > -Anthony > > On Mon, Dec 17, 2012 at 04:10:55PM +0100, Sverker Eriksson wrote: > > Have I understood it correctly so far if I say that my commit > > dc5f7190 seems to cause a > > > > {tcp_error,Port,emsgsize} > > > > while earlier versions caused a > > > > {http,Port,{http_error,"..."}} > > > > > > for the same scenario with some sort of very long http lines? > > > > /Sverker, Erlang/OTP > > > > Anthony Molinaro wrote: > > >On Fri, Dec 14, 2012 at 11:32:11AM -0500, Steve Vinoski wrote: > > >>Hi Anthony, based on your example, it looks like a follow-up commit > that > > >>modified some of the changes introduced by my patch introduced the > issue > > >>you're seeing: commit dc5f7190. You might want to report it over on > > >>erlang-bugs. > > > > > >Nice catch, I guess that it's actually not enough to return error > > >for backward compatibility ;) > > > > > >I think the main thing I'm still not sure of is if the decode_packet > changes > > >are actually the cause. I was able to call decode_packet with long > headers > > >and not actually see an issue. > > > > > >This > > > > > >erlang:decode_packet ( httph, > > > list_to_binary ([ "X-Random: ", > > > [$a || _ <- > lists:seq(1,10000)], > > > "\r\n\r\n" > > > ]), > > > []). > > > > > >Returns the same thing in both R14B04 and R15B02. And as far as I am > able > > >to tell that is the only call made to decode_packet in mochiweb. > > > > > >I think the actual error is around recvbuf sizing (mochiweb uses 8192 as > > >the default, so 10000 is definitely larger than that, however, the > standard > > >libraries must be doing something different as now it returns emsgsize > > >where it did no in the past). I really wish there was a way to search > > >commits on github as then I could search for recvbuf or something like > > >that to see what might have changed. > > > > > >Before I go over to bugs I'll probably try to detangle mochiweb enough > > >to create a small reproducible test case. > > > > > >I also have a pull request into mochiweb which prevents the crash but > > >has the annoying behavior at the moment that it returns an error to the > > >client about disconnecting version the 400 error it returned before. > > > > > >https://github.com/mochi/mochiweb/pull/91 > > > > > >But since the standard library seems to be the one closing the socket > > >there's not much that can be done other than the fix I put in place. > > > > > >Thanks for your help Steve, > > > > > >-Anthony > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > -- > ------------------------------------------------------------------------ > Anthony Molinaro > _______________________________________________ > 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 Wed Jan 2 20:21:33 2013 From: rickard@REDACTED (Rickard Green) Date: Wed, 2 Jan 2013 20:21:33 +0100 Subject: [erlang-questions] Why system_flag(scheduler_bind_type) is deprecated? In-Reply-To: References: <6072f3ef-54a4-4e83-bebe-62186d18cbc2@17g2000vba.googlegroups.com> <373FD3CE-B816-45AF-A97C-F1F0E3C56586@erlang.org> Message-ID: <50E488BD.2080703@erlang.org> On 12/31/2012 12:04 PM, Max Lapshin wrote: > Damn, this removal is really a problem. > > I can't use erlang:system_flag/2 call anymore, I can't use +sbt option, > because it is impossible to understand if this flag is supported with > current erlang build, I can't work without this flag, because by default > scheduler is trying to group processes on one core and udp packets are lost. > > Is it possible to ignore +sbt flag, not to fail the runtime? Currently no, but I can add another switch that will try setting bind type and fail silently if not supported. I'll do this at the same time as removing the erlang:system_flags(scheduler_bind_type, _) support. Regards, Rickard -- Rickard Green, Erlang/OTP, Ericsson AB. From daniel@REDACTED Wed Jan 2 21:13:30 2013 From: daniel@REDACTED (Daniel Luna) Date: Wed, 2 Jan 2013 15:13:30 -0500 Subject: [erlang-questions] Erlang - supervised gen_server to drain off a queue In-Reply-To: <20121229073535.GA18325@sagitarius.getae.net> References: <20121229073535.GA18325@sagitarius.getae.net> Message-ID: The task you are describing is very much a gen_server type of thing. Just subscribe to the rabbit queue and you are good to go. Copy/pasting from our code, we do something similar to the following #'basic.qos_ok'{} = amqp_channel:call(Channel, #'basic.qos'{prefetch_count = Prefetch}), #'basic.consume_ok'{consumer_tag = Tag} = amqp_channel:subscribe(Channel, #'basic.consume'{queue = Q}, self()), receive #'basic.consume_ok'{consumer_tag = Tag} -> ok end, When you want to unsubscribe you can either just kill the reader or unsubscribe using the consumer_tag. Every message can then be handled in handle_info receiving {#'basic.deliver'{delivery_tag = Tag}, #amqp_msg{payload = PayloadBin}}. After you've done the logging you ack the message: amqp_channel:cast(Channel, #'basic.ack'{delivery_tag = Tag}). That should be enough to get you going. /Daniel On 29 December 2012 02:35, hyperboreean wrote: > Hi guys, > > I'm just trying to bring Erlang into my company - it's a hard road, but > we might eventually use it for at least some of our projects. I want to > get started by changing a small piece of code that reads an AMQP queue > and appends the contents of each message to a file. To be more specific, > there are multiple producers for that queue (which produce error > messages, if any) and there's this consumer which gets the error > messages from the queue and updates a file with them. Now, this piece of > software has always been problematic for us, for one reason or another - > it's not reliable and when it fails it might bring the AMQP broker to > its knees because of the number of messages that are not consumed. > > I'd like to change this code with some Erlang code - maybe with a > supervision tree so that if/when the server fails, it gets automatically > restarted. I was thinking of trying a gen_server, but then I figured out > that there's no client of the server, the code just has to constantly > pull data out of that queue. > > Any good hints on how to get started on this ? What's the OTP way of > doing this kind of things? > > Thank you! > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From daniel.goertzen@REDACTED Wed Jan 2 22:25:22 2013 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Wed, 2 Jan 2013 15:25:22 -0600 Subject: [erlang-questions] Unicorn-style load balancing in Erlang? In-Reply-To: References: Message-ID: For bare acceptor pool libraries, take a look at... https://github.com/extend/ranch https://github.com/jeremey/swarm And I would bet that most significant socket server apps written in Erlang would use acceptor pooling of some sort. Dan. On Wed, Jan 2, 2013 at 10:09 AM, Xiao Jia wrote: > From http://www.erlang.org/doc/man/gen_tcp.html#accept-1: > > > It is worth noting that the accept call does not have to be issued > > from the socket owner process. Using version 5.5.3 and higher of > > the emulator, multiple simultaneous accept calls can be issued > > from different processes, which allows for a pool of acceptor > > processes handling incoming connections. > > Does it mean that we can have Unicorn-style load balancing in Erlang? > If so, are there any existing servers or libraries making use of this > feature? > > For those who are not familiar with Unicorn [1], it is a traditional > UNIX prefork web server. Load balancing between worker processes is > done by the OS kernel. All workers share a common set of listener > sockets and does non-blocking accept() on them. The kernel will decide > which worker process to give a socket to and workers will sleep if > there is nothing to accept(). > > btw, I also posted this question on StackOverflow [2] but no active > responses there :-( > > [1]: http://unicorn.bogomips.org/ > [2]: > http://stackoverflow.com/questions/14121987/unicorn-style-load-balancing-in-erlang > > --- > Regards, > Xiao Jia > _______________________________________________ > 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 Wed Jan 2 23:01:06 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 3 Jan 2013 01:01:06 +0300 Subject: [erlang-questions] Why system_flag(scheduler_bind_type) is deprecated? In-Reply-To: <50E488BD.2080703@erlang.org> References: <6072f3ef-54a4-4e83-bebe-62186d18cbc2@17g2000vba.googlegroups.com> <373FD3CE-B816-45AF-A97C-F1F0E3C56586@erlang.org> <50E488BD.2080703@erlang.org> Message-ID: Rickard, it would be great. On Wednesday, January 2, 2013, Rickard Green wrote: > On 12/31/2012 12:04 PM, Max Lapshin wrote: > >> Damn, this removal is really a problem. >> >> I can't use erlang:system_flag/2 call anymore, I can't use +sbt option, >> because it is impossible to understand if this flag is supported with >> current erlang build, I can't work without this flag, because by default >> scheduler is trying to group processes on one core and udp packets are >> lost. >> >> Is it possible to ignore +sbt flag, not to fail the runtime? >> > > Currently no, but I can add another switch that will try setting bind type > and fail silently if not supported. I'll do this at the same time as > removing the erlang:system_flags(scheduler_**bind_type, _) support. > > Regards, > Rickard > -- > Rickard Green, Erlang/OTP, Ericsson AB. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmakarlsson@REDACTED Thu Jan 3 00:25:22 2013 From: jmakarlsson@REDACTED (J K) Date: Wed, 2 Jan 2013 15:25:22 -0800 (PST) Subject: [erlang-questions] Strings and Text Processing In-Reply-To: References: <65EC42E5-54A3-4556-A3DA-9E949255C1D1@gmail.com> Message-ID: <1357169122.88636.YahooMailNeo@web162801.mail.bf1.yahoo.com> Hi, I'm not sure I understand your 20.000 files example. Are you suggesting that the user should limit the number of erlang processes to the number of cores or are you suggesting that the VM compresses the erlang process data when not running? That would be really nice if it can be done with only a small performance penalty, say 10-20%. In my case I start 50.000 to 100.000 processes , one per file (it's an (map reduce like) application to do feature extraction for some machine learning algorithms) . One erlang node uses about 7GB of memory. I can probably tune it a bit (a lot?) more by using binaries but it would be nice to have an option to compress process data when not running, for people that are lazy/not an erlang expert/does not have that much time (my case)/or just as an indication of how much memory that could be saved by using binaries. JK ________________________________ From: Joe Armstrong To: Dmitry Kolesnikov Cc: Steve Davis ; Erlang Questions Sent: Saturday, December 29, 2012 4:30 PM Subject: Re: [erlang-questions] Strings and Text Processing On Sat, Dec 29, 2012 at 3:20 PM, Dmitry Kolesnikov wrote: Hello Steve, > >You have raised a good point here. >One more reason for binary is memory consumption and IPC overhead. > The point about memory consumption is raised *many* times - on a modern machine this is not a problem. Example: I am working on a text file of 84KB - in a 32 bit Erlang we use 8 bytes/character - so I use 0.6 MB - I have 4GB memory - so I use 0.015% of memory - ie no problem. My strategy is to keep large strings as binaries when I'm not working on them, turn them into lists in order to work on them, and turn them back into binaries when I'm done. Just because a string starts off in a binary does not mean that it has to stay as a binary as you work on it. Imagine I have a lot of text files, say each of 50KB, I can store 20 per/MB or 20,000 files per GB. Assume I have a quad core. I can only work on four things at the same time - so having (say) 20,000 files (at 50K) and work on four of them (unpacked) at a time is another 1.6 Meg. Gigabyte memories mean (among other things) what saving the odd byte here are there is hardly relevant. ? On another hand list allows to represent a code point per element. > yes - the convenience of having one character per list element far outweighs the space saving of storing strings in binaries ? iolists are also very handy to dynamically compose a complex strings. > >I am afraid that this is an application specific questions? However, I tend to use binary for strings... > > My strings change form depending on what I'm doing. Sometimes they are binaries, sometimes lists, sometimes trees, ... Cheers /Joe ? - Dmitry > > > >On Dec 29, 2012, at 4:08 PM, Steve Davis wrote: > >> Disclaimer :-) All the below is prefixed by a big IMHO >> >> Erlang has been correctly criticized for the difficulty of handling "strings". >> >> There are two reasons for this (fundamental decisions that were taken way-back-when): >> 1) "strings" are "just lists of integers" >> 2) "strings" are by default latin-1 representations >> >> This introduces major inconveniences, some of which are not resolvable: >> When faced with any list during pattern matching, it is not at all easy to determine whether that list is a "string". >> Further, since strings are "only" a subset of the set of lists of integers, it can be impossible to determine programmatically whether the list is a list of integers or is meant to represent a string. Determining whether a particular list even qualifies as a string in a program requires non-trivial processing of the entire list. >> >> It's rather unfortunate that Erlang has earned this reputation, since the truth is that Erlang is truly excellent at text processing. However, to benefit from this excellence, you need to do two things: >> 1) Represent and process text as binaries. >> 2) Assume that the text binary is UTF-8 encoded, unless otherwise stated (meaning, e.g. #text{encoding = cstring, value = <<116,101,120,116,0>>}). >> >> Suddenly, thanks to binary syntax and pattern matching, processing text in your programs becomes deterministic and easy. (Note that part of the reason for this is that binaries are "expected" to be opaque, whereas general list processing is fundamental to writing any program in Erlang). >> >> There's a couple of minor drawbacks, both of which are the result of the initial decisions about "strings": >> 1) The code is littered with additional angle brackets <<"string">> (annoying, but definitely worth the inconvenience) >> 2) The standard Erlang/OTP library functions require textual arguments as lists (requiring overuse of binary_to_list) >> >> And there are further benefits: >> 1) Parsing/transcoding different charset encodings is far more straightforward >> 2) Internationalization/localization is far more straightfoward >> >> I wonder if, had the current binary pattern matching/comprehensions been available "way-back-when", whether the decision about "string" representation in Erlang may have been different. (i.e. <<116,101,120,116>> = "text"). >> >> Finally, here's my two questions: >> 1) Is there any benefit at all to the "list representation" of strings above binary text? >> 2) If not, I wonder if there's any way to change our minds about "strings" as we enter 2013? >> >> regs, >> /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 > _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From masklinn@REDACTED Thu Jan 3 00:40:48 2013 From: masklinn@REDACTED (Masklinn) Date: Thu, 3 Jan 2013 00:40:48 +0100 Subject: [erlang-questions] Strings and Text Processing In-Reply-To: References: , <6E1DA248-66E9-43C0-B0CE-9D95A3079C8E@masklinn.net>, <1356800348.72926.YahooMailNeo@web120705.mail.ne1.yahoo.com>, Message-ID: <44C64144-EB79-492A-A3B5-A42BAE5380F7@masklinn.net> On 2012-12-31, at 21:11 , Matthew Evans wrote: > Really there are advantages for using both lists or binaries, but I think one of the "issues" with string handling is the need for consistent library support between the two. What would be nice is to have consistent support with the Erlang libraries to handle both types (e.g. string, re, regexp etc.). > Just my 2c? Which would work nicely if the understanding of "strings" (and the corresponding string-using functions) was extended to iolists (even more so if bare binaries were included in iolists as well, but it's easy enough to wrap them in a list), as I previously noted. Although there's an issue when using binaries for strings: what's the encoding? From stfairy@REDACTED Thu Jan 3 01:53:44 2013 From: stfairy@REDACTED (Xiao Jia) Date: Thu, 3 Jan 2013 08:53:44 +0800 Subject: [erlang-questions] Unicorn-style load balancing in Erlang? In-Reply-To: References: Message-ID: Thanks for your reply. I have used ranch before, and I think Unicorn is more than an acceptor pool. In ranch, acceptor processes only do "accept", and then dispatch the request to some worker process. I believe swarm works the same way as a middleman. In Unicorn, there's no separate worker (or acceptor) process; a prefork process is both acceptor and worker. All the prefork processes start out by calling "accept()" on the same listener socket. Then it's the OS kernel who determines which "accept()" to awake, while others remain sleeping. >From the documentation of ranch: > Our observations suggest that using 100 acceptors > on modern hardware is a good solution, as it's big > enough to always have acceptors ready and it's low > enough that it doesn't have a negative impact on > the system's performances. What if there's no separate worker process? Will many number of acceptor-and-workers have a negative impact as well? On Thu, Jan 3, 2013 at 5:25 AM, Daniel Goertzen wrote: > For bare acceptor pool libraries, take a look at... > > https://github.com/extend/ranch > https://github.com/jeremey/swarm > > And I would bet that most significant socket server apps written in Erlang > would use acceptor pooling of some sort. > > Dan. > > On Wed, Jan 2, 2013 at 10:09 AM, Xiao Jia wrote: >> >> From http://www.erlang.org/doc/man/gen_tcp.html#accept-1: >> >> > It is worth noting that the accept call does not have to be issued >> > from the socket owner process. Using version 5.5.3 and higher of >> > the emulator, multiple simultaneous accept calls can be issued >> > from different processes, which allows for a pool of acceptor >> > processes handling incoming connections. >> >> Does it mean that we can have Unicorn-style load balancing in Erlang? >> If so, are there any existing servers or libraries making use of this >> feature? >> >> For those who are not familiar with Unicorn [1], it is a traditional >> UNIX prefork web server. Load balancing between worker processes is >> done by the OS kernel. All workers share a common set of listener >> sockets and does non-blocking accept() on them. The kernel will decide >> which worker process to give a socket to and workers will sleep if >> there is nothing to accept(). >> >> btw, I also posted this question on StackOverflow [2] but no active >> responses there :-( >> >> [1]: http://unicorn.bogomips.org/ >> [2]: >> http://stackoverflow.com/questions/14121987/unicorn-style-load-balancing-in-erlang >> >> --- >> Regards, >> Xiao Jia >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > From essen@REDACTED Thu Jan 3 02:07:48 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Thu, 03 Jan 2013 02:07:48 +0100 Subject: [erlang-questions] Unicorn-style load balancing in Erlang? In-Reply-To: References: Message-ID: <50E4D9E4.70701@ninenines.eu> I believe from the README that swarm creates processes that accept and then become workers as you mentioned. On 01/03/2013 01:53 AM, Xiao Jia wrote: > Thanks for your reply. > > I have used ranch before, and I think Unicorn is more than an acceptor > pool. In ranch, acceptor processes only do "accept", and then dispatch > the request to some worker process. I believe swarm works the same way > as a middleman. > > In Unicorn, there's no separate worker (or acceptor) process; a > prefork process is both acceptor and worker. All the prefork processes > start out by calling "accept()" on the same listener socket. Then it's > the OS kernel who determines which "accept()" to awake, while others > remain sleeping. > > From the documentation of ranch: >> Our observations suggest that using 100 acceptors >> on modern hardware is a good solution, as it's big >> enough to always have acceptors ready and it's low >> enough that it doesn't have a negative impact on >> the system's performances. > > What if there's no separate worker process? Will many number of > acceptor-and-workers have a negative impact as well? > > On Thu, Jan 3, 2013 at 5:25 AM, Daniel Goertzen > wrote: >> For bare acceptor pool libraries, take a look at... >> >> https://github.com/extend/ranch >> https://github.com/jeremey/swarm >> >> And I would bet that most significant socket server apps written in Erlang >> would use acceptor pooling of some sort. >> >> Dan. >> >> On Wed, Jan 2, 2013 at 10:09 AM, Xiao Jia wrote: >>> >>> From http://www.erlang.org/doc/man/gen_tcp.html#accept-1: >>> >>>> It is worth noting that the accept call does not have to be issued >>>> from the socket owner process. Using version 5.5.3 and higher of >>>> the emulator, multiple simultaneous accept calls can be issued >>>> from different processes, which allows for a pool of acceptor >>>> processes handling incoming connections. >>> >>> Does it mean that we can have Unicorn-style load balancing in Erlang? >>> If so, are there any existing servers or libraries making use of this >>> feature? >>> >>> For those who are not familiar with Unicorn [1], it is a traditional >>> UNIX prefork web server. Load balancing between worker processes is >>> done by the OS kernel. All workers share a common set of listener >>> sockets and does non-blocking accept() on them. The kernel will decide >>> which worker process to give a socket to and workers will sleep if >>> there is nothing to accept(). >>> >>> btw, I also posted this question on StackOverflow [2] but no active >>> responses there :-( >>> >>> [1]: http://unicorn.bogomips.org/ >>> [2]: >>> http://stackoverflow.com/questions/14121987/unicorn-style-load-balancing-in-erlang >>> >>> --- >>> Regards, >>> Xiao Jia >>> _______________________________________________ >>> erlang-questions mailing list >>> 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 Erlang Cowboy Nine Nines http://ninenines.eu From surferjeff@REDACTED Thu Jan 3 04:26:09 2013 From: surferjeff@REDACTED (Jeffrey Rennie) Date: Wed, 2 Jan 2013 19:26:09 -0800 Subject: [erlang-questions] open_port returns enoent even when driver init function executes correctly. Message-ID: <008a01cde962$13dfe700$3b9fb500$@com> I'm working through the example here: http://www.erlang.org/doc/tutorial/c_portdriver.html And I'm trying to get it to run on Windows. I reordered the code in the C source so that it compiles, and added a module.def file so that erlang actually finds and executes the driver init function. I attached a debugger. Walking back up the stack, I observe that: The driver init function returns correctly. erts_sys_ddll_call_init() returns correctly. do_load_driver_entry() returns ERL_DE_NO_ERROR. load_driver_entry() returns ERL_DE_NO_ERROR. erl_ddll_try_load_3 returns t = TUPLE2(hp, am_ok, ok_term); on line 417 of erl_bif_ddl.c. But the next higher call on the stack is _process_main(), which was compiled with gcc and has no debug symbols so I can't step through and figure out why the end result is: =ERROR REPORT==== 2-Jan-2013::19:14:22 === Error in process <0.31.0> with exit value: {enoent,[{erlang,open_port,[{spawn,"example_drv"},[]],[]},{complex5,init,1,[ {file,"c:/Users/jeff/code/code/port_driver/complex5.erl"},{line,19}]}]} Has anyone seen this before? If not, how do I recompile erl.exe purely with cl.exe (no gcc) so that it generates debug symbols? And while I'm recompiling, how do I turn off all optimizations? I can read basic make files, but I get lost in the configure scripts and .in and .mk files. Please take pity on a Windows programmer ;-) From stfairy@REDACTED Thu Jan 3 04:52:05 2013 From: stfairy@REDACTED (Xiao Jia) Date: Thu, 3 Jan 2013 11:52:05 +0800 Subject: [erlang-questions] Unicorn-style load balancing in Erlang? In-Reply-To: <50E4D9E4.70701@ninenines.eu> References: <50E4D9E4.70701@ninenines.eu> Message-ID: Oh I see. The way swarm works is the same as Unicorn in the sense that the acceptor and worker is combined. But they are a bit different because swarm can accept a new socket in parallel with the processing of the accepted socket, while Unicorn only accepts after the accepted socket is processed. So Unicorn has better control of the number of processes (well it's prefork by nature) but requests have to be *fast*. I prefer the swarm style since it's ideal for both fast and slow requests. Thanks, that's a great work :-) On Thu, Jan 3, 2013 at 9:07 AM, Lo?c Hoguin wrote: > I believe from the README that swarm creates processes that accept and then > become workers as you mentioned. > > > On 01/03/2013 01:53 AM, Xiao Jia wrote: >> >> Thanks for your reply. >> >> I have used ranch before, and I think Unicorn is more than an acceptor >> pool. In ranch, acceptor processes only do "accept", and then dispatch >> the request to some worker process. I believe swarm works the same way >> as a middleman. >> >> In Unicorn, there's no separate worker (or acceptor) process; a >> prefork process is both acceptor and worker. All the prefork processes >> start out by calling "accept()" on the same listener socket. Then it's >> the OS kernel who determines which "accept()" to awake, while others >> remain sleeping. >> >> From the documentation of ranch: >>> >>> Our observations suggest that using 100 acceptors >>> on modern hardware is a good solution, as it's big >>> enough to always have acceptors ready and it's low >>> enough that it doesn't have a negative impact on >>> the system's performances. >> >> >> What if there's no separate worker process? Will many number of >> acceptor-and-workers have a negative impact as well? >> >> On Thu, Jan 3, 2013 at 5:25 AM, Daniel Goertzen >> wrote: >>> >>> For bare acceptor pool libraries, take a look at... >>> >>> https://github.com/extend/ranch >>> https://github.com/jeremey/swarm >>> >>> And I would bet that most significant socket server apps written in >>> Erlang >>> would use acceptor pooling of some sort. >>> >>> Dan. >>> >>> On Wed, Jan 2, 2013 at 10:09 AM, Xiao Jia wrote: >>>> >>>> >>>> From http://www.erlang.org/doc/man/gen_tcp.html#accept-1: >>>> >>>>> It is worth noting that the accept call does not have to be issued >>>>> from the socket owner process. Using version 5.5.3 and higher of >>>>> the emulator, multiple simultaneous accept calls can be issued >>>>> from different processes, which allows for a pool of acceptor >>>>> processes handling incoming connections. >>>> >>>> >>>> Does it mean that we can have Unicorn-style load balancing in Erlang? >>>> If so, are there any existing servers or libraries making use of this >>>> feature? >>>> >>>> For those who are not familiar with Unicorn [1], it is a traditional >>>> UNIX prefork web server. Load balancing between worker processes is >>>> done by the OS kernel. All workers share a common set of listener >>>> sockets and does non-blocking accept() on them. The kernel will decide >>>> which worker process to give a socket to and workers will sleep if >>>> there is nothing to accept(). >>>> >>>> btw, I also posted this question on StackOverflow [2] but no active >>>> responses there :-( >>>> >>>> [1]: http://unicorn.bogomips.org/ >>>> [2]: >>>> >>>> http://stackoverflow.com/questions/14121987/unicorn-style-load-balancing-in-erlang >>>> >>>> --- >>>> Regards, >>>> Xiao Jia >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> 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 > Erlang Cowboy > Nine Nines > http://ninenines.eu From surferjeff@REDACTED Thu Jan 3 05:53:30 2013 From: surferjeff@REDACTED (SurferJeff) Date: Wed, 2 Jan 2013 20:53:30 -0800 (PST) Subject: [erlang-questions] open_port returns enoent even when driver init function executes correctly. In-Reply-To: <008a01cde962$13dfe700$3b9fb500$@com> References: <008a01cde962$13dfe700$3b9fb500$@com> Message-ID: I found the recipe to build debug: $ cd $ERL_TOP $ rm bin/win32/erlexec.dll $ cd erts/emulator $ make debug $ cd ../etc $ make debug And it succeeded. However, the next command in the recipe fails: jeff@REDACTED /cygdrive/c/Users/jeff/GitHub/otp $ make local_setup make[1]: Entering directory `/cygdrive/c/Users/jeff/GitHub/otp/erts' make[2]: Entering directory `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_script s' make[2]: Nothing to be done for `debug'. make[2]: Leaving directory `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_scripts ' ct_run.exe dialyzer.exe erl.ini erl_crash.dump escript.exe run_test.exe typer.ex e werl.exe win32 make[2]: Entering directory `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_script s' /usr/bin/install -c -d /cygdrive/c/users/jeff/github/otp/erts/start_scripts/tmp ( cd /cygdrive/c/users/jeff/github/otp/erts/start_scripts/tmp && \ erlc -W -I/cygdrive/c/users/jeff/github/otp/lib/kernel/ebin -I/cygdrive/c/use rs/jeff/github/otp/lib/stdlib/ebin -I/cygdrive/c/users/jeff/github/otp/lib/sasl/ ebin +no_warn_sasl +otp_build -o /cygdrive/c/users/jeff/github/otp/bin/start.scr ipt /cygdrive/c/users/jeff/github/otp/erts/start_scripts/start_clean.rel ) File not found: "c:/cygdrive/c/users/jeff/github/otp/erts/start_scripts/start_cl ean.rel" Makefile:129: recipe for target `/cygdrive/c/users/jeff/github/otp/bin/start.scr ipt' failed make[2]: *** [/cygdrive/c/users/jeff/github/otp/bin/start.script] Error 1 make[2]: Leaving directory `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_scripts ' Makefile:69: recipe for target `local_setup' failed make[1]: *** [local_setup] Error 2 make[1]: Leaving directory `/cygdrive/c/Users/jeff/GitHub/otp/erts' Makefile:883: recipe for target `local_setup' failed make: *** [local_setup] Error 2 And now my erl.exe is completely hosed: jeff@REDACTED /cygdrive/c/Users/jeff/GitHub/otp/bin/win32 $ ./erl.exe {(no error logger present"i)n ietr rtoerr: m"iEnrartoirn gi ni np rdooc_ebsoost "<,0{.b2a.d0a>r wgi,t[h{ eerxli_tp rviaml_uleo:a d{ebra,dcahregc,k[_{feirlle__pr reismu_llto,a3d,e[r{,fcihleec,k"_efrill_ep_rriems_ullota,d3er,[.{efrill"e},,\{"l eirnle_,p28r3i}m]_}l,o{aidneirt.,egrelt\_"b}o,o{tl,i1n,e[,{2f8i3l}e,]"}i,n{iitn. ite,rgle"t},_{bloionte,,178,5[}{]f}i,l{ei,n\i"ti,ngiett._ebrolo\t",}2,,{[l{ifnie l,e7,8"5i}n]i}t,.{eirnli"t},,g{elti_nbeo,o77t2,}2]},,[{{ifniilte,,d\o"_ibnoiott. ,e3r,l[\{"f}i,l{el,i"nien,i7t7.2e}r]l}",}{,i{nliitn,ed,o73_9b}o]o}t],}3}, [{file,\"init.erl\"},{line,739}]}]}\n" Crash dump was written to: erl_crash.dump init terminating in do_boot () On Wednesday, January 2, 2013 7:26:09 PM UTC-8, SurferJeff wrote: > I'm working through the example here: > http://www.erlang.org/doc/tutorial/c_portdriver.html > And I'm trying to get it to run on Windows. I reordered the code in the C > source so that it compiles, and added a module.def file so that erlang > actually finds and executes the driver init function. > > I attached a debugger. Walking back up the stack, I observe that: > The driver init function returns correctly. > erts_sys_ddll_call_init() returns correctly. > do_load_driver_entry() returns ERL_DE_NO_ERROR. > load_driver_entry() returns ERL_DE_NO_ERROR. > erl_ddll_try_load_3 returns t = TUPLE2(hp, am_ok, ok_term); on line 417 of > erl_bif_ddl.c. > But the next higher call on the stack is _process_main(), which was > compiled > with gcc and has no debug symbols so I can't step through and figure out > why > the end result is: > > =ERROR REPORT==== 2-Jan-2013::19:14:22 === > Error in process <0.31.0> with exit value: > {enoent,[{erlang,open_port,[{spawn,"example_drv"},[]],[]},{complex5,init,1,[ > > {file,"c:/Users/jeff/code/code/port_driver/complex5.erl"},{line,19}]}]} > > Has anyone seen this before? > > If not, how do I recompile erl.exe purely with cl.exe (no gcc) so that it > generates debug symbols? And while I'm recompiling, how do I turn off all > optimizations? I can read basic make files, but I get lost in the > configure > scripts and .in and .mk files. Please take pity on a Windows programmer > ;-) > > > _______________________________________________ > 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 Thu Jan 3 07:16:26 2013 From: anthonym@REDACTED (Anthony Molinaro) Date: Wed, 2 Jan 2013 22:16:26 -0800 Subject: [erlang-questions] Any tcp related changes in R15B* that might cause this? In-Reply-To: References: <20121212182632.GB72594@alumni.caltech.edu> <20121212234803.GA75710@alumni.caltech.edu> <20121213002455.GA75861@alumni.caltech.edu> <20121213183830.GA81730@alumni.caltech.edu> <20121214211117.GA86501@alumni.caltech.edu> <50CF35FF.6020101@erix.ericsson.se> <20130102172816.GA24637@alumni.caltech.edu> Message-ID: <20130103061626.GB26037@alumni.caltech.edu> Attached is a test which shows the difference using only gen_tcp calls. Here's the output from both Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.8.5 (abort with ^G) 1> gen_tcp_test:test(1000). gen_tcp:send ok {{"HTTP/1.1",200,"OK"}, [{"date","Wed, 02 Jan 2013 21:01:08 GMT"}, {"server","Test"}, {"content-length","31"}, {"content-type","text/html"}], "Hello"} 2> gen_tcp_test:test(10000). http_error - R14 gen_tcp:send ok {{"HTTP/1.1",400,"Bad Request"}, [{"date","Wed, 02 Jan 2013 21:03:24 GMT"}, {"server","Test"}, {"content-length","0"}], []} 3> and for R15 Erlang R15B02 (erts-5.9.2) [source] [64-bit] [smp:2:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9.2 (abort with ^G) 1> gen_tcp_test:test(1000). gen_tcp:send ok {{"HTTP/1.1",200,"OK"}, [{"date","Wed, 02 Jan 2013 21:01:08 GMT"}, {"server","Test"}, {"content-length","31"}, {"content-type","text/html"}], "Hello"} 2> gen_tcp_test:test(10000). emsgsize - R15 gen_tcp:send failed with {error,closed} socket_closed_remotely 3> Hope it helps, -Anthony On Wed, Jan 02, 2013 at 12:34:56PM -0500, Steve Vinoski wrote: > Hi Anthony and Sverker, as I mentioned in a previous email, using Anthony's > test case a few weeks ago I bisected between R14B04 and HEAD and found > commit dc5f7190 to be the first commit where the test case fails. > > --steve > > On Wed, Jan 2, 2013 at 12:28 PM, Anthony Molinaro < > anthonym@REDACTED> wrote: > > > Hi, > > > > The holidays went and interrupted everything, so I'm sorry about the > > late response. > > It's unclear if the commit dc5f7190 did it or not, but sometime between > > R14B04 and R15B02 the behavior did change. I've not isolated it outside > > of mochiweb, but I don't think its a mochiweb problem. > > > > Here's the pull request which contains the short program I used to > > reproduce with mochiweb (and work around the new behavior) > > > > https://github.com/mochi/mochiweb/pull/91 > > > > I'll see if I can't isolate it to just OTP sometime in the next > > couple of days. > > > > -Anthony > > > > On Mon, Dec 17, 2012 at 04:10:55PM +0100, Sverker Eriksson wrote: > > > Have I understood it correctly so far if I say that my commit > > > dc5f7190 seems to cause a > > > > > > {tcp_error,Port,emsgsize} > > > > > > while earlier versions caused a > > > > > > {http,Port,{http_error,"..."}} > > > > > > > > > for the same scenario with some sort of very long http lines? > > > > > > /Sverker, Erlang/OTP > > > > > > Anthony Molinaro wrote: > > > >On Fri, Dec 14, 2012 at 11:32:11AM -0500, Steve Vinoski wrote: > > > >>Hi Anthony, based on your example, it looks like a follow-up commit > > that > > > >>modified some of the changes introduced by my patch introduced the > > issue > > > >>you're seeing: commit dc5f7190. You might want to report it over on > > > >>erlang-bugs. > > > > > > > >Nice catch, I guess that it's actually not enough to return error > > > >for backward compatibility ;) > > > > > > > >I think the main thing I'm still not sure of is if the decode_packet > > changes > > > >are actually the cause. I was able to call decode_packet with long > > headers > > > >and not actually see an issue. > > > > > > > >This > > > > > > > >erlang:decode_packet ( httph, > > > > list_to_binary ([ "X-Random: ", > > > > [$a || _ <- > > lists:seq(1,10000)], > > > > "\r\n\r\n" > > > > ]), > > > > []). > > > > > > > >Returns the same thing in both R14B04 and R15B02. And as far as I am > > able > > > >to tell that is the only call made to decode_packet in mochiweb. > > > > > > > >I think the actual error is around recvbuf sizing (mochiweb uses 8192 as > > > >the default, so 10000 is definitely larger than that, however, the > > standard > > > >libraries must be doing something different as now it returns emsgsize > > > >where it did no in the past). I really wish there was a way to search > > > >commits on github as then I could search for recvbuf or something like > > > >that to see what might have changed. > > > > > > > >Before I go over to bugs I'll probably try to detangle mochiweb enough > > > >to create a small reproducible test case. > > > > > > > >I also have a pull request into mochiweb which prevents the crash but > > > >has the annoying behavior at the moment that it returns an error to the > > > >client about disconnecting version the 400 error it returned before. > > > > > > > >https://github.com/mochi/mochiweb/pull/91 > > > > > > > >But since the standard library seems to be the one closing the socket > > > >there's not much that can be done other than the fix I put in place. > > > > > > > >Thanks for your help Steve, > > > > > > > >-Anthony > > > > > > > > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > > ------------------------------------------------------------------------ > > Anthony Molinaro > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > -- ------------------------------------------------------------------------ Anthony Molinaro -------------- next part -------------- -module (gen_tcp_test). -export ([start/0, start_one/0, test/1]). start () -> application:start (inets), spawn (gen_tcp_test, start_one, []). start_one () -> {ok, LSock} = gen_tcp:listen (5678, [ binary, {reuseaddr,true}, {packet,0}, {active,false} ]), {ok, Sock} = gen_tcp:accept (LSock), ok = inet:setopts (Sock, [{packet, http}]), Resp = req (Sock), case gen_tcp:send (Sock, Resp) of ok -> io:format ("gen_tcp:send ok~n"); E -> io:format ("gen_tcp:send failed with ~p~n",[E]) end, close (Sock). close (Socket) -> gen_tcp:close (Socket), exit (normal). req (Socket) -> ok = inet:setopts (Socket, [{active, once}]), receive {_, _, {http_request, _, _, _}} -> ok = inet:setopts(Socket, [{packet, httph}]), headers (Socket) end. headers (Socket) -> ok = inet:setopts(Socket, [{active, once}]), receive {_, _, http_eoh} -> ok = inet:setopts(Socket, [{packet, raw}]), [<<"HTTP/1.1 ">>, ["200",[" ",79,75]], <<"\r\n">>, "Server",<<": ">>, "Test",<<"\r\n">>, "Date",<<": ">>,"Wed, 02 Jan 2013 21:01:08 GMT",<<"\r\n">>, "Content-Type",<<": ">>,"text/html",<<"\r\n">>, "Content-Length",<<": ">>,"31",<<"\r\n">>,<<"\r\n">>, "Hello"]; {_,_, {http_header, _, _, _, _}} -> headers (Socket); {_,_, {http_error, _}} -> io:format("http_error - R14~n"), invalid (Socket); {tcp_error, _, emsgsize} -> io:format("emsgsize - R15~n"), invalid (Socket) end. invalid (_Socket) -> [ <<"HTTP/1.1 ">>, [ "400",[" ",66,97,100,32,82,101,113,117,101,115,116]],<<"\r\n">>, "Server",<<": ">>, "Test",<<"\r\n">>, "Date",<<": ">>,"Wed, 02 Jan 2013 21:03:24 GMT",<<"\r\n">>, "Content-Length",<<": ">>,"0",<<"\r\n">>,<<"\r\n">> ]. test (Len) -> start (), case httpc:request (get, { "http://127.0.0.1:5678/", [{"X-Random", [$a || _ <- lists:seq(1,Len)]}] }, [], []) of {ok, Resp} -> Resp; {error, Err} -> Err end. From rtrlists@REDACTED Thu Jan 3 09:30:48 2013 From: rtrlists@REDACTED (Robert Raschke) Date: Thu, 3 Jan 2013 08:30:48 +0000 Subject: [erlang-questions] open_port returns enoent even when driver init function executes correctly. In-Reply-To: <008a01cde962$13dfe700$3b9fb500$@com> References: <008a01cde962$13dfe700$3b9fb500$@com> Message-ID: Hi Jeffrey, I don't have those sources in front of me, but is there any chance that the C code depends on another DLL? And that other one isn't on the path when the driver is started from Erlang? I've found Windows to be super obscure when dependencies in DLLs don't resolve properly. Regards, Robby On Jan 3, 2013 3:26 AM, "Jeffrey Rennie" wrote: > I'm working through the example here: > http://www.erlang.org/doc/tutorial/c_portdriver.html > And I'm trying to get it to run on Windows. I reordered the code in the C > source so that it compiles, and added a module.def file so that erlang > actually finds and executes the driver init function. > > I attached a debugger. Walking back up the stack, I observe that: > The driver init function returns correctly. > erts_sys_ddll_call_init() returns correctly. > do_load_driver_entry() returns ERL_DE_NO_ERROR. > load_driver_entry() returns ERL_DE_NO_ERROR. > erl_ddll_try_load_3 returns t = TUPLE2(hp, am_ok, ok_term); on line 417 of > erl_bif_ddl.c. > But the next higher call on the stack is _process_main(), which was > compiled > with gcc and has no debug symbols so I can't step through and figure out > why > the end result is: > > =ERROR REPORT==== 2-Jan-2013::19:14:22 === > Error in process <0.31.0> with exit value: > > {enoent,[{erlang,open_port,[{spawn,"example_drv"},[]],[]},{complex5,init,1,[ > {file,"c:/Users/jeff/code/code/port_driver/complex5.erl"},{line,19}]}]} > > Has anyone seen this before? > > If not, how do I recompile erl.exe purely with cl.exe (no gcc) so that it > generates debug symbols? And while I'm recompiling, how do I turn off all > optimizations? I can read basic make files, but I get lost in the > configure > scripts and .in and .mk files. Please take pity on a Windows programmer > ;-) > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rtrlists@REDACTED Thu Jan 3 09:36:58 2013 From: rtrlists@REDACTED (Robert Raschke) Date: Thu, 3 Jan 2013 08:36:58 +0000 Subject: [erlang-questions] open_port returns enoent even when driver init function executes correctly. In-Reply-To: References: <008a01cde962$13dfe700$3b9fb500$@com> Message-ID: You can try running erl.exe with sasl enabled to get better error messages. The messages you see at the moment are coming out interleaved, like in the old joke "When faced with a problem you decide to use threading, ..." :-) Robby On Jan 3, 2013 4:53 AM, "SurferJeff" wrote: > I found the recipe to build debug: > > $ cd $ERL_TOP > $ rm bin/win32/erlexec.dll > $ cd erts/emulator > $ make debug > $ cd ../etc > $ make debug > > > And it succeeded. However, the next command in the recipe fails: > jeff@REDACTED /cygdrive/c/Users/jeff/GitHub/otp > $ make local_setup > make[1]: Entering directory `/cygdrive/c/Users/jeff/GitHub/otp/erts' > make[2]: Entering directory > `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_script > s' > make[2]: Nothing to be done for `debug'. > make[2]: Leaving directory > `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_scripts > ' > ct_run.exe dialyzer.exe erl.ini erl_crash.dump escript.exe run_test.exe > typer.ex > e werl.exe win32 > make[2]: Entering directory > `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_script > s' > /usr/bin/install -c -d > /cygdrive/c/users/jeff/github/otp/erts/start_scripts/tmp > ( cd /cygdrive/c/users/jeff/github/otp/erts/start_scripts/tmp && \ > erlc -W -I/cygdrive/c/users/jeff/github/otp/lib/kernel/ebin > -I/cygdrive/c/use > rs/jeff/github/otp/lib/stdlib/ebin > -I/cygdrive/c/users/jeff/github/otp/lib/sasl/ > ebin +no_warn_sasl +otp_build -o > /cygdrive/c/users/jeff/github/otp/bin/start.scr > ipt /cygdrive/c/users/jeff/github/otp/erts/start_scripts/start_clean.rel ) > File not found: > "c:/cygdrive/c/users/jeff/github/otp/erts/start_scripts/start_cl > ean.rel" > Makefile:129: recipe for target > `/cygdrive/c/users/jeff/github/otp/bin/start.scr > ipt' failed > make[2]: *** [/cygdrive/c/users/jeff/github/otp/bin/start.script] Error 1 > make[2]: Leaving directory > `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_scripts > ' > Makefile:69: recipe for target `local_setup' failed > make[1]: *** [local_setup] Error 2 > make[1]: Leaving directory `/cygdrive/c/Users/jeff/GitHub/otp/erts' > Makefile:883: recipe for target `local_setup' failed > make: *** [local_setup] Error 2 > > > And now my erl.exe is completely hosed: > jeff@REDACTED /cygdrive/c/Users/jeff/GitHub/otp/bin/win32 > $ ./erl.exe > {(no error logger present"i)n ietr rtoerr: m"iEnrartoirn gi ni np > rdooc_ebsoost > "<,0{.b2a.d0a>r wgi,t[h{ eerxli_tp rviaml_uleo:a > d{ebra,dcahregc,k[_{feirlle__pr > > reismu_llto,a3d,e[r{,fcihleec,k"_efrill_ep_rriems_ullota,d3er,[.{efrill"e},,\{"l > > eirnle_,p28r3i}m]_}l,o{aidneirt.,egrelt\_"b}o,o{tl,i1n,e[,{2f8i3l}e,]"}i,n{iitn. > > ite,rgle"t},_{bloionte,,178,5[}{]f}i,l{ei,n\i"ti,ngiett._ebrolo\t",}2,,{[l{ifnie > > l,e7,8"5i}n]i}t,.{eirnli"t},,g{elti_nbeo,o77t2,}2]},,[{{ifniilte,,d\o"_ibnoiott. > ,e3r,l[\{"f}i,l{el,i"nien,i7t7.2e}r]l}",}{,i{nliitn,ed,o73_9b}o]o}t],}3}, > [{file,\"init.erl\"},{line,739}]}]}\n" > Crash dump was written to: erl_crash.dump > init terminating in do_boot () > > > On Wednesday, January 2, 2013 7:26:09 PM UTC-8, SurferJeff wrote: > >> I'm working through the example here: >> http://www.erlang.org/doc/**tutorial/c_portdriver.html >> And I'm trying to get it to run on Windows. I reordered the code in the >> C >> source so that it compiles, and added a module.def file so that erlang >> actually finds and executes the driver init function. >> >> I attached a debugger. Walking back up the stack, I observe that: >> The driver init function returns correctly. >> erts_sys_ddll_call_init() returns correctly. >> do_load_driver_entry() returns ERL_DE_NO_ERROR. >> load_driver_entry() returns ERL_DE_NO_ERROR. >> erl_ddll_try_load_3 returns t = TUPLE2(hp, am_ok, ok_term); on line 417 >> of >> erl_bif_ddl.c. >> But the next higher call on the stack is _process_main(), which was >> compiled >> with gcc and has no debug symbols so I can't step through and figure out >> why >> the end result is: >> >> =ERROR REPORT==== 2-Jan-2013::19:14:22 === >> Error in process <0.31.0> with exit value: >> {enoent,[{erlang,open_port,[{**spawn,"example_drv"},[]],[]},{**complex5,init,1,[ >> >> {file,"c:/Users/jeff/code/**code/port_driver/complex5.erl"**},{line,19}]}]} >> >> >> Has anyone seen this before? >> >> If not, how do I recompile erl.exe purely with cl.exe (no gcc) so that it >> generates debug symbols? And while I'm recompiling, how do I turn off >> all >> optimizations? I can read basic make files, but I get lost in the >> configure >> scripts and .in and .mk files. Please take pity on a Windows programmer >> ;-) >> >> >> ______________________________**_________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/**listinfo/erlang-questions >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Thu Jan 3 10:07:21 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 3 Jan 2013 10:07:21 +0100 Subject: [erlang-questions] inspect process mailbox size In-Reply-To: References: <49849562.4050202@moonpolysoft.com> <446f9f38-4ee6-4d09-bd82-f77fdf6bfd5c@googlegroups.com> Message-ID: <0CBEF1E0-9009-4F37-AEF7-A2CBB64F8F56@erlang-solutions.com> The way to restrict a mailbox is to implement some kind of flow control on the mailbox to make sure it does not overflow. Currently, there is no way to limit the mailbox size - but do note that the VM makes sending messages to large mailboxes more expensive. This implements a somewhat rudimentary flow control and makes sure you need to screw up to a larger extent. Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen On Dec 21, 2012, at 5:16 AM, Harsh J wrote: > I'm not aware of any way to do that (but please let me know if there > is one). However, this past thread may be helpful to you: > http://erlang.org/pipermail/erlang-questions/2011-June/059355.html > > On Fri, Dec 21, 2012 at 8:52 AM, krad wrote: >> a further question is, is there anyway to restrict the mailbox size? >> >> On Sunday, February 1, 2009 3:11:14 AM UTC+8, Geoff Cant wrote: >>> >>> Cliff Moon writes: >>> >>>> is there any way to inspect mailbox size at runtime? Under load testing >>>> I'm seeing conditions pop up where a node will go out of control due to >>>> mailbox growth and it's rather hard to debug the issue post mortem from >>>> crash dumps. >>> >>> erlang:process_info/2 is very helpful for this: >>> erlang:process_info(Pid, messages_queue_len) gives you the length of the >>> queue and erlang:process_info(Pid, messages) gives you the queue itself. >>> >>> A common cause of mailbox blowout is that the process is blocked waiting >>> for a reply from something - in this case erlang:process_info(Pid, >>> backtrace) and erlang:process_info(Pid, current_function) can help you >>> figure out what it might be waiting for. >>> >>> Cheers, >>> -- >>> Geoff Cant >>> >>> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > > -- > Harsh J > http://harshj.com > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From max.lapshin@REDACTED Thu Jan 3 10:30:30 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 3 Jan 2013 12:30:30 +0300 Subject: [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition Released In-Reply-To: <50D8DA63.2060600@ninenines.eu> References: <50D8DA63.2060600@ninenines.eu> Message-ID: Loic, it would be great to hear a bit, what problems have you met with. What issues with stability can be in acceptor pool? Also I have question about updating protocol options: have you done something with the problem that after updating protocol options existing workers are running with old config? On Tuesday, December 25, 2012, Lo?c Hoguin wrote: > Ho ho ho! > > I have just tagged version 0.6.0 of the Ranch project! > > Ranch is a socket acceptor pool for TCP protocols. > > https://github.com/extend/**ranch > > Ranch is used by the next version of Cowboy, 0.8.0, set to be released > early February, but also in Basho's Riak multi-data center replication > amongst others. > > All tickets have been resolved. A significant contribution was made by > Andrew Majorov to improve the fault tolerance capabilities of the > application, making sure it always restarts properly when things go wrong. > This has been made possible thanks to the amazing project from Daniel Luna, > chaos_monkey (https://github.com/dluna/**chaos_monkey > ). > > The guide has also been improved and completed. > > http://ninenines.eu/docs/en/**ranch/HEAD/guide/introduction > > If the guide isn't enough, drop by our new IRC channel dedicated to > Cowboy, Ranch and all our other projects! #ninenines on Freenode. > > Following is the list of change since last time: > > * Improve fault tolerance thanks to chaos_monkey testing > * Add 'nodelay' option to transports > * Add 'verify' option to ranch_ssl transport > * Add 'socket' option to pass an already open socket to the listener > * Add Transport:sendfile/2 function (uses a fallback if unavailable) > * Allow IP tuples in Transport:connect/3 > * Add ranch:set_max_connections/2 to update the value live > * Add ranch:get_max_connections/1 to retrieve it > > We are always looking for feedback, especially now that there is no ticket > left open on this project. If you are using Ranch and have questions or > needs that it doesn't cover, please send them to us. > > Commercial support will be available starting from January, ping me if you > are interested. Details will be announced at a later time on the > ninenines.eu mailing list. > > I want to thank all contributors for helping this project by opening > tickets, sending patches and offering feedback. I am as always very > grateful for any and all contributions. I wouldn't have made it this far > without the tremendous help I receive everyday. > > Thanks to all and have a nice holiday! > > -- > Lo?c Hoguin > Erlang Santa > Nine Nines > 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 Jan 3 10:34:53 2013 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 3 Jan 2013 10:34:53 +0100 Subject: [erlang-questions] Strings and Text Processing In-Reply-To: <1357169122.88636.YahooMailNeo@web162801.mail.bf1.yahoo.com> References: <65EC42E5-54A3-4556-A3DA-9E949255C1D1@gmail.com> <1357169122.88636.YahooMailNeo@web162801.mail.bf1.yahoo.com> Message-ID: On Thu, Jan 3, 2013 at 12:25 AM, J K wrote: > Hi, > > I'm not sure I understand your 20.000 files example. > *This was just to give an estimate of the total memory size* > Are you suggesting that the user should limit the number of erlang > processes to the number of cores or are you suggesting that the VM > compresses the erlang process data when not running? > You could experiment with limiting the number of active processes and compressing data when it's not being used (you'd have to do this yourself as part of the application). To first approximation one process per parallel activity is a good rule of thumb (and you let the Erlang scheduler figure out who is to run where) - the alternative is that you limit the number of parallel processes and decide when and where they execute - you are basically saying "because I know a lot about the specific details of my application I can do a better job of process management than the Erlang VM" - this is pretty tricky. That would be really nice if it can be done with only a small performance > penalty, say 10-20%. > > In my case I start 50.000 to 100.000 processes , one per file (it's an > (map reduce like) application to do feature extraction for some machine > learning algorithms) . > How big is each file? how much processing is needed per-file to do feature extraction? > One erlang node uses about 7GB of memory. I can probably tune it a bit (a > lot?) more by using binaries but it would be nice to have an option to > compress process data when not running, for people that are lazy/not an > erlang expert/does not have that much time (my case)/or just as an > indication of how much memory that could be saved by using binaries. > > look up the manual entry for hibernate/3 http://erlang.org/doc/man/erlang.html#hibernate-3 The hibernate BIF minimise the size of a process before putting it to sleep. It won't compress any process data - but it does trim the stack and heap before suspending a process. If you have a large number of processes that sleep for long times this might be a good idea. If your processes sleep for short times and wake up at random then it probably won't help. Performance tuning is a black art. Unfortunately it's *very* system dependent. If you change the number of cores, or operating system, or amount of memory you have to start again. If in doubt measure ! /Joe > JK > > > ------------------------------ > *From:* Joe Armstrong > *To:* Dmitry Kolesnikov > *Cc:* Steve Davis ; Erlang Questions < > erlang-questions@REDACTED> > *Sent:* Saturday, December 29, 2012 4:30 PM > > *Subject:* Re: [erlang-questions] Strings and Text Processing > > > > On Sat, Dec 29, 2012 at 3:20 PM, Dmitry Kolesnikov > wrote: > > Hello Steve, > > You have raised a good point here. > One more reason for binary is memory consumption and IPC overhead. > > > The point about memory consumption is raised *many* times - on a modern > machine this is not a problem. > > Example: I am working on a text file of 84KB - in a 32 bit Erlang we use > 8 bytes/character - so I use 0.6 MB - I have 4GB memory - so I use 0.015% > of > memory - ie no problem. > > My strategy is to keep large strings as binaries when I'm not working on > them, > turn them into lists in order to work on them, and turn them back into > binaries > when I'm done. Just because a string starts off in a binary does not mean > that it has to stay as a binary as you work on it. > > > Imagine I have a lot of text files, say each of 50KB, I can store 20 > per/MB or > 20,000 files per GB. Assume I have a quad core. I can only work on four > things > at the same time - so having (say) 20,000 files (at 50K) and work on four > of them > (unpacked) at a time is another 1.6 Meg. > > Gigabyte memories mean (among other things) what saving the odd byte here > are there is hardly relevant. > > > > On another hand list allows to represent a code point per element. > > > yes - the convenience of having one character per list element far > outweighs > the space saving of storing strings in binaries > > > > iolists are also very handy to dynamically compose a complex strings. > > I am afraid that this is an application specific questions? However, I > tend to use binary for strings... > > > My strings change form depending on what I'm doing. Sometimes they are > binaries, sometimes lists, sometimes trees, ... > > Cheers > > /Joe > > > > - Dmitry > > > On Dec 29, 2012, at 4:08 PM, Steve Davis > wrote: > > > Disclaimer :-) All the below is prefixed by a big IMHO > > > > Erlang has been correctly criticized for the difficulty of handling > "strings". > > > > There are two reasons for this (fundamental decisions that were taken > way-back-when): > > 1) "strings" are "just lists of integers" > > 2) "strings" are by default latin-1 representations > > > > This introduces major inconveniences, some of which are not resolvable: > > When faced with any list during pattern matching, it is not at all easy > to determine whether that list is a "string". > > Further, since strings are "only" a subset of the set of lists of > integers, it can be impossible to determine programmatically whether the > list is a list of integers or is meant to represent a string. Determining > whether a particular list even qualifies as a string in a program requires > non-trivial processing of the entire list. > > > > It's rather unfortunate that Erlang has earned this reputation, since > the truth is that Erlang is truly excellent at text processing. However, to > benefit from this excellence, you need to do two things: > > 1) Represent and process text as binaries. > > 2) Assume that the text binary is UTF-8 encoded, unless otherwise stated > (meaning, e.g. #text{encoding = cstring, value = <<116,101,120,116,0>>}). > > > > Suddenly, thanks to binary syntax and pattern matching, processing text > in your programs becomes deterministic and easy. (Note that part of the > reason for this is that binaries are "expected" to be opaque, whereas > general list processing is fundamental to writing any program in Erlang). > > > > There's a couple of minor drawbacks, both of which are the result of the > initial decisions about "strings": > > 1) The code is littered with additional angle brackets <<"string">> > (annoying, but definitely worth the inconvenience) > > 2) The standard Erlang/OTP library functions require textual arguments > as lists (requiring overuse of binary_to_list) > > > > And there are further benefits: > > 1) Parsing/transcoding different charset encodings is far more > straightforward > > 2) Internationalization/localization is far more straightfoward > > > > I wonder if, had the current binary pattern matching/comprehensions been > available "way-back-when", whether the decision about "string" > representation in Erlang may have been different. (i.e. <<116,101,120,116>> > = "text"). > > > > Finally, here's my two questions: > > 1) Is there any benefit at all to the "list representation" of strings > above binary text? > > 2) If not, I wonder if there's any way to change our minds about > "strings" as we enter 2013? > > > > regs, > > /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 > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Thu Jan 3 10:36:53 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 3 Jan 2013 10:36:53 +0100 Subject: [erlang-questions] Strings and Text Processing In-Reply-To: References: Message-ID: <66BB3ED8-E438-4BD2-9757-13E34EC05FE9@erlang-solutions.com> On Dec 29, 2012, at 3:08 PM, Steve Davis wrote: > 2) If not, I wonder if there's any way to change our minds about "strings" as we enter 2013? There is :) A String is often a notoriously bad way to represent data. Think about it: a string is really just a sequence of bytes with some interpretation (utf8 is common). The problem is that people tend to keep their data represented as strings where other data structures are better for the purpose. A Comma-separated file for instance is better represented as a list of tuples or a generator of tuples (and/or records). The reason you don't usually need a lot of syntactic sugar for manipulating strings are simply that you shouldn't be manipulating strings too much in the first case. A language like Perl is good for processing directly on text, but the weakness is that it has a harder time at structuring data like you should do in Erlang (Or ML or Haskell or ?). I have a hunch that most of the critique is really due to the fact that people are trying to write in the style of a different language in Erlang. Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen From essen@REDACTED Thu Jan 3 13:46:56 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 03 Jan 2013 13:46:56 +0100 Subject: [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition Released In-Reply-To: References: <50D8DA63.2060600@ninenines.eu> Message-ID: <50E57DC0.5090408@ninenines.eu> Haven't had any stability issue. What we did here is ensure that when any process gets killed for any reason, especially reasons we can't foresee, Ranch continues to work as expected. Ranch not updating protocol options for existing connections isn't a problem, it won't be "fixed". Ranch can't guess how connection processes are implemented. It's up to you to allow this if you need it. The upgrade updates the options for all acceptors and all future connections, that's it. On 01/03/2013 10:30 AM, Max Lapshin wrote: > Loic, it would be great to hear a bit, what problems have you met with. > > What issues with stability can be in acceptor pool? > > Also I have question about updating protocol options: have you done > something with the problem that after updating protocol options existing > workers are running with old config? > > On Tuesday, December 25, 2012, Lo?c Hoguin wrote: > > Ho ho ho! > > I have just tagged version 0.6.0 of the Ranch project! > > Ranch is a socket acceptor pool for TCP protocols. > > https://github.com/extend/__ranch > > Ranch is used by the next version of Cowboy, 0.8.0, set to be > released early February, but also in Basho's Riak multi-data center > replication amongst others. > > All tickets have been resolved. A significant contribution was made > by Andrew Majorov to improve the fault tolerance capabilities of the > application, making sure it always restarts properly when things go > wrong. This has been made possible thanks to the amazing project > from Daniel Luna, chaos_monkey > (https://github.com/dluna/__chaos_monkey > ). > > The guide has also been improved and completed. > > http://ninenines.eu/docs/en/__ranch/HEAD/guide/introduction > > > If the guide isn't enough, drop by our new IRC channel dedicated to > Cowboy, Ranch and all our other projects! #ninenines on Freenode. > > Following is the list of change since last time: > > * Improve fault tolerance thanks to chaos_monkey testing > * Add 'nodelay' option to transports > * Add 'verify' option to ranch_ssl transport > * Add 'socket' option to pass an already open socket to the listener > * Add Transport:sendfile/2 function (uses a fallback if unavailable) > * Allow IP tuples in Transport:connect/3 > * Add ranch:set_max_connections/2 to update the value live > * Add ranch:get_max_connections/1 to retrieve it > > We are always looking for feedback, especially now that there is no > ticket left open on this project. If you are using Ranch and have > questions or needs that it doesn't cover, please send them to us. > > Commercial support will be available starting from January, ping me > if you are interested. Details will be announced at a later time on > the ninenines.eu mailing list. > > I want to thank all contributors for helping this project by opening > tickets, sending patches and offering feedback. I am as always very > grateful for any and all contributions. I wouldn't have made it this > far without the tremendous help I receive everyday. > > Thanks to all and have a nice holiday! > > -- > Lo?c Hoguin > Erlang Santa > Nine Nines > http://ninenines.eu > _________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/__listinfo/erlang-questions > > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From steven.charles.davis@REDACTED Thu Jan 3 14:11:36 2013 From: steven.charles.davis@REDACTED (Steve Davis) Date: Thu, 3 Jan 2013 07:11:36 -0600 Subject: [erlang-questions] Strings and Text Processing In-Reply-To: <66BB3ED8-E438-4BD2-9757-13E34EC05FE9@erlang-solutions.com> References: <66BB3ED8-E438-4BD2-9757-13E34EC05FE9@erlang-solutions.com> Message-ID: <85023EF5-46B1-460F-B4F0-6FBAE0A20A9E@gmail.com> Hi Jesper, I do most certainly agree with your comments. The requirement for text processing is almost entirely a boundary consideration - made quite common owing to the number of text-based protocols and file formats out there. The provision of codecs that transform from string to the internal data representation, and then from the internal representation out to a string is a not-infrequent requirement of the code. Decoders are frequently far harder to write than encoders - and as I noted, made harder still when using erlang strings than when using binaries. Regards, Steve On Jan 3, 2013, at 3:36 AM, Jesper Louis Andersen wrote: > > > On Dec 29, 2012, at 3:08 PM, Steve Davis wrote: > >> 2) If not, I wonder if there's any way to change our minds about "strings" as we enter 2013? > > There is :) > > A String is often a notoriously bad way to represent data. Think about it: a string is really just a sequence of bytes with some interpretation (utf8 is common). The problem is that people tend to keep their data represented as strings where other data structures are better for the purpose. A Comma-separated file for instance is better represented as a list of tuples or a generator of tuples (and/or records). > > The reason you don't usually need a lot of syntactic sugar for manipulating strings are simply that you shouldn't be manipulating strings too much in the first case. A language like Perl is good for processing directly on text, but the weakness is that it has a harder time at structuring data like you should do in Erlang (Or ML or Haskell or ?). I have a hunch that most of the critique is really due to the fact that people are trying to write in the style of a different language in Erlang. > > Jesper Louis Andersen > Erlang Solutions Ltd., Copenhagen > From max.lapshin@REDACTED Thu Jan 3 14:32:16 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 3 Jan 2013 16:32:16 +0300 Subject: [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition Released In-Reply-To: <50E57DC0.5090408@ninenines.eu> References: <50D8DA63.2060600@ninenines.eu> <50E57DC0.5090408@ninenines.eu> Message-ID: I mean situation that after cowboy:update_options existing acceptors are still working with old routes. Currently it is useless API, so I have to stop cowboy and start it back. On Thu, Jan 3, 2013 at 4:46 PM, Lo?c Hoguin wrote: > Haven't had any stability issue. What we did here is ensure that when any > process gets killed for any reason, especially reasons we can't foresee, > Ranch continues to work as expected. > > Ranch not updating protocol options for existing connections isn't a > problem, it won't be "fixed". Ranch can't guess how connection processes > are implemented. It's up to you to allow this if you need it. The upgrade > updates the options for all acceptors and all future connections, that's it. > > > On 01/03/2013 10:30 AM, Max Lapshin wrote: > >> Loic, it would be great to hear a bit, what problems have you met with. >> >> What issues with stability can be in acceptor pool? >> >> Also I have question about updating protocol options: have you done >> something with the problem that after updating protocol options existing >> workers are running with old config? >> >> On Tuesday, December 25, 2012, Lo?c Hoguin wrote: >> >> Ho ho ho! >> >> I have just tagged version 0.6.0 of the Ranch project! >> >> Ranch is a socket acceptor pool for TCP protocols. >> >> https://github.com/extend/__**ranch< >> https://github.com/extend/**ranch > >> >> >> Ranch is used by the next version of Cowboy, 0.8.0, set to be >> released early February, but also in Basho's Riak multi-data center >> replication amongst others. >> >> All tickets have been resolved. A significant contribution was made >> by Andrew Majorov to improve the fault tolerance capabilities of the >> application, making sure it always restarts properly when things go >> wrong. This has been made possible thanks to the amazing project >> from Daniel Luna, chaos_monkey >> (https://github.com/dluna/__**chaos_monkey >> >> >). >> >> >> The guide has also been improved and completed. >> >> http://ninenines.eu/docs/en/__**ranch/HEAD/guide/introduction >> >> >> > >> >> If the guide isn't enough, drop by our new IRC channel dedicated to >> Cowboy, Ranch and all our other projects! #ninenines on Freenode. >> >> Following is the list of change since last time: >> >> * Improve fault tolerance thanks to chaos_monkey testing >> * Add 'nodelay' option to transports >> * Add 'verify' option to ranch_ssl transport >> * Add 'socket' option to pass an already open socket to the >> listener >> * Add Transport:sendfile/2 function (uses a fallback if >> unavailable) >> * Allow IP tuples in Transport:connect/3 >> * Add ranch:set_max_connections/2 to update the value live >> * Add ranch:get_max_connections/1 to retrieve it >> >> We are always looking for feedback, especially now that there is no >> ticket left open on this project. If you are using Ranch and have >> questions or needs that it doesn't cover, please send them to us. >> >> Commercial support will be available starting from January, ping me >> if you are interested. Details will be announced at a later time on >> the ninenines.eu mailing list. >> >> >> I want to thank all contributors for helping this project by opening >> tickets, sending patches and offering feedback. I am as always very >> grateful for any and all contributions. I wouldn't have made it this >> far without the tremendous help I receive everyday. >> >> Thanks to all and have a nice holiday! >> >> -- >> Lo?c Hoguin >> Erlang Santa >> Nine Nines >> http://ninenines.eu >> ______________________________**___________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/__**listinfo/erlang-questions >> >> > >> >> > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Thu Jan 3 14:51:48 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 03 Jan 2013 14:51:48 +0100 Subject: [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition Released In-Reply-To: References: <50D8DA63.2060600@ninenines.eu> <50E57DC0.5090408@ninenines.eu> Message-ID: <50E58CF4.9080804@ninenines.eu> Existing acceptors were using the old options for the next connection and then switched to the new options. But that has been fixed a long time ago. Ranch doesn't have that issue. On 01/03/2013 02:32 PM, Max Lapshin wrote: > I mean situation that after cowboy:update_options existing acceptors are > still working with old routes. > Currently it is useless API, so I have to stop cowboy and start it back. > > > On Thu, Jan 3, 2013 at 4:46 PM, Lo?c Hoguin > wrote: > > Haven't had any stability issue. What we did here is ensure that > when any process gets killed for any reason, especially reasons we > can't foresee, Ranch continues to work as expected. > > Ranch not updating protocol options for existing connections isn't a > problem, it won't be "fixed". Ranch can't guess how connection > processes are implemented. It's up to you to allow this if you need > it. The upgrade updates the options for all acceptors and all future > connections, that's it. > > > On 01/03/2013 10:30 AM, Max Lapshin wrote: > > Loic, it would be great to hear a bit, what problems have you > met with. > > What issues with stability can be in acceptor pool? > > Also I have question about updating protocol options: have you done > something with the problem that after updating protocol options > existing > workers are running with old config? > > On Tuesday, December 25, 2012, Lo?c Hoguin wrote: > > Ho ho ho! > > I have just tagged version 0.6.0 of the Ranch project! > > Ranch is a socket acceptor pool for TCP protocols. > > https://github.com/extend/____ranch > > > > > > Ranch is used by the next version of Cowboy, 0.8.0, set to be > released early February, but also in Basho's Riak > multi-data center > replication amongst others. > > All tickets have been resolved. A significant contribution > was made > by Andrew Majorov to improve the fault tolerance > capabilities of the > application, making sure it always restarts properly when > things go > wrong. This has been made possible thanks to the amazing > project > from Daniel Luna, chaos_monkey > (https://github.com/dluna/____chaos_monkey > > >). > > > The guide has also been improved and completed. > > http://ninenines.eu/docs/en/____ranch/HEAD/guide/introduction > > > > > > > If the guide isn't enough, drop by our new IRC channel > dedicated to > Cowboy, Ranch and all our other projects! #ninenines on > Freenode. > > Following is the list of change since last time: > > * Improve fault tolerance thanks to chaos_monkey testing > * Add 'nodelay' option to transports > * Add 'verify' option to ranch_ssl transport > * Add 'socket' option to pass an already open socket to > the listener > * Add Transport:sendfile/2 function (uses a fallback if > unavailable) > * Allow IP tuples in Transport:connect/3 > * Add ranch:set_max_connections/2 to update the value live > * Add ranch:get_max_connections/1 to retrieve it > > We are always looking for feedback, especially now that > there is no > ticket left open on this project. If you are using Ranch > and have > questions or needs that it doesn't cover, please send them > to us. > > Commercial support will be available starting from January, > ping me > if you are interested. Details will be announced at a later > time on > the ninenines.eu > mailing list. > > > I want to thank all contributors for helping this project > by opening > tickets, sending patches and offering feedback. I am as > always very > grateful for any and all contributions. I wouldn't have > made it this > far without the tremendous help I receive everyday. > > Thanks to all and have a nice holiday! > > -- > Lo?c Hoguin > Erlang Santa > Nine Nines > http://ninenines.eu > ___________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/____listinfo/erlang-questions > > > > > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From max.lapshin@REDACTED Thu Jan 3 15:00:56 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 3 Jan 2013 17:00:56 +0300 Subject: [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition Released In-Reply-To: <50E58CF4.9080804@ninenines.eu> References: <50D8DA63.2060600@ninenines.eu> <50E57DC0.5090408@ninenines.eu> <50E58CF4.9080804@ninenines.eu> Message-ID: ok On Thu, Jan 3, 2013 at 5:51 PM, Lo?c Hoguin wrote: > Existing acceptors were using the old options for the next connection and > then switched to the new options. But that has been fixed a long time ago. > Ranch doesn't have that issue. > > > On 01/03/2013 02:32 PM, Max Lapshin wrote: > >> I mean situation that after cowboy:update_options existing acceptors are >> still working with old routes. >> Currently it is useless API, so I have to stop cowboy and start it back. >> >> >> On Thu, Jan 3, 2013 at 4:46 PM, Lo?c Hoguin > > wrote: >> >> Haven't had any stability issue. What we did here is ensure that >> when any process gets killed for any reason, especially reasons we >> can't foresee, Ranch continues to work as expected. >> >> Ranch not updating protocol options for existing connections isn't a >> problem, it won't be "fixed". Ranch can't guess how connection >> processes are implemented. It's up to you to allow this if you need >> it. The upgrade updates the options for all acceptors and all future >> connections, that's it. >> >> >> On 01/03/2013 10:30 AM, Max Lapshin wrote: >> >> Loic, it would be great to hear a bit, what problems have you >> met with. >> >> What issues with stability can be in acceptor pool? >> >> Also I have question about updating protocol options: have you >> done >> something with the problem that after updating protocol options >> existing >> workers are running with old config? >> >> On Tuesday, December 25, 2012, Lo?c Hoguin wrote: >> >> Ho ho ho! >> >> I have just tagged version 0.6.0 of the Ranch project! >> >> Ranch is a socket acceptor pool for TCP protocols. >> >> https://github.com/extend/____**ranch >> >> > >> >> >> >> >> >> >> >> Ranch is used by the next version of Cowboy, 0.8.0, set to be >> released early February, but also in Basho's Riak >> multi-data center >> replication amongst others. >> >> All tickets have been resolved. A significant contribution >> was made >> by Andrew Majorov to improve the fault tolerance >> capabilities of the >> application, making sure it always restarts properly when >> things go >> wrong. This has been made possible thanks to the amazing >> project >> from Daniel Luna, chaos_monkey >> (https://github.com/dluna/____**chaos_monkey >> >> > >> >> >> >> >>). >> >> >> The guide has also been improved and completed. >> >> http://ninenines.eu/docs/en/__**__ranch/HEAD/guide/**introduction >> >> **> >> >> >> >> >> >> >**> >> >> If the guide isn't enough, drop by our new IRC channel >> dedicated to >> Cowboy, Ranch and all our other projects! #ninenines on >> Freenode. >> >> Following is the list of change since last time: >> >> * Improve fault tolerance thanks to chaos_monkey testing >> * Add 'nodelay' option to transports >> * Add 'verify' option to ranch_ssl transport >> * Add 'socket' option to pass an already open socket to >> the listener >> * Add Transport:sendfile/2 function (uses a fallback if >> unavailable) >> * Allow IP tuples in Transport:connect/3 >> * Add ranch:set_max_connections/2 to update the value live >> * Add ranch:get_max_connections/1 to retrieve it >> >> We are always looking for feedback, especially now that >> there is no >> ticket left open on this project. If you are using Ranch >> and have >> questions or needs that it doesn't cover, please send them >> to us. >> >> Commercial support will be available starting from January, >> ping me >> if you are interested. Details will be announced at a later >> time on >> the ninenines.eu >> mailing list. >> >> >> I want to thank all contributors for helping this project >> by opening >> tickets, sending patches and offering feedback. I am as >> always very >> grateful for any and all contributions. I wouldn't have >> made it this >> far without the tremendous help I receive everyday. >> >> Thanks to all and have a nice holiday! >> >> -- >> Lo?c Hoguin >> Erlang Santa >> Nine Nines >> http://ninenines.eu >> ______________________________**_____________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> > >> http://erlang.org/mailman/____**listinfo/erlang-questions >> >> > >> >> >> >> >> >> >> >> >> -- >> Lo?c Hoguin >> Erlang Cowboy >> Nine Nines >> http://ninenines.eu >> >> >> > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Thu Jan 3 15:03:48 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 03 Jan 2013 15:03:48 +0100 Subject: [erlang-questions] Unicorn-style load balancing in Erlang? In-Reply-To: References: <50E4D9E4.70701@ninenines.eu> Message-ID: <50E58FC4.5030109@ninenines.eu> In Erlang it makes no difference on a running system. It's slightly better for 1 concurrent connection, not so much for 1000. It's probably also good for processes that do not use receive and are short enough to not get rescheduled. But otherwise there's no guarantee that this or another method will be faster to reply because you can't stop your process from being rescheduled. The more processes you have, the more it evens out, and the more these kind of "optimizations" become worthless. What this approach does though is share the same supervisor for connections and acceptors, which means that if the listening socket gets closed and the supervisor dies, all your connections get dropped. Not so great fault tolerance. On 01/03/2013 04:52 AM, Xiao Jia wrote: > Oh I see. The way swarm works is the same as Unicorn in the sense that > the acceptor and worker is combined. > > But they are a bit different because swarm can accept a new socket in > parallel with the processing of the accepted socket, while Unicorn > only accepts after the accepted socket is processed. So Unicorn has > better control of the number of processes (well it's prefork by > nature) but requests have to be *fast*. > > I prefer the swarm style since it's ideal for both fast and slow > requests. Thanks, that's a great work :-) > > On Thu, Jan 3, 2013 at 9:07 AM, Lo?c Hoguin wrote: >> I believe from the README that swarm creates processes that accept and then >> become workers as you mentioned. >> >> >> On 01/03/2013 01:53 AM, Xiao Jia wrote: >>> >>> Thanks for your reply. >>> >>> I have used ranch before, and I think Unicorn is more than an acceptor >>> pool. In ranch, acceptor processes only do "accept", and then dispatch >>> the request to some worker process. I believe swarm works the same way >>> as a middleman. >>> >>> In Unicorn, there's no separate worker (or acceptor) process; a >>> prefork process is both acceptor and worker. All the prefork processes >>> start out by calling "accept()" on the same listener socket. Then it's >>> the OS kernel who determines which "accept()" to awake, while others >>> remain sleeping. >>> >>> From the documentation of ranch: >>>> >>>> Our observations suggest that using 100 acceptors >>>> on modern hardware is a good solution, as it's big >>>> enough to always have acceptors ready and it's low >>>> enough that it doesn't have a negative impact on >>>> the system's performances. >>> >>> >>> What if there's no separate worker process? Will many number of >>> acceptor-and-workers have a negative impact as well? >>> >>> On Thu, Jan 3, 2013 at 5:25 AM, Daniel Goertzen >>> wrote: >>>> >>>> For bare acceptor pool libraries, take a look at... >>>> >>>> https://github.com/extend/ranch >>>> https://github.com/jeremey/swarm >>>> >>>> And I would bet that most significant socket server apps written in >>>> Erlang >>>> would use acceptor pooling of some sort. >>>> >>>> Dan. >>>> >>>> On Wed, Jan 2, 2013 at 10:09 AM, Xiao Jia wrote: >>>>> >>>>> >>>>> From http://www.erlang.org/doc/man/gen_tcp.html#accept-1: >>>>> >>>>>> It is worth noting that the accept call does not have to be issued >>>>>> from the socket owner process. Using version 5.5.3 and higher of >>>>>> the emulator, multiple simultaneous accept calls can be issued >>>>>> from different processes, which allows for a pool of acceptor >>>>>> processes handling incoming connections. >>>>> >>>>> >>>>> Does it mean that we can have Unicorn-style load balancing in Erlang? >>>>> If so, are there any existing servers or libraries making use of this >>>>> feature? >>>>> >>>>> For those who are not familiar with Unicorn [1], it is a traditional >>>>> UNIX prefork web server. Load balancing between worker processes is >>>>> done by the OS kernel. All workers share a common set of listener >>>>> sockets and does non-blocking accept() on them. The kernel will decide >>>>> which worker process to give a socket to and workers will sleep if >>>>> there is nothing to accept(). >>>>> >>>>> btw, I also posted this question on StackOverflow [2] but no active >>>>> responses there :-( >>>>> >>>>> [1]: http://unicorn.bogomips.org/ >>>>> [2]: >>>>> >>>>> http://stackoverflow.com/questions/14121987/unicorn-style-load-balancing-in-erlang >>>>> >>>>> --- >>>>> Regards, >>>>> Xiao Jia >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> 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 >> Erlang Cowboy >> Nine Nines >> http://ninenines.eu -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From daniel@REDACTED Thu Jan 3 16:20:55 2013 From: daniel@REDACTED (Daniel Luna) Date: Thu, 3 Jan 2013 10:20:55 -0500 Subject: [erlang-questions] Special Characters problem In-Reply-To: References: Message-ID: On 2 January 2013 06:35, Vlad Dumitrescu wrote: > On Wed, Jan 2, 2013 at 12:26 PM, Evren Bayraktar wrote: >> lists:flatten(io_lib:format("from=~s&to=~s&message=~s&status=~b&time_create=~b", >> [FromS, ToS, BodyS, Status, unix_timestamp() > > > I would guess that the message's body (and maybe even the other strings) > should be escaped or quoted (by using ~w instead of ~s), probably the parser > for the resulting string can't handle the spaces and the '>'. > > You should in any case sanitize the input, otherwise you will have problems > with code injection, imagine a message saying > "Hello&status=closed&time_create=..." (or worse). Exactly what Vlad is saying. The correct solution is: io_lib:format("from=~s&to=~s&message=~s&status=~b&time_create=~b", [url_encode(FromS), url_encode(ToS), url_encode(BodyS), Status, unix_timestamp()]) and FYI, in most cases you don't have to flatten the resulting list from io_lib:format. If you are writing the data to a port or a file, the driver will take care of that in a more efficient way. Cheers, Daniel From kajan26@REDACTED Thu Jan 3 18:22:47 2013 From: kajan26@REDACTED (Varatharaja Kajamugan) Date: Thu, 3 Jan 2013 22:52:47 +0530 Subject: [erlang-questions] Erlang application distribution Message-ID: Hi, I have tested a distributed test application between 2 nodes (test_p and test_s). test_p is primary node and test_s is secondary. When i stop test_p node, start(failover, Args) was called in test_s node. But when i stop only the test application in test_p node without stopping the node, start(failover, Args) was not called in test_s node. is that the behavior of erlang kernel distribution. if not can u guys please help me on this. my kernel configuration is below : {kernel, [{distributed, [ {reduce_test, 5000, [test_p@REDACTED, test_s@REDACTED]} ]}, {sync_nodes_optional, [test_p@REDACTED, test_s@REDACTED]}, {sync_nodes_timeout, 5000}, {start_dist_ac, true} ]} Thanks Kajan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From k.petrauskas@REDACTED Thu Jan 3 18:49:23 2013 From: k.petrauskas@REDACTED (Karolis Petrauskas) Date: Thu, 3 Jan 2013 19:49:23 +0200 Subject: [erlang-questions] Accessing sibling processes in a supervisor. In-Reply-To: References: Message-ID: Hello, I ended up by using gproc as a process registry instead of maintaining sibling pids manually. That simplified my application notably. I found it very convenient to use gproc with the standard behaviours using the process name in form of {via,gproc,{n, l, {?MODULE, Key}}}, where Key is known for all the related processes. In my case the related processes receive the Key from the supervisor as a initialization argument. Thank you all for the comments, Karolis On Fri, Dec 21, 2012 at 3:49 AM, ???? ????? ??? ? wrote: > > Karolis - > > I'd recommend to study gproc (https://github.com/uwiger/gproc) and in particular it's process registry features. Worker processes and/or other processes can query the set of active processes using gproc:first/1, gproc:next/2, gproc:select/{1,2}, etc. > > For example, a worker process could register themselves with a key such as {?MODULE, self()}. If worker processes have a unique identifier, a worker process could register themselves with a key such as {?MODULE, Id::term()} where term() is an unique identifier. > > Hope this helps. > > Joe N. > > On Dec 21, 2012, at 10:24 , Karolis Petrauskas wrote: > >> Hi, >> >> I have a question regarding an example [1] in LYSE. The example >> proposes a supervision scheme for a server-worker like processes. I >> have used this scheme a lot (I learnt Erlang from this book mainly), >> but now I'm in doubt. Is the proposed way of accessing a sibling >> process (access worker_sup from ppool_serv, see [1]) is the correct >> one? How will the ppool_serv get a PID of the worker_sup after a crash >> and restart? As I understand, if one of the processes will crash, both >> processes will be restarted and the server should get an error while >> starting the worker_sup again (the corresponding child already >> exists): >> >> handle_info({start_worker_supervisor, Sup, MFA}, S = #state{}) -> >> {ok, Pid} = supervisor:start_child(Sup, ?SPEC(MFA)), % >> Will this work after restart? >> >> Or maybe I missed the point? I am aware of some other ways of getting >> processes to know each other [2], but I would like to get your >> comments on this example. Other schemes for implementing communication >> of anonymous sibling processes (in the supervision tree) would be >> interesting also. >> >> [1] http://learnyousomeerlang.com/building-applications-with-otp#implementing-the-supervisors >> [2] http://erlang.2086793.n4.nabble.com/supervisor-children-s-pid-td3530959.html#a3531973 >> >> Best regards, >> Karolis Petrauskas >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > From erlang@REDACTED Thu Jan 3 19:23:39 2013 From: erlang@REDACTED (=?UTF-8?Q?Micha=C5=82_Ptaszek?=) Date: Thu, 3 Jan 2013 19:23:39 +0100 Subject: [erlang-questions] Including erl_call in the release tarball Message-ID: Hey, I'm running my system in the embedded mode, and trying to apply live upgrades using release_handler. Nonetheless, in order to automate the process, I would like to interface with the running Erlang node via 'erl_call' command and pass the release_handler instructions as arguments (I would love to avoid writing escripts or playing with 'erl -eval "rpc:call(...)"' mumbo-jumbo). Unfortunately, it seems like erl_call is not included in the release package generated by rebar, and to make things worse - is not even put in the standard erlang bin/ directory. Instead, by default, it's located under $ERL_ROOT/lib/erlang/lib/erl_interface-$VERSION/bin/erl_call. Also, trying to add erl_interface application to the released apps does not work, as erl_interface is not an OTP application (does not have .app file). What would be the best way to make sure that the target release package contains erl_call binary? How do you usually make it accessible/available on the target system? Thanks, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Thu Jan 3 22:15:07 2013 From: ulf@REDACTED (Ulf Wiger) Date: Thu, 3 Jan 2013 22:15:07 +0100 Subject: [erlang-questions] Including erl_call in the release tarball In-Reply-To: References: Message-ID: Hi Michal, Not sure if it helps, but here is a first draft of an escript that works roughly like erl_call. https://gist.github.com/4447248 I've had great difficulty getting the Distributed Erlang bootstrap to work nicely on MacOS (haven't tried it elsewhere). Thus, the quirky method of deleting the net_sup child and re-adding it with specified arguments (also, the call to inet_db:set_hostname/1 is absolutely necessary on my machine - I can't explain why). Some of the issues I've run into: - When calling net_kernel:start(?) from within an escript, the host name is apparently determined differently from when a %%! line with a node name is given at the top of the escript. For it to work on my laptop, I have to give a fully qualified name, which the script then splits and uses for set_hostname. - The times I was able to make it work at all with net_kernel:start(), connection took forever. After replacing it with the delete_child/start_child gymnastics, this problem went away. Anyway, if it helps anyone, have at it. OTP team - this shouldn't be so hard. Perhaps someone could take a look at the issues? BR, Ulf W On 3 Jan 2013, at 19:23, Micha? Ptaszek wrote: > Hey, > > I'm running my system in the embedded mode, and trying to apply live upgrades using release_handler. Nonetheless, in order to automate the process, I would like to interface with the running Erlang node via 'erl_call' command and pass the release_handler instructions as arguments (I would love to avoid writing escripts or playing with 'erl -eval "rpc:call(...)"' mumbo-jumbo). > > Unfortunately, it seems like erl_call is not included in the release package generated by rebar, and to make things worse - is not even put in the standard erlang bin/ directory. Instead, by default, it's located under $ERL_ROOT/lib/erlang/lib/erl_interface-$VERSION/bin/erl_call. > > Also, trying to add erl_interface application to the released apps does not work, as erl_interface is not an OTP application (does not have .app file). > > What would be the best way to make sure that the target release package contains erl_call binary? How do you usually make it accessible/available on the target system? > > Thanks, > Michal > _______________________________________________ > 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 surferjeff@REDACTED Fri Jan 4 00:49:18 2013 From: surferjeff@REDACTED (Jeffrey Rennie) Date: Thu, 3 Jan 2013 15:49:18 -0800 Subject: [erlang-questions] open_port returns enoent even when driver init function executes correctly. In-Reply-To: References: <008a01cde962$13dfe700$3b9fb500$@com> Message-ID: <009001cdea0c$f304fd30$d90ef790$@com> I tried with sasl, but it gives me no more info: ... =PROGRESS REPORT==== 3-Jan-2013::15:48:34 === supervisor: {local,sasl_sup} started: [{pid,<0.36.0>}, {name,release_handler}, {mfargs,{release_handler,start_link,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] =PROGRESS REPORT==== 3-Jan-2013::15:48:34 === application: sasl started_at: nonode@REDACTED =ERROR REPORT==== 3-Jan-2013::15:48:35 === Error in process <0.40.0> with exit value: {enoent,[{erlang,open_port,[{spawn,"example_drv"},[]],[]},{complex5,init,1,[{file,"c:/Users/jeff/code/code/port_driver/complex5.erl"},{line,19}]}]} From: Robert Raschke [mailto:rtrlists@REDACTED] Sent: Thursday, January 03, 2013 12:37 AM To: SurferJeff Cc: erlang-questions@REDACTED; erlang-programming@REDACTED Subject: Re: [erlang-questions] open_port returns enoent even when driver init function executes correctly. You can try running erl.exe with sasl enabled to get better error messages. The messages you see at the moment are coming out interleaved, like in the old joke "When faced with a problem you decide to use threading, ..." :-) Robby On Jan 3, 2013 4:53 AM, "SurferJeff" wrote: I found the recipe to build debug: $ cd $ERL_TOP $ rm bin/win32/erlexec.dll $ cd erts/emulator $ make debug $ cd ../etc $ make debug And it succeeded. However, the next command in the recipe fails: jeff@REDACTED /cygdrive/c/Users/jeff/GitHub/otp $ make local_setup make[1]: Entering directory `/cygdrive/c/Users/jeff/GitHub/otp/erts' make[2]: Entering directory `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_script s' make[2]: Nothing to be done for `debug'. make[2]: Leaving directory `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_scripts ' ct_run.exe dialyzer.exe erl.ini erl_crash.dump escript.exe run_test.exe typer.ex e werl.exe win32 make[2]: Entering directory `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_script s' /usr/bin/install -c -d /cygdrive/c/users/jeff/github/otp/erts/start_scripts/tmp ( cd /cygdrive/c/users/jeff/github/otp/erts/start_scripts/tmp && \ erlc -W -I/cygdrive/c/users/jeff/github/otp/lib/kernel/ebin -I/cygdrive/c/use rs/jeff/github/otp/lib/stdlib/ebin -I/cygdrive/c/users/jeff/github/otp/lib/sasl/ ebin +no_warn_sasl +otp_build -o /cygdrive/c/users/jeff/github/otp/bin/start.scr ipt /cygdrive/c/users/jeff/github/otp/erts/start_scripts/start_clean.rel ) File not found: "c:/cygdrive/c/users/jeff/github/otp/erts/start_scripts/start_cl ean.rel" Makefile:129: recipe for target `/cygdrive/c/users/jeff/github/otp/bin/start.scr ipt' failed make[2]: *** [/cygdrive/c/users/jeff/github/otp/bin/start.script] Error 1 make[2]: Leaving directory `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_scripts ' Makefile:69: recipe for target `local_setup' failed make[1]: *** [local_setup] Error 2 make[1]: Leaving directory `/cygdrive/c/Users/jeff/GitHub/otp/erts' Makefile:883: recipe for target `local_setup' failed make: *** [local_setup] Error 2 And now my erl.exe is completely hosed: jeff@REDACTED /cygdrive/c/Users/jeff/GitHub/otp/bin/win32 $ ./erl.exe {(no error logger present"i)n ietr rtoerr: m"iEnrartoirn gi ni np rdooc_ebsoost "<,0{.b2a.d0a>r wgi,t[h{ eerxli_tp rviaml_uleo:a d{ebra,dcahregc,k[_{feirlle__pr reismu_llto,a3d,e[r{,fcihleec,k"_efrill_ep_rriems_ullota,d3er,[.{efrill"e},,\{"l eirnle_,p28r3i}m]_}l,o{aidneirt.,egrelt\_"b}o,o{tl,i1n,e[,{2f8i3l}e,]"}i,n{iitn. ite,rgle"t},_{bloionte,,178,5[}{]f}i,l{ei,n\i"ti,ngiett._ebrolo\t",}2,,{[l{ifnie l,e7,8"5i}n]i}t,.{eirnli"t},,g{elti_nbeo,o77t2,}2]},,[{{ifniilte,,d\o"_ibnoiott. ,e3r,l[\{"f}i,l{el,i"nien,i7t7.2e}r]l}",}{,i{nliitn,ed,o73_9b}o]o}t],}3}, [{file,\"init.erl\"},{line,739}]}]}\n" Crash dump was written to: erl_crash.dump init terminating in do_boot () On Wednesday, January 2, 2013 7:26:09 PM UTC-8, SurferJeff wrote: I'm working through the example here: http://www.erlang.org/doc/tutorial/c_portdriver.html And I'm trying to get it to run on Windows. I reordered the code in the C source so that it compiles, and added a module.def file so that erlang actually finds and executes the driver init function. I attached a debugger. Walking back up the stack, I observe that: The driver init function returns correctly. erts_sys_ddll_call_init() returns correctly. do_load_driver_entry() returns ERL_DE_NO_ERROR. load_driver_entry() returns ERL_DE_NO_ERROR. erl_ddll_try_load_3 returns t = TUPLE2(hp, am_ok, ok_term); on line 417 of erl_bif_ddl.c. But the next higher call on the stack is _process_main(), which was compiled with gcc and has no debug symbols so I can't step through and figure out why the end result is: =ERROR REPORT==== 2-Jan-2013::19:14:22 === Error in process <0.31.0> with exit value: {enoent,[{erlang,open_port,[{spawn,"example_drv"},[]],[]},{complex5,init,1,[ {file,"c:/Users/jeff/code/code/port_driver/complex5.erl"},{line,19}]}]} Has anyone seen this before? If not, how do I recompile erl.exe purely with cl.exe (no gcc) so that it generates debug symbols? And while I'm recompiling, how do I turn off all optimizations? I can read basic make files, but I get lost in the configure scripts and .in and .mk files. Please take pity on a Windows programmer ;-) _______________________________________________ erlang-questions mailing list 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 surferjeff@REDACTED Fri Jan 4 01:02:37 2013 From: surferjeff@REDACTED (Jeffrey Rennie) Date: Thu, 3 Jan 2013 16:02:37 -0800 Subject: [erlang-questions] open_port returns enoent even when driver init function executes correctly. In-Reply-To: References: <008a01cde962$13dfe700$3b9fb500$@com> Message-ID: <009c01cdea0e$ced66050$6c8320f0$@com> I tried hacking the Makefile to force compiling beam_emu.c with cl.exe, but it appears that beam_emu.c hasn't been ported to work with cl.exe: C:\Users\jeff\GitHub\otp\erts\emulator>bash c:/Users/jeff/GitHub/otp/erts/etc/wi n32/cygwin_tools/vc/cc.sh -O3 -I/cygdrive/c/Users/jeff/GitHub/otp/erts/win32 -D_WIN32_WINNT=0x0500 -DWINVER=0x0500 -DERTS_MIXED_CYGWIN_VC -DSTATIC_ERLANG_DR IVER -DERTS_SMP -DHAVE_CONFIG_H -DUSE_THREADS -DWIN32_THREADS -Iwin32/opt/smp -Ibeam -Isys/win32 -Isys/common -Iwin32 -Izlib -Ipcre -Ihipe -I../include -I../ include/win32 -I../include/internal -I../include/internal/win32 -c beam/beam_emu .c -o obj/win32/opt/smp/beam_emu.o TAIL: lseeki64() failed 9 Wow, getting the simplest .dll driver to load on Windows is brutally difficult. Has anyone successfully loaded a .dll driver on Windows? Could you send me the most primitive skeleton that works? Alternatively, I've attached my source files for inspection. Sincerely, Jeffrey Rennie From: Robert Raschke [mailto:rtrlists@REDACTED] Sent: Thursday, January 03, 2013 12:37 AM To: SurferJeff Cc: erlang-questions@REDACTED; erlang-programming@REDACTED Subject: Re: [erlang-questions] open_port returns enoent even when driver init function executes correctly. You can try running erl.exe with sasl enabled to get better error messages. The messages you see at the moment are coming out interleaved, like in the old joke "When faced with a problem you decide to use threading, ..." :-) Robby On Jan 3, 2013 4:53 AM, "SurferJeff" wrote: I found the recipe to build debug: $ cd $ERL_TOP $ rm bin/win32/erlexec.dll $ cd erts/emulator $ make debug $ cd ../etc $ make debug And it succeeded. However, the next command in the recipe fails: jeff@REDACTED /cygdrive/c/Users/jeff/GitHub/otp $ make local_setup make[1]: Entering directory `/cygdrive/c/Users/jeff/GitHub/otp/erts' make[2]: Entering directory `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_script s' make[2]: Nothing to be done for `debug'. make[2]: Leaving directory `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_scripts ' ct_run.exe dialyzer.exe erl.ini erl_crash.dump escript.exe run_test.exe typer.ex e werl.exe win32 make[2]: Entering directory `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_script s' /usr/bin/install -c -d /cygdrive/c/users/jeff/github/otp/erts/start_scripts/tmp ( cd /cygdrive/c/users/jeff/github/otp/erts/start_scripts/tmp && \ erlc -W -I/cygdrive/c/users/jeff/github/otp/lib/kernel/ebin -I/cygdrive/c/use rs/jeff/github/otp/lib/stdlib/ebin -I/cygdrive/c/users/jeff/github/otp/lib/sasl/ ebin +no_warn_sasl +otp_build -o /cygdrive/c/users/jeff/github/otp/bin/start.scr ipt /cygdrive/c/users/jeff/github/otp/erts/start_scripts/start_clean.rel ) File not found: "c:/cygdrive/c/users/jeff/github/otp/erts/start_scripts/start_cl ean.rel" Makefile:129: recipe for target `/cygdrive/c/users/jeff/github/otp/bin/start.scr ipt' failed make[2]: *** [/cygdrive/c/users/jeff/github/otp/bin/start.script] Error 1 make[2]: Leaving directory `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_scripts ' Makefile:69: recipe for target `local_setup' failed make[1]: *** [local_setup] Error 2 make[1]: Leaving directory `/cygdrive/c/Users/jeff/GitHub/otp/erts' Makefile:883: recipe for target `local_setup' failed make: *** [local_setup] Error 2 And now my erl.exe is completely hosed: jeff@REDACTED /cygdrive/c/Users/jeff/GitHub/otp/bin/win32 $ ./erl.exe {(no error logger present"i)n ietr rtoerr: m"iEnrartoirn gi ni np rdooc_ebsoost "<,0{.b2a.d0a>r wgi,t[h{ eerxli_tp rviaml_uleo:a d{ebra,dcahregc,k[_{feirlle__pr reismu_llto,a3d,e[r{,fcihleec,k"_efrill_ep_rriems_ullota,d3er,[.{efrill"e},,\{"l eirnle_,p28r3i}m]_}l,o{aidneirt.,egrelt\_"b}o,o{tl,i1n,e[,{2f8i3l}e,]"}i,n{iitn. ite,rgle"t},_{bloionte,,178,5[}{]f}i,l{ei,n\i"ti,ngiett._ebrolo\t",}2,,{[l{ifnie l,e7,8"5i}n]i}t,.{eirnli"t},,g{elti_nbeo,o77t2,}2]},,[{{ifniilte,,d\o"_ibnoiott. ,e3r,l[\{"f}i,l{el,i"nien,i7t7.2e}r]l}",}{,i{nliitn,ed,o73_9b}o]o}t],}3}, [{file,\"init.erl\"},{line,739}]}]}\n" Crash dump was written to: erl_crash.dump init terminating in do_boot () On Wednesday, January 2, 2013 7:26:09 PM UTC-8, SurferJeff wrote: I'm working through the example here: http://www.erlang.org/doc/tutorial/c_portdriver.html And I'm trying to get it to run on Windows. I reordered the code in the C source so that it compiles, and added a module.def file so that erlang actually finds and executes the driver init function. I attached a debugger. Walking back up the stack, I observe that: The driver init function returns correctly. erts_sys_ddll_call_init() returns correctly. do_load_driver_entry() returns ERL_DE_NO_ERROR. load_driver_entry() returns ERL_DE_NO_ERROR. erl_ddll_try_load_3 returns t = TUPLE2(hp, am_ok, ok_term); on line 417 of erl_bif_ddl.c. But the next higher call on the stack is _process_main(), which was compiled with gcc and has no debug symbols so I can't step through and figure out why the end result is: =ERROR REPORT==== 2-Jan-2013::19:14:22 === Error in process <0.31.0> with exit value: {enoent,[{erlang,open_port,[{spawn,"example_drv"},[]],[]},{complex5,init,1,[ {file,"c:/Users/jeff/code/code/port_driver/complex5.erl"},{line,19}]}]} Has anyone seen this before? If not, how do I recompile erl.exe purely with cl.exe (no gcc) so that it generates debug symbols? And while I'm recompiling, how do I turn off all optimizations? I can read basic make files, but I get lost in the configure scripts and .in and .mk files. Please take pity on a Windows programmer ;-) _______________________________________________ erlang-questions mailing list 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: complex5.erl Type: application/octet-stream Size: 1175 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: module.def URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: port_driver.cpp URL: From surferjeff@REDACTED Fri Jan 4 01:26:11 2013 From: surferjeff@REDACTED (Jeffrey Rennie) Date: Thu, 3 Jan 2013 16:26:11 -0800 Subject: [erlang-questions] open_port returns enoent even when driver init function executes correctly. References: <008a01cde962$13dfe700$3b9fb500$@com> Message-ID: <00a201cdea12$19be8680$4d3b9380$@com> I found dummy_drv.c in the emulator/test directory. So I tried making tests. After about 100 lines of warnings, it failed with this error: Recompile: old_mod old_mod.erl:25: can't find include file "test_server.hrl" old_mod.erl:32: undefined macro 'line' old_mod.erl:23: function sort_on_old_node/1 undefined From: Jeffrey Rennie [mailto:surferjeff@REDACTED] Sent: Thursday, January 03, 2013 4:03 PM To: 'erlang-questions@REDACTED' Subject: RE: [erlang-questions] open_port returns enoent even when driver init function executes correctly. I tried hacking the Makefile to force compiling beam_emu.c with cl.exe, but it appears that beam_emu.c hasn't been ported to work with cl.exe: C:\Users\jeff\GitHub\otp\erts\emulator>bash c:/Users/jeff/GitHub/otp/erts/etc/wi n32/cygwin_tools/vc/cc.sh -O3 -I/cygdrive/c/Users/jeff/GitHub/otp/erts/win32 -D_WIN32_WINNT=0x0500 -DWINVER=0x0500 -DERTS_MIXED_CYGWIN_VC -DSTATIC_ERLANG_DR IVER -DERTS_SMP -DHAVE_CONFIG_H -DUSE_THREADS -DWIN32_THREADS -Iwin32/opt/smp -Ibeam -Isys/win32 -Isys/common -Iwin32 -Izlib -Ipcre -Ihipe -I../include -I../ include/win32 -I../include/internal -I../include/internal/win32 -c beam/beam_emu .c -o obj/win32/opt/smp/beam_emu.o TAIL: lseeki64() failed 9 Wow, getting the simplest .dll driver to load on Windows is brutally difficult. Has anyone successfully loaded a .dll driver on Windows? Could you send me the most primitive skeleton that works? Alternatively, I've attached my source files for inspection. Sincerely, Jeffrey Rennie From: Robert Raschke [mailto:rtrlists@REDACTED] Sent: Thursday, January 03, 2013 12:37 AM To: SurferJeff Cc: erlang-questions@REDACTED; erlang-programming@REDACTED Subject: Re: [erlang-questions] open_port returns enoent even when driver init function executes correctly. You can try running erl.exe with sasl enabled to get better error messages. The messages you see at the moment are coming out interleaved, like in the old joke "When faced with a problem you decide to use threading, ..." :-) Robby On Jan 3, 2013 4:53 AM, "SurferJeff" wrote: I found the recipe to build debug: $ cd $ERL_TOP $ rm bin/win32/erlexec.dll $ cd erts/emulator $ make debug $ cd ../etc $ make debug And it succeeded. However, the next command in the recipe fails: jeff@REDACTED /cygdrive/c/Users/jeff/GitHub/otp $ make local_setup make[1]: Entering directory `/cygdrive/c/Users/jeff/GitHub/otp/erts' make[2]: Entering directory `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_script s' make[2]: Nothing to be done for `debug'. make[2]: Leaving directory `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_scripts ' ct_run.exe dialyzer.exe erl.ini erl_crash.dump escript.exe run_test.exe typer.ex e werl.exe win32 make[2]: Entering directory `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_script s' /usr/bin/install -c -d /cygdrive/c/users/jeff/github/otp/erts/start_scripts/tmp ( cd /cygdrive/c/users/jeff/github/otp/erts/start_scripts/tmp && \ erlc -W -I/cygdrive/c/users/jeff/github/otp/lib/kernel/ebin -I/cygdrive/c/use rs/jeff/github/otp/lib/stdlib/ebin -I/cygdrive/c/users/jeff/github/otp/lib/sasl/ ebin +no_warn_sasl +otp_build -o /cygdrive/c/users/jeff/github/otp/bin/start.scr ipt /cygdrive/c/users/jeff/github/otp/erts/start_scripts/start_clean.rel ) File not found: "c:/cygdrive/c/users/jeff/github/otp/erts/start_scripts/start_cl ean.rel" Makefile:129: recipe for target `/cygdrive/c/users/jeff/github/otp/bin/start.scr ipt' failed make[2]: *** [/cygdrive/c/users/jeff/github/otp/bin/start.script] Error 1 make[2]: Leaving directory `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_scripts ' Makefile:69: recipe for target `local_setup' failed make[1]: *** [local_setup] Error 2 make[1]: Leaving directory `/cygdrive/c/Users/jeff/GitHub/otp/erts' Makefile:883: recipe for target `local_setup' failed make: *** [local_setup] Error 2 And now my erl.exe is completely hosed: jeff@REDACTED /cygdrive/c/Users/jeff/GitHub/otp/bin/win32 $ ./erl.exe {(no error logger present"i)n ietr rtoerr: m"iEnrartoirn gi ni np rdooc_ebsoost "<,0{.b2a.d0a>r wgi,t[h{ eerxli_tp rviaml_uleo:a d{ebra,dcahregc,k[_{feirlle__pr reismu_llto,a3d,e[r{,fcihleec,k"_efrill_ep_rriems_ullota,d3er,[.{efrill"e},,\{"l eirnle_,p28r3i}m]_}l,o{aidneirt.,egrelt\_"b}o,o{tl,i1n,e[,{2f8i3l}e,]"}i,n{iitn. ite,rgle"t},_{bloionte,,178,5[}{]f}i,l{ei,n\i"ti,ngiett._ebrolo\t",}2,,{[l{ifnie l,e7,8"5i}n]i}t,.{eirnli"t},,g{elti_nbeo,o77t2,}2]},,[{{ifniilte,,d\o"_ibnoiott. ,e3r,l[\{"f}i,l{el,i"nien,i7t7.2e}r]l}",}{,i{nliitn,ed,o73_9b}o]o}t],}3}, [{file,\"init.erl\"},{line,739}]}]}\n" Crash dump was written to: erl_crash.dump init terminating in do_boot () On Wednesday, January 2, 2013 7:26:09 PM UTC-8, SurferJeff wrote: I'm working through the example here: http://www.erlang.org/doc/tutorial/c_portdriver.html And I'm trying to get it to run on Windows. I reordered the code in the C source so that it compiles, and added a module.def file so that erlang actually finds and executes the driver init function. I attached a debugger. Walking back up the stack, I observe that: The driver init function returns correctly. erts_sys_ddll_call_init() returns correctly. do_load_driver_entry() returns ERL_DE_NO_ERROR. load_driver_entry() returns ERL_DE_NO_ERROR. erl_ddll_try_load_3 returns t = TUPLE2(hp, am_ok, ok_term); on line 417 of erl_bif_ddl.c. But the next higher call on the stack is _process_main(), which was compiled with gcc and has no debug symbols so I can't step through and figure out why the end result is: =ERROR REPORT==== 2-Jan-2013::19:14:22 === Error in process <0.31.0> with exit value: {enoent,[{erlang,open_port,[{spawn,"example_drv"},[]],[]},{complex5,init,1,[ {file,"c:/Users/jeff/code/code/port_driver/complex5.erl"},{line,19}]}]} Has anyone seen this before? If not, how do I recompile erl.exe purely with cl.exe (no gcc) so that it generates debug symbols? And while I'm recompiling, how do I turn off all optimizations? I can read basic make files, but I get lost in the configure scripts and .in and .mk files. Please take pity on a Windows programmer ;-) _______________________________________________ erlang-questions mailing list 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 surferjeff@REDACTED Fri Jan 4 04:18:30 2013 From: surferjeff@REDACTED (Jeffrey Rennie) Date: Thu, 3 Jan 2013 19:18:30 -0800 Subject: [erlang-questions] open_port returns enoent even when driver init function executes correctly. In-Reply-To: References: <008a01cde962$13dfe700$3b9fb500$@com> Message-ID: <00b601cdea2a$2c538710$84fa9530$@com> Here's the first real clue. The example driver is being unloaded before it's invoked! See below for the call stack of the unload. This must be either a bug in the documentation at http://www.erlang.org/doc/tutorial/c_portdriver.html or a bug in the erlang itself. What's the process for filing a bug? 0439f644 517572e2 example_drv!example_drv_finish(void)+0x1e [c:\users\jeff\code\code\port_driver\port_driver.cpp @ 64] 0439f654 51757729 beam_smp!do_unload_driver_entry(struct DE_Handle * dh = 0x00000000, unsigned long * save_name = 0x00000000)+0x72 [c:\users\jeff\github\otp\erts\emulator\beam\erl_bif_ddll.c @ 1655] 0439f680 51797c2b beam_smp!ddll_no_more_references(void * vdh = 0x517576d0)+0x59 [c:\users\jeff\github\otp\erts\emulator\beam\erl_bif_ddll.c @ 1221] 0439f69c 5179b89f beam_smp!exec_misc_ops(struct ErtsRunQueue_ * rq = 0x518c3b8c)+0x7b [c:\users\jeff\github\otp\erts\emulator\beam\erl_process.c @ 7231] 0439f6c8 51801be7 beam_smp!schedule(struct process * p = 0x00000002, int calls = 0)+0x5df [c:\users\jeff\github\otp\erts\emulator\beam\erl_process.c @ 6891] 0439f6fc 7714c7c5 beam_smp!process_main+0x167 From: Robert Raschke [mailto:rtrlists@REDACTED] Sent: Thursday, January 03, 2013 12:37 AM To: SurferJeff Cc: erlang-questions@REDACTED; erlang-programming@REDACTED Subject: Re: [erlang-questions] open_port returns enoent even when driver init function executes correctly. You can try running erl.exe with sasl enabled to get better error messages. The messages you see at the moment are coming out interleaved, like in the old joke "When faced with a problem you decide to use threading, ..." :-) Robby On Jan 3, 2013 4:53 AM, "SurferJeff" wrote: I found the recipe to build debug: $ cd $ERL_TOP $ rm bin/win32/erlexec.dll $ cd erts/emulator $ make debug $ cd ../etc $ make debug And it succeeded. However, the next command in the recipe fails: jeff@REDACTED /cygdrive/c/Users/jeff/GitHub/otp $ make local_setup make[1]: Entering directory `/cygdrive/c/Users/jeff/GitHub/otp/erts' make[2]: Entering directory `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_script s' make[2]: Nothing to be done for `debug'. make[2]: Leaving directory `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_scripts ' ct_run.exe dialyzer.exe erl.ini erl_crash.dump escript.exe run_test.exe typer.ex e werl.exe win32 make[2]: Entering directory `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_script s' /usr/bin/install -c -d /cygdrive/c/users/jeff/github/otp/erts/start_scripts/tmp ( cd /cygdrive/c/users/jeff/github/otp/erts/start_scripts/tmp && \ erlc -W -I/cygdrive/c/users/jeff/github/otp/lib/kernel/ebin -I/cygdrive/c/use rs/jeff/github/otp/lib/stdlib/ebin -I/cygdrive/c/users/jeff/github/otp/lib/sasl/ ebin +no_warn_sasl +otp_build -o /cygdrive/c/users/jeff/github/otp/bin/start.scr ipt /cygdrive/c/users/jeff/github/otp/erts/start_scripts/start_clean.rel ) File not found: "c:/cygdrive/c/users/jeff/github/otp/erts/start_scripts/start_cl ean.rel" Makefile:129: recipe for target `/cygdrive/c/users/jeff/github/otp/bin/start.scr ipt' failed make[2]: *** [/cygdrive/c/users/jeff/github/otp/bin/start.script] Error 1 make[2]: Leaving directory `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_scripts ' Makefile:69: recipe for target `local_setup' failed make[1]: *** [local_setup] Error 2 make[1]: Leaving directory `/cygdrive/c/Users/jeff/GitHub/otp/erts' Makefile:883: recipe for target `local_setup' failed make: *** [local_setup] Error 2 And now my erl.exe is completely hosed: jeff@REDACTED /cygdrive/c/Users/jeff/GitHub/otp/bin/win32 $ ./erl.exe {(no error logger present"i)n ietr rtoerr: m"iEnrartoirn gi ni np rdooc_ebsoost "<,0{.b2a.d0a>r wgi,t[h{ eerxli_tp rviaml_uleo:a d{ebra,dcahregc,k[_{feirlle__pr reismu_llto,a3d,e[r{,fcihleec,k"_efrill_ep_rriems_ullota,d3er,[.{efrill"e},,\{"l eirnle_,p28r3i}m]_}l,o{aidneirt.,egrelt\_"b}o,o{tl,i1n,e[,{2f8i3l}e,]"}i,n{iitn. ite,rgle"t},_{bloionte,,178,5[}{]f}i,l{ei,n\i"ti,ngiett._ebrolo\t",}2,,{[l{ifnie l,e7,8"5i}n]i}t,.{eirnli"t},,g{elti_nbeo,o77t2,}2]},,[{{ifniilte,,d\o"_ibnoiott. ,e3r,l[\{"f}i,l{el,i"nien,i7t7.2e}r]l}",}{,i{nliitn,ed,o73_9b}o]o}t],}3}, [{file,\"init.erl\"},{line,739}]}]}\n" Crash dump was written to: erl_crash.dump init terminating in do_boot () On Wednesday, January 2, 2013 7:26:09 PM UTC-8, SurferJeff wrote: I'm working through the example here: http://www.erlang.org/doc/tutorial/c_portdriver.html And I'm trying to get it to run on Windows. I reordered the code in the C source so that it compiles, and added a module.def file so that erlang actually finds and executes the driver init function. I attached a debugger. Walking back up the stack, I observe that: The driver init function returns correctly. erts_sys_ddll_call_init() returns correctly. do_load_driver_entry() returns ERL_DE_NO_ERROR. load_driver_entry() returns ERL_DE_NO_ERROR. erl_ddll_try_load_3 returns t = TUPLE2(hp, am_ok, ok_term); on line 417 of erl_bif_ddl.c. But the next higher call on the stack is _process_main(), which was compiled with gcc and has no debug symbols so I can't step through and figure out why the end result is: =ERROR REPORT==== 2-Jan-2013::19:14:22 === Error in process <0.31.0> with exit value: {enoent,[{erlang,open_port,[{spawn,"example_drv"},[]],[]},{complex5,init,1,[ {file,"c:/Users/jeff/code/code/port_driver/complex5.erl"},{line,19}]}]} Has anyone seen this before? If not, how do I recompile erl.exe purely with cl.exe (no gcc) so that it generates debug symbols? And while I'm recompiling, how do I turn off all optimizations? I can read basic make files, but I get lost in the configure scripts and .in and .mk files. Please take pity on a Windows programmer ;-) _______________________________________________ erlang-questions mailing list 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 huss01@REDACTED Fri Jan 4 09:28:48 2013 From: huss01@REDACTED (=?ISO-8859-1?Q?H=E5kan_Huss?=) Date: Fri, 4 Jan 2013 09:28:48 +0100 Subject: [erlang-questions] Elevator demo In-Reply-To: <50E46AE7.1000204@erlang-solutions.com> References: <50E2222E.3080906@ninenines.eu> <50E46AE7.1000204@erlang-solutions.com> Message-ID: On Wed, Jan 2, 2013 at 6:14 PM, Francesco Cesarini wrote: > The Elevator example was implemented by Hakan Huss in the late 90s at Erlang > Systems. It was part of the 5-day Erlang Literacy course aimed at test and > support staff of the GPRS project. It has been used to demonstrate how Quick > Check can test elevator systems, and featured in a few academic papers. > > /F I haven't looked at the code or the course material in the last ten years, nor do I have it available in any readable format. (I may have a course binder in a box somewhere in the attic, but I think I threw away the floppies containing the course setup a couple of years ago when I realized I didn't have a floppy disk reader any more :-) So all of the following is very much IIRC. Just to add a bit more of background: the elevator example was used as a lab exercise in several parts of the course to practise different topics such as behaviours, supervisors, release handling, etc. The first exercise using the elevator example was the mentioned "bug" that the elevator always stopped at every floor (it is actually not a bug, but an elevator scheduler which is trivially guaranteed to fulfil the requirements on elevator scheduling used in the example). Several refinements of the scheduling were made in the course lab exercises. Since the purpose of the exercise was to use many different aspects of Erlang and OTP, the code has been written to use many behaviours rather than to be the "best" solution for the problem. I still think that the resulting architecture is pretty ok. Regards, /H?kan > > > On 31/12/2012 23:39, Lo?c Hoguin wrote: >> >> Hello 2013, >> >> Just a quick link targeted mostly to people who teach Erlang or those who >> want to demonstrate its features. >> >> Last September Scott gave me the code he had for an old Ericsson elevator >> training application that shows an application with a bug, and an upgrade >> available to perform a release upgrade to fix the bug live. As these are >> elevators, the bug (doors opening at every floor) can be quickly seen fixed >> since the elevators will continue moving until their destination without the >> bug triggering anymore once you did the upgrade. >> >> You can find the source here: >> >> https://github.com/extend/elevators >> >> It should work for R15. Probably does for R14 too, but I didn't test it. >> >> As this is an old demo it uses gs, but I will port the code to wx for R16 >> once it is released if nobody did it before. >> >> Patches are welcome. Also if you know more about the history behind this >> application, I'm interested and will put these infos in the README file. >> > > -- > Erlang Solutions Ltd. > http://www.erlang-solutions.com > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From erlang@REDACTED Fri Jan 4 12:20:35 2013 From: erlang@REDACTED (=?UTF-8?Q?Micha=C5=82_Ptaszek?=) Date: Fri, 4 Jan 2013 12:20:35 +0100 Subject: [erlang-questions] Including erl_call in the release tarball In-Reply-To: References: Message-ID: Hi Ulf, thanks a lot, this one was one of the alternatives I've been thinking about - you saved me a lot of time! FWIW, I'm trying to use Chef and Vagrant on my Mac OS, so I'm afraid I'll not be of a much help when it comes to debugging nasty net_kernel behavior in combination with escript. So again - thanks! Michal PS: Nonetheless, it would be really nice to know if there is an easy way to ship the original erl_call together with the release. On Thu, Jan 3, 2013 at 10:15 PM, Ulf Wiger wrote: > > Hi Michal, > > Not sure if it helps, but here is a first draft of an escript that works > roughly like erl_call. > > https://gist.github.com/4447248 > > I've had great difficulty getting the Distributed Erlang bootstrap to work > nicely on MacOS (haven't tried it elsewhere). Thus, the quirky method of > deleting the net_sup child and re-adding it with specified arguments (also, > the call to inet_db:set_hostname/1 is absolutely necessary on my machine - > I can't explain why). > > Some of the issues I've run into: > > - When calling net_kernel:start(?) from within an escript, the host name > is apparently determined differently from when a %%! line with a node name > is given at the top of the escript. For it to work on my laptop, I have to > give a fully qualified name, which the script then splits and uses for > set_hostname. > > - The times I was able to make it work at all with net_kernel:start(), > connection took forever. After replacing it with the > delete_child/start_child gymnastics, this problem went away. > > Anyway, if it helps anyone, have at it. > > OTP team - this shouldn't be so hard. Perhaps someone could take a look at > the issues? > > BR, > Ulf W > > On 3 Jan 2013, at 19:23, Micha? Ptaszek wrote: > > > Hey, > > > > I'm running my system in the embedded mode, and trying to apply live > upgrades using release_handler. Nonetheless, in order to automate the > process, I would like to interface with the running Erlang node via > 'erl_call' command and pass the release_handler instructions as arguments > (I would love to avoid writing escripts or playing with 'erl -eval > "rpc:call(...)"' mumbo-jumbo). > > > > Unfortunately, it seems like erl_call is not included in the release > package generated by rebar, and to make things worse - is not even put in > the standard erlang bin/ directory. Instead, by default, it's located under > $ERL_ROOT/lib/erlang/lib/erl_interface-$VERSION/bin/erl_call. > > > > Also, trying to add erl_interface application to the released apps does > not work, as erl_interface is not an OTP application (does not have .app > file). > > > > What would be the best way to make sure that the target release package > contains erl_call binary? How do you usually make it accessible/available > on the target system? > > > > Thanks, > > Michal > > _______________________________________________ > > 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clist@REDACTED Fri Jan 4 12:54:46 2013 From: clist@REDACTED (Angel J. Alvarez Miguel) Date: Fri, 4 Jan 2013 12:54:46 +0100 Subject: [erlang-questions] Why system_flag(scheduler_bind_type) is deprecated? In-Reply-To: <20A107A4-ADA5-46F0-A473-FF9418DC211A@erlang.org> References: <20A107A4-ADA5-46F0-A473-FF9418DC211A@erlang.org> Message-ID: <201301041254.46214.clist@uah.es> hi I look a this : "...since we do not want to change this configuration in runtime..." This sounds a bit limiting Current platforms can (and will) shutdown CPU cores in response to power management policies and erlang deamonized software must adapt to this changes without needing a restart. While it seems at first an unprobable scenario right now, on server side it really sounds good when you run erlang on laptop/mobile platforms. Even some virtualization products are planin to use hot-plug facilities to make resource management easier on current platforms so its not really crazy today to think that cpu cores will come and leave at unexpected times on tipical cloud scenarios. IMHO the ability to sense this on user code and facilities to control or alter the scheduler behaviour will be more important in the near future , thus having to restart the entire VM for this seems overkill and a backward movement from the current setup. I have recently experimiented this during the summer case when i unplug my laptop my power management script shut down half of the cores when battery starts to run out and lowers de cpu frecuency and erlang responded on stderrr something about scheduler failure trying to bind to the dead cores, then i managed to make some tests trying to monitor this from erlang code and to put schedulers offline until cores reapear again. Even i can depict scenarios where depending on licensing feaures application code can control the amount of paralelism the VM will exhibit by tweaking schedulers affinity or just shutting them down to limit to the cores licensed... You should think about this even if you plan to make other improvements Regards, Angel On Jueves, 27 de Diciembre de 2012 00:45:05 Rickard Green escribi?: > On Dec 26, 2012, at 5:21 PM, Max Lapshin wrote: > > Why system_flag(scheduler_bind_type, How) is deprecated in favor of +sbt > > flag? > > > > This sbt flag is different when I have to launch via escript or via erl > > and this is why it is less convenient than using system_flag call. > > > > Also system_flag call can be called according to some system > > configuration file and sbt needs full restart. > > Both the 'cpu_topology' and the 'scheduler_bind_type' arguments of the > system_flag/2 BIF are deprecated and will be removed since we do not want > to change this configuration in runtime. With the support for this we got > today the runtime configuration change isn't that problematic, but it > prevents future planned improvements from being implemented. > > Regards, > Rickard Green, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From max.lapshin@REDACTED Fri Jan 4 13:02:28 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Fri, 4 Jan 2013 15:02:28 +0300 Subject: [erlang-questions] Why system_flag(scheduler_bind_type) is deprecated? In-Reply-To: <201301041254.46214.clist@uah.es> References: <20A107A4-ADA5-46F0-A473-FF9418DC211A@erlang.org> <201301041254.46214.clist@uah.es> Message-ID: No, no Angel. You are very right: modern servers are the first candidates to change amount of CPU and RAM. Clouds can change amount of cores and RAM on fly. It was almost impossible on commodity hardware 4 years ago, but it is already here nowadays. Rickard, maybe OTP group should discuss this idea again? Erlang server launched on cloud hosting should be ready for changing number of cores. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wallentin.dahlberg@REDACTED Fri Jan 4 13:44:20 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Fri, 4 Jan 2013 13:44:20 +0100 Subject: [erlang-questions] Why system_flag(scheduler_bind_type) is deprecated? In-Reply-To: References: <20A107A4-ADA5-46F0-A473-FF9418DC211A@erlang.org> <201301041254.46214.clist@uah.es> Message-ID: Two different things. 1. Being able to handle loss of cores or graceful termination of schedulers at runtime. 2. Scheduler bindings at runtime. The first is more important than the second one and something we want to be able to handle gracefully. 2013/1/4 Max Lapshin > No, no Angel. You are very right: modern servers are the first candidates > to change amount of CPU and RAM. > > Clouds can change amount of cores and RAM on fly. It was almost impossible > on commodity hardware 4 years ago, but it is already here nowadays. > > Rickard, maybe OTP group should discuss this idea again? > > Erlang server launched on cloud hosting should be ready for changing > number of cores. > > _______________________________________________ > 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 Fri Jan 4 13:46:00 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Fri, 4 Jan 2013 15:46:00 +0300 Subject: [erlang-questions] Why system_flag(scheduler_bind_type) is deprecated? In-Reply-To: References: <20A107A4-ADA5-46F0-A473-FF9418DC211A@erlang.org> <201301041254.46214.clist@uah.es> Message-ID: Cores can not only shutdown, they can also appear. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zabrane3@REDACTED Fri Jan 4 13:51:56 2013 From: zabrane3@REDACTED (Zabrane Mickael) Date: Fri, 4 Jan 2013 13:51:56 +0100 Subject: [erlang-questions] Why system_flag(scheduler_bind_type) is deprecated? In-Reply-To: References: <20A107A4-ADA5-46F0-A473-FF9418DC211A@erlang.org> <201301041254.46214.clist@uah.es> Message-ID: Agree with Max on this. Regards, Zabrane On Jan 4, 2013, at 1:46 PM, Max Lapshin wrote: > Cores can not only shutdown, they can also appear. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From masklinn@REDACTED Fri Jan 4 13:55:45 2013 From: masklinn@REDACTED (Masklinn) Date: Fri, 4 Jan 2013 13:55:45 +0100 Subject: [erlang-questions] Why system_flag(scheduler_bind_type) is deprecated? In-Reply-To: <373FD3CE-B816-45AF-A97C-F1F0E3C56586@erlang.org> References: <6072f3ef-54a4-4e83-bebe-62186d18cbc2@17g2000vba.googlegroups.com> <373FD3CE-B816-45AF-A97C-F1F0E3C56586@erlang.org> Message-ID: <29835075-11F6-4667-8B14-0F08A5CCF709@masklinn.net> On 2012-12-27, at 00:45 , Rickard Green wrote: > > Neither the +sbt flag nor the 'scheduler_bind_type' argument of the system_flag/2 BIF have ever been supported on MacOSX. This since the last time I tried to find an api for binding threads to processors on MacOSX I couldn't find one. This might however have changed since then. It has not, as far as I know. OSX only provides an affinity API (since 10.5): http://developer.apple.com/library/mac/#releasenotes/Performance/RN-AffinityAPI/_index.html > OS X does not export interfaces that identify processors or control > thread placement?explicit thread to processor binding is not > supported. Instead, the kernel manages all thread placement. From essen@REDACTED Fri Jan 4 14:09:22 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Fri, 04 Jan 2013 14:09:22 +0100 Subject: [erlang-questions] Elevator demo In-Reply-To: References: <50E2222E.3080906@ninenines.eu> <50E46AE7.1000204@erlang-solutions.com> Message-ID: <50E6D482.6000903@ninenines.eu> On 01/04/2013 09:28 AM, H?kan Huss wrote: > On Wed, Jan 2, 2013 at 6:14 PM, Francesco Cesarini > wrote: >> The Elevator example was implemented by Hakan Huss in the late 90s at Erlang >> Systems. It was part of the 5-day Erlang Literacy course aimed at test and >> support staff of the GPRS project. It has been used to demonstrate how Quick >> Check can test elevator systems, and featured in a few academic papers. >> >> /F > I haven't looked at the code or the course material in the last ten > years, nor do I have it available in any readable format. (I may have > a course binder in a box somewhere in the attic, but I think I threw > away the floppies containing the course setup a couple of years ago > when I realized I didn't have a floppy disk reader any more :-) So all > of the following is very much IIRC. > > Just to add a bit more of background: the elevator example was used as > a lab exercise in several parts of the course to practise different > topics such as behaviours, supervisors, release handling, etc. The > first exercise using the elevator example was the mentioned "bug" that > the elevator always stopped at every floor (it is actually not a bug, > but an elevator scheduler which is trivially guaranteed to fulfil the > requirements on elevator scheduling used in the example). Several > refinements of the scheduling were made in the course lab exercises. > > Since the purpose of the exercise was to use many different aspects of > Erlang and OTP, the code has been written to use many behaviours > rather than to be the "best" solution for the problem. I still think > that the resulting architecture is pretty ok. I've added both your comments to the README. Thanks a lot! -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From rustompmody@REDACTED Fri Jan 4 18:19:54 2013 From: rustompmody@REDACTED (Rustom Mody) Date: Fri, 4 Jan 2013 22:49:54 +0530 Subject: [erlang-questions] first erlang program Message-ID: Wrote my first erlang program -- sieve of eratostenes; -------------------------------------------- -module(eratos). -export([main/0, gen/1, sieve/0, filtloop/2]). -define (MAX, 200000). gen(Proc) -> gen(Proc,2). gen(Proc, N) -> if N =< ?MAX -> Proc ! N, gen(Proc, N+1); true -> stop end. filtloop(Prime, NS) -> % NS is NextSieve receive N when is_integer(N) -> if N rem Prime =/= 0 -> NS ! N; true -> ok end, filtloop(Prime,NS); stop -> ok; % io:format("Stopping ~w~n", [Prime]); XX -> io:format("Something strange in filtloop~w~n", [XX]) end. sieve() -> receive Prime -> ok end, io:format("~w~n", [Prime]), Nextsieve = spawn(fun sieve/0), filtloop(Prime, Nextsieve). main() -> gen(spawn (fun sieve/0)). ------------------------------ It is modelled after this shell script (consisting of 3 scripts) $ cat gen.sh i=2 while true; do echo $i i=`expr $i + 1` done -------- $ cat filt.sh while true; do read x if [ 0 != `expr $x % $1` ] ; then echo $x fi done ------------- $ cat sieve.sh read x echo $x filt.sh $x | sieve.sh ---------------- Call like this gen.sh | sieve Performance wise its fun to watch the erlang go 10 (50?) times faster than the shell script However the shell script has an elegance that the erlang does not have because I dont know how to 'anonymize' the stdin/stdout that a classic Unix pipeline gives Also more basic noob questions like how to avoid the io:format statements etc TIA for any tips/guidance Rusi -- http://www.the-magus.in http://blog.languager.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From aggelgian@REDACTED Fri Jan 4 20:22:45 2013 From: aggelgian@REDACTED (Aggelos Giantsios) Date: Fri, 4 Jan 2013 21:22:45 +0200 Subject: [erlang-questions] Manually remove a message from Process Mailbox Message-ID: Happy New Year to everyone! I am trying to simulate the 'receive' expression behaviour. I access the process message queue with erlang:process_info(self(), messages). Assuming I have selected a message Msg which is at position k in the message list and have safely stored it in a variable, is there a way to manually remove Msg from the process message queue? Thanks, Aggelos -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Fri Jan 4 20:51:12 2013 From: tony@REDACTED (Tony Rogvall) Date: Fri, 4 Jan 2013 20:51:12 +0100 Subject: [erlang-questions] Manually remove a message from Process Mailbox In-Reply-To: References: Message-ID: Hi! And happy new year. If you also simulate send you could send with a unique reference: Replace Pid ! Message With Pid ! {make_ref(), Message} Then you can get the k'th message {Ref,Message} and do a selective receive to remove that message: receive {Ref,_Message} -> ok end A bit on the heavy side, but fun. Handling timeout is a bit more tricky, but solvable with the above schema. /Tony On 4 jan 2013, at 20:22, Aggelos Giantsios wrote: > Happy New Year to everyone! > > I am trying to simulate the 'receive' expression behaviour. > I access the process message queue with erlang:process_info(self(), messages). > Assuming I have selected a message Msg which is at position k in the message list and have safely stored it in a variable, > is there a way to manually remove Msg from the process message queue? > > Thanks, > Aggelos > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From eriksoe@REDACTED Fri Jan 4 20:55:08 2013 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Fri, 4 Jan 2013 20:55:08 +0100 Subject: [erlang-questions] Manually remove a message from Process Mailbox In-Reply-To: References: Message-ID: [forgot to write the list] That would be receive TheMsg when TheMsg=:=Msg -> ok end (or shorter but perhaps less clear: receive Msg -> ok end where Msg is already bound) assuming of course that you won't be trying to remove the non-first copy of a specific message - but given that you say you're trying to emulate the receive expression, and that doesn't allow it, then the above should be what you want. 2013/1/4 Aggelos Giantsios > Happy New Year to everyone! > > I am trying to simulate the 'receive' expression behaviour. > I access the process message queue with erlang:process_info(self(), > messages). > Assuming I have selected a message Msg which is at position k in the > message list and have safely stored it in a variable, > is there a way to manually remove Msg from the process message queue? > > Thanks, > Aggelos > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Fri Jan 4 21:03:36 2013 From: tony@REDACTED (Tony Rogvall) Date: Fri, 4 Jan 2013 21:03:36 +0100 Subject: [erlang-questions] Manually remove a message from Process Mailbox In-Reply-To: References: Message-ID: <8C7E40E9-074E-4479-A43F-00EDD38E41F2@rogvall.se> Yes, of course :-) Not sure what I was drinking... /Tony On 4 jan 2013, at 20:55, Erik S?e S?rensen wrote: > [forgot to write the list] > > That would be > receive TheMsg when TheMsg=:=Msg -> ok end > (or shorter but perhaps less clear: > receive Msg -> ok end > where Msg is already bound) > assuming of course that you won't be trying to remove the non-first copy of a specific message - but given that you say you're trying to emulate the receive expression, and that doesn't allow it, then the above should be what you want. > > 2013/1/4 Aggelos Giantsios > Happy New Year to everyone! > > I am trying to simulate the 'receive' expression behaviour. > I access the process message queue with erlang:process_info(self(), messages). > Assuming I have selected a message Msg which is at position k in the message list and have safely stored it in a variable, > is there a way to manually remove Msg from the process message queue? > > Thanks, > Aggelos > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From aggelgian@REDACTED Fri Jan 4 21:21:37 2013 From: aggelgian@REDACTED (Aggelos Giantsios) Date: Fri, 4 Jan 2013 22:21:37 +0200 Subject: [erlang-questions] Manually remove a message from Process Mailbox In-Reply-To: <8C7E40E9-074E-4479-A43F-00EDD38E41F2@rogvall.se> References: <8C7E40E9-074E-4479-A43F-00EDD38E41F2@rogvall.se> Message-ID: The selective receive with a bound Msg worked like a charm. Thanks for the help!! Aggelos On Fri, Jan 4, 2013 at 10:03 PM, Tony Rogvall wrote: > Yes, of course :-) > > Not sure what I was drinking... > > /Tony > > On 4 jan 2013, at 20:55, Erik S?e S?rensen wrote: > > [forgot to write the list] > > That would be > receive TheMsg when TheMsg=:=Msg -> ok end > (or shorter but perhaps less clear: > receive Msg -> ok end > where Msg is already bound) > assuming of course that you won't be trying to remove the non-first copy > of a specific message - but given that you say you're trying to emulate the > receive expression, and that doesn't allow it, then the above should be > what you want. > > 2013/1/4 Aggelos Giantsios > >> Happy New Year to everyone! >> >> I am trying to simulate the 'receive' expression behaviour. >> I access the process message queue with erlang:process_info(self(), >> messages). >> Assuming I have selected a message Msg which is at position k in the >> message list and have safely stored it in a variable, >> is there a way to manually remove Msg from the process message queue? >> >> Thanks, >> Aggelos >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > "Installing applications can lead to corruption over time. Applications > gradually write over each other's libraries, partial upgrades occur, user > and system errors happen, and minute changes may be unnoticeable and > difficult to fix" > > > > > _______________________________________________ > 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 Fri Jan 4 21:24:26 2013 From: gleber.p@REDACTED (Gleb Peregud) Date: Fri, 4 Jan 2013 21:24:26 +0100 Subject: [erlang-questions] Manually remove a message from Process Mailbox In-Reply-To: References: <8C7E40E9-074E-4479-A43F-00EDD38E41F2@rogvall.se> Message-ID: Please note that if you have two identical messages you won't be able to fetch a second message from the queue - receive will always get the first one. On Fri, Jan 4, 2013 at 9:21 PM, Aggelos Giantsios wrote: > The selective receive with a bound Msg worked like a charm. > Thanks for the help!! > > Aggelos > > > On Fri, Jan 4, 2013 at 10:03 PM, Tony Rogvall wrote: >> >> Yes, of course :-) >> >> Not sure what I was drinking... >> >> /Tony >> >> On 4 jan 2013, at 20:55, Erik S?e S?rensen wrote: >> >> [forgot to write the list] >> >> That would be >> receive TheMsg when TheMsg=:=Msg -> ok end >> (or shorter but perhaps less clear: >> receive Msg -> ok end >> where Msg is already bound) >> assuming of course that you won't be trying to remove the non-first copy >> of a specific message - but given that you say you're trying to emulate the >> receive expression, and that doesn't allow it, then the above should be what >> you want. >> >> 2013/1/4 Aggelos Giantsios >>> >>> Happy New Year to everyone! >>> >>> I am trying to simulate the 'receive' expression behaviour. >>> I access the process message queue with erlang:process_info(self(), >>> messages). >>> Assuming I have selected a message Msg which is at position k in the >>> message list and have safely stored it in a variable, >>> is there a way to manually remove Msg from the process message queue? >>> >>> Thanks, >>> Aggelos >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> "Installing applications can lead to corruption over time. Applications >> gradually write over each other's libraries, partial upgrades occur, user >> and system errors happen, and minute changes may be unnoticeable and >> difficult to fix" >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> 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 Sat Jan 5 00:25:25 2013 From: k.petrauskas@REDACTED (Karolis Petrauskas) Date: Sat, 5 Jan 2013 01:25:25 +0200 Subject: [erlang-questions] Application startup order in a release Message-ID: Hello, My Erlang based system is composed of several applications.The applications can be classified to Core, Plugins and Workers. All Plugins and Workers have static dependencies on the Core only. I.e Plugin and Worker application modules use modules from the Core, and have the application Core listed in their *.app files. The Core application provides several behaviours and process registries. Plugins are providing callback modules for these behaviours and registers corresponding processes to the registries. The Worker applications use behaviours defined in the Core and use the registries to lookup the needed processes. That way the Worker applications can use Plugin processes without knowing about them in advance (behaviours are used as interface definitions). I am using sys.config to wire-up all the system (telling Workers which Plugin-provided processes to use by specifying process names). That way I am getting runtime dependencies between the corresponding Workers and Plugins. The corresponding Plugins should be started before the Workers that have run-time dependencies on them. I am generating release (using rebar) to run my system. As I understand, the applications are started according to their application dependencies, as listed in the .app files. Here is my question: how can I control application startup order in the release without including corresponding Plugin applications into the *.app files of the Workers? I want to keep the Worker applications as clean as possible. Is there a way to control the startup order during generation of the release? The only option I know is to transform the application files after they are build (rebar compile) and before the release is generated (rebar generate). But that sounds hacky. Maybe there are better options or maybe my approach on managing application dependencies is wrong? For example, the static dependencies are the following: Plugin1 -> Core, Lib1 Plugin2 -> Core, Lib2, Lib3 Worker1-> Core Worker2-> Core The Lib1, 2, 3 are other applications (e.g. Yaws). They are not needed by Workers till the run-time. Even integration tests (common-test) can be executed without them. But for the production system the following dependencies should be added (or at least the corresponding startup order enforced): Worker1 -> Plugin1, Plugin2 Worker2 -> Plugin1 Karolis From steven.charles.davis@REDACTED Sat Jan 5 00:59:22 2013 From: steven.charles.davis@REDACTED (Steve Davis) Date: Fri, 4 Jan 2013 15:59:22 -0800 (PST) Subject: [erlang-questions] first erlang program In-Reply-To: References: Message-ID: Hi Rusi, Run that program two or three times in one vm session. You may find that io:format isn't the big issue here :-) The io statements are simply a user echo (i.e. io:format(user, _, _)) A useful program would return the composite list... (think map/reduce). Welcome to the fun - your first program is definitely more sophisticated than my first erlang program was. Best, Steve On Friday, January 4, 2013 11:19:54 AM UTC-6, rusi wrote: > > Wrote my first erlang program -- sieve of eratostenes; > -------------------------------------------- > -module(eratos). > -export([main/0, gen/1, sieve/0, filtloop/2]). > > -define (MAX, 200000). > gen(Proc) -> gen(Proc,2). > gen(Proc, N) -> > if N =< ?MAX -> Proc ! N, > gen(Proc, N+1); > true -> stop > end. > > filtloop(Prime, NS) -> % NS is NextSieve > receive > N when is_integer(N) -> > if N rem Prime =/= 0 -> > NS ! N; > true -> ok > end, > filtloop(Prime,NS); > stop -> ok; % io:format("Stopping ~w~n", [Prime]); > XX -> io:format("Something strange in filtloop~w~n", [XX]) > end. > > sieve() -> > receive Prime -> ok end, > io:format("~w~n", [Prime]), > Nextsieve = spawn(fun sieve/0), > filtloop(Prime, Nextsieve). > > main() -> > gen(spawn (fun sieve/0)). > ------------------------------ > > > It is modelled after this shell script (consisting of 3 scripts) > > $ cat gen.sh > i=2 > while true; do > echo $i > i=`expr $i + 1` > done > -------- > $ cat filt.sh > while true; do > read x > if [ 0 != `expr $x % $1` ] ; then > echo $x > fi > done > ------------- > $ cat sieve.sh > read x > echo $x > filt.sh $x | sieve.sh > ---------------- > Call like this > gen.sh | sieve > > Performance wise its fun to watch the erlang go 10 (50?) times faster than > the shell script > However the shell script has an elegance that the erlang does not have > because I dont know how to 'anonymize' > the stdin/stdout that a classic Unix pipeline gives > > Also more basic noob questions like how to avoid the io:format statements > etc > > TIA for any tips/guidance > Rusi > -- > http://www.the-magus.in > http://blog.languager.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.charles.davis@REDACTED Sat Jan 5 03:03:23 2013 From: steven.charles.davis@REDACTED (Steve Davis) Date: Fri, 4 Jan 2013 18:03:23 -0800 (PST) Subject: [erlang-questions] Application startup order in a release In-Reply-To: References: Message-ID: <8e72220c-d0b9-4c15-a6f9-5a80aca82caf@googlegroups.com> If, in your app definition you have: {application, 'Plugin1', [ ... {applications, ['Core', 'Lib1']}, ... ]} ...then it would be reasonable to expect that they *have* to be there. No? This might be a really annoying answer... and not just for you. /s -------------- next part -------------- An HTML attachment was scrubbed... URL: From rustompmody@REDACTED Sat Jan 5 04:15:20 2013 From: rustompmody@REDACTED (Rustom Mody) Date: Sat, 5 Jan 2013 08:45:20 +0530 Subject: [erlang-questions] first erlang program In-Reply-To: References: Message-ID: On Sat, Jan 5, 2013 at 5:29 AM, Steve Davis wrote: > Hi Rusi, > > Run that program two or three times in one vm session. You may find that > io:format isn't the big issue here :-) > Yeah I know processes are not dying (overpopulation? :D ) Welcome to the fun - your first program is definitely more sophisticated > than my first erlang program was. > Thanks Steve for the kind words. My problem is that Ive modelled this problem after haskell, where the solution is a one-liner: sieve (p:xs) = p : sieve [x | x<- xs, x `mod` p /= 0] And a control-C solves the 'inifinity' problem My attempts at 'finitizing' the erlang are evidently not so successful :D Any tips? [About me: Ive spent 2 1/2 decades doing and teaching functional programming. Never touched concurrency] Rusi -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Sat Jan 5 09:29:58 2013 From: dmkolesnikov@REDACTED (dmitry kolesnikov) Date: Sat, 5 Jan 2013 10:29:58 +0200 Subject: [erlang-questions] Application startup order in a release In-Reply-To: References: Message-ID: <-496209823458418460@unknownmsgid> Hello, Basically you are assembling a release out of many applications. You have to define a relconfig file. It defines all application and they start up order. Once config is defined you can generate a release ./rebar generate Best Regards, Dmitry >-|-|-*> On 5.1.2013, at 1.25, Karolis Petrauskas wrote: > Hello, > > My Erlang based system is composed of several applications.The > applications can be classified to Core, Plugins and Workers. All > Plugins and Workers have static dependencies on the Core only. I.e > Plugin and Worker application modules use modules from the Core, and > have the application Core listed in their *.app files. The Core > application provides several behaviours and process registries. > Plugins are providing callback modules for these behaviours and > registers corresponding processes to the registries. The Worker > applications use behaviours defined in the Core and use the registries > to lookup the needed processes. That way the Worker applications can > use Plugin processes without knowing about them in advance (behaviours > are used as interface definitions). > I am using sys.config to wire-up all the system (telling Workers > which Plugin-provided processes to use by specifying process names). > That way I am getting runtime dependencies between the corresponding > Workers and Plugins. The corresponding Plugins should be started > before the Workers that have run-time dependencies on them. > I am generating release (using rebar) to run my system. As I > understand, the applications are started according to their > application dependencies, as listed in the .app files. Here is my > question: how can I control application startup order in the release > without including corresponding Plugin applications into the *.app > files of the Workers? I want to keep the Worker applications as clean > as possible. Is there a way to control the startup order during > generation of the release? The only option I know is to transform the > application files after they are build (rebar compile) and before the > release is generated (rebar generate). But that sounds hacky. Maybe > there are better options or maybe my approach on managing application > dependencies is wrong? > > For example, the static dependencies are the following: > Plugin1 -> Core, Lib1 > Plugin2 -> Core, Lib2, Lib3 > Worker1-> Core > Worker2-> Core > > The Lib1, 2, 3 are other applications (e.g. Yaws). They are not > needed by Workers till the run-time. Even integration tests > (common-test) can be executed without them. But for the production > system the following dependencies should be added (or at least the > corresponding startup order enforced): > Worker1 -> Plugin1, Plugin2 > Worker2 -> Plugin1 > > Karolis > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From k.petrauskas@REDACTED Sat Jan 5 10:35:03 2013 From: k.petrauskas@REDACTED (Karolis Petrauskas) Date: Sat, 5 Jan 2013 11:35:03 +0200 Subject: [erlang-questions] Application startup order in a release In-Reply-To: <-496209823458418460@unknownmsgid> References: <-496209823458418460@unknownmsgid> Message-ID: Hello, I have: {application, 'Core', [ ... {applications, []}, ... ]} {application, 'Plugin1', [ ... {applications, ['Core', 'Lib1']}, ... ]} {application, 'Worker1', [ ... {applications, ['Core']}, ... ]} The dependencies in this case do not define, which application should be started first, Plugin1 or Worker1. Is it enough to specify these applications in an appropriate order in the reltool.config (in order to be sure, that the Plugin1 will be started before Worker1)?, i.e. {sys, [ ... {rel, "my_rel", "1", [ .... Core, Plugin1, Worker1 ]}, ... ]} Or maybe there are other configuration options in the reltool.config to specify application startup order? I experimented with the rel option in the reltool.config a bit. It looks like the applications are started in the specified order, except that the order is adjusted to satisfy the dependencies (applications option) in the application resource files. But I am not sure, if that was just lucky case, or the system is guaranteed to work so. Karolis On Sat, Jan 5, 2013 at 10:29 AM, dmitry kolesnikov wrote: > Hello, > > Basically you are assembling a release out of many applications. You > have to define a relconfig file. It defines all application and they > start up order. > Once config is defined you can generate a release ./rebar generate > > Best Regards, > Dmitry >-|-|-*> > > > On 5.1.2013, at 1.25, Karolis Petrauskas wrote: > >> Hello, >> >> My Erlang based system is composed of several applications.The >> applications can be classified to Core, Plugins and Workers. All >> Plugins and Workers have static dependencies on the Core only. I.e >> Plugin and Worker application modules use modules from the Core, and >> have the application Core listed in their *.app files. The Core >> application provides several behaviours and process registries. >> Plugins are providing callback modules for these behaviours and >> registers corresponding processes to the registries. The Worker >> applications use behaviours defined in the Core and use the registries >> to lookup the needed processes. That way the Worker applications can >> use Plugin processes without knowing about them in advance (behaviours >> are used as interface definitions). >> I am using sys.config to wire-up all the system (telling Workers >> which Plugin-provided processes to use by specifying process names). >> That way I am getting runtime dependencies between the corresponding >> Workers and Plugins. The corresponding Plugins should be started >> before the Workers that have run-time dependencies on them. >> I am generating release (using rebar) to run my system. As I >> understand, the applications are started according to their >> application dependencies, as listed in the .app files. Here is my >> question: how can I control application startup order in the release >> without including corresponding Plugin applications into the *.app >> files of the Workers? I want to keep the Worker applications as clean >> as possible. Is there a way to control the startup order during >> generation of the release? The only option I know is to transform the >> application files after they are build (rebar compile) and before the >> release is generated (rebar generate). But that sounds hacky. Maybe >> there are better options or maybe my approach on managing application >> dependencies is wrong? >> >> For example, the static dependencies are the following: >> Plugin1 -> Core, Lib1 >> Plugin2 -> Core, Lib2, Lib3 >> Worker1-> Core >> Worker2-> Core >> >> The Lib1, 2, 3 are other applications (e.g. Yaws). They are not >> needed by Workers till the run-time. Even integration tests >> (common-test) can be executed without them. But for the production >> system the following dependencies should be added (or at least the >> corresponding startup order enforced): >> Worker1 -> Plugin1, Plugin2 >> Worker2 -> Plugin1 >> >> Karolis >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions From steven.charles.davis@REDACTED Sat Jan 5 15:10:58 2013 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sat, 5 Jan 2013 06:10:58 -0800 (PST) Subject: [erlang-questions] first erlang program In-Reply-To: References: Message-ID: On Friday, January 4, 2013 9:15:20 PM UTC-6, rusi wrote: > My attempts at 'finitizing' the erlang are evidently not so successful :D > Any tips? > > Although your code includes a 'stop' signal to break out of the loop, once a sieve enters its filtloop, when does it ever receive a signal to stop? What happens to the sieve that never receives a prime? The result is that any prime sieve (and the very last) will still be waiting in a receive state after all the required processing is complete. regs, /s -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerome@REDACTED Sat Jan 5 15:21:45 2013 From: jerome@REDACTED (=?UTF-8?B?SsOpcsO0bWUgRGVzcXVpbGJldA==?=) Date: Sat, 05 Jan 2013 15:21:45 +0100 Subject: [erlang-questions] first erlang program In-Reply-To: References: Message-ID: <50E836F9.5080900@desquilbet.org> Hello Rusdom, Le 04/01/2013 18:19, Rustom Mody a ?crit : > Wrote my first erlang program -- sieve of eratostenes; Funny, it was also my first attempt to Erlang, starting from an Ada example in "Concurrent and Real-Time Programming in Ada" by Alan Burns and Andy Wellings; and we reprogrammed it (well, yet another variant) as a group exercise during our Erlang Dojo in Paris last December... :-) Some comments below. > -------------------------------------------- > -module(eratos). > -export([main/0, gen/1, sieve/0, filtloop/2]). Because you spawn the funs, you only need to export "main". > -define (MAX, 200000). > gen(Proc) -> gen(Proc,2). > gen(Proc, N) -> > if N =< ?MAX -> Proc ! N, > gen(Proc, N+1); > true -> stop > end. > > filtloop(Prime, NS) -> % NS is NextSieve Or rename "NS" into "Next_Sieve" :-) And maybe refactor with two function clauses to avoid the if. But the main issue I guess here is "stop", which should be more: send "stop" to the first sieve (prime number 2) and have it resend "stop" the next sieves so that they all stop. See also at the end of this email. With your version, if you run the program from an erlang shell and then type > i(). you'll see that all the sieve-processes are still running. > receive > N when is_integer(N) -> Well, you may think again about why you would really need the guard here. If it is just not to catch "stop", then move the "stop" clause below to the first place. > if N rem Prime =/= 0 -> > NS ! N; > true -> ok > end, > filtloop(Prime,NS); > stop -> ok; % io:format("Stopping ~w~n", [Prime]); Again, good idea but I don't think any "stop" message is ever sent. > XX -> io:format("Something strange in filtloop~w~n", [XX]) Indeed. But I think you have let go with defensive programming in Erlang. > end. > > sieve() -> > receive Prime -> ok end, > io:format("~w~n", [Prime]), > Nextsieve = spawn(fun sieve/0), > filtloop(Prime, Nextsieve). > > main() -> > gen(spawn (fun sieve/0)). I think the Erlang way would be to name the "main" function "start" instead of "main". Juste because it is the default name from an erl command perspective: see "-run" at . > ------------------------------ > > > It is modelled after this shell script (consisting of 3 scripts) > > $ cat gen.sh > i=2 > while true; do > echo $i > i=`expr $i + 1` > done > -------- > $ cat filt.sh > while true; do > read x > if [ 0 != `expr $x % $1` ] ; then > echo $x > fi > done > ------------- > $ cat sieve.sh > read x > echo $x > filt.sh $x | sieve.sh > ---------------- > Call like this > gen.sh | sieve > > Performance wise its fun to watch the erlang go 10 (50?) times faster > than the shell script > However the shell script has an elegance that the erlang does not have > because I dont know how to 'anonymize' > the stdin/stdout that a classic Unix pipeline gives > > Also more basic noob questions like how to avoid the io:format > statements etc I think you have to put some concurrent observer pattern in place, in order to distribute the primes to whatever clients need them ? > TIA for any tips/guidance > Rusi > -- > http://www.the-magus.in > http://blog.languager.org Here is how I refactored your code (still io:format()), but it's not optimal I think. I'll try to merge your version with ours, but later... :-) Cordially, J?r?me. --------8<----------------- -module(eratos2). -export([start/0]). -define (MAX, 200000). start() -> gen(spawn (fun sieve/0)). gen(Sieve) -> gen(Sieve, 2). gen(Sieve, N) when N =< ?MAX -> Sieve ! N, gen(Sieve, N+1); gen(Sieve, N) -> io:format("Stopping at ~b~n", [N]), Sieve ! stop. filtloop(Prime, NextSieve) -> receive stop -> NextSieve ! stop, exit(stopped); N -> if N rem Prime =/= 0 -> NextSieve ! N; true -> ok end, filtloop(Prime, NextSieve) end. sieve() -> receive stop -> exit(stopped); Prime -> io:format("~b~n", [Prime]), NextSieve = spawn(fun sieve/0), filtloop(Prime, NextSieve) end. --------8<----------------- From steven.charles.davis@REDACTED Sat Jan 5 16:43:07 2013 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sat, 5 Jan 2013 07:43:07 -0800 (PST) Subject: [erlang-questions] first erlang program In-Reply-To: <50E836F9.5080900@desquilbet.org> References: <50E836F9.5080900@desquilbet.org> Message-ID: <2def38e5-44a6-4165-9be6-ad7afd82a19a@googlegroups.com> And... for fun... a refactored version that should scale and also avoid io:format: -module(eratos). -export([primes/1]). primes(Max) -> ResultPid = self(), Pid = spawn(fun() -> sieve(ResultPid) end), map(Pid, 2, Max). map(Pid, N, Max) when N =< Max -> Pid ! N, map(Pid, N + 1, Max); map(Pid, _, _) -> Pid ! done, reduce([]). reduce(Acc) -> receive done -> lists:reverse(Acc); Prime -> reduce([Prime|Acc]) end. sieve(ResultPid) -> receive done -> ResultPid ! done; Prime when is_integer(Prime) -> ResultPid ! Prime, Pid = spawn(fun() -> sieve(ResultPid) end), sieve(Prime, Pid) end. sieve(Prime, Pid) -> receive done -> Pid ! done; N when N rem Prime =/= 0 -> Pid ! N, sieve(Prime, Pid); N when is_integer(N) -> sieve(Prime, Pid) end. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rustompmody@REDACTED Sun Jan 6 04:16:30 2013 From: rustompmody@REDACTED (Rustom Mody) Date: Sun, 6 Jan 2013 08:46:30 +0530 Subject: [erlang-questions] first erlang program In-Reply-To: <2def38e5-44a6-4165-9be6-ad7afd82a19a@googlegroups.com> References: <50E836F9.5080900@desquilbet.org> <2def38e5-44a6-4165-9be6-ad7afd82a19a@googlegroups.com> Message-ID: On Sat, Jan 5, 2013 at 9:13 PM, Steve Davis wrote: > And... for fun... a refactored version that should scale and also avoid > io:format: > Thanks Steve for your efforts. Now if I wanted to 'see' the scaling what do I have to do/setup? Just for context: I am demoing this to a class of noobs (more noob than me if thats possible :D) on a 4-core laptop mostly on linux but could also use windows. I suppose I could hook up another machine with a back-to-back ethernet cable. Naturally I would prefer to 'scale up the scaling-up measurement' ie first erlang-ecosystem methods then linux processes methods then throwing more 'hard' hardware -------------- next part -------------- An HTML attachment was scrubbed... URL: From hd2010@REDACTED Sun Jan 6 09:25:41 2013 From: hd2010@REDACTED (Henning Diedrich) Date: Sun, 6 Jan 2013 09:25:41 +0100 Subject: [erlang-questions] Dialyzer: send_timeout infinity Message-ID: <3C7F5DFD-3016-4524-9CA7-ECD6AB224401@eonblast.com> I had trouble with Dialyzer from a socket connect option that included {send_timeout, infinity}. Dialyzer felt that made this and all calling functions fail. Using an integer like in {send_timeout, 1000000} works. I saw an old bug report regarding an internal type check for number on that parameter. Maybe that is still in place? Or is this a feature? This did not work: -spec connect(inet:ip_address() | inet:hostname(),inet:port_number()) -> {ok, inet:socket()} | no_return(). connect(Host, Port) -> Opts = [ binary, {packet, 4}, {delay_send, true}, {nodelay, false}, {send_timeout, infinity} ], % Dialyzer does not accept infinity {ok, Socket} = try case gen_tcp:connect(Host, Port, Opts) of ... This works: -spec connect(inet:ip_address() | inet:hostname(),inet:port_number()) -> {ok, inet:socket()} | no_return(). connect(Host, Port) -> Opts = [ binary, {packet, 4}, {delay_send, true}, {nodelay, false}, {send_timeout, 10000000000} ], % Dialyzer does not accept infinity {ok, Socket} = try case gen_tcp:connect(Host, Port, Opts) of ?. The actual error messages from Dialyzer were: erlvolt_conn.erl:93: Function tx_loop/1 will never be called erlvolt_conn.erl:181: Function consume/1 will never be called erlvolt_conn.erl:196: Function dispatch/1 will never be called erlvolt_conn.erl:378: Function encode_pid/1 will never be called erlvolt_conn.erl:384: Function decode_pid/1 will never be called erlvolt_wire.erl:1780: Function createConnection/0 has no local return erlvolt_wire.erl:1791: Function createConnection/1 has no local return erlvolt_wire.erl:1800: Function createConnection/3 has no local return erlvolt_wire.erl:1809: Function createConnection/4 has no local return erlvolt_wire.erl:1820: Function open/4 has no local return erlvolt_wire.erl:1830: Function connect/2 has no local return They disappeared by replacing infinity with an integer. Best, Henning From steven.charles.davis@REDACTED Sun Jan 6 12:44:27 2013 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sun, 6 Jan 2013 03:44:27 -0800 (PST) Subject: [erlang-questions] first erlang program In-Reply-To: References: <50E836F9.5080900@desquilbet.org> <2def38e5-44a6-4165-9be6-ad7afd82a19a@googlegroups.com> Message-ID: <53040cae-0ee7-41d4-a8dc-4195f5bbee02@googlegroups.com> Hm ok. By "throw in more hardware" you are meaning you wish to take advantage of distribution as well as concurrency. Perhaps I should have been more specific about the context of scaling I was talking about, namely, vertical. You see, while this version of the program should be able to use all the cores (which without more work, I don't guarantee), and won't exhaust resources (which is easy to prove), it also won't (and was not designed to) distribute across nodes. For that, the next step is that you need to turn eratos into a gen server inside an OTP application... You will need to consider in the next iteration of design what parts of the processing you are distributing, what messages need to be passed between distributed nodes. This may mean some thought about how elements of the algorithm can be separated efficiently. For all the "magic" of OTP, you will likely find that what erlang is rather good at is facing you with the real problem you are trying to solve rather than to allowing you to get distracted inside "boilerplate" code. When I started learning the many capabilities of Erlang, I found that as well as the documentation's manuals, Joe's book was the most helpful guide for me... http://pragprog.com/book/jaerlang/programming-erlang (which IIRC may be being updated to a new edition as I write) BTW this is not to deny the quality of other books on Erlang (e.g. I have not read LYSE), but rather that Joe's book happened to fit my approach to learning. regs, /s On Saturday, January 5, 2013 9:16:30 PM UTC-6, rusi wrote: > > On Sat, Jan 5, 2013 at 9:13 PM, Steve Davis > > wrote: > >> And... for fun... a refactored version that should scale and also avoid >> io:format: >> > > Thanks Steve for your efforts. > Now if I wanted to 'see' the scaling what do I have to do/setup? > > Just for context: I am demoing this to a class of noobs (more noob than me > if thats possible :D) on a 4-core laptop mostly on linux but could also use > windows. > > I suppose I could hook up another machine with a back-to-back ethernet > cable. > Naturally I would prefer to 'scale up the scaling-up measurement' > ie first erlang-ecosystem methods > then linux processes methods > then throwing more 'hard' hardware > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.charles.davis@REDACTED Sun Jan 6 13:02:06 2013 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sun, 6 Jan 2013 04:02:06 -0800 (PST) Subject: [erlang-questions] first erlang program In-Reply-To: <53040cae-0ee7-41d4-a8dc-4195f5bbee02@googlegroups.com> References: <50E836F9.5080900@desquilbet.org> <2def38e5-44a6-4165-9be6-ad7afd82a19a@googlegroups.com> <53040cae-0ee7-41d4-a8dc-4195f5bbee02@googlegroups.com> Message-ID: <5e9b9d45-eb1a-493c-b299-0fc82f0a50ea@googlegroups.com> I'm going to rebut my previous post! Whenever I'm creating a useful application I now "naturally" resort to using OTP support, but it's not strictly necessary. In fact, if you are learning it may not be very productive to introduce too many parts of the platform in one go. The next thing to understand is actually just nodes and node communication in the core erlang modules. Secondly, I'm not sure the sieve is a good candidate for an algorithm to distribute since the outcome of each calculation is reliant on all previous calculations. You may consider a different program that has parts that can be obviously partitioned out into independent blocks of processing. best, /s On Sunday, January 6, 2013 5:44:27 AM UTC-6, Steve Davis wrote: > > Hm ok. By "throw in more hardware" you are meaning you wish to take > advantage of distribution as well as concurrency. Perhaps I should have > been more specific about the context of scaling I was talking about, > namely, vertical. You see, while this version of the program should be able > to use all the cores (which without more work, I don't guarantee), and > won't exhaust resources (which is easy to prove), it also won't (and was > not designed to) distribute across nodes. > > For that, the next step is that you need to turn eratos into a gen server > inside an OTP application... You will need to consider in the next > iteration of design what parts of the processing you are distributing, what > messages need to be passed between distributed nodes. This may mean some > thought about how elements of the algorithm can be separated > efficiently. For all the "magic" of OTP, you will likely find that what > erlang is rather good at is facing you with the real problem you are trying > to solve rather than to allowing you to get distracted inside "boilerplate" > code. > > When I started learning the many capabilities of Erlang, I found that as > well as the documentation's manuals, Joe's book was the most helpful guide > for me... http://pragprog.com/book/jaerlang/programming-erlang (which > IIRC may be being updated to a new edition as I write) BTW this is not to > deny the quality of other books on Erlang (e.g. I have not read LYSE), but > rather that Joe's book happened to fit my approach to learning. > > regs, > /s > > On Saturday, January 5, 2013 9:16:30 PM UTC-6, rusi wrote: >> >> On Sat, Jan 5, 2013 at 9:13 PM, Steve Davis wrote: >> >>> And... for fun... a refactored version that should scale and also avoid >>> io:format: >>> >> >> Thanks Steve for your efforts. >> Now if I wanted to 'see' the scaling what do I have to do/setup? >> >> Just for context: I am demoing this to a class of noobs (more noob than >> me if thats possible :D) on a 4-core laptop mostly on linux but could also >> use windows. >> >> I suppose I could hook up another machine with a back-to-back ethernet >> cable. >> Naturally I would prefer to 'scale up the scaling-up measurement' >> ie first erlang-ecosystem methods >> then linux processes methods >> then throwing more 'hard' hardware >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.charles.davis@REDACTED Sun Jan 6 13:44:55 2013 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sun, 6 Jan 2013 04:44:55 -0800 (PST) Subject: [erlang-questions] first erlang program In-Reply-To: <5e9b9d45-eb1a-493c-b299-0fc82f0a50ea@googlegroups.com> References: <50E836F9.5080900@desquilbet.org> <2def38e5-44a6-4165-9be6-ad7afd82a19a@googlegroups.com> <53040cae-0ee7-41d4-a8dc-4195f5bbee02@googlegroups.com> <5e9b9d45-eb1a-493c-b299-0fc82f0a50ea@googlegroups.com> Message-ID: Something interesting. I imagined that a serial implementation of this algorithm would be as fast/faster than the concurrent version. So I quickly ran up a comparison. On measuring, I found that I my first guess was wrong. The parallel version is some 30-50% quicker... %% serial code used to compare primes2(Max) -> sieve(2, Max, []). sieve(X, Max, Acc) when X =< Max -> case is_prime(X, Acc) of true -> Acc0 = [X|Acc]; false -> Acc0 = Acc end, sieve(X + 1, Max, Acc0); sieve(_, _, Acc) -> lists:reverse(Acc). is_prime(X, [H|_]) when X rem H =:= 0 -> false; is_prime(X, [_|T]) -> is_prime(X, T); is_prime(_, []) -> true. So maybe the sieve would work as a demo after all, by distributing the prime sieves across multiple nodes using spawn(Node, Fun). /s On Sunday, January 6, 2013 6:02:06 AM UTC-6, Steve Davis wrote: > > I'm going to rebut my previous post! > > Whenever I'm creating a useful application I now "naturally" resort to > using OTP support, but it's not strictly necessary. In fact, if you are > learning it may not be very productive to introduce too many parts of the > platform in one go. The next thing to understand is actually just nodes and > node communication in the core erlang modules. > > Secondly, I'm not sure the sieve is a good candidate for an algorithm to > distribute since the outcome of each calculation is reliant on all previous > calculations. You may consider a different program that has parts that can > be obviously partitioned out into independent blocks of processing. > > best, > /s > > On Sunday, January 6, 2013 5:44:27 AM UTC-6, Steve Davis wrote: >> >> Hm ok. By "throw in more hardware" you are meaning you wish to take >> advantage of distribution as well as concurrency. Perhaps I should have >> been more specific about the context of scaling I was talking about, >> namely, vertical. You see, while this version of the program should be able >> to use all the cores (which without more work, I don't guarantee), and >> won't exhaust resources (which is easy to prove), it also won't (and was >> not designed to) distribute across nodes. >> >> For that, the next step is that you need to turn eratos into a gen server >> inside an OTP application... You will need to consider in the next >> iteration of design what parts of the processing you are distributing, what >> messages need to be passed between distributed nodes. This may mean some >> thought about how elements of the algorithm can be separated >> efficiently. For all the "magic" of OTP, you will likely find that what >> erlang is rather good at is facing you with the real problem you are trying >> to solve rather than to allowing you to get distracted inside "boilerplate" >> code. >> >> When I started learning the many capabilities of Erlang, I found that as >> well as the documentation's manuals, Joe's book was the most helpful guide >> for me... http://pragprog.com/book/jaerlang/programming-erlang (which >> IIRC may be being updated to a new edition as I write) BTW this is not to >> deny the quality of other books on Erlang (e.g. I have not read LYSE), but >> rather that Joe's book happened to fit my approach to learning. >> >> regs, >> /s >> >> On Saturday, January 5, 2013 9:16:30 PM UTC-6, rusi wrote: >>> >>> On Sat, Jan 5, 2013 at 9:13 PM, Steve Davis wrote: >>> >>>> And... for fun... a refactored version that should scale and also avoid >>>> io:format: >>>> >>> >>> Thanks Steve for your efforts. >>> Now if I wanted to 'see' the scaling what do I have to do/setup? >>> >>> Just for context: I am demoing this to a class of noobs (more noob than >>> me if thats possible :D) on a 4-core laptop mostly on linux but could also >>> use windows. >>> >>> I suppose I could hook up another machine with a back-to-back ethernet >>> cable. >>> Naturally I would prefer to 'scale up the scaling-up measurement' >>> ie first erlang-ecosystem methods >>> then linux processes methods >>> then throwing more 'hard' hardware >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonstl@REDACTED Sun Jan 6 16:56:41 2013 From: simonstl@REDACTED (Simon St.Laurent) Date: Sun, 06 Jan 2013 10:56:41 -0500 Subject: [erlang-questions] further documentation for -spec directive? Message-ID: <50E99EB9.2010303@simonstl.com> Is there more comprehensive (ideally tutorial) documentation for the -spec directive than is available from: The examples there are minimal, and don't show, for example, results in EDoc or other environments that rely on this information. If there isn't, I'll probably end up writing it, but I'd be happier if someone else has already done it. -- Simon St.Laurent http://simonstl.com/ From jerome@REDACTED Sun Jan 6 17:25:36 2013 From: jerome@REDACTED (=?UTF-8?B?SsOpcsO0bWUgRGVzcXVpbGJldA==?=) Date: Sun, 06 Jan 2013 17:25:36 +0100 Subject: [erlang-questions] first erlang program In-Reply-To: References: <50E836F9.5080900@desquilbet.org> <2def38e5-44a6-4165-9be6-ad7afd82a19a@googlegroups.com> Message-ID: <50E9A580.1010208@desquilbet.org> > Now if I wanted to 'see' the scaling what do I have to do/setup? > > Just for context: I am demoing this to a class of noobs (more noob than > me if thats possible :D) on a 4-core laptop mostly on linux but could > also use windows. You can demo that using a kind of "cpu graph" widget (like xfce4-taskmanager) showing that all the cores are at their maximum. It proves at least that erl transparently distributes the erlang processes on all the nodes. > I suppose I could hook up another machine with a back-to-back ethernet > cable. > Naturally I would prefer to 'scale up the scaling-up measurement' > ie first erlang-ecosystem methods > then linux processes methods > then throwing more 'hard' hardware Not sure to understand. The program will be limited to the number of erlang processes (some of the erlang framwework plus one process for each sieve - adjust erl with the +P option) you can run on your machine. Then if you want to have another machine taking the following sieves in charge, and another machine, etc., then the whole program/application will have to be redesigned. J. From kunthar@REDACTED Sun Jan 6 17:33:17 2013 From: kunthar@REDACTED (Kunthar) Date: Sun, 6 Jan 2013 18:33:17 +0200 Subject: [erlang-questions] practice on music data Message-ID: Maybe someone or possibly me can provide a better/faster way: http://musicmachinery.com/2011/09/04/how-to-process-a-million-songs-in-20-minutes/ Just FYI. -- BR, \|/ Kunthar From rustompmody@REDACTED Sun Jan 6 18:38:07 2013 From: rustompmody@REDACTED (Rustom Mody) Date: Sun, 6 Jan 2013 23:08:07 +0530 Subject: [erlang-questions] rebar and erlang version compatibility Message-ID: One of my colleagues whom I introduced rebar to asked me this. Since I am out of depth in erlang matters rather quickly, hoping someone here can help ------------------ The difficulty is with using Rebar with Erlang. I am using the following versions: Erlang-(R15B01) rebar 2.1.0-pre R15B01 Q 1> Is this an incompatible combination? I am having difficulties with './rebar -v generate'. I tried varied fudges with the reltool.config, but am unable to build an embedded node with my app. My dir tree: myproj/apps/myapp myproj/rel myproj/rel/reltool.config myproj/rebar.config myproj/rebar myproj/rel directory tree generated with: ./rebar create-node nodeid=myapp rebar.config has a single line: {sub_dirs, ["apps/myapp", "rel"]}. reltool.config is: {sys, [ {lib_dirs , ["../apps"]}, {erts, [{mod_cond, derived}, {app_file, strip}]}, {rel, "", "1",[myapp,kernel,stdlib,sasl ]}, {rel, "start_clean", "",[kernel,stdlib ]}, {boot_rel, "myapp"}, {relocatable, true}, {profile, embedded}, {incl_cond, exclude}, {app, sasl, [{incl_cond, include}]}, {app, stdlib, [{incl_cond, include}]}, {app, kernel, [{incl_cond, include}]}, {app, hipe, [{incl_cond, exclude}]}, {app, myapp, [{mod_cond, app}, {incl_cond, include}]} ]}. Q2> I find that the embedded node is not being generated. Can someone guide me to a solution (or the right forum) to raise this question for a newbie? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy@REDACTED Sun Jan 6 21:57:27 2013 From: jeremy@REDACTED (Jeremy Ong) Date: Sun, 6 Jan 2013 12:57:27 -0800 Subject: [erlang-questions] rebar and erlang version compatibility In-Reply-To: References: Message-ID: Forgot to CC list: --- Your release name is an empty string in your reltool.config {rel, "", "1",[myapp,kernel,stdlib,sasl ]}, Try something like {rel, "myapp", "1",[myapp,kernel,stdlib,sasl ]}, and see if that helps. On Sun, Jan 6, 2013 at 9:38 AM, Rustom Mody wrote: > One of my colleagues whom I introduced rebar to asked me this. > Since I am out of depth in erlang matters rather quickly, hoping someone > here can help > > ------------------ > The difficulty is with using Rebar with Erlang. I am using the following > versions: > Erlang-(R15B01) > rebar 2.1.0-pre R15B01 > > Q 1> Is this an incompatible combination? > > I am having difficulties with './rebar -v generate'. I tried varied fudges > with > the reltool.config, but am unable to build an embedded node with my app. > > > My dir tree: > myproj/apps/myapp > myproj/rel > myproj/rel/reltool.config > myproj/rebar.config > myproj/rebar > > myproj/rel directory tree generated with: > ./rebar create-node nodeid=myapp > > rebar.config has a single line: > {sub_dirs, ["apps/myapp", "rel"]}. > > reltool.config is: > {sys, [ {lib_dirs , ["../apps"]}, > {erts, [{mod_cond, derived}, {app_file, strip}]}, > {rel, "", "1",[myapp,kernel,stdlib,sasl ]}, > {rel, "start_clean", "",[kernel,stdlib ]}, > {boot_rel, "myapp"}, > {relocatable, true}, > {profile, embedded}, > {incl_cond, exclude}, > {app, sasl, [{incl_cond, include}]}, > {app, stdlib, [{incl_cond, include}]}, > {app, kernel, [{incl_cond, include}]}, > {app, hipe, [{incl_cond, exclude}]}, > {app, myapp, [{mod_cond, app}, {incl_cond, include}]} > ]}. > > Q2> I find that the embedded node is not being generated. > Can someone guide me to a solution (or the right forum) to raise this > question > for a newbie? > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourinov@REDACTED Sun Jan 6 22:04:20 2013 From: bourinov@REDACTED (Max Bourinov) Date: Mon, 7 Jan 2013 01:04:20 +0400 Subject: [erlang-questions] further documentation for -spec directive? In-Reply-To: <50E99EB9.2010303@simonstl.com> References: <50E99EB9.2010303@simonstl.com> Message-ID: +1 Also would love to have a full docs and tutorials. Best regards, Max On Sun, Jan 6, 2013 at 7:56 PM, Simon St.Laurent wrote: > Is there more comprehensive (ideally tutorial) documentation for the -spec > directive than is available from: > > > **> > > The examples there are minimal, and don't show, for example, results in > EDoc or other environments that rely on this information. > > If there isn't, I'll probably end up writing it, but I'd be happier if > someone else has already done it. > > -- > Simon St.Laurent > http://simonstl.com/ > ______________________________**_________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/**listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bog09@REDACTED Mon Jan 7 10:01:26 2013 From: bog09@REDACTED (Bogdan Andu) Date: Mon, 7 Jan 2013 01:01:26 -0800 (PST) Subject: [erlang-questions] error_logger heap overflow In-Reply-To: <20121128064746.GE24714@hijacked.us> References: <1353404860.96882.YahooMailNeo@web120706.mail.ne1.yahoo.com> <1353410937.92586.YahooMailNeo@web120706.mail.ne1.yahoo.com> <20121128064746.GE24714@hijacked.us> Message-ID: <1357549286.2317.YahooMailNeo@web120706.mail.ne1.yahoo.com> Sorry for delayed response. Unfortunately, I cannot use the work around presented because is experimental and the system is ready to be launched into production, so I cannot anymore switch back to lager, although is more heap overflow resistant than error_logger is. I stick with error_logger because errors are easier to read and I am accustomed with it. log rotation is solved with newsyslog. What makes lager's messages 'hard to read' is the lack of error formatting. What I would expect from lager: 1. ??? lager:notice() send the message in /var/log/notice_log ??????? lager:error() send the message in /var/log/error_log ??????? lager:info() send the message in /va/log/info_log 2. crash messages to appear only in /var/log/crash_log 3. this sould be configurable 4. more error formatting, like error_log has, in order to be easier to read Why I want that? Because error has higher priority that notice, so all messages founded in /var/log/error_log are also founded in /var/log/notice_log. I do not want duplicated error messages even if they are truncated. Bogdan ----- Original Message ----- From: Andrew Thompson To: erlang-questions@REDACTED Cc: Bogdan Andu Sent: Wednesday, November 28, 2012 8:47 AM Subject: Re: [erlang-questions] error_logger heap overflow On Tue, Nov 20, 2012 at 03:28:57AM -0800, Bogdan Andu wrote: > I used that, lager, but it is hard to read error messages, and the errors are duplicated across all log files. > > One cannot say to lager: commit notice messages to /var/log/notice_log, because all error messages with higher prority get written there, too. I decided to tinker around this week in relation to this issue and came up with this: https://github.com/basho/lager/pull/95 Does that address your concern on that front? > I like how error_logger prints the errors and I am used to it. > > Please give me an advice of how to overcome this situation. > One thing you could do would be to fork the stdlib (or SASL) error_logger gen_event handlers to use lager_format instead of io_lib (lager_format is a fork of io_lib with size based truncation added to avoid the OOM issues). The only downside to this is that lager_format currently lacks the line-wrapping support ~p and friends have in io_lib, so stacktraces, for example, end up on one big line rather than being line wrapped nicely. Also, with regard to lager and formatting OTP errors, lager will try to rewrite common OTP errors into more 'friendly' log messages, but it will also write a truncated version of the original log format to the 'crash.log', if more information is required. Finally, if you could give me more information on what makes lager's messages 'hard to read', I'd appreciate it. Maybe some improvements can be made. Hope that helps, Andrew From bourinov@REDACTED Mon Jan 7 10:30:43 2013 From: bourinov@REDACTED (Max Bourinov) Date: Mon, 7 Jan 2013 13:30:43 +0400 Subject: [erlang-questions] error_logger heap overflow In-Reply-To: <1357549286.2317.YahooMailNeo@web120706.mail.ne1.yahoo.com> References: <1353404860.96882.YahooMailNeo@web120706.mail.ne1.yahoo.com> <1353410937.92586.YahooMailNeo@web120706.mail.ne1.yahoo.com> <20121128064746.GE24714@hijacked.us> <1357549286.2317.YahooMailNeo@web120706.mail.ne1.yahoo.com> Message-ID: As many suggested, go with lager https://github.com/basho/lager We have it in production under decent load and have no issues with it. Best regards, Max On Mon, Jan 7, 2013 at 1:01 PM, Bogdan Andu wrote: > Sorry for delayed response. > > Unfortunately, I cannot use the work around presented because is > experimental and the system is ready to be launched into production, so I > cannot anymore switch back to lager, although is more heap overflow > resistant than error_logger is. > > I stick with error_logger because errors are easier to read and I am > accustomed with it. > > > log rotation is solved with newsyslog. > > > What makes lager's messages 'hard to read' is the lack of error formatting. > > > What I would expect from lager: > 1. lager:notice() send the message in /var/log/notice_log > lager:error() send the message in /var/log/error_log > lager:info() send the message in /va/log/info_log > 2. crash messages to appear only in /var/log/crash_log > 3. this sould be configurable > 4. more error formatting, like error_log has, in order to be easier to read > > > Why I want that? Because error has higher priority that notice, so all > messages founded in /var/log/error_log are also founded in > /var/log/notice_log. I do not want duplicated error messages even if they > are truncated. > > Bogdan > > > > > ----- Original Message ----- > From: Andrew Thompson > To: erlang-questions@REDACTED > Cc: Bogdan Andu > Sent: Wednesday, November 28, 2012 8:47 AM > Subject: Re: [erlang-questions] error_logger heap overflow > > On Tue, Nov 20, 2012 at 03:28:57AM -0800, Bogdan Andu wrote: > > I used that, lager, but it is hard to read error messages, and the > errors are duplicated across all log files. > > > > One cannot say to lager: commit notice messages to /var/log/notice_log, > because all error messages with higher prority get written there, too. > > I decided to tinker around this week in relation to this issue and came > up with this: > > https://github.com/basho/lager/pull/95 > > Does that address your concern on that front? > > > I like how error_logger prints the errors and I am used to it. > > > > Please give me an advice of how to overcome this situation. > > > > One thing you could do would be to fork the stdlib (or SASL) > error_logger gen_event handlers to use lager_format instead of io_lib > (lager_format is a fork of io_lib with size based truncation added to > avoid the OOM issues). The only downside to this is that lager_format > currently lacks the line-wrapping support ~p and friends have in io_lib, > so stacktraces, for example, end up on one big line rather than being > line wrapped nicely. > > Also, with regard to lager and formatting OTP errors, lager will try to > rewrite common OTP errors into more 'friendly' log messages, but it will > also write a truncated version of the original log format to the > 'crash.log', if more information is required. > > Finally, if you could give me more information on what makes lager's > messages 'hard to read', I'd appreciate it. Maybe some improvements can > be made. > > Hope that helps, > > Andrew > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From solomon.wzs@REDACTED Mon Jan 7 10:47:22 2013 From: solomon.wzs@REDACTED (Solomon) Date: Mon, 7 Jan 2013 17:47:22 +0800 Subject: [erlang-questions] How to dynamically compiled module? Message-ID: I want to save a variable and number of threads would call it, but I don't want to save it in ets. I want to dynamically compiled a module, when I call foo:bar(), it will return the variable directly. How should I do? (P.S. the variable like this: {#Fun<...>, <0.1.0>, ...}) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Mon Jan 7 13:20:05 2013 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Mon, 7 Jan 2013 14:20:05 +0200 Subject: [erlang-questions] How to dynamically compiled module? In-Reply-To: References: Message-ID: <85961214-0B78-4F4E-ACDC-AA604C868749@gmail.com> Hi, I looks like you are talking about global status. They do not exists but you can * use ets * use a proc that holds them then foo:bar() -> gen_server:call(foo, bar). * use app environment - Dmitry On Jan 7, 2013, at 11:47 AM, Solomon wrote: > I want to save a variable and number of threads would call it, but I don't want to save it in ets. > > I want to dynamically compiled a module, when I call foo:bar(), it will return the variable directly. > > How should I do? > > (P.S. the variable like this: {#Fun<...>, <0.1.0>, ...}) > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From dmkolesnikov@REDACTED Mon Jan 7 15:11:55 2013 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Mon, 7 Jan 2013 16:11:55 +0200 Subject: [erlang-questions] return supervisor:start_child Message-ID: <88AECA2E-FF84-4D05-8112-995B5EF26303@gmail.com> Hello, Here is copy-paste of supervisor:start_child. start_child(SupRef, ChildSpec) -> Result Result = {ok,Child} | {ok,Child,Info} | {error,Error} When supervisor return {ok,Child,Info} instead of {ok, Child}? I've never seen such return. - Dmitry From straightflush@REDACTED Mon Jan 7 15:15:39 2013 From: straightflush@REDACTED (AD) Date: Mon, 7 Jan 2013 09:15:39 -0500 Subject: [erlang-questions] Environment variables for release Message-ID: Hello, I have a library being built that is leveraging environment variables. There is a line in the library include file that looks like -define(CONST, lib:get_env(Key,Default)). the lib:get_env function simply checks application:get_env(lib, Key) % in order to check the library.app first and then application:get_env(Key) % check for local overrides However when i place variables like the following in the main example.app file in ebin/ {application,example, [{description,[]}, {env,[{'COWBOY_HTTP_PORT',9090}]}, ...... Nothing is getting read. I am not sure if this needs to be in rel/files/app.config instead? Appreciate any help here. -AD -------------- next part -------------- An HTML attachment was scrubbed... URL: From yurinvv@REDACTED Mon Jan 7 15:21:09 2013 From: yurinvv@REDACTED (Slava Yurin) Date: Mon, 07 Jan 2013 21:21:09 +0700 Subject: [erlang-questions] return supervisor:start_child In-Reply-To: <88AECA2E-FF84-4D05-8112-995B5EF26303@gmail.com> References: <88AECA2E-FF84-4D05-8112-995B5EF26303@gmail.com> Message-ID: <596531357568469@web11d.yandex.ru> An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Mon Jan 7 15:27:14 2013 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Mon, 7 Jan 2013 16:27:14 +0200 Subject: [erlang-questions] return supervisor:start_child In-Reply-To: <596531357568469@web11d.yandex.ru> References: <88AECA2E-FF84-4D05-8112-995B5EF26303@gmail.com> <596531357568469@web11d.yandex.ru> Message-ID: <6E068760-9718-4E47-A8E0-EE96F6FA42FE@gmail.com> Sure but when function returns the same value {ok,Child,Info} ? I am always getting {ok, Child} - Dmitry On Jan 7, 2013, at 4:21 PM, Slava Yurin wrote: > http://www.erlang.org/doc/man/supervisor.html#start_child-2: > > If the child process start function returns {ok,Child} or {ok,Child,Info}, the child specification and pid is added to the supervisor and the function returns the same value. > > 07.01.2013, 21:12, "Dmitry Kolesnikov" : > Hello, > > Here is copy-paste of supervisor:start_child. > > start_child(SupRef, ChildSpec) -> Result > Result = {ok,Child} | {ok,Child,Info} | {error,Error} > > When supervisor return {ok,Child,Info} instead of {ok, Child}? I've never seen such return. > > - Dmitry > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yurinvv@REDACTED Mon Jan 7 15:34:03 2013 From: yurinvv@REDACTED (Slava Yurin) Date: Mon, 07 Jan 2013 21:34:03 +0700 Subject: [erlang-questions] return supervisor:start_child In-Reply-To: <6E068760-9718-4E47-A8E0-EE96F6FA42FE@gmail.com> References: <88AECA2E-FF84-4D05-8112-995B5EF26303@gmail.com> <596531357568469@web11d.yandex.ru> <6E068760-9718-4E47-A8E0-EE96F6FA42FE@gmail.com> Message-ID: <1887891357569243@web20e.yandex.ru> An HTML attachment was scrubbed... URL: From ulf@REDACTED Mon Jan 7 16:36:08 2013 From: ulf@REDACTED (Ulf Wiger) Date: Mon, 7 Jan 2013 16:36:08 +0100 Subject: [erlang-questions] Environment variables for release In-Reply-To: References: Message-ID: <8784BC93-D120-4B83-9838-758F024B3BC3@feuerlabs.com> One suggestion: The application lib must be loaded before get_env() can work. BR, Ulf W On 7 Jan 2013, at 15:15, AD wrote: > Hello, > > I have a library being built that is leveraging environment variables. There is a line in the library include file that looks like > > -define(CONST, lib:get_env(Key,Default)). > > the lib:get_env function simply checks > > application:get_env(lib, Key) % in order to check the library.app first > and then > application:get_env(Key) % check for local overrides > > However when i place variables like the following in the main example.app file in ebin/ > > {application,example, > [{description,[]}, > {env,[{'COWBOY_HTTP_PORT',9090}]}, > ...... > > Nothing is getting read. I am not sure if this needs to be in rel/files/app.config instead? > > Appreciate any help here. > > -AD > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker.eriksson@REDACTED Mon Jan 7 17:26:09 2013 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Mon, 7 Jan 2013 17:26:09 +0100 Subject: [erlang-questions] Any tcp related changes in R15B* that might cause this? In-Reply-To: References: <20121212182632.GB72594@alumni.caltech.edu> <20121212234803.GA75710@alumni.caltech.edu> <20121213002455.GA75861@alumni.caltech.edu> <20121213183830.GA81730@alumni.caltech.edu> <20121214211117.GA86501@alumni.caltech.edu> <50CF35FF.6020101@erix.ericsson.se> <20130102172816.GA24637@alumni.caltech.edu> <20130103061626.GB26037@alumni.caltech.edu> Message-ID: <50EAF721.2020002@erix.ericsson.se> Thanks for the clarification, guys. I've look at dc5f7190 and it seems like the change in error handling was more or less intentional (by me). Old behavior was 1. Truncate a too long http line and return it as if it was ok. 2. Continue parsing rest of the line as if it were a new http line which probably (and hopefully) results in a http_error. I didn't like that; as it returned a partially parsed line as if it was ok, reported the error too late and confusing and also (I guess) constituted a security bug that could be abused to trick the http parsing with long lines. So I changed it to reject too long lines and return tcp_error, which is what happens for all packet protocols when the length of the packet is in some way invalid. The caller has to handle tcp_error's anyway, so it's a case of bad fault identification. I guess it would be nicer to return {http_error, "Line too long: X-Randomaaaaaaaaaaaaaaaaaa..."} or something like that. I don't have time to fix that now, but don't think it would be too hard do if anyone is eager... /Sverker, Erlang/OTP Steve Vinoski wrote: > Same results with this test: works on commits prior to dc5f7190, fails > on dc5f7190. > > --steve > > On Thu, Jan 3, 2013 at 1:16 AM, Anthony Molinaro < > anthonym@REDACTED> wrote: > > >> Attached is a test which shows the difference using only gen_tcp calls. >> >> Here's the output from both >> >> Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:2:2] [rq:2] >> [async-threads:0] >> [hipe] [kernel-poll:false] >> >> Eshell V5.8.5 (abort with ^G) >> 1> gen_tcp_test:test(1000). >> gen_tcp:send ok >> {{"HTTP/1.1",200,"OK"}, >> [{"date","Wed, 02 Jan 2013 21:01:08 GMT"}, >> {"server","Test"}, >> {"content-length","31"}, >> {"content-type","text/html"}], >> "Hello"} >> 2> gen_tcp_test:test(10000). >> http_error - R14 >> gen_tcp:send ok >> {{"HTTP/1.1",400,"Bad Request"}, >> [{"date","Wed, 02 Jan 2013 21:03:24 GMT"}, >> {"server","Test"}, >> {"content-length","0"}], >> []} >> 3> >> >> and for R15 >> >> Erlang R15B02 (erts-5.9.2) [source] [64-bit] [smp:2:2] [async-threads:0] >> [hipe] >> [kernel-poll:false] >> >> Eshell V5.9.2 (abort with ^G) >> 1> gen_tcp_test:test(1000). >> gen_tcp:send ok >> {{"HTTP/1.1",200,"OK"}, >> [{"date","Wed, 02 Jan 2013 21:01:08 GMT"}, >> {"server","Test"}, >> {"content-length","31"}, >> {"content-type","text/html"}], >> "Hello"} >> 2> gen_tcp_test:test(10000). >> emsgsize - R15 >> gen_tcp:send failed with {error,closed} >> socket_closed_remotely >> 3> >> >> Hope it helps, >> >> -Anthony >> >> On Wed, Jan 02, 2013 at 12:34:56PM -0500, Steve Vinoski wrote: >> >>> Hi Anthony and Sverker, as I mentioned in a previous email, using >>> >> Anthony's >> >>> test case a few weeks ago I bisected between R14B04 and HEAD and found >>> commit dc5f7190 to be the first commit where the test case fails. >>> >>> --steve >>> >>> On Wed, Jan 2, 2013 at 12:28 PM, Anthony Molinaro < >>> anthonym@REDACTED> wrote: >>> >>> >>>> Hi, >>>> >>>> The holidays went and interrupted everything, so I'm sorry about the >>>> late response. >>>> It's unclear if the commit dc5f7190 did it or not, but sometime between >>>> R14B04 and R15B02 the behavior did change. I've not isolated it >>>> >> outside >> >>>> of mochiweb, but I don't think its a mochiweb problem. >>>> >>>> Here's the pull request which contains the short program I used to >>>> reproduce with mochiweb (and work around the new behavior) >>>> >>>> https://github.com/mochi/mochiweb/pull/91 >>>> >>>> I'll see if I can't isolate it to just OTP sometime in the next >>>> couple of days. >>>> >>>> -Anthony >>>> >>>> On Mon, Dec 17, 2012 at 04:10:55PM +0100, Sverker Eriksson wrote: >>>> >>>>> Have I understood it correctly so far if I say that my commit >>>>> dc5f7190 seems to cause a >>>>> >>>>> {tcp_error,Port,emsgsize} >>>>> >>>>> while earlier versions caused a >>>>> >>>>> {http,Port,{http_error,"..."}} >>>>> >>>>> >>>>> for the same scenario with some sort of very long http lines? >>>>> >>>>> /Sverker, Erlang/OTP >>>>> >>>>> Anthony Molinaro wrote: >>>>> >>>>>> On Fri, Dec 14, 2012 at 11:32:11AM -0500, Steve Vinoski wrote: >>>>>> >>>>>>> Hi Anthony, based on your example, it looks like a follow-up commit >>>>>>> >>>> that >>>> >>>>>>> modified some of the changes introduced by my patch introduced the >>>>>>> >>>> issue >>>> >>>>>>> you're seeing: commit dc5f7190. You might want to report it over on >>>>>>> erlang-bugs. >>>>>>> >>>>>> Nice catch, I guess that it's actually not enough to return error >>>>>> for backward compatibility ;) >>>>>> >>>>>> I think the main thing I'm still not sure of is if the decode_packet >>>>>> >>>> changes >>>> >>>>>> are actually the cause. I was able to call decode_packet with long >>>>>> >>>> headers >>>> >>>>>> and not actually see an issue. >>>>>> >>>>>> This >>>>>> >>>>>> erlang:decode_packet ( httph, >>>>>> list_to_binary ([ "X-Random: ", >>>>>> [$a || _ <- >>>>>> >>>> lists:seq(1,10000)], >>>> >>>>>> "\r\n\r\n" >>>>>> ]), >>>>>> []). >>>>>> >>>>>> Returns the same thing in both R14B04 and R15B02. And as far as I >>>>>> >> am >> >>>> able >>>> >>>>>> to tell that is the only call made to decode_packet in mochiweb. >>>>>> >>>>>> I think the actual error is around recvbuf sizing (mochiweb uses >>>>>> >> 8192 as >> >>>>>> the default, so 10000 is definitely larger than that, however, the >>>>>> >>>> standard >>>> >>>>>> libraries must be doing something different as now it returns >>>>>> >> emsgsize >> >>>>>> where it did no in the past). I really wish there was a way to >>>>>> >> search >> >>>>>> commits on github as then I could search for recvbuf or something >>>>>> >> like >> >>>>>> that to see what might have changed. >>>>>> >>>>>> Before I go over to bugs I'll probably try to detangle mochiweb >>>>>> >> enough >> >>>>>> to create a small reproducible test case. >>>>>> >>>>>> I also have a pull request into mochiweb which prevents the crash >>>>>> >> but >> >>>>>> has the annoying behavior at the moment that it returns an error to >>>>>> >> the >> >>>>>> client about disconnecting version the 400 error it returned before. >>>>>> >>>>>> https://github.com/mochi/mochiweb/pull/91 >>>>>> >>>>>> But since the standard library seems to be the one closing the >>>>>> >> socket >> >>>>>> there's not much that can be done other than the fix I put in place. >>>>>> >>>>>> Thanks for your help Steve, >>>>>> >>>>>> -Anthony >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>> -- >>>> >>>> >> ------------------------------------------------------------------------ >> >>>> Anthony Molinaro < >>>> >> anthonym@REDACTED> >> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >> -- >> ------------------------------------------------------------------------ >> Anthony Molinaro >> >> > > From pan@REDACTED Mon Jan 7 18:31:07 2013 From: pan@REDACTED (Patrik Nyblom) Date: Mon, 7 Jan 2013 18:31:07 +0100 Subject: [erlang-questions] Working around the Windows firewall In-Reply-To: <00d001cde16a$9a795bc0$cf6c1340$@com> References: <00d001cde16a$9a795bc0$cf6c1340$@com> Message-ID: <50EB065B.1070602@erlang.org> On 12/24/2012 01:07 AM, Jeffrey Rennie wrote: > > Before I draft a formal EEP, > > Windows firewall is enabled by default, and blocks sockets used by > erlang. Yes, exceptions can be added to the firewall, however, this > is not possible in some situations. For example: > > 1. A corporate network with strict policies that prohibit opening > ports used by erlang. > > 2. An application written in erlang that installs without > administrator privileges. > > 3. (A generalization of the above) Whenever the user who wants to run > erlang is not an administrator. > > In these environments, an alternative to sockets which get entangled > in the firewall, is Win32 named pipes which do not get entangled in > the firewall. > > Therefore, I propose a change that will allow erlang nodes to > communicate over named pipes in addition to sockets. Of course, it > would be controlled by command-line parameters. > > I've spent a day browsing the erlang source code and it looks pretty > doable. > > Comments and questions please. > Good idea! There is actually no need to change anything in the Erlang VM to do that. The distribution mechanism is pluggable, so you can write a driver that uses any protocol where you can setup a stream of bytes between nodes (ok, that sounds easier than it really is, but it's absolutely doable). There is an example in the kernel source code ($ERL_TOP/lib/kernel/examples/uds_dist) where distribution is set up using Unix named pipes, which is of course more limited, but shows the general idea of how to implement a distribution driver. > P.S. It took me about 5 hours to successfully build on Windows; I had > most of the tools like Visual Studio and cygwin installed. I got > tripped up by git switching LFs to CRLFs, which chokes bash. Also, > it's much faster to just run vcvars32.bat and then run bash than to > write your own script that sets the vc environment variables. > Yes, it's a pain. The CRLF defaults of msysgit is also a pain. Using vcvars32 directly may definitely be a shortcut, maybe you could add some section to the windows readme about your approach? > > Cheers, /Patrik > > > _______________________________________________ > 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 Jan 7 18:35:29 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Mon, 07 Jan 2013 18:35:29 +0100 Subject: [erlang-questions] error_logger heap overflow In-Reply-To: <1357549286.2317.YahooMailNeo@web120706.mail.ne1.yahoo.com> References: <1353404860.96882.YahooMailNeo@web120706.mail.ne1.yahoo.com> <1353410937.92586.YahooMailNeo@web120706.mail.ne1.yahoo.com> <20121128064746.GE24714@hijacked.us> <1357549286.2317.YahooMailNeo@web120706.mail.ne1.yahoo.com> Message-ID: <50EB0761.1020001@ninenines.eu> On 01/07/2013 10:01 AM, Bogdan Andu wrote: > Sorry for delayed response. > > Unfortunately, I cannot use the work around presented because is experimental and the system is ready to be launched into production, so I cannot anymore switch back to lager, although is more heap overflow resistant than error_logger is. > > I stick with error_logger because errors are easier to read and I am accustomed with it. > > > log rotation is solved with newsyslog. > > > What makes lager's messages 'hard to read' is the lack of error formatting. > > > What I would expect from lager: > 1. lager:notice() send the message in /var/log/notice_log > lager:error() send the message in /var/log/error_log > lager:info() send the message in /va/log/info_log > 2. crash messages to appear only in /var/log/crash_log > 3. this sould be configurable > 4. more error formatting, like error_log has, in order to be easier to read > > > Why I want that? Because error has higher priority that notice, so all messages founded in /var/log/error_log are also founded in > /var/log/notice_log. I do not want duplicated error messages even if they are truncated. > > Bogdan > > > > > ----- Original Message ----- > From: Andrew Thompson > To: erlang-questions@REDACTED > Cc: Bogdan Andu > Sent: Wednesday, November 28, 2012 8:47 AM > Subject: Re: [erlang-questions] error_logger heap overflow > > On Tue, Nov 20, 2012 at 03:28:57AM -0800, Bogdan Andu wrote: >> I used that, lager, but it is hard to read error messages, and the errors are duplicated across all log files. >> >> One cannot say to lager: commit notice messages to /var/log/notice_log, because all error messages with higher prority get written there, too. > > I decided to tinker around this week in relation to this issue and came > up with this: > > https://github.com/basho/lager/pull/95 > > Does that address your concern on that front? > >> I like how error_logger prints the errors and I am used to it. >> >> Please give me an advice of how to overcome this situation. >> > > One thing you could do would be to fork the stdlib (or SASL) > error_logger gen_event handlers to use lager_format instead of io_lib > (lager_format is a fork of io_lib with size based truncation added to > avoid the OOM issues). The only downside to this is that lager_format > currently lacks the line-wrapping support ~p and friends have in io_lib, > so stacktraces, for example, end up on one big line rather than being > line wrapped nicely. > > Also, with regard to lager and formatting OTP errors, lager will try to > rewrite common OTP errors into more 'friendly' log messages, but it will > also write a truncated version of the original log format to the > 'crash.log', if more information is required. Recent lager allows you to do just that: https://github.com/basho/lager/pull/95 =debug - only the debug level Doesn't seem to be talked about in the README unfortunately. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From pan@REDACTED Mon Jan 7 18:53:02 2013 From: pan@REDACTED (Patrik Nyblom) Date: Mon, 7 Jan 2013 18:53:02 +0100 Subject: [erlang-questions] open_port returns enoent even when driver init function executes correctly. In-Reply-To: <00b601cdea2a$2c538710$84fa9530$@com> References: <008a01cde962$13dfe700$3b9fb500$@com> <00b601cdea2a$2c538710$84fa9530$@com> Message-ID: <50EB0B7E.9000400@erlang.org> Hi! You do not need to file a bug, I saw the error in the doc a few weeks ago and corrected it in master. It will be correct in R16. The port_driver.c code looks like this in master: --------------------- /* port_driver.c */ #include #include "erl_driver.h" typedef struct { ErlDrvPort port; } example_data; static ErlDrvData example_drv_start(ErlDrvPort port, char *buff) { example_data* d = (example_data*)driver_alloc(sizeof(example_data)); d->port = port; return (ErlDrvData)d; } static void example_drv_stop(ErlDrvData handle) { driver_free((char*)handle); } static void example_drv_output(ErlDrvData handle, char *buff, ErlDrvSizeT bufflen) { example_data* d = (example_data*)handle; char fn = buff[0], arg = buff[1], res; if (fn == 1) { res = foo(arg); } else if (fn == 2) { res = bar(arg); } driver_output(d->port, &res, 1); } ErlDrvEntry example_driver_entry = { NULL, /* F_PTR init, called when driver is loaded */ example_drv_start, /* L_PTR start, called when port is opened */ example_drv_stop, /* F_PTR stop, called when port is closed */ example_drv_output, /* F_PTR output, called when erlang has sent */ NULL, /* F_PTR ready_input, called when input descriptor ready */ NULL, /* F_PTR ready_output, called when output descriptor ready */ "example_drv", /* char *driver_name, the argument to open_port */ NULL, /* F_PTR finish, called when unloaded */ NULL, /* void *handle, Reserved by VM */ NULL, /* F_PTR control, port_command callback */ NULL, /* F_PTR timeout, reserved */ NULL, /* F_PTR outputv, reserved */ NULL, /* F_PTR ready_async, only for async drivers */ NULL, /* F_PTR flush, called when port is about to be closed, but there is data in driver queue */ NULL, /* F_PTR call, much like control, sync call to driver */ NULL, /* F_PTR event, called when an event selected by driver_event() occurs. */ ERL_DRV_EXTENDED_MARKER, /* int extended marker, Should always be set to indicate driver versioning */ ERL_DRV_EXTENDED_MAJOR_VERSION, /* int major_version, should always be set to this value */ ERL_DRV_EXTENDED_MINOR_VERSION, /* int minor_version, should always be set to this value */ 0, /* int driver_flags, see documentation */ NULL, /* void *handle2, reserved for VM use */ NULL, /* F_PTR process_exit, called when a monitored process dies */ NULL /* F_PTR stop_select, called to close an event object */ }; DRIVER_INIT(example_drv) /* must match name in driver_entry */ { return &example_driver_entry; } ------------------------------- Cheers, /Patrik On 01/04/2013 04:18 AM, Jeffrey Rennie wrote: > > Here's the first real clue. The example driver is being unloaded > before it's invoked! See below for the call stack of the unload. > > This must be either a bug in the documentation at > > http://www.erlang.org/doc/tutorial/c_portdriver.html > > or a bug in the erlang itself. > > What's the process for filing a bug? > > 0439f644 517572e2 example_drv!example_drv_finish(void)+0x1e > [c:\users\jeff\code\code\port_driver\port_driver.cpp @ 64] > > 0439f654 51757729 beam_smp!do_unload_driver_entry(struct DE_Handle * > dh = 0x00000000, unsigned long * save_name = 0x00000000)+0x72 > [c:\users\jeff\github\otp\erts\emulator\beam\erl_bif_ddll.c @ 1655] > > 0439f680 51797c2b beam_smp!ddll_no_more_references(void * vdh = > 0x517576d0)+0x59 > [c:\users\jeff\github\otp\erts\emulator\beam\erl_bif_ddll.c @ 1221] > > 0439f69c 5179b89f beam_smp!exec_misc_ops(struct ErtsRunQueue_ * rq = > 0x518c3b8c)+0x7b > [c:\users\jeff\github\otp\erts\emulator\beam\erl_process.c @ 7231] > > 0439f6c8 51801be7 beam_smp!schedule(struct process * p = 0x00000002, > int calls = 0)+0x5df > [c:\users\jeff\github\otp\erts\emulator\beam\erl_process.c @ 6891] > > 0439f6fc 7714c7c5 beam_smp!process_main+0x167 > > *From:*Robert Raschke [mailto:rtrlists@REDACTED] > *Sent:* Thursday, January 03, 2013 12:37 AM > *To:* SurferJeff > *Cc:* erlang-questions@REDACTED; erlang-programming@REDACTED > *Subject:* Re: [erlang-questions] open_port returns enoent even when > driver init function executes correctly. > > You can try running erl.exe with sasl enabled to get better error > messages. > > The messages you see at the moment are coming out interleaved, like in > the old joke "When faced with a problem you decide to use threading, > ..." :-) > > Robby > > On Jan 3, 2013 4:53 AM, "SurferJeff" > wrote: > > I found the recipe to build debug: > > $ cd $ERL_TOP > $ rm bin/win32/erlexec.dll > $ cd erts/emulator > $ make debug > $ cd ../etc > $ make debug > > And it succeeded. However, the next command in the recipe fails: > > jeff@REDACTED /cygdrive/c/Users/jeff/GitHub/otp > $ make local_setup > make[1]: Entering directory `/cygdrive/c/Users/jeff/GitHub/otp/erts' > make[2]: Entering directory > `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_script > s' > make[2]: Nothing to be done for `debug'. > make[2]: Leaving directory > `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_scripts > ' > ct_run.exe dialyzer.exe erl.ini erl_crash.dump escript.exe > run_test.exe typer.ex > e werl.exe win32 > make[2]: Entering directory > `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_script > s' > /usr/bin/install -c -d > /cygdrive/c/users/jeff/github/otp/erts/start_scripts/tmp > ( cd /cygdrive/c/users/jeff/github/otp/erts/start_scripts/tmp && \ > erlc -W -I/cygdrive/c/users/jeff/github/otp/lib/kernel/ebin > -I/cygdrive/c/use > rs/jeff/github/otp/lib/stdlib/ebin > -I/cygdrive/c/users/jeff/github/otp/lib/sasl/ > ebin +no_warn_sasl +otp_build -o > /cygdrive/c/users/jeff/github/otp/bin/start.scr > ipt /cygdrive/c/users/jeff/github/otp/erts/start_scripts/start_clean.rel ) > File not found: > "c:/cygdrive/c/users/jeff/github/otp/erts/start_scripts/start_cl > ean.rel" > Makefile:129: recipe for target > `/cygdrive/c/users/jeff/github/otp/bin/start.scr > ipt' failed > make[2]: *** [/cygdrive/c/users/jeff/github/otp/bin/start.script] Error 1 > make[2]: Leaving directory > `/cygdrive/c/Users/jeff/GitHub/otp/erts/start_scripts > ' > Makefile:69: recipe for target `local_setup' failed > make[1]: *** [local_setup] Error 2 > make[1]: Leaving directory `/cygdrive/c/Users/jeff/GitHub/otp/erts' > Makefile:883: recipe for target `local_setup' failed > make: *** [local_setup] Error 2 > > And now my erl.exe is completely hosed: > > jeff@REDACTED > /cygdrive/c/Users/jeff/GitHub/otp/bin/win32 > $ ./erl.exe > {(no error logger present"i)n ietr rtoerr: m"iEnrartoirn gi ni np > rdooc_ebsoost > "<,0{.b2a.d0a>r wgi,t[h{ eerxli_tp rviaml_uleo:a > d{ebra,dcahregc,k[_{feirlle__pr > reismu_llto,a3d,e[r{,fcihleec,k"_efrill_ep_rriems_ullota,d3er,[.{efrill"e},,\{"l > eirnle_,p28r3i}m]_}l,o{aidneirt.,egrelt\_"b}o,o{tl,i1n,e[,{2f8i3l}e,]"}i,n{iitn. > ite,rgle"t},_{bloionte,,178,5[}{]f}i,l{ei,n\i"ti,ngiett._ebrolo\t",}2,,{[l{ifnie > l,e7,8"5i}n]i}t,.{eirnli"t},,g{elti_nbeo,o77t2,}2]},,[{{ifniilte,,d\o"_ibnoiott. > ,e3r,l[\{"f}i,l{el,i"nien,i7t7.2e}r]l}",}{,i{nliitn,ed,o73_9b}o]o}t],}3}, > [{file,\"init.erl\"},{line,739}]}]}\n" > > Crash dump was written to: erl_crash.dump > init terminating in do_boot () > > > On Wednesday, January 2, 2013 7:26:09 PM UTC-8, SurferJeff wrote: > > I'm working through the example here: > http://www.erlang.org/doc/tutorial/c_portdriver.html > And I'm trying to get it to run on Windows. I reordered the code > in the C > source so that it compiles, and added a module.def file so that > erlang > actually finds and executes the driver init function. > > I attached a debugger. Walking back up the stack, I observe that: > The driver init function returns correctly. > erts_sys_ddll_call_init() returns correctly. > do_load_driver_entry() returns ERL_DE_NO_ERROR. > load_driver_entry() returns ERL_DE_NO_ERROR. > erl_ddll_try_load_3 returns t = TUPLE2(hp, am_ok, ok_term); on > line 417 of > erl_bif_ddl.c. > But the next higher call on the stack is _process_main(), which > was compiled > with gcc and has no debug symbols so I can't step through and > figure out why > the end result is: > > =ERROR REPORT==== 2-Jan-2013::19:14:22 === > Error in process <0.31.0> with exit value: > {enoent,[{erlang,open_port,[{spawn,"example_drv"},[]],[]},{complex5,init,1,[ > > {file,"c:/Users/jeff/code/code/port_driver/complex5.erl"},{line,19}]}]} > > > Has anyone seen this before? > > If not, how do I recompile erl.exe purely with cl.exe (no gcc) so > that it > generates debug symbols? And while I'm recompiling, how do I turn > off all > optimizations? I can read basic make files, but I get lost in the > configure > scripts and .in and .mk files. Please take pity on a Windows > programmer ;-) > > > _______________________________________________ > erlang-questions mailing list > 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 antoine.koener@REDACTED Mon Jan 7 21:33:52 2013 From: antoine.koener@REDACTED (Antoine Koener) Date: Mon, 7 Jan 2013 21:33:52 +0100 Subject: [erlang-questions] Working around the Windows firewall In-Reply-To: <50EB065B.1070602@erlang.org> References: <00d001cde16a$9a795bc0$cf6c1340$@com> <50EB065B.1070602@erlang.org> Message-ID: Just to share my small experience with uds_dist: last time I've checked, everything was fine but the distribution was not working at all. Pipes were OK, but the distribution wasn't. The problem seems to be related to some obscure flag in the structure. I think this code may have worked with old version of erlang < R13... On Mon, Jan 7, 2013 at 6:31 PM, Patrik Nyblom wrote: > On 12/24/2012 01:07 AM, Jeffrey Rennie wrote: > > Before I draft a formal EEP,**** > > ** ** > > Windows firewall is enabled by default, and blocks sockets used by > erlang. Yes, exceptions can be added to the firewall, however, this is not > possible in some situations. For example:**** > > 1. A corporate network with strict policies that prohibit opening ports > used by erlang.**** > > 2. An application written in erlang that installs without administrator > privileges.**** > > 3. (A generalization of the above) Whenever the user who wants to run > erlang is not an administrator.**** > > ** ** > > In these environments, an alternative to sockets which get entangled in > the firewall, is Win32 named pipes which do not get entangled in the > firewall.**** > > ** ** > > Therefore, I propose a change that will allow erlang nodes to communicate > over named pipes in addition to sockets. Of course, it would be controlled > by command-line parameters.**** > > ** ** > > I've spent a day browsing the erlang source code and it looks pretty > doable.**** > > ** ** > > Comments and questions please. > > > Good idea! There is actually no need to change anything in the Erlang VM > to do that. The distribution mechanism is pluggable, so you can write a > driver that uses any protocol where you can setup a stream of bytes between > nodes (ok, that sounds easier than it really is, but it's absolutely > doable). There is an example in the kernel source code > ($ERL_TOP/lib/kernel/examples/uds_dist) where distribution is set up using > Unix named pipes, which is of course more limited, but shows the general > idea of how to implement a distribution driver. > > **** > > ** ** > > P.S. It took me about 5 hours to successfully build on Windows; I had most > of the tools like Visual Studio and cygwin installed. I got tripped up by > git switching LFs to CRLFs, which chokes bash. Also, it's much faster to > just run vcvars32.bat and then run bash than to write your own script that > sets the vc environment variables.**** > > Yes, it's a pain. The CRLF defaults of msysgit is also a pain. Using > vcvars32 directly may definitely be a shortcut, maybe you could add some > section to the windows readme about your approach? > > ** ** > > Cheers, > /Patrik > > > _______________________________________________ > erlang-questions mailing listerlang-questions@REDACTED://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 simonstl@REDACTED Tue Jan 8 01:43:37 2013 From: simonstl@REDACTED (Simon St.Laurent) Date: Mon, 07 Jan 2013 19:43:37 -0500 Subject: [erlang-questions] further documentation for -spec directive? In-Reply-To: <50E99EB9.2010303@simonstl.com> References: <50E99EB9.2010303@simonstl.com> Message-ID: <50EB6BB9.4010400@simonstl.com> Hmmm... perhaps easier - Are there especially good examples of publicly available well-documented code that uses the -spec directive? Thanks, Simon On 1/6/13 10:56 AM, Simon St.Laurent wrote: > Is there more comprehensive (ideally tutorial) documentation for the > -spec directive than is available from: > > > > The examples there are minimal, and don't show, for example, results in > EDoc or other environments that rely on this information. > > If there isn't, I'll probably end up writing it, but I'd be happier if > someone else has already done it. > -- Simon St.Laurent http://simonstl.com/ From norton@REDACTED Tue Jan 8 02:06:16 2013 From: norton@REDACTED (=?utf-8?B?44OO44O844OI44OzIOOCuOODp+ODvOOCu+ODlSDjgqbjgqfjgqQg?= =?utf-8?B?44Oz?=) Date: Tue, 8 Jan 2013 10:06:16 +0900 Subject: [erlang-questions] further documentation for -spec directive? In-Reply-To: <50EB6BB9.4010400@simonstl.com> References: <50E99EB9.2010303@simonstl.com> <50EB6BB9.4010400@simonstl.com> Message-ID: Simon - These examples might be helpful to you (but no guarantee for the "goodness"): https://github.com/norton/gen-ets/blob/master/src/gen_ets.erl https://github.com/norton/lets/blob/master/src/lets.erl I'd also recommend using find and grep to search for the "-spec" directive in the Erlang/OTP code base itself. https://github.com/erlang/otp You should find plenty of examples. regards, Joe N. On Jan 8, 2013, at 09:43 , "Simon St.Laurent" wrote: > Hmmm... perhaps easier - > > Are there especially good examples of publicly available well-documented code that uses the -spec directive? > > Thanks, > Simon > > > On 1/6/13 10:56 AM, Simon St.Laurent wrote: >> Is there more comprehensive (ideally tutorial) documentation for the >> -spec directive than is available from: >> >> >> >> The examples there are minimal, and don't show, for example, results in >> EDoc or other environments that rely on this information. >> >> If there isn't, I'll probably end up writing it, but I'd be happier if >> someone else has already done it. >> > > > -- > Simon St.Laurent > http://simonstl.com/ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bourinov@REDACTED Tue Jan 8 06:17:06 2013 From: bourinov@REDACTED (Max Bourinov) Date: Tue, 8 Jan 2013 09:17:06 +0400 Subject: [erlang-questions] further documentation for -spec directive? In-Reply-To: References: <50E99EB9.2010303@simonstl.com> <50EB6BB9.4010400@simonstl.com> Message-ID: > > Simon - > > These examples might be helpful to you (but no guarantee for the > "goodness"): > > https://github.com/norton/gen-ets/blob/master/src/gen_ets.erl > https://github.com/norton/lets/blob/master/src/lets.erl > > I'd also recommend using find and grep to search for the "-spec" directive > in the Erlang/OTP code base itself. > > https://github.com/erlang/otp > > You should find plenty of examples. > > This is how I learned -spec directives. I thought that there is somewhere secret pdf that has full specification for -spec =) > regards, > > Joe N. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martynasp@REDACTED Tue Jan 8 09:21:41 2013 From: martynasp@REDACTED (Martynas Pumputis) Date: Tue, 8 Jan 2013 09:21:41 +0100 Subject: [erlang-questions] further documentation for -spec directive? In-Reply-To: References: <50E99EB9.2010303@simonstl.com> <50EB6BB9.4010400@simonstl.com> Message-ID: Chapter about Dialyzer in LYSE might be useful : http://learnyousomeerlang.com/dialyzer Martynas On Tue, Jan 8, 2013 at 6:17 AM, Max Bourinov wrote: > >> >> Simon - >> >> These examples might be helpful to you (but no guarantee for the >> "goodness"): >> >> https://github.com/norton/gen-ets/blob/master/src/gen_ets.erl >> https://github.com/norton/lets/blob/master/src/lets.erl >> >> I'd also recommend using find and grep to search for the "-spec" directive >> in the Erlang/OTP code base itself. >> >> https://github.com/erlang/otp >> >> You should find plenty of examples. >> > > This is how I learned -spec directives. I thought that there is somewhere > secret pdf that has full specification for -spec =) > >> >> regards, >> >> Joe N. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From maruthavanan_s@REDACTED Tue Jan 8 09:34:06 2013 From: maruthavanan_s@REDACTED (Maruthavanan Subbarayan) Date: Tue, 8 Jan 2013 03:34:06 -0500 Subject: [erlang-questions] Mnesia web interface Message-ID: Hi, I just wanted to know are there any other latest repositories or apps which can give me more information on mnesia web interfaces other than ymnesia from yaws and webnesia (https://github.com/tarpipe/webnesia) Thanks,Marutha -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard@REDACTED Tue Jan 8 10:32:55 2013 From: rickard@REDACTED (Rickard Green) Date: Tue, 8 Jan 2013 10:32:55 +0100 Subject: [erlang-questions] Why system_flag(scheduler_bind_type) is deprecated? In-Reply-To: <201301041254.46214.clist@uah.es> References: <20A107A4-ADA5-46F0-A473-FF9418DC211A@erlang.org> <201301041254.46214.clist@uah.es> Message-ID: <63435556-30BB-4682-8F4E-5E6C5FC6702B@erlang.org> The following is the idea of how it should work some time in the future. Note that this won't happen in R16, and that it has not implemented yet and may be subject to changes. When the runtime system boots, a fixed cpu-topology is set. The cpu-topology set is either automatically determined, or configured by the user on the command line. Schedulers are then bound to logical processors according to the bind type argument passed. This mapping between scheduler and logical processor will after this be fixed and will never change. This does, however, *not* mean that from this point on every logical processor must remain online. It will still be possible to take processors offline as well as online. The state of the scheduler mapped to a logical processor should normally follow the state of the logical processor. That is, when a processor is taken offline, so is its scheduler... The cpu-topology used should match the actual hardware topology of the machine when it is fully equipped, and the amount of schedulers started should equal the amount of logical processors in that cpu-topology. This way we will be able to handle reasonable changes of the cpu-topology while we will be able to have a fixed mapping between schedulers and logical processors. This fixed mapping is important since it simplifies implementations of things like better NUMA support, load-balancing that take cpu-topology into account, etc. My guess is that using this strategy we will be able to handle hot-plug, and power management scenarios on real hardware for quite some time whiteout running into trouble. As it is today, when cpu-topology and/or scheduler bind type is changed in runtime, the mapping between schedulers and logical processors can completely transform into something that looks nothing similar to what it was before. This unnecessarily complicates things a lot. I don't think that we will see hardware that can be physically transformed this way in the near future. When that happens we will just have to deal with it. Such transformations might perhaps occur in virtualized environments, but you don't want to bind schedulers if the cpu-topology doesn't match the actual physical hardware topology. This will just get more and more important as the runtime system utilize more information about the cpu-topology. Another scenario when you typically don't want to bind schedulers is when all schedulers aren't guaranteed to get the major part of the cpu time of the processors that they are bound to. We have in some cases seen severe performance degradation in such scenarios (which is why we do not bind schedulers by default anymore). In a virtualized environment it might also be hard to get such guarantees. Regards, Rickard Green, Erlang/OTP, Ericsson AB On Jan 4, 2013, at 12:54 PM, Angel J. Alvarez Miguel wrote: > hi > > I look a this : > > "...since we do not want to change this configuration in runtime..." > > This sounds a bit limiting > > Current platforms can (and will) shutdown CPU cores in response to power management policies > and erlang deamonized software must adapt to this changes without needing a restart. > > While it seems at first an unprobable scenario right now, on server side it really sounds good when > you run erlang on laptop/mobile platforms. > > Even some virtualization products are planin to use hot-plug facilities to make resource management easier on current > platforms so its not really crazy today to think that cpu cores will come and leave at unexpected times on tipical cloud scenarios. > > IMHO the ability to sense this on user code and facilities to control or alter the scheduler behaviour will be more important > in the near future , thus having to restart the entire VM for this seems overkill and a backward movement from the current setup. > > I have recently experimiented this during the summer case when i unplug my laptop my power management script > shut down half of the cores when battery starts to run out and lowers de cpu frecuency and erlang responded > on stderrr something about scheduler failure trying to bind to the dead cores, then i managed to make some tests trying to > monitor this from erlang code and to put schedulers offline until cores reapear again. > > Even i can depict scenarios where depending on licensing feaures application code can control the amount of paralelism > the VM will exhibit by tweaking schedulers affinity or just shutting them down to limit to the cores licensed... > > You should think about this even if you plan to make other improvements > > Regards, Angel > > On Jueves, 27 de Diciembre de 2012 00:45:05 Rickard Green escribi?: >> On Dec 26, 2012, at 5:21 PM, Max Lapshin wrote: >>> Why system_flag(scheduler_bind_type, How) is deprecated in favor of +sbt >>> flag? >>> >>> This sbt flag is different when I have to launch via escript or via erl >>> and this is why it is less convenient than using system_flag call. >>> >>> Also system_flag call can be called according to some system >>> configuration file and sbt needs full restart. >> >> Both the 'cpu_topology' and the 'scheduler_bind_type' arguments of the >> system_flag/2 BIF are deprecated and will be removed since we do not want >> to change this configuration in runtime. With the support for this we got >> today the runtime configuration change isn't that problematic, but it >> prevents future planned improvements from being implemented. >> >> Regards, >> Rickard Green, Erlang/OTP, Ericsson AB >> _______________________________________________ >> erlang-questions mailing list >> 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 erlangsiri@REDACTED Tue Jan 8 11:39:49 2013 From: erlangsiri@REDACTED (Siri Hansen) Date: Tue, 8 Jan 2013 11:39:49 +0100 Subject: [erlang-questions] Erlang application distribution In-Reply-To: References: Message-ID: Hi - this is the expected behavior of distributed applications. The supervision is based on monitoring nodes and detecting nodedown messages. Regards siri 2013/1/3 Varatharaja Kajamugan > Hi, > > I have tested a distributed test application between 2 nodes (test_p and > test_s). > > test_p is primary node and test_s is secondary. > > When i stop test_p node, start(failover, Args) was called in test_s node. > > But when i stop only the test application in test_p node without stopping > the node, start(failover, Args) was not called in test_s node. > > is that the behavior of erlang kernel distribution. if not can u guys > please help me on this. > > my kernel configuration is below : > {kernel, > [{distributed, > [ > {reduce_test, 5000, [test_p@REDACTED, test_s@REDACTED]} > ]}, > {sync_nodes_optional, [test_p@REDACTED, test_s@REDACTED]}, > {sync_nodes_timeout, 5000}, > {start_dist_ac, true} > ]} > > Thanks > Kajan. > > _______________________________________________ > 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 Tue Jan 8 12:04:00 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Tue, 8 Jan 2013 14:04:00 +0300 Subject: [erlang-questions] Why system_flag(scheduler_bind_type) is deprecated? In-Reply-To: <63435556-30BB-4682-8F4E-5E6C5FC6702B@erlang.org> References: <20A107A4-ADA5-46F0-A473-FF9418DC211A@erlang.org> <201301041254.46214.clist@uah.es> <63435556-30BB-4682-8F4E-5E6C5FC6702B@erlang.org> Message-ID: Ok, Rickard. I see that you have to deal with much more complicated cases that I have. But current situation with flags and system_flag makes almost impossible to distribute software than _needs_ spreading of tasks. If erlyvideo is launched without +sbt spread flag, it looses packets from UDP because too many tasks are on one core. There are some erlang distributions (OS X, ubuntu package, some others) that are just halting if you pass +sbt flag. So I can't write proper init script that passes this flag or don't pass. This is my problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Tue Jan 8 12:08:41 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 8 Jan 2013 12:08:41 +0100 Subject: [erlang-questions] Why system_flag(scheduler_bind_type) is deprecated? In-Reply-To: References: <20A107A4-ADA5-46F0-A473-FF9418DC211A@erlang.org> <201301041254.46214.clist@uah.es> <63435556-30BB-4682-8F4E-5E6C5FC6702B@erlang.org> Message-ID: On Jan 8, 2013, at 12:04 PM, Max Lapshin wrote: > If erlyvideo is launched without +sbt spread flag, it looses packets from UDP because too many tasks are on one core. > There are some erlang distributions (OS X, ubuntu package, some others) that are just halting if you pass +sbt flag. > So I can't write proper init script that passes this flag or don't pass. I think Rickard already said he would implement a "silent failure" flag for this, so you could do something like erl +sbt db +sbt-ignore-failure and have it work on, say, OSX because it would silently disable the flag. As you say, +sbt has too much of an impact in the real world to be ignored for certain types of load, so I still like the default of refusing to start if the bind type can't be satisfied. Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen From erlangsiri@REDACTED Tue Jan 8 12:17:44 2013 From: erlangsiri@REDACTED (Siri Hansen) Date: Tue, 8 Jan 2013 12:17:44 +0100 Subject: [erlang-questions] Including erl_call in the release tarball In-Reply-To: References: Message-ID: Hi Michael! 2013/1/4 Micha? Ptaszek > > PS: Nonetheless, it would be really nice to know if there is an easy way > to ship the original erl_call together with the release. > > I don't know if there is some rebar magic that can do this, but from the release_handler/reltool point of view it is, unfortunately, not possible to do this automatically by configuration. However, if you were to copy the file to the top level bin directory before creating the release I think it would work - unless you have archive filters (in your reltool config) preventing it. And we do have a ticket on reltool to make it possible to include non-otp applications - it just hasn't got the "right" priority yet :( A contribution would of course speed up the matter... :) Regards siri@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Tue Jan 8 12:20:28 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Tue, 8 Jan 2013 14:20:28 +0300 Subject: [erlang-questions] Why system_flag(scheduler_bind_type) is deprecated? In-Reply-To: References: <20A107A4-ADA5-46F0-A473-FF9418DC211A@erlang.org> <201301041254.46214.clist@uah.es> <63435556-30BB-4682-8F4E-5E6C5FC6702B@erlang.org> Message-ID: > > I think Rickard already said he would implement a "silent failure" flag > for this, so you could do something like > > erl +sbt db +sbt-ignore-failure > > and have it work on, say, OSX because it would silently disable the flag. > As you say, +sbt has too much of an impact in the real world to be ignored > for certain types of load, so I still like the default of refusing to start > if the bind type can't be satisfied. > > No, you are wrong with it. There are problems with capturing 100 Mbit/s and more via UDP. This feature is required by 1% of users. What for to disable erlyvideo for other 99% of users? scheduler binding is a performance setting, system should be gracefully degraded in case of lacking it. No -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Tue Jan 8 12:41:36 2013 From: tony@REDACTED (Tony Rogvall) Date: Tue, 8 Jan 2013 12:41:36 +0100 Subject: [erlang-questions] openCL darwin 64 Message-ID: Hi! Found a workaround for cl (https://github.com/tonyrog/cl) not starting on erlang 64-bit mac os x The fix is to add "-framework Foundation" to LIBCARBON in erts/configure.in --- Like this --- case $ARCH-$OPSYS in amd64-darwin*) LIBCARBON="-framework Foundation" AC_MSG_RESULT([no]) ;; *-darwin*) LIBCARBON="-framework Carbon -framework Foundation" AC_MSG_RESULT([yes]) ;; -- Any chans that this might be fixed in a future release ? /Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From chandrashekhar.mullaparthi@REDACTED Tue Jan 8 13:02:07 2013 From: chandrashekhar.mullaparthi@REDACTED (Chandru) Date: Tue, 8 Jan 2013 12:02:07 +0000 Subject: [erlang-questions] [Job] System testers Message-ID: Hi all, I run a software development team at EE (based in Hatfield, UK) and I have a couple of contracting positions open for testing of some our internally developed systems. I'm looking for a person who has the diligence of a tester, but is comfortable writing code to develop stubs and simulators. Experience with load testing is a big plus. Each position is for 6 months. Please get in touch if you are interested. regards, Chandru From clist@REDACTED Tue Jan 8 13:04:01 2013 From: clist@REDACTED (Angel J. Alvarez Miguel) Date: Tue, 8 Jan 2013 13:04:01 +0100 Subject: [erlang-questions] Why system_flag(scheduler_bind_type) is deprecated? In-Reply-To: References: Message-ID: <201301081304.02164.clist@uah.es> On Martes, 8 de Enero de 2013 12:08:41 Jesper Louis Andersen escribi?: > On Jan 8, 2013, at 12:04 PM, Max Lapshin wrote: > > If erlyvideo is launched without +sbt spread flag, it looses packets from > > UDP because too many tasks are on one core. There are some erlang > > distributions (OS X, ubuntu package, some others) that are just halting > > if you pass +sbt flag. So I can't write proper init script that passes > > this flag or don't pass. > > I think Rickard already said he would implement a "silent failure" flag for > this, so you could do something like > > erl +sbt db +sbt-ignore-failure This seems to be a good falloff, here we use scritptized rebars deployments for our projects and this fits very well to be included in the escript_emu_args variable... provided the user cant change default vm args per se > > and have it work on, say, OSX because it would silently disable the flag. > As you say, +sbt has too much of an impact in the real world to be ignored > for certain types of load, so I still like the default of refusing to > start if the bind type can't be satisfied. > > Jesper Louis Andersen > Erlang Solutions Ltd., Copenhagen > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From essen@REDACTED Tue Jan 8 13:25:33 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 08 Jan 2013 13:25:33 +0100 Subject: [erlang-questions] Including erl_call in the release tarball In-Reply-To: References: Message-ID: <50EC103D.4070303@ninenines.eu> On 01/08/2013 12:17 PM, Siri Hansen wrote: > Hi Michael! > > 2013/1/4 Micha? Ptaszek > > > > PS: Nonetheless, it would be really nice to know if there is an easy > way to ship the original erl_call together with the release. > > > I don't know if there is some rebar magic that can do this, but from the > release_handler/reltool point of view it is, unfortunately, not possible > to do this automatically by configuration. However, if you were to copy > the file to the top level bin directory before creating the release I > think it would work - unless you have archive filters (in your reltool > config) preventing it. > > And we do have a ticket on reltool to make it possible to include > non-otp applications - it just hasn't got the "right" priority yet :( A > contribution would of course speed up the matter... :) Isn't that what overlays are for? -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From simonstl@REDACTED Tue Jan 8 13:30:56 2013 From: simonstl@REDACTED (Simon St.Laurent) Date: Tue, 08 Jan 2013 07:30:56 -0500 Subject: [erlang-questions] further documentation for -spec directive? In-Reply-To: References: <50E99EB9.2010303@simonstl.com> <50EB6BB9.4010400@simonstl.com> Message-ID: <50EC1180.7040204@simonstl.com> On 1/8/13 3:21 AM, Martynas Pumputis wrote: > Chapter about Dialyzer in LYSE might be useful : > http://learnyousomeerlang.com/dialyzer Thanks - I'd seen the earlier chapter about types but hadn't realized he continued later in the book. That's much better than anything else I've found. Thank you! -- Simon St.Laurent http://simonstl.com/ From rickard@REDACTED Tue Jan 8 13:57:49 2013 From: rickard@REDACTED (Rickard Green) Date: Tue, 8 Jan 2013 13:57:49 +0100 Subject: [erlang-questions] Why system_flag(scheduler_bind_type) is deprecated? In-Reply-To: <201301081304.02164.clist@uah.es> References: <201301081304.02164.clist@uah.es> Message-ID: On Jan 8, 2013, at 1:04 PM, "Angel J. Alvarez Miguel" wrote: > On Martes, 8 de Enero de 2013 12:08:41 Jesper Louis Andersen escribi?: >> On Jan 8, 2013, at 12:04 PM, Max Lapshin wrote: >>> If erlyvideo is launched without +sbt spread flag, it looses packets from >>> UDP because too many tasks are on one core. There are some erlang >>> distributions (OS X, ubuntu package, some others) that are just halting >>> if you pass +sbt flag. So I can't write proper init script that passes >>> this flag or don't pass. >> >> I think Rickard already said he would implement a "silent failure" flag for >> this, so you could do something like >> >> erl +sbt db +sat-ignore-failure > > This seems to be a good falloff, here we use scritptized rebars deployments > for our projects and this fits very well to be included in the > escript_emu_args variable... provided the user cant change default vm args per > se > >> >> and have it work on, say, OSX because it would silently disable the flag. >> As you say, +sbt has too much of an impact in the real world to be ignored >> for certain types of load, so I still like the default of refusing to >> start if the bind type can't be satisfied. >> >> Jesper Louis Andersen >> Erlang Solutions Ltd., Copenhagen >> I'll add an +stbt ("try bind type") switch that will do the same thing as +sbt, but if it fails this will silently be ignored and the runtime will be started anyway. I can add the +stbt switch to r16. The change will be quite simple, so I guess that it should be quite easy to apply the change on the r15b03 source if you want to. Regarding support for automatic detection of cpu-topology and binding of schedulers. I think this is an area really suitable for user contributions. Since the APIs that need to be used often differ between OSes and sometimes also between hardware architectures on the same OS, we will never have the time to implement support for this on all platforms users are interested in. Therefore, user contributions implementing this on various platforms are much appreciated (other contributions are of course also appreciated). If +sbt fails on a newer Linux, the problem is most likely that no cpu-topology were automatically detected. On Linux, the runtime tries to detect this by inspecting the /sys filesystem. The content under /sys/devices/system/{cpu,node} varies quite a lot depending on hw arch. Sometimes there aren't enough info there to determine the topology, but it could also be that the information is just formatted another way than we expected. Detection of cpu-topology and binding of threads to logical processors are implemented in $ERL_TOP/erts/lib_src/common/erl_misc_utils.c Regards, Rickard Green, Erlang/OTP, Ericsson AB From bchesneau@REDACTED Tue Jan 8 14:03:50 2013 From: bchesneau@REDACTED (Benoit Chesneau) Date: Tue, 8 Jan 2013 14:03:50 +0100 Subject: [erlang-questions] folsom + statsd/graphite ? Message-ID: Does anyone know a good project handling both at the same time? Or rather I'm looking for a tool that would allows me to display in realtime on the web some statistics/counters from an erlang application while archiving them in graphite. Any idea ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mabrek@REDACTED Tue Jan 8 14:40:45 2013 From: mabrek@REDACTED (Anton Lebedevich) Date: Tue, 08 Jan 2013 17:40:45 +0400 Subject: [erlang-questions] folsom + statsd/graphite ? In-Reply-To: References: Message-ID: <50EC21DD.5050601@gmail.com> On 01/08/2013 05:03 PM, Benoit Chesneau wrote: > Does anyone know a good project handling both at the same time? > > > Or rather I'm looking for a tool that would allows me to display in > realtime on the web some statistics/counters from an erlang application > while archiving them in graphite. > > > Any idea ? Both folsom and statsd do their own aggregation/sampling of metrics which could lead to confusion. There is a simpler approach: https://github.com/ferd/vmstats for gathering beam vm metrics and https://github.com/lpgauth/statsderl for sending metrics to statsd. Regards, Anton Lebedevich. From max.lapshin@REDACTED Tue Jan 8 14:57:32 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Tue, 8 Jan 2013 16:57:32 +0300 Subject: [erlang-questions] Why system_flag(scheduler_bind_type) is deprecated? In-Reply-To: References: <201301081304.02164.clist@uah.es> Message-ID: Ok. Thank you for +stbt -------------- next part -------------- An HTML attachment was scrubbed... URL: From emmiller@REDACTED Tue Jan 8 16:54:57 2013 From: emmiller@REDACTED (Evan Miller) Date: Tue, 8 Jan 2013 09:54:57 -0600 Subject: [erlang-questions] openCL darwin 64 In-Reply-To: References: Message-ID: +1 for this issue. OpenCL is an excellent complement to Erlang when it comes to high performance numerical computing. On Tue, Jan 8, 2013 at 5:41 AM, Tony Rogvall wrote: > Hi! > > Found a workaround for cl (https://github.com/tonyrog/cl) not starting on > erlang 64-bit mac os x > The fix is to add "-framework Foundation" to LIBCARBON in erts/ > configure.in > > --- Like this --- > case $ARCH-$OPSYS in > amd64-darwin*) > LIBCARBON="-framework Foundation" > AC_MSG_RESULT([no]) > ;; > *-darwin*) > LIBCARBON="-framework Carbon -framework Foundation" > AC_MSG_RESULT([yes]) > ;; > -- > > Any chans that this might be fixed in a future release ? > > > /Tony > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Evan Miller http://www.evanmiller.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthonym@REDACTED Tue Jan 8 17:42:31 2013 From: anthonym@REDACTED (Anthony Molinaro) Date: Tue, 8 Jan 2013 08:42:31 -0800 Subject: [erlang-questions] Any tcp related changes in R15B* that might cause this? In-Reply-To: <50EAF721.2020002@erix.ericsson.se> References: <20121213183830.GA81730@alumni.caltech.edu> <20121214211117.GA86501@alumni.caltech.edu> <50CF35FF.6020101@erix.ericsson.se> <20130102172816.GA24637@alumni.caltech.edu> <20130103061626.GB26037@alumni.caltech.edu> <50EAF721.2020002@erix.ericsson.se> Message-ID: <20130108164231.GA40748@alumni.caltech.edu> I agree that the new behavior of returning an emsgsize tcp_error is probably correct, however the new behavior also closes the socket. Before your changes mochiweb and my test could return a 400 error so the client would get a response even if they were sending in a bad request. After the change the client just gets a remote side closed connection message. So I guess the question is, why is the connection being closed? Is that also something the other packet protocols do? Thanks for looking at it, -Anthony On Mon, Jan 07, 2013 at 05:26:09PM +0100, Sverker Eriksson wrote: > Thanks for the clarification, guys. > I've look at dc5f7190 and it seems like the change in error > handling was more or less intentional (by me). > > Old behavior was > 1. Truncate a too long http line and return it as if it was ok. > 2. Continue parsing rest of the line as if it were a new http line > which probably (and hopefully) results in a http_error. > > I didn't like that; as it returned a partially parsed line as if it > was ok, reported the error too late and confusing and also (I guess) > constituted a security bug that could be abused to trick the http > parsing with long lines. > > So I changed it to reject too long lines and return tcp_error, which > is what happens for all packet protocols when the length of the > packet is in some way invalid. > > The caller has to handle tcp_error's anyway, so it's a case of bad > fault identification. > I guess it would be nicer to return {http_error, "Line too long: > X-Randomaaaaaaaaaaaaaaaaaa..."} > or something like that. > I don't have time to fix that now, but don't think it would be too > hard do if anyone is eager... > > > /Sverker, Erlang/OTP > > > > Steve Vinoski wrote: > >Same results with this test: works on commits prior to dc5f7190, fails > >on dc5f7190. > > > >--steve > > > >On Thu, Jan 3, 2013 at 1:16 AM, Anthony Molinaro < > >anthonym@REDACTED> wrote: > > > >>Attached is a test which shows the difference using only gen_tcp calls. > >> > >>Here's the output from both > >> > >>Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:2:2] [rq:2] > >>[async-threads:0] > >>[hipe] [kernel-poll:false] > >> > >>Eshell V5.8.5 (abort with ^G) > >>1> gen_tcp_test:test(1000). > >>gen_tcp:send ok > >>{{"HTTP/1.1",200,"OK"}, > >> [{"date","Wed, 02 Jan 2013 21:01:08 GMT"}, > >> {"server","Test"}, > >> {"content-length","31"}, > >> {"content-type","text/html"}], > >> "Hello"} > >>2> gen_tcp_test:test(10000). > >>http_error - R14 > >>gen_tcp:send ok > >>{{"HTTP/1.1",400,"Bad Request"}, > >> [{"date","Wed, 02 Jan 2013 21:03:24 GMT"}, > >> {"server","Test"}, > >> {"content-length","0"}], > >> []} > >>3> > >> > >>and for R15 > >> > >>Erlang R15B02 (erts-5.9.2) [source] [64-bit] [smp:2:2] [async-threads:0] > >>[hipe] > >>[kernel-poll:false] > >> > >>Eshell V5.9.2 (abort with ^G) > >>1> gen_tcp_test:test(1000). > >>gen_tcp:send ok > >>{{"HTTP/1.1",200,"OK"}, > >> [{"date","Wed, 02 Jan 2013 21:01:08 GMT"}, > >> {"server","Test"}, > >> {"content-length","31"}, > >> {"content-type","text/html"}], > >> "Hello"} > >>2> gen_tcp_test:test(10000). > >>emsgsize - R15 > >>gen_tcp:send failed with {error,closed} > >>socket_closed_remotely > >>3> > >> > >>Hope it helps, > >> > >>-Anthony > >> > >>On Wed, Jan 02, 2013 at 12:34:56PM -0500, Steve Vinoski wrote: > >>>Hi Anthony and Sverker, as I mentioned in a previous email, using > >>Anthony's > >>>test case a few weeks ago I bisected between R14B04 and HEAD and found > >>>commit dc5f7190 to be the first commit where the test case fails. > >>> > >>>--steve > >>> > >>>On Wed, Jan 2, 2013 at 12:28 PM, Anthony Molinaro < > >>>anthonym@REDACTED> wrote: > >>> > >>>>Hi, > >>>> > >>>> The holidays went and interrupted everything, so I'm sorry about the > >>>>late response. > >>>>It's unclear if the commit dc5f7190 did it or not, but sometime between > >>>>R14B04 and R15B02 the behavior did change. I've not isolated it > >>outside > >>>>of mochiweb, but I don't think its a mochiweb problem. > >>>> > >>>>Here's the pull request which contains the short program I used to > >>>>reproduce with mochiweb (and work around the new behavior) > >>>> > >>>>https://github.com/mochi/mochiweb/pull/91 > >>>> > >>>>I'll see if I can't isolate it to just OTP sometime in the next > >>>>couple of days. > >>>> > >>>>-Anthony > >>>> > >>>>On Mon, Dec 17, 2012 at 04:10:55PM +0100, Sverker Eriksson wrote: > >>>>>Have I understood it correctly so far if I say that my commit > >>>>>dc5f7190 seems to cause a > >>>>> > >>>>>{tcp_error,Port,emsgsize} > >>>>> > >>>>>while earlier versions caused a > >>>>> > >>>>>{http,Port,{http_error,"..."}} > >>>>> > >>>>> > >>>>>for the same scenario with some sort of very long http lines? > >>>>> > >>>>>/Sverker, Erlang/OTP > >>>>> > >>>>>Anthony Molinaro wrote: > >>>>>>On Fri, Dec 14, 2012 at 11:32:11AM -0500, Steve Vinoski wrote: > >>>>>>>Hi Anthony, based on your example, it looks like a follow-up commit > >>>>that > >>>>>>>modified some of the changes introduced by my patch introduced the > >>>>issue > >>>>>>>you're seeing: commit dc5f7190. You might want to report it over on > >>>>>>>erlang-bugs. > >>>>>>Nice catch, I guess that it's actually not enough to return error > >>>>>>for backward compatibility ;) > >>>>>> > >>>>>>I think the main thing I'm still not sure of is if the decode_packet > >>>>changes > >>>>>>are actually the cause. I was able to call decode_packet with long > >>>>headers > >>>>>>and not actually see an issue. > >>>>>> > >>>>>>This > >>>>>> > >>>>>>erlang:decode_packet ( httph, > >>>>>> list_to_binary ([ "X-Random: ", > >>>>>> [$a || _ <- > >>>>lists:seq(1,10000)], > >>>>>> "\r\n\r\n" > >>>>>> ]), > >>>>>> []). > >>>>>> > >>>>>>Returns the same thing in both R14B04 and R15B02. And as far as I > >>am > >>>>able > >>>>>>to tell that is the only call made to decode_packet in mochiweb. > >>>>>> > >>>>>>I think the actual error is around recvbuf sizing (mochiweb uses > >>8192 as > >>>>>>the default, so 10000 is definitely larger than that, however, the > >>>>standard > >>>>>>libraries must be doing something different as now it returns > >>emsgsize > >>>>>>where it did no in the past). I really wish there was a way to > >>search > >>>>>>commits on github as then I could search for recvbuf or something > >>like > >>>>>>that to see what might have changed. > >>>>>> > >>>>>>Before I go over to bugs I'll probably try to detangle mochiweb > >>enough > >>>>>>to create a small reproducible test case. > >>>>>> > >>>>>>I also have a pull request into mochiweb which prevents the crash > >>but > >>>>>>has the annoying behavior at the moment that it returns an error to > >>the > >>>>>>client about disconnecting version the 400 error it returned before. > >>>>>> > >>>>>>https://github.com/mochi/mochiweb/pull/91 > >>>>>> > >>>>>>But since the standard library seems to be the one closing the > >>socket > >>>>>>there's not much that can be done other than the fix I put in place. > >>>>>> > >>>>>>Thanks for your help Steve, > >>>>>> > >>>>>>-Anthony > >>>>>> > >>>>>_______________________________________________ > >>>>>erlang-questions mailing list > >>>>>erlang-questions@REDACTED > >>>>>http://erlang.org/mailman/listinfo/erlang-questions > >>>>-- > >>>> > >>------------------------------------------------------------------------ > >>>>Anthony Molinaro < > >>anthonym@REDACTED> > >>>>_______________________________________________ > >>>>erlang-questions mailing list > >>>>erlang-questions@REDACTED > >>>>http://erlang.org/mailman/listinfo/erlang-questions > >>>> > >>-- > >>------------------------------------------------------------------------ > >>Anthony Molinaro > >> > > > -- ------------------------------------------------------------------------ Anthony Molinaro From sverker.eriksson@REDACTED Tue Jan 8 19:46:43 2013 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Tue, 8 Jan 2013 19:46:43 +0100 Subject: [erlang-questions] Any tcp related changes in R15B* that might cause this? In-Reply-To: <20130108164231.GA40748@alumni.caltech.edu> References: <20121213183830.GA81730@alumni.caltech.edu> <20121214211117.GA86501@alumni.caltech.edu> <50CF35FF.6020101@erix.ericsson.se> <20130102172816.GA24637@alumni.caltech.edu> <20130103061626.GB26037@alumni.caltech.edu> <50EAF721.2020002@erix.ericsson.se> <20130108164231.GA40748@alumni.caltech.edu> Message-ID: <50EC6993.9000608@erix.ericsson.se> Anthony Molinaro wrote: > I agree that the new behavior of returning an emsgsize tcp_error is > probably correct, however the new behavior also closes the socket. > > Before your changes mochiweb and my test could return a 400 error so > the client would get a response even if they were sending in a bad > request. After the change the client just gets a remote side closed > connection message. > > So I guess the question is, why is the connection being closed? Is > that also something the other packet protocols do? > > Yes all packets protocols act the same in this sense. You can use socket option {exit_on_close, false} to only do a half-close and still allow writing to the socket. /Sverker > Thanks for looking at it, > > -Anthony > > On Mon, Jan 07, 2013 at 05:26:09PM +0100, Sverker Eriksson wrote: > >> Thanks for the clarification, guys. >> I've look at dc5f7190 and it seems like the change in error >> handling was more or less intentional (by me). >> >> Old behavior was >> 1. Truncate a too long http line and return it as if it was ok. >> 2. Continue parsing rest of the line as if it were a new http line >> which probably (and hopefully) results in a http_error. >> >> I didn't like that; as it returned a partially parsed line as if it >> was ok, reported the error too late and confusing and also (I guess) >> constituted a security bug that could be abused to trick the http >> parsing with long lines. >> >> So I changed it to reject too long lines and return tcp_error, which >> is what happens for all packet protocols when the length of the >> packet is in some way invalid. >> >> The caller has to handle tcp_error's anyway, so it's a case of bad >> fault identification. >> I guess it would be nicer to return {http_error, "Line too long: >> X-Randomaaaaaaaaaaaaaaaaaa..."} >> or something like that. >> I don't have time to fix that now, but don't think it would be too >> hard do if anyone is eager... >> >> >> /Sverker, Erlang/OTP >> >> >> >> Steve Vinoski wrote: >> >>> Same results with this test: works on commits prior to dc5f7190, fails >>> on dc5f7190. >>> >>> --steve >>> >>> On Thu, Jan 3, 2013 at 1:16 AM, Anthony Molinaro < >>> anthonym@REDACTED> wrote: >>> >>> >>>> Attached is a test which shows the difference using only gen_tcp calls. >>>> >>>> Here's the output from both >>>> >>>> Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:2:2] [rq:2] >>>> [async-threads:0] >>>> [hipe] [kernel-poll:false] >>>> >>>> Eshell V5.8.5 (abort with ^G) >>>> 1> gen_tcp_test:test(1000). >>>> gen_tcp:send ok >>>> {{"HTTP/1.1",200,"OK"}, >>>> [{"date","Wed, 02 Jan 2013 21:01:08 GMT"}, >>>> {"server","Test"}, >>>> {"content-length","31"}, >>>> {"content-type","text/html"}], >>>> "Hello"} >>>> 2> gen_tcp_test:test(10000). >>>> http_error - R14 >>>> gen_tcp:send ok >>>> {{"HTTP/1.1",400,"Bad Request"}, >>>> [{"date","Wed, 02 Jan 2013 21:03:24 GMT"}, >>>> {"server","Test"}, >>>> {"content-length","0"}], >>>> []} >>>> 3> >>>> >>>> and for R15 >>>> >>>> Erlang R15B02 (erts-5.9.2) [source] [64-bit] [smp:2:2] [async-threads:0] >>>> [hipe] >>>> [kernel-poll:false] >>>> >>>> Eshell V5.9.2 (abort with ^G) >>>> 1> gen_tcp_test:test(1000). >>>> gen_tcp:send ok >>>> {{"HTTP/1.1",200,"OK"}, >>>> [{"date","Wed, 02 Jan 2013 21:01:08 GMT"}, >>>> {"server","Test"}, >>>> {"content-length","31"}, >>>> {"content-type","text/html"}], >>>> "Hello"} >>>> 2> gen_tcp_test:test(10000). >>>> emsgsize - R15 >>>> gen_tcp:send failed with {error,closed} >>>> socket_closed_remotely >>>> 3> >>>> >>>> Hope it helps, >>>> >>>> -Anthony >>>> >>>> On Wed, Jan 02, 2013 at 12:34:56PM -0500, Steve Vinoski wrote: >>>> >>>>> Hi Anthony and Sverker, as I mentioned in a previous email, using >>>>> >>>> Anthony's >>>> >>>>> test case a few weeks ago I bisected between R14B04 and HEAD and found >>>>> commit dc5f7190 to be the first commit where the test case fails. >>>>> >>>>> --steve >>>>> >>>>> On Wed, Jan 2, 2013 at 12:28 PM, Anthony Molinaro < >>>>> anthonym@REDACTED> wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> The holidays went and interrupted everything, so I'm sorry about the >>>>>> late response. >>>>>> It's unclear if the commit dc5f7190 did it or not, but sometime between >>>>>> R14B04 and R15B02 the behavior did change. I've not isolated it >>>>>> >>>> outside >>>> >>>>>> of mochiweb, but I don't think its a mochiweb problem. >>>>>> >>>>>> Here's the pull request which contains the short program I used to >>>>>> reproduce with mochiweb (and work around the new behavior) >>>>>> >>>>>> https://github.com/mochi/mochiweb/pull/91 >>>>>> >>>>>> I'll see if I can't isolate it to just OTP sometime in the next >>>>>> couple of days. >>>>>> >>>>>> -Anthony >>>>>> >>>>>> On Mon, Dec 17, 2012 at 04:10:55PM +0100, Sverker Eriksson wrote: >>>>>> >>>>>>> Have I understood it correctly so far if I say that my commit >>>>>>> dc5f7190 seems to cause a >>>>>>> >>>>>>> {tcp_error,Port,emsgsize} >>>>>>> >>>>>>> while earlier versions caused a >>>>>>> >>>>>>> {http,Port,{http_error,"..."}} >>>>>>> >>>>>>> >>>>>>> for the same scenario with some sort of very long http lines? >>>>>>> >>>>>>> /Sverker, Erlang/OTP >>>>>>> >>>>>>> Anthony Molinaro wrote: >>>>>>> >>>>>>>> On Fri, Dec 14, 2012 at 11:32:11AM -0500, Steve Vinoski wrote: >>>>>>>> >>>>>>>>> Hi Anthony, based on your example, it looks like a follow-up commit >>>>>>>>> >>>>>> that >>>>>> >>>>>>>>> modified some of the changes introduced by my patch introduced the >>>>>>>>> >>>>>> issue >>>>>> >>>>>>>>> you're seeing: commit dc5f7190. You might want to report it over on >>>>>>>>> erlang-bugs. >>>>>>>>> >>>>>>>> Nice catch, I guess that it's actually not enough to return error >>>>>>>> for backward compatibility ;) >>>>>>>> >>>>>>>> I think the main thing I'm still not sure of is if the decode_packet >>>>>>>> >>>>>> changes >>>>>> >>>>>>>> are actually the cause. I was able to call decode_packet with long >>>>>>>> >>>>>> headers >>>>>> >>>>>>>> and not actually see an issue. >>>>>>>> >>>>>>>> This >>>>>>>> >>>>>>>> erlang:decode_packet ( httph, >>>>>>>> list_to_binary ([ "X-Random: ", >>>>>>>> [$a || _ <- >>>>>>>> >>>>>> lists:seq(1,10000)], >>>>>> >>>>>>>> "\r\n\r\n" >>>>>>>> ]), >>>>>>>> []). >>>>>>>> >>>>>>>> Returns the same thing in both R14B04 and R15B02. And as far as I >>>>>>>> >>>> am >>>> >>>>>> able >>>>>> >>>>>>>> to tell that is the only call made to decode_packet in mochiweb. >>>>>>>> >>>>>>>> I think the actual error is around recvbuf sizing (mochiweb uses >>>>>>>> >>>> 8192 as >>>> >>>>>>>> the default, so 10000 is definitely larger than that, however, the >>>>>>>> >>>>>> standard >>>>>> >>>>>>>> libraries must be doing something different as now it returns >>>>>>>> >>>> emsgsize >>>> >>>>>>>> where it did no in the past). I really wish there was a way to >>>>>>>> >>>> search >>>> >>>>>>>> commits on github as then I could search for recvbuf or something >>>>>>>> >>>> like >>>> >>>>>>>> that to see what might have changed. >>>>>>>> >>>>>>>> Before I go over to bugs I'll probably try to detangle mochiweb >>>>>>>> >>>> enough >>>> >>>>>>>> to create a small reproducible test case. >>>>>>>> >>>>>>>> I also have a pull request into mochiweb which prevents the crash >>>>>>>> >>>> but >>>> >>>>>>>> has the annoying behavior at the moment that it returns an error to >>>>>>>> >>>> the >>>> >>>>>>>> client about disconnecting version the 400 error it returned before. >>>>>>>> >>>>>>>> https://github.com/mochi/mochiweb/pull/91 >>>>>>>> >>>>>>>> But since the standard library seems to be the one closing the >>>>>>>> >>>> socket >>>> >>>>>>>> there's not much that can be done other than the fix I put in place. >>>>>>>> >>>>>>>> Thanks for your help Steve, >>>>>>>> >>>>>>>> -Anthony >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> erlang-questions mailing list >>>>>>> erlang-questions@REDACTED >>>>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>>>> >>>>>> -- >>>>>> >>>>>> >>>> ------------------------------------------------------------------------ >>>> >>>>>> Anthony Molinaro < >>>>>> >>>> anthonym@REDACTED> >>>> >>>>>> _______________________________________________ >>>>>> erlang-questions mailing list >>>>>> erlang-questions@REDACTED >>>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>>> >>>>>> >>>> -- >>>> ------------------------------------------------------------------------ >>>> Anthony Molinaro >>>> >>>> > > From langxianzhe@REDACTED Wed Jan 9 05:08:00 2013 From: langxianzhe@REDACTED (=?GB2312?B?wMnPzM7k?=) Date: Wed, 9 Jan 2013 12:08:00 +0800 Subject: [erlang-questions] =?gb2312?b?udjT2mdsb2JhbL34s8zLwLX0zsrM4g==?= Message-ID: ????????A?B?C?????? ???A ??????????? ?? ????????? gl??????? *???? *A ???????B?C ????????????. ???????????????? ???? ??? 1 -module(global_t). 2 3 -compile(export_all). 4 5 6 start() -> 7 Pid = spawn(?MODULE, loop, []), 8 global:register_name(gl, Pid). 9 10 11 loop() -> 12 io:format("loop~n", []), 13 receive 14 {Pid,Any} -> 15 io:format("~p~n", [{Pid,Any}]), 16 Pid ! okss, 17 loop() 18 end. 19 20 21 ~ ~ ~ -- ??????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From langxianzhe@REDACTED Wed Jan 9 05:16:00 2013 From: langxianzhe@REDACTED (=?GB2312?B?wMnPzM7k?=) Date: Wed, 9 Jan 2013 12:16:00 +0800 Subject: [erlang-questions] About global process is killed question Message-ID: *Assuming that* it is true, what should we do now?Assuming there is 3 servers (A?B?C) in the cluster. Register a global process (global:register_name(gl, Pid)) in the A server. Then 3 servers is work well. *The question* is the other Sever(B and C ) does not work when the A server is killed. Thanks for any idea. Cheers, Jason ??????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From barcojie@REDACTED Wed Jan 9 05:39:48 2013 From: barcojie@REDACTED (Barco You) Date: Wed, 9 Jan 2013 12:39:48 +0800 Subject: [erlang-questions] =?gb2312?b?udjT2mdsb2JhbL34s8zLwLX0zsrM4g==?= In-Reply-To: References: Message-ID: ??B,C?????timeout????? receive {Pid,okss} -> io:format("~p~n", [{Pid,Any}]), Pid ! "thank you", loop() after Timeout -> dosothing here end. 2013/1/9 ??? > ????????A?B?C?????? > ???A ??????????? > ?? ????????? gl??????? > > *???? *A ???????B?C ????????????. > > ???????????????? > > ???? > > ??? > > > 1 -module(global_t). > > > 2 > 3 -compile(export_all). > 4 > 5 > 6 start() -> > 7 Pid = spawn(?MODULE, loop, []), > 8 global:register_name(gl, Pid). > 9 > 10 > 11 loop() -> > 12 io:format("loop~n", []), > 13 receive > 14 {Pid,Any} -> > 15 io:format("~p~n", [{Pid,Any}]), > 16 Pid ! okss, > 17 loop() > 18 end. > 19 > 20 > 21 > ~ > > > ~ > > > ~ > -- > ??????????????? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From barcojie@REDACTED Wed Jan 9 05:40:19 2013 From: barcojie@REDACTED (Barco You) Date: Wed, 9 Jan 2013 12:40:19 +0800 Subject: [erlang-questions] About global process is killed question In-Reply-To: References: Message-ID: Use Timeout on B,C receive {Pid,okss} -> io:format("~p~n", [{Pid,Any}]), Pid ! "thank you", loop() after Timeout -> dosothing here end. On Wed, Jan 9, 2013 at 12:16 PM, ??? wrote: > *Assuming that* it is true, what should we do now? Assuming there is 3 > servers (A?B?C) in the cluster. > > Register a global process (global:register_name(gl, Pid)) in the A server. > Then 3 servers is work well. > > *The question* is the other Sever(B and C ) does not work when the A > server is killed. > > Thanks for any idea. > > Cheers, Jason > > > > > ??????????????? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bduggan@REDACTED Wed Jan 9 06:33:27 2013 From: bduggan@REDACTED (Bernie Duggan) Date: Wed, 9 Jan 2013 05:33:27 +0000 Subject: [erlang-questions] Accessing the SNMP MIB 'Description' field Message-ID: <31E741CCEAAEA641930B48274B5C9840324FC20B@SVLITMX02.shoretel.com> Hi list, I'm using the built-in SNMP agent module (snmpa) to read some SNMP data, and I was wondering if there's any way to access the DESCRIPTION field in the MIBS (either through snmpa or any other mechanism that doesn't involve me parsing the mib text files myself). The snmpc mib compiler provides a '--desc' option to include the description field into the compiled files (which can then be loaded by snmpa) but I can't see any way to access that data even if it is included. Any help would be appreciated. Cheers, Bernard ________________________________ This e-mail and any attachments are confidential. If it is not intended for you, please notify the sender, and please erase and ignore the contents. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wgwi@REDACTED Wed Jan 9 07:37:02 2013 From: wgwi@REDACTED (Wang Wei) Date: Wed, 09 Jan 2013 14:37:02 +0800 Subject: [erlang-questions] =?utf-8?b?5YWz5LqOZ2xvYmFs6L+b56iL5q275o6J6Zeu?= =?utf-8?b?6aKY?= In-Reply-To: References: Message-ID: <50ED100E.6000305@sxu.edu.cn> 1. ?A???????D??,??A???. 2. A,D?????gl,??????(??rabbitmq??mneniz),????? ?? ? 2013/1/9 12:08, ??? ??: > ????????A?B?C?????? > ???A ??????????? > ?? ????????? gl??????? > > *???? *A ???????B?C ????????????. > > ???????????????? > > ???? > > ??? > > > 1 -module(global_t). > 2 > 3 -compile(export_all). > 4 > 5 > 6 start() -> > 7 Pid = spawn(?MODULE, loop, []), > 8 global:register_name(gl, Pid). > 9 > 10 > 11 loop() -> > 12 io:format("loop~n", []), > 13 receive > 14 {Pid,Any} -> > 15 io:format("~p~n", [{Pid,Any}]), > 16 Pid ! okss, > 17 loop() > 18 end. > 19 > 20 > 21 > ~ > ~ > ~ > -- > ??????????????? > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From barcojie@REDACTED Wed Jan 9 07:44:22 2013 From: barcojie@REDACTED (Barco You) Date: Wed, 9 Jan 2013 14:44:22 +0800 Subject: [erlang-questions] =?gb2312?b?udjT2mdsb2JhbL34s8zLwLX0zsrM4g==?= In-Reply-To: <50ED100E.6000305@sxu.edu.cn> References: <50ED100E.6000305@sxu.edu.cn> Message-ID: ???????? ?gproc?ABC???????Key????? 2013/1/9 Wang Wei > 1. ?A???????D??,??A???. > 2. A,D?????gl,??????(??rabbitmq??mneniz),????? > > ?? > ? 2013/1/9 12:08, ??? ??: > > ????????A?B?C?????? > ???A ??????????? > ?? ????????? gl??????? > > *???? *A ???????B?C ????????????. > > ???????????????? > > ???? > > ??? > > > 1 -module(global_t). > > > 2 > 3 -compile(export_all). > 4 > 5 > 6 start() -> > 7 Pid = spawn(?MODULE, loop, []), > 8 global:register_name(gl, Pid). > 9 > 10 > 11 loop() -> > 12 io:format("loop~n", []), > 13 receive > 14 {Pid,Any} -> > 15 io:format("~p~n", [{Pid,Any}]), > 16 Pid ! okss, > 17 loop() > 18 end. > 19 > 20 > 21 > ~ > > > ~ > > > ~ > -- > ??????????????? > > > _______________________________________________ > erlang-questions mailing listerlang-questions@REDACTED://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 inanun@REDACTED Wed Jan 9 08:27:53 2013 From: inanun@REDACTED (Kyungho Yun) Date: Wed, 9 Jan 2013 16:27:53 +0900 Subject: [erlang-questions] What is the best type as key of mnesia table? Message-ID: I used _list_ as key of table. Now I need more faster and lighter so I tested some. Before I tested, I think that _atom_ is the fastest and smaller mnesia files. And I thought that _binary_ is the best candidate because _atom_ has issue of garbage collection. But test results make me confused. Q0. What is the best type as key? == test results == There are three candidates; list, binary and atom. 100k keys; list keys are "k1000001" ~ "k1100000", binary keys are <<"k1000001">> ~ <<"k1100000">>, atom keys are k1000001 ~ k1100000. I tested both mnesia types; disc_copy and disc_only_copy Q1. Mnesia file sizes are strange, what's wrong? - disc_copy size table_type 3100089 atom.DCD 3300089 binary.DCD 3100089 list.DCD - disc_only_copy size table_type 5391992 list_o.DAT 6489808 binary_o.DAT 6130276 atom_o.DAT * Every key has same value. * checked the sizes after q(). accoding to http://erlang.org/doc/efficiency_guide/advanced.html list : 1 word + 2 words * 8(length of a list) = 17 words binary : 3..6 + 8(length of a list) = 11 ~ 14 words atom : 1 word so I thought the size order will list > binary >> atom. Q2. Why atom is not fastest? atom is sometimes the slowest. atom read : 61.095 binary read : 65.729 list read : 84.162 atom write : 858.18 binary write : 913.092 list write : 861.357 atom_o read : 1657.427 binary_o read : 1453.002 list_o read : 1482.138 atom_o write : 1765.436 binary_o write : 2261.9 list_o write : 2289.084 * read and write every tables(100k) * tried to avoid difference of period to get a key. * milli seconds * I think that the best type is _integer_, but I want use one of them. thanks. /nanun -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourinov@REDACTED Wed Jan 9 08:36:01 2013 From: bourinov@REDACTED (Max Bourinov) Date: Wed, 9 Jan 2013 11:36:01 +0400 Subject: [erlang-questions] What is the best type as key of mnesia table? In-Reply-To: References: Message-ID: Hi Kyungho Yun, Atoms as a key will work only if you have limited amount of keys... Anyways it is not very good idea, because amount of atoms in Erlang VM is limited by about 1.000.000. Of course you can increase amount of atoms in VM by simply patching Erlang source code... But I would not suggest you to do so. List is also not the very best options because it is relatively complex data structure. Go with something simple: binaries or integers could work for you. Best regards, Max On Wed, Jan 9, 2013 at 11:27 AM, Kyungho Yun wrote: > I used _list_ as key of table. > Now I need more faster and lighter so I tested some. > > Before I tested, I think that _atom_ is the fastest and smaller mnesia > files. > And I thought that _binary_ is the best candidate because _atom_ has issue > of garbage collection. > > But test results make me confused. > > Q0. What is the best type as key? > > == test results == > > There are three candidates; list, binary and atom. > > 100k keys; > list keys are "k1000001" ~ "k1100000", > binary keys are <<"k1000001">> ~ <<"k1100000">>, > atom keys are k1000001 ~ k1100000. > > I tested both mnesia types; disc_copy and disc_only_copy > > Q1. Mnesia file sizes are strange, what's wrong? > - disc_copy > size table_type > 3100089 atom.DCD > 3300089 binary.DCD > 3100089 list.DCD > - disc_only_copy > size table_type > 5391992 list_o.DAT > 6489808 binary_o.DAT > 6130276 atom_o.DAT > > * Every key has same value. > * checked the sizes after q(). > > > accoding to http://erlang.org/doc/efficiency_guide/advanced.html > list : 1 word + 2 words * 8(length of a list) = 17 words > binary : 3..6 + 8(length of a list) = 11 ~ 14 words > atom : 1 word > so I thought the size order will list > binary >> atom. > > Q2. Why atom is not fastest? atom is sometimes the slowest. > atom read : 61.095 > binary read : 65.729 > list read : 84.162 > > atom write : 858.18 > binary write : 913.092 > list write : 861.357 > > atom_o read : 1657.427 > binary_o read : 1453.002 > list_o read : 1482.138 > > atom_o write : 1765.436 > binary_o write : 2261.9 > list_o write : 2289.084 > > * read and write every tables(100k) > * tried to avoid difference of period to get a key. > * milli seconds > > * I think that the best type is _integer_, but I want use one of them. > > thanks. > /nanun > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.glushkov@REDACTED Wed Jan 9 09:29:31 2013 From: ivan.glushkov@REDACTED (Ivan Glushkov) Date: Wed, 9 Jan 2013 12:29:31 +0400 Subject: [erlang-questions] Unused local function kills the process when the code updates Message-ID: Hi there. I do know that using long-lived local function is not a good idea, but I'm a bit concerned about the following behavior. I have a small example: $ cat my.erl -module(my). %-export([foo/0]). -export([ start/0, loop/1 ]). start() -> register(?MODULE, spawn_link(?MODULE, loop, [fun logger/2])). %foo() -> apply(fun erlang:now/0, []). loop(Logger) -> receive V -> io:format("received ~p~n", [V]), ?MODULE:loop(Logger) after 100 -> ?MODULE:loop(Logger) end. logger(Msg, Args) -> io:format(Msg, Args). You see, here I save 'fun logger/2' into a loop state, and I don't use it anymore. Then if I do the following steps: - compile and load the code - start loop - uncomment foo - compile and load the code twice it kills my process. I would understand such a behavior if I didn't use fully qualified name for the 'loop' function. But I do. Actually, the same thing is happened if I use a gen_server instead of loop, and save my variable in it's state. I've done some research and compiled to assembler both versions of the code (attached). The only valuable difference (beside adding 'foo' surely) is the labels: 1. where the anonymous function 'fun logger/2' is defined: -{function, '-start/0-fun-0-', 2, 14}. - {label,13}. +{function, '-start/0-fun-0-', 2, 16}. + {label,15}. {line,[{location,"my.erl",5}]}. {func_info,{atom,my},{atom,'-start/0-fun-0-'},2}. - {label,14}. - {call_only,2,{f,8}}. + {label,16}. + {call_only,2,{f,10}}. 2. where it is used to create a 'Logger' variable: - {make_fun2,{f,14},0,0,0}. + {make_fun2,{f,16},0,0,0}. 3. where the logger function itself is defined: -{function, logger, 2, 8}. - {label,7}. +{function, logger, 2, 10}. + {label,9}. {line,[{location,"my.erl",16}]}. {func_info,{atom,my},{atom,logger},2}. - {label,8}. + {label,10}. {line,[{location,"my.erl",16}]}. {call_ext_only,2,{extfunc,io,format,2}}. 4. and of course the total number of labels: -{labels, 15}. +{labels, 17}. I'm not an expert in the field, but it seems to me that this is not a great deal. Function signature hasn't been changed, I mean name and arity. Why does it break my code? What concerns me is that if for some reason I'm saving some opaque values (received from the user) in my gen_server state, I can't be sure that it won't break my code _even if it isn't used_. I'm almost sure it's a incorrect behavior. Best, Ivan. -------------- next part -------------- A non-text attachment was scrubbed... Name: files.zip Type: application/zip Size: 1901 bytes Desc: not available URL: From mbj@REDACTED Wed Jan 9 09:37:40 2013 From: mbj@REDACTED (Martin Bjorklund) Date: Wed, 09 Jan 2013 09:37:40 +0100 (CET) Subject: [erlang-questions] Accessing the SNMP MIB 'Description' field In-Reply-To: <31E741CCEAAEA641930B48274B5C9840324FC20B@SVLITMX02.shoretel.com> References: <31E741CCEAAEA641930B48274B5C9840324FC20B@SVLITMX02.shoretel.com> Message-ID: <20130109.093740.492286544298478601.mbj@tail-f.com> Hi, Bernie Duggan wrote: > Hi list, > I'm using the built-in SNMP agent module (snmpa) to read some SNMP > data, and I was wondering if there's any way to access the DESCRIPTION > field in the MIBS (either through snmpa or any other mechanism that > doesn't involve me parsing the mib text files myself). The snmpc mib > compiler provides a '--desc' option to include the description field > into the compiled files (which can then be loaded by snmpa) but I > can't see any way to access that data even if it is included. The info is available (I think ;) in the #me{} (mib entry). Use like this: {value, OID} = snmpa:name_to_oid(snmpEngineID), {ok, ME} = snmpa:me_of(OID ++ [0]), ME#me.description. See the documentation for snmpa:me_of(). /martin From solomon.wzs@REDACTED Wed Jan 9 11:16:30 2013 From: solomon.wzs@REDACTED (Solomon) Date: Wed, 9 Jan 2013 18:16:30 +0800 Subject: [erlang-questions] How to dynamically compiled module? In-Reply-To: <61cc37af-43d7-42c2-9d1d-7b0ea1da7641@googlegroups.com> References: <61cc37af-43d7-42c2-9d1d-7b0ea1da7641@googlegroups.com> Message-ID: It is ok when I call the function like that: mochiglobal:put(key, [1, 2, 3]). But it is error when I call the function like that: mochiglobal:put(key, self()). I know I could save the variable like that: mochiglobal:put(key, term_to_binary(self())), but I want to know whether there are some methods to save pid or port directly. Thanks. 2013/1/9 Andrew Majorov > I beleive mochiglobal is exactly what you are searching for. Note this is > more or less legacy stuff. If you are just into the deal with global > variables, IMO ets or dedicated process is more appropriate. > > https://github.com/mochi/mochiweb/blob/master/src/mochiglobal.erl > > I want to save a variable and number of threads would call it, but I don't >> want to save it in ets. >> >> I want to dynamically compiled a module, when I call foo:bar(), it will >> return the variable directly. >> >> How should I do? >> >> (P.S. the variable like this: {#Fun<...>, <0.1.0>, ...}) >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pan@REDACTED Wed Jan 9 12:25:17 2013 From: pan@REDACTED (Patrik Nyblom) Date: Wed, 9 Jan 2013 12:25:17 +0100 Subject: [erlang-questions] Unused local function kills the process when the code updates In-Reply-To: References: Message-ID: <50ED539D.6020802@erlang.org> Hi, As you changed the code and reloaded it, your fun, which is held in the process belongs to old code. The function signature has changed when you changed and loaded the new version of the module. When you reload again, you need to purge the old code, which is referenced by your process and the process is killed. The fact that the fun has not changed textually is only a guarantee if it does no local calls and has no environment. As soon as the code changes the fun's will get new signatures as there is a hash of the module included in the fun signature, there is no optimization to keep fun signatures for this case. If you want long living fun's just change the fun to a module fun: register(?MODULE, spawn_link(?MODULE, loop, [fun ?MODULE:logger/2])). Cheers, /Patrik On 01/09/2013 09:29 AM, Ivan Glushkov wrote: > Hi there. > > I do know that using long-lived local function is not a good idea, but > I'm a bit concerned about the following behavior. > > I have a small example: > $ cat my.erl > -module(my). > %-export([foo/0]). > -export([ start/0, loop/1 ]). > > start() -> register(?MODULE, spawn_link(?MODULE, loop, [fun logger/2])). > > %foo() -> apply(fun erlang:now/0, []). > > loop(Logger) -> > receive V -> > io:format("received ~p~n", [V]), > ?MODULE:loop(Logger) > after 100 -> ?MODULE:loop(Logger) > end. > > logger(Msg, Args) -> io:format(Msg, Args). > > > You see, here I save 'fun logger/2' into a loop state, and I don't use > it anymore. > Then if I do the following steps: > - compile and load the code > - start loop > - uncomment foo > - compile and load the code twice > > it kills my process. > > I would understand such a behavior if I didn't use fully qualified > name for the 'loop' function. But I do. > Actually, the same thing is happened if I use a gen_server instead of > loop, and save my variable in it's state. > > I've done some research and compiled to assembler both versions of the > code (attached). > The only valuable difference (beside adding 'foo' surely) is the labels: > > 1. where the anonymous function 'fun logger/2' is defined: > -{function, '-start/0-fun-0-', 2, 14}. > - {label,13}. > +{function, '-start/0-fun-0-', 2, 16}. > + {label,15}. > {line,[{location,"my.erl",5}]}. > {func_info,{atom,my},{atom,'-start/0-fun-0-'},2}. > - {label,14}. > - {call_only,2,{f,8}}. > + {label,16}. > + {call_only,2,{f,10}}. > > 2. where it is used to create a 'Logger' variable: > - {make_fun2,{f,14},0,0,0}. > + {make_fun2,{f,16},0,0,0}. > > 3. where the logger function itself is defined: > -{function, logger, 2, 8}. > - {label,7}. > +{function, logger, 2, 10}. > + {label,9}. > {line,[{location,"my.erl",16}]}. > {func_info,{atom,my},{atom,logger},2}. > - {label,8}. > + {label,10}. > {line,[{location,"my.erl",16}]}. > {call_ext_only,2,{extfunc,io,format,2}}. > > 4. and of course the total number of labels: > -{labels, 15}. > +{labels, 17}. > > I'm not an expert in the field, but it seems to me that this is not a > great deal. Function signature hasn't been changed, I mean name and > arity. Why does it break my code? > > What concerns me is that if for some reason I'm saving some opaque > values (received from the user) in my gen_server state, I can't be > sure that it won't break my code _even if it isn't used_. > I'm almost sure it's a incorrect behavior. > > Best, > Ivan. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From cloudqiu1110@REDACTED Wed Jan 9 12:31:06 2013 From: cloudqiu1110@REDACTED (Cloud) Date: Wed, 09 Jan 2013 19:31:06 +0800 Subject: [erlang-questions] Application startup order in a release Message-ID: <4xcyh52567hqaaqjngyybog3.1357731066961@email.android.com> ?????M9 -------- ???? -------- ????Karolis Petrauskas ????? 1/5 7:25 ????erlang-questions@REDACTED ???[erlang-questions] Application startup order in a release >Hello, > > My Erlang based system is composed of several applications.The >applications can be classified to Core, Plugins and Workers. All >Plugins and Workers have static dependencies on the Core only. I.e >Plugin and Worker application modules use modules from the Core, and >have the application Core listed in their *.app files. The Core >application provides several behaviours and process registries. >Plugins are providing callback modules for these behaviours and >registers corresponding processes to the registries. The Worker >applications use behaviours defined in the Core and use the registries >to lookup the needed processes. That way the Worker applications can >use Plugin processes without knowing about them in advance (behaviours >are used as interface definitions). > I am using sys.config to wire-up all the system (telling Workers >which Plugin-provided processes to use by specifying process names). >That way I am getting runtime dependencies between the corresponding >Workers and Plugins. The corresponding Plugins should be started >before the Workers that have run-time dependencies on them. > I am generating release (using rebar) to run my system. As I >understand, the applications are started according to their >application dependencies, as listed in the .app files. Here is my >question: how can I control application startup order in the release >without including corresponding Plugin applications into the *.app >files of the Workers? I want to keep the Worker applications as clean >as possible. Is there a way to control the startup order during >generation of the release? The only option I know is to transform the >application files after they are build (rebar compile) and before the >release is generated (rebar generate). But that sounds hacky. Maybe >there are better options or maybe my approach on managing application >dependencies is wrong? > > For example, the static dependencies are the following: >Plugin1 -> Core, Lib1 >Plugin2 -> Core, Lib2, Lib3 >Worker1-> Core >Worker2-> Core > > The Lib1, 2, 3 are other applications (e.g. Yaws). They are not >needed by Workers till the run-time. Even integration tests >(common-test) can be executed without them. But for the production >system the following dependencies should be added (or at least the >corresponding startup order enforced): >Worker1 -> Plugin1, Plugin2 >Worker2 -> Plugin1 > >Karolis >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From anotherworldofworld@REDACTED Wed Jan 9 14:13:34 2013 From: anotherworldofworld@REDACTED (Alexander 0xAX) Date: Wed, 9 Jan 2013 19:13:34 +0600 Subject: [erlang-questions] application:get_env return undefined Message-ID: Hello, I have simple test application with test.app.src file, test_app.erl and test_sup.erl Also i want to read config in my application. I have app.config: [ {my_app_config, [{key1, "val"}]} ]. I run my application: erl -boot start_sasl -config app.config -s test_app And now, after application successful starting i try to read my config: >application:get_env(test_app, my_app_config). undefined Why? How can i correctly read config file? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Wed Jan 9 14:45:39 2013 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Wed, 9 Jan 2013 14:45:39 +0100 Subject: [erlang-questions] application:get_env return undefined In-Reply-To: References: Message-ID: <1357739139.4799.26.camel@sekic1152.rnd.ki.sw.ericsson.se> Greetings, Is this not the problem that the file app.config must have .config extension on the file itself, but must not have .config extension on the command line ("-config app")? bengt On Wed, 2013-01-09 at 19:13 +0600, Alexander 0xAX wrote: > Hello, > > > > I have simple test application with test.app.src file, test_app.erl > and test_sup.erl > > > Also i want to read config in my application. I have app.config: > > > [ > {my_app_config, > [{key1, "val"}]} > ]. > > > I run my application: > > > erl -boot start_sasl -config app.config -s test_app > > > And now, after application successful starting i try to read my > config: > > > >application:get_env(test_app, my_app_config). > undefined > > > Why? How can i correctly read config file? > > > Thank you. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From mononcqc@REDACTED Wed Jan 9 14:54:38 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 9 Jan 2013 08:54:38 -0500 Subject: [erlang-questions] application:get_env return undefined In-Reply-To: <1357739139.4799.26.camel@sekic1152.rnd.ki.sw.ericsson.se> References: <1357739139.4799.26.camel@sekic1152.rnd.ki.sw.ericsson.se> Message-ID: <20130109135437.GA83145@ferdmbp.local> If I recall correctly, submitting 'app.config' will look for 'app.config' on disk, and if it is not found, only then will the VM append the '.config' extension and look for 'app.config.config' for the configuration file. It's fine to leave the .config extension in the path for that one. Regards, Fred. On 01/09, Bengt Kleberg wrote: > Greetings, > > Is this not the problem that the file app.config must have .config > extension on the file itself, but must not have .config extension on the > command line ("-config app")? > > > bengt > > On Wed, 2013-01-09 at 19:13 +0600, Alexander 0xAX wrote: > > Hello, > > > > > > > > I have simple test application with test.app.src file, test_app.erl > > and test_sup.erl > > > > > > Also i want to read config in my application. I have app.config: > > > > > > [ > > {my_app_config, > > [{key1, "val"}]} > > ]. > > > > > > I run my application: > > > > > > erl -boot start_sasl -config app.config -s test_app > > > > > > And now, after application successful starting i try to read my > > config: > > > > > > >application:get_env(test_app, my_app_config). > > undefined > > > > > > Why? How can i correctly read config file? > > > > > > Thank you. > > _______________________________________________ > > erlang-questions mailing list > > 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 yurinvv@REDACTED Wed Jan 9 15:12:53 2013 From: yurinvv@REDACTED (Slava Yurin) Date: Wed, 09 Jan 2013 21:12:53 +0700 Subject: [erlang-questions] application:get_env return undefined In-Reply-To: References: Message-ID: <49281357740773@web12d.yandex.ru> An HTML attachment was scrubbed... URL: From straightflush@REDACTED Wed Jan 9 15:12:57 2013 From: straightflush@REDACTED (AD) Date: Wed, 9 Jan 2013 09:12:57 -0500 Subject: [erlang-questions] Environment variables for release In-Reply-To: <8784BC93-D120-4B83-9838-758F024B3BC3@feuerlabs.com> References: <8784BC93-D120-4B83-9838-758F024B3BC3@feuerlabs.com> Message-ID: Yea i think that was it thanks. One follow-up here, the 'startup' of the library depends on the parent app thats including it since it can override some startup parameters via environment variables. Is there a best practice here? I figure you can either 1 - manually start it with application:start(library) in the parent apps start() and remove it from the auto-start list in release 2 - have a separate supervisor that starts the library but doesnt start the workers (kind of like how cowboy only starts the clock, but you have to do cowboy:start_http() in your app). The problem is I only really have 1 gen_server to start and i would like the calling application to load first so it can override with its own environment vars. Any best practice advise appreciated. -A On Mon, Jan 7, 2013 at 10:36 AM, Ulf Wiger wrote: > > One suggestion: > > The application lib must be loaded before get_env() can work. > > BR, > Ulf W > > On 7 Jan 2013, at 15:15, AD wrote: > > Hello, > > I have a library being built that is leveraging environment variables. > There is a line in the library include file that looks like > > -define(CONST, lib:get_env(Key,Default)). > > the lib:get_env function simply checks > > application:get_env(lib, Key) % in order to check the library.app first > and then > application:get_env(Key) % check for local overrides > > However when i place variables like the following in the main example.app > file in ebin/ > > {application,example, > [{description,[]}, > {env,[{'COWBOY_HTTP_PORT',9090}]}, > ...... > > Nothing is getting read. I am not sure if this needs to be in > rel/files/app.config instead? > > Appreciate any help here. > > -AD > > > _______________________________________________ > 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k.petrauskas@REDACTED Wed Jan 9 15:37:27 2013 From: k.petrauskas@REDACTED (Karolis Petrauskas) Date: Wed, 9 Jan 2013 16:37:27 +0200 Subject: [erlang-questions] Application startup order in a release In-Reply-To: <4xcyh52567hqaaqjngyybog3.1357731066961@email.android.com> References: <4xcyh52567hqaaqjngyybog3.1357731066961@email.android.com> Message-ID: Hi, Thanks for the reply. Altrough I have some troubles with understanding your language :) Google translates it as "Sent from Meizu M9". Karolis On Wed, Jan 9, 2013 at 1:31 PM, Cloud wrote: > > > ?????M9 > > > -------- ???? -------- > ????Karolis Petrauskas > ????? 1/5 7:25 > ????erlang-questions@REDACTED > ???[erlang-questions] Application startup order in a release > > > Hello, > > My Erlang based system is composed of several applications.The > applications can be classified to Core, Plugins and Workers. All > Plugins and Workers have static dependencies on the Core only. I.e > Plugin and Worker application modules use modules from the Core, and > have the application Core listed in their *.app files. The Core > application provides several behaviours and process registries. > Plugins are providing callback modules for these behaviours and > registers corresponding processes to the registries. The Worker > applications use behaviours defined in the Core and use the registries > to lookup the needed processes. That way the Worker applications can > use Plugin processes without knowing about them in advance (behaviours > are used as interface definitions). > I am using sys.config to wire-up all the system (telling Workers > which Plugin-provided processes to use by specifying process names). > That way I am getting runtime dependencies between the corresponding > Workers and Plugins. The corresponding Plugins should be started > before the Workers that have run-time dependencies on them. > I am generating release (using rebar) to run my system. As I > understand, the applications are started according to their > application dependencies, as listed in the .app files. Here is my > question: how can I control application startup order in the release > without including corresponding Plugin applications into the *.app > files of the Workers? I want to keep the Worker applications as clean > as possible. Is there a way to control the startup order during > generation of the release? The only option I know is to transform the > application files after they are build (rebar compile) and before the > release is generated (rebar generate). But that sounds hacky. Maybe > there are better options or maybe my approach on managing application > dependencies is wrong? > > For example, the static dependencies are the following: > Plugin1 -> Core, Lib1 > Plugin2 -> Core, Lib2, Lib3 > Worker1-> Core > Worker2-> Core > > The Lib1, 2, 3 are other applications (e.g. Yaws). They are not > needed by Workers till the run-time. Even integration tests > (common-test) can be executed without them. But for the production > system the following dependencies should be added (or at least the > corresponding startup order enforced): > Worker1 -> Plugin1, Plugin2 > Worker2 -> Plugin1 > > Karolis > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From anotherworldofworld@REDACTED Wed Jan 9 15:39:00 2013 From: anotherworldofworld@REDACTED (Alexander 0xAX) Date: Wed, 9 Jan 2013 20:39:00 +0600 Subject: [erlang-questions] application:get_env return undefined In-Reply-To: <49281357740773@web12d.yandex.ru> References: <49281357740773@web12d.yandex.ru> Message-ID: Hello, Thank you for replies. I try to run my application without .config extenstion: exec erl -config app -s test_app Same result. 2013/1/9 Slava Yurin > Hi Alexander. > > Please see https://github.com/nevar/sys_test. > > 09.01.2013, 20:14, "Alexander 0xAX" : > > Hello, > > I have simple test application with test.app.src file, test_app.erl and > test_sup.erl > > Also i want to read config in my application. I have app.config: > > [ > {my_app_config, > [{key1, "val"}]} > ]. > > I run my application: > > erl -boot start_sasl -config app.config -s test_app > > And now, after application successful starting i try to read my config: > > >application:get_env(test_app, my_app_config). > undefined > > Why? How can i correctly read config file? > > Thank you. > , > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.virding@REDACTED Wed Jan 9 16:06:00 2013 From: robert.virding@REDACTED (Robert Virding) Date: Wed, 9 Jan 2013 15:06:00 +0000 (GMT) Subject: [erlang-questions] application:get_env return undefined In-Reply-To: Message-ID: <872759388.2745500.1357743960075.JavaMail.root@erlang-solutions.com> A config file has the syntax: [{Application1, [{Par11,Val11},...]}, ..., {ApplicationN, [{ParN1,ValN1},...]}]. which means that the application is not specified in the file name but in the data in the actual file. So you can have configuration data for many applications in one file. So in your case you have defined configuration data for the application 'my_app_config' with key1. So if we define our minimal application my_app with config file in my_app.app and app.config: $ cat my_app.app {application,my_app, [{description,"My App"}, {env,[{key1,"val .app"}]} ]}. $ cat app.config [{my_app,[{key1,"val .config"}]}]. Then we can do: $ erl Erlang R15B (erts-5.9) [source] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9 (abort with ^G) 1> application:start(my_app). ok 2> application:get_env(my_app,key1). {ok,"val .app"} while: $ erl -config app.config Erlang R15B (erts-5.9) [source] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9 (abort with ^G) 1> application:start(my_app). ok 2> application:get_env(my_app,key1). {ok,"val .config"} Check in http://www.erlang.org/doc/design_principles/applications.html more specifically: http://www.erlang.org/doc/design_principles/applications.html#id74278 The problem of finding the file still remains of course. Robert P.S. Got a bit longer than expected here. ----- Original Message ----- > From: "Alexander 0xAX" > To: erlang-questions@REDACTED > Sent: Wednesday, 9 January, 2013 3:39:00 PM > Subject: Re: [erlang-questions] application:get_env return undefined > Hello, > Thank you for replies. > I try to run my application without .config extenstion: > exec erl -config app -s test_app > Same result. > 2013/1/9 Slava Yurin < yurinvv@REDACTED > > > Hi Alexander. > > > Please see https://github.com/nevar/sys_test . > > > 09.01.2013, 20:14, "Alexander 0xAX" < anotherworldofworld@REDACTED > > >: > > > > Hello, > > > > > > I have simple test application with test.app.src file, > > > test_app.erl > > > and test_sup.erl > > > > > > Also i want to read config in my application. I have app.config: > > > > > > [ > > > > > > {my_app_config, > > > > > > [{key1, "val"}]} > > > > > > ]. > > > > > > I run my application: > > > > > > erl -boot start_sasl -config app.config -s test_app > > > > > > And now, after application successful starting i try to read my > > > config: > > > > > > >application:get_env(test_app, my_app_config). > > > > > > undefined > > > > > > Why? How can i correctly read config file? > > > > > > Thank you. > > > > > > , > > > > > > _______________________________________________ > > > > > > erlang-questions mailing list > > > > > > 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 lovei.laszlo@REDACTED Wed Jan 9 16:56:21 2013 From: lovei.laszlo@REDACTED (Laszlo Lovei) Date: Wed, 9 Jan 2013 07:56:21 -0800 (PST) Subject: [erlang-questions] What is the best type as key of mnesia table? In-Reply-To: References: Message-ID: <0e1ab273-ce9d-4a08-bb54-da03fdea93b3@googlegroups.com> Q0: there is not a single best key type, and you are on the right track to find the one that is best suited for your scenario: do a lot of experiments and measurements :) Personally I would advise against using atoms when you use a lot of dynamically generated keys, they are not designed for that. Q1: the numbers you quote are the sizes for in-memory representation. Atoms use 1 word in memory because there is a lookup table for them. When you write the data to disc, all characters have to be stored, and the difference between these types will be small. L. On Wednesday, January 9, 2013 8:27:53 AM UTC+1, nanun wrote: > > I used _list_ as key of table. > Now I need more faster and lighter so I tested some. > > Before I tested, I think that _atom_ is the fastest and smaller mnesia > files. > And I thought that _binary_ is the best candidate because _atom_ has issue > of garbage collection. > > But test results make me confused. > > Q0. What is the best type as key? > > == test results == > > There are three candidates; list, binary and atom. > > 100k keys; > list keys are "k1000001" ~ "k1100000", > binary keys are <<"k1000001">> ~ <<"k1100000">>, > atom keys are k1000001 ~ k1100000. > > I tested both mnesia types; disc_copy and disc_only_copy > > Q1. Mnesia file sizes are strange, what's wrong? > - disc_copy > size table_type > 3100089 atom.DCD > 3300089 binary.DCD > 3100089 list.DCD > - disc_only_copy > size table_type > 5391992 list_o.DAT > 6489808 binary_o.DAT > 6130276 atom_o.DAT > > * Every key has same value. > * checked the sizes after q(). > > > accoding to http://erlang.org/doc/efficiency_guide/advanced.html > list : 1 word + 2 words * 8(length of a list) = 17 words > binary : 3..6 + 8(length of a list) = 11 ~ 14 words > atom : 1 word > so I thought the size order will list > binary >> atom. > > Q2. Why atom is not fastest? atom is sometimes the slowest. > atom read : 61.095 > binary read : 65.729 > list read : 84.162 > > atom write : 858.18 > binary write : 913.092 > list write : 861.357 > > atom_o read : 1657.427 > binary_o read : 1453.002 > list_o read : 1482.138 > > atom_o write : 1765.436 > binary_o write : 2261.9 > list_o write : 2289.084 > > * read and write every tables(100k) > * tried to avoid difference of period to get a key. > * milli seconds > > * I think that the best type is _integer_, but I want use one of them. > > thanks. > /nanun > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clist@REDACTED Wed Jan 9 18:08:20 2013 From: clist@REDACTED (Angel J. Alvarez Miguel) Date: Wed, 9 Jan 2013 18:08:20 +0100 Subject: [erlang-questions] Why system_flag(scheduler_bind_type) is deprecated? In-Reply-To: References: <201301081304.02164.clist@uah.es> Message-ID: <201301091808.21286.clist@uah.es> Thanks for the explanations! On Martes, 8 de Enero de 2013 13:57:49 Rickard Green escribi?: > On Jan 8, 2013, at 1:04 PM, "Angel J. Alvarez Miguel" wrote: > > On Martes, 8 de Enero de 2013 12:08:41 Jesper Louis Andersen escribi?: > >> On Jan 8, 2013, at 12:04 PM, Max Lapshin wrote: > >>> If erlyvideo is launched without +sbt spread flag, it looses packets > >>> from UDP because too many tasks are on one core. There are some erlang > >>> distributions (OS X, ubuntu package, some others) that are just > >>> halting if you pass +sbt flag. So I can't write proper init script > >>> that passes this flag or don't pass. > >> > >> I think Rickard already said he would implement a "silent failure" flag > >> for this, so you could do something like > >> > >> erl +sbt db +sat-ignore-failure > > > > This seems to be a good falloff, here we use scritptized rebars > > deployments for our projects and this fits very well to be included in > > the > > escript_emu_args variable... provided the user cant change default vm > > args per se > > > >> and have it work on, say, OSX because it would silently disable the > >> flag. As you say, +sbt has too much of an impact in the real world to > >> be ignored for certain types of load, so I still like the default of > >> refusing to start if the bind type can't be satisfied. > >> > >> Jesper Louis Andersen > >> > >> Erlang Solutions Ltd., Copenhagen > > I'll add an +stbt ("try bind type") switch that will do the same thing as > +sbt, but if it fails this will silently be ignored and the runtime will > be started anyway. I can add the +stbt switch to r16. The change will be > quite simple, so I guess that it should be quite easy to apply the change > on the r15b03 source if you want to. > > Regarding support for automatic detection of cpu-topology and binding of > schedulers. I think this is an area really suitable for user > contributions. Since the APIs that need to be used often differ between > OSes and sometimes also between hardware architectures on the same OS, we > will never have the time to implement support for this on all platforms > users are interested in. Therefore, user contributions implementing this > on various platforms are much appreciated (other contributions are of > course also appreciated). > > If +sbt fails on a newer Linux, the problem is most likely that no > cpu-topology were automatically detected. On Linux, the runtime tries to > detect this by inspecting the /sys filesystem. The content under > /sys/devices/system/{cpu,node} varies quite a lot depending on hw arch. > Sometimes there aren't enough info there to determine the topology, but it > could also be that the information is just formatted another way than we > expected. > > Detection of cpu-topology and binding of threads to logical processors are > implemented in $ERL_TOP/erts/lib_src/common/erl_misc_utils.c > > Regards, > Rickard Green, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From anotherworldofworld@REDACTED Wed Jan 9 18:08:29 2013 From: anotherworldofworld@REDACTED (Alexander 0xAX) Date: Wed, 9 Jan 2013 23:08:29 +0600 Subject: [erlang-questions] application:get_env return undefined In-Reply-To: <872759388.2745500.1357743960075.JavaMail.root@erlang-solutions.com> References: <872759388.2745500.1357743960075.JavaMail.root@erlang-solutions.com> Message-ID: Robert thank you for detailed answer. Now all right. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pan@REDACTED Wed Jan 9 19:18:58 2013 From: pan@REDACTED (Patrik Nyblom) Date: Wed, 9 Jan 2013 19:18:58 +0100 Subject: [erlang-questions] Working around the Windows firewall In-Reply-To: References: <00d001cde16a$9a795bc0$cf6c1340$@com> <50EB065B.1070602@erlang.org> Message-ID: <50EDB492.8060208@erlang.org> Hi! On 01/07/2013 09:33 PM, Antoine Koener wrote: > Just to share my small experience with uds_dist: last time I've > checked, everything was fine but the distribution was not working at all. > Pipes were OK, but the distribution wasn't. > The problem seems to be related to some obscure flag in the structure. > I think this code may have worked with old version of erlang < R13... > > You're absolutely right, it's broken... I'll fix it for the R16 release. Cheers, /Patrik > > On Mon, Jan 7, 2013 at 6:31 PM, Patrik Nyblom > wrote: > > On 12/24/2012 01:07 AM, Jeffrey Rennie wrote: >> >> Before I draft a formal EEP, >> >> Windows firewall is enabled by default, and blocks sockets used >> by erlang. Yes, exceptions can be added to the firewall, >> however, this is not possible in some situations. For example: >> >> 1. A corporate network with strict policies that prohibit >> opening ports used by erlang. >> >> 2. An application written in erlang that installs without >> administrator privileges. >> >> 3. (A generalization of the above) Whenever the user who wants >> to run erlang is not an administrator. >> >> In these environments, an alternative to sockets which get >> entangled in the firewall, is Win32 named pipes which do not get >> entangled in the firewall. >> >> Therefore, I propose a change that will allow erlang nodes to >> communicate over named pipes in addition to sockets. Of course, >> it would be controlled by command-line parameters. >> >> I've spent a day browsing the erlang source code and it looks >> pretty doable. >> >> Comments and questions please. >> > > Good idea! There is actually no need to change anything in the > Erlang VM to do that. The distribution mechanism is pluggable, so > you can write a driver that uses any protocol where you can setup > a stream of bytes between nodes (ok, that sounds easier than it > really is, but it's absolutely doable). There is an example in the > kernel source code ($ERL_TOP/lib/kernel/examples/uds_dist) where > distribution is set up using Unix named pipes, which is of course > more limited, but shows the general idea of how to implement a > distribution driver. > >> P.S. It took me about 5 hours to successfully build on Windows; I >> had most of the tools like Visual Studio and cygwin installed. I >> got tripped up by git switching LFs to CRLFs, which chokes bash. >> Also, it's much faster to just run vcvars32.bat and then run bash >> than to write your own script that sets the vc environment variables. >> > Yes, it's a pain. The CRLF defaults of msysgit is also a pain. > Using vcvars32 directly may definitely be a shortcut, maybe you > could add some section to the windows readme about your approach? >> >> > Cheers, > /Patrik >> >> >> _______________________________________________ >> erlang-questions mailing list >> 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 ivan.glushkov@REDACTED Wed Jan 9 21:18:18 2013 From: ivan.glushkov@REDACTED (Ivan Glushkov) Date: Thu, 10 Jan 2013 00:18:18 +0400 Subject: [erlang-questions] Unused local function kills the process when the code updates In-Reply-To: <50ED539D.6020802@erlang.org> References: <50ED539D.6020802@erlang.org> Message-ID: Thank you for the answer, Patric. You mean there's no way to get the local function saved if it has smth like "io:format" call in it? It will always kill the process after the second code update, won't it? Ivan. On Wed, Jan 9, 2013 at 3:25 PM, Patrik Nyblom wrote: > Hi, > > As you changed the code and reloaded it, your fun, which is held in the > process belongs to old code. The function signature has changed when you > changed and loaded the new version of the module. When you reload again, you > need to purge the old code, which is referenced by your process and the > process is killed. The fact that the fun has not changed textually is only a > guarantee if it does no local calls and has no environment. As soon as the > code changes the fun's will get new signatures as there is a hash of the > module included in the fun signature, there is no optimization to keep fun > signatures for this case. > > If you want long living fun's just change the fun to a module fun: > > register(?MODULE, spawn_link(?MODULE, loop, [fun ?MODULE:logger/2])). > > > Cheers, > /Patrik > > On 01/09/2013 09:29 AM, Ivan Glushkov wrote: > > Hi there. > > I do know that using long-lived local function is not a good idea, but > I'm a bit concerned about the following behavior. > > I have a small example: > $ cat my.erl > -module(my). > %-export([foo/0]). > -export([ start/0, loop/1 ]). > > start() -> register(?MODULE, spawn_link(?MODULE, loop, [fun logger/2])). > > %foo() -> apply(fun erlang:now/0, []). > > loop(Logger) -> > receive V -> > io:format("received ~p~n", [V]), > ?MODULE:loop(Logger) > after 100 -> ?MODULE:loop(Logger) > end. > > logger(Msg, Args) -> io:format(Msg, Args). > > > You see, here I save 'fun logger/2' into a loop state, and I don't use > it anymore. > Then if I do the following steps: > - compile and load the code > - start loop > - uncomment foo > - compile and load the code twice > > it kills my process. > > I would understand such a behavior if I didn't use fully qualified > name for the 'loop' function. But I do. > Actually, the same thing is happened if I use a gen_server instead of > loop, and save my variable in it's state. > > I've done some research and compiled to assembler both versions of the > code (attached). > The only valuable difference (beside adding 'foo' surely) is the labels: > > 1. where the anonymous function 'fun logger/2' is defined: > -{function, '-start/0-fun-0-', 2, 14}. > - {label,13}. > +{function, '-start/0-fun-0-', 2, 16}. > + {label,15}. > {line,[{location,"my.erl",5}]}. > {func_info,{atom,my},{atom,'-start/0-fun-0-'},2}. > - {label,14}. > - {call_only,2,{f,8}}. > + {label,16}. > + {call_only,2,{f,10}}. > > 2. where it is used to create a 'Logger' variable: > - {make_fun2,{f,14},0,0,0}. > + {make_fun2,{f,16},0,0,0}. > > 3. where the logger function itself is defined: > -{function, logger, 2, 8}. > - {label,7}. > +{function, logger, 2, 10}. > + {label,9}. > {line,[{location,"my.erl",16}]}. > {func_info,{atom,my},{atom,logger},2}. > - {label,8}. > + {label,10}. > {line,[{location,"my.erl",16}]}. > {call_ext_only,2,{extfunc,io,format,2}}. > > 4. and of course the total number of labels: > -{labels, 15}. > +{labels, 17}. > > I'm not an expert in the field, but it seems to me that this is not a > great deal. Function signature hasn't been changed, I mean name and > arity. Why does it break my code? > > What concerns me is that if for some reason I'm saving some opaque > values (received from the user) in my gen_server state, I can't be > sure that it won't break my code _even if it isn't used_. > I'm almost sure it's a incorrect behavior. > > Best, > Ivan. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From jmakarlsson@REDACTED Wed Jan 9 23:44:34 2013 From: jmakarlsson@REDACTED (J K) Date: Wed, 9 Jan 2013 14:44:34 -0800 (PST) Subject: [erlang-questions] Strings and Text Processing In-Reply-To: References: <65EC42E5-54A3-4556-A3DA-9E949255C1D1@gmail.com> <1357169122.88636.YahooMailNeo@web162801.mail.bf1.yahoo.com> Message-ID: <1357771474.39103.YahooMailNeo@web162801.mail.bf1.yahoo.com> ________________________________ From: Joe Armstrong To: J K Cc: Dmitry Kolesnikov ; Steve Davis ; Erlang Questions Sent: Thursday, January 3, 2013 10:34 AM Subject: Re: [erlang-questions] Strings and Text Processing On Thu, Jan 3, 2013 at 12:25 AM, J K wrote: Hi, > > >I'm not sure I understand your 20.000 files example. This was just to give an estimate of the total memory size ? Are you suggesting that the user should limit the number of erlang processes to the number of cores or are you suggesting that the VM compresses the erlang process data when not running? You could experiment with limiting the number of active processes and compressing data when it's not being used (you'd have to do this yourself as part of the application). To first approximation one process per?parallel?activity is a good rule of thumb (and you let the Erlang scheduler figure out who is to run where) - the alternative is that you limit the number of parallel processes and decide when and where they execute - you are basically saying "because I know a lot about the specific details of my application I can do a better job of ?process management than the Erlang VM" - this is pretty tricky. --- Yes, it would probably take some time to do that. I would rather let the VM limit the number of processes to a number set by the user.? That would be really nice if it can be done with only a small performance penalty, say 10-20%. > >In my case I start 50.000 to 100.000 processes , one per file (it's an (map reduce like) application to do feature extraction for some machine learning algorithms) . How big is each file? how much processing is needed per-file to do feature extraction? --- I would guess most of them are about 200-300KB, but probably vary between 0.1-1MB. This is the parsing part of one of the feature extraction algorithms: Definitions. T = [a-zA-Z0-9!"#?&%/()=??@?$??{\[\]}\\,.\-;:_<>\|^~\*'+?`\s\r\n\t\f\e\b\v\d??] Rules. {T}{T}: {token,TokenChars,pushback(TokenChars)}. {T}: skip_token. Erlang code. pushback([_,X]) -> [X]. It's the character bigram algorithm: http://en.wikipedia.org/wiki/Bigram A special case of n-gram: http://en.wikipedia.org/wiki/N-gram However I just realized I can do this: {T}{T}: {token,list_to_binary(TokenChars),pushback(TokenChars)}. ? One erlang node uses about 7GB of memory. I can probably tune it a bit (a lot?) more by using binaries but it would be nice to have an option to compress process data when not running, for people that are lazy/not an erlang expert/does not have that much time (my case)/or just as an indication of how much memory that could be saved by using binaries. > > look up the manual entry for hibernate/3 http://erlang.org/doc/man/erlang.html#hibernate-3? The hibernate BIF minimise the size of a process before putting it to sleep. It won't compress any process data - but it does trim the stack and heap before suspending a process. If you have a large number of processes that sleep for long times this might be a good idea. If your processes sleep for short times and wake up at random then it probably won't help. Performance tuning is a black art. Unfortunately it's *very* system dependent. If you change the number of cores, or operating system, or amount of memory you have to start again. If in doubt measure ! --- I actually do explicit garbage collection already. I made some measurement of peak memory usage using different combinations of GC, binary, list and fullsweep_after. I might try hibernate later but I'm not sure if it would make any big difference, after all I have 7GB available on each host :) And I can easily add another host if needed. I don't have the files available right now so I copied some include files totaling about 27MB (as reported by du -m). Peak mem usage (using this:?http://www.linuxquestions.org/questions/linux-software-2/how-to-measure-a-programs-peak-memory-consumption-336376/?): Using: {T}{T}: {token,TokenChars,pushback(TokenChars)}. - No explicit GC, no fullsweep_after:? ? ? Min 1318, Max1578, Individual Measurements: 1346, 1318, 1342, 1321, 1587, 1343 MB - No explicit GC, fullsweep_after 0: ? ? Min 1359, Max 1414, Meas: 1361, 1363, 1359, 1414, 1365 MB - Explicit GC, no fullsweep_after: ? ? Min 1009, Max 1093, Meas: 1010, 1015, 1009, 1093, 1015, 1022 MB - Explicit GC, fullsweep_after 0 ? ? Min 840, Max 1193, Meas: 864, 844, 847, 840, 868, 1193, 860, 859 MB,? Using: {T}{T}: {token,list_to_binary(TokenChars),pushback(TokenChars)}. - No explicit GC, no fullsweep_after: ? ? 1215-1232. 1232, 1215, 1225, 1222 MB - No explicit GC, fullsweep_after 0 ? ? 1191-1304. 1205, 1239, 1304, 1267, 1238, 1191, 1220 MB - Explicit GC, no fullsweep_after: ? ? 750-955. 890, 813, 885, 822, 874, 955, 846, 890, 750 MB - Explicit GC, fullsweep_after 0 ? ? 813-822, 822, 820, 813, 815, 821, 817 MB In summary (for my case): using binaries is a good idea but is not critical if using explicit GC and fullsweep_after 0. Also worth mentioning is that I create an ets table for each file to save the parsed result??(working with lists is too slow). This is when the memory usage peaks.? It would also be good if the fullsweep_after option was mentioned in the GC chapter: http://erlang.org/doc/man/erlang.html#garbage_collect-0 Johan /Joe ? JK > > > > > >________________________________ > From: Joe Armstrong >To: Dmitry Kolesnikov >Cc: Steve Davis ; Erlang Questions >Sent: Saturday, December 29, 2012 4:30 PM > >Subject: Re: [erlang-questions] Strings and Text Processing > > > > > > >On Sat, Dec 29, 2012 at 3:20 PM, Dmitry Kolesnikov wrote: > >Hello Steve, >> >>You have raised a good point here. >>One more reason for binary is memory consumption and IPC overhead. >> > > >The point about memory consumption is raised *many* times - on a modern >machine this is not a problem. > > >Example: I am working on a text file of 84KB - in a 32 bit Erlang we use >8 bytes/character - so I use 0.6 MB - I have 4GB memory - so I use 0.015% of >memory - ie no problem. > > >My strategy is to keep large strings as binaries when I'm not working on them, >turn them into lists in order to work on them, and turn them back into binaries >when I'm done. Just because a string starts off in a binary does not mean >that it has to stay as a binary as you work on it. > > > > >Imagine I have a lot of text files, say each of 50KB, I can store 20 per/MB or >20,000 files per GB. Assume I have a quad core. I can only work on four things >at the same time - so having (say) 20,000 files (at 50K) and work on four of them >(unpacked) at a time is another 1.6 Meg. > > >Gigabyte memories mean (among other things) what saving the odd byte here are there is hardly relevant. > > >? >On another hand list allows to represent a code point per element. >> > > >yes - the convenience of having one character per list element far outweighs >the space saving of storing strings in binaries > > >? >iolists are also very handy to dynamically compose a complex strings. >> >>I am afraid that this is an application specific questions? However, I tend to use binary for strings... >> >> > > >My strings change form depending on what I'm doing. Sometimes they are >binaries, sometimes lists, sometimes trees, ... > > >Cheers > > >/Joe > > >? >- Dmitry >> >> >> >>On Dec 29, 2012, at 4:08 PM, Steve Davis wrote: >> >>> Disclaimer :-) All the below is prefixed by a big IMHO >>> >>> Erlang has been correctly criticized for the difficulty of handling "strings". >>> >>> There are two reasons for this (fundamental decisions that were taken way-back-when): >>> 1) "strings" are "just lists of integers" >>> 2) "strings" are by default latin-1 representations >>> >>> This introduces major inconveniences, some of which are not resolvable: >>> When faced with any list during pattern matching, it is not at all easy to determine whether that list is a "string". >>> Further, since strings are "only" a subset of the set of lists of integers, it can be impossible to determine programmatically whether the list is a list of integers or is meant to represent a string. Determining whether a particular list even qualifies as a string in a program requires non-trivial processing of the entire list. >>> >>> It's rather unfortunate that Erlang has earned this reputation, since the truth is that Erlang is truly excellent at text processing. However, to benefit from this excellence, you need to do two things: >>> 1) Represent and process text as binaries. >>> 2) Assume that the text binary is UTF-8 encoded, unless otherwise stated (meaning, e.g. #text{encoding = cstring, value = <<116,101,120,116,0>>}). >>> >>> Suddenly, thanks to binary syntax and pattern matching, processing text in your programs becomes deterministic and easy. (Note that part of the reason for this is that binaries are "expected" to be opaque, whereas general list processing is fundamental to writing any program in Erlang). >>> >>> There's a couple of minor drawbacks, both of which are the result of the initial decisions about "strings": >>> 1) The code is littered with additional angle brackets <<"string">> (annoying, but definitely worth the inconvenience) >>> 2) The standard Erlang/OTP library functions require textual arguments as lists (requiring overuse of binary_to_list) >>> >>> And there are further benefits: >>> 1) Parsing/transcoding different charset encodings is far more straightforward >>> 2) Internationalization/localization is far more straightfoward >>> >>> I wonder if, had the current binary pattern matching/comprehensions been available "way-back-when", whether the decision about "string" representation in Erlang may have been different. (i.e. <<116,101,120,116>> = "text"). >>> >>> Finally, here's my two questions: >>> 1) Is there any benefit at all to the "list representation" of strings above binary text? >>> 2) If not, I wonder if there's any way to change our minds about "strings" as we enter 2013? >>> >>> regs, >>> /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 >> > > >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dujinfang@REDACTED Thu Jan 10 06:01:50 2013 From: dujinfang@REDACTED (Seven Du) Date: Wed, 9 Jan 2013 21:01:50 -0800 (PST) Subject: [erlang-questions] Telnet Client In-Reply-To: <28874.194.88.55.211.1262936149.squirrel@localhost> References: <4B42372A.5020107@eonblast.com> <28874.194.88.55.211.1262936149.squirrel@localhost> Message-ID: <2efecde0-ac6a-442f-a346-1a5ce816e7ae@googlegroups.com> And now http://www.erlang.org/examples/small_examples/index.html is 404 but the mirror is still there ? 2010?1?8????UTC+8??3?35?49??Zoltan Lajos Kis??? > > >> I just wonder why you are referring to the url of a mirror site > >> instead of the original. > >> By the way I don't even know if we link to this mirror site any more. > > > > I remembered that example, googled for it, and just pasted in the link. > > > > Yeah, I also noticed that for most Erlang googling the ftp.sunet.se mirror > is always the first result. Most of the times erlang.org is not even > there... > > I wonder if Google "thinks" erlang.org is a mirror site of ftp.sunet.se. > > Zoltan. > > > ________________________________________________________________ > erlang-questions mailing list. See http://www.erlang.org/faq.html > erlang-questions (at) erlang.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stfairy@REDACTED Thu Jan 10 06:05:22 2013 From: stfairy@REDACTED (Xiao Jia) Date: Thu, 10 Jan 2013 13:05:22 +0800 Subject: [erlang-questions] Thread creation benchmark Message-ID: <20130110050522.GA5932@xjia-desktop> Hi, I just wrote a program trying to see the time cost of thread creation in Erlang. Here "thread" means "Erlang process" actually. My code and plotted result are here: https://gist.github.com/4499544 The idea is to create M x N threads, and measure the time cost for every N threads created. After a thread is created, it sends a message to let the main process continue, and finishes execution. I wonder if this is the right way to do this. Also it seems that Erlang behaves in some pattern periodically according to the figure. Any hint about why? Thanks, Xiao Jia From kenneth.lundin@REDACTED Thu Jan 10 08:14:14 2013 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Thu, 10 Jan 2013 08:14:14 +0100 Subject: [erlang-questions] Telnet Client In-Reply-To: <2efecde0-ac6a-442f-a346-1a5ce816e7ae@googlegroups.com> References: <4B42372A.5020107@eonblast.com> <28874.194.88.55.211.1262936149.squirrel@localhost> <2efecde0-ac6a-442f-a346-1a5ce816e7ae@googlegroups.com> Message-ID: Den 10 jan 2013 06:02 skrev "Seven Du" : > > And now http://www.erlang.org/examples/small_examples/index.html is 404 but the mirror is still there This link to the examples has been removed since several years. New link to examples is http://www.erlang.org/article/7. You can navigate to it via erlang.org/documentation. /Kenneth, Erlang/OTP Ericsson > > ? 2010?1?8????UTC+8??3?35?49??Zoltan Lajos Kis??? >> >> >> I just wonder why you are referring to the url of a mirror site >> >> instead of the original. >> >> By the way I don't even know if we link to this mirror site any more. >> > >> > I remembered that example, googled for it, and just pasted in the link. >> > >> >> Yeah, I also noticed that for most Erlang googling the ftp.sunet.semirror >> is always the first result. Most of the times erlang.org is not even >> there... >> >> I wonder if Google "thinks" erlang.org is a mirror site of ftp.sunet.se. >> >> Zoltan. >> >> >> ________________________________________________________________ >> erlang-questions mailing list. See http://www.erlang.org/faq.html >> erlang-questions (at) erlang.org > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Thu Jan 10 11:39:26 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 10 Jan 2013 11:39:26 +0100 Subject: [erlang-questions] Thread creation benchmark In-Reply-To: <20130110050522.GA5932@xjia-desktop> References: <20130110050522.GA5932@xjia-desktop> Message-ID: <34A721EB-00EB-4226-9C74-4A2EBEA62E95@erlang-solutions.com> On Jan 10, 2013, at 6:05 AM, Xiao Jia wrote: > Hi, > > I just wrote a program trying to see the time cost of thread creation > in Erlang. Here "thread" means "Erlang process" actually. > Why are you interested in process creation speed? Since all your processes die immediately, a guess could be you are seeing the memory allocator kick in. Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen From watson.timothy@REDACTED Thu Jan 10 12:59:25 2013 From: watson.timothy@REDACTED (Tim Watson) Date: Thu, 10 Jan 2013 11:59:25 +0000 Subject: [erlang-questions] Thread creation benchmark In-Reply-To: <20130110050522.GA5932@xjia-desktop> References: <20130110050522.GA5932@xjia-desktop> Message-ID: <58CE5764-E032-4AED-AFC9-3DA53AA6CEF6@gmail.com> On 10 Jan 2013, at 05:05, Xiao Jia wrote: > The idea is to create M x N threads, and measure the time cost for > every N threads created. After a thread is created, it sends a message > to let the main process continue, and finishes execution. > Why do you make the main thread wait for each thread to respond that it has started? Aren't you therefore measuring the time it takes for the communication with to the 'creator' to take place as well in this case? That's not measuring process creation time, it's measuring that *plus* the time it takes to enqueue a response and for the main process to dequeue that message, plus of course the effect that scheduling has on all of this. The expression `[spawn(fun() -> (receive stop -> ok end) end) || _ <- lists:seq(1, N)]` will measuring creation time only. You can use timer:tc and the value of N to calculate the average cost. Spawning is essentially an asynchronous operation, and the semantics aren't defined except that you get back a process identifier once the process is *alive*. The use of erlang:spawn/1 therefore *does* measure the cost of spawning a process properly, thus timer:tc with spawn/1 is a reasonable way to measure this I think. From watson.timothy@REDACTED Thu Jan 10 13:16:01 2013 From: watson.timothy@REDACTED (Tim Watson) Date: Thu, 10 Jan 2013 12:16:01 +0000 Subject: [erlang-questions] Thread creation benchmark In-Reply-To: <20130110121144.GA19470@xjia-desktop> References: <20130110050522.GA5932@xjia-desktop> <58CE5764-E032-4AED-AFC9-3DA53AA6CEF6@gmail.com> <20130110121144.GA19470@xjia-desktop> Message-ID: <88D1ECD1-DF1B-4BC4-A477-562CD222E751@gmail.com> On 10 Jan 2013, at 12:11, Xiao Jia wrote: > On Thu, Jan 10, 2013 at 11:59:25AM +0000, Tim Watson wrote: >> On 10 Jan 2013, at 05:05, Xiao Jia wrote: >> >>> The idea is to create M x N threads, and measure the time cost for >>> every N threads created. After a thread is created, it sends a message >>> to let the main process continue, and finishes execution. >>> >> >> Why do you make the main thread wait for each thread to respond that it has started? Aren't you therefore measuring the time it takes for the communication with to the 'creator' to take place as well in this case? That's not measuring process creation time, it's measuring that *plus* the time it takes to enqueue a response and for the main process to dequeue that message, plus of course the effect that scheduling has on all of this. >> >> The expression `[spawn(fun() -> (receive stop -> ok end) end) || _ <- lists:seq(1, N)]` will measuring creation time only. You can use timer:tc and the value of N to calculate the average cost. >> >> Spawning is essentially an asynchronous operation, and the semantics aren't defined except that you get back a process identifier once the process is *alive*. The use of erlang:spawn/1 therefore *does* measure the cost of spawning a process properly, thus timer:tc with spawn/1 is a reasonable way to measure this I think. > > Thanks. You are right, that's not only creation time. I merely test > something not computation intensive but appears frequently. I'm not sure what you mean by this, but then I'm not really sure what you're trying to measure either. Presumably you're measuring in order to help make design decisions about the code you're writing, so it may be more helpful if you explain what you're trying to achieve so we can suggest the best kind of benchmarks for your needs. Cheers, Tim From straightflush@REDACTED Thu Jan 10 15:11:16 2013 From: straightflush@REDACTED (AD) Date: Thu, 10 Jan 2013 09:11:16 -0500 Subject: [erlang-questions] cowboy throwing a routing error Message-ID: hello, Using sockjs and the latest cowboy/ranch, I am running into a badarg error with cowboy_router. Not sure what is causing this, i captured the debug info here in this gist https://gist.github.com/4502255 I am starting like this SockjsState = sockjs_handler:init_state(<<"/socket">>,fun wsocket_handler/3, state, []), VRoutes = [{[<<"socket">>, '...'], sockjs_cowboy_handler, SockjsState}, {'_', ?MODULE, []}], Routes = [{'_', VRoutes}], lager:info("Starting the cowboy listener on port ~p..~n",[?COWBOY_HTTP_PORT]), cowboy:start_http(my_http_listener, ?COWBOY_HTTP_ACCEPTORS, [{port, ?COWBOY_HTTP_PORT}], [{dispatch, Routes}]). But the call to lists:keyfind(dispatch, 1, Env) seems to be failing for some reason. Any ideas ? Thanks - AD -------------- next part -------------- An HTML attachment was scrubbed... URL: From yurinvv@REDACTED Thu Jan 10 15:22:58 2013 From: yurinvv@REDACTED (Slava Yurin) Date: Thu, 10 Jan 2013 21:22:58 +0700 Subject: [erlang-questions] cowboy throwing a routing error In-Reply-To: References: Message-ID: <939941357827778@web20h.yandex.ru> An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Thu Jan 10 15:24:17 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 10 Jan 2013 09:24:17 -0500 Subject: [erlang-questions] cowboy throwing a routing error In-Reply-To: References: Message-ID: <20130110142416.GB31728@ferdmbp.local> The latest cowboy now uses [{env, [{dispatch, Routes}]}] as its options for the dispatching rather than the old format. I got the same error yesterday and this fixed it. The documentation didn't follow through with the changes, but that's what we get for using the bleeding edge rather than tagged versions. Regards, Fred. On 01/10, AD wrote: > hello, > > Using sockjs and the latest cowboy/ranch, I am running into a badarg > error with cowboy_router. Not sure what is causing this, i captured the > debug info here in this gist > > https://gist.github.com/4502255 > > I am starting like this > > SockjsState = sockjs_handler:init_state(<<"/socket">>,fun > wsocket_handler/3, state, []), > > VRoutes = [{[<<"socket">>, '...'], sockjs_cowboy_handler, SockjsState}, > > {'_', ?MODULE, []}], > Routes = [{'_', VRoutes}], > > lager:info("Starting the cowboy listener on port ~p..~n",[?COWBOY_HTTP_PORT]), > > cowboy:start_http(my_http_listener, ?COWBOY_HTTP_ACCEPTORS, [{port, > ?COWBOY_HTTP_PORT}], [{dispatch, Routes}]). > > But the call to lists:keyfind(dispatch, 1, Env) seems to be failing > for some reason. > > Any ideas ? > > Thanks > - AD > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From straightflush@REDACTED Thu Jan 10 15:49:47 2013 From: straightflush@REDACTED (AD) Date: Thu, 10 Jan 2013 09:49:47 -0500 Subject: [erlang-questions] cowboy throwing a routing error In-Reply-To: <20130110142416.GB31728@ferdmbp.local> References: <20130110142416.GB31728@ferdmbp.local> Message-ID: Hmm that helped, but now a different error about a compress param is showing up Error in process <0.989.0> on node 'example@REDACTED' with exit value: {badarg,[{lists,keyfind,[compress,1,{env,[{dispatch,[{'_',[{[<<6 bytes>>,'...'],sockjs_cowboy_handler,{service,"/socket",#Fun,[{callback,example_callback}]," https://d1fxtkz8shb9d2.cloudfront.net/sockjs-0.3.min.js",false... 09:45:40.850 [error] Supervisor ranch_conns_sup had child ranch_conns_sup started with {ranch_conns_sup,start_protocol,undefined} at <0.989.0> exit with reason bad argument in call to lists:keyfind(compress, 1, {env,[{dispatch,[{'_',[{[<<"socket">>,'...'],sockjs_cowboy_handler,{service,"/socket",#Fun,...}},...]}]}]}) in cowboy_protocol:get_value/3 line 97 in context child_terminated On Thu, Jan 10, 2013 at 9:24 AM, Fred Hebert wrote: > The latest cowboy now uses [{env, [{dispatch, Routes}]}] as its options > for the dispatching rather than the old format. > > I got the same error yesterday and this fixed it. The documentation didn't > follow through with the changes, but that's what we get for using the > bleeding edge rather than tagged versions. > > Regards, > Fred. > > On 01/10, AD wrote: > > hello, > > > > Using sockjs and the latest cowboy/ranch, I am running into a badarg > > error with cowboy_router. Not sure what is causing this, i captured the > > debug info here in this gist > > > > https://gist.github.com/4502255 > > > > I am starting like this > > > > SockjsState = sockjs_handler:init_state(<<"/socket">>,fun > > wsocket_handler/3, state, []), > > > > VRoutes = [{[<<"socket">>, '...'], sockjs_cowboy_handler, SockjsState}, > > > > {'_', ?MODULE, []}], > > Routes = [{'_', VRoutes}], > > > > lager:info("Starting the cowboy listener on port > ~p..~n",[?COWBOY_HTTP_PORT]), > > > > cowboy:start_http(my_http_listener, ?COWBOY_HTTP_ACCEPTORS, [{port, > > ?COWBOY_HTTP_PORT}], [{dispatch, Routes}]). > > > > But the call to lists:keyfind(dispatch, 1, Env) seems to be failing > > for some reason. > > > > Any ideas ? > > > > Thanks > > - AD > > > _______________________________________________ > > 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 Jan 10 15:53:06 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 10 Jan 2013 09:53:06 -0500 Subject: [erlang-questions] cowboy throwing a routing error In-Reply-To: References: <20130110142416.GB31728@ferdmbp.local> Message-ID: <20130110145305.GD31728@ferdmbp.local> It seems like you just passed through an env tuple and forgot to put it in a list. Note the usage of [{env, ...}], not just {env, ...}. Regards, Fred. On 01/10, AD wrote: > Hmm that helped, but now a different error about a compress param is > showing up > > Error in process <0.989.0> on node 'example@REDACTED' with exit value: > {badarg,[{lists,keyfind,[compress,1,{env,[{dispatch,[{'_',[{[<<6 > bytes>>,'...'],sockjs_cowboy_handler,{service,"/socket",#Fun,[{callback,example_callback}]," > https://d1fxtkz8shb9d2.cloudfront.net/sockjs-0.3.min.js",false... > > > 09:45:40.850 [error] Supervisor ranch_conns_sup had child ranch_conns_sup > started with {ranch_conns_sup,start_protocol,undefined} at <0.989.0> exit > with reason bad argument in call to lists:keyfind(compress, 1, > {env,[{dispatch,[{'_',[{[<<"socket">>,'...'],sockjs_cowboy_handler,{service,"/socket",#Fun,...}},...]}]}]}) > in cowboy_protocol:get_value/3 line 97 in context child_terminated > > > On Thu, Jan 10, 2013 at 9:24 AM, Fred Hebert wrote: > > > The latest cowboy now uses [{env, [{dispatch, Routes}]}] as its options > > for the dispatching rather than the old format. > > > > I got the same error yesterday and this fixed it. The documentation didn't > > follow through with the changes, but that's what we get for using the > > bleeding edge rather than tagged versions. > > > > Regards, > > Fred. > > > > On 01/10, AD wrote: > > > hello, > > > > > > Using sockjs and the latest cowboy/ranch, I am running into a badarg > > > error with cowboy_router. Not sure what is causing this, i captured the > > > debug info here in this gist > > > > > > https://gist.github.com/4502255 > > > > > > I am starting like this > > > > > > SockjsState = sockjs_handler:init_state(<<"/socket">>,fun > > > wsocket_handler/3, state, []), > > > > > > VRoutes = [{[<<"socket">>, '...'], sockjs_cowboy_handler, SockjsState}, > > > > > > {'_', ?MODULE, []}], > > > Routes = [{'_', VRoutes}], > > > > > > lager:info("Starting the cowboy listener on port > > ~p..~n",[?COWBOY_HTTP_PORT]), > > > > > > cowboy:start_http(my_http_listener, ?COWBOY_HTTP_ACCEPTORS, [{port, > > > ?COWBOY_HTTP_PORT}], [{dispatch, Routes}]). > > > > > > But the call to lists:keyfind(dispatch, 1, Env) seems to be failing > > > for some reason. > > > > > > Any ideas ? > > > > > > Thanks > > > - AD > > > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > From comptekki@REDACTED Thu Jan 10 16:43:43 2013 From: comptekki@REDACTED (Wes James) Date: Thu, 10 Jan 2013 08:43:43 -0700 Subject: [erlang-questions] cowboy throwing a routing error In-Reply-To: References: Message-ID: Like this.... {ok, _} = cowboy:start_http( http, 100, [{port, HTTP_Port}], [{env, [{dispatch, Dispatch}]}] ) wes On Thu, Jan 10, 2013 at 7:11 AM, AD wrote: > hello, > > Using sockjs and the latest cowboy/ranch, I am running into a badarg > error with cowboy_router. Not sure what is causing this, i captured the > debug info here in this gist > > https://gist.github.com/4502255 > > I am starting like this > > SockjsState = sockjs_handler:init_state(<<"/socket">>,fun wsocket_handler/3, state, []), > > VRoutes = [{[<<"socket">>, '...'], sockjs_cowboy_handler, SockjsState}, > > > {'_', ?MODULE, []}], > Routes = [{'_', VRoutes}], > > > lager:info("Starting the cowboy listener on port ~p..~n",[?COWBOY_HTTP_PORT]), > > > cowboy:start_http(my_http_listener, ?COWBOY_HTTP_ACCEPTORS, [{port, ?COWBOY_HTTP_PORT}], [{dispatch, Routes}]). > > But the call to lists:keyfind(dispatch, 1, Env) seems to be failing for some reason. > > Any ideas ? > > Thanks > - AD > > > _______________________________________________ > 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 Jan 10 20:36:32 2013 From: erlang@REDACTED (Erik Reitsma) Date: Thu, 10 Jan 2013 20:36:32 +0100 Subject: [erlang-questions] Erlang for Android release suggestions? Message-ID: <50EF1840.1090909@ernovation.com> Hi all, I have ported Erlang/OTP R15B03 to Android, to work with Scripting Layer for Android (SL4A). This involved some patches to the Erlang/OTP source and build scripts (configure, Makefile, etc). I also wrote the installation app to install is under SL4A. Access to the SL4A API is provided, but I have not tried all available functions. I have included all OTP applications except the ones that are only useful with a gui. It is possible to use the interactive shell or to specify a .erl file (which will be compiled if not yet compiled) and run its main/0 function. I have tried the port on some Android devices, and it worked on all of them. The device does not need to be rooted to use the port. What would be the best way to release this to the public, considering the license of Erlang/OTP? Should I put the entire source on some repository provider, or just a script that will modify the original Erlang/OTP sources? Regards, *Erik. From mononcqc@REDACTED Thu Jan 10 20:47:05 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 10 Jan 2013 14:47:05 -0500 Subject: [erlang-questions] [ANN] Learn You Some Erlang now in Dead Tree Form! Message-ID: <20130110194704.GC70640@ferdmbp.local> Hi everyone, I think a lot of people on this list are now familiar with the existence of Learn You Some Erlang for Great Good!, my website/tutorial about Erlang. I've been working with the crew at No Starch Press for over a year now to bring it down to a softcover book containing 624 pages. It's also available as a DRM-Free ebook (PDF, Mobi, ePub). If you buy the paper copy, you also get the ebook for free. You can get it from http://nostarch.com/erlang Moreover, the team at No Starch is kicking it with 40% off if you buy it with the CONCURRENT coupon code (see http://nostar.ch/erlang_promo for details). It also contains a sticker. The website will keep being accessible and free. The book versions have the advantage of having gone through professional editing and reviewing, corrections to wording and explanations, and much nicer format to be read in. Thanks for everyone's support while I was working on LYSE during the last few years, and enjoy! Regards, Fred. From mallen@REDACTED Thu Jan 10 21:15:20 2013 From: mallen@REDACTED (Mark Allen) Date: Thu, 10 Jan 2013 14:15:20 -0600 Subject: [erlang-questions] Celery-like task queue applications? Message-ID: Hello lazy-web :) Are there any celery-like task queue implementations / applications for Erlang? Thanks. Mark From daniel.goertzen@REDACTED Thu Jan 10 21:15:51 2013 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Thu, 10 Jan 2013 14:15:51 -0600 Subject: [erlang-questions] [ANN] Learn You Some Erlang now in Dead Tree Form! In-Reply-To: <20130110194704.GC70640@ferdmbp.local> References: <20130110194704.GC70640@ferdmbp.local> Message-ID: Sold! Nice work. Dan. On Thu, Jan 10, 2013 at 1:47 PM, Fred Hebert wrote: > Hi everyone, > > I think a lot of people on this list are now familiar with the existence > of Learn You Some Erlang for Great Good!, my website/tutorial about > Erlang. > > I've been working with the crew at No Starch Press for over a year now > to bring it down to a softcover book containing 624 pages. It's also > available as a DRM-Free ebook (PDF, Mobi, ePub). If you buy the paper > copy, you also get the ebook for free. You can get it from > http://nostarch.com/erlang > > Moreover, the team at No Starch is kicking it with 40% off if you buy it > with the CONCURRENT coupon code (see http://nostar.ch/erlang_promo for > details). It also contains a sticker. > > The website will keep being accessible and free. The book versions have > the advantage of having gone through professional editing and reviewing, > corrections to wording and explanations, and much nicer format to be > read in. > > Thanks for everyone's support while I was working on LYSE during the > last few years, and enjoy! > > 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 gumm@REDACTED Thu Jan 10 22:28:57 2013 From: gumm@REDACTED (Jesse Gumm) Date: Thu, 10 Jan 2013 15:28:57 -0600 Subject: [erlang-questions] [ANN] Learn You Some Erlang now in Dead Tree Form! In-Reply-To: <20130110194704.GC70640@ferdmbp.local> References: <20130110194704.GC70640@ferdmbp.local> Message-ID: Big time congrats! On Jan 10, 2013 1:47 PM, "Fred Hebert" wrote: > Hi everyone, > > I think a lot of people on this list are now familiar with the existence > of Learn You Some Erlang for Great Good!, my website/tutorial about > Erlang. > > I've been working with the crew at No Starch Press for over a year now > to bring it down to a softcover book containing 624 pages. It's also > available as a DRM-Free ebook (PDF, Mobi, ePub). If you buy the paper > copy, you also get the ebook for free. You can get it from > http://nostarch.com/erlang > > Moreover, the team at No Starch is kicking it with 40% off if you buy it > with the CONCURRENT coupon code (see http://nostar.ch/erlang_promo for > details). It also contains a sticker. > > The website will keep being accessible and free. The book versions have > the advantage of having gone through professional editing and reviewing, > corrections to wording and explanations, and much nicer format to be > read in. > > Thanks for everyone's support while I was working on LYSE during the > last few years, and enjoy! > > 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 Jan 10 22:29:48 2013 From: erlang@REDACTED (Erik Reitsma) Date: Thu, 10 Jan 2013 22:29:48 +0100 Subject: [erlang-questions] Erlang for Android release suggestions? In-Reply-To: References: <50EF1840.1090909@ernovation.com> Message-ID: <50EF32CC.3080308@ernovation.com> An HTML attachment was scrubbed... URL: From erlang@REDACTED Thu Jan 10 22:30:44 2013 From: erlang@REDACTED (Erik Reitsma) Date: Thu, 10 Jan 2013 22:30:44 +0100 Subject: [erlang-questions] Erlang for Android release suggestions? In-Reply-To: References: <50EF1840.1090909@ernovation.com> Message-ID: <50EF3304.9030907@ernovation.com> An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Thu Jan 10 22:36:45 2013 From: bchesneau@REDACTED (Benoit Chesneau) Date: Thu, 10 Jan 2013 22:36:45 +0100 Subject: [erlang-questions] Erlang for Android release suggestions? In-Reply-To: <50EF3304.9030907@ernovation.com> References: <50EF1840.1090909@ernovation.com> <50EF3304.9030907@ernovation.com> Message-ID: On Thu, Jan 10, 2013 at 10:30 PM, Erik Reitsma wrote: > An example is a good idea. It also forces me to try some features of the > SL4A framework. Is there a very simple chat client & server example > available that I could adapt? > When I have a working example, I will put it all up on github. I hope I > will get it done this weekend. > > Regards, > *Erik. > > If you put the source online I can eventually try to port my current couchdb work on it. For now I'm using erlang r14b03 on android... - beno?t -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Thu Jan 10 22:37:01 2013 From: bchesneau@REDACTED (Benoit Chesneau) Date: Thu, 10 Jan 2013 22:37:01 +0100 Subject: [erlang-questions] Fwd: Erlang for Android release suggestions? In-Reply-To: References: <50EF1840.1090909@ernovation.com> Message-ID: ---------- Forwarded message ---------- From: Benoit Chesneau Date: Thu, Jan 10, 2013 at 9:25 PM Subject: Re: [erlang-questions] Erlang for Android release suggestions? To: erlang@REDACTED On Thu, Jan 10, 2013 at 8:36 PM, Erik Reitsma wrote: > Hi all, > > I have ported Erlang/OTP R15B03 to Android, to work with Scripting Layer > for Android (SL4A). This involved some patches to the Erlang/OTP source and > build scripts (configure, Makefile, etc). I also wrote the installation app > to install is under SL4A. Access to the SL4A API is provided, but I have > not tried all available functions. I have included all OTP applications > except the ones that are only useful with a gui. > > It is possible to use the interactive shell or to specify a .erl file > (which will be compiled if not yet compiled) and run its main/0 function. > > I have tried the port on some Android devices, and it worked on all of > them. The device does not need to be rooted to use the port. > > What would be the best way to release this to the public, considering the > license of Erlang/OTP? Should I put the entire source on some repository > provider, or just a script that will modify the original Erlang/OTP sources? > > Regards, > *Erik. > > Nice! I would say that any public repository either or github or the one you prefer is good. So anyone could review it. Putting patches in a branch is a common practice imo. - beno?t -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Thu Jan 10 22:48:25 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Thu, 10 Jan 2013 22:48:25 +0100 Subject: [erlang-questions] [ANN] Learn You Some Erlang now in Dead Tree Form! In-Reply-To: <20130110194704.GC70640@ferdmbp.local> References: <20130110194704.GC70640@ferdmbp.local> Message-ID: <50EF3729.5000908@ninenines.eu> Yipee!! On 01/10/2013 08:47 PM, Fred Hebert wrote: > Hi everyone, > > I think a lot of people on this list are now familiar with the existence > of Learn You Some Erlang for Great Good!, my website/tutorial about > Erlang. > > I've been working with the crew at No Starch Press for over a year now > to bring it down to a softcover book containing 624 pages. It's also > available as a DRM-Free ebook (PDF, Mobi, ePub). If you buy the paper > copy, you also get the ebook for free. You can get it from > http://nostarch.com/erlang > > Moreover, the team at No Starch is kicking it with 40% off if you buy it > with the CONCURRENT coupon code (see http://nostar.ch/erlang_promo for > details). It also contains a sticker. > > The website will keep being accessible and free. The book versions have > the advantage of having gone through professional editing and reviewing, > corrections to wording and explanations, and much nicer format to be > read in. > > Thanks for everyone's support while I was working on LYSE during the > last few years, and enjoy! > > Regards, > Fred. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From straightflush@REDACTED Thu Jan 10 23:08:40 2013 From: straightflush@REDACTED (AD) Date: Thu, 10 Jan 2013 17:08:40 -0500 Subject: [erlang-questions] [ANN] Learn You Some Erlang now in Dead Tree Form! In-Reply-To: <50EF3729.5000908@ninenines.eu> References: <20130110194704.GC70640@ferdmbp.local> <50EF3729.5000908@ninenines.eu> Message-ID: sold, best resource out there, congrats ! On Thu, Jan 10, 2013 at 4:48 PM, Lo?c Hoguin wrote: > Yipee!! > > > On 01/10/2013 08:47 PM, Fred Hebert wrote: > >> Hi everyone, >> >> I think a lot of people on this list are now familiar with the existence >> of Learn You Some Erlang for Great Good!, my website/tutorial about >> Erlang. >> >> I've been working with the crew at No Starch Press for over a year now >> to bring it down to a softcover book containing 624 pages. It's also >> available as a DRM-Free ebook (PDF, Mobi, ePub). If you buy the paper >> copy, you also get the ebook for free. You can get it from >> http://nostarch.com/erlang >> >> Moreover, the team at No Starch is kicking it with 40% off if you buy it >> with the CONCURRENT coupon code (see http://nostar.ch/erlang_promo for >> details). It also contains a sticker. >> >> The website will keep being accessible and free. The book versions have >> the advantage of having gone through professional editing and reviewing, >> corrections to wording and explanations, and much nicer format to be >> read in. >> >> Thanks for everyone's support while I was working on LYSE during the >> last few years, and enjoy! >> >> Regards, >> Fred. >> ______________________________**_________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/**listinfo/erlang-questions >> >> > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > 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 jeremy@REDACTED Thu Jan 10 23:14:06 2013 From: jeremy@REDACTED (Jeremy Ong) Date: Thu, 10 Jan 2013 14:14:06 -0800 Subject: [erlang-questions] [ANN] Learn You Some Erlang now in Dead Tree Form! In-Reply-To: <50EF3729.5000908@ninenines.eu> References: <20130110194704.GC70640@ferdmbp.local> <50EF3729.5000908@ninenines.eu> Message-ID: Congrats! Got two copies for the office :) On Thu, Jan 10, 2013 at 1:48 PM, Lo?c Hoguin wrote: > Yipee!! > > > On 01/10/2013 08:47 PM, Fred Hebert wrote: > >> Hi everyone, >> >> I think a lot of people on this list are now familiar with the existence >> of Learn You Some Erlang for Great Good!, my website/tutorial about >> Erlang. >> >> I've been working with the crew at No Starch Press for over a year now >> to bring it down to a softcover book containing 624 pages. It's also >> available as a DRM-Free ebook (PDF, Mobi, ePub). If you buy the paper >> copy, you also get the ebook for free. You can get it from >> http://nostarch.com/erlang >> >> Moreover, the team at No Starch is kicking it with 40% off if you buy it >> with the CONCURRENT coupon code (see http://nostar.ch/erlang_promo for >> details). It also contains a sticker. >> >> The website will keep being accessible and free. The book versions have >> the advantage of having gone through professional editing and reviewing, >> corrections to wording and explanations, and much nicer format to be >> read in. >> >> Thanks for everyone's support while I was working on LYSE during the >> last few years, and enjoy! >> >> Regards, >> Fred. >> ______________________________**_________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/**listinfo/erlang-questions >> >> > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > 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 rtrlists@REDACTED Thu Jan 10 23:48:24 2013 From: rtrlists@REDACTED (Robert Raschke) Date: Thu, 10 Jan 2013 22:48:24 +0000 Subject: [erlang-questions] Celery-like task queue applications? In-Reply-To: References: Message-ID: I'm not sure, but maybe Disco ( http://discoproject.org/) might be of interest. Robby On Jan 10, 2013 8:15 PM, "Mark Allen" wrote: > Hello lazy-web :) > > Are there any celery-like task queue implementations / applications for > Erlang? > > Thanks. > > Mark > > > > _______________________________________________ > 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 Fri Jan 11 00:04:50 2013 From: mjtruog@REDACTED (Michael Truog) Date: Thu, 10 Jan 2013 15:04:50 -0800 Subject: [erlang-questions] Celery-like task queue applications? In-Reply-To: References: Message-ID: <50EF4912.7080309@gmail.com> CloudI exists http://cloudi.org, but: - it currently lacks many of the features of celery, like task persistence - it deals with messages which puts the serialize/deserialize burden on you (more flexibility) RabbitMQ might be closer to what you want, http://www.rabbitmq.com/ On 01/10/2013 12:15 PM, Mark Allen wrote: > Hello lazy-web :) > > Are there any celery-like task queue implementations / applications for > Erlang? > > Thanks. > > Mark > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From steven.charles.davis@REDACTED Fri Jan 11 00:36:42 2013 From: steven.charles.davis@REDACTED (Steve Davis) Date: Thu, 10 Jan 2013 17:36:42 -0600 Subject: [erlang-questions] Guaranteed Delivery over a Network Message-ID: News announcement from MIT... http://phys.org/news/2013-01-algorithm-message-dissemination-decentralized-networks.html ...which I think refers to this... http://arxiv.org/abs/1210.1193 - of interest to many of us? /s -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.girondel@REDACTED Fri Jan 11 01:49:38 2013 From: olivier.girondel@REDACTED (Olivier Girondel) Date: Fri, 11 Jan 2013 01:49:38 +0100 Subject: [erlang-questions] [ANN] Learn You Some Erlang now in Dead Tree Form! In-Reply-To: <20130110194704.GC70640@ferdmbp.local> References: <20130110194704.GC70640@ferdmbp.local> Message-ID: Congrats, great work ! -- Olivier - http://biniou.net On 10 janv. 2013, at 20:47, Fred Hebert wrote: > Hi everyone, > > I think a lot of people on this list are now familiar with the existence > of Learn You Some Erlang for Great Good!, my website/tutorial about > Erlang. > > I've been working with the crew at No Starch Press for over a year now > to bring it down to a softcover book containing 624 pages. It's also > available as a DRM-Free ebook (PDF, Mobi, ePub). If you buy the paper > copy, you also get the ebook for free. You can get it from > http://nostarch.com/erlang > > Moreover, the team at No Starch is kicking it with 40% off if you buy it > with the CONCURRENT coupon code (see http://nostar.ch/erlang_promo for > details). It also contains a sticker. > > The website will keep being accessible and free. The book versions have > the advantage of having gone through professional editing and reviewing, > corrections to wording and explanations, and much nicer format to be > read in. > > Thanks for everyone's support while I was working on LYSE during the > last few years, and enjoy! > > Regards, > Fred. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From mjtruog@REDACTED Fri Jan 11 01:53:08 2013 From: mjtruog@REDACTED (Michael Truog) Date: Thu, 10 Jan 2013 16:53:08 -0800 Subject: [erlang-questions] [ANN] Learn You Some Erlang now in Dead Tree Form! In-Reply-To: <20130110194704.GC70640@ferdmbp.local> References: <20130110194704.GC70640@ferdmbp.local> Message-ID: <50EF6274.8050407@gmail.com> Congrats! On 01/10/2013 11:47 AM, Fred Hebert wrote: > Hi everyone, > > I think a lot of people on this list are now familiar with the existence > of Learn You Some Erlang for Great Good!, my website/tutorial about > Erlang. > > I've been working with the crew at No Starch Press for over a year now > to bring it down to a softcover book containing 624 pages. It's also > available as a DRM-Free ebook (PDF, Mobi, ePub). If you buy the paper > copy, you also get the ebook for free. You can get it from > http://nostarch.com/erlang > > Moreover, the team at No Starch is kicking it with 40% off if you buy it > with the CONCURRENT coupon code (see http://nostar.ch/erlang_promo for > details). It also contains a sticker. > > The website will keep being accessible and free. The book versions have > the advantage of having gone through professional editing and reviewing, > corrections to wording and explanations, and much nicer format to be > read in. > > Thanks for everyone's support while I was working on LYSE during the > last few years, and enjoy! > > Regards, > Fred. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From kenji.rikitake@REDACTED Fri Jan 11 02:37:58 2013 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Fri, 11 Jan 2013 10:37:58 +0900 Subject: [erlang-questions] OS lib patch required for Erlang dtrace-enabled VM on FreeBSD Message-ID: <20130111013758.GA33677@k2r.org> If you want to build a dtrace-enabled VM on FreeBSD 9.1-STABLE, check out this Problem Report http://www.freebsd.org/cgi/query-pr.cgi?pr=171678 and apply the OS library patch provided in the PR. My FreeBSD Erlang Port is duly updated and FYI the summary is here: https://github.com/jj1bdx/erlang-freebsd-port/blob/master/PR-171678-dtrace-patch/fix-dtrace-build.md Thanks to Jimmy Olgeni, the hard-working FreeBSD Port maintainer of lang/erlang and other great tools. FYI Kenji Rikitake From zacma36@REDACTED Fri Jan 11 06:05:31 2013 From: zacma36@REDACTED (zac ma) Date: Fri, 11 Jan 2013 13:05:31 +0800 Subject: [erlang-questions] [ANN] Learn You Some Erlang now in Dead Tree Form! In-Reply-To: <50EF6274.8050407@gmail.com> References: <20130110194704.GC70640@ferdmbp.local> <50EF6274.8050407@gmail.com> Message-ID: good On Fri, Jan 11, 2013 at 8:53 AM, Michael Truog wrote: > Congrats! > > > On 01/10/2013 11:47 AM, Fred Hebert wrote: > >> Hi everyone, >> >> I think a lot of people on this list are now familiar with the existence >> of Learn You Some Erlang for Great Good!, my website/tutorial about >> Erlang. >> >> I've been working with the crew at No Starch Press for over a year now >> to bring it down to a softcover book containing 624 pages. It's also >> available as a DRM-Free ebook (PDF, Mobi, ePub). If you buy the paper >> copy, you also get the ebook for free. You can get it from >> http://nostarch.com/erlang >> >> Moreover, the team at No Starch is kicking it with 40% off if you buy it >> with the CONCURRENT coupon code (see http://nostar.ch/erlang_promo for >> details). It also contains a sticker. >> >> The website will keep being accessible and free. The book versions have >> the advantage of having gone through professional editing and reviewing, >> corrections to wording and explanations, and much nicer format to be >> read in. >> >> Thanks for everyone's support while I was working on LYSE during the >> last few years, and enjoy! >> >> 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 mabrek@REDACTED Fri Jan 11 08:32:07 2013 From: mabrek@REDACTED (Anton Lebedevich) Date: Fri, 11 Jan 2013 11:32:07 +0400 Subject: [erlang-questions] what is the "race condition bug in core Erlang" mentioned by @damienkatz? Message-ID: <50EFBFF7.8020103@gmail.com> Hello. In the article http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html he writes about "race condition bug in core Erlang". I wonder is that bug known/reported/fixed? Is there more detailed description of it? Regards, Anton Lebedevich. From jeremy@REDACTED Fri Jan 11 08:41:29 2013 From: jeremy@REDACTED (Jeremy Ong) Date: Thu, 10 Jan 2013 23:41:29 -0800 Subject: [erlang-questions] what is the "race condition bug in core Erlang" mentioned by @damienkatz? In-Reply-To: <50EFBFF7.8020103@gmail.com> References: <50EFBFF7.8020103@gmail.com> Message-ID: To quote the section of interest: "At Couchbase we recently spent easily 2+ man/months dealing with a crash in the Erlang VM. We wasted a ton of time tracking down something that was in the core Erlang implementation, never sure what was happening or why, thinking perhaps the flaw was something in our own plug-in C code, hoping it was something we could find and fix. It wasn't, it was a race condition bug in core Erlang. We only found the problem via code inspection of Erlang. This is a fundamental problem in any language that abstracts away too much of the computer." I'm also interested in what he was doing to come across this "bug." On Thu, Jan 10, 2013 at 11:32 PM, Anton Lebedevich wrote: > Hello. > > In the article > http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html > he writes about "race condition bug in core Erlang". > > I wonder is that bug known/reported/fixed? Is there more detailed > description of it? > > Regards, > Anton Lebedevich. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From demeshchuk@REDACTED Fri Jan 11 09:23:03 2013 From: demeshchuk@REDACTED (Dmitry Demeshchuk) Date: Fri, 11 Jan 2013 12:23:03 +0400 Subject: [erlang-questions] what is the "race condition bug in core Erlang" mentioned by @damienkatz? In-Reply-To: <50EFBFF7.8020103@gmail.com> References: <50EFBFF7.8020103@gmail.com> Message-ID: Sorry for my whole answer being too sarcastic. He asked that on twitter several months ago: https://twitter.com/damienkatz/statuses/247816369863798785 I searched if he actually asked anything on mailing list (here, or at erlang-bugs), but he didn't. And there doesn't seem to be a thread that's related to the bug he mentioned, in either of the lists. Quite a healthy approach to serious bugs, huh? As a matter of a small off-topic, that's a weird article written by a person who's making a weird product. And, while my vision of Couchbase may be way too subjective, the post has obvious flaws: 1. No links. Well, one link to a page with strange benchmarks, two links to Couchbase site and one link to the author's twitter. Wonderful. 2. No actual proofs of the provided statements. "C is great", "C is high-level enough", "C has extremely professional community", and so on. Don't get me wrong, I like C, it's really great for some purposes. But there are a lot of tasks that C is not suited for (web services, admin scripts, applications with complicated business logic, and fo on and so on). High-level? Come on, it's almost a cross-processor assembler, still highly dependent on your processor architecture and OS. Professional community? Is that why so many programs have tons of memory leaks and segfaults? 3. He mentioned some "bug in core Erlang". Why no references to the mailing list, again? No explanation of what exactly was happening. Did they contact OTP team at all, or just were trying to fix it themselves? On Fri, Jan 11, 2013 at 11:32 AM, Anton Lebedevich wrote: > Hello. > > In the article > http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html > he writes about "race condition bug in core Erlang". > > I wonder is that bug known/reported/fixed? Is there more detailed > description of it? > > Regards, > Anton Lebedevich. > _______________________________________________ > 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 hd2010@REDACTED Fri Jan 11 09:43:36 2013 From: hd2010@REDACTED (Henning Diedrich) Date: Fri, 11 Jan 2013 09:43:36 +0100 Subject: [erlang-questions] what is the "race condition bug in core Erlang" mentioned by @damienkatz? In-Reply-To: <50EFBFF7.8020103@gmail.com> References: <50EFBFF7.8020103@gmail.com> Message-ID: I love that how languages can be love affairs etc. A race condition in core Erlang, I am sure Damien will share his find. In the meantime maybe it's worth looking at the political circumstances. Some might note not only that you fall out of love and then you're irrationally deeply disappointed. You'll find all the feeling of understanding was an illusion in the first place. And sometimes you're even right. But that CouchDB surfed the Erlang hype, a while ago Damien was able to close a deal, and for some reason I don't know anyone quite understood announced that he'll reprogram it all in C. Maybe it was an astounding proposition to program a transactional, local (!) database in the age of Big Data in a language that happens to be transactional by nature but is really made for distribution, and it's not too surprising when that premise is now abandoned. CouchDB is great for certain things, I have no doubt about that, how else could it be so successful. But maybe one could ask, with the distribution layer of Couchbase coming from Membase [1] (which means it would still be Erlang?) but the local storage being in C (coming from memcached I believe), was there simply a necessity in play because C would be a better fit with the rest of the local part of Membase? Like after renaming things, the CouchDB principle would be reprogrammed, to replace or amend the memcached parts in Membase, to become Coucbase, so it had to be in C? And dealing only with the local storage parts, for a database, which was probably the task ? I am not sure that's a natural for Erlang. You wouldn't think someone could be talking himself publicly into loving his partner in a forced marriage? Me for instance, I love C. Erlang always makes me feel stupid. Who wants that. Henning [1] old: http://blog.couchbase.com/why-membase-uses-erlang On Jan 11, 2013, at 8:32 AM, Anton Lebedevich wrote: > Hello. > > In the article > http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html > he writes about "race condition bug in core Erlang". > > I wonder is that bug known/reported/fixed? Is there more detailed > description of it? > > Regards, > Anton Lebedevich. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ulf@REDACTED Fri Jan 11 10:12:40 2013 From: ulf@REDACTED (Ulf Wiger) Date: Fri, 11 Jan 2013 10:12:40 +0100 Subject: [erlang-questions] suggestion: shorthand functions Message-ID: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> Since I've been writing a bunch of rebar.config.script code lately, I've suffered the agony of trying to write concise and readable code without having to do tons of copy-paste, weird unwrapping funs etc. What I think would make this sort of thing easier, and also escript programming in general, is if OTP could provide some modules with concise naming and let-it-fail semantics. Just off the top of my head, I scribbled down a few functions that I think would make *my* life easier. I pushed them to github to get some discussion going. http://github.com/uwiger/shorthand The modules are: f.erl - shorthand functions for file.erl fn.erl - ditto for filename.erl e.erl - ditto for erl_eval.erl The least beneficial is perhaps filename:erl, but my fingers and eyes ache from all the filename:join(filename:dirname(F), ?) code. Otherwise, I think the biggest benefit is to stick to let-it-crash programming, which I find is usually the default when I write scripts. The original functions are always available if you want to take a closer look at return values. (For the file:script() counterparts, I also always pass the name of the script as a binding). Comments? BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From tpodowd@REDACTED Fri Jan 11 10:31:09 2013 From: tpodowd@REDACTED (Thomas O'Dowd) Date: Fri, 11 Jan 2013 18:31:09 +0900 Subject: [erlang-questions] suggestion: shorthand functions In-Reply-To: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> References: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> Message-ID: <1357896669.1745.88.camel@bertha> Ulf, I'm probably missing something but what's wrong with importing functions if you are using them so much? Example. -import(filename, [join/2]). Tom. On Fri, 2013-01-11 at 10:12 +0100, Ulf Wiger wrote: > Since I've been writing a bunch of rebar.config.script code lately, > I've suffered the agony of trying to write concise and readable > code without having to do tons of copy-paste, weird unwrapping > funs etc. > > What I think would make this sort of thing easier, and also > escript programming in general, is if OTP could provide some > modules with concise naming and let-it-fail semantics. > > Just off the top of my head, I scribbled down a few functions that > I think would make *my* life easier. I pushed them to github to > get some discussion going. > > http://github.com/uwiger/shorthand > > The modules are: > > f.erl - shorthand functions for file.erl > fn.erl - ditto for filename.erl > e.erl - ditto for erl_eval.erl > > The least beneficial is perhaps filename:erl, but my fingers and > eyes ache from all the filename:join(filename:dirname(F), ?) > code. > > Otherwise, I think the biggest benefit is to stick to let-it-crash > programming, which I find is usually the default when I write > scripts. The original functions are always available if you want > to take a closer look at return values. > > (For the file:script() counterparts, I also always pass the name > of the script as a binding). > > Comments? > > BR, > Ulf W > > Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. > http://feuerlabs.com > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Cloudian KK - http://cloudian.jp/ S3 REST API Compliant Cloud Storage with Cloudian? From thomasl_erlang@REDACTED Fri Jan 11 10:34:20 2013 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Fri, 11 Jan 2013 01:34:20 -0800 (PST) Subject: [erlang-questions] suggestion: shorthand functions In-Reply-To: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> References: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> Message-ID: <1357896860.83828.YahooMailNeo@web120705.mail.ne1.yahoo.com> Another approach to reduce verbosity might be to implement a "DSL" of sorts, a la %% obviously incomplete, but you get the idea expand({d, D}) -> filename:dirname(D); expand(Ds) when list(Ds) -> filename:join([ expand(D) || D <- Ds ]); expand(F) -> F. My main gripe with the "expand/1" approach above would be that the resulting caller might look a bit messy. But some experimentation could get the interface right. (Compiling this into direct calls with a parse transform is left as an exercise.) Best, Thomas ----- Original Message ----- > From: Ulf Wiger > To: erlang-questions Questions > Cc: > Sent: Friday, January 11, 2013 10:12 AM > Subject: [erlang-questions] suggestion: shorthand functions > > Since I've been writing a bunch of rebar.config.script code lately, > I've suffered the agony of trying to write concise and readable > code without having to do tons of copy-paste, weird unwrapping > funs etc. > > What I think would make this sort of thing easier, and also > escript programming in general, is if OTP could provide some > modules with concise naming and let-it-fail semantics. > > Just off the top of my head, I scribbled down a few functions that > I think would make *my* life easier. I pushed them to github to > get some discussion going. > > http://github.com/uwiger/shorthand > > The modules are: > > f.erl - shorthand functions for file.erl > fn.erl - ditto for filename.erl > e.erl - ditto for erl_eval.erl > > The least beneficial is perhaps filename:erl, but my fingers and > eyes ache from all the filename:join(filename:dirname(F), ?) > code. > > Otherwise, I think the biggest benefit is to stick to let-it-crash > programming, which I find is usually the default when I write > scripts. The original functions are always available if you want > to take a closer look at return values. > > (For the file:script() counterparts, I also always pass the name > of the script as a binding). > > Comments? > > BR, > Ulf W > > Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. > http://feuerlabs.com > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From jbothma@REDACTED Fri Jan 11 11:23:37 2013 From: jbothma@REDACTED (JD Bothma) Date: Fri, 11 Jan 2013 11:23:37 +0100 Subject: [erlang-questions] Ubuntu update breaking longnames Message-ID: Has anyone else experienced this and perhaps found a fix? I updated ubuntu this morning and since then I can't start net_kernel with longnames. erl Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:8:8] [async-threads:0] [kernel-poll:false] Eshell V5.9.1 (abort with ^G) Same with R14B03 cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=12.10 DISTRIB_CODENAME=quantal DISTRIB_DESCRIPTION="Ubuntu 12.10" uname -a Linux marlin 3.5.0-21-generic #32-Ubuntu SMP Tue Dec 11 18:51:59 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux erl -name bob {error_logger,{{2013,1,11},{11,20,6}},"Can't set long node name!\nPlease check your configuration\n",[]} {error_logger,{{2013,1,11},{11,20,6}},crash_report,[[{initial_call,{net_kernel,init,['Argument__1']}},{pid,<0.20.0>},{registered_name,[]},{error_info,{exit,{error,badarg},[{gen_server,init_it,6,[{file,"gen_server.erl"},{line,320}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]}},{ancestors,[net_sup,kernel_sup,<0.9.0>]},{messages,[]},{links,[<0.17.0>]},{dictionary,[{longnames,true}]},{trap_exit,true},{status,running},{heap_size,1597},{stack_size,24},{reductions,882}],[]]} {error_logger,{{2013,1,11},{11,20,6}},supervisor_report,[{supervisor,{local,net_sup}},{errorContext,start_error},{reason,{'EXIT',nodistribution}},{offender,[{pid,undefined},{name,net_kernel},{mfargs,{net_kernel,start_link,[[bob,longnames]]}},{restart_type,permanent},{shutdown,2000},{child_type,worker}]}]} {error_logger,{{2013,1,11},{11,20,6}},supervisor_report,[{supervisor,{local,kernel_sup}},{errorContext,start_error},{reason,shutdown},{offender,[{pid,undefined},{name,net_sup},{mfargs,{erl_distribution,start_link,[]}},{restart_type,permanent},{shutdown,infinity},{child_type,supervisor}]}]} {error_logger,{{2013,1,11},{11,20,6}},std_info,[{application,kernel},{exited,{shutdown,{kernel,start,[normal,[]]}}},{type,permanent}]} {"Kernel pid terminated",application_controller,"{application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}}"} Crash dump was written to: erl_crash.dump Kernel pid terminated (application_controller) ({application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}}) -------------- next part -------------- An HTML attachment was scrubbed... URL: From desired.mta@REDACTED Fri Jan 11 11:37:53 2013 From: desired.mta@REDACTED (=?UTF-8?Q?Motiejus_Jak=C5=A1tys?=) Date: Fri, 11 Jan 2013 10:37:53 +0000 Subject: [erlang-questions] Ubuntu update breaking longnames In-Reply-To: References: Message-ID: On Fri, Jan 11, 2013 at 10:23 AM, JD Bothma wrote: > > erl -name bob Hi, I am surprised how this worked before. For -name you need an FQDN. Technically, it's a name with at least one dot. Maybe you mean erl -sname bob, which is expected to work? -- Motiejus Jak?tys From ulf@REDACTED Fri Jan 11 11:45:23 2013 From: ulf@REDACTED (Ulf Wiger) Date: Fri, 11 Jan 2013 11:45:23 +0100 Subject: [erlang-questions] suggestion: shorthand functions In-Reply-To: <1357896669.1745.88.camel@bertha> References: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> <1357896669.1745.88.camel@bertha> Message-ID: <56D674F4-66CA-451E-92AC-14B131975A9C@feuerlabs.com> On 11 Jan 2013, at 10:31, Thomas O'Dowd wrote: > Ulf, > > I'm probably missing something but what's wrong with importing functions > if you are using them so much? Example. > > -import(filename, [join/2]). This can be done in escripts, but not in file:script() files, and it only addresses the number of keystrokes. I realize that historically, few people have written such scripts, if they even knew the function existed. But now that rebar supports the notion of rebar.config.script for dynamic configuration, I have seen them popping up here and there. But, as I said, the different semantics - return a value or raise an exception - allow you to eliminate a great deal of code that checks and unwraps values only to pass them on. That, or you live with the risk of getting ugly badmatch exceptions. In order to be a real improvement, these wrapper functions would need to present more informative exceptions too. BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From bengt.kleberg@REDACTED Fri Jan 11 11:46:49 2013 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Fri, 11 Jan 2013 11:46:49 +0100 Subject: [erlang-questions] Ubuntu update breaking longnames In-Reply-To: References: Message-ID: <1357901209.4818.26.camel@sekic1152.rnd.ki.sw.ericsson.se> Greetings, On all my/Ericssons computers "erl -name kalle" will start a FQDN node. The domainname is added to "kalle". bengt On Fri, 2013-01-11 at 10:37 +0000, Motiejus Jak?tys wrote: > On Fri, Jan 11, 2013 at 10:23 AM, JD Bothma wrote: > > > > erl -name bob > > Hi, > I am surprised how this worked before. For -name you need an FQDN. > Technically, it's a name with at least one dot. > > Maybe you mean erl -sname bob, which is expected to work? > From ulf@REDACTED Fri Jan 11 11:48:16 2013 From: ulf@REDACTED (Ulf Wiger) Date: Fri, 11 Jan 2013 11:48:16 +0100 Subject: [erlang-questions] suggestion: shorthand functions In-Reply-To: <1357896860.83828.YahooMailNeo@web120705.mail.ne1.yahoo.com> References: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> <1357896860.83828.YahooMailNeo@web120705.mail.ne1.yahoo.com> Message-ID: <09365F44-5E4C-4F54-82C9-4F43CFC187A4@feuerlabs.com> Yes, but a bit tricky with escripts and downright impractical with file:script() files. A problem with escripts is that, while you can create libraries with useful helper functions, you then need to pack it all into an archive, as e.g. rebar does. Of course, when done this way, ordinary Erlang programming works reasonably well, but it is too heavy for simple scripts. For the simple scripts, you tend to rely on the things that exist in OTP, for better or for worse. BR, Ulf W On 11 Jan 2013, at 10:34, Thomas Lindgren wrote: > Another approach to reduce verbosity might be to implement a "DSL" of sorts, a la > > %% obviously incomplete, but you get the idea > expand({d, D}) -> filename:dirname(D); > expand(Ds) when list(Ds) -> filename:join([ expand(D) || D <- Ds ]); > expand(F) -> F. > > My main gripe with the "expand/1" approach above would be that the resulting caller might look a bit messy. But some experimentation could get the interface right. > > (Compiling this into direct calls with a parse transform is left as an exercise.) > > Best, > Thomas > > > ----- Original Message ----- >> From: Ulf Wiger >> To: erlang-questions Questions >> Cc: >> Sent: Friday, January 11, 2013 10:12 AM >> Subject: [erlang-questions] suggestion: shorthand functions >> >> Since I've been writing a bunch of rebar.config.script code lately, >> I've suffered the agony of trying to write concise and readable >> code without having to do tons of copy-paste, weird unwrapping >> funs etc. >> >> What I think would make this sort of thing easier, and also >> escript programming in general, is if OTP could provide some >> modules with concise naming and let-it-fail semantics. >> >> Just off the top of my head, I scribbled down a few functions that >> I think would make *my* life easier. I pushed them to github to >> get some discussion going. >> >> http://github.com/uwiger/shorthand >> >> The modules are: >> >> f.erl - shorthand functions for file.erl >> fn.erl - ditto for filename.erl >> e.erl - ditto for erl_eval.erl >> >> The least beneficial is perhaps filename:erl, but my fingers and >> eyes ache from all the filename:join(filename:dirname(F), ?) >> code. >> >> Otherwise, I think the biggest benefit is to stick to let-it-crash >> programming, which I find is usually the default when I write >> scripts. The original functions are always available if you want >> to take a closer look at return values. >> >> (For the file:script() counterparts, I also always pass the name >> of the script as a binding). >> >> Comments? >> >> BR, >> Ulf W >> >> Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. >> http://feuerlabs.com >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > _______________________________________________ > 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 jesper.louis.andersen@REDACTED Fri Jan 11 11:58:14 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 11 Jan 2013 11:58:14 +0100 Subject: [erlang-questions] suggestion: shorthand functions In-Reply-To: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> References: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> Message-ID: On Jan 11, 2013, at 10:12 AM, Ulf Wiger wrote: > Comments? In the Standard ML module system, in particular with the .MLB file extension you get module-level import renaming: local $(OTP_LIB)/R15B % Grab *that* version of the Erlang OTP library in module file = f module filename = fn module lists = l end % From here on out in our build specification, the modules f, fn and l are specified. your_module.erl Note that this also solves module clashes: local file1.erl in module file = f1 end local file2.erl in module file = f2 end ? Do note, however, that Standard ML did *not* make the--unfortunately ubiquitous--mistake of conflating a filename with a module name. So it may be hard to pull off in Erlang-land :/ Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen From jbothma@REDACTED Fri Jan 11 12:01:04 2013 From: jbothma@REDACTED (JD Bothma) Date: Fri, 11 Jan 2013 12:01:04 +0100 Subject: [erlang-questions] Ubuntu update breaking longnames In-Reply-To: References: Message-ID: hmmm... my hostname was set "in a roughly proper way" to marlin (marlin /etc/hosts points to my public IP, /etc/hostname is marlin, sudo hostname marlin, etc.) setting all that to something more FQDN-y seems to have made it work. This still feels a bit like magic, yes. I just found http://erlang.org/doc/apps/erts/inet_cfg.html which might explain more how it works for future ref. On 11 January 2013 11:37, Motiejus Jak?tys wrote: > On Fri, Jan 11, 2013 at 10:23 AM, JD Bothma wrote: > > > > erl -name bob > > Hi, > I am surprised how this worked before. For -name you need an FQDN. > Technically, it's a name with at least one dot. > > Maybe you mean erl -sname bob, which is expected to work? > > -- > Motiejus Jak?tys > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Fri Jan 11 12:42:53 2013 From: ulf@REDACTED (Ulf Wiger) Date: Fri, 11 Jan 2013 12:42:53 +0100 Subject: [erlang-questions] suggestion: shorthand functions In-Reply-To: References: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> Message-ID: Yes, this seems a bit harder to emulate in Erlang than my modest addition. :) Note also that my primary aim is erlang for scripting, when it's not always practical to assume the presence of 3rd party libraries that can be imported. Also, again, I think that many of the functions most used in scripts have the wrong semantics, using the {ok,Value} | {error, Reason} approach. BR, Ulf W On 11 Jan 2013, at 11:58, Jesper Louis Andersen wrote: > > On Jan 11, 2013, at 10:12 AM, Ulf Wiger wrote: > >> Comments? > > In the Standard ML module system, in particular with the .MLB file extension you get module-level import renaming: > > local > $(OTP_LIB)/R15B % Grab *that* version of the Erlang OTP library > in > module file = f > module filename = fn > module lists = l > end > % From here on out in our build specification, the modules f, fn and l are specified. > your_module.erl > > Note that this also solves module clashes: > > local > file1.erl > in > module file = f1 > end > local > file2.erl > in > module file = f2 > end > ? > > Do note, however, that Standard ML did *not* make the--unfortunately ubiquitous--mistake of conflating a filename with a module name. So it may be hard to pull off in Erlang-land :/ > > Jesper Louis Andersen > Erlang Solutions Ltd., Copenhagen > > > Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From raimo+erlang-questions@REDACTED Fri Jan 11 15:18:54 2013 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Fri, 11 Jan 2013 15:18:54 +0100 Subject: [erlang-questions] suggestion: shorthand functions In-Reply-To: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> References: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> Message-ID: <20130111141854.GA31136@erix.ericsson.se> On Fri, Jan 11, 2013 at 10:12:40AM +0100, Ulf Wiger wrote: > Since I've been writing a bunch of rebar.config.script code lately, > I've suffered the agony of trying to write concise and readable > code without having to do tons of copy-paste, weird unwrapping > funs etc. > > What I think would make this sort of thing easier, and also > escript programming in general, is if OTP could provide some > modules with concise naming and let-it-fail semantics. > > Just off the top of my head, I scribbled down a few functions that > I think would make *my* life easier. I pushed them to github to > get some discussion going. > > http://github.com/uwiger/shorthand > > The modules are: > > f.erl - shorthand functions for file.erl > fn.erl - ditto for filename.erl > e.erl - ditto for erl_eval.erl > > The least beneficial is perhaps filename:erl, but my fingers and > eyes ache from all the filename:join(filename:dirname(F), ?) > code. > > Otherwise, I think the biggest benefit is to stick to let-it-crash > programming, which I find is usually the default when I write > scripts. The original functions are always available if you want > to take a closer look at return values. > > (For the file:script() counterparts, I also always pass the name > of the script as a binding). > > Comments? I think it is a nice idea that would improve scripting. But how to agree on module names and content is harder. There is a limited number of 1 and 2 character module names, and once in OTP they are written in stone. For f.erl I miss e.g is_dir from filelib, which would introduce the notion of merging old module functionality. Using the name 'fl' for filelib functions would just be hard to remember. Aliasing filename:basename to fn:base is a bit unintuitive since the original Unix command is called 'basename' and for e.g file:list_dir you have aliased it to f:ls (as for many other) to make them more Unix:ish. I think it would be better to keep to unix command names where possible. [Wild idea: f:'-d' for filelib:is_dir, or t:'-d', or f:test(d, Path).] An alternative approach might be to have a helper module named 'es' containing all scripting aliases... > > BR, > Ulf W > > Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. > http://feuerlabs.com -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From straightflush@REDACTED Fri Jan 11 15:49:51 2013 From: straightflush@REDACTED (AD) Date: Fri, 11 Jan 2013 09:49:51 -0500 Subject: [erlang-questions] did cowboy_req:transport/1 go missing ? Message-ID: i have the latest master checkout of cowboy and it looks like cowboy_req:transport/1 went missing. The in code docs reference it exists but its not defined. Any thoughts ? %% Exceptions include chunk/2 which always returns 'ok', %% to_list/1 which returns a list of key/values, %% and transport/1 which returns {ok, Transport, Socket}. -AD -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Fri Jan 11 15:54:08 2013 From: ulf@REDACTED (Ulf Wiger) Date: Fri, 11 Jan 2013 15:54:08 +0100 Subject: [erlang-questions] suggestion: shorthand functions In-Reply-To: <20130111141854.GA31136@erix.ericsson.se> References: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> <20130111141854.GA31136@erix.ericsson.se> Message-ID: On 11 Jan 2013, at 15:18, Raimo Niskanen wrote: > I think it is a nice idea that would improve scripting. > > But how to agree on module names and content is harder. There is a limited > number of 1 and 2 character module names, and once in OTP they are written > in stone. This is true. I don't think keeping the module names within 2 characters is a top priority. Actually, 'file' is just fine, but the functions in file consistently return {ok,V} | {error, R}, so mixing it up in there has its disadvantages. OTOH, once you string together a few calls to filename:basename/1 and filename:dirname/1 inside a call to filename:join/2, 80 character line width doesn't seem like much. :) > For f.erl I miss e.g is_dir from filelib, which would introduce the notion > of merging old module functionality. Using the name 'fl' for filelib > functions would just be hard to remember. I also thought about adding is_dir/1, is_file/1, is_symlink/1, but didn't partly because I had other things to do, and partly because I started thinking about how the semantics of the original functions is the right one anyway? When I added the module fn, it was mainly because e.g. adding join/2 to f.erl might seem unintuitive, as we're not joining files, but filenames. OTOH, the functions in filelib could be mapped to f.erl, I think. > Aliasing filename:basename to fn:base is a bit unintuitive since the > original Unix command is called 'basename' and for e.g file:list_dir > you have aliased it to f:ls (as for many other) to make them more Unix:ish. > I think it would be better to keep to unix command names where possible. > [Wild idea: f:'-d' for filelib:is_dir, or t:'-d', or f:test(d, Path).] Agree. > An alternative approach might be to have a helper module named 'es' > containing all scripting aliases? That's an idea, but on the other hand, the functions may well catch on outside of scripting too, among those who prefer the let-it-fail semantics. BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From essen@REDACTED Fri Jan 11 15:55:22 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Fri, 11 Jan 2013 15:55:22 +0100 Subject: [erlang-questions] did cowboy_req:transport/1 go missing ? In-Reply-To: References: Message-ID: <50F027DA.3050800@ninenines.eu> On 01/11/2013 03:49 PM, AD wrote: > i have the latest master checkout of cowboy and it looks like > cowboy_req:transport/1 went missing. The in code docs reference it > exists but its not defined. Any thoughts ? > > %% Exceptions include chunk/2 which always returns 'ok', > > %% to_list/1 which returns a list of key/values, > > %% and transport/1 which returns {ok, Transport, Socket}. Forgot to remove that from the docs! Use: [Socket, Transport] = cowboy_req:get([socket, transport], Req) if you need it. If you are using response streaming, you don't need it anymore as the Socket and Transport are now passed to the fun. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From g@REDACTED Fri Jan 11 15:55:49 2013 From: g@REDACTED (Garrett Smith) Date: Fri, 11 Jan 2013 08:55:49 -0600 Subject: [erlang-questions] suggestion: shorthand functions In-Reply-To: <20130111141854.GA31136@erix.ericsson.se> References: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> <20130111141854.GA31136@erix.ericsson.se> Message-ID: On Fri, Jan 11, 2013 at 8:18 AM, Raimo Niskanen wrote: > On Fri, Jan 11, 2013 at 10:12:40AM +0100, Ulf Wiger wrote: >> Since I've been writing a bunch of rebar.config.script code lately, >> I've suffered the agony of trying to write concise and readable >> code without having to do tons of copy-paste, weird unwrapping >> funs etc. >> >> What I think would make this sort of thing easier, and also >> escript programming in general, is if OTP could provide some >> modules with concise naming and let-it-fail semantics. >> >> Just off the top of my head, I scribbled down a few functions that >> I think would make *my* life easier. I pushed them to github to >> get some discussion going. >> >> http://github.com/uwiger/shorthand >> >> The modules are: >> >> f.erl - shorthand functions for file.erl >> fn.erl - ditto for filename.erl >> e.erl - ditto for erl_eval.erl >> >> The least beneficial is perhaps filename:erl, but my fingers and >> eyes ache from all the filename:join(filename:dirname(F), ?) >> code. >> >> Otherwise, I think the biggest benefit is to stick to let-it-crash >> programming, which I find is usually the default when I write >> scripts. The original functions are always available if you want >> to take a closer look at return values. >> >> (For the file:script() counterparts, I also always pass the name >> of the script as a binding). >> >> Comments? > > I think it is a nice idea that would improve scripting. > > But how to agree on module names and content is harder. There is a limited > number of 1 and 2 character module names, and once in OTP they are written > in stone. Aye. I don't know how critical this use case is (scripting simplification/improvements) to justify new modules in OTP space. And I'm not sure there *is* a case that would be sufficiently ubiquitous. I've resigned myself to writing little project specific functions/libraries like this to deal with project specific problems. E.g. this stuff drives me nuts: {ok, X} = foo:x(), {ok, Y} = foo:y(), combine(X, Y) ... So I'll write foo_x/0 and foo_y/0 with crash-on-error semantics to get this: combine(foo_x(), foo_y()) But who knew that I needed those particular variants? And what about changes? It's my project, so I don't mind little wrappers, especially since functions clarify intent. E.g. when I see this: ProjectFile = filename:join(ProjectDir, ProjectName) I'll almost create a function like this: project_filename(Dir, Name) -> filename:join(Dir, Name). > For f.erl I miss e.g is_dir from filelib, which would introduce the notion > of merging old module functionality. Using the name 'fl' for filelib > functions would just be hard to remember. > > Aliasing filename:basename to fn:base is a bit unintuitive since the > original Unix command is called 'basename' and for e.g file:list_dir > you have aliased it to f:ls (as for many other) to make them more Unix:ish. > I think it would be better to keep to unix command names where possible. > [Wild idea: f:'-d' for filelib:is_dir, or t:'-d', or f:test(d, Path).] It seems one could make these arguments ad nauseam. To me it's just easier (and preferable frankly) to roll my own as the need arises. > An alternative approach might be to have a helper module named 'es' > containing all scripting aliases... I love escripts but find myself intuitively avoiding them for a couple reasons: - In most cases, bash is more portable and solves system level problems more directly - I don't have the escript foo required to wrench my program it into a single script file Setting bash aside (not Ulf's use case) the main barrier for me is in the perceived complexity of getting a release-of-sorts into an escript. If I could write up one of these wrapper libraries, or pull it down from somewhere easily, I might use escript everywhere. It's not hard to write the wrappers (you write them as you need them, it takes literally less than a minute for each function) and they're tailored to your requirements. It may be trivial to package up the required bytes into an escript today. If it is, I've love to know! And I don't know how this fits into rebar specific scripting :) Garrett From mahesh@REDACTED Fri Jan 11 16:11:26 2013 From: mahesh@REDACTED (Mahesh Paolini-Subramanya) Date: Fri, 11 Jan 2013 10:11:26 -0500 Subject: [erlang-questions] suggestion: shorthand functions In-Reply-To: References: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> <20130111141854.GA31136@erix.ericsson.se> Message-ID: > I love escripts but find myself intuitively avoiding them for a couple reasons: > > - In most cases, bash is more portable and solves system level > problems more directly > > - I don't have the escript foo required to wrench my program it into a > single script file Amen. perl (bash, python, whatever) is optimally suited for orchestrating between 'application space' and 'business space', as well as orchestration across loosely coupled systems and activities. Yes, you could force most of this into erlang-world, but to what point? IMHO, we do live in a polyglot world, and we may as well take advantage of it? Cheers p.s. Mind you, there is an entirely different argument to be made about systems where you only have access to erlang (or Ada. or whatever :-) ) Mahesh Paolini-Subramanya That Tall Bald Indian Guy... Google+ | Blog | Twitter | LinkedIn On Jan 11, 2013, at 9:55 AM, Garrett Smith wrote: > On Fri, Jan 11, 2013 at 8:18 AM, Raimo Niskanen > wrote: >> On Fri, Jan 11, 2013 at 10:12:40AM +0100, Ulf Wiger wrote: >>> Since I've been writing a bunch of rebar.config.script code lately, >>> I've suffered the agony of trying to write concise and readable >>> code without having to do tons of copy-paste, weird unwrapping >>> funs etc. >>> >>> What I think would make this sort of thing easier, and also >>> escript programming in general, is if OTP could provide some >>> modules with concise naming and let-it-fail semantics. >>> >>> Just off the top of my head, I scribbled down a few functions that >>> I think would make *my* life easier. I pushed them to github to >>> get some discussion going. >>> >>> http://github.com/uwiger/shorthand >>> >>> The modules are: >>> >>> f.erl - shorthand functions for file.erl >>> fn.erl - ditto for filename.erl >>> e.erl - ditto for erl_eval.erl >>> >>> The least beneficial is perhaps filename:erl, but my fingers and >>> eyes ache from all the filename:join(filename:dirname(F), ?) >>> code. >>> >>> Otherwise, I think the biggest benefit is to stick to let-it-crash >>> programming, which I find is usually the default when I write >>> scripts. The original functions are always available if you want >>> to take a closer look at return values. >>> >>> (For the file:script() counterparts, I also always pass the name >>> of the script as a binding). >>> >>> Comments? >> >> I think it is a nice idea that would improve scripting. >> >> But how to agree on module names and content is harder. There is a limited >> number of 1 and 2 character module names, and once in OTP they are written >> in stone. > > Aye. I don't know how critical this use case is (scripting > simplification/improvements) to justify new modules in OTP space. And > I'm not sure there *is* a case that would be sufficiently ubiquitous. > > I've resigned myself to writing little project specific > functions/libraries like this to deal with project specific problems. > E.g. this stuff drives me nuts: > > {ok, X} = foo:x(), > {ok, Y} = foo:y(), > combine(X, Y) > ... > > So I'll write foo_x/0 and foo_y/0 with crash-on-error semantics to get this: > > combine(foo_x(), foo_y()) > > But who knew that I needed those particular variants? And what about > changes? It's my project, so I don't mind little wrappers, especially > since functions clarify intent. > > E.g. when I see this: > > ProjectFile = filename:join(ProjectDir, ProjectName) > > I'll almost create a function like this: > > project_filename(Dir, Name) -> filename:join(Dir, Name). > >> For f.erl I miss e.g is_dir from filelib, which would introduce the notion >> of merging old module functionality. Using the name 'fl' for filelib >> functions would just be hard to remember. >> >> Aliasing filename:basename to fn:base is a bit unintuitive since the >> original Unix command is called 'basename' and for e.g file:list_dir >> you have aliased it to f:ls (as for many other) to make them more Unix:ish. >> I think it would be better to keep to unix command names where possible. >> [Wild idea: f:'-d' for filelib:is_dir, or t:'-d', or f:test(d, Path).] > > It seems one could make these arguments ad nauseam. To me it's just > easier (and preferable frankly) to roll my own as the need arises. > >> An alternative approach might be to have a helper module named 'es' >> containing all scripting aliases... > > I love escripts but find myself intuitively avoiding them for a couple reasons: > > - In most cases, bash is more portable and solves system level > problems more directly > > - I don't have the escript foo required to wrench my program it into a > single script file > > Setting bash aside (not Ulf's use case) the main barrier for me is in > the perceived complexity of getting a release-of-sorts into an > escript. If I could write up one of these wrapper libraries, or pull > it down from somewhere easily, I might use escript everywhere. It's > not hard to write the wrappers (you write them as you need them, it > takes literally less than a minute for each function) and they're > tailored to your requirements. > > It may be trivial to package up the required bytes into an escript > today. If it is, I've love to know! > > And I don't know how this fits into rebar specific scripting :) > > Garrett > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From straightflush@REDACTED Fri Jan 11 16:27:42 2013 From: straightflush@REDACTED (AD) Date: Fri, 11 Jan 2013 10:27:42 -0500 Subject: [erlang-questions] did cowboy_req:transport/1 go missing ? In-Reply-To: <50F027DA.3050800@ninenines.eu> References: <50F027DA.3050800@ninenines.eu> Message-ID: Thanks, trying to get sockjs working with the latest version of cowboy. Will give this a shot. On Fri, Jan 11, 2013 at 9:55 AM, Lo?c Hoguin wrote: > On 01/11/2013 03:49 PM, AD wrote: > >> i have the latest master checkout of cowboy and it looks like >> cowboy_req:transport/1 went missing. The in code docs reference it >> exists but its not defined. Any thoughts ? >> >> %% Exceptions include chunk/2 which always returns 'ok', >> >> %% to_list/1 which returns a list of key/values, >> >> %% and transport/1 which returns {ok, Transport, >> Socket}. >> > > Forgot to remove that from the docs! > > Use: > > [Socket, Transport] = cowboy_req:get([socket, transport], Req) > > if you need it. > > If you are using response streaming, you don't need it anymore as the > Socket and Transport are now passed to the fun. > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Fri Jan 11 16:09:36 2013 From: ulf@REDACTED (Ulf Wiger) Date: Fri, 11 Jan 2013 16:09:36 +0100 Subject: [erlang-questions] suggestion: shorthand functions In-Reply-To: References: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> <20130111141854.GA31136@erix.ericsson.se> Message-ID: <324F692B-8E40-4139-B9B4-B7B0BE3A8361@feuerlabs.com> On 11 Jan 2013, at 15:55, Garrett Smith wrote: > Setting bash aside (not Ulf's use case) the main barrier for me is in > the perceived complexity of getting a release-of-sorts into an > escript. If I could write up one of these wrapper libraries, or pull > it down from somewhere easily, I might use escript everywhere. It's > not hard to write the wrappers (you write them as you need them, it > takes literally less than a minute for each function) and they're > tailored to your requirements. Yes, I agree that this is a barrier. This is also why I started the discussion of getting a scripting-friendly library into OTP. The big question is of course how big the gain is, and if it's worth the redundancy. I thought I'd try to stimulate some discussion before I invest too much effort into the idea. While I agree that the wrapper functions are easy to write, they're still a nuisance, and you have to live with > It may be trivial to package up the required bytes into an escript > today. If it is, I've love to know! Well, what I do in 'setup' is simply to let rebar handle it: {escript_name, setup_gen}. in your rebar.config (but with a name of your choosing). Then call `rebar escriptize` In 'setup', I've added {post_hooks, [{compile, "rebar skip_deps=true escriptize"}]}. since I want the escript to be created even if setup is included as a dependency and the top app just calls `rebar compile` > And I don't know how this fits into rebar specific scripting :) I've liked the file:script() function ever since I wrote it many years ago, but failed to recruit others to my religion until I was able to sneak it into rebar. ;-) I will say that the biggest problem, if you start chaining scripts together (which I do sometimes in rebar, and also when using 'setup'), is that when you get e.g. a badmatch exception in a sub-script, it gets to you via erl_eval, which is not nearly as nice as an exception from compiled code. Often, you end up scratching your head trying to figure out which sub-script it was that actually failed. Fixable, I'm sure, but I guess it hasn't been a priority. BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From alkondratenko@REDACTED Fri Jan 11 19:12:46 2013 From: alkondratenko@REDACTED (Aliaksey Kandratsenka) Date: Fri, 11 Jan 2013 10:12:46 -0800 Subject: [erlang-questions] what is the "race condition bug in core Erlang" mentioned by @damienkatz? (was: Re: erlang-questions Digest, Vol 95, Issue 9) Message-ID: Sorry for replying for digest. I normally just passively listen here. I'm one of the guys directly involved in final stages of figuring out that bug. Here's the story. As we approached finalization of Couchbase Server 2.0 we started seeing http://www.couchbase.com/issues/browse/MB-6638. Given that we have a bunch of custom nifs, we weren't sure until very last minute whether it's erlang vm bug or ours. And, initially, even reliably reproducing this was hard. And when we learned how to reproduce it still required few hours of running our full stack. That's why we never asked help in erlang MLs. Backtraces suggested something in efile driver related to async io threads, so our folks tried to disable them and observed that crashes were gone. They also tried to reproduce this problem in smaller scale, but they only found some different bug. Which Filipe fixed recently: https://github.com/erlang/otp/commit/5ddf4118617d7e5bac5b889025aa0f3903796a49 We had to ship 2.0 without getting on top of this. So 2.0 _does not have_ async io threads enabled. This means some heavy disk io (which we do) can cause unpredictable delays for any erlang process and thus some end-user badness. BTW, Why something as crucial as async io threads is off by default ? When I was trying to argue for not disabling async io threads prior to 2.0 and fighting this issue "to death", I've heard argument: "it's experimental feature because it's off by default". Is it ? In the end we found that when process linked to raw file dies, it'll stop linked file driver. And as part of that underlying os file or gzip stream (depending on compressed option) will be closed. Without taking into account any possible in-flight async call for that file. It's somewhat harmless for plain files to try to read/write closed fd, but it'll clearly cause crash if some code tries to read from closed (and freed) gzip stream. And of course tiny possibility of reading/writing to/from another file that happened to reuse same fd is not fun either. We found that file_sorter is actually passing compressed option "just case" all the time and we confirmed that indeed crashes happen because of those "compressed by not really" raw file ports. Couchbase Server 2.0.1 will ship with workaround that replaces file_sorter from stdlib with it's tiny fork that cuts compressed option out. I've seen Filipe produced erlang vm patch for that issue too, but what I've seen only covers closing compressed files. IMHO right fix would be to cover both options. I'm also seeing some folks in this thread being unhappy and somewhat angry. Apparently they seem to interpret Damien's opinion as bashing of Erlang. Which is IMHO not the case. I think his arguments apply for core database software. And In my humble opinion candid expressions like that should be encouraged and studied with cold minds. It is true that we have found that getting performance out of Erlang and in general understanding what happens inside VM is next to impossible. And, personally, even without knowing all I know about challenges of getting performance out of Erlang VM I'd still say that doing core database in erlang (or any other not C-like-low-level language) is just crazy. IMHO. BTW, perhaps, not everybody here is aware that Damien has "erlanger of the year" 2009 award. I guess for CouchDB. Indeed, it's very much like love affair that's gone :) But hey, un-loved being is not necessarily bad, right ? As for plans of using Erlang in Couchbase (which is former Membase). We indeed plan to incrementally and gradually rewrite performance sensitive pieces in C or C++. But there are no concrete plans of getting rid of Erlang entirely, yet. It works ok for our cluster management layer. And IMHO compared to some our competitors which either do all in low-level language (mongo, rethinkdb) or high-level (riak) our approach of combining low-level language for "moving bits around" and high-level language for cluster management and orchestration seems to work best. So even if we switch off Erlang completely, we'll very likely still use something much higher level than C for cluster management and other not performance sensitive but sometimes tricky pieces. On Fri, Jan 11, 2013 at 3:00 AM, wrote: > Date: Fri, 11 Jan 2013 09:43:36 +0100 > From: Henning Diedrich > To: Anton Lebedevich > Cc: "erlang-questions@REDACTED" > Subject: Re: [erlang-questions] what is the "race condition bug in > core Erlang" mentioned by @damienkatz? > Message-ID: > Content-Type: text/plain; charset=windows-1252 > > I love that how languages can be love affairs etc. > > A race condition in core Erlang, I am sure Damien will share his find. > > In the meantime maybe it's worth looking at the political circumstances. > > Some might note not only that you fall out of love and then you're > irrationally deeply disappointed. You'll find all the feeling of > understanding was an illusion in the first place. And sometimes you're even > right. But that CouchDB surfed the Erlang hype, a while ago Damien was able > to close a deal, and for some reason I don't know anyone quite understood > announced that he'll reprogram it all in C. > > Maybe it was an astounding proposition to program a transactional, local > (!) database in the age of Big Data in a language that happens to be > transactional by nature but is really made for distribution, and it's not > too surprising when that premise is now abandoned. CouchDB is great for > certain things, I have no doubt about that, how else could it be so > successful. > > But maybe one could ask, with the distribution layer of Couchbase coming > from Membase [1] (which means it would still be Erlang?) but the local > storage being in C (coming from memcached I believe), was there simply a > necessity in play because C would be a better fit with the rest of the > local part of Membase? Like after renaming things, the CouchDB principle > would be reprogrammed, to replace or amend the memcached parts in Membase, > to become Coucbase, so it had to be in C? And dealing only with the local > storage parts, for a database, which was probably the task ? I am not sure > that's a natural for Erlang. > > You wouldn't think someone could be talking himself publicly into loving > his partner in a forced marriage? > > Me for instance, I love C. Erlang always makes me feel stupid. Who wants > that. > > Henning > > > [1] old: http://blog.couchbase.com/why-membase-uses-erlang > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raould@REDACTED Fri Jan 11 19:34:50 2013 From: raould@REDACTED (Raoul Duke) Date: Fri, 11 Jan 2013 10:34:50 -0800 Subject: [erlang-questions] what is the "race condition bug in core Erlang" mentioned by @damienkatz? In-Reply-To: References: <50EFBFF7.8020103@gmail.com> Message-ID: boy, i hope they submitted a patch. From fdmanana@REDACTED Fri Jan 11 19:42:04 2013 From: fdmanana@REDACTED (Filipe David Manana) Date: Fri, 11 Jan 2013 18:42:04 +0000 Subject: [erlang-questions] what is the "race condition bug in core Erlang" mentioned by @damienkatz? In-Reply-To: References: <50EFBFF7.8020103@gmail.com> Message-ID: On Fri, Jan 11, 2013 at 6:34 PM, Raoul Duke wrote: > boy, i hope they submitted a patch. As Aliaksey said, they were. The commits are: https://github.com/erlang/otp/commit/98c745ac9b3f7a74f15b99c9292204c115dcf322 (vm crash, master-pu branch) https://github.com/erlang/otp/commit/bcbd925da0544249bd31ffab04bd65bdbdc3d10f (just a file descriptor leak, master branch) > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." From mjtruog@REDACTED Fri Jan 11 19:45:40 2013 From: mjtruog@REDACTED (Michael Truog) Date: Fri, 11 Jan 2013 10:45:40 -0800 Subject: [erlang-questions] what is the "race condition bug in core Erlang" mentioned by @damienkatz? (was: Re: erlang-questions Digest, Vol 95, Issue 9) In-Reply-To: References: Message-ID: <50F05DD4.4060608@gmail.com> Thank you for providing an explanation of the problems and the information about the use of Erlang with databases. Often these points for (or against) the usage of Erlang, gets lost within passionate arguments and sales pitches, but this provides some level-headed information. On 01/11/2013 10:12 AM, Aliaksey Kandratsenka wrote: > Sorry for replying for digest. I normally just passively listen here. > > I'm one of the guys directly involved in final stages of figuring out > that bug. > > Here's the story. > > As we approached finalization of Couchbase Server 2.0 we started > seeing http://www.couchbase.com/issues/browse/MB-6638. Given that we > have a bunch of custom nifs, we weren't sure until very last minute > whether it's erlang vm bug or ours. And, initially, even reliably > reproducing this was hard. And when we learned how to reproduce it > still required few hours of running our full stack. That's why we > never asked help in erlang MLs. > > Backtraces suggested something in efile driver related to async io > threads, so our folks tried to disable them and observed that crashes > were gone. They also tried to reproduce this problem in smaller scale, > but they only found some different bug. Which Filipe fixed recently: > https://github.com/erlang/otp/commit/5ddf4118617d7e5bac5b889025aa0f3903796a49 > > We had to ship 2.0 without getting on top of this. So 2.0 _does not > have_ async io threads enabled. This means some heavy disk io (which > we do) can cause unpredictable delays for any erlang process and thus > some end-user badness. > > BTW, Why something as crucial as async io threads is off by default ? > When I was trying to argue for not disabling async io threads prior to > 2.0 and fighting this issue "to death", I've heard argument: "it's > experimental feature because it's off by default". Is it ? > > In the end we found that when process linked to raw file dies, it'll > stop linked file driver. And as part of that underlying os file or > gzip stream (depending on compressed option) will be closed. Without > taking into account any possible in-flight async call for that file. > It's somewhat harmless for plain files to try to read/write closed fd, > but it'll clearly cause crash if some code tries to read from closed > (and freed) gzip stream. And of course tiny possibility of > reading/writing to/from another file that happened to reuse same fd is > not fun either. > > We found that file_sorter is actually passing compressed option "just > case" all the time and we confirmed that indeed crashes happen because > of those "compressed by not really" raw file ports. > > Couchbase Server 2.0.1 will ship with workaround that replaces > file_sorter from stdlib with it's tiny fork that cuts compressed > option out. I've seen Filipe produced erlang vm patch for that issue > too, but what I've seen only covers closing compressed files. IMHO > right fix would be to cover both options. > > I'm also seeing some folks in this thread being unhappy and somewhat > angry. Apparently they seem to interpret Damien's opinion as bashing > of Erlang. Which is IMHO not the case. I think his arguments apply for > core database software. > > And In my humble opinion candid expressions like that should be > encouraged and studied with cold minds. > > It is true that we have found that getting performance out of Erlang > and in general understanding what happens inside VM is next to impossible. > > And, personally, even without knowing all I know about challenges of > getting performance out of Erlang VM I'd still say that doing core > database in erlang (or any other not C-like-low-level language) is > just crazy. IMHO. > > BTW, perhaps, not everybody here is aware that Damien has "erlanger of > the year" 2009 award. I guess for CouchDB. Indeed, it's very much like > love affair that's gone :) But hey, un-loved being is not necessarily > bad, right ? > > As for plans of using Erlang in Couchbase (which is former Membase). > We indeed plan to incrementally and gradually rewrite performance > sensitive pieces in C or C++. But there are no concrete plans of > getting rid of Erlang entirely, yet. It works ok for our cluster > management layer. > > And IMHO compared to some our competitors which either do all in > low-level language (mongo, rethinkdb) or high-level (riak) our > approach of combining low-level language for "moving bits around" and > high-level language for cluster management and orchestration seems to > work best. > > So even if we switch off Erlang completely, we'll very likely still > use something much higher level than C for cluster management and > other not performance sensitive but sometimes tricky pieces. > > On Fri, Jan 11, 2013 at 3:00 AM, > wrote: > > Date: Fri, 11 Jan 2013 09:43:36 +0100 > From: Henning Diedrich > > To: Anton Lebedevich > > Cc: "erlang-questions@REDACTED > " > > Subject: Re: [erlang-questions] what is the "race condition bug in > core Erlang" mentioned by @damienkatz? > Message-ID: > > Content-Type: text/plain; charset=windows-1252 > > I love that how languages can be love affairs etc. > > A race condition in core Erlang, I am sure Damien will share his find. > > In the meantime maybe it's worth looking at the political > circumstances. > > Some might note not only that you fall out of love and then you're > irrationally deeply disappointed. You'll find all the feeling of > understanding was an illusion in the first place. And sometimes > you're even right. But that CouchDB surfed the Erlang hype, a > while ago Damien was able to close a deal, and for some reason I > don't know anyone quite understood announced that he'll reprogram > it all in C. > > Maybe it was an astounding proposition to program a transactional, > local (!) database in the age of Big Data in a language that > happens to be transactional by nature but is really made for > distribution, and it's not too surprising when that premise is now > abandoned. CouchDB is great for certain things, I have no doubt > about that, how else could it be so successful. > > But maybe one could ask, with the distribution layer of Couchbase > coming from Membase [1] (which means it would still be Erlang?) > but the local storage being in C (coming from memcached I > believe), was there simply a necessity in play because C would be > a better fit with the rest of the local part of Membase? Like > after renaming things, the CouchDB principle would be > reprogrammed, to replace or amend the memcached parts in Membase, > to become Coucbase, so it had to be in C? And dealing only with > the local storage parts, for a database, which was probably the > task ? I am not sure that's a natural for Erlang. > > You wouldn't think someone could be talking himself publicly into > loving his partner in a forced marriage? > > Me for instance, I love C. Erlang always makes me feel stupid. Who > wants that. > > Henning > > > [1] old: http://blog.couchbase.com/why-membase-uses-erlang > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From raould@REDACTED Fri Jan 11 19:50:15 2013 From: raould@REDACTED (Raoul Duke) Date: Fri, 11 Jan 2013 10:50:15 -0800 Subject: [erlang-questions] what is the "race condition bug in core Erlang" mentioned by @damienkatz? In-Reply-To: References: <50EFBFF7.8020103@gmail.com> Message-ID: > As Aliaksey said, they were. The commits are: thanks! somehow i failed to see that big explanatory email at all. i guess i somehow deleted it w/out noticing it in the thread in my mail reader or something. From raould@REDACTED Fri Jan 11 20:10:30 2013 From: raould@REDACTED (Raoul Duke) Date: Fri, 11 Jan 2013 11:10:30 -0800 Subject: [erlang-questions] what is the "race condition bug in core Erlang" mentioned by @damienkatz? (was: Re: erlang-questions Digest, Vol 95, Issue 9) In-Reply-To: References: Message-ID: > I'm also seeing some folks in this thread being unhappy and somewhat angry. > Apparently they seem to interpret Damien's opinion as bashing of Erlang. > Which is IMHO not the case. I think his arguments apply for core database > software. > > And In my humble opinion candid expressions like that should be encouraged > and studied with cold minds. personally i agree. i'd rather even see some nasty rants that are wrong (somebody named Z. S. comes to mind :-) than no rants at all. it is important to look at things from lots of angles. it is no skin off my back to ignore the utterly wrong rants. or just use them as entertainment. but if they have a nugget of truth in them anywhere, that is worth me hearing and learning from. > As for plans of using Erlang in Couchbase (which is former Membase). We > indeed plan to incrementally and gradually rewrite performance sensitive > pieces in C or C++. But there are no concrete plans of getting rid of Erlang > entirely, yet. It works ok for our cluster management layer. > > And IMHO compared to some our competitors which either do all in low-level > language (mongo, rethinkdb) or high-level (riak) our approach of combining > low-level language for "moving bits around" and high-level language for > cluster management and orchestration seems to work best. > > So even if we switch off Erlang completely, we'll very likely still use > something much higher level than C for cluster management and other not > performance sensitive but sometimes tricky pieces. in other words, we need another blog posting on the Unreasonable Effectiveness of Higher Level Languages Than Just Dumb C When I'm Doing More Than Performance Sensitive but Sometimes Tricky Pieces. :-) sincerely. From max.lapshin@REDACTED Fri Jan 11 20:11:15 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Fri, 11 Jan 2013 22:11:15 +0300 Subject: [erlang-questions] what is the "race condition bug in core Erlang" mentioned by @damienkatz? In-Reply-To: References: <50EFBFF7.8020103@gmail.com> Message-ID: Ok, my question is: why do they think that fixing the same bug in C program, written around libuv will be easier? I've written a video streaming server in ObjectiveC and I can tell how hard is to find bugs in single threaded callback-style program. So, this is a hard-to-find-bug. When you fix all easy-to-find-bugs there are only hard bugs. Erlang has all easy bugs fixed, left only hard bugs. This is why we will hear more and more that some horrible bug inside Erlang VM is found and fixed. Frankly speaking, I dont understand complaints about erlang performance, when half of your system is written in C. Fast path is coded in C and erlang has excelent capabilities for it. I've used such approach to 1) capture UDP packets in fast manner with my own hand-crafted gen_udp https://github.com/erlyvideo/flussonic/blob/master/apps/mpegts/c_src/mpegts_udp.c 2) use direct mmap access (which is impossible in Java): https://github.com/erlyvideo/flussonic/blob/master/apps/flussonic/c_src/mmap.c 3) write USB video capture: https://github.com/erlyvideo/uvc/blob/master/c_src/uvc.c 4) write my own database for storing ticks: https://github.com/maxlapshin/stockdb/blob/master/c_src/stockdb_format.c So I really don't understand the problem. You are writing a database server and use erlang prim_file? Sorry, are you really sure that you are writing a database server or you are just playing a new shiny toy? Was it a problem to open very simple erlang sources and find that prim_file is designed for non-blocking, not for speed? For example, when I understood that erlang's gen_udp cannot accept 10K of messages per second, I've rewritten it in C in a couple of days. If I was writing a database server with high requirements to disk IO, I would definitely use blocking but fast direct file access. But I don't see any of these reasonings in Damien's post, I see only "created cultures that focus on the wrong things". Yes, of course C created a culture which is focused only on right things. -------------- next part -------------- An HTML attachment was scrubbed... URL: From raould@REDACTED Fri Jan 11 20:16:37 2013 From: raould@REDACTED (Raoul Duke) Date: Fri, 11 Jan 2013 11:16:37 -0800 Subject: [erlang-questions] what is the "race condition bug in core Erlang" mentioned by @damienkatz? In-Reply-To: References: <50EFBFF7.8020103@gmail.com> Message-ID: On Fri, Jan 11, 2013 at 11:11 AM, Max Lapshin wrote: > So, this is a hard-to-find-bug. When you fix all easy-to-find-bugs there are > only hard bugs. Erlang has all easy bugs fixed, left only hard bugs. This is > why we will hear more and more that some horrible bug inside Erlang VM is > found and fixed. (not to disagree, just wondering out loud.) these kinds of bugs always make me wonder if they are there and hard because the design isn't helping as much as it should. when i hear "race condition" i think "gosh why aren't we all using dataflow?" for example, not that it might have any bearing on this particular case. (of course the dataflow core would have to be bug free ha ha.) > Was it a problem to open very simple erlang sources and find that prim_file is designed for non-blocking, not for speed? i thought the issue was an actual bug, not a design choice? From bourinov@REDACTED Sat Jan 12 10:57:35 2013 From: bourinov@REDACTED (Max Bourinov) Date: Sat, 12 Jan 2013 13:57:35 +0400 Subject: [erlang-questions] what is the "race condition bug in core Erlang" mentioned by @damienkatz? In-Reply-To: References: <50EFBFF7.8020103@gmail.com> Message-ID: +1 Best regards, Max On Fri, Jan 11, 2013 at 11:11 PM, Max Lapshin wrote: > Ok, my question is: why do they think that fixing the same bug in C > program, written around libuv will be easier? > I've written a video streaming server in ObjectiveC and I can tell how > hard is to find bugs in single threaded callback-style program. > > So, this is a hard-to-find-bug. When you fix all easy-to-find-bugs there > are only hard bugs. Erlang has all easy bugs fixed, left only hard bugs. > This is why we will hear more and more that some horrible bug inside Erlang > VM is found and fixed. > > > Frankly speaking, I dont understand complaints about erlang performance, > when half of your system is written in C. Fast path is coded in C and > erlang has excelent capabilities for it. > I've used such approach to > 1) capture UDP packets in fast manner with my own hand-crafted gen_udp > https://github.com/erlyvideo/flussonic/blob/master/apps/mpegts/c_src/mpegts_udp.c > 2) use direct mmap access (which is impossible in Java): > https://github.com/erlyvideo/flussonic/blob/master/apps/flussonic/c_src/mmap.c > 3) write USB video capture: > https://github.com/erlyvideo/uvc/blob/master/c_src/uvc.c > 4) write my own database for storing ticks: > https://github.com/maxlapshin/stockdb/blob/master/c_src/stockdb_format.c > > So I really don't understand the problem. > > You are writing a database server and use erlang prim_file? Sorry, are you > really sure that you are writing a database server or you are just playing > a new shiny toy? > Was it a problem to open very simple erlang sources and find that > prim_file is designed for non-blocking, not for speed? > > For example, when I understood that erlang's gen_udp cannot accept 10K of > messages per second, I've rewritten it in C in a couple of days. If I was > writing a database server with high requirements to disk IO, I would > definitely use blocking but fast direct file access. > > But I don't see any of these reasonings in Damien's post, I see only > "created cultures that focus on the wrong things". Yes, of course C created > a culture which is focused only on right things. > > _______________________________________________ > 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 Jan 13 02:38:36 2013 From: mfidelman@REDACTED (Miles Fidelman) Date: Sat, 12 Jan 2013 20:38:36 -0500 Subject: [erlang-questions] install problem - wxwidgets, R15B03 Message-ID: <50F2101C.4090906@meetinghouse.net> Hi Folks, I'm installing R15B03 on Debian Squeeze. I've managed to resolve all the dependency issues EXCEPT: wxWidgets not found, wx will NOT be usable I've tried: - installing wxWidgets-2.8.12 from source, and - installing the debian packages of libwxgtk2.8-dev libgtk2.0-dev from apt.wxwidgets.org - installed the erlang-wx package from the debian repo (the only thing not installed by the above) And finally, per the directions in the ./config output, stating: Please check that wx-config is in path, the directory where wxWidgets libraries are installed (returned by 'wx-config --libs' or 'wx-config --static --libs' command) is in LD_LIBRARY_PATH or equivalent variable and wxWidgets version is 2.8.4 or above. # which wx-config /usr/local/bin/wx-config # wx-config --libs -L/usr/local/lib -pthread -lwx_gtk2_richtext-2.8 -lwx_gtk2_aui-2.8 -lwx_gtk2_xrc-2.8 -lwx_gtk2_qa-2.8 -lwx_gtk2_html-2.8 -lwx_gtk2_adv-2.8 -lwx_gtk2_core-2.8 -lwx_base_xml-2.8 -lwx_base_net-2.8 -lwx_base-2.8 # echo $LD_LIBRARY_PATH /usr/local/lib configure still gives the "not found" error a lot of googling tells me at least a few other folks have this as their last remaining install problem, as well. Not really essential for my purposes, but still... is this a bug, or am I missing something? Any suggestions? Thanks! Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mfidelman@REDACTED Sun Jan 13 07:06:50 2013 From: mfidelman@REDACTED (Miles Fidelman) Date: Sun, 13 Jan 2013 01:06:50 -0500 Subject: [erlang-questions] install problem - wxwidgets, R15B03 - solved, sort of In-Reply-To: <50F2101C.4090906@meetinghouse.net> References: <50F2101C.4090906@meetinghouse.net> Message-ID: <50F24EFA.6030205@meetinghouse.net> Just installed R15B03 on Debian Squeeze. Ran into lots of problems getting wxwidgets to configure. I don't think I'm alone in this, googling for solutions, I found a number of other folks who got stuck on this. After digging through ../lib/wx/config.log, I discovered some interesting things: 1. First, I was getting errors about there not being a working copy of wxwidgets. Turns out, that when building wxWidgets, from source, one has to: ./configure --enable-unicode and, after make; make install, I think it's necessary to: exportLD_LIBRARY_PATH=/usr/local/lib ldconfig (not sure, the wxwidget build instructions are equivocal on this, after multiple tries, I'm no longer sure whether this step was necessary or not) 2. Once past that, I started getting warnings about not being able to link to wxwidgets, and looking in the logs, I found an error about not being able to find wx/stc/stc.h. Turns out that configure was looking in /usr/local/include/wx, but... the make install was putting the file under /usr/local/include/wx-2.8/ The simple fix was to do: ln -s /usr/local/include/wx-2.8/ /usr/local/include/wx After which configure found everything, and make worked just fine. I'm not quite wise enough in the ways of Autoconf to tell if this is a bug in ../lib/wx/configure.in, or if it's a bug in in the Makefile for wxwidgets (though ../lib/wx/configure.in is smart enough to find gtk files that are under ../gtk-2.0/...., so.... Figure this might be useful to folks. Miles Fidelman wrote: > Hi Folks, > > I'm installing R15B03 on Debian Squeeze. I've managed to resolve all > the dependency issues EXCEPT: > wxWidgets not found, wx will NOT be usable > > I've tried: > - installing wxWidgets-2.8.12 from source, and > - installing the debian packages of > libwxgtk2.8-dev libgtk2.0-dev > from apt.wxwidgets.org > > - installed the erlang-wx package from the debian repo (the only thing > not installed by the above) > > And finally, per the directions in the ./config output, stating: > Please check that wx-config is in path, the directory > where wxWidgets libraries are installed (returned by > 'wx-config --libs' or 'wx-config --static --libs' command) > is in LD_LIBRARY_PATH or equivalent variable and > wxWidgets version is 2.8.4 or above. > # which wx-config > /usr/local/bin/wx-config > # wx-config --libs > -L/usr/local/lib -pthread -lwx_gtk2_richtext-2.8 -lwx_gtk2_aui-2.8 > -lwx_gtk2_xrc-2.8 -lwx_gtk2_qa-2.8 -lwx_gtk2_html-2.8 > -lwx_gtk2_adv-2.8 -lwx_gtk2_core-2.8 -lwx_base_xml-2.8 > -lwx_base_net-2.8 -lwx_base-2.8 > # echo $LD_LIBRARY_PATH > /usr/local/lib > > configure still gives the "not found" error > > a lot of googling tells me at least a few other folks have this as > their last remaining install problem, as well. > > Not really essential for my purposes, but still... is this a bug, or > am I missing something? > > Any suggestions? > > Thanks! > > Miles Fidelman > > > > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mfidelman@REDACTED Sun Jan 13 07:08:41 2013 From: mfidelman@REDACTED (Miles Fidelman) Date: Sun, 13 Jan 2013 01:08:41 -0500 Subject: [erlang-questions] R15B03 - make check? Message-ID: <50F24F69.6010302@meetinghouse.net> Just installed R15B03. I seem to recall that R14 had a "make check" or "make test" that ran a fairly in-depth set of regression tests. This doesn't seem to be in R15. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From aggelgian@REDACTED Sun Jan 13 18:00:18 2013 From: aggelgian@REDACTED (Aggelos Giantsios) Date: Sun, 13 Jan 2013 19:00:18 +0200 Subject: [erlang-questions] Binaries and Core Erlang Message-ID: Hello everybody!! Let's assume we have the following code: -module(foo). bar() -> <<1:3>>. In R15B03, calling foo:bar() evaluates to <<1:3>> as we should expect. Should you compile the module to Core Erlang the resulting code is 'foo'/0 = fun () -> #{#<1>(3,1,'integer',['unsigned'|['big']])}# and by using the core_scan and core_parse modules the resulting AST in record format of foo is {c_fun,[],[], {c_binary,[], [{c_bitstr,[], {c_literal,[],1}, {c_literal,[],3}, {c_literal,[],1}, {c_literal,[],integer}, {c_literal,[],[unsigned,big]}}]}} Having said that, let's try to evaluate the above #c_fun{}. #c_fun{} has no parameters so we use an empty set of bindings and we evaluate #c_binary{}. #c_binary{} evaluates to the concatenation of the [#c_bitstr{}]. We have one #c_bitstr{} so the resulting valu is the value of #c_bitstr{}. #c_bitstr{} evaluates to <<1:3/unsigned-big-integer-unit:1>> that equals to <<1:3>> making this the overall value of the #c_fun{}, which is consistent with what we got from the interpreter. However, in the Core Erlang 1.0.3 language specs, it explicitly says that the number of bits in the resulting value of a #c_binary{} must be divisible by 8 making it a valid Erlang binary. In this case, the #c_binary{} evaluates to the bitstring <<1:3>> which is not a valid binary. So, in theory, we should have raised an exception at this point. But this is not what happens when we evaluate foo:bar/0 in the interpreter. So is there an inconsistency with the Core Erlang specs or am I missing something? Thanks, Aggelos -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Sun Jan 13 21:06:06 2013 From: erlang@REDACTED (Erik Reitsma) Date: Sun, 13 Jan 2013 21:06:06 +0100 Subject: [erlang-questions] Erlang4Android Message-ID: <50F313AE.8050303@ernovation.com> An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Sun Jan 13 21:46:04 2013 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Sun, 13 Jan 2013 21:46:04 +0100 Subject: [erlang-questions] Binaries and Core Erlang In-Reply-To: References: Message-ID: <50F31D0C.3010706@gmail.com> I think the short answer is that the Core Erlang spec was not updated when bitstrings were added. /Richard On 2013-01-13 18:00, Aggelos Giantsios wrote: > Hello everybody!! > > Let's assume we have the following code: > > -module(foo). > bar() -> <<1:3>>. > > In R15B03, calling foo:bar() evaluates to <<1:3>> as we should expect. > > Should you compile the module to Core Erlang the resulting code is > > 'foo'/0 = > fun () -> > #{#<1>(3,1,'integer',['unsigned'|['big']])}# > > and by using the core_scan and core_parse modules the resulting AST in > record format of foo is > > {c_fun,[],[], > {c_binary,[], > [{c_bitstr,[], > {c_literal,[],1}, > {c_literal,[],3}, > {c_literal,[],1}, > {c_literal,[],integer}, > {c_literal,[],[unsigned,big]}}]}} > > Having said that, let's try to evaluate the above #c_fun{}. > #c_fun{} has no parameters so we use an empty set of bindings and we > evaluate #c_binary{}. > #c_binary{} evaluates to the concatenation of the [#c_bitstr{}]. We have > one #c_bitstr{} so the resulting valu is the value of #c_bitstr{}. > #c_bitstr{} evaluates to <<1:3/unsigned-big-integer-unit:1>> that equals > to <<1:3>> making this the overall value of the #c_fun{}, which is > consistent with what we got from the interpreter. > > However, in the Core Erlang 1.0.3 language specs, it explicitly says > that the number of bits in the resulting value of a #c_binary{} must be > divisible by 8 making it a valid Erlang binary. In this case, the > #c_binary{} evaluates to the bitstring <<1:3>> which is not a valid > binary. So, in theory, we should have raised an exception at this point. > But this is not what happens when we evaluate foo:bar/0 in the interpreter. > > So is there an inconsistency with the Core Erlang specs or am I missing > something? > > Thanks, > Aggelos > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From aggelgian@REDACTED Sun Jan 13 23:29:51 2013 From: aggelgian@REDACTED (Aggelos Giantsios) Date: Mon, 14 Jan 2013 00:29:51 +0200 Subject: [erlang-questions] Binaries and Core Erlang In-Reply-To: <50F31D0C.3010706@gmail.com> References: <50F31D0C.3010706@gmail.com> Message-ID: That actually makes sense. Thanks for the clarification. Aggelos On Sun, Jan 13, 2013 at 10:46 PM, Richard Carlsson < carlsson.richard@REDACTED> wrote: > I think the short answer is that the Core Erlang spec was not updated when > bitstrings were added. > > /Richard > > > On 2013-01-13 18:00, Aggelos Giantsios wrote: > >> Hello everybody!! >> >> Let's assume we have the following code: >> >> -module(foo). >> bar() -> <<1:3>>. >> >> In R15B03, calling foo:bar() evaluates to <<1:3>> as we should expect. >> >> Should you compile the module to Core Erlang the resulting code is >> >> 'foo'/0 = >> fun () -> >> #{#<1>(3,1,'integer',['**unsigned'|['big']])}# >> >> and by using the core_scan and core_parse modules the resulting AST in >> record format of foo is >> >> {c_fun,[],[], >> {c_binary,[], >> [{c_bitstr,[], >> {c_literal,[],1}, >> {c_literal,[],3}, >> {c_literal,[],1}, >> {c_literal,[],integer}, >> {c_literal,[],[unsigned,big]}}**]}} >> >> Having said that, let's try to evaluate the above #c_fun{}. >> #c_fun{} has no parameters so we use an empty set of bindings and we >> evaluate #c_binary{}. >> #c_binary{} evaluates to the concatenation of the [#c_bitstr{}]. We have >> one #c_bitstr{} so the resulting valu is the value of #c_bitstr{}. >> #c_bitstr{} evaluates to <<1:3/unsigned-big-integer-**unit:1>> that >> equals >> to <<1:3>> making this the overall value of the #c_fun{}, which is >> consistent with what we got from the interpreter. >> >> However, in the Core Erlang 1.0.3 language specs, it explicitly says >> that the number of bits in the resulting value of a #c_binary{} must be >> divisible by 8 making it a valid Erlang binary. In this case, the >> #c_binary{} evaluates to the bitstring <<1:3>> which is not a valid >> binary. So, in theory, we should have raised an exception at this point. >> But this is not what happens when we evaluate foo:bar/0 in the >> interpreter. >> >> So is there an inconsistency with the Core Erlang specs or am I missing >> something? >> >> Thanks, >> Aggelos >> >> >> ______________________________**_________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/**listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From inanun@REDACTED Mon Jan 14 04:36:12 2013 From: inanun@REDACTED (Kyungho Yun) Date: Mon, 14 Jan 2013 12:36:12 +0900 Subject: [erlang-questions] Where can I get information about segfault? Message-ID: Hi list, I met segfault message. kernel: beam.smp[25999]: segfault at 000000000000039f rip 00000000004529f6 rsp 0000000043b36dc0 error 6 I googled and found a looks similar web page ( http://erlang.org/pipermail/erlang-bugs/2010-August/001946.html ) but it looks already fixed issue. No more information in there. Q1. How can I get information about why my erlang is dead? There is no core dump file, There is only the message. Q2. Where can I get information about segfault and error 6 in erlang? I want to know what means error 6. Q3. What can I do to know why erlang is dead with the message? thanks. Best Regards, nanun. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vivek.ayer@REDACTED Mon Jan 14 04:38:06 2013 From: vivek.ayer@REDACTED (Vivek Ayer) Date: Sun, 13 Jan 2013 19:38:06 -0800 Subject: [erlang-questions] Erlang4Android In-Reply-To: <50F313AE.8050303@ernovation.com> References: <50F313AE.8050303@ernovation.com> Message-ID: Erik, This is awesome! I just tried it out. I've been waiting for something like this! Keep up the good work! Vivek On Sun, Jan 13, 2013 at 12:06 PM, Erik Reitsma wrote: > Hi all, > > I have put my port of Erlang to Android on Google Code: > http://code.google.com/p/erlang4android/ > > To install it on your Android device, you should allow applications from > unknown sources, because the app is not delivered through Google Play (yet). > The Android device does *not* have to be rooted. > > It depends on Scripting Layer for Android (SL4A). So in order to use it, you > should first install SL4A r6 from here: > http://code.google.com/p/android-scripting/downloads/detail?name=sl4a_r6.apk > Then install the APK for Erlang, this one: > http://code.google.com/p/erlang4android/downloads/detail?name=ErlangForAndroid.apk > This app is just the installer. Run it to actually install Erlang/OTP. I > have included as much of OTP as might be remotely useful, so the download is > 36.5 MB. Of course you want to use the megaco and orber applications on your > phone! > > You can use the SL4A API through the module android that I have added. I > have added a very simple example, to show you how you can make a small gui > and respond to events. Study the SL4A API to do other Android things. > > You can run some Erlang code by putting your source in the SL4A scripts > directory on the Android device, which is /sdcard/sl4a/scripts/. The .erl > file should contain and export a function main/0, which will be called when > the script is run. The .erl file will be compiled to a .beam file > automatically, only if the .beam file does not exist. A minor inconvenience > now is, that if the .erl file is modified, it will not be recompiled unless > the .beam file is removed. The scripts directory will be in the code path, > so if you put other .beam files there, they will be found, and .erl files > there will be compiled too, if necessary. > > Enjoy! > > *Erik. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From max.lapshin@REDACTED Mon Jan 14 08:29:58 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 14 Jan 2013 10:29:58 +0300 Subject: [erlang-questions] Erlang Moscow meetup: my speach about protecting system from overload Message-ID: Meetup of erlang programmers was on 12 January in Moscow. I was speaking about some useful tips for protecting erlang system from overload and crash. Here they are in posts: http://blog.erlyvideo.org/2013/01/01/overload-protection-1/ introducing feedback inside system parts http://blog.erlyvideo.org/2013/01/02/overload-protection-2/ early rejecting requests http://blog.erlyvideo.org/2013/01/03/deadlocks-1/ tips to workaround deadlocks http://blog.erlyvideo.org/2013/01/04/unobtrusive-read/ some notes about non-messaging reads http://blog.erlyvideo.org/2013/01/05/maintain-long-requests/ controlling long user tasks It would be good if this will be helpful to someone. Any feedback on these ideas is welcome. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gabre@REDACTED Mon Jan 14 09:25:43 2013 From: gabre@REDACTED (=?iso-8859-2?b?SG9zc3r6IA==?= =?iso-8859-2?b?R+Fib3I=?=) Date: Mon, 14 Jan 2013 09:25:43 +0100 Subject: [erlang-questions] Wx Toolbars in Erlang Message-ID: <20130114092543.17352hpaybulsah3@webmail.elte.hu> Hello, I have started to implement a GUI for an Erlang software but I have some problems with Wx Toolbars. I googled it and searched in the Wx docs but found nothing so I think that it may be an Erlang Wx related problem (or I am doing something wrong). I have a window and a toolbar in it which is created at the startup as it is shown and coded in the Erlang wx demo (my one has no tools on it). I have to add buttons to this toolbar dinamically and remove other buttons so I want to alter the whole toolbar dinamically. I have a function which is ran in those cases when I have to modify the toolbar: my_fun() -> Frame = wx:typeCast(wxWindow:findWindowByName("win"), wxFrame), TB = wxFrame:getToolBar(Frame), BM = wxBitmap:new(...,[{type,?wxBITMAP_TYPE_JPEG}]), wxToolBar:addTool(TB, 1, "label", BM), wxToolBar:realize(TB). (and the path at ... is correct and valid) I have double checked that my fun is executed but nothing is added to the toolbar. How can I solve this problem? Regards, Gabor From erlang@REDACTED Mon Jan 14 11:37:11 2013 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 14 Jan 2013 11:37:11 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: <50F313AE.8050303@ernovation.com> References: <50F313AE.8050303@ernovation.com> Message-ID: This is amazing - works like a charm - fantastic. Quick comment - It would be very nice to make the client and server in fac_example.zip run "out of the box" client.erl is a *must read* file. server.erl does not export main/0 and should be changed to spawn the server - otherwise you don't get control in the shell ... First thoughts/questions: - The download is rather large - I'm sure this could be made a *lot smaller - Need Erlang APIs to the camera, GPS, .... etc. - The client.erl example shows I can make an application *without* eclipse it would be very nice top abstract the details of the layout() function so as not to see the XML :-) Cheers /Joe On Sun, Jan 13, 2013 at 9:06 PM, Erik Reitsma wrote: > Hi all, > > I have put my port of Erlang to Android on Google Code: > http://code.google.com/p/erlang4android/ > > To install it on your Android device, you should allow applications from > unknown sources, because the app is not delivered through Google Play > (yet). The Android device does *not* have to be rooted. > > It depends on Scripting Layer for Android (SL4A). So in order to use it, > you should first install SL4A r6 from here: > http://code.google.com/p/android-scripting/downloads/detail?name=sl4a_r6.apkThen install the APK for Erlang, this one: > http://code.google.com/p/erlang4android/downloads/detail?name=ErlangForAndroid.apk > This app is just the installer. Run it to actually install Erlang/OTP. I > have included as much of OTP as might be remotely useful, so the download > is 36.5 MB. Of course you want to use the megaco and orber applications on > your phone! > > You can use the SL4A API through the module android that I have added. I > have added a very simple example, to show you how you can make a small gui > and respond to events. Study the SL4A API to do other Android things. > > You can run some Erlang code by putting your source in the SL4A scripts > directory on the Android device, which is /sdcard/sl4a/scripts/. The .erl > file should contain and export a function main/0, which will be called when > the script is run. The .erl file will be compiled to a .beam file > automatically, only if the .beam file does not exist. A minor inconvenience > now is, that if the .erl file is modified, it will not be recompiled unless > the .beam file is removed. The scripts directory will be in the code path, > so if you put other .beam files there, they will be found, and .erl files > there will be compiled too, if necessary. > > Enjoy! > > *Erik. > > > _______________________________________________ > 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 Mon Jan 14 12:45:48 2013 From: dangud@REDACTED (Dan Gudmundsson) Date: Mon, 14 Jan 2013 12:45:48 +0100 Subject: [erlang-questions] Wx Toolbars in Erlang In-Reply-To: <20130114092543.17352hpaybulsah3@webmail.elte.hu> References: <20130114092543.17352hpaybulsah3@webmail.elte.hu> Message-ID: This works for me (tested on linux) Frame = wxFrame:new(Wx, ?wxID_ANY, "Frame"), TB = wxFrame:createToolBar(Frame), wxToolBar:addTool(TB, 747, "PressMe", wxArtProvider:getBitmap("wxART_COPY", [{size, {16,16}}]), [{shortHelp, "Press Me"}]), Add = fun(#wx{}, _) -> wxToolBar:addTool(TB, -1, "Added", wxArtProvider:getBitmap("wxART_TICK_MARK", [{size, {16,16}}]), [{shortHelp, "Test 2 popup text"}]) end, wxFrame:connect(Frame, command_menu_selected, [{callback, Add}, {id, 747}]), wxFrame:show(Frame), /Dan On Mon, Jan 14, 2013 at 9:25 AM, Hossz? G?bor wrote: > Hello, > > I have started to implement a GUI for an Erlang software but I have some > problems with Wx Toolbars. I googled it and searched in the Wx docs but > found nothing so I think that it may be an Erlang Wx related problem (or I > am doing something wrong). > > I have a window and a toolbar in it which is created at the startup as it is > shown and coded in the Erlang wx demo (my one has no tools on it). I have to > add buttons to this toolbar dinamically and remove other buttons so I want > to alter the whole toolbar dinamically. I have a function which is ran in > those cases when I have to modify the toolbar: > my_fun() -> > Frame = wx:typeCast(wxWindow:findWindowByName("win"), wxFrame), > TB = wxFrame:getToolBar(Frame), > BM = wxBitmap:new(...,[{type,?wxBITMAP_TYPE_JPEG}]), > wxToolBar:addTool(TB, 1, "label", BM), > wxToolBar:realize(TB). > (and the path at ... is correct and valid) > I have double checked that my fun is executed but nothing is added to the > toolbar. > How can I solve this problem? > > Regards, > Gabor > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From mabrek@REDACTED Mon Jan 14 13:08:58 2013 From: mabrek@REDACTED (Anton Lebedevich) Date: Mon, 14 Jan 2013 16:08:58 +0400 Subject: [erlang-questions] compare and set semantics using ets? Message-ID: <50F3F55A.5080404@gmail.com> Hello. Is it possible to implement atomic compare-and-set semantics using ets? Currently it allows to increment counter and return new value atomically but "don't touch the counter if someone touched it before me" is quite tricky or impossible to achieve. I might be digging in a wrong direction, the problem is following: There is a shared limited resource (i.e. memory). Incoming requests require some (specified in headers) amount of the resource which is freed on completion. Each request is served via it's own process. The process needs to allocate the resource and serve the request or refuse if there is not enough resource available. Simple (and slow on high request rate) solution is to implement gen_server that handles allocation requests and either grants them or refuses based on calculated total. https://github.com/ferd/dispcount uses ets counter with known initial value to implement compare-and-set but in my case the initial value (currently allocated amount) is unknown. Regards, Anton Lebedevich. From essen@REDACTED Mon Jan 14 13:19:18 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Mon, 14 Jan 2013 13:19:18 +0100 Subject: [erlang-questions] Where can I get information about segfault? In-Reply-To: References: Message-ID: <50F3F7C6.7060905@ninenines.eu> Just a piece of advice, I don't know the answers to your questions. On 01/14/2013 04:36 AM, Kyungho Yun wrote: > Q1. How can I get information about why my erlang is dead? > There is no core dump file, There is only the message. To get a core dump next time, you should make sure that the system allows its creation. The following link explains pretty well how to enable core dumps: http://www.akadia.com/services/ora_enable_core.html -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From max.lapshin@REDACTED Mon Jan 14 13:24:37 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 14 Jan 2013 15:24:37 +0300 Subject: [erlang-questions] compare and set semantics using ets? In-Reply-To: <50F3F55A.5080404@gmail.com> References: <50F3F55A.5080404@gmail.com> Message-ID: You want something like iptables -L which atomically tells you current value and reset it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mabrek@REDACTED Mon Jan 14 13:44:49 2013 From: mabrek@REDACTED (Anton Lebedevich) Date: Mon, 14 Jan 2013 16:44:49 +0400 Subject: [erlang-questions] compare and set semantics using ets? In-Reply-To: References: <50F3F55A.5080404@gmail.com> Message-ID: <50F3FDC1.6090503@gmail.com> On 01/14/2013 04:24 PM, Max Lapshin wrote: > You want something like iptables -L which atomically tells you current > value and reset it. You'll need -Z flag for iptables to actually reset counters. Here's the description of compare and set (or swap): http://en.wikipedia.org/wiki/Compare_and_swap Regards, Anton Lebedevich. From dmkolesnikov@REDACTED Mon Jan 14 13:45:56 2013 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Mon, 14 Jan 2013 14:45:56 +0200 Subject: [erlang-questions] compare and set semantics using ets? In-Reply-To: <50F3F55A.5080404@gmail.com> References: <50F3F55A.5080404@gmail.com> Message-ID: <22A30FF7-4E05-4040-8AEF-8471D869BAC1@gmail.com> Hello, not it is not possible w/o touching VM. I've started to implement "advanced counters" via dedicated process. BTW, you approach with manager process is aligned with OTP principles. - Dmitry On Jan 14, 2013, at 2:08 PM, Anton Lebedevich wrote: > Hello. > > Is it possible to implement atomic compare-and-set semantics using ets? > > Currently it allows to increment counter and return new value atomically > but "don't touch the counter if someone touched it before me" is quite > tricky or impossible to achieve. > > I might be digging in a wrong direction, the problem is following: > There is a shared limited resource (i.e. memory). Incoming requests > require some (specified in headers) amount of the resource which is > freed on completion. Each request is served via it's own process. The > process needs to allocate the resource and serve the request or refuse > if there is not enough resource available. > > Simple (and slow on high request rate) solution is to implement > gen_server that handles allocation requests and either grants them or > refuses based on calculated total. > > https://github.com/ferd/dispcount uses ets counter with known initial > value to implement compare-and-set but in my case the initial value > (currently allocated amount) is unknown. > > Regards, > Anton Lebedevich. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From mononcqc@REDACTED Mon Jan 14 14:49:56 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 14 Jan 2013 08:49:56 -0500 Subject: [erlang-questions] Erlang Moscow meetup: my speach about protecting system from overload In-Reply-To: References: Message-ID: <20130114134954.GA1503@ferdmbp.local> Hi Max, Very interesting read. Really liked the following quote: "Deadlocked system maintain good load (about zero) but it provides bad service (about zero)". One thing you seem to rely a lot on is the use of process_info/2. I noticed you used it to get the message queue length, and also to read the process dictionary by foreign processes. Does accessing foreign data with process info have any noticeable cost? How does it compare to using ETS tables? Do you use the process dictionary due to better performances, or because it reduces the pain of maintaining multiple tables? I was wondering about using the message queue length as some arbitrary measure of load to implement ideas described in www.eecs.harvard.edu/~michaelm/postscripts/handbook2001.pdf Basically statistically optimal choices in [sequential] load-balancing can be made by picking 2 random entries, checking the load, and picking the most available one. Using message queue lengths for this would have been useful, but I was afraid doing it on average twice per request could have a prohibitive cost in a production system. I never tested it, but your post reminded me of that. Regarding the use of process dictionary to store states to debug (put(status, write_frame_on_disk), etc.), would you still use that system given newer OTP versions tell you what function they're currently running? I'm assuming the process dictionary is a bit more fool proof to refactoring when you come to rely on it. On 01/14, Max Lapshin wrote: > Meetup of erlang programmers was on 12 January in Moscow. > > I was speaking about some useful tips for protecting erlang system from > overload and crash. > > Here they are in posts: > > http://blog.erlyvideo.org/2013/01/01/overload-protection-1/ introducing > feedback inside system parts > http://blog.erlyvideo.org/2013/01/02/overload-protection-2/ early > rejecting requests > http://blog.erlyvideo.org/2013/01/03/deadlocks-1/ tips to workaround > deadlocks > http://blog.erlyvideo.org/2013/01/04/unobtrusive-read/ some notes about > non-messaging reads > http://blog.erlyvideo.org/2013/01/05/maintain-long-requests/ controlling > long user tasks > > It would be good if this will be helpful to someone. Any feedback on these > ideas is welcome. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From essen@REDACTED Mon Jan 14 15:51:45 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Mon, 14 Jan 2013 15:51:45 +0100 Subject: [erlang-questions] Monitor sockets Message-ID: <50F41B81.4050105@ninenines.eu> Hello, It is currently not possible to only listen for tcp_closed events on a socket through the current interface. Sure you can link with a gen_tcp socket, because the socket is a port and you can link to these, but you can't with ssl because the socket is an opaque type and the port is deep inside it (or at least not easily). We could have one of two solutions to know when a socket closed. I would like to implement whichever is the best. Please tell me and I'll send a patch. 1) Add gen_tcp:link/1, gen_tcp:unlink/1, ssl:link/1 and ssl:unlink/1 to link/unlink with the port that manages the socket This would likely be the easiest, but requires trapping exits and I would like to avoid doing that, because the user's code may not want that. 2) Add {inet,ssl}:setopts([{active, once_closed_only}]), would only listen for and send the {tcp,ssl}_closed messages, option name could be improved This would be perhaps harder to write, but would be much easier to work with, as this would be just a message to receive, and a message we already know. Would OTP team be interested in such a feature? -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From jesper.louis.andersen@REDACTED Mon Jan 14 16:01:31 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 14 Jan 2013 16:01:31 +0100 Subject: [erlang-questions] compare and set semantics using ets? In-Reply-To: <50F3F55A.5080404@gmail.com> References: <50F3F55A.5080404@gmail.com> Message-ID: <1869BFB0-1B59-4455-AD66-90E7AF6E2216@erlang-solutions.com> On Jan 14, 2013, at 1:08 PM, Anton Lebedevich wrote: > Is it possible to implement atomic compare-and-set semantics using ets? Only in a limited fashion. I guess we either need a specific CAS-instruction, or you have to look up how it is achieved in mnesia, which does to transactional updates. CAS would relate to modern hardware implementations of software transactional memory. Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen From jesper.louis.andersen@REDACTED Mon Jan 14 16:02:30 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 14 Jan 2013 16:02:30 +0100 Subject: [erlang-questions] Erlang Moscow meetup: my speach about protecting system from overload In-Reply-To: <20130114134954.GA1503@ferdmbp.local> References: <20130114134954.GA1503@ferdmbp.local> Message-ID: <1653D6FA-9318-47A7-A3D8-34CFF2CEDE4E@erlang-solutions.com> On Jan 14, 2013, at 2:49 PM, Fred Hebert wrote: > Very interesting read. Really liked the following quote: "Deadlocked > system maintain good load (about zero) but it provides bad service > (about zero)". Yes, I enjoyed reading it as well. It is always good to see how other people have solved these kinds of problems. Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen From mabrek@REDACTED Mon Jan 14 16:13:27 2013 From: mabrek@REDACTED (Anton Lebedevich) Date: Mon, 14 Jan 2013 19:13:27 +0400 Subject: [erlang-questions] compare and set semantics using ets? In-Reply-To: <1869BFB0-1B59-4455-AD66-90E7AF6E2216@erlang-solutions.com> References: <50F3F55A.5080404@gmail.com> <1869BFB0-1B59-4455-AD66-90E7AF6E2216@erlang-solutions.com> Message-ID: <50F42097.3010909@gmail.com> On 01/14/2013 07:01 PM, Jesper Louis Andersen wrote: > On Jan 14, 2013, at 1:08 PM, Anton Lebedevich wrote: > >> Is it possible to implement atomic compare-and-set semantics using ets? > > Only in a limited fashion. I guess we either need a specific CAS-instruction, or you have to look up how it is achieved in mnesia, which does to transactional updates. Good catch, I've completely forgot that mnesia already does it, will take a look at its sources. > CAS would relate to modern hardware implementations of software transactional memory. One word CAS (Intel CMPXCHG) doesn't need bleeding edge hardware, it has been there for quite a long time. Regards, Anton Lebedevich. From pan@REDACTED Mon Jan 14 16:33:55 2013 From: pan@REDACTED (Patrik Nyblom) Date: Mon, 14 Jan 2013 16:33:55 +0100 Subject: [erlang-questions] Unused local function kills the process when the code updates In-Reply-To: References: <50ED539D.6020802@erlang.org> Message-ID: <50F42563.3070108@erlang.org> On 01/09/2013 09:18 PM, Ivan Glushkov wrote: > Thank you for the answer, Patric. > You mean there's no way to get the local function saved if it has smth > like "io:format" call in it? > It will always kill the process after the second code update, won't it? > Ivan. Yes, that's right. The "module-fun" is there to solve exactly that problem (among others). Cheers, /Patrik > > On Wed, Jan 9, 2013 at 3:25 PM, Patrik Nyblom wrote: >> Hi, >> >> As you changed the code and reloaded it, your fun, which is held in the >> process belongs to old code. The function signature has changed when you >> changed and loaded the new version of the module. When you reload again, you >> need to purge the old code, which is referenced by your process and the >> process is killed. The fact that the fun has not changed textually is only a >> guarantee if it does no local calls and has no environment. As soon as the >> code changes the fun's will get new signatures as there is a hash of the >> module included in the fun signature, there is no optimization to keep fun >> signatures for this case. >> >> If you want long living fun's just change the fun to a module fun: >> >> register(?MODULE, spawn_link(?MODULE, loop, [fun ?MODULE:logger/2])). >> >> >> Cheers, >> /Patrik >> >> On 01/09/2013 09:29 AM, Ivan Glushkov wrote: >> >> Hi there. >> >> I do know that using long-lived local function is not a good idea, but >> I'm a bit concerned about the following behavior. >> >> I have a small example: >> $ cat my.erl >> -module(my). >> %-export([foo/0]). >> -export([ start/0, loop/1 ]). >> >> start() -> register(?MODULE, spawn_link(?MODULE, loop, [fun logger/2])). >> >> %foo() -> apply(fun erlang:now/0, []). >> >> loop(Logger) -> >> receive V -> >> io:format("received ~p~n", [V]), >> ?MODULE:loop(Logger) >> after 100 -> ?MODULE:loop(Logger) >> end. >> >> logger(Msg, Args) -> io:format(Msg, Args). >> >> >> You see, here I save 'fun logger/2' into a loop state, and I don't use >> it anymore. >> Then if I do the following steps: >> - compile and load the code >> - start loop >> - uncomment foo >> - compile and load the code twice >> >> it kills my process. >> >> I would understand such a behavior if I didn't use fully qualified >> name for the 'loop' function. But I do. >> Actually, the same thing is happened if I use a gen_server instead of >> loop, and save my variable in it's state. >> >> I've done some research and compiled to assembler both versions of the >> code (attached). >> The only valuable difference (beside adding 'foo' surely) is the labels: >> >> 1. where the anonymous function 'fun logger/2' is defined: >> -{function, '-start/0-fun-0-', 2, 14}. >> - {label,13}. >> +{function, '-start/0-fun-0-', 2, 16}. >> + {label,15}. >> {line,[{location,"my.erl",5}]}. >> {func_info,{atom,my},{atom,'-start/0-fun-0-'},2}. >> - {label,14}. >> - {call_only,2,{f,8}}. >> + {label,16}. >> + {call_only,2,{f,10}}. >> >> 2. where it is used to create a 'Logger' variable: >> - {make_fun2,{f,14},0,0,0}. >> + {make_fun2,{f,16},0,0,0}. >> >> 3. where the logger function itself is defined: >> -{function, logger, 2, 8}. >> - {label,7}. >> +{function, logger, 2, 10}. >> + {label,9}. >> {line,[{location,"my.erl",16}]}. >> {func_info,{atom,my},{atom,logger},2}. >> - {label,8}. >> + {label,10}. >> {line,[{location,"my.erl",16}]}. >> {call_ext_only,2,{extfunc,io,format,2}}. >> >> 4. and of course the total number of labels: >> -{labels, 15}. >> +{labels, 17}. >> >> I'm not an expert in the field, but it seems to me that this is not a >> great deal. Function signature hasn't been changed, I mean name and >> arity. Why does it break my code? >> >> What concerns me is that if for some reason I'm saving some opaque >> values (received from the user) in my gen_server state, I can't be >> sure that it won't break my code _even if it isn't used_. >> I'm almost sure it's a incorrect behavior. >> >> Best, >> Ivan. >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> From max.lapshin@REDACTED Mon Jan 14 16:44:22 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 14 Jan 2013 18:44:22 +0300 Subject: [erlang-questions] Erlang Moscow meetup: my speach about protecting system from overload In-Reply-To: <20130114134954.GA1503@ferdmbp.local> References: <20130114134954.GA1503@ferdmbp.local> Message-ID: Hi Fred. Glad to hear that my posts amused You. I use process_info because it is convenient: easy to manage data and easy to test. Any ets table is an external dependency. Also it is too hard to keep process length in ets table eithout process info call. Otp's current_function doesn't help beccause it shows something like gen:waitreply but i want to know what exactly process is doing. High-level put(status, smth) helps. The same is with initial function, it doesn't help to distinguish different streams On Monday, January 14, 2013, Fred Hebert wrote: > Hi Max, > > Very interesting read. Really liked the following quote: "Deadlocked > system maintain good load (about zero) but it provides bad service > (about zero)". > > One thing you seem to rely a lot on is the use of process_info/2. I > noticed you used it to get the message queue length, and also to read > the process dictionary by foreign processes. > > Does accessing foreign data with process info have any noticeable cost? > How does it compare to using ETS tables? Do you use the process > dictionary due to better performances, or because it reduces the pain of > maintaining multiple tables? > > I was wondering about using the message queue length as some arbitrary > measure of load to implement ideas described in > www.eecs.harvard.edu/~michaelm/postscripts/handbook2001.pdf > > Basically statistically optimal choices in [sequential] load-balancing > can be made by picking 2 random entries, checking the load, and picking > the most available one. Using message queue lengths for this would have > been useful, but I was afraid doing it on average twice per request > could have a prohibitive cost in a production system. I never tested it, > but your post reminded me of that. > > Regarding the use of process dictionary to store states to debug > (put(status, write_frame_on_disk), etc.), would you still use that system > given newer OTP versions tell you what function they're currently > running? I'm assuming the process dictionary is a bit more fool proof to > refactoring when you come to rely on it. > > > On 01/14, Max Lapshin wrote: > > Meetup of erlang programmers was on 12 January in Moscow. > > > > I was speaking about some useful tips for protecting erlang system from > > overload and crash. > > > > Here they are in posts: > > > > http://blog.erlyvideo.org/2013/01/01/overload-protection-1/ introducing > > feedback inside system parts > > http://blog.erlyvideo.org/2013/01/02/overload-protection-2/ early > > rejecting requests > > http://blog.erlyvideo.org/2013/01/03/deadlocks-1/ tips to workaround > > deadlocks > > http://blog.erlyvideo.org/2013/01/04/unobtrusive-read/ some notes about > > non-messaging reads > > http://blog.erlyvideo.org/2013/01/05/maintain-long-requests/ controlling > > long user tasks > > > > It would be good if this will be helpful to someone. Any feedback on > these > > ideas is welcome. > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alessandro.sivieri@REDACTED Mon Jan 14 18:58:59 2013 From: alessandro.sivieri@REDACTED (Alessandro Sivieri) Date: Mon, 14 Jan 2013 18:58:59 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: <50F313AE.8050303@ernovation.com> References: <50F313AE.8050303@ernovation.com> Message-ID: Hi, great work! Question: are you planning on distributing also the patches for the Erlang distribution? I saw in the wiki page of the project the description of the modifications, but in the "sources" section there are only the app sources (or maybe I missed them?)... -- Sivieri Alessandro alessandro.sivieri@REDACTED http://sivieri.wordpress.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Mon Jan 14 21:04:38 2013 From: erlang@REDACTED (Erik Reitsma) Date: Mon, 14 Jan 2013 21:04:38 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: References: <50F313AE.8050303@ernovation.com> Message-ID: <50F464D6.9030700@ernovation.com> On 01/14/2013 11:37 AM, Joe Armstrong wrote: > This is amazing - works like a charm - fantastic. > I am glad it not only works on my own devices. :-) > Quick comment - > > It would be very nice to make the client and server in > fac_example.zip run "out of the box" > client.erl is a *must read* file. server.erl does not export main/0 > and should be changed to > spawn the server - otherwise you don't get control in the shell ... > The server was intended to be run on some server, not on the Android device. Only the client should run on the device. Of course, the server could easily be adapted to run on the same device, or another device, as well. The example was mainly intended for people familiar with Erlang, who want to try their Erlang skills on Android. A different example may be required for Android programmers who do not yet know Erlang. > First thoughts/questions: > > - The download is rather large - I'm sure this could be made a *lot > smaller Definitely. As I wrote, I put in as much as I could, mainly to show that all those libraries could run on the device. I intend to make a minimal installation too. The current download includes almost everything from OTP, including things like epmd (which also works, but you will need to start Erlang from a shell, probably with root permissions). I think I can probably remove the corba applications, the megaco application, ASN.1 and many others. I will see if I can make it possible to make your own selection of OTP applications, and perhaps even allow other repositories with non-OTP-applications. > - Need Erlang APIs to the camera, GPS, .... etc. For now the easiest way to do this is write wrappers around the SL4A APIs. Have you looked at those and found them lacking? You can find all available functions here: http://code.google.com/p/android-scripting/wiki/ApiReference I have actually only tried a view of them myself. All functionality from SL4A is available through the module android. I have implemented this using a dirty trick: I have modified error_handler.erl such that for an undefined function android:F(Args), the function android:rpc([Args]) will be called. So I only implemented android:rpc/1, which will be called for any other function android:F/N. Dirty, but if there is a new function in SL4A, it will be supported automagically. This is similar to the implementation for Python4Android. > - The client.erl example shows I can make an application *without* > eclipse > it would be very nice top abstract the details of the layout() > function > so as not to see the XML :-) > Yes. :-) SL4A does not provide an API to dynamically create gui elements, so this is a limitation with the current approach. It would be possible to write Erlang code that transforms something erlangy into the required XML. I would have to look at how generic that could be made, because I may be too lazy to specifically implement all possibilities for the layout XML. I think it would be possible to make some simple XML-generation from lists of tuples records. I will give it some thought. Regards, *Erik. From erlang@REDACTED Mon Jan 14 22:05:25 2013 From: erlang@REDACTED (Erik Reitsma) Date: Mon, 14 Jan 2013 22:05:25 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: References: <50F313AE.8050303@ernovation.com> Message-ID: <50F47315.3010302@ernovation.com> I have put the sources in a tgz file in the downloads section, for now. I am not sure if the license of the source is compatible with the requirements from Google Code, because the EPL was not an option. So I may move the source to Github, perhaps by cloning the otp repository. On 01/14/2013 06:58 PM, Alessandro Sivieri wrote: > Hi, > > great work! Question: are you planning on distributing also the > patches for the Erlang distribution? I saw in the wiki page of the > project the description of the modifications, but in the "sources" > section there are only the app sources (or maybe I missed them?)... > > -- > Sivieri Alessandro > alessandro.sivieri@REDACTED > http://sivieri.wordpress.com/ From max.lapshin@REDACTED Tue Jan 15 04:46:16 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Tue, 15 Jan 2013 06:46:16 +0300 Subject: [erlang-questions] Erlang Moscow meetup: my speach about protecting system from overload In-Reply-To: References: <20130114134954.GA1503@ferdmbp.local> Message-ID: Some small additions about handling issue of long startup procedure http://blog.erlyvideo.org/2013/01/14/long-coldstart/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthonym@REDACTED Tue Jan 15 07:40:28 2013 From: anthonym@REDACTED (Anthony Molinaro) Date: Mon, 14 Jan 2013 22:40:28 -0800 Subject: [erlang-questions] Any tcp related changes in R15B* that might cause this? In-Reply-To: <50EC6993.9000608@erix.ericsson.se> References: <20121214211117.GA86501@alumni.caltech.edu> <50CF35FF.6020101@erix.ericsson.se> <20130102172816.GA24637@alumni.caltech.edu> <20130103061626.GB26037@alumni.caltech.edu> <50EAF721.2020002@erix.ericsson.se> <20130108164231.GA40748@alumni.caltech.edu> <50EC6993.9000608@erix.ericsson.se> Message-ID: <20130115064028.GA53613@alumni.caltech.edu> Hi Sverker, I cannot get {exit_on_close, false}, to actually change the behavior of my test. I set it as an options to gen_tcp:listen/2 but gen_tcp:send/2 still returns {error,closed}. I also tried setting it at various other points with inet:setopts/2, but it never seems to make a difference. I'm using R15B02, but I'm wondering if you can modify my example, such that the gen_tcp:send/2 doesn't fail with {error,closed}. I reattached it without any modifications. You should be able to just compile it and run gen_tcp_test:test(10000). To see it fail. Hopefully you can show me the error of my ways ;) -Anthony On Tue, Jan 08, 2013 at 07:46:43PM +0100, Sverker Eriksson wrote: > Anthony Molinaro wrote: > >I agree that the new behavior of returning an emsgsize tcp_error is > >probably correct, however the new behavior also closes the socket. > > > >Before your changes mochiweb and my test could return a 400 error so > >the client would get a response even if they were sending in a bad > >request. After the change the client just gets a remote side closed > >connection message. > > > >So I guess the question is, why is the connection being closed? Is > >that also something the other packet protocols do? > > > Yes all packets protocols act the same in this sense. > > You can use socket option {exit_on_close, false} to only do a > half-close and still allow writing to the socket. > > /Sverker > > >Thanks for looking at it, > > > >-Anthony > > > >On Mon, Jan 07, 2013 at 05:26:09PM +0100, Sverker Eriksson wrote: > >>Thanks for the clarification, guys. > >>I've look at dc5f7190 and it seems like the change in error > >>handling was more or less intentional (by me). > >> > >>Old behavior was > >>1. Truncate a too long http line and return it as if it was ok. > >>2. Continue parsing rest of the line as if it were a new http line > >>which probably (and hopefully) results in a http_error. > >> > >>I didn't like that; as it returned a partially parsed line as if it > >>was ok, reported the error too late and confusing and also (I guess) > >>constituted a security bug that could be abused to trick the http > >>parsing with long lines. > >> > >>So I changed it to reject too long lines and return tcp_error, which > >>is what happens for all packet protocols when the length of the > >>packet is in some way invalid. > >> > >>The caller has to handle tcp_error's anyway, so it's a case of bad > >>fault identification. > >>I guess it would be nicer to return {http_error, "Line too long: > >>X-Randomaaaaaaaaaaaaaaaaaa..."} > >>or something like that. > >>I don't have time to fix that now, but don't think it would be too > >>hard do if anyone is eager... > >> > >> > >>/Sverker, Erlang/OTP > >> > >> > >> > >>Steve Vinoski wrote: > >>>Same results with this test: works on commits prior to dc5f7190, fails > >>>on dc5f7190. > >>> > >>>--steve > >>> > >>>On Thu, Jan 3, 2013 at 1:16 AM, Anthony Molinaro < > >>>anthonym@REDACTED> wrote: > >>> > >>>>Attached is a test which shows the difference using only gen_tcp calls. > >>>> > >>>>Here's the output from both > >>>> > >>>>Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:2:2] [rq:2] > >>>>[async-threads:0] > >>>>[hipe] [kernel-poll:false] > >>>> > >>>>Eshell V5.8.5 (abort with ^G) > >>>>1> gen_tcp_test:test(1000). > >>>>gen_tcp:send ok > >>>>{{"HTTP/1.1",200,"OK"}, > >>>>[{"date","Wed, 02 Jan 2013 21:01:08 GMT"}, > >>>> {"server","Test"}, > >>>> {"content-length","31"}, > >>>> {"content-type","text/html"}], > >>>>"Hello"} > >>>>2> gen_tcp_test:test(10000). > >>>>http_error - R14 > >>>>gen_tcp:send ok > >>>>{{"HTTP/1.1",400,"Bad Request"}, > >>>>[{"date","Wed, 02 Jan 2013 21:03:24 GMT"}, > >>>> {"server","Test"}, > >>>> {"content-length","0"}], > >>>> []} > >>>>3> > >>>> > >>>>and for R15 > >>>> > >>>>Erlang R15B02 (erts-5.9.2) [source] [64-bit] [smp:2:2] [async-threads:0] > >>>>[hipe] > >>>>[kernel-poll:false] > >>>> > >>>>Eshell V5.9.2 (abort with ^G) > >>>>1> gen_tcp_test:test(1000). > >>>>gen_tcp:send ok > >>>>{{"HTTP/1.1",200,"OK"}, > >>>>[{"date","Wed, 02 Jan 2013 21:01:08 GMT"}, > >>>> {"server","Test"}, > >>>> {"content-length","31"}, > >>>> {"content-type","text/html"}], > >>>>"Hello"} > >>>>2> gen_tcp_test:test(10000). > >>>>emsgsize - R15 > >>>>gen_tcp:send failed with {error,closed} > >>>>socket_closed_remotely > >>>>3> > >>>> > >>>>Hope it helps, > >>>> > >>>>-Anthony > >>>> > >>>>On Wed, Jan 02, 2013 at 12:34:56PM -0500, Steve Vinoski wrote: > >>>>>Hi Anthony and Sverker, as I mentioned in a previous email, using > >>>>Anthony's > >>>>>test case a few weeks ago I bisected between R14B04 and HEAD and found > >>>>>commit dc5f7190 to be the first commit where the test case fails. > >>>>> > >>>>>--steve > >>>>> > >>>>>On Wed, Jan 2, 2013 at 12:28 PM, Anthony Molinaro < > >>>>>anthonym@REDACTED> wrote: > >>>>> > >>>>>>Hi, > >>>>>> > >>>>>> The holidays went and interrupted everything, so I'm sorry about the > >>>>>>late response. > >>>>>>It's unclear if the commit dc5f7190 did it or not, but sometime between > >>>>>>R14B04 and R15B02 the behavior did change. I've not isolated it > >>>>outside > >>>>>>of mochiweb, but I don't think its a mochiweb problem. > >>>>>> > >>>>>>Here's the pull request which contains the short program I used to > >>>>>>reproduce with mochiweb (and work around the new behavior) > >>>>>> > >>>>>>https://github.com/mochi/mochiweb/pull/91 > >>>>>> > >>>>>>I'll see if I can't isolate it to just OTP sometime in the next > >>>>>>couple of days. > >>>>>> > >>>>>>-Anthony > >>>>>> > >>>>>>On Mon, Dec 17, 2012 at 04:10:55PM +0100, Sverker Eriksson wrote: > >>>>>>>Have I understood it correctly so far if I say that my commit > >>>>>>>dc5f7190 seems to cause a > >>>>>>> > >>>>>>>{tcp_error,Port,emsgsize} > >>>>>>> > >>>>>>>while earlier versions caused a > >>>>>>> > >>>>>>>{http,Port,{http_error,"..."}} > >>>>>>> > >>>>>>> > >>>>>>>for the same scenario with some sort of very long http lines? > >>>>>>> > >>>>>>>/Sverker, Erlang/OTP > >>>>>>> > >>>>>>>Anthony Molinaro wrote: > >>>>>>>>On Fri, Dec 14, 2012 at 11:32:11AM -0500, Steve Vinoski wrote: > >>>>>>>>>Hi Anthony, based on your example, it looks like a follow-up commit > >>>>>>that > >>>>>>>>>modified some of the changes introduced by my patch introduced the > >>>>>>issue > >>>>>>>>>you're seeing: commit dc5f7190. You might want to report it over on > >>>>>>>>>erlang-bugs. > >>>>>>>>Nice catch, I guess that it's actually not enough to return error > >>>>>>>>for backward compatibility ;) > >>>>>>>> > >>>>>>>>I think the main thing I'm still not sure of is if the decode_packet > >>>>>>changes > >>>>>>>>are actually the cause. I was able to call decode_packet with long > >>>>>>headers > >>>>>>>>and not actually see an issue. > >>>>>>>> > >>>>>>>>This > >>>>>>>> > >>>>>>>>erlang:decode_packet ( httph, > >>>>>>>> list_to_binary ([ "X-Random: ", > >>>>>>>> [$a || _ <- > >>>>>>lists:seq(1,10000)], > >>>>>>>> "\r\n\r\n" > >>>>>>>> ]), > >>>>>>>> []). > >>>>>>>> > >>>>>>>>Returns the same thing in both R14B04 and R15B02. And as far as I > >>>>am > >>>>>>able > >>>>>>>>to tell that is the only call made to decode_packet in mochiweb. > >>>>>>>> > >>>>>>>>I think the actual error is around recvbuf sizing (mochiweb uses > >>>>8192 as > >>>>>>>>the default, so 10000 is definitely larger than that, however, the > >>>>>>standard > >>>>>>>>libraries must be doing something different as now it returns > >>>>emsgsize > >>>>>>>>where it did no in the past). I really wish there was a way to > >>>>search > >>>>>>>>commits on github as then I could search for recvbuf or something > >>>>like > >>>>>>>>that to see what might have changed. > >>>>>>>> > >>>>>>>>Before I go over to bugs I'll probably try to detangle mochiweb > >>>>enough > >>>>>>>>to create a small reproducible test case. > >>>>>>>> > >>>>>>>>I also have a pull request into mochiweb which prevents the crash > >>>>but > >>>>>>>>has the annoying behavior at the moment that it returns an error to > >>>>the > >>>>>>>>client about disconnecting version the 400 error it returned before. > >>>>>>>> > >>>>>>>>https://github.com/mochi/mochiweb/pull/91 > >>>>>>>> > >>>>>>>>But since the standard library seems to be the one closing the > >>>>socket > >>>>>>>>there's not much that can be done other than the fix I put in place. > >>>>>>>> > >>>>>>>>Thanks for your help Steve, > >>>>>>>> > >>>>>>>>-Anthony > >>>>>>>> > >>>>>>>_______________________________________________ > >>>>>>>erlang-questions mailing list > >>>>>>>erlang-questions@REDACTED > >>>>>>>http://erlang.org/mailman/listinfo/erlang-questions > >>>>>>-- > >>>>>> > >>>>------------------------------------------------------------------------ > >>>>>>Anthony Molinaro < > >>>>anthonym@REDACTED> > >>>>>>_______________________________________________ > >>>>>>erlang-questions mailing list > >>>>>>erlang-questions@REDACTED > >>>>>>http://erlang.org/mailman/listinfo/erlang-questions > >>>>>> > >>>>-- > >>>>------------------------------------------------------------------------ > >>>>Anthony Molinaro > >>>> > > > -- ------------------------------------------------------------------------ Anthony Molinaro -------------- next part -------------- -module (gen_tcp_test). -export ([start/0, start_one/0, test/1]). start () -> application:start (inets), spawn (gen_tcp_test, start_one, []). start_one () -> {ok, LSock} = gen_tcp:listen (5678, [ binary, {reuseaddr,true}, {packet,0}, {active,false} ]), {ok, Sock} = gen_tcp:accept (LSock), ok = inet:setopts (Sock, [{packet, http}]), Resp = req (Sock), case gen_tcp:send (Sock, Resp) of ok -> io:format ("gen_tcp:send ok~n"); E -> io:format ("gen_tcp:send failed with ~p~n",[E]) end, close (Sock). close (Socket) -> gen_tcp:close (Socket), exit (normal). req (Socket) -> ok = inet:setopts (Socket, [{active, once}]), receive {_, _, {http_request, _, _, _}} -> ok = inet:setopts(Socket, [{packet, httph}]), headers (Socket) end. headers (Socket) -> ok = inet:setopts(Socket, [{active, once}]), receive {_, _, http_eoh} -> ok = inet:setopts(Socket, [{packet, raw}]), [<<"HTTP/1.1 ">>, ["200",[" ",79,75]], <<"\r\n">>, "Server",<<": ">>, "Test",<<"\r\n">>, "Date",<<": ">>,"Wed, 02 Jan 2013 21:01:08 GMT",<<"\r\n">>, "Content-Type",<<": ">>,"text/html",<<"\r\n">>, "Content-Length",<<": ">>,"31",<<"\r\n">>,<<"\r\n">>, "Hello"]; {_,_, {http_header, _, _, _, _}} -> headers (Socket); {_,_, {http_error, _}} -> io:format("http_error - R14~n"), invalid (Socket); {tcp_error, _, emsgsize} -> io:format("emsgsize - R15~n"), invalid (Socket) end. invalid (_Socket) -> [ <<"HTTP/1.1 ">>, [ "400",[" ",66,97,100,32,82,101,113,117,101,115,116]],<<"\r\n">>, "Server",<<": ">>, "Test",<<"\r\n">>, "Date",<<": ">>,"Wed, 02 Jan 2013 21:03:24 GMT",<<"\r\n">>, "Content-Length",<<": ">>,"0",<<"\r\n">>,<<"\r\n">> ]. test (Len) -> start (), case httpc:request (get, { "http://127.0.0.1:5678/", [{"X-Random", [$a || _ <- lists:seq(1,Len)]}] }, [], []) of {ok, Resp} -> Resp; {error, Err} -> Err end. From cloudzen@REDACTED Tue Jan 15 08:43:21 2013 From: cloudzen@REDACTED (skyman) Date: Tue, 15 Jan 2013 15:43:21 +0800 (CST) Subject: [erlang-questions] About timeout of gen_server:call cross nodes Message-ID: <180f1369.d12d.13c3d2997f4.Coremail.cloudzen@163.com> Hi all, I find sometimes gen_server:call cross nodes will return 'timeout' error after less than Timeout millisecodes. For example: gen_server:call({Name,Node}, 'GET_DATA', 5000). Sometimes it will return "timeout" error after less than 5 seconds, why? Is it relevant to erlang:monitor? Thanks in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Tue Jan 15 10:41:25 2013 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 15 Jan 2013 10:41:25 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: <50F464D6.9030700@ernovation.com> References: <50F313AE.8050303@ernovation.com> <50F464D6.9030700@ernovation.com> Message-ID: On Mon, Jan 14, 2013 at 9:04 PM, Erik Reitsma wrote: > On 01/14/2013 11:37 AM, Joe Armstrong wrote: > >> This is amazing - works like a charm - fantastic. >> >> I am glad it not only works on my own devices. :-) > > > Quick comment - >> >> It would be very nice to make the client and server in >> fac_example.zip run "out of the box" >> client.erl is a *must read* file. server.erl does not export main/0 and >> should be changed to >> spawn the server - otherwise you don't get control in the shell ... >> >> The server was intended to be run on some server, not on the Android > device. Only the client should run on the device. Of course, the server > could easily be adapted to run on the same device, or another device, as > well. > The example was mainly intended for people familiar with Erlang, who want > to try their Erlang skills on Android. A different example may be required > for Android programmers who do not yet know Erlang. > > > First thoughts/questions: >> >> - The download is rather large - I'm sure this could be made a *lot >> smaller >> > > Definitely. As I wrote, I put in as much as I could, mainly to show that > all those libraries could run on the device. I intend to make a minimal > installation too. The current download includes almost everything from OTP, > including things like epmd (which also works, but you will need to start > Erlang from a shell, probably with root permissions). I think I can > probably remove the corba applications, the megaco application, ASN.1 and > many others. I will see if I can make it possible to make your own > selection of OTP applications, and perhaps even allow other repositories > with non-OTP-applications. > > > - Need Erlang APIs to the camera, GPS, .... etc. >> > > For now the easiest way to do this is write wrappers around the SL4A APIs. > Have you looked at those and found them lacking? You can find all available > functions here: http://code.google.com/p/**android-scripting/wiki/** > ApiReferenceI have actually only tried a view of them myself. > All functionality from SL4A is available through the module android. I > have implemented this using a dirty trick: I have modified > error_handler.erl such that for an undefined function android:F(Args), the > function android:rpc([Args]) will be called. So I only implemented > android:rpc/1, which will be called for any other function android:F/N. > Dirty, but if there is a new function in SL4A, it will be supported > automagically. This is similar to the implementation for Python4Android. Golly - I read the code - you modified error_handler.erl !!!! So what happens is ... I call android:fooBar(Args) - fooBar is not defined in android.erl so it's caught in error_handler and then android:rpc(fooBar, [...]) is called and this ends up as a Json call to a socket - (aside) I'm not sure I'm totally happy with modifying the error_handler for this, what's wrong with calling android:rpc(Func, Args) in your code and not changing the error handler? (/aside) It appears that SL4A is interfaced via a socket carrying JSON encode terms - is that correct? I Googled a bit to see if I could find where the protocol is defined - but found nothing. Where, for example, is the handshake that you perform in android:init *specified* If I want to call an andoid function I need to create a JSON argument list from erlang - what are the calling conventions? This is all very interesting stuff - I'd really like some documentation though, how the heck did you figure out how the interface works? - did you have to sniff the socket? - is there an architectural description somewhere? Cheers /Joe > > > - The client.erl example shows I can make an application *without* >> eclipse >> it would be very nice top abstract the details of the layout() >> function >> so as not to see the XML :-) >> >> Yes. :-) SL4A does not provide an API to dynamically create gui > elements, so this is a limitation with the current approach. It would be > possible to write Erlang code that transforms something erlangy into the > required XML. I would have to look at how generic that could be made, > because I may be too lazy to specifically implement all possibilities for > the layout XML. I think it would be possible to make some simple > XML-generation from lists of tuples records. I will give it some thought. > > Regards, > *Erik. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mabrek@REDACTED Tue Jan 15 10:41:37 2013 From: mabrek@REDACTED (Anton Lebedevich) Date: Tue, 15 Jan 2013 13:41:37 +0400 Subject: [erlang-questions] compare and set semantics using ets? In-Reply-To: <50F42097.3010909@gmail.com> References: <50F3F55A.5080404@gmail.com> <1869BFB0-1B59-4455-AD66-90E7AF6E2216@erlang-solutions.com> <50F42097.3010909@gmail.com> Message-ID: <50F52451.4040902@gmail.com> On 01/14/2013 07:13 PM, Anton Lebedevich wrote: > On 01/14/2013 07:01 PM, Jesper Louis Andersen wrote: >> On Jan 14, 2013, at 1:08 PM, Anton Lebedevich wrote: >> >>> Is it possible to implement atomic compare-and-set semantics using ets? >> >> Only in a limited fashion. I guess we either need a specific CAS-instruction, or you have to look up how it is achieved in mnesia, which does to transactional updates. > > Good catch, I've completely forgot that mnesia already does it, will > take a look at its sources. Reading mnesia sources revealed that it uses transaction manager and locker processes to serialize modification operations. Mnesia transactions rely on making modifications sequential not on CAS-instructions. It turns out that CAS which is a workhorse of many non-Erlang concurrent libraries isn't available in Erlang without NIFs. Am I missing something? Regards, Anton Lebedevich. From yrashk@REDACTED Tue Jan 15 11:22:23 2013 From: yrashk@REDACTED (Yurii Rashkovskii) Date: Tue, 15 Jan 2013 02:22:23 -0800 (PST) Subject: [erlang-questions] suggestion: shorthand functions In-Reply-To: References: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> <20130111141854.GA31136@erix.ericsson.se> Message-ID: Mahesh, This is certainly a good point about bash/perl/python/whatever, but these become quite useless the moment you need to talk to some erlang node from your escript. Yurii. On Friday, January 11, 2013 7:11:26 AM UTC-8, Mahesh Paolini-Subramanya wrote: > > I love escripts but find myself intuitively avoiding them for a couple > reasons: > > - In most cases, bash is more portable and solves system level > problems more directly > > - I don't have the escript foo required to wrench my program it into a > single script file > > > Amen. > perl (bash, python, whatever) is optimally suited for orchestrating > between 'application space' and 'business space', as well as orchestration > across loosely coupled systems and activities. > Yes, you could force most of this into erlang-world, but to what point? > IMHO, we do live in a polyglot world, and we may as well take advantage of > it? > > Cheers > > p.s. Mind you, there is an entirely different argument to be made about > systems where you only have access to erlang (or Ada. or whatever :-) ) > > * > Mahesh Paolini-Subramanya > * > That Tall Bald Indian Guy... > Google+ | Blog > | Twitter | LinkedIn > > On Jan 11, 2013, at 9:55 AM, Garrett Smith > > wrote: > > On Fri, Jan 11, 2013 at 8:18 AM, Raimo Niskanen > > wrote: > > On Fri, Jan 11, 2013 at 10:12:40AM +0100, Ulf Wiger wrote: > > Since I've been writing a bunch of rebar.config.script code lately, > I've suffered the agony of trying to write concise and readable > code without having to do tons of copy-paste, weird unwrapping > funs etc. > > What I think would make this sort of thing easier, and also > escript programming in general, is if OTP could provide some > modules with concise naming and let-it-fail semantics. > > Just off the top of my head, I scribbled down a few functions that > I think would make *my* life easier. I pushed them to github to > get some discussion going. > > http://github.com/uwiger/shorthand > > The modules are: > > f.erl - shorthand functions for file.erl > fn.erl - ditto for filename.erl > e.erl - ditto for erl_eval.erl > > The least beneficial is perhaps filename:erl, but my fingers and > eyes ache from all the filename:join(filename:dirname(F), ?) > code. > > Otherwise, I think the biggest benefit is to stick to let-it-crash > programming, which I find is usually the default when I write > scripts. The original functions are always available if you want > to take a closer look at return values. > > (For the file:script() counterparts, I also always pass the name > of the script as a binding). > > Comments? > > > I think it is a nice idea that would improve scripting. > > But how to agree on module names and content is harder. There is a limited > number of 1 and 2 character module names, and once in OTP they are written > in stone. > > > Aye. I don't know how critical this use case is (scripting > simplification/improvements) to justify new modules in OTP space. And > I'm not sure there *is* a case that would be sufficiently ubiquitous. > > I've resigned myself to writing little project specific > functions/libraries like this to deal with project specific problems. > E.g. this stuff drives me nuts: > > {ok, X} = foo:x(), > {ok, Y} = foo:y(), > combine(X, Y) > ... > > So I'll write foo_x/0 and foo_y/0 with crash-on-error semantics to get > this: > > combine(foo_x(), foo_y()) > > But who knew that I needed those particular variants? And what about > changes? It's my project, so I don't mind little wrappers, especially > since functions clarify intent. > > E.g. when I see this: > > ProjectFile = filename:join(ProjectDir, ProjectName) > > I'll almost create a function like this: > > project_filename(Dir, Name) -> filename:join(Dir, Name). > > For f.erl I miss e.g is_dir from filelib, which would introduce the notion > of merging old module functionality. Using the name 'fl' for filelib > functions would just be hard to remember. > > Aliasing filename:basename to fn:base is a bit unintuitive since the > original Unix command is called 'basename' and for e.g file:list_dir > you have aliased it to f:ls (as for many other) to make them more Unix:ish. > I think it would be better to keep to unix command names where possible. > [Wild idea: f:'-d' for filelib:is_dir, or t:'-d', or f:test(d, Path).] > > > It seems one could make these arguments ad nauseam. To me it's just > easier (and preferable frankly) to roll my own as the need arises. > > An alternative approach might be to have a helper module named 'es' > containing all scripting aliases... > > > I love escripts but find myself intuitively avoiding them for a couple > reasons: > > - In most cases, bash is more portable and solves system level > problems more directly > > - I don't have the escript foo required to wrench my program it into a > single script file > > Setting bash aside (not Ulf's use case) the main barrier for me is in > the perceived complexity of getting a release-of-sorts into an > escript. If I could write up one of these wrapper libraries, or pull > it down from somewhere easily, I might use escript everywhere. It's > not hard to write the wrappers (you write them as you need them, it > takes literally less than a minute for each function) and they're > tailored to your requirements. > > It may be trivial to package up the required bytes into an escript > today. If it is, I've love to know! > > And I don't know how this fits into rebar specific scripting :) > > Garrett > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Tue Jan 15 11:52:03 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Tue, 15 Jan 2013 13:52:03 +0300 Subject: [erlang-questions] compare and set semantics using ets? In-Reply-To: <50F52451.4040902@gmail.com> References: <50F3F55A.5080404@gmail.com> <1869BFB0-1B59-4455-AD66-90E7AF6E2216@erlang-solutions.com> <50F42097.3010909@gmail.com> <50F52451.4040902@gmail.com> Message-ID: Why are you speaking about some CAS instructions, when you just need API in ets module: insert_or_replace On Tue, Jan 15, 2013 at 1:41 PM, Anton Lebedevich wrote: > On 01/14/2013 07:13 PM, Anton Lebedevich wrote: > > On 01/14/2013 07:01 PM, Jesper Louis Andersen wrote: > >> On Jan 14, 2013, at 1:08 PM, Anton Lebedevich wrote: > >> > >>> Is it possible to implement atomic compare-and-set semantics using ets? > >> > >> Only in a limited fashion. I guess we either need a specific > CAS-instruction, or you have to look up how it is achieved in mnesia, which > does to transactional updates. > > > > Good catch, I've completely forgot that mnesia already does it, will > > take a look at its sources. > > Reading mnesia sources revealed that it uses transaction manager and > locker processes to serialize modification operations. > Mnesia transactions rely on making modifications sequential not on > CAS-instructions. > > It turns out that CAS which is a workhorse of many non-Erlang concurrent > libraries isn't available in Erlang without NIFs. Am I missing something? > > Regards, > Anton Lebedevich. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cao.xu@REDACTED Tue Jan 15 13:07:33 2013 From: cao.xu@REDACTED (cao xu) Date: Tue, 15 Jan 2013 20:07:33 +0800 Subject: [erlang-questions] What does 'Taints' mean in crash dump file Message-ID: Hi I did't find any information about the 'Taints' from the user guide of crash dump. Could anyone explain the meaning please? Thanks. From erlang@REDACTED Tue Jan 15 13:33:39 2013 From: erlang@REDACTED (Erik Reitsma) Date: Tue, 15 Jan 2013 13:33:39 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: References: <50F313AE.8050303@ernovation.com> <50F464D6.9030700@ernovation.com> Message-ID: <50F54CA3.8030302@ernovation.com> An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Tue Jan 15 13:41:16 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Tue, 15 Jan 2013 07:41:16 -0500 Subject: [erlang-questions] What does 'Taints' mean in crash dump file In-Reply-To: References: Message-ID: <20130115124115.GA81957@ferdmbp.local> I don't know what the original intent of 'taints' were, but if memory serves me right, they're only used to annotate what NIFs were loaded in your code at this point in time. I'm not sure if the meaning is ever gonna change, but in current versions they will only let you know about NIFs. By the way, when I struggled with a few crashdump files a couple of months ago, I ended up writing https://github.com/ferd/erl_crashdump_analyzer/blob/master/erl_crashdump_analyzer.sh as a quick way to help me find a diagnostic on a server where there was no GUI or where running the server for the OTP crashdump analyzer wasn't an option. Maybe it can help. Regards, Fred. On 01/15, cao xu wrote: > Hi > > I did't find any information about the 'Taints' from the user guide of crash dump. Could anyone explain the meaning please? > Thanks. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From erlang@REDACTED Tue Jan 15 13:44:10 2013 From: erlang@REDACTED (Erik Reitsma) Date: Tue, 15 Jan 2013 13:44:10 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: References: <50F313AE.8050303@ernovation.com> <50F464D6.9030700@ernovation.com> Message-ID: <50F54F1A.4060103@ernovation.com> An HTML attachment was scrubbed... URL: From sverker.eriksson@REDACTED Tue Jan 15 14:39:01 2013 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Tue, 15 Jan 2013 14:39:01 +0100 Subject: [erlang-questions] What does 'Taints' mean in crash dump file In-Reply-To: <20130115124115.GA81957@ferdmbp.local> References: <20130115124115.GA81957@ferdmbp.local> Message-ID: <50F55BF5.5050207@erix.ericsson.se> The idea was a way to see all user libraries that has ever been loaded and executed by the VM. Currently it only shows NIF libraries, but driver names will hopefully be added as well in some future release. /Sverker, Erlang/OTP Ericsson Fred Hebert wrote: > I don't know what the original intent of 'taints' were, but if memory > serves me right, they're only used to annotate what NIFs were loaded > in your code at this point in time. > > I'm not sure if the meaning is ever gonna change, but in current > versions they will only let you know about NIFs. > > By the way, when I struggled with a few crashdump files a couple of > months ago, I ended up writing > https://github.com/ferd/erl_crashdump_analyzer/blob/master/erl_crashdump_analyzer.sh > as a quick way to help me find a diagnostic on a server where there was > no GUI or where running the server for the OTP crashdump analyzer wasn't > an option. Maybe it can help. > > Regards, > Fred. > > On 01/15, cao xu wrote: > >> Hi >> >> I did't find any information about the 'Taints' from the user guide of crash dump. Could anyone explain the meaning please? >> 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 mahesh@REDACTED Tue Jan 15 14:46:27 2013 From: mahesh@REDACTED (Mahesh Paolini-Subramanya) Date: Tue, 15 Jan 2013 08:46:27 -0500 Subject: [erlang-questions] suggestion: shorthand functions In-Reply-To: References: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> <20130111141854.GA31136@erix.ericsson.se> Message-ID: Ah, you misunderstand. I'm not running around saying Perl Now! Perl Forever! Instead, what we do is separate the problem domains (to the extent possible, of course). There is some set of functionality in the erlang application that needs to be exposed to our business processes - think "add a user", "disable a client", "add billing credits", etc. These are encapsulated and exposed via escript, and then embedded in perl via 'system' / 'qx' / backquotes / whatever. The same applies for activities like "rebalance node", "move user to debug node", etc. :-) cheers Mahesh Paolini-Subramanya That Tall Bald Indian Guy... Google+ | Blog | Twitter | LinkedIn On Jan 15, 2013, at 5:22 AM, Yurii Rashkovskii wrote: > Mahesh, > > This is certainly a good point about bash/perl/python/whatever, but these become quite useless the moment you need to talk to some erlang node from your escript. > > Yurii. > > On Friday, January 11, 2013 7:11:26 AM UTC-8, Mahesh Paolini-Subramanya wrote: >> I love escripts but find myself intuitively avoiding them for a couple reasons: >> >> - In most cases, bash is more portable and solves system level >> problems more directly >> >> - I don't have the escript foo required to wrench my program it into a >> single script file > > Amen. > perl (bash, python, whatever) is optimally suited for orchestrating between 'application space' and 'business space', as well as orchestration across loosely coupled systems and activities. > Yes, you could force most of this into erlang-world, but to what point? IMHO, we do live in a polyglot world, and we may as well take advantage of it? > > Cheers > > p.s. Mind you, there is an entirely different argument to be made about systems where you only have access to erlang (or Ada. or whatever :-) ) > > Mahesh Paolini-Subramanya > That Tall Bald Indian Guy... > Google+ | Blog | Twitter | LinkedIn > > On Jan 11, 2013, at 9:55 AM, Garrett Smith wrote: > >> On Fri, Jan 11, 2013 at 8:18 AM, Raimo Niskanen >> wrote: >>> On Fri, Jan 11, 2013 at 10:12:40AM +0100, Ulf Wiger wrote: >>>> Since I've been writing a bunch of rebar.config.script code lately, >>>> I've suffered the agony of trying to write concise and readable >>>> code without having to do tons of copy-paste, weird unwrapping >>>> funs etc. >>>> >>>> What I think would make this sort of thing easier, and also >>>> escript programming in general, is if OTP could provide some >>>> modules with concise naming and let-it-fail semantics. >>>> >>>> Just off the top of my head, I scribbled down a few functions that >>>> I think would make *my* life easier. I pushed them to github to >>>> get some discussion going. >>>> >>>> http://github.com/uwiger/shorthand >>>> >>>> The modules are: >>>> >>>> f.erl - shorthand functions for file.erl >>>> fn.erl - ditto for filename.erl >>>> e.erl - ditto for erl_eval.erl >>>> >>>> The least beneficial is perhaps filename:erl, but my fingers and >>>> eyes ache from all the filename:join(filename:dirname(F), ?) >>>> code. >>>> >>>> Otherwise, I think the biggest benefit is to stick to let-it-crash >>>> programming, which I find is usually the default when I write >>>> scripts. The original functions are always available if you want >>>> to take a closer look at return values. >>>> >>>> (For the file:script() counterparts, I also always pass the name >>>> of the script as a binding). >>>> >>>> Comments? >>> >>> I think it is a nice idea that would improve scripting. >>> >>> But how to agree on module names and content is harder. There is a limited >>> number of 1 and 2 character module names, and once in OTP they are written >>> in stone. >> >> Aye. I don't know how critical this use case is (scripting >> simplification/improvements) to justify new modules in OTP space. And >> I'm not sure there *is* a case that would be sufficiently ubiquitous. >> >> I've resigned myself to writing little project specific >> functions/libraries like this to deal with project specific problems. >> E.g. this stuff drives me nuts: >> >> {ok, X} = foo:x(), >> {ok, Y} = foo:y(), >> combine(X, Y) >> ... >> >> So I'll write foo_x/0 and foo_y/0 with crash-on-error semantics to get this: >> >> combine(foo_x(), foo_y()) >> >> But who knew that I needed those particular variants? And what about >> changes? It's my project, so I don't mind little wrappers, especially >> since functions clarify intent. >> >> E.g. when I see this: >> >> ProjectFile = filename:join(ProjectDir, ProjectName) >> >> I'll almost create a function like this: >> >> project_filename(Dir, Name) -> filename:join(Dir, Name). >> >>> For f.erl I miss e.g is_dir from filelib, which would introduce the notion >>> of merging old module functionality. Using the name 'fl' for filelib >>> functions would just be hard to remember. >>> >>> Aliasing filename:basename to fn:base is a bit unintuitive since the >>> original Unix command is called 'basename' and for e.g file:list_dir >>> you have aliased it to f:ls (as for many other) to make them more Unix:ish. >>> I think it would be better to keep to unix command names where possible. >>> [Wild idea: f:'-d' for filelib:is_dir, or t:'-d', or f:test(d, Path).] >> >> It seems one could make these arguments ad nauseam. To me it's just >> easier (and preferable frankly) to roll my own as the need arises. >> >>> An alternative approach might be to have a helper module named 'es' >>> containing all scripting aliases... >> >> I love escripts but find myself intuitively avoiding them for a couple reasons: >> >> - In most cases, bash is more portable and solves system level >> problems more directly >> >> - I don't have the escript foo required to wrench my program it into a >> single script file >> >> Setting bash aside (not Ulf's use case) the main barrier for me is in >> the perceived complexity of getting a release-of-sorts into an >> escript. If I could write up one of these wrapper libraries, or pull >> it down from somewhere easily, I might use escript everywhere. It's >> not hard to write the wrappers (you write them as you need them, it >> takes literally less than a minute for each function) and they're >> tailored to your requirements. >> >> It may be trivial to package up the required bytes into an escript >> today. If it is, I've love to know! >> >> And I don't know how this fits into rebar specific scripting :) >> >> Garrett >> _______________________________________________ >> erlang-questions mailing list >> erlang-q...@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g@REDACTED Tue Jan 15 15:05:13 2013 From: g@REDACTED (Garrett Smith) Date: Tue, 15 Jan 2013 08:05:13 -0600 Subject: [erlang-questions] Erlang Moscow meetup: my speach about protecting system from overload In-Reply-To: References: <20130114134954.GA1503@ferdmbp.local> Message-ID: Hi Max, On Mon, Jan 14, 2013 at 9:46 PM, Max Lapshin wrote: > Some small additions about handling issue of long startup procedure > http://blog.erlyvideo.org/2013/01/14/long-coldstart/ Great post! I found it interesting that in your break-down of the problem you were free to think in terms of autonomic activities -- process orientation. Some of your language: - building of initial data - serving already indexed data - wait for its status - accept all incoming requests Of course you can do this in other languages, but the impedance is often *much* higher, leaving this sort of approach to the gifted or very determined. In Erlang it's just what you do! Garrett From g@REDACTED Tue Jan 15 15:24:44 2013 From: g@REDACTED (Garrett Smith) Date: Tue, 15 Jan 2013 08:24:44 -0600 Subject: [erlang-questions] suggestion: shorthand functions In-Reply-To: References: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> <20130111141854.GA31136@erix.ericsson.se> Message-ID: Hi Mahesh, Sounds like Yuri's driver is distributed Erlang. There are a bunch of apps out there that implement their command line interfaces (CLI) as distributed Erlang nodes that spin up, interact with another local node, then shut down. RabbitMQ does this. I *hate* it! (anger issues) - It's slow -- slower than *Java* for CLI operations - It's brittle -- distributed Erlang can fail for a number of reasons that are hard to diagnose - It introduces a third OS process -- epmd, a little single-point-of-failure devil that is the devil I personally advocate run_erl, which exposes a shell to to_erl over pipes. It's trivial to send commands to an Erlang process from bash or Python or anything you like. Some have criticized this approach as also being brittle. All I can say is that I've used this for years across thousands of servers and I'm very happy with it. That said, I often spend my Sunday mornings over coffee wondering how OS signal support isn't supported in Erlang. Garrett On Tue, Jan 15, 2013 at 7:46 AM, Mahesh Paolini-Subramanya wrote: > Ah, you misunderstand. > I'm not running around saying Perl Now! Perl Forever! > Instead, what we do is separate the problem domains (to the extent possible, > of course). > There is some set of functionality in the erlang application that needs to > be exposed to our business processes - think "add a user", "disable a > client", "add billing credits", etc. > These are encapsulated and exposed via escript, and then embedded in perl > via 'system' / 'qx' / backquotes / whatever. > The same applies for activities like "rebalance node", "move user to debug > node", etc. :-) > > cheers > Mahesh Paolini-Subramanya > That Tall Bald Indian Guy... > Google+ | Blog | Twitter | LinkedIn > > On Jan 15, 2013, at 5:22 AM, Yurii Rashkovskii wrote: > > Mahesh, > > This is certainly a good point about bash/perl/python/whatever, but these > become quite useless the moment you need to talk to some erlang node from > your escript. > > Yurii. > > On Friday, January 11, 2013 7:11:26 AM UTC-8, Mahesh Paolini-Subramanya > wrote: >> >> I love escripts but find myself intuitively avoiding them for a couple >> reasons: >> >> - In most cases, bash is more portable and solves system level >> problems more directly >> >> - I don't have the escript foo required to wrench my program it into a >> single script file >> >> >> Amen. >> perl (bash, python, whatever) is optimally suited for orchestrating >> between 'application space' and 'business space', as well as orchestration >> across loosely coupled systems and activities. >> Yes, you could force most of this into erlang-world, but to what point? >> IMHO, we do live in a polyglot world, and we may as well take advantage of >> it? >> >> Cheers >> >> p.s. Mind you, there is an entirely different argument to be made about >> systems where you only have access to erlang (or Ada. or whatever :-) ) >> >> Mahesh Paolini-Subramanya >> That Tall Bald Indian Guy... >> Google+ | Blog | Twitter | LinkedIn >> >> On Jan 11, 2013, at 9:55 AM, Garrett Smith wrote: >> >> On Fri, Jan 11, 2013 at 8:18 AM, Raimo Niskanen >> wrote: >> >> On Fri, Jan 11, 2013 at 10:12:40AM +0100, Ulf Wiger wrote: >> >> Since I've been writing a bunch of rebar.config.script code lately, >> I've suffered the agony of trying to write concise and readable >> code without having to do tons of copy-paste, weird unwrapping >> funs etc. >> >> What I think would make this sort of thing easier, and also >> escript programming in general, is if OTP could provide some >> modules with concise naming and let-it-fail semantics. >> >> Just off the top of my head, I scribbled down a few functions that >> I think would make *my* life easier. I pushed them to github to >> get some discussion going. >> >> http://github.com/uwiger/shorthand >> >> The modules are: >> >> f.erl - shorthand functions for file.erl >> fn.erl - ditto for filename.erl >> e.erl - ditto for erl_eval.erl >> >> The least beneficial is perhaps filename:erl, but my fingers and >> eyes ache from all the filename:join(filename:dirname(F), ?) >> code. >> >> Otherwise, I think the biggest benefit is to stick to let-it-crash >> programming, which I find is usually the default when I write >> scripts. The original functions are always available if you want >> to take a closer look at return values. >> >> (For the file:script() counterparts, I also always pass the name >> of the script as a binding). >> >> Comments? >> >> >> I think it is a nice idea that would improve scripting. >> >> But how to agree on module names and content is harder. There is a limited >> number of 1 and 2 character module names, and once in OTP they are written >> in stone. >> >> >> Aye. I don't know how critical this use case is (scripting >> simplification/improvements) to justify new modules in OTP space. And >> I'm not sure there *is* a case that would be sufficiently ubiquitous. >> >> I've resigned myself to writing little project specific >> functions/libraries like this to deal with project specific problems. >> E.g. this stuff drives me nuts: >> >> {ok, X} = foo:x(), >> {ok, Y} = foo:y(), >> combine(X, Y) >> ... >> >> So I'll write foo_x/0 and foo_y/0 with crash-on-error semantics to get >> this: >> >> combine(foo_x(), foo_y()) >> >> But who knew that I needed those particular variants? And what about >> changes? It's my project, so I don't mind little wrappers, especially >> since functions clarify intent. >> >> E.g. when I see this: >> >> ProjectFile = filename:join(ProjectDir, ProjectName) >> >> I'll almost create a function like this: >> >> project_filename(Dir, Name) -> filename:join(Dir, Name). >> >> For f.erl I miss e.g is_dir from filelib, which would introduce the notion >> of merging old module functionality. Using the name 'fl' for filelib >> functions would just be hard to remember. >> >> Aliasing filename:basename to fn:base is a bit unintuitive since the >> original Unix command is called 'basename' and for e.g file:list_dir >> you have aliased it to f:ls (as for many other) to make them more >> Unix:ish. >> I think it would be better to keep to unix command names where possible. >> [Wild idea: f:'-d' for filelib:is_dir, or t:'-d', or f:test(d, Path).] >> >> >> It seems one could make these arguments ad nauseam. To me it's just >> easier (and preferable frankly) to roll my own as the need arises. >> >> An alternative approach might be to have a helper module named 'es' >> containing all scripting aliases... >> >> >> I love escripts but find myself intuitively avoiding them for a couple >> reasons: >> >> - In most cases, bash is more portable and solves system level >> problems more directly >> >> - I don't have the escript foo required to wrench my program it into a >> single script file >> >> Setting bash aside (not Ulf's use case) the main barrier for me is in >> the perceived complexity of getting a release-of-sorts into an >> escript. If I could write up one of these wrapper libraries, or pull >> it down from somewhere easily, I might use escript everywhere. It's >> not hard to write the wrappers (you write them as you need them, it >> takes literally less than a minute for each function) and they're >> tailored to your requirements. >> >> It may be trivial to package up the required bytes into an escript >> today. If it is, I've love to know! >> >> And I don't know how this fits into rebar specific scripting :) >> >> Garrett >> _______________________________________________ >> erlang-questions mailing list >> erlang-q...@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > From a.shneyderman@REDACTED Tue Jan 15 15:39:00 2013 From: a.shneyderman@REDACTED (Alex Shneyderman) Date: Tue, 15 Jan 2013 09:39:00 -0500 Subject: [erlang-questions] SSL connection is closed unexpectedly Message-ID: Hello, everybody! I had a need to STARTTLS-enable tsung's jabber client. I use ssl engine that comes with R15B02. Basically, code takes an existing socket (tsung client - FSM owns that socket) and does an upgrade to TLS at an appropriate moment in time. Like so: {ok,SslSocket} = ssl:connect(Socket, [{verify, verify_none},{reuse_sessions,false}]), ssl:controlling_process(SslSocket,ClientFSMPid), ssl:setopts(SslSocket,[{active, once}]), If I spawn some number of clients (the number varies but anything beyond 200 seems to cause the problem) - connections get dropped and I believe it is the client side that drops the connections (since this behavior is not observed without TLS in the picture). So the questions: 1. Is this a known default behavior? If so how do I make it go away, i.e. some of the tests we are running need 2000 clients and plain (non-tls). 2. Is there a simple way to debug these disconnects. In the logs all I am getting is {tcp_closed, #Port<0.1608>}. Message does not have hints as to why this socket was closed. Anything I can do to figure out exactly why this happens? Cheers, Alex. From mahesh@REDACTED Tue Jan 15 16:40:01 2013 From: mahesh@REDACTED (Mahesh Paolini-Subramanya) Date: Tue, 15 Jan 2013 10:40:01 -0500 Subject: [erlang-questions] suggestion: shorthand functions In-Reply-To: References: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> <20130111141854.GA31136@erix.ericsson.se> Message-ID: <24E953AA-550F-4A99-998C-8362777769DF@dieswaytoofast.com> Garrett: This gets perilously close to a "how and where one should be doing distributed erlang in the first place" discussion, which is an entire other can of worms :-) I quite agree re: spinning up nodes - adding yet another moving part to what is already perilously close to being a hairball makes my eye twitch? (mind you, I suspect this might be different in simpler scenarios, but I'd rather not go down that road in the first place?) Cheers p.s. The last time I mentioned OS signal support on a Sunday morning, Nicole almost brained me w/ her coffee mug... Mahesh Paolini-Subramanya That Tall Bald Indian Guy... Google+ | Blog | Twitter | LinkedIn On Jan 15, 2013, at 9:24 AM, Garrett Smith wrote: > Hi Mahesh, > > Sounds like Yuri's driver is distributed Erlang. > > There are a bunch of apps out there that implement their command line > interfaces (CLI) as distributed Erlang nodes that spin up, interact > with another local node, then shut down. RabbitMQ does this. > > I *hate* it! (anger issues) > > - It's slow -- slower than *Java* for CLI operations > > - It's brittle -- distributed Erlang can fail for a number of reasons > that are hard to diagnose > > - It introduces a third OS process -- epmd, a little > single-point-of-failure devil that is the devil > > I personally advocate run_erl, which exposes a shell to to_erl over > pipes. It's trivial to send commands to an Erlang process from bash or > Python or anything you like. > > Some have criticized this approach as also being brittle. All I can > say is that I've used this for years across thousands of servers and > I'm very happy with it. > > That said, I often spend my Sunday mornings over coffee wondering how > OS signal support isn't supported in Erlang. > > Garrett > > On Tue, Jan 15, 2013 at 7:46 AM, Mahesh Paolini-Subramanya > wrote: >> Ah, you misunderstand. >> I'm not running around saying Perl Now! Perl Forever! >> Instead, what we do is separate the problem domains (to the extent possible, >> of course). >> There is some set of functionality in the erlang application that needs to >> be exposed to our business processes - think "add a user", "disable a >> client", "add billing credits", etc. >> These are encapsulated and exposed via escript, and then embedded in perl >> via 'system' / 'qx' / backquotes / whatever. >> The same applies for activities like "rebalance node", "move user to debug >> node", etc. :-) >> >> cheers >> Mahesh Paolini-Subramanya >> That Tall Bald Indian Guy... >> Google+ | Blog | Twitter | LinkedIn >> >> On Jan 15, 2013, at 5:22 AM, Yurii Rashkovskii wrote: >> >> Mahesh, >> >> This is certainly a good point about bash/perl/python/whatever, but these >> become quite useless the moment you need to talk to some erlang node from >> your escript. >> >> Yurii. >> >> On Friday, January 11, 2013 7:11:26 AM UTC-8, Mahesh Paolini-Subramanya >> wrote: >>> >>> I love escripts but find myself intuitively avoiding them for a couple >>> reasons: >>> >>> - In most cases, bash is more portable and solves system level >>> problems more directly >>> >>> - I don't have the escript foo required to wrench my program it into a >>> single script file >>> >>> >>> Amen. >>> perl (bash, python, whatever) is optimally suited for orchestrating >>> between 'application space' and 'business space', as well as orchestration >>> across loosely coupled systems and activities. >>> Yes, you could force most of this into erlang-world, but to what point? >>> IMHO, we do live in a polyglot world, and we may as well take advantage of >>> it? >>> >>> Cheers >>> >>> p.s. Mind you, there is an entirely different argument to be made about >>> systems where you only have access to erlang (or Ada. or whatever :-) ) >>> >>> Mahesh Paolini-Subramanya >>> That Tall Bald Indian Guy... >>> Google+ | Blog | Twitter | LinkedIn >>> >>> On Jan 11, 2013, at 9:55 AM, Garrett Smith wrote: >>> >>> On Fri, Jan 11, 2013 at 8:18 AM, Raimo Niskanen >>> wrote: >>> >>> On Fri, Jan 11, 2013 at 10:12:40AM +0100, Ulf Wiger wrote: >>> >>> Since I've been writing a bunch of rebar.config.script code lately, >>> I've suffered the agony of trying to write concise and readable >>> code without having to do tons of copy-paste, weird unwrapping >>> funs etc. >>> >>> What I think would make this sort of thing easier, and also >>> escript programming in general, is if OTP could provide some >>> modules with concise naming and let-it-fail semantics. >>> >>> Just off the top of my head, I scribbled down a few functions that >>> I think would make *my* life easier. I pushed them to github to >>> get some discussion going. >>> >>> http://github.com/uwiger/shorthand >>> >>> The modules are: >>> >>> f.erl - shorthand functions for file.erl >>> fn.erl - ditto for filename.erl >>> e.erl - ditto for erl_eval.erl >>> >>> The least beneficial is perhaps filename:erl, but my fingers and >>> eyes ache from all the filename:join(filename:dirname(F), ?) >>> code. >>> >>> Otherwise, I think the biggest benefit is to stick to let-it-crash >>> programming, which I find is usually the default when I write >>> scripts. The original functions are always available if you want >>> to take a closer look at return values. >>> >>> (For the file:script() counterparts, I also always pass the name >>> of the script as a binding). >>> >>> Comments? >>> >>> >>> I think it is a nice idea that would improve scripting. >>> >>> But how to agree on module names and content is harder. There is a limited >>> number of 1 and 2 character module names, and once in OTP they are written >>> in stone. >>> >>> >>> Aye. I don't know how critical this use case is (scripting >>> simplification/improvements) to justify new modules in OTP space. And >>> I'm not sure there *is* a case that would be sufficiently ubiquitous. >>> >>> I've resigned myself to writing little project specific >>> functions/libraries like this to deal with project specific problems. >>> E.g. this stuff drives me nuts: >>> >>> {ok, X} = foo:x(), >>> {ok, Y} = foo:y(), >>> combine(X, Y) >>> ... >>> >>> So I'll write foo_x/0 and foo_y/0 with crash-on-error semantics to get >>> this: >>> >>> combine(foo_x(), foo_y()) >>> >>> But who knew that I needed those particular variants? And what about >>> changes? It's my project, so I don't mind little wrappers, especially >>> since functions clarify intent. >>> >>> E.g. when I see this: >>> >>> ProjectFile = filename:join(ProjectDir, ProjectName) >>> >>> I'll almost create a function like this: >>> >>> project_filename(Dir, Name) -> filename:join(Dir, Name). >>> >>> For f.erl I miss e.g is_dir from filelib, which would introduce the notion >>> of merging old module functionality. Using the name 'fl' for filelib >>> functions would just be hard to remember. >>> >>> Aliasing filename:basename to fn:base is a bit unintuitive since the >>> original Unix command is called 'basename' and for e.g file:list_dir >>> you have aliased it to f:ls (as for many other) to make them more >>> Unix:ish. >>> I think it would be better to keep to unix command names where possible. >>> [Wild idea: f:'-d' for filelib:is_dir, or t:'-d', or f:test(d, Path).] >>> >>> >>> It seems one could make these arguments ad nauseam. To me it's just >>> easier (and preferable frankly) to roll my own as the need arises. >>> >>> An alternative approach might be to have a helper module named 'es' >>> containing all scripting aliases... >>> >>> >>> I love escripts but find myself intuitively avoiding them for a couple >>> reasons: >>> >>> - In most cases, bash is more portable and solves system level >>> problems more directly >>> >>> - I don't have the escript foo required to wrench my program it into a >>> single script file >>> >>> Setting bash aside (not Ulf's use case) the main barrier for me is in >>> the perceived complexity of getting a release-of-sorts into an >>> escript. If I could write up one of these wrapper libraries, or pull >>> it down from somewhere easily, I might use escript everywhere. It's >>> not hard to write the wrappers (you write them as you need them, it >>> takes literally less than a minute for each function) and they're >>> tailored to your requirements. >>> >>> It may be trivial to package up the required bytes into an escript >>> today. If it is, I've love to know! >>> >>> And I don't know how this fits into rebar specific scripting :) >>> >>> Garrett >>> _______________________________________________ >>> 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 Tue Jan 15 16:43:07 2013 From: essen@REDACTED (=?windows-1252?Q?Lo=EFc_Hoguin?=) Date: Tue, 15 Jan 2013 16:43:07 +0100 Subject: [erlang-questions] suggestion: shorthand functions In-Reply-To: References: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> <20130111141854.GA31136@erix.ericsson.se> Message-ID: <50F5790B.5010301@ninenines.eu> Can you give an example of such a run_erl use? I have no idea how the tool works. On 01/15/2013 03:24 PM, Garrett Smith wrote: > Hi Mahesh, > > Sounds like Yuri's driver is distributed Erlang. > > There are a bunch of apps out there that implement their command line > interfaces (CLI) as distributed Erlang nodes that spin up, interact > with another local node, then shut down. RabbitMQ does this. > > I *hate* it! (anger issues) > > - It's slow -- slower than *Java* for CLI operations > > - It's brittle -- distributed Erlang can fail for a number of reasons > that are hard to diagnose > > - It introduces a third OS process -- epmd, a little > single-point-of-failure devil that is the devil > > I personally advocate run_erl, which exposes a shell to to_erl over > pipes. It's trivial to send commands to an Erlang process from bash or > Python or anything you like. > > Some have criticized this approach as also being brittle. All I can > say is that I've used this for years across thousands of servers and > I'm very happy with it. > > That said, I often spend my Sunday mornings over coffee wondering how > OS signal support isn't supported in Erlang. > > Garrett > > On Tue, Jan 15, 2013 at 7:46 AM, Mahesh Paolini-Subramanya > wrote: >> Ah, you misunderstand. >> I'm not running around saying Perl Now! Perl Forever! >> Instead, what we do is separate the problem domains (to the extent possible, >> of course). >> There is some set of functionality in the erlang application that needs to >> be exposed to our business processes - think "add a user", "disable a >> client", "add billing credits", etc. >> These are encapsulated and exposed via escript, and then embedded in perl >> via 'system' / 'qx' / backquotes / whatever. >> The same applies for activities like "rebalance node", "move user to debug >> node", etc. :-) >> >> cheers >> Mahesh Paolini-Subramanya >> That Tall Bald Indian Guy... >> Google+ | Blog | Twitter | LinkedIn >> >> On Jan 15, 2013, at 5:22 AM, Yurii Rashkovskii wrote: >> >> Mahesh, >> >> This is certainly a good point about bash/perl/python/whatever, but these >> become quite useless the moment you need to talk to some erlang node from >> your escript. >> >> Yurii. >> >> On Friday, January 11, 2013 7:11:26 AM UTC-8, Mahesh Paolini-Subramanya >> wrote: >>> >>> I love escripts but find myself intuitively avoiding them for a couple >>> reasons: >>> >>> - In most cases, bash is more portable and solves system level >>> problems more directly >>> >>> - I don't have the escript foo required to wrench my program it into a >>> single script file >>> >>> >>> Amen. >>> perl (bash, python, whatever) is optimally suited for orchestrating >>> between 'application space' and 'business space', as well as orchestration >>> across loosely coupled systems and activities. >>> Yes, you could force most of this into erlang-world, but to what point? >>> IMHO, we do live in a polyglot world, and we may as well take advantage of >>> it? >>> >>> Cheers >>> >>> p.s. Mind you, there is an entirely different argument to be made about >>> systems where you only have access to erlang (or Ada. or whatever :-) ) >>> >>> Mahesh Paolini-Subramanya >>> That Tall Bald Indian Guy... >>> Google+ | Blog | Twitter | LinkedIn >>> >>> On Jan 11, 2013, at 9:55 AM, Garrett Smith wrote: >>> >>> On Fri, Jan 11, 2013 at 8:18 AM, Raimo Niskanen >>> wrote: >>> >>> On Fri, Jan 11, 2013 at 10:12:40AM +0100, Ulf Wiger wrote: >>> >>> Since I've been writing a bunch of rebar.config.script code lately, >>> I've suffered the agony of trying to write concise and readable >>> code without having to do tons of copy-paste, weird unwrapping >>> funs etc. >>> >>> What I think would make this sort of thing easier, and also >>> escript programming in general, is if OTP could provide some >>> modules with concise naming and let-it-fail semantics. >>> >>> Just off the top of my head, I scribbled down a few functions that >>> I think would make *my* life easier. I pushed them to github to >>> get some discussion going. >>> >>> http://github.com/uwiger/shorthand >>> >>> The modules are: >>> >>> f.erl - shorthand functions for file.erl >>> fn.erl - ditto for filename.erl >>> e.erl - ditto for erl_eval.erl >>> >>> The least beneficial is perhaps filename:erl, but my fingers and >>> eyes ache from all the filename:join(filename:dirname(F), ?) >>> code. >>> >>> Otherwise, I think the biggest benefit is to stick to let-it-crash >>> programming, which I find is usually the default when I write >>> scripts. The original functions are always available if you want >>> to take a closer look at return values. >>> >>> (For the file:script() counterparts, I also always pass the name >>> of the script as a binding). >>> >>> Comments? >>> >>> >>> I think it is a nice idea that would improve scripting. >>> >>> But how to agree on module names and content is harder. There is a limited >>> number of 1 and 2 character module names, and once in OTP they are written >>> in stone. >>> >>> >>> Aye. I don't know how critical this use case is (scripting >>> simplification/improvements) to justify new modules in OTP space. And >>> I'm not sure there *is* a case that would be sufficiently ubiquitous. >>> >>> I've resigned myself to writing little project specific >>> functions/libraries like this to deal with project specific problems. >>> E.g. this stuff drives me nuts: >>> >>> {ok, X} = foo:x(), >>> {ok, Y} = foo:y(), >>> combine(X, Y) >>> ... >>> >>> So I'll write foo_x/0 and foo_y/0 with crash-on-error semantics to get >>> this: >>> >>> combine(foo_x(), foo_y()) >>> >>> But who knew that I needed those particular variants? And what about >>> changes? It's my project, so I don't mind little wrappers, especially >>> since functions clarify intent. >>> >>> E.g. when I see this: >>> >>> ProjectFile = filename:join(ProjectDir, ProjectName) >>> >>> I'll almost create a function like this: >>> >>> project_filename(Dir, Name) -> filename:join(Dir, Name). >>> >>> For f.erl I miss e.g is_dir from filelib, which would introduce the notion >>> of merging old module functionality. Using the name 'fl' for filelib >>> functions would just be hard to remember. >>> >>> Aliasing filename:basename to fn:base is a bit unintuitive since the >>> original Unix command is called 'basename' and for e.g file:list_dir >>> you have aliased it to f:ls (as for many other) to make them more >>> Unix:ish. >>> I think it would be better to keep to unix command names where possible. >>> [Wild idea: f:'-d' for filelib:is_dir, or t:'-d', or f:test(d, Path).] >>> >>> >>> It seems one could make these arguments ad nauseam. To me it's just >>> easier (and preferable frankly) to roll my own as the need arises. >>> >>> An alternative approach might be to have a helper module named 'es' >>> containing all scripting aliases... >>> >>> >>> I love escripts but find myself intuitively avoiding them for a couple >>> reasons: >>> >>> - In most cases, bash is more portable and solves system level >>> problems more directly >>> >>> - I don't have the escript foo required to wrench my program it into a >>> single script file >>> >>> Setting bash aside (not Ulf's use case) the main barrier for me is in >>> the perceived complexity of getting a release-of-sorts into an >>> escript. If I could write up one of these wrapper libraries, or pull >>> it down from somewhere easily, I might use escript everywhere. It's >>> not hard to write the wrappers (you write them as you need them, it >>> takes literally less than a minute for each function) and they're >>> tailored to your requirements. >>> >>> It may be trivial to package up the required bytes into an escript >>> today. If it is, I've love to know! >>> >>> And I don't know how this fits into rebar specific scripting :) >>> >>> Garrett >>> _______________________________________________ >>> 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 > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From bengt.kleberg@REDACTED Tue Jan 15 16:49:30 2013 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 15 Jan 2013 16:49:30 +0100 Subject: [erlang-questions] suggestion: shorthand functions In-Reply-To: <50F5790B.5010301@ninenines.eu> References: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> <20130111141854.GA31136@erix.ericsson.se> <50F5790B.5010301@ninenines.eu> Message-ID: <1358264970.4826.23.camel@sekic1152.rnd.ki.sw.ericsson.se> Greetings, Please start here: http://www.erlang.org/doc/man/run_erl.html bengt On Tue, 2013-01-15 at 16:43 +0100, Lo?c Hoguin wrote: > Can you give an example of such a run_erl use? I have no idea how the > tool works. > > On 01/15/2013 03:24 PM, Garrett Smith wrote: > > Hi Mahesh, > > > > Sounds like Yuri's driver is distributed Erlang. > > > > There are a bunch of apps out there that implement their command line > > interfaces (CLI) as distributed Erlang nodes that spin up, interact > > with another local node, then shut down. RabbitMQ does this. > > > > I *hate* it! (anger issues) > > > > - It's slow -- slower than *Java* for CLI operations > > > > - It's brittle -- distributed Erlang can fail for a number of reasons > > that are hard to diagnose > > > > - It introduces a third OS process -- epmd, a little > > single-point-of-failure devil that is the devil > > > > I personally advocate run_erl, which exposes a shell to to_erl over > > pipes. It's trivial to send commands to an Erlang process from bash or > > Python or anything you like. > > > > Some have criticized this approach as also being brittle. All I can > > say is that I've used this for years across thousands of servers and > > I'm very happy with it. > > > > That said, I often spend my Sunday mornings over coffee wondering how > > OS signal support isn't supported in Erlang. > > > > Garrett > > > > On Tue, Jan 15, 2013 at 7:46 AM, Mahesh Paolini-Subramanya > > wrote: > >> Ah, you misunderstand. > >> I'm not running around saying Perl Now! Perl Forever! > >> Instead, what we do is separate the problem domains (to the extent possible, > >> of course). > >> There is some set of functionality in the erlang application that needs to > >> be exposed to our business processes - think "add a user", "disable a > >> client", "add billing credits", etc. > >> These are encapsulated and exposed via escript, and then embedded in perl > >> via 'system' / 'qx' / backquotes / whatever. > >> The same applies for activities like "rebalance node", "move user to debug > >> node", etc. :-) > >> > >> cheers > >> Mahesh Paolini-Subramanya > >> That Tall Bald Indian Guy... > >> Google+ | Blog | Twitter | LinkedIn > >> > >> On Jan 15, 2013, at 5:22 AM, Yurii Rashkovskii wrote: > >> > >> Mahesh, > >> > >> This is certainly a good point about bash/perl/python/whatever, but these > >> become quite useless the moment you need to talk to some erlang node from > >> your escript. > >> > >> Yurii. > >> > >> On Friday, January 11, 2013 7:11:26 AM UTC-8, Mahesh Paolini-Subramanya > >> wrote: > >>> > >>> I love escripts but find myself intuitively avoiding them for a couple > >>> reasons: > >>> > >>> - In most cases, bash is more portable and solves system level > >>> problems more directly > >>> > >>> - I don't have the escript foo required to wrench my program it into a > >>> single script file > >>> > >>> > >>> Amen. > >>> perl (bash, python, whatever) is optimally suited for orchestrating > >>> between 'application space' and 'business space', as well as orchestration > >>> across loosely coupled systems and activities. > >>> Yes, you could force most of this into erlang-world, but to what point? > >>> IMHO, we do live in a polyglot world, and we may as well take advantage of > >>> it? > >>> > >>> Cheers > >>> > >>> p.s. Mind you, there is an entirely different argument to be made about > >>> systems where you only have access to erlang (or Ada. or whatever :-) ) > >>> > >>> Mahesh Paolini-Subramanya > >>> That Tall Bald Indian Guy... > >>> Google+ | Blog | Twitter | LinkedIn > >>> > >>> On Jan 11, 2013, at 9:55 AM, Garrett Smith wrote: > >>> > >>> On Fri, Jan 11, 2013 at 8:18 AM, Raimo Niskanen > >>> wrote: > >>> > >>> On Fri, Jan 11, 2013 at 10:12:40AM +0100, Ulf Wiger wrote: > >>> > >>> Since I've been writing a bunch of rebar.config.script code lately, > >>> I've suffered the agony of trying to write concise and readable > >>> code without having to do tons of copy-paste, weird unwrapping > >>> funs etc. > >>> > >>> What I think would make this sort of thing easier, and also > >>> escript programming in general, is if OTP could provide some > >>> modules with concise naming and let-it-fail semantics. > >>> > >>> Just off the top of my head, I scribbled down a few functions that > >>> I think would make *my* life easier. I pushed them to github to > >>> get some discussion going. > >>> > >>> http://github.com/uwiger/shorthand > >>> > >>> The modules are: > >>> > >>> f.erl - shorthand functions for file.erl > >>> fn.erl - ditto for filename.erl > >>> e.erl - ditto for erl_eval.erl > >>> > >>> The least beneficial is perhaps filename:erl, but my fingers and > >>> eyes ache from all the filename:join(filename:dirname(F), ?) > >>> code. > >>> > >>> Otherwise, I think the biggest benefit is to stick to let-it-crash > >>> programming, which I find is usually the default when I write > >>> scripts. The original functions are always available if you want > >>> to take a closer look at return values. > >>> > >>> (For the file:script() counterparts, I also always pass the name > >>> of the script as a binding). > >>> > >>> Comments? > >>> > >>> > >>> I think it is a nice idea that would improve scripting. > >>> > >>> But how to agree on module names and content is harder. There is a limited > >>> number of 1 and 2 character module names, and once in OTP they are written > >>> in stone. > >>> > >>> > >>> Aye. I don't know how critical this use case is (scripting > >>> simplification/improvements) to justify new modules in OTP space. And > >>> I'm not sure there *is* a case that would be sufficiently ubiquitous. > >>> > >>> I've resigned myself to writing little project specific > >>> functions/libraries like this to deal with project specific problems. > >>> E.g. this stuff drives me nuts: > >>> > >>> {ok, X} = foo:x(), > >>> {ok, Y} = foo:y(), > >>> combine(X, Y) > >>> ... > >>> > >>> So I'll write foo_x/0 and foo_y/0 with crash-on-error semantics to get > >>> this: > >>> > >>> combine(foo_x(), foo_y()) > >>> > >>> But who knew that I needed those particular variants? And what about > >>> changes? It's my project, so I don't mind little wrappers, especially > >>> since functions clarify intent. > >>> > >>> E.g. when I see this: > >>> > >>> ProjectFile = filename:join(ProjectDir, ProjectName) > >>> > >>> I'll almost create a function like this: > >>> > >>> project_filename(Dir, Name) -> filename:join(Dir, Name). > >>> > >>> For f.erl I miss e.g is_dir from filelib, which would introduce the notion > >>> of merging old module functionality. Using the name 'fl' for filelib > >>> functions would just be hard to remember. > >>> > >>> Aliasing filename:basename to fn:base is a bit unintuitive since the > >>> original Unix command is called 'basename' and for e.g file:list_dir > >>> you have aliased it to f:ls (as for many other) to make them more > >>> Unix:ish. > >>> I think it would be better to keep to unix command names where possible. > >>> [Wild idea: f:'-d' for filelib:is_dir, or t:'-d', or f:test(d, Path).] > >>> > >>> > >>> It seems one could make these arguments ad nauseam. To me it's just > >>> easier (and preferable frankly) to roll my own as the need arises. > >>> > >>> An alternative approach might be to have a helper module named 'es' > >>> containing all scripting aliases... > >>> > >>> > >>> I love escripts but find myself intuitively avoiding them for a couple > >>> reasons: > >>> > >>> - In most cases, bash is more portable and solves system level > >>> problems more directly > >>> > >>> - I don't have the escript foo required to wrench my program it into a > >>> single script file > >>> > >>> Setting bash aside (not Ulf's use case) the main barrier for me is in > >>> the perceived complexity of getting a release-of-sorts into an > >>> escript. If I could write up one of these wrapper libraries, or pull > >>> it down from somewhere easily, I might use escript everywhere. It's > >>> not hard to write the wrappers (you write them as you need them, it > >>> takes literally less than a minute for each function) and they're > >>> tailored to your requirements. > >>> > >>> It may be trivial to package up the required bytes into an escript > >>> today. If it is, I've love to know! > >>> > >>> And I don't know how this fits into rebar specific scripting :) > >>> > >>> Garrett > >>> _______________________________________________ > >>> 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 dmercer@REDACTED Tue Jan 15 16:54:49 2013 From: dmercer@REDACTED (David Mercer) Date: Tue, 15 Jan 2013 09:54:49 -0600 Subject: [erlang-questions] Erlang4Android In-Reply-To: References: <50F313AE.8050303@ernovation.com> <50F464D6.9030700@ernovation.com> Message-ID: <005901cdf338$a69d3090$f3d791b0$@gmail.com> Am I the only one whose email reader (Outlook 2010) does not distinguish well between who is saying what in this email message? Not just this one?others too?but often they are Joe?s. Anyone else using Outlook and had this problem and then tweaked some setting somewhere and the problem went away? Please advise. Thank-you. Cheers, DBM From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Joe Armstrong Sent: Tuesday, January 15, 2013 03:41 To: erlang@REDACTED Cc: Erlang-questions Subject: Re: [erlang-questions] Erlang4Android On Mon, Jan 14, 2013 at 9:04 PM, Erik Reitsma wrote: On 01/14/2013 11:37 AM, Joe Armstrong wrote: This is amazing - works like a charm - fantastic. I am glad it not only works on my own devices. :-) Quick comment - It would be very nice to make the client and server in fac_example.zip run "out of the box" client.erl is a *must read* file. server.erl does not export main/0 and should be changed to spawn the server - otherwise you don't get control in the shell ... The server was intended to be run on some server, not on the Android device. Only the client should run on the device. Of course, the server could easily be adapted to run on the same device, or another device, as well. The example was mainly intended for people familiar with Erlang, who want to try their Erlang skills on Android. A different example may be required for Android programmers who do not yet know Erlang. First thoughts/questions: - The download is rather large - I'm sure this could be made a *lot smaller Definitely. As I wrote, I put in as much as I could, mainly to show that all those libraries could run on the device. I intend to make a minimal installation too. The current download includes almost everything from OTP, including things like epmd (which also works, but you will need to start Erlang from a shell, probably with root permissions). I think I can probably remove the corba applications, the megaco application, ASN.1 and many others. I will see if I can make it possible to make your own selection of OTP applications, and perhaps even allow other repositories with non-OTP-applications. - Need Erlang APIs to the camera, GPS, .... etc. For now the easiest way to do this is write wrappers around the SL4A APIs. Have you looked at those and found them lacking? You can find all available functions here: http://code.google.com/p/android-scripting/wiki/ApiReference I have actually only tried a view of them myself. All functionality from SL4A is available through the module android. I have implemented this using a dirty trick: I have modified error_handler.erl such that for an undefined function android:F(Args), the function android:rpc([Args]) will be called. So I only implemented android:rpc/1, which will be called for any other function android:F/N. Dirty, but if there is a new function in SL4A, it will be supported automagically. This is similar to the implementation for Python4Android. Golly - I read the code - you modified error_handler.erl !!!! So what happens is ... I call android:fooBar(Args) - fooBar is not defined in android.erl so it's caught in error_handler and then android:rpc(fooBar, [...]) is called and this ends up as a Json call to a socket - (aside) I'm not sure I'm totally happy with modifying the error_handler for this, what's wrong with calling android:rpc(Func, Args) in your code and not changing the error handler? (/aside) It appears that SL4A is interfaced via a socket carrying JSON encode terms - is that correct? I Googled a bit to see if I could find where the protocol is defined - but found nothing. Where, for example, is the handshake that you perform in android:init *specified* If I want to call an andoid function I need to create a JSON argument list from erlang - what are the calling conventions? This is all very interesting stuff - I'd really like some documentation though, how the heck did you figure out how the interface works? - did you have to sniff the socket? - is there an architectural description somewhere? Cheers /Joe - The client.erl example shows I can make an application *without* eclipse it would be very nice top abstract the details of the layout() function so as not to see the XML :-) Yes. :-) SL4A does not provide an API to dynamically create gui elements, so this is a limitation with the current approach. It would be possible to write Erlang code that transforms something erlangy into the required XML. I would have to look at how generic that could be made, because I may be too lazy to specifically implement all possibilities for the layout XML. I think it would be possible to make some simple XML-generation from lists of tuples records. I will give it some thought. Regards, *Erik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Tue Jan 15 16:54:21 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 15 Jan 2013 16:54:21 +0100 Subject: [erlang-questions] suggestion: shorthand functions In-Reply-To: <1358264970.4826.23.camel@sekic1152.rnd.ki.sw.ericsson.se> References: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> <20130111141854.GA31136@erix.ericsson.se> <50F5790B.5010301@ninenines.eu> <1358264970.4826.23.camel@sekic1152.rnd.ki.sw.ericsson.se> Message-ID: <50F57BAD.5000208@ninenines.eu> No examples there. Also confusing, Solaris? Redirect Erlang input and output streams on Solaris? But mostly because the page you linked has nothing related to how Garrett uses it. On 01/15/2013 04:49 PM, Bengt Kleberg wrote: > Greetings, > > Please start here: > http://www.erlang.org/doc/man/run_erl.html > > > bengt > > On Tue, 2013-01-15 at 16:43 +0100, Lo?c Hoguin wrote: >> Can you give an example of such a run_erl use? I have no idea how the >> tool works. >> >> On 01/15/2013 03:24 PM, Garrett Smith wrote: >>> Hi Mahesh, >>> >>> Sounds like Yuri's driver is distributed Erlang. >>> >>> There are a bunch of apps out there that implement their command line >>> interfaces (CLI) as distributed Erlang nodes that spin up, interact >>> with another local node, then shut down. RabbitMQ does this. >>> >>> I *hate* it! (anger issues) >>> >>> - It's slow -- slower than *Java* for CLI operations >>> >>> - It's brittle -- distributed Erlang can fail for a number of reasons >>> that are hard to diagnose >>> >>> - It introduces a third OS process -- epmd, a little >>> single-point-of-failure devil that is the devil >>> >>> I personally advocate run_erl, which exposes a shell to to_erl over >>> pipes. It's trivial to send commands to an Erlang process from bash or >>> Python or anything you like. >>> >>> Some have criticized this approach as also being brittle. All I can >>> say is that I've used this for years across thousands of servers and >>> I'm very happy with it. >>> >>> That said, I often spend my Sunday mornings over coffee wondering how >>> OS signal support isn't supported in Erlang. >>> >>> Garrett >>> >>> On Tue, Jan 15, 2013 at 7:46 AM, Mahesh Paolini-Subramanya >>> wrote: >>>> Ah, you misunderstand. >>>> I'm not running around saying Perl Now! Perl Forever! >>>> Instead, what we do is separate the problem domains (to the extent possible, >>>> of course). >>>> There is some set of functionality in the erlang application that needs to >>>> be exposed to our business processes - think "add a user", "disable a >>>> client", "add billing credits", etc. >>>> These are encapsulated and exposed via escript, and then embedded in perl >>>> via 'system' / 'qx' / backquotes / whatever. >>>> The same applies for activities like "rebalance node", "move user to debug >>>> node", etc. :-) >>>> >>>> cheers >>>> Mahesh Paolini-Subramanya >>>> That Tall Bald Indian Guy... >>>> Google+ | Blog | Twitter | LinkedIn >>>> >>>> On Jan 15, 2013, at 5:22 AM, Yurii Rashkovskii wrote: >>>> >>>> Mahesh, >>>> >>>> This is certainly a good point about bash/perl/python/whatever, but these >>>> become quite useless the moment you need to talk to some erlang node from >>>> your escript. >>>> >>>> Yurii. >>>> >>>> On Friday, January 11, 2013 7:11:26 AM UTC-8, Mahesh Paolini-Subramanya >>>> wrote: >>>>> >>>>> I love escripts but find myself intuitively avoiding them for a couple >>>>> reasons: >>>>> >>>>> - In most cases, bash is more portable and solves system level >>>>> problems more directly >>>>> >>>>> - I don't have the escript foo required to wrench my program it into a >>>>> single script file >>>>> >>>>> >>>>> Amen. >>>>> perl (bash, python, whatever) is optimally suited for orchestrating >>>>> between 'application space' and 'business space', as well as orchestration >>>>> across loosely coupled systems and activities. >>>>> Yes, you could force most of this into erlang-world, but to what point? >>>>> IMHO, we do live in a polyglot world, and we may as well take advantage of >>>>> it? >>>>> >>>>> Cheers >>>>> >>>>> p.s. Mind you, there is an entirely different argument to be made about >>>>> systems where you only have access to erlang (or Ada. or whatever :-) ) >>>>> >>>>> Mahesh Paolini-Subramanya >>>>> That Tall Bald Indian Guy... >>>>> Google+ | Blog | Twitter | LinkedIn >>>>> >>>>> On Jan 11, 2013, at 9:55 AM, Garrett Smith wrote: >>>>> >>>>> On Fri, Jan 11, 2013 at 8:18 AM, Raimo Niskanen >>>>> wrote: >>>>> >>>>> On Fri, Jan 11, 2013 at 10:12:40AM +0100, Ulf Wiger wrote: >>>>> >>>>> Since I've been writing a bunch of rebar.config.script code lately, >>>>> I've suffered the agony of trying to write concise and readable >>>>> code without having to do tons of copy-paste, weird unwrapping >>>>> funs etc. >>>>> >>>>> What I think would make this sort of thing easier, and also >>>>> escript programming in general, is if OTP could provide some >>>>> modules with concise naming and let-it-fail semantics. >>>>> >>>>> Just off the top of my head, I scribbled down a few functions that >>>>> I think would make *my* life easier. I pushed them to github to >>>>> get some discussion going. >>>>> >>>>> http://github.com/uwiger/shorthand >>>>> >>>>> The modules are: >>>>> >>>>> f.erl - shorthand functions for file.erl >>>>> fn.erl - ditto for filename.erl >>>>> e.erl - ditto for erl_eval.erl >>>>> >>>>> The least beneficial is perhaps filename:erl, but my fingers and >>>>> eyes ache from all the filename:join(filename:dirname(F), ?) >>>>> code. >>>>> >>>>> Otherwise, I think the biggest benefit is to stick to let-it-crash >>>>> programming, which I find is usually the default when I write >>>>> scripts. The original functions are always available if you want >>>>> to take a closer look at return values. >>>>> >>>>> (For the file:script() counterparts, I also always pass the name >>>>> of the script as a binding). >>>>> >>>>> Comments? >>>>> >>>>> >>>>> I think it is a nice idea that would improve scripting. >>>>> >>>>> But how to agree on module names and content is harder. There is a limited >>>>> number of 1 and 2 character module names, and once in OTP they are written >>>>> in stone. >>>>> >>>>> >>>>> Aye. I don't know how critical this use case is (scripting >>>>> simplification/improvements) to justify new modules in OTP space. And >>>>> I'm not sure there *is* a case that would be sufficiently ubiquitous. >>>>> >>>>> I've resigned myself to writing little project specific >>>>> functions/libraries like this to deal with project specific problems. >>>>> E.g. this stuff drives me nuts: >>>>> >>>>> {ok, X} = foo:x(), >>>>> {ok, Y} = foo:y(), >>>>> combine(X, Y) >>>>> ... >>>>> >>>>> So I'll write foo_x/0 and foo_y/0 with crash-on-error semantics to get >>>>> this: >>>>> >>>>> combine(foo_x(), foo_y()) >>>>> >>>>> But who knew that I needed those particular variants? And what about >>>>> changes? It's my project, so I don't mind little wrappers, especially >>>>> since functions clarify intent. >>>>> >>>>> E.g. when I see this: >>>>> >>>>> ProjectFile = filename:join(ProjectDir, ProjectName) >>>>> >>>>> I'll almost create a function like this: >>>>> >>>>> project_filename(Dir, Name) -> filename:join(Dir, Name). >>>>> >>>>> For f.erl I miss e.g is_dir from filelib, which would introduce the notion >>>>> of merging old module functionality. Using the name 'fl' for filelib >>>>> functions would just be hard to remember. >>>>> >>>>> Aliasing filename:basename to fn:base is a bit unintuitive since the >>>>> original Unix command is called 'basename' and for e.g file:list_dir >>>>> you have aliased it to f:ls (as for many other) to make them more >>>>> Unix:ish. >>>>> I think it would be better to keep to unix command names where possible. >>>>> [Wild idea: f:'-d' for filelib:is_dir, or t:'-d', or f:test(d, Path).] >>>>> >>>>> >>>>> It seems one could make these arguments ad nauseam. To me it's just >>>>> easier (and preferable frankly) to roll my own as the need arises. >>>>> >>>>> An alternative approach might be to have a helper module named 'es' >>>>> containing all scripting aliases... >>>>> >>>>> >>>>> I love escripts but find myself intuitively avoiding them for a couple >>>>> reasons: >>>>> >>>>> - In most cases, bash is more portable and solves system level >>>>> problems more directly >>>>> >>>>> - I don't have the escript foo required to wrench my program it into a >>>>> single script file >>>>> >>>>> Setting bash aside (not Ulf's use case) the main barrier for me is in >>>>> the perceived complexity of getting a release-of-sorts into an >>>>> escript. If I could write up one of these wrapper libraries, or pull >>>>> it down from somewhere easily, I might use escript everywhere. It's >>>>> not hard to write the wrappers (you write them as you need them, it >>>>> takes literally less than a minute for each function) and they're >>>>> tailored to your requirements. >>>>> >>>>> It may be trivial to package up the required bytes into an escript >>>>> today. If it is, I've love to know! >>>>> >>>>> And I don't know how this fits into rebar specific scripting :) >>>>> >>>>> Garrett >>>>> _______________________________________________ >>>>> 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 >>> >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From bryan@REDACTED Tue Jan 15 17:58:58 2013 From: bryan@REDACTED (Bryan Hughes) Date: Tue, 15 Jan 2013 08:58:58 -0800 Subject: [erlang-questions] Interesting issue... Message-ID: <50F58AD2.6010400@go-factory.net> Hi Everyone, I already submitted this to erlang-bugs@REDACTED, but figured others might be interested. I found an interesting issue while traveling and working through Thailand. I have been able to reproduce it on my MacBook Pro using R15B01, built from source. 1. Set your date to Indochina Time. 2. In the shell, try executing: calendar:local_time_to_universal_time_dst({{2012,12,3},{8,48,42}}). Here is the exception that I am getting. Note that the date is a validate datetime. Eshell V5.9.1 (abort with ^G) 1> calendar:local_time_to_universal_time_dst({{2012,12,3},{8,48,42}}). ** exception error: bad argument in function erlang:localtime_to_universaltime/2 called as erlang:localtime_to_universaltime({{2012,12,3},{8,48,42}},true) in call from calendar:local_time_to_universal_time_dst/1 (calendar.erl, line 282) When I set my date back to Pacific time, it works without any problem -- you can switch it back and forth while in the shell and either get the exception, or the correct output. I was able to isolate it to function the bif.c function, unfortunately my environment is not really set up to debug the erlang runtime. BIF_RETTYPE localtime_to_universaltime_2(BIF_ALIST_2); Cheers, Bryan -- Bryan Hughes CTO and Founder / *Go Factory* http://www.go-factory.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From anotherworldofworld@REDACTED Tue Jan 15 18:29:06 2013 From: anotherworldofworld@REDACTED (Alexander 0xAX) Date: Tue, 15 Jan 2013 23:29:06 +0600 Subject: [erlang-questions] [ANN] Ybot-0.1 - an erlang customizable chat bot Message-ID: Hello, I just released version 0.1 of my chat bot - Ybot. One time i use Github hubot robot, but i don't like javascript, coffescript and etc... I like erlang. And i decide to write my own customizable bot in erlang. All main part of Ybot, Ybot core, Ybot transports written fully with erlang. Also Ybot has plugins. Plugins are Plugins can be written in python, ruby and shell now. In future i plan to add perl, escript and etc... Ybot support irc chat now. As there is a xmpp experimental support (see xmpp-transport-experemental branch). You can take a look at the code and the README over at the github repo: https://github.com/0xAX/Ybot. Feedback, contributing, critic and suggestions are welcome. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From g@REDACTED Tue Jan 15 18:47:49 2013 From: g@REDACTED (Garrett Smith) Date: Tue, 15 Jan 2013 11:47:49 -0600 Subject: [erlang-questions] suggestion: shorthand functions In-Reply-To: <50F5790B.5010301@ninenines.eu> References: <89E252DD-0629-4CCC-A1AA-526F1E53454D@feuerlabs.com> <20130111141854.GA31136@erix.ericsson.se> <50F5790B.5010301@ninenines.eu> Message-ID: Hi Lo?c, I use run_erl/to_erl as a proxy for OS signals. You can also use to_erl as a tty terminal via pipes, but that's not the case I'm talking about. Here's a simple example, requesting an orderly shutdown of the VM: 1. Start the VM as a daemon using run_erl $ mkdir -p /tmp/myapp $ run_erl -daemon /tmp/myapp/ tmp/myapp/ erl [your erl start args here] 2. Send a shell command to the VM by way of to_erl and run_erl $ echo "init:stop()." | to_erl /tmp/myapp/ You can tail the logs on /tmp/myapp/ to see what's going on. run_erl is basically an Erlang shell that exposes read and write access over pipes (FIFOs). $ to_erl /tmp/myapp/ If you want to get values from the process, you can write to the log (similar to Java's SIGQUIT behavior) or to a file. E.g. $ echo 'myapp:write_status("/tmp/myapp/status").' | to_erl /tmp/myapp/ If the app requires tighter interactivity with a CLI this approach starts to break down. Then you're back to distributed Erlang or roll-your-own interface (REST, simple RPC server, etc.) My *main* beef with distributed Erlang is epmd. It starts lazily and when killed (e.g. someone uninstalls the program and user that *happened* to start it) each of your local nodes goes dark. I recall seeing some activity around improving epmd somehow (don't remember) but IMO the problem is that it's a shared resource that isn't explicitly managed (started by the first Erlang node to need it). It'd be nice if you could have some of the distributed Erlang goodness, but with explicit ports and addressing - no NATing. Also, IMO Erlang should fail to start in distributed mode if epmd is *not* already running (with optional override). This would force epmd to be explicitly managed as an external dependency, which is what it in fact is. Garrett On Tue, Jan 15, 2013 at 9:43 AM, Lo?c Hoguin wrote: > Can you give an example of such a run_erl use? I have no idea how the tool > works. > > > On 01/15/2013 03:24 PM, Garrett Smith wrote: >> >> Hi Mahesh, >> >> Sounds like Yuri's driver is distributed Erlang. >> >> There are a bunch of apps out there that implement their command line >> interfaces (CLI) as distributed Erlang nodes that spin up, interact >> with another local node, then shut down. RabbitMQ does this. >> >> I *hate* it! (anger issues) >> >> - It's slow -- slower than *Java* for CLI operations >> >> - It's brittle -- distributed Erlang can fail for a number of reasons >> that are hard to diagnose >> >> - It introduces a third OS process -- epmd, a little >> single-point-of-failure devil that is the devil >> >> I personally advocate run_erl, which exposes a shell to to_erl over >> pipes. It's trivial to send commands to an Erlang process from bash or >> Python or anything you like. >> >> Some have criticized this approach as also being brittle. All I can >> say is that I've used this for years across thousands of servers and >> I'm very happy with it. >> >> That said, I often spend my Sunday mornings over coffee wondering how >> OS signal support isn't supported in Erlang. >> >> Garrett >> >> On Tue, Jan 15, 2013 at 7:46 AM, Mahesh Paolini-Subramanya >> wrote: >>> >>> Ah, you misunderstand. >>> I'm not running around saying Perl Now! Perl Forever! >>> Instead, what we do is separate the problem domains (to the extent >>> possible, >>> of course). >>> There is some set of functionality in the erlang application that needs >>> to >>> be exposed to our business processes - think "add a user", "disable a >>> client", "add billing credits", etc. >>> These are encapsulated and exposed via escript, and then embedded in perl >>> via 'system' / 'qx' / backquotes / whatever. >>> The same applies for activities like "rebalance node", "move user to >>> debug >>> node", etc. :-) >>> >>> cheers >>> Mahesh Paolini-Subramanya >>> That Tall Bald Indian Guy... >>> Google+ | Blog | Twitter | LinkedIn >>> >>> On Jan 15, 2013, at 5:22 AM, Yurii Rashkovskii wrote: >>> >>> Mahesh, >>> >>> This is certainly a good point about bash/perl/python/whatever, but these >>> become quite useless the moment you need to talk to some erlang node from >>> your escript. >>> >>> Yurii. >>> >>> On Friday, January 11, 2013 7:11:26 AM UTC-8, Mahesh Paolini-Subramanya >>> wrote: >>>> >>>> >>>> I love escripts but find myself intuitively avoiding them for a couple >>>> reasons: >>>> >>>> - In most cases, bash is more portable and solves system level >>>> problems more directly >>>> >>>> - I don't have the escript foo required to wrench my program it into a >>>> single script file >>>> >>>> >>>> Amen. >>>> perl (bash, python, whatever) is optimally suited for orchestrating >>>> between 'application space' and 'business space', as well as >>>> orchestration >>>> across loosely coupled systems and activities. >>>> Yes, you could force most of this into erlang-world, but to what point? >>>> IMHO, we do live in a polyglot world, and we may as well take advantage >>>> of >>>> it? >>>> >>>> Cheers >>>> >>>> p.s. Mind you, there is an entirely different argument to be made about >>>> systems where you only have access to erlang (or Ada. or whatever :-) ) >>>> >>>> Mahesh Paolini-Subramanya >>>> That Tall Bald Indian Guy... >>>> Google+ | Blog | Twitter | LinkedIn >>>> >>>> On Jan 11, 2013, at 9:55 AM, Garrett Smith wrote: >>>> >>>> On Fri, Jan 11, 2013 at 8:18 AM, Raimo Niskanen >>>> wrote: >>>> >>>> On Fri, Jan 11, 2013 at 10:12:40AM +0100, Ulf Wiger wrote: >>>> >>>> Since I've been writing a bunch of rebar.config.script code lately, >>>> I've suffered the agony of trying to write concise and readable >>>> code without having to do tons of copy-paste, weird unwrapping >>>> funs etc. >>>> >>>> What I think would make this sort of thing easier, and also >>>> escript programming in general, is if OTP could provide some >>>> modules with concise naming and let-it-fail semantics. >>>> >>>> Just off the top of my head, I scribbled down a few functions that >>>> I think would make *my* life easier. I pushed them to github to >>>> get some discussion going. >>>> >>>> http://github.com/uwiger/shorthand >>>> >>>> The modules are: >>>> >>>> f.erl - shorthand functions for file.erl >>>> fn.erl - ditto for filename.erl >>>> e.erl - ditto for erl_eval.erl >>>> >>>> The least beneficial is perhaps filename:erl, but my fingers and >>>> eyes ache from all the filename:join(filename:dirname(F), ?) >>>> code. >>>> >>>> Otherwise, I think the biggest benefit is to stick to let-it-crash >>>> programming, which I find is usually the default when I write >>>> scripts. The original functions are always available if you want >>>> to take a closer look at return values. >>>> >>>> (For the file:script() counterparts, I also always pass the name >>>> of the script as a binding). >>>> >>>> Comments? >>>> >>>> >>>> I think it is a nice idea that would improve scripting. >>>> >>>> But how to agree on module names and content is harder. There is a >>>> limited >>>> number of 1 and 2 character module names, and once in OTP they are >>>> written >>>> in stone. >>>> >>>> >>>> Aye. I don't know how critical this use case is (scripting >>>> simplification/improvements) to justify new modules in OTP space. And >>>> I'm not sure there *is* a case that would be sufficiently ubiquitous. >>>> >>>> I've resigned myself to writing little project specific >>>> functions/libraries like this to deal with project specific problems. >>>> E.g. this stuff drives me nuts: >>>> >>>> {ok, X} = foo:x(), >>>> {ok, Y} = foo:y(), >>>> combine(X, Y) >>>> ... >>>> >>>> So I'll write foo_x/0 and foo_y/0 with crash-on-error semantics to get >>>> this: >>>> >>>> combine(foo_x(), foo_y()) >>>> >>>> But who knew that I needed those particular variants? And what about >>>> changes? It's my project, so I don't mind little wrappers, especially >>>> since functions clarify intent. >>>> >>>> E.g. when I see this: >>>> >>>> ProjectFile = filename:join(ProjectDir, ProjectName) >>>> >>>> I'll almost create a function like this: >>>> >>>> project_filename(Dir, Name) -> filename:join(Dir, Name). >>>> >>>> For f.erl I miss e.g is_dir from filelib, which would introduce the >>>> notion >>>> of merging old module functionality. Using the name 'fl' for filelib >>>> functions would just be hard to remember. >>>> >>>> Aliasing filename:basename to fn:base is a bit unintuitive since the >>>> original Unix command is called 'basename' and for e.g file:list_dir >>>> you have aliased it to f:ls (as for many other) to make them more >>>> Unix:ish. >>>> I think it would be better to keep to unix command names where possible. >>>> [Wild idea: f:'-d' for filelib:is_dir, or t:'-d', or f:test(d, Path).] >>>> >>>> >>>> It seems one could make these arguments ad nauseam. To me it's just >>>> easier (and preferable frankly) to roll my own as the need arises. >>>> >>>> An alternative approach might be to have a helper module named 'es' >>>> containing all scripting aliases... >>>> >>>> >>>> I love escripts but find myself intuitively avoiding them for a couple >>>> reasons: >>>> >>>> - In most cases, bash is more portable and solves system level >>>> problems more directly >>>> >>>> - I don't have the escript foo required to wrench my program it into a >>>> single script file >>>> >>>> Setting bash aside (not Ulf's use case) the main barrier for me is in >>>> the perceived complexity of getting a release-of-sorts into an >>>> escript. If I could write up one of these wrapper libraries, or pull >>>> it down from somewhere easily, I might use escript everywhere. It's >>>> not hard to write the wrappers (you write them as you need them, it >>>> takes literally less than a minute for each function) and they're >>>> tailored to your requirements. >>>> >>>> It may be trivial to package up the required bytes into an escript >>>> today. If it is, I've love to know! >>>> >>>> And I don't know how this fits into rebar specific scripting :) >>>> >>>> Garrett >>>> _______________________________________________ >>>> 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 >> > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu From erlang@REDACTED Tue Jan 15 20:45:41 2013 From: erlang@REDACTED (Erik Reitsma) Date: Tue, 15 Jan 2013 20:45:41 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: References: <50F313AE.8050303@ernovation.com> Message-ID: <50F5B1E5.70508@ernovation.com> I have just stripped the erlang_r15b03.1.zip to a much smaller file (erlang_r15b03.2.zip), including only the basic applications. The new file can be installed using a new installer APK, http://erlang4android.googlecode.com/files/ErlangForAndroid_small.apk If you have installed Erlang on the Android device, and you want to try the light version instead, use the original installer to uninstall Erlang. Then install the new installer APK (which should replace the old installer), and use it to install Erlang again. Regards, *Erik. From desired.mta@REDACTED Tue Jan 15 21:39:42 2013 From: desired.mta@REDACTED (=?UTF-8?Q?Motiejus_Jak=C5=A1tys?=) Date: Tue, 15 Jan 2013 20:39:42 +0000 Subject: [erlang-questions] {precondition, false} in PropEr_statem Message-ID: Hi, I introduced some preconditions to my stateful properties. Depending on external state it returns true or false (if application somewhere is turned on or not). After many (1000+ usually) tests I get this error: History: State: Result: {precondition,false} It is natural that precondition sometimes returns false; that's the reason to have them. But I couldn't figure what is wrong in this case. Snippet: ?FORALL(Cmds, commands(?MODULE, initial_state(Nodes)), begin % Every test should be run in a separate bucket {History,State,Result} = run_commands(?MODULE, Cmds), % ... clean up ?WHENFAIL( io:format("No: ~p~nHistory: ~p\nState: ~p\nResult: ~p\n", [Id, History, State,Result]), Result =:= ok) end). What does it mean when PropEr returns {precondition, false}? Thanks, Motiejus Jak?tys From desired.mta@REDACTED Wed Jan 16 00:31:38 2013 From: desired.mta@REDACTED (Motiejus =?utf-8?Q?Jak=C5=A1tys?=) Date: Tue, 15 Jan 2013 23:31:38 +0000 Subject: [erlang-questions] {precondition, false} in PropEr_statem In-Reply-To: References: Message-ID: <20130115233138.GA9979@precise.local> On Wed, Jan 16, 2013 at 12:01:58AM +0100, Eirini Arvaniti wrote: > On 15 January 2013 21:39, Motiejus Jak?tys wrote: > > > Hi, > > I introduced some preconditions to my stateful properties. Depending > > on external state it returns true or false (if application somewhere > > is turned on or not). After many (1000+ usually) tests I get this > > error: > > > > History: > > State: > > Result: {precondition,false} > > > > It is natural that precondition sometimes returns false; that's the > > reason to have them. But I couldn't figure what is wrong in this case. > > > > Snippet: > > > > ?FORALL(Cmds, commands(?MODULE, initial_state(Nodes)), > > begin > > % Every test should be run in a separate bucket > > {History,State,Result} = run_commands(?MODULE, Cmds), > > % ... clean up > > ?WHENFAIL( > > io:format("No: ~p~nHistory: ~p\nState: ~p\nResult: > > ~p\n", > > [Id, History, State,Result]), > > Result =:= ok) > > end). > > > > What does it mean when PropEr returns {precondition, false}? > > > > Thanks, > > Motiejus Jak?tys > > > > > Hello Motiejus, > > {precondition, false} means that a precondition is not satisfied during > command execution. > > When a command sequence is executed, preconditions are checked and are > expected to be true, > since they have been already checked (and were true) during command > generation. > A precondition may be expected to be false at runtime only when a > counterexample is re-checked. > During normal testing it should not happen. > In your case, could it be that the external state on which preconditions > depend changes during command execution? Hello Eirini, External state is indeed changed during runtime of the algorithm. I.e. changing the external state is one of the of the commands that can be generated. But it is the expected way proper_statem works, isn't it? If I understand correctly, you are asking whether the state is changed between command generation and actual execution, but somewhat from remote. Then no. Or you are talking about different external state change? I will briefly illustrate what the system does, maybe I missed something. Demobucket is just an OTP application. These are the commands that change external state: command(S) -> frequency([ ... {1, {call, ?MODULE, stop_bucket, [rand_node(S)]}}, {9, {call, ?MODULE, start_bucket, [rand_node(S)]}} ]). start_bucket(Node) -> rpc:call(Node, application, start, [demobucket]). stop_bucket(Node) -> rpc:call(Node, application, stop, [demobucket]). %% some code to check if bucket runs anywhere but on Node precondition(#state{nodes=AllNodes}, {call, ?MODULE, stop_bucket, [Node]}) -> Nodes = AllNodes -- [N], Cond = fun(Apps) -> lists:keyfind(demobucket, 1, Apps) /= false end, {[A|B], []} = rpc:multicall([N|Nodes], application, which_applications, []), Cond(A) andalso lists:any(Cond, B); %% some code to check whether bucket doesn't run on Node precondition(_, {call, ?MODULE, start_bucket, [Node]}) -> Apps = rpc:call(Node, application, which_applications, []), lists:keyfind(demobucket, 1, Apps) =:= false; precondition(_, {call, ?MODULE, _, _}) -> true. To sum up, unless I am looking at wrong direction, nothing except stop_bucket/1 and start_bucket/1 change external system state. Regards, Motiejus From ryankbrown@REDACTED Wed Jan 16 00:50:26 2013 From: ryankbrown@REDACTED (Ryan Brown) Date: Tue, 15 Jan 2013 16:50:26 -0700 Subject: [erlang-questions] [Newbie] Erlang or Erlang/OTP Message-ID: I have begun learning erlang using the tutorial at: http://learnyousomeerlang.com So far it has been wonderful and I expect the remainder to be as well. However, as a newbie to Erlang, I have come across an issue and need some clarification. When I began the tutorial I just did an install via apt-get like so: sudo apt-get install erlang This has worked very well in the console for the excercises thus far. However, I am now at the point when I want to begin using emacs. When I go to install the emacs erlang-mode it seems to be requiring OTP. (I had planned on starting with the Erlang language fundamentals then move-on to OTP specific stuff) When I went to install OTP it instucted me to use apt-get and install esl\erlang: sudo apt-get install esl\erlang However, when I do this I receive conflict errors. So, I just went ahead and removed erlang: sudo apt-get remove erlang Then installed OTP as instructed: sudo apt-get install esl/erlang Now it appears to be good but I am unsure of what state I am in. Could someone please explain the difference? Am I missing anything from core erlang? I want to make sure because I am about to begin work maintaining a system that uses erlang and OTP. Thanks in advance! -- -rb -------------- next part -------------- An HTML attachment was scrubbed... URL: From ababkin@REDACTED Wed Jan 16 01:00:08 2013 From: ababkin@REDACTED (Alex Babkin) Date: Tue, 15 Jan 2013 19:00:08 -0500 Subject: [erlang-questions] [Newbie] Erlang or Erlang/OTP In-Reply-To: References: Message-ID: Hi Ryan I'd suggest not using the apt but rather just get the freshest sources and build it from source http://www.erlang.org/download.html do tell us about the project you will be maintaining On Tue, Jan 15, 2013 at 6:50 PM, Ryan Brown wrote: > I have begun learning erlang using the tutorial at: > > http://learnyousomeerlang.com > > So far it has been wonderful and I expect the remainder to be as well. > However, as a newbie to Erlang, I have come across an issue and need some > clarification. > > When I began the tutorial I just did an install via apt-get like so: > > sudo apt-get install erlang > > This has worked very well in the console for the excercises thus far. > However, I am now at the point when I want to begin using emacs. When I go > to install the emacs erlang-mode it seems to be requiring OTP. (I had > planned on starting with the Erlang language fundamentals then move-on to > OTP specific stuff) When I went to install OTP it instucted me to use > apt-get and install esl\erlang: > > sudo apt-get install esl\erlang > > However, when I do this I receive conflict errors. So, I just went ahead > and removed erlang: > > sudo apt-get remove erlang > > Then installed OTP as instructed: > > sudo apt-get install esl/erlang > > Now it appears to be good but I am unsure of what state I am in. Could > someone please explain the difference? Am I missing anything from core > erlang? I want to make sure because I am about to begin work maintaining > a system that uses erlang and OTP. > > Thanks in advance! > > -- > -rb > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From desired.mta@REDACTED Wed Jan 16 02:20:05 2013 From: desired.mta@REDACTED (=?UTF-8?Q?Motiejus_Jak=C5=A1tys?=) Date: Wed, 16 Jan 2013 01:20:05 +0000 Subject: [erlang-questions] [Newbie] Erlang or Erlang/OTP In-Reply-To: References: Message-ID: On Tue, Jan 15, 2013 at 11:50 PM, Ryan Brown wrote: > > sudo apt-get install esl/erlang > > Now it appears to be good but I am unsure of what state I am in. Could > someone please explain the difference? Am I missing anything from core > erlang? I want to make sure because I am about to begin work maintaining a > system that uses erlang and OTP. esl/erlang is a usually recent package provided by erlang solutions. Standard Erlang from debian based repositories is usually a bit out of date (I am not aware of any official repository which has >=R15B). Looks like you are good. However, as a safety measure, do dpkg -l \*erlang\* to see if you really do not have any conflicts (you should have probably esl-erlang only). Unless you run into problems that cannot be solved other way, I would advise against compiling from source when there are working packages available (this applies not only for Erlang, but for any software in general). That's what packages are for! Good luck and enjoy learning! Motiejus From norton@REDACTED Wed Jan 16 02:33:24 2013 From: norton@REDACTED (=?utf-8?B?44OO44O844OI44OzIOOCuOODp+ODvOOCu+ODlSDjgqbjgqfjgqQg?= =?utf-8?B?44Oz?=) Date: Wed, 16 Jan 2013 10:33:24 +0900 Subject: [erlang-questions] [Newbie] Erlang or Erlang/OTP In-Reply-To: References: Message-ID: <639F16E7-F832-4352-82FA-E1DC771474E0@lovely.email.ne.jp> If you want to build and/or to install Erlang/OTP from source, kerl (https://github.com/spawngrid/kerl) is a handy tool. regards, Joe N. On Jan 16, 2013, at 09:00 , Alex Babkin wrote: > Hi Ryan > > I'd suggest not using the apt but rather just get the freshest sources and build it from source > http://www.erlang.org/download.html > > do tell us about the project you will be maintaining > > > > On Tue, Jan 15, 2013 at 6:50 PM, Ryan Brown wrote: > I have begun learning erlang using the tutorial at: > > http://learnyousomeerlang.com > > So far it has been wonderful and I expect the remainder to be as well. However, as a newbie to Erlang, I have come across an issue and need some clarification. > > When I began the tutorial I just did an install via apt-get like so: > > sudo apt-get install erlang > > This has worked very well in the console for the excercises thus far. However, I am now at the point when I want to begin using emacs. When I go to install the emacs erlang-mode it seems to be requiring OTP. (I had planned on starting with the Erlang language fundamentals then move-on to OTP specific stuff) When I went to install OTP it instucted me to use apt-get and install esl\erlang: > > sudo apt-get install esl\erlang > > However, when I do this I receive conflict errors. So, I just went ahead and removed erlang: > > sudo apt-get remove erlang > > Then installed OTP as instructed: > > sudo apt-get install esl/erlang > > Now it appears to be good but I am unsure of what state I am in. Could someone please explain the difference? Am I missing anything from core erlang? I want to make sure because I am about to begin work maintaining a system that uses erlang and OTP. > > Thanks in advance! > > -- > -rb > > _______________________________________________ > erlang-questions mailing list > 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 ryankbrown@REDACTED Wed Jan 16 04:45:36 2013 From: ryankbrown@REDACTED (Ryan Brown) Date: Tue, 15 Jan 2013 20:45:36 -0700 Subject: [erlang-questions] [Newbie] Erlang or Erlang/OTP In-Reply-To: <639F16E7-F832-4352-82FA-E1DC771474E0@lovely.email.ne.jp> References: <639F16E7-F832-4352-82FA-E1DC771474E0@lovely.email.ne.jp> Message-ID: Thank you all for the excellent advice. I'm not entire which to follow however. Seems like there is some disagreement in terms of best practices. What I gather from these responses: - apt erlang packages are likely out-of-date - esl-erlang (sorry, typo in first email) may or may not be correct version (this was found at https://www.erlang-solutions.com/downloads/download-erlang-otp) - For erlang mode I should get the package It sounds like the Erlang Solutions version should be good for development but I am still not sure if this is best. I do tend to prefer not to compile from code if that is at all possible. However, I am certainly not opposed to it if that is what is generally recommended. I think for the time being I will continue with what I have. It sounds like it also includes OTP which I will be needing shortly. So far I am loving erlang. It's an incredibly powerful tool to add to my tech toolbox. For some reason many people I have spoken with seem to shy away from it seeing it as "difficult" or "too narrowly focused". But I can say, from what I have learned so far, that neither appears to be true. As for the project I am working on. It is a globally distributed, highly available and scalable, rabbitmq backed, pub/sub solution. It's been a tremendous solution created by a great former developer of ours that has become, somewhat, a victim of it's own success. It now needs some work on reducing latency across globally-distributed nodes and some supporting maintenance and monitoring. I'm very excited to be a part of it and expect to be a regular contributor, both on the giving and receiving end, to this group. Again, thank you all! -rb On Tue, Jan 15, 2013 at 6:33 PM, ???? ????? ??? ? wrote: > > If you want to build and/or to install Erlang/OTP from source, kerl ( > https://github.com/spawngrid/kerl) is a handy tool. > > regards, > > Joe N. > > On Jan 16, 2013, at 09:00 , Alex Babkin wrote: > > Hi Ryan > > I'd suggest not using the apt but rather just get the freshest sources and > build it from source > http://www.erlang.org/download.html > > do tell us about the project you will be maintaining > > > > On Tue, Jan 15, 2013 at 6:50 PM, Ryan Brown wrote: > >> I have begun learning erlang using the tutorial at: >> >> http://learnyousomeerlang.com >> >> So far it has been wonderful and I expect the remainder to be as well. >> However, as a newbie to Erlang, I have come across an issue and need some >> clarification. >> >> When I began the tutorial I just did an install via apt-get like so: >> >> sudo apt-get install erlang >> >> This has worked very well in the console for the excercises thus far. >> However, I am now at the point when I want to begin using emacs. When I go >> to install the emacs erlang-mode it seems to be requiring OTP. (I had >> planned on starting with the Erlang language fundamentals then move-on to >> OTP specific stuff) When I went to install OTP it instucted me to use >> apt-get and install esl\erlang: >> >> sudo apt-get install esl\erlang >> >> However, when I do this I receive conflict errors. So, I just went ahead >> and removed erlang: >> >> sudo apt-get remove erlang >> >> Then installed OTP as instructed: >> >> sudo apt-get install esl/erlang >> >> Now it appears to be good but I am unsure of what state I am in. Could >> someone please explain the difference? Am I missing anything from core >> erlang? I want to make sure because I am about to begin work maintaining >> a system that uses erlang and OTP. >> >> Thanks in advance! >> >> -- >> -rb >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > -- -rb -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Wed Jan 16 11:00:02 2013 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Wed, 16 Jan 2013 12:00:02 +0200 Subject: [erlang-questions] supervisor behaviour Message-ID: <2C70E9A6-77FA-40A7-819F-E97CACB42092@gmail.com> Hello, I do have a supervisor my_sup, where I add dynamically _transient_ child supervisor. supervisor:start_child(my_sup, { factory, {my_xxx_sup, start_link, []}, transient, 1000, supervisor, dynamic }), When my_xxx_sup is terminated "exit with reason reached_max_restart_intensity in context shutdown" the parent sup does nothing to restart it. However, the spec says "... transient child process should be restarted only if it terminates abnormally, i.e. with another exit reason than normal." BTW, when transient is changed to permanent everything works like expected. This sounds as a bug to me. The bug either in supervisor behaviour or in documentation, isn't it? Best Regards, Dmitry From davidnwelton@REDACTED Wed Jan 16 12:03:29 2013 From: davidnwelton@REDACTED (David Welton) Date: Wed, 16 Jan 2013 12:03:29 +0100 Subject: [erlang-questions] C nodes and OTP Message-ID: Hi I'm trying to wrap my head around the "best" way to set up an OTP-based system that comunicates with a C node. My inclination so far is to set up a gen_server, and use handle_info/2 to deal with messages coming from the C node. Looking at the C node example, it's all about messages, which seems to be "the simplest thing that could possibly work", which is good. I'm wondering, though, if it makes more sense to try and call directly into my gen_server's api with rpc, along the lines of what is being done here: http://stackoverflow.com/questions/4749693/can-i-get-erlang-otp-behaviors-in-c-nodes Any other tips/tricks/best practices/pitfalls to avoid would be welcome. Thanks, -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From rtrlists@REDACTED Wed Jan 16 18:44:45 2013 From: rtrlists@REDACTED (Robert Raschke) Date: Wed, 16 Jan 2013 17:44:45 +0000 Subject: [erlang-questions] C nodes and OTP In-Reply-To: References: Message-ID: Hi David, one potential pitfall with C nodes in general, regardless of pure message based or erl_rpc, comes when your C node does something time consuming. That is, your C node is not responding to ERL_TICK in a timely fashion. The connected Erlang nodes will then think that the C node has become disconnected. It is possible to recognise this situation from within the C node and explicitly reconnect to an Erlang node. I'm away from my work just now, but if you want an example, let me know and I'll send something round tomorrow. Alternatively, your C node can use threading to handle messages. That goes beyond my abilities ;-) Robby -- Sent from a mobile device, please excuse the typos. On Jan 16, 2013 11:03 AM, "David Welton" wrote: > Hi > > I'm trying to wrap my head around the "best" way to set up an > OTP-based system that comunicates with a C node. > > My inclination so far is to set up a gen_server, and use handle_info/2 > to deal with messages coming from the C node. > > Looking at the C node example, it's all about messages, which seems to > be "the simplest thing that could possibly work", which is good. I'm > wondering, though, if it makes more sense to try and call directly > into my gen_server's api with rpc, along the lines of what is being > done here: > > > http://stackoverflow.com/questions/4749693/can-i-get-erlang-otp-behaviors-in-c-nodes > > Any other tips/tricks/best practices/pitfalls to avoid would be welcome. > > Thanks, > -- > 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 magnus@REDACTED Wed Jan 16 19:17:14 2013 From: magnus@REDACTED (Magnus Henoch) Date: Wed, 16 Jan 2013 18:17:14 +0000 Subject: [erlang-questions] reltool vs non-numeric app version numbers Message-ID: Hi all, I was trying to understand why reltool rejected my application with "Missing application directory", and eventually came to the conclusion that reltool doesn't like application directories whose version components contain letters. My application uses rebar's {vsn, git} feature in its app.src file, and thus ends up with a 6-digit hexadecimal number as its version number. I can generate my release in my working directory, where the application is in a directory with a version-less name. If I install my application into /usr/lib/erlang/lib, and give it a name like "foo-42.0", then reltool finds it. Also, if I put a 'lib_dir' option in the 'app' tuple in reltool.config, then reltool accepts the directory no matter what it's called. In all of these cases, the code server can find the application if I set ERL_LIBS to the parent directory, so reltool has a stricter criterion. I suspect this happens because of the predicate in reltool_utils:split_app_name, but I haven't been able to confirm that; will do more testing tomorrow. Is this a bug or a feature? Regards, Magnus From mjtruog@REDACTED Wed Jan 16 20:09:02 2013 From: mjtruog@REDACTED (Michael Truog) Date: Wed, 16 Jan 2013 11:09:02 -0800 Subject: [erlang-questions] C nodes and OTP In-Reply-To: References: Message-ID: <50F6FACE.1090301@gmail.com> Hi C nodes have been a non-intrusive way to communicate with Erlang nodes, and is used in jinterface for JVM communication. So the main benefit of a C node is decoupling the startup of the C node code and the Erlang node code. If you don't need the startup decoupled, I believe an Erlang port is a better choice. If you want a simpler way of doing C-node-like integration, I have a project called CloudI (http://cloudi.org), which provides language integration (including Java) which avoids C nodes. The scalability limitation to C nodes is related to the fully connected network topology that distributed Erlang makes and the use of the ERL_TICK message (limiting distributed Erlang to 50-100 nodes, unless you get a really fast network.... then perhaps 200). So, avoiding C nodes is also avoiding scalability problems. On 01/16/2013 09:44 AM, Robert Raschke wrote: > > Hi David, > > one potential pitfall with C nodes in general, regardless of pure message based or erl_rpc, comes when your C node does something time consuming. That is, your C node is not responding to ERL_TICK in a timely fashion. The connected Erlang nodes will then think that the C node has become disconnected. > > It is possible to recognise this situation from within the C node and explicitly reconnect to an Erlang node. I'm away from my work just now, but if you want an example, let me know and I'll send something round tomorrow. > > Alternatively, your C node can use threading to handle messages. That goes beyond my abilities ;-) > > Robby > > -- > Sent from a mobile device, please excuse the typos. > > On Jan 16, 2013 11:03 AM, "David Welton" > wrote: > > Hi > > I'm trying to wrap my head around the "best" way to set up an > OTP-based system that comunicates with a C node. > > My inclination so far is to set up a gen_server, and use handle_info/2 > to deal with messages coming from the C node. > > Looking at the C node example, it's all about messages, which seems to > be "the simplest thing that could possibly work", which is good. I'm > wondering, though, if it makes more sense to try and call directly > into my gen_server's api with rpc, along the lines of what is being > done here: > > http://stackoverflow.com/questions/4749693/can-i-get-erlang-otp-behaviors-in-c-nodes > > Any other tips/tricks/best practices/pitfalls to avoid would be welcome. > > Thanks, > -- > 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 > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob@REDACTED Wed Jan 16 23:06:37 2013 From: jakob@REDACTED (Jakob Sievers) Date: Wed, 16 Jan 2013 23:06:37 +0100 Subject: [erlang-questions] [ANN] Some software from Klarna Message-ID: Hi, Klarna was nice enough to allow me to release some packages which I wrote under the Apache 2.0 license. Hopefully these are of interest to someone. TUlib: Klarna's standard library. https://github.com/klarna/tulib SoapBox: A microframework for RPC-style APIs. Like most other microframeworks but written with XMLRPC rather than REST in mind. Has fairly elaborate support for input validation. https://github.com/klarna/soapbox MeshUp: Workflow engine with some special support for Dynamo-style databases. I talked about this at the recent Erlang Factory in London. http://www.erlang-factory.com/conference/London2012/speakers/JakobSievers Sadly, poor sound quality doesn't go very well with poor public speaking. https://github.com/klarna/meshup RiMU: Implementations of the various MeshUp interfaces for Riak. https://github.com/klarna/rimu KRC: The K Riak Client. Sits on top of Basho's protobuffs client, providing a higher-level API and a connection pool. https://github.com/klarna/krc It should be noted that I uploaded copies of my dev branches (rather than the production branches), so there might be more lurking bugs than usual. enjoy, -jakob From alessandro.sivieri@REDACTED Thu Jan 17 00:26:59 2013 From: alessandro.sivieri@REDACTED (Alessandro Sivieri) Date: Thu, 17 Jan 2013 00:26:59 +0100 Subject: [erlang-questions] Terms to binary and viceversa Message-ID: Hi all, I have the following situation: two processes are exchanging data, and one particular packet contains the following three contents: - a character (which defines the type of that specific packet, in this case it is a 'A') - a pid - some binary data which I encode and decode in a specific way The question is: how can I extract the pid part using the bit syntax? I am able to extract the character, and I know that the pid (encoded to binary with term_to_binary) is 27 bytes, or 216 bits, so my first thought was something like <<$A:8, Pid:216, Data/binary>> But this is wrong because in Pid at this point I have a very large integer (and I see my error in that pattern), so do I have to get each single byte of the 27 bytes composing the pid one by one or is there a pattern that immediately matches that term giving me something that I can pass to binary_to_term? I have experimented a little but I always obtain a no matching clause... Alessandro -- Sivieri Alessandro alessandro.sivieri@REDACTED http://sivieri.wordpress.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Thu Jan 17 00:38:35 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 16 Jan 2013 18:38:35 -0500 Subject: [erlang-questions] Terms to binary and viceversa In-Reply-To: References: Message-ID: <20130116233834.GA8105@ferdmbp.local> The pattern: <<$A, BinPid:27/binary, Data/binary>> Should do it. Then you can get `Pid` by calling `binary_to_term/1` on `BinPid`. By default, the size of the `binary` type of matching is in bytes, so you should be extracting it fine. To get it in bits, you'd need to specify `BinPid:216/binary-unit:1`, for example. In your case, what you were doing is returning `Pid` as a 216 bits integer (the default type), not something you can use in any useful way. Regards, Fred. On 01/17, Alessandro Sivieri wrote: > Hi all, > > I have the following situation: two processes are exchanging data, and one > particular packet contains the following three contents: > > - a character (which defines the type of that specific packet, in this > case it is a 'A') > - a pid > - some binary data which I encode and decode in a specific way > > The question is: how can I extract the pid part using the bit syntax? I am > able to extract the character, and I know that the pid (encoded to binary > with term_to_binary) is 27 bytes, or 216 bits, so my first thought was > something like > > <<$A:8, Pid:216, Data/binary>> > > But this is wrong because in Pid at this point I have a very large integer > (and I see my error in that pattern), so do I have to get each single byte > of the 27 bytes composing the pid one by one or is there a pattern that > immediately matches that term giving me something that I can pass to > binary_to_term? I have experimented a little but I always obtain a no > matching clause... > > Alessandro > > -- > Sivieri Alessandro > alessandro.sivieri@REDACTED > http://sivieri.wordpress.com/ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From jayson.barley@REDACTED Thu Jan 17 00:40:41 2013 From: jayson.barley@REDACTED (Jayson Barley) Date: Wed, 16 Jan 2013 15:40:41 -0800 Subject: [erlang-questions] [ANN] Learn You Some Erlang now in Dead Tree Form! In-Reply-To: References: <20130110194704.GC70640@ferdmbp.local> <50EF6274.8050407@gmail.com> Message-ID: Fred, I got my copy of the book today, I pre-ordered it back in October. This is a beautiful book and want to thank you for taking the time to put it together. Jayson On Thu, Jan 10, 2013 at 9:05 PM, zac ma wrote: > good > > > On Fri, Jan 11, 2013 at 8:53 AM, Michael Truog wrote: > >> Congrats! >> >> >> On 01/10/2013 11:47 AM, Fred Hebert wrote: >> >>> Hi everyone, >>> >>> I think a lot of people on this list are now familiar with the existence >>> of Learn You Some Erlang for Great Good!, my website/tutorial about >>> Erlang. >>> >>> I've been working with the crew at No Starch Press for over a year now >>> to bring it down to a softcover book containing 624 pages. It's also >>> available as a DRM-Free ebook (PDF, Mobi, ePub). If you buy the paper >>> copy, you also get the ebook for free. You can get it from >>> http://nostarch.com/erlang >>> >>> Moreover, the team at No Starch is kicking it with 40% off if you buy it >>> with the CONCURRENT coupon code (see http://nostar.ch/erlang_promo for >>> details). It also contains a sticker. >>> >>> The website will keep being accessible and free. The book versions have >>> the advantage of having gone through professional editing and reviewing, >>> corrections to wording and explanations, and much nicer format to be >>> read in. >>> >>> Thanks for everyone's support while I was working on LYSE during the >>> last few years, and enjoy! >>> >>> 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-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 Thu Jan 17 01:10:53 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Thu, 17 Jan 2013 01:10:53 +0100 Subject: [erlang-questions] Terms to binary and viceversa In-Reply-To: <20130116233834.GA8105@ferdmbp.local> References: <20130116233834.GA8105@ferdmbp.local> Message-ID: Pids are not always 27 bytes. Names are atoms. Example: -module(t). -compile([export_all]). start() -> Pid = self(), PidBin = term_to_binary(Pid), SomeData = <<"some other data">>, Bin = <<$A, PidBin/binary, SomeData/binary>>, <<$A, 131, 103, 100, Len:16, Name:Len/binary, Id:4/binary, Serial:4/binary, Creation, Rest/binary>> = Bin, DecPid = binary_to_term(<<131, 103, 100, Len:16, Name/binary, Id/binary, Serial/binary, Creation>>), {Pid, DecPid, Rest}. Output: egil@REDACTED ~ $ erl -sname some-node-name-used Erlang R15B (erts-5.9) [source] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9 (abort with ^G) (some-node-name-used@REDACTED)1> t:start(). {<0.37.0>,<0.37.0>,<<"some other data">>} // Bj?rn-Egil 2013/1/17 Fred Hebert > The pattern: > > <<$A, BinPid:27/binary, Data/binary>> > > Should do it. Then you can get `Pid` by calling `binary_to_term/1` on > `BinPid`. By default, the size of the `binary` type of matching is in > bytes, so you should be extracting it fine. To get it in bits, you'd > need to specify `BinPid:216/binary-unit:1`, for example. > > In your case, what you were doing is returning `Pid` as a 216 bits > integer (the default type), not something you can use in any useful way. > > Regards, > Fred. > > On 01/17, Alessandro Sivieri wrote: > > Hi all, > > > > I have the following situation: two processes are exchanging data, and > one > > particular packet contains the following three contents: > > > > - a character (which defines the type of that specific packet, in this > > case it is a 'A') > > - a pid > > - some binary data which I encode and decode in a specific way > > > > The question is: how can I extract the pid part using the bit syntax? I > am > > able to extract the character, and I know that the pid (encoded to binary > > with term_to_binary) is 27 bytes, or 216 bits, so my first thought was > > something like > > > > <<$A:8, Pid:216, Data/binary>> > > > > But this is wrong because in Pid at this point I have a very large > integer > > (and I see my error in that pattern), so do I have to get each single > byte > > of the 27 bytes composing the pid one by one or is there a pattern that > > immediately matches that term giving me something that I can pass to > > binary_to_term? I have experimented a little but I always obtain a no > > matching clause... > > > > Alessandro > > > > -- > > Sivieri Alessandro > > alessandro.sivieri@REDACTED > > http://sivieri.wordpress.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 mononcqc@REDACTED Thu Jan 17 01:38:33 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 16 Jan 2013 19:38:33 -0500 Subject: [erlang-questions] Terms to binary and viceversa In-Reply-To: References: <20130116233834.GA8105@ferdmbp.local> Message-ID: <20130117003832.GB8105@ferdmbp.local> I went with whatever structure was mentionned in the parent post. If the pid expected is 27 bytes then it should work, if for example it equals some hardcoded node name (which is a big no-no to begin with.) Personally I'd use the Erlang External Term Format (http://erlang.org/doc/apps/erts/erl_ext_dist.html) (or BERT) and serialize everything with it, or go with a prefix indicating the length of the term to follow to make it simpler. On 01/17, Bj???rn-Egil Dahlberg wrote: > Pids are not always 27 bytes. Names are atoms. > > Example: > > -module(t). > > -compile([export_all]). > > start() -> > Pid = self(), > PidBin = term_to_binary(Pid), > SomeData = <<"some other data">>, > Bin = <<$A, PidBin/binary, SomeData/binary>>, > <<$A, 131, 103, 100, Len:16, Name:Len/binary, Id:4/binary, > Serial:4/binary, Creation, Rest/binary>> = Bin, > DecPid = binary_to_term(<<131, 103, 100, Len:16, Name/binary, > Id/binary, Serial/binary, Creation>>), > {Pid, DecPid, Rest}. > > Output: > > egil@REDACTED ~ $ erl -sname some-node-name-used > Erlang R15B (erts-5.9) [source] [smp:4:4] [async-threads:0] [hipe] > [kernel-poll:false] > > Eshell V5.9 (abort with ^G) > (some-node-name-used@REDACTED)1> t:start(). > {<0.37.0>,<0.37.0>,<<"some other data">>} > > > // Bj?rn-Egil > > > 2013/1/17 Fred Hebert > > > The pattern: > > > > <<$A, BinPid:27/binary, Data/binary>> > > > > Should do it. Then you can get `Pid` by calling `binary_to_term/1` on > > `BinPid`. By default, the size of the `binary` type of matching is in > > bytes, so you should be extracting it fine. To get it in bits, you'd > > need to specify `BinPid:216/binary-unit:1`, for example. > > > > In your case, what you were doing is returning `Pid` as a 216 bits > > integer (the default type), not something you can use in any useful way. > > > > Regards, > > Fred. > > > > On 01/17, Alessandro Sivieri wrote: > > > Hi all, > > > > > > I have the following situation: two processes are exchanging data, and > > one > > > particular packet contains the following three contents: > > > > > > - a character (which defines the type of that specific packet, in this > > > case it is a 'A') > > > - a pid > > > - some binary data which I encode and decode in a specific way > > > > > > The question is: how can I extract the pid part using the bit syntax? I > > am > > > able to extract the character, and I know that the pid (encoded to binary > > > with term_to_binary) is 27 bytes, or 216 bits, so my first thought was > > > something like > > > > > > <<$A:8, Pid:216, Data/binary>> > > > > > > But this is wrong because in Pid at this point I have a very large > > integer > > > (and I see my error in that pattern), so do I have to get each single > > byte > > > of the 27 bytes composing the pid one by one or is there a pattern that > > > immediately matches that term giving me something that I can pass to > > > binary_to_term? I have experimented a little but I always obtain a no > > > matching clause... > > > > > > Alessandro > > > > > > -- > > > Sivieri Alessandro > > > alessandro.sivieri@REDACTED > > > http://sivieri.wordpress.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 wallentin.dahlberg@REDACTED Thu Jan 17 01:47:39 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Thu, 17 Jan 2013 01:47:39 +0100 Subject: [erlang-questions] Terms to binary and viceversa In-Reply-To: <20130117003832.GB8105@ferdmbp.local> References: <20130116233834.GA8105@ferdmbp.local> <20130117003832.GB8105@ferdmbp.local> Message-ID: +1 2013/1/17 Fred Hebert > I went with whatever structure was mentionned in the parent post. > > If the pid expected is 27 bytes then it should work, if for example it > equals some hardcoded node name (which is a big no-no to begin with.) > Personally I'd use the Erlang External Term Format > (http://erlang.org/doc/apps/erts/erl_ext_dist.html) (or BERT) and > serialize everything with it, or go with a prefix indicating the length > of the term to follow to make it simpler. > > On 01/17, Bj?rn-Egil Dahlberg wrote: > > Pids are not always 27 bytes. Names are atoms. > > > > Example: > > > > -module(t). > > > > -compile([export_all]). > > > > start() -> > > Pid = self(), > > PidBin = term_to_binary(Pid), > > SomeData = <<"some other data">>, > > Bin = <<$A, PidBin/binary, SomeData/binary>>, > > <<$A, 131, 103, 100, Len:16, Name:Len/binary, Id:4/binary, > > Serial:4/binary, Creation, Rest/binary>> = Bin, > > DecPid = binary_to_term(<<131, 103, 100, Len:16, Name/binary, > > Id/binary, Serial/binary, Creation>>), > > {Pid, DecPid, Rest}. > > > > Output: > > > > egil@REDACTED ~ $ erl -sname some-node-name-used > > Erlang R15B (erts-5.9) [source] [smp:4:4] [async-threads:0] [hipe] > > [kernel-poll:false] > > > > Eshell V5.9 (abort with ^G) > > (some-node-name-used@REDACTED)1> t:start(). > > {<0.37.0>,<0.37.0>,<<"some other data">>} > > > > > > // Bj?rn-Egil > > > > > > 2013/1/17 Fred Hebert > > > > > The pattern: > > > > > > <<$A, BinPid:27/binary, Data/binary>> > > > > > > Should do it. Then you can get `Pid` by calling `binary_to_term/1` on > > > `BinPid`. By default, the size of the `binary` type of matching is in > > > bytes, so you should be extracting it fine. To get it in bits, you'd > > > need to specify `BinPid:216/binary-unit:1`, for example. > > > > > > In your case, what you were doing is returning `Pid` as a 216 bits > > > integer (the default type), not something you can use in any useful > way. > > > > > > Regards, > > > Fred. > > > > > > On 01/17, Alessandro Sivieri wrote: > > > > Hi all, > > > > > > > > I have the following situation: two processes are exchanging data, > and > > > one > > > > particular packet contains the following three contents: > > > > > > > > - a character (which defines the type of that specific packet, in > this > > > > case it is a 'A') > > > > - a pid > > > > - some binary data which I encode and decode in a specific way > > > > > > > > The question is: how can I extract the pid part using the bit > syntax? I > > > am > > > > able to extract the character, and I know that the pid (encoded to > binary > > > > with term_to_binary) is 27 bytes, or 216 bits, so my first thought > was > > > > something like > > > > > > > > <<$A:8, Pid:216, Data/binary>> > > > > > > > > But this is wrong because in Pid at this point I have a very large > > > integer > > > > (and I see my error in that pattern), so do I have to get each single > > > byte > > > > of the 27 bytes composing the pid one by one or is there a pattern > that > > > > immediately matches that term giving me something that I can pass to > > > > binary_to_term? I have experimented a little but I always obtain a no > > > > matching clause... > > > > > > > > Alessandro > > > > > > > > -- > > > > Sivieri Alessandro > > > > alessandro.sivieri@REDACTED > > > > http://sivieri.wordpress.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 ababkin@REDACTED Thu Jan 17 02:26:38 2013 From: ababkin@REDACTED (Alex Babkin) Date: Wed, 16 Jan 2013 20:26:38 -0500 Subject: [erlang-questions] using erlang openCL bindings codebase Message-ID: Hi I was trying to play around with this code (https://github.com/tonyrog/cl) and get it going on my mac (Air, OS X 10.8.2), but wasn't all that successful I have some experience running erlang programs but usually bootstrapped with rebar. I've gotten as far as getting "Trace/BPT trap: 5" as soon as i run some examples (and this error doesn't really help/tell me much) It'd be really great if there would be a step by step instructions on how to get the examples running and how to set the system up in general. A lot of people use macs for development nowadays, so mac specific instructions and gotchas would be great (and i can help with this however i can) here are the steps i followed: $mkdir opencl $cd opencl $git clone git://github.com/tonyrog/cl.git $cd cl $make $cd examples $make $ cd ../.. $erl -pa cl/ebin Erlang R15B03 (erts-5.9.3) [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9.3 (abort with ^G) 1> cl_bandwidth:test(). Trace/BPT trap: 5 Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.andin@REDACTED Thu Jan 17 09:26:07 2013 From: ingela.andin@REDACTED (Ingela Andin) Date: Thu, 17 Jan 2013 09:26:07 +0100 Subject: [erlang-questions] SSL connection is closed unexpectedly In-Reply-To: References: Message-ID: Hi! 2013/1/15 Alex Shneyderman : > Hello, everybody! > > I had a need to STARTTLS-enable tsung's jabber client. I use ssl > engine that comes with R15B02. Basically, code takes an existing > socket (tsung client - FSM owns that socket) and does an upgrade to > TLS at an appropriate moment in time. Like so: > > {ok,SslSocket} = ssl:connect(Socket, [{verify, > verify_none},{reuse_sessions,false}]), > ssl:controlling_process(SslSocket,ClientFSMPid), > ssl:setopts(SslSocket,[{active, once}]), > > > If I spawn some number of clients (the number varies but anything > beyond 200 seems to cause the problem) - connections get dropped and I > believe it is the client side that drops the connections (since this > behavior is not observed without TLS in the picture). So the > questions: > > 1. Is this a known default behavior? If so how do I make it go away, > i.e. some of the tests we are running need 2000 clients and plain > (non-tls). No it is not. What server are you running against? Servers may allow different number of concurrent connections for TLS and non TLS. > 2. Is there a simple way to debug these disconnects. In the logs all I > am getting is {tcp_closed, #Port<0.1608>}. Message does not have hints > as to why this socket was closed. Anything I can do to figure out > exactly why this happens? tcp_closed indicates that the peer closed the connection. Regards Ingela Erlang/OTP team - Ericsson AB From dgud@REDACTED Thu Jan 17 09:55:30 2013 From: dgud@REDACTED (Dan Gudmundsson) Date: Thu, 17 Jan 2013 09:55:30 +0100 Subject: [erlang-questions] using erlang openCL bindings codebase In-Reply-To: References: Message-ID: Yes there is a problem running OpenCL on 64-bit erlang. Try 32-bits or checkout the latest otp master from github it should be fixed there. /Dan On Thu, Jan 17, 2013 at 2:26 AM, Alex Babkin wrote: > Hi > > I was trying to play around with this code (https://github.com/tonyrog/cl) > and get it going on my mac (Air, OS X 10.8.2), but wasn't all that > successful > > I have some experience running erlang programs but usually bootstrapped with > rebar. > > I've gotten as far as getting "Trace/BPT trap: 5" as soon as i run some > examples (and this error doesn't really help/tell me much) > > It'd be really great if there would be a step by step instructions on how to > get the examples running and how to set the system up in general. A lot of > people use macs for development nowadays, so mac specific instructions and > gotchas would be great (and i can help with this however i can) > > here are the steps i followed: > > $mkdir opencl > $cd opencl > $git clone git://github.com/tonyrog/cl.git > $cd cl > $make > $cd examples > $make > $ cd ../.. > $erl -pa cl/ebin > Erlang R15B03 (erts-5.9.3) [source] [64-bit] [smp:4:4] [async-threads:0] > [hipe] [kernel-poll:false] > > Eshell V5.9.3 (abort with ^G) > 1> cl_bandwidth:test(). > Trace/BPT trap: 5 > > > Thanks > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From davidnwelton@REDACTED Thu Jan 17 10:01:24 2013 From: davidnwelton@REDACTED (David Welton) Date: Thu, 17 Jan 2013 10:01:24 +0100 Subject: [erlang-questions] C nodes and OTP In-Reply-To: <50F6FACE.1090301@gmail.com> References: <50F6FACE.1090301@gmail.com> Message-ID: > C nodes have been a non-intrusive way to communicate with Erlang nodes, and > is used in jinterface for JVM communication. So the main benefit of a C > node is decoupling the startup of the C node code and the Erlang node code. > If you don't need the startup decoupled, I believe an Erlang port is a > better choice. If you want a simpler way of doing C-node-like integration, > I have a project called CloudI (http://cloudi.org), which provides language > integration (including Java) which avoids C nodes One of the big advantages of a C node is that the C code can live a relatively independent life: if it crashes, it does not take Erlang with it. That's more important than simplicity or speed for us. > The scalability limitation to C nodes is related to the fully connected > network topology that distributed Erlang makes and the use of the ERL_TICK > message (limiting distributed Erlang to 50-100 nodes, unless you get a > really fast network.... then perhaps 200). So, avoiding C nodes is also > avoiding scalability problems. This is a semi-embedded system, so actually scalability is not really a concern. Latency is, but so is reliability. Thanks! -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From tony@REDACTED Thu Jan 17 10:10:15 2013 From: tony@REDACTED (Tony Rogvall) Date: Thu, 17 Jan 2013 10:10:15 +0100 Subject: [erlang-questions] using erlang openCL bindings codebase In-Reply-To: References: Message-ID: Yes. I did a post about that just the other day. if you know how, you can edit the erts/configure.in a rebuild erlang. If you can live with 32-bit or build from git Dan also had some nice ways around this. I will see if I can produce some easy instructions on how to start with cl. But in this case it was never possible to get started ;-) Thanks /Tony >> Hi! >> >> Found a workaround for cl (https://github.com/tonyrog/cl) not starting on erlang 64-bit mac os x >> The fix is to add "-framework Foundation" to LIBCARBON in erts/configure.in >> >> --- Like this --- >> case $ARCH-$OPSYS in >> amd64-darwin*) >> LIBCARBON="-framework Foundation" >> AC_MSG_RESULT([no]) >> ;; >> *-darwin*) >> LIBCARBON="-framework Carbon -framework Foundation" >> AC_MSG_RESULT([yes]) >> ;; >> -- >> >> Any chans that this might be fixed in a future release ? >> >> >> /Tony On 17 jan 2013, at 02:26, Alex Babkin wrote: > Hi > > I was trying to play around with this code (https://github.com/tonyrog/cl) and get it going on my mac (Air, OS X 10.8.2), but wasn't all that successful > > I have some experience running erlang programs but usually bootstrapped with rebar. > > I've gotten as far as getting "Trace/BPT trap: 5" as soon as i run some examples (and this error doesn't really help/tell me much) > > It'd be really great if there would be a step by step instructions on how to get the examples running and how to set the system up in general. A lot of people use macs for development nowadays, so mac specific instructions and gotchas would be great (and i can help with this however i can) > > here are the steps i followed: > > $mkdir opencl > $cd opencl > $git clone git://github.com/tonyrog/cl.git > $cd cl > $make > $cd examples > $make > $ cd ../.. > $erl -pa cl/ebin > Erlang R15B03 (erts-5.9.3) [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.9.3 (abort with ^G) > 1> cl_bandwidth:test(). > Trace/BPT trap: 5 > > > Thanks > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alessandro.sivieri@REDACTED Thu Jan 17 11:00:57 2013 From: alessandro.sivieri@REDACTED (Alessandro Sivieri) Date: Thu, 17 Jan 2013 11:00:57 +0100 Subject: [erlang-questions] Terms to binary and viceversa In-Reply-To: References: <20130116233834.GA8105@ferdmbp.local> <20130117003832.GB8105@ferdmbp.local> Message-ID: Thanks all for your help! Alessandro -- Sivieri Alessandro alessandro.sivieri@REDACTED http://sivieri.wordpress.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus@REDACTED Thu Jan 17 12:41:14 2013 From: magnus@REDACTED (Magnus Henoch) Date: Thu, 17 Jan 2013 11:41:14 +0000 Subject: [erlang-questions] reltool vs non-numeric app version numbers In-Reply-To: (Magnus Henoch's message of "Wed, 16 Jan 2013 18:17:14 +0000") References: Message-ID: Magnus Henoch writes: > I was trying to understand why reltool rejected my application with > "Missing application directory", and eventually came to the conclusion > that reltool doesn't like application directories whose version > components contain letters. My application uses rebar's {vsn, git} > feature in its app.src file, and thus ends up with a 6-digit hexadecimal > number as its version number. > > I can generate my release in my working directory, where the application > is in a directory with a version-less name. If I install my application > into /usr/lib/erlang/lib, and give it a name like "foo-42.0", then > reltool finds it. Also, if I put a 'lib_dir' option in the 'app' tuple > in reltool.config, then reltool accepts the directory no matter what > it's called. In all of these cases, the code server can find the > application if I set ERL_LIBS to the parent directory, so reltool has a > stricter criterion. I created a test case: https://gist.github.com/4555365 Regards, Magnus From a.shneyderman@REDACTED Thu Jan 17 14:31:58 2013 From: a.shneyderman@REDACTED (Alex Shneyderman) Date: Thu, 17 Jan 2013 08:31:58 -0500 Subject: [erlang-questions] SSL connection is closed unexpectedly In-Reply-To: References: Message-ID: On Thu, Jan 17, 2013 at 3:26 AM, Ingela Andin wrote: > Hi! > > 2013/1/15 Alex Shneyderman : >> Hello, everybody! >> >> I had a need to STARTTLS-enable tsung's jabber client. I use ssl >> engine that comes with R15B02. Basically, code takes an existing >> socket (tsung client - FSM owns that socket) and does an upgrade to >> TLS at an appropriate moment in time. Like so: >> >> {ok,SslSocket} = ssl:connect(Socket, [{verify, >> verify_none},{reuse_sessions,false}]), >> ssl:controlling_process(SslSocket,ClientFSMPid), >> ssl:setopts(SslSocket,[{active, once}]), >> >> >> If I spawn some number of clients (the number varies but anything >> beyond 200 seems to cause the problem) - connections get dropped and I >> believe it is the client side that drops the connections (since this >> behavior is not observed without TLS in the picture). So the >> questions: >> >> 1. Is this a known default behavior? If so how do I make it go away, >> i.e. some of the tests we are running need 2000 clients and plain >> (non-tls). > > No it is not. What server are you running against? Servers may allow different > number of concurrent connections for TLS and non TLS. this is ejabberd (2.1.11). I do not think there is any difference on maximum of connections between TLS and non-TLS on this server. Cheers, Alex. From antoine.koener@REDACTED Thu Jan 17 17:06:51 2013 From: antoine.koener@REDACTED (Antoine Koener) Date: Thu, 17 Jan 2013 17:06:51 +0100 Subject: [erlang-questions] SSL connection is closed unexpectedly In-Reply-To: References: Message-ID: Ejabberd needs a lot of memory, and ssl need more memory then plain tcp. Look at your ejabberd.log or erlang.log to investigate. Max tcp connections > max ssl connections Did you tweak Erl max ports ? On Thursday, January 17, 2013, Alex Shneyderman wrote: > On Thu, Jan 17, 2013 at 3:26 AM, Ingela Andin > > wrote: > > Hi! > > > > 2013/1/15 Alex Shneyderman >: > >> Hello, everybody! > >> > >> I had a need to STARTTLS-enable tsung's jabber client. I use ssl > >> engine that comes with R15B02. Basically, code takes an existing > >> socket (tsung client - FSM owns that socket) and does an upgrade to > >> TLS at an appropriate moment in time. Like so: > >> > >> {ok,SslSocket} = ssl:connect(Socket, [{verify, > >> verify_none},{reuse_sessions,false}]), > >> ssl:controlling_process(SslSocket,ClientFSMPid), > >> ssl:setopts(SslSocket,[{active, once}]), > >> > >> > >> If I spawn some number of clients (the number varies but anything > >> beyond 200 seems to cause the problem) - connections get dropped and I > >> believe it is the client side that drops the connections (since this > >> behavior is not observed without TLS in the picture). So the > >> questions: > >> > >> 1. Is this a known default behavior? If so how do I make it go away, > >> i.e. some of the tests we are running need 2000 clients and plain > >> (non-tls). > > > > No it is not. What server are you running against? Servers may allow > different > > number of concurrent connections for TLS and non TLS. > > this is ejabberd (2.1.11). I do not think there is > any difference on maximum of connections between > TLS and non-TLS on this server. > > Cheers, > Alex. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From MChenini@REDACTED Thu Jan 17 17:34:57 2013 From: MChenini@REDACTED (Chenini, Mohamed) Date: Thu, 17 Jan 2013 16:34:57 +0000 Subject: [erlang-questions] ErlangDC 2013: First Speakers Announced. In-Reply-To: References: <20130109160043.1BD374A0AA@prod-task-app1.evbops.com> Message-ID: FYI From: ErlangDC 2013 [mailto:auto-message@REDACTED] Sent: Wednesday, January 09, 2013 11:01 AM To: Chenini, Mohamed Subject: ErlangDC 2013: First Speakers Announced. [https://ebmedia.eventbrite.com/s3-s3/marketing/emails/top.gif] To All ErlangDC 2011 attendees: We've announced the first speakers for ErlangDC 2013 and they can be seen at http://erlangdc.com We will announce the remaining speakers next week. In the meantime, make sure you get your hands on one of the Early Bird tickets before they sell out. This year, in addition to a morning bootcamp for Erlang beginners, we will also hold other talks/workshops in the morning for the intermediate/advanced users. We hope you will join us again this year and we are asking for your support to spread the news on Twitter (https://twitter.com/erlangdc), Facebook, and other social networks. Help us make ErlangDC 2013 a success! Cheers, -- The ErlangDC Organizers Find us at https://twitter.com/erlangdc [https://ebmedia.eventbrite.com/s3-s3/marketing/emails/bottom.gif] [https://ebmedia.eventbrite.com/s3-s3/static/images/django/util/line.gif] This invitation was sent to mchenini@REDACTED by Erlang DC 2011 the organizer. To stop receiving invitations from this organizer, you can unsubscribe. [Eventbrite] Eventbrite | 651 Brannan St. Suite 110 | San Francisco, CA 94107 ==================== This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ababkin@REDACTED Thu Jan 17 17:40:44 2013 From: ababkin@REDACTED (Alex Babkin) Date: Thu, 17 Jan 2013 11:40:44 -0500 Subject: [erlang-questions] using erlang openCL bindings codebase In-Reply-To: References: Message-ID: Thanks Tony, Dan grabbed and built latest master erlang/otp from github and it seems to work now! let the opencl experimenting begin... :) On Thu, Jan 17, 2013 at 4:10 AM, Tony Rogvall wrote: > Yes. > I did a post about that just the other day. > if you know how, you can edit the erts/configure.in a rebuild erlang. > If you can live with 32-bit or build from git Dan also had some nice ways > around this. > > I will see if I can produce some easy instructions on how to start with cl. > But in this case it was never possible to get started ;-) > > Thanks > > /Tony > > Hi! > > Found a workaround for cl (https://github.com/tonyrog/cl) not starting on > erlang 64-bit mac os x > The fix is to add "-framework Foundation" to LIBCARBON in erts/ > configure.in > > --- Like this --- > case $ARCH-$OPSYS in > amd64-darwin*) > LIBCARBON="-framework Foundation" > AC_MSG_RESULT([no]) > ;; > *-darwin*) > LIBCARBON="-framework Carbon -framework Foundation" > AC_MSG_RESULT([yes]) > ;; > -- > > Any chans that this might be fixed in a future release ? > > > /Tony > > > > On 17 jan 2013, at 02:26, Alex Babkin wrote: > > Hi > > I was trying to play around with this code (https://github.com/tonyrog/cl) > and get it going on my mac (Air, OS X 10.8.2), but wasn't all that > successful > > I have some experience running erlang programs but usually bootstrapped > with rebar. > > I've gotten as far as getting "Trace/BPT trap: 5" as soon as i run some > examples (and this error doesn't really help/tell me much) > > It'd be really great if there would be a step by step instructions on how > to get the examples running and how to set the system up in general. A lot > of people use macs for development nowadays, so mac specific instructions > and gotchas would be great (and i can help with this however i can) > > here are the steps i followed: > > $mkdir opencl > $cd opencl > $git clone git://github.com/tonyrog/cl.git > $cd cl > $make > $cd examples > $make > $ cd ../.. > $erl -pa cl/ebin > Erlang R15B03 (erts-5.9.3) [source] [64-bit] [smp:4:4] [async-threads:0] > [hipe] [kernel-poll:false] > > Eshell V5.9.3 (abort with ^G) > 1> cl_bandwidth:test(). > Trace/BPT trap: 5 > > > Thanks > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias@REDACTED Thu Jan 17 23:09:05 2013 From: matthias@REDACTED (Matthias Lang) Date: Thu, 17 Jan 2013 23:09:05 +0100 Subject: [erlang-questions] C nodes and OTP In-Reply-To: References: <50F6FACE.1090301@gmail.com> Message-ID: <20130117220905.GA5284@corelatus.se> MT> > If you don't need the startup decoupled, I believe an Erlang port is a MT> > better choice. ... DW> One of the big advantages of a C node is that the C code can live a DW> relatively independent life: if it crashes, it does not take Erlang DW> with it. That's more important than simplicity or speed for us. It sounds like you're confusing a linked-in driver and a regular port. A linked-in driver can crash the Erlang VM. A plain port program cannot. Matt From dkuhlman@REDACTED Fri Jan 18 04:29:26 2013 From: dkuhlman@REDACTED (Dave Kuhlman) Date: Thu, 17 Jan 2013 19:29:26 -0800 (PST) Subject: [erlang-questions] edoc preformatted function specs Message-ID: <1358479766.75528.YahooMailNeo@web184802.mail.gq1.yahoo.com> I give edoc this: %%-------------------------------------------------------------------- -spec handle_incoming( ????????? ServiceURL::string(), ????????? WebSocket::pid(), ????????? SessionId::string(), ????????? Message::string(), ????????? State::#state{}) -> ????? {noreply, NewState::#state{}} | ????? {noreply, NewState::#state{}, Timeout::integer()} | ????? {stop, Reason::string(), NewState::#state{}}. %% @doc %% Handle an incoming message to this service. %% @end %%-------------------------------------------------------------------- And, it gives me what looks like this in the Web browser: %%-------------------------------------------------------------------- handle_incoming/5 handle_incoming(ServiceURL::string(), WebSocket::pid(), SessionId::string(), Message::string(), State::#state{}) -> {noreply, NewState::#state{}} | {noreply, NewState::#state{}, Timeout::integer()} | {stop, Reason::string(), NewState::#state{}} Handle an incoming message to this service. %%-------------------------------------------------------------------- which is rather difficult to read. Is there some way to prevent edoc from causing function specs to word wrap? I suspect that there is, because none of the erlang documentaion is wrapped and mashed together like that.? But, I've done Web searches and looked for flags and read the edoc docs.? And, I can't get a clue. Thanks for help. - Dave -- Dave Kuhlman http://www.rexx.com/~dkuhlman From yurinvv@REDACTED Fri Jan 18 04:36:27 2013 From: yurinvv@REDACTED (Slava Yurin) Date: Fri, 18 Jan 2013 10:36:27 +0700 Subject: [erlang-questions] edoc preformatted function specs In-Reply-To: <1358479766.75528.YahooMailNeo@web184802.mail.gq1.yahoo.com> References: <1358479766.75528.YahooMailNeo@web184802.mail.gq1.yahoo.com> Message-ID: <290201358480187@web10h.yandex.ru> An HTML attachment was scrubbed... URL: From steve@REDACTED Fri Jan 18 09:12:36 2013 From: steve@REDACTED (Steve Strong) Date: Fri, 18 Jan 2013 09:12:36 +0100 Subject: [erlang-questions] lager_trunc_io Message-ID: <52F8F721F8BC4C4E9C6E3027232CADE2@srstrong.com> Hi All, Having a strange one with some lager logging, and hopping someone might have seen it before? In the last couple of days I've spotted a few crashes in my logs that I've not seen before. In my console log, I get: 2013-01-17 14:56:44.712 [error] <0.46.0> gen_server lager_crash_log terminated with reason: bad argument in call to lager_trunc_io:format("FORMAT ERROR: ~p ~p", ["** Generic server ~p terminating \ \n** Last message in was ~p~n** When Server state == ~p~n** R...",...]) line 66 in lager_crash_log:do_log/2 line 189 2013-01-17 14:56:44.820 [error] <0.46.0> CRASH REPORT Process lager_crash_log with 0 neighbours exited with reason: bad argument in call to lager_trunc_io:format("FORMAT ERROR: ~p ~p", ["** Generi\ c server ~p terminating \n** Last message in was ~p~n** When Server state == ~p~n** R...",...]) line 66 in lager_crash_log:do_log/2 line 189 in gen_server:terminate/6 line 747 2013-01-17 14:56:45.079 [error] <0.43.0> Supervisor lager_sup had child lager_crash_log started with lager_crash_log:start_link("log/crash.log", 65536, 65536, [{hour,0}], 5) at <0.46.0> exit with \ reason bad argument in call to lager_trunc_io:format("FORMAT ERROR: ~p ~p", ["** Generic server ~p terminating \n** Last message in was ~p~n** When Server state == ~p~n** R...",...]) line 66 in la\ ger_crash_log:do_log/2 line 189 in context child_terminated with a corresponding crash report in the crash log: 013-01-17 14:56:45 =CRASH REPORT==== crasher: initial call: lager_crash_log:init/1 pid: <0.2189.47> registered_name: lager_crash_log exception exit: {{function_clause,[{lager_trunc_io,alist,[{<0.390.0>,left},64003,{print_options,-1,true,false}],[{file,"src/lager_trunc_io.erl"},{line,367}]},{lager_trunc_io,alist,3,[{file,"sr\ c/lager_trunc_io.erl"},{line,382}]},{lager_trunc_io,alist_start,3,[{file,"src/lager_trunc_io.erl"},{line,355}]},{lager_trunc_io,list_body,4,[{file,"src/lager_trunc_io.erl"},{line,299}]},{lager_tru\ nc_io,alist_start,3,[{file,"src/lager_trunc_io.erl"},{line,364}]},{lager_trunc_io,list_bodyc,4,[{file,"src/lager_trunc_io.erl"},{line,311}]},{lager_trunc_io,list_bodyc,4,[{file,"src/lager_trunc_io\ .erl"},{line,312}]},{lager_trunc_io,list_body,4,[{file,"src/lager_trunc_io.erl"},{line,300}]}]},[{gen_server,terminate,6,[{file,"gen_server.erl"},{line,747}]},{proc_lib,init_p_do_apply,3,[{file,"p\ roc_lib.erl"},{line,227}]}]} ancestors: [lager_sup,<0.41.0>] messages: [] links: [<0.43.0>,#Port<0.6132>] dictionary: [] trap_exit: false status: running heap_size: 2584 stack_size: 24 reductions: 3739 neighbours: 2013-01-17 14:56:46 =SUPERVISOR REPORT==== Supervisor: {local,lager_sup} Context: child_terminated Reason: {function_clause,[{lager_trunc_io,alist,[{<0.390.0>,left},64003,{print_options,-1,true,false}],[{file,"src/lager_trunc_io.erl"},{line,367}]},{lager_trunc_io,alist,3,[{file,"src/la\ ger_trunc_io.erl"},{line,382}]},{lager_trunc_io,alist_start,3,[{file,"src/lager_trunc_io.erl"},{line,355}]},{lager_trunc_io,list_body,4,[{file,"src/lager_trunc_io.erl"},{line,299}]},{lager_trunc_i\ o,alist_start,3,[{file,"src/lager_trunc_io.erl"},{line,364}]},{lager_trunc_io,list_bodyc,4,[{file,"src/lager_trunc_io.erl"},{line,311}]},{lager_trunc_io,list_bodyc,4,[{file,"src/lager_trunc_io.erl\ "},{line,312}]},{lager_trunc_io,list_body,4,[{file,"src/lager_trunc_io.erl"},{line,300}]}]} Offender: [{pid,<0.2189.47>},{name,lager_crash_log},{mfargs,{lager_crash_log,start_link,["log/crash.log",65536,65536,[{hour,0}],5]}},{restart_type,permanent},{shutdown,5000},{child_type,wor\ ker}] The lager activity is, I think, due to one of my gen_servers crashing, but I've never seen lager exhibit this behaviour before. This is lager v1.2.1. Anyone seen this behaviour before? Any pointers as to how to track down the root cause? Cheers, Steve -- Steve Strong Sent with Sparrow (http://www.sparrowmailapp.com/?sig) -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Jan 18 10:19:37 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Fri, 18 Jan 2013 10:19:37 +0100 Subject: [erlang-questions] edoc preformatted function specs In-Reply-To: <1358479766.75528.YahooMailNeo@web184802.mail.gq1.yahoo.com> References: <1358479766.75528.YahooMailNeo@web184802.mail.gq1.yahoo.com> Message-ID: <50F913A9.7060506@ninenines.eu> On 01/18/2013 04:29 AM, Dave Kuhlman wrote: > I suspect that there is, because none of the erlang documentaion is wrapped > and mashed together like that. But, I've done Web searches and looked for > flags and read the edoc docs. And, I can't get a clue. Most, if not all, of the Erlang documentation is in DocBook format, including the function reference. I am not sure they use edoc for anything inside Erlang itself. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From andrew@REDACTED Fri Jan 18 12:44:09 2013 From: andrew@REDACTED (Andrew Thompson) Date: Fri, 18 Jan 2013 06:44:09 -0500 Subject: [erlang-questions] lager_trunc_io In-Reply-To: <52F8F721F8BC4C4E9C6E3027232CADE2@srstrong.com> References: <52F8F721F8BC4C4E9C6E3027232CADE2@srstrong.com> Message-ID: <20130118114409.GC12548@hijacked.us> On Fri, Jan 18, 2013 at 09:12:36AM +0100, Steve Strong wrote: > Hi All, > > Having a strange one with some lager logging, and hopping someone might have seen it before? In the last couple of days I've spotted a few crashes in my logs that I've not seen before. In my console log, I get: > > > 2013-01-17 14:56:44.712 [error] <0.46.0> gen_server lager_crash_log terminated with reason: bad argument in call to lager_trunc_io:format("FORMAT ERROR: ~p ~p", ["** Generic server ~p terminating \ > \n** Last message in was ~p~n** When Server state == ~p~n** R...",...]) line 66 in lager_crash_log:do_log/2 line 189 > Looks like a bug... somewhere. Not sure how that is happening, but I'll try to look after I'm done traveling. Can you file an issue against basho/lager so we can track it there? Andrew From yashgt@REDACTED Fri Jan 18 13:18:32 2013 From: yashgt@REDACTED (Yash Ganthe) Date: Fri, 18 Jan 2013 17:48:32 +0530 Subject: [erlang-questions] SAX-like JSON Parser for Erlang In-Reply-To: References: Message-ID: SAX allows the client application to read an XML piece-by-piece. This is different than DOM which expects the entire XML to be loaded in memory. SAX is thus useful for reading very large XML documents.**** ** ** Mochijson is a good JSON parser which emits structs that correspond to individual JSON strings. It however expects the entire JSON string to be given to its functions.**** If I have about 10000 records in an JSON such as this,**** { "d" : **** [**** {**** "ID": 1, "Name": "p1", "Email": "p1@REDACTED"* *** }, **** {**** "ID": 2, "Name": "p2", "Email": "p2@REDACTED"* *** }, **** {**** "ID": 3, "Name": "p3", "Email": "p3@REDACTED"* *** }, **** {**** "ID": 4, "Name": "p4", "Email": "p4@REDACTED"* *** } . . . . .**** ] }**** the entire JSON string would have to be first obtained and then passed to mochijson/mochijson2.**** ** ** I am looking for a way to let the module give me one record at a time from the large JSON-formatted array. Is there any module that lets us do this?*** * ** ** Thanks,**** Yash -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Fri Jan 18 13:21:12 2013 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Fri, 18 Jan 2013 14:21:12 +0200 Subject: [erlang-questions] SAX-like JSON Parser for Erlang In-Reply-To: References: Message-ID: Hello, check this one https://github.com/talentdeficit/jsx.git - Dmitry On Jan 18, 2013, at 2:18 PM, Yash Ganthe wrote: > SAX allows the client application to read an XML piece-by-piece. This is different than DOM which expects the entire XML to be loaded in memory. SAX is thus useful for reading very large XML documents. > > > > Mochijson is a good JSON parser which emits structs that correspond to individual JSON strings. It however expects the entire JSON string to be given to its functions. > > If I have about 10000 records in an JSON such as this, > > { "d" : > > [ > > { > > "ID": 1, "Name": "p1", "Email": "p1@REDACTED" > > }, > > { > > "ID": 2, "Name": "p2", "Email": "p2@REDACTED" > > }, > > { > > "ID": 3, "Name": "p3", "Email": "p3@REDACTED" > > }, > > { > > "ID": 4, "Name": "p4", "Email": "p4@REDACTED" > > } . . . . . > > ] } > > the entire JSON string would have to be first obtained and then passed to mochijson/mochijson2. > > > > I am looking for a way to let the module give me one record at a time from the large JSON-formatted array. Is there any module that lets us do this? > > > > Thanks, > > Yash > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From yashgt@REDACTED Fri Jan 18 14:31:41 2013 From: yashgt@REDACTED (Yash Ganthe) Date: Fri, 18 Jan 2013 05:31:41 -0800 (PST) Subject: [erlang-questions] SAX-like JSON Parser for Erlang In-Reply-To: References: Message-ID: This module looks really good. The documentation mentions "incomplete" data. I assume this ti be a case where we want to read data from an HTTP response. I could not find an exported method in the module that lets me pass a stearm to jsx and get event to fire when individual objects are read from the stream. Is this supported in the module? Thanks, Yash On Friday, January 18, 2013 5:51:12 PM UTC+5:30, Dmitry Kolesnikov wrote: > Hello, > > check this one https://github.com/talentdeficit/jsx.git > > - Dmitry > > On Jan 18, 2013, at 2:18 PM, Yash Ganthe > > wrote: > > SAX allows the client application to read an XML piece-by-piece. This is > different than DOM which expects the entire XML to be loaded in memory. SAX > is thus useful for reading very large XML documents.**** > > ** ** > > Mochijson is a good JSON parser which emits structs that correspond to > individual JSON strings. It however expects the entire JSON string to be > given to its functions.**** > > If I have about 10000 records in an JSON such as this,**** > > { "d" : **** > > [**** > > {**** > > "ID": 1, "Name": "p1", "Email": " > p...@REDACTED "**** > > }, **** > > {**** > > "ID": 2, "Name": "p2", "Email": " > p...@REDACTED "**** > > }, **** > > {**** > > "ID": 3, "Name": "p3", "Email": " > p...@REDACTED "**** > > }, **** > > {**** > > "ID": 4, "Name": "p4", "Email": " > p...@REDACTED "**** > > } . . . . .**** > > ] }**** > > the entire JSON string would have to be first obtained and then passed to > mochijson/mochijson2.**** > > ** ** > > I am looking for a way to let the module give me one record at a time from > the large JSON-formatted array. Is there any module that lets us do this?* > *** > > ** ** > > Thanks,**** > > Yash > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Fri Jan 18 14:55:01 2013 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Fri, 18 Jan 2013 05:55:01 -0800 (PST) Subject: [erlang-questions] SAX-like JSON Parser for Erlang In-Reply-To: References: Message-ID: <1358517301.25429.YahooMailNeo@web120702.mail.ne1.yahoo.com> One potential problem with SAX-style parsing is that repeated keys in a JSON object will use/return only the last value (a behaviour inherited from javascript, I believe). Thus, to find the value of a given key you need in principle to parse the whole object anyway. This makes SAX less convenient, though using it might still save memory.? If you know repeated keys will never happen (the JSON RFC says "The names within an object SHOULD be unique."), you could roll the dice and go ahead anyway. Best, Thomas >________________________________ > From: Yash Ganthe >To: erlang-questions >Sent: Friday, January 18, 2013 1:18 PM >Subject: [erlang-questions] SAX-like JSON Parser for Erlang > > >SAX allows the client application to read an XML piece-by-piece. This is different than DOM which expects the entire XML to be loaded in memory. SAX is thus useful for reading very large XML documents. >? >Mochijson is a good JSON parser which emits structs that correspond to individual JSON strings. It however expects the entire JSON string to be given to its functions. >If I have about 10000 records in an JSON such as this, >{ "d" : >[ >??????????????? { >??????????????????????????????? "ID": 1, "Name": "p1", "Email": "p1@REDACTED" >??????????????? }, >??????????????? { >??????????????????????????????? "ID": 2, "Name": "p2", "Email": "p2@REDACTED" >??????????????? }, >??????????????? { >??????????????????????????????? "ID": 3, "Name": "p3", "Email": "p3@REDACTED" >??????????????? }, >??????????????? { >??????????????????????????????? "ID": 4, "Name": "p4", "Email": "p4@REDACTED" >??????????????? } . . . . . >] } >the entire JSON string would have to be first obtained and then passed to mochijson/mochijson2. >? >I am looking for a way to let the module give me one record at a time from the large JSON-formatted array. Is there any module that lets us do this? >? >Thanks, >Yash >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > > > From atulatri2004@REDACTED Fri Jan 18 15:10:59 2013 From: atulatri2004@REDACTED (atul atri) Date: Fri, 18 Jan 2013 19:40:59 +0530 Subject: [erlang-questions] Mnesia select aborted Message-ID: Dear All, I am getting following kind of error under heavy load while selecting many records from a table. {aborted, {cyclic, ejabberd@REDACTED, {staff, '______WHOLETABLE_____'}, read,read, {tid,20368014, <0.1219.0>}}}. I tried to search over internet about 'cyclic' mnesia errors but could not find any clue. Do anyone have any idea about such kind of error? Thanks & Regards, Atul Atri. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangud@REDACTED Fri Jan 18 15:18:35 2013 From: dangud@REDACTED (Dan Gudmundsson) Date: Fri, 18 Jan 2013 15:18:35 +0100 Subject: [erlang-questions] Mnesia select aborted In-Reply-To: References: Message-ID: You should not use catch inside a mnesia transaction. But if you do you must re-throw mnesia's exceptions. /Dan On Fri, Jan 18, 2013 at 3:10 PM, atul atri wrote: > Dear All, > > I am getting following kind of error under heavy load while selecting many > records from a table. > > {aborted, > {cyclic, > ejabberd@REDACTED, > {staff, > > '______WHOLETABLE_____'}, > read,read, > {tid,20368014, > <0.1219.0>}}}. > > > > I tried to search over internet about 'cyclic' mnesia errors but could not > find any clue. Do anyone have any idea about such kind of error? > > Thanks & Regards, > Atul Atri. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From davidnwelton@REDACTED Fri Jan 18 16:08:19 2013 From: davidnwelton@REDACTED (David Welton) Date: Fri, 18 Jan 2013 16:08:19 +0100 Subject: [erlang-questions] C nodes and OTP In-Reply-To: <20130117220905.GA5284@corelatus.se> References: <50F6FACE.1090301@gmail.com> <20130117220905.GA5284@corelatus.se> Message-ID: On Thu, Jan 17, 2013 at 11:09 PM, Matthias Lang wrote: > > > MT> > If you don't need the startup decoupled, I believe an Erlang port is a > MT> > better choice. > ... > > DW> One of the big advantages of a C node is that the C code can live a > DW> relatively independent life: if it crashes, it does not take Erlang > DW> with it. That's more important than simplicity or speed for us. > > It sounds like you're confusing a linked-in driver and a regular port. > A linked-in driver can crash the Erlang VM. A plain port program cannot. Sorry, yes, I think I was looking at this: http://www.erlang.org/doc/tutorial/c_portdriver.html which is what had me confused. Regular old open_port might work for what we want to do too...I'll have to consider it. C nodes just seemed cleaner and more decoupled. -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From bgustavsson@REDACTED Fri Jan 18 16:25:04 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 18 Jan 2013 16:25:04 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: <50F54CA3.8030302@ernovation.com> References: <50F313AE.8050303@ernovation.com> <50F464D6.9030700@ernovation.com> <50F54CA3.8030302@ernovation.com> Message-ID: On Tue, Jan 15, 2013 at 1:33 PM, Erik Reitsma wrote: > On 01/15/2013 10:41 AM, Joe Armstrong wrote: > > Golly - I read the code - you modified error_handler.erl !!!! > > So what happens is ... > > I call android:fooBar(Args) - fooBar is not defined in android.erl > so it's caught in error_handler and then android:rpc(fooBar, [...]) is > called > and this ends up as a Json call to a socket - > > Yes, that is what happens. > > > It might interest you to know, that in R16, you can have a handler for undefined functions in each module. (We needed that to implement the parse transformation for parameterized modules.) This new feature has just been merged to the master branch: https://github.com/erlang/otp/commit/209a479080214ab901116d48b90e91d6c056278d /Bjorn -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Fri Jan 18 16:32:42 2013 From: tony@REDACTED (Tony Rogvall) Date: Fri, 18 Jan 2013 16:32:42 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: References: <50F313AE.8050303@ernovation.com> <50F464D6.9030700@ernovation.com> <50F54CA3.8030302@ernovation.com> Message-ID: Wow, this must be abused without hesitation. Really nice ! /Tony On 18 jan 2013, at 16:25, Bj?rn Gustavsson wrote: > > > > On Tue, Jan 15, 2013 at 1:33 PM, Erik Reitsma wrote: > On 01/15/2013 10:41 AM, Joe Armstrong wrote: >> Golly - I read the code - you modified error_handler.erl !!!! >> >> So what happens is ... >> >> I call android:fooBar(Args) - fooBar is not defined in android.erl >> so it's caught in error_handler and then android:rpc(fooBar, [...]) is called >> and this ends up as a Json call to a socket - >> > Yes, that is what happens. >> > > It might interest you to know, that in R16, you can have a handler for > undefined functions in each module. (We needed that to implement the parse > transformation for parameterized modules.) > > This new feature has just been merged to the master branch: > > https://github.com/erlang/otp/commit/209a479080214ab901116d48b90e91d6c056278d > > /Bjorn > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Fri Jan 18 16:36:02 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 18 Jan 2013 16:36:02 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: References: <50F313AE.8050303@ernovation.com> <50F464D6.9030700@ernovation.com> <50F54CA3.8030302@ernovation.com> Message-ID: Out of curiosity, why? -- Anthony Ramine Le 18 janv. 2013 ? 16:25, Bj?rn Gustavsson a ?crit : > We needed that to implement the parse > transformation for parameterized modules -------------- next part -------------- An HTML attachment was scrubbed... URL: From egil@REDACTED Fri Jan 18 16:37:14 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Fri, 18 Jan 2013 16:37:14 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: References: <50F313AE.8050303@ernovation.com> <50F464D6.9030700@ernovation.com> <50F54CA3.8030302@ernovation.com> Message-ID: <50F96C2A.1060100@erlang.org> On 2013-01-18 16:32, Tony Rogvall wrote: > > Wow, this must be abused without hesitation. > Oh, good god. Tony, when you put your brainpower into abusing Erlang code, Erlang maintainers run scared. =) // Bj?rn-Egil > Really nice ! > > /Tony > > On 18 jan 2013, at 16:25, Bj?rn Gustavsson > wrote: > >> >> >> >> On Tue, Jan 15, 2013 at 1:33 PM, Erik Reitsma > > wrote: >> >> On 01/15/2013 10:41 AM, Joe Armstrong wrote: >>> Golly - I read the code - you modified error_handler.erl !!!! >>> >>> So what happens is ... >>> >>> I call android:fooBar(Args) - fooBar is not defined in >>> android.erl >>> so it's caught in error_handler and then android:rpc(fooBar, >>> [...]) is called >>> and this ends up as a Json call to a socket - >>> >> Yes, that is what happens. >>> >> It might interest you to know, that in R16, you can have a handler for >> undefined functions in each module. (We needed that to implement the >> parse >> transformation for parameterized modules.) >> >> This new feature has just been merged to the master branch: >> >> https://github.com/erlang/otp/commit/209a479080214ab901116d48b90e91d6c056278d >> >> /Bjorn >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > "Installing applications can lead to corruption over time. > Applications gradually write over each other's libraries, partial > upgrades occur, user and system errors happen, and minute changes may > be unnoticeable and difficult to fix" > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Jan 18 16:50:33 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Fri, 18 Jan 2013 16:50:33 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: References: <50F313AE.8050303@ernovation.com> <50F464D6.9030700@ernovation.com> <50F54CA3.8030302@ernovation.com> Message-ID: <50F96F49.1030006@ninenines.eu> Dialyzer will complain if the function is undefined. It also breaks expectations, what's the type going in? Out? You shouldn't use it. On 01/18/2013 04:32 PM, Tony Rogvall wrote: > Wow, this must be abused without hesitation. > > Really nice ! > > /Tony > > On 18 jan 2013, at 16:25, Bj?rn Gustavsson > wrote: > >> >> >> >> On Tue, Jan 15, 2013 at 1:33 PM, Erik Reitsma > > wrote: >> >> On 01/15/2013 10:41 AM, Joe Armstrong wrote: >>> Golly - I read the code - you modified error_handler.erl !!!! >>> >>> So what happens is ... >>> >>> I call android:fooBar(Args) - fooBar is not defined in android.erl >>> so it's caught in error_handler and then android:rpc(fooBar, >>> [...]) is called >>> and this ends up as a Json call to a socket - >>> >> Yes, that is what happens. >>> >> It might interest you to know, that in R16, you can have a handler for >> undefined functions in each module. (We needed that to implement the parse >> transformation for parameterized modules.) >> >> This new feature has just been merged to the master branch: >> >> https://github.com/erlang/otp/commit/209a479080214ab901116d48b90e91d6c056278d >> >> /Bjorn >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > "Installing applications can lead to corruption over time. Applications > gradually write over each other's libraries, partial upgrades occur, > user and system errors happen, and minute changes may be unnoticeable > and difficult to fix" > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From essen@REDACTED Fri Jan 18 16:53:26 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Fri, 18 Jan 2013 16:53:26 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: References: <50F313AE.8050303@ernovation.com> <50F464D6.9030700@ernovation.com> <50F54CA3.8030302@ernovation.com> Message-ID: <50F96FF6.3070404@ninenines.eu> On 01/18/2013 04:25 PM, Bj?rn Gustavsson wrote: > > > > On Tue, Jan 15, 2013 at 1:33 PM, Erik Reitsma > wrote: > > On 01/15/2013 10:41 AM, Joe Armstrong wrote: >> Golly - I read the code - you modified error_handler.erl !!!! >> >> So what happens is ... >> >> I call android:fooBar(Args) - fooBar is not defined in android.erl >> so it's caught in error_handler and then android:rpc(fooBar, >> [...]) is called >> and this ends up as a Json call to a socket - >> > Yes, that is what happens. >> > It might interest you to know, that in R16, you can have a handler for > undefined functions in each module. (We needed that to implement the parse > transformation for parameterized modules.) > > This new feature has just been merged to the master branch: > > https://github.com/erlang/otp/commit/209a479080214ab901116d48b90e91d6c056278d This sounds like a temporary workaround with potentially very bad uses. Why was it documented? -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From apauley@REDACTED Fri Jan 18 16:56:12 2013 From: apauley@REDACTED (Andreas Pauley) Date: Fri, 18 Jan 2013 17:56:12 +0200 Subject: [erlang-questions] How to enslave an army of minions with Distributed Erlang Nodes Message-ID: Hi everyone, I've been reading up on some of the cool distributed features of Erlang. With this in mind I've created a simple example so I could demo this to a couple of people by connecting the nodes on a few laptops. Check out the code if this sound interesting to you: https://github.com/apauley/dark-overlord It has mostly been tested on Mac OS X, and it can be improved a lot by maybe applying more OTP principles etc, but I had quite a bit of fun doing and showing the primitive version already. Next I'd like to figure out some more simple and fun examples to do once you have a master node with an army of minions at your disposal. Any ideas would be appreciated :-) Kind regards, Andreas -- http://pauley.org.za/ http://twitter.com/apauley http://www.meetup.com/lambda-luminaries/ From bgustavsson@REDACTED Fri Jan 18 16:57:14 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 18 Jan 2013 16:57:14 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: References: <50F313AE.8050303@ernovation.com> <50F464D6.9030700@ernovation.com> <50F54CA3.8030302@ernovation.com> Message-ID: To implement the -extends() attribute that allows the implementation of a module to be extended by inheritance. That used to be implemented in the error_handler. I have removed that code in the same commit that implements $handle-undefined-function. On Fri, Jan 18, 2013 at 4:36 PM, Anthony Ramine wrote: > Out of curiosity, why? > > -- > Anthony Ramine > > Le 18 janv. 2013 ? 16:25, Bj?rn Gustavsson a ?crit : > > We needed that to implement the parse > transformation for parameterized modules > > > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Jan 18 16:59:34 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Fri, 18 Jan 2013 16:59:34 +0100 Subject: [erlang-questions] Specs for optional callbacks Message-ID: <50F97166.4020109@ninenines.eu> Is this planned? We can today write behaviours with the specifications of the callbacks documented. What about optional callbacks, like gen_server's format_status/2? It would be great to have a way to specify the specifications for these, too. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From n.oxyde@REDACTED Fri Jan 18 17:02:41 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 18 Jan 2013 17:02:41 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: References: <50F313AE.8050303@ernovation.com> <50F464D6.9030700@ernovation.com> <50F54CA3.8030302@ernovation.com> Message-ID: <31A875D7-B842-4F48-9AE2-DAD514B2BFB9@gmail.com> Why is it documented? Isn't -extends unsupported? Shouldn't this disappear in the future too? -- Anthony Ramine Le 18 janv. 2013 ? 16:57, Bj?rn Gustavsson a ?crit : > To implement the -extends() attribute that allows the > implementation of a module to be extended by > inheritance. That used to be implemented in the > error_handler. I have removed that code in the same > commit that implements $handle-undefined-function. > > > On Fri, Jan 18, 2013 at 4:36 PM, Anthony Ramine wrote: > Out of curiosity, why? > > -- > Anthony Ramine > > Le 18 janv. 2013 ? 16:25, Bj?rn Gustavsson a ?crit : > >> We needed that to implement the parse >> transformation for parameterized modules > > > > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Fri Jan 18 17:48:33 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 18 Jan 2013 17:48:33 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: <50F96FF6.3070404@ninenines.eu> References: <50F313AE.8050303@ernovation.com> <50F464D6.9030700@ernovation.com> <50F54CA3.8030302@ernovation.com> <50F96FF6.3070404@ninenines.eu> Message-ID: Parameterized modules were not documented, but that did not prevent people from using them. Nowadays we generally prefer to document everything, but add warnings in the documentation if we think it could be abused. We might add such warnings to the documentation of $handle_undefined_function. Although other languages may give the programmer more rope to hang himself, Erlang already provides plenty of rope, for instance parse_transforms, NIFs, and the error_handler module. Using $handle_undefined_function is safer than modfying error_handler, since it can be done locally to a single module. So we have shortened the rope. :-) On Fri, Jan 18, 2013 at 4:53 PM, Lo?c Hoguin wrote: > On 01/18/2013 04:25 PM, Bj?rn Gustavsson wrote: > >> >> >> >> On Tue, Jan 15, 2013 at 1:33 PM, Erik Reitsma > **> wrote: >> >> On 01/15/2013 10:41 AM, Joe Armstrong wrote: >> >>> Golly - I read the code - you modified error_handler.erl !!!! >>> >>> So what happens is ... >>> >>> I call android:fooBar(Args) - fooBar is not defined in android.erl >>> so it's caught in error_handler and then android:rpc(fooBar, >>> [...]) is called >>> and this ends up as a Json call to a socket - >>> >>> Yes, that is what happens. >> >>> >>> It might interest you to know, that in R16, you can have a handler for >> undefined functions in each module. (We needed that to implement the parse >> transformation for parameterized modules.) >> >> This new feature has just been merged to the master branch: >> >> https://github.com/erlang/otp/**commit/**209a479080214ab901116d48b90e91** >> d6c056278d >> > > This sounds like a temporary workaround with potentially very bad uses. > Why was it documented? > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Fri Jan 18 18:32:13 2013 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 18 Jan 2013 18:32:13 +0100 Subject: [erlang-questions] edoc preformatted function specs In-Reply-To: <50F913A9.7060506@ninenines.eu> References: <1358479766.75528.YahooMailNeo@web184802.mail.gq1.yahoo.com> <50F913A9.7060506@ninenines.eu> Message-ID: On Fri, Jan 18, 2013 at 10:19 AM, Lo?c Hoguin wrote: > On 01/18/2013 04:29 AM, Dave Kuhlman wrote: > >> I suspect that there is, because none of the erlang documentaion is >> wrapped >> and mashed together like that. But, I've done Web searches and looked for >> flags and read the edoc docs. And, I can't get a clue. >> > > Most, if not all, of the Erlang documentation is in DocBook format, > including the function reference. I am not sure they use edoc for anything > inside Erlang itself. It's not docbook we have our own DTD's - the documentation is made from a mixture of XML and the spec and type declarations in the code - the XML and type info is merged together into XML and then transformed into HTML and (via FOP) into PDF. The edoc stuff doesn't make it into the printed documentation. edoc, the type notation and erldoc evolved in parallel and are not 100% consistent with each other. Cheers /Joe > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > 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 rustompmody@REDACTED Fri Jan 18 18:36:48 2013 From: rustompmody@REDACTED (Rustom Mody) Date: Fri, 18 Jan 2013 23:06:48 +0530 Subject: [erlang-questions] how to get labels on digraphs Message-ID: The add_edge/4 routine in digraph claims to have labels that are arbitrary erlang terms. However nothing I do seems to show me the label I created the edge with. Is there something I am missing? -------------- next part -------------- An HTML attachment was scrubbed... URL: From aggelgian@REDACTED Fri Jan 18 19:09:35 2013 From: aggelgian@REDACTED (Aggelos Giantsios) Date: Fri, 18 Jan 2013 20:09:35 +0200 Subject: [erlang-questions] how to get labels on digraphs In-Reply-To: References: Message-ID: On Fri, Jan 18, 2013 at 7:36 PM, Rustom Mody wrote: > The add_edge/4 routine in digraph claims to have labels that are arbitrary > erlang terms. > However nothing I do seems to show me the label I created the edge with. > Hello!! You can retrieve the label information of edge E in a digraph G with the function digraph:edge(G, E). Here's the output of my interpreter (R15B03) 1> G = digraph:new(). {digraph,16400,20497,24594,true} 2> digraph:add_vertex(G, v1). v1 3> digraph:add_vertex(G, v2). v2 4> digraph:add_edge(G, e1, v1, v2, my_label). e1 5> digraph:edge(G, e1). {e1,v1,v2,my_label} I hope that helps! Aggelos -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Fri Jan 18 19:39:50 2013 From: erlang@REDACTED (Erik Reitsma) Date: Fri, 18 Jan 2013 19:39:50 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: References: <50F313AE.8050303@ernovation.com> <50F464D6.9030700@ernovation.com> <50F54CA3.8030302@ernovation.com> Message-ID: <50F996F6.3030700@ernovation.com> On 01/18/2013 04:25 PM, Bj?rn Gustavsson wrote: > > On Tue, Jan 15, 2013 at 1:33 PM, Erik Reitsma > wrote: > > On 01/15/2013 10:41 AM, Joe Armstrong wrote: >> Golly - I read the code - you modified error_handler.erl !!!! >> >> So what happens is ... >> >> I call android:fooBar(Args) - fooBar is not defined in android.erl >> so it's caught in error_handler and then android:rpc(fooBar, >> [...]) is called >> and this ends up as a Json call to a socket - >> > Yes, that is what happens. >> > It might interest you to know, that in R16, you can have a handler for > undefined functions in each module. (We needed that to implement the parse > transformation for parameterized modules.) > > This new feature has just been merged to the master branch: > > https://github.com/erlang/otp/commit/209a479080214ab901116d48b90e91d6c056278d > That's interesting. I will use it to implement this feature. I modified the error_handler also to look for the source if a compiled module was not found. I will probably remove that feature and only compile the module to be run. I can do that in my android module, so I will be able to leave error_handler.erl unmodified. Quite a relief for everybody, I am sure. :-) *Erik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anotherworldofworld@REDACTED Fri Jan 18 19:54:54 2013 From: anotherworldofworld@REDACTED (0xAX 0xAX) Date: Sat, 19 Jan 2013 00:54:54 +0600 Subject: [erlang-questions] ibrowse freeze after some requests Message-ID: Hello erlangers, I use ibrowse for campfire http streaming using. My code: https://gist.github.com/4567230 When i start it, it's ok, I can receive messages from campfire, but after 10 messages {ibrowse_async_response, ReqId, Data} all freeze, and all the stops and did not get any message. In what could be the problem? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkuhlman@REDACTED Fri Jan 18 20:17:44 2013 From: dkuhlman@REDACTED (Dave Kuhlman) Date: Fri, 18 Jan 2013 11:17:44 -0800 (PST) Subject: [erlang-questions] edoc preformatted function specs In-Reply-To: <290201358480187@web10h.yandex.ru> References: <1358479766.75528.YahooMailNeo@web184802.mail.gq1.yahoo.com> <290201358480187@web10h.yandex.ru> Message-ID: <1358536664.45503.YahooMailNeo@web184803.mail.gq1.yahoo.com> > From: Slava Yurin >Sent: Thursday, January 17, 2013 7:36 PM > Hi Dave. > > You can try pass to edoc comand option {pretty_printer, erl_pp}. > Slava - Thanks.? That works great.? It does just what I wanted, even though I did not know that was what I wanted. I was actually looking for something that would preserve *my* formatting, but this (re-formatting with erlang style) is even better. After you told me what to look for, I was able to use grep to find it in the HTML documentation.? For others who need more formatting control etc, it's buried in the documentation for edoc_layout, along with some other options like index_columns, stylesheet, sort_functions, and xml_export. Thanks again for help. - Dave -- Dave Kuhlman http://www.rexx.com/~dkuhlman From w.a.de.jong@REDACTED Fri Jan 18 20:43:50 2013 From: w.a.de.jong@REDACTED (Willem de Jong) Date: Fri, 18 Jan 2013 20:43:50 +0100 Subject: [erlang-questions] SAX-like JSON Parser for Erlang In-Reply-To: References: Message-ID: Hi Yash, I don't know if it meets your requirements, but I wrote a SAX-like JSON parser a couple of years ago. You can find it on trapexit.org in the user contributions section: http://forum.trapexit.org/download.php?id=158 Good luck, Willem On Fri, Jan 18, 2013 at 1:18 PM, Yash Ganthe wrote: > SAX allows the client application to read an XML piece-by-piece. This is > different than DOM which expects the entire XML to be loaded in memory. SAX > is thus useful for reading very large XML documents.**** > > ** ** > > Mochijson is a good JSON parser which emits structs that correspond to > individual JSON strings. It however expects the entire JSON string to be > given to its functions.**** > > If I have about 10000 records in an JSON such as this,**** > > { "d" : **** > > [**** > > {**** > > "ID": 1, "Name": "p1", "Email": "p1@REDACTED > "**** > > }, **** > > {**** > > "ID": 2, "Name": "p2", "Email": "p2@REDACTED > "**** > > }, **** > > {**** > > "ID": 3, "Name": "p3", "Email": "p3@REDACTED > "**** > > }, **** > > {**** > > "ID": 4, "Name": "p4", "Email": "p4@REDACTED > "**** > > } . . . . .**** > > ] }**** > > the entire JSON string would have to be first obtained and then passed to > mochijson/mochijson2.**** > > ** ** > > I am looking for a way to let the module give me one record at a time from > the large JSON-formatted array. Is there any module that lets us do this?* > *** > > ** ** > > Thanks,**** > > Yash > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel@REDACTED Fri Jan 18 23:14:51 2013 From: daniel@REDACTED (Daniel Luna) Date: Fri, 18 Jan 2013 17:14:51 -0500 Subject: [erlang-questions] Specs for optional callbacks In-Reply-To: <50F97166.4020109@ninenines.eu> References: <50F97166.4020109@ninenines.eu> Message-ID: On 18 January 2013 10:59, Lo?c Hoguin wrote: > Is this planned? > > We can today write behaviours with the specifications of the callbacks > documented. What about optional callbacks, like gen_server's > format_status/2? It would be great to have a way to specify the > specifications for these, too. +1 Oh, and while we are at it, it would be great to allow multiple behaviours with shared callback functions to compile without warnings. My single file supervisor/gen_server/gen_event logger module had to comment out two of the -behaviour lines. Almost totally while using good coding standard too. Either that or disallow multiple behaviours in the same file in general. Cheers, Daniel From rustompmody@REDACTED Sat Jan 19 04:54:23 2013 From: rustompmody@REDACTED (Rustom Mody) Date: Sat, 19 Jan 2013 09:24:23 +0530 Subject: [erlang-questions] how to get labels on digraphs In-Reply-To: References: Message-ID: On Fri, Jan 18, 2013 at 11:39 PM, Aggelos Giantsios wrote: > On Fri, Jan 18, 2013 at 7:36 PM, Rustom Mody wrote: > >> The add_edge/4 routine in digraph claims to have labels that are >> arbitrary erlang terms. >> However nothing I do seems to show me the label I created the edge with. >> > > Hello!! > > You can retrieve the label information of edge E in a digraph G with the > function digraph:edge(G, E). > > Here's the output of my interpreter (R15B03) > > 1> G = digraph:new(). > {digraph,16400,20497,24594,true} > 2> digraph:add_vertex(G, v1). > v1 > 3> digraph:add_vertex(G, v2). > v2 > 4> digraph:add_edge(G, e1, v1, v2, my_label). > e1 > 5> digraph:edge(G, e1). > {e1,v1,v2,my_label} > > I hope that helps! > > Aggelos > Thanks Aggelos -- kept doing 'edges' and seeing nothing. In fact I think I tried edge as well ? must have been something else the matter? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Sat Jan 19 15:13:54 2013 From: tony@REDACTED (Tony Rogvall) Date: Sat, 19 Jan 2013 15:13:54 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: <50F96F49.1030006@ninenines.eu> References: <50F313AE.8050303@ernovation.com> <50F464D6.9030700@ernovation.com> <50F54CA3.8030302@ernovation.com> <50F96F49.1030006@ninenines.eu> Message-ID: On 18 jan 2013, at 16:50, Lo?c Hoguin wrote: > Dialyzer will complain if the function is undefined. It also breaks expectations, what's the type going in? Out? > > You shouldn't use it. > I did not see a smiley, serious man. Of course you must use it, it is there! For example: - I am currently building a version system for Erlang modules and can use this feature to implement proof of concept. The function can be used as dispatcher to different versions, one small component in the implementation of the POC. - Implement curry of functions with a little help of a simple parse_transform. -module(curry). -export([add/2]). add(X,Y) -> X + Y. foo(X,Y,Z) -> X+Y-Z. %% some parse_transform magic may generate this '$handle_undefined_function'(add, [X]) -> fun(Y) -> add(X,Y) end; '$handle_undefined_function'(foo, [X]) -> fun(Y) -> fun(Z) -> foo(X,Y,Z) end end; '$handle_undefined_function'(foo, [X,Y]) -> fun(Z) -> foo(X,Y,Z) end; ... Now we can call: (currry:add(1))(2) - implement varadic functions also with a little help of parse_transform -module(m). sum(Xs) -> lists:sum(Xs). %% some parse_transform magic may generate this '$handle_undefined_function'(sum, Xs) -> sum(Xs). Now we can call m:sum(1), m:sum(1,2,3,4). - a flavour of the above is to make simple proxy modules, trace, debug... And ... well the list can be extended with some creativity. /Tony > On 01/18/2013 04:32 PM, Tony Rogvall wrote: >> Wow, this must be abused without hesitation. >> >> Really nice ! >> >> /Tony >> >> On 18 jan 2013, at 16:25, Bj?rn Gustavsson > > wrote: >> >>> >>> >>> >>> On Tue, Jan 15, 2013 at 1:33 PM, Erik Reitsma >> > wrote: >>> >>> On 01/15/2013 10:41 AM, Joe Armstrong wrote: >>>> Golly - I read the code - you modified error_handler.erl !!!! >>>> >>>> So what happens is ... >>>> >>>> I call android:fooBar(Args) - fooBar is not defined in android.erl >>>> so it's caught in error_handler and then android:rpc(fooBar, >>>> [...]) is called >>>> and this ends up as a Json call to a socket - >>>> >>> Yes, that is what happens. >>>> >>> It might interest you to know, that in R16, you can have a handler for >>> undefined functions in each module. (We needed that to implement the parse >>> transformation for parameterized modules.) >>> >>> This new feature has just been merged to the master branch: >>> >>> https://github.com/erlang/otp/commit/209a479080214ab901116d48b90e91d6c056278d >>> >>> /Bjorn >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> "Installing applications can lead to corruption over time. Applications >> gradually write over each other's libraries, partial upgrades occur, >> user and system errors happen, and minute changes may be unnoticeable >> and difficult to fix" >> >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Sat Jan 19 16:06:48 2013 From: bchesneau@REDACTED (Benoit Chesneau) Date: Sat, 19 Jan 2013 16:06:48 +0100 Subject: [erlang-questions] erlang:statistics & erlang:memory Message-ID: I am curious, how are the vm statistics & memory collected ? Is this a counter, or something aggregated? - beno?t -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.virding@REDACTED Sun Jan 20 00:16:41 2013 From: robert.virding@REDACTED (Robert Virding) Date: Sat, 19 Jan 2013 23:16:41 +0000 (GMT) Subject: [erlang-questions] Erlang4Android In-Reply-To: Message-ID: <1152298455.2921291.1358637401797.JavaMail.root@erlang-solutions.com> Isn't that the best reason NOT to implement it. Kill -extends() instead, it sucks. Robert ----- Original Message ----- > From: "Bj?rn Gustavsson" > To: "Anthony Ramine" > Cc: "Erlang-questions" > Sent: Friday, 18 January, 2013 4:57:14 PM > Subject: Re: [erlang-questions] Erlang4Android > To implement the -extends() attribute that allows the > implementation of a module to be extended by > inheritance. That used to be implemented in the > error_handler. I have removed that code in the same > commit that implements $handle-undefined-function. > On Fri, Jan 18, 2013 at 4:36 PM, Anthony Ramine < n.oxyde@REDACTED > > wrote: > > Out of curiosity, why? > > > -- > > > Anthony Ramine > > > Le 18 janv. 2013 ? 16:25, Bj?rn Gustavsson a ?crit : > > > > We needed that to implement the parse > > > > > > transformation for parameterized modules > > > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > _______________________________________________ > 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 Sun Jan 20 00:18:11 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Sun, 20 Jan 2013 00:18:11 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: <1152298455.2921291.1358637401797.JavaMail.root@erlang-solutions.com> References: <1152298455.2921291.1358637401797.JavaMail.root@erlang-solutions.com> Message-ID: <50FB29B3.3090402@ninenines.eu> +1 On 01/20/2013 12:16 AM, Robert Virding wrote: > Isn't that the best reason NOT to implement it. Kill -extends() instead, > it sucks. > > Robert > > ------------------------------------------------------------------------ > > *From: *"Bj?rn Gustavsson" > *To: *"Anthony Ramine" > *Cc: *"Erlang-questions" > *Sent: *Friday, 18 January, 2013 4:57:14 PM > *Subject: *Re: [erlang-questions] Erlang4Android > > To implement the -extends() attribute that allows the > implementation of a module to be extended by > inheritance. That used to be implemented in the > error_handler. I have removed that code in the same > commit that implements $handle-undefined-function. > > > On Fri, Jan 18, 2013 at 4:36 PM, Anthony Ramine > wrote: > > Out of curiosity, why? > > -- > Anthony Ramine > > Le 18 janv. 2013 ? 16:25, Bj?rn Gustavsson a ?crit : > > We needed that to implement the parse > transformation for parameterized modules > > > > > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > > _______________________________________________ > erlang-questions mailing list > 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 Erlang Cowboy Nine Nines http://ninenines.eu From tony@REDACTED Sun Jan 20 00:33:22 2013 From: tony@REDACTED (Tony Rogvall) Date: Sun, 20 Jan 2013 00:33:22 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: <1152298455.2921291.1358637401797.JavaMail.root@erlang-solutions.com> References: <1152298455.2921291.1358637401797.JavaMail.root@erlang-solutions.com> Message-ID: <7AC67CFA-EEF0-4023-8B43-830A55F2D9D3@rogvall.se> I have never used parametrized modules, so I have no clue what you talk about, but I think $handle_undefined-function may be very useful. I vote for it. :-) /Tony On 20 jan 2013, at 00:16, Robert Virding wrote: > Isn't that the best reason NOT to implement it. Kill -extends() instead, it sucks. > > Robert > > From: "Bj?rn Gustavsson" > To: "Anthony Ramine" > Cc: "Erlang-questions" > Sent: Friday, 18 January, 2013 4:57:14 PM > Subject: Re: [erlang-questions] Erlang4Android > > To implement the -extends() attribute that allows the > implementation of a module to be extended by > inheritance. That used to be implemented in the > error_handler. I have removed that code in the same > commit that implements $handle-undefined-function. > > > On Fri, Jan 18, 2013 at 4:36 PM, Anthony Ramine wrote: > Out of curiosity, why? > > -- > Anthony Ramine > > Le 18 janv. 2013 ? 16:25, Bj?rn Gustavsson a ?crit : > > We needed that to implement the parse > transformation for parameterized modules > > > > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From emmiller@REDACTED Sun Jan 20 01:30:02 2013 From: emmiller@REDACTED (Evan Miller) Date: Sat, 19 Jan 2013 18:30:02 -0600 Subject: [erlang-questions] Erlang4Android In-Reply-To: <7AC67CFA-EEF0-4023-8B43-830A55F2D9D3@rogvall.se> References: <1152298455.2921291.1358637401797.JavaMail.root@erlang-solutions.com> <7AC67CFA-EEF0-4023-8B43-830A55F2D9D3@rogvall.se> Message-ID: If folks don't like pmods, -extends(), and error_handler, than ban them from your organization. Why is it so important to people to prevent other developers from using them? I love Erlang, but sometimes I feel oppressed by zealous Puritanism in the community. If you don't like dancing, gambling, and pmods, then don't do them... but that shouldn't stop the rest of us from having a good time. I've found that Pmods are great for writing callback modules where you want some arguments always passed in implicitly. -extends() is great if you have a lot of related callback modules and want to override functionality in some cases but not in others. It's just a way to manage code complexity, and I won't apologize for making use of it. Security and predictability are not the only desiderata in development projects. Sometimes productivity, simplicity, and manageability are more important. It all depends on the situation. I personally look forward to playing around with error_handler to GREATLY simplify code generation in BossDB. I consider it a boon to my productivity, and I think people who don't like it should just look the other way and go about their own business. Evan On Sat, Jan 19, 2013 at 5:33 PM, Tony Rogvall wrote: > I have never used parametrized modules, so I have no clue what you talk > about, > but I think $handle_undefined-function may be very useful. > > I vote for it. :-) > > /Tony > > On 20 jan 2013, at 00:16, Robert Virding < > robert.virding@REDACTED> wrote: > > Isn't that the best reason NOT to implement it. Kill -extends() instead, > it sucks. > > Robert > > ------------------------------ > > *From: *"Bj?rn Gustavsson" > *To: *"Anthony Ramine" > *Cc: *"Erlang-questions" > *Sent: *Friday, 18 January, 2013 4:57:14 PM > *Subject: *Re: [erlang-questions] Erlang4Android > > To implement the -extends() attribute that allows the > implementation of a module to be extended by > inheritance. That used to be implemented in the > error_handler. I have removed that code in the same > commit that implements $handle-undefined-function. > > > On Fri, Jan 18, 2013 at 4:36 PM, Anthony Ramine wrote: > >> Out of curiosity, why? >> >> -- >> Anthony Ramine >> >> Le 18 janv. 2013 ? 16:25, Bj?rn Gustavsson a ?crit : >> >> We needed that to implement the parse >> transformation for parameterized modules >> >> >> > > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > "Installing applications can lead to corruption over time. Applications > gradually write over each other's libraries, partial upgrades occur, user > and system errors happen, and minute changes may be unnoticeable and > difficult to fix" > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Evan Miller http://www.evanmiller.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.charles.davis@REDACTED Sun Jan 20 01:34:47 2013 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sat, 19 Jan 2013 18:34:47 -0600 Subject: [erlang-questions] Erlang averse mentality... Message-ID: <2AE27A42-D1BE-4683-A596-2BCDFD11ECCC@gmail.com> I see this: http://www.infoq.com/presentations/Erlang-Principles-Reliable Why emulate? Why try to do what erlang does already? Why not just do it in erlang? ...people confuse me. /s From g@REDACTED Sun Jan 20 01:52:10 2013 From: g@REDACTED (Garrett Smith) Date: Sat, 19 Jan 2013 18:52:10 -0600 Subject: [erlang-questions] Erlang averse mentality... In-Reply-To: <2AE27A42-D1BE-4683-A596-2BCDFD11ECCC@gmail.com> References: <2AE27A42-D1BE-4683-A596-2BCDFD11ECCC@gmail.com> Message-ID: On Sat, Jan 19, 2013 at 6:34 PM, Steve Davis wrote: > I see this: > > http://www.infoq.com/presentations/Erlang-Principles-Reliable > > Why emulate? Why try to do what erlang does already? Why not just do it in erlang? > > ...people confuse me. I agree. I think *everyone* should watch that presentation to appreciate how much easier things are in Erlang :) And tell their friends! Garrett From essen@REDACTED Sun Jan 20 02:21:18 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Sun, 20 Jan 2013 02:21:18 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: References: <1152298455.2921291.1358637401797.JavaMail.root@erlang-solutions.com> <7AC67CFA-EEF0-4023-8B43-830A55F2D9D3@rogvall.se> Message-ID: <50FB468E.70407@ninenines.eu> You are talking about simplicity, but also saying Pmods are great because of arguments passed implicitly. Isn't implicitness the opposite of simplicity? It requires a lot more knowledge and care to get it working properly. The more implicit things you have in a project, the more its complexity increases, because you have to look around all the time, or remember many things to understand how it works. It makes it harder for newcomers of course, but also for you, because the range of things you can mess up increases. In the case of this catchall function, for example, you increase complexity because you will have to also make sure to handle the calls that you don't want. Before you had one problem: writing proper exported functions. Now you have this additional problem: make sure other calls result in an expected error. Because you have two problems now, that means you can't really pattern match the arguments directly, if the pattern match fails you'll end up throwing an undefined function error when you instead wanted a badarg. And that's just the tip of the iceberg. How does increasing the range in which you can make mistakes improve your productivity? If there's more chances for bugs to happen, then you will have more bugs. How is that more maintainable? You maintain it more, for sure, but I don't think that's the intended effect. The most maintainable code is the one you never need to look at again. Call it puritanism if you want. I call it pragmatism. On 01/20/2013 01:30 AM, Evan Miller wrote: > If folks don't like pmods, -extends(), and error_handler, than ban them > from your organization. Why is it so important to people to prevent > other developers from using them? I love Erlang, but sometimes I feel > oppressed by zealous Puritanism in the community. If you don't like > dancing, gambling, and pmods, then don't do them... but that shouldn't > stop the rest of us from having a good time. > > I've found that Pmods are great for writing callback modules where you > want some arguments always passed in implicitly. -extends() is great if > you have a lot of related callback modules and want to override > functionality in some cases but not in others. It's just a way to manage > code complexity, and I won't apologize for making use of it. Security > and predictability are not the only desiderata in development projects. > Sometimes productivity, simplicity, and manageability are more > important. It all depends on the situation. > > I personally look forward to playing around with error_handler to > GREATLY simplify code generation in BossDB. I consider it a boon to my > productivity, and I think people who don't like it should just look the > other way and go about their own business. > > Evan > > > > > > On Sat, Jan 19, 2013 at 5:33 PM, Tony Rogvall > wrote: > > I have never used parametrized modules, so I have no clue what you > talk about, > but I think $handle_undefined-function may be very useful. > > I vote for it. :-) > > /Tony > > On 20 jan 2013, at 00:16, Robert Virding > > wrote: > >> Isn't that the best reason NOT to implement it. Kill -extends() >> instead, it sucks. >> >> Robert >> >> ------------------------------------------------------------------------ >> >> *From:*"Bj?rn Gustavsson" > > >> *To:*"Anthony Ramine" > > >> *Cc:*"Erlang-questions" > > >> *Sent:*Friday, 18 January, 2013 4:57:14 PM >> *Subject:*Re: [erlang-questions] Erlang4Android >> >> To implement the -extends() attribute that allows the >> implementation of a module to be extended by >> inheritance. That used to be implemented in the >> error_handler. I have removed that code in the same >> commit that implements $handle-undefined-function. >> >> >> On Fri, Jan 18, 2013 at 4:36 PM, Anthony >> Ramine>wrote: >> >> Out of curiosity, why? >> >> -- >> Anthony Ramine >> >> Le 18 janv. 2013 ? 16:25, Bj?rn Gustavsson a ?crit : >> >> We needed that to implement the parse >> transformation for parameterized modules >> >> >> >> >> >> -- >> Bj?rn Gustavsson, Erlang/OTP, Ericsson AB >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > "Installing applications can lead to corruption over time. > Applications gradually write over each other's libraries, partial > upgrades occur, user and system errors happen, and minute changes > may be unnoticeable and difficult to fix" > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > Evan Miller > http://www.evanmiller.org/ > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From g@REDACTED Sun Jan 20 02:46:50 2013 From: g@REDACTED (Garrett Smith) Date: Sat, 19 Jan 2013 19:46:50 -0600 Subject: [erlang-questions] Erlang4Android In-Reply-To: <50FB468E.70407@ninenines.eu> References: <1152298455.2921291.1358637401797.JavaMail.root@erlang-solutions.com> <7AC67CFA-EEF0-4023-8B43-830A55F2D9D3@rogvall.se> <50FB468E.70407@ninenines.eu> Message-ID: Wouldn't it be simpler to just dunk Evan under water and see if he's *actually* a child of Satan? On Sat, Jan 19, 2013 at 7:21 PM, Lo?c Hoguin wrote: > You are talking about simplicity, but also saying Pmods are great because of > arguments passed implicitly. Isn't implicitness the opposite of simplicity? > It requires a lot more knowledge and care to get it working properly. > > The more implicit things you have in a project, the more its complexity > increases, because you have to look around all the time, or remember many > things to understand how it works. It makes it harder for newcomers of > course, but also for you, because the range of things you can mess up > increases. > > In the case of this catchall function, for example, you increase complexity > because you will have to also make sure to handle the calls that you don't > want. Before you had one problem: writing proper exported functions. Now you > have this additional problem: make sure other calls result in an expected > error. Because you have two problems now, that means you can't really > pattern match the arguments directly, if the pattern match fails you'll end > up throwing an undefined function error when you instead wanted a badarg. > And that's just the tip of the iceberg. > > How does increasing the range in which you can make mistakes improve your > productivity? If there's more chances for bugs to happen, then you will have > more bugs. How is that more maintainable? You maintain it more, for sure, > but I don't think that's the intended effect. The most maintainable code is > the one you never need to look at again. > > Call it puritanism if you want. I call it pragmatism. > > > On 01/20/2013 01:30 AM, Evan Miller wrote: >> >> If folks don't like pmods, -extends(), and error_handler, than ban them >> from your organization. Why is it so important to people to prevent >> other developers from using them? I love Erlang, but sometimes I feel >> oppressed by zealous Puritanism in the community. If you don't like >> dancing, gambling, and pmods, then don't do them... but that shouldn't >> stop the rest of us from having a good time. >> >> I've found that Pmods are great for writing callback modules where you >> want some arguments always passed in implicitly. -extends() is great if >> you have a lot of related callback modules and want to override >> functionality in some cases but not in others. It's just a way to manage >> code complexity, and I won't apologize for making use of it. Security >> and predictability are not the only desiderata in development projects. >> Sometimes productivity, simplicity, and manageability are more >> important. It all depends on the situation. >> >> I personally look forward to playing around with error_handler to >> GREATLY simplify code generation in BossDB. I consider it a boon to my >> productivity, and I think people who don't like it should just look the >> other way and go about their own business. >> >> Evan >> >> >> >> >> >> On Sat, Jan 19, 2013 at 5:33 PM, Tony Rogvall > > wrote: >> >> I have never used parametrized modules, so I have no clue what you >> talk about, >> but I think $handle_undefined-function may be very useful. >> >> I vote for it. :-) >> >> /Tony >> >> On 20 jan 2013, at 00:16, Robert Virding >> > > wrote: >> >>> Isn't that the best reason NOT to implement it. Kill -extends() >>> instead, it sucks. >>> >>> Robert >>> >>> >>> ------------------------------------------------------------------------ >>> >>> *From:*"Bj?rn Gustavsson" >> > >>> *To:*"Anthony Ramine" >> > >>> *Cc:*"Erlang-questions" >> > >>> *Sent:*Friday, 18 January, 2013 4:57:14 PM >>> *Subject:*Re: [erlang-questions] Erlang4Android >>> >>> >>> To implement the -extends() attribute that allows the >>> implementation of a module to be extended by >>> inheritance. That used to be implemented in the >>> error_handler. I have removed that code in the same >>> commit that implements $handle-undefined-function. >>> >>> >>> On Fri, Jan 18, 2013 at 4:36 PM, Anthony >>> Ramine>wrote: >>> >>> >>> Out of curiosity, why? >>> >>> -- >>> Anthony Ramine >>> >>> Le 18 janv. 2013 ? 16:25, Bj?rn Gustavsson a ?crit : >>> >>> We needed that to implement the parse >>> transformation for parameterized modules >>> >>> >>> >>> >>> >>> -- >>> Bj?rn Gustavsson, Erlang/OTP, Ericsson AB >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> "Installing applications can lead to corruption over time. >> Applications gradually write over each other's libraries, partial >> upgrades occur, user and system errors happen, and minute changes >> may be unnoticeable and difficult to fix" >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> >> -- >> Evan Miller >> http://www.evanmiller.org/ >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From emmiller@REDACTED Sun Jan 20 03:01:58 2013 From: emmiller@REDACTED (Evan Miller) Date: Sat, 19 Jan 2013 20:01:58 -0600 Subject: [erlang-questions] Erlang4Android In-Reply-To: <50FB468E.70407@ninenines.eu> References: <1152298455.2921291.1358637401797.JavaMail.root@erlang-solutions.com> <7AC67CFA-EEF0-4023-8B43-830A55F2D9D3@rogvall.se> <50FB468E.70407@ninenines.eu> Message-ID: On Sat, Jan 19, 2013 at 7:21 PM, Lo?c Hoguin wrote: > You are talking about simplicity, but also saying Pmods are great because > of arguments passed implicitly. Isn't implicitness the opposite of > simplicity? It requires a lot more knowledge and care to get it working > properly. > > Implicitness is not the opposite of simplicity. "Lust conquered shame, audacity fear, madness reason" -Cicero The verb is implicit in the last two clauses of that sentence, but there is no confusion as to the sentence's meaning, and its style is the epitome of simplicity. Removing the unnecessary verbs enhances one's understanding of the sentence's parallel structure. In a similar way, the parameter list of a pmod reinforces the concept that the module's functions are executed in a similar context. When used with intention, it imparts understanding. The more implicit things you have in a project, the more its complexity > increases, because you have to look around all the time, or remember many > things to understand how it works. It makes it harder for newcomers of > course, but also for you, because the range of things you can mess up > increases. > How do you know this is true 100% of the time? It's not true in my experience, and a Pmod design can make life considerably easier for newcomers in some circumstances. I don't know how you can be confident about sweeping generalizations like these. > > In the case of this catchall function, for example, you increase > complexity because you will have to also make sure to handle the calls that > you don't want. Before you had one problem: writing proper exported > functions. Now you have this additional problem: make sure other calls > result in an expected error. Because you have two problems now, that means > you can't really pattern match the arguments directly, if the pattern match > fails you'll end up throwing an undefined function error when you instead > wanted a badarg. And that's just the tip of the iceberg. > Ok, well they're MY problems, and let me deal with them. I am absolutely certain that I can find applications where the catchall function will let me produce more functionality in less time with fewer bugs. Why do you care if I use something that you consider to be bad style? Why can't I decide for myself if a technique's benefits outweigh the costs? > > How does increasing the range in which you can make mistakes improve your > productivity? If there's more chances for bugs to happen, then you will > have more bugs. How is that more maintainable? You maintain it more, for > sure, but I don't think that's the intended effect. The most maintainable > code is the one you never need to look at again. > The elimination of bugs is not the sole purpose of programming. The purpose is to provide functionality with an acceptable defect rate. My productivity increases because I can provide more functionality in less time by trading security for flexibility. For some projects I use Erlang, for others C, for others Perl. Sometimes maintainability is important, sometimes it's not. Sometimes I'm writing code just for fun and I plan to throw it away! I like having a lot of options, and it's important to me to have the liberty to choose what I think are appropriate design decisions in a given situation. > > Call it puritanism if you want. I call it pragmatism. > > What's pragmatic for you is not necessarily pragmatic for me. Evan > > On 01/20/2013 01:30 AM, Evan Miller wrote: > >> If folks don't like pmods, -extends(), and error_handler, than ban them >> from your organization. Why is it so important to people to prevent >> other developers from using them? I love Erlang, but sometimes I feel >> oppressed by zealous Puritanism in the community. If you don't like >> dancing, gambling, and pmods, then don't do them... but that shouldn't >> stop the rest of us from having a good time. >> >> I've found that Pmods are great for writing callback modules where you >> want some arguments always passed in implicitly. -extends() is great if >> you have a lot of related callback modules and want to override >> functionality in some cases but not in others. It's just a way to manage >> code complexity, and I won't apologize for making use of it. Security >> and predictability are not the only desiderata in development projects. >> Sometimes productivity, simplicity, and manageability are more >> important. It all depends on the situation. >> >> I personally look forward to playing around with error_handler to >> GREATLY simplify code generation in BossDB. I consider it a boon to my >> productivity, and I think people who don't like it should just look the >> other way and go about their own business. >> >> Evan >> >> >> >> >> >> On Sat, Jan 19, 2013 at 5:33 PM, Tony Rogvall > > wrote: >> >> I have never used parametrized modules, so I have no clue what you >> talk about, >> but I think $handle_undefined-function may be very useful. >> >> I vote for it. :-) >> >> /Tony >> >> On 20 jan 2013, at 00:16, Robert Virding >> >> >> >> wrote: >> >> Isn't that the best reason NOT to implement it. Kill -extends() >>> instead, it sucks. >>> >>> Robert >>> >>> ------------------------------**------------------------------** >>> ------------ >>> >>> *From:*"Bj?rn Gustavsson" >> **> >>> >>> *To:*"Anthony Ramine" >> > >>> *Cc:*"Erlang-questions" >> >>> >> >>> *Sent:*Friday, 18 January, 2013 4:57:14 PM >>> *Subject:*Re: [erlang-questions] Erlang4Android >>> >>> >>> To implement the -extends() attribute that allows the >>> implementation of a module to be extended by >>> inheritance. That used to be implemented in the >>> error_handler. I have removed that code in the same >>> commit that implements $handle-undefined-function. >>> >>> >>> On Fri, Jan 18, 2013 at 4:36 PM, Anthony >>> Ramine>**wrote: >>> >>> >>> Out of curiosity, why? >>> >>> -- >>> Anthony Ramine >>> >>> Le 18 janv. 2013 ? 16:25, Bj?rn Gustavsson a ?crit : >>> >>> We needed that to implement the parse >>> transformation for parameterized modules >>> >>> >>> >>> >>> >>> -- >>> Bj?rn Gustavsson, Erlang/OTP, Ericsson AB >>> >>> ______________________________**_________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >> erlang.org > >>> >>> http://erlang.org/mailman/**listinfo/erlang-questions >>> >>> >>> ______________________________**_________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> > >>> http://erlang.org/mailman/**listinfo/erlang-questions >>> >> >> "Installing applications can lead to corruption over time. >> Applications gradually write over each other's libraries, partial >> upgrades occur, user and system errors happen, and minute changes >> may be unnoticeable and difficult to fix" >> >> >> >> >> ______________________________**_________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> > >> >> http://erlang.org/mailman/**listinfo/erlang-questions >> >> >> >> >> -- >> Evan Miller >> http://www.evanmiller.org/ >> >> >> ______________________________**_________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/**listinfo/erlang-questions >> >> > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > -- Evan Miller http://www.evanmiller.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From g@REDACTED Sun Jan 20 03:04:24 2013 From: g@REDACTED (Garrett Smith) Date: Sat, 19 Jan 2013 20:04:24 -0600 Subject: [erlang-questions] Erlang4Android In-Reply-To: References: <1152298455.2921291.1358637401797.JavaMail.root@erlang-solutions.com> <7AC67CFA-EEF0-4023-8B43-830A55F2D9D3@rogvall.se> <50FB468E.70407@ninenines.eu> Message-ID: Apologies, this reference isn't universal and some have asked: http://en.wikipedia.org/wiki/Dunking For the record, and as a Puritan, Evan is not a witch and actually makes an excellent point. Though it would still be fun to dunk him. On Sat, Jan 19, 2013 at 7:46 PM, Garrett Smith wrote: > Wouldn't it be simpler to just dunk Evan under water and see if he's > *actually* a child of Satan? > > On Sat, Jan 19, 2013 at 7:21 PM, Lo?c Hoguin wrote: >> You are talking about simplicity, but also saying Pmods are great because of >> arguments passed implicitly. Isn't implicitness the opposite of simplicity? >> It requires a lot more knowledge and care to get it working properly. >> >> The more implicit things you have in a project, the more its complexity >> increases, because you have to look around all the time, or remember many >> things to understand how it works. It makes it harder for newcomers of >> course, but also for you, because the range of things you can mess up >> increases. >> >> In the case of this catchall function, for example, you increase complexity >> because you will have to also make sure to handle the calls that you don't >> want. Before you had one problem: writing proper exported functions. Now you >> have this additional problem: make sure other calls result in an expected >> error. Because you have two problems now, that means you can't really >> pattern match the arguments directly, if the pattern match fails you'll end >> up throwing an undefined function error when you instead wanted a badarg. >> And that's just the tip of the iceberg. >> >> How does increasing the range in which you can make mistakes improve your >> productivity? If there's more chances for bugs to happen, then you will have >> more bugs. How is that more maintainable? You maintain it more, for sure, >> but I don't think that's the intended effect. The most maintainable code is >> the one you never need to look at again. >> >> Call it puritanism if you want. I call it pragmatism. >> >> >> On 01/20/2013 01:30 AM, Evan Miller wrote: >>> >>> If folks don't like pmods, -extends(), and error_handler, than ban them >>> from your organization. Why is it so important to people to prevent >>> other developers from using them? I love Erlang, but sometimes I feel >>> oppressed by zealous Puritanism in the community. If you don't like >>> dancing, gambling, and pmods, then don't do them... but that shouldn't >>> stop the rest of us from having a good time. >>> >>> I've found that Pmods are great for writing callback modules where you >>> want some arguments always passed in implicitly. -extends() is great if >>> you have a lot of related callback modules and want to override >>> functionality in some cases but not in others. It's just a way to manage >>> code complexity, and I won't apologize for making use of it. Security >>> and predictability are not the only desiderata in development projects. >>> Sometimes productivity, simplicity, and manageability are more >>> important. It all depends on the situation. >>> >>> I personally look forward to playing around with error_handler to >>> GREATLY simplify code generation in BossDB. I consider it a boon to my >>> productivity, and I think people who don't like it should just look the >>> other way and go about their own business. >>> >>> Evan >>> >>> >>> >>> >>> >>> On Sat, Jan 19, 2013 at 5:33 PM, Tony Rogvall >> > wrote: >>> >>> I have never used parametrized modules, so I have no clue what you >>> talk about, >>> but I think $handle_undefined-function may be very useful. >>> >>> I vote for it. :-) >>> >>> /Tony >>> >>> On 20 jan 2013, at 00:16, Robert Virding >>> >> > wrote: >>> >>>> Isn't that the best reason NOT to implement it. Kill -extends() >>>> instead, it sucks. >>>> >>>> Robert >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> *From:*"Bj?rn Gustavsson" >>> > >>>> *To:*"Anthony Ramine" >>> > >>>> *Cc:*"Erlang-questions" >>> > >>>> *Sent:*Friday, 18 January, 2013 4:57:14 PM >>>> *Subject:*Re: [erlang-questions] Erlang4Android >>>> >>>> >>>> To implement the -extends() attribute that allows the >>>> implementation of a module to be extended by >>>> inheritance. That used to be implemented in the >>>> error_handler. I have removed that code in the same >>>> commit that implements $handle-undefined-function. >>>> >>>> >>>> On Fri, Jan 18, 2013 at 4:36 PM, Anthony >>>> Ramine>wrote: >>>> >>>> >>>> Out of curiosity, why? >>>> >>>> -- >>>> Anthony Ramine >>>> >>>> Le 18 janv. 2013 ? 16:25, Bj?rn Gustavsson a ?crit : >>>> >>>> We needed that to implement the parse >>>> transformation for parameterized modules >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Bj?rn Gustavsson, Erlang/OTP, Ericsson AB >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >>> "Installing applications can lead to corruption over time. >>> Applications gradually write over each other's libraries, partial >>> upgrades occur, user and system errors happen, and minute changes >>> may be unnoticeable and difficult to fix" >>> >>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >>> >>> >>> -- >>> Evan Miller >>> http://www.evanmiller.org/ >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> >> -- >> Lo?c Hoguin >> Erlang Cowboy >> Nine Nines >> http://ninenines.eu >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions From freza@REDACTED Sun Jan 20 04:35:21 2013 From: freza@REDACTED (Jachym Holecek) Date: Sat, 19 Jan 2013 22:35:21 -0500 Subject: [erlang-questions] Erlang4Android In-Reply-To: References: <50F313AE.8050303@ernovation.com> <50F464D6.9030700@ernovation.com> <50F54CA3.8030302@ernovation.com> <50F96F49.1030006@ninenines.eu> Message-ID: <20130120033521.GA26273@circlewave.net> # Tony Rogvall 2013-01-19: > And ... well the list can be extended with some creativity. Oh yes, creativity... because fixing issues in live systems composed of say 50-100kLOC just isn't enough fun when all you've got to work with is some monitoring data and business logic expressed in fairly straightforward code. Let's make life more interesting right now, pretty please! The more layers of indirection: the better! Or here's a truly creative one: why not divorce apparent structure of source code from its meaning altogether? ;-) BR, -- Jachym From ulf@REDACTED Sun Jan 20 08:58:46 2013 From: ulf@REDACTED (Ulf Wiger) Date: Sun, 20 Jan 2013 08:58:46 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: <1152298455.2921291.1358637401797.JavaMail.root@erlang-solutions.com> References: <1152298455.2921291.1358637401797.JavaMail.root@erlang-solutions.com> Message-ID: <5DF36329-BB19-40F9-8E39-81307125229B@feuerlabs.com> So... the error_handler is central in the implementation of a much-lauded (albeit not unique) function in Erlang - on-demand code loading. People have been asked not to mess with it, since (a) it's subtle, and (b) it has global scope. Now we have a chance to address (b). The behavior of this function can aready be tweaked, using the -mode parameter. Are we content that this covers all worthy uses? BR, Ulf W Whether Evan is or is not a witch, the practice of burning them at the stake has long since been abandoned. ;-) Ulf Wiger, Feuerlabs, Inc. http://www.feuerlabs.com 20 jan 2013 kl. 00:16 skrev Robert Virding : > Isn't that the best reason NOT to implement it. Kill -extends() instead, it sucks. > > Robert > > From: "Bj?rn Gustavsson" > To: "Anthony Ramine" > Cc: "Erlang-questions" > Sent: Friday, 18 January, 2013 4:57:14 PM > Subject: Re: [erlang-questions] Erlang4Android > > To implement the -extends() attribute that allows the > implementation of a module to be extended by > inheritance. That used to be implemented in the > error_handler. I have removed that code in the same > commit that implements $handle-undefined-function. > > > On Fri, Jan 18, 2013 at 4:36 PM, Anthony Ramine wrote: >> Out of curiosity, why? >> >> -- >> Anthony Ramine >> >> Le 18 janv. 2013 ? 16:25, Bj?rn Gustavsson a ?crit : >> >> We needed that to implement the parse >> transformation for parameterized modules > > > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > > _______________________________________________ > erlang-questions mailing list > 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 desired.mta@REDACTED Sun Jan 20 11:31:44 2013 From: desired.mta@REDACTED (=?UTF-8?Q?Motiejus_Jak=C5=A1tys?=) Date: Sun, 20 Jan 2013 10:31:44 +0000 Subject: [erlang-questions] -mode directive (was: Erlang4Android) Message-ID: On Sun, Jan 20, 2013 at 7:58 AM, Ulf Wiger wrote: > The behavior of this function can aready be tweaked, using the -mode > parameter. Huh, I've never heard about this before, and neither my favorite search engine nor OTP sources seem to be very helpful: otp$ git grep -- ^-mode erts/doc/src/escript.xml:-mode(compile). erts/emulator/utils/count:-mode(compile). erts/emulator/utils/loaded:-mode(compile). erts/lib_src/utils/make_atomics_api:-mode(compile). lib/diameter/bin/diameterc:-mode(compile). lib/reltool/examples/mnesia_core_dump_viewer:-mode(compile). lib/snmp/src/compile/snmpc.src:-mode(compile). lib/stdlib/test/escript_SUITE_data/factorial_compile:-mode(compile). lib/stdlib/test/escript_SUITE_data/factorial_compile_main:-mode(compile). lib/stdlib/test/escript_SUITE_data/strange.name:-mode(compile). lib/stdlib/test/escript_SUITE_data/tail_rec:-mode(interpret). make/emd2exml.in:-mode(compile). What does that mean? -- Motiejus Jak?tys From desired.mta@REDACTED Sun Jan 20 11:34:33 2013 From: desired.mta@REDACTED (=?UTF-8?Q?Motiejus_Jak=C5=A1tys?=) Date: Sun, 20 Jan 2013 10:34:33 +0000 Subject: [erlang-questions] -mode directive (was: Erlang4Android) In-Reply-To: References: Message-ID: Oops, I missed the first match in OTP sources... it's explained in that file. Never mind, thank you. :-) On Sun, Jan 20, 2013 at 10:31 AM, Motiejus Jak?tys wrote: > On Sun, Jan 20, 2013 at 7:58 AM, Ulf Wiger wrote: > otp$ git grep -- ^-mode > erts/doc/src/escript.xml:-mode(compile). -- Motiejus Jak?tys From essen@REDACTED Sun Jan 20 12:37:08 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Sun, 20 Jan 2013 12:37:08 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: References: <1152298455.2921291.1358637401797.JavaMail.root@erlang-solutions.com> <7AC67CFA-EEF0-4023-8B43-830A55F2D9D3@rogvall.se> <50FB468E.70407@ninenines.eu> Message-ID: <50FBD6E4.9060502@ninenines.eu> On 01/20/2013 03:01 AM, Evan Miller wrote: > On Sat, Jan 19, 2013 at 7:21 PM, Lo?c Hoguin > wrote: > > You are talking about simplicity, but also saying Pmods are great > because of arguments passed implicitly. Isn't implicitness the > opposite of simplicity? It requires a lot more knowledge and care to > get it working properly. > > > Implicitness is not the opposite of simplicity. > > "Lust conquered shame, audacity fear, madness reason" -Cicero > > The verb is implicit in the last two clauses of that sentence, but there > is no confusion as to the sentence's meaning, and its style is the > epitome of simplicity. Removing the unnecessary verbs enhances one's > understanding of the sentence's parallel structure. In a similar way, > the parameter list of a pmod reinforces the concept that the module's > functions are executed in a similar context. When used with intention, > it imparts understanding. No! It helps understanding only when you read the full sentence. If you arrive in the middle of the sentence, you cannot understand anything that is said. When reading code you rarely read the whole module, only fragments, and if some of them are implicitly in other modules, or implicitly handled by a catchall, then good luck understanding it. > The more implicit things you have in a project, the more its > complexity increases, because you have to look around all the time, > or remember many things to understand how it works. It makes it > harder for newcomers of course, but also for you, because the range > of things you can mess up increases. > > > How do you know this is true 100% of the time? It's not true in my > experience, and a Pmod design can make life considerably easier for > newcomers in some circumstances. I don't know how you can be confident > about sweeping generalizations like these. Pmods are confusing. They break expectations. First you learn that: Module = my_module, Module:some_function(). will call my_module:some_function(). Pmods though: Pmod = {my_module, blabla}, Pmod:some_function(). will call my_module:some_function({my_module, blabla}). WTF? How is that supposed to be simple if a) it's completely different to your initial expectations and b) is resolved dynamically, which can allow for errors like: Pmod = {ok, {my_module, blabla}}, Pmod:some_function(). and now you call ok:some_function({ok,...}) instead. But this is more of an issue of tuple calls, not parameterized modules, which I probably wouldn't mind if they didn't break expectations in this way. So perhaps this implementation of Pmods make the easy cases easier, but they sure make harder things harder. > In the case of this catchall function, for example, you increase > complexity because you will have to also make sure to handle the > calls that you don't want. Before you had one problem: writing > proper exported functions. Now you have this additional problem: > make sure other calls result in an expected error. Because you have > two problems now, that means you can't really pattern match the > arguments directly, if the pattern match fails you'll end up > throwing an undefined function error when you instead wanted a > badarg. And that's just the tip of the iceberg. > > > Ok, well they're MY problems, and let me deal with them. I am absolutely > certain that I can find applications where the catchall function will > let me produce more functionality in less time with fewer bugs. Why do > you care if I use something that you consider to be bad style? Why can't > I decide for myself if a technique's benefits outweigh the costs? It's not about you. It's about trying to prevent insane features from getting into the language. And this above is some of the reasons why. > How does increasing the range in which you can make mistakes improve > your productivity? If there's more chances for bugs to happen, then > you will have more bugs. How is that more maintainable? You maintain > it more, for sure, but I don't think that's the intended effect. The > most maintainable code is the one you never need to look at again. > > > The elimination of bugs is not the sole purpose of programming. The > purpose is to provide functionality with an acceptable defect rate. My > productivity increases because I can provide more functionality in less > time by trading security for flexibility. For some projects I use > Erlang, for others C, for others Perl. Sometimes maintainability is > important, sometimes it's not. Sometimes I'm writing code just for fun > and I plan to throw it away! I like having a lot of options, and it's > important to me to have the liberty to choose what I think are > appropriate design decisions in a given situation. The elimination of bugs isn't the sole purpose of programming, indeed. But I'm pretty sure adding ways to hang yourself with isn't the purpose of programming either. And again I'm not against this feature per se, I only talked about the *implementation*. This implementation is bad, IMHO. And I'm well allowed to say it. > Call it puritanism if you want. I call it pragmatism. > > > What's pragmatic for you is not necessarily pragmatic for me. > > Evan > > > On 01/20/2013 01:30 AM, Evan Miller wrote: > > If folks don't like pmods, -extends(), and error_handler, than > ban them > from your organization. Why is it so important to people to prevent > other developers from using them? I love Erlang, but sometimes I > feel > oppressed by zealous Puritanism in the community. If you don't like > dancing, gambling, and pmods, then don't do them... but that > shouldn't > stop the rest of us from having a good time. > > I've found that Pmods are great for writing callback modules > where you > want some arguments always passed in implicitly. -extends() is > great if > you have a lot of related callback modules and want to override > functionality in some cases but not in others. It's just a way > to manage > code complexity, and I won't apologize for making use of it. > Security > and predictability are not the only desiderata in development > projects. > Sometimes productivity, simplicity, and manageability are more > important. It all depends on the situation. > > I personally look forward to playing around with error_handler to > GREATLY simplify code generation in BossDB. I consider it a boon > to my > productivity, and I think people who don't like it should just > look the > other way and go about their own business. > > Evan > > > > > > On Sat, Jan 19, 2013 at 5:33 PM, Tony Rogvall > >> wrote: > > I have never used parametrized modules, so I have no clue > what you > talk about, > but I think $handle_undefined-function may be very useful. > > I vote for it. :-) > > /Tony > > On 20 jan 2013, at 00:16, Robert Virding > > >> wrote: > > Isn't that the best reason NOT to implement it. Kill > -extends() > instead, it sucks. > > Robert > > > ------------------------------__------------------------------__------------ > > *From:*"Bj?rn Gustavsson" > >__> > > *To:*"Anthony Ramine" > >> > *Cc:*"Erlang-questions" > > >> > *Sent:*Friday, 18 January, 2013 4:57:14 PM > *Subject:*Re: [erlang-questions] Erlang4Android > > > To implement the -extends() attribute that allows the > implementation of a module to be extended by > inheritance. That used to be implemented in the > error_handler. I have removed that code in the same > commit that implements $handle-undefined-function. > > > On Fri, Jan 18, 2013 at 4:36 PM, Anthony > Ramine > >>__wrote: > > > Out of curiosity, why? > > -- > Anthony Ramine > > Le 18 janv. 2013 ? 16:25, Bj?rn Gustavsson a > ?crit : > > We needed that to implement the parse > transformation for parameterized modules > > > > > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > > _________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > > > > > http://erlang.org/mailman/__listinfo/erlang-questions > > > > _________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > > > > http://erlang.org/mailman/__listinfo/erlang-questions > > > > "Installing applications can lead to corruption over time. > Applications gradually write over each other's libraries, > partial > upgrades occur, user and system errors happen, and minute > changes > may be unnoticeable and difficult to fix" > > > > > _________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > > > > http://erlang.org/mailman/__listinfo/erlang-questions > > > > > > -- > Evan Miller > http://www.evanmiller.org/ > > > _________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/__listinfo/erlang-questions > > > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > > > > > -- > Evan Miller > http://www.evanmiller.org/ -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From ulf@REDACTED Sun Jan 20 14:58:20 2013 From: ulf@REDACTED (Ulf Wiger) Date: Sun, 20 Jan 2013 14:58:20 +0100 Subject: [erlang-questions] -mode directive (was: Erlang4Android) In-Reply-To: References: Message-ID: Sorry for being overly brief, due to mailing from my phone. I was referring to the possibility to add the command-line option -mode embedded, and turn off on-demand code loading. Strictly speaking, this parameter is checked by the code_server and not the error_handler, but since the error_handler triggers on-demand code loading, I felt it was relevant. BR, Ulf Ulf Wiger, Feuerlabs, Inc. http://www.feuerlabs.com 20 jan 2013 kl. 11:34 skrev Motiejus Jak?tys : > Oops, I missed the first match in OTP sources... it's explained in > that file. Never mind, thank you. :-) > > On Sun, Jan 20, 2013 at 10:31 AM, Motiejus Jak?tys > wrote: >> On Sun, Jan 20, 2013 at 7:58 AM, Ulf Wiger wrote: >> otp$ git grep -- ^-mode >> erts/doc/src/escript.xml:-mode(compile). > > -- > Motiejus Jak?tys From ward@REDACTED Sun Jan 20 21:17:31 2013 From: ward@REDACTED (Ward Bekker (TTY)) Date: Sun, 20 Jan 2013 21:17:31 +0100 Subject: [erlang-questions] Quick connect to another node with erl Message-ID: <29954670-7D8E-4F94-8547-E7A2D7C3984B@tty.nl> Hi, I want to connect to the shell on node bar@REDACTED My current solution (see below) needs some user switch commands. Is there a way using CL arguments? Couldn't find a mention in the erl man page. Thx, Ward ---------- localhost ward$ erl -sname foo Erlang R15B02 (erts-5.9.2) [source] [64-bit] [smp:2:2] [async-threads:0] [hipe] [kernel-poll:false] [dtrace] Eshell V5.9.2 (abort with ^G) (foo@REDACTED)1> net_adm:ping(bar@REDACTED). pong (foo@REDACTED)2> User switch command --> r bar@REDACTED --> c Eshell V5.9.2 (abort with ^G) (bar@REDACTED)1> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ward@REDACTED Sun Jan 20 21:21:36 2013 From: ward@REDACTED (Ward Bekker (TTY)) Date: Sun, 20 Jan 2013 21:21:36 +0100 Subject: [erlang-questions] Quick connect to another node with erl In-Reply-To: <29954670-7D8E-4F94-8547-E7A2D7C3984B@tty.nl> References: <29954670-7D8E-4F94-8547-E7A2D7C3984B@tty.nl> Message-ID: <11013667-7C5A-4F15-A687-E6B7105B7AF3@tty.nl> Nevermind. Just found `remsh` ;-) /W On 20 jan. 2013, at 21:17, Ward Bekker (TTY) wrote: > Hi, > > I want to connect to the shell on node bar@REDACTED My current solution (see below) needs some user switch commands. Is there a way using CL arguments? Couldn't find a mention in the erl man page. > > Thx, > > Ward > > ---------- > > localhost ward$ erl -sname foo > Erlang R15B02 (erts-5.9.2) [source] [64-bit] [smp:2:2] [async-threads:0] [hipe] [kernel-poll:false] [dtrace] > > Eshell V5.9.2 (abort with ^G) > (foo@REDACTED)1> net_adm:ping(bar@REDACTED). > pong > (foo@REDACTED)2> > User switch command > --> r bar@REDACTED > --> c > Eshell V5.9.2 (abort with ^G) > (bar@REDACTED)1> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From freza@REDACTED Sun Jan 20 21:16:20 2013 From: freza@REDACTED (Jachym Holecek) Date: Sun, 20 Jan 2013 15:16:20 -0500 Subject: [erlang-questions] Quick connect to another node with erl In-Reply-To: <29954670-7D8E-4F94-8547-E7A2D7C3984B@tty.nl> References: <29954670-7D8E-4F94-8547-E7A2D7C3984B@tty.nl> Message-ID: <20130120201620.GA15728@circlewave.net> # Ward Bekker (TTY) 2013-01-20: > I want to connect to the shell on node bar@REDACTED My current solution > (see below) needs some user switch commands. Is there a way using CL > arguments? Couldn't find a mention in the erl man page. Yes, using -remsh, like this: Terminal 1: # erl -sname foo -setcookie abc Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [kernel-poll:false] Eshell V5.8.5 (abort with ^G) (foo@REDACTED)1> Terminal 2: # erl -sname bar -setcookie abc -remsh foo@REDACTED Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [kernel-poll:false] Eshell V5.8.5 (abort with ^G) (foo@REDACTED)1> node(). foo@REDACTED (foo@REDACTED)2> nodes(). [bar@REDACTED] (foo@REDACTED)3> BR, -- Jachym From ok@REDACTED Mon Jan 21 06:25:07 2013 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 21 Jan 2013 18:25:07 +1300 Subject: [erlang-questions] Erlang4Android In-Reply-To: References: <1152298455.2921291.1358637401797.JavaMail.root@erlang-solutions.com> <7AC67CFA-EEF0-4023-8B43-830A55F2D9D3@rogvall.se> Message-ID: <647C5F74-6BE1-43CE-BF77-AE307F009BE6@cs.otago.ac.nz> On 20/01/2013, at 1:30 PM, Evan Miller wrote: > If folks don't like pmods, -extends(), and error_handler, than ban them from your organization. How, exactly? I'm reminded of what we used to be told about PL/I: sure it's a complicated language with all sorts of traps for young players but if you don't use them they won't hurt you. Problem is, you could use them by accident. Now parameterised modules could not be used by accident, but the *implementation* of them could, and that hurts everyone. -extends is pretty much a solution in search of a problem (there's not much you can do that way you can't do with -include and a little thought); you can't use it by accident, but that doesn't mean you can't run into the *implementation* of it by accident. And again with the error handler: error handling machinery always limits the freedom of compilers to transform your programs because they have to be able to (re)construct the information the error handler is expecting to see. If you can tell me the erlc command line switch that will banish parameterised modules, extends, and explicit use of the error_handler, I shall be very happy to use it. > Why is it so important to people to prevent other developers from using them? Because there is no feature that is not a limitation on something else. TANSTAAFL. > I love Erlang, but sometimes I feel oppressed by zealous Puritanism in the community. It's not Puritanism. People distrust these things each for their own feature-specific reasons, not simply because they are features. Let me quote Oliver Cromwell: consider it *possible* that you *may* be wrong. What *good* reasons might people who disagree with you about these features have? Let's take one example from the past. Way back when I was still at RMIT I was doing some work on trying to derive properties of functions. Not a type system as such, but an effects system. At that time, Erlang didn't have anonymous functions. Then *pow*, suddenly it did. And all my work became so much junk. Yes, anonymous functions are a very handy feature, BUT they were ALSO a huge limitation on what I could easily discover. This was work that *would* have allowed user-defined functions in guards. If anyone had been interested in my opinion back then, I would have pressed for an extended version of list comprehensions in preference to anonymous functions, because I could have analysed that. As for parameterised modules, I've wanted module parameters for a long time for something else entirely: automatic logic-programming-style configuration. Maybe nobody else wants that; my point is that we cannot have BOTH. There is not feature that is not a limitation. I have written enough OO code in enough languages to be painfully aware that -extends, whatever its merits, makes code significantly less readable and quite a bit harder to maintain. (See "Fragile base class problem.") There comes a point where throwing new features at a language is a bad idea and it's time to stop and redesign from the beginning, possibly keeping the VM backwards compatible. Java is pretty much at the point where there are enough good ideas to make a coherent usable language but that language would not be Java. From zerthurd@REDACTED Mon Jan 21 06:38:45 2013 From: zerthurd@REDACTED (Maxim Treskin) Date: Mon, 21 Jan 2013 12:38:45 +0700 Subject: [erlang-questions] Distribution protocol error Message-ID: Hello I write implementation of Erlang Distribution Protocol for Go: https://github.com/metachord/eclus/blob/dist/src/erlang/node/node.go https://github.com/metachord/eclus/blob/dist/src/erlang/node/gen_server.go Now this implementation can publish its port via epmd (or other daemon, like eclus), establish incoming connection from Erlang node, parse messages, pass them to registered or not registered goroutines on local node. But I cannot send message to remote node while it seems all is ok: Incoming call to `net_kernel` process: 2013/01/21 12:24:31 NET_KERNEL: HandleCall: term.Tuple{"is_auth", "asd@REDACTED"}, From: term.Tuple{term.Pid{Node:"asd@REDACTED", Id:0x26, Serial:0x0, Creation:0x1}, term.Reference{Node:"asd@REDACTED", Creation:0x1, Id:[]uint32{0x32, 0x0, 0x0}}} Process replied (atom 'yes'): 2013/01/21 12:24:31 Send: term.Pid{Node:"asd@REDACTED", Id:0x26, Serial:0x0, Creation:0x1}, term.Tuple{term.Reference{Node:"asd@REDACTED", Creation:0x1, Id:[]uint32{0x32, 0x0, 0x0}}, "yes"} Find connection with node 'asd@REDACTED' and send data to this connection: 2013/01/21 12:24:31 Send to remote node: term.Pid{Node:"asd@REDACTED", Id:0x26, Serial:0x0, Creation:0x1}, node.nodeConn{conn:(*net.TCPConn)(0x18745858), wchan:(chan []term.Term)(0x18799000)} Write terms to socket: 2013/01/21 12:24:31 WRITE: []term.Term{term.Tuple{2, "", term.Pid{Node:"asd@REDACTED", Id:0x26, Serial:0x0, Creation:0x1}}, term.Tuple{term.Reference{Node:"asd@REDACTED", Creation:0x1, Id:[]uint32{0x32, 0x0, 0x0}}, "yes"}}: []byte{0x70, 0x83, 0x68, 0x3, 0x61, 0x2, 0x64, 0x0, 0x0, 0x64, 0x0, 0xd, 0x61, 0x73, 0x64, 0x40, 0x6c, 0x6f, 0x63, 0x61, 0x6c, 0x68, 0x6f, 0x73, 0x74, 0x0, 0x0, 0x0, 0x26, 0x0, 0x0, 0x0, 0x0, 0x1, 0x83, 0x68, 0x2, 0x64, 0x0, 0xd, 0x61, 0x73, 0x64, 0x40, 0x6c, 0x6f, 0x63, 0x61, 0x6c, 0x68, 0x6f, 0x73, 0x74, 0x1, 0x0, 0x0, 0x0, 0x32, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x64, 0x0, 0x3, 0x79, 0x65, 0x73} Raw bytes written: 2013/01/21 12:24:31 Write to enode: [0 0 0 72 112 131 104 3 97 2 100 0 0 100 0 13 97 115 100 64 108 111 99 97 108 104 111 115 116 0 0 0 38 0 0 0 0 1 131 104 2 100 0 13 97 115 100 64 108 111 99 97 108 104 111 115 116 1 0 0 0 50 0 0 0 0 0 0 0 0 100 0 3 121 101 115] But on 'asd@REDACTED' node i see: =ERROR REPORT==== 21-Jan-2013::12:24:31 === Invalid distribution message: {2,'','asd@REDACTED'} Can you help me? File erts/emulator/beam/dist.c contains many goto to label invalid_message, which prints this message, so I cannot find real matched clause for this case. Thank you -- Max Treskin -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignatovs@REDACTED Mon Jan 21 08:29:25 2013 From: ignatovs@REDACTED (Sergey Ignatov) Date: Mon, 21 Jan 2013 11:29:25 +0400 Subject: [erlang-questions] [ANN] Erlang plugin for IntelliJ IDEA version 0.4 Message-ID: Hi all, Today I'm happy to announce the new version of Erlang plugin for IntelliJ IDEA. The new version is the biggest improvement of our project. The highlight of the new version: - Rebar run configurations (also includes Rebar-based Eunit integration) - Erlang types support - External and local documentation for OTP functions and modules - Function parameter info context help - Upgraded structure view (shows exported and inner functions) - Go to action for all Erlang definitions - Improved BIFs completion - And many others, please check out release notes: https://github.com/ignatov/intellij-erlang#version-04 Plugin page in IntelliJ repository: http://plugins.jetbrains.com/plugin/?pluginId=7083 Source code: https://github.com/ignatov/intellij-erlang If you are interesting in this plugin, feel free to use the issue tracker: https://github.com/ignatov/intellij-erlang/issues Stay tuned. Cheers, Sergey Ignatov From bourinov@REDACTED Mon Jan 21 09:21:15 2013 From: bourinov@REDACTED (Max Bourinov) Date: Mon, 21 Jan 2013 12:21:15 +0400 Subject: [erlang-questions] [ANN] Erlang plugin for IntelliJ IDEA version 0.4 In-Reply-To: References: Message-ID: Hi Sergey, I just tried your plugin and it looks very promising. I will give it a try in my next project. Thank you for your work! p.s.: I am myself used to use idea from 2004, but last year switched to Sublime Text 2. Best regards, Max On Mon, Jan 21, 2013 at 11:29 AM, Sergey Ignatov wrote: > Hi all, > > Today I'm happy to announce the new version of Erlang plugin for > IntelliJ IDEA. The new version is the biggest improvement of our > project. > > The highlight of the new version: > - Rebar run configurations (also includes Rebar-based Eunit integration) > - Erlang types support > - External and local documentation for OTP functions and modules > - Function parameter info context help > - Upgraded structure view (shows exported and inner functions) > - Go to action for all Erlang definitions > - Improved BIFs completion > - And many others, please check out release notes: > https://github.com/ignatov/intellij-erlang#version-04 > > Plugin page in IntelliJ repository: > http://plugins.jetbrains.com/plugin/?pluginId=7083 > Source code: https://github.com/ignatov/intellij-erlang > > If you are interesting in this plugin, feel free to use the issue > tracker: https://github.com/ignatov/intellij-erlang/issues > > Stay tuned. > > Cheers, > Sergey Ignatov > _______________________________________________ > 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 Mon Jan 21 12:20:34 2013 From: davidnwelton@REDACTED (David Welton) Date: Mon, 21 Jan 2013 12:20:34 +0100 Subject: [erlang-questions] Erlang averse mentality... In-Reply-To: <2AE27A42-D1BE-4683-A596-2BCDFD11ECCC@gmail.com> References: <2AE27A42-D1BE-4683-A596-2BCDFD11ECCC@gmail.com> Message-ID: > I see this: > > http://www.infoq.com/presentations/Erlang-Principles-Reliable > > Why emulate? Why try to do what erlang does already? Why not just do it in erlang? > ...people confuse me. Finding out those answers is a great way of learning more about economics and other squishy "human" issues that are much more important to programming than we might think they are. After all, the computer does not really care what language you are using - the language is for humans. It turns out that most people are probably more rational than we sometimes give them credit for. -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From zerthurd@REDACTED Mon Jan 21 12:35:45 2013 From: zerthurd@REDACTED (Maxim Treskin) Date: Mon, 21 Jan 2013 18:35:45 +0700 Subject: [erlang-questions] Distribution protocol error In-Reply-To: References: Message-ID: Just error in Pid and Reference serialization. Now I have `pong` reply :) On 21 January 2013 12:38, Maxim Treskin wrote: > Hello > > I write implementation of Erlang Distribution Protocol for Go: > https://github.com/metachord/eclus/blob/dist/src/erlang/node/node.go > https://github.com/metachord/eclus/blob/dist/src/erlang/node/gen_server.go > > Now this implementation can publish its port via epmd (or other daemon, > like eclus), establish incoming connection from Erlang node, parse > messages, pass them to registered or not registered goroutines on local > node. But I cannot send message to remote node while it seems all is ok: > > Incoming call to `net_kernel` process: > > 2013/01/21 12:24:31 NET_KERNEL: HandleCall: term.Tuple{"is_auth", > "asd@REDACTED"}, From: term.Tuple{term.Pid{Node:"asd@REDACTED", > Id:0x26, Serial:0x0, Creation:0x1}, term.Reference{Node:"asd@REDACTED", > Creation:0x1, Id:[]uint32{0x32, 0x0, 0x0}}} > > > Process replied (atom 'yes'): > > 2013/01/21 12:24:31 Send: term.Pid{Node:"asd@REDACTED", Id:0x26, > Serial:0x0, Creation:0x1}, term.Tuple{term.Reference{Node:"asd@REDACTED", > Creation:0x1, Id:[]uint32{0x32, 0x0, 0x0}}, "yes"} > > > Find connection with node 'asd@REDACTED' and send data to this > connection: > > 2013/01/21 12:24:31 Send to remote node: term.Pid{Node:"asd@REDACTED", > Id:0x26, Serial:0x0, Creation:0x1}, > node.nodeConn{conn:(*net.TCPConn)(0x18745858), wchan:(chan > []term.Term)(0x18799000)} > > Write terms to socket: > > 2013/01/21 12:24:31 WRITE: []term.Term{term.Tuple{2, "", > term.Pid{Node:"asd@REDACTED", Id:0x26, Serial:0x0, Creation:0x1}}, > term.Tuple{term.Reference{Node:"asd@REDACTED", Creation:0x1, > Id:[]uint32{0x32, 0x0, 0x0}}, "yes"}}: []byte{0x70, 0x83, 0x68, 0x3, 0x61, > 0x2, 0x64, 0x0, 0x0, 0x64, 0x0, 0xd, 0x61, 0x73, 0x64, 0x40, 0x6c, 0x6f, > 0x63, 0x61, 0x6c, 0x68, 0x6f, 0x73, 0x74, 0x0, 0x0, 0x0, 0x26, 0x0, 0x0, > 0x0, 0x0, 0x1, 0x83, 0x68, 0x2, 0x64, 0x0, 0xd, 0x61, 0x73, 0x64, 0x40, > 0x6c, 0x6f, 0x63, 0x61, 0x6c, 0x68, 0x6f, 0x73, 0x74, 0x1, 0x0, 0x0, 0x0, > 0x32, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x64, 0x0, 0x3, 0x79, 0x65, > 0x73} > > > Raw bytes written: > > 2013/01/21 12:24:31 Write to enode: > [0 0 0 72 112 > 131 104 3 97 2 100 0 0 100 0 13 97 115 100 64 108 111 99 97 108 104 > 111 115 116 0 0 0 38 0 0 0 0 1 > 131 104 2 100 0 13 97 115 100 64 108 111 99 97 108 104 111 115 116 1 0 > 0 0 50 0 0 0 0 0 0 0 0 100 0 3 121 101 115] > > But on 'asd@REDACTED' node i see: > > =ERROR REPORT==== 21-Jan-2013::12:24:31 === > Invalid distribution message: {2,'','asd@REDACTED'} > > > Can you help me? File erts/emulator/beam/dist.c contains many goto to > label invalid_message, which prints this message, so I cannot find real > matched clause for this case. > > Thank you > > -- > Max Treskin > -- Max Treskin -------------- next part -------------- An HTML attachment was scrubbed... URL: From fly@REDACTED Mon Jan 21 12:47:46 2013 From: fly@REDACTED (Fred Youhanaie) Date: Mon, 21 Jan 2013 11:47:46 +0000 Subject: [erlang-questions] Erlang averse mentality... In-Reply-To: References: <2AE27A42-D1BE-4683-A596-2BCDFD11ECCC@gmail.com> Message-ID: <50FD2AE2.7010801@anydata.co.uk> On 20/01/13 00:52, Garrett Smith wrote: > On Sat, Jan 19, 2013 at 6:34 PM, Steve Davis > wrote: >> I see this: >> >> http://www.infoq.com/presentations/Erlang-Principles-Reliable >> >> Why emulate? Why try to do what erlang does already? Why not just do it in erlang? >> >> ...people confuse me. > > I agree. I think *everyone* should watch that presentation to > appreciate how much easier things are in Erlang :) > > And tell their friends! > > Garrett This sounds interesting. Is it available to those who are not registered with infoq? Cheers Fred From essen@REDACTED Mon Jan 21 19:04:50 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Mon, 21 Jan 2013 19:04:50 +0100 Subject: [erlang-questions] Improve $handle_undefined_function Message-ID: <50FD8342.8030100@ninenines.eu> Hello, Just recently the $handle_undefined_function feature was introduced. It is a way to override error_handler mechanisms when a function isn't found, and works per module for all processes, instead of just one. Regardless of the intent behind this feature, the implementation that was pushed to master is in my opinion, and apparently others, deeply flawed. The main issue is that it pushes the responsability of propagating the right errors directly to the user, and the user must use extra care when writing this handler. For example this handler would be incorrect: $handle_undefined_function(monitor, [process, Pid]) -> do_something(); $handle_undefined_function(demonitor, Pid) -> do_something_else(); $handle_undefined_function(F, Args) -> error_handler:raise_undef_exception(?MODULE, F, Args). Can you see why?[1] If it's not obvious to you, then perhaps this feature needs more work. My proposal is to use an attribute to list the functions defined like this, so that error_handler can make the distinction between undef and badarg directly. The above function would then be written like this: $handle_undefined_function(monitor, [process, Pid]) -> do_something(); $handle_undefined_function(demonitor, Pid) -> do_something_else(). And the issue would be gone. Adding an attribute isn't hard, whether you generate code or not, and it can be used by tools to figure out what's going on with the module, providing better integration. And why not just use -export and still allow -spec anyway? The function is exported, has specs, but is just defined elsewhere. I'm sure there can be a simple solution that fits a lot better the existing toolbase. [1] The answer is: if the first argument to 'monitor' is anything other than the atom 'process', then an undef error will be triggered instead of 'badarg'. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From anotherworldofworld@REDACTED Mon Jan 21 19:30:35 2013 From: anotherworldofworld@REDACTED (Alex toyer) Date: Tue, 22 Jan 2013 00:30:35 +0600 Subject: [erlang-questions] [ANN] Ybot-0.2 chat bot released Message-ID: Hello erlangers. I released Ybot chat bot 0.2 version. Ybot changelog: * Xmpp transport supporting added * Campfire transport supporting added * New plugins added (chuck, github_status, erl, decide) * Ibrowse added to dependencies * Reloader added to dependencies * Lager added to dependencies * Mochijson2 added to dependencies * Code cleaned & documentation improved * Help plugin fixed --> #9 * Command args must be string, not list of strings --> #12 * Added supporting for perl plugins. * Added supporting for elixir plugins. * Added hacker_news plugin Ybot in github - https://github.com/0xAX/Ybot Ybot plugins - https://github.com/0xAX/Ybot/tree/master/plugins -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Mon Jan 21 19:36:57 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 21 Jan 2013 21:36:57 +0300 Subject: [erlang-questions] Cowboy_static and http auth Message-ID: What is the best way to add http authorization before cowboy_static? -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Mon Jan 21 19:44:07 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Mon, 21 Jan 2013 19:44:07 +0100 Subject: [erlang-questions] Cowboy_static and http auth In-Reply-To: References: Message-ID: <50FD8C77.8040305@ninenines.eu> On 01/21/2013 07:36 PM, Max Lapshin wrote: > What is the best way to add http authorization before cowboy_static? This, probably. https://github.com/extend/cowboy/blob/master/guide/middlewares.md -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From max.lapshin@REDACTED Mon Jan 21 20:08:46 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 21 Jan 2013 22:08:46 +0300 Subject: [erlang-questions] Cowboy_static and http auth In-Reply-To: <50FD8C77.8040305@ninenines.eu> References: <50FD8C77.8040305@ninenines.eu> Message-ID: Ok, got it. On Mon, Jan 21, 2013 at 10:44 PM, Lo?c Hoguin wrote: > On 01/21/2013 07:36 PM, Max Lapshin wrote: > >> What is the best way to add http authorization before cowboy_static? >> > > This, probably. > > https://github.com/extend/**cowboy/blob/master/guide/**middlewares.md > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.charles.davis@REDACTED Mon Jan 21 20:38:16 2013 From: steven.charles.davis@REDACTED (Steve Davis) Date: Mon, 21 Jan 2013 13:38:16 -0600 Subject: [erlang-questions] unexpected result of term_to_binary Message-ID: The following appears to encode lists of integers as strings (?!?): Eshell V5.9.3 (abort with ^G) 1> term_to_binary([1,2,3,4]). <<131,107,0,4,1,2,3,4>> Is there a reason for this that I'm missing? regs, /s From ivan@REDACTED Mon Jan 21 20:44:57 2013 From: ivan@REDACTED (Ivan Uemlianin) Date: Mon, 21 Jan 2013 19:44:57 +0000 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: References: Message-ID: <22D44D80-7253-462B-A86F-E796A8882031@llaisdy.com> What's the difference between a list of integers and a string? -- festina lente On 21 Jan 2013, at 19:38, Steve Davis wrote: > The following appears to encode lists of integers as strings (?!?): > > Eshell V5.9.3 (abort with ^G) > 1> term_to_binary([1,2,3,4]). > <<131,107,0,4,1,2,3,4>> > > Is there a reason for this that I'm missing? > > regs, > /s > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From paul.joseph.davis@REDACTED Mon Jan 21 20:46:33 2013 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Mon, 21 Jan 2013 13:46:33 -0600 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: References: Message-ID: In Erlang a list of integers in the range 0-255 is a string. An easy test is to show that the value 256 changes the encoding into a list of integers: > term_to_binary([1, 2, 3, 4, 256]). <<131,108,0,0,0,5,97,1,97,2,97,3,97,4,98,0,0,1,0,106>> On Mon, Jan 21, 2013 at 1:38 PM, Steve Davis wrote: > The following appears to encode lists of integers as strings (?!?): > > Eshell V5.9.3 (abort with ^G) > 1> term_to_binary([1,2,3,4]). > <<131,107,0,4,1,2,3,4>> > > Is there a reason for this that I'm missing? > > regs, > /s > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Mon Jan 21 20:53:37 2013 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Mon, 21 Jan 2013 21:53:37 +0200 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: References: Message-ID: Hello, This make sense to me! term_to_binary/1 returns a binary data object which is the result of encoding Term according to the Erlang external term format. See http://erlang.org/doc/apps/erts/erl_ext_dist.html Use list_to_binary or unicode:character_to_binary depends on your use-case. - Dmitry On Jan 21, 2013, at 9:38 PM, Steve Davis wrote: > The following appears to encode lists of integers as strings (?!?): > > Eshell V5.9.3 (abort with ^G) > 1> term_to_binary([1,2,3,4]). > <<131,107,0,4,1,2,3,4>> > > Is there a reason for this that I'm missing? > > regs, > /s > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From steven.charles.davis@REDACTED Mon Jan 21 21:00:32 2013 From: steven.charles.davis@REDACTED (Steve Davis) Date: Mon, 21 Jan 2013 14:00:32 -0600 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: References: Message-ID: Hi Dmitry, It "makes sense" only if the "binary_to_term" decode is done in erlang. br, /s On Jan 21, 2013, at 1:53 PM, Dmitry Kolesnikov wrote: > Hello, > > This make sense to me! > > term_to_binary/1 returns a binary data object which is the result of encoding Term according to the Erlang external term format. See http://erlang.org/doc/apps/erts/erl_ext_dist.html > > Use list_to_binary or unicode:character_to_binary depends on your use-case. > > - Dmitry > > On Jan 21, 2013, at 9:38 PM, Steve Davis wrote: > >> The following appears to encode lists of integers as strings (?!?): >> >> Eshell V5.9.3 (abort with ^G) >> 1> term_to_binary([1,2,3,4]). >> <<131,107,0,4,1,2,3,4>> >> >> Is there a reason for this that I'm missing? >> >> regs, >> /s >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > From dmkolesnikov@REDACTED Mon Jan 21 21:13:13 2013 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Mon, 21 Jan 2013 22:13:13 +0200 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: References: Message-ID: <219AEB9D-540E-44CA-8CC5-F44DF674174B@gmail.com> Hi Steve, There is a well document External Term Format protocol. I am not here to judge that protocol but it is implementable on other languages as well (https://github.com/rustyio/BERT-JS). Yes, it make sense in scopes of that protocol specification. Long time ago, I've been trying to use it for WebApp development and ? switched to JSON. :-) But I strongly believe that External Term Format make sense for other use-case... Best Regards, Dmitry On Jan 21, 2013, at 10:00 PM, Steve Davis wrote: > Hi Dmitry, > > It "makes sense" only if the "binary_to_term" decode is done in erlang. > > br, > /s > > On Jan 21, 2013, at 1:53 PM, Dmitry Kolesnikov wrote: > >> Hello, >> >> This make sense to me! >> >> term_to_binary/1 returns a binary data object which is the result of encoding Term according to the Erlang external term format. See http://erlang.org/doc/apps/erts/erl_ext_dist.html >> >> Use list_to_binary or unicode:character_to_binary depends on your use-case. >> >> - Dmitry >> >> On Jan 21, 2013, at 9:38 PM, Steve Davis wrote: >> >>> The following appears to encode lists of integers as strings (?!?): >>> >>> Eshell V5.9.3 (abort with ^G) >>> 1> term_to_binary([1,2,3,4]). >>> <<131,107,0,4,1,2,3,4>> >>> >>> Is there a reason for this that I'm missing? >>> >>> regs, >>> /s >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> > From steven.charles.davis@REDACTED Mon Jan 21 21:15:41 2013 From: steven.charles.davis@REDACTED (Steve Davis) Date: Mon, 21 Jan 2013 14:15:41 -0600 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: <219AEB9D-540E-44CA-8CC5-F44DF674174B@gmail.com> References: <219AEB9D-540E-44CA-8CC5-F44DF674174B@gmail.com> Message-ID: <43BBEB18-AE31-4C48-B812-F03E3C1783DF@gmail.com> Hi Dmitry, Unfortunately, Bert-js suffers from the same ambiguity client side. I have in fact found a reasonable hack which only costs an extra byte and is to prepend NIL_EXT to the list: 1> term_to_binary([[],1,2,3,4]). <<131,108,0,0,0,5,106,97,1,97,2,97,3,97,4,106>> Best, Steve On Jan 21, 2013, at 2:13 PM, Dmitry Kolesnikov wrote: > Hi Steve, > > There is a well document External Term Format protocol. I am not here to judge that protocol but it is implementable on other languages as well (https://github.com/rustyio/BERT-JS). Yes, it make sense in scopes of that protocol specification. > > Long time ago, I've been trying to use it for WebApp development and ? switched to JSON. :-) > But I strongly believe that External Term Format make sense for other use-case... > > > Best Regards, > Dmitry > > > On Jan 21, 2013, at 10:00 PM, Steve Davis wrote: > >> Hi Dmitry, >> >> It "makes sense" only if the "binary_to_term" decode is done in erlang. >> >> br, >> /s >> >> On Jan 21, 2013, at 1:53 PM, Dmitry Kolesnikov wrote: >> >>> Hello, >>> >>> This make sense to me! >>> >>> term_to_binary/1 returns a binary data object which is the result of encoding Term according to the Erlang external term format. See http://erlang.org/doc/apps/erts/erl_ext_dist.html >>> >>> Use list_to_binary or unicode:character_to_binary depends on your use-case. >>> >>> - Dmitry >>> >>> On Jan 21, 2013, at 9:38 PM, Steve Davis wrote: >>> >>>> The following appears to encode lists of integers as strings (?!?): >>>> >>>> Eshell V5.9.3 (abort with ^G) >>>> 1> term_to_binary([1,2,3,4]). >>>> <<131,107,0,4,1,2,3,4>> >>>> >>>> Is there a reason for this that I'm missing? >>>> >>>> regs, >>>> /s >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> > From steven.charles.davis@REDACTED Mon Jan 21 21:24:05 2013 From: steven.charles.davis@REDACTED (Steve Davis) Date: Mon, 21 Jan 2013 14:24:05 -0600 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: <43BBEB18-AE31-4C48-B812-F03E3C1783DF@gmail.com> References: <219AEB9D-540E-44CA-8CC5-F44DF674174B@gmail.com> <43BBEB18-AE31-4C48-B812-F03E3C1783DF@gmail.com> Message-ID: <7060B0EF-C164-440B-AD71-5F37FC64AEE8@gmail.com> Even better solution is to send "lists of integers" as tuples: 2> term_to_binary({1,2,3,4}). <<131,104,4,97,1,97,2,97,3,97,4>> :-) /s On Jan 21, 2013, at 2:15 PM, Steve Davis wrote: > Hi Dmitry, > > Unfortunately, Bert-js suffers from the same ambiguity client side. > > I have in fact found a reasonable hack which only costs an extra byte and is to prepend NIL_EXT to the list: > 1> term_to_binary([[],1,2,3,4]). > <<131,108,0,0,0,5,106,97,1,97,2,97,3,97,4,106>> > > Best, > Steve > > On Jan 21, 2013, at 2:13 PM, Dmitry Kolesnikov wrote: > >> Hi Steve, >> >> There is a well document External Term Format protocol. I am not here to judge that protocol but it is implementable on other languages as well (https://github.com/rustyio/BERT-JS). Yes, it make sense in scopes of that protocol specification. >> >> Long time ago, I've been trying to use it for WebApp development and ? switched to JSON. :-) >> But I strongly believe that External Term Format make sense for other use-case... >> >> >> Best Regards, >> Dmitry >> >> >> On Jan 21, 2013, at 10:00 PM, Steve Davis wrote: >> >>> Hi Dmitry, >>> >>> It "makes sense" only if the "binary_to_term" decode is done in erlang. >>> >>> br, >>> /s >>> >>> On Jan 21, 2013, at 1:53 PM, Dmitry Kolesnikov wrote: >>> >>>> Hello, >>>> >>>> This make sense to me! >>>> >>>> term_to_binary/1 returns a binary data object which is the result of encoding Term according to the Erlang external term format. See http://erlang.org/doc/apps/erts/erl_ext_dist.html >>>> >>>> Use list_to_binary or unicode:character_to_binary depends on your use-case. >>>> >>>> - Dmitry >>>> >>>> On Jan 21, 2013, at 9:38 PM, Steve Davis wrote: >>>> >>>>> The following appears to encode lists of integers as strings (?!?): >>>>> >>>>> Eshell V5.9.3 (abort with ^G) >>>>> 1> term_to_binary([1,2,3,4]). >>>>> <<131,107,0,4,1,2,3,4>> >>>>> >>>>> Is there a reason for this that I'm missing? >>>>> >>>>> regs, >>>>> /s >>>>> >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>> >> > From erlang@REDACTED Mon Jan 21 21:26:10 2013 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 21 Jan 2013 21:26:10 +0100 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: References: Message-ID: On Mon, Jan 21, 2013 at 8:38 PM, Steve Davis wrote: > The following appears to encode lists of integers as strings (?!?): > > No no no - Erlang doesn't have strings - there are no strings in Erlang (repeat this 100 times). There are two internal types commonly used to represent strings lists and binaries. There are also string literals (ie things in programs like "aaaaabbbbb") these are just shorthand for lists of integers. term_to_binary(Term) converts Term to a Binary (Bin). You're not supposed to know whats *in* the binary. All you need to know is that binary_to_term(Bin) is the inverse. It's like the bits in a float - you're not supposed to know what the bits mean 99.999999% of all programs should not know what the *internal* structure of the thing returned by term_to_binary is (if you want to know it's the term represented in the external format ( http://erlang.org/doc/apps/erts/erl_ext_dist.html) Just about the *only* reason to call term_to_binary is that at some later time somebody will call binary_to_term on the result. > Eshell V5.9.3 (abort with ^G) > 1> term_to_binary([1,2,3,4]). > <<131,107,0,4,1,2,3,4>> > > Is there a reason for this that I'm missing? > <<131,107,...>> Is *not* a string - it's a binary literal 2> binary_to_term(<<131,107,0,4,1,2,3,4>>). [1,2,3,4] Cheers /Joe > > regs, > /s > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.charles.davis@REDACTED Mon Jan 21 21:30:04 2013 From: steven.charles.davis@REDACTED (Steve Davis) Date: Mon, 21 Jan 2013 14:30:04 -0600 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: References: Message-ID: On Jan 21, 2013, at 2:26 PM, Joe Armstrong wrote: > > > On Mon, Jan 21, 2013 at 8:38 PM, Steve Davis wrote: > The following appears to encode lists of integers as strings (?!?): > > > No no no - Erlang doesn't have strings - there are no strings in Erlang > (repeat this 100 times). > Indeed, but the documentation says byte 107 means: 8 External Term Format 8.14 STRING_EXT So please forgive the "inaccuracy" :-) br, /s -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Mon Jan 21 21:33:58 2013 From: ulf@REDACTED (Ulf Wiger) Date: Mon, 21 Jan 2013 21:33:58 +0100 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: References: Message-ID: <10BCABEF-7F9E-4849-87AA-007F96B62903@feuerlabs.com> Yeah, and? 1> erl_scan:string("\"abc\""). {ok,[{string,1,"abc"}],1} ...so an uneducated user might be forgiven for thinking that there *are* in fact strings in Erlang. :) BR, Ulf W On 21 Jan 2013, at 21:30, Steve Davis wrote: > > On Jan 21, 2013, at 2:26 PM, Joe Armstrong wrote: > >> >> >> On Mon, Jan 21, 2013 at 8:38 PM, Steve Davis wrote: >> The following appears to encode lists of integers as strings (?!?): >> >> >> No no no - Erlang doesn't have strings - there are no strings in Erlang >> (repeat this 100 times). >> > > Indeed, but the documentation says byte 107 means: > 8 External Term Format > > 8.14 STRING_EXT > > > So please forgive the "inaccuracy" :-) > > br, > /s > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Mon Jan 21 21:41:07 2013 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 21 Jan 2013 21:41:07 +0100 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: References: Message-ID: On Mon, Jan 21, 2013 at 8:46 PM, Paul Davis wrote: > In Erlang a list of integers in the range 0-255 is a string. > No it's not - a list of integers in the range 0-255 is not a string - it's a list of integers from 0-255 and nothing else - you don't a clue what it represents. Example: > Ages = [65,66,67]. "ABC" is a list of the ages (integers) at which many people become pensioners in Sweden - it's also three ascii characters codes for 'A' 'B' and 'C'. All erlang knows is that this is a list of three integers it hasn't a clue what it means. The shell prints this as "ABC" (this is a string literal representing the integers [65,66,67]) This is because the shell prints a list of printable character codes as a string literal, ie it guesses that the intended meaning is as a list of character codes and prints it as a string to help you. In this case the shell guessed wrong. It's a list of ages :-) We can use io:format to change the printed representation > io:format(" ~s ~w ~p~n", [Ages, Ages,Ages]). ABC [65,66,67] "ABC" Ages is a list of three integers. /Joe > An easy test is to show that the value 256 changes the encoding into a > list of integers: > > > term_to_binary([1, 2, 3, 4, 256]). > <<131,108,0,0,0,5,97,1,97,2,97,3,97,4,98,0,0,1,0,106>> > > > > On Mon, Jan 21, 2013 at 1:38 PM, Steve Davis < > steven.charles.davis@REDACTED> wrote: > >> The following appears to encode lists of integers as strings (?!?): >> >> Eshell V5.9.3 (abort with ^G) >> 1> term_to_binary([1,2,3,4]). >> <<131,107,0,4,1,2,3,4>> >> >> Is there a reason for this that I'm missing? >> >> regs, >> /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 erlang@REDACTED Mon Jan 21 21:44:07 2013 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 21 Jan 2013 21:44:07 +0100 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: References: Message-ID: On Mon, Jan 21, 2013 at 9:00 PM, Steve Davis wrote: > Hi Dmitry, > > It "makes sense" only if the "binary_to_term" decode is done in erlang. > > No - your could do it in C or java or C++. remember it's an external formal. It makes sense for an external program to examine the format - that way we can "teach" C++ etc. to understand erlang terms. Inside Erlang you only use pairs of functions term_to_binary and the inverse binary_to_term /Joe > br, > /s > > On Jan 21, 2013, at 1:53 PM, Dmitry Kolesnikov > wrote: > > > Hello, > > > > This make sense to me! > > > > term_to_binary/1 returns a binary data object which is the result of > encoding Term according to the Erlang external term format. See > http://erlang.org/doc/apps/erts/erl_ext_dist.html > > > > Use list_to_binary or unicode:character_to_binary depends on your > use-case. > > > > - Dmitry > > > > On Jan 21, 2013, at 9:38 PM, Steve Davis > wrote: > > > >> The following appears to encode lists of integers as strings (?!?): > >> > >> Eshell V5.9.3 (abort with ^G) > >> 1> term_to_binary([1,2,3,4]). > >> <<131,107,0,4,1,2,3,4>> > >> > >> Is there a reason for this that I'm missing? > >> > >> regs, > >> /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 erlang@REDACTED Mon Jan 21 21:49:58 2013 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 21 Jan 2013 21:49:58 +0100 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: <219AEB9D-540E-44CA-8CC5-F44DF674174B@gmail.com> References: <219AEB9D-540E-44CA-8CC5-F44DF674174B@gmail.com> Message-ID: On Mon, Jan 21, 2013 at 9:13 PM, Dmitry Kolesnikov wrote: > Hi Steve, > > There is a well document External Term Format protocol. I am not here to > judge that protocol but it is implementable on other languages as well ( > https://github.com/rustyio/BERT-JS). Yes, it make sense in scopes of that > protocol specification. > > Long time ago, I've been trying to use it for WebApp development and ? > switched to JSON. :-) > There is a slight problem here. Binary data arriving on sockets often ends up stored in javascript as UTF-8 strings - but these is no guarantee that an arbitrary erlang term when converted to the external format is a valid UTF8 string .... /Joe > But I strongly believe that External Term Format make sense for other > use-case... > > > Best Regards, > Dmitry > > > On Jan 21, 2013, at 10:00 PM, Steve Davis > wrote: > > > Hi Dmitry, > > > > It "makes sense" only if the "binary_to_term" decode is done in erlang. > > > > br, > > /s > > > > On Jan 21, 2013, at 1:53 PM, Dmitry Kolesnikov > wrote: > > > >> Hello, > >> > >> This make sense to me! > >> > >> term_to_binary/1 returns a binary data object which is the result of > encoding Term according to the Erlang external term format. See > http://erlang.org/doc/apps/erts/erl_ext_dist.html > >> > >> Use list_to_binary or unicode:character_to_binary depends on your > use-case. > >> > >> - Dmitry > >> > >> On Jan 21, 2013, at 9:38 PM, Steve Davis < > steven.charles.davis@REDACTED> wrote: > >> > >>> The following appears to encode lists of integers as strings (?!?): > >>> > >>> Eshell V5.9.3 (abort with ^G) > >>> 1> term_to_binary([1,2,3,4]). > >>> <<131,107,0,4,1,2,3,4>> > >>> > >>> Is there a reason for this that I'm missing? > >>> > >>> regs, > >>> /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 erlang@REDACTED Mon Jan 21 21:56:59 2013 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 21 Jan 2013 21:56:59 +0100 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: <10BCABEF-7F9E-4849-87AA-007F96B62903@feuerlabs.com> References: <10BCABEF-7F9E-4849-87AA-007F96B62903@feuerlabs.com> Message-ID: On Mon, Jan 21, 2013 at 9:33 PM, Ulf Wiger wrote: > > Yeah, and? > > 1> erl_scan:string("\"abc\""). > {ok,[{string,1,"abc"}],1} > > ...so an uneducated user might be forgiven for thinking that there *are* > in fact strings in Erlang. :) > Right - I guess it should be {ok,[{string_literal,1,[65,66,67]}]} which would be even more confusing. > > BR, > Ulf W > > On 21 Jan 2013, at 21:30, Steve Davis wrote: > > > On Jan 21, 2013, at 2:26 PM, Joe Armstrong wrote: > > > > On Mon, Jan 21, 2013 at 8:38 PM, Steve Davis < > steven.charles.davis@REDACTED> wrote: > >> The following appears to encode lists of integers as strings (?!?): >> >> > No no no - Erlang doesn't have strings - there are no strings in Erlang > (repeat this 100 times). > > > Indeed, but the documentation says byte 107 means: > 8 External Term Format > 8.14 STRING_EXT > > So please forgive the "inaccuracy" :-) > > br, > /s > _______________________________________________ > 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Mon Jan 21 22:00:40 2013 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 21 Jan 2013 22:00:40 +0100 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: <7060B0EF-C164-440B-AD71-5F37FC64AEE8@gmail.com> References: <219AEB9D-540E-44CA-8CC5-F44DF674174B@gmail.com> <43BBEB18-AE31-4C48-B812-F03E3C1783DF@gmail.com> <7060B0EF-C164-440B-AD71-5F37FC64AEE8@gmail.com> Message-ID: On Mon, Jan 21, 2013 at 9:24 PM, Steve Davis wrote: > Even better solution is to send "lists of integers" as tuples: > 2> term_to_binary({1,2,3,4}). > <<131,104,4,97,1,97,2,97,3,97,4>> > > :-) > While we're on the subject - shouldn't we rename lists. stacks is a much better name - Erlang has no lists only stacks. think of explaining reverse reverse(L) -> reverse(L, []). reverse([H|T], L) -> reverse(T, [H|L]); reverse([], L) -> L. easy to explain using the "two stacks of plates" model. Lists is a stupid name :-) /Joe > /s > > > On Jan 21, 2013, at 2:15 PM, Steve Davis > wrote: > > > Hi Dmitry, > > > > Unfortunately, Bert-js suffers from the same ambiguity client side. > > > > I have in fact found a reasonable hack which only costs an extra byte > and is to prepend NIL_EXT to the list: > > 1> term_to_binary([[],1,2,3,4]). > > <<131,108,0,0,0,5,106,97,1,97,2,97,3,97,4,106>> > > > > Best, > > Steve > > > > On Jan 21, 2013, at 2:13 PM, Dmitry Kolesnikov > wrote: > > > >> Hi Steve, > >> > >> There is a well document External Term Format protocol. I am not here > to judge that protocol but it is implementable on other languages as well ( > https://github.com/rustyio/BERT-JS). Yes, it make sense in scopes of that > protocol specification. > >> > >> Long time ago, I've been trying to use it for WebApp development and ? > switched to JSON. :-) > >> But I strongly believe that External Term Format make sense for other > use-case... > >> > >> > >> Best Regards, > >> Dmitry > >> > >> > >> On Jan 21, 2013, at 10:00 PM, Steve Davis < > steven.charles.davis@REDACTED> wrote: > >> > >>> Hi Dmitry, > >>> > >>> It "makes sense" only if the "binary_to_term" decode is done in erlang. > >>> > >>> br, > >>> /s > >>> > >>> On Jan 21, 2013, at 1:53 PM, Dmitry Kolesnikov > wrote: > >>> > >>>> Hello, > >>>> > >>>> This make sense to me! > >>>> > >>>> term_to_binary/1 returns a binary data object which is the result of > encoding Term according to the Erlang external term format. See > http://erlang.org/doc/apps/erts/erl_ext_dist.html > >>>> > >>>> Use list_to_binary or unicode:character_to_binary depends on your > use-case. > >>>> > >>>> - Dmitry > >>>> > >>>> On Jan 21, 2013, at 9:38 PM, Steve Davis < > steven.charles.davis@REDACTED> wrote: > >>>> > >>>>> The following appears to encode lists of integers as strings (?!?): > >>>>> > >>>>> Eshell V5.9.3 (abort with ^G) > >>>>> 1> term_to_binary([1,2,3,4]). > >>>>> <<131,107,0,4,1,2,3,4>> > >>>>> > >>>>> Is there a reason for this that I'm missing? > >>>>> > >>>>> regs, > >>>>> /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 hd2010@REDACTED Mon Jan 21 22:05:10 2013 From: hd2010@REDACTED (Henning Diedrich) Date: Mon, 21 Jan 2013 22:05:10 +0100 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: References: <219AEB9D-540E-44CA-8CC5-F44DF674174B@gmail.com> <43BBEB18-AE31-4C48-B812-F03E3C1783DF@gmail.com> <7060B0EF-C164-440B-AD71-5F37FC64AEE8@gmail.com> Message-ID: On Jan 21, 2013, at 10:00 PM, Joe Armstrong wrote: > stacks is a much better name - Erlang has no lists only stacks. > And rename Erlang to Erlforth. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.goertzen@REDACTED Mon Jan 21 22:36:02 2013 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Mon, 21 Jan 2013 15:36:02 -0600 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: <219AEB9D-540E-44CA-8CC5-F44DF674174B@gmail.com> References: <219AEB9D-540E-44CA-8CC5-F44DF674174B@gmail.com> Message-ID: The BERT protocol specification (http://bert-rpc.org/) does not support strings at all. I guess you are supposed to encode strings at a higher layer as int-lists or binaries, which goes along with what Joe is saying. Having written a Python ETF module, I have to admit I was confused by STRING_EXT and strings. Once you realize there are no strings, life gets easier. Dan. On Mon, Jan 21, 2013 at 2:13 PM, Dmitry Kolesnikov wrote: > Hi Steve, > > There is a well document External Term Format protocol. I am not here to > judge that protocol but it is implementable on other languages as well ( > https://github.com/rustyio/BERT-JS). Yes, it make sense in scopes of that > protocol specification. > > Long time ago, I've been trying to use it for WebApp development and ? > switched to JSON. :-) > But I strongly believe that External Term Format make sense for other > use-case... > > > Best Regards, > Dmitry > > > On Jan 21, 2013, at 10:00 PM, Steve Davis > wrote: > > > Hi Dmitry, > > > > It "makes sense" only if the "binary_to_term" decode is done in erlang. > > > > br, > > /s > > > > On Jan 21, 2013, at 1:53 PM, Dmitry Kolesnikov > wrote: > > > >> Hello, > >> > >> This make sense to me! > >> > >> term_to_binary/1 returns a binary data object which is the result of > encoding Term according to the Erlang external term format. See > http://erlang.org/doc/apps/erts/erl_ext_dist.html > >> > >> Use list_to_binary or unicode:character_to_binary depends on your > use-case. > >> > >> - Dmitry > >> > >> On Jan 21, 2013, at 9:38 PM, Steve Davis < > steven.charles.davis@REDACTED> wrote: > >> > >>> The following appears to encode lists of integers as strings (?!?): > >>> > >>> Eshell V5.9.3 (abort with ^G) > >>> 1> term_to_binary([1,2,3,4]). > >>> <<131,107,0,4,1,2,3,4>> > >>> > >>> Is there a reason for this that I'm missing? > >>> > >>> regs, > >>> /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 tony@REDACTED Mon Jan 21 23:15:23 2013 From: tony@REDACTED (Tony Rogvall) Date: Mon, 21 Jan 2013 23:15:23 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <50FD8342.8030100@ninenines.eu> References: <50FD8342.8030100@ninenines.eu> Message-ID: <09F7ADED-CF58-4B75-8BDC-BD823524181A@rogvall.se> On 21 jan 2013, at 19:04, Lo?c Hoguin wrote: > Hello, > > Just recently the $handle_undefined_function feature was introduced. It is a way to override error_handler mechanisms when a function isn't found, and works per module for all processes, instead of just one. > > Regardless of the intent behind this feature, the implementation that was pushed to master is in my opinion, and apparently others, deeply flawed. The main issue is that it pushes the responsability of propagating the right errors directly to the user, and the user must use extra care when writing this handler. > This is strange. You think that every one should stay away from this feature, but then you start to play around with it your self. Why? Are better suited to handle this abomination than the rest of us or what? > For example this handler would be incorrect: > > $handle_undefined_function(monitor, [process, Pid]) -> > do_something(); > $handle_undefined_function(demonitor, Pid) -> > do_something_else(); > $handle_undefined_function(F, Args) -> > error_handler:raise_undef_exception(?MODULE, F, Args). > > Can you see why?[1] If it's not obvious to you, then perhaps this feature needs more work. > What is the fix? ... > My proposal is to use an attribute to list the functions defined like this, so that error_handler can make the distinction between undef and badarg directly. The above function would then be written like this: > Wow, you really want to contribute to the development of Erlang. > $handle_undefined_function(monitor, [process, Pid]) -> > do_something(); > $handle_undefined_function(demonitor, Pid) -> > do_something_else(). > > And the issue would be gone. > > Adding an attribute isn't hard, whether you generate code or not, and it can be used by tools to figure out what's going on with the module, providing better integration. > > And why not just use -export and still allow -spec anyway? The function is exported, has specs, but is just defined elsewhere. I'm sure there can be a simple solution that fits a lot better the existing toolbase. > Now we are getting creative and cooperative, I like that. Here is a smiley for you :-) /Tony > [1] The answer is: if the first argument to 'monitor' is anything other than the atom 'process', then an undef error will be triggered instead of 'badarg'. > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Mon Jan 21 23:26:27 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 21 Jan 2013 17:26:27 -0500 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <50FD8342.8030100@ninenines.eu> References: <50FD8342.8030100@ninenines.eu> Message-ID: <20130121222625.GB69040@ferdmbp.local> As long as the call order is well-defined to always be the same (process-defined handler -> module-defined handler), there should be no big consistency problem. There should be work done in order to make sure that a crash in the `'$handle_undefined_function'` handler does *not* change the error type from `undef` to whatever the crash was. In my opinion, this will allow to keep a more declarative type of error handling there while keeping the caller's expectations sane, and will put the burden of shoddy programming maintenance on the authors of the original handler, and not push it to the user of the library. Let's imagine I use a module that used this feature, gets updated, and has a bug that breaks the functionality within `'$handle_undefined_function'`. As the user of that module, I may get anything from `undef` to whatever the handler uses and can generate (`badarg`, `badarith`, `badfun`, etc.). This can be *very* confusing to debug and manage. On the other hand, if the error is restricted to `undef`, the unknown behaviour is pushed back on the maintainer of the library to figure out, and inspecting the module will show that the function is indeed missing. It breaks fewer expectations. I would also be in favor of a new error type of the kind `module_author_uses_features_he_or_she_is_not_understanding_please_blame_them` to be returned to make the problem 100% obvious and embarrassing. It could be more insulting too. I'm barely kidding here. I'm not against the idea, but I do believe more work is needed to make sure users of libraries are protected from bad, shoddy implementations of the function, especially in the age-old semantics of what fails or not. -Fred. From essen@REDACTED Tue Jan 22 00:10:13 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Tue, 22 Jan 2013 00:10:13 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <09F7ADED-CF58-4B75-8BDC-BD823524181A@rogvall.se> References: <50FD8342.8030100@ninenines.eu> <09F7ADED-CF58-4B75-8BDC-BD823524181A@rogvall.se> Message-ID: <50FDCAD5.1020705@ninenines.eu> On 01/21/2013 11:15 PM, Tony Rogvall wrote: > > On 21 jan 2013, at 19:04, Lo?c Hoguin > wrote: > >> Hello, >> >> Just recently the $handle_undefined_function feature was introduced. >> It is a way to override error_handler mechanisms when a function isn't >> found, and works per module for all processes, instead of just one. >> >> Regardless of the intent behind this feature, the implementation that >> was pushed to master is in my opinion, and apparently others, deeply >> flawed. The main issue is that it pushes the responsability of >> propagating the right errors directly to the user, and the user must >> use extra care when writing this handler. >> > This is strange. You think that every one should stay away from this > feature, but then you start to play > around with it your self. Why? Are better suited to handle this > abomination than the rest of us or what? I said stay away because the implementation is flawed. If this feature behaves the same as any other function call, then I'm perfectly good with it. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From emmiller@REDACTED Tue Jan 22 00:15:00 2013 From: emmiller@REDACTED (Evan Miller) Date: Mon, 21 Jan 2013 17:15:00 -0600 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <50FD8342.8030100@ninenines.eu> References: <50FD8342.8030100@ninenines.eu> Message-ID: On Mon, Jan 21, 2013 at 12:04 PM, Lo?c Hoguin wrote: > Hello, > > Just recently the $handle_undefined_function feature was introduced. It is > a way to override error_handler mechanisms when a function isn't found, and > works per module for all processes, instead of just one. > > Regardless of the intent behind this feature, the implementation that was > pushed to master is in my opinion, and apparently others, deeply flawed. > The main issue is that it pushes the responsability of propagating the > right errors directly to the user, and the user must use extra care when > writing this handler. > > For example this handler would be incorrect: > > $handle_undefined_function(**monitor, [process, Pid]) -> > do_something(); > $handle_undefined_function(**demonitor, Pid) -> > do_something_else(); > $handle_undefined_function(F, Args) -> > error_handler:raise_undef_**exception(?MODULE, F, Args). > > Can you see why?[1] If it's not obvious to you, then perhaps this feature > needs more work. > > My proposal is to use an attribute to list the functions defined like > this, so that error_handler can make the distinction between undef and > badarg directly. The above function would then be written like this: > > $handle_undefined_function(**monitor, [process, Pid]) -> > do_something(); > $handle_undefined_function(**demonitor, Pid) -> > do_something_else(). > > And the issue would be gone. > This is a great point. An attribute is one solution. Another would be adding another function, e.g. $should_handle_undefined_function(FunctionName, Arity), that determines at run-time whether to call the handler. $should_handle_undefined_function(monitor, 2) -> true; $should_handle_undefined_function(demonitor, 1) -> true; $should_handle_undefined_function(_, _) -> false. $handle_undefined_function(monitor, [process, Pid]) -> do_something(); $handle_undefined_function(**demonitor, Pid) -> do_something_else(). What do you think? Evan > > Adding an attribute isn't hard, whether you generate code or not, and it > can be used by tools to figure out what's going on with the module, > providing better integration. > > And why not just use -export and still allow -spec anyway? The function is > exported, has specs, but is just defined elsewhere. I'm sure there can be a > simple solution that fits a lot better the existing toolbase. > > [1] The answer is: if the first argument to 'monitor' is anything other > than the atom 'process', then an undef error will be triggered instead of > 'badarg'. > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > 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 Tue Jan 22 00:24:12 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Tue, 22 Jan 2013 00:24:12 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: References: <50FD8342.8030100@ninenines.eu> Message-ID: <50FDCE1C.7040204@ninenines.eu> On 01/22/2013 12:15 AM, Evan Miller wrote: > On Mon, Jan 21, 2013 at 12:04 PM, Lo?c Hoguin > wrote: > > Hello, > > Just recently the $handle_undefined_function feature was introduced. > It is a way to override error_handler mechanisms when a function > isn't found, and works per module for all processes, instead of just > one. > > Regardless of the intent behind this feature, the implementation > that was pushed to master is in my opinion, and apparently others, > deeply flawed. The main issue is that it pushes the responsability > of propagating the right errors directly to the user, and the user > must use extra care when writing this handler. > > For example this handler would be incorrect: > > $handle_undefined_function(__monitor, [process, Pid]) -> > do_something(); > $handle_undefined_function(__demonitor, Pid) -> > do_something_else(); > $handle_undefined_function(F, Args) -> > error_handler:raise_undef___exception(?MODULE, F, Args). > > Can you see why?[1] If it's not obvious to you, then perhaps this > feature needs more work. > > My proposal is to use an attribute to list the functions defined > like this, so that error_handler can make the distinction between > undef and badarg directly. The above function would then be written > like this: > > $handle_undefined_function(__monitor, [process, Pid]) -> > do_something(); > $handle_undefined_function(__demonitor, Pid) -> > do_something_else(). > > And the issue would be gone. > > > This is a great point. An attribute is one solution. Another would be > adding another function, e.g. > $should_handle_undefined_function(FunctionName, Arity), that determines > at run-time whether to call the handler. > > $should_handle_undefined_function(monitor, 2) -> true; > $should_handle_undefined_function(demonitor, 1) -> true; > $should_handle_undefined_function(_, _) -> false. > > $handle_undefined_function(monitor, [process, Pid]) -> do_something(); > $handle_undefined_function(__demonitor, Pid) -> do_something_else(). > > What do you think? A function is dangerous in that it may return a value conditionally (using for example the process dictionary, a receive, or anything else) and this can heavily mess up the execution. You can still throw an undef error yourself anywhere of course, but this one would look legit and most confusing. That could lead to some debugging hell sessions. Perhaps you do have a need for dynamically managing the list of allowed functions? On the other hand, if you just return true or false right away, I don't see what this has better compared to much shorter to write attributes. I'm fine with both even though I favor attributes. > Adding an attribute isn't hard, whether you generate code or not, > and it can be used by tools to figure out what's going on with the > module, providing better integration. > > And why not just use -export and still allow -spec anyway? The > function is exported, has specs, but is just defined elsewhere. I'm > sure there can be a simple solution that fits a lot better the > existing toolbase. > > [1] The answer is: if the first argument to 'monitor' is anything > other than the atom 'process', then an undef error will be triggered > instead of 'badarg'. > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > _________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/__listinfo/erlang-questions > > > > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From steven.charles.davis@REDACTED Tue Jan 22 00:48:04 2013 From: steven.charles.davis@REDACTED (Steve Davis) Date: Mon, 21 Jan 2013 17:48:04 -0600 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: References: <219AEB9D-540E-44CA-8CC5-F44DF674174B@gmail.com> Message-ID: <6C28C021-B04A-4656-B572-BA33A93BC8CB@gmail.com> If you mean web sockets, then it's important to flag the web socket message as being binary (opcode 2) rather than flagging it as text (opcode 1). It certainly makes no sense to send external term format to JavaScript as "text". The onus is on the sender. /s On Jan 21, 2013, at 2:49 PM, Joe Armstrong wrote: > > There is a slight problem here. Binary data arriving on sockets often ends > up stored in javascript as UTF-8 strings - but these is no guarantee that > an arbitrary erlang term when converted to the external format is a valid > UTF8 string .... > > /Joe > From ok@REDACTED Tue Jan 22 06:23:23 2013 From: ok@REDACTED (Richard O'Keefe) Date: Tue, 22 Jan 2013 18:23:23 +1300 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: References: Message-ID: <3F9C345F-57DE-49AA-B7CB-A1B7804D5A51@cs.otago.ac.nz> On 22/01/2013, at 8:38 AM, Steve Davis wrote: > The following appears to encode lists of integers as strings (?!?): > > Is there a reason for this that I'm missing? Why do you _care_ what the encoding is as long as it decodes correctly? From ok@REDACTED Tue Jan 22 06:39:07 2013 From: ok@REDACTED (Richard O'Keefe) Date: Tue, 22 Jan 2013 18:39:07 +1300 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: References: <219AEB9D-540E-44CA-8CC5-F44DF674174B@gmail.com> <43BBEB18-AE31-4C48-B812-F03E3C1783DF@gmail.com> <7060B0EF-C164-440B-AD71-5F37FC64AEE8@gmail.com> Message-ID: <2D829BAC-4E34-451F-BB6D-22E33727573C@cs.otago.ac.nz> On 22/01/2013, at 10:00 AM, Joe Armstrong wrote: > While we're on the subject - shouldn't we rename lists. > > stacks is a much better name - Erlang has no lists only stacks. Let's see: every Lisp I've come across calls them lists, Clean, Haskell, O'Caml, F#, ML, Prolog, Mercury, &c call them lists, they *are* what the CS literature calls singly-linked lists, and they are *not* what most people think of as stacks, not being mutable. In fact, the word "list" seems to have been used for these things in computing since about 1954. > > Lists is a stupid name :-) > > /Joe I was going to make a quip on your name, but oddly enough, Joseph means "he will add", and you _have_ added much (Erlang), so I guess it's a good name for you. From ok@REDACTED Tue Jan 22 06:44:34 2013 From: ok@REDACTED (Richard O'Keefe) Date: Tue, 22 Jan 2013 18:44:34 +1300 Subject: [erlang-questions] Erlang4Android In-Reply-To: References: <50F313AE.8050303@ernovation.com> <50F464D6.9030700@ernovation.com> <50F54CA3.8030302@ernovation.com> Message-ID: <20D1BC9B-2F4C-412F-BC81-80BA90E1786E@cs.otago.ac.nz> On 19/01/2013, at 4:25 AM, Bj?rn Gustavsson wrote: > It might interest you to know, that in R16, you can have a handler for > undefined functions in each module. (We needed that to implement the parse > transformation for parameterized modules.) Where is the semantics written up? From ok@REDACTED Tue Jan 22 06:51:42 2013 From: ok@REDACTED (Richard O'Keefe) Date: Tue, 22 Jan 2013 18:51:42 +1300 Subject: [erlang-questions] SAX-like JSON Parser for Erlang In-Reply-To: <1358517301.25429.YahooMailNeo@web120702.mail.ne1.yahoo.com> References: <1358517301.25429.YahooMailNeo@web120702.mail.ne1.yahoo.com> Message-ID: <0B25DEFA-2C1C-4AF0-A17A-22CAEFC695A8@cs.otago.ac.nz> On 19/01/2013, at 2:55 AM, Thomas Lindgren wrote: > > > One potential problem with SAX-style parsing is that repeated keys in a JSON object will use/return only the last value (a behaviour inherited from javascript, I believe). When implementing a JSON parser, I found the JSON specification silent about this and asked for clarification. Taking the last value for repeated keys is *NOT* a defined property of JSON nor is it something you can expect as a de-facto standard. Some parsers will take the first value. Some will take the last one. Some will raise a sensible exception. Some a non-sensible one. From yashgt@REDACTED Tue Jan 22 07:02:16 2013 From: yashgt@REDACTED (yashgt@REDACTED) Date: Tue, 22 Jan 2013 06:02:16 +0000 Subject: [erlang-questions] Question regarding JSX Erlang parser Message-ID: <50fe2b87.c368310a.418d.ffff8fbc@mx.google.com> An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Tue Jan 22 07:34:44 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Tue, 22 Jan 2013 07:34:44 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <50FD8342.8030100@ninenines.eu> References: <50FD8342.8030100@ninenines.eu> Message-ID: On Mon, Jan 21, 2013 at 7:04 PM, Lo?c Hoguin wrote: > My proposal is to use an attribute to list the functions defined like > this, so that error_handler can make the distinction between undef and > badarg directly. The above function would then be written like this: > > $handle_undefined_function(**monitor, [process, Pid]) -> > do_something(); > $handle_undefined_function(**demonitor, Pid) -> > do_something_else(). > > I don't really get the rationale for your proposal. If have understood you correctly, I must know beforehand which functions that $handle_undefined_function would handle, and put all functions to be handled in an attribute. Why not use the existing -export() attribute and write like this: -export([monitor/2,demonitor/1]). monitor(process, Pid) -> do_something. demonitor(Pid) -> do_something_else(). So what would be the advantage of your version? -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Tue Jan 22 07:44:14 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Tue, 22 Jan 2013 07:44:14 +0100 Subject: [erlang-questions] Is -extends() used in any projects? Message-ID: -extends() was mentioned when we first talked about removing parameterized modules, so we assumed that we needed to emulate -extends() as well as parameterized modules. It seems to be a good time to ask the question: Is -extends() used by real projects? Do we really need to emulate it? BTW, -extends() is described here: http://www.erlang.se/euc/07/papers/1700Carlsson.pdf -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Tue Jan 22 10:35:36 2013 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 22 Jan 2013 09:35:36 +0000 Subject: [erlang-questions] Question regarding JSX Erlang parser In-Reply-To: <50fe2b87.c368310a.418d.ffff8fbc@mx.google.com> References: <50fe2b87.c368310a.418d.ffff8fbc@mx.google.com> Message-ID: <274D267A-498D-4346-96FE-233BC39D117B@gmail.com> Hi On 22 Jan 2013, at 06:02, yashgt@REDACTED wrote: > Hi, > > I came across https://github.com/talentdeficit/jsx. I have a couple of questions regarding this module: > > 1. Does it allow us to parse JSON data being served over an HTTP stream? This might be useful for consuming web services that serve JSON. If so, is there any example code that shows how this can be done? > Yes it can be done, but I can't release the code as it was proprietary. This is fairly simple however, so long as you've got either a direct connection to the socket (which was how our code worked) or a library/API that allows you to wire the incoming chunks to JSX's continuation mechanism. > 2. Does it read the entire JSON data into memory or does it behave like a SAX parser where the data is read in chunks? > It behaves like a SAX parser where the data is read in chunks, providing you use the continuations API explicitly. From essen@REDACTED Tue Jan 22 12:10:56 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 22 Jan 2013 12:10:56 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: References: <50FD8342.8030100@ninenines.eu> Message-ID: <50FE73C0.5000107@ninenines.eu> On 01/22/2013 07:34 AM, Bj?rn Gustavsson wrote: > On Mon, Jan 21, 2013 at 7:04 PM, Lo?c Hoguin > wrote: > > My proposal is to use an attribute to list the functions defined > like this, so that error_handler can make the distinction between > undef and badarg directly. The above function would then be written > like this: > > $handle_undefined_function(__monitor, [process, Pid]) -> > do_something(); > $handle_undefined_function(__demonitor, Pid) -> > do_something_else(). > > > I don't really get the rationale for your proposal. > > If have understood you correctly, I must know beforehand > which functions that $handle_undefined_function would handle, > and put all functions to be handled in an attribute. Of course you need to know what functions exist in advance. How else do you expect to be able to call them in a reliable manner? > Why not use the existing -export() attribute and write like > this: > > -export([monitor/2,demonitor/1]). > > monitor(process, Pid) -> > do_something. > > demonitor(Pid) -> > do_something_else(). > > So what would be the advantage of your version? It still allows Evan Miller to write this: -attr([first_name/1, last_name/1, ...]). $handle_undefined_function(F, [Model]) -> {_, Value} = lists:keyfind(F, 1, Model), Value. As you can see he doesn't have to worry about adding clauses to handle undef, which is good. This also still allows you to do -extends: %% Functions you override. -export([ponies/1]). %% Functions you don't. -attr([horses/1, cows/1]). $handle_undefined_function(F, Args) -> apply(base_module, F, Args). Again you still don't have to handle undef. Tools can expect these functions. If you allow specs for undefined functions then Dialyzer can also act as if they were defined normally. Implementing it like this, without pushing the burden of handling undef to the user, would avoid making half the community scream in terror and endlessly ask for the removal of the feature (like with pmods). -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From vladdu55@REDACTED Tue Jan 22 12:57:47 2013 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Tue, 22 Jan 2013 12:57:47 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <50FE73C0.5000107@ninenines.eu> References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> Message-ID: Hi, On Tue, Jan 22, 2013 at 12:10 PM, Lo?c Hoguin wrote: > On 01/22/2013 07:34 AM, Bj?rn Gustavsson wrote: > >> Why not use the existing -export() attribute and write like >> > this: >> >> -export([monitor/2,demonitor/**1]). >> >> monitor(process, Pid) -> >> do_something. >> >> demonitor(Pid) -> >> do_something_else(). >> >> So what would be the advantage of your version? >> > > It still allows Evan Miller to write this: > > -attr([first_name/1, last_name/1, ...]). > > $handle_undefined_function(F, [Model]) -> > {_, Value} = lists:keyfind(F, 1, Model), > Value. > > I'm sorry, but I don't think you are answering Bj?rn's question. For this particular case, why not write regular Erlang like first_name(Model) -> get(first_name, Model). last_name(Model) -> get(last_name, Model). get(F, [Model]) -> {_, Value} = lists:keyfind(F, 1, Model), Value. which is much clearer to understand. One argument might be that there is some duplication, but I think that it could be handled with much more elegance if we had abstract patterns implemented. Do you have a more relevant example where using $handle_undefined_function gives significant advantage? best regards, Vlad As you can see he doesn't have to worry about adding clauses to handle > undef, which is good. > > This also still allows you to do -extends: > > %% Functions you override. > -export([ponies/1]). > > %% Functions you don't. > -attr([horses/1, cows/1]). > > $handle_undefined_function(F, Args) -> > apply(base_module, F, Args). > > Again you still don't have to handle undef. > > Tools can expect these functions. If you allow specs for undefined > functions then Dialyzer can also act as if they were defined normally. > > Implementing it like this, without pushing the burden of handling undef to > the user, would avoid making half the community scream in terror and > endlessly ask for the removal of the feature (like with pmods). > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > 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 Tue Jan 22 13:02:10 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Tue, 22 Jan 2013 13:02:10 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> Message-ID: <50FE7FC2.90204@ninenines.eu> On 01/22/2013 12:57 PM, Vlad Dumitrescu wrote: > Hi, > > On Tue, Jan 22, 2013 at 12:10 PM, Lo?c Hoguin > wrote: > > On 01/22/2013 07:34 AM, Bj?rn Gustavsson wrote: > > Why not use the existing -export() attribute and write like > > this: > > -export([monitor/2,demonitor/__1]). > > monitor(process, Pid) -> > do_something. > > demonitor(Pid) -> > do_something_else(). > > So what would be the advantage of your version? > > > It still allows Evan Miller to write this: > > -attr([first_name/1, last_name/1, ...]). > > $handle_undefined_function(F, [Model]) -> > {_, Value} = lists:keyfind(F, 1, Model), > Value. > > > I'm sorry, but I don't think you are answering Bj?rn's question. For > this particular case, why not write regular Erlang like > > first_name(Model) -> get(first_name, Model). > last_name(Model) -> get(last_name, Model). > get(F, [Model]) -> > {_, Value} = lists:keyfind(F, 1, Model), > Value. > which is much clearer to understand. One argument might be that there is > some duplication, but I think that it could be handled with much more > elegance if we had abstract patterns implemented. > > Do you have a more relevant example where using > $handle_undefined_function gives significant advantage? That's a question about $handle_undefined_function in general, not about this specific implementation proposal. Bj?rn is the one who wrote the current implementation that's now in master, I don't have to tell him what can be done with it, he knows. I do have to tell him how implementing it this way improves the usage, though. Which is the sole reason of this thread. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From vladdu55@REDACTED Tue Jan 22 13:10:49 2013 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Tue, 22 Jan 2013 13:10:49 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <50FE7FC2.90204@ninenines.eu> References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> Message-ID: On Tue, Jan 22, 2013 at 1:02 PM, Lo?c Hoguin wrote: > On 01/22/2013 12:57 PM, Vlad Dumitrescu wrote: > >> Hi, >> >> On Tue, Jan 22, 2013 at 12:10 PM, Lo?c Hoguin > > wrote: >> >> On 01/22/2013 07:34 AM, Bj?rn Gustavsson wrote: >> >> Why not use the existing -export() attribute and write like >> >> this: >> >> -export([monitor/2,demonitor/_**_1]). >> >> >> monitor(process, Pid) -> >> do_something. >> >> demonitor(Pid) -> >> do_something_else(). >> >> So what would be the advantage of your version? >> >> >> It still allows Evan Miller to write this: >> >> -attr([first_name/1, last_name/1, ...]). >> >> $handle_undefined_function(F, [Model]) -> >> {_, Value} = lists:keyfind(F, 1, Model), >> Value. >> >> >> I'm sorry, but I don't think you are answering Bj?rn's question. For >> this particular case, why not write regular Erlang like >> >> first_name(Model) -> get(first_name, Model). >> last_name(Model) -> get(last_name, Model). >> get(F, [Model]) -> >> {_, Value} = lists:keyfind(F, 1, Model), >> Value. >> which is much clearer to understand. One argument might be that there is >> some duplication, but I think that it could be handled with much more >> elegance if we had abstract patterns implemented. >> >> Do you have a more relevant example where using >> $handle_undefined_function gives significant advantage? >> > > That's a question about $handle_undefined_function in general, not about > this specific implementation proposal. Bj?rn is the one who wrote the > current implementation that's now in master, I don't have to tell him what > can be done with it, he knows. I do have to tell him how implementing it > this way improves the usage, though. Which is the sole reason of this > thread. > Maybe I'm confused, but your answer would make 100% sense if Bj?rn's question would have been " Why not use the existing -export() attribute and write like this: -export([monitor/2,demonitor/1]). $handle_undefined_function(**monitor, [process, Pid]) -> do_something(); $handle_undefined_function(**demonitor, Pid) -> do_something_else(). " My question is a follow-up on his own formulation, where your suggestion is compared with an implementation not using $handle_undefined_function at all. best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Tue Jan 22 13:25:59 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Tue, 22 Jan 2013 13:25:59 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> Message-ID: <50FE8557.3040509@ninenines.eu> On 01/22/2013 01:10 PM, Vlad Dumitrescu wrote: > On Tue, Jan 22, 2013 at 1:02 PM, Lo?c Hoguin > wrote: > > On 01/22/2013 12:57 PM, Vlad Dumitrescu wrote: > > Hi, > > On Tue, Jan 22, 2013 at 12:10 PM, Lo?c Hoguin > > >> wrote: > > On 01/22/2013 07:34 AM, Bj?rn Gustavsson wrote: > > Why not use the existing -export() attribute and write like > > this: > > -export([monitor/2,demonitor/____1]). > > > monitor(process, Pid) -> > do_something. > > demonitor(Pid) -> > do_something_else(). > > So what would be the advantage of your version? > > > It still allows Evan Miller to write this: > > -attr([first_name/1, last_name/1, ...]). > > $handle_undefined_function(F, [Model]) -> > {_, Value} = lists:keyfind(F, 1, Model), > Value. > > > I'm sorry, but I don't think you are answering Bj?rn's question. For > this particular case, why not write regular Erlang like > > first_name(Model) -> get(first_name, Model). > last_name(Model) -> get(last_name, Model). > get(F, [Model]) -> > {_, Value} = lists:keyfind(F, 1, Model), > Value. > which is much clearer to understand. One argument might be that > there is > some duplication, but I think that it could be handled with much > more > elegance if we had abstract patterns implemented. > > Do you have a more relevant example where using > $handle_undefined_function gives significant advantage? > > > That's a question about $handle_undefined_function in general, not > about this specific implementation proposal. Bj?rn is the one who > wrote the current implementation that's now in master, I don't have > to tell him what can be done with it, he knows. I do have to tell > him how implementing it this way improves the usage, though. Which > is the sole reason of this thread. > > > Maybe I'm confused, but your answer would make 100% sense if Bj?rn's > question would have been > > " > Why not use the existing -export() attribute and write like this: > -export([monitor/2,demonitor/1]). > $handle_undefined_function(__monitor, [process, Pid]) -> > do_something(); > $handle_undefined_function(__demonitor, Pid) -> > do_something_else(). > " > > My question is a follow-up on his own formulation, where your suggestion > is compared with an implementation not using $handle_undefined_function > at all. And I answered it based on known potential uses. The snippet you quote was made to demonstrate the flaws in the current implementation, not to demonstrate an interesting use of the feature. It can be demonstrated using Evan's example too, for example: $handle_undefined_function(F, [Model]) when is_list(Model) -> {_, Value} = lists:keyfind(F, 1, Model), Value; $handle_undefined_function(F, Args) -> error_handler:raise_undef_exception(?MODULE, F, Args). This would be an incorrect implementation of Evan's use for it, and nothing about it says "It's obvious!". And yet it's still wrong. Correct implementation would be: $handle_undefined_function(F, [Model]) when is_list(Model) -> {_, Value} = lists:keyfind(F, 1, Model), Value; $handle_undefined_function(F, Args) -> case lists:member({F, length(Args)}, [{first_name, 1}, {last_name, 1}, ...]) of true -> erlang:error(badarg); false -> error_handler:raise_undef_exception(?MODULE, F, Args) end. With my proposal he can write: -attr([first_name/1, last_name/1]). $handle_undefined_function(F, [Model]) when is_list(Model) -> {_, Value} = lists:keyfind(F, 1, Model), Value. This makes error_handler properly handle undef errors, reduces the code needed to use the feature, allow tools to behave nicely when using the feature, etc. As for why Evan would use $handle_undefined_function instead of creating many functions, that's for him to decide. But both implementations of $handle_undefined_function allow all known uses of the feature, yet only one gets error handling and tools support straight. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From vladdu55@REDACTED Tue Jan 22 13:30:30 2013 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Tue, 22 Jan 2013 13:30:30 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <50FE8557.3040509@ninenines.eu> References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> <50FE8557.3040509@ninenines.eu> Message-ID: Ok, I see. I had lost track of who suggested the example originally. I suppose that the functions listed in -attr() would have to be included in an -export() too if they are to be public? regards, Vlad On Tue, Jan 22, 2013 at 1:25 PM, Lo?c Hoguin wrote: > On 01/22/2013 01:10 PM, Vlad Dumitrescu wrote: > >> On Tue, Jan 22, 2013 at 1:02 PM, Lo?c Hoguin > > wrote: >> >> On 01/22/2013 12:57 PM, Vlad Dumitrescu wrote: >> >> Hi, >> >> On Tue, Jan 22, 2013 at 12:10 PM, Lo?c Hoguin >> >> >> wrote: >> >> On 01/22/2013 07:34 AM, Bj?rn Gustavsson wrote: >> >> Why not use the existing -export() attribute and write >> like >> >> this: >> >> -export([monitor/2,demonitor/_**___1]). >> >> >> >> monitor(process, Pid) -> >> do_something. >> >> demonitor(Pid) -> >> do_something_else(). >> >> So what would be the advantage of your version? >> >> >> It still allows Evan Miller to write this: >> >> -attr([first_name/1, last_name/1, ...]). >> >> $handle_undefined_function(F, [Model]) -> >> {_, Value} = lists:keyfind(F, 1, Model), >> Value. >> >> >> I'm sorry, but I don't think you are answering Bj?rn's question. >> For >> this particular case, why not write regular Erlang like >> >> first_name(Model) -> get(first_name, Model). >> last_name(Model) -> get(last_name, Model). >> get(F, [Model]) -> >> {_, Value} = lists:keyfind(F, 1, Model), >> Value. >> which is much clearer to understand. One argument might be that >> there is >> some duplication, but I think that it could be handled with much >> more >> elegance if we had abstract patterns implemented. >> >> Do you have a more relevant example where using >> $handle_undefined_function gives significant advantage? >> >> >> That's a question about $handle_undefined_function in general, not >> about this specific implementation proposal. Bj?rn is the one who >> wrote the current implementation that's now in master, I don't have >> to tell him what can be done with it, he knows. I do have to tell >> him how implementing it this way improves the usage, though. Which >> is the sole reason of this thread. >> >> >> Maybe I'm confused, but your answer would make 100% sense if Bj?rn's >> question would have been >> >> " >> Why not use the existing -export() attribute and write like this: >> -export([monitor/2,demonitor/**1]). >> $handle_undefined_function(__**monitor, [process, Pid]) -> >> do_something(); >> $handle_undefined_function(__**demonitor, Pid) -> >> >> do_something_else(). >> " >> >> My question is a follow-up on his own formulation, where your suggestion >> is compared with an implementation not using $handle_undefined_function >> at all. >> > > And I answered it based on known potential uses. The snippet you quote was > made to demonstrate the flaws in the current implementation, not to > demonstrate an interesting use of the feature. It can be demonstrated using > Evan's example too, for example: > > $handle_undefined_function(F, [Model]) when is_list(Model) -> > > {_, Value} = lists:keyfind(F, 1, Model), > Value; > > $handle_undefined_function(F, Args) -> > error_handler:raise_undef_**exception(?MODULE, F, Args). > > This would be an incorrect implementation of Evan's use for it, and > nothing about it says "It's obvious!". And yet it's still wrong. Correct > implementation would be: > > $handle_undefined_function(F, [Model]) when is_list(Model) -> > > {_, Value} = lists:keyfind(F, 1, Model), > Value; > $handle_undefined_function(F, Args) -> > case lists:member({F, length(Args)}, > [{first_name, 1}, {last_name, 1}, ...]) of > true -> erlang:error(badarg); > false -> error_handler:raise_undef_**exception(?MODULE, F, Args) > end. > > With my proposal he can write: > > -attr([first_name/1, last_name/1]). > > $handle_undefined_function(F, [Model]) when is_list(Model) -> > > {_, Value} = lists:keyfind(F, 1, Model), > Value. > > This makes error_handler properly handle undef errors, reduces the code > needed to use the feature, allow tools to behave nicely when using the > feature, etc. > > As for why Evan would use $handle_undefined_function instead of creating > many functions, that's for him to decide. But both implementations of > $handle_undefined_function allow all known uses of the feature, yet only > one gets error handling and tools support straight. > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Tue Jan 22 13:34:06 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Tue, 22 Jan 2013 13:34:06 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> <50FE8557.3040509@ninenines.eu> Message-ID: <50FE873E.4010009@ninenines.eu> I don't think they can appear as exported, due to error_handler's use of function_exported to know if it's defined. The attribute can be named something like -undef-export([]) though, to make it clearer. Note that the feature is only applicable when the function is called through M:F(...), not local calls, because the module wouldn't compile. On 01/22/2013 01:30 PM, Vlad Dumitrescu wrote: > Ok, I see. I had lost track of who suggested the example originally. > > I suppose that the functions listed in -attr() would have to be included > in an -export() too if they are to be public? > > regards, > Vlad > > > On Tue, Jan 22, 2013 at 1:25 PM, Lo?c Hoguin > wrote: > > On 01/22/2013 01:10 PM, Vlad Dumitrescu wrote: > > On Tue, Jan 22, 2013 at 1:02 PM, Lo?c Hoguin > >> wrote: > > On 01/22/2013 12:57 PM, Vlad Dumitrescu wrote: > > Hi, > > On Tue, Jan 22, 2013 at 12:10 PM, Lo?c Hoguin > > > > > >>> wrote: > > On 01/22/2013 07:34 AM, Bj?rn Gustavsson wrote: > > Why not use the existing -export() attribute > and write like > > this: > > -export([monitor/2,demonitor/______1]). > > > > monitor(process, Pid) -> > do_something. > > demonitor(Pid) -> > do_something_else(). > > So what would be the advantage of your version? > > > It still allows Evan Miller to write this: > > -attr([first_name/1, last_name/1, ...]). > > $handle_undefined_function(F, [Model]) -> > {_, Value} = lists:keyfind(F, 1, Model), > Value. > > > I'm sorry, but I don't think you are answering Bj?rn's > question. For > this particular case, why not write regular Erlang like > > first_name(Model) -> get(first_name, Model). > last_name(Model) -> get(last_name, Model). > get(F, [Model]) -> > {_, Value} = lists:keyfind(F, 1, Model), > Value. > which is much clearer to understand. One argument might > be that > there is > some duplication, but I think that it could be handled > with much > more > elegance if we had abstract patterns implemented. > > Do you have a more relevant example where using > $handle_undefined_function gives significant advantage? > > > That's a question about $handle_undefined_function in > general, not > about this specific implementation proposal. Bj?rn is the > one who > wrote the current implementation that's now in master, I > don't have > to tell him what can be done with it, he knows. I do have > to tell > him how implementing it this way improves the usage, > though. Which > is the sole reason of this thread. > > > Maybe I'm confused, but your answer would make 100% sense if Bj?rn's > question would have been > > " > Why not use the existing -export() attribute and write like > this: > -export([monitor/2,demonitor/__1]). > $handle_undefined_function(____monitor, [process, Pid]) -> > do_something(); > $handle_undefined_function(____demonitor, Pid) -> > > do_something_else(). > " > > My question is a follow-up on his own formulation, where your > suggestion > is compared with an implementation not using > $handle_undefined_function > at all. > > > And I answered it based on known potential uses. The snippet you > quote was made to demonstrate the flaws in the current > implementation, not to demonstrate an interesting use of the > feature. It can be demonstrated using Evan's example too, for example: > > $handle_undefined_function(F, [Model]) when is_list(Model) -> > > {_, Value} = lists:keyfind(F, 1, Model), > Value; > > $handle_undefined_function(F, Args) -> > error_handler:raise_undef___exception(?MODULE, F, Args). > > This would be an incorrect implementation of Evan's use for it, and > nothing about it says "It's obvious!". And yet it's still wrong. > Correct implementation would be: > > $handle_undefined_function(F, [Model]) when is_list(Model) -> > > {_, Value} = lists:keyfind(F, 1, Model), > Value; > $handle_undefined_function(F, Args) -> > case lists:member({F, length(Args)}, > [{first_name, 1}, {last_name, 1}, ...]) of > true -> erlang:error(badarg); > false -> error_handler:raise_undef___exception(?MODULE, F, > Args) > end. > > With my proposal he can write: > > -attr([first_name/1, last_name/1]). > > $handle_undefined_function(F, [Model]) when is_list(Model) -> > > {_, Value} = lists:keyfind(F, 1, Model), > Value. > > This makes error_handler properly handle undef errors, reduces the > code needed to use the feature, allow tools to behave nicely when > using the feature, etc. > > As for why Evan would use $handle_undefined_function instead of > creating many functions, that's for him to decide. But both > implementations of $handle_undefined_function allow all known uses > of the feature, yet only one gets error handling and tools support > straight. > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From yashgt@REDACTED Tue Jan 22 13:36:27 2013 From: yashgt@REDACTED (yashgt@REDACTED) Date: Tue, 22 Jan 2013 12:36:27 +0000 Subject: [erlang-questions] Accessing Mnesia from C++ on Unix Message-ID: <50fe87ea.c2bee00a.7078.ffffa7f5@mx.google.com> An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Tue Jan 22 13:41:11 2013 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 22 Jan 2013 04:41:11 -0800 (PST) Subject: [erlang-questions] SAX-like JSON Parser for Erlang In-Reply-To: <0B25DEFA-2C1C-4AF0-A17A-22CAEFC695A8@cs.otago.ac.nz> References: <1358517301.25429.YahooMailNeo@web120702.mail.ne1.yahoo.com> <0B25DEFA-2C1C-4AF0-A17A-22CAEFC695A8@cs.otago.ac.nz> Message-ID: <1358858471.99223.YahooMailNeo@web120704.mail.ne1.yahoo.com> ----- Original Message ----- > From: Richard O'Keefe > To: Thomas Lindgren > Cc: erlang-questions > Sent: Tuesday, January 22, 2013 6:51 AM > Subject: Re: [erlang-questions] SAX-like JSON Parser for Erlang > > > On 19/01/2013, at 2:55 AM, Thomas Lindgren wrote: > >> >> >> One potential problem with SAX-style parsing is that repeated keys in a > JSON object will use/return only the last value (a behaviour inherited from > javascript, I believe). > > When implementing a JSON parser, I found the JSON specification > silent about this and asked for clarification.? Taking the last > value for repeated keys is *NOT* a defined property of JSON nor > is it something you can expect as a de-facto standard.? Some > parsers will take the first value.? Some will take the last one. > Some will raise a sensible exception.? Some a non-sensible one. Could you give a reference to that clarification? It could be useful in upcoming discussions. Taking the RFC at face value, it seems the behaviour is unspecified (since it only says the use of repeated keys is discouraged). As far as I'm aware, though, the common expectation would be that the decoder behaves "like javascript". I've seen some proposed usage that relies on the parser handling duplicate keys (without throwing exceptions). See the fairly recent node.js mailing list archives. Best, Thomas From g.a.c.rijnders@REDACTED Tue Jan 22 13:59:32 2013 From: g.a.c.rijnders@REDACTED (Michel Rijnders) Date: Tue, 22 Jan 2013 13:59:32 +0100 Subject: [erlang-questions] SAX-like JSON Parser for Erlang In-Reply-To: <0B25DEFA-2C1C-4AF0-A17A-22CAEFC695A8@cs.otago.ac.nz> References: <1358517301.25429.YahooMailNeo@web120702.mail.ne1.yahoo.com> <0B25DEFA-2C1C-4AF0-A17A-22CAEFC695A8@cs.otago.ac.nz> Message-ID: Yep, I was recently looking into this because I'm writing a library that will provide XPath like querying for JSON. The only thing RFC 4627 (JSON) says is: ""The names within an object SHOULD be unique." But this is "should" in the sense of RFC 2119, i.e. it means "recommended"... On Tue, Jan 22, 2013 at 6:51 AM, Richard O'Keefe wrote: > > On 19/01/2013, at 2:55 AM, Thomas Lindgren wrote: > > > > > > > One potential problem with SAX-style parsing is that repeated keys in a > JSON object will use/return only the last value (a behaviour inherited from > javascript, I believe). > > When implementing a JSON parser, I found the JSON specification > silent about this and asked for clarification. Taking the last > value for repeated keys is *NOT* a defined property of JSON nor > is it something you can expect as a de-facto standard. Some > parsers will take the first value. Some will take the last one. > Some will raise a sensible exception. Some a non-sensible one. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- My other car is a cdr. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.charles.davis@REDACTED Tue Jan 22 14:29:54 2013 From: steven.charles.davis@REDACTED (Steve Davis) Date: Tue, 22 Jan 2013 07:29:54 -0600 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: <3F9C345F-57DE-49AA-B7CB-A1B7804D5A51@cs.otago.ac.nz> References: <3F9C345F-57DE-49AA-B7CB-A1B7804D5A51@cs.otago.ac.nz> Message-ID: <836DB9E2-CFF8-4E08-B39F-EF687DDB5BBC@gmail.com> Because I was writing an ETF decoder for a language that does make a distinction between strings and arrays of integers, and wanted to avoid constraints on the kinds of terms that could be sent from the erlang side of things. On Jan 21, 2013, at 11:23 PM, "Richard O'Keefe" wrote: > > On 22/01/2013, at 8:38 AM, Steve Davis wrote: > >> The following appears to encode lists of integers as strings (?!?): >> >> Is there a reason for this that I'm missing? > > Why do you _care_ what the encoding is as long as it decodes correctly? From elbrujohalcon@REDACTED Tue Jan 22 14:39:46 2013 From: elbrujohalcon@REDACTED (Brujo Benavides) Date: Tue, 22 Jan 2013 10:39:46 -0300 Subject: [erlang-questions] Is -extends() used in any projects? In-Reply-To: References: Message-ID: <39AAA92F-57C1-48CF-9090-BFCE589363FF@inaka.net> I can think of this module where I used it to extend some basic Erlang functionality in a similar way than what Kresten at basho-labs did in hanoidb I also did a quick search on github to see who else was using it for open source projects. This is what I've found: - People at Beam.js use it in erlv8 for their objects - Ivan Dubrov uses it in siperl for transactions - claimstrade uses it in maru for its models elbrujohalcon@REDACTED On Jan 22, 2013, at 3:44 AM, Bj?rn Gustavsson wrote: > -extends() was mentioned when we first talked > about removing parameterized modules, so we > assumed that we needed to emulate -extends() > as well as parameterized modules. > > It seems to be a good time to ask the question: > > Is -extends() used by real projects? Do we really > need to emulate it? > > BTW, -extends() is described here: > > http://www.erlang.se/euc/07/papers/1700Carlsson.pdf > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > _______________________________________________ > 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 Tue Jan 22 15:16:40 2013 From: serge@REDACTED (Serge Aleynikov) Date: Tue, 22 Jan 2013 09:16:40 -0500 Subject: [erlang-questions] Accessing Mnesia from C++ on Unix In-Reply-To: <50fe87ea.c2bee00a.7078.ffffa7f5@mx.google.com> References: <50fe87ea.c2bee00a.7078.ffffa7f5@mx.google.com> Message-ID: <50FE9F48.60903@aleynikov.org> There's no standard mnesia API designed specifically for C++/C. A C++ application running in a separate process from an Erlang node running mnesia database can use: 1. A helper application such as webnesia to expose mnesia data through REST: https://github.com/tarpipe/webnesia. 2. Distributed Erlang transport to call mnesia functions (http://www.erlang.org/doc/man/mnesia.html) over RPC using a C++ library such as https://github.com/saleyn/eixx. 3. Your own marshaling protocol over TCP that would serve mnesia data out-of-process. Serge On 1/22/2013 7:36 AM, yashgt@REDACTED wrote: > Hi, > > What is the best and standard way for accessing an Mnesia DB from Unix > in a C++ application? I am aware of 2 options: > > REST API of Mnesia: What is the best C++/C library to use for this? > > Mnesia Sessions API: This seems to be deprecated. > > > > Thanks, > > Yash > > > > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From bgustavsson@REDACTED Tue Jan 22 15:41:16 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Tue, 22 Jan 2013 15:41:16 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <50FE7FC2.90204@ninenines.eu> References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> Message-ID: On Tue, Jan 22, 2013 at 1:02 PM, Lo?c Hoguin wrote: > That's a question about $handle_undefined_function in general, not about > this specific implementation proposal. Bj?rn is the one who wrote the > current implementation that's now in master, I don't have to tell him what > can be done with it, he knows. I do have to tell him how implementing it > this way improves the usage, though. Which is the sole reason of this > thread. > > Except that your "improvements" to $handle_undefined_function renders it completely useless for the problem it was supposed to solve. Namely to emulate the existing -extends() directive, which is used as follows: -extends(Module). where Module is the module to be extended. [1] Your mission, should you decide to accept it, is to implement -extends(Module) in a parse transform. You have no knowledge of the the other module. It might not even exist when the module containing the -extends() directive is compiled; furthermore, if more functions are added to the module being extended in the future, you should still be able to call them from the module containing the -extends() directive (without recompiling it). To make it more concrete, you should implement a parse transform and use it to compile the following module: -module(extender). -extends(mission_impossible). extender should then be able to call any function in the module 'mission_impossible' stored on my computer. That is: extender:foo(42) will call mission_impossible:foo(42) provided that foo/1 is exported from mission_impossible. You may use either the current implementation or your "improved" version of $handle_undefined_function, at your choice. Should any of your computer systems crash or burn, the Secretary will disavow any knowledge of your actions. [2] [1] http://www.erlang.se/euc/07/papers/1700Carlsson.pdf [2] http://en.wikipedia.org/wiki/Mission:_Impossible -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Tue Jan 22 15:49:46 2013 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Tue, 22 Jan 2013 07:49:46 -0700 Subject: [erlang-questions] Is -extends() used in any projects? In-Reply-To: <39AAA92F-57C1-48CF-9090-BFCE589363FF@inaka.net> References: <39AAA92F-57C1-48CF-9090-BFCE589363FF@inaka.net> Message-ID: Is anyone actually relying on the runtime aspect of -extends? The examples above use -extends to extend another module and it happens at runtime. It means that, if you call extending:call() it will delegate propagate at runtime to extended:call(). In erlang/otp master, this propagation happens via '$handle_undefined_function'. However, this could also happen at compilation time. We can imagine a parse transform that handle -extends() in the following way: when you declare -extends(foo) inside a module, the parse transform will get all the functions in the module foo that are not yet defined in the module bar and generate stubs like: call(Arg1, Arg2) -> foo:call(Arg1, Arg2). This has the following advantages: 1. It is faster at runtime; 2. Doesn't require '$handle_undefined_function'; 3. Calling bar:module_info(exports) will also reveal the functions "inherited" from foo, so it is clearer in behaviour too However, it has the following disadvantages: 1. It requires module foo to be compiled before bar. I don't believe this is an issue as it is easy to tweak your Makefile or your rebar.config; 2. If the module foo is hot loaded in production, the new functions added in foo are not going to appear in bar if it is not recompiled as well Even if someone is relying on this particular aspect (2) of extends, all they have to do is to accordingly include their updated version of bar in the upgrade recipes as well. It seems to be a fair trade-off for faster and simpler runtime semantics, unless, of course, I am missing something. *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer On Tue, Jan 22, 2013 at 6:39 AM, Brujo Benavides wrote: > I can think of this module where > I used it to extend some basic Erlang functionality in a similar way than > what Kresten at basho-labs did in hanoidb > > I also did a quick search on github to see who else was using it for open > source projects. This is what I've found: > > - People at Beam.js use it in erlv8 > for their objects > - Ivan Dubrov uses it in siperl > for transactions > - claimstrade uses it in maru > for its models > > elbrujohalcon@REDACTED > > > On Jan 22, 2013, at 3:44 AM, Bj?rn Gustavsson wrote: > > -extends() was mentioned when we first talked > about removing parameterized modules, so we > assumed that we needed to emulate -extends() > as well as parameterized modules. > > It seems to be a good time to ask the question: > > Is -extends() used by real projects? Do we really > need to emulate it? > > BTW, -extends() is described here: > > http://www.erlang.se/euc/07/papers/1700Carlsson.pdf > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-questions mailing list > 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 Tue Jan 22 16:07:34 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 22 Jan 2013 16:07:34 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> Message-ID: <50FEAB36.5010102@ninenines.eu> On 01/22/2013 03:41 PM, Bj?rn Gustavsson wrote: > On Tue, Jan 22, 2013 at 1:02 PM, Lo?c Hoguin > wrote: > > That's a question about $handle_undefined_function in general, not > about this specific implementation proposal. Bj?rn is the one who > wrote the current implementation that's now in master, I don't have > to tell him what can be done with it, he knows. I do have to tell > him how implementing it this way improves the usage, though. Which > is the sole reason of this thread. > > > Except that your "improvements" to $handle_undefined_function > renders it completely useless for the problem it was supposed > to solve. > > Namely to emulate the existing -extends() directive, which is > used as follows: > > -extends(Module). > > where Module is the module to be extended. [1] > > Your mission, should you decide to accept it, > is to implement -extends(Module) in a parse transform. > > You have no knowledge of the the other module. This statement alone makes me go back to thinking -extends() should be dropped, and if not, $handle_undefined_function shouldn't be used and should be dropped; it's incompatible with tools, prone to user error, and is going to make half the community scream in terror. As Jose Valim said right after you, the parse transform can simply look at the original module directly. If it can't, then there's no fixing it. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From Ola.Backstrom@REDACTED Tue Jan 22 16:10:34 2013 From: Ola.Backstrom@REDACTED (=?iso-8859-1?Q?Ola__B=E4ckstr=F6m?=) Date: Tue, 22 Jan 2013 15:10:34 +0000 Subject: [erlang-questions] Dialyzer treats -opaque types different? Message-ID: I've not used -opaque type specifiers much, but so far I've gotten the impression that it should be the same as -type within the module the type is declared in. Now I'm facing differences ... why? :) I've managed to reduce my real source code down to a small snippet. I have a custom type mytest() that I'd like to make opaque for other modules. But here is the first version: -module(dummy). -export([test/1]). -type mytype() :: proplists:proplist() | atom(). -spec test(A :: mytype()) -> term(). test(A) -> case something(A) of true -> throw(up); _ -> proplists:get_value(test, A) end. -spec something(A :: mytype()) -> boolean(). something(A) -> is_atom(A). Dialyzer reports no issue on the above snippet. If I change the type to opaque in line 3: -opaque mytype() :: proplists:proplist() | atom(). then Dialyzer reports: dummy.erl:6: Function test/1 has no local return dummy.erl:11: The call proplists:get_value('test',A::dummy:mytype()) contains an opaque term as 2nd argument when terms of different types are expected in these positions Then adding module name to the type reference in the 2 function specs: -spec test(A :: dummy:mytype()) -> term(). and -spec something(A :: dummy:mytype()) -> boolean(). makes Dialyzer happy again. Why? And do I have a type error or not :) /Ola -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.boyer@REDACTED Tue Jan 22 16:38:58 2013 From: eric.boyer@REDACTED (Eric Boyer) Date: Tue, 22 Jan 2013 10:38:58 -0500 Subject: [erlang-questions] Erlang VM Crash and Heart doesn't restart Message-ID: Hi there, We're running R15B02 on Windows Server 2008 R2 on a mainly IO bound application. Occasionally when it get busy processing hundreds of files it will crash with the following event log entry: Faulting application name: erl.exe, version: 0.0.0.0, time stamp: 0x504492cf Faulting module name: beam.smp.dll, version: 0.0.0.0, time stamp: 0x50449201 Exception code: 0xc0000005 Fault offset: 0x00000000000c75f2 Faulting process id: 0x9d3c Faulting application start time: 0x01cdf82413c26aeb There is no erl_crash.dump generated and the heart process does not restart the vm. Are there any ideas as to why this is happening or what can be done so that heart can properly restart the vm? I see the heart.exe process active with the correct pid for the erlang process but it doesn't seem to work in this case. Thanks, Eric Additional Information: vm.args is: ## Name of the node -name ## Cookie for distributed erlang -setcookie ## Heartbeat management; auto-restarts VM if it dies or becomes unresponsive ## (Disabled by default..use with caution!) -heart ## Enable kernel poll and a few async threads +K true +A 32 +P 1000000 ## Increase number of concurrent ports/sockets -env ERL_MAX_PORTS 100000 ## Tweak GC to run more often -env ERL_FULLSWEEP_AFTER 10 os:getenv("HEART_COMMAND") returns: %node_root%\bin\%node_name%.cmd start -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Tue Jan 22 16:39:41 2013 From: tony@REDACTED (Tony Rogvall) Date: Tue, 22 Jan 2013 16:39:41 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <50FEAB36.5010102@ninenines.eu> References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> <50FEAB36.5010102@ninenines.eu> Message-ID: <3BF69263-7CB0-4157-BB1A-0714342566F3@rogvall.se> Regardless of -extends() should be dropped or not I think $handle_undefined_function is a great addition to the runtime system. It allows for various experiments and hacks. No one forces you or any other one to use it. So please just look in an other direction for a while. Screaming in terror? Stop being such a wimp. /Tony > > This statement alone makes me go back to thinking -extends() should be dropped, and if not, $handle_undefined_function shouldn't be used and should be dropped; it's incompatible with tools, prone to user error, and is going to make half the community scream in terror. > > As Jose Valim said right after you, the parse transform can simply look at the original module directly. If it can't, then there's no fixing it. > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Tue Jan 22 17:05:21 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Tue, 22 Jan 2013 17:05:21 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <3BF69263-7CB0-4157-BB1A-0714342566F3@rogvall.se> References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> <50FEAB36.5010102@ninenines.eu> <3BF69263-7CB0-4157-BB1A-0714342566F3@rogvall.se> Message-ID: <50FEB8C1.2090206@ninenines.eu> You missed the humor. No one forces me, or anyone else, to use it. Indeed we can recommend people not use it and tell people to avoid using libraries that are using it, and if they still do tell them to *really* be careful about it. All this not because we think the *feature* is bad, but because the *implementation* can easily lead to user error. On 01/22/2013 04:39 PM, Tony Rogvall wrote: > Regardless of -extends() should be dropped or not I think > $handle_undefined_function is a great addition > to the runtime system. It allows for various experiments and hacks. No > one forces you or any other one to > use it. So please just look in an other direction for a while. Screaming > in terror? Stop being such a wimp. > > /Tony > >> >> This statement alone makes me go back to thinking -extends() should be >> dropped, and if not, $handle_undefined_function shouldn't be used and >> should be dropped; it's incompatible with tools, prone to user error, >> and is going to make half the community scream in terror. >> >> As Jose Valim said right after you, the parse transform can simply >> look at the original module directly. If it can't, then there's no >> fixing it. >> >> -- >> Lo?c Hoguin >> Erlang Cowboy >> Nine Nines >> http://ninenines.eu >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > "Installing applications can lead to corruption over time. Applications > gradually write over each other's libraries, partial upgrades occur, > user and system errors happen, and minute changes may be unnoticeable > and difficult to fix" > > > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From ulf@REDACTED Tue Jan 22 17:11:38 2013 From: ulf@REDACTED (Ulf Wiger) Date: Tue, 22 Jan 2013 17:11:38 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <50FEB8C1.2090206@ninenines.eu> References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> <50FEAB36.5010102@ninenines.eu> <3BF69263-7CB0-4157-BB1A-0714342566F3@rogvall.se> <50FEB8C1.2090206@ninenines.eu> Message-ID: On 22 Jan 2013, at 17:05, Lo?c Hoguin wrote: > No one forces me, or anyone else, to use it. Indeed we can recommend people not use it and tell people to avoid using libraries that are using it, and if they still do tell them to *really* be careful about it. All this not because we think the *feature* is bad, but because the *implementation* can easily lead to user error. This happens to be the exact same advice as for the original error_handler and libraries that rely on error_handler modifications - although the risk of collateral damage is much smaller with $handle_undefined_function... BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From tyron.zerafa@REDACTED Tue Jan 22 18:21:17 2013 From: tyron.zerafa@REDACTED (Tyron Zerafa) Date: Tue, 22 Jan 2013 18:21:17 +0100 Subject: [erlang-questions] Function Reference to Code Tree Message-ID: F = fun(X,Y) -> X+Y end, In the above statement, F is just a function reference. Can I get the syntax, code tree or anything else from this variable? All I need is to extract the syntax out of a function reference. Any ideas how I can achieve this? The following convert a fun string into an actual fun. I need something the other way round, any ideas ?? {ok,Tks,_} = erl_scan:string(FunString), {ok,E} = erl_parse:parse_exprs(Tks), {value,Funs,_} = erl_eval:exprs(E,[]) Thanks :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.virding@REDACTED Tue Jan 22 18:35:48 2013 From: robert.virding@REDACTED (Robert Virding) Date: Tue, 22 Jan 2013 17:35:48 +0000 (GMT) Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: <836DB9E2-CFF8-4E08-B39F-EF687DDB5BBC@gmail.com> Message-ID: <1127346428.2964860.1358876148647.JavaMail.root@erlang-solutions.com> I don't see the problem. Erlang doesn't have strings, it only has lists of integers so unless you start tagging things there is no safe way to differentiate between them. As a general list can be a list of anything so the encoding must be able to handle this. However, the encoding special cases a list of small (<256) integers and uses a more compact representation. That it calls it a STRING_EXT doesn't really mean anything, they could just as well have called it LIST_OF_SMALL_INTEGER_EXT instead. The description of STRING_EXT actually says this: "String does NOT have a corresponding Erlang representation, but is an optimization for sending lists of bytes (integer in the range 0-255) more efficiently over the distribution." So why not just treat it as such? Robert ----- Original Message ----- > From: "Steve Davis" > To: "Richard O'Keefe" > Cc: "Erlang Questions" > Sent: Tuesday, 22 January, 2013 2:29:54 PM > Subject: Re: [erlang-questions] unexpected result of term_to_binary > > Because I was writing an ETF decoder for a language that does make a > distinction between strings and arrays of integers, and wanted to > avoid constraints on the kinds of terms that could be sent from the > erlang side of things. > > On Jan 21, 2013, at 11:23 PM, "Richard O'Keefe" > wrote: > > > > > On 22/01/2013, at 8:38 AM, Steve Davis wrote: > > > >> The following appears to encode lists of integers as strings > >> (?!?): > >> > >> Is there a reason for this that I'm missing? > > > > Why do you _care_ what the encoding is as long as it decodes > > correctly? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From alessandro.sivieri@REDACTED Tue Jan 22 18:42:00 2013 From: alessandro.sivieri@REDACTED (Alessandro Sivieri) Date: Tue, 22 Jan 2013 18:42:00 +0100 Subject: [erlang-questions] On internals of the VM and message delivery Message-ID: Hi all, probably someone in this ml is able to give me a pointer to the correct source code: I am trying to follow the path of a message from the send operation in Erlang to the driver through the VM, and from the reception of the packets from the network to the delivery of the message in Erlang (when the "receive" operator is used). Now, I was able to follow the "send" path thoroughly, but I am stuck in the "receive" path: I went from the io.c:driver_output to dist.c:erts_net_message to erl_message.c:erts_queue_dist_message, and at this point the received message is put inside the process queue. Where is the message extracted then? I guess that somewhere the message is taken from the queue, the binary stream (the message, because the header is already extracted in dist.c) unpacked into a term and the term given to the process, and in particular I am looking for the place where the term is unpacked... P.S.: sorry if the request is so low level :) -- Sivieri Alessandro alessandro.sivieri@REDACTED http://sivieri.wordpress.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Tue Jan 22 19:16:42 2013 From: tony@REDACTED (Tony Rogvall) Date: Tue, 22 Jan 2013 19:16:42 +0100 Subject: [erlang-questions] On internals of the VM and message delivery In-Reply-To: References: Message-ID: <8C5D5AA1-9539-487C-A0B0-08A3E1E1B93C@rogvall.se> It's in opcodes, look in beam_emu.c Search for OpCase(recv_mark_f) there is even some ascii art showing the processes (not sure if it is up to date) /Tony On 22 jan 2013, at 18:42, Alessandro Sivieri wrote: > Hi all, > > probably someone in this ml is able to give me a pointer to the correct source code: I am trying to follow the path of a message from the send operation in Erlang to the driver through the VM, and from the reception of the packets from the network to the delivery of the message in Erlang (when the "receive" operator is used). > Now, I was able to follow the "send" path thoroughly, but I am stuck in the "receive" path: I went from the io.c:driver_output to dist.c:erts_net_message to erl_message.c:erts_queue_dist_message, and at this point the received message is put inside the process queue. > Where is the message extracted then? I guess that somewhere the message is taken from the queue, the binary stream (the message, because the header is already extracted in dist.c) unpacked into a term and the term given to the process, and in particular I am looking for the place where the term is unpacked... > > P.S.: sorry if the request is so low level :) > > -- > Sivieri Alessandro > alessandro.sivieri@REDACTED > http://sivieri.wordpress.com/ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From emmiller@REDACTED Tue Jan 22 19:30:45 2013 From: emmiller@REDACTED (Evan Miller) Date: Tue, 22 Jan 2013 12:30:45 -0600 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <50FE8557.3040509@ninenines.eu> References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> <50FE8557.3040509@ninenines.eu> Message-ID: On Tue, Jan 22, 2013 at 6:25 AM, Lo?c Hoguin wrote: > > As for why Evan would use $handle_undefined_function instead of creating many functions, that's for him to decide. But both implementations of $handle_undefined_function allow all known uses of the feature, yet only one gets error handling and tools support straight. > Since my name is being thrown around as a sort of bugaboo and a way to scare programmers' children with night-time stories, I'd like to clarify why exactly I support horrible features like Pmods and $handle_undefined_function in the Erlang run-time. Most people on this list seem to care about "big-scale" issues like reliability, predictability, processing kajillions of commercial transactions, and so forth. I happen to care a lot more about "small-scale" issues -- in particular, the programming experience of one person just trying to get something to work for the first time and having the code look nice. I think that's ultimately where innovation comes from -- one person experimenting around, seeing if things work, and not caring whether it's production-ready or fit to be seen by anyone. I worry that Erlang is missing out on a lot of potential developer talent because the platform's benefits tend to be back-loaded: it's great for the big-scale stuff, but it can be painful for a newcomer just tinkering around and seeing if stuff works. A hobbyist has to be both extremely tenacious and perhaps delusional to stick with Erlang long enough to realize the platform's benefits. For example, Erlang is missing one feature found in every other language that I've used that is missing from Erlang. It's the ability to write: Person.name Not Person#person.name, not person:name(Person), not proplists:get_value, not dict:fetch, just plain old stupid anyone-who-has-ever-looked-at-a-programming-language-before-can-understand: Person Dot Name. Every other language I can think of has something like this, whether it's person.name, person->name, $person{name}, or person.name(). I wonder how many potential Erlang programmers moved on to something else because they couldn't find this very simple language construct while they were playing around with Erlang for the first time. Thanks to Pmods and some code generation, I was able to come up with what I felt was acceptable alternative in Erlang: Person:name(). If Erlang ever gets any kind of native support for syntax that looks like that, I honestly won't care so much about Pmods. That brings me to $handle_undefined_function. I won't actually use it in production (much), since I'd rather have compile-time checks for my generated functions, and I have most of the code generation I need at this point. But it would have made my life a lot easier while I was prototyping the library that later became BossDB. So that's why I think it's necessary: to make it easier to experiment with ideas before sweating it out with the dark arts of code generation. I'd like to reiterate my proposal for $should_handle_undefined_function as a way to resolve Lo?c's concerns while preserving the dynamic nature of $handle_undefined_function. Some interesting use-cases that come to mind for me are a dynamic API like: person:find_by_name("Joseph") Is that a good API? I don't know, but I'd like to be able to experiment with it, get a feel for it, and move on to something else quickly if it turns out to be a bad idea. I'm sure people will immediately tell me that the "right" way to do it is find(person, name, "Joseph") or something. But maybe it's not -- maybe the increase in readability is worth the loss in generality. Readability and familiarity are really important for attracting hobbyist programmers, who have a lot to contribute to any platform, and whose interests I try represent on this list as best I can. Evan > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Evan Miller http://www.evanmiller.org/ From tristan.sloughter@REDACTED Tue Jan 22 20:09:40 2013 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Tue, 22 Jan 2013 13:09:40 -0600 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> <50FE8557.3040509@ninenines.eu> Message-ID: Honestly this sounds like wanting Elixir. ChicagoBoss and BossDB would still have the benefits of the Erlang VM and also have the style of coding you are looking for. Tristan On Tue, Jan 22, 2013 at 12:30 PM, Evan Miller wrote: > On Tue, Jan 22, 2013 at 6:25 AM, Lo?c Hoguin wrote: > > > > As for why Evan would use $handle_undefined_function instead of creating > many functions, that's for him to decide. But both implementations of > $handle_undefined_function allow all known uses of the feature, yet only > one gets error handling and tools support straight. > > > > Since my name is being thrown around as a sort of bugaboo and a way to > scare programmers' children with night-time stories, I'd like to > clarify why exactly I support horrible features like Pmods and > $handle_undefined_function in the Erlang run-time. > > Most people on this list seem to care about "big-scale" issues like > reliability, predictability, processing kajillions of commercial > transactions, and so forth. I happen to care a lot more about > "small-scale" issues -- in particular, the programming experience of > one person just trying to get something to work for the first time and > having the code look nice. I think that's ultimately where innovation > comes from -- one person experimenting around, seeing if things work, > and not caring whether it's production-ready or fit to be seen by > anyone. > > I worry that Erlang is missing out on a lot of potential developer > talent because the platform's benefits tend to be back-loaded: it's > great for the big-scale stuff, but it can be painful for a newcomer > just tinkering around and seeing if stuff works. A hobbyist has to be > both extremely tenacious and perhaps delusional to stick with Erlang > long enough to realize the platform's benefits. > > For example, Erlang is missing one feature found in every other > language that I've used that is missing from Erlang. It's the ability > to write: > > Person.name > > Not Person#person.name, not person:name(Person), not > proplists:get_value, not dict:fetch, just plain old stupid > anyone-who-has-ever-looked-at-a-programming-language-before-can-understand: > Person Dot Name. Every other language I can think of has something > like this, whether it's person.name, person->name, $person{name}, or > person.name(). I wonder how many potential Erlang programmers moved on > to something else because they couldn't find this very simple language > construct while they were playing around with Erlang for the first > time. > > Thanks to Pmods and some code generation, I was able to come up with > what I felt was acceptable alternative in Erlang: Person:name(). If > Erlang ever gets any kind of native support for syntax that looks like > that, I honestly won't care so much about Pmods. > > That brings me to $handle_undefined_function. I won't actually use it > in production (much), since I'd rather have compile-time checks for my > generated functions, and I have most of the code generation I need at > this point. But it would have made my life a lot easier while I was > prototyping the library that later became BossDB. So that's why I > think it's necessary: to make it easier to experiment with ideas > before sweating it out with the dark arts of code generation. > > I'd like to reiterate my proposal for > $should_handle_undefined_function as a way to resolve Lo?c's concerns > while preserving the dynamic nature of $handle_undefined_function. > Some interesting use-cases that come to mind for me are a dynamic API > like: > > person:find_by_name("Joseph") > > Is that a good API? I don't know, but I'd like to be able to > experiment with it, get a feel for it, and move on to something else > quickly if it turns out to be a bad idea. I'm sure people will > immediately tell me that the "right" way to do it is find(person, > name, "Joseph") or something. But maybe it's not -- maybe the increase > in readability is worth the loss in generality. Readability and > familiarity are really important for attracting hobbyist programmers, > who have a lot to contribute to any platform, and whose interests I > try represent on this list as best I can. > > Evan > > > > > > > -- > > Lo?c Hoguin > > Erlang Cowboy > > Nine Nines > > http://ninenines.eu > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > Evan Miller > http://www.evanmiller.org/ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyron.zerafa@REDACTED Tue Jan 22 20:11:27 2013 From: tyron.zerafa@REDACTED (Tyron Zerafa) Date: Tue, 22 Jan 2013 20:11:27 +0100 Subject: [erlang-questions] Function Reference to Code Tree In-Reply-To: References: Message-ID: Erlang:fun_info(F) is returning the function body because it is constructed in the shell which essentially passes the entire code tree to the erl_eval module for execution. If you call this for a function constructed in a module, you won't get this tree. I need something along these lines that work for functions constructed in modules rather than the shell. On Tue, Jan 22, 2013 at 8:05 PM, Gianfranco Alongi < gianfranco.alongi@REDACTED> wrote: > Is this what you are after? > > 1> F = fun(X,Y) -> X + Y end.#Fun >2 > > 2> erlang:fun_info(F). > [{pid,<0.31.0>}, {module,erl_eval}, {new_index,3}, > {new_uniq,<<251,3,184,152,93,16,176,57,2,110,24,202,39, > 247,72,160>>}, {index,12}, {uniq,107821302}, {name,'-expr/5-fun-3-'}, > {arity,2}, {env,[[], {value,#Fun}, > {eval,#Fun}, [{clause,1, > [{var,1,'X'},{var,1,'Y'}], [], > [{op,1,'+',{var,1,'X'},{var,1,...}}]}]]}, {type,local}] > 3> > > > On Tue, Jan 22, 2013 at 6:21 PM, Tyron Zerafa wrote: > >> F = fun(X,Y) -> X+Y end, >> >> In the above statement, F is just a function reference. Can I get the >> syntax, code tree or anything else from this variable? All I need is to >> extract the syntax out of a function reference. Any ideas how I can achieve >> this? >> >> The following convert a fun string into an actual fun. I need something >> the other way round, any ideas ?? >> >> >> {ok,Tks,_} = erl_scan:string(FunString), >> {ok,E} = erl_parse:parse_exprs(Tks), >> {value,Funs,_} = erl_eval:exprs(E,[]) >> >> Thanks :) >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- Best Regards, Tyron Zerafa -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.charles.davis@REDACTED Tue Jan 22 20:18:44 2013 From: steven.charles.davis@REDACTED (Steve Davis) Date: Tue, 22 Jan 2013 13:18:44 -0600 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: <1127346428.2964860.1358876148647.JavaMail.root@erlang-solutions.com> References: <1127346428.2964860.1358876148647.JavaMail.root@erlang-solutions.com> Message-ID: Let's just say that I'm now sorry I asked the question in the first place. I have a decent, unambiguous solution to the issue. However, to name that byte flag STRING_EXT is simply dishonest and misleading. And apart from erl_scan that Ulf mentioned, consider the meaning of this module for erlang: http://www.erlang.org/doc/man/string.html Finally, if you search this list you'll see I have a history of promoting the revocation of the whole concept of a "string" in erlang. I don't see how it's possible to deny the existence of this concept since it is plainly obvious that the platform does makes implicit decisions about text as soon as you type [65,66,67] in the REPL. BR, /s On Jan 22, 2013, at 11:35 AM, Robert Virding wrote: > I don't see the problem. Erlang doesn't have strings, it only has lists of integers so unless you start tagging things there is no safe way to differentiate between them. As a general list can be a list of anything so the encoding must be able to handle this. However, the encoding special cases a list of small (<256) integers and uses a more compact representation. That it calls it a STRING_EXT doesn't really mean anything, they could just as well have called it LIST_OF_SMALL_INTEGER_EXT instead. The description of STRING_EXT actually says this: > > "String does NOT have a corresponding Erlang representation, but is an optimization for sending lists of bytes (integer in the range 0-255) more efficiently over the distribution." > > So why not just treat it as such? > > Robert > > ----- Original Message ----- >> From: "Steve Davis" >> To: "Richard O'Keefe" >> Cc: "Erlang Questions" >> Sent: Tuesday, 22 January, 2013 2:29:54 PM >> Subject: Re: [erlang-questions] unexpected result of term_to_binary >> >> Because I was writing an ETF decoder for a language that does make a >> distinction between strings and arrays of integers, and wanted to >> avoid constraints on the kinds of terms that could be sent from the >> erlang side of things. >> >> On Jan 21, 2013, at 11:23 PM, "Richard O'Keefe" >> wrote: >> >>> >>> On 22/01/2013, at 8:38 AM, Steve Davis wrote: >>> >>>> The following appears to encode lists of integers as strings >>>> (?!?): >>>> >>>> Is there a reason for this that I'm missing? >>> >>> Why do you _care_ what the encoding is as long as it decodes >>> correctly? >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> From qoocku@REDACTED Tue Jan 22 20:46:33 2013 From: qoocku@REDACTED (=?UTF-8?B?RGFtaWFuIERvYnJvY3p5xYRza2k=?=) Date: Tue, 22 Jan 2013 20:46:33 +0100 Subject: [erlang-questions] Is -extends() used in any projects? In-Reply-To: References: Message-ID: <50FEEC99.4050108@gmail.com> Yes, we use it in our real-world product (http://www.mfinder.pl/en.pdf) - we have a sort of "basic" communication protocol which may be "extended" - and really is. No big deal, we may program such feature in this way or another. Personally, I would not miss it. -- D. W dniu 22.01.2013 07:44, Bj?rn Gustavsson pisze: > -extends() was mentioned when we first talked > about removing parameterized modules, so we > assumed that we needed to emulate -extends() > as well as parameterized modules. > > It seems to be a good time to ask the question: > > Is -extends() used by real projects? Do we really > need to emulate it? > > BTW, -extends() is described here: > > http://www.erlang.se/euc/07/papers/1700Carlsson.pdf > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From alisdairsullivan@REDACTED Tue Jan 22 21:34:47 2013 From: alisdairsullivan@REDACTED (alisdair) Date: Tue, 22 Jan 2013 12:34:47 -0800 Subject: [erlang-questions] Question regarding JSX Erlang parser In-Reply-To: <50fe2b87.c368310a.418d.ffff8fbc@mx.google.com> References: <50fe2b87.c368310a.418d.ffff8fbc@mx.google.com> Message-ID: > I came across https://github.com/talentdeficit/jsx. I have a couple of questions regarding this module: > 1. Does it allow us to parse JSON data being served over an HTTP stream? This might be useful for consuming web services that serve JSON. If so, is there any example code that shows how this can be done? > > Yes it does. See https://github.com/talentdeficit/jsx#decode12. > 2. Does it read the entire JSON data into memory or does it behave like a SAX parser where the data is read in chunks? > > > jsx retains just enough context in memory to resume parsing. in most cases very little is retained. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.proctor@REDACTED Tue Jan 22 21:52:59 2013 From: steven.proctor@REDACTED (Steven Proctor) Date: Tue, 22 Jan 2013 14:52:59 -0600 Subject: [erlang-questions] Dallas / Fort Worth Erlang User Group Message-ID: We are starting a Erlang User Group for the Dallas / Fort Worth Metroplex. We have just setup a Meetup.com group for those of you on the list that are in the area. The group can be found here: http://www.erlang.org/mailman/listinfo/erlang-questions We currently have some Erlang in our company, and are wanting to get a user group going to bring the Dallas / Fort Worth community together, and provide a place to share experiences with other developers who are doing Erlang or just starting out. Thanks so much, --Proctor -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmr@REDACTED Tue Jan 22 23:02:07 2013 From: tmr@REDACTED (Tomas Morstein) Date: Tue, 22 Jan 2013 14:02:07 -0800 (PST) Subject: [erlang-questions] Quick connect to another node with erl In-Reply-To: <20130120201620.GA15728@circlewave.net> References: <29954670-7D8E-4F94-8547-E7A2D7C3984B@tty.nl> <20130120201620.GA15728@circlewave.net> Message-ID: <35da1108-1647-4070-88b6-ed2de11ee1ec@googlegroups.com> Dne ned?le, 20. ledna 2013 21:16:20 UTC+1 Jachym Holecek napsal(a): > > # Ward Bekker (TTY) 2013-01-20: > > I want to connect to the shell on node bar@REDACTED My current > solution > > (see below) needs some user switch commands. Is there a way using CL > > arguments? Couldn't find a mention in the erl man page. > > Yes, using -remsh, like this: > > Terminal 1: > # erl -sname foo -setcookie abc > Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:4:4] [rq:4] > [async-threads:0] [kernel-poll:false] > > Eshell V5.8.5 (abort with ^G) It's worth to note that `remsh' should be used with extra care, especially when it comes to connecting live production systems. Time by time, it happens (at least to me) that someone accidentally issues `q().' instead of ^G-q. The result is remote node shutdown what is usually not what we wanted to do, although `q().' is good habit otherwise :) That's why I would recommend you to use extra VM options to restrict the shell and block at least `q()' and friends (well, I've never seen anybody who accidentally typed `init:stop()' yet :-) ). In production, we do it like this: `+Bi -stdlib restricted_shell shell_restriction_policy_mod' -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Tue Jan 22 23:05:33 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 22 Jan 2013 23:05:33 +0100 Subject: [erlang-questions] Quick connect to another node with erl In-Reply-To: <35da1108-1647-4070-88b6-ed2de11ee1ec@googlegroups.com> References: <29954670-7D8E-4F94-8547-E7A2D7C3984B@tty.nl> <20130120201620.GA15728@circlewave.net> <35da1108-1647-4070-88b6-ed2de11ee1ec@googlegroups.com> Message-ID: <50FF0D2D.1070906@ninenines.eu> On 01/22/2013 11:02 PM, Tomas Morstein wrote: > Dne ned?le, 20. ledna 2013 21:16:20 UTC+1 Jachym Holecek napsal(a): > > # Ward Bekker (TTY) 2013-01-20: > > I want to connect to the shell on node bar@REDACTED My current > solution > > (see below) needs some user switch commands. Is there a way using CL > > arguments? Couldn't find a mention in the erl man page. > > Yes, using -remsh, like this: > > Terminal 1: > # erl -sname foo -setcookie abc > Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:4:4] > [rq:4] [async-threads:0] [kernel-poll:false] > > Eshell V5.8.5 (abort with ^G) > > > It's worth to note that `remsh' should be used with extra care, especially > when it comes to connecting live production systems. > Time by time, it happens (at least to me) that someone accidentally > issues `q().' instead of ^G-q. The result is remote node shutdown what > is usually not what we wanted to do, although `q().' is good habit > otherwise :) > > That's why I would recommend you to use extra VM options to restrict > the shell and block at least `q()' and friends (well, I've never seen > anybody who accidentally typed `init:stop()' yet :-) ). init:stop() seems to stop the local node, not the remote node. > In production, we do it like this: `+Bi -stdlib restricted_shell > shell_restriction_policy_mod' Nice advice. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From steven.proctor@REDACTED Tue Jan 22 23:34:13 2013 From: steven.proctor@REDACTED (Steven Proctor) Date: Tue, 22 Jan 2013 16:34:13 -0600 Subject: [erlang-questions] Dallas / Fort Worth Erlang User Group In-Reply-To: References: Message-ID: Sorry about the url, didn't capture the link to the Meetup group in the clipboard. Here is the page for the new group: http://www.meetup.com/DFW-Erlang-User-Group/ On Tue, Jan 22, 2013 at 2:52 PM, Steven Proctor wrote: > We are starting a Erlang User Group for the Dallas / Fort Worth Metroplex. > We have just setup a Meetup.com group for those of you on the list that > are in the area. The group can be found here: > http://www.erlang.org/mailman/listinfo/erlang-questions > > We currently have some Erlang in our company, and are wanting to get a > user group going to bring the Dallas / Fort Worth community together, and > provide a place to share experiences with other developers who are doing > Erlang or just starting out. > > Thanks so much, > --Proctor > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yrashk@REDACTED Tue Jan 22 23:48:07 2013 From: yrashk@REDACTED (Yurii Rashkovskii) Date: Tue, 22 Jan 2013 14:48:07 -0800 (PST) Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> <50FE8557.3040509@ninenines.eu> Message-ID: <1299e38d-bdd6-4623-837c-5a4079a8733f@googlegroups.com> Elixir doesn't have any other "undefined function" handling beyond of what Erlang/OTP provides. On Tuesday, January 22, 2013 11:09:40 AM UTC-8, Tristan Sloughter wrote: > > Honestly this sounds like wanting Elixir. > > ChicagoBoss and BossDB would still have the benefits of the Erlang VM and > also have the style of coding you are looking for. > > Tristan > > > On Tue, Jan 22, 2013 at 12:30 PM, Evan Miller > > wrote: > >> On Tue, Jan 22, 2013 at 6:25 AM, Lo?c Hoguin > >> wrote: >> > >> > As for why Evan would use $handle_undefined_function instead of >> creating many functions, that's for him to decide. But both implementations >> of $handle_undefined_function allow all known uses of the feature, yet only >> one gets error handling and tools support straight. >> > >> >> Since my name is being thrown around as a sort of bugaboo and a way to >> scare programmers' children with night-time stories, I'd like to >> clarify why exactly I support horrible features like Pmods and >> $handle_undefined_function in the Erlang run-time. >> >> Most people on this list seem to care about "big-scale" issues like >> reliability, predictability, processing kajillions of commercial >> transactions, and so forth. I happen to care a lot more about >> "small-scale" issues -- in particular, the programming experience of >> one person just trying to get something to work for the first time and >> having the code look nice. I think that's ultimately where innovation >> comes from -- one person experimenting around, seeing if things work, >> and not caring whether it's production-ready or fit to be seen by >> anyone. >> >> I worry that Erlang is missing out on a lot of potential developer >> talent because the platform's benefits tend to be back-loaded: it's >> great for the big-scale stuff, but it can be painful for a newcomer >> just tinkering around and seeing if stuff works. A hobbyist has to be >> both extremely tenacious and perhaps delusional to stick with Erlang >> long enough to realize the platform's benefits. >> >> For example, Erlang is missing one feature found in every other >> language that I've used that is missing from Erlang. It's the ability >> to write: >> >> Person.name >> >> Not Person#person.name, not person:name(Person), not >> proplists:get_value, not dict:fetch, just plain old stupid >> >> anyone-who-has-ever-looked-at-a-programming-language-before-can-understand: >> Person Dot Name. Every other language I can think of has something >> like this, whether it's person.name, person->name, $person{name}, or >> person.name(). I wonder how many potential Erlang programmers moved on >> to something else because they couldn't find this very simple language >> construct while they were playing around with Erlang for the first >> time. >> >> Thanks to Pmods and some code generation, I was able to come up with >> what I felt was acceptable alternative in Erlang: Person:name(). If >> Erlang ever gets any kind of native support for syntax that looks like >> that, I honestly won't care so much about Pmods. >> >> That brings me to $handle_undefined_function. I won't actually use it >> in production (much), since I'd rather have compile-time checks for my >> generated functions, and I have most of the code generation I need at >> this point. But it would have made my life a lot easier while I was >> prototyping the library that later became BossDB. So that's why I >> think it's necessary: to make it easier to experiment with ideas >> before sweating it out with the dark arts of code generation. >> >> I'd like to reiterate my proposal for >> $should_handle_undefined_function as a way to resolve Lo?c's concerns >> while preserving the dynamic nature of $handle_undefined_function. >> Some interesting use-cases that come to mind for me are a dynamic API >> like: >> >> person:find_by_name("Joseph") >> >> Is that a good API? I don't know, but I'd like to be able to >> experiment with it, get a feel for it, and move on to something else >> quickly if it turns out to be a bad idea. I'm sure people will >> immediately tell me that the "right" way to do it is find(person, >> name, "Joseph") or something. But maybe it's not -- maybe the increase >> in readability is worth the loss in generality. Readability and >> familiarity are really important for attracting hobbyist programmers, >> who have a lot to contribute to any platform, and whose interests I >> try represent on this list as best I can. >> >> Evan >> >> > >> > >> > -- >> > Lo?c Hoguin >> > Erlang Cowboy >> > Nine Nines >> > http://ninenines.eu >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-q...@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> >> -- >> Evan Miller >> http://www.evanmiller.org/ >> _______________________________________________ >> erlang-questions mailing list >> erlang-q...@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ababkin@REDACTED Wed Jan 23 00:00:27 2013 From: ababkin@REDACTED (Alex Babkin) Date: Tue, 22 Jan 2013 18:00:27 -0500 Subject: [erlang-questions] possible to use cowboy with websockets in current master? Message-ID: Hi Anyone knows if the websockets are functional in the current cowboy master? I used 0.6 branch but would like to upgrade asap to ensure compatibility with upcoming 0.8. Any examples of the new interface usage? (doesn't look like examples/ contains anything websocket specific) Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From g@REDACTED Wed Jan 23 00:06:19 2013 From: g@REDACTED (Garrett Smith) Date: Tue, 22 Jan 2013 17:06:19 -0600 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <1299e38d-bdd6-4623-837c-5a4079a8733f@googlegroups.com> References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> <50FE8557.3040509@ninenines.eu> <1299e38d-bdd6-4623-837c-5a4079a8733f@googlegroups.com> Message-ID: Looking over Elixir, I tend to agree with Tristan -- it seems to have all the syntactic sugar that creative, non-hardcore, easily frightened developers might like :) In seriousness, it looks like a nice language -- I wonder if it, or the Ruby, Python, JavaScript "front-end" toolsets, might be a better fit for extending Erlang applications to programmers who are looking for a kinder, gentler syntax? On Tue, Jan 22, 2013 at 4:48 PM, Yurii Rashkovskii wrote: > Elixir doesn't have any other "undefined function" handling beyond of what > Erlang/OTP provides. > > > On Tuesday, January 22, 2013 11:09:40 AM UTC-8, Tristan Sloughter wrote: >> >> Honestly this sounds like wanting Elixir. >> >> ChicagoBoss and BossDB would still have the benefits of the Erlang VM and >> also have the style of coding you are looking for. >> >> Tristan >> >> >> On Tue, Jan 22, 2013 at 12:30 PM, Evan Miller wrote: >>> >>> On Tue, Jan 22, 2013 at 6:25 AM, Lo?c Hoguin wrote: >>> > >>> > As for why Evan would use $handle_undefined_function instead of >>> > creating many functions, that's for him to decide. But both implementations >>> > of $handle_undefined_function allow all known uses of the feature, yet only >>> > one gets error handling and tools support straight. >>> > >>> >>> Since my name is being thrown around as a sort of bugaboo and a way to >>> scare programmers' children with night-time stories, I'd like to >>> clarify why exactly I support horrible features like Pmods and >>> $handle_undefined_function in the Erlang run-time. >>> >>> Most people on this list seem to care about "big-scale" issues like >>> reliability, predictability, processing kajillions of commercial >>> transactions, and so forth. I happen to care a lot more about >>> "small-scale" issues -- in particular, the programming experience of >>> one person just trying to get something to work for the first time and >>> having the code look nice. I think that's ultimately where innovation >>> comes from -- one person experimenting around, seeing if things work, >>> and not caring whether it's production-ready or fit to be seen by >>> anyone. >>> >>> I worry that Erlang is missing out on a lot of potential developer >>> talent because the platform's benefits tend to be back-loaded: it's >>> great for the big-scale stuff, but it can be painful for a newcomer >>> just tinkering around and seeing if stuff works. A hobbyist has to be >>> both extremely tenacious and perhaps delusional to stick with Erlang >>> long enough to realize the platform's benefits. >>> >>> For example, Erlang is missing one feature found in every other >>> language that I've used that is missing from Erlang. It's the ability >>> to write: >>> >>> Person.name >>> >>> Not Person#person.name, not person:name(Person), not >>> proplists:get_value, not dict:fetch, just plain old stupid >>> >>> anyone-who-has-ever-looked-at-a-programming-language-before-can-understand: >>> Person Dot Name. Every other language I can think of has something >>> like this, whether it's person.name, person->name, $person{name}, or >>> person.name(). I wonder how many potential Erlang programmers moved on >>> to something else because they couldn't find this very simple language >>> construct while they were playing around with Erlang for the first >>> time. >>> >>> Thanks to Pmods and some code generation, I was able to come up with >>> what I felt was acceptable alternative in Erlang: Person:name(). If >>> Erlang ever gets any kind of native support for syntax that looks like >>> that, I honestly won't care so much about Pmods. >>> >>> That brings me to $handle_undefined_function. I won't actually use it >>> in production (much), since I'd rather have compile-time checks for my >>> generated functions, and I have most of the code generation I need at >>> this point. But it would have made my life a lot easier while I was >>> prototyping the library that later became BossDB. So that's why I >>> think it's necessary: to make it easier to experiment with ideas >>> before sweating it out with the dark arts of code generation. >>> >>> I'd like to reiterate my proposal for >>> $should_handle_undefined_function as a way to resolve Lo?c's concerns >>> while preserving the dynamic nature of $handle_undefined_function. >>> Some interesting use-cases that come to mind for me are a dynamic API >>> like: >>> >>> person:find_by_name("Joseph") >>> >>> Is that a good API? I don't know, but I'd like to be able to >>> experiment with it, get a feel for it, and move on to something else >>> quickly if it turns out to be a bad idea. I'm sure people will >>> immediately tell me that the "right" way to do it is find(person, >>> name, "Joseph") or something. But maybe it's not -- maybe the increase >>> in readability is worth the loss in generality. Readability and >>> familiarity are really important for attracting hobbyist programmers, >>> who have a lot to contribute to any platform, and whose interests I >>> try represent on this list as best I can. >>> >>> Evan >>> >>> > >>> > >>> > -- >>> > Lo?c Hoguin >>> > Erlang Cowboy >>> > Nine Nines >>> > http://ninenines.eu >>> > _______________________________________________ >>> > erlang-questions mailing list >>> > erlang-q...@REDACTED >>> > http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >>> >>> >>> -- >>> Evan Miller >>> http://www.evanmiller.org/ >>> _______________________________________________ >>> 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 essen@REDACTED Wed Jan 23 00:08:57 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Wed, 23 Jan 2013 00:08:57 +0100 Subject: [erlang-questions] possible to use cowboy with websockets in current master? In-Reply-To: References: Message-ID: <50FF1C09.8030801@ninenines.eu> On 01/23/2013 12:00 AM, Alex Babkin wrote: > Hi > > Anyone knows if the websockets are functional in the current cowboy > master? I used 0.6 branch but would like to upgrade asap to ensure > compatibility with upcoming 0.8. Any examples of the new interface usage? > (doesn't look like examples/ contains anything websocket specific) Websocket interface didn't change. Websocket was only made 100% compliant. List of changes from a couple months ago is here: https://github.com/extend/cowboy/blob/master/CHANGELOG.md There's more, it'll be updated after routing changes are done. Otherwise you might want to check the guide: https://github.com/extend/cowboy/tree/master/guide And if something isn't in there, or is unclear, please open a ticket! Thanks. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From yrashk@REDACTED Wed Jan 23 00:11:18 2013 From: yrashk@REDACTED (Yurii Rashkovskii) Date: Tue, 22 Jan 2013 15:11:18 -0800 (PST) Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> <50FE8557.3040509@ninenines.eu> <1299e38d-bdd6-4623-837c-5a4079a8733f@googlegroups.com> Message-ID: <9b9f0f59-d7f3-46a0-8f70-6f10f0f39a13@googlegroups.com> It isn't really much about syntax. It is, however, about 1) macro capabilities, 2) saner and a more consistent stdlib (we already have a fairly good and fast Unicode implementation and a faster hash dictionary) On Tuesday, January 22, 2013 3:06:19 PM UTC-8, Garrett Smith wrote: > > Looking over Elixir, I tend to agree with Tristan -- it seems to have > all the syntactic sugar that creative, non-hardcore, easily frightened > developers might like :) > > In seriousness, it looks like a nice language -- I wonder if it, or > the Ruby, Python, JavaScript "front-end" toolsets, might be a better > fit for extending Erlang applications to programmers who are looking > for a kinder, gentler syntax? > > On Tue, Jan 22, 2013 at 4:48 PM, Yurii Rashkovskii > > wrote: > > Elixir doesn't have any other "undefined function" handling beyond of > what > > Erlang/OTP provides. > > > > > > On Tuesday, January 22, 2013 11:09:40 AM UTC-8, Tristan Sloughter wrote: > >> > >> Honestly this sounds like wanting Elixir. > >> > >> ChicagoBoss and BossDB would still have the benefits of the Erlang VM > and > >> also have the style of coding you are looking for. > >> > >> Tristan > >> > >> > >> On Tue, Jan 22, 2013 at 12:30 PM, Evan Miller > wrote: > >>> > >>> On Tue, Jan 22, 2013 at 6:25 AM, Lo?c Hoguin > wrote: > >>> > > >>> > As for why Evan would use $handle_undefined_function instead of > >>> > creating many functions, that's for him to decide. But both > implementations > >>> > of $handle_undefined_function allow all known uses of the feature, > yet only > >>> > one gets error handling and tools support straight. > >>> > > >>> > >>> Since my name is being thrown around as a sort of bugaboo and a way to > >>> scare programmers' children with night-time stories, I'd like to > >>> clarify why exactly I support horrible features like Pmods and > >>> $handle_undefined_function in the Erlang run-time. > >>> > >>> Most people on this list seem to care about "big-scale" issues like > >>> reliability, predictability, processing kajillions of commercial > >>> transactions, and so forth. I happen to care a lot more about > >>> "small-scale" issues -- in particular, the programming experience of > >>> one person just trying to get something to work for the first time and > >>> having the code look nice. I think that's ultimately where innovation > >>> comes from -- one person experimenting around, seeing if things work, > >>> and not caring whether it's production-ready or fit to be seen by > >>> anyone. > >>> > >>> I worry that Erlang is missing out on a lot of potential developer > >>> talent because the platform's benefits tend to be back-loaded: it's > >>> great for the big-scale stuff, but it can be painful for a newcomer > >>> just tinkering around and seeing if stuff works. A hobbyist has to be > >>> both extremely tenacious and perhaps delusional to stick with Erlang > >>> long enough to realize the platform's benefits. > >>> > >>> For example, Erlang is missing one feature found in every other > >>> language that I've used that is missing from Erlang. It's the ability > >>> to write: > >>> > >>> Person.name > >>> > >>> Not Person#person.name, not person:name(Person), not > >>> proplists:get_value, not dict:fetch, just plain old stupid > >>> > >>> > anyone-who-has-ever-looked-at-a-programming-language-before-can-understand: > >>> Person Dot Name. Every other language I can think of has something > >>> like this, whether it's person.name, person->name, $person{name}, or > >>> person.name(). I wonder how many potential Erlang programmers moved > on > >>> to something else because they couldn't find this very simple language > >>> construct while they were playing around with Erlang for the first > >>> time. > >>> > >>> Thanks to Pmods and some code generation, I was able to come up with > >>> what I felt was acceptable alternative in Erlang: Person:name(). If > >>> Erlang ever gets any kind of native support for syntax that looks like > >>> that, I honestly won't care so much about Pmods. > >>> > >>> That brings me to $handle_undefined_function. I won't actually use it > >>> in production (much), since I'd rather have compile-time checks for my > >>> generated functions, and I have most of the code generation I need at > >>> this point. But it would have made my life a lot easier while I was > >>> prototyping the library that later became BossDB. So that's why I > >>> think it's necessary: to make it easier to experiment with ideas > >>> before sweating it out with the dark arts of code generation. > >>> > >>> I'd like to reiterate my proposal for > >>> $should_handle_undefined_function as a way to resolve Lo?c's concerns > >>> while preserving the dynamic nature of $handle_undefined_function. > >>> Some interesting use-cases that come to mind for me are a dynamic API > >>> like: > >>> > >>> person:find_by_name("Joseph") > >>> > >>> Is that a good API? I don't know, but I'd like to be able to > >>> experiment with it, get a feel for it, and move on to something else > >>> quickly if it turns out to be a bad idea. I'm sure people will > >>> immediately tell me that the "right" way to do it is find(person, > >>> name, "Joseph") or something. But maybe it's not -- maybe the increase > >>> in readability is worth the loss in generality. Readability and > >>> familiarity are really important for attracting hobbyist programmers, > >>> who have a lot to contribute to any platform, and whose interests I > >>> try represent on this list as best I can. > >>> > >>> Evan > >>> > >>> > > >>> > > >>> > -- > >>> > Lo?c Hoguin > >>> > Erlang Cowboy > >>> > Nine Nines > >>> > http://ninenines.eu > >>> > _______________________________________________ > >>> > erlang-questions mailing list > >>> > erlang-q...@REDACTED > >>> > http://erlang.org/mailman/listinfo/erlang-questions > >>> > >>> > >>> > >>> > >>> -- > >>> Evan Miller > >>> http://www.evanmiller.org/ > >>> _______________________________________________ > >>> erlang-questions mailing list > >>> erlang-q...@REDACTED > >>> http://erlang.org/mailman/listinfo/erlang-questions > >> > >> > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-q...@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > 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 Wed Jan 23 00:16:15 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Wed, 23 Jan 2013 00:16:15 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <9b9f0f59-d7f3-46a0-8f70-6f10f0f39a13@googlegroups.com> References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> <50FE8557.3040509@ninenines.eu> <1299e38d-bdd6-4623-837c-5a4079a8733f@googlegroups.com> <9b9f0f59-d7f3-46a0-8f70-6f10f0f39a13@googlegroups.com> Message-ID: <50FF1DBF.1060109@ninenines.eu> I can understand 1), but what's the point of 2)? Wouldn't it be better for that to be in the erlang/otp repository instead so that everything can benefit from it? On 01/23/2013 12:11 AM, Yurii Rashkovskii wrote: > It isn't really much about syntax. It is, however, about 1) macro > capabilities, 2) saner and a more consistent stdlib (we already have a > fairly good and fast Unicode implementation and a faster hash dictionary) > > On Tuesday, January 22, 2013 3:06:19 PM UTC-8, Garrett Smith wrote: > > Looking over Elixir, I tend to agree with Tristan -- it seems to have > all the syntactic sugar that creative, non-hardcore, easily frightened > developers might like :) > > In seriousness, it looks like a nice language -- I wonder if it, or > the Ruby, Python, JavaScript "front-end" toolsets, might be a better > fit for extending Erlang applications to programmers who are looking > for a kinder, gentler syntax? > > On Tue, Jan 22, 2013 at 4:48 PM, Yurii Rashkovskii > wrote: > > Elixir doesn't have any other "undefined function" handling > beyond of what > > Erlang/OTP provides. > > > > > > On Tuesday, January 22, 2013 11:09:40 AM UTC-8, Tristan Sloughter > wrote: > >> > >> Honestly this sounds like wanting Elixir. > >> > >> ChicagoBoss and BossDB would still have the benefits of the > Erlang VM and > >> also have the style of coding you are looking for. > >> > >> Tristan > >> > >> > >> On Tue, Jan 22, 2013 at 12:30 PM, Evan Miller > wrote: > >>> > >>> On Tue, Jan 22, 2013 at 6:25 AM, Lo?c Hoguin > wrote: > >>> > > >>> > As for why Evan would use $handle_undefined_function instead of > >>> > creating many functions, that's for him to decide. But both > implementations > >>> > of $handle_undefined_function allow all known uses of the > feature, yet only > >>> > one gets error handling and tools support straight. > >>> > > >>> > >>> Since my name is being thrown around as a sort of bugaboo and a > way to > >>> scare programmers' children with night-time stories, I'd like to > >>> clarify why exactly I support horrible features like Pmods and > >>> $handle_undefined_function in the Erlang run-time. > >>> > >>> Most people on this list seem to care about "big-scale" issues > like > >>> reliability, predictability, processing kajillions of commercial > >>> transactions, and so forth. I happen to care a lot more about > >>> "small-scale" issues -- in particular, the programming > experience of > >>> one person just trying to get something to work for the first > time and > >>> having the code look nice. I think that's ultimately where > innovation > >>> comes from -- one person experimenting around, seeing if things > work, > >>> and not caring whether it's production-ready or fit to be seen by > >>> anyone. > >>> > >>> I worry that Erlang is missing out on a lot of potential developer > >>> talent because the platform's benefits tend to be back-loaded: > it's > >>> great for the big-scale stuff, but it can be painful for a > newcomer > >>> just tinkering around and seeing if stuff works. A hobbyist has > to be > >>> both extremely tenacious and perhaps delusional to stick with > Erlang > >>> long enough to realize the platform's benefits. > >>> > >>> For example, Erlang is missing one feature found in every other > >>> language that I've used that is missing from Erlang. It's the > ability > >>> to write: > >>> > >>> Person.name > >>> > >>> Not Person#person.name , not > person:name(Person), not > >>> proplists:get_value, not dict:fetch, just plain old stupid > >>> > >>> > anyone-who-has-ever-looked-at-a-programming-language-before-can-understand: > > >>> Person Dot Name. Every other language I can think of has something > >>> like this, whether it's person.name , > person->name, $person{name}, or > >>> person.name (). I wonder how many potential > Erlang programmers moved on > >>> to something else because they couldn't find this very simple > language > >>> construct while they were playing around with Erlang for the first > >>> time. > >>> > >>> Thanks to Pmods and some code generation, I was able to come up > with > >>> what I felt was acceptable alternative in Erlang: > Person:name(). If > >>> Erlang ever gets any kind of native support for syntax that > looks like > >>> that, I honestly won't care so much about Pmods. > >>> > >>> That brings me to $handle_undefined_function. I won't actually > use it > >>> in production (much), since I'd rather have compile-time checks > for my > >>> generated functions, and I have most of the code generation I > need at > >>> this point. But it would have made my life a lot easier while I > was > >>> prototyping the library that later became BossDB. So that's why I > >>> think it's necessary: to make it easier to experiment with ideas > >>> before sweating it out with the dark arts of code generation. > >>> > >>> I'd like to reiterate my proposal for > >>> $should_handle_undefined_function as a way to resolve Lo?c's > concerns > >>> while preserving the dynamic nature of $handle_undefined_function. > >>> Some interesting use-cases that come to mind for me are a > dynamic API > >>> like: > >>> > >>> person:find_by_name("Joseph") > >>> > >>> Is that a good API? I don't know, but I'd like to be able to > >>> experiment with it, get a feel for it, and move on to something > else > >>> quickly if it turns out to be a bad idea. I'm sure people will > >>> immediately tell me that the "right" way to do it is find(person, > >>> name, "Joseph") or something. But maybe it's not -- maybe the > increase > >>> in readability is worth the loss in generality. Readability and > >>> familiarity are really important for attracting hobbyist > programmers, > >>> who have a lot to contribute to any platform, and whose > interests I > >>> try represent on this list as best I can. > >>> > >>> Evan > >>> > >>> > > >>> > > >>> > -- > >>> > Lo?c Hoguin > >>> > Erlang Cowboy > >>> > Nine Nines > >>> > http://ninenines.eu > >>> > _______________________________________________ > >>> > erlang-questions mailing list > >>> > erlang-q...@REDACTED > >>> > http://erlang.org/mailman/listinfo/erlang-questions > > >>> > >>> > >>> > >>> > >>> -- > >>> Evan Miller > >>> http://www.evanmiller.org/ > >>> _______________________________________________ > >>> erlang-questions mailing list > >>> erlang-q...@REDACTED > >>> http://erlang.org/mailman/listinfo/erlang-questions > > >> > >> > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-q...@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > 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 > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From tmr@REDACTED Wed Jan 23 00:20:27 2013 From: tmr@REDACTED (Tomas Morstein) Date: Wed, 23 Jan 2013 00:20:27 +0100 (CET) Subject: [erlang-questions] Quick connect to another node with erl In-Reply-To: <50FF0D2D.1070906@ninenines.eu> Message-ID: ----- Original Message ----- > Od: "Lo?c Hoguin" > Komu: "Tomas Morstein" > Kopie: erlang-questions@REDACTED > Odeslan?: ?ter?, 22. Leden 2013 23:05:33 > P?edm?t: Re: [erlang-questions] Quick connect to another node with erl > > On 01/22/2013 11:02 PM, Tomas Morstein wrote: > > Dne ned?le, 20. ledna 2013 21:16:20 UTC+1 Jachym Holecek napsal(a): > > > > # Ward Bekker (TTY) 2013-01-20: > > > I want to connect to the shell on node bar@REDACTED My > > > current > > solution > > > (see below) needs some user switch commands. Is there a way > > > using CL > > > arguments? Couldn't find a mention in the erl man page. > > > > Yes, using -remsh, like this: > > > > Terminal 1: > > # erl -sname foo -setcookie abc > > Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:4:4] > > [rq:4] [async-threads:0] [kernel-poll:false] > > > > Eshell V5.8.5 (abort with ^G) > > > > > > It's worth to note that `remsh' should be used with extra care, > > especially > > when it comes to connecting live production systems. > > Time by time, it happens (at least to me) that someone accidentally > > issues `q().' instead of ^G-q. The result is remote node shutdown > > what > > is usually not what we wanted to do, although `q().' is good habit > > otherwise :) > > > > That's why I would recommend you to use extra VM options to > > restrict > > the shell and block at least `q()' and friends (well, I've never > > seen > > anybody who accidentally typed `init:stop()' yet :-) ). > > init:stop() seems to stop the local node, not the remote node. Are you sure? Depends on what you define as remote and local. Everything you write is executed on the remote node which is local from the point of view of the (remote) shell. The way I think it works is that `remsh' creates just a new shell on the remote node which is redirected to another console, and should deliver the very same behaviour as if you're directly on the remote machine's console and start another shell job via ^G followed by `s' command. At the other hand, if you make ^G and `s' on the "local" node (that one which was started with -remsh), you can get shell which is truly local to that secondary node. If you know about any tricks how to detect the original node which is just remsh'd somewhere, let me know, because it may be useful for improving the restricted_shell module. [I would like to have ability to issue `q().' only on the master console and block it on all the others. Now we have it that `q().' is disabled at all unless you issue something like `shell_restriction_policy:unlock ()' and then the `q()' becomes allowed.] A little example at the end: tmr@REDACTED:~$ erl -sname foo -setcookie abc Erlang R15B (erts-5.9) [source] [64-bit] [smp:8:8] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9 (abort with ^G) (foo@REDACTED)1> (foo@REDACTED)1> (foo@REDACTED)1> node (). foo@REDACTED (foo@REDACTED)2> tmr@REDACTED:~$ erl -sname boo -setcookie abc -remsh foo@REDACTED Erlang R15B (erts-5.9) [source] [64-bit] [smp:8:8] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9 (abort with ^G) (foo@REDACTED)1> (foo@REDACTED)1> node (). foo@REDACTED (foo@REDACTED)2> User switch command --> j 1* {foo@REDACTED,shell,start,[]} --> s --> j 1 {foo@REDACTED,shell,start,[]} 2* {shell,start,[]} --> c 2 Eshell V5.9 (abort with ^G) (boo@REDACTED)1> User switch command --> c 1 (foo@REDACTED)2> From yrashk@REDACTED Wed Jan 23 00:29:12 2013 From: yrashk@REDACTED (Yurii Rashkovskii) Date: Tue, 22 Jan 2013 15:29:12 -0800 (PST) Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <50FF1DBF.1060109@ninenines.eu> References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> <50FE8557.3040509@ninenines.eu> <1299e38d-bdd6-4623-837c-5a4079a8733f@googlegroups.com> <9b9f0f59-d7f3-46a0-8f70-6f10f0f39a13@googlegroups.com> <50FF1DBF.1060109@ninenines.eu> Message-ID: <80918584-d165-476d-86ab-0a0ff13e6628@googlegroups.com> Many reasons. Certain API unifications (like 0-based index) are hard to do for element/setelement ? and you can't override those anyway ? as it will break compatibility. Certain API extensions are much, much easier and enjoyable in Elixir as opposed to Erlang (see unicode.ex) Designing an API that benefits from agreed-on primitives in Elixir won't be possible in Erlang so Elixir would have to use a slightly inferior base. Elixir contributors like programming in Elixir :) Yurii. On Tuesday, January 22, 2013 3:16:15 PM UTC-8, Lo?c Hoguin wrote: > > I can understand 1), but what's the point of 2)? Wouldn't it be better > for that to be in the erlang/otp repository instead so that everything > can benefit from it? > > On 01/23/2013 12:11 AM, Yurii Rashkovskii wrote: > > It isn't really much about syntax. It is, however, about 1) macro > > capabilities, 2) saner and a more consistent stdlib (we already have a > > fairly good and fast Unicode implementation and a faster hash > dictionary) > > > > On Tuesday, January 22, 2013 3:06:19 PM UTC-8, Garrett Smith wrote: > > > > Looking over Elixir, I tend to agree with Tristan -- it seems to > have > > all the syntactic sugar that creative, non-hardcore, easily > frightened > > developers might like :) > > > > In seriousness, it looks like a nice language -- I wonder if it, or > > the Ruby, Python, JavaScript "front-end" toolsets, might be a better > > fit for extending Erlang applications to programmers who are looking > > for a kinder, gentler syntax? > > > > On Tue, Jan 22, 2013 at 4:48 PM, Yurii Rashkovskii > > wrote: > > > Elixir doesn't have any other "undefined function" handling > > beyond of what > > > Erlang/OTP provides. > > > > > > > > > On Tuesday, January 22, 2013 11:09:40 AM UTC-8, Tristan Sloughter > > wrote: > > >> > > >> Honestly this sounds like wanting Elixir. > > >> > > >> ChicagoBoss and BossDB would still have the benefits of the > > Erlang VM and > > >> also have the style of coding you are looking for. > > >> > > >> Tristan > > >> > > >> > > >> On Tue, Jan 22, 2013 at 12:30 PM, Evan Miller > > wrote: > > >>> > > >>> On Tue, Jan 22, 2013 at 6:25 AM, Lo?c Hoguin > > wrote: > > >>> > > > >>> > As for why Evan would use $handle_undefined_function instead > of > > >>> > creating many functions, that's for him to decide. But both > > implementations > > >>> > of $handle_undefined_function allow all known uses of the > > feature, yet only > > >>> > one gets error handling and tools support straight. > > >>> > > > >>> > > >>> Since my name is being thrown around as a sort of bugaboo and a > > way to > > >>> scare programmers' children with night-time stories, I'd like > to > > >>> clarify why exactly I support horrible features like Pmods and > > >>> $handle_undefined_function in the Erlang run-time. > > >>> > > >>> Most people on this list seem to care about "big-scale" issues > > like > > >>> reliability, predictability, processing kajillions of > commercial > > >>> transactions, and so forth. I happen to care a lot more about > > >>> "small-scale" issues -- in particular, the programming > > experience of > > >>> one person just trying to get something to work for the first > > time and > > >>> having the code look nice. I think that's ultimately where > > innovation > > >>> comes from -- one person experimenting around, seeing if things > > work, > > >>> and not caring whether it's production-ready or fit to be seen > by > > >>> anyone. > > >>> > > >>> I worry that Erlang is missing out on a lot of potential > developer > > >>> talent because the platform's benefits tend to be back-loaded: > > it's > > >>> great for the big-scale stuff, but it can be painful for a > > newcomer > > >>> just tinkering around and seeing if stuff works. A hobbyist has > > to be > > >>> both extremely tenacious and perhaps delusional to stick with > > Erlang > > >>> long enough to realize the platform's benefits. > > >>> > > >>> For example, Erlang is missing one feature found in every other > > >>> language that I've used that is missing from Erlang. It's the > > ability > > >>> to write: > > >>> > > >>> Person.name > > >>> > > >>> Not Person#person.name , not > > person:name(Person), not > > >>> proplists:get_value, not dict:fetch, just plain old stupid > > >>> > > >>> > > > anyone-who-has-ever-looked-at-a-programming-language-before-can-understand: > > > > >>> Person Dot Name. Every other language I can think of has > something > > >>> like this, whether it's person.name , > > person->name, $person{name}, or > > >>> person.name (). I wonder how many > potential > > Erlang programmers moved on > > >>> to something else because they couldn't find this very simple > > language > > >>> construct while they were playing around with Erlang for the > first > > >>> time. > > >>> > > >>> Thanks to Pmods and some code generation, I was able to come up > > with > > >>> what I felt was acceptable alternative in Erlang: > > Person:name(). If > > >>> Erlang ever gets any kind of native support for syntax that > > looks like > > >>> that, I honestly won't care so much about Pmods. > > >>> > > >>> That brings me to $handle_undefined_function. I won't actually > > use it > > >>> in production (much), since I'd rather have compile-time checks > > for my > > >>> generated functions, and I have most of the code generation I > > need at > > >>> this point. But it would have made my life a lot easier while I > > was > > >>> prototyping the library that later became BossDB. So that's why > I > > >>> think it's necessary: to make it easier to experiment with > ideas > > >>> before sweating it out with the dark arts of code generation. > > >>> > > >>> I'd like to reiterate my proposal for > > >>> $should_handle_undefined_function as a way to resolve Lo?c's > > concerns > > >>> while preserving the dynamic nature of > $handle_undefined_function. > > >>> Some interesting use-cases that come to mind for me are a > > dynamic API > > >>> like: > > >>> > > >>> person:find_by_name("Joseph") > > >>> > > >>> Is that a good API? I don't know, but I'd like to be able to > > >>> experiment with it, get a feel for it, and move on to something > > else > > >>> quickly if it turns out to be a bad idea. I'm sure people will > > >>> immediately tell me that the "right" way to do it is > find(person, > > >>> name, "Joseph") or something. But maybe it's not -- maybe the > > increase > > >>> in readability is worth the loss in generality. Readability and > > >>> familiarity are really important for attracting hobbyist > > programmers, > > >>> who have a lot to contribute to any platform, and whose > > interests I > > >>> try represent on this list as best I can. > > >>> > > >>> Evan > > >>> > > >>> > > > >>> > > > >>> > -- > > >>> > Lo?c Hoguin > > >>> > Erlang Cowboy > > >>> > Nine Nines > > >>> > http://ninenines.eu > > >>> > _______________________________________________ > > >>> > erlang-questions mailing list > > >>> > erlang-q...@REDACTED > > >>> > http://erlang.org/mailman/listinfo/erlang-questions > > > > >>> > > >>> > > >>> > > >>> > > >>> -- > > >>> Evan Miller > > >>> http://www.evanmiller.org/ > > >>> _______________________________________________ > > >>> erlang-questions mailing list > > >>> erlang-q...@REDACTED > > >>> http://erlang.org/mailman/listinfo/erlang-questions > > > > >> > > >> > > > > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-q...@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-q...@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-q...@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > _______________________________________________ > 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 Wed Jan 23 00:30:55 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 23 Jan 2013 00:30:55 +0100 Subject: [erlang-questions] Quick connect to another node with erl In-Reply-To: References: Message-ID: <50FF212F.20000@ninenines.eu> On 01/23/2013 12:20 AM, Tomas Morstein wrote: > ----- Original Message ----- >> Od: "Lo?c Hoguin" >> Komu: "Tomas Morstein" >> Kopie: erlang-questions@REDACTED >> Odeslan?: ?ter?, 22. Leden 2013 23:05:33 >> P?edm?t: Re: [erlang-questions] Quick connect to another node with erl >> >> On 01/22/2013 11:02 PM, Tomas Morstein wrote: >>> Dne ned?le, 20. ledna 2013 21:16:20 UTC+1 Jachym Holecek napsal(a): >>> >>> # Ward Bekker (TTY) 2013-01-20: >>> > I want to connect to the shell on node bar@REDACTED My >>> > current >>> solution >>> > (see below) needs some user switch commands. Is there a way >>> > using CL >>> > arguments? Couldn't find a mention in the erl man page. >>> >>> Yes, using -remsh, like this: >>> >>> Terminal 1: >>> # erl -sname foo -setcookie abc >>> Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:4:4] >>> [rq:4] [async-threads:0] [kernel-poll:false] >>> >>> Eshell V5.8.5 (abort with ^G) >>> >>> >>> It's worth to note that `remsh' should be used with extra care, >>> especially >>> when it comes to connecting live production systems. >>> Time by time, it happens (at least to me) that someone accidentally >>> issues `q().' instead of ^G-q. The result is remote node shutdown >>> what >>> is usually not what we wanted to do, although `q().' is good habit >>> otherwise :) >>> >>> That's why I would recommend you to use extra VM options to >>> restrict >>> the shell and block at least `q()' and friends (well, I've never >>> seen >>> anybody who accidentally typed `init:stop()' yet :-) ). >> >> init:stop() seems to stop the local node, not the remote node. > > Are you sure? Depends on what you define as remote and local. > Everything you write is executed on the remote node which is > local from the point of view of the (remote) shell. No, you are right, I got confused by what happens when you use -eval at the same time (which is ran locally). That explains it. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From essen@REDACTED Wed Jan 23 00:32:47 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 23 Jan 2013 00:32:47 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <80918584-d165-476d-86ab-0a0ff13e6628@googlegroups.com> References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> <50FE8557.3040509@ninenines.eu> <1299e38d-bdd6-4623-837c-5a4079a8733f@googlegroups.com> <9b9f0f59-d7f3-46a0-8f70-6f10f0f39a13@googlegroups.com> <50FF1DBF.1060109@ninenines.eu> <80918584-d165-476d-86ab-0a0ff13e6628@googlegroups.com> Message-ID: <50FF219F.6040408@ninenines.eu> I thought Elixir compiled to Erlang (and not even Core Erlang) anyway? How can there be any primitive that aren't available in Erlang? The API, sure, but most of Unicode has nothing to do with an API. On 01/23/2013 12:29 AM, Yurii Rashkovskii wrote: > Many reasons. > > Certain API unifications (like 0-based index) are hard to do for > element/setelement ? and you can't override those anyway ? as it will > break compatibility. > Certain API extensions are much, much easier and enjoyable in Elixir as > opposed to Erlang (see unicode.ex) > Designing an API that benefits from agreed-on primitives in Elixir won't > be possible in Erlang so Elixir would have to use a slightly inferior base. > Elixir contributors like programming in Elixir :) > > Yurii. > > On Tuesday, January 22, 2013 3:16:15 PM UTC-8, Lo?c Hoguin wrote: > > I can understand 1), but what's the point of 2)? Wouldn't it be better > for that to be in the erlang/otp repository instead so that everything > can benefit from it? > > On 01/23/2013 12:11 AM, Yurii Rashkovskii wrote: > > It isn't really much about syntax. It is, however, about 1) macro > > capabilities, 2) saner and a more consistent stdlib (we already > have a > > fairly good and fast Unicode implementation and a faster hash > dictionary) > > > > On Tuesday, January 22, 2013 3:06:19 PM UTC-8, Garrett Smith wrote: > > > > Looking over Elixir, I tend to agree with Tristan -- it seems > to have > > all the syntactic sugar that creative, non-hardcore, easily > frightened > > developers might like :) > > > > In seriousness, it looks like a nice language -- I wonder if > it, or > > the Ruby, Python, JavaScript "front-end" toolsets, might be a > better > > fit for extending Erlang applications to programmers who are > looking > > for a kinder, gentler syntax? > > > > On Tue, Jan 22, 2013 at 4:48 PM, Yurii Rashkovskii > > > wrote: > > > Elixir doesn't have any other "undefined function" handling > > beyond of what > > > Erlang/OTP provides. > > > > > > > > > On Tuesday, January 22, 2013 11:09:40 AM UTC-8, Tristan > Sloughter > > wrote: > > >> > > >> Honestly this sounds like wanting Elixir. > > >> > > >> ChicagoBoss and BossDB would still have the benefits of the > > Erlang VM and > > >> also have the style of coding you are looking for. > > >> > > >> Tristan > > >> > > >> > > >> On Tue, Jan 22, 2013 at 12:30 PM, Evan Miller > > wrote: > > >>> > > >>> On Tue, Jan 22, 2013 at 6:25 AM, Lo?c Hoguin > > wrote: > > >>> > > > >>> > As for why Evan would use $handle_undefined_function > instead of > > >>> > creating many functions, that's for him to decide. But > both > > implementations > > >>> > of $handle_undefined_function allow all known uses of the > > feature, yet only > > >>> > one gets error handling and tools support straight. > > >>> > > > >>> > > >>> Since my name is being thrown around as a sort of > bugaboo and a > > way to > > >>> scare programmers' children with night-time stories, I'd > like to > > >>> clarify why exactly I support horrible features like > Pmods and > > >>> $handle_undefined_function in the Erlang run-time. > > >>> > > >>> Most people on this list seem to care about "big-scale" > issues > > like > > >>> reliability, predictability, processing kajillions of > commercial > > >>> transactions, and so forth. I happen to care a lot more > about > > >>> "small-scale" issues -- in particular, the programming > > experience of > > >>> one person just trying to get something to work for the > first > > time and > > >>> having the code look nice. I think that's ultimately where > > innovation > > >>> comes from -- one person experimenting around, seeing if > things > > work, > > >>> and not caring whether it's production-ready or fit to > be seen by > > >>> anyone. > > >>> > > >>> I worry that Erlang is missing out on a lot of potential > developer > > >>> talent because the platform's benefits tend to be > back-loaded: > > it's > > >>> great for the big-scale stuff, but it can be painful for a > > newcomer > > >>> just tinkering around and seeing if stuff works. A > hobbyist has > > to be > > >>> both extremely tenacious and perhaps delusional to stick > with > > Erlang > > >>> long enough to realize the platform's benefits. > > >>> > > >>> For example, Erlang is missing one feature found in > every other > > >>> language that I've used that is missing from Erlang. > It's the > > ability > > >>> to write: > > >>> > > >>> Person.name > > >>> > > >>> Not Person#person.name > , not > > person:name(Person), not > > >>> proplists:get_value, not dict:fetch, just plain old stupid > > >>> > > >>> > > > anyone-who-has-ever-looked-at-a-programming-language-before-can-understand: > > > > > >>> Person Dot Name. Every other language I can think of has > something > > >>> like this, whether it's person.name > , > > person->name, $person{name}, or > > >>> person.name (). > I wonder how many potential > > Erlang programmers moved on > > >>> to something else because they couldn't find this very > simple > > language > > >>> construct while they were playing around with Erlang for > the first > > >>> time. > > >>> > > >>> Thanks to Pmods and some code generation, I was able to > come up > > with > > >>> what I felt was acceptable alternative in Erlang: > > Person:name(). If > > >>> Erlang ever gets any kind of native support for syntax that > > looks like > > >>> that, I honestly won't care so much about Pmods. > > >>> > > >>> That brings me to $handle_undefined_function. I won't > actually > > use it > > >>> in production (much), since I'd rather have compile-time > checks > > for my > > >>> generated functions, and I have most of the code > generation I > > need at > > >>> this point. But it would have made my life a lot easier > while I > > was > > >>> prototyping the library that later became BossDB. So > that's why I > > >>> think it's necessary: to make it easier to experiment > with ideas > > >>> before sweating it out with the dark arts of code > generation. > > >>> > > >>> I'd like to reiterate my proposal for > > >>> $should_handle_undefined_function as a way to resolve > Lo?c's > > concerns > > >>> while preserving the dynamic nature of > $handle_undefined_function. > > >>> Some interesting use-cases that come to mind for me are a > > dynamic API > > >>> like: > > >>> > > >>> person:find_by_name("Joseph") > > >>> > > >>> Is that a good API? I don't know, but I'd like to be > able to > > >>> experiment with it, get a feel for it, and move on to > something > > else > > >>> quickly if it turns out to be a bad idea. I'm sure > people will > > >>> immediately tell me that the "right" way to do it is > find(person, > > >>> name, "Joseph") or something. But maybe it's not -- > maybe the > > increase > > >>> in readability is worth the loss in generality. > Readability and > > >>> familiarity are really important for attracting hobbyist > > programmers, > > >>> who have a lot to contribute to any platform, and whose > > interests I > > >>> try represent on this list as best I can. > > >>> > > >>> Evan > > >>> > > >>> > > > >>> > > > >>> > -- > > >>> > Lo?c Hoguin > > >>> > Erlang Cowboy > > >>> > Nine Nines > > >>> > http://ninenines.eu > > >>> > _______________________________________________ > > >>> > erlang-questions mailing list > > >>> > erlang-q...@REDACTED > > >>> > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > >>> > > >>> > > >>> > > >>> > > >>> -- > > >>> Evan Miller > > >>> http://www.evanmiller.org/ > > >>> _______________________________________________ > > >>> erlang-questions mailing list > > >>> erlang-q...@REDACTED > > >>> http://erlang.org/mailman/listinfo/erlang-questions > > > > > > >> > > >> > > > > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-q...@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-q...@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-q...@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From yrashk@REDACTED Wed Jan 23 00:34:41 2013 From: yrashk@REDACTED (Yurii Rashkovskii) Date: Tue, 22 Jan 2013 15:34:41 -0800 (PST) Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <50FF219F.6040408@ninenines.eu> References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> <50FE8557.3040509@ninenines.eu> <1299e38d-bdd6-4623-837c-5a4079a8733f@googlegroups.com> <9b9f0f59-d7f3-46a0-8f70-6f10f0f39a13@googlegroups.com> <50FF1DBF.1060109@ninenines.eu> <80918584-d165-476d-86ab-0a0ff13e6628@googlegroups.com> <50FF219F.6040408@ninenines.eu> Message-ID: <1a9541fb-d8e2-4129-aadf-319eb957235b@googlegroups.com> I apologize, I meant library primitives, such as use of protocols or Elixir records. Elixir compiles to Erlang AST. Also, writing unicode.ex is a PITA. Possible (of course!) but PITA. On Tuesday, January 22, 2013 3:32:47 PM UTC-8, Lo?c Hoguin wrote: > > I thought Elixir compiled to Erlang (and not even Core Erlang) anyway? > How can there be any primitive that aren't available in Erlang? The API, > sure, but most of Unicode has nothing to do with an API. > > On 01/23/2013 12:29 AM, Yurii Rashkovskii wrote: > > Many reasons. > > > > Certain API unifications (like 0-based index) are hard to do for > > element/setelement ? and you can't override those anyway ? as it will > > break compatibility. > > Certain API extensions are much, much easier and enjoyable in Elixir as > > opposed to Erlang (see unicode.ex) > > Designing an API that benefits from agreed-on primitives in Elixir won't > > be possible in Erlang so Elixir would have to use a slightly inferior > base. > > Elixir contributors like programming in Elixir :) > > > > Yurii. > > > > On Tuesday, January 22, 2013 3:16:15 PM UTC-8, Lo?c Hoguin wrote: > > > > I can understand 1), but what's the point of 2)? Wouldn't it be > better > > for that to be in the erlang/otp repository instead so that > everything > > can benefit from it? > > > > On 01/23/2013 12:11 AM, Yurii Rashkovskii wrote: > > > It isn't really much about syntax. It is, however, about 1) macro > > > capabilities, 2) saner and a more consistent stdlib (we already > > have a > > > fairly good and fast Unicode implementation and a faster hash > > dictionary) > > > > > > On Tuesday, January 22, 2013 3:06:19 PM UTC-8, Garrett Smith > wrote: > > > > > > Looking over Elixir, I tend to agree with Tristan -- it seems > > to have > > > all the syntactic sugar that creative, non-hardcore, easily > > frightened > > > developers might like :) > > > > > > In seriousness, it looks like a nice language -- I wonder if > > it, or > > > the Ruby, Python, JavaScript "front-end" toolsets, might be a > > better > > > fit for extending Erlang applications to programmers who are > > looking > > > for a kinder, gentler syntax? > > > > > > On Tue, Jan 22, 2013 at 4:48 PM, Yurii Rashkovskii > > > > > wrote: > > > > Elixir doesn't have any other "undefined function" handling > > > beyond of what > > > > Erlang/OTP provides. > > > > > > > > > > > > On Tuesday, January 22, 2013 11:09:40 AM UTC-8, Tristan > > Sloughter > > > wrote: > > > >> > > > >> Honestly this sounds like wanting Elixir. > > > >> > > > >> ChicagoBoss and BossDB would still have the benefits of > the > > > Erlang VM and > > > >> also have the style of coding you are looking for. > > > >> > > > >> Tristan > > > >> > > > >> > > > >> On Tue, Jan 22, 2013 at 12:30 PM, Evan Miller > > > wrote: > > > >>> > > > >>> On Tue, Jan 22, 2013 at 6:25 AM, Lo?c Hoguin > > > wrote: > > > >>> > > > > >>> > As for why Evan would use $handle_undefined_function > > instead of > > > >>> > creating many functions, that's for him to decide. But > > both > > > implementations > > > >>> > of $handle_undefined_function allow all known uses of > the > > > feature, yet only > > > >>> > one gets error handling and tools support straight. > > > >>> > > > > >>> > > > >>> Since my name is being thrown around as a sort of > > bugaboo and a > > > way to > > > >>> scare programmers' children with night-time stories, I'd > > like to > > > >>> clarify why exactly I support horrible features like > > Pmods and > > > >>> $handle_undefined_function in the Erlang run-time. > > > >>> > > > >>> Most people on this list seem to care about "big-scale" > > issues > > > like > > > >>> reliability, predictability, processing kajillions of > > commercial > > > >>> transactions, and so forth. I happen to care a lot more > > about > > > >>> "small-scale" issues -- in particular, the programming > > > experience of > > > >>> one person just trying to get something to work for the > > first > > > time and > > > >>> having the code look nice. I think that's ultimately > where > > > innovation > > > >>> comes from -- one person experimenting around, seeing if > > things > > > work, > > > >>> and not caring whether it's production-ready or fit to > > be seen by > > > >>> anyone. > > > >>> > > > >>> I worry that Erlang is missing out on a lot of potential > > developer > > > >>> talent because the platform's benefits tend to be > > back-loaded: > > > it's > > > >>> great for the big-scale stuff, but it can be painful for > a > > > newcomer > > > >>> just tinkering around and seeing if stuff works. A > > hobbyist has > > > to be > > > >>> both extremely tenacious and perhaps delusional to stick > > with > > > Erlang > > > >>> long enough to realize the platform's benefits. > > > >>> > > > >>> For example, Erlang is missing one feature found in > > every other > > > >>> language that I've used that is missing from Erlang. > > It's the > > > ability > > > >>> to write: > > > >>> > > > >>> Person.name > > > >>> > > > >>> Not Person#person.name > > , not > > > person:name(Person), not > > > >>> proplists:get_value, not dict:fetch, just plain old > stupid > > > >>> > > > >>> > > > > > > anyone-who-has-ever-looked-at-a-programming-language-before-can-understand: > > > > > > > > >>> Person Dot Name. Every other language I can think of has > > something > > > >>> like this, whether it's person.name > > , > > > person->name, $person{name}, or > > > >>> person.name (). > > I wonder how many potential > > > Erlang programmers moved on > > > >>> to something else because they couldn't find this very > > simple > > > language > > > >>> construct while they were playing around with Erlang for > > the first > > > >>> time. > > > >>> > > > >>> Thanks to Pmods and some code generation, I was able to > > come up > > > with > > > >>> what I felt was acceptable alternative in Erlang: > > > Person:name(). If > > > >>> Erlang ever gets any kind of native support for syntax > that > > > looks like > > > >>> that, I honestly won't care so much about Pmods. > > > >>> > > > >>> That brings me to $handle_undefined_function. I won't > > actually > > > use it > > > >>> in production (much), since I'd rather have compile-time > > checks > > > for my > > > >>> generated functions, and I have most of the code > > generation I > > > need at > > > >>> this point. But it would have made my life a lot easier > > while I > > > was > > > >>> prototyping the library that later became BossDB. So > > that's why I > > > >>> think it's necessary: to make it easier to experiment > > with ideas > > > >>> before sweating it out with the dark arts of code > > generation. > > > >>> > > > >>> I'd like to reiterate my proposal for > > > >>> $should_handle_undefined_function as a way to resolve > > Lo?c's > > > concerns > > > >>> while preserving the dynamic nature of > > $handle_undefined_function. > > > >>> Some interesting use-cases that come to mind for me are a > > > dynamic API > > > >>> like: > > > >>> > > > >>> person:find_by_name("Joseph") > > > >>> > > > >>> Is that a good API? I don't know, but I'd like to be > > able to > > > >>> experiment with it, get a feel for it, and move on to > > something > > > else > > > >>> quickly if it turns out to be a bad idea. I'm sure > > people will > > > >>> immediately tell me that the "right" way to do it is > > find(person, > > > >>> name, "Joseph") or something. But maybe it's not -- > > maybe the > > > increase > > > >>> in readability is worth the loss in generality. > > Readability and > > > >>> familiarity are really important for attracting hobbyist > > > programmers, > > > >>> who have a lot to contribute to any platform, and whose > > > interests I > > > >>> try represent on this list as best I can. > > > >>> > > > >>> Evan > > > >>> > > > >>> > > > > >>> > > > > >>> > -- > > > >>> > Lo?c Hoguin > > > >>> > Erlang Cowboy > > > >>> > Nine Nines > > > >>> > http://ninenines.eu > > > >>> > _______________________________________________ > > > >>> > erlang-questions mailing list > > > >>> > erlang-q...@REDACTED > > > >>> > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> -- > > > >>> Evan Miller > > > >>> http://www.evanmiller.org/ > > > >>> _______________________________________________ > > > >>> erlang-questions mailing list > > > >>> erlang-q...@REDACTED > > > >>> http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > >> > > > >> > > > > > > > > _______________________________________________ > > > > erlang-questions mailing list > > > > erlang-q...@REDACTED > > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > > > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-q...@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-q...@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > > -- > > Lo?c Hoguin > > Erlang Cowboy > > Nine Nines > > http://ninenines.eu > > _______________________________________________ > > erlang-questions mailing list > > erlang-q...@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonstl@REDACTED Wed Jan 23 00:41:24 2013 From: simonstl@REDACTED (Simon St.Laurent) Date: Tue, 22 Jan 2013 18:41:24 -0500 Subject: [erlang-questions] hobbyists, erlang, elixir (was Improve $handle_undefined_function) Message-ID: <50FF23A4.3090604@simonstl.com> Evan Miller wrote: > I worry that Erlang is missing out on a lot of potential developer > talent because the platform's benefits tend to be back-loaded: it's > great for the big-scale stuff, but it can be painful for a newcomer > just tinkering around and seeing if stuff works. A hobbyist has to be > both extremely tenacious and perhaps delusional to stick with Erlang > long enough to realize the platform's benefits. I agree that there are a lot of people who could benefit from Erlang, and who don't participate because they think it's only for huge systems. I'm having fun, but will admit that I could get a lot of things done faster in other languages. Is the answer Elixir? It might be. I'm certainly considering 'translating' Introducing Erlang. I don't think a simple translation would be hard, though I suspect I'd have to restructure a fair amount. One way or another, it's not hard to imagine a world of people getting Erlang's benefits if we can make it seem friendlier. There's little reason for Erlang to be the preserve only of people who write huge systems. Thanks, -- Simon St.Laurent http://simonstl.com/ From jose.valim@REDACTED Wed Jan 23 00:50:56 2013 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Tue, 22 Jan 2013 16:50:56 -0700 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <50FF1DBF.1060109@ninenines.eu> References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> <50FE8557.3040509@ninenines.eu> <1299e38d-bdd6-4623-837c-5a4079a8733f@googlegroups.com> <9b9f0f59-d7f3-46a0-8f70-6f10f0f39a13@googlegroups.com> <50FF1DBF.1060109@ninenines.eu> Message-ID: > > I can understand 1), but what's the point of 2)? Wouldn't it be better for > that to be in the erlang/otp repository instead so that everything can > benefit from it? Loic, whenever it makes sense, I contribute patches back to OTP. :) I would, for example, contribute our dict implementation, but I don't believe OTP is looking for another dict implementation (I am going to write a blog post with details and benchmarks soon for those interested). Some of the stuff in our stdlib, like providing zero-index based access everywhere is hard to "backport" to Erlang. And other stuff like the Enum module, which is a bunch of functions meant to work on any enumerable data structure, like lists, dicts, etc, requires protocols. In any case, if you need/want to use any of Elixir modules from your Erlang code, you can just drop them into your project. For example, you can use our strings module, that is based on the Unicode Standarded, straight from Erlang: 'Elixir-String':capitalize(<<"?n">>) <<"Fin">> I agree 'Elixir-String' is not the prettiest sight but that is because we could not use 'Elixir.String' due to packages (RIP). I hope we can revert this decision a while after R16 is out and make integration a bit more pleasant. In general, I am very excited about R16. It will enable us to use cover in Elixir, ansi codes and more. And feel free to call me on anything you believe I should be contributing to OTP directly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ababkin@REDACTED Wed Jan 23 01:07:33 2013 From: ababkin@REDACTED (Alex Babkin) Date: Tue, 22 Jan 2013 19:07:33 -0500 Subject: [erlang-questions] possible to use cowboy with websockets in current master? In-Reply-To: <50FF1C09.8030801@ninenines.eu> References: <50FF1C09.8030801@ninenines.eu> Message-ID: Thanks BTW, do any of the example work currently? I tried hello_world, rest_hello_world and static and none of them work looks like ranch and crypto aren't being started, but even if i start them manually before starting the example apps, it errors out if indeed it's not just me and examples don't work, is there an example anywhere of a working app (with latest master cowboy), preferably websocket and static resource serving? (i looked at the testsuite but it's a bit hard to figure things out there) Cheers On Tue, Jan 22, 2013 at 6:08 PM, Lo?c Hoguin wrote: > On 01/23/2013 12:00 AM, Alex Babkin wrote: > >> Hi >> >> Anyone knows if the websockets are functional in the current cowboy >> master? I used 0.6 branch but would like to upgrade asap to ensure >> compatibility with upcoming 0.8. Any examples of the new interface usage? >> (doesn't look like examples/ contains anything websocket specific) >> > > Websocket interface didn't change. Websocket was only made 100% compliant. > > List of changes from a couple months ago is here: > > https://github.com/extend/**cowboy/blob/master/CHANGELOG.**md > > There's more, it'll be updated after routing changes are done. Otherwise > you might want to check the guide: > > https://github.com/extend/**cowboy/tree/master/guide > > And if something isn't in there, or is unclear, please open a ticket! > Thanks. > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed Jan 23 01:17:16 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 23 Jan 2013 01:17:16 +0100 Subject: [erlang-questions] possible to use cowboy with websockets in current master? In-Reply-To: References: <50FF1C09.8030801@ninenines.eu> Message-ID: <50FF2C0C.4080302@ninenines.eu> They work. Did you rebar get-deps compile as indicated by the readme, before running ./start.sh? On 01/23/2013 01:07 AM, Alex Babkin wrote: > Thanks > > BTW, do any of the example work currently? I tried hello_world, > rest_hello_world and static and none of them work > looks like ranch and crypto aren't being started, but even if i start > them manually before starting the example apps, it errors out > > if indeed it's not just me and examples don't work, is there an example > anywhere of a working app (with latest master cowboy), preferably > websocket and static resource serving? > (i looked at the testsuite but it's a bit hard to figure things out there) > > Cheers > > > On Tue, Jan 22, 2013 at 6:08 PM, Lo?c Hoguin > wrote: > > On 01/23/2013 12:00 AM, Alex Babkin wrote: > > Hi > > Anyone knows if the websockets are functional in the current cowboy > master? I used 0.6 branch but would like to upgrade asap to ensure > compatibility with upcoming 0.8. Any examples of the new > interface usage? > (doesn't look like examples/ contains anything websocket specific) > > > Websocket interface didn't change. Websocket was only made 100% > compliant. > > List of changes from a couple months ago is here: > > https://github.com/extend/__cowboy/blob/master/CHANGELOG.__md > > > There's more, it'll be updated after routing changes are done. > Otherwise you might want to check the guide: > > https://github.com/extend/__cowboy/tree/master/guide > > > And if something isn't in there, or is unclear, please open a > ticket! Thanks. > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From jeremy@REDACTED Wed Jan 23 01:19:12 2013 From: jeremy@REDACTED (Jeremy Ong) Date: Tue, 22 Jan 2013 16:19:12 -0800 Subject: [erlang-questions] possible to use cowboy with websockets in current master? In-Reply-To: References: <50FF1C09.8030801@ninenines.eu> Message-ID: I am writing a websocket example currently (a chat server) and will be giving a few erlang workshops at my company using the project as a base. I will submit a pull request once this is done. On Tue, Jan 22, 2013 at 4:07 PM, Alex Babkin wrote: > Thanks > > BTW, do any of the example work currently? I tried hello_world, > rest_hello_world and static and none of them work > looks like ranch and crypto aren't being started, but even if i start them > manually before starting the example apps, it errors out > > if indeed it's not just me and examples don't work, is there an example > anywhere of a working app (with latest master cowboy), preferably websocket > and static resource serving? > (i looked at the testsuite but it's a bit hard to figure things out there) > > Cheers > > > On Tue, Jan 22, 2013 at 6:08 PM, Lo?c Hoguin wrote: > >> On 01/23/2013 12:00 AM, Alex Babkin wrote: >> >>> Hi >>> >>> Anyone knows if the websockets are functional in the current cowboy >>> master? I used 0.6 branch but would like to upgrade asap to ensure >>> compatibility with upcoming 0.8. Any examples of the new interface usage? >>> (doesn't look like examples/ contains anything websocket specific) >>> >> >> Websocket interface didn't change. Websocket was only made 100% compliant. >> >> List of changes from a couple months ago is here: >> >> https://github.com/extend/**cowboy/blob/master/CHANGELOG.**md >> >> There's more, it'll be updated after routing changes are done. Otherwise >> you might want to check the guide: >> >> https://github.com/extend/**cowboy/tree/master/guide >> >> And if something isn't in there, or is unclear, please open a ticket! >> Thanks. >> >> >> -- >> Lo?c Hoguin >> >> Erlang Cowboy >> Nine Nines >> 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 ababkin@REDACTED Wed Jan 23 01:31:54 2013 From: ababkin@REDACTED (Alex Babkin) Date: Tue, 22 Jan 2013 19:31:54 -0500 Subject: [erlang-questions] possible to use cowboy with websockets in current master? In-Reply-To: References: <50FF1C09.8030801@ninenines.eu> Message-ID: Thanks for being patient with me Loic, seems there was a problem with my dependencies, examples work now Jeremy, it'd be great to see some sample websocket code On Tue, Jan 22, 2013 at 7:19 PM, Jeremy Ong wrote: > I am writing a websocket example currently (a chat server) and will be > giving a few erlang workshops at my company using the project as a base. > > I will submit a pull request once this is done. > > > On Tue, Jan 22, 2013 at 4:07 PM, Alex Babkin wrote: > >> Thanks >> >> BTW, do any of the example work currently? I tried hello_world, >> rest_hello_world and static and none of them work >> looks like ranch and crypto aren't being started, but even if i start >> them manually before starting the example apps, it errors out >> >> if indeed it's not just me and examples don't work, is there an example >> anywhere of a working app (with latest master cowboy), preferably websocket >> and static resource serving? >> (i looked at the testsuite but it's a bit hard to figure things out there) >> >> Cheers >> >> >> On Tue, Jan 22, 2013 at 6:08 PM, Lo?c Hoguin wrote: >> >>> On 01/23/2013 12:00 AM, Alex Babkin wrote: >>> >>>> Hi >>>> >>>> Anyone knows if the websockets are functional in the current cowboy >>>> master? I used 0.6 branch but would like to upgrade asap to ensure >>>> compatibility with upcoming 0.8. Any examples of the new interface >>>> usage? >>>> (doesn't look like examples/ contains anything websocket specific) >>>> >>> >>> Websocket interface didn't change. Websocket was only made 100% >>> compliant. >>> >>> List of changes from a couple months ago is here: >>> >>> https://github.com/extend/**cowboy/blob/master/CHANGELOG.**md >>> >>> There's more, it'll be updated after routing changes are done. Otherwise >>> you might want to check the guide: >>> >>> https://github.com/extend/**cowboy/tree/master/guide >>> >>> And if something isn't in there, or is unclear, please open a ticket! >>> Thanks. >>> >>> >>> -- >>> Lo?c Hoguin >>> >>> Erlang Cowboy >>> Nine Nines >>> 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 ok@REDACTED Wed Jan 23 02:09:56 2013 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 23 Jan 2013 14:09:56 +1300 Subject: [erlang-questions] Is -extends() used in any projects? In-Reply-To: References: Message-ID: On 22/01/2013, at 7:44 PM, Bj?rn Gustavsson wrote: > -extends() was mentioned when we first talked > about removing parameterized modules, so we > assumed that we needed to emulate -extends() > as well as parameterized modules. > > It seems to be a good time to ask the question: > > Is -extends() used by real projects? Do we really > need to emulate it? > > BTW, -extends() is described here: > > http://www.erlang.se/euc/07/papers/1700Carlsson.pdf I believe that the design described there takes a wrong step on the very first non-title slide: All function calls to new_module:f(...) will be redirected to old_module:f(...) if f is *NOT* exported from new_module. I think that the rule "you may call m:f/n from another module if and only if m explicitly exports f/n" is an excellent rule. It means that if you want to know what are the things in module m, the information is right there in the source code and the beam and if it is loaded, module_info gives it to you. With the design described in those slides, YOU NEVER KNOW WHAT THE INTERFACE OF A MODULE (that has an -extends in it) IS. If you *don't* break the module-interfaces-are-knowable rule, you get a different design which is entirely compile-time (and thus faster): If f/n is -exported and f/n is not defined and there is an -extends(m) then generate a glue definition f(A1,...,An) -> m:f(A1, ..., An). It's simple. The full interface of a module remains discoverable. And it's *faster*, because the current design requires the lack of a definition to be detected at run time, a trap out to a special handler (with the arguments packaged into a data structure), time to figure out what was undefined, the arguments have to be unpacked again, and finally what would have been the body of the glue definition is executed. To quote Jayne, "where does that get to be fun?" I once wrote a paper that I couldn't get published. It described an object oriented extension to Intercal, and it was as deliberately perverse as plain Intercal. This particular attempt to turn Erlang into an OO language reminds me very much of that paper, only it isn't funny when it's real. I've built a Smalltalk implementation. Now Smalltalk was originally a single-inheritance language, and its dynamic typing means that there are fewer constraints on what you can do that way than there are in typical typed OO languages. Even so, there is rather more code duplication than I am happy with, and it may be this year that I finally add mixins. (Or it may not. There are enough other things to worry about.) Why mention that here? Because the way -extends is presented in that paper means that it can only support single inheritance. (Since the ability to determine a module's full interface has been destroyed, it cannot handle -extends(p). -extends(q). by checking which of p, q defines f/n.) And that's an unjustified limitation. Change it slightly. Instead of -extends, use -export_from(Other_Module, Export_List). That's just a handy abbreviation form. -export_from(m, [...,f/n,...]). means f(A1, ..., An) -> m:f(A1, ..., An). And now you have multiple inheritance. And you have better compile-time checking: things are not re-exported *implicitly*, so if an -exported function is not defined in *this* module, that's still an error. And the good part is that because a module's full interface is discoverable, you can point your text editor at a .beam file and say "generate me a -export_from directive from _that_." (Which should be done by calling a little command-line tool: generating an -export_from directive doubles very nicely as a way for a human to find out what a module exports without having to read the source code, which they might not have anyway.) a little command-line From ababkin@REDACTED Wed Jan 23 02:10:16 2013 From: ababkin@REDACTED (Alex Babkin) Date: Tue, 22 Jan 2013 20:10:16 -0500 Subject: [erlang-questions] possible to use cowboy with websockets in current master? In-Reply-To: References: <50FF1C09.8030801@ninenines.eu> Message-ID: ok, with some luck, got my old bullet code working in the cowboy_websocket_handler envelope with latest cowboy master I'm still using bullet.js from older bullet code and it seems to work just fine Are there plans to upgrade bullet to work with latest cowboy or will it be integrated with cowboy from now on ? Will there be a fallback (to polling etc) in cowboy if the client doesn't support websockets ? On Tue, Jan 22, 2013 at 7:31 PM, Alex Babkin wrote: > Thanks for being patient with me Loic, seems there was a problem with my > dependencies, examples work now > > Jeremy, it'd be great to see some sample websocket code > > > On Tue, Jan 22, 2013 at 7:19 PM, Jeremy Ong wrote: > >> I am writing a websocket example currently (a chat server) and will be >> giving a few erlang workshops at my company using the project as a base. >> >> I will submit a pull request once this is done. >> >> >> On Tue, Jan 22, 2013 at 4:07 PM, Alex Babkin wrote: >> >>> Thanks >>> >>> BTW, do any of the example work currently? I tried hello_world, >>> rest_hello_world and static and none of them work >>> looks like ranch and crypto aren't being started, but even if i start >>> them manually before starting the example apps, it errors out >>> >>> if indeed it's not just me and examples don't work, is there an example >>> anywhere of a working app (with latest master cowboy), preferably websocket >>> and static resource serving? >>> (i looked at the testsuite but it's a bit hard to figure things out >>> there) >>> >>> Cheers >>> >>> >>> On Tue, Jan 22, 2013 at 6:08 PM, Lo?c Hoguin wrote: >>> >>>> On 01/23/2013 12:00 AM, Alex Babkin wrote: >>>> >>>>> Hi >>>>> >>>>> Anyone knows if the websockets are functional in the current cowboy >>>>> master? I used 0.6 branch but would like to upgrade asap to ensure >>>>> compatibility with upcoming 0.8. Any examples of the new interface >>>>> usage? >>>>> (doesn't look like examples/ contains anything websocket specific) >>>>> >>>> >>>> Websocket interface didn't change. Websocket was only made 100% >>>> compliant. >>>> >>>> List of changes from a couple months ago is here: >>>> >>>> https://github.com/extend/**cowboy/blob/master/CHANGELOG.**md >>>> >>>> There's more, it'll be updated after routing changes are done. >>>> Otherwise you might want to check the guide: >>>> >>>> https://github.com/extend/**cowboy/tree/master/guide >>>> >>>> And if something isn't in there, or is unclear, please open a ticket! >>>> Thanks. >>>> >>>> >>>> -- >>>> Lo?c Hoguin >>>> >>>> Erlang Cowboy >>>> Nine Nines >>>> 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 Jan 23 02:29:55 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Wed, 23 Jan 2013 02:29:55 +0100 Subject: [erlang-questions] Is -extends() used in any projects? In-Reply-To: References: Message-ID: <50FF3D13.2080300@ninenines.eu> On 01/23/2013 02:09 AM, Richard O'Keefe wrote: > > On 22/01/2013, at 7:44 PM, Bj?rn Gustavsson wrote: > >> -extends() was mentioned when we first talked >> about removing parameterized modules, so we >> assumed that we needed to emulate -extends() >> as well as parameterized modules. >> >> It seems to be a good time to ask the question: >> >> Is -extends() used by real projects? Do we really >> need to emulate it? >> >> BTW, -extends() is described here: >> >> http://www.erlang.se/euc/07/papers/1700Carlsson.pdf > > I believe that the design described there takes a wrong > step on the very first non-title slide: > > All function calls to new_module:f(...) > will be redirected to old_module:f(...) > if f is *NOT* exported from new_module. > > I think that the rule "you may call m:f/n from > another module if and only if m explicitly > exports f/n" is an excellent rule. > > It means that if you want to know what are the things > in module m, the information is right there in the > source code and the beam and if it is loaded, > module_info gives it to you. > > With the design described in those slides, YOU NEVER > KNOW WHAT THE INTERFACE OF A MODULE (that has an > -extends in it) IS. > > If you *don't* break the module-interfaces-are-knowable > rule, you get a different design which is entirely > compile-time (and thus faster): > > If f/n is -exported > and f/n is not defined > and there is an -extends(m) > then generate a glue definition > f(A1,...,An) -> m:f(A1, ..., An). > > It's simple. > The full interface of a module remains discoverable. > > And it's *faster*, because the current design > requires the lack of a definition to be detected at > run time, a trap out to a special handler (with the > arguments packaged into a data structure), time to > figure out what was undefined, the arguments have to > be unpacked again, and finally what would have been > the body of the glue definition is executed. > To quote Jayne, "where does that get to be fun?" > > I once wrote a paper that I couldn't get published. > It described an object oriented extension to > Intercal, and it was as deliberately perverse as > plain Intercal. > > This particular attempt to turn Erlang into an OO > language reminds me very much of that paper, only > it isn't funny when it's real. > > I've built a Smalltalk implementation. Now Smalltalk > was originally a single-inheritance language, and its > dynamic typing means that there are fewer constraints > on what you can do that way than there are in typical > typed OO languages. Even so, there is rather more > code duplication than I am happy with, and it may be > this year that I finally add mixins. (Or it may not. > There are enough other things to worry about.) Why > mention that here? > > Because the way -extends is presented in that paper > means that it can only support single inheritance. > (Since the ability to determine a module's full > interface has been destroyed, it cannot handle > -extends(p). > -extends(q). > by checking which of p, q defines f/n.) And that's > an unjustified limitation. > > Change it slightly. Instead of -extends, use > > -export_from(Other_Module, Export_List). > > That's just a handy abbreviation form. > -export_from(m, [...,f/n,...]). > means > f(A1, ..., An) -> m:f(A1, ..., An). > > And now you have multiple inheritance. > And you have better compile-time checking: things > are not re-exported *implicitly*, so if an > -exported function is not defined in *this* module, > that's still an error. > > And the good part is that because a module's full > interface is discoverable, you can point your text > editor at a .beam file and say "generate me a > -export_from directive from _that_." (Which should > be done by calling a little command-line tool: > generating an -export_from directive doubles very > nicely as a way for a human to find out what a module > exports without having to read the source code, which > they might not have anyway.) Agree with everything. Thanks ROK for always making amazingly clear explanations. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From essen@REDACTED Wed Jan 23 02:31:20 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 23 Jan 2013 02:31:20 +0100 Subject: [erlang-questions] possible to use cowboy with websockets in current master? In-Reply-To: References: <50FF1C09.8030801@ninenines.eu> Message-ID: <50FF3D68.9060406@ninenines.eu> Bullet will be updated. Actually if someone wants to patch it now I'll merge it. On 01/23/2013 02:10 AM, Alex Babkin wrote: > ok, with some luck, got my old bullet code working in > the cowboy_websocket_handler envelope with latest cowboy master > I'm still using bullet.js from older bullet code and it seems to work > just fine > > Are there plans to upgrade bullet to work with latest cowboy or will it > be integrated with cowboy from now on ? > Will there be a fallback (to polling etc) in cowboy if the client > doesn't support websockets ? > > > On Tue, Jan 22, 2013 at 7:31 PM, Alex Babkin > wrote: > > Thanks for being patient with me Loic, seems there was a problem > with my dependencies, examples work now > > Jeremy, it'd be great to see some sample websocket code > > > On Tue, Jan 22, 2013 at 7:19 PM, Jeremy Ong > wrote: > > I am writing a websocket example currently (a chat server) and > will be giving a few erlang workshops at my company using the > project as a base. > > I will submit a pull request once this is done. > > > On Tue, Jan 22, 2013 at 4:07 PM, Alex Babkin > wrote: > > Thanks > > BTW, do any of the example work currently? I tried > hello_world, rest_hello_world and static and none of them work > looks like ranch and crypto aren't being started, but even > if i start them manually before starting the example apps, > it errors out > > if indeed it's not just me and examples don't work, is there > an example anywhere of a working app (with latest master > cowboy), preferably websocket and static resource serving? > (i looked at the testsuite but it's a bit hard to figure > things out there) > > Cheers > > > On Tue, Jan 22, 2013 at 6:08 PM, Lo?c Hoguin > > wrote: > > On 01/23/2013 12:00 AM, Alex Babkin wrote: > > Hi > > Anyone knows if the websockets are functional in the > current cowboy > master? I used 0.6 branch but would like to upgrade > asap to ensure > compatibility with upcoming 0.8. Any examples of the > new interface usage? > (doesn't look like examples/ contains anything > websocket specific) > > > Websocket interface didn't change. Websocket was only > made 100% compliant. > > List of changes from a couple months ago is here: > > https://github.com/extend/__cowboy/blob/master/CHANGELOG.__md > > > There's more, it'll be updated after routing changes are > done. Otherwise you might want to check the guide: > > https://github.com/extend/__cowboy/tree/master/guide > > > And if something isn't in there, or is unclear, please > open a ticket! Thanks. > > > -- > Lo?c Hoguin > > Erlang Cowboy > Nine Nines > http://ninenines.eu > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From robert.virding@REDACTED Wed Jan 23 02:37:33 2013 From: robert.virding@REDACTED (Robert Virding) Date: Wed, 23 Jan 2013 01:37:33 +0000 (GMT) Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: Message-ID: <1356212030.2995635.1358905053674.JavaMail.root@erlang-solutions.com> While Erlang's meaning of 'string' is not the same as in many languages Erlang has always been extremely explicit and clear about what an Erlang 'string' is, it's even mentioned in the original Erlang book from 1993 (page 20). It is a list of characters, originally latin1 but these days unicode codepoints. Whether this is a good or bad way of representing strings is another question, I see both benefits and problems with it. So I don't see it as being dishonest, just different from many languages. Robert ----- Original Message ----- > From: "Steve Davis" > To: "Robert Virding" > Cc: "Erlang Questions" , "Richard O'Keefe" > Sent: Tuesday, 22 January, 2013 8:18:44 PM > Subject: Re: [erlang-questions] unexpected result of term_to_binary > > Let's just say that I'm now sorry I asked the question in the first > place. I have a decent, unambiguous solution to the issue. > > However, to name that byte flag STRING_EXT is simply dishonest and > misleading. > > And apart from erl_scan that Ulf mentioned, consider the meaning of > this module for erlang: http://www.erlang.org/doc/man/string.html > > Finally, if you search this list you'll see I have a history of > promoting the revocation of the whole concept of a "string" in > erlang. > > I don't see how it's possible to deny the existence of this concept > since it is plainly obvious that the platform does makes implicit > decisions about text as soon as you type [65,66,67] in the REPL. > > BR, > /s > > On Jan 22, 2013, at 11:35 AM, Robert Virding > wrote: > > > I don't see the problem. Erlang doesn't have strings, it only has > > lists of integers so unless you start tagging things there is no > > safe way to differentiate between them. As a general list can be a > > list of anything so the encoding must be able to handle this. > > However, the encoding special cases a list of small (<256) > > integers and uses a more compact representation. That it calls it > > a STRING_EXT doesn't really mean anything, they could just as well > > have called it LIST_OF_SMALL_INTEGER_EXT instead. The description > > of STRING_EXT actually says this: > > > > "String does NOT have a corresponding Erlang representation, but is > > an optimization for sending lists of bytes (integer in the range > > 0-255) more efficiently over the distribution." > > > > So why not just treat it as such? > > > > Robert > > > > ----- Original Message ----- > >> From: "Steve Davis" > >> To: "Richard O'Keefe" > >> Cc: "Erlang Questions" > >> Sent: Tuesday, 22 January, 2013 2:29:54 PM > >> Subject: Re: [erlang-questions] unexpected result of > >> term_to_binary > >> > >> Because I was writing an ETF decoder for a language that does make > >> a > >> distinction between strings and arrays of integers, and wanted to > >> avoid constraints on the kinds of terms that could be sent from > >> the > >> erlang side of things. > >> > >> On Jan 21, 2013, at 11:23 PM, "Richard O'Keefe" > >> > >> wrote: > >> > >>> > >>> On 22/01/2013, at 8:38 AM, Steve Davis wrote: > >>> > >>>> The following appears to encode lists of integers as strings > >>>> (?!?): > >>>> > >>>> Is there a reason for this that I'm missing? > >>> > >>> Why do you _care_ what the encoding is as long as it decodes > >>> correctly? > >> > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > >> > > From robert.virding@REDACTED Wed Jan 23 02:55:04 2013 From: robert.virding@REDACTED (Robert Virding) Date: Wed, 23 Jan 2013 01:55:04 +0000 (GMT) Subject: [erlang-questions] Is -extends() used in any projects? In-Reply-To: <50FF3D13.2080300@ninenines.eu> Message-ID: <2114150206.2995699.1358906104941.JavaMail.root@erlang-solutions.com> I agree as well! I think being able to see clearly see what functions a module exports is a rule which we should always follow. Robert ----- Original Message ----- > From: "Lo?c Hoguin" > To: "Richard O'Keefe" > Cc: "erlang-questions" > Sent: Wednesday, 23 January, 2013 2:29:55 AM > Subject: Re: [erlang-questions] Is -extends() used in any projects? > > On 01/23/2013 02:09 AM, Richard O'Keefe wrote: > > > > On 22/01/2013, at 7:44 PM, Bj?rn Gustavsson wrote: > > > >> -extends() was mentioned when we first talked > >> about removing parameterized modules, so we > >> assumed that we needed to emulate -extends() > >> as well as parameterized modules. > >> > >> It seems to be a good time to ask the question: > >> > >> Is -extends() used by real projects? Do we really > >> need to emulate it? > >> > >> BTW, -extends() is described here: > >> > >> http://www.erlang.se/euc/07/papers/1700Carlsson.pdf > > > > I believe that the design described there takes a wrong > > step on the very first non-title slide: > > > > All function calls to new_module:f(...) > > will be redirected to old_module:f(...) > > if f is *NOT* exported from new_module. > > > > I think that the rule "you may call m:f/n from > > another module if and only if m explicitly > > exports f/n" is an excellent rule. > > > > It means that if you want to know what are the things > > in module m, the information is right there in the > > source code and the beam and if it is loaded, > > module_info gives it to you. > > > > With the design described in those slides, YOU NEVER > > KNOW WHAT THE INTERFACE OF A MODULE (that has an > > -extends in it) IS. > > > > If you *don't* break the module-interfaces-are-knowable > > rule, you get a different design which is entirely > > compile-time (and thus faster): > > > > If f/n is -exported > > and f/n is not defined > > and there is an -extends(m) > > then generate a glue definition > > f(A1,...,An) -> m:f(A1, ..., An). > > > > It's simple. > > The full interface of a module remains discoverable. > > > > And it's *faster*, because the current design > > requires the lack of a definition to be detected at > > run time, a trap out to a special handler (with the > > arguments packaged into a data structure), time to > > figure out what was undefined, the arguments have to > > be unpacked again, and finally what would have been > > the body of the glue definition is executed. > > To quote Jayne, "where does that get to be fun?" > > > > I once wrote a paper that I couldn't get published. > > It described an object oriented extension to > > Intercal, and it was as deliberately perverse as > > plain Intercal. > > > > This particular attempt to turn Erlang into an OO > > language reminds me very much of that paper, only > > it isn't funny when it's real. > > > > I've built a Smalltalk implementation. Now Smalltalk > > was originally a single-inheritance language, and its > > dynamic typing means that there are fewer constraints > > on what you can do that way than there are in typical > > typed OO languages. Even so, there is rather more > > code duplication than I am happy with, and it may be > > this year that I finally add mixins. (Or it may not. > > There are enough other things to worry about.) Why > > mention that here? > > > > Because the way -extends is presented in that paper > > means that it can only support single inheritance. > > (Since the ability to determine a module's full > > interface has been destroyed, it cannot handle > > -extends(p). > > -extends(q). > > by checking which of p, q defines f/n.) And that's > > an unjustified limitation. > > > > Change it slightly. Instead of -extends, use > > > > -export_from(Other_Module, Export_List). > > > > That's just a handy abbreviation form. > > -export_from(m, [...,f/n,...]). > > means > > f(A1, ..., An) -> m:f(A1, ..., An). > > > > And now you have multiple inheritance. > > And you have better compile-time checking: things > > are not re-exported *implicitly*, so if an > > -exported function is not defined in *this* module, > > that's still an error. > > > > And the good part is that because a module's full > > interface is discoverable, you can point your text > > editor at a .beam file and say "generate me a > > -export_from directive from _that_." (Which should > > be done by calling a little command-line tool: > > generating an -export_from directive doubles very > > nicely as a way for a human to find out what a module > > exports without having to read the source code, which > > they might not have anyway.) > > Agree with everything. > > Thanks ROK for always making amazingly clear explanations. > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From g@REDACTED Wed Jan 23 02:56:26 2013 From: g@REDACTED (Garrett Smith) Date: Tue, 22 Jan 2013 19:56:26 -0600 Subject: [erlang-questions] hobbyists, erlang, elixir (was Improve $handle_undefined_function) In-Reply-To: <50FF23A4.3090604@simonstl.com> References: <50FF23A4.3090604@simonstl.com> Message-ID: On Tue, Jan 22, 2013 at 5:41 PM, Simon St.Laurent wrote: > Evan Miller wrote: >> >> I worry that Erlang is missing out on a lot of potential developer >> talent because the platform's benefits tend to be back-loaded: it's >> great for the big-scale stuff, but it can be painful for a newcomer >> just tinkering around and seeing if stuff works. A hobbyist has to be >> both extremely tenacious and perhaps delusional to stick with Erlang >> long enough to realize the platform's benefits. > > I agree that there are a lot of people who could benefit from Erlang, and > who don't participate because they think it's only for huge systems. I'm > having fun, but will admit that I could get a lot of things done faster in > other languages. "Huge system" feels abstract to me. In my experience, "systems" tend to extend beyond a single language, VM, OS process, server -- maybe data center. I think Erlang is great for programming in general. It helps to enforce -- or at least encourage adherence to -- certain principles that are applicable anywhere: - Side effects are the source of myriad problems and should be avoided when possible - Isolation (a bulwark) is the first requirement of reliability - Fault detection and recovery (restoring to a known state) is the second requirement of reliability - Less code is easier to understand and maintain than more code - State has costs that are easy to underestimate (and hiding these costs through language features is a disservice) These principles will help a programmer build bigger, more complex systems -- but they apply equally well to to small, simple programs. I've been back in "C" world lately and it looks completely different to me after having spent a few years with Erlang (I think any functional language would apply though): - Throw a dart a wall of C code and chances are you'll hit something that's *terrifyingly* bad -- the fact that some code works at all is a result of brute force trial and error (testing?) and hacking (bug fixing?) [1] - Function scope seems arbitrary -- it's sometimes hard to understand why the C programmer uses functions at all -- e.g. a single function containing 1000 lines of code with interspersed comments would be just as readable and maintainable - The world of side effects in C is sobering -- between global variables and unconstrained pointer operations (missing const, casts, etc.) the "obviously correct" snippet of code is unicorn rare True, that's your average C program, but my rant extends to other languages (at least their typical use). So Python, Ruby, Java, C#, JavaScript -- pick one -- without careful discipline, your code can quickly devolve into a horrific mess. [2] Erlang is no panacea -- there's some make-you-blind bad Erlang code out there. But if you take its path of least resistance (i.e. stop trying to make it look and act like Ruby) you get most of the principles above without much effort. Or at least you have to work to violate them. > Is the answer Elixir? It might be. I'm certainly considering 'translating' > Introducing Erlang. I don't think a simple translation would be hard, > though I suspect I'd have to restructure a fair amount. > > One way or another, it's not hard to imagine a world of people getting > Erlang's benefits if we can make it seem friendlier. There's little reason > for Erlang to be the preserve only of people who write huge systems. The reason I started using Erlang was a) I was curious and b) I ran into a concurrency problem that would have cost considerably more time and effort to solve directly in C/C++. I don't know if the general audience of programmers will simply pick up a new language because "it's healthy". I ought to adopt Clojure and Haskell because they're great languages and I'd be a better programmer for it. I haven't yet because I have a toolkit of languages (Erlang, C, Python, bash) that will almost certainly solve anything I run into (excluding platforms with language affinity like iOS, Android, etc.) So if you can get by with Ruby, you use Ruby. Don't switch to Erlang, which looks scary, just because it's web scale. I'm almost inclined to think the real solution (assuming there's a problem, and I do) is that instructors *teach* this stuff! Why the F are students learning to program with *Java*? Start with Erlang -- a simple, pragmatic, functional language -- and then introduce the features from other languages and how to effectively manage them! In any case -- and I'm not trying to be disagreeable, this is best discussed over beer in a pub -- I don't think being developer friendly or emotionally affirming or creativity enabling is a problem that needs to be solve here. > Thanks, Thank you for calling this topic out! Garrett [1] Of course there are high quality C programs -- I just don't run into them very often [2] I use this term in a strictly scientific sense From ok@REDACTED Wed Jan 23 03:03:12 2013 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 23 Jan 2013 15:03:12 +1300 Subject: [erlang-questions] SAX-like JSON Parser for Erlang In-Reply-To: References: <1358517301.25429.YahooMailNeo@web120702.mail.ne1.yahoo.com> <0B25DEFA-2C1C-4AF0-A17A-22CAEFC695A8@cs.otago.ac.nz> Message-ID: <251E5F40-6401-422E-BD39-C11963AAB980@cs.otago.ac.nz> On 23/01/2013, at 1:59 AM, Michel Rijnders wrote: > Yep, I was recently looking into this because I'm writing a library that will provide XPath like querying for JSON. That would be JSON pointers would it? http://tools.ietf.org/html/draft-pbryan-zyp-json-pointer-00 the last time I looked at it. What's happening about that, anyway? From yrashk@REDACTED Wed Jan 23 03:04:21 2013 From: yrashk@REDACTED (Yurii Rashkovskii) Date: Tue, 22 Jan 2013 18:04:21 -0800 (PST) Subject: [erlang-questions] Is -extends() used in any projects? In-Reply-To: <2114150206.2995699.1358906104941.JavaMail.root@erlang-solutions.com> References: <50FF3D13.2080300@ninenines.eu> <2114150206.2995699.1358906104941.JavaMail.root@erlang-solutions.com> Message-ID: <486a9625-4636-4c02-8fb8-1315eecf744b@googlegroups.com> What's interesting, using metaprogramming techniques available in Elixir, we can do a much better `-extend()` kind of functionality in Elixir: ``` defmodule M do defmacro __using__(_opts) do quote do def hello_world, do: "Hello, world!" end end end defmodule A do use M end defmodule B do use M end ``` Now, both modules A & B have the same shared hello_world/0 function and it's always exported, and A & B are completed decoupled from M after the compile cycle: ``` iex(1)> A.hello_world "Hello, world!" iex(2)> B.hello_world "Hello, world!" iex(3)> A.module_info(:exports) [__info__: 1, hello_world: 0, module_info: 0, module_info: 1] iex(4)> B.module_info(:exports) [__info__: 1, hello_world: 0, module_info: 0, module_info: 1] ``` On Tuesday, January 22, 2013 5:55:04 PM UTC-8, Robert Virding wrote: > > I agree as well! I think being able to see clearly see what functions a > module exports is a rule which we should always follow. > > Robert > > ----- Original Message ----- > > From: "Lo?c Hoguin" > > > To: "Richard O'Keefe" > > > Cc: "erlang-questions" > > > Sent: Wednesday, 23 January, 2013 2:29:55 AM > > Subject: Re: [erlang-questions] Is -extends() used in any projects? > > > > On 01/23/2013 02:09 AM, Richard O'Keefe wrote: > > > > > > On 22/01/2013, at 7:44 PM, Bj?rn Gustavsson wrote: > > > > > >> -extends() was mentioned when we first talked > > >> about removing parameterized modules, so we > > >> assumed that we needed to emulate -extends() > > >> as well as parameterized modules. > > >> > > >> It seems to be a good time to ask the question: > > >> > > >> Is -extends() used by real projects? Do we really > > >> need to emulate it? > > >> > > >> BTW, -extends() is described here: > > >> > > >> http://www.erlang.se/euc/07/papers/1700Carlsson.pdf > > > > > > I believe that the design described there takes a wrong > > > step on the very first non-title slide: > > > > > > All function calls to new_module:f(...) > > > will be redirected to old_module:f(...) > > > if f is *NOT* exported from new_module. > > > > > > I think that the rule "you may call m:f/n from > > > another module if and only if m explicitly > > > exports f/n" is an excellent rule. > > > > > > It means that if you want to know what are the things > > > in module m, the information is right there in the > > > source code and the beam and if it is loaded, > > > module_info gives it to you. > > > > > > With the design described in those slides, YOU NEVER > > > KNOW WHAT THE INTERFACE OF A MODULE (that has an > > > -extends in it) IS. > > > > > > If you *don't* break the module-interfaces-are-knowable > > > rule, you get a different design which is entirely > > > compile-time (and thus faster): > > > > > > If f/n is -exported > > > and f/n is not defined > > > and there is an -extends(m) > > > then generate a glue definition > > > f(A1,...,An) -> m:f(A1, ..., An). > > > > > > It's simple. > > > The full interface of a module remains discoverable. > > > > > > And it's *faster*, because the current design > > > requires the lack of a definition to be detected at > > > run time, a trap out to a special handler (with the > > > arguments packaged into a data structure), time to > > > figure out what was undefined, the arguments have to > > > be unpacked again, and finally what would have been > > > the body of the glue definition is executed. > > > To quote Jayne, "where does that get to be fun?" > > > > > > I once wrote a paper that I couldn't get published. > > > It described an object oriented extension to > > > Intercal, and it was as deliberately perverse as > > > plain Intercal. > > > > > > This particular attempt to turn Erlang into an OO > > > language reminds me very much of that paper, only > > > it isn't funny when it's real. > > > > > > I've built a Smalltalk implementation. Now Smalltalk > > > was originally a single-inheritance language, and its > > > dynamic typing means that there are fewer constraints > > > on what you can do that way than there are in typical > > > typed OO languages. Even so, there is rather more > > > code duplication than I am happy with, and it may be > > > this year that I finally add mixins. (Or it may not. > > > There are enough other things to worry about.) Why > > > mention that here? > > > > > > Because the way -extends is presented in that paper > > > means that it can only support single inheritance. > > > (Since the ability to determine a module's full > > > interface has been destroyed, it cannot handle > > > -extends(p). > > > -extends(q). > > > by checking which of p, q defines f/n.) And that's > > > an unjustified limitation. > > > > > > Change it slightly. Instead of -extends, use > > > > > > -export_from(Other_Module, Export_List). > > > > > > That's just a handy abbreviation form. > > > -export_from(m, [...,f/n,...]). > > > means > > > f(A1, ..., An) -> m:f(A1, ..., An). > > > > > > And now you have multiple inheritance. > > > And you have better compile-time checking: things > > > are not re-exported *implicitly*, so if an > > > -exported function is not defined in *this* module, > > > that's still an error. > > > > > > And the good part is that because a module's full > > > interface is discoverable, you can point your text > > > editor at a .beam file and say "generate me a > > > -export_from directive from _that_." (Which should > > > be done by calling a little command-line tool: > > > generating an -export_from directive doubles very > > > nicely as a way for a human to find out what a module > > > exports without having to read the source code, which > > > they might not have anyway.) > > > > Agree with everything. > > > > Thanks ROK for always making amazingly clear explanations. > > > > -- > > Lo?c Hoguin > > Erlang Cowboy > > Nine Nines > > http://ninenines.eu > > _______________________________________________ > > erlang-questions mailing list > > erlang-q...@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aggelgian@REDACTED Wed Jan 23 03:15:13 2013 From: aggelgian@REDACTED (Aggelos Giantsios) Date: Wed, 23 Jan 2013 04:15:13 +0200 Subject: [erlang-questions] Function Reference to Code Tree In-Reply-To: References: Message-ID: On Tue, Jan 22, 2013 at 7:21 PM, Tyron Zerafa wrote: > F = fun(X,Y) -> X+Y end, > > In the above statement, F is just a function reference. Can I get the > syntax, code tree or anything else from this variable? All I need is to > extract the syntax out of a function reference. Any ideas how I can achieve > this? > > The following convert a fun string into an actual fun. I need something > the other way round, any ideas ?? > > > Hello!! Although I am not sure, I believe that such information may be impossible to retrieve from the bytecode of a compiled module. Having said that, I think that the important question is whether you have access to a) the source code of the module or b) a compiled version of the module with debug_info. In both cases you can generate the Abstract Syntax Tree and then extract the desired expression that corresponds to the body of the lambda function. However, if what you want is something more like the result of erlang:fun_info/1, things may be somewhat tricky. Consider the following example: 1> X = 42. 42 2> F = fun(Y) -> X + Y end. #Fun 3> proplists:get_value(env, erlang:fun_info(F)). [[{'X',42}], {value,#Fun}, {eval,#Fun}, [{clause,1, [{var,1,'Y'}], [], [{op,1,'+',{var,1,'X'},{var,1,'Y'}}]}]] The value associated with the key env of the returned proplist also contains the environment (namely X = 42) in which the function must be evaluated. This information is not stated explicitly in the AST so if you want it you'll have to parse the expression and locate the variables of the outer environment. Here's an example of the resulting AST of a lambda function Erlang Code: bar(X) -> F = fun(Y) -> X + Y end, F(42). AST of F {'fun',5, {clauses,[{clause,5, [{var,5,'Y'}], [], [{op,5,'+',{var,5,'X'},{var,5,'Y'}}]}]}}} I hope I gave you some ideas!! Aggelos -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Wed Jan 23 03:57:43 2013 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 23 Jan 2013 15:57:43 +1300 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <3BF69263-7CB0-4157-BB1A-0714342566F3@rogvall.se> References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> <50FEAB36.5010102@ninenines.eu> <3BF69263-7CB0-4157-BB1A-0714342566F3@rogvall.se> Message-ID: <4E9FEA54-93C4-4A2C-A4CD-B275954D1514@cs.otago.ac.nz> On 23/01/2013, at 4:39 AM, Tony Rogvall wrote: > Regardless of -extends() should be dropped or not I think $handle_undefined_function is a great addition > to the runtime system. It allows for various experiments and hacks. And it *prevents* other experiments and hacks. There is no such thing as a feature that is not a limitation. From bob@REDACTED Wed Jan 23 04:16:59 2013 From: bob@REDACTED (Bob Ippolito) Date: Tue, 22 Jan 2013 19:16:59 -0800 Subject: [erlang-questions] Function Reference to Code Tree In-Reply-To: References: Message-ID: I don't think what you want is possible, but you can do something similar if you can require the use of a parse transform. See the ms_transform implementation used by ets:fun2ms/1. On Tuesday, January 22, 2013, Tyron Zerafa wrote: > Erlang:fun_info(F) is returning the function body because it is > constructed in the shell which essentially passes the entire code tree to > the erl_eval module for execution. If you call this for a function > constructed in a module, you won't get this tree. > > I need something along these lines that work for functions constructed in > modules rather than the shell. > > > On Tue, Jan 22, 2013 at 8:05 PM, Gianfranco Alongi < > gianfranco.alongi@REDACTED 'gianfranco.alongi@REDACTED');>> wrote: > >> Is this what you are after? >> >> 1> F = fun(X,Y) -> X + Y end.#Fun> >2 >> >> 2> erlang:fun_info(F). >> [{pid,<0.31.0>}, {module,erl_eval}, {new_index,3}, >> {new_uniq,<<251,3,184,152,93,16,176,57,2,110,24,202,39, >> 247,72,160>>}, {index,12}, {uniq,107821302}, {name,'-expr/5-fun-3-'}, >> {arity,2}, {env,[[], {value,#Fun}, >> {eval,#Fun}, [{clause,1, >> [{var,1,'X'},{var,1,'Y'}], [], >> [{op,1,'+',{var,1,'X'},{var,1,...}}]}]]}, {type,local}] >> 3> >> >> >> On Tue, Jan 22, 2013 at 6:21 PM, Tyron Zerafa >> > wrote: >> >>> F = fun(X,Y) -> X+Y end, >>> >>> In the above statement, F is just a function reference. Can I get the >>> syntax, code tree or anything else from this variable? All I need is to >>> extract the syntax out of a function reference. Any ideas how I can achieve >>> this? >>> >>> The following convert a fun string into an actual fun. I need something >>> the other way round, any ideas ?? >>> >>> >>> {ok,Tks,_} = erl_scan:string(FunString), >>> {ok,E} = erl_parse:parse_exprs(Tks), >>> {value,Funs,_} = erl_eval:exprs(E,[]) >>> >>> Thanks :) >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >> 'erlang-questions@REDACTED');> >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> > > > -- > Best Regards, > Tyron Zerafa > -------------- next part -------------- An HTML attachment was scrubbed... URL: From comptekki@REDACTED Wed Jan 23 04:26:37 2013 From: comptekki@REDACTED (Wes James) Date: Tue, 22 Jan 2013 20:26:37 -0700 Subject: [erlang-questions] possible to use cowboy with websockets in current master? In-Reply-To: References: Message-ID: The following project uses cowboy master and websockets: https://github.com/comptekki/esysman It is a systems management console for doing admin stuff to windows/linux/macs systems. The web interface talks to a controller on the admin workstation via websockets which sends commands to all the workstations/receives info back from workstations via erlang app on each workstation. I noticed that Lo?c will be talking about websockets at http://erlangdc.com/ wes On Tue, Jan 22, 2013 at 4:00 PM, Alex Babkin wrote: > Hi > > Anyone knows if the websockets are functional in the current cowboy > master? I used 0.6 branch but would like to upgrade asap to ensure > compatibility with upcoming 0.8. Any examples of the new interface usage? > (doesn't look like examples/ contains anything websocket specific) > > Thanks > > _______________________________________________ > 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 Wed Jan 23 04:41:33 2013 From: bob@REDACTED (Bob Ippolito) Date: Tue, 22 Jan 2013 19:41:33 -0800 Subject: [erlang-questions] SAX-like JSON Parser for Erlang In-Reply-To: <251E5F40-6401-422E-BD39-C11963AAB980@cs.otago.ac.nz> References: <1358517301.25429.YahooMailNeo@web120702.mail.ne1.yahoo.com> <0B25DEFA-2C1C-4AF0-A17A-22CAEFC695A8@cs.otago.ac.nz> <251E5F40-6401-422E-BD39-C11963AAB980@cs.otago.ac.nz> Message-ID: JSON pointers are much less powerful than XPath, it's not really a query language. No predicates, result must be a single node. It's just '/foo/bar/baz/0' instead of 'obj.foo.bar.baz[0]' (in JS). Something in-between (more powerful than JSON pointers, less powerful than XPath) would be something like https://github.com/etrepum/kvc -- It won't generate results from a stream, so you'd need to use it with a standard JSON parser. -bob On Tue, Jan 22, 2013 at 6:03 PM, Richard O'Keefe wrote: > > On 23/01/2013, at 1:59 AM, Michel Rijnders wrote: > > > Yep, I was recently looking into this because I'm writing a library that > will provide XPath like querying for JSON. > > That would be JSON pointers would it? > http://tools.ietf.org/html/draft-pbryan-zyp-json-pointer-00 > the last time I looked at it. What's happening about that, > anyway? > > > > _______________________________________________ > 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 Jan 23 05:01:27 2013 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 23 Jan 2013 17:01:27 +1300 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> <50FE8557.3040509@ninenines.eu> Message-ID: <878767DA-02B6-43AB-BB3B-2AF3B9E963F9@cs.otago.ac.nz> On 23/01/2013, at 7:30 AM, Evan Miller wrote: > > Most people on this list seem to care about "big-scale" issues like > reliability, predictability, processing kajillions of commercial > transactions, and so forth. I happen to care a lot more about > "small-scale" issues -- in particular, the programming experience of > one person just trying to get something to work for the first time and > having the code look nice. I care a heck of a lot about small scale usability issues, and that's precisely why I DISLIKE pmods -extends and so on. Because I have learned from painful experience that reliability and predictability ARE small scale usability issues. The fact that -extends as currently conceived destroys our ability to know what a module exports, well, words fail me. It's such a *TERRIBLE* thing to do to plain simple-minded programmers like me that it makes me want to smash things in anger. I make mistakes *all the time*, and not being able to ask "have I actually defined everything that is either called or exported" any more, well, how does THAT help me? Let's face it, I can get pretty close to the effect of -extends WITHOUT it. I happen to have a small Erlang file that lets me type > export_from:module(foobar). in an Erlang shell and get an export list and a bunch of glue definitions that I can paste into a source file. It's careful to exclude module_info/[0,1], and it uses the io module rather clumsily. And it's under 50 SLOC. Writing a parse transform that gets the info from a .beam file would be harder, but easier for a programmer to use. I'd rather not do that, because simply saying "re-export EVERYTHING" is too dangerous. -export_from(Module, Functors). which I think I first proposed back in about 1996, permits so much more checking, and makes life SO much nicer for the small- scale programmer, that the contrast is almost dizzying. > I think that's ultimately where innovation > comes from -- one person experimenting around, seeing if things work, > and not caring whether it's production-ready or fit to be seen by > anyone. Right. And *not* from shoving half-baked ideas out the door too early. Quintus did that once, and ever since Prolog programmers have been using an I/O approach that was significantly inefficient and clumsy compared with what we _could_ have had if the ***** who shoved it out the door had asked around the company if anyone had a better idea. The botch even made it into the standard! (Heck, it even got copied into Erlang...) > For example, Erlang is missing one feature found in every other > language that I've used that is missing from Erlang. It's the ability > to write: > > Person.name That's why Joe Armstrong and I have both proposed essentially the same data structure (in my case, complete with details of how it can be implemented and actual measurements from a pilot implementation in a micro-VM) many years ago. However, I would point out that this feature requires EITHER a static type system (Pascal, C, C++, Oberon, Java, C#, &c) OR a run-time search to find where the field is. > Every other language I can think of has something > like this, There are vastly more languages than you appear to be aware of. The trick is to make something like this - work EFFICIENTLY - WITHOUT a strong static type system. > person.name(). I wonder how many potential Erlang programmers moved on > to something else because they couldn't find this very simple language > construct while they were playing around with Erlang for the first > time. Only the hard-of-thinking who were unwilling to learn a new way to program. > > Thanks to Pmods and some code generation, I was able to come up with > what I felt was acceptable alternative in Erlang: Person:name(). Did you ever measure how long that took? Compared with Person#person_name? Here's a hint: if you are sick of having programs run too fast, I've some old machines I could sell you. There are easier ways to go slow than abusing the language. Erlang is *NOT* an object oriented language. That's deliberate: the inventors of Erlang were well aware of OO and chose not to use it. If you try to use Erlang as if it were an object oriented language, you are wasting your time. F# will do a _much_ better job of satisfying you, and it's a perfectly fine language available under Mono as well as .NET. From ok@REDACTED Wed Jan 23 05:15:56 2013 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 23 Jan 2013 17:15:56 +1300 Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: References: <1127346428.2964860.1358876148647.JavaMail.root@erlang-solutions.com> Message-ID: <14CAC446-BBA5-41A1-B2FD-D21593EE1681@cs.otago.ac.nz> On 23/01/2013, at 8:18 AM, Steve Davis wrote: > Let's just say that I'm now sorry I asked the question in the first place. I have a decent, unambiguous solution to the issue. > > However, to name that byte flag STRING_EXT is simply dishonest and misleading. More precisely, it DOES honestly reveal the reason for the byte's existence, which is to compactly represent an instance of one of the data structures Erlang uses for strings. It might be an idea to rename it to BYTE_LIST_EXT. It's a common problem in naming, that a name goes one way (if you know what it means you understand the name) but not the other (if you see the name you understand what it means). In this case, like all cases really, you have to go by the *documentation*, not just by the name. > > And apart from erl_scan that Ulf mentioned, consider the meaning of this module for erlang: http://www.erlang.org/doc/man/string.html > > Finally, if you search this list you'll see I have a history of promoting the revocation of the whole concept of a "string" in erlang. It's a bit like C, really. C doesn't have strings. It has nine different _representations_ for strings ( pointer to NUL-terminated array without counter, | pointer to NUL-terminated array with upper bound, | pointer to prefix of array with counter ) x ( one byte per character | multiple possibly variable bytes per character | fix multiple bytes per character ) with two different syntaxes for string literals. Yet nobody seems to feel any qualms about talking about strings in C. In any case, strings are wrong. The string is a stark data structure and everywhere it is passed there is much duplication of process. It is a perfect vehicle for hiding information. -- Alan Perlis. My enlightenment came when a fellow masters student wrote a batch version of the PRIMOS text editor in PL/I to use on IBM mainframes. (Neither of us had heard of sed at that point.) It took him about 150 pages of PL/I, and he was fighting the language's strings every step of the way. The following year, when I learned C, I wrote my own implementation, which took 20 pages. Reason? I did my own text- handling functions, bypassing C's. It also ran about as fast on a PDP-11/60 as his editor did on a mainframe, apart from I/O. Again, at Quintus, our emulator was written in a high level portable macro language (think PL/360) called Progol. The Progol compiler was rewritten by someone who _didn't_ believe that strings were a bad idea, and instead of running faster, which was one of the reasons we wanted it rewritten, it ran about four times slower. I keep on watching out for this kind of problem. Render-this-to-an-output-stream is [usually] good; convert-this-to-a-string is [usually] bad, except when it is unbelievably bad. (Smalltalk got this right, and Java, with the Smalltalk example before it and clearly explained, got it wrong.) From ok@REDACTED Wed Jan 23 05:44:41 2013 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 23 Jan 2013 17:44:41 +1300 Subject: [erlang-questions] hobbyists, erlang, elixir (was Improve $handle_undefined_function) In-Reply-To: References: <50FF23A4.3090604@simonstl.com> Message-ID: <1E189E8B-2DB7-4E55-B473-AAFA7F2062C3@cs.otago.ac.nz> On 23/01/2013, at 2:56 PM, Garrett Smith wrote: > I'm almost inclined to think the real solution (assuming there's a > problem, and I do) is that instructors *teach* this stuff! Why the F > are students learning to program with *Java* Ah, said The Man In The Corner, drawing up his chair. Let me tell you a story. Once upon a time (about 1992ish) in a land where the moles have beaks and swim and the deer jump on their hind legs (Australia), a certain computer science department (RMIT) decided that Pascal had reached its use-by date. What shall we do? What shall we replace it with? Set up a committee! I was on the committee. We set up a short list. (1) Scheme. Tiny language, amazingly capable, REPL so you can try things out, implementations for all the machines we cared about. And Rob Hagan at Monash had shown that you could teach students more COBOL with one semester of Scheme and one semester of COBOL than you could with three semesters of COBOL. (2) Miranda. The commercial precursor of Haskell. Melbourne University were also looking at this (or had already switched to it) which would make it easier to pick up some of their students. (3) Ada. Close enough to Pascal that our staff were comfortable with it and our material would not need major revision. A better Pascal than Pascal. Handled concurrency about as nicely as an imperative language can. What was the deciding factor? Schools. Our deliberations leaked, and we started getting phone calls from careers masters saying "if you go all theoretical [read: (1) or (2)] we'll tell our pupils not to study with you." There's no point teaching the ideal course if nobody comes, so (1) and (2) were abandoned and Ada was chosen. Actually, I like Ada. And that's why I was disappointed a few years later. The cry went up - Ada is not sexy! - Ada has no native graphics! (X11 bindings, yes, but you needed to read C oriented books to learn how to use X11 and then translate that to Ada.) - Ada does't run in your browser! - Ada doesn't have suitable books! (I don't agree.) - Students won't be motivated! I was not on the committee that switched to Java. The belief was that if students couldn't make flashy graphicy things in their web browsers -- this being a time when HotJava was still around -- they would fall away and what's the good of teaching the >right< stuff to an empty classroom? The department I'm in now went straight from Pascal to Java; it was not so much that we abandoned Pascal as that it abandoned us. There were plenty of Java books to choose from, ranging from bad to very bad, but that's Sturgeon's Revelation for you. One problem is that Computer Science departments simply do not have the time to teach everything they need to teach. Students want to leave in 3 years with qualifications an employer will like, and employers want 'practical' languages in CVs. I have a colleague who cannot spell because he was taught to read using the Initial Teaching Alphabet, so I'm less convinced about the educational benefits of neat languages than I used to be. From ok@REDACTED Wed Jan 23 06:02:13 2013 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 23 Jan 2013 18:02:13 +1300 Subject: [erlang-questions] Erlang is an education Message-ID: <19DF10A5-4597-4601-B46B-D1933CBAE6F5@cs.otago.ac.nz> The SWI Prolog and ISO Prolog revision mailing lists have recently been full of discussion about a proposed change to a built-in predicate. Skip to <> if you don't want the background. Prolog is a lot like Erlang in many ways, but a term is a variable (variables exist at run time) or not, and if it is not a variable it has a function symbol, an arity, and arity many arguments. A number is a nonvariable term whose function symbol is the number itself. Back in about 1984, there were type tests 'is this a variable', 'is this not a variable', 'is this a number', 'is this a term with no arguments', and a de facto 'is this a term with some arguments'. What there wasn't was 'is this a term that has a function symbol that is an atom', and that was a pity because that's the data structure that represented a function call. So a predicate callable(Term) :- "Term is not a variable and its function symbol is an atom". was introduced. There was a _different_ predicate current_predicate(Name, Term) :- "Term represents a call to some defined predicate and Name is the name of that predicate sans arity". that you could use to ask "is it OK to call this". It's not a type test, it has to check whether there is an actual loaded definition. The ISO standard removed current_predicate/2, replacing it by a significantly less usable current_predicate/1 that takes a Name/Arity pair and no Term. Then along came modules. Prolog uses the same Module:Name(Args) syntax as Erlang, and as a data structure it means ':'(Module,Name(Args)). What happened was people forgot about current_predicate/2 (although SWI Prolog has it) and complained because callable/1 didn't do anything special with module prefixes. The complaint was that code doing p(G, ...) :- callable(G), ... call(G), ... could go wrong because callable/1 wasn't looking inside the module prefix. (Although current_predicate/2 _would_, and was actually documented as being usable for this purpose.) So the cry went up, "change callable/1!" <> When people were pressed about the use cases, one person said that he was sending goals from one thread to another, which might be on another machine. From long exposure to Erlang and this mailing list, it was _instantly_ obvious that this was a bad idea. In fact it was _such_ a bad idea that I don't believe I am able to spontaneously think of doing that any more. Erlang and this mailing list have taught me that if you want another thread or machine to do something for you, you DEFINE A PROTOCOL whose elements are data structures and that's what you verify. As I pointed out, do you _really_ want an 'it's safe to call this' test that _passes_ fun () -> halt() end? Erlang. It's an education. From ok@REDACTED Wed Jan 23 06:29:42 2013 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 23 Jan 2013 18:29:42 +1300 Subject: [erlang-questions] SAX-like JSON Parser for Erlang In-Reply-To: References: <1358517301.25429.YahooMailNeo@web120702.mail.ne1.yahoo.com> <0B25DEFA-2C1C-4AF0-A17A-22CAEFC695A8@cs.otago.ac.nz> <251E5F40-6401-422E-BD39-C11963AAB980@cs.otago.ac.nz> Message-ID: On 23/01/2013, at 4:41 PM, Bob Ippolito wrote: > JSON pointers are much less powerful than XPath, it's not really a query language. No predicates, result must be a single node. It's just '/foo/bar/baz/0' instead of 'obj.foo.bar.baz[0]' (in JS). > > Something in-between (more powerful than JSON pointers, less powerful than XPath) would be something like https://github.com/etrepum/kvc -- It won't generate results from a stream, so you'd need to use it with a standard JSON parser. The examples in the README.md of https://github.com/etrepum/kvc do things like wibble =:= kvc:path(foo.bar.baz, [{foo, [{bar, [{baz, wibble}]}]}]). This feels wrong to me. A path should be a _list_ of step descriptions, [foo,bar,bar]. Reasons: (1) You can have integer steps (this element of a tuple) as well as atom steps (this entry in a dict &c). And you can also have atom steps that _look_ like integers. (2) It is more efficient not to have to split a path into steps at run time. (3) Perhaps the most painfully obvious: a named step might need to include a dot (or any other fixed character) in its name. (4) Given a recursive data structure with a small set of labels, using dotted atoms you can quickly exhaust the size of Erlang's atom table. In many ways, this is a perfect example of "strings are wrong". The abstract concept we need here is "path" and "path" = sequence of "step" and "step" = receiver-specific position or label Packing a path up as a dotted atom or any other kind of string representation means having to recover at run time and unreliably information that has been _hidden_ inside the string, when it could have been made directly available as a simple data structure. I have a key-value component for my Smalltalk library, and in that (1,3,4) were not issues, but (2) had my programmer's instincts screaming 'this is a bad idea'. In fact one of the things on my TODO list is to replace aPath subStrings: ' .' asClass: Symbol trimmed: true by aPath _steps in order to let aPath be returned if it's a sequence of steps already. Fortunately(?) the README.md is incomplete, and that KVC implementation _does_ accept a list of steps (which look as though they have to be binaries). That module is better than it sounds. By the way, things like this remind me irresistibly of Nicklaus Wirth's "Professor Cleverbyte's Visit to Heaven" (Software Practice and Experience, Vol 7 pp155-158, 1977). From ababkin@REDACTED Wed Jan 23 07:15:30 2013 From: ababkin@REDACTED (Alex Babkin) Date: Wed, 23 Jan 2013 01:15:30 -0500 Subject: [erlang-questions] possible to use cowboy with websockets in current master? In-Reply-To: References: Message-ID: Thanks Wes, this looks like an awesome project/example Got another specific question while i'm at it: Is it possible to modify cookies while maintaining a websocket connection or do i pretty much have to set cookies with regular (non-websocketed) handler? (seems like that's whats done in esysman) I'm looking at potential ways to implement authentication and persist it in cookies On Tue, Jan 22, 2013 at 10:26 PM, Wes James wrote: > The following project uses cowboy master and websockets: > > https://github.com/comptekki/esysman > > It is a systems management console for doing admin stuff to > windows/linux/macs systems. > > The web interface talks to a controller on the admin workstation via > websockets which sends commands to all the workstations/receives info back > from workstations via erlang app on each workstation. > > I noticed that Lo?c will be talking about websockets at > http://erlangdc.com/ > > wes > > > On Tue, Jan 22, 2013 at 4:00 PM, Alex Babkin wrote: > >> Hi >> >> Anyone knows if the websockets are functional in the current cowboy >> master? I used 0.6 branch but would like to upgrade asap to ensure >> compatibility with upcoming 0.8. Any examples of the new interface usage? >> (doesn't look like examples/ contains anything websocket specific) >> >> Thanks >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From surferjeff@REDACTED Wed Jan 23 07:18:21 2013 From: surferjeff@REDACTED (SurferJeff) Date: Tue, 22 Jan 2013 22:18:21 -0800 (PST) Subject: [erlang-questions] Redirecting stdout in erlang In-Reply-To: References: Message-ID: <94f870a0-6004-45b7-91c1-603e4d6339d4@googlegroups.com> Is that how it works? One would implement an io_server process, and then call erlang:group_leader(MyIoServer, self()) or the like? If so, that's great! But, I found nothing in the group_leader documentation nor the io protocol documentation linked to below that describes these details. I thought one would call erlang:group_leader(AnyOtherPid, self()) or the like, and self() would effectively inherit stdin and stdout from AnyOtherPid. On Friday, December 14, 2012 8:48:33 AM UTC-8, Attila Rajmund Nohl wrote: > Hello! > > I think you have to implement an "io_server" process and set it with > erlang:group_leader/2. I think this is the relevant documentation: > http://erlang.org/doc/apps/stdlib/io_protocol.html > > 2012/12/14 Roberto Majadas Lopez >: > > > No i don't need a logger system. I need a way to redirect all standard > > output strings written with io:format, including from other source code. > > > > > > > > 2012/12/14 Yu-ri Cho > > >> > >> Maybe lager is what you want > >> https://github.com/basho/lager > >> > >> On Fri, Dec 14, 2012 at 10:57 AM, Roberto Majadas Lopez > >> > wrote: > >>> > >>> > >>> Hello, > >>> > >>> I want to redirect all io:format outputs to one gen_server or similar. > >>> How can i do it in erlang? > >>> > >>> Roberto > >>> > >>> _______________________________________________ > >>> erlang-questions mailing list > >>> erlang-q...@REDACTED > >>> http://erlang.org/mailman/listinfo/erlang-questions > >>> > >> > >> > >> > >> -- > >> Yu-ri Gordon > >> trueEX Group LLC > >> 646-786-8520 > >> > >> > >> CONFIDENTIALITY NOTICE > >> > >> THE INFORMATION CONTAINED IN THIS COMMUNICATION IS INTENDED FOR THE > NAMED > >> RECEIVER ONLY. THE TRANSMISSION MAY CONTAIN PRIVILEGED AND CONFIDENTIAL > >> MATERIAL. IF YOU ARE NOT THE NAMED RECIPIENT, PLEASE BE ADVISED THAT > ANY > >> USE, DISSEMINATION OR UNAUTHORIZED COPYING OF THE MATERIAL IS STRICTLY > >> PROHIBITED. IF YOU HAVE RECEIVED THIS TRANSMISSION IN ERROR, PLEASE > NOTIFY > >> SUP...@REDACTED AND DESTROY THE RECEIVED COPY. THANK > YOU. > > > > > > > > > > -- > > Roberto Majadas > > OpenShine S.L > > > > email : roberto...@REDACTED > > tlf : +34 663 273 501 > > > > www.openshine.com > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-q...@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob@REDACTED Wed Jan 23 08:02:38 2013 From: bob@REDACTED (Bob Ippolito) Date: Tue, 22 Jan 2013 23:02:38 -0800 Subject: [erlang-questions] SAX-like JSON Parser for Erlang In-Reply-To: References: <1358517301.25429.YahooMailNeo@web120702.mail.ne1.yahoo.com> <0B25DEFA-2C1C-4AF0-A17A-22CAEFC695A8@cs.otago.ac.nz> <251E5F40-6401-422E-BD39-C11963AAB980@cs.otago.ac.nz> Message-ID: Sounds like I ought to fix up that documentation. My primary goal was to just clone Apple's Key-Value Coding API (which I should've stated more explicitly in the README). I never used this library for anything but introspecting data structures interactively in the shell. In that environment I find it to be friendlier if I can input the paths as an atom or string. Efficiency wasn't much of a concern. On Tue, Jan 22, 2013 at 9:29 PM, Richard O'Keefe wrote: > > On 23/01/2013, at 4:41 PM, Bob Ippolito wrote: > > > JSON pointers are much less powerful than XPath, it's not really a query > language. No predicates, result must be a single node. It's just > '/foo/bar/baz/0' instead of 'obj.foo.bar.baz[0]' (in JS). > > > > Something in-between (more powerful than JSON pointers, less powerful > than XPath) would be something like https://github.com/etrepum/kvc -- It > won't generate results from a stream, so you'd need to use it with a > standard JSON parser. > > The examples in the README.md of https://github.com/etrepum/kvc > do things like > > wibble =:= kvc:path(foo.bar.baz, [{foo, [{bar, [{baz, wibble}]}]}]). > > This feels wrong to me. A path should be a _list_ of > step descriptions, [foo,bar,bar]. Reasons: > (1) You can have integer steps (this element of a tuple) > as well as atom steps (this entry in a dict &c). > And you can also have atom steps that _look_ like integers. > (2) It is more efficient not to have to split a path into steps > at run time. > (3) Perhaps the most painfully obvious: > a named step might need to include a dot (or any other fixed > character) in its name. > (4) Given a recursive data structure with a small set of labels, > using dotted atoms you can quickly exhaust the size of > Erlang's atom table. > > In many ways, this is a perfect example of "strings are wrong". > The abstract concept we need here is > "path" > and > "path" = sequence of "step" > and > "step" = receiver-specific position or label > > Packing a path up as a dotted atom or any other kind of > string representation means having to recover at run time > and unreliably information that has been _hidden_ inside > the string, when it could have been made directly available > as a simple data structure. > > I have a key-value component for my Smalltalk library, and > in that (1,3,4) were not issues, but (2) had my programmer's > instincts screaming 'this is a bad idea'. In fact one of the > things on my TODO list is to replace > aPath subStrings: ' .' asClass: Symbol trimmed: true > by > aPath _steps > in order to let aPath be returned if it's a sequence of steps > already. > > Fortunately(?) the README.md is incomplete, and that KVC > implementation _does_ accept a list of steps (which look as > though they have to be binaries). That module is better than > it sounds. > > By the way, things like this remind me irresistibly of > Nicklaus Wirth's "Professor Cleverbyte's Visit to Heaven" > (Software Practice and Experience, Vol 7 pp155-158, 1977). > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Wed Jan 23 09:23:56 2013 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Wed, 23 Jan 2013 09:23:56 +0100 Subject: [erlang-questions] Is -extends() used in any projects? In-Reply-To: <2114150206.2995699.1358906104941.JavaMail.root@erlang-solutions.com> References: <2114150206.2995699.1358906104941.JavaMail.root@erlang-solutions.com> Message-ID: <1358929436.4777.5.camel@sekic1152.rnd.ki.sw.ericsson.se> Greetings, Slightly off topic. I apologise. It would also be nice to be able to see clearly what functions a module imports. Could a "+no_auto_import" be added to erlc? bengt On Wed, 2013-01-23 at 01:55 +0000, Robert Virding wrote: > I agree as well! I think being able to see clearly see what functions a module exports is a rule which we should always follow. > > Robert > > ----- Original Message ----- > > From: "Lo?c Hoguin" > > To: "Richard O'Keefe" > > Cc: "erlang-questions" > > Sent: Wednesday, 23 January, 2013 2:29:55 AM > > Subject: Re: [erlang-questions] Is -extends() used in any projects? > > > > On 01/23/2013 02:09 AM, Richard O'Keefe wrote: > > > > > > On 22/01/2013, at 7:44 PM, Bj?rn Gustavsson wrote: > > > > > >> -extends() was mentioned when we first talked > > >> about removing parameterized modules, so we > > >> assumed that we needed to emulate -extends() > > >> as well as parameterized modules. > > >> > > >> It seems to be a good time to ask the question: > > >> > > >> Is -extends() used by real projects? Do we really > > >> need to emulate it? > > >> > > >> BTW, -extends() is described here: > > >> > > >> http://www.erlang.se/euc/07/papers/1700Carlsson.pdf > > > > > > I believe that the design described there takes a wrong > > > step on the very first non-title slide: > > > > > > All function calls to new_module:f(...) > > > will be redirected to old_module:f(...) > > > if f is *NOT* exported from new_module. > > > > > > I think that the rule "you may call m:f/n from > > > another module if and only if m explicitly > > > exports f/n" is an excellent rule. > > > > > > It means that if you want to know what are the things > > > in module m, the information is right there in the > > > source code and the beam and if it is loaded, > > > module_info gives it to you. > > > > > > With the design described in those slides, YOU NEVER > > > KNOW WHAT THE INTERFACE OF A MODULE (that has an > > > -extends in it) IS. > > > > > > If you *don't* break the module-interfaces-are-knowable > > > rule, you get a different design which is entirely > > > compile-time (and thus faster): > > > > > > If f/n is -exported > > > and f/n is not defined > > > and there is an -extends(m) > > > then generate a glue definition > > > f(A1,...,An) -> m:f(A1, ..., An). > > > > > > It's simple. > > > The full interface of a module remains discoverable. > > > > > > And it's *faster*, because the current design > > > requires the lack of a definition to be detected at > > > run time, a trap out to a special handler (with the > > > arguments packaged into a data structure), time to > > > figure out what was undefined, the arguments have to > > > be unpacked again, and finally what would have been > > > the body of the glue definition is executed. > > > To quote Jayne, "where does that get to be fun?" > > > > > > I once wrote a paper that I couldn't get published. > > > It described an object oriented extension to > > > Intercal, and it was as deliberately perverse as > > > plain Intercal. > > > > > > This particular attempt to turn Erlang into an OO > > > language reminds me very much of that paper, only > > > it isn't funny when it's real. > > > > > > I've built a Smalltalk implementation. Now Smalltalk > > > was originally a single-inheritance language, and its > > > dynamic typing means that there are fewer constraints > > > on what you can do that way than there are in typical > > > typed OO languages. Even so, there is rather more > > > code duplication than I am happy with, and it may be > > > this year that I finally add mixins. (Or it may not. > > > There are enough other things to worry about.) Why > > > mention that here? > > > > > > Because the way -extends is presented in that paper > > > means that it can only support single inheritance. > > > (Since the ability to determine a module's full > > > interface has been destroyed, it cannot handle > > > -extends(p). > > > -extends(q). > > > by checking which of p, q defines f/n.) And that's > > > an unjustified limitation. > > > > > > Change it slightly. Instead of -extends, use > > > > > > -export_from(Other_Module, Export_List). > > > > > > That's just a handy abbreviation form. > > > -export_from(m, [...,f/n,...]). > > > means > > > f(A1, ..., An) -> m:f(A1, ..., An). > > > > > > And now you have multiple inheritance. > > > And you have better compile-time checking: things > > > are not re-exported *implicitly*, so if an > > > -exported function is not defined in *this* module, > > > that's still an error. > > > > > > And the good part is that because a module's full > > > interface is discoverable, you can point your text > > > editor at a .beam file and say "generate me a > > > -export_from directive from _that_." (Which should > > > be done by calling a little command-line tool: > > > generating an -export_from directive doubles very > > > nicely as a way for a human to find out what a module > > > exports without having to read the source code, which > > > they might not have anyway.) > > > > Agree with everything. > > > > Thanks ROK for always making amazingly clear explanations. > > > > -- > > Lo?c Hoguin > > Erlang Cowboy > > Nine Nines > > 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 cao.xu@REDACTED Wed Jan 23 09:45:16 2013 From: cao.xu@REDACTED (cao xu) Date: Wed, 23 Jan 2013 16:45:16 +0800 Subject: [erlang-questions] Keepalive in inets Message-ID: Hi, I've posted a question about inets on stackoverflow?http://stackoverflow.com/q/14473416/918170 Hope someone could explain it. Sincerely. From lfredlund@REDACTED Wed Jan 23 10:35:55 2013 From: lfredlund@REDACTED (=?ISO-8859-1?Q?Lars-=C5ke_Fredlund?=) Date: Wed, 23 Jan 2013 10:35:55 +0100 Subject: [erlang-questions] wx: getBoundingRect - how to return the bounding rectangle? Message-ID: <50FFAEFB.4020206@fi.upm.es> The getBoundingRect function in for instance wxTreeCtrl has the type getBoundingRect(This, Item, Rect) -> boolean(), indicating that one has to pass a Rect(angle) to it. However, the corresponding wx method *bool* *GetBoundingRect*(*const wxTreeItemId &*/item/, *wxRect & */rect/, *bool */textOnly = false/) *const* actually returns the bounding rectangle for the item in the argument. Any way around this? Thanks, Lars-Ake -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Wed Jan 23 11:07:04 2013 From: ulf@REDACTED (Ulf Wiger) Date: Wed, 23 Jan 2013 11:07:04 +0100 Subject: [erlang-questions] Function Reference to Code Tree In-Reply-To: References: Message-ID: <4970ABB9-9E3A-4D9E-8954-19FE964CAA29@feuerlabs.com> On 22 Jan 2013, at 20:11, Tyron Zerafa wrote: > Erlang:fun_info(F) is returning the function body because it is constructed in the shell which essentially passes the entire code tree to the erl_eval module for execution. If you call this for a function constructed in a module, you won't get this tree. > > I need something along these lines that work for functions constructed in modules rather than the shell. Mind you, this is just example code - not intended for mission-critical use. http://erlang.org/pipermail/erlang-questions/2007-December/031992.html I updated the program a little bit, since the internal naming of funs seems to have changed: -module(extract). -export([f/1]). f(F) -> {module, Mod} = erlang:fun_info(F, module), {name, Name} = erlang:fun_info(F, name), {ok, Abst} = get_abstract_code(Mod), extract_fun(Name, Abst). get_abstract_code(Module) -> {module,_} = code:ensure_loaded(Module), Beam = code:which(Module), case beam_lib:chunks(Beam, [abstract_code]) of {ok,{_,[{abstract_code,{_,AC}}]}} -> {ok, AC}; Other -> Other end. extract_fun(Name, AC) -> {F,Arity,Rel} = split_name(Name), Clauses = [Cs || {function,_,F1,Arity1,Cs} <- AC, F1 == F, Arity1 == Arity], Funs = pick_funs(lists:concat(Clauses)), lists:nth(Rel, Funs). split_name(Name) -> [Fs, As, _, Rs] = string:tokens(atom_to_list(Name),"/-"), {list_to_atom(Fs), list_to_integer(As), list_to_integer(Rs)+1}. pick_funs(L) -> Flatten = fun({'fun',_,_} = Fun) -> [Fun]; (T) when is_tuple(T) -> tuple_to_list(T); (_) -> [] end, L1 = [X || X <- lists:flatten(lists:map(Flatten, L)), is_tuple(X)], case [F || F <- L1, element(1, F) =/= 'fun'] of [] -> L1; [_|_] -> pick_funs(L1) end. Example: -module(m1). -export([f/2]). f(N, X) -> if N==1; N==2 -> element(N, {fun() -> X + 1 end, fun() -> X - 1 end}); N == 3 -> fun(Y) -> X + Y end end. Eshell V5.9.2 (abort with ^G) 1> [m1:f(N,17) || N <- [1,2,3]]. [#Fun,#Fun,#Fun] 2> [extract:f(m1:f(N,17)) || N <- [1,2,3]]. [{'fun',7, {clauses,[{clause,7,[],[], [{op,8,'+',{var,8,'X'},{integer,8,1}}]}]}}, {'fun',10, {clauses,[{clause,10,[],[], [{op,11,'-',{var,11,'X'},{integer,11,1}}]}]}}, {'fun',14, {clauses,[{clause,14, [{var,14,'Y'}], [], [{op,15,'+',{var,15,'X'},{var,15,'Y'}}]}]}}] The module m1 needs to be compiled with debug_info, of course. BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyron.zerafa@REDACTED Wed Jan 23 11:35:58 2013 From: tyron.zerafa@REDACTED (Tyron Zerafa) Date: Wed, 23 Jan 2013 11:35:58 +0100 Subject: [erlang-questions] Function Reference to Code Tree In-Reply-To: <4970ABB9-9E3A-4D9E-8954-19FE964CAA29@feuerlabs.com> References: <4970ABB9-9E3A-4D9E-8954-19FE964CAA29@feuerlabs.com> Message-ID: Fantastic, this is exactly what I had in mind :) I will surely give it a try (and some thought about the effect of free vars) Thanks On Wed, Jan 23, 2013 at 11:07 AM, Ulf Wiger wrote: > > On 22 Jan 2013, at 20:11, Tyron Zerafa wrote: > > Erlang:fun_info(F) is returning the function body because it is > constructed in the shell which essentially passes the entire code tree to > the erl_eval module for execution. If you call this for a function > constructed in a module, you won't get this tree. > > I need something along these lines that work for functions constructed in > modules rather than the shell. > > > Mind you, this is just example code - not intended for mission-critical > use. > > http://erlang.org/pipermail/erlang-questions/2007-December/031992.html > > I updated the program a little bit, since the internal naming of funs > seems to have changed: > > > -module(extract). > > -export([f/1]). > > > f(F) -> > {module, Mod} = erlang:fun_info(F, module), > {name, Name} = erlang:fun_info(F, name), > {ok, Abst} = get_abstract_code(Mod), > extract_fun(Name, Abst). > > get_abstract_code(Module) -> > {module,_} = code:ensure_loaded(Module), > Beam = code:which(Module), > case beam_lib:chunks(Beam, [abstract_code]) of > {ok,{_,[{abstract_code,{_,AC}}]}} -> > {ok, AC}; > Other -> > Other > end. > > extract_fun(Name, AC) -> > {F,Arity,Rel} = split_name(Name), > Clauses = [Cs || {function,_,F1,Arity1,Cs} <- AC, > F1 == F, Arity1 == Arity], > Funs = pick_funs(lists:concat(Clauses)), > lists:nth(Rel, Funs). > > split_name(Name) -> > [Fs, As, _, Rs] = string:tokens(atom_to_list(Name),"/-"), > {list_to_atom(Fs), list_to_integer(As), list_to_integer(Rs)+1}. > > pick_funs(L) -> > Flatten = fun({'fun',_,_} = Fun) -> [Fun]; > (T) when is_tuple(T) -> tuple_to_list(T); > (_) -> [] > end, > L1 = [X || X <- lists:flatten(lists:map(Flatten, L)), > is_tuple(X)], > case [F || F <- L1, > element(1, F) =/= 'fun'] of > [] -> L1; > [_|_] -> > pick_funs(L1) > end. > > > Example: > > -module(m1). > > -export([f/2]). > > f(N, X) -> > if N==1; N==2 -> > element(N, {fun() -> > X + 1 > end, > fun() -> > X - 1 > end}); > N == 3 -> > fun(Y) -> > X + Y > end > end. > > Eshell V5.9.2 (abort with ^G) > 1> [m1:f(N,17) || N <- [1,2,3]]. > [#Fun,#Fun,#Fun] > 2> [extract:f(m1:f(N,17)) || N <- [1,2,3]]. > [{'fun',7, > {clauses,[{clause,7,[],[], > [{op,8,'+',{var,8,'X'},{integer,8,1}}]}]}}, > {'fun',10, > {clauses,[{clause,10,[],[], > [{op,11,'-',{var,11,'X'},{integer,11,1}}]}]}}, > {'fun',14, > {clauses,[{clause,14, > [{var,14,'Y'}], > [], > [{op,15,'+',{var,15,'X'},{var,15,'Y'}}]}]}}] > > > The module m1 needs to be compiled with debug_info, of course. > > BR, > Ulf W > > Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. > http://feuerlabs.com > > > > -- Best Regards, Tyron Zerafa -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Wed Jan 23 12:07:13 2013 From: ulf@REDACTED (Ulf Wiger) Date: Wed, 23 Jan 2013 12:07:13 +0100 Subject: [erlang-questions] Function Reference to Code Tree In-Reply-To: References: <4970ABB9-9E3A-4D9E-8954-19FE964CAA29@feuerlabs.com> Message-ID: For deeper excavation, you might get something out of meditating over ct_expand.erl: https://github.com/uwiger/parse_trans/blob/master/src/ct_expand.erl Its uses are exemplified in https://github.com/uwiger/parse_trans/blob/master/examples/ct_expand_test.erl What it does is expand expresssions at compile-time, and if those expressions make use of e.g. function calls defined in the same module (i.e. not yet compiled), it finds the abstract code for those functions and evaluates it. If one wanted to pull a self-contained abstract-code definition of a fun, this sort of thing, combined perhaps with inlining, might come in handy. (That is, if the extracted abstract code contains a call to a non-exported function, it will be incomplete when pulled out of its context). BR, Ulf W On 23 Jan 2013, at 11:35, Tyron Zerafa wrote: > Fantastic, this is exactly what I had in mind :) I will surely give it a try (and some thought about the effect of free vars) > Thanks > > > On Wed, Jan 23, 2013 at 11:07 AM, Ulf Wiger wrote: > > On 22 Jan 2013, at 20:11, Tyron Zerafa wrote: > >> Erlang:fun_info(F) is returning the function body because it is constructed in the shell which essentially passes the entire code tree to the erl_eval module for execution. If you call this for a function constructed in a module, you won't get this tree. >> >> I need something along these lines that work for functions constructed in modules rather than the shell. > > Mind you, this is just example code - not intended for mission-critical use. > > http://erlang.org/pipermail/erlang-questions/2007-December/031992.html > > I updated the program a little bit, since the internal naming of funs seems to have changed: > > > -module(extract). > > -export([f/1]). > > > f(F) -> > {module, Mod} = erlang:fun_info(F, module), > {name, Name} = erlang:fun_info(F, name), > {ok, Abst} = get_abstract_code(Mod), > extract_fun(Name, Abst). > > get_abstract_code(Module) -> > {module,_} = code:ensure_loaded(Module), > Beam = code:which(Module), > case beam_lib:chunks(Beam, [abstract_code]) of > {ok,{_,[{abstract_code,{_,AC}}]}} -> > {ok, AC}; > Other -> > Other > end. > > extract_fun(Name, AC) -> > {F,Arity,Rel} = split_name(Name), > Clauses = [Cs || {function,_,F1,Arity1,Cs} <- AC, > F1 == F, Arity1 == Arity], > Funs = pick_funs(lists:concat(Clauses)), > lists:nth(Rel, Funs). > > split_name(Name) -> > [Fs, As, _, Rs] = string:tokens(atom_to_list(Name),"/-"), > {list_to_atom(Fs), list_to_integer(As), list_to_integer(Rs)+1}. > > pick_funs(L) -> > Flatten = fun({'fun',_,_} = Fun) -> [Fun]; > (T) when is_tuple(T) -> tuple_to_list(T); > (_) -> [] > end, > L1 = [X || X <- lists:flatten(lists:map(Flatten, L)), > is_tuple(X)], > case [F || F <- L1, > element(1, F) =/= 'fun'] of > [] -> L1; > [_|_] -> > pick_funs(L1) > end. > > > Example: > > -module(m1). > > -export([f/2]). > > f(N, X) -> > if N==1; N==2 -> > element(N, {fun() -> > X + 1 > end, > fun() -> > X - 1 > end}); > N == 3 -> > fun(Y) -> > X + Y > end > end. > > Eshell V5.9.2 (abort with ^G) > 1> [m1:f(N,17) || N <- [1,2,3]]. > [#Fun,#Fun,#Fun] > 2> [extract:f(m1:f(N,17)) || N <- [1,2,3]]. > [{'fun',7, > {clauses,[{clause,7,[],[], > [{op,8,'+',{var,8,'X'},{integer,8,1}}]}]}}, > {'fun',10, > {clauses,[{clause,10,[],[], > [{op,11,'-',{var,11,'X'},{integer,11,1}}]}]}}, > {'fun',14, > {clauses,[{clause,14, > [{var,14,'Y'}], > [], > [{op,15,'+',{var,15,'X'},{var,15,'Y'}}]}]}}] > > > The module m1 needs to be compiled with debug_info, of course. > > BR, > Ulf W > > Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. > http://feuerlabs.com > > > > > > > -- > Best Regards, > Tyron Zerafa Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangud@REDACTED Wed Jan 23 12:07:51 2013 From: dangud@REDACTED (Dan Gudmundsson) Date: Wed, 23 Jan 2013 12:07:51 +0100 Subject: [erlang-questions] wx: getBoundingRect - how to return the bounding rectangle? In-Reply-To: <50FFAEFB.4020206@fi.upm.es> References: <50FFAEFB.4020206@fi.upm.es> Message-ID: Thanks for the bug-report, that is a bug in the code generator. wx is so huge so I've proberbly missed several of these. Will fix in R16B, if you know any more places post them so I don't miss them. Asap, code freeze incoming.. /Dan On Wed, Jan 23, 2013 at 10:35 AM, Lars-?ke Fredlund wrote: > The getBoundingRect function in for instance wxTreeCtrl has the type > getBoundingRect(This, Item, Rect) -> boolean(), indicating that one has to > pass a Rect(angle) to it. > However, the corresponding wx method > > bool GetBoundingRect(const wxTreeItemId& item, wxRect& rect, bool textOnly = > false) const > > actually returns the bounding rectangle for the item in the argument. > Any way around this? > > Thanks, > Lars-Ake > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From kenneth.lundin@REDACTED Wed Jan 23 12:39:25 2013 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Wed, 23 Jan 2013 12:39:25 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <878767DA-02B6-43AB-BB3B-2AF3B9E963F9@cs.otago.ac.nz> References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> <50FE8557.3040509@ninenines.eu> <878767DA-02B6-43AB-BB3B-2AF3B9E963F9@cs.otago.ac.nz> Message-ID: Thank you for all input in this matter. I mean both regarding -extends and $handle_undefined_function. I think it is place for some clarifications which will have implications on earlier statements in this thread. On October 19:th a decision from the OTP Technical Board (a fora internal to the OTP development team at Ericsson) regarding parameterized types was announced. The announcement looked like this: *Issue 4 - What to do with unsupported feature 'parameterized modules'.* - The board acknowledges that a lot of software relies on this feature although it's always been experimental. The current form of the implementation is not acceptable and the parameterized modules as such has never been accepted as a feature in the language. The feature is also not compatible with for example module-fun's and is not fully integrated with the rest of the tools in OTP. To allow for source code compatibility, the board decides to only remove the syntactic support for parameterized modules. This means: * Apply with tuple modules will be retained, supported and properly documented. * Error handler functionality that today supports inheritance will be slightly generalized, so that parameterized modules can contain stubs to facilitate inheritance. The functionality in the error handler will be documented. * The parser will accept the syntax for implementation of parameterized modules, but if the parameterized modules are not handled by a parse_transform, an error message will be generated at a later stage (this concerns the implementation of the modules themselves only). * A parse_transform handling source code implementing a parameterized module will be published in the public domain, free to use and include in any package needing it. It will however not be part of OTP. As it uses supported and documented functionality, it will however be expected to work for forthcoming releases as well, or at least to be possible to adopt to forthcoming releases. As apply with tuple modules is retained, calls to parameterized modules will remain as they look today. Only the implementation of the parameterized modules themselves need to apply a parse transform to allow for the "unsupported" syntax extensions. Calling a function in an instance of a parameterized module from an evaluator (e.g. the shell) will also work as before. As I remember it we got mainly positive reactions regarding this decision and now we have implemented it exactly as said and it will be released in R16A (beta release on January 30:th) and R16B (product release on Feb 27:th). In short the previously undocumented support for parameterized modules is removed from the OTP distribution and is replaced with a parse transform which we will provide as a separate project at Github. We do this to make the transition smooth for projects having used the parameteized modules feature. We will not continue to support or enhance that parse transform in the future (it is up to the users interested in the feature to do that). Some of the comments in this thread are related to how parmaterized modules and '-extends' in particular could be improved, changed etc. and it is perfectly ok to do that, but it is not part of Erlang/OTP any more. As a consequence of removing parameterized modules from OTP we have changed the error_handler by removing a built in knowledge about parameterized modules and by adding a more general and useful functionality, the $handle_undefined_function feature. This feature is useful in a number of situations where one was earlier forced to modify the global error_handler: - Can support the parse-transform for parameterized modules (the -extends attribute) - Can be used to safely (or more safely than before) implement various "mocking" functionality for testing purposes - Can be used to interface external generic RPC interfaces like the android case. It will be documented in the error_handler module together with a fat warning that you should not use this in normal production code etc. The error_handler module is hardly something that the average or novice programmer will stumble into and immediately use features from. So in summary we have done what we promised to do: - taken parmeterized modules out of Erlang/OTP (offering a parse_transform instead) - removed knowledge about parameterized modules from error_handler and added a more generic and safe way for extending the error_handler per module instead. /Regards Kenneth, Erlang/OTP Ericsson On Wed, Jan 23, 2013 at 5:01 AM, Richard O'Keefe wrote: > > On 23/01/2013, at 7:30 AM, Evan Miller wrote: > > > > Most people on this list seem to care about "big-scale" issues like > > reliability, predictability, processing kajillions of commercial > > transactions, and so forth. I happen to care a lot more about > > "small-scale" issues -- in particular, the programming experience of > > one person just trying to get something to work for the first time and > > having the code look nice. > > I care a heck of a lot about small scale usability issues, > and that's precisely why I DISLIKE pmods -extends and so on. > Because I have learned from painful experience that reliability > and predictability ARE small scale usability issues. > > The fact that -extends as currently conceived destroys our > ability to know what a module exports, well, words fail me. > It's such a *TERRIBLE* thing to do to plain simple-minded > programmers like me that it makes me want to smash things in > anger. I make mistakes *all the time*, and not being able to > ask "have I actually defined everything that is either called > or exported" any more, well, how does THAT help me? > > Let's face it, I can get pretty close to the effect of > -extends WITHOUT it. I happen to have a small Erlang file > that lets me type > > export_from:module(foobar). > in an Erlang shell and get an export list and a bunch of > glue definitions that I can paste into a source file. > It's careful to exclude module_info/[0,1], and it uses > the io module rather clumsily. And it's under 50 SLOC. > > Writing a parse transform that gets the info from a .beam file > would be harder, but easier for a programmer to use. I'd rather > not do that, because simply saying "re-export EVERYTHING" is too > dangerous. > > -export_from(Module, Functors). > > which I think I first proposed back in about 1996, permits so > much more checking, and makes life SO much nicer for the small- > scale programmer, that the contrast is almost dizzying. > > > I think that's ultimately where innovation > > comes from -- one person experimenting around, seeing if things work, > > and not caring whether it's production-ready or fit to be seen by > > anyone. > > Right. And *not* from shoving half-baked ideas out the door > too early. Quintus did that once, and ever since Prolog programmers > have been using an I/O approach that was significantly inefficient and > clumsy compared with what we _could_ have had if the ***** who shoved > it out the door had asked around the company if anyone had a better > idea. The botch even made it into the standard! (Heck, it even got > copied into Erlang...) > > > For example, Erlang is missing one feature found in every other > > language that I've used that is missing from Erlang. It's the ability > > to write: > > > > Person.name > > That's why Joe Armstrong and I have both proposed essentially the same > data structure (in my case, complete with details of how it can be > implemented and actual measurements from a pilot implementation in a > micro-VM) many years ago. > > However, I would point out that this feature requires EITHER > a static type system (Pascal, C, C++, Oberon, Java, C#, &c) > OR a run-time search to find where the field is. > > > Every other language I can think of has something > > like this, > > There are vastly more languages than you appear to be aware of. > The trick is to make something like this > - work EFFICIENTLY > - WITHOUT a strong static type system. > > > person.name(). I wonder how many potential Erlang programmers moved on > > to something else because they couldn't find this very simple language > > construct while they were playing around with Erlang for the first > > time. > > Only the hard-of-thinking who were unwilling to learn a new way to > program. > > > > Thanks to Pmods and some code generation, I was able to come up with > > what I felt was acceptable alternative in Erlang: Person:name(). > > Did you ever measure how long that took? > Compared with Person#person_name? > Here's a hint: if you are sick of having programs > run too fast, I've some old machines I could sell you. > There are easier ways to go slow than abusing the language. > > Erlang is *NOT* an object oriented language. > That's deliberate: the inventors of Erlang were well aware of OO > and chose not to use it. > > If you try to use Erlang as if it were an object oriented language, > you are wasting your time. F# will do a _much_ better job of > satisfying you, and it's a perfectly fine language available under > Mono as well as .NET. > > > _______________________________________________ > 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 Wed Jan 23 14:29:40 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Wed, 23 Jan 2013 05:29:40 -0800 (PST) Subject: [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition Released In-Reply-To: References: <50D8DA63.2060600@ninenines.eu> <50E57DC0.5090408@ninenines.eu> <50E58CF4.9080804@ninenines.eu> Message-ID: <99e8f001-5a08-415e-af74-43db3f40d7d4@v7g2000yqv.googlegroups.com> Currently I have to do following thing to really update routes: case lists:keyfind({ranch_listener_sup,my_http}, 1, supervisor:which_children(ranch_sup)) of {_, ListenerSup, _, _} -> case lists:keyfind(ranch_acceptors_sup, 1, supervisor:which_children(ListenerSup)) of {_, AcceptorSup, _, _} -> [erlang:exit(Pid,normal) || {_,Pid,_,_} <- supervisor:which_children(AcceptorSup)], ok; false -> ok end; false -> ok end because after ranch:set_protocol_options(Ref, ProtoOpts) there are still acceptors that work with old routing information cowboy d3277b08ce ranch c3133bfbc3 Should I just update? From essen@REDACTED Wed Jan 23 14:37:43 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Wed, 23 Jan 2013 14:37:43 +0100 Subject: [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition Released In-Reply-To: <99e8f001-5a08-415e-af74-43db3f40d7d4@v7g2000yqv.googlegroups.com> References: <50D8DA63.2060600@ninenines.eu> <50E57DC0.5090408@ninenines.eu> <50E58CF4.9080804@ninenines.eu> <99e8f001-5a08-415e-af74-43db3f40d7d4@v7g2000yqv.googlegroups.com> Message-ID: <50FFE7A7.1070500@ninenines.eu> On 01/23/2013 02:29 PM, Max Lapshin wrote: > Currently I have to do following thing to really update routes: > > case lists:keyfind({ranch_listener_sup,my_http}, 1, > supervisor:which_children(ranch_sup)) of > {_, ListenerSup, _, _} -> > case lists:keyfind(ranch_acceptors_sup, 1, > supervisor:which_children(ListenerSup)) of > {_, AcceptorSup, _, _} -> > [erlang:exit(Pid,normal) || {_,Pid,_,_} <- > supervisor:which_children(AcceptorSup)], > ok; > false -> > ok > end; > false -> ok > end > > because after ranch:set_protocol_options(Ref, ProtoOpts) there are > still acceptors that work with old routing information > > > cowboy d3277b08ce > ranch c3133bfbc3 > > Should I just update? The version you're using has all acceptors updated immediately. There's a test for it (tcp_upgrade) that confirms it properly upgrades. Are you sure it's *acceptors* that are using the old routing information and not *connections*? Only new connections get the new protocol options. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From max.lapshin@REDACTED Wed Jan 23 14:39:21 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Wed, 23 Jan 2013 16:39:21 +0300 Subject: [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition Released In-Reply-To: <50FFE7A7.1070500@ninenines.eu> References: <50D8DA63.2060600@ninenines.eu> <50E57DC0.5090408@ninenines.eu> <50E58CF4.9080804@ninenines.eu> <99e8f001-5a08-415e-af74-43db3f40d7d4@v7g2000yqv.googlegroups.com> <50FFE7A7.1070500@ninenines.eu> Message-ID: I'm not sure. I think I should log all requests with pid to check it. On Wed, Jan 23, 2013 at 5:37 PM, Lo?c Hoguin wrote: > On 01/23/2013 02:29 PM, Max Lapshin wrote: > >> Currently I have to do following thing to really update routes: >> >> case lists:keyfind({ranch_listener_**sup,my_http}, 1, >> supervisor:which_children(**ranch_sup)) of >> {_, ListenerSup, _, _} -> >> case lists:keyfind(ranch_acceptors_**sup, 1, >> supervisor:which_children(**ListenerSup)) of >> {_, AcceptorSup, _, _} -> >> [erlang:exit(Pid,normal) || {_,Pid,_,_} <- >> supervisor:which_children(**AcceptorSup)], >> ok; >> false -> >> ok >> end; >> false -> ok >> end >> >> because after ranch:set_protocol_options(**Ref, ProtoOpts) there are >> still acceptors that work with old routing information >> >> >> cowboy d3277b08ce >> ranch c3133bfbc3 >> >> Should I just update? >> > > The version you're using has all acceptors updated immediately. There's a > test for it (tcp_upgrade) that confirms it properly upgrades. Are you sure > it's *acceptors* that are using the old routing information and not > *connections*? Only new connections get the new protocol options. > > -- > Lo?c Hoguin > > Erlang Cowboy > Nine Nines > http://ninenines.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Wed Jan 23 15:13:07 2013 From: tony@REDACTED (Tony Rogvall) Date: Wed, 23 Jan 2013 15:13:07 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <4E9FEA54-93C4-4A2C-A4CD-B275954D1514@cs.otago.ac.nz> References: <50FD8342.8030100@ninenines.eu> <50FE73C0.5000107@ninenines.eu> <50FE7FC2.90204@ninenines.eu> <50FEAB36.5010102@ninenines.eu> <3BF69263-7CB0-4157-BB1A-0714342566F3@rogvall.se> <4E9FEA54-93C4-4A2C-A4CD-B275954D1514@cs.otago.ac.nz> Message-ID: <8C6B1779-6A33-4C34-9BF2-81AF35247C77@rogvall.se> On 23 jan 2013, at 03:57, Richard O'Keefe wrote: > > On 23/01/2013, at 4:39 AM, Tony Rogvall wrote: > >> Regardless of -extends() should be dropped or not I think $handle_undefined_function is a great addition >> to the runtime system. It allows for various experiments and hacks. > > And it *prevents* other experiments and hacks. > Why? What kind of experiments and hacks are we talking about here? Sure, I can think of some, but who is to decide what experiments are worth doing ? ( I just hope it is OTP in this case, do not chicken out ;) > There is no such thing as a feature that is not a limitation. > And? If "users" do not add scary features like the '$handle_undefined_function' functions in their modules they will be safe. if they ignore good advise they do void the guarantee. But that, I think, is the glory of things. /Tony From aschultz@REDACTED Wed Jan 23 15:26:28 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Wed, 23 Jan 2013 15:26:28 +0100 (CET) Subject: [erlang-questions] [erlang-patches] dialyzer from otp master getting stuck in build_plt In-Reply-To: <1278860784.401361.1358950912819.JavaMail.root@tpip.net> Message-ID: <1394422765.401396.1358951188683.JavaMail.root@tpip.net> Hi, Sorry, first version went to the wrong list.... I have build and installed R16 from otp master branch. When trying to build a new plt file: 'dialyzer --build_plt --apps stdlib', dialyzer works hard (measured by CPU utilization) for about a minute, CPU usage for it then drops to 0, but it neither stops nor does it generate any additional output. The only output I get is: $ dialyzer --build_plt --apps stdlib Compiling some key modules to native code... Platform is Ubuntu 12.10 Any advise? Andreas -- -- Dipl. Inform. Andreas Schultz email: as@REDACTED From jrosenblum@REDACTED Wed Jan 23 15:29:08 2013 From: jrosenblum@REDACTED (James Rosenblum) Date: Wed, 23 Jan 2013 06:29:08 -0800 (PST) Subject: [erlang-questions] hobbyists, erlang, elixir (was Improve $handle_undefined_function) In-Reply-To: <1E189E8B-2DB7-4E55-B473-AAFA7F2062C3@cs.otago.ac.nz> References: <50FF23A4.3090604@simonstl.com> <1E189E8B-2DB7-4E55-B473-AAFA7F2062C3@cs.otago.ac.nz> Message-ID: <1358951348.43869.YahooMailNeo@web181201.mail.ne1.yahoo.com> For what its worth, in the mid 80's, my University's Computer Science?program?required?every student to take a year-long?course called Structure and Interpretation of Computer Programs. It was the *first* class any CS major took, and it was taught exclusively in Scheme. As far as I know they continue this practice. I have been?grateful?for that experience ever since and have wished that the young-guns?coming?into my organizations had had a similar experience - so often their?experiences?and thinking has been locked into an "OO - Java (or C#) - hey JavaScript is Functional - Apache" mind-set. There is nothing wrong with this, per?se,?(and many of them are super talented), but I feel like I had a real advantage by my first experience being what it was. I have since learned and used a number of languages in academic and industry settings (Clipper, C, C++, Erlang, Pascal, SmallTalk, Visual Basic, etc.), but I continue to be served by that first-class. I am?convinced?of the educational benefits of a?functional?language?that better allows one to think about the nature of a problem to be solved and the structure of a solution as opposed to wrestling with the language ... now that was probably worth $.02? ________________________________ From: Richard O'Keefe To: Garrett Smith Cc: erlang-questions@REDACTED Sent: Tuesday, January 22, 2013 11:44 PM Subject: Re: [erlang-questions] hobbyists, erlang, elixir (was Improve $handle_undefined_function) On 23/01/2013, at 2:56 PM, Garrett Smith wrote: > I'm almost inclined to think the real solution (assuming there's a > problem, and I do) is that instructors *teach* this stuff! Why the F > are students learning to program with *Java* Ah, said The Man In The Corner, drawing up his chair. Let me tell you a story. Once upon a time (about 1992ish) in a land where the moles have beaks and swim and the deer jump on their hind legs (Australia), a certain computer science department (RMIT) decided that Pascal had reached its use-by date.? What shall we do?? What shall we replace it with?? Set up a committee! I was on the committee.? We set up a short list. (1) Scheme. ? ? Tiny language, amazingly capable, REPL so you can try ? ? things out, implementations for all the machines we ? ? cared about.? And Rob Hagan at Monash had shown that ? ? you could teach students more COBOL with one semester ? ? of Scheme and one semester of COBOL than you could ? ? with three semesters of COBOL. (2) Miranda. ? ? The commercial precursor of Haskell. ? ? Melbourne University were also looking at this (or had ? ? already switched to it) which would make it easier to ? ? pick up some of their students. (3) Ada. ? ? Close enough to Pascal that our staff were comfortable with ? ? it and our material would not need major revision. ? ? A better Pascal than Pascal. ? ? Handled concurrency about as nicely as an imperative language can. What was the deciding factor? Schools. Our deliberations leaked, and we started getting phone calls from careers masters saying "if you go all theoretical [read: (1) or (2)] we'll tell our pupils not to study with you." There's no point teaching the ideal course if nobody comes, so (1) and (2) were abandoned and Ada was chosen. Actually, I like Ada.? And that's why I was disappointed a few years later.? The cry went up ? - Ada is not sexy! ? - Ada has no native graphics! ? ? (X11 bindings, yes, but you needed to read C oriented books to ? ? learn how to use X11 and then translate that to Ada.) ? - Ada does't run in your browser! ? - Ada doesn't have suitable books!? (I don't agree.) ? - Students won't be motivated! I was not on the committee that switched to Java. The belief was that if students couldn't make flashy graphicy things in their web browsers -- this being a time when HotJava was still around -- they would fall away and what's the good of teaching the >right< stuff to an empty classroom? The department I'm in now went straight from Pascal to Java; it was not so much that we abandoned Pascal as that it abandoned us. There were plenty of Java books to choose from, ranging from bad to very bad, but that's Sturgeon's Revelation for you. One problem is that Computer Science departments simply do not have the time to teach everything they need to teach.? Students want to leave in 3 years with qualifications an employer will like, and employers want 'practical' languages in CVs.? I have a colleague who cannot spell because he was taught to read using the Initial Teaching Alphabet, so I'm less convinced about the educational benefits of neat languages than I used to be. _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ababkin@REDACTED Wed Jan 23 16:35:07 2013 From: ababkin@REDACTED (Alex Babkin) Date: Wed, 23 Jan 2013 10:35:07 -0500 Subject: [erlang-questions] [erlang-patches] dialyzer from otp master getting stuck in build_plt In-Reply-To: <1394422765.401396.1358951188683.JavaMail.root@tpip.net> References: <1278860784.401361.1358950912819.JavaMail.root@tpip.net> <1394422765.401396.1358951188683.JavaMail.root@tpip.net> Message-ID: Hi this is the command i'm using to build mine. Builds and works fine with erlang/otp master (R16) of about a week old. This is on OSX 10.8.2 dialyzer --build_plt \ --output_plt .dialyzer-R16.plt \ --apps kernel stdlib sasl erts ssl \ tools os_mon runtime_tools crypto \ inets xmerl webtool snmp public_key \ mnesia eunit syntax_tools compiler \ ./deps/*/ebin On Wed, Jan 23, 2013 at 9:26 AM, Andreas Schultz wrote: > Hi, > > Sorry, first version went to the wrong list.... > > I have build and installed R16 from otp master branch. When trying > to build a new plt file: 'dialyzer --build_plt --apps stdlib', > dialyzer works hard (measured by CPU utilization) for about a minute, > CPU usage for it then drops to 0, but it neither stops nor does it > generate any additional output. > > The only output I get is: > $ dialyzer --build_plt --apps stdlib > Compiling some key modules to native code... > > Platform is Ubuntu 12.10 > > Any advise? > > Andreas > -- > -- > Dipl. Inform. > Andreas Schultz > > email: as@REDACTED > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonstl@REDACTED Wed Jan 23 16:36:49 2013 From: simonstl@REDACTED (Simon St.Laurent) Date: Wed, 23 Jan 2013 10:36:49 -0500 Subject: [erlang-questions] hobbyists, erlang, elixir (was Improve $handle_undefined_function) In-Reply-To: <1358951348.43869.YahooMailNeo@web181201.mail.ne1.yahoo.com> References: <50FF23A4.3090604@simonstl.com> <1E189E8B-2DB7-4E55-B473-AAFA7F2062C3@cs.otago.ac.nz> <1358951348.43869.YahooMailNeo@web181201.mail.ne1.yahoo.com> Message-ID: <51000391.6070904@simonstl.com> On 1/23/13 9:29 AM, James Rosenblum wrote: > I am convinced of the educational benefits of a functional language that > better allows one to think about the nature of a problem to be solved > and the structure of a solution as opposed to wrestling with the language I never took CS, and my perspective is utterly biased toward independent learners - aka the hobbyists of the subject line. I think, though, that Erlang works well for this in that context as well as in a more formal environment. Perhaps it isn't as pure as Scheme, but it's easier to answer the key question "why" when it isn't assigned. Writing Introducing Erlang convinced me that much of programming would be easier if more people started with functional languages. It's not actually that much more difficult to get started doing interesting things, and there's a lot less time spent wandering lost in the program trying to figure out where something broke. As I look back on the broken way that I learned programming - through BASIC and 6502 assembler - I see a lot of lessons I probably shouldn't have learned. I also, though, see environments that, primitive though they were, were set up to make interaction direct if occasionally arcane. I was delighted to find Erlang's shell, which made using this compiled language much friendlier. I was amazed by its remote capabilities. But then I was bluntly disappointed by the difficulty of using it as an environment - even a trivial environment - for interactive applications. It became clear quickly that the beauty of my examples would have to be abstract, because there wasn't going to be much I could show without endless preamble to distract readers from the basics. Erlang (or maybe it will be Elixir) has the power to be a language that transforms computing. It has the right tools to solve common problems. However, it may take some extra work to make it easier for people to see that! Thanks, -- Simon St.Laurent http://simonstl.com/ From comptekki@REDACTED Wed Jan 23 16:48:26 2013 From: comptekki@REDACTED (Wes James) Date: Wed, 23 Jan 2013 08:48:26 -0700 Subject: [erlang-questions] possible to use cowboy with websockets in current master? In-Reply-To: References: Message-ID: I'm using a simple cookie mechanism for the login process. When a proper username and password are entered, set a cookie and when they log out, remove the cookie. I'm not sure of all the capabilities of the cowboy cookie functions. Wes On Tue, Jan 22, 2013 at 11:15 PM, Alex Babkin wrote: > Thanks Wes, this looks like an awesome project/example > > Got another specific question while i'm at it: > > Is it possible to modify cookies while maintaining a websocket connection > or do i pretty much have to set cookies with regular (non-websocketed) > handler? (seems like that's whats done in esysman) > I'm looking at potential ways to implement authentication and persist it > in cookies > > > > > On Tue, Jan 22, 2013 at 10:26 PM, Wes James wrote: > >> The following project uses cowboy master and websockets: >> >> https://github.com/comptekki/esysman >> >> It is a systems management console for doing admin stuff to >> windows/linux/macs systems. >> >> The web interface talks to a controller on the admin workstation via >> websockets which sends commands to all the workstations/receives info back >> from workstations via erlang app on each workstation. >> >> I noticed that Lo?c will be talking about websockets at >> http://erlangdc.com/ >> >> wes >> >> >> On Tue, Jan 22, 2013 at 4:00 PM, Alex Babkin wrote: >> >>> Hi >>> >>> Anyone knows if the websockets are functional in the current cowboy >>> master? I used 0.6 branch but would like to upgrade asap to ensure >>> compatibility with upcoming 0.8. Any examples of the new interface usage? >>> (doesn't look like examples/ contains anything websocket specific) >>> >>> Thanks >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Wed Jan 23 16:57:10 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 23 Jan 2013 16:57:10 +0100 Subject: [erlang-questions] [erlang-patches] dialyzer from otp master getting stuck in build_plt In-Reply-To: References: <1278860784.401361.1358950912819.JavaMail.root@tpip.net> <1394422765.401396.1358951188683.JavaMail.root@tpip.net> Message-ID: We have now also pushed an update to the primary bootstrap to master. You will need to fetch the latest master and rebuild from scratch. On Wed, Jan 23, 2013 at 4:35 PM, Alex Babkin wrote: > Hi > > this is the command i'm using to build mine. Builds and works fine with > erlang/otp master (R16) of about a week old. This is on OSX 10.8.2 > > dialyzer --build_plt \ > --output_plt .dialyzer-R16.plt \ > --apps kernel stdlib sasl erts ssl \ > tools os_mon runtime_tools crypto \ > inets xmerl webtool snmp public_key \ > mnesia eunit syntax_tools compiler \ > ./deps/*/ebin > > > On Wed, Jan 23, 2013 at 9:26 AM, Andreas Schultz wrote: > >> Hi, >> >> Sorry, first version went to the wrong list.... >> >> I have build and installed R16 from otp master branch. When trying >> to build a new plt file: 'dialyzer --build_plt --apps stdlib', >> dialyzer works hard (measured by CPU utilization) for about a minute, >> CPU usage for it then drops to 0, but it neither stops nor does it >> generate any additional output. >> >> The only output I get is: >> $ dialyzer --build_plt --apps stdlib >> Compiling some key modules to native code... >> >> Platform is Ubuntu 12.10 >> >> Any advise? >> >> Andreas >> -- >> -- >> Dipl. Inform. >> Andreas Schultz >> >> email: as@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 > > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From zabrane3@REDACTED Wed Jan 23 17:07:37 2013 From: zabrane3@REDACTED (Zabrane Mikael) Date: Wed, 23 Jan 2013 17:07:37 +0100 Subject: [erlang-questions] Erlang binding to OpenCV Message-ID: Hi guys, Any binding to OpenCV (or OpenCV 2)? -- Regards Zab From max.lapshin@REDACTED Wed Jan 23 17:54:47 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Wed, 23 Jan 2013 19:54:47 +0300 Subject: [erlang-questions] Need help with folsom usage Message-ID: Hi. I want to use folsom for measuring page hits: response time stats and hit count. Is there any good example of code how to fetch data from folsom and send it in JSON to web-page? -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.zhuravlev@REDACTED Wed Jan 23 18:14:53 2013 From: a.zhuravlev@REDACTED (Alexander Zhuravlev) Date: Wed, 23 Jan 2013 21:14:53 +0400 Subject: [erlang-questions] Need help with folsom usage In-Reply-To: References: Message-ID: <20130123171453.GA77672@zmac> On Wed, Jan 23, 2013 at 07:54:47PM +0300, Max Lapshin wrote: > Hi. > > I want to use folsom for measuring page hits: response time stats and hit > count. > > Is there any good example of code how to fetch data from folsom and send it > in JSON to web-page? You may want to check out https://github.com/boundary/folsom_webmachine -- Alexander Zhuravlev From max.lapshin@REDACTED Wed Jan 23 18:27:18 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Wed, 23 Jan 2013 20:27:18 +0300 Subject: [erlang-questions] Need help with folsom usage In-Reply-To: <20130123171453.GA77672@zmac> References: <20130123171453.GA77672@zmac> Message-ID: Frankly speaking, I'm feeling myself an idiot. Folsom looks like a mature and cool tool, but I don't understand how can I use it. For example I want to receive history of measurements: traffic was 1 Mbit/s one minute ago, 3 mbits 2 minutes ago, etc.. Also I want to take a look at graphic of average/median request times, but I can't find any examples in open source. On Wed, Jan 23, 2013 at 9:14 PM, Alexander Zhuravlev wrote: > On Wed, Jan 23, 2013 at 07:54:47PM +0300, Max Lapshin wrote: > > Hi. > > > > I want to use folsom for measuring page hits: response time stats and hit > > count. > > > > Is there any good example of code how to fetch data from folsom and send > it > > in JSON to web-page? > > You may want to check out https://github.com/boundary/folsom_webmachine > > -- > Alexander Zhuravlev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre@REDACTED Wed Jan 23 18:42:10 2013 From: andre@REDACTED (=?ISO-8859-1?Q?Andr=E9_Graf?=) Date: Wed, 23 Jan 2013 18:42:10 +0100 Subject: [erlang-questions] Need help with folsom usage In-Reply-To: References: <20130123171453.GA77672@zmac> Message-ID: Hi Max I guess you've found out how to create a meter e.g. folsom_metrics:new_meter({meter, my_cool_meter}). as a next step you update the meter e.g. folsom_metrics:notify({{meter, my_cool_meter}, 1}). and for reading out the value you would use e.g. folsom_metrics:get_metric_value(my_cool_meter). In the case of the meter, folsom internally calculates the mean rates and exponentially weighted moving averages of your meter that you can read out with the call above. That's it, if you want to have snapshots on your metrics you have to do that by yourself (same holds for graphing the data). Hope this helped Best, Andr? On 23 January 2013 18:27, Max Lapshin wrote: > Frankly speaking, I'm feeling myself an idiot. Folsom looks like a mature > and cool tool, but I don't understand how can I use it. > > For example I want to receive history of measurements: traffic was 1 Mbit/s > one minute ago, 3 mbits 2 minutes ago, etc.. > > Also I want to take a look at graphic of average/median request times, but I > can't find any examples in open source. > > > On Wed, Jan 23, 2013 at 9:14 PM, Alexander Zhuravlev > wrote: >> >> On Wed, Jan 23, 2013 at 07:54:47PM +0300, Max Lapshin wrote: >> > Hi. >> > >> > I want to use folsom for measuring page hits: response time stats and >> > hit >> > count. >> > >> > Is there any good example of code how to fetch data from folsom and send >> > it >> > in JSON to web-page? >> >> You may want to check out https://github.com/boundary/folsom_webmachine >> >> -- >> Alexander Zhuravlev > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From paul.joseph.davis@REDACTED Wed Jan 23 19:30:34 2013 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Wed, 23 Jan 2013 12:30:34 -0600 Subject: [erlang-questions] SAX-like JSON Parser for Erlang In-Reply-To: References: <1358517301.25429.YahooMailNeo@web120702.mail.ne1.yahoo.com> <0B25DEFA-2C1C-4AF0-A17A-22CAEFC695A8@cs.otago.ac.nz> <251E5F40-6401-422E-BD39-C11963AAB980@cs.otago.ac.nz> Message-ID: And similar to kvc is the props library: https://github.com/greyarea/props On Wed, Jan 23, 2013 at 1:02 AM, Bob Ippolito wrote: > Sounds like I ought to fix up that documentation. > > My primary goal was to just clone Apple's Key-Value Coding API (which I > should've stated more explicitly in the README). I never used this library > for anything but introspecting data structures interactively in the shell. > In that environment I find it to be friendlier if I can input the paths as > an atom or string. Efficiency wasn't much of a concern. > > On Tue, Jan 22, 2013 at 9:29 PM, Richard O'Keefe wrote: > >> >> On 23/01/2013, at 4:41 PM, Bob Ippolito wrote: >> >> > JSON pointers are much less powerful than XPath, it's not really a >> query language. No predicates, result must be a single node. It's just >> '/foo/bar/baz/0' instead of 'obj.foo.bar.baz[0]' (in JS). >> > >> > Something in-between (more powerful than JSON pointers, less powerful >> than XPath) would be something like https://github.com/etrepum/kvc -- It >> won't generate results from a stream, so you'd need to use it with a >> standard JSON parser. >> >> The examples in the README.md of https://github.com/etrepum/kvc >> do things like >> >> wibble =:= kvc:path(foo.bar.baz, [{foo, [{bar, [{baz, wibble}]}]}]). >> >> This feels wrong to me. A path should be a _list_ of >> step descriptions, [foo,bar,bar]. Reasons: >> (1) You can have integer steps (this element of a tuple) >> as well as atom steps (this entry in a dict &c). >> And you can also have atom steps that _look_ like integers. >> (2) It is more efficient not to have to split a path into steps >> at run time. >> (3) Perhaps the most painfully obvious: >> a named step might need to include a dot (or any other fixed >> character) in its name. >> (4) Given a recursive data structure with a small set of labels, >> using dotted atoms you can quickly exhaust the size of >> Erlang's atom table. >> >> In many ways, this is a perfect example of "strings are wrong". >> The abstract concept we need here is >> "path" >> and >> "path" = sequence of "step" >> and >> "step" = receiver-specific position or label >> >> Packing a path up as a dotted atom or any other kind of >> string representation means having to recover at run time >> and unreliably information that has been _hidden_ inside >> the string, when it could have been made directly available >> as a simple data structure. >> >> I have a key-value component for my Smalltalk library, and >> in that (1,3,4) were not issues, but (2) had my programmer's >> instincts screaming 'this is a bad idea'. In fact one of the >> things on my TODO list is to replace >> aPath subStrings: ' .' asClass: Symbol trimmed: true >> by >> aPath _steps >> in order to let aPath be returned if it's a sequence of steps >> already. >> >> Fortunately(?) the README.md is incomplete, and that KVC >> implementation _does_ accept a list of steps (which look as >> though they have to be binaries). That module is better than >> it sounds. >> >> By the way, things like this remind me irresistibly of >> Nicklaus Wirth's "Professor Cleverbyte's Visit to Heaven" >> (Software Practice and Experience, Vol 7 pp155-158, 1977). >> >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.zhuravlev@REDACTED Wed Jan 23 19:47:14 2013 From: a.zhuravlev@REDACTED (Alexander Zhuravlev) Date: Wed, 23 Jan 2013 22:47:14 +0400 Subject: [erlang-questions] Need help with folsom usage In-Reply-To: References: <20130123171453.GA77672@zmac> Message-ID: <20130123184714.GA78630@zmac> On Wed, Jan 23, 2013 at 06:42:10PM +0100, Andr? Graf wrote: > Hi Max > > I guess you've found out how to create a meter e.g. > folsom_metrics:new_meter({meter, my_cool_meter}). > as a next step you update the meter e.g. > folsom_metrics:notify({{meter, my_cool_meter}, 1}). > and for reading out the value you would use e.g. > folsom_metrics:get_metric_value(my_cool_meter). > In the case of the meter, folsom internally calculates the mean rates > and exponentially weighted moving averages of your meter that you can > read out with the call above. That's it, if you want to have snapshots > on your metrics you have to do that by yourself (same holds for > graphing the data). Yep, you can have a process which periodically (for example, once per minute) sends a snapshot of current folsom stats values to Graphite (http://graphite.wikidot.com/) or Riemann (http://riemann.io/). > > Hope this helped > Best, > Andr? > > On 23 January 2013 18:27, Max Lapshin wrote: > > Frankly speaking, I'm feeling myself an idiot. Folsom looks like a mature > > and cool tool, but I don't understand how can I use it. > > > > For example I want to receive history of measurements: traffic was 1 Mbit/s > > one minute ago, 3 mbits 2 minutes ago, etc.. > > > > Also I want to take a look at graphic of average/median request times, but I > > can't find any examples in open source. > > > > > > On Wed, Jan 23, 2013 at 9:14 PM, Alexander Zhuravlev > > wrote: > >> > >> On Wed, Jan 23, 2013 at 07:54:47PM +0300, Max Lapshin wrote: > >> > Hi. > >> > > >> > I want to use folsom for measuring page hits: response time stats and > >> > hit > >> > count. > >> > > >> > Is there any good example of code how to fetch data from folsom and send > >> > it > >> > in JSON to web-page? > >> > >> You may want to check out https://github.com/boundary/folsom_webmachine > >> > >> -- > >> Alexander Zhuravlev > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > -- Alexander Zhuravlev From max.lapshin@REDACTED Wed Jan 23 20:28:04 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Wed, 23 Jan 2013 22:28:04 +0300 Subject: [erlang-questions] Need help with folsom usage In-Reply-To: <20130123184714.GA78630@zmac> References: <20130123171453.GA77672@zmac> <20130123184714.GA78630@zmac> Message-ID: Ok, got it. On Wed, Jan 23, 2013 at 10:47 PM, Alexander Zhuravlev wrote: > On Wed, Jan 23, 2013 at 06:42:10PM +0100, Andr? Graf wrote: > > Hi Max > > > > I guess you've found out how to create a meter e.g. > > folsom_metrics:new_meter({meter, my_cool_meter}). > > as a next step you update the meter e.g. > > folsom_metrics:notify({{meter, my_cool_meter}, 1}). > > and for reading out the value you would use e.g. > > folsom_metrics:get_metric_value(my_cool_meter). > > In the case of the meter, folsom internally calculates the mean rates > > and exponentially weighted moving averages of your meter that you can > > read out with the call above. That's it, if you want to have snapshots > > on your metrics you have to do that by yourself (same holds for > > graphing the data). > > Yep, you can have a process which periodically (for example, once per > minute) sends a snapshot of current folsom stats values to Graphite > (http://graphite.wikidot.com/) or Riemann (http://riemann.io/). > > > > > Hope this helped > > Best, > > Andr? > > > > On 23 January 2013 18:27, Max Lapshin wrote: > > > Frankly speaking, I'm feeling myself an idiot. Folsom looks like a > mature > > > and cool tool, but I don't understand how can I use it. > > > > > > For example I want to receive history of measurements: traffic was 1 > Mbit/s > > > one minute ago, 3 mbits 2 minutes ago, etc.. > > > > > > Also I want to take a look at graphic of average/median request times, > but I > > > can't find any examples in open source. > > > > > > > > > On Wed, Jan 23, 2013 at 9:14 PM, Alexander Zhuravlev < > a.zhuravlev@REDACTED> > > > wrote: > > >> > > >> On Wed, Jan 23, 2013 at 07:54:47PM +0300, Max Lapshin wrote: > > >> > Hi. > > >> > > > >> > I want to use folsom for measuring page hits: response time stats > and > > >> > hit > > >> > count. > > >> > > > >> > Is there any good example of code how to fetch data from folsom and > send > > >> > it > > >> > in JSON to web-page? > > >> > > >> You may want to check out > https://github.com/boundary/folsom_webmachine > > >> > > >> -- > > >> Alexander Zhuravlev > > > > > > > > > > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > Alexander Zhuravlev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mallen@REDACTED Wed Jan 23 20:45:24 2013 From: mallen@REDACTED (Mark Allen) Date: Wed, 23 Jan 2013 13:45:24 -0600 Subject: [erlang-questions] Halp! We're getting this SSL / ASN1 error Message-ID: We're using sendhub.com to send some SMS messages in one of our Erlang modules, and we started getting this error from R14B04 around January 10 when they replaced their SSL certificate with a new one: Erlang R14B04 (erts-5.8.5) [source] [64-bit] [rq:1] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.8.5 (abort with ^G) 1> ssl:start(). ok 2> inets:start(). ok 3> httpc:request(post, {"https://api.sendhub.com/v1/messages/?username=FAKEFAKE&api_key=FAKEFAKE", [], "application/json", <<"{\"contacts\":[], \"groups\": [\"FAKE\"], \"text\": \"this is a test\"}">>}, [], []). Ginormous SSL data structure removed... ** Reason for termination = ** {{badmatch, {error, {asn1, {'Type not compatible with table constraint', {{component,'Type'}, {value,{5,<<>>}}, {unique_name_and_value,id,{1,2,840,113549,1,1,11}}}}}}}, [{public_key,pkix_decode_cert,2}, {public_key,path_validation,2}, {ssl_handshake,certify,7}, {ssl_connection,certify,2}, {ssl_connection,next_state,3}, {gen_fsm,handle_msg,7}, {proc_lib,init_p_do_apply,3}]} {error, {eoptions, {{{badmatch, {error, {asn1, {'Type not compatible with table constraint', {{component,'Type'}, {value,{5,<<>>}}, {unique_name_and_value,id, {1,2,840,113549,1,1,11}}}}}}}, [{public_key,pkix_decode_cert,2}, {public_key,path_validation,2}, {ssl_handshake,certify,7}, {ssl_connection,certify,2}, {ssl_connection,next_state,3}, {gen_fsm,handle_msg,7}, {proc_lib,init_p_do_apply,3}]}, {gen_fsm,sync_send_all_state_event, [<0.63.0>,start,infinity]}}}} This problem only seems to happen on R14B04 - R15B+ works perfectly and so does an equivalent curl command line option. Does anyone know how to overcome this error? Thanks. Mark Allen Sr. Software Developer Alert Logic, Inc. mallen@REDACTED Security ? Compliance ? Cloud From bchesneau@REDACTED Wed Jan 23 21:50:25 2013 From: bchesneau@REDACTED (Benoit Chesneau) Date: Wed, 23 Jan 2013 21:50:25 +0100 Subject: [erlang-questions] Need help with folsom usage In-Reply-To: References: <20130123171453.GA77672@zmac> <20130123184714.GA78630@zmac> Message-ID: On Wed, Jan 23, 2013 at 8:28 PM, Max Lapshin wrote: > Ok, got it. > > > @max anyway maybe that could help: https://github.com/campanja/folsomite/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirker@REDACTED Wed Jan 23 22:42:19 2013 From: dirker@REDACTED (=?ISO-8859-1?Q?Dirk_H=F6rner?=) Date: Wed, 23 Jan 2013 22:42:19 +0100 Subject: [erlang-questions] installing to --prefix, but running symlinked somewhere else Message-ID: Hi all, I am using erlang on Mac OS X and am using homebrew (a package manager, https://github.com/mxcl/homebrew) to keep my erlang installation up-to-date. Now homebrew installs all packages into its own directory and then symlinks the files into the right spot, like this: Installed to (--prefix): /usr/local/Cellar/erlang/R15B03 Symlinked to and run in: /usr/local With the default erlang build options, this makes erlang look for its app under /usr/local/Cellar/erlang/R15B03/lib/erlang/lib. However third party apps install into /usr/local/lib/erlang/lib, and erlang cannot find them there. Currently I am fixing this by crudely changing $ROOTDIR in .../lib/erlang/bin/erl and .../lib/erlang/bin/start, but I am wondering if there is a better way to do this? And if there is not, is my hack causing any side effects I am not seeing yet? Thanks, Dirk -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Wed Jan 23 22:56:53 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 23 Jan 2013 13:56:53 -0800 Subject: [erlang-questions] installing to --prefix, but running symlinked somewhere else In-Reply-To: References: Message-ID: <20130123215651.GA74381@ferdmbp.local> I assume that by apps you mean OTP apps you end up installing on your system. There's an ENV variable called ERL_LIBS that can point to one or more directories that contains OTP app directories, and that Erlang can look for when booting up. Dump your apps in there, and either export ERL_LIBS=/your/directory, or run it as $ erl -env ERL_LIBS=/your/directory (works cross-platform) to get your Erlang copy to look wherever. By default it'll pick the newest apps. This is an especially nice feature because it lets you have many different sets of installed applications to work with on a per-release or per-project basis. I hope this helps, Fred. On 01/23, Dirk H?rner wrote: > Hi all, > > I am using erlang on Mac OS X and am using homebrew (a package manager, > https://github.com/mxcl/homebrew) to keep my erlang installation > up-to-date. Now homebrew installs all packages into its own directory and > then symlinks the files into the right spot, like this: > > Installed to (--prefix): /usr/local/Cellar/erlang/R15B03 > Symlinked to and run in: /usr/local > > With the default erlang build options, this makes erlang look for its app > under /usr/local/Cellar/erlang/R15B03/lib/erlang/lib. However third party > apps install into /usr/local/lib/erlang/lib, and erlang cannot find them > there. > > Currently I am fixing this by crudely changing $ROOTDIR in > .../lib/erlang/bin/erl and .../lib/erlang/bin/start, but I am wondering if > there is a better way to do this? And if there is not, is my hack causing > any side effects I am not seeing yet? > > Thanks, > Dirk > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ok@REDACTED Thu Jan 24 01:06:37 2013 From: ok@REDACTED (Richard O'Keefe) Date: Thu, 24 Jan 2013 13:06:37 +1300 Subject: [erlang-questions] SAX-like JSON Parser for Erlang In-Reply-To: References: <1358517301.25429.YahooMailNeo@web120702.mail.ne1.yahoo.com> <0B25DEFA-2C1C-4AF0-A17A-22CAEFC695A8@cs.otago.ac.nz> <251E5F40-6401-422E-BD39-C11963AAB980@cs.otago.ac.nz> Message-ID: <2AA0112A-6573-4881-A14B-71A746D2112B@cs.otago.ac.nz> On 23/01/2013, at 8:02 PM, Bob Ippolito wrote: > Sounds like I ought to fix up that documentation. > > My primary goal was to just clone Apple's Key-Value Coding API (which I should've stated more explicitly in the README). I never used this library for anything but introspecting data structures interactively in the shell. In that environment I find it to be friendlier if I can input the paths as an atom or string. Efficiency wasn't much of a concern. That should definitely be stated in the documentation. I don't find [foo,bar,ugh] any harder to type than <<"foo.bar.ugh">> or for that matter "foo.bar.ugh". Same number of characters as the string, four fewer than the binary. foo.bar.ugh I grant you. There is one crucial feature of Apple's key-value coding that does not apply in the Erlang context. Each non-@ step must be the name of an Objective C selector or variable. That means that such steps cannot themselves contain dots or at-signs. Erlang atoms _may_ contain dots and at-signs, and may even do so without quoting. alpher@REDACTED is a perfectly good Erlang unquoted atom. > I have a key-value component for my Smalltalk library, and > in that (1,3,4) were not issues, but (2) had my programmer's > instincts screaming 'this is a bad idea'. In fact one of the > things on my TODO list is to replace > aPath subStrings: ' .' asClass: Symbol trimmed: true > by > aPath _steps > in order to let aPath be returned if it's a sequence of steps > already. Did it last night. I decided to call it #asPropertyPath rather than #_steps. From fritchie@REDACTED Thu Jan 24 01:06:52 2013 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Wed, 23 Jan 2013 18:06:52 -0600 Subject: [erlang-questions] On internals of the VM and message delivery In-Reply-To: Message of "Tue, 22 Jan 2013 18:42:00 +0100." Message-ID: <40253.1358986012@snookles.snookles.com> Alessandro Sivieri wrote: sa> [...] Where is the message extracted then? Allesandro, there might be some helpful DTrace probes added along the message receive path ... perhaps they're helpful in your case? In erts/emulator/beam/erlang_dtrace.d there are these probes: probe message__queued(char *receiver, uint32_t size, uint32_t queue_len, int token_label, int token_previous, int token_current); probe message__receive(char *receiver, uint32_t size, uint32_t queue_len, int token_label, int token_previous, int token_current); The C preprocessor macros that I'd created would mangle the probe names to "message_queued" and "message_received", respectively. Here's one example from erts/emulator/beam/erl_message.c: if (DTRACE_ENABLED(message_queued)) { DTRACE_CHARBUF(receiver_name, DTRACE_TERM_BUF_SIZE); dtrace_proc_str(rcvr, receiver_name); if (token != NIL && token != am_have_dt_utag) { tok_label = signed_val(SEQ_TRACE_T_LABEL(token)); tok_lastcnt = signed_val(SEQ_TRACE_T_LASTCNT(token)); tok_serial = signed_val(SEQ_TRACE_T_SERIAL(token)); } DTRACE6(message_queued, receiver_name, size_object(msg), rcvr->msg.len, tok_label, tok_lastcnt, tok_serial); } -Scott From ok@REDACTED Thu Jan 24 02:52:25 2013 From: ok@REDACTED (Richard O'Keefe) Date: Thu, 24 Jan 2013 14:52:25 +1300 Subject: [erlang-questions] If you are homesick for object.selector Message-ID: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> We've had a claim recently that using Person#person_name instead of Person.name is so horrible that it's scaring off people who would otherwise use Erlang. What would be _Erlangish_ approach to this look like? (Apart from implementing frames, of course.) I think PL/I was the first language to use "." for field selection. COBOL and Algol 68 used (selector OF record). In the statement x = thingy.selector; what is ".selector"? It is nothing other than a function, applied to the argument "thingy" to yield a result. What's the Erlang syntax for applying a function to an argument? X = selector(Thingy) In the statement thingy.selector = y; what is ".selector ="? It is nothing other than a function, applied to two arguments. What's the Erlang syntax for applying a function to two arguments? Thingy1 = set_selector(Thingy0, Y) Now we can define these things manually. We just have to include a clause for each visible record type. What's the Erlang way to generate functions automatically from declarative information? Use attributes to provide the information and a parse transform to do the generation. For example, you might write -record(person, {id,name,department_id,manager_id,age,job}). -record(department, {id,name, manager_id}). -record(project, {id,name,department_id}). -getters([id,name]). -setters([name]). From that, you might like to get automatically generated code like id({person,F,_,_,_,_,_}) -> F; id({department,F,_,_}) -> F; id({project,F,_,_}) -> F. name({person,_,F,_,_,_,_}) -> F; name({department,_,F,_}) -> F; name({project,_,F,_}) -> F. set_name({person,X1,_,X3,X4,X5,X6}, F) -> {person,X1,F,X3,X4,X5,X6}; set_name({department,X1,_,X3}, F) -> {department,X1,F,X3}; set_name({project,X1,_,X3}, F) -> {project,X1,F,X3}. Well, as it happens, that code _was_ automatically generated, and it was automatically generated from those lines. This was just a quick prototype, so I whipped it up in AWK. Two pages with comments, one page without. The _right_ way is a parse transform, of course. I don't regard this design as settled, so there's no EEP. For example, it's reasonable to want automatically generated -spec declarations as well, which would generally look like -spec (#{}) -> ; (#{}) -> ... . -spec set_(R, ) -> R when R :: #{} ; (R, ) -> R when R :: #{} ... . but this is tedious rather than difficult. For another thing, you might want to give the selector function a different name from the field and you might not want all possible records for some selector function. The nice thing is that code generators like this can be written entirely in Erlang using existing features. From essen@REDACTED Thu Jan 24 03:21:26 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Thu, 24 Jan 2013 03:21:26 +0100 Subject: [erlang-questions] common_test usability enhancement Message-ID: <51009AA6.7010401@ninenines.eu> Hello, I've been wondering how to have a common url for repeated ct tests. For example if I'm fixing a few things I'd like to just refresh the browser to see how far I got. Problem is timestamps prevent that. Instead of this URL: file://localhost/home/essen/extend/cowboy/logs/ct_run.ct@REDACTED/extend.cowboy.eunit_SUITE.logs/run.2013-01-24_03.10.50/eunit_suite.eunit.html I want something like this: file://localhost/home/essen/extend/cowboy/logs/last.ct@REDACTED/extend.cowboy.eunit_SUITE.logs/run/eunit_suite.eunit.html I started fixing the first part with a naive enough patch as follow: diff --git a/lib/common_test/src/ct_logs.erl b/lib/common_test/src/ct_logs.erl index 0b7a8bb..95e85c5 100644 --- a/lib/common_test/src/ct_logs.erl +++ b/lib/common_test/src/ct_logs.erl @@ -536,6 +536,11 @@ logger(Parent, Mode, Verbosity) -> AbsDir = ?abs(Dir), put(ct_run_dir, AbsDir), + %% create a symlink always pointing to the last run + New = "last-" ++ atom_to_list(node()), + _ = file:delete(New), + _ = file:make_symlink(Dir, New), + case basic_html() of true -> put(basic_html, true); I think it could be accepted into OTP easily, but this only fixes half the problem. The other part is harder. I'd very much like to receive guidance on how to achieve my goal and have it be good enough to be included in OTP. Perhaps it'd require an option to disable the timestamp in the second part of the URL? I don't know. Any pointers would help. Thanks. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From darach@REDACTED Thu Jan 24 03:24:37 2013 From: darach@REDACTED (Darach Ennis) Date: Thu, 24 Jan 2013 02:24:37 +0000 Subject: [erlang-questions] common_test usability enhancement In-Reply-To: <51009AA6.7010401@ninenines.eu> References: <51009AA6.7010401@ninenines.eu> Message-ID: Hi Lo?c, I've been using ct a lot recently and would like to be able to see the same behaviour. Removing the time stamp from latest results would save a lot of navigation & reloads. Another issue is configuring 'total coverage' reports & merging ct with eunit reports. The incantations are not obvious... If the default URLs represented 'latest' and the timestamped URLs were preserved, wouldn't that be ideal? Regards, Darach. On 24 Jan 2013, at 02:21, Lo?c Hoguin wrote: > Hello, > > I've been wondering how to have a common url for repeated ct tests. For example if I'm fixing a few things I'd like to just refresh the browser to see how far I got. Problem is timestamps prevent that. > > Instead of this URL: > > file://localhost/home/essen/extend/cowboy/logs/ct_run.ct@REDACTED/extend.cowboy.eunit_SUITE.logs/run.2013-01-24_03.10.50/eunit_suite.eunit.html > > I want something like this: > > file://localhost/home/essen/extend/cowboy/logs/last.ct@REDACTED/extend.cowboy.eunit_SUITE.logs/run/eunit_suite.eunit.html > > I started fixing the first part with a naive enough patch as follow: > > diff --git a/lib/common_test/src/ct_logs.erl b/lib/common_test/src/ct_logs.erl > index 0b7a8bb..95e85c5 100644 > --- a/lib/common_test/src/ct_logs.erl > +++ b/lib/common_test/src/ct_logs.erl > @@ -536,6 +536,11 @@ logger(Parent, Mode, Verbosity) -> > AbsDir = ?abs(Dir), > put(ct_run_dir, AbsDir), > > + %% create a symlink always pointing to the last run > + New = "last-" ++ atom_to_list(node()), > + _ = file:delete(New), > + _ = file:make_symlink(Dir, New), > + > case basic_html() of > true -> > put(basic_html, true); > > I think it could be accepted into OTP easily, but this only fixes half the problem. The other part is harder. > > I'd very much like to receive guidance on how to achieve my goal and have it be good enough to be included in OTP. Perhaps it'd require an option to disable the timestamp in the second part of the URL? I don't know. Any pointers would help. > > Thanks. > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From essen@REDACTED Thu Jan 24 03:37:47 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Thu, 24 Jan 2013 03:37:47 +0100 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> Message-ID: <51009E7B.5090902@ninenines.eu> Richard, There is already this: https://github.com/esl/parse_trans/blob/master/src/exprecs.erl But I think their point is that Person.name does not require extra keystrokes to get the value, as opposed to Person#person.name or person:name(Person). They're incorrect when claiming it makes things harder, it's just a lot more tedious, especially if you have a lot of different values to manipulate. A simple example would be an RPG video game character, which has various kinds of state, a name, a class, stats, equipped items, inventory, unlocks, friends, quickchat, options and more. Erlang makes programming this kind of thing a nightmare, and all that simply because you can't do something like: Character.current_weapon.ability.points_req Or Character.inventory[0].name Or at least, not without a lot more keystrokes. And let's not even speak about actually modifying these values or adding an item to the inventory. In a language as horrible as PHP, adding an item to the inventory can be written as: Character->inventory[] = Item; You of course have to know what [] means, but it makes the code incredibly easier to read. Erlang lacks all these easy data manipulation facilities. I am not sure this can be fully resolved. Of course, perhaps one could use some Lua behind Erlang to do the game logic, but that's not really a good selling point for people to use Erlang, it's at best a compromise. On 01/24/2013 02:52 AM, Richard O'Keefe wrote: > We've had a claim recently that using > Person#person_name > instead of > Person.name > is so horrible that it's scaring off people who would otherwise > use Erlang. > > What would be _Erlangish_ approach to this look like? > (Apart from implementing frames, of course.) > > I think PL/I was the first language to use "." for > field selection. COBOL and Algol 68 used (selector OF record). > > In the statement > > x = thingy.selector; > > what is ".selector"? > > It is nothing other than a function, applied to the argument > "thingy" to yield a result. > > What's the Erlang syntax for applying a function to an argument? > > X = selector(Thingy) > > In the statement > > thingy.selector = y; > > what is ".selector ="? > > It is nothing other than a function, applied to two arguments. > What's the Erlang syntax for applying a function to two arguments? > > Thingy1 = set_selector(Thingy0, Y) > > Now we can define these things manually. We just have to include > a clause for each visible record type. > > What's the Erlang way to generate functions automatically from > declarative information? > > Use attributes to provide the information and a parse transform > to do the generation. > > For example, you might write > > -record(person, {id,name,department_id,manager_id,age,job}). > -record(department, {id,name, manager_id}). > -record(project, {id,name,department_id}). > -getters([id,name]). > -setters([name]). > > From that, you might like to get automatically generated code like > > id({person,F,_,_,_,_,_}) -> F; > id({department,F,_,_}) -> F; > id({project,F,_,_}) -> F. > > name({person,_,F,_,_,_,_}) -> F; > name({department,_,F,_}) -> F; > name({project,_,F,_}) -> F. > > set_name({person,X1,_,X3,X4,X5,X6}, F) -> > {person,X1,F,X3,X4,X5,X6}; > set_name({department,X1,_,X3}, F) -> > {department,X1,F,X3}; > set_name({project,X1,_,X3}, F) -> > {project,X1,F,X3}. > > Well, as it happens, that code _was_ automatically generated, and > it was automatically generated from those lines. This was just a > quick prototype, so I whipped it up in AWK. Two pages with comments, > one page without. The _right_ way is a parse transform, of course. > > I don't regard this design as settled, so there's no EEP. > For example, it's reasonable to want automatically generated -spec > declarations as well, which would generally look like > > -spec (#{}) -> > ; (#{}) -> > ... . > -spec set_(R, ) -> R when R :: #{} > ; (R, ) -> R when R :: #{} > ... . > > but this is tedious rather than difficult. > > For another thing, you might want to give the selector function a different > name from the field and you might not want all possible records for some > selector function. > > The nice thing is that code generators like this can be written entirely > in Erlang using existing features. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From rustompmody@REDACTED Thu Jan 24 06:27:16 2013 From: rustompmody@REDACTED (Rustom Mody) Date: Thu, 24 Jan 2013 10:57:16 +0530 Subject: [erlang-questions] hobbyists, erlang, elixir (was Improve $handle_undefined_function) In-Reply-To: <1E189E8B-2DB7-4E55-B473-AAFA7F2062C3@cs.otago.ac.nz> References: <50FF23A4.3090604@simonstl.com> <1E189E8B-2DB7-4E55-B473-AAFA7F2062C3@cs.otago.ac.nz> Message-ID: On Wed, Jan 23, 2013 at 10:14 AM, Richard O'Keefe wrote: > > And Rob Hagan at Monash had shown that > you could teach students more COBOL with one semester > of Scheme and one semester of COBOL than you could > with three semesters of COBOL. > Nice! One of the difficulties in being a teacher is that we know: - Yes, facts are important. - Learning them is more important - The learning-curve more so still. In established disciplines like music-education this is a commonplace. If we challenge the student too little, they lose interest; too much and wrong habits get fostered and set. One problem is that Computer Science departments simply do not have > the time to teach everything they need to teach. Students want to > leave in 3 years with qualifications an employer will like, and > employers want 'practical' languages in CVs. I have a colleague > who cannot spell because he was taught to read using the Initial > Teaching Alphabet, so I'm less convinced about the educational > benefits of neat languages than I used to be. > The problem in CS is that we do not agree (or even know) what is easy, what is hard and how to calibrate from easy to hard. How many established teachers know that concurrency can be easier than it is in C/Java? In this respect I maintain a list of traditional CS-edu-mistakes at http://blog.languager.org/2011/02/cs-education-is-fat-and-weak-1.html and http://blog.languager.org/2011/02/cs-education-is-fat-and-weak-2.html On the other hand I should mention that I just finished teaching a course on erlang. I found it very hard. I simply assumed that it is because I am too much of a noob to really 'get' it yet. [When one has taught programming for 25 years, its funny how often one hears a beginning student protest: "The compiler has a BUG!"] However after seeing Simon's comments below, I feel a little mollified that perhaps I am a fool but not an utter fool :-) On Wed, Jan 23, 2013 at 9:06 PM, Simon St.Laurent wrote: > > I was delighted to find Erlang's shell, which made using this compiled > language much friendlier. I was amazed by its remote capabilities. But > then I was bluntly disappointed by the difficulty of using it as an > environment - even a trivial environment - for interactive applications. > It became clear quickly that the beauty of my examples would have to be > abstract, because there wasn't going to be much I could show without > endless preamble to distract readers from the basics. > > Erlang (or maybe it will be Elixir) has the power to be a language that > transforms computing. It has the right tools to solve common problems. > > However, it may take some extra work to make it easier for people to see > that! > > > Thanks, > -- > Simon St.Laurent > http://simonstl.com/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zerthurd@REDACTED Thu Jan 24 10:09:45 2013 From: zerthurd@REDACTED (Maxim Treskin) Date: Thu, 24 Jan 2013 16:09:45 +0700 Subject: [erlang-questions] [ANN] Erlang distributed node in Go Message-ID: Glad to present implementation of Erlang distributed node in Go https://github.com/goerlang/node Supported features: - Publish listen port via EPMD - Handle incoming connection from other node using Erlang Distribution Protocol - Spawn Erlang-like processes - Register and unregister processes with simple atom - Send messages to registered (using atom) or not registered (using Pid) processes at Go-node or remote Erlang-node - Create own process with GenServer behaviour (like gen_server in Erlang/OTP) Pull requests are welcome! -- Max Treskin -------------- next part -------------- An HTML attachment was scrubbed... URL: From olav@REDACTED Thu Jan 24 10:12:55 2013 From: olav@REDACTED (Olav Frengstad) Date: Thu, 24 Jan 2013 10:12:55 +0100 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <51009E7B.5090902@ninenines.eu> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> Message-ID: An alternative syntax for working with (nested) records is functional lenses, the downside being evaluated at runtime opposed to a compiled parse transform solution. However this does not save you any keystrokes for Obj.selector type expressions. Taking Lo?c's example: {Get,Set} = compose([#char.cur_weapon, #weapon.ability, #ability.points_req]), Character2 = S(123, Character), 123 = G(Character2). Jesper Louis Andersen wrote a simple Erlang implementation which can be found here: https://github.com/jlouis/erl-lenses Olav 2013/1/24 Lo?c Hoguin : > Richard, > > There is already this: > https://github.com/esl/parse_trans/blob/master/src/exprecs.erl > > But I think their point is that Person.name does not require extra > keystrokes to get the value, as opposed to Person#person.name or > person:name(Person). > > They're incorrect when claiming it makes things harder, it's just a lot more > tedious, especially if you have a lot of different values to manipulate. A > simple example would be an RPG video game character, which has various kinds > of state, a name, a class, stats, equipped items, inventory, unlocks, > friends, quickchat, options and more. Erlang makes programming this kind of > thing a nightmare, and all that simply because you can't do something like: > > Character.current_weapon.ability.points_req > > Or > > Character.inventory[0].name > > Or at least, not without a lot more keystrokes. And let's not even speak > about actually modifying these values or adding an item to the inventory. In > a language as horrible as PHP, adding an item to the inventory can be > written as: > > Character->inventory[] = Item; > > You of course have to know what [] means, but it makes the code incredibly > easier to read. Erlang lacks all these easy data manipulation facilities. I > am not sure this can be fully resolved. > > Of course, perhaps one could use some Lua behind Erlang to do the game > logic, but that's not really a good selling point for people to use Erlang, > it's at best a compromise. > > > On 01/24/2013 02:52 AM, Richard O'Keefe wrote: >> >> We've had a claim recently that using >> Person#person_name >> instead of >> Person.name >> is so horrible that it's scaring off people who would otherwise >> use Erlang. >> >> What would be _Erlangish_ approach to this look like? >> (Apart from implementing frames, of course.) >> >> I think PL/I was the first language to use "." for >> field selection. COBOL and Algol 68 used (selector OF record). >> >> In the statement >> >> x = thingy.selector; >> >> what is ".selector"? >> >> It is nothing other than a function, applied to the argument >> "thingy" to yield a result. >> >> What's the Erlang syntax for applying a function to an argument? >> >> X = selector(Thingy) >> >> In the statement >> >> thingy.selector = y; >> >> what is ".selector ="? >> >> It is nothing other than a function, applied to two arguments. >> What's the Erlang syntax for applying a function to two arguments? >> >> Thingy1 = set_selector(Thingy0, Y) >> >> Now we can define these things manually. We just have to include >> a clause for each visible record type. >> >> What's the Erlang way to generate functions automatically from >> declarative information? >> >> Use attributes to provide the information and a parse transform >> to do the generation. >> >> For example, you might write >> >> -record(person, {id,name,department_id,manager_id,age,job}). >> -record(department, {id,name, manager_id}). >> -record(project, {id,name,department_id}). >> -getters([id,name]). >> -setters([name]). >> >> From that, you might like to get automatically generated code like >> >> id({person,F,_,_,_,_,_}) -> F; >> id({department,F,_,_}) -> F; >> id({project,F,_,_}) -> F. >> >> name({person,_,F,_,_,_,_}) -> F; >> name({department,_,F,_}) -> F; >> name({project,_,F,_}) -> F. >> >> set_name({person,X1,_,X3,X4,X5,X6}, F) -> >> {person,X1,F,X3,X4,X5,X6}; >> set_name({department,X1,_,X3}, F) -> >> {department,X1,F,X3}; >> set_name({project,X1,_,X3}, F) -> >> {project,X1,F,X3}. >> >> Well, as it happens, that code _was_ automatically generated, and >> it was automatically generated from those lines. This was just a >> quick prototype, so I whipped it up in AWK. Two pages with comments, >> one page without. The _right_ way is a parse transform, of course. >> >> I don't regard this design as settled, so there's no EEP. >> For example, it's reasonable to want automatically generated -spec >> declarations as well, which would generally look like >> >> -spec (#{}) -> >> ; (#{}) -> >> ... . >> -spec set_(R, ) -> R when R :: #{} >> ; (R, ) -> R when R :: #{} >> ... . >> >> but this is tedious rather than difficult. >> >> For another thing, you might want to give the selector function a >> different >> name from the field and you might not want all possible records for some >> selector function. >> >> The nice thing is that code generators like this can be written entirely >> in Erlang using existing features. >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Med Vennlig Hilsen Olav Frengstad Systemutvikler // FWT +47 920 42 090 From attila.r.nohl@REDACTED Thu Jan 24 10:43:47 2013 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Thu, 24 Jan 2013 10:43:47 +0100 Subject: [erlang-questions] common_test usability enhancement In-Reply-To: References: <51009AA6.7010401@ninenines.eu> Message-ID: Hello! I agree, a 'latest' URL would be great to have. 2013/1/24 Darach Ennis : > Hi Lo?c, > > I've been using ct a lot recently and would like to be able to see the same behaviour. > > Removing the time stamp from latest results would save a lot of navigation & reloads. > > Another issue is configuring 'total coverage' reports & merging ct with eunit reports. The incantations are not obvious... > > If the default URLs represented 'latest' and the timestamped URLs were preserved, wouldn't that be ideal? > > Regards, > > Darach. > > On 24 Jan 2013, at 02:21, Lo?c Hoguin wrote: > >> Hello, >> >> I've been wondering how to have a common url for repeated ct tests. For example if I'm fixing a few things I'd like to just refresh the browser to see how far I got. Problem is timestamps prevent that. >> >> Instead of this URL: >> >> file://localhost/home/essen/extend/cowboy/logs/ct_run.ct@REDACTED/extend.cowboy.eunit_SUITE.logs/run.2013-01-24_03.10.50/eunit_suite.eunit.html >> >> I want something like this: >> >> file://localhost/home/essen/extend/cowboy/logs/last.ct@REDACTED/extend.cowboy.eunit_SUITE.logs/run/eunit_suite.eunit.html >> >> I started fixing the first part with a naive enough patch as follow: >> >> diff --git a/lib/common_test/src/ct_logs.erl b/lib/common_test/src/ct_logs.erl >> index 0b7a8bb..95e85c5 100644 >> --- a/lib/common_test/src/ct_logs.erl >> +++ b/lib/common_test/src/ct_logs.erl >> @@ -536,6 +536,11 @@ logger(Parent, Mode, Verbosity) -> >> AbsDir = ?abs(Dir), >> put(ct_run_dir, AbsDir), >> >> + %% create a symlink always pointing to the last run >> + New = "last-" ++ atom_to_list(node()), >> + _ = file:delete(New), >> + _ = file:make_symlink(Dir, New), >> + >> case basic_html() of >> true -> >> put(basic_html, true); >> >> I think it could be accepted into OTP easily, but this only fixes half the problem. The other part is harder. >> >> I'd very much like to receive guidance on how to achieve my goal and have it be good enough to be included in OTP. Perhaps it'd require an option to disable the timestamp in the second part of the URL? I don't know. Any pointers would help. >> >> Thanks. >> >> -- >> Lo?c Hoguin >> Erlang Cowboy >> Nine Nines >> 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 erlang@REDACTED Thu Jan 24 12:26:47 2013 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 24 Jan 2013 12:26:47 +0100 Subject: [erlang-questions] hobbyists, erlang, elixir (was Improve $handle_undefined_function) In-Reply-To: References: <50FF23A4.3090604@simonstl.com> <1E189E8B-2DB7-4E55-B473-AAFA7F2062C3@cs.otago.ac.nz> Message-ID: Old timer here ... When I learnt programming (1967) , I could choose between FORTRAN and (it was rumoured, Algol) but nobody knew anything about Algol so it was FORTRAN. The turn round time for a program was three weeks week 1 - write code on paper forms - send to computer center to be turned into punched cards week 2 - review punched cards, if ok send to machine week 3 - results The compiler helpfully stopped at the first syntax error which got you back to week 1 - so if you had say ten errors in your program it would take 30 weeks to get it running. This is a pretty good environment - teaches you not to make mistakes and to think first. By about 1970 I was at university and turn round times were down to 4 hours and you could punch your own cards - it was still FORTRAN By 1974 I got access to a computer -- a honywell DDP516 - with a colossal 32 KB memory. So the 474 pass FORTRAN compiler could compile a hundred line program in less than a week (or so ...) Things improved - I went to CERN and used the CRAY1 this could compile 100K lines of FORTRAN in 1 picosecond (ie about a zillion times slower than my mobile phone today) Still Fortran. In 1974 (ish) I got to play with a DEC10 - Now I could write FORTRAN, Basic, assembler and it had time-sharing (wow) turn round times of seconds. If I'd been In the USA I'd be Bill Gates, but this was Edinburgh. In 1976 I got a job programming a NORD10 in FORTRAN/Assembler and it was really fast turn round times of seconds. In 1980 ish I was still programming in FORTRAN - I forget the name of the machine all files were in one directory, no full-screen editor, no revision control system, I wrote about 150K lines of FORTRAN for it. 1985 I joined Ericsson - wow a VAX11/750 - new languages to learn. Bye bye FORTRAN I learnt (with various degrees of proficiency) Lisp, Prolog, awk, bash, smalltalk, TCL, and became proficient in Prolog (aggghhh - the beauty ....) I also played with just about any language I could get my hands on (ML, forth, ...) Then I (1986) got into my Erlang Phase (I couldn't really learn Erlang, 'cos it didn't exist, so I invented it) - it was really an outgrowth of Prolog+Smalltalk with a bit of error recovery concurrency and distribution throw in. Then I learnt (badly) C - But Mike Williams said my C was crap and looked like Fortran so he binned my C ... (why use malloc and free and pointers anyway ...) I saw C++ coming and read the book - or at least tried to read the book - there's a dent in the wall behind my piano, where the book hit the wall - Improvements to C should make things easier not more complicated, I thought. Time passed. I tried Java (not impressed, ok it's better than C++, but oh so verbose, I used to get programmers "white fingers" when programming FORTRAN you have to write hundreds of lines to do the smallest thing - Java seemed similar - so verbose) - I also (later) tried Python (ok), Ruby (ok), Lua(better), Javascript(I like :-) It's actually taken me quite a long time to learn all these languages, and they didn't all come at once. I had a good 15 years of FORTRAN - long enough to get good at it, 10 years of Prolog, 20 years of Erlang etc. I also had a long time to assimilate the new ideas - the ideas in programming come pretty slowly - once every twenty years or so somebody has a really good idea, programming today hasn't improved much in the last 20 years - it was mess then and it's still a mess. IDE's and revision control systems have just made matters worse - now you have all the old versions of the mess as well as the mess itself, and the IDE means you can't even see the mess. The best IDE in the world is your BRAIN - it's a zillion times better than these clicky things. What's this got to do with education? Suppose you're starting off. You can choose between twenty odd languages (all of them good for one reason or another) what took me 40 years to learn, you must try to understand in 2-3 years, this is just not possible. What languages should a beginner learn, what languages should a school teach? Now we get to the paradox of choice - because there are so many alternatives it becomes impossible to choose. Old timers say "choose the language appropriate to the problem" when you know 20 odd languages (with varying degrees of proficiency) this is easy to say - but If you know two languages Java and C then this isn't much help. There are literally problems where the solution in a CLP language is a few lines and is thousands of lines in C. What would I recommend learning? - C - Prolog - Erlang (I'm biased) - Smalltalk - Javascript - Hakell / ML /OCaml - LISP/Scheme/Clojure A couple of years should be enough (PER LANGUAGE). Notice there is no quick fix here - if you want a quick fix go buy "learn PHP in ten minutes" and spend the next twenty years googling for "how do I compute the length of a string" The crazy think is we still are extremely bad at fitting things together - still the best way of fitting things together is the unix pipe find ... | grep | uniq | sort | ... and the *fundamental* reason for this is that components should be separated by well-defined protocols in a universal intermediate language. Fitting things together by message passing is the way to go - this is basis of OO programming - but done badly in most programming languages. If ALL applications in the world were interfaced by (say) sockets + lisp S expressions and had the semantics of the protocol written down in a formal notation - then we could reuse things (more) easily. Today there is an unhealthy concentration on language and efficiency and NOT on how things fit together and protocols - teach protocols and not languages. And teach ALGORITHMS. Cheers /Joe (The dates in the above are approximate) On Thu, Jan 24, 2013 at 6:27 AM, Rustom Mody wrote: > On Wed, Jan 23, 2013 at 10:14 AM, Richard O'Keefe wrote: > >> >> > And Rob Hagan at Monash had shown that >> you could teach students more COBOL with one semester >> of Scheme and one semester of COBOL than you could >> with three semesters of COBOL. >> > > Nice! One of the difficulties in being a teacher is that we know: > - Yes, facts are important. > - Learning them is more important > - The learning-curve more so still. > > In established disciplines like music-education this is a commonplace. > If we challenge the student too little, they lose interest; too much and > wrong habits get fostered and set. > > > One problem is that Computer Science departments simply do not have >> the time to teach everything they need to teach. Students want to >> leave in 3 years with qualifications an employer will like, and >> employers want 'practical' languages in CVs. I have a colleague >> who cannot spell because he was taught to read using the Initial >> Teaching Alphabet, so I'm less convinced about the educational >> benefits of neat languages than I used to be. >> > > The problem in CS is that we do not agree (or even know) what is easy, > what is hard and how to calibrate from easy to hard. How many established > teachers know that concurrency can be easier than it is in C/Java? > > In this respect I maintain a list of traditional CS-edu-mistakes at > http://blog.languager.org/2011/02/cs-education-is-fat-and-weak-1.html > and > http://blog.languager.org/2011/02/cs-education-is-fat-and-weak-2.html > > On the other hand I should mention that I just finished teaching a course > on erlang. > I found it very hard. I simply assumed that it is because I am too much > of a noob to really 'get' it yet. [When one has taught programming for 25 > years, its funny how often one hears a beginning student protest: "The > compiler has a BUG!"] > > However after seeing Simon's comments below, I feel a little mollified > that perhaps I am a fool but not an utter fool :-) > > On Wed, Jan 23, 2013 at 9:06 PM, Simon St.Laurent wrote: >> >> I was delighted to find Erlang's shell, which made using this compiled >> language much friendlier. I was amazed by its remote capabilities. But >> then I was bluntly disappointed by the difficulty of using it as an >> environment - even a trivial environment - for interactive applications. >> It became clear quickly that the beauty of my examples would have to be >> abstract, because there wasn't going to be much I could show without >> endless preamble to distract readers from the basics. >> >> Erlang (or maybe it will be Elixir) has the power to be a language that >> transforms computing. It has the right tools to solve common problems. >> >> However, it may take some extra work to make it easier for people to see >> that! >> >> >> Thanks, >> -- >> Simon St.Laurent >> http://simonstl.com/ >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tereskin@REDACTED Thu Jan 24 12:58:08 2013 From: tereskin@REDACTED (Andrew Tereskin) Date: Thu, 24 Jan 2013 03:58:08 -0800 (PST) Subject: [erlang-questions] Erlang binding to OpenCV In-Reply-To: References: Message-ID: Hi, Zab! I've implemented a http service for face detection (analog of face.com API) using opencv with erlang. On erlang side I opened worker processes connected using binary port (http://www.erlang.org/doc/tutorial/c_port.html) protocol to worker instances (just opencv program, with implemented read binary image and write result through port). I'm planing to open my implementation, but a bit later. If you have any questions I can paste some code. With best wishes, Andrew Tereskin ?????, 23 ?????? 2013 ?., 20:07:37 UTC+4 ???????????? Zabrane Mikael ???????: > > Hi guys, > > Any binding to OpenCV (or OpenCV 2)? > > -- > Regards > Zab > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zabrane3@REDACTED Thu Jan 24 13:24:45 2013 From: zabrane3@REDACTED (Zabrane Mikael) Date: Thu, 24 Jan 2013 13:24:45 +0100 Subject: [erlang-questions] Erlang binding to OpenCV In-Reply-To: References: Message-ID: Hi Andrew, It would be awesome if you decide to open it on github. I've a couple of ideas I'd like to test. Don't forget to ping me :-) -- Regards Zab 2013/1/24 Andrew Tereskin : > Hi, Zab! > > I've implemented a http service for face detection (analog of face.com API) > using opencv with erlang. On erlang side I opened worker processes connected > using binary port (http://www.erlang.org/doc/tutorial/c_port.html) protocol > to worker instances (just opencv program, with implemented read binary image > and write result through port). I'm planing to open my implementation, but a > bit later. If you have any questions I can paste some code. > > With best wishes, > Andrew Tereskin > > ?????, 23 ?????? 2013 ?., 20:07:37 UTC+4 ???????????? Zabrane Mikael > ???????: >> >> Hi guys, >> >> Any binding to OpenCV (or OpenCV 2)? >> >> -- >> Regards >> Zab >> _______________________________________________ >> erlang-questions mailing list >> erlang-q...@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions From jesper.louis.andersen@REDACTED Thu Jan 24 13:39:29 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 24 Jan 2013 13:39:29 +0100 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <51009E7B.5090902@ninenines.eu> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> Message-ID: <78E826B7-4C7B-4896-B9D0-5D061901F9D3@erlang-solutions.com> On Jan 24, 2013, at 3:37 AM, Lo?c Hoguin wrote: > Character.current_weapon.ability.points_req I think this is the major reason. It allows you to "chain" access to deep data. Note that this is a "projection" operation. You project out an element from the pair. The other solution, which is more Erlang-idiomatic is to match on the object and decode needed fields. But this solution is problematic when you need to access deep object data. What you really need is composition of lenses, and a neat syntax for doing so. That is a composable access language for obtaining data deep in structures. The usual chaining projection does *not* work in Erlang because you don't know the type of the object at compile time, unless you have the record name to help you. For that to work, you need frames, or something which works the same. On the other hand, when people access deep data like that, I often become concerned. Why is data not readily available to them but has to be dug up from far below the depths of a structure? Is this the right representation? There is overhead in following pointers and you can't always cache access over function boundaries. Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen From rickard@REDACTED Thu Jan 24 13:46:02 2013 From: rickard@REDACTED (Rickard Green) Date: Thu, 24 Jan 2013 13:46:02 +0100 Subject: [erlang-questions] Why system_flag(scheduler_bind_type) is deprecated? In-Reply-To: References: <201301081304.02164.clist@uah.es> Message-ID: <51012D0A.9040309@erlang.org> Commit 209655e30a82cdf172211278e01807024eed4130 implements +stbt. The commit is based on OTP_R15B03 and has been merged into master (to be R16A). Regards, Rickard -- Rickard Green, Erlang/OTP, Ericsson AB. From matthias@REDACTED Thu Jan 24 13:49:48 2013 From: matthias@REDACTED (Matthias Lang) Date: Thu, 24 Jan 2013 13:49:48 +0100 Subject: [erlang-questions] erlc speed (or lack thereof), Make and emake Message-ID: <20130124124948.GA4801@corelatus.se> Hi, I'm looking for tips and tricks to use speed up compiling a bunch of Erlang modules from within a build system that uses (gnu)Make. The system uses Erlang, but most of it is actually C code, which is compiled under four different compilers, plus FPGA code. So ditching 'make' for something Erlang-centric like 'rebar' doesn't look very attractive. Background ---------- Doing this on R14B03: erlc a.erl erlc b.erl erlc c.erl ... for 70 modules on my machine takes 39s. If I do this instead: erlc a.erl b.erl c.erl ... it improves to 7s. If I split the job in two parts which run at the same time, it improves again to 4s wall time, with both cores busy. So, a 10x improvement in compilation speed seems attainable, but how do I explain how to do it to 'make'? Ideas ----- I had a few simple ideas for fixing this, but none really work. See below. The more complicated idea I have is to make a shell script replacement for 'erlc' which delegates the compilation work to an Erlang node which is already running. Seems workable, and it won't spring surprises on 'make', e.g. -j 4 will still do the right thing. Anyone got a neat idea? Rest of this mail is just a list of things that don't seem to work. Matt ====================================================================== Bad Idea #1: straightforward 'make' ----------- Here's my minimal starting point for a system of three modules, a b c: beams=(addsuffix .beam, a b c) %.beam: %.erl nasty_global_stuff.hrl erlc $< That causes 'make' to hand one module to erlc at a time, which is slow. Bad Idea #2: try and use just one rule for all .beams ----------- Like this: modules=a b c beams=$(addsuffix .beam, $(modules)) erls=$(addsuffix .erl, $(modules)) all: $(beams) $(beams): $(erls) nasty_global_stuff.hrl erlc $(filter %.erl, $@) That does almost the right thing, but actually not at all. Change one .erl and it'll recompile every .beam, because I've told 'make' that each .beam depends on all .erl files. Bad Idea #3: use erl -make for all Erlang compilations ----------- all: erl -make That sort-of works, but it only runs one process (Erlang's own 'make' doesn't seem to attempt running more than one compilation at a time), passing options is not straightforward (they're not even syntactically the same as for erlc) and it requires writing 'EMakefiles', so you sort-of have to understand Erlang in order to be able to fiddle with the build system. It's also fiddly explaining dependencies between Erlang stuff and other stuff to a combination of ordinary 'make' and erlang's own make. --end of bad ideas--- From max.lapshin@REDACTED Thu Jan 24 13:52:01 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 24 Jan 2013 15:52:01 +0300 Subject: [erlang-questions] Why system_flag(scheduler_bind_type) is deprecated? In-Reply-To: <51012D0A.9040309@erlang.org> References: <201301081304.02164.clist@uah.es> <51012D0A.9040309@erlang.org> Message-ID: Thank you! On Thu, Jan 24, 2013 at 4:46 PM, Rickard Green wrote: > Commit 209655e30a82cdf172211278e01807**024eed4130 implements +stbt. The > commit is based on OTP_R15B03 and has been merged into master (to be R16A). > > Regards, > Rickard > > -- > Rickard Green, Erlang/OTP, Ericsson AB. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From js@REDACTED Thu Jan 24 15:16:15 2013 From: js@REDACTED (Schneider) Date: Thu, 24 Jan 2013 15:16:15 +0100 Subject: [erlang-questions] Unixtime in Erlang Message-ID: <5101422F.9060902@globe.de> Hi List, is there a build-in way to get the unixtime of a given Date (all I'm looking for is now()), or do I have to use my own conversion method every time? bg, Johannes From dave@REDACTED Thu Jan 24 15:16:46 2013 From: dave@REDACTED (David Goehrig) Date: Thu, 24 Jan 2013 09:16:46 -0500 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <51009E7B.5090902@ninenines.eu> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> Message-ID: On Jan 23, 2013, at 9:37 PM, Lo?c Hoguin wrote: > Character.current_weapon.ability.points_req > > Or > > Character.inventory[0].name Putting my game programmer hat back on, given a choice I would prefer: Character weapon ability cost Where each is an application of a method on the prior or in Erlangy speak: cost(ability(weapon(Character))) Where in each function destructs and returns an element of the nested structure. I might for sake of argument want to further name them: costOf(abilityOf(weaponOf(Character))) Now in a typical game, weaponOf vectors to the currently selected item from the inventory. AbilityOf vectors off of the currently selected special assigned to the B button / right click slot, and the cost is tied to the level of the character for scaling (if you assume a fixed sized mana pool). Usually each of these behaviors require implicit knowledge of other state, and would likely make extensive use of get/put in the Character's process dictionary to vector accordingly. This would imply these structures are best managed in an entirely different manner, where the Character process should memoize the values in a process dictionary, and the interrogation should happen only once upon an equip(Weapon) method. Same issue goes with inventory. We probably need a weapons manual process that can be interrogated for details based on names. These changes would make it more likely to be a bunch of message sends. To WeaponManual, Inventory, Character, etc. It would be difficult to justify the dot notation as it wouldn't even remotely resemble how one would structure the message sends. Dave -=-=- dave@REDACTED -=-=- > > Character.current_weapon.ability.points_req > > Or > > Character.inventory[0].name From desired.mta@REDACTED Thu Jan 24 15:20:15 2013 From: desired.mta@REDACTED (=?UTF-8?Q?Motiejus_Jak=C5=A1tys?=) Date: Thu, 24 Jan 2013 14:20:15 +0000 Subject: [erlang-questions] Unixtime in Erlang In-Reply-To: <5101422F.9060902@globe.de> References: <5101422F.9060902@globe.de> Message-ID: 1> now(). {1359,37050,565742} Rest should be easy. $ date +%s 1359037050 os:timestamp() is a slightly faster version of erlang:now(). On Thu, Jan 24, 2013 at 2:16 PM, Schneider wrote: > Hi List, > is there a build-in way to get the unixtime of a given Date (all I'm looking > for is now()), > or do I have to use my own conversion method every time? > > bg, > Johannes > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Motiejus Jak?tys From atulatri2004@REDACTED Thu Jan 24 15:38:58 2013 From: atulatri2004@REDACTED (atul atri) Date: Thu, 24 Jan 2013 20:08:58 +0530 Subject: [erlang-questions] Two questions: a. Recommended Application design b. Erlang memory maangement Message-ID: Hi, I recently learned erlang to work on a chat application. I wrote a chat gateway for ejabberd. Here is my application design. Every time a user logs into ejabberd, two processes(gen_server) are created. These processes keep polling two different http addresses for new messages and new chat events. These two processes are responsible for getting/posting new chat events to/from a http server for each user. Communication is done using *big* XMLs. And XMLs are parsed using same parser used by ejabberd. Mnesia is used to store parsed XMLs. I used this design because 1. It is easy to implement polling using timeouts on message boxes. 2. I learned that erlang loves processes. So here is my first question. Is this application design correct? Or will you recommend any other design(like http request pool?)? So after creating this application, I load tested it. And here are some results. When around 250 users are logged in to ejabberd , memory uses reaches to 81% and CPU usages reaches to around 80%. I checked memory and CPU usages using 'top' command. And if I increase 20-30 more users, ejabberd crashes due to low memory. But when I use *erlang*:*garbage_collect*(self()) after parsing xml in each process, Memory usages remains from 25% to 40% for same 250 users. However CPU usages shoots above 90%. So, Here is my second question. Is it wise to use *erlang*:*garbage_collect*(self())? I have not seen *garbage_collect* uses anywhere else in any other application that I know. Also it would be great if some one could throw some light on how erlang garbage collector works. Why does not it recollect memory as soon as it is available to be recollected? Thanks & Regards, Atul Atri. -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Thu Jan 24 15:48:47 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Thu, 24 Jan 2013 15:48:47 +0100 Subject: [erlang-questions] erlc speed (or lack thereof), Make and emake In-Reply-To: <20130124124948.GA4801@corelatus.se> References: <20130124124948.GA4801@corelatus.se> Message-ID: <510149CF.4020500@ninenines.eu> On 01/24/2013 01:49 PM, Matthias Lang wrote: > Hi, > > I'm looking for tips and tricks to use speed up compiling a bunch of > Erlang modules from within a build system that uses (gnu)Make. > > The system uses Erlang, but most of it is actually C code, which is compiled > under four different compilers, plus FPGA code. So ditching 'make' > for something Erlang-centric like 'rebar' doesn't look very attractive. > > Background > ---------- > > Doing this on R14B03: > > erlc a.erl > erlc b.erl > erlc c.erl > ... > > for 70 modules on my machine takes 39s. If I do this instead: > > erlc a.erl b.erl c.erl ... > > it improves to 7s. If I split the job in two parts which run at the > same time, it improves again to 4s wall time, with both cores > busy. > > So, a 10x improvement in compilation speed seems attainable, but how do > I explain how to do it to 'make'? > > > Ideas > ----- > > I had a few simple ideas for fixing this, but none really work. See below. > > The more complicated idea I have is to make a shell script replacement > for 'erlc' which delegates the compilation work to an Erlang node > which is already running. Seems workable, and it won't spring > surprises on 'make', e.g. -j 4 will still do the right thing. > > Anyone got a neat idea? > > Rest of this mail is just a list of things that don't seem to work. > > Matt > > ====================================================================== > > > Bad Idea #1: straightforward 'make' > ----------- > > Here's my minimal starting point for a system of three modules, a b c: > > beams=(addsuffix .beam, a b c) > %.beam: %.erl nasty_global_stuff.hrl > erlc $< > > That causes 'make' to hand one module to erlc at a time, which is slow. > > > Bad Idea #2: try and use just one rule for all .beams > ----------- > > Like this: > > modules=a b c > beams=$(addsuffix .beam, $(modules)) > erls=$(addsuffix .erl, $(modules)) > all: $(beams) > > $(beams): $(erls) nasty_global_stuff.hrl > erlc $(filter %.erl, $@) > > That does almost the right thing, but actually not at all. Change one > .erl and it'll recompile every .beam, because I've told 'make' that > each .beam depends on all .erl files. > > > Bad Idea #3: use erl -make for all Erlang compilations > ----------- > > all: > erl -make > > That sort-of works, but it only runs one process (Erlang's own 'make' > doesn't seem to attempt running more than one compilation at a time), > passing options is not straightforward (they're not even syntactically > the same as for erlc) and it requires writing 'EMakefiles', so you > sort-of have to understand Erlang in order to be able to fiddle with > the build system. > > It's also fiddly explaining dependencies between Erlang stuff and > other stuff to a combination of ordinary 'make' and erlang's own make. > > --end of bad ideas--- When removing rebar dependency in the Cowboy makefile to improve my workflow, I ran into the same issues you did. The normal way of doing things with make is too damn slow. I'm assuming here that each erlc call starts an Erlang VM, which isn't made to be fast. I settled for this: https://github.com/extend/cowboy/blob/master/Makefile#L33 This recompiles everything all the time, but that's not really an issue for me. I might steal your bad idea #2 to avoid recompiling deps all the time though. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From avalormaquedano@REDACTED Thu Jan 24 15:49:03 2013 From: avalormaquedano@REDACTED (=?ISO-8859-1?B?wWx2YXJv?=) Date: Thu, 24 Jan 2013 15:49:03 +0100 Subject: [erlang-questions] Receive with priority [yet again] Message-ID: Hi all, I want to know what is the current implementation of Erlang's receive statement. I need to implement a system where two priorities can be given to messages (high and normal). I need to, first, process all high priority messages and then return the first normal priority one (if any). I wonder which its best implementation can be: process_all_messages()-> receive {high_priority, Message} -> % <--- Pattern1 process_message(Message), process_all_messages() after 0 -> receive {normal_priority, Message} -> % <--- Pattern2 Message after 0 -> no_messages end end. This function will be called periodically and I need to know if this implementation will always go through all the message in the mailbox (i.e. it will try to match Pattern1 to the messages at the beginning of the mailbox over and over again). Is there any recent improvement? Will I get any gain by implementing my own priority queue? Thanks a lot, ?lvaro -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Thu Jan 24 15:51:06 2013 From: watson.timothy@REDACTED (Tim Watson) Date: Thu, 24 Jan 2013 14:51:06 +0000 Subject: [erlang-questions] erlc speed (or lack thereof), Make and emake In-Reply-To: <510149CF.4020500@ninenines.eu> References: <20130124124948.GA4801@corelatus.se> <510149CF.4020500@ninenines.eu> Message-ID: <49347419-26CF-47A3-B5E6-693065AB9335@gmail.com> Take a look at the Rabbit Makefile - it doesn't recompile all the time *and* it works with -J and is generally really fast. http://hg.rabbitmq.com/rabbitmq-server/file/default/ Cheers, Tim On 24 Jan 2013, at 14:48, Lo?c Hoguin wrote: > On 01/24/2013 01:49 PM, Matthias Lang wrote: >> Hi, >> >> I'm looking for tips and tricks to use speed up compiling a bunch of >> Erlang modules from within a build system that uses (gnu)Make. >> >> The system uses Erlang, but most of it is actually C code, which is compiled >> under four different compilers, plus FPGA code. So ditching 'make' >> for something Erlang-centric like 'rebar' doesn't look very attractive. >> >> Background >> ---------- >> >> Doing this on R14B03: >> >> erlc a.erl >> erlc b.erl >> erlc c.erl >> ... >> >> for 70 modules on my machine takes 39s. If I do this instead: >> >> erlc a.erl b.erl c.erl ... >> >> it improves to 7s. If I split the job in two parts which run at the >> same time, it improves again to 4s wall time, with both cores >> busy. >> >> So, a 10x improvement in compilation speed seems attainable, but how do >> I explain how to do it to 'make'? >> >> >> Ideas >> ----- >> >> I had a few simple ideas for fixing this, but none really work. See below. >> >> The more complicated idea I have is to make a shell script replacement >> for 'erlc' which delegates the compilation work to an Erlang node >> which is already running. Seems workable, and it won't spring >> surprises on 'make', e.g. -j 4 will still do the right thing. >> >> Anyone got a neat idea? >> >> Rest of this mail is just a list of things that don't seem to work. >> >> Matt >> >> ====================================================================== >> >> >> Bad Idea #1: straightforward 'make' >> ----------- >> >> Here's my minimal starting point for a system of three modules, a b c: >> >> beams=(addsuffix .beam, a b c) >> %.beam: %.erl nasty_global_stuff.hrl >> erlc $< >> >> That causes 'make' to hand one module to erlc at a time, which is slow. >> >> >> Bad Idea #2: try and use just one rule for all .beams >> ----------- >> >> Like this: >> >> modules=a b c >> beams=$(addsuffix .beam, $(modules)) >> erls=$(addsuffix .erl, $(modules)) >> all: $(beams) >> >> $(beams): $(erls) nasty_global_stuff.hrl >> erlc $(filter %.erl, $@) >> >> That does almost the right thing, but actually not at all. Change one >> .erl and it'll recompile every .beam, because I've told 'make' that >> each .beam depends on all .erl files. >> >> >> Bad Idea #3: use erl -make for all Erlang compilations >> ----------- >> >> all: >> erl -make >> >> That sort-of works, but it only runs one process (Erlang's own 'make' >> doesn't seem to attempt running more than one compilation at a time), >> passing options is not straightforward (they're not even syntactically >> the same as for erlc) and it requires writing 'EMakefiles', so you >> sort-of have to understand Erlang in order to be able to fiddle with >> the build system. >> >> It's also fiddly explaining dependencies between Erlang stuff and >> other stuff to a combination of ordinary 'make' and erlang's own make. >> >> --end of bad ideas--- > > When removing rebar dependency in the Cowboy makefile to improve my workflow, I ran into the same issues you did. The normal way of doing things with make is too damn slow. I'm assuming here that each erlc call starts an Erlang VM, which isn't made to be fast. > > I settled for this: > https://github.com/extend/cowboy/blob/master/Makefile#L33 > > This recompiles everything all the time, but that's not really an issue for me. I might steal your bad idea #2 to avoid recompiling deps all the time though. > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From essen@REDACTED Thu Jan 24 15:56:00 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Thu, 24 Jan 2013 15:56:00 +0100 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <78E826B7-4C7B-4896-B9D0-5D061901F9D3@erlang-solutions.com> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <78E826B7-4C7B-4896-B9D0-5D061901F9D3@erlang-solutions.com> Message-ID: <51014B80.2060608@ninenines.eu> On 01/24/2013 01:39 PM, Jesper Louis Andersen wrote: > > > On Jan 24, 2013, at 3:37 AM, Lo?c Hoguin wrote: > >> Character.current_weapon.ability.points_req > > I think this is the major reason. It allows you to "chain" access to deep data. Note that this is a "projection" operation. You project out an element from the pair. The other solution, which is more Erlang-idiomatic is to match on the object and decode needed fields. But this solution is problematic when you need to access deep object data. > > What you really need is composition of lenses, and a neat syntax for doing so. That is a composable access language for obtaining data deep in structures. The usual chaining projection does *not* work in Erlang because you don't know the type of the object at compile time, unless you have the record name to help you. For that to work, you need frames, or something which works the same. > > On the other hand, when people access deep data like that, I often become concerned. Why is data not readily available to them but has to be dug up from far below the depths of a structure? Is this the right representation? There is overhead in following pointers and you can't always cache access over function boundaries. Are you suggesting that #character *duplicates* fields from both #weapon and #ability? Then you'd just end up with #character having hundreds of fields, which is as unmanageable and even less readable, especially if some share a common name, like #character.attack_pts and #weapon.attack_pts. Hierarchy helps clarity. "Character.current_weapon.ability.points_req" is the direct transcription of "Character's current weapon's special ability's required points". (Completely made up, but would apply to various games I know. Heck it'd be even worse for management games.) Not talking about pointers there, you don't need them for enabling all this. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From aschultz@REDACTED Thu Jan 24 15:58:26 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Thu, 24 Jan 2013 15:58:26 +0100 (CET) Subject: [erlang-questions] dialyzer from R16A (from git), problem to remove deleted beam file In-Reply-To: <169803397.431169.1359039160425.JavaMail.root@tpip.net> Message-ID: <1479480396.431264.1359039506704.JavaMail.root@tpip.net> Hi, I have a plt files generate with dialyzer from R16A(git). That plt file includes an app where one of the beam files has been remove later. Any attempt to update that plt file fails with: dialyzer: Not a regular file: /usr/src/erlang/app/ebin/removed.beam I tried --check_plt, --remove_from_plt and add_to_plt, all with the same result. Only after creating an empty file with the name, dialyzer managed to update the plt. Is that expected behavior? Andreas -- -- Dipl. Inform. Andreas Schultz email: as@REDACTED From essen@REDACTED Thu Jan 24 16:18:36 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 24 Jan 2013 16:18:36 +0100 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> Message-ID: <510150CC.90208@ninenines.eu> On 01/24/2013 03:16 PM, David Goehrig wrote: > On Jan 23, 2013, at 9:37 PM, Lo?c Hoguin wrote: > >> Character.current_weapon.ability.points_req >> >> Or >> >> Character.inventory[0].name > > Putting my game programmer hat back on, given a choice I would prefer: > > Character weapon ability cost > > Where each is an application of a method on the prior or in Erlangy speak: > > cost(ability(weapon(Character))) > > Where in each function destructs and returns an element of the nested structure. I might for sake of argument want to further name them: > > costOf(abilityOf(weaponOf(Character))) > > Now in a typical game, weaponOf vectors to the currently selected item from the inventory. AbilityOf vectors off of the currently selected special assigned to the B button / right click slot, and the cost is tied to the level of the character for scaling (if you assume a fixed sized mana pool). > > Usually each of these behaviors require implicit knowledge of other state, and would likely make extensive use of get/put in the Character's process dictionary to vector accordingly. > > This would imply these structures are best managed in an entirely different manner, where the Character process should memoize the values in a process dictionary, and the interrogation should happen only once upon an equip(Weapon) method. > > Same issue goes with inventory. We probably need a weapons manual process that can be interrogated for details based on names. These changes would make it more likely to be a bunch of message sends. To WeaponManual, Inventory, Character, etc. > > It would be difficult to justify the dot notation as it wouldn't even remotely resemble how one would structure the message sends. Process dictionary? Messages? I don't understand. Assume a variable Character. This variable contains everything about the character. How do you best access and modify Character? The answer must not involve the process dictionary, processes or message passing. Today I have to write each access and modification function. Or I can generate it, but either way I end up with hundreds of functions in many modules. Or I could use records, and have one line per sub-record per modification function I write. That's not *easy* nor *practical*. Easy and practical is: Character.weapon.ability.cost for access, and: Character.weapon.ability.cost = 123 for modification. Now I know this isn't the Erlang way, but I'm sure there can be a solution that allows to write something similar. Frames looked like a pretty good step in the right direction. Regardless of syntax, I'm sure we can have something like: Character2 = Character{weapon{ability{cost=123}}} Where it would be checked against the proper type, evaluated at runtime, and return a copy of Character with the requested modifications. This can work for access, "modification", and pattern match. The user would be aware that it has runtime costs, but will likely still choose this because it allows him to actually get the work done. There's many projects that I wouldn't even dream to do because of how tedious it would be, as I want to get my project running and not battle endlessly to modify my data. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From dmitriid@REDACTED Thu Jan 24 16:27:22 2013 From: dmitriid@REDACTED (Dmitrii Dimandt) Date: Thu, 24 Jan 2013 16:27:22 +0100 Subject: [erlang-questions] The reason for filename:join/1 behaviour? Message-ID: Hi all, What is the reason behind filename:join/1's behavior? From the docs: Joins a list of file name Components with directory separators. If one of the elements of Components includes an absolute path, for example "/xxx", the preceding elements, if any, are removed from the result. That is, > filename:join(["/usr", "/local"]). "/local" > filename:join(["/usr", "local"]). "/usr/local" Why? :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Thu Jan 24 16:50:12 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 24 Jan 2013 18:50:12 +0300 Subject: [erlang-questions] The reason for filename:join/1 behaviour? In-Reply-To: References: Message-ID: To make it easier to read your /etc/passwd: filename:join(DocRoot, clean_from_double_dot(UserPath)). On Thu, Jan 24, 2013 at 7:27 PM, Dmitrii Dimandt wrote: > Hi all, > > What is the reason behind filename:join/1's behavior? From the docs: > > Joins a list of file name Components with directory separators. If one of > the elements of Components includes an absolute path, for example "/xxx", > the preceding elements, if any, are removed from the result. > > That is, > > filename:join(["/usr", "/local"]). > "/local" > > filename:join(["/usr", "local"]). > "/usr/local" > > > Why? :) > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emmiller@REDACTED Thu Jan 24 17:13:41 2013 From: emmiller@REDACTED (Evan Miller) Date: Thu, 24 Jan 2013 10:13:41 -0600 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <510150CC.90208@ninenines.eu> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <510150CC.90208@ninenines.eu> Message-ID: On Thu, Jan 24, 2013 at 9:18 AM, Lo?c Hoguin wrote: > Now I know this isn't the Erlang way, but I'm sure there can be a solution > that allows to write something similar. Frames looked like a pretty good > step in the right direction. Regardless of syntax, I'm sure we can have > something like: > > Character2 = Character{weapon{ability{cost=123}}} > > Where it would be checked against the proper type, evaluated at runtime, and > return a copy of Character with the requested modifications. This can work > for access, "modification", and pattern match. The user would be aware that > it has runtime costs, but will likely still choose this because it allows > him to actually get the work done. There's many projects that I wouldn't > even dream to do because of how tedious it would be, as I want to get my > project running and not battle endlessly to modify my data. Is there any chance we could make the colon operator left-associative? That way children of Satan could waste precious CPU cycles writing things like Cost = Character:weapon():ability():cost() While laughing maniacally and dancing around a burning pyre of Prolog books > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Evan Miller http://www.evanmiller.org/ From mononcqc@REDACTED Thu Jan 24 17:36:06 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 24 Jan 2013 08:36:06 -0800 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <510150CC.90208@ninenines.eu> Message-ID: <20130124163604.GA28786@ferdmbp.local> On 01/24, Evan Miller wrote: > Is there any chance we could make the colon operator left-associative? > That way children of Satan could waste precious CPU cycles writing > things like > > Cost = Character:weapon():ability():cost() > > While laughing maniacally and dancing around a burning pyre of Prolog books I can't help myself thinking you're one of the most dedicated people working on making the square peg fit the seemingly round hole on this mailing list :) From robert.virding@REDACTED Thu Jan 24 18:12:12 2013 From: robert.virding@REDACTED (Robert Virding) Date: Thu, 24 Jan 2013 17:12:12 +0000 (GMT) Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: Message-ID: <892582522.3039391.1359047532333.JavaMail.root@erlang-solutions.com> ----- Original Message ----- > From: "Jos? Valim" > > I can understand 1), but what's the point of 2)? Wouldn't it be > > better for that to be in the erlang/otp repository instead so that > > everything can benefit from it? > > Loic, whenever it makes sense, I contribute patches back to OTP. :) > I would, for example, contribute our dict implementation, but I don't > believe OTP is looking for another dict implementation (I am going > to write a blog post with details and benchmarks soon for those > interested). If you have a better/faster implementation of dict with the same API then you should definitely contribute it. The original idea behind having multiple dict (and sets) libraries was to allow the user to choose the one that was best for their application. The internals of dict were deliberately unspecified to allow the implementation to change in the future. By having other versions of dict with different properties but the same API then users could choose. NO, I don't like having an option to new() to say which one you want as then you automatically limit the options, having different modules makes it easy to add new ones and to write your own! So hand it in and may the fastest win. > Some of the stuff in our stdlib, like providing zero-index based > access everywhere is hard to "backport" to Erlang. And other stuff > like the Enum module, which is a bunch of functions meant to work on > any enumerable data structure, like lists, dicts, etc, requires > protocols. What is it with zero-based indexes that make people so morbidly fascinated by them. If you are talking *offsets* then I agree that zero-based is fine, it's saying how far away something is from a some point. But here we are talking *indexes*, you know like first, second, third, etc. No indexes start at one! And don' go on about how C does it because C doesn't have arrays and indexes it has pointers and offsets, foo[3] is just syntactic sugar for *foo+3. And don't go on about how much easier it is to count from zero, I don't buy that, we can all add and subtract one without problems. Or at least I hope so. I think the OTP group made a bad decision *indexing* binaries from zero instead of one like the rest of erlang. It is both wrong and makes the system inconsistent. So to go on about this but there are some sensible things you can criticize Erlang for and indexing from one is not one of them. (And not really the syntax either, and this comes from the creator of LFE) Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From tamas@REDACTED Thu Jan 24 18:14:16 2013 From: tamas@REDACTED (=?iso-8859-1?Q?Szepes_Tam=E1s?=) Date: Thu, 24 Jan 2013 18:14:16 +0100 Subject: [erlang-questions] gen_fsm internal transition Message-ID: <003801cdfa56$3d9e2c00$b8da8400$@veriport.eu> All, What is the right way of doing an internal state transition in a gen_fsm? Is the following pattern safe to use? state_name(Event, From, State) -> . . . gen_fsm:send_event_after(0, internal_transition), {next_state, state_name1, State}. state_name1(internal_transition, From, State) -> . . . {reply, ok, state_name1, State}. Thanks, Tamas From essen@REDACTED Thu Jan 24 18:21:43 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 24 Jan 2013 18:21:43 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <892582522.3039391.1359047532333.JavaMail.root@erlang-solutions.com> References: <892582522.3039391.1359047532333.JavaMail.root@erlang-solutions.com> Message-ID: <51016DA7.2000503@ninenines.eu> On 01/24/2013 06:12 PM, Robert Virding wrote: > Some of the stuff in our stdlib, like providing zero-index based > access everywhere is hard to "backport" to Erlang. And other stuff > like the Enum module, which is a bunch of functions meant to work on > any enumerable data structure, like lists, dicts, etc, requires > protocols. > > > What is it with zero-based indexes that make people so morbidly > fascinated by them. If you are talking *offsets* then I agree that > zero-based is fine, it's saying how far away something is from a some > point. But here we are talking *indexes*, you know like first, second, > third, etc. No indexes start at one! And don' go on about how C does it > because C doesn't have arrays and indexes it has pointers and offsets, > foo[3] is just syntactic sugar for *foo+3. And don't go on about how > much easier it is to count from zero, I don't buy that, we can all add > and subtract one without problems. Or at least I hope so. There are only two hard problems in computer science: cache invalidation, naming things, and off by one errors. > I think the OTP group made a bad decision *indexing* binaries from zero > instead of one like the rest of erlang. It is both wrong and makes the > system inconsistent. But then you can write: << _:Pos/binary, C, _/binary >>. Alternative would be to -1/+1 all the time. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From max.lapshin@REDACTED Thu Jan 24 18:27:15 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 24 Jan 2013 20:27:15 +0300 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <20130124163604.GA28786@ferdmbp.local> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <510150CC.90208@ninenines.eu> <20130124163604.GA28786@ferdmbp.local> Message-ID: On Thu, Jan 24, 2013 at 8:36 PM, Fred Hebert wrote: > On 01/24, Evan Miller wrote: > > Cost = Character:weapon():ability():cost() > > > > While laughing maniacally and dancing around a burning pyre of Prolog > books > > I can't help myself thinking you're one of the most dedicated people > working on making the square peg fit the seemingly round hole on this > mailing list :) > Evan develops one of the most developed and most widely used ORM on Erlang, so you have to admit that he definitely has success in this complicated task. -------------- next part -------------- An HTML attachment was scrubbed... URL: From egil@REDACTED Thu Jan 24 18:31:27 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Thu, 24 Jan 2013 18:31:27 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <892582522.3039391.1359047532333.JavaMail.root@erlang-solutions.com> References: <892582522.3039391.1359047532333.JavaMail.root@erlang-solutions.com> Message-ID: <51016FEF.2050302@erlang.org> On 2013-01-24 18:12, Robert Virding wrote: > > > Some of the stuff in our stdlib, like providing zero-index based > access everywhere is hard to "backport" to Erlang. And other stuff > like the Enum module, which is a bunch of functions meant to work > on any enumerable data structure, like lists, dicts, etc, requires > protocols. > > > What is it with zero-based indexes that make people so morbidly > fascinated by them. If you are talking *offsets* then I agree that > zero-based is fine, it's saying how far away something is from a some > point. But here we are talking *indexes*, you know like first, second, > third, etc. No indexes start at one! And don' go on about how C does > it because C doesn't have arrays and indexes it has pointers and > offsets, foo[3] is just syntactic sugar for *foo+3. And don't go on > about how much easier it is to count from zero, I don't buy that, we > can all add and subtract one without problems. Or at least I hope so. > > I think the OTP group made a bad decision *indexing* binaries from > zero instead of one like the rest of erlang. It is both wrong and > makes the system inconsistent. I can see your point. I tend to think of indexing binaries as "indexing char arrays" and everything else as "indexing erlang terms". > > So to go on about this but there are some sensible things you can > criticize Erlang for and indexing from one is not one of them. (And > not really the syntax either, and this comes from the creator of LFE) IMHO: I think not having zero-based indexing in Erlang was a *big* mistake. I can see where it comes from, but still .. it's a pain knowing that I have to do +1/-1 to make certain algorithms function properly. Btw, when you say "the OTP group made a bad decision", exactly who are you referring too? Yourself? Isn't these decisions from CS-lab? Certainly way before my time =) // Bj?rn-Egil -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Thu Jan 24 18:41:35 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 24 Jan 2013 09:41:35 -0800 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <510150CC.90208@ninenines.eu> <20130124163604.GA28786@ferdmbp.local> Message-ID: <20130124174134.GA34845@ferdmbp.local> I'm not making a judgement call on any of it, whether it's worth it or not or something to aim for, at least not in that post. It just striked me as somewhat peculiar to ask to change the associativity of one of the most basic operators of a language to be able to get something that looks different/shorter to call functions around following countless arguments on the same topic in the last few days. I don't know why making calls chainable that way is *that* desirable, as I tend to prefer unambiguous (even if verbose) code to optimized code throughput on a per-character basis, but Evan Miller certainly desires it a whole damn lot. He's got to make that square peg fit real hard :) Regards, Fred On 01/24, Max Lapshin wrote: > On Thu, Jan 24, 2013 at 8:36 PM, Fred Hebert wrote: > > > On 01/24, Evan Miller wrote: > > > Cost = Character:weapon():ability():cost() > > > > > > While laughing maniacally and dancing around a burning pyre of Prolog > > books > > > > I can't help myself thinking you're one of the most dedicated people > > working on making the square peg fit the seemingly round hole on this > > mailing list :) > > > > > Evan develops one of the most developed and most widely used ORM on Erlang, > so you have to admit that he definitely has success in this complicated > task. From egil@REDACTED Thu Jan 24 18:47:18 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Thu, 24 Jan 2013 18:47:18 +0100 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <51016FEF.2050302@erlang.org> References: <892582522.3039391.1359047532333.JavaMail.root@erlang-solutions.com> <51016FEF.2050302@erlang.org> Message-ID: <510173A6.7030904@erlang.org> On 2013-01-24 18:31, Bj?rn-Egil Dahlberg wrote: > On 2013-01-24 18:12, Robert Virding wrote: >> I think the OTP group made a bad decision *indexing* binaries from >> zero instead of one like the rest of erlang. It is both wrong and >> makes the system inconsistent. > Btw, when you say "the OTP group made a bad decision", exactly who are > you referring too? Yourself? Isn't these decisions from CS-lab? > Certainly way before my time =) That probably sounds a bit more irritated than intended. I'm honestly curious, who decided indexing on terms and binaries and what was the reasoning behind it? I think I recall someone saying that binary-syntax was the last thing out from CS-Lab? // Bj?rn-Egil -------------- next part -------------- An HTML attachment was scrubbed... URL: From desired.mta@REDACTED Thu Jan 24 19:13:19 2013 From: desired.mta@REDACTED (=?UTF-8?Q?Motiejus_Jak=C5=A1tys?=) Date: Thu, 24 Jan 2013 18:13:19 +0000 Subject: [erlang-questions] cluster configuration, or dynamic (re)configuration of distributed application nodes Message-ID: Hi, we are about to investigate dynamic node reconfiguration of distributed applications. Did somebody do that already? How does kernel application react to application:set_env(kernel, ...)? Or is there a more elegant approach? We have a quite dynamic cluster of nodes, and we need one application running all the time. We have our own solution which is quite simple, but it *seems* like it should be better done in OTP way. Reason: we have a "cluster manager" application, which collects the cluster health status: started applications, requests per second, various tests, etc. This information is updated every second via many rpc calls to all the nodes. It would be possible to have the same application running on all the nodes, but then they all have the same information. Which is data duplication. Not too many messages, but why repeat ourselves? How do/would you approach this "cluster health" problem? -- Motiejus Jak?tys From rustompmody@REDACTED Thu Jan 24 19:23:10 2013 From: rustompmody@REDACTED (Rustom Mody) Date: Thu, 24 Jan 2013 23:53:10 +0530 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <51016DA7.2000503@ninenines.eu> References: <892582522.3039391.1359047532333.JavaMail.root@erlang-solutions.com> <51016DA7.2000503@ninenines.eu> Message-ID: On Thu, Jan 24, 2013 at 10:51 PM, Lo?c Hoguin wrote: > > What is it with zero-based indexes that make people so morbidly >> fascinated by them. If you are talking *offsets* then I agree that >> zero-based is fine, it's saying how far away something is from a some >> point. But here we are talking *indexes*, you know like first, second, >> third, etc. No indexes start at one! And don' go on about how C does it >> because C doesn't have arrays and indexes it has pointers and offsets, >> foo[3] is just syntactic sugar for *foo+3. And don't go on about how >> much easier it is to count from zero, I don't buy that, we can all add >> and subtract one without problems. Or at least I hope so. >> > > There are only two hard problems in computer science: cache invalidation, > naming things, and off by one errors. I can drive a car with European controls or one with American controls. And yet whenever I change over, I end up turning on the wiper when I want to turn on the turning lights. Its fine to make fun of people who fixate over 0/1 based indexing. Having both in the same language is really an invitation to chaos. We are seeing that in our project where the initial list based prototype is now being replaced by an array based one. How much time is spent on this debugging is left to the imagination! "Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration." -- Stan Kelly-Bootle -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob@REDACTED Thu Jan 24 19:51:44 2013 From: bob@REDACTED (Bob Ippolito) Date: Thu, 24 Jan 2013 10:51:44 -0800 Subject: [erlang-questions] Two questions: a. Recommended Application design b. Erlang memory maangement In-Reply-To: References: Message-ID: An alternative to manual garbage collecting is to do all of the parsing of this ephemeral data in a separate process that dies when it's no longer needed. This is probably the best solution, and you could even tune its min_heap_size when you spawn it such that no GC (or fewer GCs) will be necessary. Some other tuning options available are the spawn_opt (some of these can be set globally too) fullsweep_after, min_heap_size, and min_bin_vheap_size. http://www.erlang.org/doc/man/erlang.html Here's some other resources with good information about the GC with varying levels of detail: http://www.erlang.org/faq/academic.html#id55803 http://prog21.dadgum.com/16.html http://erlang.org/pipermail/erlang-questions/2011-September/061051.html http://erlang.org/pipermail/erlang-questions/2009-September/046744.html http://www.erlang-factory.com/upload/presentations/708/HitchhikersTouroftheBEAM.pdf -bob On Thu, Jan 24, 2013 at 6:38 AM, atul atri wrote: > Hi, > > I recently learned erlang to work on a chat application. I wrote a chat > gateway for ejabberd. Here is my application design. > > Every time a user logs into ejabberd, two processes(gen_server) are > created. These processes keep polling two different http addresses for new > messages and new chat events. These two processes are responsible for > getting/posting new chat events to/from a http server for each user. > Communication is done using *big* XMLs. And XMLs are parsed using same > parser used by ejabberd. Mnesia is used to store parsed XMLs. I used this > design because > 1. It is easy to implement polling using timeouts on message boxes. > 2. I learned that erlang loves processes. > > So here is my first question. Is this application design correct? Or will > you recommend any other design(like http request pool?)? > > So after creating this application, I load tested it. And here are some > results. When around 250 users are logged in to ejabberd , memory uses > reaches to 81% and CPU usages reaches to around 80%. I checked memory and > CPU usages using 'top' command. And if I increase 20-30 more users, > ejabberd crashes due to low memory. > > But when I use *erlang*:*garbage_collect*(self()) after parsing xml in > each process, Memory usages remains from 25% to 40% for same 250 users. > However CPU usages shoots above 90%. > > So, Here is my second question. Is it wise to use *erlang*:* > garbage_collect*(self())? I have not seen *garbage_collect* uses anywhere > else in any other application that I know. Also it would be great if some > one could throw some light on how erlang garbage collector works. Why does > not it recollect memory as soon as it is available to be recollected? > > Thanks & Regards, > Atul Atri. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew@REDACTED Thu Jan 24 20:05:40 2013 From: andrew@REDACTED (Andrew Thompson) Date: Thu, 24 Jan 2013 14:05:40 -0500 Subject: [erlang-questions] lager_trunc_io In-Reply-To: <52F8F721F8BC4C4E9C6E3027232CADE2@srstrong.com> References: <52F8F721F8BC4C4E9C6E3027232CADE2@srstrong.com> Message-ID: <20130124190540.GE12548@hijacked.us> Ok, I think what you're seeing is the bug around improper list printing. It is fixed in master, but not in 1.2.1. I'm guessing either the 'last message' or the state contains something like this: [[$a | {self(), left}]], which is causing the crash. Anyway, I've backported the fix (and one other tiny fix) from master to a new 1.2 branch (based off of the 1.2.1 tag) and tagged 1.2.2. Thanks for the report. Andrew From paul.joseph.davis@REDACTED Thu Jan 24 21:07:25 2013 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Thu, 24 Jan 2013 14:07:25 -0600 Subject: [erlang-questions] erlc speed (or lack thereof), Make and emake In-Reply-To: <49347419-26CF-47A3-B5E6-693065AB9335@gmail.com> References: <20130124124948.GA4801@corelatus.se> <510149CF.4020500@ninenines.eu> <49347419-26CF-47A3-B5E6-693065AB9335@gmail.com> Message-ID: I once wrote a custom erlc frontend for couchdb to see if I could speed up our compilation process. It made a bit of a difference but on a decent machine with -J the improvement wasn't enough to justify adding the complexity. Script is here: https://github.com/davisp/couchdb/blob/couch_erlc/bin/couch_erlc It was working well enough for me to run tests but I didn't spend much time testing it for general bugs and what not. On Thu, Jan 24, 2013 at 8:51 AM, Tim Watson wrote: > Take a look at the Rabbit Makefile - it doesn't recompile all the time > *and* it works with -J and is generally really fast. > > http://hg.rabbitmq.com/rabbitmq-server/file/default/ > > Cheers, > Tim > > On 24 Jan 2013, at 14:48, Lo?c Hoguin wrote: > > > On 01/24/2013 01:49 PM, Matthias Lang wrote: > >> Hi, > >> > >> I'm looking for tips and tricks to use speed up compiling a bunch of > >> Erlang modules from within a build system that uses (gnu)Make. > >> > >> The system uses Erlang, but most of it is actually C code, which is > compiled > >> under four different compilers, plus FPGA code. So ditching 'make' > >> for something Erlang-centric like 'rebar' doesn't look very attractive. > >> > >> Background > >> ---------- > >> > >> Doing this on R14B03: > >> > >> erlc a.erl > >> erlc b.erl > >> erlc c.erl > >> ... > >> > >> for 70 modules on my machine takes 39s. If I do this instead: > >> > >> erlc a.erl b.erl c.erl ... > >> > >> it improves to 7s. If I split the job in two parts which run at the > >> same time, it improves again to 4s wall time, with both cores > >> busy. > >> > >> So, a 10x improvement in compilation speed seems attainable, but how do > >> I explain how to do it to 'make'? > >> > >> > >> Ideas > >> ----- > >> > >> I had a few simple ideas for fixing this, but none really work. See > below. > >> > >> The more complicated idea I have is to make a shell script replacement > >> for 'erlc' which delegates the compilation work to an Erlang node > >> which is already running. Seems workable, and it won't spring > >> surprises on 'make', e.g. -j 4 will still do the right thing. > >> > >> Anyone got a neat idea? > >> > >> Rest of this mail is just a list of things that don't seem to work. > >> > >> Matt > >> > >> ====================================================================== > >> > >> > >> Bad Idea #1: straightforward 'make' > >> ----------- > >> > >> Here's my minimal starting point for a system of three modules, a b c: > >> > >> beams=(addsuffix .beam, a b c) > >> %.beam: %.erl nasty_global_stuff.hrl > >> erlc $< > >> > >> That causes 'make' to hand one module to erlc at a time, which is slow. > >> > >> > >> Bad Idea #2: try and use just one rule for all .beams > >> ----------- > >> > >> Like this: > >> > >> modules=a b c > >> beams=$(addsuffix .beam, $(modules)) > >> erls=$(addsuffix .erl, $(modules)) > >> all: $(beams) > >> > >> $(beams): $(erls) nasty_global_stuff.hrl > >> erlc $(filter %.erl, $@) > >> > >> That does almost the right thing, but actually not at all. Change one > >> .erl and it'll recompile every .beam, because I've told 'make' that > >> each .beam depends on all .erl files. > >> > >> > >> Bad Idea #3: use erl -make for all Erlang compilations > >> ----------- > >> > >> all: > >> erl -make > >> > >> That sort-of works, but it only runs one process (Erlang's own 'make' > >> doesn't seem to attempt running more than one compilation at a time), > >> passing options is not straightforward (they're not even syntactically > >> the same as for erlc) and it requires writing 'EMakefiles', so you > >> sort-of have to understand Erlang in order to be able to fiddle with > >> the build system. > >> > >> It's also fiddly explaining dependencies between Erlang stuff and > >> other stuff to a combination of ordinary 'make' and erlang's own make. > >> > >> --end of bad ideas--- > > > > When removing rebar dependency in the Cowboy makefile to improve my > workflow, I ran into the same issues you did. The normal way of doing > things with make is too damn slow. I'm assuming here that each erlc call > starts an Erlang VM, which isn't made to be fast. > > > > I settled for this: > > https://github.com/extend/cowboy/blob/master/Makefile#L33 > > > > This recompiles everything all the time, but that's not really an issue > for me. I might steal your bad idea #2 to avoid recompiling deps all the > time though. > > > > -- > > Lo?c Hoguin > > Erlang Cowboy > > Nine Nines > > 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 ulf@REDACTED Thu Jan 24 21:24:20 2013 From: ulf@REDACTED (Ulf Wiger) Date: Thu, 24 Jan 2013 21:24:20 +0100 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> Message-ID: On 24 Jan 2013, at 10:12, Olav Frengstad wrote: > {Get,Set} = compose([#char.cur_weapon, #weapon.ability, #ability.points_req]), > Character2 = S(123, Character), > 123 = G(Character2). > > Jesper Louis Andersen wrote a simple Erlang implementation which can > be found here: https://github.com/jlouis/erl-lenses I noticed this was posted on the list quite a while ago, but I missed it then. I have added lens support in exprecs, with reference in the docs to Jesper's erl-lenses project: Eshell V5.9.2 (abort with ^G) 1> test_exprecs:'#lens-'(a,r). {#Fun, #Fun} 2> {G,S} = v(1). {#Fun, #Fun} 3> R = test_exprecs:'#new-r'(). {r,0,0,0} 4> G(S(17,R)). 17 5> S(17,R). {r,17,0,0} Pushed to http://github.com:uwiger/parse_trans.git BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From hd2010@REDACTED Thu Jan 24 21:33:45 2013 From: hd2010@REDACTED (Henning Diedrich) Date: Thu, 24 Jan 2013 21:33:45 +0100 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <20130124174134.GA34845@ferdmbp.local> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <510150CC.90208@ninenines.eu> <20130124163604.GA28786@ferdmbp.local> <20130124174134.GA34845@ferdmbp.local> Message-ID: <338CD367-ADA8-4437-9025-9FEA04845103@eonblast.com> It wasn't originally about chainability, was it. I'd support that one won't usually have deep chains, except when trying things, scripting, also in games. It would indicate something is off. So the chaining is one thing, but that verbosity, I think it is played down too nonchalantly. It does make programming harder. It would be a serious win to overcome that. I can only suspect that one doesn't see it that much anymore once you are fully used to it but I am positive it would benefit everybody. Best, Henning On Jan 24, 2013, at 6:41 PM, Fred Hebert wrote: > I'm not making a judgement call on any of it, whether it's worth it or > not or something to aim for, at least not in that post. > > It just striked me as somewhat peculiar to ask to change the > associativity of one of the most basic operators of a language to be > able to get something that looks different/shorter to call functions > around following countless arguments on the same topic in the last few > days. > > I don't know why making calls chainable that way is *that* desirable, as > I tend to prefer unambiguous (even if verbose) code to optimized code > throughput on a per-character basis, but Evan Miller certainly desires > it a whole damn lot. He's got to make that square peg fit real hard :) > > Regards, > Fred > > On 01/24, Max Lapshin wrote: >> On Thu, Jan 24, 2013 at 8:36 PM, Fred Hebert wrote: >> >>> On 01/24, Evan Miller wrote: >>>> Cost = Character:weapon():ability():cost() >>>> >>>> While laughing maniacally and dancing around a burning pyre of Prolog >>> books >>> >>> I can't help myself thinking you're one of the most dedicated people >>> working on making the square peg fit the seemingly round hole on this >>> mailing list :) >>> >> >> >> Evan develops one of the most developed and most widely used ORM on Erlang, >> so you have to admit that he definitely has success in this complicated >> task. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From dirker@REDACTED Thu Jan 24 21:48:24 2013 From: dirker@REDACTED (=?ISO-8859-1?Q?Dirk_H=F6rner?=) Date: Thu, 24 Jan 2013 21:48:24 +0100 Subject: [erlang-questions] installing to --prefix, but running symlinked somewhere else In-Reply-To: <20130123215651.GA74381@ferdmbp.local> References: <20130123215651.GA74381@ferdmbp.local> Message-ID: Hi Fred, thanks for your reply. I thought about ERL_LIBS, too, but what about port drivers/bindings you may want to install globally for every one to use. Is that something which is generally not recommended? Should every OTP app bring their own dependencies? Ciao, Dirk On Wed, Jan 23, 2013 at 10:56 PM, Fred Hebert wrote: > I assume that by apps you mean OTP apps you end up installing on your > system. There's an ENV variable called ERL_LIBS that can point to one or > more directories that contains OTP app directories, and that Erlang can > look for when booting up. > > Dump your apps in there, and either export ERL_LIBS=/your/directory, or > run it as $ erl -env ERL_LIBS=/your/directory (works cross-platform) to > get your Erlang copy to look wherever. By default it'll pick the newest > apps. > > This is an especially nice feature because it lets you have many > different sets of installed applications to work with on a per-release > or per-project basis. > > I hope this helps, > Fred. > > On 01/23, Dirk H?rner wrote: > > Hi all, > > > > I am using erlang on Mac OS X and am using homebrew (a package manager, > > https://github.com/mxcl/homebrew) to keep my erlang installation > > up-to-date. Now homebrew installs all packages into its own directory and > > then symlinks the files into the right spot, like this: > > > > Installed to (--prefix): /usr/local/Cellar/erlang/R15B03 > > Symlinked to and run in: /usr/local > > > > With the default erlang build options, this makes erlang look for its app > > under /usr/local/Cellar/erlang/R15B03/lib/erlang/lib. However third party > > apps install into /usr/local/lib/erlang/lib, and erlang cannot find them > > there. > > > > Currently I am fixing this by crudely changing $ROOTDIR in > > .../lib/erlang/bin/erl and .../lib/erlang/bin/start, but I am wondering > if > > there is a better way to do this? And if there is not, is my hack causing > > any side effects I am not seeing yet? > > > > Thanks, > > Dirk > > > _______________________________________________ > > 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 Jan 24 22:23:31 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Thu, 24 Jan 2013 22:23:31 +0100 Subject: [erlang-questions] Cowboy feedback needed Message-ID: <5101A653.400@ninenines.eu> Hey, I'm looking into perhaps starting a project related to Cowboy and could use some feedback from users, particularly in the realm of numbers. If you use Cowboy and have it in production where: * Latency is vital * Throughput is vital * Concurrent number of connections is huge * Load is huge (or would be with another solution) Then I'd like to hear from you! Please send me average numbers, statistics, graphs or anything where I can see how well it performs for you! In private if you prefer. Tell me if I can quote you or your company about it. Please answer even if we briefly discussed it in the past. (If you found that it didn't perform enough for your needs you should probably open a ticket, or, if you can't, send me a private email.) Looking forward to the feedback. Thanks! -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From fritchie@REDACTED Thu Jan 24 22:26:09 2013 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Thu, 24 Jan 2013 15:26:09 -0600 Subject: [erlang-questions] Unixtime in Erlang In-Reply-To: Message of "Thu\, 24 Jan 2013 14\:20\:15 GMT." Message-ID: <23813.1359062769@snookles.snookles.com> Motiejus Jak?tys wrote: mj> os:timestamp() is a slightly faster version of erlang:now(). Slight correction: it's quite a bit faster than erlang:now(), if you're executing in a heavily loaded VM on an multi-core machine. IIRC (untested code): now_as_time_t() -> {A, B, _} = os:timestamp(), (A * 1000000) + B. -Scott From mononcqc@REDACTED Thu Jan 24 22:41:01 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 24 Jan 2013 13:41:01 -0800 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <338CD367-ADA8-4437-9025-9FEA04845103@eonblast.com> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <510150CC.90208@ninenines.eu> <20130124163604.GA28786@ferdmbp.local> <20130124174134.GA34845@ferdmbp.local> <338CD367-ADA8-4437-9025-9FEA04845103@eonblast.com> Message-ID: <20130124214100.GB34845@ferdmbp.local> It's a definite possibility. I still work in Erlang with no tools at all past vim and tmux to get a shell right next to it, and tend not to mind verbosity *if* it makes maintenance and readability simpler, less ambiguous. I've always considered myself to be a rather slow programmer, and I don't especially care about how fast I am at writing code nearly as much as how fast code can be written so I understand it *correctly* in as short a time as possible. That's why I can be in favour of trying to get terse code or compact representations (pattern matching is the best thing for this), but I tend to dislike things like overloading existing constructs, which then force me to understand more and more of the context that surrounds a bit of code to know what it does. Sometimes the terseness of code ends up being a pure trade off between speed of writing and speed of understanding (complex regular expressions compared to writing a little one-off parser can be a good example of this debate). Given I'm not having a personal problem understanding most Erlang code that respects OTP principles, and that understandability comes before most other factors to me (and I care about my own opinion very much!), I tend to take ideas such as overloading well-defined semantics for the sake of terseness as a long term threat to a lot of the things that make Erlang great to me right now. I think a lot of people make the implicit choice of pushing more code faster, thinking "oh it's not gonna be around in 15 years". I think this gives an unfair advantage to features that improve productivity before maintainability (when the objectives clash). It's a decision I frequently make. I sometimes think I should force myself to take the egotistical position that I know better and don't want to deal with all the experimental one-off prototypes that ended up being pushed in production by eager middle-managers as what I want to end up maintaining in the future. It's a very hand-wavy position, and I realize there's no moral high ground, that projects are different and that various developers have different priorities, capacities to understand an memorize. I just feel maintainability should be seen as more important than it is seen in general -- after all, roughly 30% of the programmer time spent in a project is for development, 70% of the time spent is in maintenance. Of that 70%, between 50% to 90% of it is spent trying to figure out what the hell the code is doing (that's 20% to 60% of the whole project's life!) With these numbers, it seems insane to optimize for fast writing instead of fast understanding. Regards, Fred. P.S. That got long and rant-y way faster than I expected! Sorry! On 01/24, Henning Diedrich wrote: > It wasn't originally about chainability, was it. > > I'd support that one won't usually have deep chains, except when trying things, scripting, also in games. It would indicate something is off. > > So the chaining is one thing, but that verbosity, I think it is played down too nonchalantly. It does make programming harder. It would be a serious win to overcome that. I can only suspect that one doesn't see it that much anymore once you are fully used to it but I am positive it would benefit everybody. > > Best, > Henning > > > On Jan 24, 2013, at 6:41 PM, Fred Hebert wrote: > > > I'm not making a judgement call on any of it, whether it's worth it or > > not or something to aim for, at least not in that post. > > > > It just striked me as somewhat peculiar to ask to change the > > associativity of one of the most basic operators of a language to be > > able to get something that looks different/shorter to call functions > > around following countless arguments on the same topic in the last few > > days. > > > > I don't know why making calls chainable that way is *that* desirable, as > > I tend to prefer unambiguous (even if verbose) code to optimized code > > throughput on a per-character basis, but Evan Miller certainly desires > > it a whole damn lot. He's got to make that square peg fit real hard :) > > > > Regards, > > Fred > > > > On 01/24, Max Lapshin wrote: > >> On Thu, Jan 24, 2013 at 8:36 PM, Fred Hebert wrote: > >> > >>> On 01/24, Evan Miller wrote: > >>>> Cost = Character:weapon():ability():cost() > >>>> > >>>> While laughing maniacally and dancing around a burning pyre of Prolog > >>> books > >>> > >>> I can't help myself thinking you're one of the most dedicated people > >>> working on making the square peg fit the seemingly round hole on this > >>> mailing list :) > >>> > >> > >> > >> Evan develops one of the most developed and most widely used ORM on Erlang, > >> so you have to admit that he definitely has success in this complicated > >> task. > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > From fritchie@REDACTED Thu Jan 24 22:42:03 2013 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Thu, 24 Jan 2013 15:42:03 -0600 Subject: [erlang-questions] Receive with priority [yet again] In-Reply-To: Message of "Thu\, 24 Jan 2013 15\:49\:03 +0100." Message-ID: <25040.1359063723@snookles.snookles.com> ?lvaro wrote: am> This function will be called periodically and I need to know if this am> implementation will always go through all the message in the mailbox am> (i.e. it will try to match Pattern1 to the messages at the beginning am> of the mailbox over and over again). ?lvaro, compile your module using "erlc -S", then look at the BEAM assembly for your function ... if the operators 'recv_mark' and 'recv_set' appear (where the argument for recv_set is the same as the argument for recv_mark), then the function will not scan all messages in the mailbox. If you do not see them, then a full mailbox scan will be done. -Scott From nem@REDACTED Thu Jan 24 22:43:41 2013 From: nem@REDACTED (Geoff Cant) Date: Thu, 24 Jan 2013 13:43:41 -0800 Subject: [erlang-questions] installing to --prefix, but running symlinked somewhere else In-Reply-To: References: <20130123215651.GA74381@ferdmbp.local> Message-ID: <21B556A0-C5AE-49D6-9595-848BB68F0BF8@erlang.geek.nz> I think the general consensus for deploying erlang systems these days is to bring all your dependencies with your system. Don't share libraries amongst different systems/releases running on the same machine. Sharing is maybe convenient for stdlib and development environments, but nigh on impossible to live with in production. Other languages have already moved in this direction - bundler in ruby and virtualenv in python both spring to mind. System-wide libraries seem on the way out. Cheers, -- Geoff Cant On 2013-01-24, at 12:48 , Dirk H?rner wrote: > Hi Fred, > > thanks for your reply. I thought about ERL_LIBS, too, but what about port > drivers/bindings you may want to install globally for every one to use. Is > that something which is generally not recommended? Should every OTP app > bring their own dependencies? > > Ciao, > Dirk > > > On Wed, Jan 23, 2013 at 10:56 PM, Fred Hebert wrote: > >> I assume that by apps you mean OTP apps you end up installing on your >> system. There's an ENV variable called ERL_LIBS that can point to one or >> more directories that contains OTP app directories, and that Erlang can >> look for when booting up. >> >> Dump your apps in there, and either export ERL_LIBS=/your/directory, or >> run it as $ erl -env ERL_LIBS=/your/directory (works cross-platform) to >> get your Erlang copy to look wherever. By default it'll pick the newest >> apps. >> >> This is an especially nice feature because it lets you have many >> different sets of installed applications to work with on a per-release >> or per-project basis. >> >> I hope this helps, >> Fred. >> >> On 01/23, Dirk H?rner wrote: >>> Hi all, >>> >>> I am using erlang on Mac OS X and am using homebrew (a package manager, >>> https://github.com/mxcl/homebrew) to keep my erlang installation >>> up-to-date. Now homebrew installs all packages into its own directory and >>> then symlinks the files into the right spot, like this: >>> >>> Installed to (--prefix): /usr/local/Cellar/erlang/R15B03 >>> Symlinked to and run in: /usr/local >>> >>> With the default erlang build options, this makes erlang look for its app >>> under /usr/local/Cellar/erlang/R15B03/lib/erlang/lib. However third party >>> apps install into /usr/local/lib/erlang/lib, and erlang cannot find them >>> there. >>> >>> Currently I am fixing this by crudely changing $ROOTDIR in >>> .../lib/erlang/bin/erl and .../lib/erlang/bin/start, but I am wondering >> if >>> there is a better way to do this? And if there is not, is my hack causing >>> any side effects I am not seeing yet? >>> >>> Thanks, >>> Dirk >> >>> _______________________________________________ >>> erlang-questions mailing list >>> 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 matthias@REDACTED Thu Jan 24 23:04:20 2013 From: matthias@REDACTED (Matthias Lang) Date: Thu, 24 Jan 2013 23:04:20 +0100 Subject: [erlang-questions] erlc speed (or lack thereof), Make and emake In-Reply-To: <49347419-26CF-47A3-B5E6-693065AB9335@gmail.com> References: <20130124124948.GA4801@corelatus.se> <510149CF.4020500@ninenines.eu> <49347419-26CF-47A3-B5E6-693065AB9335@gmail.com> Message-ID: <20130124220420.GB3657@corelatus.se> On Thursday, January 24, Tim Watson wrote: > Take a look at the Rabbit Makefile - it doesn't recompile all the > time *and* it works with -J and is generally really fast. That Makefile is nice and tidy, but it's compiling the .erl files in the simplest---and slowest---way possible. It calls 'erlc' about 370 times, i.e. once per file. I.e. exactly as per "Bad Idea #1" in my OP. Quick measurements on building 3.0.1 from source: plain 'make': 220s wall time 'make -j 2': 112s I wanted to get an idea of how much of a speedup was possible, so I broke out all the calls to 'erlc' from the build process and put them in a shell script. There are about 370. Running the script so it does one call to 'erlc' at a time takes 183s. Changing the script so that each call to 'erlc' compiles many files drops the time to 40s. Further changing the script to use multiple (unix) processes gets me to 26s. That's pretty encouraging. It suggests that a 3x or 4x speedup is possible for the Erlang part of the Rabbit build process. Matt From dmkolesnikov@REDACTED Thu Jan 24 23:28:23 2013 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Fri, 25 Jan 2013 00:28:23 +0200 Subject: [erlang-questions] erlc speed (or lack thereof), Make and emake In-Reply-To: <20130124220420.GB3657@corelatus.se> References: <20130124124948.GA4801@corelatus.se> <510149CF.4020500@ninenines.eu> <49347419-26CF-47A3-B5E6-693065AB9335@gmail.com> <20130124220420.GB3657@corelatus.se> Message-ID: <866C50A6-F8BD-4019-B7DA-EDB78FCE4987@gmail.com> Hello, I had a following construction in Makefiles %.beam : %.erl $(AM_V_ERL)$(ERLC) $(ERL_CFLAGS) -I ./include -b beam \$< define rules_ERLAPP $(1)_BEAM=$(subst .in,,$(addprefix ebin/, $(notdir $($(1)_SRC:.erl=.beam)))) nobase_pkgliberl_SCRIPTS += $$($(1)_BEAM) ... endef It build only touched file? there was no issue with slow compile. But I've swapped to rebar just to stream line my workflow and still no issues :-) - Dmitry On Jan 25, 2013, at 12:04 AM, Matthias Lang wrote: > On Thursday, January 24, Tim Watson wrote: > >> Take a look at the Rabbit Makefile - it doesn't recompile all the >> time *and* it works with -J and is generally really fast. > > That Makefile is nice and tidy, but it's compiling the .erl files in > the simplest---and slowest---way possible. It calls 'erlc' about 370 > times, i.e. once per file. I.e. exactly as per "Bad Idea #1" in my OP. > > Quick measurements on building 3.0.1 from source: > > plain 'make': 220s wall time > 'make -j 2': 112s > > I wanted to get an idea of how much of a speedup was possible, so I > broke out all the calls to 'erlc' from the build process and put > them in a shell script. There are about 370. > > Running the script so it does one call to 'erlc' at a time takes 183s. > > Changing the script so that each call to 'erlc' compiles many files > drops the time to 40s. > > Further changing the script to use multiple (unix) processes gets me to 26s. > > That's pretty encouraging. It suggests that a 3x or 4x speedup is > possible for the Erlang part of the Rabbit build process. > > Matt > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From dmkolesnikov@REDACTED Thu Jan 24 23:38:04 2013 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Fri, 25 Jan 2013 00:38:04 +0200 Subject: [erlang-questions] gen_fsm internal transition In-Reply-To: <003801cdfa56$3d9e2c00$b8da8400$@veriport.eu> References: <003801cdfa56$3d9e2c00$b8da8400$@veriport.eu> Message-ID: <61AED908-07A8-4083-B752-3ECA70A5E0F6@gmail.com> Hello, In practice, this is a safe way to handle internal transition. In theory, internal FSM transitions should be avoided. I would make it like this state_name0(Event, From, State) -> my_action_1( my_action_0(State) ); state_name1(Event, From State) -> my_action1(State); ? my_action_0(State) -> % here goes code from you state_name my_action_1(State) -> % here goes code from your state_name1 - Dmitry On Jan 24, 2013, at 7:14 PM, Szepes Tam?s wrote: > All, > > What is the right way of doing an internal state transition in a gen_fsm? > > Is the following pattern safe to use? > > state_name(Event, From, State) -> > . > . > . > gen_fsm:send_event_after(0, internal_transition), > {next_state, state_name1, State}. > > state_name1(internal_transition, From, State) -> > . > . > . > {reply, ok, state_name1, State}. > > Thanks, > Tamas > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From emmiller@REDACTED Thu Jan 24 23:57:01 2013 From: emmiller@REDACTED (Evan Miller) Date: Thu, 24 Jan 2013 16:57:01 -0600 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <20130124214100.GB34845@ferdmbp.local> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <510150CC.90208@ninenines.eu> <20130124163604.GA28786@ferdmbp.local> <20130124174134.GA34845@ferdmbp.local> <338CD367-ADA8-4437-9025-9FEA04845103@eonblast.com> <20130124214100.GB34845@ferdmbp.local> Message-ID: On Thu, Jan 24, 2013 at 3:41 PM, Fred Hebert wrote: > I just feel maintainability should be seen as more important than it > is seen in general -- after all, roughly 30% of the programmer time spent > in a project is for development, 70% of the time spent is in maintenance. > Of that 70%, between 50% to 90% of it is spent trying to figure out what > the hell the code is doing (that's 20% to 60% of the whole project's > life!) > > With these numbers, it seems insane to optimize for fast writing instead > of fast understanding. "These numbers" are not physical constants. They depend solely on your market and on your development strategy. Other people's numbers will be quite different, and in many contexts, optimizing for fast writing can be quite sane. There's an apocryphal story of Andrew Carnegie visiting a British steel manufacturer. The manufacturer boasted that with proper care and maintenance, some of his furnaces had been in service for decades. "And that," Carnegie replied, "is why the United States is making you a back number. You're using still furnaces that ought to have been scrapped twenty years ago." I bring this up to point out that there are two approaches to maintenance. One can build something that is high-quality and lasts for a long time with proper ongoing investment (what I'll call the "British" approach), or one can build on the cheap and when it breaks, crank out a replacement (what I'll call the "American" approach). It's tempting to think that the British approach is more "long-term", and there is a strong tendency among engineers to equate build quality with moral virtue, but there is significant a long-term economic advantage to the American approach: if you're constantly building from scratch, you end up taking advantage of technological advances that are more difficult for your "British" counterparts to incorporate into their older designs. DeTocqueville has a similar analysis of the American versus British shipping industries in the early 1800s. Americans treated ships as expendable, the British didn't, and the Americans ended up dominating the industry. The average ship in an American merchant fleet was worse in terms of quality, but it was newer in terms of design, so it tended to reach its destination more quickly. (Of course, it was more likely to be shipwrecked along the way, and hence American seamen were better-paid than their British counterparts; but the additional wages were easily furnished by the market's thirst for fast trans-Atlantic shipping.) I think there are lessons here for software. Even if *technology* itself doesn't change (and it does), *markets* change swiftly, and it can be necessary to build new versions of products rapidly (call it "iterating" or "pivoting" or whatever you want). Engineers tend to care deeply about quality-of-build and maintainability, but in some sectors it is much more practical to be constantly building and rebuilding "crap" in short time frames. I think this insight largely explains the popularity of Ruby on Rails. It might seem insane, but it's really just economics. Evan From eriksoe@REDACTED Fri Jan 25 00:07:46 2013 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Fri, 25 Jan 2013 00:07:46 +0100 Subject: [erlang-questions] erlc speed (or lack thereof), Make and emake In-Reply-To: <20130124124948.GA4801@corelatus.se> References: <20130124124948.GA4801@corelatus.se> Message-ID: One possibility is to let the shell figure out which files need to be recompiled, and invoke erlc on that batch. Figuring out what needs recompilation could possibly be done by calling make in dry-run mode, to see what it thinks needs to be done, and then processing that output - or, as below, in a more direct manner. I don't know if all the features necessary to do this are 100% portable, but sticking with (gmake +) bash, this works: # Iterating through the source files, determine which need recompilation. # Then - if any do - invoke the compiler on the batch. fast-compile: files=""; for i in src/*.erl ; do j=$${i%.erl}.beam; j=ebin/$${j#src/} ; [ "$$j" -nt "$$i" ] || files="$$files $$i" ; done ; \ [ -z "$$files" ] || erlc -o ebin $$files /Erik 2013/1/24 Matthias Lang > Hi, > > I'm looking for tips and tricks to use speed up compiling a bunch of > Erlang modules from within a build system that uses (gnu)Make. > > The system uses Erlang, but most of it is actually C code, which is > compiled > under four different compilers, plus FPGA code. So ditching 'make' > for something Erlang-centric like 'rebar' doesn't look very attractive. > > Background > ---------- > > Doing this on R14B03: > > erlc a.erl > erlc b.erl > erlc c.erl > ... > > for 70 modules on my machine takes 39s. If I do this instead: > > erlc a.erl b.erl c.erl ... > > it improves to 7s. If I split the job in two parts which run at the > same time, it improves again to 4s wall time, with both cores > busy. > > So, a 10x improvement in compilation speed seems attainable, but how do > I explain how to do it to 'make'? > > > Ideas > ----- > > I had a few simple ideas for fixing this, but none really work. See below. > > The more complicated idea I have is to make a shell script replacement > for 'erlc' which delegates the compilation work to an Erlang node > which is already running. Seems workable, and it won't spring > surprises on 'make', e.g. -j 4 will still do the right thing. > > Anyone got a neat idea? > > Rest of this mail is just a list of things that don't seem to work. > > Matt > > ====================================================================== > > > Bad Idea #1: straightforward 'make' > ----------- > > Here's my minimal starting point for a system of three modules, a b c: > > beams=(addsuffix .beam, a b c) > %.beam: %.erl nasty_global_stuff.hrl > erlc $< > > That causes 'make' to hand one module to erlc at a time, which is slow. > > > Bad Idea #2: try and use just one rule for all .beams > ----------- > > Like this: > > modules=a b c > beams=$(addsuffix .beam, $(modules)) > erls=$(addsuffix .erl, $(modules)) > all: $(beams) > > $(beams): $(erls) nasty_global_stuff.hrl > erlc $(filter %.erl, $@) > > That does almost the right thing, but actually not at all. Change one > .erl and it'll recompile every .beam, because I've told 'make' that > each .beam depends on all .erl files. > > > Bad Idea #3: use erl -make for all Erlang compilations > ----------- > > all: > erl -make > > That sort-of works, but it only runs one process (Erlang's own 'make' > doesn't seem to attempt running more than one compilation at a time), > passing options is not straightforward (they're not even syntactically > the same as for erlc) and it requires writing 'EMakefiles', so you > sort-of have to understand Erlang in order to be able to fiddle with > the build system. > > It's also fiddly explaining dependencies between Erlang stuff and > other stuff to a combination of ordinary 'make' and erlang's own make. > > --end of bad ideas--- > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ngocdaothanh@REDACTED Fri Jan 25 00:08:22 2013 From: ngocdaothanh@REDACTED (Ngoc Dao) Date: Fri, 25 Jan 2013 08:08:22 +0900 Subject: [erlang-questions] cluster configuration, or dynamic (re)configuration of distributed application nodes In-Reply-To: References: Message-ID: I guess Mnesia has been originally designed for this purpose? On Fri, Jan 25, 2013 at 3:13 AM, Motiejus Jak?tys wrote: > Hi, > > we are about to investigate dynamic node reconfiguration of > distributed applications. Did somebody do that already? How does > kernel application react to application:set_env(kernel, ...)? Or is > there a more elegant approach? We have a quite dynamic cluster of > nodes, and we need one application running all the time. We have our > own solution which is quite simple, but it *seems* like it should be > better done in OTP way. > > Reason: we have a "cluster manager" application, which collects the > cluster health status: started applications, requests per second, > various tests, etc. This information is updated every second via many > rpc calls to all the nodes. > > It would be possible to have the same application running on all the > nodes, but then they all have the same information. Which is data > duplication. Not too many messages, but why repeat ourselves? > > How do/would you approach this "cluster health" problem? > > -- > Motiejus Jak?tys > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ok@REDACTED Fri Jan 25 01:31:25 2013 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 25 Jan 2013 13:31:25 +1300 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <51009E7B.5090902@ninenines.eu> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> Message-ID: <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> On 24/01/2013, at 3:37 PM, Lo?c Hoguin wrote: > But I think their point is that Person.name does not require extra keystrokes to get the value, as opposed to Person#person.name or person:name(Person). I thought the complaint was that Person#person.name is not polymorphic; my point was that name(Person) _can_ be polymorphic, if you seriously want it to be. > > They're incorrect when claiming it makes things harder, it's just a lot more tedious, especially if you have a lot of different values to manipulate. A simple example would be an RPG video game character, which has various kinds of state, a name, a class, stats, equipped items, inventory, unlocks, friends, quickchat, options and more. Erlang makes programming this kind of thing a nightmare, and all that simply because you can't do something like: > > Character.current_weapon.ability.points_req > > Or > > Character.inventory[0].name Don't OO programming courses teach "The Law Of Demeter" (http://en.wikipedia.org/wiki/Law_of_Demeter) any more? (It's also known as 'don't talk to strangers': send messages to yourself, your instance variables, and the parameters and local variables of the current method.) This particular example is actually a good illustration of what can go wrong: "ability" is not a property, it is a property relating a character to a category of weapons. If one character drops a weapon and another picks it up, the second player should not acquire the first player's ability. So it should be something like (player abilityWith: (player currentWeaponCategory)) and then points are required to do something, so it _really_ should be something like (player pointsRequiredTo: #fightOrcs using: player currentWeaponCategory) and note that it's player currentWeaponCategory not player currentWeapon category because the player might not _have_ a currentWeapon. > > Or at least, not without a lot more keystrokes. If you're worried about keystrokes, it's DSL time. > And let's not even speak about actually modifying these values or adding an item to the inventory. In a language as horrible as PHP, adding an item to the inventory can be written as: > > Character->inventory[] = Item; That is *precisely* one of the things that makes it a truly horrible language. "Don't let strangers touch your private parts." An object such as a character *must* remain in charge of what happens to its components (such as an inventory) because otherwise you are not doing OO programming, you are just hacking around in the dark. The OO way to add an item to a character's inventory is to *ask the character to do it*, so the right way to do that is character addToInventory: item If you let things like Character->inventory[] = Item happen, you _also_ let random bits of code reorder your inventory, delete things from your inventory, and add things from your inventory to another player's inventory without withdrawing them from yours. If Erlang turns people away because it doesn't let people write code like that, then it's turning away people I am desperately keen to see NOT touching any code that can affect my life. Just now there is a seriously broken piece of software affecting many lives in New Zealand. It's called Novopay (Google it!) and it is the payroll system for all school-teachers and support staff in this country. It's overpaying some people, underpaying more, and not paying others at all. The last time I looked at their admitted defects web site, one of their forms had refused to accept the entry of apostrophes in people's names. Well, nobody expects a large system to work correctly first time; that's why you roll it out gradually (except the government didn't choose to do that) and why you keep the old system on hot standby so you can roll back to something that (now, after long effort) works quickly when it turns out that people aren't getting paid (except the Government chose not to do that either and say it is now impossible to go back). I hereby make two retrodictions: (a) The designers did not try to follow the Law of Demeter. (I will give NZ$20 to a local school if I am wrong.) (b) The critical aspects of the code (dealing with a lot of different kinds of contracts) were not developed using an embedded domain specific language. (Again I will give NZ$20 to a local school if I am wrong.) > You of course have to know what [] means, but it makes the code incredibly easier to read. I'm not at all sure that I believe it at all. What you are talking about is ease of writing *low level* code. Not "small scale". "Low level". The kind of stuff you DON'T want to make easy to read, but next to invisible. In fact, the kind of stuff you don't want to write at all, because if you didn't write it, you didn't wrong it. One of several enlightening experiences I've had was being in the same room with a real Haskell expert who was finding some code starting to get messy. He thought for a couple of minutes, and said "I'll just define a combinator for that." Shortly afterwards, his code was markedly smaller and a lot closer to doing what he wanted. He wasn't making the low level data structure manipulation easier to read, he was making it NOT THERE in the source code. I've read Apple's Key-Value Coding manual, and as I remarked earlier this week, I've implemented something close to it in my Smalltalk system. However, there's one "feature" I chose _not_ to imitate: if you try to use a selector, and there is no method by that name, but there _is_ an instance variable, KVC will give you direct access to that variable. You can switch that off, on a per-class basis, but it's on by default. What this means is that _unless_ you have been careful to switch that feature off in every class you have, using KVC voids *every* guarantee your classes want to offer. Let's face it, trying to follow the Law of Demeter is hard. It means taking encapsulation and system integrity _seriously_. It means that when something is awkward to say, you DON'T just smash-and-grab, you redesign. It means that you try to provide conceptual-level interfaces. > Erlang lacks all these easy data manipulation facilities. I am not sure this can be fully resolved. > > Of course, perhaps one could use some Lua behind Erlang to do the game logic, but that's not really a good selling point for people to use Erlang, it's at best a compromise. That's completely back to front. You don't want *more* low-level code in your program, you want *less*. You devise a DSL in which the things you need to say about the game logic are easy to say and many of the mistakes you want to avoid cannot be expressed and where the data structure manipulation is just plain NOT THERE in the source code. It's in the translation of the source code. And it doesn't matter whether the low level code is going to be in Erlang or Ada or Lua or F#. You *still* want to write your game logic at the highest level of abstraction you are comfortable with hiding as much data structure manipulation as you can. Now, a DSL can be an embedded DSL, in which you have the facilities of the host language as well as the DSL ones. The DSL might even be a module or two just providing some handy functions. Basically, that's the Smalltalk/ Law of Demeter approach. character addToInventory: item is domain-specific code. It talks about characters, and items, and inventories, and says NOTHING about the data structures representing them. The inventory could be an SQLite table. It could be a concurrent process. It could be a hash table. And this is where it gets really nice: if you turn your game into a MPORPG where game state is replicated and changes have to be broadcast, your code that works at this level does not need to be changed. However, while the EDSL approach makes it _possible_ for your game logic to be written at a high level, it need not _prevent_ low level details (alias future bugs) creeping into that logic. And the checks the compiler can do are still almost exclusively the checks the compiler knows how to do for the host language. A free-standing DSL lets you provide *concept-level* consistency checks, which is a thing well worth having. Sorry about the rant, but for reasons I'll spare you I didn't get any sleep last night and I am just so _tired_ of people wanting to write code they should be running away from. From mononcqc@REDACTED Fri Jan 25 01:42:13 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 24 Jan 2013 16:42:13 -0800 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <51009E7B.5090902@ninenines.eu> <510150CC.90208@ninenines.eu> <20130124163604.GA28786@ferdmbp.local> <20130124174134.GA34845@ferdmbp.local> <338CD367-ADA8-4437-9025-9FEA04845103@eonblast.com> <20130124214100.GB34845@ferdmbp.local> Message-ID: <20130125004212.GA77322@ferdmbp.local> There is a difference between maintaining to a functional level and maintaining in order to keep it current with demands and needs. The usefulness of a program through time comes from its ability to answer customer demands and needs -- these needs evolve and change as the application is being used and has an impact on its environment. It doesn't live in a vacuum. The thing is, as you force a program to evolve, you add to its entropy and it keeps getting higher until it's no longer managable, unless it's taken care of. That includes bugfixes, but also all the improvement you could write a new app for. It is not always economically viable to throw it all out and start from scratch, the same way itsn't always economically viable to maintain piles of garbage. Properly maintainable apps are more like factories where if you haven't welded your furnaces to the support beams, you'll be able to replace them without taking the whole damn structure down or even stopping production at all. Sometimes the models will change so much you'll have no choice but to build a new complex to host them. Doesn't mean all furnace upgrades or changes warrant a new building. The problem with code is that there is often no up-to-date documentation, no owner for the code, it's full of hidden features, or bugs accepted as features, work-arounds that are implicit but not documented or specified anywhere, and so on. To be able to replace any of this code with anything else and have something at least functionally equivalent, you have to be able to reverse engineer it. The decision to throw shit out is economical by nature, but a large part of the price is how much of a brainfuck it will be to do the desired updates. When the code is impossible to understand, or that understanding it takes too long, then it makes sense to throw it all away. It's often more economical to figure things out as you go without needing to care for old interfaces that have non-obvious uses slowing you down. It's also more fun too! If you can understand the app easily, see the patterns in it, how to refactor it, and get a good understanding of its structure, it should be possible to throw away all the old legacy code, and get to write 100% new code in an otherwise old application. And it would be obtained at a good cost, because answering that user's need was doable efficiently without them needing to pay for the full reimplementation as part of the deal. What I want to aim for, generally speaking, is the case where code is understandable enough that it never makes sense to throw all of it away. Just the outdated parts of it, one at a time, as needs grow. I've discussed of points related to that before, on former discussions we had with parametrized modules, models, and the structure of web frameworks. I don't think we need to end up agreeing in any case. I get your point and you hopefully get mine -- we just choose a different angle of attack in how we'd do things, I think. I can't have the audacity to assert my way is the best way; at most, it's the one I prefer. Regards, Fred. On 01/24, Evan Miller wrote: > On Thu, Jan 24, 2013 at 3:41 PM, Fred Hebert wrote: > > I just feel maintainability should be seen as more important than it > > is seen in general -- after all, roughly 30% of the programmer time spent > > in a project is for development, 70% of the time spent is in maintenance. > > Of that 70%, between 50% to 90% of it is spent trying to figure out what > > the hell the code is doing (that's 20% to 60% of the whole project's > > life!) > > > > With these numbers, it seems insane to optimize for fast writing instead > > of fast understanding. > > "These numbers" are not physical constants. They depend solely on your > market and on your development strategy. Other people's numbers will > be quite different, and in many contexts, optimizing for fast writing > can be quite sane. > > There's an apocryphal story of Andrew Carnegie visiting a British > steel manufacturer. The manufacturer boasted that with proper care and > maintenance, some of his furnaces had been in service for decades. > > "And that," Carnegie replied, "is why the United States is making you > a back number. You're using still furnaces that ought to have been > scrapped twenty years ago." > > I bring this up to point out that there are two approaches to > maintenance. One can build something that is high-quality and lasts > for a long time with proper ongoing investment (what I'll call the > "British" approach), or one can build on the cheap and when it breaks, > crank out a replacement (what I'll call the "American" approach). > > It's tempting to think that the British approach is more "long-term", > and there is a strong tendency among engineers to equate build quality > with moral virtue, but there is significant a long-term economic > advantage to the American approach: if you're constantly building from > scratch, you end up taking advantage of technological advances that > are more difficult for your "British" counterparts to incorporate into > their older designs. > > DeTocqueville has a similar analysis of the American versus British > shipping industries in the early 1800s. Americans treated ships as > expendable, the British didn't, and the Americans ended up dominating > the industry. The average ship in an American merchant fleet was worse > in terms of quality, but it was newer in terms of design, so it tended > to reach its destination more quickly. (Of course, it was more likely > to be shipwrecked along the way, and hence American seamen were > better-paid than their British counterparts; but the additional wages > were easily furnished by the market's thirst for fast trans-Atlantic > shipping.) > > I think there are lessons here for software. Even if *technology* > itself doesn't change (and it does), *markets* change swiftly, and it > can be necessary to build new versions of products rapidly (call it > "iterating" or "pivoting" or whatever you want). Engineers tend to > care deeply about quality-of-build and maintainability, but in some > sectors it is much more practical to be constantly building and > rebuilding "crap" in short time frames. I think this insight largely > explains the popularity of Ruby on Rails. It might seem insane, but > it's really just economics. > > Evan From bo.zhang86@REDACTED Fri Jan 25 02:28:21 2013 From: bo.zhang86@REDACTED (Bob) Date: Fri, 25 Jan 2013 09:28:21 +0800 Subject: [erlang-questions] Does the latest erlang release have implement "native process" ? Message-ID: <772D888C4B7B4D9B9CAEAFFF1E3A743D@gmail.com> Hi, Does the latest erlang release have implement "native process" ? Cheers, --- Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From fritchie@REDACTED Fri Jan 25 02:29:37 2013 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Thu, 24 Jan 2013 19:29:37 -0600 Subject: [erlang-questions] erlc speed (or lack thereof), Make and emake In-Reply-To: Message of "Thu, 24 Jan 2013 23:04:20 +0100." <20130124220420.GB3657@corelatus.se> Message-ID: <41758.1359077377@snookles.snookles.com> Matthias Lang wrote: ml> Running the script so it does one call to 'erlc' at a time takes ml> 183s. Hrm, well, running on a random OpenSolaris virtual machine that I've got lying around at the moment.... % time erl -eval "init:stop(0)." Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:2:2] [async-threads:0] [kernel-poll:false] [dtrace] Eshell V5.9.1 (abort with ^G) 1> 0.12u 0.05s 0:01.29 13.1% So, almost 1.3 seconds to start up and stop. Some of that time is probably related to shutting down. The rest is probably startup time. Some fraction of that is probably the same overhead that starting "erlc" from scratch each time, plus some overhead that "erlc" has that "erl" doesn't. Reduce that sum of time, and you'll save a lot of time in your Makefile recipes. Plus, that reduction would likely make "escript" startup times lower, which would also please a lot of the Erlang world also? -Scott P.S. Keeping mouth shut since rebar's automatic parallellization doesn't seem to interest everyone else in the thread.... :-) From vinoski@REDACTED Fri Jan 25 02:31:22 2013 From: vinoski@REDACTED (Steve Vinoski) Date: Thu, 24 Jan 2013 20:31:22 -0500 Subject: [erlang-questions] Does the latest erlang release have implement "native process" ? In-Reply-To: <772D888C4B7B4D9B9CAEAFFF1E3A743D@gmail.com> References: <772D888C4B7B4D9B9CAEAFFF1E3A743D@gmail.com> Message-ID: On Thu, Jan 24, 2013 at 8:28 PM, Bob wrote: > Hi, > Does the latest erlang release have implement "native process" ? > No. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Fri Jan 25 02:59:20 2013 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 25 Jan 2013 14:59:20 +1300 Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <51016DA7.2000503@ninenines.eu> References: <892582522.3039391.1359047532333.JavaMail.root@erlang-solutions.com> <51016DA7.2000503@ninenines.eu> Message-ID: <058F5946-3749-462D-AB52-49CC78362C95@cs.otago.ac.nz> > On 01/24/2013 06:12 PM, Robert Virding wrote: >> >> What is it with zero-based indexes that make people so morbidly >> fascinated by them. Dijkstra has explained this at some length in one of his papers. As for me, I find that working with half-open [Start,End) intervals in arrays substantially reduces the rate at which I make off-by-one errors. I've built a Smalltalk system, complete with 1-origin indexing everywhere. The one thing that saves me from errors is the Smalltalk practice of using higher-order whole-collection operations that don't mention indices at all. When I designed the string processing library in Quintus Prolog, I chose to avoid indices everywhere that I possibly could and to specify the substring B in ABC as substring(Whole, Part, LenA, LenB, LenC) where Prolog could of course solve for any of LenA, LenB, LenC. So I could say "4 characters 3 before the end" _,4,3 or "everything but the first 2 and last 5" 2,_,5 or "skip 7 and take 9" 7,9,_ or even let the predicate find things by searching. It was clearly documented that all these and similar arguments were *lengths* of substrings. And I got complaints about using 0-origin indexing, when none of these arguments was an index! From wallentin.dahlberg@REDACTED Fri Jan 25 03:05:57 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Fri, 25 Jan 2013 03:05:57 +0100 Subject: [erlang-questions] erlc speed (or lack thereof), Make and emake In-Reply-To: <41758.1359077377@snookles.snookles.com> References: <20130124220420.GB3657@corelatus.se> <41758.1359077377@snookles.snookles.com> Message-ID: 2013/1/25 Scott Lystig Fritchie > So, almost 1.3 seconds to start up and stop. Some of that time is > probably related to shutting down. The rest is probably startup time. > Some fraction of that is probably the same overhead that starting "erlc" > from scratch each time, plus some overhead that "erlc" has that "erl" > doesn't. Reduce that sum of time, and you'll save a lot of time in your > Makefile recipes. Plus, that reduction would likely make "escript" > startup times lower, which would also please a lot of the Erlang world > also? > Though we now have parallel code loading, we don't have parallel code fetching during boot. I think most of it is dynamic on-demand fetching in a sequential process anyways. I think something like spec:ing what modules should be loaded in default boot or app-file is the way to go. Start app -> batch parallel modules loading. We want something reasonable thought through. =) > P.S. Keeping mouth shut since rebar's automatic parallellization doesn't > seem to interest everyone else in the thread.... :-) > rebar is awesome! I wonder why some people seem to shy away from it? I don't know if it is feasible to use rebar to build erlang applications within otp. I don't think so. It would be nice to have something like that and Emake needs a lot more attention if it would have the same role. We don't want to make yet another make-tool. it's just silly, we have rebar. I think if we ever manage to move out applications from otp, that we still maintain, those should use rebar to build them. (I'm a big proponent of splitting down the monolithic otp-repo, let's say its not really prioritized). Within the otp-repo we will use make + erlc for the foreseeable future. On another note, if rebar is the build-tool, what application is the concrete? A repository search and deploy engine? // Bj?rn-Egil -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Jan 25 03:08:36 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Fri, 25 Jan 2013 03:08:36 +0100 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> Message-ID: <5101E924.5030507@ninenines.eu> On 01/25/2013 01:31 AM, Richard O'Keefe wrote: > > On 24/01/2013, at 3:37 PM, Lo?c Hoguin wrote: >> But I think their point is that Person.name does not require extra keystrokes to get the value, as opposed to Person#person.name or person:name(Person). > > I thought the complaint was that Person#person.name is not polymorphic; > my point was that name(Person) _can_ be polymorphic, if you seriously > want it to be. It's about ease of use, reducing the extra steps (or plane flight in the case of Erlang) to get the work done. >> They're incorrect when claiming it makes things harder, it's just a lot more tedious, especially if you have a lot of different values to manipulate. A simple example would be an RPG video game character, which has various kinds of state, a name, a class, stats, equipped items, inventory, unlocks, friends, quickchat, options and more. Erlang makes programming this kind of thing a nightmare, and all that simply because you can't do something like: >> >> Character.current_weapon.ability.points_req >> >> Or >> >> Character.inventory[0].name > > Don't OO programming courses teach "The Law Of Demeter" > (http://en.wikipedia.org/wiki/Law_of_Demeter) any more? > (It's also known as 'don't talk to strangers': send > messages to yourself, your instance variables, and the > parameters and local variables of the current method.) > > This particular example is actually a good illustration > of what can go wrong: "ability" is not a property, > it is a property relating a character to a category of > weapons. If one character drops a weapon and another > picks it up, the second player should not acquire the > first player's ability. So it should be something > like > (player abilityWith: (player currentWeaponCategory)) > and then points are required to do something, so it _really_ > should be something like > (player pointsRequiredTo: #fightOrcs > using: player currentWeaponCategory) > and note that it's > player currentWeaponCategory > not player currentWeapon category > because the player might not _have_ a currentWeapon. You should play more games. Some recent games (actually probably games from these past 20 years or more, though it's been quite refined) feature weapons that can be upgraded. They also feature weapons that have abilities. Not the character, the weapon itself. For example a shotgun could have a spread damage ability that you can unlock if you spend enough points. You can probably guess that giving another character this weapon would be pretty lame if the weapon's upgrades didn't stick. Especially in the context of online games where selling items is fairly common. >> Or at least, not without a lot more keystrokes. > > If you're worried about keystrokes, it's DSL time. Sure. Then Erlang needs that DSL. >> And let's not even speak about actually modifying these values or adding an item to the inventory. In a language as horrible as PHP, adding an item to the inventory can be written as: >> >> Character->inventory[] = Item; > > That is *precisely* one of the things that makes it a truly horrible > language. "Don't let strangers touch your private parts." An object > such as a character *must* remain in charge of what happens to its > components (such as an inventory) because otherwise you are not doing > OO programming, you are just hacking around in the dark. The OO way > to add an item to a character's inventory is to *ask the character to > do it*, so the right way to do that is > > character addToInventory: item Let me stop you right there. Nobody said anything could change Character. In Erlang it would quite naturally belong to a gen_server and you'd make calls like {add_item, Item} and let the gen_server handle it. You'd of course program the gen_server to handle any needed logic (like inventory full). The problem is that in Erlang, if I were to use records for example, I would have to take the inventory from the #character record, add the item in it, and then put it back in the #character record. This sounds bearable, you'll probably say. Now imagine if the character could have one or more sidekick avatars (like, say, a dog and a cat), and you want to add the item to your first sidekick's inventory. This is PHP: Character->avatars[0]->inventory[] = Item; In Erlang, I'd have to update two records and two lists, which would take quite many lines. Erlang should allow us to focus on the game logic, not on trying to avoid mistakes while updating data structures. > If you let things like Character->inventory[] = Item happen, you > _also_ let random bits of code reorder your inventory, delete > things from your inventory, and add things from your inventory > to another player's inventory without withdrawing them from > yours. Irrelevant as explained above. This doesn't prevent transactional behavior, you just have to wrap it in a gen_server *like everything else*. >> You of course have to know what [] means, but it makes the code incredibly easier to read. > > I'm not at all sure that I believe it at all. > > What you are talking about is ease of writing *low level* code. > Not "small scale". "Low level". The kind of stuff you DON'T want > to make easy to read, but next to invisible. In fact, the kind of > stuff you don't want to write at all, because if you didn't write > it, you didn't wrong it. To reuse your terms, right now, in Erlang, you don't have low level. You have basement level. You have to change every single element in a hierarchy one by one and then build it back together. OR generate code to do that (and hope that code doesn't have bugs). OR write all that logic in Lua and reduce the size of the code and the potential number of bugs in it by 3. > One of several enlightening experiences I've had was being in the same > room with a real Haskell expert who was finding some code starting > to get messy. He thought for a couple of minutes, and said > > "I'll just define a combinator for that." > > Shortly afterwards, his code was markedly smaller and a lot closer > to doing what he wanted. He wasn't making the low level data > structure manipulation easier to read, he was making it NOT THERE > in the source code. Of course it was there. He had to define the combinator. [snip more irrelevant demeter stuff] >> Erlang lacks all these easy data manipulation facilities. I am not sure this can be fully resolved. >> >> Of course, perhaps one could use some Lua behind Erlang to do the game logic, but that's not really a good selling point for people to use Erlang, it's at best a compromise. > > That's completely back to front. > > You don't want *more* low-level code in your program, > you want *less*. You devise a DSL in which the things > you need to say about the game logic are easy to say and > many of the mistakes you want to avoid cannot be > expressed and where the data structure manipulation is > just plain NOT THERE in the source code. It's in the > translation of the source code. Of course I want less low-level code in my program. That's why I want to be able to update data structures in one line instead of five. > And it doesn't matter whether the low level code is going > to be in Erlang or Ada or Lua or F#. You *still* want to > write your game logic at the highest level of abstraction > you are comfortable with hiding as much data structure > manipulation as you can. > > Now, a DSL can be an embedded DSL, in which you have the > facilities of the host language as well as the DSL ones. > The DSL might even be a module or two just providing > some handy functions. Basically, that's the Smalltalk/ > Law of Demeter approach. > character addToInventory: item > is domain-specific code. It talks about characters, and > items, and inventories, and says NOTHING about the data > structures representing them. The inventory could be an > SQLite table. It could be a concurrent process. It > could be a hash table. And this is where it gets really > nice: if you turn your game into a MPORPG where game > state is replicated and changes have to be broadcast, > your code that works at this level does not need to be > changed. > > However, while the EDSL approach makes it _possible_ for > your game logic to be written at a high level, it need > not _prevent_ low level details (alias future bugs) > creeping into that logic. And the checks the compiler > can do are still almost exclusively the checks the > compiler knows how to do for the host language. > > A free-standing DSL lets you provide *concept-level* > consistency checks, which is a thing well worth having. Sure. And who has to write the code for addToInventory? Someone does. It'd typically check you have space left in your inventory, and if the item is stackable and you already have a stack of them in it, increment by 1 the stack, otherwise add the item. And to add the item I need to update one and more record and one and more list, which takes quite a few lines. Who writes this? Because that's the part that's problematic in Erlang. Not putting things behind a gen_server or a module or a DSL. > Sorry about the rant, but for reasons I'll spare you I > didn't get any sleep last night and I am just so _tired_ > of people wanting to write code they should be running > away from. I think you should go take a nap. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From norton@REDACTED Fri Jan 25 03:18:58 2013 From: norton@REDACTED (=?utf-8?B?44OO44O844OI44OzIOOCuOODp+ODvOOCu+ODlSDjgqbjgqfjgqQg?= =?utf-8?B?44Oz?=) Date: Fri, 25 Jan 2013 11:18:58 +0900 Subject: [erlang-questions] erlc speed (or lack thereof), Make and emake In-Reply-To: References: <20130124220420.GB3657@corelatus.se> <41758.1359077377@snookles.snookles.com> Message-ID: Bjorn - Why do you think it isn't feasible to use rebar to build erlang applications within OTP? Just curious. thanks, Joe N. p.s. I have been toying with this idea on GitHub. https://github.com/organizations/otphub I haven't spent any significant time on this exercise ? just out of curiosity. On Jan 25, 2013, at 11:05 , Bj?rn-Egil Dahlberg wrote: > 2013/1/25 Scott Lystig Fritchie > > So, almost 1.3 seconds to start up and stop. Some of that time is > probably related to shutting down. The rest is probably startup time. > Some fraction of that is probably the same overhead that starting "erlc" > from scratch each time, plus some overhead that "erlc" has that "erl" > doesn't. Reduce that sum of time, and you'll save a lot of time in your > Makefile recipes. Plus, that reduction would likely make "escript" > startup times lower, which would also please a lot of the Erlang world > also? > > Though we now have parallel code loading, we don't have parallel code fetching during boot. I think most of it is dynamic on-demand fetching in a sequential process anyways. > > I think something like spec:ing what modules should be loaded in default boot or app-file is the way to go. Start app -> batch parallel modules loading. We want something reasonable thought through. =) > > > P.S. Keeping mouth shut since rebar's automatic parallellization doesn't > seem to interest everyone else in the thread.... :-) > > rebar is awesome! > > I wonder why some people seem to shy away from it? > > I don't know if it is feasible to use rebar to build erlang applications within otp. I don't think so. It would be nice to have something like that and Emake needs a lot more attention if it would have the same role. We don't want to make yet another make-tool. it's just silly, we have rebar. > > I think if we ever manage to move out applications from otp, that we still maintain, those should use rebar to build them. (I'm a big proponent of splitting down the monolithic otp-repo, let's say its not really prioritized). Within the otp-repo we will use make + erlc for the foreseeable future. > > On another note, > if rebar is the build-tool, what application is the concrete? A repository search and deploy engine? > > // Bj?rn-Egil > _______________________________________________ > 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 Jan 25 03:28:19 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Fri, 25 Jan 2013 03:28:19 +0100 Subject: [erlang-questions] erlc speed (or lack thereof), Make and emake In-Reply-To: References: <20130124220420.GB3657@corelatus.se> <41758.1359077377@snookles.snookles.com> Message-ID: <5101EDC3.6070105@ninenines.eu> On topic: Anthony Ramine gave me a tip on how to build only modified erl files using make's functionality directly, I'll try it out tomorrow and report back. Off topic: On 01/25/2013 03:05 AM, Bj?rn-Egil Dahlberg wrote: > P.S. Keeping mouth shut since rebar's automatic parallellization doesn't > seem to interest everyone else in the thread.... :-) > > > rebar is awesome! > > I wonder why some people seem to shy away from it? My reasons in short: * Slow (especially for running tests) * Annoying (it does recursion by default; and might do recursion in some cases but not in others later, which is as bad) * Inconvenient (it does funny things to its ct stuff which makes it much slower and less practical than ct_run, and I run tests all the time) * Unstable (options change at regular intervals) I actually removed it initially to improve my development life (where I do a lot of dialyzing and running tests), then decided to stop using it entirely. I use Makefiles anyway, and rebar's functionality is replicated in just a dozen more lines compared to the original Makefile. I still support rebar for people who use my projects, I think it's the best current solution to get started using Erlang quickly, I just don't use it for my own development needs. As for releases, relcool[1] sounds damn sexy, I have been advising them a little on how to handle release upgrades, and will be using it starting next week. [1] https://github.com/erlware/relcool -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From wallentin.dahlberg@REDACTED Fri Jan 25 03:49:23 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Fri, 25 Jan 2013 03:49:23 +0100 Subject: [erlang-questions] erlc speed (or lack thereof), Make and emake In-Reply-To: References: <20130124220420.GB3657@corelatus.se> <41758.1359077377@snookles.snookles.com> Message-ID: 2013/1/25 ???? ????? ??? ? > > Bjorn - > > Why do you think it isn't feasible to use rebar to build erlang > applications within OTP? > Well, rebar would be a key-component to build otp. That means that rebar probably have to be included in the repo as an application. Not impossible, but I don't know if it would be ideal. What I would like, and I don't know if anybody shares this thought: OTP split down to just a core, namely runtime system, kernel, stdlib, compiler, sasl perhaps a few other applications. External dependency to rebar. Perhaps rebar could be included in that core. >From a technical standpoint, there is ofc no problem. But it would be nice to solve it in another manner. I don't really know if this is true or not, but I get the feeling when I use rebar that I loose some strictness and it adds some magic. A lack of sense of control. Just the paranoia speaking perhaps. =) Build the rest of OTP with rebar, pulled down via git or some other means. Applications are nowadays normally oriented in separate git repositories. Seems natural to use this scheme for OTP applications as well. It has some additional advantages: * Promotes modularity. * Can have separate release cycles. * Developers can choose different versions for there system, not merely the system version R16*, R15*, R14*, etc .. I can see many advantages. I'm pretty sure there are disadvantages too. Cross application updates that otherwise needs strict version-control can be done with one commit in a single repo. Thats pretty neat. but I digress, to answer your question. I don't think there is a technical problem, but perhaps an administration problem. I would like to see rebar thrive outside OTP. We won't go into this any further right now though. // Bj?rn-Egil > > Just curious. > > thanks, > > Joe N. > > > p.s. I have been toying with this idea on GitHub. > > https://github.com/organizations/otphub > > I haven't spent any significant time on this exercise ? just out of > curiosity. > > > > > On Jan 25, 2013, at 11:05 , Bj?rn-Egil Dahlberg < > wallentin.dahlberg@REDACTED> wrote: > > 2013/1/25 Scott Lystig Fritchie > > >> So, almost 1.3 seconds to start up and stop. Some of that time is >> probably related to shutting down. The rest is probably startup time. >> Some fraction of that is probably the same overhead that starting "erlc" >> from scratch each time, plus some overhead that "erlc" has that "erl" >> doesn't. Reduce that sum of time, and you'll save a lot of time in your >> Makefile recipes. Plus, that reduction would likely make "escript" >> startup times lower, which would also please a lot of the Erlang world >> also? >> > > Though we now have parallel code loading, we don't have parallel code > fetching during boot. I think most of it is dynamic on-demand fetching in a > sequential process anyways. > > I think something like spec:ing what modules should be loaded in default > boot or app-file is the way to go. Start app -> batch parallel modules > loading. We want something reasonable thought through. =) > > > >> P.S. Keeping mouth shut since rebar's automatic parallellization doesn't >> seem to interest everyone else in the thread.... :-) >> > > rebar is awesome! > > I wonder why some people seem to shy away from it? > > I don't know if it is feasible to use rebar to build erlang applications > within otp. I don't think so. It would be nice to have something like that > and Emake needs a lot more attention if it would have the same role. We > don't want to make yet another make-tool. it's just silly, we have rebar. > > I think if we ever manage to move out applications from otp, that we still > maintain, those should use rebar to build them. (I'm a big proponent of > splitting down the monolithic otp-repo, let's say its not really > prioritized). Within the otp-repo we will use make + erlc for the > foreseeable future. > > On another note, > if rebar is the build-tool, what application is the concrete? A repository > search and deploy engine? > > // Bj?rn-Egil > _______________________________________________ > 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 Jan 25 04:02:28 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Fri, 25 Jan 2013 04:02:28 +0100 Subject: [erlang-questions] erlc speed (or lack thereof), Make and emake In-Reply-To: References: <20130124220420.GB3657@corelatus.se> <41758.1359077377@snookles.snookles.com> Message-ID: 2013/1/25 Bj?rn-Egil Dahlberg > > > 2013/1/25 ???? ????? ??? ? > >> >> Bjorn - >> >> Why do you think it isn't feasible to use rebar to build erlang >> applications within OTP? >> > > Let me just preface everything below by saying that: I speak for myself and not for OTP as a whole when I say this. Some may agree with some might not. Anyways, these are my views. > > Well, rebar would be a key-component to build otp. That means that rebar > probably have to be included in the repo as an application. > Not impossible, but I don't know if it would be ideal. > > What I would like, and I don't know if anybody shares this thought: > > OTP split down to just a core, namely runtime system, kernel, stdlib, > compiler, sasl perhaps a few other applications. > > External dependency to rebar. Perhaps rebar could be included in that > core. From a technical standpoint, there is ofc no problem. But it would be > nice to solve it in another manner. > > I don't really know if this is true or not, but I get the feeling when I > use rebar that I loose some strictness and it adds some magic. A lack of > sense of control. Just the paranoia speaking perhaps. =) > > Build the rest of OTP with rebar, pulled down via git or some other means. > > Applications are nowadays normally oriented in separate git repositories. > Seems natural to use this scheme for OTP applications as well. > It has some additional advantages: > * Promotes modularity. > * Can have separate release cycles. > * Developers can choose different versions for there system, not merely > the system version R16*, R15*, R14*, etc .. > > I can see many advantages. > > I'm pretty sure there are disadvantages too. Cross application updates > that otherwise needs strict version-control can be done with one commit in > a single repo. Thats pretty neat. > > but I digress, to answer your question. I don't think there is a technical > problem, but perhaps an administration problem. I would like to see rebar > thrive outside OTP. > > We won't go into this any further right now though. > > // Bj?rn-Egil > > > > >> >> Just curious. >> >> thanks, >> >> Joe N. >> >> >> p.s. I have been toying with this idea on GitHub. >> >> https://github.com/organizations/otphub >> >> I haven't spent any significant time on this exercise ? just out of >> curiosity. >> >> >> >> >> On Jan 25, 2013, at 11:05 , Bj?rn-Egil Dahlberg < >> wallentin.dahlberg@REDACTED> wrote: >> >> 2013/1/25 Scott Lystig Fritchie >> >> >>> So, almost 1.3 seconds to start up and stop. Some of that time is >>> probably related to shutting down. The rest is probably startup time. >>> Some fraction of that is probably the same overhead that starting "erlc" >>> from scratch each time, plus some overhead that "erlc" has that "erl" >>> doesn't. Reduce that sum of time, and you'll save a lot of time in your >>> Makefile recipes. Plus, that reduction would likely make "escript" >>> startup times lower, which would also please a lot of the Erlang world >>> also? >>> >> >> Though we now have parallel code loading, we don't have parallel code >> fetching during boot. I think most of it is dynamic on-demand fetching in a >> sequential process anyways. >> >> I think something like spec:ing what modules should be loaded in default >> boot or app-file is the way to go. Start app -> batch parallel modules >> loading. We want something reasonable thought through. =) >> >> >> >>> P.S. Keeping mouth shut since rebar's automatic parallellization doesn't >>> seem to interest everyone else in the thread.... :-) >>> >> >> rebar is awesome! >> >> I wonder why some people seem to shy away from it? >> >> I don't know if it is feasible to use rebar to build erlang applications >> within otp. I don't think so. It would be nice to have something like that >> and Emake needs a lot more attention if it would have the same role. We >> don't want to make yet another make-tool. it's just silly, we have rebar. >> >> I think if we ever manage to move out applications from otp, that we >> still maintain, those should use rebar to build them. (I'm a big proponent >> of splitting down the monolithic otp-repo, let's say its not really >> prioritized). Within the otp-repo we will use make + erlc for the >> foreseeable future. >> >> On another note, >> if rebar is the build-tool, what application is the concrete? A >> repository search and deploy engine? >> >> // Bj?rn-Egil >> _______________________________________________ >> 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 Fri Jan 25 04:09:36 2013 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 25 Jan 2013 16:09:36 +1300 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <5101E924.5030507@ninenines.eu> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> Message-ID: <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> On 25/01/2013, at 3:08 PM, Lo?c Hoguin wrote: > On 01/25/2013 01:31 AM, Richard O'Keefe wrote: >> >> On 24/01/2013, at 3:37 PM, Lo?c Hoguin wrote: >>> But I think their point is that Person.name does not require extra keystrokes to get the value, as opposed to Person#person.name or person:name(Person). >> >> I thought the complaint was that Person#person.name is not polymorphic; >> my point was that name(Person) _can_ be polymorphic, if you seriously >> want it to be. > > It's about ease of use, reducing the extra steps (or plane flight in the case of Erlang) to get the work done. (1) Please let's have a real concrete example of about 1 page, not imaginary one-liners, with names that turn out to be not as intention-revealing as they look. (2) Person#person.name is just a field selector; it can only fetch a stored data. The "frames" analogue, Person~name, has the same basic property. The Smalltalk analogue, person name, or the C# analogue, person.name, can run arbitrary code, which is much more powerful. Are we debating whether Person~name, with the same fundamental limitation as field access in C or Java or ML, is a really big improvement over Person#person_name? Or has the idea crept in that Person.name might run complex code? I note that www.missioncriticalit.com claim to be able to generate about 90% of the code in a business system (in Java, C#, or Mercury) from semantic models. That's _really_ where I think the big gains are going to come from. And I expect the core Erlang ideas to be good for such systems even if the Erlang language is replaced by a different embodiment of them. (It should be clear, but if not: each Domain needs its own Domain Specific Language. "Then Erlang needs that DSL." doesn't really make sense. 'Then Erlang needs its own toolkit to make building good DSLs easy' does make sense and I think it's true. >> character addToInventory: item > > Let me stop you right there. Nobody said anything could change Character. And where does that line of code say anything _does_ change Character? The _association_ between 'character' and 'item' changes, somehow. That doesn't mean 'character' has to change. That's the point, really. From fritchie@REDACTED Fri Jan 25 05:46:32 2013 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Thu, 24 Jan 2013 22:46:32 -0600 Subject: [erlang-questions] erlc speed (or lack thereof), Make and emake In-Reply-To: Message of "Fri\, 25 Jan 2013 03\:28\:19 +0100." <5101EDC3.6070105@ninenines.eu> Message-ID: <54339.1359089192@snookles.snookles.com> Lo?c Hoguin wrote: lh> I actually removed it initially to improve my development life lh> (where I do a lot of dialyzing and running tests), then decided to lh> stop using it entirely. I use Makefiles anyway, and rebar's lh> functionality is replicated in just a dozen more lines compared to lh> the original Makefile. That's understandable, Lo?c, not faulting you for avoiding rebar. On the matter of reducing startup time, I was quite serious about that. Both "erlc" and "escript" users would benefit greatly from reduced startup time. -Scott From barcojie@REDACTED Fri Jan 25 06:53:17 2013 From: barcojie@REDACTED (Barco You) Date: Fri, 25 Jan 2013 13:53:17 +0800 Subject: [erlang-questions] Cowboy feedback needed In-Reply-To: <5101A653.400@ninenines.eu> References: <5101A653.400@ninenines.eu> Message-ID: Hi Loic, I'd like to send feedback very much. But right now Cowboy is just used as demo in my company --- BesTV (www.bestv.com.cn), which is the largest IPTV and intenetTV operator in China. Although I think Cowby is good, the production environment is still dominated by Java and mainstream HTTP servers. Because I'm from Ericsson, I hope to promote Erlang here but it's not so easy. I would send the data if Cowboy would be used in production and fully tested. Thank you! Barco On Fri, Jan 25, 2013 at 5:23 AM, Lo?c Hoguin wrote: > Hey, > > I'm looking into perhaps starting a project related to Cowboy and could > use some feedback from users, particularly in the realm of numbers. > > If you use Cowboy and have it in production where: > > * Latency is vital > * Throughput is vital > * Concurrent number of connections is huge > * Load is huge (or would be with another solution) > > Then I'd like to hear from you! > > Please send me average numbers, statistics, graphs or anything where I can > see how well it performs for you! In private if you prefer. Tell me if I > can quote you or your company about it. Please answer even if we briefly > discussed it in the past. > > (If you found that it didn't perform enough for your needs you should > probably open a ticket, or, if you can't, send me a private email.) > > Looking forward to the feedback. Thanks! > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > 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 Fri Jan 25 07:26:27 2013 From: mjtruog@REDACTED (Michael Truog) Date: Thu, 24 Jan 2013 22:26:27 -0800 Subject: [erlang-questions] Cowboy feedback needed In-Reply-To: <5101A653.400@ninenines.eu> References: <5101A653.400@ninenines.eu> Message-ID: <51022593.7090306@gmail.com> A comparison (summary) of cowboy 0.6.1 and misultin 0.9 final in the context of CloudI is here: https://github.com/okeuday/CloudI/blob/master/src/tests/http_req/loadtest/results_v1_1_0/201210_summary.pdf (the raw Tsung results are also within the same directory) The results are just showing the latency when putting cowboy and misultin under 10kreq/s load with both 20k and 40k connections, when the requests go through CloudI messaging into all the supported programming languages (Erlang, C/C++, pure-Java, Python/C, pure-Python, and pure-Ruby.... the "pure" part is where only the target language is used to create the CloudI API, which does the Erlang binary term format CloudI request encoding/decoding). So, the test is showing the performance of a simple HTTP GET query parameter parse/response using XML (the XML is based on historical misultin testing). For these tests, it showed cowboy always has less latency which is significant, if the programming language internal latency is not significant. The cpu usage of cowboy was slightly lower than misultin for high connection counts (40k instead of 20k). The memory usage of cowboy was significantly lower than misultin. The test results are for R15B01 and R15B02, just due to when I did the loadtesting. I will continue to do similar loadtests in the future to make sure and evaluate performance with more recent Erlang releases, as time allows, but the Tsung configurations are within the repository for people to test their own (hardware) environments. On 01/24/2013 01:23 PM, Lo?c Hoguin wrote: > Hey, > > I'm looking into perhaps starting a project related to Cowboy and could use some feedback from users, particularly in the realm of numbers. > > If you use Cowboy and have it in production where: > > * Latency is vital > * Throughput is vital > * Concurrent number of connections is huge > * Load is huge (or would be with another solution) > > Then I'd like to hear from you! > > Please send me average numbers, statistics, graphs or anything where I can see how well it performs for you! In private if you prefer. Tell me if I can quote you or your company about it. Please answer even if we briefly discussed it in the past. > > (If you found that it didn't perform enough for your needs you should probably open a ticket, or, if you can't, send me a private email.) > > Looking forward to the feedback. Thanks! > From jesper.louis.andersen@REDACTED Fri Jan 25 10:39:28 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 25 Jan 2013 10:39:28 +0100 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <51014B80.2060608@ninenines.eu> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <78E826B7-4C7B-4896-B9D0-5D061901F9D3@erlang-solutions.com> <51014B80.2060608@ninenines.eu> Message-ID: <7AC7CB49-0DC8-4A4E-BE82-785E33F2E131@erlang-solutions.com> On Jan 24, 2013, at 3:56 PM, Lo?c Hoguin wrote: > Are you suggesting that #character *duplicates* fields from both #weapon and #ability? Then you'd just end up with #character having hundreds of fields, which is as unmanageable and even less readable, especially if some share a common name, like #character.attack_pts and #weapon.attack_pts. No, I am just looking at how the data will be represented in the heap in memory. Each record is a tuple and you access it by following a reference to another tuple until you have been digging deep down into the structure. Note that few other functional languages support chained projections. Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen From jesper.louis.andersen@REDACTED Fri Jan 25 10:47:30 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 25 Jan 2013 10:47:30 +0100 Subject: [erlang-questions] Does the latest erlang release have implement "native process" ? In-Reply-To: References: <772D888C4B7B4D9B9CAEAFFF1E3A743D@gmail.com> Message-ID: On Jan 25, 2013, at 2:31 AM, Steve Vinoski wrote: > > > On Thu, Jan 24, 2013 at 8:28 PM, Bob wrote: > Hi, > Does the latest erlang release have implement "native process" ? > > No. > > --steve > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions This is the place where you need to bug Rickard, and perhaps even more so, Kenneth to make native processes goddammit. (But it is not as easy as you would think to make them) Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen From avalormaquedano@REDACTED Fri Jan 25 11:11:00 2013 From: avalormaquedano@REDACTED (=?ISO-8859-1?B?wWx2YXJv?=) Date: Fri, 25 Jan 2013 11:11:00 +0100 Subject: [erlang-questions] Receive with priority [yet again] In-Reply-To: <25040.1359063723@snookles.snookles.com> References: <25040.1359063723@snookles.snookles.com> Message-ID: Thanks a lot Scott. No 'recv_mark' or 'recv_set' operators appear, so I must look for a workaround... :-( Cheers, ?lvaro 2013/1/24 Scott Lystig Fritchie > ?lvaro wrote: > > am> This function will be called periodically and I need to know if this > am> implementation will always go through all the message in the mailbox > am> (i.e. it will try to match Pattern1 to the messages at the beginning > am> of the mailbox over and over again). > > ?lvaro, compile your module using "erlc -S", then look at the BEAM > assembly for your function ... if the operators 'recv_mark' and > 'recv_set' appear (where the argument for recv_set is the same as the > argument for recv_mark), then the function will not scan all messages in > the mailbox. If you do not see them, then a full mailbox scan will be > done. > > -Scott > -------------- next part -------------- An HTML attachment was scrubbed... URL: From knutin@REDACTED Fri Jan 25 11:30:47 2013 From: knutin@REDACTED (Knut Nesheim) Date: Fri, 25 Jan 2013 11:30:47 +0100 Subject: [erlang-questions] cluster configuration, or dynamic (re)configuration of distributed application nodes In-Reply-To: References: Message-ID: Hi, I've faced similar problems in the past although on a much more fine grained scale (tens of thousands of these processes, but less important). It was also important to never have overlapping processes. In your case it sounds like you could well live with having two applications running for some time. We ended up using a distributed consistent locking system. The way it works is that any number of processes tries to grab a named lock and only one process acquire the lock. The lock gives you a lease for a period of time and you have to extend the lease before it expires. If the process or node owning the lock dies and does not clean up after itself, the lock will be released shortly. This works well for very fine-grained locks. Our implementation is released under the MIT license and is on https://github.com/wooga/locker Some more highlights: nodes can be added and removed to the cluster dynamically, you can have replicas for scaling reads. I will be presenting it at the Erlang Factory in San Francisco in March. Disclaimer: it makes some really tough trade offs, for example cluster reconfiguration assumes all nodes and the network are behaving well. As you only have one big thing you want to move around a cluster, it sounds more like you would want to elect a leader among your nodes. When the leader dies (application is shut down or node goes away or it stops checking in with the other nodes), you can elect a new leader and start the application there. gen_leader could help you with this, although I've never used it myself. Zookeper is a good option, but maybe overkill for just a smaller piece of your overall app. If you can live with multiple instances of your app running, it makes things much more relaxed in terms of consistency. Maybe you could have a look at how Riak is gossiping around the ring. It's relatively simple, decentralized and robust. It could serve as an inspiration. Knut On Thu, Jan 24, 2013 at 7:13 PM, Motiejus Jak?tys wrote: > Hi, > > we are about to investigate dynamic node reconfiguration of > distributed applications. Did somebody do that already? How does > kernel application react to application:set_env(kernel, ...)? Or is > there a more elegant approach? We have a quite dynamic cluster of > nodes, and we need one application running all the time. We have our > own solution which is quite simple, but it *seems* like it should be > better done in OTP way. > > Reason: we have a "cluster manager" application, which collects the > cluster health status: started applications, requests per second, > various tests, etc. This information is updated every second via many > rpc calls to all the nodes. > > It would be possible to have the same application running on all the > nodes, but then they all have the same information. Which is data > duplication. Not too many messages, but why repeat ourselves? > > How do/would you approach this "cluster health" problem? > > -- > Motiejus Jak?tys > _______________________________________________ > 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 Jan 25 12:10:07 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Fri, 25 Jan 2013 12:10:07 +0100 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> Message-ID: <5102680F.1030108@ninenines.eu> On 01/25/2013 04:09 AM, Richard O'Keefe wrote: > > On 25/01/2013, at 3:08 PM, Lo?c Hoguin wrote: > >> On 01/25/2013 01:31 AM, Richard O'Keefe wrote: >>> >>> On 24/01/2013, at 3:37 PM, Lo?c Hoguin wrote: >>>> But I think their point is that Person.name does not require extra keystrokes to get the value, as opposed to Person#person.name or person:name(Person). >>> >>> I thought the complaint was that Person#person.name is not polymorphic; >>> my point was that name(Person) _can_ be polymorphic, if you seriously >>> want it to be. >> >> It's about ease of use, reducing the extra steps (or plane flight in the case of Erlang) to get the work done. > > > (1) Please let's have a real concrete example of about 1 page, > not imaginary one-liners, with names that turn out to be > not as intention-revealing as they look. It's a real concrete example. I'm sure you can imagine other examples. Or perhaps you are going to tell me you never had to manage big amounts of related data in Erlang? (Wouldn't surprise me.) > (2) Person#person.name is just a field selector; it can only fetch > a stored data. The "frames" analogue, Person~name, has the > same basic property. The Smalltalk analogue, person name, > or the C# analogue, person.name, can run arbitrary code, which > is much more powerful. > > Are we debating whether Person~name, with the same fundamental > limitation as field access in C or Java or ML, is a really big > improvement over Person#person_name? > > Or has the idea crept in that Person.name might run complex code? *Data*. Not code. Access. Update. That's all that's needed. > I note that www.missioncriticalit.com claim to be able to generate > about 90% of the code in a business system (in Java, C#, or Mercury) > from semantic models. > > That's _really_ where I think the big gains are going to come from. > And I expect the core Erlang ideas to be good for such systems even > if the Erlang language is replaced by a different embodiment of them. > > (It should be clear, but if not: each Domain needs its own Domain > Specific Language. "Then Erlang needs that DSL." doesn't really > make sense. 'Then Erlang needs its own toolkit to make building > good DSLs easy' does make sense and I think it's true. Let me tell you something about yourself. You are confronted with the problem of wasting a lot of time writing basement level code to access and update deep values. You think "Great! I can write DSL or combinators to solve this!". Now you got two problems, and you haven't come any closer to solving the first one. The DSL still maps to functions which needs to access and update these values, and that code is still painful to write. Your next step is to think "Great! Let's generate all that code then!". Now you got three problems, and you better hope to have not made any error when writing that code generator or you'll waste a lot more time. Speaking of time, by the time you get to that point the PHP developer has already long finished his bug-free implementation of the same code and is moving on to other tasks. There's absolutely no need for a DSL. All you have to do is have the correct interface, like character:add_to_inventory(Item, Character) and your game logic is clear. The problem is that the code on the other side of this interface is messy, prone to errors and takes too damn long to write with current Erlang, because Erlang focuses so much on functions that it totally forgot that in the end it's all about data and it'd be nice to actually do something meaningful with it. >>> character addToInventory: item >> >> Let me stop you right there. Nobody said anything could change Character. > > And where does that line of code say anything _does_ change Character? > The _association_ between 'character' and 'item' changes, somehow. > That doesn't mean 'character' has to change. > > That's the point, really. That's still besides the point. If it's not Character.inventory it's State.character and State.inventory. Doesn't make updating any easier. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From robert.virding@REDACTED Fri Jan 25 13:11:42 2013 From: robert.virding@REDACTED (Robert Virding) Date: Fri, 25 Jan 2013 12:11:42 +0000 (GMT) Subject: [erlang-questions] Improve $handle_undefined_function In-Reply-To: <510173A6.7030904@erlang.org> Message-ID: <534063266.3051367.1359115902000.JavaMail.root@erlang-solutions.com> ----- Original Message ----- > From: "Bj?rn-Egil Dahlberg" > On 2013-01-24 18:31, Bj?rn-Egil Dahlberg wrote: > > On 2013-01-24 18:12, Robert Virding wrote: > > > > I think the OTP group made a bad decision *indexing* binaries > > > from > > > zero instead of one like the rest of erlang. It is both wrong and > > > makes the system inconsistent. > > > > > Btw, when you say "the OTP group made a bad decision", exactly who > > are you referring too? Yourself? Isn't these decisions from CS-lab? > > Certainly way before my time =) > > That probably sounds a bit more irritated than intended. > I'm honestly curious, who decided indexing on terms and binaries and > what was the reasoning behind it? > I think I recall someone saying that binary-syntax was the last thing > out from CS-Lab? The decisions were made at different times. The choice of indexing in tuples and lists (with the lists:nth function) were made very early when all Erlang work was done by the CS-lab. So they are definitely my fault, partly at least. And I still think it was a good decision. :-) Binaries were added when Erlang was still at CS-lab, but there were no indexing operations as such. split_binary/2 ORIGINALLY had as argument the length of the first binary, but now it is the position of the split. It works the same either way. IIRC The later BIFs binary_split/2/3 came longer after Erlang left the CS-lab and is in the hands of the OTP group and are explicitly zero indexed. My view is that you could choose either depending on you how you swing, but choosing both is definitely the worst option. I am getting old and I value consistency. :-) Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Jan 25 13:25:40 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Fri, 25 Jan 2013 13:25:40 +0100 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <5102680F.1030108@ninenines.eu> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> Message-ID: <510279C4.9000000@ninenines.eu> On 01/25/2013 12:10 PM, Lo?c Hoguin wrote: > Let me tell you something about yourself. I have been told this bit can be considered offensive in English, it isn't meant to be. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From dave@REDACTED Fri Jan 25 13:33:39 2013 From: dave@REDACTED (David Goehrig) Date: Fri, 25 Jan 2013 07:33:39 -0500 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <510150CC.90208@ninenines.eu> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <510150CC.90208@ninenines.eu> Message-ID: On Thu, Jan 24, 2013 at 10:18 AM, Lo?c Hoguin wrote: > > Assume a variable Character. This variable contains everything about the > character. How do you best access and modify Character? The answer must not > involve the process dictionary, processes or message passing. Today I have > to write each access and modification function. Or I can generate it, but > either way I end up with hundreds of functions in many modules. Assuming that "you're doing it wrong" and you make "doing this wrong" a requirement, the easiest way is nested proplists (as would effectively be the case in Perl, Python, Ruby, Javascript, Lua, etc. minus some fine points of the implementations of the dictionaries, hashes, and tables), and two utility functions: of(Object,Property) -> proplists:get_value(Property,Object). has(Object,Property,Value) -> [ { Property, Value } | proplists:delete(Property,Object) ]. Where due to the horrible nature of the beast Character.weapon.ability.cost is: of(of(of(Character,weapon),ability),cost). And the assignment Character.weapon.ability.cost := 123 is: Character2 = has(Character,weapon, has(of(Character,weapon), ability), has(of(of(Character,weapon),ability), cost, 123))). Which of course once again only goes to suggest "you're doing it wrong", but at least you aren't writing reams of code for each object type. This would then lend itself to abstracting out each "type" of setting if you want to feel like you're doing something "object oriented": character:wield(Character,Weapon ) -> has(Character,weapon,Weapon). weapon:enchanted(Weapon,Ability) -> has(Weapon,ability, Ability). ability:price(Ability,Cost) -> has(Ability,cost,Cost). Which would disguise your problem into something more "object oriented": Character2 = character:wield(Character, weapon:enchanted(of(Character,weapon),ability:price(of(of(Character,weapon),ability),123))). But the entire notion of nested structures for this sort of design would be wrong in most languages as the exact semantics rely upon wether or not you are intending for just this instance of this Character's weapon's ability's cost to be modified, or you are modifying the cost of the ability across the game (due to ability being a reference to a shared data structure, or just intending all instances of this weapon to be modified (due to ability being a substructure of weapon itself AND weapon is a reference to a shared structure). In either of those two cases, this approach will fail entirely, as it will construct clean proplists and only modify the cost of this specific character's individual weapon's specific ability cost. So once again: Character.weapon.ability.cost = 123 Is very difficult to qualify within your assumptions, because we don't know the structural ramifications of the . operator. Part of the reason I brought up process dictionaries and processes is I've been playing around with structuring game data using them: https://github.com/cthulhuology/eoom/blob/master/object.erl Where you can send "objects" messages to do these things: 1> l(object). {module,object} 2> O = object:new(). <0.34.0> 3> O ! [ self(), does, hello, fun() -> io:format("hello world~n") end ]. [<0.31.0>,does,hello,#Fun] 4> O ! hello. hello world hello 5> The fun thing here is sending funs to objects living out in the servers and modifying their behavior at a distance. So in this scheme, I would tend to do something like: Character ! [ self(), wielding ]. Which would respond with a message send of its own Sender ! [ wielding, get(weapon) ]. In the interrogating process's wielding method I'd then send the Weapon: Weapon ! [ self(), price, 123 ]. And it would set its own cost in it's price method. So there's a lot of ways to skin this cat based on the structure of how you hide your properties. Dave -- -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From js@REDACTED Fri Jan 25 13:33:28 2013 From: js@REDACTED (Schneider) Date: Fri, 25 Jan 2013 13:33:28 +0100 Subject: [erlang-questions] Unixtime in Erlang In-Reply-To: <23813.1359062769@snookles.snookles.com> References: <23813.1359062769@snookles.snookles.com> Message-ID: <51027B98.1060005@globe.de> thnx. On Thu 24 Jan 2013 10:26:09 PM CET, Scott Lystig Fritchie wrote: > Motiejus Jak?tys wrote: > > mj> os:timestamp() is a slightly faster version of erlang:now(). > > Slight correction: it's quite a bit faster than erlang:now(), if you're > executing in a heavily loaded VM on an multi-core machine. > > IIRC (untested code): > > now_as_time_t() -> > {A, B, _} = os:timestamp(), > (A * 1000000) + B. > > -Scott From maruthavanan_s@REDACTED Fri Jan 25 13:45:43 2013 From: maruthavanan_s@REDACTED (Maruthavanan Subbarayan) Date: Fri, 25 Jan 2013 07:45:43 -0500 Subject: [erlang-questions] Why some functions are not documented Message-ID: Hi, I found that there are many functions exported in edoc_lib module, but I wanted to know why those are not documented. I wanted to encode a http url and was able to do with this edoc_lib:escape_uri() but luckily found in some website about this function. Thanks,Marutha -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Jan 25 13:56:37 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Fri, 25 Jan 2013 13:56:37 +0100 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <510150CC.90208@ninenines.eu> Message-ID: <51028105.2090703@ninenines.eu> On 01/25/2013 01:33 PM, David Goehrig wrote: > > > On Thu, Jan 24, 2013 at 10:18 AM, Lo?c Hoguin > wrote: > > > Assume a variable Character. This variable contains everything about > the character. How do you best access and modify Character? The > answer must not involve the process dictionary, processes or message > passing. Today I have to write each access and modification > function. Or I can generate it, but either way I end up with > hundreds of functions in many modules. > > > Assuming that "you're doing it wrong" and you make "doing this wrong" a Am I? What is the right way then? Creating many processes isn't helping write my snippets any easier in Erlang, it just complicates things. > the easiest way is nested proplists Nope, it's still a pain to update. > if you want to feel like you're doing something "object oriented": I don't want to do something object oriented. I hate OO. I just want primitives to easily update deep data structures. [...] > > But the entire notion of nested structures for this sort of design would > be wrong in most languages as the exact semantics rely upon wether or > not you are intending for just this instance of this Character's > weapon's ability's cost to be modified, or you are modifying the cost of > the ability across the game (due to ability being a reference to a > shared data structure, or just intending all instances of this weapon to > be modified (due to ability being a substructure of weapon itself AND > weapon is a reference to a shared structure). > > In either of those two cases, this approach will fail entirely, as it > will construct clean proplists and only modify the cost of this specific > character's individual weapon's specific ability cost. But modifying the cost of this specific character's individual weapon is exactly what we want! And it's exactly what is painfully hard to write in Erlang. > Is very difficult to qualify within your assumptions, because we don't > know the structural ramifications of the . operator. Think of it as C structs and arrays for example. If I have a field in a struct in an array in a struct, and I want to update this field's value, it's a one liner in C, and many many lines in Erlang. Of course Erlang has immutable variables, but that doesn't prevent it to figure out at runtime what exactly we want to modify and return a copy of the struct with the field modified. This of course has a runtime cost, but it's irrelevant compared to how nicely small your program becomes and how fast you can write it. > So there's a lot of ways to skin this cat based on the structure of how > you hide your properties. This isn't about hiding the properties, this is about the syntax for modifying these properties in the process where you hide them. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From darach@REDACTED Fri Jan 25 14:07:34 2013 From: darach@REDACTED (Darach Ennis) Date: Fri, 25 Jan 2013 13:07:34 +0000 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <510279C4.9000000@ninenines.eu> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> <510279C4.9000000@ninenines.eu> Message-ID: Hi guys, There is a problem here. Any reasonably sized or structured erlang application requires records, despite the grody record syntax. The alternative? Big hairy unstructured clods of tuple and lists and things? Worse. Unmaintainable in and of itself. Hard to pattern match. Had to manipulate. Hard for humans to grok whilst reading without squinting your brain hard and quizzically at the terminal ... Unlike the matrix, it's not blonde, brunette or a redhead ... It's something else! ;( So they're needed? Yes. Use by choice? No. And that's the problem. I secretly hope for for something better to come along. A big gnarly unstructured and frequently accessed tuple would be fine, for example, if there was some kind of tuple path expression language... like XML has XPath? Jackpot. So maybe frames aren't needed at all. Maybe frames would be nice. Perhaps we just want to reach out and touch the a subset of tuples of lists of tuples of lists of tuples of ... I'm pretty sure with or without frames that solves 80% of the need for me. The other 20%? - Native support for Kaysian transforms and other natural conveniences for efficient slicing, dicing, filtering and merging. I'm not sure record or any other syntax is actually the problem. Also, the nice thing about adding something like an XPath like thing for tuples? It doesn't break existing applications. It's backward compatible. It's forward migratable. No new syntax because an expression can be a plain old list of binary (string). So, we maybe xmerl_xpath already has 99% of what's needed... Cheers, Darach. On Fri, Jan 25, 2013 at 12:25 PM, Lo?c Hoguin wrote: > On 01/25/2013 12:10 PM, Lo?c Hoguin wrote: > >> Let me tell you something about yourself. >> > > I have been told this bit can be considered offensive in English, it isn't > meant to be. > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > 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 schintke@REDACTED Fri Jan 25 14:10:31 2013 From: schintke@REDACTED (Florian Schintke) Date: Fri, 25 Jan 2013 14:10:31 +0100 Subject: [erlang-questions] erlc speed (or lack thereof), Make and emake In-Reply-To: <20130124124948.GA4801@corelatus.se> References: <20130124124948.GA4801@corelatus.se> Message-ID: <20130125131031.GH3169@csr-pc9.zib.de> Hi, we use the Erlang module 'make' and an Emakefile to specify what and how to compile if necessary. See http://erldocs.com/R14B04/tools/make.html Our Unix makefile entry looks as follows: --- compile: @$(ERL) -pa ebin -noinput +B -eval 'case make:all() of up_to_date -> halt(0); error -> halt(1) end.' --- It starts Erlang once and compiles all touched/depending modules, which is really fast. Parallel make is missing, but not necessary at that speed. See scalaris.googlecode.com for a sample Emakefile. Florian [Matthias Lang] > Hi, > > I'm looking for tips and tricks to use speed up compiling a bunch of > Erlang modules from within a build system that uses (gnu)Make. > > The system uses Erlang, but most of it is actually C code, which is compiled > under four different compilers, plus FPGA code. So ditching 'make' > for something Erlang-centric like 'rebar' doesn't look very attractive. > > Background > ---------- > > Doing this on R14B03: > > erlc a.erl > erlc b.erl > erlc c.erl > ... > > for 70 modules on my machine takes 39s. If I do this instead: > > erlc a.erl b.erl c.erl ... > > it improves to 7s. If I split the job in two parts which run at the > same time, it improves again to 4s wall time, with both cores > busy. > > So, a 10x improvement in compilation speed seems attainable, but how do > I explain how to do it to 'make'? > > > Ideas > ----- > > I had a few simple ideas for fixing this, but none really work. See below. > > The more complicated idea I have is to make a shell script replacement > for 'erlc' which delegates the compilation work to an Erlang node > which is already running. Seems workable, and it won't spring > surprises on 'make', e.g. -j 4 will still do the right thing. > > Anyone got a neat idea? > > Rest of this mail is just a list of things that don't seem to work. > > Matt > > ====================================================================== > > > Bad Idea #1: straightforward 'make' > ----------- > > Here's my minimal starting point for a system of three modules, a b c: > > beams=(addsuffix .beam, a b c) > %.beam: %.erl nasty_global_stuff.hrl > erlc $< > > That causes 'make' to hand one module to erlc at a time, which is slow. > > > Bad Idea #2: try and use just one rule for all .beams > ----------- > > Like this: > > modules=a b c > beams=$(addsuffix .beam, $(modules)) > erls=$(addsuffix .erl, $(modules)) > all: $(beams) > > $(beams): $(erls) nasty_global_stuff.hrl > erlc $(filter %.erl, $@) > > That does almost the right thing, but actually not at all. Change one > .erl and it'll recompile every .beam, because I've told 'make' that > each .beam depends on all .erl files. > > > Bad Idea #3: use erl -make for all Erlang compilations > ----------- > > all: > erl -make > > That sort-of works, but it only runs one process (Erlang's own 'make' > doesn't seem to attempt running more than one compilation at a time), > passing options is not straightforward (they're not even syntactically > the same as for erlc) and it requires writing 'EMakefiles', so you > sort-of have to understand Erlang in order to be able to fiddle with > the build system. > > It's also fiddly explaining dependencies between Erlang stuff and > other stuff to a combination of ordinary 'make' and erlang's own make. > > --end of bad ideas--- From steve@REDACTED Fri Jan 25 14:21:01 2013 From: steve@REDACTED (Steve Strong) Date: Fri, 25 Jan 2013 14:21:01 +0100 Subject: [erlang-questions] lager_trunc_io In-Reply-To: <20130124190540.GE12548@hijacked.us> References: <52F8F721F8BC4C4E9C6E3027232CADE2@srstrong.com> <20130124190540.GE12548@hijacked.us> Message-ID: Excellent - many thanks. I've pulled 1.2.2 an will run it on our QA stack for a few days to see how it behaves. Cheers, Steve -- Steve Strong Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Thursday, 24 January 2013 at 20:05, Andrew Thompson wrote: > Ok, I think what you're seeing is the bug around improper list printing. > It is fixed in master, but not in 1.2.1. > > I'm guessing either the 'last message' or the state contains something > like this: [[$a | {self(), left}]], which is causing the crash. > > Anyway, I've backported the fix (and one other tiny fix) from master to > a new 1.2 branch (based off of the 1.2.1 tag) and tagged 1.2.2. > > Thanks for the report. > > Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From tamas@REDACTED Fri Jan 25 15:19:22 2013 From: tamas@REDACTED (=?iso-8859-1?Q?Szepes_Tam=E1s?=) Date: Fri, 25 Jan 2013 15:19:22 +0100 Subject: [erlang-questions] gen_fsm internal transition In-Reply-To: <61AED908-07A8-4083-B752-3ECA70A5E0F6@gmail.com> References: <003801cdfa56$3d9e2c00$b8da8400$@veriport.eu> <61AED908-07A8-4083-B752-3ECA70A5E0F6@gmail.com> Message-ID: <000d01cdfb06$f9224280$eb66c780$@veriport.eu> Thanks for suggestion, I modified my code accordingly. Tamas -----Original Message----- From: Dmitry Kolesnikov [mailto:dmkolesnikov@REDACTED] Sent: Thursday, January 24, 2013 11:38 PM To: Szepes Tam?s Cc: erlang-questions@REDACTED Subject: Re: [erlang-questions] gen_fsm internal transition Hello, In practice, this is a safe way to handle internal transition. In theory, internal FSM transitions should be avoided. I would make it like this state_name0(Event, From, State) -> my_action_1( my_action_0(State) ); state_name1(Event, From State) -> my_action1(State); my_action_0(State) -> % here goes code from you state_name my_action_1(State) -> % here goes code from your state_name1 - Dmitry On Jan 24, 2013, at 7:14 PM, Szepes Tam?s wrote: > All, > > What is the right way of doing an internal state transition in a gen_fsm? > > Is the following pattern safe to use? > > state_name(Event, From, State) -> > . > . > . > gen_fsm:send_event_after(0, internal_transition), > {next_state, state_name1, State}. > > state_name1(internal_transition, From, State) -> > . > . > . > {reply, ok, state_name1, State}. > > Thanks, > Tamas > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From daniel.goertzen@REDACTED Fri Jan 25 15:36:47 2013 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Fri, 25 Jan 2013 08:36:47 -0600 Subject: [erlang-questions] erlc speed (or lack thereof), Make and emake In-Reply-To: <20130124124948.GA4801@corelatus.se> References: <20130124124948.GA4801@corelatus.se> Message-ID: As a variation of bad idea #2, use rebar instead of erlc to update all the beams. Rebar seems pretty fast to me, so you could even take the brute force approach and unconditionally run rebar on every build: .PHONY: mybeams mybeams: rebar compile Dan. On Thu, Jan 24, 2013 at 6:49 AM, Matthias Lang wrote: > Hi, > > I'm looking for tips and tricks to use speed up compiling a bunch of > Erlang modules from within a build system that uses (gnu)Make. > > The system uses Erlang, but most of it is actually C code, which is > compiled > under four different compilers, plus FPGA code. So ditching 'make' > for something Erlang-centric like 'rebar' doesn't look very attractive. > > Background > ---------- > > Doing this on R14B03: > > erlc a.erl > erlc b.erl > erlc c.erl > ... > > for 70 modules on my machine takes 39s. If I do this instead: > > erlc a.erl b.erl c.erl ... > > it improves to 7s. If I split the job in two parts which run at the > same time, it improves again to 4s wall time, with both cores > busy. > > So, a 10x improvement in compilation speed seems attainable, but how do > I explain how to do it to 'make'? > > > Ideas > ----- > > I had a few simple ideas for fixing this, but none really work. See below. > > The more complicated idea I have is to make a shell script replacement > for 'erlc' which delegates the compilation work to an Erlang node > which is already running. Seems workable, and it won't spring > surprises on 'make', e.g. -j 4 will still do the right thing. > > Anyone got a neat idea? > > Rest of this mail is just a list of things that don't seem to work. > > Matt > > ====================================================================== > > > Bad Idea #1: straightforward 'make' > ----------- > > Here's my minimal starting point for a system of three modules, a b c: > > beams=(addsuffix .beam, a b c) > %.beam: %.erl nasty_global_stuff.hrl > erlc $< > > That causes 'make' to hand one module to erlc at a time, which is slow. > > > Bad Idea #2: try and use just one rule for all .beams > ----------- > > Like this: > > modules=a b c > beams=$(addsuffix .beam, $(modules)) > erls=$(addsuffix .erl, $(modules)) > all: $(beams) > > $(beams): $(erls) nasty_global_stuff.hrl > erlc $(filter %.erl, $@) > > That does almost the right thing, but actually not at all. Change one > .erl and it'll recompile every .beam, because I've told 'make' that > each .beam depends on all .erl files. > > > Bad Idea #3: use erl -make for all Erlang compilations > ----------- > > all: > erl -make > > That sort-of works, but it only runs one process (Erlang's own 'make' > doesn't seem to attempt running more than one compilation at a time), > passing options is not straightforward (they're not even syntactically > the same as for erlc) and it requires writing 'EMakefiles', so you > sort-of have to understand Erlang in order to be able to fiddle with > the build system. > > It's also fiddly explaining dependencies between Erlang stuff and > other stuff to a combination of ordinary 'make' and erlang's own make. > > --end of bad ideas--- > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmercer@REDACTED Fri Jan 25 15:42:05 2013 From: dmercer@REDACTED (David Mercer) Date: Fri, 25 Jan 2013 08:42:05 -0600 Subject: [erlang-questions] Erlang Intro Presentation Message-ID: <017901cdfb0a$2581ca00$70855e00$@gmail.com> This comes up a couple of times a year, so thought I would send out another to see if anyone has any recommendations for intro-to-Erlang?type presentations that can be presented to a technical team of non-Erlangers during lunch sort of thing. I can come up with my own?and I have searched Google and come up with a bunch?but since this does come up periodically on this list, I figure others have done all the Google research more thoroughly recently, and I wanted to tap your brains for the state of the art Erlang presentation. Thanks in advance. Cheers, DBM -------------- next part -------------- An HTML attachment was scrubbed... URL: From abdoo.mahran@REDACTED Fri Jan 25 16:03:42 2013 From: abdoo.mahran@REDACTED (Abd El-Fattah Mahran) Date: Fri, 25 Jan 2013 17:03:42 +0200 Subject: [erlang-questions] Erlang Intro Presentation In-Reply-To: <017901cdfb0a$2581ca00$70855e00$@gmail.com> References: <017901cdfb0a$2581ca00$70855e00$@gmail.com> Message-ID: You can use this one if you like. I presented to people new to Erlang three years ago. http://www.slideshare.net/SinarShebl/introduction-to-erlang-final Thanks, best regards, On Fri, Jan 25, 2013 at 4:42 PM, David Mercer wrote: > This comes up a couple of times a year, so thought I would send out > another to see if anyone has any recommendations for intro-to-Erlang?type > presentations that can be presented to a technical team of non-Erlangers > during lunch sort of thing. I can come up with my own?and I have searched > Google and come up with a bunch?but since this does come up periodically on > this list, I figure others have done all the Google research more > thoroughly recently, and I wanted to tap your brains for the state of the > art Erlang presentation.**** > > ** ** > > Thanks in advance.**** > > ** ** > > Cheers,**** > > ** ** > > DBM**** > > ** ** > > _______________________________________________ > 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 loris.fichera@REDACTED Fri Jan 25 16:05:56 2013 From: loris.fichera@REDACTED (Loris Fichera) Date: Fri, 25 Jan 2013 16:05:56 +0100 Subject: [erlang-questions] Erlang Intro Presentation In-Reply-To: <017901cdfb0a$2581ca00$70855e00$@gmail.com> References: <017901cdfb0a$2581ca00$70855e00$@gmail.com> Message-ID: <51029F54.5080103@gmail.com> Hey David, On 01/25/2013 03:42 PM, David Mercer wrote: > This comes up a couple of times a year, so thought I would send out > another to see if anyone has any recommendations for > intro-to-Erlang?type presentations that can be presented to a technical > team of non-Erlangers during lunch sort of thing. I can come up with my > own?and I have searched Google and come up with a bunch?but since this > does come up periodically on this list, I figure others have done all > the Google research more thoroughly recently, and I wanted to tap your > brains for the state of the art Erlang presentation. Did you have a look at Roberto Aloi's "Why you should build your next application in Erlang" talk? https://speakerdeck.com/robertoaloi/why-you-should-build-your-next-application-in-erlang Cheers, --Loris. From erlang@REDACTED Fri Jan 25 16:08:50 2013 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 25 Jan 2013 16:08:50 +0100 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> <510279C4.9000000@ninenines.eu> Message-ID: Manipulating nested records is a pain - how about this? Assume we have three records -record(top, {a::#one{}, b::#two{}, c::#three{} }). -record(one, {x::#foo{}, y::#bar{} }) -record(foo, {p,q,r}). and I want to unpack the p field from a variable X containing a top record. I don't want to write #top{a=#one{x=#foo{p=P}}} = X this is messy and error prone This should do the job P = extract_from(X, top,p) A compile transform could figure out the code to make. In this case the tag p has a unique path from the top root. In the case where the required tag is not unique, we'll need to "hint" the path. We just give the parse transform enough hints to figure out the path at compile time. We should get a error if the path does not uniquely specify the element. Cheers /Joe On Fri, Jan 25, 2013 at 2:07 PM, Darach Ennis wrote: > Hi guys, > > There is a problem here. Any reasonably sized or structured erlang > application > requires records, despite the grody record syntax. The alternative? Big > hairy unstructured > clods of tuple and lists and things? Worse. Unmaintainable in and of > itself. Hard to pattern > match. Had to manipulate. Hard for humans to grok whilst reading without > squinting your > brain hard and quizzically at the terminal ... > > Unlike the matrix, it's not blonde, brunette or a redhead ... It's > something else! ;( > > So they're needed? Yes. Use by choice? No. And that's the problem. > > I secretly hope for for something better to come along. A big gnarly > unstructured > and frequently accessed tuple would be fine, for example, if there was > some kind > of tuple path expression language... like XML has XPath? Jackpot. > > So maybe frames aren't needed at all. Maybe frames would be nice. Perhaps > we > just want to reach out and touch the a subset of tuples of lists of tuples > of lists of > tuples of ... I'm pretty sure with or without frames that solves 80% of > the need for me. > > The other 20%? - Native support for Kaysian transforms and other natural > conveniences > for efficient slicing, dicing, filtering and merging. > > I'm not sure record or any other syntax is actually the problem. > > Also, the nice thing about adding something like an XPath like thing for > tuples? > It doesn't break existing applications. It's backward compatible. It's > forward > migratable. No new syntax because an expression can be a plain old list of > binary (string). > > So, we maybe xmerl_xpath already has 99% of what's needed... > > Cheers, > > Darach. > > > > On Fri, Jan 25, 2013 at 12:25 PM, Lo?c Hoguin wrote: > >> On 01/25/2013 12:10 PM, Lo?c Hoguin wrote: >> >>> Let me tell you something about yourself. >>> >> >> I have been told this bit can be considered offensive in English, it >> isn't meant to be. >> >> >> -- >> Lo?c Hoguin >> Erlang Cowboy >> Nine Nines >> 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 vladdu55@REDACTED Fri Jan 25 16:55:06 2013 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 25 Jan 2013 16:55:06 +0100 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> <510279C4.9000000@ninenines.eu> Message-ID: Hi all, There are two schools of thought here. One would like to put all the data in a giant nested data structure and the other would like to split it up into the smallest possible parts. I think that was what David G. hinted at before, but he didn't put the final dot over the i. Having a single huge immutable nested data structure would require the kind of access patterns exemplified by "character.current_weapon.score", but is not without other kind of problems. I can think of three important ones. (1) You would need another syntax for "character.bag_item(12).supply" or "character.friend('Bilbo').weapon", for example. This is alleviated by Joe's suggestion, where one can use all kind of selectors. (2) All updating must be done from the root or in several steps, so i f I have X=Character.weapon, X.score=10, I need to remember to Character.weapon=X. (3) Changing the implementation of an item to another data structure might be problematic without changing all the call sites. On the other side, that David described, one could have a character process, a weapon process, a bag process and so on. Then, using a construct that Joe suggested oh so many years ago, you could write Character!!weapon!!score to retrieve it and Character!!weapon!!{score, 30} to set it. The !! operator is a 'rpc' and is conceptually a send followed by a receive. The processes will be effectively implement active objects. My feeling is that the latter option is more Erlang-y, but it may be a matter of taste. best regards, Vlad On Fri, Jan 25, 2013 at 4:08 PM, Joe Armstrong wrote: > Manipulating nested records is a pain - how about this? > > Assume we have three records > > -record(top, {a::#one{}, b::#two{}, c::#three{} }). > -record(one, {x::#foo{}, y::#bar{} }) > -record(foo, {p,q,r}). > and I want to unpack the p field from a variable X containing a top > record. > > I don't want to write > > #top{a=#one{x=#foo{p=P}}} = X > > this is messy and error prone > > This should do the job > > P = extract_from(X, top,p) > > A compile transform could figure out the code to make. In this case the > tag p has a unique path from the top root. In the case where the required > tag is not unique, we'll need to "hint" the path. > > We just give the parse transform enough hints to figure out > the path at compile time. We should get a error if the path does not > uniquely > specify the element. > > Cheers > > /Joe > > > > > On Fri, Jan 25, 2013 at 2:07 PM, Darach Ennis wrote: > >> Hi guys, >> >> There is a problem here. Any reasonably sized or structured erlang >> application >> requires records, despite the grody record syntax. The alternative? Big >> hairy unstructured >> clods of tuple and lists and things? Worse. Unmaintainable in and of >> itself. Hard to pattern >> match. Had to manipulate. Hard for humans to grok whilst reading without >> squinting your >> brain hard and quizzically at the terminal ... >> >> Unlike the matrix, it's not blonde, brunette or a redhead ... It's >> something else! ;( >> >> So they're needed? Yes. Use by choice? No. And that's the problem. >> >> I secretly hope for for something better to come along. A big gnarly >> unstructured >> and frequently accessed tuple would be fine, for example, if there was >> some kind >> of tuple path expression language... like XML has XPath? Jackpot. >> >> So maybe frames aren't needed at all. Maybe frames would be nice. Perhaps >> we >> just want to reach out and touch the a subset of tuples of lists of >> tuples of lists of >> tuples of ... I'm pretty sure with or without frames that solves 80% of >> the need for me. >> >> The other 20%? - Native support for Kaysian transforms and other natural >> conveniences >> for efficient slicing, dicing, filtering and merging. >> >> I'm not sure record or any other syntax is actually the problem. >> >> Also, the nice thing about adding something like an XPath like thing for >> tuples? >> It doesn't break existing applications. It's backward compatible. It's >> forward >> migratable. No new syntax because an expression can be a plain old list of >> binary (string). >> >> So, we maybe xmerl_xpath already has 99% of what's needed... >> >> Cheers, >> >> Darach. >> >> >> >> On Fri, Jan 25, 2013 at 12:25 PM, Lo?c Hoguin wrote: >> >>> On 01/25/2013 12:10 PM, Lo?c Hoguin wrote: >>> >>>> Let me tell you something about yourself. >>>> >>> >>> I have been told this bit can be considered offensive in English, it >>> isn't meant to be. >>> >>> >>> -- >>> Lo?c Hoguin >>> Erlang Cowboy >>> Nine Nines >>> 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 pan@REDACTED Fri Jan 25 17:10:16 2013 From: pan@REDACTED (Patrik Nyblom) Date: Fri, 25 Jan 2013 17:10:16 +0100 Subject: [erlang-questions] Interesting issue... In-Reply-To: <50F58AD2.6010400@go-factory.net> References: <50F58AD2.6010400@go-factory.net> Message-ID: <5102AE68.7090103@erlang.org> Hi! This ought to be fixed already in R15B03, can you please verify that it's not present there? I can only reproduce it in R15B01 and prior releases. Cheers, /Patrik On 01/15/2013 05:58 PM, Bryan Hughes wrote: > Hi Everyone, > > I already submitted this to erlang-bugs@REDACTED, but figured others > might be interested. I found an interesting issue while traveling and > working through Thailand. I have been able to reproduce it on my > MacBook Pro using R15B01, built from source. > > 1. Set your date to Indochina Time. > 2. In the shell, try executing: > calendar:local_time_to_universal_time_dst({{2012,12,3},{8,48,42}}). > > Here is the exception that I am getting. Note that the date is a > validate datetime. > > Eshell V5.9.1 (abort with ^G) > 1> calendar:local_time_to_universal_time_dst({{2012,12,3},{8,48,42}}). > ** exception error: bad argument > in function erlang:localtime_to_universaltime/2 > called as > erlang:localtime_to_universaltime({{2012,12,3},{8,48,42}},true) > in call from calendar:local_time_to_universal_time_dst/1 > (calendar.erl, line 282) > > When I set my date back to Pacific time, it works without any problem > -- you can switch it back and forth while in the shell and either get > the exception, or the correct output. > > I was able to isolate it to function the bif.c function, unfortunately > my environment is not really set up to debug the erlang runtime. > > BIF_RETTYPE localtime_to_universaltime_2(BIF_ALIST_2); > > Cheers, > Bryan > > -- > > Bryan Hughes > CTO and Founder / *Go Factory* > http://www.go-factory.net > > > > > _______________________________________________ > 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 Fri Jan 25 17:23:33 2013 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Fri, 25 Jan 2013 17:23:33 +0100 Subject: [erlang-questions] Interesting issue... In-Reply-To: <5102AE68.7090103@erlang.org> References: <50F58AD2.6010400@go-factory.net> <5102AE68.7090103@erlang.org> Message-ID: Tried it on R15B03 on my MacBook Air (Indochina Time) and got no exception. The issue cannot be reproduced on R15B03. On 25 January 2013 17:10, Patrik Nyblom wrote: > Hi! > > This ought to be fixed already in R15B03, can you please verify that it's > not present there? I can only reproduce it in R15B01 and prior releases. > > Cheers, > /Patrik > > > On 01/15/2013 05:58 PM, Bryan Hughes wrote: > > Hi Everyone, > > I already submitted this to erlang-bugs@REDACTED, but figured others > might be interested. I found an interesting issue while traveling and > working through Thailand. I have been able to reproduce it on my MacBook > Pro using R15B01, built from source. > > 1. Set your date to Indochina Time. > 2. In the shell, try executing: > calendar:local_time_to_universal_time_dst({{2012,12,3},{8,48,42}}). > > Here is the exception that I am getting. Note that the date is a validate > datetime. > > Eshell V5.9.1 (abort with ^G) > 1> calendar:local_time_to_universal_time_dst({{2012,12,3},{8,48,42}}). > ** exception error: bad argument > in function erlang:localtime_to_universaltime/2 > called as > erlang:localtime_to_universaltime({{2012,12,3},{8,48,42}},true) > in call from calendar:local_time_to_universal_time_dst/1 > (calendar.erl, line 282) > > When I set my date back to Pacific time, it works without any problem -- > you can switch it back and forth while in the shell and either get the > exception, or the correct output. > > I was able to isolate it to function the bif.c function, unfortunately my > environment is not really set up to debug the erlang runtime. > > BIF_RETTYPE localtime_to_universaltime_2(BIF_ALIST_2); > > Cheers, > Bryan > > -- > > Bryan Hughes > CTO and Founder / *Go Factory* > http://www.go-factory.net > > > > > _______________________________________________ > erlang-questions mailing listerlang-questions@REDACTED://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 jose.valim@REDACTED Fri Jan 25 17:34:21 2013 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Fri, 25 Jan 2013 09:34:21 -0700 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> <510279C4.9000000@ninenines.eu> Message-ID: Since there has been some discussion about "real" code, I can provide some. The extract below comes the latest project I am working on and it was extracted from a gen server. Gen servers are spawned by a simple one by one supervisor and each represents a building. The gen server needs to keep track of: 1. How many people (i.e. users) are in the building overall; 2. And how many of those users are on each level. Users in the same building can comunicate with each other via codes and each code is tied to a socket pid; 3. The users dict in state contains a user_id -> #user relation. And the levels dict in state contains a level_id -> [user_id] relation (I am keeping this as a reverse index instead of a levels list inside each user because this is how I access this data); -record(state, { levels=dict:new(), users=dict:new(), review=30000, company_id=undefined }). -record(user, { codes=dict:new() }). -record(code, { pid=nil, counter=0 }). There is more information in the system but that is in a database because the gen server does not care about it. The state record is what is passed around gen server callbacks. As Lo?c previously said, I like to treat all the information above as data. If the user gets a new code, I would like to simply add it to the codes dictionary in the user. This is how it looks like: User1 = User#user{ codes=dict:store(Code, #code{pid=Pid}, User#user.codes) }, Users1 = dict:store(UserId, User1, Users), { reply, ok, State#state{users=Users1} }. And that is because the snippet above is *not* showing how the User, Users and Code variables were retrieved. Indeed, it could be much better and we don't even need to compare with PHP, which contains mutable data structures. For instance, Clojure provides an assoc_in[1] (and related functions) that would allow me to write all of this as: { reply, ok, assoc_in(State, [users, UserId, codes], Code, #code{pid=Pid}) } Which is similar to what the kvc project does. Others have mentioned lenses as well. My point is that it seems to be a common issue and others seem to be looking for (or have found) a streamlined solution, which they can present and introduce to developers using and learning the language. [1]: http://clojuredocs.org/clojure_core/1.2.0/clojure.core/assoc-in *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From micheus@REDACTED Fri Jan 25 17:43:30 2013 From: micheus@REDACTED (Micheus) Date: Fri, 25 Jan 2013 14:43:30 -0200 Subject: [erlang-questions] A function as an element of a list of action Message-ID: Hi there, I did a google search but I couldn't find anything appropriated or I didn't know how to ask about that. I would like to generate a list (based in some criterias - so, it can be variable) in which each element is an function to be called posteriorly. Something like a "script". These functions will receive the same parameters. I have an list of "fields" that tell me what I need to do (function to call) . What I'm looking for is something like this: +----------------------------------------------------------------------------------------+ : Lf=[{density,{true,Value}}, {ws,{trueValue}}, {hs,{trueValue}}, ... ,{he,{trueValue}}], : Lc=lists:foldl( fun({density,{true,Value}}, Dict) -> Dict0=dict:store(top, calc_top/1, Dict); Dict1=dict:store(bottom, calc_bottom/1, Dict0); dict:store(side, calc_side/1, Dict1); ({bf,{true,Value}}, Acc) -> Dict0=dict:store(bottom, calc_bottom/1, Dict); dict:store(side, calc_side/1, Dict1); ({sf,{true,Value}}, Acc) -> dict:store(side, calc_side/1, Dict); : (_, Dict) -> Dict dict:new(), Lf), dict:fold(_Key, Func, Params0) -> Func(Params0) Params, Lc), : +----------------------------------------------------------------------------------------+ Does someone can help me? TIA Micheus -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Fri Jan 25 17:51:53 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 25 Jan 2013 08:51:53 -0800 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <5102680F.1030108@ninenines.eu> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> Message-ID: <20130125165039.GA68598@ferdmbp.local> On 01/25, Lo?c Hoguin wrote: > *Data*. Not code. Access. Update. That's all that's needed. Alright, here's a 15 minutes attempt at getting some monster design working based on tuple lists, but any data structure that's dynamic enough (not records) would probably do. No benchmarking, no testing, but you can pretty much use lists of accessors in verbose manner, but less verbose than your usual dictionary or k/v use. Here's how the code is used (I used terrible function names on purpose!): test() -> %% build Char1 = '='('='('='('='('0'(), [name], karl), [current,weapon,points], 10), [current,weapon,name], "crappy sword"), [stats, level], 3), Skills = '='('='('='('0'(), [strength], 12), [charisma], 7), [luck], 3), Char = '='(Char1, [stats,skills], Skills), %% read [{strength, '?'(Char, [stats,skills,strength])}, {item, {'?'(Char, [current,weapon,name]), '?'(Char, [current,weapon,points])}}, {damage, '?'(Char, [current,weapon,points]) * '?'(Char, [stats,skills,strength]) + '?'(Skills, [luck])} ]. '='/3 sets fields, '?'/2 reads from them. Note that you can either build everything from the top level (Like 'Char1' does) or do it in incremental steps (the way 'Skills' is done). Fetching respects the same concept. And here's the output: 1> hubble:test(). [{strength,12}, {item,{"crappy sword",10}}, {damage,123}] That seems to work. And here's the code -module(hubble). -export(['0'/0, '='/3, '?'/2]). -export([test/0]). '0'() -> []. '='(L, Fields, Val) -> set(L, Fields, Val). '?'(L, Fields) -> fetch(L, Fields). set([], [K], V) -> [{K,V}]; set(L, [K], V) -> lists:keystore(K, 1, L, {K,V}); set(L, [K|T], V) -> case lists:keyfind(K, 1, L) of false -> lists:keystore(K, 1, L, {K, set([], T, V)}); {K,Old} -> lists:keyreplace(K, 1, L, {K, set(Old, T, V)}) end. fetch(L, [K]) -> case lists:keyfind(K, 1, L) of false -> undefined; {K,V} -> V end; fetch(L, [H|T]) -> {H, L2} = lists:keyfind(H, 1, L), fetch(L2,T). Basic list functionality with a tiny wrapper, no parse transform, usable as a library over any k/v data type today. There's probably a connection to be made to jlouis' lenses in how this is organized. I'm guessing someone with more than 15 minutes could probably make a decent parse transform out of it, overload some syntax or whatever and get it to a more usable/pretty level. The mechanism seems to generaly work, though. Regards, Fred. From mononcqc@REDACTED Fri Jan 25 17:55:06 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 25 Jan 2013 08:55:06 -0800 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <5102680F.1030108@ninenines.eu> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> Message-ID: <20130125165505.GB79682@ferdmbp.local> On 01/25, Lo?c Hoguin wrote: > *Data*. Not code. Access. Update. That's all that's needed. Alright, here's a 15 minutes attempt at getting some monster design working based on tuple lists, but any data structure that's dynamic enough (not records) would probably do. No benchmarking, no testing, but you can pretty much use lists of accessors in verbose manner, but less verbose than your usual dictionary or k/v use. Here's how the code is used (I used terrible function names on purpose!): test() -> %% build Char1 = '='('='('='('='('0'(), [name], karl), [current,weapon,points], 10), [current,weapon,name], "crappy sword"), [stats, level], 3), Skills = '='('='('='('0'(), [strength], 12), [charisma], 7), [luck], 3), Char = '='(Char1, [stats,skills], Skills), ???????? %% read [{strength, '?'(Char, [stats,skills,strength])}, {item, {'?'(Char, [current,weapon,name]), '?'(Char, [current,weapon,points])}}, {damage, '?'(Char, [current,weapon,points]) * '?'(Char, [stats,skills,strength]) + '?'(Skills, [luck])} ]. '='/3 sets fields, '?'/2 reads from them. Note that you can either build everything from the top level (Like 'Char1' does) or do it in incremental steps (the way 'Skills' is done). Fetching respects the same concept. And here's the output: 1> hubble:test(). [{strength,12}, {item,{"crappy sword",10}}, {damage,123}] That seems to work. And here's the code -module(hubble). -export(['0'/0, '='/3, '?'/2]). -export([test/0]). ???? '0'() -> []. ???? '='(L, Fields, Val) -> set(L, Fields, Val). ???? '?'(L, Fields) -> fetch(L, Fields). ???? set([], [K], V) -> [{K,V}]; set(L, [K], V) -> lists:keystore(K, 1, L, {K,V}); set(L, [K|T], V) -> case lists:keyfind(K, 1, L) of false -> lists:keystore(K, 1, L, {K, set([], T, V)}); {K,Old} -> lists:keyreplace(K, 1, L, {K, set(Old, T, V)}) end. ???? fetch(L, [K]) -> case lists:keyfind(K, 1, L) of false -> undefined; {K,V} -> V end; fetch(L, [H|T]) -> {H, L2} = lists:keyfind(H, 1, L), fetch(L2,T). Basic list functionality with a tiny wrapper, no parse transform, usable as a library over any k/v data type today. There's probably a connection to be made to jlouis' lenses in how this is organized. I'm guessing someone with more than 15 minutes could probably make a decent parse transform out of it, overload some syntax or whatever and get it to a more usable/pretty level. The mechanism seems to generaly work, though. Regards, Fred. From pan@REDACTED Fri Jan 25 18:55:11 2013 From: pan@REDACTED (Patrik Nyblom) Date: Fri, 25 Jan 2013 18:55:11 +0100 Subject: [erlang-questions] Erlang VM Crash and Heart doesn't restart In-Reply-To: References: Message-ID: <5102C6FF.9060907@erlang.org> Hi! On 01/22/2013 04:38 PM, Eric Boyer wrote: > Hi there, > > We're running R15B02 on Windows Server 2008 R2 on a mainly IO bound > application. Occasionally when it get busy processing hundreds of > files it will crash with the following event log entry: > > Faulting application name: erl.exe, version: 0.0.0.0, time stamp: > 0x504492cf > Faulting module name: beam.smp.dll, version: 0.0.0.0, time stamp: > 0x50449201 > Exception code: 0xc0000005 > Fault offset: 0x00000000000c75f2 > Faulting process id: 0x9d3c > Faulting application start time: 0x01cdf82413c26aeb > > There is no erl_crash.dump generated and the heart process does not > restart the vm. Are there any ideas as to why this is happening or > what can be done so that heart can properly restart the vm? I see the > heart.exe process active with the correct pid for the erlang process > but it doesn't seem to work in this case. > Is the erl process still running? Windows has a tendency to try to start a debugger or wait for you to meditate over if you want to send a bug report to Microsoft or whatnot. If the process does not really stop, heart can not detect that it's dead immediately (as it is not dead). Then it would wait for timeout. However, after the timeout it ought to try starting a new vm (after trying to kill the process, which ultimately fails if Windows has set the process in "Debugged"-mode). If you start the Erlang node in a windows command shell, you should see what Heart tries to do. It may be that the new node cannot be started because of a distribution name conflict, in which case your heart-command could try to unregister the nodename from epmd prior to restarting the node. You should also try to run erlang:halt() in your Erlang node to verify that the heart command really works. To force unregister on epmd, epmd has to be started with the flag -relaxed_command_check to begin with (so it has to be started manually before starting the erlang node), then do epmd -stop before starting the new Erlang node. This looks like the VM crashing in a bad way, so it would be nice if you could install a debugger on the system and connect it as a just in time debugger, then mail me the stackdump or something. I usually use Windbg, which is included in the Microsoft SDK. If you run "Windbg -I" it installs itself as a just-in-time debugger and you could possibly get a look at erl.exe's stack at the point where it fails. I recommend adding this in "File->Synmbol File Path": SRV*c:\SymbolCache*http://msdl.microsoft.com/download/symbols; after creating the directory c:\SymbolCache, otherwise you will get corrupted stacks when you look into windows own code and the stacks of Erlangs threads will often be unreadable. > Thanks, > Eric > Cheers, /Patrik > Additional Information: > > vm.args is: > > ## Name of the node > -name > > ## Cookie for distributed erlang > -setcookie > > ## Heartbeat management; auto-restarts VM if it dies or becomes > unresponsive > ## (Disabled by default..use with caution!) > -heart > > ## Enable kernel poll and a few async threads > +K true > +A 32 > +P 1000000 > > ## Increase number of concurrent ports/sockets > -env ERL_MAX_PORTS 100000 > > ## Tweak GC to run more often > -env ERL_FULLSWEEP_AFTER 10 > > > os:getenv("HEART_COMMAND") returns: > > %node_root%\bin\%node_name%.cmd start > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From heinz@REDACTED Fri Jan 25 19:13:14 2013 From: heinz@REDACTED (Heinz Nikolaus Gies) Date: Fri, 25 Jan 2013 19:13:14 +0100 Subject: [erlang-questions] open_port and raw mode (zlogin) Message-ID: <3D11C3B4-3231-44DA-8F3D-8FD8A414BA8D@licenser.net> Hi everyone, I am trying to get Erlang to talk to (solarises) zlogin. I figured, open_port would be the logical step to do that BUT it dies horribly the command I run is: open_port({spawn, "/usr/sbin/zlogin -C 8e3b630b-d18a-4047-bad3-600b17d9ef46"}, [use_stdio]). also experimented with other port options but they don't' really make a difference safe for nouse_stdio which replaces the Erlang console with the zlogin one (which doesn't help much ;) the error I get from zlogin is: (chunter@REDACTED)8> open_port({spawn, "/usr/sbin/zlogin -C 8e3b630b-d18a-4047-bad3-600b17d9ef46"}, [use_stdio]). zlogin: failed to get user terminal settings: Invalid argument zlogin: failed to set stdin pty to raw mode: Invalid argument I've tracked down that a bit further into the zlogin code and it seems to be related to a call to tcgetattr(fd, &term) in the code which fails with the open_socket created connection. I'm a bit at a loss here what to do next sadly, any advice? Regards, Heinz -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pan@REDACTED Fri Jan 25 19:16:18 2013 From: pan@REDACTED (Patrik Nyblom) Date: Fri, 25 Jan 2013 19:16:18 +0100 Subject: [erlang-questions] Interesting issue... In-Reply-To: References: <50F58AD2.6010400@go-factory.net> <5102AE68.7090103@erlang.org> Message-ID: <5102CBF2.6040002@erlang.org> Hi! On 01/25/2013 05:23 PM, Pierre Fenoll wrote: > Tried it on R15B03 on my MacBook Air (Indochina Time) and got no > exception. > The issue cannot be reproduced on R15B03. > Great, then I close the issue, as I cannot reproduce it in any timezone lacking DST in recent releases. It seems to have been fixed by a patch mending some general issues with time on BSD. Thanks, /Patrik > On 25 January 2013 17:10, Patrik Nyblom > wrote: > > Hi! > > This ought to be fixed already in R15B03, can you please verify > that it's not present there? I can only reproduce it in R15B01 and > prior releases. > > Cheers, > /Patrik > > > On 01/15/2013 05:58 PM, Bryan Hughes wrote: >> Hi Everyone, >> >> I already submitted this to erlang-bugs@REDACTED >> , but figured others might be >> interested. I found an interesting issue while traveling and >> working through Thailand. I have been able to reproduce it on my >> MacBook Pro using R15B01, built from source. >> >> 1. Set your date to Indochina Time. >> 2. In the shell, try executing: >> calendar:local_time_to_universal_time_dst({{2012,12,3},{8,48,42}}). >> >> Here is the exception that I am getting. Note that the date is a >> validate datetime. >> >> Eshell V5.9.1 (abort with ^G) >> 1> >> calendar:local_time_to_universal_time_dst({{2012,12,3},{8,48,42}}). >> ** exception error: bad argument >> in function erlang:localtime_to_universaltime/2 >> called as >> erlang:localtime_to_universaltime({{2012,12,3},{8,48,42}},true) >> in call from calendar:local_time_to_universal_time_dst/1 >> (calendar.erl, line 282) >> >> When I set my date back to Pacific time, it works without any >> problem -- you can switch it back and forth while in the shell >> and either get the exception, or the correct output. >> >> I was able to isolate it to function the bif.c function, >> unfortunately my environment is not really set up to debug the >> erlang runtime. >> >> BIF_RETTYPE localtime_to_universaltime_2(BIF_ALIST_2); >> >> Cheers, >> Bryan >> >> -- >> >> Bryan Hughes >> CTO and Founder / *Go Factory* >> http://www.go-factory.net >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> 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 Fri Jan 25 19:16:24 2013 From: g@REDACTED (Garrett Smith) Date: Fri, 25 Jan 2013 12:16:24 -0600 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <20130125165039.GA68598@ferdmbp.local> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> <20130125165039.GA68598@ferdmbp.local> Message-ID: On Fri, Jan 25, 2013 at 10:51 AM, Fred Hebert wrote: > > On 01/25, Lo?c Hoguin wrote: >> *Data*. Not code. Access. Update. That's all that's needed. > > Alright, here's a 15 minutes attempt at getting some monster design > working based on tuple lists, but any data structure that's dynamic > enough (not records) would probably do. No benchmarking, no testing, > but you can pretty much use lists of accessors in verbose manner, but > less verbose than your usual dictionary or k/v use. Let's compare this: Strength = '?'(Char, [stats,skills,strength])} to this: Strength = Char.stats.skills.strength Now, which would a beginner prefer? The first version is *terrifying*. And if the programmer *could* brave the syntax, what about all that extra typing?? Just looking at that code makes my fingers tired :( That's why Ruby is #2 on github language ranks and Erlang isn't even in the top 10! [1] Imagine the boundless creativity Erlang will never harness because it's so hard to navigate deeply nested data structures using dots! Or course this is absurd. But it's the basis of this thread. The debate has become how we should represent a particular operation, when in Erlang, it should be clear -- you use a function: get_strength(Char) and if that contract is overly specific: get_attr(strength, Char) Inside that function you can do whatever want. The function is a contract. It's easy to type, easy to read, easy to use. You want to update? set_attr(strength, "muscley", Char) So, a game developer has a requirement to easily and efficiently navigate a deeply nested data structure, and optionally apply transformations along the way. [2] Okay, that's the requirement. Erlang term manipulation can *conceivably* be used for that, but upon casual inspection, it's *obviously* not well suited. I offhand don't know what is best suited as an implementation. It's an engineering problem. But I do know that however it's implemented, gaming programmers should not be exposed to those details. They should get a simple, easy to use interface. If Erlang functions are too painful or otherwise unnatural to use, create a DSL. With a DSL, game programmers can use whatever syntax they care to invent. And you can plug in engines behind that interface as you see fit. Depending on the performance, scalability, and reliability requirements, the implementation of this gaming infrastructure could be wildly different, of course. Here are some other ways you *could* implement the game-engine-state-problem described: - ets/dets - Relational database (SQLite, MySQL, PostreSQL) - Graph database (I only know of Neo4J, but Erlang talks to Java) - Redis - Riak - Some crazy heap navigator in C over a port -- or a NIF! - Python + ErlPort - Embedded Lua with an R backend -- go crazy!! Whatever. It all sits behind an interface that is clear, simple, even fun! Now, as far as using Erlang to create DSLs, I think you have an interesting topic. [3] Garrett [1] https://github.com/languages [2] I'm reminded of the coding horror that is jQuery [3] I'd point to Eric Merrit's outstanding with with Joxa (http://joxa.org) as an example of what can be done with core Erlang and the Erlang tool chain From pan@REDACTED Fri Jan 25 19:23:41 2013 From: pan@REDACTED (Patrik Nyblom) Date: Fri, 25 Jan 2013 19:23:41 +0100 Subject: [erlang-questions] open_port and raw mode (zlogin) In-Reply-To: <3D11C3B4-3231-44DA-8F3D-8FD8A414BA8D@licenser.net> References: <3D11C3B4-3231-44DA-8F3D-8FD8A414BA8D@licenser.net> Message-ID: <5102CDAD.2080005@erlang.org> Hi! On 01/25/2013 07:13 PM, Heinz Nikolaus Gies wrote: > Hi everyone, > I am trying to get Erlang to talk to (solarises) zlogin. I figured, > open_port would be the logical step to do that BUT it dies horribly > the command I run is: > > open_port({spawn, "/usr/sbin/zlogin -C > 8e3b630b-d18a-4047-bad3-600b17d9ef46"}, [use_stdio]). > > also experimented with other port options but they don't' really make > a difference safe for nouse_stdio which replaces the Erlang console > with the zlogin one (which doesn't help much ;) > > the error I get from zlogin is: > > (chunter@REDACTED )8> > open_port({spawn, "/usr/sbin/zlogin -C > 8e3b630b-d18a-4047-bad3-600b17d9ef46"}, [use_stdio]). > zlogin: failed to get user terminal settings: Invalid argument > zlogin: failed to set stdin pty to raw mode: Invalid argument > > I've tracked down that a bit further into the zlogin code and it seems > to be related to a call to tcgetattr(fd, &term) in the code which > fails with the open_socket created connection. > > I'm a bit at a loss here what to do next sadly, any advice? > It seems zlogin expects a terminal as stdin, but if you open_port, stdin for the program will be a pipe, which you cannot do tcgetattr on. You will need to either find an option to zlogin that expects input from something not a terminal, or create a wrapper program that creates a pty , starts zlogin and forwards data from/to the pty and the pipe (which would be some hacking, but not impossible, that's basically what run_erl does, but to/from a named pipe - possibly there's already a program out there doing that, maybe someone on the list can enlighten us :)) > Regards, > Heinz > Cheers, /Patrik > > > _______________________________________________ > 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 Jan 25 19:26:52 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 25 Jan 2013 10:26:52 -0800 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> <20130125165039.GA68598@ferdmbp.local> Message-ID: <20130125182650.GA84348@ferdmbp.local> On 01/25, Garrett Smith wrote: > Let's compare this: > > Strength = '?'(Char, [stats,skills,strength])} > > to this: > > Strength = Char.stats.skills.strength > > Now, which would a beginner prefer? The first version is *terrifying*. > And if the programmer *could* brave the syntax, what about all that > extra typing?? Just looking at that code makes my fingers tired :( > > That's why Ruby is #2 on github language ranks and Erlang isn't even > in the top 10! [1] Of course it's terrible. It's a 15 minutes attempt to show it's doable to navigate deeply nested data structures. I might as realistically make a function that accepts: Char = set(new, stats,skills,strength, 50) Strength = get(Char, stats,skills,strength) by using parse transforms (you can get list of args and redistribute them the way you want, iirc), using my module from the previous e-mail as the underlying representation. This can be done as a blind replacement, without any new support from the language, with currently existing tools, and work on pretty much any reasonable depth. Someone just has to go through the trouble of doing it. Plus you could automatically change representations by having different parse transforms. One for tuple lists, one for dicts, one for ETS, whatever you feel like. These two versions are not significantly annoying -- they don't even need annotations for types or pointers or whatever the way many languages would need them. Clearly they would be concise enough. There are reasons for Erlang to not be that used, but accessors for deep data structures are likely not the most important part of it. I'd probably bet on the difficulty to translate algorithms that assume O(1) access to hashes or arrays, with destructive updates, as a significant barrier of entries with far fewer easy workarounds. That's all speculation anyway. Regards, Fred. From g@REDACTED Fri Jan 25 19:34:44 2013 From: g@REDACTED (Garrett Smith) Date: Fri, 25 Jan 2013 12:34:44 -0600 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <20130125182650.GA84348@ferdmbp.local> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> <20130125165039.GA68598@ferdmbp.local> <20130125182650.GA84348@ferdmbp.local> Message-ID: On Fri, Jan 25, 2013 at 12:26 PM, Fred Hebert wrote: > On 01/25, Garrett Smith wrote: >> Let's compare this: >> >> Strength = '?'(Char, [stats,skills,strength])} >> >> to this: >> >> Strength = Char.stats.skills.strength >> >> Now, which would a beginner prefer? The first version is *terrifying*. >> And if the programmer *could* brave the syntax, what about all that >> extra typing?? Just looking at that code makes my fingers tired :( >> >> That's why Ruby is #2 on github language ranks and Erlang isn't even >> in the top 10! [1] > > Of course it's terrible. It's a 15 minutes attempt to show it's doable > to navigate deeply nested data structures. I might as realistically make > a function that accepts: > > Char = set(new, stats,skills,strength, 50) > Strength = get(Char, stats,skills,strength) Indeed, I was just using your code as a straw man :) When chaining operations like that, I too use lists. It's the natural thing to do in Erlang for that case I think. -snip- > There are reasons for Erlang to not be that used, but accessors for deep > data structures are likely not the most important part of it. I'd > probably bet on the difficulty to translate algorithms that assume O(1) > access to hashes or arrays, with destructive updates, as a significant > barrier of entries with far fewer easy workarounds. > > That's all speculation anyway. Precisely! Garrett From erlang@REDACTED Fri Jan 25 20:17:35 2013 From: erlang@REDACTED (Erik Reitsma) Date: Fri, 25 Jan 2013 20:17:35 +0100 Subject: [erlang-questions] Erlang4Android In-Reply-To: <4e641416-f21c-4dcb-addf-9cf38a1e6d4e@googlegroups.com> References: <50F313AE.8050303@ernovation.com> <4e641416-f21c-4dcb-addf-9cf38a1e6d4e@googlegroups.com> Message-ID: <5102DA4F.2000506@ernovation.com> Hi, I am using this script to set environment variables, in order to use the Android Arm toolchain: export TOOLCHAIN_ROOT=/home/user/android-ndk/toolchains/arm-linux-androideabi-4.7 export erl_xcomp_sysroot=${TOOLCHAIN_ROOT}/sysroot export CROSS_COMPILE=arm-linux-androideabi- export CC=${TOOLCHAIN_ROOT}/bin/${CROSS_COMPILE}gcc export CXX=${TOOLCHAIN_ROOT}/bin/${CROSS_COMPILE}g++ export SHLIB_LD=${TOOLCHAIN_ROOT}/bin/${CROSS_COMPILE}gcc export LD=${TOOLCHAIN_ROOT}/bin/${CROSS_COMPILE}ld export AR=${TOOLCHAIN_ROOT}/bin/${CROSS_COMPILE}ar export RANLIB=${TOOLCHAIN_ROOT}/bin/${CROSS_COMPILE}ranlib export CFLAGS= export LDFLAGS="" export ERLANDROID_ROOT=`pwd` export ERL_TOP=`pwd`/otp_src_R15B03 And then I configure using: ./configure --prefix=/tmp/arm_erlang --with-ssl=/home/user/openssl/openssl-android-master --without-java --disable-hipe --without-termcap --disable-smp-support --host=arm-linux-androideabi --build=i686-pc-linux-gnu Note that I have compiled openssl for Android. If you do not need it, you can disable openssl by using --without-ssl Then I compile using: TARGET=arm-linux-androideabi make noboot -j12 TARGET=arm-linux-androideabi ./otp_build release -a ${ERLANDROID_ROOT}/arm_erlang_R15B03_rel That gives me a directory arm_erlang_R15B03_rel with the compiled Erlang/OTP. This directory contains a script Install, which you should call with appropriate arguments. I call it like this: ./Install -cross -minimal /data/data/com.ernovation.erlangforandroid/files/erlang Anyway, you are right that the cross compiler finds the Android NDK's lib/include from erl_xcomp_sysroot. On 01/25/2013 07:05 PM, Dongsheng Wang wrote: > > hi, Erik, > > I have been trying to cross compile erlang for Android as well. I am > working on a Mac here. Question about the your configure script: > > http://code.google.com/p/erlang4android/downloads/detail?name=otp_src_R15B03.android.tgz&can=2&q= > > How does the cross compiler find the Android NDK's lib/include? I am > guessing it is using > > erl_xcomp_sysroot=${TOOLCHAIN_ROOT}/sysroot > > Some now, but could not figure out how. > > ds *Erik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.james.barry@REDACTED Fri Jan 25 20:39:46 2013 From: paul.james.barry@REDACTED (Paul Barry) Date: Fri, 25 Jan 2013 19:39:46 +0000 Subject: [erlang-questions] Erlang Intro Presentation In-Reply-To: <51029F54.5080103@gmail.com> References: <017901cdfb0a$2581ca00$70855e00$@gmail.com> <51029F54.5080103@gmail.com> Message-ID: Hi. Here's a set of slides from my October 2011 PyCon Ireland talk (which I also gave as an O'Reilly Webcast in June of that year): paulbarry.itcarlow.ie/ErlangWebcast.pdf And if you don't feel like talking, here's a video of me actually giving the talk: http://vimeo.com/groups/pyconireland/videos/32045208 - it's about 30 minutess long. I also have the slides (in OpenOffice format) if you want to take them and amend to your purposes. Email me off-list and I'll send them onto you. Regards. Paul. On 25 January 2013 15:05, Loris Fichera wrote: > Hey David, > > > On 01/25/2013 03:42 PM, David Mercer wrote: > >> This comes up a couple of times a year, so thought I would send out >> another to see if anyone has any recommendations for >> intro-to-Erlang?type presentations that can be presented to a technical >> team of non-Erlangers during lunch sort of thing. I can come up with my >> own?and I have searched Google and come up with a bunch?but since this >> does come up periodically on this list, I figure others have done all >> the Google research more thoroughly recently, and I wanted to tap your >> brains for the state of the art Erlang presentation. >> > > Did you have a look at Roberto Aloi's "Why you should build your next > application in Erlang" talk? > > https://speakerdeck.com/**robertoaloi/why-you-should-** > build-your-next-application-**in-erlang > > Cheers, > > --Loris. > > > ______________________________**_________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/**listinfo/erlang-questions > -- Paul Barry, w: http://paulbarry.itcarlow.ie - e: paul.barry@REDACTED Lecturer, Computer Networking: Institute of Technology, Carlow, Ireland. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy@REDACTED Fri Jan 25 21:08:28 2013 From: jeremy@REDACTED (Jeremy Ong) Date: Fri, 25 Jan 2013 12:08:28 -0800 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> <20130125165039.GA68598@ferdmbp.local> <20130125182650.GA84348@ferdmbp.local> Message-ID: I work at a game-development studio so I can chime in on some of this. First, real world data =/= designed data. What I mean by this is that real world data (mined from measurements or analytics or something) tends to fit certain patterns and have even levels of nesting, so that something like nested proplists or dicts can be easy to reason about. Once we are referring to data that pertains to game data, the data isn't "nice" anymore. To take Loic's example: suppose I design a character to have an arsenal of weapons. When I initially implement this, a flat data structure is fine. Later however, design changes, and now some weapons (not all) can be outfitted with a weapon add-on, like a scope or laser sight. Other weapons can be upgraded. A future design might even allow for the scope itself to be upgraded. Coming up with a way to represent this in Erlang such that it can be *flexibly* expanded on without changing api and implementation everywhere is very difficult. I can say that nested proplists and dicts and lists are very cumbersome to work with because there are no enforced contracts with the developer. Incidentally, I can understand why bringing up OO ruffles feathers, but what is wrong about discussing how to represent objects themselves? Personally, I wish something like C-structs were available I suppose. The fact is, sometimes, data is deeply nested, and we should be able to talk about nested representations for them (with convenient accessors). On Fri, Jan 25, 2013 at 10:34 AM, Garrett Smith wrote: > On Fri, Jan 25, 2013 at 12:26 PM, Fred Hebert wrote: > > On 01/25, Garrett Smith wrote: > >> Let's compare this: > >> > >> Strength = '?'(Char, [stats,skills,strength])} > >> > >> to this: > >> > >> Strength = Char.stats.skills.strength > >> > >> Now, which would a beginner prefer? The first version is *terrifying*. > >> And if the programmer *could* brave the syntax, what about all that > >> extra typing?? Just looking at that code makes my fingers tired :( > >> > >> That's why Ruby is #2 on github language ranks and Erlang isn't even > >> in the top 10! [1] > > > > Of course it's terrible. It's a 15 minutes attempt to show it's doable > > to navigate deeply nested data structures. I might as realistically make > > a function that accepts: > > > > Char = set(new, stats,skills,strength, 50) > > Strength = get(Char, stats,skills,strength) > > Indeed, I was just using your code as a straw man :) > > When chaining operations like that, I too use lists. It's the natural > thing to do in Erlang for that case I think. > > -snip- > > > There are reasons for Erlang to not be that used, but accessors for deep > > data structures are likely not the most important part of it. I'd > > probably bet on the difficulty to translate algorithms that assume O(1) > > access to hashes or arrays, with destructive updates, as a significant > > barrier of entries with far fewer easy workarounds. > > > > That's all speculation anyway. > > Precisely! > > Garrett > _______________________________________________ > 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 Jan 25 23:35:02 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Fri, 25 Jan 2013 23:35:02 +0100 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <20130125182650.GA84348@ferdmbp.local> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> <20130125165039.GA68598@ferdmbp.local> <20130125182650.GA84348@ferdmbp.local> Message-ID: <51030896.1080400@ninenines.eu> On 01/25/2013 07:26 PM, Fred Hebert wrote: > On 01/25, Garrett Smith wrote: >> Let's compare this: >> >> Strength = '?'(Char, [stats,skills,strength])} >> >> to this: >> >> Strength = Char.stats.skills.strength >> >> Now, which would a beginner prefer? The first version is *terrifying*. >> And if the programmer *could* brave the syntax, what about all that >> extra typing?? Just looking at that code makes my fingers tired :( >> >> That's why Ruby is #2 on github language ranks and Erlang isn't even >> in the top 10! [1] > > Of course it's terrible. It's a 15 minutes attempt to show it's doable > to navigate deeply nested data structures. I might as realistically make > a function that accepts: > > Char = set(new, stats,skills,strength, 50) > Strength = get(Char, stats,skills,strength) > > by using parse transforms (you can get list of args and redistribute > them the way you want, iirc), using my module from the previous e-mail as > the underlying representation. This can be done as a blind replacement, > without any new support from the language, with currently existing > tools, and work on pretty much any reasonable depth. Someone just has to > go through the trouble of doing it. That's the point: it should be *built into the language*, you shouldn't have to go through the trouble of doing something like this. And it should be *obvious* and in line with the rest of the language. I quite like the xpath idea Darach mentioned. It could integrate very well with the rest of the language. I might experiment with it. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From raould@REDACTED Fri Jan 25 23:37:24 2013 From: raould@REDACTED (Raoul Duke) Date: Fri, 25 Jan 2013 14:37:24 -0800 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <51030896.1080400@ninenines.eu> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> <20130125165039.GA68598@ferdmbp.local> <20130125182650.GA84348@ferdmbp.local> <51030896.1080400@ninenines.eu> Message-ID: please contribute to getting LFE back in motion. $0.02, sincerely. From steven.charles.davis@REDACTED Sat Jan 26 01:13:15 2013 From: steven.charles.davis@REDACTED (Steve Davis) Date: Fri, 25 Jan 2013 16:13:15 -0800 (PST) Subject: [erlang-questions] unexpected result of term_to_binary In-Reply-To: <14CAC446-BBA5-41A1-B2FD-D21593EE1681@cs.otago.ac.nz> References: <1127346428.2964860.1358876148647.JavaMail.root@erlang-solutions.com> <14CAC446-BBA5-41A1-B2FD-D21593EE1681@cs.otago.ac.nz> Message-ID: As ever, the thoughtful comments of ROK+JA+RV have triggered me to dig further to confirm my beliefs and understanding (e.g. in this case "string"->List->Cons->car/cdr->lambda). On Tuesday, January 22, 2013 10:15:56 PM UTC-6, Richard O'Keefe wrote: > > It might be an idea > to rename it to BYTE_LIST_EXT. > > I believe the flag should be called BYTE_ARRAY_EXT. br, /s -------------- next part -------------- An HTML attachment was scrubbed... URL: From darach@REDACTED Sat Jan 26 01:13:27 2013 From: darach@REDACTED (Darach Ennis) Date: Sat, 26 Jan 2013 00:13:27 +0000 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> <20130125165039.GA68598@ferdmbp.local> <20130125182650.GA84348@ferdmbp.local> <51030896.1080400@ninenines.eu> Message-ID: Hi guys, I have no beef with these parse transforms you speak of. But, I haven't used them so will stop at wishing them good health - maybe pencil in a few hours with them as penance for my non-erlangy sins too. :) I think folk new to erlang will likely be familiar with XML Path though. So picking up a variant based on XPath 1.0 would be fairly natural. I'm clutching at straws here, but maybe parse transforms have a role to play here too. I see no reason why Joe's selector couldn't be bound as function in some kind of erlangy xpath for tuples. So we would get something like: P = tpath:scan(X, "/top/a/x/p"). No hints required. The path is explicit. The hints in the parse transform would equate to the following XPath P = tpath:scan(X, "/top//p"). If the structure changed so there was a list of x's and we just want the p from the first occurrence? P = tpath:scan(X, "/top/x[first()]/p"). Maybe I want all p's matched on some guard or filter? P = tpath:scan(X, "/top/x[key =/= 'corba']/p[@a]"). And, maybe parse transforms, funs could be plugged in too ... P = tpath:scan(X, "some_module:some_fun(//p[@a)"). Perhaps I'm stuck with the xpath style bag because it's familiar and I've been using it for ~14 years. The cool young kids might prefer a more jsony selection experience. I could live with that: P = jsony:scan(X, "top.a.x.p"); But this: #top{a=#one{x=#foo{p=P}}} = X I can barely parse it visually. It's too noisy, too busy. Cheers, Darach. On Fri, Jan 25, 2013 at 10:37 PM, Raoul Duke wrote: > please contribute to getting LFE back in motion. > $0.02, > sincerely. > _______________________________________________ > 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 Sat Jan 26 03:26:01 2013 From: ok@REDACTED (ok@REDACTED) Date: Sat, 26 Jan 2013 15:26:01 +1300 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <5102680F.1030108@ninenines.eu> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> Message-ID: >> >> Lo?c Hoguin wrote: >> (1) Please let's have a real concrete example of about 1 page, >> not imaginary one-liners, with names that turn out to be >> not as intention-revealing as they look. > > It's a real concrete example. The one and only example I have seen so far was a one-liner involving an imaginary game. If it isn't an imaginary game, my apologies. But it was still a one liner, and without any context to make it interpretable. > I'm sure you can imagine other examples. I don't want imaginary examples. Like I said, please let's have about a page of code, with enough context to make it intelligible. > Or perhaps you are going to tell me you never had to manage big amounts > of related data in Erlang? (Wouldn't surprise me.) I've had to manage sufficient data for a single run to take days. >> Are we debating whether Person~name, with the same fundamental >> limitation as field access in C or Java or ML, is a really big >> improvement over Person#person_name? >> >> Or has the idea crept in that Person.name might run complex code? > > *Data*. Not code. Access. Update. That's all that's needed. Sigh. But does *CARRYING OUT* that access or update involve running complex code? I mean, fetching a field from a *record* doesn't count as complex code, but fetching an entry from a 'dict' does count as running complex code, way beyond what Person#person.name could do. > Let me tell you something about yourself. > > You are confronted with the problem of wasting a lot of time writing > basement level code to access and update deep values. If confronted with that task, I will refuse to do it. I will _definitely_ do something to generate that code automatically, just as we have leex and yecc and other tools for generating code. > The > DSL still maps to functions which needs to access and update these > values, and that code is still painful to write. Yes, but using a DSL ***means*** that you do not write that code more than once. > Your next step is to > think "Great! Let's generate all that code then!". Now you got three > problems, and you better hope to have not made any error when writing > that code generator or you'll waste a lot more time. I write small-scale task-specific code generators a LOT. It's not quite as easy as falling off a log, but it's easier than, say, getting a complex regular expression right. Yes, I make mistakes when I do this, and yes, I have to test a fair bit. But most of this is testing I would have had to do *anyway* and mistakes I would have made *anyway* except that instead of a mistake being made once, found by one test, and fixed with a single fix, there would have been dozens of copies. > Speaking of time, > by the time you get to that point the PHP developer has already long > finished his bug-free implementation of the same code and is moving on > to other tasks. Does there exist such a thing as a bug-free implementation of anything in PHP? In all seriousness, I use small-scale code generation BECAUSE IT SAVES ME TIME. Coding time, testing time, debugging time. > That's still besides the point. If it's not Character.inventory it's > State.character and State.inventory. Doesn't make updating any easier. Again, I think we have strayed from the original path, which had nothing to do with updating and everything to do with the perceived verbosity of Person#person.name. If you want ease of updating, there's no shame in using F#. From ok@REDACTED Sat Jan 26 03:41:54 2013 From: ok@REDACTED (ok@REDACTED) Date: Sat, 26 Jan 2013 15:41:54 +1300 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <510150CC.90208@ninenines.eu> Message-ID: <066249d4a063d4111e549ae5894a27ce.squirrel@chasm.otago.ac.nz> David Goehrig wrote: > > of(Object,Property) -> proplists:get_value(Property,Object). ... > > of(of(of(Character,weapon),ability),cost). At this point it might be useful to mention R (or rather the S language that R implements). Leaving S4 objects to one side as a distraction, S "objects" are immutable. The rule in S is that f(e1, e2) <- e0 is syntactic sugar for e1 <- 'f<-'(e1, e2, e0) with the rule applied recursively (although I've never seen the details made clear). Even a[i] <- x is just shorthand for a <- '[<-'(a, i, x). Imagine Erlang to be extended with a := operator with the following semantics: var := expr if var is not bound in the current path, var = expr if var is bound, introduce a new variable var', var' = expr, and use var' instead of var downstream At if/case/receive/... termini, reconcile live variables as with a SSA phi-function f(E1,...,En) := E0 rewrite as E1 := 'f:='(E1, ..., En, En) const := expr illegal This would in no way affect the underlying 'no mutable data'/ single assignment nature of Erlang. Indeed, the VM would not be altered in even the slightest way. It's all compile time. Then you could write of(of(of(Character,weapon),ability),cost) := 123 This requires a function 'of:='(Thing, Slot, New_Value). You could also define cost(X) -> of(X, cost). 'cost:='(X, C) -> 'of:='(X, cost, C). ... cost(ability(weapon(Character)) := 123 It's all just pure values and functions underneath. Would _this_ satisfy the complaints? From ok@REDACTED Sat Jan 26 05:04:28 2013 From: ok@REDACTED (ok@REDACTED) Date: Sat, 26 Jan 2013 17:04:28 +1300 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> <510279C4.9000000@ninenines.eu> Message-ID: > Manipulating nested records is a pain - how about this? > > Assume we have three records > > -record(top, {a::#one{}, b::#two{}, c::#three{} }). > -record(one, {x::#foo{}, y::#bar{} }) > -record(foo, {p,q,r}). > and I want to unpack the p field from a variable X containing a top > record. Disagreeing with Joe Armstrong in the Erlang mailing list is rather like arguing with God, but if Honi the circle-drawer (http://www.youtube.com/watch?v=hRfV7XrGfBo) got away with it, maybe I'll survive. Why should I assume that? What does a real example look like? > > I don't want to write > > #top{a=#one{x=#foo{p=P}}} = X I don't mind writing that. Once. In one place. And naming it. Ideally, I'd write #american_express(<{a ~ <{ x ~ <{ p ~ X }>}>}> -> X. but even american_express(AXP) -> AXP#top.a#one.x#foo.p. will do. There's a style guideline I've been feeling my way towards over the last couple of years, and this thread is helping me to clarify it, but I'm not quite there yet. It's something like "no multi-clause construct should cross more than one abstraction layer." I don't count a #state record that merely aggregates a bunch of state variables as an abstraction layer; I do count a record that might escape from the boundaries of its module as an abstraction layer. So I don't _want_ to write AXP.a.x.p because that code frightens me with its fragility. The only x.a.b or x->a->b I could find in a quick find+grep over my own C code on this laptop were two lines in some code to handle doubly linked lists. If I don't do this sort of thing in C, why would I be doing it in Erlang? Just for the sake of pointing out that there _are_ alternatives, let me suggest another approach that could be taken with records. Suppose we spotted that .a.x.p was used often enough to be worth worrying about. We might decide that it was worth storing redundantly. After all, memory references are _expensive_ on modern machines. So let's introduce the notion of a *virtual* field. A virtual field looks just like an ordinary field, except that you cannot update it, and it is computed, not fetched. We'll use Field_Name -> Expression as the syntax, where Expression is a guard expression so that we can still use records in patterns, and may include THIS. Now we define -record(top, { a :: #one{}, b :: #two{}, c :: #three{}, axp -> THIS#top.a#one.x#foo.p }). -record(one, { x :: #foo{}, y :: #bar{} }). -record(foo, { p, q, r }). and use #top(axp = P) = X or P = X#top.axp This code follows the Law of Demeter. After the definitions, the source code no longer assumes very much about #top and *nothing* about #one or #foo, not even that they exist. All it assumes about #top is that a #top record knows how to find .axp *somehow* (and safely). Once the code has been rewritten to use the virtual field, we can change the definition so that the field is stored concretely. (Aside.) Given that I don't like records very much, and invented abstract patterns and frames so that we could get rid of them, I'm not that thrilled that I've just made records do something frames can't do at all. Oh well, this is just an example, not an EEP. (End aside.) (Second aside.) Having warned you that this is just an alternative to prove that alternatives are possible, this _is_ something we could practically do, and it _could_ shorten code, and it _could_ simplify a transition from one representation to another. Maybe it does deserve serious thought. (End second aside.) From ok@REDACTED Sat Jan 26 11:15:07 2013 From: ok@REDACTED (ok@REDACTED) Date: Sat, 26 Jan 2013 23:15:07 +1300 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> <510279C4.9000000@ninenines.eu> Message-ID: I wrote: > So I don't _want_ to write AXP.a.x.p because that code > frightens me with its fragility. The only x.a.b or > x->a->b I could find in a quick find+grep over my own > C code on this laptop were two lines in some code to > handle doubly linked lists. Imagine me with egg all over my face. Somehow that find+grep missed an entire directory, containing a project with lots of code by me and nobody else, containing hundreds of examples of what I said I didn't do. Some of the code is actually benign. It's not *really* spanning multiple records. I have a lot of tagged unions, struct Thingy { enum Thingy_Tag tag; union { int i; Unique_String s; ... } u; } and occurrences of thingy->u.s really count as a single field reference. However, there were also about 300 lines containing foo->bar->ugh and I have spent a couple of hours fixing as many of them as I could. In many cases, the code was (to my mind) simplified and clarified by introducing gvar const o = m->owner; ... o->whatever ... instead of m->owner->whatever, because it turned out that o was actually used several times in a function containing such a double step. Simply, if I was using foo->bar->ugh I was almost always _also_ using foo->bar->zoo and/or plain foo->bar itself. Before C compilers got good at optimising, this change would also have made the object code smaller and faster; even these days, C's aliasing rules probably mean there's some benefit there. I've spotted this in other people's Erlang code too. Function bodies that contain lots of field references can often be shortened (and to my mind simplified) by replacing field references by pattern matching in the head. Of the rest, quite a few would have benefited from virtual fields, had C supported them. Some of the ones that are left would have been simpler and easier for the compiler to type-check had I *not* been using C format strings. (The whole program basically doubled in speed when I stopped using for most I/O; the only stdio code left is for error messages.) But to me the most interesting thing was recalling, as I worked over the code, that these had been the most error prone parts of the program. foo->bar->ugh really _had_ been a warning sign that I had not understood years ago when writing this stuff. Not only that: the foo->bar->ugh antipattern turned up a lot in code that needs a rewrite in order to hold Unicode in certain internal data structures, and I'd been putting that off and putting it off because fixing this stuff was so scary. I hadn't understood _why_ it was scary, but now I think I do. Why has it taken me so long to learn not to be so stupid? From ok@REDACTED Sat Jan 26 11:53:03 2013 From: ok@REDACTED (ok@REDACTED) Date: Sat, 26 Jan 2013 23:53:03 +1300 Subject: [erlang-questions] open_port and raw mode (zlogin) In-Reply-To: <3D11C3B4-3231-44DA-8F3D-8FD8A414BA8D@licenser.net> References: <3D11C3B4-3231-44DA-8F3D-8FD8A414BA8D@licenser.net> Message-ID: <27b5aba65cb4cee5fd825bf5e93a9413.squirrel@chasm.otago.ac.nz> > Hi everyone, > I am trying to get Erlang to talk to (solarises) zlogin. Which wants its standard streams to be connected to a tty or pty. Sadly, while open_port/2 has a 'use_stdio' option, it doesn't have a 'use_pty' option. Is there any reason that it couldn't? I wonder if having Erlang run an expect(1) script that then runs zlogin might do the trick? From darach@REDACTED Sat Jan 26 14:05:52 2013 From: darach@REDACTED (Darach Ennis) Date: Sat, 26 Jan 2013 13:05:52 +0000 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> <510279C4.9000000@ninenines.eu> Message-ID: Hi guys, My apologies for not introducing what a Kaysian transform is. It's basically a technique discovered by Michael Kay (long time XPath / XSLT guy, wrote/leads Saxon) for efficient set intersection and difference with XPath. It's a neat little efficiency trick. It's documented in the following (page 3), with other neat tricks: http://www.xml.org//sites/www.xml.org/files/xslt_efficient_programming_techniques.pdf On the schemey/lispy approach? I like it. If the structures are reasonably stable with respect to change over time then some artful hiding behind accessor functions is good enough. I do it myself for things like gen_server state (accessors) or process options (mutators). I agree with Joe too. If a parse transform compiles away some inefficiency (human or systemic) then that's a better accessor. But would I maintain the structures for a family of complex financial derivative instruments in erlang today and/or represent them as erlang records? No, not with the same accessors and/or code generators I'd be happy to write and use for other isolated tasks. The reason is simple. The number of, complexity of, frequency of change, and continuous arrival and departure of newly invented structures would mean a lot of maintenance and upheaval. It's a significant source of pain in capital markets and the problem is not exclusive to any one language. At some point you're going to end up compromising and accept a certain level of maintenance. So maybe there isn't one perfect solution. Maybe there's a few good partial solutions and each is optimal given a certain presumed level of maintenance. But to presume all environments are dealing with fairly trivial structures like the examples thus far, or that they are few in volume, or that the frequency of change of those structures is low? That is an auto selection problem. I see more than one good approach but no right one here. Cheers, Darach. On Sat, Jan 26, 2013 at 10:15 AM, wrote: > I wrote: > > > > So I don't _want_ to write AXP.a.x.p because that code > > frightens me with its fragility. The only x.a.b or > > x->a->b I could find in a quick find+grep over my own > > C code on this laptop were two lines in some code to > > handle doubly linked lists. > > Imagine me with egg all over my face. > Somehow that find+grep missed an entire directory, > containing a project with lots of code by me and > nobody else, containing hundreds of examples of > what I said I didn't do. > > Some of the code is actually benign. It's not *really* > spanning multiple records. I have a lot of tagged unions, > struct Thingy { > enum Thingy_Tag tag; > union { > int i; > Unique_String s; > ... > } u; > } > and occurrences of thingy->u.s really count as a single > field reference. > > However, there were also about 300 lines containing > foo->bar->ugh and I have spent a couple of hours > fixing as many of them as I could. > > In many cases, the code was (to my mind) simplified > and clarified by introducing > gvar const o = m->owner; > ... o->whatever ... > instead of m->owner->whatever, because it turned out > that o was actually used several times in a function > containing such a double step. Simply, if I was using > foo->bar->ugh I was almost always _also_ using > foo->bar->zoo and/or plain foo->bar itself. Before C > compilers got good at optimising, this change would > also have made the object code smaller and faster; > even these days, C's aliasing rules probably mean there's > some benefit there. > > I've spotted this in other people's Erlang code too. > Function bodies that contain lots of field references > can often be shortened (and to my mind simplified) by > replacing field references by pattern matching in the > head. > > Of the rest, quite a few would have benefited from > virtual fields, had C supported them. Some of the > ones that are left would have been simpler and easier > for the compiler to type-check had I *not* been using > C format strings. (The whole program basically doubled > in speed when I stopped using for most I/O; > the only stdio code left is for error messages.) > > But to me the most interesting thing was recalling, > as I worked over the code, that these had been the > most error prone parts of the program. foo->bar->ugh > really _had_ been a warning sign that I had not > understood years ago when writing this stuff. > > Not only that: the foo->bar->ugh antipattern turned up > a lot in code that needs a rewrite in order to hold > Unicode in certain internal data structures, and I'd > been putting that off and putting it off because fixing > this stuff was so scary. I hadn't understood _why_ it > was scary, but now I think I do. > > Why has it taken me so long to learn not to be so stupid? > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyron.zerafa@REDACTED Sat Jan 26 15:32:19 2013 From: tyron.zerafa@REDACTED (Tyron Zerafa) Date: Sat, 26 Jan 2013 15:32:19 +0100 Subject: [erlang-questions] Variable bindings Message-ID: Does there exist any particular function which would give me all variable bindings (including their values) at that point. For instance, something similar to get_all_bindings (example below) should result in [{X=3},{Y=4}] when called with X=2. my_fun(X) -> Y = X+1, get_all_bindings(). Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From heinz@REDACTED Sat Jan 26 15:34:49 2013 From: heinz@REDACTED (Heinz Nikolaus Gies) Date: Sat, 26 Jan 2013 15:34:49 +0100 Subject: [erlang-questions] open_port and raw mode (zlogin) References: <6E8D16B1-80F0-459C-9C55-1EF1B2CDB7F0@licenser.net> Message-ID: <8F03008B-863D-4CAA-AEF0-6DAB49E4F35B@licenser.net> > > Sadly I'm in a rather constrained environment and don't have the luxury of expect but yea use_pty would be very nice :) - After Patriks suggestion I started experimenting with run_erl as wrapper which generates named pipes for input and output but accessing them didn't work very well for me :/ > > On Jan 26, 2013, at 11:53, ok@REDACTED wrote: > >>> Hi everyone, >>> I am trying to get Erlang to talk to (solarises) zlogin. >> >> Which wants its standard streams to be connected to a tty >> or pty. Sadly, while open_port/2 has a 'use_stdio' option, >> it doesn't have a 'use_pty' option. Is there any reason >> that it couldn't? >> >> I wonder if having Erlang run an expect(1) script that >> then runs zlogin might do the trick? >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ward@REDACTED Sat Jan 26 16:03:16 2013 From: ward@REDACTED (Ward Bekker (TTY)) Date: Sat, 26 Jan 2013 16:03:16 +0100 Subject: [erlang-questions] Understanding memory usage Message-ID: <7EFEA754-B706-4358-8896-6E3D196B99D3@tty.nl> Hi, I run into high memory usage (>1.5GB) when running `crack_util:crack` from this module: https://gist.github.com/4642789 (make sure crypto is running: `crypto:start()`). As far as I can see, it's not creating (or holding on to) huge pieces of data. Why is that? Ward Bekker -------------- next part -------------- An HTML attachment was scrubbed... URL: From aggelgian@REDACTED Sat Jan 26 17:16:14 2013 From: aggelgian@REDACTED (Aggelos Giantsios) Date: Sat, 26 Jan 2013 18:16:14 +0200 Subject: [erlang-questions] Variable bindings In-Reply-To: References: Message-ID: On Sat, Jan 26, 2013 at 4:32 PM, Tyron Zerafa wrote: > Does there exist any particular function which would give me all variable > bindings (including their values) at that point. > > Hello!! I don't think that it's possible to retrieve such information when running compiled code. After all the transformations and optimizations are performed by the compiler, the actual variables in the program may be different form those declared in the source code. For example, consider this code: foo(X) -> Y = X, max(Y, 42). The value of Y will most surely be propagated to its use in max/2 thus eliminating the variable from the final compiled code altogether. So all you could theoretically access at runtime would be the actual variables in the function's call frame in the stack. However, this is done by the erts emulator and I don't believe this is possible from within Erlang code. One way to work around this would be to manually store the bindings, for example, in a dictionary so you can perform lookups at will. However, that means that there would be overhead due to the stores and lookups and also require more memory. Aggelos -------------- next part -------------- An HTML attachment was scrubbed... URL: From g@REDACTED Sat Jan 26 18:37:27 2013 From: g@REDACTED (Garrett Smith) Date: Sat, 26 Jan 2013 11:37:27 -0600 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> <20130125165039.GA68598@ferdmbp.local> <20130125182650.GA84348@ferdmbp.local> <51030896.1080400@ninenines.eu> Message-ID: I suggest spending some time with Joxa... it goes well beyond LFE. On Jan 25, 2013 4:37 PM, "Raoul Duke" wrote: > please contribute to getting LFE back in motion. > $0.02, > sincerely. > _______________________________________________ > 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 Jan 26 19:45:37 2013 From: vinoski@REDACTED (Steve Vinoski) Date: Sat, 26 Jan 2013 13:45:37 -0500 Subject: [erlang-questions] Variable bindings In-Reply-To: References: Message-ID: On Sat, Jan 26, 2013 at 9:32 AM, Tyron Zerafa wrote: > Does there exist any particular function which would give me all variable > bindings (including their values) at that point. For instance, something > similar to get_all_bindings (example below) should result in [{X=3},{Y=4}] > when called with X=2. > > my_fun(X) -> > Y = X+1, > get_all_bindings(). > I don't think anything like that exists, but here's a parse transform that might work for you: https://gist.github.com/4643721 The parse transform looks for a call to get_all_bindings/1 in each function body and replaces its argument with a list of variable names and their bindings used in the function up to that point. The argument to get_all_bindings can be anything because the parse transform replaces it. Example: -module(foo). -export([my_fun/1]). -compile([{parse_transform,get_all_bindings}]). -record(rec, {f1, f2, f3}). my_fun(X) -> Y = X+1, Z = [a,b,c,d,e,{X,Y}], #rec{f1=F1, f2=F2, f3=F3} = #rec{f1=42, f2=[X,Y], f3=Z}, get_all_bindings([]), Q = 32, Q. get_all_bindings(Bindings) -> io:format("~p~n", [Bindings]). The code produced for my_fun/1 by the parse transform looks like this: my_fun(X) -> Y = X + 1, Z = [a, b, c, d, e, {X, Y}], #rec{f1 = F1, f2 = F2, f3 = F3} = #rec{f1 = 42, f2 = [X, Y], f3 = Z}, get_all_bindings([{'Z', Z}, {'Y', Y}, {'X', X}, {'F3', F3}, {'F2', F2}, {'F1', F1}]), Q = 32, Q. Note that Q isn't included in the list because it occurs after the call to get_all_bindings/1. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sat Jan 26 20:51:24 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 26 Jan 2013 20:51:24 +0100 Subject: [erlang-questions] Variable bindings In-Reply-To: References: Message-ID: Hi, An easier way to write this parse transform would be to populate the AST with its bindings with erl_syntax_lib:annotate_bindings/2 and then to fold through the tree with erl_syntax_lib:fold/3 to replace local calls to get_all_bindings/1. Regards, -- Anthony Ramine Le 26 janv. 2013 ? 19:45, Steve Vinoski a ?crit : > > > On Sat, Jan 26, 2013 at 9:32 AM, Tyron Zerafa wrote: > Does there exist any particular function which would give me all variable bindings (including their values) at that point. For instance, something similar to get_all_bindings (example below) should result in [{X=3},{Y=4}] when called with X=2. > > my_fun(X) -> > Y = X+1, > get_all_bindings(). > > I don't think anything like that exists, but here's a parse transform that might work for you: > > https://gist.github.com/4643721 > > The parse transform looks for a call to get_all_bindings/1 in each function body and replaces its argument with a list of variable names and their bindings used in the function up to that point. The argument to get_all_bindings can be anything because the parse transform replaces it. Example: > > -module(foo). > -export([my_fun/1]). > -compile([{parse_transform,get_all_bindings}]). > > -record(rec, {f1, f2, f3}). > > my_fun(X) -> > Y = X+1, > Z = [a,b,c,d,e,{X,Y}], > #rec{f1=F1, f2=F2, f3=F3} = #rec{f1=42, f2=[X,Y], f3=Z}, > get_all_bindings([]), > Q = 32, > Q. > > get_all_bindings(Bindings) -> > io:format("~p~n", [Bindings]). > > The code produced for my_fun/1 by the parse transform looks like this: > > my_fun(X) -> > Y = X + 1, > Z = [a, b, c, d, e, {X, Y}], > #rec{f1 = F1, f2 = F2, f3 = F3} = #rec{f1 = 42, > f2 = [X, Y], f3 = Z}, > get_all_bindings([{'Z', Z}, {'Y', Y}, {'X', X}, > {'F3', F3}, {'F2', F2}, {'F1', F1}]), > Q = 32, > Q. > > Note that Q isn't included in the list because it occurs after the call to get_all_bindings/1. > > --steve > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vinoski@REDACTED Sat Jan 26 21:06:41 2013 From: vinoski@REDACTED (Steve Vinoski) Date: Sat, 26 Jan 2013 15:06:41 -0500 Subject: [erlang-questions] Variable bindings In-Reply-To: References: Message-ID: Hi Anthony, thanks for letting me know -- I'll need to try that. I've never played with erl_syntax_lib before. I also realized the current version doesn't handle nested anonymous functions, so I'll need to fix that too. --steve On Sat, Jan 26, 2013 at 2:51 PM, Anthony Ramine wrote: > Hi, > > An easier way to write this parse transform would be to populate the AST > with its bindings with erl_syntax_lib:annotate_bindings/2 and then to > fold through the tree with erl_syntax_lib:fold/3 to replace local calls > to get_all_bindings/1. > > Regards, > > -- > Anthony Ramine > > Le 26 janv. 2013 ? 19:45, Steve Vinoski a ?crit : > > > > > > > On Sat, Jan 26, 2013 at 9:32 AM, Tyron Zerafa > wrote: > > Does there exist any particular function which would give me all > variable bindings (including their values) at that point. For instance, > something similar to get_all_bindings (example below) should result in > [{X=3},{Y=4}] when called with X=2. > > > > my_fun(X) -> > > Y = X+1, > > get_all_bindings(). > > > > I don't think anything like that exists, but here's a parse transform > that might work for you: > > > > https://gist.github.com/4643721 > > > > The parse transform looks for a call to get_all_bindings/1 in each > function body and replaces its argument with a list of variable names and > their bindings used in the function up to that point. The argument to > get_all_bindings can be anything because the parse transform replaces it. > Example: > > > > -module(foo). > > -export([my_fun/1]). > > -compile([{parse_transform,get_all_bindings}]). > > > > -record(rec, {f1, f2, f3}). > > > > my_fun(X) -> > > Y = X+1, > > Z = [a,b,c,d,e,{X,Y}], > > #rec{f1=F1, f2=F2, f3=F3} = #rec{f1=42, f2=[X,Y], f3=Z}, > > get_all_bindings([]), > > Q = 32, > > Q. > > > > get_all_bindings(Bindings) -> > > io:format("~p~n", [Bindings]). > > > > The code produced for my_fun/1 by the parse transform looks like this: > > > > my_fun(X) -> > > Y = X + 1, > > Z = [a, b, c, d, e, {X, Y}], > > #rec{f1 = F1, f2 = F2, f3 = F3} = #rec{f1 = 42, > > f2 = [X, Y], f3 = Z}, > > get_all_bindings([{'Z', Z}, {'Y', Y}, {'X', X}, > > {'F3', F3}, {'F2', F2}, {'F1', F1}]), > > Q = 32, > > Q. > > > > Note that Q isn't included in the list because it occurs after the call > to get_all_bindings/1. > > > > --steve > > > > > > _______________________________________________ > > erlang-questions mailing list > > 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 robert.virding@REDACTED Sun Jan 27 04:07:02 2013 From: robert.virding@REDACTED (Robert Virding) Date: Sun, 27 Jan 2013 03:07:02 +0000 (GMT) Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: Message-ID: <1166146732.3080936.1359256022649.JavaMail.root@erlang-solutions.com> LFE is still very much alive! So is Joxa. LFE is much closer to vanilla Erlang in details and properties, this was always a goal. Using it "feels" more Erlangy and it maps more directly onto vanilla Erlang/OTP. In my opinion anyway. Robert ----- Original Message ----- > From: "Raoul Duke" > To: "erlang-questions Questions" > Sent: Friday, 25 January, 2013 11:37:24 PM > Subject: Re: [erlang-questions] If you are homesick for object.selector > > please contribute to getting LFE back in motion. > $0.02, > sincerely. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From mononcqc@REDACTED Sun Jan 27 06:31:35 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Sun, 27 Jan 2013 00:31:35 -0500 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <51030896.1080400@ninenines.eu> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> <20130125165039.GA68598@ferdmbp.local> <20130125182650.GA84348@ferdmbp.local> <51030896.1080400@ninenines.eu> Message-ID: <20130127053131.GA9751@ferdmbp.local.tld> In the mean time, enjoy an implementation of it: https://github.com/ferd/hubble Allows the following mode: demo() -> Stats = hubble:puts(hubble:new(), [{[strength], 12}, {[wisdom], 9}, {[luck], 10}, {[dexterity], 5}]), Char = hubble:puts(hubble:new(), [{[name], <<"karl">>}, {[bio, age], 219}, {[bio, hometown], <<"The Internet">>}, {[bio, parent, father], undefined}, {[bio, parent, mother], <<"A Unicorn">>}, {[stats], Stats}]), Char2 = hubble:put(Char, [level], 1), Char3 = hubble:up(Char2, [bio,parent,father], <<"Randalf">>), 9 = hubble:get(Char3, [stats,wisdom]), <<"A Unicorn">> = hubble:get(Char3, [bio,parent,mother]), <<"Randalf">> = hubble:get(hubble:get(Char3, [bio,parent]), [father]). Or, using a parse transform: -compile({parse_transform, hubble_trans}). demo() -> Stats = puts(new(), [strength, 12], [wisdom, 9], [luck, 10], [dexterity, 5]), Char = puts(new(), [name, <<"karl">>], [bio, age, 219], [bio, hometown, <<"The Internet">>], [bio, parent, father, undefined], [bio, parent, mother, <<"A Unicorn">>], [stats, Stats]), Char2 = put(Char, level, 1), Char3 = up(Char2, bio,parent,father, <<"Randalf">>), 9 = get(Char3, stats, wisdom), <<"A Unicorn">> = get(Char3, bio, parent, mother), <<"Randalf">> = get(get(Char3, bio, parent), father). And it lets you use any damn term you please for the path, not just yet another overloaded bunch of strings with encodings to worry about. The README.md file has a bit more details. Regards, Fred. On 01/25, Lo???c Hoguin wrote: > > That's the point: it should be *built into the language*, you > shouldn't have to go through the trouble of doing something like > this. And it should be *obvious* and in line with the rest of the > language. I quite like the xpath idea Darach mentioned. It could > integrate very well with the rest of the language. I might > experiment with it. > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu From ok@REDACTED Sun Jan 27 09:13:32 2013 From: ok@REDACTED (ok@REDACTED) Date: Sun, 27 Jan 2013 21:13:32 +1300 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <7ed10e58-34f4-4b05-aca6-ccd23796ce40@googlegroups.com> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <7ed10e58-34f4-4b05-aca6-ccd23796ce40@googlegroups.com> Message-ID: <8f75883f6059ce2dffd84ad38d26525a.squirrel@chasm.otago.ac.nz> > While I have no idea how the Erlang parsing process works, I assume it > would not be very hard to write a pre-processor that does the following; > 1. parse all code for occurrences of record assignments. (i.e. > Person#person) > 2. replace all occurrences of the Variable + "." with > Variable#typeFromScope.) (i.e. replace "Person.[somevar]" with > Person#person.somevar. Why do you assume that? The preprocessor would have to do more work than the normal compiler does. -record(foo, {a}). -record(bar, {a}). f(X) -> X#???.a. There isn't any type in scope. And this is far from unusual in Erlang code. > > If you did forget to mention your type somewhere, compilation would still > fail (which is what it should do IMO). > > Most of the frustration probably hides in the fact that the compiler > should > be able to derive that info from the code, as it has been mentioned > before. Should be able to derive it? Please describe the algorithm. I used to be an ML fan, and like Haskell a lot. But there is one phenomenon common to programming languages with type inference, unless you put a _lot_ of work into error reporting. This is where a tiny change to a module in one place (like, for example, removing one call to a function, leaving others) causes an error report somewhere else in the module (like the compiler no longer being able to disambiguate a field). These days we do have the Dialyzer, but it is an _optional_ tool, and it wasn't designed for this particular task. I honestly don't see what's so bad about putting the record name in the selector. It was common practice in Lisp-family languages to use things like (set-circle-area! my-circle (* (circle-area my-circle) 2)) For that matter, look at C structs like 'struct tm' with its tm_sec, tm_min, tm_hour. tm_mday &c fields. From ok@REDACTED Sun Jan 27 09:31:27 2013 From: ok@REDACTED (ok@REDACTED) Date: Sun, 27 Jan 2013 21:31:27 +1300 Subject: [erlang-questions] Variable bindings In-Reply-To: References: Message-ID: > Does there exist any particular function which would give me all variable > bindings (including their values) at that point. Maybe someone has already asked this, but why do you want this? There _are_ programming languages in which this degree of runtime introspection is possible: Interlisp and S spring to mind. But that comes at a fairly heavy cost, and Erlang does not support it. This kind of thing is more commonly found in debuggers. Is it a debugging task you want this for? The parse-transform approach that's been mentioned does this at compile time, not at run time. Now consider f(X) -> Y = g(X), if Y > 0 -> {{A}} h(Y) ; Y =< 0 -> {{B}} r(X) end. At point {{A}}, an Erlang compiler would normally say that Y exists but X doesn't any more. At point {{B}}, we'd normally say that X exists but Y doesn't any more: a variable "exists" from its binding time to its last use. (If you kept variables around any longer than that, you'd be hobbling the garbage collector.) So I think we might need a clearer idea of what variables _you_ expect to exist at a point and whether retaining data longer than necessary is acceptable to do. From essen@REDACTED Sun Jan 27 10:46:21 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sun, 27 Jan 2013 10:46:21 +0100 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <20130127053131.GA9751@ferdmbp.local.tld> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> <20130125165039.GA68598@ferdmbp.local> <20130125182650.GA84348@ferdmbp.local> <51030896.1080400@ninenines.eu> <20130127053131.GA9751@ferdmbp.local.tld> Message-ID: <5104F76D.9080302@ninenines.eu> On 01/27/2013 06:31 AM, Fred Hebert wrote: > In the mean time, enjoy an implementation of it: > > https://github.com/ferd/hubble You're not fixing the issue, it still has no language support. In short it means: * Can't pattern match * Can't use values with function clause guards * Can't modify values at different depths in one go Seems it's also quite verbose and you have to repeat paths all the time, similar to how you have to repeat the record name all the time. > And it lets you use any damn term you please for the path, not just yet > another overloaded bunch of strings with encodings to worry about. No idea what this means. > On 01/25, Lo?c Hoguin wrote: >> >> That's the point: it should be *built into the language*, you >> shouldn't have to go through the trouble of doing something like >> this. And it should be *obvious* and in line with the rest of the >> language. I quite like the xpath idea Darach mentioned. It could >> integrate very well with the rest of the language. I might >> experiment with it. >> >> -- >> Lo?c Hoguin >> Erlang Cowboy >> Nine Nines >> http://ninenines.eu -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From ok@REDACTED Sun Jan 27 11:33:40 2013 From: ok@REDACTED (ok@REDACTED) Date: Sun, 27 Jan 2013 23:33:40 +1300 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <858e5abe-39eb-4e54-8dbc-e73dfefd6083@googlegroups.com> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <7ed10e58-34f4-4b05-aca6-ccd23796ce40@googlegroups.com> <8f75883f6059ce2dffd84ad38d26525a.squirrel@chasm.otago.ac.nz> <858e5abe-39eb-4e54-8dbc-e73dfefd6083@googlegroups.com> Message-ID: <26817c5ca64bc2a81d603093e1fce06e.squirrel@chasm.otago.ac.nz> Tom Janssens wrote: > This is not how it would work; this would be a better example: > > BEFORE: > > -record(foo, {a,b,c}). > -record(bar, {a,x,y}). > > sum(X#foo) -> X.a+X.b+X.c; > sum(X#bar) -> X.a+X.x+X.y. Weird. Are you suggesting a new syntax # which is like =#{}? I can't help feeling that sum(#foo{a=A, b=B, c=C}) -> A+B+C; sum(#bar{a=A, x=X, y=Y}) -> A+X+Y. is superior. In ML, I would write datatype thingy = Foo of {a : int, b : int, c : int} | Bar of {a : int, x : int, c : int} fun sum (Foo {a=a, b=b, c=c}) = a+b+c | sum (Bar {a=a, x=x, y=y}} = a+x+y and pretty much the same thing in Haskell. In functional languages, I expect to use field names in patterns and not elsewhere. If you pick up all the fields you want in one pattern match, you write the record name once and only once. > anotherSum(X) -> > First = X#foo.a, > Middle = X.b, > Last = X.c, > First+Middle+Last. Yes, but again, why go out of your way to avoid a pattern match? The idiomatic way to do this is another_sum(#foo{a = First, b = Middle, c = Last}) -> First + Middle + Last. When I devised frames I tried rewriting some fairly large chunks of existing code using frame notation, and a _very_ helpful first step was pushing field accesses back into pattern matching. As a _reader_ of other people's code, I found it _extremely_ helpful to see _all_ the fields being picked up mentioned in one place. > So the preprocessor would only infer record info when it is available. Yes, but "available" is the magic word, isn't it? The case where a variable is annotated with a record name (and X#foo is not currently legal Erlang syntax) is straightforward, but what about > anotherSum(X) -> > First = f(X)#foo.a, > Middle = f(X).b, > Last = f(X).c, > First+Middle+Last. where to a human reader who has seen f/1 it is obvious that f/1 always returns the same kind of thing. A *local* check by a preprocessor is not going to catch this. You need some sort of type check for at least a whole module. I am NOT saying that it cannot be done. I am NOT saying that it should not be done. I *AM* saying that the hard work of devising an effective (abstract) algorithm that CAN do whatever the task is should be done by the people who want the feature. And simplistic hacks are never going to be satisfactory long term because people will expect whatever the algorithm accomplishes to _make sense to them_. And that means that if X#foo works, then element(N,X)#foo should work, and X#zoo.ick#foo should work, and if f/1 is "obviously" safe, f(X)#foo should work. When the algorithm break down, it should be clear to a programmer _why_ it broke down and what to do about it. >> Should be able to derive it? Please describe the algorithm. > > See above I did _look_ above, but did not _see_ it because you have not described an algorithm. A sample input output pair or two is not a description of an algorithm. Describe an algorithm. Write an EEP. Some EEPs get adopted. Some get implemented by third parties who like the idea. From tyron.zerafa@REDACTED Sun Jan 27 12:11:46 2013 From: tyron.zerafa@REDACTED (Tyron Zerafa) Date: Sun, 27 Jan 2013 12:11:46 +0100 Subject: [erlang-questions] Variable bindings In-Reply-To: References: Message-ID: I want to build a call which accepts a fun, extracts all of its code and dependencies, pass everything over to a remote node and execute it there. The only problem I am having is extracting the value of the free vars of such fun. I was thinking about adding these to the parameter list of the fun, i.e shadowing the respective vars. I believe that the parse transform may work at compile time, though I still have to try it out. I do not want to retain data longer than necessary since all I want is to pass the environment values to a remote node. I am not changing in any way the original fun I am transferring between nodes. Having said so, this is the first part of my project and I still have not given much thought about the possibility of unserializable vars type such as file handlers etc. On Sun, Jan 27, 2013 at 9:31 AM, wrote: > > Does there exist any particular function which would give me all variable > > bindings (including their values) at that point. > > Maybe someone has already asked this, > but why do you want this? > > There _are_ programming languages in which this degree > of runtime introspection is possible: Interlisp and S > spring to mind. But that comes at a fairly heavy cost, > and Erlang does not support it. > This kind of thing is more commonly found in debuggers. > > Is it a debugging task you want this for? > > The parse-transform approach that's been mentioned does > this at compile time, not at run time. Now consider > > f(X) -> Y = g(X), if Y > 0 -> {{A}} h(Y) > ; Y =< 0 -> {{B}} r(X) > end. > > At point {{A}}, an Erlang compiler would normally say that > Y exists but X doesn't any more. At point {{B}}, we'd > normally say that X exists but Y doesn't any more: a > variable "exists" from its binding time to its last use. > (If you kept variables around any longer than that, you'd > be hobbling the garbage collector.) > > So I think we might need a clearer idea of what variables > _you_ expect to exist at a point and whether retaining > data longer than necessary is acceptable to do. > > > -- Best Regards, Tyron Zerafa -------------- next part -------------- An HTML attachment was scrubbed... URL: From per@REDACTED Sun Jan 27 14:07:00 2013 From: per@REDACTED (Per Hedeland) Date: Sun, 27 Jan 2013 14:07:00 +0100 (CET) Subject: [erlang-questions] open_port and raw mode (zlogin) In-Reply-To: <5102CDAD.2080005@erlang.org> Message-ID: <201301271307.r0RD70lV051526@pluto.hedeland.org> Patrik Nyblom wrote: > >On 01/25/2013 07:13 PM, Heinz Nikolaus Gies wrote: [snip] >> >> I've tracked down that a bit further into the zlogin code and it seems >> to be related to a call to tcgetattr(fd, &term) in the code which >> fails with the open_socket created connection. >> >> I'm a bit at a loss here what to do next sadly, any advice? >> >It seems zlogin expects a terminal as stdin, but if you open_port, stdin >for the program will be a pipe, which you cannot do tcgetattr on. You >will need to either find an option to zlogin that expects input from >something not a terminal, or create a wrapper program that creates a pty >, starts zlogin and forwards data from/to the pty and the pipe (which >would be some hacking, but not impossible, that's basically what run_erl >does, but to/from a named pipe - possibly there's already a program out >there doing that, maybe someone on the list can enlighten us :)) Yes, there is actually such a wrapper program included with the Lux tool that H?kan Mattson announced here a while back (in http://erlang.org/pipermail/erlang-questions/2012-May/066891.html). It's called 'runpty' and can be found at https://github.com/hawk/lux/tree/master/c_src - a little demo: 29> P = open_port({spawn, "/bin/sh"},[]). #Port<0.519> 30> P ! {self(), {command, "tty\n"}}. {<0.57.0>,{command,"tty\n"}} 31> flush(). Shell got {#Port<0.519>,{data,"not a tty\n"}} ok 32> erlang:port_close(P). true 33> f(P). ok 34> P = open_port({spawn, "runpty /bin/sh"},[]). #Port<0.525> 35> P ! {self(), {command, "tty\n"}}. {<0.57.0>,{command,"tty\n"}} 36> flush(). Shell got {#Port<0.525>,{data,"$ "}} Shell got {#Port<0.525>,{data,"tty\r\n"}} Shell got {#Port<0.525>,{data,"/dev/pts/12\r\n"}} Shell got {#Port<0.525>,{data,"$ "}} ok 37> Note well that besides tty(1) working, the presence of a tty also (by default) results in echo, pesky CRLF line termination, and an interactive shell. It should work fine to just pass "runpty zlogin ..." to open_port/2 though, but I haven't tried that. --Per Hedeland From heinz@REDACTED Sun Jan 27 16:52:49 2013 From: heinz@REDACTED (Heinz Nikolaus Gies) Date: Sun, 27 Jan 2013 16:52:49 +0100 Subject: [erlang-questions] open_port and raw mode (zlogin) In-Reply-To: <201301271307.r0RD70lV051526@pluto.hedeland.org> References: <201301271307.r0RD70lV051526@pluto.hedeland.org> Message-ID: <0D11DB33-83AF-4E2A-9A23-2E954B735D1A@licenser.net> On Jan 27, 2013, at 14:07, Per Hedeland wrote: ... > Yes, there is actually such a wrapper program included with the Lux tool > that H?kan Mattson announced here a while back (in > http://erlang.org/pipermail/erlang-questions/2012-May/066891.html). > It's called 'runpty' and can be found at > https://github.com/hawk/lux/tree/master/c_src - a little demo: > ... Per, you (and H?ken of cause ;) are a lifesavers! this works like a charm :) thank you so much! Regards, Heinz From mononcqc@REDACTED Sun Jan 27 18:06:22 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Sun, 27 Jan 2013 12:06:22 -0500 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <5104F76D.9080302@ninenines.eu> References: <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> <20130125165039.GA68598@ferdmbp.local> <20130125182650.GA84348@ferdmbp.local> <51030896.1080400@ninenines.eu> <20130127053131.GA9751@ferdmbp.local.tld> <5104F76D.9080302@ninenines.eu> Message-ID: <20130127170615.GA17479@ferdmbp.local> On 01/27, Lo?c Hoguin wrote: > On 01/27/2013 06:31 AM, Fred Hebert wrote: > > In the mean time, enjoy an implementation of it: > > > > https://github.com/ferd/hubble > > You're not fixing the issue, it still has no language support. In > short it means: > > * Can't pattern match > * Can't use values with function clause guards > * Can't modify values at different depths in one go > > Seems it's also quite verbose and you have to repeat paths all the > time, similar to how you have to repeat the record name all the > time. You indeed: * Can't pattern match * Can't use value with function clause guards If these are 100% necessary and vital, there isn't much to do, although there could be some forms of pattern matching (see below). You can modify values at different depths in one go. It would also be easy to support nested operations where you pretty much draw the tree, nearly trivial too, so that: ups(H, [stats, strength, 1], [stats, wisdom, 2], [bio, age, 329]) Becomes: ups(H, [stats, [strength, 1] [wisdom, 2]], [bio, age, 329]) This means you can no longer use lists (or strings) as keys, though, because you couldn't know whether they're nested levels or keys; another syntax could be found possibly. I don't know when that would become too cumbersome or not cumbersome enough for your own tastes. It would maybe be possible to do the deconstruction on the left-hand side of the match operator. Find the desired fields, shove them in a tuple, and match on the final values or whatever. A transformation that targets making a call similar to: {X,5,Z} = {hubble:get(Hubble,[stats,strength]), hubble:get(Hubble,[stats,wisdom]), hubble:get(Hubble,[bio,parent,father])} would possibly allow a declaration like (I think they'll be allowed this far down the compilation, but I haven't checked): match([stats, [strength, X] [wisdom, 5]], [bio, parent, father, Z]) = Hubble That's a far cry from native language support with function heads and guards. I don't know if you'd still consider this far too cumbersome, if it's somehow still worse than your aversion to the current record format: #character{stats=#stats{strength=X, wisdom=5}, bio=#bio{parent=#parent{father=Z}}} = Hubble If there's a common translation accepted of match(Hubble) -> Tuple, or match(Hubble) -> List, then you could allow the transformation of the match/1 function as a general rule and be able to pass it to cases and guards. I'm not sure how reliable that thing would be, and it could not work with function heads. It's stuff that can be explored right away, though, without needing language support, if the need for such a structure or the hate of records make this really pressing. If it's not that urgent, then oh well. > > >And it lets you use any damn term you please for the path, not just yet > >another overloaded bunch of strings with encodings to worry about. > > No idea what this means. > When XPath was mentioned, I assumed it would be something string-based like the real XPath libraries use: "people//author[first-name][3]" This means whatever your key is, it needs to be a string or an atom, hope that they use the same encoding, escape values that could have been used, etc. I feel it's generally more interesting to be able to have mixed-type keys for some operations on dict-like data structures. Say I have a gen_event with registered handlers {make_ref(), Name}. Using these for keys becomes impossible with a string matching syntax. Maybe most people wouldn't care about that, though, and xPathing could be interesting. I'm not sure how you could use that to pattern match while binding values though. Regards, Fred. From tamas@REDACTED Sun Jan 27 19:00:51 2013 From: tamas@REDACTED (=?iso-8859-1?Q?Szepes_Tam=E1s?=) Date: Sun, 27 Jan 2013 19:00:51 +0100 Subject: [erlang-questions] Mnesia normalized field lookup Message-ID: <000f01cdfcb8$3ea623f0$bbf26bd0$@veriport.eu> All, I have couple of Mnesia tables where the records has some long text fields with relatively little variation in content (like institute_name which can be 128 characters long, but in a typical installation there is no more than 20 different values). About 1/3 of my fields are similar and I cannot determine all possible values in advance to make atoms for them (data from a new institute can come any time after installation, and the database needs to be self contained for archiving purposes). As I need to handle ~10^8 records I?d like to normalize these fields to spare storage space. However it blows my code if I have to do 3-6 joins in every lookup operation, not to mention the inserts. Is there any elegant way of handling this situation? Thanks in advance, Tamas From dave@REDACTED Sun Jan 27 19:26:53 2013 From: dave@REDACTED (David Goehrig) Date: Sun, 27 Jan 2013 13:26:53 -0500 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <066249d4a063d4111e549ae5894a27ce.squirrel@chasm.otago.ac.nz> References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <510150CC.90208@ninenines.eu> <066249d4a063d4111e549ae5894a27ce.squirrel@chasm.otago.ac.nz> Message-ID: <9357A43F-8A51-443F-9531-359EB6DBDB64@nexttolast.com> -=-=- dave@REDACTED -=-=- On Jan 25, 2013, at 9:41 PM, ok@REDACTED wrote: > It's all just pure values and functions underneath. > Would _this_ satisfy the complaints? Well I don't actually have a complaint, although that sugar looks sugary :) I do, however, see a fundamental design flaw in any Erlang program that attempts to manipulate nested data structures as it were C (or substitute your favorite Algol in Funny Hats here). Erlang has a wonderful dictionary object for each process, and you can straight forwardly map any Algol in funny hats language solution to Erlang message sends + process dictionaries. You just have to observe strict message passing OO requirements, as process dictionaries can not be modified externally (without playing games at the VM level). In my experience 100k+ processes acting as basically Python dictionaries or Perl hashes is just as manageable as 100k+ objects in any OO language. Only in Erlang, I can't cheat and those 100k processes are much easier to wrangle over a distributed cluster. Dave From ericbmerritt@REDACTED Sun Jan 27 19:28:50 2013 From: ericbmerritt@REDACTED (Eric Merritt) Date: Sun, 27 Jan 2013 10:28:50 -0800 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> <20130125165039.GA68598@ferdmbp.local> Message-ID: > Garrett > > [1] https://github.com/languages > > [2] I'm reminded of the coding horror that is jQuery > > [3] I'd point to Eric Merrit's outstanding with with Joxa > (http://joxa.org) as an example of what can be done with core Erlang > and the Erlang tool chain We will probably be hoisting Joxa up from Core Erlang to the higher level Erlang AST sometime soon. Unfortunately, Core Erlang isn't really the first class language target that it is claimed. The main problem is it does not produce Abstract Code in the resulting beam. This makes it impossible to use both Erlang's built in debugger and Dialyzer on things compiled to Core Erlang. It could be argued that this isn't a major problem. In Joxa, at least, the lack of those features have been somewhat painful for new folks. On the plus side Core Erlang is a nice, simple AST to target that gives a lot of flexibility. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From raould@REDACTED Sun Jan 27 22:17:38 2013 From: raould@REDACTED (Raoul Duke) Date: Sun, 27 Jan 2013 13:17:38 -0800 Subject: [erlang-questions] dialyzer for lisps (Re: If you are homesick for object.selector) Message-ID: > This makes it impossible to use both Erlang's built in debugger and > Dialyzer on things compiled to Core Erlang. It could be argued that > this isn't a major problem. In Joxa, at least, the lack of those > features have been somewhat painful for new folks. i would argue it is clearly a giant problem. i don't mean that i'm mad at joxa, i'm just saying *any* language that doesn't have a debugger is not a real language. but furthermore, anything in the erlang ecosystem that can't work with dialyzer is to my mind a bit of a non-starter. ?2. From pablo.platt@REDACTED Sun Jan 27 22:56:09 2013 From: pablo.platt@REDACTED (pablo platt) Date: Sun, 27 Jan 2013 23:56:09 +0200 Subject: [erlang-questions] receiving output from a python shell Message-ID: How can I get the output of a python shell? This is what I'm trying to do: > Port = open_port({spawn, "python"}, [binary, exit_status]). #Port<0.586> > port_command(Port, "print 1\n"). true > flush(). ok When calling flush(), I expect to get {Port,{data, <<"1\n">>}} but I'm not getting any message. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sun Jan 27 23:01:01 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 27 Jan 2013 23:01:01 +0100 Subject: [erlang-questions] dialyzer for lisps (Re: If you are homesick for object.selector) In-Reply-To: References: Message-ID: <57E1CAD1-EA42-4406-881B-2E701FAE432A@gmail.com> Patching Dialyzer to make it work on Core Erlang should be pretty straightforward as it does its analysis on Core Erlang code anyway; it's just that it doesn't currently know how to obtain it from the BEAM file without first getting the Erlang AST chunk and compiling it to Core Erlang AST. -- Anthony Ramine Le 27 janv. 2013 ? 22:17, Raoul Duke a ?crit : >> This makes it impossible to use both Erlang's built in debugger and >> Dialyzer on things compiled to Core Erlang. It could be argued that >> this isn't a major problem. In Joxa, at least, the lack of those >> features have been somewhat painful for new folks. > > i would argue it is clearly a giant problem. i don't mean that i'm mad > at joxa, i'm just saying *any* language that doesn't have a debugger > is not a real language. but furthermore, anything in the erlang > ecosystem that can't work with dialyzer is to my mind a bit of a > non-starter. ?2. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vinoski@REDACTED Sun Jan 27 23:53:14 2013 From: vinoski@REDACTED (Steve Vinoski) Date: Sun, 27 Jan 2013 17:53:14 -0500 Subject: [erlang-questions] receiving output from a python shell In-Reply-To: References: Message-ID: On Sun, Jan 27, 2013 at 4:56 PM, pablo platt wrote: > How can I get the output of a python shell? > > This is what I'm trying to do: > > Port = open_port({spawn, "python"}, [binary, exit_status]). > #Port<0.586> > > port_command(Port, "print 1\n"). > true > > flush(). > ok > > When calling flush(), I expect to get {Port,{data, <<"1\n">>}} > but I'm not getting any message. > You might want to try ErlPort: http://erlport.org Otherwise, you're just going to have to re-code what ErlPort already gives you. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablo.platt@REDACTED Mon Jan 28 00:03:17 2013 From: pablo.platt@REDACTED (pablo platt) Date: Mon, 28 Jan 2013 01:03:17 +0200 Subject: [erlang-questions] receiving output from a python shell In-Reply-To: References: Message-ID: erlport looks interesting but I don't need to manipulate the python shell response. I want to start a python shell (or any other shell), send arbitrary commands to it and get the response. On Mon, Jan 28, 2013 at 12:53 AM, Steve Vinoski wrote: > > > On Sun, Jan 27, 2013 at 4:56 PM, pablo platt wrote: > >> How can I get the output of a python shell? >> >> This is what I'm trying to do: >> > Port = open_port({spawn, "python"}, [binary, exit_status]). >> #Port<0.586> >> > port_command(Port, "print 1\n"). >> true >> > flush(). >> ok >> >> When calling flush(), I expect to get {Port,{data, <<"1\n">>}} >> but I'm not getting any message. >> > > You might want to try ErlPort: > > http://erlport.org > > Otherwise, you're just going to have to re-code what ErlPort already gives > you. > > --steve > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chandrashekhar.mullaparthi@REDACTED Mon Jan 28 00:03:35 2013 From: chandrashekhar.mullaparthi@REDACTED (Chandru) Date: Sun, 27 Jan 2013 23:03:35 +0000 Subject: [erlang-questions] Mnesia normalized field lookup In-Reply-To: <000f01cdfcb8$3ea623f0$bbf26bd0$@veriport.eu> References: <000f01cdfcb8$3ea623f0$bbf26bd0$@veriport.eu> Message-ID: You could consider computing the hash of your value, and store the mapping from actual value to hash value in another table. When writing your record, store the hash value instead of the actual value. When you need to retrieve the original, use the mapping table to map the hashed value to the actual value. Does that make sense? Chandru On 27 January 2013 18:00, Szepes Tam?s wrote: > All, > > I have couple of Mnesia tables where the records has some long text fields > with relatively little variation in content (like institute_name which can > be 128 characters long, but in a typical installation there is no more than > 20 different values). About 1/3 of my fields are similar and I cannot > determine all possible values in advance to make atoms for them (data from > a > new institute can come any time after installation, and the database needs > to be self contained for archiving purposes). > As I need to handle ~10^8 records I?d like to normalize these fields to > spare storage space. However it blows my code if I have to do 3-6 joins in > every lookup operation, not to mention the inserts. > Is there any elegant way of handling this situation? > > Thanks in advance, > Tamas > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norton@REDACTED Mon Jan 28 00:13:31 2013 From: norton@REDACTED (Joseph Wayne Norton) Date: Mon, 28 Jan 2013 08:13:31 +0900 Subject: [erlang-questions] receiving output from a python shell In-Reply-To: References: Message-ID: <2264D986-D24B-42F7-B1F9-D6F1BB4A7AFB@lovely.email.ne.jp> Here is a snippet that invokes a python program and captures the output. https://github.com/norton/asciiedoc/blob/master/src/asciiedoc_lib.erl#L96 This example isn't interactive but might be of help to you. regards, Joe N. On Jan 28, 2013, at 8:03 AM, pablo platt wrote: > erlport looks interesting but I don't need to manipulate the python shell response. > I want to start a python shell (or any other shell), send arbitrary commands to it and get the response. > > On Mon, Jan 28, 2013 at 12:53 AM, Steve Vinoski wrote: > > > On Sun, Jan 27, 2013 at 4:56 PM, pablo platt wrote: > How can I get the output of a python shell? > > This is what I'm trying to do: > > Port = open_port({spawn, "python"}, [binary, exit_status]). > #Port<0.586> > > port_command(Port, "print 1\n"). > true > > flush(). > ok > > When calling flush(), I expect to get {Port,{data, <<"1\n">>}} > but I'm not getting any message. > > You might want to try ErlPort: > > http://erlport.org > > Otherwise, you're just going to have to re-code what ErlPort already gives you. > > --steve > > _______________________________________________ > 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 Mon Jan 28 00:20:12 2013 From: pablo.platt@REDACTED (pablo platt) Date: Mon, 28 Jan 2013 01:20:12 +0200 Subject: [erlang-questions] receiving output from a python shell In-Reply-To: <2264D986-D24B-42F7-B1F9-D6F1BB4A7AFB@lovely.email.ne.jp> References: <2264D986-D24B-42F7-B1F9-D6F1BB4A7AFB@lovely.email.ne.jp> Message-ID: When executing a python file or command it works but when starting a python shell and interacting with it I'm not getting any output 1> Port = open_port({spawn, "python -c \"print 1\""}, [binary, exit_status]). #Port<0.586> 2> flush(). Shell got {#Port<0.586>,{data,<<"1\n">>}} Shell got {#Port<0.586>,{exit_status,0}} ok On Mon, Jan 28, 2013 at 1:13 AM, Joseph Wayne Norton < norton@REDACTED> wrote: > > Here is a snippet that invokes a python program and captures the output. > > https://github.com/norton/asciiedoc/blob/master/src/asciiedoc_lib.erl#L96 > > This example isn't interactive but might be of help to you. > > regards, > > Joe N. > > On Jan 28, 2013, at 8:03 AM, pablo platt wrote: > > erlport looks interesting but I don't need to manipulate the python shell > response. > I want to start a python shell (or any other shell), send arbitrary > commands to it and get the response. > > On Mon, Jan 28, 2013 at 12:53 AM, Steve Vinoski wrote: > >> >> >> On Sun, Jan 27, 2013 at 4:56 PM, pablo platt wrote: >> >>> How can I get the output of a python shell? >>> >>> This is what I'm trying to do: >>> > Port = open_port({spawn, "python"}, [binary, exit_status]). >>> #Port<0.586> >>> > port_command(Port, "print 1\n"). >>> true >>> > flush(). >>> ok >>> >>> When calling flush(), I expect to get {Port,{data, <<"1\n">>}} >>> but I'm not getting any message. >>> >> >> You might want to try ErlPort: >> >> http://erlport.org >> >> Otherwise, you're just going to have to re-code what ErlPort already >> gives you. >> >> --steve >> > > _______________________________________________ > 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 Mon Jan 28 00:40:17 2013 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 28 Jan 2013 12:40:17 +1300 Subject: [erlang-questions] Variable bindings In-Reply-To: References: Message-ID: <333D06FA-EB73-4140-A6D2-BB059413A1F5@cs.otago.ac.nz> On 28/01/2013, at 12:11 AM, Tyron Zerafa wrote: > I want to build a call which accepts a fun, extracts all of its code and dependencies, pass everything over to a remote node and execute it there. The problem is that funs don't normally _have_ code available unless you compile the containing module with a special option. Have you considered the alternative of accepting the *source code* of a fun and parsing that? > The only problem I am having is extracting the value of the free vars of such fun. Er, the free variables of a fun are _not_ the variables that are in scope at its point of creation, they are that subset of those variables that are *used* inside the fun. What a fun _is_, conceptually, is a tuple containing a code reference and a set of variable bindings. If someone gives you a fun, you know exactly what the values for those variables are because they are right there. A fun does not point back to the stack frame of its creator. Let's take a look at a tiny example. foo(X, Y) -> M = (X+Y)/2, fun (Z) -> {Z,M} end. Now let's look at the BEAM code. {function, foo, 2, 2}. {label,1}. {func_info,{atom,foo},{atom,foo},2}. {label,2}. % add Y to X; put the result back in X {gc_bif,'+',{f,0},2,[{x,0},{x,1}],{x,0}}. % check that there is room for two floats {test_heap,{alloc,[{words,0},{floats,1}]},2}. % convert X to floating point (in FR 0) {fconv,{x,0},{fr,0}}. % convert 2 to floating point (in FR 1) %?? Why is this not done at compile time? {fconv,{integer,2},{fr,1}}. fclearerror. % Divide FR 0 by FR 1 and put the result in FR 0. {bif,fdiv,{f,0},[{fr,0},{fr,1}],{fr,0}}. {fcheckerror,{f,0}}. % Now that we know all went well, box the result % and put it back in X. {fmove,{fr,0},{x,0}}. {'%live',1}. % Create a fun, copying X (but not what X points to) % into it. {make_fun2,{f,8},0,98308069,1}. return. {function, '-foo/2-fun-0-', 2, 8}. {label,7}. {func_info,{atom,foo},{atom,'-foo/2-fun-0-'},2}. % {f,8} in the make_fun2 instruction points here. {label,8}. % Check that there is room for a 2-tuple {test_heap,3,2}. % start to create it, and let X2 point to it. {put_tuple,2,{x,2}}. % put in Z {put,{x,0}}. % put in M {put,{x,1}}. % move X2 down to X0 {move,{x,2},{x,0}}. % return X0 return. > I was thinking about adding these to the parameter list of the fun, As the code shows, the (selected) free variables _are_ hidden parameters of the fun. > i.e shadowing the respective vars. ? Finding the dependencies of a fun, at least those not already compiled inline, can be done from its BEAM code. You do not need the source code. What you cannot get, either way, is which _versions_ of the modules used the code depends on. And that creates a big problem. On local node L, send F1 to remote node R. F1 needs module M. Ensure that R has M loaded. But M on R is a completely different module from M on L. So send L to R as well and have it install that. Congratulations, you just broke everything else on R that used M. If you can manage version consistency to the point at which every node you try to send stuff to has the same versions of all the relevant modules you need, then you don't need to extract dependencies at run time. If you can't do that, it's not going to work anyway. This whole sending-code-to-a-remote-node business is to be done with *extreme* vigilant trepidation, if at all. Do you *really* want me to be able to call your_module:your_handy_function(fun () -> halt() end) Consider whether it is possible to devise a *sublanguage* of trustworthy code. From g@REDACTED Mon Jan 28 00:49:17 2013 From: g@REDACTED (Garrett Smith) Date: Sun, 27 Jan 2013 17:49:17 -0600 Subject: [erlang-questions] receiving output from a python shell In-Reply-To: References: Message-ID: I would still consider using erlport and the eval function to evaluate commands: http://docs.python.org/2/library/functions.html#eval This will give you control over what you're doing. Unless you're trying to literally screen-scrape Python. If that's your goal, you'll want to run Python in interactive mode with the -i option (man python). 1> P = erlang:open_port({spawn, "python -i"}, [stderr_to_stdout]). #Port<0.516> 2> flush(). Shell got {#Port<0.516>, {data,"Python 2.7.3 (default, Aug 1 2012, 05:14:39) \n[GCC 4.6.3] on linux2\n"}} Shell got {#Port<0.516>, {data,"Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n"}} Shell got {#Port<0.516>,{data,">>> "}} ok 3> erlang:port_command(P, "print 1\n"). true 4> flush(). Shell got {#Port<0.516>,{data,"1\n>>> "}} ok Garrett On Sun, Jan 27, 2013 at 5:03 PM, pablo platt wrote: > erlport looks interesting but I don't need to manipulate the python shell > response. > I want to start a python shell (or any other shell), send arbitrary commands > to it and get the response. > > > On Mon, Jan 28, 2013 at 12:53 AM, Steve Vinoski wrote: >> >> >> >> On Sun, Jan 27, 2013 at 4:56 PM, pablo platt >> wrote: >>> >>> How can I get the output of a python shell? >>> >>> This is what I'm trying to do: >>> > Port = open_port({spawn, "python"}, [binary, exit_status]). >>> #Port<0.586> >>> > port_command(Port, "print 1\n"). >>> true >>> > flush(). >>> ok >>> >>> When calling flush(), I expect to get {Port,{data, <<"1\n">>}} >>> but I'm not getting any message. >> >> >> You might want to try ErlPort: >> >> http://erlport.org >> >> Otherwise, you're just going to have to re-code what ErlPort already gives >> you. >> >> --steve > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From pablo.platt@REDACTED Mon Jan 28 01:11:40 2013 From: pablo.platt@REDACTED (pablo platt) Date: Mon, 28 Jan 2013 02:11:40 +0200 Subject: [erlang-questions] receiving output from a python shell In-Reply-To: References: Message-ID: I've tested "python -i" before but without stderr_to_stdout. With stderr_to_stdout it works. Not sure why it is needed. I thought that it only direct errors to stdout. Thanks. On Mon, Jan 28, 2013 at 1:49 AM, Garrett Smith wrote: > I would still consider using erlport and the eval function to evaluate > commands: > > http://docs.python.org/2/library/functions.html#eval > > This will give you control over what you're doing. > > Unless you're trying to literally screen-scrape Python. If that's your > goal, you'll want to run Python in interactive mode with the -i option > (man python). > > 1> P = erlang:open_port({spawn, "python -i"}, [stderr_to_stdout]). > #Port<0.516> > 2> flush(). > Shell got {#Port<0.516>, > {data,"Python 2.7.3 (default, Aug 1 2012, 05:14:39) \n[GCC > 4.6.3] on linux2\n"}} > Shell got {#Port<0.516>, > {data,"Type \"help\", \"copyright\", \"credits\" or > \"license\" for more information.\n"}} > Shell got {#Port<0.516>,{data,">>> "}} > ok > 3> erlang:port_command(P, "print 1\n"). > true > 4> flush(). > Shell got {#Port<0.516>,{data,"1\n>>> "}} > ok > > Garrett > > On Sun, Jan 27, 2013 at 5:03 PM, pablo platt > wrote: > > erlport looks interesting but I don't need to manipulate the python shell > > response. > > I want to start a python shell (or any other shell), send arbitrary > commands > > to it and get the response. > > > > > > On Mon, Jan 28, 2013 at 12:53 AM, Steve Vinoski > wrote: > >> > >> > >> > >> On Sun, Jan 27, 2013 at 4:56 PM, pablo platt > >> wrote: > >>> > >>> How can I get the output of a python shell? > >>> > >>> This is what I'm trying to do: > >>> > Port = open_port({spawn, "python"}, [binary, exit_status]). > >>> #Port<0.586> > >>> > port_command(Port, "print 1\n"). > >>> true > >>> > flush(). > >>> ok > >>> > >>> When calling flush(), I expect to get {Port,{data, <<"1\n">>}} > >>> but I'm not getting any message. > >> > >> > >> You might want to try ErlPort: > >> > >> http://erlport.org > >> > >> Otherwise, you're just going to have to re-code what ErlPort already > gives > >> you. > >> > >> --steve > > > > > > > > _______________________________________________ > > 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 Mon Jan 28 02:01:03 2013 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 28 Jan 2013 14:01:03 +1300 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> <510279C4.9000000@ninenines.eu> Message-ID: <27483647-10A7-4521-8376-A497854A5CBC@cs.otago.ac.nz> This is _so_ on-topic... http://thedailywtf.com/Articles/Ancestors.aspx From reading http://www.xml.org//sites/www.xml.org/files/xslt_efficient_programming_techniques.pdf it appears that the Kaysian technique is a horrible kluge to work around the fact that XPath 1.0 does not have set operations. XPath 2.0 _does_ have set operations: 3.3.3 Combining Node Sequences [14] UnionExpr ::= IntersectExceptExpr ( ("union" | "|") IntersectExceptExpr )* [15] IntersectExceptExpr ::= InstanceofExpr ( ("intersect" | "except") InstanceofExpr )* It would be interesting to see measurements of intersections computed using "say-exactly-what-you-mean" vs "Kaysian-kluge". Given that the results of union, intersect, except are returned in document order, these operations would _probably_ be implemented as linear time merges; hard to beat. From robert.virding@REDACTED Mon Jan 28 02:23:19 2013 From: robert.virding@REDACTED (Robert Virding) Date: Mon, 28 Jan 2013 01:23:19 +0000 (GMT) Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <27483647-10A7-4521-8376-A497854A5CBC@cs.otago.ac.nz> Message-ID: <704615102.3084165.1359336199090.JavaMail.root@erlang-solutions.com> ----- Original Message ----- > From: "Richard O'Keefe" > > This is _so_ on-topic... > > http://thedailywtf.com/Articles/Ancestors.aspx Think how much more difficult to read it would have been if you had to include the record names. :-) Robert From robert.virding@REDACTED Mon Jan 28 02:42:37 2013 From: robert.virding@REDACTED (Robert Virding) Date: Mon, 28 Jan 2013 01:42:37 +0000 (GMT) Subject: [erlang-questions] dialyzer for lisps (Re: If you are homesick for object.selector) In-Reply-To: <57E1CAD1-EA42-4406-881B-2E701FAE432A@gmail.com> Message-ID: <2121730453.3084280.1359337357092.JavaMail.root@erlang-solutions.com> Making read it read source files from other front-ends which generate core erlang would not be too difficult. The main problem is that it is hard-coded that dialyzer assumes that source files end with .erl. I thought a bit about generating Erlang instead of Code for LFE but came to the conclusion that the resulting Erlang would not be very transparent anyway. Robert ----- Original Message ----- > From: "Anthony Ramine" > To: "Raoul Duke" > Cc: "erlang-questions Questions" > Sent: Sunday, 27 January, 2013 11:01:01 PM > Subject: Re: [erlang-questions] dialyzer for lisps (Re: If you are homesick for object.selector) > > Patching Dialyzer to make it work on Core Erlang should be pretty > straightforward as it does its analysis on Core Erlang code anyway; > it's just that it doesn't currently know how to obtain it from the > BEAM file without first getting the Erlang AST chunk and compiling > it to Core Erlang AST. > > -- > Anthony Ramine > > Le 27 janv. 2013 ? 22:17, Raoul Duke a ?crit : > > >> This makes it impossible to use both Erlang's built in debugger > >> and > >> Dialyzer on things compiled to Core Erlang. It could be argued > >> that > >> this isn't a major problem. In Joxa, at least, the lack of those > >> features have been somewhat painful for new folks. > > > > i would argue it is clearly a giant problem. i don't mean that i'm > > mad > > at joxa, i'm just saying *any* language that doesn't have a > > debugger > > is not a real language. but furthermore, anything in the erlang > > ecosystem that can't work with dialyzer is to my mind a bit of a > > non-starter. ?2. > > _______________________________________________ > > erlang-questions mailing list > > 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 Jan 28 02:57:18 2013 From: g@REDACTED (Garrett Smith) Date: Sun, 27 Jan 2013 19:57:18 -0600 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <704615102.3084165.1359336199090.JavaMail.root@erlang-solutions.com> References: <27483647-10A7-4521-8376-A497854A5CBC@cs.otago.ac.nz> <704615102.3084165.1359336199090.JavaMail.root@erlang-solutions.com> Message-ID: On Sun, Jan 27, 2013 at 7:23 PM, Robert Virding wrote: > > ----- Original Message ----- >> From: "Richard O'Keefe" >> >> This is _so_ on-topic... >> >> http://thedailywtf.com/Articles/Ancestors.aspx > > Think how much more difficult to read it would have been if you had to include the record names. :-) For the benefit of those who didn't click the link, it contains this function in C#: private void MouseMove(object sender, MouseEventArgs e) { (sender as PictureBox).Parent.Parent.Parent.Parent.Parent.GetType(); } After seeing that, I'm convinced Erlang record syntax is one the language's best features. If other languages had such a tax, this sort of thing would be held in check. Call it a sin tax. Get it? Garrett From ok@REDACTED Mon Jan 28 04:55:18 2013 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 28 Jan 2013 16:55:18 +1300 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <704615102.3084165.1359336199090.JavaMail.root@erlang-solutions.com> References: <704615102.3084165.1359336199090.JavaMail.root@erlang-solutions.com> Message-ID: <73EB0D27-B542-4979-A4A6-9E6BACD8E8B2@cs.otago.ac.nz> On 28/01/2013, at 2:23 PM, Robert Virding wrote: >> http://thedailywtf.com/Articles/Ancestors.aspx > > Think how much more difficult to read it would have been if you had to include the record names. :-) Yeah, it might have been hard enough to _write_ that the original programmers might have _thought_. Well, one can hope. From eriksoe@REDACTED Mon Jan 28 09:46:17 2013 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Mon, 28 Jan 2013 09:46:17 +0100 Subject: [erlang-questions] Understanding memory usage In-Reply-To: <7EFEA754-B706-4358-8896-6E3D196B99D3@tty.nl> References: <7EFEA754-B706-4358-8896-6E3D196B99D3@tty.nl> Message-ID: 2013/1/26 Ward Bekker (TTY) > Hi, > > I run into high memory usage (>1.5GB) when running `crack_util:crack` from > this module: https://gist.github.com/4642789 (make sure crypto is > running: `crypto:start()`). As far as I can see, it's not creating (or > holding on to) huge pieces of data. > > Why is that? > It happens in this line: lists:seq(0, Products-1)). because Products = round(math:pow(length(?CHAR_LIST), TryLength)) = 59^5 = 714924299 lists:seq() is, as anything else in Erlang, calculated eagerly, so you get a full representation of the list. In a 32-bit Erlang VM, that takes 5,7GB. You may want to write a function that folds over a range of integers, and use that instead of lists:foldl(_,_,lists:seq(A,B)) :-) /Erik -------------- next part -------------- An HTML attachment was scrubbed... URL: From valentin@REDACTED Mon Jan 28 09:52:34 2013 From: valentin@REDACTED (Valentin Micic) Date: Mon, 28 Jan 2013 10:52:34 +0200 Subject: [erlang-questions] Understanding memory usage In-Reply-To: References: <7EFEA754-B706-4358-8896-6E3D196B99D3@tty.nl> Message-ID: Hmmmm? how can anything take 5,7GB in 32-bit architecture? V/ On 28 Jan 2013, at 10:46 AM, Erik S?e S?rensen wrote: > 2013/1/26 Ward Bekker (TTY) > Hi, > > I run into high memory usage (>1.5GB) when running `crack_util:crack` from this module: https://gist.github.com/4642789 (make sure crypto is running: `crypto:start()`). As far as I can see, it's not creating (or holding on to) huge pieces of data. > > Why is that? > > It happens in this line: > lists:seq(0, Products-1)). > because > Products = round(math:pow(length(?CHAR_LIST), TryLength)) = 59^5 = 714924299 > lists:seq() is, as anything else in Erlang, calculated eagerly, so you get a full representation of the list. > In a 32-bit Erlang VM, that takes 5,7GB. > > You may want to write a function that folds over a range of integers, and use that instead of lists:foldl(_,_,lists:seq(A,B)) :-) > > /Erik > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrii@REDACTED Mon Jan 28 10:00:25 2013 From: dmitrii@REDACTED (Dmitrii Dimandt) Date: Mon, 28 Jan 2013 10:00:25 +0100 Subject: [erlang-questions] Message order and exit(Reason) Message-ID: Hi all, We've had a semi-heated discussion in Russian community over this question: http://stackoverflow.com/questions/14556109/race-condition-between-trap-exit-exit-msg-and-common-msg The question is as following: Assume we have processes A and B which are linked. Process's A flag trap_exit is set to true. Let B process send a msg to A and then exit: PidA ! 'msg', exit(reason). What I wanna know if we can be shure that the process A will receive 'msg' and only after It {'EXIT', Pid, reason} will come ? Can we predict the ordering of msgs? I can't found any proofs in documentation, but I guess that it will work that way, but I need some proofs. Don't want to have race condition here. Can anyone with the intimate knowledge of Erlang internals shed some light on this? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Mon Jan 28 10:24:32 2013 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Mon, 28 Jan 2013 01:24:32 -0800 (PST) Subject: [erlang-questions] Message order and exit(Reason) In-Reply-To: References: Message-ID: <1359365072.70812.YahooMailNeo@web120702.mail.ne1.yahoo.com> Hi Dmitrii, I think the following means that if A sends M1, M2 to B, then B will receive M1, M2 in the order of sending. It's not explicitly stated that exit messages are handled the same way as regular messages, though I think the default assumption should be that they are. Those here who have worked on model checking and whatnot, feel free to expound. 10.8? Is the order of message reception guaranteed? Yes, but only within one process. If there is a live process and you send it message A and then message B, it's guaranteed that if message B arrived, message A arrived before it. On the other hand, imagine processes P, Q and R. P sends message A to Q, and then message B to R. There is no guarantee that A arrives before B. (Distributed Erlang would have a pretty tough time if this was required!) http://www.erlang.org/faq/academic.html Best, Thomas >________________________________ > From: Dmitrii Dimandt >To: Erlang Questions >Sent: Monday, January 28, 2013 10:00 AM >Subject: [erlang-questions] Message order and exit(Reason) > > >Hi all, > > >We've had a semi-heated discussion in Russian community over this question:?http://stackoverflow.com/questions/14556109/race-condition-between-trap-exit-exit-msg-and-common-msg > > >The question is as following: Assume we have processes A and B which are linked. Process's A flag trap_exit is set to true. Let B?process send a msg to A and then exit: > > >PidA ! 'msg', >exit(reason). >What I wanna know if we can be shure that the process A will receive 'msg' and only after It {'EXIT', Pid, reason} will come ? Can we?predict the ordering of msgs? I can't found any proofs in documentation, but I guess that it will work that way, but I need some proofs.?Don't want to have race condition here. > > > > >Can anyone with the intimate knowledge of Erlang internals shed some light on this? > > >Thanks! >_______________________________________________ >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 Mon Jan 28 10:24:59 2013 From: francesco@REDACTED (Francesco Cesarini) Date: Mon, 28 Jan 2013 09:24:59 +0000 Subject: [erlang-questions] Fwd: Six PhD Studentships at St Andrews (tight deadline) In-Reply-To: <8E74F5A2-D0B5-4056-A072-DA4B18217CDA@cs.st-andrews.ac.uk> References: <8E74F5A2-D0B5-4056-A072-DA4B18217CDA@cs.st-andrews.ac.uk> Message-ID: <510643EB.5030904@erlang-solutions.com> While slightly off topic, it might be of interest to some of you. St. Andrews is currently involved in the ParaPhrase project, http://paraphrase-ict.eu/, of which Erlang is a key component. St. Andrews is in a beautiful setting in Scotland close to the golf courses and the beaches, a short train ride from Edinburgh. Please contact Kevin directly of have a look at the website for more information. Francesco -------- Original Message -------- Subject: Six PhD Studentships at St Andrews (tight deadline) Date: Sun, 27 Jan 2013 18:43:31 +0000 From: Kevin Hammond To: Francesco Cesarini Dear Francesco We have six funded PhD Studentships available. If you know any good applicants with an interest in functional programming, parallelism or related areas, I'd be pleased to hear from them. The deadline is tight (4th February), but the main thing is to get an application in. http://blogs.cs.st-andrews.ac.uk/csblog/2012/12/20/600th-anniversary-phd-scholarships/ Best Wishes, Kevin -------- Kevin Hammond, Professor of Computer Science, University of St Andrews T: +44-1334 463241 F: +44-1334-463278 W: http://www.cs.st-andrews.ac.uk/~kh In accordance with University policy on electronic mail, this email reflects the opinions of the individual concerned, may contain confidential or copyright information that should not be copied or distributed without permission, may be of a private or personal nature unless explicitly indicated otherwise, and should not under any circumstances be taken as an official statement of University policy or procedure (see http://www.st-and.ac.uk). The University of St Andrews is a charity registered in Scotland : No SC013532 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eriksoe@REDACTED Mon Jan 28 10:49:27 2013 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Mon, 28 Jan 2013 10:49:27 +0100 Subject: [erlang-questions] Understanding memory usage In-Reply-To: References: <7EFEA754-B706-4358-8896-6E3D196B99D3@tty.nl> Message-ID: Indeed - you run out of pointer values as well as physical space :-) So, for that program to work as it is, you need >12GB ram on a 64-bit machine. If Beam supports such large processes at all. I think the time is best spent rewriting that seq() call. 2013/1/28 Valentin Micic > Hmmmm? how can anything take 5,7GB in 32-bit architecture? > > V/ > > On 28 Jan 2013, at 10:46 AM, Erik S?e S?rensen wrote: > > 2013/1/26 Ward Bekker (TTY) > >> Hi, >> >> I run into high memory usage (>1.5GB) when running `crack_util:crack` >> from this module: https://gist.github.com/4642789 (make sure crypto is >> running: `crypto:start()`). As far as I can see, it's not creating (or >> holding on to) huge pieces of data. >> >> Why is that? >> > > It happens in this line: > lists:seq(0, Products-1)). > because > Products = round(math:pow(length(?CHAR_LIST), TryLength)) = 59^5 = > 714924299 > lists:seq() is, as anything else in Erlang, calculated eagerly, so you get > a full representation of the list. > In a 32-bit Erlang VM, that takes 5,7GB. > > You may want to write a function that folds over a range of integers, and > use that instead of lists:foldl(_,_,lists:seq(A,B)) :-) > > /Erik > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ward@REDACTED Mon Jan 28 10:50:12 2013 From: ward@REDACTED (Ward Bekker (TTY)) Date: Mon, 28 Jan 2013 10:50:12 +0100 Subject: [erlang-questions] Understanding memory usage In-Reply-To: References: <7EFEA754-B706-4358-8896-6E3D196B99D3@tty.nl> Message-ID: Hi Erik, Doh! Thank you very much by pointing that out. That was the fix. Memory consumption is now constant and below 20MB. /W On 28 jan. 2013, at 09:46, Erik S?e S?rensen wrote: > 2013/1/26 Ward Bekker (TTY) > Hi, > > I run into high memory usage (>1.5GB) when running `crack_util:crack` from this module: https://gist.github.com/4642789 (make sure crypto is running: `crypto:start()`). As far as I can see, it's not creating (or holding on to) huge pieces of data. > > Why is that? > > It happens in this line: > lists:seq(0, Products-1)). > because > Products = round(math:pow(length(?CHAR_LIST), TryLength)) = 59^5 = 714924299 > lists:seq() is, as anything else in Erlang, calculated eagerly, so you get a full representation of the list. > In a 32-bit Erlang VM, that takes 5,7GB. > > You may want to write a function that folds over a range of integers, and use that instead of lists:foldl(_,_,lists:seq(A,B)) :-) > > /Erik -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Mon Jan 28 10:58:32 2013 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Mon, 28 Jan 2013 10:58:32 +0100 Subject: [erlang-questions] Message order and exit(Reason) In-Reply-To: <1359365072.70812.YahooMailNeo@web120702.mail.ne1.yahoo.com> References: <1359365072.70812.YahooMailNeo@web120702.mail.ne1.yahoo.com> Message-ID: <51064BC8.9010300@gmail.com> The only place I seem to find this actually described is in the old (never finished) Standard Erlang Specification Draft by Barklund and Virding. In brief, Thomas is right: with regards to propagation and order, exit messages are handled like regular messages. In fact, both are instances of what the spec calls Signals, and the ordering guarantees are valid for all Signals, not just messages. The spec lists the following signals: Messages Exit signals Link requests Unlink requests Group leader request Info request Suspend/resume request Trace/notrace request since the spec is quite old, it is possible that there are now other examples of signals in the system, or that some of the above are obsolete. But the ordering guarantees means that the following code will work as expected: link(PidA), PidA ! 'msg', exit(reason). that is, the link will be set up before 'msg' arrives, and the exit signal will arrive after the message. /Richard On 2013-01-28 10:24 , Thomas Lindgren wrote: > > Hi Dmitrii, > > I think the following means that if A sends M1, M2 to B, then B will > receive M1, M2 in the order of sending. It's not explicitly stated that > exit messages are handled the same way as regular messages, though I > think the default assumption should be that they are. Those here who > have worked on model checking and whatnot, feel free to expound. > > > 10.8 Is the order of message reception guaranteed? > > Yes, but only within one process. > If there is a live process and you send it message A and then message B, > it's guaranteed that if message B arrived, message A arrived before it. > On the other hand, imagine processes P, Q and R. P sends message A to Q, > and then message B to R. There is no guarantee that A arrives before B. > (Distributed Erlang would have a pretty tough time if this was required!) > > http://www.erlang.org/faq/academic.html > > Best, > Thomas > > ------------------------------------------------------------------------ > *From:* Dmitrii Dimandt > *To:* Erlang Questions > *Sent:* Monday, January 28, 2013 10:00 AM > *Subject:* [erlang-questions] Message order and exit(Reason) > > Hi all, > > We've had a semi-heated discussion in Russian community over this > question: http://stackoverflow.com/questions/14556109/race-condition-between-trap-exit-exit-msg-and-common-msg > > The question is as following: Assume we have processes A and B which > are linked. Process's A flag trap_exit is set to true. Let B process > send a msg to A and then exit: > > PidA ! 'msg', > exit(reason). > > What I wanna know if we can be shure that the process A will receive > 'msg' and only after It {'EXIT', Pid, reason} will come ? Can > we predict the ordering of msgs? I can't found any proofs in > documentation, but I guess that it will work that way, but I need > some proofs. Don't want to have race condition here. > > > Can anyone with the intimate knowledge of Erlang internals shed some > light on this? > > 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 jesper.louis.andersen@REDACTED Mon Jan 28 11:07:46 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 28 Jan 2013 11:07:46 +0100 Subject: [erlang-questions] Message order and exit(Reason) In-Reply-To: <51064BC8.9010300@gmail.com> References: <1359365072.70812.YahooMailNeo@web120702.mail.ne1.yahoo.com> <51064BC8.9010300@gmail.com> Message-ID: On Jan 28, 2013, at 10:58 AM, Richard Carlsson wrote: > The only place I seem to find this actually described is in the old (never finished) Standard Erlang Specification Draft by Barklund and Virding. In brief, Thomas is right: with regards to propagation and order, exit messages are handled like regular messages. In fact, both are instances of what the spec calls Signals, and the ordering guarantees are valid for all Signals, not just messages. The spec lists the following signals Right. If you do not have this guarantee, there will be trouble in implementing almost anything. The key is that you can rely on the message order and this vastly simplifies the code base. Since message order is deterministic, you can avoid coding the case where messages arrive out of order sometimes. This in turn makes for simpler code. I would even predict that some things are outright *impossible* to implement if you do not have message ordering guarantees. I know Rickard Green has made the semantics for Ports more clear in R16 because ports will be asynchronous and thus you need to know what guarantees you have about them in your program. This question, about messaging, is the same. In a language like Java or Go, you have a "memory model" which describes the semantics of passing messages and a "happens before" relation. It definitely makes sense to have the same for Erlang, so programmers know what relation they can rely on and what they can't. Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen From eriksoe@REDACTED Mon Jan 28 11:09:28 2013 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Mon, 28 Jan 2013 11:09:28 +0100 Subject: [erlang-questions] A function as an element of a list of action In-Reply-To: References: Message-ID: I think (though I'm not sure) I understand what you're trying to do. If I'm completely off track, perhaps you could be more concrete in your example - especially wrt. what the output should be? If I understand correctly, - having Lc be a dict is a bad idea - if you want to preserve the order of the commands. Use a list instead: Lc = lists:map(fun({density,{true,Value}}, Dict) -> ... end, Lf) - You don't use Value. Where should it be used? I presume it should somehow be part of the context of the inner funs. I think what you want could be something like: Lc = % List of command functions lists:map(fun({density,{true,Value}}, Dict) -> [fun(Dict) -> Dict0=dict:store(top, calc_top(Value), Dict); Dict1=dict:store(bottom, calc_bottom(Value), Dict0); dict:store(side, calc_side(Value, Dict1) end]; ... end, Lf), ... lists:foldl(fun(F,P) -> F(P) end, Params0, Lc) (Not tested!) Hoping this helps (which depends heavily of how well I understood your problem), /Erik 2013/1/25 Micheus > Hi there, > > I did a google search but I couldn't find anything appropriated or I > didn't know how to ask about that. > > I would like to generate a list (based in some criterias - so, it can be > variable) in which each element is an function to be called posteriorly. > Something like a "script". > These functions will receive the same parameters. > > I have an list of "fields" that tell me what I need to do (function to > call) . What I'm looking for is something like this: > > +----------------------------------------------------------------------------------------+ > : > Lf=[{density,{true,Value}}, {ws,{trueValue}}, {hs,{trueValue}}, ... > ,{he,{trueValue}}], > : > Lc=lists:foldl( > fun({density,{true,Value}}, Dict) -> > Dict0=dict:store(top, calc_top/1, Dict); > Dict1=dict:store(bottom, calc_bottom/1, Dict0); > dict:store(side, calc_side/1, Dict1); > ({bf,{true,Value}}, Acc) -> > Dict0=dict:store(bottom, calc_bottom/1, Dict); > dict:store(side, calc_side/1, Dict1); > ({sf,{true,Value}}, Acc) -> > dict:store(side, calc_side/1, Dict); > : > (_, Dict) -> Dict > dict:new(), Lf), > > dict:fold(_Key, Func, Params0) -> > Func(Params0) > Params, Lc), > : > > +----------------------------------------------------------------------------------------+ > > Does someone can help me? > > TIA > Micheus > > _______________________________________________ > 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 Jan 28 11:14:24 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 28 Jan 2013 11:14:24 +0100 Subject: [erlang-questions] A function as an element of a list of action In-Reply-To: References: Message-ID: On Jan 28, 2013, at 11:09 AM, Erik S?e S?rensen wrote: > I think what you want could be something like Would be my solution as well I think. You have data which you turn into code by building a closure for each step. Then you compose your code into a program and execute it. If you fold in the right order, you may be able to pass things around directly in the fold, but note it might take some CPS to get this right. Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen From ingela.andin@REDACTED Mon Jan 28 11:24:19 2013 From: ingela.andin@REDACTED (Ingela Andin) Date: Mon, 28 Jan 2013 11:24:19 +0100 Subject: [erlang-questions] Keepalive in inets In-Reply-To: References: Message-ID: Hi! It was quite a long time ago that I last looked at that code, I think you understand the RFC correctly and it looks like the inets code is broken. We will investigate this further. Regards Ingela Erlang/OTP team - Ericsson AB 2013/1/23, cao xu : > Hi, > > I've posted a question about inets on > stackoverflow?http://stackoverflow.com/q/14473416/918170 > Hope someone could explain it. > Sincerely. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From bgustavsson@REDACTED Mon Jan 28 12:31:04 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 28 Jan 2013 12:31:04 +0100 Subject: [erlang-questions] Variable bindings In-Reply-To: <333D06FA-EB73-4140-A6D2-BB059413A1F5@cs.otago.ac.nz> References: <333D06FA-EB73-4140-A6D2-BB059413A1F5@cs.otago.ac.nz> Message-ID: On Mon, Jan 28, 2013 at 12:40 AM, Richard O'Keefe wrote: > > % convert 2 to floating point (in FR 1) > %?? Why is this not done at compile time? > {fconv,{integer,2},{fr,1}}. > No good reason. I will fix that in R16B. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.virding@REDACTED Mon Jan 28 14:18:38 2013 From: robert.virding@REDACTED (Robert Virding) Date: Mon, 28 Jan 2013 13:18:38 +0000 (GMT) Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: Message-ID: <531807091.3154198.1359379118268.JavaMail.root@erlang-solutions.com> There was an even better one mentioned in the test: if(hasrating) { thechkbox = currRating[0].parentElement.parentElement.parentElement.parentElement.parentElement.parentElement.children(2).children(0).children(0) thechkbox.disabled = false; } :-) ----- Original Message ----- > From: "Garrett Smith" > To: "Robert Virding" > Cc: "Richard O'Keefe" , "erlang-questions Questions" > Sent: Monday, 28 January, 2013 2:57:18 AM > Subject: Re: [erlang-questions] If you are homesick for object.selector > > On Sun, Jan 27, 2013 at 7:23 PM, Robert Virding > wrote: > > > > ----- Original Message ----- > >> From: "Richard O'Keefe" > >> > >> This is _so_ on-topic... > >> > >> http://thedailywtf.com/Articles/Ancestors.aspx > > > > Think how much more difficult to read it would have been if you had > > to include the record names. :-) > > For the benefit of those who didn't click the link, it contains this > function in C#: > > private void MouseMove(object sender, MouseEventArgs e) > { > (sender as > PictureBox).Parent.Parent.Parent.Parent.Parent.GetType(); > } > > After seeing that, I'm convinced Erlang record syntax is one the > language's best features. If other languages had such a tax, this > sort > of thing would be held in check. > > Call it a sin tax. > > Get it? > > Garrett > From essen@REDACTED Mon Jan 28 18:08:27 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Mon, 28 Jan 2013 18:08:27 +0100 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <27483647-10A7-4521-8376-A497854A5CBC@cs.otago.ac.nz> <704615102.3084165.1359336199090.JavaMail.root@erlang-solutions.com> Message-ID: <5106B08B.4020105@ninenines.eu> On 01/28/2013 02:57 AM, Garrett Smith wrote: > On Sun, Jan 27, 2013 at 7:23 PM, Robert Virding > wrote: >> >> ----- Original Message ----- >>> From: "Richard O'Keefe" >>> >>> This is _so_ on-topic... >>> >>> http://thedailywtf.com/Articles/Ancestors.aspx >> >> Think how much more difficult to read it would have been if you had to include the record names. :-) > > For the benefit of those who didn't click the link, it contains this > function in C#: > > private void MouseMove(object sender, MouseEventArgs e) > { > (sender as PictureBox).Parent.Parent.Parent.Parent.Parent.GetType(); > } > > After seeing that, I'm convinced Erlang record syntax is one the > language's best features. If other languages had such a tax, this sort > of thing would be held in check. > > Call it a sin tax. Except that's completely different from what we'd like to have. * We do not want a parent() mechanism. * We do not want pointers or references. * We do not want to be able to call functions. Also note that with regards to Erlang, it's *not* syntax that prevents this kind of behavior, but processes and message passing. Your process can only handle so much. We just need a data structure and associated syntax that's convenient for semi-deep data structures, where the fields are clearly defined (like a record), except field resolution would be performed at runtime to allow chaining and thus easier pattern match and/or modification. And ironically it could also easily solve the record upgrade problem, because you'd have the fields at runtime. Data manipulation is something that can make or break projects, and is the reason why I stopped one of mine, because all the solutions you can think of are light years away of what can be achieved with very little language support. Of course, language support means first acknowledging there is indeed a problem, and I am not surprised to hit walls here, especially in the "you just need functions" crowd (who don't seem to be aware of how nice pattern matching in function clauses and guards are). So I'll experiment on my end for a while and if it turns out that it works I might just use this new language for the previously mentioned project. That'd certainly motivate me enough to reboot it. Have a nice day. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From g@REDACTED Mon Jan 28 18:40:51 2013 From: g@REDACTED (Garrett Smith) Date: Mon, 28 Jan 2013 11:40:51 -0600 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <5106B08B.4020105@ninenines.eu> References: <27483647-10A7-4521-8376-A497854A5CBC@cs.otago.ac.nz> <704615102.3084165.1359336199090.JavaMail.root@erlang-solutions.com> <5106B08B.4020105@ninenines.eu> Message-ID: On Mon, Jan 28, 2013 at 11:08 AM, Lo?c Hoguin wrote: > On 01/28/2013 02:57 AM, Garrett Smith wrote: >> >> On Sun, Jan 27, 2013 at 7:23 PM, Robert Virding >> wrote: >>> >>> >>> ----- Original Message ----- >>>> >>>> From: "Richard O'Keefe" >>>> >>>> This is _so_ on-topic... >>>> >>>> http://thedailywtf.com/Articles/Ancestors.aspx >>> >>> >>> Think how much more difficult to read it would have been if you had to >>> include the record names. :-) >> >> >> For the benefit of those who didn't click the link, it contains this >> function in C#: >> >> private void MouseMove(object sender, MouseEventArgs e) >> { >> (sender as PictureBox).Parent.Parent.Parent.Parent.Parent.GetType(); >> } >> >> After seeing that, I'm convinced Erlang record syntax is one the >> language's best features. If other languages had such a tax, this sort >> of thing would be held in check. >> >> Call it a sin tax. > > > Except that's completely different from what we'd like to have. > > * We do not want a parent() mechanism. > * We do not want pointers or references. > * We do not want to be able to call functions. > > Also note that with regards to Erlang, it's *not* syntax that prevents this > kind of behavior, but processes and message passing. Your process can only > handle so much. > > We just need a data structure and associated syntax that's convenient for > semi-deep data structures, where the fields are clearly defined (like a > record), except field resolution would be performed at runtime to allow > chaining and thus easier pattern match and/or modification. And ironically > it could also easily solve the record upgrade problem, because you'd have > the fields at runtime. Isn't this close to frames? I'm somehow under the impression that Ericsson has a "maps" (or similarly named feature) that's near release. Unless I've missed something, perhaps a status update on the "frames" problem might bring this thread to a happier conclusion. > Data manipulation is something that can make or break projects, and is the > reason why I stopped one of mine, because all the solutions you can think of > are light years away of what can be achieved with very little language > support. > > Of course, language support means first acknowledging there is indeed a > problem, and I am not surprised to hit walls here, especially in the "you > just need functions" crowd (who don't seem to be aware of how nice pattern > matching in function clauses and guards are). So I'll experiment on my end > for a while and if it turns out that it works I might just use this new > language for the previously mentioned project. That'd certainly motivate me > enough to reboot it. I still think you want a relational model for your gaming use case. SQLite + memory db FTW! Garrett From tyron.zerafa@REDACTED Mon Jan 28 19:23:53 2013 From: tyron.zerafa@REDACTED (Tyron Zerafa) Date: Mon, 28 Jan 2013 19:23:53 +0100 Subject: [erlang-questions] Variable bindings In-Reply-To: <333D06FA-EB73-4140-A6D2-BB059413A1F5@cs.otago.ac.nz> References: <333D06FA-EB73-4140-A6D2-BB059413A1F5@cs.otago.ac.nz> Message-ID: >>The problem is that funs don't normally _have_ code available >>unless you compile the containing module with a special option. >>Have you considered the alternative of accepting the *source code* >>of a fun and parsing that? I have considered this option but as far as possible we do not want to change any syntax. The final objective is to have the same spawn(N,F) syntax but which is capable of accepting and executing F on the remote node irrelevant of whether the code is there or not. >>Er, the free variables of a fun are _not_ the variables that are >>in scope at its point of creation, they are that subset of those >>variables that are *used* inside the fun. >>What a fun _is_, conceptually, is a tuple containing a code reference >>and a set of variable bindings. If someone gives you a fun, you know >>exactly what the values for those variables are because they are right >>there. A fun does not point back to the stack frame of its creator. Our intention is to change exactly this; i.e. what fun actually _is_. We are trying to change from the current ETF for fun to one containing also the function's code tree or some other presentation. Since fun does not point back to the stack frame, our current implementation is passing the required environment variables as part of the fun's parameter list, thus shadowing the original one. In practice *?x:x+y * * * becomes * * *?x,y:x+y *<- this gets serialized and transferred. * * In regards to version consistency, we are not using the original module name, but renaming to module@REDACTED This would not break anything on the remote node. It goes without saying that any code transferred to the remote node reflects this change in mod name. Thanks for your insight :) On Mon, Jan 28, 2013 at 12:40 AM, Richard O'Keefe wrote: > > On 28/01/2013, at 12:11 AM, Tyron Zerafa wrote: > > > I want to build a call which accepts a fun, extracts all of its code and > dependencies, pass everything over to a remote node and execute it there. > > The problem is that funs don't normally _have_ code available > unless you compile the containing module with a special option. > > Have you considered the alternative of accepting the *source code* > of a fun and parsing that? > > > The only problem I am having is extracting the value of the free vars of > such fun. > > Er, the free variables of a fun are _not_ the variables that are > in scope at its point of creation, they are that subset of those > variables that are *used* inside the fun. > > What a fun _is_, conceptually, is a tuple containing a code reference > and a set of variable bindings. If someone gives you a fun, you know > exactly what the values for those variables are because they are right > there. A fun does not point back to the stack frame of its creator. > > Let's take a look at a tiny example. > > foo(X, Y) -> > M = (X+Y)/2, > fun (Z) -> {Z,M} end. > > Now let's look at the BEAM code. > > {function, foo, 2, 2}. > {label,1}. > {func_info,{atom,foo},{atom,foo},2}. > {label,2}. > % add Y to X; put the result back in X > {gc_bif,'+',{f,0},2,[{x,0},{x,1}],{x,0}}. > % check that there is room for two floats > {test_heap,{alloc,[{words,0},{floats,1}]},2}. > % convert X to floating point (in FR 0) > {fconv,{x,0},{fr,0}}. > % convert 2 to floating point (in FR 1) > %?? Why is this not done at compile time? > {fconv,{integer,2},{fr,1}}. > fclearerror. > % Divide FR 0 by FR 1 and put the result in FR 0. > {bif,fdiv,{f,0},[{fr,0},{fr,1}],{fr,0}}. > {fcheckerror,{f,0}}. > % Now that we know all went well, box the result > % and put it back in X. > {fmove,{fr,0},{x,0}}. > {'%live',1}. > % Create a fun, copying X (but not what X points to) > % into it. > {make_fun2,{f,8},0,98308069,1}. > return. > > {function, '-foo/2-fun-0-', 2, 8}. > {label,7}. > {func_info,{atom,foo},{atom,'-foo/2-fun-0-'},2}. > % {f,8} in the make_fun2 instruction points here. > {label,8}. > % Check that there is room for a 2-tuple > {test_heap,3,2}. > % start to create it, and let X2 point to it. > {put_tuple,2,{x,2}}. > % put in Z > {put,{x,0}}. > % put in M > {put,{x,1}}. > % move X2 down to X0 > {move,{x,2},{x,0}}. > % return X0 > return. > > > I was thinking about adding these to the parameter list of the fun, > > As the code shows, the (selected) free variables _are_ hidden > parameters of the fun. > > > i.e shadowing the respective vars. > > ? > > Finding the dependencies of a fun, at least those not already > compiled inline, can be done from its BEAM code. You do not > need the source code. What you cannot get, either way, is > which _versions_ of the modules used the code depends on. > > And that creates a big problem. > > On local node L, send F1 to remote node R. > F1 needs module M. > Ensure that R has M loaded. > But M on R is a completely different module from M on L. > So send L to R as well and have it install that. > Congratulations, you just broke everything else on R > that used M. > > If you can manage version consistency to the point at > which every node you try to send stuff to has the same > versions of all the relevant modules you need, then you > don't need to extract dependencies at run time. > If you can't do that, it's not going to work anyway. > > This whole sending-code-to-a-remote-node business is to be done > with *extreme* vigilant trepidation, if at all. > > Do you *really* want me to be able to call > your_module:your_handy_function(fun () -> halt() end) > > Consider whether it is possible to devise a *sublanguage* of > trustworthy code. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Mon Jan 28 19:49:18 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Mon, 28 Jan 2013 19:49:18 +0100 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <27483647-10A7-4521-8376-A497854A5CBC@cs.otago.ac.nz> <704615102.3084165.1359336199090.JavaMail.root@erlang-solutions.com> <5106B08B.4020105@ninenines.eu> Message-ID: <5106C82E.90703@ninenines.eu> On 01/28/2013 06:40 PM, Garrett Smith wrote: > On Mon, Jan 28, 2013 at 11:08 AM, Lo?c Hoguin wrote: >> On 01/28/2013 02:57 AM, Garrett Smith wrote: >>> >>> On Sun, Jan 27, 2013 at 7:23 PM, Robert Virding >>> wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> >>>>> From: "Richard O'Keefe" >>>>> >>>>> This is _so_ on-topic... >>>>> >>>>> http://thedailywtf.com/Articles/Ancestors.aspx >>>> >>>> >>>> Think how much more difficult to read it would have been if you had to >>>> include the record names. :-) >>> >>> >>> For the benefit of those who didn't click the link, it contains this >>> function in C#: >>> >>> private void MouseMove(object sender, MouseEventArgs e) >>> { >>> (sender as PictureBox).Parent.Parent.Parent.Parent.Parent.GetType(); >>> } >>> >>> After seeing that, I'm convinced Erlang record syntax is one the >>> language's best features. If other languages had such a tax, this sort >>> of thing would be held in check. >>> >>> Call it a sin tax. >> >> >> Except that's completely different from what we'd like to have. >> >> * We do not want a parent() mechanism. >> * We do not want pointers or references. >> * We do not want to be able to call functions. >> >> Also note that with regards to Erlang, it's *not* syntax that prevents this >> kind of behavior, but processes and message passing. Your process can only >> handle so much. >> >> We just need a data structure and associated syntax that's convenient for >> semi-deep data structures, where the fields are clearly defined (like a >> record), except field resolution would be performed at runtime to allow >> chaining and thus easier pattern match and/or modification. And ironically >> it could also easily solve the record upgrade problem, because you'd have >> the fields at runtime. > > Isn't this close to frames? I'm somehow under the impression that > Ericsson has a "maps" (or similarly named feature) that's near > release. > > Unless I've missed something, perhaps a status update on the "frames" > problem might bring this thread to a happier conclusion. Close. But not quite (at least in its current form). Here we are talking about a data structure with fixed fields, like records, which allows amongst other things type checking (dialyzer and runtime). Frames would be "better than nothing" but at the last EUC the only thing related was a benchmark of hash implementations to see which one is best for eventual inclusion. Sounds like it's the last thing that should be done though, make it work, make it pretty, make it fast. Many people would be fine with just the first two (and that's what I'll do in my experiments). >> Data manipulation is something that can make or break projects, and is the >> reason why I stopped one of mine, because all the solutions you can think of >> are light years away of what can be achieved with very little language >> support. >> >> Of course, language support means first acknowledging there is indeed a >> problem, and I am not surprised to hit walls here, especially in the "you >> just need functions" crowd (who don't seem to be aware of how nice pattern >> matching in function clauses and guards are). So I'll experiment on my end >> for a while and if it turns out that it works I might just use this new >> language for the previously mentioned project. That'd certainly motivate me >> enough to reboot it. > > I still think you want a relational model for your gaming use case. > SQLite + memory db FTW! Half of this data is temporary to the current session. The other half is tied to the first half, and only needs to be retrieved and saved at key intervals. A relational database fits the storage of the permanent data. It however again only complexifies the manipulation. It would also likely not scale much. A game has a lot of things happening per player and you need one or the other value available for use or to send it to the client when needed and not 2 seconds later. But regardless, you're still just proposing solutions that increase the complexity of the work one has to do. I know there's currently no good solution for this in Erlang, you don't need to convince me. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From emmiller@REDACTED Mon Jan 28 17:16:07 2013 From: emmiller@REDACTED (Evan Miller) Date: Mon, 28 Jan 2013 10:16:07 -0600 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <531807091.3154198.1359379118268.JavaMail.root@erlang-solutions.com> References: <531807091.3154198.1359379118268.JavaMail.root@erlang-solutions.com> Message-ID: On Mon, Jan 28, 2013 at 7:18 AM, Robert Virding wrote: > There was an even better one mentioned in the test: > > if(hasrating) > { > thechkbox = currRating[0].parentElement.parentElement.parentElement.parentElement.parentElement.parentElement.children(2).children(0).children(0) > thechkbox.disabled = false; > } > > :-) > >From my understanding of the Law of Demeter, a proper rewrite would look like: if (hasrating) { thechkbox = currRating[0].firstChildOfFirstChildOfThirdChildOfParentOfParentOfParentOfParentOfParentOfParent(); thechkbox.disabled = false; } -- Evan Miller http://www.evanmiller.org/ From kenneth.lundin@REDACTED Mon Jan 28 17:04:52 2013 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Mon, 28 Jan 2013 17:04:52 +0100 Subject: [erlang-questions] OTP R16 beta is soon to be released, help us test it! Message-ID: > > Hi, > > The R16 beta (called R16A by tradition) will be released on Wednesday, > January 30:th. > > We encourage you to test it and come with feedback as soon as possible so > that we if necessary can make corrections before the R16B release on > February 28. > > There are a number of intentional incompatibilities (since this is a new > major release) which we have judged to be good for the continued > development of Erlang/OTP, but that will require no or minor changes on > existing applications. > The beta release is extensively tested by us, but since there are many changes we can never know if there has slipped in some unexpected incompatibilities or other problems that don't show up in our tests. So please try to build and run your current products/applications and tell us if you find any unexpected problems, that cannot be explained with the description of potential incompatibilities that you will find in the README of the release. /Regards Kenneth, Erlang/OTP Ericsson > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g@REDACTED Mon Jan 28 20:04:36 2013 From: g@REDACTED (Garrett Smith) Date: Mon, 28 Jan 2013 13:04:36 -0600 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <5106C82E.90703@ninenines.eu> References: <27483647-10A7-4521-8376-A497854A5CBC@cs.otago.ac.nz> <704615102.3084165.1359336199090.JavaMail.root@erlang-solutions.com> <5106B08B.4020105@ninenines.eu> <5106C82E.90703@ninenines.eu> Message-ID: On Mon, Jan 28, 2013 at 12:49 PM, Lo?c Hoguin wrote: > On 01/28/2013 06:40 PM, Garrett Smith wrote: > >> On Mon, Jan 28, 2013 at 11:08 AM, Lo?c Hoguin wrote: >>> >>> On 01/28/2013 02:57 AM, Garrett Smith wrote: >>>> >>>> >>>> On Sun, Jan 27, 2013 at 7:23 PM, Robert Virding >>>> wrote: >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> >>>>>> >>>>>> From: "Richard O'Keefe" >>>>>> >>>>>> This is _so_ on-topic... >>>>>> >>>>>> http://thedailywtf.com/Articles/Ancestors.aspx >>>>> >>>>> >>>>> >>>>> Think how much more difficult to read it would have been if you had to >>>>> include the record names. :-) >>>> >>>> >>>> >>>> For the benefit of those who didn't click the link, it contains this >>>> function in C#: >>>> >>>> private void MouseMove(object sender, MouseEventArgs e) >>>> { >>>> (sender as >>>> PictureBox).Parent.Parent.Parent.Parent.Parent.GetType(); >>>> } >>>> >>>> After seeing that, I'm convinced Erlang record syntax is one the >>>> language's best features. If other languages had such a tax, this sort >>>> of thing would be held in check. >>>> >>>> Call it a sin tax. >>> >>> >>> >>> Except that's completely different from what we'd like to have. >>> >>> * We do not want a parent() mechanism. >>> * We do not want pointers or references. >>> * We do not want to be able to call functions. >>> >>> Also note that with regards to Erlang, it's *not* syntax that prevents >>> this >>> kind of behavior, but processes and message passing. Your process can >>> only >>> handle so much. >>> >>> We just need a data structure and associated syntax that's convenient for >>> semi-deep data structures, where the fields are clearly defined (like a >>> record), except field resolution would be performed at runtime to allow >>> chaining and thus easier pattern match and/or modification. And >>> ironically >>> it could also easily solve the record upgrade problem, because you'd have >>> the fields at runtime. >> >> >> Isn't this close to frames? I'm somehow under the impression that >> Ericsson has a "maps" (or similarly named feature) that's near >> release. >> >> Unless I've missed something, perhaps a status update on the "frames" >> problem might bring this thread to a happier conclusion. > > > Close. But not quite (at least in its current form). > > Here we are talking about a data structure with fixed fields, like records, > which allows amongst other things type checking (dialyzer and runtime). > > Frames would be "better than nothing" but at the last EUC the only thing > related was a benchmark of hash implementations to see which one is best for > eventual inclusion. Sounds like it's the last thing that should be done > though, make it work, make it pretty, make it fast. Many people would be > fine with just the first two (and that's what I'll do in my experiments). > > >>> Data manipulation is something that can make or break projects, and is >>> the >>> reason why I stopped one of mine, because all the solutions you can think >>> of >>> are light years away of what can be achieved with very little language >>> support. >>> >>> Of course, language support means first acknowledging there is indeed a >>> problem, and I am not surprised to hit walls here, especially in the "you >>> just need functions" crowd (who don't seem to be aware of how nice >>> pattern >>> matching in function clauses and guards are). So I'll experiment on my >>> end >>> for a while and if it turns out that it works I might just use this new >>> language for the previously mentioned project. That'd certainly motivate >>> me >>> enough to reboot it. >> >> >> I still think you want a relational model for your gaming use case. >> SQLite + memory db FTW! > > > Half of this data is temporary to the current session. The other half is > tied to the first half, and only needs to be retrieved and saved at key > intervals. A relational database fits the storage of the permanent data. It > however again only complexifies the manipulation. It would also likely not > scale much. A game has a lot of things happening per player and you need one > or the other value available for use or to send it to the client when needed > and not 2 seconds later. I'm talking about 1 in-memory db per process. I have no idea how this would perform -- I'm *mainly* trying to see how long we can make this thread :) Nonetheless, if I had a complex data structure that was subject to change (new features, etc.) I'd be tempted to use a relational model. Erlang + native SQLite bindings might be quite fast -- I have no idea, but I'd give it a try and measure. Of course then you'd *really* need a functional facade -- and how beautiful would that be? Garrett From steve@REDACTED Mon Jan 28 20:00:53 2013 From: steve@REDACTED (Steve Strong) Date: Mon, 28 Jan 2013 20:00:53 +0100 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <531807091.3154198.1359379118268.JavaMail.root@erlang-solutions.com> Message-ID: Lol, excellent :) Sent from my iPhone On 28 Jan 2013, at 17:16, Evan Miller wrote: > On Mon, Jan 28, 2013 at 7:18 AM, Robert Virding > wrote: >> There was an even better one mentioned in the test: >> >> if(hasrating) >> { >> thechkbox = currRating[0].parentElement.parentElement.parentElement.parentElement.parentElement.parentElement.children(2).children(0).children(0) >> thechkbox.disabled = false; >> } >> >> :-) > > From my understanding of the Law of Demeter, a proper rewrite would look like: > > if (hasrating) > { > thechkbox = currRating[0].firstChildOfFirstChildOfThirdChildOfParentOfParentOfParentOfParentOfParentOfParent(); > thechkbox.disabled = false; > } > > -- > Evan Miller > http://www.evanmiller.org/ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From raould@REDACTED Mon Jan 28 19:12:07 2013 From: raould@REDACTED (Raoul Duke) Date: Mon, 28 Jan 2013 10:12:07 -0800 Subject: [erlang-questions] dialyzer for lisps (Re: If you are homesick for object.selector) In-Reply-To: <2121730453.3084280.1359337357092.JavaMail.root@erlang-solutions.com> References: <57E1CAD1-EA42-4406-881B-2E701FAE432A@gmail.com> <2121730453.3084280.1359337357092.JavaMail.root@erlang-solutions.com> Message-ID: > Making read it read source files from other front-ends which generate core erlang would not be too difficult. The main problem is that it is hard-coded that dialyzer assumes that source files end with .erl. cool! who has the time and brains (not i!) to make a patch for this? seems like there's more than one project interested in the direction now :-) From raould@REDACTED Mon Jan 28 19:15:39 2013 From: raould@REDACTED (Raoul Duke) Date: Mon, 28 Jan 2013 10:15:39 -0800 Subject: [erlang-questions] game coding style (Re: If you are homesick for object.selector) Message-ID: > I still think you want a relational model for your gaming use case. > SQLite + memory db FTW! as a small-time game developer (well, i've had real jobs doing real games, but not these days) and as somebody who likes to read www.lambda-the-ultimate.org in addition to game dev sites, i have also come around to seeing that, at least, most uses of OO for game (and simulation in general, even given the history of OO) development are just leading to trouble. sincerely. From define.null@REDACTED Mon Jan 28 20:30:43 2013 From: define.null@REDACTED (Defnull) Date: Mon, 28 Jan 2013 11:30:43 -0800 (PST) Subject: [erlang-questions] Message order and exit(Reason) In-Reply-To: References: <1359365072.70812.YahooMailNeo@web120702.mail.ne1.yahoo.com> <51064BC8.9010300@gmail.com> Message-ID: <3956ee85-a85d-44a3-9d78-2dd9b3e62486@googlegroups.com> Thank you for reply, I hope this will appear in the documentation soon and I'm a little bit confused why there is no information covering this topic about signals in the documentation right now. Maybe someone who know internals could answer it? What should we do to make it appear in the documentation? -------------- next part -------------- An HTML attachment was scrubbed... URL: From micheus@REDACTED Mon Jan 28 20:55:18 2013 From: micheus@REDACTED (Micheus) Date: Mon, 28 Jan 2013 17:55:18 -0200 Subject: [erlang-questions] A function as an element of a list of action In-Reply-To: References: Message-ID: Thanks Jesper and Erik by your comments. I'll give you more details about what I trying to do, but I believe that the suggestion here will help me. :) I'm coding a "terrain" maker for Wings3d (heightmap plugin). There are some parameters in the form that will result in many different calculations. You can see them in this picture: http://imageshack.us/f/820/density100.png/ As the list of vertices can be ~147K, I would like to minimize the calcs by fragmenting the code. If the density is changed, then the entire parameters (vertices and faces) need to be recalculated. But if the used just decide to create or not the side faces then I don't need to calculate everything again. What I thought was to check for every field (parameter) in the form and build an list of what I need to recalculate. I used to store in a {key,data} format because some operations (function to be called) will be repeated for different parameters, but - at the end - it would exists only once in the list. I've it implemented this way: : case changed_field(Old_Res,Res) of {bf, _} -> VsBottom0=create_normalized_bottom(W,H,What,VsTop), FsBottom0=create_faces_bottom(W,H,What), FsSide0=create_faces_side(W,H,What), He0=create_hard_edges(W,H,What,HardEdges), {{VsTop,VsBottom0},{FsTop,FsBottom0,FsSide0},He0}; {sf, _} -> VsBottom0=create_normalized_bottom(W,H,What,VsTop), FsBottom0=create_faces_bottom(W,H,What), FsSide0=create_faces_side(W,H,What), He0=create_hard_edges(W,H,What,HardEdges), {{VsTop,VsBottom0},{FsTop,FsBottom0,FsSide0},He0}; {gv, _} -> VsTop0=set_ground(CLo,VsTop), {{VsTop0,VsBottom},{FsTop,FsBottom,FsSide},He}; {he, Value} -> He0=create_hard_edges(W,H,What,Value), {{VsTop,VsBottom},{FsTop,FsBottom,FsSide},He0}; {Fld, _} when Fld=:=density; Fld=:=ih; Fld=:=iw-> process_surface(Res); {Fld, _} when Fld=:=scut_lo; Fld=:=scut_hi; Fld=:=es; Fld=:=hs; Fld=:=ws; Fld=:=ar -> Els=wings_pref:get_value(heightmap_elevation), VsTop3=create_normalized_top(W,H,Els), VsBottom1=create_normalized_bottom(W,H,What,VsTop3), VsTop2=set_ground(CLo,VsTop3), VsTop1=cut(CLo,CHi,VsTop2), {VsTop0,VsBottom0}=scale(Wm,Em,Hm,{VsTop1,VsBottom1}), {{VsTop0,VsBottom0},{FsTop,FsBottom,FsSide},He}; _ -> Old_Data end. : it's supposing that there is only one field being changed each time it is processed, but it should check for a list. So, that "case" should be in a lists:foreach and the code that has being ran for each option should be processed only after I build this list of function I'm looking for. I hope I could clarify about what I'm trying to do. (English is not my first language) /Micheus -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard@REDACTED Mon Jan 28 22:34:43 2013 From: rickard@REDACTED (Rickard Green) Date: Mon, 28 Jan 2013 22:34:43 +0100 Subject: [erlang-questions] Message order and exit(Reason) In-Reply-To: References: Message-ID: <5106EEF3.7020200@erlang.org> Dmitrii Dimandt wrote: > > The question is as following: Assume we have processes A and B which > are linked. Process's A flag trap_exit is set to true. Let B process > send a msg to A and then exit: > > PidA ! 'msg', > exit(reason). > > What I wanna know if we can be shure that the process A will receive > 'msg' and only after It {'EXIT', Pid, reason} will come ? The order is guaranteed to be preserved here. > Can > we predict the ordering of msgs? I can't found any proofs in > documentation, but I guess that it will work that way, but I need some > proofs. Don't want to have race condition here. > Unfortunately our documentation lacked this information. In R16 the following chapter will be part of the ERTS User's guide. Cut from ERTS-5.10 User's Guide: > > 1 Communication in Erlang > > Communication in Erlang is conceptually performed using asynchronous signaling. All different executing entities such as processes, and ports communicate via asynchronous signals. The most commonly used signal is a message. Other common signals are exit, link, unlink, monitor, demonitor signals. > > 1.1 Passing of Signals > > The amount of time that passes between a signal being sent and the arrival of the signal at the destination is unspecified but positive. If the receiver has terminated, the signal will not arrive, but it is possible that it triggers another signal. For example, a link signal sent to a non-existing process will trigger an exit signal which will be sent back to where the link signal originated from. When communicating over the distribution, signals may be lost if the distribution channel goes down. > > The only signal ordering guarantee given is the following. If an entity sends multiple signals to the same destination entity, the order will be preserved. That is, if A send a signal S1 to B, and later sends the signal S2 to B, S1 is guaranteed not to arrive after S2. > > 1.2 Synchronous Communication > > Some communication is synchronous. If broken down into pieces, a synchronous communication operation, consists of two asynchronous signals. One request signal and one reply signal. An example of such a synchronous communication is a call to process_info/2 when the first argument is not self(). The caller will send an asynchronous signal requesting information, and will then wait for the reply signal containing the requested information. When the request signal reaches its destination the destination process replies with the requested information. > > 1.3 Implementation > > The implementation of different asynchronous signals in the VM may vary over time, but the behavior will always respect this concept of asynchronous signals being passed between entities as described above. > > By inspecting the implementation you might notice that some specific signal actually gives a stricter guarantee than described above. It is of vital importance that such knowledge about the implementation is *not* used by Erlang code, since the implementation might change at any time without prior notice. > > Some example of major implementation changes: > > As of ERTS version 5.5.2 exit signals to processes are truly asynchronously delivered. > As of ERTS version 5.10 all signals from processes to ports are truly asynchronously delivered. > Richard Carlsson wrote: > The only place I seem to find this actually described is in the old > (never finished) Standard Erlang Specification Draft by Barklund and > Virding. In brief, Thomas is right: with regards to propagation and > order, exit messages are handled like regular messages. In fact, both > are instances of what the spec calls Signals, and the ordering > guarantees are valid for all Signals, not just messages. The wording in 1.1 above is more or less "stolen" from the Barklund/Virding spec . Unfortunately the spec was never completed. I find the spec really valuable. Hopefully, we will some day find the time to update and finish it. Perhaps we could get some help from the original authors; hint hint :-) Regards, Rickard -- Rickard Green, Erlang/OTP, Ericsson AB. From tamas@REDACTED Mon Jan 28 22:36:50 2013 From: tamas@REDACTED (=?iso-8859-1?Q?Szepes_Tam=E1s?=) Date: Mon, 28 Jan 2013 22:36:50 +0100 Subject: [erlang-questions] Mnesia normalized field lookup In-Reply-To: References: <000f01cdfcb8$3ea623f0$bbf26bd0$@veriport.eu> Message-ID: <001601cdfd9f$961246e0$c236d4a0$@veriport.eu> Thanks, but I rather thought about a library that automates these lookups behind the scene. Maybe through a customized activity access callback module or somehow with the traverse parameter of mnesia:table/2. Tamas From: Chandru [mailto:chandrashekhar.mullaparthi@REDACTED] Sent: Monday, January 28, 2013 12:04 AM To: Szepes Tam?s Cc: erlang-questions@REDACTED Subject: Re: [erlang-questions] Mnesia normalized field lookup You could consider computing the hash of your value, and store the mapping from actual value to hash value in another table. When writing your record, store the hash value instead of the actual value. When you need to retrieve the original, use the mapping table to map the hashed value to the actual value. Does that make sense? Chandru On 27 January 2013 18:00, Szepes Tam?s wrote: All, I have couple of Mnesia tables where the records has some long text fields with relatively little variation in content (like institute_name which can be 128 characters long, but in a typical installation there is no more than 20 different values). About 1/3 of my fields are similar and I cannot determine all possible values in advance to make atoms for them (data from a new institute can come any time after installation, and the database needs to be self contained for archiving purposes). As I need to handle ~10^8 records I?d like to normalize these fields to spare storage space. However it blows my code if I have to do 3-6 joins in every lookup operation, not to mention the inserts. Is there any elegant way of handling this situation? Thanks in advance, Tamas _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From desired.mta@REDACTED Mon Jan 28 22:53:48 2013 From: desired.mta@REDACTED (=?UTF-8?Q?Motiejus_Jak=C5=A1tys?=) Date: Mon, 28 Jan 2013 21:53:48 +0000 Subject: [erlang-questions] Mnesia normalized field lookup In-Reply-To: <000f01cdfcb8$3ea623f0$bbf26bd0$@veriport.eu> References: <000f01cdfcb8$3ea623f0$bbf26bd0$@veriport.eu> Message-ID: On Sun, Jan 27, 2013 at 6:00 PM, Szepes Tam?s wrote: > As I need to handle ~10^8 records I?d like to normalize these fields to > spare storage space. However it blows my code if I have to do 3-6 joins in > every lookup operation, not to mention the inserts. > Is there any elegant way of handling this situation? Hi, this sounds very much like a task for a relational database, for which mnesia is not the best use case. Why not sqlite? -- Motiejus Jak?tys From ok@REDACTED Tue Jan 29 01:07:39 2013 From: ok@REDACTED (Richard O'Keefe) Date: Tue, 29 Jan 2013 13:07:39 +1300 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: <5106C82E.90703@ninenines.eu> References: <27483647-10A7-4521-8376-A497854A5CBC@cs.otago.ac.nz> <704615102.3084165.1359336199090.JavaMail.root@erlang-solutions.com> <5106B08B.4020105@ninenines.eu> <5106C82E.90703@ninenines.eu> Message-ID: <33B085B5-5672-42A3-86B6-12B5CE99D761@cs.otago.ac.nz> On 29/01/2013, at 7:49 AM, Lo?c Hoguin wrote: > Frames would be "better than nothing" but at the last EUC the only thing related was a benchmark of hash implementations to see which one is best for eventual inclusion. Sounds like it's the last thing that should be done though, make it work, make it pretty, make it fast. Many people would be fine with just the first two (and that's what I'll do in my experiments). The frames paper actually explains why hash tables are the *wrong* way to implement them and presents a very lightweight (and empirically fast _enough_) implementation technique. From ok@REDACTED Tue Jan 29 01:08:52 2013 From: ok@REDACTED (Richard O'Keefe) Date: Tue, 29 Jan 2013 13:08:52 +1300 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <531807091.3154198.1359379118268.JavaMail.root@erlang-solutions.com> Message-ID: <5336CA6A-2C8C-4804-8783-B4946E218D61@cs.otago.ac.nz> On 29/01/2013, at 5:16 AM, Evan Miller wrote: > From my understanding of the Law of Demeter, a proper rewrite would look like: > > if (hasrating) > { > thechkbox = currRating[0].firstChildOfFirstChildOfThirdChildOfParentOfParentOfParentOfParentOfParentOfParent(); > thechkbox.disabled = false; > } No, it would be something like if (has_rating) ratable_part().disable_checkbox(); From ok@REDACTED Tue Jan 29 01:23:56 2013 From: ok@REDACTED (Richard O'Keefe) Date: Tue, 29 Jan 2013 13:23:56 +1300 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <27483647-10A7-4521-8376-A497854A5CBC@cs.otago.ac.nz> <704615102.3084165.1359336199090.JavaMail.root@erlang-solutions.com> <5106B08B.4020105@ninenines.eu> <5106C82E.90703@ninenines.eu> Message-ID: <329C420C-52C8-45AD-8C32-7418D338C203@cs.otago.ac.nz> Speaking of alternative models, one approach is to move from thinking of ::= | [{,] where you are thinking of a thing as a tree with edges labelled by keys and leaves labelled with scalars, to ::= finite map [] -> for which an interface like thing_has(Thing, Path) thing_get(Thing, Path) thing_get(Thing, Path, Default) thing_put(Thing, Path, Value) thing_add(Thing, Path, Value) thing_rem(Thing, Path) makes sense. This thing could really be a tree underneath, or it could be a dictionary with paths as keys and leaves as values, or it could be some sort of factored representation. Or it could be a process, with the paths being used as keys in that process's dictionary. It may _look_ like a duck; it may _quack_ like a duck; but it's _really_ a Psychon. ( http://en.wikipedia.org/wiki/Maya_(Space:_1999) ) Out of the many things that are not clear to me, one of them is a typical total number of paths relevant to one of these game characters we have heard so much and seen so little of. At some point, it would make sense to annoint one dictionary _interface_ and provide special brief syntax for using it From ok@REDACTED Tue Jan 29 01:28:32 2013 From: ok@REDACTED (Richard O'Keefe) Date: Tue, 29 Jan 2013 13:28:32 +1300 Subject: [erlang-questions] Message order and exit(Reason) In-Reply-To: <5106EEF3.7020200@erlang.org> References: <5106EEF3.7020200@erlang.org> Message-ID: On 29/01/2013, at 10:34 AM, Rickard Green wrote: >> The only signal ordering guarantee given is the following. If an entity sends multiple signals to the same destination entity, the order will be preserved. That is, if A send a signal S1 to B, and later sends the signal S2 to B, S1 is guaranteed not to arrive after S2. s/if A send/if A sends/ >> >> The implementation of different asynchronous signals in the VM may vary over time, but the behavior will always respect this concept of asynchronous signals being passed between entities as described above. Unless you are deliberately using American speling, s/behavior/behaviour/. The English spelling of behaviour is usual in Erlang. From ericbmerritt@REDACTED Tue Jan 29 01:49:32 2013 From: ericbmerritt@REDACTED (Eric Merrit) Date: Mon, 28 Jan 2013 16:49:32 -0800 Subject: [erlang-questions] alternative syntax to '-spec' attributes. Message-ID: <423B2E86-1B2C-4AE7-89E2-973CF9D676D5@gmail.com> There seems to be an alternative syntax for specs. Lets say we have a spec declared in the traditional way -spec to_boolean(term()) -> boolean(). We could also declare it the following way and have it be consumed without problems -spec to_boolean/1 :: (term()) -> boolean(). I like the second way quite a bit since it visually distinguishes between spec declarations and function declarations better then the traditional syntax. However, I recently went looking for documentation on this and now can't find it. So I am wondering what its status is. Thanks, Eric From rickard@REDACTED Tue Jan 29 02:09:23 2013 From: rickard@REDACTED (Rickard Green) Date: Tue, 29 Jan 2013 02:09:23 +0100 Subject: [erlang-questions] Message order and exit(Reason) In-Reply-To: References: <5106EEF3.7020200@erlang.org> Message-ID: <51072143.5070404@erlang.org> On 01/29/2013 01:28 AM, Richard O'Keefe wrote: > > On 29/01/2013, at 10:34 AM, Rickard Green wrote: >>> The only signal ordering guarantee given is the following. If an entity sends multiple signals to the same destination entity, the order will be preserved. That is, if A send a signal S1 to B, and later sends the signal S2 to B, S1 is guaranteed not to arrive after S2. > > s/if A send/if A sends/ >>> >>> The implementation of different asynchronous signals in the VM may vary over time, but the behavior will always respect this concept of asynchronous signals being passed between entities as described above. > > Unless you are deliberately using American speling, s/behavior/behaviour/. > The English spelling of behaviour is usual in Erlang. > > Thanks, fixed it. Not sure the fix will make to R16A, but definitely to R16B. Regards, Rickard -- Rickard Green, Erlang/OTP, Ericsson AB. From essen@REDACTED Tue Jan 29 02:44:39 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Tue, 29 Jan 2013 02:44:39 +0100 Subject: [erlang-questions] erlc speed (or lack thereof), Make and emake In-Reply-To: <5101EDC3.6070105@ninenines.eu> References: <20130124220420.GB3657@corelatus.se> <41758.1359077377@snookles.snookles.com> <5101EDC3.6070105@ninenines.eu> Message-ID: <51072987.10601@ninenines.eu> On 01/25/2013 03:28 AM, Lo?c Hoguin wrote: > Anthony Ramine gave me a tip on how to build only modified erl files > using make's functionality directly, I'll try it out tomorrow and report > back. I have finally played with this. It is very nice and works perfectly. The idea is to recompile only source files newer than the .app file. This can be done by making source files depend on the .app file, and using $? to obtain the list of changed files. This can be seen here: https://github.com/extend/cowboy/blob/747bfc29ee951841f38d6e8d471041d6a3008d60/Makefile If no files have changed: essen@REDACTED (0) % time make make[1]: Entering directory `/home/essen/extend/ranch' make[1]: Leaving directory `/home/essen/extend/ranch' make 0.04s user 0.01s system 77% cpu 0.060 total If one file has changed: essen@REDACTED (0) % time make erlc -v -Werror +debug_info +warn_export_all -o ebin/ -pa ebin/ \ src/cowboy_middleware.erl src/cowboy.erl make[1]: Entering directory `/home/essen/extend/ranch' make[1]: Leaving directory `/home/essen/extend/ranch' make 0.20s user 0.03s system 91% cpu 0.249 total As you can see I always compile cowboy_middleware, because I need it compiled before anything else, as it's a behavior. If you want to rebuild everything: essen@REDACTED (0) % time make clean app make[1]: Entering directory `/home/essen/extend/ranch' rm -rf ebin/ rm -f test/*.beam rm -f erl_crash.dump make[1]: Leaving directory `/home/essen/extend/ranch' rm -rf ebin/ rm -f test/*.beam rm -f erl_crash.dump erlc -v -Werror +debug_info +warn_export_all -o ebin/ -pa ebin/ \ src/cowboy_middleware.erl src/cowboy_multipart.erl src/cowboy_http_handler.erl src/cowboy_handler.erl src/cowboy_router.erl src/cowboy_http.erl src/cowboy_loop_handler.erl src/cowboy_websocket.erl src/cowboy_sup.erl src/cowboy_rest.erl src/cowboy_app.erl src/cowboy_bstr.erl src/cowboy_protocol.erl src/cowboy_req.erl src/cowboy_middleware.erl src/cowboy.erl src/cowboy_client.erl src/cowboy_websocket_handler.erl src/cowboy_clock.erl src/cowboy_static.erl make[1]: Entering directory `/home/essen/extend/ranch' erlc -v -Werror +debug_info +warn_export_all -o ebin/ -pa ebin/ \ src/ranch_transport.erl src/ranch_transport.erl src/ranch_acceptor.erl src/ranch_sup.erl src/ranch_listener.erl src/ranch_server.erl src/ranch_acceptors_sup.erl src/ranch_conns_sup.erl src/ranch_listener_sup.erl src/ranch_ssl.erl src/ranch_app.erl src/ranch_protocol.erl src/ranch.erl src/ranch_tcp.erl make[1]: Leaving directory `/home/essen/extend/ranch' make clean app 1.39s user 0.10s system 98% cpu 1.512 total That's pretty fast in my book. In comparison, rebar: essen@REDACTED (0) % time rebar clean compile ==> ranch (clean) ==> cowboy (clean) ==> ranch (compile) Compiled src/ranch_protocol.erl Compiled src/ranch_transport.erl Compiled src/ranch_acceptor.erl Compiled src/ranch_listener.erl Compiled src/ranch.erl Compiled src/ranch_tcp.erl Compiled src/ranch_listener_sup.erl Compiled src/ranch_conns_sup.erl Compiled src/ranch_ssl.erl Compiled src/ranch_acceptors_sup.erl Compiled src/ranch_server.erl Compiled src/ranch_sup.erl Compiled src/ranch_app.erl ==> cowboy (compile) Compiled src/cowboy_http_handler.erl Compiled src/cowboy_loop_handler.erl Compiled src/cowboy_websocket_handler.erl Compiled src/cowboy_middleware.erl Compiled src/cowboy.erl Compiled src/cowboy_bstr.erl Compiled src/cowboy_router.erl Compiled src/cowboy_static.erl Compiled src/cowboy_handler.erl Compiled src/cowboy_rest.erl Compiled src/cowboy_protocol.erl Compiled src/cowboy_sup.erl Compiled src/cowboy_multipart.erl Compiled src/cowboy_req.erl Compiled src/cowboy_clock.erl Compiled src/cowboy_websocket.erl Compiled src/cowboy_app.erl Compiled src/cowboy_client.erl Compiled src/cowboy_http.erl rebar clean compile 2.38s user 0.17s system 179% cpu 1.419 total All this on a state of the art 13" laptop with a good SSD, i7 and everything, if you wonder. I probably won't bother trying to make -j to work. Feel free to send a patch if you want to have fun with it, though. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From essen@REDACTED Tue Jan 29 02:57:35 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 29 Jan 2013 02:57:35 +0100 Subject: [erlang-questions] erlc speed (or lack thereof), Make and emake In-Reply-To: References: <20130124220420.GB3657@corelatus.se> <41758.1359077377@snookles.snookles.com> Message-ID: <51072C8F.7030404@ninenines.eu> On 01/25/2013 03:49 AM, Bj?rn-Egil Dahlberg wrote: > > > 2013/1/25 ???? ????? ??? ? > > > > Bjorn - > > Why do you think it isn't feasible to use rebar to build erlang > applications within OTP? > > > > Well, rebar would be a key-component to build otp. That means that rebar > probably have to be included in the repo as an application. > Not impossible, but I don't know if it would be ideal. It'd need a lot of work. I love rebar for the simple things, but it's a pain if you need to do hard things. I'm also not sure you'd gain much doing this, the only bad thing about compiling OTP right now is that there's too many applications. > What I would like, and I don't know if anybody shares this thought: > > OTP split down to just a core, namely runtime system, kernel, stdlib, > compiler, sasl perhaps a few other applications. Definitely yes. > External dependency to rebar. Perhaps rebar could be included in that > core. From a technical standpoint, there is ofc no problem. But it would > be nice to solve it in another manner. > > I don't really know if this is true or not, but I get the feeling when I > use rebar that I loose some strictness and it adds some magic. A lack of > sense of control. Just the paranoia speaking perhaps. =) It adds a lot of magic, makes guesses as to what you want, and gets it right most of the time. Not as magic with more complex applications. > Applications are nowadays normally oriented in separate git > repositories. Seems natural to use this scheme for OTP applications as > well. > It has some additional advantages: > * Promotes modularity. > * Can have separate release cycles. > * Developers can choose different versions for there system, not merely > the system version R16*, R15*, R14*, etc .. > > I can see many advantages. I agree with these points. Core applications should definitely keep the Rxx version system, but some would perhaps benefit more from being outside (thinking of common_test particularly). I'm also not sure what diameter and others are doing there. > I'm pretty sure there are disadvantages too. Cross application updates > that otherwise needs strict version-control can be done with one commit > in a single repo. Thats pretty neat. The good thing though is that if nobody cares about one such application you can quickly notice it and drop it or lower the amount of support you give to it. > We won't go into this any further right now though. One step at a time. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From essen@REDACTED Tue Jan 29 03:16:35 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Tue, 29 Jan 2013 03:16:35 +0100 Subject: [erlang-questions] If you are homesick for object.selector In-Reply-To: References: <7A312CC3-1505-426C-B303-84F43FDCAC7F@cs.otago.ac.nz> <51009E7B.5090902@ninenines.eu> <5A8829B8-EAB5-480D-B693-D820D61B4649@cs.otago.ac.nz> <5101E924.5030507@ninenines.eu> <3936587E-4099-4AEB-A200-CF5C46D320B3@cs.otago.ac.nz> <5102680F.1030108@ninenines.eu> <20130125165039.GA68598@ferdmbp.local> Message-ID: <51073103.9050108@ninenines.eu> On 01/27/2013 07:28 PM, Eric Merritt wrote: >> Garrett >> >> [1] https://github.com/languages >> >> [2] I'm reminded of the coding horror that is jQuery >> >> [3] I'd point to Eric Merrit's outstanding with with Joxa >> (http://joxa.org) as an example of what can be done with core Erlang >> and the Erlang tool chain > > We will probably be hoisting Joxa up from Core Erlang to the higher > level Erlang AST sometime soon. Unfortunately, Core Erlang isn't > really the first class language target that it is claimed. The main > problem is it does not produce Abstract Code in the resulting beam. > This makes it impossible to use both Erlang's built in debugger and > Dialyzer on things compiled to Core Erlang. It could be argued that > this isn't a major problem. In Joxa, at least, the lack of those > features have been somewhat painful for new folks. It sounds like it'd be more work than improving the Core Erlang support in OTP. Correct me if I'm wrong: Dialyzer works on Core Erlang. It needs the abstract code because Core Erlang has no support for typespecs. When Dialyzer works on beam files, it extracts typespecs, compiles the abstract code to Core Erlang and continues with it. It does a similar process from source. Instead the compilation process could perhaps add a beam chunk containing the typespec information that Dialyzer would use, and another with the Core Erlang AST. This'd likely also make Dialyzer a little faster as it would not need to compile the AST to Core Erlang and to retrieve values from it. The debugger application, but not dbg from what I understand, is indeed making heavy use of the Erlang AST. This sounds like a minor issue though if dbg still works. I'll need to confirm this later on. The last two issues are the tools cover and xref. I don't think xref would be too difficult to port to Core Erlang, cover I'm not sure. > On the plus side Core Erlang is a nice, simple AST to target that > gives a lot of flexibility. And we should help make it viable for many languages to come. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From serge@REDACTED Tue Jan 29 03:32:02 2013 From: serge@REDACTED (Serge Aleynikov) Date: Mon, 28 Jan 2013 21:32:02 -0500 Subject: [erlang-questions] erlc speed (or lack thereof), Make and emake In-Reply-To: <51072987.10601@ninenines.eu> References: <20130124220420.GB3657@corelatus.se> <41758.1359077377@snookles.snookles.com> <5101EDC3.6070105@ninenines.eu> <51072987.10601@ninenines.eu> Message-ID: <510734A2.60402@aleynikov.org> Lo?c, There's a little trick you can use in a make file to avoid spawning external shell to comma delimit files: empty := space := $(empty) $(empty) comma := $(empty), $(empty) FILES := $(wildcard src/*.erl) MODULES := $(subst $(space),$(comma),$(sort $(FILES:src/%.erl=%))) example: @echo "UsingShell = $(shell ls src/*.erl | sed 's/src\///;s/\.erl/,/' | sed '$$s/.$$//')" @echo "UsingMake = $(MODULES)" And also for the app target you can just do: ebin/$(PROJECT).app: src/$(PROJECT).app.src sed 's/{modules, \[\]}/{modules, \[$(MODULES)\]}/' $< > $@ app: deps/ranch ebin/$(PROJECT).app @$(MAKE) -C $(DEPS_DIR)/ranch My $2c. Regards, Serge On 1/28/2013 8:44 PM, Lo?c Hoguin wrote: > On 01/25/2013 03:28 AM, Lo?c Hoguin wrote: >> Anthony Ramine gave me a tip on how to build only modified erl files >> using make's functionality directly, I'll try it out tomorrow and report >> back. > > I have finally played with this. It is very nice and works perfectly. > > The idea is to recompile only source files newer than the .app file. > This can be done by making source files depend on the .app file, and > using $? to obtain the list of changed files. > > This can be seen here: > > > https://github.com/extend/cowboy/blob/747bfc29ee951841f38d6e8d471041d6a3008d60/Makefile > > > If no files have changed: > > essen@REDACTED (0) % time make > make[1]: Entering directory `/home/essen/extend/ranch' > make[1]: Leaving directory `/home/essen/extend/ranch' > make 0.04s user 0.01s system 77% cpu 0.060 total > > If one file has changed: > > essen@REDACTED (0) % time make > erlc -v -Werror +debug_info +warn_export_all -o ebin/ -pa ebin/ \ > src/cowboy_middleware.erl src/cowboy.erl > make[1]: Entering directory `/home/essen/extend/ranch' > make[1]: Leaving directory `/home/essen/extend/ranch' > make 0.20s user 0.03s system 91% cpu 0.249 total > > As you can see I always compile cowboy_middleware, because I need it > compiled before anything else, as it's a behavior. > > If you want to rebuild everything: > > essen@REDACTED (0) % time make clean app > make[1]: Entering directory `/home/essen/extend/ranch' > rm -rf ebin/ > rm -f test/*.beam > rm -f erl_crash.dump > make[1]: Leaving directory `/home/essen/extend/ranch' > rm -rf ebin/ > rm -f test/*.beam > rm -f erl_crash.dump > erlc -v -Werror +debug_info +warn_export_all -o ebin/ -pa ebin/ \ > src/cowboy_middleware.erl src/cowboy_multipart.erl > src/cowboy_http_handler.erl src/cowboy_handler.erl src/cowboy_router.erl > src/cowboy_http.erl src/cowboy_loop_handler.erl src/cowboy_websocket.erl > src/cowboy_sup.erl src/cowboy_rest.erl src/cowboy_app.erl > src/cowboy_bstr.erl src/cowboy_protocol.erl src/cowboy_req.erl > src/cowboy_middleware.erl src/cowboy.erl src/cowboy_client.erl > src/cowboy_websocket_handler.erl src/cowboy_clock.erl src/cowboy_static.erl > make[1]: Entering directory `/home/essen/extend/ranch' > erlc -v -Werror +debug_info +warn_export_all -o ebin/ -pa ebin/ \ > src/ranch_transport.erl src/ranch_transport.erl > src/ranch_acceptor.erl src/ranch_sup.erl src/ranch_listener.erl > src/ranch_server.erl src/ranch_acceptors_sup.erl src/ranch_conns_sup.erl > src/ranch_listener_sup.erl src/ranch_ssl.erl src/ranch_app.erl > src/ranch_protocol.erl src/ranch.erl src/ranch_tcp.erl > make[1]: Leaving directory `/home/essen/extend/ranch' > make clean app 1.39s user 0.10s system 98% cpu 1.512 total > > That's pretty fast in my book. > > In comparison, rebar: > > essen@REDACTED (0) % time rebar clean compile > ==> ranch (clean) > ==> cowboy (clean) > ==> ranch (compile) > Compiled src/ranch_protocol.erl > Compiled src/ranch_transport.erl > Compiled src/ranch_acceptor.erl > Compiled src/ranch_listener.erl > Compiled src/ranch.erl > Compiled src/ranch_tcp.erl > Compiled src/ranch_listener_sup.erl > Compiled src/ranch_conns_sup.erl > Compiled src/ranch_ssl.erl > Compiled src/ranch_acceptors_sup.erl > Compiled src/ranch_server.erl > Compiled src/ranch_sup.erl > Compiled src/ranch_app.erl > ==> cowboy (compile) > Compiled src/cowboy_http_handler.erl > Compiled src/cowboy_loop_handler.erl > Compiled src/cowboy_websocket_handler.erl > Compiled src/cowboy_middleware.erl > Compiled src/cowboy.erl > Compiled src/cowboy_bstr.erl > Compiled src/cowboy_router.erl > Compiled src/cowboy_static.erl > Compiled src/cowboy_handler.erl > Compiled src/cowboy_rest.erl > Compiled src/cowboy_protocol.erl > Compiled src/cowboy_sup.erl > Compiled src/cowboy_multipart.erl > Compiled src/cowboy_req.erl > Compiled src/cowboy_clock.erl > Compiled src/cowboy_websocket.erl > Compiled src/cowboy_app.erl > Compiled src/cowboy_client.erl > Compiled src/cowboy_http.erl > rebar clean compile 2.38s user 0.17s system 179% cpu 1.419 total > > All this on a state of the art 13" laptop with a good SSD, i7 and > everything, if you wonder. > > I probably won't bother trying to make -j to work. Feel free to send a > patch if you want to have fun with it, though. > From techabc@REDACTED Tue Jan 29 06:26:18 2013 From: techabc@REDACTED (techabc) Date: Tue, 29 Jan 2013 13:26:18 +0800 Subject: [erlang-questions] [go-nuts] Re: [ANN] Erlang distributed node in Go In-Reply-To: References: <7d781b7a-dfc3-404f-949a-3c3662a4d3a7@googlegroups.com> Message-ID: nice bridge between erlang and golang, thank u. > > On Thu, Jan 24, 2013 at 11:48 AM, Vladimir Sibirov > wrote: > >> That's quite an interesting project! >> >> Is it already used in some real world applications? What are the benefits >> of building heterogeneous Erlang/Go systems? >> >> >> >> Glad to present implementation of Erlang distributed node in Go >>> >>> https://github.com/goerlang/**node >>> >>> Supported features: >>> >>> - Publish listen port via EPMD >>> - Handle incoming connection from other node using Erlang Distribution >>> Protocol >>> - Spawn Erlang-like processes >>> - Register and unregister processes with simple atom >>> - Send messages to registered (using atom) or not registered (using >>> Pid) processes at Go-node or remote Erlang-node >>> - Create own process with GenServer behaviour (like gen_server in >>> Erlang/OTP) >>> >>> Pull requests are welcome! >>> >>> -- >>> Max Treskin >>> >> -- >> >> >> > > -- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From toby@REDACTED Tue Jan 29 06:36:14 2013 From: toby@REDACTED (Toby Thain) Date: Tue, 29 Jan 2013 00:36:14 -0500 Subject: [erlang-questions] game coding style (Re: If you are homesick for object.selector) In-Reply-To: References: Message-ID: <51075FCE.9020003@telegraphics.com.au> On 28/01/13 1:15 PM, Raoul Duke wrote: >> I still think you want a relational model for your gaming use case. >> SQLite + memory db FTW! > > as a small-time game developer (well, i've had real jobs doing real > games, but not these days) and as somebody who likes to read > www.lambda-the-ultimate.org in addition to game dev sites, > > i have also come around to seeing that, at least, most uses of OO for > game (and simulation in general, even given the history of OO) > development are just leading to trouble. He said relational model -- not OO :-) --Toby > > sincerely. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From baliulia@REDACTED Tue Jan 29 09:00:38 2013 From: baliulia@REDACTED (=?UTF-8?B?SWduYXMgVnnFoW5pYXVza2Fz?=) Date: Tue, 29 Jan 2013 09:00:38 +0100 Subject: [erlang-questions] Message order and exit(Reason) In-Reply-To: <5106EEF3.7020200@erlang.org> References: <5106EEF3.7020200@erlang.org> Message-ID: <510781A6.9010405@gmail.com> On 01/28/2013 10:34 PM, Rickard Green wrote: > The only signal ordering guarantee given is the following. If an > entity sends multiple signals to the same destination entity, the > order will be preserved. That is, if A send a signal S1 to B, and > later sends the signal S2 to B, S1 is guaranteed not to arrive after > S2. But this is true only for single-node semantics/settings, correct? At least I this paper[1] by Koen Claessen and Hans Svensson claims that: > In Fredlund?s semantics the delivery of a message is instantaneous, > meaning that all messages are delivered in exactly the order they are > sent. Now, this is actually true for processes running on the same > node, due to how the Erlang runtime system is implemented. It is, > however, not true in general for a concurrency oriented programming > language, and specifically not in a distributed setting with several > different Erlang nodes. In general, they have a similar example to the one described in this thread where problems with the exit signal appear in Chapter 5 and conclude: > After Fredlund proposed his single-node semantics, it was at least > thought ?morally OK? to use this semantics to reason about and model > distributed systems. However, messages actually can and do > arrive in different orders in a distributed setting as compared to a > local setting. A simple experiment involving 3 nodes already shows > this, even when the nodes are implemented as 3 run-time systems > running on the same workstation! Moreover, we discovered that the > above was not merely a theoretical anomaly, but an actual problem > with a real-life implementation. Along the same lines, many Erlang > developers think it morally OK to test their distributed system on a > single node. For the same reasons as mentioned above, errors might > slip through. There's also a more recent one[2] by Hans Svensson. So I guess the moral is that it's not all so simple and nice when you "really" start distributing and it's not a good idea to make strong assumptions even about the tiniest details. Regards, Ignas [1]: "A Semantics for Distributed Erlang", 2005: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.101.9412 [2]: "A more accurate semantics for distributed Erlang", 2007: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.102.1723 From carlsson.richard@REDACTED Tue Jan 29 09:39:59 2013 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Tue, 29 Jan 2013 09:39:59 +0100 Subject: [erlang-questions] Message order and exit(Reason) In-Reply-To: <510781A6.9010405@gmail.com> References: <5106EEF3.7020200@erlang.org> <510781A6.9010405@gmail.com> Message-ID: <51078ADF.9050200@gmail.com> On 2013-01-29 09:00 , Ignas Vy?niauskas wrote: > On 01/28/2013 10:34 PM, Rickard Green wrote: >> The only signal ordering guarantee given is the following. If an >> entity sends multiple signals to the same destination entity, the >> order will be preserved. That is, if A send a signal S1 to B, and >> later sends the signal S2 to B, S1 is guaranteed not to arrive after >> S2. > > But this is true only for single-node semantics/settings, correct? > > At least I this paper[1] by Koen Claessen and Hans Svensson claims that: > >> In Fredlund?s semantics the delivery of a message is instantaneous, >> meaning that all messages are delivered in exactly the order they are >> sent. Now, this is actually true for processes running on the same >> node, due to how the Erlang runtime system is implemented. It is, >> however, not true in general for a concurrency oriented programming >> language, and specifically not in a distributed setting with several >> different Erlang nodes. These are different things. The delivery order of signals between two *specific* processes is always guaranteed, even in a distributed setting. Even if process A is on node 1 and process B is on node 2, it's easy to preserve the order. What Fredlund is talking about is the message order over all sends in the system. They do not model the time it may take in a distributed system for a message to be transferred from the sender to the mailbox of the receiver. Within a single node, it *used to* be the case that this operation was atomic. However, in a modern Erlang node on a multicore machine, there may be several sends being performed by different scheduler threads in true concurrent fashion, so the atomicity assumption is fundamentally broken. > In general, they have a similar example to the one described in this > thread where problems with the exit signal appear in Chapter 5 and conclude: > >> After Fredlund proposed his single-node semantics, it was at least >> thought ?morally OK? to use this semantics to reason about and model >> distributed systems. However, messages actually can and do >> arrive in different orders in a distributed setting as compared to a >> local setting. A simple experiment involving 3 nodes already shows >> this, even when the nodes are implemented as 3 run-time systems >> running on the same workstation! Moreover, we discovered that the >> above was not merely a theoretical anomaly, but an actual problem >> with a real-life implementation. Along the same lines, many Erlang >> developers think it morally OK to test their distributed system on a >> single node. For the same reasons as mentioned above, errors might >> slip through. > > There's also a more recent one[2] by Hans Svensson. > > So I guess the moral is that it's not all so simple and nice when you > "really" start distributing and it's not a good idea to make strong > assumptions even about the tiniest details. No, the ordering guarantees exist and can be relied on. You just can't assume a total order, even if that assumption makes your model easier to reason about. Your results won't be applicable on the real world. /Richard From baliulia@REDACTED Tue Jan 29 09:57:27 2013 From: baliulia@REDACTED (=?UTF-8?B?SWduYXMgVnnFoW5pYXVza2Fz?=) Date: Tue, 29 Jan 2013 09:57:27 +0100 Subject: [erlang-questions] Message order and exit(Reason) In-Reply-To: <51078ADF.9050200@gmail.com> References: <5106EEF3.7020200@erlang.org> <510781A6.9010405@gmail.com> <51078ADF.9050200@gmail.com> Message-ID: <51078EF7.2010409@gmail.com> On 01/29/2013 09:39 AM, Richard Carlsson wrote: > These are different things. The delivery order of signals between > two *specific* processes is always guaranteed, even in a distributed > setting. Even if process A is on node 1 and process B is on node 2, > it's easy to preserve the order. What Fredlund is talking about is > the message order over all sends in the system. This made a lot of sense, thanks for the clarification! Ignas From n.oxyde@REDACTED Tue Jan 29 10:19:24 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 29 Jan 2013 10:19:24 +0100 Subject: [erlang-questions] alternative syntax to '-spec' attributes. In-Reply-To: <423B2E86-1B2C-4AE7-89E2-973CF9D676D5@gmail.com> References: <423B2E86-1B2C-4AE7-89E2-973CF9D676D5@gmail.com> Message-ID: That is an old and deprecated syntax that predates the one everyone knows. -- Anthony Ramine Le 29 janv. 2013 ? 01:49, Eric Merrit a ?crit : > There seems to be an alternative syntax for specs. Lets say we have a spec declared in the traditional way > > -spec to_boolean(term()) -> boolean(). > > We could also declare it the following way and have it be consumed without problems > > -spec to_boolean/1 :: (term()) -> boolean(). > > I like the second way quite a bit since it visually distinguishes between spec declarations and function declarations better then the traditional syntax. However, I recently went looking for documentation on this and now can't find it. So I am wondering what its status is. > > Thanks, > Eric > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From kostis@REDACTED Tue Jan 29 11:31:03 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 29 Jan 2013 11:31:03 +0100 Subject: [erlang-questions] alternative syntax to '-spec' attributes. In-Reply-To: <423B2E86-1B2C-4AE7-89E2-973CF9D676D5@gmail.com> References: <423B2E86-1B2C-4AE7-89E2-973CF9D676D5@gmail.com> Message-ID: <5107A4E7.40106@cs.ntua.gr> On 01/29/2013 01:49 AM, Eric Merrit wrote: > There seems to be an alternative syntax for specs. Lets say we have a spec declared in the traditional way > > -spec to_boolean(term()) -> boolean(). > > We could also declare it the following way and have it be consumed without problems > > -spec to_boolean/1 :: (term()) -> boolean(). > > I like the second way quite a bit since it visually distinguishes between spec declarations and function declarations better then the traditional syntax. However, I recently went looking for documentation on this and now can't find it. So I am wondering what its status is. As Antony also mentioned, the :: version is the old spec syntax. It's still accepted by the parser, but this is only for reasons of backwards compatibility and will most likely become obsolete soon. Besides a bit more verbose (as you can see from your example), another reason to switch to the new one was that the old one required a sanity check that the arity specified in the function name actually matches the number of argument types specified by the programmer. The newer one does not need this. Kostis From essen@REDACTED Tue Jan 29 12:03:47 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Tue, 29 Jan 2013 12:03:47 +0100 Subject: [erlang-questions] erlc speed (or lack thereof), Make and emake In-Reply-To: <510734A2.60402@aleynikov.org> References: <20130124220420.GB3657@corelatus.se> <41758.1359077377@snookles.snookles.com> <5101EDC3.6070105@ninenines.eu> <51072987.10601@ninenines.eu> <510734A2.60402@aleynikov.org> Message-ID: <5107AC93.3080009@ninenines.eu> On 01/29/2013 03:32 AM, Serge Aleynikov wrote: > Lo?c, > > There's a little trick you can use in a make file to avoid spawning > external shell to comma delimit files: > > empty := > space := $(empty) $(empty) > comma := $(empty), $(empty) > > FILES := $(wildcard src/*.erl) > MODULES := $(subst $(space),$(comma),$(sort $(FILES:src/%.erl=%))) > > example: > @echo "UsingShell = $(shell ls src/*.erl | sed > 's/src\///;s/\.erl/,/' | sed '$$s/.$$//')" > @echo "UsingMake = $(MODULES)" Your "little" trick is a lot more verbose. :) I don't think the external call slows anything down. Good to know it's possible though. > And also for the app target you can just do: > > ebin/$(PROJECT).app: src/$(PROJECT).app.src > sed 's/{modules, \[\]}/{modules, \[$(MODULES)\]}/' $< > $@ > > app: deps/ranch ebin/$(PROJECT).app > @$(MAKE) -C $(DEPS_DIR)/ranch I'm using the ebin/$(PROJECT).app rule to compile only the modified .erl files, and the ebin/$(PROJECT).app needs to be compiled everytime for that to work properly, not just when .app.src is modified. Thanks for the interesting tips! -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From ah.kode@REDACTED Tue Jan 29 13:49:09 2013 From: ah.kode@REDACTED (a h) Date: Tue, 29 Jan 2013 14:49:09 +0200 Subject: [erlang-questions] Erlang data structure Message-ID: Hi Everyone, Please suggest me the best way to implement the below requirement: I have one file-A which contains below format of data A10,A11, A12, A13 A20, A21, A22, A23, and B file as: B10, B11, B12, B13 B20, B21, B22, B23 I need to process these two file but my system(framework in Erlang) can able to send data chunks of A to my application and the path for B file. My application need to perform that if A10 = B10 then do something. What I am doing is storing the B file in ETS and then when i receive 1st line from framework, I am searching the same in ETS. But I am facing an Issue that storing the B file(which is too huge in GB) in ETS result in Heap Crash. Please suggest me better way in which I can able to store the file or do i need to merge these files before sending to framework. Appreciate your earliest response Thanks, AH -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmercer@REDACTED Tue Jan 29 15:36:22 2013 From: dmercer@REDACTED (David Mercer) Date: Tue, 29 Jan 2013 08:36:22 -0600 Subject: [erlang-questions] Message order and exit(Reason) In-Reply-To: References: <5106EEF3.7020200@erlang.org> Message-ID: <014201cdfe2e$02d533d0$087f9b70$@gmail.com> On Monday, January 28, 2013, Richard O'Keefe wrote: > Unless you are deliberately using American speling, s/behavior/behaviour/. > The English spelling of behaviour is usual in Erlang. So the guy who wants to be able to write Erlang in Maori wants to prohibit us from writing in American English. :-) Cheers, DBM From raould@REDACTED Tue Jan 29 17:42:02 2013 From: raould@REDACTED (Raoul Duke) Date: Tue, 29 Jan 2013 08:42:02 -0800 Subject: [erlang-questions] game coding style (Re: If you are homesick for object.selector) In-Reply-To: <51075FCE.9020003@telegraphics.com.au> References: <51075FCE.9020003@telegraphics.com.au> Message-ID: > He said relational model -- not OO :-) yes, and that's why i was agreeing with him vs. the thread discussion about OO and train wrecks. From sverker.eriksson@REDACTED Tue Jan 29 19:34:34 2013 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Tue, 29 Jan 2013 19:34:34 +0100 Subject: [erlang-questions] Any tcp related changes in R15B* that might cause this? In-Reply-To: <20130115064028.GA53613@alumni.caltech.edu> References: <20121214211117.GA86501@alumni.caltech.edu> <50CF35FF.6020101@erix.ericsson.se> <20130102172816.GA24637@alumni.caltech.edu> <20130103061626.GB26037@alumni.caltech.edu> <50EAF721.2020002@erix.ericsson.se> <20130108164231.GA40748@alumni.caltech.edu> <50EC6993.9000608@erix.ericsson.se> <20130115064028.GA53613@alumni.caltech.edu> Message-ID: <5108163A.6090403@erix.ericsson.se> Sorry for the late answer, been kind of busy with R16A. I think you have found a bug. I did this modification in your test ok = inet:setopts (Sock, [{packet, http}, {exit_on_close,false}]), and it still close the socket. Here is a patch that seems to solve the problem: git fetch git://github.com/sverker/otp.git sverk/tcp-exit_on_close-false I'm not 100% sure that this fix doesn't has some other unexpected effect. The inet driver is quite a complex piece of software. It would be good if you could test this out. The patch is based on R15B02 but it should be easy to apply on both R15B03 and R16A. /Sverker, Erlang/OTP Anthony Molinaro wrote: > Hi Sverker, > > I cannot get {exit_on_close, false}, to actually change the behavior > of my test. I set it as an options to gen_tcp:listen/2 but gen_tcp:send/2 > still returns {error,closed}. I also tried setting it at various other > points with inet:setopts/2, but it never seems to make a difference. > > I'm using R15B02, but I'm wondering if you can modify my example, such > that the gen_tcp:send/2 doesn't fail with {error,closed}. > > I reattached it without any modifications. You should be able to > just compile it and run > > gen_tcp_test:test(10000). > > To see it fail. > > Hopefully you can show me the error of my ways ;) > > -Anthony > > On Tue, Jan 08, 2013 at 07:46:43PM +0100, Sverker Eriksson wrote: > >> Anthony Molinaro wrote: >> >>> I agree that the new behavior of returning an emsgsize tcp_error is >>> probably correct, however the new behavior also closes the socket. >>> >>> Before your changes mochiweb and my test could return a 400 error so >>> the client would get a response even if they were sending in a bad >>> request. After the change the client just gets a remote side closed >>> connection message. >>> >>> So I guess the question is, why is the connection being closed? Is >>> that also something the other packet protocols do? >>> >>> >> Yes all packets protocols act the same in this sense. >> >> You can use socket option {exit_on_close, false} to only do a >> half-close and still allow writing to the socket. >> >> /Sverker >> >> >>> Thanks for looking at it, >>> >>> -Anthony >>> >>> On Mon, Jan 07, 2013 at 05:26:09PM +0100, Sverker Eriksson wrote: >>> >>>> Thanks for the clarification, guys. >>>> I've look at dc5f7190 and it seems like the change in error >>>> handling was more or less intentional (by me). >>>> >>>> Old behavior was >>>> 1. Truncate a too long http line and return it as if it was ok. >>>> 2. Continue parsing rest of the line as if it were a new http line >>>> which probably (and hopefully) results in a http_error. >>>> >>>> I didn't like that; as it returned a partially parsed line as if it >>>> was ok, reported the error too late and confusing and also (I guess) >>>> constituted a security bug that could be abused to trick the http >>>> parsing with long lines. >>>> >>>> So I changed it to reject too long lines and return tcp_error, which >>>> is what happens for all packet protocols when the length of the >>>> packet is in some way invalid. >>>> >>>> The caller has to handle tcp_error's anyway, so it's a case of bad >>>> fault identification. >>>> I guess it would be nicer to return {http_error, "Line too long: >>>> X-Randomaaaaaaaaaaaaaaaaaa..."} >>>> or something like that. >>>> I don't have time to fix that now, but don't think it would be too >>>> hard do if anyone is eager... >>>> >>>> >>>> /Sverker, Erlang/OTP >>>> >>>> >>>> >>>> Steve Vinoski wrote: >>>> >>>>> Same results with this test: works on commits prior to dc5f7190, fails >>>>> on dc5f7190. >>>>> >>>>> --steve >>>>> >>>>> On Thu, Jan 3, 2013 at 1:16 AM, Anthony Molinaro < >>>>> anthonym@REDACTED> wrote: >>>>> >>>>> >>>>>> Attached is a test which shows the difference using only gen_tcp calls. >>>>>> >>>>>> Here's the output from both >>>>>> >>>>>> Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:2:2] [rq:2] >>>>>> [async-threads:0] >>>>>> [hipe] [kernel-poll:false] >>>>>> >>>>>> Eshell V5.8.5 (abort with ^G) >>>>>> 1> gen_tcp_test:test(1000). >>>>>> gen_tcp:send ok >>>>>> {{"HTTP/1.1",200,"OK"}, >>>>>> [{"date","Wed, 02 Jan 2013 21:01:08 GMT"}, >>>>>> {"server","Test"}, >>>>>> {"content-length","31"}, >>>>>> {"content-type","text/html"}], >>>>>> "Hello"} >>>>>> 2> gen_tcp_test:test(10000). >>>>>> http_error - R14 >>>>>> gen_tcp:send ok >>>>>> {{"HTTP/1.1",400,"Bad Request"}, >>>>>> [{"date","Wed, 02 Jan 2013 21:03:24 GMT"}, >>>>>> {"server","Test"}, >>>>>> {"content-length","0"}], >>>>>> []} >>>>>> 3> >>>>>> >>>>>> and for R15 >>>>>> >>>>>> Erlang R15B02 (erts-5.9.2) [source] [64-bit] [smp:2:2] [async-threads:0] >>>>>> [hipe] >>>>>> [kernel-poll:false] >>>>>> >>>>>> Eshell V5.9.2 (abort with ^G) >>>>>> 1> gen_tcp_test:test(1000). >>>>>> gen_tcp:send ok >>>>>> {{"HTTP/1.1",200,"OK"}, >>>>>> [{"date","Wed, 02 Jan 2013 21:01:08 GMT"}, >>>>>> {"server","Test"}, >>>>>> {"content-length","31"}, >>>>>> {"content-type","text/html"}], >>>>>> "Hello"} >>>>>> 2> gen_tcp_test:test(10000). >>>>>> emsgsize - R15 >>>>>> gen_tcp:send failed with {error,closed} >>>>>> socket_closed_remotely >>>>>> 3> >>>>>> >>>>>> Hope it helps, >>>>>> >>>>>> -Anthony >>>>>> >>>>>> On Wed, Jan 02, 2013 at 12:34:56PM -0500, Steve Vinoski wrote: >>>>>> >>>>>>> Hi Anthony and Sverker, as I mentioned in a previous email, using >>>>>>> >>>>>> Anthony's >>>>>> >>>>>>> test case a few weeks ago I bisected between R14B04 and HEAD and found >>>>>>> commit dc5f7190 to be the first commit where the test case fails. >>>>>>> >>>>>>> --steve >>>>>>> >>>>>>> On Wed, Jan 2, 2013 at 12:28 PM, Anthony Molinaro < >>>>>>> anthonym@REDACTED> wrote: >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> The holidays went and interrupted everything, so I'm sorry about the >>>>>>>> late response. >>>>>>>> It's unclear if the commit dc5f7190 did it or not, but sometime between >>>>>>>> R14B04 and R15B02 the behavior did change. I've not isolated it >>>>>>>> >>>>>> outside >>>>>> >>>>>>>> of mochiweb, but I don't think its a mochiweb problem. >>>>>>>> >>>>>>>> Here's the pull request which contains the short program I used to >>>>>>>> reproduce with mochiweb (and work around the new behavior) >>>>>>>> >>>>>>>> https://github.com/mochi/mochiweb/pull/91 >>>>>>>> >>>>>>>> I'll see if I can't isolate it to just OTP sometime in the next >>>>>>>> couple of days. >>>>>>>> >>>>>>>> -Anthony >>>>>>>> >>>>>>>> On Mon, Dec 17, 2012 at 04:10:55PM +0100, Sverker Eriksson wrote: >>>>>>>> >>>>>>>>> Have I understood it correctly so far if I say that my commit >>>>>>>>> dc5f7190 seems to cause a >>>>>>>>> >>>>>>>>> {tcp_error,Port,emsgsize} >>>>>>>>> >>>>>>>>> while earlier versions caused a >>>>>>>>> >>>>>>>>> {http,Port,{http_error,"..."}} >>>>>>>>> >>>>>>>>> >>>>>>>>> for the same scenario with some sort of very long http lines? >>>>>>>>> >>>>>>>>> /Sverker, Erlang/OTP >>>>>>>>> >>>>>>>>> Anthony Molinaro wrote: >>>>>>>>> >>>>>>>>>> On Fri, Dec 14, 2012 at 11:32:11AM -0500, Steve Vinoski wrote: >>>>>>>>>> >>>>>>>>>>> Hi Anthony, based on your example, it looks like a follow-up commit >>>>>>>>>>> >>>>>>>> that >>>>>>>> >>>>>>>>>>> modified some of the changes introduced by my patch introduced the >>>>>>>>>>> >>>>>>>> issue >>>>>>>> >>>>>>>>>>> you're seeing: commit dc5f7190. You might want to report it over on >>>>>>>>>>> erlang-bugs. >>>>>>>>>>> >>>>>>>>>> Nice catch, I guess that it's actually not enough to return error >>>>>>>>>> for backward compatibility ;) >>>>>>>>>> >>>>>>>>>> I think the main thing I'm still not sure of is if the decode_packet >>>>>>>>>> >>>>>>>> changes >>>>>>>> >>>>>>>>>> are actually the cause. I was able to call decode_packet with long >>>>>>>>>> >>>>>>>> headers >>>>>>>> >>>>>>>>>> and not actually see an issue. >>>>>>>>>> >>>>>>>>>> This >>>>>>>>>> >>>>>>>>>> erlang:decode_packet ( httph, >>>>>>>>>> list_to_binary ([ "X-Random: ", >>>>>>>>>> [$a || _ <- >>>>>>>>>> >>>>>>>> lists:seq(1,10000)], >>>>>>>> >>>>>>>>>> "\r\n\r\n" >>>>>>>>>> ]), >>>>>>>>>> []). >>>>>>>>>> >>>>>>>>>> Returns the same thing in both R14B04 and R15B02. And as far as I >>>>>>>>>> >>>>>> am >>>>>> >>>>>>>> able >>>>>>>> >>>>>>>>>> to tell that is the only call made to decode_packet in mochiweb. >>>>>>>>>> >>>>>>>>>> I think the actual error is around recvbuf sizing (mochiweb uses >>>>>>>>>> >>>>>> 8192 as >>>>>> >>>>>>>>>> the default, so 10000 is definitely larger than that, however, the >>>>>>>>>> >>>>>>>> standard >>>>>>>> >>>>>>>>>> libraries must be doing something different as now it returns >>>>>>>>>> >>>>>> emsgsize >>>>>> >>>>>>>>>> where it did no in the past). I really wish there was a way to >>>>>>>>>> >>>>>> search >>>>>> >>>>>>>>>> commits on github as then I could search for recvbuf or something >>>>>>>>>> >>>>>> like >>>>>> >>>>>>>>>> that to see what might have changed. >>>>>>>>>> >>>>>>>>>> Before I go over to bugs I'll probably try to detangle mochiweb >>>>>>>>>> >>>>>> enough >>>>>> >>>>>>>>>> to create a small reproducible test case. >>>>>>>>>> >>>>>>>>>> I also have a pull request into mochiweb which prevents the crash >>>>>>>>>> >>>>>> but >>>>>> >>>>>>>>>> has the annoying behavior at the moment that it returns an error to >>>>>>>>>> >>>>>> the >>>>>> >>>>>>>>>> client about disconnecting version the 400 error it returned before. >>>>>>>>>> >>>>>>>>>> https://github.com/mochi/mochiweb/pull/91 >>>>>>>>>> >>>>>>>>>> But since the standard library seems to be the one closing the >>>>>>>>>> >>>>>> socket >>>>>> >>>>>>>>>> there's not much that can be done other than the fix I put in place. >>>>>>>>>> >>>>>>>>>> Thanks for your help Steve, >>>>>>>>>> >>>>>>>>>> -Anthony >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> erlang-questions mailing list >>>>>>>>> erlang-questions@REDACTED >>>>>>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>>>> Anthony Molinaro < >>>>>>>> >>>>>> anthonym@REDACTED> >>>>>> >>>>>>>> _______________________________________________ >>>>>>>> erlang-questions mailing list >>>>>>>> erlang-questions@REDACTED >>>>>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>>>>> >>>>>>>> >>>>>> -- >>>>>> ------------------------------------------------------------------------ >>>>>> Anthony Molinaro >>>>>> >>>>>> > > From ericbmerritt@REDACTED Tue Jan 29 21:05:27 2013 From: ericbmerritt@REDACTED (Eric Merritt) Date: Tue, 29 Jan 2013 12:05:27 -0800 Subject: [erlang-questions] alternative syntax to '-spec' attributes. In-Reply-To: <5107A4E7.40106@cs.ntua.gr> References: <423B2E86-1B2C-4AE7-89E2-973CF9D676D5@gmail.com> <5107A4E7.40106@cs.ntua.gr> Message-ID: Thanks Kostis and Anthony thats exactly what I was looking for. Eric On Tue, Jan 29, 2013 at 2:31 AM, Kostis Sagonas wrote: > On 01/29/2013 01:49 AM, Eric Merrit wrote: >> >> There seems to be an alternative syntax for specs. Lets say we have a spec >> declared in the traditional way >> >> -spec to_boolean(term()) -> boolean(). >> >> We could also declare it the following way and have it be consumed without >> problems >> >> -spec to_boolean/1 :: (term()) -> boolean(). >> >> I like the second way quite a bit since it visually distinguishes between >> spec declarations and function declarations better then the traditional >> syntax. However, I recently went looking for documentation on this and now >> can't find it. So I am wondering what its status is. > > > As Antony also mentioned, the :: version is the old spec syntax. It's still > accepted by the parser, but this is only for reasons of backwards > compatibility and will most likely become obsolete soon. > > Besides a bit more verbose (as you can see from your example), another > reason to switch to the new one was that the old one required a sanity check > that the arity specified in the function name actually matches the number of > argument types specified by the programmer. The newer one does not need > this. > > Kostis > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From max.lapshin@REDACTED Tue Jan 29 21:43:48 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Tue, 29 Jan 2013 23:43:48 +0300 Subject: [erlang-questions] need help with cowboy routing Message-ID: Hi. There is a big mess with cowboy routes in erlyvideo. User can access a stream via different http-based protocols. For example if stream is named mtv, urls are: /mtv/index.m3u8 /mtv/manifest.f4m /mtv/hls/2012/12/23/14/59.ts /mtv/index-123456780-3600.ts /mtv/mpegts All of them are mapping to different functions If user is accessing a dynamic stream, url may be: /live/user/15/somestream/index.m3u8 - here stream name is "live/user/15/somestream" So I want to detect handler according to postfix with dynamic length and even with some matching. Currently I do so: I map [<<"mtv">>, '...'], media_handler [<<"live">>, '...', media_handler and then media_handler tries to guess what route is it via dynamic matching: route(Segments) -> case Segments of [<<"index.m3u8">>] -> .. [<<"index-", TimeSpec/binary>>] -> ... [Part|Rest] -> route(Rest) I think it is a bad idea and think how to rewirte it because this mechanism makes very difficult to add some other handlers to existing prefix, for example map "/mtv/mpegts" to mpegts_handler. Also I have a problem with clashing /mtv/index.m3u8 and /mtv/index-123456780-3600.ts that should be routed to different handlers. My main idea is to bypass cowboy routing and compile dynamically routing file with all possible matches for streams with known names and make several clauses for dynamic streams: [<<"live">>, Segment1, <<"index.m3u8">>] -> [<<"live">>, Segment1, Segment2, <<"index.m3u8">>] -> (and so limit depth of such name). So I think that I can pregenerate all possible route matches, but it will not help with clashing names =( Maybe such router should be made as a cowboy middleware? Or I'm missing some cool features inside current router? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjtruog@REDACTED Tue Jan 29 22:32:05 2013 From: mjtruog@REDACTED (Michael Truog) Date: Tue, 29 Jan 2013 13:32:05 -0800 Subject: [erlang-questions] need help with cowboy routing In-Reply-To: References: Message-ID: <51083FD5.1000401@gmail.com> You could use my trie data structure with list-of-integers keys (and module/function values) to do a lookup with patterns like: /live/user/*/*/index.m3u8 If that is what you are looking for. You would just use trie:find_match/2 and then perhaps trie:pattern_parse/2 if you wanted the individual dynamic values. The trie:find_match/2 function is used within cpg within CloudI to handle request routing to processes, for the same purpose. The code is here https://github.com/okeuday/trie On 01/29/2013 12:43 PM, Max Lapshin wrote: > Hi. > > There is a big mess with cowboy routes in erlyvideo. > > User can access a stream via different http-based protocols. For example if stream is named mtv, urls are: > > > /mtv/index.m3u8 > /mtv/manifest.f4m > /mtv/hls/2012/12/23/14/59.ts > /mtv/index-123456780-3600.ts > /mtv/mpegts > > All of them are mapping to different functions > > If user is accessing a dynamic stream, url may be: > > /live/user/15/somestream/index.m3u8 - here stream name is "live/user/15/somestream" > > So I want to detect handler according to postfix with dynamic length and even with some matching. > > Currently I do so: I map > > [<<"mtv">>, '...'], media_handler > [<<"live">>, '...', media_handler > and then media_handler tries to guess what route is it via dynamic matching: > > > route(Segments) -> > case Segments of > [<<"index.m3u8">>] -> .. > [<<"index-", TimeSpec/binary>>] -> ... > [Part|Rest] -> > route(Rest) > > > I think it is a bad idea and think how to rewirte it because this mechanism makes very difficult to add some other handlers to existing prefix, for example map "/mtv/mpegts" to mpegts_handler. > > Also I have a problem with clashing /mtv/index.m3u8 and /mtv/index-123456780-3600.ts > that should be routed to different handlers. > > My main idea is to bypass cowboy routing and compile dynamically routing file with all possible matches for streams with known names and make several clauses for dynamic streams: > > [<<"live">>, Segment1, <<"index.m3u8">>] -> > [<<"live">>, Segment1, Segment2, <<"index.m3u8">>] -> (and so limit depth of such name). > > So I think that I can pregenerate all possible route matches, but it will not help with clashing names =( > > > Maybe such router should be made as a cowboy middleware? > Or I'm missing some cool features inside current router? > > > > > _______________________________________________ > 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 Jan 30 01:31:40 2013 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 30 Jan 2013 13:31:40 +1300 Subject: [erlang-questions] Message order and exit(Reason) In-Reply-To: <014201cdfe2e$02d533d0$087f9b70$@gmail.com> References: <5106EEF3.7020200@erlang.org> <014201cdfe2e$02d533d0$087f9b70$@gmail.com> Message-ID: On 30/01/2013, at 3:36 AM, David Mercer wrote: > On Monday, January 28, 2013, Richard O'Keefe wrote: > >> Unless you are deliberately using American speling, s/behavior/behaviour/. >> The English spelling of behaviour is usual in Erlang. > > So the guy who wants to be able to write Erlang in Maori wants to prohibit us from writing in American English. You *quoted* the part "Unless you are deliberately using American speling". Did you *read* it? Where does it say "don't write in American"? (As opposed to say Microsoft Word, which does its level best to stamp out non-American varieties of English.) The point at issue is not dialect X vs dialect Y but *consistency*. To quote another chunk of Erlang documentation, Behaviour Module Attribute It is possible to specify that the module is the callback module for a behaviour: -behaviour(Behaviour). The atom Behaviour gives the name of the behaviour, which can be a user defined behaviour or one of the OTP standard behaviours gen_server, gen_fsm, gen_event or supervisor. The spelling behavior is also accepted. Read more about behaviours and callback modules in OTP Design Principles. Given _that_, was it really so unlikely that the omission of the 'u' from the word was an _unintential_ typo? There may well be other places where the word has been differently spelled. My point is not to follow this spelling or that speling but to pick one and stick to it. And what I said in an earlier thread was that I wanted my *students* to be able to write Erlang in M?ori because it is a policy of this University that students should be allowed to perform assessment work in M?ori. From ababkin@REDACTED Wed Jan 30 01:36:52 2013 From: ababkin@REDACTED (Alex Babkin) Date: Tue, 29 Jan 2013 19:36:52 -0500 Subject: [erlang-questions] setting cookies with cowboy websocket handler Message-ID: Hi all Imagine an auth protocol over a websocket: client sends credentials, server responds with either success or failure. If success, it should set some persistent state so if the user reloads the page, the session will continue until either logout or some timeout I'm trying to set a cookie from a websocket handler, such that after a page reload, in the websocket handler init i can try to read back the cookie and check for it's validity and if valid, resume the session without the user needing to login again here is some code i tried with no success, i.e upon reload, the cookie is no longer there (or perhaps is never getting set by the handler to begin with) websocket_handle({text, Input}, Req, State) -> lager:debug("stream received ~s", [Input]), Req2 = cowboy_req:set_resp_cookie( <<"auth">>, [<<"test">>], [{max_age, 600}, {path, "/"}, {secure, true}, {http_only, true}], Req ), {ok, Req3} = cowboy_req:reply(200, Req2), {ok, Req3, NewState}. ... or alternatively: {reply, {text, Output}, Req2, NewState}. as the last line after the socket terminates and i try to reload page i do this in websocket init: {Cookie, Req2} = cowboy_req:cookie(<<"auth">>, Req), and there are no cookies any ideas what i'm doing wrong? is this even possible with websocket or do i pretty much have to have a dedicated regular http roundtrip to set the auth cookie? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From oj@REDACTED Wed Jan 30 01:49:24 2013 From: oj@REDACTED (OJ Reeves) Date: Wed, 30 Jan 2013 10:49:24 +1000 Subject: [erlang-questions] setting cookies with cowboy websocket handler In-Reply-To: References: Message-ID: Alex, I don't believe that sending cookies in the response when in the websocket handler will result in a cookie being set in the browser. The way I handle this is sending the cookie in the response outside of the websocket handler. That is, I have a "home" and "websocket" resource. I deal with authentication in the usual HTTP/REST way in the "home" resource, and only when the user is authenticated do I set up a websocket for communications via the "websocket" resource. My websocket_init function in the "websocket" resource is able to check for the authentication cookie, and if the user isn't auth'd then the websocket connection is killed. I haven't tried (or considered) setting up and sending out an auth cookie via websocket_init, I don't feel that it makes much sense. Hope that helps in some way. OJ On Wed, Jan 30, 2013 at 10:36 AM, Alex Babkin wrote: > Hi all > > Imagine an auth protocol over a websocket: client sends credentials, > server responds with either success or failure. If success, it should set > some persistent state so if the user reloads the page, the session will > continue until either logout or some timeout > > I'm trying to set a cookie from a websocket handler, such that after a > page reload, in the websocket handler init i can try to read back the > cookie and check for it's validity and if valid, resume the session without > the user needing to login again > > here is some code i tried with no success, i.e upon reload, the cookie is > no longer there (or perhaps is never getting set by the handler to begin > with) > > websocket_handle({text, Input}, Req, State) -> > lager:debug("stream received ~s", [Input]), > Req2 = cowboy_req:set_resp_cookie( > <<"auth">>, > [<<"test">>], > [{max_age, 600}, {path, "/"}, {secure, true}, {http_only, true}], > Req > ), > {ok, Req3} = cowboy_req:reply(200, Req2), > {ok, Req3, NewState}. > > ... or alternatively: > > {reply, {text, Output}, Req2, NewState}. > > as the last line > > after the socket terminates and i try to reload page i do this in > websocket init: > > {Cookie, Req2} = cowboy_req:cookie(<<"auth">>, Req), > > and there are no cookies > > > any ideas what i'm doing wrong? > is this even possible with websocket or do i pretty much have to have a > dedicated regular http roundtrip to set the auth cookie? > > Thanks > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- OJ Reeves +61 431 952 586 http://buffered.io/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cao.xu@REDACTED Wed Jan 30 07:29:22 2013 From: cao.xu@REDACTED (cao xu) Date: Wed, 30 Jan 2013 14:29:22 +0800 Subject: [erlang-questions] yaws processes hang with very different heap size Message-ID: <1F4E86B2-3C7B-4FD2-A43D-C82A52D1DB6D@rytong.com> Hi, We've deployed one web application with yaws 1.88(erlang R14B) on two machines, and there is a web interface with problem in the business logic which can cause the handling yaws process hang when processes the http request. What make me confused is that those hung processes consume quite different memory size on different machines. The heap size of one hung process is 3,029,104 words(24,233,888 bytes) on one machine, but on the other the size is 139,104 words(1,113,888 bytes). The application is deployed on separated server but the environment seems same to me. And the process is hanging at the same place when problem occurs. I suspect it's because of the behavior of erlang allocators, but nothing special can be found from the system info of ert_alloc. Could someone help me find the reason?Thanks. Sincerely. From simonstl@REDACTED Wed Jan 30 14:24:57 2013 From: simonstl@REDACTED (Simon St.Laurent) Date: Wed, 30 Jan 2013 08:24:57 -0500 Subject: [erlang-questions] Introducing Erlang Message-ID: <51091F29.3000502@simonstl.com> Introducing Erlang, a 200-page tutorial on the language you all (mostly) love, is now shipping from O'Reilly: It's a shorter, cheaper, and deliberately more basic book than the other great Erlang books out there. I very deliberately set out to write a book that would get readers started, and make it easier for them to read the other books. Most readers of this list already know and understand the material it covers, but it may be useful to you as a way to prime developers who haven't explored Erlang (and may be put off by the notion of functional programming). It moves step by step through simple concrete code, teaching the fundamentals of the language. Bruce Tate noted that "Erlang makes hard things easy and easy things hard." Introducing Erlang walks readers through the "easy things hard" part and gives them a glimpse of the promised land of "hard things easy". Once they're done with this book, they should have a foundation that will make it much easier to move on to other excellent books and documentation to figure out more of process-oriented programming and Erlang's data processing capabilities. I wrote this book in a different way from most technical books: I wrote it while I was learning Erlang myself, instead of afterwards. My hope is that it will better reflect at least one easily followed learning path. Thankfully, I had excellent detailed review from Steve Vinoski and Fred Hebert along the way, and I need to give Fred extra thanks for reviewing this while he was in the final stages of work on Learn You Some Erlang for Great Good! The book is designed primarily as an ebook, though a print version is available. The ebook nature of it will make it easier for me to make changes over time, adding (and correcting if necessary) material, with readers getting automatic updates. I do, however, want it to stay short, ideally as unintimidating as the giant red flying squirrel on the cover. Thank you all for Erlang and the conversation here, which has been very helpful! -- Simon St.Laurent http://simonstl.com/ From kunthar@REDACTED Wed Jan 30 15:22:46 2013 From: kunthar@REDACTED (Kunthar) Date: Wed, 30 Jan 2013 16:22:46 +0200 Subject: [erlang-questions] Introducing Erlang In-Reply-To: <51091F29.3000502@simonstl.com> References: <51091F29.3000502@simonstl.com> Message-ID: Congrats It was good idea in 2009 :) Anyway hope it will help to someone else. On Wed, Jan 30, 2013 at 3:24 PM, Simon St.Laurent wrote: > Introducing Erlang, a 200-page tutorial on the language you all (mostly) > love, is now shipping from O'Reilly: > > > > It's a shorter, cheaper, and deliberately more basic book than the other > great Erlang books out there. I very deliberately set out to write a book > that would get readers started, and make it easier for them to read the > other books. > > Most readers of this list already know and understand the material it > covers, but it may be useful to you as a way to prime developers who haven't > explored Erlang (and may be put off by the notion of functional > programming). It moves step by step through simple concrete code, teaching > the fundamentals of the language. > > Bruce Tate noted that "Erlang makes hard things easy and easy things hard." > Introducing Erlang walks readers through the "easy things hard" part and > gives them a glimpse of the promised land of "hard things easy". Once > they're done with this book, they should have a foundation that will make it > much easier to move on to other excellent books and documentation to figure > out more of process-oriented programming and Erlang's data processing > capabilities. > > I wrote this book in a different way from most technical books: I wrote it > while I was learning Erlang myself, instead of afterwards. My hope is that > it will better reflect at least one easily followed learning path. > Thankfully, I had excellent detailed review from Steve Vinoski and Fred > Hebert along the way, and I need to give Fred extra thanks for reviewing > this while he was in the final stages of work on Learn You Some Erlang for > Great Good! > > The book is designed primarily as an ebook, though a print version is > available. The ebook nature of it will make it easier for me to make > changes over time, adding (and correcting if necessary) material, with > readers getting automatic updates. I do, however, want it to stay short, > ideally as unintimidating as the giant red flying squirrel on the cover. > > Thank you all for Erlang and the conversation here, which has been very > helpful! > > -- > Simon St.Laurent > http://simonstl.com/ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- BR, \|/ Kunthar From nico.kruber@REDACTED Wed Jan 30 15:34:26 2013 From: nico.kruber@REDACTED (Nico Kruber) Date: Wed, 30 Jan 2013 15:34:26 +0100 Subject: [erlang-questions] edoc broken in current master? Message-ID: <4159396.DFkII5edO4@csr-pc40.zib.de> we regularly check that Scalaris builds on master and since the checks of 11 Jan 2013 6am CET, creating the documentation with edoc fails. We don't use packages, although we do put files into sub-folders - anyway, I guess a function_clause should not be returned to the user at any point (see below) svn co http://scalaris.googlecode.com/svn/trunk/ scalaris cd scalaris make doc ------------------------------ /home/buildbot/apps/erlang-dev/bin/erl -noshell -run edoc_run application "'scalaris'" \ '"."' '[{def, {vsn, "0.5.0+svn"}}, no_packages, {preprocess, true}, {includes, ["include", "contrib/yaws/include", "contrib/log4erl/include"]}, {sort_functions, false}, {pretty_printer, erl_pp}, {macros, [{tid_not_builtin, true}, {with_export_type_support, true}, {have_cthooks_support, true}, {have_callback_support, true}]}]' edoc: edoc terminated abnormally: {function_clause, [{edoc_lib,find_sources_3, [["random_bias.erl",[...]|...], "./src/rrepair",rrepair|...], [{file,...},{...}]}, {edoc_lib,find_sources_2,5,[{...}|...]}, {edoc_lib,'-find_sources_3/6-lc$^0/1-0-',5, [...]}, {edoc_lib,find_sources_2,5,...}, {edoc_lib,find_sources_1,...}, {edoc_lib,...}, {...}|...]}. make: *** [.make-doc] Error 1 ------------------------------ From nico.kruber@REDACTED Wed Jan 30 15:35:41 2013 From: nico.kruber@REDACTED (Nico Kruber) Date: Wed, 30 Jan 2013 15:35:41 +0100 Subject: [erlang-questions] edoc broken in current master? In-Reply-To: <4159396.DFkII5edO4@csr-pc40.zib.de> References: <4159396.DFkII5edO4@csr-pc40.zib.de> Message-ID: <3788796.M1GmZlaJoO@csr-pc40.zib.de> On Wednesday 30 Jan 2013 15:34:26 you wrote: > we regularly check that Scalaris builds on master and since the checks of 11 > Jan 2013 6am CET, creating the documentation with edoc fails. > We don't use packages, although we do put files into sub-folders - anyway, I > guess a function_clause should not be returned to the user at any point > (see below) > > svn co http://scalaris.googlecode.com/svn/trunk/ scalaris > cd scalaris > make doc > ------------------------------ > /home/buildbot/apps/erlang-dev/bin/erl -noshell -run edoc_run application > "'scalaris'" \ > '"."' '[{def, {vsn, "0.5.0+svn"}}, no_packages, {preprocess, true}, > {includes, ["include", "contrib/yaws/include", "contrib/log4erl/include"]}, > {sort_functions, false}, {pretty_printer, erl_pp}, {macros, > [{tid_not_builtin, true}, {with_export_type_support, true}, > {have_cthooks_support, true}, {have_callback_support, true}]}]' > edoc: edoc terminated abnormally: {function_clause, > [{edoc_lib,find_sources_3, > [["random_bias.erl",[...]|...], > "./src/rrepair",rrepair|...], > [{file,...},{...}]}, > {edoc_lib,find_sources_2,5,[{...}|...]}, > {edoc_lib,'-find_sources_3/6-lc$^0/1-0-',5, > [...]}, > {edoc_lib,find_sources_2,5,...}, > {edoc_lib,find_sources_1,...}, > {edoc_lib,...}, > {...}|...]}. > make: *** [.make-doc] Error 1 > ------------------------------ maybe this commit is related https://github.com/erlang/otp/commit/beb660aa59a8d9cd7f65b8b91dc5dd9bc74015e0 Nico From ababkin@REDACTED Wed Jan 30 16:23:26 2013 From: ababkin@REDACTED (Alex Babkin) Date: Wed, 30 Jan 2013 10:23:26 -0500 Subject: [erlang-questions] setting cookies with cowboy websocket handler In-Reply-To: References: Message-ID: Thanks OJ, this makes sense On Tue, Jan 29, 2013 at 7:49 PM, OJ Reeves wrote: > Alex, > > I don't believe that sending cookies in the response when in the websocket > handler will result in a cookie being set in the browser. The way I handle > this is sending the cookie in the response outside of the websocket handler. > > That is, I have a "home" and "websocket" resource. I deal with > authentication in the usual HTTP/REST way in the "home" resource, and only > when the user is authenticated do I set up a websocket for communications > via the "websocket" resource. My websocket_init function in the "websocket" > resource is able to check for the authentication cookie, and if the user > isn't auth'd then the websocket connection is killed. > > I haven't tried (or considered) setting up and sending out an auth cookie > via websocket_init, I don't feel that it makes much sense. > > Hope that helps in some way. > OJ > > > On Wed, Jan 30, 2013 at 10:36 AM, Alex Babkin wrote: > >> Hi all >> >> Imagine an auth protocol over a websocket: client sends credentials, >> server responds with either success or failure. If success, it should set >> some persistent state so if the user reloads the page, the session will >> continue until either logout or some timeout >> >> I'm trying to set a cookie from a websocket handler, such that after a >> page reload, in the websocket handler init i can try to read back the >> cookie and check for it's validity and if valid, resume the session without >> the user needing to login again >> >> here is some code i tried with no success, i.e upon reload, the cookie is >> no longer there (or perhaps is never getting set by the handler to begin >> with) >> >> websocket_handle({text, Input}, Req, State) -> >> lager:debug("stream received ~s", [Input]), >> Req2 = cowboy_req:set_resp_cookie( >> <<"auth">>, >> [<<"test">>], >> [{max_age, 600}, {path, "/"}, {secure, true}, {http_only, true}], >> Req >> ), >> {ok, Req3} = cowboy_req:reply(200, Req2), >> {ok, Req3, NewState}. >> >> ... or alternatively: >> >> {reply, {text, Output}, Req2, NewState}. >> >> as the last line >> >> after the socket terminates and i try to reload page i do this in >> websocket init: >> >> {Cookie, Req2} = cowboy_req:cookie(<<"auth">>, Req), >> >> and there are no cookies >> >> >> any ideas what i'm doing wrong? >> is this even possible with websocket or do i pretty much have to have a >> dedicated regular http roundtrip to set the auth cookie? >> >> Thanks >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > -- > > OJ Reeves > +61 431 952 586 > http://buffered.io/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth.lundin@REDACTED Wed Jan 30 16:26:15 2013 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Wed, 30 Jan 2013 16:26:15 +0100 Subject: [erlang-questions] OTP R16A has been released Message-ID: Erlang/OTP R16A has been released. This is a beta release before the R16B product release on February 27:th. OTP R16 i a new major release with a number of new features, characteristics and also some minor incompatibilities. We encourage you to build and test your applications using this release and report unexpected problems to us. See the readme file and the documentation for more details. Some of the highlights are: - Optimized handling of processes in the VM - New internal process table allowing for parallel reads and writes - optimized run queue management - optimized process state changes - "Non-blocking" code loading - New internal port table, and rewrite of scheduling of port tasks. - Dynamic allocation of port structures, allowing the default for maximum ports to be raised to 65536 (from 1024) - Support for UTF-8 encoded Unicode characters in source files. - Inets application: The http client now support HTTPS through a proxy - Asn1 application: Major cleanup of back ends and optimizations of mainly decode for PER and UPER. - The experimental features parameterized modules and packages are removed. An alternative compatible solution for parameterized modules is provided here https://github.com/erlang/pmod_transform. - All built in functions BIF's (even if they are implemented in C as part of the VM) are now visible in the source code of the module they belong to, including their type specs. - The Wx application now compiles and is usable with the unstable development branch of wxWidgets-2.9. This means that wx can now be built on 64 bit MacOsX as well. You can find the README file with more detailed info at http://www.erlang.org/download/otp_src_R16A_RELEASE_CANDIDATE.readme You can download the full source distribution from http://www.erlang.org/download/otp_src_R16A_RELEASE_CANDIDATE.tar.gz http://www.erlang.org/download/otp_src_R16A_RELEASE_CANDIDATE.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_R16A_RELEASE_CANDIDATE* The Windows binary distribution can be downloaded from http://www.erlang.org/download/otp_win32_R16A_RELEASE_CANDIDATE.exe http://www.erlang.org/download/otp_win64_R16A_RELEASE_CANDIDATE.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_R16A_RELEASE_CANDIDATE.tar.gz http://www.erlang.org/download/otp_doc_man_R16A_RELEASE_CANDIDATE.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 mononcqc@REDACTED Wed Jan 30 16:40:14 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 30 Jan 2013 10:40:14 -0500 Subject: [erlang-questions] OTP R16A has been released In-Reply-To: References: Message-ID: <20130130154013.GA10589@ferdmbp.local> Been reading the README and I'm pretty excited for a lot of the changes there. Especially anything related to contention and better parallel behaviour for ETS tables, processes, ports, and module loading. I'll be interested to see how well a stable version does for us in production. Unicode support is nice. There is no mention of Unicode support libraries. Anything regarding that? Did you get the libraries to add unicode support through some random detection, purely switching on the comment and using the right io functions? Also: OTP-10739 Add search to Erlang shell's history. Thanks to Fred Herbert. My name is Hebert :) Here's a question regarding reltool updates: -- The rel specification now dictates the order in which included and used applications (specified in the .app file as included_applications and applications respectively) are loaded/started by the boot file. If the applications are not specified in the rel spec, then the order from the .app file is used. This was a bug earlier reported on systools, and is now also implemented in reltool. Does this let people put in orders that break the load/boot sequence (say starting my app before stdlib/kernel, or other ones), or does it only allow to specify ambiguous cases (where it doesn't contradict the .app file)? Thanks for all the work! Fred. On 01/30, Kenneth Lundin wrote: > Erlang/OTP R16A has been released. This is a beta release before the R16B > product release on February 27:th. > > OTP R16 i a new major release with a number of new features, > characteristics and also some minor incompatibilities. > We encourage you to build and test your applications using this release and > report unexpected problems to us. > See the readme file and the documentation for more details. > > Some of the highlights are: > > - Optimized handling of processes in the VM > - New internal process table allowing for parallel reads and writes > - optimized run queue management > - optimized process state changes > - "Non-blocking" code loading > - New internal port table, and rewrite of scheduling of port tasks. > - Dynamic allocation of port structures, allowing the default for > maximum ports to be raised to 65536 (from 1024) > - Support for UTF-8 encoded Unicode characters in source files. > - Inets application: The http client now support HTTPS through a proxy > - Asn1 application: Major cleanup of back ends and optimizations of > mainly decode for PER and UPER. > - The experimental features parameterized modules and packages are > removed. An alternative compatible solution > for parameterized modules is provided here > https://github.com/erlang/pmod_transform. > - All built in functions BIF's (even if they are implemented in C as > part of the VM) are now visible in the > source code of the module they belong to, including their type specs. > - The Wx application now compiles and is usable with the > unstable development branch of wxWidgets-2.9. > This means that wx can now be built on 64 bit MacOsX as well. > > > > You can find the README file with more detailed info at > http://www.erlang.org/download/otp_src_R16A_RELEASE_CANDIDATE.readme > > You can download the full source distribution from > http://www.erlang.org/download/otp_src_R16A_RELEASE_CANDIDATE.tar.gz > http://www.erlang.org/download/otp_src_R16A_RELEASE_CANDIDATE.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_R16A_RELEASE_CANDIDATE* > > > The Windows binary distribution can be downloaded from > > http://www.erlang.org/download/otp_win32_R16A_RELEASE_CANDIDATE.exe > http://www.erlang.org/download/otp_win64_R16A_RELEASE_CANDIDATE.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_R16A_RELEASE_CANDIDATE.tar.gz > http://www.erlang.org/download/otp_doc_man_R16A_RELEASE_CANDIDATE.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 From max.lapshin@REDACTED Wed Jan 30 16:54:13 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Wed, 30 Jan 2013 18:54:13 +0300 Subject: [erlang-questions] OTP R16A has been released In-Reply-To: <20130130154013.GA10589@ferdmbp.local> References: <20130130154013.GA10589@ferdmbp.local> Message-ID: Great news! Can you tell, what means "optimized process state changes"? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Wed Jan 30 17:29:11 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 30 Jan 2013 17:29:11 +0100 Subject: [erlang-questions] Erlang data structure In-Reply-To: References: Message-ID: <43D300C9-23C0-4E14-8BF8-D8DA7F917BDC@erlang-solutions.com> On Jan 29, 2013, at 1:49 PM, a h wrote: > Hi Everyone, > > Please suggest me the best way to implement the below requirement: > I have one file-A which contains below format of data > A10,A11, A12, A13 > A20, A21, A22, A23, > > and B file as: > B10, B11, B12, B13 > B20, B21, B22, B23 > > I need to process these two file but my system(framework in Erlang) can able to send data chunks of A to my application and the path for B file. > My application need to perform that if A10 = B10 then do something. > What I am doing is storing the B file in ETS and then when i receive 1st line from framework, I am searching the same in ETS. > > But I am facing an Issue that storing the B file(which is too huge in GB) in ETS result in Heap Crash. If you cannot process your data on-line, the usual trick is to process them off-line. * Call the unix sort(1) on the file. Note that GNU sort is parallel. Now data can be processed with an ordered merge and this is much faster and memory usage is constant. * investigate probable use of the file_sorter module and use disk_logs * Data is in CSV format, so you can store data in postgres (Look up the COPY command) and index data, then do a join on the tables. This makes sure you get data in the correct order. You can use the 'epgsql' application from Erlang to read out data in chunks over a cursor. Alternative: * Avoid storign A10, B10 and so on as lists, but store them as binaries. This cuts memory use by 20 on 64bit architectures. * If you can accept an approximate correctness, hash your A10 and B10 values and gain a heuristically correct value. Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen From bourinov@REDACTED Wed Jan 30 17:50:16 2013 From: bourinov@REDACTED (Max Bourinov) Date: Wed, 30 Jan 2013 17:50:16 +0100 Subject: [erlang-questions] OTP R16A has been released In-Reply-To: References: <20130130154013.GA10589@ferdmbp.local> Message-ID: Great news! Congradulations to all Erlangers! Best regards, Max On Wed, Jan 30, 2013 at 4:54 PM, Max Lapshin wrote: > Great news! > > Can you tell, what means "optimized process state changes"? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth.lundin@REDACTED Wed Jan 30 17:55:39 2013 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Wed, 30 Jan 2013 17:55:39 +0100 Subject: [erlang-questions] OTP R16A has been released In-Reply-To: <20130130154013.GA10589@ferdmbp.local> References: <20130130154013.GA10589@ferdmbp.local> Message-ID: On Wed, Jan 30, 2013 at 4:40 PM, Fred Hebert wrote: > Been reading the README and I'm pretty excited for a lot of the changes > there. Especially anything related to contention and better parallel > behaviour for ETS tables, processes, ports, and module loading. I'll be > interested to see how well a stable version does for us in production. > I encourage you to test that as soon as possible. We don't regard this release as particularly unstable. We only expect minor corrections until R16B and of course we will have even better confidence regarding the quality after some weeks of community testing on top of our own. /Kenneth Erlang7OTP Ericsson > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karol.urbanski@REDACTED Wed Jan 30 17:59:03 2013 From: karol.urbanski@REDACTED (Karol Urbanski) Date: Wed, 30 Jan 2013 17:59:03 +0100 Subject: [erlang-questions] R16A binary packages for CentOS, Debian, Mac, Ubuntu and Windows Message-ID: <20130130165902.GA22351@dex.krakow> Hello, You can find our binary packages for the newest Erlang release (R16A) at http://www.erlang-solutions.com/downloads/download-erlang-otp The systems we provide the packages for are CentOS 6, Mac OS X Snow Leopard and newer, Debian 6, Ubuntu 12.10 and Windows. More systems to come soon! Best regards, Karol Urbanski From max.lapshin@REDACTED Wed Jan 30 18:32:31 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Wed, 30 Jan 2013 20:32:31 +0300 Subject: [erlang-questions] OTP R16A has been released In-Reply-To: References: <20130130154013.GA10589@ferdmbp.local> Message-ID: "The rewrite was also necessary in order to make it possible to schedule signals from processes to ports." Can I intercept sighup now in driver? I can write proper fork/execve driver now? -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed Jan 30 18:32:46 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Wed, 30 Jan 2013 18:32:46 +0100 Subject: [erlang-questions] OTP R16A has been released In-Reply-To: References: Message-ID: <5109593E.1030102@ninenines.eu> On 01/30/2013 04:26 PM, Kenneth Lundin wrote: > We encourage you to build and test your applications using this release > and report unexpected problems to us. Works for me! Great release, can't wait for R16B! Thanks! -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From garazdawi@REDACTED Wed Jan 30 18:56:33 2013 From: garazdawi@REDACTED (Lukas Larsson) Date: Wed, 30 Jan 2013 18:56:33 +0100 Subject: [erlang-questions] OTP R16A has been released In-Reply-To: References: <20130130154013.GA10589@ferdmbp.local> Message-ID: Signals is referring to Erlang signals[1], not OS signals. [1]: http://www.erlang.org/doc/apps/erts/communication.html On Wed, Jan 30, 2013 at 6:32 PM, Max Lapshin wrote: > "The rewrite was also necessary in order to make it possible to schedule > signals from processes to ports." > > Can I intercept sighup now in driver? I can write proper fork/execve > driver now? > > _______________________________________________ > 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 Wed Jan 30 19:01:40 2013 From: rickard@REDACTED (Rickard Green) Date: Wed, 30 Jan 2013 19:01:40 +0100 Subject: [erlang-questions] OTP R16A has been released In-Reply-To: References: <20130130154013.GA10589@ferdmbp.local> Message-ID: On Jan 30, 2013, at 4:54 PM, Max Lapshin wrote: > Great news! > > Can you tell, what means "optimized process state changes"? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions It should have said "optimized process internal state changes". For details see: https://github.com/erlang/otp/commit/4bcffe41e193bfa03f54f77e2158b3d989a001d0 Regards, Rickard Green, Erlang/OTP, Ericsson AB From comptekki@REDACTED Wed Jan 30 22:50:42 2013 From: comptekki@REDACTED (Wes James) Date: Wed, 30 Jan 2013 14:50:42 -0700 Subject: [erlang-questions] OTP R16A has been released In-Reply-To: References: Message-ID: > On Wed, Jan 30, 2013 at 8:26 AM, Kenneth Lundin wrote: > > >Erlang/OTP R16A has been released. This is a beta release before the R16B product release on February 27:th. For what it's worth: I git cloned my "database search web ui" from: https://github.com/comptekki/dbswui.git I ran make and this pulls cowboy (master), ranch (0.6.1), epgsql (master) and compiles all those and dbswui. I ran dbswui and I could search, add, edit and delete postgres records so all looks well for these. Thanks! Wes -------------- next part -------------- An HTML attachment was scrubbed... URL: From desired.mta@REDACTED Wed Jan 30 23:47:05 2013 From: desired.mta@REDACTED (=?UTF-8?Q?Motiejus_Jak=C5=A1tys?=) Date: Wed, 30 Jan 2013 22:47:05 +0000 Subject: [erlang-questions] OTP R16A has been released In-Reply-To: <20130130154013.GA10589@ferdmbp.local> References: <20130130154013.GA10589@ferdmbp.local> Message-ID: On Wed, Jan 30, 2013 at 3:40 PM, Fred Hebert wrote: > Also: > > OTP-10739 Add search to Erlang shell's history. Thanks to Fred > Herbert. History between sessions is not implemented (I get readline-style ctrl-r in same session fine which is super cool)? /home/motiejus$ erl -config hist.config -name labas Erlang R16A (erts-5.10) [source] [smp:2:2] [async-threads:10] [hipe] [kernel-poll:false] Eshell V5.10 (abort with ^G) (labas@REDACTED)1> application:get_all_env(kernel). [{hist_file,"erlang-history"}, {included_applications,[]}, {error_logger,tty}, {hist_size,120}, {hist_drop,["q().","init:stop()."]}] (labas@REDACTED)2> q(). ok (labas@REDACTED)3> % /home/motiejus$ ls -lA | grep erlang -r-------- 1 motiejus motiejus 20 Rgp 23 23:00 .erlang.cookie -- Motiejus Jak?tys From mononcqc@REDACTED Thu Jan 31 00:07:10 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 30 Jan 2013 18:07:10 -0500 Subject: [erlang-questions] OTP R16A has been released In-Reply-To: References: <20130130154013.GA10589@ferdmbp.local> Message-ID: <20130130230709.GF10589@ferdmbp.local> That's what it is. It searches the line stack. It's a *history-search* patch, not a general history-saving patch. I have https://github.com/ferd/erlang-history that implements a search that can be saved, but there's still work to do in it before it can be good enough for OTP: 1. it relies on DETS, and DETS seems to corrupt files from time to time either when too many shells write to it, or when it's interrupted while dumping. I want to get rid of DETS at some point for some other line utility, maybe disk_log. 2. I'll need to make it use a .erlang/ directory in $HOME rather than plenty of .erlang.$NAME files. There's a truckload of .erlang.* config files around, and one per named shell is problematic. 3. Multiple shells are implemented in an okay way, but there may be a need to correct codes when many shells write to the same file (usually multiple non-distributed shells). 4. The usual OTP cleanup and formatting is required. 5. I haven't considered the issue of multiple encodings used in the same shell history file yet. 6. I haven't asked the OTP team what they think should be done at that point, but I'd be fine forking this thread to start discussing it. Lately I haven't had the time/motivation to do that heavy lifting, but with the book and university done, I'll probably find time here and there to try and make a better implementation. In the mean time, I'll keep the repository above up to date. It's not yet ready for R16A support -- I use the compiler versions to deal with things and the new code can't be the same to make it there. It should work fine with the new ^R support feature. Shell history is a tiny bit about injecting history in a shell and is *mostly* about handling files on disk. Shell history search is pretty much handling the line stack in the shell and edlin, so that one was much simpler to deal with than history to make it part of OTP :) Regards, Fred. On 01/30, Motiejus Jak?tys wrote: > On Wed, Jan 30, 2013 at 3:40 PM, Fred Hebert wrote: > > Also: > > > > OTP-10739 Add search to Erlang shell's history. Thanks to Fred > > Herbert. > > History between sessions is not implemented (I get readline-style > ctrl-r in same session fine which is super cool)? > > /home/motiejus$ erl -config hist.config -name labas > Erlang R16A (erts-5.10) [source] [smp:2:2] [async-threads:10] [hipe] > [kernel-poll:false] > > Eshell V5.10 (abort with ^G) > (labas@REDACTED)1> application:get_all_env(kernel). > [{hist_file,"erlang-history"}, > {included_applications,[]}, > {error_logger,tty}, > {hist_size,120}, > {hist_drop,["q().","init:stop()."]}] > (labas@REDACTED)2> q(). > ok > (labas@REDACTED)3> % > /home/motiejus$ ls -lA | grep erlang > -r-------- 1 motiejus motiejus 20 Rgp 23 23:00 .erlang.cookie > > > -- > Motiejus Jak?tys From pierrefenoll@REDACTED Thu Jan 31 00:14:11 2013 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Thu, 31 Jan 2013 00:14:11 +0100 Subject: [erlang-questions] OTP R16A has been released In-Reply-To: <20130130230709.GF10589@ferdmbp.local> References: <20130130154013.GA10589@ferdmbp.local> <20130130230709.GF10589@ferdmbp.local> Message-ID: Hi Fred! and sorry to diverge this thread? Why do you want a history file per erlshell? bash only uses one: ~/.bash_history You only need one ~/.erlang.history, don't you? On 31 January 2013 00:07, Fred Hebert wrote: > That's what it is. It searches the line stack. It's a *history-search* > patch, not a general history-saving patch. > > I have https://github.com/ferd/erlang-history that implements a search > that can be saved, but there's still work to do in it before it can be > good enough for OTP: > > 1. it relies on DETS, and DETS seems to corrupt files from time to time > either when too many shells write to it, or when it's interrupted > while dumping. I want to get rid of DETS at some point for some other > line utility, maybe disk_log. > 2. I'll need to make it use a .erlang/ directory in $HOME rather than > plenty of .erlang.$NAME files. There's a truckload of .erlang.* > config files around, and one per named shell is problematic. > 3. Multiple shells are implemented in an okay way, but there may be a > need to correct codes when many shells write to the same file > (usually multiple non-distributed shells). > 4. The usual OTP cleanup and formatting is required. > 5. I haven't considered the issue of multiple encodings used in the same > shell history file yet. > 6. I haven't asked the OTP team what they think should be done at that > point, but I'd be fine forking this thread to start discussing it. > > Lately I haven't had the time/motivation to do that heavy lifting, > but with the book and university done, I'll probably find time here and > there to try and make a better implementation. > > In the mean time, I'll keep the repository above up to date. It's not > yet ready for R16A support -- I use the compiler versions to deal with > things and the new code can't be the same to make it there. It should > work fine with the new ^R support feature. > > Shell history is a tiny bit about injecting history in a shell and is > *mostly* about handling files on disk. Shell history search is pretty > much handling the line stack in the shell and edlin, so that one was > much simpler to deal with than history to make it part of OTP :) > > Regards, > Fred. > > On 01/30, Motiejus Jak?tys wrote: > > On Wed, Jan 30, 2013 at 3:40 PM, Fred Hebert wrote: > > > Also: > > > > > > OTP-10739 Add search to Erlang shell's history. Thanks to Fred > > > Herbert. > > > > History between sessions is not implemented (I get readline-style > > ctrl-r in same session fine which is super cool)? > > > > /home/motiejus$ erl -config hist.config -name labas > > Erlang R16A (erts-5.10) [source] [smp:2:2] [async-threads:10] [hipe] > > [kernel-poll:false] > > > > Eshell V5.10 (abort with ^G) > > (labas@REDACTED)1> application:get_all_env(kernel). > > [{hist_file,"erlang-history"}, > > {included_applications,[]}, > > {error_logger,tty}, > > {hist_size,120}, > > {hist_drop,["q().","init:stop()."]}] > > (labas@REDACTED)2> q(). > > ok > > (labas@REDACTED)3> % > > /home/motiejus$ ls -lA | grep erlang > > -r-------- 1 motiejus motiejus 20 Rgp 23 23:00 .erlang.cookie > > > > > > -- > > Motiejus Jak?tys > _______________________________________________ > 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 Jan 31 00:12:25 2013 From: ok@REDACTED (Richard O'Keefe) Date: Thu, 31 Jan 2013 12:12:25 +1300 Subject: [erlang-questions] OTP R16A has been released In-Reply-To: References: Message-ID: <8450FD78-4494-4C3F-95B5-54EDA605F019@cs.otago.ac.nz> On 31/01/2013, at 4:26 AM, Kenneth Lundin wrote: [Lots of goodies in R16A] > ? All built in functions BIF's (even if they are implemented in C as part of the VM) are now visible in the > source code of the module they belong to, including their type specs. This one I _love_. From mononcqc@REDACTED Thu Jan 31 00:41:21 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 30 Jan 2013 18:41:21 -0500 Subject: [erlang-questions] Erlang Shell History discussion (Was: Re: OTP R16A has been released) In-Reply-To: References: <20130130154013.GA10589@ferdmbp.local> <20130130230709.GF10589@ferdmbp.local> Message-ID: <20130130234120.GG10589@ferdmbp.local> On 01/31, Pierre Fenoll wrote: > Hi Fred! and sorry to diverge this thread? > Why do you want a history file per erlshell? bash only uses one: > ~/.bash_history > You only need one ~/.erlang.history, don't you? > Because from one computer you can be using remote shells to many different Erlang VMs running with different names. I always figured that the history for test@REDACTED would be something you would like a different history from something like prod@REDACTED, especially considering histories disappearing over time and whatnot. That way, different projects or nodes get isolated histories. So far I've enjoyed it and the fact I can get a clean shell history for projects I haven't touched in months whereas the shell I use to test everything locally (nonode@REDACTED) is chuck full of unrelated garbage and experiments. If people tell me they don't give a crap, I'm open to consider getting rid of that, but there's really no complexity attached to any of this. I simply add a call atom_to_list(node()) when opening the table/file and that's it. Regards, Fred. > On 31 January 2013 00:07, Fred Hebert wrote: > > > That's what it is. It searches the line stack. It's a *history-search* > > patch, not a general history-saving patch. > > > > I have https://github.com/ferd/erlang-history that implements a search > > that can be saved, but there's still work to do in it before it can be > > good enough for OTP: > > > > 1. it relies on DETS, and DETS seems to corrupt files from time to time > > either when too many shells write to it, or when it's interrupted > > while dumping. I want to get rid of DETS at some point for some other > > line utility, maybe disk_log. > > 2. I'll need to make it use a .erlang/ directory in $HOME rather than > > plenty of .erlang.$NAME files. There's a truckload of .erlang.* > > config files around, and one per named shell is problematic. > > 3. Multiple shells are implemented in an okay way, but there may be a > > need to correct codes when many shells write to the same file > > (usually multiple non-distributed shells). > > 4. The usual OTP cleanup and formatting is required. > > 5. I haven't considered the issue of multiple encodings used in the same > > shell history file yet. > > 6. I haven't asked the OTP team what they think should be done at that > > point, but I'd be fine forking this thread to start discussing it. > > > > Lately I haven't had the time/motivation to do that heavy lifting, > > but with the book and university done, I'll probably find time here and > > there to try and make a better implementation. > > > > In the mean time, I'll keep the repository above up to date. It's not > > yet ready for R16A support -- I use the compiler versions to deal with > > things and the new code can't be the same to make it there. It should > > work fine with the new ^R support feature. > > > > Shell history is a tiny bit about injecting history in a shell and is > > *mostly* about handling files on disk. Shell history search is pretty > > much handling the line stack in the shell and edlin, so that one was > > much simpler to deal with than history to make it part of OTP :) > > > > Regards, > > Fred. > > > > On 01/30, Motiejus Jak?tys wrote: > > > On Wed, Jan 30, 2013 at 3:40 PM, Fred Hebert wrote: > > > > Also: > > > > > > > > OTP-10739 Add search to Erlang shell's history. Thanks to Fred > > > > Herbert. > > > > > > History between sessions is not implemented (I get readline-style > > > ctrl-r in same session fine which is super cool)? > > > > > > /home/motiejus$ erl -config hist.config -name labas > > > Erlang R16A (erts-5.10) [source] [smp:2:2] [async-threads:10] [hipe] > > > [kernel-poll:false] > > > > > > Eshell V5.10 (abort with ^G) > > > (labas@REDACTED)1> application:get_all_env(kernel). > > > [{hist_file,"erlang-history"}, > > > {included_applications,[]}, > > > {error_logger,tty}, > > > {hist_size,120}, > > > {hist_drop,["q().","init:stop()."]}] > > > (labas@REDACTED)2> q(). > > > ok > > > (labas@REDACTED)3> % > > > /home/motiejus$ ls -lA | grep erlang > > > -r-------- 1 motiejus motiejus 20 Rgp 23 23:00 .erlang.cookie > > > > > > > > > -- > > > Motiejus Jak?tys > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > From paul.cager@REDACTED Thu Jan 31 00:45:17 2013 From: paul.cager@REDACTED (Paul Cager) Date: Wed, 30 Jan 2013 23:45:17 +0000 Subject: [erlang-questions] Following a send_timeout inet:close() no longer closes the socket. Message-ID: I am seeing a problem with erts-5.9.3.1 regarding TCP and send_timeout. Please see the example program, below, but to summarise it: * A server accepts an incoming connection with options {send_timeout, 250}. * The server continually writes data until it gets an {error, timeout}. The server then calls inet:close(Sock). * However the socket isn't actually closed - netstat reports that it is still established (and stays that way for at least an hour, probably for ever). * I've enabled debug tracing in drivers/common/inet_drv.c (+ added a couple of debugs to show the return value of inet_subscribe). I've also added tracing to show when desc_close is being called in that module. * Normally calling inet:close() results in tcp_inet_stop and desc_close being called. When inet:close() is called *after* an {error, timeout} response "inet_ctl(606): INET_REQ_SUBSCRIBE" is called, but not tcp_inet_stop (or desc_close), which is consistent with the socket remaining ESTABLISHED. * Using port_close rather than inet:close shows the same behaviour. That does not sound like the correct behaviour. Here is the debug output for a "normal" inet:close(): tcp_inet_ctl(606): 24 inet_ctl(606): INET_REQ_SUBSCRIBE inet_ctl(606): Calling inet_subscribe inet_subscribe returned 6 tcp_inet_stop(606) {s=10 deq(606): queue empty release_buffer: 1460 tcp_inet_stop(606) } desc_close(606): 10 Here is the debug output when receiving a {error, timeout} and calling inet:close(): tcp_sendv(606): s=10, about to send 0,8192 bytes tcp_sendv(606): s=10, only sent 512/2 of 8192/2 bytes/items tcp_sendv(606): s=10, Send failed, queuing sock_select(606): flags=02, onoff=1, event_mask=03 tcp_inet_commandv(606) } tcp_inet_commanv(606) {s=10 tcp_sendv(606): s=10, sender forced busy tcp_inet_commandv(606) } tcp_inet_timeout(606) {s=10 inet_reply_error_am 35 523 tcp_inet_timeout(606) } ** timeout - closing ** CLOSING port_info: {connected,<0.2.0>} tcp_inet_ctl(606): 24 inet_ctl(606): INET_REQ_SUBSCRIBE inet_ctl(606): Calling inet_subscribe inet_subscribe returned 6 tcp_inet_ctl(606): 11 inet_ctl(606): GETSTAT Do you have any ideas why this happens? TEST PROGRAM ============= -module(test_tcp_close). -compile(export_all). main() -> {ok, LSock} = gen_tcp:listen(1616, [binary, {packet,0}, {active, false}, {reuseaddr, true}]), spawn(?MODULE, connect_and_idle, [1616]), {ok, Sock} = gen_tcp:accept(LSock), io:format("** Accepted a connection~n", []), ok = inet:setopts(Sock, [ %% {send_timeout, 250}, {send_timeout_close, true}, {send_timeout, 250}, {active, once}, {nodelay, true}, {sndbuf, 131072}, {keepalive, true} ]), fill_write(Sock). fill_write(Sock) -> %% Make sure the output buffer becomes full so we trigger send_timeout. Size = 8 * 1024 * 8, %% 8 KB (k *bytes*). case gen_tcp:send(Sock, <<0:Size>>) of {error, timeout} -> io:format("** timeout - closing~n", []), io:format("** CLOSING port_info: ~p~n", [catch erlang:port_info(Sock, connected)]), inet:close(Sock), %% Wait at least INET_CLOSE_TIMEOUT and a bit timer:sleep(10000), io:format("** CLOSED port_info: ~p~n", [catch erlang:port_info(Sock, connected)]); {error, X} -> io:format("** Unexpected send error: ~p~n", [X]), io:format("** port_info: ~p~n", [catch erlang:port_info(Sock, connected)]); ok -> %% Uncomment to test an early close %% io:format("** Closing Sock early~n", []), %% inet:close(Sock), %% io:format("** Closed~n", []), timer:sleep(1000), fill_write(Sock) end. connect_and_idle(Port) -> {ok, _Sock} = gen_tcp:connect("localhost", Port, [{active,false}, {mode,binary}, {packet, 0}]), timer:sleep(infinity). -------------- next part -------------- An HTML attachment was scrubbed... URL: From solomon.wzs@REDACTED Thu Jan 31 02:46:12 2013 From: solomon.wzs@REDACTED (Solomon) Date: Thu, 31 Jan 2013 09:46:12 +0800 Subject: [erlang-questions] Which communication ports does erlang use? Message-ID: I set up two erlang nodes at two servers, and they have distributed mnesia tables. I must start the firewall at servers, so I want to know which communication ports does erlang use? -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge@REDACTED Thu Jan 31 03:01:24 2013 From: serge@REDACTED (Serge Aleynikov) Date: Wed, 30 Jan 2013 21:01:24 -0500 Subject: [erlang-questions] Which communication ports does erlang use? In-Reply-To: References: Message-ID: <5109D074.1010200@aleynikov.org> When running nodes separated by a firewall you'll need to open the port 4369 for access to epmd [1], and specify the range of ports that a node behind a firewall can use for binding its distributed transport by using the following kernel options: {kernel, [ {inet_dist_listen_min, StartPort}, {inet_dist_listen_max, EndPort} ]} The [StartPort ... EndPort] range would be provisioned in your firewall. Mnesia uses Erlang distributed transport and doesn't open any other ports for replication. Serge [1] http://www.erlang.org/doc/man/epmd.html On 1/30/2013 8:46 PM, Solomon wrote: > I set up two erlang nodes at two servers, and they have distributed > mnesia tables. > > I must start the firewall at servers, so I want to know which > communication ports does erlang use? > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From jbothma@REDACTED Thu Jan 31 08:02:33 2013 From: jbothma@REDACTED (JD Bothma) Date: Thu, 31 Jan 2013 08:02:33 +0100 Subject: [erlang-questions] setting cookies with cowboy websocket handler In-Reply-To: References: Message-ID: I'm not very familiar with cowboy but AFAIK generally... The last opportunity to set a cookie over HTTP (e.g. with cowboy's resp functions) is when you do the upgrade to websocket: client -> GET /websocket.endpoint server -> Upgrade : ... header; Cookie: header or whatever it looks like So once you're talking over websocket, it's too late. If you really want to set a cookie and auth over websocket, you can send the cookie over websocket and set it using javascript on the client. On 30 January 2013 01:36, Alex Babkin wrote: > Hi all > > Imagine an auth protocol over a websocket: client sends credentials, > server responds with either success or failure. If success, it should set > some persistent state so if the user reloads the page, the session will > continue until either logout or some timeout > > I'm trying to set a cookie from a websocket handler, such that after a > page reload, in the websocket handler init i can try to read back the > cookie and check for it's validity and if valid, resume the session without > the user needing to login again > > here is some code i tried with no success, i.e upon reload, the cookie is > no longer there (or perhaps is never getting set by the handler to begin > with) > > websocket_handle({text, Input}, Req, State) -> > lager:debug("stream received ~s", [Input]), > Req2 = cowboy_req:set_resp_cookie( > <<"auth">>, > [<<"test">>], > [{max_age, 600}, {path, "/"}, {secure, true}, {http_only, true}], > Req > ), > {ok, Req3} = cowboy_req:reply(200, Req2), > {ok, Req3, NewState}. > > ... or alternatively: > > {reply, {text, Output}, Req2, NewState}. > > as the last line > > after the socket terminates and i try to reload page i do this in > websocket init: > > {Cookie, Req2} = cowboy_req:cookie(<<"auth">>, Req), > > and there are no cookies > > > any ideas what i'm doing wrong? > is this even possible with websocket or do i pretty much have to have a > dedicated regular http roundtrip to set the auth cookie? > > Thanks > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgud@REDACTED Thu Jan 31 09:22:31 2013 From: dgud@REDACTED (Dan Gudmundsson) Date: Thu, 31 Jan 2013 09:22:31 +0100 Subject: [erlang-questions] Erlang Shell History discussion (Was: Re: OTP R16A has been released) In-Reply-To: <20130130234120.GG10589@ferdmbp.local> References: <20130130154013.GA10589@ferdmbp.local> <20130130230709.GF10589@ferdmbp.local> <20130130234120.GG10589@ferdmbp.local> Message-ID: That work list addresses the concerns we had with original implementation, looks good to me for a starter. I don't have a preference about multiple or single history files either, right now. /Dan On Thu, Jan 31, 2013 at 12:41 AM, Fred Hebert wrote: > On 01/31, Pierre Fenoll wrote: >> Hi Fred! and sorry to diverge this thread... >> Why do you want a history file per erlshell? bash only uses one: >> ~/.bash_history >> You only need one ~/.erlang.history, don't you? >> > > Because from one computer you can be using remote shells to many > different Erlang VMs running with different names. > > I always figured that the history for test@REDACTED would be something > you would like a different history from something like prod@REDACTED, > especially considering histories disappearing over time and whatnot. > That way, different projects or nodes get isolated histories. > > So far I've enjoyed it and the fact I can get a clean shell history for > projects I haven't touched in months whereas the shell I use to test > everything locally (nonode@REDACTED) is chuck full of unrelated garbage > and experiments. > > If people tell me they don't give a crap, I'm open to consider getting > rid of that, but there's really no complexity attached to any of this. I > simply add a call atom_to_list(node()) when opening the table/file and > that's it. > > Regards, > Fred. > >> On 31 January 2013 00:07, Fred Hebert wrote: >> >> > That's what it is. It searches the line stack. It's a *history-search* >> > patch, not a general history-saving patch. >> > >> > I have https://github.com/ferd/erlang-history that implements a search >> > that can be saved, but there's still work to do in it before it can be >> > good enough for OTP: >> > >> > 1. it relies on DETS, and DETS seems to corrupt files from time to time >> > either when too many shells write to it, or when it's interrupted >> > while dumping. I want to get rid of DETS at some point for some other >> > line utility, maybe disk_log. >> > 2. I'll need to make it use a .erlang/ directory in $HOME rather than >> > plenty of .erlang.$NAME files. There's a truckload of .erlang.* >> > config files around, and one per named shell is problematic. >> > 3. Multiple shells are implemented in an okay way, but there may be a >> > need to correct codes when many shells write to the same file >> > (usually multiple non-distributed shells). >> > 4. The usual OTP cleanup and formatting is required. >> > 5. I haven't considered the issue of multiple encodings used in the same >> > shell history file yet. >> > 6. I haven't asked the OTP team what they think should be done at that >> > point, but I'd be fine forking this thread to start discussing it. >> > >> > Lately I haven't had the time/motivation to do that heavy lifting, >> > but with the book and university done, I'll probably find time here and >> > there to try and make a better implementation. >> > >> > In the mean time, I'll keep the repository above up to date. It's not >> > yet ready for R16A support -- I use the compiler versions to deal with >> > things and the new code can't be the same to make it there. It should >> > work fine with the new ^R support feature. >> > >> > Shell history is a tiny bit about injecting history in a shell and is >> > *mostly* about handling files on disk. Shell history search is pretty >> > much handling the line stack in the shell and edlin, so that one was >> > much simpler to deal with than history to make it part of OTP :) >> > >> > Regards, >> > Fred. >> > >> > On 01/30, Motiejus Jak?tys wrote: >> > > On Wed, Jan 30, 2013 at 3:40 PM, Fred Hebert wrote: >> > > > Also: >> > > > >> > > > OTP-10739 Add search to Erlang shell's history. Thanks to Fred >> > > > Herbert. >> > > >> > > History between sessions is not implemented (I get readline-style >> > > ctrl-r in same session fine which is super cool)? >> > > >> > > /home/motiejus$ erl -config hist.config -name labas >> > > Erlang R16A (erts-5.10) [source] [smp:2:2] [async-threads:10] [hipe] >> > > [kernel-poll:false] >> > > >> > > Eshell V5.10 (abort with ^G) >> > > (labas@REDACTED)1> application:get_all_env(kernel). >> > > [{hist_file,"erlang-history"}, >> > > {included_applications,[]}, >> > > {error_logger,tty}, >> > > {hist_size,120}, >> > > {hist_drop,["q().","init:stop()."]}] >> > > (labas@REDACTED)2> q(). >> > > ok >> > > (labas@REDACTED)3> % >> > > /home/motiejus$ ls -lA | grep erlang >> > > -r-------- 1 motiejus motiejus 20 Rgp 23 23:00 .erlang.cookie >> > > >> > > >> > > -- >> > > Motiejus Jak?tys >> > _______________________________________________ >> > erlang-questions mailing list >> > 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 erlangsiri@REDACTED Thu Jan 31 09:54:11 2013 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 31 Jan 2013 09:54:11 +0100 Subject: [erlang-questions] OTP R16A has been released In-Reply-To: <20130130154013.GA10589@ferdmbp.local> References: <20130130154013.GA10589@ferdmbp.local> Message-ID: Hi Fred! Kernel and stdlib will always be started first. Other applications you can sort as you want. Regards /siri 2013/1/30 Fred Hebert > > Here's a question regarding reltool updates: > > -- The rel specification now dictates the order in which > included and used applications (specified in the .app file as > included_applications and applications respectively) are > loaded/started by the boot file. If the applications are not > specified in the rel spec, then the order from the .app file > is used. This was a bug earlier reported on systools, and is > now also implemented in reltool. > > Does this let people put in orders that break the load/boot sequence > (say starting my app before stdlib/kernel, or other ones), or does it > only allow to specify ambiguous cases (where it doesn't contradict the > .app file)? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Thu Jan 31 10:04:00 2013 From: ulf@REDACTED (Ulf Wiger) Date: Thu, 31 Jan 2013 10:04:00 +0100 Subject: [erlang-questions] OTP R16A has been released In-Reply-To: References: <20130130154013.GA10589@ferdmbp.local> Message-ID: <6FEE20A8-8792-4D2B-BBC8-B3B9FA988C4E@feuerlabs.com> On 31 Jan 2013, at 09:54, Siri Hansen wrote: > Hi Fred! > Kernel and stdlib will always be started first. Other applications you can sort as you want. Siri, Isn't it so that reltool_target:sort_apps/1 is still called, and that it retains the specified order *unless* it violates application dependencies? That is, if application dependencies require a change to the order, sort_apps/1 will change the order to fulfill these requirements, but it will not change an order that is legal. I interpreted that as the essence Fred's question (otherwise, it is just mine). BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From francesco@REDACTED Thu Jan 31 10:17:11 2013 From: francesco@REDACTED (Francesco Cesarini) Date: Thu, 31 Jan 2013 09:17:11 +0000 Subject: [erlang-questions] Fwd: Last chance to submit a proposal to speak at OSCON 2013 In-Reply-To: <1359586422.7804.0.508903@post.oreilly.com> References: <1359586422.7804.0.508903@post.oreilly.com> Message-ID: <510A3697.4090908@erlang-solutions.com> As always, it would be great to have a strong Erlang presence at OSCON this year. It is a huge conference (In excess of ten parallel tracks) with thousands of delegates from different programming communities and corners of the world. Last year, Loic spoke about Cowboy and Garrett gave a tutorial on Erlang, both to large, crowded rooms. In the halls, I kept on running into Erlang programmers. I warmly recommend you to submit a talk, as Erlang needs more exposure there relative to other non main stream technologies. Francesco -------- Original Message -------- Subject: Last chance to submit a proposal to speak at OSCON 2013 Date: Wed, 30 Jan 2013 14:53:42 -0800 From: O'Reilly Open Source Convention To: francesco@REDACTED If you cannot read the information below, view in browser . O'Reilly Open Source Convention Share your expertise at OSCON 2013 Submit your proposal by February 4 This summer, we'll celebrate 15 years of *OSCON* , and we're inviting you to be part of the celebration by joining the ranks of esteemed OSCON speakers. Open source has come a long way--from the early days when a handful of visionaries were working to make the case for free and open software (imagine wanting access to your source code!) to today, when open source is the standard for everyday programming languages, databases, utilities, and operating systems. These days, *who doesn't work with open source*? *Speaking at OSCON is a great way to give back to the community* The OSCON *call for participation* will wrap up on Monday, February 4. When you speak at OSCON, you not only share your knowledge with your peers, but you get your projects, ideas, and your company in front of a savvy and connected audience. You don't need to be a guru or experienced speaker; it's enough to have something worthwhile to share and the desire to communicate it to others. This year, make it happen. Let us hear from you by February 4. *See a list of suggested topics and submission guidelines* . Get help writing your proposal OSCON chair Matthew McCullough will be hosting a free webcast Thursday, January 31 at 11:00am PT to give tips, pointers, and advice on *Building Proposals for Conferences *. If you can't join the live event, *register * for the webcast to receive a link to the recording afterward. Looking forward to hearing from you! /Sarah Novotny, Edd Dumbill, and Matthew McCullough/ /OSCON Program Chairs/ *Speak at OSCON* *- Proposals Due Feb 4 -* *Find Out More * Premier Diamond Sponsors * Bluehost * Citrix Systems Diamond Sponsors * HP * Media Temple, Inc. * Shared Learning Collaborative Titanium Sponsor * OpenStack Platinum Sponsor * Google You are receiving this message because you attended a previous OSCON Conference or have expressed a strong interest in a open source related technology. Keep up on all things O'Reilly by signing up for our email newsletters, product alerts, and promotions at elists.oreilly.com . To ensure delivery to your inbox (not bulk or junk folders), please add oreilly@REDACTED to your address book. To unsubscribe from all email announcements from O'Reilly, click here . O'Reilly Media, Inc. 1005 Gravenstein Highway North, Sebastopol, CA 95472 (800) 889-8969 or (707) 827-7019 -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Thu Jan 31 10:31:35 2013 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 31 Jan 2013 10:31:35 +0100 Subject: [erlang-questions] OTP R16A has been released In-Reply-To: <6FEE20A8-8792-4D2B-BBC8-B3B9FA988C4E@feuerlabs.com> References: <20130130154013.GA10589@ferdmbp.local> <6FEE20A8-8792-4D2B-BBC8-B3B9FA988C4E@feuerlabs.com> Message-ID: 2013/1/31 Ulf Wiger > > On 31 Jan 2013, at 09:54, Siri Hansen wrote: > > Hi Fred! > Kernel and stdlib will always be started first. Other applications you can > sort as you want. > > > Siri, > > Isn't it so that reltool_target:sort_apps/1 is still called, and that it > retains the specified order *unless* it violates application dependencies? > That is, if application dependencies require a change to the order, > sort_apps/1 will change the order to fulfill these requirements, but it > will not change an order that is legal. > > I interpreted that as the essence Fred's question (otherwise, it is just > mine). > > BR, > Ulf W > > Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. > http://feuerlabs.com > Ulf, Fred - that is correct. The fix allows the rel specification to modify the order of things as long as it does not contradict the .app files. E.g. the rel file may change the order internally between included applications, but it may not change the fact that included applications are started before the application which includes them. /siri -------------- next part -------------- An HTML attachment was scrubbed... URL: From roe.adrian@REDACTED Thu Jan 31 12:15:07 2013 From: roe.adrian@REDACTED (Adrian Roe) Date: Thu, 31 Jan 2013 11:15:07 +0000 Subject: [erlang-questions] R16A binary packages for CentOS, Debian, Mac, Ubuntu and Windows In-Reply-To: <20130130165902.GA22351@dex.krakow> References: <20130130165902.GA22351@dex.krakow> Message-ID: I'm really excited about having access to observer etc on my Mac :) ? ? but not entirely plain sailing getting observer to run (trace below). Am I being stupid? Thanks for your help. Adrian -- Adrian Roe Sent with Sparrow (http://www.sparrowmailapp.com/?sig) 4> observer:start(). {error,{{load_driver,"dlopen(/usr/local/lib/erlang/lib/wx-1.0/priv/wxe_driver.so, 2): Symbol not found: __ZN10wxBoxSizer11RecalcSizesEv\n Referenced from: /usr/local/lib/erlang/lib/wx-1.0/priv/wxe_driver.so\n Expected in: flat namespace\n in /usr/local/lib/erlang/lib/wx-1.0/priv/wxe_driver.so"}, [{wxe_server,start,1,[{file,"wxe_server.erl"},{line,64}]}, {wx,new,1,[{file,"wx.erl"},{line,114}]}, {observer_wx,init,1,[{file,"observer_wx.erl"},{line,87}]}, {wx_object,init_it,6,[{file,"wx_object.erl"},{line,299}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,239}]}]}} 5> =ERROR REPORT==== 31-Jan-2013::11:10:42 === WX Failed loading "wxe_driver"@"/usr/local/lib/erlang/lib/wx-1.0/priv" On Wednesday, 30 January 2013 at 16:59, Karol Urbanski wrote: > Hello, > > You can find our binary packages for the newest Erlang release (R16A) at > http://www.erlang-solutions.com/downloads/download-erlang-otp > > The systems we provide the packages for are CentOS 6, Mac OS X Snow > Leopard and newer, Debian 6, Ubuntu 12.10 and Windows. More systems to > come soon! > > Best regards, > Karol Urbanski > _______________________________________________ > 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 karol.urbanski@REDACTED Thu Jan 31 13:26:07 2013 From: karol.urbanski@REDACTED (Karol Urbanski) Date: Thu, 31 Jan 2013 13:26:07 +0100 Subject: [erlang-questions] R16A binary packages for CentOS, Debian, Mac, Ubuntu and Windows In-Reply-To: References: <20130130165902.GA22351@dex.krakow> Message-ID: <20130131122606.GA28211@dex.krakow> Hi, apt-get installs the older version, as this is an A release and thus unstable. We don't want users to automatically update to a potentially unstable version, and thus the downloads aren't in the repository. Try downloading the package directly if you want to try it out. Or wait for the future R16B release, which will end up in the apt repositories. Best regards, Karol Urba?ski On Wed, Jan 30, 2013 at 10:25:03PM +0100, Waldemar Rachwa? wrote: > It looks that apt-get installs the older R15B03, not R16A. I checked on ubuntu quantal (amd64). > Regards, > Waldemar. > $ /usr/bin/erl > Erlang R15B03 (erts-5.9.3.1) [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false] > Eshell V5.9.3.1 (abort with ^G) > $ dpkg-query -S /usr/bin/erl > esl-erlang: /usr/bin/erl > > On Wed, Jan 30, 2013 at 5:59 PM, Karol Urbanski wrote: > > Hello, > You can find our binary packages for the newest Erlang release (R16A) at > http://www.erlang-solutions.com/downloads/download-erlang-otp > The systems we provide the packages for are CentOS 6, Mac OS X Snow > Leopard and newer, Debian 6, Ubuntu 12.10 and Windows. More systems to > come soon! > Best regards, > Karol Urbanski > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From karol.urbanski@REDACTED Thu Jan 31 13:42:56 2013 From: karol.urbanski@REDACTED (Karol Urbanski) Date: Thu, 31 Jan 2013 13:42:56 +0100 Subject: [erlang-questions] R16A binary packages for CentOS, Debian, Mac, Ubuntu and Windows In-Reply-To: References: <20130130165902.GA22351@dex.krakow> Message-ID: <20130131124255.GC28211@dex.krakow> Hi, There was a problem with linked dynamic libraries in yesterday's R16A 32-bit release. We've fixed this already, so try to download the package for your Mac again. If the problem persists, please let us know. Best regards, Karol Urbanski On Thu, Jan 31, 2013 at 11:15:07AM +0000, Adrian Roe wrote: > I'm really excited about having access to observer etc on my Mac :) ?? > > ?? but not entirely plain sailing getting observer to run (trace below). Am I being stupid? > > Thanks for your help. > > Adrian > > -- > Adrian Roe > Sent with Sparrow > > > > 4> observer:start(). > {error,{{load_driver,"dlopen(/usr/local/lib/erlang/lib/wx-1.0/priv/wxe_driver.so, 2): Symbol not found: __ZN10wxBoxSizer11RecalcSizesEv\n Referenced from: /usr/local/lib/erlang/lib/wx-1.0/priv/wxe_driver.so\n Expected in: flat namespace\n in /usr/local/lib/erlang/lib/wx-1.0/priv/wxe_driver.so"}, > [{wxe_server,start,1,[{file,"wxe_server.erl"},{line,64}]}, > {wx,new,1,[{file,"wx.erl"},{line,114}]}, > {observer_wx,init,1,[{file,"observer_wx.erl"},{line,87}]}, > {wx_object,init_it,6,[{file,"wx_object.erl"},{line,299}]}, > {proc_lib,init_p_do_apply,3, > [{file,"proc_lib.erl"},{line,239}]}]}} > 5> > =ERROR REPORT==== 31-Jan-2013::11:10:42 === > WX Failed loading "wxe_driver"@"/usr/local/lib/erlang/lib/wx-1.0/priv" > > On Wednesday, 30 January 2013 at 16:59, Karol Urbanski wrote: > > Hello, > You can find our binary packages for the newest Erlang release (R16A) at > http://www.erlang-solutions.com/downloads/download-erlang-otp > The systems we provide the packages for are CentOS 6, Mac OS X Snow > Leopard and newer, Debian 6, Ubuntu 12.10 and Windows. More systems to > come soon! > Best regards, > Karol Urbanski > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From jesper.louis.andersen@REDACTED Thu Jan 31 17:23:11 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 31 Jan 2013 17:23:11 +0100 Subject: [erlang-questions] Is -extends() used in any projects? In-Reply-To: <486a9625-4636-4c02-8fb8-1315eecf744b@googlegroups.com> References: <50FF3D13.2080300@ninenines.eu> <2114150206.2995699.1358906104941.JavaMail.root@erlang-solutions.com> <486a9625-4636-4c02-8fb8-1315eecf744b@googlegroups.com> Message-ID: On Jan 23, 2013, at 3:04 AM, Yurii Rashkovskii wrote: > What's interesting, using metaprogramming techniques available in Elixir, we can do a much better `-extend()` kind of functionality in Elixir: > You don't need metaprogramming for this however. Just a proper module system: signature M = sig val hello : unit -> string end structure Silly = struct fun hello () = "Hello World" end functor App(X : M) = struct open X end structure A = App(Silly) structure B = App(Silly) (Straight from the brain, not tested that much, but it passes the type checker of SML/NJ) But it may require a type system to pull off properly :) Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen > ``` > defmodule M do > defmacro __using__(_opts) do > quote do > def hello_world, do: "Hello, world!" > end > end > end > defmodule A do > use M > end > defmodule B do > use M > end > ``` > > Now, both modules A & B have the same shared hello_world/0 function and it's always exported, and A & B are completed decoupled from M after the compile cycle: > > ``` > iex(1)> A.hello_world > "Hello, world!" > iex(2)> B.hello_world > "Hello, world!" > iex(3)> A.module_info(:exports) > [__info__: 1, hello_world: 0, module_info: 0, module_info: 1] > iex(4)> B.module_info(:exports) > [__info__: 1, hello_world: 0, module_info: 0, module_info: 1] > ``` > > > On Tuesday, January 22, 2013 5:55:04 PM UTC-8, Robert Virding wrote: > I agree as well! I think being able to see clearly see what functions a module exports is a rule which we should always follow. > Robert > > ----- Original Message ----- > > From: "Lo?c Hoguin" > > To: "Richard O'Keefe" > > Cc: "erlang-questions" > > Sent: Wednesday, 23 January, 2013 2:29:55 AM > > Subject: Re: [erlang-questions] Is -extends() used in any projects? > > > > On 01/23/2013 02:09 AM, Richard O'Keefe wrote: > > > > > > On 22/01/2013, at 7:44 PM, Bj?rn Gustavsson wrote: > > > > > >> -extends() was mentioned when we first talked > > >> about removing parameterized modules, so we > > >> assumed that we needed to emulate -extends() > > >> as well as parameterized modules. > > >> > > >> It seems to be a good time to ask the question: > > >> > > >> Is -extends() used by real projects? Do we really > > >> need to emulate it? > > >> > > >> BTW, -extends() is described here: > > >> > > >> http://www.erlang.se/euc/07/papers/1700Carlsson.pdf > > > > > > I believe that the design described there takes a wrong > > > step on the very first non-title slide: > > > > > > All function calls to new_module:f(...) > > > will be redirected to old_module:f(...) > > > if f is *NOT* exported from new_module. > > > > > > I think that the rule "you may call m:f/n from > > > another module if and only if m explicitly > > > exports f/n" is an excellent rule. > > > > > > It means that if you want to know what are the things > > > in module m, the information is right there in the > > > source code and the beam and if it is loaded, > > > module_info gives it to you. > > > > > > With the design described in those slides, YOU NEVER > > > KNOW WHAT THE INTERFACE OF A MODULE (that has an > > > -extends in it) IS. > > > > > > If you *don't* break the module-interfaces-are-knowable > > > rule, you get a different design which is entirely > > > compile-time (and thus faster): > > > > > > If f/n is -exported > > > and f/n is not defined > > > and there is an -extends(m) > > > then generate a glue definition > > > f(A1,...,An) -> m:f(A1, ..., An). > > > > > > It's simple. > > > The full interface of a module remains discoverable. > > > > > > And it's *faster*, because the current design > > > requires the lack of a definition to be detected at > > > run time, a trap out to a special handler (with the > > > arguments packaged into a data structure), time to > > > figure out what was undefined, the arguments have to > > > be unpacked again, and finally what would have been > > > the body of the glue definition is executed. > > > To quote Jayne, "where does that get to be fun?" > > > > > > I once wrote a paper that I couldn't get published. > > > It described an object oriented extension to > > > Intercal, and it was as deliberately perverse as > > > plain Intercal. > > > > > > This particular attempt to turn Erlang into an OO > > > language reminds me very much of that paper, only > > > it isn't funny when it's real. > > > > > > I've built a Smalltalk implementation. Now Smalltalk > > > was originally a single-inheritance language, and its > > > dynamic typing means that there are fewer constraints > > > on what you can do that way than there are in typical > > > typed OO languages. Even so, there is rather more > > > code duplication than I am happy with, and it may be > > > this year that I finally add mixins. (Or it may not. > > > There are enough other things to worry about.) Why > > > mention that here? > > > > > > Because the way -extends is presented in that paper > > > means that it can only support single inheritance. > > > (Since the ability to determine a module's full > > > interface has been destroyed, it cannot handle > > > -extends(p). > > > -extends(q). > > > by checking which of p, q defines f/n.) And that's > > > an unjustified limitation. > > > > > > Change it slightly. Instead of -extends, use > > > > > > -export_from(Other_Module, Export_List). > > > > > > That's just a handy abbreviation form. > > > -export_from(m, [...,f/n,...]). > > > means > > > f(A1, ..., An) -> m:f(A1, ..., An). > > > > > > And now you have multiple inheritance. > > > And you have better compile-time checking: things > > > are not re-exported *implicitly*, so if an > > > -exported function is not defined in *this* module, > > > that's still an error. > > > > > > And the good part is that because a module's full > > > interface is discoverable, you can point your text > > > editor at a .beam file and say "generate me a > > > -export_from directive from _that_." (Which should > > > be done by calling a little command-line tool: > > > generating an -export_from directive doubles very > > > nicely as a way for a human to find out what a module > > > exports without having to read the source code, which > > > they might not have anyway.) > > > > Agree with everything. > > > > Thanks ROK for always making amazingly clear explanations. > > > > -- > > Lo?c Hoguin > > Erlang Cowboy > > Nine Nines > > http://ninenines.eu > > _______________________________________________ > > erlang-questions mailing list > > erlang-q...@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-q...@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vladdu55@REDACTED Thu Jan 31 19:23:31 2013 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 31 Jan 2013 19:23:31 +0100 Subject: [erlang-questions] OTP R16A has been released In-Reply-To: References: <20130130154013.GA10589@ferdmbp.local> <6FEE20A8-8792-4D2B-BBC8-B3B9FA988C4E@feuerlabs.com> Message-ID: Hi, It looks like R16 works nicely with erlide too. We have support for the new coding comment in source files and have fixed some issues with the console too (the latter is only available in the current nightly builds). best regards, Vlad On Thu, Jan 31, 2013 at 10:31 AM, Siri Hansen wrote: > > > 2013/1/31 Ulf Wiger > >> >> On 31 Jan 2013, at 09:54, Siri Hansen wrote: >> >> Hi Fred! >> Kernel and stdlib will always be started first. Other applications you >> can sort as you want. >> >> >> Siri, >> >> Isn't it so that reltool_target:sort_apps/1 is still called, and that it >> retains the specified order *unless* it violates application dependencies? >> That is, if application dependencies require a change to the order, >> sort_apps/1 will change the order to fulfill these requirements, but it >> will not change an order that is legal. >> >> I interpreted that as the essence Fred's question (otherwise, it is just >> mine). >> >> BR, >> Ulf W >> >> Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. >> http://feuerlabs.com >> > > Ulf, Fred - > that is correct. The fix allows the rel specification to modify the order > of things as long as it does not contradict the .app files. E.g. the rel > file may change the order internally between included applications, but it > may not change the fact that included applications are started before the > application which includes them. > /siri > > _______________________________________________ > 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 Jan 31 20:28:20 2013 From: erlang@REDACTED (Erik Reitsma) Date: Thu, 31 Jan 2013 20:28:20 +0100 Subject: [erlang-questions] OTP R16A has been released In-Reply-To: References: Message-ID: <510AC5D4.7040500@ernovation.com> Hi Kenneth, Could you update the config.sub and config.guess to include arm-linux-androideabi, unless there is a reason to keep the 2007 version in favor of the one from 2012-12-30? The fewer files I need to update to cross-compile for Android, the better! Regards, *Erik. From john@REDACTED Thu Jan 31 22:08:42 2013 From: john@REDACTED (John Kemp) Date: Thu, 31 Jan 2013 16:08:42 -0500 Subject: [erlang-questions] "Automatic" recompile app from a console Message-ID: <510ADD5A.4060103@jkemp.net> Hi, I have been writing an application using rebar to build the app. I run the server and open a console. I then change the source code and apparently I need to leave the console, 'make rel' and restart the app and the console. I'm sure there's a better way to do what I'm doing. One project I found is https://github.com/rustyio/sync, but this did not (yet) work for me according to the instructions. How can I have my rebar (or just Erlang) app automatically recompile ('make rel') when one of the source files changes, or run a command from within the console to do this? Cheers, JohnK From g@REDACTED Thu Jan 31 22:25:33 2013 From: g@REDACTED (Garrett Smith) Date: Thu, 31 Jan 2013 15:25:33 -0600 Subject: [erlang-questions] "Automatic" recompile app from a console In-Reply-To: <510ADD5A.4060103@jkemp.net> References: <510ADD5A.4060103@jkemp.net> Message-ID: On Thu, Jan 31, 2013 at 3:08 PM, John Kemp wrote: > Hi, > > I have been writing an application using rebar to build the app. I run the > server and open a console. I then change the source code and apparently I > need to leave the console, 'make rel' and restart the app and the console. > > I'm sure there's a better way to do what I'm doing. > > One project I found is https://github.com/rustyio/sync, but this did not > (yet) work for me according to the instructions. > > How can I have my rebar (or just Erlang) app automatically recompile ('make > rel') when one of the source files changes, or run a command from within the > console to do this? You're asking about a completely different workflow, but on the outside chance you're simply looking for a streamlined way to integrate the shell with your programming, this is what I use: - Edit and compile source explicitly (I have a key binding to run "make" in Emacs, but I'm sure most editors have an easy equivalent) - Let mochiweb's reloader, which is started using the "-s reloader" option, automatically reload the modified beams I *live* in the Erlang shell during development, always using this workflow. When I watch others constantly closing and restarting the Erlang shell in between changes, I wonder how on earth they get anything done :) Garrett From john@REDACTED Thu Jan 31 22:32:26 2013 From: john@REDACTED (John Kemp) Date: Thu, 31 Jan 2013 16:32:26 -0500 Subject: [erlang-questions] "Automatic" recompile app from a console In-Reply-To: References: <510ADD5A.4060103@jkemp.net> Message-ID: <510AE2EA.4060308@jkemp.net> On 01/31/2013 04:25 PM, Garrett Smith wrote: > You're asking about a completely different workflow, but on the > outside chance you're simply looking for a streamlined way to > integrate the shell with your programming, I am :) > this is what I use: > > - Edit and compile source explicitly (I have a key binding to run > "make" in Emacs, but I'm sure most editors have an easy equivalent) This is the part that was failing for me, actually - I get an error about reloading a beam file when I ran the make from within emacs. Works OK from a command line, but not from emacs. > > - Let mochiweb's reloader, which is started using the "-s reloader" > option, automatically reload the modified beams > > I *live* in the Erlang shell during development, always using this > workflow. When I watch others constantly closing and restarting the > Erlang shell in between changes, I wonder how on earth they get > anything done :) I programmed in Erlang a few years ago and gave it up. I don't remember how I worked before but I'm pretty sure I wouldn't have lived with this either :) So now I need to get it working again... Cheers, John > > Garrett > From g@REDACTED Thu Jan 31 23:36:27 2013 From: g@REDACTED (Garrett Smith) Date: Thu, 31 Jan 2013 16:36:27 -0600 Subject: [erlang-questions] "Automatic" recompile app from a console In-Reply-To: <510AE2EA.4060308@jkemp.net> References: <510ADD5A.4060103@jkemp.net> <510AE2EA.4060308@jkemp.net> Message-ID: On Thu, Jan 31, 2013 at 3:32 PM, John Kemp wrote: > On 01/31/2013 04:25 PM, Garrett Smith wrote: > >> You're asking about a completely different workflow, but on the >> outside chance you're simply looking for a streamlined way to >> integrate the shell with your programming, > > > I am :) > > >> this is what I use: >> >> - Edit and compile source explicitly (I have a key binding to run >> "make" in Emacs, but I'm sure most editors have an easy equivalent) > > > This is the part that was failing for me, actually - I get an error about > reloading a beam file when I ran the make from within emacs. Works OK from a > command line, but not from emacs. This is what I have in my emacs.d/init.el: (global-set-key (kbd "C-x RET") 'compile) So it's CTRL-C M and I get the compile prompt, which defaults to "make -k", then enter. Of course I have a Makefile that contains ./rebar compile in the default target. Emacs knows how to go to the source line on error with CTRL ` I personally would not want my compiler to auto-compile when I saved the file, though I realize some IDEs not only do that, but try to compile as you type! Everyone has a different thing though. >> >> - Let mochiweb's reloader, which is started using the "-s reloader" >> option, automatically reload the modified beams >> >> I *live* in the Erlang shell during development, always using this >> workflow. When I watch others constantly closing and restarting the >> Erlang shell in between changes, I wonder how on earth they get >> anything done :) > > > I programmed in Erlang a few years ago and gave it up. I don't remember how > I worked before but I'm pretty sure I wouldn't have lived with this either > :) So now I need to get it working again... Good luck! Garrett