Series 2.1 released
Fernando D. Mato Mira
- Workaround for ACL 5.0.1 TAGBODY bug.
- ALL-TIME SERIES BUG FIX: wrappers now inserted more precisely.
- Fixed GATHERING redundant wrapping.
- Prevented generation of some dead termination code.
Implementation:
- Abstracted use of wrapper component of frags.
- GENERATOR deftyped to CONS, not LIST, when necessary.
Current qualification list:
CMUCL 18b (cmucl-2.4.19-2) [SuSE Linux 6.3/Intel]
CMUCL 18c [Solaris]
LispWorks 4.1 [Windows NT 4.0 SP6]
clisp-99.01.08-21 with -a option [SuSE Linux 6.3/Intel]
ACL 5.0.1 [SuSE Linux 6.3/Intel]
http://series.sourceforge.net/
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
Bruno Haible
What kind of bug does ACL have with TAGBODY? Could you please give details?
Bruno
Jon Dyte
mask(#z()) used to segfault. Lieven Marchand posted me a fix (thanks)
and described it as :-
" Basically the problem is a miscompilation of a
second order forward referenced trampoline. As you can see in my
patches I just change the forward reference to a backward one."
Look at the (defS mask .... form to see it patched.
Jon
Sent via Deja.com http://www.deja.com/
Before you buy.
Lieven Marchand
> There is/was an error which shows up in compiled code only. In series
> mask(#z()) used to segfault. Lieven Marchand posted me a fix (thanks)
> and described it as :-
> " Basically the problem is a miscompilation of a
> second order forward referenced trampoline. As you can see in my
> patches I just change the forward reference to a backward one."
>
To expand a bit:
MASK creates something like the following (this is from memory, I
didn't keep a copy of my bug report):
#'(lambda () (tagbody (foo #'(lambda () (go f)) f)))
A closure of a GO in a closure over a TAGBODY with the tag not yet
encountered at the point of creating the closure.
This seems to trigger a bug in code generation. I had reduced the 200
line monstrosity defS generated to a ten liner but anything changed
after that made the problem disappear, even removing unused tags.
--
Lieven Marchand <m...@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker
Fernando D. Mato Mira
> This seems to trigger a bug in code generation. I had reduced the 200
> line monstrosity defS generated to a ten liner but anything changed
> after that made the problem disappear, even removing unused tags.
You macroexpanded defS MASK? Why not just the test expression raising the
problem?
Lieven Marchand
> Lieven Marchand wrote:
>
> > This seems to trigger a bug in code generation. I had reduced the 200
> > line monstrosity defS generated to a ten liner but anything changed
> > after that made the problem disappear, even removing unused tags.
>
> You macroexpanded defS MASK? Why not just the test expression raising the
> problem?
>
The problem is in the closure that gets stored in the gen-fn field of
the series struct. It goes wrong for every use of MASK. Anyway, the
patch had to work at that level too, so I had to make sure my changes
to defS MASK had the correct effect.
Erik Naggum
| The problem is in the closure that gets stored in the gen-fn field of
| the series struct. It goes wrong for every use of MASK. Anyway, the
| patch had to work at that level too, so I had to make sure my changes
| to defS MASK had the correct effect.
I'm curious about all this work you're putting in. have you bothered to
alert bu...@franz.com with a test case so they could fix it and you could
do something more useful with your life?
#:Erik
Jon Dyte
Erik Naggum <er...@naggum.no> wrote:
> I'm curious about all this work you're putting in. have you bothered
to
> alert bu...@franz.com with a test case so they could fix it and you
could
> do something more useful with your life?
>
> #:Erik
>
I sent bu...@franz.com a rather large isolated macro expansion of the
defs mask problem, which seg'd when compiled. I dont have the spr to
hand right now. I didnt fully understand the code and didnt isolate the
problem, very clearly, but I could see it was something to do with
closures.
I got nothing but the mailer autoresponse from franz, but as trial-
edition user I wasnt expecting any more.
I think Lieven sent them a 10 liner which demonstrated the problem.
I send franz all the bugs I have found :-
like :element-type '(integer 0 1) on open didnt appear to work and
(make-sequence 'string (vector 1 2)) doesnt report an error
at least on my linux version.
Jon Dyte
>
> I send franz all the bugs I have found :-
> like :element-type '(integer 0 1) on open didnt appear to work and
> (make-sequence 'string (vector 1 2)) doesnt report an error
> at least on my linux version.
Ooops, that should have been (make-list (vector 1 2)) doesnt report
an error. On the trial linux version you will run out of memory as it
tries to do something it shouldnt.
The spr's are spr21041 (element-type and streams) and
spr21710 (make-list not signalling error) if anyone wants
to follow it up.