in one eye, without apparent cause. Blurry vision in one is a
"normal" aftereffect, in my case, of a so-called and badly named
"cluster" headache -- what I call an "eye attack." A cluster headache
usually wakes a person from sleep, in a memorable way, because they
can hurt like hell. But I don't remember that happening.
The last time I had mysterious blurry vision in one eye, it turned out
that I _had_ been awakened by an eye attack, because Kristy told me
so. Yet I didn't remember.
I conclude, thus, that these attacks are mild and brief, so I fall
back asleep despite them -- probably the doing of the nortriptyline
capsules.
So I'm sitting here typing while looking through just my right eye,
because I have the left eye closed because now it is not just blurry
but also photophobic. Which also explains the wearing of shades
indoors; it's not because I'm mysterious.
For pretentious quasi-artistry I will now change topic bizarrely.
I have been thinking lately of how to make it easier to use C
libraries directly from programs written in Unicon. You want to use
the Unicon runtime's DLL interface; that facility makes it almost
trivial to link with a shared library, and shared libraries are easy
to create in the OSes I use. Between Unicon and the C library you
just need a wrapper function that converts between Unicon types and C
types. C integers of all sizes can be stored in Unicon integers, and
so can all types of C pointers; that works because Unicon integers are
long int and so even on 64-bit AMD64 (which I use) a Unicon integer is
big enough to store a pointer.
Unicon runtime includes easy routines for converting between Unicon
strings and C strings, so that requires no special work. The
more difficult part is how to deal with composite structures like
arrays and structs.
Some desirable constraints:
* C should be able to hide the members of a struct, by not naming
them in header files. This is done in some common libraries.
This means that such C structs appear to Unicon as nought but
pointers, which we represent in Unicon as integers.
* The representation of C structs (and arrays) in Unicon should be
uniform.
This means that even structs with visible members should be
represented as C pointers stored in Unicon integers.
The second constraint did not occur to me until last evening, and in
my early experiments I did not apply it. I had opaque structs
represented as Unicon integers and structs with visible members
represented as Unicon classes.
The constraints lead to (at least) the following implementation:
* C structs are represented in Unicon as integers whose values are
addresses of C structs. (This takes care of structs nested within
structs, too.)
* Allocation of struct space must be done in C code. (I have not
yet investigate Whether the runtime's garbage collector can be
used. In some cases the C code uses malloc() and so in those
cases you would need to call free().)
* Members of a struct should be accessed via C functions. How to
link with those C functions is a design decision with lots of
alternatives. One possibility is a "member access" Unicon class
for each C struct type. A bunch of plain old Icon procedures also
would work. In any case, the structure of a struct is platform
dependent, and so should be calculated ahead of time by a program
that can analyze C struct definitions.
