On Mon, Oct 11, 2010 at 01:17:49PM +0900, Alex Shinn wrote:
The valid-index? predicate does not return a boolean #t value:
#;9 (irregex-match-valid-index? m 3)
0
It returns #t for this in the upstream irregex.
I'll look into that. It's probably a bug introduced by a
Chicken-specific
On Mon, Oct 11, 2010 at 02:51, Peter Bex peter@xs4all.nl wrote:
On Mon, Oct 11, 2010 at 01:17:49PM +0900, Alex Shinn wrote:
However, in case of substring and index operations, the result is
always an integer/a string. Returning #f is completely unambiguous
in those cases, so I don't see
On Mon, Oct 11, 2010 at 09:51:15AM +0200, Peter Bex wrote:
#;9 (irregex-match-valid-index? m 3)
0
It returns #t for this in the upstream irregex.
I'll look into that. It's probably a bug introduced by a
Chicken-specific optimization.
Yeah, it was a small oversight in a manual merge
Jim Ursetto zbignie...@gmail.com writes:
I agree with Peter, the /default procedures seem like a needless
abstraction as a totally unambiguous #f is common practice. For
example, srfi-13 string-index.
No, in retrospect I'm not sure why I didn't suggest that to
begin with - I think I've been
Jim Ursetto zbignie...@gmail.com writes:
There is some inconsistency in the docs:
irregex-match-num-submatches: Returns the number of numbered
submatches that are defined in the
irregex or match object.
irregex-match-valid-index?: Returns {{#t}} iff the {{index-or-name}}
named submatch or
On Thu, Oct 07, 2010 at 08:37:59PM -0500, Jim Ursetto wrote:
Does this mean for every egg that uses the irregex API directly, I
need to insert this [cond-expand] blob of code?
You have three options:
- Add a dependency on the regex egg and keep doing
(require-library regex)(import irregex)
On Fri, Oct 08, 2010 at 09:05:10AM +0200, Peter Bex wrote:
On Thu, Oct 07, 2010 at 08:37:59PM -0500, Jim Ursetto wrote:
Does this mean for every egg that uses the irregex API directly, I
need to insert this [cond-expand] blob of code?
You have three options:
- Add a dependency on the
On Fri, Oct 8, 2010 at 02:09, Peter Bex peter@xs4all.nl wrote:
That's not quite true; some of the compatibility code is still necessary
to make up for the changes in the API.
If that's the case, it means that eggs compiled with 4.6.0 aren't
compatible with those compiled with 4.6.2, because
Eh, let me clarify #2. Eggs built with 4.6.0 need to be recompiled
with 4.6.2 regardless due to the C_regex_toplevel linking issues.
However, once they are, they would also work with 4.6.0 again, as long
as they stuck to the old irregex API. I think. This is pretty
confusing. Maybe we should
From: Jim Ursetto zbignie...@gmail.com
Subject: Re: [Chicken-users] Using irregex safely responsibly [Was: Re:
dev-snapshot 4.6.3]
Date: Fri, 8 Oct 2010 16:00:05 -0500
Why can't the compatibility code be included in the new irregex unit?
In other words, the old procedure names and behavior
Hello!
Since there are a few pitfalls to updating eggs to work with the new
Chicken 4.6.2, I've decided to draw up a quick list of pitfalls I noticed.
If you're just using the regex API or the regex API with a few irregex
things, usually all you need is to add (needs regex) to your egg's meta
On Thu, Oct 7, 2010 at 15:53, Peter Bex peter@xs4all.nl wrote:
In your egg's file, where you would previously use this idiom:
(require-library regex) ; or (use regex) for the lazy sloppy
(import irregex)
you can now replace it with this block (you can delete emulation of
12 matches
Mail list logo
