On Tue, Jan 28, 2020 at 11:41 PM Han-Wen Nienhuys wrote:
> Unfortunately, it looks like the adoption of the BDW GC library caused
> a ~6x slowdown, causing an overall end-to-end slowdown of 50%.
>
> I was wondering if you folks would have tips to further tune GC for
> wall-time speed, and if there
Here is an example that shows better how things work, and what might
be the cause of my problems. Is it right that programmatically set
contents of "current-module" are not serialized into the compiled
file?
(define (run-at-compile-time cmd)
(module-define! (current-module) (string->symbol
+lilypond-devel for visibility.
On Sat, Feb 1, 2020 at 10:54 AM Han-Wen Nienhuys wrote:
>
> Here is an example that shows better how things work, and what might
> be the cause of my problems. Is it right that programmatically set
> contents of "current-module" are not serialized into the compiled
Han-Wen Nienhuys writes:
> +lilypond-devel for visibility.
>
> On Sat, Feb 1, 2020 at 10:54 AM Han-Wen Nienhuys wrote:
>>
>> Here is an example that shows better how things work, and what might
>> be the cause of my problems. Is it right that programmatically set
>> contents of "current-module"
Linus Björnstam writes:
> Guile1.8's macros are run-time macros: they are executed directly and
> not transformed to output code that is then compiled. That is the
> reason why your code works: to newer guiles the (inner ...) is only
> available at expansion time. The macro output is trying to ca
On Sat, Feb 1, 2020 at 11:11 AM David Kastrup wrote:
> >> Here is an example that shows better how things work, and what might
> >> be the cause of my problems. Is it right that programmatically set
> >> contents of "current-module" are not serialized into the compiled
> >> file?
> >>
> >>(def
Han-Wen Nienhuys writes:
> On Sat, Feb 1, 2020 at 11:11 AM David Kastrup wrote:
>> >> Here is an example that shows better how things work, and what might
>> >> be the cause of my problems. Is it right that programmatically set
>> >> contents of "current-module" are not serialized into the compi
Did you try just expanding it to a define? Or just output a module-define! at
runtime and run a module-define! at compile time.
--
Linus Björnstam
On Sat, 1 Feb 2020, at 10:54, Han-Wen Nienhuys wrote:
> Here is an example that shows better how things work, and what might
> be the cause of m
On Sat, 1 Feb 2020, at 12:09, David Kastrup wrote:
>
> Can you expand about the "expansion time and macro time separation"?
>
> If we have
>
> (define decl '())
> (define (make-var n v) (list "var" n v))
> (defmacro define-session (name value)
> (define (inner n v)
> (set! decl
>
Linus Björnstam writes:
> On Sat, 1 Feb 2020, at 12:09, David Kastrup wrote:
>>
>> Can you expand about the "expansion time and macro time separation"?
>>
>> If we have
>>
>> (define decl '())
>> (define (make-var n v) (list "var" n v))
>> (defmacro define-session (name value)
>> (define (in
tried it in a couple of syntax-case-enabled schemes (defmacro is implemented
using syntax-case in guile) and it doesn't work anywhere. The procedure ends up
undefined everywhere.
The # object ,inner points to doesn't exist at runtime because it is
not defined anywhere in any meaningful way to t
> (defmacro define-session (name value)
> (define (inner n v)
> (set! decl
> (cons
> (make-var n v)
> decl))
> )
> `(,inner ',name ,value))
The problem here is that the macro output
`(,inner ',name ,value)
would include a # object, because it evaluates 'in
(Duplicate of the mail I sent to guile-devel before realizing you're not
on the list.)
> (defmacro define-session (name value)
> (define (inner n v)
> (set! decl
> (cons
> (make-var n v)
> decl))
> )
> `(,inner ',name ,value))
The problem here is that the mac
13 matches
Mail list logo
