Re: Review of gnio, round 1
> >In libsoup it's also important because it's thread-safe/non-racy. That > >may not be a relevant criterion for GSocket, although the source > >returned by g_socket_create_source() could create similar problems; you > >need to be certain that any such sources are destroyed before you call > >g_socket_close(), or else they could trigger falsely if the fd gets > >reused. Delaying close() until finalization makes that easy because then > >you can just have the source hold a ref on the socket to ensure that the > >fd doesn't get closed. Why not just set the FD to -1? It'll give bad a EBADF instead of ENOTCONNECTED (or whatever), but it seems better... no flags, i guess it's "racy" but that's intrinsic to the circumstance of having one thread writing and another closing. (Really, the caller is going to have to have a lock if they want multiple threads to write to the same fd) - dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_utf8_validate() and NUL characters
Hey all, I recent ran across this situation. The simple fact is that NUL (character 0) (also: not NULL which is a pointer) is nowhere stated to be an invalid unicode character in the unicode spec (g_unichar_validate(0) returns TRUE btw), and the UTF-8 spec doesn't prohibit 0, and following its wording literally, unicode char 0 transforms to a single byte 0. Nonetheless, I think g_utf8_validate() should be kept as is, at least for a long time. It is misnamed, but it serves such a useful purpose that it is widely deployed. I think it should have been named g_utf8_validate_string() b/c that's a more accurate name. I think it's fair to say that strings are NUL-terminated in C (e.g. str* functions and string literals) but there's no standard saying what a string is, so who knows. The simple fact is that MOST strings in structures, param-lists etc in C are simply: char *name; not guint name_len; char *name; so, you definitely want a function like g_utf8_validate_string() to ensure that a string doesn't contain NUL in a situation that it actually cannot be used. It would be nice if a g_utf8_validate_data (const char *str, gsize size, GError**error) could be added... it should follow the UTF-8 spec permitting character 0. Perhaps g_utf8_validate_string() could be added (identical to current g_utf8_validate() or maybe removing the size param, and possibly deprecating that function as confusing). But replacing it with the new semantics should probably wait a long time. --- This is all rather tangential, I believe to the original problem with gedit. It should do it's own UTF-8 validation, b/c a text editor likes to handle invalid UTF-8 specially. UTF-8 is a spec that will not change, and is about 10 lines of code; you can afford to include your own version. It should do something smarter first-off to handle other encodings ie detect Latin1, obey locale, etc etc. And it could default to markup like HEX for non-UTF8 bytes. That's a lot different that the handling you want from say, a configuration parser. - dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_format_file_size_for_display()
On Tue, Dec 18, 2007 at 05:14:31PM -0600, Federico Mena Quintero wrote: > Big deal :) When you see 61.2 MB you think, "oh, file system overhead! > ripples in the time-space continuum". Nobody cares about that. > > Back to my original question: should this function be called > g_format_size_for_display()? It's not for files only. I have no idea whether to use SI or computer units, but the fact that there's debate suggests holding off til there's more experience. Once a few cut-n-pasted versions exist, then you can decide if they are all the same... - dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: turning g_assert* into warnings
> c) programs that aren't 100% bug free could possibly trigger these warnings > during production. aborting would take all the end user data with it, > created/modified images, text documents, etc. > issuing just a warnig preserves the possibility to still save crucial > data if the application logic state still permits (which is most often > the case in practice). > > in a recent discussion, i figured that (c) perfectly applies to g_assert > and g_assert_if_reached() also. but we're actually aborting here: One problem i see is that g_return_if_fail() also does something, ie returns, which can act as a sufficient fallback in many cases. Another tradeoff is that while you may be able to save something, it may be corrupted. my recent work (on journalling databases) has seen a lot of cases where assertions prevented corruption from making it to disk, allowing an earlier state to be resumed. but that may be less common on the desktop. Finally, i do think it's a pretty big break with the traditional definition of assert(). - dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GObject property virtualization
I had some random comments about gobject's property mechanism, i'm not sure it's really worth pursuing, since i've got well-working workarounds in place, but food for thought... For language-bindings, and similar purposes, it is often beneficial to bypass the gobject property mechanism: - it is a bit of a pain to implement a property-id allocation system, and then implement get_property()/set_property() appropriately. the problem grows worse if subclassing is considered. for other projects i've added a new property system with: my_object_class_add_property_full (MyObjectClass *class, GParamSpec*pspec, MyGetFunc get_func, MySetFunc set_func, gpointer data, MyDestroyNotify destroy_instance, GDestroyNotify destroy); the destroy_instance function is called from finalize, and provides e.g. string parameter the opportunity to free themselves. One can add additional macro gobbledegook to make a nice macro that adds an integer property to the class, using only the name of the object-type and the member-name. (It uses offsetof to figure out where the member to set is located) Same for essentially any other property type, though there are perhaps caveats. Many objects have to do special things when a property changes, and so such simple macro properties are useless; but other objects are factory-type objects, and simply need a member set. So, in one project i have: UF_OBJECT_CLASS_STRING_PROPERTY (object_class, MyObject, string_member_name, "string-member", "String Member", "The String Member", NULL, G_PARAM_READWRITE); and that takes care of the get_property(), set_property() and finalize(). It uses an inline function and hackery to ensure that string_member_name is a 'char*' (or at least warn if it isn't). it seems like it would be easy to graft this into gobject, i could provide patches pretty easily. - it would be nice if g_object_new() could fail... i really think that a system that supported property-setting to fail would be useful. in my systems, at least "MySetFunc" returns a gboolean with GError-style handling. But that may not be deemed acceptable for gobject. in any event, on the plus side, gobject has been totally flexible enough for my needs to introduce these things in a subclass, so that works nicely... just some random thoughts, dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Unloading sequence of GTK
On Tue, Mar 21, 2006 at 11:10:24AM -0500, Owen Taylor wrote: > (*) Basically, it's impossible for GObject to know when a type is no > longer in use, because we don't have garbage collection in C. > So, if you unload and reload GTK+ again, referencing the > type "GtkButton" is going to try to create a button object from > the last copy of the GTK+ libraries. well, if GTypes weren't permanent, there could be a g_type_ref(), g_type_unref(), and g_type_unregister()... gtk_unload() could call g_type_unregister() on all the common types. (actually, that might allow for a non-global type-context, which i've occasionally wanted...) - dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK_FLOATING broken in 2.9?
> GFloatingObject, derived from GObject: > - created with ref_count=1 > - initial reference is floating > > GtkObject, derived from GFloating object: > - created with ref_count=1 > - initial reference is floating > - floating flag is implemented as GtkObject.flags>K_FLOATING > via a compat hook, i.e. g_object_ref_sink() will work on this > and GTK_OBJECT_SET_FLAGS() will as well. why does one want GFloatingObject? it seems like calling g_object_force_floating() isn't too hard... and derivation is a somewhat inflexible way to set flags (for example, it can't be done in a subsubclass of object; and to support N flags this way would require 2^N object types) it seems like the principal merit would be to do G_IS_FLOATING_OBJECT() (which is confusingly named to begin with, since it has rather different meaning than g_object_is_floating() but that's a different issue)... one way to achieve that is to support floating-ness on a per-class basis, so that G_IS_FLOATING_OBJECT() replaced by g_object_class_are_instances_initially_floating(G_OBJECT_GET_CLASS(objcet)) (g_object_force_floating() would be used only in g_object_init() and binding hacks instead g_object_class_make_instances_float() or something would be in class_init()) - dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK_FLOATING broken in 2.9?
On Sat, Dec 17, 2005 at 07:00:59PM -0800, Dave Benson wrote: > anyways, *nothing* can fix: > object = g_object_new (MY_TYPE_OBJECT, NULL); > g_object_ref_sink (object); > my_object_ref_sink (object); > g_object_unref(object); > g_object_unref(object); > except upgrading the 'my_object' library to a version that > depends on a late glib.. but if people are just upgrading glib > to say, move to a later gtk, then well, they won't notice the > situation. hey, sorry to reply to myself, but... one thing can fix this: if the floating flag defaults to off for GObject, and g_object_force_floating() is in gtk_object_init(), et al - dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK_FLOATING broken in 2.9?
On Thu, Dec 15, 2005 at 05:07:34PM +0100, Tim Janik wrote: > On Thu, 15 Dec 2005, Dave Benson wrote: [long discussion cut] > >this thread never really addressed my concern, > >which was that this makes it so that container classes > >before 2.10 have one style, and >=2.10 have another. > >considering that this change is trying to simplify > >memory management, i'm dubious. > > > >as i origianlly mentioned, my example is > > g_value_set_object() > >which clearly should ref_sink(), but clearly cannot > >for abi compatiblity reasons (though i'm not exactly going to > >be shocked when a patch goes in that does it anyways...) > > you're right that simply changing that function take over one > reference for floating objects would break existing user code. > > compatibly, you can add extra value setters that properly sink > though, if you think adding that API is worthwhile. > > and you could then deprecate the old API if you think that'd be wise. > > (i'm intentionally leaving this open) so... do you agree that if you could, g_value_set_object() would ref-sink? if so, then isn't it confusing that it doesn't? you shouldn't really have to read the api docs for every function to know their memory-management policy... that's the whole point of the "never pass ownership through function-calls paradigm" (which, i think is it driving force behind needing sink at all-- if you just admit g_value_take_object(), then sink becomes somewhat superfluous.) which is why i thought GObject didn't have a floating flag to start with... b/c it's only good for a certain few usage patterns. in particular, with widgets, there's a natural parent which will sink the object. in more general cases, it's unclear who sinks the object. (i recall a debate whether gtk_container_foreach() sunk... that's just due to the fact that there's no precisely defined sematics for who sinks) anyways, *nothing* can fix: object = g_object_new (MY_TYPE_OBJECT, NULL); g_object_ref_sink (object); my_object_ref_sink (object); g_object_unref(object); g_object_unref(object); except upgrading the 'my_object' library to a version that depends on a late glib.. but if people are just upgrading glib to say, move to a later gtk, then well, they won't notice the situation. - dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: ABI and API for g_object_ref_sink() (Re: GTK_FLOATING broken in 2.9?)
On Fri, Dec 16, 2005 at 12:29:18AM +0100, Tim Janik wrote: > i think this is a good enough compromise. we'll allow potential breakage > if applications/libraries don't care to implement their dependencies > properly. i hope that is weak enough to not occour or be easily fixable > in practice. to help with that, it should be outlined in the docs and > release notes of course. > basically, a rule of thumb for applications will be that if they depend on > glib-2.10 for some reason *and* also depend on gtk+, they should make sure > to at least depend on gtk+-2.8.10. this will be the case for the next > gnome release. and this hackery will need to be propagated to other libraries that currently implement their own floating flag, i suppose... once again, is this really worth it? i mean, we knew about the fundamental desire for a floating flag from gobject 2.0's birth, since it was based on gtkobject, and users have had 4 major releases to design code around it. there's no essentially new information to motivate this change, except maybe the existance of a spare bit in GObject. it seems like just waiting for 3.0 is a nicer, more stable approach. - dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK_FLOATING broken in 2.9?
> There is no problem in this combination. GTK+ 2.8 continues to use the > GtkObject floating flag, > and does not care about the GObject floating flag at all. We decided to > allow finalizing floating GObjects, > so there is no problem. as long as no-one g_object_sink()s a GtkObject, right? - dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK_FLOATING broken in 2.9?
On Thu, Dec 15, 2005 at 12:49:45PM +0100, Tim Janik wrote: > On Wed, 14 Dec 2005, Morten Welinder wrote: > > > > >>before starting to investigate in ugly hacks to continue maintaining the > >>current GTK_FLOATING semantics with GtkObject, i'd really like to raise > >>the issue that people/langauge bnindings most probably never should be > >>setting GTK_FLOATING with GTK_OBJECT_SET_FLAGS. besides the obvious > >>implementation, the only case i saw so far where this was need is > >>in GtkMenu. > > > >Gnumeric's use is in go_combo_popup_reparent which pretty much mirrors > >gtk_menu_reparent. > > > >Note, that GTK_OBJECT_SET_FLAGS is a macro. Fixing it will not help > >programs compiled against, say, gtk+ 2.6 headers. If the user updates > >gtk+, the application breaks, i.e., no ABI stability. > > yes, i'm fully aware of that, it was listed as possible impact > in the original thread: > http://mail.gnome.org/archives/gtk-devel-list/2005-September/msg00165.html this thread never really addressed my concern, which was that this makes it so that container classes before 2.10 have one style, and >=2.10 have another. considering that this change is trying to simplify memory management, i'm dubious. as i origianlly mentioned, my example is g_value_set_object() which clearly should ref_sink(), but clearly cannot for abi compatiblity reasons (though i'm not exactly going to be shocked when a patch goes in that does it anyways...) - dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: Re: GTK_FLOATING broken in 2.9?
On Thu, Dec 15, 2005 at 12:33:52AM -0600, Yevgen Muntyan wrote: > ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN wrote: > > >When you are calling your own code, it is not that > >much to keep track of, but when I write code that is used by 1000 > >developers it is much easier for me to take care of the reference issues > >inside the API and make the large group of unknown developers free from > >unknowingly creating reference counting bugs. > > > > > So, the thousands of another developers now will have to check > documentation for any GObject-derived class to figure out whether > they own reference or not. This is exactly why it's good when you > invent your wrappers, where it's clear that wrapper is made for > purpose and one might be interested in what that wrapper does. > So, if before the usage pattern was: > > object = create_object (); > ... > g_object_unref (object); /* I do know I own it */ > > now it will be > > object = create_object (); > g_object_ref_sink (object); /* who knows what will happen in ... */ > ... > g_object_unref (object); > > Is it really good for glib, the library which is used by all people > using glib, > not just those 1000 unknown developers who are not aware of the need > to free allocated memory? > > These arguments about bugs and stuff are good arguments about why > one should use C++ or whatever other language with some sort of automatic > memory management. C is known not to be safe, and it's known that you > must be careful. After introducing floating references one will still need > to be as careful, but he also will need to check one more thing - floating > reference (or sink it as soon as possible). > Maybe real solution would be for those 1000 guys to use mono or something? > > In short, it's nice that glib will be more safe for those who do not check > what his code does, but if one tries to write safe code, he'll get one more > headache. > > Regards, > Yevgen agreed! the only really solid arguments i've heard for this change are from the people who want a reliable way to get a non-floating refernce (typically for bindings). i've felt that problem myself in writing xml<->object mappings... i personally would prefer a more conceptually-compatible api change, for example, a GObjectClass method to convert a potentially floating reference into a real reference (ala ref_sink), where the floating flag's implementation is deferred to a derived class. people who want floating flags could always derive from GtkObject if they don't want to reimplement it... - dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_slice_
On Sat, Dec 03, 2005 at 10:35:38PM -0500, Behdad Esfahbod wrote: > On Sat, 3 Dec 2005, Morten Welinder wrote: > > > I might be dense, but what exactly does g_slice_ buy us over > > plain, old malloc? > > > > * Don't say speed. That's a bogus argument because you cannot > > possibly have tested all mallocs. > > It's tested with the glibc implementation, and that buys us speed > over the malloc at hand. i have two sort-of related questions: - doesn't this belong in glibc? - why isn't it implemented as g_mem_set_table(g_slice_allocator)? - dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GHashTable ref counting
On Fri, Nov 18, 2005 at 02:12:26PM +0100, Tim Janik wrote: > 3) implement hash table reference counting in GLib natively, also allowing >the use of hash tables as boxed types. to use this, one might want finalization notification on the hash-table itself -- some hashtables don't properly own their data. (although i hate to see the size of GHashTable bloat too much...) also, are you planning on doing the same to GTree? - dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject reference counting / lack of "sink" issue
On Wed, Nov 09, 2005 at 04:23:42PM +0100, Michael Natterer wrote: > On Fri, 2005-09-30 at 01:38 +0200, Tim Janik wrote: > > (snip) > > > so for a change, i'd like to suggest introducing extra API (and do some > > slight > > deprecations) for this and apprechiate people's comments on it: > > > > /* ref() and clear floating flag (#1) */ > > GObject*g_object_ref_sink (GObject *object); > > > > /* figure whether floating flag is set */ > > gbooleang_object_is_floating(GObject *object); > > > > /* intended for object implementations only, sets the floating flag */ > > voidg_object_force_floating (GObject *object); > > (more API details snipped) > > > Better a late response than none at all... > > I would very much appreciate such an API for GObject. GIMP is one of the > examples that contain a 1:1 copy of GtkObject's "floating" feature. > Having it in GObject would allow us (and probably many other projects) > to get rid of this code duplication. since i balked a bit, i think i'd like to rescind my complaint. in my original reply i somehow thought that the default GObject constructor would yield a floating object, which seemed like a recipe for compatibility headaches. i think that the example i pointed out, g_value_set_object() is already confusing with regard to sinking. and i agree that there are definitely benefits to consolidating the floating stuff. (otoh, the more i think about the floating flag, the less i really think it helps anyone, but i does save a few g_object_unrefs i guess, shrug) cheers, dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject reference counting / lack of "sink" issue
On Mon, Oct 03, 2005 at 02:09:27AM -, Andrew Paprocki wrote: > Dave, > > Using the same container example which needs to take ownership of GObjects > passed to the public API -- > The problem we have is that much more time and effort goes into crafting the > core container objects, and having inconsistent public API (two methods) to > add an object to a container is highly undesirable. This leads to confusion > and bugs in our experience. The burden should be placed on the person > designing the container to ensure that the public API calls properly ref/sink > when needed thereby eliminating the burden from the much larger group of > programmers which will be calling the API. > > We have run into consistent problems when writing reusable objects for an > audience of over a thousand developers at our firm. Since callers of the API > are not expected to be fully literate in GObject semantics, pushing the > burden to the caller (requiring them to unref after passing) can lead to > nasty memory leaks. Similarly, creating two API calls to pass an object into > a container is also not desired because it leads to confusion when the > callers are not familiar with GObject's ref-counting implementation. you cannot avoid it in c: you must understand the ref-counting policy. if you wish for thousands of developers to never have a a problem, you should switch languages. - dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject reference counting / lack of "sink" issue
On Fri, Sep 30, 2005 at 01:38:40AM +0200, Tim Janik wrote: > you are right, GObject is widely used these days out of GtkObject contexts, > and anywhere in C land (where memory book keeping or reference house keeping > can't be automized) when objects are created and ownership is passed on, > a floating flag is strongly desired (and forces you to derive and > reimplement > if you're consequent enough ;) while i think that the floating flag is a good idea, i'm pretty skeptical about its addition at this point... in particular, such an addition doesn't modify the api per se, but certainly modifies "best practice". for example, users will have to choose whether certain methods sink or not, and it won't be possible to modify existing api to be consistent. to take an example: g_value_set_object(). once you add a floating flag, it'd be tempting to assume that you can safely: g_value_set_object(value, g_object_new(...)); but changing set_object to sink would break api. and, in my opinion, there already has been invented a nice enough solution to this problem: g_value_take_object(value, g_object_new(...)) if you are implementing a container class simply have my_container_take_object(container, child); and #define my_container_add_object(container,child) \ my_container_take_object(container,g_object_ref(child)) which will actually be more efficient than a bunch of bit-twiddling, and probably easier to understand. - dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: dbus glib bindings: deriving from G_TYPE_BOXED, parameterized types
On Mon, May 16, 2005 at 10:10:17AM -0400, Matthias Clasen wrote: > On Mon, 2005-05-16 at 15:16 +0200, Tim Janik wrote: > > On Fri, 13 May 2005, Matthias Clasen wrote: > > > > > On Fri, 2005-05-13 at 13:01 -0400, Colin Walters wrote: > > > > > As I just pointed out to Colin, using derivation to model the relation > > > between generic types and their specializations is not really adaequate, > > > since you violate the substitution principle: a List can not be > > > substituted for a List, since List promises you to store arbitrary > > > objectds, while List can only store ints (which is why generic > > > types systems like the one in Java 5 don't do it like this). > > > > what kind of substitution is that? having an abstract or very generic > > base type (List) and specialization in derived types (List) is > > fairly common practice in inheritance patterns. > > The principle is that you should be able to treat instances of derived > types as if they were instances of the base type. I guess i don't understand how "List promises you to store arbitrary objects".. How does memory management work? How does the client check the type of elements in the list? It seems like you'd want a List for that... It seems like you *can* treat the derived class as the base class, but the methods of the base class are quite constrained: you can generically reverse a list, or compute its length. But operations like "append" or "remove" doesn't really make sense on the List generic class-- it must be a specific type of list to do type checking. - dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ team irc meeting
Hi, Unfortunately, I have to be out-of-town this weekend, but i would like to call attention to one seeming regression of glib 2.6.1: the inlining apparatus no longer works as advertised. This has been reported as bug 165852, but i'm afraid it starts out with a red-herring: a user misusing G_INLINE_FUNC instead of inline. But there appears to be a very real regression... the header file gutil.h describes the intended usage: /* inlining hassle. for compilers that don't allow the `inline' keyword, * mostly because of strict ANSI C compliance or dumbness, we try to fall * back to either `__inline__' or `__inline'. * G_CAN_INLINE is defined in glibconfig.h if the compiler seems to be * actually *capable* to do function inlining, in which case inline * function bodies do make sense. we also define G_INLINE_FUNC to properly * export the function prototypes if no inlining can be performed. * inline function bodies have to be special cased with G_CAN_INLINE and a * .c file specific macro to allow one compiled instance with extern linkage * of the functions by defining G_IMPLEMENT_INLINES and the .c file macro. */ But alas, ifdef G_IMPLEMENT_INLINES, then G_CAN_INLINE remains defined, (That changed from 2.6.0 to 2.6.1) and so *every header included is implemented*. This causes multiple definition errors of glib inline functions like g_bit_nth_lsf() if you use the inlining apparatus. On the other hand, it's not like #undef G_CAN_INLINE is free: every inline function will be non-inlined, even throughout your implementation. Therefore, i'd recommend people only #define G_IMPLEMENT_INLINES from a file that includes no other code. That would a change of recommendations from earlier glibs, but a sensible one, and one that has always been beneficial for efficiency. - dave On Mon, Mar 28, 2005 at 12:12:43AM -0500, Matthias Clasen wrote: > Since some people may be away on Easter Monday, lets move > the meeting to Tuesday. > > The meeting is intended for the GTK+ team, but everybody is > welcome to come and listen. The meeting logs will be posted > on the GTK+ website (http://www.gtk.org/plan/meetings). > > Place: irc.gnome.org:#gtk-devel > Time: 21:00 UTC (16:00 EST), Tuesday March 29 > > Possible Agenda items: > - Timeframe and patches for 2.6.5 > - Where do we stand wrt to prototypes for 2.8 features ? > > > Matthias > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Introspection API
On Fri, Feb 25, 2005 at 12:12:30PM -0500, John Ehresman wrote: > Dave Benson wrote: > >a small c program to generate GValue marshallers from the metadata > >seems pretty straightforward. such marshallers should probably > >be compiled at the same time as the metadata... i think. > > Yes, but what's the advantage of using compiled marshallers over using > libffi? Are you concerned about portability? I wonder if mozilla uses > libffi or if they have their own mechanism for foreign calls. yeah, portability. it's not very encouraging that everyone seems to adopt their own local copy of libffi. it means trying out glib on new platforms is going to be a pain, subject to bugs, etc. by contrast, generating marshallers is totally portable, and we do it anyways, i believe, for signals. - dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Introspection API
On Fri, Feb 25, 2005 at 11:08:16AM -0500, John Ehresman wrote: > Matthias Clasen wrote: > >Is using libffi or something similar a problem ? > > I think we want to set things up so libffi could be easily used. In > other words, the information that libffi needs should be easily > obtainable from the introspection api. I'd also like not to have to > wrap everything in GValue's if that can be avoided. That said, we need > to figure out how to package libffi for non-gcc compilers such as MS VC++. a small c program to generate GValue marshallers from the metadata seems pretty straightforward. such marshallers should probably be compiled at the same time as the metadata... i think. if some language-binding doesn't like GValue, they could always hack that prorgam to get marshallers in a form they like. - dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
