Re: [Chicken-users] Egg <-> Chicken version compatibility

[Felix]

> Hello!

Hello, Alaric.

> 
> Looks like the message-digest egg passes
> - -no-procedure-checks-for-toplevel-bindings to csc, which this old
> version of it doesn't like.
> 

Probably an oversight of the egg maintainer. Have you contacted
that person?

> Now, there's several easy fixes to that (I'm compiling a more recent
> chicken from git as we speak), but it's a bad precedent IMHO that people
> might install chicken from their system package manager and then find
> they can't run Chicken apps. I'd like to be able to confidently say
> "Wanna use Ugarit? Install chicken then type 'chicken-setup -s ugarit'
> and you're away!" rather than expect people to install from source or
> from funny packages.

Yes, that would be nice. But chicken-install is not a package manager,
it's a tool to install libraries.

> 
> In this case, I think that optimisation flags should all be ignored by
> csc if it doesn't understand them.

That wouldn't work for flags that take arguments.

> 
> Perhaps that would require optimisation flags being marked as such so
> they can be differentiated from less optional flags; that might be no
> bad thing anyway from a "keeping the flag namespace clean" perspective,
> if a messy change to go through.

That itself would be a rather messy change.

> 
> We've had other problems with problems due to moving things around in
> the core chicken libraries, too.

Oh yeah, we head. Sometimes things have to change. Still we try to
maintain backwards compatibility, if possible. Long deprecation
phases, change request, etc. Yes, I mean it, even if development
sometimes may make the impression of being haphazardly done. I've sent
you a mail about compatibility issues regarding ugarit (use of
"getenv"). IIRC, you never replied.

> 
> I think, overally, we all need to think more about backwards and
> forwards compatibility when we change the chicken core, so that eggs can
> work reliably on older versions without needing too many version
> conditionals!

The problem you encountered was not caused by core system changes in
this case. And who do you mean with "we"? And "think about"? Can't
you simply say that this is annoying and you want it to stop?

(A statement like the one you make above is mostly ineffective. It's
like going into the living room and saying: "It would be nice if
someone cleaned this mess up!" As you will certainly have experienced,
nothing is going to happen (unless your family has as a member one of
those unfortunate humans that constantly try to fulfill other people's
expectations - but I digress...))

So, do you have any suggestions? What can we do better? What are YOU
willing to contribute? Could you specify more precisely what you'd
like to have? How are the necessary incompatibilities to be
introduced? How can we safely distinguish between bugfixes and
incompatibilities (probably brought in with the intend of fixing
bugs)? How can we keep up fast-paced development and maintenance, and
fast response/bugfixing cycles for user reports and feature requests?


cheers,
felix