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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
28 matches
Mail list logo
