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 t
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
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
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 go
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, an
satisifed with what Juerg et al have produced for me...)
Sam
-Original Message-
From: Ali Sabil <[EMAIL PROTECTED]>
Sent: Wednesday, August 20, 2008 9:25 PM
To: Bastien Nocera <[EMAIL PROTECTED]>
Cc: gtk-devel-list ; Vala Mailing list <[EMAIL
PROTECTED]>
Subject: Re: [Va
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 dupli
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?
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, everyt
> 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
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
> pl
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 langua
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 b
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 th
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 th
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 th
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
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 .
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?
>
>
> 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
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 i
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 c
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, 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
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-coun
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
> > langu
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
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
> 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@gnom
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 GPtrA
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?
Regards,
Yu
31 matches
Mail list logo
