>From e14436798deb8c9bb59273844d194c1bc4af6682 Mon Sep 17 00:00:00 2001
From: BT Templeton
Date: Tue, 22 Feb 2011 13:15:31 -0500
Subject: [PATCH] guile-snarf: allow multiple init actions on one line
* libguile/guile-snarf.in (modern_snarf): Allow programs to specify
multiple initialization actions on a single line. This
Andy Wingo writes:
> On Tue 22 Feb 2011 20:14, BT Templeton writes:
>
>> Guile-SDL contains some cpp macros that define multiple subrs. To allow
>> that, this patch modifies guile-snarf to recognize more than one
>> initialization action per line, which is n
Andy Wingo writes:
> If you are a Guile committer, think for a while about SoC-sized projects
> that you would like to mentor: things that you would like someone to do,
> about which you have ideas, and mail the ideas to the list.
I'd like to continue my work on the Emacs Lisp compiler. Some a
l...@gnu.org (Ludovic Courtès) writes:
> Saluton Brian,
>
> BT Templeton writes:
>
>> I'd like to continue my work on the Emacs Lisp compiler.
>
> Would be great!
>
>> Some areas that could use improvement:
>>
>> * Implement Emacs-compati
Hello all,
I've been accepted for GSoC 2011, and I'm excited to continue working
towards Guile-Emacs (: I'll be improving Guile's Emacs Lisp support and
will begin work on Emacs integration. I've included part of my project
proposal below.
Deliverables:
* Complete the Elisp subr library. Most of
Are the scm_remember_upto_here_* functions useful now that Guile uses
BDW-GC?
--
Inteligenta persono lernas la lingvon Esperanton rapide kaj facile.
Esperanto estas moderna, kultura lingvo por la mondo. Simpla, fleksebla,
belsona, Esperanto estas la praktika solvo de la problemo de universala
int
What is `*current-language*' supposed to be used for? I see that it's
set by `(@ (ice-9 eval-string) read-and-eval)' and by `(@ (system base
compile) read-and-compile)', but not by the REPL. So calling
`primitive-load-path' on a Scheme file from a REPL for another language
works as expected, but it
BT Templeton writes:
> What is `*current-language*' supposed to be used for? I see that it's
> set by `(@ (ice-9 eval-string) read-and-eval)' and by `(@ (system base
> compile) read-and-compile)', but not by the REPL. So calling
> `primitive-load-path' on
How are language environments (i.e., the values passed as `#:env'
arguments to the various compilation functions) supposed to be used?
Currently all languages use it as the value of the current module, but
would it be appropriate to use the environment value to keep track of
other compilation-unit-
Andy Wingo writes:
> On Sat 09 Jul 2011 22:30, BT Templeton writes:
>
>> How are language environments (i.e., the values passed as `#:env'
>> arguments to the various compilation functions) supposed to be used?
>> Currently all languages use it as the value of the
Noah Lavine writes:
> Hello,
>
> Guile's Summer of Code project this summer was an implementation of
> Emacs Lisp. I am curious - what is happening with that? Is it
> progressing?
>
> I follow the list, but haven't heard anything since the decision on
> which project we wanted.
It is! Here's a q
* module/system/repl/command.scm (trace): Set trace width to terminal
width by default.
---
module/system/repl/command.scm |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/module/system/repl/command.scm b/module/system/repl/command.scm
index a2f2a6f..98325cb 100644
--- a
Andy Wingo writes:
> Hi Mark,
>
> On Mon 18 Jul 2011 23:57, Mark H Weaver writes:
>
>> From an efficiency perspective, it is much more straightforward and
>> reliable for a compiler to understand what operation is done by
>> (fluid-ref x) than (x).
>
> This is true.
>
>> More generally, from a p
I noticed that when uninterned symbols are used as Tree-IL constants,
they're just dumped as normal (interned) symbols, which isn't useful for
Elisp or other languages with unhygienic macro systems. Is there a
particular reason there's no special handling for uninterned symbols in
`dump-object' in
l...@gnu.org (Ludovic Courtès) writes:
> Hi,
>
> BT Templeton skribis:
>
>> I noticed that when uninterned symbols are used as Tree-IL constants,
>
> I thought literal (constant) symbols in Elisp were interned. You seem
> to imply this isn’t always the case; can you
Mark H Weaver writes:
> Andy Wingo writes:
>>> * Is there any way to embed references to non-serializable objects in
>>> compiled code?
>>
>> No. Can you give an example of when you would want this?
[...]
> Furthermore, I'd suggest that _not_ serializing the objtable should be
> the default b
* module/language/tree-il/primitives.scm (resolve-primitives!): Resolve
public module-refs to primitives.
---
module/language/tree-il/primitives.scm | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/module/language/tree-il/primitives.scm
b/module/language/t
orrect; I just added a workaround for
the specific issue mentioned in the comment.
> On Mon, Mar 12, 2012 at 12:42 PM, BT Templeton wrote:
>> * module/language/tree-il/primitives.scm (resolve-primitives!): Resolve
>> public module-refs to primitives.
>> ---
>> module/
Noah Lavine writes:
> Hello,
>
>> I don't think I've changed the correctness wrt `module-set!' and the
>> like -- the current, private-refs-only optimization already exhibits the
>> problem you describe:
>>
>> | scheme@(guile-user)> (define old-car car)
>> | scheme@(guile-user)> (module-set! (cur
))
+
+ (pass-if-peval
+ ((@@ (guile) car) '(1 2))
+ (const 1)))
--
1.7.9.1
l...@gnu.org (Ludovic Courtès) writes:
> Hi BT,
>
> BT Templeton skribis:
>
>> * module/language/tree-il/primitives.scm (resolve-primitives!): Resolve
>> public module-refs to primi
Mark H Weaver writes:
> Hello all,
>
> I was chatting with the folks working on Python-on-Guile, and it seems
> clear that they need the ability to create GOOPS objects that can
> emulate procedures. Otherwise they will probably end up creating an
> entirely separate object system for Python, wh
Mark H Weaver writes:
> BT Templeton writes:
>
>> GOOPS defines an metaclass for this (similar
>> to AMOP's funcallable-standard-class):
>>
>> scheme@(guile-user)> (define-class ())
>> scheme@(guile-user)> ((make #:procedure car) '(1
As of 1 April 2012, GNU Guile's Elisp compiler fully supports the Dunnet
text adventure distributed with GNU Emacs. Dunnet is, of course, a key
feature distinguishing Emacs from its less capable competitors, so this
is an important milestone for the Guile-Emacs project.
To run dunnet, you'll need
l...@gnu.org (Ludovic Courtès) writes:
> Hi BT,
>
> The patch doesn’t apply currently on stable-2.0. Could you send an
> updated one, or apply it yourself?
It was a patch for master. Committed to stable-2.0 in commit
a8004dcb4d7148ec66cbaa109a18715d757700eb
--
Inteligenta persono lernas la lin
24 matches
Mail list logo
