Date: Thu, 3 Nov 2016 18:00:17 -0700
From: Matt Birkholz
> That excerpt is about (begin (values 1 2 3) ...). [repeat of 1st excerpt]
>
> [second excerpt]
>
> That excerpt is about (list (values 1 2 3)), which I strongly advise
> that we report noisily.
Is ther
> From: Taylor R Campbell
> Date: Thu, 3 Nov 2016 20:26:22 +
>
> [...]
>I was pleased to find only a couple spots needing patching to "pass
>along multiple values". The team did good. The lusers may still get
>sore, but our canon offered a good example.
>
> How do you know you
Date: Thu, 3 Nov 2016 13:15:54 -0700
From: Matt Birkholz
> From: Taylor R Campbell
> Date: Thu, 3 Nov 2016 18:36:24 +
>
> [...] Did anything other than paths involving CALL-WITH-VALUES and
> VALUES change?
Nope.
Might be worthwhile to try the profiler, an
> From: Taylor R Campbell
> Date: Thu, 3 Nov 2016 18:36:24 +
>
> [...] Did anything other than paths involving CALL-WITH-VALUES and
> VALUES change?
Nope.
> It has long been a bug and it's why I introduced BEGIN0, so that we
> could prepare code to do the right thing before making the righ
Date: Thu, 3 Nov 2016 11:28:18 -0700
From: Matt Birkholz
> From: Taylor R Campbell
> Date: Thu, 3 Nov 2016 16:10:34 +
>
> and thereby avoid the closure altogether. That's what the integration
> you're deleting did.
I see. You assume values is integrated into
> From: Taylor R Campbell
> Date: Thu, 3 Nov 2016 16:10:34 +
>
> [...]
> LIAR didn't, but SF did. It would transform
>
> (receive (x y z) (values a b c)
> ...)
>
> into
>
> (let ((x a) (y b) (z c))
> ...)
>
> and thereby avoid the closure altogether. That's what the integration
> yo
Date: Thu, 3 Nov 2016 07:58:49 -0700
From: Matt Birkholz
> From: Taylor R Campbell
> Date: Thu, 3 Nov 2016 00:16:21 +
>
> Why are you deleting expansions in SF that are already deleted from
> the source code?
I delete SF expansions in the host. Deleting them
> From: Taylor R Campbell
> Date: Thu, 3 Nov 2016 00:16:21 +
>
>Date: Wed, 2 Nov 2016 16:56:03 -0700
>From: Matt Birkholz
>
>I do not have SVM builds working yet, but I don't expect that will be
>a problem. Is tools/patch.scm a problem? Too kludgerrific? How
>SHOULD I
Date: Thu, 3 Nov 2016 00:16:21 +
From: Taylor R Campbell
Date: Wed, 2 Nov 2016 16:56:03 -0700
From: Matt Birkholz
I do not have SVM builds working yet, but I don't expect that will be
a problem. Is tools/patch.scm a problem? Too kludgerrific? How
SHOUL
Date: Wed, 2 Nov 2016 16:56:03 -0700
From: Matt Birkholz
I do not have SVM builds working yet, but I don't expect that will be
a problem. Is tools/patch.scm a problem? Too kludgerrific? How
SHOULD I train a 9.2 build host?
I don't understand what tools/patch.scm is needed for.
I just pushed a commit to the new multiple-values branch that implements
REFLECT_CODE_MULTIPLE_VALUES. Most of the smarts still end up in
Prim_values, the stack magician. The reflection(?) improves the
performance of the tests (aka tests/check.scm) dramatically.
With a Prim_call_with_values that
> From: Taylor R Campbell
> Date: Fri, 14 Oct 2016 20:10:38 +
>
>Date: Fri, 14 Oct 2016 12:25:12 -0700
>From: Matt Birkholz
>
>Did I hear that VALUES might not be terribly expensive nor difficult
>to implement? Taylor suggested a simple trap is all we need(?).
>I have t
Date: Fri, 14 Oct 2016 12:25:12 -0700
From: Matt Birkholz
Did I hear that VALUES might not be terribly expensive nor difficult
to implement? Taylor suggested a simple trap is all we need(?).
I have tried to work out the details here.
What I experimented with several years ago was
13 matches
Mail list logo
