[C2hs] Re: support for 6.4

[Gour]

Duncan Coutts (duncan.coutts at worc.ox.ac.uk) wrote:

> Our considered opinion (Axel and myself) is that c2hs's memory
> consumption is a very difficult thing to fix and any fix we might be
> able to come up with would likely be very invasive and so Manuel would
> not be very keen on the idea.

Pls. excuse me for dumb question (I'm not familiar with c2hs'
internals): is c2hs' memory consumption result of its design, or
consequence of unfixed space-leaks, ie. is it fixable without
re-writing?

> One approach I havn't tried but might bear some fruit is to check that
> c2hs is actually using all the data it collects, or if in fact much of
> the AST goes unused in which case it could be eliminated. However I
> don't imagine that this would give any enourmous savings (ie enough to
> process the Gtk 2.x headers on a machine with 256Mb or RAM).

So, let's not dwell on it.

> Basically the idea is that we want to to only run c2hs on the developers
> machine and distribute the resulting .hs files. That way only the
> developers machines need 1Gb of RAM. 

But, don't we cut with this the (potential) number of devs who can hack
on repository code (maybe not relevant now, but hopefully it will
become) ?

And what is the real amount of RAM needed?

I could not compile gtk2hs with 1GB of RAM, but I'm not sure whether it
is because of problems with ghc on amd64 or due to c2hs memory
consumption?

> But we also want the resulting .hs
> files to be portable. Portable both between architectures and between
> different versions of Gtk+. For the architecture independence all we
> have to do is make sure we are not using the c2hs {# get #} {# set #}
> features since they embed field offsets into the .hs file which is not
> portable. This is not a great hardship for us since we mostly use hsc2hs
> for doing structure access and c2hs for calling functions.

Are there some other spots where using hsc2hs (instead of depending on
c2hs) can become handy?

> I do not yet know if this approach will work fully, I'm still asessing
> its feasability. If it does turn out to be a workable approach, I'd be
> keen to discuss with Manuel wether he might accept such a feature
> (controlled by some command line flag) into the main c2hs.

Although I like concept of c2hs very much, still I consider that in case
we cannot have gtk2hs build on 'normal' machines with the 'normal'
invoking of c2hs - fixing the present c2hs memory consumption - then we
have to be pragmatic and use and/or tailor available tools so that the
job can be done, not thinking about compatibility with the 'official'
c2hs development. At the end, c2hs should be a tool helping us
developing gtk2hs bindings, and not vice versa.

However, I still hope that (somehow) c2hs can be brought down to the
'normal' mem reqs...and (hopefully) this discussion can shed some more
light.


Manuel, as the author of c2hs, what is your piece of advice?


Sincerely,
Gour

-- 
Registered Linux User	| #278493
GPG Public Key		| 8C44EDCD