[ANN] optparse 1.3 released

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[ANN] optparse 1.3 released

Gary V. Vaughan
Automatically generate a custom command-line option parser from just the
long-form help text for your program.

I am happy to announce release 1.3 of optparse.

Optparse's home page is at https://github.com/gvvaughan/optparse, with
documentation at https://gvvaughan.github.io/optparse.

This was the option parser I originally wrote for Specl, and later
donated to lua-stdlib. Even though I’ve not yet completed the slimming
down of lua-stdlib in preparation for the next release, you can continue
to use optparse without requiring the installation of all of stdlib.  In
contrast with v1.2, this release is built atop the `std.normalize` library.

This release also fixes another long standing bug.

Install it with LuaRocks, using:

     luarocks install optparse 1.3


## Noteworthy changes in release 1.3 (2017-12-17) [stable]
 

### Bug fixes
 

   - don't hang when help text has a bare '-' as the first
non-whitespace character on the line.

 

### Incompatible changes
 

   - the implementation now depends upon and requires the luarocks
modules `std.normalize` and `std._debug`.

 


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] optparse 1.3 released

steve donovan
On Mon, Dec 18, 2017 at 5:51 AM, Gary V. Vaughan <[hidden email]> wrote:
> Automatically generate a custom command-line option parser from just the
> long-form help text for your program.

I've always been a fan of this approach, starting with the help text
that you have to write anyway. I did a Rust crate lapp (after the
Penlight module) that follows this philosophy, mostly because I didn't
feel like an extra 400Kb in my exes for the more fashionable
solutions. (It is possible that I still have late 20-Century attitudes
to executable size)

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] optparse 1.3 released

Jonathan Goble
On Wed, Dec 20, 2017 at 2:28 AM steve donovan <[hidden email]> wrote:
(It is possible that I still have late 20-Century attitudes
to executable size)

That's OK; I would say that Lua itself has late 20th-century attitudes toward executable size. And that's not necessarily a bad thing.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] optparse 1.3 released

Tim Hill
In reply to this post by steve donovan


> On Dec 19, 2017, at 11:27 PM, steve donovan <[hidden email]> wrote:
>
> (It is possible that I still have late 20-Century attitudes
> to executable size)
>

Me also. I’m partly amused and partly horrified at the size of “Hello world” these days.

—Tim


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] optparse 1.3 released

Tobias Kieslich
In reply to this post by Jonathan Goble

Quoting Jonathan Goble <[hidden email]>:

> On Wed, Dec 20, 2017 at 2:28 AM steve donovan <[hidden email]>
> wrote:
>
>> (It is possible that I still have late 20-Century attitudes
>> to executable size)
>>
>
> That's OK; I would say that Lua itself has late 20th-century attitudes
> toward executable size. And that's not necessarily a bad thing.

I guess you could call it late 20th-century attitude towards executable
size ... or you could call it "ready for IOT" where size and efficiency
will actually matter again.

-tobias


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] optparse 1.3 released

steve donovan
On Thu, Dec 21, 2017 at 2:35 AM,  <[hidden email]> wrote:
> I guess you could call it late 20th-century attitude towards executable
> size ... or you could call it "ready for IOT" where size and efficiency
> will actually matter again.

Totally this. People pick up bad habits with computers with beefy
processors and gigs of memory, but there are small devices all around
us. The other day a colleague confessed that he was having a hard time
finding 16Kb for a TCP/IP stack in one of our devices.  That's life in
the fully embedded world. However, even little Linux devices can be
challenging - we have some ARM-powered stations underground, and it's
a shame to see how they struggle with the Salt Stack (which is a big
pile of Python). Lua would do the job as effectively and with more
modularity.

(offtopic: it _is_ possible to do lean and mean programs in Rust, but
conventional wisdom makes it hard - it says "It's so easy to add a
dependency with Cargo. This is not C++ anymore". Everything has
consequences, and there is always a price.  I don't think we've got to
that point with Luarocks, which isn't as universal in Lua as Cargo is
in Rust, and crates.io has an order of magnitude more packages than
Luarocks.  It is, in fact, a little _too easy_ to publish packages
with Cargo)

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] optparse 1.3 released

Ką Mykolas
In reply to this post by Tobias Kieslich
Well, leaving IoT crapware alone, Lua is ready for VM per bullet.

On 21 Dec 2017 2:35 am, <[hidden email]> wrote:

Quoting Jonathan Goble <[hidden email]>:

On Wed, Dec 20, 2017 at 2:28 AM steve donovan <[hidden email]>
wrote:

(It is possible that I still have late 20-Century attitudes
to executable size)


That's OK; I would say that Lua itself has late 20th-century attitudes
toward executable size. And that's not necessarily a bad thing.

I guess you could call it late 20th-century attitude towards executable
size ... or you could call it "ready for IOT" where size and efficiency
will actually matter again.

-tobias


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] optparse 1.3 released

Jim Burnes
In reply to this post by steve donovan
Good points all.  If you're getting that small, a direct threaded forth would also seem to be a good fit.  

A security friend of mine invented a Scheme VM called Mosquito to use as a portable hacking environment.  Memory size was targeted at typical buffer overflows.  All you had to do was inject the vm for the target architecture and it was off to the races.

Sent from my iPhone

> On Dec 20, 2017, at 11:44 PM, steve donovan <[hidden email]> wrote:
>
>> On Thu, Dec 21, 2017 at 2:35 AM,  <[hidden email]> wrote:
>> I guess you could call it late 20th-century attitude towards executable
>> size ... or you could call it "ready for IOT" where size and efficiency
>> will actually matter again.
>
> Totally this. People pick up bad habits with computers with beefy
> processors and gigs of memory, but there are small devices all around
> us. The other day a colleague confessed that he was having a hard time
> finding 16Kb for a TCP/IP stack in one of our devices.  That's life in
> the fully embedded world. However, even little Linux devices can be
> challenging - we have some ARM-powered stations underground, and it's
> a shame to see how they struggle with the Salt Stack (which is a big
> pile of Python). Lua would do the job as effectively and with more
> modularity.
>
> (offtopic: it _is_ possible to do lean and mean programs in Rust, but
> conventional wisdom makes it hard - it says "It's so easy to add a
> dependency with Cargo. This is not C++ anymore". Everything has
> consequences, and there is always a price.  I don't think we've got to
> that point with Luarocks, which isn't as universal in Lua as Cargo is
> in Rust, and crates.io has an order of magnitude more packages than
> Luarocks.  It is, in fact, a little _too easy_ to publish packages
> with Cargo)
>