Discussion:
a memory issue; mildly scaring to me
(too old to reply)
Jörg F. Wittenberger
2011-09-24 16:08:13 UTC
Permalink
Hi,

I'm facing a strange issue. My program normally runs quite well.
Just once upon a time (that is sometimes only after hours plus
a sleep mode, however under certain circumstances upon ~70% of
starts within the first few seconds) it will start to eat memory
as if it where electricity.

Tracking that down seems hard. There is no unexpected heap usage
according to ##sys#dump-heap-state and ##sys#memory-info.
Furthermore there is no indication so far that elsewhere a memory
leak would exist. (I added tracking code to those few malloc/free
pairs I have.)

Time to learn how to use valgrind. ... I thought, so at worst this
is a "help me learning" request of mine.

To begin with I rebuild my chicken with DEBUGBUILD=1 (and my app too).

The expected slow down is in fact worse enough to trigger my "app
alive" watchdog. But for half a minute it runs quite well. Except
that valgrind will report problems:

==14864== Conditional jump or move depends on uninitialised value(s)
==14864== at 0x531AB24: C_equalp (runtime.c:3909)
==14864== by 0x4F5F816: f_6610 (library.c:38125)
==14864== by 0x519853B: f_19858 (irregex.c:12514)
==14864== by 0x5198B2C: f_19929 (irregex.c:12591)
==14864== by 0x51988B0: f_19843 (irregex.c:12562)
==14864== by 0x4F47532: f_9742 (library.c:32791)

Note that line numbers in runtime.c will be off - I added some debug
code there.

So untime.c:3909 resolves to C_equalp right after the "loop:" label:

loop:
if(x == y) return 1;

Around 30 lines down we find:

x = C_block_item(x, i);
y = C_block_item(y, i);
goto loop;

which I take as looking suspicious. The i just ran from 0 while
i < (n = header & C_HEADER_SIZE_MASK).

Now I might missread the source, but at that point I'd assume
that C_block_item(x-or-y, i) would be off-by-one.

But wait!

I tried to change the procedure and instead of those 3 lines
I left a "return 1;" there. This seems at least to work well
for some simple checks in csi. But my app will now: a) run
without valgrinds complaint b) into an endless loop.

Taking into account that while compiling the DEBUGBUILD I ignored
a ton of warnings about type issues in irregex.scm, I'm kinda
alarmed that those calls to the questionable equal? originated from
irregex.

So the first question would be: why do we "goto loop;" here?
If this is correct, it looks weird enough IMHO to warrent a comment
in the source code. If those three lines could be replaced by

return 1;

then they should be for clarity.

In the latter case however we would probably have a problem in irregex.
don't we?

/Jörg
.......
Peter Bex
2011-09-24 16:15:33 UTC
Permalink
Post by Jörg F. Wittenberger
Hi,
I tried to change the procedure and instead of those 3 lines
I left a "return 1;" there. This seems at least to work well
for some simple checks in csi. But my app will now: a) run
without valgrinds complaint b) into an endless loop.
Taking into account that while compiling the DEBUGBUILD I ignored
a ton of warnings about type issues in irregex.scm, I'm kinda
alarmed that those calls to the questionable equal? originated from
irregex.
Please try the current master first; it contains some bugfixes to
the types database, which make those irregex errors go away
(changeset 0fbbba9d5fc0dcce7b2364beaf3396d501967d0e).

Cheers,
Peter
--
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth
Jörg F. Wittenberger
2011-09-24 17:53:12 UTC
Permalink
Post by Peter Bex
Post by Jörg F. Wittenberger
Hi,
I tried to change the procedure and instead of those 3 lines
I left a "return 1;" there. This seems at least to work well
for some simple checks in csi. But my app will now: a) run
without valgrinds complaint b) into an endless loop.
Taking into account that while compiling the DEBUGBUILD I ignored
a ton of warnings about type issues in irregex.scm, I'm kinda
alarmed that those calls to the questionable equal? originated from
irregex.
Please try the current master first; it contains some bugfixes to
the types database, which make those irregex errors go away
(changeset 0fbbba9d5fc0dcce7b2364beaf3396d501967d0e).
I will do so. (But have to leave now.)

However, I consider the other part of my posting the real issue:

Those C_block_item statements do - at least in my eyes - reference
some memory, which does not pertain to the objects the equal?
compares. Independent of "seems to work" judgements it looks
wrong. If it is correct, I'd really love to see some remarks about
the situation in the source (and sure in the mail list before).

Otherwise I'll see anyway what the update will bring in. :-)/
Jörg F. Wittenberger
2011-09-24 20:27:48 UTC
Permalink
Post by Peter Bex
Please try the current master first; it contains some bugfixes to
the types database, which make those irregex errors go away
(changeset 0fbbba9d5fc0dcce7b2364beaf3396d501967d0e).
So I did (I hope).

Remaining "Note:"-labeld warnings in irregex.scm which look as if they
could be relevant:


Note: in local procedure `lp',
in local procedure `collect/terms',
in local procedure `lp',
in toplevel procedure `string->sre':
irregex-core.scm:806: in procedure call to `pair?', the predicate is
called with an argument of type
`pair' and will always return true

Note: in local procedure `lp',
in local procedure `collect/terms',
in local procedure `lp',
in toplevel procedure `string->sre':
irregex-core.scm:811: in procedure call to `pair?', the predicate is
called with an argument of type
`(pair (pair * pair) *)' and will always return true

All remarks like
Note: global variable `XXX' is only locally visible and never used
removed.

Valgrinds complains look similar as before, but are off now:

==9367== Conditional jump or move depends on uninitialised value(s)
==9367== at 0x531DA93: C_equalp (runtime.c:3902)
==9367== by 0x4F600D3: f_6609 (library.c:38818)
==9367== by 0x519B067: f_20818 (irregex.c:12516)
==9367== by 0x519B649: f_20889 (irregex.c:12593)
==9367== by 0x519B3CD: f_20803 (irregex.c:12564)
==9367== by 0x4F47C7B: f_9740 (library.c:33397)
==9367== by 0x5365F32: allocate_vector_2 (runtime.c:7089)
==9367== by 0x5365B99: C_allocate_vector (runtime.c:7039)
==9367== by 0x4F4816D: f_9702 (library.c:33468)
==9367== by 0x4F480E1: f_9695r (library.c:33455)
==9367== by 0x4F47FBE: f_9695 (library.c:33439)
==9367== by 0x4F47B28: f_9724 (library.c:33381)
==9367== Uninitialised value was created by a stack allocation
==9367== at 0x5178540: f_7287 (irregex.c:6181)

Whereby

runtime.c:3902 is - as before - right after the "loop:" label.

There are so far 3 occurences within the time period my prog runs
under valgrind (which would be something like 2 seconds wall clock
until killed for being 50 times too slow or something).

Two have the same source:

==9367== Uninitialised value was created by a stack allocation
==9367== at 0x5178540: f_7287 (irregex.c:6181)

while the third has

==9367== Uninitialised value was created by a stack allocation
==9367== at 0x517A5F8: f_17819 (irregex.c:6370)

Hm.
Jörg F. Wittenberger
2011-09-24 20:53:21 UTC
Permalink
Post by Peter Bex
Please try the current master first; it contains some bugfixes to
the types database, which make those irregex errors go away
(changeset 0fbbba9d5fc0dcce7b2364beaf3396d501967d0e).
To be sure, I recompiled my prog with the 4.7.4 chicken.

Now I am where I least which where to be. Or maybe at the begin of
a successful bug hunt? Now my prog will eat all memory. Always.

For no mildly good looking reasons.

:-(


I better find a nice place on my pillow for tonight.

......
Jörg F. Wittenberger
2011-09-25 10:36:23 UTC
Permalink
I'm still kinda lost.

Is there any documentation I could read to understand a little more of
irregex code? The source says it should run on any Scheme; just not how.
;-)

On repeated examination my problem really looks as if it was an
initialisation issue.

Just the odds have changed. While it used to be mostly working, it's
working sometimes only now. (Whereby mysteriously it's already somewhat
better today. Same machine, same executable.)

That is, the actual prog is working as expected. Same way as on the other
Scheme. No indication of errors, which could be relevant in the case at
hand.

The strange consumption looks like this: After a normal startup the prog
will run into about 70M or 130M virtual memory within about 3-5 seconds.
Only heavy load will make it expand beyond. Up to 2% CPU usage on my laptop.

The rarest case: after running that way for possibly really long time,
it might suddenly eat memory.

The case which recently appears at about 50% of starts: it expands within
1 second to at least 130 or more likely 240M. Within the next seconds
it will eat 2-3G. Thereby it will run on the same 2% CPU and work normally.
That is until the whole machine dies from swap workload.
Post by Peter Bex
Post by Jörg F. Wittenberger
Hi,
I tried to change the procedure and instead of those 3 lines
I left a "return 1;" there. This seems at least to work well
for some simple checks in csi. But my app will now: a) run
without valgrinds complaint b) into an endless loop.
Taking into account that while compiling the DEBUGBUILD I ignored
a ton of warnings about type issues in irregex.scm, I'm kinda
alarmed that those calls to the questionable equal? originated from
irregex.
Please try the current master first; it contains some bugfixes to
the types database, which make those irregex errors go away
(changeset 0fbbba9d5fc0dcce7b2364beaf3396d501967d0e).
Peter Bex
2011-09-25 11:58:02 UTC
Permalink
Post by Jörg F. Wittenberger
I'm still kinda lost.
Is there any documentation I could read to understand a little more of
irregex code? The source says it should run on any Scheme; just not how.
;-)
The *portable* and upstream version of irregex is at
http://code.google.com/p/irregex/
The in-tree version we have for Chicken is hacked up for performance,
so it is no longer portable.

I think this is probably a huge red herring; the equal? code you
mentioned does seem to have an off-by-one error. Have you tried just
returning true instead of the assignments and "goto loop;" at the end?

Cheers,
Peter
--
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth
Jörg F. Wittenberger
2011-09-26 09:28:21 UTC
Permalink
Post by Peter Bex
Post by Jörg F. Wittenberger
I'm still kinda lost.
Is there any documentation I could read to understand a little more of
irregex code? The source says it should run on any Scheme; just not how.
;-)
The *portable* and upstream version of irregex is at
http://code.google.com/p/irregex/
The in-tree version we have for Chicken is hacked up for performance,
so it is no longer portable.
I think this is probably a huge red herring; the equal? code you
mentioned does seem to have an off-by-one error. Have you tried just
returning true instead of the assignments and "goto loop;" at the end?
Yes I did (I mentioned before, I did not post it without trying that one).

This is the "seems to be correct" case: If I remove it, the prog will
run without valgrind warnings into an endless loop. The same goes for the
compiler; compiling with an equal? fixed according to the theory that this
must be an off-by-one will not terminate either.

At the same time some tests with csi and the fixed equal? gave correct
results.

My bet by now is that the off-by-one is there and ought to be fixed.
However another bug relies on it, which would trigger the endless recursion.
So we will need to kill both at once.

The fact that the irregex code is modified give me hope that it is
reasonable to analyse that part in more detail.
Jörg F. Wittenberger
2011-09-26 09:41:50 UTC
Permalink
Post by Jörg F. Wittenberger
The fact that the irregex code is modified give me hope that it is
reasonable to analyse that part in more detail.
Things are getting harder to understand for me.

AFAIK ##sys#setislot is for immediate objects only. irregex.scm/build-cache
-however uses it and the call site passes non-immediate values.
Jörg F. Wittenberger
2011-09-26 10:17:20 UTC
Permalink
Post by Jörg F. Wittenberger
My bet by now is that the off-by-one is there and ought to be fixed.
However another bug relies on it, which would trigger the endless
recursion. So we will need to kill both at once.
Worse: I found that the off-by-one might not be there.
The code avoids on recursion into itself on the last slot.

But I'm already confused enough. Maybe I'm misreading even more.
Jörg F. Wittenberger
2011-09-26 11:41:17 UTC
Permalink
Post by Jörg F. Wittenberger
The fact that the irregex code is modified give me hope that it is
reasonable to analyse that part in more detail.
While it does not fix the problem at hand:

There is a suspicious line in regex-core.scm 2222:

it reads:

(printing or graphic whitespace)

IMHO it should read:

(printing . (or graphic whitespace))
John Cowan
2011-09-26 12:39:29 UTC
Permalink
Post by Jörg F. Wittenberger
(printing or graphic whitespace)
(printing . (or graphic whitespace))
Those are exactly the same thing. I run into this all the time when
creating a-lists where the value is a list.
--
We call nothing profound ***@ccil.org
that is not wittily expressed. John Cowan
--Northrop Frye (improved)
Jörg F. Wittenberger
2011-09-26 13:16:07 UTC
Permalink
Post by Jörg F. Wittenberger
(printing or graphic whitespace)
(printing . (or graphic whitespace))
BTW: I know that those are the same. It's just confusing the reader,
when the same list is written both styles.

Since the valgrind hints point into the initialization, I'm actually
reading the code. :-/

There is more inconsistency to report, which too pertains to the original
rrregex source:

In sre-named-definitions there is exactly one entry, which obviously
has a procedure in the cdr:

(escape . ,(lambda (esc . o) `(* (or (~ ,esc ,@o) (seq ,esc any)))))

Since I do not fully understand the code, I don#t know what the intention
is.

However the uses are not too many and hint towards possible errors:

line 1714 in the original 1816 in the chicken/irregex-core:
(cond
((assq (car sre) sre-named-definitions)
=> (lambda (cell)
(lp (apply (cdr cell) (cdr sre)) n lo hi return)))

This one looks compatible with the escape procedure.

Line 1728 resp. 1830:

(let ((cell (assq sre sre-named-definitions)))
(if cell
(lp (if (procedure? (cdr cell)) ((cdr cell)) (cdr cell))
n lo hi return)

This one should produce a missing parameter.

Ah: since parameter checking might be off in the chicken core (is it?),
what would happen, if we use a parameter, which has not been passed?
Might that be the uninitialized value from a stack allocation, which
I see from valgrind?

2301/2404, same possible miss.

2421/2523: again signature compatible.

3321/3429:

(let ((cell (assq sre sre-named-definitions)))
(if cell
(rec (cdr cell))

loops into sre->procedure, which should IMHO default ince there's no
case for procedures.

The final one line(s) 3481/3589 should also raise an error.

What should be done?

Best regards

/Jörg
.....
Peter Bex
2011-09-26 13:26:59 UTC
Permalink
Post by Jörg F. Wittenberger
Post by Jörg F. Wittenberger
(printing or graphic whitespace)
(printing . (or graphic whitespace))
BTW: I know that those are the same. It's just confusing the reader,
when the same list is written both styles.
Maybe. This can be fixed, but it's not the issue here.
Post by Jörg F. Wittenberger
Ah: since parameter checking might be off in the chicken core (is it?),
what would happen, if we use a parameter, which has not been passed?
Might that be the uninitialized value from a stack allocation, which
I see from valgrind?
What should be done?
Why don't you try your regex code with upstream irregex itself?

Just (load "irregex.scm") and then run your regex match.
Then it will run with all checks enabled, at slow speed, but at least
it'll fail when something is broken.

All this speculation is kind of pointless without a proper testcase.

Cheers,
Peter
--
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth
Jörg F. Wittenberger
2011-09-26 15:04:12 UTC
Permalink
Post by Peter Bex
Post by Jörg F. Wittenberger
Post by Jörg F. Wittenberger
(printing or graphic whitespace)
(printing . (or graphic whitespace))
BTW: I know that those are the same. It's just confusing the reader,
when the same list is written both styles.
Maybe. This can be fixed, but it's not the issue here.
Post by Jörg F. Wittenberger
Ah: since parameter checking might be off in the chicken core (is it?),
what would happen, if we use a parameter, which has not been passed?
Might that be the uninitialized value from a stack allocation, which
I see from valgrind?
What should be done?
Why don't you try your regex code with upstream irregex itself?
This looks infeasible expensive to me. A ton of them scattered all around
in many source files. Some are for historical reasons dispatched to pcre.
I will not be able to say which one are checked and passed good.

Furthermore recall: the issue will only appear sometimes. Or might be
hinted to from valgrind output.

Alls those hints however point into irregex toplevel initialisation.
There seems to be a good chance that they will pass all in the interpreter.

At the other hand there is no evidence that a *particular* regex is the
cause. So far I have two complaints from valgrind with the same sequence
of calls and one different. Both the C functions appear to do toplevel
initializations. Only one of them is about sre-named-definitions.

Hence I'm afraid that my considerations wrt. possible irregex weirdness
might be both correct and irrelevant at the same time. At worst.

I fail to see a test plan on that path.
Post by Peter Bex
Just (load "irregex.scm") and then run your regex match.
Then it will run with all checks enabled, at slow speed, but at least
it'll fail when something is broken.
All this speculation is kind of pointless without a proper testcase.
That's the problem in fact.

So far I'm trying pin one down.

I'll try instead to make a version of libchicken with the checks enforced.
Jörg F. Wittenberger
2011-09-26 18:16:02 UTC
Permalink
Hi,

I've got a question wrt. the scope of definitions in chicken core units:

How does it come that some definitions are visible at top level eventually,
while some are used in the compilation unit only?

E.g., SRFI-1. It lives in it's own file. irregex defines some simplified
versions too. How does it come that those do not end up in the global envt?


So much for the question. While I tried to answer that to myself, I've
got this monkey-typing-idea: "make sure it does not" -> don't define e.g.
"fold" as a procedure in irregex. So I commented it out in irregex-core.scm
and wrote this into irregex.scm:

(define-compiler-syntax fold
(syntax-rules ()
((_ kons knil lst)
(let lp ((ls ls) (res knil))
(if (null? ls)
res
(lp (cdr ls) (kons (car ls) res)))))))


This results in a strange error message hinting towards an expansion
problem:


(let2940 lp2941 (((cdr sre) (cdr sre))
(res2942 (+ sum (case (car sre)
(($ submatch => submatch-named)
1)
((dsm) (+ (cadr sre) (caddr
sre))) ((posix-string) (sre-count-submatches (string->sre (cadr sre))))
(else 0))))) (if2943 (null?2944 (cdr sre)) res2942 (lp2941 (cdr2945 (cdr
sre)) (count (car2946 (cdr sre)) res2942))))


Resulting from:


(define (sre-count-submatches sre)
(let count ((sre sre) (sum 0))
(if (pair? sre)
(fold count
(+ sum (case (car sre)
(($ submatch => submatch-named) 1)
((dsm) (+ (cadr sre) (caddr sre)))
((posix-string)
(sre-count-submatches (string->sre (cadr sre))))
(else 0)))
(cdr sre))
sum)))


Given the expansion in the error message I tried changing my syntax
slightly:


(define-compiler-syntax fold
(syntax-rules ()
((_ kons knil lst)
(let lp ((ls lst) (res knil))
(if (null? ls)
res
(lp (cdr ls) (kons (car ls) res)))))))


This one compiles and runs.

But it looks as if the macro expansion where not hygienic.
Otherwise those two definitions would IMHO be equivalent.

Bet regards

/Jerry
....
Jörg F. Wittenberger
2011-09-26 18:34:01 UTC
Permalink
I kinda confirmed that the possible problems I reported here
are more an aesthetic issue wrt. comprehensibility of code.

At least I made sure that *none* of those "suspicious" looking calls
where ever made in my case.
Post by Jörg F. Wittenberger
Post by Jörg F. Wittenberger
(printing or graphic whitespace)
(printing . (or graphic whitespace))
BTW: I know that those are the same. It's just confusing the reader,
when the same list is written both styles.
Since the valgrind hints point into the initialization, I'm actually
reading the code. :-/
There is more inconsistency to report, which too pertains to the original
In sre-named-definitions there is exactly one entry, which obviously
Since I do not fully understand the code, I don#t know what the intention
is.
(cond
((assq (car sre) sre-named-definitions)
=> (lambda (cell)
(lp (apply (cdr cell) (cdr sre)) n lo hi return)))
This one looks compatible with the escape procedure.
(let ((cell (assq sre sre-named-definitions)))
(if cell
(lp (if (procedure? (cdr cell)) ((cdr cell)) (cdr cell))
n lo hi return)
This one should produce a missing parameter.
Ah: since parameter checking might be off in the chicken core (is it?),
what would happen, if we use a parameter, which has not been passed?
Might that be the uninitialized value from a stack allocation, which
I see from valgrind?
2301/2404, same possible miss.
2421/2523: again signature compatible.
(let ((cell (assq sre sre-named-definitions)))
(if cell
(rec (cdr cell))
loops into sre->procedure, which should IMHO default ince there's no
case for procedures.
The final one line(s) 3481/3589 should also raise an error.
What should be done?
Best regards
/Jörg
.....
_______________________________________________
Chicken-users mailing list
https://lists.nongnu.org/mailman/listinfo/chicken-use
Jörg F. Wittenberger
2011-09-26 18:39:50 UTC
Permalink
I found theses definitions in the irregex code mirroring srfi-1
simplified cases.

(define (filter pred ls)
(let lp ((ls ls) (res '()))
(if (null? ls)
(reverse res)
(lp (cdr ls) (if (pred (car ls)) (cons (car ls) res) res)))))

(define (remove pred ls)
(let lp ((ls ls) (res '()))
(if (null? ls)
(reverse res)
(lp (cdr ls) (if (pred (car ls)) res (cons (car ls) res))))))

The irregex code itself appears not to use them anywhere.

Obsolete?
Jörg F. Wittenberger
2011-09-26 18:56:25 UTC
Permalink
While I've been tampering with the irregex code I found that adding this


(define-compiler-syntax any
(syntax-rules ()
((_ pred ls)
(and (pair? ls)
(let lp ((head (car ls)) (tail (cdr ls)))
(if (null? tail)
(pred head)
(or (pred head) (lp (car tail) (cdr tail)))))))))

(define-compiler-syntax every
(syntax-rules ()
((_ pred ls)
(or (null? ls)
(let lp ((head (car ls)) (tail (cdr ls)))
(if (null? tail)
(pred head)
(and (pred head) (lp (car tail) (cdr tail)))))))))

to irregex.scm (before define-compiler-syntax reverse ) would not do any
harm. The corresponding definition in irregex-core.scm would then be
obsolete.

I have no idea how much the gain/cost ration would be.

Anybody who does?
Alex Shinn
2011-09-26 23:23:09 UTC
Permalink
On Tue, Sep 27, 2011 at 3:39 AM, Jörg F. Wittenberger
Post by Jörg F. Wittenberger
I found theses definitions in the irregex code mirroring srfi-1
simplified cases.
(define (filter pred ls)
 (let lp ((ls ls) (res '()))
  (if (null? ls)
      (reverse res)
      (lp (cdr ls) (if (pred (car ls)) (cons (car ls) res) res)))))
(define (remove pred ls)
 (let lp ((ls ls) (res '()))
  (if (null? ls)
      (reverse res)
      (lp (cdr ls) (if (pred (car ls)) res (cons (car ls) res))))))
The irregex code itself appears not to use them anywhere.
Irregex is designed so that (load "irregex.scm") will work
in any vaguely Scheme-like system. In the near future I
plan on switching to the R7RS module system, but in the
meantime I have no interest in breaking that simplicity.
--
Alex
Jörg F. Wittenberger
2011-09-27 08:30:13 UTC
Permalink
Post by Alex Shinn
On Tue, Sep 27, 2011 at 3:39 AM, Jörg F. Wittenberger
Post by Jörg F. Wittenberger
I found theses definitions in the irregex code mirroring srfi-1
simplified cases.
(define (filter pred ls)
(let lp ((ls ls) (res '()))
(if (null? ls)
(reverse res)
(lp (cdr ls) (if (pred (car ls)) (cons (car ls) res) res)))))
(define (remove pred ls)
(let lp ((ls ls) (res '()))
(if (null? ls)
(reverse res)
(lp (cdr ls) (if (pred (car ls)) res (cons (car ls) res))))))
The irregex code itself appears not to use them anywhere.
Irregex is designed so that (load "irregex.scm") will work
in any vaguely Scheme-like system. In the near future I
plan on switching to the R7RS module system, but in the
meantime I have no interest in breaking that simplicity.
I do understand and really appreciate that goal.

But not including those two definitions should IMHO not do any harm.
I simply can not see where those would be used within irregex.scm.


/Jörg
Alex Shinn
2011-09-27 12:28:50 UTC
Permalink
On Tue, Sep 27, 2011 at 5:30 PM, Jörg F. Wittenberger
Post by Jörg F. Wittenberger
But not including those two definitions should IMHO not do any harm.
I simply can not see where those would be used within irregex.scm.
Sorry, I thought you were suggesting importing
srfi-1 instead of using those definitions.

The references to them do seem to have been
removed recently.
--
Alex
Loading...