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

[Alaric Snell-Pym]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/20/2011 04:32 AM, Felix wrote:
>> Hello!
>
> Hello, Alaric.

Hi!

>>
>> 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?

Kon had a patch out within SECONDS, before I'd even found out it was his
egg.

>> 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.

That's an interesting distinction to make. Given that it has the
facility to install executables anyway, what's the difference in your mind?

>>
>> 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.

In the other message, though, you suggested using declares, where
unknown ones emit warnings rather than errors. Can't the command-line
optimisation flags have the same semantics? What happens with declares
that correspond to flags with 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.

Aye, I prefer the subsequent suggestions of sticking to "-O<n>" for
portable command lines, or declarations in the source!

>> 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.

Indeed! I'm only just getting back into sorting Ugarit out, after a
too-long hiatus :-( I need to get it compiling before I can start to
change things :-)

>> 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.

Well, an egg was using a flag that didn't work in older versions - so
adding that flag was a change to the core, no?

> 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?

Did I not managed to express that? :-)

> 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?

Well, as I'm still catching up on things myself, I didn't want to get
too far into specifics, but here's a few ideas:

 * Let's have a discussion about what the best semantics for an
optimisation flag are. Should it fail if that optimisation isn't
available in this version, or just emit a warning? What this boils down
to is, when somebody requests such a flag, are they saying "My code
NEEDS this optimisation" or "My could WOULD LIKE this optimisation but
will work without it"?

 * Can we work out what versions are being installed by distros out
there and draw a line in the sand of the oldest version it'd be nice if
eggs still worked with (to be revised periodically) and have salmonella
do another build of all the eggs against the appropriate git tag of
chicken, to help detect accidental dependencies in eggs?

 * How about, when interfaces change in the manual, writing something
along the lines of "added in version X", so that people writing code
using those interfaces who are concerned about compatability are given
pause for thought, and can take appropriate actions (SRFI-0 etc)

As for what *I* can do? I've got some hardware on order for a new home
fileserver to replace my long-dead one, so I could probably set up a
chroot to bring up a geriatric chicken in and test the eggs for salmonella.

>
> cheers,
> felix
>

ABS

- --
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5QNfIACgkQRgz/WHNxCGrqIACeMlnnDU79q3ZpB+6iQyOkPVFf
22sAn1lFoUeH6tt8BtoV84ro4ZDdIXpy
=/9c9
-----END PGP SIGNATURE-----