Because malloc() implementations generally kept a linear linked list of
free space, and traversed the list on a free() in case they found
adjacent memory areas to the one you were freeing, which they could join
together and make into a single larger area.
I'm sorry, I now understand what you
Hi All
On 10/02/11 18:26, John Emmas wrote:
On 9 Feb 2011, at 17:01, James Morris wrote:
Not only do we have to write our own code, we have to put work into
making other peoples code ignore the errors in other peoples code so
we can see the errors in our own code. It's a bloody outrage!
From: Carlos Pereira [jose.carlos.pere...@ist.utl.pt], Date: 10/02/2011 09:10:
something), but aside from that it's a pure waste of CPU cycles.
I am sorry, I totally disagree.
I can only see two cases. Either fixing these hundreds and hundreds of
mem leaks is easy or difficult.
In the first
The basic idea that one must understand about programming is that of
paradigms and concepts. They are really stressed for C++ and higher
level stuff (scripting languages notwithstanding ofcourse). But if
you're gonna use C you're gonna write paradigms and concepts that
you'll really have to be
On 10/02/11 19:50, Costin Chirvasuta wrote:
I'm sorry, I now understand what you mean. If what you say is true
(which I don't doubt) it's a really boneheaded mechanism in my
opinion. Defragmenting memory in realtime is a performance nightmare.
But that's irrelevant. Your point is well taken.
On 10 Feb 2011, at 11:36, Freddie Unpenstein wrote:
I really don't want to have to sit around for an extra 10-20 seconds while a
closing application crawls along pulling data from swap space for no
particularly good reason, when the OS could have simply marked those pages as
available and
To describe the standard mechanism of garbage collection as a boneheaded
idea shows a total lack of awareness of first year Computer Science course
principles. That garbage collection has been refined and highly optimised
over the years is true; however it is a very necessary thing with
Hi all,
I'm always working on a treeview that display a sorted filtered :
the model displayed is a GtkTreeModelSort whose child is a
GtkTreeModelFilter whose child is a GtkListStore.
Sometime when the model is actually sort and filtered I have on
selection 2 Gtk-Critical on
On 02/10/2011 12:19 AM, Costin Chirvasuta wrote:
I find not cleaning up explicitly quite ugly. I shudder at the thought
and maybe I'm not the only one. Not only that, but cleaning up
explicitly is obviously useful for some people.
I guess we're at an impasse then. The discussion has now moved
On 10 Feb 2011, at 17:48, Michael Torrie wrote:
I guess we're at an impasse then. The discussion has now moved from the
definition of leak to some personal idea of what beauty is.
In which case, maybe we should agree to use the word leak for the simple
purpose of identifying the
GTK+ 3.0.0 is now available for download at:
http://download.gnome.org/sources/gtk+/3.0/
ftp://ftp.gtk.org/pub/gtk/3.0/
sha256 sums:
ec0729bf28f09a16e0b0a6a588556c7cee091f40426505b3694a9488bf6cbf67 gtk
+-3.0.0.tar.bz2
d294155389c9ba4765c0b26805967f2dae1d84565f5d4095d489f94619406df9 gtk
On Thu, Feb 10, 2011 at 07:28:40PM +, John Emmas wrote:
To me, the debate has become something very simple when a program
needs to allocate a block of memory only once, does the programmer
necessarily have to release it programmatically or can he defer it to
the OS? Remember we
On Thu, 2011-02-10 at 10:50 +0200, Costin Chirvasuta wrote:
Because malloc() implementations generally kept a linear linked list of
free space, and traversed the list on a free() in case they found
adjacent memory areas to the one you were freeing, which they could join
together and make
On 11/02/11 09:13, David Nečas wrote:
While I agree having a clean-up function could be useful in some cases
(dynamical modules with GUI) this ‘widespread expectation in C++’ stuff
is just rubbish.
Yeti
___
gtk-app-devel-list mailing list
On 10 Feb 2011, at 22:13, David Nečas wrote:
And others, Gtk+ devs probably including, consider this a useful
optimisation – and in many cases a necessity. You still do not seem to
accept even the existence of this point of view.
I would say quite the reverse. Every single person here
To handle setting/getting of D-Bus properties asynchronously, the
documentation for GDBusConnection states:
'...simply register an object with the org.freedesktop.DBus.Properties D-Bus
interface using g_dbus_connection_register_object().'
This works so far as allowing an application to handle
Hi,
On Thu, Feb 10, 2011 at 10:01 AM, Matthew Bucknall
matthew.buckn...@googlemail.com wrote:
To handle setting/getting of D-Bus properties asynchronously, the
documentation for GDBusConnection states:
'...simply register an object with the org.freedesktop.DBus.Properties D-Bus
interface
In .NET it is invalid to generate a property or a method which is the
same name as an event as it is ambiguous as to whether you're invoking
the event or calling the method. The issue I have in particular is
GtkButton. It has the following (reduced) gir:
glib:signal name=clicked
method
On Thu, Feb 10, 2011 at 05:14:39PM +, Alan wrote:
In .NET it is invalid to generate a property or a method which is the
same name as an event as it is ambiguous as to whether you're invoking
the event or calling the method.
This also affects Vala. Other problems happen wrt properties and
Ryan,
what do you think about this patch?
Thanks,
rsc
On Tue, Feb 01, 2011 at 10:57:54AM +0100, Robert Schwebel wrote:
G_DBUS_SIGNAL_FLAGS_NO_MATCH_RULE was introduced only in glib-2.27.3, so
this is the minimum required glib version now.
Signed-off-by: Robert Schwebel
GTK+ 3.0.0 is now available for download at:
http://download.gnome.org/sources/gtk+/3.0/
ftp://ftp.gtk.org/pub/gtk/3.0/
sha256 sums:
ec0729bf28f09a16e0b0a6a588556c7cee091f40426505b3694a9488bf6cbf67 gtk
+-3.0.0.tar.bz2
d294155389c9ba4765c0b26805967f2dae1d84565f5d4095d489f94619406df9 gtk
the migration doc mentioned in matthias' email announcement is 404'd
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
On Thu, Feb 10, 2011 at 4:05 PM, Paul Davis p...@linuxaudiosystems.com wrote:
the migration doc mentioned in matthias' email announcement is 404'd
as is the common questions document.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
On Thu, Feb 10, 2011 at 4:05 PM, Paul Davis p...@linuxaudiosystems.com wrote:
the migration doc mentioned in matthias' email announcement is 404'd
Should be there now, I think.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
On Thu, 2011-02-10 at 16:05 -0500, Paul Davis wrote:
the migration doc mentioned in matthias' email announcement is 404'd
yes, library.gnome.org will take just a bit to pick it up from the
tarball.
ciao,
Emmanuele.
--
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi
On Thu, 2011-02-10 at 22:24 +0100, Tadej Borovšak wrote:
http://library.gnome.org/devel/gtk3/unstable/gtk-migrating-2-to-3.html
Any reason not to have the URLs at .../gtk/3.0/... ?
AfC
Sydney
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
On Fri, 2011-02-11 at 10:00 +1100, Andrew Cowie wrote:
On Thu, 2011-02-10 at 22:24 +0100, Tadej Borovšak wrote:
http://library.gnome.org/devel/gtk3/unstable/gtk-migrating-2-to-3.html
Any reason not to have the URLs at .../gtk/3.0/... ?
It's there now. It takes library.gnome.org a little
On Thu, 2011-02-10 at 19:47 -0500, Shaun McCance wrote:
On Fri, 2011-02-11 at 10:00 +1100, Andrew Cowie wrote:
On Thu, 2011-02-10 at 22:24 +0100, Tadej Borovšak wrote:
http://library.gnome.org/devel/gtk3/unstable/gtk-migrating-2-to-3.html
Any reason not to have the URLs at
On Thu, Feb 10, 2011 at 10:03 PM, Andrew Cowie
and...@operationaldynamics.com wrote:
On Thu, 2011-02-10 at 19:47 -0500, Shaun McCance wrote:
On Fri, 2011-02-11 at 10:00 +1100, Andrew Cowie wrote:
On Thu, 2011-02-10 at 22:24 +0100, Tadej Borovšak wrote:
On Fri, 2011-02-11 at 14:03 +1100, Andrew Cowie wrote:
On Thu, 2011-02-10 at 19:47 -0500, Shaun McCance wrote:
On Fri, 2011-02-11 at 10:00 +1100, Andrew Cowie wrote:
On Thu, 2011-02-10 at 22:24 +0100, Tadej Borovšak wrote:
On Fri, Feb 11, 2011 at 12:05 AM, Shaun McCance sha...@gnome.org wrote:
I can see how this could lead some users to get to the wrong
place though. Even with navigation and layout that pushes
people towards the 3.0 stack, the URLs are so predictable
that it's not unreasonable to expect
31 matches
Mail list logo
