So, finally, here we go with these patches. (again! :-))
In summary, they all look great, and I just have a few minor comments
(below) on the first one.
But I guess we need to decide on your suggestion about
> (I still believe that these should be changed to versions that handle
> %nil properl
Andy Wingo writes:
>> scm_is_false_assume_not_lisp_nil scm_is_true_assume_not_lisp_nil
>> scm_is_false_and_not_lisp_nil scm_is_true_or_lisp_nil
>> scm_is_false_or_lisp_nil scm_is_true_and_not_lisp_nil
>>
>> scm_is_lisp_false scm_is_lisp_true
>>
>> scm_is_nu
Hi Julian!
Neil Jerram writes:
> You're completely right. The version stuff is historical and no
> longer needed in master, so we should definitely blow it away. In
> fact the same applies to the whole existence of
> ice-9-debugger-extensions. (It was all about wanting to support 1.6
> and 1.
Hi Mark!
Mark H Weaver writes:
> I would like to argue that the definitions of scm_is_false,
> scm_is_true, and scm_is_null should indeed be changed to test for
> %nil.
OK, thanks to your arguments, I now agree with this.
> Do a grep-find in the tree for uses of these macros. I think you'll
>
"Mark H. Weaver" writes:
> I found one thorny use of scm_is_bool and scm_is_null, and request
> your collective wisdom:
>
> scm_class_of() in goops.c tries to determine the class of a scheme
> value. If scm_is_bool returns true, it's classified as
> scm_class_boolean, and if scm_is_null returns
Mark H Weaver writes:
> This numbering has the nice properties that 0 is #f.
Just to be clear: will this mean that (SCM_BOOL_F == 0) ? As things
stand I don't think it will, because SCM_MAKIFLAG shifts and adds
0x04.
Just checking this because Ludovic said recently that (SCM_BOOL_F ==
0) would
Neil Jerram writes:
> because if we agreed this, some of the changes would be needed, or
> wouldn't be needed.
:-)
I think I meant to say "would be different, or wouldn't be needed".
Neil
Neil wrote:
> > I would like to argue that the definitions of scm_is_false,
> > scm_is_true, and scm_is_null should indeed be changed to test for
> > %nil.
>
> OK, thanks to your arguments, I now agree with this.
Excellent!
What about scm_is_bool? I'm tempted to suggest that it should work
the
On Sun, Aug 30, 2009 at 12:13:59PM +0100, Neil Jerram wrote:
> Mark H Weaver writes:
>
> > This numbering has the nice properties that 0 is #f.
>
> Just to be clear: will this mean that (SCM_BOOL_F == 0) ? As things
> stand I don't think it will, because SCM_MAKIFLAG shifts and adds
> 0x04.
Ye
Hi Barry,
Thank you for the bug report, it was quite interesting.
On Sat 29 Aug 2009 17:49, Barry Fishman writes:
> #! /bin/sh
> # -*- scheme -*-
> exec guile -s "$0" $*
> !#
>
> (load "dotimes.scm")
>
> (dotimes (indx 5)
> (display indx)
> (newline))
When compiling tryme, what happens is
Hi Neil,
Ack, sorry for not replying sooner -- I've been occupied with
switching jobs and moving apartments.
> This should all be fixed in master now. Can you have a go and let me
> know if you still see any problems?
Just built from HEAD. The errors I reported earlier are gone, but I'm
still
Hey folks,
I'd like to outline something of a plan.
The general outline is first to simplify dispatch, then to pull it into
the VM.
Ideally I would like to have only three kinds of procedures: VM
procedures, subrs, and applicable structs. It might not be possible to
simplify all of these, but we
Andy Wingo writes:
> Thank you for the bug report, it was quite interesting.
Thank you for your clear explanation, and your solutions are
simple to implement.
> When compiling tryme, what happens is that `(load "dotimes.scm")' gets
> compiled into a load at runtime -- but the dotimes.scm isn't
I wrote up a little summary about the new representation of lisp
booleans. Maybe something like it will end up in the documentation of
guile internals.
It assumes two more "never use" values that weren't in my v1 patch:
IFLAGS 6 and 7. This helps make scm_is_lisp_bool a fast operation
without fu
I wrote:
> > I added the following macros, whose names explicitly state how %nil
> > should be handled. See the comments in the patch for more information
> > about these.
> >
> > scm_is_false_assume_not_lisp_nil scm_is_true_assume_not_lisp_nil
> > scm_is_false_and_not_lisp_nil scm_is_tru
On Aug 30, 2009, at 07:13, Neil Jerram wrote:
Mark H Weaver writes:
This numbering has the nice properties that 0 is #f.
Just to be clear: will this mean that (SCM_BOOL_F == 0) ? As things
stand I don't think it will, because SCM_MAKIFLAG shifts and adds
0x04.
Just checking this because Ludovi
16 matches
Mail list logo
