[erlang-questions] suggestion: shorthand functions

Tue Jan 15 16:49:30 CET 2013

Greetings,

Please start here:
http://www.erlang.org/doc/man/run_erl.html


bengt

On Tue, 2013-01-15 at 16:43 +0100, Loïc Hoguin wrote:
> Can you give an example of such a run_erl use? I have no idea how the 
> tool works.
> 
> On 01/15/2013 03:24 PM, Garrett Smith wrote:
> > Hi Mahesh,
> >
> > Sounds like Yuri's driver is distributed Erlang.
> >
> > There are a bunch of apps out there that implement their command line
> > interfaces (CLI) as distributed Erlang nodes that spin up, interact
> > with another local node, then shut down. RabbitMQ does this.
> >
> > I *hate* it! (anger issues)
> >
> > - It's slow -- slower than *Java* for CLI operations
> >
> > - It's brittle -- distributed Erlang can fail for a number of reasons
> > that are hard to diagnose
> >
> > - It introduces a third OS process -- epmd, a little
> > single-point-of-failure devil that is the devil
> >
> > I personally advocate run_erl, which exposes a shell to to_erl over
> > pipes. It's trivial to send commands to an Erlang process from bash or
> > Python or anything you like.
> >
> > Some have criticized this approach as also being brittle. All I can
> > say is that I've used this for years across thousands of servers and
> > I'm very happy with it.
> >
> > That said, I often spend my Sunday mornings over coffee wondering how
> > OS signal support isn't supported in Erlang.
> >
> > Garrett
> >
> > On Tue, Jan 15, 2013 at 7:46 AM, Mahesh Paolini-Subramanya
> > <mahesh@REDACTED> wrote:
> >> Ah, you misunderstand.
> >> I'm not running around saying Perl Now! Perl Forever!
> >> Instead, what we do is separate the problem domains (to the extent possible,
> >> of course).
> >> There is some set of functionality in the erlang application that needs to
> >> be exposed to our business processes - think "add a user", "disable a
> >> client", "add billing credits", etc.
> >> These are encapsulated and exposed via escript, and then embedded in perl
> >> via 'system' / 'qx' / backquotes / whatever.
> >> The same applies for activities like "rebalance node", "move user to debug
> >> node", etc. :-)
> >>
> >> cheers
> >> Mahesh Paolini-Subramanya
> >> That Tall Bald Indian Guy...
> >> Google+  | Blog   | Twitter  | LinkedIn
> >>
> >> On Jan 15, 2013, at 5:22 AM, Yurii Rashkovskii <yrashk@REDACTED> wrote:
> >>
> >> Mahesh,
> >>
> >> This is certainly a good point about bash/perl/python/whatever, but these
> >> become quite useless the moment you need to talk to some erlang node from
> >> your escript.
> >>
> >> Yurii.
> >>
> >> On Friday, January 11, 2013 7:11:26 AM UTC-8, Mahesh Paolini-Subramanya
> >> wrote:
> >>>
> >>> I love escripts but find myself intuitively avoiding them for a couple
> >>> reasons:
> >>>
> >>> - In most cases, bash is more portable and solves system level
> >>> problems more directly
> >>>
> >>> - I don't have the escript foo required to wrench my program it into a
> >>> single script file
> >>>
> >>>
> >>> Amen.
> >>> perl (bash, python, whatever) is optimally suited for orchestrating
> >>> between 'application space' and 'business space', as well as orchestration
> >>> across loosely coupled systems and activities.
> >>> Yes, you could force most of this into erlang-world, but to what point?
> >>> IMHO, we do live in a polyglot world, and we may as well take advantage of
> >>> it…
> >>>
> >>> Cheers
> >>>
> >>> p.s. Mind you, there is an entirely different argument to be made about
> >>> systems where you only have access to erlang (or Ada. or whatever :-)  )
> >>>
> >>> Mahesh Paolini-Subramanya
> >>> That Tall Bald Indian Guy...
> >>> Google+  | Blog   | Twitter  | LinkedIn
> >>>
> >>> On Jan 11, 2013, at 9:55 AM, Garrett Smith <g...@REDACTED> wrote:
> >>>
> >>> On Fri, Jan 11, 2013 at 8:18 AM, Raimo Niskanen
> >>> <raimo+erlan...@REDACTED> wrote:
> >>>
> >>> On Fri, Jan 11, 2013 at 10:12:40AM +0100, Ulf Wiger wrote:
> >>>
> >>> Since I've been writing a bunch of rebar.config.script code lately,
> >>> I've suffered the agony of trying to write concise and readable
> >>> code without having to do tons of copy-paste, weird unwrapping
> >>> funs etc.
> >>>
> >>> What I think would make this sort of thing easier, and also
> >>> escript programming in general, is if OTP could provide some
> >>> modules with concise naming and let-it-fail semantics.
> >>>
> >>> Just off the top of my head, I scribbled down a few functions that
> >>> I think would make *my* life easier. I pushed them to github to
> >>> get some discussion going.
> >>>
> >>> http://github.com/uwiger/shorthand
> >>>
> >>> The modules are:
> >>>
> >>> f.erl - shorthand functions for file.erl
> >>> fn.erl - ditto for filename.erl
> >>> e.erl - ditto for erl_eval.erl
> >>>
> >>> The least beneficial is perhaps filename:erl, but my fingers and
> >>> eyes ache from all the filename:join(filename:dirname(F), …)
> >>> code.
> >>>
> >>> Otherwise, I think the biggest benefit is to stick to let-it-crash
> >>> programming, which I find is usually the default when I write
> >>> scripts. The original functions are always available if you want
> >>> to take a closer look at return values.
> >>>
> >>> (For the file:script() counterparts, I also always pass the name
> >>> of the script as a binding).
> >>>
> >>> Comments?
> >>>
> >>>
> >>> I think it is a nice idea that would improve scripting.
> >>>
> >>> But how to agree on module names and content is harder. There is a limited
> >>> number of 1 and 2 character module names, and once in OTP they are written
> >>> in stone.
> >>>
> >>>
> >>> Aye. I don't know how critical this use case is (scripting
> >>> simplification/improvements) to justify new modules in OTP space. And
> >>> I'm not sure there *is* a case that would be sufficiently ubiquitous.
> >>>
> >>> I've resigned myself to writing little project specific
> >>> functions/libraries like this to deal with project specific problems.
> >>> E.g. this stuff drives me nuts:
> >>>
> >>> {ok, X} = foo:x(),
> >>> {ok, Y} = foo:y(),
> >>> combine(X, Y)
> >>> ...
> >>>
> >>> So I'll write foo_x/0 and foo_y/0 with crash-on-error semantics to get
> >>> this:
> >>>
> >>> combine(foo_x(), foo_y())
> >>>
> >>> But who knew that I needed those particular variants? And what about
> >>> changes? It's my project, so I don't mind little wrappers, especially
> >>> since functions clarify intent.
> >>>
> >>> E.g. when I see this:
> >>>
> >>> ProjectFile = filename:join(ProjectDir, ProjectName)
> >>>
> >>> I'll almost create a function like this:
> >>>
> >>> project_filename(Dir, Name) -> filename:join(Dir, Name).
> >>>
> >>> For f.erl I miss e.g is_dir from filelib, which would introduce the notion
> >>> of merging old module functionality. Using the name 'fl' for filelib
> >>> functions would just be hard to remember.
> >>>
> >>> Aliasing filename:basename to fn:base is a bit unintuitive since the
> >>> original Unix command is called 'basename' and for e.g file:list_dir
> >>> you have aliased it to f:ls (as for many other) to make them more
> >>> Unix:ish.
> >>> I think it would be better to keep to unix command names where possible.
> >>> [Wild idea: f:'-d' for filelib:is_dir, or t:'-d', or f:test(d, Path).]
> >>>
> >>>
> >>> It seems one could make these arguments ad nauseam. To me it's just
> >>> easier (and preferable frankly) to roll my own as the need arises.
> >>>
> >>> An alternative approach might be to have a helper module named 'es'
> >>> containing all scripting aliases...
> >>>
> >>>
> >>> I love escripts but find myself intuitively avoiding them for a couple
> >>> reasons:
> >>>
> >>> - In most cases, bash is more portable and solves system level
> >>> problems more directly
> >>>
> >>> - I don't have the escript foo required to wrench my program it into a
> >>> single script file
> >>>
> >>> Setting bash aside (not Ulf's use case) the main barrier for me is in
> >>> the perceived complexity of getting a release-of-sorts into an
> >>> escript. If I could write up one of these wrapper libraries, or pull
> >>> it down from somewhere easily, I might use escript everywhere. It's
> >>> not hard to write the wrappers (you write them as you need them, it
> >>> takes literally less than a minute for each function) and they're
> >>> tailored to your requirements.
> >>>
> >>> It may be trivial to package up the required bytes into an escript
> >>> today. If it is, I've love to know!
> >>>
> >>> And I don't know how this fits into rebar specific scripting :)
> >>>
> >>> Garrett
> >>> _______________________________________________
> >>> erlang-questions mailing list
> >>> erlang-q...@REDACTED
> >>> http://erlang.org/mailman/listinfo/erlang-questions
> >>>
> >>>
> >>
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
> >
> 
>