Re: GUILE_MAX_HEAP_SIZE

[Ludovic Courtès]

Hi Han-Wen,

Han-Wen Nienhuys <address@hidden> 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 to when
writing code for the GNU Project:

  http://www.gnu.org/prep/standards/

>> instance), or does it fix anything?  It's hard to tell.  Can you
>> reproduce the heap usage graphs referred earlier in this thread?  Do
>
> No, the memory usage is more stable now. 

Can you show what the graph looks like, for comparison purposes?

>> you have any evidence of improved behavior?  Is it this patch that
>> triggers the assertion failure you referred to in your first message?
>> Which assertion is it that fails?
>
> This is fixed now.  See my message about our test-suite being broken 
> by LD_LIBRARY_PATH.

Which assertion is it that failed?  Was that due to an old
`libguile-i18n.so' being loaded?

> I had a look at pulling this change apart, but it is tricky since
> many of the changes are interrelated.

That's also why it's tricky to review.

> I spent more than a day writing and debugging this code - approximately
> 16 hours over the weekend.  Please keep in mind that I write serious 
> software for a living during my 40 hour work week, and don't much time
> for GUILE to spare. 

Well, I suppose most of us are in this situation, as you probably know.
That doesn't mean we never make mistakes, nor that peer review is
useless.

> If you think you need to roll back this change, please revoke my 
> commit privilege and sort things out yourself.

I tried and failed, and so did Kevin
(http://thread.gmane.org/gmane.lisp.guile.devel/6699/focus=6832).  AIUI,
both Kevin and I tried to identify the root of the problem (the "bug")
in a way that would allow us to fix the offending code as conservatively
as possible.

Conversely, the size and scope of your patch leaves me the impression
that you rewrote parts of the GC, without actually pinpointing what
was/is wrong with the code.  I'd have been much more confident with a
one-liner along with an explanation and sample program to determine
whether the problem is there.

> The garbage collector isn't that complicated after all.

Then the people, including me, who spent large amounts of time trying in
vain to fix the code must have been dumb.

Thanks,
Ludovic.