[Openmcl-devel] ? jfli

[james anderson]

On 2009-06-11, at 14:39 , Gary Byers wrote:

> I don't know if anyone's using the jfli port or not, but whether
> they are or not has nothing to do with whether entry point names
> have leading underscores on Darwin.
>
> The old way of looking up the addresses of foreign symbols on Darwin
> (which viewed all external symbols as having leading underscores and
> required its argument to have such a leading underscore) has been
> deprecated (certainly as of Tiger, possibly before - it's been a few
> years) in favor of a new (previously deprecated) way which pretends
> that Darwin symbols don't have leading underscores (at a lower level,
> they still do) and which strips an initial leading underscore from
> its argument.  So:
>
> ? (foreign-symbol-address "read")
> #<A Foreign Pointer #x7FFF81232284>
> ? (foreign-symbol-address "_read")
> #<A Foreign Pointer #x7FFF81232284>

that is not what i see happen.

marbella:/Development/Applications/LISP/ccl-1.3 james$  
system_profiler SPSoftwareDataType
Software:

     System Software Overview:

       System Version: Mac OS X 10.4.11 (8S165)
       Kernel Version: Darwin 8.11.0
       Boot Volume: marbella-backup
       Computer Name: marbella
       User Name: james anderson (james)

marbella:/Development/Applications/LISP/ccl-1.3 james$ ./dppccl
Welcome to Clozure Common Lisp Version 1.3-RC1-r11719M  (DarwinPPC32)!
? (foreign-symbol-address "read")
NIL
?

1.3-r11936 does this as well.

>
> the leading underscore is usually optional, and Apple has cleverly
> designed a symbol-lookup mechanism that makes it awkward to refer
> to foreign symbols that actually have meaningful leading underscores
> in their C-visible names.  (But I digress ...).
>
> You're correct in noting that if the advocated way of resolving
> foreign symbol addresses on Darwin still required its argument
> to have a leading underscore the jfli example (and lots of other
> things, including lots of code in CCL itself) wouldn't work.

i wrote the note, because it didn't.
what would make the "_" not optional?

>   Those
> things generally do (or at least aren't affected by this ...), and
> AFAIK jfli more-or-less does as well.  (The "or less" parts that I'm
> aware of have to do with JNI objects not being freed when they should
> be, and the general plan is to RTFJNIM to get a clearer idea of when
> they should be.)
>
> What's there does seem to work at least well enough to run simple
> demos, including the simple SWT demo that's included (assuming that
> you can find an SWT library for your platform and can adjust the paths
> to it and the JFM that're hardwired into the examples.)  One platform
> for which there was not a released SWT library (unless it's been
> released very recently) is 64-bit OSX: the OSX version of SWT has been
> based on Carbon (and is therefore 32-bit only), though work on a
> Cocoa-based version is ongoing.)

i intend to use it in 64-bit linux.

>
> Nick Levine made some changes to Rich Hickey's original jfli code
> a year or so ago; I wasn't aware of those changes when I did the
> CCL port last winter.  Nick's changes include improvements to
> pathname handling and ways of abstracting away some Windows/Unix
> differences, and it'd be good to merge those changes into the CCL
> port when time permits.

i will keep that in mind. from the list of things mr levine had in  
that blog note about the changes, i will look at them before i try to  
do anything serious with it.