On Tue, 15 Jul 2008, Alessandro Vesely wrote:
This discussion reminds me that smc_notify_tree() does not actually check
which thread does a chunk belong to. Could that result in misbehavior?
No, chunks may be freely passed back and forth betwen threads without
problems. Except for a few blocks
On Tue, 2008-07-15 at 17:19 +0200, Sven Herzberg wrote:
> Hi Alessandro,
>
> Am Dienstag, den 15.07.2008, 17:04 +0200 schrieb Alessandro Vesely:
> > What would you say about that
>
> It's pretty nice, I only have two comments:
>
> * you change "only for debugging" to "always for debugging", may
Sven Herzberg wrote:
Hi Alessandro,
Am Dienstag, den 15.07.2008, 17:04 +0200 schrieb Alessandro Vesely:
What would you say about that
It's pretty nice, I only have two comments:
* you change "only for debugging" to "always for debugging", maybe you
should simply use "iff" (or the expande
Hi Alessandro,
Am Dienstag, den 15.07.2008, 17:04 +0200 schrieb Alessandro Vesely:
> What would you say about that
It's pretty nice, I only have two comments:
* you change "only for debugging" to "always for debugging", maybe you
should simply use "iff" (or the expanded version "if and only
Sven Herzberg wrote:
Am Dienstag, den 15.07.2008, 14:13 +0200 schrieb Alessandro Vesely:
I didn't mean glib's test suite. What I wanted to say is that any
client program that has its own test suite should enable debug-blocks
in it. The above page should explicitly encourage such practice, IMHO.
Am Dienstag, den 15.07.2008, 14:13 +0200 schrieb Alessandro Vesely:
> I didn't mean glib's test suite. What I wanted to say is that any
> client program that has its own test suite should enable debug-blocks
> in it. The above page should explicitly encourage such practice, IMHO.
> Overlapping va
Kalle Vahlman wrote:
Well, it *is* mentioned in the docs, with explanations:
http://library.gnome.org/devel/glib/stable/glib-running.html
;)
Alas, I missed it. However, I guess mono developers read it. After
googling mono-project.com for G_SLICE, I'd say that page didn't work ;-)
Also,
2008/7/13 Alessandro Vesely <[EMAIL PROTECTED]>:
> So, I *don't* apologize for that false report :-) Both because nobody saved
> me a few hours of code reading on this sunny sunday, and because that debug
> feature deserves a more thorough advertising: It is nonsensical that client
> test suites ex
I wrote:
GOT BUG: last=0x82b61a0, next=(nil), new=0x82b61a0
Although I'm inclined to think the bug is due to the old compiler
And I was wrong
In facts, 0x82b61a0 was used and freed various times before eventually
being allocated twice on two consecutive loops of the client code. [...]
And
I wrote:
GOT BUG: last=0x82b61a0, next=(nil), new=0x82b61a0
[...]
I'll try and reconfigure glib with CFLAGS="-O0 -g", and
see if that changes anything.
No changes. Even the memory address is the same!
___
gtk-devel-list mailing list
gtk-devel-list@g
Hi,
I've compiled glib, and make check worked fine. Next, I compiled the
"mono" package, which uses it. It compiled almost ok (few twists
needed on a pre-C99 compiler) but make check freezes. After some
tinkering I found out that freezing occurs because of circular list.
The functions involve
11 matches
Mail list logo
