Re: [cfe-dev] LLVM / Clang 3.0 rc1 Binaries Available
P.S. Please can you check that -fexceptions is being passed to clang. -fobjc-exceptions doesn't seem to do anything in 3.0 (I thought it implied -fexceptions in 2.9, but I could be wrong). If this is the problem, then it's an easy fix. David On 27 Oct 2011, at 12:33, David Chisnall wrote: On 27 Oct 2011, at 09:14, Richard Frith-Macdonald wrote: Is this the compiler passing the wrong value, or possibly something wrong in the objc library? Neither - this is the correct behaviour. That method doesn't exist, and trying to call it is supposed to throw an exception. The problem is not that the exception is thrown, it is that it is not caught. This means that either: - There is a bug in libobjc2's exception handling, or - One of your stack frames does not have unwind information. One of the bug changes that LLVM 3.0 made over 2.9 was to emit .cfi* directives in the assembler, instead of emitting the unwind tables directly. Do you get any warnings from the assembler about unknown directives when you compile? Do simple @throw / @catch tests pass for you? What about C++ exceptions (Sebastian - did you check that on OpenBSD?) David -- This email complies with ISO 3103 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep -- Sent from my brain ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Fwd: [cfe-dev] LLVM / Clang 3.0 rc1 Binaries Available
FYI: Please test on platforms you care about and file bugs... Begin forwarded message: From: Bill Wendling wendl...@apple.com Subject: [cfe-dev] LLVM / Clang 3.0 rc1 Binaries Available Date: 21 October 2011 09:41:34 GMT+01:00 To: llvmdev List llvm...@cs.uiuc.edu, cfe-dev cfe-...@cs.uiuc.edu Hello developers! We have binaries available for download and testing! Please visit: http://llvm.org/pre-releases/3.0/rc1/binaries/ download the appropriate binaries for your system (they have obvious names), and start compiling things with it. Things to look for: • Compile failures that compiled in 2.9 • Execution failures that executed in 2.9 • Incorrect results that were correct in 2.9 • Massive compile time or execution slowdowns when compared to LLVM 2.9 For all problems you find, please create a PR for it (http://llvm.org/bugs/). Many thanks go to our team of testers for their hard work! -bw P.S. The 3.0 rc1 sources have been moved here: http://llvm.org/pre-releases/3.0/rc1/sources/ P.P.S. You'll notice that this is the Release+Asserts builds of rc1. I intentionally asked the testers for this one because it is most likely to ferret out bugs. ___ cfe-dev mailing list cfe-...@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev -- Send from my Jacquard Loom ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: [cfe-dev] LLVM / Clang 3.0 rc1 Binaries Available
On 21 Oct 2011, at 17:40, Ivan Vučica wrote: Just a tiny question: Apple has already shipped Apple LLVM Compiler 3.0 or something like that in Xcode 4.2. (I have not upgraded yet on my current machine, so I cannot check the exact naming). I suppose that Clang shipped by Apple is actually a prerelease as well? Yup. Apple periodically branches LLVM releases for Darwin independently of the official LLVM release cycle, because LLVM releases don't often coincide with XCode / OS X / iOS releases. You can check this with a Mac: $ clang -v Apple clang version 2.1 (tags/Apple/clang-163.7.1) (based on LLVM 3.0svn) Target: x86_64-apple-darwin11.2.0 'Apple's LLVM Compiler 3.0' is a trunk snapshot (with some bug fixes back ported) of Everyone Else's LLVM Compiler sometime between 2.9 and 3.0. Basically, they wanted to ship a version with ARC support immediately after the WWDC presentation, but there wasn't a release ready, so they shipped a trunk version. They may do a small update for XCode that upgrades LLVM / Clang to the real release, or they may not. Apparently they do periodic snapshots for internal use (every 2 months, I think), which then go through some extra testing, and then get used by Apple once any regressions have been fixed - I'm not sure how these correspond to their public releases either. David -- Sent from my brain ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: building a self-contained deployable gnustep
I have some out-of-tree patches that make this quite easy - I wrote them for deploying on WebOS, where I wanted to do the same thing. I hope to have time to tidy them up (and make sure that they don't break other configurations) soon... Basically, you can link the GNUstep libraries just as you would others, but they need to be able to find the their resources. There is some optimisation in NSBundle that, unfortunately, has the side effect of breaking everything when the GNUstep libraries are not where they expect to be. This primarily means that the time zone data is not in the right place. I'm not 100% certain why the time zone data needs to be bundled with GNUstep, since it's present on most systems anyway, so I also want to look at factoring this out a bit. David On 13 Oct 2011, at 11:25, Julian Mayer wrote: hello all i recently started porting a Mac OS X game to linux via gnustep, you may have seen the flood of bugreports. thanks for the fixes so far! while i am waiting for some showstopper bugs which are too complicated for me to fix myself (mainly #34492 and #34481) i thought i would move forward in other direction. the problem i am facing is that i want to create a binary-only deployable package (more of a .tgz'ed folder - akin to sauerbraten) that linux users regardless of distribution can download and run without having to install dependencies, namely GNUstep. (since my app requires svn gnustep, recent clang, recent libobjc2, and some unmerged gnustep fixes, i.e. #34490 it won't run on what distributions ship for a few years anyway) for the non-gnustep libraries i figured this would not be too hard to do. just build dependencies on a distribution with an old glibc, and either link statically (if license permits) or shared and adjust the LD load path to be inside my folder (ADDITIONAL_LDFLAGS = -Wl,--rpath='$$ORIGIN/'). the remaining problem is, i do not know how to build and package gnustep in a way so it is loaded from my app-folder wherever it resides. it seems to expect being in a global location. the only resources i could find on this topic are http://wiki.gnustep.org/index.php/Deployment_on_Windows which applies to windows only - i'd need the same thing for linux. there is also the GNUstep Deployment Environment on the GNUstep wish list in the wiki - which sounds what i need, but it being a wishlist-item is discouraging. so, does anyone know how to: • build gnustep in a way so it can operate from a location relative to my binary so i can deploy it? • how to handle the dependencies of gnustep itself - so that the whole thing runs on an as-large-as-possible pool of distributions: • i guess libtiff and libpng and possibly libxml2 can be statically linked but what about libffi, libxt, libXft, freetype2 and libart? for additional complication i absolutely need the embedded gnustep to use either the gnome-theme (which probably is a deploy-dependency nightmare) or a (good looking theme get rid of the weird separate-window-horizontal-menu) so that my future users don't turn away laughing or even crying. thanks for any help, julian ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep -- Send from my Jacquard Loom ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Please remove NFMake from GNA
On 10 Oct 2011, at 14:57, Gregory Casamento wrote: Also, it was me that did the relicense... I just removed it. I had thought Karl's code was open source, but I was mistaken since he never put it under any open source license. The source files all have a LGPLv2.1 or later header, there just wasn't a COPYING file. Karl: The initial commit (from 1999) is in your name and does have a FSF copyright header. If you didn't assign copyright to the FSF formally, then I'm not sure why this is the case. David -- Sent from my brain ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Steven P. Jobs 1955-2011: Here's to the crazy one who inspired us all...
Richard, As the founder of the GNU project and the Free Software Foundation, when you make comments like this in public, it reflects on all of us who contribute to these projects. When you use the death of someone who made huge contributions to the industry (some negative, a lot positive) to score political points, then that reflects on the GNU project, the FSF, and all of us. I notice that you put iTunes in the same category as the App Store. Perhaps you should recall that the iTunes Music Store was instrumental getting the entire music industry to abandon DRM. I'd contrast this with your achievements with the Defective By Design campaign, and say that's a clear win by Steve Jobs on behalf of end user freedom. What else did Steve Jobs make cool? I can think of a few things that immediately come to mind: - Graphical user interfaces - Object oriented programming - Rapid Application Development - Using computers! All of these have enriched the Free Software world. How many hackers in the 80s learned to program on an Apple II? How many in the '90s on a NeXT computer? How many in the last decade on a Mac? At FOSDEM, I lost count of the number of people who said to me something along the lines of 'Oh, you work on GNUstep? I learned to program on NeXTSTEP'. Many of these people moved on from Objective-C and are now working at companies like Red Hat, being paid full time to write Free Software. During Steve Jobs time at Apple, the company released a lot of Free Software, including (off the top of my head - not an exclusive list) original authorship or significant contributions to: - CUPS - Launchd - LLVM / Clang - libdispatch - libc++ - Darwin Streaming Server - Darwin Calendar / Contacts Server - WebKit In fact, the C++11 stack that we are currently testing in FreeBSD was primarily written by Apple employees, on company time. I'm assuming when you talk about 'making jails cool', you're talking about the App Store. I would certainly agree that denying users the right to run any software that they choose is a bad thing, but in Apple's product lines this kind of lock in is restricted to iOS devices, which currently have a declining market share. The same model is also used by Android, which claims to be open but, to coin an OpenBSD slogan, is only open for business. Perhaps your ire would be better directed there... If you are actually talking about making proprietary software cool, I'd say that this honour probably goes to the author of the Open Letter to Hobbyists, a certain William Henry Gates III. So, a summary of Steve Jobs achievements, good and bad: - Ran a company that was responsible for a number of developments we take for granted in modern computer. - Ran a company that released several million lines of Free Software and pushed open standards - Forced the music industry to abandon DRM - Sold proprietary software - Sold a handheld computing environment so attractive to users that they didn't notice how locked down it was for the first couple of years If you believe that the last two of these outweigh the first three, then that's your prerogative. It's not a point of view that I would agree with, but I respect your right to hold this opinion. I do not respect your choice to use his death as a political platform, and I believe that your tendency to ignore the good that individuals and companies do and focus entirely on their negative aspects is detrimental to the Free Software movement. Given the choice of releasing proprietary software and being ignored by you and releasing some Free Software and being harangued by you for keeping some proprietary, it's little wonder that we have difficulty persuading companies to open parts of their product lines. If we are judging people's lives by a few actions, then I can think of several instances when you have caused serious harm to the public image of Free Software. Perhaps you would like your obituary to focus entirely on these, and ignore your significant positive contributions. David On 8 Oct 2011, at 09:50, Richard Stallman wrote: So it is unfair of RMS to characterize Steve as the one who made jail cool. That is fair because that is the most important effect he had on the world. Don't let one bad thing tarnish a myriad of great things. I don't think anyone here disagrees with that. If Jobs did several things, the rational way to judge these things is separately. Thus, the App Store does not make the NextSTEP design bad, and the NextSTEP design does not make the App Store good. If the question is to judge Jobs, that requires adding them all up. I conclude that his net effect was very negative, because the App Store and iTunes did tremendous harm. However, when judging Jobs' legacy isn't the question, we don't need to add them up. We can keep them separate. In particular,
Re: GNUstep on 10.7
On 8 Oct 2011, at 12:40, Nat! wrote: Am 07.10.2011 um 23:24 schrieb Gregory Casamento: What I was particularly wondering about is why try to get GNUstep to work on Mac OS X since the Mac has it's own implementation of GNUstep it's called Cocoa. Which is closed-source and non-free. If you don't put a value on these two properties, then yes I can see, why you are wondering. But no more non-Free than most of the rest of OS X. If you're targeting OS X, then you've already decided that using non-Free software is acceptable. It therefore makes sense to use the implementation of the frameworks that is better tested and supported on this platform. If you want to run your code on other platforms, then it makes more sense to use GNUstep. If you care about software freedom, then you should write your code on GNUstep and then port it to Cocoa, because that will ensure that you don't use any of the APIs that aren't supported by the Free Software implementation. But I find it just a little bizarre to read this on a FSF-mailing list from the maintainer of said FSF-project. I thought freedom is the core value of the Free Software Foundation. So what would you want the reply to be? The answer to the question of how to run GNUstep on OS X should be 'uninstall OS X, install HURD, and use GNUstep there'? David -- Sent from my IBM 1620 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Steven P. Jobs 1955-2011: Here's to the crazy one who inspired us all...
It would be nice if we could link to (or host) some of the videos of Steve Jobs demoing the NeXT stuff (NeXTSTEP, OPENSTEP, PDO, WebObjects). All of these demos show just how far ahead NeXT was. I just watched the one about the design of the DMA architecture on the NeXT workstation - it looks crazy today because he's talking about stuff that everyone does as if it's new and exciting. Then you realise that the reason that he's having to explain in so much detail is that this really is a new concept for anything smaller than a mainframe - PCs and workstations are all doing it now, but they weren't back then. Many of the presentations have the same quality. You watch them and think 'well, of course - why would you do it any other way?' Then you remember that the rest of the industry at the time was doing it another way. David On 7 Oct 2011, at 04:08, Gregory Casamento wrote: That link is just fine. I can't think of anything better. I'll put it up. On Thu, Oct 6, 2011 at 4:54 PM, Fred Kiefer fredkie...@gmx.de wrote: I thought of linking just to the page Apple has set up: http://www.apple.com/stevejobs/ But there may be a better place. Fred On the road Am 06.10.2011 um 22:28 schrieb Gregory Casamento greg.casame...@gmail.com: Fred I think it's a wonderful idea. Give me the link and I can do it, I have access to the webpage code, just tell me where you think we should put it. GC On Thu, Oct 6, 2011 at 2:55 PM, Fred Kiefer fredkie...@gmx.de wrote: Thank you for writing this note. I have been thinking about putting a link to the commemoration page on the GNUstep web page. What do you think about this and who would be able to make this change? It has been twenty years now, but I still remember opening the first mail that got send to every account on a Next computer and hearing his voice, Hi, this is Steve Jobs, I want to welcome you... Fred On the road Am 06.10.2011 um 19:57 schrieb Gregory Casamento greg.casame...@gmail.com: Sometimes life hits you in the head with a brick. Don't lose faith. I'm convinced that the only thing that kept me going was that I loved what I did. - (Steve Jobs, 2005 Commencement Speech at Stanford) Steve Jobs 1955-2011. Through your shining example, you gave many of us the courge to act, believe and think different. Thank you. GC -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep -- Sent from my IBM 1620 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Steven P. Jobs 1955-2011: Here's to the crazy one who inspired us all...
Reading that made me feel faintly ashamed that I contribute to a GNU project. Especially given that, looking at my GNUstep development system, I see more lines of Free Software written by people @apple.com than by people @gnu.org. Fortunately, his attitude doesn't seem to be prevalent in the GNUstep community. Having a competitor like NeXT and later Apple forced the Free Software community to set high standards for itself. Imagine how bad life would be if we were only trying to build something better than Windows... David On 7 Oct 2011, at 16:48, Ivan Vučica wrote: And then, we also have comments like these. http://www.zdnet.com/blog/hardware/richard-m-stallman-on-steve-jobs-im-not-glad-hes-dead-but-im-glad-hes-gone/15275 On Fri, Oct 7, 2011 at 05:08, Gregory Casamento greg.casame...@gmail.com wrote: That link is just fine. I can't think of anything better. I'll put it up. On Thu, Oct 6, 2011 at 4:54 PM, Fred Kiefer fredkie...@gmx.de wrote: I thought of linking just to the page Apple has set up: http://www.apple.com/stevejobs/ But there may be a better place. Fred On the road Am 06.10.2011 um 22:28 schrieb Gregory Casamento greg.casame...@gmail.com: Fred I think it's a wonderful idea. Give me the link and I can do it, I have access to the webpage code, just tell me where you think we should put it. GC On Thu, Oct 6, 2011 at 2:55 PM, Fred Kiefer fredkie...@gmx.de wrote: Thank you for writing this note. I have been thinking about putting a link to the commemoration page on the GNUstep web page. What do you think about this and who would be able to make this change? It has been twenty years now, but I still remember opening the first mail that got send to every account on a Next computer and hearing his voice, Hi, this is Steve Jobs, I want to welcome you... Fred On the road Am 06.10.2011 um 19:57 schrieb Gregory Casamento greg.casame...@gmail.com: Sometimes life hits you in the head with a brick. Don't lose faith. I'm convinced that the only thing that kept me going was that I loved what I did. - (Steve Jobs, 2005 Commencement Speech at Stanford) Steve Jobs 1955-2011. Through your shining example, you gave many of us the courge to act, believe and think different. Thank you. GC -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep -- Ivan Vučica - i...@vucica.net ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep -- Sent from my brain ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Failed gui test:NSView_autoresize_and_rounding WAS: gnustep compiled with clang and gworkspace problem
On 5 Oct 2011, at 10:46, Sebastian Reitenbach wrote:
Hi,
On Wednesday, October 5, 2011 11:18 CEST, Fred Kiefer fredkie...@gmx.de
wrote:
First off and completely unrelated to the actual issue: GNUstep seems to
use fake main on your system. Why is this the case? As far as I know
this shouldn't be needed on any normal operating system. Could you
please check the configuration output of base to find out what is going
on here?
what is actually the purpose of this fake main? I just hear the first time
about it.
GNUstep needs access to the program arguments. If there is a libc API for
doing this, it could use that. Typically it uses procfs to look up the
arguments. If neither of these is available, it will interpose its own main()
function in front of the real one so that it can capture argc / argv and then
call your main(). This is a really ugly hack, but it's sometimes the only
option...
configure is called this way:
$ ./configure --disable-procfs --disable-procfs-psinfo --enable-debug
--disable-strip --prefix=/usr/local --sysconfdir=/etc --mandir=/usr/local/man
--infodir=/usr/local/info --disable-silent-rules
If you're disabling procfs, then you're probably getting fake main.
in configure output I see:
checking use of pass-through arguments... no
checking use of fake-main definition... yes
checking ffi.h usability... yes
checking ffi.h presence... yes
in config.log I see:
configure:21520: checking use of fake-main definition
configure:21563: result: yes
in configure:21520 I see:
{ $as_echo $as_me:$LINENO: checking use of fake-main definition 5
$as_echo_n checking use of fake-main definition... 6; }
# Check whether --enable-fake-main was given.
if test ${enable_fake_main+set} = set; then
enableval=$enable_fake_main;
else
enable_fake_main=no
fi
if test $enable_pass_arguments = no; then
case $target_os in
freebsd2*) enable_fake_main=yes;;
freebsd*) ;;
netbsd*)enable_fake_main=yes;;
openbsd*) enable_fake_main=yes;;
*sysv*) enable_fake_main=yes;;
esac
fi
so it's set unconditionally.
I can remove the line, and retry rebuilding everything and test whether it
will work without the fake main.
It will only work if there is some other mechanism for getting the arguments.
I don't know if there is a codepath for OpenBSD. If not, and there is a
sensible way of accessing it, then it's worth adding...
David
-- Sent from my brain
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: gnustep compiled with clang and gworkspace problem
Can you test with libobjc2 svn? That test should pass with 1.6 (which is probably due a release about now), but it is an expected fail with 1.5.1. It was added because someone recently pointed out that Apple libobjc does inherit +initialize and, even though it is weird, we should do the same because some people seem to rely on it... David On 4 Oct 2011, at 17:04, Sebastian Reitenbach wrote: Here the test results for -base and -gui compiled with clang 3.0 and libobjc2 1.5.1: base: 6528 Passed tests 7 Dashed hopes 1 Failed test The failed test is the following: Testing initialize.m... Running gnustep-base-1.23.1/Tests/base/NSObject/initialize.m... Start set: initialize.m:128 ... +initialize Passed test: initialize.m:133 ... initialize test starts Failed test: initialize.m:139 ... inherited +initialize is called automatically Passed test: initialize.m:50 ... Superclass +initialize called before subclass Passed test: initialize.m:79 ... First initialize method did not finish too early Passed test: initialize.m:85 ... +initialize called exactly once Passed test: initialize.m:86 ... +initialize completed before another method started Passed test: initialize.m:85 ... +initialize called exactly once Passed test: initialize.m:86 ... +initialize completed before another method started End set: initialize.m:164 ... +initialize Completed file: initialize.m gui: 737 Passed tests 5 Failed tests The 5 failed tests are the same that failed with just only using clang or gcc. Sebastian On Tuesday, October 4, 2011 11:40 CEST, Sebastian Reitenbach sebas...@l00-bugdead-prods.de wrote: On Tuesday, October 4, 2011 11:05 CEST, David Chisnall thera...@sucs.org wrote: So, do you have tests that pass with gcc but fail with clang? for -base, there is this failed build, which works with gcc, CLANG: 6436 Passed tests 17 Dashed hopes 1 Skipped set 1 Failed test 1 Failed file 1 Failed build GCC: 6428 Passed tests 17 Dashed hopes 1 Skipped set 1 Failed test 1 Failed file with gcc, it just doesn't run all the tests it runs with CLANG, but that is I guess due to the failed build. I used gcc-4.2.1 that comes with OpenBSD base installation. for -gui it looks like this: CLANG: 737 Passed tests 5 Failed tests GCC: 773 Passed tests - since I did not cut n pasted, I may have accidently mixed up the last 7 and 3 I guess 5 Failed tests the 5 failed tests are the same. And the test that Fred says should not fail, has the same output: NSView_autoresize_and_rounding.m so its pretty much the same. Sebastian David On 4 Oct 2011, at 10:03, Sebastian Reitenbach wrote: Hi, this is just to confirm, the numbers of the test results are not different whether using clang 2.9 or svn a.k.a 3.0. The only difference is that with gui I now have: 737 Passed tests 5 Failed tests but this is due to the lazy copy test, which failed with clang 2.9 because of not started gpbs. Now I'll recompile with clang and libobjc2, test results will follow. Sebastian On Tuesday, October 4, 2011 09:44 CEST, Sebastian Reitenbach sebas...@l00-bugdead-prods.de wrote: Hi, here the gnustep-tests results from base and gui, compiled with clang 2.9. clang 3.0 is also ready, these are just for reference and for comparison. looks fairly similar to what gcc produced. One build failure of a -base test is strange, this did not happen with gcc. I was using the same svn revision like I did with gcc. Here the relevant parts of the -base tests: 6436 Passed tests 17 Dashed hopes 1 Skipped set 1 Failed test 1 Failed file 1 Failed build Testing initialize.m... Running gnustep-base-1.23.1/Tests/base/NSObject/initialize.m... Start set: initialize.m:128 ... +initialize Passed test: initialize.m:133 ... initialize test starts Failed test: initialize.m:139 ... inherited +initialize is called automatically 2011-10-04 09:05:13.022 initialize[17875] WARNING your program is becoming multi-threaded, but you are using an ObjectiveC runtime library which does not have a thre ad-safe implementation of the +initialize method. Please see README.initialize for more information. Terminated Failed file: initialize.m aborted without running all tests! GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-openbsd5.0... Breakpoint 1 at 0x1c0046e0: file Testing.h, line 149. (gdb) break -[NSException raise] Function -[NSException raise] not defined. Make breakpoint pending on future
Re: Failed gui test:NSView_autoresize_and_rounding WAS: gnustep compiled with clang and gworkspace problem
On 5 Oct 2011, at 11:18, Sebastian Reitenbach wrote: Besides its ugly, and forces one more step to do on the user before he can use gnustep programs, is there any good advantage of using procfs instead of the fake main? Will stuff be noticeably faster, more stable, whatever? The fake main stuff is fragile, because it will break if the compilation unit containing main() does not include the GNUstep headers. For example, if you have a main.c that then calls into some Objective-C stuff later, it won't work. On FreeBSD, we use kvm to get this, with some slight fudges. I don't know if the same code path works on OpenBSD - you can try it (you may need to enable kvm in configure). David -- Sent from my Cray X1 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: gnustep compiled with clang and gworkspace problem
These are both libobjc problems. The failed build is because that test is checking property introspection. With GCC, it just skips compiling the test entirely because GCC can't parse the property notation. With clang, it compiles but then you are linking to a libobjc that doesn't have the property introspection functions, so it fails. The +initialise test is also failing due to problems with your runtime. David On 4 Oct 2011, at 10:40, Sebastian Reitenbach wrote: On Tuesday, October 4, 2011 11:05 CEST, David Chisnall thera...@sucs.org wrote: So, do you have tests that pass with gcc but fail with clang? for -base, there is this failed build, which works with gcc, CLANG: 6436 Passed tests 17 Dashed hopes 1 Skipped set 1 Failed test 1 Failed file 1 Failed build GCC: 6428 Passed tests 17 Dashed hopes 1 Skipped set 1 Failed test 1 Failed file with gcc, it just doesn't run all the tests it runs with CLANG, but that is I guess due to the failed build. I used gcc-4.2.1 that comes with OpenBSD base installation. for -gui it looks like this: CLANG: 737 Passed tests 5 Failed tests GCC: 773 Passed tests - since I did not cut n pasted, I may have accidently mixed up the last 7 and 3 I guess 5 Failed tests the 5 failed tests are the same. And the test that Fred says should not fail, has the same output: NSView_autoresize_and_rounding.m so its pretty much the same. Sebastian David On 4 Oct 2011, at 10:03, Sebastian Reitenbach wrote: Hi, this is just to confirm, the numbers of the test results are not different whether using clang 2.9 or svn a.k.a 3.0. The only difference is that with gui I now have: 737 Passed tests 5 Failed tests but this is due to the lazy copy test, which failed with clang 2.9 because of not started gpbs. Now I'll recompile with clang and libobjc2, test results will follow. Sebastian On Tuesday, October 4, 2011 09:44 CEST, Sebastian Reitenbach sebas...@l00-bugdead-prods.de wrote: Hi, here the gnustep-tests results from base and gui, compiled with clang 2.9. clang 3.0 is also ready, these are just for reference and for comparison. looks fairly similar to what gcc produced. One build failure of a -base test is strange, this did not happen with gcc. I was using the same svn revision like I did with gcc. Here the relevant parts of the -base tests: 6436 Passed tests 17 Dashed hopes 1 Skipped set 1 Failed test 1 Failed file 1 Failed build Testing initialize.m... Running gnustep-base-1.23.1/Tests/base/NSObject/initialize.m... Start set: initialize.m:128 ... +initialize Passed test: initialize.m:133 ... initialize test starts Failed test: initialize.m:139 ... inherited +initialize is called automatically 2011-10-04 09:05:13.022 initialize[17875] WARNING your program is becoming multi-threaded, but you are using an ObjectiveC runtime library which does not have a thre ad-safe implementation of the +initialize method. Please see README.initialize for more information. Terminated Failed file: initialize.m aborted without running all tests! GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-openbsd5.0... Breakpoint 1 at 0x1c0046e0: file Testing.h, line 149. (gdb) break -[NSException raise] Function -[NSException raise] not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 2 (-[NSException raise]) pending. (gdb) r Starting program: /home/ports/pobj/gnustep-base-1.23.1/gnustep-base-1.23.1/Tests/base/NSObject/obj/initialize Breakpoint 3 at 0x1004101: file NSException.m, line 956. Pending breakpoint -[NSException raise] resolved Start set: initialize.m:128 ... +initialize Passed test: initialize.m:133 ... initialize test starts [Switching to process 21264, thread 0x8b735000] Breakpoint 1, testStart () at Testing.h:149 149 } Current language: auto; currently minimal (gdb) bt #0 testStart () at Testing.h:149 #1 0x1c003488 in gnustep_base_user_main () at initialize.m:139 #2 0x010ca627 in main (argc=1, argv=0xcfbd7734, env=0xcfbd773c) at NSProcessInfo.m:979 #3 0x1c0015d7 in ___start () #4 0x1c001552 in _start () (gdb) c Continuing. Failed test: initialize.m:139 ... inherited +initialize is called automatically 2011-10-04 08:58:31.700 initialize[21264] WARNING your program is becoming multi-threaded, but you are using an ObjectiveC runtime library which does not have a thread-safe implementation of the +initialize method. Please see README.initialize for more information. [New process
Re: problem with gworkspace-0.9.0 and gnustep-base-1.23.0
On 3 Oct 2011, at 10:53, Sebastian Reitenbach wrote: On 10/02/11 19:46, David Chisnall wrote: On 2 Oct 2011, at 18:43, Sebastian Reitenbach wrote: Right now I'm experimenting with clang/libobjc2 again on OpenBSD. It seems to not crash randomly anymore (which is better than half a year or so ago when I tried last time), but still applications seem to be unusable. Will open a new thread for that topic... Clang / LLVM is going in to feature freeze in a couple of weeks for the 3.0 release, so now is a really good time to identify bugs... are there maybe daily snapshots of the svn repo available? I don't think so. You need to grab the source and compile. David -- Sent from my PDP-11 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: problem with gworkspace-0.9.0 and gnustep-base-1.23.0
On 2 Oct 2011, at 18:43, Sebastian Reitenbach wrote: Right now I'm experimenting with clang/libobjc2 again on OpenBSD. It seems to not crash randomly anymore (which is better than half a year or so ago when I tried last time), but still applications seem to be unusable. Will open a new thread for that topic... Clang / LLVM is going in to feature freeze in a couple of weeks for the 3.0 release, so now is a really good time to identify bugs... David -- Send from my Jacquard Loom ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Opal, CGLayer and OpenGL in UIKit
On 30 Sep 2011, at 17:48, Ivan Vučica wrote: Hi, I've been reading the Apple docs on Quartz/CoreGraphics, and I've stumbled upon CGLayer. Upon first look, it looks like CGLayer is already implemented. My first thought is that perhaps we don't need to actually use OpenGL when implementing UIKit, at least not initially. What do you guys think? CGLayer is implemented, but it currently only does the very basic stuff. It currently uses a Cairo pattern to allow it to be composited. This works, but it's going to be fairly slow. UIKit (and modern AppKit) do a lot more. For example, even the very basic swoosh effect as you slide a layer off the screen is going to require compositing the texture a few dozen times. This can be very fast in OpenGL, but is likely to be slow with Cairo. CoreAnimation wants to move layers around in 3D space (well, rotate them in 3D, move them in 2D), while CoreImage wants to run shader programs on them. All of these things are trivial with OpenGL, but very hard in Cairo. So, in theory it's possible, but in practice it will be hard. David -- This email complies with ISO 3103 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cross-compiling GNUstep?
On 28 Sep 2011, at 07:58, Fred Kiefer wrote: On 27.09.2011 20:09, David Chisnall wrote: HP has kindly sent me a TouchPad to play with, so I wanted to run GNUstep on it. I've managed to get clang to use their cross-build toolchain, but I'm having problems with the configure script for -base. It just aborts if you're cross compiling. Am I the first person to try cross-compiling GNUstep? I was fairly sure Nikolaus had done this before. Is there an easy way to tell the configure thing 'really, I know what I'm doing, just trust me...' and have it assume that the test programs will work? I can always tweak configure options until they actually later... Nikolaus Schaller isn't using GNUstep itself. He has his own fork mySTEP and to my knowledge he uses XCode to do the compilation for the different environments. As he only needs to support a few well controlled target systems, he gets along without all these compilcated configure scripts we are using. I tried myself to cross compile GNUstep ages ago and failed. One problem was that gnustep-make was using the terms host/build/target in a different order than the cross compilation standard. No idea whether Nicola fixed that. The 'standard' definition is somewhat unintuitive, but it seems that -make now uses the correct values. I agree with Richard that it is probably best to just generate the results of autoconf in a different way and use these then. I created them manually at that time. It would help to document what gets changed by the configure step. I've poked the configure script a lot now and basically disabled all of the executable tests when it detects that you're cross-compiling. I now have a pretty minimal GNUstep (no ICU, no XML, no SSL) building on the Mac for deployment on WebOS. My aim with this is to get the native GNUstep .so talking to Objective-C that's been compiled down to JavaScript with my clang plugin. David -- This email complies with ISO 3103 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Cross-compiling GNUstep?
Hi Everyone, HP has kindly sent me a TouchPad to play with, so I wanted to run GNUstep on it. I've managed to get clang to use their cross-build toolchain, but I'm having problems with the configure script for -base. It just aborts if you're cross compiling. Am I the first person to try cross-compiling GNUstep? I was fairly sure Nikolaus had done this before. Is there an easy way to tell the configure thing 'really, I know what I'm doing, just trust me...' and have it assume that the test programs will work? I can always tweak configure options until they actually later... David -- Sent from my IBM 1620 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Compiling corebase on Windows
I had the same problem with libobjc2 on Windows. I worked around it by doing something like this: #define BOOL WINBOOL #include windows_stuff.h #undef BOOL And then including Objective-C headers. David On 25 Sep 2011, at 18:19, Stefan Bidi wrote: I booted into Windows today and figured it would be a good idea to try corebase there. I ran into some problems that I was able to fix, but I don't know what to do with the set of error I'm getting now. It's about BOOL being defined by both windef.h and objc/objc.h. I'm sure I'm screwing something up, can anyone more familiar with Windows please shed some light? I've attached the output. Stef output___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep -- Sent from my brain ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Doxygen documentation
Unfortunately, the output from doxygen is pretty horrible for Objective-C. You might like to take a look at the DocGenerator that Quentin wrote, in Étoilé svn. It uses simpler markup and produces much nicer output. David On 20 Sep 2011, at 01:23, Stefan Bidi wrote: I just wanted to let everyone know that I've started documenting corebase with doxygen instead of autogsdoc. The learning curve is quite steep if you're just starting out, but I'm getting the hang of it. The configuration file has at least a few hundred options... I managed to understand only 5 of them. The output is decent, but needs a lot more work to be be useful. I know there was some talk about it a few weeks ago. I just took a better look at it and I found doxygen much more powerful than autogsdoc. I had to download 100+ MB worth of packages to get it to even do anything on my system, however. Corebase is still a very small project so I figured it was a good test bed for this sort of thing. Let me know what you guys think (run doxygen Doxyfile to have it output the html). Stef ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep -- Sent from my Difference Engine ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Why is +initialize not inherited?
I'm not sure how that would help you. Your subclasses would only receive a
+initialize message once you'd sent them some other message, which requires
some other bit of code to be able to locate them, which means the other code
can trivially register them...
That said, I agree that we should aim to be compatible with Apple, although in
this case I think the GNU behaviour is more logical. I've made that change in
the GNUstep Objective-C runtime, and it will be part of the 1.6 release unless
someone objects strongly...
David
On 15 Sep 2011, at 19:28, Larry Campbell wrote:
The problem I have is when some shared behavior is implemented in a
superclass, and it doesn't get called for the subclass. Something like:
@implementation Superclass
+ (void)initialize
{
[OtherClass registerNewClass:self];
}
@end
Now if I subclass Superclass, my subclass doesn't get registered, unless I
explicitly call +[Subclass initialize] myself. But I don't think I should
have to call initialize myself; the runtime should do it for me.
- lc
On Sep 15, 2011, at 12:01 PM, Fred Kiefer wrote:
I have to apologize, sticking to these simple rules isn't as easy as I
thought it would be. I just fixed a bug in Gorm that was inside of an
+initialize method in a category. Just imagine somebody had implemented that
method in the main class later on.
On 14.09.2011 23:39, Fred Kiefer wrote:
What exactly was the problem that you experienced?
In GNUstep we always write our +initialize methods like this and I don't
know of any problem with that style:
+ (void)initialize
{
if (self == [MyClass class])
{
// do stuff
}
}
There are certain differences between the different runtimes, but in
most cases you are save to ignore them as long as you stick to a careful
coding style.
On 14.09.2011 23:09, Larry Campbell wrote:
Today, having forgotten this five-year-old conversation, I was burned
by this again.
I cannot think of any good reason (other than inertia) for +initialize
not to be inherited as it is on Mac OS X. It's incompatibilities like
this that make it hard to recommend Objective-C. Does anyone else care
about this?
- lc
On Jan 21, 2006, at 1:31 PM, David Ayers wrote:
Larry Campbell schrieb:
On Jan 21, 2006, at 4:50 AM, David Ayers wrote:
Have a look at this discussion:
http://lists.apple.com/archives/objc-language/2004/Mar/msg6.html
Now, I'm no advocate of being different just for the sake of being
different, but I also think that '+load' and '+initialize' are simply
special wrt inheritance and guarantees on how/when they are
called and
I would assume that we would break code written for the FSF libobjc
runtime if FSF's libobjc started to inherit +initialize.
However, I think that:
1. The difference between FSF here and Apple is a trap for the unwary
2. It would be best to remove such traps when possible
3. Due to binary compatibility it's extremely unlikely Apple will
change
4. There's no clear advantage to the FSF approach (or the Apple
approach)
All of these points could be applied for most of the FSF libobjc API.
(E.g., did you know that the class pointer of an 'id' in FSF's libobjc
is called 'class_pointer' instead of 'isa'? But yes, I realize the
inconsistency that Object.h still uses 'isa' as the ivar name.)
The reasons are historical and I assume have to do with the reluctance
of NeXT to release their GCC modifications to ObjC in the first place.
I kind of doubt that the FSF wanted to make their libobjc incompatible,
but I don't know the details of what happened and they seem to diverge
quite a bit more than I would have expected... Anyway, now there is
code out there that relies on FSF's libobjc and we should consider
changes carefully.
5. If you really want to share initialization code with subclasses, you
have to move such initialization code into a separate method, or
subclasses have to call [super initialize]
Moving them to separate methods that get invoked by +initialize seems
like the most robust approach to me.
So I think I would argue that FSF should consider changing; not
precipitously, and with perhaps a way to override via an environment
variable in case of compatibility bugs.
Well this is the type of discussion that the above mentioned list was
created for. I am personally undecided on the issue and would insure
that any code I write today would be portable. Even if it is decided to
change the GNU semantics I believe the earliest libobjc release would be
4.2 (or possibly 4.3 depending on libobjc maintainers view this in light
of the pending switch to Stage 2 of gcc's trunk) and any code relying on
NeXT/Apple semantics would have to wait until that compiler version is
in wide spread use.
Note that if you actually invoked either +initialize or +load in a
true
method invocation, the normal inheritance techniques would be used.
But
be warned, code often is not
Re: Interesting error in GWorkspace
On 11 Sep 2011, at 20:01, Eric Wasylishen wrote: I wonder if the clang static analyzer can find places where we send a message returning something other than an object to something that might be nil? Clang will automatically insert a check that receivers are nil for structure returns and substitute a zero-initialised structure instead of doing the message send in these cases. It's done this for about a year, so the simplest fix is just to use clang to compile. The static analyser also warns if you do this, but you only need to bother fixing it in code that you intend to compile with gcc. David -- Sent from my STANTEC-ZEBRA ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: GNU Hackers Meeting Presentation
On 1 Sep 2011, at 20:51, Lars Sonchocky-Helldorf wrote: I hope David got a chance to grab a HP TouchPad Sadly not - they were all sold out here too. The demo of JTalk running on the Touchpad was pretty amazing, and even without it WebOS is so far ahead of Android in terms of usability that it would be a tragedy if it died, but it looks like HP is going to mismanage it to death. If anyone spots somewhere selling Touchpads for about £100 that delivers in the UK, let me know... David -- Sent from my brain ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: GNU Hackers Meeting Presentation
Thanks Quentin, I've also put my slides from the 2011 International Smalltalk Conference, where I was invited to talk about Étoilé / Pragmatic Smalltalk on the Étoilé blog. This talk was mostly aimed at Smalltalk developers, but it may be of interest to other people. David On 1 Sep 2011, at 10:48, Quentin Mathé wrote: Hello everyone, I just posted a short summary of the GNU hackers meeting where I went to last week: http://etoileos.com/news/archive/2011/09/01/1100/ You can read the presentation slides in PDF that covers both GNUstep and Étoilé here: http://etoileos.com/uploads/presentations/extensibility-in-gnustep-etoile-gnu-hackers-2011.pdf A short overview of the talk is given in the schedule if you want some additional background: http://www.gnu.org/ghm/2011/paris/#sec-4_12 Cheers, Quentin. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep -- Sent from my Difference Engine ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Setting up Clang compiler
I wrote a tutorial for installing GNUstep on FreeBSD a week or so ago: http://etoileos.com/news/archive/2011/08/14/1206/ For Windows, you'll need to change a few things. For a start, all of this stuff will need to run inside a MinGW install. You may want to use a different filesystem layout (do we have a standard Windows layout? With everything inside an application's install directory?) You may also need to disable native exceptions - I've no idea if they work on Windows. David On 1 Sep 2011, at 13:42, Omar Campos wrote: Hi everyone, A while back I asked on this list why things like @property don't seem to work on GNUStep, and I was told that these belong to Objective-C 2.0, and that if I wanted to use them, I needed to either use the Clang compiler, or something called lib_objc2 (if I remember correctly). I downloaded Clang, but I have no idea how to get GNUStep to use it. Are there any tutorials or instructions on how to set this up? Note than I am using the Windows version of GNUStep. Thanks for any info! Sincerely, Omar Campos Rivera ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep -- Sent from my Apple II ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Setting up Clang compiler
On 1 Sep 2011, at 18:40, Eric Wasylishen wrote: I think implementing support for Window's native SEH is on both gcc's and clang/llvm's wish list. SEH is a parent nightmare, so I don't think anyone is working on it - doing so would basically mean you can't distribute in the USA. There is work in LLVM to support the exception model that Win64 uses for C++ exceptions, which is quite similar to the zero-cost mode on most UNIX systems. David -- This email complies with ISO 3103 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Setting up Clang compiler
On 1 Sep 2011, at 18:40, Eric Wasylishen wrote: When mingw does a release with gcc4.6 or clang, it should be easy for us to make an installer where ObjC2 works out of the box. There are prebuilt binaries of Clang for MingW32 available from the LLVM web site: http://llvm.org/releases/download.html#2.9 David -- Send from my Jacquard Loom ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: GNUstep on 10.7
On 27 Aug 2011, at 22:15, artware wrote: /usr/include/objc/message.h:72:1: error: unknown type name 'OBJC_EXPORT' This is a header that, as far as I know, only exists in the Mac Objective-C runtime. It may be possible to use GNUstep with this runtime, but it's completely untested and some bits of the code almost certainly won't work (we've tidied those up a bit over the last couple of years, but it's still probably not a good idea). If you want to use GNUstep on OS X (which I wouldn't recommend - Apple has their own clean-room reimplementation of GNUstep called Cocoa), then you will need to install another Objective-C runtime. David -- Sent from my Apple II ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: GNUstep on 10.7
On 28 Aug 2011, at 14:57, Adam Fedor wrote: Better to build on OSX/Cocoa and deploy on FreeBSD/GNUstep. You'd have to test on FreeBSD anyway due to operating system differences. I agree with this. OS X and FreeBSD have almost the same libc, making it the easiest place to port OS X code to, but there are still some subtle differences that can bite you if you're unlucky. If you don't want another physical machine, it only takes about an hour to install FreeBSD in a VirtualBox VM and then install GNUstep on top. This is what I do, so that I can test my code on 32-bit and 64-bit FreeBSD easily. And, if you find that you want to use some Cocoa classes or methods that are not yet present in GNUstep, then patches are very welcome... David -- This email complies with ISO 3103 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: GNUstep on 10.7
On 27 Aug 2011, at 07:17, artware wrote: I've been working for 14 hours straight trying to get GNUstep-base installed on FreeBSD I wrote instructions for installing GNUstep and Étoilé on FreeBSD last week: http://etoileos.com/news/archive/2011/08/14/1206/ These are tested on a fresh install of 9-BETA1, but they should work on 8 too. Note: the options selected are for people intending to hack on Étoilé, so they may not be ideal for you. David -- Sent from my brain ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: gcc warnings
On 17 Aug 2011, at 14:22, Andreas Höschler wrote: Hi all, I am cross-building on GNUstep/Solaris and MacOSX. When I build code like NSString *message = @some string [NSException raise:NSInternalInconsistencyException format:message]; on MacOSX 10.6 using GNUstep make, gcc gives the following warning SOEditingContext.m:3574: warning: format not a string literal and no format arguments Any vaguely-recent compiler will give you the same warning. Any idea how to get rid of that one? Yes, use a constant string, not a variable, for the format string. Here, you are assigning the constant string to a variable and then passing it as the format string. The compiler can not tell at this point that the string is constant (it can only tell that after doing data-flow analysis, which doesn't happen until much later). David ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: gcc warnings
On 17 Aug 2011, at 14:41, Andreas Höschler wrote: Hi all, I am cross-building on GNUstep/Solaris and MacOSX. When I build code like NSString *message = @some string [NSException raise:NSInternalInconsistencyException format:message]; on MacOSX 10.6 using GNUstep make, gcc gives the following warning SOEditingContext.m:3574: warning: format not a string literal and no format arguments Any idea how to get rid of that one? [NSException raise:NSInternalInconsistencyException format: @%@, message]; The warning is because it can't do a compile time check of message to see if it's a valid format string ... you need to use a string literal as the format string. Thanks for your feedback! I know that this prevents the warning, but I can't do that. The message is calculated by some method and then returned as a string. I then need to raise the exception with the readily build string. If NSException had a +[raise:string:] method I would use that, but it hasn't! :-( I have the same problem with NSLog(). I am again building the message somewhere and get it as a NSString. I then simply want to log it out and get the above warning. NSLog([localException description]); This is just plain wrong. Do that, and you can get random stack corruption. You should always do this instead: NSLog(@%@, [localException description]); That's simply annoying! :-( Isn't there some compiler switch that could be used to suppress these kind of warnings? Well, the best way of getting rid of compiler warnings is to write correct code. If you have a string that is generated programatically, then you can't generally guarantee that it doesn't contain format escape sequences, so if you pass it to something that expects a format string then you may have things break. If you have a function that returns output that is usable in format strings in the same context as its input, then there is an __attribute__() that you can add to let the compiler know. See the localisation stuff in NSBundle.h for some examples of this. David -- Sent from my Apple II ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: New -base release?
On 16 Aug 2011, at 07:37, Sebastian Reitenbach wrote: OpenBSD sparc was switched to gcc-4.2 some weeks ago. OpenBSD SPARC was, as far as I know, the last platform we supported that used GCC 2.95. Does this mean that we can finally require GCC 3 or later and switch to C99 mode? David -- Sent from my PDP-11 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: GSIMap and OpenBSD (Was: Re: GSIMap and gcc 2.95)
On 16 Aug 2011, at 20:38, Riccardo Mottola wrote: Hi, I forgot to mention that it was OpenBSD/sparc On my OpenBSD/x86 computer however I get the same problem and it has gcc 4.2 Thus it appears to be an OpenBSD problem? I reconfigured and made clean. I don't see any apparent OS difference there. This may be an OpenBSD libc problem. Can you check how NULL is defined? I fixed a bug in FreeBSD libc a couple of years back that would cause this, and they may have inherited the same bug from some common ancestor. In C, the definition of NULL is usually (void*)0, but in C++ it is supposed to be 0 (except that 0 is an int so on LP64 this causes stack smashing on variadic functions, but I digress), and it's possible that they just #define it to 0 for C and C++. GCC provides a builtin __null which works better - it's a special literal that is a 0 value in any pointer type. If you replace the NULL with (void*)0 in GSIMap.h, does that fix it? David ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: OsiriX [Was: environment]
On 14 Aug 2011, at 11:05, Philip G Batchelor wrote: (For the moment, Osirix compilation fails at 'libkern/OSByteOrder.h: No such file or directory' but that was a first attempt, I'll try more). The OSByteOrder stuff is more or less the same as the NSByteOrder stuff, so it should be relatively simple to rewrite it to use NSByteOrder. No idea why they'd use the libkern interfaces - they're only meant to be used for low-level things that can't link against Foundation. David -- Sent from my Difference Engine ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: New -base release?
On 2 Aug 2011, at 19:02, Richard Frith-Macdonald wrote: And nowadays we really need to test builds with clang, new runtime, and with the latest gcc and the new gcc runtime, and we have two new GC variants ... I regularly run the test suite with FreeBSD/x86-32 and Linux/x86-64, both with the non-fragile ABI for everything (clang + libobjc2). So three different compiler/runtime setups at least, various cpu architectures, and now four memory management schemes (trad retain/release, gc with gnu runtime, gc with new runtime, automated retain/release). That's a lot to get tested ... so the timescale may not be realistic :-( ARC is not a new scheme, it's intended to be compatible with manual retain / release. You can't mix ARC and non-ARC code in the same compilation unit, but you can mix them in different .o files in the same project. Most of the ARC-related changes are tweaking method declarations so that they can be called from ARC. GNUstep is not built with ARC - that would require some massive and invasive changes to the code - it is just used with code that is compiled in ARC mode. Think of ARC like C99 or C++ - you can mix GNUstep's Objective-C89 code with Objective-C99 or or Objective-C++0x code in other projects, as long as the GNUstep headers are compatible with these languages. I'm happy to call the Apple-compatible GC mode experimental in the next release. Apple seems to be ditching this mode in the long term (everyone at Apple except the 5 guys on the autozone team hates it) so it's mainly of interest to people who are porting code that only worked on OS X =10.5 (not iOS or OS X =10.4) to GNUstep, so I'm not sure it's of much interest in the long term as more than a tick in a feature checklist. David -- Sent from my IBM 1620 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: New -base release?
On 2 Aug 2011, at 09:44, Fred Kiefer wrote: Hi David, you don't seem to get the point. I don't have to tell you that a change the contains the word fix is just as likely to break something as if it doesn't contain that word. And even if these fixes where 100% correct, we still need to make sure that none of the other changes has any effect outside the proper target environment. I agree. I would suggest that we start a code freeze for GNUstep base on the next weekend. This gives people some time (although rather little) to push in features that they really want to see in the next release. Then we have two weeks of code freeze during which only changes to the test are allowed, plus bug fixes that are supported by tests. NO new features during that time, not even tiny ones. After that a release would be fine for me. Sounds good to me. Could we agree on that schedule? I will try to get some response from Richard on this. As tests go, I just run the base tests and had quite a few failing for me: 6248 Passed tests 13 Dashed hopes 8 Skipped sets 5 Failed tests 2 Failed files 1 Failed build I would prefer to see skipped tests and dashed hopes here. A failing test always should mean that my system is broken and unusable in some sense, for example because my objc runtime isn't thread safe. But I don't want to see a failed test because I don't have ICU installed. In that case we should report a skipped test. Of course this will mean that some features of GNUstep base aren't available on my system, but basically GNUstep is still usable. The failed tests are: base/NSMapTable/weak.m base/NSHashTable/weak.m These are expected failures - the tests are actually wrong (I based them on common sense, not on the crazy things that OS X actually does) and I need to revert some things. base/NSString/regex.m It should be relatively easy to turn this one into a dashed hope - I'll fix these three tomorrow. As with the rest of the NSRegularExpression tests, it depends on ICU, so we should be skipping it for you. base/NSJSONSerialization/json.m I will look into the last one that fails to compile without C99 and add an autorelease pool to the regex test. Could you please make the first three tests dashed hopes? Will do. David -- Sent from my STANTEC-ZEBRA ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
New -base release?
Hello all of the people, What do you think about the idea of doing a new point release of -base soon? Most of the changes I've made in -base since the last release have been bug fixes and cleanups - and looking at the commit logs, I'm far from being the only person to do this - so trunk is probably in a more stable state than it was when we did the last release. We've also got some shiny new features, like some 10.7 classes and methods and support for ARC / GC. I'd like to do a little bit more ARC-related cleanup, but I'd be in favour of doing a release in the next week or two. David -- Sent from my Apple II ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: New -base release?
On 1 Aug 2011, at 16:27, Fred Kiefer wrote: we also should get rid of the compiler warnings from NSRegularExpression and NSThread I get no warnings at all from base - what do you get in NSRegularExpression? And did you try removing the @ from the string in the assert() in NSThread (and does it make that one go away)? David -- This email complies with ISO 3103 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: New -base release?
Well, looking through the change log, about 90% of the changes since the last release have contained the word 'fix'. A lot of the changes I made were fixes because PyObjC discovered bugs in GNUstep. I'd like to tighten up some of the ARC-related stuff, but I'm not too bothered about the stability of things like ARC / GC - they're not yet used by many people yet - but lots of the other stuff has been bug fixed since the last release. We don't have many new untested features, but we do have a lot of fixes since the last release. I think we've actually done more bug fixing since the release than during the code freeze period prior to it... David On 1 Aug 2011, at 23:16, Riccardo Mottola wrote: Hi, you added great stuff, but I think it should settle a bit... Just to ensure that base is not causing things to be crashy and/or less portable. Riccardo David Chisnall wrote: Hello all of the people, What do you think about the idea of doing a new point release of -base soon? Most of the changes I've made in -base since the last release have been bug fixes and cleanups - and looking at the commit logs, I'm far from being the only person to do this - so trunk is probably in a more stable state than it was when we did the last release. We've also got some shiny new features, like some 10.7 classes and methods and support for ARC / GC. I'd like to do a little bit more ARC-related cleanup, but I'd be in favour of doing a release in the next week or two. David -- Sent from my Apple II ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep -- Sent from my Cray X1 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: another exception triggered by OGo in gnustep-base
On 29 Jul 2011, at 13:51, Sebastian Reitenbach wrote: I found this documentation here: http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSData_Class/Reference/Reference.html Initializes a newly allocated data object by adding to it length bytes of data from the buffer bytes. but it doesn't state that a subclass should implement it??? SkyDecodeWrapperData is a subclass of NSData, so I should implement that method there? I think this is a GNUstep bug. The default implementation o initWithBytesNoCopy:length:freeWhenDone: should probably be releasing self and returning a new instance of the class that does support this initialiser (as happens in the placeholder data class). David -- Sent from my STANTEC-ZEBRA ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: question regarding explicit exception in NSKeyValueCoding.m:429 -[NSObject(KeyValueCoding) setValue:forUndefinedKey:]
On 28 Jul 2011, at 15:06, Sebastian Reitenbach wrote:
the exception happens here:NSKeyValueCoding.m:429 -[NSObject(KeyValueCoding)
setValue:forUndefinedKey:]
This exception is unconditionally. I first tried to
WANT_DEPRECATED_KVC_COMPAT, and recompiled, but that did not helped.
Then I commented out the exception, and OGo is just fine with that.
Obviously, libFoundation did not raised an exception, so I'm a bit wondering,
who is/was right?
GNUstep is right. On OS X:
$ cat undefined.m
#import Cocoa/Cocoa.h
int main(void)
{
[NSAutoreleasePool new];
[[NSObject new] setValue: @foo forUndefinedKey: @bar];
return 0;
}
$ clang -framework Cocoa undefined.m
$ ./a.out
2011-07-28 15:17:05.872 a.out[56109:903] *** Terminating app due to uncaught
exception 'NSUnknownKeyException', reason: '[NSObject 0x100111410
setValue:forUndefinedKey:]: this class is not key value coding-compliant for
the key bar.'
I don't have a mac, so cannot check what would happen there if I'd run into
this setValue:forUndefinedKey:?
It throws an NSUnknownKeyException. This is the documented behaviour when you
try to set a nonexistent key. Why is OGo trying to do this? What is it
expecting to happen?
Anyways, instead of commenting out the exception, I guess I need to put an
exception handler somewhere, and catch it?
Am I on the right track here?
No, silently discarding missing key error is almost certainly the wrong thing
to do. If that is the desired behaviour for a specific class, then it should
override setValue:forUndefinedKey: and discard it, but more likely it should
not be setting values for keys that don't exist...
David
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Odd problem
On 25 Jul 2011, at 11:44, Fred Kiefer wrote: Could it be that there are cases (64-bit machine?) where node-key is not equal to GSI_MAP_READ_KEY(map, node-key), that is (*(node-key))? I don't think it's a 64-bit issue. I see valgrind errors in the NSSet tests on a 32-bit system. I'll take a look now. David -- Sent from my brain ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: API diffs
On 23 Jul 2011, at 14:41, Quentin Mathé wrote: Le 21 juil. 2011 à 11:34, David Chisnall a écrit : Hi Everyone, Just in case you've not see this already, this release Apple has published diffs against the last set of APIs, so it's easy to see what was added across an entire framework with 10.7: http://developer.apple.com/library/mac/#releasenotes/General/MacOSXLionAPIDiffs/index.html%23//apple_ref/doc/uid/TP40010630 Lots of new AppKit stuff, and a little bit of new Foundation stuff. The NSOrderedSet, NSJSONSerialization are welcome additions. NSOrderedSet would be trivial to implement in Objective-C++ with std::map (in fact, I wouldn't be surprised if that's how Apple implements it). Since we're not allowed to use Objective-C++ in base, it will be a bit trickier. I've just committed an implementation of NSJSONSerialization. Please test it - I've committed some tests for the NSData API, but the NSStream API is not well tested at all. The NSLinguisticTagger looks promising too. Yup, although it depends on some other things that we don't have (I added stubs for the bits that NSRegularExpression needs, but this would be worth doing properly). But my favorite additions is the layout constraint support in the AppKit… I have been waiting this feature for ages. Yes, should make localisation easier. The other thing I really appreciate is that dragging sessions are now clearly reified, until now it was hard to take control precisely over the dragging (this gave me some headaches for EtoileUI). It looks like there are some interesting small additions to NSResponder. These mostly seem to be syncing with UIKit. AppKit now should support a superset of the interaction models that UIKit supports. And it's good to see that the view-support has been added to NSTableView and NSOutlineView :-) Yes, I wonder a bit if it would be worth rewriting NSTableView to always use views (and use NSControl where NSCell is used), rather than try to integrate views into the existing stuff. David -- Sent from my Apple II ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Odd problem
On 25 Jul 2011, at 18:17, Germán Arias wrote: NSJSONSerialization.m:104:5: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] This code may need some tweaking to compile with compilers that don't support the 12-year-old version of the C standard. David -- Sent from my Cray X1 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Odd problem
On 24 Jul 2011, at 01:03, Germán Arias wrote: As I can see this is a problem with libobjc in gcc, so I will ask at gcc help list. Thanks. While I wouldn't completely rule out a libobjc bug, this kind of crash is usually caused by a message being sent to a dangling pointer. Try using valgrind or NSZombieEnabled to find what it is and where it's being deallocated. David ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: NSZone pointers
On 23 Jul 2011, at 07:57, Richard Frith-Macdonald wrote: David, I've never liked zones, but we probably need to keep them around for people who *do* want them. I implemented per-object zone pointers simply because I couldn't figure out a way to get reasonable performance if people used a lot of zones and we had to look outside the object to determine the zone, but that was back when machines were slower (and when I thought people actually used zones a lot), and the world has changed in the last decade or so :-) I think people DID use zones a lot - they just don't anymore. Even now, if we continue to support zones without zone pointers in objects, we will slow down a bit because we have to do some sort of check to see whether an object is in a zone or not, but I suspect that a. practically nobody uses zones This seems to be the case. The only program I found that used zones was one I wrote - and that was just a research prototype. b. the slowdown is relatively unimportant on modern hardware If anything, I'd expect the reduced cache churn to have more of an impact. -zone is called relatively infrequently over an object's lifetime, but we lose a word of cache per object for the zone pointer. By the way, I did some profiling a few years ago and found that the average size for Objective-C objects (counting allocations - actually, in an NSZone) was 24 bytes (on a 32-bit system), so removing the zone pointer gives about a 15% memory saving in object memory. In Gorm, it's about a 2% saving, because object memory is dwarfed by things like images and mapped code. Why don't we make them a configurable default, but with the default setting being to NOT have them? Well, as a first step, I can commit the NSObject.m part of my diff. This still allows zones to work, but removes the pointer. We can then think about removing them completely. I'm a bit hesitant to make that a configuration option, because I suspect that will leave us with a code path that hardly anyone uses, and which is therefore easy to break. If we build with zones turned off (the default), we could just optimise the NSZone... functions to be direct calls to the malloc family of functions, and code would be a tiny bit faster than at present. If we build with zones on, we could maintain a map from objects to zones and the -zone method could consult the map to see if an object is in a non-standard zone (or we could ask each zone if the object is in it), rather than keeping a pointer before the object. These lookups would make everything slower, but we'd then have a consistent memory layout for an object irrespective of the configuration option. The diff I sent calls NSZoneForPointer() in -zone, which then asks each zone if it owns the pointer. In the no-zones case, this function already has a fast path that skips the lookup and just returns NSDefaultMallocZone(). If someone is implementing a custom zone that doesn't use a contiguous block of memory (allowing fast checks by just checking if the pointer is in the range), then they need to implement a map or similar. The most common use for zones even in the NeXT days was implementing short-lived bump-the-pointer allocators. These can have a very fast lookup, and there generally weren't many of them alive at once. With GC, we do use two zones - one for the malloc zone and one for the GC zone - but the GC code paths have their own NSZoneForPointer() that handles this, by just asking the GC if it's managing the pointer. If we're going to remove zones, then we need to make sure that we remember about this... David -- Sent from my IBM 1620 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: NSZone pointers
On 21 Jul 2011, at 23:26, Stefan Bidi wrote: Just wondering... how's CoreFoundation affected by this? CFAllocators (NSZone's equivalent) is everywhere. Does it also get disregarded? I've been overlooking CFAllocator for a while now, so I would prefer if it wasn't used at all, too. On OS X, NSZone and CFAllocator are not the same. NSZone is something inherited from NeXT. CFAllocator is a C version of std::allocator from C++. CF structures that use allocators store their own reference to them, although I wouldn't be surprised if some of the toll-free bridged versions don't bother and always use malloc(). David ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
[ANN] PyObjC for GNUstep
Hi Everyone, Are you worried that your Objective-C code is too fast? Too readable? Too maintainable? Well now you can fix that, by adding Python! Attached is a diff against PyObjC that allows it to build with GNUstep[1]. This allows Python to use Objective-C objects, to subclass them, and to pass Python objects to Objective-C. There are still some bugs, but please try it, play with it, and see what breaks! With PyObjC, it's trivial to export a Python interface for scripting your Objective-C code, so you can allow Python programmers to write plugins and so forth without needing to modify your Objective-C code. This port was funded by Inverse: http://www.inverse.ca/. David [1] Tested with libobjc2 1.5, GNUstep-base and corebase from trunk on Linux/PowerPC and FreeBSD/x86. pyobjc.diff Description: Binary data ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
API diffs
Hi Everyone, Just in case you've not see this already, this release Apple has published diffs against the last set of APIs, so it's easy to see what was added across an entire framework with 10.7: http://developer.apple.com/library/mac/#releasenotes/General/MacOSXLionAPIDiffs/index.html%23//apple_ref/doc/uid/TP40010630 Lots of new AppKit stuff, and a little bit of new Foundation stuff. David ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
NSZone pointers
Hello the list.
I said a little while ago that I was uncertain about the utility of the zone
pointer for every object, because in most cases it would be wasting one word
per object to store a value that is the same for every single object.
I decided to test this, with the attached diff. Please test it and see what
you find. On exit, it will log the number of times zone lookup was performed
and the number of times that it returned a zone other than the default malloc()
zone.
In my testing, Gorm's memory usage dropped by about 2MB and it used a
non-default zone precisely zero times. If this is representative, then it
would make sense to commit the NSObject portion of this diff, so we can avoid
burning RAM for no benefit. If, on the other hand, people are actually using
zones a lot, then this will make their code slower and so is a bad idea.
David
--
This email complies with ISO 3103
Index: Source/NSObject.m
===
--- Source/NSObject.m (revision 33594)
+++ Source/NSObject.m (working copy)
@@ -409,7 +409,6 @@
* (before the start) in each object.
*/
typedef struct obj_layout_unpadded {
-NSZone *zone;
NSUInteger retained;
} unp;
#defineUNP sizeof(unp)
@@ -420,7 +419,6 @@
* structure correct.
*/
struct obj_layout {
-NSZone *zone;
NSUInteger retained;
char padding[ALIGN - ((UNP % ALIGN) ? (UNP % ALIGN) : ALIGN)];
};
@@ -770,7 +768,7 @@
GSOnceFLog(@GSObjCZone() is deprecated ... use -zone instead);
if (object_getClass(object) == NSConstantStringClass)
return NSDefaultMallocZone();
- return ((obj)object)[-1].zone;
+ return NSZoneFromPointer(object);
}
#endif
@@ -818,7 +816,6 @@
if (new != nil)
{
memset (new, 0, size);
- ((obj)new)-zone = zone;
new = (id)((obj)new)[1];
object_setClass(new, aClass);
AADD(aClass, new);
@@ -861,7 +858,7 @@
if ((anObject != nil) !class_isMetaClass(aClass))
{
obj o = ((obj)anObject)[-1];
- NSZone *z = o-zone;
+ NSZone *z = NSZoneFromPointer(o);
/* Call the default finalizer to handle C++ destructors.
*/
@@ -2160,7 +2157,7 @@
*/
return NSDefaultMallocZone();
#else
- return (((obj)self)[-1]).zone;
+ return NSZoneFromPointer(self);
#endif
}
Index: Source/NSZone.m
===
--- Source/NSZone.m (revision 33594)
+++ Source/NSZone.m (working copy)
@@ -1932,14 +1932,26 @@
}
static void rnfree (NSZone *zone, void *ptr);
+static long long defaultZoneLookups;
+static long long otherZoneLookups;
+__attribute__((destructor))
+static void logStats(void)
+{
+fprintf(stderr, NSZoneFromPointer() called %lld times. %lld non-default
zones returned\n, defaultZoneLookups + otherZoneLookups, otherZoneLookups);
+}
+
GS_DECLARE NSZone*
NSZoneFromPointer(void *ptr)
{
NSZone *zone;
if (ptr == 0) return 0;
- if (zone_list == 0) return default_zone;
+ if (zone_list == 0)
+{
+ defaultZoneLookups++;
+ return default_zone;
+}
/*
* See if we can find the zone in our list of all zones.
@@ -1953,6 +1965,16 @@
}
}
[gnustep_global_lock unlock];
+ if (0 != zone)
+{
+ otherZoneLookups++;
+ NSLog(@Non-default zone found);
+}
+ else
+{
+ defaultZoneLookups++;
+}
+
return (zone == 0) ? default_zone : zone;
}
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: [ANN] PyObjC for GNUstep
On 21 Jul 2011, at 13:13, Stefan Bidi wrote: On Thu, Jul 21, 2011 at 2:10 AM, Fred Kiefer fredkie...@gmx.de wrote: I am not interested in Python, but looked over your changes to see what functionality is missing or different in GNUstep. One thing that I noticed was that this code expects that result of a copy operation on an NSMutableArray is a mutable array, and that on GNUstep you had to use mutableCopy. If this is true we should change the GNustep behaviour and add a test case for this. Any other interesting stuff you found while working on this? That's probably because NS(Mutable)Array objects in Cocoa are actually NSCFArray objects (due to the toll-free bridging mechanism), which can be either mutable or immutable. I just tested it, and the GNUstep behaviour is correct. [NSMutableArray -copy] does return an immutable array: NSMutableArray *a = [NSMutableArray new]; id b = [a copy]; [b addObject: @foo]; This terminates with an exception: 2011-07-21 13:17:19.940 a.out[15566:903] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '*** -[NSCFArray insertObject:atIndex:]: mutating method sent to immutable object' So, it's probably one of the many bits in the PyObjC code that didn't work on GNUstep because it was Just Plain Wrong™ and shouldn't work on OS X either. David ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: [ANN] PyObjC for GNUstep
On 21 Jul 2011, at 14:04, Ivan Vučica wrote: Hi David, that's great! Will this be submitted upstream? Ask Ludovic. I'm not sure if the plan is to merge it or for Inverse to maintain a GNUstep branch of PyObjC. I'd imagine the latter in the short term and the former in the longer term. David ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: NSZone pointers
On 21 Jul 2011, at 14:16, Ivan Vučica wrote: I didn't even bother looking up what zones are for until now. They're not used very much anymore, because half of Cocoa is not zone-aware. On OS X, zones are opaque, so they're not even very useful, they just act as hints for the allocation policy. Judging by information on CocoaDev, it looks to me like zones might primarily be interesting to games, screensavers and other continuously-rendered and high-performance applications. Not really. They were mainly used on OPENSTEP for optimisation where lots of short-lived objects that would never be aliased were created and destroyed at once. Generally though, if that's the problem then the right solution is to use C structure rather than objects. Given the throughput of a modern malloc() implementation, it's largely irrelevant. I've done some things with zones in the past, for example defining a persistent zone backed by an mmap()'d segment, so that objects could persist between program invocations (needed some hacks to update their isa pointers on each restart though, so it wasn't very useful), but I've not seen any post-NeXT code that used them for anything. It would be interesting to have this as a ./configure-able setting when building the runtime, with the default being current behavior. Reducing RAM usage is not very important these days. I disagree. Reducing RAM is still important, and in this case it's a trade: either reduce RAM or reduce CPU cycles. I think we're optimising for the very unlikely case and burning RAM. More importantly, we're burning cache. Objects are allocated starting at the zone pointer, which means that we're wasting one word of a cache line in every object for a value that almost never needs to be accessed - every time you touch an object, you'll be pulling it into cache. Reducing cache churn is likely to make more of a performance difference than anything else in this diff - on a modern system, efficient cache usage is one of the biggest factors in performance. David ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: NSZone pointers
On 21 Jul 2011, at 14:27, David Chisnall wrote: On 21 Jul 2011, at 14:16, Ivan Vučica wrote: I didn't even bother looking up what zones are for until now. They're not used very much anymore, because half of Cocoa is not zone-aware. On OS X, zones are opaque, so they're not even very useful, they just act as hints for the allocation policy. Oh, and apparently I missed that in Objective-C 2 they were removed. +allocWithZone: on OS X now apparently ignores the zone pointer and -zone always returns the default malloc() zone. David ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Logging NSData
On 21 Jul 2011, at 20:12, Andreas Höschler wrote: Hi Ivan, Could it be preferring -localizedDescription? Is -localizedDescription also implemented? Just guessing here. Thanks for the hint. I tried that, but still no avail! :-( Any more ideas? I wondered if it was a class cluster problem - NSData is a class cluster, but as far as I could see none of the subclasses implemented -description. Are you sure that your category is actually being loaded? David ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
[ANN] GNUstep Objective-C Runtime 1.5
Hi Everyone, I've just pushed the 1.5 release of libobjc2 (yes, I said I would do this a week ago, but PyObjC uncovered a couple of bugs that I wanted to fix first). Thanks to Niels, Quentin, Sebastian, Wolfgang, Ludovic, and everyone else who helped me find and fix bugs and test new features. This is an important release for GNUstep, because it's one of the few times when we're not playing catchup with Apple. This release of the runtime supports all of the Objective-C language features supported by the compiler that Apple ships for OS X 10.7 and iOS 5 under the brand Apple's LLVM Compiler 3[1]. This includes support for automatic reference counting, which is now the default development mode for OS X and is fully supported by the runtime, in combination with LLVM / Clang trunk. David [1] Actually a snapshot of LLVM / Clang trunk from between 2.9 and 3.0. LLVM releases don't always happen at convenient times for Apple, so the use their own release numbers. GNUstep Objective-C Runtime 1.5 === This is the sixth official release of the GNUstep Objective-C runtime (a.k.a. libobjc2). This runtime was designed to support the features of Objective-C 2 for use with GNUstep and other Objective-C programs. Highlights of this release include: - Support for Apple-compatible garbage collection APIs, along with extensions to support CoreFoundation-style explicit reference counting in a garbage collected environment. This uses the Boehm garbage collector and is enabled by specifying boehm_gc=yes when building. This requires version 7.1 or later of libgc. Code compiled with -fobjc-gc can be mixed with code that implements normal reference counting and with code compiled with -fobjc-gc-only. The runtime supports both GC and non-GC code when compiled with GC support and will automatically select the correct behavior depending on the loaded code. - The runtime will now use Boehm GC for several internal data structures, if it is built with GC enabled. This avoids the need for defensive programming with respect to thread safety in several places. - This is the first release to provide a superset of the functionality provided by the Mac Objective-C runtime, as shipped with OS X 10.6. - Full support for Automatic Reference Counting (ARC), compatible with OS X 10.7 and iOS 5, including support for __weak references. - The LLVM optimisation passes have been improved and better tested. Code compiled with them now passes the EtoileFoundation test suite. You may obtain the code for this release from subversion at the following subversion branch: svn://svn.gna.org/svn/gnustep/libs/libobjc2/1.5 Alternatively, a tarball is available from: http://download.gna.org/gnustep/libobjc2-1.5.tar.bz2 The runtime library is responsible for implementing the core features of the object model, as well as exposing introspection features to the user. The GNUstep runtime implements Apple's Objective-C Runtime APIs, and a small number of GCC APIs for legacy compatibility. This library is based on the Étoilé Objective-C Runtime, an earlier research prototype, and includes support for non-fragile instance variables, type-dependent dispatch, and object planes. It is fully compatible with the FSF's GCC Objective-C ABI and also implements a new ABI that is supported by Clang and Étoilé's LanguageKit and is required for some of the newer features. Although the runtime has been tested by several people, and is being used extensively by the Étoilé project, it is entirely new (MIT licensed) code and may still contain bugs. If you come across any problems, please report them to the GNUstep Developer mailing list gnustep-...@gnu.org. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: problem with gnustep on OpenBSD sparc64 -- the journey goes on
On 8 Jul 2011, at 15:00, Sebastian Reitenbach wrote: I'm not sure if it's related, but I was seeing 'conditional jump depends on uninitialised value' errors in valgrind while loading defaults. I think it was somewhere in GSXML, but I'm not completely sure - by the time I got around to trying to find the cause, they'd stopped happening. I assumed that meant someone had fixed the relevant bug, but it might just have meant that my defaults settings had changed in a way that stopped the bug from being triggered. I guess, uninitialized variables, the compiler should warn, when it encounters it while compiling. Not always. In GCC, it only warns at all in an optimised build, because it only computes a code flow graph during optimisation. In any case, often the compiler doesn't have enough information to know. For example: int foo; bar(foo); Is foo used uninitialized? Maybe. If bar starts with *foo = 0, then no. If bar starts with if (foo) then yes. If bar is defined in another compilation unit, the compiler can't tell. David -- Send from my Jacquard Loom ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: problem with gnustep on OpenBSD sparc64
On 7 Jul 2011, at 09:56, Wolfgang Lux wrote: ... and here. The sizeof_type callback expects an argument with type size_t *, but element_size has type int *. This does work on 32-bit architectures where sizeof(size_t) = sizeof(int) and it works coincidentally on low-endian 64-bit architectures like x86_64, but is definitely wrong for big-endian 64-bit machines like sparc. Ugh - obvious bug that I completely missed, thanks. It's fixed in svn, and I had a look at all of the other places where that pattern is used. They all use size_t correctly. Thanks for looking at that, and many thanks to Sebastian for testing on SPARC64. I really should get my USii out of the attic and test GNUstep stuff on it... David -- Sent from my IBM 1620 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: problem with gnustep on OpenBSD sparc64
On 7 Jul 2011, at 09:01, Sebastian Reitenbach wrote: sizeof_type: after calling parse_array: element_size: 0, element_count: 4, size pointern: 0xfffcf0d0 ^^^ as far as I can see, the value on address 0xfffcf0d0 should be 32, but I have no idea, why it is not 32??? It's possible that it's a compiler bug, which compiler are you using? Can you add a watchpoint on that address in gdb and see when it is assigned to? Can you also try adding volatile to the declaration of element_count? That shouldn't make a difference, but if it's a bug with the compiler's optimiser then that might tell it not to do incorrect optimisation... David -- This email complies with ISO 3103 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: problem with gnustep on OpenBSD sparc64 -- the journey goes on
On 7 Jul 2011, at 10:25, Sebastian Reitenbach wrote: I updated libobjc from svn, and starting i.e. addressmanager now I get some steps further, but I run into this bus error: Try r33476. David -- Sent from my Cray X1 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Automatic Reference Counting
On 7 Jul 2011, at 20:52, Ondřej Hošek wrote: They remain untouched by ARC. ObjC pointers are detected using semantic analysis -- a heuristic along the lines of oh, an asterisk, I'm taking over would break everything (including the strict superset of C philosophy). C or C++. ARC works extremely nicely with Objective-C++. C++ structures can contain Objective-C pointers, but then they become non-POD types and have a destructor added that releases the Objective-C ivars. C++ templates can take Objective-C types and will have the retain / release calls added automatically. This means that you can write things like: std::mapint, __weak NSString* foo; The variable foo will then be a(n ordered) map from integers to NSStrings. If you do: id a = foo[12]; Then a will be nil if the string that was inserted into the collection has been deallocated before this line is reached. This makes Objective-C++ a lot nicer to work with - you don't need to worry about memory management for Objective-C objects, it happens automatically even when you store them in C++ variables. You don't have to think about copy constructors calling retain and so on, all of this Just Works™. David -- Sent from my STANTEC-ZEBRA ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Automatic Reference Counting
Ooops, forgot to CC: the list: On 7 Jul 2011, at 19:23, Ivan Vučica wrote: Hi, I just read this, so I have a couple of questions :-) On Wed, Jun 29, 2011 at 15:36, David Chisnall thera...@sucs.org wrote: ARC does some quite nice things for you. For every assignment, the compiler will automatically insert calls to runtime functions that do the retain / release juggling for you. It will also implicitly add code to your objects freeing all instance variables. Because of this, some things are not allowed in ARC mode: - Implementing -retain, -release, or -autorelease - Calling -retain, -release, or -autorelease - Storing object pointers that are not __unsafe_unretained qualified in structures. If calling -retain, -release and -autorelease is not allowed, how is it possible to mix ARC with non-ARC code? Does the compiler throw a warning, an error, or the thing just silently doesn't work? You can only mix them in separate compilation units, you can't mix them within the same source file. The compiler will reject any code that explicitly calls any of these methods in ARC mode. In non-ARC mode, it will permit them and will not insert the barrier functions. What happens when -retain, -release and -autorelease are overridden? This is not allowed in ARC compilation units. My ARC implementation will call them if the class declaring them does not explicitly opt in to ARC (see README for how to do this). Not sure about Apple's. What happens when non-__unsafe_unretained pointers are stored in structure? Does it silently crash? The compiler rejects the code. Are all pointers __strong by default? All object pointers, yes. What happens with non-Objective-C pointers, such as results of SDL functions? Nothing. ARC only affects objects. Other pointers are treated just as they are in C. Will I have any problems using SDL if ARC is used in same codebase? Not unless you are passing objects to SDL code (e.g. for callbacks) without calling CFRetain() on them. David -- Sent from my Difference Engine ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: problem with gnustep on OpenBSD sparc64 -- the journey goes on
On 7 Jul 2011, at 22:10, Sebastian Reitenbach wrote: defaults read works well, when there are no defaults existing, but with the copied .GNUstepDefaults file, it runs into the bus error. I'm not sure if it's related, but I was seeing 'conditional jump depends on uninitialised value' errors in valgrind while loading defaults. I think it was somewhere in GSXML, but I'm not completely sure - by the time I got around to trying to find the cause, they'd stopped happening. I assumed that meant someone had fixed the relevant bug, but it might just have meant that my defaults settings had changed in a way that stopped the bug from being triggered. David -- Sent from my Difference Engine ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: problem with gnustep on OpenBSD sparc64
On 6 Jul 2011, at 10:55, Sebastian Reitenbach wrote: Error: Instance variables in NSTextTable overlap superclass NSTextBlock. Offset of first instance variable, _layoutAlgorithm, is 196. Last instance variable in superclass, _widthType, ends at offset 148. This probably means that you are subclassing aclass from a library, which has changed in a binary-incompatibleway. I think this is a bug in how libobjc2 is calculating sizes. The last ivar of NSTextBlock is an array of arrays, and my guess is that the runtime thinks that it is smaller than it is. David -- Send from my Jacquard Loom ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: problem with gnustep on OpenBSD sparc64
On 6 Jul 2011, at 11:02, David Chisnall wrote: On 6 Jul 2011, at 10:55, Sebastian Reitenbach wrote: Error: Instance variables in NSTextTable overlap superclass NSTextBlock. Offset of first instance variable, _layoutAlgorithm, is 196. Last instance variable in superclass, _widthType, ends at offset 148. This probably means that you are subclassing aclass from a library, which has changed in a binary-incompatibleway. I think this is a bug in how libobjc2 is calculating sizes. The last ivar of NSTextBlock is an array of arrays, and my guess is that the runtime thinks that it is smaller than it is. Having said that, I can't actually reproduce this, and objc_sizeof_type() seems to return the same size as sizeof() for me when I copy the last ivar into a file and test it. Both of these numbers look a bit wrong. For me, class_getInstanceSize() returns 172 for NSTextBlock, so unless you've got some very strict alignment requirements 196 looks too large. The header doesn't seem to have been modified for a long time, so I'm not sure how it could happen. Can you tell me from the debugger: - What the type encoding of the last ivar is - What the calculated size of the last ivar is - How big void* is on your platform David -- Sent from my brain ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: problem with gnustep on OpenBSD sparc64
On 6 Jul 2011, at 11:45, Sebastian Reitenbach wrote: On Wednesday, July 6, 2011 12:14 CEST, David Chisnall thera...@sucs.org wrote: On 6 Jul 2011, at 11:02, David Chisnall wrote: On 6 Jul 2011, at 10:55, Sebastian Reitenbach wrote: Error: Instance variables in NSTextTable overlap superclass NSTextBlock. Offset of first instance variable, _layoutAlgorithm, is 196. Last instance variable in superclass, _widthType, ends at offset 148. This probably means that you are subclassing aclass from a library, which has changed in a binary-incompatibleway. I think this is a bug in how libobjc2 is calculating sizes. The last ivar of NSTextBlock is an array of arrays, and my guess is that the runtime thinks that it is smaller than it is. Having said that, I can't actually reproduce this, and objc_sizeof_type() seems to return the same size as sizeof() for me when I copy the last ivar into a file and test it. Both of these numbers look a bit wrong. For me, class_getInstanceSize() returns 172 for NSTextBlock, so unless you've got some very strict alignment requirements 196 looks too large. The header doesn't seem to have been modified for a long time, so I'm not sure how it could happen. IIRC, the alignment is fairly strict on sparc64, but I'm not an expert ;) Hmm, 196 might be correct for SPARC64. Can you tell me from the debugger: - What the type encoding of the last ivar is - What the calculated size of the last ivar is Do you can give me a hint how I can figure this out? At which frame stack I should potentially go, or where to set a breakpoint, and what to enter? The stack frame that calls abort (objc_compute_ivar_offsets()). It has a local variable called ivar, which is the last ivar in the superclass. It uses this to calculate the size from the type. David -- Sent from my IBM 1620 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: problem with gnustep on OpenBSD sparc64
On 6 Jul 2011, at 13:01, Sebastian Reitenbach wrote:
69 /* Find the last superclass with at least one ivar. */
70 while (NULL == super-ivars)
71 {
72 super = class_getSuperclass(super);
73 }
74 struct objc_ivar *ivar =
75
super-ivars-ivar_list[super-ivars-count-1];
76
77 // Find the end of the last ivar - instance_size
contains some padding
78 // for alignment.
(gdb)
Do you maybe can propose an NSLog() statement that I could add somewhere
after teh line 74 to print out the values you would like to see?
Easiest would be a patch for me that I can apply and recompile, and report
back.
On line 76:
fprintf(stderr, Ivar type: %s, size: %d\nSuperclass size: %d, ivar-type,
(int)objc_sizeof_type(ivar-type), (int)super-instance_size);
David
-- Sent from my Apple II
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: problem with gnustep on OpenBSD sparc64
On 6 Jul 2011, at 13:13, Sebastian Reitenbach wrote:
Ivar type: [3[4i]], size: 0
Well, that's obviously wrong, but I can't reproduce it. We can, at least, work
from a simpler test case now though:
$ cat test.c
#include stdio.h
size_t objc_sizeof_type(const char*);
int main(void)
{
printf(%d\n, (int)objc_sizeof_type([3[4i]]));
return 0;
}
$ cc size.c -lobjc ./a.out
48
On SPARC64, I think sizeof(int) is 8, so I'd expect this to be 96. If it
isn't, we need to work out why. Can you step through this call and see if it's
doing anything obviously wrong?
David
-- Sent from my PDP-11
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: problem with gnustep on OpenBSD sparc64
On 6 Jul 2011, at 13:44, Sebastian Reitenbach wrote:
running it in gdb, I see the following:
It helps me if you can tidy up the gdb traces a bit before sending them. It's
easy to miss important things in the middle of a load of list commands and
frames in libc with no debugging info.
Breakpoint 1, objc_sizeof_type (type=0x200c10 [3[4i]]) at encoding2.c:319
319 sizeof_type(type, size);
This is calling the real sizeof function, which calls itself recursively on
subtypes.
(gdb) print type
$1 = 0x200c10 [3[4i]]
(gdb) s
sizeof_type (type=0x200c10 [3[4i]], size=0xfffdebd8) at
encoding2.c:152
152 type = objc_skip_type_qualifiers(type);
No type qualifiers on this, skip it.
0x000204d64c94 in objc_exception_throw () at encoding2.c:85
Well, that's wrong. Looks like the debug info is mangled. What did you
compile libobjc2 with, and did you do a debug build?
85 static void parse_struct_or_union(const char **type, type_parser
callback, void *context, char endchar)
This is the generic visitor function that walks a structure or union type. It
can only be invoked via parse_struct() or parse_union(), and these are only
invoked as a result of encountering { or ( in the input stream, so it shouldn't
be there...
(gdb) s
0x000204d64c98 85 static void parse_struct_or_union(const char
**type, type_parser callback, void *context, char endchar)
(gdb) s
objc_skip_type_qualifiers (type=0x200c10 [3[4i]]) at encoding2.c:20
20 while('\0' != *type strchr(type_qualifiers, *type))
(gdb)
Ah, now we're back somewhere sensible...
strchr (p=0x204e74c68 rnNoORV, ch=91) at /usr/src/lib/libc/string/index.c:41
41 /usr/src/lib/libc/string/index.c: No such file or directory.
in /usr/src/lib/libc/string/index.c
objc_skip_type_qualifiers (type=0x200c10 [3[4i]]) at encoding2.c:20
20 while('\0' != *type strchr(type_qualifiers, *type))
(gdb)
25 }
(gdb)
Okay, we've passed the (nonexistent) type qualifiers, now we're really parsing
it.
sizeof_type (type=0x200c10 [3[4i]], size=0xfffdebd8) at
encoding2.c:153
153 switch (*type)
(gdb)
196 int element_count = parse_array(t,
(type_parser)sizeof_type, element_size);
First character is [, therefore this is an array type. Parse it as an a array
type.
(gdb) print type
$4 = 0x200c10 [3[4i]]
None of the input stream has been consumed yet.
(gdb) s
193 const char *t = type;
(gdb)
196 int element_count = parse_array(t,
(type_parser)sizeof_type, element_size);
(gdb)
194 int element_size = 0;
This will be set by the recursive call.
(gdb) s
196 int element_count = parse_array(t,
(type_parser)sizeof_type, element_size);
(gdb)
parse_array (type=0xfffdeb08, callback=0x204d652a0 sizeof_type,
context=0xfffdeb00) at encoding2.c:77
77 (*type)++;
(gdb) print type
$5 = (const char **) 0xfffdeb08
(gdb) print *type
$6 = 0x200c10 [3[4i]]
In the array type. The line after this, type will be 4[4i]]. It's helpful
if you print values after they've been modified...
(gdb) s
78 int element_count = (int)strtol(*type, (char**)type, 10);
Array encodings start with the number of elements, parse it.
What was the result?
(gdb) print *type
$7 = 0x200c10 [3[4i]]
Well, that's wrong. Might be incorrect debug info, or optimisation not
actually committing the change until the end of the function. Maybe add a
printf() here?
(gdb) s
75 {
(gdb) print element_count
No symbol element_count in current context.
Not so helpful - are you sure you did a debug build?
(gdb) s
77 (*type)++;
(gdb)
78 int element_count = (int)strtol(*type, (char**)type, 10);
Optimisation stuff - reordered all of these expressions.
(gdb) print type
$8 = (const char **) 0xfffdeb08
(gdb) print *type
$9 = 0x200c10 [3[4i]]
(gdb) s
strtol (nptr=0x200c11 3[4i]], endptr=0xfffdeb08, base=10) at
ctype.h:133
133 return (c == -1 ? 0 : ((_ctype_ + 1)[(unsigned char)c] _S));
Here we go. *type is the correct value here. strtol should return 3 (did it?)
and set *type to [4i]] (did it?)
(gdb)
parse_array (type=0xfffdeb08, callback=0x204d652a0 sizeof_type,
context=0xfffdeb00) at encoding2.c:79
79 *type = callback(*type, context);
Now we're calling sizeof_type() again, on the array element type.
Did you skip over that? That should be parsing the element type [4i] as an
array of 4 integers and returning the size.
Unfortunately, you seem to have stepped over the bit that actually calculated
the array element size, so I can't tell if it's doing anything sensible.
David
-- Sent from my Apple II
___
NSMutableDictionary Vs std::tr1::unordered_map
Hi Everyone,
I'm not sure if this is interesting to anyone else, but I thought I'd share it
anyway.
One of the interesting things about ARC is that it makes it trivial to use C++
collections with Objective-C objects: the compiler will insert the relevant
read / write barriers on every assignment, including ones in templates. This
means that you can do things like std::mapint, __weak id and get a map from
integers to zeroing weak references to objects.
With this in mind, I thought I'd see how GNUstep's NSMutableDictionary
implementation held up against the C++ TR1 / C++0x unordered_map, as
implemented in GNU libstdc++. I generated a large array of NSNumber instances
containing pseudorandom values, then populated each of the collections with
them (same key and value) and then searched for each one.
The three collections I tested were:
- The stock NSMutableDictionary, as returned by +new
- A new NSMutableDictionary subclass (CXXMap), which is a thin wrapper around
unordered_map
- Using unordered_map directly.
I tested on a couple of machines. Unfortunately, modern CPUs are rubbish for
benchmarking, because there is no longer a strong correlation between CPU
seconds and work done. My rough tests showed:
- Inserting into CXXMap was roughly 20-30% faster than inserting into
NSMutableDictionary
- Searching CXXMap was about 10% faster than searching NSMutableDictionary
- The performance difference between CXXMap and using unordered_map directly
was negligible.
I've attached my CXXMap code at the end of this email. Feel free to use it in
your own workloads and see if you see anything different.
David
-- Sent from my IBM 1620
namespace {
struct eqid
{
bool operator()(const id s1, const id s2) const
{
return (s1 == s2) || [s1 isEqual: s2];
}
};
struct hashid
{
size_t operator()(const id s1) const
{
return (size_t)[s1 hash];
}
};
}
@interface CXXMap : NSMutableDictionary
{
std::tr1::unordered_mapid, id, hashid, eqid map;
}
@end
@implementation CXXMap
- (void)setObject: (id)obj forKey: (id)key
{
key = [key copy];
map[key] = obj;
}
- (void)removeObjectForKey:(id)aKey
{
map.erase(aKey);
}
- (NSUInteger)count
{
return (NSUInteger)map.size();
}
- (id)objectForKey: (id)key
{
return map[key];
}
@end
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: problem with gnustep on OpenBSD sparc64
The stuff around skip type qualifiers is irrelevant - there aren't any, this function is a no-op in this case, ignore it. On 6 Jul 2011, at 18:38, Sebastian Reitenbach wrote: I added some more fprintf's to the functions that are involved, hope the output also helps: $ ./a.out parse_array: element_count: 3, type: [4i]] parse_array: element_count: 4, type: i]] Well, this shows that it is finding the correct number of elements for each array. So, there are two places where it could be going wrong: - Calculating the size of int (line 161) - Combining the size of the elements with the count (line 197) Please see my earlier mail where I explained the code flow. David -- Sent from my IBM 1620 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: problem with gnustep on OpenBSD sparc64
On 6 Jul 2011, at 19:35, Sebastian Reitenbach wrote:
On Wednesday, July 6, 2011 19:47 CEST, David Chisnall thera...@sucs.org
wrote:
The stuff around skip type qualifiers is irrelevant - there aren't any, this
function is a no-op in this case, ignore it.
On 6 Jul 2011, at 18:38, Sebastian Reitenbach wrote:
I added some more fprintf's to the functions that are involved, hope the
output also helps:
$ ./a.out
parse_array: element_count: 3, type: [4i]]
parse_array: element_count: 4, type: i]]
Well, this shows that it is finding the correct number of elements for each
array. So, there are two places where it could be going wrong:
- Calculating the size of int (line 161)
I added two fprintfs before and after that line
- Combining the size of the elements with the count (line 197)
and another fprintf before that line, after the parse_array:
and another 2 fprintf in parse_array, before and after calling the callback.
$ ./a.out
parse_array: type: [4i]]
parse_array: type: i]]
^^^ those lines are in parse_array before the callback
That's good. The elements of the outer array are of type [4i], the elements of
the inner array are of type i.
sizeof_type: sizeof(typeName): 4
sizeof_type: size: 32
^^^ those lines are around line 161
int is 32 bits, that looks sensible. The size of the inner array is 32 bits
(note: we work with bits internally because this code needs to handle
bitfields, which are ugly and evil).
parse_array: type: ]]
^^^ fprintf after calling callback
Okay, now it's coming back up.
element_size: 0, element_count: 4
^^^ this line is before line 197
Hmm, why is element_size 0 here? It was 32 just now - somehow it got reset to
0. This looks like the bug. element_size should have been set to 32 on line
161. Can you check that the address of element_size passed in here is the same
as the address of size on line 161?
parse_array: type: ]
^^^ fprintf after calling callback
element_size: 0, element_count: 3
^^^ this line is before line 197
as far as I can see in line 194:
int element_size = 0;
// FIXME: aligned size
int element_count = parse_array(t,
(type_parser)sizeof_type, element_size);
That FIXME should go in the bin, it was fixed ages ago, so ignore that.
element_size goes into parse_array with a value of 0, and it also gives
itself as the callback function, then in parse_array I see:
static int parse_array(const char **type, type_parser callback, void *context)
{
// skip [
(*type)++;
int element_count = (int)strtol(*type, (char**)type, 10);
*type = callback(*type, context);
// skip ]
(*type)++;
return element_count;
}
This is a generic visitor function for walking arrays. There are similar ones
for walking structures and unions. All of the objc_{something}of_type()
functions are implemented in terms of a simple case function that handles the
primitive types and calls these to recursively visit complex types.
I don't get it what the code is doing in the #define APPLY_TYPE, where the
switch statement checks for the case: i
That #define is kind of puzzling me. It seems to detect the size of the i
correctly, sizeof(typeName): 4, but it somewhere gets lost in the
iterations...
Yup, that's just applying the macro defining the case for every one of the
valid primitive type encodings. The APPLY_TYPE() macro is instantiated once
for each primitive type encoding by type_encoding_cases.h. For the int case,
it matches the case 'i', rounds up size to the alignment required bit int, and
then adds the size of integer (the first bit is only relevant when visiting
structures - we need to make sure that we the field in the right place).
And I'm kind of lost too
Well, it seems to be getting lost returning the size up the stack...
David
--
This email complies with ISO 3103
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: new attempt GNUstep on cygwin
On 4 Jul 2011, at 10:14, Fred Kiefer wrote: you need to run configure --enable-server=win32 if you want the native display and why wouldn't you want that? When I ran Cygwin, I wanted everything using it to use X11 (XFree86, which shows how long ago it was), so that I could access it remotely or locally. X on Windows had a nice rootless mode (actually, two - one where you ran a WM and one where windows were decorated by Windows), so when I didn't want a full Cygwin environment, I could just run a few apps, but when I did I could just make the X server full screen and ignore Windows completely. I'm not sure if it's still true, but back then it was fairly common for apps to use a native Win32 UI with MinGW and X11 with Cygwin. David -- Sent from my brain ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: build failure on FreeBSD
You probably need to rerun configure. I added some qualifiers in various places to allow code using ARC to use the GNUstep headers. In preface.h, there is some code that checks if you are using ARC and #defines these qualifiers away if you are not, but preface.h seems not to be automatically regenerated by make when preface.h.in changes. David On 30 Jun 2011, at 08:00, Riccardo Mottola wrote: Hi, on FreeBSD with gcc, no GC, standard runtime, I get: Making all for tool make_strings... Compiling file make_strings.m ... In file included from ../../Source/./common.h:34, from make_strings.m:23: ../../Headers/Foundation/NSZone.h:78: error: expected specifier-qualifier-list before '__unsafe_unretained' ../../Headers/Foundation/NSZone.h:312: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void' ../../Headers/Foundation/NSZone.h:319: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void' In file included from make_strings.m:25: ../../Headers/Foundation/NSAutoreleasePool.h:56: error: expected specifier-qualifier-list before '__unsafe_unretained' ../../Headers/Foundation/NSAutoreleasePool.h:95: error: expected specifier-qualifier-list before '__unsafe_unretained' In file included from ../../Headers/Foundation/NSDictionary.h:30, from make_strings.m:26: ../../Headers/Foundation/NSEnumerator.h:40: error: expected specifier-qualifier-list before '__unsafe_unretained' gmake[5]: *** [obj/make_strings.obj/make_strings.m.o] Error 1 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep -- Sent from my PDP-11 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: build failure on FreeBSD
Ah, actually the problem is related to make_strings specifically. It still looks for Additions/GNUstepBase/preface.h in preference to Additions/preface.h. Unfortunately, when someone (Richard?) deleted Additions, the old preface.h file won't have been removed because it was not owned by svn, so it will find that one instead of the new one... David On 30 Jun 2011, at 09:12, David Chisnall wrote: You probably need to rerun configure. I added some qualifiers in various places to allow code using ARC to use the GNUstep headers. In preface.h, there is some code that checks if you are using ARC and #defines these qualifiers away if you are not, but preface.h seems not to be automatically regenerated by make when preface.h.in changes. David On 30 Jun 2011, at 08:00, Riccardo Mottola wrote: Hi, on FreeBSD with gcc, no GC, standard runtime, I get: Making all for tool make_strings... Compiling file make_strings.m ... In file included from ../../Source/./common.h:34, from make_strings.m:23: ../../Headers/Foundation/NSZone.h:78: error: expected specifier-qualifier-list before '__unsafe_unretained' ../../Headers/Foundation/NSZone.h:312: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void' ../../Headers/Foundation/NSZone.h:319: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void' In file included from make_strings.m:25: ../../Headers/Foundation/NSAutoreleasePool.h:56: error: expected specifier-qualifier-list before '__unsafe_unretained' ../../Headers/Foundation/NSAutoreleasePool.h:95: error: expected specifier-qualifier-list before '__unsafe_unretained' In file included from ../../Headers/Foundation/NSDictionary.h:30, from make_strings.m:26: ../../Headers/Foundation/NSEnumerator.h:40: error: expected specifier-qualifier-list before '__unsafe_unretained' gmake[5]: *** [obj/make_strings.obj/make_strings.m.o] Error 1 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep -- Sent from my PDP-11 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep -- Sent from my STANTEC-ZEBRA ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
NSProxy retain / release
Hi,
I was looking at NSProxy's code, and it seems to store its retain count in an
ivar, rather than using the standard one. Is there a reason for this? It
means that:
- NSProxy uses one word more than it needs to, two more than it needs to in GC
mode
- -retain and -release on NSProxy subclasses are not thread-safe (they don't
use atomic ops)
- -retainCount and NSExtraRefCount give different results (contrary to the
Cocoa behaviour)
David
$ cat proxy.m
#import Foundation/Foundation.h
int main(void)
{
[NSAutoreleasePool new];
id p = [NSProxy alloc];
NSLog(@%d (%d), (int)[p retainCount], (int)NSExtraRefCount(p));
[p retain];
NSLog(@%d (%d), (int)[p retainCount], (int)NSExtraRefCount(p));
NSIncrementExtraRefCount(p);
NSLog(@%d (%d), (int)[p retainCount], (int)NSExtraRefCount(p));
return 0;
}
# On Cocoa:
$ clang proxy.m -framework Foundation ./a.out
2011-06-30 14:52:45.314 a.out[63606:903] 0x10010ce90
2011-06-30 14:52:45.318 a.out[63606:903] 1 (0)
2011-06-30 14:52:45.318 a.out[63606:903] 2 (1)
2011-06-30 14:52:45.319 a.out[63606:903] 3 (2)
# On GNUstep:
$ clang `gnustep-config --objc-flags` `gnustep-config --base-libs` proxy.m
./a.out
2011-06-30 13:53:55.789 a.out[61681] 0x29ec7c28
2011-06-30 13:53:55.792 a.out[61681] 1 (0)
2011-06-30 13:53:55.795 a.out[61681] 2 (0)
2011-06-30 13:53:55.795 a.out[61681] 2 (1)
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Please test libobjc2
Hello everyone, I'd like to do a release of the GNUstep Objective-C runtime soon, so please can everyone test the current trunk. This adds, among other things, support for Apple-compatible garbage collection and the core support for automatic reference counting. The ARC support is compatible with OS X 10.6. OS X 10.7 and iOS 5 add support for zeroing weak references in ARC mode, which I will add soon, but possibly after the next release, as they require some support from Foundation to work correctly. You will need Boehm GC 7 (I think, maybe 7.1) or greater to enable GC mode. If you do not have this, then you must build with: [g]make boehm_gc=no I've tested GC mode building everything with -fobjc-gc-only. The GC-optional mode for frameworks should work if -base is built with -fobjc-gc or -fobjc-gc-only and the frameworks are built with -fobjc-gc. You can't build GNUstep with -fobjc-arc and some parts of Foundation can not be implemented in ARC mode. For other code, you can try ARC by simply omitting -retain, -release, and -autorelease calls. Clang includes a migration tool that allows you to switch your code over to using automatic reference counting. You can first add -ccc-arrmt-check to your OBJCFLAGS to see if there are any migration issues in your code that need to be manually fixed. Then, after fixing them if you add -ccc-arrmt-modify, clang will rewrite your code to use automatic reference counting. Automatic reference counting is now the default development style in XCode. It's important to test this with GNUstep, as code coming from OS X is increasingly going to be using this mode. David -- Send from my Jacquard Loom ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Automatic Reference Counting
Hi Everyone, This year I got a birthday present from Apple's compiler team: the open source release of the compiler part of their automatic reference counting (ARC) implementation. I've just finished adding the relevant support code to the GNUstep runtime and to GNUstep Base. If you're on the OS X or iOS developer programme (I'm not), then you've probably already played with ARC. If you're not, then here's a quick overview: Object pointers are now either __strong (the default), __weak, or __unsafe_unretained. A __strong pointer contains an owning reference, meaning that it accounts for one retain on the object. A __weak reference does not contain an owning reference and will be automatically zero'd when the object begins deallocation. An __unsafe_unretained pointer is not tracked by ARC at all. ARC does some quite nice things for you. For every assignment, the compiler will automatically insert calls to runtime functions that do the retain / release juggling for you. It will also implicitly add code to your objects freeing all instance variables. Because of this, some things are not allowed in ARC mode: - Implementing -retain, -release, or -autorelease - Calling -retain, -release, or -autorelease - Storing object pointers that are not __unsafe_unretained qualified in structures. ARC code can be mixed with non-ARC code without any problems. This means that you can compile GNUstep with manual reference counting, link against frameworks that use manual reference counting, and still use ARC in your own code. Note that, unlike GC mode, __weak pointers are allowed on the stack in ARC mode. You can, for example, do this: Foo *f = [Foo new]; __weak id weak = f; f = nil; fprintf(stderr, Weak: %p\n, weak); This will always print Weak: 0 when you run it. ARC, like manual reference counting, is deterministic. This code compiles to the equivalent of: Foo *f = [Foo new]; // No retain, because +new returns an owning reference id weak; objc_initWeak(weak, f); // Register weak as a weak pointer, stores f in it objc_release(f); // Release f f = nil; objc_destroyWeak(weak); Apple has also open sourced the optimiser component, which will remove redundant retain/release pairs and attempt to combine various calls into single aggregate ones. ARC is now the default mode for OS X and iOS development, so expect to see a lot of code that uses it... David P.S. Apple's implementation of ARC is not available to the general public until 10.7 is released next month, so this means that GNUstep is shipping the first publicly available (if not officially released) implementation of ARC. -- Sent from my Difference Engine ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: UIKit
On 28 Jun 2011, at 05:30, Amr Aboelela wrote: So later you guys are going to use Chameleon framework as a start to build your own UIKit framework? There may be some code in Chameleon that is useful, but I'm not certain, and the FSF's copyright assignment requirement would be problematic if we did incorporate any. what about QuantumStep is it related to building the UIKit also? As far as I know, QuantumStep doesn't have a UIKit implementation. It uses AppKit on mobile devices. what do u mean by the missing part of CoreAnimation, is CoreAnimation only in UIKit and not AppKit? and isn't it implemented in the Chameleon implementation? CoreAnimation is used by both AppKit on OS X and UIKit on iOS, however AppKit predates CoreAnimation by about 15 years so can be used quite happily without it. UIKit, in contrast, was designed with CoreAnimation in mind and makes (very) heavy use of layers and transitions. CoreAnimation is nice to have with AppKit, but is pretty much essential with UIKit. David -- Send from my Jacquard Loom ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: GNUstep
Amr, Please read emails before replying half a dozen times. I said: There may be some code in Chameleon that is useful, but I'm not certain, and the FSF's copyright assignment requirement would be problematic if we did incorporate any. You somehow interpreted this as 'GNUstep is GPL'd and therefore can't incorporate Chameleon code'. GNUstep is not GPL'd, and even if it were there is no problem incorporating permissively licensed code in a restrictively licensed project - that's the point of permissive licenses. The problem is that GNUstep is part of the GNU project, and requires copyright assignment. That said, there's really no point in incorporating Chameleon into GNUstep. If it provides a working implementation of UIKit on top of our AppKit implementation, then you are free to use both projects without the need for either to subsume the other. David -- Sent from my STANTEC-ZEBRA ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: UIKit
On Sun, Jun 26, 2011 at 5:49 PM, Fred Kiefer fredkie...@gmx.de wrote: At the FOSDEM this year we decided to start a GNUsep sub project to implement UIKit. And just a few weeks later we learned about UIKit: http://chameleonproject.org/ This made us stop our own efforts in this direction. I think nobody ever tried to use this code on top of GNUstep gui and you will need the missing bit CoreAnimation for this. But implementing that should be easier than an full UIKit implementation. Did it? I'm still interested in a proper UIKit implementation - Cameleon is not really equivalent, and is less interesting - I just haven't had time to work on it. I think lack of people with both time and inclination to work on UIKit is more to blame than the existence of Cameleon. David -- This email complies with ISO 3103 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Category for NSString not included?
On 26 Jun 2011, at 18:38, Jonathan Bartlett wrote: I have a category for NSString which defines a method isEmpty. However, I am getting the following error: GSCSubString (instance) does not recognize isEmpty. Is this because this class is not inheriting from NSString, or something else? Which Objective-C runtime are you using? There was a bug with older versions of the GNUstep runtime which occasionally caused categories that were loaded before the classes to get lost. GSCSubString is a(n indirect) subclass of NSString, so a category on NSString should be working. If it isn't, then it's a bug in either your compiler or the runtime. Can you send this message to other string objects? What happens if you do this: [class_createInstance(objc_getClass(NSString)) isEmpty]; David -- Sent from my Apple II ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Category for NSString not included?
On 27 Jun 2011, at 16:06, Jonathan Bartlett wrote: It's the standard gcc 4.1 on CentOS, so it is probably an older runtime. When I built the latest GNUstep, it turned off exceptions, so that is probably the case. Thanks! If you're using the GCC runtime, then you shouldn't be seeing this behaviour - I'm not aware of any shipped versions that included this bug. If you're using a packaged version, you probably don't have debugging symbols switched on in the runtime, which makes this a little bit difficult to track down. You can try inspecting the NSString class in gdb and seeing if your isEmpty method appears in its method list. If it doesn't, then the category has not been loaded. If it does, then the dtable has not been correctly constructed... David -- Sent from my IBM 1620 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Implementation of CommonCrypto?
On 26 Jun 2011, at 05:32, Jonathan Bartlett wrote: Has anyone worked on getting an implementaiton of CommonCrypto for GNUstep? As far as I am aware, there is no need. Apple released CommonCrpyto under a BSD license[1]. Someone (Niels, I think) checked with them to confirm that the EULA-style license for part of it was put there in error a while ago, and it's all available under a BSD license. It is not, as far as I know, packaged by any open source operating systems, so you might want to poke your favourite distribution to produce packages. David [1] http://www.opensource.apple.com/source/CommonCrypto/ -- Sent from my Apple II ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Objective-C code running on Android
On 25 Jun 2011, at 00:45, Ivan Vučica wrote:
Regarding getting GUI to work, that would be something amazing. It would
perhaps be even more interesting to get Java-ObjC bridge to work -- that
would allow getting native GUI to work. AppKit user interfaces are pretty
much designed for use on desktops, and one would need to redesign the GUI
anyway to run it on mobile. (Using an NSPanel, for example, would be quite a
strange experience on a mobile device.)
It looks like there will be more work involved in getting clang to work. I
just tried using Apple's clang to compile code for Android. Instead of using
the custom compiler, I've tried to use clang with specified -arch armv6 and
with added appropriate include paths.
#OBJC=$(NDKOBJC)/usr/local/android/bin/arm-eabi-gcc
OBJC=clang -I `dirname
\`$(NDK)/toolchains/arm-linux-androideabi-4.4.3/prebuilt/darwin-x86/bin/arm-linux-androideabi-gcc
-print-libgcc-file-name\``/include -I `dirname
\`$(NDKOBJC)/usr/local/android/bin/arm-eabi-gcc
-print-libgcc-file-name\``/include -arch armv6
It's slightly more complicated. You also have to tell clang which as and ld to
use. I think you should be able to do this with -triple rather than -arch
(which will still be trying to produce Darwin Mach-O binaries, just for ARM).
It also needs to know to produce Linux / ELF binaries.
It is already quite promising; I did not really connect the dots enough to
expect to find an ARM backend.
However, headers from the same GCC version conflict among themselves:
In file included from test.m:1:
In file included from
/Applications/android-sdk-mac_x86/ndk-objc/usr/local/android/bin/../lib/gcc/arm-eabi/4.2.1/include/objc/Object.h:31:
In file included from
/Applications/android-sdk-mac_x86/ndk-objc/usr/local/android/bin/../lib/gcc/arm-eabi/4.2.1/include/objc/typedstream.h:33:
In file included from
/Applications/android-sdk-mac_x86/android-ndk-r5c/platforms/android-5/arch-arm//usr/include/stdio.h:42:
In file included from
/Applications/android-sdk-mac_x86/android-ndk-r5c/platforms/android-5/arch-arm//usr/include/sys/_types.h:40:
/Applications/android-sdk-mac_x86/android-ndk-r5c/platforms/android-5/arch-arm//usr/include/machine/_types.h:46:24:
error:
typedef redefinition with different types ('long' vs 'int')
typedef long ptrdiff_t;
^
In file included from test.m:1:
In file included from
/Applications/android-sdk-mac_x86/ndk-objc/usr/local/android/bin/../lib/gcc/arm-eabi/4.2.1/include/objc/Object.h:30:
In file included from
/Applications/android-sdk-mac_x86/ndk-objc/usr/local/android/bin/../lib/gcc/arm-eabi/4.2.1/include/objc/objc.h:34:
/Applications/android-sdk-mac_x86/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/darwin-x86/bin/../lib/gcc/arm-linux-androideabi/4.4.3/include/stddef.h:149:26:
note:
previous definition is here
typedef __PTRDIFF_TYPE__ ptrdiff_t;
^
It's the same if I specify only the custom compiler (the 4.2.1), and if I
specify the Android compiler (4.4.3).
Apparently GCC tolerates int being used as equal to long, while clang does
not. I would fix this in headers, but I suspect there might be more such
differences.
Any tips on getting clang to be more tolerant?
I don't think so. You can try -std=gnu99, but this redefinition of the typedef
is not allowed in standard C (int and long are distinct types, even if they
have the same type), so if gcc accepts it then it's a GCC bug.
David
-- Sent from my brain
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Objective-C code running on Android
On 24 Jun 2011, at 21:58, Ivan Vučica wrote: On Fri, Jun 24, 2011 at 22:55, Pirmin Braun p...@seat-1.com wrote: Am Fri, 24 Jun 2011 22:03:31 +0200 schrieb Ivan Vučica ivuc...@gmail.com : Is there any interest in getting at least GNUstep's Foundation to run on Android? yes. I am almost certain that I will NOT be able to successfully do this, which is why I have posted on this list. :-) I'm interested. The clang that Apple ships can target ARM and the GNU runtimes, so you should be able to target android without a custom compiler, although you will need a copy of Android binutils for linking, along with the Android headers. With the latest NDK, there is even the possibility of running -gui. There's a Skia back end for Cairo, so it should be possible to port the drawing part with minimal effort, although the event handling and window management code will need writing. David -- This email complies with ISO 3103 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Please test pending bugfix release of base
On 18 Jun 2011, at 14:07, Richard Frith-Macdonald wrote: The solution here might be to cast the argument to match the format string rather than trying to make the format string fit the argument. The only problem with that is a possible loss of precision when casing a 64bit value to int/unsigned. I'm not really certain what the *ideal* solution is. C comes with a convenient set of macros to solve this kind of problem, in inttypes.h. The macro PRIdPTR will expand to either d or lld, depending on whether intptr_t is int or long long (or to something else, if applicable). Since NS[U]Integer is the same as [u]intptr_t, then it seems to make sense to use these macros. Format strings can be written as: NSLog(@some integer: % PRIdPTR, someNSInteger); Note: This does not work with strings being localised. In that case, casting to long and using %ld or %lu is probably better (this is what Apple recommends). David -- Sent from my PDP-11 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Please test pending bugfix release of base
On 18 Jun 2011, at 08:41, Richard Frith-Macdonald wrote: I've toyed with the idea of providing a standard mechanism to register objects in some way rather than storing them in static variables, so we could (when in debug mode) release all such registered objects from an atexit handler. Of course, going through all the codebase and changing all the deliberately 'leaked' data to be registered that way would be a large undertaking for no operational gain ... but the advantage for tracking leaks is big enough that I'd be prepared to devote some time to it. Valgrind will not report things stored in static variables as leaked (they will be in the still reachable at exit total), so anything that valgrind is reporting is really being lost. David -- Sent from my PDP-11 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: ANN: GNUstep 2.6.0 for openSUSE 11.4
On 14 Jun 2011, at 23:19, Nat! wrote: Am 14.06.2011 um 23:47 schrieb David Chisnall: On 14 Jun 2011, at 22:38, Nat! wrote: Hmm interesting, though I don't see offhand, why dividing what objc_msgSend does into separate steps makes it inherently more portable. I will have to look into my code, to see if its feasible to roll my own objc_msgSend, (because I use it a lot as I found out :) ). objc_msgSend() is a trampoline function. It must pass all of its arguments to the called IMP. This is not possible in C. Apple implements a version of it in assembly for every calling convention, for every architecture, and for every platform that they support (currently, this comes to about a dozen implementations, and they support a very narrow range of platforms compared to GNUstep). Ah I see. I hope, that if I reduce the scope to a small fixed number of id parameters, I can get by. It's really better to just call class_getMethodImplementation() and call the returning IMP. This code will work everywhere, and the performance difference between using it and using objc_msgSend() is tiny. Note that you are supposed to cast objc_msgSend() to the correct type before use anyway (95% of the time, this doesn't matter, 5% it will corrupt your stack), and you need to make sure that you call the _sret, _fpret suffix versions (not all of which exist on all Darwin targets) to call it correctly. objc_msgSend() is designed for compilers to use, not for you to use. The logic required to select the correct one is nontrivial, to say the least. Ah and one more question, regarding forwarding is __objc_msg_forward (instead of __objc_msg_forward2) ever really used or can I ignore it, when I run atop a current runtime ? The forwarding hooks that are used depend on the runtime. See GSFFIInvocation.m for how they are all used. Is there some exported #define (like OBJC_API_VERSION) that could be checked, which runtime I am compiling against ? Not really. GCC 4.6 and later define something. The GNUstep Runtime defines __GNUSTEP_RUNTIME__ in objc/runtime.h and then provides a set of capability flags in objc/caps.h to let you check at compile time and run time which capabilities the runtime that you are using supports. You should never need to care about any of them in your own code. Hmm, maybe it is different on GNUstep. On OSX I know that I care :) On OS X, these forwarding hooks are not even part of the semi-public API. You can only find them by digging around in the libobjc source. They also have a habit of changing without notice and without backwards compatibility. If you are using them on OS X, then you are definitely doing something wrong. The only reasons that they are part of the 'public' API with GNU libobjc implementations is that they are part of the libobjc-Foundation interface, and we don't have the luxury of tying libobjc to Foundation quite as closely as Apple does. With the GNUstep runtime, all hooks like this are declared and documented in objc/hooks.h. If you're including this file outside of a compiler or a Foundation implementation, then you are almost certainly doing something very, very wrong. David -- Sent from my Difference Engine ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: ANN: GNUstep 2.6.0 for openSUSE 11.4
On 15 Jun 2011, at 10:16, Nat! wrote: It's more of an experiment porting my stuff to GNUstep, so your advice nonwithstanding I think my plan, will work, because I believe I only use it objc_msgSend for simple calls (max. one or two id parameters and return value). Otherwise I would have to change a lot of source. I used to have a macro that did this in runtime.h, but I removed it because it's very easy to use it wrongly. If you're sure that you're only using id parameters, then you can use something like this: #define objc_msgSend(obj, sel, ...) class_getMethodImplementation(object_getClass(obj), sel)(obj, sel, ## __VA_ARGS__) Hmm, this could indicate that I _do_ have the wrong set of headers. In /usr/lib/gcc/i586-suse-linux/4.5/include/objc I neither see caps.h nor runtime.h. But it's not a big problem, for my experiments I can live without them. That means that you're using the GCC runtime (the gcc in the path is a hint). Since it's the 4.5 runtime, you will be using the runtime API implementation from the ObjectiveC2 framework in GNUstep-base. David -- This email complies with ISO 3103 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: ANN: GNUstep 2.6.0 for openSUSE 11.4
On 14 Jun 2011, at 08:46, Matt Rice wrote: what version of gdb? I mainly use the last GPLv2 release, but I tried installing the latest 7.x, and aside from the fact that it's much easier to crash the debugger I've not noticed any difference. The bugs I'd got used to working around are all there. David -- Sent from my Apple II ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Problem with exception handling: WAS: no thread-safe +initialize in old gnustep runtime?
Which compiler / flags are you using? The ability to generate a backtrace is HIGHLY dependent on the compiler. For example, -fomit-frame-pointer (default at some optimisation levels) will break it. There are also some linker flags required for undwind-based backtraces to work. David On 14 Jun 2011, at 09:31, Sebastian Reitenbach wrote: On Monday, June 13, 2011 16:41 CEST, Sebastian Reitenbach sebas...@l00-bugdead-prods.de wrote: Hi, On Monday, June 13, 2011 14:30 CEST, David Chisnall thera...@sucs.org wrote: On 13 Jun 2011, at 13:19, Sebastian Reitenbach wrote: I just reread the Linux signal manual, and saw, its not retruning the address of the actual handler, but of the old handler, so I exchanged the calls later in that function from i.e. signal(SIGSEGV, env-segv) to signal(SIGSEGV, SIG_DFL) but without difference in the behaviour observed. This will break any code that had already set a signal handler (for example, anything using GC, since libgc implements dirty bits for its generational garbage collection by marking pages as no-access and then catching the SIGSEGV). A better solution would be to stop using the C signal() function and use the POSIX sigaction() function. Since this has been in the standard since 1990, I'd imagine that it's pretty well supported, although someone should check MinGW. Even with that change, this code isn't even remotely thread safe, so it would be better to replace it with something less fragile. Is there no port of libexecinfo to OpenBSD? If there is, then it would be a good idea to add that as a dependency for the FreeBSD port and use the backtrace() version. Thanks for pointing me to libexecinfo, I wasn't aware of it. There exists a port for it for OpenBSD, and I got gnustep-base configure to find and link against it. (I had to use LDFLAGS=-lexecinfo) in the configure and make environment. Unfortunately, Sudoku now crashes in libexecinfo ;) I really ugly hacked libexecinfo, to not to crash, and then Sudoku was able to successfully generate the sudoku. Libexecinfo, when the crasher there is investigated and fixed, could be a way to go, but still doesn't explain the hanger, when its not used. After bothering ports@openbsd with the crasher I've seen in libexecinfo, I was told, that this library seems to be kind of broken in general. I was also pointed to libbacktrace: http://opensource.conformal.com/cgi-bin/cvsweb/backtrace/backtrace/ Which I installed, and linked gnustep-base against it. It actually fails the same way like libexecinfo fails. Looking at the code, it is more or less doing the same like libexecinfo. I also tried to run Sudoku without HAVE_BACKTRACE on Linux. After ./configure I edited the config.h and change the #define HAVE_BACKTRACE 1 into a #undef HAVE_BACKTRACE. Now gnustep-base was using the gnustep internal backtrace generation, which just worked as expected. If I don't find a solution to the problem, I think, I kind of have to assume that the backtrace generation is not working on OpenBSD, and will just disable the generation of the backtrace, with the little patch I had. cheers, Sebastian ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep -- Sent from my PDP-11 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: ANN: GNUstep 2.6.0 for openSUSE 11.4
On 14 Jun 2011, at 09:35, Nat! wrote: Yes, sure works better this way. This leads to the next question, how do I set a breakpoint on raise ? gdb /usr/bin/Gorm break -[NSException raise] ... future... y run I think break [NSException raise] (no -) should work. Alternatively, putting a breakpoint on objc_exception_throw will work. David -- Sent from my Difference Engine ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: ANN: GNUstep 2.6.0 for openSUSE 11.4
On 14 Jun 2011, at 21:43, Nat! wrote: Am 10.06.2011 um 03:08 schrieb Richard Stonehouse: GNUstep 2.6.0 for openSUSE 11.4 *** Ok, two more questions popped up: I am trying to build UnitKit. I can build the framework. When I say make install, this framework then gets installed (by GNUstep make) into /usr/local/lib/GNUstep/Frameworks. But, the compiler doesn't find the headers when compiling the tool. So #import UnitKit/UKRunner.h fails Even if I give it -F/usr/local/lib/GNUstep/Frameworks, it makes no differences. If I create a symlink in /usr/local/include ln -s /usr/local/lib/GNUstep/Frameworks/UnitKit.framework/Headers UnitKit it works. Odd. UnitKit in the Étoilé repository installs correctly. That symlink should be created by [g]make install... Secondly, where is objc_msgSend (or objc_msg_send as it's probably called in GNUstep) ? There is a reference in the headers, but it's nowhere declared, which I find a bit peculiar/troubling. objc_msgSend() is an implementation detail of the NeXT and Apple runtimes. It is not possible to implement in a portable fashion, so the GCC and GNUstep runtimes use a different approach. For portable code, use class_getMethodImplementation() and then call the returned function. David -- Sent from my brain ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: ANN: GNUstep 2.6.0 for openSUSE 11.4
On 14 Jun 2011, at 22:38, Nat! wrote: Hmm interesting, though I don't see offhand, why dividing what objc_msgSend does into separate steps makes it inherently more portable. I will have to look into my code, to see if its feasible to roll my own objc_msgSend, (because I use it a lot as I found out :) ). objc_msgSend() is a trampoline function. It must pass all of its arguments to the called IMP. This is not possible in C. Apple implements a version of it in assembly for every calling convention, for every architecture, and for every platform that they support (currently, this comes to about a dozen implementations, and they support a very narrow range of platforms compared to GNUstep). Ah and one more question, regarding forwarding is __objc_msg_forward (instead of __objc_msg_forward2) ever really used or can I ignore it, when I run atop a current runtime ? The forwarding hooks that are used depend on the runtime. See GSFFIInvocation.m for how they are all used. You should never need to care about any of them in your own code. David -- Send from my Jacquard Loom ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: ANN: One Step to GNUstep - pre-release version 0.9
On 13 Jun 2011, at 00:54, Nicola Pero wrote: Then there is the point that, if all that matters is the technical feature parity with Apple, then buy an Apple; why bother with GNUstep. If that's your view, then why bother with GNUstep at all? Why not work on an Objective-C framework that doesn't aim for Cocoa compatibility. and for many people in the project using a GNU/FSF compiler is important, more important than having some small additional feature. I'd hardly call full support for the language that GNUstep uses a 'small feature', nor would I put the ability to reuse the front end for IDE integration or the static analyser in the same category. We've fixed well over a hundred GNUstep bugs so far that have been found by the static analyser alone. If you consider the track record of Apple dealing with open source projects, you'll clearly see the dangers. Apple likes their version of open source, where you can see the code, send bug fixes and contribute improvements (so that they save money on development costs) but to actually use the result you'll have to buy an Apple product; Let's see, Apple's open source record... Well, they took the FreeBSD useland, libc, and chunks of the kernel and... released improvements upstream. The bastards! They published Launchd under an open source license (APSL) and, when the FreeBSD Foundation said that this license was too restrictive, Apple's evil response was... to relicense it under the Apache 2.0 License. Freedom haters! Then they forked KHTML and, when the KHTML team started complaining about their patch dumps being difficult to support... they started developing WebKit in an open subversion repository and soliciting outside contributions and ports to other platforms. Deliciously evil! Or are you talking about Apple-originated projects, like CalDAV server and libdispatch, which Apple callously and ruthlessly exploited the open source community by giving us large amounts of production-quality code under various open source licenses? In your release notes for GCC 4.6, I saw that you thanked some Apple developers for their assistance in porting features from their branch. Did you mention that you viewed them as instruments of 'rapacity and amorality' at the time? the Apple Objective-C runtime is a great example. Do you mean the one that they inherited from NeXT under a proprietary license and released under APSL 2 (a FSF-approved license), or the one that they wrote from scratch and released under APSL 2? If you want to use it on another platform then you are free to do so, but the design's pretty horrible so I don't think anyone does want to... With clang they're pushing even further, since clang on Linux is basically now the freeware trialware version of Apple XCode; This doesn't even make sense. Clang has almost exactly the same feature set on OS X and on Linux (__thread only works on Linux, but aside from that they're equivalent). XCode adds a lot of features on top, just as it did when it used GCC as the compiler. For example, XCode uses clang for syntax highlighting, and those open source hating bastards at Apple have provided a C API with guaranteed forward compatibility to allow other IDEs to do the same. XCode provides a nice UI for viewing static analyser results, while Linux users with the 'trialware' version have to view the same results in a web browser. Well, actually clang emits the results in plist format, so it would be fairly trivial for GNUstep code to make use of it... of course to get the real thing you have to buy an Apple product because the license allows them to have open source developers (ie, unpaid developers outside of Apple) look at the compiler code, debug and improve it, but the actual final product That's how Free Software is supposed to work! People who mutually benefit from the existence of a project collaborate to work on it. (XCode where the compiler is deeply integrated into the real IDE) can only be obtained by purchasing an Apple product. And if something ever goes wrong with this model, they can still announce that they're merging clang/LLVM into XCode and you'll never see a single line of source code of it again. And then we'll have to rely on the other contributors, like Google (one of the biggest contributors to LLVM, as they are not moving a lot of their back end code over to LLVM / Clang - they also employ more of the GCC team than any other company at the moment). Open source works best when it's backed by self interest. Apple benefits from having a decent compiler with a reusable back end and a front end that can be used for analysis as well as compilation. If they developed it in house then it would be more expensive than if they got outside contributors to do some of the work. Replace Apple with Google, Adobe, or any of the other company or individual that contributes to LLVM / clang in the previous
Re: ANN: One Step to GNUstep - pre-release version 0.9
On 13 Jun 2011, at 12:49, Matt Rice wrote: I would take this one step further, and propose that such a project would benefit from severing its ties with objective-c all together. Take objective-c as a model, god forbid make a standard for it and call it something else. A Small language, encapsulating the Objective-C object model, allowing objects to Talk to each other by sending messages, maybe? David -- Sent from my STANTEC-ZEBRA ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Problem with exception handling: WAS: no thread-safe +initialize in old gnustep runtime?
On 13 Jun 2011, at 13:19, Sebastian Reitenbach wrote: I just reread the Linux signal manual, and saw, its not retruning the address of the actual handler, but of the old handler, so I exchanged the calls later in that function from i.e. signal(SIGSEGV, env-segv) to signal(SIGSEGV, SIG_DFL) but without difference in the behaviour observed. This will break any code that had already set a signal handler (for example, anything using GC, since libgc implements dirty bits for its generational garbage collection by marking pages as no-access and then catching the SIGSEGV). A better solution would be to stop using the C signal() function and use the POSIX sigaction() function. Since this has been in the standard since 1990, I'd imagine that it's pretty well supported, although someone should check MinGW. Even with that change, this code isn't even remotely thread safe, so it would be better to replace it with something less fragile. Is there no port of libexecinfo to OpenBSD? If there is, then it would be a good idea to add that as a dependency for the FreeBSD port and use the backtrace() version. David -- Sent from my brain ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: ANN: One Step to GNUstep - pre-release version 0.9
On 13 Jun 2011, at 16:09, Richard Stonehouse wrote: Thanks, that's good to know. I see that openSUSE (the distribution I use) intends to adopt GCC 4.6 as default compiler in the next release but, currently, it is breaking quite a few of their package builds. However I don't know whether that is the fault of the compiler or the packages. I've seen no complaints about clang, but suspect this is because there is less work being done with it. The only issues I've seen recently with clang have been caused by the integration of core libraries and headers with GCC packages, so the compiler hard-codes paths. On some Linux distributions, standard headers are installed in non-standard locations with paths that change for every GCC release. Clang needs to copy these hard-coded paths, which takes a little bit of effort and requires someone using the distribution to notice. There are a few SuSE developers who are quite active in the LLVM community though, so hopefully this won't be a problem for you. Are you saying these are provided by clang but not by GCC 4.6? Mostly. A few are purely runtime features and don't require any compiler support. These are available with GCC 4.6 and the GNUstep runtime. Most require at least some assistance from the compiler. OK, from what you and Ivan say it seems clear that there's a need to do something about Objective C 2.0. I'll pull down the openSUSE packages of clang and gcc-4.6, and have a go at doing some GNUstep builds, then think about where to go from there. Either way, presumably, the GNUstep libobjc2 will be required. It's not required for the core Objective-C 2 features, but it is required for the non-fragile ABI and most of the things on my earlier list. The licensing issues are important - we want to avoid lock-in. But this does not preclude developers using clang if it provides a better development environment. Dual-sourcing is good, if it is practicable. My worry is that the features supported by the two compilers may diverge (or have they done so already)? The clang license is BSD-style. It is a FSF-approved Free Software license. GCC 4.6 supports a subset of the features of clang. The biggest developer-visible example of this is the lack of blocks support. Apple's most recent APIs make heavy use of blocks, so this is problematic for people coming from OS X. GNUstep uses some macros to try to hack around this, but it's problematic in a few places. For example the API documentation for NSRegularExpression requires that the primitive method be implemented with blocks and the other methods call this. If you compile GNUstep-base with GCC then you get a version that doesn't work like that (because, while it's trivial to call blocks with macros, it's nontrivial to create them). What I'm leaning towards, if it turns out to be practicable, is using GCC 4.6 for the GNUstep library builds but including clang for developers' use. That is assuming there's no incompatibility between GCC-compiled GNUstep libraries and clang-compiled applications. But that's not necessarily my last word! This would mean that you wouldn't be able to use blocks in -base, and you wouldn't be able to use the non-fragile ABI. The main advantage of the non-fragile ABI is that you can add ivars to classes without needing to recompile their subclasses. This is what the non-fragile part means: changes to one framework are much less likely to Unlike Apple's non-fragile ABI, the non-fragile ABI supported by the GNUstep runtime (and clang / LanguageKit) does permit code compiled with the GCC ABI to be used as well, but they suffer from the same limitations that they do in all contexts. For example, if an application uses the fragile ABI, then it will need to be recompiled if framework classes that it uses are recompiled, even if they are compiled using the non-fragile ABI. I'd have liked to do a break-the-world release, but the feedback I got suggested that this would lead to crowds of packagers with pitchforks and flaming torches outside my house. Clang uses a hybrid ABI when compiling in fragile mode, where it exports some extra metadata that only the GNUstep runtime will notice (the GCC runtime will ignore it). David -- Sent from my Difference Engine ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
