On Jun 7, 2010, at 12:51 PM, Wayne Davison wrote:

> On Mon, Jun 7, 2010 at 9:40 AM, Jeff Johnson <n3...@mac.com> wrote:
> The added tyrrany of forcing every application that currently has
>       -lpopt
> to change to
>       -ljdod
> will be rate-determining to adoption (and glacially/tectonically slow imho)
> 
> For me, if popt 2 is not compatible with popt 1 then I would rather have to 
> make a conscious choice to upgrade my code (testing it for compatibility), 
> and having to change the libray name as a part of that is pretty minor.  
> Having a possibility for my program to be run-time linked with a library that 
> is not compatible with what it expects would be very bad, imo.
> 

Last I checked you already had made your choice and included your own
private version of -lpopt (and the reasons are perfectly understood and have
nothing to do with POPT 2.0).

Your decision paths are all status quo ante no matter what is done (or not) in 
POPT 2.0.

And I point out that your decision paths are all independent of whether POPT 
2.0 is
"compatible" or "renamed" or ... anything else.

Yes, your comments are valued, you send patches ;-)


Meanwhile the discussion on <popt-devel@rpm5.org> is intended to
explictly extract what problems/features need to be solved in POPT 2.0
before doing any coding.

(aside)
I almost added a RPN calculator to popt-1.16 this weekend past.
The implementation would have involved a table entry like

    int counter = 0;

  { "autoincrement", '\0', POPT_ARG_INT|POPT_ARGFLAG_RPN,       &counter, 0,
        N_("Demonstrate autoincrmenting using a RPN calculator"), "1 +"  },

where a simple uint64_t stack would push the existing value (with coercion), 
parse simple
digit strings onto the uint64_t stack, with the usual toy calculator arithmetic
operations of + - * / % & | ... , and then transferring the result (again with 
coercion)
back to the counter variable.

The exercise of in-fix -> reverse polish is left to inquiring minds. Hint: see 
wikipedia.

Alas I got (and am) side-tracked with RSA/DSA/Elgamal/ECDSA generate & sign 
methods
for RPM, so I did not get around to the RPN calculator and your "autoincrement" 
request.


73 de Jeff

Reply via email to