em on Fedora 35, with Guile 2.2.7 and libgc 8.0.4)
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Sun, Feb 14, 2021 at 11:35 AM Han-Wen Nienhuys wrote:
> >> Thanks. It turns out my previous fix introduced ABI
> >> breakage, so I reworked it to not change function
> >> signatures or struct sizes. It's also split up in more
> >>
On Wed, Feb 10, 2021 at 11:18 PM Thien-Thi Nguyen wrote:
>
>
> () Han-Wen Nienhuys
> () Tue, 9 Feb 2021 09:59:07 +0100
>
>> Thanks. It turns out my previous fix introduced ABI
>> breakage, so I reworked it to not change function
>> signatures or st
On Sun, Jan 17, 2021 at 7:37 PM Han-Wen Nienhuys wrote:
> On Sun, Jan 17, 2021 at 12:10 AM Thien-Thi Nguyen wrote:
> >your timing is fortuitous. I just spent the christmas
> >holidays delving into GUILE 1.8's heap expansion strategy and
> >fou
On Sun, Jan 17, 2021 at 12:10 AM Thien-Thi Nguyen wrote:
>
>
> () Han-Wen Nienhuys
> () Tue, 12 Jan 2021 09:20:55 +0100
>
>your timing is fortuitous. I just spent the christmas
>holidays delving into GUILE 1.8's heap expansion strategy and
>
work these days?
I'd be happy to polish it up (ie. add a proper test) for inclusion in
GUILE 1.8.9,
cheers,
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
statprof.scm:251:4
6.7% #x2212b88
Is there a way to get insight into what these hex addresses (?) mean?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
> `(define q "i am Q\n"))
>
> This is very much expected. The macro body contains two side-effect
> free expressions (namely quoted lists) and returns the last one which is
..
> You probably wanted something like
> `(begin (define p ...) (define q ...))
d'oh! I am an idiot.
Thanks,
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
blic my-macro-new (command-and-args . definition)
`(define p "i am P\n")
`(define q "i am Q\n"))
(my-macro-old 1 2)
(my-macro-new 1 2)
(display x1)
(display x2)
(display q)
(display p)
thanks,
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
>
No, I think it's because in some phases of the program, there is a lot of
heap growth, with little garbage generation. This causes frequent
(expensive) GCs that don't reclaim anything.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
ub.com/lilypond/lilypond/blob/c5ffa540fdbe52486b9575567ede70be575adb47/scm/define-markup-commands.scm#L305
and seeing how the error message changes.
I still don't understand why some code is executed compile time (the
expansion of the markup macro) while other is not (defining the
make-x-mar
+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 n
That seems to be a documentation bug. Try fiddling with the
> arguments to eval when and see if you can make it work.
>
> --
> Linus Björnstam
>
> On Fri, 31 Jan 2020, at 20:17, Han-Wen Nienhuys wrote:
> > On Fri, Jan 31, 2020 at 7:20 PM Linus Björnstam
> > wrote
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-tim
ri Jan 31 20:15:58+0100 2020
[hanwen@localhost lilypond]$ guile2.2 e.scm
Fri Jan 31 20:16:00+0100 2020
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
(set ! ...
> (inner ,name ,value))
>
> I doubt you can make the old code work in newer guiles, since I doubt any
> scheme is a s lax about expansion time and macro time separation.
> --
> Linus Björnstam
>
> On Wed, 29 Jan 2020, at 00:08, Han-Wen Nienhu
Is it possible to attach doc strings to (define-syntax .. )
declarations, and if so, where do they go?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Thu, Jan 30, 2020 at 9:05 AM Han-Wen Nienhuys wrote:
>
> [guile1.8]$ grep -ir define-syntax-rule .
>
> (empty)
>
> I need something that works in GUILE 1.8 too.
>
> this is what I got from David Kastrup:
>
> >Got any comments about macros being sooo yes
in why I get this error message?
On Wed, Jan 29, 2020 at 4:06 PM Ricardo Wurmus wrote:
>
>
> Han-Wen Nienhuys writes:
>
> > Some of the lilypond Scheme files do the following:
> >
> >
> > (define decl '())
> > (define (make-var n v) (list "var&qu
he numbers that support this; can somebody point
me to them? From where I stand, it looks like a huge performance
regression.
On Tue, Jan 28, 2020 at 11:41 PM Han-Wen Nienhuys wrote:
>
> Hi folks,
>
> after a long hiatus I have started getting involved with LilyPond
> again,
define-session foo 1)
(display decl)
(newline)
In GUILE 2.2, this yields
;;; WARNING: compilation of /home/hanwen/vc/lilypond/q.scm failed:
;;; unhandled constant #
What does this error message mean, and what should I do to address the problem?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
additional diagnostics to see if we're
doing something extraordinarily silly.
I already found the GC_free_space_divisor, but I already tuned to its
fastest value, 1.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
/Code-Coverage.html
- perhaps you can work out a way with the guile folks to resurrect
lilypond's test coverage code.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
e to 2.0 (2.0 supports boehm GC, right?)
> 4. We've already seen the %module-public-interface thing in the Lily C++.
> There's probably more smelly stuff lurking in the C++ interface, which
> won't surface until we start trying to use Guile 2.0 more.
There may be lots of hairiness in the module interface; I sort of made
up functions as I went along, since it was largely undocumented.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
the majority of the time in this
> function is in the SCM_GC_MARK_P line.
Well, GC_MARK_P is bit fiddling a pointer dereference, with a possible cache
miss.
Also, the code up to that point will get executed much more often than what
follows.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
(expr, tail);
which is very dubious if a thread switch happens at (*)
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
release that passes the tests is good.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
de is definitely worth it.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Guile's repo at Savannah be a good fit?).
I recommend you push a branch to savannah, for everyone to see what is
happening.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Han-Wen Nienhuys escreveu:
> Ludovic Courtès escreveu:
>> Hello Guilers!
>>
>> Below are some of the points (in no particular order) that IMO can make
>> it worthwhile to use the Boehm-Demers-Weiser GC [0] in Guile instead of
>> Guile's historical GC, from an
scrapping code; here are my concerns:
- what is the performance impact?
- does BDW GC handle weak references correctly?
- What about various (undoubtedly little used) areas where GC interacts
with the interpreter: port de-allocation, guardians, etc.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
`LTALLOCA' is undefined
lib/Makefile.am: installing `build-aux/depcomp'
configure.in:51: required file `config.h.in' not found
configure.in:86: required file `build-aux/ltmain.sh' not found
[EMAIL PROTECTED] guile-x]$ echo $?
1
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Ping?
Han-Wen Nienhuys escreveu:
> Ludovic Courtès escreveu:
>>>> Yes, fine by me, but no rush. ;-)
>>> Do you mean anything specific by "no rush" here?
>> I just meant I'm not gonna do it Right Now but that's fine by me if
>> so
Ludovic Courtès escreveu:
>>> Yes, fine by me, but no rush. ;-)
>> Do you mean anything specific by "no rush" here?
>
> I just meant I'm not gonna do it Right Now but that's fine by me if
> somebody else does.
Please see dev/hanwen on savannah.
--
Do we have a consensus?
Ludovic Courtès escreveu:
>> The GH interface was marked as deprecated in
>> * Explain GH deprecation & plan for scm documentation.
>>
>>
>> Let's really drop it now.
>
> Why? It doesn't cost much to keep it, do
Ludovic Courtès escreveu:
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> The GH interface was marked as deprecated in
>>
>> commit a0143ebc24c24198e0dfce9b80f3648feb706226
>> Author: Neil Jerram <[EMAIL PROTECTED]>
>> Date: Wed Jun 20 22:08:
cal variables to see where all that memory is going. Also, look at
the preprocessed source and scan for array variables.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
The GH interface was marked as deprecated in
commit a0143ebc24c24198e0dfce9b80f3648feb706226
Author: Neil Jerram <[EMAIL PROTECTED]>
Date: Wed Jun 20 22:08:19 2001 +
* Explain GH deprecation & plan for scm documentation.
Let's really drop it now.
--
Han-Wen Ni
ke a good opportunity to take all
these variable private, and have people use gc-stats to get the data.
Providing direct access to variables is problematic from an API stability
point of view.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
ore exact name.
> BTW, can you add a one-line summary to the log, as is done on `master',
> `vm', etc.?
The custom is (see git-format-patch) that the subject line is the summary.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
* libguile/gc.c (scm_i_gc): Change assert into deprecation warning.
* libguile/private-gc.h (nil): introduce scm_i_last_marked_cell_count,
as a private mechanism for maintaining cell counts. Previous
versions incremented scm_cells_allocated in an inlined function, so
loading dynamic object
Ludovic Courtès escreveu:
> Hi,
>
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> i686-mingw32-gcc -mms-bitfields -DHAVE_CONFIG_H
>> -I/home/lilydev/vc/gub/target/mingw/src/guile-1.9.git -I..
>> -I/home/lilydev/vc/gub/target/mingw/src/guile-1.9.
Ludovic Courtès escreveu:
> Hi,
>
> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>
>> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>>> Han-Wen Nienhuys escreveu:
>>>> Ludovic Courtès escreveu:
>>>>> +/*
>>>>> + Cla
verse: ensuring that the non-mark phase is correct (in
not having mark calls), but I couldn't think of a good name.
> * Use "static const char msg[] = ...".
done.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Ludovic Courtès escreveu:
> Hello,
>
> Is anyone against getting rid of `AM_MAINTAINER_MODE'?
>
> If in doubt, see (info "(automake) maintainer-mode"). :-)
Getting rid of anything that starts with AM_ has my full support.
--
Han-Wen Nienhuys - [EMAIL PRO
Andy Wingo escreveu:
> On Tue 09 Sep 2008 07:58, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> Is there any code in GUILE that would create a thread (possibly
>> leading to race conditions) when there is no explicit start-thread
>> call in the code? The progr
On Tue, Sep 9, 2008 at 4:00 AM, Andy Wingo <[EMAIL PROTECTED]> wrote:
> On Tue 09 Sep 2008 07:58, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> Is there any code in GUILE that would create a thread (possibly
>> leading to race conditions) when there is no explic
sibly
leading to race conditions) when there is no explicit start-thread
call in the code? The program (lilypond) does run through the
regular GUILE boot procedure.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
ned tradition of updating
> `NEWS' when changing something in a branch! :-)
Well, yes, but we also have many commits that are identified as
"Changes from Arch/CVS synchronization"
and
"merge from 1.8"
I tend to look at development history with gitk. I
Neil Jerram escreveu:
> 2008/9/7 Han-Wen Nienhuys <[EMAIL PROTECTED]>:
>> OK - I will admit that interpreter/GC hacking is cool, but on the
>> downside, when I try to do anything, the intertia/resistance I feel in
>> the community here is a big turnoff for me.
>
&g
Neil Jerram escreveu:
> 2008/9/2 Han-Wen Nienhuys <[EMAIL PROTECTED]>:
>> If you are doing memq? for something you already know to
>> somewhere in front of the list [...]
>
> Why would you do that? In two senses:
>
> 1. I know memq gives you the tail of the lis
ing this for Guile? (We need to figure out how to set it up, and
contributors need to have gmail addresses, but that should not be a problem,
is it?)
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
or the 1.8 release before I could do
this.
If anything, my impression so far is that the objective is to produce
a piece of perfect code (with pretty linear history graphs and GNU
compliant commit messages!) without a desire to actually ship
anything.
So, what are the goals in this group?
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Neil Jerram escreveu:
> 2008/9/7 Han-Wen Nienhuys <[EMAIL PROTECTED]>:
>> I am not using and enhancing GUILE primarily for fun. A large part of
>> the lilypond architecture in written in it, and performance problems
>> in GUILE often translate directly to problems in
doing his
job, GUILE will be left with a bunch of weird code that noone knows
how to deal with.
All this also makes me wonder why there are no Gnucash developers
here, since I recall they actually do use GUILE for a lot of stuff.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
sidering the
amount of time I sank into it. I seriously looked into moving lily to
mzscheme, but I lack the bandwidth to do that now.
I hope you can understand that I have a somewhat different basic
attitude wrt GUILE development.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Andy Wingo escreveu:
> On Sun 31 Aug 2008 17:12, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> On a tangent, is anyone still seriously considering to run Emacs atop GUILE?
>> (It looks a bit like a travesty if we're trying to accomodate elisp while
>> also t
Ludovic Courtès escreveu:
> Hi,
>
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> Please check dev/hanwen for changes.
>
> The `HACKING' changes looks good overall, thank you! The "complete
> description in the commit message" should rath
Ludovic Courtès escreveu:
> Hi,
>
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> Ludovic Courtès escreveu:
>
>>> Note that what we agreed on was to provide ChangeLog-style comments in
>>> the Git log entry, which this patch doesn't have.
&
Ludovic Courtès escreveu:
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> Pushed (without changelog entry).
>
> Note that what we agreed on was to provide ChangeLog-style comments in
> the Git log entry, which this patch doesn't have.
Can you explain me e
Han-Wen Nienhuys escreveu:
>>> ERROR: srfi-18.test: thread-start!:
>>> thread activates only after start
>>>- arguments: ((syntax-error "memoization"
>>> "In file ~S, line ~S: ~A ~S in expression ~S."
>>>
ut of sight.
comments?
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
I think it's not a good solution.
>>
>> Commenting out the assert for x86-64 should yield better behavior.
>
> Alright, then please go ahead.
Pushed (without changelog entry).
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
oved was not equally likely to be
> anywhere along the list.)
All these functions are O(n), but by prefixing the list check
you're doubling the running time (eg. in the case of reverse!).
If you are doing memq? for something you already know to
somewhere in front of the list, the list? check will slow
it down much worse.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
track of which files have
> seen significant changes in the new year and which have not. It is
> recommended and simpler to add the new year to all files in the
> package, and be done with it for the rest of the year.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
;inits);
{
const SCM new_body = m_body (SCM_IM_LET, SCM_CDR (cdr_expr));
const SCM new_tail = scm_cons2 (rvariables, inits, new_body);
SCM_SETCAR (expr, SCM_IM_LET);
// !!!
SCM_SETCDR (expr, new_tail);
What happens if another thread tries to evaluate expr at the place marked
!!! ?
At the very least, we should have an atomic SCM_SETCELL() which overwrites car
and
cdr atomically.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
e Software Foundation, Inc.
Can we do this in one fell swoop, adding 2008 to all files? After all
publishing
a commit is a release in some sense. Then, we don't have to worry about the
file
headers anymore.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
very scary looking explanation in eval.c about the
evaluator being unlocked but still thread-safe since the result of memoizing
was supposed to be confluent (ie. duplicate runs would yield independent
results.)
/* The Lookup Car Race
- by Eva Luator
This was added by Marius Vollmer, but at the time, GUILE did not support
real posix threads, so any problem may not have manifested itself before.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Ludovic Courtès escreveu:
> Hello,
>
> "Han-Wen Nienhuys" <[EMAIL PROTECTED]> writes:
>
>> autoreconf: running: aclocal --force
>> autoreconf: configure.in: not using Libtool
>> autoreconf: running: /home/hanwen/usr/pkg/ac/bin/autoconf --force
>&
ed my 32 bit laptop, but that some people complaining :)
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
s something else, unrelated to the
> patch I just sent in. I'll keep looking at it. You have any luck
> narrowing things down with Helgrind?
No, there is no consistent lock ordering in Guile at all, so Helgrind gives
1000s of errors.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
for a couple of hours). There's a patch attached.
>
> (Sorry, should have noticed this earlier; the problem existed before
> the changes I introduced to support SRFI-18...)
Would this also explain the 'corruption' in the evaluator we have been
seeing ("bad bindings at .. ")?
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
efault
will generate a 32 bit binary.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Ludovic Courtès escreveu:
> Hey!
>
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> Ludovic Courtès escreveu:
>
>>> That said, the ideal would be something like `add-change-log-entry' that
>>> operates on Git logs instead of ChangeLogs, b
ry' that
> operates on Git logs instead of ChangeLogs, but there doesn't seem to be
> anything like this. DVC is said to support things like that, but it
> doesn't seem to be well documented.
Try magit (by Marius Vollmer, our previous overlord). It lets you create
commits by marking individual patch hunks.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
correctly. Hence
>> it requires double work for the committer.
>
> Guile is distributed as a tarball, not a git repo. Does it make
> sense to create the ChangeLog from the git log at make dist time?
I'm not against that, but anyone who is interested in the history
might
changes to ChangeLog ensure
that every cherry pick will need manual conflict resolution.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Han-Wen Nienhuys escreveu:
>>> The use of scm_gc_mark() outside of GC is fundamentally broken, since it
>>> creates race conditions in the presence of threads.
>> I was not aware that this was the case.
>>
>> My impression was that the mark phase is global; it
Andy Wingo escreveu:
> Hi again!
>
> On Wed 27 Aug 2008 12:00, Andy Wingo <[EMAIL PROTECTED]> writes:
>
>> On Wed 27 Aug 2008 07:00, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>>
>>>>>> http://thread.gmane.org/gmane.lisp.guile.u
se think and reread before you
send out something.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
thermore, in the eventuality where none of us eventually finds a fix,
> `master' is left in the previous state, which is better IMO.
'master' in its previous states grows the heap to 600M doing the 1000-fold
version of srfi-18 test I posted. I think it's not a good soluti
mutex already gives away
implementation details.
I'm a bit miffed that the current interface already gives away that we
won't rewrite (ie. compact) the current heap. Let's not paint
ourselves in more corners.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Ludovic Courtès escreveu:
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> I am pushing a fix for this to master.
>
> Will you care to post and discuss your patches before pushing them?
Over the last weeks I have seen little discussion on you
:
> Hi,
>
> On Sat 16 Aug 2008 11:45, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> Julian Graham escreveu:
>>> Hmmm... I don't recall seeing those when I was writing that test
>>> suite. Just to be clear, were you getting those errors before makin
Han-Wen Nienhuys escreveu:
>> even the lazy smob case I wrote about here:
>>
>> http://thread.gmane.org/gmane.lisp.guile.user/6372
>
> I would classify the use of mark bits outside of the mark phase as outside
> of the defined API. If you want to have weak poin
Andy Wingo escreveu:
> Hi,
>
> On Sat 16 Aug 2008 11:45, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> Julian Graham escreveu:
>>> Hmmm... I don't recall seeing those when I was writing that test
>>> suite. Just to be clear, were you gett
r...
The statistics form the basis of the allocation strategy, so they are not
a 'cute' feature. If these statistics go off, we overallocate, or spend too
much time trying garbage collect when there is nothing to reclaim.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
can you try similar things on your machine?
(getenv "LD_LIBRARY_PATH")
"/home/lilydev/usr/lib:"
I'm running Fedora 9.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Ludovic Courtès escreveu:
> I don't observe this failure on my x86 (Core(TM)2 Duo) laptop.
Let me try to look at this during next week. As a kludge, you can #if 0 the
asserts; although the stats will be off (as well as the allocation strategy),
nothing bad should happen.
--
Han-Wen
r: for each function it appears in.)
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Han-Wen Nienhuys escreveu:
> Ludovic Courtès escreveu:
>> Hello,
>>
>> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>>
>>> Ludovic Courtès escreveu:
>>>> Off the top of my head: incorrect indentation, missing spaces around
>>>> bra
h out
1.10 now, and merge the VM (which is a large change) afterwards?
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
ter'. However, Kevin's original post
> compared 1.8 (which doesn't have this commit) to 1.6.
I did a big rewrite of the garbage collector between 1.6 and 1.8; See
commit 06e80f59f976c8dda5161804f611f489ec2948a2
Author: Han-Wen Nienhuys <[EMAIL PROTECTED]>
Date: Tue
Ludovic Courtès escreveu:
> Hello,
>
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> Ludovic Courtès escreveu:
>
>>> Off the top of my head: incorrect indentation, missing spaces around
>>> brackets, and more importantly comments (see (standar
tion is
cleaned up only once - (on iteration 1000), and remains 'live' after
that, so there may still be some bugs lurking.
BTW2 stress.scm says
(char-set #\.) ;; double-cell
char-sets are smobs and use single cells, AFAICT.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
<>
ives are not used anywhere else.
Do we have a slow-slot-ref that we could simply substitute for this code?
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
7;.
On the contrary, I think the GC is one of the more interesting parts. Only
the evaluator is more funky, but I lack the braincells to deal with that
competently.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Ludovic Courtès escreveu:
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> Running the test suite through valgrind, I get some fishy errors.
>
> So was that fixed by this commit?
>
> commit 51ef99f7fa9fb766fbb48619fc5863ab9914591d
> Author: Han-Wen Nien
Ludovic Courtès escreveu:
> Hi Han-Wen,
>
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> Ludovic Courtès escreveu:
>
>>> is kind of hard to review in a glimpse. Does it just randomly "clean
>>> things up" (whatever that means---i
t; practice since I follow Guile development (c. 2004).
FWIW, GUILE development seems from the outside very much stagnant,
even if there are the occasional commits to the master branch. Perhaps I have
various preconceptions because I also follow LilyPond development, which is
more turbulent, with more mistakes going in at a higher pace, but also more
discussion and more bugfixing going in at a higher pace.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
1 - 100 of 278 matches
Mail list logo
