info-sather
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]