The last collective release was only two months ago.
As far as the ABI is concerned that is certainly an issue. The last time
we discussed it we came up with two solutions:
- Pad the ivar-structures in the classes out to give space to grow so
that it pushes off any ABI compatibility issue
On 5 Mar 2009, at 16:10, Gregory Casamento wrote:
The last collective release was only two months ago.
As far as the ABI is concerned that is certainly an issue. The
last time we discussed it we came up with two solutions:
• Pad the ivar-structures in the classes out to give space to grow
On 5 Mar 2009, at 16:10, Gregory Casamento wrote:
The last collective release was only two months ago.
As far as the ABI is concerned that is certainly an issue. The
last time we discussed it we came up with two solutions:
• Pad the ivar-structures in the classes out to give space to grow
On 5 Mar 2009, at 20:27, David Chisnall wrote:
On 5 Mar 2009, at 16:10, Gregory Casamento wrote:
The last collective release was only two months ago.
As far as the ABI is concerned that is certainly an issue. The
last time we discussed it we came up with two solutions:
• Pad the ivar-s
Hi
I dont understand this problem about ABI and binary compatibility, so
please excuse me if this looks stupid :\
The problem comes from ivars that would not be always at the same
offset, doesn't it ? But these ivars are supposed to be private, dont
they ? So the code that uses these ivars is al
Xavier Glattard wrote:
> The problem comes from ivars that would not be always at the same
> offset, doesn't it ? But these ivars are supposed to be private, dont
> they ? So the code that uses these ivars is always released along with
> the class interface. I can not find any official 'public' iva
On 6 Mar 2009, at 07:05, Xavier Glattard wrote:
Hi
I dont understand this problem about ABI and binary compatibility, so
please excuse me if this looks stupid :\
The problem comes from ivars that would not be always at the same
offset, doesn't it ? But these ivars are supposed to be private,
В Thu, 05 Mar 2009 11:10:42 -0500, Gregory Casamento написа:
> As far as the ABI is concerned that is certainly an issue.
The real issue is the gratuitous/frivolous SONAME bump when there are
only API additions. Users and distributors are forced to recompile
everything unnecessarily and this ca
Richard Frith-Macdonald a écrit :
On 6 Mar 2009, at 07:05, Xavier Glattard wrote:
Hi
I dont understand this problem about ABI and binary compatibility, so
please excuse me if this looks stupid :\
The problem comes from ivars that would not be always at the same
offset, doesn't it ? But thes
On 6 Mar 2009, at 09:15, Xavier Glattard wrote:
Richard Frith-Macdonald a écrit :
On 6 Mar 2009, at 07:05, Xavier Glattard wrote:
Hi
I dont understand this problem about ABI and binary compatibility,
so
please excuse me if this looks stupid :\
The problem comes from ivars that would not
Richard Frith-Macdonald a écrit :
On 6 Mar 2009, at 09:15, Xavier Glattard wrote:
Richard Frith-Macdonald a écrit :
On 6 Mar 2009, at 07:05, Xavier Glattard wrote:
Hi
I dont understand this problem about ABI and binary compatibility, so
please excuse me if this looks stupid :\
The proble
Am Freitag, den 06.03.2009, 06:17 + schrieb Richard Frith-Macdonald:
> I feel we probably need to break things in trunk during the
> development cycle to get a reaction and some suggestions from other
> people. For instance I asked for ideas about the change to using
> NSUInteger,NSInte
Hi
I dont understand this problem about ABI and binary compatibility, so
please excuse me if this looks stupid :\
The problem comes from ivars that would not be always at the same
offset, doesn't it ? But these ivars are supposed to be private, dont
they ? So the code that uses these ivars i
Hi,
Gregory Casamento wrote:
> The last collective release was only two months ago.
>
> As far as the ABI is concerned that is certainly an issue. The last time
> we discussed it we came up with two solutions:
>
>
>
> I, personally, think we should implement the first option. It's the meth
On 7 Mar 2009, at 08:30, Riccardo Mottola wrote:
- I do not want any additional runtime overhead. Performance needs
to be
maximum. Always.
Don't use Objective-C then. The language compromises performance for
flexibility all of the time. How much in GNUstep is CPU-bound? Most
of the bo
Hi,
David Chisnall wrote:
> On 7 Mar 2009, at 08:30, Riccardo Mottola wrote:
>
>> - I do not want any additional runtime overhead. Performance needs to be
>> maximum. Always.
>
> Don't use Objective-C then. The language compromises performance for
> flexibility all of the time. How much in GNUst
Riccardo Mottola a écrit :
(...)
David Chisnall wrote:
(...)
Yes, this appears to me the "least hurting" path. But I laready dislike.
If we really need, this should be the road.
If you make private ivars into a structure and make a pointer to this
an ivar, you add an extra malloc for every +a
On 10 Mar 2009, at 10:28, Xavier Glattard wrote:
Riccardo Mottola a écrit :
(...)
David Chisnall wrote:
(...)
Yes, this appears to me the "least hurting" path. But I laready
dislike.
If we really need, this should be the road.
If you make private ivars into a structure and make a pointer t
David Chisnall a écrit :
On 10 Mar 2009, at 10:28, Xavier Glattard wrote:
Riccardo Mottola a écrit :
(...)
David Chisnall wrote:
(...)
Yes, this appears to me the "least hurting" path. But I laready dislike.
If we really need, this should be the road.
If you make private ivars into a str
On 10 Mar 2009, at 14:27, Xavier Glattard wrote:
David Chisnall a écrit :
The extra bytes are allocated after the object, which would be
completely useless. Imagine:
(...)
Now you add another ivar to A and remove the extra bytes, and you
have this layout:
id isa;// offset 0
int
On 10 Mar 2009, at 14:27, Xavier Glattard wrote:
The extra bytes are already used in some class in GNUstep (GSString,
GSArray...) and AKAIK there is no problem with system arch.
This is only used for private subclasses which cannot themselves be
subclassed.
I would not recommend using th
David Chisnall a écrit :
On 10 Mar 2009, at 14:27, Xavier Glattard wrote:
David Chisnall a écrit :
The extra bytes are allocated after the object, which would be
completely useless. Imagine:
(...)
Now you add another ivar to A and remove the extra bytes, and you
have this layout:
id i
On 10 Mar 2009, at 16:49, Xavier Glattard wrote:
I'm sorry, i still can't see any problem.
I'll try to explain this in simple words then:
- If two classes use this mechanism in the same inheritance chain,
then they will have overlapping ivars, unless you add even more
complicated code to
David Chisnall a e'crit :
On 10 Mar 2009, at 16:49, Xavier Glattard wrote:
I'm sorry, i still can't see any problem.
I'll try to explain this in simple words then:
- If two classes use this mechanism in the same inheritance chain, then
they will have overlapping ivars, unless you add even
Hello Xavier,
Am Dienstag, den 10.03.2009, 17:49 +0100 schrieb Xavier Glattard:
> I'm sorry, i still can't see any problem.
>
> NSAllocateObject is implemented as this : (NSObject.m:767)
>
>size = aClass->instance_size + extraBytes + sizeof(struct obj_layout);
>new = NSZoneMalloc(zone,
В Mon, 09 Mar 2009 22:23:25 +0100, Riccardo Mottola написа:
> If we compare to other projects like glib2, gtk2: fine-grained packages
> like debian will give you udpates only when necessary
Glib/GTK+ have a stable API/ABI throughout the whole lifetime of the
GNOME 2 platform. If you upgrade from
On 11 Mar 2009, at 08:26, Yavor Doganov wrote:
Glib/GTK+ have a stable API/ABI throughout the whole lifetime of the
GNOME 2 platform
It is very easy to have a stable ABI for a procedural API because
there is no notion of subclassing. Even with GObject this is not
really a problem, as it d
David Ayers a écrit :
Hello Xavier,
Am Dienstag, den 10.03.2009, 17:49 +0100 schrieb Xavier Glattard:
(...)
This is the same behavior than 'classic' external ivars, but the memory
is allocated along with the instance itself (remember: the question is
'no extra malloc call'). The pointer to
В Wed, 11 Mar 2009 12:53:56 +, David Chisnall написа:
> It is very easy to have a stable ABI for a procedural API because
> there is no notion of subclassing. Even with GObject this is not
> really a problem, as it doesn't really present an OO model.
Right you are. Even then, after years of
On Mar 12, 2009, at 2:19 AM, Yavor Doganov wrote:
I think you misunderstood. As a GNUstep user and distro maintainer of
GNUstep packages, I don't mind if the GNUstep developers break the ABI
as much as they want (of course, the less the better). But only bump
the soname of a library when ther
В Fri, 13 Mar 2009 13:00:19 -0600, Adam Fedor написа:
> We had a long discussion about this before
Yes, I remember it.
> that ended in the request that stable releases have no ABI or API
> changes (even additions), so that a developer and user could count
> on the same set of functionality in a
On 17 Mar 2009, at 10:28, Yavor Doganov wrote:
This is probably worth having in the (very) distant future, but has
little to do with the question at hand. My objection was that it's
absolutely useless to bump the soname 1.14 -> 1.15 -> 1.16 (just an
example) when there are only compatible bugfi
This policy caused every framework and every application to require
recompiling
(well, technically only relinking, but good luck persuading GNUstep
make to do that) FOR NO REASON.
The recompiling occurs because the new headers are newer than the
object file that depends on them.
GNUstep-mak
On 20 May 2009, at 10:34, David Chisnall wrote:
On 17 Mar 2009, at 10:28, Yavor Doganov wrote:
This is probably worth having in the (very) distant future, but has
little to do with the question at hand. My objection was that it's
absolutely useless to bump the soname 1.14 -> 1.15 -> 1.16 (ju
On Wed, May 20, 2009 at 11:24:39AM +0100, Richard Frith-Macdonald wrote:
> I think what you are describing (as the correct way to do things) is
> what GNUstep already tries to do ... see
> http://mediawiki.gnustep.org/index.php/GNUstep_release_policy for the
> actual release policy details.
On
On 20 May 2009, at 11:53, Yavor Doganov wrote:
On Wed, May 20, 2009 at 11:24:39AM +0100, Richard Frith-Macdonald
wrote:
I think what you are describing (as the correct way to do things) is
what GNUstep already tries to do ... see
http://mediawiki.gnustep.org/index.php/GNUstep_release_policy fo
On 20 May 2009, at 11:53, Yavor Doganov wrote:
On Wed, May 20, 2009 at 11:24:39AM +0100, Richard Frith-Macdonald
wrote:
I think what you are describing (as the correct way to do things) is
what GNUstep already tries to do ... see
http://mediawiki.gnustep.org/index.php/GNUstep_release_policy f
On 20 May 2009, at 12:29, David Chisnall wrote:
In fact, this link appears to directly contradict itself:
The library (SONAME) versions is changed when the major or minor
version number of a release changes, but not the subminor number.
and
The minor version number is changed (and theref
Richard Frith-Macdonald wrote:
> On 20 May 2009, at 11:53, Yavor Doganov wrote:
>> On Wed, May 20, 2009 at 11:24:39AM +0100, Richard Frith-Macdonald wrote:
>>> However, I don't think there have been any recent releases which should
>>> have changed the so number for any of the libraries.
>>
>> I've
Richard Frith-Macdonald wrote:
> On 20 May 2009, at 11:53, Yavor Doganov wrote:
> > The SONAME of a shared library should be bumped if and only if
> > there is ABI break
>
> That's a matter of opinion.
Yes, the opinion of the library maintainer(s), which ideally should
conform to best practices.
On 20 May 2009, at 20:54, Yavor Doganov wrote:
Richard Frith-Macdonald wrote:
Even the base library needs to break binary compatibility
occasionally in order to improve MacOS-X compatibility.
"Occasionally", you say. If I understand correctly, you say that
between 1.13 and
Richard Frith-Macdonald wrote:
> On 20 May 2009, at 20:54, Yavor Doganov wrote:
> > If I understand correctly, you say that between 1.13 and 1.19 (for
> > example) not all soname bumps were warranted.
>
> No that's absolutely *not* what I said.
>
> I pointed out that the large majority of the rec
On 20 May 2009, at 23:17, Yavor Doganov wrote:
Richard Frith-Macdonald wrote:
On 20 May 2009, at 20:54, Yavor Doganov wrote:
If I understand correctly, you say that between 1.13 and 1.19 (for
example) not all soname bumps were warranted.
No that's absolutely *not* what I said.
I pointed ou
Richard Frith-Macdonald wrote:
Chasing MacOS-X is a problem for us .. sometimes Apple make changes
which require ABI changes. Often they add new stuff, which we try
to add too. If we don't get the additions quite right in one
release, we need to fix them in the next release, and that fix
On 21 May 2009, at 10:34, Wolfgang Lux wrote:
Have you ever looked at what Apple is doing? I can use executables
compiled on Mac OS X 10.2 on Mac OS X 10.5 without any problems and
Mac OS X does ship with only a single instance of all its libraries/
frameworks
Only half of this is true. A
On 21 May 2009, at 10:34, Wolfgang Lux wrote:
Richard Frith-Macdonald wrote:
Chasing MacOS-X is a problem for us .. sometimes Apple make changes
which require ABI changes. Often they add new stuff, which we try
to add too. If we don't get the additions quite right in one
release, we ne
David Chisnall wrote:
On 21 May 2009, at 10:34, Wolfgang Lux wrote:
Have you ever looked at what Apple is doing? I can use executables
compiled on Mac OS X 10.2 on Mac OS X 10.5 without any problems
and Mac OS X does ship with only a single instance of all its
libraries/frameworks
Only
Richard Frith-Macdonald wrote:
On 21 May 2009, at 10:34, Wolfgang Lux wrote:
Richard Frith-Macdonald wrote:
Chasing MacOS-X is a problem for us .. sometimes Apple make
changes which require ABI changes. Often they add new stuff,
which we try to add too. If we don't get the additions qu
On May 21, 2009, at 11:47, David Chisnall wrote:
Only half of this is true. Apple only ships one version of its
frameworks. Each framework, however, contains different versions of
the libraries. You may have noticed all of the OS X version macros
in the headers. Each of those defines t
Richard Frith-Macdonald wrote:
> On 20 May 2009, at 23:17, Yavor Doganov wrote:
> > I am counting only the major releases when there was a soname
> > bump; the regular point releases are not interesting for this
> > discussion.
>
> Then the discussion seems rather pointless ... since what you are
50 matches
Mail list logo
