5 Apr 2000 tony   » (Journeyer)


Some non-meme thoughts (I'm done with them, Kelly-- thanks for pointing out the misdirections intrinsic to the concept):

The current implementation of gnome-filer is fatally flawed. I'm not doing any real kind of memory management; I was hoping a good method would pop up, and I could have some sort of coherent strategy.

No such luck.

Currently, the watchpoint mechanism uses a gpointer for data storage, and doesn't do any allocation or deallocation. Really, I should use a GTK_ARG datatype for storage; then I can copy strings and handle internal (to the object) memory management, and leave everything else alone. But does that make sense? Or should I leave strings alone, too, and count on the application to handle memory? Or should I strongly-type everything, and only allow lists of GTK_ARGS for compound data types?

Too many questions.

I suspect I should just count on the application to handle memory management. I mean, the language plug-ins can handle memory for user-space programs; and for the gnome-filer designer application, I can probably handle my own memory. If I count on the object plug-ins to handle memory, there will be too many special cases. Hell, everything will be a special case. So perhaps there will be fewer problems if the application itself keeps track of everything.

In any case, the current implementation of gnome-filer is fatally flawed.

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!