chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Felix
Subject: Re: [Chicken-users] Egg <-> Chicken version compatibility
Date: Mon, 22 Aug 2011 10:27:36 +0200 (CEST)

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

It doesn't take care of third-party libraries. I see it as a device to
install libraries and perhaps some tools. That doesn't prevent it being
used to install other sorts of applications, but it simply isn't a 
replacement for apt-get. Some sort of preparation (even if it means
installing a reasonably recent chicken) will be needed.

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

The compiler can ignore declarations like

  (declare (florgleborgle this that the-other))

But how should it ignore

  csc ... -forgleborgle "this that the-other" 

Marking optimization flags ("-opt-..." or "-f..." or so) would perhaps
be an answer, but I find it ugly and it would introduce too much
change and means a lot of work on the docs.

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

Yes, that's a good suggestion.

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

Perhaps more of an enhancement. Since eggs and core are two different
development streams, it is hard to keep them in sync perfectly. And we
(and Salmonella) work hard at doing that.

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

Yes, you did.

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

I'm not sure I understand. Isn't the problem that old chickens fail to
support a new option? Or are you suggesting to be more careful when
introducing options? I try to add declarations for all new options
that regard specific optimizations, if possible.

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

A good idea. But I think we will need more computing resources for
that (a "Salmonella Farm"! ;-). Or a very simple and easy-to-use way
for someone to grab a shell-script that downloads everything,
performs a salmonella run and sends us the results. Or something like
this.

> 
>  * 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)

Hm... yes.

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

Very good. 


cheers,
felix



reply via email to

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