[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Interfacing with C - macros and stuff
From: |
Marek Janukowicz |
Subject: |
Re: Interfacing with C - macros and stuff |
Date: |
Sat, 26 Mar 2011 23:43:31 +0100 |
User-agent: |
KMail/1.13.3 (Linux/2.6.37-gentoo-r1; KDE/4.5.2; x86_64; ; ) |
On Saturday 26 of March 2011, Sather User wrote:
> On Mon, 10 Jan 2011, Marek Janukowicz wrote:
> > Hello
> >
> > Specification p. 15.2. reads: "Constants of external C types are
> > interpreted as C constants or macros.".
>
> Marek, if you are still there months later:
Yeah, I'm still here :)
Thank you for this email and the previous one, which shed some light on Sather
background and current situation. TBH the problem that I see is that even
though barely any Sather community exists, we have many forks out there: K-
Sather (which is most likely dead, even for Sather standards :)), Waikato
Sather-1.3beta7 (kindly sent to me by Keith Hopper), your pre-GNU fork (beta)
and GNU Sather (guess what - yeah, beta as well :)). I'd say there is no
stable version out there.
I'm trying to apply Sather to some real-life business problems, so I
concentrated on creation of some basic libraries. Unfortunately this means a
lot of interfacing with C (yuck), which - as I've found out - is not as easy
as I initially thought. Thank you for your elaborate answer on the subject,
but the approach you suggested (from TclTk interface) is the one I have
already taken. However, I'm not happy with it, as it's way too verbose. Keith
took a completely different approach in his 1.3 version, just adding all the
constants literally on Sather side, but I don't really like it because I have
the feeling it's not really portable and would break if things change on C
side (but this is really unlikely). The upside is that it's very clean and
everything is done on Sather side (but then again, it's way much work then
just wrapping C stuff into Sather interface).
I also spotted .config files and "builtin" keywords, which supposedly should
help with stuff like wrapping C constants (I even made a small compiler patch
to be able to specify custom .config files on command line), but AFAIK there
is no documentation about those.
When it comes to compiler etc. one thing I really miss is some support for
namespaces. I'm currently trying to work on that, but it's not that easy for
me to plug into the parser, as it looks like the only remotely sane namespace
separator that won't conflict with existing syntax too much would be "--",
which I don't really like.
You are definitely right on the bugs and other problems you mentioned, but for
me they do not really matter. Given the benchmarks you made I'd say
performance is still ok and if at some point it becomes unacceptable to me
(which I doubt) I can always try to improve it then (or hope someone else
does). Also the bugs only bug me if I'm directly affected and can't find a
workaround. But the thing I really miss are libraries, because without them
I'm unable to write any real apps. Oh, and namespaces, because they would
really help making API of libraries nicer (as I may live with clunky internals
- interface to C, but not with clunky externals - API).
--
Marek Janukowicz