Barry SCHWARTZ (Barijo ŜVARC) (chemoelectric) wrote,
Barry SCHWARTZ (Barijo ŜVARC)
chemoelectric

eye attacks

Today was at least the third day in which I woke up with blurry vision
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.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments