On Sep 12 2011, Kon Lovett wrote:
So: I've been using the environment eggs code for some things.
This does not work any longer. I'd rather like to keep the
code compatibility with rscheme and chicken's veal.
I thought he environments egg worked for < Chicken 4.7.4; simple tests
work for me w/ Chicken 4.7.3 using the procs below. I understand that
with 4.7.4 the egg will not function: see
http://lists.nongnu.org/archive/html/chicken-
hackers/2011-08/msg00041.html. Sorry, but I am out-of-the-loop on this
one.
Ah! I chose a great moment to stay on git trunk while fixing the issues
I'm facing. }:-/
(Just noticed that I have yet another issue: the debian changelog is
not in sync with the actual version. This however would be better done
automatically...which would bring me to the unrelated point that I'm
more or less maintaining a debian directory here; but I'm in no way a
seasoned debian developer; it's just a working build, not a nice one
- is there anybody listening on the list, who would could help on
that one? Should it go into git? Elsewhere?)
Mixing and matching versions and differences is no option for me.
Are any changes considered for the API definition to come for those
procs I need? (If not, I could live for the time being with some
compatible redirects I'd code up in a moment. But I really want to
express by the environment type something I could just pass to the
interpreter - and my "compatible redirects" would only avoid that
at this time rare case.)
make-environment
environment-extend!
environment-copy
environment-ref
/Jerry
These I found so far to be kind of the minimum to enable envt
manipulations from user code.
Could we have such a thing? I'm ready to hack the code overnight,
but what's the API chicken does need right now and which changes
to this API are expected to come more sooner than later?
Thanks a lot
/Jerry
.....
_______________________________________________
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users