From mjtruog@REDACTED Wed Feb 1 01:44:31 2012 From: mjtruog@REDACTED (Michael Truog) Date: Tue, 31 Jan 2012 16:44:31 -0800 Subject: [erlang-questions] Erlang and cloud computing In-Reply-To: <26e8f451-450b-4820-ac08-f306ea649662@j15g2000yqb.googlegroups.com> References: <4F2850D6.9080602@gmail.com> <26e8f451-450b-4820-ac08-f306ea649662@j15g2000yqb.googlegroups.com> Message-ID: <4F288AEF.7040503@gmail.com> On 01/31/2012 02:16 PM, eigenfunction wrote: > I have always been intrigued by cloudi but never had the time to take > it for a ride. Lets say that i am building a website in erlang and > decide to use java for (jdbc)database access or to use some NLP > librairies. In what way can cloudi be beneficial over, say, plain old > jinterface? When using plain old jinterface, the JVM is used as a cnode by Erlang. However, when using the Java CloudI API, CloudI starts the JVM as an Erlang port while using jinterface for the communication within the JVM, for multiple sockets, so that each socket opened for the JVM can be used by a separate Java thread. By doing things this way, there are a few benefits: 1) CloudI can facilitate more scalable Java source code execution with concurrent messaging done by separate Java threads (i.e., no shared Java data or Java locks). 2) CloudI does not run the JVM as a cnode, so it does not limit the scalability of the Erlang cluster based on the net tick time and the JVM responsiveness. Distributed Erlang is limited to roughly 50 - 100 connected nodes, because of the net tick time checking. Not running the JVM as an Erlang node helps to conserve distributed Erlang node connections so that they are only used for remote CloudI instances (on the LAN). This also helps to avoid extra overhead within the JVM that would otherwise be doing the net tick time responses, because the JVM is ran on the local machine and is already managed as a separate OS process. 3) CloudI manages the fault-tolerance of the JVM execution, so that unstable Java source code can still be ran with limited interruption if the JVM dies infrequently. > On Jan 31, 9:36 pm, Michael Truog wrote: >> On 01/30/2012 07:40 AM, Yves S. Garret wrote: >> >> >> >>> I have a curiosity question. Is Erlang being used somehow in the field of cloud computing? The idea of splitting up a task and then processing it in pieces in parallel seems right up Erlang's alley. >>> I have looked at Windows Azure, but they mostly use .NET languages, are there services where you can have a cloud computing environment and use Erlang to do the application development? What has been your experience if you have used Erlang in cloud computing? >> There is a public/private cloud computing framework that I have been working on for a few years called CloudI (http://cloudi.org). CloudI helps take advantage of Erlang's actor model, extending it into C/C++, Java, Python, and Ruby, to provide fault tolerance and scalability. Erlang is very applicable to cloud computing, since it provides real fault-tolerance... while there are attempts to provide fault-tolerance within JVM languages, it is limited by their single heap garbage collection strategy (which also helps to limit scalability). So, it is very beneficial to have solid supervision tree functionality to manage fault-tolerance within the Erlang language. Other cloud computing source code and services are unable to provide granular fault-tolerance... they focus on large system redundancy, like with the AWS zones or avoid an AWS zone outage. With CloudI, it is much simpler to test without a public deployment, so you can make architectural decisions without getting >> locked into a particular cloud computing service and that allows you to focus on lower-level fault-tolerance/scalability concerns. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From steven.charles.davis@REDACTED Wed Feb 1 02:02:18 2012 From: steven.charles.davis@REDACTED (Steve Davis) Date: Tue, 31 Jan 2012 17:02:18 -0800 (PST) Subject: [erlang-questions] Erlang and cloud computing In-Reply-To: References: Message-ID: <21fc6356-de0c-497b-b285-4d8693b633c0@q8g2000yqa.googlegroups.com> Another interesting related project (more focused on enterprise scalability, not necessarily "cloud" computing) is Spring Integration. The centerpiece of the new Spring Integration framework is RabbitMQ, which is of course an AMQP server written entirely in Erlang/OTP. On Jan 30, 9:40?am, "Yves S. Garret" wrote: > Hello, > > ? ?I have a curiosity question. ?Is Erlang being used somehow in the field > of cloud computing? ?The idea of splitting up a task and then processing it > in pieces in parallel seems right up Erlang's alley. > > ? ?I have looked at Windows Azure, but they mostly use .NET languages, are > there services where you can have a cloud computing environment and use > Erlang to do the application development? ?What has been your experience if > you have used Erlang in cloud computing? > > --Yves > > _______________________________________________ > erlang-questions mailing list > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions From steven.charles.davis@REDACTED Wed Feb 1 02:21:55 2012 From: steven.charles.davis@REDACTED (Steve Davis) Date: Tue, 31 Jan 2012 17:21:55 -0800 (PST) Subject: [erlang-questions] smtp server In-Reply-To: References: Message-ID: <2b8d6c69-23d1-4046-8878-09d4729637a4@gi10g2000vbb.googlegroups.com> I have noticed that a great number of SMTP projects fail with a whimper. In particular, I observed that the JBoss project ran an SMTP project for a long, long time before even barely having something reasonable, and it's still not really "production quality". While the underlying protocol for SMTP is straightforward, I think things run aground owing to the teams initially underestimating the number of rfcs and protocol extensions that you are essentially *required* to support (especially wrt authentication etc) to have a production level server; and also the storage issues such as the user directory and message store. There's no reason it couldn't be done, of course, but there's a lot of moving parts that need to come together to make it a real production competitor to the venerable sendmail or servers like MS exchange. As far as Erlang is concerned, it's hard to see it happening until certain requisite libraries are mature. For instance, START_TLS is still not "easy" in erlang owing to the long, and continuing, struggle to get good TLS protocol support. Assuming that does get "finished" (and there's a whole raft of crypto work still to do), perhaps a good start towards such a goal would be to integrate, at the very least, an LDAP client into the base libraries... ok before I ramble too much, I'll leave my 2c there. regards, /s On Jan 29, 12:56?am, Roberto Ostinelli wrote: > dear list, > > are you aware of any existent production-ready SMTP server in Erlang? I've > only found, maintained:https://github.com/Vagabond/gen_smtp > > thank you, > > r. > > _______________________________________________ > erlang-questions mailing list > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions From ok@REDACTED Wed Feb 1 04:27:39 2012 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 1 Feb 2012 16:27:39 +1300 Subject: [erlang-questions] XML diff In-Reply-To: References: Message-ID: <3D88AA58-1851-459D-96D9-E1D64DD93BB2@cs.otago.ac.nz> Look at http://www.cs.umd.edu/Outreach/hsContest99/questions/node8.html and follow the "Our Solution" link. which refers to Stanley Selkow's paper in Information Processing Letters, Volume 6, number 6, 1977. There's a paper by Wuu Yang in Software Practice and Experience, Volume 21, issue 7, 739-755 (July 1991), called "Identifying Syntactic Differences Between Two Programs" which works by finding differences between their parse trees. There's a Perl module for precisely this task at http://search.cpan.org/~sdether/XML-Diff-0.04/Diff.pm The documentation points to Gregory Cobena's PhD thesis which can be found through at http://gregory.cobena.free.fr/www/Publications/thesis.html I haven't read that, but it has a chapter comparing several algorithms. From swetha.2112@REDACTED Wed Feb 1 08:48:30 2012 From: swetha.2112@REDACTED (Swetha) Date: Tue, 31 Jan 2012 23:48:30 -0800 (PST) Subject: [erlang-questions] Stand alone TLS encryption module? In-Reply-To: <56DA5079467D1C48B857C6FE59D5D4FC5877D3@prodeaserve.prodea.local> References: <56DA5079467D1C48B857C6FE59D5D4FC5874A4@prodeaserve.prodea.local> <464432E4.6080507@niclux.org> <56DA5079467D1C48B857C6FE59D5D4FC5877D3@prodeaserve.prodea.local> Message-ID: <1328082510831-4347165.post@n4.nabble.com> Hi Michael, I have a similar requirement of load testing XMPP+TLS,i have been using Tsung non-ssl connections have been not bale to find a tool which supports TLS.Were you able to find a solution for it ? If yes could you please share it with me. Thanks, Swetha -- View this message in context: http://erlang.2086793.n4.nabble.com/Stand-alone-TLS-encryption-module-tp2095788p4347165.html Sent from the Erlang Questions mailing list archive at Nabble.com. From swetha.2112@REDACTED Wed Feb 1 08:52:24 2012 From: swetha.2112@REDACTED (Swetha) Date: Tue, 31 Jan 2012 23:52:24 -0800 (PST) Subject: [erlang-questions] Stand alone TLS encryption module? In-Reply-To: References: <56DA5079467D1C48B857C6FE59D5D4FC5874A4@prodeaserve.prodea.local> Message-ID: <1328082744426-4347172.post@n4.nabble.com> Chandru-4 wrote > > > Have you tried using stunnel(*) to sit in between Tsung and ejabberd? > That way you don't have to change Tsung at all. > > Chandru > > Hi Chandru, > Have you been successful with this approach ?Could you > please share your findings > > Thanks, > Swetha > > * http://stunnel.org > _______________________________________________ > erlang-questions mailing list > erlang-questions@ > http://www.erlang.org/mailman/listinfo/erlang-questions > -- View this message in context: http://erlang.2086793.n4.nabble.com/Stand-alone-TLS-encryption-module-tp2095788p4347172.html Sent from the Erlang Questions mailing list archive at Nabble.com. From jakob@REDACTED Wed Feb 1 09:05:10 2012 From: jakob@REDACTED (Jakob Praher) Date: Wed, 01 Feb 2012 09:05:10 +0100 Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions In-Reply-To: <7732-4f27e780-9-748af280@35816950> Message-ID: <4aaf-4f28f200-3-4452b880@168192673> Hi Erlangers, I think people should pay attention to issues faced by experienced newcomers in exercising Erlang programming. Matz from Ruby calls a ver important design principle, the principle of least surprise. No matter that the following may be a syntactic surface issue, but designating function objects is neither orthogonal nor does follow the expectations of the programmer. Therefore it also makes understanding code harder. if I can write: module:fun(). I should be also able to write F = module:fun, F(). and not having to write F = fun module:fun/0, F(). . I am happy to learn why module:fun is not an expression. Best, Jakob Am Dienstag, 31. Januar 2012 14:07 CET, "Jakob Praher" schrieb: > > As I tried out the code below I learned that tuples of module and function atoms evalute to functions, not atoms by themselves. > If one can apply arguments to a tuple, why not to an atom if this would be denote a function in the current environment? > > {R, V} = apply_each([{m1,z},{m2,y},{m3,x}], Arg). > if R = ok -> ... > > Thanks, > Jakob > > > Am Mittwoch, 25. Januar 2012 14:29 CET, "Jakob Praher" schrieb: > > > > > One could also compose a sequence of functions much like in combinator parsing, and fail at the first event returning the error status, otherwise continue to call apply the functions to the result. > > > > apply_each([F|FS],X) -> > > {S, V} = F(X), > > if S = error -> > > {S, V} > > S = ok -> > > apply_each(FS, V); > > end > > . > > > > {R, V} = apply_each([z,y,x], Arg). > > if R = ok -> ... > > > > I have not much practice in Erlang (though I have some practice in Prolog), so this might not be 100 % correct. > > > > Cheers, > > Jakob > > > > Am Mittwoch, 25. Januar 2012 13:16 CET, Joe Armstrong schrieb: > > > > > I think you are asking the wrong question. If a function returns > > > {ok,Val} | {error,Reason} > > > then I think to myself "the caller of this function expects things to > > > go wrong and is > > > committed to handling *both* return values. > > > > > > So they would *never* write w(x(y(z(....))) because this does not cater for both > > > return values. > > > > > > With the "let it crash" philosophy one would make w,x,y, .. return a > > > value OR call exit(...). > > > With this convention things do nest in the "happy" case without using > > > a staircase. > > > > > > At the top level try or catch is used to catch the error. > > > > > > Alternatively you could say > > > > > > ok({ok,X}) -> X; > > > ok{error,E}) -> exit(E). > > > > > > and then > > > > > > w(ok(x(ok(y(ok(z(X)))))) > > > > > > Not pretty but it does the job > > > > > > /Joe > > > > > > > > > On Tue, Jan 24, 2012 at 8:31 PM, Reynaldo Baquerizo > > > wrote: > > > > > > > > A friend of mine asked: > > > > > > > > ## > > > > If you have functions that return {ok, Result} | {error, Reason} > > > > how do you chained them? So that you have: > > > > > > > > w(x(y(z(...)))) > > > > > > > > without building a staircasing. Something that would be done in Haskell > > > > with monads. > > > > ## > > > > > > > > I would probably go for: > > > > > > > > x({ok, Value}) -> > > > > ?NewValue = , > > > > ?{ok, NewValue}; > > > > x({error, Reason}) -> > > > > ?{error, Reason}. > > > > > > > > in each function > > > > > > > > which brings me other question, when do you tag return values? > > > > > > > > I tend to only use tagged return values with impure functions, were an > > > > error is more likely due to side effects. > > > > > > > > -- > > > > Reynaldo > > > > _______________________________________________ > > > > erlang-questions mailing list > > > > erlang-questions@REDACTED > > > > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > From bengt.kleberg@REDACTED Wed Feb 1 09:14:37 2012 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Wed, 1 Feb 2012 09:14:37 +0100 Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions In-Reply-To: <4aaf-4f28f200-3-4452b880@168192673> References: <4aaf-4f28f200-3-4452b880@168192673> Message-ID: <1328084077.12502.4.camel@seasc1137> Greetings, This is perhaps totally wrong but in my mind allowing F = module:fun, F(). would also mean that this is good: F = module:fun(, F). Ie, "F = module:fun" is text/syntax, not semantic. bengt On Wed, 2012-02-01 at 09:05 +0100, Jakob Praher wrote: > Hi Erlangers, > > I think people should pay attention to issues faced by experienced newcomers in exercising Erlang programming. Matz from Ruby calls a ver important design principle, the principle of least surprise. > > No matter that the following may be a syntactic surface issue, but designating function objects is neither orthogonal nor does follow the expectations of the programmer. Therefore it also makes understanding code harder. > > if I can write: > module:fun(). > I should be also able to write > F = module:fun, F(). > and not having to write > F = fun module:fun/0, F(). > . > > I am happy to learn why module:fun is not an expression. > > Best, > Jakob > > > Am Dienstag, 31. Januar 2012 14:07 CET, "Jakob Praher" schrieb: > > > > > As I tried out the code below I learned that tuples of module and function atoms evalute to functions, not atoms by themselves. > > If one can apply arguments to a tuple, why not to an atom if this would be denote a function in the current environment? > > > > {R, V} = apply_each([{m1,z},{m2,y},{m3,x}], Arg). > > if R = ok -> ... > > > > Thanks, > > Jakob > > > > > > Am Mittwoch, 25. Januar 2012 14:29 CET, "Jakob Praher" schrieb: > > > > > > > > One could also compose a sequence of functions much like in combinator parsing, and fail at the first event returning the error status, otherwise continue to call apply the functions to the result. > > > > > > apply_each([F|FS],X) -> > > > {S, V} = F(X), > > > if S = error -> > > > {S, V} > > > S = ok -> > > > apply_each(FS, V); > > > end > > > . > > > > > > {R, V} = apply_each([z,y,x], Arg). > > > if R = ok -> ... > > > > > > I have not much practice in Erlang (though I have some practice in Prolog), so this might not be 100 % correct. > > > > > > Cheers, > > > Jakob > > > > > > Am Mittwoch, 25. Januar 2012 13:16 CET, Joe Armstrong schrieb: > > > > > > > I think you are asking the wrong question. If a function returns > > > > {ok,Val} | {error,Reason} > > > > then I think to myself "the caller of this function expects things to > > > > go wrong and is > > > > committed to handling *both* return values. > > > > > > > > So they would *never* write w(x(y(z(....))) because this does not cater for both > > > > return values. > > > > > > > > With the "let it crash" philosophy one would make w,x,y, .. return a > > > > value OR call exit(...). > > > > With this convention things do nest in the "happy" case without using > > > > a staircase. > > > > > > > > At the top level try or catch is used to catch the error. > > > > > > > > Alternatively you could say > > > > > > > > ok({ok,X}) -> X; > > > > ok{error,E}) -> exit(E). > > > > > > > > and then > > > > > > > > w(ok(x(ok(y(ok(z(X)))))) > > > > > > > > Not pretty but it does the job > > > > > > > > /Joe > > > > > > > > > > > > On Tue, Jan 24, 2012 at 8:31 PM, Reynaldo Baquerizo > > > > wrote: > > > > > > > > > > A friend of mine asked: > > > > > > > > > > ## > > > > > If you have functions that return {ok, Result} | {error, Reason} > > > > > how do you chained them? So that you have: > > > > > > > > > > w(x(y(z(...)))) > > > > > > > > > > without building a staircasing. Something that would be done in Haskell > > > > > with monads. > > > > > ## > > > > > > > > > > I would probably go for: > > > > > > > > > > x({ok, Value}) -> > > > > > NewValue = , > > > > > {ok, NewValue}; > > > > > x({error, Reason}) -> > > > > > {error, Reason}. > > > > > > > > > > in each function > > > > > > > > > > which brings me other question, when do you tag return values? > > > > > > > > > > I tend to only use tagged return values with impure functions, were an > > > > > error is more likely due to side effects. > > > > > > > > > > -- > > > > > Reynaldo > > > > > _______________________________________________ > > > > > erlang-questions mailing list > > > > > erlang-questions@REDACTED > > > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > > > > erlang-questions mailing list > > > > erlang-questions@REDACTED > > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > > > > > > > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From emeka_1978@REDACTED Wed Feb 1 09:25:02 2012 From: emeka_1978@REDACTED (eigenfunction) Date: Wed, 1 Feb 2012 00:25:02 -0800 (PST) Subject: [erlang-questions] Simple NAT traversal Message-ID: <7b4e7bc9-b97f-421d-806a-93bfaee58697@dp8g2000vbb.googlegroups.com> Hi everybody, i have an erlang application running behind a nat. Now i have come to a point where i need to know my public ip. I was thinking about running a tiny tcp server behind the nat whose sole purpose would be to send me my public ip. My question is this: isn't there a more simple alternative? Heck, even if i could determine the public ip of the NAT device without doing a "backflip" it will be enough for my case. Any idea? From emeka_1978@REDACTED Wed Feb 1 09:26:05 2012 From: emeka_1978@REDACTED (eigenfunction) Date: Wed, 1 Feb 2012 00:26:05 -0800 (PST) Subject: [erlang-questions] Erlang and cloud computing In-Reply-To: <4F288AEF.7040503@gmail.com> References: <4F2850D6.9080602@gmail.com> <26e8f451-450b-4820-ac08-f306ea649662@j15g2000yqb.googlegroups.com> <4F288AEF.7040503@gmail.com> Message-ID: <69b682ed-7eeb-42bb-951c-1c26952187c4@s7g2000vby.googlegroups.com> Thanks for the explanation. That sounds good. On 1 Feb., 01:44, Michael Truog wrote: > On 01/31/2012 02:16 PM, eigenfunction wrote: > > > I have always been intrigued by cloudi but never had the time to take > > it for a ride. Lets say that i am building a website in erlang and > > decide to use java for (jdbc)database access or to use some NLP > > librairies. In what way can cloudi be beneficial over, say, plain old > > jinterface? > > When using plain old jinterface, the JVM is used as a cnode by Erlang. ?However, when using the Java CloudI API, CloudI starts the JVM as an Erlang port while using jinterface for the communication within the JVM, for multiple sockets, so that each socket opened for the JVM can be used by a separate Java thread. ?By doing things this way, there are a few benefits: > 1) CloudI can facilitate more scalable Java source code execution with concurrent messaging done by separate Java threads (i.e., no shared Java data or Java locks). > 2) CloudI does not run the JVM as a cnode, so it does not limit the scalability of the Erlang cluster based on the net tick time and the JVM responsiveness. ?Distributed Erlang is limited to roughly 50 - 100 connected nodes, because of the net tick time checking. ?Not running the JVM as an Erlang node helps to conserve distributed Erlang node connections so that they are only used for remote CloudI instances (on the LAN). ?This also helps to avoid extra overhead within the JVM that would otherwise be doing the net tick time responses, because the JVM is ran on the local machine and is already managed as a separate OS process. > 3) CloudI manages the fault-tolerance of the JVM execution, so that unstable Java source code can still be ran with limited interruption if the JVM dies infrequently. > > > > > > > > > > > On Jan 31, 9:36 pm, Michael Truog wrote: > >> On 01/30/2012 07:40 AM, Yves S. Garret wrote: > > >>> ? ?I have a curiosity question. ?Is Erlang being used somehow in the field of cloud computing? ?The idea of splitting up a task and then processing it in pieces in parallel seems right up Erlang's alley. > >>> ? ?I have looked at Windows Azure, but they mostly use .NET languages, are there services where you can have a cloud computing environment and use Erlang to do the application development? ?What has been your experience if you have used Erlang in cloud computing? > >> There is a public/private cloud computing framework that I have been working on for a few years called CloudI (http://cloudi.org). ?CloudI helps take advantage of Erlang's actor model, extending it into C/C++, Java, Python, and Ruby, to provide fault tolerance and scalability. ?Erlang is very applicable to cloud computing, since it provides real fault-tolerance... while there are attempts to provide fault-tolerance within JVM languages, it is limited by their single heap garbage collection strategy (which also helps to limit scalability). ?So, it is very beneficial to have solid supervision tree functionality to manage fault-tolerance within the Erlang language. ?Other cloud computing source code and services are unable to provide granular fault-tolerance... they focus on large system redundancy, like with the AWS zones or avoid an AWS zone outage. ?With CloudI, it is much simpler to test without a public deployment, so you can make architectural decisions without getting > >> locked into a particular cloud computing service and that allows you to focus on lower-level fault-tolerance/scalability concerns. > > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > > erlang-questions mailing list > > erlang-questi...@REDACTED > >http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions From jakob@REDACTED Wed Feb 1 10:05:16 2012 From: jakob@REDACTED (Jakob Praher) Date: Wed, 01 Feb 2012 10:05:16 +0100 Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions In-Reply-To: <1328084077.12502.4.camel@seasc1137> Message-ID: <6a2e-4f290080-5-6b8b4580@717786> Thanks for your reply. As a counterargument F = {module,fun}, F(). works. Also in this case F is just the designator and not the function itself. It would be possible for instance to evaluate module:fun as {module,fun}. Best, Jakob Am Mittwoch, 01. Februar 2012 09:14 CET, Bengt Kleberg schrieb: > Greetings, > > This is perhaps totally wrong but in my mind allowing > F = module:fun, > F(). > > would also mean that this is good: > F = module:fun(, > F). > > Ie, "F = module:fun" is text/syntax, not semantic. > > > bengt > > On Wed, 2012-02-01 at 09:05 +0100, Jakob Praher wrote: > > Hi Erlangers, > > > > I think people should pay attention to issues faced by experienced newcomers in exercising Erlang programming. Matz from Ruby calls a ver important design principle, the principle of least surprise. > > > > No matter that the following may be a syntactic surface issue, but designating function objects is neither orthogonal nor does follow the expectations of the programmer. Therefore it also makes understanding code harder. > > > > if I can write: > > module:fun(). > > I should be also able to write > > F = module:fun, F(). > > and not having to write > > F = fun module:fun/0, F(). > > . > > > > I am happy to learn why module:fun is not an expression. > > > > Best, > > Jakob > > > > > > Am Dienstag, 31. Januar 2012 14:07 CET, "Jakob Praher" schrieb: > > > > > > > > As I tried out the code below I learned that tuples of module and function atoms evalute to functions, not atoms by themselves. > > > If one can apply arguments to a tuple, why not to an atom if this would be denote a function in the current environment? > > > > > > {R, V} = apply_each([{m1,z},{m2,y},{m3,x}], Arg). > > > if R = ok -> ... > > > > > > Thanks, > > > Jakob > > > > > > > > > Am Mittwoch, 25. Januar 2012 14:29 CET, "Jakob Praher" schrieb: > > > > > > > > > > > One could also compose a sequence of functions much like in combinator parsing, and fail at the first event returning the error status, otherwise continue to call apply the functions to the result. > > > > > > > > apply_each([F|FS],X) -> > > > > {S, V} = F(X), > > > > if S = error -> > > > > {S, V} > > > > S = ok -> > > > > apply_each(FS, V); > > > > end > > > > . > > > > > > > > {R, V} = apply_each([z,y,x], Arg). > > > > if R = ok -> ... > > > > > > > > I have not much practice in Erlang (though I have some practice in Prolog), so this might not be 100 % correct. > > > > > > > > Cheers, > > > > Jakob > > > > > > > > Am Mittwoch, 25. Januar 2012 13:16 CET, Joe Armstrong schrieb: > > > > > > > > > I think you are asking the wrong question. If a function returns > > > > > {ok,Val} | {error,Reason} > > > > > then I think to myself "the caller of this function expects things to > > > > > go wrong and is > > > > > committed to handling *both* return values. > > > > > > > > > > So they would *never* write w(x(y(z(....))) because this does not cater for both > > > > > return values. > > > > > > > > > > With the "let it crash" philosophy one would make w,x,y, .. return a > > > > > value OR call exit(...). > > > > > With this convention things do nest in the "happy" case without using > > > > > a staircase. > > > > > > > > > > At the top level try or catch is used to catch the error. > > > > > > > > > > Alternatively you could say > > > > > > > > > > ok({ok,X}) -> X; > > > > > ok{error,E}) -> exit(E). > > > > > > > > > > and then > > > > > > > > > > w(ok(x(ok(y(ok(z(X)))))) > > > > > > > > > > Not pretty but it does the job > > > > > > > > > > /Joe > > > > > > > > > > > > > > > On Tue, Jan 24, 2012 at 8:31 PM, Reynaldo Baquerizo > > > > > wrote: > > > > > > > > > > > > A friend of mine asked: > > > > > > > > > > > > ## > > > > > > If you have functions that return {ok, Result} | {error, Reason} > > > > > > how do you chained them? So that you have: > > > > > > > > > > > > w(x(y(z(...)))) > > > > > > > > > > > > without building a staircasing. Something that would be done in Haskell > > > > > > with monads. > > > > > > ## > > > > > > > > > > > > I would probably go for: > > > > > > > > > > > > x({ok, Value}) -> > > > > > > NewValue = , > > > > > > {ok, NewValue}; > > > > > > x({error, Reason}) -> > > > > > > {error, Reason}. > > > > > > > > > > > > in each function > > > > > > > > > > > > which brings me other question, when do you tag return values? > > > > > > > > > > > > I tend to only use tagged return values with impure functions, were an > > > > > > error is more likely due to side effects. > > > > > > > > > > > > -- > > > > > > Reynaldo > > > > > > _______________________________________________ > > > > > > erlang-questions mailing list > > > > > > erlang-questions@REDACTED > > > > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > _______________________________________________ > > > > > erlang-questions mailing list > > > > > erlang-questions@REDACTED > > > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > erlang-questions mailing list > > > > erlang-questions@REDACTED > > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bengt.kleberg@REDACTED Wed Feb 1 10:17:29 2012 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Wed, 1 Feb 2012 10:17:29 +0100 Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions In-Reply-To: <6a2e-4f290080-5-6b8b4580@717786> References: <6a2e-4f290080-5-6b8b4580@717786> Message-ID: <1328087849.12502.11.camel@seasc1137> I think {module,fun} is a complete ''thing'' (grammar item?) whereas module:fun is lacking a final () to be complete. bengt On Wed, 2012-02-01 at 10:05 +0100, Jakob Praher wrote: > Thanks for your reply. > > As a counterargument F = {module,fun}, F(). works. > Also in this case F is just the designator and not the function itself. > > It would be possible for instance to evaluate module:fun as {module,fun}. > > Best, > Jakob > > > > Am Mittwoch, 01. Februar 2012 09:14 CET, Bengt Kleberg schrieb: > > > Greetings, > > > > This is perhaps totally wrong but in my mind allowing > > F = module:fun, > > F(). > > > > would also mean that this is good: > > F = module:fun(, > > F). > > > > Ie, "F = module:fun" is text/syntax, not semantic. > > > > > > bengt > > > > On Wed, 2012-02-01 at 09:05 +0100, Jakob Praher wrote: > > > Hi Erlangers, > > > > > > I think people should pay attention to issues faced by experienced newcomers in exercising Erlang programming. Matz from Ruby calls a ver important design principle, the principle of least surprise. > > > > > > No matter that the following may be a syntactic surface issue, but designating function objects is neither orthogonal nor does follow the expectations of the programmer. Therefore it also makes understanding code harder. > > > > > > if I can write: > > > module:fun(). > > > I should be also able to write > > > F = module:fun, F(). > > > and not having to write > > > F = fun module:fun/0, F(). > > > . > > > > > > I am happy to learn why module:fun is not an expression. > > > > > > Best, > > > Jakob > > > > > > > > > Am Dienstag, 31. Januar 2012 14:07 CET, "Jakob Praher" schrieb: > > > > > > > > > > > As I tried out the code below I learned that tuples of module and function atoms evalute to functions, not atoms by themselves. > > > > If one can apply arguments to a tuple, why not to an atom if this would be denote a function in the current environment? > > > > > > > > {R, V} = apply_each([{m1,z},{m2,y},{m3,x}], Arg). > > > > if R = ok -> ... > > > > > > > > Thanks, > > > > Jakob > > > > > > > > > > > > Am Mittwoch, 25. Januar 2012 14:29 CET, "Jakob Praher" schrieb: > > > > > > > > > > > > > > One could also compose a sequence of functions much like in combinator parsing, and fail at the first event returning the error status, otherwise continue to call apply the functions to the result. > > > > > > > > > > apply_each([F|FS],X) -> > > > > > {S, V} = F(X), > > > > > if S = error -> > > > > > {S, V} > > > > > S = ok -> > > > > > apply_each(FS, V); > > > > > end > > > > > . > > > > > > > > > > {R, V} = apply_each([z,y,x], Arg). > > > > > if R = ok -> ... > > > > > > > > > > I have not much practice in Erlang (though I have some practice in Prolog), so this might not be 100 % correct. > > > > > > > > > > Cheers, > > > > > Jakob > > > > > > > > > > Am Mittwoch, 25. Januar 2012 13:16 CET, Joe Armstrong schrieb: > > > > > > > > > > > I think you are asking the wrong question. If a function returns > > > > > > {ok,Val} | {error,Reason} > > > > > > then I think to myself "the caller of this function expects things to > > > > > > go wrong and is > > > > > > committed to handling *both* return values. > > > > > > > > > > > > So they would *never* write w(x(y(z(....))) because this does not cater for both > > > > > > return values. > > > > > > > > > > > > With the "let it crash" philosophy one would make w,x,y, .. return a > > > > > > value OR call exit(...). > > > > > > With this convention things do nest in the "happy" case without using > > > > > > a staircase. > > > > > > > > > > > > At the top level try or catch is used to catch the error. > > > > > > > > > > > > Alternatively you could say > > > > > > > > > > > > ok({ok,X}) -> X; > > > > > > ok{error,E}) -> exit(E). > > > > > > > > > > > > and then > > > > > > > > > > > > w(ok(x(ok(y(ok(z(X)))))) > > > > > > > > > > > > Not pretty but it does the job > > > > > > > > > > > > /Joe > > > > > > > > > > > > > > > > > > On Tue, Jan 24, 2012 at 8:31 PM, Reynaldo Baquerizo > > > > > > wrote: > > > > > > > > > > > > > > A friend of mine asked: > > > > > > > > > > > > > > ## > > > > > > > If you have functions that return {ok, Result} | {error, Reason} > > > > > > > how do you chained them? So that you have: > > > > > > > > > > > > > > w(x(y(z(...)))) > > > > > > > > > > > > > > without building a staircasing. Something that would be done in Haskell > > > > > > > with monads. > > > > > > > ## > > > > > > > > > > > > > > I would probably go for: > > > > > > > > > > > > > > x({ok, Value}) -> > > > > > > > NewValue = , > > > > > > > {ok, NewValue}; > > > > > > > x({error, Reason}) -> > > > > > > > {error, Reason}. > > > > > > > > > > > > > > in each function > > > > > > > > > > > > > > which brings me other question, when do you tag return values? > > > > > > > > > > > > > > I tend to only use tagged return values with impure functions, were an > > > > > > > error is more likely due to side effects. > > > > > > > > > > > > > > -- > > > > > > > Reynaldo > > > > > > > _______________________________________________ > > > > > > > erlang-questions mailing list > > > > > > > erlang-questions@REDACTED > > > > > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > _______________________________________________ > > > > > > erlang-questions mailing list > > > > > > erlang-questions@REDACTED > > > > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > erlang-questions mailing list > > > > > erlang-questions@REDACTED > > > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > From attila.r.nohl@REDACTED Wed Feb 1 10:17:58 2012 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Wed, 1 Feb 2012 10:17:58 +0100 Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions In-Reply-To: <6a2e-4f290080-5-6b8b4580@717786> References: <1328084077.12502.4.camel@seasc1137> <6a2e-4f290080-5-6b8b4580@717786> Message-ID: 2012/2/1, Jakob Praher : > > Thanks for your reply. > > As a counterargument F = {module,fun}, F(). works. Currently. As far as I know, it is planned to not work in OTP R16B. Even OTP R15B produces run-time warnings for this construct. From edward.yu.wang@REDACTED Wed Feb 1 10:50:13 2012 From: edward.yu.wang@REDACTED (Edward Wang) Date: Wed, 1 Feb 2012 17:50:13 +0800 Subject: [erlang-questions] Simple NAT traversal In-Reply-To: <7b4e7bc9-b97f-421d-806a-93bfaee58697@dp8g2000vbb.googlegroups.com> References: <7b4e7bc9-b97f-421d-806a-93bfaee58697@dp8g2000vbb.googlegroups.com> Message-ID: If your NAT device supports UPnP, you can ask for its external address using UPnP protocol. But there's nothing simple in it. UPnP is a horrible protocol. That said, if you do want to try this, you can check out UPnP implementation in etorrent. I did that about one year ago for opening port mapping. The related source code are (https://github.com/edwardw/etorrent/tree/master/apps/etorrent/src): etorrent_upnp_sup.erl etorrent_upnp_proto.erl etorrent_upnp_net.erl etorrent_upnp_handler.erl etorrent_upnp_entity.erl They are quite standalone and complete UPnP implementation. Take a look at how add_port_mapping is implemented: https://github.com/jlouis/etorrent/blob/master/apps/etorrent/src/etorrent_upnp_net.erl#L155 It should be easy enough to add your own get_external_address function, which is defined in following specification: http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf Regards, Edward On Wed, Feb 1, 2012 at 4:25 PM, eigenfunction wrote: > Hi everybody, > i have an erlang application running behind a nat. Now i have come to > a point where i need to know my public ip. I was thinking about > running a tiny tcp server behind the nat whose sole purpose would be > to send me my public ip. My question is this: isn't there a more > simple alternative? Heck, even if i could determine the public ip of > the NAT device without doing a "backflip" it will be enough for my > case. > Any idea? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From hynek@REDACTED Wed Feb 1 10:52:59 2012 From: hynek@REDACTED (Hynek Vychodil) Date: Wed, 1 Feb 2012 10:52:59 +0100 Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions In-Reply-To: <6a2e-4f290080-5-6b8b4580@717786> References: <1328084077.12502.4.camel@seasc1137> <6a2e-4f290080-5-6b8b4580@717786> Message-ID: Disclaimer: It is mine explanation which works for me and makes me happy. F is not designator per se but designator of variable. Erlang is dynamic strong typed language, every value in variables have it's own type. module:fun is not value and doesn't have type. {module,fun} is value and has type 2-tuple with two members of atom type. F() means call (apply) func in variable F but there is hack, that above tuple type is magically converted to func under-hood which is scheduled for removal in R16. So if you want use F() operation you have to assign proper func value to variable F first and it is `F = fun module:fun/0`. Note that M:F() is different operation with different arity and also accepts different types. It is perfect consistent for me at least and it is mine explanation why it works and doesn't surprise me. On Wed, Feb 1, 2012 at 10:05 AM, Jakob Praher wrote: > > Thanks for your reply. > > As a counterargument F = {module,fun}, F(). works. > Also in this case F is just the designator and not the function itself. > > It would be possible for instance to evaluate module:fun as {module,fun}. > > Best, > Jakob > > > > Am Mittwoch, 01. Februar 2012 09:14 CET, Bengt Kleberg schrieb: > >> Greetings, >> >> This is perhaps totally wrong but in my mind allowing >> F = module:fun, >> F(). >> >> would also mean that this is good: >> F = module:fun(, >> F). >> >> Ie, "F = module:fun" is text/syntax, not semantic. >> >> >> bengt >> >> On Wed, 2012-02-01 at 09:05 +0100, Jakob Praher wrote: >> > Hi Erlangers, >> > >> > I think people should pay attention to issues faced by experienced newcomers in exercising Erlang programming. Matz from Ruby calls a ver important design principle, the principle of least surprise. >> > >> > No matter that the following may be a syntactic surface issue, but designating function objects is neither orthogonal nor does follow the expectations of the programmer. Therefore it also makes understanding code harder. >> > >> > if I can write: >> > ? ? ?module:fun(). >> > I should be also able to write >> > ? ? ?F = module:fun, F(). >> > and not having to write >> > ? ? ?F = fun module:fun/0, F(). >> > . >> > >> > I am happy to learn why module:fun is not an expression. >> > >> > Best, >> > Jakob >> > >> > >> > Am Dienstag, 31. Januar 2012 14:07 CET, "Jakob Praher" schrieb: >> > >> > > >> > > As I tried out the code below I learned that tuples of module and function atoms evalute to functions, not atoms by themselves. >> > > If one can apply arguments to a tuple, why not to an atom if this would be denote a function in the current environment? >> > > >> > > {R, V} = apply_each([{m1,z},{m2,y},{m3,x}], Arg). >> > > if R = ok -> ... >> > > >> > > Thanks, >> > > Jakob >> > > >> > > >> > > Am Mittwoch, 25. Januar 2012 14:29 CET, "Jakob Praher" schrieb: >> > > >> > > > >> > > > One could also compose a sequence of functions much like in combinator parsing, and fail at the first event returning the error status, otherwise continue to call apply the functions to the result. >> > > > >> > > > apply_each([F|FS],X) -> >> > > > ? ? ? {S, V} = F(X), >> > > > ? ? ? if S = error ?-> >> > > > ? ? ? ? ? ? {S, V} >> > > > ? ? ? ? ?S = ok -> >> > > > ? ? ? ? ? ? apply_each(FS, V); >> > > > ? ? ? end >> > > > ? ? ? . >> > > > >> > > > {R, V} = apply_each([z,y,x], Arg). >> > > > if R = ok -> ... >> > > > >> > > > I have not much practice in Erlang (though I have some practice in Prolog), so this might not be 100 % correct. >> > > > >> > > > Cheers, >> > > > Jakob >> > > > >> > > > Am Mittwoch, 25. Januar 2012 13:16 CET, Joe Armstrong schrieb: >> > > > >> > > > > I think you are asking the wrong question. If a function returns >> > > > > {ok,Val} | {error,Reason} >> > > > > then I think to myself "the caller of this function expects things to >> > > > > go wrong and is >> > > > > committed to handling *both* return values. >> > > > > >> > > > > So they would *never* write w(x(y(z(....))) because this does not cater for both >> > > > > return values. >> > > > > >> > > > > With the "let it crash" philosophy one would make w,x,y, .. return a >> > > > > value OR call exit(...). >> > > > > With this convention things do nest in the "happy" case without using >> > > > > a staircase. >> > > > > >> > > > > At the top level try or catch is used to catch the error. >> > > > > >> > > > > Alternatively you could say >> > > > > >> > > > > ? ok({ok,X}) -> X; >> > > > > ? ok{error,E}) -> exit(E). >> > > > > >> > > > > and then >> > > > > >> > > > > ? ?w(ok(x(ok(y(ok(z(X)))))) >> > > > > >> > > > > Not pretty but it does the job >> > > > > >> > > > > /Joe >> > > > > >> > > > > >> > > > > On Tue, Jan 24, 2012 at 8:31 PM, Reynaldo Baquerizo >> > > > > wrote: >> > > > > > >> > > > > > A friend of mine asked: >> > > > > > >> > > > > > ## >> > > > > > If you have functions that return {ok, Result} | {error, Reason} >> > > > > > how do you chained them? So that you have: >> > > > > > >> > > > > > w(x(y(z(...)))) >> > > > > > >> > > > > > without building a staircasing. Something that would be done in Haskell >> > > > > > with monads. >> > > > > > ## >> > > > > > >> > > > > > I would probably go for: >> > > > > > >> > > > > > x({ok, Value}) -> >> > > > > > ?NewValue = , >> > > > > > ?{ok, NewValue}; >> > > > > > x({error, Reason}) -> >> > > > > > ?{error, Reason}. >> > > > > > >> > > > > > in each function >> > > > > > >> > > > > > which brings me other question, when do you tag return values? >> > > > > > >> > > > > > I tend to only use tagged return values with impure functions, were an >> > > > > > error is more likely due to side effects. >> > > > > > >> > > > > > -- >> > > > > > Reynaldo >> > > > > > _______________________________________________ >> > > > > > erlang-questions mailing list >> > > > > > erlang-questions@REDACTED >> > > > > > http://erlang.org/mailman/listinfo/erlang-questions >> > > > > _______________________________________________ >> > > > > erlang-questions mailing list >> > > > > erlang-questions@REDACTED >> > > > > http://erlang.org/mailman/listinfo/erlang-questions >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > _______________________________________________ >> > > > erlang-questions mailing list >> > > > erlang-questions@REDACTED >> > > > http://erlang.org/mailman/listinfo/erlang-questions >> > > >> > > >> > > >> > > >> > > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Hynek Vychodil BI consultant GoodData n?m?st? 28. ??jna 1104/17, 602 00, Brno - ?ern? Pole Office: ? +420 530 50 7704 E-mail: ?hynek@REDACTED Web: ? ? www.gooddata.com From jakob@REDACTED Wed Feb 1 11:11:28 2012 From: jakob@REDACTED (Jakob Praher) Date: Wed, 01 Feb 2012 11:11:28 +0100 Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions In-Reply-To: Message-ID: <6a2e-4f291000-d-6b8b4580@717790> Jup, I have read that the binary tuple construct is deprecated. I am just wondering what the benefits of using "fun module:fun/0" are. It is also just a designator (a reference) and has to be evaluated at runtime to get the address of the current function loaded. I can think that "fun module:fun/0" is used to be more familiar with anonymous functions. According to parse_erl.yrl atom:atom is an expression (matched by expr_800), right? expr_800 mathces "expr_900 ':' expr_max" and expr_900 matches "expr_max" expr_max matches "atomic" atomic matches "atom" function_call -> expr_800 argument_list : {call,?line('$1'),'$1',element(1, '$2')}. Best, Jakob Am Mittwoch, 01. Februar 2012 10:17 CET, Attila Rajmund Nohl schrieb: > 2012/2/1, Jakob Praher : > > > > Thanks for your reply. > > > > As a counterargument F = {module,fun}, F(). works. > > Currently. As far as I know, it is planned to not work in OTP R16B. > Even OTP R15B produces run-time warnings for this construct. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From jakob@REDACTED Wed Feb 1 11:11:34 2012 From: jakob@REDACTED (Jakob Praher) Date: Wed, 01 Feb 2012 11:11:34 +0100 Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions Message-ID: <6a2e-4f291000-f-6b8b4580@717791> Jup, I have read that the binary tuple construct is deprecated. I am just wondering what the benefits of using "fun module:fun/0" are. It is also just a designator (a reference) and has to be evaluated at runtime to get the address of the current function loaded. I can think that "fun module:fun/0" is used to be more familiar with anonymous functions. According to parse_erl.yrl atom:atom is an expression (matched by expr_800), right? expr_800 mathces "expr_900 ':' expr_max" and expr_900 matches "expr_max" expr_max matches "atomic" atomic matches "atom" function_call -> expr_800 argument_list : {call,?line('$1'),'$1',element(1, '$2')}. Best, Jakob Am Mittwoch, 01. Februar 2012 10:17 CET, Attila Rajmund Nohl schrieb: > 2012/2/1, Jakob Praher : > > > > Thanks for your reply. > > > > As a counterargument F = {module,fun}, F(). works. > > Currently. As far as I know, it is planned to not work in OTP R16B. > Even OTP R15B produces run-time warnings for this construct. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From emeka_1978@REDACTED Wed Feb 1 14:19:55 2012 From: emeka_1978@REDACTED (eigenfunction) Date: Wed, 1 Feb 2012 05:19:55 -0800 (PST) Subject: [erlang-questions] Simple NAT traversal In-Reply-To: References: <7b4e7bc9-b97f-421d-806a-93bfaee58697@dp8g2000vbb.googlegroups.com> Message-ID: Thank you for the response. But before i wade into that territory, do you think it will be easier than just writing a tcp server? Anyway, i am going to check that out. On 1 Feb., 10:50, Edward Wang wrote: > If your NAT device supports UPnP, you can ask for its external address > using UPnP protocol. But there's nothing simple in it. UPnP is a > horrible protocol. > > That said, if you do want to try this, you can check out UPnP > implementation in etorrent. I did that about one year ago for opening > port mapping. The related source code are > (https://github.com/edwardw/etorrent/tree/master/apps/etorrent/src): > > ? ? etorrent_upnp_sup.erl > ? ? etorrent_upnp_proto.erl > ? ? etorrent_upnp_net.erl > ? ? etorrent_upnp_handler.erl > ? ? etorrent_upnp_entity.erl > > They are quite standalone and complete UPnP implementation. Take a > look at how add_port_mapping is implemented: > ? ?https://github.com/jlouis/etorrent/blob/master/apps/etorrent/src/etor... > It should be easy enough to add your own get_external_address > function, which is defined in following specification: > ? ?http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf > > Regards, > Edward > > On Wed, Feb 1, 2012 at 4:25 PM, eigenfunction wrote: > > Hi everybody, > > i have an erlang application running behind a nat. Now i have come to > > a point where i need to know my public ip. I was thinking about > > running a tiny tcp server behind the nat whose sole purpose would be > > to send me my public ip. My question is this: isn't there a more > > simple alternative? Heck, even if i could determine the public ip of > > the NAT device without doing a "backflip" it will be enough for my > > case. > > Any idea? > > _______________________________________________ > > erlang-questions mailing list > > erlang-questi...@REDACTED > >http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions From iostres@REDACTED Wed Feb 1 14:34:13 2012 From: iostres@REDACTED (Ivan Ostres) Date: Wed, 1 Feb 2012 14:34:13 +0100 Subject: [erlang-questions] Simple NAT traversal In-Reply-To: References: <7b4e7bc9-b97f-421d-806a-93bfaee58697@dp8g2000vbb.googlegroups.com> Message-ID: Easiest way is to sent http GET to something like http://www.ip-adress.com/ - it's a free IP address lookup. Other simple alternative (if possible) is to add such facility to clients (if you control them). BR, Ivan On 2/1/12 2:19 PM, eigenfunction wrote: > Thank you for the response. But before i wade into that territory, > do you think it will be easier than just writing a tcp server? > Anyway, i am going to check that out. > > On 1 Feb., 10:50, Edward Wang wrote: >> If your NAT device supports UPnP, you can ask for its external address >> using UPnP protocol. But there's nothing simple in it. UPnP is a >> horrible protocol. >> >> That said, if you do want to try this, you can check out UPnP >> implementation in etorrent. I did that about one year ago for opening >> port mapping. The related source code are >> (https://github.com/edwardw/etorrent/tree/master/apps/etorrent/src): >> >> etorrent_upnp_sup.erl >> etorrent_upnp_proto.erl >> etorrent_upnp_net.erl >> etorrent_upnp_handler.erl >> etorrent_upnp_entity.erl >> >> They are quite standalone and complete UPnP implementation. Take a >> look at how add_port_mapping is implemented: >> https://github.com/jlouis/etorrent/blob/master/apps/etorrent/src/etor... >> It should be easy enough to add your own get_external_address >> function, which is defined in following specification: >> http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf >> >> Regards, >> Edward >> >> On Wed, Feb 1, 2012 at 4:25 PM, eigenfunction wrote: >>> Hi everybody, >>> i have an erlang application running behind a nat. Now i have come to >>> a point where i need to know my public ip. I was thinking about >>> running a tiny tcp server behind the nat whose sole purpose would be >>> to send me my public ip. My question is this: isn't there a more >>> simple alternative? Heck, even if i could determine the public ip of >>> the NAT device without doing a "backflip" it will be enough for my >>> case. >>> Any idea? >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questi...@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> _______________________________________________ >> erlang-questions mailing list >> erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From edward.yu.wang@REDACTED Wed Feb 1 14:37:28 2012 From: edward.yu.wang@REDACTED (Edward Wang) Date: Wed, 1 Feb 2012 21:37:28 +0800 Subject: [erlang-questions] Simple NAT traversal In-Reply-To: References: <7b4e7bc9-b97f-421d-806a-93bfaee58697@dp8g2000vbb.googlegroups.com> Message-ID: A tcp server itself is simple enough, but that's another piece of software running on a separated machine. That's a big disadvantage. On the other hand, a UPnP control point is something you can integrate into your own application, given your NAT device speaks UPnP and you want to deal with the protocol. -Edward On Wed, Feb 1, 2012 at 9:19 PM, eigenfunction wrote: > Thank you for the response. But before i wade into that territory, > do you think it will be easier than just writing a tcp server? > Anyway, i am going to check that out. > > On 1 Feb., 10:50, Edward Wang wrote: >> If your NAT device supports UPnP, you can ask for its external address >> using UPnP protocol. But there's nothing simple in it. UPnP is a >> horrible protocol. >> >> That said, if you do want to try this, you can check out UPnP >> implementation in etorrent. I did that about one year ago for opening >> port mapping. The related source code are >> (https://github.com/edwardw/etorrent/tree/master/apps/etorrent/src): >> >> ? ? etorrent_upnp_sup.erl >> ? ? etorrent_upnp_proto.erl >> ? ? etorrent_upnp_net.erl >> ? ? etorrent_upnp_handler.erl >> ? ? etorrent_upnp_entity.erl >> >> They are quite standalone and complete UPnP implementation. Take a >> look at how add_port_mapping is implemented: >> ? ?https://github.com/jlouis/etorrent/blob/master/apps/etorrent/src/etor... >> It should be easy enough to add your own get_external_address >> function, which is defined in following specification: >> ? ?http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf >> >> Regards, >> Edward >> >> On Wed, Feb 1, 2012 at 4:25 PM, eigenfunction wrote: >> > Hi everybody, >> > i have an erlang application running behind a nat. Now i have come to >> > a point where i need to know my public ip. I was thinking about >> > running a tiny tcp server behind the nat whose sole purpose would be >> > to send me my public ip. My question is this: isn't there a more >> > simple alternative? Heck, even if i could determine the public ip of >> > the NAT device without doing a "backflip" it will be enough for my >> > case. >> > Any idea? >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questi...@REDACTED >> >http://erlang.org/mailman/listinfo/erlang-questions >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From michael.santos@REDACTED Wed Feb 1 14:47:37 2012 From: michael.santos@REDACTED (Michael Santos) Date: Wed, 1 Feb 2012 08:47:37 -0500 Subject: [erlang-questions] Simple NAT traversal In-Reply-To: <7b4e7bc9-b97f-421d-806a-93bfaee58697@dp8g2000vbb.googlegroups.com> References: <7b4e7bc9-b97f-421d-806a-93bfaee58697@dp8g2000vbb.googlegroups.com> Message-ID: <20120201134736.GA20387@ecn.lan> On Wed, Feb 01, 2012 at 12:25:02AM -0800, eigenfunction wrote: > Hi everybody, > i have an erlang application running behind a nat. Now i have come to > a point where i need to know my public ip. I was thinking about > running a tiny tcp server behind the nat whose sole purpose would be > to send me my public ip. My question is this: isn't there a more > simple alternative? Heck, even if i could determine the public ip of > the NAT device without doing a "backflip" it will be enough for my > case. > Any idea? You could ask a 3rd party service: 1> inets:start(). ok. 2> URL = "http://automation.whatismyip.com/n09230945.asp". 3> {ok, {{"HTTP/1.1",200,"OK"}, _Headers, Body}} = httpc:request(URL). {ok,{{"HTTP/1.1",200,"OK"}, [{"cache-control","private"}, {"date","Wed, 01 Feb 2012 13:15:10 GMT"}, {"server","Microsoft-IIS/6.0"}, {"content-length","13"}, {"content-type","text/html"}, {"x-powered-by","ASP.NET"}, {"set-cookie", "ASPSESSIONIDQARTQQTD=DEJMEEEANLDPDNGGOJIKKFAG; path=/"}], "1.11.111.12"}} 4> inet_parse:address(Body). {ok,{1,11,111,12}} Google will show you your public IP too: http://google.com/?q=what+is+my+ip+address From jws@REDACTED Wed Feb 1 14:41:32 2012 From: jws@REDACTED (Jeff Schultz) Date: Thu, 2 Feb 2012 00:41:32 +1100 Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions In-Reply-To: <4aaf-4f28f200-3-4452b880@168192673> References: <7732-4f27e780-9-748af280@35816950> <4aaf-4f28f200-3-4452b880@168192673> Message-ID: <20120201134132.GA9846@mulga.csse.unimelb.edu.au> On Wed, Feb 01, 2012 at 09:05:10AM +0100, Jakob Praher wrote: > No matter that the following may be a syntactic surface issue, but > designating function objects is neither orthogonal nor does follow the > expectations of the programmer. Therefore it also makes understanding > code harder. > if I can write: > module:fun(). > I should be also able to write > F = module:fun, F(). > and not having to write > F = fun module:fun/0, F(). > I am happy to learn why module:fun is not an expression. If one could write F = module:fun, F(), then presumably one could also write F = module:fun, F(), F(abc) and call two different functions thereby. Nothing particularly wrong with that, though it would mean that the function actually called would need to be looked up at run time (rather than just checked for matching arity) and the call would thus be slower. Jeff Schultz From emeka_1978@REDACTED Wed Feb 1 14:54:35 2012 From: emeka_1978@REDACTED (eigenfunction) Date: Wed, 1 Feb 2012 05:54:35 -0800 (PST) Subject: [erlang-questions] Simple NAT traversal In-Reply-To: References: <7b4e7bc9-b97f-421d-806a-93bfaee58697@dp8g2000vbb.googlegroups.com> Message-ID: <1c53f1ae-aee9-4a98-b5d1-e6d5b4454405@v14g2000vbc.googlegroups.com> @Edward You are right and thank you again for your help @Michael I am in a corporate intranet, so i do not have access to the outside world and there are a couple of nats between the networks. On 1 Feb., 14:37, Edward Wang wrote: > A tcp server itself is simple enough, but that's another piece of > software running on a separated machine. That's a big disadvantage. On > the other hand, a UPnP control point is something you can integrate > into your own application, given your NAT device speaks UPnP and you > want to deal with the protocol. > > -Edward > > > > > > > > > > On Wed, Feb 1, 2012 at 9:19 PM, eigenfunction wrote: > > Thank you for the response. But before i wade into that territory, > > do you think it will be easier than just writing a tcp server? > > Anyway, i am going to check that out. > > > On 1 Feb., 10:50, Edward Wang wrote: > >> If your NAT device supports UPnP, you can ask for its external address > >> using UPnP protocol. But there's nothing simple in it. UPnP is a > >> horrible protocol. > > >> That said, if you do want to try this, you can check out UPnP > >> implementation in etorrent. I did that about one year ago for opening > >> port mapping. The related source code are > >> (https://github.com/edwardw/etorrent/tree/master/apps/etorrent/src): > > >> ? ? etorrent_upnp_sup.erl > >> ? ? etorrent_upnp_proto.erl > >> ? ? etorrent_upnp_net.erl > >> ? ? etorrent_upnp_handler.erl > >> ? ? etorrent_upnp_entity.erl > > >> They are quite standalone and complete UPnP implementation. Take a > >> look at how add_port_mapping is implemented: > >> ? ?https://github.com/jlouis/etorrent/blob/master/apps/etorrent/src/etor... > >> It should be easy enough to add your own get_external_address > >> function, which is defined in following specification: > >> ? ?http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf > > >> Regards, > >> Edward > > >> On Wed, Feb 1, 2012 at 4:25 PM, eigenfunction wrote: > >> > Hi everybody, > >> > i have an erlang application running behind a nat. Now i have come to > >> > a point where i need to know my public ip. I was thinking about > >> > running a tiny tcp server behind the nat whose sole purpose would be > >> > to send me my public ip. My question is this: isn't there a more > >> > simple alternative? Heck, even if i could determine the public ip of > >> > the NAT device without doing a "backflip" it will be enough for my > >> > case. > >> > Any idea? > >> > _______________________________________________ > >> > erlang-questions mailing list > >> > erlang-questi...@REDACTED > >> >http://erlang.org/mailman/listinfo/erlang-questions > > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > > erlang-questions mailing list > > erlang-questi...@REDACTED > >http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions From alisdairsullivan@REDACTED Wed Feb 1 15:04:31 2012 From: alisdairsullivan@REDACTED (Alisdair Sullivan) Date: Wed, 1 Feb 2012 06:04:31 -0800 Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions In-Reply-To: <4aaf-4f28f200-3-4452b880@168192673> References: <4aaf-4f28f200-3-4452b880@168192673> Message-ID: <971B2997-2319-4F98-9542-15D18D8108ED@yahoo.ca> functions in erlang are identified by their name and their arity 'F = module:fun()' is ok because the arity, 0, is implied by the arguments 'F = module:fun' is not okay because it does not refer to a specific function. you need to tell the compiler which function you wish to call. hence the 'fun module:fun/n' syntax From kaiduanx@REDACTED Wed Feb 1 15:53:52 2012 From: kaiduanx@REDACTED (Kaiduan Xie) Date: Wed, 1 Feb 2012 09:53:52 -0500 Subject: [erlang-questions] Simple NAT traversal In-Reply-To: <1c53f1ae-aee9-4a98-b5d1-e6d5b4454405@v14g2000vbc.googlegroups.com> References: <7b4e7bc9-b97f-421d-806a-93bfaee58697@dp8g2000vbb.googlegroups.com> <1c53f1ae-aee9-4a98-b5d1-e6d5b4454405@v14g2000vbc.googlegroups.com> Message-ID: First NAT/Firewall traversal is not simple :) UPnP will not work when there is a multiple layer of NATs, and definitely does not work in enterprise network. Based on the following assumptions, 1) Your server is TCP based, 2) Your server is behind NAT, 3) Your corporate NAT/Firewall only allows outbound connections to certain ports, for example, HTTP port 80 and HTTPS port 443 then you need TURN-TCP server (defined in RFC 6062), and a back-to-back TURN client/TCP client. The TURN-TCP server resides on public Internet, and back-to-back TURN client/TCP client sits in front of your TCP server behind NAT as illustrated below, TURN-TCP server | | | Public Internet | | Corporate NAT/Firewall | | back-to-back TURN client/TCP client | | Your TCP server First, back-to-back TURN client/TCP client asks TURN-TCP server on behalf of your TCP server to allocate a port on TURN-TCP server, for example, port 55478, then TURN-TCP server starts listening on port 55478. Whenever a client makes TCP connection to port 55478 on TURN-TCP server, TURN-TCP server notifies back-to-back TURN client/TCP client the pending connection, TURN client/TCP client then makes another outbound TCP connection to TURN-TCP server, and makes a TCP connection to your TCP server. The traffic is relayed by TURN-TCP server and TURN client/TCP client. With this solution, you do not need any changes on your TCP server, and this works on ANY firewall/NAT. I have built the TURN-TCP server and back-to-back TURN client/TCP client in Erlang. For more information, please contact me offline. Thanks, /Kaiduan On Wed, Feb 1, 2012 at 8:54 AM, eigenfunction wrote: > @Edward > You are right and thank you again for your help > > @Michael > I am in a corporate intranet, so i do not have access to the outside > world and there are a couple of nats between the networks. > > On 1 Feb., 14:37, Edward Wang wrote: >> A tcp server itself is simple enough, but that's another piece of >> software running on a separated machine. That's a big disadvantage. On >> the other hand, a UPnP control point is something you can integrate >> into your own application, given your NAT device speaks UPnP and you >> want to deal with the protocol. >> >> -Edward >> >> >> >> >> >> >> >> >> >> On Wed, Feb 1, 2012 at 9:19 PM, eigenfunction wrote: >> > Thank you for the response. But before i wade into that territory, >> > do you think it will be easier than just writing a tcp server? >> > Anyway, i am going to check that out. >> >> > On 1 Feb., 10:50, Edward Wang wrote: >> >> If your NAT device supports UPnP, you can ask for its external address >> >> using UPnP protocol. But there's nothing simple in it. UPnP is a >> >> horrible protocol. >> >> >> That said, if you do want to try this, you can check out UPnP >> >> implementation in etorrent. I did that about one year ago for opening >> >> port mapping. The related source code are >> >> (https://github.com/edwardw/etorrent/tree/master/apps/etorrent/src): >> >> >> ? ? etorrent_upnp_sup.erl >> >> ? ? etorrent_upnp_proto.erl >> >> ? ? etorrent_upnp_net.erl >> >> ? ? etorrent_upnp_handler.erl >> >> ? ? etorrent_upnp_entity.erl >> >> >> They are quite standalone and complete UPnP implementation. Take a >> >> look at how add_port_mapping is implemented: >> >> ? ?https://github.com/jlouis/etorrent/blob/master/apps/etorrent/src/etor... >> >> It should be easy enough to add your own get_external_address >> >> function, which is defined in following specification: >> >> ? ?http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf >> >> >> Regards, >> >> Edward >> >> >> On Wed, Feb 1, 2012 at 4:25 PM, eigenfunction wrote: >> >> > Hi everybody, >> >> > i have an erlang application running behind a nat. Now i have come to >> >> > a point where i need to know my public ip. I was thinking about >> >> > running a tiny tcp server behind the nat whose sole purpose would be >> >> > to send me my public ip. My question is this: isn't there a more >> >> > simple alternative? Heck, even if i could determine the public ip of >> >> > the NAT device without doing a "backflip" it will be enough for my >> >> > case. >> >> > Any idea? >> >> > _______________________________________________ >> >> > erlang-questions mailing list >> >> > erlang-questi...@REDACTED >> >> >http://erlang.org/mailman/listinfo/erlang-questions >> >> >> _______________________________________________ >> >> erlang-questions mailing list >> >> erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questi...@REDACTED >> >http://erlang.org/mailman/listinfo/erlang-questions >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bourinov@REDACTED Wed Feb 1 15:54:35 2012 From: bourinov@REDACTED (Max Bourinov) Date: Wed, 1 Feb 2012 17:54:35 +0300 Subject: [erlang-questions] Simple NAT traversal In-Reply-To: <1c53f1ae-aee9-4a98-b5d1-e6d5b4454405@v14g2000vbc.googlegroups.com> References: <7b4e7bc9-b97f-421d-806a-93bfaee58697@dp8g2000vbb.googlegroups.com> <1c53f1ae-aee9-4a98-b5d1-e6d5b4454405@v14g2000vbc.googlegroups.com> Message-ID: Our corporate clients use static IP for such tasks. Maybe it is possible to have static IP? Best regards, Max On Wed, Feb 1, 2012 at 4:54 PM, eigenfunction wrote: > @Edward > You are right and thank you again for your help > > @Michael > I am in a corporate intranet, so i do not have access to the outside > world and there are a couple of nats between the networks. > > On 1 Feb., 14:37, Edward Wang wrote: > > A tcp server itself is simple enough, but that's another piece of > > software running on a separated machine. That's a big disadvantage. On > > the other hand, a UPnP control point is something you can integrate > > into your own application, given your NAT device speaks UPnP and you > > want to deal with the protocol. > > > > -Edward > > > > > > > > > > > > > > > > > > > > On Wed, Feb 1, 2012 at 9:19 PM, eigenfunction > wrote: > > > Thank you for the response. But before i wade into that territory, > > > do you think it will be easier than just writing a tcp server? > > > Anyway, i am going to check that out. > > > > > On 1 Feb., 10:50, Edward Wang wrote: > > >> If your NAT device supports UPnP, you can ask for its external address > > >> using UPnP protocol. But there's nothing simple in it. UPnP is a > > >> horrible protocol. > > > > >> That said, if you do want to try this, you can check out UPnP > > >> implementation in etorrent. I did that about one year ago for opening > > >> port mapping. The related source code are > > >> (https://github.com/edwardw/etorrent/tree/master/apps/etorrent/src): > > > > >> etorrent_upnp_sup.erl > > >> etorrent_upnp_proto.erl > > >> etorrent_upnp_net.erl > > >> etorrent_upnp_handler.erl > > >> etorrent_upnp_entity.erl > > > > >> They are quite standalone and complete UPnP implementation. Take a > > >> look at how add_port_mapping is implemented: > > >> > https://github.com/jlouis/etorrent/blob/master/apps/etorrent/src/etor... > > >> It should be easy enough to add your own get_external_address > > >> function, which is defined in following specification: > > >> http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf > > > > >> Regards, > > >> Edward > > > > >> On Wed, Feb 1, 2012 at 4:25 PM, eigenfunction > wrote: > > >> > Hi everybody, > > >> > i have an erlang application running behind a nat. Now i have come > to > > >> > a point where i need to know my public ip. I was thinking about > > >> > running a tiny tcp server behind the nat whose sole purpose would be > > >> > to send me my public ip. My question is this: isn't there a more > > >> > simple alternative? Heck, even if i could determine the public ip of > > >> > the NAT device without doing a "backflip" it will be enough for my > > >> > case. > > >> > Any idea? > > >> > _______________________________________________ > > >> > erlang-questions mailing list > > >> > erlang-questi...@REDACTED > > >> >http://erlang.org/mailman/listinfo/erlang-questions > > > > >> _______________________________________________ > > >> erlang-questions mailing list > > >> erlang-questi...@REDACTED:// > erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questi...@REDACTED > > >http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questi...@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 kaiduanx@REDACTED Wed Feb 1 16:50:32 2012 From: kaiduanx@REDACTED (Kaiduan Xie) Date: Wed, 1 Feb 2012 10:50:32 -0500 Subject: [erlang-questions] smtp server In-Reply-To: <2b8d6c69-23d1-4046-8878-09d4729637a4@gi10g2000vbb.googlegroups.com> References: <2b8d6c69-23d1-4046-8878-09d4729637a4@gi10g2000vbb.googlegroups.com> Message-ID: "For instance, START_TLS is still not "easy" in erlang owing to the long, and continuing, struggle to get good TLS protocol support." Steve, do you mean the TLS support in Erlang is not good? Can you explain a bit more? I think the new SSL in Erlang is awesome compared with the old openSSL based implementation. /Kaiduan On Tue, Jan 31, 2012 at 8:21 PM, Steve Davis wrote: > I have noticed that a great number of SMTP projects fail with a > whimper. In particular, I observed that the JBoss project ran an SMTP > project for a long, long time before even barely having something > reasonable, and it's still not really "production quality". While the > underlying protocol for SMTP is straightforward, I think things run > aground owing to the teams initially underestimating the number of > rfcs and protocol extensions that you are essentially *required* to > support (especially wrt authentication etc) to have a production level > server; and also the storage issues such as the user directory and > message store. > > There's no reason it couldn't be done, of course, but there's a lot of > moving parts that need to come together to make it a real production > competitor to the venerable sendmail or servers like MS exchange. > > As far as Erlang is concerned, it's hard to see it happening until > certain requisite libraries are mature. For instance, START_TLS is > still not "easy" in erlang owing to the long, and continuing, struggle > to get good TLS protocol support. > > Assuming that does get "finished" (and there's a whole raft of crypto > work still to do), perhaps a good start towards such a goal would be > to integrate, at the very least, an LDAP client into the base > libraries... > > ok before I ramble too much, I'll leave my 2c there. > > regards, > /s > > On Jan 29, 12:56?am, Roberto Ostinelli wrote: >> dear list, >> >> are you aware of any existent production-ready SMTP server in Erlang? I've >> only found, maintained:https://github.com/Vagabond/gen_smtp >> >> thank you, >> >> r. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From jakob@REDACTED Wed Feb 1 17:29:35 2012 From: jakob@REDACTED (Jakob Praher) Date: Wed, 01 Feb 2012 17:29:35 +0100 Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions In-Reply-To: <971B2997-2319-4F98-9542-15D18D8108ED@yahoo.ca> Message-ID: <6a2e-4f296880-13-6b8b4580@717793> Am Mittwoch, 01. Februar 2012 15:04 CET, Alisdair Sullivan schrieb: > functions in erlang are identified by their name and their arity > > 'F = module:fun()' is ok because the arity, 0, is implied by the arguments > > 'F = module:fun' is not okay because it does not refer to a specific function. you need to tell the compiler which function you wish to call. hence the 'fun module:fun/n' syntax IMHO it depends what one is trying to achieve. From an operational point of view I am fine with having a "function reference" as something that can be called if applied with concrete arguments. Hence I do not require a funciton object in the sense that it represents the function itself. If one wants to make sure that the right function is targeted one could always write it like: "F = module:fun/N", which is not something I am thinking of. With the exception of currying, where the arity of the function arguments vs the actual arguments differs, it suffices to just apply the actual arguments to the matching function. E.g. map([],_) -> []; map([X|Rest], F) -> [F(X) | map(Rest, F)]. > map([1,2,3], math:square). [1,4,9] This is a more lazy / symbolic usage of functions. Best, Jakob > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From comptekki@REDACTED Wed Feb 1 17:49:45 2012 From: comptekki@REDACTED (Wes James) Date: Wed, 1 Feb 2012 09:49:45 -0700 Subject: [erlang-questions] XML diff In-Reply-To: References: Message-ID: On Tue, Jan 31, 2012 at 2:45 PM, Roberto Ostinelli wrote: > Dear list, > > I was wandering if there is some available work done in generating XML files > diff, obviously in Erlang but this is a broader question. Are you going to have trivial xml files so that a simple line comparison would work? -module(spxml). -export([p/0]). p() -> {ok,F1}=file:open("f1.xml",read), {ok,F2}=file:open("f2.xml",read), p2(F1,F2,1). p2(F1,F2,Acc) -> F1_line=file:read_line(F1), F2_line=file:read_line(F2), case F1_line of eof -> []; _ -> {ok,Res1}=F1_line, {ok,Res2}=F2_line, case Res1 =:= Res2 of true -> [{ok, same, Acc}|p2(F1,F2,Acc+1)]; false -> [{ok, diff, Acc}|p2(F1,F2,Acc+1)] end end. If not you, working with some of these ideas might: http://erlang.2086793.n4.nabble.com/Compare-XML-string-td2268027.html Regarding read_line, its odd that it returns a tuple until eof is reached. Shouldn't it return {ok, eof}? -wes From jared.nance@REDACTED Wed Feb 1 18:33:34 2012 From: jared.nance@REDACTED (Jared Kofron) Date: Wed, 1 Feb 2012 09:33:34 -0800 Subject: [erlang-questions] Simple NAT traversal In-Reply-To: References: <7b4e7bc9-b97f-421d-806a-93bfaee58697@dp8g2000vbb.googlegroups.com> <1c53f1ae-aee9-4a98-b5d1-e6d5b4454405@v14g2000vbc.googlegroups.com> Message-ID: Some switches/routers also support SNMP interrogation of public IP address. I take advantage of this at home to keep track of my own IP. On Feb 1, 2012, at 6:54 AM, Max Bourinov wrote: > Our corporate clients use static IP for such tasks. Maybe it is possible to have static IP? > > Best regards, > Max > > > > > On Wed, Feb 1, 2012 at 4:54 PM, eigenfunction wrote: > @Edward > You are right and thank you again for your help > > @Michael > I am in a corporate intranet, so i do not have access to the outside > world and there are a couple of nats between the networks. > > On 1 Feb., 14:37, Edward Wang wrote: > > A tcp server itself is simple enough, but that's another piece of > > software running on a separated machine. That's a big disadvantage. On > > the other hand, a UPnP control point is something you can integrate > > into your own application, given your NAT device speaks UPnP and you > > want to deal with the protocol. > > > > -Edward > > > > > > > > > > > > > > > > > > > > On Wed, Feb 1, 2012 at 9:19 PM, eigenfunction wrote: > > > Thank you for the response. But before i wade into that territory, > > > do you think it will be easier than just writing a tcp server? > > > Anyway, i am going to check that out. > > > > > On 1 Feb., 10:50, Edward Wang wrote: > > >> If your NAT device supports UPnP, you can ask for its external address > > >> using UPnP protocol. But there's nothing simple in it. UPnP is a > > >> horrible protocol. > > > > >> That said, if you do want to try this, you can check out UPnP > > >> implementation in etorrent. I did that about one year ago for opening > > >> port mapping. The related source code are > > >> (https://github.com/edwardw/etorrent/tree/master/apps/etorrent/src): > > > > >> etorrent_upnp_sup.erl > > >> etorrent_upnp_proto.erl > > >> etorrent_upnp_net.erl > > >> etorrent_upnp_handler.erl > > >> etorrent_upnp_entity.erl > > > > >> They are quite standalone and complete UPnP implementation. Take a > > >> look at how add_port_mapping is implemented: > > >> https://github.com/jlouis/etorrent/blob/master/apps/etorrent/src/etor... > > >> It should be easy enough to add your own get_external_address > > >> function, which is defined in following specification: > > >> http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf > > > > >> Regards, > > >> Edward > > > > >> On Wed, Feb 1, 2012 at 4:25 PM, eigenfunction wrote: > > >> > Hi everybody, > > >> > i have an erlang application running behind a nat. Now i have come to > > >> > a point where i need to know my public ip. I was thinking about > > >> > running a tiny tcp server behind the nat whose sole purpose would be > > >> > to send me my public ip. My question is this: isn't there a more > > >> > simple alternative? Heck, even if i could determine the public ip of > > >> > the NAT device without doing a "backflip" it will be enough for my > > >> > case. > > >> > Any idea? > > >> > _______________________________________________ > > >> > erlang-questions mailing list > > >> > erlang-questi...@REDACTED > > >> >http://erlang.org/mailman/listinfo/erlang-questions > > > > >> _______________________________________________ > > >> erlang-questions mailing list > > >> erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questi...@REDACTED > > >http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questi...@REDACTED://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 emeka_1978@REDACTED Wed Feb 1 19:48:25 2012 From: emeka_1978@REDACTED (eigenfunction) Date: Wed, 1 Feb 2012 10:48:25 -0800 (PST) Subject: [erlang-questions] Simple NAT traversal In-Reply-To: References: <7b4e7bc9-b97f-421d-806a-93bfaee58697@dp8g2000vbb.googlegroups.com> <1c53f1ae-aee9-4a98-b5d1-e6d5b4454405@v14g2000vbc.googlegroups.com> Message-ID: <24f4d037-d579-4356-a0a5-93f01e1bca40@r10g2000yqi.googlegroups.com> Our NATs are dynamic alas :-( On Feb 1, 3:54?pm, Max Bourinov wrote: > Our corporate clients use static IP for such tasks. Maybe it is possible to > have static IP? > > Best regards, > Max > > > > > > > > On Wed, Feb 1, 2012 at 4:54 PM, eigenfunction wrote: > > @Edward > > You are right and thank you again for your help > > > @Michael > > I am in a corporate intranet, so i do not have access to the outside > > world and there are a couple of nats between the networks. > > > On 1 Feb., 14:37, Edward Wang wrote: > > > A tcp server itself is simple enough, but that's another piece of > > > software running on a separated machine. That's a big disadvantage. On > > > the other hand, a UPnP control point is something you can integrate > > > into your own application, given your NAT device speaks UPnP and you > > > want to deal with the protocol. > > > > -Edward > > > > On Wed, Feb 1, 2012 at 9:19 PM, eigenfunction > > wrote: > > > > Thank you for the response. But before i wade into that territory, > > > > do you think it will be easier than just writing a tcp server? > > > > Anyway, i am going to check that out. > > > > > On 1 Feb., 10:50, Edward Wang wrote: > > > >> If your NAT device supports UPnP, you can ask for its external address > > > >> using UPnP protocol. But there's nothing simple in it. UPnP is a > > > >> horrible protocol. > > > > >> That said, if you do want to try this, you can check out UPnP > > > >> implementation in etorrent. I did that about one year ago for opening > > > >> port mapping. The related source code are > > > >> (https://github.com/edwardw/etorrent/tree/master/apps/etorrent/src): > > > > >> ? ? etorrent_upnp_sup.erl > > > >> ? ? etorrent_upnp_proto.erl > > > >> ? ? etorrent_upnp_net.erl > > > >> ? ? etorrent_upnp_handler.erl > > > >> ? ? etorrent_upnp_entity.erl > > > > >> They are quite standalone and complete UPnP implementation. Take a > > > >> look at how add_port_mapping is implemented: > > >https://github.com/jlouis/etorrent/blob/master/apps/etorrent/src/etor... > > > >> It should be easy enough to add your own get_external_address > > > >> function, which is defined in following specification: > > > >> ? ?http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf > > > > >> Regards, > > > >> Edward > > > > >> On Wed, Feb 1, 2012 at 4:25 PM, eigenfunction > > wrote: > > > >> > Hi everybody, > > > >> > i have an erlang application running behind a nat. Now i have come > > to > > > >> > a point where i need to know my public ip. I was thinking about > > > >> > running a tiny tcp server behind the nat whose sole purpose would be > > > >> > to send me my public ip. My question is this: isn't there a more > > > >> > simple alternative? Heck, even if i could determine the public ip of > > > >> > the NAT device without doing a "backflip" it will be enough for my > > > >> > case. > > > >> > Any idea? > > > >> > _______________________________________________ > > > >> > erlang-questions mailing list > > > >> > erlang-questi...@REDACTED > > > >> >http://erlang.org/mailman/listinfo/erlang-questions > > > > >> _______________________________________________ > > > >> erlang-questions mailing list > > > >> erlang-questi...@REDACTED:// > > erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > > > > erlang-questions mailing list > > > > erlang-questi...@REDACTED > > > >http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questi...@REDACTED:// > > erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > > erlang-questions mailing list > > erlang-questi...@REDACTED > >http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions From dmkolesnikov@REDACTED Wed Feb 1 19:53:31 2012 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Wed, 1 Feb 2012 20:53:31 +0200 Subject: [erlang-questions] XML diff In-Reply-To: References: Message-ID: Hello, even with trivial XML it would be messy, you have to supress white spaces, then take into account order of attributes and child elements, etc. The simples and reliable way to diff would be a construction of hash tree and then do a diff from top to down. - Dmitry On Feb 1, 2012, at 6:49 PM, Wes James wrote: > On Tue, Jan 31, 2012 at 2:45 PM, Roberto Ostinelli wrote: >> Dear list, >> >> I was wandering if there is some available work done in generating XML files >> diff, obviously in Erlang but this is a broader question. > > > Are you going to have trivial xml files so that a simple line > comparison would work? > > -module(spxml). > > -export([p/0]). > > p() -> > {ok,F1}=file:open("f1.xml",read), > {ok,F2}=file:open("f2.xml",read), > p2(F1,F2,1). > > p2(F1,F2,Acc) -> > F1_line=file:read_line(F1), > F2_line=file:read_line(F2), > case F1_line of > eof -> []; > _ -> > {ok,Res1}=F1_line, > {ok,Res2}=F2_line, > case Res1 =:= Res2 of > true -> [{ok, same, Acc}|p2(F1,F2,Acc+1)]; > false -> [{ok, diff, Acc}|p2(F1,F2,Acc+1)] > end > end. > > If not you, working with some of these ideas might: > > http://erlang.2086793.n4.nabble.com/Compare-XML-string-td2268027.html > > Regarding read_line, its odd that it returns a tuple until eof is > reached. Shouldn't it return {ok, eof}? > > -wes > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From iostres@REDACTED Wed Feb 1 20:37:29 2012 From: iostres@REDACTED (Ivan Ostres) Date: Wed, 1 Feb 2012 20:37:29 +0100 Subject: [erlang-questions] Simple NAT traversal In-Reply-To: <24f4d037-d579-4356-a0a5-93f01e1bca40@r10g2000yqi.googlegroups.com> References: <7b4e7bc9-b97f-421d-806a-93bfaee58697@dp8g2000vbb.googlegroups.com> <1c53f1ae-aee9-4a98-b5d1-e6d5b4454405@v14g2000vbc.googlegroups.com> <24f4d037-d579-4356-a0a5-93f01e1bca40@r10g2000yqi.googlegroups.com> Message-ID: Either your network is badly designed or you are doing something you really shouldn't ;-). On 2/1/12 7:48 PM, eigenfunction wrote: > Our NATs are dynamic alas :-( > > On Feb 1, 3:54 pm, Max Bourinov wrote: >> Our corporate clients use static IP for such tasks. Maybe it is possible to >> have static IP? >> >> Best regards, >> Max >> >> >> >> >> >> >> >> On Wed, Feb 1, 2012 at 4:54 PM, eigenfunction wrote: >>> @Edward >>> You are right and thank you again for your help >>> @Michael >>> I am in a corporate intranet, so i do not have access to the outside >>> world and there are a couple of nats between the networks. >>> On 1 Feb., 14:37, Edward Wang wrote: >>>> A tcp server itself is simple enough, but that's another piece of >>>> software running on a separated machine. That's a big disadvantage. On >>>> the other hand, a UPnP control point is something you can integrate >>>> into your own application, given your NAT device speaks UPnP and you >>>> want to deal with the protocol. >>>> -Edward >>>> On Wed, Feb 1, 2012 at 9:19 PM, eigenfunction >>> wrote: >>>>> Thank you for the response. But before i wade into that territory, >>>>> do you think it will be easier than just writing a tcp server? >>>>> Anyway, i am going to check that out. >>>>> On 1 Feb., 10:50, Edward Wang wrote: >>>>>> If your NAT device supports UPnP, you can ask for its external address >>>>>> using UPnP protocol. But there's nothing simple in it. UPnP is a >>>>>> horrible protocol. >>>>>> That said, if you do want to try this, you can check out UPnP >>>>>> implementation in etorrent. I did that about one year ago for opening >>>>>> port mapping. The related source code are >>>>>> (https://github.com/edwardw/etorrent/tree/master/apps/etorrent/src): >>>>>> etorrent_upnp_sup.erl >>>>>> etorrent_upnp_proto.erl >>>>>> etorrent_upnp_net.erl >>>>>> etorrent_upnp_handler.erl >>>>>> etorrent_upnp_entity.erl >>>>>> They are quite standalone and complete UPnP implementation. Take a >>>>>> look at how add_port_mapping is implemented: >>> https://github.com/jlouis/etorrent/blob/master/apps/etorrent/src/etor... >>>>>> It should be easy enough to add your own get_external_address >>>>>> function, which is defined in following specification: >>>>>> http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf >>>>>> Regards, >>>>>> Edward >>>>>> On Wed, Feb 1, 2012 at 4:25 PM, eigenfunction >>> wrote: >>>>>>> Hi everybody, >>>>>>> i have an erlang application running behind a nat. Now i have come >>> to >>>>>>> a point where i need to know my public ip. I was thinking about >>>>>>> running a tiny tcp server behind the nat whose sole purpose would be >>>>>>> to send me my public ip. My question is this: isn't there a more >>>>>>> simple alternative? Heck, even if i could determine the public ip of >>>>>>> the NAT device without doing a "backflip" it will be enough for my >>>>>>> case. >>>>>>> Any idea? >>>>>>> _______________________________________________ >>>>>>> erlang-questions mailing list >>>>>>> erlang-questi...@REDACTED >>>>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>>> _______________________________________________ >>>>>> erlang-questions mailing list >>>>>> erlang-questi...@REDACTED:// >>> erlang.org/mailman/listinfo/erlang-questions >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questi...@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questi...@REDACTED:// >>> erlang.org/mailman/listinfo/erlang-questions >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questi...@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From watson.timothy@REDACTED Wed Feb 1 21:37:37 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Wed, 1 Feb 2012 20:37:37 +0000 Subject: [erlang-questions] [ANN] Annotations 0.0.2 Message-ID: Still in a very early state, https:://github.com/hyperthunk/annotations now supports generating additional functions as well as instrumenting existing (i.e., annotated) ones with before/after/around. As an example of how to use this, I've written up a sample application that can be used to generate tedious/boilerplate wrapper functions: https://github.com/hyperthunk/delegate. A typical use of delegate is to remove the need to hand code the named 'wrapper' functions for this AST builder that produces a generic representation of applying a 'binary operator': -delegate([ %% pass the generated/target function name %% in front of the input arguments {args, ['$T', '$I']}, %% let the generated function(s) have a different arity {arity, 2}, %% generate functions with/for each of these names... {delegate, [ "eq", "gt", "gteq", "lt", "lteq", "like", "contains", "starts_with", "ends_with", "matches", "path_exists" ]}]). binop(Op, Axis, {{_,_,_}, _}=Literal) -> binop(Op, Axis, {literal, Literal}); binop(Op, Axis, Literal) when is_integer(Literal) orelse is_float(Literal) orelse is_list(Literal) orelse is_record(Literal, semver) -> binop(Op, Axis, {literal, Literal}); binop(Op, Axis, {literal, _}=Literal) -> {Axis, {operator, Op}, Literal}. None of this would be possible without the awesome parse_trans library, so a big thank you is due to Ulf for that really killer tool! Roadmap for 0.0.3 is mainly runtime module/code changes via parse_trans_mod. -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed Feb 1 21:39:02 2012 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Wed, 01 Feb 2012 21:39:02 +0100 Subject: [erlang-questions] Paris Drinkup February 15th at 7pm Message-ID: <4F29A2E6.20602@ninenines.eu> Hello! Just a heads up if anyone happens to be in Paris on that day, French speaker or otherwise. Benoit Chesneau and myself are organizing a drinkup on wednesday, february 15th at 7pm in a yet-to-be-determined bar in Paris. It is a purely informal meetup to meet people and discuss with a drink. If you are interested you can either subscribe to the Erlang Paris mailing list[1] where all future drinkups will be announced and say so, or simply reply to this email and I'll make sure to include you when posting updates about the drinkup! Thanks for your interest. [1] https://groups.google.com/group/erlang-paris -- Lo?c Hoguin Erlang Cowboy Nine Nines From mononcqc@REDACTED Wed Feb 1 22:00:25 2012 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 1 Feb 2012 16:00:25 -0500 Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions In-Reply-To: <6a2e-4f296880-13-6b8b4580@717793> References: <971B2997-2319-4F98-9542-15D18D8108ED@yahoo.ca> <6a2e-4f296880-13-6b8b4580@717793> Message-ID: The following concepts are functions or things that can be interpreted as functions: 1. fun([Args]) -> ... end (declared in the shell / eval'd) 2. fun([Args]) -> ... end (compiled) 3. fun Name/Arity 4. fun Mod:Name/Arity 5. {Mod, Fun}(Args) (to be deprecated) 6. ModAsVariable:FunAsVariable() 7. FunAsVariable() 8. apply(Fun, Args) 9. apply(Mod, Fun, Args) In the case of the two first ones, the scope of the function depends on where it's coming from and so I can expect the call to be local. For the 3rd and 4th ones, there is a very clear distinction between a local call and a fully qualified call. The module name is obvious, and the arity lets me know I'm pointing to a known function, and not just a name. For the 5th and 6th ones, there is no doubt about whether I'm declaring something to be a local or a fully qualified call. It's going to be the latter. For the 7th case, we have a funny possibility. It looks like what we're doing is defining a local call, but the result is entirely depending on whether I'm passing in {Mod,Fun}, a fun, fun Name/Arity, fun Mod:Name/arity, etc. This is an entirely transparent way to make any kind of call, as long as we know how many arguments we have. The 8th case is the same as the 7th one, except the number of arguments is unknown and variable. The 9th case is obviously a fully qualified call, but the number of arguments isn't known first hand. With this being said, where does Mod:Fun as a syntax stand? I don't think it would be semantically outrageous given it fits the use cases 7 and 8 quite well. I still don't think it could be the best thing to do, though. Why? there are a two big issues I see with it: I don't think it shows a clear gain in readability or maintainability. All the cases above have different uses, different purposes. At most, Mod:Fun is a shortcut to save typing time, without clear maintainability advantages or even learning advantages. It doesn't do anything different than any of the many forms that already exist. It's more syntax for a use case we already have a solution for. Secondly, it can't have a counterpart when it comes to local calls. I can't just pass 'atom' and expect to be passing a local function reference -- otherwise we'd never know if what we're passing (whether it's an atom or a function). This is the biggest problem to me. We'd create a short form to avoid fun Mod:Name/N, but we have no equivalent for fun Name/N. This is a gaping hole in what can be done with the language and can be even more confusing, IMO. A good solution to simplify the syntax should do it well, not in an incomplete way that creates more inconsistencies in the language. I think adding it would break more programmer expectations than not having it. On Wed, Feb 1, 2012 at 11:29 AM, Jakob Praher wrote: Am Mittwoch, 01. Februar 2012 15:04 CET, Alisdair Sullivan < > alisdairsullivan@REDACTED> schrieb: > > > functions in erlang are identified by their name and their arity > > > > 'F = module:fun()' is ok because the arity, 0, is implied by the > arguments > > > > 'F = module:fun' is not okay because it does not refer to a specific > function. you need to tell the compiler which function you wish to call. > hence the 'fun module:fun/n' syntax > > > IMHO it depends what one is trying to achieve. From an operational point > of view I am fine with having a "function reference" as something that can > be called if applied with concrete arguments. Hence I do not require a > funciton object in the sense that it represents the function itself. > > If one wants to make sure that the right function is targeted one could > always write it like: "F = module:fun/N", which is not something I am > thinking of. > > With the exception of currying, where the arity of the function arguments > vs the actual arguments differs, it suffices to just apply the actual > arguments to the matching function. > > E.g. > > map([],_) -> []; > map([X|Rest], F) -> [F(X) | map(Rest, F)]. > > > map([1,2,3], math:square). > [1,4,9] > > This is a more lazy / symbolic usage of functions. > > Best, > Jakob > > > _______________________________________________ > > erlang-questions mailing list > > 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 emeka_1978@REDACTED Wed Feb 1 22:10:12 2012 From: emeka_1978@REDACTED (eigenfunction) Date: Wed, 1 Feb 2012 13:10:12 -0800 (PST) Subject: [erlang-questions] Simple NAT traversal In-Reply-To: References: <7b4e7bc9-b97f-421d-806a-93bfaee58697@dp8g2000vbb.googlegroups.com> <1c53f1ae-aee9-4a98-b5d1-e6d5b4454405@v14g2000vbc.googlegroups.com> <24f4d037-d579-4356-a0a5-93f01e1bca40@r10g2000yqi.googlegroups.com> Message-ID: <79c188e3-1922-453c-932a-cdd14d8f0498@a15g2000yqf.googlegroups.com> Typical big co network with security concerns at every turn :-) On Feb 1, 8:37?pm, Ivan Ostres wrote: > Either your network is badly designed or you are doing something you > really shouldn't ;-). > > On 2/1/12 7:48 PM, eigenfunction wrote: > > > > > > > > > > > Our NATs are dynamic alas :-( > > > On Feb 1, 3:54 pm, Max Bourinov ?wrote: > >> Our corporate clients use static IP for such tasks. Maybe it is possible to > >> have static IP? > > >> Best regards, > >> Max > > >> On Wed, Feb 1, 2012 at 4:54 PM, eigenfunction ?wrote: > >>> @Edward > >>> You are right and thank you again for your help > >>> @Michael > >>> I am in a corporate intranet, so i do not have access to the outside > >>> world and there are a couple of nats between the networks. > >>> On 1 Feb., 14:37, Edward Wang ?wrote: > >>>> A tcp server itself is simple enough, but that's another piece of > >>>> software running on a separated machine. That's a big disadvantage. On > >>>> the other hand, a UPnP control point is something you can integrate > >>>> into your own application, given your NAT device speaks UPnP and you > >>>> want to deal with the protocol. > >>>> -Edward > >>>> On Wed, Feb 1, 2012 at 9:19 PM, eigenfunction > >>> wrote: > >>>>> Thank you for the response. But before i wade into that territory, > >>>>> do you think it will be easier than just writing a tcp server? > >>>>> Anyway, i am going to check that out. > >>>>> On 1 Feb., 10:50, Edward Wang ?wrote: > >>>>>> If your NAT device supports UPnP, you can ask for its external address > >>>>>> using UPnP protocol. But there's nothing simple in it. UPnP is a > >>>>>> horrible protocol. > >>>>>> That said, if you do want to try this, you can check out UPnP > >>>>>> implementation in etorrent. I did that about one year ago for opening > >>>>>> port mapping. The related source code are > >>>>>> (https://github.com/edwardw/etorrent/tree/master/apps/etorrent/src): > >>>>>> ? ? ?etorrent_upnp_sup.erl > >>>>>> ? ? ?etorrent_upnp_proto.erl > >>>>>> ? ? ?etorrent_upnp_net.erl > >>>>>> ? ? ?etorrent_upnp_handler.erl > >>>>>> ? ? ?etorrent_upnp_entity.erl > >>>>>> They are quite standalone and complete UPnP implementation. Take a > >>>>>> look at how add_port_mapping is implemented: > >>>https://github.com/jlouis/etorrent/blob/master/apps/etorrent/src/etor... > >>>>>> It should be easy enough to add your own get_external_address > >>>>>> function, which is defined in following specification: > >>>>>> ? ?http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf > >>>>>> Regards, > >>>>>> Edward > >>>>>> On Wed, Feb 1, 2012 at 4:25 PM, eigenfunction > >>> wrote: > >>>>>>> Hi everybody, > >>>>>>> i have an erlang application running behind a nat. Now i have come > >>> to > >>>>>>> a point where i need to know my public ip. I was thinking about > >>>>>>> running a tiny tcp server behind the nat whose sole purpose would be > >>>>>>> to send me my public ip. My question is this: isn't there a more > >>>>>>> simple alternative? Heck, even if i could determine the public ip of > >>>>>>> the NAT device without doing a "backflip" it will be enough for my > >>>>>>> case. > >>>>>>> Any idea? > >>>>>>> _______________________________________________ > >>>>>>> erlang-questions mailing list > >>>>>>> erlang-questi...@REDACTED > >>>>>>>http://erlang.org/mailman/listinfo/erlang-questions > >>>>>> _______________________________________________ > >>>>>> erlang-questions mailing list > >>>>>> erlang-questi...@REDACTED:// > >>> erlang.org/mailman/listinfo/erlang-questions > >>>>> _______________________________________________ > >>>>> erlang-questions mailing list > >>>>> erlang-questi...@REDACTED > >>>>>http://erlang.org/mailman/listinfo/erlang-questions > >>>> _______________________________________________ > >>>> erlang-questions mailing list > >>>> erlang-questi...@REDACTED:// > >>> erlang.org/mailman/listinfo/erlang-questions > >>> _______________________________________________ > >>> erlang-questions mailing list > >>> erlang-questi...@REDACTED > >>>http://erlang.org/mailman/listinfo/erlang-questions > > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > > erlang-questions mailing list > > erlang-questi...@REDACTED > >http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions From robert.virding@REDACTED Wed Feb 1 22:47:16 2012 From: robert.virding@REDACTED (Robert Virding) Date: Wed, 01 Feb 2012 21:47:16 -0000 (GMT) Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions In-Reply-To: <6a2e-4f296880-13-6b8b4580@717793> Message-ID: The problem with your reasoning is that your "functional reference" may refer to many functions. Functions with the same name and a different arity are DIFFERENT functions, one reference cannot refer to them. It is like expecting the "reference" F = module:big also to call not just the function 'big' but also the function 'big_name' because they have the same prefix. They ARE different functions which just happen to have the same name. Robert ----- Original Message ----- > > Am Mittwoch, 01. Februar 2012 15:04 CET, Alisdair Sullivan > schrieb: > > > functions in erlang are identified by their name and their arity > > > > 'F = module:fun()' is ok because the arity, 0, is implied by the > > arguments > > > > 'F = module:fun' is not okay because it does not refer to a > > specific function. you need to tell the compiler which function > > you wish to call. hence the 'fun module:fun/n' syntax > > IMHO it depends what one is trying to achieve. From an operational > point of view I am fine with having a "function reference" as > something that can be called if applied with concrete arguments. > Hence I do not require a funciton object in the sense that it > represents the function itself. > > If one wants to make sure that the right function is targeted one > could always write it like: "F = module:fun/N", which is not > something I am thinking of. > > With the exception of currying, where the arity of the function > arguments vs the actual arguments differs, it suffices to just apply > the actual arguments to the matching function. > > E.g. > > map([],_) -> []; > map([X|Rest], F) -> [F(X) | map(Rest, F)]. > > > map([1,2,3], math:square). > [1,4,9] > > This is a more lazy / symbolic usage of functions. > > Best, > Jakob > > > _______________________________________________ > > erlang-questions mailing list > > 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 jakob@REDACTED Thu Feb 2 00:08:12 2012 From: jakob@REDACTED (Jakob Praher) Date: Thu, 02 Feb 2012 00:08:12 +0100 Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions In-Reply-To: References: Message-ID: <4F29C5DC.6090003@praher.info> Am 01.02.12 22:47, schrieb Robert Virding: > The problem with your reasoning is that your "functional reference" may refer to many functions. Functions with the same name and a different arity are DIFFERENT functions, one reference cannot refer to them. It is like expecting the "reference" F = module:big also to call not just the function 'big' but also the function 'big_name' because they have the same prefix. They ARE different functions which just happen to have the same name. I understand this fact. But alltough the reference does not designate one function, it deterministically designates the intended function: the function that can be applied to the actual parameters (see below for a statement on matching against actual argument values as well). Therefore to my taste it feels redundant. E.g. I know I am calling a function with one parameter, still I have to pass this information to the references as well as to the call. Type inference can easily detect the arity, e.g. the second argument passed to the function map in the example below has to be a unary function, by the usage of F(X). In such a case type checking is able to detect errors early - e.g. that a unary function square is exported from the module math, when passing math:square as the second argument to map. In the sense that Erlang can also have different function bodies dependently defined by pattern matching on the actual argument values beeing passed, the arity is anyway not the only determiner of the actual target body of expressions beeing called (even if this is internally represented as a single function, conceptionally it is not). But here I guess everybody would find it tedious/strange, if one has to refer to a function by the signature of its arguments. For the future I think even identifying the function to call in case of currying (if it would be already possible) is mostly deterministic by knowing that the result value having to be of a certain structure as well. Anyway the problem of currying also applies to the current function call expression as well (e.g. module:fun(X). could be interpreted as calling the unary funciton fun resulting or also currying on the binary function fun and so on ...). Best, Jakob > > Robert > > ----- Original Message ----- >> Am Mittwoch, 01. Februar 2012 15:04 CET, Alisdair Sullivan >> schrieb: >> >>> functions in erlang are identified by their name and their arity >>> >>> 'F = module:fun()' is ok because the arity, 0, is implied by the >>> arguments >>> >>> 'F = module:fun' is not okay because it does not refer to a >>> specific function. you need to tell the compiler which function >>> you wish to call. hence the 'fun module:fun/n' syntax >> IMHO it depends what one is trying to achieve. From an operational >> point of view I am fine with having a "function reference" as >> something that can be called if applied with concrete arguments. >> Hence I do not require a funciton object in the sense that it >> represents the function itself. >> >> If one wants to make sure that the right function is targeted one >> could always write it like: "F = module:fun/N", which is not >> something I am thinking of. >> >> With the exception of currying, where the arity of the function >> arguments vs the actual arguments differs, it suffices to just apply >> the actual arguments to the matching function. >> >> E.g. >> >> map([],_) -> []; >> map([X|Rest], F) -> [F(X) | map(Rest, F)]. >> >>> map([1,2,3], math:square). >> [1,4,9] >> >> This is a more lazy / symbolic usage of functions. >> >> Best, >> Jakob >> >>> _______________________________________________ >>> erlang-questions mailing list >>> 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 steven.charles.davis@REDACTED Thu Feb 2 03:52:52 2012 From: steven.charles.davis@REDACTED (Steve Davis) Date: Wed, 01 Feb 2012 20:52:52 -0600 Subject: [erlang-questions] smtp server In-Reply-To: References: <2b8d6c69-23d1-4046-8878-09d4729637a4@gi10g2000vbb.googlegroups.com> Message-ID: <4F29FA84.3080603@gmail.com> Hi Kaiduan, For sure, with "old ssl", I could never get a reliable socket upgrade at all. Comparatively, new ssl is indeed far more advanced than old ssl. Nonetheless, for the qualification of "awesome" in a platform comparison (i.e. with NOT erts version X versus erts version Y) there's a massive task that perhaps you can't appreciate without reviewing the following document... http://www.iana.org/assignments/tls-parameters/tls-parameters.xml ...and test suite referenced here... http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html There's also connection cost/memory overhead to take into account, and possibly process spawning cost under high load (which I have not measured but "wonder about")... but I digress. I think the team at Ericsson that we rely on have made incredible strides with tls, but the overall task is undeniably huge and will take quite some time yet to settle into a mature implementation. Fortunately, the motivation to solve these issues appears to be higher now than it was a couple of years ago, and will definitely benefit all (also note that some of the earlier application-level enterprise platforms e.g. ejabberd had even gone to the extent of implementing their own ssl processes). Well, that's where I am with this but feel free to disagree/correct, as I still feel there's a ways to go :) regards, /s On 2/1/2012 9:50 AM, Kaiduan Xie wrote: > "For instance, START_TLS is still not "easy" in erlang owing to the > long, and continuing, struggle > to get good TLS protocol support." > > Steve, do you mean the TLS support in Erlang is not good? Can you > explain a bit more? I think the new SSL in Erlang is awesome compared > with the old openSSL based implementation. > > /Kaiduan > > On Tue, Jan 31, 2012 at 8:21 PM, Steve Davis > wrote: >> I have noticed that a great number of SMTP projects fail with a >> whimper. In particular, I observed that the JBoss project ran an SMTP >> project for a long, long time before even barely having something >> reasonable, and it's still not really "production quality". While the >> underlying protocol for SMTP is straightforward, I think things run >> aground owing to the teams initially underestimating the number of >> rfcs and protocol extensions that you are essentially *required* to >> support (especially wrt authentication etc) to have a production level >> server; and also the storage issues such as the user directory and >> message store. >> >> There's no reason it couldn't be done, of course, but there's a lot of >> moving parts that need to come together to make it a real production >> competitor to the venerable sendmail or servers like MS exchange. >> >> As far as Erlang is concerned, it's hard to see it happening until >> certain requisite libraries are mature. For instance, START_TLS is >> still not "easy" in erlang owing to the long, and continuing, struggle >> to get good TLS protocol support. >> >> Assuming that does get "finished" (and there's a whole raft of crypto >> work still to do), perhaps a good start towards such a goal would be >> to integrate, at the very least, an LDAP client into the base >> libraries... >> >> ok before I ramble too much, I'll leave my 2c there. >> >> regards, >> /s >> >> On Jan 29, 12:56 am, Roberto Ostinelli wrote: >>> dear list, >>> >>> are you aware of any existent production-ready SMTP server in Erlang? I've >>> only found, maintained:https://github.com/Vagabond/gen_smtp >>> >>> thank you, >>> >>> r. >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > From kaiduanx@REDACTED Thu Feb 2 04:36:53 2012 From: kaiduanx@REDACTED (Kaiduan Xie) Date: Wed, 1 Feb 2012 22:36:53 -0500 Subject: [erlang-questions] smtp server In-Reply-To: <4F29FA84.3080603@gmail.com> References: <2b8d6c69-23d1-4046-8878-09d4729637a4@gi10g2000vbb.googlegroups.com> <4F29FA84.3080603@gmail.com> Message-ID: Ejabberd was written long time ago, the new SSL was introduced recently and the old SSL was buggy, so folks at Ejabberd came up an open SSL based solution. RabbitMQ is using new SSL. Anyone can share the experience? Thanks, /Kaiduan On Wed, Feb 1, 2012 at 9:52 PM, Steve Davis wrote: > Hi Kaiduan, > > For sure, with "old ssl", I could never get a reliable socket upgrade at > all. Comparatively, new ssl is indeed far more advanced than old ssl. > > Nonetheless, for the qualification of "awesome" in a platform comparison > (i.e. with NOT erts version X versus erts version Y) there's a massive task > that perhaps you can't appreciate without reviewing the following > document... > > http://www.iana.org/assignments/tls-parameters/tls-parameters.xml > > ...and test suite referenced here... > > http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html > > There's also connection cost/memory overhead to take into account, and > possibly process spawning cost under high load (which I have not measured > but "wonder about")... but I digress. > > I think the team at Ericsson that we rely on have made incredible strides > with tls, but the overall task is undeniably huge and will take quite some > time yet to settle into a mature implementation. Fortunately, the motivation > to solve these issues appears to be higher now than it was a couple of years > ago, and will definitely benefit all (also note that some of the earlier > application-level enterprise platforms e.g. ejabberd had even gone to the > extent of implementing their own ssl processes). > > Well, that's where I am with this but feel free to disagree/correct, as I > still feel there's a ways to go :) > > regards, > /s > > > > On 2/1/2012 9:50 AM, Kaiduan Xie wrote: >> >> "For instance, START_TLS is still not "easy" in erlang owing to the >> long, and continuing, struggle >> to get good TLS protocol support." >> >> Steve, do you mean the TLS support in Erlang is not good? Can you >> explain a bit more? I think the new SSL in Erlang is awesome compared >> with the old openSSL based implementation. >> >> /Kaiduan >> >> On Tue, Jan 31, 2012 at 8:21 PM, Steve Davis >> ?wrote: >>> >>> I have noticed that a great number of SMTP projects fail with a >>> whimper. In particular, I observed that the JBoss project ran an SMTP >>> project for a long, long time before even barely having something >>> reasonable, and it's still not really "production quality". While the >>> underlying protocol for SMTP is straightforward, I think things run >>> aground owing to the teams initially underestimating the number of >>> rfcs and protocol extensions that you are essentially *required* to >>> support (especially wrt authentication etc) to have a production level >>> server; and also the storage issues such as the user directory and >>> message store. >>> >>> There's no reason it couldn't be done, of course, but there's a lot of >>> moving parts that need to come together to make it a real production >>> competitor to the venerable sendmail or servers like MS exchange. >>> >>> As far as Erlang is concerned, it's hard to see it happening until >>> certain requisite libraries are mature. For instance, START_TLS is >>> still not "easy" in erlang owing to the long, and continuing, struggle >>> to get good TLS protocol support. >>> >>> Assuming that does get "finished" (and there's a whole raft of crypto >>> work still to do), perhaps a good start towards such a goal would be >>> to integrate, at the very least, an LDAP client into the base >>> libraries... >>> >>> ok before I ramble too much, I'll leave my 2c there. >>> >>> regards, >>> /s >>> >>> On Jan 29, 12:56 am, Roberto Ostinelli ?wrote: >>>> >>>> dear list, >>>> >>>> are you aware of any existent production-ready SMTP server in Erlang? >>>> I've >>>> only found, maintained:https://github.com/Vagabond/gen_smtp >>>> >>>> thank you, >>>> >>>> r. >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> >>>> erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> > From jozsef.berces@REDACTED Thu Feb 2 04:54:22 2012 From: jozsef.berces@REDACTED (=?iso-8859-1?Q?J=F3zsef_B=E9rces?=) Date: Thu, 2 Feb 2012 04:54:22 +0100 Subject: [erlang-questions] Native code In-Reply-To: <4F2650AA.2050406@cs.ntua.gr> References: <4F25AD8B.6070209@cs.ntua.gr> <4F2650AA.2050406@cs.ntua.gr> Message-ID: <3717CEF51B134A4F8073627839A9DF4120FE20366B@ESESSCMS0353.eemea.ericsson.se> Hi, It seems that even after compiling erlang with hipe support, the system modules do not have the native code. For example, beam_lib:info does not show any HX86 section for lists. Would the system benefit from compiling all files with native code? If yes, is there an easy way to do that? Maybe I missed some switches during compilation? Thanks, Jozsef From pfisher@REDACTED Thu Feb 2 05:33:30 2012 From: pfisher@REDACTED (Paul Fisher) Date: Wed, 1 Feb 2012 22:33:30 -0600 Subject: [erlang-questions] Native code In-Reply-To: <3717CEF51B134A4F8073627839A9DF4120FE20366B@ESESSCMS0353.eemea.ericsson.se> References: <4F25AD8B.6070209@cs.ntua.gr> <4F2650AA.2050406@cs.ntua.gr> <3717CEF51B134A4F8073627839A9DF4120FE20366B@ESESSCMS0353.eemea.ericsson.se> Message-ID: <73CFA33F-0496-4DD8-8115-187EB94BC8F7@alertlogic.com> --enable-native-libs -- paul On Feb 1, 2012, at 9:54 PM, "J?zsef B?rces" wrote: > Hi, > > It seems that even after compiling erlang with hipe support, the system modules do not have the native code. For example, beam_lib:info does not show any HX86 section for lists. > > Would the system benefit from compiling all files with native code? If yes, is there an easy way to do that? Maybe I missed some switches during compilation? > > Thanks, > Jozsef > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ok@REDACTED Thu Feb 2 05:33:49 2012 From: ok@REDACTED (Richard O'Keefe) Date: Thu, 2 Feb 2012 17:33:49 +1300 Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions In-Reply-To: <4aaf-4f28f200-3-4452b880@168192673> References: <4aaf-4f28f200-3-4452b880@168192673> Message-ID: On 1/02/2012, at 9:05 PM, Jakob Praher wrote: > No matter that the following may be a syntactic surface issue, but designating function objects is neither orthogonal nor does follow the expectations of the programmer. Therefore it also makes understanding code harder. > > if I can write: > module:fun(). > I should be also able to write > F = module:fun, F(). > and not having to write > F = fun module:fun/0, F(). > . > > I am happy to learn why module:fun is not an expression. Because it would be ambiguous. From ok@REDACTED Thu Feb 2 05:35:34 2012 From: ok@REDACTED (Richard O'Keefe) Date: Thu, 2 Feb 2012 17:35:34 +1300 Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions In-Reply-To: References: <1328084077.12502.4.camel@seasc1137> <6a2e-4f290080-5-6b8b4580@717786> Message-ID: <264CC271-1C1E-4AEB-883C-0A41D8E20B06@cs.otago.ac.nz> On 1/02/2012, at 10:52 PM, Hynek Vychodil wrote: > Disclaimer: It is mine explanation which works for me and makes me happy. > F is not designator per se but designator of variable. I don't understand this. From ok@REDACTED Thu Feb 2 05:46:01 2012 From: ok@REDACTED (Richard O'Keefe) Date: Thu, 2 Feb 2012 17:46:01 +1300 Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions In-Reply-To: <6a2e-4f291000-d-6b8b4580@717790> References: <6a2e-4f291000-d-6b8b4580@717790> Message-ID: On 1/02/2012, at 11:11 PM, Jakob Praher wrote: > I am just wondering what the benefits of using "fun module:fun/0" are. (1) It is unambiguous. There is no remaining doubt about *which* function it refers to. In contrast, module:fun refers to a potentially enormously large family of functions (except, of course, that it doesn't, because that family does not actually _exist_ as a concept in Erlang semantics). This is a HUGE benefit for people. (2) Because it is unambiguous, it is useful in cross-referencing. (3) Similarly, it's much more use to a type checker. > It is also just a designator (a reference) and has to be evaluated at runtime to get the address of the current function loaded. Eh? How is that different from mention of a remote function? In a call like module:func(Foo, Bar), where we know exactly what function we want and what we want to do with it (call it!), we still have to figure out at run time what the address is. > I can think that "fun module:fun/0" is used to be more familiar with anonymous functions. The actual syntactic form really isn't important. Having written an Erlang grammar from scratch, I was really glad to have the 'fun' keyword to warn me what was coming next. Disambiguating this occurrence of '/' from '/' meaning numeric division is helpful. > > According to parse_erl.yrl atom:atom is an expression (matched by expr_800), right? It's a grammar hack; the kind of thing where the syntax over-generalises and the semantics patches it. From kostis@REDACTED Thu Feb 2 08:51:56 2012 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 02 Feb 2012 09:51:56 +0200 Subject: [erlang-questions] Native code In-Reply-To: <3717CEF51B134A4F8073627839A9DF4120FE20366B@ESESSCMS0353.eemea.ericsson.se> References: <4F25AD8B.6070209@cs.ntua.gr> <4F2650AA.2050406@cs.ntua.gr> <3717CEF51B134A4F8073627839A9DF4120FE20366B@ESESSCMS0353.eemea.ericsson.se> Message-ID: <4F2A409C.3060203@cs.ntua.gr> On 02/02/12 05:54, J?zsef B?rces wrote: > Hi, > > It seems that even after compiling erlang with hipe support, the system modules do not have the native code. For example, beam_lib:info does not show any HX86 section for lists. > > Would the system benefit from compiling all files with native code? If yes, is there an easy way to do that? Maybe I missed some switches during compilation? As somebody else already mentioned, you can use the configure option: --enable-native-libs. However, this currently does not compile all files to native code. It only enables native code compilation of files in kernel, stdlib, hipe, dialyzer, typer and syntax_tools. There is no fundamental reason for this: it is just laziness from my part that I've never bothered adding the following lines to the Makefiles of the remaining applications: ifeq ($(NATIVE_LIBS_ENABLED),yes) ERL_COMPILE_FLAGS += +native endif Ideally, (something like) the above should be added in the `master' Makefile instead of on each and every individual Makefile. Perhaps somebody at OTP who knows the Makefile structure better than I do can do this change. Kostis From mfidelman@REDACTED Thu Feb 2 10:29:42 2012 From: mfidelman@REDACTED (Miles Fidelman) Date: Thu, 02 Feb 2012 04:29:42 -0500 Subject: [erlang-questions] newbie question: multiple shells, same VM? Message-ID: <4F2A5786.7090207@meetinghouse.net> Hi, Please pardon a perhaps silly newbie question. I'm just beginning to learn Erlang, and as I start playing with code that involves multiple concurrent processes, I find myself wanting to have multiple windows open, each running an Erlang shell, but all running on the same VM -- e.g., so I can interact with one process via one window and another process through a 2nd window, while those processes are both running in the same Erlang environment. (I.e., the same behavior one has with a regular Unix shell - open a new window, it's a new process, but it's running on a common underlying O/S instance). Which leads to the question: Is this possible, and if so, how? Thanks very much, Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From watson.timothy@REDACTED Thu Feb 2 10:48:58 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Thu, 2 Feb 2012 09:48:58 +0000 Subject: [erlang-questions] newbie question: multiple shells, same VM? In-Reply-To: <4F2A5786.7090207@meetinghouse.net> References: <4F2A5786.7090207@meetinghouse.net> Message-ID: Have a look at run_erl and to_erl. On 2 February 2012 09:29, Miles Fidelman wrote: > Hi, > > Please pardon a perhaps silly newbie question. > > I'm just beginning to learn Erlang, and as I start playing with code that > involves multiple concurrent processes, I find myself wanting to have > multiple windows open, each running an Erlang shell, but all running on the > same VM -- e.g., so I can interact with one process via one window and > another process through a 2nd window, while those processes are both > running in the same Erlang environment. (I.e., the same behavior one has > with a regular Unix shell - open a new window, it's a new process, but it's > running on a common underlying O/S instance). > > Which leads to the question: Is this possible, and if so, how? > > Thanks very much, > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > > ______________________________**_________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/**listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ngocdaothanh@REDACTED Thu Feb 2 10:49:09 2012 From: ngocdaothanh@REDACTED (Ngoc Dao) Date: Thu, 2 Feb 2012 18:49:09 +0900 Subject: [erlang-questions] newbie question: multiple shells, same VM? In-Reply-To: <4F2A5786.7090207@meetinghouse.net> References: <4F2A5786.7090207@meetinghouse.net> Message-ID: Yes this is possible. Erlang is very famous for this feature. 1. In a console, start a node: erl -sname mynode1 -setcookie mypassword A prompt like this will appear: (mynode1@REDACTED)1> ngoc is my computer name. 2. In another console connect to that node: erl -sname mynode2 -setcookie mypassword -remsh mynode1@REDACTED If you want to run the first node in background: erl -sname mynode1 -setcookie mypassword -detached Each node is like a virtual machine, virtual machine in the sense of virtual OS in cloud computing. Ngoc On Thu, Feb 2, 2012 at 6:29 PM, Miles Fidelman wrote: > Hi, > > Please pardon a perhaps silly newbie question. > > I'm just beginning to learn Erlang, and as I start playing with code that > involves multiple concurrent processes, I find myself wanting to have > multiple windows open, each running an Erlang shell, but all running on the > same VM -- e.g., so I can interact with one process via one window and > another process through a 2nd window, while those processes are both running > in the same Erlang environment. ?(I.e., the same behavior one has with a > regular Unix shell - open a new window, it's a new process, but it's running > on a common underlying O/S instance). > > Which leads to the question: Is this possible, and if so, how? > > Thanks very much, > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. ? .... Yogi Berra > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From freeakk@REDACTED Thu Feb 2 10:49:55 2012 From: freeakk@REDACTED (Michael Uvarov) Date: Thu, 2 Feb 2012 13:49:55 +0400 Subject: [erlang-questions] newbie question: multiple shells, same VM? In-Reply-To: <4F2A5786.7090207@meetinghouse.net> References: <4F2A5786.7090207@meetinghouse.net> Message-ID: ctrl+g, h -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Thu Feb 2 11:13:52 2012 From: mfidelman@REDACTED (Miles Fidelman) Date: Thu, 02 Feb 2012 05:13:52 -0500 Subject: [erlang-questions] newbie question: multiple shells, same VM? In-Reply-To: References: <4F2A5786.7090207@meetinghouse.net> Message-ID: <4F2A61E0.40006@meetinghouse.net> Ngoc, Exactly what I was looking for. Thanks! (And thanks for the amazingly quick reply at 5am in the morning, though it looks like it's a little later in the day for you :-) Miles Ngoc Dao wrote: > Yes this is possible. > Erlang is very famous for this feature. > > 1. In a console, start a node: > erl -sname mynode1 -setcookie mypassword > > A prompt like this will appear: > (mynode1@REDACTED)1> > > ngoc is my computer name. > > 2. In another console connect to that node: > erl -sname mynode2 -setcookie mypassword -remsh mynode1@REDACTED > > If you want to run the first node in background: > erl -sname mynode1 -setcookie mypassword -detached > > Each node is like a virtual machine, virtual machine in the sense of > virtual OS in cloud computing. > > Ngoc > > > On Thu, Feb 2, 2012 at 6:29 PM, Miles Fidelman > wrote: >> Hi, >> >> Please pardon a perhaps silly newbie question. >> >> I'm just beginning to learn Erlang, and as I start playing with code that >> involves multiple concurrent processes, I find myself wanting to have >> multiple windows open, each running an Erlang shell, but all running on the >> same VM -- e.g., so I can interact with one process via one window and >> another process through a 2nd window, while those processes are both running >> in the same Erlang environment. (I.e., the same behavior one has with a >> regular Unix shell - open a new window, it's a new process, but it's running >> on a common underlying O/S instance). >> >> Which leads to the question: Is this possible, and if so, how? >> >> Thanks very much, >> >> Miles Fidelman >> >> -- >> In theory, there is no difference between theory and practice. >> In practice, there is. .... Yogi Berra >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From ingela.andin@REDACTED Thu Feb 2 18:25:00 2012 From: ingela.andin@REDACTED (Ingela Andin) Date: Thu, 2 Feb 2012 18:25:00 +0100 Subject: [erlang-questions] smtp server In-Reply-To: <4F29FA84.3080603@gmail.com> References: <2b8d6c69-23d1-4046-8878-09d4729637a4@gi10g2000vbb.googlegroups.com> <4F29FA84.3080603@gmail.com> Message-ID: Hi! 2012/2/2, Steve Davis : > Hi Kaiduan, > > For sure, with "old ssl", I could never get a reliable socket upgrade at > all. Comparatively, new ssl is indeed far more advanced than old ssl. > > Nonetheless, for the qualification of "awesome" in a platform comparison > (i.e. with NOT erts version X versus erts version Y) there's a massive > task that perhaps you can't appreciate without reviewing the following > document... > > http://www.iana.org/assignments/tls-parameters/tls-parameters.xml > > ...and test suite referenced here... > > http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html We use this test suite to verify our PKIX-path-validation code, granted we do not yet support CRL-handling but that is on its way. Our verify_fun will let you work around the problem that it is not yet supported. (Not so fun for you perhaps but a possible solution for now). The somewhat optional policy mapping extension is further into the future, if we see a strong enough argument to implement it, but even this can be handled by the verify_fun if you really need it. We are working on supporting the latest TLS-version on the other hand as far as I know OpenSSL 1.0 only supports TLS v1.0. The development version has experimental support for TLS v1.1 and no version currently supports TLS v1.2. We do not support all possible optional extensions as Kerberos-cipher-SUITES, but hey feel free to contribute. > There's also connection cost/memory overhead to take into account, and > possibly process spawning cost under high load (which I have not > measured but "wonder about")... but I digress. Spawning erlang processes is cheap, but speculation is fairly uninteresting if you have concerns you should make measurments. Also check out the hibernate option that will make your ssl-processes garbage-collected earlier. Regards Ingela Erlang/OTP team - Ericsson AB > I think the team at Ericsson that we rely on have made incredible > strides with tls, but the overall task is undeniably huge and will take > quite some time yet to settle into a mature implementation. Fortunately, > the motivation to solve these issues appears to be higher now than it > was a couple of years ago, and will definitely benefit all (also note > that some of the earlier application-level enterprise platforms e.g. > ejabberd had even gone to the extent of implementing their own ssl > processes). > > Well, that's where I am with this but feel free to disagree/correct, as > I still feel there's a ways to go :) > > regards, > /s > > > On 2/1/2012 9:50 AM, Kaiduan Xie wrote: >> "For instance, START_TLS is still not "easy" in erlang owing to the >> long, and continuing, struggle >> to get good TLS protocol support." >> >> Steve, do you mean the TLS support in Erlang is not good? Can you >> explain a bit more? I think the new SSL in Erlang is awesome compared >> with the old openSSL based implementation. >> >> /Kaiduan >> >> On Tue, Jan 31, 2012 at 8:21 PM, Steve Davis >> wrote: >>> I have noticed that a great number of SMTP projects fail with a >>> whimper. In particular, I observed that the JBoss project ran an SMTP >>> project for a long, long time before even barely having something >>> reasonable, and it's still not really "production quality". While the >>> underlying protocol for SMTP is straightforward, I think things run >>> aground owing to the teams initially underestimating the number of >>> rfcs and protocol extensions that you are essentially *required* to >>> support (especially wrt authentication etc) to have a production level >>> server; and also the storage issues such as the user directory and >>> message store. >>> >>> There's no reason it couldn't be done, of course, but there's a lot of >>> moving parts that need to come together to make it a real production >>> competitor to the venerable sendmail or servers like MS exchange. >>> >>> As far as Erlang is concerned, it's hard to see it happening until >>> certain requisite libraries are mature. For instance, START_TLS is >>> still not "easy" in erlang owing to the long, and continuing, struggle >>> to get good TLS protocol support. >>> >>> Assuming that does get "finished" (and there's a whole raft of crypto >>> work still to do), perhaps a good start towards such a goal would be >>> to integrate, at the very least, an LDAP client into the base >>> libraries... >>> >>> ok before I ramble too much, I'll leave my 2c there. >>> >>> regards, >>> /s >>> >>> On Jan 29, 12:56 am, Roberto Ostinelli wrote: >>>> dear list, >>>> >>>> are you aware of any existent production-ready SMTP server in Erlang? >>>> I've >>>> only found, maintained:https://github.com/Vagabond/gen_smtp >>>> >>>> thank you, >>>> >>>> r. >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From emmiller@REDACTED Thu Feb 2 20:24:16 2012 From: emmiller@REDACTED (Evan Miller) Date: Thu, 2 Feb 2012 13:24:16 -0600 Subject: [erlang-questions] [ANN] Chicago Boss 0.7 released Message-ID: Chicago Boss (http://www.chicagoboss.org/) hit version 0.7 yesterday and is fast approaching 1.0. This version of the web framework makes it easier to manage the production server via the command line and now uses Rebar for building projects. The full announcement is here: http://groups.google.com/group/chicagoboss/browse_thread/thread/45818549c3f74a9 The PDF tutorial (http://www.chicagoboss.org/tutorial.pdf) has been updated accordingly. Our next focus of development will be on scalability, i.e. getting rid of remaining bottlenecks by using worker process pools. If that sounds like fun to you, come on by! Best regards, Evan Miller From roberto@REDACTED Thu Feb 2 21:51:38 2012 From: roberto@REDACTED (Roberto Ostinelli) Date: Thu, 2 Feb 2012 12:51:38 -0800 Subject: [erlang-questions] XML diff In-Reply-To: <3D88AA58-1851-459D-96D9-E1D64DD93BB2@cs.otago.ac.nz> References: <3D88AA58-1851-459D-96D9-E1D64DD93BB2@cs.otago.ac.nz> Message-ID: than you so much richard, this looks very interesting. thank all of you for responses :) r. On Tue, Jan 31, 2012 at 7:27 PM, Richard O'Keefe wrote: > Look at > http://www.cs.umd.edu/Outreach/hsContest99/questions/node8.html > and follow the "Our Solution" link. > which refers to Stanley Selkow's paper in > Information Processing Letters, Volume 6, number 6, 1977. > > There's a paper by Wuu Yang in Software Practice and > Experience, Volume 21, issue 7, 739-755 (July 1991), > called "Identifying Syntactic Differences Between Two Programs" > which works by finding differences between their parse trees. > > There's a Perl module for precisely this task at > http://search.cpan.org/~sdether/XML-Diff-0.04/Diff.pm > The documentation points to Gregory Cobena's PhD thesis > which can be found through at > http://gregory.cobena.free.fr/www/Publications/thesis.html > I haven't read that, but it has a chapter comparing several > algorithms. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto@REDACTED Thu Feb 2 21:52:40 2012 From: roberto@REDACTED (Roberto Ostinelli) Date: Thu, 2 Feb 2012 12:52:40 -0800 Subject: [erlang-questions] smtp server In-Reply-To: <2b8d6c69-23d1-4046-8878-09d4729637a4@gi10g2000vbb.googlegroups.com> References: <2b8d6c69-23d1-4046-8878-09d4729637a4@gi10g2000vbb.googlegroups.com> Message-ID: indeed. i actually liked your 'rambling', so if you have other specific issues you're thinking of please let us know. r. On Tue, Jan 31, 2012 at 5:21 PM, Steve Davis wrote: > I have noticed that a great number of SMTP projects fail with a > whimper. In particular, I observed that the JBoss project ran an SMTP > project for a long, long time before even barely having something > reasonable, and it's still not really "production quality". While the > underlying protocol for SMTP is straightforward, I think things run > aground owing to the teams initially underestimating the number of > rfcs and protocol extensions that you are essentially *required* to > support (especially wrt authentication etc) to have a production level > server; and also the storage issues such as the user directory and > message store. > > There's no reason it couldn't be done, of course, but there's a lot of > moving parts that need to come together to make it a real production > competitor to the venerable sendmail or servers like MS exchange. > > As far as Erlang is concerned, it's hard to see it happening until > certain requisite libraries are mature. For instance, START_TLS is > still not "easy" in erlang owing to the long, and continuing, struggle > to get good TLS protocol support. > > Assuming that does get "finished" (and there's a whole raft of crypto > work still to do), perhaps a good start towards such a goal would be > to integrate, at the very least, an LDAP client into the base > libraries... > > ok before I ramble too much, I'll leave my 2c there. > > regards, > /s > > On Jan 29, 12:56 am, Roberto Ostinelli wrote: > > dear list, > > > > are you aware of any existent production-ready SMTP server in Erlang? > I've > > only found, maintained:https://github.com/Vagabond/gen_smtp > > > > thank you, > > > > r. > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questi...@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 steven.charles.davis@REDACTED Fri Feb 3 02:07:24 2012 From: steven.charles.davis@REDACTED (Steve Davis) Date: Thu, 2 Feb 2012 17:07:24 -0800 (PST) Subject: [erlang-questions] smtp server In-Reply-To: References: <2b8d6c69-23d1-4046-8878-09d4729637a4@gi10g2000vbb.googlegroups.com> <4F29FA84.3080603@gmail.com> Message-ID: For sure, if you have an interest in this specific topic (i.e. SSL in RabbitMQ), the below page is worth reading as it provides some perspective from the RabbitMQ team. The document includes a section on "bugs in new_ssl": http://www.rabbitmq.com/ssl.html Note when reading the speed at which many earlier bugs in new_ssl were resolved; So while the TLS effort for the platform is making enormous strides and the response is fast, the library still isn't what you could call "mature". regs, /s On Feb 1, 9:36?pm, Kaiduan Xie wrote: > RabbitMQ is using new SSL. Anyone can share the experience? From steven.charles.davis@REDACTED Fri Feb 3 02:15:58 2012 From: steven.charles.davis@REDACTED (Steve Davis) Date: Thu, 2 Feb 2012 17:15:58 -0800 (PST) Subject: [erlang-questions] smtp server In-Reply-To: References: <2b8d6c69-23d1-4046-8878-09d4729637a4@gi10g2000vbb.googlegroups.com> <4F29FA84.3080603@gmail.com> Message-ID: <0b0f023a-4866-4c6f-9e73-d05cef76e95b@n8g2000pbc.googlegroups.com> Hi Ingela, I'm sure that all on this list appreciate the amazing progress that's been made with new_ssl, and I tried to highlight that in my earlier comments. I also commented that the library can't be considered "mature" for some of the very reasons that you state. I appreciate that there's a long "to do" list, and that the scope of the effort required to accomplish it was huge. Please see the inline comment also :) On Feb 2, 11:25?am, Ingela Andin wrote: > Hi! > > 2012/2/2, Steve Davis : > > ...and test suite referenced here... > > >http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html > > We use this test suite to verify our PKIX-path-validation code, > granted we do not yet support CRL-handling but that is on its > way. Our verify_fun will let you work around the problem that it > is not yet supported. (Not so fun for you perhaps but a possible > solution for now). > > The somewhat optional policy mapping extension is further into the > future, if we see a strong enough argument to implement it, but > even this can be handled by the verify_fun if you really need it. > > We are working on supporting the latest TLS-version on the other > hand as far as I know OpenSSL 1.0 only supports TLS v1.0. The > development version has experimental support for TLS v1.1 and no > version currently supports TLS v1.2. > > We do not support all possible optional extensions as > Kerberos-cipher-SUITES, but hey feel free to contribute. > > > There's also connection cost/memory overhead to take into account, and > > possibly process spawning cost under high load (which I have not > > measured but "wonder about")... but I digress. > > Spawning erlang processes is cheap, but speculation is fairly > uninteresting if you have > concerns you should make measurments. I couldn't agree more - only measurement would allay that concern. Spawning is indeed cheap but it is not free. Should I be able to provide any worthwhile results on that, I most certainly will. > Also check out the hibernate > option that will > make your ssl-processes garbage-collected earlier. > > Regards Ingela Erlang/OTP team - Ericsson AB > Best regards, /s From sg2342@REDACTED Fri Feb 3 03:10:36 2012 From: sg2342@REDACTED (Stefan Grundmann) Date: Fri, 3 Feb 2012 02:10:36 +0000 Subject: [erlang-questions] smtp server In-Reply-To: References: <2b8d6c69-23d1-4046-8878-09d4729637a4@gi10g2000vbb.googlegroups.com> <4F29FA84.3080603@gmail.com> Message-ID: <20120203021036.53281d7c@googlemail.com> On Thu, 2 Feb 2012 18:25:00 +0100 Ingela Andin wrote: > We use this test suite to verify our PKIX-path-validation code, > granted we do not yet support CRL-handling but that is on its > way. Our verify_fun will let you work around the problem that it > is not yet supported. (Not so fun for you perhaps but a possible > solution for now). this is unfortunately not the case since for versions that contain commit 4dbf3c9e4ae7cfd19b247353369166d31b8f15e5 (it is in R14B04 and R15B) the documented behaviour (verify_fun will be called for every certificate) is broken: the verify_fun will only be called, if the certificate contains unknown extensions. it is therefore not useful as a CRL workaround (anymore). best regards Stefan Grundmann From ttom.kelly@REDACTED Fri Feb 3 11:44:15 2012 From: ttom.kelly@REDACTED (tom kelly) Date: Fri, 3 Feb 2012 10:44:15 +0000 Subject: [erlang-questions] Slow when using chained gen_server:call's, redesign or optimize? In-Reply-To: References: Message-ID: Hi List, I'm a bit late replying to this thread, only reading it now. Probably too late to help the original poster but here's my contribution anyway. Matthew, hope you don't mind me suggesting a minor improvement to your code snippet, just to demonstrate a larger point. Instead of: handle_call({long_operation,Data},From,State) -> spawn(fun() -> Rsp = do_lengthy_operation(Data), gen_server:reply(Rsp,From) end), {noreply, State}; I prefer getting the calling thread to do as much work as possible. Here a process is spawned to do the work and then die, all while the calling process waits. I think it's preferable to get the calling process to do the work itself, it avoids the spawn and any crashes in the do_lengthy_operation are argubly easier to debug. Eg: long_operation(Data) -> State = gen_server:call(?MODULE, get_state), do_lengthy_operation(Data,State). handle_call(get_state,_From,State) -> {reply,State,State}; Normally when I'm writing a new gen_server I get the calling process to do as much work as possible and try to get the handle_calls/casts to only do the work that requires mutual exclusion. I normally store what I can in a protected, named_table ets table so that interface funtions that need this can read it without going through the gen_server but I do all updates in a handle_call/cast. Once one of my gen_servers became a bottle-neck in a system and I ended up taking these steps to fix the problem. Since then I've adopted this as a rule of thumb when writing new gen_servers and avoid such pointless bottle-necks that I'd have to fix later on anyway. I inherited some code with the same problem as the original poster with gen_server calls going five-deep in one instance. Everything worked fine at low load levels but once the load crossed a threshold there was no recovery as every management process spent most of its time waiting for other management processes to reply while their own message queues built up. Meanwhile the worker threads would timeout, reconnect and add to the backlog. The message queues just built up until the entire node fell over. After making sure that the chained calls weren't required to keep the data consistent I moved as work as possible to the calling process. This way I kept the interface unchanged for each module but avoided the case where each process in the chain was tied up, waiting for the last one to complete. I think for newbies it's important to be aware of which process is doing the work. I know when I started using Erlang it took a while to get my head around the concurrency. //TTom. On Sat, Jan 28, 2012 at 3:18 PM, Matthew Evans wrote: > Of course you need to run a profiler such as fprof to see what's going > on. > > Sounds like a classic head of line blocking problem. Many requests, > possibly from processes on different schedulers/cores, all getting > serialized on a single gen_server. > > The obvious, and maybe non-OTP, answer is to hold some of this state > information in a public or protected named ETS table that your clients read > from directly. A single gen_server can still own and write to that ETS > table. > > Another obvious answer is to provide back-pressure of some kind to prevent > clients from requesting data when it is under load. > > You might find that a particular infrequent gen_server:call operation is > taking a long time to complete causing a message queue to suddenly grow. > You might want to change such an operation from: > > handle_call({long_operation,Data},From,State) -> > Rsp = do_lengthy_operation(Data), > {reply, Rsp, State}; > > to: > > handle_call({long_operation,Data},From,State) -> > spawn(fun() -> > Rsp = do_lengthy_operation(Data), > gen_server:reply(Rsp,From) > end), > {noreply, State}; > > > ------------------------------ > From: goddang@REDACTED > To: erlang-questions@REDACTED > Date: Sat, 28 Jan 2012 00:06:04 +0000 > Subject: [erlang-questions] Slow when using chained gen_server:call's, > redesign or optimize? > > > I'm creating a system where I've ended up with alot of gen_servers that > provides a clean interface. When I run this under load I see that the > gen_server:call's is becoming a bottleneck. > For instance, In a handle_request I might ask an other gen_server to get > me a cached object, then ask the database something, then etc... > and in some cases I have > my-gen_server->cache-gen_server->memcache-client-gen_server as you see it > stacks up to alot of steps. I've tried to optimize with deferring > gen_server responses and that has given a slight performance improvement > but not as drastical as if I for instance bypass one gen_server instance. > > Is there a better way to go about this or some smart optimization to do? > And FYI, I use gen_server when I need to keep a state of a connection or > something so if the answer is to scrap or reduce the number of gen_servers > I will need to keep those connections somewhere else. > > Thanks, Dang > > > _______________________________________________ erlang-questions mailing > list 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 als@REDACTED Fri Feb 3 13:11:57 2012 From: als@REDACTED (Anthony Shipman) Date: Fri, 3 Feb 2012 23:11:57 +1100 Subject: [erlang-questions] sharing a binary when decoding? Message-ID: <201202032311.57110.als@iinet.net.au> If I decode a binary B using binary_to_term() and get a result like {1, 2, <<"abc">>} is it guaranteed that a binary in the result is a sub-binary of B? -- Anthony Shipman Mamas don't let your babies als@REDACTED grow up to be outsourced. From carlsson.richard@REDACTED Fri Feb 3 13:27:32 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Fri, 03 Feb 2012 13:27:32 +0100 Subject: [erlang-questions] sharing a binary when decoding? In-Reply-To: <201202032311.57110.als@iinet.net.au> References: <201202032311.57110.als@iinet.net.au> Message-ID: <4F2BD2B4.1040409@gmail.com> On 02/03/2012 01:11 PM, Anthony Shipman wrote: > If I decode a binary B using binary_to_term() and get a result like > {1, 2,<<"abc">>} is it guaranteed that a binary in the result is a sub-binary > of B? I can't see why the language would want to give such a guarantee, since that would prevent making more efficient implementation choices in certain cases. For example, if the resulting binary is quite short, as in your example, it's probably better to just copy the data to a new binary. On a 64-bit machine, one could even use an immediate representation of a single word for very short binaries, if there is room in the tagging scheme. (I don't know if Erts does this already.) /Richard From ingela.andin@REDACTED Fri Feb 3 13:31:03 2012 From: ingela.andin@REDACTED (Ingela Andin) Date: Fri, 3 Feb 2012 13:31:03 +0100 Subject: [erlang-questions] smtp server In-Reply-To: <20120203021036.53281d7c@googlemail.com> References: <2b8d6c69-23d1-4046-8878-09d4729637a4@gi10g2000vbb.googlegroups.com> <4F29FA84.3080603@gmail.com> <20120203021036.53281d7c@googlemail.com> Message-ID: Hi! You are correct there is a bug in ssl here is the patch that will be part of the next release. diff --git a/lib/ssl/src/ssl_handshake.erl b/lib/ssl/src/ssl_handshake.erl index 371f475..d68b80c 100644 --- a/lib/ssl/src/ssl_handshake.erl +++ b/lib/ssl/src/ssl_handshake.erl @@ -188,14 +188,14 @@ certify(#certificate{asn1_certificates = ASN1Certs}, CertDbHandle, CertDbRef, ValidationFunAndState = case VerifyFunAndState of undefined -> - {fun(OtpCert, ExtensionOrError, SslState) -> + {fun(OtpCert, ExtensionOrVerifyResult, SslState) -> ssl_certificate:validate_extension(OtpCert, - ExtensionOrError, SslState) + ExtensionOrVerifyResult, SslState) end, Role}; {Fun, UserState0} -> - {fun(OtpCert, ExtensionOrError, {SslState, UserState}) -> + {fun(OtpCert, {extension, _} = Extension, {SslState, UserState}) -> case ssl_certificate:validate_extension(OtpCert, - ExtensionOrError, + Extension, SslState) of {valid, NewSslState} -> {valid, {NewSslState, UserState}}; @@ -204,8 +204,11 @@ certify(#certificate{asn1_certificates = ASN1Certs}, CertDbHandle, CertDbRef, SslState); {unknown, _} -> apply_user_fun(Fun, OtpCert, - ExtensionOrError, UserState, SslState) - end + Extension, UserState, SslState) + end; + (OtpCert, VerifyResult, {SslState, UserState}) -> + apply_user_fun(Fun, OtpCert, VerifyResult, UserState, + SslState) end, {Role, UserState0}} end, Regards Ingela Erlang/OTP team - Ericsson AB 2012/2/3, Stefan Grundmann : > On Thu, 2 Feb 2012 18:25:00 +0100 > Ingela Andin wrote: >> We use this test suite to verify our PKIX-path-validation code, >> granted we do not yet support CRL-handling but that is on its >> way. Our verify_fun will let you work around the problem that it >> is not yet supported. (Not so fun for you perhaps but a possible >> solution for now). > > this is unfortunately not the case since for versions that contain > commit 4dbf3c9e4ae7cfd19b247353369166d31b8f15e5 (it is in R14B04 and > R15B) the documented behaviour (verify_fun will be called for every > certificate) is broken: the verify_fun will only be called, if the > certificate contains unknown extensions. > it is therefore not useful as a CRL workaround (anymore). > > best regards > > Stefan Grundmann > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From als@REDACTED Fri Feb 3 14:12:01 2012 From: als@REDACTED (Anthony Shipman) Date: Sat, 4 Feb 2012 00:12:01 +1100 Subject: [erlang-questions] sharing a binary when decoding? In-Reply-To: <4F2BD2B4.1040409@gmail.com> References: <201202032311.57110.als@iinet.net.au> <4F2BD2B4.1040409@gmail.com> Message-ID: <201202040012.01907.als@iinet.net.au> On Fri, 3 Feb 2012 11:27:32 pm Richard Carlsson wrote: > On 02/03/2012 01:11 PM, Anthony Shipman wrote: > > If I decode a binary B using binary_to_term() and get a result like > > {1, 2,<<"abc">>} is it guaranteed that a binary in the result is a > > sub-binary of B? > > I can't see why the language would want to give such a guarantee, since > that would prevent making more efficient implementation choices in > certain cases. For example, if the resulting binary is quite short, as > in your example, it's probably better to just copy the data to a new > binary. On a 64-bit machine, one could even use an immediate > representation of a single word for very short binaries, if there is > room in the tagging scheme. (I don't know if Erts does this already.) > > /Richard What I have in mind will have large binaries that are decoded from socket data. I was hoping that this wouldn't duplicate the data. -- Anthony Shipman Mamas don't let your babies als@REDACTED grow up to be outsourced. From jesper.louis.andersen@REDACTED Fri Feb 3 15:20:02 2012 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 03 Feb 2012 15:20:02 +0100 Subject: [erlang-questions] sharing a binary when decoding? In-Reply-To: <201202040012.01907.als@iinet.net.au> References: <201202032311.57110.als@iinet.net.au> <4F2BD2B4.1040409@gmail.com> <201202040012.01907.als@iinet.net.au> Message-ID: <4F2BED12.7030500@erlang-solutions.com> On 2/3/12 2:12 PM, Anthony Shipman wrote: > What I have in mind will have large binaries that are decoded from > socket data. I was hoping that this wouldn't duplicate the data. The binary might be compressed and in that case it is not possible to use the sub-binary representation. In other words, you are not guaranteed that it uses sub-binaries, but an implementation may choose to do so in some cases. My recommendation would be to decode once and then go with that. Decoding is usually extremely fast. -- Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen, DK From jesper.louis.andersen@REDACTED Fri Feb 3 15:24:37 2012 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 03 Feb 2012 15:24:37 +0100 Subject: [erlang-questions] XML diff In-Reply-To: <3D88AA58-1851-459D-96D9-E1D64DD93BB2@cs.otago.ac.nz> References: <3D88AA58-1851-459D-96D9-E1D64DD93BB2@cs.otago.ac.nz> Message-ID: <4F2BEE25.6020908@erlang-solutions.com> On 2/1/12 4:27 AM, Richard O'Keefe wrote: > Look at > http://www.cs.umd.edu/Outreach/hsContest99/questions/node8.html > and follow the "Our Solution" link. > which refers to Stanley Selkow's paper in > Information Processing Letters, Volume 6, number 6, 1977. > Another pointer that might be interesting is the multiset discrimination path (Bob Paige et.al). Fritz Henglein worked with that about 10 years ago. The references here might prove helpful as well: http://www.plan-x.org/msd/ -- Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen, DK From jesper.louis.andersen@REDACTED Fri Feb 3 16:34:54 2012 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 03 Feb 2012 16:34:54 +0100 Subject: [erlang-questions] Writers Readers problem In-Reply-To: References: Message-ID: <4F2BFE9E.5060701@erlang-solutions.com> On 1/31/12 4:12 PM, Garrett Smith wrote: > This sounds like a registered process (e.g. gen_server) that manages > the token. It's user facing API might look like this: > > acquire_token() -> {ok, Token} | timeout > acquire_token(Timeout) -> {ok, Token} | timeout > release_token(Token) > is_token_valid(Token) -> boolean() In addition, the gen_server could set a monitor on the process that acquires the token so if the worker dies, then the token is given back to the queue. I don't think it is a bad idea to have a single process since the token operations are supposed to take very little time anyway and you need a serious amount of run on this token system before its performance limits will emerge. -- Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen, DK From zabrane3@REDACTED Fri Feb 3 17:27:32 2012 From: zabrane3@REDACTED (Zabrane Mickael) Date: Fri, 3 Feb 2012 17:27:32 +0100 Subject: [erlang-questions] [ANN] Chicago Boss 0.7 released In-Reply-To: References: Message-ID: <4B9DAC0D-522A-4844-951F-4DDE7447C8EB@gmail.com> Congratulations for this new release Evan! Regards, Zabrane On Feb 2, 2012, at 8:24 PM, Evan Miller wrote: > Chicago Boss (http://www.chicagoboss.org/) hit version 0.7 yesterday > and is fast approaching 1.0. This version of the web framework makes > it easier to manage the production server via the command line and now > uses Rebar for building projects. The full announcement is here: > > http://groups.google.com/group/chicagoboss/browse_thread/thread/45818549c3f74a9 > > The PDF tutorial (http://www.chicagoboss.org/tutorial.pdf) has been > updated accordingly. Our next focus of development will be on > scalability, i.e. getting rid of remaining bottlenecks by using worker > process pools. If that sounds like fun to you, come on by! > > Best regards, > > Evan Miller > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ulf@REDACTED Fri Feb 3 18:20:25 2012 From: ulf@REDACTED (Ulf Wiger) Date: Fri, 3 Feb 2012 18:20:25 +0100 Subject: [erlang-questions] xmerl expanded names Message-ID: <46D3999F-633C-4CB3-8537-BD927B4B6EC4@feuerlabs.com> Refreshing my memory of the xmerl_scan code, I came across this apparent discrepancy: -record(xmlElement,{ name, % atom() expanded_name = [], % string() | {URI,Local} | {"xmlns",Local} So the types are just comments, leaving Dialyzer out of this, but, in xmerl_scan.erl: processed_whole_element(S=#xmerl_scanner{...}, Pos, Name, Attrs, Lang, Parents, NSI, Namespace) -> ..., {ExpName, ExpAttrs} = case S#xmerl_scanner.namespace_conformant of true -> ? {expanded_name(Name, NSI, Namespace, S), ExpAttrsX}; false -> {Name, AllAttrs} end, #xmlElement{name = Name, ..., expanded_name = ExpName, ...}. If S#xmerl_scanner.namespace_conformant == false, ExpName = Name, but Name cannot be an atom() and a string() at the same time. The type comments in xmerl.hrl, then, are likely incorrect. Or is it the code? Less likely, I think. The bug is of course that Dialyzer cannot parse xmerl comments. :) BR, Ulf W From roberto@REDACTED Fri Feb 3 18:21:54 2012 From: roberto@REDACTED (Roberto Ostinelli) Date: Fri, 3 Feb 2012 09:21:54 -0800 Subject: [erlang-questions] XML diff In-Reply-To: <4F2BEE25.6020908@erlang-solutions.com> References: <3D88AA58-1851-459D-96D9-E1D64DD93BB2@cs.otago.ac.nz> <4F2BEE25.6020908@erlang-solutions.com> Message-ID: interesting, thank you. r. On Fri, Feb 3, 2012 at 6:24 AM, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > >> Another pointer that might be interesting is the multiset discrimination > path (Bob Paige et.al). Fritz Henglein worked with that about 10 years > ago. The references here might prove helpful as well: > > http://www.plan-x.org/msd/\ -------------- next part -------------- An HTML attachment was scrubbed... URL: From joelr1@REDACTED Fri Feb 3 18:30:32 2012 From: joelr1@REDACTED (Joel Reymont) Date: Fri, 3 Feb 2012 17:30:32 +0000 Subject: [erlang-questions] erlang api for amazon dynamo db Message-ID: https://github.com/wagerlabs/ddb Kudos to Issuu Aps for allowing me to open source this library! FYI, I'm available for consulting effective February 15. -- Hardcore embedded Linux development http://www.linkedin.com/in/joelreymont Device drivers, firmware and debugging From gumm@REDACTED Fri Feb 3 18:54:49 2012 From: gumm@REDACTED (Jesse Gumm) Date: Fri, 3 Feb 2012 11:54:49 -0600 Subject: [erlang-questions] [ANN] Chicago Boss 0.7 released In-Reply-To: <4B9DAC0D-522A-4844-951F-4DDE7447C8EB@gmail.com> References: <4B9DAC0D-522A-4844-951F-4DDE7447C8EB@gmail.com> Message-ID: Congrats on the release! -- Jesse Gumm Owner, Sigma Star Systems 414.940.4866 www.sigma-star.com @jessegumm On Feb 3, 2012 10:33 AM, "Zabrane Mickael" wrote: > Congratulations for this new release Evan! > > Regards, > Zabrane > > > On Feb 2, 2012, at 8:24 PM, Evan Miller wrote: > > > Chicago Boss (http://www.chicagoboss.org/) hit version 0.7 yesterday > > and is fast approaching 1.0. This version of the web framework makes > > it easier to manage the production server via the command line and now > > uses Rebar for building projects. The full announcement is here: > > > > > http://groups.google.com/group/chicagoboss/browse_thread/thread/45818549c3f74a9 > > > > The PDF tutorial (http://www.chicagoboss.org/tutorial.pdf) has been > > updated accordingly. Our next focus of development will be on > > scalability, i.e. getting rid of remaining bottlenecks by using worker > > process pools. If that sounds like fun to you, come on by! > > > > Best regards, > > > > Evan Miller > > _______________________________________________ > > erlang-questions mailing list > > 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 jwatte@REDACTED Fri Feb 3 19:13:57 2012 From: jwatte@REDACTED (Jon Watte) Date: Fri, 3 Feb 2012 10:13:57 -0800 Subject: [erlang-questions] Large-scale Erlang in practice Message-ID: As some of you know, we operate a medium-to-large-scale Erlang infrastructure, with about 16 nodes (each of which is a dual-Xeon type Dell server) As we put load on the system, we keep finding places where the system falls over, typically based on N-squared behavior in various parts of the OTP and the runtime library. This is a bit disconcerting, because any system that scales really should be built with constant-time (or, worst case, log-time) runtime behavior. The latest such behavior we've found is gen_udp:send(). This will make a synchronous call from the calling process to the inet system. Then it will wait for a response. Unfortunately, that wait-for-response means a matched receive to the current process. When the current process has a mailbox with a number of messages, then each call to gen_udp:send() will have to scan all the messages in the mailbox. So, consider a burst of, say, 10,000 messages I want to send. If each of those messages are an input message to a process that calls gen_udp:send(), then sending one of those messages will cause a mailbox scan of the entire queue. I might say that "I shouldn't have a long mailbox," but in a message-based system, that's pretty much impossible to avoid. For example, if some part of the Internet is having bad weather, ten or twenty thousand clients will possibly be disconnected at one time, each of which will cause a process monitor message to be queued with the supervisor or other such process. If all operations are constant-time, that doesn't matter, but with each operation being linear in pending messages or linear in number of supervised processes, such an event will cause unbounded disrupion to the system at large -- not just the clients affected by the "bad weather." So, what's the meaning of this rant? Three things: 1) I'm considering writing some nifs that allow me to send UDP datagrams without going through a mailbox scan. For syslog and statistics, this would be a perfectly fine thing to do. 2) Are there any other "linear-in-number-of-users-so-n-squared-overall" systems we need to worry about? Mailbox scans may happen deep inside the standard libraries, and I'm at the mercy of those implementations, no matter how careful I am in crafting my own code. (N-squared garbage generated by using dict for data that mutates often was another "neat" realization.) What's the next thing that we'll run into? 3) Has there been any attempt at removing these kinds of bottlenecks on a more systematic level? We're still using R13B3 because we're using Ubuntu LTS which is still version 10.04... However, if there is a significant, measurable gain to be had by upgrading, it might be worth it. Sincerely, jw -- Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. From jwatte@REDACTED Fri Feb 3 19:18:52 2012 From: jwatte@REDACTED (Jon Watte) Date: Fri, 3 Feb 2012 10:18:52 -0800 Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions In-Reply-To: <1328087849.12502.11.camel@seasc1137> References: <6a2e-4f290080-5-6b8b4580@717786> <1328087849.12502.11.camel@seasc1137> Message-ID: The question is: why is the grammar like that? For people used to first class functions, Erlang doesn't actually live up to the expectation. I think there are both runtime efficiency and legacy implementation reasons for this. Note that it's a bit ambiguous what this would mean in the face of code loading: F = module:fun Now, reload "module" Does F() call the old code, or the new code? I could see an argument for either way, but the more useful behavior would be to call the new code. Sincerely, jw -- Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. On Wed, Feb 1, 2012 at 1:17 AM, Bengt Kleberg wrote: > I think {module,fun} is a complete ''thing'' (grammar item?) whereas > module:fun is lacking a final () to be complete. > > > bengt > > ?On Wed, 2012-02-01 at 10:05 +0100, Jakob Praher wrote: >> Thanks for your reply. >> >> As a counterargument F = {module,fun}, F(). works. >> Also in this case F is just the designator and not the function itself. >> >> It would be possible for instance to evaluate module:fun as {module,fun}. >> >> Best, >> Jakob >> >> >> >> Am Mittwoch, 01. Februar 2012 09:14 CET, Bengt Kleberg schrieb: >> >> > Greetings, >> > >> > This is perhaps totally wrong but in my mind allowing >> > F = module:fun, >> > F(). >> > >> > would also mean that this is good: >> > F = module:fun(, >> > F). >> > >> > Ie, "F = module:fun" is text/syntax, not semantic. >> > >> > >> > bengt >> > >> > On Wed, 2012-02-01 at 09:05 +0100, Jakob Praher wrote: >> > > Hi Erlangers, >> > > >> > > I think people should pay attention to issues faced by experienced newcomers in exercising Erlang programming. Matz from Ruby calls a ver important design principle, the principle of least surprise. >> > > >> > > No matter that the following may be a syntactic surface issue, but designating function objects is neither orthogonal nor does follow the expectations of the programmer. Therefore it also makes understanding code harder. >> > > >> > > if I can write: >> > > ? ? ?module:fun(). >> > > I should be also able to write >> > > ? ? ?F = module:fun, F(). >> > > and not having to write >> > > ? ? ?F = fun module:fun/0, F(). >> > > . >> > > >> > > I am happy to learn why module:fun is not an expression. >> > > >> > > Best, >> > > Jakob >> > > >> > > >> > > Am Dienstag, 31. Januar 2012 14:07 CET, "Jakob Praher" schrieb: >> > > >> > > > >> > > > As I tried out the code below I learned that tuples of module and function atoms evalute to functions, not atoms by themselves. >> > > > If one can apply arguments to a tuple, why not to an atom if this would be denote a function in the current environment? >> > > > >> > > > {R, V} = apply_each([{m1,z},{m2,y},{m3,x}], Arg). >> > > > if R = ok -> ... >> > > > >> > > > Thanks, >> > > > Jakob >> > > > >> > > > >> > > > Am Mittwoch, 25. Januar 2012 14:29 CET, "Jakob Praher" schrieb: >> > > > >> > > > > >> > > > > One could also compose a sequence of functions much like in combinator parsing, and fail at the first event returning the error status, otherwise continue to call apply the functions to the result. >> > > > > >> > > > > apply_each([F|FS],X) -> >> > > > > ? ? ? {S, V} = F(X), >> > > > > ? ? ? if S = error ?-> >> > > > > ? ? ? ? ? ? {S, V} >> > > > > ? ? ? ? ?S = ok -> >> > > > > ? ? ? ? ? ? apply_each(FS, V); >> > > > > ? ? ? end >> > > > > ? ? ? . >> > > > > >> > > > > {R, V} = apply_each([z,y,x], Arg). >> > > > > if R = ok -> ... >> > > > > >> > > > > I have not much practice in Erlang (though I have some practice in Prolog), so this might not be 100 % correct. >> > > > > >> > > > > Cheers, >> > > > > Jakob >> > > > > >> > > > > Am Mittwoch, 25. Januar 2012 13:16 CET, Joe Armstrong schrieb: >> > > > > >> > > > > > I think you are asking the wrong question. If a function returns >> > > > > > {ok,Val} | {error,Reason} >> > > > > > then I think to myself "the caller of this function expects things to >> > > > > > go wrong and is >> > > > > > committed to handling *both* return values. >> > > > > > >> > > > > > So they would *never* write w(x(y(z(....))) because this does not cater for both >> > > > > > return values. >> > > > > > >> > > > > > With the "let it crash" philosophy one would make w,x,y, .. return a >> > > > > > value OR call exit(...). >> > > > > > With this convention things do nest in the "happy" case without using >> > > > > > a staircase. >> > > > > > >> > > > > > At the top level try or catch is used to catch the error. >> > > > > > >> > > > > > Alternatively you could say >> > > > > > >> > > > > > ? ok({ok,X}) -> X; >> > > > > > ? ok{error,E}) -> exit(E). >> > > > > > >> > > > > > and then >> > > > > > >> > > > > > ? ?w(ok(x(ok(y(ok(z(X)))))) >> > > > > > >> > > > > > Not pretty but it does the job >> > > > > > >> > > > > > /Joe >> > > > > > >> > > > > > >> > > > > > On Tue, Jan 24, 2012 at 8:31 PM, Reynaldo Baquerizo >> > > > > > wrote: >> > > > > > > >> > > > > > > A friend of mine asked: >> > > > > > > >> > > > > > > ## >> > > > > > > If you have functions that return {ok, Result} | {error, Reason} >> > > > > > > how do you chained them? So that you have: >> > > > > > > >> > > > > > > w(x(y(z(...)))) >> > > > > > > >> > > > > > > without building a staircasing. Something that would be done in Haskell >> > > > > > > with monads. >> > > > > > > ## >> > > > > > > >> > > > > > > I would probably go for: >> > > > > > > >> > > > > > > x({ok, Value}) -> >> > > > > > > ?NewValue = , >> > > > > > > ?{ok, NewValue}; >> > > > > > > x({error, Reason}) -> >> > > > > > > ?{error, Reason}. >> > > > > > > >> > > > > > > in each function >> > > > > > > >> > > > > > > which brings me other question, when do you tag return values? >> > > > > > > >> > > > > > > I tend to only use tagged return values with impure functions, were an >> > > > > > > error is more likely due to side effects. >> > > > > > > >> > > > > > > -- >> > > > > > > Reynaldo >> > > > > > > _______________________________________________ >> > > > > > > erlang-questions mailing list >> > > > > > > erlang-questions@REDACTED >> > > > > > > http://erlang.org/mailman/listinfo/erlang-questions >> > > > > > _______________________________________________ >> > > > > > erlang-questions mailing list >> > > > > > erlang-questions@REDACTED >> > > > > > http://erlang.org/mailman/listinfo/erlang-questions >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > _______________________________________________ >> > > > > erlang-questions mailing list >> > > > > erlang-questions@REDACTED >> > > > > http://erlang.org/mailman/listinfo/erlang-questions >> > > > >> > > > >> > > > >> > > > >> > > > >> > > >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > erlang-questions mailing list >> > > erlang-questions@REDACTED >> > > http://erlang.org/mailman/listinfo/erlang-questions >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> >> >> >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From max.lapshin@REDACTED Fri Feb 3 19:57:34 2012 From: max.lapshin@REDACTED (Max Lapshin) Date: Fri, 3 Feb 2012 21:57:34 +0300 Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: References: Message-ID: > > 1) I'm considering writing some nifs that allow me to send UDP > datagrams without going through a mailbox scan. For syslog and > statistics, this would be a perfectly fine thing to do. It was invented about year or more ago for gen_server:call. Instruction like "look for incoming message, but only beginning from mark" From gleber.p@REDACTED Fri Feb 3 20:15:58 2012 From: gleber.p@REDACTED (Gleb Peregud) Date: Fri, 3 Feb 2012 20:15:58 +0100 Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: References: Message-ID: On Fri, Feb 3, 2012 at 19:57, Max Lapshin wrote: >> >> 1) I'm considering writing some nifs that allow me to send UDP >> datagrams without going through a mailbox scan. For syslog and >> statistics, this would be a perfectly fine thing to do. > > > It was invented about year or more ago for gen_server:call. > > Instruction like "look for incoming message, but only beginning from mark" I believe Max means the change done in R14A: OTP-8623 == compiler erts hipe stdlib == Receive statements that can only read out a newly created reference are now specially optimized so that it will execute in constant time regardless of the number of messages in the receive queue for the process. That optimization will benefit calls to gen_server:call(). (See gen:do_call/4 for an example of a receive statement that will be optimized.) From gleber.p@REDACTED Fri Feb 3 20:20:38 2012 From: gleber.p@REDACTED (Gleb Peregud) Date: Fri, 3 Feb 2012 20:20:38 +0100 Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions In-Reply-To: References: <6a2e-4f290080-5-6b8b4580@717786> <1328087849.12502.11.camel@seasc1137> Message-ID: On Fri, Feb 3, 2012 at 19:18, Jon Watte wrote: > The question is: why is the grammar like that? > For people used to first class functions, Erlang doesn't actually live > up to the expectation. > I think there are both runtime efficiency and legacy implementation > reasons for this. > > Note that it's a bit ambiguous what this would mean in the face of code loading: > > F = module:fun > Now, reload "module" > Does F() call the old code, or the new code? I could see an argument > for either way, but the more useful behavior would be to call the new > code. AFAIK in case of fun module:func/X it will call current module version, hence the newest From gleber.p@REDACTED Fri Feb 3 20:22:38 2012 From: gleber.p@REDACTED (Gleb Peregud) Date: Fri, 3 Feb 2012 20:22:38 +0100 Subject: [erlang-questions] erlang api for amazon dynamo db In-Reply-To: References: Message-ID: On Fri, Feb 3, 2012 at 18:30, Joel Reymont wrote: > https://github.com/wagerlabs/ddb > > Kudos to Issuu Aps for allowing me to open source this library! > > FYI, I'm available for consulting effective February 15. It would be awesome if it is integrated into erlcloud project - it seems to be the most comprehensive collection of AWS APIs for Erlang! From joelr1@REDACTED Fri Feb 3 20:29:32 2012 From: joelr1@REDACTED (Joel Reymont) Date: Fri, 3 Feb 2012 19:29:32 +0000 Subject: [erlang-questions] erlang api for amazon dynamo db In-Reply-To: References: Message-ID: I tried that but then took the easy path. Maybe I'll get to it someday or someone else will. On Fri, Feb 3, 2012 at 7:22 PM, Gleb Peregud wrote: > > It would be awesome if it is integrated into erlcloud project - it > seems to be the most comprehensive collection of AWS APIs for Erlang! -- Hardcore embedded Linux development http://www.linkedin.com/in/joelreymont Device drivers, firmware and debugging From king@REDACTED Fri Feb 3 21:20:16 2012 From: king@REDACTED (Benjamin King) Date: Fri, 3 Feb 2012 15:20:16 -0500 Subject: [erlang-questions] Erlang developer position in Sarasota, Florida Message-ID: Title: Erlang Developer Position: Full-time employee **NO contractors** Location: Sarasota, Florida Voalt? is revolutionizing healthcare communication at the point-of-care using the latest mobile devices, such as the iPhone and Android. Watch a demo video of our app. We are improving nurse productivity and patient outcomes by making it easier for nurses to use 1 device to make phone calls, receive critical alarms and send text messages -- voice, alarms, text -- Voalt?! Our servers are running Linux and our application is developed in Erlang using open-source software and standard Internet protocols such as HTTP, XMPP and LDAP. We also do Voice over IP using SIP/RTP. Voalte is looking for an accomplished software developer with at least 1 year of solid Erlang and OTP programming experience. With practical knowledge and understanding of TCP/IP client/server protocols and applications. Any experience with XMPP, LDAP, SIP/RTP is a nice to have. Skills: 1+ year of Erlang and OTP programming TCP/IP client/server protocols (must know HTTP) UNIX/Linux system, networking and scripting experience Team player and good communication with developers, QA and rest of the company To apply go to http://voalte.jobscore.com/jobs/voalte/erlang-developer/d8Qa3ytQir4yDkeJe4bk1X Benjamin King Chief Technology Officer 3665 Bee Ridge Rd, Suite 200 Sarasota, FL 34233 Ph. 941-312-2830 Fax 941-552-8392 Redefining Point-of-Care Communication -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.j.thompson@REDACTED Fri Feb 3 21:40:12 2012 From: s.j.thompson@REDACTED (Simon Thompson) Date: Fri, 3 Feb 2012 20:40:12 +0000 Subject: [erlang-questions] TFPIE: Trends in Functional Programming in Education 2012 Message-ID: <2502E9A0-8C90-430F-BA7A-29BF3EC48632@kent.ac.uk> [Apologies for multiple postings, Simon.] CALL FOR PAPERS/PRESENTATIONS TFPIE 2012 International Workshop on Trends in Functional Programming in Education 2012 June 11 2012 University of St Andrews, Scotland http://www.cs.ru.nl/P.Achten/TFPIE_2012/TFPIE_2012_home.html The first International Workshop on Trends in Functional Programming in Education, TFPIE 2012, will be co-located with TFP 2012 at the University of St Andrews in Scotland. The goal of TFPIE is to gather researchers, professors, teachers, and all professionals that use or are interested in the use of functional programming in education. TFPIE aims to be a venue where novel ideas, classroom-tested ideas, and work in progress on the use of functional programming in education are discussed. The one-day workshop will foster a spirit of open discussion by having a review process for publication after the workshop. The program chairs of TFPIE 2012 will screen submissions to ensure that all presentations are within scope and are of interest to participants. Potential presenters are invited to submit an extended abstract (4-6 pages) or an article (up to 16 pages). The authors of all accepted presentations will have their preprints and their slides made available on the workshop's website/wiki. Any visitors to the TFPIE 2012 website/wiki will be able to add comments. This includes presenters who may respond to comments and questions as well as provide pointers to improvements and follow-up work. After the workshop, the program committee will review, using prevailing academic standards, the articles accepted for presentation to select the best for publication in Electronic Proceedings in Theoretical Computer Science (EPTCS). Articles rejected for presentation and all extended abstracts will not be formally reviewed by the PC. TOPICS OF INTEREST TFPIE 2012 welcomes submissions describing practical techniques used in the classroom, tools used and/or developed, and any creative use of functional programming (FP) to aid education in or outside Computer Science. Topics of interest include, but are not limited to: FP and beginning CS students FP in Artificial Intelligence FP in Robotics FP and Music Advanced FP for undergraduates FP in graduate education Engaging students in research using FP FP in Programming Languages FP in the high school curriculum FP as a stepping stone to other CS topics FP and Philosophy If you are not sure if your work is appropriate for TFPIE 2012, please contact the PC chairs by e-mail at: tfpie2012@REDACTED . Program Committee Peter Achten, Radboud University Nijmegen Jost Berthold, University of Copenhagen Marc Feeley, University of Montreal Ralf Hinze, University of Oxford Shriram Krishnamurthi, Brown University Michel Mauny, ENSTA Paris Tech James McKinna, UK Marco T. Morazan, Seton Hall University Rinus Plasmeijer, Radboud University Nijmegen Simon Thompson, University of Kent Important Dates May 20 submission of abstract or article May 25 notification of acceptance June 11 TFPIE July 6 submission of formal paper September 10 notification of acceptance October 1 camera-ready paper Venue The University of St Andrews is Scotland's first university and the third oldest in the English-speaking world, founded in 1413. Over six centuries it has established a reputation as one of Europe's leading and most distinctive centers for teaching and research. St Andrews is situated on the east coast of Fife, Scotland, UK. The town is approximately 50 miles north-east of Edinburgh, 14 miles south-east of Dundee, 78 miles south of Aberdeen, and 82 miles east of Glasgow making it easily accessible by any means of transportation. Help on traveling to St Andrews can be found at: http://www.st-andrews.ac.uk/visiting/GettingtoStAndrews/ . Questions? If you have any questions, do not hesitate to contact us at: tfpie2012@REDACTED . Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson@REDACTED | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt From avinash@REDACTED Sat Feb 4 06:01:21 2012 From: avinash@REDACTED (Avinash Dhumane) Date: Sat, 4 Feb 2012 10:31:21 +0530 (IST) Subject: [erlang-questions] BCD encoding and decodiing Message-ID: <1328331681.97451.YahooMailNeo@web5603.biz.mail.in.yahoo.com> Can the following encode and decode functions be written without any library calls from modules 'lists' and 'io_lib'? Please show how. The test cases are included at the end. Thanks $ cat bcd.erl -module(bcd). -compile(export_all). % pack the digits of an integer as BCD in a given size of binary % pad with leading zeros encode(N, Size) -> ? << <> || X <- lists:flatten(io_lib:fwrite("~*..0B", [Size*2, N])) >>. % unpack the given size of BCD binary into an integer % strip leading zeros decode(N, Size) -> ? io_lib:fread("~d", [ X+$0 || <> <= <> ]). $ erl Eshell V5.8.3 ?(abort with ^G) 1> c(bcd). {ok,bcd} 2> bcd:encode(1, 5). <<0,0,0,0,1>> 3> bcd:decode(v(2), 5). {ok,[1],[]} 4> bcd:encode(12345, 5). <<0,0,1,35,69>> 5> bcd:decode(v(4), 5). {ok,[12345],[]} 6> bcd:encode(1234567890, 5). <<18,52,86,120,144>> 7> bcd:decode(v(6), 5). {ok,[1234567890],[]} 8>? -------------- next part -------------- An HTML attachment was scrubbed... URL: From per.melin@REDACTED Sat Feb 4 13:05:46 2012 From: per.melin@REDACTED (Per Melin) Date: Sat, 4 Feb 2012 13:05:46 +0100 Subject: [erlang-questions] Lightweight proper code update Message-ID: <15EAFCA3-F30C-46A7-AE19-0FB365849AAE@gmail.com> OTP release management, if you need most of the benefits it offers, can undoubtedly be very useful. But I believe that most of us don't need most of those benefits most of the time, and that all the careful administration it requires can be a hindrance and even a source of errors. Especially if you are running your code in-house and do frequent incremental releases. Unfortunately the next best thing is to restart the node or simply reload the changed modules and hope for the best. I think there is room for something better than that. I've toyed with different solutions and the best I've come up with is an application that does this: 1. Compare the loaded code with the beam files on disk to find modules that have been changed. 2. Use xref to figure out any dependencies between the changed modules (who calls whom). 3. Inspect the modules to separate supervisors, special processes like gen_server, and the rest. 4. Generate a script with appup instructions, based on the previous steps. 5. Use systools to compile this script to a lower level relup script. 6. Ask release handler to execute the low level script. You can find the code here. It is only about 200 lines. https://github.com/permelin/updo With this you don't get named releases or a bundled ERTS, but you do get the same code upgrade process as with a proper release; suspension of special processes, optional update of their states, updated child specs for supervisors, modules are reloaded in a logical order, etc. And it does not require you to keep app and appup files perfectly maintained or jump through any of the hoops otherwise associated with releases. There are however also some potential problems. At the top of my head: - To accomplish steps 5 and 6 I am calling functions in systools and release handler that are exported, but were most likely never intended to be used outside those applications. - xref will not always be able to find all cross-module calls, or do something about circular dependencies. Though I'm not sure it will do a worse job than a human manually writing appup instructions. Any other problems I've missed? Ideas? Questions? Wouldn't something like this be nice to have in OTP? From steven.charles.davis@REDACTED Sat Feb 4 13:29:38 2012 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sat, 4 Feb 2012 04:29:38 -0800 (PST) Subject: [erlang-questions] BCD encoding and decodiing In-Reply-To: <1328331681.97451.YahooMailNeo@web5603.biz.mail.in.yahoo.com> References: <1328331681.97451.YahooMailNeo@web5603.biz.mail.in.yahoo.com> Message-ID: <651898dc-ee33-438a-b4e0-9c8296aae4b6@h6g2000yqk.googlegroups.com> encode(N, Size) -> encode0(N, Size * 2, <<>>). encode0(N, Size, Acc) when Size > 0 -> encode0(N div 10, Size - 1, <<(N rem 10):4, Acc/bits>>); encode0(_, _, Acc) -> Acc. decode(N, Size) -> case byte_size(N) of Size -> decode0(N, 0); _ -> error end. decode0(<>, Acc) -> decode0(Bin, Acc * 10 + X); decode0(<<>>, Acc) -> Acc. ..assuming the "size" argument in decode is a constraint. Not sure you need it. regs, /s On Feb 3, 11:01?pm, Avinash Dhumane wrote: > Can the following encode and decode functions be written without any library calls from modules 'lists' and 'io_lib'? Please show how. The test cases are included at the end. Thanks > > $ cat bcd.erl > -module(bcd). > -compile(export_all). > % pack the digits of an integer as BCD in a given size of binary > % pad with leading zeros > encode(N, Size) -> > ? << <> || X <- lists:flatten(io_lib:fwrite("~*..0B", [Size*2, N])) >>. > % unpack the given size of BCD binary into an integer > % strip leading zeros > decode(N, Size) -> > ? io_lib:fread("~d", [ X+$0 || <> <= <> ]). > > $ erl > Eshell V5.8.3 ?(abort with ^G) > 1> c(bcd). > {ok,bcd} > 2> bcd:encode(1, 5). > <<0,0,0,0,1>> > 3> bcd:decode(v(2), 5). > {ok,[1],[]} > 4> bcd:encode(12345, 5). > <<0,0,1,35,69>> > 5> bcd:decode(v(4), 5). > {ok,[12345],[]} > 6> bcd:encode(1234567890, 5). > <<18,52,86,120,144>> > 7> bcd:decode(v(6), 5). > {ok,[1234567890],[]} > 8> > > _______________________________________________ > erlang-questions mailing list > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions From watson.timothy@REDACTED Sat Feb 4 13:33:29 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Sat, 4 Feb 2012 12:33:29 +0000 Subject: [erlang-questions] Lightweight proper code update In-Reply-To: <15EAFCA3-F30C-46A7-AE19-0FB365849AAE@gmail.com> References: <15EAFCA3-F30C-46A7-AE19-0FB365849AAE@gmail.com> Message-ID: This looks very interesting, I will have a play. I would definitely like to see this kind of thing either move into OTP proper, or be based on supported/documented OTP features - e.g., if the OTP team made the extended API for systools/reltool official. Oh and personally I would prefer updo:dry_run(details) or updo:dry_run(high | low) to updo:dry_run_low, but that's just a matter of taste. ;) Nice work. On 4 February 2012 12:05, Per Melin wrote: > OTP release management, if you need most of the benefits it offers, can > undoubtedly be very useful. > > But I believe that most of us don't need most of those benefits most of > the time, and that all the careful administration it requires can be a > hindrance and even a source of errors. Especially if you are running your > code in-house and do frequent incremental releases. > > Unfortunately the next best thing is to restart the node or simply reload > the changed modules and hope for the best. I think there is room for > something better than that. > > I've toyed with different solutions and the best I've come up with is an > application that does this: > > 1. Compare the loaded code with the beam files on disk to find modules > that have been changed. > 2. Use xref to figure out any dependencies between the changed modules > (who calls whom). > 3. Inspect the modules to separate supervisors, special processes like > gen_server, and the rest. > 4. Generate a script with appup instructions, based on the previous steps. > 5. Use systools to compile this script to a lower level relup script. > 6. Ask release handler to execute the low level script. > > You can find the code here. It is only about 200 lines. > https://github.com/permelin/updo > > With this you don't get named releases or a bundled ERTS, but you do get > the same code upgrade process as with a proper release; suspension of > special processes, optional update of their states, updated child specs for > supervisors, modules are reloaded in a logical order, etc. And it does not > require you to keep app and appup files perfectly maintained or jump > through any of the hoops otherwise associated with releases. > > There are however also some potential problems. At the top of my head: > - To accomplish steps 5 and 6 I am calling functions in systools and > release handler that are exported, but were most likely never intended to > be used outside those applications. > - xref will not always be able to find all cross-module calls, or do > something about circular dependencies. Though I'm not sure it will do a > worse job than a human manually writing appup instructions. > > Any other problems I've missed? Ideas? Questions? Wouldn't something like > this be nice to have in OTP? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebegumisa@REDACTED Sat Feb 4 16:17:15 2012 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Sun, 05 Feb 2012 02:17:15 +1100 Subject: [erlang-questions] XML diff In-Reply-To: References: Message-ID: Also note that there is a proposed standard (RFC 5261) that uses XPath for defining XML patches... http://tools.ietf.org/html/rfc5261 Nokia have an open-source C implementation that does both diff and patch. You could look at that for inspiration... http://sourceforge.net/projects/xmlpatch/ - Edmond - On Wed, 01 Feb 2012 08:45:02 +1100, Roberto Ostinelli wrote: > Dear list, > > I was wandering if there is some available work done in generating XML > files diff, obviously in Erlang but this is a broader question. > > so, for instance, given these two files: > > > > 1 > 2 > > > > and > > > > 1 > 3 > > > > I'd like to be able to generate some kind of diff file stating that entry > with value 2 got removed and entry with value 3 added. > > I do realize this is a generic questions but I'd like to hear any > thoughts > that you might have. > > Thank you, > > r. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From tony@REDACTED Sat Feb 4 16:21:27 2012 From: tony@REDACTED (Tony Rogvall) Date: Sat, 4 Feb 2012 16:21:27 +0100 Subject: [erlang-questions] BCD encoding and decodiing In-Reply-To: <651898dc-ee33-438a-b4e0-9c8296aae4b6@h6g2000yqk.googlegroups.com> References: <1328331681.97451.YahooMailNeo@web5603.biz.mail.in.yahoo.com> <651898dc-ee33-438a-b4e0-9c8296aae4b6@h6g2000yqk.googlegroups.com> Message-ID: Here is a version not using loops, 'case', 'if', io_lib nor lists (just for fun) I put macros here to make the code a bit more readable :-) -define(SIGN(X), ((abs((X)+1) - abs((X)-1)) div 2)). -define(POSITIVEP(X), ((?SIGN((X)) + 1) div 2)). -define(TRUNCD(N,S), ((N) rem trunc(math:pow(10,(S))))). encode(N, Size) when N > 0, Size > 0 -> Bits = << <<(X-$0):4>> || X <- integer_to_list(?TRUNCD(N,Size*2))>>, K = Size*8 - bit_size(Bits), <<0:(K*?POSITIVEP(K)),Bits/bits>>. decode(Bits) -> list_to_integer([X+$0 || <> <= Bits]). /Tony On 4 feb 2012, at 13:29, Steve Davis wrote: > encode(N, Size) -> > encode0(N, Size * 2, <<>>). > > encode0(N, Size, Acc) when Size > 0 -> > encode0(N div 10, Size - 1, <<(N rem 10):4, Acc/bits>>); > encode0(_, _, Acc) -> > Acc. > > decode(N, Size) -> > case byte_size(N) of > Size -> > decode0(N, 0); > _ -> > error > end. > > decode0(<>, Acc) -> > decode0(Bin, Acc * 10 + X); > decode0(<<>>, Acc) -> > Acc. > > ..assuming the "size" argument in decode is a constraint. Not sure you > need it. > > regs, > /s > > On Feb 3, 11:01 pm, Avinash Dhumane wrote: >> Can the following encode and decode functions be written without any library calls from modules 'lists' and 'io_lib'? Please show how. The test cases are included at the end. Thanks >> >> $ cat bcd.erl >> -module(bcd). >> -compile(export_all). >> % pack the digits of an integer as BCD in a given size of binary >> % pad with leading zeros >> encode(N, Size) -> >> << <> || X <- lists:flatten(io_lib:fwrite("~*..0B", [Size*2, N])) >>. >> % unpack the given size of BCD binary into an integer >> % strip leading zeros >> decode(N, Size) -> >> io_lib:fread("~d", [ X+$0 || <> <= <> ]). >> >> $ erl >> Eshell V5.8.3 (abort with ^G) >> 1> c(bcd). >> {ok,bcd} >> 2> bcd:encode(1, 5). >> <<0,0,0,0,1>> >> 3> bcd:decode(v(2), 5). >> {ok,[1],[]} >> 4> bcd:encode(12345, 5). >> <<0,0,1,35,69>> >> 5> bcd:decode(v(4), 5). >> {ok,[12345],[]} >> 6> bcd:encode(1234567890, 5). >> <<18,52,86,120,144>> >> 7> bcd:decode(v(6), 5). >> {ok,[1234567890],[]} >> 8> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questi...@REDACTED://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 ebegumisa@REDACTED Sat Feb 4 17:36:05 2012 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Sun, 05 Feb 2012 03:36:05 +1100 Subject: [erlang-questions] [ANN] Annotations 0.0.2 In-Reply-To: References: Message-ID: Excellent work :) This is really nice to use with the OTP Event Tracer, which I use a lot with macros. Annotations are much cleaner. - Edmond - On Thu, 02 Feb 2012 07:37:37 +1100, Tim Watson wrote: > Still in a very early state, https:://github.com/hyperthunk/annotations > now > supports generating additional functions as well as instrumenting > existing > (i.e., annotated) ones with before/after/around. As an example of how to > use this, I've written up a sample application that can be used to > generate > tedious/boilerplate wrapper functions: > https://github.com/hyperthunk/delegate. > > A typical use of delegate is to remove the need to hand code the named > 'wrapper' functions for this AST builder that produces a generic > representation of applying a 'binary operator': > > -delegate([ > %% pass the generated/target function name > %% in front of the input arguments > {args, ['$T', '$I']}, > %% let the generated function(s) have a different arity > {arity, 2}, > %% generate functions with/for each of these names... > {delegate, [ > "eq", "gt", > "gteq", "lt", > "lteq", "like", > "contains", "starts_with", > "ends_with", "matches", "path_exists" > ]}]). > binop(Op, Axis, {{_,_,_}, _}=Literal) -> > binop(Op, Axis, {literal, Literal}); > binop(Op, Axis, Literal) when is_integer(Literal) orelse > is_float(Literal) orelse > is_list(Literal) orelse > is_record(Literal, semver) -> > binop(Op, Axis, {literal, Literal}); > binop(Op, Axis, {literal, _}=Literal) -> > {Axis, {operator, Op}, Literal}. > > > None of this would be possible without the awesome parse_trans library, > so > a big thank you is due to Ulf for that really killer tool! Roadmap for > 0.0.3 is mainly runtime module/code changes via parse_trans_mod. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From watson.timothy@REDACTED Sat Feb 4 23:30:08 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Sat, 4 Feb 2012 22:30:08 +0000 Subject: [erlang-questions] [ANN] Annotations 0.0.2 In-Reply-To: References: Message-ID: Thanks Edmond. I'm going to simplify the code generation so that the wrapper functions make the call directly rather than via the delegate_advice function, which will make tracing easier. I just need to find a few spare hours! :) On 4 February 2012 16:36, Edmond Begumisa wrote: > Excellent work :) > > This is really nice to use with the OTP Event Tracer, which I use a lot > with macros. Annotations are much cleaner. > > - Edmond - > > On Thu, 02 Feb 2012 07:37:37 +1100, Tim Watson > wrote: > > Still in a very early state, https:://github.com/**hyperthunk/annotationsnow >> supports generating additional functions as well as instrumenting existing >> (i.e., annotated) ones with before/after/around. As an example of how to >> use this, I've written up a sample application that can be used to >> generate >> tedious/boilerplate wrapper functions: >> https://github.com/hyperthunk/**delegate >> . >> >> A typical use of delegate is to remove the need to hand code the named >> 'wrapper' functions for this AST builder that produces a generic >> representation of applying a 'binary operator': >> >> -delegate([ >> %% pass the generated/target function name >> %% in front of the input arguments >> {args, ['$T', '$I']}, >> %% let the generated function(s) have a different arity >> {arity, 2}, >> %% generate functions with/for each of these names... >> {delegate, [ >> "eq", "gt", >> "gteq", "lt", >> "lteq", "like", >> "contains", "starts_with", >> "ends_with", "matches", "path_exists" >> ]}]). >> binop(Op, Axis, {{_,_,_}, _}=Literal) -> >> binop(Op, Axis, {literal, Literal}); >> binop(Op, Axis, Literal) when is_integer(Literal) orelse >> is_float(Literal) orelse >> is_list(Literal) orelse >> is_record(Literal, semver) -> >> binop(Op, Axis, {literal, Literal}); >> binop(Op, Axis, {literal, _}=Literal) -> >> {Axis, {operator, Op}, Literal}. >> >> >> None of this would be possible without the awesome parse_trans library, so >> a big thank you is due to Ulf for that really killer tool! Roadmap for >> 0.0.3 is mainly runtime module/code changes via parse_trans_mod. >> > > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Sun Feb 5 00:13:10 2012 From: tony@REDACTED (Tony Rogvall) Date: Sun, 5 Feb 2012 00:13:10 +0100 Subject: [erlang-questions] BCD encoding and decodiing In-Reply-To: References: <1328331681.97451.YahooMailNeo@web5603.biz.mail.in.yahoo.com> <651898dc-ee33-438a-b4e0-9c8296aae4b6@h6g2000yqk.googlegroups.com> Message-ID: <23E958A2-2489-468B-A93D-213DA4AC60F4@rogvall.se> Found a better one-liner for encode. Also fixed that N >= 0! (Still would like to replace the math:pow with something better) encode(N, S) when N >= 0, S > 0 -> << <<(X-$0):4>> || X <- tl(integer_to_list(trunc(math:pow(10,S*2)) + (N rem trunc(math:pow(10,S*2))))) >>. /Tony On 4 feb 2012, at 16:21, Tony Rogvall wrote: > Here is a version not using loops, 'case', 'if', io_lib nor lists (just for fun) > I put macros here to make the code a bit more readable :-) > > -define(SIGN(X), ((abs((X)+1) - abs((X)-1)) div 2)). > -define(POSITIVEP(X), ((?SIGN((X)) + 1) div 2)). > -define(TRUNCD(N,S), ((N) rem trunc(math:pow(10,(S))))). > > encode(N, Size) when N > 0, Size > 0 -> > Bits = << <<(X-$0):4>> || X <- integer_to_list(?TRUNCD(N,Size*2))>>, > K = Size*8 - bit_size(Bits), > <<0:(K*?POSITIVEP(K)),Bits/bits>>. > > > decode(Bits) -> > list_to_integer([X+$0 || <> <= Bits]). > > /Tony > > On 4 feb 2012, at 13:29, Steve Davis wrote: > >> encode(N, Size) -> >> encode0(N, Size * 2, <<>>). >> >> encode0(N, Size, Acc) when Size > 0 -> >> encode0(N div 10, Size - 1, <<(N rem 10):4, Acc/bits>>); >> encode0(_, _, Acc) -> >> Acc. >> >> decode(N, Size) -> >> case byte_size(N) of >> Size -> >> decode0(N, 0); >> _ -> >> error >> end. >> >> decode0(<>, Acc) -> >> decode0(Bin, Acc * 10 + X); >> decode0(<<>>, Acc) -> >> Acc. >> >> ..assuming the "size" argument in decode is a constraint. Not sure you >> need it. >> >> regs, >> /s >> >> On Feb 3, 11:01 pm, Avinash Dhumane wrote: >>> Can the following encode and decode functions be written without any library calls from modules 'lists' and 'io_lib'? Please show how. The test cases are included at the end. Thanks >>> >>> $ cat bcd.erl >>> -module(bcd). >>> -compile(export_all). >>> % pack the digits of an integer as BCD in a given size of binary >>> % pad with leading zeros >>> encode(N, Size) -> >>> << <> || X <- lists:flatten(io_lib:fwrite("~*..0B", [Size*2, N])) >>. >>> % unpack the given size of BCD binary into an integer >>> % strip leading zeros >>> decode(N, Size) -> >>> io_lib:fread("~d", [ X+$0 || <> <= <> ]). >>> >>> $ erl >>> Eshell V5.8.3 (abort with ^G) >>> 1> c(bcd). >>> {ok,bcd} >>> 2> bcd:encode(1, 5). >>> <<0,0,0,0,1>> >>> 3> bcd:decode(v(2), 5). >>> {ok,[1],[]} >>> 4> bcd:encode(12345, 5). >>> <<0,0,1,35,69>> >>> 5> bcd:decode(v(4), 5). >>> {ok,[12345],[]} >>> 6> bcd:encode(1234567890, 5). >>> <<18,52,86,120,144>> >>> 7> bcd:decode(v(6), 5). >>> {ok,[1234567890],[]} >>> 8> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questi...@REDACTED://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 "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 stu.bailey@REDACTED Sun Feb 5 04:15:06 2012 From: stu.bailey@REDACTED (Stu Bailey) Date: Sat, 4 Feb 2012 19:15:06 -0800 Subject: [erlang-questions] XML diff In-Reply-To: <3D88AA58-1851-459D-96D9-E1D64DD93BB2@cs.otago.ac.nz> References: <3D88AA58-1851-459D-96D9-E1D64DD93BB2@cs.otago.ac.nz> Message-ID: If you are interested in papers you might want to consult: Sebastian R?nnau, Geraint Philipp, and Uwe M. Borghoff. 2009. Efficient change control of XML documents. In Proceedings of the 9th ACM symposium on Document engineering (DocEng '09). ACM, New York, NY, USA, 3-12. DOI=10.1145/1600193.1600197 http://doi.acm.org/10.1145/1600193.1600197 Stu On Tue, Jan 31, 2012 at 7:27 PM, Richard O'Keefe wrote: > Look at > http://www.cs.umd.edu/Outreach/hsContest99/questions/node8.html > and follow the "Our Solution" link. > which refers to Stanley Selkow's paper in > Information Processing Letters, Volume 6, number 6, 1977. > > There's a paper by Wuu Yang in Software Practice and > Experience, ?Volume 21, issue 7, 739-755 (July 1991), > called "Identifying Syntactic Differences Between Two Programs" > which works by finding differences between their parse trees. > > There's a Perl module for precisely this task at > http://search.cpan.org/~sdether/XML-Diff-0.04/Diff.pm > The documentation points to Gregory Cobena's PhD thesis > which can be found through at > http://gregory.cobena.free.fr/www/Publications/thesis.html > I haven't read that, but it has a chapter comparing several > algorithms. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From jakob@REDACTED Sun Feb 5 18:49:04 2012 From: jakob@REDACTED (Jakob Praher) Date: Sun, 05 Feb 2012 18:49:04 +0100 Subject: [erlang-questions] Closure on named function as values Message-ID: <4F2EC110.4020905@praher.info> Dear Erlangers, this is a closure on my posts on function references. First of all I think Erlang is an amazing language and I am happy to be studying it in more detail. I really enjoy writing Erlang code. I find it funny that in retrospect the discussion seems to confirm Wadler's law of language design[1]: people tend to spend 8-times the amount of the time used for discussing semantics on discussing the lexical syntax of comments :-) To my defense I was not so much interested in the concrete syntax but in the fact that I found it unintuitive how to pass a named function as a value. I was thinking more about the operational aspects. Applying a function consists of evaluating the body of the matching function clause. In this procedure the arity to me is just as important as any other aspect of the argument values passed. For instance map/2 in [2] still refers to two possible function clause bodies. This said I am happy, if you can point me to some good papers or source code spots about the implementation of erl/beam. I will definitely dig more into the Core Erlang spec [3]. Happy hacking, Jakob [1] - http://www.haskell.org/haskellwiki/Wadlers_Law [2] - http://www.erlang.org/doc/programming_examples/funs.html [3] - http://www.it.uu.se/research/group/hipe/cerl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimenezrick@REDACTED Sun Feb 5 21:59:21 2012 From: jimenezrick@REDACTED (Ricardo Catalinas =?iso-8859-1?Q?Jim=E9nez?=) Date: Sun, 5 Feb 2012 21:59:21 +0100 Subject: [erlang-questions] EDoc prints: function connect/2: at line 101: multiple @spec tag Message-ID: <20120205205921.GM897@viper.local> Hi, I'm using EDoc to extract the exported functions and their types from the modules in order to do omni completion in my Vim Erlang plugin[1]. But EDoc gives me the next error in the `ssl' module: function start/0: at line 73: multiple @spec tag. The issue is that the spec declarations aren't exactly above the function they specify. The code in question is pasted below. Is there any workaround for using EDoc in modules with the specs written in this way? Regards [1] http://github.com/jimenezrick/vimerl ---8<------------------------------------------------------------------- -spec start() -> ok | {error, reason()}. -spec start(permanent | transient | temporary) -> ok | {error, reason()}. start() -> application:start(crypto), application:start(public_key), application:start(ssl). start(Type) -> application:start(crypto, Type), application:start(public_key, Type), application:start(ssl, Type). ---8<------------------------------------------------------------------- -- Ricardo (http://r.untroubled.be/) From carlsson.richard@REDACTED Sun Feb 5 22:15:43 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Sun, 05 Feb 2012 22:15:43 +0100 Subject: [erlang-questions] add compiler checked atoms Message-ID: <4F2EF17F.3020006@gmail.com> Sorry, pressed send too soon in the last attempt. Here is the code: git fetch git@REDACTED:richcarl/otp.git warn-unknown-atom Here is a suggested patch to the compiler, that I'm throwing out there as a request for comments. In any large code base, it can be hard to maintain atom hygiene - you may have hidden errors due to misspelled atoms, people may be adding atoms without much thought, and it can be hard to track which atoms are being used where and for what (e.g., atoms used for options, error indicators, message tags, callback module and function names, etc. This allows you to declare your atoms like so: -atoms([foo, bar]). You can have any number of such declarations, and an atom may occur multiple times and/or in different declarations - it's the union of known atoms that matters. Note that this declaration is backwards compatible; the current compiler will accept it as a generic attribute with no particular meaning. If you specify the compiler option `warn_unused_atom' when compiling a module (you can put `-compile([warn_unused_atom]).' in the module if you want to enable the checking in that module only), you will get a warning for each atom that has not been explicitly declared. The compiler knows about standard atoms such as `ok', `true', `false', `undefined' etc., and it does not check function and module names in calls, or record names and fields of records, since these are checked in other ways already. I don't think this addition warrants an EEP, since it doesn't change the language as such; it only adds a backwards compatible feature to the compiler. However, I'd like to get some initial feedback before I bother to update the documentation and submit it as a full patch. git@REDACTED:richcarl/otp.git /Richard From carlsson.richard@REDACTED Sun Feb 5 22:23:12 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Sun, 05 Feb 2012 22:23:12 +0100 Subject: [erlang-questions] add compiler checked atoms In-Reply-To: <4F2EF17F.3020006@gmail.com> References: <4F2EF17F.3020006@gmail.com> Message-ID: <4F2EF340.8000505@gmail.com> On 02/05/2012 10:15 PM, Richard Carlsson wrote: > If you specify the compiler option `warn_unused_atom' when compiling a > module (you can put `-compile([warn_unused_atom]).' in the module if you > want to enable the checking in that module only), you will get a warning > for each atom that has not been explicitly declared. I'm obviously too tired; that should be `warn_unknown_atom'. /Richard From mjtruog@REDACTED Sun Feb 5 22:34:45 2012 From: mjtruog@REDACTED (Michael Truog) Date: Sun, 05 Feb 2012 13:34:45 -0800 Subject: [erlang-questions] [erlang-patches] add compiler checked atoms In-Reply-To: <4F2EF17F.3020006@gmail.com> References: <4F2EF17F.3020006@gmail.com> Message-ID: <4F2EF5F5.10206@gmail.com> This is very cool. It could help document complex code by making atom usage more transparent within the module, while also preventing errors. I mention the documentation part, since having the atom declaration gives the opportunity for comments specific to that atom declaration (so you could have atom declarations as logical groupings, similar to what is commonly done for export declarations). Do atoms used within the spec declarations need to be mentioned within the atom declaration when using this compiler flag? That might bring in a lot of external module atom dependencies, which might be counter-productive. On 02/05/2012 01:15 PM, Richard Carlsson wrote: > Sorry, pressed send too soon in the last attempt. Here is the code: > > git fetch git@REDACTED:richcarl/otp.git warn-unknown-atom > > Here is a suggested patch to the compiler, that I'm throwing out there as a request for comments. In any large code base, it can be hard to maintain atom hygiene - you may have hidden errors due to misspelled atoms, people may be adding atoms without much thought, and it can be hard to track which atoms are being used where and for what (e.g., atoms used for options, error indicators, message tags, callback module and function names, etc. This allows you to declare your atoms like so: > > -atoms([foo, bar]). > > You can have any number of such declarations, and an atom may occur multiple times and/or in different declarations - it's the union of known atoms that matters. Note that this declaration is backwards compatible; the current compiler will accept it as a generic attribute with no particular meaning. > > If you specify the compiler option `warn_unused_atom' when compiling a module (you can put `-compile([warn_unused_atom]).' in the module if you want to enable the checking in that module only), you will get a warning for each atom that has not been explicitly declared. The compiler knows about standard atoms such as `ok', `true', `false', `undefined' etc., and it does not check function and module names in calls, or record names and fields of records, since these are checked in other ways already. > > I don't think this addition warrants an EEP, since it doesn't change the language as such; it only adds a backwards compatible feature to the compiler. However, I'd like to get some initial feedback before I bother to update the documentation and submit it as a full patch. > > git@REDACTED:richcarl/otp.git > > /Richard > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > From carlsson.richard@REDACTED Sun Feb 5 22:57:19 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Sun, 05 Feb 2012 22:57:19 +0100 Subject: [erlang-questions] [erlang-patches] add compiler checked atoms In-Reply-To: <4F2EF5F5.10206@gmail.com> References: <4F2EF17F.3020006@gmail.com> <4F2EF5F5.10206@gmail.com> Message-ID: <4F2EFB3F.2040204@gmail.com> On 02/05/2012 10:34 PM, Michael Truog wrote: > This is very cool. It could help document complex code by making > atom usage more transparent within the module, while also preventing > errors. I mention the documentation part, since having the atom > declaration gives the opportunity for comments specific to that atom > declaration (so you could have atom declarations as logical > groupings, similar to what is commonly done for export declarations). > Do atoms used within the spec declarations need to be mentioned > within the atom declaration when using this compiler flag? That > might bring in a lot of external module atom dependencies, which > might be counter-productive. No, atoms occurring in -spec and -type declarations are not checked. As you say, that could force you to declare a lot more atoms than you want. You'll have to run Dialyzer to check the consistency of specs. What you mention about groupings of atoms is exactly the sort of thing I had in mind. Here are some examples from eunit, which I used as a test bed for this feature: %% used in options -atoms([verbose, report, no_tty, event_log, enqueue, eunit_test_suffix, eunit_generator_suffix, eunit_export_suffix]). %% atoms used in test representations -atoms([module, application, file, dir, generator, with, local, spawn, local, remote, timeout, inorder, inparallel, setup, node, foreach, foreachx]). %% used by erlang:fun_info/2 -atoms([module, name, type, local, external, arity]). %% used in I/O stream messages -atoms([io_request, io_reply, put_chars, get_chars, get_line, get_until, eof, getopts, setopts, get_geometry, columns, rows, enotsup, requests, request]). %% used in file_monitor server messages -atoms([monitor, demonitor, automonitor, set_interval, get_interval, stop, poll, enable_poll]). Some of these, you'd put in some header file shared between several of your modules, but atoms only used in one module should be declared in that module, to keep the checking as tight as possible. The explicit declaration and grouping of atoms makes it easy to find which modules actually use a particular atom, and for what. This can otherwise be very hard to figure out. If you've ever tried to use grep to find all places in stdlib where the atom `gen' occurs in the gen_... modules (it's hardcoded at various points as a callback module name), you know the sort of pain I'm talking about. /Richard From dmkolesnikov@REDACTED Mon Feb 6 00:03:58 2012 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Mon, 6 Feb 2012 01:03:58 +0200 Subject: [erlang-questions] pts for erlang Message-ID: <8FD72946-6DD5-4FDA-BDA4-14C4E5168164@gmail.com> I have been constantly fighting with the issue about exchanging status data and statistic between master and worker processes. I mean there is not rocket science but different projects where using different flavor (some used shared memory, some async message passing), etc. Finally, I decided to consolidate that into generalized a project https://github.com/fogfish/pts The library provides hashtable-like interface to manipulate data distributed across Erlang processes. Let me know your thought on the issue, any use for the solution, etc. BR, Dmitry From jesper.louis.andersen@REDACTED Mon Feb 6 10:42:14 2012 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 06 Feb 2012 10:42:14 +0100 Subject: [erlang-questions] pts for erlang In-Reply-To: <8FD72946-6DD5-4FDA-BDA4-14C4E5168164@gmail.com> References: <8FD72946-6DD5-4FDA-BDA4-14C4E5168164@gmail.com> Message-ID: <4F2FA076.9040003@erlang-solutions.com> On 2/6/12 12:03 AM, Dmitry Kolesnikov wrote: > I have been constantly fighting with the issue about exchanging status data and statistic between master and worker processes. I mean there is not rocket science but different projects where using different flavor (some used shared memory, some async message passing), etc. > > GProc does this kind of thing too for simple properties. But the approach is probably a bit more light weight than what you had in mind. Gproc is using ETS to store its data, whereas it looks like you are using a process for the same thing. So the scope is different. Just a heads up on alternative approaches. -- Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen, DK From hynek@REDACTED Mon Feb 6 11:52:26 2012 From: hynek@REDACTED (Hynek Vychodil) Date: Mon, 6 Feb 2012 11:52:26 +0100 Subject: [erlang-questions] BCD encoding and decodiing In-Reply-To: <23E958A2-2489-468B-A93D-213DA4AC60F4@rogvall.se> References: <1328331681.97451.YahooMailNeo@web5603.biz.mail.in.yahoo.com> <651898dc-ee33-438a-b4e0-9c8296aae4b6@h6g2000yqk.googlegroups.com> <23E958A2-2489-468B-A93D-213DA4AC60F4@rogvall.se> Message-ID: Another possible solution: -module(bcd). -compile(export_all). % pack the digits of an integer as BCD in a given size of binary % pad with leading zeros encode(N, Size) -> ? encode(N, Size, []). encode(_, 0, Acc) -> list_to_binary(Acc); encode(N, Size, Acc) -> ? B ?= N ?rem 10, ? N1 = N ?div 10, ? A ?= N1 rem 10, ? N2 = N1 div 10, ? encode(N2, Size - 1, [(A bsl 4) + B | Acc]). % unpack the given size of BCD binary into an integer % strip leading zeros decode(N, Size) when size(N) =:= Size -> ? decode(N). decode(<<>>) -> "0"; decode(<<0,Rest/binary>>) -> decode(Rest); decode(<<0:4,X:4,Rest/binary>>) -> ? [$0 + X | decode_(Rest)]; decode(N) -> decode_(N). decode_(N) -> ? [ $0+X || ?<> <= N ]. On Sun, Feb 5, 2012 at 12:13 AM, Tony Rogvall wrote: > Found a better one-liner for encode. Also fixed that N >= 0! > (Still would like to replace the math:pow with something better) > > encode(N, S) when N >= 0, S > 0 -> > ? ? << <<(X-$0):4>> || X <- tl(integer_to_list(trunc(math:pow(10,S*2)) + (N > rem trunc(math:pow(10,S*2))))) >>. > > /Tony > > On 4 feb 2012, at 16:21, Tony Rogvall wrote: > > Here is a version not using loops, 'case', 'if', io_lib nor lists (just for > fun) > I put macros here to make the code a bit more readable :-) > > -define(SIGN(X), ((abs((X)+1) - abs((X)-1)) div 2)). > -define(POSITIVEP(X), ((?SIGN((X)) + 1) div 2)). > -define(TRUNCD(N,S), ((N) rem trunc(math:pow(10,(S))))). > > encode(N, Size) when N > 0, Size > 0 -> > ? ? Bits = << <<(X-$0):4>> || X <- integer_to_list(?TRUNCD(N,Size*2))>>, > ? ? K = Size*8 - bit_size(Bits), > ? ? <<0:(K*?POSITIVEP(K)),Bits/bits>>. > > > decode(Bits) -> > ? ? list_to_integer([X+$0 || <> <= Bits]). > > /Tony > > On 4 feb 2012, at 13:29, Steve Davis wrote: > > encode(N, Size) -> > encode0(N, Size * 2, <<>>). > > encode0(N, Size, Acc) when Size > 0 -> > encode0(N div 10, Size - 1, <<(N rem 10):4, Acc/bits>>); > encode0(_, _, Acc) -> > Acc. > > decode(N, Size) -> > case byte_size(N) of > Size -> > decode0(N, 0); > _ -> > error > end. > > decode0(<>, Acc) -> > decode0(Bin, Acc * 10 + X); > decode0(<<>>, Acc) -> > Acc. > > ..assuming the "size" argument in decode is a constraint. Not sure you > need it. > > regs, > /s > > On Feb 3, 11:01?pm, Avinash Dhumane wrote: > > Can the following encode and decode functions be written without any library > calls from modules 'lists' and 'io_lib'? Please show how. The test cases are > included at the end. Thanks > > > $ cat bcd.erl > > -module(bcd). > > -compile(export_all). > > % pack the digits of an integer as BCD in a given size of binary > > % pad with leading zeros > > encode(N, Size) -> > > ? << <> || X <- lists:flatten(io_lib:fwrite("~*..0B", [Size*2, N])) >>. > > % unpack the given size of BCD binary into an integer > > % strip leading zeros > > decode(N, Size) -> > > ? io_lib:fread("~d", [ X+$0 || <> <= <> ]). > > > $ erl > > Eshell V5.8.3 ?(abort with ^G) > > 1> c(bcd). > > {ok,bcd} > > 2> bcd:encode(1, 5). > > <<0,0,0,0,1>> > > 3> bcd:decode(v(2), 5). > > {ok,[1],[]} > > 4> bcd:encode(12345, 5). > > <<0,0,1,35,69>> > > 5> bcd:decode(v(4), 5). > > {ok,[12345],[]} > > 6> bcd:encode(1234567890, 5). > > <<18,52,86,120,144>> > > 7> bcd:decode(v(6), 5). > > {ok,[1234567890],[]} > > 8> > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questi...@REDACTED://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 > > > "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 > -- Hynek Vychodil BI consultant GoodData n?m?st? 28. ??jna 1104/17, 602 00, Brno - ?ern? Pole Office: ? +420 530 50 7704 E-mail: ?hynek@REDACTED Web: ? ? www.gooddata.com From mfidelman@REDACTED Mon Feb 6 16:11:24 2012 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 06 Feb 2012 10:11:24 -0500 Subject: [erlang-questions] looking for good tutorials (newbie) Message-ID: <4F2FED9C.9070901@meetinghouse.net> Hi Folks, I'm struggling through the process of learning Erlang, and I'm wondering if anybody can point to some favorite tutorials. Not so much the basics (functional programming, tail recursion - which takes time to wrap one's head around, but is fairly tractable) but more at the application development level - how to conceptualize a problem from a concurrent point-of-few (vs. a procedural or object-oriented view), and then proceed through development, test, packaging, and deployment. There's lots of stuff like that for object-oriented practice, but not-so-much for Erlang. There's some pretty good stuff in both Armstrong's book, and in the book by Cesarini and Thompson - but I'd really like to find something that works through the nitty gritty from problem statement -> top level design (what processes, protocols, etc.) -> code -> debugging -> packaging -- with a graphical presentation (maybe it's just me, but when thinking about concurrency, pictures of interacting processes and message flows works a lot better than sequential, textual presentation of code snippets). Also details of how to use different tools to debug parallel interactions. The User's Guides and Reference Manuals are well and good - but more useful after you know what you're looking for - not as useful for thinking through a test/debug strategy, or an approach to a specific crash. In the Smalltalk world, I came across this: http://squeak.preeminent.org/tut2007/html/ -- wondering if anybody has seen something comparable for Erlang. So... just wondering if anybody has seen a good powerpoint deck or two along these lines. Thanks very much, Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From daniel.widgren@REDACTED Mon Feb 6 16:13:04 2012 From: daniel.widgren@REDACTED (Daniel Widgren) Date: Mon, 6 Feb 2012 16:13:04 +0100 Subject: [erlang-questions] looking for good tutorials (newbie) In-Reply-To: <4F2FED9C.9070901@meetinghouse.net> References: <4F2FED9C.9070901@meetinghouse.net> Message-ID: http://learnyousomeerlang.com/content Is a good tutorial for learning Erlang. / Daniel Den 6 februari 2012 16:11 skrev Miles Fidelman : > Hi Folks, > > I'm struggling through the process of learning Erlang, and I'm wondering if > anybody can point to some favorite tutorials. > > Not so much the basics (functional programming, tail recursion - which takes > time to wrap one's head around, but is fairly tractable) but more at the > application development level - how to conceptualize a problem from a > concurrent point-of-few (vs. a procedural or object-oriented view), and then > proceed through development, test, packaging, and deployment. ?There's lots > of stuff like that for object-oriented practice, but not-so-much for Erlang. > > There's some pretty good stuff in both Armstrong's book, and in the book by > Cesarini and Thompson - but I'd really like to find something that works > through the nitty gritty from problem statement -> top level design (what > processes, protocols, etc.) -> code -> debugging -> packaging -- with a > graphical presentation (maybe it's just me, but when thinking about > concurrency, pictures of interacting processes and message flows works a lot > better than sequential, textual presentation of code snippets). > > Also details of how to use different tools to debug parallel interactions. > ?The User's Guides and Reference Manuals are well and good - but more useful > after you know what you're looking for - not as useful for thinking through > a test/debug strategy, or an approach to a specific crash. > > In the Smalltalk world, I came across this: > http://squeak.preeminent.org/tut2007/html/ -- wondering if anybody has seen > something comparable for Erlang. > > So... just wondering if anybody has seen a good powerpoint deck or two along > these lines. > > Thanks very much, > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. ? .... Yogi Berra > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From zabrane3@REDACTED Mon Feb 6 16:11:36 2012 From: zabrane3@REDACTED (Zabrane Mickael) Date: Mon, 6 Feb 2012 16:11:36 +0100 Subject: [erlang-questions] looking for good tutorials (newbie) In-Reply-To: References: <4F2FED9C.9070901@meetinghouse.net> Message-ID: http://learnyousomeerlang.com/ Regards, Zabrane On Feb 6, 2012, at 4:13 PM, Daniel Widgren wrote: > http://learnyousomeerlang.com/content > > Is a good tutorial for learning Erlang. > > / Daniel > > Den 6 februari 2012 16:11 skrev Miles Fidelman : >> Hi Folks, >> >> I'm struggling through the process of learning Erlang, and I'm wondering if >> anybody can point to some favorite tutorials. >> >> Not so much the basics (functional programming, tail recursion - which takes >> time to wrap one's head around, but is fairly tractable) but more at the >> application development level - how to conceptualize a problem from a >> concurrent point-of-few (vs. a procedural or object-oriented view), and then >> proceed through development, test, packaging, and deployment. There's lots >> of stuff like that for object-oriented practice, but not-so-much for Erlang. >> >> There's some pretty good stuff in both Armstrong's book, and in the book by >> Cesarini and Thompson - but I'd really like to find something that works >> through the nitty gritty from problem statement -> top level design (what >> processes, protocols, etc.) -> code -> debugging -> packaging -- with a >> graphical presentation (maybe it's just me, but when thinking about >> concurrency, pictures of interacting processes and message flows works a lot >> better than sequential, textual presentation of code snippets). >> >> Also details of how to use different tools to debug parallel interactions. >> The User's Guides and Reference Manuals are well and good - but more useful >> after you know what you're looking for - not as useful for thinking through >> a test/debug strategy, or an approach to a specific crash. >> >> In the Smalltalk world, I came across this: >> http://squeak.preeminent.org/tut2007/html/ -- wondering if anybody has seen >> something comparable for Erlang. >> >> So... just wondering if anybody has seen a good powerpoint deck or two along >> these lines. >> >> Thanks very much, >> >> Miles Fidelman >> >> -- >> In theory, there is no difference between theory and practice. >> In practice, there is. .... Yogi Berra -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Mon Feb 6 16:35:19 2012 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 06 Feb 2012 10:35:19 -0500 Subject: [erlang-questions] looking for good tutorials (newbie) In-Reply-To: References: <4F2FED9C.9070901@meetinghouse.net> Message-ID: <4F2FF337.3040804@meetinghouse.net> Zabrane and Daniel... thanks for the pointers to learnyousomeerlang.com. The thing is, that's what I'm working through now. I'm hoping to find something that goes the next step, into more details - particularly re. both conceptualizing and debugging highly concurrent applications. Thanks, Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From james@REDACTED Mon Feb 6 16:45:31 2012 From: james@REDACTED (James Aimonetti) Date: Mon, 6 Feb 2012 07:45:31 -0800 Subject: [erlang-questions] looking for good tutorials (newbie) In-Reply-To: <4F2FF337.3040804@meetinghouse.net> References: <4F2FED9C.9070901@meetinghouse.net> <4F2FF337.3040804@meetinghouse.net> Message-ID: <4F2FF59B.4090207@2600hz.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OTP in Action: http://manning.com/logan/ Well written book covering a lot of the ground you're looking for, I think. On 02/06/2012 07:35 AM, Miles Fidelman wrote: > Zabrane and Daniel... thanks for the pointers to learnyousomeerlang.com. > > The thing is, that's what I'm working through now. I'm hoping to find > something that goes the next step, into more details - particularly re. > both conceptualizing and debugging highly concurrent applications. > > Thanks, > > Miles > > - -- James Aimonetti Distributed Systems Engineer / DJ MC_ 2600hz | http://2600hz.com sip:james@REDACTED tel: 415.886.7905 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPL/WbAAoJENc77s1OYoGgKUUIAKAccaMTppJNv39/X5WDGvKp 7sMrq9K/aT8pnkBFR2EKJ/PaFE1MEQIGJ1cKGRIdeaJ2XYjZ1SRjZjvL5UiWndoR DZbSRf8d1YJFZqiObLc8KWsikQn/B4TXYsJXTis3KFx6OgBWsV0uJiIDRqbw7deL nEk6C3hBsrt5AT7ZIt7l/itmEnI09D3fcAa2Hy4w00BW6J6ALMseUdN6SZC11Uh6 GF2/9XtOp22enytg5x1J8sAqa1rkWe5Cy0z/wDGNba45cJfdPLVxh0LeTaa6c4gk 98OVHd9NjmBUQXfP7jEGT8WYCTMOpLRsQASPMz2mcMudj4ifruNPbb9nyqvgThQ= =G1Xh -----END PGP SIGNATURE----- From jesper.louis.andersen@REDACTED Mon Feb 6 17:24:43 2012 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 06 Feb 2012 17:24:43 +0100 Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions In-Reply-To: <4aaf-4f28f200-3-4452b880@168192673> References: <4aaf-4f28f200-3-4452b880@168192673> Message-ID: <4F2FFECB.3030402@erlang-solutions.com> On 2/1/12 9:05 AM, Jakob Praher wrote: > Hi Erlangers, > > I think people should pay attention to issues faced by experienced newcomers in exercising Erlang programming. Matz from Ruby calls a ver important design principle, the principle of least surprise. > > This is a good principle, but Ruby does not heed it: http://stackoverflow.com/questions/372652/what-are-the-ruby-gotchas-a-newbie-should-be-warned-about My personal favorite is this simple one: def a 7 + 7 end versus def b 7 + 7 end The a function returns 7 because the first 7 is produced as a side effect and the line '+ 7' evaluates to 7. The b function on the other hand produces an incomplete expression with 7 + and then adds 7 to it, returning 14 as you would expect. Note that in Erlang, where the grammar is more well-defined, there is no such distinction (note though that this is Ruby 1.8.7 - it may have been fixed in later ruby versions). That is the reason for the prefixed 'fun' in Erlang: It makes the grammar unambiguous, like Richard O'Keefe mention - such that things like the above cannot occur. -- Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen, DK From jose.valim@REDACTED Mon Feb 6 17:34:39 2012 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Mon, 6 Feb 2012 17:34:39 +0100 Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions In-Reply-To: <4F2FFECB.3030402@erlang-solutions.com> References: <4aaf-4f28f200-3-4452b880@168192673> <4F2FFECB.3030402@erlang-solutions.com> Message-ID: > > This is a good principle, but Ruby does not heed it: > > http://stackoverflow.com/**questions/372652/what-are-the-** > ruby-gotchas-a-newbie-should-**be-warned-about Matz, the creator of Ruby, once said that the "Principle of Least Surprise" applies to *him* and every person has different "surprises" since they expect different things based on their past experience. It was not Matz that came up with the term. For this reason, he said explicitly on Ruby mailing list that a developer should never use this "principle" to persuade him to add/remove/change a feature. And I hope the same applies here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oribrost@REDACTED Mon Feb 6 17:43:02 2012 From: oribrost@REDACTED (ori brost) Date: Mon, 6 Feb 2012 18:43:02 +0200 Subject: [erlang-questions] Trie NIFs Message-ID: I'm looking for a trie NIF library that can support strings as trie tokens, and basic pattern matching with a '.' like wildcard (i.e. If / is the trie separator and the tree contains 3 entries: /usr/bin, /usr/include/X12/XTrans, /usr/include/X11/Xtrans, then I can do trie:get_all(["usr", "include", '.', "XTrans"]) and it will return [["usr","include","X11","Xtrans"], ["usr","include","X12","Xtrans"]] It would also be nice to have a trie:get_single(["usr","include", '.', "XTrans"]) that returns only one of the matching entries Does anyone know of such a NIF library? Or something similar enough that I can modify it for these needs? Regards, OriB. From mattevans123@REDACTED Mon Feb 6 17:52:30 2012 From: mattevans123@REDACTED (Matthew Evans) Date: Mon, 6 Feb 2012 11:52:30 -0500 Subject: [erlang-questions] What is best practice (records/tupples)? Message-ID: Hi, Given something like: -record(my_record, {aaa,? ? ? ? ? ? ? ? ? ? bbb,? ? ? ? ? ? ? ? ? ? ccc,? ? ? ? ? ? ? ? ? ? ddd}). What is more efficient, and what is best practice?? This - some_function(#my_record{aaa = AAA, bbb = BBB, ddd = DDD} = _MyRecord) ->? ? % Some work Or this - some_function(MyRecord) ->? ? AAA = MyRecord#my_record.aaa,? ? BBB = MyRecord#my_record.bbb,? ? DDD = MyRecord#my_record.ccc,? ? % Some work I've always thought that the first example is best. Or does the compiler do some kind of trickery? Does it make any difference if you only need a few vs. all the variables from the record? Thanks Matt From per.melin@REDACTED Mon Feb 6 18:03:46 2012 From: per.melin@REDACTED (Per Melin) Date: Mon, 6 Feb 2012 18:03:46 +0100 Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions In-Reply-To: <4F2FFECB.3030402@erlang-solutions.com> References: <4aaf-4f28f200-3-4452b880@168192673> <4F2FFECB.3030402@erlang-solutions.com> Message-ID: <5135AECD-96BC-4C27-9F18-4543E374BB80@gmail.com> > This is a good principle, but Ruby does not heed it: If we're going to pick on Ruby I think you can find several examples closer to what this thread is about. f = lambda { 4711 } f() NoMethodError: undefined method `f' for main:Object f.call() 4711 Least surprise? From freza@REDACTED Mon Feb 6 18:05:44 2012 From: freza@REDACTED (Jachym Holecek) Date: Mon, 6 Feb 2012 12:05:44 -0500 Subject: [erlang-questions] Orthogonality and Principle of least surprise Was: chained functions In-Reply-To: References: <4aaf-4f28f200-3-4452b880@168192673> <4F2FFECB.3030402@erlang-solutions.com> Message-ID: <20120206170543.GA24354@circlewave.net> # Jos? Valim 2012-02-06: > > > > This is a good principle, but Ruby does not heed it: > > > > http://stackoverflow.com/**questions/372652/what-are-the-** > > ruby-gotchas-a-newbie-should-**be-warned-about > > Matz, the creator of Ruby, once said that the "Principle of Least Surprise" > applies to *him* and every person has different "surprises" since they > expect different things based on their past experience. *sigh* Such solipsistic interpretation for one violates POLS in itself and further defeats practical value of said principle... That a Cool Guy said it doesn't make it any less stupid (in case he was serious -- hopefully I'm just overworked and missed an obvious joke). BR, -- Jachym From abdoo.mahran@REDACTED Mon Feb 6 18:10:48 2012 From: abdoo.mahran@REDACTED (Abdul Fattah Mahran) Date: Mon, 6 Feb 2012 19:10:48 +0200 Subject: [erlang-questions] What is best practice (records/tupples)? In-Reply-To: References: Message-ID: Hi Matthew, You are right, the first on is better because you check the length and assign the variable in one time. and it is a good practice if the contents of the record are small. /Abd El-Fattah On Mon, Feb 6, 2012 at 6:52 PM, Matthew Evans wrote: > > Hi, > Given something like: > -record(my_record, {aaa, bbb, ccc, > ddd}). > > What is more efficient, and what is best practice? > This - > some_function(#my_record{aaa = AAA, bbb = BBB, ddd = DDD} = _MyRecord) -> > % Some work > > Or this - > > some_function(MyRecord) -> AAA = MyRecord#my_record.aaa, BBB = > MyRecord#my_record.bbb, DDD = MyRecord#my_record.ccc, % Some work > > I've always thought that the first example is best. Or does the compiler > do some kind of trickery? > Does it make any difference if you only need a few vs. all the variables > from the record? > Thanks > Matt > > _______________________________________________ > 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 mfidelman@REDACTED Mon Feb 6 18:30:41 2012 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 06 Feb 2012 12:30:41 -0500 Subject: [erlang-questions] looking for good tutorials (newbie) In-Reply-To: <4F2FF59B.4090207@2600hz.com> References: <4F2FED9C.9070901@meetinghouse.net> <4F2FF337.3040804@meetinghouse.net> <4F2FF59B.4090207@2600hz.com> Message-ID: <4F300E41.9090002@meetinghouse.net> Perfect. Thanks! Miles James Aimonetti wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > OTP in Action: http://manning.com/logan/ > > Well written book covering a lot of the ground you're looking for, I think. > > On 02/06/2012 07:35 AM, Miles Fidelman wrote: >> Zabrane and Daniel... thanks for the pointers to learnyousomeerlang.com. >> >> The thing is, that's what I'm working through now. I'm hoping to find >> something that goes the next step, into more details - particularly re. >> both conceptualizing and debugging highly concurrent applications. >> >> Thanks, >> >> Miles >> >> > > - -- > James Aimonetti > Distributed Systems Engineer / DJ MC_ > > 2600hz | http://2600hz.com > sip:james@REDACTED > tel: 415.886.7905 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJPL/WbAAoJENc77s1OYoGgKUUIAKAccaMTppJNv39/X5WDGvKp > 7sMrq9K/aT8pnkBFR2EKJ/PaFE1MEQIGJ1cKGRIdeaJ2XYjZ1SRjZjvL5UiWndoR > DZbSRf8d1YJFZqiObLc8KWsikQn/B4TXYsJXTis3KFx6OgBWsV0uJiIDRqbw7deL > nEk6C3hBsrt5AT7ZIt7l/itmEnI09D3fcAa2Hy4w00BW6J6ALMseUdN6SZC11Uh6 > GF2/9XtOp22enytg5x1J8sAqa1rkWe5Cy0z/wDGNba45cJfdPLVxh0LeTaa6c4gk > 98OVHd9NjmBUQXfP7jEGT8WYCTMOpLRsQASPMz2mcMudj4ifruNPbb9nyqvgThQ= > =G1Xh > -----END PGP SIGNATURE----- > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From jwatte@REDACTED Mon Feb 6 20:16:04 2012 From: jwatte@REDACTED (Jon Watte) Date: Mon, 6 Feb 2012 11:16:04 -0800 Subject: [erlang-questions] Lightweight proper code update In-Reply-To: <15EAFCA3-F30C-46A7-AE19-0FB365849AAE@gmail.com> References: <15EAFCA3-F30C-46A7-AE19-0FB365849AAE@gmail.com> Message-ID: This looks great! We're currently in the throes of deciding between rolling re-starts (and client re-connects) or in-place updates, and this might skew the scales in favor of in-place. There's still the whole question about how you unit test cross-version updates effectively, but I don't expect anyone has a canned solution for that... Sincerely, jw -- Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. On Sat, Feb 4, 2012 at 4:05 AM, Per Melin wrote: > OTP release management, if you need most of the benefits it offers, can undoubtedly be very useful. > > But I believe that most of us don't need most of those benefits most of the time, and that all the careful administration it requires can be a hindrance and even a source of errors. Especially if you are running your code in-house and do frequent incremental releases. > > Unfortunately the next best thing is to restart the node or simply reload the changed modules and hope for the best. I think there is room for something better than that. > > I've toyed with different solutions and the best I've come up with is an application that does this: > > 1. Compare the loaded code with the beam files on disk to find modules that have been changed. > 2. Use xref to figure out any dependencies between the changed modules (who calls whom). > 3. Inspect the modules to separate supervisors, special processes like gen_server, and the rest. > 4. Generate a script with appup instructions, based on the previous steps. > 5. Use systools to compile this script to a lower level relup script. > 6. Ask release handler to execute the low level script. > > You can find the code here. It is only about 200 lines. > https://github.com/permelin/updo > > With this you don't get named releases or a bundled ERTS, but you do get the same code upgrade process as with a proper release; suspension of special processes, optional update of their states, updated child specs for supervisors, modules are reloaded in a logical order, etc. And it does not require you to keep app and appup files perfectly maintained or jump through any of the hoops otherwise associated with releases. > > There are however also some potential problems. At the top of my head: > - To accomplish steps 5 and 6 I am calling functions in systools and release handler that are exported, but were most likely never intended to be used outside those applications. > - xref will not always be able to find all cross-module calls, or do something about circular dependencies. Though I'm not sure it will do a worse job than a human manually writing appup instructions. > > Any other problems I've missed? Ideas? Questions? Wouldn't something like this be nice to have in OTP? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From jwatte@REDACTED Mon Feb 6 20:24:20 2012 From: jwatte@REDACTED (Jon Watte) Date: Mon, 6 Feb 2012 11:24:20 -0800 Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: References: Message-ID: That is interesting -- it might make it worth it to upgrade to R14. Also, we found a module called "gen_server2" that works around this problem by draining the message queue before calling any callback, and then dispatching messages based on this list of drained messages. Does anyone have experience with this module? Sincerely, jw -- Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. On Fri, Feb 3, 2012 at 10:57 AM, Max Lapshin wrote: >> >> 1) I'm considering writing some nifs that allow me to send UDP >> datagrams without going through a mailbox scan. For syslog and >> statistics, this would be a perfectly fine thing to do. > > > It was invented about year or more ago for gen_server:call. > > Instruction like "look for incoming message, but only beginning from mark" From ingo.jaeckel@REDACTED Mon Feb 6 20:32:36 2012 From: ingo.jaeckel@REDACTED (Ingo Jaeckel) Date: Mon, 6 Feb 2012 19:32:36 +0000 Subject: [erlang-questions] looking for good tutorials (newbie) In-Reply-To: <4F2FF59B.4090207@2600hz.com> References: <4F2FED9C.9070901@meetinghouse.net> <4F2FF337.3040804@meetinghouse.net> <4F2FF59B.4090207@2600hz.com> Message-ID: Hello Miles, there are plenty of websites and papers out there that explain Erlang in great detail. I just created a list of good free Erlang resources here: http://usability-nightmare.blogspot.com/2012/02/great-free-erlang-resources.html Regarding books, I can recommend Joe's Programming Erlang a lot! Cheers, Ingo On Mon, Feb 6, 2012 at 3:45 PM, James Aimonetti wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > OTP in Action: http://manning.com/logan/ > > Well written book covering a lot of the ground you're looking for, I think. > > On 02/06/2012 07:35 AM, Miles Fidelman wrote: >> Zabrane and Daniel... thanks for the pointers to learnyousomeerlang.com. >> >> The thing is, that's what I'm working through now. ?I'm hoping to find >> something that goes the next step, into more details - particularly re. >> both conceptualizing and debugging highly concurrent applications. >> >> Thanks, >> >> Miles >> >> > > > - -- > James Aimonetti > Distributed Systems Engineer / DJ MC_ > > 2600hz | http://2600hz.com > sip:james@REDACTED > tel: 415.886.7905 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJPL/WbAAoJENc77s1OYoGgKUUIAKAccaMTppJNv39/X5WDGvKp > 7sMrq9K/aT8pnkBFR2EKJ/PaFE1MEQIGJ1cKGRIdeaJ2XYjZ1SRjZjvL5UiWndoR > DZbSRf8d1YJFZqiObLc8KWsikQn/B4TXYsJXTis3KFx6OgBWsV0uJiIDRqbw7deL > nEk6C3hBsrt5AT7ZIt7l/itmEnI09D3fcAa2Hy4w00BW6J6ALMseUdN6SZC11Uh6 > GF2/9XtOp22enytg5x1J8sAqa1rkWe5Cy0z/wDGNba45cJfdPLVxh0LeTaa6c4gk > 98OVHd9NjmBUQXfP7jEGT8WYCTMOpLRsQASPMz2mcMudj4ifruNPbb9nyqvgThQ= > =G1Xh > -----END PGP SIGNATURE----- > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From watson.timothy@REDACTED Mon Feb 6 20:38:56 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Mon, 6 Feb 2012 19:38:56 +0000 Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: References: Message-ID: On 6 February 2012 19:24, Jon Watte wrote: > That is interesting -- it might make it worth it to upgrade to R14. > > Also, we found a module called "gen_server2" that works around this > problem by draining the message queue before calling any callback, and > then dispatching messages based on this list of drained messages. Does > anyone have experience with this module? > > It is part of rabbitmq, which I'm guessing it's reasonable to call *fairly stable and production worthy* lol. I keep a copy as a standalone OTP library application on github, which I update/synchronise periodically with updates from the rabbit hg/git repository. I haven't refreshed it in a while, as we're largely >= R14 now, but I find this approach (of bundling it as a standalone library app) works nicely for making it available across projects, though I'm less reliant on it now as I'm not using the extra features it provides in addition to message queue draining. > Sincerely, > > jw > > > > -- > Americans might object: there is no way we would sacrifice our living > standards for the benefit of people in the rest of the world. > Nevertheless, whether we get there willingly or not, we shall soon > have lower consumption rates, because our present rates are > unsustainable. > > > > On Fri, Feb 3, 2012 at 10:57 AM, Max Lapshin > wrote: > >> > >> 1) I'm considering writing some nifs that allow me to send UDP > >> datagrams without going through a mailbox scan. For syslog and > >> statistics, this would be a perfectly fine thing to do. > > > > > > It was invented about year or more ago for gen_server:call. > > > > Instruction like "look for incoming message, but only beginning from > mark" > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Mon Feb 6 21:21:46 2012 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 6 Feb 2012 15:21:46 -0500 Subject: [erlang-questions] Run queue reportings Message-ID: Hey there, mailing list. I've got a quick question for you. We've been using erlang:statistics(run_queue) to have one of many ways to measure overload on a system. The documentation for the function says the following: run_queue Returns the length of the run queue, that is, the number of processes that are ready to run. I was wondering if this has any relationship to the run queues used by the schedulers ([rq:N] when starting the VM in pre R15 Erlang releases). And if so, is the value obtained by the function call representing the union of all run queues, or only the run queue(s) of the scheduler executing the call? How reliable can we consider this information to be? Regards, Fred. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwatte@REDACTED Mon Feb 6 21:37:52 2012 From: jwatte@REDACTED (Jon Watte) Date: Mon, 6 Feb 2012 12:37:52 -0800 Subject: [erlang-questions] Trie NIFs In-Reply-To: References: Message-ID: Why does it have to be NIF? On the surface, that looks like a data structure that might actually work reasonably well as an Erlang native library. (Modification generates log-N garbage) Sincerely, jw -- Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. On Mon, Feb 6, 2012 at 8:43 AM, ori brost wrote: > I'm looking for a trie NIF library that can support strings as trie > tokens, and basic pattern matching with a '.' like wildcard (i.e. If / > is the trie separator and the tree contains 3 entries: /usr/bin, > /usr/include/X12/XTrans, /usr/include/X11/Xtrans, then I can do > > trie:get_all(["usr", "include", '.', "XTrans"]) > > and it will return > > [["usr","include","X11","Xtrans"], > ?["usr","include","X12","Xtrans"]] > > It would also be nice to have a > > trie:get_single(["usr","include", '.', "XTrans"]) > > that returns only one of the matching entries > > Does anyone know of such a NIF library? Or something similar enough > that I can modify it for these needs? > > Regards, OriB. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From zabrane3@REDACTED Mon Feb 6 21:42:04 2012 From: zabrane3@REDACTED (Zabrane Mickael) Date: Mon, 6 Feb 2012 21:42:04 +0100 Subject: [erlang-questions] looking for good tutorials (newbie) In-Reply-To: <4F2FF337.3040804@meetinghouse.net> References: <4F2FED9C.9070901@meetinghouse.net> <4F2FF337.3040804@meetinghouse.net> Message-ID: <547D73EA-7F41-4495-8DD8-627CB4A8A91C@gmail.com> Miles, LYSE is awesome and Fred (the author) is one of the most talented Erlang coders around. I found in LYSE what i didn't find in any other Erlang book (advanced topics such release handling, upgrade ... and how to debug complex app.). my 2 cents Regards, Zabrane On Feb 6, 2012, at 4:35 PM, Miles Fidelman wrote: > Zabrane and Daniel... thanks for the pointers to learnyousomeerlang.com. > > The thing is, that's what I'm working through now. I'm hoping to find something that goes the next step, into more details - particularly re. both conceptualizing and debugging highly concurrent applications. > > Thanks, > > Miles > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From zabrane3@REDACTED Mon Feb 6 21:45:15 2012 From: zabrane3@REDACTED (Zabrane Mickael) Date: Mon, 6 Feb 2012 21:45:15 +0100 Subject: [erlang-questions] Trie NIFs In-Reply-To: References: Message-ID: Try this: https://github.com/okeuday/trie See bench: http://okeuday.livejournal.com/16941.html Regards, Zabrane On Feb 6, 2012, at 9:37 PM, Jon Watte wrote: > Why does it have to be NIF? On the surface, that looks like a data > structure that might actually work reasonably well as an Erlang native > library. (Modification generates log-N garbage) > > Sincerely, > > jw > > > -- > Americans might object: there is no way we would sacrifice our living > standards for the benefit of people in the rest of the world. > Nevertheless, whether we get there willingly or not, we shall soon > have lower consumption rates, because our present rates are > unsustainable. > > > > On Mon, Feb 6, 2012 at 8:43 AM, ori brost wrote: >> I'm looking for a trie NIF library that can support strings as trie >> tokens, and basic pattern matching with a '.' like wildcard (i.e. If / >> is the trie separator and the tree contains 3 entries: /usr/bin, >> /usr/include/X12/XTrans, /usr/include/X11/Xtrans, then I can do >> >> trie:get_all(["usr", "include", '.', "XTrans"]) >> >> and it will return >> >> [["usr","include","X11","Xtrans"], >> ["usr","include","X12","Xtrans"]] >> >> It would also be nice to have a >> >> trie:get_single(["usr","include", '.', "XTrans"]) >> >> that returns only one of the matching entries >> >> Does anyone know of such a NIF library? Or something similar enough >> that I can modify it for these needs? >> >> Regards, OriB. >> _______________________________________________ >> erlang-questions mailing list >> 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 anthonym@REDACTED Mon Feb 6 22:22:01 2012 From: anthonym@REDACTED (Anthony Molinaro) Date: Mon, 6 Feb 2012 13:22:01 -0800 Subject: [erlang-questions] Los Angeles Erlang Meetup, February 15th, 7PM Message-ID: <20120206212201.GB42939@alumni.caltech.edu> Once again at OpenX in Pasadena. http://www.erlang.la/events/50240402/ Blaine Whittle will talk about automating existing tools and excuting external applications with erlang, as well as debugging and profiling of erlang code. It's my understanding that he's used these techniques to automate the building of World of Warcraft clients at Blizzard. Please RSVP at the above link if you can come. -- ------------------------------------------------------------------------ Anthony Molinaro From ransomr@REDACTED Tue Feb 7 00:32:32 2012 From: ransomr@REDACTED (Ransom Richardson) Date: Mon, 6 Feb 2012 23:32:32 +0000 Subject: [erlang-questions] "Kernel pid terminated" error getting release to run (newbie) Message-ID: I'm building my first non-trivial Erlang application. I've gotten it working in the shell. Now I'm trying to build a release using rebar. "rebar generate" succeeds, but when I try to run the application I get the error below. I'm trying to follow these tutorials: http://www.metabrew.com/article/erlang-rebar-tutorial-generating-releases-upgrades http://alancastro.org/2010/05/01/erlang-application-management-with-rebar.html I have named both my application and my node "session". The error seems rather unhelpful, so any suggestions on how to debug are appreciated. thanks, Ransom cocomo@REDACTED:~/dev/talko/service/session$ ./rel/session/bin/session console Exec: /home/cocomo/dev/talko/service/session/rel/session/erts-5.9/bin/erlexec -boot /home/cocomo/dev/talko/service/session/rel/session/releases/1/session -mode embedded -config /home/cocomo/dev/talko/service/session/rel/session/releases/1/sys.config -args_file /home/cocomo/dev/talko/service/session/rel/session/releases/1/vm.args -- console Root: /home/cocomo/dev/talko/service/session/rel/session Erlang R15B (erts-5.9) [source] [smp:2:2] [async-threads:0] [hipe] [kernel-poll:false] 1 2 =INFO REPORT==== 6-Feb-2012::18:15:15 === application: session exited: {shutdown,{session_app,start,[normal,[]]}} type: permanent Eshell V5.9 (abort with ^G) (session@REDACTED)1> {"Kernel pid terminated",application_controller,"{application_start_failure,session,{shutdown,{session_app,start,[normal,[]]}}}"} Crash dump was written to: erl_crash.dump Kernel pid terminated (application_controller) ({application_start_failure,session,{shutdown,{session_app,start,[normal,[]]}}}) FILE session_app.erl -module(session_app). -behaviour(application). %% Application callbacks -export([start/0, start/2, stop/1]). %% =================================================================== %% Application callbacks %% =================================================================== %% start/0 is only to use for testing in the shell start() -> {ok, Pid} = session_sup:start_link(), unlink(Pid). start(_StartType, _StartArgs) -> session_sup:start_link(). stop(_State) -> ok. FILE session_sup.erl -module(session_sup). -behaviour(supervisor). %% API -export([start_link/0]). %% Supervisor callbacks -export([init/1]). %% Helper macro for declaring children of supervisor -define(CHILD(I, Type), {I, {I, start_link, []}, permanent, 5000, Type, [I]}). %% =================================================================== %% API functions %% =================================================================== start_link() -> supervisor:start_link({local, ?MODULE}, ?MODULE, []). %% =================================================================== %% Supervisor callbacks %% =================================================================== init([]) -> Controller = ?CHILD(controller, worker), {ok, { {one_for_one, 5, 10}, [Controller]} }. FILE reltool.config {sys, [ {lib_dirs, ["../../"]}, {erts, [{mod_cond, derived}, {app_file, strip}]}, {app_file, strip}, {rel, "session", "1", [ kernel, stdlib, sasl, session ]}, {rel, "start_clean", "", [ kernel, stdlib ]}, {boot_rel, "session"}, {profile, embedded}, {incl_cond, exclude}, {excl_archive_filters, [".*"]}, %% Do not archive built libs {excl_sys_filters, ["^bin/.*", "^erts.*/bin/(dialyzer|typer)", "^erts.*/(doc|info|include|lib|man|src)"]}, {excl_app_filters, ["\.gitignore"]}, {app, sasl, [{incl_cond, include}]}, {app, stdlib, [{incl_cond, include}]}, {app, kernel, [{incl_cond, include}]}, {app, session, [{incl_cond, include}]} ]}. {target_dir, "session"}. {overlay, [ {mkdir, "log/sasl"}, {copy, "files/erl", "\{\{erts_vsn\}\}/bin/erl"}, {copy, "files/nodetool", "\{\{erts_vsn\}\}/bin/nodetool"}, {copy, "files/session", "bin/session"}, {copy, "files/sys.config", "releases/\{\{rel_vsn\}\}/sys.config"}, {copy, "files/session.cmd", "bin/session.cmd"}, {copy, "files/start_erl.cmd", "bin/start_erl.cmd"}, {copy, "files/vm.args", "releases/\{\{rel_vsn\}\}/vm.args"} ]}. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjtruog@REDACTED Tue Feb 7 00:54:44 2012 From: mjtruog@REDACTED (Michael Truog) Date: Mon, 06 Feb 2012 15:54:44 -0800 Subject: [erlang-questions] Trie NIFs In-Reply-To: References: Message-ID: <4F306844.1060806@gmail.com> That code doesn't currently contain regex support, but you could iterate on the contents based on a common prefix held within the trie, while checking each string passed to the anonymous function to do this programmatically. To do things this way, you would use: trie:fold_similar("/usr/include/", Function, Accumulator, Trie) Some simple pattern matching (perhaps using "*") could probably be grafted on in a similar way, where you would be matching string suffixes after the "*" character's last occurrence. On 02/06/2012 12:45 PM, Zabrane Mickael wrote: > Try this: > https://github.com/okeuday/trie > > See bench: > http://okeuday.livejournal.com/16941.html > > Regards, > Zabrane > > > On Feb 6, 2012, at 9:37 PM, Jon Watte wrote: > >> Why does it have to be NIF? On the surface, that looks like a data >> structure that might actually work reasonably well as an Erlang native >> library. (Modification generates log-N garbage) >> >> Sincerely, >> >> jw >> >> >> -- >> Americans might object: there is no way we would sacrifice our living >> standards for the benefit of people in the rest of the world. >> Nevertheless, whether we get there willingly or not, we shall soon >> have lower consumption rates, because our present rates are >> unsustainable. >> >> >> >> On Mon, Feb 6, 2012 at 8:43 AM, ori brost > wrote: >>> I'm looking for a trie NIF library that can support strings as trie >>> tokens, and basic pattern matching with a '.' like wildcard (i.e. If / >>> is the trie separator and the tree contains 3 entries: /usr/bin, >>> /usr/include/X12/XTrans, /usr/include/X11/Xtrans, then I can do >>> >>> trie:get_all(["usr", "include", '.', "XTrans"]) >>> >>> and it will return >>> >>> [["usr","include","X11","Xtrans"], >>> ["usr","include","X12","Xtrans"]] >>> >>> It would also be nice to have a >>> >>> trie:get_single(["usr","include", '.', "XTrans"]) >>> >>> that returns only one of the matching entries >>> >>> Does anyone know of such a NIF library? Or something similar enough >>> that I can modify it for these needs? >>> >>> Regards, OriB. >>> _______________________________________________ >>> erlang-questions mailing list >>> 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 steven.charles.davis@REDACTED Tue Feb 7 01:38:14 2012 From: steven.charles.davis@REDACTED (Steve Davis) Date: Mon, 6 Feb 2012 16:38:14 -0800 (PST) Subject: [erlang-questions] the Israeli programming language Erlang Message-ID: In: http://us.shalomlife.com/business/16634/swedish-israeli-payment-solution-company-takes-the-fear-out-of-online-shopping/ There's this: "The company?s payment solutions,which are built using the Israeli programming language Erlang" ...wow, that's certainly news to me... /s From michael.eugene.turner@REDACTED Tue Feb 7 05:14:52 2012 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Tue, 7 Feb 2012 13:14:52 +0900 Subject: [erlang-questions] the Israeli programming language Erlang In-Reply-To: References: Message-ID: I always thought Erlang was a Greek programming language. (Or am I thinking of PLEX?) ;-) -michael On Tue, Feb 7, 2012 at 9:38 AM, Steve Davis wrote: > In: > > http://us.shalomlife.com/business/16634/swedish-israeli-payment-solution-company-takes-the-fear-out-of-online-shopping/ > > There's this: > > "The company?s payment solutions,which are built using the Israeli > programming language Erlang" > > ...wow, that's certainly news to me... > > /s > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From thaterlangguy@REDACTED Tue Feb 7 05:26:14 2012 From: thaterlangguy@REDACTED (Ahmed Al-Saadi) Date: Mon, 6 Feb 2012 23:26:14 -0500 Subject: [erlang-questions] the Israeli programming language Erlang In-Reply-To: References: Message-ID: <031017F2BEF34C38BC31AA2D52C00FEC@gmail.com> In other news, prime minister Netanyahu declares that Joe Armstrong did not really invent Erlang and that Donald Knuth promised that language to his government a couple of centuries prior. He has since cut off water and electricity from Armstrong's house until the latter returns to negotiations. Armstrong continues to contend that giving him part of the 'io' module and denying him BIFs is not a generous offer! End the blockade! Free Armstrong! -signed(ahmed). -- Ahmed Al-Saadi Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Monday, February 6, 2012 at 7:38 PM, Steve Davis wrote: > In: > > http://us.shalomlife.com/business/16634/swedish-israeli-payment-solution-company-takes-the-fear-out-of-online-shopping/ > > There's this: > > "The company?s payment solutions,which are built using the Israeli > programming language Erlang" > > ...wow, that's certainly news to me... > > /s > _______________________________________________ > 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 dbarker@REDACTED Tue Feb 7 06:45:36 2012 From: dbarker@REDACTED (Deryk Barker) Date: Mon, 06 Feb 2012 21:45:36 -0800 Subject: [erlang-questions] the Israeli programming language Erlang In-Reply-To: References: Message-ID: <4F30BA80.3090601@camosun.bc.ca> On 06/02/12 20:14, Michael Turner wrote: > I always thought Erlang was a Greek programming language. (Or am I > thinking of PLEX?) ;-) > APL. deryk From bourinov@REDACTED Tue Feb 7 06:46:35 2012 From: bourinov@REDACTED (Max Bourinov) Date: Tue, 7 Feb 2012 09:46:35 +0400 Subject: [erlang-questions] the Israeli programming language Erlang In-Reply-To: <031017F2BEF34C38BC31AA2D52C00FEC@gmail.com> References: <031017F2BEF34C38BC31AA2D52C00FEC@gmail.com> Message-ID: *This is the way how many inventions were made. Nothing personal - just pure science.* Best regards, Max (Italic means irony) On Tue, Feb 7, 2012 at 8:26 AM, Ahmed Al-Saadi wrote: > In other news, prime minister Netanyahu declares that Joe Armstrong did > not really invent Erlang and that Donald Knuth promised that language to > his government a couple of centuries prior. He has since cut off water and > electricity from Armstrong's house until the latter returns to > negotiations. Armstrong continues to contend that giving him part of the > 'io' module and denying him BIFs is not a generous offer! > > End the blockade! Free Armstrong! > > -signed(ahmed). > > -- > Ahmed Al-Saadi > Sent with Sparrow > > On Monday, February 6, 2012 at 7:38 PM, Steve Davis wrote: > > In: > > > http://us.shalomlife.com/business/16634/swedish-israeli-payment-solution-company-takes-the-fear-out-of-online-shopping/ > > There's this: > > "The company?s payment solutions,which are built using the Israeli > programming language Erlang" > > ...wow, that's certainly news to me... > > /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 ulf@REDACTED Tue Feb 7 07:22:57 2012 From: ulf@REDACTED (Ulf Wiger) Date: Tue, 7 Feb 2012 07:22:57 +0100 Subject: [erlang-questions] the Israeli programming language Erlang In-Reply-To: References: Message-ID: <3ABF3FDA-1942-48E0-A641-47FC9084D7CB@feuerlabs.com> I was also a bit surprised to learn that Klarna was a Swedish-Israeli company, but if Klarna acquired an Israeli company in 2011, I guess they assimilated some of the Israeli gene pool then. :) I guess Ford is an American-Swedish company then, since they acquired Volvo in 1999? That would be a consolation, since we're starting to run out of Swedish car manufacturers... BR, Ulf W On 7 Feb 2012, at 01:38, Steve Davis wrote: > In: > > http://us.shalomlife.com/business/16634/swedish-israeli-payment-solution-company-takes-the-fear-out-of-online-shopping/ > > There's this: > > "The company?s payment solutions,which are built using the Israeli > programming language Erlang" > > ...wow, that's certainly news to me... > > /s > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From paul.james.barry@REDACTED Tue Feb 7 10:29:03 2012 From: paul.james.barry@REDACTED (Paul Barry) Date: Tue, 7 Feb 2012 09:29:03 +0000 Subject: [erlang-questions] the Israeli programming language Erlang In-Reply-To: <031017F2BEF34C38BC31AA2D52C00FEC@gmail.com> References: <031017F2BEF34C38BC31AA2D52C00FEC@gmail.com> Message-ID: I've chartered a boat, have filled it full of humanitarian supplies, and I'm setting sail for Joe's house in the morning... wish me luck. ;-) On 7 February 2012 04:26, Ahmed Al-Saadi wrote: > > End the blockade! Free Armstrong! -- Paul Barry, w: http://paulbarry.itcarlow.ie - e: paul.barry@REDACTED Lecturer, Computer Networking: Institute of Technology, Carlow, Ireland. From karol.skocik@REDACTED Tue Feb 7 11:45:53 2012 From: karol.skocik@REDACTED (karol skocik) Date: Tue, 7 Feb 2012 11:45:53 +0100 Subject: [erlang-questions] escript's beam in in distributed environment Message-ID: Hi, I want to have an escript, which starts some slave nodes making requests to some target host - basically a simple load generator. On a slave nodes, running functions from escript directly fails, since slaves can't find those escript functions, which is understandable. For that purpose, the escript contains this function: make_beam() -> Name = escript:script_name(), AbsName = filename:absname(Name), {ok, Sections} = escript:extract(AbsName, [compile_source]), {source, BeamCode} = lists:keyfind(source, 1, Sections), BeamFile = filename:join("/tmp", atom_to_list(?MODULE) ++ ".beam"), file:write_file(BeamFile, BeamCode), BeamFile. The plan was: 1.) save the escript as a beam to the "/tmp" directory (with a funky name from ?MODULE - like 'gcf-tester__escript__1328__608633__210866') 2.) add "/tmp" to the code path on master, before starting slaves 3.) let the slaves load module (named ?MODULE in escript) using code load mechanism thru master Now the problem: When the saved escript's beam is loaded in the Erlang shell, it seems broken: (gcfc@REDACTED)5> code:add_patha("/tmp"). true (gcfc@REDACTED)6> l('gcf-tester__escript__1328__608402__188688'). {error,badfile} (gcfc@REDACTED)7> =ERROR REPORT==== 7-Feb-2012::10:54:09 === Loading of /tmp/gcf-tester__escript__1328__608402__188688.beam failed: badfile =ERROR REPORT==== 7-Feb-2012::10:54:09 === beam/beam_load.c(1084): Error loading module 'gcf-tester__escript__1328__608402__188688': module name in object code is gcf-tester__escript__1328__608402__542812 I am using: Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] on: Gentoo Linux 2.6.38-tuxonice-r2-mars #9 SMP PREEMPT x86_64 Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz GenuineIntel GNU/Linux Is this a bug? (Maybe fixed in R15?). If this is an expected behavior, how do I know the final module name at the time of creating the escript's beam? And finally, what's the easiest way to "patch" the beam's binary to supply the correct module name? Thank you for your advice, Karol Skocik From hm@REDACTED Tue Feb 7 12:19:11 2012 From: hm@REDACTED (=?ISO-8859-1?Q?H=E5kan_Mattsson?=) Date: Tue, 7 Feb 2012 12:19:11 +0100 Subject: [erlang-questions] escript's beam in in distributed environment In-Reply-To: References: Message-ID: Use the module attribute in the escript source (e.g. -module(funky)) to control the module name. /H?kan On Tue, Feb 7, 2012 at 11:45, karol skocik wrote: > Hi, > ?I want to have an escript, which starts some slave nodes making > requests to some target host - basically a simple load generator. > On a slave nodes, running functions from escript directly fails, since > slaves can't find those escript functions, which is understandable. > For that purpose, the escript contains this function: > > make_beam() -> > ? ?Name = escript:script_name(), > ? ?AbsName = filename:absname(Name), > ? ?{ok, Sections} = escript:extract(AbsName, [compile_source]), > ? ?{source, BeamCode} = lists:keyfind(source, 1, Sections), > ? ?BeamFile = filename:join("/tmp", atom_to_list(?MODULE) ++ ".beam"), > ? ?file:write_file(BeamFile, BeamCode), > ? ?BeamFile. > > The plan was: > 1.) save the escript as a beam to the "/tmp" directory (with a funky > name from ?MODULE - like 'gcf-tester__escript__1328__608633__210866') > 2.) add "/tmp" to the code path on master, before starting slaves > 3.) let the slaves load module (named ?MODULE in escript) using code > load mechanism thru master > > Now the problem: > > When the saved escript's beam is loaded in the Erlang shell, it seems broken: > > (gcfc@REDACTED)5> code:add_patha("/tmp"). > true > (gcfc@REDACTED)6> l('gcf-tester__escript__1328__608402__188688'). > {error,badfile} > (gcfc@REDACTED)7> > =ERROR REPORT==== 7-Feb-2012::10:54:09 === > Loading of /tmp/gcf-tester__escript__1328__608402__188688.beam failed: badfile > > =ERROR REPORT==== 7-Feb-2012::10:54:09 === > beam/beam_load.c(1084): Error loading module > 'gcf-tester__escript__1328__608402__188688': > ?module name in object code is gcf-tester__escript__1328__608402__542812 > > I am using: > Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] > on: > Gentoo Linux 2.6.38-tuxonice-r2-mars #9 SMP PREEMPT x86_64 Intel(R) > Core(TM)2 CPU T7400 @ 2.16GHz GenuineIntel GNU/Linux > > Is this a bug? (Maybe fixed in R15?). > If this is an expected behavior, how do I know the final module name > at the time of creating the escript's beam? > And finally, what's the easiest way to "patch" the beam's binary to > supply the correct module name? > > Thank you for your advice, > ?Karol Skocik > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From karol.skocik@REDACTED Tue Feb 7 12:24:05 2012 From: karol.skocik@REDACTED (karol skocik) Date: Tue, 7 Feb 2012 12:24:05 +0100 Subject: [erlang-questions] escript's beam in in distributed environment In-Reply-To: References: Message-ID: That's it - thank you. Didn't know "-module" is a valid escript attribute. Have a nice day, Karol On Tue, Feb 7, 2012 at 12:19 PM, H?kan Mattsson wrote: > Use the module attribute in the escript source (e.g. -module(funky)) > to control the module name. > > /H?kan > > On Tue, Feb 7, 2012 at 11:45, karol skocik wrote: >> Hi, >> ?I want to have an escript, which starts some slave nodes making >> requests to some target host - basically a simple load generator. >> On a slave nodes, running functions from escript directly fails, since >> slaves can't find those escript functions, which is understandable. >> For that purpose, the escript contains this function: >> >> make_beam() -> >> ? ?Name = escript:script_name(), >> ? ?AbsName = filename:absname(Name), >> ? ?{ok, Sections} = escript:extract(AbsName, [compile_source]), >> ? ?{source, BeamCode} = lists:keyfind(source, 1, Sections), >> ? ?BeamFile = filename:join("/tmp", atom_to_list(?MODULE) ++ ".beam"), >> ? ?file:write_file(BeamFile, BeamCode), >> ? ?BeamFile. >> >> The plan was: >> 1.) save the escript as a beam to the "/tmp" directory (with a funky >> name from ?MODULE - like 'gcf-tester__escript__1328__608633__210866') >> 2.) add "/tmp" to the code path on master, before starting slaves >> 3.) let the slaves load module (named ?MODULE in escript) using code >> load mechanism thru master >> >> Now the problem: >> >> When the saved escript's beam is loaded in the Erlang shell, it seems broken: >> >> (gcfc@REDACTED)5> code:add_patha("/tmp"). >> true >> (gcfc@REDACTED)6> l('gcf-tester__escript__1328__608402__188688'). >> {error,badfile} >> (gcfc@REDACTED)7> >> =ERROR REPORT==== 7-Feb-2012::10:54:09 === >> Loading of /tmp/gcf-tester__escript__1328__608402__188688.beam failed: badfile >> >> =ERROR REPORT==== 7-Feb-2012::10:54:09 === >> beam/beam_load.c(1084): Error loading module >> 'gcf-tester__escript__1328__608402__188688': >> ?module name in object code is gcf-tester__escript__1328__608402__542812 >> >> I am using: >> Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] >> on: >> Gentoo Linux 2.6.38-tuxonice-r2-mars #9 SMP PREEMPT x86_64 Intel(R) >> Core(TM)2 CPU T7400 @ 2.16GHz GenuineIntel GNU/Linux >> >> Is this a bug? (Maybe fixed in R15?). >> If this is an expected behavior, how do I know the final module name >> at the time of creating the escript's beam? >> And finally, what's the easiest way to "patch" the beam's binary to >> supply the correct module name? >> >> Thank you for your advice, >> ?Karol Skocik >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions From mihai@REDACTED Tue Feb 7 12:27:22 2012 From: mihai@REDACTED (Mihai Balea) Date: Tue, 7 Feb 2012 06:27:22 -0500 Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: References: Message-ID: <17A58775-B62F-4244-8DBF-5561F87D4FBC@hates.ms> On Feb 6, 2012, at 2:38 PM, Tim Watson wrote: > On 6 February 2012 19:24, Jon Watte wrote: > That is interesting -- it might make it worth it to upgrade to R14. > > Also, we found a module called "gen_server2" that works around this > problem by draining the message queue before calling any callback, and > then dispatching messages based on this list of drained messages. Does > anyone have experience with this module? > > > It is part of rabbitmq, which I'm guessing it's reasonable to call *fairly stable and production worthy* lol. I keep a copy as a standalone OTP library application on github, which I update/synchronise periodically with updates from the rabbit hg/git repository. I haven't refreshed it in a while, as we're largely >= R14 now, but I find this approach (of bundling it as a standalone library app) works nicely for making it available across projects, though I'm less reliant on it now as I'm not using the extra features it provides in addition to message queue draining. I wish there was an "official" standalone version of gen_server2. Rabbitmq includes it, the Erlang rabbitmq client includes it as well, riak_core too plus a variety of individuals like Tim have created standalone versions based on one of the above. If one attempts to combine, say, riak_core with the rabbitmq erlang client, frustration ensues. Mihai -------------- next part -------------- An HTML attachment was scrubbed... URL: From rtrlists@REDACTED Tue Feb 7 12:59:54 2012 From: rtrlists@REDACTED (Robert Raschke) Date: Tue, 7 Feb 2012 11:59:54 +0000 Subject: [erlang-questions] "Kernel pid terminated" error getting release to run (newbie) In-Reply-To: References: Message-ID: Looks like controller:start_link/0 failed in some way. Robby On Mon, Feb 6, 2012 at 11:32 PM, Ransom Richardson wrote: > I'm building my first non-trivial Erlang application. I've gotten it > working in the shell. Now I'm trying to build a release using rebar. "rebar > generate" succeeds, but when I try to run the application I get the error > below. I'm trying to follow these tutorials: > > http://www.metabrew.com/article/erlang-rebar-tutorial-generating-releases-upgrades > > http://alancastro.org/2010/05/01/erlang-application-management-with-rebar.html > > I have named both my application and my node "session". The error seems > rather unhelpful, so any suggestions on how to debug are appreciated. > > thanks, > Ransom > > > > cocomo@REDACTED:~/dev/talko/service/session$ ./rel/session/bin/session > console > Exec: > /home/cocomo/dev/talko/service/session/rel/session/erts-5.9/bin/erlexec > -boot /home/cocomo/dev/talko/service/session/rel/session/releases/1/session > -mode embedded -config > /home/cocomo/dev/talko/service/session/rel/session/releases/1/sys.config > -args_file > /home/cocomo/dev/talko/service/session/rel/session/releases/1/vm.args -- > console > Root: /home/cocomo/dev/talko/service/session/rel/session > Erlang R15B (erts-5.9) [source] [smp:2:2] [async-threads:0] [hipe] > [kernel-poll:false] > > 1 > 2 > > =INFO REPORT==== 6-Feb-2012::18:15:15 === > application: session > exited: {shutdown,{session_app,start,[normal,[]]}} > type: permanent > Eshell V5.9 (abort with ^G) > (session@REDACTED)1> {"Kernel pid > terminated",application_controller,"{application_start_failure,session,{shutdown,{session_app,start,[normal,[]]}}}"} > > Crash dump was written to: erl_crash.dump > Kernel pid terminated (application_controller) > ({application_start_failure,session,{shutdown,{session_app,start,[normal,[]]}}}) > > > FILE session_app.erl > > > -module(session_app). > > -behaviour(application). > > %% Application callbacks > -export([start/0, start/2, stop/1]). > > %% =================================================================== > %% Application callbacks > %% =================================================================== > > %% start/0 is only to use for testing in the shell > start() -> > {ok, Pid} = session_sup:start_link(), > unlink(Pid). > > start(_StartType, _StartArgs) -> > session_sup:start_link(). > > stop(_State) -> > ok. > > > > FILE session_sup.erl > > > -module(session_sup). > > -behaviour(supervisor). > > %% API > -export([start_link/0]). > > %% Supervisor callbacks > -export([init/1]). > > %% Helper macro for declaring children of supervisor > -define(CHILD(I, Type), {I, {I, start_link, []}, permanent, 5000, Type, > [I]}). > > %% =================================================================== > %% API functions > %% =================================================================== > > start_link() -> > supervisor:start_link({local, ?MODULE}, ?MODULE, []). > > %% =================================================================== > %% Supervisor callbacks > %% =================================================================== > > init([]) -> > Controller = ?CHILD(controller, worker), > {ok, { {one_for_one, 5, 10}, [Controller]} }. > > > FILE reltool.config > > > {sys, [ > {lib_dirs, ["../../"]}, > {erts, [{mod_cond, derived}, {app_file, strip}]}, > {app_file, strip}, > {rel, "session", "1", > [ > kernel, > stdlib, > sasl, > session > ]}, > {rel, "start_clean", "", > [ > kernel, > stdlib > ]}, > {boot_rel, "session"}, > {profile, embedded}, > {incl_cond, exclude}, > {excl_archive_filters, [".*"]}, %% Do not archive built libs > {excl_sys_filters, ["^bin/.*", "^erts.*/bin/(dialyzer|typer)", > "^erts.*/(doc|info|include|lib|man|src)"]}, > {excl_app_filters, ["\.gitignore"]}, > {app, sasl, [{incl_cond, include}]}, > {app, stdlib, [{incl_cond, include}]}, > {app, kernel, [{incl_cond, include}]}, > {app, session, [{incl_cond, include}]} > ]}. > > {target_dir, "session"}. > > {overlay, [ > {mkdir, "log/sasl"}, > {copy, "files/erl", "\{\{erts_vsn\}\}/bin/erl"}, > {copy, "files/nodetool", "\{\{erts_vsn\}\}/bin/nodetool"}, > {copy, "files/session", "bin/session"}, > {copy, "files/sys.config", > "releases/\{\{rel_vsn\}\}/sys.config"}, > {copy, "files/session.cmd", "bin/session.cmd"}, > {copy, "files/start_erl.cmd", "bin/start_erl.cmd"}, > {copy, "files/vm.args", "releases/\{\{rel_vsn\}\}/vm.args"} > ]}. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.rutkowski@REDACTED Tue Feb 7 14:55:59 2012 From: adam.rutkowski@REDACTED (Adam Rutkowski) Date: Tue, 7 Feb 2012 14:55:59 +0100 Subject: [erlang-questions] Strange module loading issue Message-ID: <3166EA90-0E71-4FAF-9BC9-6E335D8E2E61@jtendo.com> Hey List, (dynx@REDACTED)1> dynx_sms:send("666", "bah"). ** exception error: undefined function dynx_sms:send/2 (dynx@REDACTED)2> l(dynx_sms). {module,dynx_sms} (dynx@REDACTED)3> dynx_sms:send("666", "bah"). 14:09:16.272 [info] Sending "bah" to "666" Can someone explain me this behaviour? Some additional information: 1. This a rebar generated release, running on RH5 with R14B03 2. The module dynx_sms is listed within the app file (triple-checked now) 3. I have bunch of other dynx_* modules that load automatically with no issue 4. The issue reproduces on application restart, crashing with 'module cannot be loaded' reason (after a call from another module). Loading the module manually solves the problem. Would appreciate your thoughts on this. Thanks -- AR From hm@REDACTED Tue Feb 7 15:00:15 2012 From: hm@REDACTED (=?ISO-8859-1?Q?H=E5kan_Mattsson?=) Date: Tue, 7 Feb 2012 15:00:15 +0100 Subject: [erlang-questions] Strange module loading issue In-Reply-To: <3166EA90-0E71-4FAF-9BC9-6E335D8E2E61@jtendo.com> References: <3166EA90-0E71-4FAF-9BC9-6E335D8E2E61@jtendo.com> Message-ID: It seems like you are running the system in embedded mode. See the man-page for code. /H?kan On Tue, Feb 7, 2012 at 14:55, Adam Rutkowski wrote: > Hey List, > > (dynx@REDACTED)1> dynx_sms:send("666", "bah"). > ** exception error: undefined function dynx_sms:send/2 > (dynx@REDACTED)2> l(dynx_sms). > {module,dynx_sms} > (dynx@REDACTED)3> dynx_sms:send("666", "bah"). > 14:09:16.272 [info] Sending "bah" to "666" > > Can someone explain me this behaviour? > > Some additional information: > > 1. This a rebar generated release, running on RH5 with R14B03 > 2. The module dynx_sms is listed within the app file (triple-checked now) > 3. I have bunch of other dynx_* modules that load automatically with no issue > 4. The issue reproduces on application restart, crashing with 'module cannot be loaded' reason (after a call from another module). Loading the module manually solves the problem. > > Would appreciate your thoughts on this. > Thanks > -- > AR > > > > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From adam.rutkowski@REDACTED Tue Feb 7 15:10:32 2012 From: adam.rutkowski@REDACTED (Adam Rutkowski) Date: Tue, 7 Feb 2012 15:10:32 +0100 Subject: [erlang-questions] Strange module loading issue In-Reply-To: References: <3166EA90-0E71-4FAF-9BC9-6E335D8E2E61@jtendo.com> Message-ID: <69E06272-7EFB-4634-A448-06705AE01DE9@jtendo.com> On Feb 7, 2012, at 3:00 PM, H?kan Mattsson wrote: > It seems like you are running the system in embedded mode. > See the man-page for code. Right, thank you, solved. -- AR From attila.r.nohl@REDACTED Tue Feb 7 15:47:00 2012 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Tue, 7 Feb 2012 15:47:00 +0100 Subject: [erlang-questions] Extending behaviours with -callback sytnax Message-ID: Hello! I have a behaviour which extends an other behaviour, so it's behaviour_info function looks something like this: behaviour_info(callbacks) -> parent_module:behaviour_info(callbacks) ++ [{some_fun,1}, ...]. In OTP R15B I'd like to use the -callback syntax to define the functions in order to help dialyzer to find type problems. How can I extend an other behaviour without copying and pasting it's callback definitions? From erlang@REDACTED Tue Feb 7 15:48:38 2012 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 7 Feb 2012 15:48:38 +0100 Subject: [erlang-questions] the Israeli programming language Erlang In-Reply-To: References: <031017F2BEF34C38BC31AA2D52C00FEC@gmail.com> Message-ID: On Tue, Feb 7, 2012 at 10:29 AM, Paul Barry wrote: > I've chartered a boat, have filled it full of humanitarian supplies, > and I'm setting sail for Joe's house in the morning... wish me luck. > ;-) Wonderful - I'll need Marmite, tea and ginger biscuits. I'm down to my last six months supplies of Marmite - so things are getting desperate. BTW - you might need an icebreaker - this morning there was about five cms of ice on the canal - just outside where I live :-) /Joe > > On 7 February 2012 04:26, Ahmed Al-Saadi wrote: >> >> End the blockade! Free Armstrong! > > -- > Paul Barry, w: http://paulbarry.itcarlow.ie - e: paul.barry@REDACTED > Lecturer, Computer Networking: Institute of Technology, Carlow, Ireland. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From aronisstav@REDACTED Tue Feb 7 16:01:32 2012 From: aronisstav@REDACTED (Stavros Aronis) Date: Tue, 7 Feb 2012 07:01:32 -0800 (PST) Subject: [erlang-questions] Extending behaviours with -callback sytnax In-Reply-To: References: Message-ID: <33407233.3266.1328626892421.JavaMail.geo-discussion-forums@yqks7> Hi! Being able to extend a behavior in such a manner was not something that we had in mind when writing this extension. I don't think there is any better solution than simply putting the callback attributes of the "parent" in a header file and including it in a similar header file for your extending behaviour. Stavros -------------- next part -------------- An HTML attachment was scrubbed... URL: From comptekki@REDACTED Tue Feb 7 17:18:35 2012 From: comptekki@REDACTED (Wes James) Date: Tue, 7 Feb 2012 09:18:35 -0700 Subject: [erlang-questions] xmerl_scan results question Message-ID: From this file: Installed I ran xmerl_scan("t.plist"). and get rp(xmerl_scan:file("t.plist")). {{xmlElement,plist,plist,[], {xmlNamespace,[],[]}, [],1, [{xmlAttribute,version,[],[],[], [{plist,1}], 1,[],"1.0",false}], [{xmlText,[{plist,1}],1,[],"\n",text}, {xmlElement,dict,dict,[], {xmlNamespace,[],[]}, [{plist,1}], 2,[], [{xmlText,[{dict,2},{plist,1}],1,[],"\n\t",text}, {xmlElement,key,key,[], {xmlNamespace,[],[]}, [{dict,2},{plist,1}], 2,[], [{xmlText,[{key,2},{dict,2},{plist,1}], 1,[],"Installed",text}], [],".",undeclared}, {xmlText,[{dict,2},{plist,1}],3,[],"\n\t",text}, {xmlElement,true,true,[], {xmlNamespace,[],[]}, [{dict,2},{plist,1}], 4,[],[],[],".",undeclared}, {xmlText,[{dict,2},{plist,1}],5,[],"\n",text}], [],".",undeclared}, {xmlText,[{plist,1}],3,[],"\n",text}], [],".",undeclared}, []} ok I am wondering why, based on the xmerl.hrl file that there is no output for xmlDecl. Isn't it the 1st line of the plist/xml file an xmlDecl? What about the second line, i.e. DOCTYPE line? Thanks, Wes From watson.timothy@REDACTED Tue Feb 7 18:16:00 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 7 Feb 2012 17:16:00 +0000 Subject: [erlang-questions] "Kernel pid terminated" error getting release to run (newbie) In-Reply-To: References: Message-ID: On 7 February 2012 11:59, Robert Raschke wrote: > Looks like controller:start_link/0 failed in some way. > > Definitely looks that way doesn't it. How does `application:start(session)` behave in the shell, assuming all the prerequisites such as SASL are started first? For a quick hack to startup the dependant apps in the shell, you can use https://github.com/hyperthunk/appstart. TBH I'd expect to see a bit more info in the error logs - normally a failed startup produces a ton of noise... -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Tue Feb 7 18:25:41 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 7 Feb 2012 17:25:41 +0000 Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: <17A58775-B62F-4244-8DBF-5561F87D4FBC@hates.ms> References: <17A58775-B62F-4244-8DBF-5561F87D4FBC@hates.ms> Message-ID: On 7 February 2012 11:27, Mihai Balea wrote: > > On Feb 6, 2012, at 2:38 PM, Tim Watson wrote: > > On 6 February 2012 19:24, Jon Watte wrote: > >> That is interesting -- it might make it worth it to upgrade to R14. >> >> Also, we found a module called "gen_server2" that works around this >> problem by draining the message queue before calling any callback, and >> then dispatching messages based on this list of drained messages. Does >> anyone have experience with this module? >> >> > It is part of rabbitmq, which I'm guessing it's reasonable to call *fairly > stable and production worthy* lol. I keep a copy as a standalone OTP > library application on github, which I update/synchronise periodically with > updates from the rabbit hg/git repository. I haven't refreshed it in a > while, as we're largely >= R14 now, but I find this approach (of bundling > it as a standalone library app) works nicely for making it available across > projects, though I'm less reliant on it now as I'm not using the extra > features it provides in addition to message queue draining. > > > I wish there was an "official" standalone version of gen_server2. Rabbitmq > includes it, the Erlang rabbitmq client includes it as well, riak_core too > plus a variety of individuals like Tim have created standalone versions > based on one of the above. If one attempts to combine, say, riak_core with > the rabbitmq erlang client, frustration ensues. > > Actually this issue (of duplicate uses of the same module name) has to do with lack of namespace/package support and isn't so simple to solve - at least based on the myriad discussions on this list regarding the issue, none of which have yielded a satisfactory answer. Personally I think that whilst the java/.net approach of providing a namespace such as org.foobar.appname.package...etc might be flawed/imperfect, but it's a lot better than having clashes. The reason it works well in practise is that you can import modules via their namespace which reduces finger ache and you can always fully qualify a *thing* you want to use if there is a potential clash. Personally, I don't mind renaming gen_server2 to nebularis_gen_server2 but I just don't want to have to type that all the time. On the other hand, if packages were fully supported I could do this: -import(org.nebularis.gen_server2). doodah() -> gen_server2:start(....). But of course in todays system there are numerous tools (reltool, cover, etc) that do not work properly with packages *and* you have to import "top level" modules as well, which is just a pain in the arse: -import(lists). %% but why!!! I *know* there are potentially better ways and I fully recognise that there is little difference semantically between a_b and a.b, but it's not a about the separator, it's about the tedium of typing in long names, not to mention the fact the a_very_long_series_of_different_segments_separated_by_underscores is appalling to read. Personally I'd like to see behaviours and import come together so I can define take the gen_server(2) behaviour and import an implementation at the top level: -api(gen_server2, nebularis_genserver2). > Mihai > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourinov@REDACTED Tue Feb 7 20:39:15 2012 From: bourinov@REDACTED (Max Bourinov) Date: Tue, 7 Feb 2012 23:39:15 +0400 Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: References: <17A58775-B62F-4244-8DBF-5561F87D4FBC@hates.ms> Message-ID: <-8808220144167783942@unknownmsgid> I believe that Erlang is perfect the way it is. I see problem in absence of good IDE/editors for Erlang (yes, emacs is way not perfect). If there will be a tool like IntelliJ IDEA for Erlang, there will be no problems with typing very_long_names any more. Auto completion rules. (there is plugin for idea to write Erlang code, but I didn't find it useful) Sent from my iPhone On 07.02.2012, at 21:25, Tim Watson wrote: On 7 February 2012 11:27, Mihai Balea wrote: > > On Feb 6, 2012, at 2:38 PM, Tim Watson wrote: > > On 6 February 2012 19:24, Jon Watte wrote: > >> That is interesting -- it might make it worth it to upgrade to R14. >> >> Also, we found a module called "gen_server2" that works around this >> problem by draining the message queue before calling any callback, and >> then dispatching messages based on this list of drained messages. Does >> anyone have experience with this module? >> >> > It is part of rabbitmq, which I'm guessing it's reasonable to call *fairly > stable and production worthy* lol. I keep a copy as a standalone OTP > library application on github, which I update/synchronise periodically with > updates from the rabbit hg/git repository. I haven't refreshed it in a > while, as we're largely >= R14 now, but I find this approach (of bundling > it as a standalone library app) works nicely for making it available across > projects, though I'm less reliant on it now as I'm not using the extra > features it provides in addition to message queue draining. > > > I wish there was an "official" standalone version of gen_server2. Rabbitmq > includes it, the Erlang rabbitmq client includes it as well, riak_core too > plus a variety of individuals like Tim have created standalone versions > based on one of the above. If one attempts to combine, say, riak_core with > the rabbitmq erlang client, frustration ensues. > > Actually this issue (of duplicate uses of the same module name) has to do with lack of namespace/package support and isn't so simple to solve - at least based on the myriad discussions on this list regarding the issue, none of which have yielded a satisfactory answer. Personally I think that whilst the java/.net approach of providing a namespace such as org.foobar.appname.package...etc might be flawed/imperfect, but it's a lot better than having clashes. The reason it works well in practise is that you can import modules via their namespace which reduces finger ache and you can always fully qualify a *thing* you want to use if there is a potential clash. Personally, I don't mind renaming gen_server2 to nebularis_gen_server2 but I just don't want to have to type that all the time. On the other hand, if packages were fully supported I could do this: -import(org.nebularis.gen_server2). doodah() -> gen_server2:start(....). But of course in todays system there are numerous tools (reltool, cover, etc) that do not work properly with packages *and* you have to import "top level" modules as well, which is just a pain in the arse: -import(lists). %% but why!!! I *know* there are potentially better ways and I fully recognise that there is little difference semantically between a_b and a.b, but it's not a about the separator, it's about the tedium of typing in long names, not to mention the fact the a_very_long_series_of_different_segments_separated_by_underscores is appalling to read. Personally I'd like to see behaviours and import come together so I can define take the gen_server(2) behaviour and import an implementation at the top level: -api(gen_server2, nebularis_genserver2). > Mihai > > _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Tue Feb 7 20:49:15 2012 From: mfidelman@REDACTED (Miles Fidelman) Date: Tue, 07 Feb 2012 14:49:15 -0500 Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: <-8808220144167783942@unknownmsgid> References: <17A58775-B62F-4244-8DBF-5561F87D4FBC@hates.ms> <-8808220144167783942@unknownmsgid> Message-ID: <4F31803B.1040405@meetinghouse.net> Max Bourinov wrote: > I believe that Erlang is perfect the way it is. > > I see problem in absence of good IDE/editors for Erlang (yes, emacs is > way not perfect). > > If there will be a tool like IntelliJ IDEA for Erlang, there will be > no problems with typing very_long_names any more. Auto completion rules. > I'm starting to think that a smalltalk-like toolset would be great for Erlang - browsers, inspectors, etc. for a long-running environment. A lot of the pieces already exist, it would seem to be a matter of integration. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From vladdu55@REDACTED Tue Feb 7 21:00:14 2012 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Tue, 7 Feb 2012 21:00:14 +0100 Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: <4F31803B.1040405@meetinghouse.net> References: <17A58775-B62F-4244-8DBF-5561F87D4FBC@hates.ms> <-8808220144167783942@unknownmsgid> <4F31803B.1040405@meetinghouse.net> Message-ID: Hi, On Tue, Feb 7, 2012 at 20:49, Miles Fidelman wrote: > Max Bourinov wrote: >> I see problem in absence of good IDE/editors for Erlang (yes, emacs is way >> not perfect). >> If there will be a tool like IntelliJ IDEA for Erlang, there will be no >> problems with typing very_long_names any more. Auto completion rules. Did you try erlide? http://erlide.org > I'm starting to think that a smalltalk-like toolset would be great for > Erlang - browsers, inspectors, etc. for a long-running environment. ?A lot > of the pieces already exist, it would seem to be a matter of integration. This is something that I have in mind for the future of erlide. It's not as easy as it seems, especially as one has to invent new ways to present information: for example, overviewing a system with several thousands of processes... regards, Vlad From watson.timothy@REDACTED Tue Feb 7 21:49:34 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 7 Feb 2012 20:49:34 +0000 Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: <-8808220144167783942@unknownmsgid> References: <17A58775-B62F-4244-8DBF-5561F87D4FBC@hates.ms> <-8808220144167783942@unknownmsgid> Message-ID: On 7 February 2012 19:39, Max Bourinov wrote: > I believe that Erlang is perfect the way it is. > I love Erlang's simplicity and it's been pretty much my favorite development platform for the past few years now. I would like to be able to refer to a module *via* some additional context though, whether that is the application it resides in or a package/namespace. > > I see problem in absence of good IDE/editors for Erlang (yes, emacs is way > not perfect). > > Personally I get along fine with vim, but erlide is cool for those who want to use it. > If there will be a tool like IntelliJ IDEA for Erlang, there will be no > problems with typing very_long_names any more. Auto completion rules. > > Yes but my point about very_long_module_names is not just that it is ugly and painful to type. I can get autocompletion in vim/emacs today so that's not the issue. The point is that as the number of libraries/applications I am able to choose from increases (and let's face it, they're growing fast) I'm increasingly being forced to deal with module name clashes *or* to put up with very long names which are distracting to look at - they take focus away from the *function* that is being called, which is what *I* want to focus on. Maybe it's just me, and I'm in no way suggesting I know how to fix this. I would like to be able to run rabbitmq and riak in the same vm without a module name clash though, and it is there that currently one of several things has to happen: 1. both rabbit and riak- rename their copy of gen_server2 to riak_gen_server2/rabbit_gen_server2 2. I let the first one on the code path get loaded and hope to the gods that it *behaves* properly for both applications 3. I give up and run them in a separate vm None of these are satisfactory, especially as (1) isn't likely to happen. What might make this go away could be something like: - module code scoped to "application domains" i.e., to the application the beam file resides in - so as not to clash - modules within the same "application domain" referring to one another default to the same domain - so if app1 contains [mod1, mod2] and mod1 calls a function via `mod2:do_it(...)` then the function is resolved to the module `mod2` in the same application domain - we get the ability to `import` modules from external application domains, so that I can call stuff in other apps when I want to. % import everything in kernel and stdlib - this should probably be a default attribute! -import_app([kernel, stdlib]). % import a specific module from a specific app-domain -import_mod(rabbitmq, [gen_server2]). start() -> %% this resolves to the gen_server2 beam which resides in the rabbitmq application gen_server2:start(...). (there is plugin for idea to write Erlang code, but I didn't find it useful) > I *have* to use intelliJ to write java code, because it's so complicated to write anything in java that without a good IDE it takes forever. I agree wholeheartedly that Erlang is a better language precisely because I *don't* need an IDE to be productive with it. > > Sent from my iPhone > > On 07.02.2012, at 21:25, Tim Watson wrote: > > On 7 February 2012 11:27, Mihai Balea wrote: > >> >> On Feb 6, 2012, at 2:38 PM, Tim Watson wrote: >> >> On 6 February 2012 19:24, Jon Watte wrote: >> >>> That is interesting -- it might make it worth it to upgrade to R14. >>> >>> Also, we found a module called "gen_server2" that works around this >>> problem by draining the message queue before calling any callback, and >>> then dispatching messages based on this list of drained messages. Does >>> anyone have experience with this module? >>> >>> >> It is part of rabbitmq, which I'm guessing it's reasonable to call >> *fairly stable and production worthy* lol. I keep a copy as a standalone >> OTP library application on github, which I update/synchronise periodically >> with updates from the rabbit hg/git repository. I haven't refreshed it in a >> while, as we're largely >= R14 now, but I find this approach (of bundling >> it as a standalone library app) works nicely for making it available across >> projects, though I'm less reliant on it now as I'm not using the extra >> features it provides in addition to message queue draining. >> >> >> I wish there was an "official" standalone version of gen_server2. >> Rabbitmq includes it, the Erlang rabbitmq client includes it as well, >> riak_core too plus a variety of individuals like Tim have created >> standalone versions based on one of the above. If one attempts to combine, >> say, riak_core with the rabbitmq erlang client, frustration ensues. >> >> > Actually this issue (of duplicate uses of the same module name) has to do > with lack of namespace/package support and isn't so simple to solve - at > least based on the myriad discussions on this list regarding the issue, > none of which have yielded a satisfactory answer. Personally I think that > whilst the java/.net approach of providing a namespace such as > org.foobar.appname.package...etc might be flawed/imperfect, but it's a lot > better than having clashes. The reason it works well in practise is that > you can import modules via their namespace which reduces finger ache and > you can always fully qualify a *thing* you want to use if there is a > potential clash. Personally, I don't mind renaming gen_server2 to > nebularis_gen_server2 but I just don't want to have to type that all the > time. On the other hand, if packages were fully supported I could do this: > > -import(org.nebularis.gen_server2). > doodah() -> gen_server2:start(....). > > > But of course in todays system there are numerous tools (reltool, cover, > etc) that do not work properly with packages *and* you have to import "top > level" modules as well, which is just a pain in the arse: > > -import(lists). %% but why!!! > > I *know* there are potentially better ways and I fully recognise that > there is little difference semantically between a_b and a.b, but it's not a > about the separator, it's about the tedium of typing in long names, not to > mention the fact the > a_very_long_series_of_different_segments_separated_by_underscores is > appalling to read. > > Personally I'd like to see behaviours and import come together so I can > define take the gen_server(2) behaviour and import an implementation at the > top level: > > -api(gen_server2, nebularis_genserver2). > > >> Mihai >> >> > _______________________________________________ > 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 Tue Feb 7 22:18:14 2012 From: bourinov@REDACTED (Max Bourinov) Date: Wed, 8 Feb 2012 01:18:14 +0400 Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: References: <17A58775-B62F-4244-8DBF-5561F87D4FBC@hates.ms> <-8808220144167783942@unknownmsgid> Message-ID: <-1799286719738760728@unknownmsgid> I *don't* need an IDE to be productive with it. True. I use BBEdit. Sent from my iPhone On 08.02.2012, at 0:49, Tim Watson wrote: On 7 February 2012 19:39, Max Bourinov wrote: > I believe that Erlang is perfect the way it is. > I love Erlang's simplicity and it's been pretty much my favorite development platform for the past few years now. I would like to be able to refer to a module *via* some additional context though, whether that is the application it resides in or a package/namespace. > > I see problem in absence of good IDE/editors for Erlang (yes, emacs is way > not perfect). > > Personally I get along fine with vim, but erlide is cool for those who want to use it. > If there will be a tool like IntelliJ IDEA for Erlang, there will be no > problems with typing very_long_names any more. Auto completion rules. > > Yes but my point about very_long_module_names is not just that it is ugly and painful to type. I can get autocompletion in vim/emacs today so that's not the issue. The point is that as the number of libraries/applications I am able to choose from increases (and let's face it, they're growing fast) I'm increasingly being forced to deal with module name clashes *or* to put up with very long names which are distracting to look at - they take focus away from the *function* that is being called, which is what *I* want to focus on. Maybe it's just me, and I'm in no way suggesting I know how to fix this. I would like to be able to run rabbitmq and riak in the same vm without a module name clash though, and it is there that currently one of several things has to happen: 1. both rabbit and riak- rename their copy of gen_server2 to riak_gen_server2/rabbit_gen_server2 2. I let the first one on the code path get loaded and hope to the gods that it *behaves* properly for both applications 3. I give up and run them in a separate vm None of these are satisfactory, especially as (1) isn't likely to happen. What might make this go away could be something like: - module code scoped to "application domains" i.e., to the application the beam file resides in - so as not to clash - modules within the same "application domain" referring to one another default to the same domain - so if app1 contains [mod1, mod2] and mod1 calls a function via `mod2:do_it(...)` then the function is resolved to the module `mod2` in the same application domain - we get the ability to `import` modules from external application domains, so that I can call stuff in other apps when I want to. % import everything in kernel and stdlib - this should probably be a default attribute! -import_app([kernel, stdlib]). % import a specific module from a specific app-domain -import_mod(rabbitmq, [gen_server2]). start() -> %% this resolves to the gen_server2 beam which resides in the rabbitmq application gen_server2:start(...). (there is plugin for idea to write Erlang code, but I didn't find it useful) > I *have* to use intelliJ to write java code, because it's so complicated to write anything in java that without a good IDE it takes forever. I agree wholeheartedly that Erlang is a better language precisely because I *don't* need an IDE to be productive with it. > > Sent from my iPhone > > On 07.02.2012, at 21:25, Tim Watson wrote: > > On 7 February 2012 11:27, Mihai Balea wrote: > >> >> On Feb 6, 2012, at 2:38 PM, Tim Watson wrote: >> >> On 6 February 2012 19:24, Jon Watte wrote: >> >>> That is interesting -- it might make it worth it to upgrade to R14. >>> >>> Also, we found a module called "gen_server2" that works around this >>> problem by draining the message queue before calling any callback, and >>> then dispatching messages based on this list of drained messages. Does >>> anyone have experience with this module? >>> >>> >> It is part of rabbitmq, which I'm guessing it's reasonable to call >> *fairly stable and production worthy* lol. I keep a copy as a standalone >> OTP library application on github, which I update/synchronise periodically >> with updates from the rabbit hg/git repository. I haven't refreshed it in a >> while, as we're largely >= R14 now, but I find this approach (of bundling >> it as a standalone library app) works nicely for making it available across >> projects, though I'm less reliant on it now as I'm not using the extra >> features it provides in addition to message queue draining. >> >> >> I wish there was an "official" standalone version of gen_server2. >> Rabbitmq includes it, the Erlang rabbitmq client includes it as well, >> riak_core too plus a variety of individuals like Tim have created >> standalone versions based on one of the above. If one attempts to combine, >> say, riak_core with the rabbitmq erlang client, frustration ensues. >> >> > Actually this issue (of duplicate uses of the same module name) has to do > with lack of namespace/package support and isn't so simple to solve - at > least based on the myriad discussions on this list regarding the issue, > none of which have yielded a satisfactory answer. Personally I think that > whilst the java/.net approach of providing a namespace such as > org.foobar.appname.package...etc might be flawed/imperfect, but it's a lot > better than having clashes. The reason it works well in practise is that > you can import modules via their namespace which reduces finger ache and > you can always fully qualify a *thing* you want to use if there is a > potential clash. Personally, I don't mind renaming gen_server2 to > nebularis_gen_server2 but I just don't want to have to type that all the > time. On the other hand, if packages were fully supported I could do this: > > -import(org.nebularis.gen_server2). > doodah() -> gen_server2:start(....). > > > But of course in todays system there are numerous tools (reltool, cover, > etc) that do not work properly with packages *and* you have to import "top > level" modules as well, which is just a pain in the arse: > > -import(lists). %% but why!!! > > I *know* there are potentially better ways and I fully recognise that > there is little difference semantically between a_b and a.b, but it's not a > about the separator, it's about the tedium of typing in long names, not to > mention the fact the > a_very_long_series_of_different_segments_separated_by_underscores is > appalling to read. > > Personally I'd like to see behaviours and import come together so I can > define take the gen_server(2) behaviour and import an implementation at the > top level: > > -api(gen_server2, nebularis_genserver2). > > >> Mihai >> >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Tue Feb 7 22:38:25 2012 From: mfidelman@REDACTED (Miles Fidelman) Date: Tue, 07 Feb 2012 16:38:25 -0500 Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: References: <17A58775-B62F-4244-8DBF-5561F87D4FBC@hates.ms> <-8808220144167783942@unknownmsgid> <4F31803B.1040405@meetinghouse.net> Message-ID: <4F3199D1.3040608@meetinghouse.net> Vlad Dumitrescu wrote: > Hi, > > On Tue, Feb 7, 2012 at 20:49, Miles Fidelman wrote: > I'm starting to think that a smalltalk-like toolset would be great for > Erlang - browsers, inspectors, etc. for a long-running environment. A lot > of the pieces already exist, it would seem to be a matter of integration. > This is something that I have in mind for the future of erlide. It's > not as easy as it seems, especially as one has to invent new ways to > present information: for example, overviewing a system with several > thousands of processes... > Maybe borrow from: - operations management tools (e.g., as used to monitor lots of servers and services in a data center), and, - some of the emerging social network analysis tools and visualizations (e.g., as used to analyze communications patterns in a social network, particularly by the intelligence community) These sort of suggest: - big picture visualizations of process status and message flows - browsers and inspectors for drilling down into specific processes, message flows, specific messages Of course those are operations management and debugging tools. Something like a Smalltalk class browser might be nice for editing and distributing code modules - maybe tied to functions for visualizing and inspecting where those modules and functions are currently being instantiated in processes. Just some random thoughts. Cheers, Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From attila.r.nohl@REDACTED Tue Feb 7 23:00:32 2012 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Tue, 7 Feb 2012 23:00:32 +0100 Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: References: <17A58775-B62F-4244-8DBF-5561F87D4FBC@hates.ms> <-8808220144167783942@unknownmsgid> Message-ID: 2012/2/7, Tim Watson : [...] > Yes but my point about very_long_module_names is not just that it is ugly > and painful to type. I can get autocompletion in vim/emacs today so that's > not the issue. The point is that as the number of libraries/applications I > am able to choose from increases (and let's face it, they're growing fast) > I'm increasingly being forced to deal with module name clashes *or* to put > up with very long names which are distracting to look at - they take focus > away from the *function* that is being called, which is what *I* want to > focus on. In the AXD301 the module names were prefixed with the subsystem name, so for example many subsystems could have a library module with name like xyzLib. I guess this was enforced on project level. Honestly, C doesn't have packages either, still applications can use dozens of libraries. Even though the situation is not exactly the same (in C the internal names can "clash"), the API functions are (in many cases) religiously prefixed with the library name. An this worked for the last 40 years. From zvi.avraham@REDACTED Wed Feb 8 00:17:00 2012 From: zvi.avraham@REDACTED (Zvi) Date: Tue, 7 Feb 2012 15:17:00 -0800 (PST) Subject: [erlang-questions] the Israeli programming language Erlang In-Reply-To: References: Message-ID: Wow, Erlang is in US Jewish "mainstream" media :) The only Israeli programming language I ever programmed in was a Hebrew-flavored Prolog interpreter developed in Weizmann Institute of Science.t usi As far as I know Analyzd do not use Erlang whatsoever (only mainstream Java / C++). Anyway it's pathetic to call Klarna "Swedish-Israeli" company just because they acquired tiny Analyzd. Zvi On Feb 7, 2:38?am, Steve Davis wrote: > In: > > http://us.shalomlife.com/business/16634/swedish-israeli-payment-solut... > > There's this: > > "The company?s payment solutions,which are built using the Israeli > programming language Erlang" > > ...wow, that's certainly news to me... > > /s > _______________________________________________ > erlang-questions mailing list > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions From watson.timothy@REDACTED Wed Feb 8 02:06:48 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Wed, 8 Feb 2012 01:06:48 +0000 Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: References: <17A58775-B62F-4244-8DBF-5561F87D4FBC@hates.ms> <-8808220144167783942@unknownmsgid> Message-ID: On 7 February 2012 22:00, Attila Rajmund Nohl wrote: > 2012/2/7, Tim Watson : > [...] > > Yes but my point about very_long_module_names is not just that it is ugly > > and painful to type. I can get autocompletion in vim/emacs today so > that's > > not the issue. The point is that as the number of libraries/applications > I > > am able to choose from increases (and let's face it, they're growing > fast) > > I'm increasingly being forced to deal with module name clashes *or* to > put > > up with very long names which are distracting to look at - they take > focus > > away from the *function* that is being called, which is what *I* want to > > focus on. > > In the AXD301 the module names were prefixed with the subsystem name, > so for example many subsystems could have a library module with name > like xyzLib. I guess this was enforced on project level. > Yes I'm not surprised because everybody (including me) is still doing this today. You can see modules called riak_something and rabbitmq_something and mochiweb_something, etc etc. I have no problem with this, but if people *don't* follow this convention then you run into trouble. > > Honestly, C doesn't have packages either, still applications can use > dozens of libraries. Even though the situation is not exactly the same > (in C the internal names can "clash"), the API functions are (in many > cases) religiously prefixed with the library name. An this worked for > the last 40 years. > Yes it can be made to work with, as you put it, religious adherence to coding standards, but C is hardly the poster child for making this stuff easy. In fact C is notoriously annoying when it comes to name clashes, forcing you to write statically linked wrappers to re-export symbols with alternative names and/or mess around with symbol renaming tools. I'm sure there are many clever things that people do in order to make writing assembler code manageable, but that doesn't mean we should consider those good approaches for high level languages like Erlang does it? I suppose a simple approach to the "long names" complaint might be to write a common parse_transform that appends a configurable "__" prefix to modules during the build and generates a bit of metadata in the application config file. That way I can write my own code in a pithy fashion, have the generated modules *fully qualifies* and have other code that uses it consume the full name. If someone else wants to take advantage of the concise names, they can include the parse_transform in their build and take advantage of whatever `-special_import(...)` directive(s) it makes available for mapping short names to fully qualified module names during the AST transform. But I still think that having a coarser grained scoping/grouping construct than modules would be useful. This is obviously what applications are for, but they're not *first class* citizens in the way modules are. For example, another IMO great benefit that application level scoping of modules would bring is the ability to provide an export directive that makes functions callable from within your application (i.e., between the modules in app123) but *not* by outside callers. From an API design perspective, that would be very nice to have, as I often need to export shared code for use in my application but don't really want external callers to depend on it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinodhg@REDACTED Wed Feb 8 07:18:07 2012 From: vinodhg@REDACTED (Vinod H G) Date: Wed, 8 Feb 2012 11:48:07 +0530 Subject: [erlang-questions] finding module name clashes Message-ID: Hi, If i run "erl -pa my_path1 my_path2" and both have same module name my_module, my_module from my_path2 gets loaded. Is there a way to find out the module name clash or change the default behavior? Thanks & Regards, Vinod H. G. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Wed Feb 8 09:03:47 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Wed, 08 Feb 2012 09:03:47 +0100 Subject: [erlang-questions] finding module name clashes In-Reply-To: References: Message-ID: <4F322C63.8030104@gmail.com> On 02/08/2012 07:18 AM, Vinod H G wrote: > Hi, > > If i run "erl -pa my_path1 my_path2" and both have same module name > my_module, my_module from my_path2 gets loaded. > Is there a way to find out the module name clash or change the default > behavior? code:clash() reports all name clashes in the code path. You have to set up your path in a suitable order. code:get_path() returns the current path. You might want to use the -pz option instead for directories that should be added at the end of the path. /Richard From bengt.kleberg@REDACTED Wed Feb 8 11:02:37 2012 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Wed, 8 Feb 2012 11:02:37 +0100 Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: References: <17A58775-B62F-4244-8DBF-5561F87D4FBC@hates.ms> <-8808220144167783942@unknownmsgid> Message-ID: <1328695357.5625.28.camel@seasc1137> Greetings, To what extent would something like LACE (http://archive.eiffel.com/doc/manuals/technology/lace/subcluster/page.html), but for Erlang, handle your problems? bengt On Wed, 2012-02-08 at 02:06 +0100, Tim Watson wrote: > On 7 February 2012 22:00, Attila Rajmund Nohl > wrote: > 2012/2/7, Tim Watson : > [...] > > Yes but my point about very_long_module_names is not just > that it is ugly > > and painful to type. I can get autocompletion in vim/emacs > today so that's > > not the issue. The point is that as the number of > libraries/applications I > > am able to choose from increases (and let's face it, they're > growing fast) > > I'm increasingly being forced to deal with module name > clashes *or* to put > > up with very long names which are distracting to look at - > they take focus > > away from the *function* that is being called, which is what > *I* want to > > focus on. > > > In the AXD301 the module names were prefixed with the > subsystem name, > so for example many subsystems could have a library module > with name > like xyzLib. I guess this was enforced on project level. > > > Yes I'm not surprised because everybody (including me) is still doing > this today. You can see modules called riak_something and > rabbitmq_something and mochiweb_something, etc etc. I have no problem > with this, but if people *don't* follow this convention then you run > into trouble. > > > Honestly, C doesn't have packages either, still applications > can use > dozens of libraries. Even though the situation is not exactly > the same > (in C the internal names can "clash"), the API functions are > (in many > cases) religiously prefixed with the library name. An this > worked for > the last 40 years. > > Yes it can be made to work with, as you put it, religious adherence to > coding standards, but C is hardly the poster child for making this > stuff easy. In fact C is notoriously annoying when it comes to name > clashes, forcing you to write statically linked wrappers to re-export > symbols with alternative names and/or mess around with symbol renaming > tools. I'm sure there are many clever things that people do in order > to make writing assembler code manageable, but that doesn't mean we > should consider those good approaches for high level languages like > Erlang does it? > > > I suppose a simple approach to the "long names" complaint might be to > write a common parse_transform that appends a configurable > "__" prefix to modules during the build and > generates a bit of metadata in the application config file. That way I > can write my own code in a pithy fashion, have the generated modules > *fully qualifies* and have other code that uses it consume the full > name. If someone else wants to take advantage of the concise names, > they can include the parse_transform in their build and take advantage > of whatever `-special_import(...)` directive(s) it makes available for > mapping short names to fully qualified module names during the AST > transform. > > > But I still think that having a coarser grained scoping/grouping > construct than modules would be useful. This is obviously what > applications are for, but they're not *first class* citizens in the > way modules are. For example, another IMO great benefit that > application level scoping of modules would bring is the ability to > provide an export directive that makes functions callable from within > your application (i.e., between the modules in app123) but *not* by > outside callers. From an API design perspective, that would be very > nice to have, as I often need to export shared code for use in my > application but don't really want external callers to depend on it. > > From kilgoretrout62@REDACTED Wed Feb 8 12:49:56 2012 From: kilgoretrout62@REDACTED (kilgore trout) Date: Wed, 8 Feb 2012 11:49:56 +0000 Subject: [erlang-questions] Supervisor question Message-ID: Hello List, I have a newbie question. I've written myself a server process in basic Erlang and put it into a supervision tree. It all works fine but it always throws out a crash report on shutdown as it looks like it's not getting shut down when it should. I intend to redisgn it as a gen_server but for now I want to know how to make it shut down properly. In the supervisor's documentation I see the line: "Note that all child processes implemented using the standard OTP behavior modules automatically adhere to the shutdown protocol." Is there something simple I can add or remove to make my server appear like a "standard OTP behaviour"? Thanks in advance, KT. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Wed Feb 8 12:56:16 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Wed, 08 Feb 2012 12:56:16 +0100 Subject: [erlang-questions] Supervisor question In-Reply-To: References: Message-ID: <4F3262E0.2040806@gmail.com> On 02/08/2012 12:49 PM, kilgore trout wrote: > Hello List, > > I have a newbie question. I've written myself a server process in basic > Erlang and put it into a supervision tree. It all works fine but it > always throws out a crash report on shutdown as it looks like it's not > getting shut down when it should. I intend to redisgn it as a gen_server > but for now I want to know how to make it shut down properly. > > In the supervisor's documentation I see the line: "Note that all child > processes implemented using the standard OTP behavior modules > automatically adhere to the shutdown protocol." Is there something > simple I can add or remove to make my server appear like a "standard OTP > behaviour"? You could try a supervisor bridge: http://www.erlang.org/doc/man/supervisor_bridge.html /Richard From kilgoretrout62@REDACTED Wed Feb 8 13:17:21 2012 From: kilgoretrout62@REDACTED (kilgore trout) Date: Wed, 8 Feb 2012 12:17:21 +0000 Subject: [erlang-questions] Supervisor question In-Reply-To: <4F3262E0.2040806@gmail.com> References: <4F3262E0.2040806@gmail.com> Message-ID: That looks exactly like what I need. Thanks for the super-fast response! Regards, KT. On Wed, Feb 8, 2012 at 11:56 AM, Richard Carlsson < carlsson.richard@REDACTED> wrote: > On 02/08/2012 12:49 PM, kilgore trout wrote: > >> Hello List, >> >> I have a newbie question. I've written myself a server process in basic >> Erlang and put it into a supervision tree. It all works fine but it >> always throws out a crash report on shutdown as it looks like it's not >> getting shut down when it should. I intend to redisgn it as a gen_server >> but for now I want to know how to make it shut down properly. >> >> In the supervisor's documentation I see the line: "Note that all child >> processes implemented using the standard OTP behavior modules >> automatically adhere to the shutdown protocol." Is there something >> simple I can add or remove to make my server appear like a "standard OTP >> behaviour"? >> > > You could try a supervisor bridge: > > http://www.erlang.org/doc/man/**supervisor_bridge.html > > > /Richard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Wed Feb 8 13:53:37 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Wed, 8 Feb 2012 12:53:37 +0000 Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: <1328695357.5625.28.camel@seasc1137> References: <17A58775-B62F-4244-8DBF-5561F87D4FBC@hates.ms> <-8808220144167783942@unknownmsgid> <1328695357.5625.28.camel@seasc1137> Message-ID: IIRC Dr Richard O'Keefe has suggested something very similar to this approach. I think it is pretty much exactly what I want, especially given that you don't have to use oodles of sub-directories to structure the code. I'm perfectly happy having all my .erl sources under one folder versus the java debacle of a subfolder per package. I guess I don't fully see how this resolves the name clashing problem, but then I'm not that familiar with Eiffel or LACE. The laundry list for me then, looks a bit like this: 1. I'd like to minimise the risk of name clashes without having to add a massive prefix to my module names. In practise, even if I prefix with my application/library name there is a small change that someone else will come up with the same name and it might be necessary as a third party to use both dependencies (my foobar library and their foobar application) in order to access useful functionality that would take a long time to build from scratch. To avoid this situation fully, I've got to append my organisation/company name *and* application name to all modules then. Some modules require more than one *part* to their name, therefore I end up with crazy names like __ nebularis_ioutils_remote_resource_resolver I want to get away from having to put org + application in the module name somehow, and if something like LACE does this then great. 2. I'd like to export/share functions within an application (or "grouping construct" of some sort) but not outside it I need to export xoa_qa_stats_optimiser:sync_metadata/2 in order to use it in my application, but I *do not* want someone else's code to be able to call it. I know there is a proposed -export_to(...) directive, but that's a pretty fine grained approach and having to explicitly specify which modules I'm willing to share code with looks like a maintenance headache to me. 3. I'd like to have a *simple* way to switch between implementations that observe the same external interface For me, this could be as simple as being able to switch between modules that implement a custom behaviour. I think this plays into the same space as the recent discussion on this list about unifying the interfaces for dict/orddict/sets. I don't really know what the *best* solution to this looks like, but I guess what I'm after is an approach that *encourages* people to provide (or conform to) a common interface so that I don't have to rely on macros or worse, recoding my modules, when I switch from sets to ordsets, log4erl to lager or even mochiweb to misultin. I suspect that (3) is a bit out of place in this discussion, but I've dropped it in as all three of these issues make it harder to design an API that people can rely on and/or consume other people's APIs. As the level of code sharing in the Erlang/OTP world increases, this is becoming more of an issue at large. Hope that makes sense. Cheers, Tim On 8 February 2012 10:02, Bengt Kleberg wrote: > Greetings, > > To what extent would something like LACE > ( > http://archive.eiffel.com/doc/manuals/technology/lace/subcluster/page.html), > but for Erlang, handle your problems? > > > bengt > > On Wed, 2012-02-08 at 02:06 +0100, Tim Watson wrote: > > On 7 February 2012 22:00, Attila Rajmund Nohl > > wrote: > > 2012/2/7, Tim Watson : > > [...] > > > Yes but my point about very_long_module_names is not just > > that it is ugly > > > and painful to type. I can get autocompletion in vim/emacs > > today so that's > > > not the issue. The point is that as the number of > > libraries/applications I > > > am able to choose from increases (and let's face it, they're > > growing fast) > > > I'm increasingly being forced to deal with module name > > clashes *or* to put > > > up with very long names which are distracting to look at - > > they take focus > > > away from the *function* that is being called, which is what > > *I* want to > > > focus on. > > > > > > In the AXD301 the module names were prefixed with the > > subsystem name, > > so for example many subsystems could have a library module > > with name > > like xyzLib. I guess this was enforced on project level. > > > > > > Yes I'm not surprised because everybody (including me) is still doing > > this today. You can see modules called riak_something and > > rabbitmq_something and mochiweb_something, etc etc. I have no problem > > with this, but if people *don't* follow this convention then you run > > into trouble. > > > > > > Honestly, C doesn't have packages either, still applications > > can use > > dozens of libraries. Even though the situation is not exactly > > the same > > (in C the internal names can "clash"), the API functions are > > (in many > > cases) religiously prefixed with the library name. An this > > worked for > > the last 40 years. > > > > Yes it can be made to work with, as you put it, religious adherence to > > coding standards, but C is hardly the poster child for making this > > stuff easy. In fact C is notoriously annoying when it comes to name > > clashes, forcing you to write statically linked wrappers to re-export > > symbols with alternative names and/or mess around with symbol renaming > > tools. I'm sure there are many clever things that people do in order > > to make writing assembler code manageable, but that doesn't mean we > > should consider those good approaches for high level languages like > > Erlang does it? > > > > > > I suppose a simple approach to the "long names" complaint might be to > > write a common parse_transform that appends a configurable > > "__" prefix to modules during the build and > > generates a bit of metadata in the application config file. That way I > > can write my own code in a pithy fashion, have the generated modules > > *fully qualifies* and have other code that uses it consume the full > > name. If someone else wants to take advantage of the concise names, > > they can include the parse_transform in their build and take advantage > > of whatever `-special_import(...)` directive(s) it makes available for > > mapping short names to fully qualified module names during the AST > > transform. > > > > > > But I still think that having a coarser grained scoping/grouping > > construct than modules would be useful. This is obviously what > > applications are for, but they're not *first class* citizens in the > > way modules are. For example, another IMO great benefit that > > application level scoping of modules would bring is the ability to > > provide an export directive that makes functions callable from within > > your application (i.e., between the modules in app123) but *not* by > > outside callers. From an API design perspective, that would be very > > nice to have, as I often need to export shared code for use in my > > application but don't really want external callers to depend on it. > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emeka_1978@REDACTED Wed Feb 8 15:24:12 2012 From: emeka_1978@REDACTED (eigenfunction) Date: Wed, 8 Feb 2012 06:24:12 -0800 (PST) Subject: [erlang-questions] os:cmd Message-ID: <3d574332-3756-407b-b914-457ff83672fe@i2g2000vbv.googlegroups.com> I was wondering: is os:cmd("...") synchronous in the sense that the erlang process waits for the command to be executed completely before returning? From vladdu55@REDACTED Wed Feb 8 15:26:57 2012 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 8 Feb 2012 15:26:57 +0100 Subject: [erlang-questions] os:cmd In-Reply-To: <3d574332-3756-407b-b914-457ff83672fe@i2g2000vbv.googlegroups.com> References: <3d574332-3756-407b-b914-457ff83672fe@i2g2000vbv.googlegroups.com> Message-ID: Hi, On Wed, Feb 8, 2012 at 15:24, eigenfunction wrote: > I was wondering: is os:cmd("...") synchronous in the sense that the > erlang process waits for the command to be executed completely before > returning? Since it captures the console output and returns it as a string, then it must be synchronous. regards, Vlad From magnus.henoch@REDACTED Wed Feb 8 15:37:09 2012 From: magnus.henoch@REDACTED (Magnus Henoch) Date: Wed, 08 Feb 2012 14:37:09 -0000 (GMT) Subject: [erlang-questions] Dialyzer vs funs with unknown arity In-Reply-To: <4D9C8D99.5010507@cs.ntua.gr> Message-ID: <1c93d104-85da-40cf-915e-a56aad686727@knuth> > Magnus Henoch wrote: > > Hi all, > > > > I'm trying to get Dialyzer to accept a type spec containing a fun > > of > > unknown arity. According to the manual > > (http://www.erlang.org/doc/reference_manual/typespec.html) that > > should > > be fun((...) -> ReturnType), but when I run Dialyzer, it gives me > > an error. > > > > I'm probably missing something obvious but I really can't see > > it... > > You are not missing anything. I've submitted a patch about this > which > is currently cooking in 'pu'. Hopefully it will be ready soon. See: > > https://github.com/erlang/otp/commit/b92234d1b1b527bb56e5b66d206ea50fcb82c381 > > Kostis I just tried this with R15B, and it failed in the same way. Some searching revealed that this patch was dropped on 2011-04-13. Are there plans to fix this in some other way? Regards, -- Magnus Henoch Erlang Solutions Ltd http://www.erlang-solutions.com/ From michael.eugene.turner@REDACTED Wed Feb 8 16:15:35 2012 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Thu, 9 Feb 2012 00:15:35 +0900 Subject: [erlang-questions] the Israeli programming language Erlang In-Reply-To: <4F30BA80.3090601@camosun.bc.ca> References: <4F30BA80.3090601@camosun.bc.ca> Message-ID: I was alluding to this incident: http://spectrum.ieee.org/telecom/security/the-athens-affair/0 -michael On Tue, Feb 7, 2012 at 2:45 PM, Deryk Barker wrote: > On 06/02/12 20:14, Michael Turner wrote: >> >> I always thought Erlang was a Greek programming language. (Or am I >> thinking of PLEX?) ;-) >> > APL. > > deryk > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vinayakapawar@REDACTED Wed Feb 8 17:12:45 2012 From: vinayakapawar@REDACTED (Vinayak Pawar) Date: Wed, 8 Feb 2012 21:42:45 +0530 Subject: [erlang-questions] Detecting hot code swapping Message-ID: 1) How to detect whether any module of running Erlang application has been swapped? I want to create a table that records date, time and name of module that was swapped... 2) Is it possible to disable hot code swapping feature altogether? Thanks! Vinayak -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Wed Feb 8 17:20:25 2012 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Wed, 8 Feb 2012 08:20:25 -0800 (PST) Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: References: <17A58775-B62F-4244-8DBF-5561F87D4FBC@hates.ms> <-8808220144167783942@unknownmsgid> Message-ID: <1328718025.64319.YahooMailNeo@web111411.mail.gq1.yahoo.com> >________________________________ > From: Tim Watson > ... > >But I still think that having a coarser grained scoping/grouping construct than modules would be useful. This is obviously what applications are for, but they're not *first class* citizens in the way modules are. For example,?another IMO great benefit that application level scoping of modules would bring is the ability to provide an export directive that makes functions callable from within your application (i.e., between the modules in app123) but *not* by outside callers. From an API design perspective, that would be very nice to have, as I often need to export shared code for use in my application but don't really want external callers to depend on it. As I recall, the original packages release had semantic problems with atoms used as module names. Has this been fixed? For example, if memory serves, the following didn't do what one might expect: -import(org.proj.app.mod, mod). foo() -> ? ?M = mod, ? ?M:start_link(). ? %% will not invoke org.proj.app.mod:start_link() (It got more confusing when you passed 'mod' into another scope.) Best regards, Thomas From essen@REDACTED Wed Feb 8 19:29:33 2012 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Wed, 08 Feb 2012 19:29:33 +0100 Subject: [erlang-questions] Missing binary BIFs Message-ID: <4F32BF0D.9060001@ninenines.eu> Hello, It feels a bit tedious to keep doing things like list_to_binary(integer_to_list(42)) or even list_to_binary(atom_to_list(forty_two)) when we could have convenient integer_to_binary/1 or /2 or atom_to_list/1 BIFs. Is there any chance to add them in a future release? With all the advantages of binaries it's a shame it's not easier to deal with them. Thanks. -- Lo?c Hoguin Erlang Cowboy Nine Nines From baliulia@REDACTED Wed Feb 8 19:34:23 2012 From: baliulia@REDACTED (=?UTF-8?B?SWduYXMgVnnFoW5pYXVza2Fz?=) Date: Wed, 08 Feb 2012 18:34:23 +0000 Subject: [erlang-questions] Missing binary BIFs In-Reply-To: <4F32BF0D.9060001@ninenines.eu> References: <4F32BF0D.9060001@ninenines.eu> Message-ID: <4F32C02F.2070007@gmail.com> Hi, On 2012.02.08 18:29, Lo?c Hoguin wrote: > It feels a bit tedious to keep doing things like > list_to_binary(integer_to_list(42)) <<42>> /= <<"42">>, so this would be ambigous. > or even > list_to_binary(atom_to_list(forty_two)) > Check out atom_to_binary/2. Ignas From andrew@REDACTED Wed Feb 8 19:37:53 2012 From: andrew@REDACTED (Andrew Thompson) Date: Wed, 8 Feb 2012 13:37:53 -0500 Subject: [erlang-questions] Missing binary BIFs In-Reply-To: <4F32C02F.2070007@gmail.com> References: <4F32BF0D.9060001@ninenines.eu> <4F32C02F.2070007@gmail.com> Message-ID: <20120208183753.GC10141@hijacked.us> On Wed, Feb 08, 2012 at 06:34:23PM +0000, Ignas Vy?niauskas wrote: > Hi, > > On 2012.02.08 18:29, Lo?c Hoguin wrote: > > It feels a bit tedious to keep doing things like > > list_to_binary(integer_to_list(42)) > > <<42>> /= <<"42">>, so this would be ambigous. By that logic, integer_to_list is also ambigous, since [42] /= "42". I think it's pretty clear what integer_to_binary should do, and there's no reason to force people to use a list as an intermediate representation. Andrew From watson.timothy@REDACTED Wed Feb 8 19:42:11 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Wed, 8 Feb 2012 18:42:11 +0000 Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: <1328718025.64319.YahooMailNeo@web111411.mail.gq1.yahoo.com> References: <17A58775-B62F-4244-8DBF-5561F87D4FBC@hates.ms> <-8808220144167783942@unknownmsgid> <1328718025.64319.YahooMailNeo@web111411.mail.gq1.yahoo.com> Message-ID: Not only this, but a number of important tools (including reltool and cover) don't work properly with the existing packages implementation. I think it's safe to say that as they exist today they're not usable. On 8 February 2012 16:20, Thomas Lindgren wrote: > > > > > > >________________________________ > > From: Tim Watson > > ... > > > >But I still think that having a coarser grained scoping/grouping > construct than modules would be useful. This is obviously what applications > are for, but they're not *first class* citizens in the way modules are. For > example, another IMO great benefit that application level scoping of > modules would bring is the ability to provide an export directive that > makes functions callable from within your application (i.e., between the > modules in app123) but *not* by outside callers. From an API design > perspective, that would be very nice to have, as I often need to export > shared code for use in my application but don't really want external > callers to depend on it. > > As I recall, the original packages release had semantic problems with > atoms used as module names. Has this been fixed? > For example, if memory serves, the following didn't do what one might > expect: > > > -import(org.proj.app.mod, mod). > > foo() -> > M = mod, > M:start_link(). %% will not invoke org.proj.app.mod:start_link() > > (It got more confusing when you passed 'mod' into another scope.) > > Best regards, > Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed Feb 8 20:21:37 2012 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 08 Feb 2012 20:21:37 +0100 Subject: [erlang-questions] Missing binary BIFs In-Reply-To: <4F32C02F.2070007@gmail.com> References: <4F32BF0D.9060001@ninenines.eu> <4F32C02F.2070007@gmail.com> Message-ID: <4F32CB41.4090108@ninenines.eu> On 02/08/2012 07:34 PM, Ignas Vy?niauskas wrote: >> or even >> list_to_binary(atom_to_list(forty_two)) >> > > Check out atom_to_binary/2. Right, missed that one. -- Lo?c Hoguin Erlang Cowboy Nine Nines From comptekki@REDACTED Wed Feb 8 20:34:33 2012 From: comptekki@REDACTED (Wes James) Date: Wed, 8 Feb 2012 12:34:33 -0700 Subject: [erlang-questions] got wx working with R15B on OS X Lion In-Reply-To: References: Message-ID: I just did this on a new machine and realize that ./configure should be ./configure --enable-m32-build for wxwidgets to work on Lion. -wes On Tue, Dec 20, 2011 at 8:45 PM, Wes James wrote: > How to get wx working in Erlang R15B on OS X Lion. ?(this is one way, > maybe there are others??) > > 1. install mac ports ( http://www.macports.org/ ) > 2. run: sudo port -f install wxwidgets > 3. in .bashrc add: > > export LDFLAGS='-L/opt/local/lib' > export CPPFLAGS='-I/opt/local/include' > export LD_LIBRARY_PATH=/opt/local/lib > export LD_INCLUDE_PATH=/opt/local/include > > 4. download Erlang R15B from erlang.org or > > git clone https://github.com/erlang/otp.git > > 5. in the src folder run: > > ?./otp_build autoconf > ./configure > make > make install > > (maybe one of the otp_buld options does these three installing in /usr/local ??) > > 6. run erl > > 7. run wx:demo(). to check if it runs > > I saw that there is a mac port of R14B04 that I was going to try next here: > > http://www.macports.org/ports.php?by=category&substr=erlang > > But R15B is working now, but with this error when running programs: > > > 2011-12-20 20:26:25.547 beam.smp[28373:e0b] CFURLCreateWithString was > passed this invalid URL string: '/Syst\ > em/Library/CoreServices/CommonCocoaPanels.bundle' (a file system path > instead of an URL string). The URL cre\ > ated will not work with most file URL functions. > CFURLCreateWithFileSystemPath or CFURLCreateWithFileSystemP\ > athRelativeToBase should be used instead. > > The wx gui debugger is so much better than the xwindow version on OS X > Lion. ?The worst thing was the pin-wheel of death when a window was > resized from the bottom right corner. ?The only resize that would work > was clicking on the green maximize button at the top left of a window. > > -wes From emeka_1978@REDACTED Wed Feb 8 21:13:23 2012 From: emeka_1978@REDACTED (eigenfunction) Date: Wed, 8 Feb 2012 12:13:23 -0800 (PST) Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: <-8808220144167783942@unknownmsgid> References: <17A58775-B62F-4244-8DBF-5561F87D4FBC@hates.ms> <-8808220144167783942@unknownmsgid> Message-ID: <95565657-080c-426b-87e9-44237fc401ef@b23g2000yqn.googlegroups.com> http://erlide.org is the best erlang ide hands down. It pretty much gives you all the goodies that the .net and the java folks enjoy in term of project oriented editing of many files. Then you just fire you shell and test your application like you would have had if you had used emacs or vi and something like sinan. But Erlide has the potential to put erlang on the map. I mean, i have worked with emacs before. Just my 2 cents. On Feb 7, 8:39?pm, Max Bourinov wrote: > I believe that Erlang is perfect the way it is. > > I see problem in absence of good IDE/editors for Erlang (yes, emacs is way > not perfect). > > If there will be a tool like IntelliJ IDEA for Erlang, there will be no > problems with typing very_long_names any more. Auto completion rules. > > (there is plugin for idea to write Erlang code, but I didn't find it useful) > > Sent from my iPhone > > On 07.02.2012, at 21:25, Tim Watson wrote: > > On 7 February 2012 11:27, Mihai Balea wrote: > > > > > > > > > > > > > On Feb 6, 2012, at 2:38 PM, Tim Watson wrote: > > > On 6 February 2012 19:24, Jon Watte wrote: > > >> That is interesting -- it might make it worth it to upgrade to R14. > > >> Also, we found a module called "gen_server2" that works around this > >> problem by draining the message queue before calling any callback, and > >> then dispatching messages based on this list of drained messages. Does > >> anyone have experience with this module? > > > It is part of rabbitmq, which I'm guessing it's reasonable to call *fairly > > stable and production worthy* lol. I keep a copy as a standalone OTP > > library application on github, which I update/synchronise periodically with > > updates from the rabbit hg/git repository. I haven't refreshed it in a > > while, as we're largely >= R14 now, but I find this approach (of bundling > > it as a standalone library app) works nicely for making it available across > > projects, though I'm less reliant on it now as I'm not using the extra > > features it provides in addition to message queue draining. > > > I wish there was an "official" standalone version of gen_server2. Rabbitmq > > includes it, the Erlang rabbitmq client includes it as well, riak_core too > > plus a variety of individuals like Tim have created standalone versions > > based on one of the above. If one attempts to combine, say, riak_core with > > the rabbitmq erlang client, frustration ensues. > > Actually this issue (of duplicate uses of the same module name) has to do > with lack of namespace/package support and isn't so simple to solve - at > least based on the myriad discussions on this list regarding the issue, > none of which have yielded a satisfactory answer. Personally I think that > whilst the java/.net approach of providing a namespace such as > org.foobar.appname.package...etc might be flawed/imperfect, but it's a lot > better than having clashes. The reason it works well in practise is that > you can import modules via their namespace which reduces finger ache and > you can always fully qualify a *thing* you want to use if there is a > potential clash. Personally, I don't mind renaming gen_server2 to > nebularis_gen_server2 but I just don't want to have to type that all the > time. On the other hand, if packages were fully supported I could do this: > > -import(org.nebularis.gen_server2). > doodah() -> gen_server2:start(....). > > But of course in todays system there are numerous tools (reltool, cover, > etc) that do not work properly with packages *and* you have to import "top > level" modules as well, which is just a pain in the arse: > > -import(lists). %% but why!!! > > I *know* there are potentially better ways and I fully recognise that there > is little difference semantically between a_b and a.b, but it's not a about > the separator, it's about the tedium of typing in long names, not to > mention the fact the > a_very_long_series_of_different_segments_separated_by_underscores is > appalling to read. > > Personally I'd like to see behaviours and import come together so I can > define take the gen_server(2) behaviour and import an implementation at the > top level: > > -api(gen_server2, nebularis_genserver2). > > > Mihai > > _______________________________________________ > erlang-questions mailing list > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions From mattevans123@REDACTED Thu Feb 9 00:11:47 2012 From: mattevans123@REDACTED (Matthew Evans) Date: Wed, 8 Feb 2012 18:11:47 -0500 Subject: [erlang-questions] LINX and Erlang Message-ID: Hi Group, I was wondering if anyone is aware of a NIF or driver for communication between LINX and Erlang?? Since LINX is an ENEA project (also Swedish) I was hoping that there might be something before I roll my own. The only think I've found so far is this: http://web.it.kth.se/~johanmon/theses/casas.pdf Thanks Matt From prashant.sharma@REDACTED Thu Feb 9 04:31:57 2012 From: prashant.sharma@REDACTED (Prashant Sharma) Date: Thu, 9 Feb 2012 09:01:57 +0530 Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: References: <17A58775-B62F-4244-8DBF-5561F87D4FBC@hates.ms> <-8808220144167783942@unknownmsgid> Message-ID: +1 for Tim's idea here. Above that I feel with the advent of autocompletion etc... and IDE's the code is less readable otherwise and becomes imperative to use them, thus they are not just an option. I love the way things are with vi/emacs. :) There is definitely a world of difference between JAVA( or others on similar lines.) and thus love to write code for them in IDEs. Wonder if something we could do, like clojure's clear cut idea of managing namespaces. :) On Wed, Feb 8, 2012 at 2:19 AM, Tim Watson wrote: > On 7 February 2012 19:39, Max Bourinov wrote: >> >> I believe that Erlang is perfect the way it is. > > > I love Erlang's simplicity and it's been pretty much my favorite development > platform for the past few years now. I would like to be able to refer to a > module *via* some additional context though, whether that is the application > it resides in or a package/namespace. > >> >> >> I see problem in absence of good IDE/editors for Erlang (yes, emacs is way >> not perfect). >> > > Personally I get along fine with vim, but erlide is cool for those who want > to use it. > >> >> If there will be a tool like IntelliJ IDEA for Erlang, there will be no >> problems with typing very_long_names any more. Auto completion rules. >> > > Yes but my point about very_long_module_names is not just that it is ugly > and painful to type. I can get autocompletion in vim/emacs today so that's > not the issue. The point is that as the number of libraries/applications I > am able to choose from increases (and let's face it, they're growing fast) > I'm increasingly being forced to deal with module name clashes *or* to put > up with very long names which are distracting to look at - they take focus > away from the *function* that is being called, which is what *I* want to > focus on. > > Maybe it's just me, and I'm in no way suggesting I know how to fix this. I > would like to be able to run rabbitmq and riak in the same vm without a > module name clash though, and it is there that currently one of several > things has to happen: > > 1. both rabbit and riak- rename their copy of gen_server2 to > riak_gen_server2/rabbit_gen_server2 > 2. I let the first one on the code path get loaded and hope to the gods that > it *behaves* properly for both applications > 3. I give up and run them in a separate vm > > None of these are satisfactory, especially as (1) isn't likely to happen. > What might make this go away could be something like: > > - module code scoped to "application domains" i.e., to the application the > beam file resides in - so as not to clash > - modules within the same "application domain" referring to one another > default to the same domain - so if app1 contains [mod1, mod2] and mod1 calls > a function via `mod2:do_it(...)` then the function is resolved to the module > `mod2` in the same application domain > - we get the ability to `import` modules from external application domains, > so that I can call stuff in other apps when I want to. > > % import everything in kernel and stdlib - this should probably be a default > attribute! > -import_app([kernel,?stdlib]). > > % import a specific module from a specific app-domain > -import_mod(rabbitmq, [gen_server2]). > > start() -> > ? ? %% this resolves to the gen_server2 beam which resides in the rabbitmq > application > ? ? gen_server2:start(...). > >> (there is plugin for idea to write Erlang code, but I didn't find it >> useful) > > > I *have* to use intelliJ to write java code, because it's so complicated to > write anything in java that without a good IDE it takes forever. I agree > wholeheartedly that Erlang is a better language precisely because I *don't* > need an IDE to be productive with it. > >> >> >> Sent from my iPhone >> >> On 07.02.2012, at 21:25, Tim Watson wrote: >> >> On 7 February 2012 11:27, Mihai Balea wrote: >>> >>> >>> On Feb 6, 2012, at 2:38 PM, Tim Watson wrote: >>> >>> On 6 February 2012 19:24, Jon Watte wrote: >>>> >>>> That is interesting -- it might make it worth it to upgrade to R14. >>>> >>>> Also, we found a module called "gen_server2" that works around this >>>> problem by draining the message queue before calling any callback, and >>>> then dispatching messages based on this list of drained messages. Does >>>> anyone have experience with this module? >>>> >>> >>> It is part of rabbitmq, which I'm guessing it's reasonable to call >>> *fairly stable and production worthy* lol. I keep a copy as a standalone OTP >>> library application on github, which I update/synchronise periodically with >>> updates from the rabbit hg/git repository. I haven't refreshed it in a >>> while, as we're largely >= R14 now, but I find this approach (of bundling it >>> as a standalone library app) works nicely for making it available across >>> projects, though I'm less reliant on it now as I'm not using the extra >>> features it provides in addition to message queue draining. >>> >>> >>> I wish there was an "official" standalone version of gen_server2. >>> Rabbitmq includes it, the Erlang rabbitmq client includes it as well, >>> riak_core too plus a variety of individuals like Tim have created standalone >>> versions based on one of the above. If one attempts to combine, say, >>> riak_core with the rabbitmq erlang client, frustration ensues. >>> >> >> Actually this issue (of duplicate uses of the same module name) has to do >> with lack of namespace/package support and isn't so simple to solve - at >> least based on the myriad discussions on this list regarding the issue, none >> of which have yielded a satisfactory answer. Personally I think that whilst >> the java/.net approach of providing a namespace such as >> org.foobar.appname.package...etc might be flawed/imperfect, but it's a lot >> better than having clashes. The reason it works well in practise is that you >> can import modules via their namespace which reduces finger ache and you can >> always fully qualify a *thing* you want to use if there is a potential >> clash. Personally, I don't mind renaming gen_server2 to >> nebularis_gen_server2 but I just don't want to have to type that all the >> time. On the other hand, if packages were fully supported I could do this: >> >> -import(org.nebularis.gen_server2). >> doodah() -> gen_server2:start(....). >> >> >> But of course in todays system there are numerous tools (reltool, cover, >> etc) that do not work properly with packages *and* you have to import "top >> level" modules as well, which is just a pain in the arse: >> >> -import(lists). %% but why!!! >> >> I *know* there are potentially better ways and I fully recognise that >> there is little difference semantically between a_b and a.b, but it's not a >> about the separator, it's about the tedium of typing in long names, not to >> mention the fact the >> a_very_long_series_of_different_segments_separated_by_underscores is >> appalling to read. >> >> Personally I'd like to see behaviours and import come together so I can >> define take the gen_server(2) behaviour and import an implementation at the >> top level: >> >> -api(gen_server2, nebularis_genserver2). >> >>> >>> Mihai >>> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Prashant Sharma Mtech CSE IIIT Hyderabad. "Hare Krishna" From ok@REDACTED Thu Feb 9 06:15:30 2012 From: ok@REDACTED (ok@REDACTED) Date: Thu, 9 Feb 2012 18:15:30 +1300 Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: References: <17A58775-B62F-4244-8DBF-5561F87D4FBC@hates.ms> <-8808220144167783942@unknownmsgid> Message-ID: <4ecaed69a1bade9221e94b1e4a41a73d.squirrel@chasm.otago.ac.nz> There _has_ been a proposal in this mailing list to manage module names from *outside* the module, so that all module names in a module can be short. This does have the consequence that the same atom may refer to different modules _in_ different modules, but if we are going to escape diamond dependencies we probably want that anyway. The main inspiration for the proposal was [Schmidt 82] Schmidt, Eric E. Controlling Large Software Development In a Distributed Environment. PhD thesis, University of California Berkeley, December, 1982. This thesis is available as XEROX PARC Technical Report CSL-82-7. The other inspiration was Eiffel's LACE. As other people have pointed out, the problem with long_module_names is NOT the burden of typing them. If you have a decent editor, that goes away. It is the burden of *reading* them, and the fact that it is such a slog making up (and reading) a name that reveals *where a module comes from* that there is little strength left to reveal (or understand) what it is *about*. No amount of Java-style dotted names and no amount of multi_word_names is going to do anything about versions, and in a sufficiently large system you may need two (or even more) versions of a module in active use at the same time *both* of which may need to be patched and reloaded. (Package X uses Foo-1.2.1; package Y uses Foo-2.1.3; they need to be upgraded to Foo-1.2.2 and Foo-2.1.4 respectively, without changing X to use Foo-2.1.*.) From chandrashekhar.mullaparthi@REDACTED Thu Feb 9 07:40:20 2012 From: chandrashekhar.mullaparthi@REDACTED (Chandru) Date: Thu, 9 Feb 2012 06:40:20 +0000 Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: <4ecaed69a1bade9221e94b1e4a41a73d.squirrel@chasm.otago.ac.nz> References: <17A58775-B62F-4244-8DBF-5561F87D4FBC@hates.ms> <-8808220144167783942@unknownmsgid> <4ecaed69a1bade9221e94b1e4a41a73d.squirrel@chasm.otago.ac.nz> Message-ID: On 9 February 2012 05:15, wrote: > > The main inspiration for the proposal was > [Schmidt 82] Schmidt, Eric E. > Controlling Large Software Development In a Distributed Environment. PhD > thesis, University of California Berkeley, December, 1982. > This thesis is available as XEROX PARC Technical Report CSL-82-7. > > Just started reading this, and I was pleasantly surprised to see how the "Description Files" map to erlang's .app files, and the "System Model" maps neatly on to the .rel file. Nice! Chandru -------------- next part -------------- An HTML attachment was scrubbed... URL: From rapsey@REDACTED Thu Feb 9 09:03:39 2012 From: rapsey@REDACTED (Rapsey) Date: Thu, 9 Feb 2012 09:03:39 +0100 Subject: [erlang-questions] Missing binary BIFs In-Reply-To: <4F32BF0D.9060001@ninenines.eu> References: <4F32BF0D.9060001@ninenines.eu> Message-ID: I wrote functions that convert between all types that I use constantly. Much easier to just force a specific type somewhere if you're not sure what the input type is going to be instead of doing checks everywhere or annoying conversions like the one you wrote. It has a dependency on mochinum:digits/1 though. tolist(<<_/binary>> = P) -> binary_to_list(P); tolist(P) when is_atom(P) -> atom_to_list(P); tolist(P) when is_integer(P) -> integer_to_list(P); tolist(P) when is_float(P) -> mochinum:digits(P); tolist(P) when is_list(P) -> P. tobin(<<_/binary>> = P) -> P; tobin(P) when is_list(P) -> iolist_to_binary(P); tobin(P) when is_atom(P) -> atom_to_binary(P,latin1); tobin(P) when is_integer(P) -> tobin(integer_to_list(P)); tobin(P) when is_float(P) -> tobin(mochinum:digits(P)). toatom(P) when is_binary(P) -> binary_to_atom(P,latin1); toatom(P) when is_list(P) -> list_to_atom(P); toatom(P) when is_atom(P) -> P. toint(<<_/binary>> = P) -> list_to_integer(binary_to_list(P)); toint([_|_] = P) -> list_to_integer(P); toint(P) when is_integer(P) -> P; toint(P) when is_float(P) -> erlang:round(P). tofloat(P) when is_integer(P) -> P / 1; tofloat(P) when is_float(P) -> P; tofloat(P) when is_binary(P) -> tofloat(binary_to_list(P)); tofloat(P) when is_list(P) -> Str = string:join(string:tokens(P,","),"."), case string:str(Str,".") of 0 -> tofloat(P ++ ".0"); _ -> list_to_float(Str) end; tofloat(P) -> list_to_float(tolist(P)). On Wed, Feb 8, 2012 at 7:29 PM, Lo?c Hoguin wrote: > Hello, > > It feels a bit tedious to keep doing things like > list_to_binary(integer_to_**list(42)) > > or even > list_to_binary(atom_to_list(**forty_two)) > > when we could have convenient integer_to_binary/1 or /2 or atom_to_list/1 > BIFs. > > Is there any chance to add them in a future release? With all the > advantages of binaries it's a shame it's not easier to deal with them. > > Thanks. > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > ______________________________**_________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/**listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oribrost@REDACTED Thu Feb 9 10:40:49 2012 From: oribrost@REDACTED (ori brost) Date: Thu, 9 Feb 2012 11:40:49 +0200 Subject: [erlang-questions] Fetching several ets keys Message-ID: Is there any way in ets to fetch values for several keys in 1 call? i.e. something like ets:multi_fetch(Tid, ["A","B","C","D"]) % will fetch all entries with keys A, B, C, D From dmkolesnikov@REDACTED Thu Feb 9 11:11:39 2012 From: dmkolesnikov@REDACTED (dmitry kolesnikov) Date: Thu, 9 Feb 2012 12:11:39 +0200 Subject: [erlang-questions] Fetching several ets keys In-Reply-To: References: Message-ID: <8835000436152470626@unknownmsgid> You could try ets:select or qlc interface. It table is not big enough then qlc and custom fold function would work: Q=qlc:q([ X || X <- ets:table(mytab)]), qlc:fold(FoldFun, [], Q) Best Regards, Dmitry >-|-|-*> On 9.2.2012, at 11.40, ori brost wrote: > Is there any way in ets to fetch values for several keys in 1 call? > i.e. something like > > ets:multi_fetch(Tid, ["A","B","C","D"]) % will fetch all entries with > keys A, B, C, D > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From essen@REDACTED Thu Feb 9 11:27:08 2012 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Thu, 09 Feb 2012 11:27:08 +0100 Subject: [erlang-questions] Missing binary BIFs In-Reply-To: References: <4F32BF0D.9060001@ninenines.eu> Message-ID: <4F339F7C.5080201@ninenines.eu> While seemingly practical, I'm not sure why I would want any place in my code where I wouldn't be sure what the input type is. Even with dialyzer checks I'm sure I would make false assumptions and get surprises here and there. I also would like an efficient solution, both in processing speed and memory use. Converting to list then binary isn't that great, even less so after module:function calls with guards. On 02/09/2012 09:03 AM, Rapsey wrote: > I wrote functions that convert between all types that I use constantly. > Much easier to just force a specific type somewhere if you're not sure > what the input type is going to be instead of doing checks everywhere or > annoying conversions like the one you wrote. > It has a dependency on mochinum:digits/1 though. > > tolist(<<_/binary>> = P) -> > binary_to_list(P); > tolist(P) when is_atom(P) -> > atom_to_list(P); > tolist(P) when is_integer(P) -> > integer_to_list(P); > tolist(P) when is_float(P) -> > mochinum:digits(P); > tolist(P) when is_list(P) -> > P. > > tobin(<<_/binary>> = P) -> > P; > tobin(P) when is_list(P) -> > iolist_to_binary(P); > tobin(P) when is_atom(P) -> > atom_to_binary(P,latin1); > tobin(P) when is_integer(P) -> > tobin(integer_to_list(P)); > tobin(P) when is_float(P) -> > tobin(mochinum:digits(P)). > > toatom(P) when is_binary(P) -> > binary_to_atom(P,latin1); > toatom(P) when is_list(P) -> > list_to_atom(P); > toatom(P) when is_atom(P) -> > P. > toint(<<_/binary>> = P) -> > list_to_integer(binary_to_list(P)); > toint([_|_] = P) -> > list_to_integer(P); > toint(P) when is_integer(P) -> > P; > toint(P) when is_float(P) -> > erlang:round(P). > tofloat(P) when is_integer(P) -> > P / 1; > tofloat(P) when is_float(P) -> > P; > tofloat(P) when is_binary(P) -> > tofloat(binary_to_list(P)); > tofloat(P) when is_list(P) -> > Str = string:join(string:tokens(P,","),"."), > case string:str(Str,".") of > 0 -> > tofloat(P ++ ".0"); > _ -> > list_to_float(Str) > end; > tofloat(P) -> > list_to_float(tolist(P)). > > > On Wed, Feb 8, 2012 at 7:29 PM, Lo?c Hoguin > wrote: > > Hello, > > It feels a bit tedious to keep doing things like > list_to_binary(integer_to___list(42)) > > or even > list_to_binary(atom_to_list(__forty_two)) > > when we could have convenient integer_to_binary/1 or /2 or > atom_to_list/1 BIFs. > > Is there any chance to add them in a future release? With all the > advantages of binaries it's a shame it's not easier to deal with them. > > Thanks. > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > _________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/__listinfo/erlang-questions > > > -- Lo?c Hoguin Erlang Cowboy Nine Nines From spawn.think@REDACTED Thu Feb 9 11:49:26 2012 From: spawn.think@REDACTED (Ahmed Omar) Date: Thu, 9 Feb 2012 11:49:26 +0100 Subject: [erlang-questions] Fetching several ets keys In-Reply-To: <8835000436152470626@unknownmsgid> References: <8835000436152470626@unknownmsgid> Message-ID: ets:select(Tid, [{{'$1','$2'},[{'==','$1',X}],['$_']}|| X<- ["A","B","C","D"]]). On Thu, Feb 9, 2012 at 11:11 AM, dmitry kolesnikov wrote: > You could try > ets:select or qlc interface. > > It table is not big enough then qlc and custom fold function would work: > > Q=qlc:q([ X || X <- ets:table(mytab)]), > qlc:fold(FoldFun, [], Q) > > Best Regards, > Dmitry >-|-|-*> > > > On 9.2.2012, at 11.40, ori brost wrote: > > > Is there any way in ets to fetch values for several keys in 1 call? > > i.e. something like > > > > ets:multi_fetch(Tid, ["A","B","C","D"]) % will fetch all entries with > > keys A, B, C, D > > _______________________________________________ > > erlang-questions mailing list > > 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 oribrost@REDACTED Thu Feb 9 11:59:37 2012 From: oribrost@REDACTED (ori brost) Date: Thu, 9 Feb 2012 12:59:37 +0200 Subject: [erlang-questions] Fetching several ets keys In-Reply-To: References: <8835000436152470626@unknownmsgid> Message-ID: Ahmed, The question is, will ets:select as you described be smart enough to run lookups for each X instead of doing a fold all over the ets and checking for every key whether it equals "A" or "B" or "C" or "D"? On Thu, Feb 9, 2012 at 12:49 PM, Ahmed Omar wrote: > ets:select(Tid, [{{'$1','$2'},[{'==','$1',X}],['$_']}|| X<- > ["A","B","C","D"]]). > > > On Thu, Feb 9, 2012 at 11:11 AM, dmitry kolesnikov > wrote: >> >> You could try >> ets:select or qlc interface. >> >> It table is not big enough then qlc and custom fold function would work: >> >> Q=qlc:q([ X || X <- ets:table(mytab)]), >> qlc:fold(FoldFun, [], Q) >> >> Best Regards, >> Dmitry >-|-|-*> >> >> >> On 9.2.2012, at 11.40, ori brost wrote: >> >> > Is there any way in ets to fetch values for several keys in 1 call? >> > i.e. something like >> > >> > ets:multi_fetch(Tid, ["A","B","C","D"]) % will fetch all entries with >> > keys A, B, C, D >> > _______________________________________________ >> > erlang-questions mailing list >> > 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 hynek@REDACTED Thu Feb 9 12:00:21 2012 From: hynek@REDACTED (Hynek Vychodil) Date: Thu, 9 Feb 2012 12:00:21 +0100 Subject: [erlang-questions] Fetching several ets keys In-Reply-To: References: <8835000436152470626@unknownmsgid> Message-ID: This code will cause table full scan which usually will be far slower than just [ V || K <- ["A","B","C","D"], V <- ets:lookup(Tid, K) ] except very small tables full scan will not be good idea. On Thu, Feb 9, 2012 at 11:49 AM, Ahmed Omar wrote: > ets:select(Tid, [{{'$1','$2'},[{'==','$1',X}],['$_']}|| X<- > ["A","B","C","D"]]). > > > On Thu, Feb 9, 2012 at 11:11 AM, dmitry kolesnikov > wrote: >> >> You could try >> ets:select or qlc interface. >> >> It table is not big enough then qlc and custom fold function would work: >> >> Q=qlc:q([ X || X <- ets:table(mytab)]), >> qlc:fold(FoldFun, [], Q) >> >> Best Regards, >> Dmitry >-|-|-*> >> >> >> On 9.2.2012, at 11.40, ori brost wrote: >> >> > Is there any way in ets to fetch values for several keys in 1 call? >> > i.e. something like >> > >> > ets:multi_fetch(Tid, ["A","B","C","D"]) % will fetch all entries with >> > keys A, B, C, D >> > _______________________________________________ >> > erlang-questions mailing list >> > 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 > -- Hynek Vychodil BI consultant GoodData n?m?st? 28. ??jna 1104/17, 602 00, Brno - ?ern? Pole Office: ? +420 530 50 7704 E-mail: ?hynek@REDACTED Web: ? ? www.gooddata.com From oribrost@REDACTED Thu Feb 9 12:02:05 2012 From: oribrost@REDACTED (ori brost) Date: Thu, 9 Feb 2012 13:02:05 +0200 Subject: [erlang-questions] Fetching several ets keys In-Reply-To: References: <8835000436152470626@unknownmsgid> Message-ID: The question is whether there is any way that I can avoid the "erlang-to-c call" cost and do these 4 lookups (i.e. with one ets call do lookup for all 4). On Thu, Feb 9, 2012 at 1:00 PM, Hynek Vychodil wrote: > This code will cause table full scan which usually will be far slower than just > [ V || K <- ["A","B","C","D"], V <- ets:lookup(Tid, K) ] > except very small tables full scan will not be good idea. > > On Thu, Feb 9, 2012 at 11:49 AM, Ahmed Omar wrote: >> ets:select(Tid, [{{'$1','$2'},[{'==','$1',X}],['$_']}|| X<- >> ["A","B","C","D"]]). >> >> >> On Thu, Feb 9, 2012 at 11:11 AM, dmitry kolesnikov >> wrote: >>> >>> You could try >>> ets:select or qlc interface. >>> >>> It table is not big enough then qlc and custom fold function would work: >>> >>> Q=qlc:q([ X || X <- ets:table(mytab)]), >>> qlc:fold(FoldFun, [], Q) >>> >>> Best Regards, >>> Dmitry >-|-|-*> >>> >>> >>> On 9.2.2012, at 11.40, ori brost wrote: >>> >>> > Is there any way in ets to fetch values for several keys in 1 call? >>> > i.e. something like >>> > >>> > ets:multi_fetch(Tid, ["A","B","C","D"]) % will fetch all entries with >>> > keys A, B, C, D >>> > _______________________________________________ >>> > erlang-questions mailing list >>> > 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 >> > > > > -- > Hynek Vychodil > BI consultant > > GoodData > n?m?st? 28. ??jna 1104/17, 602 00, Brno - ?ern? Pole > Office: ? +420 530 50 7704 > E-mail: ?hynek@REDACTED > Web: ? ? www.gooddata.com From spawn.think@REDACTED Thu Feb 9 12:09:21 2012 From: spawn.think@REDACTED (Ahmed Omar) Date: Thu, 9 Feb 2012 12:09:21 +0100 Subject: [erlang-questions] Fetching several ets keys In-Reply-To: References: <8835000436152470626@unknownmsgid> Message-ID: Hynek, Yes you are right, if the table is big full scan is not a good idea. 2012/2/9 ori brost > The question is whether there is any way that I can avoid the > "erlang-to-c call" cost and do these 4 lookups (i.e. with one ets call > do lookup for all 4). > > On Thu, Feb 9, 2012 at 1:00 PM, Hynek Vychodil wrote: > > This code will cause table full scan which usually will be far slower > than just > > [ V || K <- ["A","B","C","D"], V <- ets:lookup(Tid, K) ] > > except very small tables full scan will not be good idea. > > > > On Thu, Feb 9, 2012 at 11:49 AM, Ahmed Omar > wrote: > >> ets:select(Tid, [{{'$1','$2'},[{'==','$1',X}],['$_']}|| X<- > >> ["A","B","C","D"]]). > >> > >> > >> On Thu, Feb 9, 2012 at 11:11 AM, dmitry kolesnikov < > dmkolesnikov@REDACTED> > >> wrote: > >>> > >>> You could try > >>> ets:select or qlc interface. > >>> > >>> It table is not big enough then qlc and custom fold function would > work: > >>> > >>> Q=qlc:q([ X || X <- ets:table(mytab)]), > >>> qlc:fold(FoldFun, [], Q) > >>> > >>> Best Regards, > >>> Dmitry >-|-|-*> > >>> > >>> > >>> On 9.2.2012, at 11.40, ori brost wrote: > >>> > >>> > Is there any way in ets to fetch values for several keys in 1 call? > >>> > i.e. something like > >>> > > >>> > ets:multi_fetch(Tid, ["A","B","C","D"]) % will fetch all entries with > >>> > keys A, B, C, D > >>> > _______________________________________________ > >>> > erlang-questions mailing list > >>> > 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 > >> > > > > > > > > -- > > Hynek Vychodil > > BI consultant > > > > GoodData > > n?m?st? 28. ??jna 1104/17, 602 00, Brno - ?ern? Pole > > Office: +420 530 50 7704 > > E-mail: hynek@REDACTED > > Web: www.gooddata.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker@REDACTED Thu Feb 9 12:24:01 2012 From: sverker@REDACTED (Sverker Eriksson) Date: Thu, 9 Feb 2012 12:24:01 +0100 Subject: [erlang-questions] Fetching several ets keys In-Reply-To: References: <8835000436152470626@unknownmsgid> Message-ID: <4F33ACD1.5010602@erix.ericsson.se> ets:select will not do a full scan if the key is bound: ets:select(Tid, [{{Key,'_'},[],['$_']} || Key <- ["A","B","C"]]). But you should specify the key in the first part of the matchspec tuple, not use a $-variable and '=='. /Sverker, Erlang/OTP Ericsson Ahmed Omar wrote: > Hynek, > Yes you are right, if the table is big full scan is not a good idea. > > 2012/2/9 ori brost > > >> The question is whether there is any way that I can avoid the >> "erlang-to-c call" cost and do these 4 lookups (i.e. with one ets call >> do lookup for all 4). >> >> On Thu, Feb 9, 2012 at 1:00 PM, Hynek Vychodil wrote: >> >>> This code will cause table full scan which usually will be far slower >>> >> than just >> >>> [ V || K <- ["A","B","C","D"], V <- ets:lookup(Tid, K) ] >>> except very small tables full scan will not be good idea. >>> >>> On Thu, Feb 9, 2012 at 11:49 AM, Ahmed Omar >>> >> wrote: >> >>>> ets:select(Tid, [{{'$1','$2'},[{'==','$1',X}],['$_']}|| X<- >>>> ["A","B","C","D"]]). >>>> >>>> >>>> On Thu, Feb 9, 2012 at 11:11 AM, dmitry kolesnikov < >>>> >> dmkolesnikov@REDACTED> >> >>>> wrote: >>>> >>>>> You could try >>>>> ets:select or qlc interface. >>>>> >>>>> It table is not big enough then qlc and custom fold function would >>>>> >> work: >> >>>>> Q=qlc:q([ X || X <- ets:table(mytab)]), >>>>> qlc:fold(FoldFun, [], Q) >>>>> >>>>> Best Regards, >>>>> Dmitry >-|-|-*> >>>>> >>>>> >>>>> On 9.2.2012, at 11.40, ori brost wrote: >>>>> >>>>> >>>>>> Is there any way in ets to fetch values for several keys in 1 call? >>>>>> i.e. something like >>>>>> >>>>>> ets:multi_fetch(Tid, ["A","B","C","D"]) % will fetch all entries with >>>>>> keys A, B, C, D >>>>>> _______________________________________________ >>>>>> erlang-questions mailing list >>>>>> 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 >>>> >>>> >>> >>> -- >>> Hynek Vychodil >>> BI consultant >>> >>> GoodData >>> n?m?st? 28. ??jna 1104/17, 602 00, Brno - ?ern? Pole >>> Office: +420 530 50 7704 >>> E-mail: hynek@REDACTED >>> Web: www.gooddata.com >>> > > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From rtrlists@REDACTED Thu Feb 9 12:29:32 2012 From: rtrlists@REDACTED (Robert Raschke) Date: Thu, 9 Feb 2012 11:29:32 +0000 Subject: [erlang-questions] Missing binary BIFs In-Reply-To: <4F339F7C.5080201@ninenines.eu> References: <4F32BF0D.9060001@ninenines.eu> <4F339F7C.5080201@ninenines.eu> Message-ID: Are you guys sure you're not looking for term_to_binary/1 and binary_to_term/1 ? On Thu, Feb 9, 2012 at 10:27 AM, Lo?c Hoguin wrote: > While seemingly practical, I'm not sure why I would want any place in my > code where I wouldn't be sure what the input type is. Even with dialyzer > checks I'm sure I would make false assumptions and get surprises here and > there. > > I also would like an efficient solution, both in processing speed and > memory use. Converting to list then binary isn't that great, even less so > after module:function calls with guards. > > > On 02/09/2012 09:03 AM, Rapsey wrote: > >> I wrote functions that convert between all types that I use constantly. >> Much easier to just force a specific type somewhere if you're not sure >> what the input type is going to be instead of doing checks everywhere or >> annoying conversions like the one you wrote. >> It has a dependency on mochinum:digits/1 though. >> >> tolist(<<_/binary>> = P) -> >> binary_to_list(P); >> tolist(P) when is_atom(P) -> >> atom_to_list(P); >> tolist(P) when is_integer(P) -> >> integer_to_list(P); >> tolist(P) when is_float(P) -> >> mochinum:digits(P); >> tolist(P) when is_list(P) -> >> P. >> >> tobin(<<_/binary>> = P) -> >> P; >> tobin(P) when is_list(P) -> >> iolist_to_binary(P); >> tobin(P) when is_atom(P) -> >> atom_to_binary(P,latin1); >> tobin(P) when is_integer(P) -> >> tobin(integer_to_list(P)); >> tobin(P) when is_float(P) -> >> tobin(mochinum:digits(P)). >> >> toatom(P) when is_binary(P) -> >> binary_to_atom(P,latin1); >> toatom(P) when is_list(P) -> >> list_to_atom(P); >> toatom(P) when is_atom(P) -> >> P. >> toint(<<_/binary>> = P) -> >> list_to_integer(binary_to_**list(P)); >> toint([_|_] = P) -> >> list_to_integer(P); >> toint(P) when is_integer(P) -> >> P; >> toint(P) when is_float(P) -> >> erlang:round(P). >> tofloat(P) when is_integer(P) -> >> P / 1; >> tofloat(P) when is_float(P) -> >> P; >> tofloat(P) when is_binary(P) -> >> tofloat(binary_to_list(P)); >> tofloat(P) when is_list(P) -> >> Str = string:join(string:tokens(P,",**"),"."), >> case string:str(Str,".") of >> 0 -> >> tofloat(P ++ ".0"); >> _ -> >> list_to_float(Str) >> end; >> tofloat(P) -> >> list_to_float(tolist(P)). >> >> >> On Wed, Feb 8, 2012 at 7:29 PM, Lo?c Hoguin > > wrote: >> >> Hello, >> >> It feels a bit tedious to keep doing things like >> list_to_binary(integer_to___**list(42)) >> >> or even >> list_to_binary(atom_to_list(__**forty_two)) >> >> >> when we could have convenient integer_to_binary/1 or /2 or >> atom_to_list/1 BIFs. >> >> Is there any chance to add them in a future release? With all the >> advantages of binaries it's a shame it's not easier to deal with them. >> >> Thanks. >> >> -- >> Lo?c Hoguin >> Erlang Cowboy >> Nine Nines >> ______________________________**___________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> > >> http://erlang.org/mailman/__**listinfo/erlang-questions >> >> > >> >> >> > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > ______________________________**_________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/**listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Thu Feb 9 12:31:57 2012 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Thu, 09 Feb 2012 12:31:57 +0100 Subject: [erlang-questions] Missing binary BIFs In-Reply-To: References: <4F32BF0D.9060001@ninenines.eu> <4F339F7C.5080201@ninenines.eu> Message-ID: <4F33AEAD.6070003@ninenines.eu> Those encode the term in the Erlang term format, which has a very particular purpose. The functions I'm talking about are just conversion from one type to binary strings. On 02/09/2012 12:29 PM, Robert Raschke wrote: > Are you guys sure you're not looking for term_to_binary/1 and > binary_to_term/1 ? > > On Thu, Feb 9, 2012 at 10:27 AM, Lo?c Hoguin > wrote: > > While seemingly practical, I'm not sure why I would want any place > in my code where I wouldn't be sure what the input type is. Even > with dialyzer checks I'm sure I would make false assumptions and get > surprises here and there. > > I also would like an efficient solution, both in processing speed > and memory use. Converting to list then binary isn't that great, > even less so after module:function calls with guards. > > > On 02/09/2012 09:03 AM, Rapsey wrote: > > I wrote functions that convert between all types that I use > constantly. > Much easier to just force a specific type somewhere if you're > not sure > what the input type is going to be instead of doing checks > everywhere or > annoying conversions like the one you wrote. > It has a dependency on mochinum:digits/1 though. > > tolist(<<_/binary>> = P) -> > binary_to_list(P); > tolist(P) when is_atom(P) -> > atom_to_list(P); > tolist(P) when is_integer(P) -> > integer_to_list(P); > tolist(P) when is_float(P) -> > mochinum:digits(P); > tolist(P) when is_list(P) -> > P. > > tobin(<<_/binary>> = P) -> > P; > tobin(P) when is_list(P) -> > iolist_to_binary(P); > tobin(P) when is_atom(P) -> > atom_to_binary(P,latin1); > tobin(P) when is_integer(P) -> > tobin(integer_to_list(P)); > tobin(P) when is_float(P) -> > tobin(mochinum:digits(P)). > > toatom(P) when is_binary(P) -> > binary_to_atom(P,latin1); > toatom(P) when is_list(P) -> > list_to_atom(P); > toatom(P) when is_atom(P) -> > P. > toint(<<_/binary>> = P) -> > list_to_integer(binary_to___list(P)); > toint([_|_] = P) -> > list_to_integer(P); > toint(P) when is_integer(P) -> > P; > toint(P) when is_float(P) -> > erlang:round(P). > tofloat(P) when is_integer(P) -> > P / 1; > tofloat(P) when is_float(P) -> > P; > tofloat(P) when is_binary(P) -> > tofloat(binary_to_list(P)); > tofloat(P) when is_list(P) -> > Str = string:join(string:tokens(P,",__"),"."), > case string:str(Str,".") of > 0 -> > tofloat(P ++ ".0"); > _ -> > list_to_float(Str) > end; > tofloat(P) -> > list_to_float(tolist(P)). > > > On Wed, Feb 8, 2012 at 7:29 PM, Lo?c Hoguin > >> wrote: > > Hello, > > It feels a bit tedious to keep doing things like > list_to_binary(integer_to_____list(42)) > > or even > list_to_binary(atom_to_list(____forty_two)) > > > when we could have convenient integer_to_binary/1 or /2 or > atom_to_list/1 BIFs. > > Is there any chance to add them in a future release? With > all the > advantages of binaries it's a shame it's not easier to deal > with them. > > Thanks. > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > ___________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > > > http://erlang.org/mailman/____listinfo/erlang-questions > > > > > > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > _________________________________________________ > erlang-questions mailing list > 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 From spawn.think@REDACTED Thu Feb 9 12:42:46 2012 From: spawn.think@REDACTED (Ahmed Omar) Date: Thu, 9 Feb 2012 12:42:46 +0100 Subject: [erlang-questions] Fetching several ets keys In-Reply-To: <4F33ACD1.5010602@erix.ericsson.se> References: <8835000436152470626@unknownmsgid> <4F33ACD1.5010602@erix.ericsson.se> Message-ID: Thanks for the tip Sverker. 2012/2/9 Sverker Eriksson > ets:select will not do a full scan if the key is bound: > > ets:select(Tid, [{{Key,'_'},[],['$_']} || Key <- ["A","B","C"]]). > > But you should specify the key in the first part of the matchspec tuple, > not use a $-variable and '=='. > > /Sverker, Erlang/OTP Ericsson > > Ahmed Omar wrote: > >> Hynek, >> Yes you are right, if the table is big full scan is not a good idea. >> >> 2012/2/9 ori brost >> >> >> >>> The question is whether there is any way that I can avoid the >>> "erlang-to-c call" cost and do these 4 lookups (i.e. with one ets call >>> do lookup for all 4). >>> >>> On Thu, Feb 9, 2012 at 1:00 PM, Hynek Vychodil >>> wrote: >>> >>> >>>> This code will cause table full scan which usually will be far slower >>>> >>>> >>> than just >>> >>> >>>> [ V || K <- ["A","B","C","D"], V <- ets:lookup(Tid, K) ] >>>> except very small tables full scan will not be good idea. >>>> >>>> On Thu, Feb 9, 2012 at 11:49 AM, Ahmed Omar >>>> >>>> >>> wrote: >>> >>> >>>> ets:select(Tid, [{{'$1','$2'},[{'==','$1',X}],**['$_']}|| X<- >>>>> ["A","B","C","D"]]). >>>>> >>>>> >>>>> On Thu, Feb 9, 2012 at 11:11 AM, dmitry kolesnikov < >>>>> >>>>> >>>> dmkolesnikov@REDACTED> >>> >>> >>>> wrote: >>>>> >>>>> >>>>>> You could try >>>>>> ets:select or qlc interface. >>>>>> >>>>>> It table is not big enough then qlc and custom fold function would >>>>>> >>>>>> >>>>> work: >>> >>> >>>> Q=qlc:q([ X || X <- ets:table(mytab)]), >>>>>> qlc:fold(FoldFun, [], Q) >>>>>> >>>>>> Best Regards, >>>>>> Dmitry >-|-|-*> >>>>>> >>>>>> >>>>>> On 9.2.2012, at 11.40, ori brost wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Is there any way in ets to fetch values for several keys in 1 call? >>>>>>> i.e. something like >>>>>>> >>>>>>> ets:multi_fetch(Tid, ["A","B","C","D"]) % will fetch all entries with >>>>>>> keys A, B, C, D >>>>>>> ______________________________**_________________ >>>>>>> erlang-questions mailing list >>>>>>> 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 >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Hynek Vychodil >>>> BI consultant >>>> >>>> GoodData >>>> n?m?st? 28. ??jna 1104/17, 602 00, Brno - ?ern? Pole >>>> Office: +420 530 50 7704 >>>> E-mail: hynek@REDACTED >>>> Web: www.gooddata.com >>>> >>>> >>> >> ------------------------------**------------------------------** >> ------------ >> >> >> ______________________________**_________________ >> 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 Feb 9 12:48:10 2012 From: rtrlists@REDACTED (Robert Raschke) Date: Thu, 9 Feb 2012 11:48:10 +0000 Subject: [erlang-questions] Missing binary BIFs In-Reply-To: <4F33AEAD.6070003@ninenines.eu> References: <4F32BF0D.9060001@ninenines.eu> <4F339F7C.5080201@ninenines.eu> <4F33AEAD.6070003@ninenines.eu> Message-ID: Sure, but don't you usually use them in pairs? Just wondering cause list_to_binary/1 and binary_to_list/1 are not opposites of each other, that is, binary_to_list(list_to_binary(L)) /= L in general. But I'm guessing that probably doesn't matter for your use case. On Thu, Feb 9, 2012 at 11:31 AM, Lo?c Hoguin wrote: > Those encode the term in the Erlang term format, which has a very > particular purpose. The functions I'm talking about are just conversion > from one type to binary strings. > > > On 02/09/2012 12:29 PM, Robert Raschke wrote: > >> Are you guys sure you're not looking for term_to_binary/1 and >> binary_to_term/1 ? >> >> On Thu, Feb 9, 2012 at 10:27 AM, Lo?c Hoguin > > wrote: >> >> While seemingly practical, I'm not sure why I would want any place >> in my code where I wouldn't be sure what the input type is. Even >> with dialyzer checks I'm sure I would make false assumptions and get >> surprises here and there. >> >> I also would like an efficient solution, both in processing speed >> and memory use. Converting to list then binary isn't that great, >> even less so after module:function calls with guards. >> >> >> On 02/09/2012 09:03 AM, Rapsey wrote: >> >> I wrote functions that convert between all types that I use >> constantly. >> Much easier to just force a specific type somewhere if you're >> not sure >> what the input type is going to be instead of doing checks >> everywhere or >> annoying conversions like the one you wrote. >> It has a dependency on mochinum:digits/1 though. >> >> tolist(<<_/binary>> = P) -> >> binary_to_list(P); >> tolist(P) when is_atom(P) -> >> atom_to_list(P); >> tolist(P) when is_integer(P) -> >> integer_to_list(P); >> tolist(P) when is_float(P) -> >> mochinum:digits(P); >> tolist(P) when is_list(P) -> >> P. >> >> tobin(<<_/binary>> = P) -> >> P; >> tobin(P) when is_list(P) -> >> iolist_to_binary(P); >> tobin(P) when is_atom(P) -> >> atom_to_binary(P,latin1); >> tobin(P) when is_integer(P) -> >> tobin(integer_to_list(P)); >> tobin(P) when is_float(P) -> >> tobin(mochinum:digits(P)). >> >> toatom(P) when is_binary(P) -> >> binary_to_atom(P,latin1); >> toatom(P) when is_list(P) -> >> list_to_atom(P); >> toatom(P) when is_atom(P) -> >> P. >> toint(<<_/binary>> = P) -> >> list_to_integer(binary_to___**list(P)); >> >> toint([_|_] = P) -> >> list_to_integer(P); >> toint(P) when is_integer(P) -> >> P; >> toint(P) when is_float(P) -> >> erlang:round(P). >> tofloat(P) when is_integer(P) -> >> P / 1; >> tofloat(P) when is_float(P) -> >> P; >> tofloat(P) when is_binary(P) -> >> tofloat(binary_to_list(P)); >> tofloat(P) when is_list(P) -> >> Str = string:join(string:tokens(P,",**__"),"."), >> >> case string:str(Str,".") of >> 0 -> >> tofloat(P ++ ".0"); >> _ -> >> list_to_float(Str) >> end; >> tofloat(P) -> >> list_to_float(tolist(P)). >> >> >> On Wed, Feb 8, 2012 at 7:29 PM, Lo?c Hoguin > >> >> >> wrote: >> >> Hello, >> >> It feels a bit tedious to keep doing things like >> list_to_binary(integer_to_____**list(42)) >> >> or even >> list_to_binary(atom_to_list(__**__forty_two)) >> >> >> >> when we could have convenient integer_to_binary/1 or /2 or >> atom_to_list/1 BIFs. >> >> Is there any chance to add them in a future release? With >> all the >> advantages of binaries it's a shame it's not easier to deal >> with them. >> >> Thanks. >> >> -- >> Lo?c Hoguin >> Erlang Cowboy >> Nine Nines >> ______________________________**_____________________ >> >> erlang-questions mailing list >> erlang-questions@REDACTED >> > >> >> >> >> >> http://erlang.org/mailman/____**listinfo/erlang-questions >> >> > >> >> >> >> >> >> >> >> >> >> -- >> Lo?c Hoguin >> >> Erlang Cowboy >> Nine Nines >> ______________________________**___________________ >> erlang-questions mailing list >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Thu Feb 9 12:51:35 2012 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 09 Feb 2012 12:51:35 +0100 Subject: [erlang-questions] Missing binary BIFs In-Reply-To: References: <4F32BF0D.9060001@ninenines.eu> <4F339F7C.5080201@ninenines.eu> <4F33AEAD.6070003@ninenines.eu> Message-ID: <4F33B347.7080008@ninenines.eu> Hm I would be very surprised if binary_to_list(list_to_binary(L)) /= L wouldn't be true. Do you have an example of this? On 02/09/2012 12:48 PM, Robert Raschke wrote: > Sure, but don't you usually use them in pairs? Just wondering cause > list_to_binary/1 and binary_to_list/1 are not opposites of each other, > that is, binary_to_list(list_to_binary(L)) /= L in general. But I'm > guessing that probably doesn't matter for your use case. > > On Thu, Feb 9, 2012 at 11:31 AM, Lo?c Hoguin > wrote: > > Those encode the term in the Erlang term format, which has a very > particular purpose. The functions I'm talking about are just > conversion from one type to binary strings. > > > On 02/09/2012 12:29 PM, Robert Raschke wrote: > > Are you guys sure you're not looking for term_to_binary/1 and > binary_to_term/1 ? > > On Thu, Feb 9, 2012 at 10:27 AM, Lo?c Hoguin > >> wrote: > > While seemingly practical, I'm not sure why I would want any > place > in my code where I wouldn't be sure what the input type is. Even > with dialyzer checks I'm sure I would make false assumptions > and get > surprises here and there. > > I also would like an efficient solution, both in processing > speed > and memory use. Converting to list then binary isn't that great, > even less so after module:function calls with guards. > > > On 02/09/2012 09:03 AM, Rapsey wrote: > > I wrote functions that convert between all types that I use > constantly. > Much easier to just force a specific type somewhere if > you're > not sure > what the input type is going to be instead of doing checks > everywhere or > annoying conversions like the one you wrote. > It has a dependency on mochinum:digits/1 though. > > tolist(<<_/binary>> = P) -> > binary_to_list(P); > tolist(P) when is_atom(P) -> > atom_to_list(P); > tolist(P) when is_integer(P) -> > integer_to_list(P); > tolist(P) when is_float(P) -> > mochinum:digits(P); > tolist(P) when is_list(P) -> > P. > > tobin(<<_/binary>> = P) -> > P; > tobin(P) when is_list(P) -> > iolist_to_binary(P); > tobin(P) when is_atom(P) -> > atom_to_binary(P,latin1); > tobin(P) when is_integer(P) -> > tobin(integer_to_list(P)); > tobin(P) when is_float(P) -> > tobin(mochinum:digits(P)). > > toatom(P) when is_binary(P) -> > binary_to_atom(P,latin1); > toatom(P) when is_list(P) -> > list_to_atom(P); > toatom(P) when is_atom(P) -> > P. > toint(<<_/binary>> = P) -> > list_to_integer(binary_to_____list(P)); > > toint([_|_] = P) -> > list_to_integer(P); > toint(P) when is_integer(P) -> > P; > toint(P) when is_float(P) -> > erlang:round(P). > tofloat(P) when is_integer(P) -> > P / 1; > tofloat(P) when is_float(P) -> > P; > tofloat(P) when is_binary(P) -> > tofloat(binary_to_list(P)); > tofloat(P) when is_list(P) -> > Str = string:join(string:tokens(P,",____"),"."), > > case string:str(Str,".") of > 0 -> > tofloat(P ++ ".0"); > _ -> > list_to_float(Str) > end; > tofloat(P) -> > list_to_float(tolist(P)). > > > On Wed, Feb 8, 2012 at 7:29 PM, Lo?c Hoguin > > > > > > >>> wrote: > > Hello, > > It feels a bit tedious to keep doing things like > list_to_binary(integer_to_______list(42)) > > or even > list_to_binary(atom_to_list(______forty_two)) > > > > when we could have convenient integer_to_binary/1 or > /2 or > atom_to_list/1 BIFs. > > Is there any chance to add them in a future release? > With > all the > advantages of binaries it's a shame it's not easier > to deal > with them. > > Thanks. > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > _____________________________________________________ > > erlang-questions mailing list > erlang-questions@REDACTED > > > __erl__ang.org > >> > http://erlang.org/mailman/______listinfo/erlang-questions > > > > > > >> > > > > > -- > Lo?c Hoguin > > Erlang Cowboy > Nine Nines > ___________________________________________________ > erlang-questions mailing list > 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 > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Lo?c Hoguin Erlang Cowboy Nine Nines From rtrlists@REDACTED Thu Feb 9 12:54:32 2012 From: rtrlists@REDACTED (Robert Raschke) Date: Thu, 9 Feb 2012 11:54:32 +0000 Subject: [erlang-questions] Missing binary BIFs In-Reply-To: <4F33B347.7080008@ninenines.eu> References: <4F32BF0D.9060001@ninenines.eu> <4F339F7C.5080201@ninenines.eu> <4F33AEAD.6070003@ninenines.eu> <4F33B347.7080008@ninenines.eu> Message-ID: (erl@REDACTED)6> list_to_binary([1, [2], 3]). <<1,2,3>> (erl@REDACTED)7> binary_to_list(list_to_binary([1, [2], 3])). [1,2,3] (erl@REDACTED)8> But I see you are using iolist, so you are probably not interested in nested lists keeping their structure. On Thu, Feb 9, 2012 at 11:51 AM, Lo?c Hoguin wrote: > Hm I would be very surprised if binary_to_list(list_to_binary(**L)) /= L > wouldn't be true. Do you have an example of this? > > > On 02/09/2012 12:48 PM, Robert Raschke wrote: > >> Sure, but don't you usually use them in pairs? Just wondering cause >> list_to_binary/1 and binary_to_list/1 are not opposites of each other, >> that is, binary_to_list(list_to_binary(**L)) /= L in general. But I'm >> guessing that probably doesn't matter for your use case. >> >> On Thu, Feb 9, 2012 at 11:31 AM, Lo?c Hoguin > > wrote: >> >> Those encode the term in the Erlang term format, which has a very >> particular purpose. The functions I'm talking about are just >> conversion from one type to binary strings. >> >> >> On 02/09/2012 12:29 PM, Robert Raschke wrote: >> >> Are you guys sure you're not looking for term_to_binary/1 and >> binary_to_term/1 ? >> >> On Thu, Feb 9, 2012 at 10:27 AM, Lo?c Hoguin > >> >> wrote: >> >> While seemingly practical, I'm not sure why I would want any >> place >> in my code where I wouldn't be sure what the input type is. >> Even >> with dialyzer checks I'm sure I would make false assumptions >> and get >> surprises here and there. >> >> I also would like an efficient solution, both in processing >> speed >> and memory use. Converting to list then binary isn't that >> great, >> even less so after module:function calls with guards. >> >> >> On 02/09/2012 09:03 AM, Rapsey wrote: >> >> I wrote functions that convert between all types that I use >> constantly. >> Much easier to just force a specific type somewhere if >> you're >> not sure >> what the input type is going to be instead of doing checks >> everywhere or >> annoying conversions like the one you wrote. >> It has a dependency on mochinum:digits/1 though. >> >> tolist(<<_/binary>> = P) -> >> binary_to_list(P); >> tolist(P) when is_atom(P) -> >> atom_to_list(P); >> tolist(P) when is_integer(P) -> >> integer_to_list(P); >> tolist(P) when is_float(P) -> >> mochinum:digits(P); >> tolist(P) when is_list(P) -> >> P. >> >> tobin(<<_/binary>> = P) -> >> P; >> tobin(P) when is_list(P) -> >> iolist_to_binary(P); >> tobin(P) when is_atom(P) -> >> atom_to_binary(P,latin1); >> tobin(P) when is_integer(P) -> >> tobin(integer_to_list(P)); >> tobin(P) when is_float(P) -> >> tobin(mochinum:digits(P)). >> >> toatom(P) when is_binary(P) -> >> binary_to_atom(P,latin1); >> toatom(P) when is_list(P) -> >> list_to_atom(P); >> toatom(P) when is_atom(P) -> >> P. >> toint(<<_/binary>> = P) -> >> list_to_integer(binary_to_____**list(P)); >> >> >> toint([_|_] = P) -> >> list_to_integer(P); >> toint(P) when is_integer(P) -> >> P; >> toint(P) when is_float(P) -> >> erlang:round(P). >> tofloat(P) when is_integer(P) -> >> P / 1; >> tofloat(P) when is_float(P) -> >> P; >> tofloat(P) when is_binary(P) -> >> tofloat(binary_to_list(P)); >> tofloat(P) when is_list(P) -> >> Str = string:join(string:tokens(P,",**____"),"."), >> >> >> case string:str(Str,".") of >> 0 -> >> tofloat(P ++ ".0"); >> _ -> >> list_to_float(Str) >> end; >> tofloat(P) -> >> list_to_float(tolist(P)). >> >> >> On Wed, Feb 8, 2012 at 7:29 PM, Lo?c Hoguin >> >> > >> >> >> >>> wrote: >> >> Hello, >> >> It feels a bit tedious to keep doing things like >> list_to_binary(integer_to_____**__list(42)) >> >> or even >> list_to_binary(atom_to_list(__**____forty_two)) >> >> >> >> >> when we could have convenient integer_to_binary/1 or >> /2 or >> atom_to_list/1 BIFs. >> >> Is there any chance to add them in a future release? >> With >> all the >> advantages of binaries it's a shame it's not easier >> to deal >> with them. >> >> Thanks. >> >> -- >> Lo?c Hoguin >> Erlang Cowboy >> Nine Nines >> ______________________________** >> _______________________ >> >> >> erlang-questions mailing list >> erlang-questions@REDACTED >> > >> >> >> >> >> > __er**l__ang.org < >> http://erlang.org> >> >> >> >>> >> http://erlang.org/mailman/____**__listinfo/erlang-questions >> >> > >> >> >> >> >> >> >> >> >> > >> >> >> >>> >> >> >> >> >> -- >> Lo?c Hoguin >> >> Erlang Cowboy >> Nine Nines >> ______________________________**_____________________ >> erlang-questions mailing list >> 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 >> >> >> >> >> ______________________________**_________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/**listinfo/erlang-questions >> > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Thu Feb 9 12:57:28 2012 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 09 Feb 2012 12:57:28 +0100 Subject: [erlang-questions] Missing binary BIFs In-Reply-To: References: <4F32BF0D.9060001@ninenines.eu> <4F339F7C.5080201@ninenines.eu> <4F33AEAD.6070003@ninenines.eu> <4F33B347.7080008@ninenines.eu> Message-ID: <4F33B4A8.9080708@ninenines.eu> Oh, didn't think it accepted nested lists. That's good to know, thanks. And yeah I'm not interested in the structure, just the representation when printed as text. On 02/09/2012 12:54 PM, Robert Raschke wrote: > (erl@REDACTED)6> list_to_binary([1, [2], 3]). > <<1,2,3>> > (erl@REDACTED)7> binary_to_list(list_to_binary([1, [2], 3])). > [1,2,3] > (erl@REDACTED)8> > > But I see you are using iolist, so you are probably not interested in > nested lists keeping their structure. > > On Thu, Feb 9, 2012 at 11:51 AM, Lo?c Hoguin > wrote: > > Hm I would be very surprised if binary_to_list(list_to_binary(__L)) > /= L wouldn't be true. Do you have an example of this? > > > On 02/09/2012 12:48 PM, Robert Raschke wrote: > > Sure, but don't you usually use them in pairs? Just wondering cause > list_to_binary/1 and binary_to_list/1 are not opposites of each > other, > that is, binary_to_list(list_to_binary(__L)) /= L in general. > But I'm > guessing that probably doesn't matter for your use case. > > On Thu, Feb 9, 2012 at 11:31 AM, Lo?c Hoguin > >> wrote: > > Those encode the term in the Erlang term format, which has a > very > particular purpose. The functions I'm talking about are just > conversion from one type to binary strings. > > > On 02/09/2012 12:29 PM, Robert Raschke wrote: > > Are you guys sure you're not looking for > term_to_binary/1 and > binary_to_term/1 ? > > On Thu, Feb 9, 2012 at 10:27 AM, Lo?c Hoguin > > > > > >>> wrote: > > While seemingly practical, I'm not sure why I would > want any > place > in my code where I wouldn't be sure what the input > type is. Even > with dialyzer checks I'm sure I would make false > assumptions > and get > surprises here and there. > > I also would like an efficient solution, both in > processing > speed > and memory use. Converting to list then binary isn't > that great, > even less so after module:function calls with guards. > > > On 02/09/2012 09:03 AM, Rapsey wrote: > > I wrote functions that convert between all types > that I use > constantly. > Much easier to just force a specific type > somewhere if > you're > not sure > what the input type is going to be instead of > doing checks > everywhere or > annoying conversions like the one you wrote. > It has a dependency on mochinum:digits/1 though. > > tolist(<<_/binary>> = P) -> > binary_to_list(P); > tolist(P) when is_atom(P) -> > atom_to_list(P); > tolist(P) when is_integer(P) -> > integer_to_list(P); > tolist(P) when is_float(P) -> > mochinum:digits(P); > tolist(P) when is_list(P) -> > P. > > tobin(<<_/binary>> = P) -> > P; > tobin(P) when is_list(P) -> > iolist_to_binary(P); > tobin(P) when is_atom(P) -> > atom_to_binary(P,latin1); > tobin(P) when is_integer(P) -> > tobin(integer_to_list(P)); > tobin(P) when is_float(P) -> > tobin(mochinum:digits(P)). > > toatom(P) when is_binary(P) -> > binary_to_atom(P,latin1); > toatom(P) when is_list(P) -> > list_to_atom(P); > toatom(P) when is_atom(P) -> > P. > toint(<<_/binary>> = P) -> > list_to_integer(binary_to_______list(P)); > > > toint([_|_] = P) -> > list_to_integer(P); > toint(P) when is_integer(P) -> > P; > toint(P) when is_float(P) -> > erlang:round(P). > tofloat(P) when is_integer(P) -> > P / 1; > tofloat(P) when is_float(P) -> > P; > tofloat(P) when is_binary(P) -> > tofloat(binary_to_list(P)); > tofloat(P) when is_list(P) -> > Str = string:join(string:tokens(P,",______"),"."), > > > case string:str(Str,".") of > 0 -> > tofloat(P ++ ".0"); > _ -> > list_to_float(Str) > end; > tofloat(P) -> > list_to_float(tolist(P)). > > > On Wed, Feb 8, 2012 at 7:29 PM, Lo?c Hoguin > > > > > >> > > > > > > >>>> wrote: > > Hello, > > It feels a bit tedious to keep doing things like > list_to_binary(integer_to_________list(42)) > > or even > > list_to_binary(atom_to_list(________forty_two)) > > > > > when we could have convenient > integer_to_binary/1 or > /2 or > atom_to_list/1 BIFs. > > Is there any chance to add them in a future > release? > With > all the > advantages of binaries it's a shame it's not > easier > to deal > with them. > > Thanks. > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > > _______________________________________________________ > > > erlang-questions mailing list > erlang-questions@REDACTED > > > __erl__ang.org > >> > > >__er__l__ang.org > > __erl__ang.org > >>> > http://erlang.org/mailman/________listinfo/erlang-questions > > > > > > >> > > > > > > >>> > > > > > -- > Lo?c Hoguin > > Erlang Cowboy > Nine Nines > _____________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > > > __erl__ang.org > >> > 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 > > > > > _________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/__listinfo/erlang-questions > > > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > > -- Lo?c Hoguin Erlang Cowboy Nine Nines From bengt.kleberg@REDACTED Thu Feb 9 14:53:50 2012 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 9 Feb 2012 14:53:50 +0100 Subject: [erlang-questions] beginner: How make reltool handle multiple versions of libs? Message-ID: <1328795630.4952.73.camel@seasc1137> Greetings, The Erlang/OTP installation I use(*) overwhelms reltool(**). At least that is what I think, since dialyzer gave me a similar error until I switched to use "-r lib/*-0". Can I tell reltool to ignore all but the *-0 versions, too? bengt (*) lib/appmon-0 lib/appmon-2.1.12 lib/appmon-2.1.13 lib/asn1-0 lib/asn1-1.6.14 lib/asn1-1.6.14.1 lib/asn1-1.6.15 lib/asn1-1.6.16 ... lib/wx-0.98.8 lib/wx-0.98.9 lib/wx-0.99 lib/xmerl-0 lib/xmerl-1.2.10 lib/xmerl-1.2.5 lib/xmerl-1.2.6 lib/xmerl-1.2.7 lib/xmerl-1.2.8 lib/xmerl-1.2.9 (**) 4> {ok, Pid} = reltool:start_server([{config, "reltool.config"}]). {ok,<0.51.0>} =CRASH REPORT==== 9-Feb-2012::14:43:17 === crasher: initial call: reltool_server:init/1 pid: <0.51.0> registered_name: [] exception exit: "hipe: Application version clash. Multiple directories contains version \"3.8.1\"." in function reltool_server:do_init/1 in call from reltool_server:init/1 ancestors: [<0.47.0>] messages: [] links: [<0.47.0>] dictionary: [] trap_exit: false status: running heap_size: 317811 stack_size: 24 reductions: 1762187 neighbours: neighbour: [{pid,<0.47.0>}, {registered_name,[]}, {initial_call,{erlang,apply,2}}, {current_function,{shell,eval_loop,3}}, {ancestors,[]}, {messages,[]}, {links,[<0.26.0>,<0.51.0>]}, {dictionary,[]}, {trap_exit,false}, {status,waiting}, {heap_size,2584}, {stack_size,7}, {reductions,5367}] ** exception error: "hipe: Application version clash. Multiple directories contains version \"3.8.1\"." From hm@REDACTED Thu Feb 9 15:05:31 2012 From: hm@REDACTED (=?ISO-8859-1?Q?H=E5kan_Mattsson?=) Date: Thu, 9 Feb 2012 15:05:31 +0100 Subject: [erlang-questions] beginner: How make reltool handle multiple versions of libs? In-Reply-To: <1328795630.4952.73.camel@seasc1137> References: <1328795630.4952.73.camel@seasc1137> Message-ID: No. /H?kan On Thu, Feb 9, 2012 at 14:53, Bengt Kleberg wrote: > Greetings, > > The Erlang/OTP installation I use(*) overwhelms reltool(**). At least > that is what I think, since dialyzer gave me a similar error until I > switched to use "-r lib/*-0". > Can I tell reltool to ignore all but the *-0 versions, too? > > > bengt > > (*) > lib/appmon-0 > lib/appmon-2.1.12 > lib/appmon-2.1.13 > lib/asn1-0 > lib/asn1-1.6.14 > lib/asn1-1.6.14.1 > lib/asn1-1.6.15 > lib/asn1-1.6.16 > ... > lib/wx-0.98.8 > lib/wx-0.98.9 > lib/wx-0.99 > lib/xmerl-0 > lib/xmerl-1.2.10 > lib/xmerl-1.2.5 > lib/xmerl-1.2.6 > lib/xmerl-1.2.7 > lib/xmerl-1.2.8 > lib/xmerl-1.2.9 > > > (**) > 4> {ok, Pid} = reltool:start_server([{config, "reltool.config"}]). > {ok,<0.51.0>} > > =CRASH REPORT==== 9-Feb-2012::14:43:17 === > crasher: > initial call: reltool_server:init/1 > pid: <0.51.0> > registered_name: [] > exception exit: "hipe: Application version clash. Multiple > directories contains version \"3.8.1\"." > in function reltool_server:do_init/1 > in call from reltool_server:init/1 > ancestors: [<0.47.0>] > messages: [] > links: [<0.47.0>] > dictionary: [] > trap_exit: false > status: running > heap_size: 317811 > stack_size: 24 > reductions: 1762187 > neighbours: > neighbour: [{pid,<0.47.0>}, > {registered_name,[]}, > {initial_call,{erlang,apply,2}}, > {current_function,{shell,eval_loop,3}}, > {ancestors,[]}, > {messages,[]}, > {links,[<0.26.0>,<0.51.0>]}, > {dictionary,[]}, > {trap_exit,false}, > {status,waiting}, > {heap_size,2584}, > {stack_size,7}, > {reductions,5367}] > ** exception error: "hipe: Application version clash. Multiple > directories contains version \"3.8.1\"." > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinodhg@REDACTED Thu Feb 9 16:02:43 2012 From: vinodhg@REDACTED (Vinod H G) Date: Thu, 9 Feb 2012 20:32:43 +0530 Subject: [erlang-questions] Starting erl with unicode hostname Message-ID: Hi, When trying to support erl running on different language OS got an issue with the hostname. The hostname had Unicode characters. I used short name and got following error. Can?t set short node name. please check your configuration. registered_name, { error, badarg} If i use long name ex: erl -name abc@REDACTED vm starts but cnode communication (using ei_connect) is breaking in receive with {error, einval}. Please help. Thanks & Regards, Vinod H. G. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrtndimitrov@REDACTED Thu Feb 9 16:37:47 2012 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Thu, 09 Feb 2012 17:37:47 +0200 Subject: [erlang-questions] searching in an ETS table for substring Message-ID: <4F33E84B.7020604@gmail.com> Hello, Is it possible to search in an ETS table for a key that starts with certain characters? Something equivalent to: SELECT * FROM table WHERE name LIKE 'some%' I read the documentation for select/2 and it says we can use as guards functions as is_* and the like. Best regards, Martin From ulf@REDACTED Thu Feb 9 16:48:06 2012 From: ulf@REDACTED (Ulf Wiger) Date: Thu, 9 Feb 2012 16:48:06 +0100 Subject: [erlang-questions] searching in an ETS table for substring In-Reply-To: <4F33E84B.7020604@gmail.com> References: <4F33E84B.7020604@gmail.com> Message-ID: If the key is a list (not a binary), you can use the pattern "foo" ++ '_'. There is no equivalent syntax for binaries. If the table is an ordered set, this search will be efficient, since it will use the bound prefix to narrow the search. BR, Ulf On 9 Feb 2012, at 16:37, Martin Dimitrov wrote: > Hello, > > Is it possible to search in an ETS table for a key that starts with > certain characters? > Something equivalent to: > > SELECT * FROM table WHERE name LIKE 'some%' > > I read the documentation for select/2 and it says we can use as guards > functions as is_* and the like. > > Best regards, > > Martin > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From mrtndimitrov@REDACTED Thu Feb 9 17:00:10 2012 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Thu, 09 Feb 2012 18:00:10 +0200 Subject: [erlang-questions] searching in an ETS table for substring In-Reply-To: References: <4F33E84B.7020604@gmail.com> Message-ID: <4F33ED8A.4050808@gmail.com> Thanks but where do you put this pattern? On 2/9/2012 5:48 PM, Ulf Wiger wrote: > If the key is a list (not a binary), you can use the pattern "foo" ++ '_'. > > There is no equivalent syntax for binaries. > > If the table is an ordered set, this search will be efficient, since it will use the bound prefix to narrow the search. > > BR, > Ulf > > On 9 Feb 2012, at 16:37, Martin Dimitrov wrote: > >> Hello, >> >> Is it possible to search in an ETS table for a key that starts with >> certain characters? >> Something equivalent to: >> >> SELECT * FROM table WHERE name LIKE 'some%' >> >> I read the documentation for select/2 and it says we can use as guards >> functions as is_* and the like. >> >> Best regards, >> >> Martin >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions From mrtndimitrov@REDACTED Thu Feb 9 17:35:01 2012 From: mrtndimitrov@REDACTED (Martin Dimitrov) Date: Thu, 09 Feb 2012 18:35:01 +0200 Subject: [erlang-questions] How to convert UTF8 string to lowercase? Message-ID: <4F33F5B5.9050609@gmail.com> Hello, In the string module no word is mentioned about Unicode. Can to_lower/1 be used to covert Utf8 encoded string to lowercase? I remember I read somewhere that these functions are not Unicode safe. So what else can be used? Regards, Martin From mononcqc@REDACTED Thu Feb 9 18:08:12 2012 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 9 Feb 2012 12:08:12 -0500 Subject: [erlang-questions] How to convert UTF8 string to lowercase? In-Reply-To: <4F33F5B5.9050609@gmail.com> References: <4F33F5B5.9050609@gmail.com> Message-ID: As far as I know, the string module is all about lists. Erlang Unicode is handled in different ways. 1. Lists of Unicode code points (no specific encoding), 2. Binaries with a specific encoding (utf-8, utf-16, utf-32). A utf-8 list will be seen as a list of bytes; not a unicode string proper. It will have no notion of codepoints or encoding and will be equivalent to latin-1. You need to convert back to a list of codepoints with unicode:characters_to_list(list_to_binary(ByteList)), or to an encoded binary with unicode:characters_to_binary(IoList). In any case, this is as far as Erlang goes when it comes to unicode support as far as I know. There is no library to handle and transform it, just to convert and transport it. On Feb 9, 2012 11:35 AM, "Martin Dimitrov" wrote: > Hello, > > In the string module no word is mentioned about Unicode. Can to_lower/1 > be used to covert Utf8 encoded string to lowercase? > > I remember I read somewhere that these functions are not Unicode safe. > So what else can be used? > > Regards, > > Martin > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From desired.mta@REDACTED Thu Feb 9 19:37:03 2012 From: desired.mta@REDACTED (Motiejus =?utf-8?Q?Jak=C5=A1tys?=) Date: Thu, 9 Feb 2012 18:37:03 +0000 Subject: [erlang-questions] is empty catch statement possible? Message-ID: <20120209183703.GA4274@jakstys.lt> Hello, consider this macro: -define(silent(Level, Expr), (fun() -> __Lager_OldLevel = lager:get_loglevel(lager_console_backend), try fun() -> Expr end catch throw:'$__should_never_be_thrown' -> ok after leger:set_loglevel(lager_console_backend, __Lager_OldLevel) end end)()). 1) does it do what I expect? I want log level to be restored in _any_ case. 2) Is there a way to avoid the stub throw:Atom statement? Thanks Motiejus From simon@REDACTED Thu Feb 9 19:37:13 2012 From: simon@REDACTED (Simon MacMullen) Date: Thu, 09 Feb 2012 18:37:13 +0000 Subject: [erlang-questions] Character encoding and the Windows command line Message-ID: <4F341259.8000008@rabbitmq.com> Here is a simple test program: -module(test). -export([test/0]). test() -> io:format("Args were ~w~n", [init:get_plain_arguments()]). If I invoke this on Ubuntu, with the command line: $ erl -run test test -- ? I get: Args were [[230,150,176]] which is the UTF-8 encoding of the character I gave (\u65b0, "new, recent, fresh, modern"). Great! Then I try it on my Chinese language copy of Windows XP: C:\>"c:\Program Files\erl5.9\bin\erl" -run test test -- ? Args were [[208,194]] Huh. That's (it turns out) encoded in GB18030. Which would appear to be the encoding used by Windows. Better yet, if I try the same thing on a UK copy of Windows it tries to use an encoding which can't handle Chinese characters. So this sucks. I would like my application internally to use all UTF-8, all the time. It would appear that I can use the Windows command "chcp" to detect which encoding Windows will impose on me, then try to use erlang-iconv or something to sort myself out but: a) This seems hideous; does anyone have a better way? (Sorry, "don't support Windows" is not a better way). b) It gets worse: suppose my application is installed to a path which includes non-ASCII characters, and we use "-pa" to tell erl.exe where that is... In that case we *still* pass through the path in GB18030 or whatever, and erl.exe fails to even find it as it expects UTF-8. Is there any solution to this *at all*? Cheers, Simon -- Simon MacMullen RabbitMQ, VMware From desired.mta@REDACTED Thu Feb 9 19:39:28 2012 From: desired.mta@REDACTED (Motiejus =?utf-8?Q?Jak=C5=A1tys?=) Date: Thu, 9 Feb 2012 18:39:28 +0000 Subject: [erlang-questions] is empty catch statement possible? In-Reply-To: <20120209183703.GA4274@jakstys.lt> References: <20120209183703.GA4274@jakstys.lt> Message-ID: <20120209183928.GB4274@jakstys.lt> Whoops, a small mistake in code. Fixed version: -define(silent(Level, Expr), (fun() -> __Lager_OldLevel = lager:get_loglevel(lager_console_backend), + lager:set_loglevel(lager_console_backend, Level), try fun() -> Expr end catch throw:'$__should_never_be_thrown' -> ok after leger:set_loglevel(lager_console_backend, __Lager_OldLevel) end end)()). Motiejus From lukas@REDACTED Thu Feb 9 19:46:07 2012 From: lukas@REDACTED (Lukas Larsson) Date: Thu, 9 Feb 2012 19:46:07 +0100 Subject: [erlang-questions] is empty catch statement possible? In-Reply-To: <20120209183928.GB4274@jakstys.lt> References: <20120209183703.GA4274@jakstys.lt> <20120209183928.GB4274@jakstys.lt> Message-ID: iirc you should be able to do: try something after io:format("hello after",[]) end. Not sure how lager works, but if it keeps an external state for the logging level it will not be reset if the process executing the try catch is killed due to an exit msg. Lukas 2012/2/9 Motiejus Jak?tys : > Whoops, a small mistake in code. Fixed version: > > -define(silent(Level, Expr), (fun() -> > ? ? ? ? ? ? ? ? __Lager_OldLevel = lager:get_loglevel(lager_console_backend), > + ? ? ? ? ? ? ? ?lager:set_loglevel(lager_console_backend, Level), > ? ? ? ? ? ? ? ? try > ? ? ? ? ? ? ? ? ? ? fun() -> Expr end > ? ? ? ? ? ? ? ? catch > ? ? ? ? ? ? ? ? ? ? throw:'$__should_never_be_thrown' -> ok > ? ? ? ? ? ? ? ? after > ? ? ? ? ? ? ? ? ? ? leger:set_loglevel(lager_console_backend, __Lager_OldLevel) > ? ? ? ? ? ? ? ? end > ? ? ? ? end)()). > > Motiejus > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From f355@REDACTED Thu Feb 9 20:06:56 2012 From: f355@REDACTED (Konstantin Tcepliaev) Date: Thu, 09 Feb 2012 23:06:56 +0400 Subject: [erlang-questions] is empty catch statement possible? In-Reply-To: <20120209183703.GA4274@jakstys.lt> References: <20120209183703.GA4274@jakstys.lt> Message-ID: <710341328814416@web101.yandex.ru> Hello, Motiejus. 1. Yes, except that your code will return your Expr wrapped in zero arity fun, which is probably not what you want, though I'm not sure. 2. You can omit 'catch' clause entirely, leaving only 'try' and 'after'. Also a couple of tedious notes: first, better be less javascriptish and replace your outer lambda with begin ... end, as that'll be a bit faster and a lot more readable, and second - avoid starting variable name with underscore when you're going to use its value somewhere, it'll save you from stupid debugging someday. 09.02.2012, 22:37, "Motiejus Jak?tys" : > ?Hello, > ?consider this macro: > > ?-define(silent(Level, Expr), (fun() -> > ?????????????????__Lager_OldLevel = lager:get_loglevel(lager_console_backend), > ?????????????????try > ?????????????????????fun() -> Expr end > ?????????????????catch > ?????????????????????throw:'$__should_never_be_thrown' -> ok > ?????????????????after > ?????????????????????leger:set_loglevel(lager_console_backend, __Lager_OldLevel) > ?????????????????end > ?????????end)()). > > ?1) does it do what I expect? I want log level to be restored in _any_ case. > ?2) Is there a way to avoid the stub throw:Atom statement? > > ?Thanks > ?Motiejus > ?_______________________________________________ > ?erlang-questions mailing list > ?erlang-questions@REDACTED > ?http://erlang.org/mailman/listinfo/erlang-questions Regards, -- Konstantin From desired.mta@REDACTED Thu Feb 9 20:18:05 2012 From: desired.mta@REDACTED (Motiejus =?utf-8?Q?Jak=C5=A1tys?=) Date: Thu, 9 Feb 2012 19:18:05 +0000 Subject: [erlang-questions] is empty catch statement possible? In-Reply-To: <710341328814416@web101.yandex.ru> References: <20120209183703.GA4274@jakstys.lt> <710341328814416@web101.yandex.ru> Message-ID: <20120209191805.GA6254@jakstys.lt> On Thu, Feb 09, 2012 at 11:06:56PM +0400, Konstantin Tcepliaev wrote: > Hello, Motiejus. > > 1. Yes, except that your code will return your Expr wrapped in zero > arity fun, which is probably not what you want, though I'm not sure. Yes, that was another mistake... > 2. You can omit 'catch' clause entirely, leaving only 'try' and > 'after'. Cool. Not sure why didn't work before, when I tried that. > > Also a couple of tedious notes: first, better be less javascriptish > and replace your outer lambda with begin ... end, as that'll be a bit > faster and a lot more readable, and second - avoid starting variable > name with underscore when you're going to use its value somewhere, > it'll save you from stupid debugging someday. Didn't know it's possible to do like that. Thanks! Motiejus From mallen@REDACTED Thu Feb 9 21:04:11 2012 From: mallen@REDACTED (Mark Allen) Date: Thu, 9 Feb 2012 14:04:11 -0600 Subject: [erlang-questions] Post and query string parameter validation library? Message-ID: Hello. I'm relatively new to Erlang programming. My project is an backend API for a JSON based webservice. I'm looking for a library which can take a proplist in form of [{"param_name", "value"}, ...] and validate the values against a set of specifications for the parameters. I'm pretty open to how specifications are declared or passed. (The proplist comes from mochiweb post_params() or query_params() calls.) Before I go reinvent the wheel, I thought I'd ask if there's something already out there that does this. Thanks. Mark Mark Allen Sr. Software Developer Alert Logic, Inc. mallen@REDACTED Security ? Compliance ? Cloud From pingwin@REDACTED Thu Feb 9 22:56:30 2012 From: pingwin@REDACTED (Brian Smith) Date: Thu, 09 Feb 2012 16:56:30 -0500 Subject: [erlang-questions] Performance difference between string and binary data when queried in mnesia? Message-ID: <4F34410E.5050908@gmail.com> I have a table to have >1.5 million records in it. -record(hosts, {hostname, flags, catmask}). application:start(mnesia). mnesia:create_table(hosts, [{ram_copies, [node()]}, {attributes, record_info(fields, hosts)}]). mnesia:dirty_select(hosts, [{#hosts{hostname='$1', _='_'}, [{'=<', '$1', SearchParam}], ['$_']}]). Is there any significant performance difference between: SearchTerm = "facebook.com", and SearchTerm = <<8,"facebook", 3, "com", 0>>, ? Thanks and egger to hear some responses... -- -brian From pingwin@REDACTED Thu Feb 9 23:08:00 2012 From: pingwin@REDACTED (Brian Smith) Date: Thu, 9 Feb 2012 14:08:00 -0800 (PST) Subject: [erlang-questions] Performance difference between string and binary data when queried in mnesia? In-Reply-To: <4F34410E.5050908@gmail.com> References: <4F34410E.5050908@gmail.com> Message-ID: <28082420.1091.1328825280273.JavaMail.geo-discussion-forums@yqis10> also would like to mention that I'd like to still find facebook.com even if the search term is www.facebook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgsmcmlxxv@REDACTED Fri Feb 10 06:26:24 2012 From: cgsmcmlxxv@REDACTED (CGS) Date: Fri, 10 Feb 2012 06:26:24 +0100 Subject: [erlang-questions] crypto:md5/1 vs openssl md5 Message-ID: Hi, Just for my curiosity, does anybody know if crypto:md5/1 in R14B03 is intentionally different from openssl md5? (The sha matches perfectly.) Just a short test (Erlang shell): 1> RB = crypto:rand_bytes(16). <<141,190,84,7,129,230,147,112,200,205,68,80,240,78,68,198>> 2> MD5 = crypto:md5(RB). <<97,59,0,195,229,254,195,237,238,126,156,14,33,142,206,183>> 3> lists:flatten(lists:map(fun([X,Y])->[case X>64 of true -> X+32; false-> X end,case Y>64 of true -> Y+32; false -> Y end];([X])->[$0,case X>64 of true -> X+32; false -> X end] end, lists:map(fun(X)->integer_to_list(X,16) end, binary_to_list(RB)))). "8dbe540781e69370c8cd4450f04e44c6" 4> lists:flatten(lists:map(fun([X,Y])->[case X>64 of true -> X+32; false-> X end,case Y>64 of true -> Y+32; false -> Y end];([X])->[$0,case X>64 of true -> X+32; false -> X end] end, lists:map(fun(X)->integer_to_list(X,16) end, binary_to_list(MD5)))). "613b00c3e5fec3edee7e9c0e218eceb7" 5> os:cmd("echo \"8dbe540781e69370c8cd4450f04e44c6\" | openssl md5"). "(stdin)= 6007d8f36b589078f3565b5c90cedffc\n" As you can see the same rand number, "8dbe540781e69370c8cd4450f04e44c6", gives in crypto:md5 "613b00c3e5fec3edee7e9c0e218eceb7" while in openssl md5 "6007d8f36b589078f3565b5c90cedffc". Please, let me know if I do something wrong. CGS -------------- next part -------------- An HTML attachment was scrubbed... URL: From rapsey@REDACTED Fri Feb 10 07:06:52 2012 From: rapsey@REDACTED (Rapsey) Date: Fri, 10 Feb 2012 07:06:52 +0100 Subject: [erlang-questions] How to convert UTF8 string to lowercase? In-Reply-To: <4F33F5B5.9050609@gmail.com> References: <4F33F5B5.9050609@gmail.com> Message-ID: This library: https://github.com/freeakk/ux Sergej On Thu, Feb 9, 2012 at 5:35 PM, Martin Dimitrov wrote: > Hello, > > In the string module no word is mentioned about Unicode. Can to_lower/1 > be used to covert Utf8 encoded string to lowercase? > > I remember I read somewhere that these functions are not Unicode safe. > So what else can be used? > > Regards, > > Martin > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f355@REDACTED Fri Feb 10 08:17:47 2012 From: f355@REDACTED (Konstantin Tcepliaev) Date: Fri, 10 Feb 2012 11:17:47 +0400 Subject: [erlang-questions] is empty catch statement possible? In-Reply-To: <20120209191805.GA6254@jakstys.lt> References: <20120209183703.GA4274@jakstys.lt> <710341328814416@web101.yandex.ru> <20120209191805.GA6254@jakstys.lt> Message-ID: <486951328858267@web33.yandex.ru> Hello again, Motiejus. One more thing: macro variables' scope is not limited to the text of macro, so in a piece of code such as: lager:set_loglevel(lager_console_backend, InitialLevel), .. ?silent(SLevel, Expr), .. lager:set_loglevel(lager_console_backend, NewLevel), %% NewLevel /= InitialLevel .. ?silent(SLevel, OtherExpr), %% badmatch here! ..you'll get a badmatch error on your __Lager_OldLevel variable. Redefining your macro as a normal function would be a great solution. 09.02.2012, 23:18, "Motiejus Jak?tys" : > On Thu, Feb 09, 2012 at 11:06:56PM +0400, Konstantin Tcepliaev wrote: > >> ?Hello, Motiejus. >> >> ?1. Yes, except that your code will return your Expr wrapped in zero >> ?arity fun, which is probably not what you want, though I'm not sure. > > Yes, that was another mistake... > >> ?2. You can omit 'catch' clause entirely, leaving only 'try' and >> ?'after'. > > Cool. Not sure why didn't work before, when I tried that. > >> ?Also a couple of tedious notes: first, better be less javascriptish >> ?and replace your outer lambda with begin ... end, as that'll be a bit >> ?faster and a lot more readable, and second - avoid starting variable >> ?name with underscore when you're going to use its value somewhere, >> ?it'll save you from stupid debugging someday. > > Didn't know it's possible to do like that. Thanks! > > Motiejus Regards, -- Konstantin From bourinov@REDACTED Fri Feb 10 08:30:17 2012 From: bourinov@REDACTED (Max Bourinov) Date: Fri, 10 Feb 2012 10:30:17 +0300 Subject: [erlang-questions] State in webmachine Message-ID: I would like to keep time of last call inside page module. I suspect that State which exists in the page module can help me with it - is it correct? How would you do it in easy way? The hard way I know is to spawn process that will keep my data. Best regards, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From w.a.de.jong@REDACTED Fri Feb 10 08:53:48 2012 From: w.a.de.jong@REDACTED (Willem de Jong) Date: Fri, 10 Feb 2012 08:53:48 +0100 Subject: [erlang-questions] Post and query string parameter validation library? In-Reply-To: References: Message-ID: Hi, I have some code that translates a query string to a record. It uses the record definition as the specification for the parameters. You can extend the specification a bit by adding some special comments to the record definition (a bit like eDoc). The code is in a kind of semi-finished state: it works for my current purposes, but there is no documentation and there will probably be some bugs or rough edges. If you want I can put it on github this weekend, maybe you polish it a bit... Regards, Willem On Thu, Feb 9, 2012 at 9:04 PM, Mark Allen wrote: > Hello. I'm relatively new to Erlang programming. My project is an backend > API for a JSON based webservice. > > I'm looking for a library which can take a proplist in form of > > [{"param_name", "value"}, ...] > > and validate the values against a set of specifications for the > parameters. > > I'm pretty open to how specifications are declared or passed. > > (The proplist comes from mochiweb post_params() or query_params() calls.) > > Before I go reinvent the wheel, I thought I'd ask if there's something > already > out there that does this. > > Thanks. > > Mark > > Mark Allen > Sr. Software Developer > Alert Logic, Inc. > mallen@REDACTED > Security ? Compliance ? Cloud > > _______________________________________________ > 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 Fri Feb 10 09:09:54 2012 From: desired.mta@REDACTED (=?UTF-8?Q?Motiejus_Jak=C5=A1tys?=) Date: Fri, 10 Feb 2012 08:09:54 +0000 Subject: [erlang-questions] is empty catch statement possible? In-Reply-To: <486951328858267@web33.yandex.ru> References: <20120209183703.GA4274@jakstys.lt> <710341328814416@web101.yandex.ru> <20120209191805.GA6254@jakstys.lt> <486951328858267@web33.yandex.ru> Message-ID: 2012/2/10 Konstantin Tcepliaev : > Hello again, Motiejus. > > One more thing: macro variables' scope is not limited to the text of macro, so in a piece of code such as: > > lager:set_loglevel(lager_console_backend, InitialLevel), > .. > ?silent(SLevel, Expr), > .. > lager:set_loglevel(lager_console_backend, NewLevel), %% NewLevel /= InitialLevel > .. > ?silent(SLevel, OtherExpr), %% badmatch here! > > ..you'll get a badmatch error on your __Lager_OldLevel variable. Redefining your macro as a normal function would be a great solution. This is why I was initially wrapping the macro to the function. "JavaScript"ish way makes sense in this case, so Lager_OldLevel will be in a separate scope. -- Motiejus Jak?tys From andre@REDACTED Fri Feb 10 09:48:09 2012 From: andre@REDACTED (=?ISO-8859-1?Q?Andr=E9_Graf?=) Date: Fri, 10 Feb 2012 09:48:09 +0100 Subject: [erlang-questions] State in webmachine In-Reply-To: References: Message-ID: <4F34D9C9.1090008@dergraf.org> As far as I understand in webmachine the state (they call it context) is only passed among the different webmachine resource functions e.g. you build up your state in the init/1 function, which you can later use in e.g. process_post. Once the request is handled the state is destroyed, as it makes sense for a stateless protocol such as http. If you really need shared state I would suggest to use a process holding your state or just take an ets table. Am 10.02.12 08:30, schrieb Max Bourinov: > I would like to keep time of last call inside page module. I suspect > that State which exists in the page module can help me with it - is it > correct? > > How would you do it in easy way? > > The hard way I know is to spawn process that will keep my data. > > Best regards, > Max > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From freeakk@REDACTED Fri Feb 10 09:50:37 2012 From: freeakk@REDACTED (Michael Uvarov) Date: Fri, 10 Feb 2012 11:50:37 +0300 Subject: [erlang-questions] Starting erl with unicode hostname In-Reply-To: References: Message-ID: Hostname is an atom. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourinov@REDACTED Fri Feb 10 09:58:04 2012 From: bourinov@REDACTED (Max Bourinov) Date: Fri, 10 Feb 2012 11:58:04 +0300 Subject: [erlang-questions] State in webmachine In-Reply-To: <4F34D9C9.1090008@dergraf.org> References: <4F34D9C9.1090008@dergraf.org> Message-ID: Thank you Andre! I also came to this during my investigations... Good that it is easy to make a process in erlang :-) ETS will also work. Best regards, Max On Fri, Feb 10, 2012 at 11:48 AM, Andr? Graf wrote: > As far as I understand in webmachine the state (they call it context) is > only passed among the different webmachine resource functions e.g. you > build up your state in the init/1 function, which you can later use in e.g. > process_post. Once the request is handled the state is destroyed, as it > makes sense for a stateless protocol such as http. If you really need > shared state I would suggest to use a process holding your state or just > take an ets table. > > > Am 10.02.12 08:30, schrieb Max Bourinov: > >> I would like to keep time of last call inside page module. I suspect >> that State which exists in the page module can help me with it - is it >> correct? >> >> How would you do it in easy way? >> >> The hard way I know is to spawn process that will keep my data. >> >> Best regards, >> Max >> >> >> >> >> ______________________________**_________________ >> erlang-questions mailing list >> 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 emeka_1978@REDACTED Fri Feb 10 11:38:53 2012 From: emeka_1978@REDACTED (eigenfunction) Date: Fri, 10 Feb 2012 02:38:53 -0800 (PST) Subject: [erlang-questions] wxerlang Message-ID: <931131ce-e710-47bb-8cc5-fd1545da318a@t5g2000yqk.googlegroups.com> Is there any comprehensive tutorial out there about wxerlang? Or do i have to go the wxWidget route? The only thing i could find is http://wxerlang.dougedmunds.com . Any idea? From tony@REDACTED Fri Feb 10 11:55:38 2012 From: tony@REDACTED (Tony Rogvall) Date: Fri, 10 Feb 2012 11:55:38 +0100 Subject: [erlang-questions] crypto:md5/1 vs openssl md5 In-Reply-To: References: Message-ID: <7D469D53-9B7B-4066-8269-3135EEF3E1E2@rogvall.se> Problem is newline! Testing with string input: Erlang-version: [ lists:nth(X+1,"0123456789abcdef") || <> <= crypto:md5("hello-world")]. "2095312189753de6ad47dfe20cbe97ec" Port with -n flag work!! 18> open_port({spawn,"echo -n hello-world | openssl md5"}, []). #Port<0.1075> 19> flush(). Shell got {#Port<0.1075>,{data,"(stdin)= 2095312189753de6ad47dfe20cbe97ec\n"}} ok Without a -n flag you get a newline in input, does not match 20> open_port({spawn,"echo hello-world | openssl md5"}, []). #Port<0.1076> 21> flush(). Shell got {#Port<0.1076>,{data,"(stdin)= 8a8933dab8deebe52e30886da1ef6ee2\n"}} ok Same as above. 22> os:cmd("echo hello-world | openssl md5"). "(stdin)= 8a8933dab8deebe52e30886da1ef6ee2\n" But this is truly strange :-) 24> os:cmd("echo -n hello-world | openssl md5"). "(stdin)= c298a9eb9b7697afa9b4b7bbd6b012b1\n" Until you read os.erl and see that the command is mangled into the form: os:cmd corresponds in doing the following commands: 40> Port = open_port({spawn, "/bin/sh -s unix:cmd 2>&1"}, [stream]). 41> erlang:port_command(Port, "(echo -n hello-world | openssl md5) < /dev/null; echo \"\^D\"\n"). true 42> flush(). Shell got {#Port<0.943>,{data,"(stdin)= c298a9eb9b7697afa9b4b7bbd6b012b1\n"}} Shell got {#Port<0.943>,{data,[4,10]}} ok Testing a bit more yield: 64> Port = open_port({spawn, "/bin/sh -s unix:cmd 2>&1"}, [stream]). 65> erlang:port_command(Port, "(echo -n hello-world | cat) < /dev/null; echo \"\^D\"\n"). 66> flush(). Shell got {#Port<0.1077>,{data,"-n hello-world\n"}} Shell got {#Port<0.1077>,{data,[4,10]}} so -n is not accepted by /bin/sh version of echo! verifying this: [ lists:nth(X+1,"0123456789abcdef") || <> <= crypto:md5("-n hello-world\n")]. "c298a9eb9b7697afa9b4b7bbd6b012b1" /Tony On 10 feb 2012, at 06:26, CGS wrote: > > Hi, > > Just for my curiosity, does anybody know if crypto:md5/1 in R14B03 is intentionally different from openssl md5? (The sha matches perfectly.) > > Just a short test (Erlang shell): > 1> RB = crypto:rand_bytes(16). > <<141,190,84,7,129,230,147,112,200,205,68,80,240,78,68,198>> > 2> MD5 = crypto:md5(RB). > <<97,59,0,195,229,254,195,237,238,126,156,14,33,142,206,183>> > 3> lists:flatten(lists:map(fun([X,Y])->[case X>64 of true -> X+32; false-> X end,case Y>64 of true -> Y+32; false -> Y end];([X])->[$0,case X>64 of true -> X+32; false -> X end] end, lists:map(fun(X)->integer_to_list(X,16) end, binary_to_list(RB)))). > "8dbe540781e69370c8cd4450f04e44c6" > 4> lists:flatten(lists:map(fun([X,Y])->[case X>64 of true -> X+32; false-> X end,case Y>64 of true -> Y+32; false -> Y end];([X])->[$0,case X>64 of true -> X+32; false -> X end] end, lists:map(fun(X)->integer_to_list(X,16) end, binary_to_list(MD5)))). > "613b00c3e5fec3edee7e9c0e218eceb7" > 5> os:cmd("echo \"8dbe540781e69370c8cd4450f04e44c6\" | openssl md5"). > "(stdin)= 6007d8f36b589078f3565b5c90cedffc\n" > > As you can see the same rand number, "8dbe540781e69370c8cd4450f04e44c6", gives in crypto:md5 "613b00c3e5fec3edee7e9c0e218eceb7" while in openssl md5 "6007d8f36b589078f3565b5c90cedffc". Please, let me know if I do something wrong. > > CGS > > _______________________________________________ > 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 sverker@REDACTED Fri Feb 10 11:57:31 2012 From: sverker@REDACTED (Sverker Eriksson) Date: Fri, 10 Feb 2012 11:57:31 +0100 Subject: [erlang-questions] crypto:md5/1 vs openssl md5 In-Reply-To: References: Message-ID: <4F34F81B.6010908@erix.ericsson.se> Don't seem to me like "openssl md5" command expects a hexstring, but rather the raw data itself. > echo Hello > Hello > hexdump -C Hello 00000000 48 65 6c 6c 6f 0a |Hello.| 00000006 > cat Hello | openssl md5 09f7e02f1290be211da707a266f153b3 > erl Erlang R15B (erts-5.9.0.1) [64-bit] [smp:4:4] [async-threads:0] [kernel-poll:false] Eshell V5.9.0.1 (abort with ^G) 1> crypto:md5(<<"Hello\n">>). <<9,247,224,47,18,144,190,33,29,167,7,162,102,241,83,179>> /Sverker, Erlang/OTP CGS wrote: > Hi, > > Just for my curiosity, does anybody know if crypto:md5/1 in R14B03 is > intentionally different from openssl md5? (The sha matches perfectly.) > > Just a short test (Erlang shell): > 1> RB = > crypto:rand_bytes(16). > <<141,190,84,7,129,230,147,112,200,205,68,80,240,78,68,198>> > > 2> MD5 = > crypto:md5(RB). > <<97,59,0,195,229,254,195,237,238,126,156,14,33,142,206,183>> > 3> lists:flatten(lists:map(fun([X,Y])->[case X>64 of true -> X+32; false-> > X end,case Y>64 of true -> Y+32; false -> Y end];([X])->[$0,case X>64 of > true -> X+32; false -> X end] end, lists:map(fun(X)->integer_to_list(X,16) > end, binary_to_list(RB)))). > "8dbe540781e69370c8cd4450f04e44c6" > 4> lists:flatten(lists:map(fun([X,Y])->[case X>64 of true -> X+32; false-> > X end,case Y>64 of true -> Y+32; false -> Y end];([X])->[$0,case X>64 of > true -> X+32; false -> X end] end, lists:map(fun(X)->integer_to_list(X,16) > end, binary_to_list(MD5)))). > "613b00c3e5fec3edee7e9c0e218eceb7" > 5> os:cmd("echo \"8dbe540781e69370c8cd4450f04e44c6\" | openssl > md5"). > "(stdin)= > 6007d8f36b589078f3565b5c90cedffc\n" > > As you can see the same rand number, "8dbe540781e69370c8cd4450f04e44c6", > gives in crypto:md5 "613b00c3e5fec3edee7e9c0e218eceb7" while in openssl md5 > "6007d8f36b589078f3565b5c90cedffc". Please, let me know if I do something > wrong. > > CGS > > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From dgud@REDACTED Fri Feb 10 12:30:51 2012 From: dgud@REDACTED (Dan Gudmundsson) Date: Fri, 10 Feb 2012 12:30:51 +0100 Subject: [erlang-questions] wxerlang In-Reply-To: <931131ce-e710-47bb-8cc5-fd1545da318a@t5g2000yqk.googlegroups.com> References: <931131ce-e710-47bb-8cc5-fd1545da318a@t5g2000yqk.googlegroups.com> Message-ID: Not that I know of, I think the best thing is to read code. I'm still learning how to use wx (and still finding bugs in unused code), but it's getting better. So take a look at the observer code, which is the best usage of wx I have written so far. I havn't looked at wx code outside of OTP so I don't know if there are other good code examples out there. But otherwise you will have to google wxwidgets and read their docs/tutorials. /Dan On Fri, Feb 10, 2012 at 11:38 AM, eigenfunction wrote: > Is there any comprehensive tutorial out there about wxerlang? Or do i > have to go the wxWidget route? > The only thing i could find is http://wxerlang.dougedmunds.com . > Any idea? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From emeka_1978@REDACTED Fri Feb 10 13:30:39 2012 From: emeka_1978@REDACTED (eigenfunction) Date: Fri, 10 Feb 2012 04:30:39 -0800 (PST) Subject: [erlang-questions] wxerlang In-Reply-To: References: <931131ce-e710-47bb-8cc5-fd1545da318a@t5g2000yqk.googlegroups.com> Message-ID: <2e520d6a-12c4-4c7b-a67e-4644b6ceb561@f30g2000yqh.googlegroups.com> Thanks, i am going to check that out. On 10 Feb., 12:30, Dan Gudmundsson wrote: > Not that I know of, I think the best thing is to read code. > > I'm still learning how to use wx (and still finding bugs in unused > code), but it's getting better. > So take a look at the observer code, which is the best usage of wx I > have written so far. > I havn't looked at wx code outside of OTP so I don't know if there are > other good code examples out there. > > But otherwise you will have to google wxwidgets and read their docs/tutorials. > > /Dan > > On Fri, Feb 10, 2012 at 11:38 AM, eigenfunction wrote: > > Is there any comprehensive tutorial out there about wxerlang? Or do i > > have to go the wxWidget route? > > The only thing i could find ishttp://wxerlang.dougedmunds.com. > > Any idea? > > _______________________________________________ > > erlang-questions mailing list > > erlang-questi...@REDACTED > >http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions From comptekki@REDACTED Fri Feb 10 16:09:06 2012 From: comptekki@REDACTED (Wes James) Date: Fri, 10 Feb 2012 08:09:06 -0700 Subject: [erlang-questions] wxerlang In-Reply-To: <931131ce-e710-47bb-8cc5-fd1545da318a@t5g2000yqk.googlegroups.com> References: <931131ce-e710-47bb-8cc5-fd1545da318a@t5g2000yqk.googlegroups.com> Message-ID: On Fri, Feb 10, 2012 at 3:38 AM, eigenfunction wrote: > Is there any comprehensive tutorial out there about wxerlang? Or do i > have to go the wxWidget route? > The only thing i could find is http://wxerlang.dougedmunds.com . > Any idea? You may want to run wx:demo() to see examples and also look at the code for the demo. -wes From mallen@REDACTED Fri Feb 10 17:43:54 2012 From: mallen@REDACTED (Mark Allen) Date: Fri, 10 Feb 2012 10:43:54 -0600 Subject: [erlang-questions] Post and query string parameter validation library? In-Reply-To: Message-ID: > Willem de Jong wrote: > The code is in a kind of semi-finished state: it works for my > current purposes, but there is no documentation and there will > probably be some bugs or rough edges. If you want I can put it > on github this weekend, maybe you polish it a bit... That'd be great. Thank you. I am about half-way done with my validation module. I'll put it up on github when I'm done too. Mark Mark Allen Sr. Software Developer Alert Logic, Inc. mallen@REDACTED Security ? Compliance ? Cloud From desired.mta@REDACTED Fri Feb 10 20:22:01 2012 From: desired.mta@REDACTED (Motiejus =?utf-8?Q?Jak=C5=A1tys?=) Date: Fri, 10 Feb 2012 19:22:01 +0000 Subject: [erlang-questions] lager runtime configuration changes Message-ID: <20120210192201.GA10409@jakstys.lt> Hello, Sometimes hot changing lager loglevel is not sufficient. Let's say I want to add a lager backend while system is running (actually, change anything that's in lager config file). What should I run/execute, after the change/if I know the new params? {lager, [ {handlers, [ {lager_console_backend, info}, {lager_file_backend, [ {"error.log", error, 10485760, "$D0", 5}, % assume I just created this {"console.log", info, 10485760, "$D0", 5} ]} ]} ]}. One way would be application:set_env/3. How unsafe is it? Thanks Motiejus From mallen@REDACTED Fri Feb 10 23:59:52 2012 From: mallen@REDACTED (Mark Allen) Date: Fri, 10 Feb 2012 16:59:52 -0600 Subject: [erlang-questions] Post and query string parameter validation library? In-Reply-To: Message-ID: On 2/10/12 10:43 AM, "Mark Allen" wrote: >I am about half-way done with my validation module. I'll put it up on >github when I'm done too. https://gist.github.com/1793796 I'd love comments, feedback or edits. This isn't 100% finished, either, but it's close enough to show what I'm aiming for. Thank you. Mark From emeka_1978@REDACTED Sat Feb 11 00:07:19 2012 From: emeka_1978@REDACTED (eigenfunction) Date: Fri, 10 Feb 2012 15:07:19 -0800 (PST) Subject: [erlang-questions] wxerlang In-Reply-To: References: <931131ce-e710-47bb-8cc5-fd1545da318a@t5g2000yqk.googlegroups.com> Message-ID: <9dc186b3-bb97-4838-9df2-ab6877bc9c43@q12g2000yqg.googlegroups.com> WOW, wx:demo() has a lot of stuffs. That's exactly what i was looking for. Thanks lot. On Feb 10, 4:09?pm, Wes James wrote: > On Fri, Feb 10, 2012 at 3:38 AM, eigenfunction wrote: > > Is there any comprehensive tutorial out there about wxerlang? Or do i > > have to go the wxWidget route? > > The only thing i could find ishttp://wxerlang.dougedmunds.com. > > Any idea? > > You may want to run wx:demo() to see examples and also look at the > code for the demo. > > -wes > _______________________________________________ > erlang-questions mailing list > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions From andrew@REDACTED Sat Feb 11 00:58:26 2012 From: andrew@REDACTED (Andrew Thompson) Date: Fri, 10 Feb 2012 18:58:26 -0500 Subject: [erlang-questions] lager runtime configuration changes In-Reply-To: <20120210192201.GA10409@jakstys.lt> References: <20120210192201.GA10409@jakstys.lt> Message-ID: <20120210235826.GG10141@hijacked.us> On Fri, Feb 10, 2012 at 07:22:01PM +0000, Motiejus Jak?tys wrote: > Hello, > > Sometimes hot changing lager loglevel is not sufficient. Let's say I want to > add a lager backend while system is running (actually, change anything that's > in lager config file). What should I run/execute, after the change/if I know > the new params? > > {lager, [ > {handlers, [ > {lager_console_backend, info}, > {lager_file_backend, [ > {"error.log", error, 10485760, "$D0", 5}, % assume I just created this > {"console.log", info, 10485760, "$D0", 5} > ]} > ]} > ]}. > > One way would be application:set_env/3. How unsafe is it? Lager is really just gen_event at its core, you can just add/remove handlers manually if you wish, at runtime: gen_event:add_handler(lager_event, {lager_file_backend, "error.log"}, {"error.log", error, 0485760, "$D0", 5}) You can also use which_handlers() and delete_handler() to see what's installed and remove one. That said, it might be nice to have a little more runtime flexibility at some point that would make this easier. Andrew From kaiduanx@REDACTED Sat Feb 11 03:03:05 2012 From: kaiduanx@REDACTED (Kaiduan Xie) Date: Fri, 10 Feb 2012 21:03:05 -0500 Subject: [erlang-questions] Server Name Indication support in Erlang SSL Message-ID: Ingela, Does Erlang new SSL support Server Name Indication extension? http://en.wikipedia.org/wiki/Server_Name_Indication https://alice.sni.velox.ch/ Thanks, /Kaiduan From poprosturadek@REDACTED Sat Feb 11 11:34:21 2012 From: poprosturadek@REDACTED (Radek) Date: Sat, 11 Feb 2012 11:34:21 +0100 Subject: [erlang-questions] The future of Erlang and BEAM Message-ID: <4F36442D.1060202@gmail.com> Hello Group, it's my first post here, although I've been reading many interesting posts here for quite a long time. Anyway, I posted a question on StackOverflow today with the same title (here ). As I've written there, I don't want to start any flame-war, particularly because I'm actually an Erlang fan-boy :) but I'd like to know your opinion on the subject. Here's the original question: ------- Some time ago I got seriously interested in Erlang (coming from C++/PHP/Java world) - and I've seen it has been successfuly used in the industry, by Ericsson, Facebook, Goldman Sachs, etc. So, I thought it would be a great platform to build high demanding apps, with low-latency profile, with a lot cleaner and nicer language than, for example, Java (for me). But after "wow effect" has gone, I discovered that there are many high performance Java libraries that seem to resolve many problems that Erlang is theoretically best suited for (real-time, low-latency applications, concurrency, fault-tolerance, etc.). Moreover, it seems that there are things that, despite Erlang profile, are just not possible to achieve on BEAM (like LMAX Disruptor concurrent framework). So the question arises: is Erlang still the best platform to build such demanding applications ? Wouldn't it be better if we stick to one, very mature (J)VM and try to make it even better than trying to achieve something similar with less resources available (size of OTP team vs. JVM team, supporters, etc) ? And is it possible at all to achieve this kind of performance and adoption with BEAM ? And just to make things clear: I don't want to init a flame war here. I am just curious becouse I really like Erlang and I think it's a great platform and I'd like to invest time and effort to build real-life projects on it. But I'd just like to know what others might say about that and - if I'wrong - maybe someone could correct me. ------- I hope we can discuss it since I think it would be valuable not only for me. Greetings, Radek -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourinov@REDACTED Sat Feb 11 12:14:31 2012 From: bourinov@REDACTED (Max Bourinov) Date: Sat, 11 Feb 2012 15:14:31 +0400 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F36442D.1060202@gmail.com> References: <4F36442D.1060202@gmail.com> Message-ID: Hi Radek, Before answering your question, could you please clarify to the list what is so special in "LMAX Disruptor"? Why it is impossible to implement it in Erlang? Does it really makes sense to use this technology? I asked those questions because I read about "LMAX Disruptor" while ago, but I didn't find anything special in it. Moreover for me is seems as an obvious thing in a shiny package. About Java vs Erlang: After many years in Java world (banking, investing, transportation) I started to work with Erlang (including all guys in our company). Now all our software is written in Erlang/C. It handles huge payload, very easy to scale, in case of problems it heals itself automatically. It is very easy to develop and maintain software in Erlang. This is a true dream technology. We are really happy now. I don't see any Java use cases in our company in the future. p.s. Of course Erlang is not designed for UI. --- So, thanks again for Ericson company and all those great people that developed Erlang (I hope you read this mail. I am really proud to know you) and all of those people that contribute to Erlang/OTP. Thank you! Best regards, Max On Sat, Feb 11, 2012 at 2:34 PM, Radek wrote: > Hello Group, > > it's my first post here, although I've been reading many interesting posts > here for quite a long time. > Anyway, I posted a question on StackOverflow today with the same title ( > here). > As I've written there, I don't want to start any flame-war, particularly > because I'm actually an Erlang fan-boy :) but I'd like to know your opinion > on the subject. Here's the original question: > > ------- > Some time ago I got seriously interested in Erlang (coming from > C++/PHP/Java world) - and I've seen it has been successfuly used in the > industry, by Ericsson, Facebook, Goldman Sachs, etc. So, I thought it would > be a great platform to build high demanding apps, with low-latency profile, > with a lot cleaner and nicer language than, for example, Java (for me). > > But after "wow effect" has gone, I discovered that there are many high > performance Java libraries that seem to resolve many problems that Erlang > is theoretically best suited for (real-time, low-latency applications, > concurrency, fault-tolerance, etc.). Moreover, it seems that there are > things that, despite Erlang profile, are just not possible to achieve on > BEAM (like LMAX Disruptor concurrent framework). > > So the question arises: is Erlang still the best platform to build such > demanding applications ? Wouldn't it be better if we stick to one, very > mature (J)VM and try to make it even better than trying to achieve > something similar with less resources available (size of OTP team vs. JVM > team, supporters, etc) ? And is it possible at all to achieve this kind of > performance and adoption with BEAM ? > > And just to make things clear: I don't want to init a flame war here. I am > just curious becouse I really like Erlang and I think it's a great platform > and I'd like to invest time and effort to build real-life projects on it. > But I'd just like to know what others might say about that and - if I'wrong > - maybe someone could correct me. > ------- > > I hope we can discuss it since I think it would be valuable not only for > me. > > Greetings, > Radek > > _______________________________________________ > 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 Sat Feb 11 12:43:26 2012 From: ulf@REDACTED (Ulf Wiger) Date: Sat, 11 Feb 2012 12:43:26 +0100 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: References: <4F36442D.1060202@gmail.com> Message-ID: <4831CAB4-2E26-4415-806E-1F91C21F3131@feuerlabs.com> Radek, My take on the LMAX Disruptor is that it would probably be hard to get the same raw throughput in Erlang. OTOH, for many products, this is not the clincher, and Erlang may still be the better option over time, since it tends to make it easier to make use of multicore or improvements in cluster technology in order to get the desired performance improvements. In my own experience, this has been demonstrated many times. I have witnessed many different C++-based applications temporarily run circles around their Erlang-based counterparts, but eventually running into severe problems, either because they hit hard limits that stopped them from achieving the required performance on available hardware [1], or because changing requirements added a complexity that they were not designed to manage [2]. Another notable occasion was the shift to multicore, where most C++ and Java developers ended up facing a magnificent challenge, while we could ship Erlang-based systems on the new architectures with only minimal changes. The thing that was missing from your list of things Erlang is that it shines for coordination problems. Erlang is sometimes called an *orchestration language*. This is where most of the competing solutions are often woefully inadequate. The key is where you get inputs from different sources, and must be able to handle events arriving in unexpected order. This is typical for control systems, and actually where the biggest complexity lies. LMAX Disruptor, if I recall correctly, is essentially a processing pipeline, where each job is independent and processed to completion. Thus, there is no coordination complexity to speak of, and the main challenges are managing access to shared resources and achieving high processor utilization. Granted, I have spent my whole career working with problems where Erlang is a near-perfect fit. YMMV depending on domain. :) BR, Ulf W [1] In one case, the performance gains came in no small part from the fact that the C++ app was using static memory management. This worked fine, until the required capacity required more RAM than could be installed onto the available processor board. Rewriting the code to use dynamic memory management was deemed too risky and expensive, given the schedule. [2] See e.g. my presentation, Death by Accidental Complexity, http://www.infoq.com/presentations/Death-by-Accidental-Complexity On 11 Feb 2012, at 12:14, Max Bourinov wrote: > Hi Radek, > > Before answering your question, could you please clarify to the list what is so special in "LMAX Disruptor"? Why it is impossible to implement it in Erlang? Does it really makes sense to use this technology? I asked those questions because I read about "LMAX Disruptor" while ago, but I didn't find anything special in it. Moreover for me is seems as an obvious thing in a shiny package. > > About Java vs Erlang: After many years in Java world (banking, investing, transportation) I started to work with Erlang (including all guys in our company). Now all our software is written in Erlang/C. It handles huge payload, very easy to scale, in case of problems it heals itself automatically. It is very easy to develop and maintain software in Erlang. This is a true dream technology. We are really happy now. I don't see any Java use cases in our company in the future. > > p.s. Of course Erlang is not designed for UI. > > --- > > So, thanks again for Ericson company and all those great people that developed Erlang (I hope you read this mail. I am really proud to know you) and all of those people that contribute to Erlang/OTP. Thank you! > > Best regards, > Max > > > On Sat, Feb 11, 2012 at 2:34 PM, Radek wrote: > Hello Group, > > it's my first post here, although I've been reading many interesting posts here for quite a long time. > Anyway, I posted a question on StackOverflow today with the same title (here). As I've written there, I don't want to start any flame-war, particularly because I'm actually an Erlang fan-boy :) but I'd like to know your opinion on the subject. Here's the original question: > > ------- > Some time ago I got seriously interested in Erlang (coming from C++/PHP/Java world) - and I've seen it has been successfuly used in the industry, by Ericsson, Facebook, Goldman Sachs, etc. So, I thought it would be a great platform to build high demanding apps, with low-latency profile, with a lot cleaner and nicer language than, for example, Java (for me). > > But after "wow effect" has gone, I discovered that there are many high performance Java libraries that seem to resolve many problems that Erlang is theoretically best suited for (real-time, low-latency applications, concurrency, fault-tolerance, etc.). Moreover, it seems that there are things that, despite Erlang profile, are just not possible to achieve on BEAM (like LMAX Disruptor concurrent framework). > > So the question arises: is Erlang still the best platform to build such demanding applications ? Wouldn't it be better if we stick to one, very mature (J)VM and try to make it even better than trying to achieve something similar with less resources available (size of OTP team vs. JVM team, supporters, etc) ? And is it possible at all to achieve this kind of performance and adoption with BEAM ? > > And just to make things clear: I don't want to init a flame war here. I am just curious becouse I really like Erlang and I think it's a great platform and I'd like to invest time and effort to build real-life projects on it. But I'd just like to know what others might say about that and - if I'wrong - maybe someone could correct me. > ------- > > I hope we can discuss it since I think it would be valuable not only for me. > > Greetings, > Radek > > _______________________________________________ > erlang-questions mailing list > 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 poprosturadek@REDACTED Sat Feb 11 13:19:32 2012 From: poprosturadek@REDACTED (Radek) Date: Sat, 11 Feb 2012 13:19:32 +0100 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: References: <4F36442D.1060202@gmail.com> Message-ID: <4F365CD4.30504@gmail.com> # sending once more to show on mailing list Hi Max, Thank you for such a quick answer, it's nice to know there is someone to talk to In posted question I indeed didn't exactly clarifiy what (probably) is so special about these (and others) libraries, so let me do it now. 1. LMAX Disruptor architecture is desribed in Martin Fowler's article here (long) - http://martinfowler.com/articles/lmax.html?t=1319912579 . I got interested in it when I found it's being advertised as a "High Performance Inter-Thread Messaging Library" by which you can run huge number of concurrent tasks with minimal latency between each "thread" (nanoseconds order of magnitude). Of course, it's not "that simple" but still, the numbers are really amazing. 2. Java Chronicle library (https://github.com/peter-lawrey/Java-Chronicle) which describes itself as a "ultra low latency, high throughput, persisted, messaging and event driven in memory database". With their numbers (16 nano-seconds latency and throughputs of 5-20 million messages/record updates per second) I think oi could be easily used as a platform to build very low-latency message-queue or similar kind of middleware. 3. The well-known (it was mentioned on Erlang Factory) library Akka (http://akka.io/) which copies actor model, distribution and fault-tolerance from Erlang and again, looking at their numbers, tends to be faster than Erlang in terms of message passing latency (due to shared heap). 4. Kilim library (http://www.malhar.net/sriram/kilim/) which is somehow similar to akka, but just for message passing. Anyway, similar strength of zero-copy messaging. And probably more, but that's what I remember the most. One other thing is, that could be controversial, arising of Clojure (mainly it, but also other FP languages on JVM) which show that we could be faster just because of the Hot-Spot JIT compiler on JVM. Of course, I could be all wrong, just because I'm rather a beginner (still) in terms of functional programming, Erlang, etc. But I wanted to know your opinion on the subject and maybe show me errors in the way I see this problem. Greetings, Radek -------------- next part -------------- An HTML attachment was scrubbed... URL: From poprosturadek@REDACTED Sat Feb 11 13:20:54 2012 From: poprosturadek@REDACTED (Radek) Date: Sat, 11 Feb 2012 13:20:54 +0100 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4831CAB4-2E26-4415-806E-1F91C21F3131@feuerlabs.com> References: <4F36442D.1060202@gmail.com> <4831CAB4-2E26-4415-806E-1F91C21F3131@feuerlabs.com> Message-ID: <4F365D26.4000004@gmail.com> # the same as above, sorry for inconvenience Hi Ulf, thank you very much for answer. I understand that Erlang has been created in purpose of managing coordination complexity and it does it's job well. But, maybe I'm a bit of devil's advocate, let's say that we (by which I mean mostly OTP team because of their knowledge of Erlang intrinsics but others too) could follow similar direction that Clojure's creator Rick Hickey took. Which means, to build Erlang on JVM, using tools that we already have (like earlier mentioned Java libraries, etc) and optimize it for using with JIT. Of course, it's not obvious that (despite being big effort) it would bring desired performance (although, it seems it would) but some advantages for sure, like ubiquity of JVM, wide gremium of supporters/maintainers, ease of deployment (even single .jar maybe), access to huge variety of other languages and libraries, and even some minor things like proper module managament, etc. As I said before, I'm rather novice in Erlang world (still digging through Erlang and OTP in Action) so all above may be wrong/incomplete/etc. I had this idea some time ago so I finally took decision to write about my concerns here. Greetings, Radek -------------- next part -------------- An HTML attachment was scrubbed... URL: From gleber.p@REDACTED Sat Feb 11 13:37:39 2012 From: gleber.p@REDACTED (Gleb Peregud) Date: Sat, 11 Feb 2012 13:37:39 +0100 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F365D26.4000004@gmail.com> References: <4F36442D.1060202@gmail.com> <4831CAB4-2E26-4415-806E-1F91C21F3131@feuerlabs.com> <4F365D26.4000004@gmail.com> Message-ID: On Sat, Feb 11, 2012 at 13:20, Radek wrote: > But, maybe I'm a bit of devil's advocate, let's say that we (by which I mean > mostly OTP team because of their knowledge of Erlang intrinsics but others > too) could follow similar direction that Clojure's creator Rick Hickey took. > Which means, to build Erlang on JVM, using tools that we already have (like > earlier mentioned Java libraries, etc) and optimize it for using with JIT. http://erjang.org/ - actually there is such solution already :) Not sure how mature it is, but afaik it implements most of stdlib and bifs From poprosturadek@REDACTED Sat Feb 11 13:52:05 2012 From: poprosturadek@REDACTED (Radek) Date: Sat, 11 Feb 2012 13:52:05 +0100 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: References: <4F36442D.1060202@gmail.com> <4831CAB4-2E26-4415-806E-1F91C21F3131@feuerlabs.com> <4F365D26.4000004@gmail.com> Message-ID: <4F366475.4020209@gmail.com> Hi Gleb, Yes, I've seen it already. But I'm not sure if it's exactly what I meant. I rather thought about making something like a framework which would emphasize concurrency, fault-tolerance, etc. and implement Erlang as a DSL just to operate on it. Kresten (author of Erjang) did a great job but took (as I understand it; I may be wrong) little different option and "translated" C code to Java, made .beam files possible to be loaded on JVN thus making it capable of running Erlang code. By making a special framework and Erlang-as-DSL to operate on it, we could then use normal Erlang tools without many downsides of them (for example, we could always rely on messages because of no copy-on-send penalty, use more data structures apart from just lists and tuples, and so on). Of course, I'd like to repeat that I'm not an Erlang-master nor skilled in language design etc so my ideas can be just wrong. Greetings, Radek W dniu 2012-02-11 13:37, Gleb Peregud pisze: > On Sat, Feb 11, 2012 at 13:20, Radek wrote: >> But, maybe I'm a bit of devil's advocate, let's say that we (by which I mean >> mostly OTP team because of their knowledge of Erlang intrinsics but others >> too) could follow similar direction that Clojure's creator Rick Hickey took. >> Which means, to build Erlang on JVM, using tools that we already have (like >> earlier mentioned Java libraries, etc) and optimize it for using with JIT. > http://erjang.org/ - actually there is such solution already :) Not > sure how mature it is, but afaik it implements most of stdlib and bifs From avinash@REDACTED Sat Feb 11 14:28:58 2012 From: avinash@REDACTED (Avinash Dhumane) Date: Sat, 11 Feb 2012 18:58:58 +0530 (IST) Subject: [erlang-questions] searching in an ETS table for substring In-Reply-To: References: <4F33E84B.7020604@gmail.com> Message-ID: <1328966938.72060.YahooMailNeo@web5607.biz.mail.in.yahoo.com> I am learning Erlang, and I must be doing something wrong here; please correct me! Thanks. avinash@REDACTED:~$ erl Erlang R14B02 (erts-5.8.3) [source] [smp:2:2] [rq:2] [async-threads:0] [kernel-poll:false] Eshell V5.8.3? (abort with ^G) 1>? T=ets:new(test, [set]). 16400 2>? ets:insert(T, {"erlang", 1}). true 3>? ets:insert(T, {"ericsson", 2}). true 4> ets:insert(T, {"erring", 3}).?? true 5>?? 5> ets:insert(T, {"ejection", 4}). true 6>? ets:insert(T, {"emersion", 5}). true 7> ets:select(T, [{{'$1', '_'}, [], ['$$']}]). [["erring"], ?["emersion"], ?["ericsson"], ?["erlang"], ?["ejection"]] 8> ets:select(T, [{{'$1', '_'}, [{'==', '$1', "er"++'_'}], ['$$']}]). [] 9> ets:select(T, [{{'$1', '_'}, [{'=:=', '$1', "er"++'_'}], ['$$']}]). [] 10> ets:select(T, [{{'$1', '_'}, [{'=', '$1', "er"++'_'}], ['$$']}]).? ** exception error: bad argument ???? in function? ets:select/2 ??????? called as ets:select(16400, ???????????????????????????? [{{'$1','_'},[{'=','$1',[101,114|'_']}],['$$']}]) 11> ________________________________ From: Ulf Wiger To: Martin Dimitrov Cc: Erlang Questions Sent: Thursday, 9 February 2012 9:18 PM Subject: Re: [erlang-questions] searching in an ETS table for substring If the key is a list (not a binary), you can use the pattern "foo" ++ '_'. There is no equivalent syntax for binaries. If the table is an ordered set, this search will be efficient, since it will use the bound prefix to narrow the search. BR, Ulf On 9 Feb 2012, at 16:37, Martin Dimitrov wrote: > Hello, > > Is it possible to search in an ETS table for a key that starts with > certain characters? > Something equivalent to: > > SELECT * FROM table WHERE name LIKE 'some%' > > I read the documentation for select/2 and it says we can use as guards > functions as is_* and the like. > > Best regards, > > Martin > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Sat Feb 11 14:41:36 2012 From: mfidelman@REDACTED (Miles Fidelman) Date: Sat, 11 Feb 2012 08:41:36 -0500 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F36442D.1060202@gmail.com> References: <4F36442D.1060202@gmail.com> Message-ID: <4F367010.5020200@meetinghouse.net> Radek wrote: > > But after "wow effect" has gone, I discovered that there are many high > performance Java libraries that seem to resolve many problems that > Erlang is theoretically best suited for (real-time, low-latency > applications, concurrency, fault-tolerance, etc.). Moreover, it seems > that there are things that, despite Erlang profile, are just not > possible to achieve on BEAM (like LMAX Disruptor concurrent framework). > > So the question arises: is Erlang still the best platform to build > such demanding applications ? Wouldn't it be better if we stick to > one, very mature (J)VM and try to make it even better than trying to > achieve something similar with less resources available (size of OTP > team vs. JVM team, supporters, etc) ? And is it possible at all to > achieve this kind of performance and adoption with BEAM ? > Two observations, from someone who has just started a migration to Erlang - in service of a project with massive concurrency at its core: 1. Erlang and Java start from very different programming perspectives. As far as I can tell, Erlang is still the only environment designed, from day one, to support massive concurrency (processes as fundamental vs. objects as fundamental). 2. Erlang is about 10 years older than Java, and used for building production systems from its inception. There's a lot more real-world experience packed into Erlang and OTP - particularly where massive concurrency is concerned. Seems to me that Erlang is far more mature than Java for the kinds of problems and environments that are now emerging. Now one might argue that there's a good academic exercise in writing yet another new language, that learns from the lessons of Erlang, and maybe cleans up some of the more obscure syntax, but such an exercise would take a long time before yielding any kind of mature platform. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From attila.r.nohl@REDACTED Sat Feb 11 14:58:00 2012 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Sat, 11 Feb 2012 14:58:00 +0100 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F36442D.1060202@gmail.com> References: <4F36442D.1060202@gmail.com> Message-ID: 2012/2/11, Radek : [...] > But after "wow effect" has gone, I discovered that there are many high > performance Java libraries that seem to resolve many problems that > Erlang is theoretically best suited for (real-time, low-latency > applications, concurrency, fault-tolerance, etc.). Moreover, it seems > that there are things that, despite Erlang profile, are just not > possible to achieve on BEAM (like LMAX Disruptor concurrent framework). > > So the question arises: is Erlang still the best platform to build such > demanding applications ? Wouldn't it be better if we stick to one, very > mature (J)VM and try to make it even better than trying to achieve > something similar with less resources available (size of OTP team vs. > JVM team, supporters, etc) ? And is it possible at all to achieve this > kind of performance and adoption with BEAM ? The feature I really like in Erlang is it's debuggablity. I can connect to the live system, I can get an Erlang shell on the VM and can inspect the system real time. I can also load code (not only to the live system), which makes development really fast. From poprosturadek@REDACTED Sat Feb 11 15:00:35 2012 From: poprosturadek@REDACTED (Radek) Date: Sat, 11 Feb 2012 15:00:35 +0100 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F367010.5020200@meetinghouse.net> References: <4F36442D.1060202@gmail.com> <4F367010.5020200@meetinghouse.net> Message-ID: <4F367483.5000608@gmail.com> Hi Miles, Well, although I didn't mean to write a new language (I meant writing Erlang-for-JVM, but rather as a DSL), I agree that Erlang IS very mature and stable. And of course, it started as a industry-level language, so it's designed to operate as such. I was just wondering if and maybe we could benefit from being hosted on JVM which is, although not THAT industrial-level, also capable of being used in such conditions and is most popular VM on the world (so far). The obvious advantage of using Erlang in such conditions would be (apart from above) just not using verbose Java, which is big plus on it's own :) (in my opinion). So, if we could have both of the worlds, i.e. industry-level of OTP and JVM ubiquity, that would be something huge I think. Greetings, Radek W dniu 2012-02-11 14:41, Miles Fidelman pisze: > Radek wrote: >> >> But after "wow effect" has gone, I discovered that there are many >> high performance Java libraries that seem to resolve many problems >> that Erlang is theoretically best suited for (real-time, low-latency >> applications, concurrency, fault-tolerance, etc.). Moreover, it seems >> that there are things that, despite Erlang profile, are just not >> possible to achieve on BEAM (like LMAX Disruptor concurrent framework). >> >> So the question arises: is Erlang still the best platform to build >> such demanding applications ? Wouldn't it be better if we stick to >> one, very mature (J)VM and try to make it even better than trying to >> achieve something similar with less resources available (size of OTP >> team vs. JVM team, supporters, etc) ? And is it possible at all to >> achieve this kind of performance and adoption with BEAM ? >> > Two observations, from someone who has just started a migration to > Erlang - in service of a project with massive concurrency at its core: > > 1. Erlang and Java start from very different programming > perspectives. As far as I can tell, Erlang is still the only > environment designed, from day one, to support massive concurrency > (processes as fundamental vs. objects as fundamental). > > 2. Erlang is about 10 years older than Java, and used for building > production systems from its inception. There's a lot more real-world > experience packed into Erlang and OTP - particularly where massive > concurrency is concerned. > > Seems to me that Erlang is far more mature than Java for the kinds of > problems and environments that are now emerging. > > Now one might argue that there's a good academic exercise in writing > yet another new language, that learns from the lessons of Erlang, and > maybe cleans up some of the more obscure syntax, but such an exercise > would take a long time before yielding any kind of mature platform. > > Miles Fidelman > > > > From poprosturadek@REDACTED Sat Feb 11 15:07:42 2012 From: poprosturadek@REDACTED (Radek) Date: Sat, 11 Feb 2012 15:07:42 +0100 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: References: <4F36442D.1060202@gmail.com> Message-ID: <4F36762E.20700@gmail.com> Hi Attila, that's undoubtedly one of the very handy features of Erlang/OTP, which has roots in it's real-time non-stop usage. But of course I meant the bigger picture here; live debugging is handy but can be (quite) easily reproduced on the JVM also (using OSGi framework). Of course, Erlang has this from many years now which counts as a big advantage, that's true. Greetings, Radek W dniu 2012-02-11 14:58, Attila Rajmund Nohl pisze: > 2012/2/11, Radek: > [...] >> But after "wow effect" has gone, I discovered that there are many high >> performance Java libraries that seem to resolve many problems that >> Erlang is theoretically best suited for (real-time, low-latency >> applications, concurrency, fault-tolerance, etc.). Moreover, it seems >> that there are things that, despite Erlang profile, are just not >> possible to achieve on BEAM (like LMAX Disruptor concurrent framework). >> >> So the question arises: is Erlang still the best platform to build such >> demanding applications ? Wouldn't it be better if we stick to one, very >> mature (J)VM and try to make it even better than trying to achieve >> something similar with less resources available (size of OTP team vs. >> JVM team, supporters, etc) ? And is it possible at all to achieve this >> kind of performance and adoption with BEAM ? > The feature I really like in Erlang is it's debuggablity. I can > connect to the live system, I can get an Erlang shell on the VM and > can inspect the system real time. I can also load code (not only to > the live system), which makes development really fast. From mfidelman@REDACTED Sat Feb 11 15:44:56 2012 From: mfidelman@REDACTED (Miles Fidelman) Date: Sat, 11 Feb 2012 09:44:56 -0500 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F367483.5000608@gmail.com> References: <4F36442D.1060202@gmail.com> <4F367010.5020200@meetinghouse.net> <4F367483.5000608@gmail.com> Message-ID: <4F367EE8.7020109@meetinghouse.net> Radek wrote: > Hi Miles, > > Well, although I didn't mean to write a new language (I meant writing > Erlang-for-JVM, but rather as a DSL), I agree that Erlang IS very > mature and stable. And of course, it started as a industry-level > language, so it's designed to operate as such. > I was just wondering if and maybe we could benefit from being hosted > on JVM which is, although not THAT industrial-level, also capable of > being used in such conditions and is most popular VM on the world (so > far). The obvious advantage of using Erlang in such conditions would > be (apart from above) just not using verbose Java, which is big plus > on it's own :) (in my opinion). > > So, if we could have both of the worlds, i.e. industry-level of OTP > and JVM ubiquity, that would be something huge I think. > But why would I want to run massively concurrent software on a JVM? What makes Erlang different are its underpinnings. Massive concurrency on top of a JVM is just broken. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From vinoski@REDACTED Sat Feb 11 16:19:56 2012 From: vinoski@REDACTED (Steve Vinoski) Date: Sat, 11 Feb 2012 10:19:56 -0500 Subject: [erlang-questions] searching in an ETS table for substring In-Reply-To: <1328966938.72060.YahooMailNeo@web5607.biz.mail.in.yahoo.com> References: <4F33E84B.7020604@gmail.com> <1328966938.72060.YahooMailNeo@web5607.biz.mail.in.yahoo.com> Message-ID: On Sat, Feb 11, 2012 at 8:28 AM, Avinash Dhumane wrote: > I am learning Erlang, and I must be doing something wrong here; please > correct me! Thanks. > > avinash@REDACTED:~$ erl > Erlang R14B02 (erts-5.8.3) [source] [smp:2:2] [rq:2] [async-threads:0] > [kernel-poll:false] > > Eshell V5.8.3? (abort with ^G) > 1>? T=ets:new(test, [set]). > 16400 > 2>? ets:insert(T, {"erlang", 1}). > true > 3>? ets:insert(T, {"ericsson", 2}). > true > 4> ets:insert(T, {"erring", 3}). > true > 5> > 5> ets:insert(T, {"ejection", 4}). > true > 6>? ets:insert(T, {"emersion", 5}). > true > 7> ets:select(T, [{{'$1', '_'}, [], ['$$']}]). > [["erring"], > ?["emersion"], > ?["ericsson"], > ?["erlang"], > ?["ejection"]] > 8> ets:select(T, [{{'$1', '_'}, [{'==', '$1', "er"++'_'}], ['$$']}]). > [] > 9> ets:select(T, [{{'$1', '_'}, [{'=:=', '$1', "er"++'_'}], ['$$']}]). > [] > 10> ets:select(T, [{{'$1', '_'}, [{'=', '$1', "er"++'_'}], ['$$']}]). > ** exception error: bad argument > ???? in function? ets:select/2 > ??????? called as ets:select(16400, > > [{{'$1','_'},[{'=','$1',[101,114|'_']}],['$$']}]) > 11> One approach: 1> ets:select(T, [{{"er"++'_','_'}, [], ['$_']}]). [{"erring",3},{"ericsson",2},{"erlang",1}] But note this returns entire objects, not just keys. Still, I think that's what Martin might have wanted, since it matches what his original SQL select example would do. Another approach, fetching just the keys: 2> MS = ets:fun2ms(fun({K,_}) when is_list(K), hd(K) =:= $e, hd(tl(K)) =:= $r -> K end). [{{'$1','_'}, [{is_list,'$1'}, {'=:=',{hd,'$1'},101}, {'=:=',{hd,{tl,'$1'}},114}], ['$1']}] 3> ets:select(T, MS). ["erring","ericsson","erlang"] This approach can work OK if you're matching a prefix of just 2 or 3 characters, but could get tedious beyond that. --steve From poprosturadek@REDACTED Sat Feb 11 17:03:17 2012 From: poprosturadek@REDACTED (Radek) Date: Sat, 11 Feb 2012 17:03:17 +0100 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F367EE8.7020109@meetinghouse.net> References: <4F36442D.1060202@gmail.com> <4F367010.5020200@meetinghouse.net> <4F367483.5000608@gmail.com> <4F367EE8.7020109@meetinghouse.net> Message-ID: <4F369145.5080403@gmail.com> Well, I think it depends. It's true that using default concurrency libraries is quite difficult and error prone but as I said before, thare are others which mimics Erlang approach (and do it well, just looking at numbers). But, I'm not sure if it's a good idea to run anything massively concurrent on JVM; that's one of reasons I've started this topic. Greetings, Radek W dniu 2012-02-11 15:44, Miles Fidelman pisze: > Radek wrote: >> Hi Miles, >> >> Well, although I didn't mean to write a new language (I meant writing >> Erlang-for-JVM, but rather as a DSL), I agree that Erlang IS very >> mature and stable. And of course, it started as a industry-level >> language, so it's designed to operate as such. >> I was just wondering if and maybe we could benefit from being hosted >> on JVM which is, although not THAT industrial-level, also capable of >> being used in such conditions and is most popular VM on the world (so >> far). The obvious advantage of using Erlang in such conditions would >> be (apart from above) just not using verbose Java, which is big plus >> on it's own :) (in my opinion). >> >> So, if we could have both of the worlds, i.e. industry-level of OTP >> and JVM ubiquity, that would be something huge I think. >> > > But why would I want to run massively concurrent software on a JVM? > What makes Erlang different are its underpinnings. Massive > concurrency on top of a JVM is just broken. > > > From mfidelman@REDACTED Sat Feb 11 17:09:14 2012 From: mfidelman@REDACTED (Miles Fidelman) Date: Sat, 11 Feb 2012 11:09:14 -0500 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F369145.5080403@gmail.com> References: <4F36442D.1060202@gmail.com> <4F367010.5020200@meetinghouse.net> <4F367483.5000608@gmail.com> <4F367EE8.7020109@meetinghouse.net> <4F369145.5080403@gmail.com> Message-ID: <4F3692AA.4060701@meetinghouse.net> Radek wrote: > Well, I think it depends. It's true that using default concurrency > libraries is quite difficult and error prone but as I said before, > thare are others which mimics Erlang approach (and do it well, just > looking at numbers). > > But, I'm not sure if it's a good idea to run anything massively > concurrent on JVM; that's one of reasons I've started this topic. The only way to run something massively concurrent on a JVM is to write a collection of libraries that would look suspiciously like BEAM. So why bother? -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From bourinov@REDACTED Sat Feb 11 17:13:11 2012 From: bourinov@REDACTED (Max Bourinov) Date: Sat, 11 Feb 2012 20:13:11 +0400 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F3692AA.4060701@meetinghouse.net> References: <4F36442D.1060202@gmail.com> <4F367010.5020200@meetinghouse.net> <4F367483.5000608@gmail.com> <4F367EE8.7020109@meetinghouse.net> <4F369145.5080403@gmail.com> <4F3692AA.4060701@meetinghouse.net> Message-ID: +1 On Sat, Feb 11, 2012 at 8:09 PM, Miles Fidelman wrote: > Radek wrote: > >> Well, I think it depends. It's true that using default concurrency >> libraries is quite difficult and error prone but as I said before, thare >> are others which mimics Erlang approach (and do it well, just looking at >> numbers). >> >> But, I'm not sure if it's a good idea to run anything massively >> concurrent on JVM; that's one of reasons I've started this topic. >> > > The only way to run something massively concurrent on a JVM is to write a > collection of libraries that would look suspiciously like BEAM. So why > bother? > > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > > ______________________________**_________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/**listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Sat Feb 11 17:19:59 2012 From: tony@REDACTED (Tony Rogvall) Date: Sat, 11 Feb 2012 17:19:59 +0100 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: References: <4F36442D.1060202@gmail.com> <4F367010.5020200@meetinghouse.net> <4F367483.5000608@gmail.com> <4F367EE8.7020109@meetinghouse.net> <4F369145.5080403@gmail.com> <4F3692AA.4060701@meetinghouse.net> Message-ID: I do agree. But on the other hand, there is nothing stopping people to implement the Erlang platform, and compete. So stop talking about it and start hacking. Let the best implementation win ;) /Tony On 11 feb 2012, at 17:13, Max Bourinov wrote: > +1 > > On Sat, Feb 11, 2012 at 8:09 PM, Miles Fidelman wrote: > Radek wrote: > Well, I think it depends. It's true that using default concurrency libraries is quite difficult and error prone but as I said before, thare are others which mimics Erlang approach (and do it well, just looking at numbers). > > But, I'm not sure if it's a good idea to run anything massively concurrent on JVM; that's one of reasons I've started this topic. > > The only way to run something massively concurrent on a JVM is to write a collection of libraries that would look suspiciously like BEAM. So why bother? > > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions "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 poprosturadek@REDACTED Sat Feb 11 17:22:40 2012 From: poprosturadek@REDACTED (Radek) Date: Sat, 11 Feb 2012 17:22:40 +0100 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F3692AA.4060701@meetinghouse.net> References: <4F36442D.1060202@gmail.com> <4F367010.5020200@meetinghouse.net> <4F367483.5000608@gmail.com> <4F367EE8.7020109@meetinghouse.net> <4F369145.5080403@gmail.com> <4F3692AA.4060701@meetinghouse.net> Message-ID: <4F3695D0.5010609@gmail.com> Well, that's a good point. But it also shows that there is place for improvement. Because, it would be really come in handy when one could write correct, highly-concurrent, callback-free code (Erlang), using his favourite libraries/frameworks (Java) on a platform that his company uses (JVM). Like I said, I like Erlang. This is the reason why I left Java etc, just because it's not nice to write something that has to be concurrent and (mainly at least) correct, not to mention development time (which is usually shorter in Java). But I sometimes think that we could make one step more and, as I would call it, join efforts (with JVM community, so to speak). Greetings, Radek W dniu 2012-02-11 17:09, Miles Fidelman pisze: > Radek wrote: >> Well, I think it depends. It's true that using default concurrency >> libraries is quite difficult and error prone but as I said before, >> thare are others which mimics Erlang approach (and do it well, just >> looking at numbers). >> >> But, I'm not sure if it's a good idea to run anything massively >> concurrent on JVM; that's one of reasons I've started this topic. > > The only way to run something massively concurrent on a JVM is to > write a collection of libraries that would look suspiciously like > BEAM. So why bother? > > From erlang@REDACTED Sat Feb 11 18:02:07 2012 From: erlang@REDACTED (Joe Armstrong) Date: Sat, 11 Feb 2012 18:02:07 +0100 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F36442D.1060202@gmail.com> References: <4F36442D.1060202@gmail.com> Message-ID: I'll try and give a short answer to your question. To start with you are comparing chalk with cheese - Erlang was NOT designed to be a fast messaging passing language. It was designed for building fault-tolerant applications - it wasn't designed for speed it was designed for safety. A lot of the message passing platforms you read about, and mention in the same breath as Erlang were designed for speed and not safety - so it's hardly surprising that is the absence of errors these other platforms are faster than Erlang. Where Erlang should excel is when things go wrong - when the code is buggy and crashes, when the system is overloaded, when you stress things in unexpected ways. The Erlang view of the world is very different to the view of the world used in most other languages. Take a web server, for example. In the conventional view of the world if there might be one web server per machine, the web server might spawn an OS process for each incoming task (if it wants safety) of it might handle all sessions in the same task if it wants speed but no safety. It (the web server) uses OS processes for reasons of safety - to isolate the user sessions from each other - but this is very slow. What happens if there is a rare error in the web-server code itself - one that is very rarely encountered. Does this affect *all* user sessions or only the session where the error occurred? - My guess is that all sessions will collapse if the web-server itself collapses. How is a web-server in Erlang written? On the face of things it looks like any other web sever - but an Erlang system that appears from the outside to be handling (say) 2000 user sessions, is NOT one web server with 2000 sessions - it is 2000 erlang process (all independent) and each one is running ONE web server. So in the Erlang case we have 2000 web servers, each running one user session - in the conventional case we have one web server running 2000 sessions. Back to my question - what happens if there is a rare error in the web server code itself which is triggered in one session? In the Erlang case only one web server dies and all the rest survive. In the case where all 2000 sessions are handled by the faster server all sessions die. So you choose - fast or safe? - If you want the fastest possible solution Erlang is not the answer - BUT it will be unsafe. Adding checks and recovery mechanism COSTS something. There are no free lunches. I often see messaging passing systems mentioned that are said to have "Erlang like semantics" and are said to be faster. But these are unsafe systems and Erlang like semantics means *a lot more* than fast message passing. Erlang is good at what it was designed to be good at - which was building fault-tolerant soft real-time distributed systems with dynamic code upgrade - I know of nothing that has remotely similar semantics. There are *many* systems with superficial similarities - but non that I would trust to build fault-tolerant systems with. Cheers /Joe On Sat, Feb 11, 2012 at 11:34 AM, Radek wrote: > Hello Group, > > it's my first post here, although I've been reading many interesting posts > here for quite a long time. > Anyway, I posted a question on StackOverflow today with the same title > (here). As I've written there, I don't want to start any flame-war, > particularly because I'm actually an Erlang fan-boy :) but I'd like to know > your opinion on the subject. Here's the original question: > > ------- > Some time ago I got seriously interested in Erlang (coming from C++/PHP/Java > world) - and I've seen it has been successfuly used in the industry, by > Ericsson, Facebook, Goldman Sachs, etc. So, I thought it would be a great > platform to build high demanding apps, with low-latency profile, with a lot > cleaner and nicer language than, for example, Java (for me). > > But after "wow effect" has gone, I discovered that there are many high > performance Java libraries that seem to resolve many problems that Erlang is > theoretically best suited for (real-time, low-latency applications, > concurrency, fault-tolerance, etc.). Moreover, it seems that there are > things that, despite Erlang profile, are just not possible to achieve on > BEAM (like LMAX Disruptor concurrent framework). > > So the question arises: is Erlang still the best platform to build such > demanding applications ? Wouldn't it be better if we stick to one, very > mature (J)VM and try to make it even better than trying to achieve something > similar with less resources available (size of OTP team vs. JVM team, > supporters, etc) ? And is it possible at all to achieve this kind of > performance and adoption with BEAM ? > > And just to make things clear: I don't want to init a flame war here. I am > just curious becouse I really like Erlang and I think it's a great platform > and I'd like to invest time and effort to build real-life projects on it. > But I'd just like to know what others might say about that and - if I'wrong > - maybe someone could correct me. > ------- > > I hope we can discuss it since I think it would be valuable not only for me. > > Greetings, > Radek > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From mattevans123@REDACTED Sat Feb 11 19:37:51 2012 From: mattevans123@REDACTED (Matthew Evans) Date: Sat, 11 Feb 2012 13:37:51 -0500 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F365D26.4000004@gmail.com> References: <4F36442D.1060202@gmail.com>, , <4831CAB4-2E26-4415-806E-1F91C21F3131@feuerlabs.com>, <4F365D26.4000004@gmail.com> Message-ID: Yes, I could write an essay on this one.. The other thing to remember about all these Java (and C++) libraries is that there are, frankly, so many of them. Each time you look at one it's a whole different set of semantics that need learning. With Erlang you have a single set of concurrency principles that need learning that are core to the language, and who's behavior is well understood. It makes for code that is easy to reason about, especially when things go wrong. I also worry that many of these Java libraries are only going to be supported until something shinier, newer or better comes along. I should add here that I have recently started learning Java, and quite like the language, especially compared to the effects that C++ has had on my hairline. ;-) Having said that there is a valid criticism of Erlang in that it is often perceived to be too slow. As Joe said, you can't have all the features of resilience and reliability without some cost, but when trying to "sell" Erlang it's often the first argument against Erlang that I hear. The pointy haired managers look at things like the Alioth shootout and see Erlang perform poorly for most tests. Now, most Erlang users will correctly say "well, Erlang isn't designed for those types of highly serial tasks, use C, C++ or Java for that instead, and use Erlang where it makes sense". But this now means that a company needs to embrace 2 (perhaps more) languages to do a job. This isn't necessarily a bad thing, but can make for pain when hiring, training and retaining staff. My point is that I don't think Erlang will ever be as fast as Java and certainly never as fast as C/C++, but I would like to see a greater focus on performance, perhaps get it into the top 10 languages for performance. I'm happy to see that work is been done WRT to JIT in the Erlang VM, and LLVM+HiPE, so maybe future releases will address those concerns. I've also often wondered if it makes sense to implement some of the Kernel and STDLIB modules as BIFs instead of in Erlang. Would that improve things? Matt________________________________ > Date: Sat, 11 Feb 2012 13:20:54 +0100 > From: poprosturadek@REDACTED > To: ulf@REDACTED > CC: erlang-questions@REDACTED > Subject: Re: [erlang-questions] The future of Erlang and BEAM > > # the same as above, sorry for inconvenience > > Hi Ulf, > > thank you very much for answer. > > I understand that Erlang has been created in purpose of managing > coordination complexity and it does it's job well. > But, maybe I'm a bit of devil's advocate, let's say that we (by which I > mean mostly OTP team because of their knowledge of Erlang intrinsics > but others too) could follow similar direction that Clojure's creator > Rick Hickey took. Which means, to build Erlang on JVM, using tools that > we already have (like earlier mentioned Java libraries, etc) and > optimize it for using with JIT. > > Of course, it's not obvious that (despite being big effort) it would > bring desired performance (although, it seems it would) but some > advantages for sure, like ubiquity of JVM, wide gremium of > supporters/maintainers, ease of deployment (even single .jar maybe), > access to huge variety of other languages and libraries, and even some > minor things like proper module managament, etc. > > As I said before, I'm rather novice in Erlang world (still digging > through Erlang and OTP in Action) so all above may be > wrong/incomplete/etc. I had this idea some time ago so I finally took > decision to write about my concerns here. > > Greetings, > Radek > > _______________________________________________ erlang-questions > mailing list erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtsiour@REDACTED Sat Feb 11 19:42:52 2012 From: gtsiour@REDACTED (Yiannis Tsiouris) Date: Sat, 11 Feb 2012 20:42:52 +0200 Subject: [erlang-questions] on_load attribute + inline compile flag Message-ID: <4F36B6AC.2080108@softlab.ntua.gr> Hi all, I've noticed the following thing that looks like a bug to me! I have (the attached) my_on_load module that has an "on_load" hook. When I BEAM-compile my_on_load.erl with no flags everything is fine; on_load works as expected: > yiannis@REDACTED [~/Desktop]>>= erlc my_on_load.erl > yiannis@REDACTED [~/Desktop]>>= erl > Erlang R15B (erts-5.9) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.9 (abort with ^G) > 1> code:is_loaded(my_on_load). > false > 2> code:load_file(my_on_load). > Bump! On_load works! > {module,my_on_load} > 4> code:is_loaded(my_on_load). > {file,"/home/yiannis/Desktop/my_on_load.beam"} While, I use "+inline" flag: > yiannis@REDACTED [~/Desktop]>>= erlc +inline my_on_load.erl > yiannis@REDACTED [~/Desktop]>>= erl > Erlang R15B (erts-5.9) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.9 (abort with ^G) > 1> code:is_loaded(my_on_load). > false > 2> code:load_file(my_on_load). > {module,my_on_load} > 4> code:is_loaded(my_on_load). > {file,"/home/yiannis/Desktop/my_on_load.beam"} No call to bump/0 is performed! Is bump/0 optimized-out because it is not exported (due to the "+inline")? Is this expected behaviour? Cause if it is, it 's not very clear to me why! Plus, it took me the whole day to track a strange bug that involved loading some NIFs with "on_load"! :-) Best wishes, Yiannis -- Yiannis Tsiouris Ph.D. student, Software Engineering Laboratory, National Technical University of Athens WWW: http://www.softlab.ntua.gr/~gtsiour -------------- next part -------------- A non-text attachment was scrubbed... Name: my_on_load.erl Type: text/x-erlang Size: 176 bytes Desc: not available URL: From mfidelman@REDACTED Sat Feb 11 19:48:36 2012 From: mfidelman@REDACTED (Miles Fidelman) Date: Sat, 11 Feb 2012 13:48:36 -0500 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: References: <4F36442D.1060202@gmail.com> Message-ID: <4F36B804.1060507@meetinghouse.net> Joe, I'll add one more thing - correct me if I'm wrong here (you are, after all the expert :-).... Joe Armstrong wrote: > To start with you are comparing chalk with cheese - Erlang was > NOT designed to be a fast messaging passing language. It was designed > for building fault-tolerant applications - it wasn't designed > for speed it was designed for safety. > > Erlang also is really nice for building systems where you want to THINK and organize your code in terms of concurrent processes. Simulation is the application that comes to mind (based on my own experience). If you want to simulate 10,000 tanks, on a simulated battlefield - my first instinct is "each tank is a process." Turns out, that most (all?) conventional simulators model each tank as an object, with a small number of threads touching each object 20-40 times per second (a state update thread, a display thread, etc.) Leads to really horrible spaghetti code and systems that are really hard to change. I found Erlang when I joined a simulation software house, after a background in networking (where we spawn processes all the time). Programmers kept telling me that "we can't spawn 10,000 processes, the overhead will kill us" - which is true with C++ (what we were using) or Java. I did some digging and found Erlang as a counter-example. I guess what I draw from this is that, while Erlang might not be blindingly fast for some applications, if I want to write code that spawns 1000s of processes, it's a lot faster than anything else around. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From hynek@REDACTED Sat Feb 11 20:25:26 2012 From: hynek@REDACTED (Hynek Vychodil) Date: Sat, 11 Feb 2012 20:25:26 +0100 Subject: [erlang-questions] searching in an ETS table for substring In-Reply-To: References: <4F33E84B.7020604@gmail.com> <1328966938.72060.YahooMailNeo@web5607.biz.mail.in.yahoo.com> Message-ID: This approach seems work as well: ets:select(T, [{{"er"++'$1','_'}, [], ["er"++'$1']}]). ["erring","ericsson","erlang"] On Sat, Feb 11, 2012 at 4:19 PM, Steve Vinoski wrote: > On Sat, Feb 11, 2012 at 8:28 AM, Avinash Dhumane wrote: >> I am learning Erlang, and I must be doing something wrong here; please >> correct me! Thanks. >> >> avinash@REDACTED:~$ erl >> Erlang R14B02 (erts-5.8.3) [source] [smp:2:2] [rq:2] [async-threads:0] >> [kernel-poll:false] >> >> Eshell V5.8.3? (abort with ^G) >> 1>? T=ets:new(test, [set]). >> 16400 >> 2>? ets:insert(T, {"erlang", 1}). >> true >> 3>? ets:insert(T, {"ericsson", 2}). >> true >> 4> ets:insert(T, {"erring", 3}). >> true >> 5> >> 5> ets:insert(T, {"ejection", 4}). >> true >> 6>? ets:insert(T, {"emersion", 5}). >> true >> 7> ets:select(T, [{{'$1', '_'}, [], ['$$']}]). >> [["erring"], >> ?["emersion"], >> ?["ericsson"], >> ?["erlang"], >> ?["ejection"]] >> 8> ets:select(T, [{{'$1', '_'}, [{'==', '$1', "er"++'_'}], ['$$']}]). >> [] >> 9> ets:select(T, [{{'$1', '_'}, [{'=:=', '$1', "er"++'_'}], ['$$']}]). >> [] >> 10> ets:select(T, [{{'$1', '_'}, [{'=', '$1', "er"++'_'}], ['$$']}]). >> ** exception error: bad argument >> ???? in function? ets:select/2 >> ??????? called as ets:select(16400, >> >> [{{'$1','_'},[{'=','$1',[101,114|'_']}],['$$']}]) >> 11> > > One approach: > > 1> ets:select(T, [{{"er"++'_','_'}, [], ['$_']}]). > [{"erring",3},{"ericsson",2},{"erlang",1}] > > But note this returns entire objects, not just keys. Still, I think > that's what Martin might have wanted, since it matches what his > original SQL select example would do. > > Another approach, fetching just the keys: > > 2> MS = ets:fun2ms(fun({K,_}) when is_list(K), hd(K) =:= $e, hd(tl(K)) > =:= $r -> K end). > [{{'$1','_'}, > ?[{is_list,'$1'}, > ? {'=:=',{hd,'$1'},101}, > ? {'=:=',{hd,{tl,'$1'}},114}], > ?['$1']}] > 3> ets:select(T, MS). > ["erring","ericsson","erlang"] > > This approach can work OK if you're matching a prefix of just 2 or 3 > characters, but could get tedious beyond that. > > --steve > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Hynek Vychodil BI consultant GoodData n?m?st? 28. ??jna 1104/17, 602 00, Brno - ?ern? Pole Office: ? +420 530 50 7704 E-mail: ?hynek@REDACTED Web: ? ? www.gooddata.com From hynek@REDACTED Sat Feb 11 20:29:01 2012 From: hynek@REDACTED (Hynek Vychodil) Date: Sat, 11 Feb 2012 20:29:01 +0100 Subject: [erlang-questions] searching in an ETS table for substring In-Reply-To: References: <4F33E84B.7020604@gmail.com> <1328966938.72060.YahooMailNeo@web5607.biz.mail.in.yahoo.com> Message-ID: On Sat, Feb 11, 2012 at 8:25 PM, Hynek Vychodil wrote: > This approach seems work as well: > > ets:select(T, [{{"er"++'$1','_'}, [], ["er"++'$1']}]). > ["erring","ericsson","erlang"] and dynamic creation works as well Prefix = "er", ets:select(T, [{{Prefix++'$1','_'}, [], [Prefix++'$1']}]). ["erring","ericsson","erlang"] > > On Sat, Feb 11, 2012 at 4:19 PM, Steve Vinoski wrote: >> On Sat, Feb 11, 2012 at 8:28 AM, Avinash Dhumane wrote: >>> I am learning Erlang, and I must be doing something wrong here; please >>> correct me! Thanks. >>> >>> avinash@REDACTED:~$ erl >>> Erlang R14B02 (erts-5.8.3) [source] [smp:2:2] [rq:2] [async-threads:0] >>> [kernel-poll:false] >>> >>> Eshell V5.8.3? (abort with ^G) >>> 1>? T=ets:new(test, [set]). >>> 16400 >>> 2>? ets:insert(T, {"erlang", 1}). >>> true >>> 3>? ets:insert(T, {"ericsson", 2}). >>> true >>> 4> ets:insert(T, {"erring", 3}). >>> true >>> 5> >>> 5> ets:insert(T, {"ejection", 4}). >>> true >>> 6>? ets:insert(T, {"emersion", 5}). >>> true >>> 7> ets:select(T, [{{'$1', '_'}, [], ['$$']}]). >>> [["erring"], >>> ?["emersion"], >>> ?["ericsson"], >>> ?["erlang"], >>> ?["ejection"]] >>> 8> ets:select(T, [{{'$1', '_'}, [{'==', '$1', "er"++'_'}], ['$$']}]). >>> [] >>> 9> ets:select(T, [{{'$1', '_'}, [{'=:=', '$1', "er"++'_'}], ['$$']}]). >>> [] >>> 10> ets:select(T, [{{'$1', '_'}, [{'=', '$1', "er"++'_'}], ['$$']}]). >>> ** exception error: bad argument >>> ???? in function? ets:select/2 >>> ??????? called as ets:select(16400, >>> >>> [{{'$1','_'},[{'=','$1',[101,114|'_']}],['$$']}]) >>> 11> >> >> One approach: >> >> 1> ets:select(T, [{{"er"++'_','_'}, [], ['$_']}]). >> [{"erring",3},{"ericsson",2},{"erlang",1}] >> >> But note this returns entire objects, not just keys. Still, I think >> that's what Martin might have wanted, since it matches what his >> original SQL select example would do. >> >> Another approach, fetching just the keys: >> >> 2> MS = ets:fun2ms(fun({K,_}) when is_list(K), hd(K) =:= $e, hd(tl(K)) >> =:= $r -> K end). >> [{{'$1','_'}, >> ?[{is_list,'$1'}, >> ? {'=:=',{hd,'$1'},101}, >> ? {'=:=',{hd,{tl,'$1'}},114}], >> ?['$1']}] >> 3> ets:select(T, MS). >> ["erring","ericsson","erlang"] >> >> This approach can work OK if you're matching a prefix of just 2 or 3 >> characters, but could get tedious beyond that. >> >> --steve >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > Hynek Vychodil > BI consultant > > GoodData > n?m?st? 28. ??jna 1104/17, 602 00, Brno - ?ern? Pole > Office: ? +420 530 50 7704 > E-mail: ?hynek@REDACTED > Web: ? ? www.gooddata.com -- Hynek Vychodil BI consultant GoodData n?m?st? 28. ??jna 1104/17, 602 00, Brno - ?ern? Pole Office: ? +420 530 50 7704 E-mail: ?hynek@REDACTED Web: ? ? www.gooddata.com From poprosturadek@REDACTED Sat Feb 11 20:33:27 2012 From: poprosturadek@REDACTED (Radek) Date: Sat, 11 Feb 2012 20:33:27 +0100 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F36B804.1060507@meetinghouse.net> References: <4F36442D.1060202@gmail.com> <4F36B804.1060507@meetinghouse.net> Message-ID: <4F36C287.6090504@gmail.com> Dear Group, first of all, I am pretty amazed that my question started such a nice discussion with interesting posts. What amazes me even more, that (with full&great respect to the others) even such known people like Joe Armstrong or Ulf Wiger found some time to answer me directly. I think it's truly amazing :) Thank you very much, all of you, for such interesting answers. Now I think I understand what is the real difference between Erlang & rest of the world. I really haven't thought about safety and reliability in the first place. Now it seems to be logical for me that "raw performance" isn't an only factor which I should consider. Thank all of you very much, once more. Now I think I'm Erlang fab-boy even more :) Greetings, Radek W dniu 2012-02-11 19:48, Miles Fidelman pisze: > Joe, > > I'll add one more thing - correct me if I'm wrong here (you are, after > all the expert :-).... > > Joe Armstrong wrote: >> To start with you are comparing chalk with cheese - Erlang was >> NOT designed to be a fast messaging passing language. It was designed >> for building fault-tolerant applications - it wasn't designed >> for speed it was designed for safety. >> >> > Erlang also is really nice for building systems where you want to > THINK and organize your code in terms of concurrent processes. > Simulation is the application that comes to mind (based on my own > experience). > > If you want to simulate 10,000 tanks, on a simulated battlefield - my > first instinct is "each tank is a process." Turns out, that most > (all?) conventional simulators model each tank as an object, with a > small number of threads touching each object 20-40 times per second (a > state update thread, a display thread, etc.) Leads to really horrible > spaghetti code and systems that are really hard to change. > > I found Erlang when I joined a simulation software house, after a > background in networking (where we spawn processes all the time). > Programmers kept telling me that "we can't spawn 10,000 processes, the > overhead will kill us" - which is true with C++ (what we were using) > or Java. I did some digging and found Erlang as a counter-example. > > I guess what I draw from this is that, while Erlang might not be > blindingly fast for some applications, if I want to write code that > spawns 1000s of processes, it's a lot faster than anything else around. > > Miles Fidelman > > > > > From mononcqc@REDACTED Sat Feb 11 21:33:58 2012 From: mononcqc@REDACTED (Fred Hebert) Date: Sat, 11 Feb 2012 15:33:58 -0500 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: References: <4F36442D.1060202@gmail.com> <4831CAB4-2E26-4415-806E-1F91C21F3131@feuerlabs.com> <4F365D26.4000004@gmail.com> Message-ID: The best question to ask after this is "What's slow?", "What do you consider to be fast enough?", "What are your requirements?". You often (but not always) find out that they do not really know what they want, so they aim for the fastest overall thinking 'surely, I won't make a mistake there.' Do you need a 5 nanosecond message sending requirement when you're going to treat the message for 20 milliseconds anyway? In some cases they do need something too fast for Erlang, or think Erlang is optimized for areas it isn't. Then being honest will be the best argument to prove you're giving sane recommendations and are not a fanboy. But before knowing what they really need, it is pretty hard to counter any argument. There's no use fighting someone whose task to accomplish requires too much work or time in Erlang, but sometimes apprehensions come from not knowing the technology or the problem enough; that's where we can help. On Sat, Feb 11, 2012 at 1:37 PM, Matthew Evans wrote: > > Having said that there is a valid criticism of Erlang in that it is often > perceived to be too slow. As Joe said, you can't have all the features of > resilience and reliability without some cost, but when trying to "sell" > Erlang it's often the first argument against Erlang that I hear. The pointy > haired managers look at things like the Alioth shootout and see Erlang > perform poorly for most tests. Now, most Erlang users will correctly say > "well, Erlang isn't designed for those types of highly serial tasks, use C, > C++ or Java for that instead, and use Erlang where it makes sense". But > this now means that a company needs to embrace 2 (perhaps more) languages > to do a job. This isn't necessarily a bad thing, but can make for pain when > hiring, training and retaining staff. > > My point is that I don't think Erlang will ever be as fast as Java and > certainly never as fast as C/C++, but I would like to see a greater focus > on performance, perhaps get it into the top 10 languages for performance. > I'm happy to see that work is been done WRT to JIT in the Erlang VM, and > LLVM+HiPE, so maybe future releases will address those concerns. > > I've also often wondered if it makes sense to implement some of the Kernel > and STDLIB modules as BIFs instead of in Erlang. Would that improve things? > > Matt > ________________________________ > > Date: Sat, 11 Feb 2012 13:20:54 +0100 > > From: poprosturadek@REDACTED > > To: ulf@REDACTED > > CC: erlang-questions@REDACTED > > Subject: Re: [erlang-questions] The future of Erlang and BEAM > > > > # the same as above, sorry for inconvenience > > > > Hi Ulf, > > > > thank you very much for answer. > > > > I understand that Erlang has been created in purpose of managing > > coordination complexity and it does it's job well. > > But, maybe I'm a bit of devil's advocate, let's say that we (by which I > > mean mostly OTP team because of their knowledge of Erlang intrinsics > > but others too) could follow similar direction that Clojure's creator > > Rick Hickey took. Which means, to build Erlang on JVM, using tools that > > we already have (like earlier mentioned Java libraries, etc) and > > optimize it for using with JIT. > > > > Of course, it's not obvious that (despite being big effort) it would > > bring desired performance (although, it seems it would) but some > > advantages for sure, like ubiquity of JVM, wide gremium of > > supporters/maintainers, ease of deployment (even single .jar maybe), > > access to huge variety of other languages and libraries, and even some > > minor things like proper module managament, etc. > > > > As I said before, I'm rather novice in Erlang world (still digging > > through Erlang and OTP in Action) so all above may be > > wrong/incomplete/etc. I had this idea some time ago so I finally took > > decision to write about my concerns here. > > > > Greetings, > > Radek > > > > _______________________________________________ erlang-questions > > mailing list 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 watson.timothy@REDACTED Sat Feb 11 21:49:23 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Sat, 11 Feb 2012 20:49:23 +0000 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: References: <4F36442D.1060202@gmail.com> <4831CAB4-2E26-4415-806E-1F91C21F3131@feuerlabs.com> <4F365D26.4000004@gmail.com> Message-ID: I'd really second this. I work with both Erlang and Java (alongside a few other bits and peices) on a daily basis and slowness isn't something I've really run into major difficulties with Erlang at all. If you take a look at that rather well documented case of the chat at Github who implemented an Erlang git daemon, but then found it to be too slow so abandoned it. A more experiences Erlang programmer came along and refactored the code for massive performance improvements. It's true that sometimes you need raw throughput that Erlang can't provide and need to break out to C/C++ with a port/nif or whatever, but that's not so often the case. Also I prefer to 'pick the right tool for the job' and not every system has to be monolithic running on only one VM. Cheers, Tim On 11 February 2012 20:33, Fred Hebert wrote: > The best question to ask after this is "What's slow?", "What do you > consider to be fast enough?", "What are your requirements?". You often (but > not always) find out that they do not really know what they want, so they > aim for the fastest overall thinking 'surely, I won't make a mistake > there.' Do you need a 5 nanosecond message sending requirement when you're > going to treat the message for 20 milliseconds anyway? > > In some cases they do need something too fast for Erlang, or think Erlang > is optimized for areas it isn't. Then being honest will be the best > argument to prove you're giving sane recommendations and are not a fanboy. > But before knowing what they really need, it is pretty hard to counter any > argument. > > There's no use fighting someone whose task to accomplish requires too much > work or time in Erlang, but sometimes apprehensions come from not knowing > the technology or the problem enough; that's where we can help. > > On Sat, Feb 11, 2012 at 1:37 PM, Matthew Evans wrote: > >> >> Having said that there is a valid criticism of Erlang in that it is often >> perceived to be too slow. As Joe said, you can't have all the features of >> resilience and reliability without some cost, but when trying to "sell" >> Erlang it's often the first argument against Erlang that I hear. The pointy >> haired managers look at things like the Alioth shootout and see Erlang >> perform poorly for most tests. Now, most Erlang users will correctly say >> "well, Erlang isn't designed for those types of highly serial tasks, use C, >> C++ or Java for that instead, and use Erlang where it makes sense". But >> this now means that a company needs to embrace 2 (perhaps more) languages >> to do a job. This isn't necessarily a bad thing, but can make for pain when >> hiring, training and retaining staff. >> >> My point is that I don't think Erlang will ever be as fast as Java and >> certainly never as fast as C/C++, but I would like to see a greater focus >> on performance, perhaps get it into the top 10 languages for performance. >> I'm happy to see that work is been done WRT to JIT in the Erlang VM, and >> LLVM+HiPE, so maybe future releases will address those concerns. >> >> I've also often wondered if it makes sense to implement some of the >> Kernel and STDLIB modules as BIFs instead of in Erlang. Would that improve >> things? >> >> Matt >> ________________________________ >> > Date: Sat, 11 Feb 2012 13:20:54 +0100 >> > From: poprosturadek@REDACTED >> > To: ulf@REDACTED >> > CC: erlang-questions@REDACTED >> > Subject: Re: [erlang-questions] The future of Erlang and BEAM >> > >> > # the same as above, sorry for inconvenience >> > >> > Hi Ulf, >> > >> > thank you very much for answer. >> > >> > I understand that Erlang has been created in purpose of managing >> > coordination complexity and it does it's job well. >> > But, maybe I'm a bit of devil's advocate, let's say that we (by which I >> > mean mostly OTP team because of their knowledge of Erlang intrinsics >> > but others too) could follow similar direction that Clojure's creator >> > Rick Hickey took. Which means, to build Erlang on JVM, using tools that >> > we already have (like earlier mentioned Java libraries, etc) and >> > optimize it for using with JIT. >> > >> > Of course, it's not obvious that (despite being big effort) it would >> > bring desired performance (although, it seems it would) but some >> > advantages for sure, like ubiquity of JVM, wide gremium of >> > supporters/maintainers, ease of deployment (even single .jar maybe), >> > access to huge variety of other languages and libraries, and even some >> > minor things like proper module managament, etc. >> > >> > As I said before, I'm rather novice in Erlang world (still digging >> > through Erlang and OTP in Action) so all above may be >> > wrong/incomplete/etc. I had this idea some time ago so I finally took >> > decision to write about my concerns here. >> > >> > Greetings, >> > Radek >> > >> > _______________________________________________ erlang-questions >> > mailing list 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 hnakamur@REDACTED Sat Feb 11 21:52:12 2012 From: hnakamur@REDACTED (Hiroaki Nakamura) Date: Sun, 12 Feb 2012 05:52:12 +0900 Subject: [erlang-questions] got wx working with R15B on OS X Lion In-Reply-To: References: Message-ID: Hi, I made a Homebrew Formula for building Erlang R15B with wxMac 2.8.2, ncurses 5.9. Yes, you need to build all of them in 32-bit. https://github.com/hnakamur/homebrew/blob/erlang_pullrequest/Library/Formula/erlang.rb https://github.com/hnakamur/homebrew/blob/master/Library/Formula/wxmac.rb https://github.com/adamv/homebrew-alt/blob/master/duplicates/ncurses.rb 2012/2/9 Wes James : > I just did this on a new machine and realize that > > ./configure > > should be > > ./configure --enable-m32-build > > for wxwidgets to work on Lion. > > -wes > > On Tue, Dec 20, 2011 at 8:45 PM, Wes James wrote: >> How to get wx working in Erlang R15B on OS X Lion. (this is one way, >> maybe there are others??) >> >> 1. install mac ports ( http://www.macports.org/ ) >> 2. run: sudo port -f install wxwidgets >> 3. in .bashrc add: >> >> export LDFLAGS='-L/opt/local/lib' >> export CPPFLAGS='-I/opt/local/include' >> export LD_LIBRARY_PATH=/opt/local/lib >> export LD_INCLUDE_PATH=/opt/local/include >> >> 4. download Erlang R15B from erlang.org or >> >> git clone https://github.com/erlang/otp.git >> >> 5. in the src folder run: >> >> ./otp_build autoconf >> ./configure >> make >> make install >> >> (maybe one of the otp_buld options does these three installing in /usr/local ??) >> >> 6. run erl >> >> 7. run wx:demo(). to check if it runs >> >> I saw that there is a mac port of R14B04 that I was going to try next here: >> >> http://www.macports.org/ports.php?by=category&substr=erlang >> >> But R15B is working now, but with this error when running programs: >> >> >> 2011-12-20 20:26:25.547 beam.smp[28373:e0b] CFURLCreateWithString was >> passed this invalid URL string: '/Syst\ >> em/Library/CoreServices/CommonCocoaPanels.bundle' (a file system path >> instead of an URL string). The URL cre\ >> ated will not work with most file URL functions. >> CFURLCreateWithFileSystemPath or CFURLCreateWithFileSystemP\ >> athRelativeToBase should be used instead. >> >> The wx gui debugger is so much better than the xwindow version on OS X >> Lion. The worst thing was the pin-wheel of death when a window was >> resized from the bottom right corner. The only resize that would work >> was clicking on the green maximize button at the top left of a window. >> >> -wes > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- ?? ?? )Hiroaki Nakamura) hnakamur@REDACTED From hnakamur@REDACTED Sat Feb 11 21:56:40 2012 From: hnakamur@REDACTED (Hiroaki Nakamura) Date: Sun, 12 Feb 2012 05:56:40 +0900 Subject: [erlang-questions] got wx working with R15B on OS X Lion In-Reply-To: References: Message-ID: Oops, I forgot to tell options you need to specify when running the brew command. brew install wxmac brew install ncurses --universal brew install erlang --odbc --wxmac 2012?2?12?5:52 Hiroaki Nakamura : > Hi, > > I made a Homebrew Formula for building Erlang R15B with wxMac 2.8.2, > ncurses 5.9. > Yes, you need to build all of them in 32-bit. > > https://github.com/hnakamur/homebrew/blob/erlang_pullrequest/Library/Formula/erlang.rb > https://github.com/hnakamur/homebrew/blob/master/Library/Formula/wxmac.rb > https://github.com/adamv/homebrew-alt/blob/master/duplicates/ncurses.rb > > 2012/2/9 Wes James : >> I just did this on a new machine and realize that >> >> ./configure >> >> should be >> >> ./configure --enable-m32-build >> >> for wxwidgets to work on Lion. >> >> -wes >> >> On Tue, Dec 20, 2011 at 8:45 PM, Wes James wrote: >>> How to get wx working in Erlang R15B on OS X Lion. (this is one way, >>> maybe there are others??) >>> >>> 1. install mac ports ( http://www.macports.org/ ) >>> 2. run: sudo port -f install wxwidgets >>> 3. in .bashrc add: >>> >>> export LDFLAGS='-L/opt/local/lib' >>> export CPPFLAGS='-I/opt/local/include' >>> export LD_LIBRARY_PATH=/opt/local/lib >>> export LD_INCLUDE_PATH=/opt/local/include >>> >>> 4. download Erlang R15B from erlang.org or >>> >>> git clone https://github.com/erlang/otp.git >>> >>> 5. in the src folder run: >>> >>> ./otp_build autoconf >>> ./configure >>> make >>> make install >>> >>> (maybe one of the otp_buld options does these three installing in /usr/local ??) >>> >>> 6. run erl >>> >>> 7. run wx:demo(). to check if it runs >>> >>> I saw that there is a mac port of R14B04 that I was going to try next here: >>> >>> http://www.macports.org/ports.php?by=category&substr=erlang >>> >>> But R15B is working now, but with this error when running programs: >>> >>> >>> 2011-12-20 20:26:25.547 beam.smp[28373:e0b] CFURLCreateWithString was >>> passed this invalid URL string: '/Syst\ >>> em/Library/CoreServices/CommonCocoaPanels.bundle' (a file system path >>> instead of an URL string). The URL cre\ >>> ated will not work with most file URL functions. >>> CFURLCreateWithFileSystemPath or CFURLCreateWithFileSystemP\ >>> athRelativeToBase should be used instead. >>> >>> The wx gui debugger is so much better than the xwindow version on OS X >>> Lion. The worst thing was the pin-wheel of death when a window was >>> resized from the bottom right corner. The only resize that would work >>> was clicking on the green maximize button at the top left of a window. >>> >>> -wes >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > ?? ?? )Hiroaki Nakamura) hnakamur@REDACTED -- ?? ?? )Hiroaki Nakamura) hnakamur@REDACTED From carlsson.richard@REDACTED Sat Feb 11 22:24:26 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Sat, 11 Feb 2012 22:24:26 +0100 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F367010.5020200@meetinghouse.net> References: <4F36442D.1060202@gmail.com> <4F367010.5020200@meetinghouse.net> Message-ID: <4F36DC8A.2030202@gmail.com> On 2012-02-11 14:41, Miles Fidelman wrote: > 2. Erlang is about 10 years older than Java, Not really; the first prototype implementation of Erlang was made in 1987; it got its first users at Ericsson 1988-89, and was shown to the public in 1990. Java was implemented 1991-1992 (under the name Oak); they tried to market it to makers of embedded systems and such, but no-one gave a damn, so they changed focus to Internet and multimedia and got Java included in Netscape Navigator in 1995. So Erlang is younger by only about 4 years. /Richard From paul.joseph.davis@REDACTED Sat Feb 11 22:29:11 2012 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Sat, 11 Feb 2012 15:29:11 -0600 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: References: <4F36442D.1060202@gmail.com> <4831CAB4-2E26-4415-806E-1F91C21F3131@feuerlabs.com> <4F365D26.4000004@gmail.com> Message-ID: On Sat, Feb 11, 2012 at 2:49 PM, Tim Watson wrote: > I'd really second this. I work with both Erlang and Java (alongside a few > other bits and peices) on a daily basis and slowness isn't something I've > really run into major difficulties with Erlang at all. If you take a look at > that rather well documented case of the chat at Github who implemented an > Erlang git daemon, but then found it to be too slow so abandoned it. A more > experiences Erlang programmer came along and refactored the code for massive > performance improvements. > Here's a link to the articles about refactoring egitd by Andrew Thompson. I'd highly recommend them to anyone that's not read the series. http://andrew.hijacked.us/article/324/optimizing-egitd-introduction > It's true that sometimes you need raw throughput that Erlang can't provide > and need to break out to C/C++ with a port/nif or whatever, but that's not > so often the case. Also I prefer to 'pick the right tool for the job' and > not every system has to be monolithic running on only one VM. > > Cheers, > > Tim > > > On 11 February 2012 20:33, Fred Hebert wrote: >> >> The best question to ask after this is "What's slow?", "What do you >> consider to be fast enough?", "What are your requirements?". You often (but >> not always) find out that they do not really know what they want, so they >> aim for the fastest overall thinking 'surely, I won't make a mistake there.' >> Do you need a 5 nanosecond message sending requirement when you're going to >> treat the message for 20 milliseconds anyway? >> >> In some cases they do need something too fast for Erlang, or think Erlang >> is optimized for areas it isn't. Then being honest will be the best argument >> to prove you're giving sane recommendations and are not a fanboy. But before >> knowing what they really need, it is pretty hard to counter any argument. >> >> There's no use fighting someone whose task to accomplish requires too much >> work or time in Erlang, but sometimes apprehensions come from not knowing >> the technology or the problem enough; that's where we can help. >> >> On Sat, Feb 11, 2012 at 1:37 PM, Matthew Evans >> wrote: >>> >>> >>> Having said that there is a valid criticism of Erlang in that it is often >>> perceived to be too slow. As Joe said, you can't have all the features of >>> resilience and reliability without some cost, but when trying to "sell" >>> Erlang it's often the first argument against Erlang that I hear. The pointy >>> haired managers look at things like the Alioth shootout and see Erlang >>> perform poorly for most tests. Now, most Erlang users will correctly say >>> "well, Erlang isn't designed for those types of highly serial tasks, use C, >>> C++ or Java for that instead, and use Erlang where it makes sense". But this >>> now means that a company needs to embrace 2 (perhaps more) languages to do a >>> job. This isn't?necessarily?a bad thing, but can make for pain when hiring, >>> training and retaining staff. >>> >>> My point is that I don't think Erlang will ever be as fast as Java and >>> certainly never as fast as C/C++, but I would like to see a greater focus on >>> performance, perhaps get it into the top 10 languages for performance. I'm >>> happy to see that work is been done WRT to JIT in the Erlang VM, and >>> LLVM+HiPE, so maybe future releases will address those concerns. >>> >>> I've also often wondered if it makes sense to implement some of the >>> Kernel and STDLIB modules as BIFs instead of in Erlang. Would that improve >>> things? >>> >>> Matt >>> ________________________________ >>> > Date: Sat, 11 Feb 2012 13:20:54 +0100 >>> > From: poprosturadek@REDACTED >>> > To: ulf@REDACTED >>> > CC: erlang-questions@REDACTED >>> > Subject: Re: [erlang-questions] The future of Erlang and BEAM >>> > >>> > # the same as above, sorry for inconvenience >>> > >>> > Hi Ulf, >>> > >>> > thank you very much for answer. >>> > >>> > I understand that Erlang has been created in purpose of managing >>> > coordination complexity and it does it's job well. >>> > But, maybe I'm a bit of devil's advocate, let's say that we (by which I >>> > mean mostly OTP team because of their knowledge of Erlang intrinsics >>> > but others too) could follow similar direction that Clojure's creator >>> > Rick Hickey took. Which means, to build Erlang on JVM, using tools that >>> > we already have (like earlier mentioned Java libraries, etc) and >>> > optimize it for using with JIT. >>> > >>> > Of course, it's not obvious that (despite being big effort) it would >>> > bring desired performance (although, it seems it would) but some >>> > advantages for sure, like ubiquity of JVM, wide gremium of >>> > supporters/maintainers, ease of deployment (even single .jar maybe), >>> > access to huge variety of other languages and libraries, and even some >>> > minor things like proper module managament, etc. >>> > >>> > As I said before, I'm rather novice in Erlang world (still digging >>> > through Erlang and OTP in Action) so all above may be >>> > wrong/incomplete/etc. I had this idea some time ago so I finally took >>> > decision to write about my concerns here. >>> > >>> > Greetings, >>> > Radek >>> > >>> > _______________________________________________ erlang-questions >>> > mailing list erlang-questions@REDACTED >>> > http://erlang.org/mailman/listinfo/erlang-questions >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From carlsson.richard@REDACTED Sat Feb 11 22:32:52 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Sat, 11 Feb 2012 22:32:52 +0100 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F36DC8A.2030202@gmail.com> References: <4F36442D.1060202@gmail.com> <4F367010.5020200@meetinghouse.net> <4F36DC8A.2030202@gmail.com> Message-ID: <4F36DE84.50709@gmail.com> On 2012-02-11 22:24, Richard Carlsson wrote: > younger by only about 4 years. Older, I meant. Sorry. /Richard From jesper.louis.andersen@REDACTED Sat Feb 11 23:06:57 2012 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Sat, 11 Feb 2012 23:06:57 +0100 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F36442D.1060202@gmail.com> References: <4F36442D.1060202@gmail.com> Message-ID: <4F36E681.90807@erlang-solutions.com> On 2/11/12 11:34 AM, Radek wrote: > > So the question arises: is Erlang still the best platform to build > such demanding applications ? Wouldn't it be better if we stick to > one, very mature (J)VM and try to make it even better than trying to > achieve something similar with less resources available (size of OTP > team vs. JVM team, supporters, etc) ? And is it possible at all to > achieve this kind of performance and adoption with BEAM ? > Performance is but one of many aspects of writing a program. Usually performance is possible, but bounded by human time spent. That is, if you have limited time, say 3 days, to implement something then usually the solutions are very different performance wise. One of the distinct advantages of Erlang is how fast you can build up prototypes and make them run. This means you have ample time to sit back and tune your system for better performance. You have more time to change algorithms and tune for faster execution. Another strength of Erlang is that programs can evolve. Adding another process with a certain responsibility or altering the internal implementation of a process is easy: the messages passed forces an API between your components. This yields a system where you can gradually build it up over time. Erlang is a rarely seen triumvirate: fault-tolerance, distribution+message passing, and functional sequential programming. You often see other systems implementing one or two of those, but I have not yet seen all three implemented in another language. This places Erlang in a niche, and I think many people who do take time to learn the details enjoy the ideology of Erlang as a fabric for program construction. -- Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen, DK -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjtruog@REDACTED Sat Feb 11 23:29:20 2012 From: mjtruog@REDACTED (Michael Truog) Date: Sat, 11 Feb 2012 14:29:20 -0800 Subject: [erlang-questions] Trie NIFs In-Reply-To: <4F306844.1060806@gmail.com> References: <4F306844.1060806@gmail.com> Message-ID: <4F36EBC0.5070901@gmail.com> I added a function fold_match/4 which can do what you require: 1> Paths = trie:new(["/usr/bin","/usr/include/X12/Xtrans","/usr/include/X11/Xtrans"]). {47,47, {{{117,117, {{{115,115, {{{114,114,{{{47,47,{{{98,105,{{...},...}},error}}},error}}}, error}}}, error}}}, error}}} 2> trie:fold_match("/usr/include/*/Xtrans", fun(K, _, L) -> [K | L] end, [], Paths). ["/usr/include/X12/Xtrans","/usr/include/X11/Xtrans"] 3> On 02/06/2012 03:54 PM, Michael Truog wrote: > That code doesn't currently contain regex support, but you could iterate on the contents based on a common prefix held within the trie, while checking each string passed to the anonymous function to do this programmatically. To do things this way, you would use: > trie:fold_similar("/usr/include/", Function, Accumulator, Trie) > > Some simple pattern matching (perhaps using "*") could probably be grafted on in a similar way, where you would be matching string suffixes after the "*" character's last occurrence. > > On 02/06/2012 12:45 PM, Zabrane Mickael wrote: >> Try this: >> https://github.com/okeuday/trie >> >> See bench: >> http://okeuday.livejournal.com/16941.html >> >> Regards, >> Zabrane >> >> >> On Feb 6, 2012, at 9:37 PM, Jon Watte wrote: >> >>> Why does it have to be NIF? On the surface, that looks like a data >>> structure that might actually work reasonably well as an Erlang native >>> library. (Modification generates log-N garbage) >>> >>> Sincerely, >>> >>> jw >>> >>> >>> -- >>> Americans might object: there is no way we would sacrifice our living >>> standards for the benefit of people in the rest of the world. >>> Nevertheless, whether we get there willingly or not, we shall soon >>> have lower consumption rates, because our present rates are >>> unsustainable. >>> >>> >>> >>> On Mon, Feb 6, 2012 at 8:43 AM, ori brost > wrote: >>>> I'm looking for a trie NIF library that can support strings as trie >>>> tokens, and basic pattern matching with a '.' like wildcard (i.e. If / >>>> is the trie separator and the tree contains 3 entries: /usr/bin, >>>> /usr/include/X12/XTrans, /usr/include/X11/Xtrans, then I can do >>>> >>>> trie:get_all(["usr", "include", '.', "XTrans"]) >>>> >>>> and it will return >>>> >>>> [["usr","include","X11","Xtrans"], >>>> ["usr","include","X12","Xtrans"]] >>>> >>>> It would also be nice to have a >>>> >>>> trie:get_single(["usr","include", '.', "XTrans"]) >>>> >>>> that returns only one of the matching entries >>>> >>>> Does anyone know of such a NIF library? Or something similar enough >>>> that I can modify it for these needs? >>>> >>>> Regards, OriB. >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> 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 poprosturadek@REDACTED Sat Feb 11 23:36:10 2012 From: poprosturadek@REDACTED (Radek) Date: Sat, 11 Feb 2012 23:36:10 +0100 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F36E681.90807@erlang-solutions.com> References: <4F36442D.1060202@gmail.com> <4F36E681.90807@erlang-solutions.com> Message-ID: <4F36ED5A.9070707@gmail.com> I'm still a novice, but I can clearly say that Erlang is a nice language to play with; There is short period of time needed to convert the working prototype to full solution, since it's sometimes just the case of clearing/adding some API (because you already use gen_server, gen_fsm, ...) etc. Moreover, I think that many times it's just simpler to use Erlang compared to Java/C++/... because you don't have such difference from model (when it's said "sending message from object A to object B) to implementation. In Erlang you actually send a message and don't have to bother to properly implement Observer pattern and all that stuff. So it's a huge advantage of both Erlang style on concurrency & functional programming. I was just wondering if making it on JVM wouln't be a good idea, but I realized I didn't put some thing under consideration (like safety and truly fault-tolerance). And, it seems it's easier to make Erlang faster by researching for better algorithm/solution or sacrificing some performance for overall better (in terms of speed/reliability ratio) quality of product than trying to make things to work the same way on platform(-s) that wasn't designed for it in the first place. Greetings, Radek W dniu 2012-02-11 23:06, Jesper Louis Andersen pisze: > On 2/11/12 11:34 AM, Radek wrote: >> >> So the question arises: is Erlang still the best platform to build >> such demanding applications ? Wouldn't it be better if we stick to >> one, very mature (J)VM and try to make it even better than trying to >> achieve something similar with less resources available (size of OTP >> team vs. JVM team, supporters, etc) ? And is it possible at all to >> achieve this kind of performance and adoption with BEAM ? >> > Performance is but one of many aspects of writing a program. Usually > performance is possible, but bounded by human time spent. That is, if > you have limited time, say 3 days, to implement something then usually > the solutions are very different performance wise. One of the distinct > advantages of Erlang is how fast you can build up prototypes and make > them run. This means you have ample time to sit back and tune your > system for better performance. You have more time to change algorithms > and tune for faster execution. > > Another strength of Erlang is that programs can evolve. Adding another > process with a certain responsibility or altering the internal > implementation of a process is easy: the messages passed forces an API > between your components. This yields a system where you can gradually > build it up over time. > > Erlang is a rarely seen triumvirate: fault-tolerance, > distribution+message passing, and functional sequential programming. > You often see other systems implementing one or two of those, but I > have not yet seen all three implemented in another language. This > places Erlang in a niche, and I think many people who do take time to > learn the details enjoy the ideology of Erlang as a fabric for program > construction. > > -- > Jesper Louis Andersen > Erlang Solutions Ltd., Copenhagen, DK > > > _______________________________________________ > 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 Sat Feb 11 23:53:06 2012 From: mfidelman@REDACTED (Miles Fidelman) Date: Sat, 11 Feb 2012 17:53:06 -0500 Subject: [erlang-questions] very large networks of erlang nodes? Message-ID: <4F36F152.9070002@meetinghouse.net> Does anybody have experience running an Erlang environment consisting of 100s, 1000s, or more nodes, spread across a network? I'm thinking about applications like SETI@REDACTED and folding@REDACTED, that distribute processing tasks across huge numbers of PCs, taking advantage of shared cycles to run long-running, data intensive jobs that can be parallelized -- and more generally about the BOINC platform (http://boinc.berkeley.edu). Seems to me that Erlang would be a great platform for such things. Sort of wondering if anybody has played with anything along such lines. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mjtruog@REDACTED Sun Feb 12 00:10:02 2012 From: mjtruog@REDACTED (Michael Truog) Date: Sat, 11 Feb 2012 15:10:02 -0800 Subject: [erlang-questions] very large networks of erlang nodes? In-Reply-To: <4F36F152.9070002@meetinghouse.net> References: <4F36F152.9070002@meetinghouse.net> Message-ID: <4F36F54A.9080903@gmail.com> On 02/11/2012 02:53 PM, Miles Fidelman wrote: > Does anybody have experience running an Erlang environment consisting of 100s, 1000s, or more nodes, spread across a network? > > I'm thinking about applications like SETI@REDACTED and folding@REDACTED, that distribute processing tasks across huge numbers of PCs, taking advantage of shared cycles to run long-running, data intensive jobs that can be parallelized -- and more generally about the BOINC platform (http://boinc.berkeley.edu). > > Seems to me that Erlang would be a great platform for such things. Sort of wondering if anybody has played with anything along such lines. > Conceptually, Erlang would be a wonderful fit. However, distributed Erlang creates a fully connected network topology which is a limiting factor, that limits a distributed Erlang cluster to 50 - 100 nodes roughly. I do not have proof from trying this on my own, just knowledge of the attempts of others. The net tick time within distributed Erlang expects a response every minute with some permissible variation. You can try changing the net tick time, however, I have seen breakage when using links/monitors between distributed Erlang nodes with a net tick time set longer than 60 seconds (so I assume the net tick time was hard-coded internally, in some places). You can always try doing something strange with hidden nodes trying to limit the scope of a fully-connected network, but it seems like more trouble than it is worth. I have a project called CloudI (http://cloudi.org) that provides a SOA framework that allows you to connect CloudI distributed Erlang clusters together with ZeroMQ bridges, to surpass the distributed Erlang fully connected network topology limitations. When doing things that way, you would create CloudI services that communicated through message passing using the CloudI API, and the internal routing takes care of service communication (through ZeroMQ or distributed Erlang messaging). Its an open source project (BSD license), so you host it yourself "for greater good". - Michael From michael.eugene.turner@REDACTED Sun Feb 12 05:59:38 2012 From: michael.eugene.turner@REDACTED (Michael Turner) Date: Sun, 12 Feb 2012 13:59:38 +0900 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F36DC8A.2030202@gmail.com> References: <4F36442D.1060202@gmail.com> <4F367010.5020200@meetinghouse.net> <4F36DC8A.2030202@gmail.com> Message-ID: What probably matters more than age-measured-from-inception is the sponsoring corporation's agenda. Java was open-sourced by Sun in part because open-sourcing it furthered the goal of getting Java adopted as a de facto industry standard; Erlang was open-sourced (years after Java was) to escape getting strangled in its crib by Ericsson. By this measure, Erlang might be considerably "younger" than Java, and moreover suffering from a kind of "arrested development" -- because, as useful as Erlang might be for Ericsson, it's not really considered a *strategic* technology, whose spread furthers Ericsson's core interests. -michael turner On Sun, Feb 12, 2012 at 6:24 AM, Richard Carlsson wrote: > On 2012-02-11 14:41, Miles Fidelman wrote: >> >> 2. Erlang is about 10 years older than Java, > > > Not really; the first prototype implementation of Erlang was made in 1987; > it got its first users at Ericsson 1988-89, and was shown to the public in > 1990. Java was implemented 1991-1992 (under the name Oak); they tried to > market it to makers of embedded systems and such, but no-one gave a damn, so > they changed focus to Internet and multimedia and got Java included in > Netscape Navigator in 1995. So Erlang is younger by only about 4 years. > > ? /Richard > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From mononcqc@REDACTED Sun Feb 12 06:19:11 2012 From: mononcqc@REDACTED (Fred Hebert) Date: Sun, 12 Feb 2012 00:19:11 -0500 Subject: [erlang-questions] Common Test and base applications Message-ID: I've recently discovered that Common Test appears to not be starting basic applications such as kernel and stdlib, but it still starts things like application controllers and whatnot. This gives me a few problems because it breaks a few behaviours such as application:which_applications(), being able to start a few applications (they depend on stdlib and kernel. Sstdlib depends on kernel, and manually starting kernel fails because a bunch of processes already have that name). It will also play negatively with things like manually calling application:set_env/3 before starting an application to configure it (after loading it) as just starting it will overwrite all values, etc. This causes me a few problems because it forces me to test everything below the application level, and I can't automate testing of things like distributed applications and their failover/takeover mechanisms. Is there any workaround for these problems? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Sun Feb 12 06:22:57 2012 From: mononcqc@REDACTED (Fred Hebert) Date: Sun, 12 Feb 2012 00:22:57 -0500 Subject: [erlang-questions] Common Test and base applications In-Reply-To: References: Message-ID: I should specify this problem is something I noticed when using distributed tests based on ct_slave; I would suspect that local tests being run from a shell started manually do not suffer from this. On Sun, Feb 12, 2012 at 12:19 AM, Fred Hebert wrote: > I've recently discovered that Common Test appears to not be starting basic > applications such as kernel and stdlib, but it still starts things like > application controllers and whatnot. > > This gives me a few problems because it breaks a few behaviours such as > application:which_applications(), being able to start a few applications > (they depend on stdlib and kernel. Sstdlib depends on kernel, and manually > starting kernel fails because a bunch of processes already have that > name). > > It will also play negatively with things like manually calling > application:set_env/3 before starting an application to configure it (after > loading it) as just starting it will overwrite all values, etc. > > This causes me a few problems because it forces me to test everything > below the application level, and I can't automate testing of things like > distributed applications and their failover/takeover mechanisms. > > Is there any workaround for these problems? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Sun Feb 12 11:45:35 2012 From: spawn.think@REDACTED (Ahmed Omar) Date: Sun, 12 Feb 2012 11:45:35 +0100 Subject: [erlang-questions] Common Test and base applications In-Reply-To: References: Message-ID: Hi Fred, 1- How do you start the ct_slave nodes? (ct@REDACTED)1> ct_slave:start(omarmb, testnode,[]). {ok,testnode@REDACTED} (ct@REDACTED)2> rpc:call('testnode@REDACTED', application, which_applications,[]). [{stdlib,"ERTS CXC 138 10","1.17.5"}, {kernel,"ERTS CXC 138 10","2.14.5"}] 2- You can use erl_flags to specify more options to your slave node, e.g: (ct@REDACTED)3> ct_slave:start(omarmb, testnode1,[{erl_flags, "-s mnesia"}]). {ok,testnode1@REDACTED} (ct@REDACTED)4> rpc:call('testnode1@REDACTED', application, which_applications,[]). [{mnesia,"MNESIA CXC 138 12","4.5"}, {stdlib,"ERTS CXC 138 10","1.17.5"}, {kernel,"ERTS CXC 138 10","2.14.5"}] On Sun, Feb 12, 2012 at 6:22 AM, Fred Hebert wrote: > I should specify this problem is something I noticed when using > distributed tests based on ct_slave; I would suspect that local tests being > run from a shell started manually do not suffer from this. > > > On Sun, Feb 12, 2012 at 12:19 AM, Fred Hebert wrote: > >> I've recently discovered that Common Test appears to not be starting >> basic applications such as kernel and stdlib, but it still starts things >> like application controllers and whatnot. >> >> This gives me a few problems because it breaks a few behaviours such as >> application:which_applications(), being able to start a few applications >> (they depend on stdlib and kernel. Sstdlib depends on kernel, and manually >> starting kernel fails because a bunch of processes already have that >> name). >> >> It will also play negatively with things like manually calling >> application:set_env/3 before starting an application to configure it (after >> loading it) as just starting it will overwrite all values, etc. >> >> This causes me a few problems because it forces me to test everything >> below the application level, and I can't automate testing of things like >> distributed applications and their failover/takeover mechanisms. >> >> Is there any workaround for these problems? >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Sun Feb 12 16:59:56 2012 From: mononcqc@REDACTED (Fred Hebert) Date: Sun, 12 Feb 2012 10:59:56 -0500 Subject: [erlang-questions] Common Test and base applications In-Reply-To: References: Message-ID: I start them with distributed test specifications: {node, master, 'ct@REDACTED'}. {node, a, 'a@REDACTED'}. {node, b, 'b@REDACTED'}. {init, a, [{node_start, [{monitor_master, true}, {boot_timeout, 10}, {startup_functions, [{application,start,[crypto]}, {application,start,[m8ball]}]}, {erl_flags, "-pa /Users/ferd/code/self/learn-you-some-erlang/m8ball/ebin/" "-config dist_m8ball_SUITE_data/main.config"}]}]}. {init, b, [{node_start, [{monitor_master, true}, {boot_timeout, 10}, {startup_functions, [{application,start,[crypto]}, {application,start,[m8ball]}]}, {erl_flags, "-pa /Users/ferd/code/self/learn-you-some-erlang/m8ball/ebin/ " "-config dist_m8ball_SUITE_data/backup.config"}]}]}. And I start it with: $ erl -name ct -pa ../ebin/ Erlang R15B (erts-5.9) [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.9 (abort with ^G) (ct@REDACTED)1> ct_master:run("m8ball_dist.spec"). And whenever I use ct:pal("~p",[application:which_applications()]) in the suite, I get [] as a result. Further inspection shows that the distributed applications I have are read by the controllers, but stdlib and kernel are not started. On Sun, Feb 12, 2012 at 5:45 AM, Ahmed Omar wrote: > Hi Fred, > 1- How do you start the ct_slave nodes? > (ct@REDACTED)1> ct_slave:start(omarmb, testnode,[]). > {ok,testnode@REDACTED} > (ct@REDACTED)2> rpc:call('testnode@REDACTED', application, > which_applications,[]). > [{stdlib,"ERTS CXC 138 10","1.17.5"}, > {kernel,"ERTS CXC 138 10","2.14.5"}] > > 2- You can use erl_flags to specify more options to your slave node, e.g: > (ct@REDACTED)3> ct_slave:start(omarmb, testnode1,[{erl_flags, "-s > mnesia"}]). > {ok,testnode1@REDACTED} > (ct@REDACTED)4> rpc:call('testnode1@REDACTED', application, > which_applications,[]). > [{mnesia,"MNESIA CXC 138 12","4.5"}, > {stdlib,"ERTS CXC 138 10","1.17.5"}, > {kernel,"ERTS CXC 138 10","2.14.5"}] > > On Sun, Feb 12, 2012 at 6:22 AM, Fred Hebert wrote: > >> I should specify this problem is something I noticed when using >> distributed tests based on ct_slave; I would suspect that local tests being >> run from a shell started manually do not suffer from this. >> >> >> On Sun, Feb 12, 2012 at 12:19 AM, Fred Hebert wrote: >> >>> I've recently discovered that Common Test appears to not be starting >>> basic applications such as kernel and stdlib, but it still starts things >>> like application controllers and whatnot. >>> >>> This gives me a few problems because it breaks a few behaviours such as >>> application:which_applications(), being able to start a few applications >>> (they depend on stdlib and kernel. Sstdlib depends on kernel, and manually >>> starting kernel fails because a bunch of processes already have that >>> name). >>> >>> It will also play negatively with things like manually calling >>> application:set_env/3 before starting an application to configure it (after >>> loading it) as just starting it will overwrite all values, etc. >>> >>> This causes me a few problems because it forces me to test everything >>> below the application level, and I can't automate testing of things like >>> distributed applications and their failover/takeover mechanisms. >>> >>> Is there any workaround for these problems? >>> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From w.a.de.jong@REDACTED Sun Feb 12 18:56:18 2012 From: w.a.de.jong@REDACTED (Willem de Jong) Date: Sun, 12 Feb 2012 18:56:18 +0100 Subject: [erlang-questions] Post and query string parameter validation library? In-Reply-To: References: Message-ID: Hi, I put my version on github: https://github.com/willemdj/parse_qs It translates a query string to a record, based on a specification that can be generated from the record declaration (+ some optional additional tags in comments, EDoc-style). It probably needs some additional work (for sure the REAME file does, it looks awful - my first attempt to use the markdown format). Regards, Willem On Fri, Feb 10, 2012 at 11:59 PM, Mark Allen wrote: > On 2/10/12 10:43 AM, "Mark Allen" wrote: > > >I am about half-way done with my validation module. I'll put it up on > >github when I'm done too. > > https://gist.github.com/1793796 > > > I'd love comments, feedback or edits. This isn't 100% finished, either, > but > it's close enough to show what I'm aiming for. > > Thank you. > > Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Sun Feb 12 20:26:18 2012 From: mfidelman@REDACTED (Miles Fidelman) Date: Sun, 12 Feb 2012 14:26:18 -0500 Subject: [erlang-questions] very large networks of erlang nodes? In-Reply-To: References: <4F36F152.9070002@meetinghouse.net> Message-ID: <4F38125A.6030806@meetinghouse.net> Steve Strong wrote: > The largest the we have run at id3as so far is 768 erlang nodes, distributed across 5 data centers. The nodes were structured in a hierarchy and used the hidden flag to ensure that the network did not become fully connected. > > cool! can you say a little more about what you were doing with them? -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From ok@REDACTED Sun Feb 12 23:58:37 2012 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 13 Feb 2012 11:58:37 +1300 Subject: [erlang-questions] Erlang on ARM Message-ID: <72786C06-997C-4FFD-800E-5BD2B3E92220@cs.otago.ac.nz> One of my colleagues has made his information retrieval search engine run on an Android phone, and we're looking at getting some BeagleBones to play with. I was wondering about running Erlang on them. I understand that HiPE on ARM is no problem these days. Are there any problems I should know about? From kostis@REDACTED Mon Feb 13 00:19:39 2012 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 13 Feb 2012 01:19:39 +0200 Subject: [erlang-questions] Erlang on ARM In-Reply-To: <72786C06-997C-4FFD-800E-5BD2B3E92220@cs.otago.ac.nz> References: <72786C06-997C-4FFD-800E-5BD2B3E92220@cs.otago.ac.nz> Message-ID: <4F38490B.6040702@cs.ntua.gr> On 02/13/12 00:58, Richard O'Keefe wrote: > One of my colleagues has made his information retrieval search engine run on > an Android phone, and we're looking at getting some BeagleBones to play with. > I was wondering about running Erlang on them. I understand that HiPE on ARM > is no problem these days. Are there any problems I should know about? I am not aware of any problems of HiPE on the ARM, but then again, we do not have any ARM handy as a development machine and we do not actively test this particular backend. If you do run into any problem let us know. Even more importantly, if all goes well, a follow up mail here describing your experiences with it will be nice to have. Kostis From ingo.jaeckel@REDACTED Mon Feb 13 00:42:16 2012 From: ingo.jaeckel@REDACTED (Ingo) Date: Sun, 12 Feb 2012 15:42:16 -0800 (PST) Subject: [erlang-questions] tidier is down In-Reply-To: <35F49CCD-F958-4677-B53F-F9AAA0A8BEA7@i-tool.eu> References: <35F49CCD-F958-4677-B53F-F9AAA0A8BEA7@i-tool.eu> Message-ID: <6629728d-3284-4a39-bc8f-02f4fb20e575@bs8g2000vbb.googlegroups.com> Hi, it seems like the tidier website is still down (for almost a month now).. Can someone provide another server to run tidier or a standalone version of the tool? Thanks, Ingo On Jan 15, 6:55?am, Andrzej Sliwa wrote: > Hi Guys, > > it looks like tidier service is down: > > http://tidier.softlab.ntua.gr/mediawiki/ > Database error > A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: > (SQL query hidden) > from within function "MediaWikiBagOStuff::_doinsert". MySQL returned error "1114: The table 'objectcache' is full (localhost)". > > http://tidier.softlab.ntua.gr:20000/tidier/getstarted > ERROR erlang ?code ?crashed: > ?File: appmod:0 > Reason: {undef, > ? ? ? ? ? ? [{erlyweb,out, > ? ? ? ? ? ? ? ? ?[{arg,#Port<0.486>, > ? ? ? ? ? ? ? ? ? ? ? {{89,228,137,251},64315}, > ? ? ? ? ? ? ? ? ? ? ? {headers,"keep-alive", > ? ? ? ? ? ? ? ? ? ? ? ? ? "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", > ? ? ? ? ? ? ? ? ? ? ? ? ? "tidier.softlab.ntua.gr:20000",undefined,undefined, > ? ? ? ? ? ? ? ? ? ? ? ? ? undefined,undefined,undefined,undefined,undefined, > ? ? ? ? ? ? ? ? ? ? ? ? ? "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/534.52.7 (KHTML, like Gecko) Version/5.1.2 Safari/534.52.7", > ? ? ? ? ? ? ? ? ? ? ? ? ? undefined,[],undefined,undefined,undefined, > ? ? ? ? ? ? ? ? ? ? ? ? ? undefined,undefined,undefined,undefined, > ? ? ? ? ? ? ? ? ? ? ? ? ? [{http_header,10,'Accept-Encoding',undefined, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"gzip, deflate"}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ?{http_header,11,'Accept-Language',undefined, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"en-us"}]}, > ? ? ? ? ? ? ? ? ? ? ? {http_request,'GET', > ? ? ? ? ? ? ? ? ? ? ? ? ? {abs_path,"/tidier/getstarted"}, > ? ? ? ? ? ? ? ? ? ? ? ? ? {1,1}}, > ? ? ? ? ? ? ? ? ? ? ? undefined,"/tidier/getstarted",undefined,"getstarted", > ? ? ? ? ? ? ? ? ? ? ? "/home/ethan/apps/tidier/www","/", > ? ? ? ? ? ? ? ? ? ? ? "/home/ethan/apps/tidier/www/tidier/getstarted", > ? ? ? ? ? ? ? ? ? ? ? undefined,undefined,<0.240.0>, > ? ? ? ? ? ? ? ? ? ? ? [{"appname","tidier"}], > ? ? ? ? ? ? ? ? ? ? ? "/","/","/getstarted"}]}, > ? ? ? ? ? ? ?{yaws_server,deliver_dyn_part,8}, > ? ? ? ? ? ? ?{yaws_server,aloop,3}, > ? ? ? ? ? ? ?{yaws_server,acceptor0,2}, > ? ? ? ? ? ? ?{proc_lib,init_p,5}]} > Req: {http_request,'GET',{abs_path,"/tidier/getstarted"},{1,1}} > Stack: [{erlyweb,out, > ? ? ? ? ? ? [{arg,#Port<0.486>, > ? ? ? ? ? ? ? ? ?{{89,228,137,251},64315}, > ? ? ? ? ? ? ? ? ?{headers,"keep-alive", > ? ? ? ? ? ? ? ? ? ? ?"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", > ? ? ? ? ? ? ? ? ? ? ?"tidier.softlab.ntua.gr:20000",undefined,undefined, > ? ? ? ? ? ? ? ? ? ? ?undefined,undefined,undefined,undefined,undefined, > ? ? ? ? ? ? ? ? ? ? ?"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/534.52.7 (KHTML, like Gecko) Version/5.1.2 Safari/534.52.7", > ? ? ? ? ? ? ? ? ? ? ?undefined,[],undefined,undefined,undefined,undefined, > ? ? ? ? ? ? ? ? ? ? ?undefined,undefined,undefined, > ? ? ? ? ? ? ? ? ? ? ?[{http_header,10,'Accept-Encoding',undefined, > ? ? ? ? ? ? ? ? ? ? ? ? ? "gzip, deflate"}, > ? ? ? ? ? ? ? ? ? ? ? {http_header,11,'Accept-Language',undefined,"en-us"}]}, > ? ? ? ? ? ? ? ? ?{http_request,'GET',{abs_path,"/tidier/getstarted"},{1,1}}, > ? ? ? ? ? ? ? ? ?undefined,"/tidier/getstarted",undefined,"getstarted", > ? ? ? ? ? ? ? ? ?"/home/ethan/apps/tidier/www","/", > ? ? ? ? ? ? ? ? ?"/home/ethan/apps/tidier/www/tidier/getstarted",undefined, > ? ? ? ? ? ? ? ? ?undefined,<0.240.0>, > ? ? ? ? ? ? ? ? ?[{"appname","tidier"}], > ? ? ? ? ? ? ? ? ?"/","/","/getstarted"}]}, > ? ? ? ? {yaws_server,deliver_dyn_part,8}, > ? ? ? ? {yaws_server,aloop,3}, > ? ? ? ? {yaws_server,acceptor0,2}, > ? ? ? ? {proc_lib,init_p,5}] > > Maybe it is good time to make this tool open, or free standalone version for open source projects? > > best regards, > Andrzej > > _______________________________________________ > erlang-questions mailing list > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions From taavi@REDACTED Mon Feb 13 01:36:25 2012 From: taavi@REDACTED (Taavi Talvik) Date: Mon, 13 Feb 2012 02:36:25 +0200 Subject: [erlang-questions] Erlang on ARM In-Reply-To: <72786C06-997C-4FFD-800E-5BD2B3E92220@cs.otago.ac.nz> References: <72786C06-997C-4FFD-800E-5BD2B3E92220@cs.otago.ac.nz> Message-ID: On Feb 13, 2012, at 12:58 AM, Richard O'Keefe wrote: > One of my colleagues has made his information retrieval search engine run on > an Android phone, and we're looking at getting some BeagleBones to play with. > I was wondering about running Erlang on them. I understand that HiPE on ARM > is no problem these days. Are there any problems I should know about? Android has very aggressive power saving model, which definitely hurts. For Beagleboard/Pandaboard/Ionics plug (http://www.ionicsplug.com/stratus.html) under conventional linux erlang works very well. Not much experience with HiPE though, as it is more convenient to use generic beam files until performance is not issue. best regards, taavi From dbarker@REDACTED Mon Feb 13 04:17:04 2012 From: dbarker@REDACTED (Deryk Barker) Date: Sun, 12 Feb 2012 19:17:04 -0800 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F36ED5A.9070707@gmail.com> References: <4F36442D.1060202@gmail.com> <4F36E681.90807@erlang-solutions.com> <4F36ED5A.9070707@gmail.com> Message-ID: <4F3880B0.9050706@camosun.bc.ca> As a mere amateur in the erlang world - I've used it a few times in my network programming course, probably bending the rules slightly to do so... But I've been programming for a while (first program FORTRAN on an IBM 7090 while still at school in 1968, second program in BASIC on a PDP-8 while taking a course from Maurice Wilkes at Cambridge in 1970) and there's one aspect in all of this thread that has either not been mentioned or at least not made much of: the fact that erlang is a functional language. For years FP got a bad press, from the early days when the accusation was inefficiency ("LISP programmers know the value of everything and the cost of nothing") to the more recent criticisms that FP is very nice for academics but won't work in the *real* world. Erlang clearly blows these ideas out of the water and combines all of the attributes everybody else has mentioned with those of developing in a functional language, with all of its associated benefits, especially of correctness. Besides, I think java is a terribly *ugly* language...:-) deryk -- Deryk Barker, Computer Science Dept. Camosun College, Victoria, BC, Canada From ok@REDACTED Mon Feb 13 06:55:47 2012 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 13 Feb 2012 18:55:47 +1300 Subject: [erlang-questions] Erlang on ARM In-Reply-To: References: <72786C06-997C-4FFD-800E-5BD2B3E92220@cs.otago.ac.nz> Message-ID: <5BC624B5-3013-4C46-94C2-8983AA883BD4@cs.otago.ac.nz> I should also mention that my colleague doing IR on an Android phone has fallen foul of Linux memory management: by default the OS will overcommit virtual memory. So his program ask for memory, is told it has been given it, and then some random service gets shut down because there isn't that much. If I recall correctly, it was sshd that got killed the first time. While it was an Android _phone_, I think it was some other Linux he'd installed on it; I remember he and a student had the dickens of a job getting gdb to work on it. Overcommitment must be a problem for other people running Erlang on Linux. What, other that a few incantations as root, do you/can you do about it? From vinodhg@REDACTED Mon Feb 13 07:15:52 2012 From: vinodhg@REDACTED (Vinod H G) Date: Mon, 13 Feb 2012 11:45:52 +0530 Subject: [erlang-questions] Starting erl with unicode hostname In-Reply-To: References: Message-ID: I agree hostname is an atom, but os hostname may have unicode right. Ex: 'host_with_?_or_?' erl -name 'node@REDACTED?_or_?' or erl -sname node These will give invalid node name error. On Fri, Feb 10, 2012 at 2:20 PM, Michael Uvarov wrote: > > Hostname is an atom. -- Thanks & Regards, Vinod H. G. From dmkolesnikov@REDACTED Mon Feb 13 08:35:39 2012 From: dmkolesnikov@REDACTED (dmitry kolesnikov) Date: Mon, 13 Feb 2012 09:35:39 +0200 Subject: [erlang-questions] Starting erl with unicode hostname In-Reply-To: References: Message-ID: <-2242150019508365735@unknownmsgid> Hello, Have you tried IDNA encoding instead of Unicode? Best Regards, Dmitry >-|-|-*> On 13.2.2012, at 8.16, Vinod H G wrote: > I agree hostname is an atom, but os hostname may have unicode right. > > Ex: > > 'host_with_?_or_?' > > erl -name 'node@REDACTED?_or_?' > or > erl -sname node > > These will give invalid node name error. > > > On Fri, Feb 10, 2012 at 2:20 PM, Michael Uvarov wrote: >> >> Hostname is an atom. > > > > > -- > > Thanks & Regards, > Vinod H. G. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bgustavsson@REDACTED Mon Feb 13 09:00:37 2012 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 13 Feb 2012 09:00:37 +0100 Subject: [erlang-questions] on_load attribute + inline compile flag In-Reply-To: <4F36B6AC.2080108@softlab.ntua.gr> References: <4F36B6AC.2080108@softlab.ntua.gr> Message-ID: On 2/11/12, Yiannis Tsiouris wrote: > Is bump/0 optimized-out because it is not exported (due to the > "+inline")? Yes. > Is this expected behaviour? No, it is a bug. Thanks for the bug report. /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From ingela@REDACTED Mon Feb 13 11:03:39 2012 From: ingela@REDACTED (Ingela Anderton Andin) Date: Mon, 13 Feb 2012 11:03:39 +0100 Subject: [erlang-questions] Server Name Indication support in Erlang SSL In-Reply-To: References: Message-ID: <4F38DFFB.5020408@erix.ericsson.se> Hi! Kaiduan Xie wrote: > Ingela, > > Does Erlang new SSL support Server Name Indication extension? > > http://en.wikipedia.org/wiki/Server_Name_Indication > https://alice.sni.velox.ch/ > > Thanks, > > /Kaiduan The answer to your question is no not yet. It should be fairly easy to add but as always it will be question of time and priority, and if you want it really soon there is always the option of user contribution. Regards Ingela Erlang/OTP team Ericsson AB From spawn.think@REDACTED Mon Feb 13 11:44:17 2012 From: spawn.think@REDACTED (Ahmed Omar) Date: Mon, 13 Feb 2012 11:44:17 +0100 Subject: [erlang-questions] Common Test and base applications In-Reply-To: References: Message-ID: I tried to reproduce it using same steps, but i get this when i use ct:pal("~p",[application:which_applications()]) i get *** User 2012-02-13 11:39:24.901 *** [{crypto,"CRYPTO version 2","2.0.4"}, {stdlib,"ERTS CXC 138 10","1.17.5"}, {kernel,"ERTS CXC 138 10","2.14.5"}] maybe i'm doing something different.. i'm using Erlang R14B04 (erts-5.8.5) On Sun, Feb 12, 2012 at 4:59 PM, Fred Hebert wrote: > I start them with distributed test specifications: > > {node, master, 'ct@REDACTED'}. > {node, a, 'a@REDACTED'}. > {node, b, 'b@REDACTED'}. > > {init, a, [{node_start, [{monitor_master, true}, > {boot_timeout, 10}, > {startup_functions, [{application,start,[crypto]}, > > {application,start,[m8ball]}]}, > {erl_flags, "-pa > /Users/ferd/code/self/learn-you-some-erlang/m8ball/ebin/" > "-config > dist_m8ball_SUITE_data/main.config"}]}]}. > {init, b, [{node_start, [{monitor_master, true}, > {boot_timeout, 10}, > {startup_functions, > [{application,start,[crypto]}, > > {application,start,[m8ball]}]}, > {erl_flags, "-pa > /Users/ferd/code/self/learn-you-some-erlang/m8ball/ebin/ " > "-config > dist_m8ball_SUITE_data/backup.config"}]}]}. > > And I start it with: > > $ erl -name ct -pa ../ebin/ > Erlang R15B (erts-5.9) [source] [64-bit] [smp:4:4] [async-threads:0] > [hipe] [kernel-poll:false] Eshell V5.9 (abort with ^G) > > (ct@REDACTED)1> ct_master:run("m8ball_dist.spec"). > > And whenever I use ct:pal("~p",[application:which_applications()]) in the > suite, I get [] as a result. Further inspection shows that the distributed > applications I have are read by the controllers, but stdlib and kernel are > not started. > > > On Sun, Feb 12, 2012 at 5:45 AM, Ahmed Omar wrote: > >> Hi Fred, >> 1- How do you start the ct_slave nodes? >> (ct@REDACTED)1> ct_slave:start(omarmb, testnode,[]). >> {ok,testnode@REDACTED} >> (ct@REDACTED)2> rpc:call('testnode@REDACTED', application, >> which_applications,[]). >> [{stdlib,"ERTS CXC 138 10","1.17.5"}, >> {kernel,"ERTS CXC 138 10","2.14.5"}] >> >> 2- You can use erl_flags to specify more options to your slave node, e.g: >> (ct@REDACTED)3> ct_slave:start(omarmb, testnode1,[{erl_flags, "-s >> mnesia"}]). >> {ok,testnode1@REDACTED} >> (ct@REDACTED)4> rpc:call('testnode1@REDACTED', application, >> which_applications,[]). >> [{mnesia,"MNESIA CXC 138 12","4.5"}, >> {stdlib,"ERTS CXC 138 10","1.17.5"}, >> {kernel,"ERTS CXC 138 10","2.14.5"}] >> >> On Sun, Feb 12, 2012 at 6:22 AM, Fred Hebert wrote: >> >>> I should specify this problem is something I noticed when using >>> distributed tests based on ct_slave; I would suspect that local tests being >>> run from a shell started manually do not suffer from this. >>> >>> >>> On Sun, Feb 12, 2012 at 12:19 AM, Fred Hebert wrote: >>> >>>> I've recently discovered that Common Test appears to not be starting >>>> basic applications such as kernel and stdlib, but it still starts things >>>> like application controllers and whatnot. >>>> >>>> This gives me a few problems because it breaks a few behaviours such as >>>> application:which_applications(), being able to start a few applications >>>> (they depend on stdlib and kernel. Sstdlib depends on kernel, and manually >>>> starting kernel fails because a bunch of processes already have that >>>> name). >>>> >>>> It will also play negatively with things like manually calling >>>> application:set_env/3 before starting an application to configure it (after >>>> loading it) as just starting it will overwrite all values, etc. >>>> >>>> This causes me a few problems because it forces me to test everything >>>> below the application level, and I can't automate testing of things like >>>> distributed applications and their failover/takeover mechanisms. >>>> >>>> Is there any workaround for these problems? >>>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Mon Feb 13 11:52:18 2012 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Mon, 13 Feb 2012 11:52:18 +0100 Subject: [erlang-questions] [ANN] sheriff 0.2: parse transform for type-based data validation Message-ID: <4F38EB62.6060908@ninenines.eu> Hello! We just released the first beta version of the sheriff parse transform. It allows you to validate data against types defined through the Erlang type system. Sheriff allows you to write this: -type colors() :: blue | red | green | yellow. paint(Color, Object) -> case sheriff:check(Color, colors) of true -> do_paint(Color, Object); false -> {error, badarg} end. In this example, sheriff:check/2 will check that Color is of type colors(), meaning it is one of 'blue', 'red', 'green' or 'yellow'. This allows you to quickly and efficiently write validation code for unsafe external data without having to repeat yourself too much. Sheriff can be found here along with extended usage instructions: https://github.com/extend/sheriff It's still in beta and has not been used in production yet, so feel free to open tickets on github if you find bugs or don't understand something. Finally, I want to thank my students from last summer William Dang and Hamza Mahmood for doing the awesome initial work and research that led to this release. Thanks! -- Lo?c Hoguin Erlang Cowboy Nine Nines From watson.timothy@REDACTED Mon Feb 13 13:04:34 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Mon, 13 Feb 2012 12:04:34 +0000 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F3880B0.9050706@camosun.bc.ca> References: <4F36442D.1060202@gmail.com> <4F36E681.90807@erlang-solutions.com> <4F36ED5A.9070707@gmail.com> <4F3880B0.9050706@camosun.bc.ca> Message-ID: Java is ugly and bloated to boot. The JVM though, is actually a pretty fantastic piece of engineering and if you dig into the guts of it, there's a lot that VM teams across the board can learn, especially around self tuning and diagnostic/instrumentation support. I think the point about Michael made about mind-share is a very good one. Also the Java platform, for all its bloated complexity, is more mature in some respects. What I mean by that is, for developing typical business applications, Java (and god forgive me for saying it, the other big unmentionable corporate platform too) offers a number of things that are very beneficial and currently lacking from Erlang's ecosystem. For example, JDBC offers reliable and high performance connectivity to almost every database on the market. There are standardised APIs for working with things like web servers and this makes a big difference to the productivity of *ordinary programmers* who are the target audience for these kinds of development platforms. Having said that, I'd pick Erlang and fiddle with API inconsistencies and the near suicide inducing pain of ODBC on unix any day over Java. Going back to what the OP was asking: One of the reasons I don't think that we'll see a competitive implementation of Erlang on the JVM any time soon is that the JVM was built, first and foremost, to host an imperative language. Now the appearance of Clojure does prove that you *can* implement a functional language on the JVM, but Erlang is not just a functional langauge/platform, it is also (as Joe has put it) "Concurrency Orientated", which is about the lightweight Process being a fundamental and first class concept. Java does not have micro/green threads and native threads have limitations. The JVM does not, at its core, support the notion of immutability that we have in Erlang, despite good support for copy-on-write semantics in some (limited) circumstances. The scala crowd can build 'actors' and 'message passing' into their libraries, but these concepts are not part of the JVM. Developers of Scala/Clojure code *can* make their variables, types (and so on) immutable, can implement a syntax for passing around chunks of code in order to imitate higher order functions, but these concepts are not (as of today) part of the JVM. The core concepts for the JVM (and the CLR) are Objects with 'mutable state', native (os level) threads and in Java's case, primitive types that are distinct from objects. You can't get away from those underlying concepts in reality, so 'actors' are Objects and 'message passing' is done by sharing (object) state on a heap and so on. One of the problems people *seem* to be trying to get away from by moving to the JVM is that of raw throughput. We might see a shared heap appear in BEAM some time in the future, for certain special cases, and maybe other optimisations for performance will occur. But as Joe and others have pointed out, Erlang was never built with this in mind. And yet I'm not convinced that an Erlang implementation running on the JVM will really offer great performance benefits, because in order to be *truly like* Erlang, that implementation would *have* to recreate the BEAM emulator running on the JVM. Languages like Scala (and maybe Clojure, I don't actually know) compile down to Java byte code, which means that they're really just syntactic sugar with some runtime library support around it. Perhaps the innovator behind Erjang will pipe in and correct me, but my guess is that you couldn't do that with Erlang without loosing so much of what the langauge/platform is all about. Therefore you're now running a complex runtime environment (i.e., the BEAM emulator) inside another complex runtime environment (the JVM), and fun though they are, the implementations of Jython and JRuby demonstrate that there is a great cost (in terms of performance) when you do this. I'm happy to be proved wrong, but for all the good engineering that resides in the JVM, I suspect it's probably not the right platform for a competitive Erlang/OTP implementation. On 13 February 2012 03:17, Deryk Barker wrote: > As a mere amateur in the erlang world - I've used it a few times in my > network programming course, probably bending the rules slightly to do so... > > But I've been programming for a while (first program FORTRAN on an IBM > 7090 while still at school in 1968, second program in BASIC on a PDP-8 > while taking a course from Maurice Wilkes at Cambridge in 1970) and there's > one aspect in all of this thread that has either not been mentioned or at > least not made much of: > > the fact that erlang is a functional language. > > For years FP got a bad press, from the early days when the accusation was > inefficiency ("LISP programmers know the value of everything and the cost > of nothing") to the more recent criticisms that FP is very nice for > academics but won't work in the *real* world. > > Erlang clearly blows these ideas out of the water and combines all of the > attributes everybody else has mentioned with those of developing in a > functional language, with all of its associated benefits, especially of > correctness. > > Besides, I think java is a terribly *ugly* language...:-) > > deryk > -- > > Deryk Barker, Computer Science Dept. > Camosun College, Victoria, BC, Canada > > > > ______________________________**_________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/**listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Mon Feb 13 13:34:05 2012 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 13 Feb 2012 07:34:05 -0500 Subject: [erlang-questions] Common Test and base applications In-Reply-To: References: Message-ID: I tried it with R14B04 also, and it still doesn't work for me. I'll try a few more things to try and discover what it might be. I'm a bit surprised this can even happen in the first place, though. On Mon, Feb 13, 2012 at 5:44 AM, Ahmed Omar wrote: > I tried to reproduce it using same steps, but i get this when i use > ct:pal("~p",[application:which_applications()]) > i get > > *** User 2012-02-13 11:39:24.901 *** > [{crypto,"CRYPTO version 2","2.0.4"}, > {stdlib,"ERTS CXC 138 10","1.17.5"}, > {kernel,"ERTS CXC 138 10","2.14.5"}] > > maybe i'm doing something different.. > > i'm using Erlang R14B04 (erts-5.8.5) > > On Sun, Feb 12, 2012 at 4:59 PM, Fred Hebert wrote: > >> I start them with distributed test specifications: >> >> {node, master, 'ct@REDACTED'}. >> {node, a, 'a@REDACTED'}. >> {node, b, 'b@REDACTED'}. >> >> {init, a, [{node_start, [{monitor_master, true}, >> {boot_timeout, 10}, >> {startup_functions, >> [{application,start,[crypto]}, >> >> {application,start,[m8ball]}]}, >> {erl_flags, "-pa >> /Users/ferd/code/self/learn-you-some-erlang/m8ball/ebin/" >> "-config >> dist_m8ball_SUITE_data/main.config"}]}]}. >> {init, b, [{node_start, [{monitor_master, true}, >> {boot_timeout, 10}, >> {startup_functions, >> [{application,start,[crypto]}, >> >> {application,start,[m8ball]}]}, >> {erl_flags, "-pa >> /Users/ferd/code/self/learn-you-some-erlang/m8ball/ebin/ " >> "-config >> dist_m8ball_SUITE_data/backup.config"}]}]}. >> >> And I start it with: >> >> $ erl -name ct -pa ../ebin/ >> Erlang R15B (erts-5.9) [source] [64-bit] [smp:4:4] [async-threads:0] >> [hipe] [kernel-poll:false] Eshell V5.9 (abort with ^G) >> >> (ct@REDACTED)1> ct_master:run("m8ball_dist.spec"). >> >> And whenever I use ct:pal("~p",[application:which_applications()]) in >> the suite, I get [] as a result. Further inspection shows that the >> distributed applications I have are read by the controllers, but stdlib and >> kernel are not started. >> >> >> On Sun, Feb 12, 2012 at 5:45 AM, Ahmed Omar wrote: >> >>> Hi Fred, >>> 1- How do you start the ct_slave nodes? >>> (ct@REDACTED)1> ct_slave:start(omarmb, testnode,[]). >>> {ok,testnode@REDACTED} >>> (ct@REDACTED)2> rpc:call('testnode@REDACTED', application, >>> which_applications,[]). >>> [{stdlib,"ERTS CXC 138 10","1.17.5"}, >>> {kernel,"ERTS CXC 138 10","2.14.5"}] >>> >>> 2- You can use erl_flags to specify more options to your slave node, >>> e.g: >>> (ct@REDACTED)3> ct_slave:start(omarmb, testnode1,[{erl_flags, "-s >>> mnesia"}]). >>> {ok,testnode1@REDACTED} >>> (ct@REDACTED)4> rpc:call('testnode1@REDACTED', application, >>> which_applications,[]). >>> [{mnesia,"MNESIA CXC 138 12","4.5"}, >>> {stdlib,"ERTS CXC 138 10","1.17.5"}, >>> {kernel,"ERTS CXC 138 10","2.14.5"}] >>> >>> On Sun, Feb 12, 2012 at 6:22 AM, Fred Hebert wrote: >>> >>>> I should specify this problem is something I noticed when using >>>> distributed tests based on ct_slave; I would suspect that local tests being >>>> run from a shell started manually do not suffer from this. >>>> >>>> >>>> On Sun, Feb 12, 2012 at 12:19 AM, Fred Hebert wrote: >>>> >>>>> I've recently discovered that Common Test appears to not be starting >>>>> basic applications such as kernel and stdlib, but it still starts things >>>>> like application controllers and whatnot. >>>>> >>>>> This gives me a few problems because it breaks a few behaviours such >>>>> as application:which_applications(), being able to start a few applications >>>>> (they depend on stdlib and kernel. Sstdlib depends on kernel, and manually >>>>> starting kernel fails because a bunch of processes already have that >>>>> name). >>>>> >>>>> It will also play negatively with things like manually calling >>>>> application:set_env/3 before starting an application to configure it (after >>>>> loading it) as just starting it will overwrite all values, etc. >>>>> >>>>> This causes me a few problems because it forces me to test everything >>>>> below the application level, and I can't automate testing of things like >>>>> distributed applications and their failover/takeover mechanisms. >>>>> >>>>> Is there any workaround for these problems? >>>>> >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvjunk@REDACTED Mon Feb 13 13:35:50 2012 From: hvjunk@REDACTED (Hendrik Visage) Date: Mon, 13 Feb 2012 14:35:50 +0200 Subject: [erlang-questions] GFS/Hadoop implementation using Erlang? Message-ID: Hi there, I'm looking for some Erlang implementations of Hadoop(HDFS)/GoggleFileSystem. any know implementations? Any similar stuff? I'm seeing potential use/needs for something using GFS/Hadoop(HDFS) (especially with a nice map-reduce type implementation on top of it with code/processing following locality of the file's chunks) and no, I have issues with caffeine ;) (And yes, it's a teleco with millions if not billions of records to process etc. ;) Hendrik From gustav.simonsson@REDACTED Mon Feb 13 13:57:15 2012 From: gustav.simonsson@REDACTED (Gustav Simonsson) Date: Mon, 13 Feb 2012 12:57:15 -0000 (GMT) Subject: [erlang-questions] GFS/Hadoop implementation using Erlang? In-Reply-To: Message-ID: <5484fef3-23b1-43fd-9894-5ee63bffbc2d@knuth> Hi! Riak supports LevelDB, which has similarities with BigTable which is built on GFS. http://wiki.basho.com/LevelDB.html Regards, Gustav Simonsson Sent from my PC ----- Original Message ----- From: "Hendrik Visage" To: "erlang-questions" Sent: Monday, February 13, 2012 1:35:50 PM Subject: [erlang-questions] GFS/Hadoop implementation using Erlang? Hi there, I'm looking for some Erlang implementations of Hadoop(HDFS)/GoggleFileSystem. any know implementations? Any similar stuff? I'm seeing potential use/needs for something using GFS/Hadoop(HDFS) (especially with a nice map-reduce type implementation on top of it with code/processing following locality of the file's chunks) and no, I have issues with caffeine ;) (And yes, it's a teleco with millions if not billions of records to process etc. ;) Hendrik _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From edward.yu.wang@REDACTED Mon Feb 13 14:23:29 2012 From: edward.yu.wang@REDACTED (Edward Wang) Date: Mon, 13 Feb 2012 13:23:29 +0000 Subject: [erlang-questions] GFS/Hadoop implementation using Erlang? In-Reply-To: <5484fef3-23b1-43fd-9894-5ee63bffbc2d@knuth> References: <5484fef3-23b1-43fd-9894-5ee63bffbc2d@knuth> Message-ID: The Disco project (http://discoproject.org/) sounds very close to what you're looking for. Edward. On Mon, Feb 13, 2012 at 12:57 PM, Gustav Simonsson wrote: > > Hi! > > Riak supports LevelDB, which has similarities with BigTable which is built on GFS. > > http://wiki.basho.com/LevelDB.html > > Regards, > Gustav Simonsson > > Sent from my PC > > ----- Original Message ----- > From: "Hendrik Visage" > To: "erlang-questions" > Sent: Monday, February 13, 2012 1:35:50 PM > Subject: [erlang-questions] GFS/Hadoop implementation using Erlang? > > Hi there, > > ?I'm looking for some Erlang implementations of > Hadoop(HDFS)/GoggleFileSystem. any know implementations? > Any similar stuff? > > I'm seeing potential use/needs for something using GFS/Hadoop(HDFS) > (especially with a nice map-reduce type implementation on top of it > with code/processing following locality of the file's chunks) and no, > I have issues with caffeine ;) > > (And yes, it's a teleco with millions if not billions of records to > process etc. ;) > > Hendrik > _______________________________________________ > erlang-questions mailing list > 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 toby@REDACTED Mon Feb 13 15:07:29 2012 From: toby@REDACTED (Toby Thain) Date: Mon, 13 Feb 2012 09:07:29 -0500 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F3880B0.9050706@camosun.bc.ca> References: <4F36442D.1060202@gmail.com> <4F36E681.90807@erlang-solutions.com> <4F36ED5A.9070707@gmail.com> <4F3880B0.9050706@camosun.bc.ca> Message-ID: <4F391921.8060601@telegraphics.com.au> On 12/02/12 10:17 PM, Deryk Barker wrote: > As a mere amateur in the erlang world - I've used it a few times in my > network programming course, probably bending the rules slightly to do so... > > But I've been programming for a while (first program FORTRAN on an IBM > 7090 while still at school in 1968, second program in BASIC on a PDP-8 > while taking a course from Maurice Wilkes at Cambridge in 1970) and > there's one aspect in all of this thread that has either not been > mentioned or at least not made much of: > > the fact that erlang is a functional language. > > For years FP got a bad press, from the early days when the accusation > was inefficiency ("LISP programmers know the value of everything and the > cost of nothing") to the more recent criticisms that FP is very nice for > academics but won't work in the *real* world. > > Erlang clearly blows these ideas out of the water and combines all of All modern functional languages blow those preconceptions out of the water, for those who care to investigate. --Toby > the attributes everybody else has mentioned with those of developing in > a functional language, with all of its associated benefits, especially > of correctness. > > Besides, I think java is a terribly *ugly* language...:-) > > deryk From mononcqc@REDACTED Mon Feb 13 15:10:03 2012 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 13 Feb 2012 09:10:03 -0500 Subject: [erlang-questions] Common Test and base applications In-Reply-To: References: Message-ID: After trying some different things with Ahmed, I've found out that the problem is the config file I'm passing to the slave nodes: [{kernel, [{distributed, [{m8ball, 5000, ['a@REDACTED', 'b@REDACTED']}]}, {sync_nodes_mandatory, [' b@REDACTED']}, {sync_nodes_timeout, 5000} ] } ]. This seems to override a few values needed by ct_slave when using distributed applications. Removing the config file solves the application:which_applications() problem. What would be the best way to test distributed OTP applications with CT, then? On Mon, Feb 13, 2012 at 7:34 AM, Fred Hebert wrote: > I tried it with R14B04 also, and it still doesn't work for me. I'll try a > few more things to try and discover what it might be. I'm a bit surprised > this can even happen in the first place, though. > > > On Mon, Feb 13, 2012 at 5:44 AM, Ahmed Omar wrote: > >> I tried to reproduce it using same steps, but i get this when i use >> ct:pal("~p",[application:which_applications()]) >> i get >> >> *** User 2012-02-13 11:39:24.901 *** >> [{crypto,"CRYPTO version 2","2.0.4"}, >> {stdlib,"ERTS CXC 138 10","1.17.5"}, >> {kernel,"ERTS CXC 138 10","2.14.5"}] >> >> maybe i'm doing something different.. >> >> i'm using Erlang R14B04 (erts-5.8.5) >> >> On Sun, Feb 12, 2012 at 4:59 PM, Fred Hebert wrote: >> >>> I start them with distributed test specifications: >>> >>> {node, master, 'ct@REDACTED'}. >>> {node, a, 'a@REDACTED'}. >>> {node, b, 'b@REDACTED'}. >>> >>> {init, a, [{node_start, [{monitor_master, true}, >>> {boot_timeout, 10}, >>> {startup_functions, >>> [{application,start,[crypto]}, >>> >>> {application,start,[m8ball]}]}, >>> {erl_flags, "-pa >>> /Users/ferd/code/self/learn-you-some-erlang/m8ball/ebin/" >>> "-config >>> dist_m8ball_SUITE_data/main.config"}]}]}. >>> {init, b, [{node_start, [{monitor_master, true}, >>> {boot_timeout, 10}, >>> {startup_functions, >>> [{application,start,[crypto]}, >>> >>> {application,start,[m8ball]}]}, >>> {erl_flags, "-pa >>> /Users/ferd/code/self/learn-you-some-erlang/m8ball/ebin/ " >>> "-config >>> dist_m8ball_SUITE_data/backup.config"}]}]}. >>> >>> And I start it with: >>> >>> $ erl -name ct -pa ../ebin/ >>> Erlang R15B (erts-5.9) [source] [64-bit] [smp:4:4] [async-threads:0] >>> [hipe] [kernel-poll:false] Eshell V5.9 (abort with ^G) >>> >>> (ct@REDACTED)1> ct_master:run("m8ball_dist.spec"). >>> >>> And whenever I use ct:pal("~p",[application:which_applications()]) in >>> the suite, I get [] as a result. Further inspection shows that the >>> distributed applications I have are read by the controllers, but stdlib and >>> kernel are not started. >>> >>> >>> On Sun, Feb 12, 2012 at 5:45 AM, Ahmed Omar wrote: >>> >>>> Hi Fred, >>>> 1- How do you start the ct_slave nodes? >>>> (ct@REDACTED)1> ct_slave:start(omarmb, testnode,[]). >>>> {ok,testnode@REDACTED} >>>> (ct@REDACTED)2> rpc:call('testnode@REDACTED', application, >>>> which_applications,[]). >>>> [{stdlib,"ERTS CXC 138 10","1.17.5"}, >>>> {kernel,"ERTS CXC 138 10","2.14.5"}] >>>> >>>> 2- You can use erl_flags to specify more options to your slave node, >>>> e.g: >>>> (ct@REDACTED)3> ct_slave:start(omarmb, testnode1,[{erl_flags, "-s >>>> mnesia"}]). >>>> {ok,testnode1@REDACTED} >>>> (ct@REDACTED)4> rpc:call('testnode1@REDACTED', application, >>>> which_applications,[]). >>>> [{mnesia,"MNESIA CXC 138 12","4.5"}, >>>> {stdlib,"ERTS CXC 138 10","1.17.5"}, >>>> {kernel,"ERTS CXC 138 10","2.14.5"}] >>>> >>>> On Sun, Feb 12, 2012 at 6:22 AM, Fred Hebert wrote: >>>> >>>>> I should specify this problem is something I noticed when using >>>>> distributed tests based on ct_slave; I would suspect that local tests being >>>>> run from a shell started manually do not suffer from this. >>>>> >>>>> >>>>> On Sun, Feb 12, 2012 at 12:19 AM, Fred Hebert wrote: >>>>> >>>>>> I've recently discovered that Common Test appears to not be starting >>>>>> basic applications such as kernel and stdlib, but it still starts things >>>>>> like application controllers and whatnot. >>>>>> >>>>>> This gives me a few problems because it breaks a few behaviours such >>>>>> as application:which_applications(), being able to start a few applications >>>>>> (they depend on stdlib and kernel. Sstdlib depends on kernel, and manually >>>>>> starting kernel fails because a bunch of processes already have that >>>>>> name). >>>>>> >>>>>> It will also play negatively with things like manually calling >>>>>> application:set_env/3 before starting an application to configure it (after >>>>>> loading it) as just starting it will overwrite all values, etc. >>>>>> >>>>>> This causes me a few problems because it forces me to test everything >>>>>> below the application level, and I can't automate testing of things like >>>>>> distributed applications and their failover/takeover mechanisms. >>>>>> >>>>>> Is there any workaround for these problems? >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-questions >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman@REDACTED Mon Feb 13 15:32:38 2012 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 13 Feb 2012 09:32:38 -0500 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F391921.8060601@telegraphics.com.au> References: <4F36442D.1060202@gmail.com> <4F36E681.90807@erlang-solutions.com> <4F36ED5A.9070707@gmail.com> <4F3880B0.9050706@camosun.bc.ca> <4F391921.8060601@telegraphics.com.au> Message-ID: <4F391F06.8070403@meetinghouse.net> Somehow, this conversation reminds me of Virding's First Rule of Programming - as posted to this list on 1/11/2008 :-) -------- reposted message ----- After reading the blogs about how good Erlang's concurrency model is and how we just just made a super implementation of it in XXX I have been led to formulate Virding's First Rule of Programming: Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang. This is, of course, a mild travesty of Greenspun (*) but I think it is fundamental enough to be my first rule, not the tenth. Robert (*) "Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp." -------- -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From fhunleth@REDACTED Mon Feb 13 15:55:04 2012 From: fhunleth@REDACTED (Frank Hunleth) Date: Mon, 13 Feb 2012 09:55:04 -0500 Subject: [erlang-questions] Erlang on ARM In-Reply-To: <5BC624B5-3013-4C46-94C2-8983AA883BD4@cs.otago.ac.nz> References: <72786C06-997C-4FFD-800E-5BD2B3E92220@cs.otago.ac.nz> <5BC624B5-3013-4C46-94C2-8983AA883BD4@cs.otago.ac.nz> Message-ID: On Mon, Feb 13, 2012 at 12:55 AM, Richard O'Keefe wrote: > I should also mention that my colleague doing IR on an Android phone > has fallen foul of Linux memory management: ?by default the OS will > overcommit virtual memory. ?So his program ask for memory, is told > it has been given it, and then some random service gets shut down > because there isn't that much. ?If I recall correctly, it was sshd > that got killed the first time. ?While it was an Android _phone_, > I think it was some other Linux he'd installed on it; I remember > he and a student had the dickens of a job getting gdb to work on it. Right. Linux is usually set up to overcommit memory by default. Take a look at /proc/sys/vm/overcommit_memory to change this. I thought that Android also had a more sophisticated low memory handling policy, but I do not know for sure. At least with "regular" Linux, when a low memory situation occurs, the OOM killer runs a heuristic that will pick the sacrificial process to shut down. > > Overcommitment must be a problem for other people running Erlang on > Linux. ?What, other that a few incantations as root, do you/can you > do about it? I have had problems with the OOM killer, but not with Erlang. I'm new to the Erlang world, though. I most recently ran into the problem with a Javascript interpreter that was embedded in a low memory device. It was possible to limit the amount of memory allocated by the interpreter and that addressed the issue. Of course, some Javascript apps needed to be rewritten, but they never would have worked well on the device anyway. I don't know if Erlang has an option to limit the amount of memory used, but that seems like a route to explore. My guess is that Erlang applications are more equipped to handle out of memory conditions than anything else running on the hardware. Also, since you mentioned that you were looking into running on the Beaglebone, I have been running Erlang on that board as well. I've made a small SD card image (code on GitHub) that may help get you past the cross-compiling and other challenges of running on the board. I have some instructions here: http://nerves-project.org/gettingstarted.html The image is made using Buildroot which is fairly bare bones if you're used to Ubuntu or Angstrom. It may be easier to tweak should you need more memory or other resources, though. I have not looked into enabling HiPE, but I'm encouraged by the other responses to your email. Frank From roe.adrian@REDACTED Mon Feb 13 17:08:35 2012 From: roe.adrian@REDACTED (Adrian Roe) Date: Mon, 13 Feb 2012 16:08:35 +0000 Subject: [erlang-questions] very large networks of erlang nodes? In-Reply-To: <4F38125A.6030806@meetinghouse.net> References: <4F36F152.9070002@meetinghouse.net> <4F38125A.6030806@meetinghouse.net> Message-ID: <4F393583.90705@gmail.com> This was a cloud-based solution id3as built for Thomson Reuters that completely virtualised their online communications business that they run for most FTSE / NYSE companies. Our experience was that Erlang played nicely when in a star topology and (understandably) got very upset at these levels of scale when in a fully connected environment. We create / throw away servers in response to demand which can be very spikey. The project broke my previous "personal best" for numbers of concurrent servers in a single solution by about 750 ;) and I think we may be one of very few companies to have persuaded Amazon Cloud to return "Out of capacity" errors as opposed to "Exceeded account limits"... The responsiveness of AWS is remarkable - without hot spares etc, we can create and commission a server entirely from scratch less than a minute after exceeding a load threshold. Adrian *Dr Adrian Roe Director* On 12/02/12 19:26, Miles Fidelman wrote: > Steve Strong wrote: >> The largest the we have run at id3as so far is 768 erlang nodes, >> distributed across 5 data centers. The nodes were structured in a >> hierarchy and used the hidden flag to ensure that the network did not >> become fully connected. >> >> > cool! can you say a little more about what you were doing with them? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew@REDACTED Mon Feb 13 17:28:03 2012 From: andrew@REDACTED (Andrew Thompson) Date: Mon, 13 Feb 2012 11:28:03 -0500 Subject: [erlang-questions] smtp server In-Reply-To: References: <2b8d6c69-23d1-4046-8878-09d4729637a4@gi10g2000vbb.googlegroups.com> Message-ID: <20120213162803.GI10141@hijacked.us> A few inline comments: > > I have noticed that a great number of SMTP projects fail with a > > whimper. In particular, I observed that the JBoss project ran an SMTP > > project for a long, long time before even barely having something > > reasonable, and it's still not really "production quality". While the > > underlying protocol for SMTP is straightforward, I think things run > > aground owing to the teams initially underestimating the number of > > rfcs and protocol extensions that you are essentially *required* to > > support (especially wrt authentication etc) to have a production level > > server; and also the storage issues such as the user directory and > > message store. gen_smtp isn't a full SMTP server, its a library for working with SMTP. You can actually specify the extensions to advertise and you can even implement them in your callback module by defining the appropriately named function. gen_smtp supports some of the more basic extensions, at least. > > As far as Erlang is concerned, it's hard to see it happening until > > certain requisite libraries are mature. For instance, START_TLS is > > still not "easy" in erlang owing to the long, and continuing, struggle > > to get good TLS protocol support. Using new_ssl I've been able send SMTP over SSL to a bunch of major email servers, including gmail. So it's certainly not completely impossible, although I admit there might be configurations that erlang's ssl can't talk to. Both STARTTLS and connecting to a SSL socket both work. > > Assuming that does get "finished" (and there's a whole raft of crypto > > work still to do), perhaps a good start towards such a goal would be > > to integrate, at the very least, an LDAP client into the base > > libraries... I doubt that adding LDAP to the base libraries would be very helpful to most of erlang's userbase, but maybe I'm just being cynical. Andrew From mattevans123@REDACTED Mon Feb 13 17:56:55 2012 From: mattevans123@REDACTED (Matthew Evans) Date: Mon, 13 Feb 2012 11:56:55 -0500 Subject: [erlang-questions] Term to binary in a NIF Message-ID: Hi I've written a NIF that takes data from an external device driver, converts it to a term (a tuple) and uses enif_send (from a thread created by the nif) to a specific Erlang process. Unfortunately on some deployments we have been forced to disable SMP in the Linux kernel and BEAM due to a third-party driver issue. In these cases what I have done is used enif_system_info in the NIF, and if SMP is disabled I will send the message via a unix domain socket (I have a driver for that) instead of enif_send. On the Erlang side the UDS is opened, and I use erlang:open_port to pass the unix domain socket to the event loop. What is nice here is that I can use the same Erlang and C code for both SMP enabled and disabled systems. So the Erlang process would get an Erlang message like: {driver_result,Integer,Integer} - If SMP is enabled Or: {#Port<0.647>,{data,SomeBinary}} - If SMP is disabled What I would like to do is see if I can send the message as an Erlang term to the unix domain socket using something like term_to_binary in the NIF (I would prefer that instead of sending raw binary to Erlang with enif_send). Is that possible? Thanks Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.santos@REDACTED Mon Feb 13 19:00:41 2012 From: michael.santos@REDACTED (Michael Santos) Date: Mon, 13 Feb 2012 13:00:41 -0500 Subject: [erlang-questions] Term to binary in a NIF In-Reply-To: References: Message-ID: <20120213180041.GA1071@ecn.lan> On Mon, Feb 13, 2012 at 11:56:55AM -0500, Matthew Evans wrote: > > Hi > I've written a NIF that takes data from an external device driver, converts it to a term (a tuple) and uses enif_send (from a thread created by the nif) to a specific Erlang process. > Unfortunately on some deployments we have been forced to disable SMP in the Linux kernel and BEAM due to a third-party driver issue. In these cases what I have done is used enif_system_info in the NIF, and if SMP is disabled I will send the message via a unix domain socket (I have a driver for that) instead of enif_send. An alternative would be using a port driver. > On the Erlang side the UDS is opened, and I use erlang:open_port to pass the unix domain socket to the event loop. What is nice here is that I can use the same Erlang and C code for both SMP enabled and disabled systems. So the Erlang process would get an Erlang message like: > {driver_result,Integer,Integer} - If SMP is enabled > Or: > {#Port<0.647>,{data,SomeBinary}} - If SMP is disabled > What I would like to do is see if I can send the message as an Erlang term to the unix domain socket using something like term_to_binary in the NIF (I would prefer that instead of sending raw binary to Erlang with enif_send). > Is that possible? You can do the encoding using ei or manually create the binary using the external term format, e.g.: 1> term_to_binary(foo). <<131,100,0,3,102,111,111>> 131 = magic 100 = atom 0 3 = 3 bytes 102 111 111 = foo From mattevans123@REDACTED Mon Feb 13 18:53:27 2012 From: mattevans123@REDACTED (Matthew Evans) Date: Mon, 13 Feb 2012 12:53:27 -0500 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: References: <4F36442D.1060202@gmail.com>, <4F36E681.90807@erlang-solutions.com>, <4F36ED5A.9070707@gmail.com>, <4F3880B0.9050706@camosun.bc.ca>, Message-ID: A well written email Tim, I would also add that with development packages such as Maven, building complex Java applications is a breeze. Now personally I think Maven is a royal pain in the ass (XML hell anyone), the ability to bring in dependancies in such a simple way is awesome for product packaging. I've even used it myself - since most of my team are Java developers - for Erlang deployments (see http://erlang-plugin.sourceforge.net/). I think that what needs to be asked long term is where do we see Erlang been used? Will it just be a niche language, used in certain specific situations? Or do we see it becoming more of a general purpose language? Of course, it's not ever going to beat Java, C++ or other OOP/imperative languages in terms of number of users, although it would be nice if it would. For one it's off to a bad start with it been functional language. However, unlike Haskell it's not a pure-functional language. Your code can contain little bits of imperative functionality; functions can have side effects for example. In other words it's not too hard to learn. I guess I can only speak from my own experience trying to get Erlang accepted into two businesses. Normally there is an existing code base, or a set of users who have been coding in language X all their career. These people are always very reluctant to embrace something new. Many of these people will think that it's going to threaten their future in the company. Many will actively lie and present massaged data to prove their point (I've seen this a few times - for example comparing a simple NGINX reverse proxy that is doing nothing to a full-blown Yaws web-server for example). Managers also have the same worry, but also need to look at what it means to retain staff and employ new staff. Erlang, unfortunately, often times faces an up-hill battle. Something like Erjang can help here. I personally think it's non-ideal for most Erlang deployments, but can be used to get a foot in the door. Deploy Erjang on something that they are familiar with (JVM), have it "natively" talk to Java, and then introduce BEAM later. I also agree with other people that Erlang's performance is in most cases more than "good enough" for what it's being used for. But when you have a manager who is already reluctant to use it, and employees who are even less willing to use it, they are going to be even less accepting when they *think* it's too slow (even though that might not actually be the case). Anything that can be done by the community to help here is invaluable. I would add that in my experience many issues of poor-performance are often a case of poor code. People not adhering to OTP principles, people not getting to grips with concurrent programming by doing things like implementing a single Erlang process that serializes requests for the whole system. Or in other cases people not using what's available in the language (regex on binary data using binary_to_list and and then the re module, instead of the binary module). In those cases it won't matter a squat what Ericsson do to improve BEAM. But perhaps we need to make an effort to hammer home good programming practice and be more consistent with core libraries (especially with lists vs binaries). I guess I'm trying to say that everyone is correct, performance is usually more than good enough. But there is a perception among many non-Erlang developers that that is not the case. Matt Date: Mon, 13 Feb 2012 12:04:34 +0000 From: watson.timothy@REDACTED To: dbarker@REDACTED CC: erlang-questions@REDACTED Subject: Re: [erlang-questions] The future of Erlang and BEAM Java is ugly and bloated to boot. The JVM though, is actually a pretty fantastic piece of engineering and if you dig into the guts of it, there's a lot that VM teams across the board can learn, especially around self tuning and diagnostic/instrumentation support. I think the point about Michael made about mind-share is a very good one. Also the Java platform, for all its bloated complexity, is more mature in some respects. What I mean by that is, for developing typical business applications, Java (and god forgive me for saying it, the other big unmentionable corporate platform too) offers a number of things that are very beneficial and currently lacking from Erlang's ecosystem. For example, JDBC offers reliable and high performance connectivity to almost every database on the market. There are standardised APIs for working with things like web servers and this makes a big difference to the productivity of *ordinary programmers* who are the target audience for these kinds of development platforms. Having said that, I'd pick Erlang and fiddle with API inconsistencies and the near suicide inducing pain of ODBC on unix any day over Java. Going back to what the OP was asking: One of the reasons I don't think that we'll see a competitive implementation of Erlang on the JVM any time soon is that the JVM was built, first and foremost, to host an imperative language. Now the appearance of Clojure does prove that you *can* implement a functional language on the JVM, but Erlang is not just a functional langauge/platform, it is also (as Joe has put it) "Concurrency Orientated", which is about the lightweight Process being a fundamental and first class concept. Java does not have micro/green threads and native threads have limitations. The JVM does not, at its core, support the notion of immutability that we have in Erlang, despite good support for copy-on-write semantics in some (limited) circumstances. The scala crowd can build 'actors' and 'message passing' into their libraries, but these concepts are not part of the JVM. Developers of Scala/Clojure code *can* make their variables, types (and so on) immutable, can implement a syntax for passing around chunks of code in order to imitate higher order functions, but these concepts are not (as of today) part of the JVM. The core concepts for the JVM (and the CLR) are Objects with 'mutable state', native (os level) threads and in Java's case, primitive types that are distinct from objects. You can't get away from those underlying concepts in reality, so 'actors' are Objects and 'message passing' is done by sharing (object) state on a heap and so on. One of the problems people *seem* to be trying to get away from by moving to the JVM is that of raw throughput. We might see a shared heap appear in BEAM some time in the future, for certain special cases, and maybe other optimisations for performance will occur. But as Joe and others have pointed out, Erlang was never built with this in mind. And yet I'm not convinced that an Erlang implementation running on the JVM will really offer great performance benefits, because in order to be *truly like* Erlang, that implementation would *have* to recreate the BEAM emulator running on the JVM. Languages like Scala (and maybe Clojure, I don't actually know) compile down to Java byte code, which means that they're really just syntactic sugar with some runtime library support around it. Perhaps the innovator behind Erjang will pipe in and correct me, but my guess is that you couldn't do that with Erlang without loosing so much of what the langauge/platform is all about. Therefore you're now running a complex runtime environment (i.e., the BEAM emulator) inside another complex runtime environment (the JVM), and fun though they are, the implementations of Jython and JRuby demonstrate that there is a great cost (in terms of performance) when you do this. I'm happy to be proved wrong, but for all the good engineering that resides in the JVM, I suspect it's probably not the right platform for a competitive Erlang/OTP implementation. On 13 February 2012 03:17, Deryk Barker wrote: As a mere amateur in the erlang world - I've used it a few times in my network programming course, probably bending the rules slightly to do so... But I've been programming for a while (first program FORTRAN on an IBM 7090 while still at school in 1968, second program in BASIC on a PDP-8 while taking a course from Maurice Wilkes at Cambridge in 1970) and there's one aspect in all of this thread that has either not been mentioned or at least not made much of: the fact that erlang is a functional language. For years FP got a bad press, from the early days when the accusation was inefficiency ("LISP programmers know the value of everything and the cost of nothing") to the more recent criticisms that FP is very nice for academics but won't work in the *real* world. Erlang clearly blows these ideas out of the water and combines all of the attributes everybody else has mentioned with those of developing in a functional language, with all of its associated benefits, especially of correctness. Besides, I think java is a terribly *ugly* language...:-) deryk -- Deryk Barker, Computer Science Dept. Camosun College, Victoria, BC, Canada _______________________________________________ erlang-questions mailing list 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 watson.timothy@REDACTED Mon Feb 13 19:35:07 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Mon, 13 Feb 2012 18:35:07 +0000 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: References: <4F36442D.1060202@gmail.com> <4F36E681.90807@erlang-solutions.com> <4F36ED5A.9070707@gmail.com> <4F3880B0.9050706@camosun.bc.ca> Message-ID: On 13 February 2012 17:53, Matthew Evans wrote: > A well written email Tim, > > I would also add that with development packages such as Maven, building > complex Java applications is a breeze. Now personally I think Maven is a > royal pain in the ass (XML hell anyone), the ability to bring in > dependancies in such a simple way is awesome for product packaging. I've > even used it myself - since most of my team are Java developers - for > Erlang deployments (see http://erlang-plugin.sourceforge.net/). > > Yes indeed. Rebar does a reasonable job with dependencies, but having to build them from source each time isn't ok from the perspective of a large enterprise team with dozens of components making up each project. As we've gradually started breaking up our libraries/applications to factor out common code, this problem has grown. The team have adopted the maven erlang plugin for exactly this reason, although personally whilst I don't mind using maven/ivy for java projects, I'd much rather stick to rebar for Erlang ones. A binary artefact repository is the thing that seems to be missing, and having it only available as a hosted thing (like Erlware or CEAN 1.0/2.0) doesn't cut it for most shops with large development teams and infrastructure to manage (we have a combination of in-house and out-sourced engineers which I've heard (anecdotally) is around > 0.5 million technologists of which about a quarter are developers - so I guess we qualify as 'large'). Personally I think a good solution to this is to use the maven repository structure to deploy artefacts into and fetch them from. That way you can use a free (or commercial version) repository such as Sonatype Nexus for such things internally and have public facing mirrors also. There are complications (with having to use naming conventions to distinguish between different target versions of beam and different target os/architectures where drivers are present) but these aren't insurmountable. I'm quietly working on a dependency manager (like ivy, not a package manager like cean/agner) to do just this, as a rebar plugin. > I think that what needs to be asked long term is where do we see Erlang > been used? Will it just be a niche language, used in certain specific > situations? Or do we see it becoming more of a general purpose language? > I hope the latter, although it's not fit for every domain and personally I have no problem with multiple technologies mixed together, as long as the architectural boundaries are cleanly defined (e.g., via messaging or whatever integration approach fits the domain best). > > Of course, it's not ever going to beat Java, C++ or other > OOP/imperative languages in terms of number of users, although it would be > nice if it would. For one it's off to a bad start with it been functional > language. However, unlike Haskell it's not a pure-functional language. Your > code can contain little bits of imperative functionality; functions can > have side effects for example. In other words it's not too hard to learn. > > Coming from an Python + OCaml background, I found Java and .NET quite awkward to learn! ;) > I guess I can only speak from my own experience trying to get Erlang > accepted into two businesses. Normally there is an existing code base, or a > set of users who have been coding in language X all their career. These > people are always very reluctant to embrace something new. Many of these > people will think that it's going to threaten their future in the company. > Many will actively lie and present massaged data to prove their point (I've > seen this a few times - for example comparing a simple NGINX reverse proxy > that is doing nothing to a full-blown Yaws web-server for example). > > Managers also have the same worry, but also need to look at what it means > to retain staff and employ new staff. > > Erlang, unfortunately, often times faces an up-hill battle. > I've been through this too. I work in telecoms and unsurprisingly there is a reasonable amount of Erlang based infrastructure, but absolutely nothing existed in the (BSS) business applications space, where Java and .NET dominate. That's gradually changing, but only because my team took the time to build prototypes in our spare time and demonstrate the quality, robustness, *performance* and maintenance benefits these rewrites/alternatives delivered. We still run into a lot of road blocks, and I think it'd be the same if we were pushing Ruby or Python as well. > > Something like Erjang can help here. I personally think it's non-ideal for > most Erlang deployments, but can be used to get a foot in the door. Deploy > Erjang on something that they are familiar with (JVM), have it "natively" > talk to Java, and then introduce BEAM later. > > IMO the bottom line is that a lot of people are loved-up with Java because of the 'enterprise features' which is another way of saying 'all the stuff that makes their life as a developer simple/easy.' Those of us who've used Erlang in anger know that in reality, Java is far more complex than it needs to be and Erlang is part of a group of much more productive languages/platforms. But many more people would be willing to try if there were - standardised interfaces/APIs (a la Servlets, JDBC) - better dependency management tools - awesome build tools* * IMO rebar is already *the* awesome build tool and I'm using it for all my open source stuff. I think the other two points could (and maybe should??) come from the community, but there's a lot of effort involved. Also Erlang doesn't have a neat mechanism for defining an 'interface' that everyone can follow. There's custom behaviours, which are great, but no simple way to swap in and out of implementations cleanly and easily. Fixing that would be *massively* beneficial to the platform IMHO, but I digress. > I also agree with other people that Erlang's performance is in most cases > more than "good enough" for what it's being used for. But when you have a > manager who is already reluctant to use it, and employees who are even less > willing to use it, they are going to be even less accepting when they > *think* it's too slow (even though that might not actually be the case). > Anything that can be done by the community to help here is invaluable. > > I would add that in my experience many issues of poor-performance are > often a case of poor code. People not adhering to OTP principles, people > not getting to grips with concurrent programming by doing things like > implementing a single Erlang process that serializes requests for the whole > system. Or in other cases people not using what's available in the language > (regex on binary data using binary_to_list and and then the re module, > instead of the binary module). In those cases it won't matter a squat what > Ericsson do to improve BEAM. But perhaps we need to make an effort to > hammer home good programming practice and be more consistent with core > libraries (especially with lists vs binaries). > > +1. Most performance difficulties are down to poorly written code - often code that is not 'dirty' but simply not idiomatically correct. We have a web based application (RESTful web service) written on Misultin that out performs the Java application it replaced both in terms of concurrent connections and its raw (round trip) response time (which includes accessing a postgres database). Incidentally, the key to our success was *not* copying the request lifecycle that the java application had. Asynchronous communication with the database is handled carefully so that each row returned from the network driver is almost immediately made available to the response generating code, which in turn streams its output back to the client immediately. Not waiting until the whole response has been built up saved 3-4x memory use and increased the 'speed' of the application by a similar factor. This is a much more Erlang-ish approach, and that really seems to pay off. > I guess I'm trying to say that everyone is correct, performance is usually > more than good enough. But there is a perception among many non-Erlang > developers that that is not the case. > Benchmarks will fix this. Problem is, they need to be based on the *full request lifecycle* - e.g., for a bog standard web application/service. Perhaps we need a proof of concept application that does all the various stuff you'd expect to see happening on the server i.e., mapping the request to a handler, validation of input data/parameters, performing some application domain logic, talking to a database, serialising the response back to the client. The Java and .NET crowds have a "Pet Store" application that demonstrates this, attempting to point out good practises along the way. Perhaps if we, as a community, were to produce the same thing, it would not only benefit new users but also provide an opportunity to show that Erlang can be a competitive solution for building such applications. I for one would be willing to participate, although I'd be *much* more inclined to do so if there was a standard API for interacting with web servers. There are a couple of open source efforts, but they're still at about 70 - 80% completeness from what I can tell, and personally I won't back anything that is based on parameterised modules until the OTP team decides once and for all if they're staying or going. -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Mon Feb 13 19:35:51 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Mon, 13 Feb 2012 18:35:51 +0000 Subject: [erlang-questions] tidier is down In-Reply-To: <6629728d-3284-4a39-bc8f-02f4fb20e575@bs8g2000vbb.googlegroups.com> References: <35F49CCD-F958-4677-B53F-F9AAA0A8BEA7@i-tool.eu> <6629728d-3284-4a39-bc8f-02f4fb20e575@bs8g2000vbb.googlegroups.com> Message-ID: +1 I'd *really* like to be able to use it again. :) On 12 February 2012 23:42, Ingo wrote: > Hi, > > it seems like the tidier website is still down (for almost a month > now).. Can someone provide another server to run tidier or a > standalone version of the tool? > > Thanks, > Ingo > > On Jan 15, 6:55 am, Andrzej Sliwa wrote: > > Hi Guys, > > > > it looks like tidier service is down: > > > > http://tidier.softlab.ntua.gr/mediawiki/ > > Database error > > A database query syntax error has occurred. This may indicate a bug in > the software. The last attempted database query was: > > (SQL query hidden) > > from within function "MediaWikiBagOStuff::_doinsert". MySQL returned > error "1114: The table 'objectcache' is full (localhost)". > > > > http://tidier.softlab.ntua.gr:20000/tidier/getstarted > > ERROR erlang code crashed: > > File: appmod:0 > > Reason: {undef, > > [{erlyweb,out, > > [{arg,#Port<0.486>, > > {{89,228,137,251},64315}, > > {headers,"keep-alive", > > > "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", > > "tidier.softlab.ntua.gr:20000 > ",undefined,undefined, > > > undefined,undefined,undefined,undefined,undefined, > > "Mozilla/5.0 (Macintosh; Intel Mac OS X > 10_7_2) AppleWebKit/534.52.7 (KHTML, like Gecko) Version/5.1.2 > Safari/534.52.7", > > undefined,[],undefined,undefined,undefined, > > undefined,undefined,undefined,undefined, > > [{http_header,10,'Accept-Encoding',undefined, > > "gzip, deflate"}, > > {http_header,11,'Accept-Language',undefined, > > "en-us"}]}, > > {http_request,'GET', > > {abs_path,"/tidier/getstarted"}, > > {1,1}}, > > > undefined,"/tidier/getstarted",undefined,"getstarted", > > "/home/ethan/apps/tidier/www","/", > > "/home/ethan/apps/tidier/www/tidier/getstarted", > > undefined,undefined,<0.240.0>, > > [{"appname","tidier"}], > > "/","/","/getstarted"}]}, > > {yaws_server,deliver_dyn_part,8}, > > {yaws_server,aloop,3}, > > {yaws_server,acceptor0,2}, > > {proc_lib,init_p,5}]} > > Req: {http_request,'GET',{abs_path,"/tidier/getstarted"},{1,1}} > > Stack: [{erlyweb,out, > > [{arg,#Port<0.486>, > > {{89,228,137,251},64315}, > > {headers,"keep-alive", > > > "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", > > "tidier.softlab.ntua.gr:20000",undefined,undefined, > > undefined,undefined,undefined,undefined,undefined, > > "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) > AppleWebKit/534.52.7 (KHTML, like Gecko) Version/5.1.2 Safari/534.52.7", > > > undefined,[],undefined,undefined,undefined,undefined, > > undefined,undefined,undefined, > > [{http_header,10,'Accept-Encoding',undefined, > > "gzip, deflate"}, > > > {http_header,11,'Accept-Language',undefined,"en-us"}]}, > > > {http_request,'GET',{abs_path,"/tidier/getstarted"},{1,1}}, > > undefined,"/tidier/getstarted",undefined,"getstarted", > > "/home/ethan/apps/tidier/www","/", > > > "/home/ethan/apps/tidier/www/tidier/getstarted",undefined, > > undefined,<0.240.0>, > > [{"appname","tidier"}], > > "/","/","/getstarted"}]}, > > {yaws_server,deliver_dyn_part,8}, > > {yaws_server,aloop,3}, > > {yaws_server,acceptor0,2}, > > {proc_lib,init_p,5}] > > > > Maybe it is good time to make this tool open, or free standalone version > for open source projects? > > > > best regards, > > Andrzej > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questi...@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 watson.timothy@REDACTED Mon Feb 13 19:37:51 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Mon, 13 Feb 2012 18:37:51 +0000 Subject: [erlang-questions] Post and query string parameter validation library? In-Reply-To: References: Message-ID: Github markdown tip: when you're writing blocks of Erlang code, do this: ```erlang %% put your code in here, and watch the syntax highlighting goodness... ``` On 12 February 2012 17:56, Willem de Jong wrote: > Hi, > > I put my version on github: > > https://github.com/willemdj/parse_qs > > It translates a query string to a record, based on a specification that > can be generated from the record declaration (+ some optional additional > tags in comments, EDoc-style). > > It probably needs some additional work (for sure the REAME file does, it > looks awful - my first attempt to use the markdown format). > > Regards, > Willem > > > On Fri, Feb 10, 2012 at 11:59 PM, Mark Allen wrote: > >> On 2/10/12 10:43 AM, "Mark Allen" wrote: >> >> >I am about half-way done with my validation module. I'll put it up on >> >github when I'm done too. >> >> https://gist.github.com/1793796 >> >> >> I'd love comments, feedback or edits. This isn't 100% finished, either, >> but >> it's close enough to show what I'm aiming for. >> >> Thank you. >> >> Mark >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingo.jaeckel@REDACTED Mon Feb 13 19:42:56 2012 From: ingo.jaeckel@REDACTED (Ingo Jaeckel) Date: Mon, 13 Feb 2012 13:42:56 -0500 Subject: [erlang-questions] tidier is down In-Reply-To: References: <35F49CCD-F958-4677-B53F-F9AAA0A8BEA7@i-tool.eu> <6629728d-3284-4a39-bc8f-02f4fb20e575@bs8g2000vbb.googlegroups.com> Message-ID: Hi, I informed Kostis Sagonas earlier today. He already told me that they are working on a fix. Tomorrow, it should be working again. Cheers, Ingo On Mon, Feb 13, 2012 at 1:35 PM, Tim Watson wrote: > +1 > > I'd *really* like to be able to use it again. :) > > > On 12 February 2012 23:42, Ingo wrote: >> >> Hi, >> >> it seems like the tidier website is still down (for almost a month >> now).. Can someone provide another server to run tidier or a >> standalone version of the tool? >> >> Thanks, >> Ingo >> >> On Jan 15, 6:55?am, Andrzej Sliwa wrote: >> > Hi Guys, >> > >> > it looks like tidier service is down: >> > >> > http://tidier.softlab.ntua.gr/mediawiki/ >> > Database error >> > A database query syntax error has occurred. This may indicate a bug in >> > the software. The last attempted database query was: >> > (SQL query hidden) >> > from within function "MediaWikiBagOStuff::_doinsert". MySQL returned >> > error "1114: The table 'objectcache' is full (localhost)". >> > >> > http://tidier.softlab.ntua.gr:20000/tidier/getstarted >> > ERROR erlang ?code ?crashed: >> > ?File: appmod:0 >> > Reason: {undef, >> > ? ? ? ? ? ? [{erlyweb,out, >> > ? ? ? ? ? ? ? ? ?[{arg,#Port<0.486>, >> > ? ? ? ? ? ? ? ? ? ? ? {{89,228,137,251},64315}, >> > ? ? ? ? ? ? ? ? ? ? ? {headers,"keep-alive", >> > >> > "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", >> > >> > "tidier.softlab.ntua.gr:20000",undefined,undefined, >> > >> > undefined,undefined,undefined,undefined,undefined, >> > ? ? ? ? ? ? ? ? ? ? ? ? ? "Mozilla/5.0 (Macintosh; Intel Mac OS X >> > 10_7_2) AppleWebKit/534.52.7 (KHTML, like Gecko) Version/5.1.2 >> > Safari/534.52.7", >> > ? ? ? ? ? ? ? ? ? ? ? ? ? undefined,[],undefined,undefined,undefined, >> > ? ? ? ? ? ? ? ? ? ? ? ? ? undefined,undefined,undefined,undefined, >> > ? ? ? ? ? ? ? ? ? ? ? ? ? [{http_header,10,'Accept-Encoding',undefined, >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"gzip, deflate"}, >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ?{http_header,11,'Accept-Language',undefined, >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"en-us"}]}, >> > ? ? ? ? ? ? ? ? ? ? ? {http_request,'GET', >> > ? ? ? ? ? ? ? ? ? ? ? ? ? {abs_path,"/tidier/getstarted"}, >> > ? ? ? ? ? ? ? ? ? ? ? ? ? {1,1}}, >> > >> > undefined,"/tidier/getstarted",undefined,"getstarted", >> > ? ? ? ? ? ? ? ? ? ? ? "/home/ethan/apps/tidier/www","/", >> > ? ? ? ? ? ? ? ? ? ? ? "/home/ethan/apps/tidier/www/tidier/getstarted", >> > ? ? ? ? ? ? ? ? ? ? ? undefined,undefined,<0.240.0>, >> > ? ? ? ? ? ? ? ? ? ? ? [{"appname","tidier"}], >> > ? ? ? ? ? ? ? ? ? ? ? "/","/","/getstarted"}]}, >> > ? ? ? ? ? ? ?{yaws_server,deliver_dyn_part,8}, >> > ? ? ? ? ? ? ?{yaws_server,aloop,3}, >> > ? ? ? ? ? ? ?{yaws_server,acceptor0,2}, >> > ? ? ? ? ? ? ?{proc_lib,init_p,5}]} >> > Req: {http_request,'GET',{abs_path,"/tidier/getstarted"},{1,1}} >> > Stack: [{erlyweb,out, >> > ? ? ? ? ? ? [{arg,#Port<0.486>, >> > ? ? ? ? ? ? ? ? ?{{89,228,137,251},64315}, >> > ? ? ? ? ? ? ? ? ?{headers,"keep-alive", >> > >> > ?"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", >> > ? ? ? ? ? ? ? ? ? ? ?"tidier.softlab.ntua.gr:20000",undefined,undefined, >> > ? ? ? ? ? ? ? ? ? ? ?undefined,undefined,undefined,undefined,undefined, >> > ? ? ? ? ? ? ? ? ? ? ?"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) >> > AppleWebKit/534.52.7 (KHTML, like Gecko) Version/5.1.2 Safari/534.52.7", >> > >> > ?undefined,[],undefined,undefined,undefined,undefined, >> > ? ? ? ? ? ? ? ? ? ? ?undefined,undefined,undefined, >> > ? ? ? ? ? ? ? ? ? ? ?[{http_header,10,'Accept-Encoding',undefined, >> > ? ? ? ? ? ? ? ? ? ? ? ? ? "gzip, deflate"}, >> > >> > {http_header,11,'Accept-Language',undefined,"en-us"}]}, >> > >> > ?{http_request,'GET',{abs_path,"/tidier/getstarted"},{1,1}}, >> > ? ? ? ? ? ? ? ? ?undefined,"/tidier/getstarted",undefined,"getstarted", >> > ? ? ? ? ? ? ? ? ?"/home/ethan/apps/tidier/www","/", >> > >> > ?"/home/ethan/apps/tidier/www/tidier/getstarted",undefined, >> > ? ? ? ? ? ? ? ? ?undefined,<0.240.0>, >> > ? ? ? ? ? ? ? ? ?[{"appname","tidier"}], >> > ? ? ? ? ? ? ? ? ?"/","/","/getstarted"}]}, >> > ? ? ? ? {yaws_server,deliver_dyn_part,8}, >> > ? ? ? ? {yaws_server,aloop,3}, >> > ? ? ? ? {yaws_server,acceptor0,2}, >> > ? ? ? ? {proc_lib,init_p,5}] >> > >> > Maybe it is good time to make this tool open, or free standalone version >> > for open source projects? >> > >> > best regards, >> > Andrzej >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > >> > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > From mfidelman@REDACTED Mon Feb 13 19:53:48 2012 From: mfidelman@REDACTED (Miles Fidelman) Date: Mon, 13 Feb 2012 13:53:48 -0500 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: References: <4F36442D.1060202@gmail.com>, <4F36E681.90807@erlang-solutions.com>, <4F36ED5A.9070707@gmail.com>, <4F3880B0.9050706@camosun.bc.ca>, Message-ID: <4F395C3C.6080908@meetinghouse.net> Matthew Evans wrote: > > I think that what needs to be asked long term is where do we see > Erlang been used? Will it just be a niche language, used in certain > specific situations? Or do we see it becoming more of a general > purpose language? > I can answer that at least from the point of view of what I'm looking at it for: - highly distributed applications and services (e.g., a network of Jabber servers, RabbitMQ) - a platform for applications with high concurrency (e.g., CouchDB) - modeling and simulation / massively multiplayer games (i.e, anything that is conceptually a massively concurrent application) - high-availability service environments (i.e., carrier-class telecom apps - where Erlang has its roots) Beyond that, personally, does it need to be general purpose? (For that matter, what does it mean to be general purpose these days?) Miles Fidleman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From dmercer@REDACTED Mon Feb 13 23:11:20 2012 From: dmercer@REDACTED (David Mercer) Date: Mon, 13 Feb 2012 16:11:20 -0600 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: References: <4F36442D.1060202@gmail.com> Message-ID: <007c01ccea9c$6b1bbf00$41533d00$@com> Perhaps it wasn?t Erlang's original intent, but I find one of the amazing things about Erlang that I had an application that ran on a single box. However, it needed to be running 24?7, which, of course, is impossible on a single box, since sometimes that box has to be rebooted or taken down for maintenance. With the addition of just a few config files ? no code changes ? I was able to have it running at a single place on my network, but with failover sessions waiting in the background for the occasions when the main process goes down. This is a fun demo, too, when people ask why I chose Erlang for the application; I can just pull up a few remote sessions to the servers and kill the main, and they can see the failover take over right away. > -----Original Message----- > From: erlang-questions-bounces@REDACTED [mailto:erlang-questions- > bounces@REDACTED] On Behalf Of Joe Armstrong > Sent: Saturday, February 11, 2012 11:02 AM > To: Radek > Cc: erlang-questions@REDACTED > Subject: Re: [erlang-questions] The future of Erlang and BEAM > > I'll try and give a short answer to your question. > > To start with you are comparing chalk with cheese - Erlang was > NOT designed to be a fast messaging passing language. It was designed > for building fault-tolerant applications - it wasn't designed > for speed it was designed for safety. > > A lot of the message passing platforms you read about, and mention in > the same breath as Erlang were designed for speed > and not safety - so it's hardly surprising that is the absence of > errors these other platforms are faster than Erlang. > > Where Erlang should excel is when things go wrong - when the > code is buggy and crashes, when the system is overloaded, when you > stress things in unexpected ways. > > The Erlang view of the world is very different to the view of > the world used in most other languages. > > Take a web server, for example. In the conventional view of the > world if there might be one web server per machine, the > web server might spawn an OS process for each incoming task > (if it wants safety) of it might handle all sessions in the same task > if it wants speed but no safety. It (the web server) uses OS processes > for reasons of safety - to isolate the user sessions from > each other - but this is very slow. > > What happens if there is a rare > error in the web-server code itself - one that is very rarely > encountered. Does this affect *all* user sessions or only the > session where the error occurred? - My guess is that all sessions > will collapse if the web-server itself collapses. > > How is a web-server in Erlang written? On the face of things it > looks like any other web sever - but an Erlang system that appears > from the outside to be handling (say) 2000 user sessions, > is NOT one web server with 2000 sessions - it is 2000 erlang > process (all independent) and each one is running ONE web server. > > So in the Erlang case we have 2000 web servers, each running > one user session - in the conventional case we have one web > server running 2000 sessions. > > Back to my question - what happens if there is a rare error > in the web server code itself which is triggered in one session? > In the Erlang case only one web server dies and all the rest > survive. In the case where all 2000 sessions are handled by the > faster server all sessions die. > > So you choose - fast or safe? - If you want the fastest possible > solution Erlang is not the answer - BUT it will be unsafe. > > Adding checks and recovery mechanism COSTS something. > There are no free lunches. > > I often see messaging passing systems mentioned that are said > to have "Erlang like semantics" and are said to be faster. > > But these are unsafe systems and Erlang like semantics means > *a lot more* than fast message passing. > > Erlang is good at what it was designed to be good at - which was > building fault-tolerant soft real-time distributed systems with > dynamic code upgrade - I know of nothing that has remotely > similar semantics. > > There are *many* systems with superficial similarities - but non > that I would trust to build fault-tolerant systems with. > > Cheers > > /Joe > > > > > > On Sat, Feb 11, 2012 at 11:34 AM, Radek > wrote: > > Hello Group, > > > > it's my first post here, although I've been reading many interesting > posts > > here for quite a long time. > > Anyway, I posted a question on StackOverflow today with the same > title > > (here). As I've written there, I don't want to start any flame-war, > > particularly because I'm actually an Erlang fan-boy :) but I'd like > to know > > your opinion on the subject. Here's the original question: > > > > ------- > > Some time ago I got seriously interested in Erlang (coming from > C++/PHP/Java > > world) - and I've seen it has been successfuly used in the industry, > by > > Ericsson, Facebook, Goldman Sachs, etc. So, I thought it would be a > great > > platform to build high demanding apps, with low-latency profile, with > a lot > > cleaner and nicer language than, for example, Java (for me). > > > > But after "wow effect" has gone, I discovered that there are many > high > > performance Java libraries that seem to resolve many problems that > Erlang is > > theoretically best suited for (real-time, low-latency applications, > > concurrency, fault-tolerance, etc.). Moreover, it seems that there > are > > things that, despite Erlang profile, are just not possible to achieve > on > > BEAM (like LMAX Disruptor concurrent framework). > > > > So the question arises: is Erlang still the best platform to build > such > > demanding applications ? Wouldn't it be better if we stick to one, > very > > mature (J)VM and try to make it even better than trying to achieve > something > > similar with less resources available (size of OTP team vs. JVM team, > > supporters, etc) ? And is it possible at all to achieve this kind of > > performance and adoption with BEAM ? > > > > And just to make things clear: I don't want to init a flame war here. > I am > > just curious becouse I really like Erlang and I think it's a great > platform > > and I'd like to invest time and effort to build real-life projects on > it. > > But I'd just like to know what others might say about that and - if > I'wrong > > - maybe someone could correct me. > > ------- > > > > I hope we can discuss it since I think it would be valuable not only > for me. > > > > Greetings, > > Radek > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ok@REDACTED Tue Feb 14 00:17:47 2012 From: ok@REDACTED (Richard O'Keefe) Date: Tue, 14 Feb 2012 12:17:47 +1300 Subject: [erlang-questions] Erlang on ARM In-Reply-To: References: <72786C06-997C-4FFD-800E-5BD2B3E92220@cs.otago.ac.nz> <5BC624B5-3013-4C46-94C2-8983AA883BD4@cs.otago.ac.nz> Message-ID: On 14/02/2012, at 3:55 AM, Frank Hunleth wrote: > Right. Linux is usually set up to overcommit memory by default. Take a > look at /proc/sys/vm/overcommit_memory to change this. Yeah, we know about that. (Isn't wonderful?) However, you have to be root to change that, and my colleague doesn't want to distribute software that requires people to change their OS parameters as root. I can't say I blame him. > I thought that > Android also had a more sophisticated low memory handling policy, but > I do not know for sure. At least with "regular" Linux, when a low > memory situation occurs, the OOM killer runs a heuristic that will > pick the sacrificial process to shut down. The problem is that it seems to be really really stupid at making those choices, killing system services with small memory use. > > I have had problems with the OOM killer, but not with Erlang. I'm new > to the Erlang world, though. I most recently ran into the problem with > a Javascript interpreter that was embedded in a low memory device. It > was possible to limit the amount of memory allocated by the > interpreter and that addressed the issue. Of course my colleague can limit the amount of memory he asks for. He does. However, living within that limit doesn't stop his process being killed if *some other* process decides to ask for a lot of memory. The best we've been able to come up with is to have two processes. One of them does the real work. Each of them polls the other and if there's no response, restarts it. This relies on the OOM-killer killing just one process, of course... > Also, since you mentioned that you were looking into running on the > Beaglebone, I have been running Erlang on that board as well. I've > made a small SD card image (code on GitHub) that may help get you past > the cross-compiling and other challenges of running on the board. I > have some instructions here: > > http://nerves-project.org/gettingstarted.html I am very thankful to you for this. This is a _great_ list. From kenneth.lundin@REDACTED Tue Feb 14 09:44:14 2012 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Tue, 14 Feb 2012 09:44:14 +0100 Subject: [erlang-questions] [erlang-patches] add compiler checked atoms In-Reply-To: <4F2EF17F.3020006@gmail.com> References: <4F2EF17F.3020006@gmail.com> Message-ID: Hi, I don't think this is a good way to introduce declared atoms. We already have the -type and -spec notation for definition of types and function signatures which are then used by Dialyzer for type checking. I don't think we should introduce yet another notation that is not harmonized with -type and -spec. It is already possible to declare atoms in -type and -spec. Why not use this already present notation and add optional checking of atoms against declared atoms inside -type and -spec instead. With the suggested -atom declaration we will probably get the same atoms declared 2 times with different notations and I think that will clutter down the code with redundant information to an unacceptable degree. /Kenneth, Erlang/OTP Ericsson On Sun, Feb 5, 2012 at 10:15 PM, Richard Carlsson < carlsson.richard@REDACTED> wrote: > Sorry, pressed send too soon in the last attempt. Here is the code: > > git fetch git@REDACTED:richcarl/otp.**git warn-unknown-atom > > Here is a suggested patch to the compiler, that I'm throwing out there as > a request for comments. In any large code base, it can be hard to maintain > atom hygiene - you may have hidden errors due to misspelled atoms, people > may be adding atoms without much thought, and it can be hard to track which > atoms are being used where and for what (e.g., atoms used for options, > error indicators, message tags, callback module and function names, etc. > This allows you to declare your atoms like so: > > -atoms([foo, bar]). > > You can have any number of such declarations, and an atom may occur > multiple times and/or in different declarations - it's the union of known > atoms that matters. Note that this declaration is backwards compatible; the > current compiler will accept it as a generic attribute with no particular > meaning. > > If you specify the compiler option `warn_unused_atom' when compiling a > module (you can put `-compile([warn_unused_atom]).**' in the module if > you want to enable the checking in that module only), you will get a > warning for each atom that has not been explicitly declared. The compiler > knows about standard atoms such as `ok', `true', `false', `undefined' etc., > and it does not check function and module names in calls, or record names > and fields of records, since these are checked in other ways already. > > I don't think this addition warrants an EEP, since it doesn't change the > language as such; it only adds a backwards compatible feature to the > compiler. However, I'd like to get some initial feedback before I bother to > update the documentation and submit it as a full patch. > > git@REDACTED:richcarl/otp.**git > > /Richard > ______________________________**_________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/**listinfo/erlang-patches > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Tue Feb 14 10:47:01 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Tue, 14 Feb 2012 10:47:01 +0100 Subject: [erlang-questions] [erlang-patches] add compiler checked atoms In-Reply-To: References: <4F2EF17F.3020006@gmail.com> Message-ID: <4F3A2D95.8030305@gmail.com> On 02/14/2012 09:44 AM, Kenneth Lundin wrote: > Hi, > I don't think this is a good way to introduce declared atoms. > We already have the -type and -spec notation for definition of > types and function signatures which are then used by Dialyzer for type > checking. > I don't think we should introduce yet another notation that is not > harmonized with -type and -spec. > It is already possible to declare atoms in -type and -spec. Why not use > this already present notation and add > optional checking of atoms against declared atoms inside -type and -spec > instead. > With the suggested -atom declaration we will probably get the same atoms > declared 2 times with different notations and I think that > will clutter down the code with redundant information to an > unacceptable degree. Yes, that is probably a better idea: that any atom occurring in a -type and/or -spec declaration is implicitly said to be known, and others are not. This would be an incentive for people to define types for things like the set of messages to a server or the set of atoms allowed as flags to a function (or error codes returned from a function). The question is, should atoms occurring in -spec declarations be taken as implicit "exists"-declarations, or should it only be those in -type? If it's only -type that counts, you could get checking of the atoms in -spec declarations as well, so you don't spell an atom wrong in the spec for one of 3 versions of a function and suddenly that atom is also implicitly allowed. I think -type only is the right way. I'll see if I can change my patch to do this instead. /Richard From kenneth.lundin@REDACTED Tue Feb 14 12:24:41 2012 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Tue, 14 Feb 2012 12:24:41 +0100 Subject: [erlang-questions] [erlang-patches] add compiler checked atoms In-Reply-To: <4F3A2D95.8030305@gmail.com> References: <4F2EF17F.3020006@gmail.com> <4F3A2D95.8030305@gmail.com> Message-ID: I think atoms introduced in both -type and -spec should be respected in this feature. If you want to guard yourself against a misspelled atom in one -spec you can use -type but you are not forced to. And if you introduce an atom in a -spec and never use it in the code then you could maybe issue a warning for that too. /Kenneth On Tue, Feb 14, 2012 at 10:47 AM, Richard Carlsson < carlsson.richard@REDACTED> wrote: > On 02/14/2012 09:44 AM, Kenneth Lundin wrote: > >> Hi, >> I don't think this is a good way to introduce declared atoms. >> We already have the -type and -spec notation for definition of >> types and function signatures which are then used by Dialyzer for type >> checking. >> I don't think we should introduce yet another notation that is not >> harmonized with -type and -spec. >> It is already possible to declare atoms in -type and -spec. Why not use >> this already present notation and add >> optional checking of atoms against declared atoms inside -type and -spec >> instead. >> With the suggested -atom declaration we will probably get the same atoms >> declared 2 times with different notations and I think that >> will clutter down the code with redundant information to an >> unacceptable degree. >> > > Yes, that is probably a better idea: that any atom occurring in a -type > and/or -spec declaration is implicitly said to be known, and others are > not. This would be an incentive for people to define types for things like > the set of messages to a server or the set of atoms allowed as flags to a > function (or error codes returned from a function). > > The question is, should atoms occurring in -spec declarations be taken as > implicit "exists"-declarations, or should it only be those in -type? If > it's only -type that counts, you could get checking of the atoms in -spec > declarations as well, so you don't spell an atom wrong in the spec for one > of 3 versions of a function and suddenly that atom is also implicitly > allowed. I think -type only is the right way. > > I'll see if I can change my patch to do this instead. > > /Richard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baliulia@REDACTED Tue Feb 14 14:38:09 2012 From: baliulia@REDACTED (=?UTF-8?B?SWduYXMgVnnFoW5pYXVza2Fz?=) Date: Tue, 14 Feb 2012 13:38:09 +0000 Subject: [erlang-questions] [ANN] sheriff 0.2: parse transform for type-based data validation In-Reply-To: <4F38EB62.6060908@ninenines.eu> References: <4F38EB62.6060908@ninenines.eu> Message-ID: <4F3A63C1.3040507@gmail.com> Hi, I'm confused why no-one is excited about this, this looks awesome! I am already looking forward to using this in our project. Lo?c, are there any milestones/plans regarding further developement of this? Regards, Ignas On 2012.02.13 10:52, Lo?c Hoguin wrote: > Hello! > > We just released the first beta version of the sheriff parse transform. > It allows you to validate data against types defined through the Erlang > type system. > <..> From essen@REDACTED Tue Feb 14 15:35:00 2012 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 14 Feb 2012 15:35:00 +0100 Subject: [erlang-questions] [ANN] sheriff 0.2: parse transform for type-based data validation In-Reply-To: <4F3A63C1.3040507@gmail.com> References: <4F38EB62.6060908@ninenines.eu> <4F3A63C1.3040507@gmail.com> Message-ID: <4F3A7114.3040305@ninenines.eu> In the short term fixing bugs, adding the missing iolist() and iodata() validation and a couple other less documented types. In the long term it would be nice to find a way to generate validation functions also for types found in the Erlang libs, or at least a certain subset for the most used of the lot, like the calendar module for example. I'm open to any and all suggestions at this point. On 02/14/2012 02:38 PM, Ignas Vy?niauskas wrote: > Hi, > > I'm confused why no-one is excited about this, this looks awesome! I am > already looking forward to using this in our project. > > Lo?c, are there any milestones/plans regarding further developement of this? > > Regards, > Ignas > > On 2012.02.13 10:52, Lo?c Hoguin wrote: >> Hello! >> >> We just released the first beta version of the sheriff parse transform. >> It allows you to validate data against types defined through the Erlang >> type system. >> <..> -- Lo?c Hoguin Erlang Cowboy Nine Nines From daniel.goertzen@REDACTED Tue Feb 14 15:38:37 2012 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Tue, 14 Feb 2012 08:38:37 -0600 Subject: [erlang-questions] Term to binary in a NIF In-Reply-To: References: Message-ID: Take a look at BERT ( http://bert-rpc.org/ ). BERT does almost the same thing as binary_to_term() and term_to_binary(), and there is a C++ implementation that might fit in your NIF. Dan. On Mon, Feb 13, 2012 at 10:56 AM, Matthew Evans wrote: > Hi > > I've written a NIF that takes data from an external device driver, > converts it to a term (a tuple) and uses enif_send (from a thread created > by the nif) to a specific Erlang process. > > Unfortunately on some deployments we have been forced to disable SMP in > the Linux kernel and BEAM due to a third-party driver issue. In these cases > what I have done is used enif_system_info in the NIF, and if SMP is > disabled I will send the message via a unix domain socket (I have a driver > for that) instead of enif_send. > > On the Erlang side the UDS is opened, and I use erlang:open_port to pass > the unix domain socket to the event loop. What is nice here is that I can > use the same Erlang and C code for both SMP enabled and disabled systems. > So the Erlang process would get an Erlang message like: > > {driver_result,Integer,Integer} - If SMP is enabled > > Or: > > {#Port<0.647>,{data,SomeBinary}} - If SMP is disabled > > What I would like to do is see if I can send the message as an Erlang term > to the unix domain socket using something like term_to_binary in the NIF (I > would prefer that instead of sending raw binary to Erlang with enif_send). > > Is that possible? > > Thanks > > Matt > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tristan.sloughter@REDACTED Tue Feb 14 16:24:05 2012 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Tue, 14 Feb 2012 09:24:05 -0600 Subject: [erlang-questions] [ANN] sheriff 0.2: parse transform for type-based data validation In-Reply-To: <4F3A7114.3040305@ninenines.eu> References: <4F38EB62.6060908@ninenines.eu> <4F3A63C1.3040507@gmail.com> <4F3A7114.3040305@ninenines.eu> Message-ID: It would be nice if the validation of a type could be defined as a fun. I was going to build something similar to this for validation on models in a web framework. So for validating email addresses and things like that. More complicated than a simple type. Tristan On Tue, Feb 14, 2012 at 8:35 AM, Lo?c Hoguin wrote: > In the short term fixing bugs, adding the missing iolist() and iodata() > validation and a couple other less documented types. > > In the long term it would be nice to find a way to generate validation > functions also for types found in the Erlang libs, or at least a certain > subset for the most used of the lot, like the calendar module for example. > > I'm open to any and all suggestions at this point. > > > On 02/14/2012 02:38 PM, Ignas Vy?niauskas wrote: > >> Hi, >> >> I'm confused why no-one is excited about this, this looks awesome! I am >> already looking forward to using this in our project. >> >> Lo?c, are there any milestones/plans regarding further developement of >> this? >> >> Regards, >> Ignas >> >> On 2012.02.13 10:52, Lo?c Hoguin wrote: >> >>> Hello! >>> >>> We just released the first beta version of the sheriff parse transform. >>> It allows you to validate data against types defined through the Erlang >>> type system. >>> <..> >>> >> > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > ______________________________**_________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/**listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.boudeville@REDACTED Tue Feb 14 16:31:32 2012 From: olivier.boudeville@REDACTED (Olivier BOUDEVILLE) Date: Tue, 14 Feb 2012 16:31:32 +0100 Subject: [erlang-questions] ExecutableUML and Erlang Message-ID: Hi everyone, In echo to the older thread "UML or other modeling tools" (http://erlang.2086793.n4.nabble.com/UML-or-other-modeling-tools-td3205732.html), we happened to find an Ericsson presentation about ExecutableUML (http://www.cse.chalmers.se/edu/year/2010/course/MDSD/Year2010/Lectures/ExecutableUML_for_MDA_EricssonAB.pdf), which apparently was already able to generate Erlang code. This xtUML looks like a very interesting approach; in short we are contemplating to specify some domain-specific models that are involved in a discrete simulation, based on a proper high-level, formal, implementation-agnostic pivot format, targeting a few different simulation engines, one of which expecting models to be written in C++, another one expecting them in Erlang. So it looks like if our pivot format could be a flavour of xtUML (a special, constrained, case thereof). Is there any material (documentation and/or tool) that is publicly available, so that we could test this ExecutableUML-based approach? Any opinion in terms of completeness, applicability or maturity? Thanks in advance for any information! Best regards, Olivier. --------------------------- Olivier Boudeville EDF R&D : 1, avenue du G?n?ral de Gaulle, 92140 Clamart, France D?partement SINETICS, groupe ASICS (I2A), bureau B-226 Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47 65 27 13 Ce message et toutes les pi?ces jointes (ci-apr?s le 'Message') sont ?tablis ? l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme ? sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. Si vous n'?tes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez re?u ce Message par erreur, merci de le supprimer de votre syst?me, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions ?galement d'en avertir imm?diatement l'exp?diteur par retour du message. Il est impossible de garantir que les communications par messagerie ?lectronique arrivent en temps utile, sont s?curis?es ou d?nu?es de toute erreur ou virus. ____________________________________________________ This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. E-mail communication cannot be guaranteed to be timely secure, error or virus-free. -------------- next part -------------- An HTML attachment was scrubbed... URL: From g@REDACTED Tue Feb 14 16:49:36 2012 From: g@REDACTED (Garrett Smith) Date: Tue, 14 Feb 2012 09:49:36 -0600 Subject: [erlang-questions] very large networks of erlang nodes? In-Reply-To: <4F36F152.9070002@meetinghouse.net> References: <4F36F152.9070002@meetinghouse.net> Message-ID: On Sat, Feb 11, 2012 at 4:53 PM, Miles Fidelman wrote: > Does anybody have experience running an Erlang environment consisting of > 100s, 1000s, or more nodes, spread across a network? > > I'm thinking about applications like SETI@REDACTED and folding@REDACTED, that > distribute processing tasks across huge numbers of PCs, taking advantage of > shared cycles to run long-running, data intensive jobs that can be > parallelized -- and more generally about the BOINC platform > (http://boinc.berkeley.edu). > > Seems to me that Erlang would be a great platform for such things. ?Sort of > wondering if anybody has played with anything along such lines. As has been said, the fully connected mesh practically limits you to 50 - 150 nodes, at least in my experience. You will also find that connections flap quite a bit across unreliable networks, wreaking havoc in your application if you don't design for it. We (CloudBees) have several hundred Erlang VMs running in non-distributed mode. Our main backbone for messaging is RabbitMQ, but we're actively moving away from AMQP toward 0MQ. The cost for moving outside distributed Erlang is you lose the famed "location transparency" feature that lets you seamlessly distribute your application without significant changes to your code. The upside is you can safely move well beyond the limits of a full connected mesh. I haven't tried with the hierarchical / hidden node approach that Adrian mentioned, but I'm very glad to see a number like 750! If you're talking SETI like applications, that suggests an unbounded limit. I'd definitely look at 0MQ -- you'll have enough low level flexibility in your messaging topology to tackle that hard problem. Garrett From essen@REDACTED Tue Feb 14 17:01:06 2012 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 14 Feb 2012 17:01:06 +0100 Subject: [erlang-questions] [ANN] sheriff 0.2: parse transform for type-based data validation In-Reply-To: References: <4F38EB62.6060908@ninenines.eu> <4F3A63C1.3040507@gmail.com> <4F3A7114.3040305@ninenines.eu> Message-ID: <4F3A8542.9080300@ninenines.eu> Right, forgot about that. I also want pre-defined functions for validating things like emails, URLs and others that string() or binary() types can't define. But I'm not sure this should go in sheriff proper, it could very well just be another library, perhaps generated based on RFCs or something. On 02/14/2012 04:24 PM, Tristan Sloughter wrote: > It would be nice if the validation of a type could be defined as a fun. > > I was going to build something similar to this for validation on models > in a web framework. So for validating email addresses and things like > that. More complicated than a simple type. > > Tristan > > On Tue, Feb 14, 2012 at 8:35 AM, Lo?c Hoguin > wrote: > > In the short term fixing bugs, adding the missing iolist() and > iodata() validation and a couple other less documented types. > > In the long term it would be nice to find a way to generate > validation functions also for types found in the Erlang libs, or at > least a certain subset for the most used of the lot, like the > calendar module for example. > > I'm open to any and all suggestions at this point. > > > On 02/14/2012 02:38 PM, Ignas Vy?niauskas wrote: > > Hi, > > I'm confused why no-one is excited about this, this looks > awesome! I am > already looking forward to using this in our project. > > Lo?c, are there any milestones/plans regarding further > developement of this? > > Regards, > Ignas > > On 2012.02.13 10 :52, Lo?c Hoguin wrote: > > Hello! > > We just released the first beta version of the sheriff parse > transform. > It allows you to validate data against types defined through > the Erlang > type system. > <..> > > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > _________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/__listinfo/erlang-questions > > > -- Lo?c Hoguin Erlang Cowboy Nine Nines From g@REDACTED Tue Feb 14 17:02:50 2012 From: g@REDACTED (Garrett Smith) Date: Tue, 14 Feb 2012 10:02:50 -0600 Subject: [erlang-questions] Large-scale Erlang in practice In-Reply-To: References: <17A58775-B62F-4244-8DBF-5561F87D4FBC@hates.ms> Message-ID: On Tue, Feb 7, 2012 at 11:25 AM, Tim Watson wrote: > On 7 February 2012 11:27, Mihai Balea wrote: >> >> I wish there was an "official" standalone version of gen_server2. Rabbitmq >> includes it, the Erlang rabbitmq client includes it as well, riak_core too >> plus a variety of individuals like Tim have created standalone versions >> based on one of the above. If one attempts to combine, say, riak_core with >> the rabbitmq erlang client, frustration ensues. >> > > Actually this issue (of duplicate uses of the same module name) has to do > with lack of namespace/package support and isn't so simple to solve I'm a little late to the party. The issue as I see is the amazing presumptuousness of these projects to usurp the "gen_server" prefix. At the very least, they could have appended a random hash of their project name to avoid this silly conflict :) Garrett From dmercer@REDACTED Tue Feb 14 17:14:21 2012 From: dmercer@REDACTED (David Mercer) Date: Tue, 14 Feb 2012 10:14:21 -0600 Subject: [erlang-questions] -spec Enhancement: -spec f :: ftype(). Message-ID: <00cb01cceb33$b6a66780$23f33680$@com> You know, I've always wished I could declare a function type (e.g., -type f() :: fun((arg_type1(), arg_type2()) -> return_type())) and then declare a function as conforming to that spec (e.g., -spec f1 :: f()), instead of having to repeat myself (i.e., -spec f1(arg_type1(), arg_type2()) -> return_type()). This helps when the function type is quite complicated and needs to be repeated often, and also when you have a function that takes a function with a certain spec, when you define the actual functions that can be passed to it. What do y'all think? Am I crazy? Cheers, DBM -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Tue Feb 14 20:40:39 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Tue, 14 Feb 2012 19:40:39 +0000 Subject: [erlang-questions] -spec Enhancement: -spec f :: ftype(). In-Reply-To: <00cb01cceb33$b6a66780$23f33680$@com> References: <00cb01cceb33$b6a66780$23f33680$@com> Message-ID: On 14 February 2012 16:14, David Mercer wrote: > You know, I?ve always wished I could declare a function type (e.g., -type > f() :: fun((arg_type1(), arg_type2()) -> return_type())) and then declare > a function as conforming to that spec (e.g., -spec f1 :: f()), instead of > having to repeat myself (i.e., -spec f1(arg_type1(), arg_type2()) -> > return_type()). This helps when the function type is quite complicated > and needs to be repeated often, and also when you have a function that > takes a function with a certain spec, when you define the actual functions > that can be passed to it. What do y?all think? Am I crazy?**** > > ** ** > > I wonder if, combined with custom behaviours, that might be a step in the direction of being able to provide a consistent interface to modules that offer equivalent functionality (database connectivity, config file handling, logging, etc). I'm assuming that is the primary use case, although I have a feeling you have encountered other scenarios from what you've said. I think it sounds quite handy, although presumably you'd want to export the type from a module somewhere, in which case it gets scoped to an application and it *could* get hairy trying to figure out the right place to put it. Pushing it down to the appropriate scope would then make it less appropriate to re-use across modules/components. For example, consider a concrete example specification: -opaque dbms_connection() :: #dbms_connection_handle{}. %% with some fields for vendor specific stuff -type dbms_connection_info() :: #dbms_connection_info{}. %% with some fields for vendor specific stuff -type open_connection(connection_info()) -> dbms_connection() | {error, term()}. Where should I export this from? Do I have some 'core' module (say, the primary or application callback module for the app/library) where I do this? %% in dbms.erl -include("dbms.hrl"). -export_type([open_connection/1]). And then presumably I'm going to use this in a few different places. It'd be fine, I suppose, to see something like -spec open_connection() :: dbms:open_connection() open_connection(CInfo) -> ..... But then if I start to use that across multiple applications, does it still make sense? -module(pgsql_connection). -spec open_connection() :: dbms:open_connection() open_connection(CInfo) -> ..... I suppose that reads ok, but why not just put it into a header file as a sepc and distribute that? If that's the case, I can have a library application carry the header and just use -spec instead. Any implementor can simply include the header and reference the spec: %% in application/library dbms_api/include/dbms_api.hrl -opaque dbms_connection() :: #dbms_connection_handle{}. %% with some fields for vendor specific stuff -type dbms_connection_info() :: #dbms_connection_info{}. %% with some fields for vendor specific stuff -spec open_connection(connection_info()) -> dbms_connection() | {error, term()}. %% in application dbms_pgsql/pgsql.erl -include_lib("dbms_api/include/dbms_api.hrl"). %% we 'inherit' the -spec from our library dependency on dbms_api open_connection(CInfo) -> dbms_pgsql_connection:open(CInfo). So here I'm not sure what the value is. If we're thinking about three or four functions that have the same signature in terms of input arguments and return type, but have different names, then Kostis correct me if I'm wrong but I think it'd be pretty tough to do something like that because the function name *is* part of the signature. You *could* experiment with this idea by writing a parse_transform that creates the -spec in response to a user defined annotation ( https://github.com/hyperthunk/annotations) but I'm not sure if (a) the -type and -spec data will appear during the parse_transform execution or (b) how you export a -spec from a parse_transform, or if this (b) is even possible. Another approach might be to write a build plugin (for rebar or whatever) that reads a bunch of metadata and generates the specs accordingly. Yet another approach might be to provide a hint to TypEr and let it generate the -specs for you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gianfranco.alongi@REDACTED Tue Feb 14 21:53:42 2012 From: gianfranco.alongi@REDACTED (Gianfranco Alongi) Date: Tue, 14 Feb 2012 21:53:42 +0100 Subject: [erlang-questions] wxerlang In-Reply-To: <9dc186b3-bb97-4838-9df2-ab6877bc9c43@q12g2000yqg.googlegroups.com> References: <931131ce-e710-47bb-8cc5-fd1545da318a@t5g2000yqk.googlegroups.com> <9dc186b3-bb97-4838-9df2-ab6877bc9c43@q12g2000yqg.googlegroups.com> Message-ID: I just thought I would throw this out there https://github.com/Gianfrancoalongi/wx-graphics this was mainly worked on during the long tube rides in London between work and home. So take it for what it is. The idea was to make a lib for using WX to develop sprite based rpg-games. I had it lying around on my drive and thought it could inspire someone. /G On Sat, Feb 11, 2012 at 12:07 AM, eigenfunction wrote: > WOW, wx:demo() has a lot of stuffs. That's exactly what i was looking > for. Thanks lot. > > On Feb 10, 4:09?pm, Wes James wrote: >> On Fri, Feb 10, 2012 at 3:38 AM, eigenfunction wrote: >> > Is there any comprehensive tutorial out there about wxerlang? Or do i >> > have to go the wxWidget route? >> > The only thing i could find ishttp://wxerlang.dougedmunds.com. >> > Any idea? >> >> You may want to run wx:demo() to see examples and also look at the >> code for the demo. >> >> -wes >> _______________________________________________ >> erlang-questions mailing list >> erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ok@REDACTED Wed Feb 15 00:16:09 2012 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 15 Feb 2012 12:16:09 +1300 Subject: [erlang-questions] [ANN] sheriff 0.2: parse transform for type-based data validation In-Reply-To: <4F3A63C1.3040507@gmail.com> References: <4F38EB62.6060908@ninenines.eu> <4F3A63C1.3040507@gmail.com> Message-ID: <6C7F7392-F927-4417-A688-5E701BB0D09B@cs.otago.ac.nz> On 15/02/2012, at 2:38 AM, Ignas Vy?niauskas wrote: > I'm confused why no-one is excited about this, this looks awesome! Just because I didn't write anything about it doesn't mean I'm not impressed. (Of course, shire-reeves are concerned with crimes; someone who examines your conformance is surely an inquisitor.) From nem@REDACTED Wed Feb 15 00:21:13 2012 From: nem@REDACTED (Geoff Cant) Date: Tue, 14 Feb 2012 15:21:13 -0800 Subject: [erlang-questions] [ANN] sheriff 0.2: parse transform for type-based data validation In-Reply-To: <6C7F7392-F927-4417-A688-5E701BB0D09B@cs.otago.ac.nz> References: <4F38EB62.6060908@ninenines.eu> <4F3A63C1.3040507@gmail.com> <6C7F7392-F927-4417-A688-5E701BB0D09B@cs.otago.ac.nz> Message-ID: <6403E83E-10E8-407E-ACAF-05EEABC55FBB@erlang.geek.nz> On 2012-02-14, at 15:16 , Richard O'Keefe wrote: > > On 15/02/2012, at 2:38 AM, Ignas Vy?niauskas wrote: >> I'm confused why no-one is excited about this, this looks awesome! > > Just because I didn't write anything about it doesn't mean I'm not > impressed. (Of course, shire-reeves are concerned with crimes; > someone who examines your conformance is surely an inquisitor.) No-one expects the auto-generated inquisition/1. But we are very grateful that this now exists. Cheers Lo?c! -- Geoff Cant From tristan.sloughter@REDACTED Wed Feb 15 00:23:38 2012 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Tue, 14 Feb 2012 17:23:38 -0600 Subject: [erlang-questions] [ANN] sheriff 0.2: parse transform for type-based data validation In-Reply-To: <4F3A8542.9080300@ninenines.eu> References: <4F38EB62.6060908@ninenines.eu> <4F3A63C1.3040507@gmail.com> <4F3A7114.3040305@ninenines.eu> <4F3A8542.9080300@ninenines.eu> Message-ID: Hmm, yeah. And I should have mentioned I modified Ulf's exprecs to have slightly different syntax but the main thing was to also use types in records to add calls to convert (which I may change to check...) for setting each attribute of a record. https://github.com/tsloughter/maru/blob/master/lib/maru_models/src/maru_model_transform.erl Add support for validating email addresses and more complicated types is in my plan for dealing with that model creation. But no reason to have it not be a secondary piece of sheriff now :) Tristan On Tue, Feb 14, 2012 at 10:01 AM, Lo?c Hoguin wrote: > Right, forgot about that. I also want pre-defined functions for validating > things like emails, URLs and others that string() or binary() types can't > define. But I'm not sure this should go in sheriff proper, it could very > well just be another library, perhaps generated based on RFCs or something. > > > On 02/14/2012 04:24 PM, Tristan Sloughter wrote: > >> It would be nice if the validation of a type could be defined as a fun. >> >> I was going to build something similar to this for validation on models >> in a web framework. So for validating email addresses and things like >> that. More complicated than a simple type. >> >> Tristan >> >> On Tue, Feb 14, 2012 at 8:35 AM, Lo?c Hoguin > > wrote: >> >> In the short term fixing bugs, adding the missing iolist() and >> iodata() validation and a couple other less documented types. >> >> In the long term it would be nice to find a way to generate >> validation functions also for types found in the Erlang libs, or at >> least a certain subset for the most used of the lot, like the >> calendar module for example. >> >> I'm open to any and all suggestions at this point. >> >> >> On 02/14/2012 02:38 PM, Ignas Vy?niauskas wrote: >> >> Hi, >> >> I'm confused why no-one is excited about this, this looks >> awesome! I am >> already looking forward to using this in our project. >> >> Lo?c, are there any milestones/plans regarding further >> developement of this? >> >> Regards, >> Ignas >> >> On 2012.02.13 10 :52, Lo?c Hoguin wrote: >> >> Hello! >> >> We just released the first beta version of the sheriff parse >> transform. >> It allows you to validate data against types defined through >> the Erlang >> type system. >> <..> >> >> >> >> -- >> Lo?c Hoguin >> Erlang Cowboy >> Nine Nines >> ______________________________**___________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> > >> http://erlang.org/mailman/__**listinfo/erlang-questions >> >> > >> >> >> > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Wed Feb 15 00:27:37 2012 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 15 Feb 2012 12:27:37 +1300 Subject: [erlang-questions] very large networks of erlang nodes? In-Reply-To: References: <4F36F152.9070002@meetinghouse.net> Message-ID: <8981237E-215C-472E-8619-6E2F6DD8FFC9@cs.otago.ac.nz> On 15/02/2012, at 4:49 AM, Garrett Smith wrote: > On Sat, Feb 11, 2012 at 4:53 PM, Miles Fidelman > wrote: >> Does anybody have experience running an Erlang environment consisting of >> 100s, 1000s, or more nodes, spread across a network? > As has been said, the fully connected mesh practically limits you to > 50 - 150 nodes, at least in my experience. You will also find that > connections flap quite a bit across unreliable networks, wreaking > havoc in your application if you don't design for it. What would happen if you had 1000 nodes in a box with a reliable but not ultrafast interconnect? I'm not talking about multicore here, although 16 Tileras in a smallish box doesn't seem unlikely any more, but say 1000 separate-physical-address-space nodes connected as a tree or a hypercube or something. Could distributed Erlang be set up in some hierarchical fashion? It seems to me that there are three issues: - number of points of authentication (network: many; cluster-in-a-box: one) - number of eavesdropping points (network: many; cluster-in-a-box: one) - number of communicating devices (network: many; cluster-in-a-box: many) and that just thinking in terms of authentication and eavesdropping, distributed Erlang makes perfect sense for cluster-in-a-box, IF it works at that scale. The Magnus project that Fergus O'Brien was involved with would have been using Erlang in this way, I believe. From cbenac@REDACTED Wed Feb 15 11:08:17 2012 From: cbenac@REDACTED (Clara Benac Earle) Date: Wed, 15 Feb 2012 11:08:17 +0100 Subject: [erlang-questions] Madrid Erlounge 8th of March Message-ID: <4F3B8411.4020700@fi.upm.es> Dear all, We will meet up for the 4th Madrid Erlounge the 8th of March. In principle the talk will be in Spanish but please let us know if anybody planning to attend prefers English and then we will switch to Spanglish :-) Everybody welcome! Clara ------------------------------------------------------------------------------------------- Hola a todos, Anunciamos la pr?xima Madrid Erlounge. *Cu?ndo:* 8 de Marzo 2012, charla a las 19:30 *D?nde:* Sala de Grados (1? planta Facultad de Inform?tica, Universidad Complutense de Madrid) (http://gpd.sip.ucm.es/fraguas/wflp06/campus_ucm.jpg) *Qui?n:* Manuel ?ngel Rubio (alias Bombadil) Manuel ?ngel trabaja en el departamento de I+D de Jet Multimedia Espa?a (http://www.jetmultimedia.es), como gerente de desarrollos de I+D ?rea de voz. Desde 2008 usan Erlang para el desarrollo de soluciones escalables y para telefon?a con ?xito, consiguiendo desarrollos como un ACD con m?s de 200 agentes (algo totalmente imposible con otros entornos) y sistemas de gesti?n de llamadas salientes de hasta 20 mil llamadas concurrentes. *Qu?:* Gesti?n de Llamadas con Erlang/OTP La charla va encauzada a mostrar un ejemplo, en propia piel, del uso de Erlang/OTP en el entorno de la prestaci?n de servicios por Internet. En este caso, de telefon?a, donde se ver? c?mo se di? soluci?n a la gesti?n de llamadas miles de llamadas concurrentes con sistemas que en principio solo soportaban decenas. Por favor m?ndadme un correo si pens?is venir para que sepa m?s o menos cuanta gente se apunta. ?Nos vemos! Clara -------------- next part -------------- An HTML attachment was scrubbed... URL: From yoursurrogategod@REDACTED Wed Feb 15 14:26:23 2012 From: yoursurrogategod@REDACTED (Yves S. Garret) Date: Wed, 15 Feb 2012 08:26:23 -0500 Subject: [erlang-questions] wxWidgets and Erlang Message-ID: Hi all, is this GUI for Erlang interface still going strong or is it dead? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingo.jaeckel@REDACTED Wed Feb 15 15:10:53 2012 From: ingo.jaeckel@REDACTED (Ingo Jaeckel) Date: Wed, 15 Feb 2012 09:10:53 -0500 Subject: [erlang-questions] Erlang User Groups and Events in Canada? Message-ID: Hi, which user groups exist and what Erlang-events (conferences, workshops, meetings) take place in Canada? Specifically, in southern Ontario? Thanks, Ingo From spawn.think@REDACTED Wed Feb 15 15:33:25 2012 From: spawn.think@REDACTED (Ahmed Omar) Date: Wed, 15 Feb 2012 15:33:25 +0100 Subject: [erlang-questions] Erlang User Groups and Events in Canada? In-Reply-To: References: Message-ID: Check EUG-Canada http://www.linkedin.com/groups?gid=3838220&sharedKey=2EA88A5A1985&trk=anetsrch_name&goback=%2Eanh_90878_1329316334910_1 On Wed, Feb 15, 2012 at 3:10 PM, Ingo Jaeckel wrote: > Hi, > > which user groups exist and what Erlang-events (conferences, > workshops, meetings) take place in Canada? Specifically, in southern > Ontario? > > Thanks, > Ingo > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Wed Feb 15 15:34:11 2012 From: spawn.think@REDACTED (Ahmed Omar) Date: Wed, 15 Feb 2012 15:34:11 +0100 Subject: [erlang-questions] Erlang User Groups and Events in Canada? In-Reply-To: References: Message-ID: Sorry the correct link is http://www.linkedin.com/groups?gid=3838220 On Wed, Feb 15, 2012 at 3:33 PM, Ahmed Omar wrote: > > http://www.linkedin.com/groups?gid=3838220&sharedKey=2EA88A5A1985&trk=anetsrch_name&goback=%2Eanh_90878_1329316334910_1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmercer@REDACTED Wed Feb 15 15:43:18 2012 From: dmercer@REDACTED (David Mercer) Date: Wed, 15 Feb 2012 08:43:18 -0600 Subject: [erlang-questions] -spec Enhancement: -spec f :: ftype(). In-Reply-To: References: <00cb01cceb33$b6a66780$23f33680$@com> Message-ID: <011401ccebf0$293db4d0$7bb91e70$@com> Yes, custom behaviors is definitely one of the primary use cases, though, for me , any time you have functions that take functions as arguments, it would be nice to be able to specify a function as having a certain type, rather than having to repeat yourself in the -spec. From: Tim Watson [mailto:watson.timothy@REDACTED] Sent: Tuesday, February 14, 2012 1:41 PM To: David Mercer Cc: erlang-questions@REDACTED Subject: Re: [erlang-questions] -spec Enhancement: -spec f :: ftype(). On 14 February 2012 16:14, David Mercer wrote: You know, I've always wished I could declare a function type (e.g., -type f() :: fun((arg_type1(), arg_type2()) -> return_type())) and then declare a function as conforming to that spec (e.g., -spec f1 :: f()), instead of having to repeat myself (i.e., -spec f1(arg_type1(), arg_type2()) -> return_type()). This helps when the function type is quite complicated and needs to be repeated often, and also when you have a function that takes a function with a certain spec, when you define the actual functions that can be passed to it. What do y'all think? Am I crazy? I wonder if, combined with custom behaviours, that might be a step in the direction of being able to provide a consistent interface to modules that offer equivalent functionality (database connectivity, config file handling, logging, etc). I'm assuming that is the primary use case, although I have a feeling you have encountered other scenarios from what you've said. I think it sounds quite handy, although presumably you'd want to export the type from a module somewhere, in which case it gets scoped to an application and it *could* get hairy trying to figure out the right place to put it. Pushing it down to the appropriate scope would then make it less appropriate to re-use across modules/components. For example, consider a concrete example specification: -opaque dbms_connection() :: #dbms_connection_handle{}. %% with some fields for vendor specific stuff -type dbms_connection_info() :: #dbms_connection_info{}. %% with some fields for vendor specific stuff -type open_connection(connection_info()) -> dbms_connection() | {error, term()}. Where should I export this from? Do I have some 'core' module (say, the primary or application callback module for the app/library) where I do this? %% in dbms.erl -include("dbms.hrl"). -export_type([open_connection/1]). And then presumably I'm going to use this in a few different places. It'd be fine, I suppose, to see something like -spec open_connection() :: dbms:open_connection() open_connection(CInfo) -> ..... But then if I start to use that across multiple applications, does it still make sense? -module(pgsql_connection). -spec open_connection() :: dbms:open_connection() open_connection(CInfo) -> ..... I suppose that reads ok, but why not just put it into a header file as a sepc and distribute that? If that's the case, I can have a library application carry the header and just use -spec instead. Any implementor can simply include the header and reference the spec: %% in application/library dbms_api/include/dbms_api.hrl -opaque dbms_connection() :: #dbms_connection_handle{}. %% with some fields for vendor specific stuff -type dbms_connection_info() :: #dbms_connection_info{}. %% with some fields for vendor specific stuff -spec open_connection(connection_info()) -> dbms_connection() | {error, term()}. %% in application dbms_pgsql/pgsql.erl -include_lib("dbms_api/include/dbms_api.hrl"). %% we 'inherit' the -spec from our library dependency on dbms_api open_connection(CInfo) -> dbms_pgsql_connection:open(CInfo). So here I'm not sure what the value is. If we're thinking about three or four functions that have the same signature in terms of input arguments and return type, but have different names, then Kostis correct me if I'm wrong but I think it'd be pretty tough to do something like that because the function name *is* part of the signature. You *could* experiment with this idea by writing a parse_transform that creates the -spec in response to a user defined annotation (https://github.com/hyperthunk/annotations) but I'm not sure if (a) the -type and -spec data will appear during the parse_transform execution or (b) how you export a -spec from a parse_transform, or if this (b) is even possible. Another approach might be to write a build plugin (for rebar or whatever) that reads a bunch of metadata and generates the specs accordingly. Yet another approach might be to provide a hint to TypEr and let it generate the -specs for you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yoursurrogategod@REDACTED Wed Feb 15 16:13:31 2012 From: yoursurrogategod@REDACTED (Yves S. Garret) Date: Wed, 15 Feb 2012 10:13:31 -0500 Subject: [erlang-questions] wxWidgets and Erlang In-Reply-To: References: Message-ID: Rather, are there any projects out there to make GUIs with Erlang that are supported? On Wed, Feb 15, 2012 at 8:26 AM, Yves S. Garret wrote: > Hi all, is this GUI for Erlang interface still going strong or is it dead? -------------- next part -------------- An HTML attachment was scrubbed... URL: From peerst@REDACTED Wed Feb 15 16:22:35 2012 From: peerst@REDACTED (Peer Stritzinger) Date: Wed, 15 Feb 2012 16:22:35 +0100 Subject: [erlang-questions] Cross building Erlang as a lib for running on a embedded real time executive Message-ID: Hi, I'm in the process of creating a Erlang port for the RTEMS realtime system (www.rtems.org). RTEMS is a real time executive meaning there are no Unix like processes but only threads. Currently I have succeeded cross building until it wants to link the beam.smp executable which aborts with a error about missing dl* reference (different story since there is no dynamic linking on RTEMS this has to go probably). What I want to do here is not linking a beam executable but rather a libbeam.a that I could link to the RTEMS executable and initialize manually. * What is the best way to cross-build a lib without a main() function? * Am I right building the smp variant even if I don't intend to use smp? I want to use threads from NIF's however. The results of this work BTW will be submitted back or provided as BSD licensed add on if necessary. I think this will be pretty useful for Erlang use on that need some hard-realtime and hardware access (where RTEMS is very good at) combining this with the flexibility and soft-realtime features of Erlang (which will be even more responsive since it can be run basically on the bare hardware without OS preemption (except for hard-realtime things which will probably run at a higher priority that the beam thread). Cheers, -- Peer From mattevans123@REDACTED Wed Feb 15 17:39:46 2012 From: mattevans123@REDACTED (Matthew Evans) Date: Wed, 15 Feb 2012 11:39:46 -0500 Subject: [erlang-questions] Compile Erlang as standalone Message-ID: Hi, We have a situation where we are using Maven as a project management system for Java, Erlang and C. I would like to allow the Java and C developers to do a build of the whole system including the Erlang sources. Can they do that without downloading and installing Erlang? In other-words can "erlc" be made into a standalone library (it seems like erlc needs erl)? NOTE: They will not need to build the Erlang/OTP modules, just the private modules used in the project. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From knutin@REDACTED Wed Feb 15 17:53:28 2012 From: knutin@REDACTED (Knut Nesheim) Date: Wed, 15 Feb 2012 17:53:28 +0100 Subject: [erlang-questions] VM using only 2 out of 8 schedulers available Message-ID: Dear list, >From time to time we see the VM using only some of the available cores. Typically 2 or 4 out of 8 available cores will be busy, while the others are not used at all. From 'top' and 'htop' we see only some cores being used. We are running the halfword emulator on 8 core machines and the VM is correctly reporting the number of schedulers and the underlying topology. The nodes are utilizing roughly 25% of each of the 8 cores during normal operation. This problem appeared again today and we still have the process running if anyone has any ideas for how to debug the issue. We are on Ubuntu 10.04 LTS, 2.6.32-342-ec2, 64bit, R14B04 with the halfword emulator. The only NIF library we are using is jiffy. Regards Knut From eriksoe@REDACTED Wed Feb 15 19:43:59 2012 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Wed, 15 Feb 2012 19:43:59 +0100 Subject: [erlang-questions] Pattern matching in guards - status? Message-ID: Hello - I was considering writing an EEP for adding the possibility of having pattern matching in guards (as well as a test in expressions), when I noticed hints around the 'net that this had already been discussed at some point. In particular, EEP-29[1] mentions it: - Stage 0: Allow pattern matching in guards. This is the subject of another EEP, as it is desirable in itself. This MUST be implemented first before implementing Stage 1, because that's what we want inlinable pattern calls to expand to. as well as this post[2]: *Robert Virding> *No, you cannot do pattern matching in guards. It has been discussed and would be possible, but for now you can't. Does anyone know what the status is of this idea? I see no existing EEP for it, but that of course doesn't mean that it isn't done elsewhere - or has for some reason been dropped. Thanks, Erik S?e S?rensen PS: For what it's worth: EEP-29 goes on to say this in the "reference implementation" section: Given stage 0, this stage 1 is within my knowledge and abilities, but I don't understand the Erlang VM well enough to do stage 0. >From my knowledge of the Erlang VM and in particular the byte code format, I'm reasonably certain that at least for the semantics I have in mind, no VM changes are needed -- i.e., only compiler and shell will need to be extended. [1] http://www.erlang.org/eeps/eep-0029.html [2] http://erlang.org/pipermail/erlang-questions/2009-December/048562.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Wed Feb 15 21:23:40 2012 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Wed, 15 Feb 2012 22:23:40 +0200 Subject: [erlang-questions] Compile Erlang as standalone In-Reply-To: References: Message-ID: Hello, systools allows to assemble a standalone application, see systools:make_tar http://erldocs.com/R14B02/sasl/systools.html?i=0&search=systo#undefined but this would affect you build procedure. You have to deliver a erlang app tarball to your C/Java developers and they would not be able to rebuild Erlang sources. - Dmitry On Feb 15, 2012, at 6:39 PM, Matthew Evans wrote: > Hi, > > We have a situation where we are using Maven as a project management system for Java, Erlang and C. > > I would like to allow the Java and C developers to do a build of the whole system including the Erlang sources. > > Can they do that without downloading and installing Erlang? In other-words can "erlc" be made into a standalone library (it seems like erlc needs erl)? > > NOTE: They will not need to build the Erlang/OTP modules, just the private modules used in the project. > > Matt > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Wed Feb 15 22:15:46 2012 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Wed, 15 Feb 2012 23:15:46 +0200 Subject: [erlang-questions] default gateway Message-ID: Hello, do you have any idea, how to get a default gateway using erlang native code? I know how to handle it through external program - Dmitry From theflowerstars@REDACTED Wed Feb 15 22:16:31 2012 From: theflowerstars@REDACTED (flowerstars) Date: Wed, 15 Feb 2012 13:16:31 -0800 (PST) Subject: [erlang-questions] Question about using ETS, PUT/GET Message-ID: <1329340591686-4392011.post@n4.nabble.com> Hi everyone, I am working on developing modules on ejabberd. I tried to use ETS in start/2. The codes are following: ets:new(table_name, [named_table, public, bag]), ets:insert(table_name, {num, 999}), I use "ets:lookup(table_name, num)," in another function within the same file to read the value "999". The issue is I cannot start ejabberd, according to the log, when the second time this module starts, ejabberd tells there is an argument error. Actually, I just want to share some variables. I used to use PUT/2 and GET/1, I use "put(key, Value)" in start/2, and use "get(key)" in another function within one file. However, what I got is "undefined". Are they in the same process? Any help is appreciated!! Thanks a lot! -- View this message in context: http://erlang.2086793.n4.nabble.com/Question-about-using-ETS-PUT-GET-tp4392011p4392011.html Sent from the Erlang Questions mailing list archive at Nabble.com. From dmkolesnikov@REDACTED Wed Feb 15 22:22:18 2012 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Wed, 15 Feb 2012 23:22:18 +0200 Subject: [erlang-questions] Question about using ETS, PUT/GET In-Reply-To: <1329340591686-4392011.post@n4.nabble.com> References: <1329340591686-4392011.post@n4.nabble.com> Message-ID: <5A98F765-BBBF-4FC7-9AEA-0FC6A5236414@gmail.com> Hello, > The issue is I cannot start ejabberd, according to the log, when the second > time this module starts, ejabberd tells there is an argument error. this is due to your named ets table. When you stat this module second time the table_name is exists and ets throws an error. You have to re-shake you app in the way that only one copy of ets is created. - Dmitry On Feb 15, 2012, at 11:16 PM, flowerstars wrote: > Hi everyone, > > I am working on developing modules on ejabberd. I tried to use ETS in > start/2. The codes are following: > > ets:new(table_name, [named_table, public, bag]), > ets:insert(table_name, {num, 999}), > > I use "ets:lookup(table_name, num)," in another function within the same > file to read the value "999". > > The issue is I cannot start ejabberd, according to the log, when the second > time this module starts, ejabberd tells there is an argument error. > > Actually, I just want to share some variables. I used to use PUT/2 and > GET/1, I use "put(key, Value)" in start/2, and use "get(key)" in another > function within one file. However, what I got is "undefined". Are they in > the same process? > > Any help is appreciated!! > > Thanks a lot! > > > -- > View this message in context: http://erlang.2086793.n4.nabble.com/Question-about-using-ETS-PUT-GET-tp4392011p4392011.html > Sent from the Erlang Questions mailing list archive at Nabble.com. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From gleber.p@REDACTED Wed Feb 15 22:22:26 2012 From: gleber.p@REDACTED (Gleb Peregud) Date: Wed, 15 Feb 2012 22:22:26 +0100 Subject: [erlang-questions] default gateway In-Reply-To: References: Message-ID: On Wed, Feb 15, 2012 at 22:15, Dmitry Kolesnikov wrote: > Hello, > > do you have any idea, how to get a default gateway using erlang native code? > I know how to handle it through external program A bit convoluted solution would be to send ICMP ping to "the Internet" with TTL equal to one and receive a response. Of course it can get messy in multiple ways, but it'll be "native" Erlang code. Are you interested in cross-platform solution? Or do you want to avoid spawning port (or using os:cmd) ? Best, Gleb Peregud From dmkolesnikov@REDACTED Wed Feb 15 22:27:30 2012 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Wed, 15 Feb 2012 23:27:30 +0200 Subject: [erlang-questions] default gateway In-Reply-To: References: Message-ID: Hello, thanks! I am in the middle of os:cmd implementation. It looks ugly for me :-) ICMP ping sound reasonable but I've never tried a RAW sockets in erlang. Do you have any hints about them? - Dmitry On Feb 15, 2012, at 11:22 PM, Gleb Peregud wrote: > On Wed, Feb 15, 2012 at 22:15, Dmitry Kolesnikov wrote: >> Hello, >> >> do you have any idea, how to get a default gateway using erlang native code? >> I know how to handle it through external program > > A bit convoluted solution would be to send ICMP ping to "the Internet" > with TTL equal to one and receive a response. Of course it can get > messy in multiple ways, but it'll be "native" Erlang code. > > Are you interested in cross-platform solution? Or do you want to avoid > spawning port (or using os:cmd) ? > > Best, > Gleb Peregud From gleber.p@REDACTED Wed Feb 15 22:30:12 2012 From: gleber.p@REDACTED (Gleb Peregud) Date: Wed, 15 Feb 2012 22:30:12 +0100 Subject: [erlang-questions] default gateway In-Reply-To: References: Message-ID: On Wed, Feb 15, 2012 at 22:27, Dmitry Kolesnikov wrote: > Hello, > > thanks! > I am in the middle of os:cmd implementation. It looks ugly for me :-) > ICMP ping sound reasonable but I've never tried a RAW sockets in erlang. > Do you have any hints about them? No hints. Just a ready solution by Michael Santos: https://github.com/msantos/gen_icmp Michael has other cool repositories in his github! From dmkolesnikov@REDACTED Wed Feb 15 22:37:24 2012 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Wed, 15 Feb 2012 23:37:24 +0200 Subject: [erlang-questions] default gateway In-Reply-To: References: Message-ID: Yes, just went through. It looks cool but it requires https://github.com/msantos/procket I do not what to mess-up with long dependencies chain for simple issue I am going with os:cmd :-) Thanks! - Dmitry On Feb 15, 2012, at 11:30 PM, Gleb Peregud wrote: > On Wed, Feb 15, 2012 at 22:27, Dmitry Kolesnikov wrote: >> Hello, >> >> thanks! >> I am in the middle of os:cmd implementation. It looks ugly for me :-) >> ICMP ping sound reasonable but I've never tried a RAW sockets in erlang. >> Do you have any hints about them? > > No hints. Just a ready solution by Michael Santos: > > https://github.com/msantos/gen_icmp > > Michael has other cool repositories in his github! From watson.timothy@REDACTED Wed Feb 15 23:53:00 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Wed, 15 Feb 2012 22:53:00 +0000 Subject: [erlang-questions] Compile Erlang as standalone In-Reply-To: References: Message-ID: A *release* will contain the erts libraries for the machine on which is was built. If you're all working in a common environment, the easiest thing to do is generate a release (which IIRC the maven-erlang-plugin does nicely) and have this pushed into your artefact repository (Nexus or equivalent). Providing the release is configured to include erts then the dependency, once pulled/installed into the users local .m2 repository is effectively standalone (and can be used in integration tests, for example, using the maven-failsafe-plugin). We had to do some jiggery-pokery with the maven-assembly-plugin to get this working, but I suspect the maven-erlang-plugin might have moved on since then (and I've not looked at that bit of the build for a long while, as I've since moved a lot of stuff to rebar + rebar_dist_plugin and a custom script which deploys the 'artefacts' to nexus by hand using the REST api). Not really sure (from the sounds of things) if that's what you're looking for, but I think it's as close as you're likely to get to not needing an Erlang install. Of course it'll fail miserably if your developers work across multiple os/architectures. On 15 February 2012 16:39, Matthew Evans wrote: > Hi, > > We have a situation where we are using Maven as a project management > system for Java, Erlang and C. > > I would like to allow the Java and C developers to do a build of the whole > system including the Erlang sources. > > Can they do that without downloading and installing Erlang? > In other-words can "erlc" be made into a standalone library (it seems like > erlc needs erl)? > > NOTE: They will not need to build the Erlang/OTP modules, just the private > modules used in the project. > > Matt > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peerst@REDACTED Thu Feb 16 02:29:01 2012 From: peerst@REDACTED (Peer Stritzinger) Date: Thu, 16 Feb 2012 02:29:01 +0100 Subject: [erlang-questions] (no subject) Message-ID: Several hour ago I sent a patch fetch request to the erlang-patches mailing list. However I don't see it appear in the archive. Do I have to subscribe to erlang-patches in order to be able to post? Cheers -- Peer From peerst@REDACTED Thu Feb 16 02:31:49 2012 From: peerst@REDACTED (Peer Stritzinger) Date: Thu, 16 Feb 2012 02:31:49 +0100 Subject: [erlang-questions] Do I need to be subscriber of erlang-patches in order to post? Message-ID: Sorry forgot the Subject on my last post: Several hour ago I sent a patch fetch request to the erlang-patches mailing list. However I don't see it appear in the archive. Do I have to subscribe to erlang-patches in order to be able to post? Cheers -- Peer From vinodhg@REDACTED Thu Feb 16 06:04:32 2012 From: vinodhg@REDACTED (Vinod H G) Date: Thu, 16 Feb 2012 10:34:32 +0530 Subject: [erlang-questions] Starting erl with unicode hostname In-Reply-To: <-2242150019508365735@unknownmsgid> References: <-2242150019508365735@unknownmsgid> Message-ID: IDNA encoded hostname works perfectly fine. Thanks Dmitry. Unicode is not a standard in hostname but windows supports it giving warning. Just wanted to know whether Erlang also supports it. Thanks for the info. On Mon, Feb 13, 2012 at 1:05 PM, dmitry kolesnikov wrote: > Hello, > > Have you tried IDNA encoding instead of Unicode? > > Best Regards, > Dmitry >-|-|-*> > > > On 13.2.2012, at 8.16, Vinod H G wrote: > >> I agree hostname is an atom, but os hostname may have unicode right. >> >> Ex: >> >> 'host_with_?_or_?' >> >> erl -name 'node@REDACTED?_or_?' >> or >> erl -sname node >> >> These will give invalid node name error. >> >> >> On Fri, Feb 10, 2012 at 2:20 PM, Michael Uvarov wrote: >>> >>> Hostname is an atom. >> >> >> >> >> -- >> >> Thanks & Regards, >> Vinod H. G. >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions -- Thanks & Regards, Vinod H. G. From gleber.p@REDACTED Thu Feb 16 07:04:34 2012 From: gleber.p@REDACTED (Gleb Peregud) Date: Thu, 16 Feb 2012 07:04:34 +0100 Subject: [erlang-questions] Do I need to be subscriber of erlang-patches in order to post? In-Reply-To: References: Message-ID: I just realized, that the same happened to me two days ago, Eve though I am subscribed to that mailing list On Feb 16, 2012 2:31 AM, "Peer Stritzinger" wrote: > Sorry forgot the Subject on my last post: > > Several hour ago I sent a patch fetch request to the erlang-patches > mailing list. > > However I don't see it appear in the archive. > > Do I have to subscribe to erlang-patches in order to be able to post? > > Cheers > -- Peer > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth.lundin@REDACTED Thu Feb 16 08:01:14 2012 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Thu, 16 Feb 2012 08:01:14 +0100 Subject: [erlang-questions] VM using only 2 out of 8 schedulers available In-Reply-To: References: Message-ID: What is your real problem except that there is no reported cpu load on some of the cores? When there is low load on the system i.e. when there are too few runnable Erlang processes some of the schedulers will automatically be put as idle letting the remaining schedulers run all processes. When the load increases the idle schedulers will be taken into service again. Each scheduler normally runs on one processor core. Can this explain what you have observed? /Kenneth Erlang/OTP Ericsson Den 15 feb 2012 17:53 skrev "Knut Nesheim" : > Dear list, > > From time to time we see the VM using only some of the available > cores. Typically 2 or 4 out of 8 available cores will be busy, while > the others are not used at all. From 'top' and 'htop' we see only some > cores being used. > > We are running the halfword emulator on 8 core machines and the VM is > correctly reporting the number of schedulers and the underlying > topology. The nodes are utilizing roughly 25% of each of the 8 cores > during normal operation. > > This problem appeared again today and we still have the process > running if anyone has any ideas for how to debug the issue. > > We are on Ubuntu 10.04 LTS, 2.6.32-342-ec2, 64bit, R14B04 with the > halfword emulator. The only NIF library we are using is jiffy. > > Regards > Knut > _______________________________________________ > 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 Feb 16 02:32:54 2012 From: gumm@REDACTED (Jesse Gumm) Date: Wed, 15 Feb 2012 19:32:54 -0600 Subject: [erlang-questions] Do I need to be subscriber of erlang-patches in order to post? In-Reply-To: References: Message-ID: If the patches mailing list is like this one, then yes, you'll have to subscribe first. -Jesse On Wed, Feb 15, 2012 at 7:31 PM, Peer Stritzinger wrote: > Sorry forgot the Subject on my last post: > > Several hour ago I sent a patch fetch request to the erlang-patches > mailing list. > > However I don't see it appear in the archive. > > Do I have to subscribe to erlang-patches in order to be able to post? > > Cheers > -- Peer > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Jesse Gumm Sigma Star Systems 414.940.4866 gumm@REDACTED http://www.sigma-star.com From gleber.p@REDACTED Thu Feb 16 09:34:39 2012 From: gleber.p@REDACTED (Gleb Peregud) Date: Thu, 16 Feb 2012 09:34:39 +0100 Subject: [erlang-questions] Do I need to be subscriber of erlang-patches in order to post? In-Reply-To: References: Message-ID: On Thu, Feb 16, 2012 at 02:32, Jesse Gumm wrote: > If the patches mailing list is like this one, then yes, you'll have to > subscribe first. I see. I double checked it and it turned out that I was not subscribed. This is weird, since I'm sure I have been subscribed to it for a long time and I don't recall unsubscribing From ulf@REDACTED Thu Feb 16 09:48:33 2012 From: ulf@REDACTED (Ulf Wiger) Date: Thu, 16 Feb 2012 09:48:33 +0100 Subject: [erlang-questions] ExecutableUML and Erlang In-Reply-To: References: Message-ID: <1525C7CD-4DA3-4EA6-92E6-6D1662723330@feuerlabs.com> Hmm? since it has been presented in public, I guess I can also add that I've seen the Erlang code generated from that model, and it's not something that I would ever want to use in production. :) There was some discussion about whether the code could be 'trivially optimized', but I think it should be demonstrated first. The code pretty much looked like a naive mapping from an OO design onto Erlang. I was involved in quite some discussion about the point of doing this in the first place. The focus area for this approach is Hardware-Software co-design, and in that narrow niche, it really seems like a useful idea. However, it's a stretch to imagine that one would need to be open to generating target code as either e.g. VHDL or Erlang - at least from a target-agnostic high-level design. Another point of discussion was why an Erlang programmer would want to bother with Executable UML in the first place, as it doesn't offer more powerful abstractions than Erlang already has - just *different* abstractions, which is not necessarily a good thing. It got to the point where I was invited to meet one of the chief designers of BridgePoint, so that he could convince me. Interestingly, he turned out to be a secret fan of Functional Programming and Erlang, and we ended up agreeing that Executable UML and Erlang were at roughly the same abstraction level, and there was no benefit for the Erlang programmer to first architect the system using one paradigm, and then make a sideways move into another paradigm. He did try to argue that Erlang programmers might still find the Schlaer&Mellor analysis domains useful, but I thought that the mass of unwanted baggage would cancel out any such benefit. Having said this, I don't want to take away from the other work done behind this. It's impressive. I just don't think that throwing Erlang into the mix helps their case, nor that of the Erlang programmers. Also, this is of course my personal opinion - I freely admit that I have not tried it out for real. BR, Ulf W On 14 Feb 2012, at 16:31, Olivier BOUDEVILLE wrote: > > Hi everyone, > > In echo to the older thread "UML or other modeling tools" (http://erlang.2086793.n4.nabble.com/UML-or-other-modeling-tools-td3205732.html), we happened to find an Ericsson presentation about ExecutableUML (http://www.cse.chalmers.se/edu/year/2010/course/MDSD/Year2010/Lectures/ExecutableUML_for_MDA_EricssonAB.pdf), which apparently was already able to generate Erlang code. > > This xtUML looks like a very interesting approach; in short we are contemplating to specify some domain-specific models that are involved in a discrete simulation, based on a proper high-level, formal, implementation-agnostic pivot format, targeting a few different simulation engines, one of which expecting models to be written in C++, another one expecting them in Erlang. So it looks like if our pivot format could be a flavour of xtUML (a special, constrained, case thereof). > > Is there any material (documentation and/or tool) that is publicly available, so that we could test this ExecutableUML-based approach? Any opinion in terms of completeness, applicability or maturity? > > Thanks in advance for any information! > > Best regards, > > Olivier. > --------------------------- > Olivier Boudeville > > EDF R&D : 1, avenue du G?n?ral de Gaulle, 92140 Clamart, France > D?partement SINETICS, groupe ASICS (I2A), bureau B-226 > Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47 65 27 13 > > > Ce message et toutes les pi?ces jointes (ci-apr?s le 'Message') sont ?tablis ? l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme ? sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. > > Si vous n'?tes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez re?u ce Message par erreur, merci de le supprimer de votre syst?me, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions ?galement d'en avertir imm?diatement l'exp?diteur par retour du message. > > Il est impossible de garantir que les communications par messagerie ?lectronique arrivent en temps utile, sont s?curis?es ou d?nu?es de toute erreur ou virus. > ____________________________________________________ > > This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. > > If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. > > E-mail communication cannot be guaranteed to be timely secure, error or virus-free._______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Thu Feb 16 09:59:06 2012 From: ulf@REDACTED (Ulf Wiger) Date: Thu, 16 Feb 2012 09:59:06 +0100 Subject: [erlang-questions] [ANN] sheriff 0.2: parse transform for type-based data validation In-Reply-To: References: <4F38EB62.6060908@ninenines.eu> <4F3A63C1.3040507@gmail.com> <4F3A7114.3040305@ninenines.eu> <4F3A8542.9080300@ninenines.eu> Message-ID: On 15 Feb 2012, at 00:23, Tristan Sloughter wrote: > Hmm, yeah. And I should have mentioned I modified Ulf's exprecs to have slightly different syntax but the main thing was to also use types in records to add calls to convert (which I may change to check...) for setting each attribute of a record. Interesting. Exprecs now also generates type signatures for the accessor functions, and does have some added support for controlling the naming of the accessors. I'd be interested in hearing if this support is insufficient for you. This was in response to Joel Reymont wanting full type signatures, and thinking that the exprecs naming convetion was hideous. :) Two reasons: (1) I'm of course curious to see how exprecs can be improved, and (2) I assume it would be better for you if you didn't have to maintain your own hacked version. I could also imagine running vanilla exprecs first and then another transform which e.g. does function renaming (hmm? there's an idea for a new transform :) BR, Ulf W From https://github.com/esl/parse_trans/blob/master/doc/exprecs.md : It is possible to modify the naming rules of exprecs, through the use of the following attributes (example reflecting the current rules): -exprecs_prefix(["#", operation, "-"]). -exprecs_fname([prefix, record]). -exprecs_vfname([fname, "__", version]). The lists must contain strings or any of the following control atoms: in exprecs_prefix: operation in exprecs_fname: operation, record, prefix in exprecs_vfname: operation, record, prefix, fname, version -------------- next part -------------- An HTML attachment was scrubbed... URL: From knutin@REDACTED Thu Feb 16 10:19:12 2012 From: knutin@REDACTED (Knut Nesheim) Date: Thu, 16 Feb 2012 10:19:12 +0100 Subject: [erlang-questions] VM using only 2 out of 8 schedulers available In-Reply-To: References: Message-ID: Thanks for a quick reply. During the GMT night which is our low point, we see quite low traffic on each machine with maybe 5% cpu utilization of each of the 8 cores. This could explain why some schedulers are put as idle. When traffic picks up, we're using around 25% of each core. The problem for us is that when traffic picks up again, the VM did not start using the idle schedulers again. erlang:statistics(run_queue) reports that there almost always are processes waiting, with peaks of around 20 processes in our case. This causes much higher latency than when using all cores. We will try pushing more load to this node to see if it starts using the idle schedulers. Thanks Knut On Thu, Feb 16, 2012 at 8:01 AM, Kenneth Lundin wrote: > What is your real problem except that there is no reported cpu load on some > of the cores? > > When there is low load on the system i.e. when there are too few runnable > Erlang processes some of the schedulers will automatically be put as idle > letting the remaining schedulers run all processes. When the load increases > the idle schedulers will be taken into service again. > > Each scheduler normally runs on one processor core. > > Can this explain what you have observed? > > /Kenneth Erlang/OTP Ericsson > > Den 15 feb 2012 17:53 skrev "Knut Nesheim" : >> >> Dear list, >> >> From time to time we see the VM using only some of the available >> cores. Typically 2 or 4 out of 8 available cores will be busy, while >> the others are not used at all. From 'top' and 'htop' we see only some >> cores being used. >> >> We are running the halfword emulator on 8 core machines and the VM is >> correctly reporting the number of schedulers and the underlying >> topology. The nodes are utilizing roughly 25% of each of the 8 cores >> during normal operation. >> >> This problem appeared again today and we still have the process >> running if anyone has any ideas for how to debug the issue. >> >> We are on Ubuntu 10.04 LTS, 2.6.32-342-ec2, 64bit, R14B04 with the >> halfword emulator. The only NIF library we are using is jiffy. >> >> Regards >> Knut >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions From ulf@REDACTED Thu Feb 16 10:49:48 2012 From: ulf@REDACTED (Ulf Wiger) Date: Thu, 16 Feb 2012 10:49:48 +0100 Subject: [erlang-questions] very large networks of erlang nodes? In-Reply-To: <8981237E-215C-472E-8619-6E2F6DD8FFC9@cs.otago.ac.nz> References: <4F36F152.9070002@meetinghouse.net> <8981237E-215C-472E-8619-6E2F6DD8FFC9@cs.otago.ac.nz> Message-ID: <11DE6608-22AC-47EE-B0C9-ECFCA42A510F@feuerlabs.com> It should be noted that there is an ongoing EU-funded research project which aims to address the limits of the current fully-connected approach. http://www.release-project.eu/ http://www.release-project.eu/documents/RELEASEfactsheetv6.pdf The high-level goal is to figure out how to build clusters of up to 10^5 cores. We envision having to improve both SMP scalability (beyond 100 cores per node) and Distributed Erlang scalability (more than 1000 nodes), and offer powerful and fault-tolerant standard libraries for high productivity. One factor that speaks for Erlang in this realm is that MTTCF (mean time to core failure) for a cluster of that many cores, given current technology, could be less than an hour. This necessitates a solution that can handle partial failure. It would be great if you could lean on those guys with experiences and ideas. Catch any one of e.g. Robert Virding, Tino Breddin, Kostis, Simon Thompson, Francesco, Olivier Boudeville, or Kenneth Lundin and buy them a beer or two - I'm sure you'll find them receptive. ;-) Using hidden nodes and spinning your own cluster is one thing we discussed, as well as , but our feeling was that this is way too low-level for a respectable Erlang approach. I imagine some sort of routing paradigm integrated into OTP will be needed, if Distribution Transparency is to be preserved without heroic effort. Regarding heart-beat timeouts, I think this is often due to port back-pressure. If the VM detects busy_dist_port, it will simply suspend the process trying to send, and when the dist_port queue falls back under a given threshold, it resumes all suspended processes at once. This can easily become disastrous in a situation with very high traffic or slow ports (e.g. in a virtual environment). Things have improved much in this regard in later releases. For one thing, buffers and thresholds have been increased, are more easily tunable (some hacking required still, I think), and overall throughput on the dist port has been improved. There is still much that can be done, but most of the really embarrassing problems should now be a thing of the past. If not, please share your experiences. BR, Ulf W On 15 Feb 2012, at 00:27, Richard O'Keefe wrote: > > On 15/02/2012, at 4:49 AM, Garrett Smith wrote: >> On Sat, Feb 11, 2012 at 4:53 PM, Miles Fidelman >> wrote: >>> Does anybody have experience running an Erlang environment consisting of >>> 100s, 1000s, or more nodes, spread across a network? >> As has been said, the fully connected mesh practically limits you to >> 50 - 150 nodes, at least in my experience. You will also find that >> connections flap quite a bit across unreliable networks, wreaking >> havoc in your application if you don't design for it. > > What would happen if you had 1000 nodes in a box with a reliable but > not ultrafast interconnect? I'm not talking about multicore here, > although 16 Tileras in a smallish box doesn't seem unlikely any more, > but say 1000 separate-physical-address-space nodes connected as a > tree or a hypercube or something. > > Could distributed Erlang be set up in some hierarchical fashion? > > It seems to me that there are three issues: > - number of points of authentication > (network: many; cluster-in-a-box: one) > - number of eavesdropping points > (network: many; cluster-in-a-box: one) > - number of communicating devices > (network: many; cluster-in-a-box: many) > and that just thinking in terms of authentication and eavesdropping, > distributed Erlang makes perfect sense for cluster-in-a-box, > IF it works at that scale. > > The Magnus project that Fergus O'Brien was involved with would have > been using Erlang in this way, I believe. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From alttagil@REDACTED Thu Feb 16 14:13:50 2012 From: alttagil@REDACTED (Alexander Hudich) Date: Thu, 16 Feb 2012 17:13:50 +0400 Subject: [erlang-questions] dh_anon SSL connection failed In-Reply-To: References: <002e01ccd43f$816f1270$844d3750$@gmail.com> <005b01ccd47a$84fd4070$8ef7c150$@gmail.com> Message-ID: <006b01ccecac$d466aad0$7d340070$@gmail.com> Hi, Ingela! You wrote: > Hum ... interesting it could be so that SSLv23_client_method() is more forgiving in some way and that your server has a bug... I will try to look into this more when I get time. If you come up with > something in the meantime pleas let me know. I wonder if you had any chance for further investigation of this problem? I remember I sent you openssl connection dump and as I saw that openssl always uses SSLv2/v3 method even if I pointed -no_ssl2 option explicitly. May be that's a way which have to be chosen to have ability to make connections with SSLv23_server_method() servers? I understand that SSL2 unsecured and it won't be supported, but it's really important to be able to make SSLv3 and TLSv1 connections with SSLv23_server_method() servers. Maybe there should be an option which version of SSL handshake hello should be sent? $openssl s_client -connect ip:5666 -state -debug -no_ssl2 -cipher ADH SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A SSL_connect:SSLv3 read server key exchange A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data SSL_connect:SSLv3 read server session ticket A SSL_connect:SSLv3 read finished A -----Original Message----- From: Ingela Andin [mailto:ingela.andin@REDACTED] Sent: Wednesday, January 18, 2012 12:39 PM To: alttagil@REDACTED; Erlang Subject: Re: [erlang-questions] dh_anon SSL connection failed Hi! 2012/1/16 Alexander Hudich : > Hi, Ingela! > >>> This is kind of excerpt from check_nrpe code which connects just fine: >>> >>>SSL_library_init(); >>>SSLeay_add_ssl_algorithms(); >>>meth=SSLv23_client_method(); >>>SSL_load_error_strings(); >>>ctx=SSL_CTX_new(meth)); >>>SSL_CTX_set_options(ctx,SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3); >>>result=my_tcp_connect(server_name,server_port,&sd); >>> >>> /* do SSL handshake */ >>> >>> if(result==STATE_OK && use_ssl==TRUE){ >>> if((ssl=SSL_new(ctx))!=NULL){ >>> SSL_CTX_set_cipher_list(ctx,"ADH"); >>> SSL_set_fd(ssl,sd); >>> rc=SSL_connect(ssl)); >>> } >>>} > >> What cipher suite and SSL/TLS-protocol version will this code end up > using? > > > I have not very much experience in development with using SSL connections. > So I don't know if I've done it's right I added this line after > SSL_connect to get current information about established SSL > connection in check_nrpe: > > printf( "CIPHER %s %s\n", SSL_CIPHER_get_name( > SSL_get_current_cipher(ssl) ), SSL_CIPHER_get_version( > SSL_get_current_cipher(ssl) ) ); > > And it gives: > > CIPHER ADH-AES256-SHA TLSv1/SSLv3 > > Also I tried to change SSLv23_client_method() call to SSLv3_client_method(). > And that gave very interesting result: > > CHECK_NRPE: Error - Could not complete SSL handshake. > SSL_connect=0 > 36071:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert > handshake failure:s3_pkt.c:1102:SSL alert number 40 > > That looks pretty similar to what I get with a result that erlang > ssl:connect call returns. > Hum ... interesting it could be so that SSLv23_client_method() is more forgiving in some way and that your server has a bug... I will try to look into this more when I get time. If you come up with something in the meantime pleas let me know. >>> Erlang R16B (erts-5.10) [source] [64-bit] [smp:1:1] >>> [async-threads:0] [hipe] [kernel-poll:false] >>> 5> SockOpts. >>> [{active,false}, >>> {ssl_imp,old}, > > >>This is not a relevant option after R15B ( it will always be new even >>if > you write old). > > Yes I know that, it was just an act of despair :) > > > >>> {verify,verify_none}, >>> {ciphers,[{dh_anon,rc4_128,md5}, >>> {dh_anon,des_cbc,sha}, >>> {dh_anon,'3des_ede_cbc',sha}, >>> {dh_anon,aes_128_cbc,sha}, >>> {dh_anon,aes_256_cbc,sha}]}] >>> >>> 6> ssl:connect( Ip, 5666, SockOpts, infinity). >>> >>> =ERROR REPORT==== 16-Jan-2012::12:49:23 === >>> SSL: hello: ssl_handshake.erl:885:Fatal error: handshake failure >>> {error,esslconnect} What do you think is it possible to make this >>> type of connection in > Erlang? >>> What else can I try or is it a bug? > >> Our test cases for anonymous suites works just fine. Have you tried > running the test case anonymous_cipher_suites in ssl_basic_SUITE? > > How can I do that? See description under testing in erlang patch instructions: https://github.com/erlang/otp/wiki/submitting-patches > >> Servers will normally not support anonymous cipher suites and we >> include > them only for test purposes and they may only be used if explicitly > supplied. > > I thought that I explicitly pointed to use that anonymous ciphers by > supplying them in connection options. Or there is something else I > should do? By supplying them in the connection options you will make the client try to connect to the server with those suites but it does not necessarily mean that the server supports them and will let you set up the connection. However your server seeems to support {dh_anon,aes_256_cbc,sha} ( ADH-AES256-SHA ). Regards Ingela Erlang/OTP team - Ericsson AB From erisa85d@REDACTED Thu Feb 16 15:15:58 2012 From: erisa85d@REDACTED (Erisa Dervishi) Date: Thu, 16 Feb 2012 15:15:58 +0100 Subject: [erlang-questions] Multiple db connection drivers Message-ID: Hi everybody, I am an erlang newbie, and I am doing a survey on existing Erlang db access drivers. I am most interested in drivers that can handle and process multiple concurrent db requests. Are there any working Erlang multithread db access drivers for MySql or PostgreSQL? What about BerkleyDB? Or any other Erlang driver that can handle db requests in parallel? There are plenty of drivers out there, but no documentation at all, and I am not experienced enough to find out the ones I'm interested in. I would be really glad if you could provide me some links or valuable suggestions. Thanks in advance! Cheers, Erisa -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Thu Feb 16 15:45:07 2012 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Thu, 16 Feb 2012 15:45:07 +0100 Subject: [erlang-questions] [ANN] sheriff 0.2: parse transform for type-based data validation In-Reply-To: <4F38EB62.6060908@ninenines.eu> References: <4F38EB62.6060908@ninenines.eu> Message-ID: <4F3D1673.2030304@ninenines.eu> Hello, I have just pushed a couple changes, including this important one. You can now check types directly using an inline notation by including the type to be checked against in a string: sheriff:check(Var, "list({atom(), integer()})") Works with built-in, local and remote types. Should make using sheriff a lot easier than before. On 02/13/2012 11:52 AM, Lo?c Hoguin wrote: > Hello! > > We just released the first beta version of the sheriff parse transform. > It allows you to validate data against types defined through the Erlang > type system. > > Sheriff allows you to write this: > > -type colors() :: blue | red | green | yellow. > > paint(Color, Object) -> > case sheriff:check(Color, colors) of > true -> > do_paint(Color, Object); > false -> > {error, badarg} > end. > > In this example, sheriff:check/2 will check that Color is of type > colors(), meaning it is one of 'blue', 'red', 'green' or 'yellow'. > > This allows you to quickly and efficiently write validation code for > unsafe external data without having to repeat yourself too much. > > Sheriff can be found here along with extended usage instructions: > https://github.com/extend/sheriff > > It's still in beta and has not been used in production yet, so feel free > to open tickets on github if you find bugs or don't understand something. > > Finally, I want to thank my students from last summer William Dang and > Hamza Mahmood for doing the awesome initial work and research that led > to this release. Thanks! > -- Lo?c Hoguin Erlang Cowboy Nine Nines From kenneth.lundin@REDACTED Thu Feb 16 15:55:28 2012 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Thu, 16 Feb 2012 15:55:28 +0100 Subject: [erlang-questions] ExecutableUML and Erlang In-Reply-To: <1525C7CD-4DA3-4EA6-92E6-6D1662723330@feuerlabs.com> References: <1525C7CD-4DA3-4EA6-92E6-6D1662723330@feuerlabs.com> Message-ID: Hi, Ulf has already covered most of it but I can add that I have also seen a demo and presentation of this and it is certainly nothing that we working with Erlang gets impressed by or even think is a good idea. As Ulf pointed out xtUML is on lower abstraction level than Erlang, my impression was that if the tool used Erlang as the xtUML it would be much better. I also think that the graphics is nice and fun as long as you have small toy examples which fits nicely on the screen. In summary I think textual programming in Erlang (possibly with a tool which can give a graphical view of processes etc) is much better. Additionally a DSL (still textual) where you can express a state-machine in tabular form could be useful. /Kenneth, Erlang/OTP, Ericsson On Thu, Feb 16, 2012 at 9:48 AM, Ulf Wiger wrote: > > Hmm? since it has been presented in public, I guess I can also add that > I've seen the Erlang code generated from that model, and it's not something > that I would ever want to use in production. :) > > There was some discussion about whether the code could be 'trivially > optimized', but I think it should be demonstrated first. The code pretty > much looked like a naive mapping from an OO design onto Erlang. > > I was involved in quite some discussion about the point of doing this in > the first place. The focus area for this approach is Hardware-Software > co-design, and in that narrow niche, it really seems like a useful idea. > > However, it's a stretch to imagine that one would need to be open to > generating target code as either e.g. VHDL or Erlang - at least from a > target-agnostic high-level design. > > Another point of discussion was why an Erlang programmer would want to > bother with Executable UML in the first place, as it doesn't offer more > powerful abstractions than Erlang already has - just *different* > abstractions, which is not necessarily a good thing. > > It got to the point where I was invited to meet one of the chief designers > of BridgePoint, so that he could convince me. Interestingly, he turned out > to be a secret fan of Functional Programming and Erlang, and we ended up > agreeing that Executable UML and Erlang were at roughly the same > abstraction level, and there was no benefit for the Erlang programmer to > first architect the system using one paradigm, and then make a sideways > move into another paradigm. He did try to argue that Erlang programmers > might still find the Schlaer&Mellor analysis domains useful, but I thought > that the mass of unwanted baggage would cancel out any such benefit. > > Having said this, I don't want to take away from the other work done > behind this. It's impressive. I just don't think that throwing Erlang into > the mix helps their case, nor that of the Erlang programmers. Also, this is > of course my personal opinion - I freely admit that I have not tried it out > for real. > > BR, > Ulf W > > On 14 Feb 2012, at 16:31, Olivier BOUDEVILLE wrote: > > > Hi everyone, > > In echo to the older thread "UML or other modeling tools" ( > http://erlang.2086793.n4.nabble.com/UML-or-other-modeling-tools-td3205732.html), > we happened to find an Ericsson presentation about ExecutableUML ( > http://www.cse.chalmers.se/edu/year/2010/course/MDSD/Year2010/Lectures/ExecutableUML_for_MDA_EricssonAB.pdf), > which apparently was already able to generate Erlang code. > > This xtUML looks like a very interesting approach; in short we are > contemplating to specify some domain-specific models that are involved in a > discrete simulation, based on a proper high-level, formal, > implementation-agnostic pivot format, targeting a few different simulation > engines, one of which expecting models to be written in C++, another one > expecting them in Erlang. So it looks like if our pivot format could be a > flavour of xtUML (a special, constrained, case thereof). > > Is there any material (documentation and/or tool) that is publicly > available, so that we could test this ExecutableUML-based approach? Any > opinion in terms of completeness, applicability or maturity? > > Thanks in advance for any information! > > Best regards, > > Olivier. > --------------------------- > Olivier Boudeville > > EDF R&D : 1, avenue du G?n?ral de Gaulle, 92140 Clamart, France > D?partement SINETICS, groupe ASICS (I2A), bureau B-226 > Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47 > 65 27 13 > > > > Ce message et toutes les pi?ces jointes (ci-apr?s le 'Message') sont > ?tablis ? l'intention exclusive des destinataires et les informations qui y > figurent sont strictement confidentielles. Toute utilisation de ce Message > non conforme ? sa destination, toute diffusion ou toute publication totale > ou partielle, est interdite sauf autorisation expresse. > > Si vous n'?tes pas le destinataire de ce Message, il vous est interdit de > le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou > partie. Si vous avez re?u ce Message par erreur, merci de le supprimer de > votre syst?me, ainsi que toutes ses copies, et de n'en garder aucune trace > sur quelque support que ce soit. Nous vous remercions ?galement d'en > avertir imm?diatement l'exp?diteur par retour du message. > > Il est impossible de garantir que les communications par messagerie > ?lectronique arrivent en temps utile, sont s?curis?es ou d?nu?es de toute > erreur ou virus. > ____________________________________________________ > > This message and any attachments (the 'Message') are intended solely for > the addressees. The information contained in this Message is confidential. > Any use of information contained in this Message not in accord with its > purpose, any dissemination or disclosure, either whole or partial, is > prohibited except formal approval. > > If you are not the addressee, you may not copy, forward, disclose or use > any part of it. If you have received this message in error, please delete > it and all copies from your system and notify the sender immediately by > return message. > > E-mail communication cannot be guaranteed to be timely secure, error or > virus-free._______________________________________________ > erlang-questions mailing list > 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 roberto@REDACTED Thu Feb 16 16:56:28 2012 From: roberto@REDACTED (Roberto Ostinelli) Date: Thu, 16 Feb 2012 07:56:28 -0800 Subject: [erlang-questions] Misultin EOL Message-ID: Dear list, Misultin development has been discontinued. There currently are three main webserver *libraries* which basically do similar things: - Mochiweb - Cowboy - Misultin Especially since the recent heavy development of Cowboy's HTTP server, I believe there is way too much duplication of efforts going on here. This is why Misultin's current 'state of the art' has been frozen in the latest tag, v0.9 , to support all the companies currently using Misultin in their production environment. I'm here to provide help, if needed, in moving away from it. Thus, this server should be robust and stable enough to continue serving your needs for some time. Instead of letting this library stand on github without notice, and getting developers still use this project, I have preferred to explicitly state to gradually move away from it, so that efforts can be concentrated around one server library only. It's hard enough to let one 'child' like this one go, but I believe it's best for the whole Erlang community. There are many ways to try to help each other in the community, I believe this decision is now for the better. *Mochiweb* has been around the block for a while and it's proven solid in production, I can only recommend it for all basic webserver needs you might have. *Cowboy* has a very interesting approach since it allows to use multiple TCP and UDP protocols on top of a common acceptor pool. It is a very modern approach, is very actively maintained and many projects are starting to be built around it. I'll personally concentrate my efforts around Cowboy, simply because the projects I'm involved in often require multiple procotols. I really hope that it'll live up to the expectations that I'm putting into this. Thank you to everyone that has been supporting Misultin in these years. Hopefully its *code usability*, which I still believe to be unmatched (well, I have developed it so how could I feel differently about this ^^_), will provide inspiration for some library interfaces. Best to you all, r. -------------- next part -------------- An HTML attachment was scrubbed... URL: From knutin@REDACTED Thu Feb 16 17:00:21 2012 From: knutin@REDACTED (Knut Nesheim) Date: Thu, 16 Feb 2012 17:00:21 +0100 Subject: [erlang-questions] VM using only 2 out of 8 schedulers available In-Reply-To: References: Message-ID: Hi, We just tried moving more load to the node using only two schedulers. The VM is using 100% cpu on the two cores, with a run queue hovering between 50 and 100 processes. There is no change in active schedulers. As far as I can see, the load is now at a point where the schedulers should become active. Is there anything we can do to understand more about why this is not happening? Knut On Thu, Feb 16, 2012 at 10:19 AM, Knut Nesheim wrote: > Thanks for a quick reply. > > During the GMT night which is our low point, we see quite low traffic > on each machine with maybe 5% cpu utilization of each of the 8 cores. > This could explain why some schedulers are put as idle. When traffic > picks up, we're using around 25% of each core. > > The problem for us is that when traffic picks up again, the VM did not > start using the idle schedulers again. erlang:statistics(run_queue) > reports that there almost always are processes waiting, with peaks of > around 20 processes in our case. This causes much higher latency than > when using all cores. > > We will try pushing more load to this node to see if it starts using > the idle schedulers. > > Thanks > Knut > > On Thu, Feb 16, 2012 at 8:01 AM, Kenneth Lundin > wrote: >> What is your real problem except that there is no reported cpu load on some >> of the cores? >> >> When there is low load on the system i.e. when there are too few runnable >> Erlang processes some of the schedulers will automatically be put as idle >> letting the remaining schedulers run all processes. When the load increases >> the idle schedulers will be taken into service again. >> >> Each scheduler normally runs on one processor core. >> >> Can this explain what you have observed? >> >> /Kenneth Erlang/OTP Ericsson >> >> Den 15 feb 2012 17:53 skrev "Knut Nesheim" : >>> >>> Dear list, >>> >>> From time to time we see the VM using only some of the available >>> cores. Typically 2 or 4 out of 8 available cores will be busy, while >>> the others are not used at all. From 'top' and 'htop' we see only some >>> cores being used. >>> >>> We are running the halfword emulator on 8 core machines and the VM is >>> correctly reporting the number of schedulers and the underlying >>> topology. The nodes are utilizing roughly 25% of each of the 8 cores >>> during normal operation. >>> >>> This problem appeared again today and we still have the process >>> running if anyone has any ideas for how to debug the issue. >>> >>> We are on Ubuntu 10.04 LTS, 2.6.32-342-ec2, 64bit, R14B04 with the >>> halfword emulator. The only NIF library we are using is jiffy. >>> >>> Regards >>> Knut >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions From antoine.koener@REDACTED Thu Feb 16 17:08:04 2012 From: antoine.koener@REDACTED (Antoine Koener) Date: Thu, 16 Feb 2012 17:08:04 +0100 Subject: [erlang-questions] Multiple db connection drivers In-Reply-To: References: Message-ID: Hi, On Thu, Feb 16, 2012 at 3:15 PM, Erisa Dervishi wrote: > Hi everybody, > > I am an erlang newbie, and I am doing a survey on existing Erlang db access > drivers. I am most interested in drivers that can handle and process > multiple concurrent db requests. Are there any working Erlang multithread db > access drivers for MySql or PostgreSQL? What about BerkleyDB? Or any other > Erlang driver that can handle db requests in parallel? > There are plenty of drivers out there, but no documentation at all, and I am > not experienced enough to find out the ones I'm interested in. > I would be really glad if you could provide me some links or valuable > suggestions. Have a look at http://sqlrelay.sourceforge.net/about.html From bourinov@REDACTED Thu Feb 16 18:11:57 2012 From: bourinov@REDACTED (Max Bourinov) Date: Thu, 16 Feb 2012 21:11:57 +0400 Subject: [erlang-questions] Multiple db connection drivers In-Reply-To: References: Message-ID: For PostgreSQL we use: * https://github.com/wg/epgsql - driver * https://github.com/josephwecker/epgsql_pool - connection pool (which is gen_server) It runs in production under heavy load. Works very well. Best regards, Max On Thu, Feb 16, 2012 at 6:15 PM, Erisa Dervishi wrote: > Hi everybody, > > I am an erlang newbie, and I am doing a survey on existing Erlang db > access drivers. I am most interested in drivers that can handle and process > multiple concurrent db requests. Are there any working Erlang multithread > db access drivers for MySql or PostgreSQL? What about BerkleyDB? Or any > other Erlang driver that can handle db requests in parallel? > There are plenty of drivers out there, but no documentation at all, and I > am not experienced enough to find out the ones I'm interested in. > I would be really glad if you could provide me some links or valuable > suggestions. > > Thanks in advance! > Cheers, > Erisa > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Thu Feb 16 19:09:26 2012 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Thu, 16 Feb 2012 19:09:26 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: Message-ID: <4F3D4656.9010807@ninenines.eu> Hello. I'm sad to see Misultin go, this was in my opinion the only other project that had enough momentum to introduce innovation in Erlang web servers. Even though there certainly was duplication happening, there was also original and interesting components (some which landed in cowboy, and vice versa). I almost ended up going for Misultin originally, but I wanted a Misultin+Webmachine+binaries (for the most part), a combination that didn't exist at the time. I'm always available by email or on #erlounge on freenode if people need help with moving to Cowboy. From what I've seen so far the task isn't too complicated. If anything is missing in Cowboy, please open a ticket. For usability concerns, Spawngrid did the following parse transform that helps you deal with the many Req variables. I don't use it, but it seems to work great for them. https://github.com/spawngrid/seqbind Thank you Roberto for everything you have done so far and I hope we can continue to work together on making Erlang HTTP stacks the best ones in the world. On 02/16/2012 04:56 PM, Roberto Ostinelli wrote: > Dear list, > > Misultin development has been discontinued. > > There currently are three main webserver /libraries/ which basically do > similar things: > > * Mochiweb > * Cowboy > * Misultin > > Especially since the recent heavy development of Cowboy's HTTP server, I > believe there is way too much duplication of efforts going on here. This > is why Misultin's current 'state of the art' has been frozen in the > latest tag, v0.9 > , to support > all the companies currently using Misultin in their production > environment. I'm here to provide help, if needed, in moving away from > it. Thus, this server should be robust and stable enough to continue > serving your needs for some time. > > Instead of letting this library stand on github without notice, and > getting developers still use this project, I have preferred to > explicitly state to gradually move away from it, so that efforts can be > concentrated around one server library only. It's hard enough to let one > 'child' like this one go, but I believe it's best for the whole Erlang > community. There are many ways to try to help each other in the > community, I believe this decision is now for the better. > > *Mochiweb* has been around the block for a while and it's proven solid > in production, I can only recommend it for all basic webserver needs you > might have. *Cowboy* has a very interesting approach since it allows to > use multiple TCP and UDP protocols on top of a common acceptor pool. It > is a very modern approach, is very actively maintained and many projects > are starting to be built around it. > > I'll personally concentrate my efforts around Cowboy, simply because the > projects I'm involved in often require multiple procotols. I really hope > that it'll live up to the expectations that I'm putting into this. > > Thank you to everyone that has been supporting Misultin in these years. > Hopefully its *code usability*, which I still believe to be unmatched > (well, I have developed it so how could I feel differently about this > ^^_), will provide inspiration for some library interfaces. > > Best to you all, > > r. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Lo?c Hoguin Erlang Cowboy Nine Nines From mfidelman@REDACTED Thu Feb 16 19:40:44 2012 From: mfidelman@REDACTED (Miles Fidelman) Date: Thu, 16 Feb 2012 13:40:44 -0500 Subject: [erlang-questions] very large networks of erlang nodes? In-Reply-To: <11DE6608-22AC-47EE-B0C9-ECFCA42A510F@feuerlabs.com> References: <4F36F152.9070002@meetinghouse.net> <8981237E-215C-472E-8619-6E2F6DD8FFC9@cs.otago.ac.nz> <11DE6608-22AC-47EE-B0C9-ECFCA42A510F@feuerlabs.com> Message-ID: <4F3D4DAC.8020200@meetinghouse.net> Now that is cool! Ulf Wiger wrote: > > It should be noted that there is an ongoing EU-funded research project > which aims to address the limits of the current fully-connected approach. > > http://www.release-project.eu/ > http://www.release-project.eu/documents/RELEASEfactsheetv6.pdf > > The high-level goal is to figure out how to build clusters of up to > 10^5 cores. We envision having to improve both SMP scalability (beyond > 100 cores per node) and Distributed Erlang scalability (more than 1000 > nodes), and offer powerful and fault-tolerant standard libraries for > high productivity. One factor that speaks for Erlang in this realm is > that MTTCF (mean time to core failure) for a cluster of that many > cores, given current technology, could be less than an hour. This > necessitates a solution that can handle partial failure. > > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From tristan.sloughter@REDACTED Thu Feb 16 19:44:31 2012 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Thu, 16 Feb 2012 12:44:31 -0600 Subject: [erlang-questions] Misultin EOL In-Reply-To: <4F3D4656.9010807@ninenines.eu> References: <4F3D4656.9010807@ninenines.eu> Message-ID: > > For usability concerns, Spawngrid did the following parse transform that > helps you deal with the many Req variables. I don't use it, but it seems to > work great for them. > > https://github.com/spawngrid/**seqbind Also checkout Erlando from RabbitMQ and the State Monad for dealing with this pattern. https://github.com/rabbitmq/erlando Tristan -------------- next part -------------- An HTML attachment was scrubbed... URL: From zabrane3@REDACTED Thu Feb 16 20:07:09 2012 From: zabrane3@REDACTED (Zabrane Mickael) Date: Thu, 16 Feb 2012 20:07:09 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: Message-ID: <43F19585-FA30-497F-8672-33703FF8F74B@gmail.com> Sad news Roberto. Anyway, thousands thanks for Misultin and hope you'll be still present to help the community (if needed). Regards, Zabrane On Feb 16, 2012, at 4:56 PM, Roberto Ostinelli wrote: > Dear list, > > Misultin development has been discontinued. > > There currently are three main webserver libraries which basically do similar things: > > Mochiweb > Cowboy > Misultin > Especially since the recent heavy development of Cowboy's HTTP server, I believe there is way too much duplication of efforts going on here. This is why Misultin's current 'state of the art' has been frozen in the latest tag, v0.9, to support all the companies currently using Misultin in their production environment. I'm here to provide help, if needed, in moving away from it. Thus, this server should be robust and stable enough to continue serving your needs for some time. > > Instead of letting this library stand on github without notice, and getting developers still use this project, I have preferred to explicitly state to gradually move away from it, so that efforts can be concentrated around one server library only. It's hard enough to let one 'child' like this one go, but I believe it's best for the whole Erlang community. There are many ways to try to help each other in the community, I believe this decision is now for the better. > > Mochiweb has been around the block for a while and it's proven solid in production, I can only recommend it for all basic webserver needs you might have. Cowboy has a very interesting approach since it allows to use multiple TCP and UDP protocols on top of a common acceptor pool. It is a very modern approach, is very actively maintained and many projects are starting to be built around it. > > I'll personally concentrate my efforts around Cowboy, simply because the projects I'm involved in often require multiple procotols. I really hope that it'll live up to the expectations that I'm putting into this. > Thank you to everyone that has been supporting Misultin in these years. Hopefully its code usability, which I still believe to be unmatched (well, I have developed it so how could I feel differently about this ^^_), will provide inspiration for some library interfaces. > > Best to you all, > > r. > > _______________________________________________ > 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 Thu Feb 16 21:50:17 2012 From: mjtruog@REDACTED (Michael Truog) Date: Thu, 16 Feb 2012 12:50:17 -0800 Subject: [erlang-questions] Misultin EOL In-Reply-To: <4F3D4656.9010807@ninenines.eu> References: <4F3D4656.9010807@ninenines.eu> Message-ID: <4F3D6C09.7050103@gmail.com> Hi, I am very concerned about the fact Misultin will no longer be developed, mainly because I don't see how cowboy has been able to provide the same performance and stability Misultin has provided. I understand there has been a great push for people to use cowboy, but I think it really requires loadtest result comparisons with Misultin to drive more serious usage. A good way to start would be to show that cowboy can surpass or at least be on-par with Misultin in a benchmark similar to http://www.ostinelli.net/a-comparison-between-misultin-mochiweb-cowboy-nodejs-and-tornadoweb/ . How can we compare cowboy and Misultin stability (i.e., for how long has cowboy been stable in production)? Is cowboy going to be able to take the lead on HTTP Erlang web server performance where mochiweb and yaws have been unable to (please don't bother to flame this, those people that don't care about performance, but care about Erlang)? So, this change just leaves me with a bunch of questions that have no clear answers available. It is sad that we are losing stability due to hype, which seems like an uncommon trend among Erlang, but I assume this is more of a comment on the community rather than the language. Thank you for your efforts on Misultin! Thanks, Michael On 02/16/2012 10:09 AM, Lo?c Hoguin wrote: > Hello. > > I'm sad to see Misultin go, this was in my opinion the only other project that had enough momentum to introduce innovation in Erlang web servers. Even though there certainly was duplication happening, there was also original and interesting components (some which landed in cowboy, and vice versa). I almost ended up going for Misultin originally, but I wanted a Misultin+Webmachine+binaries (for the most part), a combination that didn't exist at the time. > > I'm always available by email or on #erlounge on freenode if people need help with moving to Cowboy. From what I've seen so far the task isn't too complicated. If anything is missing in Cowboy, please open a ticket. > > For usability concerns, Spawngrid did the following parse transform that helps you deal with the many Req variables. I don't use it, but it seems to work great for them. > > https://github.com/spawngrid/seqbind > > Thank you Roberto for everything you have done so far and I hope we can continue to work together on making Erlang HTTP stacks the best ones in the world. > > On 02/16/2012 04:56 PM, Roberto Ostinelli wrote: >> Dear list, >> >> Misultin development has been discontinued. >> >> There currently are three main webserver /libraries/ which basically do >> similar things: >> >> * Mochiweb >> * Cowboy >> * Misultin >> >> Especially since the recent heavy development of Cowboy's HTTP server, I >> believe there is way too much duplication of efforts going on here. This >> is why Misultin's current 'state of the art' has been frozen in the >> latest tag, v0.9 >> , to support >> all the companies currently using Misultin in their production >> environment. I'm here to provide help, if needed, in moving away from >> it. Thus, this server should be robust and stable enough to continue >> serving your needs for some time. >> >> Instead of letting this library stand on github without notice, and >> getting developers still use this project, I have preferred to >> explicitly state to gradually move away from it, so that efforts can be >> concentrated around one server library only. It's hard enough to let one >> 'child' like this one go, but I believe it's best for the whole Erlang >> community. There are many ways to try to help each other in the >> community, I believe this decision is now for the better. >> >> *Mochiweb* has been around the block for a while and it's proven solid >> in production, I can only recommend it for all basic webserver needs you >> might have. *Cowboy* has a very interesting approach since it allows to >> use multiple TCP and UDP protocols on top of a common acceptor pool. It >> is a very modern approach, is very actively maintained and many projects >> are starting to be built around it. >> >> I'll personally concentrate my efforts around Cowboy, simply because the >> projects I'm involved in often require multiple procotols. I really hope >> that it'll live up to the expectations that I'm putting into this. >> >> Thank you to everyone that has been supporting Misultin in these years. >> Hopefully its *code usability*, which I still believe to be unmatched >> (well, I have developed it so how could I feel differently about this >> ^^_), will provide inspiration for some library interfaces. >> >> Best to you all, >> >> r. >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > From vinoski@REDACTED Thu Feb 16 22:17:02 2012 From: vinoski@REDACTED (Steve Vinoski) Date: Thu, 16 Feb 2012 16:17:02 -0500 Subject: [erlang-questions] Misultin EOL In-Reply-To: <4F3D6C09.7050103@gmail.com> References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: On Thu, Feb 16, 2012 at 3:50 PM, Michael Truog wrote: >?Is cowboy going to be able to take the lead on HTTP Erlang web server performance where mochiweb and yaws have been unable to (please don't bother to flame this, those people that don't care about performance, but care about Erlang)? I'm not interested in flames either, but I am interested in facts. Please back up your assertion by posting your meaningful benchmarks that prove that Yaws is lacking in performance. thanks, --steve From gumm@REDACTED Thu Feb 16 22:42:45 2012 From: gumm@REDACTED (Jesse Gumm) Date: Thu, 16 Feb 2012 15:42:45 -0600 Subject: [erlang-questions] Misultin EOL In-Reply-To: <4F3D6C09.7050103@gmail.com> References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: Not to state the obvious or anything, but Misultin is open source, so someone could always step up to the plate and become the *official* fork. There will still be efforts to support Misultin: Chicago Boss uses it, and barring some serious arguments against it, I'll still be adding misultin support to Nitrogen and SimpleBridge for the upcoming 2.1.0 release. So while it's unfortunate that Roberto is stepping away from Misultin development, that doesn't mean it's necessarily dead - someone can always take over. -Jesse On Thu, Feb 16, 2012 at 2:50 PM, Michael Truog wrote: > Hi, > > I am very concerned about the fact Misultin will no longer be developed, mainly because I don't see how cowboy has been able to provide the same performance and stability Misultin has provided. ?I understand there has been a great push for people to use cowboy, but I think it really requires loadtest result comparisons with Misultin to drive more serious usage. ?A good way to start would be to show that cowboy can surpass or at least be on-par with Misultin in a benchmark similar to http://www.ostinelli.net/a-comparison-between-misultin-mochiweb-cowboy-nodejs-and-tornadoweb/ . ?How can we compare cowboy and Misultin stability (i.e., for how long has cowboy been stable in production)? ?Is cowboy going to be able to take the lead on HTTP Erlang web server performance where mochiweb and yaws have been unable to (please don't bother to flame this, those people that don't care about performance, but care about Erlang)? > > So, this change just leaves me with a bunch of questions that have no clear answers available. ?It is sad that we are losing stability due to hype, which seems like an uncommon trend among Erlang, but I assume this is more of a comment on the community rather than the language. ?Thank you for your efforts on Misultin! > > Thanks, > Michael > > On 02/16/2012 10:09 AM, Lo?c Hoguin wrote: >> Hello. >> >> I'm sad to see Misultin go, this was in my opinion the only other project that had enough momentum to introduce innovation in Erlang web servers. Even though there certainly was duplication happening, there was also original and interesting components (some which landed in cowboy, and vice versa). I almost ended up going for Misultin originally, but I wanted a Misultin+Webmachine+binaries (for the most part), a combination that didn't exist at the time. >> >> I'm always available by email or on #erlounge on freenode if people need help with moving to Cowboy. From what I've seen so far the task isn't too complicated. If anything is missing in Cowboy, please open a ticket. >> >> For usability concerns, Spawngrid did the following parse transform that helps you deal with the many Req variables. I don't use it, but it seems to work great for them. >> >> ? ? https://github.com/spawngrid/seqbind >> >> Thank you Roberto for everything you have done so far and I hope we can continue to work together on making Erlang HTTP stacks the best ones in the world. >> >> On 02/16/2012 04:56 PM, Roberto Ostinelli wrote: >>> Dear list, >>> >>> Misultin development has been discontinued. >>> >>> There currently are three main webserver /libraries/ which basically do >>> similar things: >>> >>> ? * Mochiweb >>> ? * Cowboy >>> ? * Misultin >>> >>> Especially since the recent heavy development of Cowboy's HTTP server, I >>> believe there is way too much duplication of efforts going on here. This >>> is why Misultin's current 'state of the art' has been frozen in the >>> latest tag, v0.9 >>> , to support >>> all the companies currently using Misultin in their production >>> environment. I'm here to provide help, if needed, in moving away from >>> it. Thus, this server should be robust and stable enough to continue >>> serving your needs for some time. >>> >>> Instead of letting this library stand on github without notice, and >>> getting developers still use this project, I have preferred to >>> explicitly state to gradually move away from it, so that efforts can be >>> concentrated around one server library only. It's hard enough to let one >>> 'child' like this one go, but I believe it's best for the whole Erlang >>> community. There are many ways to try to help each other in the >>> community, I believe this decision is now for the better. >>> >>> *Mochiweb* has been around the block for a while and it's proven solid >>> in production, I can only recommend it for all basic webserver needs you >>> might have. *Cowboy* has a very interesting approach since it allows to >>> use multiple TCP and UDP protocols on top of a common acceptor pool. It >>> is a very modern approach, is very actively maintained and many projects >>> are starting to be built around it. >>> >>> I'll personally concentrate my efforts around Cowboy, simply because the >>> projects I'm involved in often require multiple procotols. I really hope >>> that it'll live up to the expectations that I'm putting into this. >>> >>> Thank you to everyone that has been supporting Misultin in these years. >>> Hopefully its *code usability*, which I still believe to be unmatched >>> (well, I have developed it so how could I feel differently about this >>> ^^_), will provide inspiration for some library interfaces. >>> >>> Best to you all, >>> >>> r. >>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Jesse Gumm Owner, Sigma Star Systems 414.940.4866 || sigma-star.com || @jessegumm From roberto@REDACTED Thu Feb 16 22:55:26 2012 From: roberto@REDACTED (Roberto Ostinelli) Date: Thu, 16 Feb 2012 13:55:26 -0800 Subject: [erlang-questions] Misultin EOL In-Reply-To: <43F19585-FA30-497F-8672-33703FF8F74B@gmail.com> References: <43F19585-FA30-497F-8672-33703FF8F74B@gmail.com> Message-ID: I sure am. I just believe this is actually my best way to be around, i.e. by trying to push towards a common great lib. r. On Thu, Feb 16, 2012 at 11:07 AM, Zabrane Mickael wrote: > Sad news Roberto. > > Anyway, thousands thanks for Misultin and hope you'll be still present to > help the community (if needed). > > Regards, > Zabrane > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto@REDACTED Thu Feb 16 23:02:13 2012 From: roberto@REDACTED (Roberto Ostinelli) Date: Thu, 16 Feb 2012 14:02:13 -0800 Subject: [erlang-questions] Misultin EOL In-Reply-To: <4F3D6C09.7050103@gmail.com> References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: On Thu, Feb 16, 2012 at 12:50 PM, Michael Truog wrote: > Hi, > > I am very concerned about the fact Misultin will no longer be developed, > mainly because I don't see how cowboy has been able to provide the same > performance and stability Misultin has provided. I understand there has > been a great push for people to use cowboy, but I think it really requires > loadtest result comparisons with Misultin to drive more serious usage. A > good way to start would be to show that cowboy can surpass or at least be > on-par with Misultin in a benchmark similar to > http://www.ostinelli.net/a-comparison-between-misultin-mochiweb-cowboy-nodejs-and-tornadoweb/. How can we compare cowboy and Misultin stability (i.e., for how long has > cowboy been stable in production)? Is cowboy going to be able to take the > lead on HTTP Erlang web server performance where mochiweb and yaws have > been unable to (please don't bother to flame this, those people that don't > care about performance, but care about Erlang)? > > So, this change just leaves me with a bunch of questions that have no > clear answers available. It is sad that we are losing stability due to > hype, which seems like an uncommon trend among Erlang, but I assume this is > more of a comment on the community rather than the language. Thank you for > your efforts on Misultin! > > Thanks, > Michael hi michael, as stated in that old benchmark, please do not take wrong conclusions out of it. there's nothing in there which talks about stability and other things. i'm happy that i've published because it has brought *a lot* of attention to erlang, but i probably wouldn't do it again: benchmarks like this are probably more confusing than anything else. i'm not going for 'hype', but tend to be a little realistic. i've been developing misultin mainly by myself with the support of the community. cowboy has had a fast adoption and lot of developer which i believe to be very good are actively and jointly working on it. i'm obviously running misultin in production since i've built it because i needed it: i'm simply gradually gonna consider cowboy for my new projects. r. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto@REDACTED Thu Feb 16 23:05:49 2012 From: roberto@REDACTED (Roberto Ostinelli) Date: Thu, 16 Feb 2012 14:05:49 -0800 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: On Thu, Feb 16, 2012 at 1:42 PM, Jesse Gumm wrote: > Not to state the obvious or anything, but Misultin is open source, so > someone could always step up to the plate and become the *official* > fork. > > There will still be efforts to support Misultin: Chicago Boss uses it, > and barring some serious arguments against it, I'll still be adding > misultin support to Nitrogen and SimpleBridge for the upcoming 2.1.0 > release. > > So while it's unfortunate that Roberto is stepping away from Misultin > development, that doesn't mean it's necessarily dead - someone can > always take over. > > -Jesse hi jesse, please don't suggest that. while i cannot avoid someone doing so, i could have kept maintaing misultin myself. as i said, it has been a hard decision. my intent here is to avoid duplication of efforts, both for the contributors of the community (often reporting the same bugs in both repositories) and for the developers, which now have an hard time in deciding which way to go. i just wanted to clear the way for a single webserver library, and cowboy seems to have much more developer time to actually maintaining it. r. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Thu Feb 16 23:28:17 2012 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 17 Feb 2012 11:28:17 +1300 Subject: [erlang-questions] very large networks of erlang nodes? In-Reply-To: <11DE6608-22AC-47EE-B0C9-ECFCA42A510F@feuerlabs.com> References: <4F36F152.9070002@meetinghouse.net> <8981237E-215C-472E-8619-6E2F6DD8FFC9@cs.otago.ac.nz> <11DE6608-22AC-47EE-B0C9-ECFCA42A510F@feuerlabs.com> Message-ID: <4DAF3FCD-AA1F-4340-84DD-DA29013959F4@cs.otago.ac.nz> On 16/02/2012, at 10:49 PM, Ulf Wiger wrote: > It would be great if you could lean on those guys with experiences and ideas. Catch any one of e.g. Robert Virding, Tino Breddin, Kostis, Simon Thompson, Francesco, Olivier Boudeville, or Kenneth Lundin and buy them a beer or two - I'm sure you'll find them receptive. ;-) If they ever visit Dunedin, it will be an honour and a pleasure to do so. From mjtruog@REDACTED Thu Feb 16 23:41:02 2012 From: mjtruog@REDACTED (Michael Truog) Date: Thu, 16 Feb 2012 14:41:02 -0800 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: <4F3D85FE.2040909@gmail.com> On 02/16/2012 02:02 PM, Roberto Ostinelli wrote: > On Thu, Feb 16, 2012 at 12:50 PM, Michael Truog > wrote: > > Hi, > > I am very concerned about the fact Misultin will no longer be developed, mainly because I don't see how cowboy has been able to provide the same performance and stability Misultin has provided. I understand there has been a great push for people to use cowboy, but I think it really requires loadtest result comparisons with Misultin to drive more serious usage. A good way to start would be to show that cowboy can surpass or at least be on-par with Misultin in a benchmark similar to http://www.ostinelli.net/a-comparison-between-misultin-mochiweb-cowboy-nodejs-and-tornadoweb/ . How can we compare cowboy and Misultin stability (i.e., for how long has cowboy been stable in production)? Is cowboy going to be able to take the lead on HTTP Erlang web server performance where mochiweb and yaws have been unable to (please don't bother to flame this, those people that don't care about performance, but care about Erlang)? > > So, this change just leaves me with a bunch of questions that have no clear answers available. It is sad that we are losing stability due to hype, which seems like an uncommon trend among Erlang, but I assume this is more of a comment on the community rather than the language. Thank you for your efforts on Misultin! > > Thanks, > Michael > > > hi michael, > > as stated in that old benchmark, please do not take wrong conclusions out of it. there's nothing in there which talks about stability and other things. i'm happy that i've published because it has brought *a lot* of attention to erlang, but i probably wouldn't do it again: benchmarks like this are probably more confusing than anything else. > > i'm not going for 'hype', but tend to be a little realistic. i've been developing misultin mainly by myself with the support of the community. cowboy has had a fast adoption and lot of developer which i believe to be very good are actively and jointly working on it. > > i'm obviously running misultin in production since i've built it because i needed it: i'm simply gradually gonna consider cowboy for my new projects. > > r. That may be a common reason to avoid providing any public benchmarks, it may never be a diplomatic thing to do, since it is raw results. The interpretation of the results is always dependent on the individual that is doing the decision making. However, the potential for an individual to misinterpret the results does not seem to be good justification for not posting performance information. Keeping performance information private, helps to limit innovation, only encouraging stagnation. Having a good idea of how HTTP servers compare is very beneficial, to help reduce latency, support more connections, and support more internal computation latency.... so, it helps us push limits. I understand you may not want to do benchmarks like that in the future, but I think it would be a shame to not have more recent benchmark results that can provide a more logical guide for our decision making when we consider the strengths and weaknesses of the various Erlang HTTP servers (and their improvements over what is available without Erlang). - Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjtruog@REDACTED Fri Feb 17 00:06:44 2012 From: mjtruog@REDACTED (Michael Truog) Date: Thu, 16 Feb 2012 15:06:44 -0800 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: <4F3D8C04.6040101@gmail.com> On 02/16/2012 01:17 PM, Steve Vinoski wrote: > On Thu, Feb 16, 2012 at 3:50 PM, Michael Truog wrote: >> Is cowboy going to be able to take the lead on HTTP Erlang web server performance where mochiweb and yaws have been unable to (please don't bother to flame this, those people that don't care about performance, but care about Erlang)? > I'm not interested in flames either, but I am interested in facts. > Please back up your assertion by posting your meaningful benchmarks > that prove that Yaws is lacking in performance. > > thanks, > --steve It is unfair to say that yaws does not perform like misultin and I do not have data to make that statement. When I think of performance, I am also thinking of software development performance for modifying, extending, and using the code-base. Yaws has lacked support once mochiweb was available because of some fragmentation within the community. From what I have seen, yaws chooses not to focus on performance, and has never intended to do so in the past, so it is unclear whether it would be able to maintain its performance in the future, if it received more support (based on http://steve.vinoski.net/blog/2011/05/09/erlang-web-server-benchmarking/). So, that was misleading for me to say, since you are probably correct that misultin is on par with yaws, though there are no public results to show that. With yaws the concern seems to be more about the code being regarded as legacy, not actively developed, and not modular (and whatever other reasons that seemed to make mochiweb appear necessary). I say this knowing that you are currently the main maintainer of the code-base. These are just the impressions I have had from being within the Erlang community for a few years. - Michael From essen@REDACTED Fri Feb 17 01:02:38 2012 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Fri, 17 Feb 2012 01:02:38 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: <4F3D6C09.7050103@gmail.com> References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: <4F3D991E.5000205@ninenines.eu> I would have loved to have more benchmarks but of all the ones I've heard about Cowboy so far none have been published (besides Roberto's). Benchmarks are unfortunately often misunderstood and subject to flame wars as was pointed out, but also hype. There's also the fact that not all applications have the same requirements. Even if Cowboy was good enough for 90% of applications, there'd still be a need for other kinds of servers (same goes for other servers). I can throw a few numbers if you want, however. A couple months ago someone did a websocket benchmark on an Amazon EC2 instance and measured Cowboy to take 11GB of memory with 500K idle connections. Then they simulated the workload their application would take and after ironing an issue out it ended up still working with 500K working connections. They tested with more connections but I don't know the details there. I myself had Cowboy running in production with no issue for a few months now. I know various companies using it in different domains. I still consider it beta and always warn people about it but this doesn't seem to slow its adoption. I can also say that Cowboy will take a central part in a few major projects in the near future, though I can't say more than that at this time. On 02/16/2012 09:50 PM, Michael Truog wrote: > Hi, > > I am very concerned about the fact Misultin will no longer be developed, mainly because I don't see how cowboy has been able to provide the same performance and stability Misultin has provided. I understand there has been a great push for people to use cowboy, but I think it really requires loadtest result comparisons with Misultin to drive more serious usage. A good way to start would be to show that cowboy can surpass or at least be on-par with Misultin in a benchmark similar to http://www.ostinelli.net/a-comparison-between-misultin-mochiweb-cowboy-nodejs-and-tornadoweb/ . How can we compare cowboy and Misultin stability (i.e., for how long has cowboy been stable in production)? Is cowboy going to be able to take the lead on HTTP Erlang web server performance where mochiweb and yaws have been unable to (please don't bother to flame this, those people that don't care about performance, but care about Erlang)? > > So, this change just leaves me with a bunch of questions that have no clear answers available. It is sad that we are losing stability due to hype, which seems like an uncommon trend among Erlang, but I assume this is more of a comment on the community rather than the language. Thank you for your efforts on Misultin! > > Thanks, > Michael > > On 02/16/2012 10:09 AM, Lo?c Hoguin wrote: >> Hello. >> >> I'm sad to see Misultin go, this was in my opinion the only other project that had enough momentum to introduce innovation in Erlang web servers. Even though there certainly was duplication happening, there was also original and interesting components (some which landed in cowboy, and vice versa). I almost ended up going for Misultin originally, but I wanted a Misultin+Webmachine+binaries (for the most part), a combination that didn't exist at the time. >> >> I'm always available by email or on #erlounge on freenode if people need help with moving to Cowboy. From what I've seen so far the task isn't too complicated. If anything is missing in Cowboy, please open a ticket. >> >> For usability concerns, Spawngrid did the following parse transform that helps you deal with the many Req variables. I don't use it, but it seems to work great for them. >> >> https://github.com/spawngrid/seqbind >> >> Thank you Roberto for everything you have done so far and I hope we can continue to work together on making Erlang HTTP stacks the best ones in the world. >> >> On 02/16/2012 04:56 PM, Roberto Ostinelli wrote: >>> Dear list, >>> >>> Misultin development has been discontinued. >>> >>> There currently are three main webserver /libraries/ which basically do >>> similar things: >>> >>> * Mochiweb >>> * Cowboy >>> * Misultin >>> >>> Especially since the recent heavy development of Cowboy's HTTP server, I >>> believe there is way too much duplication of efforts going on here. This >>> is why Misultin's current 'state of the art' has been frozen in the >>> latest tag, v0.9 >>> , to support >>> all the companies currently using Misultin in their production >>> environment. I'm here to provide help, if needed, in moving away from >>> it. Thus, this server should be robust and stable enough to continue >>> serving your needs for some time. >>> >>> Instead of letting this library stand on github without notice, and >>> getting developers still use this project, I have preferred to >>> explicitly state to gradually move away from it, so that efforts can be >>> concentrated around one server library only. It's hard enough to let one >>> 'child' like this one go, but I believe it's best for the whole Erlang >>> community. There are many ways to try to help each other in the >>> community, I believe this decision is now for the better. >>> >>> *Mochiweb* has been around the block for a while and it's proven solid >>> in production, I can only recommend it for all basic webserver needs you >>> might have. *Cowboy* has a very interesting approach since it allows to >>> use multiple TCP and UDP protocols on top of a common acceptor pool. It >>> is a very modern approach, is very actively maintained and many projects >>> are starting to be built around it. >>> >>> I'll personally concentrate my efforts around Cowboy, simply because the >>> projects I'm involved in often require multiple procotols. I really hope >>> that it'll live up to the expectations that I'm putting into this. >>> >>> Thank you to everyone that has been supporting Misultin in these years. >>> Hopefully its *code usability*, which I still believe to be unmatched >>> (well, I have developed it so how could I feel differently about this >>> ^^_), will provide inspiration for some library interfaces. >>> >>> Best to you all, >>> >>> r. >>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > -- Lo?c Hoguin Erlang Cowboy Nine Nines From steven.charles.davis@REDACTED Fri Feb 17 03:09:45 2012 From: steven.charles.davis@REDACTED (Steve Davis) Date: Thu, 16 Feb 2012 18:09:45 -0800 (PST) Subject: [erlang-questions] Misultin EOL In-Reply-To: <4F3D991E.5000205@ninenines.eu> References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D991E.5000205@ninenines.eu> Message-ID: <4915914f-b378-43ab-9fcc-742980c2ee43@bs8g2000vbb.googlegroups.com> Hi Roberto, I'm a bit confused by this whole thread... I'm agreeing with Jesse that since Misultin is open source, it's not really in your control to "stop development" if the interest is there elsewhere to push it on? I'm also agreeing with Steve that I've not seen any demonstration that yaws is somehow "lacking", For me, the last interesting benchmark that demonstrated anything graspably real was "yaws vs apache". A really interesting benchmark for today's "web server" would be, if someone were willing to engage in a non-trivial effort, to make a comparison of a full-fledged web application with full session management and routing capabilities. Note that this would truly test the appropriateness of the server's http APIs as well as the base response. That kind of benchmark, for me, would seem more appropriate and useful according to the epoch. Best regards, /s From barcojie@REDACTED Fri Feb 17 03:57:12 2012 From: barcojie@REDACTED (Barco You) Date: Fri, 17 Feb 2012 10:57:12 +0800 Subject: [erlang-questions] Misultin EOL In-Reply-To: <4915914f-b378-43ab-9fcc-742980c2ee43@bs8g2000vbb.googlegroups.com> References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D991E.5000205@ninenines.eu> <4915914f-b378-43ab-9fcc-742980c2ee43@bs8g2000vbb.googlegroups.com> Message-ID: >my intent here is to avoid duplication of efforts, both for the contributors of the community (often reporting the same bugs in both repositories) and for the developers, which now have an hard time in deciding which way to go. >i just wanted to clear the way for a single webserver library, and cowboy seems to have much more developer time to actually maintaining it. What's the logic behind forgoing a better one to support another with the purpose of avoiding duplicate efforts? Why not contributors come to help migrate the productions on those over-hyped frameworks to on the proven-best one? No matter how, I like Misultin very much for its high performance, simplicity and advanced concepts. If it would really go I would be very sad and I believe many others in this community too. Let's find a better way to contribute to our community better! Regards, Barco On Fri, Feb 17, 2012 at 10:09 AM, Steve Davis < steven.charles.davis@REDACTED> wrote: > Hi Roberto, > > I'm a bit confused by this whole thread... > > I'm agreeing with Jesse that since Misultin is open source, it's not > really in your control to "stop development" if the interest is there > elsewhere to push it on? > > I'm also agreeing with Steve that I've not seen any demonstration that > yaws is somehow "lacking", > > For me, the last interesting benchmark that demonstrated anything > graspably real was "yaws vs apache". > > A really interesting benchmark for today's "web server" would be, if > someone were willing to engage in a non-trivial effort, to make a > comparison of a full-fledged web application with full session > management and routing capabilities. Note that this would truly test > the appropriateness of the server's http APIs as well as the base > response. That kind of benchmark, for me, would seem more appropriate > and useful according to the epoch. > > Best regards, > /s > _______________________________________________ > 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 Feb 17 06:40:14 2012 From: mjtruog@REDACTED (Michael Truog) Date: Thu, 16 Feb 2012 21:40:14 -0800 Subject: [erlang-questions] Misultin EOL In-Reply-To: <4915914f-b378-43ab-9fcc-742980c2ee43@bs8g2000vbb.googlegroups.com> References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D991E.5000205@ninenines.eu> <4915914f-b378-43ab-9fcc-742980c2ee43@bs8g2000vbb.googlegroups.com> Message-ID: <4F3DE83E.1090200@gmail.com> I understand that for your own specific use, you would prefer to benchmark the complete stack, which is completely reasonable. However, the goal is avoiding subjective judgments on complex technological decisions by reducing the testing to smaller components. The "yaws vs apache" benchmark is probably the oldest benchmark that exists, showing results with an Erlang HTTP server. The misultin benchmark is the best in the absence of other loadtest results, but I agree it is unfortunate that it wasn't more serious with client machines driving the test with something like Tsung. If you ignore that, the fact it was able to show relative performance was interesting. Adding more complexity to the tests, when you bring in other components seems like it would make the test less useful, unless the Erlang components are part of someone's favorite "web framework" bundle. Then that just becomes a sales-pitch. I like the idea of having a more objective guide as to which Erlang HTTP server should be used, or how the decisions compare to non-Erlang HTTP servers. Those results then can help guide development decisions and simulate more innovation. On 02/16/2012 06:09 PM, Steve Davis wrote: > For me, the last interesting benchmark that demonstrated anything > graspably real was "yaws vs apache". > > A really interesting benchmark for today's "web server" would be, if > someone were willing to engage in a non-trivial effort, to make a > comparison of a full-fledged web application with full session > management and routing capabilities. Note that this would truly test > the appropriateness of the server's http APIs as well as the base > response. That kind of benchmark, for me, would seem more appropriate > and useful according to the epoch. From ebegumisa@REDACTED Fri Feb 17 06:52:47 2012 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Fri, 17 Feb 2012 16:52:47 +1100 Subject: [erlang-questions] Misultin EOL In-Reply-To: <4F3D8C04.6040101@gmail.com> References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> Message-ID: Hi, I have a small quibble (not trying to flame here), but isn't a comparison between Yaws and Mutlisin a case of apples and oranges? From a developer's perspective, Yaws is a webserver in the Apache+PHP sense or IIS+.Net sense. Mutlisin (Mochiweb/Cowboy) are web server libraries in the libmicrohttpd sense. Nitrogen, Erlang-web and Erlyweb are web-frameworks in the Django/CakePHP sense. While webmachine is uniquely on its own. Yaws is about *serving* dynamic and static *content*? You'd consider using Cowboy & Co' to develop "a yaws" if you were starting a yaws-like project afresh in 2012. While you'd consider using yaws to develop a new django-like framework for Erlang. I'm yet to come across an Erlang web-server that is in the Yaws category that has it's features and thoughtful design. I know of only Inets that's also in this category. So I always find it curious when Yaws is lumped into discussions where it's strengths and focus don't fit at all. Addressing some of your concerns: Modularity - If you think of yaws as a web-application server that never goes down and can run many applications, you'd find that it's very very modular (appmonds/yapps). If it's modularity of the code-base itself that your referring to, well, it doesn't look bad to me. I learned Erlang largely by reading Yaws source code. Usability - Development with yaws is the reverse of the popular web-libs. You use yaws to "serve", cache, log and session manage one or more of your web-apps (dynamic and static content) as opposed to using Mutlisin/Mochiweb/Cowboy to write a web-app that serves, caches, and logs itself and manages it's own sessions. (In)activity - I personally haven't found many features that I've wanted to be added to yaws itself, so it could be a case of feature saturation rather than an under-developed legacy code-base. Most things that don't exist, you can use from your app code without it being in yaws coz of the way it's designed. For instance, I don't much like yaws' dynamic content creation features (ehtml/ssi/yssi). Instead, I frequently use the ErlTL template module from Erlyweb (without erlyweb). That said, sometimes, for some projects, I find yaws overkill and reach for one of the newer light webserver libs (usually when the app needs to expose a simple web-API). But for most web projects with lots of content (and where development time is scarce), I find using those libs would have me duplicating a lot of the great work already done in yaws, so I reach for yaws instead. - Edmond - On Fri, 17 Feb 2012 10:06:44 +1100, Michael Truog wrote: > On 02/16/2012 01:17 PM, Steve Vinoski wrote: >> On Thu, Feb 16, 2012 at 3:50 PM, Michael Truog >> wrote: >>> Is cowboy going to be able to take the lead on HTTP Erlang web server >>> performance where mochiweb and yaws have been unable to (please don't >>> bother to flame this, those people that don't care about performance, >>> but care about Erlang)? >> I'm not interested in flames either, but I am interested in facts. >> Please back up your assertion by posting your meaningful benchmarks >> that prove that Yaws is lacking in performance. >> >> thanks, >> --steve > > It is unfair to say that yaws does not perform like misultin and I do > not have data to make that statement. When I think of performance, I am > also thinking of software development performance for modifying, > extending, and using the code-base. Yaws has lacked support once > mochiweb was available because of some fragmentation within the > community. From what I have seen, yaws chooses not to focus on > performance, and has never intended to do so in the past, so it is > unclear whether it would be able to maintain its performance in the > future, if it received more support (based on > http://steve.vinoski.net/blog/2011/05/09/erlang-web-server-benchmarking/). > So, that was misleading for me to say, since you are probably correct > that misultin is on par with yaws, though there are no public results to > show that. With yaws the concern seems to be more about the code being > regarded as legacy, not actively developed, and not modular (and > whatever other reasons that seemed to make mochiweb > appear necessary). I say this knowing that you are currently the main > maintainer of the code-base. These are just the impressions I have had > from being within the Erlang community for a few years. > > - Michael > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From ebegumisa@REDACTED Fri Feb 17 06:59:22 2012 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Fri, 17 Feb 2012 16:59:22 +1100 Subject: [erlang-questions] Misultin EOL In-Reply-To: <4915914f-b378-43ab-9fcc-742980c2ee43@bs8g2000vbb.googlegroups.com> References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D991E.5000205@ninenines.eu> <4915914f-b378-43ab-9fcc-742980c2ee43@bs8g2000vbb.googlegroups.com> Message-ID: On Fri, 17 Feb 2012 13:09:45 +1100, Steve Davis wrote: > Hi Roberto, > > I'm a bit confused by this whole thread... > Me too! > I'm agreeing with Jesse that since Misultin is open source, it's not > really in your control to "stop development" if the interest is there > elsewhere to push it on? But he is basically the only guy developing it. Practically speaking, if he declares to users "move to something else", the project is unlikely to recover. Most people are unlikely to argue with the developer and persist. > > I'm also agreeing with Steve that I've not seen any demonstration that > yaws is somehow "lacking", > > For me, the last interesting benchmark that demonstrated anything > graspably real was "yaws vs apache". > > A really interesting benchmark for today's "web server" would be, if > someone were willing to engage in a non-trivial effort, to make a > comparison of a full-fledged web application with full session > management and routing capabilities. Note that this would truly test > the appropriateness of the server's http APIs as well as the base > response. That kind of benchmark, for me, would seem more appropriate > and useful according to the epoch. > I agree, there are too may apples and oranges comparisons in these discussions. - Edmond - > Best regards, > /s > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From mjtruog@REDACTED Fri Feb 17 07:18:54 2012 From: mjtruog@REDACTED (Michael Truog) Date: Thu, 16 Feb 2012 22:18:54 -0800 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> Message-ID: <4F3DF14E.6020503@gmail.com> The modularity/usability issues mainly seem to be related to the fact that I see it as overkill for most projects that I would be interested in. So, this is a subjective judgment, where I don't want to get locked into an obscure templating format, etc. The activity issue impacts decisions about newer features. When I have looked at the yaws code in the past, it looks like legacy code, where there are modifications for various features scattered in various ways. I can understand how its age with all the various testing should make it the most stable full-featured choice. However, for new integration work it becomes overkill due to its complexity and the lack of modularity within the code-base. I say this, because if yaws was written in a modular way, it seems like you could easily pull a few modules to replace misultin functionality with something that has more testing. If that was possible, perhaps it would even perform better than misultin and cowboy, but it seems like doing that has not been possible, nor would it be possible in the future (due to the legacy nature of yaws). Inets usually seems to go unmentioned in these discussions and the benchmarks, but it would be interesting to see how it might compare to yaws and the other choices. On 02/16/2012 09:52 PM, Edmond Begumisa wrote: > Hi, > > I have a small quibble (not trying to flame here), but isn't a comparison between Yaws and Mutlisin a case of apples and oranges? > > From a developer's perspective, Yaws is a webserver in the Apache+PHP sense or IIS+.Net sense. Mutlisin (Mochiweb/Cowboy) are web server libraries in the libmicrohttpd sense. Nitrogen, Erlang-web and Erlyweb are web-frameworks in the Django/CakePHP sense. While webmachine is uniquely on its own. > > Yaws is about *serving* dynamic and static *content*? You'd consider using Cowboy & Co' to develop "a yaws" if you were starting a yaws-like project afresh in 2012. While you'd consider using yaws to develop a new django-like framework for Erlang. > > I'm yet to come across an Erlang web-server that is in the Yaws category that has it's features and thoughtful design. I know of only Inets that's also in this category. > > So I always find it curious when Yaws is lumped into discussions where it's strengths and focus don't fit at all. > > Addressing some of your concerns: > > Modularity - If you think of yaws as a web-application server that never goes down and can run many applications, you'd find that it's very very modular (appmonds/yapps). If it's modularity of the code-base itself that your referring to, well, it doesn't look bad to me. I learned Erlang largely by reading Yaws source code. > > Usability - Development with yaws is the reverse of the popular web-libs. You use yaws to "serve", cache, log and session manage one or more of your web-apps (dynamic and static content) as opposed to using Mutlisin/Mochiweb/Cowboy to write a web-app that serves, caches, and logs itself and manages it's own sessions. > > (In)activity - I personally haven't found many features that I've wanted to be added to yaws itself, so it could be a case of feature saturation rather than an under-developed legacy code-base. Most things that don't exist, you can use from your app code without it being in yaws coz of the way it's designed. For instance, I don't much like yaws' dynamic content creation features (ehtml/ssi/yssi). Instead, I frequently use the ErlTL template module from Erlyweb (without erlyweb). > > That said, sometimes, for some projects, I find yaws overkill and reach for one of the newer light webserver libs (usually when the app needs to expose a simple web-API). But for most web projects with lots of content (and where development time is scarce), I find using those libs would have me duplicating a lot of the great work already done in yaws, so I reach for yaws instead. > > - Edmond - > > > > > On Fri, 17 Feb 2012 10:06:44 +1100, Michael Truog wrote: > >> On 02/16/2012 01:17 PM, Steve Vinoski wrote: >>> On Thu, Feb 16, 2012 at 3:50 PM, Michael Truog wrote: >>>> Is cowboy going to be able to take the lead on HTTP Erlang web server performance where mochiweb and yaws have been unable to (please don't bother to flame this, those people that don't care about performance, but care about Erlang)? >>> I'm not interested in flames either, but I am interested in facts. >>> Please back up your assertion by posting your meaningful benchmarks >>> that prove that Yaws is lacking in performance. >>> >>> thanks, >>> --steve >> >> It is unfair to say that yaws does not perform like misultin and I do not have data to make that statement. When I think of performance, I am also thinking of software development performance for modifying, extending, and using the code-base. Yaws has lacked support once mochiweb was available because of some fragmentation within the community. From what I have seen, yaws chooses not to focus on performance, and has never intended to do so in the past, so it is unclear whether it would be able to maintain its performance in the future, if it received more support (based on http://steve.vinoski.net/blog/2011/05/09/erlang-web-server-benchmarking/). So, that was misleading for me to say, since you are probably correct that misultin is on par with yaws, though there are no public results to show that. With yaws the concern seems to be more about the code being regarded as legacy, not actively developed, and not modular (and whatever other reasons that seemed to make mochiweb >> appear necessary). I say this knowing that you are currently the main maintainer of the code-base. These are just the impressions I have had from being within the Erlang community for a few years. >> >> - Michael >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > From ebegumisa@REDACTED Fri Feb 17 08:37:32 2012 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Fri, 17 Feb 2012 18:37:32 +1100 Subject: [erlang-questions] Misultin EOL In-Reply-To: <4F3DF14E.6020503@gmail.com> References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> <4F3DF14E.6020503@gmail.com> Message-ID: On Fri, 17 Feb 2012 17:18:54 +1100, Michael Truog wrote: > The modularity/usability issues mainly seem to be related to the fact > that I see it as overkill for most projects that I would be interested > in. So, this is a subjective judgment, where I don't want to get locked > into an obscure templating format, etc. I see. I was just pointing out that I never seen comparisons made between Apache vs libmicrohttpd vs Django, nor have I heard of someone having a "dilemma" choosing between these three completely different (but related) technologies focused on solving different problems. Yet curiously, this sort of comparision frequently occurs on this list in dicussions relating to Erlang and the web. > The activity issue impacts decisions about newer features. When I have > looked at the yaws code in the past, it looks like legacy code, where > there are modifications for various features scattered in various ways. > I can understand how its age with all the various testing should make it > the most stable full-featured choice. However, for new integration work > it becomes overkill due to its complexity and the lack of modularity > within the code-base. Fair enough. I haven't personally tried to add features to yaws so I can't comment. > I say this, because if yaws was written in a modular way, it seems like > you could easily pull a few modules to replace misultin functionality > with something that has more testing. If that was possible, perhaps it > would even perform better than misultin and cowboy, but it seems like > doing that has not been possible, nor would it be possible in the future > (due to the legacy nature of yaws). Another way to look at it: If misultin and cowboy were available at the time, maybe Claes Wikstrom would have used one of them to write yaws, which according to one of his interviews[1], was written as a result of his understandable frustration with the popular Apache-PHP combination, rather than as extensible lightweigth web library for Erlang. > Inets usually seems to go unmentioned in these discussions and the > benchmarks, but it would be interesting to see how it might compare to > yaws and the other choices. > In my view, any credible benchmark mentioning yaws must talk about content and caching: * Delivery of un-cached static content * Delivery of un-cached dynamic content * Delivery of cached content * Delivery of streamed content * Delivery when caches are full * Delivery when complex session data is involved If these things aren't being measured, it's likely that an apples and oranges comparision is being made, because these are the things that matter when I choose to use yaws (and I guess when most people choose yaws.) [1] http://bsdtalk.blogspot.com.au/2006/08/bsdtalk062-interview-with-yaws.html - Edmond - > On 02/16/2012 09:52 PM, Edmond Begumisa wrote: >> Hi, >> >> I have a small quibble (not trying to flame here), but isn't a >> comparison between Yaws and Mutlisin a case of apples and oranges? >> >> From a developer's perspective, Yaws is a webserver in the Apache+PHP >> sense or IIS+.Net sense. Mutlisin (Mochiweb/Cowboy) are web server >> libraries in the libmicrohttpd sense. Nitrogen, Erlang-web and Erlyweb >> are web-frameworks in the Django/CakePHP sense. While webmachine is >> uniquely on its own. >> >> Yaws is about *serving* dynamic and static *content*? You'd consider >> using Cowboy & Co' to develop "a yaws" if you were starting a yaws-like >> project afresh in 2012. While you'd consider using yaws to develop a >> new django-like framework for Erlang. >> >> I'm yet to come across an Erlang web-server that is in the Yaws >> category that has it's features and thoughtful design. I know of only >> Inets that's also in this category. >> >> So I always find it curious when Yaws is lumped into discussions where >> it's strengths and focus don't fit at all. >> >> Addressing some of your concerns: >> >> Modularity - If you think of yaws as a web-application server that >> never goes down and can run many applications, you'd find that it's >> very very modular (appmonds/yapps). If it's modularity of the code-base >> itself that your referring to, well, it doesn't look bad to me. I >> learned Erlang largely by reading Yaws source code. >> >> Usability - Development with yaws is the reverse of the popular >> web-libs. You use yaws to "serve", cache, log and session manage one or >> more of your web-apps (dynamic and static content) as opposed to using >> Mutlisin/Mochiweb/Cowboy to write a web-app that serves, caches, and >> logs itself and manages it's own sessions. >> >> (In)activity - I personally haven't found many features that I've >> wanted to be added to yaws itself, so it could be a case of feature >> saturation rather than an under-developed legacy code-base. Most things >> that don't exist, you can use from your app code without it being in >> yaws coz of the way it's designed. For instance, I don't much like >> yaws' dynamic content creation features (ehtml/ssi/yssi). Instead, I >> frequently use the ErlTL template module from Erlyweb (without erlyweb). >> >> That said, sometimes, for some projects, I find yaws overkill and reach >> for one of the newer light webserver libs (usually when the app needs >> to expose a simple web-API). But for most web projects with lots of >> content (and where development time is scarce), I find using those libs >> would have me duplicating a lot of the great work already done in yaws, >> so I reach for yaws instead. >> >> - Edmond - >> >> >> >> >> On Fri, 17 Feb 2012 10:06:44 +1100, Michael Truog >> wrote: >> >>> On 02/16/2012 01:17 PM, Steve Vinoski wrote: >>>> On Thu, Feb 16, 2012 at 3:50 PM, Michael Truog >>>> wrote: >>>>> Is cowboy going to be able to take the lead on HTTP Erlang web >>>>> server performance where mochiweb and yaws have been unable to >>>>> (please don't bother to flame this, those people that don't care >>>>> about performance, but care about Erlang)? >>>> I'm not interested in flames either, but I am interested in facts. >>>> Please back up your assertion by posting your meaningful benchmarks >>>> that prove that Yaws is lacking in performance. >>>> >>>> thanks, >>>> --steve >>> >>> It is unfair to say that yaws does not perform like misultin and I do >>> not have data to make that statement. When I think of performance, I >>> am also thinking of software development performance for modifying, >>> extending, and using the code-base. Yaws has lacked support once >>> mochiweb was available because of some fragmentation within the >>> community. From what I have seen, yaws chooses not to focus on >>> performance, and has never intended to do so in the past, so it is >>> unclear whether it would be able to maintain its performance in the >>> future, if it received more support (based on >>> http://steve.vinoski.net/blog/2011/05/09/erlang-web-server-benchmarking/). >>> So, that was misleading for me to say, since you are probably correct >>> that misultin is on par with yaws, though there are no public results >>> to show that. With yaws the concern seems to be more about the code >>> being regarded as legacy, not actively developed, and not modular (and >>> whatever other reasons that seemed to make mochiweb >>> appear necessary). I say this knowing that you are currently the main >>> maintainer of the code-base. These are just the impressions I have >>> had from being within the Erlang community for a few years. >>> >>> - Michael >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From ulf@REDACTED Fri Feb 17 09:33:54 2012 From: ulf@REDACTED (Ulf Wiger) Date: Fri, 17 Feb 2012 09:33:54 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: <4915914f-b378-43ab-9fcc-742980c2ee43@bs8g2000vbb.googlegroups.com> References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D991E.5000205@ninenines.eu> <4915914f-b378-43ab-9fcc-742980c2ee43@bs8g2000vbb.googlegroups.com> Message-ID: <2F937BFA-C379-4A90-ADD9-636A50116F71@feuerlabs.com> On 17 Feb 2012, at 03:09, Steve Davis wrote: > I'm a bit confused by this whole thread... > > I'm agreeing with Jesse that since Misultin is open source, it's not > really in your control to "stop development" if the interest is there > elsewhere to push it on? I read Roberto's announcement as saying that *he* would stop development on Misultin. I think it's admirable that he clearly declares his intentions. On occasion, someone else might pick up another component and move forward with it - like Joseph Norton has with UBF. Either way, it's good for users to know that the previous maintainer has moved on to other things, and why. BR, Ulf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Fri Feb 17 09:59:36 2012 From: ulf@REDACTED (Ulf Wiger) Date: Fri, 17 Feb 2012 09:59:36 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: <4F3D8C04.6040101@gmail.com> References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> Message-ID: On 17 Feb 2012, at 00:06, Michael Truog wrote: > With yaws the concern seems to be more about the code being regarded as legacy, not actively developed, and not modular (and whatever other reasons that seemed to make mochiweb > appear necessary). I think this is no longer true. My impression is that yaws development has picked up again, Looking at the change log for the releases in the past year or two [1], it is obvious that it is being actively maintained. This is also apparent from the github stats [2]. And yaws now comes with generic support for the various forms of JSON RPC (1.1 and 2.0), HAXE, SOAP, and even WebSockets. One of the few things I miss is WebMachine support. :) [1] http://yaws.hyber.org/ [2] https://github.com/klacke/yaws/contributors BR, Ulf W -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.virding@REDACTED Fri Feb 17 10:54:41 2012 From: robert.virding@REDACTED (Robert Virding) Date: Fri, 17 Feb 2012 09:54:41 -0000 (GMT) Subject: [erlang-questions] Inconsistent and incomprehensible handling of variables in spec's by compiler In-Reply-To: Message-ID: If in my file I add the sepc: -spec set_var(PrefixExp, Val, State) -> State. I get the compiler errors, errors mind you, not warnings: src/luerl_eval.erl:332: type variable 'PrefixExp' is only used once (is unbound) src/luerl_eval.erl:332: type variable 'Val' is only used once (is unbound) but if I write it as: -spec set_var(_PrefixExp, _Val, State) -> State. then the compiler is happy and is quiet. If I write it as: -spec set_var(Val, Val, State) -> State. (which is wrongly from my point of view) or go all verbose and write: -spec set_var(PrefixExp::any(), Val::any(), State::any()) -> State::any(). (which doesn't really add any useful information) the compiler is again happy and silent. This is inconsistent and does not make sense for variables in a function spec. Either it is wrong, for some incomprehensible reason, to have singleton variables in a function spec, or it shouldn't matter what the variable names are. And why should adding a type, even the most general one, make a difference to the variable name usage. And why should the compiler be bothered with the function spec at all seeing it is doesn't use it and it is not part of the language. In my naive view of the the typing world my original spec says that set_var/3 takes three arguments of any type and returns a value of the same type as the third argument. Then why not just add type information and make the compiler happy? Well in my case it doesn't give me anything; it makes the spec much longer and there is nothing in a type which would give me more information than is in the variable names. Also dialyzer doesn't actually *need* the spec as it works it out by itself anyway. And the type of PrefixExp is a big hairy recursive type which I am happy to let dialyzer work out for me. Typer gives me a half-screen long type for it. I get the same behaviour when running dialyzer on the different versions. Again I don't understand why it behaves like that. Robert From john.hughes@REDACTED Fri Feb 17 11:53:12 2012 From: john.hughes@REDACTED (John Hughes) Date: Fri, 17 Feb 2012 11:53:12 +0100 Subject: [erlang-questions] ExecutableUML and Erlang In-Reply-To: References: Message-ID: I've also looked at this. My conclusion was that it provides a nice graphical syntax for a particular domain, but has weak abilities to define additional abstractions on top. For example, just as in Erlang messages are delivered asynchronously to recipients. But if you want to define *synchronous* communication with a server on top of that, by including the Pid of the sender in the message and sending a reply back to that Pid, then you have a problem--because Pids are not first class in xtUML and cannot be sent in messages, because message destinations must be statically known and so your server must know all of its possible clients in advance, and because you cannot define new graphical syntax so as to use synchronous message sending with the same convenience as the asynchronous kind. Not impressed. John ----- Original Message ----- From: Olivier BOUDEVILLE To: erlang-questions@REDACTED Sent: Tuesday, February 14, 2012 4:31 PM Subject: [erlang-questions] ExecutableUML and Erlang Hi everyone, In echo to the older thread "UML or other modeling tools" (http://erlang.2086793.n4.nabble.com/UML-or-other-modeling-tools-td3205732.html), we happened to find an Ericsson presentation about ExecutableUML (http://www.cse.chalmers.se/edu/year/2010/course/MDSD/Year2010/Lectures/ExecutableUML_for_MDA_EricssonAB.pdf), which apparently was already able to generate Erlang code. This xtUML looks like a very interesting approach; in short we are contemplating to specify some domain-specific models that are involved in a discrete simulation, based on a proper high-level, formal, implementation-agnostic pivot format, targeting a few different simulation engines, one of which expecting models to be written in C++, another one expecting them in Erlang. So it looks like if our pivot format could be a flavour of xtUML (a special, constrained, case thereof). Is there any material (documentation and/or tool) that is publicly available, so that we could test this ExecutableUML-based approach? Any opinion in terms of completeness, applicability or maturity? Thanks in advance for any information! Best regards, Olivier. --------------------------- Olivier Boudeville EDF R&D : 1, avenue du G?n?ral de Gaulle, 92140 Clamart, France D?partement SINETICS, groupe ASICS (I2A), bureau B-226 Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47 65 27 13 Ce message et toutes les pi?ces jointes (ci-apr?s le 'Message') sont ?tablis ? l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme ? sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. Si vous n'?tes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez re?u ce Message par erreur, merci de le supprimer de votre syst?me, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions ?galement d'en avertir imm?diatement l'exp?diteur par retour du message. Il est impossible de garantir que les communications par messagerie ?lectronique arrivent en temps utile, sont s?curis?es ou d?nu?es de toute erreur ou virus. ____________________________________________________ This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message. E-mail communication cannot be guaranteed to be timely secure, error or virus-free. ------------------------------------------------------------------------------ _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.henoch@REDACTED Fri Feb 17 12:49:09 2012 From: magnus.henoch@REDACTED (Magnus Henoch) Date: Fri, 17 Feb 2012 11:49:09 -0000 (GMT) Subject: [erlang-questions] [erlang-bugs] Inconsistent and incomprehensible handling of variables in spec's by compiler In-Reply-To: Message-ID: There is a big difference between this: > -spec set_var(PrefixExp, Val, State) -> State. and this: > -spec set_var(PrefixExp::any(), Val::any(), State::any()) -> State::any(). The argument and return value type specifications are either Type or Name::Type, so the first declaration says that the arguments are of _types_ PrefixExp, Val and State, while the second declaration says that all three arguments are of type any(). (As far as I know, argument names are ignored by the compiler and dialyzer, and only used by edoc.) Specifying a singleton variable as the _type_ of an argument is most likely not what the programmer meant, since it doesn't add any information, so to me it makes sense to have the compiler reject it. That specification could be written like this: -spec set_var(PrefixExp::any(), Val::any(), State::X) -> NewState::X. which specifies that State and NewState must have the same type, no matter which one. Hope this helps, -- Magnus Henoch Erlang Solutions Ltd http://www.erlang-solutions.com/ From matthias@REDACTED Fri Feb 17 14:35:45 2012 From: matthias@REDACTED (Matthias Lang) Date: Fri, 17 Feb 2012 14:35:45 +0100 Subject: [erlang-questions] Sergey Aleynikov (Ex Goldman) acquitted Message-ID: <20120217133545.GA25654@corelatus.se> Hi, Offtopic, but Serge used to contribute to erlang-questions quite a bit: http://dealbook.nytimes.com/2012/02/17/court-overturns-conviction-of-ex-goldman-programmer/ http://www.ca2.uscourts.gov/decisions/isysquery/f247ec41-8374-4be3-a2af-2cfad0631f49/1/doc/11-1126_2.pdf#xml=http://www.ca2.uscourts.gov/decisions/isysquery/f247ec41-8374-4be3-a2af-2cfad0631f49/1/hilite/aleynikov/ I have no idea what actually happened, I don't know Serge and I know basically nothing about legal systems, though I've watched a few episodes of Rumpole. Matt From ulf@REDACTED Fri Feb 17 15:24:06 2012 From: ulf@REDACTED (Ulf Wiger) Date: Fri, 17 Feb 2012 15:24:06 +0100 Subject: [erlang-questions] Sergey Aleynikov (Ex Goldman) acquitted In-Reply-To: <20120217133545.GA25654@corelatus.se> References: <20120217133545.GA25654@corelatus.se> Message-ID: <633222A5-9B30-4E26-98FE-2EEE79EEEE40@feuerlabs.com> Indeed a promising development for Serge! I think this was a bit extraordinary: On February 16, 2012, the United States Court of Appeals for the Second Circuit heard oral argument on his appeal and, later that same day, ordered his conviction reversed and a judgment of acquittal entered, with opinion to follow. The same day, after hearing oral arguments? This has been going on since 2009! More info on the original conviction here: http://tsi.brooklaw.edu/cases/united-states-v-aleynikov/reports/case-report-united-states-v-aleynikov "At best, the Aleynikov case looks like an attempt by federal prosecutors and the courts to set a strong example that this sort of conduct will not be tolerated. " And more info on the acquittal here: http://mobile.bloomberg.com/news/2012-02-17/ex-goldman-programmer-s-conviction-overturned-on-appeal?category=%2F Interestingly, inflation has expanded the amount of code copied from "thousands of lines of code" to "hundreds of thousand lines". BR, Ulf W On 17 Feb 2012, at 14:35, Matthias Lang wrote: > Hi, > > Offtopic, but Serge used to contribute to erlang-questions quite a bit: > > http://dealbook.nytimes.com/2012/02/17/court-overturns-conviction-of-ex-goldman-programmer/ > http://www.ca2.uscourts.gov/decisions/isysquery/f247ec41-8374-4be3-a2af-2cfad0631f49/1/doc/11-1126_2.pdf#xml=http://www.ca2.uscourts.gov/decisions/isysquery/f247ec41-8374-4be3-a2af-2cfad0631f49/1/hilite/aleynikov/ > > I have no idea what actually happened, I don't know Serge and I know > basically nothing about legal systems, though I've watched a few > episodes of Rumpole. > > Matt > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Fri Feb 17 15:31:57 2012 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 17 Feb 2012 15:31:57 +0100 Subject: [erlang-questions] ANNOUNCE: adapter_pattern for mochiweb/cowboy/misult and scripting language Message-ID: This is an experiment - but the code is rather pretty so it might be of interest. https://github.com/joearms/adapter_pattern What's this all about? Mochweb, misultin and cowboy all have *different* interfaces I don't like this. I have made a simple generic interface to all three. Yesterdays announcement that misultin would not be supported in the future sparked off this work - I'd been thinking about how to abuse paramerised modules for a while so this seemed like a golden opportunity. I also threw in a web scripting language called EHE. EHE is "Html with embedded Erlang" So has characters would print out "joe has 3 characters" - inside the we expect a sequence of Erlang expressions. The replacement value is the value of the *last* expression in the sequence which must be a string. Bindings are forward propagated in the script. That's it. Although this is *very* simple it is also very powerful (ie it has the full power of all of erlang) It is also very easy to embed into your favorite web server - the example on github shows how to embed ehe into mochiweb/misultin and cowboy. It would seem to me to be advantageous to agree to use EHE (or something better) on all available erlang web-servers - since a common langage would encourage code sharing and so on (like PHP) Take a look? Is this the right way to go? Cheers /Joe From erlang@REDACTED Fri Feb 17 15:39:48 2012 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 17 Feb 2012 15:39:48 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: Message-ID: Thanks for all your hard work Roberto - I've been a fan of Misultin for a while now. I always choose the code with the best documentation since I don't care about efficiency. So thanks once again for your efforts. BWT I posted https://github.com/joearms/adapter_pattern today - this provides a 100% identical interface to mochiweb, misultin and cowboy (and a scripting language EHE) which should remove some of the pain of moving from misultin to "something else". Cheers /Joe On Thu, Feb 16, 2012 at 4:56 PM, Roberto Ostinelli wrote: > Dear list, > > Misultin development has been discontinued. > > There currently are three main webserver libraries which basically do > similar things: > > Mochiweb > Cowboy > Misultin > > Especially since the recent heavy development of Cowboy's HTTP server, I > believe there is way too much duplication of efforts going on here. This is > why Misultin's current 'state of the art' has been frozen in the latest tag, > v0.9, to support all the companies currently using Misultin in their > production environment. I'm here to provide help, if needed, in moving away > from it. Thus, this server should be robust and stable enough to continue > serving your needs for some time. > > Instead of letting this library stand on github without notice, and getting > developers still use this project, I have preferred to explicitly state to > gradually move away from it, so that efforts can be concentrated around one > server library only. It's hard enough to let one 'child' like this one go, > but I believe it's best for the whole Erlang community. There are many ways > to try to help each other in the community, I believe this decision is now > for the better. > > Mochiweb has been around the block for a while and it's proven solid in > production, I can only recommend it for all basic webserver needs you might > have. Cowboy has a very interesting approach since it allows to use multiple > TCP and UDP protocols on top of a common acceptor pool. It is a very modern > approach, is very actively maintained and many projects are starting to be > built around it. > > I'll personally concentrate my efforts around Cowboy, simply because the > projects I'm involved in often require multiple procotols. I really hope > that it'll live up to the expectations that I'm putting into this. > > Thank you to everyone that has been supporting Misultin in these years. > Hopefully its code usability, which I still believe to be unmatched (well, I > have developed it so how could I feel differently about this ^^_), will > provide inspiration for some library interfaces. > > Best to you all, > > r. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From steven.charles.davis@REDACTED Fri Feb 17 15:57:34 2012 From: steven.charles.davis@REDACTED (Steve Davis) Date: Fri, 17 Feb 2012 08:57:34 -0600 Subject: [erlang-questions] Misultin EOL In-Reply-To: <2F937BFA-C379-4A90-ADD9-636A50116F71@feuerlabs.com> References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D991E.5000205@ninenines.eu> <4915914f-b378-43ab-9fcc-742980c2ee43@bs8g2000vbb.googlegroups.com> <2F937BFA-C379-4A90-ADD9-636A50116F71@feuerlabs.com> Message-ID: <4F3E6ADE.1020704@gmail.com> On 2/17/2012 2:33 AM, Ulf Wiger wrote: > I read Roberto's announcement as saying that *he* would stop development > on Misultin. I think it's admirable that he clearly declares his intentions. OK, fair enough -- I guess I was diverted by the title of the thread "Misultin EOL" which I read as the end of life for Misultin as an application library. /s From ebegumisa@REDACTED Fri Feb 17 15:57:15 2012 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Sat, 18 Feb 2012 01:57:15 +1100 Subject: [erlang-questions] ANNOUNCE: adapter_pattern for mochiweb/cowboy/misult and scripting language In-Reply-To: References: Message-ID: On Sat, 18 Feb 2012 01:31:57 +1100, Joe Armstrong wrote: > This is an experiment - but the code is rather pretty so it might be > of interest. > > https://github.com/joearms/adapter_pattern > > What's this all about? Mochweb, misultin and cowboy all have > *different* interfaces > I don't like this. I have made a simple generic interface to all three. > > Yesterdays announcement that misultin would not be supported in the > future > sparked off this work - I'd been thinking about how to abuse > paramerised modules for a while > so this seemed like a golden opportunity. > > I also threw in a web scripting language called EHE. EHE is "Html with > embedded Erlang" > > So has characters > > would print out "joe has 3 characters" - inside the we > expect a sequence of > Erlang expressions. The replacement value is the value of the *last* > expression in the > sequence which must be a string. Bindings are forward propagated in the > script. > > That's it. > > Although this is *very* simple it is also very powerful (ie it has the > full power of all of erlang) > > It is also very easy to embed into your favorite web server - the > example on github shows how > to embed ehe into mochiweb/misultin and cowboy. > > It would seem to me to be advantageous to agree to use EHE (or > something better) on all > available erlang web-servers - since a common langage would encourage > code sharing and so on > (like PHP) > EHE reminds me of Yariv's ErlTL which I very much like... https://github.com/yariv/erlyweb/blob/master/src/erltl/erltl.erl http://yarivsblog.blogspot.com.au/2006/10/introducing-erltl-simple-erlang.html http://yarivsblog.blogspot.com.au/2006/10/erltl-091.html ErlTL has some nice features, perhaps these two could be combined. - Edmond - > Take a look? > > Is this the right way to go? > > Cheers > > /Joe > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From vinoski@REDACTED Fri Feb 17 16:06:11 2012 From: vinoski@REDACTED (Steve Vinoski) Date: Fri, 17 Feb 2012 10:06:11 -0500 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> Message-ID: On Fri, Feb 17, 2012 at 3:59 AM, Ulf Wiger wrote: > > On 17 Feb 2012, at 00:06, Michael Truog wrote: > > With yaws the concern seems to be more about the code being regarded as > legacy, not actively developed, and not modular (and whatever other reasons > that seemed to make mochiweb > appear necessary). > > > I think this is no longer true. My impression is that yaws development has > picked up again, Looking at the change log for the releases in the past year > or two [1], it is obvious that it is being actively maintained. This is also > apparent from the github stats [2]. And yaws now comes with generic support > for the various forms of JSON RPC (1.1 and 2.0), HAXE, SOAP, and even > WebSockets. One of the few things I miss is WebMachine support. :) > > [1]?http://yaws.hyber.org/ > [2]?https://github.com/klacke/yaws/contributors Very true, Ulf. And we'll get you that webmachine support soon. And Michael, another way anyone can see how active yaws development is is to simply look at the commits: https://github.com/klacke/yaws/commits/master This approach would seem vastly preferable to spreading inaccurate and irresponsible rumors on this mailing list about yaws not being actively developed. I've been using yaws for the past 5 years, much of it in a production embedded system, and it's been actively developed for all 5 of those years. Yaws is now in its 11th year of active development. Regarding yaws modularity, I keep hearing this rumor that it lacks in that regard, yet nobody has yet pointed out any specifics. If someone were to point out things they think are too intertwined, then Klacke, Christopher Faulet, or I -- those with commit rights to the yaws repo -- could at least consider fixing them, as could anyone else with an interest in providing a patch. But in the absence of anything concrete, it's hard to take action. Note that the production embedded system I mentioned earlier doesn't use SOAP or haxe or websockets or numerous other yaws features, and in fact doesn't even include them, plus it runs embedded within a larger application, not as a stand-alone server. If it truly lacked modularity, or if it weren't usable in a library-like fashion, none of that would be possible. Earlier in this thread we have this gem from Lo?c: > I'm sad to see Misultin go, this was in my opinion the only other project that had enough > momentum to introduce innovation in Erlang web servers. Wow. At best, this is simply ignorant on several fronts. At worst, it's insulting to Klacke, Bob Ippolito, me and others who've put a lot of work into their Erlang web servers and continue to do so. Hell, Erlang wouldn't be where it is today without all the features Klacke put into it, and I doubt Erlang web systems would be as far along as they are now without Klacke's and Bob's continued contributions and deployments into real products in years where most of us hadn't even started using Erlang yet. Part of the reason Roberto has taken this new action regarding misultin is that he wants the Erlang web community to become more cohesive, reusing each other's work instead of competing with each other, but irresponsible statements like this one from Lo?c don't help Roberto's cause at all. If we truly want the Erlang web dev community to become less fractured so it can grow, taking cheap shots at each other won't get us there. Yaws exists and continues to exist because people continue to use it in real-life production systems. Klacke, Christopher, and I all have day jobs, so whatever time we put into yaws is based on what users are asking for. What makes it real interesting and fun is to fit new features like websockets into a system without it being an ugly hack and without breaking everything else that's already there, and we intend to continue to do exactly that. Perhaps worst of all about parts of this thread, though, is that from what I've seen over the past few years, those spreading these unfounded rumors about yaws being old and creaky and slow and legacy and not actively developed and not usable for their projects never once contacted Klacke or me or the erlyaws mailing list about questions or issues with the system. They've never attempted to contribute to the system with features or patches. I therefore suspect that they just listened to the same recurring unfounded gossip and made up their mind that way. Unfortunate, if true. But surely it's not asking too much to request that, going forward, people at least do their homework, try things out, and maybe ask some questions before stating "facts" that simply aren't true about yaws, or mochiweb, or any other such systems? --steve From g@REDACTED Fri Feb 17 16:13:11 2012 From: g@REDACTED (Garrett Smith) Date: Fri, 17 Feb 2012 09:13:11 -0600 Subject: [erlang-questions] Multiple db connection drivers In-Reply-To: References: Message-ID: Hi Erisa, On Thu, Feb 16, 2012 at 8:15 AM, Erisa Dervishi wrote: > Hi everybody, > > I am an erlang newbie, and I am doing a survey on existing Erlang db access > drivers. I am most interested in drivers that can handle and process > multiple concurrent db requests. Are there any working Erlang multithread db > access drivers for MySql or PostgreSQL? What about BerkleyDB? Or any other > Erlang driver that can handle db requests in parallel? > There are plenty of drivers out there, but no documentation at all, and I am > not experienced enough to find out the ones I'm interested in. > I would be really glad if you could provide me some links or valuable > suggestions. Erlang has so many amazing features and benefits, it's hard to keep track! Database interfaces, however, is not on that list :) That's a broad, sweeping statement that leaves me open to easy criticism! But I think if you're coming from a Java or .NET background, it's hard to not scratch your head at the state of the available libraries. Erisa, I would suggest first identifying which database(s) you'd like to target, and then dig into what's available. You are likely to find something that works, even works very well. If it's not clear which database to look at, post your use cases and you'll probably get a deluge of suggestions here. Keep in mind that Erlang does not have a tradition of "ORMs" the way Java, Ruby, Python, etc. do. You'll need to dive into the details of whatever data stores you end up working with. I personally think this is a benefit, but it does take more energy up front to consider your requirements and learn the technology. Garrett From essen@REDACTED Fri Feb 17 16:13:54 2012 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Fri, 17 Feb 2012 16:13:54 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> Message-ID: <4F3E6EB2.3000505@ninenines.eu> On 02/17/2012 04:06 PM, Steve Vinoski wrote: > Earlier in this thread we have this gem from Lo?c: >> I'm sad to see Misultin go, this was in my opinion the only other project that had enough >> momentum to introduce innovation in Erlang web servers. I'm sorry if you misunderstood this but you also provide the reason why I have that opinion. > Yaws exists and continues to exist because people continue to use it > in real-life production systems. Klacke, Christopher, and I all have > day jobs, so whatever time we put into yaws is based on what users are > asking for. Misultin and Cowboy are still at a point in the projects' life where features continue being added or improved before users request them, not the other way around. They can also afford to break the API a little if a better solution exists, since both of them aren't considered stable at this point. That's all I meant. -- Lo?c Hoguin Erlang Cowboy Nine Nines From g@REDACTED Fri Feb 17 16:47:06 2012 From: g@REDACTED (Garrett Smith) Date: Fri, 17 Feb 2012 09:47:06 -0600 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: On Thu, Feb 16, 2012 at 3:17 PM, Steve Vinoski wrote: > On Thu, Feb 16, 2012 at 3:50 PM, Michael Truog wrote: >>?Is cowboy going to be able to take the lead on HTTP Erlang web server performance where mochiweb and yaws have been unable to (please don't bother to flame this, those people that don't care about performance, but care about Erlang)? > > I'm not interested in flames either, but I am interested in facts. > Please back up your assertion by posting your meaningful benchmarks > that prove that Yaws is lacking in performance. FWIW, I spent some time looking at HTTP servers a couple years ago in developing Landshark [1], which uses Mochiweb. I found that *any* Erlang HTTP server, and certainly YAWs, was decisively both faster and more resilient to faults than the other language environment options I looked at, which the exception of mod_php, which also fared very well. [2] That said, I place little credence in these sorts of benchmarks. They provide data, but it's not always clear what you can correctly infer from them. We do have a tendency to get our rulers out and start measuring, even if what we're measuring is completely pointless [3]. I've also observed that developers will, for whatever reason, go to incredible lengths to eek out even the slightest performance gains in the web tier [4]. In every large scale Web application I've seen though, the web tier is not a bottleneck -- it's the data tier that gives us fits. Of course there are exceptions, but if performance is that critical, there's C! Garrett [1] Landshark was my first Erlang project and is now totally defunct. I'm a proponent of modlib - https://github.com/gar1t/modlib - which is a supplement to Erlang's built in httpd server. [2] https://github.com/gar1t/landshark/blob/master/doc/benchmarks.txt [3] http://www.youtube.com/watch?v=xEJ1n13soWU [4] http://www.youtube.com/watch?v=bzkRVzciAZg From michal.ptaszek@REDACTED Fri Feb 17 16:48:53 2012 From: michal.ptaszek@REDACTED (Michal Ptaszek) Date: Fri, 17 Feb 2012 16:48:53 +0100 Subject: [erlang-questions] VM using only 2 out of 8 schedulers available In-Reply-To: References: Message-ID: <10DE79B8-D9DA-4765-9D5E-71D87E4F62F4@erlang-solutions.com> Hi Knut, have you tried to play with scheduler wakeup thresholds? I would probably try running beam with '+swt very_low' (see http://erlang.org/doc/man/erl.html for details). Best regards, Michal Ptaszek On Feb 16, 2012, at 5:00 PM, Knut Nesheim wrote: > Hi, > > We just tried moving more load to the node using only two schedulers. > The VM is using 100% cpu on the two cores, with a run queue hovering > between 50 and 100 processes. There is no change in active schedulers. > > As far as I can see, the load is now at a point where the schedulers > should become active. Is there anything we can do to understand more > about why this is not happening? > > Knut > > On Thu, Feb 16, 2012 at 10:19 AM, Knut Nesheim wrote: >> Thanks for a quick reply. >> >> During the GMT night which is our low point, we see quite low traffic >> on each machine with maybe 5% cpu utilization of each of the 8 cores. >> This could explain why some schedulers are put as idle. When traffic >> picks up, we're using around 25% of each core. >> >> The problem for us is that when traffic picks up again, the VM did not >> start using the idle schedulers again. erlang:statistics(run_queue) >> reports that there almost always are processes waiting, with peaks of >> around 20 processes in our case. This causes much higher latency than >> when using all cores. >> >> We will try pushing more load to this node to see if it starts using >> the idle schedulers. >> >> Thanks >> Knut >> >> On Thu, Feb 16, 2012 at 8:01 AM, Kenneth Lundin >> wrote: >>> What is your real problem except that there is no reported cpu load on some >>> of the cores? >>> >>> When there is low load on the system i.e. when there are too few runnable >>> Erlang processes some of the schedulers will automatically be put as idle >>> letting the remaining schedulers run all processes. When the load increases >>> the idle schedulers will be taken into service again. >>> >>> Each scheduler normally runs on one processor core. >>> >>> Can this explain what you have observed? >>> >>> /Kenneth Erlang/OTP Ericsson >>> >>> Den 15 feb 2012 17:53 skrev "Knut Nesheim" : >>>> >>>> Dear list, >>>> >>>> From time to time we see the VM using only some of the available >>>> cores. Typically 2 or 4 out of 8 available cores will be busy, while >>>> the others are not used at all. From 'top' and 'htop' we see only some >>>> cores being used. >>>> >>>> We are running the halfword emulator on 8 core machines and the VM is >>>> correctly reporting the number of schedulers and the underlying >>>> topology. The nodes are utilizing roughly 25% of each of the 8 cores >>>> during normal operation. >>>> >>>> This problem appeared again today and we still have the process >>>> running if anyone has any ideas for how to debug the issue. >>>> >>>> We are on Ubuntu 10.04 LTS, 2.6.32-342-ec2, 64bit, R14B04 with the >>>> halfword emulator. The only NIF library we are using is jiffy. >>>> >>>> Regards >>>> Knut >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> 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 ebegumisa@REDACTED Fri Feb 17 16:57:35 2012 From: ebegumisa@REDACTED (Edmond Begumisa) Date: Sat, 18 Feb 2012 02:57:35 +1100 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> Message-ID: Perhaps there is some lack of knowldege about the variety of things yaws can do, and the ease with which it can do them. I have a *single* permanent local yaws server on my dev laptop running several unrelated apps, some of which have nothing to do with Erlang... * One port serves a local copy of Erlang OTP documentation searchable via the Xapian Omega CGI app (it took me 2 minutes to get that first working.) * One port serves a local 200 GB copy of the Mozilla Developer Network also searchable via Xapian Omega CGI. * One port points to a directory that has ediable-links I use to point to whatever Erlang web-apps I'm currently developing, which I usually deploy to customers without trouble. * Another port I use to serve XUL/JS files for Mozilla XULRunner development. How can anyone find yaws lacking? - Edmond - On Sat, 18 Feb 2012 02:06:11 +1100, Steve Vinoski wrote: > On Fri, Feb 17, 2012 at 3:59 AM, Ulf Wiger wrote: >> >> On 17 Feb 2012, at 00:06, Michael Truog wrote: >> >> With yaws the concern seems to be more about the code being regarded as >> legacy, not actively developed, and not modular (and whatever other >> reasons >> that seemed to make mochiweb >> appear necessary). >> >> >> I think this is no longer true. My impression is that yaws development >> has >> picked up again, Looking at the change log for the releases in the past >> year >> or two [1], it is obvious that it is being actively maintained. This is >> also >> apparent from the github stats [2]. And yaws now comes with generic >> support >> for the various forms of JSON RPC (1.1 and 2.0), HAXE, SOAP, and even >> WebSockets. One of the few things I miss is WebMachine support. :) >> >> [1] http://yaws.hyber.org/ >> [2] https://github.com/klacke/yaws/contributors > > Very true, Ulf. And we'll get you that webmachine support soon. > > And Michael, another way anyone can see how active yaws development is > is to simply look at the commits: > > https://github.com/klacke/yaws/commits/master > > This approach would seem vastly preferable to spreading inaccurate and > irresponsible rumors on this mailing list about yaws not being > actively developed. I've been using yaws for the past 5 years, much of > it in a production embedded system, and it's been actively developed > for all 5 of those years. Yaws is now in its 11th year of active > development. > > Regarding yaws modularity, I keep hearing this rumor that it lacks in > that regard, yet nobody has yet pointed out any specifics. If someone > were to point out things they think are too intertwined, then Klacke, > Christopher Faulet, or I -- those with commit rights to the yaws repo > -- could at least consider fixing them, as could anyone else with an > interest in providing a patch. But in the absence of anything > concrete, it's hard to take action. > > Note that the production embedded system I mentioned earlier doesn't > use SOAP or haxe or websockets or numerous other yaws features, and in > fact doesn't even include them, plus it runs embedded within a larger > application, not as a stand-alone server. If it truly lacked > modularity, or if it weren't usable in a library-like fashion, none of > that would be possible. > > Earlier in this thread we have this gem from Lo?c: >> I'm sad to see Misultin go, this was in my opinion the only other >> project that had enough >> momentum to introduce innovation in Erlang web servers. > > Wow. At best, this is simply ignorant on several fronts. At worst, > it's insulting to Klacke, Bob Ippolito, me and others who've put a lot > of work into their Erlang web servers and continue to do so. Hell, > Erlang wouldn't be where it is today without all the features Klacke > put into it, and I doubt Erlang web systems would be as far along as > they are now without Klacke's and Bob's continued contributions and > deployments into real products in years where most of us hadn't even > started using Erlang yet. Part of the reason Roberto has taken this > new action regarding misultin is that he wants the Erlang web > community to become more cohesive, reusing each other's work instead > of competing with each other, but irresponsible statements like this > one from Lo?c don't help Roberto's cause at all. If we truly want the > Erlang web dev community to become less fractured so it can grow, > taking cheap shots at each other won't get us there. > > Yaws exists and continues to exist because people continue to use it > in real-life production systems. Klacke, Christopher, and I all have > day jobs, so whatever time we put into yaws is based on what users are > asking for. What makes it real interesting and fun is to fit new > features like websockets into a system without it being an ugly hack > and without breaking everything else that's already there, and we > intend to continue to do exactly that. > > Perhaps worst of all about parts of this thread, though, is that from > what I've seen over the past few years, those spreading these > unfounded rumors about yaws being old and creaky and slow and legacy > and not actively developed and not usable for their projects never > once contacted Klacke or me or the erlyaws mailing list about > questions or issues with the system. They've never attempted to > contribute to the system with features or patches. I therefore suspect > that they just listened to the same recurring unfounded gossip and > made up their mind that way. Unfortunate, if true. But surely it's not > asking too much to request that, going forward, people at least do > their homework, try things out, and maybe ask some questions before > stating "facts" that simply aren't true about yaws, or mochiweb, or > any other such systems? > > --steve > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From ulf@REDACTED Fri Feb 17 17:10:04 2012 From: ulf@REDACTED (Ulf Wiger) Date: Fri, 17 Feb 2012 17:10:04 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> Message-ID: On 17 Feb 2012, at 16:06, Steve Vinoski wrote: > On Fri, Feb 17, 2012 at 3:59 AM, Ulf Wiger wrote: >> >> >> I think this is no longer true. My impression is that yaws development has >> picked up again, Looking at the change log for the releases in the past year >> or two [1], it is obvious that it is being actively maintained. This is also >> apparent from the github stats [2]. And yaws now comes with generic support >> for the various forms of JSON RPC (1.1 and 2.0), HAXE, SOAP, and even >> WebSockets. One of the few things I miss is WebMachine support. :) >> >> [1] http://yaws.hyber.org/ >> [2] https://github.com/klacke/yaws/contributors > > Very true, Ulf. And we'll get you that webmachine support soon. I knew you wouldn't be able to resist, Steve. :-) FWIW, as has perhaps become evident, as we needed to pick a web server here at Feuerlabs, we had an open-ended discussion about the different alternatives, then decided to go with Yaws. First off, we will do our best to steer clear of tying ourselves to hard to any particular web server API, but I don't see that as a big problem. If we decide to change later on, it will be a small effort in our case. We chose to start with yaws for exactly the reasons that have come up here. It's battle-proven, has remained stable over the years, and doesn't appear to have any big problems keeping up with the new kids on the block in terms of speed (at least within the margin of uncertainty given that Yaws really does strive hard to be fully compliant - something that means something to us, as it will be the point of interface for our external customers). What impresses with Yaws is its long track record and feature list, and a quick look at the development activity made it obvious that it is being very well looked after. That said, the energy around Cowboy is impressive too. Our choice was not a vote *against* Cowboy, but rather a vote of confidence for Yaws. We have other fish to fry. Steve, I'll be expecting a nice cold beer when we see each other at the SF Erlang Factory. ;-) BR, Ulf W -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.andin@REDACTED Fri Feb 17 17:57:28 2012 From: ingela.andin@REDACTED (Ingela Andin) Date: Fri, 17 Feb 2012 17:57:28 +0100 Subject: [erlang-questions] dh_anon SSL connection failed In-Reply-To: <006b01ccecac$d466aad0$7d340070$@gmail.com> References: <002e01ccd43f$816f1270$844d3750$@gmail.com> <005b01ccd47a$84fd4070$8ef7c150$@gmail.com> <006b01ccecac$d466aad0$7d340070$@gmail.com> Message-ID: Hi! Well I have not had time until today. The problem is that the keyexchange for anonymous suites was expected by our code to be ?SERVER_KEY_EXCHANGE, <> but atleas sometimes it will be SERVER_KEY_EXCHANGE, <> I need to revisit the spec to figure out if we shall expect both or if it should always be the latter. Regards Ingela Erlang/OTP team - Ericsson AB 2012/2/16, Alexander Hudich : > Hi, Ingela! > > You wrote: > >> Hum ... interesting it could be so that SSLv23_client_method() is more > forgiving in some way and that your server has a bug... I will try to look > into this more when I get time. If you come up with >> something in the meantime pleas let me know. > > I wonder if you had any chance for further investigation of this problem? I > remember I sent you openssl connection dump and as I saw that openssl > always uses SSLv2/v3 method even if I pointed -no_ssl2 option explicitly. > May be that's a way which have to be chosen to have ability to make > connections with SSLv23_server_method() servers? I understand that SSL2 > unsecured and it won't be supported, but it's really important to be able to > make SSLv3 and TLSv1 connections with SSLv23_server_method() servers. Maybe > there should be an option which version of SSL handshake hello should be > sent? > > $openssl s_client -connect ip:5666 -state -debug -no_ssl2 -cipher ADH > > SSL_connect:before/connect initialization > SSL_connect:SSLv2/v3 write client hello A > SSL_connect:SSLv3 read server hello A > SSL_connect:SSLv3 read server key exchange A > SSL_connect:SSLv3 read server done A > SSL_connect:SSLv3 write client key exchange A > SSL_connect:SSLv3 write change cipher spec A > SSL_connect:SSLv3 write finished A > SSL_connect:SSLv3 flush data > SSL_connect:SSLv3 read server session ticket A > SSL_connect:SSLv3 read finished A > > > > > -----Original Message----- > From: Ingela Andin [mailto:ingela.andin@REDACTED] > Sent: Wednesday, January 18, 2012 12:39 PM > To: alttagil@REDACTED; Erlang > Subject: Re: [erlang-questions] dh_anon SSL connection failed > > Hi! > > 2012/1/16 Alexander Hudich : >> Hi, Ingela! >> >>>> This is kind of excerpt from check_nrpe code which connects just fine: >>>> >>>>SSL_library_init(); >>>>SSLeay_add_ssl_algorithms(); >>>>meth=SSLv23_client_method(); >>>>SSL_load_error_strings(); >>>>ctx=SSL_CTX_new(meth)); >>>>SSL_CTX_set_options(ctx,SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3); >>>>result=my_tcp_connect(server_name,server_port,&sd); >>>> >>>> /* do SSL handshake */ >>>> >>>> if(result==STATE_OK && use_ssl==TRUE){ >>>> if((ssl=SSL_new(ctx))!=NULL){ >>>> SSL_CTX_set_cipher_list(ctx,"ADH"); >>>> SSL_set_fd(ssl,sd); >>>> rc=SSL_connect(ssl)); >>>> } >>>>} >> >>> What cipher suite and SSL/TLS-protocol version will this code end up >> using? >> >> >> I have not very much experience in development with using SSL connections. >> So I don't know if I've done it's right I added this line after >> SSL_connect to get current information about established SSL >> connection in check_nrpe: >> >> printf( "CIPHER %s %s\n", SSL_CIPHER_get_name( >> SSL_get_current_cipher(ssl) ), SSL_CIPHER_get_version( >> SSL_get_current_cipher(ssl) ) ); >> >> And it gives: >> >> CIPHER ADH-AES256-SHA TLSv1/SSLv3 >> >> Also I tried to change SSLv23_client_method() call to > SSLv3_client_method(). >> And that gave very interesting result: >> >> CHECK_NRPE: Error - Could not complete SSL handshake. >> SSL_connect=0 >> 36071:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert >> handshake failure:s3_pkt.c:1102:SSL alert number 40 >> >> That looks pretty similar to what I get with a result that erlang >> ssl:connect call returns. >> > > Hum ... interesting it could be so that SSLv23_client_method() is more > forgiving in some way and that your server has a bug... I will try to look > into this more when I get time. If you come up with something in the > meantime pleas let me know. > >>>> Erlang R16B (erts-5.10) [source] [64-bit] [smp:1:1] >>>> [async-threads:0] [hipe] [kernel-poll:false] >>>> 5> SockOpts. >>>> [{active,false}, >>>> {ssl_imp,old}, >> >> >>>This is not a relevant option after R15B ( it will always be new even >>>if >> you write old). >> >> Yes I know that, it was just an act of despair :) >> >> >> >>>> {verify,verify_none}, >>>> {ciphers,[{dh_anon,rc4_128,md5}, >>>> {dh_anon,des_cbc,sha}, >>>> {dh_anon,'3des_ede_cbc',sha}, >>>> {dh_anon,aes_128_cbc,sha}, >>>> {dh_anon,aes_256_cbc,sha}]}] >>>> >>>> 6> ssl:connect( Ip, 5666, SockOpts, infinity). >>>> >>>> =ERROR REPORT==== 16-Jan-2012::12:49:23 === >>>> SSL: hello: ssl_handshake.erl:885:Fatal error: handshake failure >>>> {error,esslconnect} What do you think is it possible to make this >>>> type of connection in >> Erlang? >>>> What else can I try or is it a bug? >> >>> Our test cases for anonymous suites works just fine. Have you tried >> running the test case anonymous_cipher_suites in ssl_basic_SUITE? >> >> How can I do that? > > See description under testing in erlang patch instructions: > > https://github.com/erlang/otp/wiki/submitting-patches > >> >>> Servers will normally not support anonymous cipher suites and we >>> include >> them only for test purposes and they may only be used if explicitly >> supplied. >> >> I thought that I explicitly pointed to use that anonymous ciphers by >> supplying them in connection options. Or there is something else I >> should do? > > By supplying them in the connection options you will make the client try to > connect to the server with those suites but it does not necessarily mean > that the server supports them and will let you set up the connection. > However your server seeems to support {dh_anon,aes_256_cbc,sha} ( > ADH-AES256-SHA ). > > Regards Ingela Erlang/OTP team - Ericsson AB > > From mjtruog@REDACTED Fri Feb 17 18:59:41 2012 From: mjtruog@REDACTED (Michael Truog) Date: Fri, 17 Feb 2012 09:59:41 -0800 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> Message-ID: <4F3E958D.60008@gmail.com> On 02/17/2012 07:06 AM, Steve Vinoski wrote: > On Fri, Feb 17, 2012 at 3:59 AM, Ulf Wiger wrote: >> On 17 Feb 2012, at 00:06, Michael Truog wrote: >> >> With yaws the concern seems to be more about the code being regarded as >> legacy, not actively developed, and not modular (and whatever other reasons >> that seemed to make mochiweb >> appear necessary). >> >> >> I think this is no longer true. My impression is that yaws development has >> picked up again, Looking at the change log for the releases in the past year >> or two [1], it is obvious that it is being actively maintained. This is also >> apparent from the github stats [2]. And yaws now comes with generic support >> for the various forms of JSON RPC (1.1 and 2.0), HAXE, SOAP, and even >> WebSockets. One of the few things I miss is WebMachine support. :) >> >> [1] http://yaws.hyber.org/ >> [2] https://github.com/klacke/yaws/contributors > Very true, Ulf. And we'll get you that webmachine support soon. > > And Michael, another way anyone can see how active yaws development is > is to simply look at the commits: > > https://github.com/klacke/yaws/commits/master > > This approach would seem vastly preferable to spreading inaccurate and > irresponsible rumors on this mailing list about yaws not being > actively developed. I've been using yaws for the past 5 years, much of > it in a production embedded system, and it's been actively developed > for all 5 of those years. Yaws is now in its 11th year of active > development. > > Regarding yaws modularity, I keep hearing this rumor that it lacks in > that regard, yet nobody has yet pointed out any specifics. If someone > were to point out things they think are too intertwined, then Klacke, > Christopher Faulet, or I -- those with commit rights to the yaws repo > -- could at least consider fixing them, as could anyone else with an > interest in providing a patch. But in the absence of anything > concrete, it's hard to take action. > > Note that the production embedded system I mentioned earlier doesn't > use SOAP or haxe or websockets or numerous other yaws features, and in > fact doesn't even include them, plus it runs embedded within a larger > application, not as a stand-alone server. If it truly lacked > modularity, or if it weren't usable in a library-like fashion, none of > that would be possible. > > Earlier in this thread we have this gem from Lo?c: >> I'm sad to see Misultin go, this was in my opinion the only other project that had enough >> momentum to introduce innovation in Erlang web servers. > Wow. At best, this is simply ignorant on several fronts. At worst, > it's insulting to Klacke, Bob Ippolito, me and others who've put a lot > of work into their Erlang web servers and continue to do so. Hell, > Erlang wouldn't be where it is today without all the features Klacke > put into it, and I doubt Erlang web systems would be as far along as > they are now without Klacke's and Bob's continued contributions and > deployments into real products in years where most of us hadn't even > started using Erlang yet. Part of the reason Roberto has taken this > new action regarding misultin is that he wants the Erlang web > community to become more cohesive, reusing each other's work instead > of competing with each other, but irresponsible statements like this > one from Lo?c don't help Roberto's cause at all. If we truly want the > Erlang web dev community to become less fractured so it can grow, > taking cheap shots at each other won't get us there. > > Yaws exists and continues to exist because people continue to use it > in real-life production systems. Klacke, Christopher, and I all have > day jobs, so whatever time we put into yaws is based on what users are > asking for. What makes it real interesting and fun is to fit new > features like websockets into a system without it being an ugly hack > and without breaking everything else that's already there, and we > intend to continue to do exactly that. > > Perhaps worst of all about parts of this thread, though, is that from > what I've seen over the past few years, those spreading these > unfounded rumors about yaws being old and creaky and slow and legacy > and not actively developed and not usable for their projects never > once contacted Klacke or me or the erlyaws mailing list about > questions or issues with the system. They've never attempted to > contribute to the system with features or patches. I therefore suspect > that they just listened to the same recurring unfounded gossip and > made up their mind that way. Unfortunate, if true. But surely it's not > asking too much to request that, going forward, people at least do > their homework, try things out, and maybe ask some questions before > stating "facts" that simply aren't true about yaws, or mochiweb, or > any other such systems? > > --steve > I am glad yaws is now actively developed and I hope it will be used more in the future to help support your efforts. I am sorry for the misunderstanding. - Michael From robert.virding@REDACTED Fri Feb 17 19:33:02 2012 From: robert.virding@REDACTED (Robert Virding) Date: Fri, 17 Feb 2012 18:33:02 -0000 (GMT) Subject: [erlang-questions] [erlang-bugs] Inconsistent and incomprehensible handling of variables in spec's by compiler In-Reply-To: Message-ID: Yes, I know that. My comment was mainly about how variables are handled. It is not logical that the compiler complains about a variable being used once but not when used more than once. It also doesn't make sense that prefixing the variable name with a '_' makes the compiler keep quite. It seems like it is reusing some of the variable checking code for functions but generating errors instead of warnings. In my case just using variable names does add information, it tells me what it is. In the respect the actual type is unimportant, if I need to type check my functions dialyzer will do it for me without a type spec. Just giving it an appropriate name is enough. It is also a way of giving long names in the "documentation" which allows me to use short names in the code. Reusing the same name tells me it is the same type. In this respect it gives me as much information as your alternative and is shorter and more concise. Again the actual errors I get from the compiler don't make sense and I ask why the compiler should worry as it does not use the information at all. The type interpretation is actually very close to my usage and would work if it wasn't for the compiler errors, and the similar dialyzer errors. Robert ----- Original Message ----- > There is a big difference between this: > > > -spec set_var(PrefixExp, Val, State) -> State. > > and this: > > > -spec set_var(PrefixExp::any(), Val::any(), State::any()) -> > > State::any(). > > The argument and return value type specifications are either Type > or Name::Type, so the first declaration says that the arguments > are of _types_ PrefixExp, Val and State, while the second declaration > says that all three arguments are of type any(). (As far as I know, > argument names are ignored by the compiler and dialyzer, and only > used by edoc.) Specifying a singleton variable as the _type_ of an > argument is most likely not what the programmer meant, since it > doesn't add any information, so to me it makes sense to have the > compiler reject it. > > That specification could be written like this: > > -spec set_var(PrefixExp::any(), Val::any(), State::X) -> NewState::X. > > which specifies that State and NewState must have the same type, no > matter which one. > > Hope this helps, > -- > Magnus Henoch > Erlang Solutions Ltd > http://www.erlang-solutions.com/ > > From roberto@REDACTED Fri Feb 17 21:52:05 2012 From: roberto@REDACTED (Roberto Ostinelli) Date: Fri, 17 Feb 2012 12:52:05 -0800 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: Message-ID: On Fri, Feb 17, 2012 at 6:39 AM, Joe Armstrong wrote: > Thanks for all your hard work Roberto - I've been a fan > of Misultin for a while now. I always choose the code > with the best documentation since I don't care about efficiency. > > So thanks once again for your efforts. > and thank you for using misultin in the first place ^^_ websocket supports was first added thanks to a post you did on your blog regarding this, some time ago now. r. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Fri Feb 17 21:56:00 2012 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 17 Feb 2012 22:56:00 +0200 Subject: [erlang-questions] Inconsistent and incomprehensible handling of variables in spec's by compiler In-Reply-To: References: Message-ID: <4F3EBEE0.30008@cs.ntua.gr> On 02/17/2012 10:54 AM, Robert Virding wrote: > If in my file I add the sepc: > > -spec set_var(PrefixExp, Val, State) -> State. > > I get the compiler errors, errors mind you, not warnings: > > src/luerl_eval.erl:332: type variable 'PrefixExp' is only used once (is unbound) > src/luerl_eval.erl:332: type variable 'Val' is only used once (is unbound) > > but if I write it as: > > -spec set_var(_PrefixExp, _Val, State) -> State. > > then the compiler is happy and is quiet. If I write it as: > > -spec set_var(Val, Val, State) -> State. > > (which is wrongly from my point of view) or go all verbose and write: > > -spec set_var(PrefixExp::any(), Val::any(), State::any()) -> State::any(). > > (which doesn't really add any useful information) the compiler is again happy and silent. > > This is inconsistent and does not make sense for variables in a function spec. Either it is wrong, for some incomprehensible reason, to have singleton variables in a function spec, or it shouldn't matter what the variable names are. And why should adding a type, even the most general one, make a difference to the variable name usage. And why should the compiler be bothered with the function spec at all seeing it is doesn't use it and it is not part of the language. > > In my naive view of the the typing world my original spec says that set_var/3 takes three arguments of any type and returns a value of the same type as the third argument. Then why not just add type information and make the compiler happy? Well in my case it doesn't give me anything; it makes the spec much longer and there is nothing in a type which would give me more information than is in the variable names. Also dialyzer doesn't actually *need* the spec as it works it out by itself anyway. And the type of PrefixExp is a big hairy recursive type which I am happy to let dialyzer work out for me. Typer gives me a half-screen long type for it. > > I get the same behaviour when running dialyzer on the different versions. Again I don't understand why it behaves like that. As others mentioned, in their most basic form, specs should contain *types*, not type variables. Continuing your example, the following is a valid spec: -spec set_var(exp(), val(), state()) -> state(). for some appropriate definitions of exp(), val() and state() types. I recommend that you write such specs. I would even go as far as say that you should stick to this kind of specs: specs that contain types and types alone. Of course, the benefits of writing the above spec are dependent on the precision of your type declarations. If you are lazy and map all three types to any(), something that the type language allows you to do, then of course you cannot expect much from the tools that take these specs into account, can you? (In such a case the spec is there mostly (only?) for documentation purposes. Personally, I am not interested in this type of specs; they have very little purpose.) Now, for convenience and for compatibility with what the edoc @spec language also allowed, we have retained the possibility that the user provides, perhaps selectively, *names* to argument positions and return results. So, you can write the above as: -spec set_var(PrefixExp::exp(), ImpValue::val(), state()) -> state(). Note that PrefixExp and ImpValue, i.e. whatever comes to the left of the :: symbol in the above, are *optional names* for arguments 1 and 2, not type variables. Type variables in specs come into the picture when you want to express (subtype or equality) relations between different argument positions or return values. (And by definition to express a relation you need to somehow use the same variable twice; personally I cannot think of a case where a singleton type variable is interesting.) For example, you may want to state in a more emphatic way that the third argument and the return result of the set_var/3 function are of the same type. You can do that as follows: -spec set_var(PrefixExp::exp(), ImpValue::val(), InState::ST) -> OutState::ST when ST::state(). (Note that the only type variable in the above is ST.) Another example of use of type variables is in functions like map/2. Since the type system is based on subtyping, you would need to write its spec as follows: -spec map(F::fun((X) -> Y), InL::[XE]) -> OutL::[YE] when X::term(), Y::term(), XE::term(), YE::term(), XL::X, YL::Y. or, even stricter, as: -spec map(F::fun((X) -> Y), InL::[X]) -> OutL::[Y] when X::term(), Y::term(). but I guess most people would find the above two ways of giving a spec for map/2 probably too verbose so we also allowed them to write simply: -spec map(fun((X) -> Y), [X]) -> [Y]. with the implicit assumption that for all type variables T that are not qualified by a subtype constraint, there is a constraint T::term() which is implicit. (Note that in this case, all type variables are not singletons.) Also, because we had a hunch that there may be Erlang programmers who have hard time grasping the subtleties of the type language (for example, they might be confusing type variables with argument and position names) and might make typos in specs, we decided to never allow type variables that are singleton. As I explained, such variables are not just unconstrained, but they are really not needed because they serve no purpose; instead type names do. I saw/see no reason for one to write a type variable just to name a position; if you think otherwise, please provide an example that makes sense. Till you do, you are not allowed to write MY_NAME for the type any(); if you want the type any() please write any(); if you want to name it appropriately, you are required to write MY_NAME::any() or its shorthand MY_NAME::_. I hope it is clear now. Kostis From emeka_1978@REDACTED Fri Feb 17 22:09:18 2012 From: emeka_1978@REDACTED (eigenfunction) Date: Fri, 17 Feb 2012 13:09:18 -0800 (PST) Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> Message-ID: <1a2edd68-e190-456d-bba8-f62d07110b3d@n12g2000yqb.googlegroups.com> Thank you steve for pointing that out. I have found yaws to be one of the most complete real webservers on the planet with the potential to become the next apache. It s just sad that even in the erlang community, it is being mentioned as an afterthought. What i did find out when i was looking for a nice way to do web development in erlang was that, yaws was not only a magnificent webserver, it is a web framework as well. I stopped reading blogs about other erlang webservers after that. On Feb 17, 4:06?pm, Steve Vinoski wrote: > On Fri, Feb 17, 2012 at 3:59 AM, Ulf Wiger wrote: > > > On 17 Feb 2012, at 00:06, Michael Truog wrote: > > > With yaws the concern seems to be more about the code being regarded as > > legacy, not actively developed, and not modular (and whatever other reasons > > that seemed to make mochiweb > > appear necessary). > > > I think this is no longer true. My impression is that yaws development has > > picked up again, Looking at the change log for the releases in the past year > > or two [1], it is obvious that it is being actively maintained. This is also > > apparent from the github stats [2]. And yaws now comes with generic support > > for the various forms of JSON RPC (1.1 and 2.0), HAXE, SOAP, and even > > WebSockets. One of the few things I miss is WebMachine support. :) > > > [1]?http://yaws.hyber.org/ > > [2]?https://github.com/klacke/yaws/contributors > > Very true, Ulf. And we'll get you that webmachine support soon. > > And Michael, another way anyone can see how active yaws development is > is to simply look at the commits: > > https://github.com/klacke/yaws/commits/master > > This approach would seem vastly preferable to spreading inaccurate and > irresponsible rumors on this mailing list about yaws not being > actively developed. I've been using yaws for the past 5 years, much of > it in a production embedded system, and it's been actively developed > for all 5 of those years. Yaws is now in its 11th year of active > development. > > Regarding yaws modularity, I keep hearing this rumor that it lacks in > that regard, yet nobody has yet pointed out any specifics. If someone > were to point out things they think are too intertwined, then Klacke, > Christopher Faulet, or I -- those with commit rights to the yaws repo > -- could at least consider fixing them, as could anyone else with an > interest in providing a patch. But in the absence of anything > concrete, it's hard to take action. > > Note that the production embedded system I mentioned earlier doesn't > use SOAP or haxe or websockets or numerous other yaws features, and in > fact doesn't even include them, plus it runs embedded within a larger > application, not as a stand-alone server. If it truly lacked > modularity, or if it weren't usable in a library-like fashion, none of > that would be possible. > > Earlier in this thread we have this gem from Lo?c: > > > I'm sad to see Misultin go, this was in my opinion the only other project that had enough > > momentum to introduce innovation in Erlang web servers. > > Wow. At best, this is simply ignorant on several fronts. At worst, > it's insulting to Klacke, Bob Ippolito, me and others who've put a lot > of work into their Erlang web servers and continue to do so. Hell, > Erlang wouldn't be where it is today without all the features Klacke > put into it, and I doubt Erlang web systems would be as far along as > they are now without Klacke's and Bob's continued contributions and > deployments into real products in years where most of us hadn't even > started using Erlang yet. Part of the reason Roberto has taken this > new action regarding misultin is that he wants the Erlang web > community to become more cohesive, reusing each other's work instead > of competing with each other, but irresponsible statements like this > one from Lo?c don't help Roberto's cause at all. If we truly want the > Erlang web dev community to become less fractured so it can grow, > taking cheap shots at each other won't get us there. > > Yaws exists and continues to exist because people continue to use it > in real-life production systems. Klacke, Christopher, and I all have > day jobs, so whatever time we put into yaws is based on what users are > asking for. What makes it real interesting and fun is to fit new > features like websockets into a system without it being an ugly hack > and without breaking everything else that's already there, and we > intend to continue to do exactly that. > > Perhaps worst of all about parts of this thread, though, is that from > what I've seen over the past few years, those spreading these > unfounded rumors about yaws being old and creaky and slow and legacy > and not actively developed and not usable for their projects never > once contacted Klacke or me or the erlyaws mailing list about > questions or issues with the system. They've never attempted to > contribute to the system with features or patches. I therefore suspect > that they just listened to the same recurring unfounded gossip and > made up their mind that way. Unfortunate, if true. But surely it's not > asking too much to request that, going forward, people at least do > their homework, try things out, and maybe ask some questions before > stating "facts" that simply aren't true about yaws, or mochiweb, or > any other such systems? > > --steve > _______________________________________________ > erlang-questions mailing list > erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions From roberto@REDACTED Fri Feb 17 22:11:38 2012 From: roberto@REDACTED (Roberto Ostinelli) Date: Fri, 17 Feb 2012 13:11:38 -0800 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> Message-ID: On Fri, Feb 17, 2012 at 8:10 AM, Ulf Wiger wrote: > > FWIW, as has perhaps become evident, as we needed to pick a web server > here at Feuerlabs, we had an open-ended discussion about the different > alternatives, then decided to go with Yaws. First off, we will do our best > to steer clear of tying ourselves to hard to any particular web server API, > but I don't see that as a big problem. If we decide to change later on, it > will be a small effort in our case. > > We chose to start with yaws for exactly the reasons that have come up > here. It's battle-proven, has remained stable over the years, and doesn't > appear to have any big problems keeping up with the new kids on the block > in terms of speed (at least within the margin of uncertainty given that > Yaws really does strive hard to be fully compliant - something that means > something to us, as it will be the point of interface for our external > customers). > > What impresses with Yaws is its long track record and feature list, and a > quick look at the development activity made it obvious that it is being > very well looked after. > > That said, the energy around Cowboy is impressive too. Our choice was not > a vote *against* Cowboy, but rather a vote of confidence for Yaws. We have > other fish to fry. > this is exactly why i took misultin out of the picture. we discussed about web servers, bob ippolito, steve vinoski and i some months ago at the riak 1.0 release party (there's proof! https://twitter.com/#!/ostinelli/status/134183807560593408/photo/1). in my belief, we should be concentrating our efforts in a common 'low-level' library, on top of which we could build other services. in an extreme point of view, i even suggested that, should cowboy live up to the expectations, steve could consider it as being yaws engine, on top of which it could deliver all the amazing features yaws is capable of. obviously this ain't gonna happen anytime soon, yaws is way more mature/stable than cowboy. my opinion is that there should be mainly two candidates: . yaws . cowboy the different features / ease of maintenante / personal taste, etc. should be the discriminating factors. i would _personally_ use (please, read the IMHO statement really loud in your head): . yaws - for blown-up web applications with templates, etc; . cowboy - for API / REST related stuff, or for building custom non-http protocols. 95% of my usage is in developing protocols and backend APIs, hence my added interest in cowboy. cowboy adding webmachine's REST-like support was the decisive move that made me go for my decision in stopping public support for misultin (obviously, it is still used in production and probably will be for some time). on a final note, i want to say that i'm really glad of the open source community reaction. it has acted very mature upon my decision, understanding the reasons and sharing the outcomes we all hope this may have. now let's continue building amazing stuff ^^_ r. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rexxe98@REDACTED Fri Feb 17 22:46:42 2012 From: rexxe98@REDACTED (Andrew Berman) Date: Fri, 17 Feb 2012 13:46:42 -0800 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> Message-ID: I want to applaud you Roberto on stepping away from Misultin like this. Far too often I see duplication of efforts of libraries simply because someone saw some functionality lacking in a library. My biggest gripe these days is with JavaScript libraries. It's almost like every day a new MV* library comes out which almost replicates something like Backbone or Knockout or whatever library. My thought has always been that instead of creating a new one, how about helping out on an existing one to fill in the holes or to improve upon it. It's simply mind-blowing how many JavaScript MV* libraries there are. I, like you, switched to Cowboy based on the Webmachine-like adapter they just added. I think it's MUCH better to have two solid libraries (e.g. yaws and cowboy) which are supported by the community-at-large rather than a fragmented set of tools which have little to no support and this is why I think you have done the right thing. I want to thank you for Misultin, I sure learned a lot from the code. --Andrew On Fri, Feb 17, 2012 at 1:11 PM, Roberto Ostinelli wrote: > On Fri, Feb 17, 2012 at 8:10 AM, Ulf Wiger wrote: > >> >> FWIW, as has perhaps become evident, as we needed to pick a web server >> here at Feuerlabs, we had an open-ended discussion about the different >> alternatives, then decided to go with Yaws. First off, we will do our best >> to steer clear of tying ourselves to hard to any particular web server API, >> but I don't see that as a big problem. If we decide to change later on, it >> will be a small effort in our case. >> >> We chose to start with yaws for exactly the reasons that have come up >> here. It's battle-proven, has remained stable over the years, and doesn't >> appear to have any big problems keeping up with the new kids on the block >> in terms of speed (at least within the margin of uncertainty given that >> Yaws really does strive hard to be fully compliant - something that means >> something to us, as it will be the point of interface for our external >> customers). >> >> What impresses with Yaws is its long track record and feature list, and a >> quick look at the development activity made it obvious that it is being >> very well looked after. >> >> That said, the energy around Cowboy is impressive too. Our choice was not >> a vote *against* Cowboy, but rather a vote of confidence for Yaws. We have >> other fish to fry. >> > > this is exactly why i took misultin out of the picture. > > we discussed about web servers, bob ippolito, steve vinoski and i some > months ago at the riak 1.0 release party (there's proof! > https://twitter.com/#!/ostinelli/status/134183807560593408/photo/1). > > in my belief, we should be concentrating our efforts in a common > 'low-level' library, on top of which we could build other services. in an > extreme point of view, i even suggested that, should cowboy live up to the > expectations, steve could consider it as being yaws engine, on top of which > it could deliver all the amazing features yaws is capable of. obviously > this ain't gonna happen anytime soon, yaws is way more mature/stable than > cowboy. > > my opinion is that there should be mainly two candidates: > > . yaws > . cowboy > > the different features / ease of maintenante / personal taste, etc. should > be the discriminating factors. > > i would _personally_ use (please, read the IMHO statement really loud in > your head): > > . yaws - for blown-up web applications with templates, etc; > . cowboy - for API / REST related stuff, or for building custom non-http > protocols. > > 95% of my usage is in developing protocols and backend APIs, hence my > added interest in cowboy. > > cowboy adding webmachine's REST-like support was the decisive move that > made me go for my decision in stopping public support for misultin > (obviously, it is still used in production and probably will be for some > time). > > on a final note, i want to say that i'm really glad of the open source > community reaction. it has acted very mature upon my decision, > understanding the reasons and sharing the outcomes we all hope this may > have. > > now let's continue building amazing stuff ^^_ > > r. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Fri Feb 17 23:12:53 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Fri, 17 Feb 2012 22:12:53 +0000 Subject: [erlang-questions] Misultin EOL In-Reply-To: <4915914f-b378-43ab-9fcc-742980c2ee43@bs8g2000vbb.googlegroups.com> References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D991E.5000205@ninenines.eu> <4915914f-b378-43ab-9fcc-742980c2ee43@bs8g2000vbb.googlegroups.com> Message-ID: On 17 February 2012 02:09, Steve Davis wrote: > Hi Roberto, > > I'm a bit confused by this whole thread... > > I'm agreeing with Jesse that since Misultin is open source, it's not > really in your control to "stop development" if the interest is there > elsewhere to push it on? > > I'm also agreeing with Steve that I've not seen any demonstration that > yaws is somehow "lacking", > > For me, the last interesting benchmark that demonstrated anything > graspably real was "yaws vs apache". > > A really interesting benchmark for today's "web server" would be, if > someone were willing to engage in a non-trivial effort, to make a > comparison of a full-fledged web application with full session > management and routing capabilities. Note that this would truly test > the appropriateness of the server's http APIs as well as the base > response. That kind of benchmark, for me, would seem more appropriate > and useful according to the epoch. > I've been suggesting this for some time now. I will make some time (somehow) to participate and I'm sure others will too. > > Best regards, > /s > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Fri Feb 17 23:16:49 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Fri, 17 Feb 2012 22:16:49 +0000 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: On 16 February 2012 22:05, Roberto Ostinelli wrote: > On Thu, Feb 16, 2012 at 1:42 PM, Jesse Gumm wrote: > >> Not to state the obvious or anything, but Misultin is open source, so >> someone could always step up to the plate and become the *official* >> fork. >> >> There will still be efforts to support Misultin: Chicago Boss uses it, >> and barring some serious arguments against it, I'll still be adding >> misultin support to Nitrogen and SimpleBridge for the upcoming 2.1.0 >> release. >> >> So while it's unfortunate that Roberto is stepping away from Misultin >> development, that doesn't mean it's necessarily dead - someone can >> always take over. >> >> -Jesse > > > hi jesse, > > please don't suggest that. while i cannot avoid someone doing so, i could > have kept maintaing misultin myself. as i said, it has been a hard decision. > > my intent here is to avoid duplication of efforts, both for the > contributors of the community (often reporting the same bugs in both > repositories) and for the developers, which now have an hard time in > deciding which way to go. > > i just wanted to clear the way for a single webserver library, and cowboy > seems to have much more developer time to actually maintaining it. > Personally I don't understand why having a single library is so great, although I respect your decision to do this and am very grateful for all the hard work you've put into misultin to date. In *java-land* I like being able to choose between Tomcat, Jetty (for embedded stuff) and other commercial options too. I don't see why it's a bad thing at all, although I would *really* love it if Erlang had just one API for building standard web applications (a la servlets, but obviously more 'erlang-ish' in flavour) and then interesting stuff like Chicago Boss can be built on top of it. Personally I'm not keen on simple bridge because I don't like parameterised modules, but in every other respect I think it's a laudable effort. If we could standardise on an API - and god knows, I *really like* the one in Cowboy - then I personally think that would provide more benefit than having 'just one implementation'. Personally I don't think having just one implementation is the answer though. > > r. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Fri Feb 17 23:33:17 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Fri, 17 Feb 2012 22:33:17 +0000 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> Message-ID: On 17 February 2012 15:06, Steve Vinoski wrote: > Very true, Ulf. And we'll get you that webmachine support soon. > I'll jump on YAWS in a second, once that webmachine support is available. YAWS maturity is a big selling point for me. Most of the time, I don't want to think about generating HTML. Most of the web applications we've built at work are RESTful web services, which serve up either XML, JSON or both. None of them actually serve web pages - we have static HTML/Javascript content served up by nginx in front of Mochiweb/Misultin that makes ajax calls to the back end. Another feature that we rely on is streaming (or chunking) the response back to the client, which YAWS appears to do very nicely. I'd still really like it if all these applications had a consistent API though. One thing I really appreciate about YAWS and Cowboy is that they both avoid parameterised modules. Not that I care one way or the other about whether parameterised modules are good or bad TBH, just that they're not officially supported and that puts me off. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rexxe98@REDACTED Fri Feb 17 23:42:14 2012 From: rexxe98@REDACTED (Andrew Berman) Date: Fri, 17 Feb 2012 14:42:14 -0800 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: Tim, I think a comparison between the Java app servers is not really accurate. The reason I say that is that most have commercial support. Tomcat might be the only one without commercial support, but it's the reference implementation and has plenty of books about it. As far as I know with all the other popular ones there is some company who's willing to support it. I think that's a big difference here between comparing Java app servers and Erlang servers. Misultin is completely open-source with one man supporting it and no commercial support. I'd much rather see fewer servers with better support and possibly commercial support than many with little support. I do agree completely that Erlang needs a consistent servlet-like API. It would certainly help a lot. I'd be keen on simple bridge if the Erlang guys would just come out and say if they support parameterized modules or not. If they don't, just get rid of it. What's the point of having something in a language if it's not going to be supported (but that's a different topic)? --Andrew On Fri, Feb 17, 2012 at 2:16 PM, Tim Watson wrote: > On 16 February 2012 22:05, Roberto Ostinelli wrote: > >> On Thu, Feb 16, 2012 at 1:42 PM, Jesse Gumm wrote: >> >>> Not to state the obvious or anything, but Misultin is open source, so >>> someone could always step up to the plate and become the *official* >>> fork. >>> >>> There will still be efforts to support Misultin: Chicago Boss uses it, >>> and barring some serious arguments against it, I'll still be adding >>> misultin support to Nitrogen and SimpleBridge for the upcoming 2.1.0 >>> release. >>> >>> So while it's unfortunate that Roberto is stepping away from Misultin >>> development, that doesn't mean it's necessarily dead - someone can >>> always take over. >>> >>> -Jesse >> >> >> hi jesse, >> >> please don't suggest that. while i cannot avoid someone doing so, i could >> have kept maintaing misultin myself. as i said, it has been a hard decision. >> >> my intent here is to avoid duplication of efforts, both for the >> contributors of the community (often reporting the same bugs in both >> repositories) and for the developers, which now have an hard time in >> deciding which way to go. >> >> i just wanted to clear the way for a single webserver library, and cowboy >> seems to have much more developer time to actually maintaining it. >> > > Personally I don't understand why having a single library is so great, > although I respect your decision to do this and am very grateful for all > the hard work you've put into misultin to date. > > In *java-land* I like being able to choose between Tomcat, Jetty (for > embedded stuff) and other commercial options too. I don't see why it's a > bad thing at all, although I would *really* love it if Erlang had just one > API for building standard web applications (a la servlets, but obviously > more 'erlang-ish' in flavour) and then interesting stuff like Chicago Boss > can be built on top of it. > > Personally I'm not keen on simple bridge because I don't like > parameterised modules, but in every other respect I think it's a laudable > effort. If we could standardise on an API - and god knows, I *really like* > the one in Cowboy - then I personally think that would provide more benefit > than having 'just one implementation'. Personally I don't think having just > one implementation is the answer though. > > >> >> r. >> >> _______________________________________________ >> erlang-questions mailing list >> 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 watson.timothy@REDACTED Fri Feb 17 23:46:03 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Fri, 17 Feb 2012 22:46:03 +0000 Subject: [erlang-questions] Multiple db connection drivers In-Reply-To: References: Message-ID: On 17 February 2012 15:13, Garrett Smith wrote: > Hi Erisa, > Erlang has so many amazing features and benefits, it's hard to keep track! > > Database interfaces, however, is not on that list :) > > +1 - this is most annoying. We have a custom OCI based Oracle driver at work which is lightning fast, but I'm not allowed to 'replicate' so I decided to write it from scratch but haven't had the time to get properly started. As soon as I began, I thought to myself 'what should the API look like' and kind of despaired that there isn't an equivalent to JDBC/ADO.NETthat I could just conform to. > That's a broad, sweeping statement that leaves me open to easy > criticism! But I think if you're coming from a Java or .NET > background, it's hard to not scratch your head at the state of the > available libraries. > > The pgsql libraries mentioned are actually very good and the built in ODBC works fine if you can live with it. I'm pretty sure I've heard (on this list) that people have used it successfully in production for years without issue. Like I said we've got a fabulous Oracle/OCI driver that's not once died in production for the last three years, but I'm now thinking that any rewrite would be better off done once the NIF/Native-Process changes come in. > Keep in mind that Erlang does not have a tradition of "ORMs" the way > Java, Ruby, Python, etc. do. You'll need to dive into the details of > whatever data stores you end up working with. I personally think this > is a benefit, but it does take more energy up front to consider your > requirements and learn the technology. > > There is ORM-like stuff in Erlyweb and Chicago Boss. Personally I think ORMs are pants and avoid them like the plague regardless of the language I'm using, but that's just me. Anyway, I'm not sure what the 'O' part would mean in Erlang, as a mapping from db rows to tuples/lists is probably just fine for most jobs. I'd also suggest that the OP take a look at the source code for zotonic, which does some interesting things with a fairly low level data model backed by postgres (not much unlike the schema our oracle driver is hitting) and works very well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gumm@REDACTED Fri Feb 17 23:49:39 2012 From: gumm@REDACTED (Jesse Gumm) Date: Fri, 17 Feb 2012 16:49:39 -0600 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: I agree with you about the parameterised modules. ?I'm not a big fan of them either (though seeing how it works, I do understand why Rusty went that route), and the deprecation of the tuple modules had me scared for a moment. After that happened, I've been starting to think about a roadmap away from the parameterised modules with simple_bridge. -Jesse > Personally I'm not keen on simple bridge because I don't like parameterised > modules, but in every other respect I think it's a laudable effort. > ... > Not that I care one way or the other about whether parameterised modules are > good or bad TBH, just that they're not officially supported and that puts me off. > >> >> >> r. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -- Jesse Gumm Owner, Sigma Star Systems 414.940.4866 || sigma-star.com || @jessegumm From watson.timothy@REDACTED Fri Feb 17 23:57:07 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Fri, 17 Feb 2012 22:57:07 +0000 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: On 17 February 2012 22:42, Andrew Berman wrote: > Tim, > > I think a comparison between the Java app servers is not really accurate. > The reason I say that is that most have commercial support. Tomcat might > be the only one without commercial support, but it's the reference > implementation and has plenty of books about it. As far as I know with all > the other popular ones there is some company who's willing to support it. > I think that's a big difference here between comparing Java app servers > and Erlang servers. Misultin is completely open-source with one man > supporting it and no commercial support. I'd much rather see fewer servers > with better support and possibly commercial support than many with little > support. > > Yes ok, you make a very good point there. I hadn't thought about that, and on a few minutes reflection, I think you're quite right. > I do agree completely that Erlang needs a consistent servlet-like API. It > would certainly help a lot. > > Yes. There database libraries need this too. Java might be pants, but there are a few good things we can learn from it, and consistent APIs are one of them. > I'd be keen on simple bridge if the Erlang guys would just come out and > say if they support parameterized modules or not. If they don't, just get > rid of it. What's the point of having something in a language if it's not > going to be supported (but that's a different topic)? > > Yes indeed, same here. Personally I actually find them rather unintuitive, but I'd use them more readily in other people's libraries if they were properly supported. We've actually got Misultin running in production and it's been great, so it's not that I'm completely allergic to parameterised modules, just that I would prefer not to have them in an API. -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Sat Feb 18 00:03:04 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Fri, 17 Feb 2012 23:03:04 +0000 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: On 17 February 2012 22:49, Jesse Gumm wrote: > I agree with you about the parameterised modules. I'm not a big fan > of them either (though seeing how it works, I do understand why Rusty > went that route), and the deprecation of the tuple modules had me > scared for a moment. After that happened, I've been starting to think > about a roadmap away from the parameterised modules with > simple_bridge. > I think that's a good idea. I would also like to respectfully suggest that api implementations might be distributed separately from the api itself, so that I can choose to get simple_bridge and simple_bridge_mochiweb (or whatever) but ignore the other stuff. Just a suggestion you may wish to consider. Cheers, Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From rexxe98@REDACTED Sat Feb 18 00:05:14 2012 From: rexxe98@REDACTED (Andrew Berman) Date: Fri, 17 Feb 2012 15:05:14 -0800 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: I think a lot of issues with APIs would be solved if we had something analogous to Java interfaces in Erlang. Behaviors just don't cut it. I want something that is a replica of interfaces. Then all the Erlang guys have to do is create the interface and then people can create whatever implementations they want and I never have to worry about changing my code! On Fri, Feb 17, 2012 at 3:03 PM, Tim Watson wrote: > On 17 February 2012 22:49, Jesse Gumm wrote: > >> I agree with you about the parameterised modules. I'm not a big fan >> of them either (though seeing how it works, I do understand why Rusty >> went that route), and the deprecation of the tuple modules had me >> scared for a moment. After that happened, I've been starting to think >> about a roadmap away from the parameterised modules with >> simple_bridge. >> > > > I think that's a good idea. > > I would also like to respectfully suggest that api implementations might > be distributed separately from the api itself, so that I can choose to get > simple_bridge and simple_bridge_mochiweb (or whatever) but ignore the other > stuff. Just a suggestion you may wish to consider. > > Cheers, > > Tim > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yrashk@REDACTED Sat Feb 18 00:31:27 2012 From: yrashk@REDACTED (Yurii Rashkovskii) Date: Fri, 17 Feb 2012 15:31:27 -0800 (PST) Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: <8330821.1609.1329521487117.JavaMail.geo-discussion-forums@pbvr2> Andrew, >I think a lot of issues with APIs would be solved if we had something analogous to Java interfaces in Erlang. Behaviors just don't cut it. I want something that is a replica of interfaces. Then all the Erlang guys have to do is create the interface and then people can create whatever implementations they want and I never have to worry about changing my code! I think this new -callback stuff is more apt to solving the problem of interfaces. -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Sat Feb 18 01:54:12 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Sat, 18 Feb 2012 00:54:12 +0000 Subject: [erlang-questions] Misultin EOL In-Reply-To: <8330821.1609.1329521487117.JavaMail.geo-discussion-forums@pbvr2> References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <8330821.1609.1329521487117.JavaMail.geo-discussion-forums@pbvr2> Message-ID: On 17 February 2012 23:31, Yurii Rashkovskii wrote: > Andrew, > > >I think a lot of issues with APIs would be solved if we had something > analogous to Java interfaces in Erlang. Behaviors just don't cut it. I > want something that is a replica of interfaces. Then all the Erlang guys > have to do is create the interface and then people can create whatever > implementations they want and I never have to worry about changing my code! > > I think this new -callback stuff is more apt to solving the problem of > interfaces. > > If I've understood this properly, then the -callback thing will provide a compile time check for the implementors of the callback interface into the custom behaviour, but gives nothing to the (external) client. Now what Andrew and I are looking for in practise, is something roughly like DbHandle = dbms:bind(pgsql, DriverConfig), DbConnection = dbms:connect(DbHandle, dbms:connection_info(Catalog, Schema, AuthMode)) Results = dbms:execute_query(DbConnection, "select * from foo"), dbms_result_set:foldl(Results, [], fun collect_foobar/2) So I can change 'pgsql' to 'pgsql2' or 'oracle-oci' or 'mysql' or whatever, I can call connect/2 with *any* valid `-opaque db_handle() :: ...' data, call execute_query/2 with *any* valid `-opaque db_connection() :: ...' and I can rely on all implementations returning a structure that I can pass to dbms_result_set foreach/map/foldl and it will 'just work' even if the result set has to have a 'pointer' to those functions or (less tidily) I have to pass the DbHandle to those functions. Here I can clearly rely on only the 'dbms' API and the people who have to do the heavy lifting are the implementors or 'pgsql' and similar libraries, who have to make sure that their libraries conform to the -callback interface(s) defined by the dbms application. I think though, that there is a question of state that makes this a bit awkward in practise (because even if there are no processes behind the custom behaviour, you still have to maintain the binding to the implementation module(s) somewhere) and also it makes implementing the API more complicated than simply saying 'define these callback functions'. I think this is why so many API efforts (such as simple_bridge) seem to end up using parameterised modules. A classic example of this is the recent conversation about unifying the dict APIs, but you could apply that to lots of other situations. How can I do that using the -callback approach? D = dict_api:new(dict | orddict | ....) %% add some stuff dict_api:find(key1, D2) So at a minimum, the implementor of dict_api needs to return (a) the module that implements its -callback interface and (b) whatever state/data that is required in order to fulfil any subsequent call. Now if there was a bit of sugar that allowed me to do this dbms:bind and dict_api:new stuff so that I only need to 1. define the -callback interface somewhere as the API 2. have a way to get an implementation of the callback interface for any module that provides that -behaviour then things would be good right!? But I want this to work without breaking hot loading/upgrades, so I'm not convinced that it's so easy to do when you're effectively spending a lot of time passing around the module name(s) in a bunch of variables or embedded in some records or whatever. What we're looking for is a way to say %% bind the -callback source to an implementation -bind(api_module, implementation_module). do_something() -> api_module:do_something(....) And make sure that when an upgrade takes place, that what's *really* happening is that the call is being made to 'implementation_module' and any change to 'implementation_module' will trigger a proper code change. I suppose this might be achievable with a parse_transform (that translates from mod_api to the other) but that feels a bit messy and it would be nice for the compiler to check the client code for consistency with the exported -callback API too. That's probably a terrible approach, but I hope you get the gist of what we're thinking about. -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Sat Feb 18 02:53:19 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Sat, 18 Feb 2012 01:53:19 +0000 Subject: [erlang-questions] Multiple db connection drivers In-Reply-To: References: Message-ID: On 16 February 2012 14:15, Erisa Dervishi wrote: > Hi everybody, > > I am an erlang newbie, and I am doing a survey on existing Erlang db access > drivers. I am most interested in drivers that can handle and process > multiple concurrent db requests. Are there any working Erlang multithread db > access drivers for MySql or PostgreSQL? What about BerkleyDB? Or any other > Erlang driver that can handle db requests in parallel? Max has suggested good pgsql drivers. It is worth baring in mind that 'multiple requests in parallel' is a broad requirement. Most JDBC drivers, for example, offer thread safe Connection objects because they serialise access, which means only one thread can proceed at once. In practise, you need to use a connection per thread, which is prohibitively expensive (esp. in terms of setup/teardown) and is the reason all production java code ends up using connection pools. The same is going to be true for erlang database drivers. SqlRelay is an interesting one. If you use it, just bare in mind each erlang port (linked to the external C program which is in turn, connected to one of the connection daemons) is going to communicate synchronously over stdio, so you'll need to do the same thing (pooling the ports) there I would've thought. Like Max, I can highly recommend Will's pgsql driver and there are a number of other good ones out there, including some derived from his. > There are plenty of drivers out there, but no documentation at all, and I am > not experienced enough to find out the ones I'm interested in. > I would be really glad if you could provide me some links or valuable > suggestions. > > Thanks in advance! > Cheers, > Erisa > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From mjtruog@REDACTED Sat Feb 18 04:46:58 2012 From: mjtruog@REDACTED (Michael Truog) Date: Fri, 17 Feb 2012 19:46:58 -0800 Subject: [erlang-questions] Multiple db connection drivers In-Reply-To: References: Message-ID: <4F3F1F32.2090203@gmail.com> On 02/17/2012 05:53 PM, Tim Watson wrote: > On 16 February 2012 14:15, Erisa Dervishi wrote: >> Hi everybody, >> >> I am an erlang newbie, and I am doing a survey on existing Erlang db access >> drivers. I am most interested in drivers that can handle and process >> multiple concurrent db requests. Are there any working Erlang multithread db >> access drivers for MySql or PostgreSQL? What about BerkleyDB? Or any other >> Erlang driver that can handle db requests in parallel? > SqlRelay is an interesting one. If you use it, just bare in mind each > erlang port (linked to the external C program which is in turn, > connected to one of the connection daemons) is going to communicate > synchronously over stdio, so you'll need to do the same thing (pooling > the ports) there I would've thought. If you want to get more concurrency in your usage of an erlang port, you can use CloudI (http://cloudi.org) to provide a configured number of tcp connections to the local OS process (configured as the number of threads for a CloudI service running as a job). The CloudI API would then provide some simple message passing functions to use in each thread that could interface with SqlRelay. So, that approach could help you avoid contention, but still provide the fault-tolerance of an erlang port (i.e., avoiding the use of a port driver or NIF). There is native Erlang code available for PostgreSQL (I agree that Will's pgsql is currently the best) and MySQL (many versions of this exist from many authors). There is a BerkleyDB port driver in EDTK, but I am not sure how much usage it has now. It seems best to stick with native Erlang code for database drivers, whenever possible, so that you have fault-tolerance and simpler concurrency. - Michael From erlang@REDACTED Sat Feb 18 11:14:42 2012 From: erlang@REDACTED (Joe Armstrong) Date: Sat, 18 Feb 2012 11:14:42 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: On Sat, Feb 18, 2012 at 12:03 AM, Tim Watson wrote: > On 17 February 2012 22:49, Jesse Gumm wrote: >> >> I agree with you about the parameterised modules. ?I'm not a big fan >> of them either (though seeing how it works, I do understand why Rusty >> went that route), and the deprecation of the tuple modules had me >> scared for a moment. After that happened, I've been starting to think >> about a roadmap away from the parameterised modules with >> simple_bridge. >> > > > I think that's a good idea. > > I would also like to respectfully suggest that api implementations might be > distributed separately from the api itself, so that I can choose to get > simple_bridge and simple_bridge_mochiweb (or whatever) but ignore the other > stuff. Just a suggestion you may wish to consider. This is *exactly* what I posted yesterday :-) See https://github.com/joearms/adapter_pattern I have made three independent adapters (call them bridges if you like) to misultin, mochiweb and cowboy. With this you can change the entire backend by changing *one* module name in one place in the code. They use parameterised modules to hide all the messy details. Probably isolation via an addition process would be better - I don't know, but I suspect this to be the case. /Joe > > Cheers, > > Tim > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From erlang@REDACTED Sat Feb 18 11:39:50 2012 From: erlang@REDACTED (Joe Armstrong) Date: Sat, 18 Feb 2012 11:39:50 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D991E.5000205@ninenines.eu> <4915914f-b378-43ab-9fcc-742980c2ee43@bs8g2000vbb.googlegroups.com> Message-ID: On Fri, Feb 17, 2012 at 11:12 PM, Tim Watson wrote: > On 17 February 2012 02:09, Steve Davis > wrote: >> >> Hi Roberto, >> >> I'm a bit confused by this whole thread... >> >> I'm agreeing with Jesse that since Misultin is open source, it's not >> really in your control to "stop development" if the interest is there >> elsewhere to push it on? >> >> I'm also agreeing with Steve that I've not seen any demonstration that >> yaws is somehow "lacking", >> >> For me, the last interesting benchmark that demonstrated anything >> graspably real was "yaws vs apache". >> >> A really interesting benchmark for today's "web server" would be, if >> someone were willing to engage in a non-trivial effort, to make a >> comparison of a full-fledged web application with full session >> management and routing capabilities. Note that this would truly test >> the appropriateness of the server's http APIs as well as the base >> response. That kind of benchmark, for me, would seem more appropriate >> and useful according to the epoch. > > > I've been suggesting this for some time now. I will make some time (somehow) > to participate and I'm sure others will too. Yes ^ 100 My *minimal* application does this for *every* GET request 1) Is there a cookie? 2) If no cookie redirect to a set-cookie page 3) if there is a cookie lookup value in database 4) if no value in DB redirect to warning page 5) if there is a value check if user is authenticated 6) if not authenticated redirect to login page 7) if authenticated lookup same basic data about user in DB 8) send the result I suspect that impedance mismatches between the DB and web server are the main sources of inefficiency The *interesting* benchmark is (say) the number of page-views in a forum/second or the number of searches/second in a forum. We need to implement something like PHPBB and benchmark the number of page-views/second (Actually doing so would involve even more work before a page gets sent - is the IP blacklisted? - has the user posted more than N requests in the last T seconds - is the user a spammer...) One thing that hinders this is the lack of a common language to implement the web-part in. I have made a little language EHE for this - which included in my adapter pattern - EHE is easy to embed in *any* erlang web server - I have done so for misultin, cowboy and mochiweb see https://github.com/joearms/adapter_pattern The database for something like a web forum needs investigation: I want a data base with the following characteristics - persistent - Key-Value - fast lookups - slow writes - full-text indexing of certain fields of certain key-types In a forum type application the read-write ratio is heavily skewed in favor of reads - ie lots of reads very few writes. I am making a systems where all keys-values are stored in an ets table. Reads go to the ets table, writes go to the ets table and are trailed on disk. I guess I'd also like large values on disk small values in the ets table. Oh and I'd also like full-text indexing on tuple fields. ie if I say store({post,12456},#item{user="joe", text="......"}) Id like to automatically index the text field of the record. No erlang database I know of fits the bill - I don't want an interface to mySQL or whatever since I suspect the impedance mismatch between Erlang and the external database would be terrible. Summary: In addition to a fast web-server we need - a fast persistent DB suitable for web applications - zero impedance mismatch between the DB and the web server - a language for the application (like PHP) (you'll find my EHE at https://github.com/joearms/adapter_pattern) - authentication All these bits have to fit together with bridges (adapters) so we can change the database/server/authentication without having to rewrite the entire application. Do this and *then* benchmark against PHPBB (or something) Cheers /Joe > >> >> >> Best regards, >> /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 > From ulf@REDACTED Sat Feb 18 12:01:45 2012 From: ulf@REDACTED (Ulf Wiger) Date: Sat, 18 Feb 2012 12:01:45 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: On 17 Feb 2012, at 23:42, Andrew Berman wrote: > I'd be keen on simple bridge if the Erlang guys would just come out and say if they support parameterized modules or not. If they don't, just get rid of it. What's the point of having something in a language if it's not going to be supported (but that's a different topic)? I agree that if something is added as an experimental feature, it should either be graduated or removed as soon as possible, not stay experimental indefinitely. BR, Ulf W -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Sat Feb 18 12:05:43 2012 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Sat, 18 Feb 2012 12:05:43 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: > > I'd be keen on simple bridge if the Erlang guys would just come out and > say if they support parameterized modules or not. If they don't, just get > rid of it. What's the point of having something in a language if it's not > going to be supported (but that's a different topic)? > > > I agree that if something is added as an experimental feature, it should > either be graduated or removed as soon as possible, not stay experimental > indefinitely. > I don't use parameterized modules at all but it would be a pity to see { module, args }:function() go. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Sat Feb 18 12:13:19 2012 From: erlang@REDACTED (Joe Armstrong) Date: Sat, 18 Feb 2012 12:13:19 +0100 Subject: [erlang-questions] Thoughts on EHE - the PHP killer Message-ID: Thoughts on EHE I'm playing with a little language for writing web applications. It's called EHE. All it is HTML with embedded Erlang I like EHE very much since it is the simplest possible way of embedding Erlang in a web page - I can think of no simpler method - the learning gap (if you know Erlang and HTML) is pretty near zero. For me simple = good. What is EHE? An EHE script is just a file with the extension .ehe. The file contains HTML or XHTML with embedded Erlang. The embedding syntax is This syntax is chosen since this notation corresponds to an XML processing instruction. Inside the block is sequence of Erlang expressions. The replacement value of the block is the last value of the sequence is just the last value in the sequence, which must be an IO list. Binding are propagated forwards between blocks. Here's an example

Hello

Hello The first block binds the variable Name and injects "" into the text The second block injects "joe" into the text. Communicating with the environment: Inside EHE the global variable SYS provides a bridge to the outside world. We can imagine a library of useful functions that change the state of the environment - like: ... and so on SYS is a parametrised module that is configured *outside* EHE - so we can change the database later *without* changing the EHE code. There is an implementation of EHE at https://github.com/joearms/adapter_pattern (actually there is no SYS module in the git hub code, just an object called Req) Question: Do we need more than this in an embedded language. On part of me says NO WAY - you have the full power of erlang at your disposal. Another part says ... Might mean if X is true then omit the block of HTML immediately following the erlang code block. The problem with this is that it leads to a half-baked badly thought out mess of language and a slippery slope where we want to add just one more feature. For this reason I would suggest that EHE only has the semantics I have suggested and nothing else. Note - while EHE is interpreted it can easily be compiled if efficiency is a problem. Now the next question - what are the SYS functions: SYS:lookup(Key) -> {ok, Value} | error SYS is a parametric module that bridges you into Erlang - but what functions should it support? /Joe From erlang@REDACTED Sat Feb 18 12:14:34 2012 From: erlang@REDACTED (Joe Armstrong) Date: Sat, 18 Feb 2012 12:14:34 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: On Sat, Feb 18, 2012 at 12:05 PM, Jos? Valim wrote: >> I'd be keen on simple bridge if the Erlang guys would just come out and >> say if they support parameterized modules or not. ?If they don't, just get >> rid of it. ?What's the point of having something in a language if it's not >> going to be supported (but that's a different topic)? >> >> >> I agree that if something is added as an experimental feature, it should >> either be graduated or removed as soon as possible, not stay experimental >> indefinitely. > > > I don't use parameterized modules at all but it would be a pity to see { > module, args }:function() go. It will stay - and be documented to make it official /Joe > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From bchesneau@REDACTED Sat Feb 18 12:18:58 2012 From: bchesneau@REDACTED (Benoit Chesneau) Date: Sat, 18 Feb 2012 12:18:58 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: On Sat, Feb 18, 2012 at 12:05 AM, Andrew Berman wrote: > I think a lot of issues with APIs would be solved if we had something > analogous to Java interfaces in Erlang. ?Behaviors just don't cut it. ?I > want something that is a replica of interfaces. ?Then all the Erlang guys > have to do is create the interface and then people can create whatever > implementations they want and I never have to worry about changing my code! > In python world we have WSGI that define a common spec to interface Python application with the web. Defining how server should handle requests to and return response from applications. Also defining how the requests/responses should be formatted for the apps. There are many servers and many libs/frameworks handling the spec. Only the code quality, the technical differences and features distinct them. I guess somethng like that could be defined in Erlang with a lib reference to test the validaty and validate servers and libs behaviour (just like wsgiref in Python). Same exist with Rack in ruby world and probably in other language. Maybe that something that could be done. It would at least simplify a lot the work of apps developers. - beno?t From gordon@REDACTED Sat Feb 18 12:31:02 2012 From: gordon@REDACTED (Gordon Guthrie) Date: Sat, 18 Feb 2012 11:31:02 +0000 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> Message-ID: > . yaws - for blown-up web applications with templates, etc; > . cowboy - for API / REST related stuff, or for building custom non-http > protocols. On a similar note it would be good to get a consistent authentication mechanism for using API's so that people didn't need to first build their own mechanism and THEN painfully build a community of developers who have built and contributed libraries conformant to it in other languages. I made a start by building an AWS-clone private, public keypair authentication library which I committed upstream (to us) to mochiweb: https://github.com/mochi/mochiweb/blob/master/examples/hmac_api/README The aim is to make it as easy as possible to release an API that extends out to the libraries that API consumers need to build their applications in their own languagues. I know Yaws a bit, but I am not that familiar with misultin and cowboy. Is anyone else working on libraries like this that I should co-ordinate with? Gordon On 17 February 2012 21:11, Roberto Ostinelli wrote: > On Fri, Feb 17, 2012 at 8:10 AM, Ulf Wiger wrote: >> >> >> FWIW, as has perhaps become evident, as we needed to pick a web server >> here at Feuerlabs, we had an open-ended discussion about the different >> alternatives, then decided to go with Yaws. First off, we will do our best >> to steer clear of tying ourselves to hard to any particular web server API, >> but I don't see that as a big problem. If we decide to change later on, it >> will be a small effort in our case. >> >> We chose to start with yaws for exactly the reasons that have come up >> here. It's battle-proven, has remained stable over the years, and doesn't >> appear to have any big problems keeping up with the new kids on the block in >> terms of speed (at least within the margin of uncertainty given that Yaws >> really does strive hard to be fully compliant - something that means >> something to us, as it will be the point of interface for our external >> customers). >> >> What impresses with Yaws is its long track record and feature list, and a >> quick look at the development activity made it obvious that it is being very >> well looked after. >> >> That said, the energy around Cowboy is impressive too. Our choice was not >> a vote *against* Cowboy, but rather a vote of confidence for Yaws. We have >> other fish to fry. > > > this is exactly why i took misultin out of the picture. > > we discussed about web servers, bob ippolito, steve vinoski and i some > months ago at the riak 1.0 release party (there's proof! > https://twitter.com/#!/ostinelli/status/134183807560593408/photo/1). > > in my belief, we should be concentrating our efforts in a common 'low-level' > library, on top of which we could build other services. in an extreme point > of view, i even suggested that, should cowboy live up to the expectations, > steve could consider it as being yaws engine, on top of which it could > deliver all the amazing features yaws is capable of. obviously this ain't > gonna happen anytime soon, yaws is way more mature/stable than cowboy. > > my opinion is that there should be mainly two candidates: > > . yaws > . cowboy > > the different features / ease of maintenante / personal taste, etc. should > be the discriminating factors. > > i would _personally_ use (please, read the IMHO statement really loud in > your head): > > . yaws - for blown-up web applications with templates, etc; > . cowboy - for API / REST related stuff, or for building custom non-http > protocols. > > 95% of my usage is in developing protocols and backend APIs, hence my added > interest in cowboy. > > cowboy adding webmachine's REST-like support was the decisive move that made > me go for my decision in stopping public support for misultin (obviously, it > is still used in production and probably will be for some time). > > on a final note, i want to say that i'm really glad of the open source > community reaction. it has acted very mature upon my decision, understanding > the reasons and sharing the outcomes we all hope this may have. > > now let's continue building amazing stuff ^^_ > > r. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Gordon Guthrie CEO hypernumbers http://hypernumbers.com t: hypernumbers +44 7776 251669 From jose.valim@REDACTED Sat Feb 18 12:30:50 2012 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Sat, 18 Feb 2012 12:30:50 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: > > There are many servers and many libs/frameworks handling the spec. > Only the code quality, the technical differences and features distinct > them. I guess somethng like that could be defined in Erlang with a > lib reference to test the validaty and validate servers and libs > behaviour (just like wsgiref in Python). Same exist with Rack in ruby > world and probably in other language. > I agree that a common interface is desired but we should steer far away from Rack and WSGI. Rack in particular was designed with the concept of * endpoint* that is the entity responsible for calculating the response and send it back after the response is generated. This means that async and streaming the response as you get it are very hard to achieve because the whole ecosystem and the specs were not designed to handle such scenarios. Something that gets this right though is servlet API from Java with the concept of generators, filters and etc. Streaming works fine as you can, at any point, push data into the socket and filters/generators are wrapped by this API. Every time I see a Erlang or a Node.js framework based on top of Rack/WSGI a part of me dies because the ability of streaming and asynchronously pushing stuff down the socket is one of the best features you would have in such frameworks. PS: I am one of the core members of Rails by far the biggest framework that relies on Rack. We tried to add streaming on Rails 3.1 which made very clear all the shortcomings of the Rack API. We will eventually work on a Rack 2.0 that is more inspired by the Servlet API. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Sat Feb 18 12:33:42 2012 From: bchesneau@REDACTED (Benoit Chesneau) Date: Sat, 18 Feb 2012 12:33:42 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: On Sat, Feb 18, 2012 at 12:30 PM, Jos? Valim wrote: >> There are many servers and many libs/frameworks handling the spec. >> Only the code quality, the technical differences and features distinct >> them. ?I guess somethng like that could be defined in Erlang with a >> lib reference to test the validaty and validate servers and libs >> behaviour (just like wsgiref in Python). Same exist with Rack in ruby >> world and probably in other language. > > > I agree that a common interface is desired but we should steer far away from > Rack and WSGI.?Rack in particular was designed with the concept of > endpoint?that is the entity responsible for calculating the response and > send it back after the response is generated. This means that async and > streaming the response as you get it are very hard to achieve because the > whole ecosystem and the specs were not designed to handle such scenarios. > > Something that gets this right though is servlet API from Java with the > concept of generators, filters and etc. Streaming works fine as you can, at > any point, push data into the socket and filters/generators are wrapped by > this API. > > Every time I see a Erlang or a Node.js framework based on top of Rack/WSGI a > part of me dies because the ability of streaming and asynchronously pushing > stuff down the socket is one of the best features you would have in such > frameworks. > > PS: I am one of the core members of Rails by far the biggest framework that > relies on Rack. We tried to add streaming on Rails 3.1 which made very clear > all the shortcomings of the Rack API. We will eventually work on a Rack 2.0 > that is more inspired by the Servlet API. well at least in wsgi, nothing stop you to stream your content. Or even use sendfile. But right that's something a spec should take in consideration. In gunicorn for example I added the socket to the WSGI environ. - beno?t From dmkolesnikov@REDACTED Sat Feb 18 12:52:55 2012 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Sat, 18 Feb 2012 13:52:55 +0200 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: References: Message-ID: Hello Joe, This looks interesting! One of my worries is that it is too late for such language. You are absolutely right about the gap in between erlang and xHTML UI and these solution would definitely facilitate but .... xHTML UI is not only the bindings with run time. It is important to ensure availability of templates. erlydtl addresses this issue by building a compatibility with Python Django templates. From my side, I have been investigating an option to "compile" PHP templates into Erlang code but did not progressed due to time constrains. If you are targeting a wide adoption of EHE then you should work out this aspect.... However, EHE looks cool and I shall try it in my UI projects... Best Regards, Dmitry On Feb 18, 2012, at 1:13 PM, Joe Armstrong wrote: > Thoughts on EHE > > I'm playing with a little language for writing web applications. > It's called EHE. All it is HTML with embedded Erlang > > I like EHE very much since it is the simplest possible way of embedding > Erlang in a web page - I can think of no simpler method - the learning > gap (if you know Erlang and HTML) is pretty near zero. For me > simple = good. > > What is EHE? > > An EHE script is just a file with the extension .ehe. The file > contains HTML or XHTML with embedded Erlang. > > The embedding syntax is > > > > This syntax is chosen since this notation corresponds to an XML processing > instruction. > > Inside the block is sequence of Erlang expressions. > > The replacement value of the block is the last value of the sequence is > just the last value in the sequence, which must be an IO list. > > Binding are propagated forwards between blocks. > > Here's an example > >

Hello

> > > >

Hello > > The first block binds the variable Name and injects "" into the text > The second block injects "joe" into the text. > > Communicating with the environment: > > Inside EHE the global variable SYS provides a bridge to the outside world. > > We can imagine a library of useful functions that change the state of the > environment - like: > > > > > > ... > > and so on > > SYS is a parametrised module that is configured *outside* EHE - so > we can change > the database later *without* changing the EHE code. > > There is an implementation of EHE at > > https://github.com/joearms/adapter_pattern > > (actually there is no SYS module in the git hub code, just an > object called Req) > > Question: Do we need more than this in an embedded language. > > On part of me says NO WAY - you have the full power of erlang at > your disposal. > > Another part says > > > ... > > > Might mean if X is true then omit the block of HTML immediately following > the erlang code block. > > The problem with this is that it leads to a half-baked badly thought out > mess of language and a slippery slope where we want to add just one > more feature. > > For this reason I would suggest that EHE only has the semantics I > have suggested > and nothing else. > > Note - while EHE is interpreted it can easily be compiled if efficiency > is a problem. > > Now the next question - what are the SYS functions: > > SYS:lookup(Key) -> {ok, Value} | error > > SYS is a parametric module that bridges you into Erlang - but what > functions should it > support? > > /Joe > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From jose.valim@REDACTED Sat Feb 18 12:54:48 2012 From: jose.valim@REDACTED (=?utf-8?Q?Jos=C3=A9_Valim?=) Date: Sat, 18 Feb 2012 12:54:48 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: <65AD3CC8-56D8-43E9-9FA3-05554740B395@gmail.com> Yeah, you can put it in the environment but your whole middleware stack ends up clueless of what is happening. Same for streaming. Everything is created based on the wrong expectations. Async should be a requirement, not a nice to have. I hope to have more news published about this soon. From robert.virding@REDACTED Sat Feb 18 13:18:57 2012 From: robert.virding@REDACTED (Robert Virding) Date: Sat, 18 Feb 2012 12:18:57 -0000 (GMT) Subject: [erlang-questions] Misultin EOL In-Reply-To: Message-ID: I have seen behaviours used in this way. All the behaviour contained was the behaviour_info/1 function which just returned the functions' name/arity. It was created for just this purpose. But it is not how behaviours were intended. Robert ----- Original Message ----- > I think a lot of issues with APIs would be solved if we had something > analogous to Java interfaces in Erlang. Behaviors just don't cut it. > I want something that is a replica of interfaces. Then all the > Erlang guys have to do is create the interface and then people can > create whatever implementations they want and I never have to worry > about changing my code! > On Fri, Feb 17, 2012 at 3:03 PM, Tim Watson < > watson.timothy@REDACTED > wrote: > > On 17 February 2012 22:49, Jesse Gumm < gumm@REDACTED > > > wrote: > > > > I agree with you about the parameterised modules. I'm not a big > > > fan > > > > > > of them either (though seeing how it works, I do understand why > > > Rusty > > > > > > went that route), and the deprecation of the tuple modules had me > > > > > > scared for a moment. After that happened, I've been starting to > > > think > > > > > > about a roadmap away from the parameterised modules with > > > > > > simple_bridge. > > > > > I think that's a good idea. > > > I would also like to respectfully suggest that api implementations > > might be distributed separately from the api itself, so that I can > > choose to get simple_bridge and simple_bridge_mochiweb (or > > whatever) > > but ignore the other stuff. Just a suggestion you may wish to > > consider. > > > Cheers, > > > Tim > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From matti.oinas@REDACTED Sat Feb 18 13:31:13 2012 From: matti.oinas@REDACTED (Matti Oinas) Date: Sat, 18 Feb 2012 14:31:13 +0200 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: References: Message-ID: <4F3F9A11.5010001@gmail.com> Hi Joe, This is really great. Now it is simpler to take old page layout from PHP sites and rewrite the application using Erlang. There is one big problem with EHE, PHP, Django, ErlyDTL, etc and it is that the template isn't plain HTML. Any of these needs some kind of special syntax to inserted into HTML to control the generation of final output. Enlive (https://github.com/cgrand/enlive) solves this problem in a really nice way. Enlive templates are nothing but plain HTML. This is a big advantage because many times the HTML templates are written by graphical designers. When using PHP I have to modify the templates to insert PHP code to right places to make it work. It is the same with django, erlydtl and ehe. When template is updated then I have to do this again. With enlive I could just replace the old template with the new one and no other changes are needed. Template library like enlive can also solve most XSS vulnerabilities without any help from developer because the library knows the context where the dynamic data is going and can use proper quoting for that context. In PHP and EHE it is easy to create XSS vulnerabilities.

...
If Id string contains " character then there is XSS vulnerability. Developers must remember to escape data before using it. Enlive like template library can execute proper escape functions because it is aware of the context where that data is going to be inserted. ErlyDTL makes automatic escapes, but the defaults aren't always enough because HTML is a pretty complex beast that requires different characters escaped depending on the context. Developer doesn't need to escape the data because library makes it automatically so no more XSS vulnerabilities because developer forgot to escape some data before it was inserted into template. Biggest problem with enlive is that it is written with clojure. Not that clojure isn't great but it still isn't erlang. I think it is time to rewrite some PHP code with erlang and EHE. Matti On 02/18/2012 01:13 PM, Joe Armstrong wrote: > Thoughts on EHE > > I'm playing with a little language for writing web applications. > It's called EHE. All it is HTML with embedded Erlang > > I like EHE very much since it is the simplest possible way of embedding > Erlang in a web page - I can think of no simpler method - the learning > gap (if you know Erlang and HTML) is pretty near zero. For me > simple = good. > > What is EHE? > > An EHE script is just a file with the extension .ehe. The file > contains HTML or XHTML with embedded Erlang. > > The embedding syntax is > > > > This syntax is chosen since this notation corresponds to an XML processing > instruction. > > Inside the block is sequence of Erlang expressions. > > The replacement value of the block is the last value of the sequence is > just the last value in the sequence, which must be an IO list. > > Binding are propagated forwards between blocks. > > Here's an example > >

Hello

> > > >

Hello > > The first block binds the variable Name and injects "" into the text > The second block injects "joe" into the text. > > Communicating with the environment: > > Inside EHE the global variable SYS provides a bridge to the outside world. > > We can imagine a library of useful functions that change the state of the > environment - like: > > > > > > ... > > and so on > > SYS is a parametrised module that is configured *outside* EHE - so > we can change > the database later *without* changing the EHE code. > > There is an implementation of EHE at > > https://github.com/joearms/adapter_pattern > > (actually there is no SYS module in the git hub code, just an > object called Req) > > Question: Do we need more than this in an embedded language. > > On part of me says NO WAY - you have the full power of erlang at > your disposal. > > Another part says > > > ... > > > Might mean if X is true then omit the block of HTML immediately following > the erlang code block. > > The problem with this is that it leads to a half-baked badly thought out > mess of language and a slippery slope where we want to add just one > more feature. > > For this reason I would suggest that EHE only has the semantics I > have suggested > and nothing else. > > Note - while EHE is interpreted it can easily be compiled if efficiency > is a problem. > > Now the next question - what are the SYS functions: > > SYS:lookup(Key) -> {ok, Value} | error > > SYS is a parametric module that bridges you into Erlang - but what > functions should it > support? > > /Joe > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From watson.timothy@REDACTED Sat Feb 18 14:03:25 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Sat, 18 Feb 2012 13:03:25 +0000 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: On 18 February 2012 11:30, Jos? Valim wrote: > > Something that gets this right though is servlet API from Java with the > concept of generators, filters and etc. Streaming works fine as you can, at > any point, push data into the socket and filters/generators are wrapped by > this API. > +1. The Java Servlet API is excellent. Filter chains provide a simple and consistent approach to request wrapping, and Servlets provide just the right low level API for interacting with the request and/or response, allowing you to get to the socket API underneath if you need to. Good frameworks can be built on top of this easily. I also like that you configure filters/servlets using exactly the same XML configuration regardless of the web server you're running in. Obviously I'd prefer it if it wasn't XML, but the consistency is the thing. YAWS uses config files in this way (e.g., for setting up appmods) and I wish all the web server frameworks did the same, or at least the whatever common API was available would support the notion. > Every time I see a Erlang or a Node.js framework based on top of Rack/WSGI a > part of me dies because the ability of streaming and asynchronously pushing > stuff down the socket is one of the best features you would have in such > frameworks. > > PS: I am one of the core members of Rails by far the biggest framework that > relies on Rack. We tried to add streaming on Rails 3.1 which made very clear > all the shortcomings of the Rack API. We will eventually work on a Rack 2.0 > that is more inspired by the Servlet API. > JDBC and the Servlet API are both exemplary parts of the Java world. In fairness to the .NET crowd, the ADO.NET and IIS centric web APIs (HttpHandler and HttpModule) do it almost exactly the same way. From watson.timothy@REDACTED Sat Feb 18 14:19:55 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Sat, 18 Feb 2012 13:19:55 +0000 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D991E.5000205@ninenines.eu> <4915914f-b378-43ab-9fcc-742980c2ee43@bs8g2000vbb.googlegroups.com> Message-ID: Hi Joe, I don't think you actually *need* a single scripting language to rule them all - nowhere else is this the case. Even in PHP there are templating and MVC frameworks, because fundamentally any large code base begins to fray at the seams in the face of 'scriptlet' code because it is (a) hard to isolate and therefore (b) hard to unit test (c) makes it 'easy' to do the wrong thing and mingle view generation and business logic, violating separation of concerns Personally I avoid things like this (PHP, JSP, ASP.NET, etc) like the plague, opting for templating tools like ErlyDTL or - more often than not - generating JSON/XML directly from the data model and streaming/serialising this back to the client. Other than that, I think a consistent interface between the different web servers is a bloody awesome step in the right direction. One thing that simple_bridge does well, in its philosophy at least, is to delegate to the underlying framework/server as much as possible, for things like identifying the mime type. Also I don't think that the implementation adapter should make choices about, for example, the JSON library used to do the serialisation/de-serialisation as in https://github.com/joearms/adapter_pattern/blob/master/mochiweb_adapter.erl#L48. I want to make my own choices when I'm building a web application, which include 1. what libraries I use to serialise/de-serialise data 2. what scripting and/or templating libraries I wish to use to generate content (if this approach is in play) 3. what response codes I want to send to the client So I fundamentally like where you're going with this, but it's a bit too high a level of abstraction for a 'generic web server api' and is making too many choices about these things (above). You need to offer lower level APIs that bridge the different web servers, as simple_bridge does. And on that note, if parameterised modules are going to be official and 'ok' soon, then simple_bridge is actually a long way ahead already, so maybe it's worth spending some time looking at it too. On 18 February 2012 10:39, Joe Armstrong wrote: > On Fri, Feb 17, 2012 at 11:12 PM, Tim Watson wrote: >> On 17 February 2012 02:09, Steve Davis >> wrote: >>> >>> Hi Roberto, >>> >>> I'm a bit confused by this whole thread... >>> >>> I'm agreeing with Jesse that since Misultin is open source, it's not >>> really in your control to "stop development" if the interest is there >>> elsewhere to push it on? >>> >>> I'm also agreeing with Steve that I've not seen any demonstration that >>> yaws is somehow "lacking", >>> >>> For me, the last interesting benchmark that demonstrated anything >>> graspably real was "yaws vs apache". >>> >>> A really interesting benchmark for today's "web server" would be, if >>> someone were willing to engage in a non-trivial effort, to make a >>> comparison of a full-fledged web application with full session >>> management and routing capabilities. Note that this would truly test >>> the appropriateness of the server's http APIs as well as the base >>> response. That kind of benchmark, for me, would seem more appropriate >>> and useful according to the epoch. >> >> >> I've been suggesting this for some time now. I will make some time (somehow) >> to participate and I'm sure others will too. > > Yes ^ 100 > > My *minimal* application does this for *every* GET request > > ? 1) Is there a cookie? > ? 2) If no cookie redirect to a set-cookie page > ? 3) if there is a cookie lookup value in database > ? 4) if no value in DB redirect to warning page > ? 5) if there is a value check if user is authenticated > ? 6) if not authenticated redirect to login page > ? 7) if authenticated lookup same basic data about user > ? ? ? in DB > ? 8) send the result > > I suspect that impedance mismatches between the DB and > web server are the main sources of inefficiency > > The *interesting* benchmark is (say) the number of > page-views in a forum/second or the number of searches/second in a forum. > > We need to implement something like PHPBB and benchmark the number of > page-views/second > (Actually doing so would involve even more work before a page gets > sent - is the IP blacklisted? - has the user > posted more than N requests in the last T seconds - > is the user a spammer...) > > One thing that hinders this is the lack of a common language > to implement the web-part in. I have made a little language > EHE for this - which included in my adapter pattern - EHE is > easy to embed in *any* erlang web server - I have done so > for misultin, cowboy and mochiweb see > > ? https://github.com/joearms/adapter_pattern > > The database for something like a web forum needs > investigation: > > > I want a data base with the following characteristics > > ? - persistent > ? - Key-Value > ? - fast lookups > ? - slow writes > ? - full-text indexing of certain fields of certain key-types > > In a forum type application the read-write ratio is heavily > skewed in favor of reads - ie lots of reads very few writes. > > I am making a systems where all keys-values are stored in > an ets table. > > Reads go to the ets table, writes go to the ets table and are trailed > on disk. I guess I'd also like large values on disk > small values in the ets table. Oh and I'd also like full-text indexing > on tuple fields. ie if I say > > ? ?store({post,12456},#item{user="joe", text="......"}) > > Id like to automatically index the text field of the record. > > No erlang database I know of fits the bill - I don't want > an interface to mySQL or whatever since I suspect the impedance > mismatch between Erlang and the external > database would be terrible. > > Summary: > > ? ?In addition to a fast web-server we need > > ? ?- a fast persistent DB suitable for web applications > ? ?- zero impedance mismatch between the DB and the web server > ? - a language for the application (like PHP) (you'll find my > ? ? EHE at https://github.com/joearms/adapter_pattern) > ? - authentication > > All these bits have to fit together with bridges (adapters) so > we can change the database/server/authentication without > having to rewrite the entire application. > > Do this and *then* benchmark against PHPBB (or something) > > Cheers > > /Joe >> >>> >>> >>> Best regards, >>> /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 >> From ulf@REDACTED Sat Feb 18 15:26:19 2012 From: ulf@REDACTED (Ulf Wiger) Date: Sat, 18 Feb 2012 15:26:19 +0100 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: <4F3F9A11.5010001@gmail.com> References: <4F3F9A11.5010001@gmail.com> Message-ID: <0D7897B9-4403-40F3-B5A2-B2DCBB5BCF56@feuerlabs.com> On 18 Feb 2012, at 13:31, Matti Oinas wrote: > Biggest problem with enlive is that it is written with clojure. Not that clojure isn't great but it still isn't erlang. I agree that this is a great way to keep the HTML/CSS side pure, and still have lots of power to enhance it with dynamic content. There is an (experimental?) xmerl_sax_parser-based module that is able to parse most existing HTML - certainly enough to handle the kind of templates one should be able to expect from a professional web designer*. With it, and perhaps something like xmerl_xs, it shouldn't be that hard to come up with an enliven-inspired lib in Erlang. BR, Ulf W * I think this is one of the harder problems in the mix: accepting more or less malformed HTML. I know yaws has a HTML parser as well (yaws_html), but don't know how robust it is. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Sat Feb 18 15:32:03 2012 From: erlang@REDACTED (Joe Armstrong) Date: Sat, 18 Feb 2012 15:32:03 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D991E.5000205@ninenines.eu> <4915914f-b378-43ab-9fcc-742980c2ee43@bs8g2000vbb.googlegroups.com> Message-ID: On Sat, Feb 18, 2012 at 2:19 PM, Tim Watson wrote: > Hi Joe, > > I don't think you actually *need* a single scripting language to rule > them all - nowhere else is this the case. Even in PHP there are > templating and MVC frameworks, because fundamentally any large code > base begins to fray at the seams in the face of 'scriptlet' code > because it is > > (a) hard to isolate and therefore > (b) hard to unit test > (c) makes it 'easy' to do the wrong thing and mingle view generation > and business logic, violating separation of concerns > > Personally I avoid things like this (PHP, JSP, ASP.NET, etc) like the > plague, opting for templating tools like ErlyDTL or - more often than > not - generating JSON/XML directly from the data model and > streaming/serialising this back to the client. > > Other than that, I think a consistent interface between the different > web servers is a bloody awesome step in the right direction. One thing > that simple_bridge does well, in its philosophy at least, is to > delegate to the underlying framework/server as much as possible, for > things like identifying the mime type. > > Also I don't think that the implementation adapter should make choices > about, for example, the JSON library used to do the > serialisation/de-serialisation as in > https://github.com/joearms/adapter_pattern/blob/master/mochiweb_adapter.erl#L48. > I want to make my own choices when I'm building a web application, I quite agree - this code was just a proof-of-concept not frozen in stone. As I see things there are two layers: *inside* EHE I'd write code like this: SYS:get_key(Val) would have a well defined type that never changes. *outside* EHE I would define the semantics of get_key so I could say If I wanted a memory resident db, persistent, replicated, authenticated and so on. > which include > > 1. what libraries I use to serialise/de-serialise data > 2. what scripting and/or templating libraries I wish to use to > generate content (if this approach is in play) > 3. what response codes I want to send to the client > > So I fundamentally like where you're going with this, but it's a bit > too high a level of abstraction for a 'generic web server api' and is > making too many choices about these things (above). You need to offer > lower level APIs that bridge the different web servers, as > simple_bridge does. And on that note, if parameterised modules are > going to be official and 'ok' soon, then simple_bridge is actually a > long way ahead already, so maybe it's worth spending some time looking > at it too. I agree /Joe > > On 18 February 2012 10:39, Joe Armstrong wrote: >> On Fri, Feb 17, 2012 at 11:12 PM, Tim Watson wrote: >>> On 17 February 2012 02:09, Steve Davis >>> wrote: >>>> >>>> Hi Roberto, >>>> >>>> I'm a bit confused by this whole thread... >>>> >>>> I'm agreeing with Jesse that since Misultin is open source, it's not >>>> really in your control to "stop development" if the interest is there >>>> elsewhere to push it on? >>>> >>>> I'm also agreeing with Steve that I've not seen any demonstration that >>>> yaws is somehow "lacking", >>>> >>>> For me, the last interesting benchmark that demonstrated anything >>>> graspably real was "yaws vs apache". >>>> >>>> A really interesting benchmark for today's "web server" would be, if >>>> someone were willing to engage in a non-trivial effort, to make a >>>> comparison of a full-fledged web application with full session >>>> management and routing capabilities. Note that this would truly test >>>> the appropriateness of the server's http APIs as well as the base >>>> response. That kind of benchmark, for me, would seem more appropriate >>>> and useful according to the epoch. >>> >>> >>> I've been suggesting this for some time now. I will make some time (somehow) >>> to participate and I'm sure others will too. >> >> Yes ^ 100 >> >> My *minimal* application does this for *every* GET request >> >> ? 1) Is there a cookie? >> ? 2) If no cookie redirect to a set-cookie page >> ? 3) if there is a cookie lookup value in database >> ? 4) if no value in DB redirect to warning page >> ? 5) if there is a value check if user is authenticated >> ? 6) if not authenticated redirect to login page >> ? 7) if authenticated lookup same basic data about user >> ? ? ? in DB >> ? 8) send the result >> >> I suspect that impedance mismatches between the DB and >> web server are the main sources of inefficiency >> >> The *interesting* benchmark is (say) the number of >> page-views in a forum/second or the number of searches/second in a forum. >> >> We need to implement something like PHPBB and benchmark the number of >> page-views/second >> (Actually doing so would involve even more work before a page gets >> sent - is the IP blacklisted? - has the user >> posted more than N requests in the last T seconds - >> is the user a spammer...) >> >> One thing that hinders this is the lack of a common language >> to implement the web-part in. I have made a little language >> EHE for this - which included in my adapter pattern - EHE is >> easy to embed in *any* erlang web server - I have done so >> for misultin, cowboy and mochiweb see >> >> ? https://github.com/joearms/adapter_pattern >> >> The database for something like a web forum needs >> investigation: >> >> >> I want a data base with the following characteristics >> >> ? - persistent >> ? - Key-Value >> ? - fast lookups >> ? - slow writes >> ? - full-text indexing of certain fields of certain key-types >> >> In a forum type application the read-write ratio is heavily >> skewed in favor of reads - ie lots of reads very few writes. >> >> I am making a systems where all keys-values are stored in >> an ets table. >> >> Reads go to the ets table, writes go to the ets table and are trailed >> on disk. I guess I'd also like large values on disk >> small values in the ets table. Oh and I'd also like full-text indexing >> on tuple fields. ie if I say >> >> ? ?store({post,12456},#item{user="joe", text="......"}) >> >> Id like to automatically index the text field of the record. >> >> No erlang database I know of fits the bill - I don't want >> an interface to mySQL or whatever since I suspect the impedance >> mismatch between Erlang and the external >> database would be terrible. >> >> Summary: >> >> ? ?In addition to a fast web-server we need >> >> ? ?- a fast persistent DB suitable for web applications >> ? ?- zero impedance mismatch between the DB and the web server >> ? - a language for the application (like PHP) (you'll find my >> ? ? EHE at https://github.com/joearms/adapter_pattern) >> ? - authentication >> >> All these bits have to fit together with bridges (adapters) so >> we can change the database/server/authentication without >> having to rewrite the entire application. >> >> Do this and *then* benchmark against PHPBB (or something) >> >> Cheers >> >> /Joe >>> >>>> >>>> >>>> Best regards, >>>> /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 >>> From erlang@REDACTED Sat Feb 18 16:13:41 2012 From: erlang@REDACTED (Joe Armstrong) Date: Sat, 18 Feb 2012 16:13:41 +0100 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: <0D7897B9-4403-40F3-B5A2-B2DCBB5BCF56@feuerlabs.com> References: <4F3F9A11.5010001@gmail.com> <0D7897B9-4403-40F3-B5A2-B2DCBB5BCF56@feuerlabs.com> Message-ID: On Sat, Feb 18, 2012 at 3:26 PM, Ulf Wiger wrote: > > On 18 Feb 2012, at 13:31, Matti Oinas wrote: > > Biggest problem with enlive is that it is written with clojure. Not that > clojure isn't great but it still isn't erlang. > > > I agree that this is a great way to keep the HTML/CSS side pure, and still > have lots of power to enhance it with dynamic content. I was thinking about this: In theory having a watertight barrier between logic and presentation seems like a good idea - but is it? I was looking for a good template language that separates logic from control so I looked around a bit. I looked at wordpress (as far as I can see it's just PHP) so is phpBB there are loads of different styles/skins for this so they must be doing something right. Then I looked at the tumblr template language - there are loads of nice templates for this, but this language was highly structured to follow what I assumed was the tumblr internal database schemas. I think I see a pattern here. I have a similar problem with markup language - I have implemented half a dozen markup languages but at the end of the day, when I want to write a book I turn to LaTeX or docbook or an XML markup. The markup languages and templating languages get you a long way very quickly. They solve 95% of the problem immediately (or 98% or something) - its the 5% or 2% in the tail that's the problem. Simple markup languages are useless when you find you want really beautiful output - then you have to sweat blood. Same for web-sites - templating is fine until you want to do something that the template writer had not imagined. Full Erlang embedded in Html solves my problem - it might not be pretty - it might not have strict separation of issues it might not separate logic from control - but it is *very* powerful. I keep hearing about script-kiddies who can understand HTML but not "coding" (whatever that is) or people who can do html but not css so this is not for them. I'm aiming at people who are perfectly happy with mixing erlang/html/css/javascript and I'm not so worried about inversion of control or separation of logic and presentation. This ehe that I mentioned - I just write slap bang in the middle of *anything* - ie HTML, CSS, Javascript, C, java, makefiles, LaTeX - anywhere No mess no problems easy semantics - but not separation of control and logic and presentation. I have been thinking about this for a very very long time - and 100% separation of issues is incredibly difficult. Some I'm back to embedded Erlang + parameterised modules and erlhive thinking ... /Joe > > There is an (experimental?) xmerl_sax_parser-based module that is able to > parse most existing HTML - certainly enough to handle the kind of templates > one should be able to expect from a professional web designer*. With it, and > perhaps something like xmerl_xs, it shouldn't be that hard to come up with > an enliven-inspired lib in Erlang. > > BR, > Ulf W > > > * I think this is one of the harder problems in the mix: accepting more or > less malformed HTML. I know yaws has a HTML parser as well (yaws_html), but > don't know how robust it is. From ulf@REDACTED Sat Feb 18 16:18:34 2012 From: ulf@REDACTED (Ulf Wiger) Date: Sat, 18 Feb 2012 16:18:34 +0100 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: References: <4F3F9A11.5010001@gmail.com> <0D7897B9-4403-40F3-B5A2-B2DCBB5BCF56@feuerlabs.com> Message-ID: <2EC46616-57F6-4AC9-AD35-F7FA05DFDA8C@feuerlabs.com> On 18 Feb 2012, at 16:13, Joe Armstrong wrote: > Some I'm back to embedded Erlang + parameterised modules > and erlhive thinking ... Erlhive is the idea that won't die. :) I keep coming back to how that was really, in many ways, a very, very promising idea. There were some really hard obstacles in actual implementation, though. :) It was also probably one of the most flagrant abuses of parameterized modules to-date. :) BR, Ulf W -------------- next part -------------- An HTML attachment was scrubbed... URL: From tristan.sloughter@REDACTED Sat Feb 18 16:30:41 2012 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Sat, 18 Feb 2012 09:30:41 -0600 Subject: [erlang-questions] HTTP clients Message-ID: Now to http clients instead of servers :) Over the years I've bounced between httpc, lhttpc and ibrowse (I think that's all...) and was wondering what opinions people had on the 3 and which are still developed and used in production. It seems ibrowse has the most features and most development going on. Though examples are lacking for all of them... So on a side note if anyone has an example of posting form data with ibrowse that would be much appreciated. Thanks, Tristan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Sat Feb 18 16:30:16 2012 From: ulf@REDACTED (Ulf Wiger) Date: Sat, 18 Feb 2012 16:30:16 +0100 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: References: <4F3F9A11.5010001@gmail.com> <0D7897B9-4403-40F3-B5A2-B2DCBB5BCF56@feuerlabs.com> Message-ID: <40AB269C-A3FF-4FF9-AC2D-52F7BBE0B317@feuerlabs.com> On 18 Feb 2012, at 16:13, Joe Armstrong wrote: > I was thinking about this: In theory having a watertight > barrier between logic and presentation seems like > a good idea - but is it? To quote Yogi Berra (or Einstein, or van de Snepscheut): "In theory there is no difference between theory and practice. In practice there is." I've found that mixing Erlang into the Web design part drastically reduces the pickings when you need a professional web designer. The erlang community to-date hasn't attracted the kind of people who live to design beautiful HTML pages. The cousin of this train of though is the idea to put Node.js on the server. It makes perfect sense in one way: JavaScript is the one programming language a Web designer MUST be good at. Unfortunately, Node.js is a very bad server-side programming environment. Still, the question is how much that hurts you. PHP isn't a great language, but great websites have been built with it, mainly because enough great web designers make the effort to learn PHP. Of course, for a team of Erlang programmers, the fact that they may be poor web page designers to start with isn't exactly helped by the fact that they have to build their web pages in a programming language they don't master well. OTOH, they can be greatly helped by stealing good open source web designs from the web. Doing so should be easier with an enlive-style approach. Also, if you build a functional prototype, you can get away with a "developer-ugly" web UI, as long as you can hire a pro to make it beautiful later on. If you can stick to mainstream web design techniques as closely as possible, this step will be easier (or less impossible) to take. BR, Ulf W -------------- next part -------------- An HTML attachment was scrubbed... URL: From tristan.sloughter@REDACTED Sat Feb 18 16:45:20 2012 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Sat, 18 Feb 2012 09:45:20 -0600 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: <40AB269C-A3FF-4FF9-AC2D-52F7BBE0B317@feuerlabs.com> References: <4F3F9A11.5010001@gmail.com> <0D7897B9-4403-40F3-B5A2-B2DCBB5BCF56@feuerlabs.com> <40AB269C-A3FF-4FF9-AC2D-52F7BBE0B317@feuerlabs.com> Message-ID: > > I've found that mixing Erlang into the Web design part drastically reduces > the pickings when you need a professional web designer. The erlang > community to-date hasn't attracted the kind of people who live to design > beautiful HTML pages. > And not just that but reusing components from others and debugging is complicated by embedding code in the client side markup. That is why I've found using a client side MVC (in Coffeescript so its not as painful) with templates that are pure HTML (like Batman.js does, http://batmanjs.org/) and interfacing with Erlang only for dynamic data exchange with JSON is the best approach. This approach allows the frontend to be developed separately with only worrying about what format the data sent and received must be. Now your frontend developer can even just throw test JSON into a basic Node server to test their work. And since its pure HTML templates you can even view the site just fine without any server running. Now you can use any webserver and CDN to serve up your static frontend and your Erlang code not having to deal with templating or serving up static files. Though I am finding Opa (http://opalang.org) and Play! with Scala ( http://www.playframework.org/2.0) intriguing and they do not follow these rules at all :) Tristan -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Sat Feb 18 16:45:45 2012 From: max.lapshin@REDACTED (Max Lapshin) Date: Sat, 18 Feb 2012 18:45:45 +0300 Subject: [erlang-questions] HTTP clients In-Reply-To: References: Message-ID: I've rxperienced extremely high load with ibrowse: about 60% for downloading one file. I had to add my own implementation to erlyvideo On Saturday, February 18, 2012, Tristan Sloughter < tristan.sloughter@REDACTED> wrote: > Now to http clients instead of servers :) > Over the years I've bounced between httpc, lhttpc and ibrowse (I think that's all...) and was wondering what opinions people had on the 3 and which are still developed and used in production. > It seems ibrowse has the most features and most development going on. > Though examples are lacking for all of them... So on a side note if anyone has an example of posting form data with ibrowse that would be much appreciated. > Thanks, > Tristan -------------- next part -------------- An HTML attachment was scrubbed... URL: From gumm@REDACTED Sat Feb 18 17:16:25 2012 From: gumm@REDACTED (Jesse Gumm) Date: Sat, 18 Feb 2012 10:16:25 -0600 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: Well that is good news to hear that param modules are here to say. -- Jesse Gumm Owner, Sigma Star Systems 414.940.4866 www.sigma-star.com @jessegumm On Feb 18, 2012 5:14 AM, "Joe Armstrong" wrote: > On Sat, Feb 18, 2012 at 12:05 PM, Jos? Valim wrote: > >> I'd be keen on simple bridge if the Erlang guys would just come out and > >> say if they support parameterized modules or not. If they don't, just > get > >> rid of it. What's the point of having something in a language if it's > not > >> going to be supported (but that's a different topic)? > >> > >> > >> I agree that if something is added as an experimental feature, it should > >> either be graduated or removed as soon as possible, not stay > experimental > >> indefinitely. > > > > > > I don't use parameterized modules at all but it would be a pity to see { > > module, args }:function() go. > > It will stay - and be documented to make it official > > /Joe > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matti.oinas@REDACTED Sat Feb 18 17:33:11 2012 From: matti.oinas@REDACTED (Matti Oinas) Date: Sat, 18 Feb 2012 18:33:11 +0200 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: References: <4F3F9A11.5010001@gmail.com> <0D7897B9-4403-40F3-B5A2-B2DCBB5BCF56@feuerlabs.com> Message-ID: <4F3FD2C7.2010101@gmail.com> On 02/18/2012 05:13 PM, Joe Armstrong wrote: > In theory having a watertight > barrier between logic and presentation seems like > a good idea - but is it? Sometimes it is and sometimes isn't. Most of the time at work I'm not the one who writes the HTML. They just send these HTML templates to me and I'll add necessary PHP code to these templates. With total separation of logic and presentation I could just replace old html template with new one without any modifications. It probably wouldn't work every situations but in these situations I could just revert back to the old way of inserting PHP into HTML. If this separation would work even 80% of situations then I sure would benefit from that. We need things like EHE for maximum flexibility, but enlive like template engine would help us also a lot. I wouldn't mind mixing these two into same application. Using enlive like engine when possible and using EHE when other engine doesn't provide enough flexibility. When writing HTML myself then enlive like template doesn't offer much compared to EHE. Only thing enlive style engine could offer as a benefit compared to EHE is automatic escaping for the dynamic content. I know how things need to be escaped that they are safe to use, but I do forget to do that escaping sometimes and will introduce XSS vulnerabilities to the code. Even if vulnerability couldn't be used anything serious it could still damage the reputation of the service and service could lose its users. Xmerl could be used to parse these templates if only XHTML would be supported. We could also easily validate these templates for correct markup using XML validators. Matti From steve@REDACTED Sat Feb 18 17:44:35 2012 From: steve@REDACTED (Steve Strong) Date: Sat, 18 Feb 2012 17:44:35 +0100 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: References: <4F3F9A11.5010001@gmail.com> <0D7897B9-4403-40F3-B5A2-B2DCBB5BCF56@feuerlabs.com> <40AB269C-A3FF-4FF9-AC2D-52F7BBE0B317@feuerlabs.com> Message-ID: +1, this is also my preferred way for building HTML; it keeps the server very clean (just a json Api), and I find that a good JavaScript library can keep the ui code well structured. It does put a requirement on JavaScript being enabled, so it may not be appropriate for every site, but if you're happy with that restriction then I think it's hard to beat. Cheers, Steve Sent from my iPhone On 18 Feb 2012, at 16:45, Tristan Sloughter wrote: > I've found that mixing Erlang into the Web design part drastically reduces the pickings when you need a professional web designer. The erlang community to-date hasn't attracted the kind of people who live to design beautiful HTML pages. > > And not just that but reusing components from others and debugging is complicated by embedding code in the client side markup. > > That is why I've found using a client side MVC (in Coffeescript so its not as painful) with templates that are pure HTML (like Batman.js does, http://batmanjs.org/) and interfacing with Erlang only for dynamic data exchange with JSON is the best approach. > > This approach allows the frontend to be developed separately with only worrying about what format the data sent and received must be. Now your frontend developer can even just throw test JSON into a basic Node server to test their work. And since its pure HTML templates you can even view the site just fine without any server running. > > Now you can use any webserver and CDN to serve up your static frontend and your Erlang code not having to deal with templating or serving up static files. > > Though I am finding Opa (http://opalang.org) and Play! with Scala (http://www.playframework.org/2.0) intriguing and they do not follow these rules at all :) > > Tristan > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Sat Feb 18 17:58:17 2012 From: erlang@REDACTED (Joe Armstrong) Date: Sat, 18 Feb 2012 17:58:17 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: On Sat, Feb 18, 2012 at 5:16 PM, Jesse Gumm wrote: > Well that is good news to hear that param modules are here to say. Well actually it's the abuse of PMs that will stay. That {Mod,a,b,c}:foo(x,y) means foo(x,y,{Mod,a,b,c}) is an accidental side effect of the way parameterised modules were implemented. The "official way of creating a PM" is with Mod:new(...) and NOT PM = {Mod,a,b,c}. Somebody (I don't know who) discovered how to build a PM *without* calling Mod:new. I discovered this when reading the misultin code since this has never been documented. I fell mentally off my chair - I had no idea this was possible. I think (I speculate here) that misultin got the idea from mochiweb, but how mochiweb got the idea I know not. It's actually a very nice mechanism - the MFA and fun alternatives are a few characters more and less pretty so it will stay. /Joe > > -- > Jesse Gumm > Owner, Sigma Star Systems > 414.940.4866 > www.sigma-star.com > @jessegumm > > On Feb 18, 2012 5:14 AM, "Joe Armstrong" wrote: >> >> On Sat, Feb 18, 2012 at 12:05 PM, Jos? Valim wrote: >> >> I'd be keen on simple bridge if the Erlang guys would just come out and >> >> say if they support parameterized modules or not. ?If they don't, just >> >> get >> >> rid of it. ?What's the point of having something in a language if it's >> >> not >> >> going to be supported (but that's a different topic)? >> >> >> >> >> >> I agree that if something is added as an experimental feature, it >> >> should >> >> either be graduated or removed as soon as possible, not stay >> >> experimental >> >> indefinitely. >> > >> > >> > I don't use parameterized modules at all but it would be a pity to see { >> > module, args }:function() go. >> >> It will stay - and be documented to make it official >> >> /Joe >> >> >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> > From robert.virding@REDACTED Sat Feb 18 17:59:28 2012 From: robert.virding@REDACTED (Robert Virding) Date: Sat, 18 Feb 2012 16:59:28 -0000 (GMT) Subject: [erlang-questions] Luerl - Lua in Erlang Message-ID: <25cd53a2-77ca-4be9-9092-2925380491ee@knuth> I just want to announce that I have released the first version of Luerl - Lua in Erlang. It is a Lua interpreter written in Erlang which started off as a proof of concept and an experiment with handling mutable data, but it grew. You can find it at: https://github.com/rvirding/luerl It is not a full Lua but it implements most of the language and a sizeable portion of the standard libraries. The user interface is lacking but I am working on that. I am also working on improving the speed and extending the libraries. Robert From tristan.sloughter@REDACTED Sat Feb 18 18:06:58 2012 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Sat, 18 Feb 2012 11:06:58 -0600 Subject: [erlang-questions] HTTP clients In-Reply-To: References: Message-ID: So you modified it here, https://github.com/erlyvideo/erlyvideo/tree/master/apps/ibrowse ? Is there a reason these changes aren't added to the main ibrowse repo? On Sat, Feb 18, 2012 at 9:45 AM, Max Lapshin wrote: > I've rxperienced extremely high load with ibrowse: about 60% for > downloading one file. > > I had to add my own implementation to erlyvideo > > > On Saturday, February 18, 2012, Tristan Sloughter < > tristan.sloughter@REDACTED> wrote: > > Now to http clients instead of servers :) > > Over the years I've bounced between httpc, lhttpc and ibrowse (I think > that's all...) and was wondering what opinions people had on the 3 and > which are still developed and used in production. > > It seems ibrowse has the most features and most development going on. > > Though examples are lacking for all of them... So on a side note if > anyone has an example of posting form data with ibrowse that would be much > appreciated. > > Thanks, > > Tristan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob@REDACTED Sat Feb 18 18:15:34 2012 From: bob@REDACTED (Bob Ippolito) Date: Sat, 18 Feb 2012 09:15:34 -0800 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: On Sat, Feb 18, 2012 at 8:58 AM, Joe Armstrong wrote: > On Sat, Feb 18, 2012 at 5:16 PM, Jesse Gumm wrote: > > Well that is good news to hear that param modules are here to say. > > Well actually it's the abuse of PMs that will stay. > > That {Mod,a,b,c}:foo(x,y) means foo(x,y,{Mod,a,b,c}) > is an accidental side effect of the way parameterised modules > were implemented. > > The "official way of creating a PM" is with Mod:new(...) > and NOT PM = {Mod,a,b,c}. Somebody (I don't know who) > discovered how to build a PM *without* calling Mod:new. > > I discovered this when reading the misultin code since this > has never been documented. I fell mentally off my chair - I had no > idea this was possible. I think (I speculate here) that > misultin got the idea from mochiweb, but how mochiweb got the idea I know > not. > > It's actually a very nice mechanism - the MFA and fun alternatives are > a few characters more and less pretty > so it will stay. I think that the paper introducing PMs mentioned it, but it's hard not to see what the representation of a PM looks like at the prompt. -bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From gordon@REDACTED Sat Feb 18 18:20:18 2012 From: gordon@REDACTED (Gordon Guthrie) Date: Sat, 18 Feb 2012 17:20:18 +0000 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: References: <4F3F9A11.5010001@gmail.com> <0D7897B9-4403-40F3-B5A2-B2DCBB5BCF56@feuerlabs.com> <40AB269C-A3FF-4FF9-AC2D-52F7BBE0B317@feuerlabs.com> Message-ID: <0FC496B2-F001-4855-BEA6-595944F67BF9@hypernumbers.com> +1 ditto There are still internationalisation issues to resolve but pure Ajax MVC is so much better than rendering. Gordon Sent from my iPhone On 18 Feb 2012, at 16:44, Steve Strong wrote: > +1, this is also my preferred way for building HTML; it keeps the server very clean (just a json Api), and I find that a good JavaScript library can keep the ui code well structured. It does put a requirement on JavaScript being enabled, so it may not be appropriate for every site, but if you're happy with that restriction then I think it's hard to beat. > > Cheers, > > Steve > > Sent from my iPhone > > On 18 Feb 2012, at 16:45, Tristan Sloughter wrote: > >> I've found that mixing Erlang into the Web design part drastically reduces the pickings when you need a professional web designer. The erlang community to-date hasn't attracted the kind of people who live to design beautiful HTML pages. >> >> And not just that but reusing components from others and debugging is complicated by embedding code in the client side markup. >> >> That is why I've found using a client side MVC (in Coffeescript so its not as painful) with templates that are pure HTML (like Batman.js does, http://batmanjs.org/) and interfacing with Erlang only for dynamic data exchange with JSON is the best approach. >> >> This approach allows the frontend to be developed separately with only worrying about what format the data sent and received must be. Now your frontend developer can even just throw test JSON into a basic Node server to test their work. And since its pure HTML templates you can even view the site just fine without any server running. >> >> Now you can use any webserver and CDN to serve up your static frontend and your Erlang code not having to deal with templating or serving up static files. >> >> Though I am finding Opa (http://opalang.org) and Play! with Scala (http://www.playframework.org/2.0) intriguing and they do not follow these rules at all :) >> >> Tristan >> _______________________________________________ >> erlang-questions mailing list >> 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 Sat Feb 18 18:21:22 2012 From: ulf@REDACTED (Ulf Wiger) Date: Sat, 18 Feb 2012 18:21:22 +0100 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: <4F3FD2C7.2010101@gmail.com> References: <4F3F9A11.5010001@gmail.com> <0D7897B9-4403-40F3-B5A2-B2DCBB5BCF56@feuerlabs.com> <4F3FD2C7.2010101@gmail.com> Message-ID: <4475D48B-4CFB-4961-8753-F9DFF16885EE@feuerlabs.com> On 18 Feb 2012, at 17:33, Matti Oinas wrote: > Xmerl could be used to parse these templates if only XHTML would be supported. We could also easily validate these templates for correct markup using XML validators. Like I wrote, there is an unreleased version of xmerl_sax_parser with a 'html' mode, which handles most of the usual HTML badness (i.e. non-well-formed XML). I would like to suggest that the OTP team release it. It doesn't have to be perfect. When parsing html, there is no such thing as perfect. There is also the yaws_html module, which I admit that I've never used. BR, Ulf W -------------- next part -------------- An HTML attachment was scrubbed... URL: From matti.oinas@REDACTED Sat Feb 18 19:20:15 2012 From: matti.oinas@REDACTED (Matti Oinas) Date: Sat, 18 Feb 2012 20:20:15 +0200 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: <4475D48B-4CFB-4961-8753-F9DFF16885EE@feuerlabs.com> References: <4F3F9A11.5010001@gmail.com> <0D7897B9-4403-40F3-B5A2-B2DCBB5BCF56@feuerlabs.com> <4F3FD2C7.2010101@gmail.com> <4475D48B-4CFB-4961-8753-F9DFF16885EE@feuerlabs.com> Message-ID: <4F3FEBDF.9040702@gmail.com> On 02/18/2012 07:21 PM, Ulf Wiger wrote: > Like I wrote, there is an unreleased version of xmerl_sax_parser with > a 'html' mode, which handles most of the usual HTML badness (i.e. > non-well-formed XML). Sorry, I forgot to quote you in my previous post and there was also a major error in my text. I meant to say that if template engine supports only XHTML syntax then xmerl will do as it is at the moment because only XML parser is needed. That would be enough for me. I think I'll have to try to write an erlang version of enlive library and allow only XHTML syntax. Would be a great exercise and erlang doesn't have that kind of template engine at the moment as far as I know. > I would like to suggest that the OTP team release it. It doesn't have > to be perfect. When parsing html, there is no such thing as perfect. > There is also the yaws_html module, which I admit that I've never used. Decent HTML parser would be great. I'm currently maintaining an application that allows users to use normal HTML syntax to format the content they send to the service. HTML parser is used to do some cleanup and possibly modify the content a bit before it is stored into database. Xmerl html support sounds really promising. Allready using xmerl to parse XML in my erlang applications so this would remove the need for external module for parsing HTML. I have to try to rewrite my HTML cleanup code using the yaws_html module while waiting the xmerl html parser. The rest of the application is easy to rewrite using erlang so I might be able to get rid of PHP. Once this is done I could get the new erlang version accepted and running in production and eventually everyone would win. PHP isn't a good choice if the application is run on several machines and every machine must be able to communicate with others. From max.lapshin@REDACTED Sat Feb 18 19:24:05 2012 From: max.lapshin@REDACTED (Max Lapshin) Date: Sat, 18 Feb 2012 21:24:05 +0300 Subject: [erlang-questions] HTTP clients In-Reply-To: References: Message-ID: On Sat, Feb 18, 2012 at 9:06 PM, Tristan Sloughter wrote: > So you modified it here, > https://github.com/erlyvideo/erlyvideo/tree/master/apps/ibrowse?? > > Is there a reason these changes aren't added to the main ibrowse repo? > No, I speak about https://github.com/erlyvideo/erlyvideo/blob/master/apps/erlmedia/src/http_stream.erl this piece of code is a very, very limited subset of ibrowse. But it solves one very important for me problem: deliver large amount of video data in thousands of simultaneous streams. From mattevans123@REDACTED Sat Feb 18 19:29:07 2012 From: mattevans123@REDACTED (Matthew Evans) Date: Sat, 18 Feb 2012 13:29:07 -0500 Subject: [erlang-questions] Luerl - Lua in Erlang In-Reply-To: <25cd53a2-77ca-4be9-9092-2925380491ee@knuth> References: <25cd53a2-77ca-4be9-9092-2925380491ee@knuth> Message-ID: Very nice. Is it possible to call Erlang functions from inside a Lua script? Matt > Date: Sat, 18 Feb 2012 16:59:28 +0000 > From: robert.virding@REDACTED > To: erlang-questions@REDACTED > Subject: [erlang-questions] Luerl - Lua in Erlang > > I just want to announce that I have released the first version of Luerl - Lua in Erlang. It is a Lua interpreter written in Erlang which started off as a proof of concept and an experiment with handling mutable data, but it grew. You can find it at: > > https://github.com/rvirding/luerl > > It is not a full Lua but it implements most of the language and a sizeable portion of the standard libraries. The user interface is lacking but I am working on that. I am also working on improving the speed and extending the libraries. > > Robert > _______________________________________________ > 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 Sat Feb 18 20:09:00 2012 From: robert.virding@REDACTED (Robert Virding) Date: Sat, 18 Feb 2012 19:09:00 -0000 (GMT) Subject: [erlang-questions] Luerl - Lua in Erlang In-Reply-To: Message-ID: <9e065e6f-c64a-4204-a75b-bf778cd34159@knuth> Not yet, but it would easy to fix an erlang interface. I have been more concentrating on the low-level stuff. Robert ----- Original Message ----- > Very nice. > Is it possible to call Erlang functions from inside a Lua script? > Matt > > Date: Sat, 18 Feb 2012 16:59:28 +0000 > > From: robert.virding@REDACTED > > To: erlang-questions@REDACTED > > Subject: [erlang-questions] Luerl - Lua in Erlang > > > > I just want to announce that I have released the first version of > > Luerl - Lua in Erlang. It is a Lua interpreter written in Erlang > > which started off as a proof of concept and an experiment with > > handling mutable data, but it grew. You can find it at: > > > > https://github.com/rvirding/luerl > > > > It is not a full Lua but it implements most of the language and a > > sizeable portion of the standard libraries. The user interface is > > lacking but I am working on that. I am also working on improving > > the speed and extending the libraries. > > > > Robert > > _______________________________________________ > > 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 Sat Feb 18 20:27:06 2012 From: robert.virding@REDACTED (Robert Virding) Date: Sat, 18 Feb 2012 19:27:06 -0000 (GMT) Subject: [erlang-questions] Luerl - Lua in Erlang In-Reply-To: <25cd53a2-77ca-4be9-9092-2925380491ee@knuth> Message-ID: Seeing there is a discussion about scripting languages I thought I would add an extra one in the fray. Doing PHP in Erlang would not be impossible but the syntax is a right mess and there are a LOT of libraries to do. Robert ----- Original Message ----- > I just want to announce that I have released the first version of > Luerl - Lua in Erlang. It is a Lua interpreter written in Erlang > which started off as a proof of concept and an experiment with > handling mutable data, but it grew. You can find it at: > > https://github.com/rvirding/luerl > > It is not a full Lua but it implements most of the language and a > sizeable portion of the standard libraries. The user interface is > lacking but I am working on that. I am also working on improving the > speed and extending the libraries. > > Robert > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From vinoski@REDACTED Sat Feb 18 20:55:04 2012 From: vinoski@REDACTED (Steve Vinoski) Date: Sat, 18 Feb 2012 14:55:04 -0500 Subject: [erlang-questions] Misultin EOL In-Reply-To: <4F3E6EB2.3000505@ninenines.eu> References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> <4F3E6EB2.3000505@ninenines.eu> Message-ID: On Fri, Feb 17, 2012 at 10:13 AM, Lo?c Hoguin wrote: > On 02/17/2012 04:06 PM, Steve Vinoski wrote: >> >> Earlier in this thread we have this gem from Lo?c: >> >>> I'm sad to see Misultin go, this was in my opinion the only other project >>> that had enough >>> momentum to introduce innovation in Erlang web servers. > > > I'm sorry if you misunderstood this but you also provide the reason why I > have that opinion. > > >> Yaws exists and continues to exist because people continue to use it >> in real-life production systems. Klacke, Christopher, and I all have >> day jobs, so whatever time we put into yaws is based on what users are >> asking for. > > > Misultin and Cowboy are still at a point in the projects' life where > features continue being added or improved before users request them, not the > other way around. They can also afford to break the API a little if a better > solution exists, since both of them aren't considered stable at this point. > > That's all I meant. Sorry but a) I don't see how you expect anyone to be able to derive this interpretation from what you originally said, and b) this still has nothing to do with innovation. Do you equate innovation with greenfield development? You have to break APIs just to innovate? If so that's awfully misguided. I suggest studying the work of Clayton Christensen and his Harvard Business school colleagues, as well as others such as Geoffrey Moore and Steve Denning if you want to know what innovation actually is. When it comes to innovation, Scott Berkun, author of "The Myths of Innovation", once offered this advice: http://www.scottberkun.com/blog/2008/stop-saying-innovation-heres-why/ Fact is, plenty of innovation has occurred in Yaws over the past few years. When I added process-based streaming, for example, it enabled long-polling apps and served as a basis for websocket support. It also allowed me (in my day job at the time) to integrate Yaws with a proprietary hardware TCP offload engine for video delivery, notably without any special patches or changes to Yaws itself. Innovative? You bet. Christopher Faulet added a number of small features over the past year that are incredibly useful to anyone using Yaws in production. Even just adding rebar support to Yaws led to several innovative changes within rebar, making it cleaner in spots. I added support for the relatively recent HTTP PATCH verb to Yaws even though nobody asked for it, simply because it's in the spec. We even occasionally slightly broke interfaces to make improvements. And we intend to continue to innovate, through Yaws 2.0 and beyond. As I said at Erlang Factory London 2011 and in my keynote at the Erlang Workshop in Tokyo last September, my personal opinion is that nobody should be writing new Erlang web servers. Every new "lightweight" "library" web server eventually just gains weight to the point where still another new project pops up to build something more lightweight again. If you think something like this won't eventually follow Cowboy, you're dreaming. But all these new web servers just splinter the Erlang web development community IMO, and they result in multiple efforts all having to implement the same support for the same features, all in different non-reusable ways of course. If people want to contribute they should instead be working either within existing projects like Yaws, or perhaps better yet, within Erlang/OTP itself, in both the Erlang code and the C code, to improve scaling and performance at that level. Speed up the HTTP parsing within Erlang, for example. Consider what the OTP team continues to do with multicore performance, or what Scott Fritchie is doing with dtrace integration. Doing stuff like that raises all ships -- all Erlang applications, whether web-focused or not, benefit from such efforts. --steve From rapsey@REDACTED Sat Feb 18 20:56:34 2012 From: rapsey@REDACTED (Rapsey) Date: Sat, 18 Feb 2012 20:56:34 +0100 Subject: [erlang-questions] HTTP clients In-Reply-To: References: Message-ID: We used ibrowse for a while as well. We didn't have the high CPU bug, but we did have a lot of failed requests for which there was no reason for them to fail. The keepalive connection pooling seems to have some bugs. We also just went and implemented a really simple http library, that always creates a new tcp connection and closes when it's done. Sergej On Sat, Feb 18, 2012 at 7:24 PM, Max Lapshin wrote: > On Sat, Feb 18, 2012 at 9:06 PM, Tristan Sloughter > wrote: > > So you modified it here, > > https://github.com/erlyvideo/erlyvideo/tree/master/apps/ibrowse ? > > > > Is there a reason these changes aren't added to the main ibrowse repo? > > > > No, I speak about > > https://github.com/erlyvideo/erlyvideo/blob/master/apps/erlmedia/src/http_stream.erl > > this piece of code is a very, very limited subset of ibrowse. But it > solves one very important for me problem: deliver large amount of > video data in thousands of simultaneous streams. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Sat Feb 18 20:57:01 2012 From: vinoski@REDACTED (Steve Vinoski) Date: Sat, 18 Feb 2012 14:57:01 -0500 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: On Sat, Feb 18, 2012 at 6:18 AM, Benoit Chesneau wrote: > In python world we have WSGI that define a common spec to interface > Python application with the web. Something like this, EWGI, was built a few years ago, but never seemed to go anywhere: https://github.com/skarab/ewgi --steve From comptekki@REDACTED Sat Feb 18 21:05:28 2012 From: comptekki@REDACTED (Wes James) Date: Sat, 18 Feb 2012 13:05:28 -0700 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: References: Message-ID: On Sat, Feb 18, 2012 at 4:13 AM, Joe Armstrong wrote: > Thoughts on EHE > > I'm playing with a little language for writing web applications. > It's called EHE. All it is HTML with embedded Erlang Isn't this what is in YAWS already? http://yaws.hyber.org/dynamic.yaws -wes From g@REDACTED Sat Feb 18 21:14:55 2012 From: g@REDACTED (Garrett Smith) Date: Sat, 18 Feb 2012 14:14:55 -0600 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: On Sat, Feb 18, 2012 at 5:18 AM, Benoit Chesneau wrote: > On Sat, Feb 18, 2012 at 12:05 AM, Andrew Berman wrote: >> I think a lot of issues with APIs would be solved if we had something >> analogous to Java interfaces in Erlang. ?Behaviors just don't cut it. ?I >> want something that is a replica of interfaces. ?Then all the Erlang guys >> have to do is create the interface and then people can create whatever >> implementations they want and I never have to worry about changing my code! >> > In python world we have WSGI that define a common spec to interface > Python application with the web. Defining how server should handle > requests to and return response from applications. Also defining how > the requests/responses should be formatted for the apps. > > There are many servers and many libs/frameworks handling the spec. > Only the code quality, the technical differences and features distinct > them. ?I guess somethng like that could be defined in Erlang with a > lib reference to test the validaty and validate servers and libs > behaviour (just like wsgiref in Python). Same exist with Rack in ruby > world and probably in other language. > > Maybe that something that could be done. It would at least simplify a > lot the work of apps developers. WSGI is one of most successful middle layer implementation I've seen for HTTP. By success, I mean the amount of code written around the spec. For the most part, the entire Python web ecosystem, which is very rich, was spawned by this spec. http://www.python.org/dev/peps/pep-0444/ Some of what's been discussed in this thread (cookies, sessions, etc), IMO, belongs at a higher level -- which is easily supported with a good HTTP middleware layer. FWIW, this exists today in the "mod" API for Erlang's own httpd server. It's not a standard -- it's horrifyingly complicated -- but it is representative of a WSGI style middle ware layer. Garrett From g@REDACTED Sat Feb 18 21:19:44 2012 From: g@REDACTED (Garrett Smith) Date: Sat, 18 Feb 2012 14:19:44 -0600 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> Message-ID: On Sat, Feb 18, 2012 at 1:57 PM, Steve Vinoski wrote: > On Sat, Feb 18, 2012 at 6:18 AM, Benoit Chesneau wrote: >> In python world we have WSGI that define a common spec to interface >> Python application with the web. > > Something like this, EWGI, was built a few years ago, but never seemed > to go anywhere: > > https://github.com/skarab/ewgi The problem with this project IMO is that it isn't a spec -- it's a library. The success of WSGI is that it's a duck typed protocol -- you don't need to download anyone's code to use it. IIRC the prime directive of the WSGI design was to make it easy to build clients, servers, and middleware. It worked out well I think. Garrett From g@REDACTED Sat Feb 18 21:26:08 2012 From: g@REDACTED (Garrett Smith) Date: Sat, 18 Feb 2012 14:26:08 -0600 Subject: [erlang-questions] HTTP clients In-Reply-To: References: Message-ID: On Sat, Feb 18, 2012 at 9:30 AM, Tristan Sloughter wrote: > Now to http clients instead of servers :) > > Over the years I've bounced between httpc, lhttpc and ibrowse (I think > that's all...) and was wondering what opinions people had on the 3 and which > are still developed and used in production. > > It seems ibrowse has the most features and most development going on. > > Though examples are lacking for all of them... So on a side note if anyone > has an example of posting form data with ibrowse that would be much > appreciated. If I just need to grab a file, I'll call out to curl :) It'd be nice to have a solid httpc module in the core. It *seems* that httpc is close, but every now and then you'll spot some odd, hard to reproduce buggy behavior. For me that was a while ago -- it may have seen some improvements lately. Garrett From zabrane3@REDACTED Sat Feb 18 21:33:54 2012 From: zabrane3@REDACTED (Zabrane Mickael) Date: Sat, 18 Feb 2012 21:33:54 +0100 Subject: [erlang-questions] HTTP clients In-Reply-To: References: Message-ID: On Feb 18, 2012, at 9:26 PM, Garrett Smith wrote: > On Sat, Feb 18, 2012 at 9:30 AM, Tristan Sloughter > wrote: >> Now to http clients instead of servers :) >> >> Over the years I've bounced between httpc, lhttpc and ibrowse (I think >> that's all...) and was wondering what opinions people had on the 3 and which >> are still developed and used in production. >> >> It seems ibrowse has the most features and most development going on. >> >> Though examples are lacking for all of them... So on a side note if anyone >> has an example of posting form data with ibrowse that would be much >> appreciated. > > If I just need to grab a file, I'll call out to curl :) May be semonce car start from here to make this linked-in driver stable: http://www.chrisumbel.com/article/c_from_erlang_curl Regards, Zabrane -------------- next part -------------- An HTML attachment was scrubbed... URL: From matti.oinas@REDACTED Sat Feb 18 21:35:23 2012 From: matti.oinas@REDACTED (Matti Oinas) Date: Sat, 18 Feb 2012 22:35:23 +0200 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> <4F3E6EB2.3000505@ninenines.eu> Message-ID: <4F400B8B.7080001@gmail.com> On 02/18/2012 09:55 PM, Steve Vinoski wrote: > If people want > to contribute they should instead be working either within existing > projects like Yaws, or perhaps better yet, within Erlang/OTP itself, > in both the Erlang code and the C code, to improve scaling and > performance at that level. Speed up the HTTP parsing within Erlang, > for example. Steve has a really good point in that we should concentrate to improve the existing and as few as possible different implementations and if possible the one included in Erlang/OTP. Sometimes something new has to be created to demonstrate the benefits and to make development go faster but these new solutions shouldn't be recreated from the scratch just to alter a minor part of existing solution. Instead improvements should be made into existing code. If the old code isn't fast or good enough then fix it instead of writing a new one. Open source can only help if we are using existing solutions and trying to make them better instead of trying to create a new and better one and leaving existing code unfixed. I have written partially working web server and other common applications/libraries myself but just for learning purposes and when I have come to a conclusion that I have learned what I wanted then I just move the codes to my backup HD and forgot they even exist. No one would benefit anything from these codes because everything have been done before and there exists good solutions to these problems allready. Situation would have been different if I would have created a totally different and good solution to existing problem. Then the code should be published. I'm not saying there should only exist one solution to every problem but there shouldn't exist two or more allmost identical solutions to same problem. First try to contribute to existing solution before creating a new one. Matti From essen@REDACTED Sat Feb 18 22:28:46 2012 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 18 Feb 2012 22:28:46 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> <4F3E6EB2.3000505@ninenines.eu> Message-ID: <4F40180E.3060302@ninenines.eu> On 02/18/2012 08:55 PM, Steve Vinoski wrote: > On Fri, Feb 17, 2012 at 10:13 AM, Lo?c Hoguin wrote: >> On 02/17/2012 04:06 PM, Steve Vinoski wrote: >>> >>> Earlier in this thread we have this gem from Lo?c: >>> >>>> I'm sad to see Misultin go, this was in my opinion the only other project >>>> that had enough >>>> momentum to introduce innovation in Erlang web servers. >> >> >> I'm sorry if you misunderstood this but you also provide the reason why I >> have that opinion. >> >> >>> Yaws exists and continues to exist because people continue to use it >>> in real-life production systems. Klacke, Christopher, and I all have >>> day jobs, so whatever time we put into yaws is based on what users are >>> asking for. >> >> >> Misultin and Cowboy are still at a point in the projects' life where >> features continue being added or improved before users request them, not the >> other way around. They can also afford to break the API a little if a better >> solution exists, since both of them aren't considered stable at this point. >> >> That's all I meant. > > Sorry but a) I don't see how you expect anyone to be able to derive > this interpretation from what you originally said, and b) this still > has nothing to do with innovation. Do you equate innovation with > greenfield development? You have to break APIs just to innovate? If so > that's awfully misguided. > > I suggest studying the work of Clayton Christensen and his Harvard > Business school colleagues, as well as others such as Geoffrey Moore > and Steve Denning if you want to know what innovation actually is. > When it comes to innovation, Scott Berkun, author of "The Myths of > Innovation", once offered this advice: > > http://www.scottberkun.com/blog/2008/stop-saying-innovation-heres-why/ I do use innovation in the disruptive sense, but it seems there is a bigger issue at hand than my poor choice of words. > Fact is, plenty of innovation has occurred in Yaws over the past few > years. When I added process-based streaming, for example, it enabled > long-polling apps and served as a basis for websocket support. It also > allowed me (in my day job at the time) to integrate Yaws with a > proprietary hardware TCP offload engine for video delivery, notably > without any special patches or changes to Yaws itself. Innovative? You > bet. Christopher Faulet added a number of small features over the past > year that are incredibly useful to anyone using Yaws in production. > Even just adding rebar support to Yaws led to several innovative > changes within rebar, making it cleaner in spots. I added support for > the relatively recent HTTP PATCH verb to Yaws even though nobody asked > for it, simply because it's in the spec. We even occasionally slightly > broke interfaces to make improvements. And we intend to continue to > innovate, through Yaws 2.0 and beyond. Please don't take this the wrong way, as once again I mean no harm. I never heard about all the recent changes you mention. I don't follow closely any of the server projects, due to lack of time, yet I heard about all the developments happening in Misultin over the past year from different sources (announcements, IRC, twitter mostly), up to the 0.9 version. For Yaws, I saw a release announcement a couple months ago, and sometimes someone mentions it on IRC (always the same set of people though). Evidently Yaws had websockets for a long time, yet people got excited when I added them to my then 2 months old server as if it was the only server that could do them (alongside Misultin, Websocket support was added back-to-back in both projects IIRC). This is bad because unless people talk about what your project can do then people new to Erlang won't know it. I'm relatively new to Erlang and when I looked for a web server initially I didn't hear about Yaws. I heard about Webmachine (then found out it used Mochiweb internally, I didn't hear much about Mochiweb specifically) and Misultin. I did take a look at Yaws eventually, but I didn't hear much about it. There's an increase in newcomers to Erlang, and if these newcomers don't hear more often about what Yaws (or any other established project) can do and where it's going, they won't consider it. Call it buzz or hype or what you want, but that kind of communication is important if you want to grab newcomers. All the veterans use Yaws, yet none of the newcomers, or at least none of the ones I talk to, know about it. Something there is wrong and should be fixed. I hope I explained myself clearly this time and that it won't anger you. If it does though I'll leave it as that. ;) > As I said at Erlang Factory London 2011 and in my keynote at the > Erlang Workshop in Tokyo last September, my personal opinion is that > nobody should be writing new Erlang web servers. Every new > "lightweight" "library" web server eventually just gains weight to the > point where still another new project pops up to build something more > lightweight again. If you think something like this won't eventually > follow Cowboy, you're dreaming. But all these new web servers just > splinter the Erlang web development community IMO, and they result in > multiple efforts all having to implement the same support for the same > features, all in different non-reusable ways of course. If people want > to contribute they should instead be working either within existing > projects like Yaws, or perhaps better yet, within Erlang/OTP itself, > in both the Erlang code and the C code, to improve scaling and > performance at that level. Speed up the HTTP parsing within Erlang, > for example. Consider what the OTP team continues to do with multicore > performance, or what Scott Fritchie is doing with dtrace integration. > Doing stuff like that raises all ships -- all Erlang applications, > whether web-focused or not, benefit from such efforts. I for one hope that more servers appear and try out entirely new things. I'm saddened to see Misultin go, and would feel the same if Mochiweb or Yaws development stopped, because I think there is a bigger benefit in having many projects instead of one. Each project has different goals and this leads to quite different designs, that other projects can learn from. I'm hopeful that one day someone will start yet another webserver, even if just as an experiment, that can showcase a new way of improving the existing software stacks. And I'll add that if the improvements are big enough I'll gladly pull out a new Cowboy version to add them to my project, even if it breaks some compatibility, as long as it's in the project's scope and furthers its goals. When Cowboy initially appeared a lot of exchange happened between Roberto and myself about ways to improve both projects, and that's something I feel is very important. What's more important though is that even if one project thinks one way of doing things is wrong, the other can still do it. And maybe it was a good idea and it should stay, but needed to be proven over time. I'm not sure how you can get this to happen if you have a single project for the whole community. You can fork, sure, but if changes are disruptive enough you just end up with two projects again. -- Lo?c Hoguin Erlang Cowboy Nine Nines From alexxz@REDACTED Sat Feb 18 22:34:42 2012 From: alexxz@REDACTED (Alexey Eremikihin) Date: Sun, 19 Feb 2012 01:34:42 +0400 Subject: [erlang-questions] Question about using ETS, PUT/GET In-Reply-To: <5A98F765-BBBF-4FC7-9AEA-0FC6A5236414@gmail.com> References: <1329340591686-4392011.post@n4.nabble.com> <5A98F765-BBBF-4FC7-9AEA-0FC6A5236414@gmail.com> Message-ID: <4F401972.5060800@mail.ru> Small hint Ejabberd starts new instance of module for each domain specified in config. So modules are domain specific. You need to decide do you need one table for all domains, or each domain has its own table. 16.02.2012 01:22, Dmitry Kolesnikov ?????: > Hello, > >> The issue is I cannot start ejabberd, according to the log, when the second >> time this module starts, ejabberd tells there is an argument error. > > this is due to your named ets table. When you stat this module second time the table_name is exists and ets throws an error. You have to re-shake you app in the way that only one copy of ets is created. > > - Dmitry > > On Feb 15, 2012, at 11:16 PM, flowerstars wrote: > >> Hi everyone, >> >> I am working on developing modules on ejabberd. I tried to use ETS in >> start/2. The codes are following: >> >> ets:new(table_name, [named_table, public, bag]), >> ets:insert(table_name, {num, 999}), >> >> I use "ets:lookup(table_name, num)," in another function within the same >> file to read the value "999". >> >> The issue is I cannot start ejabberd, according to the log, when the second >> time this module starts, ejabberd tells there is an argument error. >> >> Actually, I just want to share some variables. I used to use PUT/2 and >> GET/1, I use "put(key, Value)" in start/2, and use "get(key)" in another >> function within one file. However, what I got is "undefined". Are they in >> the same process? >> >> Any help is appreciated!! >> >> Thanks a lot! >> >> >> -- >> View this message in context: http://erlang.2086793.n4.nabble.com/Question-about-using-ETS-PUT-GET-tp4392011p4392011.html >> Sent from the Erlang Questions mailing list archive at Nabble.com. >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From vinoski@REDACTED Sat Feb 18 23:05:44 2012 From: vinoski@REDACTED (Steve Vinoski) Date: Sat, 18 Feb 2012 17:05:44 -0500 Subject: [erlang-questions] Misultin EOL In-Reply-To: <4F40180E.3060302@ninenines.eu> References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> <4F3E6EB2.3000505@ninenines.eu> <4F40180E.3060302@ninenines.eu> Message-ID: On Sat, Feb 18, 2012 at 4:28 PM, Lo?c Hoguin wrote: > This is bad because unless people talk about what your project can do then > people new to Erlang won't know it. I'm relatively new to Erlang and when I > looked for a web server initially I didn't hear about Yaws. I just googled: erlang web server and the Yaws home page is the very first link that popped up. --steve From tristan.sloughter@REDACTED Sat Feb 18 23:14:06 2012 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Sat, 18 Feb 2012 16:14:06 -0600 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> <4F3E6EB2.3000505@ninenines.eu> <4F40180E.3060302@ninenines.eu> Message-ID: I was going to stay out of this but I must say that when I got started with Erlang webservers the way I understood it was mochiweb for using within your applications and yaws to serve static content. Whether or not that is/was accurate it seems to be what most heard. Then I looked deeper at Yaws documentation and while it was clear it was able to do more, the documentation made it seem awkward compared to what I'd see from others. When I look to use webmachine, mochiweb, cowboy, misultin it seems clear using them in standard OTP apps and releases. Yaws, not so much. Tristan On Sat, Feb 18, 2012 at 4:05 PM, Steve Vinoski wrote: > On Sat, Feb 18, 2012 at 4:28 PM, Lo?c Hoguin wrote: > > This is bad because unless people talk about what your project can do > then > > people new to Erlang won't know it. I'm relatively new to Erlang and > when I > > looked for a web server initially I didn't hear about Yaws. > > I just googled: > > erlang web server > > and the Yaws home page is the very first link that popped up. > > --steve > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Sat Feb 18 23:19:56 2012 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Sat, 18 Feb 2012 23:19:56 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> <4F3E6EB2.3000505@ninenines.eu> <4F40180E.3060302@ninenines.eu> Message-ID: <4F40240C.2050003@ninenines.eu> On 02/18/2012 11:05 PM, Steve Vinoski wrote: > On Sat, Feb 18, 2012 at 4:28 PM, Lo?c Hoguin wrote: >> This is bad because unless people talk about what your project can do then >> people new to Erlang won't know it. I'm relatively new to Erlang and when I >> looked for a web server initially I didn't hear about Yaws. > > I just googled: > > erlang web server > > and the Yaws home page is the very first link that popped up. That's not what people do when they want to know what they should use. They ask others about it. Google is good to find something specific, not to get an opinion. -- Lo?c Hoguin Erlang Cowboy Nine Nines From watson.timothy@REDACTED Sun Feb 19 00:42:20 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Sat, 18 Feb 2012 23:42:20 +0000 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D991E.5000205@ninenines.eu> <4915914f-b378-43ab-9fcc-742980c2ee43@bs8g2000vbb.googlegroups.com> Message-ID: On 18 February 2012 14:32, Joe Armstrong wrote: > > I quite agree - this code was just a proof-of-concept not > frozen in stone. > Sure, I understood that. > As I see things there are two layers: > > *inside* EHE I'd write code like this: > > ? > > SYS:get_key(Val) would have a well defined type that never changes. > > *outside* EHE I would define the semantics of get_key > so I could say If I wanted a memory resident db, persistent, > replicated, authenticated and so on. > Makes sense to me. > > >> which include >> >> 1. what libraries I use to serialise/de-serialise data >> 2. what scripting and/or templating libraries I wish to use to >> generate content (if this approach is in play) >> 3. what response codes I want to send to the client >> >> So I fundamentally like where you're going with this, but it's a bit >> too high a level of abstraction for a 'generic web server api' and is >> making too many choices about these things (above). You need to offer >> lower level APIs that bridge the different web servers, as >> simple_bridge does. And on that note, if parameterised modules are >> going to be official and 'ok' soon, then simple_bridge is actually a >> long way ahead already, so maybe it's worth spending some time looking >> at it too. > > I agree > Cool - I think Ulf's point about parameterised modules was a good one. They've been around for ages and should be 'finalised' now. I'm very excited to see where this stuff goes. Cheers, Tim From watson.timothy@REDACTED Sun Feb 19 00:56:11 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Sat, 18 Feb 2012 23:56:11 +0000 Subject: [erlang-questions] HTTP clients In-Reply-To: References: Message-ID: httpc is perfectly fine for most applications - Max had a slightly more demanding use case than is usual for a generic http client and clearly it made sense for him to do something specific in that area. I've used ibrowse in situations where I'm stuck behind a corporate proxy and inets won't upgrade the socket to ssl, making it impossible to access https urls. This was mentioned on the list and I'm pretty sure it's on the 'TODO' list for the otp team to fix. Apart from that, httpc has never let me down and the scenarios where I'm using ibrowse are very lightweight, so I can't comment on its utility very broadly. On 18 February 2012 20:33, Zabrane Mickael wrote: > > On Feb 18, 2012, at 9:26 PM, Garrett Smith wrote: > > On Sat, Feb 18, 2012 at 9:30 AM, Tristan Sloughter > wrote: > > Now to http clients instead of servers :) > > > Over the years I've bounced between httpc, lhttpc and ibrowse (I think > > that's all...) and was wondering what opinions people had on the 3 and which > > are still developed and used in production. > > > It seems ibrowse has the most features and most development going on. > > > Though examples are lacking for all of them... So on a side note if anyone > > has an example of posting form data with ibrowse that would be much > > appreciated. > > > If I just need to grab a file, I'll call out to curl :) > > > May be semonce car start from here to make this linked-in driver stable: > http://www.chrisumbel.com/article/c_from_erlang_curl > > Regards, > Zabrane > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From watson.timothy@REDACTED Sun Feb 19 01:08:53 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Sun, 19 Feb 2012 00:08:53 +0000 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: <40AB269C-A3FF-4FF9-AC2D-52F7BBE0B317@feuerlabs.com> References: <4F3F9A11.5010001@gmail.com> <0D7897B9-4403-40F3-B5A2-B2DCBB5BCF56@feuerlabs.com> <40AB269C-A3FF-4FF9-AC2D-52F7BBE0B317@feuerlabs.com> Message-ID: On 18 February 2012 15:30, Ulf Wiger wrote: > > On 18 Feb 2012, at 16:13, Joe Armstrong wrote: > > I was thinking about this: In theory having a watertight > barrier between logic and presentation seems like > a good idea - but is it? > > > To quote Yogi Berra (or Einstein, or van de Snepscheut): > > "In theory there is no difference between theory and practice. In practice > there is." > > I've found that mixing Erlang into the Web design part drastically reduces > the pickings when you need a professional web designer. The erlang community > to-date hasn't attracted the kind of people who live to design beautiful > HTML pages. > > The cousin of this train of though is the idea to put Node.js on the server. > It makes perfect sense in one way: JavaScript is the one programming > language a Web designer MUST be good at. Unfortunately, Node.js is a very > bad server-side programming environment. > > Still, the question is how much that hurts you. PHP isn't a great language, > but great websites have been built with it, mainly because enough great web > designers make the effort to learn PHP. > > Of course, for a team of Erlang programmers, the fact that they may be poor > web page designers to start with isn't exactly helped by the fact that they > have to build their web pages in a programming language they don't master > well. OTOH, they can be greatly helped by stealing good open source web > designs from the web. Doing so should be easier with an enlive-style > approach. > > Also, if you build a functional prototype, you can get away with a > "developer-ugly" web UI, as long as you can hire a pro to make it beautiful > later on. If you can stick to mainstream web design techniques as closely as > possible, this step will be easier (or less impossible) to take. > > BR, > Ulf W Major +1 on this point. Joe, what is the difference between this:

and this:
plus maybe a bit of config like this: {template, "mypage.html", mymod} with a bit of this: make_this_pretty(Dom, BoundData) -> .... ----- Because that, fundamentally, gets you away from having a web page that a designer will puke over, and still gets you the full power of Erlang where you absolutely need it. Obviously if you generate a hell of a lot of content in the Erlang code, then the designer needs to vet that and make *it* pretty, by which time you might as well use a templating language that supports dynamic includes (e.g., within a for-each loop). This approach is used by a number of frameworks (both client and server side), the first of which I came across was Apache Wicket. Also, I'm not convinced that making things truly gorgeous is outside of what's possible with the Django Templating Langauge which ErlyDTL implements most of. There are some really beautiful sites out there built with it, and it's all the easier for designers because there's very few code constructs for them to 'learn' (or at least need to ask about) and this works well in practise for a lot of people. If anything, I think a Template View works quite nicely as a pattern. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From ngocdaothanh@REDACTED Sun Feb 19 01:12:48 2012 From: ngocdaothanh@REDACTED (Ngoc Dao) Date: Sun, 19 Feb 2012 09:12:48 +0900 Subject: [erlang-questions] Misultin EOL In-Reply-To: <4F40240C.2050003@ninenines.eu> References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> <4F3E6EB2.3000505@ninenines.eu> <4F40180E.3060302@ninenines.eu> <4F40240C.2050003@ninenines.eu> Message-ID: In my opinion Yaws is the best Erlang web server and many new comers came because they saw this: http://www.sics.se/~joe/apachevsyaws.html One thing Yaws needs to improve is embedding. On Sun, Feb 19, 2012 at 7:19 AM, Lo?c Hoguin wrote: > On 02/18/2012 11:05 PM, Steve Vinoski wrote: >> >> On Sat, Feb 18, 2012 at 4:28 PM, Lo?c Hoguin ?wrote: >>> >>> This is bad because unless people talk about what your project can do >>> then >>> people new to Erlang won't know it. I'm relatively new to Erlang and when >>> I >>> looked for a web server initially I didn't hear about Yaws. >> >> >> I just googled: >> >> erlang web server >> >> and the Yaws home page is the very first link that popped up. > > > That's not what people do when they want to know what they should use. They > ask others about it. Google is good to find something specific, not to get > an opinion. > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines From watson.timothy@REDACTED Sun Feb 19 01:14:20 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Sun, 19 Feb 2012 00:14:20 +0000 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: <0FC496B2-F001-4855-BEA6-595944F67BF9@hypernumbers.com> References: <4F3F9A11.5010001@gmail.com> <0D7897B9-4403-40F3-B5A2-B2DCBB5BCF56@feuerlabs.com> <40AB269C-A3FF-4FF9-AC2D-52F7BBE0B317@feuerlabs.com> <0FC496B2-F001-4855-BEA6-595944F67BF9@hypernumbers.com> Message-ID: On 18 February 2012 17:20, Gordon Guthrie wrote: > +1 ditto > > There are still internationalisation issues to resolve but pure Ajax MVC is > so much better than rendering. > It's not quite that simple in practise though is it. We have a large (some would call it 'enterprise' but I hate that word) application that services many client applications in front of a meta-data registry/repository. The primary interface for this is a RESTful web service exposure, although we do offer other interfaces (SOAP and AMQP) and we serve up both JSON and XML. In serving up XML, we have found that numerous clients want a slightly (or sometimes significantly) different representation of the data, so we allow some post processing of the request using XSLT before it is delivered to the client. The clients are almost exclusively web applications using Ajax calls to fetch the data and chewing on it in various ways (depending on what javascript++ nonsense the UI is implemented with). So in that case, we've got your 'pure Ajax MVC' going on - although I'm not convinced I really understand your use of MVC in this case, but then I think it's a generally confusing and misused pattern name anyway - but we also have Template View going on in the server. From watson.timothy@REDACTED Sun Feb 19 01:19:09 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Sun, 19 Feb 2012 00:19:09 +0000 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: References: Message-ID: On 18 February 2012 20:05, Wes James wrote: > On Sat, Feb 18, 2012 at 4:13 AM, Joe Armstrong wrote: >> Thoughts on EHE >> >> I'm playing with a little language for writing web applications. >> It's called EHE. All it is HTML with embedded Erlang > > > > > Isn't this what is in YAWS already? > > http://yaws.hyber.org/dynamic.yaws > It kind of is isn't it, although I must admit I'm a bit confused by the relationship between the erlang code and the surrounding HTML, especially as none of the examples seems to have any html around them. What's the difference between .yaws files and an appmod? The latter 'feels' more natural to me, although clearly I don't really understand how the former works. From watson.timothy@REDACTED Sun Feb 19 01:24:29 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Sun, 19 Feb 2012 00:24:29 +0000 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> <4F3E6EB2.3000505@ninenines.eu> <4F40180E.3060302@ninenines.eu> <4F40240C.2050003@ninenines.eu> Message-ID: On 19 February 2012 00:12, Ngoc Dao wrote: > In my opinion Yaws is the best Erlang web server and many new comers > came because they saw this: > http://www.sics.se/~joe/apachevsyaws.html > > One thing Yaws needs to improve is embedding. > > I'm pretty sure that since the Yaws build has been rebar-ized, it'll not be too hard to figure out how to modify it to be (a) part of a release instead of a stand alone deployable - if this is not already the case as some on this thread seem to have suggested - and (b) possible to make it easier to embed. From watson.timothy@REDACTED Sun Feb 19 01:25:26 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Sun, 19 Feb 2012 00:25:26 +0000 Subject: [erlang-questions] Luerl - Lua in Erlang In-Reply-To: References: <25cd53a2-77ca-4be9-9092-2925380491ee@knuth> Message-ID: On 18 February 2012 19:27, Robert Virding wrote: > Seeing there is a discussion about scripting languages I thought I would add an extra one in the fray. Doing PHP in Erlang would not be impossible but the syntax is a right mess and there are a LOT of libraries to do. > > Robert This is major cool-ness. I am not going to sleep this weekend. :) From dale@REDACTED Sun Feb 19 01:29:33 2012 From: dale@REDACTED (Dale Harvey) Date: Sun, 19 Feb 2012 00:29:33 +0000 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: References: Message-ID: PHP 'died' along time ago with python (django) and Ruby (rails) and more recently Node.js or client side 'MVC' Every one of those moved away from embedding the host language in the templates and used a basic interoperable templating system because embedded php / erlang just generated terrible code erlydtl as I remember was quite nice On 19 February 2012 00:19, Tim Watson wrote: > On 18 February 2012 20:05, Wes James wrote: > > On Sat, Feb 18, 2012 at 4:13 AM, Joe Armstrong wrote: > >> Thoughts on EHE > >> > >> I'm playing with a little language for writing web applications. > >> It's called EHE. All it is HTML with embedded Erlang > > > > > > > > > > Isn't this what is in YAWS already? > > > > http://yaws.hyber.org/dynamic.yaws > > > > It kind of is isn't it, although I must admit I'm a bit confused by > the relationship between the erlang code and the surrounding HTML, > especially as none of the examples seems to have any html around them. > What's the difference between .yaws files and an appmod? The latter > 'feels' more natural to me, although clearly I don't really understand > how the former works. > _______________________________________________ > 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 Feb 19 01:32:06 2012 From: robert.virding@REDACTED (Robert Virding) Date: Sun, 19 Feb 2012 00:32:06 -0000 (GMT) Subject: [erlang-questions] Luerl - Lua in Erlang In-Reply-To: Message-ID: <36ac3634-8861-448f-bea9-8ad175f53984@knuth> Report bugs and missing features. ----- Original Message ----- > On 18 February 2012 19:27, Robert Virding > wrote: > > Seeing there is a discussion about scripting languages I thought I > > would add an extra one in the fray. Doing PHP in Erlang would not > > be impossible but the syntax is a right mess and there are a LOT > > of libraries to do. > > > > Robert > > This is major cool-ness. I am not going to sleep this weekend. :) > From watson.timothy@REDACTED Sun Feb 19 01:45:51 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Sun, 19 Feb 2012 00:45:51 +0000 Subject: [erlang-questions] Luerl - Lua in Erlang In-Reply-To: <36ac3634-8861-448f-bea9-8ad175f53984@knuth> References: <36ac3634-8861-448f-bea9-8ad175f53984@knuth> Message-ID: On 19 February 2012 00:32, Robert Virding wrote: > Report bugs and missing features. > Sure will! Matthew has already mentioned the most important one - calling Erlang modules/functions. My laundry list for the standard libraries would definitely be io + file, followed closely by coroutines, modules and packages. It looks a lot like the stdlib implementations just need to take their proper inputs (and the stack/state), call the relevant Erlang stdlib implementation and return this in the correct format along with St. Is this the right general pattern? Allowing (obviously) for the implementation to try and remain faithful to the documented semantics of Lua's standard library - because if so, it looks like assisting with implementing additional standard library functions should be relatively easy. From comptekki@REDACTED Sun Feb 19 04:20:56 2012 From: comptekki@REDACTED (Wes James) Date: Sat, 18 Feb 2012 20:20:56 -0700 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: References: Message-ID: On Sat, Feb 18, 2012 at 5:19 PM, Tim Watson wrote: > On 18 February 2012 20:05, Wes James wrote: >> On Sat, Feb 18, 2012 at 4:13 AM, Joe Armstrong wrote: >>> Thoughts on EHE >>> >>> I'm playing with a little language for writing web applications. >>> It's called EHE. All it is HTML with embedded Erlang >> >> >> >> >> Isn't this what is in YAWS already? >> >> http://yaws.hyber.org/dynamic.yaws >> > > It kind of is isn't it, although I must admit I'm a bit confused by > the relationship between the erlang code and the surrounding HTML, > especially as none of the examples seems to have any html around them. > What's the difference between .yaws files and an appmod? The latter > 'feels' more natural to me, although clearly I don't really understand > how the former works. How I think of .yaws vs appmods: .yaws files are like .php files. You can have html content with erlang interspersed throughout the html with . appmods are erlang modules where in yaws.conf you can control the url paths that run the appmod web application more details on appmods here -> http://yaws.hyber.org/appmods.yaws -wes From vinoski@REDACTED Sun Feb 19 04:39:18 2012 From: vinoski@REDACTED (Steve Vinoski) Date: Sat, 18 Feb 2012 22:39:18 -0500 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: References: Message-ID: On Sat, Feb 18, 2012 at 10:20 PM, Wes James wrote: > On Sat, Feb 18, 2012 at 5:19 PM, Tim Watson wrote: >> On 18 February 2012 20:05, Wes James wrote: >>> On Sat, Feb 18, 2012 at 4:13 AM, Joe Armstrong wrote: >>>> Thoughts on EHE >>>> >>>> I'm playing with a little language for writing web applications. >>>> It's called EHE. All it is HTML with embedded Erlang >>> >>> >>> >>> >>> Isn't this what is in YAWS already? >>> >>> http://yaws.hyber.org/dynamic.yaws >>> >> >> It kind of is isn't it, although I must admit I'm a bit confused by >> the relationship between the erlang code and the surrounding HTML, >> especially as none of the examples seems to have any html around them. >> What's the difference between .yaws files and an appmod? The latter >> 'feels' more natural to me, although clearly I don't really understand >> how the former works. > > How I think of .yaws vs appmods: > > .yaws files are like .php files. ?You can have html content with > erlang interspersed throughout the html with . > > appmods are erlang modules where in yaws.conf you can control the url > paths that run the appmod web application > > more details on appmods here -> http://yaws.hyber.org/appmods.yaws To paraphrase: .yaws file: sprinkle a little Erlang into your HTML appmod: sprinkle a little HTML/XML/JSON/whatever into your Erlang An appmod is like a servlet, I suppose. It's code that handles requests made to a configured portion of the server URI space (the path can be "/" to handle all requests to that server), and can do pretty much anything it needs to in order to fulfill each request. In my own development work with yaws, I use appmods almost exclusively because they're totally flexible. --steve From ulf@REDACTED Sun Feb 19 08:07:42 2012 From: ulf@REDACTED (Ulf Wiger) Date: Sun, 19 Feb 2012 08:07:42 +0100 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: <4475D48B-4CFB-4961-8753-F9DFF16885EE@feuerlabs.com> References: <4F3F9A11.5010001@gmail.com> <0D7897B9-4403-40F3-B5A2-B2DCBB5BCF56@feuerlabs.com> <4F3FD2C7.2010101@gmail.com> <4475D48B-4CFB-4961-8753-F9DFF16885EE@feuerlabs.com> Message-ID: Tuncer also pointed out that there is Mats Cronqvist's trane: https://github.com/massemanet/trane Which also aims to parse "real-world" HTML. Looks interesting. BR, Ulf W On 18 Feb 2012, at 18:21, Ulf Wiger wrote: > > On 18 Feb 2012, at 17:33, Matti Oinas wrote: > >> Xmerl could be used to parse these templates if only XHTML would be supported. We could also easily validate these templates for correct markup using XML validators. > > > Like I wrote, there is an unreleased version of xmerl_sax_parser with a 'html' mode, which handles most of the usual HTML badness (i.e. non-well-formed XML). > > I would like to suggest that the OTP team release it. It doesn't have to be perfect. When parsing html, there is no such thing as perfect. > > There is also the yaws_html module, which I admit that I've never used. > > BR, > Ulf W -------------- next part -------------- An HTML attachment was scrubbed... URL: From matti.oinas@REDACTED Sun Feb 19 08:37:57 2012 From: matti.oinas@REDACTED (Matti Oinas) Date: Sun, 19 Feb 2012 09:37:57 +0200 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: References: Message-ID: <4F40A6D5.1070703@gmail.com> On 02/19/2012 02:29 AM, Dale Harvey wrote: > PHP 'died' along time ago with python (django) and Ruby (rails) and > more recently Node.js or client side 'MVC' > > Every one of those moved away from embedding the host language in the > templates and used a basic interoperable templating system because > embedded php / erlang just generated terrible code How come django is better than embedding PHP or erlang code into template? Django just adds one language so instead of 2 you must use 3 to get a working template. It still fails to separate logic from the presentation so embedding is a better option because you have one less language to learn and you have all the power of the embedded language. I have used many different template systems and I always end up using plain old embedding when I'm writing software with PHP. Only thing that is better with django than with embedded PHP is that the template code looks a litle bit better in editor. Matti From erlang@REDACTED Sun Feb 19 09:42:28 2012 From: erlang@REDACTED (Joe Armstrong) Date: Sun, 19 Feb 2012 09:42:28 +0100 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: References: <4F3F9A11.5010001@gmail.com> <0D7897B9-4403-40F3-B5A2-B2DCBB5BCF56@feuerlabs.com> <40AB269C-A3FF-4FF9-AC2D-52F7BBE0B317@feuerlabs.com> Message-ID: On Sun, Feb 19, 2012 at 1:08 AM, Tim Watson wrote: > On 18 February 2012 15:30, Ulf Wiger wrote: >> >> On 18 Feb 2012, at 16:13, Joe Armstrong wrote: >> >> I was thinking about this: In theory having a watertight >> barrier between logic and presentation seems like >> a good idea - but is it? >> >> >> To quote Yogi Berra (or Einstein, or van de Snepscheut): >> >> "In theory there is no difference between theory and practice. In practice >> there is." >> >> I've found that mixing Erlang into the Web design part drastically reduces >> the pickings when you need a professional web designer. The erlang community >> to-date hasn't attracted the kind of people who live to design beautiful >> HTML pages. >> >> The cousin of this train of though is the idea to put Node.js on the server. >> It makes perfect sense in one way: JavaScript is the one programming >> language a Web designer MUST be good at. Unfortunately, Node.js is a very >> bad server-side programming environment. >> >> Still, the question is how much that hurts you. PHP isn't a great language, >> but great websites have been built with it, mainly because enough great web >> designers make the effort to learn PHP. >> >> Of course, for a team of Erlang programmers, the fact that they may be poor >> web page designers to start with isn't exactly helped by the fact that they >> have to build their web pages in a programming language they don't master >> well. OTOH, they can be greatly helped by stealing good open source web >> designs from the web. Doing so should be easier with an enlive-style >> approach. >> >> Also, if you build a functional prototype, you can get away with a >> "developer-ugly" web UI, as long as you can hire a pro to make it beautiful >> later on. If you can stick to mainstream web design techniques as closely as >> possible, this step will be easier (or less impossible) to take. >> >> BR, >> Ulf W > > Major +1 on this point. Joe, what is the difference between this: > >
> ? ? >
> > and this: > >
> > plus maybe a bit of config like this: > > {template, "mypage.html", mymod} > > with a bit of this: > > make_this_pretty(Dom, BoundData) -> .... > (( Interesting - I haven't actually tried doing it this way - This seems like how jquery does things only on the server I was wondering about viewing pages as processes and sending them messages. ie
And in Erlang mynicetag ! {content, "

hello

"} But never got round to implementing this )) )) To answer your question the difference is all the code is in one place - I don't have to go and look somewhere else to see the code. Anyway I write all the html and erlang myself I don't live in this world where one guy writes the html and another writes the code and another writes the css and another writes the js and another writes the bla bla bla I'm just making a tool for me - the problem with programming is that solving problems is one thing but solving problems subject to the condition that the solution is beautiful and maintainable is really really difficult. My problem is not making web sites that work it's making them with beautiful code. /Joe > ----- > > Because that, fundamentally, gets you away from having a web page that > a designer will puke over, and still gets you the full power of Erlang > where you absolutely need it. Obviously if you generate a hell of a > lot of content in the Erlang code, then the designer needs to vet that > and make *it* pretty, by which time you might as well use a templating > language that supports dynamic includes (e.g., within a for-each > loop). This approach is used by a number of frameworks (both client > and server side), the first of which I came across was Apache Wicket. > > Also, I'm not convinced that making things truly gorgeous is outside > of what's possible with the Django Templating Langauge which ErlyDTL > implements most of. There are some really beautiful sites out there > built with it, and it's all the easier for designers because there's > very few code constructs for them to 'learn' (or at least need to ask > about) and this works well in practise for a lot of people. If > anything, I think a Template View works quite nicely as a pattern. > >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> From gianfranco.alongi@REDACTED Sun Feb 19 10:45:57 2012 From: gianfranco.alongi@REDACTED (Gianfranco Alongi) Date: Sun, 19 Feb 2012 10:45:57 +0100 Subject: [erlang-questions] wxWidgets and Erlang In-Reply-To: References: Message-ID: AFAIK (having spoken to Kenneth) - WxWidgets will be the graphics libs (bindings) you get and will be maintained. And the GS will be discontinued. On the topic of making GUIs - no idea. Just found this question on StackOverflow, but you surely have as well http://stackoverflow.com/questions/97508/what-libraries-can-i-use-to-build-a-gui-with-erlang /G On Wed, Feb 15, 2012 at 4:13 PM, Yves S. Garret wrote: > Rather, are there any projects out there to make GUIs with Erlang that are > supported? > > > On Wed, Feb 15, 2012 at 8:26 AM, Yves S. Garret > wrote: >> >> Hi all, is this GUI for Erlang interface still going strong or is it dead? > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From adam.rutkowski@REDACTED Sun Feb 19 11:52:59 2012 From: adam.rutkowski@REDACTED (Adam Rutkowski) Date: Sun, 19 Feb 2012 11:52:59 +0100 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: <4F40A6D5.1070703@gmail.com> References: <4F40A6D5.1070703@gmail.com> Message-ID: On Feb 19, 2012, at 8:37 AM, Matti Oinas wrote: > How come django is better than embedding PHP or erlang code into template? Django just adds one language so instead of 2 you must use 3 to get a working template. You can have an UI guy providing templates and he wouldn't be able to erase your hard drive with it. Or even a team of them. They also don't want to know Python/Erlang/PHP/whatever. They will probably learn a dozen of templating markup commands though. I personally like how Jinja handles things. http://jinja.pocoo.org/ -- AR From james@REDACTED Sun Feb 19 12:54:10 2012 From: james@REDACTED (james) Date: Sun, 19 Feb 2012 11:54:10 +0000 Subject: [erlang-questions] The future of Erlang and BEAM In-Reply-To: <4F369145.5080403@gmail.com> References: <4F36442D.1060202@gmail.com> <4F367010.5020200@meetinghouse.net> <4F367483.5000608@gmail.com> <4F367EE8.7020109@meetinghouse.net> <4F369145.5080403@gmail.com> Message-ID: <4F40E2E2.3030106@mansionfamily.plus.com> I think you are missing the point with these libraries. For me the key point with Erlang is the per-process (ie per actor) GC. A Java system will GC across the whole VM and the response jitter that results is sometimes very bad. Running Java so it really does keep processing with simultaneous GC slugs the performance, increasingly so as the core count goes up. Its also hard to see how a JVM can really work well with a NUMA system, while Erlang does at least have a chance at making some optimisations. From mabrek@REDACTED Sun Feb 19 14:53:24 2012 From: mabrek@REDACTED (mabrek) Date: Sun, 19 Feb 2012 16:53:24 +0300 Subject: [erlang-questions] how to debug distribution protocol issues? Message-ID: Hello. I've got erlang process linked to jinterface mailbox. When jinterface mailbox terminates erlang process trace shows getting_unlinked and no 'EXIT' message. It's a simplified version of process leak that I'm trying to debug. dbg:p(Pid, [m, p]) wasn't very helpful, it shows getting_unlinked, but there is no unlink/1 call neither on erlang nor on jinterface side. packet dump gathered via tcpdump may contain something interesting, but I can't find any tools to decode distribution protocol messages from binary to human readable form (wireshark has support only for epmd conversations). What is the best strategy/tools to use when debugging such kind of situations? Regards, Anton Lebedevich. From watson.timothy@REDACTED Sun Feb 19 15:17:19 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Sun, 19 Feb 2012 14:17:19 +0000 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: References: Message-ID: On 19 February 2012 03:39, Steve Vinoski wrote: > To paraphrase: > > .yaws file: sprinkle a little Erlang into your HTML > appmod: sprinkle a little HTML/XML/JSON/whatever into your Erlang > > An appmod is like a servlet, I suppose. It's code that handles > requests made to a configured portion of the server URI space (the > path can be "/" to handle all requests to that server), and can do > pretty much anything it needs to in order to fulfill each request. > > In my own development work with yaws, I use appmods almost exclusively > because they're totally flexible. > > --steve Thanks steve, that was the understand I had come to from looking at what's on the site. What I haven't quite figured out is how the stuff in an out/1 function gets interspersed with the surrounding HTML and what happens when there are multiple out/1 definitions and so on. But frankly, I'm *much* more likely to use appmods anyway, as like you say they're a lot more like a servlet. I think I might go away and wire up some https://github.com/hyperthunk/annotations with so that you can write a handler that takes parts of the request URL and other bits from the Arg record declaratively. I think it will be quite easy to write an appmod that uses this to reroute the request, giving me something that looks a bit like this: -controller({"/accounts/{account_type}", 'POST', include_body}). get_account(AccountType, PostBody, YawsArg) -> .... -controller({"/accounts/{account_type}/{account_number}/", 'GET'}). get_account(AccountType, AccountNum, YawsArg) -> .... Obviously this isn't as cool as a webmachine-a-like running on YAWS, but I *think* I can make it work quite easily and it makes for more convenient mapping of URLs to controller/handler module + function. Next question I have is, how hard would it be to do something like a servlet filter in YAWS? I could do this quite well using annotations - that's how ErlangWeb does it, albeit with macros instead - but is that the best way? It would look something like this (and is quite easy to implement using annotations): -secured({auth_provider, oauth}). -controller({"/accounts/{account_type}/{account_number}/", 'GET'}). get_account(AccountType, AccountNum, YawsArg) -> .... Is there something else in YAWS like appmod that'll do a filter chain, or am I better off using annotations? Cheers, Tim From ward@REDACTED Sun Feb 19 15:46:55 2012 From: ward@REDACTED (Ward Bekker) Date: Sun, 19 Feb 2012 15:46:55 +0100 Subject: [erlang-questions] Mnesia equivalent of SQL NOT IN Message-ID: <20120219144655.dfe0d59d@groupware.tty.nl> Hi, I have two records: -record(foo, {timestamp, name}). -record(bar, {timestamp, name}). And I would like to execute a Mnesia query that mimics the following SQL query SELECT f.* FROM foo f WHERE f.timestamp NOT IN ( SELECT b.timestamp FROM boo b) What would be an efficient Mnesia equivalent? Regards, Ward -------------- next part -------------- An HTML attachment was scrubbed... URL: From tristan.sloughter@REDACTED Sun Feb 19 17:33:59 2012 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Sun, 19 Feb 2012 10:33:59 -0600 Subject: [erlang-questions] iBrowse Cookie Support Message-ID: ibrowse seems to be ignoring the cookie I pass to options. In an email to this list from 2009 someone says it does not support cookie management, but I take that to mean it simply won't handle storing and passing the cookies for you. Instead you must pass {cookie, string()} to send_req in the Options list like: [{cookie,"SESSIONID=XXXXXX"}] But this isn't working, while testing the request with curl and --cookie "SESSIONID=XXXXXX" does. Am I missing something? Thanks, Tristan -------------- next part -------------- An HTML attachment was scrubbed... URL: From watson.timothy@REDACTED Sun Feb 19 20:04:32 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Sun, 19 Feb 2012 19:04:32 +0000 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: References: <4F3F9A11.5010001@gmail.com> <0D7897B9-4403-40F3-B5A2-B2DCBB5BCF56@feuerlabs.com> <40AB269C-A3FF-4FF9-AC2D-52F7BBE0B317@feuerlabs.com> Message-ID: On 19 February 2012 08:42, Joe Armstrong wrote: > (( Interesting - I haven't actually tried doing it this way - > This seems like how jquery does things only on the server > > I was wondering about viewing pages as processes and sending them messages. > > ie ?
> > And in Erlang ? ?mynicetag ! {content, "

hello

"} > > But never got round to implementing this )) > > )) Interesting concept. Either way, I think a separation like that would appeal to many, although I suspect templating is the popular approach nowadays. > > To answer your question the difference is all the code is in one place - I don't > have to go and look somewhere else to see the code. > That isn't always beneficial though is it. Simplicity is best for sure - I'm definitely with Dijkstra on that one - but even the agile maxim "do the simplest thing that can possibly work" has to be balanced with the right factors. For example, you don't put all you code into just one module, because once a module has more than one axis for change then it becomes harder to manage and maintain. The same is true for the UI surely? > Anyway I write all the html and erlang myself I don't live in > this world where one guy writes the html and another writes the code > and another writes the css and another writes the js and another > writes the bla bla bla > And that is quite a rare thing in most medium to large teams and almost completely unheard of in a large enterprise. > I'm just making a tool for me - the problem with programming is that > solving problems is one thing but solving problems subject to the > condition that the solution is beautiful and maintainable is really > really difficult. > But you're not just making a tool for you if you're promoting it as something we should standardise on for all web servers. > My problem is not making web sites that work it's making > them with beautiful code. My problem is that I can make a web page functional, but making it look 'nice' is like black magic to me. :) From watson.timothy@REDACTED Sun Feb 19 20:29:07 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Sun, 19 Feb 2012 19:29:07 +0000 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: References: <4F40A6D5.1070703@gmail.com> Message-ID: On 19 February 2012 10:52, Adam Rutkowski wrote: > > On Feb 19, 2012, at 8:37 AM, Matti Oinas wrote: > >> How come django is better than embedding PHP or erlang code into template? Django just adds one language so instead of 2 you must use 3 to get a working template. > > You can have an UI guy providing templates and he wouldn't be able to erase your hard drive with it. > More to the point, most developers I've come across seem to think that code mixed with markup is an anti-pattern - admittedly these are people who wouldn't touch PHP with a barge pole. I seem to remember reading someone who compared the relationship between this and well designed code with that of professional wrestling to real sport. The tendency is that the 'script-let' approach makes both the code and markup harder to read and comprehend despite their proximity and obvious connection in context, encourages lazy developers to allow business logic to become interspersed with presentation logic, makes it harder to test both (certainly from a unit testing point of view) and generally sucks from a maintenance perspective. I mean for crying out loud, most people who're working on the pure client side of web development with js libraries like backbone/jQuery/etc are trying really hard not to mix up the content and the layout, with backbone going as far as to separate the model/backend, presentation logic (controllers) and rendering (views). As I've said previously, I'm not a huge fan of MVC as a pattern, but the premise upon which it is based is a good one even if the solution is a bit over complex IMO. Doing what's simple isn't always the same as doing what seems obvious, which when I hear 'do the simplest thing that can possibly work' makes me ask 'but is this *really* the simple thing to do?' Dijkstra, who was obsessed by simplicity, also claimed that 'elegance' is not a dispensable luxury but a quality that determines between success and failure. I don't find anything 'elegant' about embedding code inside of web pages, and that's not an aesthetic judgement, but one that comes from working with medium to large, multi-disciplinary teams, where 'sites' might have hundreds or even thousands of different views and considerable logic behind many of them. In an environment like that, especially when the system(s) are business critical and/or customer facing, you fight for your life to keep a strict separation of concerns, or you end up failing because of the inherent complexity and loose your reputation as a team lead as well as your bonus. From watson.timothy@REDACTED Sun Feb 19 20:32:03 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Sun, 19 Feb 2012 19:32:03 +0000 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: References: Message-ID: To clarify... On 19 February 2012 14:17, Tim Watson wrote: > > Obviously this isn't as cool as a webmachine-a-like running on YAWS, > but I *think* I can make it work quite easily and it makes for more > convenient mapping of URLs to controller/handler module + function. > What I meant there is a more convenient mapping than an appmod - obviously it's not as good as the webmachine approach to routing! From thaterlangguy@REDACTED Sun Feb 19 21:07:11 2012 From: thaterlangguy@REDACTED (Ahmed Al-Saadi) Date: Sun, 19 Feb 2012 15:07:11 -0500 Subject: [erlang-questions] Erlang User Groups and Events in Canada? In-Reply-To: References: Message-ID: <11D2F6445CEB48E6ACFBBE834F2AC180@gmail.com> Hi Ingo: The Erlang communities in Canada do not seem very mature at the moment. Here in Montreal, we are still trying to build a community (erlang-montreal.com). I suggest you follow a similar path and build a local community by attracting interest from peers in your community. Cheers, -signed(ahmed). -- Ahmed Al-Saadi Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Wednesday, February 15, 2012 at 9:10 AM, Ingo Jaeckel wrote: > Hi, > > which user groups exist and what Erlang-events (conferences, > workshops, meetings) take place in Canada? Specifically, in southern > Ontario? > > Thanks, > Ingo > _______________________________________________ > 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 matti.oinas@REDACTED Sun Feb 19 21:17:45 2012 From: matti.oinas@REDACTED (Matti Oinas) Date: Sun, 19 Feb 2012 22:17:45 +0200 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: References: <4F40A6D5.1070703@gmail.com> Message-ID: <4F4158E9.8010606@gmail.com> On 02/19/2012 09:29 PM, Tim Watson wrote: > I don't find anything 'elegant' about embedding code inside > of web pages, and that's not an aesthetic judgement, but one that > comes from working with medium to large, multi-disciplinary teams, > where 'sites' might have hundreds or even thousands of different views > and considerable logic behind many of them. In an environment like > that, especially when the system(s) are business critical and/or > customer facing, you fight for your life to keep a strict separation > of concerns, or you end up failing because of the inherent complexity > and loose your reputation as a team lead as well as your bonus. That is true that you want to keep view separated but that is where django and others fail. View still contains code like {% for match in matches %}
{{ match }}
{% endfor %} That is equally ugly with embedded code and it contains logic. Even worse is that it added one extra language but still failed to separate logic from the view. Enlive on the other hand uses plain HTML templates which are transformed with the help of CSS selectors. There is no logic in HTML template, only plain old HTML. Tranformation code defines what elements will be left and what elements contains what information. http://cleancode.se/2011/01/04/getting-started-with-moustache-and-enlive.html Now we have separated the view from logic and it is really simple to change templates. That is a library that I would like to see written in erlang. From watson.timothy@REDACTED Sun Feb 19 22:13:20 2012 From: watson.timothy@REDACTED (Tim Watson) Date: Sun, 19 Feb 2012 21:13:20 +0000 Subject: [erlang-questions] Thoughts on EHE - the PHP killer In-Reply-To: <4F4158E9.8010606@gmail.com> References: <4F40A6D5.1070703@gmail.com> <4F4158E9.8010606@gmail.com> Message-ID: On 19 February 2012 20:17, Matti Oinas wrote: > On 02/19/2012 09:29 PM, Tim Watson wrote: > > That is true that you want to keep view separated but that is where django > and others fail. View still contains code like > > {% ?for ?match ?in ?matches ?%} > ? ?
? ? ? ?{% ?else ?%} > ? ? ? ? ? ?grey > ? ? ? ?{% ?endifchanged ?%} > ? ?">{{ ?match ?}}
> {% ?endfor ?%} > > > That is equally ugly with embedded code and it contains logic. Even worse is > that it added one extra language but still failed to separate logic from the > view. > At least it is *presentation logic* and I could argue this both ways. I agree that code isn't particularly elegant, but at least it is specifically 'about' the rendering. > Enlive on the other hand uses plain HTML templates which are transformed > with the help of CSS selectors. There is no logic in HTML template, only > plain old HTML. Tranformation code defines what elements will be left and > what elements contains what information. > > http://cleancode.se/2011/01/04/getting-started-with-moustache-and-enlive.html > > Now we have separated the view from logic and it is really simple to change > templates. That is a library that I would like to see written in erlang. Yes I agree this is a far cleaner approach, and you will see that it is very similar to what I proposed to Joe in a previous message on this thread, although at the time I hadn't bothered to look at enlive in any detail. Having spent a little time looking at enlive, I think the approach is very neat and that it would be relatively easy to do this in Erlang, although you'll need a 'non-strict' parser such as https://github.com/massemanet/trane and of course the supporting libraries for generating/munging HTML content using a nice API. From jesper.louis.andersen@REDACTED Sun Feb 19 22:15:27 2012 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Sun, 19 Feb 2012 22:15:27 +0100 Subject: [erlang-questions] Mnesia equivalent of SQL NOT IN In-Reply-To: <20120219144655.dfe0d59d@groupware.tty.nl> References: <20120219144655.dfe0d59d@groupware.tty.nl> Message-ID: <4F41666F.7030706@erlang-solutions.com> On 2/19/12 3:46 PM, Ward Bekker wrote: > > Hi, > > I have two records: > > |-record(foo, {timestamp, name}). > -record(bar, {timestamp, name}). > | > > And I would like to execute a Mnesia query that mimics the following > SQL query > > |SELECT f.* FROM foo f WHERE f.timestamp NOT IN ( SELECT b.timestamp FROM boo b) > | > > What would be an efficient Mnesia equivalent? > > It depends on which indexes you have in your fine SQL database :) But writing a QLC (Query List Comprehension) containing a subselect should be possible without too much work. The question is if you get a decent efficiency out of it. Which is where the indexes comes into play. If you need this a lot, then you may need to organize your data in a shape that makes it efficient. The point of mnesia is that it works much like a modern K/V (NoSQL) store in its performance metrics - so you need to think about the shape of data to get it to run fast. -- Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen, DK -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Sun Feb 19 22:20:09 2012 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Sun, 19 Feb 2012 22:20:09 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> <4F3E6EB2.3000505@ninenines.eu> <4F40180E.3060302@ninenines.eu> <4F40240C.2050003@ninenines.eu> Message-ID: <4F416789.4060405@erlang-solutions.com> On 2/19/12 1:12 AM, Ngoc Dao wrote: > In my opinion Yaws is the best Erlang web server and many new comers > came because they saw this: > http://www.sics.se/~joe/apachevsyaws.html > > One thing Yaws needs to improve is embedding. > Speaking from experience: Embedding yaws or cowboy is dead easy. -- Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen, DK From ulf@REDACTED Sun Feb 19 22:42:09 2012 From: ulf@REDACTED (Ulf Wiger) Date: Sun, 19 Feb 2012 22:42:09 +0100 Subject: [erlang-questions] Misultin EOL In-Reply-To: References: <4F3D4656.9010807@ninenines.eu> <4F3D6C09.7050103@gmail.com> <4F3D8C04.6040101@gmail.com> <4F3E6EB2.3000505@ninenines.eu> <4F40180E.3060302@ninenines.eu> <4F40240C.2050003@ninenines.eu> Message-ID: <161C1C81-5D4C-4813-BB62-B27BF5B89991@feuerlabs.com> On 19 Feb 2012, at 01:24, Tim Watson wrote: >> One thing Yaws needs to improve is embedding. >> >> > > I'm pretty sure that since the Yaws build has been rebar-ized, it'll > not be too hard to figure out how to modify it to be (a) part of a > release instead of a stand alone deployable - if this is not already > the case as some on this thread seem to have suggested - and (b) > possible to make it easier to embed. Well, I had my own facepalm moment when I first tried to get embedded yaws working in a rebar-generated release, using what was pretty much exactly the json_rpc_example from the yaws docs. The thing I didn't think of was that rebar releases use embedded code loading by default, and I had omitted the 'compiler' app from the release. Because of this, yaws couldn't compile the .yaws files. A small gripe with yaws is that it gave me no clues about what was wrong. Anyway, switching to appmods was very easy, and now, both methods work, as I have the compiler app loaded. BR, Ulf W -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthonym@REDACTED Mon Feb 20 00:21:41 2012 From: anthonym@REDACTED (Anthony Molinaro) Date: Sun, 19 Feb 2012 15:21:41 -0800 Subject: [erlang-questions] iBrowse Cookie Support In-Reply-To: References: Message-ID: <20120219232141.GA5543@alumni.caltech.edu> Hmm, I'm not seeing this. If I run % nc -l 8081 in one terminal, then start erl and ibrowse % erl 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> application:start(ibrowse). 2> ibrowse:send_req ("http://localhost:8081/",[{cookie,"SESSIONID=XXXXXX"}],get). I see the following in the first terminal GET / HTTP/1.1 Cookie: SESSIONID=XXXXXX Host: localhost:8081 Content-Length: 0 Are you attempting to pass [{cookie, "SESSIONID=XXXXXX"}] as the 5th argument in ibrowse:send_req/5? Because those options are ibrowse options, not http headers. The headers are the second argument of either form. HTH, -Anthony PS. this was ibrowse 3.0.2 BTW On Sun, Feb 19, 2012 at 10:33:59AM -0600, Tristan Sloughter wrote: > ibrowse seems to be ignoring the cookie I pass to options. In an email to > this list from 2009 someone says it does not support cookie management, but > I take that to mean it simply won't handle storing and passing the cookies > for you. Instead you must pass {cookie, string()} to send_req in the > Options list like: > > [{cookie,"SESSIONID=XXXXXX"}] > > But this isn't working, while testing the request with curl and --cookie > "SESSIONID=XXXXXX" does. > > Am I missing something? > > Thanks, > Tristan > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- ------------------------------------------------------------------------ Anthony Molinaro From yoursurrogategod@REDACTED Mon Feb 20 00:24:01 2012 From: yoursurrogategod@REDACTED (Yves S. Garret) Date: Sun, 19 Feb 2012 18:24:01 -0500 Subject: [erlang-questions] wxWidgets and Erlang In-Reply-To: References: Message-ID: I have found that thread. I didn't really like the option presented to me (sockets). I was hoping for at least a more elegant way of handling this problem. For the record, yes, sockets would skin the cat, but I prefer a scalpel to a battle-axe. On Sun, Feb 19, 2012 at 4:45 AM, Gianfranco Alongi < gianfranco.alongi@REDACTED> wrote: > AFAIK (having spoken to Kenneth) - WxWidgets will be the graphics libs > (bindings) you get and will be maintained. > And the GS will be discontinued. > > On the topic of making GUIs - no idea. > > Just found this question on StackOverflow, but you surely have as well > > http://stackoverflow.com/questions/97508/what-libraries-can-i-use-to-build-a-gui-with-erlang > > /G > > On Wed, Feb 15, 2012 at 4:13 PM, Yves S. Garret > wrote: > > Rather, are there any projects out there to make GUIs with Erlang that > are > > supported? > > > > > > On Wed, Feb 15, 2012 at 8:26 AM, Yves S. Garret < > yoursurrogategod@REDACTED> > > wrote: > >> > >> Hi all, is this GUI for Erlang interface still going strong or is it > dead? > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tristan.sloughter@REDACTED Mon Feb 20 01:34:12 2012 From: tristan.sloughter@REDACTED (Tristan Sloughter) Date: Sun, 19 Feb 2012 18:34:12 -0600 Subject: [erlang-questions] iBrowse Cookie Support In-Reply-To: <20120219232141.GA5543@alumni.caltech.edu> References: <20120219232141.GA5543@alumni.caltech.edu> Message-ID: Thanks Anthony! Yup, that was my bad, I put it in the 5th argument. On Sun, Feb 19, 2012 at 5:21 PM, Anthony Molinaro < anthonym@REDACTED> wrote: > Hmm, I'm not seeing this. If I run > > % nc -l 8081 > > in one terminal, then start erl and ibrowse > > % erl > 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> application:start(ibrowse). > 2> ibrowse:send_req ("http://localhost:8081/ > ",[{cookie,"SESSIONID=XXXXXX"}],get). > > I see the following in the first terminal > > GET / HTTP/1.1 > Cookie: SESSIONID=XXXXXX > Host: localhost:8081 > Content-Length: 0 > > Are you attempting to pass [{cookie, "SESSIONID=XXXXXX"}] as the 5th > argument > in ibrowse:send_req/5? Because those options are ibrowse options, not http > headers. The headers are the second argument of either form. > > HTH, > > -Anthony > > PS. this was ibrowse 3.0.2 BTW > > On Sun, Feb 19, 2012 at 10:33:59AM -0600, Tristan Sloughter wrote: > > ibrowse seems to be ignoring the cookie I pass to options. In an email to > > this list from 2009 someone says it does not support cookie management, > but > > I take that to mean it simply won't handle storing and passing the > cookies > > for you. Instead you must pass {cookie, string()} to send_req in the > > Options list like: > > > > [{cookie,"SESSIONID=XXXXXX"}] > > > > But this isn't working, while testing the request with curl and --cookie > > "SESSIONID=XXXXXX" does. > > > > Am I missing something? > > > > Thanks, > > Tristan > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > -- > ------------------------------------------------------------------------ > Anthony Molinaro > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Mon Feb 20 02:19:40 2012 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 20 Feb 2012 14:19:40 +1300 Subject: [erlang-questions] ANNOUNCE: adapter_pattern for mochiweb/cowboy/misult and scripting language In-Reply-To: References: Message-ID: <038959E6-30D7-46E0-A768-125652E7723B@cs.otago.ac.nz> Joe Armstrong is, in my pantheon, an OED sense 1 hero http://www.oed.com/view/Entry/86297?rskey=8Hch8X&result=1#eid However, there are times when I strongly disagree with him, and on this occasion at least, it's _because_ he's a sense 1 hero and I'm *not*. On 18/02/2012, at 3:31 AM, Joe Armstrong wrote: > I also threw in a web scripting language called EHE. EHE is "Html with > embedded Erlang" > > So has characters FUNDAMENTAL LAW NUMBER ONE. I make mistakes. Lots of mistakes. Lots of stupid little mistakes. Not so many type errors, but more than enough typing errors. I need help. FUNDAMENTAL LAW NUMBER TWO. Strings don't nest. It didn't have to be that way. Lisp embeds Lispy mini-languages with the greatest of ease, but Lisp is fully bracketed. Algol 60 strings had distinct left and right quotation marks, so they _did_ nest. Just try to find an "Algol 60" compiler that supported them! If you use straight-up-and-down quotation marks like Fortran and Smalltalk '...' or C or Java "...", they just do not nest. HTML uses '...' and "..." in some contexts and and and (in XHTML, ) in others. They don't nest. STRING COROLLARY TO MURPHY'S LAW. What *can* go wrong in a language embedded in HTML syntax *will* go wrong. Often. Embarrassingly. EMPIRICAL LAW NUMBER THREE. None of the HTML or XML editing, checking, or validation tools available to me knows anything about Erlang syntax, at least not when processing HTML or XML, and similarly, none of the Erlang editing, checking, or validation tools available to me knows anything about HTML or XML, at least not when processing Erlang. DIABOLIC COROLLARY. With the embedded approach tool help is least available to me when I need it most. The diabolic corollary does *not* apply to embedding languages with *compatible* lexical/syntactic structures. A few years ago I generated a fair bit of XML using a Scheme toolkit I called SXS (Simple XML in Scheme, pronounced "success", and for me it _was_ a success). However, the XML was written using Schemely syntax. The "native HTML" way to do it would be to write an HTML page using any HTML editor you like, attach hook points to it using 'class' and 'id', use