libobjc2 1.0 - a couple of problems
Just playing around with this now on FreeBSD, and came across a couple of curiosities. Firstly, the code only compiles with clang, not with gcc. When I try it I get these errors... selector_table.c: In function 'add_selector_to_table': selector_table.c:244: warning: passing argument 2 of 'selector_insert' discards qualifiers from pointer target type selector_table.c:246: error: assignment of read-only location selector_table.c: In function 'register_selector_locked': selector_table.c:266: error: assignment of read-only location selector_table.c:267: error: assignment of read-only location selector_table.c:277: error: assignment of read-only location selector_table.c: In function 'objc_register_selector': selector_table.c:309: error: assignment of read-only location selector_table.c: In function 'objc_register_selector_copy': selector_table.c:339: error: assignment of read-only location selector_table.c:340: error: assignment of read-only location *** Error code 1 Secondly, I use static libraries - this will not link unless -fPIC is applied to the CFLAGS. There is no problem with the shared libraries, only the static ones. Adding -fPIC and compiling with clang works fine however. cheers, -pete. PS: could we have the static library stuff added to the Makefile ? It's only three additiuonal lines and one change. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSCalendar and NSLocale support
I would concur, but IIRC from when I looked at it a couple of years ago, there is basically a pure C API and a C++ API side-by-side. The Just to save you some time, don't use the C API, as it doesnt work properly. I went through this a couple of weeks ago. Did a C version, got odd results, and ended up recoding the lot in C++ with C wrappers to interface to Obj-C. That works a lot better (much as I hate C++) I was doing transliterations, so I have no idea if the C API would work ffor other things, but my experinece was that it wasn't any good. Subtle wrong results, the worst kind of bug! -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Grand Central
http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090608.pdf
Interesting - that ^{ syntax to describe a block is somewhat ugly, and it doesnt
give any deats of how you associate data with a block (which is necessary if
you want to get rid of locks).
It still all looks a bit heavyweight to me - I am still waiting for a
parallelism
model as easy to use as OCCAM ... people really threw the baby out with the
bathwater
there when the transputer died sadly :-(
There is no API documentation yet, but it seems that it basically
spawns a set of threads at different priorities and uses them to run
blocks from various queues. Lots of hype, but it doesn't seem to give
I can't work out if GCD is supposed to be an extension for OSX or an extension
to Objective-C itself. Obviously the block syntax requiures a language
extension,
but how do the bits fit together from there onward ?
-pete.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Fwd: [cfe-dev] Blocks runtime
We have an implementation of a blocks runtime (minus support for GC) in =C9toil=E9's ObjectiveC2.framework, but now Apple has released theirs under a BSD-style license. Very interesting - whait's this 'libgcc replacement' they are talking about ? wil that include the Obj-C runtime too ? It would seem odd to put the OPbj-C block code elsewhere from the rest of the langauge runtime. BTW, for those people out there who havent tried llvm and clang I suggest you go take it for a test drive. I've been experimenting with it for a while now, and it looks future shaped to me anyway ;-) It always looks like Davids announcements of llvm stuff on here seem to go unremarked, and maybe people aren't actually using it... -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
./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 signed long PASS: Proxy unsigned long PASS: Proxy signed long long PASS: Proxy unsigned long long PASS: Proxy float PASS: Proxy float PASS: Proxy id PASS: Proxy enum PASS: Proxy NSRange PASS: Proxy NSPoint ./obj/test01: Uncaught exception NSInvalidArgumentException, reason: GSFFIInvocation: Class 'AUATUSH'(class) does not respond to forwardInvocation: for '(null)' gmake: *** [test] Abort trap: 6 (core dumped) FAIL: base/NSProxy/test01.m ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
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 probably reduyced the chnaces of me doing an real work the rest of the day to zero ! ] -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
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/local/include and /usr/local/lib as ffi lib/include directories in configure. Using the latest SVN this now works out of the box with just 'configure' and the libffi port installed. So no need for ffcall on this platform anymore. cheers, -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
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 compile GNustep base ? I
have just soent a while playing around with the llvm port on
FreeBSD (which seems to be lacking the compiler driver). Had some
success with plain old C, but not a lot with ObjC, eeven when I am not
doing anything objecty. e.g:
#include stdio.h
#include objc/objc.h
#include objc/Object.h
@interface foo : Object
@end
@implementation foo : Object
@end
int
main(int argc, char *argv[])
{
puts(Hello world);
return 0;
}
-pete.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
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 like this:
clang test.m -emit-llvm -o - | llvm-as | opt -std-compile-opts | llc test.s
cc test.s -lobjc
./a.out
That works fine as long as there are no actual Objective C
constructs inside test.m . Its a basic hello world at the
moment:
#include stdio.h
#include objc/Object.h
int
main(int argc, char *argv[])
{
puts(Hello world);
return 0;
}
That works fine. But if I add the line id x = [Object new];
at the start of main() then I get this at runtime:
Module (null) version 8 doesn't match runtime 8
Abort trap: 6 (core dumped)
That's due to me having the wrong libobjc, yes ? I was wondering what
runtime you use which works... now I can compile and run code I
am interested in experimenting with this a bit
-pete.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
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 keep sending me reports of things that don't work. Will do - and I think this has strayed a very long way from GNUstep now, so wont do so here. I have a lot of stuff I want to compile up. WWe have several tens of thousands of lines of straight objeective C built on top of libc directly, so we can eaily use llvm to run it. cheers, -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
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 drop support!' or is this all hypothetical? 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 :-) 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 sigh of relief. -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
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 them. This I did not know. Interesting. I assumed Xcode was still using gcc. Maybe it is just me and your business model is incorrect to depend on free things when in reality there is no such thing as a free lunch. By that argument nobody should run a business on top of BSD or Linux. Yes, if you are going to be pedantic I dont depend on them - If BSD went away I would switch to Solaris, and if free Objective-C compilers went away then I shall switch to OS X. But in practice, currently the software runs on top of BSD using GCC/ObjC and it would be an imense pain if either of those things vanished tomorrow. But they are not likely to in my judgement. Indeed isn't the point of the GPL that the current version can't ever be actually taken away ? Or did I misunderstand that ? -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
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/local/include and /usr/local/lib as ffi lib/include directories in configure. Sure I can give that a try tomorrow. Last time I looked at it I couldnt make it work with libffi, but things change. -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: SIGSEGV at Unicode.m:1564
can you send me that again - it's in a bit of code I wrote, but the email inadventedly got deleteed when I wwas just looking at it! Any idea what the string is there ? -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: amd64 and libffi
I got a report from a Debian user that GNUstep programs segfault on the amd64 architecture when gnustep-base is compiled with libffi. (On the other hand, GNUstep programs apparently don't work with ffcall on Opterons, since ffcall doesn't seem to play well with the NX bit, apparently.) Unfortunately, I don't have an amd64 to try things out for myself. Does anyone have any experience with libffi under amd64? I've just switched (yesterday) to an amd64 based desktop at work - currently I can't get GNUstep running att all :-( Am using ffcall here, I havent tried with libffi yet. Does anyone have GNustep running under amd64 ? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNustep make and fat binaries
Why not compile the binaries separately and combine them with lipo? thats what we ended up doing, but it woudl be nice to be able to produce fat binaries directly just like you can on OpenStep. am trying to find the time to take a look at this. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problems with a custom constant string class
Is there any way I can have a constant string class that can subclass anything other than `Object'? Yes, as long as the thing you are subclassing from doesnt have any instance variables, as it has to have a specific layout on the stack. That can make doing some things a bit fiddly, but it does work. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
