Hi :)
On Sat 16 Nov 2019 16:26, Ludovic Courtès writes:
> Andy Wingo skribis:
>
>> On Fri 15 Nov 2019 10:03, Ludovic Courtès writes:
>>
>>> I guess we could add a specific ‘&type-exception’ exception or similar,
>>> which would allow us to improve error reporting (that can come later, of
>>> c
Hi Andy!
Andy Wingo skribis:
> On Fri 15 Nov 2019 10:03, Ludovic Courtès writes:
>
>> 0. Do I get it right that ‘throw’ and ‘catch’ are not “deprecated” in
>> the sense of (ice-9 deprecated) and are instead simply not the
>> “preferred” exception mechanism?
>
> Correct. I think we could envisi
Hey thanks for the review :)
On Fri 15 Nov 2019 10:03, Ludovic Courtès writes:
> 0. Do I get it right that ‘throw’ and ‘catch’ are not “deprecated” in
> the sense of (ice-9 deprecated) and are instead simply not the
> “preferred” exception mechanism?
Correct. I think we could envision deprecat
Hello Andy & all!
Thanks for the great summary.
I’ve taken a look at ‘wip-exceptions’, which is also remarkably easy to
follow because all the changes are incremental and follow the path you
explained in your message; thanks a lot for making it this clear!
I’ve very much support this change, I a
>> For the record, the bijection between R6RS conditions and Guile's throw
>> arguments was my work, not Julian's.
>
> An honest mistake on my part. My sincere apologies!
Thank you, Andy, I appreciate this. Thanks also for asking for input on
the mailing list. I'm heavily overloaded at the mome
On Sat 02 Nov 2019 06:20, Mark H Weaver writes:
> Andy Wingo writes:
>
>> So, now the pending task is to somehow get a condition/exception
>> hierarchy into Guile core. I will try to mostly push things off to side
>> modules but it won't always be possible. There will be bijections
>> between
Mark H Weaver writes:
> Andy Wingo writes:
>
>> [...] There will be bijections
>> between a Guile's "throw" arguments and structured exceptions, mostly
>> inspired with what Julian did in the R6RS layer already.
>
> For the record, the bijection between R6RS conditions and Guile's throw
> argume
Andy Wingo writes:
> So, now the pending task is to somehow get a condition/exception
> hierarchy into Guile core. I will try to mostly push things off to side
> modules but it won't always be possible. There will be bijections
> between a Guile's "throw" arguments and structured exceptions, mo
On Thu, 31 Oct 2019 17:20:37 +0100
Andy Wingo wrote:
> Greets :)
>
> On Thu 31 Oct 2019 01:01, Chris Vine writes:
>
> > "Condition" is a strange word for describing structured error objects,
> > I agree. However, I think it would be quite confusing to describe
> > error objects as exceptions.
Op wo 30 okt. 2019 21:55 schreef Andy Wingo :
>
>
> Thoughts welcome! Also: should these structured error objects be named
> exceptions or conditions? SRFI-35, R6RS, and R7RS say "conditions", but
> racket and my heart say "exceptions"; wdyt?
>
To my experience they are different things. An exc
Greets :)
On Thu 31 Oct 2019 01:01, Chris Vine writes:
> "Condition" is a strange word for describing structured error objects,
> I agree. However, I think it would be quite confusing to describe
> error objects as exceptions. "Error object" or "error condition object"
> seems a reasonable alt
Hey :)
On Thu 31 Oct 2019 15:17, Mikael Djurfeldt writes:
> How does the record subtyping relate to GOOPS? I do realize that there
> are issues related to keeping bootstrapping lean, but shouldn't record
> types and classes share mechanisms?
They share the struct layer.
Records are simple: the
Hello Andy,
> ...
> Thoughts welcome! Also: should these structured error objects be
> named exceptions or conditions? SRFI-35, R6RS, and R7RS say
> "conditions", but racket and my heart say "exceptions"; wdyt?
I personally prefer "exceptions" over "conditions", though I did read
and understand
Saying this without having looked at your code and also without currently
promising to do any work:
How does the record subtyping relate to GOOPS? I do realize that there are
issues related to keeping bootstrapping lean, but shouldn't record types
and classes share mechanisms?
Best regards,
Mikae
On Wed, Oct 30, 2019 at 4:55 PM Andy Wingo wrote:
>
> Thoughts welcome! Also: should these structured error objects be named
> exceptions or conditions? SRFI-35, R6RS, and R7RS say "conditions", but
> racket and my heart say "exceptions"; wdyt?
I think "exceptions" is a better name for the reas
Hi Andy! Thanks for all the work!
On Thu, Oct 31, 2019 at 4:55 AM Andy Wingo wrote:
> Hey folks!
>
> I wanted to send out an update on Guile 3. Do take a look at
> https://git.savannah.gnu.org/cgit/guile.git/tree/NEWS to see where we've
> come; basically the JIT is done, and we're ready to rele
On Wed, 30 Oct 2019 21:13:49 +0100
Andy Wingo wrote:
> Also: should these structured error objects be named
> exceptions or conditions? SRFI-35, R6RS, and R7RS say "conditions", but
> racket and my heart say "exceptions"; wdyt?
R6RS and R7RS speak of raising an exception, and handling the except
Hi Andy,
Wonderful update. I'll only comment on one thing.
Andy Wingo writes:
> Thoughts welcome! Also: should these structured error objects be named
> exceptions or conditions? SRFI-35, R6RS, and R7RS say "conditions", but
> racket and my heart say "exceptions"; wdyt?
Exceptions, since it'
Hey folks!
I wanted to send out an update on Guile 3. Do take a look at
https://git.savannah.gnu.org/cgit/guile.git/tree/NEWS to see where we've
come; basically the JIT is done, and we're ready to release soonish.
However! Here begins a long chain of yak-shaving:
I wanted good benchmarks. Gen
Hello,
Andy Wingo skribis:
> On Mon 17 Sep 2018 11:35, l...@gnu.org (Ludovic Courtès) writes:
>
>>> The threshold at which Guile will automatically JIT-compile is set from
>>> the GUILE_JIT_THRESHOLD environment variable. By default it is 5.
>>> If you set it to -1, you disable the JIT. If
Greets :)
On Mon 17 Sep 2018 11:35, l...@gnu.org (Ludovic Courtès) writes:
>> The threshold at which Guile will automatically JIT-compile is set from
>> the GUILE_JIT_THRESHOLD environment variable. By default it is 5.
>> If you set it to -1, you disable the JIT. If you set it to 0, *all*
>
Le lun. 17 sept. 2018 à 10:26, Andy Wingo a écrit :
> Hi!
>
> This is an update on progress towards Guile 3. In our last update, we
> saw the first bits of generated code:
>
> https://lists.gnu.org/archive/html/guile-devel/2018-08/msg5.html
>
> Since then, the JIT is now feature-complete.
Hello!
Andy Wingo skribis:
> This is an update on progress towards Guile 3. In our last update, we
> saw the first bits of generated code:
>
> https://lists.gnu.org/archive/html/guile-devel/2018-08/msg5.html
>
> Since then, the JIT is now feature-complete. It can JIT-compile *all*
> code
Hi!
This is an update on progress towards Guile 3. In our last update, we
saw the first bits of generated code:
https://lists.gnu.org/archive/html/guile-devel/2018-08/msg5.html
Since then, the JIT is now feature-complete. It can JIT-compile *all*
code in Guile, including delimited contin
On Mon, Aug 20, 2018 at 10:27 AM, Andy Wingo wrote:
> In this particular example, the JITted code runs about 3x faster than
> the interpreted code. The JIT doesn't do register allocation; not sure
> precisely how to do that. A future topic. For the moment I want to
> consolidate what we have an
Le ven. 24 août 2018 à 14:19, Christopher Lemmer Webber <
cweb...@dustycloud.org> a écrit :
> Andy Wingo writes:
>
> > In this particular example, the JITted code runs about 3x faster than
> > the interpreted code. The JIT doesn't do register allocation; not sure
> > precisely how to do that. A
Andy Wingo writes:
> In this particular example, the JITted code runs about 3x faster than
> the interpreted code. The JIT doesn't do register allocation; not sure
> precisely how to do that. A future topic. For the moment I want to
> consolidate what we have and once it's all just magically wo
Hi!
Last dispatch was here:
https://lists.gnu.org/archive/html/guile-devel/2018-07/msg00037.html
To recap, I merged in GNU lightning and added an extra machine-code
return address to frames, but hadn't actually written the JIT yet.
Since July, I made it so that all Guile bytecode function ent
Hi :)
Just a brief update with Guile 3. Last one was here:
https://lists.gnu.org/archive/html/guile-devel/2018-06/msg00026.html
There is a now a "lightning" branch that has GNU lightning merged in and
built statically into Guile. It causes about 1 MB of overhead in the
-Og libguile-3.0.so, b
dsm...@roadrunner.com wrote:
> Ok! now getting past the "make -j" issue, but I'm still getting a segfault.
And now commit e6461cf1b2b63e3ec9a2867731742db552b61b71 has gotten past the
segfault.
Wooo!
-Dale
Hi :)
On Mon 02 Jul 2018 11:28, l...@gnu.org (Ludovic Courtès) writes:
> Andy Wingo skribis:
>
>> My current plan is that the frame overhead will still be two slots: the
>> saved previous FP, and the saved return address. Right now the return
>> address is always a bytecode address. In the fut
Hello!
Andy Wingo skribis:
> The news is that the VM has been completely converted over to call out
> to the Guile runtime through an "intrinsics" vtable. For some
> intrinsics, the compiler will emit specialized call-intrinsic opcodes.
> (There's one of these opcodes for each intrinsic functio
Ok! now getting past the "make -j" issue, but I'm still getting a segfault.
Here is a backtrace from the core dump.
Line 25:
#25 0x7efeb518b09f in scm_error (key=0x563599bbb120, subr=subr@entry=0x0,
message=message@entry=0x7efeb521c0cd "Unbound variable: ~S",
args=0x563599f8f260,
rest=
Greetings Andy!
Andy Wingo wrote:
> Hi,
>
> Just wanted to give an update on Guile 3 developments. Last note was
> here:
>
> https://lists.gnu.org/archive/html/guile-devel/2018-04/msg4.html
>
> The news is that the VM has been completely converted over to call out
> to the Guile r
Hi,
Just wanted to give an update on Guile 3 developments. Last note was
here:
https://lists.gnu.org/archive/html/guile-devel/2018-04/msg4.html
The news is that the VM has been completely converted over to call out
to the Guile runtime through an "intrinsics" vtable. For some
intrinsics,
Hello all :)
This mail is an update on Guile 3 progress. Some previous updates were
here:
https://lists.gnu.org/archive/html/guile-devel/2018-01/msg9.html
https://lists.gnu.org/archive/html/guile-devel/2018-01/msg3.html
I took a break for a while and picked up this work again a coup
On Tue, Jan 16, 2018 at 4:55 PM, Andy Wingo wrote:
> Thinking more globally, there are some more issues -- one is that
> ideally we need call-site specialization. A GF could be highly
> polymorphic globally but monomorphic for any given call site. We need
> away to specialize.
>
Yes, but I ima
Greets,
FYI I wrote up a new update on the road to Guile 3; as I seem to be
getting closer, it's in blog form:
https://wingolog.org/archives/2018/01/17/instruction-explosion-in-guile
Cheers,
A
On Tue 09 Jan 2018 15:30, Mikael Djurfeldt writes:
> Maybe this is all completely obvious to you, but I want to remind,
> again, about the plans and ideas I had for GOOPS before I had to leave
> it at its rather prototypical and unfinished state:
>
> As you recall, generic functions (GFs) then ca
I'm aware that something similar can be achieved by different approaches.
But, note how these IMs are a nice compromise between two extremes: 1.
doing no inlining at all, leaving all function calls intact or 2. inlining
absolutely everything.
Of course such an IM based scheme could be supplemente
Hi,
Hi think this is a marvelous development and, for what it's worth, in the
right direction. Many, many thanks!
Maybe this is all completely obvious to you, but I want to remind, again,
about the plans and ideas I had for GOOPS before I had to leave it at its
rather prototypical and unfinished
Hey all!
This is an update along the road to Guile 3. Check
https://lists.gnu.org/archive/html/guile-devel/2017-11/msg00016.html for
the previous entry.
Since 25 November there have been around 100 commits or so. Firstly I
merged in patches from stable-2.0, including patches corresponding to
th
> (define (out-of-range x) (error "out of range" x))
> (define (not-int x) (error "expected an integer" x))
> (cond
>((fixnum? x)
> (if (<= -10 x 100)
> (* x 2)
> (out-of-range x)))
>((bignum? x)
> (if (<= -10 x 100)
> (* x 2)
> (out-of-range x)
Hi,
In the last update
(https://lists.gnu.org/archive/html/guile-devel/2017-11/msg00010.html) I
talked a lot about fixnums. This last couple weeks' work is along the
same lines.
Firstly I added support for specialized instructions that compare (in
the < or = sense) s64 and u64 values against 8-b
Hello Andy,
> An update on Guile 3 hackings over the past couple weeks.
> ...
> In summary, a lot of internal plumbing, for what appears to be preparatory
> work
> for future stuff.
I do not have the knowledge and background to make any valuable technical
comment,
but I wanted to thank you for
Hi,
An update on Guile 3 hackings over the past couple weeks.
Firstly I made a change to the CPS language. Before, "primcalls" --
invocations of primitives known to the compiler, some of which
ultimately compile to instructions/bytecode -- took all arguments as CPS
values. This was even the cas
Andy Wingo writes:
> Hi :)
>
> On Sun 22 Oct 2017 15:22, Christopher Allan Webber
> writes:
>
>> - Could native code compilation also be a step towards WASM, assuming
>>they lend us their GC?
>
> Regarding this question: yes! Specifically with the "GC" proposal
> (which in reality is much
Hi,
An update on the Guile 3 effort. Since last week I attacked the
conditional instructions, replacing e.g. "br-if-< A B OFFSET" with a
sequence of "
Hi :)
On Sun 22 Oct 2017 15:22, Christopher Allan Webber
writes:
> - Could native code compilation also be a step towards WASM, assuming
>they lend us their GC?
Regarding this question: yes! Specifically with the "GC" proposal
(which in reality is much more:
https://github.com/WebAssembl
Andy Wingo writes:
> Thoughts welcome if I have forgotten something. Cheers :)
Super exciting, Andy! I only have two thoughts:
- What an exciting future we have ahead of us!
- Could native code compilation also be a step towards WASM, assuming
they lend us their GC?
Woo woo, keep up the
Hi!
I have been thinking on how to get from where we are to good native
compilation. I think the next thing is instruction explosion. As
described here:
https://wingolog.org/archives/2016/02/04/guile-compiler-tasks
Currently in Guile's VM there are instructions like vector-ref.
Thi
51 matches
Mail list logo
