Bug in save-stack?

Bug in save-stack?

[Jim Blandy]

Looking at the definition of save-stack in boot-9.scm, I notice that,
in all but one of the cases, the elements of NARROWING are passed
after an even number of cutting arguments, but in the #t case, they
are passed after an odd number of cutting arguments.  In other words,
when the stack id is #t, the first argument passed to save-stack is
treated as an OUTER-CUT, not an INNER-CUT, as it would be for any
other stack id.

I don't know what a stack-id of #t is supposed to mean; I can't find
it documented or being used anywhere.  But the behavior of save-stack
when the stack-id is #t looks accidental.  Would something like the
below be appropriate?

If this is right, someone knowledgeble should also document what a
stack id of #t is supposed to mean.  Otherwise, that clause should be
deleted.

2005-02-14  Jim Blandy  <jimb@redhat.com>

	* boot-9.scm (save-stack): When (stack-id #t) is #t, don't neglect
	to pass an OUTER-CUT argument corresponding to the second
	INNER-CUT argument.

*** boot-9.scm.~1.340.~	2004-11-30 19:02:24.000000000 -0500
--- boot-9.scm	2005-02-14 21:19:26.000000000 -0500
***************
*** 2424,2430 ****
  		((tk-stack)
  		 (apply make-stack #t save-stack tk-stack-mark #t 0 narrowing))
  		((#t)
! 		 (apply make-stack #t save-stack 0 1 narrowing))
  		(else
  		 (let ((id (stack-id #t)))
  		   (and (procedure? id)
--- 2424,2430 ----
  		((tk-stack)
  		 (apply make-stack #t save-stack tk-stack-mark #t 0 narrowing))
  		((#t)
! 		 (apply make-stack #t save-stack 0 1 0 narrowing))
  		(else
  		 (let ((id (stack-id #t)))
  		   (and (procedure? id)



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Bug in save-stack?

[Mikael Djurfeldt]

On Mon, 14 Feb 2005 18:46:22 -0800 (PST), Jim Blandy <jimb@redhat.com> wrote:
> 
> Looking at the definition of save-stack in boot-9.scm, I notice that,
> in all but one of the cases, the elements of NARROWING are passed
> after an even number of cutting arguments, but in the #t case, they
> are passed after an odd number of cutting arguments.  In other words,
> when the stack id is #t, the first argument passed to save-stack is
> treated as an OUTER-CUT, not an INNER-CUT, as it would be for any
> other stack id.
[...]
> If this is right, someone knowledgeble should also document what a
> stack id of #t is supposed to mean.  Otherwise, that clause should be
> deleted.

It looks very strange. I think it's some remnant which someone,
probably I, have forgotten to remove. The tk-stack-mark thing doesn't
belong there either...

I propose we wait for a while. If no-one has objected, we'll remove it
in a week or two.

Thanks,
M

It's quite unsettling to read your own beginner's code...  :-(


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Bug in save-stack?

[Marius Vollmer]

Mikael Djurfeldt <mdjurfeldt@gmail.com> writes:

> I propose we wait for a while. If no-one has objected, we'll remove it
> in a week or two.

Ok.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel