> Years ago my text retrieval package had an option to call free() for all
> the data structures on exit, basically just for debugging. It made the
> programs often go really slow when they exited - adding tens of seconds
> wasn't uncommon.
Maybe there are corner cases (although the platforms GTK
On 10 Feb 2011, at 01:19, Costin Chirvasuta wrote:
> I'm not saying this is really important and it should be done soon.
> I'm merely stating that the value of having gtk_cleanup() would be
> greater than zero. That is, regardless of how much trouble it would be
> for someone to write, if it woul
My analogy had nothing to do with memory use. It had something to do
with code beauty which was all that Bill Atkinson was about. It was
all that article was about. You got it exactly the other way around.
Efficient use of memory at the expense of ugliness was the thing to
avoid in that article.
I
On Thu, 2011-02-10 at 00:43 +0200, Costin Chirvasuta wrote:
> > but aside from that it's a pure waste of CPU cycles.
>
> I hate to throw fuel in the fire but this is just absurd!
> How complex is freeing 200 pointers? O(1)?
Years ago my text retrieval package had an option to call free() for all
On 02/09/2011 06:08 PM, Costin Chirvasuta wrote:
> Tip: (regarding whether or not that link is relevant) Intelligence
> means analogy. Being able to make connections. If you understood my
> meaning and thought it wrong you should have said "You analogy is
> incorrect". Not point out that you didn't
On Thu, 10 Feb 2011, Costin Chirvasuta wrote:
> So it's better to use suppresion with Valgrind then to add a
> gtk_cleanup() counterpart to gtk_init()?
That's debatable, of course, but Yes, it's more efficient for the
ordinary use case of the GTK stack -- let the OS reclaim memory on
exit -- alth
I'm not saying this is really important and it should be done soon.
I'm merely stating that the value of having gtk_cleanup() would be
greater than zero. That is, regardless of how much trouble it would be
for someone to write, if it would end up in the codebase it's value
would be greater than the
So it's better to use suppresion with Valgrind then to add a
gtk_cleanup() counterpart to gtk_init()?
It's better to print something to the display and then put electrical
tape over it?
Tip: (regarding whether or not that link is relevant) Intelligence
means analogy. Being able to make connections
I think it's worth pointing out that these normally harmless leaks would
become a problem if gtk was repeatedly loaded and unloaded with
dlopen()+dlclose(). Each dlopen() results in a fresh state, so Gtk would
allocate new instances of these global structures each time.
Not exactly a prominent use
On 02/09/2011 02:29 PM, John Emmas wrote:
> But my original example looked like this:-
>
>
> Gtk::Main *app = new Gtk::Main (&argc, &argv);
>
> delete app;
Change it to this and then look at memory use:
for (;;) {
Gtk::Main *app = new Gtk::Main (&argc, &argv);
delete app;
}
If
On 02/09/2011 05:34 PM, Costin Chirvasuta wrote:
> How times have changed:
> http://www.folklore.org/StoryView.py?story=Were_Not_Hackers!.txt
Nothing to do with the issue at hand. Nothing at all. The issue is
whether a library intended for one-time loading should clean up after
itself. Whether
Some people really don't get this but it's a fact that people like to
work with a Bill Atkinson. Not so much with hackers (if you read the
above link).
Childish? Maybe. Just hope some people get my point.
___
gtk-app-devel-list mailing list
gtk-app-devel
How times have changed:
http://www.folklore.org/StoryView.py?story=Were_Not_Hackers!.txt
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
On Wed, 9 Feb 2011, Carlos Pereira wrote:
> > something), but aside from that it's a pure waste of CPU cycles.
> >
> Dear Allin,
> 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.
Easy or difficult, if the
On 02/09/2011 05:05 PM, Jeff Clough wrote:
> And the fact that so many shared library hackers have this view is the
> reason modern desktops need to ship with four gigs of RAM minimum and
> still can't stay up for more than a week.
Rubbish. What an absurd and fallacious argument. Whether GTK+ "l
On 02/09/2011 04:39 PM, Bill C wrote:
> My experience with valgrind and GTK is that it is easy to fix leaks.
>
> Simply look for leaked memory that you allocated. Then determine where
> you should have released it. If it was not allocated by you its not
> your problem so ignore it.
Right. An
On Wed, 2011-02-09 at 17:22 -0500, Allin Cottrell wrote:
> I'm afraid you're talking through your hat here. Have your ever
> worked through the code for even a simple shared library that
> saves state? Freeing all memory on exit can be useful as a
> debugging exercise (e.g. if you get a segfault
There is already gtk_init(). It's only logical it should have a counterpart.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
I think Allin's point is that even though I deleted the object in my example
app, the gtk shared library code is still technically available to be used by
some other part of my program (without needing to be re-initialized). In my
example, I just happened to not use it.
Yes, I accept All
On 10/02/11 04:01, James Morris wrote:
On 9 February 2011 16:10, Michael Cronenworth wrote:
That's called patronising. I have been there already. What good is a
work in progress when the progress stopped over two years ago?
Not only do we have to write our own code, we have to put work into
mak
On 9 Feb 2011, at 23:41, Carlos Pereira wrote:
>
>> something), but aside from that it's a pure waste of CPU cycles.
>>
> Dear Allin,
> 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
something), but aside from that it's a pure waste of CPU cycles.
Dear Allin,
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 case, is just a question of plain laziness and bad
programming
> but aside from that it's a pure waste of CPU cycles.
I hate to throw fuel in the fire but this is just absurd!
How complex is freeing 200 pointers? O(1)?
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/lis
On Wed, 9 Feb 2011, John Emmas wrote:
> On 9 Feb 2011, at 20:06, Allin Cottrell wrote:
>
> > You're missing Tor's point. Yes, all memory leaks are bad, but
> > most (all?) of the instances of not-explicitly-released memory
> > in the GTK stack are _not_ leaks. If you still have a pointer to
> > it
On 9 Feb 2011, at 20:06, Allin Cottrell wrote:
> You're missing Tor's point. Yes, all memory leaks are bad, but
> most (all?) of the instances of not-explicitly-released memory
> in the GTK stack are _not_ leaks. If you still have a pointer to
> it, it ain't a leak, even if a dumb debugger says s
On Wed, 9 Feb 2011, Tor Lillqvist wrote:
> > Am I right in
> > thinking that the "engines" that used to live in separate dlls
> > (libpixmap and libwimp) are now folded into one of the main dlls
> > -- presumably libgtk-win32-2.0-0.dll?
>
> No, that would not work (without changes to the engine-lo
> Am I right in
> thinking that the "engines" that used to live in separate dlls
> (libpixmap and libwimp) are now folded into one of the main dlls
> -- presumably libgtk-win32-2.0-0.dll?
No, that would not work (without changes to the engine-loading code to
look for built-in engines). They are wh
Quick question on the current build of GTK 2.16.6 for win32 on
gnome.org, that is, gtk+_2.16.6-3_win32.zip. Am I right in
thinking that the "engines" that used to live in separate dlls
(libpixmap and libwimp) are now folded into one of the main dlls
-- presumably libgtk-win32-2.0-0.dll?
Thanks.
-
On Wed, 9 Feb 2011, Carlos Pereira wrote:
> >P.S I will say though that in all my life I don't think I've ever written a
> >program>where it was either impractical (or too difficult) to fix its leaks.
> > IMHO ignoring>leaks is a bad habit to get into and one whose consequences
> >usually get w
P.S I will say though that in all my life I don't think I've ever written a
program>where it was either impractical (or too difficult) to fix its leaks. IMHO
ignoring>leaks is a bad habit to get into and one whose consequences usually get
worse over time.
I could not agree more with this. It
Hi all,
I'm using Gtk-2.22.0 and I have a problem using drag and drop on a GtkTreeView
on Windows.
I'd like to have a drag and drop functionality to move an item in the
GtkTreeView from a top level position to a folder contained in the same
treeView.
My code is the following, and this code
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!
I think I'd agree with you if I'd ever used Va
On 9 February 2011 16:10, Michael Cronenworth wrote:
> James Morris wrote:
>>
>> How does one gain this mysterious tool for Linux?
>
> It's called Google. There's a web page[1] that details how to setup valgrind
> to debug gtk/glib apps and even a preliminary suppression file.
>
> [1] http://live.
James Morris wrote:
How does one gain this mysterious tool for Linux?
It's called Google. There's a web page[1] that details how to setup
valgrind to debug gtk/glib apps and even a preliminary suppression file.
[1] http://live.gnome.org/Valgrind
__
On Wed, Feb 09, 2011 at 04:02:01PM +, James Morris wrote:
> I have used Valgrind but as mentioned by numerous souls at numerous
> times in the past, a suppressions file is needed for GTK/GLIB. And
> creating a suppressions file is more work than actually writing the
> code of the program I'm tr
On 9 February 2011 11:13, Tor Lillqvist wrote:
> With the right tool there is no problem at all in finding such "true"
> leaks.
How does one gain this mysterious tool for Linux?
I have used Valgrind but as mentioned by numerous souls at numerous
times in the past, a suppressions file is needed
On 9 Feb 2011, at 11:13, Tor Lillqvist wrote:
>> Each time you call _CrtDumpMemoryLeaks() it dumps all the memory that's been
>> allocated but not yet released.
>
> So it doesn't take into consideration at all whether the memory in
> question is / can be used or not, i.e. whether there is any p
On Wed, Feb 9, 2011 at 12:54, John Emmas wrote:
>
> On 9 Feb 2011, at 08:44, Tor Lillqvist wrote:
>
>> A *true* leak, in my opinion, is if performing some code sequence over
>> and over again (like what happens if you just do the same UI actions
>> repeatedly) causes the amount of unreachable memo
> Each time you call _CrtDumpMemoryLeaks() it dumps all the memory that's been
> allocated but not yet released.
So it doesn't take into consideration at all whether the memory in
question is / can be used or not, i.e. whether there is any pointer to
it in local variables, etc. All memory that ha
On 2/9/2011 3:44 AM, Tor Lillqvist wrote:
several times already over the years. This parrot is dead.
No he isn't, he's pining for the fjords...
Sorry, couldn't resist
Damon Register
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
htt
On 9 Feb 2011, at 08:44, Tor Lillqvist wrote:
> A *true* leak, in my opinion, is if performing some code sequence over
> and over again (like what happens if you just do the same UI actions
> repeatedly) causes the amount of unreachable memory to grow
> continuously.
>
It's an interesting argume
On Wed, Feb 9, 2011 at 4:44 PM, Tor Lillqvist wrote:
> It's just a question of definition. Many people, me included, don't
> consider once-only allocations of memory that stays accessible and
> aren't freed before the program exits leaks. GTK+ and GLib isn't the
> kind of libraries that you could
On Wed, 2011-02-09 at 10:44 +0200, Tor Lillqvist wrote:
> And anyway, this "OMG GTK+ leaks memory" discussion has been had
> several times already over the years. This parrot is dead.
True.
But it is a shame that there isn't a
gtk_unload_no_I_mean_really_unload_honest() function that we could use
It's just a question of definition. Many people, me included, don't
consider once-only allocations of memory that stays accessible and
aren't freed before the program exits leaks. GTK+ and GLib isn't the
kind of libraries that you could load dynamically, use a bit, and then
unload, and expect to fr
On 8 Feb 2011, at 09:36, John Emmas wrote:
>
> int main (int argc, char *argv[])
> {
> Gtk::Main *app = new Gtk::Main (&argc, &argv);
>
> delete app;
>
> return 0;
> }
>
> The above code causes hundreds of memory leaks.
>
I spent a few minutes on this (literally just a few) t
45 matches
Mail list logo
