<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Garrett:<div><span class="Apple-tab-span" style="white-space:pre"> </span>This gets perilously close to a "how and where one should be doing distributed erlang in the first place" discussion, which is an entire other can of worms :-) </div><div><br></div><div>I quite agree re: spinning up nodes - adding yet another moving part to what is already perilously close to being a hairball makes my eye twitch… (mind you, I suspect this might be different in simpler scenarios, but I'd rather not go down that road in the first place…)</div><div><br></div><div>Cheers</div><div>p.s. The last time I mentioned OS signal support on a Sunday morning, Nicole almost brained me w/ her coffee mug...</div><div><div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div style="margin: 0in 0in 0.0001pt; "><font class="Apple-style-span" color="#1f497d" face="Calibri, sans-serif"><span class="Apple-style-span" style="font-size: 15px; "><b><i><div style="margin: 0px; font-style: normal; font-weight: normal; font-family: Calibri; "><a href="http://www.gravatar.com/avatar/204a87f81a0d9764c1f3364f53e8facf.png"><b><i>Mahesh Paolini-Subramanya</i></b></a></div></i></b></span></font></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">That Tall Bald Indian Guy...</span></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><div style="margin: 0px; font-family: Calibri; color: rgb(1, 108, 226); "><span style="text-decoration: underline; "><a href="https://plus.google.com/u/0/108074935470209044442/posts">Google+</a></span><span style="color: rgb(31, 73, 125); "> | <a href="http://dieswaytoofast.blogspot.com/"><span style="color: rgb(1, 108, 226); ">Blog</span></a></span><span style="text-decoration: underline; "> </span><span style="color: rgb(31, 73, 125); "> | <span style="color: rgb(1, 108, 226); "><a href="https://twitter.com/dieswaytoofast">Twitter</a></span></span><span style="color: rgb(31, 73, 125); "> | </span><a href="http://www.linkedin.com/in/dieswaytoofast">LinkedIn</a></div></span></div></div>
</div>
<br><div><div>On Jan 15, 2013, at 9:24 AM, Garrett Smith <<a href="mailto:g@rre.tt">g@rre.tt</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi Mahesh,<br><br>Sounds like Yuri's driver is distributed Erlang.<br><br>There are a bunch of apps out there that implement their command line<br>interfaces (CLI) as distributed Erlang nodes that spin up, interact<br>with another local node, then shut down. RabbitMQ does this.<br><br>I *hate* it! (anger issues)<br><br>- It's slow -- slower than *Java* for CLI operations<br><br>- It's brittle -- distributed Erlang can fail for a number of reasons<br>that are hard to diagnose<br><br>- It introduces a third OS process -- epmd, a little<br>single-point-of-failure devil that is the devil<br><br>I personally advocate run_erl, which exposes a shell to to_erl over<br>pipes. It's trivial to send commands to an Erlang process from bash or<br>Python or anything you like.<br><br>Some have criticized this approach as also being brittle. All I can<br>say is that I've used this for years across thousands of servers and<br>I'm very happy with it.<br><br>That said, I often spend my Sunday mornings over coffee wondering how<br>OS signal support isn't supported in Erlang.<br><br>Garrett<br><br>On Tue, Jan 15, 2013 at 7:46 AM, Mahesh Paolini-Subramanya<br><<a href="mailto:mahesh@dieswaytoofast.com">mahesh@dieswaytoofast.com</a>> wrote:<br><blockquote type="cite">Ah, you misunderstand.<br>I'm not running around saying Perl Now! Perl Forever!<br>Instead, what we do is separate the problem domains (to the extent possible,<br>of course).<br>There is some set of functionality in the erlang application that needs to<br>be exposed to our business processes - think "add a user", "disable a<br>client", "add billing credits", etc.<br>These are encapsulated and exposed via escript, and then embedded in perl<br>via 'system' / 'qx' / backquotes / whatever.<br>The same applies for activities like "rebalance node", "move user to debug<br>node", etc. :-)<br><br>cheers<br>Mahesh Paolini-Subramanya<br>That Tall Bald Indian Guy...<br>Google+ | Blog | Twitter | LinkedIn<br><br>On Jan 15, 2013, at 5:22 AM, Yurii Rashkovskii <<a href="mailto:yrashk@gmail.com">yrashk@gmail.com</a>> wrote:<br><br>Mahesh,<br><br>This is certainly a good point about bash/perl/python/whatever, but these<br>become quite useless the moment you need to talk to some erlang node from<br>your escript.<br><br>Yurii.<br><br>On Friday, January 11, 2013 7:11:26 AM UTC-8, Mahesh Paolini-Subramanya<br>wrote:<br><blockquote type="cite"><br>I love escripts but find myself intuitively avoiding them for a couple<br>reasons:<br><br>- In most cases, bash is more portable and solves system level<br>problems more directly<br><br>- I don't have the escript foo required to wrench my program it into a<br>single script file<br><br><br>Amen.<br>perl (bash, python, whatever) is optimally suited for orchestrating<br>between 'application space' and 'business space', as well as orchestration<br>across loosely coupled systems and activities.<br>Yes, you could force most of this into erlang-world, but to what point?<br>IMHO, we do live in a polyglot world, and we may as well take advantage of<br>it…<br><br>Cheers<br><br>p.s. Mind you, there is an entirely different argument to be made about<br>systems where you only have access to erlang (or Ada. or whatever :-) )<br><br>Mahesh Paolini-Subramanya<br>That Tall Bald Indian Guy...<br>Google+ | Blog | Twitter | LinkedIn<br><br>On Jan 11, 2013, at 9:55 AM, Garrett Smith <g...@rre.tt> wrote:<br><br>On Fri, Jan 11, 2013 at 8:18 AM, Raimo Niskanen<br><raimo+erlan...@<a href="http://erix.ericsson.se">erix.ericsson.se</a>> wrote:<br><br>On Fri, Jan 11, 2013 at 10:12:40AM +0100, Ulf Wiger wrote:<br><br>Since I've been writing a bunch of rebar.config.script code lately,<br>I've suffered the agony of trying to write concise and readable<br>code without having to do tons of copy-paste, weird unwrapping<br>funs etc.<br><br>What I think would make this sort of thing easier, and also<br>escript programming in general, is if OTP could provide some<br>modules with concise naming and let-it-fail semantics.<br><br>Just off the top of my head, I scribbled down a few functions that<br>I think would make *my* life easier. I pushed them to github to<br>get some discussion going.<br><br><a href="http://github.com/uwiger/shorthand">http://github.com/uwiger/shorthand</a><br><br>The modules are:<br><br>f.erl - shorthand functions for file.erl<br>fn.erl - ditto for filename.erl<br>e.erl - ditto for erl_eval.erl<br><br>The least beneficial is perhaps filename:erl, but my fingers and<br>eyes ache from all the filename:join(filename:dirname(F), …)<br>code.<br><br>Otherwise, I think the biggest benefit is to stick to let-it-crash<br>programming, which I find is usually the default when I write<br>scripts. The original functions are always available if you want<br>to take a closer look at return values.<br><br>(For the file:script() counterparts, I also always pass the name<br>of the script as a binding).<br><br>Comments?<br><br><br>I think it is a nice idea that would improve scripting.<br><br>But how to agree on module names and content is harder. There is a limited<br>number of 1 and 2 character module names, and once in OTP they are written<br>in stone.<br><br><br>Aye. I don't know how critical this use case is (scripting<br>simplification/improvements) to justify new modules in OTP space. And<br>I'm not sure there *is* a case that would be sufficiently ubiquitous.<br><br>I've resigned myself to writing little project specific<br>functions/libraries like this to deal with project specific problems.<br>E.g. this stuff drives me nuts:<br><br>{ok, X} = foo:x(),<br>{ok, Y} = foo:y(),<br>combine(X, Y)<br>...<br><br>So I'll write foo_x/0 and foo_y/0 with crash-on-error semantics to get<br>this:<br><br>combine(foo_x(), foo_y())<br><br>But who knew that I needed those particular variants? And what about<br>changes? It's my project, so I don't mind little wrappers, especially<br>since functions clarify intent.<br><br>E.g. when I see this:<br><br>ProjectFile = filename:join(ProjectDir, ProjectName)<br><br>I'll almost create a function like this:<br><br>project_filename(Dir, Name) -> filename:join(Dir, Name).<br><br>For f.erl I miss e.g is_dir from filelib, which would introduce the notion<br>of merging old module functionality. Using the name 'fl' for filelib<br>functions would just be hard to remember.<br><br>Aliasing filename:basename to fn:base is a bit unintuitive since the<br>original Unix command is called 'basename' and for e.g file:list_dir<br>you have aliased it to f:ls (as for many other) to make them more<br>Unix:ish.<br>I think it would be better to keep to unix command names where possible.<br>[Wild idea: f:'-d' for filelib:is_dir, or t:'-d', or f:test(d, Path).]<br><br><br>It seems one could make these arguments ad nauseam. To me it's just<br>easier (and preferable frankly) to roll my own as the need arises.<br><br>An alternative approach might be to have a helper module named 'es'<br>containing all scripting aliases...<br><br><br>I love escripts but find myself intuitively avoiding them for a couple<br>reasons:<br><br>- In most cases, bash is more portable and solves system level<br>problems more directly<br><br>- I don't have the escript foo required to wrench my program it into a<br>single script file<br><br>Setting bash aside (not Ulf's use case) the main barrier for me is in<br>the perceived complexity of getting a release-of-sorts into an<br>escript. If I could write up one of these wrapper libraries, or pull<br>it down from somewhere easily, I might use escript everywhere. It's<br>not hard to write the wrappers (you write them as you need them, it<br>takes literally less than a minute for each function) and they're<br>tailored to your requirements.<br><br>It may be trivial to package up the required bytes into an escript<br>today. If it is, I've love to know!<br><br>And I don't know how this fits into rebar specific scripting :)<br><br>Garrett<br>_______________________________________________<br>erlang-questions mailing list<br>erlang-q...@erlang.org<br>http://erlang.org/mailman/listinfo/erlang-questions<br><br><br></blockquote><br></blockquote></blockquote></div><br></div></body></html>