[erlang-questions] suggestion: shorthand functions

Loïc Hoguin essen@REDACTED
Tue Jan 15 16:54:21 CET 2013 

No examples there.

Also confusing, Solaris?

   Redirect Erlang input and output streams on Solaris®

But mostly because the page you linked has nothing related to how 
Garrett uses it.

On 01/15/2013 04:49 PM, Bengt Kleberg wrote:
> Greetings,
>
> Please start here:
> http://www.erlang.org/doc/man/run_erl.html
>
>
> bengt
>
> On Tue, 2013-01-15 at 16:43 +0100, Loïc Hoguin wrote:
>> Can you give an example of such a run_erl use? I have no idea how the
>> tool works.
>>
>> On 01/15/2013 03:24 PM, Garrett Smith wrote:
>>> Hi Mahesh,
>>>
>>> Sounds like Yuri's driver is distributed Erlang.
>>>
>>> There are a bunch of apps out there that implement their command line
>>> interfaces (CLI) as distributed Erlang nodes that spin up, interact
>>> with another local node, then shut down. RabbitMQ does this.
>>>
>>> I *hate* it! (anger issues)
>>>
>>> - It's slow -- slower than *Java* for CLI operations
>>>
>>> - It's brittle -- distributed Erlang can fail for a number of reasons
>>> that are hard to diagnose
>>>
>>> - It introduces a third OS process -- epmd, a little
>>> single-point-of-failure devil that is the devil
>>>
>>> I personally advocate run_erl, which exposes a shell to to_erl over
>>> pipes. It's trivial to send commands to an Erlang process from bash or
>>> Python or anything you like.
>>>
>>> Some have criticized this approach as also being brittle. All I can
>>> say is that I've used this for years across thousands of servers and
>>> I'm very happy with it.
>>>
>>> That said, I often spend my Sunday mornings over coffee wondering how
>>> OS signal support isn't supported in Erlang.
>>>
>>> Garrett
>>>
>>> On Tue, Jan 15, 2013 at 7:46 AM, Mahesh Paolini-Subramanya
>>> <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
>>>
>>
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>


-- 
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu

More information about the erlang-questions mailing list