Am Freitag, den 03.04.2009, 11:19 +0200 schrieb David Ayers:
> Am Donnerstag, den 02.04.2009, 14:02 +0100 schrieb David Chisnall:
> > The error seems to be in NSDecimal handling. I suspect that this
> > structure is just big enough to be split between registers and the
> > stack, which may cau
Am Donnerstag, den 02.04.2009, 14:02 +0100 schrieb David Chisnall:
> The error seems to be in NSDecimal handling. I suspect that this
> structure is just big enough to be split between registers and the
> stack, which may cause problems. Has anyone tested this on Linux/
> x86-64? If the tes
The error seems to be in NSDecimal handling. I suspect that this
structure is just big enough to be split between registers and the
stack, which may cause problems. Has anyone tested this on Linux/
x86-64? If the test doesn't fail there, then something strange is
going on.
David
On 2 A
> ./runtest.sh base/NSProxy/test01.m
not so good sadly...
This is gnustep-make 2.0.8. Type 'gmake print-gnustep-make-help' for help.
PASS: Proxy signed char
PASS: Proxy unsigned char
PASS: Proxy signed short
PASS: Proxy unsigned short
PASS: Proxy singed int
PASS: Proxy unsigned int
PASS: Proxy si
Am Mittwoch, den 01.04.2009, 15:07 +0100 schrieb Pete French:
> > 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 NSInvocatio
Am 01.04.2009 um 14:11 schrieb David Chisnall:
If you want an overview of LLVM, you can read this article:
http://www.informit.com/articles/article.aspx?p=1215438
I added your interesting article to DZone
http://www.dzone.com/links/
how_the_llvm_compiler_infrastructure_works.html
feel fr
> Patch to fix this problem is here if you want to apply it to your
> local tree:
Just working out how to get a local tree ;-) Aside from GNUstep
I usually just build from ports.
> As far as I know, you are the first person to test clang Objective-C
> support on a 64-bit platform. Please kee
Patch to fix this problem is here if you want to apply it to your
local tree:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-April/004759.html
As far as I know, you are the first person to test clang Objective-C
support on a 64-bit platform. Please keep sending me reports of
things that
> Not sure what you are using to compile here. There is not FreeBSD
> port for clang, and trunk clang requires trunk LLVM (i.e. not the
> port). Can you tell me what commands you are trying to use to compile?
I installed llvm-dev from ports. Which gives me a 'clang' command
that I can use li
On 1 Apr 2009, at 15:10, Pete French wrote:
Clang is a new front-end for LLVM, written completely from scratch,
which is more-or-less feature complete for C99 and Objective-C 2
(parsing anyway - code generation is only finished for the Apple
runtimes), and now working towards C++ support.
Is t
> Clang is a new front-end for LLVM, written completely from scratch,
> which is more-or-less feature complete for C99 and Objective-C 2
> (parsing anyway - code generation is only finished for the Apple
> runtimes), and now working towards C++ support.
Is this what you were using to try and
> 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 1 Apr 2009, at 01:51, Pete French wrote:
Apple has moved away from GCC so you can no longer depend on them.
This I did not know. Interesting. I assumed Xcode was still using
gcc.
XCode currently ships with gcc and llvm-gcc. Only llvm-gcc is
supported for iPhone developement (if you tak
> Both, they are moving over to clang (and LLVM) witness the subject line :).
good stuff ;-) I should go re-visit llvm and clang really, I never
took a proper look at it - I didn't realise it couod compile to native
code, which is preseumably true if they are compiking a full OS with it
[ thats p
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
> 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 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".
>
>>
> 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
> 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
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
> 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: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
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 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
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 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
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
28 matches
Mail list logo