From tomorrow (wednesday 1st april) for three weeks I'll be away from
home.
I expect to be able to get online occasionally, but intermittently.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Test results for GNUstep as of Tue Mar 31 06:34:14 EDT 2009
If a particular system failed compilation, the logs for that system will
be placed at ftp://ftp.gnustep.org/pub/testfarm
If you would like to be a part of this automated testfarm, see
http://wiki.gnustep.org/index.php/Developer_FAQ#How_ca
On 30 Mar 2009, at 15:55, David Chisnall wrote:
Ooops, missed one:
static inline int retframe_int (void *rframe)
{
__builtin_return (rframe);
}
On 30 Mar 2009, at 14:34, David Chisnall wrote:
This patch moves some inner functions in mframe.m into static
functions. Inner functions are a
On 30 Mar 2009, at 15:13, David Chisnall wrote:
The code setting the floating point exception mask in NSObject is
incorrect. It works coincidentally with GCC because GCC (at least,
in current versions) adds an extra load and so the argument becomes
%eax. If it is an indirect address then
On 30 Mar 2009, at 14:55, David Chisnall wrote:
Hi,
I'm looking at lines 1032--1038 of NSInvocation.m:
struct {
char x[size];
} dummy;
dummy = va_arg(ap, typeof(dummy));
memcpy(datum, dummy.x, size);
This will only
On 30 Mar 2009, at 16:37, David Chisnall wrote:
The remaining issue is that clang (and llvm-gcc, for that matter)
does not support the __builtin_apply() family of intrinsics. These
are quite unreliable on GCC, and it seems that they are not used
when FFCall or FFI is supported, but are st
On 31 Mar 2009, at 17:13, Richard Frith-Macdonald wrote:
On 30 Mar 2009, at 16:37, David Chisnall wrote:
NSInvocation.m provides default implementations in terms of
__builtin_apply() and friends that are not used when libffi or
ffcall is provided. Is it possible to move these into a separa
Compiling file NSDistributedNotificationCenter.m ...
NSDistributedNotificationCenter.m: In function
‘-[NSDistributedNotificationCenter
addObserver:selector:name:object:suspensionBehavior:]’:
NSDistributedNotificationCenter.m:343: warning: cast from pointer to
integer of different size
NSDistributed
Hello David,
Am Dienstag, den 31.03.2009, 17:49 +0100 schrieb David Chisnall:
> On 31 Mar 2009, at 17:13, Richard Frith-Macdonald wrote:
>
> > On 30 Mar 2009, at 16:37, David Chisnall wrote:
> >
> > I *think* (iirc) a little of the code in mframe is used for some
> > NSMethodSgnature features.
On 31 Mar 2009, at 20:00, David Ayers wrote:
I'm mostly concerned about keeping support for deprecated API which
was
1) part of either the OpenStep specification.
2) part of OPENSTEP 4.2 (widely distributed cross platform
implementation of OpenStep)
3) part of WebObject 4.5 (last cross platfor
Am Dienstag, den 31.03.2009, 22:13 +0100 schrieb David Chisnall:
> On 31 Mar 2009, at 20:00, David Ayers wrote:
>
> > I'm mostly concerned about keeping support for deprecated API which
> > was
> > 1) part of either the OpenStep specification.
> > 2) part of OPENSTEP 4.2 (widely distributed cros
On 1 Apr 2009, at 00:28, David Ayers wrote:
Am Dienstag, den 31.03.2009, 22:13 +0100 schrieb David Chisnall:
On 31 Mar 2009, at 20:00, David Ayers wrote:
If we can implement the argframe approach (ie. -forward::) via
libffi
then we could also resolve some long standing libobjc issues. Yet
> From the mailing list when I asked this last, and from comparing the
> list of supported platforms for the two. Again, can you name one
> platform supported by ffcall and GNUstep, but not libffi? Does anyone
> want to jump in and say 'My platform doesn't support libffi! Please
> don't
On 1 Apr 2009, at 00:56, Pete French wrote:
My platform (FreeBSD/amd64) supports ffcall but not libffi (or
this was the case last time I compiled GNUstep about a month ago)
so please don't drop support :-)
The FreeBSD port for libffi is not marked as broken on amd64. I'd be
very surprised i
On Tue, Mar 31, 2009 at 4:56 PM, Pete French wrote:
> All the rest of the email, however, I agree with - the lack of
> ObjC maintenance on GCC worries me greatly. I depend on this
> stuff for my living, and for my business to make sales. Having
> somewhere else to jump to would make me give a huge
> Well if your business depends on it, you might want to hire someone
> someone to do the development.
Well, that would be me. But I kind of have a lot of other stuff to
do. I'll reprhrase it as "I dont want to take this on myself".
> Apple has moved away from GCC so you can no longer depend on t
> Would it be possible for you to check whether GNUstep works with
> libffi? On FreeBSD/i386, it defaults to using ffcall, but works
> better with libffi (i.e. doesn't randomly corrupt the stack when you
> pass NSInvocations between threads). You probably need to explicitly
> specify /usr
On Tue, Mar 31, 2009 at 5:51 PM, Pete French wrote:
>> Well if your business depends on it, you might want to hire someone
>> someone to do the development.
>
> Well, that would be me. But I kind of have a lot of other stuff to
> do. I'll reprhrase it as "I dont want to take this on myself".
>
>>
> I should have said moving away but really they are so close to have
> moved away, it can be considered moved.
So what have they moved to out of interest, or can't you tell us ?
Is this just for Obj-C or the whole operating system ?
-pete.
___
Gnuste
On Tue, Mar 31, 2009 at 6:00 PM, Pete French wrote:
>> I should have said moving away but really they are so close to have
>> moved away, it can be considered moved.
>
> So what have they moved to out of interest, or can't you tell us ?
> Is this just for Obj-C or the whole operating system ?
>
B
Am Mittwoch, den 01.04.2009, 00:48 +0100 schrieb David Chisnall:
> >> Has anyone heard anything from the FSF about relicensing the GNU
> >> runtime? It is currently GPL with an exemption that only applies if
> >> code is compiled with GCC. I was told about a year ago that it would
> >> be moved t
Am Mittwoch, den 01.04.2009, 00:48 +0100 schrieb David Chisnall:
> >> I'd suggest modifying the configure script. The ffcall
> >> implementation
> >> doesn't work safely with EtoileThread, since it does not provide a
> >> mechanism for preventing the invocation from trampling over a
> random
> >
Am Mittwoch, den 01.04.2009, 00:48 +0100 schrieb David Chisnall:
> > Well I'm not too fond of yet another compiler/runtime to support...
> > but
> > if it is what apple will be using and it will also replace the current
> > apple runtime, I'm glad someone is working on it. But I think will
> >
23 matches
Mail list logo
