Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> commit 53f4876abcebf3f05d2a88bba3a898ddcda25a74
> Merge: 69f2317... 242ebea...
> Author: Ludovic Courtès <[EMAIL PROTECTED]>
> Date: Tue Sep 9 22:03:42 2008 +0200
>
> Merge branch 'master' into strftime-gnulib
>
> Conflicts:
> l
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:
> +/*
> + Classic MIT Hack, see e.g. http://www.tekpool.com/?cat=9
> + */
> +int scm_i_u
Hi,
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>> Han-Wen Nienhuys escreveu:
>>> Ludovic Courtès escreveu:
>
+/*
+ Classic MIT Hack, see e.g. http://www.tekpool.com/?cat=9
+ */
+int scm_i_uint_bit_count(unsigned int u)
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 Nienhuys
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> I just added `master' to the daily build on x86-64 [0] and it fails
> there:
>
> lt-guile: gc.c:609: scm_i_gc: Assertion `scm_i_gc_sweep_stats.collected +
> scm_cells_allocated == scm_i_gc_sweep_stats.swept' failed.
>
> http://autobuild.josefsson.
Hi,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Han-Wen Nienhuys escreveu:
>> Ludovic Courtès escreveu:
>>> +/*
>>> + Classic MIT Hack, see e.g. http://www.tekpool.com/?cat=9
>>> + */
>>> +int scm_i_uint_bit_count(unsigned int u)
>>>
>>> (BTW, it'd make sense to use Gnulib's `count-one-bits'
Hi,
I just added `master' to the daily build on x86-64 [0] and it fails
there:
lt-guile: gc.c:609: scm_i_gc: Assertion `scm_i_gc_sweep_stats.collected +
scm_cells_allocated == scm_i_gc_sweep_stats.swept' failed.
http://autobuild.josefsson.org/guile/log-200808220956770665000.txt
GDB forensi
Hi,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> 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 Dec 10 13:26:25 2002 +
>
> and following commits.
>
> This
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
brackets, and more importantly comments (see (standards.info)Comments).
Ludovic Courtès escreveu:
>> A likely candidate is the patch from you that I applied. In
>> particular,
>> 4c7016dc06525c7910ce6c99d97eb9c52c6b43e4
>
> Well, that's a good candidate since it's the last significant change
> that was done to the GC on `master'. However, Kevin's original post
> comp
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 (standards.info)Comments).
>> The code I went through sho
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 (standards.info)Comments).
>
> The code I went through should not have that; please point me to
On Sun 17 Aug 2008 14:51, [EMAIL PROTECTED] (Ludovic Courtès) writes:
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> I have a request: can you put the gnulib into the repository of GUILE itself?
>
> Yeah, we could do that.
I think this would be good; and call be ornery, but a simple import,
Ludovic Courtès escreveu:
>> Ludovic Courtès escreveu:
>
>> Can you be more specific about this?
>
> Off the top of my head: incorrect indentation, missing spaces around
> brackets, and more importantly comments (see (standards.info)Comments).
The code I went through should not have that; pleas
Hi,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Ludovic Courtès escreveu:
> Can you be more specific about this?
Off the top of my head: incorrect indentation, missing spaces around
brackets, and more importantly comments (see (standards.info)Comments).
> See below - note that the old .scm
Ludovic Courtès escreveu:
>> (I intend to squash into a single commit before pushing to master).
>
> First of all, thanks for your work (I know it's not so much fun to hack
> the GC), but I feel unhappy with your commit to both `master' and
> `branch_release-1-8'.
On the contrary, I think the GC
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---it does not follow the GCS, for
>> GCS?
>
> "GNU Coding Stand
Ludovic Courtès escreveu:
>>>hell = scm_calloc (hell_size * sizeof (*hell));
>>>
>>> `sizeof (*hell)' is actually `sizeof (scm_t_bits *)', which is equal
>>> to `sizeof (scm_t_bits)', but using `sizeof (*hell)' is clearer and
>>> less error-prone.
>>>
>>> Besides, is that c
Han-Wen Nienhuys escreveu:
> Ludovic Courtès escreveu:
>
>> Not quite actually: the "hell = scm_malloc (...)" bit is still broken.
>
> ?
>
>> BTW, can you please avoid pushing small topic branches like "nit" and
>> "dev/with-gnulib" to Savannah, as we can't distinguish them from "big"
>> branche
Ludovic Courtès escreveu:
> Not quite actually: the "hell = scm_malloc (...)" bit is still broken.
?
> BTW, can you please avoid pushing small topic branches like "nit" and
> "dev/with-gnulib" to Savannah, as we can't distinguish them from "big"
> branches like "vm"?
Sorry, - contrary to what m
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Ludovic Courtès escreveu:
>>
>> * 51ef99f7fa9fb766fbb48619fc5863ab9914591d
>> Fix memory corruption issue with hell[] array: realloc/calloc need to
>> factor in sizeof(scm_t_bits)
>>
>> - hell = scm_malloc (hell_size);
>> + hell
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Ludovic Courtès escreveu:
>> * 51ef99f7fa9fb766fbb48619fc5863ab9914591d
>> Fix memory corruption issue with hell[] array: realloc/calloc need to
>> factor in sizeof(scm_t_bits)
>>
>> - hell = scm_malloc (hell_size);
>> + hell = s
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---it does not follow the GCS, for
>
> GCS?
"GNU Coding Standards", the thing we're supposed to adhere
Han-Wen Nienhuys escreveu:
> I had a look at pulling this change apart, but it is tricky since
> many of the changes are interrelated.
>
> If you think you need to roll back this change, please revoke my
> commit privilege and sort things out yourself. The garbage collector
> isn't that complic
Ludovic Courtès escreveu:
> Han-Wen,
>
> This patch:
>
> 82ae1b8eb3413e6be6bd2aa032986fc7782e85ac
> Garbage collection cleanup.
>
> Makefile.am|8
> gc-card.c | 109 ++
> gc-freelist.c | 150 +++---
> gc-malloc.c| 24 +-
> gc-mark.
Ludovic Courtès escreveu:
> * 01621bf62ec16cb62260f0b7c9e926793718fd6d
> Include min-yields in gc-stats output.
>
> Good idea.
No, bad idea, and removed in subsequent commit.
>
> * 51ef99f7fa9fb766fbb48619fc5863ab9914591d
> Fix memory corruption issue with hell[] array: realloc/
Hi,
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> First of all, thanks for your work (I know it's not so much fun to hack
> the GC), but I feel unhappy with your commit to both `master' and
> `branch_release-1-8'.
Ooops, I thought I had seen these changes on `branch_release-1-8'
through Gitweb b
Han-Wen,
This patch:
82ae1b8eb3413e6be6bd2aa032986fc7782e85ac
Garbage collection cleanup.
Makefile.am|8
gc-card.c | 109 ++
gc-freelist.c | 150 +++---
gc-malloc.c| 24 +-
gc-mark.c |8
gc-segment-table.c | 293 +++
Hi Han-Wen,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> I did a cleanup round over the GC code - see the dev/hanwen branch on
> sv.gnu.org ; It seems to work ok, there is a just one annoyance: there
> is a commented out assert that works most of the time, but once in a
> while is off by a smal
Hi,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> I have a request: can you put the gnulib into the repository of GUILE itself?
Yeah, we could do that.
There's a discussion at
http://www.gnu.org/software/gnulib/manual/html_node/VCS-Issues.html .
I'm usually tempted to not include any generated
Han-Wen Nienhuys escreveu:
> Ludovic Courtès escreveu:
>> Hi,
>>
>> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>>
>>> After switching from the 1.8 branch to master, I get
>>>
>>> ./autogen.sh: line 22: gnulib-tool: command not found
>>>
>>>
>>> I'm on Fedora 9. Where do I get gnulib-tool ?
Ludovic Courtès escreveu:
> Hi,
>
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> After switching from the 1.8 branch to master, I get
>>
>> ./autogen.sh: line 22: gnulib-tool: command not found
>>
>>
>> I'm on Fedora 9. Where do I get gnulib-tool ?
>
> With "git-clone git://git.sv
Han-Wen Nienhuys escreveu:
> Ludovic Courtès escreveu:
>> Hi Han-Wen,
>>
>> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>>
>>> I've implemented an env var GUILE_MAX_HEAP_SIZE (- some lilypond users
>>> were complaining that running lily o
Ludovic Courtès escreveu:
> Hi Han-Wen,
>
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> I've implemented an env var GUILE_MAX_HEAP_SIZE (- some lilypond users
>> were complaining that running lily on large sets of files keeps
>> growing the he
Hey!
<[EMAIL PROTECTED]> writes:
> "Ludovic Courtès" <[EMAIL PROTECTED]> wrote:
>> With "git-clone git://git.sv.gnu.org/gnulib.git". `gnulib-tool' is a
>> script that will install the right Gnulib modules into your Guile
>> directory.
>
> This should probably be added to HACKING.
You mea
"Ludovic Courtès" <[EMAIL PROTECTED]> wrote:
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> > After switching from the 1.8 branch to master, I get
> >
> > ./autogen.sh: line 22: gnulib-tool: command not found
> >
> >
> > I'm on Fedora 9. Where do I get gnulib-tool ?
>
> With "g
Hi,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> After switching from the 1.8 branch to master, I get
>
> ./autogen.sh: line 22: gnulib-tool: command not found
>
>
> I'm on Fedora 9. Where do I get gnulib-tool ?
With "git-clone git://git.sv.gnu.org/gnulib.git". `gnulib-tool' is a
s
Ludovic Courtès escreveu:
> Hi Han-Wen,
>
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> I've implemented an env var GUILE_MAX_HEAP_SIZE (- some lilypond users
>> were complaining that running lily on large sets of files keeps
>> growing the he
Ludovic Courtès escreveu:
> Hi Han-Wen,
>
> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
>> I've implemented an env var GUILE_MAX_HEAP_SIZE (- some lilypond users
>> were complaining that running lily on large sets of files keeps
>> growing the he
Hi Han-Wen,
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> I've implemented an env var GUILE_MAX_HEAP_SIZE (- some lilypond users
> were complaining that running lily on large sets of files keeps
> growing the heap forever, leading to trashing).
Of course, the correct fix
Hello,
I've implemented an env var GUILE_MAX_HEAP_SIZE (- some lilypond users were
complaining that running lily on large sets of files keeps growing the heap
forever, leading to trashing).
Please comment on the patch; it's in branch dev/hanwen on sv.git.gnu.org
--
Han-Wen Nienhuy
41 matches
Mail list logo
