Hi Christine,
On Friday, October 22, 2021 12:17 EDT, Christine Lemmer-Webber
wrote:
> Christine Lemmer-Webber writes:
> > I missed earlier in the thread that Gregg said that we should use
> > --disable-jit. Once I did that it was fine. So ignore this bit!
> >
> > - Christine
>
> It wasn't t
Christine Lemmer-Webber writes:
> Well, *something* isn't ready to go:
>
> scheme@(guile-user)> (+ 1 2)
> $3 = 3
> scheme@(guile-user)> ,L elisp
> Happy hacking with Emacs Lisp! To switch back, type `,L scheme'.
> elisp@(guile-user)> (+ 1 2)
> $4 = 3
> elisp@(guile-user)> (cons 'foo '())
> $25 =
Christine Lemmer-Webber writes:
> Christine Lemmer-Webber writes:
>
>> Well, *something* isn't ready to go:
>>
>> scheme@(guile-user)> (+ 1 2)
>> $3 = 3
>> scheme@(guile-user)> ,L elisp
>> Happy hacking with Emacs Lisp! To switch back, type `,L scheme'.
>> elisp@(guile-user)> (+ 1 2)
>> $4 = 3
Robin Templeton writes:
> Christine Lemmer-Webber writes:
>
>> Ludovic Courtès writes:
>>
>>> Hello!
>>>
>>> Christine Lemmer-Webber skribis:
>>>
I've pushed this as origin/wip-elisp-rebased. I actually rebased it
again, making some naming adjustments for myself and a couple of
Christine Lemmer-Webber writes:
> Ludovic Courtès writes:
>
>> Hello!
>>
>> Christine Lemmer-Webber skribis:
>>
>>> I've pushed this as origin/wip-elisp-rebased. I actually rebased it
>>> again, making some naming adjustments for myself and a couple of
>>> adjustments having talked to Robin.
>
"Gregg Sangster" writes:
> Hello,
>
> I have wip-elisp rebased all the way up to main as of a few days ago
> (e60469c8b6936575c079faaffa40a340e1d49f3c) plus two changes from
> Ricardo. It's available here:
>
> https://git.sr.ht/~g20r/guile
>
> There is one test failure in "make check" on test-ou
Hi Gregg,
On Thursday, October 14, 2021 13:34 EDT, Ricardo Wurmus
wrote:
I also had he same experience. Guile Emacs would segfault very
quickly. That’s why I started a rebase on top of the nearest
Emacs release, which is 25.2. I had to abandon the rebase,
because after about 45 commits
Christine Lemmer-Webber writes:
> Ludovic Courtès writes:
>
>> Hello!
>>
>> Christine Lemmer-Webber skribis:
>>
>>> I've pushed this as origin/wip-elisp-rebased. I actually rebased it
>>> again, making some naming adjustments for myself and a couple of
>>> adjustments having talked to Robin.
>
"Dr. Arne Babenhauserheide" writes:
> The workload to finish this is considerable, though: IIRC You’ll need to
> solve some deeper problems that prevent Guile Emacs from using
> byte-compiled files (that’s why it currently has a very high startup
> time).
To clarify, Guile-Emacs intentionally di
still
> upstream interest.
>From my perspective, it certainly is! There is plenty of interest from
the Guile side AFAICT; the Emacs maintainers have been (understandably)
skeptical about the project in general, but if we can make it correct
*and* fast I think they'll be more interested, especiall
Hi Ricardo,
On Thursday, October 14, 2021 13:34 EDT, Ricardo Wurmus
wrote:
> I also had he same experience. Guile Emacs would segfault very
> quickly. That’s why I started a rebase on top of the nearest
> Emacs release, which is 25.2. I had to abandon the rebase,
> because after about 45 comm
Hi Christine,
Thanks for looking at this! I just noticed that my email address as the
committer on 1ba3d7854cac0524f80d3c6113da770505c9eda9 is incorrect. Before
merging, can you please change it to gr...@thesangsters.ca?
On Tuesday, October 19, 2021 17:59 EDT, Christine Lemmer-Webber
wrote:
Christine Lemmer-Webber writes:
> Ludovic Courtès writes:
>
>> Hello!
>>
>> Christine Lemmer-Webber skribis:
>>
>>> I've pushed this as origin/wip-elisp-rebased. I actually rebased it
>>> again, making some naming adjustments for myself and a couple of
>>> adjustments having talked to Robin.
>
Ludovic Courtès writes:
> Hello!
>
> Christine Lemmer-Webber skribis:
>
>> I've pushed this as origin/wip-elisp-rebased. I actually rebased it
>> again, making some naming adjustments for myself and a couple of
>> adjustments having talked to Robin.
>>
>> If nobody objects, I'd like to merge th
Hello!
Christine Lemmer-Webber skribis:
> I've pushed this as origin/wip-elisp-rebased. I actually rebased it
> again, making some naming adjustments for myself and a couple of
> adjustments having talked to Robin.
>
> If nobody objects, I'd like to merge this into main. Maintainers, if
> you
I've pushed this as origin/wip-elisp-rebased. I actually rebased it
again, making some naming adjustments for myself and a couple of
adjustments having talked to Robin.
If nobody objects, I'd like to merge this into main. Maintainers, if
you have any objections, speak now or forever hold these c
This is awesome.
So, what's stopping us from merging this into guile main now before it
bitrots again? :)
"Gregg Sangster" writes:
> Hi Ricardo,
>
> Thanks, your changes fixed a couple of the test errors I saw.
>
> On Monday, September 13, 2021 06:56 EDT, Ricardo Wurmus
> wrote:
>
>>
>
Hi Gregg,
"Gregg Sangster" writes:
I have wip-elisp rebased all the way up to main as of a few days
ago (e60469c8b6936575c079faaffa40a340e1d49f3c) plus two changes
from Ricardo. It's available here:
https://git.sr.ht/~g20r/guile
Excellent!
There is one test failure in "make check" on te
Hello,
I have wip-elisp rebased all the way up to main as of a few days ago
(e60469c8b6936575c079faaffa40a340e1d49f3c) plus two changes from Ricardo. It's
available here:
https://git.sr.ht/~g20r/guile
There is one test failure in "make check" on test-out-of-memory. I haven't
investigated it
Hi Ricardo,
Thanks, your changes fixed a couple of the test errors I saw.
On Monday, September 13, 2021 06:56 EDT, Ricardo Wurmus
wrote:
>
> Hi Gregg,
>
> > I've rebased the wip-elisp branch on top of commit
> > 449f50dd84a081aea16ef678e32bf37abe429ff6 (git describe:
> > v3.0.4-64-g33232cb5c4
Hello,
Just my 2 cents as a drive-by watcher: I agree that having wip-elisp branch in
guile tree would be nice to have, this way it's easier to find out where
progress is being made for this endeavour, with potentially a checked out TODO
or TASKS file to see if I can ever help (if only with tes
Hi Gregg,
I've rebased the wip-elisp branch on top of commit
449f50dd84a081aea16ef678e32bf37abe429ff6 (git describe:
v3.0.4-64-g33232cb5c4). It's published here:
https://git.sr.ht/~g20r/guile
FWIW I had also rebased wip-elisp in 2020:
https://git.elephly.net/?p=software/guile.git;a=
"Dr. Arne Babenhauserheide" writes:
> [[PGP Signed Part:Undecided]]
> Hello Gregg,
> "Gregg Sangster" writes:
>
>> I've rebased the wip-elisp branch on top of commit
>> 449f50dd84a081aea16ef678e32bf37abe429ff6 (git describe:
>> v3.0.4-64-g33232cb5c4). It's published here:
>>
>> https://git.sr.h
Hello Gregg,
"Gregg Sangster" writes:
> I've rebased the wip-elisp branch on top of commit
> 449f50dd84a081aea16ef678e32bf37abe429ff6 (git describe:
> v3.0.4-64-g33232cb5c4). It's published here:
>
> https://git.sr.ht/~g20r/guile
I’m not a Guile core developer, but I think that this is awesom
Hello Guile Hackers,
I've rebased the wip-elisp branch on top of commit
449f50dd84a081aea16ef678e32bf37abe429ff6 (git describe: v3.0.4-64-g33232cb5c4).
It's published here:
https://git.sr.ht/~g20r/guile
There are two additional failed tests which appear to be new tests added since
the last w
Hello Guile Hackers,
I've rebased the wip-elisp branch on top of commit
449f50dd84a081aea16ef678e32bf37abe429ff6 (git describe: v3.0.4-64-g33232cb5c4).
It's published here:
https://git.sr.ht/~g20r/guile
There are two additional failed tests which appear to be new tests added since
the last w
Hello Guile Hackers,
I've rebased the wip-elisp branch on top of commit
449f50dd84a081aea16ef678e32bf37abe429ff6 (git describe: v3.0.4-64-g33232cb5c4).
It's published here:
https://git.sr.ht/~g20r/guile
There are two additional failed tests which appear to be new tests added since
the last w
I will just let you know that
abs((- i1 i2)) does not work is some cases on 3.0.7 , i will track this
down a bit more but later
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
gards,
Mikael
On Wed, Oct 30, 2019 at 9:55 PM 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 relea
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
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
Hi Arne,
Arne Babenhauserheide writes:
> I don’t understand the implications of this, but I realized that I would
> love to have info about the sizes of different datastructures in Guile.
Sure.
> I recently started measuring how much memory is required for a record
> compared to a list, so I c
Hi,
Mark H Weaver skribis:
> Ludovic Courtès writes:
>> Though an immediate, like a fixnum or an iflo, is still something
>> different from a tagged heap object like a pair, right? So I would
>> expect SCM_THOB_P to be a different test, not a drop-in replacement for
>> SCM_NIMP, is that correc
Ludovic Courtès writes:
> Though an immediate, like a fixnum or an iflo, is still something
> different from a tagged heap object like a pair, right?
I should clarify that in this new approach, a pair is *not* a tagged
heap object. Tagged heap objects are those which have a tag in their
first wo
Hi Ludovic,
Ludovic Courtès writes:
> Though an immediate, like a fixnum or an iflo, is still something
> different from a tagged heap object like a pair, right? So I would
> expect SCM_THOB_P to be a different test, not a drop-in replacement for
> SCM_NIMP, is that correct?
That's right. It's
Hello,
Mark H Weaver skribis:
> Ludovic Courtès writes:
[...]
>> IIUC, your plan is to have a different tagging on 32-bit platforms,
>> without fixflos, right? I’m curious to see how much complexity would
>> entail from that.
>
> Yes, although I'm avoiding the term "fixflos" because IEEE dou
I should mention that I'm very open to suggestions Andy might have about
any of this. The new approach I'm currently working on with tagged pair
pointers requires changes to both the VM and the compiler, and I'm not
confident that I've made the best choices there. I've made some
preliminary choic
Hi Ludovic,
Ludovic Courtès writes:
> As Dave Thompson wrote on IRC yesterday, this can make a significant
> difference for applications such as graphics and game engines.
Yes, it's especially important to be able to avoid heap allocation in
games, where GC pauses can be painful. However, any a
> On 8 Jun 2019, at 11:08, Chris Vine wrote:
>
> On Sat, 08 Jun 2019 10:07:45 +0200
> Arne Babenhauserheide wrote:
> [snip]
>> Wow, I didn’t know that you could do that.
>>
>> However: "The details of that allocation are implementation-defined, and
>> it's undefined behavior to read from the
On Sat, 08 Jun 2019 11:46:10 +0200
Arne Babenhauserheide wrote:
> Chris Vine writes:
> > On Sat, 08 Jun 2019 10:07:45 +0200
> > Arne Babenhauserheide wrote:
> > [snip]
> >> Wow, I didn’t know that you could do that.
> >>
> >> However: "The details of that allocation are implementation-defined,
Chris Vine writes:
> On Sat, 08 Jun 2019 10:07:45 +0200
> Arne Babenhauserheide wrote:
> [snip]
>> Wow, I didn’t know that you could do that.
>>
>> However: "The details of that allocation are implementation-defined, and
>> it's undefined behavior to read from the member of the union that wasn
On Sat, 08 Jun 2019 10:07:45 +0200
Arne Babenhauserheide wrote:
[snip]
> Wow, I didn’t know that you could do that.
>
> However: "The details of that allocation are implementation-defined, and
> it's undefined behavior to read from the member of the union that wasn't
> most recently written." htt
Mark H Weaver writes:
> Mark H Weaver writes:
>
>> Here's the format of fixrats on 64-bit systems:
…
> This allows for an elegant packing operation:
>
> if (SCM_I_INUMP (numerator) && SCM_I_INUMP (denominator))
> {
> union { double f; uint64_t u; } u;
> u.f = SCM_I_INUM (num
Mark H Weaver writes:
> Here's the format of fixrats on 64-bit systems:
>
> Srrx0111
> |\/\___/\__/
> | | | |
> | rank (6 bits
Hi Mark,
Mark H Weaver skribis:
> I've found a way to efficiently support both immediate IEEE binary-64
> doubles up to ~1.158e77 (with larger ones transparently allocated on the
> heap), and also immediate exact rationals with up to 54 binary digits
> (~16 decimal digits), without restricting t
On Thu, Jun 06, 2019 at 05:40:39AM -0400, Mark H Weaver wrote:
> I've found a way to efficiently support both immediate IEEE binary-64
> doubles up to ~1.158e77 (with larger ones transparently allocated on the
> heap), and also immediate exact rationals with up to 54 binary digits
> (~16 decimal di
Mark H Weaver writes:
> I have a working draft implementation that roughly doubles the speed of
> a simple "substract 1.0 until negative" loop for inexact reals less than
> 2^256, compared with current 'master' (near 2.9.2). The same loop for
> exact rationals runs in ~70% of the time compared w
Earlier I wrote:
> There's also a nice way to extract the denominator from a fixrat: mask
> out the sign bit, shift right 5 bits, and interpret it as an IEEE
> double. The denominator will be the integer part of the resulting
> value, with the numerator in the fraction bits. Simply cast this dou
I've found a way to efficiently support both immediate IEEE binary-64
doubles up to ~1.158e77 (with larger ones transparently allocated on the
heap), and also immediate exact rationals with up to 54 binary digits
(~16 decimal digits), without restricting the 64-bit pointer space at
all, and without
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
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 ca
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
date what we have and once it's all just magically working and
> everybody's programs are faster, we release Guile 3.
Echoing everyone else: This is very exciting! I can't wait to take it
for a spin. Thank you!
- Dave
; > 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 working and
> > everybody's programs are faster, we release Guile 3.
>
> This is great news! Very excited about Guile 3 over here! :
7;s all just magically working and
> everybody's programs are faster, we release Guile 3.
This is great news! Very excited about Guile 3 over here! :)
ter 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 working and
everybody's programs are faster, we release Guile 3.
Cheers,
Andy
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 libgu
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
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
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
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
her
> easily be implemented. That is, we re-introduce IMs, make them directly
> callable, and substitute IM calls for GF calls when compiling them. I
> gather that the code of IMs do not necessarily have to be hung onto GFs but
> could be handled by some separate manager/data structures.
>
gt;
> 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 pat
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
> (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
> On Nov 24, 2017, at 3:42 PM, Christopher Allan Webber
> wrote:
>
> Matt Wette writes:
>
>> Here are a couple desires:
>>
>> 1) more cases for cond-expand, in case 3.2 has items 3.0 does not (e.g.,
>> srfi-199)
>>
>> 2) better debugging.
>> Maybe I'm not doing it right, but I struggle
Matt Wette writes:
> Here are a couple desires:
>
> 1) more cases for cond-expand, in case 3.2 has items 3.0 does not (e.g.,
> srfi-199)
>
> 2) better debugging.
>Maybe I'm not doing it right, but I struggle in this area: I mostly resort
> to printing.
>For example, add scheme level ho
Here are a couple desires:
1) more cases for cond-expand, in case 3.2 has items 3.0 does not (e.g.,
srfi-199)
2) better debugging.
Maybe I'm not doing it right, but I struggle in this area: I mostly resort
to printing.
For example, add scheme level hook, or command arg, to turn off opti
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 t
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 wa
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
100 matches
Mail list logo
