RPM Community Forums

Mailing List Message of <popt-devel>

Re: RPN calculator with +/- operations

From: Jeff Johnson <n3npq@mac.com>
Date: Mon 14 Jun 2010 - 16:29:05 CEST
Message-id: <B33E2CA9-A06A-4056-915D-D27A7D366DBC@mac.com>

On Jun 13, 2010, at 3:30 PM, Jeff Johnson wrote:
> 
> todo++ still early yet for POPT 2.0
> 

Well after some thought, I believe that a RPN calculator
(nominally dc(1) syntax with changes as needed) will help
eliminate the litter of data typing that POPT has accumulated
over the years.

E.g. POPT has methods/types for all the usual int/short/long/longlong/float/double
data types without any clear abstractions. All that's needed is coercion
when import/exporting option values from an application. These days
an internal int64_t (or uint64_t, signedness with bit operations
is mostly useless and I don't expect much of a usage case for
a RPN calculator in POPT).

The one notable exception is RPM, which uses POPT quite extensively
for parsing not only CLI options, but also config/macro values. RPM usage of POPT
was what caused methods like poptSaveInt() et al to be added. But I
can easily change those interfaces @rpm5.org at will and the need(s)
of RPM have changed over the years so that, say, parsing Berkeley DB
configuration for an rpmdb just isn't important any more (has never
really been used/useful afaik).

For discussion purposes, assume
    1) an RPN calculator implementation for binary arithmetic operations.
    2) the RPN calculator stack is initialized with 2 values (I'll
	call the values "X" and "Y" while describing)
    3) The "X" value is pushed first and is essentially the "option value",
	either --foo=1234 or through the pointer in the 4th field of the table
    4) The "Y" value is pushed second from the integer (and eventually long/ptr)
	from the 5th field of the table.
    5) The RPN "program" (i.e. same as you would type to dc(1)) will come from
	the argDescrip 7th field in the table.

That's enough of a convention for me to re-target RPM calls into POPT and eliminate
most of the type-based methods like poptSaveInt() in POPT.

I'll wire up the RPN binary arithmetic while muddling how strings and bit masks/sets
(more useful for POPT) could/should be added to a RPN calculator abstraction.

The next goal will be to attempt a per-item (not per-table) callback signature.
For the short term, I'll assuma as starting point a no-brainer
	int main(int argc, char ** argv[])
calling signature and extend with POPT/application context arguments as needed.
	
73 de Jeff
Received on Mon Jun 14 16:29:31 2010
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.