[ctypes-users] I give up

[norseman <nor...@fi...>]

To whomever;
         The "topics" list seems a bit overly specific. Hope I got the 
correct one.

	I understand (I think) the basic philosophy behind Python. What
I don't understand is the lack of existing ties (hooks, routines, or
whatever one wishes to call them) to common programming practices when
linking to Shared libraries since Python touts its ability to link to
nearly everything. By the way, it almost succeeds. Access to outside
routines is well, routine and seems fool-proof.

	There is one item in particular that I haven't found a solution
for when using Python "out-of-the-box";  Shared Library Globals.

	Before you jump all over me, I need to lay a framework. I was
Hot Patching mainframes in the mid-1960's. Hot Patching constitutes
modifying, in-memory, the running Operating System (or a running
program) without stopping, damaging or crashing it. A Hot Fix is a Hot
Patch to fix a bug while a Hot Mod is Hot Patching to gain a minor to
major change in code and/or flow (logic), each, in core while running.

	Now:
		let   g be a Global Double in a Shared Library
		if    p is the Python pointer to the address of g
                         because Python does not directly handle globals
                         it considers the contents of p as an address to
                         the token instead of the token itself.
		then  &p (address of pointer) is machine address of byte
                         zero of the address itself. That is;  the byte
                         zero of the address of the address of the g
                         as far as Python is concerned

(Python has a decided dislike of &p syntax! maybe it has another?)
	
	And:
		if    u is a union{ double, byte0, byte1,...byte7}
		then  assigning u[0] = &p[0]
                                  .
                                  .
                                 u[7] =&p[7]
                       d = u.double
	              creates a (double)(d)
	Yielding: print d output is == actual value of g
                     (within software/machine limits)
d and p and u are Python tokens
g is a Library token


YES - one has to know what the global is. (type, size, layout, etc.)
This is usually a good reason to maintain documentation.

If Python had the verb, one would simply read the documentation and do
things like:
	(double)(d) = (convert (double)(p-global-name))

struct complex{
                 complx layout
                }
	(complex)(cs) = (convert (complex)(p-global-name))

convert, GetLibGlobal, whatever - I don't care as long as it doesn't
take a dozen lines to type the verb's name.

All we are doing is getting the total byte count of the token and
sequentially copying that many from the library's global space. Can one
say "Loop"?

That is what compilers do, isn't it?  Since there is no compiling some
manual assistance is required. As little as typing the (double)(d)...
line above or copy/paste a struct def from a header and then typing a
line like (complex)(cs)...
(NO - we are NOT going to write into the library! That is NOT allowed!)


Yes..Yes, I've heard pros and cons about Globals. Truth is, in
multi-module programs they are the only considered traffic directors.
Often, initial route does need to be specified. Preferably by whoever
wrote the sharable.  Yes, I'm a bit beyond simple c=sqrt(a^2 + b^2)
functions in my libraries.

To head off some, SWIG 1.3.33 (latest as of this date) DOES NOT work
when used with Python 2.5.1 (latest I have operational). Run the SWIG
tutorial example.c with a  swig -python  and test for yourself. SWIG
1.3.33 works fine on same example for use with tcl. I don't use Perl.

I would like a manual code interface to get a double (or any other
token) from global space in a Shared Library for use in Python. In other
words, in Python what do I type to access Shared Library globals? The
Primitives (aka values). (the nm sl.so output   address D global_name?)
The Python pointer (ShrdLibName.GlobalName) already points to byte zero
of the token, but it will only return the 4 bytes it thinks are the
address to the token.



Any help will be greatly appreciated.

Steve
nor...@fi...