Re: Lacking of a ref-counted string.
On 25/08/2008, Paul LeoNerd Evans wrote:
On Sat, 23 Aug 2008 Havoc Pennington wrote:
If you're talking about converting existing APIs to refcounted
strings, that's a very different proposal from just adding some kind
of refcounted string feature. It would break thousands of apps, or
else duplicate hundreds of API entry points ...
Personally, I didn't have in mind a change of existing API;
simply an addition of something new:
While moderately handy, GString is nowhere near as useful as it could be, so
I'd say if you're going to add ref-counted strings than it's safe to just add
ref-count directly to GString. I doubt it'll have a notable impact even in
apps where it's not needed. I can't think of any occasion when I've actually
used a bare GString, it just doesn't do anything that can't be done better.
typedef struct {
gchar *str;
gsize len;
gint refcount;
} GCString;
Your GCString, like my ZString below, is somewhat more useful due to the
ref-counting. But until it's supported in a useful way by GLib and GTK
natively, it may as well just be a chunk of text on a wiki page somewhere for
people to copy and paste verbatim into their own projects.
What I generally do is use a very simple GString wrapper;
typedef struct {
GString str;
gint refcount;
} ZString;
and then a bunch of #defines to wrap most of the GString functions with
appropriate type-casting back and forth. The only functions that actually need
re-implementing are the new/free ones. It ain't pretty, but it works.
GCString *g_cstring_new_static(gchar *static_data);
GCString *g_cstring_new_from_gstring(GString *clone);
GCString *g_cstring_ref(GCString *str);
void g_cstring_unref(GCstring *str);
GCString *g_cstring_new(gchar *dynamic_data);
which takes over ownership of an already-allocated string. len and
allocated_len are both set from strlen().
With an allocated_len field you can also indicate static string data by leaving
it at zero. (is_static = str ! allocated_len) That also makes this useful:
GCString *g_cstring_new_full(gchar *dynamic_data, gint len, gint
allocated_len);
which does everything that all three of them do. If len is -ve, it's set from
strlen(), likewise if allocated_len is -ve, it's set from len. _new and
_new_static could then simply be wrappers to _new_full(), although being as
simple as they are it'd probably be better to keep them as discrete functions.
Fredderic
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
2008/8/23 Havoc Pennington [EMAIL PROTECTED]: How much more complicated is it for bindings (most of which use ref-counted strings themselves) to wrap a reference to a string instead of wrapping a whole new copy of the string. This one I can answer: most bindings would have to copy the strings into a native string type just as they do now. A few, maybe Vala and C++, could conceivably avoid the copy. So refcounted strings would not matter much for bindings in general but might help the C-like bindings. Naturally, they wouldn't have to copy the actual string data and you are forgetting all these The returned string is owned by the $something object and should not be freed. All that just magically disappears with ref-counted strings. The bindings become one step simpler because there is one bit less information that they need to account for. -- mvh Björn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Sat, 23 Aug 2008 09:58:12 -0400
Havoc Pennington [EMAIL PROTECTED] wrote:
If you're talking about converting existing APIs to refcounted
strings, that's a very different proposal from just adding some kind
of refcounted string feature. It would break thousands of apps, or
else duplicate hundreds of API entry points ...
Personally, I didn't have in mind a change of existing API; simply an
addition of something new:
typedef struct {
gchar *str;
gsize len;
gint refcount;
} GCString;
GCString *g_cstring_new_static(gchar *data);
GCString *g_cstring_new_from_gstring(GString *clone);
GCString *g_cstring_ref(GCString *str);
void g_cstring_unref(GCstring *str);
should be sufficient for immutable strings. copy-on-write mutable ones
would probably want allocated length in the struct too, and add something
like
GCString *g_cstring_dup(GCString *clone);
which can then sit in the beginning of the modifier functions, looking
something like
GCstring *g_cstring_append(GCstring *s, gchar *data)
{
if(s-refcount 1)
s = g_cstring_dup(s);
/* now modify s */
return s;
}
From my experience using GString I'd find the following macro useful;
#define GCSTR(s) (s?s-str:NULL)
Then you can
printf(Hello, my name is %s\n, GCSTR(s));
a little safer.
Or note that C requires the address of a struct must be the address of
its first member; so a simple cast is sufficient
printf(Hello, my name is %s\n, (gchar*)s);
--
Paul LeoNerd Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: PGP signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Wed, 2008-08-20 at 21:07 -0400, Havoc Pennington wrote: Hi, On Wed, Aug 20, 2008 at 8:47 PM, Yu Feng [EMAIL PROTECTED] wrote: First, it is very difficult to manage a string without a reference count. The current vala implementation is to assume that strings are immutable, and to copy the strings almost everywhere where increasing the ref-count should be used. The copying mechanism produces workable code, but doesn't work in a efficient way. This is where it hurts. Secondly, vala doesn't introduce any additional dependency other than GLib, to implement it in VALA level, the only way is to embed it in the compiler. A compiler with embeded code to do a ref-counted string doesn't sound nice. This is why I think it should be done at GLib level. If we think of GLib features as either for C, or for language bindings in general, or for vala, this particular feature seems like it would be *only* for vala - refcounted strings would be pretty strange in plain C, and just overhead for other language bindings that already have native string types they have to convert gchar* to. Putting only-useful-for-vala features in GLib would seem odd to me. Just one opinion, though. Can't vala do the same optimizations a C programmer would do by hand in most cases - avoiding a copy for a const char* that is only stored temporarily in local scope, for example? For other cases, a plain C program would have the same inefficiencies as vala it seems like, and they are not fatal inefficiencies... What about a libvala? I guess vala is supposed to have this property that it doesn't create dependencies in distributed tarballs, but that design goal has brought us autoconf and libtool in the past... not sure I'm sold on it. Or then, embedding it in the compiler does not seem like a very big deal - it's just two operations ref and unref, both of which are trivial and can just be inlined... Havoc I think we are confusing issues here Its GString and not char * which needs the ref counting Other languages (C++ and Delphi) both use ref counting for their strings and they are invaluable to C devs too who do multi-threaded stuff. This is clearly not vala specific as a result (ever tried to free a string correctly where its used in multiple threads?) At the moment there is an inconsistent split between glib structures like GHashTable which use ref counting and the others (GList, GString et all) which dont. I do hope GLib 3 will fix this jamie ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Wed, 2008-08-20 at 21:18 -0400, Colin Walters wrote: On Wed, Aug 20, 2008 at 9:07 PM, Havoc Pennington [EMAIL PROTECTED] wrote: What about a libvala? I guess vala is supposed to have this property that it doesn't create dependencies in distributed tarballs, but that design goal has brought us autoconf and libtool in the past... not sure I'm sold on it. Another nail in the no-libvala idea's coffin is that it seems to me[1] it's a violation of the GPL to distribute code that doesn't build using the preferred form of the work for making modifications to it (GPL sec 3). In other words, generated .c files are no different from .jars and the like, and free OS vendors should not allow software which includes them. [1] IANAL etc. Thats obviously not the case Are you saying Yacc/Bison and lex/flex source files which generate c files are also incompatible with GPL? if so a whole load of software is in violation (including gcc) jamie ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Wed, 2008-08-20 at 21:49 -0400, Colin Walters wrote: On Wed, Aug 20, 2008 at 9:39 PM, Jamie McCracken [EMAIL PROTECTED] wrote: Are you saying Yacc/Bison and lex/flex source files which generate c files are also incompatible with GPL? Of course not; it's perfectly valid in general to have code generate code. But if your build process doesn't invoke yacc or bison but just relies on the shipped generated .c files, that is a problem. not a problem if the vala source and means to build them using valac and makefiles are publically available. GPL only affects distribution so if you also make the original vala source distributable (separately or in the same package with the same terms) then it should not be an issue In any case, distros can always use valac to build anything written in vala (or genie) so im not sure why any of this matters? jamie ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
From: Havoc Pennington Date: 23/08/2008 23:58 On Sat, Aug 23, 2008 at 8:29 AM, Freddie Unpenstein This issue comes up repeatedly, and each time the response is to ask for proof that it would make things better. How about the opposite, where's the proof that it would make things worse? In software, everything starts with proof it makes things worse, because changing code definitely takes time and introduces bugs ... I mean that in all seriousness. This is especially true for API changes that ripple through hundreds or even thousands of third-party apps, which is what most GLib changes are. So if you do a pros and cons list on any GLib change, there is a big con, right up front, 100% known. Yes, of that I am well aware. That's always the first answer that people throw out. Personally, I like it make it the last, because even if you don't go with it, there's a good chance some interesting ideas worth pursuing will come out in the meantime. It just annoys me when someone responds to a perfectly good proposal with that alone. Anyway... on ref-counted strings, I don't really remember this thread happening before (archive link?) so I'm not sure it comes up repeatedly. I'm partial to this topic myself, which is probably why I take note when it comes around every so often. It tends to get side-swiped rather than tackled head-on, more as a means to another end. But the idea of improving strings in general, has popped up three times just recently. There was the issue about avoiding the need to sanity-check strings, there's discussions about encodings, etc. A concerted push for some kind of enhanced string API would make dealing with these things intelligently a whole lot more realistic. I'm not sure anyone on this thread has seriously proposed changing the whole stack of GTK APIs to use refcounted strings - certainly nobody has really written up what that would mean in detail, and tried to analyze pros and cons. If you're proposing this, I would say step back and explain what the actual proposal is, before addressing the objections ;-) I am sure people have hinted at it, and been shot down with the too hard argument right off the bat. At that point they don't take it to the point of being a serious proposal. But we have a push to seal the API's going on, and there are mutterings of changing the entire GTK stack to be entirely more flexible because it's hitting fundamental limitations that are blocking some new ideas. These are changes in the same scope as what I'm trying to get some real serious proposing about. It's about time someone DID seriously propose it, with that one guaranteed too hard issue put aside for the moment, figure out whether it IS worth doing in its own right, and THEN about whether it can be done. Because personally, I believe it could be done progressively. My proposal is ref-counting and copy-on-write-if-unshared semantics. I got used to it in a scripting environment, and then when I finally understood exactly how they were doing it, I realised it's exactly the same practice as I've been using for over a decade all over the place, both in my own stuff and in other languages, etc. Exactly how much slower would GTK get if it had to ref-count instead of copy strings everywhere If you're talking about converting existing APIs to refcounted strings, that's a very different proposal from just adding some kind of refcounted string feature. It would break thousands of apps, or else duplicate hundreds of API entry points ... GTK 3. You start by changing the suitable API portions, and wrapping the corresponding string arguments with a type-casting #define, and simply reverting it back on the inside. That's a fairly tedious change but isn't likely to break very much. Then you start to actually change things as you go, starting with just the widgets being actively worked on, and work your way out from there. Once you have an opaque string entity, you can start to seriously look at the pros and cons of various enhancements. Until then it's just farting in the wind, if you'll forgive the expression. Heck, even go ahead and duplicate those API entry points, and phase out the old ones in GTK 4. Not EVERY string needs to be ref-counted, as I said in my previous message. Just the ones that get held in an objects and given back or passed on to another one later. Several of the major updates planned are going to have to do much the same radical API change themselves, though on a slightly smaller scope. Again, what I really want at this point, is for someone who knows enough about this kind of experimentation to get off the too hard track long enough to get some real idea of how it would affect things one the transition is complete. I've done this kind of API change in my own code, where I'm building a new widget that will have strings hanging around all of its own, and I've found it generally to be a good thing.
Re: Lacking of a ref-counted string.
On Wed, 20 Aug 2008 21:07:39 -0400 Havoc Pennington wrote: If we think of GLib features as either for C, or for language bindings in general, or for vala, this particular feature seems like it would be *only* for vala - refcounted strings would be pretty strange in plain C, and just overhead for other language bindings that already have native string types they have to convert gchar* to. I personally have quite often wanted refcounted GStrings in normal programs that I've written; i.e. entirely unrelated to VALA. This issue comes up repeatedly, and each time the response is to ask for proof that it would make things better. How about the opposite, where's the proof that it would make things worse? Exactly how much slower would GTK get if it had to ref-count instead of copy strings everywhere, and how much more memory would it consume if it had to share a pointer instead of duplicating every string that gets passed in or out of a widget. How less stable will GTK be with proper string lifetime management built-in. How much more complicated is it for bindings (most of which use ref-counted strings themselves) to wrap a reference to a string instead of wrapping a whole new copy of the string. Strings can be significant, too, especially if you start writing them in some of the other multi-byte scripts supported by UTF-8, and quite frequently GTK will copy a string simply so that the programmer doesn't have to concern themselves with managing its lifetime until GTK is finished with it. Then when you ask for it back, sometimes you'll get a copy which you have to free when you're done with. And if in the meantime you give it to another widget, or even even back to a different property of the same widget, yet another copy gets made. And then there's g_strdup_printf() which is about the only decently safe way to use the printf() family of functions. And there you end up creating a string, handing it off to a GTK widget which immediately makes its own copy, and then you turn right around and g_free() it again. The alternative is to pre-calculate and pre-allocate memory for it, but that opens you up to the possibility of small off-by-1 errors, is generally fiddly and error-prone, is generally what g_strdup_printf() is supposed to make better. And still ends up being copied. A few times I've taken the source code to a widget, re-worked it to use ref-counted strings, and it certainly seemed an improvement to me. I could create a string, pass it into several properties of the widget, bring it back again, all without making a copy until I wanted to change it. The ref-counted strings are only needed where the value of a string is going to be retained, so a function that throws away the value and only keeps some computed result from it, doesn't need to bother with ref-counted strings at all, but that doesn't mean you can't pass in the raw C string from a ref-counted string. And I'm pretty sure addition and subtraction of a reference is a lot cleaner than returning a string just to have it g_free()'d by the caller. I can't very well do that with every widget I use, however, which is why I've been thinking of switching to using C++ The last argument I often hear against ref-counted strings, is thread-safety. What does that have to do with GTK, where you do all your GUI work from a single thread and use other threads as workers only. And just how is it any different to any other non-trivial GLib structure? If you want it to be thread-safe, you need to do some extra work to make it so. And of course you would use copy-on-write for any shared string, which makes it safe to pass around pretty much however you wish without having to worry. Simply duplicate and unref before you change it in any way, it still seems a great deal better than having to duplicate the string several times whether you change it or not. Maybe the GTK guru's don't need ref-counting and other tricks to be able to manipulate and pass around strings safely and efficiently, but the rest of us mere mortals could sure do with it. Personally I'd be happy with a GString that has type, ref-count, length, and gchar* members, where type refers to a structure containing the standard set of string operations, including conversion into and from GTK's native UTF-8. Having a different string type for I/O (including file names) compared to strings passed around GTK, protects us from encoding issues by allowing GTK widgets to safely assume their strings are correct simply by feeding them through a g_string_to_native() function (could even be done as a #define for efficiency) that will duplicate and convert if needed, or pass it through unchanged otherwise. But even just ref-counting alone would help, and even if it hurts efficiency a little, I fully believe it would be worth it. Fredderic ___ gtk-devel-list mailing list
Re: Lacking of a ref-counted string.
Hi, On Sat, Aug 23, 2008 at 8:29 AM, Freddie Unpenstein [EMAIL PROTECTED] wrote: This issue comes up repeatedly, and each time the response is to ask for proof that it would make things better. How about the opposite, where's the proof that it would make things worse? In software, everything starts with proof it makes things worse, because changing code definitely takes time and introduces bugs ... I mean that in all seriousness. This is especially true for API changes that ripple through hundreds or even thousands of third-party apps, which is what most GLib changes are. So if you do a pros and cons list on any GLib change, there is a big con, right up front, 100% known. I think that leads to an appropriate conservatism. For code that's in an app and not used by anyone else, you wouldn't want to see the same conservatism. Anyway... on ref-counted strings, I don't really remember this thread happening before (archive link?) so I'm not sure it comes up repeatedly. I'm not sure anyone on this thread has seriously proposed changing the whole stack of GTK APIs to use refcounted strings - certainly nobody has really written up what that would mean in detail, and tried to analyze pros and cons. If you're proposing this, I would say step back and explain what the actual proposal is, before addressing the objections ;-) Exactly how much slower would GTK get if it had to ref-count instead of copy strings everywhere If you're talking about converting existing APIs to refcounted strings, that's a very different proposal from just adding some kind of refcounted string feature. It would break thousands of apps, or else duplicate hundreds of API entry points ... How much more complicated is it for bindings (most of which use ref-counted strings themselves) to wrap a reference to a string instead of wrapping a whole new copy of the string. This one I can answer: most bindings would have to copy the strings into a native string type just as they do now. A few, maybe Vala and C++, could conceivably avoid the copy. So refcounted strings would not matter much for bindings in general but might help the C-like bindings. The last argument I often hear against ref-counted strings, is thread-safety. I thought people were using that as an argument _for_ refcounted strings. (Though I agree with your sentiment that GLib's approach to threads is not to make each individual data structure transparently thread safe.) But even just ref-counting alone would help, and even if it hurts efficiency a little, I fully believe it would be worth it. While I don't know what you're proposing in detail, I can't imagine efficiency is the issue. Huge API changes would be a much, much more significant factor. The other potentially obvious factor is programming convenience; refcounted strings in the GTK APIs would make some things easier, but other things (such as passing in a string literal) harder. Illustrating a particular proposal by porting some sample apps might demo these tradeoffs. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Wed, 20 Aug 2008 21:07:39 -0400 Havoc Pennington [EMAIL PROTECTED] wrote: If we think of GLib features as either for C, or for language bindings in general, or for vala, this particular feature seems like it would be *only* for vala - refcounted strings would be pretty strange in plain C, and just overhead for other language bindings that already have native string types they have to convert gchar* to. I personally have quite often wanted refcounted GStrings in normal programs that I've written; i.e. entirely unrelated to VALA. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
2008/8/21 Yu Feng [EMAIL PROTECTED]: On Wed, 2008-08-20 at 17:59 -0400, Havoc Pennington wrote: Hi, On Wed, Aug 20, 2008 at 3:10 PM, Yu Feng [EMAIL PROTECTED] wrote: Is there any particular reason that GLib doesn't provide a ref-counted string and a ref-counted array type? Lacking them in GLib makes the VALA language a real pain. I think you would have to explain more why this is an issue for vala, at least for me (maybe everyone else already knows) OK. Vala claims automatic memory management and a programming language on top of GLib. First, it is very difficult to manage a string without a reference count. The current vala implementation is to assume that strings are immutable, and to copy the strings almost everywhere where increasing the ref-count should be used. The copying mechanism produces workable code, but doesn't work in a efficient way. This is where it hurts. Secondly, vala doesn't introduce any additional dependency other than GLib, to implement it in VALA level, the only way is to embed it in the compiler. A compiler with embeded code to do a ref-counted string doesn't sound nice. This is why I think it should be done at GLib level. How about using a GStringChunk and apply some magic compile-time logic? Although I am not quite sure how it should be done - you are the wizards :-) It could maybe also make more sense to add some more API to GStringChunk as it is quite limited as it stands. Cheers, Mikkel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Wed, Aug 20, 2008, Colin Walters wrote: Another nail in the no-libvala idea's coffin is that it seems to me[1] it's a violation of the GPL to distribute code that doesn't build using the preferred form of the work for making modifications to it (GPL sec 3). In other words, generated .c files are no different from .jars and the like, and free OS vendors should not allow software which includes them. On Wed, Aug 20, 2008, Colin Walters wrote: Are you saying Yacc/Bison and lex/flex source files which generate c files are also incompatible with GPL? Of course not; it's perfectly valid in general to have code generate code. But if your build process doesn't invoke yacc or bison but just relies on the shipped generated .c files, that is a problem. It's ok to rely on the generated files to be present in tarball releases and to use them exclusively for building, but you have to provide the real source files along with the rules to generate the others; this could be anywhere, but it's best to keep them in the tarball. (This is exactly the same thing as e.g. configure.in.) -- Loïc Minier ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Thu, 2008-08-21 at 07:57 +0200, Ali Sabil wrote: First, it is very difficult to manage a string without a reference count. The current vala implementation is to assume that strings are immutable, and to copy the strings almost everywhere where increasing the ref-count should be used. The copying mechanism produces workable code, but doesn't work in a efficient way. This is where it hurts. I am not quite sure, to me you seem to mix up copy on write string and shared buffers, copy on write strings are just an optimization, and they don't need to be in GLib. Concerning shared buffers, string are *not* used in vala for shared buffers, simply because a string in vala is a utf-8 encoded *immutablle* byte sequences. a byte buffer is represented using uchar[]. Right now vala supports is pretty young concerning array supports, they are hard to manage in the first place because of the C quirks (null terminated arrays, vs arrays with an extra parameter to specify the length). To keep it simple, why don't you just write a ByteBuffer class inheriting from GObject ? I don't know see any reasons. Secondly, vala doesn't introduce any additional dependency other than GLib, to implement it in VALA level, the only way is to embed it in the compiler. A compiler with embeded code to do a ref-counted string doesn't sound nice. This is why I think it should be done at GLib level. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Thu, 2008-08-21 at 12:18 +0200, Mikkel Kamstrup Erlandsen wrote: 2008/8/21 Yu Feng [EMAIL PROTECTED]: On Wed, 2008-08-20 at 17:59 -0400, Havoc Pennington wrote: Hi, On Wed, Aug 20, 2008 at 3:10 PM, Yu Feng [EMAIL PROTECTED] wrote: Is there any particular reason that GLib doesn't provide a ref-counted string and a ref-counted array type? Lacking them in GLib makes the VALA language a real pain. I think you would have to explain more why this is an issue for vala, at least for me (maybe everyone else already knows) OK. Vala claims automatic memory management and a programming language on top of GLib. First, it is very difficult to manage a string without a reference count. The current vala implementation is to assume that strings are immutable, and to copy the strings almost everywhere where increasing the ref-count should be used. The copying mechanism produces workable code, but doesn't work in a efficient way. This is where it hurts. Secondly, vala doesn't introduce any additional dependency other than GLib, to implement it in VALA level, the only way is to embed it in the compiler. A compiler with embeded code to do a ref-counted string doesn't sound nice. This is why I think it should be done at GLib level. How about using a GStringChunk and apply some magic compile-time logic? Although I am not quite sure how it should be done - you are the wizards :-) It could maybe also make more sense to add some more API to GStringChunk as it is quite limited as it stands. I will investigate into this. It seems at least a g_string_chunk_remove has to be added. Thanks Yu Cheers, Mikkel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
2008/8/20 Ali Sabil [EMAIL PROTECTED]: On Wed, Aug 20, 2008 at 9:15 PM, Bastien Nocera [EMAIL PROTECTED] wrote: On Wed, 2008-08-20 at 15:10 -0400, Yu Feng wrote: Is there any particular reason that GLib doesn't provide a ref-counted string and a ref-counted array type? Lacking them in GLib makes the VALA language a real pain. You could just wrap simple GObjects around GString and GPtrArray. Wouldn't that be overkill ? do we need signals and properties for strings and arrays ? maybe GLib/GObject should have something like GstMiniObject that only provides reference counting and no signals/properties ? It's quite easy to make an immutable refcounted string with GValue. This should be quite a bit lighter than a GObject implementation. Fwiw, my code is here: http://vips.svn.sourceforge.net/viewvc/vips/vips7/trunk/libsrc/iofuncs/meta.c?view=markup search for 'refstring'. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Thu, 2008-08-21 at 12:18 +0200, Mikkel Kamstrup Erlandsen wrote: 2008/8/21 Yu Feng [EMAIL PROTECTED]: On Wed, 2008-08-20 at 17:59 -0400, Havoc Pennington wrote: Hi, On Wed, Aug 20, 2008 at 3:10 PM, Yu Feng [EMAIL PROTECTED] wrote: Is there any particular reason that GLib doesn't provide a ref-counted string and a ref-counted array type? Lacking them in GLib makes the VALA language a real pain. I think you would have to explain more why this is an issue for vala, at least for me (maybe everyone else already knows) OK. Vala claims automatic memory management and a programming language on top of GLib. First, it is very difficult to manage a string without a reference count. The current vala implementation is to assume that strings are immutable, and to copy the strings almost everywhere where increasing the ref-count should be used. The copying mechanism produces workable code, but doesn't work in a efficient way. This is where it hurts. Secondly, vala doesn't introduce any additional dependency other than GLib, to implement it in VALA level, the only way is to embed it in the compiler. A compiler with embeded code to do a ref-counted string doesn't sound nice. This is why I think it should be done at GLib level. How about using a GStringChunk and apply some magic compile-time logic? Although I am not quite sure how it should be done - you are the wizards :-) It could maybe also make more sense to add some more API to GStringChunk as it is quite limited as it stands. Perhaps not since GStringChunk is not thread-safe and can't be globally held. and adding one for each thread is insane. Cheers, Mikkel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Wed, 2008-08-20 at 15:10 -0400, Yu Feng wrote: Dear Devs, Is there any particular reason that GLib doesn't provide a ref-counted string and a ref-counted array type? Lacking them in GLib makes the VALA language a real pain. Is it possible to introduce them in the next major ABI breaking? When will the breaking be? For a very light-weight implementation of refcounted strings, see EelRefString in http://svn.gnome.org/viewvc/eel/trunk/eel/eel-string.c?view=markup ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
The concept of a copy-on-write string really only makes sense in a language like C++, where classes are copied implicitely all the time. In a reference counted language, the kinds of copies that make naive std::string implementations so suboptimal, are already solved by the structure of the language. Btw, I believe most stl implementations moved away from the copy on write model, because it was really hard to do in a thread safe way, while still supporting the full std::string interface. On 8/21/08, Hubert Figuiere [EMAIL PROTECTED] wrote: On Wed, 2008-08-20 at 20:47 -0400, Yu Feng wrote: First, it is very difficult to manage a string without a reference count. The current vala implementation is to assume that strings are immutable, and to copy the strings almost everywhere where increasing the ref-count should be used. The copying mechanism produces workable code, but doesn't work in a efficient way. This is where it hurts. Maybe having a copy-on-write implementation (in Vala) of the string type is what you want. That way, when you need mutability, you copy. That's the choice made by std::string and Glib::ustring (in glibmm that is incidentaly implemented using std::string) in C++ and transcribe pretty well the usage case. Secondly, vala doesn't introduce any additional dependency other than GLib, to implement it in VALA level, the only way is to embed it in the compiler. A compiler with embeded code to do a ref-counted string doesn't sound nice. This is why I think it should be done at GLib level. That's a design choice, but it seem to be unavoidable to have a runtime library at one point. All the other language have one, more or less. Pascal, Java (libcj), Objective-C, Fortran, C++ and even C. I guess it is no exception for Vala. Hub ___ 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: Lacking of a ref-counted string.
On Wed, 2008-08-20 at 15:10 -0400, Yu Feng wrote: Dear Devs, Is there any particular reason that GLib doesn't provide a ref-counted string and a ref-counted array type? Lacking them in GLib makes the VALA language a real pain. You could just wrap simple GObjects around GString and GPtrArray. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
Is it possible to introduce them in the next major ABI breaking? New API can be introduced in any new minor version. (And has been, every time.) Adding new API doesn't break any old API or ABI. --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Wed, Aug 20, 2008 at 9:15 PM, Bastien Nocera [EMAIL PROTECTED] wrote: On Wed, 2008-08-20 at 15:10 -0400, Yu Feng wrote: Dear Devs, Is there any particular reason that GLib doesn't provide a ref-counted string and a ref-counted array type? Lacking them in GLib makes the VALA language a real pain. You could just wrap simple GObjects around GString and GPtrArray. Wouldn't that be overkill ? do we need signals and properties for strings and arrays ? maybe GLib/GObject should have something like GstMiniObject that only provides reference counting and no signals/properties ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
Hi, On Wed, Aug 20, 2008 at 3:10 PM, Yu Feng [EMAIL PROTECTED] wrote: Is there any particular reason that GLib doesn't provide a ref-counted string and a ref-counted array type? Lacking them in GLib makes the VALA language a real pain. I think you would have to explain more why this is an issue for vala, at least for me (maybe everyone else already knows) The first question is whether a solution goes in glib or in vala, which kind of depends on what the specific problems are. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Wed, 2008-08-20 at 17:59 -0400, Havoc Pennington wrote: Hi, On Wed, Aug 20, 2008 at 3:10 PM, Yu Feng [EMAIL PROTECTED] wrote: Is there any particular reason that GLib doesn't provide a ref-counted string and a ref-counted array type? Lacking them in GLib makes the VALA language a real pain. I think you would have to explain more why this is an issue for vala, at least for me (maybe everyone else already knows) OK. Vala claims automatic memory management and a programming language on top of GLib. First, it is very difficult to manage a string without a reference count. The current vala implementation is to assume that strings are immutable, and to copy the strings almost everywhere where increasing the ref-count should be used. The copying mechanism produces workable code, but doesn't work in a efficient way. This is where it hurts. Secondly, vala doesn't introduce any additional dependency other than GLib, to implement it in VALA level, the only way is to embed it in the compiler. A compiler with embeded code to do a ref-counted string doesn't sound nice. This is why I think it should be done at GLib level. The first question is whether a solution goes in glib or in vala, which kind of depends on what the specific problems are. Havoc Yu ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Wed, Aug 20, 2008 at 9:07 PM, Havoc Pennington [EMAIL PROTECTED] wrote: What about a libvala? I guess vala is supposed to have this property that it doesn't create dependencies in distributed tarballs, but that design goal has brought us autoconf and libtool in the past... not sure I'm sold on it. Another nail in the no-libvala idea's coffin is that it seems to me[1] it's a violation of the GPL to distribute code that doesn't build using the preferred form of the work for making modifications to it (GPL sec 3). In other words, generated .c files are no different from .jars and the like, and free OS vendors should not allow software which includes them. [1] IANAL etc. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Wed, Aug 20, 2008 at 9:39 PM, Jamie McCracken [EMAIL PROTECTED] wrote: Are you saying Yacc/Bison and lex/flex source files which generate c files are also incompatible with GPL? Of course not; it's perfectly valid in general to have code generate code. But if your build process doesn't invoke yacc or bison but just relies on the shipped generated .c files, that is a problem. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Wed, 2008-08-20 at 20:47 -0400, Yu Feng wrote: First, it is very difficult to manage a string without a reference count. The current vala implementation is to assume that strings are immutable, and to copy the strings almost everywhere where increasing the ref-count should be used. The copying mechanism produces workable code, but doesn't work in a efficient way. This is where it hurts. Maybe having a copy-on-write implementation (in Vala) of the string type is what you want. That way, when you need mutability, you copy. That's the choice made by std::string and Glib::ustring (in glibmm that is incidentaly implemented using std::string) in C++ and transcribe pretty well the usage case. Secondly, vala doesn't introduce any additional dependency other than GLib, to implement it in VALA level, the only way is to embed it in the compiler. A compiler with embeded code to do a ref-counted string doesn't sound nice. This is why I think it should be done at GLib level. That's a design choice, but it seem to be unavoidable to have a runtime library at one point. All the other language have one, more or less. Pascal, Java (libcj), Objective-C, Fortran, C++ and even C. I guess it is no exception for Vala. Hub ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
Hi, On Wed, Aug 20, 2008 at 9:31 PM, Jamie McCracken [EMAIL PROTECTED] wrote: Its GString and not char * which needs the ref counting That seems fine. But GString is just a temporary buffer (it's like StringBuffer/Builder in Java, not like String in Java). It's virtually never passed around in APIs. The way g_string_free() works is incompatible with refcounting, though. Perhaps g_string_free() could assert that the refcount is 1. The g_string_free() API does illustrate what GString is intended for (a way to create a char*) At the moment there is an inconsistent split between glib structures like GHashTable which use ref counting and the others (GList, GString et all) which dont. I do hope GLib 3 will fix this I think the philosophy is that refcounting (and thread locking) work best on a bit less granular a level, such as an object or struct. In my experience that is pretty safe to say, when coding in C. And languages (other than vala) have their own lists, strings, refcounting/GC schemes, and thread safety schemes. When GTK or GLib needs to do strings in a threadsafe way it normally just copies them. The other option of course is to make them refcounted and immutable, but GString (like StringBuffer/Builder) is the opposite of immutable. We could have a refcounted GString that is immutable, but that has pretty much nothing to do with current GString. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
First, it is very difficult to manage a string without a reference count. The current vala implementation is to assume that strings are immutable, and to copy the strings almost everywhere where increasing the ref-count should be used. The copying mechanism produces workable code, but doesn't work in a efficient way. This is where it hurts. I am not quite sure, to me you seem to mix up copy on write string and shared buffers, copy on write strings are just an optimization, and they don't need to be in GLib. Concerning shared buffers, string are *not* used in vala for shared buffers, simply because a string in vala is a utf-8 encoded *immutablle* byte sequences. a byte buffer is represented using uchar[]. Right now vala supports is pretty young concerning array supports, they are hard to manage in the first place because of the C quirks (null terminated arrays, vs arrays with an extra parameter to specify the length). To keep it simple, why don't you just write a ByteBuffer class inheriting from GObject ? Secondly, vala doesn't introduce any additional dependency other than GLib, to implement it in VALA level, the only way is to embed it in the compiler. A compiler with embeded code to do a ref-counted string doesn't sound nice. This is why I think it should be done at GLib level. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
