eichin@athena.mit.edu (Mark W. Eichin) (12/08/90)
As part of my efforts (conspiracy?) to implement all useful programs in
perl (for portability :-) I've begun a perl implementation of the X11
protocol in perl. (XOpenDisplay already works, as does XBell and xrdb
:-) [Yes, I'll post it when the code's less disgusting :-)]
I've run into a few style issues. Please let me know your
opinions on them (go ahead and post, these are (I think) general
enough issues...)
First of all, an X "connection" is a file handle and a bunch
of data (basically, the things the server sent back on the first
call.) I haven't decided upon a good way to "aggregate" this data;
Currently I'm leaving all of the fields as variables in package xlib,
but when I add support for multiple displays, I'll want to do
something cleaner. I've already considered
1) making each variable an array, indexed on "connection
number", i.e. $xlib'width_pixels[$connection_number]
2) making an associative array for each connection, with the
variable names as indicies, i.e. $X_1{'width_pixels'}
3) making a normal array for each connection, with $vars
holding the indicies of the variables, i.e. $X_1[$xlib'width_pixels]
A "struct" language feature might be nice... (like package,
but applicable to variables instead of code? it'll take some thought
and/or flaming to figure out a "nice" way to do this...)
On a related note, is anyone working on the problem of having
makelib (or rather, h2ph) convert 'struct' declarations to "pack"
lines, perhaps even into (something like):
sub utmp { ($line,$name,$host,$time)=unpack("A8 A8 A16
L",$_[0]); }
There's also the issue of the filehandle itself. I can pass
the name of a filehandle into a sub by reference, but I'd like to
store it in an aggregate with the other data (particularly, I'd like
to be able to "return" it with the other data from xopendisplay.)
Filehandles are occasionally tricky to manipulate; I've particularly
noticed that one can't "local(FD);".
An incidental - I discovered on one machine type (IBM PC/RT,
metaware hc2.1y [yes, commercial software with nearly as many released
patchlevels as perl - but all of these were bugfixes, not
functionality...] Perl 3.0 pl 37) the following:
% perl -e 'printf "%x\n",~3;'
7fffffff
it'll be a little while before we have pl41, but I'm surprised there
wasn't a self-test that covered this case (~3 fails in every context
we tried it, it's not the printing routine...)
_Mark_ <eichin@athena.mit.edu>tchrist@convex.COM (Tom Christiansen) (12/08/90)
In article <1990Dec8.003846.15309@uvaarpa.Virginia.EDU> eichin@athena.mit.edu
writes about putting Xlib into perl.
Unbelievable -- only at MIT! But here some have asked for it.
: On a related note, is anyone working on the problem of having
:makelib (or rather, h2ph) convert 'struct' declarations to "pack"
:lines, perhaps even into (something like):
: sub utmp { ($line,$name,$host,$time)=unpack("A8 A8 A16
:L",$_[0]); }
Not exactly, but I do think about it a lot. So does Felix Lee. My
experiences with pstruct (see archives at Ohio State) have led me to
believe that using perl to parse the C to do this is the wrong way.
I just had an idea, maybe even an inspiration: how about that we use the
STABs that 'cc -g' puts out? They're funky, but if you could get them
parsed, it just might work.
: There's also the issue of the filehandle itself. I can pass
:the name of a filehandle into a sub by reference, but I'd like to
:store it in an aggregate with the other data (particularly, I'd like
:to be able to "return" it with the other data from xopendisplay.)
:Filehandles are occasionally tricky to manipulate; I've particularly
:noticed that one can't "local(FD);".
Well, sure you can -- see question 23 in the FAQ, new this month. Saying
"local(*FD)" works just fine. Sadly, you must be very careful here. You
can't get at any subroutines called &FD now, NOR CAN ANY OF YOUR CHILDREN,
by which I mean functions you call. Dynamic scoping, you know.
--tom
--
Tom Christiansen tchrist@convex.com convex!tchrist
"With a kernel dive, all things are possible, but it sure makes it hard
to look at yourself in the mirror the next morning." -me