Hi,
I am not gonna contradict anyone to whom I owe as much as Barry Schwartz,
the "font guy" who gave us our native AMD64 co-expression switch. :-) But
his comment about interfacing does deserve some expansion.
There are major challenges and major goals for us to strive towards in the
area of C calling interfaces.
For me, the portability freak, a major issue is to be able to have the same
.c code that is callable from
Linux or Solaris also be callable from Windows. That is almost true, with
ifdef's, but unproven. More fundamental than that is: how much work is it
to write a new "native" C function that is to be called from Unicon, or how
much work is it to write the interface wrapper function that allows you to
call an existing C library function. As you know, Barry, we have an
existing C calling interface that was developed originally for Icon, but it
requires some learning of Icon/Unicon internals in order to use it, and
existing library functions require wrappers that translate parameters and
return values from Icon format to C and back.
Substantial efforts have been made to go past the Icon C calling interface
for Unicon, and the fact that we are not in nirvana yet reflects on the fact
that we aren't where we want to be, but I will report that there is some
hope. Udaykumar Batchu's M.S. project was not a bad effort at the next-gen
for interface support.
Batchu developed a working prototype for a vastly improved native interface
that we designed. If it is not mainstreamed into Unicon yet it is because
Udaykumar graduated and no volunteer or customer has yet made it happen; a
sort of similar situation occurred with Gaikaiwari's pattern type addition.
In addition to Batchu's fine work, Kostas Oikonomou of this list has done a
substantial work to extend the C calling interface for lists of numeric
values. I can attest from personal knowledge that AT&T has extensive,
successful native library interfaces running in their Unicon programs. As a
followup to his work and in collaboration with him, we are in the process of
improving Unicon's numeric processing capabilities, particularly for vector
and matrix work, including C-native array formats. These are useful also in
the 3D facilities. There is code in Unicon CVS, not turned on by default,
and a preliminary Unicon-level API for it that will likely go away in favor
of providing this feature implicitly as a special case of the list data
type.
My last information blurg about C-calling is about C-calling from the
optimizing compiler's generated code.
I recently had the pleasure of getting a bunch of native C-calling
interfaces running from unicon -C, the optimizing compiler that calls iconc
as its back end. Then I had the pleasure of restoring enough naming
consistency to where the C function wrappers call the same runtime system
functions for conversion and allocation, whether they are run from iconc's
library or from iconx. Making it so the same .so files can be loaded and
called from either is another portability step that makes the optimizing
compiler more useful.
To sum up: we are not uninterested in the native C calling interface, we
welcome contributions and
collaboration on it, and there is at least some hope that the interface will
be significantly improved in the short to medium range future.
Cheers,
Clint
On Fri, Oct 23, 2009 at 12:19 PM, Barry Schwartz <
[email protected]> wrote:
> Existing Icon versions don't interface well with today's many
> libraries and applications, or it might be more popular. Python OTOH
> interfaces happily and already with practically everything -- for
> instance, of interest to a font guy like me, both FontForge and
> FontLab. (I use the former.)
>
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Unicon-group mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/unicon-group
