Re: NSException.m: _objc_unexpected_exception undeclared
What is the output of gnustep-base's configure ?
While I was yesterday looking at config.log, I saw that:
a) _objc_unexpected_exception test passes.
b) All other unexpected exception tests fail.
This is surprising; the tests for the various options are really simple. For
example,
the test for the _objc_unexpected_exception is --
extern void (*_objc_unexpected_exception)(id);
int main (void)
{
_objc_unexpected_exception = 0;
return 0;
}
If this compiles fine, then really the reference to _objc_unexpected_exception
in NSException.m
should compile fine too, and vice versa if NSException.m doesn't, then the test
shouldn't. :-)
I guess the only explanation I can think of is that a different runtime is
being used during the configure stage
and during the actual compilation stage. Do you have multiple runtimes
installed ? How do you switch from
one to the other ?
I guess it's hard to help without more information.
Thanks
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: WebServer: caching responses
We are not sure yet whether we want to use WebServer as a replacement for Apache or whether we will try implement an Apache module to merely pass us the application specific requests. There is a third alternative, which is using Apache as a reverse proxy in front of your Objective-C web server. That's the standard enterprise setup for these things. It's great for performance. And, to answer your question, in that setup, if your Objective-C web server properly sets the caching headers for static data, Apache (if you enable mod_cache etc) will automatically cache it for you. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: ARC Cleanups
With ARC, the runtime needs to be able to find the reference count for the
fast path,
so this becomes part of the interface between the runtime and Foundation, and
so has
to be stable. If we keep the order refcount, zone, isa, then we can't remove
the zone
pointer without breaking the ABI. If we change the order to zone, refcount,
isa, then
the interface is just refcount, isa, and we can delete the zone in the future
if we want,
or keep it if it makes sense.
Yes, it makes sense, and it would be good to have a simple and stable ABI. :-)
Btw, if we're changing everything, I wonder if we shouldn't even make these
normal
instance variables ... then, the ABI for the runtime would be really simple ...
the
first instance variable would be the class ('isa'), and the second one would be
the
retain count. The third one would be the zone, and the runtime can ignore that.
I can think of a number of problems and complications with this, so I'm not
sure it would
be a good idea, but it's worth considering. ;-)
Thanks
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: gnustep-make 2.6.1
It would be worth doing a 2.6.1 gnustep-make release with the code in trunk ... which should fix building with clang. :-) I think there's no point in waiting more ... it works with GCC (I tried GCC 4.7.0 prerelease) and it was reported working with clang. Adam, can you make a release ? Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make 2.6.1
Has the regression with passing the linker flags correctly been fixed? The code has been changed a month ago, but if nobody reports if it works or not on their platform, it's hard to know! ;-) After waiting for a month for feedback, I have to assume that people have been using trunk and have no problems with it. The code looks good. Anyhow, at least you reported that it works for you with clang on FreeBSD. That's good to know. :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: error on linux x86-64
On 30 May 2011, at 22:49, Riccardo Mottola wrote: Hi, I just reconfigured base on linux x86-64 and I get this after a clean and new build: Making all for subproject Additions... Linking subproject Additions ... gcc: @OBJ_MERGE_CMD_FLAG@: No such file or directory I don't get this error on other platforms where I recompiled today Did you reconfigure gnustep-make ? What version of gnustep-make are you using ? Was @OBJ_MERGE_CMD_FLAG@ replaced in config.make ? Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Moving the bug system to GNA....
I simply would like to have things in one place. Right now we're spread between GNA and Savannah. It sounds like a good idea - I support it. But, I would recommend that: * we put up extensive announcements on the web site, mailing list, etc. * we try to migrate over the open bugs. I had a quick look in Savannah, and you can export all the bugs as an XML blob. So presumably, you'd export them in that format, then write a short script to import them all into the new one (using wget or curl ?). Unless GNA allows you to import them in block, or the GNA developers are willing to help. :-) * if there's nothing left in savannah, it may be worthwhile putting notices there pointing people to the GNA system. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
gnustep-make 2.6.1
It would be worth doing a 2.6.1 gnustep-make release with the code in trunk ... which should fix building with clang. :-) We probably need to test the future gnustep-make 2.6.1 using the latest gnustep-base release with a few different compilers to be sure that the latest iteration of the -r/-Wl,-r code now works with all the compilers and that we haven't broken anything ... so we need to test gnustep-make trunk + latest gnustep-base release * using GCC 2.95 (the oldest compiler we support) * using GCC 4.x (x 6) * using GCC 4.6 * using clang (latest release) Has anyone had any problems with any of these ? Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: sparc: ld: --relax and -r may not be used together
GCC 4.1 for example does have -mrelax on at least some targets on which --relax does something, but not everywhere, so the portable version would seem to be -Wl,--relax. Yes, that would be solution if we were trying to pass --relax to the linker ;-) But we need to do something different - we need to prevent GCC from silently passing --relax to the linker, which is quite a different problem :-( On the relevant targets, GCC avoids passing '--relax' only if it sees '-r' or '-mno-relax' on the command-line. As testing for support for -mno-relax is too complicated, we just decided (at least for this release) to simply use '-r' (like in all previous releases) when using GCC for partial linking. Better ideas would be welcome. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: OS X and gnustep-base 1.21.1
Here is a nasty patch (against svn HEAD, but it may work for 1.21.1 too) to fix that issue: patch-ObjectiveC2-Makefile.preamble FWIW, I have just committed this change to GNUstep-make where it really belongs. Thus other projects that include the Objective-C runtime headers in plain C source files should benefit from this as well. What about changing runtime.c to be runtime.m ? Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: OS X and gnustep-base 1.21.1
What about changing runtime.c to be runtime.m ? And do the same for other projects as well (e.g., Jigs :-). Yes, that would make sense. :-) I think having this patch in GNUstep-make is better because many people won't notice that they introduce a portability issue when they include the Objective-C runtime headers in plain C source files. But this is a good point; it sounds good to me then. Thanks PS: We may want to rewrite the patch to use a configure check for efficiency. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep Make not adding -fblocks
If this works, then add -fblocks to CFLAGS and OBJCFLAGS (and maybe CXXFLAGS). I implemented this in gnustep-make trunk (soon to be 2.6.0). I do recommend testing. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac
I can implement this, but I won't use it myself - is it something that other people genuinely need or want ? If it helps, I'll do it. It would help me :-) I really would like to keep the old GNUstep file system layout and currently I always have to remember to specify this when configuring GNUstep make. Use ./config.status --recheck ./config.status instead of configure :-). This is what I'm doing anyway because I need to remember a lot more additional configure options on OS X. It seems that this is probably the best solution ... as it's the standard way of re-running configure with the same options. It seems better than to develop our own, gnustep-make-only custom way of basically doing the same thing :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Desktop file generated with wrong path ?
It's probably the wrong way to do it but with the following patch the icon path is set correctly and the desktop file recognized as such by Nautilus. Philippe, thanks a lot for this patch. Well done, excellent suggestions! :-) I reworked your code a bit, and applied it to trunk. Let me know if it still works properly - it works for me. :-) Thanks PS: Do you have a copyright assignment in place ? You may want to get one if you're planning on contributing more code. :-) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: gnustep-base code freeze
Can we please spend the next few days testing base
but not making any changes other than documentation
and any fixes for serious bugs (and perhaps the one
number formatter bug reported by the testsuite).
I'd really like a new base release this month, and
there's not much of it left.
Sounds great. :-)
But there's a few improvement to configure for gnustep-make and gnustep-base
(to improve detecting support for ObjC exceptions and blocks) which are
pending.
Shall I go ahead and make these changes in the next day or two, or shall we
make them after this release ?
I think they are good to have, but would require another few weeks
of widespread testing in the wild before we can release them. If you
want to release quickly, it may be too late ?
This would have to be binary compatible with the existing stable base library
(I've been trying not to introduce any incompatibilities, but can other people
check this).
Sure. I guess you're worried about binary compatibility because you're thinking
of Linux distributions and such like. In that case, though, it's good to
backport
new features, but in terms of compiler/runtime support, keep in mind that
for example the libobjc contained in GCC changed from GCC 4.5 to 4.6 and had its
so name increased from 2 to 3. That means a gnustep-base package shipped by a
Linux
distribution is either built against libobjc.2 or against libobjc.3. It can't
be linked against both. So, once you upgrade the libobjc package to libobjc.3,
you'll also have to upgrade your gnustep-base package to one linked against
libobjc.3,
at which point you may as well just install the latest gnustep-base package (all
the other packages on top will also be linked either against libobjc.2 or
libobjc.3,
but can't be linked to both, so they'd all have to be upgraded too).
The reason I'd like to do this is that having a new release
of both the stable and development branches might get the
new features out to people via different distributions more
quickly. Is this a good idea?
Probably. I'm a bit confused by the terminology though. The new release
from trunk would be a stable release presumably ? So, it would be 1.22.0 ?
And you also want to backport changes to the old stable release, 1.20.x,
releasing 1.20.{x+1} ?
That makes some sense, even if there is the problem of testing 1.20.{x+1},
because
I think everyone as been testing from trunk, ie, they tested the future 1.22.0
(and when you backport things, typos/mistakes may slip in).
Or, are you saying that what is in trunk would simply become 1.20.{x+1} ?
Thanks
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-base code freeze
I thought at FOSDEM we decided not to do the stable/unstable thing? Distributions like Debian will only pick up the stable one, which means that we end up with loads of people complaining that feature X doesn't work with GNUstep, even though it's been supported for a year in trunk and six months in the latest release. Yes. I'm not sure what the current release policy is (well, I know for gnustep-make); I think it changed a few times. If we're discussing it, I have a bit of time today and will suggest what I think would be good. (feel free to disagree; and I may not have time to follow up on the discussion). If I can suggest an example of a good release policy, I'd suggest the postgresql one. They seem to follow the following policy: * all releases are stable * a new important release (binary-incompatible with the previous one) every 18 months or so (eg, 8.4.0, 9.0.0, etc). * each important release gets small, bugfix-only, binary-compatible releases for many years (eg, 8.4.1, 8.4.2, 8.4.3, etc) Please note that they don't backport improvements, only bugfixes. That makes it much easier to support all these subminor releases. I think it works really well because: * it's easy to understand. * if you want new stuff, you get new stuff every year or two. Obviously, you need to upgrade if you are upgrading an existing system because you want new stuff. * if you have live systems that use an old version, you still get important bugfixes for them in a binary-compatible format. * it approximately matches the release cycle of the typical Linux distribution. I'll expand on this last point, which is very important. Generally speaking, the most efficient way to get things out to GNU/Linux users of a particular distribution would be to use a release cycle that exactly matches the release cycle of the distribution; that would mean that you feed stuff to the distribution exactly when they are preparing the new release to ship, and you don't feed new stuff when they are not preparing a new release to ship (so you'd clock your development phases to match their non-preparing-a-release periods). Because there are so many different distributions that we want to support, that is not possible; but still, we can try to use a release cycle that approximately matches the average release cycle of these distributions. That most likely means a major, binary-incompatible release every X months (where the choice of X is obviously subject to debate) which is fed into their new major releases, and binary-compatible minor bugfix releases following that for Y years (where the choice of Y is obviously subject to debate), which is fed into their bugfix/support package upgrade pipeline. If our X is too small compared to the average one used by Linux distributions, ie, if we release binary-incompatible stuff too often, then most of these will be ignored by them - users will be frustrated when they see our website advertising release 12.0 and their distribution is shipping 10.0 with no way to upgrade to 12.0. Or, if distributions choose to try and follow us, users will be forced to continuously upgrade everything, which they'd hate. If X is too big, ie, if we release binary-incompatible stuff too rarely, then we're missing lots of upgrade opportunities, since each distribution basically gives us a binary-incompatible upgrade slot every X months, and if we don't use it, we lose it. If our Y is too small, then users will be forced to upgrade just to get bugfixes. If our Y is too long, we'll be doing more work than required. You'll notice that this line of reasoning pushes it towards the postgresql-release model, where the main problem is picking the right X and Y. I'd think that X=18 months and Y=5 years would be ideal, but the high Y may mean a lot of work to support old releases. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac
I started working through my list of TODOs for gnustep-make 2.6.0. * make 'fhs' the default filesystem layout (so, by default everything is installed in /usr/local/ using a Unix layout) (with the exception of apple-apple-apple because there people are using gnustep-make to compile Apple stuff, they're not really installing GNUstep) I have done this. * add help for how to use each filesystem layout (printed at the end of configure) I still need to do this. * if installing into /usr/local/, install GNUstep.conf into /usr/local/etc/GNUstep/GNUstep.conf instead of /etc/GNUstep/GNUstep.conf I have done this. * add a --remember-prefix-and-layout and --forget-prefix-and-layout options to configure (or similar) that will enable remembering the prefix and layout across configure invocations. This will be disabled by default as it would confuse new users (and we're picking all the default options to be best for new users). I can implement this, but I won't use it myself - is it something that other people genuinely need or want ? If it helps, I'll do it. * update all the documentation everywhere to discuss the 'fhs' layout ... inside and outside of gnustep-make This will take a while! Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: GNUstep Make not adding -fblocks
If you can provide the configure check, we can add it to gnustep-make's configure. Making it general, so that it may one day work with other compilers too, would be appreciated. It should all be fairly easy, but if you provide me with the appropriate configure check, I can do the gnustep-make tweaking. It would be good to do this before the new release of gnustep-make, so that it becomes part of it. :-) Thanks -Original Message- From: David Chisnall thera...@theravensnest.org Sent: Tuesday, 15 February, 2011 13:03 To: GNUstep Developer gnustep-dev@gnu.org Subject: GNUstep Make not adding -fblocks I've just noticed this, since I usually add the flag explicitly: GNUstep make is not adding -fblocks to OBJCFLAGS even when configured with clang and libobjc2 , which means that we are getting the ugly GCC-compatible-work-around code in NSRegularExpression.m, instead of the simple code that uses blocks, and people using blocks in their code are going to get a compiler error instead of having it work as they would expect. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep Make not adding -fblocks
I am no good at autoconf, but as a simple test, you can try this file: [...] Thanks Did you take a look at the exception test I sent you a mail about? It seems that the configure script is testing whether exceptions work, then deciding that, even though they do, it won't let you use them because it doesn't like the version of GCC that you have. Ah. We can fix that. I haven't seen the email though. Can you resend it (assuming it had more details) ? :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r31804 - /libs/base/trunk/Headers/Foundation/NSBundle.h
Support for attributes of Objective-C methods was added in GCC 4.6.0 (not released yet). Older GCCs do not recognize them and will throw a parse error whenever they encounter them. :-( So, it's not just a matter of that specific attribute not being recognized (that would normally generate a warning which you can turn off with a command-line flag); it's *all* attributes that don't work with GCC 4.5.0, as the parser doesn't recognize them at all. Thanks On 31 Dec 2010, at 16:52, Fred Kiefer wrote: Am 31.12.2010 15:03, schrieb David Chisnall: Author: theraven Date: Fri Dec 31 15:03:45 2010 New Revision: 31804 URL: http://svn.gna.org/viewcvs/gnustep?rev=31804view=rev Log: Add __attribute__ ((format_arg)) to [NSBundle - localizedStringForKey:value:table:]. This informs the compiler that the output can be used anywhere that the first argument can be used, and should silence all of the non-constant format string warnings that we get anywhere that _(@foo) or similar is used. Modified: libs/base/trunk/Headers/Foundation/NSBundle.h This change breaks compilation of base for me: In file included from GSXML.m:57:0: ../../Headers/Foundation/NSBundle.h:307:38: error: expected ‘;’ before ‘__attribute__’ make[4]: *** [obj/Additions.obj/GSXML.m.o] Fehler 1 make[4]: *** Warte auf noch nicht beendete Prozesse... make[3]: *** [internal-subproject-all_] Fehler 2 make[2]: *** [Additions.all.subproject.variables] Fehler 2 make[1]: *** [internal-all] Fehler 2 make: *** [internal-all] Fehler 2 I am using gcc version 4.5.0 and I am not sure whether there is just another compiler flag missing or whether this attribute isn't supported for Objective-C. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem with GUI
This was a change that accidentally slipped into David's bigger ICU change. And I could convince David to revert that part. (Not visible in the ChangeLog as David cannot be bothered by this old fashioned concept) Just do an SVN update of base and recompile. Then everything should be fine again. And if you have some extra time, send a mail to David explaining the benefits of ChangeLog entries :-) Regardless of whether they are good or bad, writing ChangeLog entries is a standard we are following for development. I look at the ChangeLog in each project in core/ and expect to find all the changes documented there, because that's what is the agreed standard. We can't have one person who actively commits non-compliant changes, as that disrupts the standards of the entire project. So, what can we do to make this disruptive behaviour stop ? It's exasperating. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem with GUI
So, what can we do to make this disruptive behaviour stop ? It's exasperating. Having briefly looked at David's latest changes, it's worse than just missing ChangeLog entries: * FSF/LGPL copyright headers are missing in new files. I even wonder if the copyright was assigned to the FSF or not, and obviously if the files are LGPL like the rest (this is critically important) * the indentation follows a different standard (which means that Richard will have to waste time reindenting the new file to be the same as everything else) * the headers lack the usual #include guards that allow them to work no matter if #import or #include is used (if we decide we don't want the #include guards, we should remove them everywhere, not just in one file, and it's a separate change that needs a separate discussion) Do we need a code review step where every change is reviewed by Richard before being applied to gnustep-base ? He can make sure that our coding standards are followed. But it seems a bit of an annoyance for our normal, regular contributors who do follow the coding standards. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem with GUI
So, what can we do to make this disruptive behaviour stop ? It's exasperating. Two options 1) Someone who cares about ChangeLogs can ... 2) Someone who cares about ChangeLogs can ... It's not about caring about ChangeLogs - it's about coding standards. If every contributor who doesn't like a specific part of the GNUstep coding standards was to just ignore them and do whatever they like (in the way that you are behaving), the project would be a huge, unmaintainable mess. If you want to take part in a larger project with many other different developers, you have to accept that such large projects have well-defined and well-documented standards that your submissions have to comply with. In your own personal pet project you can do anything you want; but when you take part in a project that is shared with hundreds of other developers and an unspecified (not small) number of users, you have to realize that there are other people - other than you - who are working on the project or using it, have different opinions on just about anything, and that the only way to get some consistency and quality in the code base is that everyone follows an agreed set of standards. That may mean doing things you wouldn't normally do, such as using a different coding style or writing ChangeLog entries or other things that are required as standard for contributions to the project. We can still have discussions and flamewars about whether ChangeLog entries are good or bad; but the fact is that all contributions to GNUstep, at this point in time, are required to include GNU-style ChangeLog entries. If you need clarification on what that means, you can refer to the GNUstep coding standards: http://www.gnustep.org/resources/documentation/Developer/CodingStandards/coding-standards.html As an experienced developer, I would expect that you would have no troubles doing the small adapations required to comply with the coding standards of each project that you contribute to - and that includes GNUstep. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Foundation.h vs. Foundation.h.install (Was: Problem with GUI)
The only issue is with headers that are removed from the source tree without updating Foundation.h, since the old header still may be present in the installed location (I don't know whether gnustep-make prunes the header directories upon make install. Nicola?) No, it doesn't prune existing headers from the header directories. That is an interesting idea though. Hmmm. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r31629 - in /libs/back/trunk: ./ Source/cairo/ Source/gsc/ Source/win32/ Source/winlib/ Source/x11/
On 20 Nov 2010, at 12:44, David Chisnall wrote: objc_malloc() and friends are GCC-runtime specific. They are not supported by other runtimes. If there is a reason for avoiding malloc(), using either NSZoneMalloc() or NSAllocateCollectable() should be the preferred indirection. Using malloc() is usually wrong as it can't work with garbage collection. ;-) objc_malloc() is traditionally used to work with the GNU runtime and the boehm garbage collector. I assume NSAllocateCollectable() could be a reasonable replacement (and gnustep-base will basically direct it to objc_malloc() if using the GNU runtime, and to something else with other runtimes). Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r31629 - in /libs/back/trunk: ./ Source/cairo/ Source/gsc/ Source/win32/ Source/winlib/ Source/x11/
objc_malloc() and friends are GCC-runtime specific. They are not supported by other runtimes. If there is a reason for avoiding malloc(), using either NSZoneMalloc() or NSAllocateCollectable() should be the preferred indirection. Using malloc() is usually wrong as it can't work with garbage collection. ;-) I'd replace 'usually' with 'sometimes' there. malloc() is absolutely fine (and should be preferred) as long as it is not used to store object pointers and it is matched with free() in - finalize. I'd also add that it CAN be used with object pointers as long as CFRetain() is called on them (rather than -retain) in Apple- land, so we should support this in GNUstep. Of course, if you're storing object pointers then NSMutableArray is probably a better bet. Using objc_malloc() for something that is stored in an ivar and contains non-object types is almost always wrong - you're burdening the GC for no benefit. Yes - it could be inefficient - every case need to be examined and understood :-) But if there is any doubt, using objc_malloc() is certainly safer. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r31629 - in /libs/back/trunk: ./ Source/cairo/ Source/gsc/ Source/win32/ Source/winlib/ Source/x11/
I'd replace 'usually' with 'sometimes' there. malloc() is absolutely fine (and should be preferred) as long as it is not used to store object pointers and it is matched with free() in - finalize. I'd also add that it CAN be used with object pointers as long as CFRetain() is called on them (rather than -retain) in Apple- land, so we should support this in GNUstep. Of course, if you're storing object pointers then NSMutableArray is probably a better bet. Using objc_malloc() for something that is stored in an ivar and contains non-object types is almost always wrong - you're burdening the GC for no benefit. Actually, I'm not entirely sure; it makes some sense to use malloc() for memory which is allocated and never released (and never references any garbage-collected memory); but for everything else, the boehm garbage collector is not limited to ObjC objects; objc_malloc() works with normal C memory allocations too - the memory is automatically garbage collected as required. :-) If boehm garbage collection is being used, I can't see a particular reason to manage C memory manually using malloc() and free(); using objc_malloc() and objc_free() (btw, objc_free() is an empty operation in that case) provides garbage collection for C memory too, and makes sure that you don't crash because you forget that you have a reference to an garbage-collected Objective-C object in your C memory. So, I guess the traditional recommendation of always using objc_malloc() and objc_free() instead of malloc() and free() actually makes sense. Unfortunately, Objective-C garbage collection as implemented by Apple is rather different. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r31629 - in /libs/back/trunk: ./ Source/cairo/ Source/gsc/ Source/win32/ Source/winlib/ Source/x11/
Hey, I can revert the change if needed, sorry if it was premature. I made the change based on David marking the objc_malloc and related functions as deprecated in libobjc2 They are not deprecated in the GNU Objective-C runtime. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changing gui-AppKit, base-Foundation... etc...
It's not about buzzword or any b.s. like that. What it's about is making it easy for developers who don't have any experience with GNUstep so that this project can get a much needed boost. Do I have any evidence that we will get that. No... I don't, but I'm trying everything I can in order to make this project a little bit more appealing to people other than the small group we have here. I'm tired of GNUstep being, more or less, a boutique project for people who get it. It's time to make it easier, really. Conduct an experiment for yourself: Pretend you're a novice user who knows nothing about GNUstep and try to get things working relying on the information you have at your disposal on the website. Better yet, get a friend who is a developer, but not familiar with GNUstep to set it up. That should illustrate to you just how daunting a task we have set before our audience. Yes, I agree with this. The website is key. I agree work on the website would be extremely helpful and good, and that we should study and improve the path that a new user or developer is expected to follow. Make that experience easy and rewarding. Get them to some juicy, exciting bits quickly :-) (By the way, we should all try to be very helpful and polite to new users or developers when they ask questions or talk to us - that really makes a difference) But I'm not sure changing the names of gnustep-base or gnustep-gui in subversion would help much with it. It seems to be a minor detail. The Apple user/ developer looking for a free Cocoa clone and with a 5 minute attention timespan shouldn't even need to know what gnustep-base or gnustep-gui are to get started; he should be able to get his GNUstep package (appropriate for his OS) that includes all that is needed, and we want him to be up and running playing with Gorm (and Project Center ?) within minutes, bypassing everything else ... :-) So maybe the root problem is not with the name of gnustep-base and gnustep-gui, the root problem is that new users have to deal directly with gnustep-base and gnustep- gui instead of being able to get all their GNUstep development tools ready for actions without being bogged down into details ? Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac
by learning more about the FHS and GNUstep layout differencies, I learned that even for the GNUstep layout we create links to the binary executables of each applications inside the Tools dir. I think this is dirty and it leaves garbage around. Application should be started using openapp / gopen. Or using NSWorkspace. Well, it means people can start 'Gorm' by simply typing 'Gorm' at the command-line. :-) Also, the application starts faster that way, without the overhead of 'openapp'. You can still use 'openapp Gorm.app' if you want, but there is no particular reason to (and typing 'Gorm' will start the application faster!). If it's really important for you, we could add an option to configure in gnustep-make to disable these symlinks. But I'm not sure what we gain. The symlinks take up very little space on disk. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Suggestion... renaming base, gui to Foundation and AppKit
but other projects which have attempted to implement Cocoa have used the names Foundation and AppKit without any problems. That is not a reason to feel safe. I agree. And I personally don't like the idea of changing the names to be identical to the Apple names. We need our own identity. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac
I like the idea that an application can be moved, around, installed by untarring it, deleting by trashing it. Like you do in OpenStep or Cocoa. You can still do that. :-) The symlinks are only used for things that are installed using 'make install'. These things are uninstalled using 'make uninstall', which removes the symlinks. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac
* if installing into /usr/local/, install GNUstep.conf into /usr/local/etc/GNUstep/GNUstep.conf instead of /etc/GNUstep/GNUstep.conf Why only in this case? We could make it the default on all systems (but my OpenSuse 11.3 doesn't have this directory by default) or find a better conditions for this. Well, if you install into /usr (as we do now), the config file should go into /etc/GNUstep/GNUstep.conf, where it is now (as prescribed by the fhs and by normal Unix conventions). :-) It only needs to go into /usr/local/ if you are installing everything into /usr/local/ ;-) * add a --remember-prefix-and-layout and --forget-prefix-and-layout options to configure (or similar) that will enable remembering the prefix and layout across configure invocations. This will be disabled by default as it would confuse new users (and we're picking all the default options to be best for new users). This is a very important part of the setup. It is not just that I am to lazy type the file system layout selection each time I install GNUstep make, which is at least after every change to that package. Yes. I think the --remember-prefix-and-layout option would be used by people like you and me who rebuild gnustep a few times per day and would otherwise have to type --with-layout=gnustep every time they configure gnustep-make ;-) But I wouldn't make it the default. The reason is that we are making changes to make GNUstep more standard for the average Unix user. And standard configure scripts don't magically pull out installation directories by looking at a similar package already installed somewhere on the machine. That would be confusing for the average new Unix user who expects configure to obey the flags that it is passed and nothing else. No matter what they are doing, they would not expect that behaviour, and would be very annoyed when they discover that configure is behaving in some different, unusual and surprising way (no matter how clever it is). We can have a configure option to turn special behaviour on for our own pleasure, but I wouldn't push it onto the average user. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac
Summarizing the discussion, the changes that we want to make to gnustep-make are: * make 'fhs' the default filesystem layout (so, by default everything is installed in /usr/local/ using a Unix layout) (with the exception of apple-apple-apple because there people are using gnustep-make to compile Apple stuff, they're not really installing GNUstep) * add help for how to use each filesystem layout (printed at the end of configure) * if installing into /usr/local/, install GNUstep.conf into /usr/local/etc/GNUstep/GNUstep.conf instead of /etc/GNUstep/GNUstep.conf * add a --remember-prefix-and-layout and --forget-prefix-and-layout options to configure (or similar) that will enable remembering the prefix and layout across configure invocations. This will be disabled by default as it would confuse new users (and we're picking all the default options to be best for new users). * update all the documentation everywhere to discuss the 'fhs' layout ... inside and outside of gnustep-make * (potentially, this is a new idea) rename 'fhs' to 'unix' ? Comments/suggestions welcome ... Is there anything I forgot ? Has anyone got a strong opinion that something in the above list is wrong ? ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: Native ObjC exceptions configure test broken with libobjc2
I'd suggest that libobjc2 could include a minimal Object implementation.
Having Object is handy to perform simple configure tests and both the Apple
and GNU runtime include a minimal implementation for that reason ... it would
make sense for libobjc2 to do so too ;-)
Else, if you have a patch to get the test to work with libobjc2 as it is,
I'd happily accept it.
Thanks
-Original Message-
From: Quentin Mathé qma...@gmail.com
Sent: Saturday, 18 September, 2010 19:24
To: GNUstep Developer gnustep-dev@gnu.org
Subject: Native ObjC exceptions configure test broken with libobjc2
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Hi,
Native ObjC exceptions support was recently turned on by default in
gnustep-make. However this doesn't work with libobjc2, at least the
configure test. objc/objc.h is missing to eliminate the 'nil' warning and
Object in libobjc2 has an empty implementation. So either Object needs a
more complete implementation or the exception test should be written in
another way.
I'm using libobjc2 r31373 (today) and gnustep-make r31362. Here is the
config.log output:
configure:6413: checking for the GCC version
configure:6440: result: version: 4.4
configure:6461: checking whether we should use native ObjC exceptions
configure:6514: gcc -o conftest -g -O2 -x objective-c -I.
-I/Local/Library/Headers -L/Local/Library/Librari
es -fgnu-runtime -DGNU_RUNTIME -fexceptions -fobjc-exceptions conftest.c
-lobjc -shared-libgcc -fexceptions
5
conftest.c: In function 'main':
conftest.c:7: error: 'nil' undeclared (first use in this function)
conftest.c:7: error: (Each undeclared identifier is reported only once
conftest.c:7: error: for each function it appears in.)
conftest.c:10: warning: 'Object' may not respond to '+new'
conftest.c:10: warning: (Messages without a matching method signature
conftest.c:10: warning: will be assumed to return 'id' and accept
conftest.c:10: warning: '...' as arguments.)
configure:6518: $? = 1
configure: program exited with status 1
configure: failed program was:
|
| #include stdlib.h
| #include objc/Object.h
|
| int main(int argc, char **argv)
| {
| Object *o=nil;
| @try
| {
| o=[Object new];
| @throw o;
| }
| @catch (id foo)
| {
| if (o!=foo)
| return 1;
| }
| return 0;
| }
|
configure:6545: result: no: native exceptions are not supported by the
compiler
Here is the result of gcc -v:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.4.3-4ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin
--enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i486
--with-tune=generic --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
Quentin.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Native ObjC exceptions configure test broken with libobjc2
Actually, this test will fail with Apple's Modern Runtime too - Object no longer implements +new. If you define __OBJC2__ (which recent Apple compilers do, you only get these two methods on Object: +class; -(BOOL) isEqual:anObject; +new is no longer allowed, so there is no defined way of creating Object instances. Ok, that is a good point. I don't even understand why they kept the Object class then! ;-) I've already fixed most of the configure scripts to define their own root class, if they need it. It should be trivial to copy one of those across into this test. But I don't think anyone can find this solution satisfactory ... surely it doesn't make sense to copypaste the same code to create a root class across every single testcase ? It would be much more logical for the runtime to provide one working class that you can use to run trivial tests without having to reimplement your root class in every single testcase ? I thought that was the point of the Object class (nowadays). A single, minimal working class that you can use to write testcases and configure checks. :-) It makes sense to slim down the Object class in the GNU runtime for forthcoming releases, but to keep it usable for testcases and configure checks. So, we'd probably keep a few more methods than Apple does (I haven't discussed this with Andrew Pinski yet though so it's just my own ideas). ;-) I guess Apple doesn't care about testcases since they assume you're using Apple and there is nothing to test. ;-) So, maybe a better solution would be to assume that (eg) @try/@throw/@catch works on Apple/NeXT runtime (ie, NeXT runtime AND __OBJC2__), and have a normal test using Object elsewhere ? Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac
I don't see a conflict between the two. LanguageKit loads frameworks using NSBundle so that you can distribute a portable .app bundle with the source code in the bundle and a plist describing the frameworks that it needs. It loads the frameworks, JIT-compiles the code, and then runs the app. Apparently this doesn't work with the FHS layout, so Étoilé doesn't support systems that use the FHS layout. I'm not sure why this wouldn't work with the FHS layout if LanguageKit only use the public NSBundle API. ;-) The public NSBundle API works fine with FHS. Usually things stop working when you try to locate things manually on disk instead of using the public API. If you have a pointer to the snippet of code that doesn't work, I can have a look at some point and see if I can suggest something. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac
I agree with this statement. It's a fact that GNUstep doesn't play well with the FHS used by, pretty much, every single *nix variant. FHS is a Linux 'standard', not a *NIX standard. Most *NIX variants use something vaguely similar, but none use FHS. For example, on *BSD, GNUstep's decision to put GNUstep.conf in /etc/GNUstep/ is incorrect - this location should only be used for stuff that is in the base system. Third-party configuration stuff should go in /usr/ local/etc. Actually, the FHS requires the same ;-) GNUstep config file for a local installation (/usr/local) should go into /usr/local/etc/GNUstep/GNUstep.conf, while for a base system installation (/usr) should go into /etc/ GNUstep/GNUstep.conf. I guess on that side gnustep-make is currently not totally compliant with the FHS (nor compliant with Unix standard practice). We can fix it though. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac
I thought about this last night ... IMO our default (of course we need to be able to choose other alternatives easily, but I think you have already make gnustep-make support that) should be to install things in native locations so they work with no further effort. As Truls Becken pointed out yesterday, that might mean having gnustep-make run ldconfig (or equivalent) when installing libraries and frameworks as well as just putting things in the 'right' place. Well, if /usr/local/lib is not in ld.so.conf (it isn't by default on most Linux distributions), running ldconfig won't help. So, we'd also have to hack /etc/ld.so.conf upon installation to add /usr/local/lib/ (or equivalent action on other unices) ... that is getting very system- specific and installation-unfriendly - we don't really want to do that. I have been thinking about this, and I am now wondering if --with- layout=gnustep isn't actually still the simpler solution for new users if we print a *huge* warning at the end of configure (and make install) about sourcing GNUstep.sh. ;-) Otherwise, we may now have a new wave of problems from new users, who don't have /usr/local/bin in their PATH and don't know how to set their PATH, or who don't have /usr/local/lib in the LD_LIBRARY_PATH or /etc/ld.so.conf (or whatever it is on their different Unix system) and don't know how to change them etc. :-( We'll end up telling them to run /usr/local/GNUstep/System/Library/ Makefiles/GNUstep.sh as that's the easiest way of doing all of the above in a single command, but then there is no longer any advantage compared to the GNUstep layout ;-) The 'fhs' layout has the advantage that is more familiar to new Unix users. That is great. But in terms of setting up the environment, just sourcing GNUstep.sh would remain the easiest way for them to do that. So, we shouldn't be switching to 'fhs' hoping that that will allow new users to run GNUstep stuff without sourcing GNUstep.sh ... and the problem of switching to 'fhs' is that the GNUstep.sh file would be in a different location so millions of web pages and web posts telling people to source /usr/ GNUstep/Library/Makefiles/GNUstep.sh would no longer work. ;-) I'm personally no longer that convinced about switching to 'fhs' as default. But I'm happy to be convinced otherwise. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac
not to mention that this is a problem shared by ALL gnu software (on systems that behave like you describe), and they all have a common solution, where the gnustep solution is highly gnustep specific. That is a good point. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac
The public NSBundle API works fine with FHS. Usually things stop working when you try to locate things manually on disk instead of using the public API. The problem seems to be that frameworks are no longer found in the frameworks directory, and are no longer bundles, meaning that you have nothing meaningful to pass to NSBundle, so you can't load frameworks using NSBundle. If you can't load frameworks using NSBundle, then everything subsequently breaks because the JIT-compiled code doesn't find the classes that it requires. Nope - it should all work. There is no difference between the layouts except for the name of the directories. Frameworks are, and behave, identically no matter what the layout is. If it doesn't work, it sounds like the NSBundle API is not being used correctly, or maybe there is a bug of some sort in NSBundle. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac
Well, if /usr/local/lib is not in ld.so.conf (it isn't by default on most Linux distributions), running ldconfig won't help. Really? I would suggest that distributions which don't have /usr/local/lib in ld.so.conf do not use/conform to the FHS ... Eg, Linux RedHat/CentOS does not have /usr/local/lib in ld.so.conf. Yet that is where you are expected to install software from source. After you install the software from source, you have to manually add that line to ld.so.conf, then run ldconfig. ;-) I'll accept Matt's point though that this problem (having to make sure libraries in /usr/local/lib are found by the linker) is common with almost every other piece of software on the planet and so the average Unix user already knows how to fix it. Instead, in the case of the GNUstep layout, the solution (sourcing GNUstep.sh) is GNUstep-specific. :-) (still, sourcing GNUstep.sh does seem simpler to me) Remember, I'm not advocating switching to FHS as the default ... I'm advocating switching to using the native layout as our default. For systems where FHS is not native, we would need to add another layout file. If this is for new users, having a common layout used almost everywhere may help them as it's easier to find information. So I'm not too keen to push this 'native' layout idea. Btw we're saying FHS but GNUstep really just does the usual Unix thing and installs binaries in xxx/bin, libraries in xxx/lib, includes in xxx/include and stuff that doesn't fit in the above dirs in xxx/share. We call it FHS mostly to appeal to the Linux distributions, but I'd expect it to be about the same as what every Unix does ... there isn't much that is FHS-specific at all. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac
If you configure GNUstep using the FHS layout on *BSD, it puts stuff in completely the wrong place (it puts GNUstep.conf in the wrong place with any configuration, unfortunately). For example ? (ignoring GNUstep.conf which we agree it's wrong on FHS as well) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac
If you configure GNUstep using the FHS layout on *BSD, it puts
stuff in completely the wrong place (it puts GNUstep.conf in the
wrong place with any configuration, unfortunately).
For example ? (ignoring GNUstep.conf which we agree it's wrong on
FHS as well)
Unless you explicitly set the prefix, it doesn't put things under /
usr/local (or didn't, last time I accidentally used FHS mode), it
put things in /usr, which is reserved for stuff in the base system
that is not required to boot single-user mode. I didn't look much
beyond that.
That is no different than what FHS/Linux expect. And it should work ;-)
--with-layout=fhs (the default that we are probably switching to)
should use /usr/local/
--with-layout-fhs-system (reserved for distribution packagers) should
use /usr/
Of course, if it didn't work for you it sounds like there may be a bug
- it's worth testing all of this again if it's going to be the
default! ;-)
By the way, there is a relatively simple way of using the GNUstep
layout in FHS-compliant mode: install in /opt/GNUstep. FHS
explicitly allows installing add-on software in /opt/{package
name}/. Of course, many FHS-compliant Linux distros don't allocated
adequate space for /opt, or don't create it at all, so this doesn't
actually work...
Yep
Thanks
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac
It's worth noting that the last person we had on the list with this problem was using Windows. Changing the default FS layout in -make does absolutely nothing to help Windows users. Yes Most new users who install GNUstep and can't do anything with it seem to be using Debian/Ubuntu packages or Windows packages. There are also some who install from source though. The highest failure rate seems to be with new users who install GNUstep from source on Windows. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_FILESYSTEM_LAYOUT_FILE Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac
Maybe the right thing to do is to do something similar to the /etc/GNUstep/installation-domains.conf. Ie, we could have gnustep-make's configure load a new file, /etc/GNUstep/default-filesystem-layout.conf but only if it exists (it has to be created manually by an advanced user). That file could contain a default layout/prefix which would be used if none are specified on the configure command-line. Yes, I had a short discussion with Richard online. I guess the main change that Richard wanted to do is change the default filesystem layout to be 'fhs'. Many people in this list (including me) actually use 'gnustep' as their default layout. To help them after the change, the idea was that you could put a file somewhere (either directly in core/make/preferences.conf, or in /etc/GNUstep/preferences.conf) with two (optional) lines GNUSTEP_PREFERENCES_FILESYSTEM_LAYOUT=gnustep GNUSTEP_PREFERENCES_PREFIX=/ ./configure would read that file and use the values in there if nothing else is specified on the ./configure command-line. So, if you need 'gnustep' as the default layout, and configure and reconfigure gnustep-make very often, you could create that file once and it would be reused forever. Alternatively, people can always use the --enable-import-config-file option (already existing) but you still have to type that option every time you configure gnustep-make. (making it the default is impractical because it means that the results of configure would depend on the results of previous configures, which would cause total confusion for new users). I wonder if autoconf has a way to specify configuration options in a local file ? Thanks PS: An alternative would be to have configure print warnings if it detects that the new configuration is different from the one in /etc/GNUstep/GNUstep.conf. This is harder to implement, and has the disadvantage that it only warns you, but you still have to type in your ./configure arguments ;-) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_FILESYSTEM_LAYOUT_FILE Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac
NB. The net result is that temporarily you need to specify --with- layout=gnustep to get the gnustep layout ... until we can work out a good mechanism for setting a preference for the layout to use. Shouldn't gnustep-make reuse the existing layout when there is already a GNUstep install? Not by default as it would be too confusing for new users. Maybe we could add a switch to gnustep-make to tell it to save the prefix/layout for next time. Something like ./configure --prefix=/ --enable-debug-by-default --with-layout=gnustep --enable-remember-layout that would store the prefix/layout in some config file in /etc/ GNUstep/ and next time your run configure it would then use it. Thanks If I do ./configure --prefix=/ --enable-debug-by-default --with- layout=gnustep make sudo -E make install then ./configure --prefix=/ --enable-debug-by-default make sudo -E make install The second time, gnustep-make ignores my previous install and just reverts to the fhs layout. I think it shouldn't switch the layout unless it's explicitly requested, and each time the layout is changed, a warning should be displayed at the end of the configuration to make things truly clear. Otherwise you can get weird results where some programs stop to compile because gnustep-make still picks the old headers of the previous GNUstep install. This happened to me when I update my working copy, because I usually don't source GNUstep.sh when I reinstall gnustep-make unless I make a new install in another location. Cheers, Quentin. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Interesting discussion on gcc about objc
GNU ObjC has so few users that it seems hardly worth the effort to upgrade the GNU ObjC front end to ObjC 2.0. And there are other issues: Translation: The GNU project doesn't care about GNUstep. The GNU project is a lot of people. One person on the GCC mailing list wasn't interested in Objective-C support. Many others were and are. I am. ;-) We already have an MIT-licensed runtime in svn that implements the ObjC 2 runtime features and works with GNUstep, so this isn't a problem. libobjc2 is a derivative work of libobjc which is an FSF GNU GPL v2+ piece of work, so I'm not sure why you say it's a MIT-licensed runtime. If you wanted a MIT-licensed runtime you should have started from scratch instead of scavenging the old FSF GNU runtime. I'm actually quite confused as to why you worked on libobjc2 now: I thought you were working on libobjc because you meant to contribute changes back to the official FSF GNU runtime, but you never have, and now claim your libobjc derivative is independent and no longer GNU GPL v2+, which I'm confused about (I guess as I'm not a lawyer) but puts your runtime (in my view) in a legal limbo to say the least. I'm not a lawyer though. Anyway, I have nothing against libobjc2 per se (except that you need to sort out your license) as I think GNUstep should support as many free Objective-C compilers and runtimes as possible. I think we all hope that there are, and will be, may free Objective-C compilers and runtimes to choose from. :-) I personally do want to use the FSF GCC and runtime library, but that's because one of the very few organizations I trust is the FSF. I don't trust Apple. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Interesting discussion on gcc about objc
I'm not condemning GCC for its stance. C and C++ are definitely much more popular languages than Objective-C, and I wouldn't blame them if they decided to completely drop Objective-C support. No one's really worked on it for around 7 years and the code that they inherited from NeXT is basically unmaintainable. You're spreading FUD and misinformation. Apple itself maintained the GCC Objective-C code until a few years ago and the code base is actually OK. It's changed dramatically for the better since I first worked on it 10 years ago. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Interesting discussion on gcc about objc
Not to spark a flame war here, but I've had some serious questions in my mind as to the GCC project's ability or willingness to help since the project seems entirely focused on endlessly improving the C, C++ and Fortran front-ends and doesn't work on ObjC at all. I think GCC has been really keen on supporting ObjC and ObjC++. They have entire testsuites that test the languages, and make no changes that ever break it. It's remarkable how hard they support it given that none of them uses it. ;-) What we need to realize, in my view, is that the GNU Objective-C Compiler and the GNU Objective-C Runtime can only be maintained by the GNU Objective-C People. And the GNU Objective-C People is mostly us (GNUstep), the people on this mailing list! ;-) As gnustep-make is mostly complete and feature-full (and so I can maintain it with low overhead), I have personally decided to give part of my free-software-hacking attention (for the foreseeable future) to Objective-C support in the FSF GCC and in the FSF GNU Objective-C runtime library. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Interesting discussion on gcc about objc
They have entire testsuites that test the languages, and make no changes that ever break it. It's remarkable how hard they support it given that none of them uses it. ;-) I'd like to see when that code was written Ehm, actually I wrote the original GCC Objective-C testsuite myself. ;-) Of course, over the years Apple added most of the interesting tests as they were working on weird cases and bugs. What we need to realize, in my view, is that the GNU Objective-C Compiler and the GNU Objective-C Runtime can only be maintained by the GNU Objective-C People. And the GNU Objective-C People is mostly us (GNUstep), the people on this mailing list! ;-) Exactly how long do you think it would take for us to have a working ObjC2.0 Implementation in GCC? I'm willing to help, but, honestly, GNUstep has so many other issues that need to be dealt with using LLVM instead of GCC to me seems a viable option since it removes the burden of maintaining the compiler from us. You can use LLVM. Nobody prevents you from doing that. ;-) If there is a need to have ObjC 2.0 right now, use LLVM. Let's improve support for it. :-) But you can't remove support for GCC from GNUstep. GCC is the default compiler on enterprise Linux distributions. Many of the key users of GNUstep are companies running enterprise Linux servers and they would be extremely disappointed if GNUstep stopped working out-of-the-box on standard enterprise Linux distributions. I think LLVM is great in that there will be a new Objective-C compiler to pick from. Until recently, GCC had been the only choice. It's great to have a choice. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Interesting discussion on gcc about objc
I'm not a lawyer. And I'm not the copyright holder of the original work (libobjc) that libobjc2 is derived from. The FSF holds the original copyright. So there is nothing to discuss with me. You should call the FSF and ask. Thanks -Original Message- From: Gregory Casamento greg.casame...@gmail.com Sent: Monday, 13 September, 2010 21:23 To: Nicola Pero nicola.p...@meta-innovation.com Cc: David Chisnall thera...@sucs.org, gnustep-dev@gnu.org Subject: Re: Interesting discussion on gcc about objc Nicola, I believe what you're saying here about David's libobjc2 runtime is just as much FUD as what he said about GCC's ObjC. He should discuss this with you further, but I don't think we have a problem here. GC On Mon, Sep 13, 2010 at 2:44 PM, Nicola Pero nicola.p...@meta-innovation.com wrote: GNU ObjC has so few users that it seems hardly worth the effort to upgrade the GNU ObjC front end to ObjC 2.0. And there are other issues: Translation: The GNU project doesn't care about GNUstep. The GNU project is a lot of people. One person on the GCC mailing list wasn't interested in Objective-C support. Many others were and are. I am. ;-) We already have an MIT-licensed runtime in svn that implements the ObjC 2 runtime features and works with GNUstep, so this isn't a problem. libobjc2 is a derivative work of libobjc which is an FSF GNU GPL v2+ piece of work, so I'm not sure why you say it's a MIT-licensed runtime. If you wanted a MIT-licensed runtime you should have started from scratch instead of scavenging the old FSF GNU runtime. I'm actually quite confused as to why you worked on libobjc2 now: I thought you were working on libobjc because you meant to contribute changes back to the official FSF GNU runtime, but you never have, and now claim your libobjc derivative is independent and no longer GNU GPL v2+, which I'm confused about (I guess as I'm not a lawyer) but puts your runtime (in my view) in a legal limbo to say the least. I'm not a lawyer though. Anyway, I have nothing against libobjc2 per se (except that you need to sort out your license) as I think GNUstep should support as many free Objective-C compilers and runtimes as possible. I think we all hope that there are, and will be, may free Objective-C compilers and runtimes to choose from. :-) I personally do want to use the FSF GCC and runtime library, but that's because one of the very few organizations I trust is the FSF. I don't trust Apple. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Interesting discussion on gcc about objc
Nicola, I believe the fundamental mistake you're making here lays in the claim that it's derived in the first place As the person making the assertion that it is, you do, in fact, need to discuss this with David. David started with libobjc and made changes. For me that is the definition of a derived work. If you start from scratch (ie, no pre-existing codebase), that is the definition of a new work. But I'm not a lawyer, so I don't know. Certainly taking an official FSF GNU GPL codebase as the starting point for a MIT-license project is not exactly the smartest thing you can do in legal terms. The resulting legal minefield is not for me to sort out. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Interesting discussion on gcc about objc
Well, according to David, he started its new runtime from scratch. Quoting http://60gp.ovh.net/~dromasof/etoile/blog/ : This, and the difficulty in supporting Objective-C 2.0 on the GNU runtime caused me to write a new one from scratch. The first subversion logs for libobjc2 states: Added new runtime library, based on GCC 4.4 libobjc, libobjc_tr and Objective2.framework. You may also want to look at that revision, r28632, which shows that libobjc2 was initially the libobjc runtime with a few minor tweaks. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Interesting discussion on gcc about objc
The first subversion logs for libobjc2 states: Added new runtime library, based on GCC 4.4 libobjc, libobjc_tr and Objective2.framework. You may also want to look at that revision, r28632, which shows that libobjc2 was initially the libobjc runtime with a few minor tweaks. Before you reply, can I ask permission to get off the thread ;-) I don't want to spend time discussing this. You should discuss with David. I won't reply as I don't want to spend the next N days tied in a mailing list flamewar. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Interesting discussion on gcc about objc
If you're asking me I would say it's very unfair to make an assertion regarding someones work, then back out of/refuse to participate in the discussion which results. I have nothing more to contribute than what is in the following comments -- The first subversion logs for libobjc2 states: Added new runtime library, based on GCC 4.4 libobjc, libobjc_tr and Objective2.framework. You may also want to look at that revision, r28632, which shows that libobjc2 was initially the libobjc runtime with a few minor tweaks. What else do you want me to say or discuss ? I like David and his code, I just don't understand the license. All my doubts are summarized in the comments above. I'm not a lawyer, so I can't contribute any legal insight. I'm sure David will state his position. He'll probably say that he's replaced most libobjc code, so the current code is mostly his and he can pick the license he wants. I have no idea of the legal validity of that assertion. You should ask a lawyer. I'm not a lawyer so I'm not sure why you want me in this discussion. The FSF have lawyers, and GNUstep is an FSF project, so you could ask them. I'm not making any accusations as you called them. I'm not trying to diminuish the value of anyone's work. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac
Richard I don't think you are an idiot at all. But I suggest we briefly discuss major changes on the mailing list before we do them ;-) So, let's discuss :-) I generally agree with this change, but if we want to do this change we have to do lots of documentation updates. Otherwise we could have lots of users who install GNUstep, then try to do . /usr/GNUstep/System/Library/Makefiles/GNUstep.sh following documentation they read somewhere, that fails and they hit a wall. My favourite option is to have each filesystem layout file include a snippet of documentation that we print at the end of configure (or maybe at the end of 'make install' ?) So, you are a new user, and you type 'configure' in gnustep-make. The thing runs and you probably don't understand most of it. The last lines that 'configure' prints would be a few lines of help for the filesystem layout that you chose ... something like --- IMPORTANT: READ THE FOLLOWING IF YOU ARE A NEW USER --- To be able to use GNUstep in the way you have configured it, you must execute the following command in the shell: . /usr/GNUstep/System/Library/Makefiles/GNUstep.sh Add this line to your shell initialization scripts (eg, /etc/profile) to have it done automatically each time you login. --- We could have a similar message for the fhs layout. How does that sound ? Thanks -Original Message- From: Richard Frith-Macdonald r...@gnu.org Sent: Friday, 10 September, 2010 23:29 To: Nicola Pero nicola.p...@meta-innovation.com Cc: Fred Kiefer fredkie...@gmx.de, GNUstep Developer gnustep-dev@gnu.org Subject: Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac On 10 Sep 2010, at 21:02, Nicola Pero wrote: I think that patch should be reverted for the time being. Changing the default choices has a massive impact because most users never deviate from the default! ;-) Exactly why I did it ... after yet *ANOTHER* complaint from a user on the mailing list about being unable to use GNUstep because of the issue of the default installation not working. I know that all the user has to do is read the INSTALL document or any of the installation HOWTOs etc and source GNUstep.sh, but the fact is that most people just don't bother. IMO we need a system that just works. We can have a discussion about the patch, and I actually may be in favour of making the change to use the native filesystem as default, but it does require some discussion - and probably should be coordinated so that it happens in a release. ;-) I strongly disagree about leaving it until a release ... how can people try it out, decide what they think, offer changes etc if they never see it until it's officially released? The point about svn trunk is for people to try out new things. I don't really mind the change being reverted if you like (the main point being to get people to actually do something about the problem), but I think it might make more sense to revert to the old behavior *after* everyone has had a chance to consider the idea and let me know that I'm an idiot, rather than assuming I'm an idiot in advance. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac
I think that patch should be reverted for the time being. Changing the default choices has a massive impact because most users never deviate from the default! ;-) We can have a discussion about the patch, and I actually may be in favour of making the change to use the native filesystem as default, but it does require some discussion - and probably should be coordinated so that it happens in a release. ;-) Thanks -Original Message- From: Fred Kiefer fredkie...@gmx.de Sent: Friday, 10 September, 2010 21:40 To: Richard Frith-Macdonald r...@gnu.org Cc: GNUstep Developer gnustep-dev@gnu.org Subject: Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac Am 10.09.2010 18:10, schrieb Richard Frith-Macdonald: Author: rfm Date: Fri Sep 10 18:10:10 2010 New Revision: 31321 URL: http://svn.gna.org/viewcvs/gnustep?rev=31321view=rev Log: Change to more sane default filesystem layout Modified: tools/make/trunk/ChangeLog tools/make/trunk/GNUstep.conf.in tools/make/trunk/configure tools/make/trunk/configure.ac I just tried to compile GNUste make and am getting the following error: checking for GNUstep filesystem layout to use... Can not find ./FilesystemLayouts/native Please check your --with-layout=xxx argument and try again. make: *** [config.make] Fehler 1 Now this just looks like some missing file in this commit. But it also looks like the default file system layout was silently changed. I never used native and for the time being I don't intend to do so. Could you please provide the missing files and switch back the default file system layout to what it used to be? And if we really want to change it, we should at least discuss it on the mailing list in advance. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: native objc-exception detection
Thanks for this report ... please try again from trunk. Thanks On 6 Sep 2010, at 23:32, Riccardo Mottola wrote: Hi, when using latest make/base, when I configure make, I get: checking for the flag to link libobjc... -lobjc checking whether objc has thread support... yes: -pthread checking whether we should use native ObjC exceptions... yes checking whether we should use the nonfragile ABI... not requested by user checking for the GCC version... version: 4.2 but when I configure base, it says exceptions cannot be enabled: /var/tmp//ccWuEW6C.o(.text+0x12): In function `main': ./config/config.unexpected.m:6: undefined reference to `_objc_unexpected_exception' configure:10902: $? = 1 configure: program exited with status 1 configure: failed program was: | #include ./config/config.unexpected.m configure:10935: result: no configure:10941: error: Your objective-c runtime library does not appear to support any mechanism to set a handler for uncaught native exceptions. Please upgrade your runtime or re-install gnustep-make without native-objc-exceptions! something is inconsistent here? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: where did objc-gnu2next.h go?
If I remember correctly, this file was removed by David or Richard. (Most likely David as I could not find an entry in the ChangeLog file stating the removal :-) I thought writing a ChangeLog entry was still standard, required practice for the core libraries ... has this changed for gnustep-base ? I feel removing the requirement to write ChangeLog entries is a way to speed up development at the expense of quality and review - which is the exact opposite of what we should be trying to do with gnustep-base. In all cases, such a change should be discussed and agreed so that we all know what is expected - until now I was happily looking at the ChangeLog in gnustep-base and assuming it was a faithful description of the changes that had been done to gnustep-base ... without realizing some rogue committers were not writing ChangeLog entries at all! ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem running hello-objc-gnustep example in gettext
On 13 Aug 2010, at 02:50, asha murthy wrote: Hi Nicola, Thank you very much for your kind reply. defaults write NSGlobalDomain NSLanguages (Language) The above command works for me from command line! Now, I would like to use this command from my application *.m file. Is there any way to do this? Hi Asha I think the idea is that your application could run in different languages, and the user would select which languages (using 'defaults write ...', or using Preferences.app) he prefers before launching the application ;-) By the way, 'defaults write ... ' writes your preferences permanently to disk; you can reboot your computer and your preferred language will still be there - if you selected a language there (eg, French) all GNUstep applications should start up in French, and even if you log out or reboot, they will still come up in French :-) Anyway, you can still change the language in main.m if you have a reason to do so (I can't really think of a reason, but presumably you have one). You need to use NSUserDefaults to do the equivalent of setting NSLanguages = (French, Italian) (for example) from the shell (note that the value is an NSArray). Check the NSUserDefaults documentation for an explanation of the API. :-) Thanks PS: You can also specify NSLanguages on the command line (for a specific application) if you want, as in openapp MyApp.app -NSLanguages '(Italian, French)' (warning: I haven't tested this command, it may contain a typo) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Testing for drawing fixes r30523
Can you give us more information on the issues you had ? I updated the README.MinGW doc a couple of months ago or so. If it stopped working (because of changes in MinGW or somewhere else) I'd like to know, so I can update it again :-) Sorry for the late reply. Here are the issues I encountered with MinGW/MSys 1.0.11 (including GCC 3.4.5): - the libxml 2.7.6 source didn't compile with GCC. I worked around it by installing the binary available at http://www.zlatkovic.com/libxml.en.html - gnustep-make didn't add -lpthread whereas I configured it with -- thread-lib=posix. I had to add -lpthread to objc_threaded by editing /usr/local/share/GNUstep/Makefiles/config.make directly - make install doesn't work on Vista because of permission issues. I solved the issue as I explained previously here: http://lists.gnu.org/archive/html/gnustep-dev/2010-06/msg00055.html - gnustep-base didn't compile. GCC was unable to find the objc headers although they were properly installed in /usr/local/include and GCC --print-search-dirs was reporting the right header search paths Thanks Quentin, I guess I'll have to try again :-) I don't have Windows Vista though, but I added a mention of the installation permission problem in the README.MinGW. Did you use the latest README.MinGW from core/make/Documentation ? I'm asking because I was checking, and in the README.MinGW mentions to configure gnustep-make using ./configure --with-layout=fhs --with-thread-lib=-lpthread but you mention --with-thread-lib=posix - maybe that was a typo ? Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Minimalist GNUstep possible?
Hi, So you see no legal impediements in proceeding? No patents, no royalties, no rules in any agreement? Would you say it is like coming up with a Java implementation 10 - 12 years ago? Did the rules for the Java technology, the JDK, disallow reverse-engineering? If they did, we are OK, and there are several competing “Java” implementations. Of course, we need only the public APIs specs for our work. But these may be governed by their web site’s terms of use, no. Then is it sufficient to rename the classes with a common project-related prefix? What bout the SDK rules against reverse-engineering? Do they affect our task? Documents that should be analyzed include the iPhone SDK Agreement and the iPhone Developer Program License Agreement. But since the XMLVM project has proven that a Java version of Cocoa- Touch is legal, an Objective-C version should be clean as well, no? There is also an Open-Source project which implements some of the UIKit while only adding a prefix to the file and type names. We have contacted the leader to seek his advice on the legality of the endeavor Consulting with a lawyer is certainly a good idea, but as far as I know, nobody can stop you implementing a public API from scratch. If your code is written from scratch, you own the copyright for the new code. APIs can't be copyrighted. Quite a number of existing open source projects (Wine, Samba, GNUstep itself, etc) provide alternative, free implementations of APIs which were originally implemented only in proprietary software. None of the original proprietary software companies has ever had any particular luck in stopping these. They usually try to change the APIs regularly to break compatibility. If you still feel threatened by the Apple agreements you should probably consult a lawyer. But, I haven't signed any agreement and I can find the UIKit API documentation on the public, open Apple web site. You don't need any agreement to get that API. So I don't see what the relevance of the iPhone SDK Agreement etc. is to this. It's not like you've been given secret information and you agreed not to reveal it. It's public documentation describing the public interface for programming some computer devices sold in millions or billions of pieces to the general public. I don't really see how this would be any different from, eg, Wine implementing the Windows API to run Windows programs on other operating systems (or implementing programs using the Windows API on other systems), or GNUstep implementing the Cocoa API. These are public APIs and some people of good will (but sometime competitor companies!) wrote alternative implementations. :-) And there's no need to change the class names. Cross-compatibility is helped if you just use the same class names! :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gsweb WebServerResources
On 18 Jun 2010, at 16:30, Elim Qiu wrote: I'm trying to figure out how img, js, css be compiled into Resources/WebServer dir. In GNUmakefile, list images etc like PROJName_WEBSERVER_RESOURCE_FILES = 1.gif 2.png ... is not practically maintainable for large proj So I put all images in WebServerResources/img and set PROJName_WEBSERVER_RESOURCE_FILES = img js css DIRS img, js, css are correctly copied into ..gswa/Resources/WebServer Just a short comment - PROJName_WEBSERVER_RESOURCE_FILES = 1.gif will install 1.gif into /home/elim/Projects/gnustep/gw/wopack/WOPack.gswa/Resources/ WebServer/1.gif while having 1.gif inside an img directory, and using PROJName_WEBSERVER_RESOURCE_FILES = img will install 1.gif into /home/elim/Projects/gnustep/gw/wopack/WOPack.gswa/Resources/ WebServer/img/1.gif The paths are different. I'm not sure how gnustep-web finds these resources, but you'd need to make sure it can find the images in the subdirectory ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUmakefile question
On 17 Jun 2010, at 08:53, David Wetzel wrote: Hi, my makefile contains this currently and it works, but I am curious if there is a variable I could use. PLATFORM = $(shell uname) ifeq ($(findstring NetBSD,$(PLATFORM)), NetBSD) ADDITIONAL_TOOL_LIBS += -lcrypt endif Hi David you should probably usually use (untested) ifeq ($(findstring netbsd, $(GNUSTEP_TARGET_OS)), netbsd) ADDITIONAL_TOOL_LIBS += -lcrypt endif give it a try. :-) (make sure to add it where you usually add things to ADDITIONAL_TOOLS_LIBS, ie in GNUmakefile.preamble, or, if you have a single GNUmakefile, just before the include $(GNUSTEP_MAKEFILES)/tool.make [and similar] line). Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gsweb WebServerResources
Look at the webpage source, the path differeces are relatively addressed correctly. If I install the app's WebResources to apache documentRoot/WebObjects/Appname.gswa/Resources/WebServer/img/... And use deploy url, the images are displayed fine. Great - in which case, if it all works, I don't understand what your question is any more :-) It is probably a gnustep-web question, nothing to do with the GNUmakefiles ? Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: wrong offset when adding subview from other window.
Hi David I finally managed to look into your problem. It looks like a bug in gnustep-gui to me. I applied a fix to trunk, please try it out :-) Thanks On 4 Jun 2010, at 09:48, David Wetzel wrote: Hi folks, I tried this again and again, but it seems like there is a bug in gui or back. This code: [[window contentView] addSubview:[inspector view] positioned:NSWindowBelow relativeTo:scrollView]; [[inspector view] setFrameOrigin:NSMakePoint(0,0)]; [[inspector view] setNeedsDisplay:YES]; [[window contentView] setNeedsDisplay:YES]; works fine on OS X but looks like that inspectors.png on gnustep. The window content is made by the same gsmarkup on both sides. Can somebody help me please? Thanks! David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Application releases...
All, Since we just did a major release of core Was there an announcement of the actual release somewhere? I am only aware about the discussion relating to an *upcoming* release. I made an announcement on the info-gnustep list. It's also on the GNUstep wiki. It may be worth posting the announcement to discuss-gnustep too ? :-) I wasn't subscribed to info-gnustep myself and was confused myself about whether we had released the core libraries or not. ;-) Just a suggestion - I think a reasonable policy would be to have announcements posted to both discuss-gnustep and info-gnustep; discuss-gnustep is then for people who want to receive everything (announcements, discussions, chats, etc), while info-gnustep is for people who want to receive only the official announcements (lower traffic). :-) I just can't imagine why someone would want to receive all the discuss- gnustep posts discussing details and situations that may or may not affect them, and *not* receive the official announcements of new releases, which affect everyone. ;-) But, it is only a suggestion. Otherwise, I guess I need to subscribe to info-gnustep. :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: how to port gorm files to renaissance?
yeah, I agree... originally i had intended to move the whole shebang to renaissance and the inspectors turned out to be fairly difficult. mainly because they are in a constrained space, and getting the autolayout to work in that constrained space and look good proved very difficult, you'd pretty much need to forgo the autolayout mechanisms in renaissance and place everything with absolute positioning in addition to that there is alot of stuff like a | x b | y c | z -- in the inspectors, with a | x aligned horizontally, but abc aligned vertically, and the box based autolayout mechanisms made it easy to get abc aligned vertically or ab by cz aligned horizontally, but getting them both to align proved a challenge. In subversion trunk there is a grid tag which does that. :-) Check Examples/grid.gsmarkup and Examples/grid-proportional.gsmarkup. Just pointing it out - if you prefer to use NIBs, why not. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Patched] What to add to GNUmakefile to compile with a .pch file that came from Xcode project?
Thanks Chris excellent contribution - we definitely want to support the .pch extension for precompiled headers! :-) I have applied to trunk a slight different patch (in attach for your interest) which is simpler and supports any possible extension for precompiled headers. In practice, I simply removed the hardcoded '.h' from the variables and rules. :-) I briefly tested it with precompiled headers on Apple both with a .h and .pch extension, and it works for me. Can you confirm that it works for you as well ? (you can try it out from subversion trunk ... will soon be released as part of gnustep-make 2.4.0) Thanks patch Description: Binary data On 24 Apr 2010, at 03:37, Chris Corbyn wrote: I've patched in support for the .pch extension for precompiled headers as used by Xcode. I believe I've also corrected a typo for OBJCC precompiled headers, which was missing a dot in the file extension. gnustep-make-2.2.0.patch This is working nicely for me. I can use .pch extension or a .h extension; it will do both. For now I'll stick to .h until this patch finds its way into the main project. e: ch...@w3style.co.uk t (en): http://twitter.com/d11wtq t (it): http://twitter.com/cosadici Il giorno 24/apr/2010, alle ore 10.11, Chris Corbyn ha scritto: Hi, I'm trying to make sure my Xcode project builds in both Xcode and GNUStep. It contains a .pch file containing common includes, which is required to be prefixed to every file compiled during the build. When I add it to the XXX_OBJC_PRECOMPILED_HEADERS as so: Cioccolata_OBJC_PRECOMPILED_HEADERS = Cioccolata_Prefix.pch The build immediately fails with: Making build-headers for framework Cioccolata... Making all for framework Cioccolata... make[1]: *** No rule to make target `/Users/chris/Projects/Mac/ Cioccolata/build/GNUStep/obj/PrecompiledHeaders/ObjC/ Cioccolata_Prefix.pch', needed by `internal-precompile-headers'. Stop. make: *** [Cioccolata.all.framework.variables] Error 2 Does GNUStep-make handle files with the .pch extension as given by Xcode? What do I need to do to make this work? While my project is still in it's early stages and therefore small I manually copied the contents of the .pch to my .m files and can build the project this way so the only thing I'm stuck on is how to use the .pch. Thanks all, Chris e: ch...@w3style.co.uk t (en): http://twitter.com/d11wtq t (it): http://twitter.com/cosadici ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
Having many commits during a feature freeze is very good as it is supposed to mean that a lots of bugs are being fixed. :-) As far as I can tell none of the recent commits in gui or back is related to any reported bug. [...] Ok - thanks! - that clarifies the problem then :-) I'm sure individual committers would probably disagree or have good arguments why their changes should have gone in - it sounds like we need some simple process to resolve the disagreements and decide what goes in and what doesn't go in at this stage ? ;-) As far as I understand, you're in charge of GUI, so maybe you (and/or Gregory) could propose how you want to manage that ? Maybe patches for GUI must be approved by you before being committed during the feature freeze ? As an outsider, it does seem that GUI needs a few weeks of feature freeze and bug fixing, so I wouldn't give up on that just because it needs to be organized somehow ;-) (btw sorry, I don't mean to interfere - I'll disappear from the discussion of the GUI release freeze after this email) -- For the part I work on (gnustep-make and core makefiles) anyone can make any small fixes they want, but for substantial changes please talk to me before committing (this is always the case though). :-) gnustep-make is quite ready for the 2.4.0 release, except that: * there is this long-standing issue of whether we should link all libraries or not when linking executables. I was planning on making that configurable at ./configure stage (with some reasonable, OS-dependent defaults). It would be good to do this before a release, as it might change how things are linked. On the other hand, I have a feeling it's too late for 2.4.0, so I'll probably do it as the first thing after this release instead. * I haven't looked at how gnustep-make works on Apple at all. I wanted to make sure the apple-apple-apple settings and compiler/linker flags are meaningful and usable - at the moment, I don't think they are as many people reported you have to tweak them in non-obvious ways to use it. If I get some time, I'll try to do this before the release. * I also wanted to look at the Cygwin port, but that may not have time before the release. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
A very very nice feature fix would be having the instalaltion domain configuration working on windows like on linux! I bet Gregory agrees... I have already fixed it :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
Looks like we have more commit right now during code freeze then we have at normal times. I would suggest that we give up the idea of doing more tests. As long as people cannot stick to a code freeze even for a week, I thought we were in feature freeze - ie, all commits must be bug fixes as opposed to implementation of new features. A typical pre-release phase to iron out bugs before a release. :-) Instead, you're suggesting we're in code freeze - meaning no commits at all ? Ie, nothing gets done for weeks ? I've never seen a project do that. Anyway it would be easy enough to do, we just all have to stop doing anything. Hmmm. Not sure why that would be useful ? ;-) Having many commits during a feature freeze is very good as it is supposed to mean that a lots of bugs are being fixed. :-) With about 150 bugs open in the bug tracking system, we probably need quite a few weeks of feature freeze / bug fixing to get a good release. :-) If I am the one who misunderstood and we really are in code freeze, please let me know. ;-) Probably Gregory should clarify. I personally suggest we stay in a feature freeze / bug fixing only phase for a while until the bug count is down and the commits slow down because there are no more bugs to fix :-) Finally, it is quite possible you were referring to some specific changes that are new features instead of being bug fixes - presumably in the gui ? If so, you should IMO feel free to point these out, and even revert them. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Issues with nextKeyView chain
But it appears to me that the code could be cleaned up and simplified quite a bit if everyone agrees with my assertion that a view should only have one (or zero) nextKeyView. To begin with, the _nextKeyView ivar could be turned into a direct pointer to the next key view rather than a GSIArray. Also, the code is not well encapsulated right now, as it makes direct changes to ivars of other objects. Does anyone see any reason not to change nextKeyView to a single object? Would someone familiar with that code like to make the change? (In particular, I'm unsure whether there may be other classes besides NSView that might be impacted…) I think you are misunderstanding the code here. Each view already has at most one next and previous key view, which is saved in the first element of the respective arrays. The remaining elements of the arrays are used to keep track of those views that refer to this view as their next and previous key view, respectively. For instance, given the statements [P1 setNextKeyView: V]; [P2 setNextKeyView: V]; [P3 setNextKeyView: V]; [V setNextKeyView: N1]; [V setNextKeyView: N2]; [V setNextKeyView: N3]; you will end up with the following situation (sorry for the poor ASCII art, you'll need a fixed pitch font to view this correctly): +-- nextKV \ P1 -- nextKV --+ | +-- prevKV -- N3 \|/ P2 -- nextKV --- V --- prevKV -- N2 /|\ P3 -- nextKV --+ | +-- prevKV -- N1 \--- prevKV --+ Note that the previous key view of V is P3 and the next key view is N3. The pointers to P1, P2, N1, and N2 must be kept in the previous key and next key view arrays so that the nextKV pointers of P1, P2, and P3 and the prevKV pointers of N1, N2, and N3 can be reset when V is deallocated, which is necessary to prevent crashes of the sort you were experiencing. Thanks Wolfgang interesting ... good point and great explanation :-) But what you describe (multiple views with the next key view set to the same view) seems like a programming (and user interface) error, so is it worth complicating the implementation to support it - wouldn't we rather have the implementation try to fix it and keep the next key view loop consistent ? :-) The next key view loop that you describe is problematic for the user when navigating. If you are on P2 and hit 'TAB' to go from P2 to V, then when you hit 'shift-TAB' to go back to P2, the system would unexpectedly send you back to another view (P3 if I read your diagram correctly). That's not good. Really, 'shift-TAB' must undo exactly the navigation action that 'TAB' did, so if TAB goes from P2 to V, then 'shift-TAB' must go from V to P2. I personally use TABs often and get upset when I'm hit by this problem which is typical of low-quality Windowish user interfaces - typically you TAB quickly to get to the view you want, but then often you hit one TAB more than needed and get past it, so you then try to go back to it by hitting 'shift-TAB' and are irritatingly sent to some place totally unrelated in the window. As 'shift-TAB' produces unpredictable results, the only way to get back to where you want to be in a predictable time is then to hit TAB again and again and again hoping that the window loop is closed and after TABbing long enough you'll get back to the start of the window and can then TAB your way back to the view you want (and being careful not to miss it again else you'll have to frantically TAB your way out again). Irritating. :-( I seem to remember that the API was built in such a way as to prevent this from ever happening. IIRC calling setNextKeyView: seems so innocent and localized, but it actually does quite a bit of work in other views to keep the next key view loop consistent. And IIRC 'setPreviousKeyView:' was removed by Apple at some point - that makes it even more obvious that 'setNextKeyView:' is expected to modify things in other views to keep the key view loop consistent. :-) So the situation you describe could (should ?) be made impossible - when you call [P2 setNextKeyView: V];, that would completely undo what [P1 setNextKeyView: V]; did. It would detect that V already has a previous key view, and would terminate that by setting both (V-PreviousKeyView)-NextKeyView and V-PreviousKeyView to nil before starting to configure the new next key view. Then any 'TAB' action would always be undoable by using 'shift-TAB', and the memory management is simpler :-) And I agree with Doug that this thing about views editing internals of other views is not that inspiring/beautiful. An alternative (better ?) API would have the 'next key view' as an NSArray instance variable of the NSWindow, and NSWindow would have the methods to manipulate it. The implementation would then be quite simple and clear, but have obviously a different feeling as information on the
Re: Next GNUstep release?
On 26 Mar 2010, at 20:55, Fred Kiefer wrote: Before FOSDEM we were planing a coordinated release of the GNUstep core components. In the meantime a lot has happened. Base was completely rewritten, Is gnustep-base really ready for a release so shortly after a large rewrite ? I assume we're talking of an unstable release ? ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
Before FOSDEM we were planing a coordinated release of the GNUstep core components. In the meantime a lot has happened. Base was completely rewritten, Is gnustep-base really ready for a release so shortly after a large rewrite ? I assume we're talking of an unstable release ? ;-) Most of the 'rewriting' was really simplifying. In terms of line count, I wouldn't be surprised if there is less code in base now than in the last stable release - although there's a lot more in terms of features. In particular, Richard has done a lot of work on the test suite, and many of the 'rewritten' parts were fixing bugs that the test suite found. I've certainly found the svn base to be more reliable than nominally-stable base, and I think calling it an unstable release just means that no one uses it. I'm not trying to downplay how great the new software is. :-) I just wouldn't consider it well-tested yet. Testing takes time. We're mostly relying on crowd-testing, where we don't have much control over who is testing what. We just hope that if we wait enough, a good number of people will have tested it in various conditions and reported the problems they had. I think it's worth waiting a month or two after a big rewrite before we can claim the software is stable. :-) See, I wouldn't use the new gnustep-base on mission critical production servers myself for a few months at least - I'm wondering if other people/users/companies would really want to ? ;-) By the way, I don't have a strong opinion on this - if other people feel there has been enough testing, you can make a stable release, I won't get offended or anything. :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Windows] : gnustep-base
And my final issue is about Install directory because everything is installed in /GNUstep/Local ... but I want it to be in /GNUstep/System. HOW CAN I CHANGE THAT ? You could use installation-domains.conf but it is currently broken on Windows. I think I know how to fix it but need a hour or so to do it properly (else I'll cause more problems than I fix as the issue is subtle). Probably won't happen until the weekend then :-( You can still install it in System manually. Give it a try -- cd core/base ./configure --with-installation-domain=SYSTEM make make install GNUSTEP_INSTALLATION_DOMAIN=SYSTEM Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Windows] : gnustep-base
So I suppose you wanted to write: ./configure --with-installation-domain=SYSTEM make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM make install GNUSTEP_INSTALLATION_DOMAIN=SYSTEM Yes. Apologies. Actually I am asking to change default install dir because this is how it's done with current windows installer. But maybe it's perfectly fine to install it inside c:/.../GNUstep/ Local ? Is someone has some opinion about that, speak loudly. You can install it anywhere you want. :-) If you're distributing the results of your build to other people, it might make sense to have the build all in System so they have a clean Local where they can install their own local stuff and they know what they got from you (in System) and what they installed themselves (in Local). ;-) If it's for yourself only, you can do whatever you want :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Google Summer of Code 2010
I think GSoC is probably a good idea, and I guess I could mentor for it, but I doubt that I'd be very good at mentoring. People have talked about having to chase students and try to get them to do the work, and I'm just never able to do that sort of thing effectively. The potential benefits if we get a good student able to devote real time to a particularly hard problem have got to make doing this worthwhile though. I agree. If we have mentors (and it seems we do), we should definitely try to take part in GSoC. :-) Selecting good students (that don't require constant chasing) is key, but it is not easy. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: sync.m
We should not sacrifice new features or readability for the sake of
holding on to older architectures and compilers.
Also, the use of non-c99 standards does hinder contributions since we
constantly expect people who don't have access to c99 based compilers
to change their code to conform to c89.
I think we should have a clear, explicit and unemotional support/
compatibility strategy. :-)
As GCC 2.95.3 was released in March 16, 2001, it may make sense to no
longer support it.
Or maybe it does. I vote for supporting it.
Anyway the question really is - what is the oldest GCC that we support
if it's not 2.95.3 ?
3.0.4 (released February 20, 2002) ?
Just mentioning c99 doesn't seem to help that much since IIRC no
version of GCC
actually implements all of c99 anyway. I actually am not really sure
what C99 features,
added after 2.95, we really need.
Nobody is breaking things gratuitously. The c99isms slip in to
code simply because all modern compilers support them, and don't
warn you that older compilers won't. Most people use them
habitually (locality of declaration of variables is particularly
good for code readability for instance) and simply won't notice
that they have used them.
We can use -Wdeclaration-after-statement to get a post-2.95 GCC warn
you when you locally declare variables without starting a { } block.
Really not a problem - it's easy enough to add it to gnustep-base and
gnustep-gui.
Thanks
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Google Summer of Code 2010
They did not select us last year and we failed to attract suitable students in the years before that. Is it possible to learn something from this experience? I mean, if GNUstep isn't attractive to students it might be not attractive to non-students as well. I don't think we failed to attract students ;-) I remember a number of very good students applying. I also remember Chris Farber who got one of the places and wrote our first key-value observing implementation as part of Google Summer of Code. That was good. I guess the main question really is not attracting students, but mentoring them. ;-) Does any of us have enough time to properly follow a student ? Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: includes/imports in gui.
I'm not convinced by the other part of the argument (about precompiled headers not being much faster), I think the problem is there is a perception that precompiled headers are much faster when used. I had that perception too, until I tried them out :-) Renaissance uses them, and I just looked at a random file (GSAutoLayoutManager.m) to get some data for you. On a test machine, compiling it without precompiled headers takes 0.61 sec, and compiling it with precompiled headers takes 0.45 sec. (after priming all caches etc, 10 results with mean deviation below 0.01 sec etc). That is faster, but to be honest not much faster. Using a precompiled header reduces compile time by about 25% (note how this is the maximum speedup you'll ever get in a build from precompiled headers). But, creating the precompiled header itself requires 0.8 sec (on same machine, same conditions). So, to do a full build, you save 0.16 sec per file you compile, but you consume 0.8 to generate the precompiled header first. If you compile less than 5 files, it's not worth it. If you're doing things in parallel, you have to multiply that, eg, if you compile with -j 4 and your computer can compile 4 files in parallel, precompiled headers are not worth it unless you compile at least 20 files (since it takes 5 compilation steps to compile 20 files, and with precompiled headers you'd save 0.16 * 5 = 0.8 sec). So if you're using -j 4 and compile 40 files, you'll be looking at a compile time of 0.61s * 10 = 6.1s without precompiled headers, and 0.8s + 0.45s * 10 = 5.3s with precompiled headers. So, just a 14% reduction in build time over a large project with 40 files. (and if you had, say, 24 files, you'd be looking at almost no speedup; if you had 16 files only, you'd be looking at a slowdown!). All new CPUs coming on the market are 4-core CPUs. So in a couple of years everyone will do 'make -j 4' as standard. Servers use powerful CPUs and often are dual-CPUs; on these machines, 'make -j 8' will easily be the minimum you do - the perception that precompiled headers are much faster in that situation is an illusion. A large project will 40 files will require 5 steps to compile with 'make -j 8', meaning using a precompiled header won't be any faster than building without it! Anything with less that 32 files will simply compile slower with a precompiled header. And at the next doubling of CPU cores, it's hard to find any Objective-C project that will compile faster with a precompiled header. ;-) -- Of course, if you are developing, and need to recompile your code after a change, you'd already have your precompiled header. So if you change two files and recompile, you have to wait 0.45s instead of 0.61s for them to be compiled. That's when precompiled headers really work great - I guess this is the case you were referring to when you talked about precompiled headers being cached. And it's a very good point - in this case using a precompiled header will always be faster. But the improvement is hard to notice in practice. You'd be saving only 0.16s on your build. Thanks PS: The tests above were with Renaissance, which includes Foundation/ Foundation.h and AppKit/AppKit.h. If you try with gnustep-gui, which only needs Foundation/Foundation.h, the results are even more disappointing as the benefits of using a precompiled header are even smaller! And gnustep-gui currently tends to only #import the Foundation headers that it needs ... so the benefits from switching to #importing the entire Foundation/ Foundation.h and precompiling it are even smaller ... ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: includes/imports in gui.
It's also worth noting that our Cocoa.h is a LOT smaller than Apple's. The output from gcc -E on a simple .m file that just contains the line #import Cocoa/Cocoa.h is around 800KB on GNUstep and over 3MB with Cocoa. How interesting. :-) That suggests processing the headers in Cocoa would take almost 4x what it takes on GNUstep (all other things being equal), and so a precompiled header would indeed have a much larger effect on an Apple build. That would explain why Apple developers are so keen on it. I couldn't really figure out why they are so keen on precompiled headers because when I tried them on GNUstep it was so hard to get any big performance speedups out of them. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: includes/imports in gui.
It has a small effect on how we should organize headers in base too: I want to clearly separate out non-OSX stuff from OSX stuff, so that our extensions would all be available to OSX users in the base- additions library. I was hoping to just have all the extensions headers collection in Additions.h and have Additions.h included in Foundation.h for backward compatibility ... so existing Apps which include foundation.h and expect to use our extensions would continue to be able to do so. But ... if people aren't going to want to include Foundation.h (because it's slow), perhaps the individual headers should be made to import the extensions (eg NSString.h would import GNUstepBase/NSString+GNUstepbase.h unless NO_GNUSTEP is defined). Alternatively, perhaps we need to update all projects to explicitly include the headers for the extensions (irritating work to do)... I'm not sure what to do here. I personally vote for the option where NSString.h would import GNUstepBase/NSString+GNUstepbase.h (unless NO_GNUSTEP). It provides the best backwards-compatibility solution. Just out of curiosity, in a normal build, would Additions be built before or after gnustep-base ? Can it be built in parallel ? Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: includes/imports in gui.
Anyway, given that gnustep-make and recent compilers have supported precompiled headers for some time now, I think gui/back should probably simplified to just do #import Foundation/Foundation.h (assuming that 'startup' installs base before it builds gui ... so the installed Foundation.h will point to all the right code and will have a precompiled version to make for fast compilation of gui and back). When I implemented precompiled headers in gnustep-make, I planned to immediately modify gnustep-gui to use them. And I did. But then I discarded the work as the speed-up was too little to be worth the extra effort and complexity - not to mention all the users for whom the build would be slower because their compiler doesn't have working precompiled headers ... eg, GCC 4.1 users!. :-( Just to clarify the background - a precompiled header is specific to the exact flags you pass to the compiler. If you change any of the compiler flags, you'll need a new precompiled header. As a consequence, precompiled headers are generally used by having the project you're building (eg, gnustep-gui) have a file with all the #imports in it, and then precompile that file as part of the compilation of the project; all files in the project then include that header as the first thing they do. So, precompiled headers initially slow your build by adding an additional step ... creating the precompiled header. That step can't be parallelized because it needs to happen before all the other ones. Depending on how much using a precompiled header speeds up the following steps, it's worth it or not. If you're compiling a lot of files, and importing lots of large system headers in all these files, it's generally worth it (the more you parallelize, the less it's worth). But in the case of GUI, it's not worth it because it's only using Foundation. So it'd be only #importing Foundation/Foundation.h. In my tests it really starts to be useful when you include at least both Foundation.h and AppKit.h. Finally, most older compilers don't support precompiled headers, and GCC 4.1 has broken precompiled header support so gnustep-make automatically disables precompiled headers if you're using GCC 4.1 (for a sad example, I am using GCC 4.1). In these cases, you'll simply get a (slightly) slower build as you're including more headers than needed and they are not even precompiled. So, switching to importing Foundation/Foundation.h and precompiled headers would slow building gnustep-gui for a large group of users (who don't have a working precompiled header support in the compiler), would not significantly speed up builds for everyone else, and adds extra complexity. The current system of importing the headers we need from gnustep-base gives us consistent, fairly fast and simple builds, so I wouldn't change it. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: headers in sub-subdirectories, and gnustep-make 2.2.1
Now the new feature is that you can specify headers that live in subdirectories, as in Beauty_HEADER_FILES = Beauty.h Vanity.h Pride/Pride.h (note the last one, Pride/Pride.h) then your headers would be in Beauty/Beauty.h Beauty/Vanity.h Beauty/Pride/Pride.h and end up installed as in Beauty.framework/Headers/Beauty.h Beauty.framework/Headers/Vanity.h Beauty.framework/Headers/Pride/Pride.h (note: the last header requires creating a directory, which is now automatically created for you) What does this mean? Do you have to break the installation in three steps. First install the rest, then create a directory manually and then install the last header file? I don't believe this is what you implemented. Could you just explain it a bit more? Not sure I understand the question, so I'll just explain a bit more. :-) It's not a big change - unless you need it. ;-) In the new gnustep-make, you don't have to do anything - it's all installed for you. All you have to do is specify your headers as in Beauty_HEADER_FILES = Beauty. Vanity.h Pride/Pride.h everything else happens automatically. In the old gnustep-make, yes, you used to have to create the Pride header directory manually in before-all::, otherwise installing the Pride/Pride.h header would fail. So the change in behaviour is that now the directory gets automatically created for you. For most people this may not be important as they have all headers in a directory. But a number of people asked for it. This change is ideally coupled to the other change in gnustep-make trunk, where you can specify source files in subdirectories -- Beauty_OBJC_FILES = Pride/Pride.m this change is actually completely different, but looks/is related in a way and it makes sense to release them together. :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
headers in sub-subdirectories, and gnustep-make 2.2.1
I implemented having headers in sub-subdirectories. For example, consider a framework called Beauty. Let's you have headers Beauty_HEADER_FILES = Beauty.h Vanity.h then your headers would be in Beauty/Beauty.h Beauty/Vanity.h and end up installed as in Beauty.framework/Beauty/Beauty.h Beauty.framework/Beauty/Vanity.h and you include them as in #import Beauty/Beauty.h #import Beauty/Vanity.h Now the new feature is that you can specify headers that live in subdirectories, as in Beauty_HEADER_FILES = Beauty.h Vanity.h Pride/Pride.h (note the last one, Pride/Pride.h) then your headers would be in Beauty/Beauty.h Beauty/Vanity.h Beauty/Pride/Pride.h and end up installed as in Beauty.framework/Headers/Beauty.h Beauty.framework/Headers/Vanity.h Beauty.framework/Headers/Pride/Pride.h (note: the last header requires creating a directory, which is now automatically created for you) and you include them as in #import Beauty/Beauty.h #import Beauty/Vanity.h #import Beauty/Pride/Pride.h --- As soon as this change has been tested, I'd like to release gnustep- make trunk as gnustep-make 2.2.1. I guess we could wait a week or two, then we could release. :-) I have other changes I'd like to make, but it's worth shipping the current batch of changes to end-users first. :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [flame] NEWS file is useless
Also, A ChangeLog is easy to search. When something breaks I grep in the changelog. Old habits. Why is: cat ChangeLog | grep easier than: svn log | grep Because using a ChangeLog doesn't require internet access, and it is *much* faster. :-) And for people who get a source tarball, they don't even need to have subversion installed, or know where the repository is located or how to access it. Anyway, it seems a long discussion on a minor point. I suggest we could simply manually copy the ChangeLog entry in the svn commit message every time we do a commit. Then the ChangeLog entry would be available also via svn log for people who use svn logs instead of ChangeLogs to track development. I guess this could be automated so a subversion hook would check that every commit contains a ChangeLog entry, and would automatically copy it into the subversion commit message. As hooks would slow down an already slow repository, we could also simply agree to do it manually. If someone gets it wrong it will be immediately obvious by looking at the svn logs and can be corrected. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [flame] NEWS file is useless
ChangeLog has less information, in a less useful format, than the svn logs and is a hold-over from CVS not storing repository-wide change information sensibly. With svn log, you can get a log of change messages at any granularity that you like. I agree there is an overlap, but there are also some differences. ;-) Subversion records a single log message for an entire transaction, which might contain changes to a number of files. A ChangeLog entry is supposed to contain a separate log message for every file that was changed. You realise that svn lets you commit changes to different files separately, right? If you have independent out-of-tree changes, commit them separately (see r29053 to r29055; three commits, all created together but committed separately to provide different log messages). I agree with your later point that you could simply write a ChangeLog entry in the subversion log - that way you still use subversion transactions properly, but document the changes to all files. :-) I don't think committing files separately makes sense instead - because you lose all the benefits of subversion transactions. If you get interrupted or lose network access between committing the separate files, the repository will be left in a broken state. That is bad. Also, I do like having in the logs the information that the changes are part of the same transaction. You do a single diff and see all the related changes to the different files, which is great. :-) So I guess the solution to that would be instead to require ChangeLog entries to be committed to svn log. Finally, the obvious advantage of a ChangeLog is that every source code distribution/tarball will include it. Subversion logs are only available if you use subversion. Subversion is available to anyone with access to the svn repository. Yes, but in practice it is a pain for people who are not following the project. When I install software from third-parties, I hate when they don't include a properly detailed ChangeLog - eg, if I need to check if a certain bug in a certain file was fixed between version 1.7.4 and 1.7.5, I just want to download the 1.7.5 tarball and check the ChangeLog. I don't want to have to set up whatever versioning system they use just to check a single file - it takes time because every project uses a different one, etc. I also occasionally work on gnustep-make offline, and the subversion logs are not available offline, while ChangeLogs are. People can track it by subscribing to the RSS feed from cia.vc, they can see an individual committer's changes by looking at the timeline on Ohloh.net. Sure, that is certainly good. If someone wants to do 'svn log ChangeLog' when creating the tarballs, they can; just add it to the script you use to generate the tarball. Given that most tarball downloads are likely to be from people who just want to build the code, however, it seems like a waste of space. It's definitely not a waste of space. ;-) But if we were to agree that people would write ChangeLog entries in the subversion logs, then we could generate the ChangeLog from the subversion logs before release. Even if in practice that can be hard, since all the interesting information for existing projects is currently in ChangeLogs, so we'd need to prepend to these ChangeLogs the latest ChangeLog entries from the subversion logs, but the system would need to be able to figure out which logs to prepend and which to ignore. Maybe a commit hook that copies the subversion log to the ChangeLog file makes more sense then, so the ChangeLog would automatically be updated whenever you commit. If we want to go through this route, that would be ideal I guess. So maybe we could adopt a different approach depending on the project. I certainly think ChangeLogs are very good for the core libraries. I still haven't seen a convincing argument for it. Any of the information that people write in the ChangeLog file they could also write in the commit log. It is impossible to make a commit without writing a log message, it is easy to make a commit without editing the ChangeLog (you could add a pre-commit hook that prevented this, but no one has done so). You're right that writing a subversion commit message is enforced, while writing a ChangeLog entry is not. But on the other hand, ChangeLog entries must be in a certain format that require you to write a description of each change to each file, while subversion log messages enforce no format and people tend to write extremely short, unexpressive messages such as fixed bug or improved performance when they maybe have changed hundreds of lines in lots of different files. When you're later trying to debug some failures caused by an old change, you need some information on what they were trying to achieve, or why things were changed - a more serious and detailed
Re: [flame] NEWS file is useless
It would be good to consider exactly how much (if any) information we want to present in NEWS/ReleaseNotes ... my preference would be for minimal information there, and a pointer to a generated ChangeLog for details. This would require a policy that svn log entries should be suitable for app developers (users of the libraries), not just for people writing the libraries themselves I agree that it would be good to have ChangeLog entries that are well written and readable by people who are not working on the software themselves :-) I still think NEWS (and/or Release Notes) need to be written separately as an additional task. We shouldn't be lazy with documentation ;-) I guess it depends on the piece of software, but for example our core libraries have a large user base, and it's worth spending some time writing clearly readable NEWS/ReleaseNotes. If you don't write them, you'll spend 10x the time answering questions via email about changes to the library anyway, so it even saves time in practice to spend time documenting changes! ;-) Finally, NEWS/ReleaseNotes are important for marketing - any time we implement something good, we should tell the world! NEWS/ReleaseNote tend to for the basis for public announcements or tend to end up on websites etc. so we should work on them. Lastly ... I'm not even sure that the historical policies on ChangeLog etc are written down anywhere They are part of the GNU Coding Standards, http://www.gnu.org/prep/standards/html_node/Change-Logs.html Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [flame] NEWS file is useless
So I guess the solution to that would be instead to require ChangeLog entries to be committed to svn log. By the way, presumably we'd still include the author of the change in the subversion commit message ? Ie, we write a full ChangeLog entry including the author at the beginning ? The reason is that when we receive patches, the committer is often *not* the author of the patch, only the reviewer. With ChangeLog entries you can see who is the author of the patch, regardless of who did the actual commit. (and occasionally, some changes simply have two or more authors - again in ChangeLogs you just list multiple authors, while subversion logs can only record the committer) I'm personally not too convinced. I guess it must be because I don't use any tools based on subversion logs so I don't see a particular benefit. Anyway, we can change things. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [flame] NEWS file is useless
I'd be in favour of ditching NEWS and ChangeLog. ChangeLog has less information, in a less useful format, than the svn logs and is a hold-over from CVS not storing repository-wide change information sensibly. With svn log, you can get a log of change messages at any granularity that you like. I agree there is an overlap, but there are also some differences. ;-) Subversion records a single log message for an entire transaction, which might contain changes to a number of files. A ChangeLog entry is supposed to contain a separate log message for every file that was changed. So, ChangeLogs are particularly good for software that is stable and where changes should be very well thought of -- forcing people to describe each single change to each file is good to slow development down and get people to think more about what they are doing. If people are submitting patches, ChangeLog entries also have the advantage that they can be submitted with the patch, and they provide a more detailed description of the changes that were done to each file, and why. Finally, the obvious advantage of a ChangeLog is that every source code distribution/tarball will include it. Subversion logs are only available if you use subversion. I still see your point - particularly for new software, written from scratch by a single person and not yet really released, it is faster to just code it all and write short subversion logs for each commit - it sounds superfluous to also write ChangeLog entries. But once the software is quite finished and stable, is widely used and released, and we're polishing it while being extremely careful not to break things, then a more careful approach where every change is documented in great detail (and even redundantly) looks good to me. ;-) So maybe we could adopt a different approach depending on the project. I certainly think ChangeLogs are very good for the core libraries. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Why does GNUstep Make add -libobjc to tools / apps?
On 17 Nov 2009, at 16:49, David Chisnall wrote: Is there a sensible reason why GNUstep Make adds -lobjc to the end of the linker flags for tools and apps (which already link against - base, which links against libobjc)? In a number of projects I'm experiencing problems with this because the GNUmakefile specifies -L/ usr/lib as a linker flag and so these apps are linking against the libobjc found there, overriding the one that GNUstep linked against, and then causing link failures because the system libobjc is missing some symbols... Omitting -lobjc would fix this, but GNUstep Make doesn't seem to provide an easy way of doing that (or, in fact, anything, but that's a different complaint). If we could discuss and agree on exactly how this should work, we could easily change it. :-) It would probably require a new 2.4 version of gnustep-make though, since we may be breaking the way libraries and programs are linked. To give you some background, first of all, some platforms are different (for example Microsoft Windows) and on these platforms we must always link against everything otherwise linking just doesn't work. So, on these platforms we have a special case and always link libobjc (and the other associated libs). On platforms where we can get away without not linking, for example, libobjc, at some stages, we had a change where only gnustep-base and the final executable are linked against -libobjc -- https://savannah.gnu.org/bugs/?9920 This is the current behaviour; some people recently complained about that change - they want -lobjc to be added everywhere, in particular, to all libraries, to comply with Debian Policy which forbids undefined symbols -- https://savannah.gnu.org/bugs/?24109. If we were to implement 24109, we'd always link everything to -libobjc to get rid of the undefined symbols. Of course, you now are asking for a totally opposite change - ie, that only libgnustep-base should be linked with -lobjc. ;-) I guess the discussion is open - I welcome ideas or arguments about what we should do with respect to linking. :-) I don't have a particular opinion myself. If we can't find any agreement, we can always add a ./configure flag to gnustep-make and make it behave differently depending on how you configure it. I assume that on GNU/Linux, if nothing else is specified, we'd default to the behaviour that conforms to the Debian Policy - other distributions have similar policies and we'd like to make it really easy to package GNUstep, so it makes sense to use by default whatever behaviour helps getting GNUstep software into Linux distributions. You could still get a different behaviour by just using a ./configure flag. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Additionally I really dislike the coding style, not because it's not mine, but because it fails to make the code more readable. On the other hand, there was code by Fred which looked really ok, so maybe it's just about using the coding style in a sane way All I wanted to say is, that it's not that easy to start hacking inside the GNUstep core libraries. Completely agree. Good coding conventions are picked because they make things that are wrong look wrong or generate compiler errors / warnings. The GNU coding conventions were picked by selecting at random various bits from all existing coding conventions in the hope that that would make everyone happy. They are a horrible mash of things. The indenting style is horrible, for example, and only works if you have your editor set up in exactly the same way as RMS; mixing tabs and spaces for indenting is one of the most stupid ideas I've ever seen. The convention of putting a space after function names and before the open bracket makes code harder to read because it makes it difficult to tell without reading the context that something is an argument list rather than a subexpression. In fact, almost everything about the GNU coding conventions looks painfully stupid to anyone with a basic understanding of how the human visual system works, but as an official GNU project we are stuck with it. I didn't know you have to stick to the GNU coding guidelines if you are an official GNU project. Now I understand all the people complaining about gcc being unreadable... Just to clarify for the non-developers, GCC being unreadable is a completely different problem, not particularly due to the coding style. ;-) Having a standard coding style for the whole GNUstep project is really important as it makes it easier to copy/move code from one part of the project to the other. Using a standard coding style that is documented and used by many other projects is also good as contributors will be immediately familiar with it. The GNU coding standards are used by a large number of projects with a lot of contributors and popularity so can't really be blamed if GNUstep is less popular than, say, GIMP (which also happens to follow the GNU coding standards) or any of the other million projects that use the GNU coding standards or some variants of them. While I sympathize with David who prefers (or is used) to some other coding style, the GNUstep project needs a consistent coding style and the GNU coding standard are as good a choice as any. Since GNUstep is a GNU project, it's a natural choice. By the way the GNU coding standards are not bad, in fact I personally like them (mostly because my eyesight is really bad and whitespace is much more effective at separating tokens than brackets or commas). There are some details I'd change, but they certainly are not an unusual or weird choice for a large free software project. If it's a burning issue for many developers, I guess changing the coding style to something else could be discussed. There would be *lots* of reformatting to do if we ever reach an agreement on some other coding style. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
By the way the GNU coding standards are not bad, in fact I personally like them (mostly because my eyesight is really bad and whitespace is much more effective at separating tokens than brackets or commas). There are some details I'd change, but they certainly are not an unusual or weird choice for a large free software project. To me it is about separating groups of tokens, e.g. if you are going to separate like this [thing foo: arg1 bar: arg2]; and insist on including that space between the 'foo:arg1' group, the whole message send looks androgynous with parts of the selectors mixed in with their arguments... compared with [thing foo:arg1 bar:arg2]; it is very easy for me to pick out which args go with which parts of the selector, and which message is being sent... My personal preference is to do [thing foo: arg1 bar: arg2] (Note the double-space between the two parts of the selector). That way, I can easily visually tokenize it when I read it. Of course, it's my personal preference and it's as good as any. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
It would undoubtedly be good to have some packager-specific documentation, but obviously the target readership is a very small group We *do* have packager documentation, in core/make/README.Packaging Feel free to add a short section about what was discussed here. :-) - How does this allow a packager to install and remove defaults as part of package installation / uninstallation? Presumably you can use plmerge to install them (again, is this documented anywhere?), but how do you uninstall them? I agree with Richard's later suggestion that the package system might deal with that by having a directory where each package installs a .plist upon installation, and removes it upon deinstallation. At the end of each package installation/deinstallation, the package scripts could do a plmerge so that all the currently existing .plists in the directory are plmerged to create the global default plist, which is hence kept up-to-date. :-) That said, it should probably be used with restrain ;-) Presumably you have a specific example in mind where it makes particular sense (Etoile ?); but in general, I personally don't see a reason why installing a package should change some system defaults. Installing a package doesn't necessarily mean enabling it. Eg, I could be installing 10 or 20 themes or other GNUstep GUI-changing bundles, but that doesn't mean every theme that is installed must be trying to force all users to switch to it. I'd expect to have a Preferences panel somewhere where I can change my own user defaults and activate/deactivate the bundles or themes I want/don't want. Different users might activate/deactivate different bundles. So I think it is more important to have a very good preference application that allow real users to configure their environment to suit their needs, including turning on/off bundles or extensions. :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep Make using $(CC) for linking
On 8 May 2009, at 18:14, David Chisnall wrote: Hi, I'm trying to compile GNUstep projects with clang using 'gmake CC=clang', but I'm now getting linker errors creating subproject.o because CC is being used as the linker, even when LD is specified as something else (e.g. gcc). Is this a bug, or a known feature? It is a known bug in gnustep-make 2.0.x, already fixed in trunk. :-) Are you using trunk (soon-to-be-2.2.0) ? It should be fixed there. I tried doing make CC=xxx LD=yyy on trunk and it uses CC when compiling, and LD when linking - so it works for me. Let me know if it doesn't work for you. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
On 7 May 2009, at 15:26, Adam Fedor wrote: I can make a release of the core libraries in the next day or two if that's OK. This was my plan: make 2.0.9 I was thinking of releasing trunk as make 2.2.0 (instead of 2.0.9). The idea being that 2.0.x does not support parallel building (make -j 2), while 2.2.x does support it. :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep Testfarm Results
Fail Compile i386-unknown-freebsd7.1 Thu Apr 2 15:35:09 CST 2009 Btw, I had a quick look - this was due to Compiling file NSObject.m ... /var/tmp//cc968ivA.s: Assembler messages: /var/tmp//cc968ivA.s:1437: Error: suffix or operands invalid for `fstcw' /var/tmp//cc968ivA.s:1446: Error: suffix or operands invalid for `fldcw' gmake[3]: *** [obj/NSObject.m.o] Error 1 It might be worth for David to review the latest changes to NSObject.m Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Updated Roadmap
On 25 Mar 2009, at 20:37, Gregory Casamento wrote: I've updated the 1.0 Roadmap here: http://wiki.gnustep.org/index.php/Roadmap I'm throwing this out for discussion to find out where everyone thinks we stand on some of these goals and what should be added/ changed on this. I support you in your efforts to organize our roadmap ... but I would rather have roadmaps for the separate packages rather than a global GNUstep 1.0 roadmap. ;-) Mostly because the simple idea of a yet-to-come GNUstep 1.0 downplays the fact that the non-graphical part of GNUstep (which is at least half of core, ie gnustep-make and gnustep-base) reached 1.0 many years ago! And they are absolutely production-ready code. :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
