[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] vector-copy! compatibility and handling + what else
From: |
Peter Bex |
Subject: |
Re: [Chicken-users] vector-copy! compatibility and handling + what else changed around -extend? |
Date: |
Mon, 4 Mar 2013 11:08:12 +0100 |
User-agent: |
Mutt/1.4.2.3i |
On Mon, Mar 04, 2013 at 10:58:05AM +0100, Jörg F. Wittenberger wrote:
> Hi all,
>
> as usual it's challenging to compile an application using a new
> version of chicken. (In this case I try to upgrade from 5.7.5 to
> current git master.)
>
> Somehow the initialization has changed. Now it breaks upon the
> use or slightly complex irregexp's.
>
> I figured out that this is due to the use of srfi-43.
>
> The problem boils down to chicken having a vector-copy! procedure,
> which takes an incompatible argument order wrt. srfi-43.
I don't see what this has to do with irregex; it uses the "incompatible"
definition from core. Importing the srfi-43 definitions from the
vector-lib egg shouldn't cause that to break.
> Since chicken claims (or claimed?) to support srfi-43, how
> should I do so now?
I did run into this incompatibility yesterday, as well. I think
the SRFI-43 definition is superior, as it allows you to cleanly indicate
copying a subsection of one vector to a subsection of another, and
it's more intuitive for people used to srfi-13's string-copy! procedure.
I think it would be nice if we could support both signatures for a while,
deprecating the old one. If others agree I'll make a CR for this.
> This is not the only change I noticed. Before I ran into
> the problem that I used to feed "define-type"s into the compilation
> via the use of -extend. Beware: this doesn't work anymore.
> One has to put them into a separate file and (include "typedefs.scm")
> everywhere they are use.
Can you give an example? Maybe file a proper bugreport in Trac, so we
can keep track of this issue.
> While I can live with the latter option, frankly I liked the former
> better. Why may I not pass them via -extend anymore? Or, for that
> matter more worrying the question is: what else from my -extend
> stuff is no longer visible as it was before?
I don't remember this being a change we made. Perhaps it's a regression.
Cheers,
Peter
--
http://www.more-magic.net