Re: Gna changeover
Dear Ivan! Am Freitag, den 02.06.2017, 13:08 + schrieb Ivan Vučica > I’ve managed to fetch this file directly onto a GCE instance, and thus > the temporary readonly copy of Subversion is available at: > > > svn://vcs.gs.badc0de.net/gnustep > > > Clearly this is not browsable in the browser, but if someone urgently > needs branches or tags of various libraries, this can serve. No > guarantees on uptime though, this is a hacked together hosting. This is very much appreciated! Thank you! I was still trying to figure out how to peace together what we need from the github checkout... I wish you the best of luck for the conversion! Cheers and thank you again! David -- David Ayers - Team Austria Free Software Foundation Europe (FSFE) [] (http://www.fsfe.org) Join the Fellowship of FSFE! [][][] (https://fsfe.org/join) Your donation powers our work! || (http://fsfe.org/donate) signature.asc Description: This is a digitally signed message part ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Gna changeover
Hello Folks! is there an ETA when the repository will be available? can we expect the historical release tags? From what I can see: https://github.com/gnustep/base does not contain any release tags. https://svn.savannah.gnu.org/viewvc/gnustep/ We generally deploy by checking out the upstream sources and we a currently assessing whether it is worthwhile to setup our own repo or import with the versions we need into our project's VCS, so that we can continue deploying. Thanks, David -- David Ayers - Team Austria Free Software Foundation Europe (FSFE) [] (http://www.fsfe.org) Join the Fellowship of FSFE! [][][] (https://fsfe.org/join) Your donation powers our work! || (http://fsfe.org/donate) signature.asc Description: This is a digitally signed message part ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: WebServer: caching responses
Am Donnerstag, den 21.07.2011, 23:00 +0100 schrieb Nicola Pero: 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. Thanks... this seems like the sane approach. 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. Well actually I doubt that will work in our particular case, since the the decision on whether to use the cache or not, is dynamic and the caches should be discarded quickly in most cases. But maybe we just have to dig into mod_cache a bit ... but it's an optimization since we may get by with extracting headers and content from a cached GSMimeDocument and feeding it to the new instance supplied by the call as Richard suggested. It's a little overhead but since the caching of the dynamic content is not used that often, we'll probably get a way with that. Cheers, David -- David Ayers - Team Austria Free Software Foundation Europe (FSFE) [] (http://www.fsfe.org) Join the Fellowship of FSFE! [][][] (https://fsfe.org/join) Your donation powers our work! || (http://fsfe.org/donate) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: WebServer: caching responses
Am Freitag, den 22.07.2011, 06:49 +0100 schrieb Richard Frith-Macdonald: The WebServer class is specifically designed for dynamic pages, not static ones (normal usage is to have apache serve static pages and WebServer serve the dynamic ones). ACK. That being said, it's trivial to cache the body of static responses (I would just use an instance of GSCache to store the body, and put that in the response) ... which gets you a reasonably fast result, but will still produce rather more cpu load than using apache would. I suppose you mean NSCache? I'll read up on it, but I think we may get away with our temporary caching of the response and transfering headers and content to the new instance if we let apache handle the truly static resources. I don't mind extending the API if you really don't want to use WebServer in conjunction with apache ... I would expect existing performance is good for most purposes, but it could be faster (and I've been thinking about adding support for streaming video, which is the other case the existing code isn't really designed to deal with). Using apache is fine, I just wasn't thinking of using a reverse proxy setup and wanted to avoid writing a new module. Thanks! David -- David Ayers - Team Austria Free Software Foundation Europe (FSFE) [] (http://www.fsfe.org) Join the Fellowship of FSFE! [][][] (https://fsfe.org/join) Your donation powers our work! || (http://fsfe.org/donate) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Substitute classes
Am Donnerstag, den 17.03.2011, 14:00 + schrieb David Chisnall: On 17 Mar 2011, at 13:49, David Wetzel wrote: Gnustep is LGPL. So there is no issue. Note: the above claim is not legal advice and neither is this. Consult with a copyright lawyer in your jurisdiction if you want legal advice. I think the LGPL is in something of a grey area with regard to licenses like the iPhone. The LGPL section 6b is the one that normally allows linking of LGPL libraries with non-Free software, however this explicitly requires the end user to replace the LGPL'd shared library with their own version. This is not possible on a locked-down version. A strict interpretation of this clause would mean that Apple is in violation of the LGPL by shipping WebKit with Mobile Safari and not providing a mechanism for the end user to replace it with their own version. Exactly how the license would be interpreted is unknown until a court has ruled on the matter. This is also no legal advice, but from http://trac.webkit.org/browser/trunk/Source/WebKit/LICENSE I gather that Apple is the copyright holder of WebKit. If that is truly the case, Apple is not bound by the LGPL. They have the right to do whatever they please. It is merely the license by which Apple's users are bound by. Cheers, David -- David Ayers - Team Austria Free Software Foundation Europe (FSFE) [] (http://www.fsfe.org) Join the Fellowship of FSFE! [][][] (https://fsfe.org/join) Your donation powers our work! || (http://fsfe.org/donate) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Please help: My build of gnustep from modules
Hello Elim Qiu, Am Montag, den 07.06.2010, 12:14 -0600 schrieb Elim Qiu: This is the result I tried so far to build gnustep from modules (svn anonymous co). Since I tried (ogo/sope) a while ago and used to work with WebObjects4.5.1 ObjC windows. I noticed the installation layout is quite different (System dir with no Frameworks, I don't see Foundation.framework anywhere etc). I just want to confirm what I got is ok... (Please help). I tried hello example in gsweb package and it worked and deployable. GDL2 and GSWeb are currently being reworked by Dave Wetzel. Unfortunately this work is being done on the trunk and not on a development branch. Also the commits are often not easily reviewable so I've only been able to poke at issues here and there. The problem with WO45 compatibility is that -base(add) removed some of the important infrastructure we needed to hack the runtime to provide the WO45 compatibility. Also the basic API adaption to Cocoa has also complicated the issue even more. Therefor we effectively dropped the WO45 compatibility goal and made some major changes in the infrastructure to adapt to current -base. We have a project in the test suite that should exercise important parts of the GDL2 API. I'm not sure if D. Wetzel is testing (and adapting it). Parallel to that Dave W. wanted to adapt DBModeler to the new API but failed due to the underlying infrastructure change and began a fork called EOModelEditor which is still a WIP and does not yet support all features that DBModeler did (eventhough it support some other features, IIRC). I guess currently Dave W. is the guy to help you get GSWeb/GDL2 up to par for you needs, but be advised that you'll probably need to adapt your WO4.5 application to make it work. I'd love to point you to stable branches but they currently do not exist. Cheers, David -- David Ayers - Team Austria Free Software Foundation Europe (FSFE) [] (http://www.fsfe.org) Join the Fellowship of FSFE! [][][] (https://fsfe.org/join) Your donation powers our work! || (http://fsfe.org/donate) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
GSObjCRuntime / GDL / GSWeb
Hello folks, I seems that the runtime abstraction layer is being deprecated. I would have expected that the introduction of yet another runtime would actually strengthen the need for the abstraction layer. Yet I appreciate that supporting three runtimes is quite a task. Also the semantics of many underlying concepts of EOF and WebObjects (in particular KVC) have changed so much that it seems hardly feasible to continue to hack the runtime structures to make GDL2/GSWeb work with current gnustep-core / Cocoa. I'm currently considering - forking GDL2 to GDL3 which will not be WO45 compatible yet follow it's concepts as much as feasible. - forking/branching -base for GDL2 but stop supporting Cocoa here - forking/branching -gsweb to be more WO45 compatible and have trunk gsweb adapt to GDL3 and current Foundation/Cocoa ie: WO45 compatiblity -base-wo45 -gdl2 -gsweb-wo45 current: -base -gdl3 -gsweb I need the WO45 compatibility and will spend most of my efforts here. the current projects will lose many of the current hacks and should be what new projects would use. @Manuel/@David: Are you still actively using GSWeb and how much do you rely on WO45 compatibility... i.e. if I fork/branch as I described would you be interested in the WO45 compatibility branch or the branch that tracks the current developments. Cheers, David -- David Ayers - Team Austria Free Software Foundation Europe (FSFE) [] (http://www.fsfe.org) Join the Fellowship of FSFE! [][][] (https://fsfe.org/join) Your donation powers our work! || (http://fsfe.org/donate) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem with Gorm and GDL2
I contemplated on relying on precompiled headers and converting everything in GDL2 to import Foundation.h (AppKit.h where applicable) but decided against it for now since I currently cannot test correctly. (I'm having VM issues) I hope that this is fixed now... Thanks for the report! Cheers, David Am Montag, den 05.04.2010, 21:26 +0200 schrieb Fred Kiefer: It could well be that this problem was triggered by the current restructuring of the gui includes. All applications will need to take care to include or rather import all the needed bits from base or gui themselves. Up to now a full include of Foundation.h would often happen when certain gui headers were included. Am 01.04.2010 19:48, schrieb German Arias: Just now I upgraded my system. But currently, my problem is that GDL2 can't compile, I get the error EOPopUpAssociation.m:155: error: ‘NSInternalInconsistencyException’ undeclared (first use in this function) EOPopUpAssociation.m:155: error: (Each undeclared identifier is reported only once EOPopUpAssociation.m:155: error: for each function it appears in.) That, I think, is a problem on NSException class. David Ayers escribió: Hello Germán, Am Mittwoch, den 24.03.2010, 18:59 -0600 schrieb Germán Arias: I have GDL2 palette in Gorm, but when I start Gorm I get the error: objc runtime: cannot find class GDL2KVCNSObject and Gorm crash. Could you please open a bug report for this? I currently don't have a setup to test this myself. In GDL2 we had infrastructure in place to insure that our KVC categories had precedence to those in the GNU and NeXT runtimes. I /believe/ (but haven't checked) that the libobjc2 runtime may not support those techniques based on Categories in method lists. Richard was so kind to attempt to work around based on classes with the goal that this works with all runtimes. So please state which runtime you are using. The class is implemented in EOControl/EOKeyValueCoding.m. It is a root class. Maybe something in Gorm or in the runtime you are using is the reason why the class cannot be found. You can assign the bug to GDL2 for now, but I wouldn't be surprised if it is a runtime bug related to the fact that this is a root class. Cheers, David -- David Ayers - Team Austria Free Software Foundation Europe (FSFE) [] (http://www.fsfe.org) Join the Fellowship of FSFE! [][][] (https://fsfe.org/join) Your donation powers our work! || (http://fsfe.org/donate) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem with Gorm and GDL2
Hello Germán, Am Mittwoch, den 24.03.2010, 18:59 -0600 schrieb Germán Arias: I have GDL2 palette in Gorm, but when I start Gorm I get the error: objc runtime: cannot find class GDL2KVCNSObject and Gorm crash. Could you please open a bug report for this? I currently don't have a setup to test this myself. In GDL2 we had infrastructure in place to insure that our KVC categories had precedence to those in the GNU and NeXT runtimes. I /believe/ (but haven't checked) that the libobjc2 runtime may not support those techniques based on Categories in method lists. Richard was so kind to attempt to work around based on classes with the goal that this works with all runtimes. So please state which runtime you are using. The class is implemented in EOControl/EOKeyValueCoding.m. It is a root class. Maybe something in Gorm or in the runtime you are using is the reason why the class cannot be found. You can assign the bug to GDL2 for now, but I wouldn't be surprised if it is a runtime bug related to the fact that this is a root class. Cheers, David -- David Ayers - Team Austria Free Software Foundation Europe (FSFE) [] (http://www.fsfe.org) Join the Fellowship of FSFE! [][][] (https://fsfe.org/join) Your donation powers our work! || (http://fsfe.org/donate) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Question about GNUstep DL2
Hello everyone, IMHO the packaging for GDL2 could take into account the non-gui/gui scenarios and would look something like this: gnustep-dl2-nox(-dev) EOControl/EOAccess gnustep-dl2-gui(-dev) (depends on dl2-nox) EOInterface gnustep-dl2-tools(-dev) (depends on dl2-nox) EOPalette EOModeler DBModeler gnustep-dl2-sqlite-adaptor (depends on dl2-nox) gnustep-dl2-sqlite-adaptor-gui (depends on dl2-gui) gnustep-dl2-postgresql-adaptor (depends on dl2-nox) gnustep-dl2-postgresql-adaptor-gui (depends on dl2-gui) Wow... yes this is ugly... but I'm not sure if there is a way around it. The respective login panels depend on -gui. Yet if we lump them into single adpator packages, all usefull adaptors will pull in -gui and therefore we might as well lump everything together into a single gnustep-dl2(-dev) package. (well save the tools package). i.e. the alternative is: gnustep-dl2(-dev) EOControl/EOAccess EOInterface gnustep-dl2-tools(-dev) (depends on dl2) EOPalette EOModeler DBModeler gnustep-dl2-sqlite-adaptor (depends on dl2) [-dev shouldn't be needed] gnustep-dl2-postgresql-adaptor (depends on dl2) [-dev shouldn't be needed] But will install full -gui and X dependencies even if all you want is a a GSWeb based WebServer. Notes: - the adaptors (i.e. PostgreSQLAdaptor) should refrain from installing headers - the Renaissance dependency should be removed, at least in the mid term (I originally was very much for switching to R. but we haven't had the resources to actually leverage it, and I think it is more easily removed than to convert all the UI to R. and either I missed the release or we currently depend on non-released version.) Cheers, David -- David Ayers - Team Austria Free Software Foundation Europe (FSFE) [] (http://www.fsfe.org) Join the Fellowship of FSFE! [][][] (https://fsfe.org/join) Your donation powers our work! || (http://fsfe.org/donate) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSound Code Review
Am Mittwoch, den 29.07.2009, 21:23 -0500 schrieb Stef Bidi: David C.: I took a quick look at your comments and did some quick modifications... uploaded the results. There were a few things that will need a lot more work, so I left those as is for now. David A.: I am using threads and locks, and unfortunately it's the only way for me to get where I want to be (streaming audio data). If I understood your replies correctly, your suggesting using pthread instead of NSLock and NSConditionLock? David C. expressed some concerns on how I'm using the locks as well. Yes, well, almost... I am suggesting that you use the objc_thread threading abstraction layer in libobjc instead of NSThread. David C. is suggesting to use pthread directly and avoid the abstraction layer. I believe that David C. believes that all deployments we care about have a pthread library they /could/ use. I believe he believes both your code and GNUstep proper should simply use that independent of what the objc_runtime and the gcc runtime uses. I'm not sure whether he believes that gcc already uses pthreads under the abstraction layers for $(ALL_RELEVANT_PLATFORMS) or not. From his last reply I would infer that he may believe that we simply shouldn't have to care. He does believe, that by using pthreads directly we can make use of some optimizations / avoid inefficiencies that the abstraction layers introduce. I believe we do have to care. GNUstep currently doesn't define which platforms it supports. We simply do not know. I do know that the discussions on the mailing list is not an indication of what is in use. I also believe that the approach to bypass NSThread by using the abstraction layers is fairly common practice. Most use cases I know have a very limited interaction with the rest of the system and are often performance critical. They are written in plain C, so no messages are being passed, no notifications processed, just plain grunt work in C. This is also what Apple seems to be doing. Another scenario where threading implementations can be added to the executable are language bridges. Java, Ruby, Python... I'm not sure how JIGS/RIGS work but I have seen bridges that start a VM in a separate thread of the same process. The only way to keep the executable sane and debugable in my view is if all components share the native threading environment. The only way I see to make this possible is to use the abstraction layers. Of course I'd also like to see the optimizations that David C. is aiming at. I just don't believe the way to achieve it is by bypassing the abstraction layers. My approach would be to optimize the abstraction layers. But in the end all discussion is moot if no one writes patches. David C. seems to have sent patches. I definitely do not have the time to implement the approach I suggest, so I'll back away from the discussion, save clarifications wrt misunderstandings/misrepresentations. Cheers, David -- David Ayers Fellow of the Free Software Foundation Europe http://www.fsfe.org http://fellowship.fsfe.org ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSound Code Review
Am Mittwoch, den 29.07.2009, 08:25 -0500 schrieb Stef Bidi: On Wed, Jul 29, 2009 at 8:13 AM, David Chisnall thera...@sucs.org wrote: That said, a number of the locks in the code under discussion are in the wrong place, and NSConditionLock appears to be consistently used incorrectly. Can you elaborate, please? This is the first time I ever used threads and locks. Hmm... I had a look at: http://review.etoileos.com/r/117/ and maybe I'm just confused by the interface. If you are not using threads and locks, then please ignore me. Cheers, David -- David Ayers Fellow of the Free Software Foundation Europe http://www.fsfe.org http://fellowship.fsfe.org ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSound Code Review
Am Mittwoch, den 29.07.2009, 17:15 +0100 schrieb David Chisnall: On 29 Jul 2009, at 16:56, Wolfgang Lux wrote: If you spawn a POSIX (or Mach) thread in OS X and make Cocoa calls from this, without ever sending a notification informing the framework of this, then things work correctly. I do not believe that this is yet the case in GNUstep, but it ought to be. Actually, that's exactly what I meant. Do not use NSThreads but an underlaying abstraction that's compatible with the actually thread implementation to avoid sending the notification. I haven't checked but I believe we may already be doing this (or maybe it was some support library, I'm not sure anymore). With respect to the pthread patch for GNUstep, I'm still not convinced that GNUstep only runs on platforms which are configured to use pthreads by default by the objc runtime. Yet I never got around to checking the history. GNUstep should use whatever threading library gcc was configured for. This is what gthreads does. Simply assuming pthreads will work for 95% of the cases yet the other 5% will case an inordinate amount debugging headaches when two threading libraries exist in parallel. If this abstraction needs to be optimized then the patches should go to libobjc/gcc. Cheers, David -- David Ayers Fellow of the Free Software Foundation Europe http://www.fsfe.org http://fellowship.fsfe.org ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSound Code Review
Hello Stefan, Am Montag, den 27.07.2009, 20:44 -0500 schrieb Stef Bidi: I really just want to get this out there so that I can get more eyes on it... this is my first time working this in-depth with GNUstep, so I'm sure mistakes were made (I'm just hoping they aren't massive). Maybe I'm just reading the code incorrectly, but will playing a sound make the application multi-threaded wrt the OpenSTEP/Cocoa API (and thereby create all the lazy locks registered for the NSWillBecomeMultiThreadedNotification)? Triggering locks will give is quite a performance hit on applications which would otherwise be single threaded. I think this really needs to be avoided. Note I'm not say that the process can't become multi-threaded at all. It's just if it really must it should do so at a lower level. I'm not sure if the ObjC-runtime wrappers can be used with triggering the notification. But GCC's gthread is probably a safe abstraction, that is if clang co also support that API. Cheers, David -- David Ayers Fellow of the Free Software Foundation Europe http://www.fsfe.org http://fellowship.fsfe.org ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [cfe-dev] Blocks runtime
Am Donnerstag, den 11.06.2009, 12:36 +0100 schrieb David Chisnall: Clang definitely needs more testing, but I've been using it recently to compile some of the Étoilé frameworks and they seem to work nicely. I've recently been playing with some (very preliminary so far) support for speculative inlining, so if the compiler can correctly guess the called method then we can inline it and avoid the call overhead. Inlining /method/ calls? How does that work with categories? (I'd be happy with a link...) -- David Ayers Fellow of the Free Software Foundation Europe http://www.fsfe.org http://fellowship.fsfe.org ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [cfe-dev] Blocks runtime
Am Donnerstag, den 11.06.2009, 17:38 +0100 schrieb David Chisnall: On 11 Jun 2009, at 17:16, David Ayers wrote: Am Donnerstag, den 11.06.2009, 12:36 +0100 schrieb David Chisnall: Clang definitely needs more testing, but I've been using it recently to compile some of the Étoilé frameworks and they seem to work nicely. I've recently been playing with some (very preliminary so far) support for speculative inlining, so if the compiler can correctly guess the called method then we can inline it and avoid the call overhead. Inlining /method/ calls? How does that work with categories? It still calls objc_msg_lookup (you can avoid this with the Étoilé runtime but not with the GNU one), but if the result is the expected function pointer then it uses the inline implementation instead. In some situations, the inline version will benefit a lot from constant propagation. In others you're just saving the call overhead. Cool! Thanks. Cheers, David -- David Ayers Fellow of the Free Software Foundation Europe http://www.fsfe.org http://fellowship.fsfe.org ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Exception handling in clang
Am Freitag, den 08.05.2009, 14:04 +0100 schrieb David Chisnall: Is anyone using @synchronized with GNUstep? If so, where do you get your implementations of the two functions which acquire and release a mutex identified by a given object? Not with the GNU runtime AFAIK... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23680 Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Small change in NSObject.m ASM needed for PowerPC build
Am Sonntag, den 03.05.2009, 17:30 +0100 schrieb David Chisnall: On 3 May 2009, at 17:26, Riccardo Mottola wrote: David Chisnall wrote: On i386, you need -march=i586 or higher for this to work. The existing code will break at runtime, rather than link time, on an 80486 and earlier, and so I assume (from the fact no one has complained) that no one is using GNUstep on a 386/486. Well, how old is that code? Up to about a year ago I built and used GNUstep on a 486-class machine, although the CPU was not genuine intel but a compatible processor which was based on 488 ISA, it did work... As I said in my other email, I was mistaken about when the atomic ops were introduced. They should work with -march=486, not just - march=586 - it works for me with no manually-set CFLAGS or modified GNUmakefile, on GCC 4.2. I could imagine that the distribution kernels/assemblers were configured to support only a subset of the features -march=486 or lower. I think the way to move forward is to add a configure option/test which would fallback to a more portable yet less efficient implementation. I can help with the configure.ac snippets if you wish. But wrt to the correct implementation I'd like to defer to you. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
Am Donnerstag, den 02.04.2009, 14:02 +0100 schrieb David Chisnall: The error seems to be in NSDecimal handling. I suspect that this structure is just big enough to be split between registers and the stack, which may cause problems. Has anyone tested this on Linux/ x86-64? If the test doesn't fail there, then something strange is going on. I can confirm that a) the test also fail on x86_64-unknown-linux-gnu b) configure warns about *** Warning The mframe software has not been ported to x86_64. Using information from unknown. *** Warning The mframe software has not been ported to x86_64-linux-gnu. Using information from unknown/generic. c) the build warns about Compiling file mframe.m ... mframe.m: In function ‘mframe_build_signature’: mframe.m:160: warning: field precision should have type ‘int’, but argument 3 has type ‘long int’ (Though I'm not sure whether those warnings are relevant to the test suite failure yet). So I guess it's fair to say that gnustep currently does not fully support x86_64-unknown-linux-gnu yet. I'll try to look into it soonish if no one beats me to it. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
Am Freitag, den 03.04.2009, 11:19 +0200 schrieb David Ayers: Am Donnerstag, den 02.04.2009, 14:02 +0100 schrieb David Chisnall: The error seems to be in NSDecimal handling. I suspect that this structure is just big enough to be split between registers and the stack, which may cause problems. Has anyone tested this on Linux/ x86-64? If the test doesn't fail there, then something strange is going on. I can confirm that a) the test also fail on x86_64-unknown-linux-gnu b) configure warns about *** Warning The mframe software has not been ported to x86_64. Using information from unknown. *** Warning The mframe software has not been ported to x86_64-linux-gnu. Using information from unknown/generic. c) the build warns about Compiling file mframe.m ... mframe.m: In function ‘mframe_build_signature’: mframe.m:160: warning: field precision should have type ‘int’, but argument 3 has type ‘long int’ (Though I'm not sure whether those warnings are relevant to the test suite failure yet). So I guess it's fair to say that gnustep currently does not fully support x86_64-unknown-linux-gnu yet. Just to put this in perspective... passing complicated structs like NSDecimal by value (and that via an NSProxy) is not something that's done very often... so this failure shouldn't be overrated... even though I think it should be fixed. I'll try to look into it soonish if no one beats me to it. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
Am Mittwoch, den 01.04.2009, 15:07 +0100 schrieb Pete French: Would it be possible for you to check whether GNUstep works with libffi? On FreeBSD/i386, it defaults to using ffcall, but works better with libffi (i.e. doesn't randomly corrupt the stack when you pass NSInvocations between threads). You probably need to explicitly specify /usr/local/include and /usr/local/lib as ffi lib/include directories in configure. Using the latest SVN this now works out of the box with just 'configure' and the libffi port installed. So no need for ffcall on this platform anymore. This sounds great! Could also check whether the NSProxy Tests pass? i.e. checkout http://svn.gna.org/svn/gnustep/tests/testsuite/trunk and run: ./runtest.sh base/NSProxy/test01.m Thanks! Cheers, David PS: the log file is called tests.log ... please post it. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
FSF GCC ObjC(++) Support
Am Mittwoch, den 01.04.2009, 00:48 +0100 schrieb David Chisnall: Well I'm not too fond of yet another compiler/runtime to support... but if it is what apple will be using and it will also replace the current apple runtime, I'm glad someone is working on it. But I think will need insure that our current main compiler / runtime stays in (or is restored to) a decent condition. Neither am I, but no one on the GCC side seems to be working on Objective-C. I tried to persuade the FreeBSD port maintainer to enable ObjC++ recently in the default build, and his reaction was that ObjC was basically unmaintained in GCC and ObjC++ was in an even worse state. Someone at Apple created some patches over a year ago for adding support for properties to GCC on the GNU runtime. Are they merged yet? No. Is anyone planning on merging them, or rewriting their functionality? Not as far as I can see. Do any of the GCC folks outside of Apple give a dam about Objective-C? Not that I can tell; we had a /stable/ release ship generating errors with any Objective-C program containing constant strings a while ago, and the GCC response was 'Objective-C is not a priority'. If we continue to treat GCC as our main compiler then run the risk that we are depending on a project which has no interest in maintaining the features we need. [snip] I currently have no insight into whether clang is a viable alternative to the FSF GCC ObjC(++) support. I'm glad that someone so close the GNUstep project is actively working on support GNUstep. I also have no insight on how portable clang is compared to FSF GCC ObjC++ (ie. we'd be back to defining and testing the platforms GNUstep should care about wrt to clang as I suggest for libffi). For production systems, I certainly will prefer the FSF GCC at least until clang has been packaged by major distributions. I understand the the price I need to pay is to either pay someone to maintain FSF ObjC support, or do it myself. Currently I'm trying to take the latter route and try to finance that work via my actual business [which is ERP implementations and not compiler/runtime/GNUstep development... but then again I doubt that's hardly anybodies business on this list] (well, I haven't talked to Andrew P. about his rate yet ;-) ). Yet I simply cannot offer meaningful help for ObjC++ since I'm simply not C++ literate. So I'm hoping that someone will step up help maintain that at least until other solutions become widely available. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GCC Runtime Licensing
Am Mittwoch, den 01.04.2009, 11:39 +0100 schrieb David Chisnall: On 1 Apr 2009, at 06:24, David Ayers wrote: Indeed I believe this concern has just been addressed: http://www.gnu.org/licenses/gcc-exception.html http://gcc.gnu.org/ml/gcc/2009-04/msg5.html Thanks for the clarification. As I read it, this means that the exemption only applies to code compiled with GCC. You have permission to propagate a work of Target Code formed by combining the Runtime Library with Independent Modules, even if such propagation would otherwise violate the terms of GPLv3, provided that all Target Code was generated by *Eligible Compilation Processes*. You may then convey such a combination under terms of your choice, consistent with the licensing of the Independent Modules. A Compilation Process is Eligible if it is done using GCC, alone *or with other GPL-compatible software*, or *if it is done without using any work based on GCC*. For example, using non-GPL-compatible Software to optimize any GCC intermediate representations would not qualify as an Eligible Compilation Process. This is bringing libgcc (and GNU libc?) into line with the existing exemption on GNU libobjc, which is exactly the opposite of what I wanted. This means that it is not possible, for example, to compile any GPLv2 program with any other compiler that uses the GNU runtime libraries. Is clang (I gather it's licensed under the MIT license?) not GPL-compatible? Note that it also doesn't specify a specific version of the GPL to be compatible with. Also note it talks about software used for the compilation process ie. IDE tools... and not the code being compiled. In fact, this entire exemption is potentially problematic, because it explicitly excludes preprocessors, which means that when GCC runs the preprocessor and copies inline functions from the libobjc headers into programs the exemption does not apply. This makes it impossible to use recent versions of GCC to compile GNUstep, since GPLv3 is incompatible with LGPLv2. The LGPLv2 is compatible with GPLv2. The exemption I would like to see is: - Use of the headers is allowed for any purpose (you can't copyright an interface, so this only applies to the very small number of inline functions and macros defined in the headers). - Linking is permitted. IANAL and jurisdictions vary but stating that you can't copyright an interface is a broad statement I'd like to be true but by no means would advise anyone to rely on. This is the old exemption from libgcc: In addition to the permissions in the GNU General Public License, the Free Software Foundation gives you unlimited permission to link the compiled version of this file into combinations with other programs, and to distribute those combinations without any restriction coming from the use of this file. (The General Public License restrictions do apply in other respects; for example, they cover modification of the file, and distribution when not linked into a combine executable. This would be absolutely perfect for libobjc. I don't understand what they hope to gain by changing it, other than to force us to stop using GNU libobjc. I'm not sure who you mean by us but I for sure am fine with using the license. But if you have issues I think the correct place to discuss this is licens...@fsf.org (or the possibly the http://www.fsfeurope.org/projects/ftf/ftf.en.html if your interested in the a European perspective). Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Deprecating ffcall
Am Mittwoch, den 01.04.2009, 11:27 +0100 schrieb David Chisnall: On 1 Apr 2009, at 09:05, Fred Kiefer wrote: This may sound strange, coming from my side as I already advocated the use of libffi when it still supported less platforms than ffcall, but I strongly advocate that we phase out support for ffcall very slowly. Remember that only two years ago somebody suggested that we should drop support for libffi :-) In that case, can someone add support for moving the return value address off the stack to GSFFCallInvocation? At the moment, certain uses of GSFFCallInvocation that work on Cocoa cause stack corruption on GNUstep, as I mentioned in an earlier email. Could I ask you for a bug report and/or a test case? It's stuff like this that we really need in our test suite. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
Am Dienstag, den 31.03.2009, 22:13 +0100 schrieb David Chisnall: On 31 Mar 2009, at 20:00, David Ayers wrote: I'm mostly concerned about keeping support for deprecated API which was 1) part of either the OpenStep specification. 2) part of OPENSTEP 4.2 (widely distributed cross platform implementation of OpenStep) 3) part of WebObject 4.5 (last cross platform implementation of OpenStep) I'd agree with this. -forwardForProxy:selector:argFrame: is not part of OpenStep. I don't know if it was part of OPENSTEP 4.2 or WO - my impression was that it was a private GNUstep method that had since been superseded by the ffi stuff. Indeed... and I don't mind removing forwardForProxy:... as long as we can continue to support -forward:: for those archs that still still work with it...unless we officially want to deprecate support those archs. If we can implement the argframe approach (ie. -forward::) via libffi then we could also resolve some long standing libobjc issues. Yet I'm still unsure if it can be done at all. I'm also a bit concerned about statements like I believe ...[some code]... never worked correctly as we simply do not know who is using it and whether it works for production code. Mostly one finds out that things stopped working when it's too late... Reading the GCC and GNUstep lists, __builtin_apply() and friends are in the 'it may work, but if it stops working randomly then don't be surprised' category. Every time someone asks a question about them on the GCC lists, the reply seems to be 'don't use them unless you absolutely have to'. I am only proposing that we deprecate bits of GNUstep that are not in code paths that are used in the standard configurations and have not been for several years, including some parts that contain comments indicating that they probably don't work. OK, but the consequence is deprecating platforms. And that should be stated and communicated as such. I'm not too fond of doing that without very good reasons. (For example currently it seems that gcc 4.5 may be breaking obj-c++ in gcc because Apple isn't maintaining it anymore, and I hardly know anything about c++ to be of much use here... I'm am trying to takle some of the objc/libobjc bits.) This is one of the reasons I want to get clang supporting GNUstep. C+ + support in clang is still very immature, but it is improving at a rapid pace, and Apple has several people working on it full time. Because it uses a unified parser, the Objective-C++ front end supports everything that C++ one does. All we need to do to be able to make use of this is ensure that the CGObjCGNU class is implemented correctly. Well I'm not too fond of yet another compiler/runtime to support... but if it is what apple will be using and it will also replace the current apple runtime, I'm glad someone is working on it. But I think will need insure that our current main compiler / runtime stays in (or is restored to) a decent condition. I'd suggest modifying the configure script. The ffcall implementation doesn't work safely with EtoileThread, since it does not provide a mechanism for preventing the invocation from trampling over a random stack address if it lasts longer than the call frame. When I reported this, there was talk of deprecating ffcall, since there don't appear to be any platforms where GNUstep and ffcall work but libffi doesn't. I would suggest that for the next release we require libffi and see if anyone complains. Where do you get the information that there don't appear to be any platforms where GNUstep and ffcall work but libffi doesn't? IIRC peoples mileage varies. But indeed we need to start documenting which works with which. ... More recently, I've been working on implementing the ObjC 2.0 runtime API (supported by Apple for both their new and old runtimes) on top of the GNU one. You can see the current version here: http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Languages/RuntimeAbstraction/ At some point, I'd like to push this up to GNUstep[1] and have the Apple runtime APIs properly supported. Now that Apple has deprecated posing and defined a stable public API for the runtime, I would imagine a lot of programs are going to start using it. I think the proper place to put this is FSF libobjc. I'd support a request to dual-license the respective files. (Not that I have any real clout but if we as a project request it, maybe are chances are not that bad.) Has anyone heard anything from the FSF about relicensing the GNU runtime? It is currently GPL with an exemption that only applies if code is compiled with GCC. I was told about a year ago that it would be moved to the same exemption as libc (which allows linking of any code), but haven't heard anything since then. I'm not really interested in working on adding Objective
Re: ABI Compatibility (was Re: Installation woes for the average user...)
Hello Xavier,
Am Dienstag, den 10.03.2009, 17:49 +0100 schrieb Xavier Glattard:
I'm sorry, i still can't see any problem.
NSAllocateObject is implemented as this : (NSObject.m:767)
size = aClass-instance_size + extraBytes + sizeof(struct obj_layout);
new = NSZoneMalloc(zone, size);
Then the extra bytes are allocated always _after_ the class ivar,
whatever the class is : the parent class or a subclass. If you get
isa-instance_size (as *you* did) you find the extra bytes.
It is true that the overall size of the instance is correct...
parent class ayout:
{
{ // the instance ivar
int a;
}
{ // the extra ivar
int a_ext;
}
}
subclass layout:
{
{ // the instance ivars
int a;
int b;
}
{ // the extra ivars
int a_ext;
}
}
This is the same behavior than 'classic' external ivars, but the memory
is allocated along with the instance itself (remember: the question is
'no extra malloc call'). The pointer to external ivars is not stored as
is, but is computed with self and instance_size. Still an 'extra load',
but not more than with a compiler-side solution. I even think this is a
'hand made' non-fragile ivar system, with no need for compiler support.
And the alignment issue seems to be solved with padding in
NSObject.m:334-371
All true but you need consider the assembler code that the compiler
emits to access the ivar in each class. And here the parent and the
subclass will disagree on what the offset to a_ext is.
This offset is currently an offset fixed at compile time by the
compiler's calculation of:
struct {
@defs(ParentClass)
} *obj;
obj[1] /* the address of a_ext */
which cannot take into account the ivars of potential subclasses, which
will be at that exact same address (i.e obj[1] == b).
It takes the non-fragile ivars to replace the fixed value (calculated
and emitted by the compiler) into a lookup to the actual offset/location
of the value. This mechanism can only be provided by a newer compiler
emitting that lookup code instead of using the fixed offsets.
Hope that makes it clear why using the extra data prevents subclasses
from adding ivars.
Cheers,
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: ABI Compatibility (was Re: Installation woes for the average user...)
Am Freitag, den 06.03.2009, 06:17 + schrieb Richard Frith-Macdonald: I feel we probably need to break things in trunk during the development cycle to get a reaction and some suggestions from other people. For instance I asked for ideas about the change to using NSUInteger,NSInteger, and CGFloat, and I adopted your idea of a #define to retain the old style behacvior, but since then I've seen no feedback about making this change work with gui/back and other apps. What I probably need to do is switch that code to use the new Apple behavior by default, deliberately breaking 64bit systems so that people will do something about it, or will at least sned specific bug reports for me to deal with. FWIW, I think I'm fine with changing the default, yet hope the other option remains. But since you said you received no feedback I want to reiterate another suggestion: Instead of: #if defined(GS_64BIT_OLD) typedef int NSInteger; typedef unsigned intNSUInteger; typedef float CGFloat; which produces a lot of compiler warning for code targeting both GNUstep and legacy API, would you consider: #define NSInteger int; #define NSUInteger unsigned int; #define CGFloat float; the bonus: it stops the warnings: Code targeting older API's will compile without the noise. the drawback: it stops the warnings: Code being my not be upgraded to use the new types so that future versions will be compatible with 64 bit. Personally I can understand if you believe the #define may be worse and I can surely keep that patch locally. But then again, anyone wanting to stay up to date will hardly use the define/configure option. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
MacOS X 10.5 API [was: Emacs 23.x from CVS 20090228]
Am Dienstag, den 03.03.2009, 08:49 + schrieb Richard Frith-Macdonald: It would be good if people could contribute patches to update core libraries (essentially to use NSUInteger, NSInteger, and CGFloat everywhere in the external API rather than using unsigned int/long, int/long, or float). Generally speaking this should make no different to the ABI on 32bit systems, but it's going to be a fairly big upheaval on 64bit systems. So for applications that still target earlier API's from Apple and there for use the old type, we would producing a whole lot of warnings, wouldn't we? If the ABI is on 32 bit is compatible, would it be easy/acceptable to replace the typedef's with #defines on (controlled by a preprocessor option) so that we can avoid these warnings? Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Top level menu spacers [was: Re: [Gnustep-cvs] r27911 ...]
Am Freitag, den 27.02.2009, 09:24 + schrieb Richard Frith-Macdonald: On 27 Feb 2009, at 09:03, Fred Kiefer wrote: I am not sure about the separator items. I fully agree that they don't look great in our current drawing style. But the idea of structuring even a vertical a menu seems correct to me. We could try to replace the separator item drawing with something that just displays a vertical or horizontal line, this will make the menu item size computation a bid harder, but surely looks a lot better. Now we have two differing opinions. How to proceed from here? Are there any other points of view out there? On the issue of spacers ... I think we need to keep the spacer items in the menu so that we retain all the information about them and can therefore switch between horizontal and vertical layouts repeatedly and consistently. However, horizontal and vertical menus should draw them differently of course. A simple option would just be for the drawing code to treat the as if they don't exist when drawing a vertical menu ... ie make them occupy zero space on screen. Visually this would probably be best. I agree that spacers at the top level (actually independent of whether vertical or horizontal layout) are unexpected to me. Yet I'm not sure whether they should categorically be disabled, or whether they could be tagged as automatically merged by the layout engine and only automatically disable their display when they are thus tagged. This would allow explicit spacers to remain. [I'm not sure whether it's really worth the work but I just wanted you to consider it.] Now the rendering of top-level spacers should probably be a theme hook. And as long as we have the NeXTstep UI as default, maybe someone could check what top-level spacers looked like in OPENSTEP. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Compatibility breakage involved in upgrading to the MacOS-X 10.5 API
Am Sonntag, den 22.02.2009, 09:55 + schrieb Richard Frith-Macdonald: Obviously that breaks binary compatibility on 64bit systesm, but perhaps less obviously it also breaks source code compatibility in quite a few places (wherever the API changes from passing a pointer to a 32bit integer to now be passing a pointer to a 64bit integer), and will cause compiler warnings wherever we assign a 64bit integer to a 32bit one. And those warnings should be taken seriously in any heterogeneous environment and the source code adapted accordingly. Possibly there will also be issues with archived data (including gorm files). IIRC, the actual size of the archived data is encoded into the archive and so if we heeded that information when decoding rather than the expected target size, we should be fine decoding the old values. But it seems that we are currently very strict in what we expect. And we have a bug... NSInteger is typedef'ed to gsaddr (which is typed def to gsuaddr) instead of gssaddr! So we are actually currently encoding unsigned integers when encoding NSInteger. So, how should we go about this? Do we update GNUstep-base, accepting that parts of the gui and back libraries (and applications and data) will be broken by the change, then fix breakage as we find it, or do we attempt to do some sort of coordinated change? I think we need to fix the NSInteger define. I think we should believe the archive/stream which were are decoding and convert into the expected type. We could warn if they types don't match but I don't think we should abort unless the types are so incompatible that we cannot sensibly convert. If the latter, what would we try to coordinate, how would we manage it, and how would we test it? I've attached a small test case that should test NSInteger... But I think for the test we want, we should create/commit architecture specific files in the test suite which should always decode to expected values on any platform. Cheers, David ArchivingUInteger.tar.gz Description: application/compressed-tar ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Compatibility breakage involved in upgrading to the MacOS-X 10.5 API
Am Sonntag, den 22.02.2009, 12:50 + schrieb Richard Frith-Macdonald: But it seems that we are currently very strict in what we expect. And we have a bug... NSInteger is typedef'ed to gsaddr (which is typed def to gsuaddr) instead of gssaddr! Not in my (as yet uncommitted) code. Are you referring to the typedef or also about the strictness of decoding? Because currently anything encoded with NSInteger before your changes will not be decoded to the new NSInteger unless the sanity checks are removed. So we are actually currently encoding unsigned integers when encoding NSInteger. Not really an issue ... since my changes to move everything over to NSInteger and NSUInteger haven't been committed yet, and when they are the commit will also include my fix to the typedef along with various other related fixes. Well yes... for any newly created archive... but what's with the archives that currently already contain NSInteger... the are currently encoded with 'I' and our decoding will expect 'i' after you commit. So, how should we go about this? Do we update GNUstep-base, accepting that parts of the gui and back libraries (and applications and data) will be broken by the change, then fix breakage as we find it, or do we attempt to do some sort of coordinated change? I think we need to fix the NSInteger define. I think we should believe the archive/stream which were are decoding and convert into the expected type. We could warn if they types don't match but I don't think we should abort unless the types are so incompatible that we cannot sensibly convert. Really archiving/encoding/decoding should not be an issue ... except for errors in conversion where perhaps we encode an NSInteger and decode with a pointer to the wrong type: eg. int val; [coder decodeValueOfObjCType: @encode(NSInteger) at: val]; Which could decode an 8 byte value into a variable which is only 4 bytes long. That sort of coding error is easy to make when converting a lot of code from using one type to another ... eg 'val' is actually an ivar declared in a separate header file, and you think you changed it from int to NSInteger, but forgot. We really need to check the code for any places where we pass pointers. I understand that you are worried about a different issue. But please be aware that changing the NSInteger typedef will also make archives containing them unloadable. If the latter, what would we try to coordinate, how would we manage it, and how would we test it? I've attached a small test case that should test NSInteger... But I think for the test we want, we should create/commit architecture specific files in the test suite which should always decode to expected values on any platform. Thanks .. I think we already have such tests for basic types. What we don't have is an exhaustive set of coding tests for every coding capable class. It would be good to add more. This case is special in that it intentionally encodes as int and decodes as NSInteger (and encodes as unsigned int and decodes as NSUInteger) and vice versa. [Well if you chose the correct #if] Now it may not be a big issue at all since we hardly @encode(NSInteger). The only instance I found is NSPointerArray which I believe has never been released. There are a few odd cases in the API where pointers are used. For instance, you can get the indexes from an NSIndexSet into a buffer. Now, if your code makes the buffer big enough for 10 unsigned int indexes (40 bytes) and retrieves them, but the base library is changed to use NSUInteger and copies 10 indexes (80 bytes) into the buffer, you have a problem. Indeed we also need to worry about this class of issues. Those are the sort of issues I'm most concerned about, as I *hope* that our archiving/coding is architecture independent anyway (NSArchiver and NSUnarchiver and all coding using them certainly was architecture independent at one point). Well.. this is not arch dependent (well with the exception that on some archs 'int' may be unsigned but I don't think we support them anyway). But I get an exception with the test case encoding as int and decoding as NSInteger, which implies to me that we are pretty strict in what we expect during decoding. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Auxiliary makefile fragements
Am Mittwoch, den 18.02.2009, 16:24 +0100 schrieb Nicola Pero: It may be good to review the linking flags/variables, though, and I wouldn't mind being able to do something like $(GNUSTEP_MAKE_CHECK_REQUIRED_LIBRARY Renaissance) $(GNUSTEP_MAKE_CHECK_REQUIRED_LIBRARY EOControl) which would produce a clear user warning if these are not there. (just an idea) Just to be sure we are on the same sheet of paper... What I requested was a way to test the availability of a GNUstep package during configure. I guess that could be altered to a 'make' check, but then that logic would be executed a lot more often than need be. I'm hoping this can be achieved via gnustep-config. Now if you also want a way to test this in -make then that's fine by me, but it wasn't what I was looking for. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Auxiliary makefile fragements
Am Dienstag, den 17.02.2009, 12:41 -0500 schrieb Gregory Casamento: One thing I think I should also mention is that, in gnustep-make, there seem to be fragments preinstalled for gswapp. Shouldn't these be moved out of gnustep-make and only be installed if and only if you install GSWeb etc, otherwise we have gnustep-make support for things which are not installed at all. There are other examples aside from GSWeb, I'm just using it as an example. The gsweb fragments that are part of -make are actually infrastructure fragments which are different from the convenience fragments I'm currently talking about. In face gsweb, when installed, installs it's own set of convenience fragments. The infrastructure fragments deal with special types of wrappers called components (WO/GSWCompoents) which need to be installed/uninstalled in the correct places. As far as I know, -make currently does not support Auxiliary infrastructure make file fragments. I'm not sure if it should since I believe you need to know a lot about -make's internals to maintain them. On the other hand I understand that it's a burden for Nicola since he needs to be aware of what these special wrappers are and how they should be handled. But in the end, I believe that the infrastructure might be tied much closer to the overall -make (i.e. FHS) logic, that I simply isn't feasible to export that logic to external packages... Nicola, what do you think? Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
Hello Gregory, Am Freitag, den 06.02.2009, 00:33 -0500 schrieb Gregory Casamento: What should NSExceptionMask be implemented as? SHould it be a boolean that determines if we should allow the application to continue or not? Did you read the link that Richard provided? http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/Exceptions/Exceptions.html http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/Exceptions/Tasks/ControllingAppResponse.html Table 1 Exception-handling constants and defaults values: Type of Action / Constant / Value for defaults -- Log uncaught NSExceptions / NSLogUncaughtExceptionMask / 1 Handle uncaught NSExceptions / NSHandleUncaughtExceptionMask / 2 Log system-level exceptions / NSLogUncaughtSystemExceptionMask / 4 Handle system-level exceptions / NSHandleUncaughtSystemExceptionMask / 8 Log runtime errors / NSLogUncaughtRuntimeErrorMask / 16 Handle runtime errors / NSHandleUncaughtRuntimeErrorMask / 32 That is to say * NSExceptionMask = YES - report all exceptions, but continue anyway... * NSExceptionMask = NO - current behavior That would be a GNUstep extension and in my view more confusing than the current behavior. If so, I have a patch almost ready. I'll submit it to the group prior to committing it since a change that is this important needs to have some amount of consensus. That's good. Yet I must admit that I find it a bit unsettling that DBModeler (who's eomodeld files are comparatively trivial) may abort while GORM (who's gorm/nib files contain very complex relationships) my silently corrupt it's files due to bugs in third party palettes. I just want you to consider this very carefully with respect to the default setting of GORM. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
Am Mittwoch, den 04.02.2009, 23:44 -0800 schrieb Matt Rice: On Wed, Feb 4, 2009 at 9:50 PM, David Ayers ay...@fsfe.org wrote: I still believe that handling generic handling of exceptions in the runloop is a dangerously wrong and an implementation detail that we shouldn't try to be compatible with. But others may disagree. I definitely agree with this, but wanted to toss out another point of view in the same vein in an editor application, say that there is an exception when working with a single document (i'm seeing something in DBModeler when closing certain documents which I haven't managed to fix yet unfortunately) so i'm getting an exception when an error occurs in a single document, but the entire application crashes, now i should probably add some exception handling somewhere (not exactly sure where, probably all over the place...) to my app but haven't figured out where yet, but until I do, an exception in a single document means that all open documents close, and could potentially lose changes in other unsaved documents which are open. Indeed, an exception could cause data corruption in a single document. It may not cause any data corruption at all. But it could also cause corruption in all documents. We simply cannot tell. DBModeler should handle Exceptions where external or internal code can reasonably be expected to raise an exception. It should not be handle defensively due to unimplemented / buggy code in DBModeler or GDL2 (or any other dependent code). For development I think it's fine to use: defaults write DBModeler NSExceptionHandlingMask 63 Maybe we should also log this workaround the when we crash, so that a user can also decide to use it for future crashes. But I guess that means that we need to link a against the ExceptionHandling framework (which we still need to create for GNUstep even if it merely contains this single feature for now). That way the user can set the preferred handling. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
Am Mittwoch, den 04.02.2009, 23:52 -0500 schrieb Gregory Casamento: The attached test program does not crash on Mac OS X when the button is pressed, but does crash on GNUstep. The button calls the action: method in Controller which immediately throws an exception. I believe this confirms that GNUstep's behavior is inconsistent with Cocoa. I can test on OpenStep, but I suspect that the behavior is the same there as it is on Cocoa. FWIW, IIRC this inconsistency was intentional an I believe for a very good reason. I thought we had documented it at the time but I can't dig it up easily right now. An uncaught exception indicates that the application is in an undefined state. For certain type of applications (like viewers) this can be ignored. For editor application this could mean that the document being edited could be corrupted and saving it cause data corruption. This thread is the only reference I found in which we suggested some type of Developer-Mode which indicates that I know what I'm doing, let me debug, will you?!. http://lists.gnu.org/archive/html/discuss-gnustep/2004-10/msg00092.html I still believe that handling generic handling of exceptions in the runloop is a dangerously wrong and an implementation detail that we shouldn't try to be compatible with. But others may disagree. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
NSComparisonMethods / compare:
Hello, I just noticed that new compatibility methods were added to -base which use the compare: method in their NSObject implementation. From memory using compare: on incompatible types is undefined behavior. I.e. a compare: method may assume that the the argument is of compatible class and may reference instance variables of the parameter directly. In fact our NSString implementation assumes that. I haven't found any documentation about this requirement, and I'm not sure it exists on Cocoa. But I wonder whether we should document this requirement (i.e. that it's the users responsibility to insure that the compared objects are compatible, since I keep running into such issues when people use these values and compare NSStrings with NSNumbers or NSNull instances resulting in invalid memory access. Cheers, David PS: We deprecated NSObject's compare: back in 2003, would anyone mind if I remove the declaration in our NSObject.h for the following release? [I would wait another stable release cycle before removing the implementation.] Maybe the same should be done for the other deprecated methods. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSBitmap+Icns.m on Sparc
Am Mittwoch, den 05.11.2008, 08:45 +0100 schrieb Fred Kiefer:
Riccardo is having trouble with the new icns loading code on sparc
architecture. I think this is caused by pointers into the data structure
not being properly aligned for this processor, but as I am no expert in
this area it would be great if somebody could have a look before I start
experimenting around.
The problem he gets is:
Program received signal SIGBUS, Bus error.
0x0fec17e4 in icns_import_family_data (size=33658, bytes=0x9a6e000 icns,
iconFamily=0xf7fca660) at NSBitmapImageRep+ICNS.m:270
270 while ((data end) element-elementSize)
(gdb) p data
$1 = (icns_byte_t *) 0xdce6372 t8mk
(gdb) p end
$2 = (icns_byte_t *) 0xdcea37a
(gdb) p element-elementSize
$3 = 16392
Given the definitions of the types:
typedef unsigned char icns_byte_t;
typedef unsigned long icns_size_t;
typedef struct _icns_type_t {
char c[4];
} icns_type_t;
typedef struct _icns_element_t {
icns_type_t elementType;
icns_size_t elementSize;
} icns_element_t;
typedef struct _icns_family_t {
icns_type_t resourceType;
icns_size_t resourceSize;
icns_element_t elements[1];
} icns_family_t;
I would assume the straight forward fix (if indeed it is an alignment
issue is to add padding to icns_element_t to the sizeof(long) boundry
which is 8 byte on most 64 bit archs. I.e.
typedef struct _icns_element_t {
icns_type_t elementType;
char padding[4];
icns_size_t elementSize;
} icns_element_t;
But yeah... maybe we should just look at their code...
Cheers,
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSPropertyListSerialization fails with OpenStepFormat on OSX
Am Sonntag, den 26.10.2008, 22:07 +0100 schrieb David Wetzel: David Wetzel wrote: add [+NSPropertyListSerialization dataFromPropertyList:format:errorDescription:] to base-additions, call the Apple implementation if format != NSPropertyListOpenStepFormat if code runs on Apple. What I cannot understand is your proposed solution to this problem. We should replace the method in the GNUstep extensions, but still call the Apple version of the same method in some cases? There may be way to do this, but this is clearly a dangerous proposal. Why? It will do the same like on a GNUstep or OPENSTEP system. Wouldn't it be easier to just convert property lists written on new Macs to be used on old installations of EOModeler? GNUstep should be able to do that conversion. I want to run DBModeler.app on OSX and read + write .eomodeld files in a format all original EOModelers understand. Otherwise DBModeler is useless. Let me put that into perspective. DBModeler is would not be useless if we changed the plist format. Yet it could not be used to write EOModel files that are understood by WO45 anymore, and the reason why some of us are so picky about WO45 compatibility, is that we still have deployments with WO45 so we need to test within a WO45 development environment to insure compatibility. Now to a possible resolution. Instead of a category overriding Foundations implementation of NSPropertyListSerialization dataFromPropertyList:format:errorDescription: I'm wondering whether a category like: dataInOpenStepFormatFromPropertyList:errorDescription: would be acceptable for -base-additions... I guess we could also put in GDL2-EOControl if no one else feels a need to be able to write old style property lists... on OS X that is, since -base does still support that format an hopefully will continue to do so. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Deadlock in NSLog
Am Freitag, den 01.08.2008, 12:06 +0100 schrieb David Chisnall: It appears that GNUstep is using the ObjC runtime mutex, which tries to emulate a recursive mutex using a non-recursive mutex. It looked like there was a potential for deadlock in here when I looked at the code a few months ago. Since GNUstep depends on pthreads anyway, it might be better to use the pthread functions directly, rather than going through a buggy abstraction layer. I don't believe that bypassing the objc abstraction layer is a good idea. GNUstep and GNU ObjC have been ported to platforms that may not be supported be pthreads. In particular I remember that FreeBSD at on point used a different threading library that claimed POSIX/pthread compatibility. I would instead try to create a libobjc test case a report a bug against libobjc to get it fixed there. Now with all this ObjC 2.0 activity I would believe that someone would have get GCC libobjc up to par anyway on these platforms to be able test it there anyway. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Deadlock in NSLog
Am Montag, den 04.08.2008, 10:58 +0100 schrieb David Chisnall: On 4 Aug 2008, at 10:12, David Ayers wrote: Am Freitag, den 01.08.2008, 12:06 +0100 schrieb David Chisnall: It appears that GNUstep is using the ObjC runtime mutex, which tries to emulate a recursive mutex using a non-recursive mutex. It looked like there was a potential for deadlock in here when I looked at the code a few months ago. Since GNUstep depends on pthreads anyway, it might be better to use the pthread functions directly, rather than going through a buggy abstraction layer. I don't believe that bypassing the objc abstraction layer is a good idea. GNUstep and GNU ObjC have been ported to platforms that may not be supported be pthreads. In particular I remember that FreeBSD at on point used a different threading library that claimed POSIX/pthread compatibility. I would instead try to create a libobjc test case a report a bug against libobjc to get it fixed there. Now with all this ObjC 2.0 activity I would believe that someone would have get GCC libobjc up to par anyway on these platforms to be able test it there anyway. On FreeBSD, libobjc has always used POSIX threads. The abstraction layer includes Mach, Irix, and Solaris back ends. All of these platforms now have a POSIX-compliant threading library (and have got about a decade). There are no platforms on which GNUstep runs that do no either support POSIX threads or get POSIX threads through the same POSIX-compatibility framework needed for the rest of GNUstep. Just to make my position clear. I personally have no issue if libobjc required a working POSIX threads implementation and the legacy threading support is removed from libobjc [in fact it may already have been deactivated]. But I do believe this should be fixed in libobjc and not worked around in -base. Wether specific platform supports POSIX threads or not is irrelevent (and I seem to be misremebering the FreeBSD case, maybe it was NetBSD and pth?). What is relevent is which specific threading library libobjc was configured to use when it was built. This decission is not something that GNUstep code can influence (well save if you have multiple libobjc's installed each configured differently). What you are proposing is to simply assume that libobjc was configured with a library called libptheads and have -base link against it directly [something which have assumed in the past and possibly still assume in some cases since I haven't checked recently]. Yet this is error prone in the sense that it will work in most cases and fail subtly on some platforms by potentially linking two threading libraries. I also have no issue if there where some configure option as a stop-gap until the fixed libobjc is widely distributed. But never the less... it should be fixed in mainline libobjc first. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Deadlock in NSLog
Am Montag, den 04.08.2008, 12:56 +0100 schrieb David Chisnall: I don't care whether libobjc uses its own threading implementation or not, however there is no reason for GNUstep to be using an inefficient and potentially (in this case, definitely) buggy wrapper around pthreads, rather than using pthreads directly. The threading abstraction in libobjc implements the minimal functionality required for libobjc, not the minimal functionality required in general, or required for GNUstep. That assumes that ObjC code using GNUstep also does not use the libobjc API directly for certain features that OpenStep/Cocoa did/does not export. I don't believe that is a safe assumption. In fact I would be very surprised if code that uses threading in meaingfull ways does not rely on some of those features. NSRecursiveLock is implemented on top of objc_mutex, which emulates a recursive mutex on top of a non-recursive pthread (or other platform- specific) mutex. If this wrapper is broken, then please file a bug (or even fix it since this seems to be the pthread implementation which you are refering to). Quite how this makes more sense than using a recursive pthread mutex is beyond me. Because libobjc wraps the threading API for a reason. I don't claim to know all the reasons. I'm weary of ignoring them since debugging those issues is painful. So if libpthread (note I'm not stating POSIX... but a specific implementation that -base would link to). On platforms without native pthreads support, there are pthread-compatibility libraries that are a lot better tested for general-purpose use than the libobjc code. I cannot asses that evaluation, but I do clearly see a benifit in fixing libobjc rather than working around this in -base. If those pthread-compatibility libraries are so much better, then libobjc should be using them. I have no issue with that. In fact I think it would be great if libobjc could be simplified in this fasion. libobjc has to support more platforms than GNUstep. For example, it supports VxWorks and Windows directly. In order to use GNUstep on these platforms, you need a POSIX API layer, such as cygwin or mingw, which implements its own pthread wrapper. If you do this, then some code will be using the cygwin / mingw / whatever wrapper code around the native APIs, and some will be using the libobjc wrapper around the native APIs. Since GNUstep depends on POSIX for a lot of -base, I see no reason why it can't use POSIX functions. Well, there is a lot of code in -base that you would have adapt to remove the dependency of libobjc's threading implementation. In fact I'm not even sure if the NSWillBecomeMutlithread hook can reliably be called via the libobjc runtime if -base was configured with a different threading library than libobjc. (Of course it would happen to work if the threading libraries happend to be identical). But maybe you can explain why you do not seem to see an merit in fixing the libobjc wrapper. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Deadlock in NSLog
Am Montag, den 04.08.2008, 14:00 +0100 schrieb David Chisnall: On 4 Aug 2008, at 13:29, David Ayers wrote: I've come across a lot of code in Objective-C applications that uses POSIX thread calls directly (this is even what Apple's Cocoa docs recommend if NSThread and friends are not adequate for your purposes) You are aware that Apple can do this since it only supports libpthread for it's runtime. , but none that calls GNU runtime threading functions other than GNUstep. Note that these are GNU runtime specific - the NeXT, Apple, and Étoilé runtimes all use POSIX threads directly. I am not sure what happens with NSLock if you try to compile it with the NeXT/ Apple runtime. Possibly it just doesn't work. It will need rewriting before it can support the Étoilé runtime (and, thus, much of Objective-C 2) anyway. AFAIK the apple-gnu-* combos are not supported. NSRecursiveLock is implemented on top of objc_mutex, which emulates a recursive mutex on top of a non-recursive pthread (or other platform- specific) mutex. If this wrapper is broken, then please file a bug (or even fix it since this seems to be the pthread implementation which you are refering to). The wrapper works in the specific usage patterns for libobjc. It is not a general wrapper. OK... so this is the real topic... Is the threading API of libobjc a publicly exported user interface or an internal libobjc API? It wraps threading APIs because it is old, and when it was written there was a Solaris threading API, an HPUX threading API, and IRIX threading API, but no standard threading API. It continues to wrap it because it, like GCC, supports non-POSIX platforms such as Windows, OS/2, and VxWorks where POSIX is not a native API. [I'll refrain from replying to this for now as the answer to the above question is what will define everything that follows.] On platforms without native pthreads support, there are pthread-compatibility libraries that are a lot better tested for general-purpose use than the libobjc code. I cannot asses that evaluation, but I do clearly see a benifit in fixing libobjc rather than working around this in -base. If those pthread-compatibility libraries are so much better, then libobjc should be using them. I have no issue with that. In fact I think it would be great if libobjc could be simplified in this fasion. For libobjc to use them would introduce a dependency on POSIX into libobjc. You can use libobjc and GCC to compile Objective-C code that does not use GNUstep and that uses the platform APIs directly. Adding a dependency on POSIX would be counter to the goals of GNU libobjc. I don't understand how this would be adding a new dependency... libobjc already depends on libpthread /if/ it was configured to use libpthread. Since all you care about is libpthread, all you need to fix it for is libpthread and have all others use the historic code. Of course a FIXME would be nice. Well, there is a lot of code in -base that you would have adapt to remove the dependency of libobjc's threading implementation. In fact I'm not even sure if the NSWillBecomeMutlithread hook can reliably be called via the libobjc runtime if -base was configured with a different threading library than libobjc. (Of course it would happen to work if the threading libraries happend to be identical). NSWillBecomeMultithreaded should not be depended upon in any case. Well that's part of the point of discussion mentioned above. Currently we rely on: objc_set_thread_callback objc_thread_set_data objc_thread_get_data Would you consider this part of the public ObjC API? Do you see them usefull for something other than a public API? (I'm not trying to sound sarcastic... I really wonder why you don't believe they were intended for something internal.) Recent versions of Cocoa always run in multithreaded mode due to difficulties in safely handling the notification and of interoperating with code that uses pthreads directly (which Apple have been encouraging for a while, although less so with the NSThread extensions in 10.5). I'm not sure how this is relevant. On OS X, NSWillBecomeMultithreaded is delivered if, and only if, new threads are created with NSThread. It is the responsibility of NSThread to send this notification, and has nothing at all to do with whether the thread APIs are called via a wrapper or not (I believe early versions of OS X used Mach locks rather than POSIX ones (which were slightly slower) but this doesn't matter unless you expect to be able to lock a mutex with pthread_mutex_lock and unlock it with - [NSLock unlock], which neither Cocoa nor GNUstep support). It is true that NSWillBecomeMultithreaded is only intended for the OpenStep/Cocoa API. But what I was trying to say is that if the runtime has been linked to a different threading
Re: [Gnustep-cvs] r26723 - in /libs/base/trunk: ChangeLog Headers/Additions/GNUstepBase/config.h.in Source/GSFFIInvocation.m configure configure.ac
Hello David David Chisnall schrieb: I think calling mmap directly is the wrong solution here. You should be using valloc() with the requested size rounded up to the nearest page size, and then use mprotect to set it as executable. Note that most sane operating systems (and Vista) are moving to W^X, so you need to set it as writeable while creating it, then executable while using it (i.e. call mprotect immediately before the return). My man page for vmalloc states: The obsolete function valloc() allocates size bytes and returns a pointer to the allocated memory. The memory address will be a multiple of the page size. It is equivalent to memalign(sysconf(_SC_PAGESIZE),size). I'm not sure whether you are aware of the fact that this function is considered obsolete. Hi Richard, My man page for mmap states: MAP_ANON Synonym for MAP_ANONYMOUS. Deprecated. So to me it seems the new #ifndef logic is inverted. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r26723 - in /libs/base/trunk: ChangeLog Headers/Additions/GNUstepBase/config.h.in Source/GSFFIInvocation.m configure configure.ac
Hubert Chathi schrieb: On Sun, 29 Jun 2008 09:54:56 +0200, David Ayers [EMAIL PROTECTED] said: Hello David David Chisnall schrieb: I think calling mmap directly is the wrong solution here. You should be using valloc() with the requested size rounded up to the nearest page size, and then use mprotect to set it as executable. Note that most sane operating systems (and Vista) are moving to W^X, so you need to set it as writeable while creating it, then executable while using it (i.e. call mprotect immediately before the return). My man page for vmalloc states: The obsolete function valloc() allocates size bytes and returns a pointer to the allocated memory. The memory address will be a multiple of the page size. It is equivalent to memalign(sysconf(_SC_PAGESIZE),size). Heh. My man page for memalign says: , | The obsolete function memalign() allocates size bytes and returns a | pointer to the allocated memory. The memory address will be a multiple | of boundary, which must be a power of two. ` and implies that posix_memalign should be used instead. From what I can gather, ptr=valloc(size) is equivalent to posix_memalign(ptr,sysconf(_SC_PAGESIZE),size), but don't quote me on that. I'm on lenny... so one could consider that a bug in the vmalloc man page... would you care to open a bug report? Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: objc native exceptions
Graham J Lee schrieb: On 27 Jun 2008, at 18:14, Richard Frith-Macdonald wrote: That's really bad news when using distributed objects ... you might make a call to another application, an exception is raised in that application, passed back and re-raised in your application which then aborts your app! Isn't that just a recommendation to catch as close to the raise as possible, and to document all exceptions with an interface? Or just to not use exceptions :-) especially as the NSError-out-parameter pattern is more prevalent, and seems to be the pattern Apple have settled on. I'm unfamiliar with NSError patterns, but I'd like to point out that NSInvocations are not only used for DO but also NSTimers and NSUndoManager [and faults and such]. And raising exceptions through these invocations is still very common in deployed code. So besides the issue wrt to size [which I imagine could be very serious issue for our embeded/handheld folks], this issue needs to be addressed if the new exceptions are to be come default in environments where they are supported. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r26723 - in /libs/base/trunk: ChangeLog Headers/Additions/GNUstepBase/config.h.in Source/GSFFIInvocation.m configure configure.ac
Richard Frith-Macdonald schrieb: Author: rfm Date: Sat Jun 28 07:13:47 2008 New Revision: 26723 URL: http://svn.gna.org/viewcvs/gnustep?rev=26723view=rev Log: Try to ensure that ffi uses executable memory and doesn't segfault Ahh! Yes, mmap! Thank you! Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Release ready?
Hello Nicola, Nicola Pero schrieb: but I'm away from my Apple so can't fix it for 10 days or so. Anyway, the bug is present in all past releases as well, so shouldn't stop 2.0.6, which has a lot of nice bugfixes and small enhancements compared to 2.0.5. Does that also affect your ability to make a Renaissance release in the next few days? Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [RFC] Locale handling fix
Richard Frith-Macdonald schrieb: On 10 Jun 2008, at 22:05, David Ayers wrote: I here is a patch I have hat locally but never had the chance to verify. I'm personally uneasy about committing merely because of the timing. But I thought I'd bring it up for review just in case folk believe it is obviously correct. It matches the decoding key for thousands separator with the encoding key. (Maybe the correct fix is the other way around wrt compatibility). I checked ... the fix *is* the other way round. The key is NS.hasthousands. But it looks like encoding is not supported anywauy/ Hmm... indeed... I wonder how I stumbled over this. Maybe it was a bug report from an Cocoa user... It also fixes stringForObjectValue: to respect the current locale wrt thousands and decimal separators. This code looks reasonable enough to me. OK, I'll take a chance and commit it then... Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
Richard Frith-Macdonald schrieb: Where we have methods which are GNUstep specific, they ought to be in the additions library ... so assuming we get round to moving them, anyone using them will need to change their software to include the appropriate headers. A small change, but still one they need to be aware of. Yet, a very different change. I agree that a change like this is hardly as radical as 'prepare for removal', but we still need to let developers know somehow, and we don't have a mechanism for telling them to follow the commits minutely to see what actually happens. In fact, I guess they would ignore that anyway. I think the current approach may very well encourage ignoring deprecation warnings. It's not clear what the how the developer should act. What I was thinking of doing was marking things as deprecated (since the version macros let us do that, and autogsdoc will adjust the documentation accordingly), and putting something in the release notes to explain exactly what we mean by deprecated in this release (ie that a few things will go completely, but most will just be moved into the additions library and require different headers to be included). I don't think the release notes are the optimal place... but that may be personal taste... I would prefer the source or the headers. If you have a better idea of how to go about this sort of thing I'm very willing to listen (even time consuming alternatives if you want to volunteer to help out). I just don't want inaction to perpetuate the situation where people complain about lack of Apple compatibility. Well I think the correct solution would be to use the version macros to hide the declarations in the Foundation/*h headers yet to re-declare them unconditionally in a corresponding GNUstepAdditions/*.h header. [I'm currently not sure whether GSCategories.h is currently includable by applications using GNUstep proper.] Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
Richard Frith-Macdonald schrieb: On 10 Jun 2008, at 15:28, David Ayers wrote: Richard Frith-Macdonald schrieb: Where we have methods which are GNUstep specific, they ought to be in If you have a better idea of how to go about this sort of thing I'm very willing to listen (even time consuming alternatives if you want to volunteer to help out). I just don't want inaction to perpetuate the situation where people complain about lack of Apple compatibility. Well I think the correct solution would be to use the version macros to hide the declarations in the Foundation/*h headers yet to re-declare them unconditionally in a corresponding GNUstepAdditions/*.h header. Perhaps I'm misunderstanding you ... but if you do that, then all existing source code would fail to compile because declarations would not be visible in the headers they are including now, but they wouldnt be including the new header they need. I thought that this commit ... http://svn.gna.org/viewcvs/gnustep/libs/base/trunk/Headers/Foundation/NSString.h?rev=26621view=diffr1=26621r2=26620p1=libs/base/trunk/Headers/Foundation/NSString.hp2=/libs/base/trunk/Headers/Foundation/NSString.h [http://tinyurl.com/3j3ysu] ... already breaks existing source code. But without providing an alternative header to include. But in fact it seems that many of those declarations already exist in GSCategories.h. Sorry I should have checked earlier. [Yet there are some declarations that are not there... not sure what should happen to them (maybe this is only true for -immutableProxy] So what I'm trying to say, is that we should insure that all those methods are declared in GSCategories.h without the version macros. And maybe add a comment in the Foundation files to indicate where these declarations have moved to. I want current code to continue to compile and work with no changes, but to warn developers that things are going to change before the next stable release. Well if someone is using version macros now, they'll notice that the declarations are hidden. If not, I suppose they can't get warned with the current infrastructure. They'll notice once the declarations are removed from the file which should probably still contain a general comment about where declarations have been moved to. [I'm currently not sure whether GSCategories.h is currently includable by applications using GNUstep proper.] It is, and it's where I would expect most method declarations to move to eventually ACK. Sorry for the confusion. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[RFC] Locale handling fix
Hello Everyone,
I here is a patch I have hat locally but never had the chance to verify.
I'm personally uneasy about committing merely because of the timing.
But I thought I'd bring it up for review just in case folk believe it is
obviously correct.
It matches the decoding key for thousands separator with the encoding
key. (Maybe the correct fix is the other way around wrt compatibility).
It also fixes stringForObjectValue: to respect the current locale wrt
thousands and decimal separators.
There may be optimization possibilities and it may be incomplete... I
just happened to stumble over it. But I've been using it for quite some
time.
Cheers,
David
Index: Source/NSNumberFormatter.m
===
--- Source/NSNumberFormatter.m (Revision 26624)
+++ Source/NSNumberFormatter.m (Arbeitskopie)
@@ -36,6 +36,8 @@
#include Foundation/NSUserDefaults.h
#include Foundation/NSCharacterSet.h
+#include GNUstepBase/GSLocale.h
+
@implementation NSNumberFormatter
- (BOOL) allowsFloats
@@ -256,10 +258,10 @@
[self setDecimalSeparator:
[decoder decodeObjectForKey: @NS.decimal]];
}
- if ([decoder containsValueForKey: @NS.hasthousands])
+ if ([decoder containsValueForKey: @NS.hasthousand])
{
[self setHasThousandSeparators:
- [decoder decodeBoolForKey: @NS.hasthousands]];
+ [decoder decodeBoolForKey: @NS.hasthousand]];
}
if ([decoder containsValueForKey: @NS.localized])
{
@@ -534,7 +536,26 @@
BOOL displayFractionalPart = NO;
BOOL negativeNumber = NO;
NSString *useFormat;
+ NSString *defaultDecimalSeparator = nil;
+ NSString *defaultThousandsSeparator = nil;
+ if (_localizesFormat)
+{
+ NSDictionary *defaultLocale = GSDomainFromDefaultLocale();
+ defaultDecimalSeparator
+ = [defaultLocale objectForKey: NSDecimalSeparator];
+ defaultThousandsSeparator
+ = [defaultLocale objectForKey: NSThousandsSeparator];
+}
+
+ if (defaultDecimalSeparator == nil)
+{
+ defaultDecimalSeparator = @.;
+}
+ if (defaultThousandsSeparator == nil)
+{
+ defaultThousandsSeparator = @,;
+}
formattingCharacters = [NSCharacterSet
characterSetWithCharactersInString: @0123456789#.,_];
placeHolders = [NSCharacterSet
@@ -546,7 +567,8 @@
return [[self attributedStringForNotANumber] string];
if ([anObject isEqual: [NSDecimalNumber notANumber]])
return [[self attributedStringForNotANumber] string];
- if ([anObject isEqual: [NSDecimalNumber zero]])
+ if (_attributedStringForZero
+ [anObject isEqual: [NSDecimalNumber zero]])
return [[self attributedStringForZero] string];
useFormat = _positiveFormat;
@@ -560,7 +582,10 @@
// if no format specified, use the same default that Cocoa does
if (nil == useFormat)
{
- useFormat = negativeNumber ? @-#,###.## : @#,###.##;
+ useFormat = [NSString stringWithFormat: @[EMAIL PROTECTED]@[EMAIL PROTECTED],
+ negativeNumber ? @- : @,
+ defaultThousandsSeparator,
+ defaultDecimalSeparator];
}
prefixRange = [useFormat rangeOfCharacterFromSet: formattingCharacters];
@@ -580,15 +605,16 @@
//should also set NSDecimalDigits?
if ([self hasThousandSeparators]
- (0 != [useFormat rangeOfString:@,].length))
+ (0 != [useFormat rangeOfString: defaultThousandsSeparator].length))
{
displayThousandsSeparators = YES;
}
if ([self allowsFloats]
- (NSNotFound != [useFormat rangeOfString:@. ].location))
+ (NSNotFound
+ != [useFormat rangeOfString: defaultDecimalSeparator].location))
{
- decimalPlaceRange = [useFormat rangeOfString: @.
+ decimalPlaceRange = [useFormat rangeOfString: defaultDecimalSeparator
options: NSBackwardsSearch];
if (NSMaxRange(decimalPlaceRange) == [useFormat length])
{
@@ -636,14 +662,15 @@
while (([placeHolders characterIsMember:
[useFormat characterAtIndex: NSMaxRange(intPartRange)]]
|| [[useFormat substringFromRange:
- NSMakeRange(NSMaxRange(intPartRange), 1)] isEqual: @,])
+ NSMakeRange(NSMaxRange(intPartRange), 1)] isEqual:
+ defaultThousandsSeparator])
NSMaxRange(intPartRange) [useFormat length] - 1)
{
intPartRange.length++;
}
}
intPad = [[useFormat substringWithRange: intPartRange] mutableCopy];
- [intPad replaceOccurrencesOfString: @,
+ [intPad replaceOccurrencesOfString: defaultThousandsSeparator
withString: @
options: 0
range: NSMakeRange(0, [intPad length])];
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
Richard Frith-Macdonald schrieb: For the base library, reverting the license to LGPLv2 should be easy, but I'd also like the next stable release to mark all non-macosx stuff as deprecated ... on the basis that this would warn developers about the intention to be *highly* macosx compatible. Then we could either remove deprecated features (or move them to the additions library and undeprecate them) at will in the unstable branch after the release. If people are happy with this approach, I will at least try to search out and mark things as deprecated in the next few days, but if anyone wants to help with that I'd appreciate it. I would like to voice my opinion that I agree that being *highly* Cocoa compatible /by default/ is a good idea with respect to making it easier to write portable apps. I'm also for moving the GNUstep additions to -baseadd. I'm even for renaming any extensions in the NS namespace to GS. I'm not convinced that deprecating all non Cocoa features is a desirable goal in itself. Yet we really need to make sure that we do not introduce last minute changes which affect applications in non-obvious ways. I think such structural changes are more fit for the beginning of a release cycle. I understand the contention wrt the intended longevity of a stable release so I don't want the to interpreted as a veto... it's just that I think we really need to think about the pros and cons wrt changing the public API (and possibly behavior) at this stage. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: -lpthread
Richard Frith-Macdonald schrieb: On 3 Jun 2008, at 17:25, David Chisnall wrote: Looking at configure.ac in gnustep-make, it appears that, unless the --with-thread-lib= command-line argument is used to explicitly override normal behavior, -pthread is only used on freebsd ... so I don't see how anyone could have a problem with -pthread on Ubuntu. On free bsd, it tries to check that the objc runtime thread support works using first -pthread, then -lpthread, then -lpcthread What happens for you if you hack gnustep-make's configure.ac (and run autoconf to generate a new configure script) so that in the freebsd case it tests for -lpthread before it tests for -pthread ? You could also see if '-pthread -lpthread' works... perhaps changing gnustep-make to try that instead of just '-pthread' would solve your problem. I believe the issue is that historically the libobjc runtime could be used with different threading libraries for its threading API. But if I remember correctly, currently only POSIX Threads are supported. I'm not 100% sure anymore so some would have to investigate, but I think the approach to really fix the issue is that we need A) to introduce a generic threading option to gcc that will add/select the correct linker flags for threading support which was compiled into libobjc. B) to introduce something like an libobjc-config script in libobjc that our configure scripts can use to figure out the correct flags for the platform we are working with. Cheers, David PS: I don't have the time to deal with this so I'd be grateful is someone could pick this up. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
GDL2 Release for Debian Lenny
Hello Everyone, I would like to plan a GDL2 release for Lenny. I'm not sure what the exact deadlines are but they are approaching. Some of the GDL2 prerequisites are -make [current version in Lenny: 2.0.5 Sid: 2.0.5] -base [current version in Lenny: 1.14.1 Sid: 1.14.1] -gui [current version in Lenny: 0.12.0 Sid: 0.12.0] -back [current version in Lenny: 0.12.0 Sid: 0.12.0] Renaissance [current version in Lenny: 0.8.0 Sid: 0.9.0] GORM.app [current version in Lenny: 1.2.2 Sid: 1.2.2] I would like to know which versions (stable/unstable) are to be expected for Lenny so that I can match/remove some of the workarounds and hacks needed. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
GSWApplication +dealloc +init
Tim McIntosh schrieb:
On Mar 13, 2008, at 12:03 PM, David Ayers wrote:
One thing I've noticed while looking at GNUstep is some strange ways of
doing things, like this, where it is not immediately evident why the
normal pattern/idiom is not being used. It would be nice if all such
things were clearly commented, so that it would be easier to know that
the oddity was intentional rather than accidental. For instance in
GSWeb I see occurrences of the following, which I had convinced myself
is wrong:
+(void)dealloc
{
...
[[self superclass]dealloc]; // should be [super dealloc]
}
That's a class method. Classes do not get dealloced. They also don't
get +init'ed.
This is either dead code or it seems like a misleading name for cache
handling that has to be invoked with [[GSApp class] init] / [[GSApp
class] dealloc].
Hello Manuel,
Can these methods be removed from GSWApplication.m?
//
+(id)init
{
id ret=[[self superclass]init];
[GSWAssociation addLogHandlerClasse:[self class]];
return ret;
};
//
+(void)dealloc
{
[GSWAssociation removeLogHandlerClasse:[self class]];
DESTROY(localDynCreateClassNames);
GSWeb_DestroyGlobalAppDefaultOptions();
[[self superclass]dealloc];
};
Cheers,
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: EOFault / NSAutoreleasePool
Richard Frith-Macdonald schrieb: Well I could revert the 'fix'. I assumed that it was safer to call -methodForSelector: on an object than -instanceMethodForSelector: on a class, since any implementation of the former would have more information to work with (knowing details about the instance) in cases where the underlaying class was implementing a proxy to some other object. Of course, in an ideal world every class *ought* to have a correct and reliable implementation of both methods ... I was just trying to go for the option which I thought most likely to be reliable in practice. Well there are a few examples of classes on which you cannot not call arbitrary methods at arbitrary times. - NSAutoreleasePool itself raises on retain and autorelease and therefor cannot be added to collections. - It is invalid to call methods that auto release any objects during dealloc/release for any object because these methods get called during -emptyPool, And firing EOFaults (what actually happened to NSFaults? I remember discussing those a once) will do exactly that. It generally implies database access, creating many auto released objects to populate the attribute instance variables including accessor methods which all could validly call autorelease. I would want to add another special handling. EOFaults are indeed not standard ObjC constructs that require special treatment (Probably like NSProxy also). They try to be transparent objects but there are some rules. Just like one isn't allowed to send certain methods to NSAutoreleasePool instances, EOFaults are also special. I don't think these optimizations should be allowed to have such an impact on the semantics other features. I think we had a good compromise with +instanceMethodForSelector: (but we my still need to improve on that within GDL2). But asking us handle -methodForSelector for an optimization seems to be rather tough. I'm happy to revert the change ... but at the same time I think EOFault should have properly working implementations of all the basic methods of NSObject and NSProxy. However, I have no knowledge of the complexity of EOFault, so I don't know how much work that would be ... Just let me know what you want me to do. There are defined methods that do /not/ cause an EOFault to fire and they have been carefully selected to cope with Foundation's paradigms. They are: -retain -release -autorelease -retainCount -class -superclass -isKindOfClass: -isMemberOfClass -conformsToProtocol: -isProxy -methodSignatureForSelector: -respondsToSelector: -zone -doesNotRecognizeSelector: These methods also don't fire the fault but they don't hide the fact that the object has been faulted: -description -descriptionWithLocale: -descriptionWithIndent: -descriptionWithLocale:indent: -eoDescription -eoShallowDescription (see: http://developer.apple.com/documentation/LegacyTechnologies/WebObjects/WebObjects_4.5/System/Library/Frameworks/EOControl.framework/ObjC_classic/Classes/EOFault.html) (http://tinyurl.com/ys3ebu) everything else should fire the fault. In particular methodForSelector: should fire it so that you will get the implementation of the real class and insure that the real class is available. Yet the side effects of firing the fault (which are valid in most contexts) aren't valid for -emtpyPool. (see above) NSAutoreleasePool is a special class that has semantics that effect every Foundation based application / library. Especially -emptyPool has to be careful not to implicitly invoke methods that need an auto release pool in place. And there are other issues it needs to take into account. For example, if you were to attempt to obtain the class with -class instead of GSObjCClass you'd get the target class instead of EOFault. Then +instanceMethodForSelector: would give you the implementation of the original object, yet you'd be invoking it while it is still faulted. I would argue that invoking /anything/ but -release (and -retainCount/retain if necessary) is likely to be bug. But I have a strong sympathy for the IMP caching when an object has a high retain count. So I'm fine with the GSObjCClass/+instanceMethodForSelector: approach even though this is already rather shady. I really don't think -methodForSelector: should avoid fireing depending on the selector. So, yes I do think the patch needs to reverted. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: EOFault / NSAutoreleasePool
Richard Frith-Macdonald schrieb: On 13 Mar 2008, at 16:32, David Ayers wrote: Richard Frith-Macdonald schrieb: - It is invalid to call methods that auto release any objects during dealloc/release for any object because these methods get called during -emptyPool, No ... or at least I mean, if so I don't understand your reasoning. Can you say why you think that an object which is being deallocated should not autorelease anything? My belief is that objects being deallocated should be free to autorelease things. Maybe the Apple documentation says otherwise somewhere though. This is interesting... I do remember that being an issue before... but I just verified that that even with the old WO45 implementation that works fine. And firing EOFaults (what actually happened to NSFaults? I remember discussing those a once) will do exactly that. It generally implies database access, creating many auto released objects to populate the attribute instance variables including accessor methods which all could validly call autorelease. Sure, but as far as I know that's fine. Anything which is autoreleased during emptying of a pool should just get added to the end of the pool and then released later during the emptying. Barring bugs of course. I stand corrected. It seems valid to call autorelease during dealloc implementations. Still I don't believe that arbitrary IMP caching is valid (see my NSDistantObject reference to Fred's mail.) But for EOFaults would assume that retain cycles would not be broken if the got got fired during autorelease as relationships would re-add the object to relationships retaining them again. So, yes I do think the patch needs to [be] reverted. OK. Thanks! Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: EOFault / NSAutoreleasePool
Helge Hess schrieb:
On 11.03.2008, at 19:37, David Ayers wrote:
if you are using ogo with gdl2... is that the case?
No, OGo/SOPE uses its own variant of GDL1. But I assume that EOFault
handling is more or less the same.
Probably not quite :-)
We took percautions due to (the old) NSAutoreleasePool optimization:
/**
* Returns a pointer to the C function implementing the method used
* to respond to messages with selector by instances of the receiving
* class.
* br /Raises NSInvalidArgumentException if given a null selector.
*
* It's a temporary fix to support NSAutoreleasePool optimization
*/
+ (IMP) instanceMethodForSelector: (SEL)selector
{
if (selector == 0)
[NSException raise: NSInvalidArgumentException
format: @%@ null selector given,
NSStringFromSelector(_cmd)];
/*
*Since 'self' is an class, get_imp() will get the instance
method.
*/
return get_imp((Class)self, selector);
}
But now that Richard has committed that fix we'd also have to
implement methodForSelector: ...
But actually the above implementation is broken... we should only be
returning the implementation pointer for the selectors that can be
safely invoked without firing the fault. All other selectors should
fire the fault first and then return the method of the real object.
Of course caching EOFault/EOEnterpriseObject methods is risky business
as the same object may be refaulted/fired do to certain side effects.
For example it would very bad if an EOEnterpriseObject caused other
faults to fire during -dealloc.
Cheers,
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: case sensitivity in make flags
Matt Rice schrieb: On Mon, Mar 10, 2008 at 4:46 PM, Nicola Pero The issue is related, but slightly different. Your GNUmakefile always had xxx_HAS_RESOURCE_BUNDLE=yes, until David changed it to YES on 2008-03-06. ;-) gnustep-make has always accepted yes for the xxx_HAS_RESOURCE_BUNDLE flag, since its first introduction in 2002. :-) But I suspect David was confused by the fact that xxx_NEEDS_GUI (a new flag) requires YES instead of yes - which actually does sound like a bad idea (since it's inconsistent with everything else!) and might be worth fixing before the release! ;-) Oops! My bad. Indeed, it was just attempting to be consistent. Yes please let's fix this! I'll do the GDL2 changes... Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
EOFault / NSAutoreleasePool
Richard Frith-Macdonald schrieb: The underlying fault in ogo was that an array was being released too many times ... so it's possible that the EOFault I found on one debug run was just there because it had re-used the memory of the deallocated array in the autorelease pool. It's even possible (assuming that EOFault manages its oven memory ... I haven't checked the source) that the EOFault had not only re-used the memory form the array but had also been deallocated itsself. ie. the crash in + instanceMethodForSelector: may have been because the fault had been deallocated rather than because of a bug in the method itsself. You would probably know whether that could happen ... I don't know the EOFault code. EOFault instance are rather tricky when it comes to retain counting. They are proxy classes that update their class_pointer to morph back into an instance of the class the originally were. (i.e. one doesn't create EOFault instances, one creates custom Objects and they are faulted by releasing the attributes and storing some data they need to be restored later and updating the class_pointer to the EOFault class.) see: + (void)makeObjectIntoFault: (id)object withHandler: (EOFaultHandler *)handler But part of the data that must be retained in both guises is the retain count. Now there is code that is supposed to insure this. To make things worse, the implementation of the these fault handlers is partly in EOControl (EOFaultHandler (abstract class)) and EOAccess (EOAccessFault). I haven't tried running the gdl2 testsuite, but I assume you have done that and it doesn't crash. No it doesn't for me. But I'm not sure we cover the concrete EOFault classes wrt retain counts excessively. I think we my need some tests here to insure that the problem isn't here, if you are using ogo with gdl2... is that the case? Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: fyi - Mac OS native GDL2 / GSWeb Installer package
Hello Tim. just a quick status report... Tim McIntosh schrieb: I think I was being too vague with regard to KVC. I wasn't referring to the deprecated KVC methods issue that has been discussed on the list recently, but something much more trivial. All I was talking about was the difference in behavior of -[NSDictionary valueForKey:] and -[NSDictionary storedValueForKey:] with respect to special keys (GDL2's @allKeys vs. Cocoa's @@allKeys), and the different handling of NSArray aggregate functions when there is a key path following the aggregating operator instead of a simple key. For example: [EMAIL PROTECTED]@count With Cocoa's -[NSArray valueForKeyPath:] behavior, this would invoke [object valueForKeyPath: @[EMAIL PROTECTED]] on each object in the display group, then return the sum of the counts. This definitely doesn't work with WO45, but I think it is a natural extension of its concepts. So I'm inclined to attempt to support it. The funny thing is, that I think we already could do this if NSObject's valueForKeyPath: would invoke valueForKeyPath: on the result of the valueForKey: of the first component with the remaining key path instead of calling valueForKey: with each component. Yet this is currently just a theory and I suppose you were having issues on Cocoa's Foundation? And I'd hate to have to override valueForKeyPath: on Cocoa... With GDL2's behavior, this would attempt to invoke [[object valueForKey: @itemsArray] decimalValue] on each object in the display group, sum the results, and then invoke [result valueForKey: @@count] on the sum--none of which would actually work as intended in this case. Actually I'm not sure I get this far yet with -base. But it's something I think we could handle. My KVC changes are really pretty simple/naive (see attached patch). I was assuming this was an EOF vs. Cocoa behavior difference, but I'm not really sure about that. The old EOF documentation that I looked at didn't seem to be clear on what the behavior should be in this case, and I didn't have a setup where I could test EOF to see what it does, compared to GDL2. I don't have a high degree of confidence that I'm doing the right thing here, but I was trying to get a specific application working without changing any of its logic, and this seemed to do the trick. Yeah... this patch is a bit of a hammer. And like I said, I'd like to see your example work for GDL2 proper and I think it can... but it may take a bit. I think this deserves a feature request bug report. Maybe you could open one (assign it to gdl2 and me if that's possible). Possibly attach you patch also. Oh... and in case you plan in providing more non-trivial patches to GDL2 you should start considering a copyright assignment. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: fyi - Mac OS native GDL2 / GSWeb Installer package
David Ayers schrieb: Tim McIntosh schrieb: For example: [EMAIL PROTECTED]@count With Cocoa's -[NSArray valueForKeyPath:] behavior, this would invoke [object valueForKeyPath: @[EMAIL PROTECTED]] on each object in the display group, then return the sum of the counts. Actually, since Cocoa currently supports the aggregate keys, then maybe we need to move some of GDL2 KVC to -base... and then also -base's KVC would need more context with valueForKeyPath: on NSArray http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Protocols/NSKeyValueCoding_Protocol/Reference/Reference.html [http://tinyurl.com/2cq4rg] Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gdb objc regressions
Hello Matt Matt Rice schrieb: there is some issues with debugging objc [snip] it appears these are covered by failures in the testsuite but i anticipate not a lot of gdb developers have the objc compiler installed, I don't mind looking into this but it may take me a while to get up to speed, so any pointers in where to start looking would be appreciated I noticed this also. It seem to be an issue with GDB not being able to parse GCC's debug info and it seems like regression in GCC rather than GDB. See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462882 A current workaround would be to: set language objective-c explicitly, as suggested by Daniel. I haven't had the resources to investigate the exact commit that caused the regression yet. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r26258 - /libs/base/trunk/Source/NSAutoreleasePool.m
Richard Frith-Macdonald schrieb: URL: http://svn.gna.org/viewcvs/gnustep?rev=26258view=rev Log: Minor tweak to cope with EOFault Modified: libs/base/trunk/Source/NSAutoreleasePool.m Ugh! An autorelease was sent to the EOFault class? I'm not sure that EOFault should be handled specially here. Maybe we have a different issue. Does the testsuite trigger this? Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: fyi - Mac OS native GDL2 / GSWeb Installer package
Hello Tim, Tim McIntosh schrieb: I've been working on a Mac OS native port of the GSWeb and GDL2 frameworks, for use with Xcode and the Cocoa frameworks outside of a full GNUstep environment. I have put together Installer packages for Mac OS 10.4 and 10.5, which can be found here: http://hoth.radiofreeomaha.net:3000/~tmcintos/GNUstepWeb/ Since I don't have OS X, I can't test it. I have made a number of minor changes that I eventually intend to either undo or get accepted into the mainline. One difference in this version that may never make it into the mainline is the use of Cocoa-style (native) KVC (as opposed to WO-4.5 style), which I wanted for use with the WO5 app that I'm porting. It depends on how well we can emulate compatibility. Currently GSWeb/GDL2 is used for Projects that are currently still deployed as GNUstep based and WO45 based applications. So it's very important not to break WO45 compatibility. Yet if we can emulate it in a similar way as -base is currently trying, then I'd take the patches as long as they don't show issues. Do you really need to change the internal KVC? Maybe we just need to implement a few more legacy methods in EOKeyValueCoding.m to get it work on OS X. (And avoid some warnings from -base while we are at it.) Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GDL2 EOFault.m patch to fix -[EOFault forward::] on MacOS 10.4
Thanks Tim! Tim McIntosh schrieb: Thanks! It works with the new patch below, i.e., check for NULL. I forgot to mention that it appears that forward:: is neither called nor implemented by NSObject under 10.5. It is implemented and called under 10.4. Great! Committed! // Used only in EOFault.m, -[EOFault forward::], for Object compatibility @interface NSInvocation(GSCompatibility) - (retval_t) returnFrame:(arglist_t)args; - (id) initWithArgframe:(arglist_t)args selector:(SEL)selector; @end [snip] The comment shown above is from the actual code in SVN, though I don't know if it is true. I deleted these methods in my copy and have not noticed any problems, but that's not saying much. Well I currently don't have all GNUstep related projects checked out so I can't easily grep. I'll assume that Richard put that comment in there. Richard, feel free to remove that category in the unstable branch at your leisure (if that's ok with everyone wrt ABI/API compatibility). Cheers, David PS: I've just committed some NSProxy tests (that would effect EOFault just the same) which has some issues with the GSFinePoint (NSPoint with doubles instead of floats) and GSBitFields (imaginary stress-test type) in my setup. I still want to add test for passing NSDecimal as values (which is generally not done so any failures there should also be taken with a grain of salt). I would suspect the GSBitFields will break everywhere since it looks like an error during the parsing of the method signature. I currently don't have the time to look into it though. So don't hold your breath. But I thought it would be nice start to check libffi/ffcall coverage. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GDL2 EOFault.m patch to fix -[EOFault forward::] on MacOS 10.4
Hello Tim! Tim McIntosh schrieb: Is this patch too evil, or can we do something like this? Hehe... actually, it's not evil enough. ;-) I've committed a patch that should replace the runtime implementation pointer of EOFault's forward:: method with the one of NSObject. This should also save us a level of indirection at the price of not being able to set a breakpoint in gdb for EOFault'S forward::. For gnu-gnu-gnu (i.e. the GNU runtime) forward:: is actually not called anymore so I can't really test it. Could you please let me know if this works for you? It allows -[EOFault forward::] to work on MacOS 10.4, gets rid of some code duplicated from NSObject.m, and allows the following unimplemented methods to be deleted from GSCategories.h and GSCompatibility.m in base: // Used only in EOFault.m, -[EOFault forward::], for Object compatibility @interface NSInvocation(GSCompatibility) - (retval_t) returnFrame:(arglist_t)args; - (id) initWithArgframe:(arglist_t)args selector:(SEL)selector; @end Indeed, if this works (and if that was really the last place these methods were used) then I'm fine with having this removed from -base. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Objective C threads on NetBSD 4.0 i386
Richard Frith-Macdonald wrote: On 6 Jan 2008, at 17:19, David Wetzel wrote: Hi, objc_thread_detach (@selector(hash), o, nil); returns NULL on all boxes. Also on NetBSD 3.1 where NSThread is working with GNUstep. Any Ideas? I don't see how that's possible unless you are linking something wrong ... if objc_thread_detach() returns NULL then NSThread cannot work ... It doesn't actually return NULL on NetBSD 3.1. There seems to be a promotion/printf issue, undefined behavior or some serious bug. For: printf(return value is %p %d\n int:%d retval:%d NULL:%d, COMP:%d\n, retval, (retval == NULL), sizeof(int), sizeof(retval), sizeof(NULL), sizeof(retval==NULL)); I get: return value is 0xbb00 0 int:4 retval:4 NULL:4, COMP:4 since it is based on objc_thread_detach() and will raise an exception if that returns NULL (since NULL is the error return from that function ... not a great piece of design, but it's what the objc runtime provides). But on the 4.0 version we really get 0x0. Now I'll poke a bit but I think Dave W. will actually have to install a debug version of gcc/libobjc for me to figure out what's going on here. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep Testfarm Results
Adam Fedor schrieb: Test results for GNUstep as of Thu Dec 20 06:34:12 EST 2007 If a particular system failed compilation, the logs for that system will be placed at ftp://ftp.gnustep.org/pub/testfarm Fail Compile sparc-sun-solaris2.7 Thu Dec 20 01:21:07 EST 2007 Compiling file NSBrowser.m ... NSBrowser.m: In function `-[NSBrowser encodeWithCoder:]': NSBrowser.m:2515: parse error before `long' NSBrowser.m:2516: `flags' undeclared (first use in this function) NSBrowser.m:2516: (Each undeclared identifier is reported only once NSBrowser.m:2516: for each function it appears in.) make[2]: *** [shared_obj/NSBrowser.o] Error 1 make[1]: *** [libgnustep-gui.all.library.variables] Error 2 make[1]: Leaving directory `/raid0/ps0/fedor/src/gstep/testing/core/gui/Source' make: *** [internal-all] Error 2 NSBroweser's encodeWithCoder: flags declaration is on line 2602 in my editor. Could someone insure that the source is current? Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep Testfarm Results
David Ayers schrieb: Adam Fedor schrieb: Test results for GNUstep as of Thu Dec 20 06:34:12 EST 2007 If a particular system failed compilation, the logs for that system will be placed at ftp://ftp.gnustep.org/pub/testfarm Fail Compile sparc-sun-solaris2.7 Thu Dec 20 01:21:07 EST 2007 NSBroweser's encodeWithCoder: flags declaration is on line 2602 in my editor. Could someone insure that the source is current? Sorry, my bad... old tarball. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: testing malloc / free behaviour
David Wetzel schrieb: Hi, just run this and a top in a different terminal. If the memory use of the process goes down after the freeing... message, all is fine. It works as expected on Mac OS X Leopard and NetBSD 3.1 You might set your limits to unlimited before running this. http://www.gnu.org/software/libc/manual/html_node/Freeing-after-Malloc.html#Freeing-after-Malloc [http://tinyurl.com/yqh6n4] Occasionally, free can actually return memory to the operating system and make the process smaller. Usually, all it can do is allow a later call to malloc to reuse the space. In the meantime, the space remains in your program as part of a free-list used internally by malloc. There is no point in freeing blocks at the end of a program, because all of the program's space is given back to the system when the process terminates. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RFA: Reorganize GS extensions (was: RFC: en/decodeBase64 relocation)
Richard Frith-Macdonald schrieb: On 2007-12-06 15:12:30 + David Ayers [EMAIL PROTECTED] wrote: I've also added the declarations to the NSData.h header because -base avoids including GSCategories.h declarations when building itself and relies on the extensions being declared in GNUstep's standard headers. I it was once explained to me that this was done to avoid having folks who merely target GNUstep from having to include the special headers. I guess I'd forgotten this. But maybe we should reconsider this approach and remove the: /* The following ifndef prevents the categories declared in this file being * seen in GNUstep code. This is necessary because those category * declarations are also present in the header files for the corresponding * classes in GNUstep. The separate category declarations in this file * are only needed for software using the GNUstep Additions library * without the main GNUstep base library. */ #ifndef GNUSTEP in GSCategories.h Well, I think so. I don;t know who wrote that (it could well have been me), but my current feeling is that the best approacch is to try to move towards as completely compatible as we can with the main part of the base library, and isolate the extensions etc in the Additions subproject. Agreed... but it seems like quite a task (read can of worms)... - to consolidate all our NSObject.h/NSDebug.h/GC-related macros and provide the definitions that work for GNUstep (with/without GC) and OS X - find a solution for extensions like NSStringEncoding enum - find solutions for the implications wrt generating documentation I think this can only be done step by step and deal with the issues as the show themselves. My first proposal would be to start preparing the header files. I think seperate GSMacros.h file would be warrented. This file should contain at least all the macros currently defined in GSCategories.h. Then we need to decide which macros from NSObject.h and NSDebug.h should also be transfered or whether we should take the opportunuty to remove them. Attached is my first proposal: Cheers, David PS: I cannot test on OS X so I'll need some help testing... maybe someone can setup the autobuilder test for OS X. Index: ChangeLog === --- ChangeLog (Revision 25700) +++ ChangeLog (Arbeitskopie) @@ -1,3 +1,15 @@ +2007-12-08 David Ayers [EMAIL PROTECTED] + + * Headers/Additions/GNUstepBase/GSMacros.h: Copied + from GSCategories.h and removed references to + categories. + * Headers/Additions/GNUstepBase/GSCategories.h: + Include new GSMacros.h file and remove all + macro definitions. Move #ifndef GNUSTEP block + inside of other conditional block to allow extracting + definitions piece by piece. + * Source/GNUmakefile: Add new GSMacros.h file. + 2007-12-07 Richard Frith-Macdonald [EMAIL PROTECTED] * Headers/Additions/GNUstepBase/GSConfig.h.in: Index: Headers/Additions/GNUstepBase/GSMacros.h === --- Headers/Additions/GNUstepBase/GSMacros.h (Revision 25700) +++ Headers/Additions/GNUstepBase/GSMacros.h (Arbeitskopie) @@ -1,6 +1,6 @@ -/** Declaration of extension methods and functions for standard classes +/** Declaration of extension macros - Copyright (C) 2003 Free Software Foundation, Inc. + Copyright (C) 2007 Free Software Foundation, Inc. Written by: Richard Frith-Macdonald [EMAIL PROTECTED] and: Adam Fedor [EMAIL PROTECTED] @@ -22,23 +22,11 @@ Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02111 USA. - AutogsdocSource: Additions/GSCategories.m - */ -#ifndef INCLUDED_GS_CATEGORIES_H -#define INCLUDED_GS_CATEGORIES_H -#include GNUstepBase/GSVersionMacros.h +#ifndef INCLUDED_GS_MACROS_H +#define INCLUDED_GS_MACROS_H -/* The following ifndef prevents the categories declared in this file being - * seen in GNUstep code. This is necessary because those category - * declarations are also present in the header files for the corresponding - * classes in GNUstep. The separate category declarations in this file - * are only needed for software using the GNUstep Additions library - * without the main GNUstep base library. - */ -#ifndef GNUSTEP - #include string.h #include Foundation/Foundation.h @@ -59,6 +47,15 @@ @class NSMutableSet; +/* The following ifndef prevents the declarations in this section from being + * seen in GNUstep code. This is necessary because those + * declarations are also present in the header files for the corresponding + * classes in GNUstep. The separate declarations in this file + * are only needed for software using the GNUstep Additions library + * without the main GNUstep base library. + */ +#ifndef GNUSTEP + /* * Macros */ @@ -189,185 +186,15 @@ #define GS_INITIALIZED_LOCK(IDENT,CLASSNAME
Re: [patch #6286] NSBezierPath encode/decode improperly implemented
Fred Kiefer schrieb:
A few days ago I replied to a patch send in by Christopher Wojno:
Fred Kiefer wrote:
Update of patch #6286 (project gnustep):
In your error message I can see that an NSKeyedArchiver gets used. As far as
I can see, your patch doesn't implement the missing keyed archiving for
NSBezierPath, so how does it help you?
In my code NSBezierPathElement is always an enumeration, why would the
encoding stuff need the additional hint that it really is an enum? As far as I
can see there is no struct called NSBezierPathElement.
It turned out that it really makes a difference if we use
@encode(NSBezierPathElement) or @encode(enum NSBezierPathElement). Could
somebody explain this to me? Why isn't NSBezierPathElement resolved to
an unsigned int?
Hello Fred,
an enum should be encoded as an int (as opposed to an unsigned int) on
most platforms (See NSComparisonResult for usage of negative values).
Yet there are platforms(/gcc options) for which small enums can be
stored in smaller signed base types.
But I do believe that:
typedef {
VAL1,
VAL2
} ENumType;
@encode(ENumType);
and
@encode(enum ENumType);
should always return the same string (on our platforms i).
Cheers,
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: RFC: en/decodeBase64 relocation
Richard Frith-Macdonald schrieb: On 2007-12-02 21:32:17 + David Ayers [EMAIL PROTECTED] wrote: Hello everyone, Even though base64 encoding is primarily used with MIME processing, its usage does spring up here in related and unrelated scenarios. It also seems more natural as an NSData category to me. I'm wondering whether this patch: moving the implementation of GSMime en/decodeBase64: to an NSData en/decodeBase64 category would be considered too much of a name pollution issue wrt NSData. I've had this patch in my tree for some time now (had to clean it up a bit and check for new usage of the current method so I cleanup some compiler warnings while I was at it to make sure I don't miss one). I agree that it seems natural as an NSData category, but I also think we need to avoid pollution of the basic headers/classes, so I don't think the patch is a good idea. mhm... IMO a more 'correct' patch would be to: 1. Put the implementation in Source/Additions/GSCategories.m (and the declaration in Headers/Additions/GNUstep/GSCategories.h) 2. Mark the methods in GSMime.h as deprecated and to be removed in version 1.17.0 3. Change GSMime.m and all files currently using the methods to use the NSData methods and include GSCategories.h I'm a bit confused... or I should have explained it better but I thought the patch did these things... well almost. I've also added the declarations to the NSData.h header because -base avoids including GSCategories.h declarations when building itself and relies on the extensions being declared in GNUstep's standard headers. I it was once explained to me that this was done to avoid having folks who merely target GNUstep from having to include the special headers. But maybe we should reconsider this approach and change remove the: /* The following ifndef prevents the categories declared in this file being * seen in GNUstep code. This is necessary because those category * declarations are also present in the header files for the corresponding * classes in GNUstep. The separate category declarations in this file * are only needed for software using the GNUstep Additions library * without the main GNUstep base library. */ #ifndef GNUSTEP in GSCategories.h But maybe you just mean that the method of deprecation isn't optimal. What I did is that I simply removed the old method declaration from the GSMime.h header but left the implementation which produces a warning when invoked before forwarding it to the NSData category. The warning also doesn't specify a specific version of when the implementation would be removed. But main issue is: a) should we (continue to) add categories to standard classes b) should we try to limit all future extensions to custom classes I'm undecided leaning towards a) (at least until we have the first collision with OS X). Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
fpclassify portability [Solaris/FreeBSD]
Hello Adam, [EMAIL PROTECTED] schrieb: On solaris, isnanf is defined in ieeefp.h, but not the other ones. Although there is a function fpclass() which provides similar information. I don't know about FreeBSD thank you for checking! I've checked up some more and it seems that: #include math.h int fpclassify(x); should be the most portable approach (without requiring a conditional include). Could you verfiy that this exists for solaris? Anyone with FreeBSD? Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep Testfarm Results
Adam Fedor schrieb: Test results for GNUstep as of Mon Dec 3 06:34:10 EST 2007 If a particular system failed compilation, the logs for that system will be placed at ftp://ftp.gnustep.org/pub/testfarm If you would like to be a part of this automated testfarm, see http://wiki.gnustep.org/index.php/Developer_FAQ#How_can_I_take_part_with_a_GNUstep_autobuilder_for_the_testfarm.3F Fail Compile i386-unknown-freebsd6.3 Mon Dec 3 15:36:40 CST 2007 NSDecimalNumber.m: In function `-[NSDecimalNumber initWithBytes:objCType:]': NSDecimalNumber.m:348: warning: implicit declaration of function `isinff' ... ../Source/./obj/libgnustep-base.so: undefined reference to `isinff' gmake[2]: *** [obj/autogsdoc] Error 1 gmake[1]: *** [autogsdoc.all.tool.variables] Error 2 gmake[1]: Leaving directory `/var/home/gstest/gnustep-testfarm/core/base/Tools' gmake: *** [internal-all] Error 2 Could someone with access to a FreeBSD system check whether I need to define something special (akin to _GNU_SOURCE) to make isinff() visible, or let me know of FreeBSD's C-Library simply does not provide isinff? Success Compile i386-unknown-netbsdelf3.1 Mon Dec 3 03:57:12 CET 2007 Fail Compile sparc-sun-solaris2.7 Mon Dec 3 01:23:28 EST 2007 Here it seems that isnanf isinf isinff are all not visible. There must also be someway to expose the C99 macros. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: KeyValueCoding compatibility issues
Richard Frith-Macdonald schrieb:
No, I guess you misunderstood what Marcus was saying about the
define. What he did was to bracket the backward compatibility code
with the define, so that we can easily remove backward compatibility
at some future date if we want to. The current code (ie with
backward compatibility turned on) checks at runtime to see what
methods the receiver responds to ... if the receiver responds to the
methods of the old API, the code behaves one way, if it responds to
methods of the new API it behaves the other way. This means that GDL2
ought to continue to work without modification, until we decide we
want to change it.
I missed the fact that backward compatibility was turned on by default.
But I don't understand how the runtime check
#ifdef WANT_DEPRECATED_KVC_COMPAT
static IMPo = 0;
/* Backward compatibility hack */
if (o == 0)
{
o = [NSObject instanceMethodForSelector:
@selector(takeValue:forKey:)];
}
if ([self methodForSelector: @selector(takeValue:forKey:)] != o)
{
[self takeValue: anObject forKey: aKey];
return;
}
#endif
is supposed to work. The objects generally /rely/ on KVC, they don't
override the primitives. Generally they implement the accessor methods
(with or without underscore / 'get') or use one of the ivar conventions.
I understand that -base intends to track Cocoa while GDL2 and GSWeb
aim at an ancient static API. I could also instead transfer the
now missing methods to GDL2 but maybe we can work out a better
approach by extracting defined KVC API's into separate
Frameworks/Libraries/Bundles which can be linked/loaded by
applications that require them, rather than having -configure
decide for the entire GNUstep installation.
There aren't any missing methods as far as I know, and compatibility
is determined by what your objects support at runtime, not by a
configure. But in any case I would have thought it made sense to
gradually update to follow the Apple API changes in case you want to
use GDL2 on MacOS.
I would love to see a way to gradually update the API while keeping
backward compatibility. But my personal goal is keep GDL2 compatible
with WO45 as long as I need to support legacy installations.
If either:
- we can finally drop WO45 compatibility in our legacy code
- someone else wants to take over GDL2 maintiance and keep it up to par
with the current API on favor of compatibility for new apps (in which
case I could keep a personal branch).
I'd be glad to have GDL2 reworked. In fact if i had API/design freedom,
I would have quite few changes I'd like to implement.
Cheers,
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: KeyValueCoding compatibility issues
Richard Frith-Macdonald schrieb: On 2007-11-29 17:24:55 + Marcus Müller [EMAIL PROTECTED] wrote: KVC compatibility is badly broken in several situations, where subclasses usually override specific methods, but the calling API was partly ported to use the new-style KVC, i.e. -takeValue:forKey: is somehow mixed with -setValue:forKey:. Usually, this happens when you port an application to the new API but some underlying framework has yet to be ported... the result is something which doesn't work properly at all. Attached, find a patch that fixes all these problems. As an added bonus, all compatibility code is prepared for exclusion from compilation, making it very easy to actually migrate to the new-style KVC completely. All compatibility workarounds will then be excluded as well, making KVC a bit faster altogether. Great ... thanks very much ... I checked the patch over visually, ran the testsuite on a copy of base with it applied, and comitted it to svn. Hmm, so I guess anyone needing GDL2 would have to set that define for -base. I understand that -base intends to track Cocoa while GDL2 and GSWeb aim at an ancient static API. I could also instead transfer the now missing methods to GDL2 but maybe we can work out a better approach by extracting defined KVC API's into separate Frameworks/Libraries/Bundles which can be linked/loaded by applications that require them, rather than having -configure decide for the entire GNUstep installation. That way apps can choose the semantics they want by linking/loading the compatibility code or not. Of course some apps (like GORM) will still face some rather volatile behavior when they start loading GDL2 code Palettes and therefor combine code expecting different semantics. Not really sure what the best course of action is... it may not be feasible to have GDL2/GSWeb rely on current -base anymore... Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: KeyValueCoding compatibility issues
[Marcus asked me to post his replies to the list (2)] Marcus Müller schrieb: Hmm, so I guess anyone needing GDL2 would have to set that define for -base. Yes, I guess so. For the time being I'd like to see that as being the default, but strictly speaking it's only there for legacy code. If GDL2 really should be considered legacy is up for discussion, in Cocoa it's definitely the case. I understand that -base intends to track Cocoa while GDL2 and GSWeb aim at an ancient static API. I could also instead transfer the now missing methods to GDL2 but maybe we can work out a better approach by extracting defined KVC API's into separate Frameworks/Libraries/ Bundles which can be linked/loaded by applications that require them, rather than having -configure decide for the entire GNUstep installation. That's probably the best approach. That way apps can choose the semantics they want by linking/loading the compatibility code or not. Of course some apps (like GORM) will still face some rather volatile behavior when they start loading GDL2 code Palettes and therefor combine code expecting different semantics. That's a major drawback, and my fix does its best to help in exactly these kinds of situations. Not really sure what the best course of action is... it may not be feasible to have GDL2/GSWeb rely on current -base I think your suggested approach would be best for all these cases. Cheers, Marcus ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Exception in takeValue:forKey:
David Wetzel schrieb:
Hi folks,
why is this raise there? I should only raise if the key is null as far as I
can see.
- (void) takeValue: (id)anObject forKey: (NSString*)aKey
{
SEL sel = 0;
const char *type = 0;
int off;
unsignedsize = [aKey length] * 8;
charkey[size+1];
GSOnceMLog(@This method is deprecated, use -setValue:forKey:);
if (anObject == nil)
{
[NSException raise: NSInvalidArgumentException
format: @Attempt to set nil value for key '%@', aKey];
}
(.)
I agree this looks very dubious to me also. Classic KVC would only
raise an exception if the attribute were a scalar value. GSObjCSetVal
takes care of calling setNilValueForKey: (unableToSetNilForKey: with
GDL2) when the attempt is made to set NSNull (EONull) or nil to a scalar
value.
I haven't noticed this because GDL2 replaces the implementation of -base.
Cheers,
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
RFA: ADDITIONAL_NATIVE_LIB_DIRS
Hello Nicola, Fred and *
I think we had talked about this just before/after the last -make
release but I can't remember what came of it. Maybe you can
review/approve this patch to add support for ADDITIONAL_NATIVE_LIB_DIRS
which in conjunction with ADDITIONAL_NATIVE_LIBS will allow a
transparent handling of flags in projects /using/ native libraries.
I'm not sure how this plays with non-flattened and/or GNUSTEP_BUILD_DIR
but if if fails, it should fail in the same manor as the the gui/base
tools should fail.
Is it OK to commit this before the release?
Cheers,
David
Index: rules.make
===
--- rules.make (Revision 25542)
+++ rules.make (Arbeitskopie)
@@ -160,7 +160,7 @@
endif
#
-# Implement ADDITIONAL_NATIVE_LIBS
+# Implement ADDITIONAL_NATIVE_LIBS/ADDITIONAL_NATIVE_LIB_DIRS
#
# A native lib is a framework on apple, and a shared library
# everywhere else. Here we provide the appropriate link flags
@@ -168,8 +168,10 @@
#
ifeq ($(FOUNDATION_LIB),apple)
ADDITIONAL_OBJC_LIBS += $(foreach lib,$(ADDITIONAL_NATIVE_LIBS),-framework $(lib))
+ ADDITIONAL_LIB_DIRS += $(foreach libdir,$(ADDITIONAL_NATIVE_LIB_DIRS),-F$(libdir))
else
ADDITIONAL_OBJC_LIBS += $(foreach lib,$(ADDITIONAL_NATIVE_LIBS),-l$(lib))
+ ADDITIONAL_LIB_DIRS += $(foreach libdir,$(ADDITIONAL_NATIVE_LIB_DIRS),-L$(libdir)/$(GNUSTEP_OBJ_DIR))
endif
#
Index: Documentation/make.texi
===
--- Documentation/make.texi (Revision 25542)
+++ Documentation/make.texi (Arbeitskopie)
@@ -476,6 +476,11 @@
targets and into -framework MyLibrary link flag for
apple-apple-apple.
+To add the corresponding flags, you can use
[EMAIL PROTECTED] += ../MyPath}
+This will be converted into -L../MyPath/$(GNUSTEP_OBJ_DIR) flag
+on for most targets and into -F../MyPath flag for apple-apple-apple.
+
@node objc.make, palette.make, native-library.make, Project Types
@subsection Objective-C Programs (@file{objc.make})
@menu
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: RFA: ADDITIONAL_NATIVE_LIB_DIRS
David Ayers schrieb:
Hello Nicola, Fred and *
I think we had talked about this just before/after the last -make
release but I can't remember what came of it. Maybe you can
review/approve this patch to add support for ADDITIONAL_NATIVE_LIB_DIRS
which in conjunction with ADDITIONAL_NATIVE_LIBS will allow a
transparent handling of flags in projects /using/ native libraries.
I'm not sure how this plays with non-flattened and/or GNUSTEP_BUILD_DIR
but if if fails, it should fail in the same manor as the the gui/base
tools should fail.
Is it OK to commit this before the release?
Cheers,
David
s/ADDITIONAL_LIB_DIRS/ADDITIONAL_FRAMEWORK_DIRS/ for the apple case...
Can you tell I don't have OS X to test this ;-)
Cheers,
David
Index: rules.make
===
--- rules.make (Revision 25542)
+++ rules.make (Arbeitskopie)
@@ -160,7 +160,7 @@
endif
#
-# Implement ADDITIONAL_NATIVE_LIBS
+# Implement ADDITIONAL_NATIVE_LIBS/ADDITIONAL_NATIVE_LIB_DIRS
#
# A native lib is a framework on apple, and a shared library
# everywhere else. Here we provide the appropriate link flags
@@ -168,8 +168,10 @@
#
ifeq ($(FOUNDATION_LIB),apple)
ADDITIONAL_OBJC_LIBS += $(foreach lib,$(ADDITIONAL_NATIVE_LIBS),-framework $(lib))
+ ADDITIONAL_FRAMEWORK_DIRS += $(foreach libdir,$(ADDITIONAL_NATIVE_LIB_DIRS),-F$(libdir))
else
ADDITIONAL_OBJC_LIBS += $(foreach lib,$(ADDITIONAL_NATIVE_LIBS),-l$(lib))
+ ADDITIONAL_LIB_DIRS += $(foreach libdir,$(ADDITIONAL_NATIVE_LIB_DIRS),-L$(libdir)/$(GNUSTEP_OBJ_DIR))
endif
#
Index: Documentation/make.texi
===
--- Documentation/make.texi (Revision 25542)
+++ Documentation/make.texi (Arbeitskopie)
@@ -476,6 +476,11 @@
targets and into -framework MyLibrary link flag for
apple-apple-apple.
+To add the corresponding flags, you can use
[EMAIL PROTECTED] += ../MyPath}
+This will be converted into -L../MyPath/$(GNUSTEP_OBJ_DIR) flag
+on for most targets and into -F../MyPath flag for apple-apple-apple.
+
@node objc.make, palette.make, native-library.make, Project Types
@subsection Objective-C Programs (@file{objc.make})
@menu
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r24805 - in /devmodules/dev-libs/simplewebkit: ./ English.lproj/ SimpleWebKit.pbproj/ Sources/
Riccardo Mottola schrieb: Author: rmottola Date: Wed Mar 7 23:43:02 2007 New Revision: 24805 URL: http://svn.gna.org/viewcvs/gnustep?rev=24805view=rev Log: initial import from mySTEP Hi Riccardo, I believe this is the wrong location... the canonical place would have been: libs/simplewebkit/trunk/ I believe devmodules/dev-libs only contains references (or External definitions) to mirror the legacy CVS layout. http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.externals Added: devmodules/dev-libs/simplewebkit/ devmodules/dev-libs/simplewebkit/English.lproj/ devmodules/dev-libs/simplewebkit/English.lproj/InfoPlist.strings (with props) devmodules/dev-libs/simplewebkit/GNUmakefile devmodules/dev-libs/simplewebkit/SimpleWebKit.pbproj/ devmodules/dev-libs/simplewebkit/SimpleWebKit.pbproj/project.pbxproj devmodules/dev-libs/simplewebkit/Sources/ devmodules/dev-libs/simplewebkit/Sources/DOM.h devmodules/dev-libs/simplewebkit/Sources/DOMCore.h devmodules/dev-libs/simplewebkit/Sources/DOMCore.m devmodules/dev-libs/simplewebkit/Sources/DOMHTML.h devmodules/dev-libs/simplewebkit/Sources/DOMHTML.m devmodules/dev-libs/simplewebkit/Sources/GNUmakefile devmodules/dev-libs/simplewebkit/Sources/Private.h devmodules/dev-libs/simplewebkit/Sources/WebBackForwardList.h devmodules/dev-libs/simplewebkit/Sources/WebBackForwardList.m devmodules/dev-libs/simplewebkit/Sources/WebDOMOperations.h devmodules/dev-libs/simplewebkit/Sources/WebDOMOperations.m devmodules/dev-libs/simplewebkit/Sources/WebDataSource.h devmodules/dev-libs/simplewebkit/Sources/WebDataSource.m devmodules/dev-libs/simplewebkit/Sources/WebDocument.h devmodules/dev-libs/simplewebkit/Sources/WebFrame.h devmodules/dev-libs/simplewebkit/Sources/WebFrame.m devmodules/dev-libs/simplewebkit/Sources/WebFrameLoadDelegate.h devmodules/dev-libs/simplewebkit/Sources/WebFrameView.h devmodules/dev-libs/simplewebkit/Sources/WebFrameView.m devmodules/dev-libs/simplewebkit/Sources/WebHTMLDocumentRepresentation.h devmodules/dev-libs/simplewebkit/Sources/WebHTMLDocumentRepresentation.m devmodules/dev-libs/simplewebkit/Sources/WebHTMLDocumentView.h devmodules/dev-libs/simplewebkit/Sources/WebHTMLDocumentView.m devmodules/dev-libs/simplewebkit/Sources/WebHistory.h devmodules/dev-libs/simplewebkit/Sources/WebHistory.m devmodules/dev-libs/simplewebkit/Sources/WebHistoryItem.h devmodules/dev-libs/simplewebkit/Sources/WebHistoryItem.m devmodules/dev-libs/simplewebkit/Sources/WebImageDocumentRepresentation.h devmodules/dev-libs/simplewebkit/Sources/WebImageDocumentRepresentation.m devmodules/dev-libs/simplewebkit/Sources/WebKit.h devmodules/dev-libs/simplewebkit/Sources/WebPDFDocumentRepresentation.h devmodules/dev-libs/simplewebkit/Sources/WebPDFDocumentRepresentation.m devmodules/dev-libs/simplewebkit/Sources/WebPlugin.h devmodules/dev-libs/simplewebkit/Sources/WebResource.h devmodules/dev-libs/simplewebkit/Sources/WebResource.m devmodules/dev-libs/simplewebkit/Sources/WebScriptObject.h devmodules/dev-libs/simplewebkit/Sources/WebScriptObject.m devmodules/dev-libs/simplewebkit/Sources/WebUIDelegate.h devmodules/dev-libs/simplewebkit/Sources/WebView.h devmodules/dev-libs/simplewebkit/Sources/WebView.m devmodules/dev-libs/simplewebkit/Sources/WebXMLDocumentRepresentation.h devmodules/dev-libs/simplewebkit/Sources/WebXMLDocumentRepresentation.m ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Richard Frith-Macdonald schrieb: On 12 Feb 2007, at 16:47, Nicola Pero wrote: IIRC we had some extensive discussions on the mailing lists that .sh/.csh should only be used for scripts that are sourced. But since GNUStep.sh is referenced so often in the archives, I'm having a hard time finding the discussion. I don't remember that discussion, but it's plain obvious that gnustep-make is not following that convention! There are lot of .sh files in gnustep-make that are not supposed to be sourced (eg, clean_cpu.sh, clean_os.sh, fixpath.sh, etc). We could change gnustep-make to follow the convention though if it can be argued that it is a good one - most of the scripts are only used internally in gnustep-make, so we should be able to rename them fairly easily. :-) Anyway, for a start I did change gnustep-config.sh to be gnustep- config. I don't remember that discussion either ... perhaps it was on another mailing list or a private email converstion? I'll try to find it. Please give me a bit. To the best of my knowledge, the standard convention is that a '.sh' extension indicates a shell script and that implies no distinction between one intended to be sourced and one intended to be executed. The distinction between a script intended to be executed and one intended to be sourced is normally made by file permissions ... one is made readable and executable but the other is made read only. Incidentally, GNUstep.sh has the wrong permissions (0755 rather than 0111) when installed by default on my system. On unix-like systems, the '#!/bin/sh' at the start of a script is enough to ensure that the script is executed properly when simply run. However, the '.sh' extension is important if you expect people to interpret a script with a specific shell (eg. they know to do 'sh foo.sh' rather than 'csh foo.sh'). So, if some discussion concluded that we should create a new convention to distinguish between executable and sourceable scripts by whether there is an extension or not ... I think it was wrong. [EMAIL PROTECTED]: /usr/local/src/svn/gnustep/projects/make$ locate -- '-config'|grep config$|grep bin|xargs file /usr/bin/aalib-config: Bourne shell script text executable /usr/bin/apr-config: Bourne shell script text executable /usr/bin/apt-config: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped /usr/bin/apu-config: Bourne shell script text executable /usr/bin/artsc-config: Bourne shell script text executable /usr/bin/audiofile-config: Bourne shell script text executable /usr/bin/autoopts-config: Bourne shell script text executable /usr/bin/cups-config: Bourne shell script text executable /usr/bin/esd-config: Bourne shell script text executable /usr/bin/ffmpeg-config:Bourne shell script text executable /usr/bin/freetype-config: Bourne shell script text executable /usr/bin/gnucash-config: Bourne shell script text executable /usr/bin/gpg-error-config: Bourne shell script text executable /usr/bin/guile-1.6-config: a /usr/bin/guile \ script text executable /usr/bin/guile-config: symbolic link to `/etc/alternatives/guile-config' /usr/bin/imlib-config: Bourne shell script text executable /usr/bin/kde-config: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped /usr/bin/libart2-config: Bourne shell script text executable /usr/bin/libgcrypt-config: Bourne shell script text executable /usr/bin/libgnutls-config: Bourne shell script text executable /usr/bin/libgnutls-extra-config: Bourne shell script text executable /usr/bin/libpng-config:symbolic link to `libpng12-config' /usr/bin/libpng12-config: Bourne shell script text executable /usr/bin/libpq3-config:symbolic link to `../lib/postgresql/bin/libpq3-config' /usr/bin/libtasn1-config: Bourne shell script text executable /usr/bin/opencdk-config: Bourne shell script text executable /usr/bin/pcre-config: Bourne shell script text executable /usr/bin/pkg-config: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped /usr/bin/scrollkeeper-config: Bourne shell script text executable /usr/bin/sdl-config: Bourne shell script text executable /usr/bin/xml2-config: Bourne shell script text executable /usr/bin/xslt-config: Bourne shell script text executable /usr/lib/postgresql/bin/libpq3-config: Bourne-Again shell script text
Re: gnustep-make experiment
Richard Frith-Macdonald schrieb: On 11 Feb 2007, at 11:23, David Ayers wrote: Should we 1) tweak the environment to allow AC_CHECK_LIB to work? 2) create our own: - AC_CHECK_GNUSTEP_LIBRARY - AC_CHECK_GNUSTEP_FRAMWORK - AC_CHECK_GNUSTEP_NATIVELIBRARY macros to be included in configure.ac scripts via GNUSTEP_MAKEFILES? 3) invoke 'make' with gnustep makefiles in some config subdirectory during ./configure 4) other ideas which I may have missed? [snip] Of your list of ideas ... I think 1 is obviously good, 2 i can understand having our own checks for frameworks and bundles, but I don't understand the library/nativelibrary distinction ... wouldn't you just use AC_CHECK_LIB? 3. OI don't really understand this one. Well the reason for the native library stems from the essentially obvious fact that native libraries are libraries on non-Darwin systems and frameworks on Darwin system (well unless your name is Matt and you've implemented native frameworks in GNU/Linux and GNU/Hurd ;-) ). So when /checking/ for projects that are native library projects we could duplicate -make's logic to decide to use _LIBRARY or _FRAMEWORK in every configure.ac script, or we could add the code to a macro supplied by -make that could be used by all and that would be updated in sync with -make when/if other platforms support frameworks. But I actually want to clarify what I meant with the third option for the configure issue... My goal is to have ./configure of GDL2 identify whether libGorm is installed/usable so it can decide whether the palette should be build or not. (The servers I deploy my GSWeb App on do not have X/AppKit/GORM but use GDL2 GSWeb... currently I need to disable building the palette explicitly via configure option.) Now most configure checks like AC_CHECK_LIB work by trying to build a minimal example code snipit and link it against the library. For GNUstep we probably need a lot of the features of -make to accomplish this. So to avoid duplicating -make in new configure macros, one could imagine creating config/gorm/ subdirs which contain a minimal test.m file and a minimal GNUmakefile (or have them generated by the new macros). And then have ./configure invoke 'make' in this subdirectory to see if this minimal project can be built/linked to decide whether to set a ./configure variable or not. OT1H, I feel this might be shooting at pigeons with canons (is that expression used in English?), yet OTOH it might be the only reasonable approach without duplicating -make features in configure macros especially for the cross-compilation case. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Nicola Pero schrieb: But I actually want to clarify what I meant with the third option for the configure issue... My goal is to have ./configure of GDL2 identify whether libGorm is installed/usable so it can decide whether the palette should be build or not. (The servers I deploy my GSWeb App on do not have X/AppKit/GORM but use GDL2 GSWeb... currently I need to disable building the palette explicitly via configure option.) I agree with Matt and others that we want to have gnustep-config able to output compile/link flags. I have a plan in mind for that. :-) But in your case, what about some makefile variable/function that lets you check if a gnustep library is installed or not ? We could add to gnustep-make a GNUSTEP_FIND_LIBRARY and GNUSTEP_FIND_FRAMEWORK functions, that would return the location of a GNUstep library/framework, or nothing if they don't exist. Then in your GNUmakefile you could just do ifneq ($(call GNUSTEP_FIND_LIBRARY, Gorm)$(call GNUSTEP_FIND_FRAMEWORK, Gorm),) SUBPROJECTS += GormPalette fi to compile your GormPallette iff libGorm.so (or Gorm.framework) is installed, without even needing the configure step. :-) Thanks NB: Here is an example GNUSTEP_FIND_LIBRARY implementation for you to test with -- GNUSTEP_FIND_LIBRARY = $(strip $(wildcard $(addsuffix $(strip $(1)).so, \ $(GNUSTEP_SYSTEM_ROOT)/Library/Libraries/lib \ $(GNUSTEP_LOCAL_ROOT)/Library/Libraries/lib \ $(GNUSTEP_NETWORK_ROOT)/Library/Libraries/lib \ $(GNUSTEP_USER_ROOT)/Library/Libraries/lib))) It would be defined inside gnustep-make though, so it will get automatically updated for the filesystem changes. You call it, and gnustep-make will make sure to look in the right library locations. PS: We could do this with standard variables (rather than functions), but functions have a more familiar syntax, and it looks like all GNU makes in the last 5 years or so support them, so we should probably start using them. Well I guess the approach would work but - the variables still need to take into account the non-flattened configuration (not sure show to do that with the variable approach without duplicating the block) and - this search would be executed for /every/ make invocation instead of once during configure. But I see that other projects that don't yet already need ./configure for other purposes like GDL2 would profit from this approach. Also I think the order should be according to precedence i.e. GNUSTEP_FIND_LIBRARY = $(strip $(wildcard $(addsuffix $(strip $(1)).so, \ $(GNUSTEP_USER_ROOT)/Library/Libraries/lib \ $(GNUSTEP_LOCAL_ROOT)/Library/Libraries/lib \ $(GNUSTEP_NETWORK_ROOT)/Library/Libraries/lib \ $(GNUSTEP_SYSTEM_ROOT)/Library/Libraries/lib))) So, do you have suggestion on how to handle the LIBRARY_COMBO/GNUSTEP_TARGET_DIR or will it be function approach? Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
David Ayers schrieb: Also I think the order should be according to precedence i.e. GNUSTEP_FIND_LIBRARY = $(strip $(wildcard $(addsuffix $(strip $(1)).so, \ $(GNUSTEP_USER_ROOT)/Library/Libraries/lib \ $(GNUSTEP_LOCAL_ROOT)/Library/Libraries/lib \ $(GNUSTEP_NETWORK_ROOT)/Library/Libraries/lib \ $(GNUSTEP_SYSTEM_ROOT)/Library/Libraries/lib))) Actually that's moot... it doesn't matter where it is found or if it's found multiple times. It will be linked according to precedence independent of what's in the variable. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Nicola Pero schrieb:
I like the idea of your patch, so I rewrote the shell script and committed it.
Minor nit... isn't gnustep-config.sh meant to be executed, not sourced?
So shouldn't it be named gnustep-config instead of gnustep.config.sh?
I'm trying to follow this discussion but it seems that we are not
addressing the issues which /I/ thought we are trying to solve.
I thought the main point was to enable ./configure to test for the
existence/usability of GNUstep libraries/frameworks. So shouldn't it be
installed in into a standard system path instead of
GNUSTEP_SYSTEM_ROOT/Tools? I would expect /usr/local/bin or whatever
--bindir is set to for configure of -make.
So how does is help with writing configure scripts?
Maybe something like?
GNUSTEP_MAKEFILES=${GNUSTEP_MAKEFILES:=`gnustep-config GNUSTEP_MAKEFILES`}
if test -z $GNUSTEP_PATHLIST; then
. ${GNUSTEP_MAKEFILES}/GNUstep.sh
fi
And then, once all the variables are set, how should we write configure
script tests? (and which variables are we allowed to use?)
Should we
1) tweak the environment to allow AC_CHECK_LIB to work?
2) create our own:
- AC_CHECK_GNUSTEP_LIBRARY
- AC_CHECK_GNUSTEP_FRAMWORK
- AC_CHECK_GNUSTEP_NATIVELIBRARY
macros to be included in configure.ac scripts via GNUSTEP_MAKEFILES?
3) invoke 'make' with gnustep makefiles in some config subdirectory
during ./configure
4) other ideas which I may have missed?
Note that I haven't really understood how pkg-config would be used at
this level either. But I get the feeling that we are not solving the
issues we are aiming at. But maybe I'm just confused, so I guess it
would be great if the usage of the two approaches in the context of
configure scripts could be summarized.
Cheers,
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Nicola Pero schrieb: I like the idea of your patch, so I rewrote the shell script and committed it. Minor nit... isn't gnustep-config.sh meant to be executed, not sourced? So shouldn't it be named gnustep-config instead of gnustep.config.sh? Yes, it is meant to be executed, not sourced. Not sure what implication that does have on the '.sh' at the end of the name though. Maybe omitting the '.sh' would allow us more freedom in the future, eg, to replace the script with a compiled binary if we ever need ? Any suggestions/comments on what the best name is ? IIRC we had some extensive discussions on the mailing lists that .sh/.csh should only be used for scripts that are sourced. But since GNUStep.sh is referenced so often in the archives, I'm having a hard time finding the discussion. I thought the main point was to enable ./configure to test for the existence/usability of GNUstep libraries/frameworks. So shouldn't it be installed in into a standard system path instead of GNUSTEP_SYSTEM_ROOT/Tools? I would expect /usr/local/bin or whatever --bindir is set to for configure of -make. If GNUSTEP_SYSTEM_ROOT/Tools is not in your PATH, then GNUstep is either not installed, or completely unusable - and your configure should fail in that case. ;-) OK, I guess I missing the point of the pkg-config/gnustep-config discussion. I admit that I'm confused about role/intent of all of these configuration files and relocaction capabilities. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Test base library stable branch please
Graham J Lee schrieb: On 2 Jan 2007, at 09:38, [EMAIL PROTECTED] wrote: David Ayers schrieb: No...at least, not if it needs to work in the same way as Cocoa's NSNumberFormatter. Because the documentation says this: When you enable localization for a number formatter, separators are converted to characters appropriate to the environment in which the application is running. and this: when you enable localization for a number formatter object, the dollar sign character is converted to the currency symbol appropriate for the environment in which the application is running. I took that to mean that the layout of the format string doesn't change, but the output does depending on the locale. In fact, that only seems true if you explicitly enable localisation in a given formatter. But I looked at providing that, and I think it would require that we already have NSLocale. Which of course isn't true :-(. Anyway, regardless the tests *ought* to still pass, because the test case *doesn't* enable localisation. N.B. in the Cocoa docs it explicitly says that the thousands separator is , unless and until you change it e.g. by enabling localisation. So I take it that the default behaviour is non-localised. Currently in a de_AT.UTF-8 locale these tests fail: base/NSNumberFormatter/basic.m: FAIL: default format same as Cocoa pass([str isEqual: @1,234.57], default format same as Cocoa); where str = @1,234. I still haven't been able to duplicate that. Maybe if you're going to FOSDEM we could meet up and have a mini-hackfest to see WTF is happening :-) The issue was not a bug in NSNumberFormatter. It was a bug in the implementation of NSDecimalNumber - (id) initWithBytes: (const void*)value objCType: (const char*)type which called: [[NSString alloc] initWithFormat: @%g,v]; instead of [[NSString alloc] initWithFormat: @%g locale: GSPrivateDefaultLocale(), v]; It's just that due to the missing tests for NSDecimalNumber, the issue didn't show up in the test suite until the tests for the formatter where added. Note that NSString's initWithFormat: will call initWithFormat:locale: with a nil locale which implies a 'C' locale representation while the subsequent -initWithString: of NSDecimalNumber is implemented as: return [self initWithString: numberValue locale: GSPrivateDefaultLocale()]; which in turn interprets the string with the current locale as documented: http://www.gnustep.org/resources/documentation/Developer/Base/Reference/NSDecimalNumber.html#method$NSDecimalNumber-initWithString$ I believe Richard has fixed this part on the release branch already. But there are actually more issues with the - (id) initWithBytes: (const void*)value objCType: (const char*)type implementation, as it ignores the type parameter and simply assumes that it is a double value. My patch proposal tries to handle most of the other types that could be passed to the method. And it also tries to handle INF and NAN double and float values better. But I must admit that I do not have a Cocoa reference implementation to verify whether Cocoa handles INF/NAN correctly. Sorry, I won't be able to make it to FOSDEM otherwise I would have been sure to schedule a GDL2 session already. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Nicola Pero schrieb: I'd rather spend some time documenting what we already have before we try working on the next steps (nobody seems to have a clue about all the new stuff in gnustep-make). So can we come back to this in a few weeks ? ;-) Personally I'd prefer to suspend the release until we have an environment that has a chance of remaining stable. It seems that we already require -make users to adapt thier projects for this release (I remeber you cleaning up many projects in SVN) and it seems they may need to adapt again for the subsequent release. But as I'm not effected by it in a big way, I won't argue hard... Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Richard Frith-Macdonald schrieb: On 24 Jan 2007, at 14:10, Matt Rice wrote: On 2007-01-24 04:17:17 -0800 Nicola Pero [EMAIL PROTECTED] innovation.com wrote: attached is just sort of an experiment in getting rid of GNUstep.sh to compile stuff If you use trunk, you don't need GNUstep.sh to compile stuff ... ;-) 1. add /usr/GNUstep/System/Library/Libraries and /usr/GNUstep/ Local/Library/Libraries to /etc/ld.so.conf and run ldconfig 2. add /usr/GNUstep/System/Tools and /usr/GNUstep/Local/Tools to your PATH 3. set GNUSTEP_MAKEFILES=/usr/GNUstep/System/Library/Makefiles and you're ready to go. Once we use FHS, then libraries and tools will automatically be in your PATHs, so you would need to: * do nothing to use GNUstep * set the single variable GNUSTEP_MAKEFILES to compile GNUstep stuff and you can also easily switch between different installations by using configuration files. Thanks PS: investigations are still welcome though ;-) In that case I still think that pkg-config support would be worthwhile, as GNUstep is then totally isolated theres no way for an external shell script/autoconf to know anything about GNUstep really since GNUstep.conf put anywhere and they can no longer rely on environment variables, I've come across at least 2 instances of needing the environment variables GDL2 needs to attempt to link to the Gorm libraries to see if it should enable building of the GDL2 Gorm palette and in porting aquaterm, and the gnuplot adaptor for aquaterm, it needs to also look for a lib in the GNUstep heirarchy to enable that. I find this discussion confusing ... I had assumed that the point of not using GNUstep.sh was for things which did not want to know anything about GNUstep. That seems reasonable enough... after all, why should you want to know about where resources are if all you want to do is run a program? However, when you talk about GDL2 wanting to know where the Gorm libraries are, you obviously DO want to know about GNUstep resource locations, and you can easily get the information by running GNUstep.sh ... so why do you want to not run it? What is the benefit of *not* running GNUstep.sh for scripts which want to know about GNUstep? It's not stricty GDL2 in this case but ./configure of GDL2 which want to tweak make file fragments dependent on what's available. So maybe we need some tool in the path to query the values. Something like gnustep-config akin to apxs and xml2-config. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[RFC/RFA]: NSDecimalNumber initWithBytes:objCType:
Hello,
This is similar crude approach short of using GMP directly in that
method. It basically adds handling for scalar types yet still relies on
a temporary string an parsing for double an float.
It does attempt to do some handling of nan and +/-inf. I propose this
patch for the trunk. The release branch should probably only add the
GSPrivateDefaultLocale.
The patch also add NAN handling for NSDecimalDouble.
From Working on this patch, I think that the _public_ API, which only
includes ...
/** Give back the value of a NSDecimal as a double in (preallocated)
result. */
GS_EXPORT double
NSDecimalDouble(NSDecimal *number);
..., is missing the following conversion functions:
void GSFloatDecimal(NSDecimal *result, float value);
void GSDoubleDecimal(NSDecimal *result, double value);
void GSLongDoubleDecimal(NSDecimal *result, long double value);
These functions would be implemented via GMP where available or via
format string processing otherwise. Possibly the API should allow for
explicit precision:
void GSFloatDecimal(NSDecimal *result, float value, unsigned prec);
void GSDoubleDecimal(NSDecimal *result, double value, unsigned prec);
void GSLongDoubleDecimal(NSDecimal *result, long double value, unsigned
prec);
Cheers,
David
Index: Source/NSDecimalNumber.m
===
--- Source/NSDecimalNumber.m (Revision 24312)
+++ Source/NSDecimalNumber.m (Arbeitskopie)
@@ -26,6 +26,9 @@
$Date$ $Revision$
*/
+#define _GNU_SOURCE
+#include math.h
+
#include Foundation/NSCoder.h
#include Foundation/NSDecimal.h
#include Foundation/NSDecimalNumber.h
@@ -235,14 +238,146 @@
*/
- (id) initWithBytes: (const void*)value objCType: (const char*)type
{
- double tmp;
- NSString *s;
+ unsigned long long val;
+ long long llval;
+ NSDecimal decimal;
+ BOOL negative, llvalSet;
- memcpy(tmp, value, sizeof(tmp));
- s = [[NSString alloc] initWithFormat: @%g, tmp];
- self = [self initWithString: s];
- RELEASE(s);
- return self;
+ if (strlen(type) != 1)
+{
+ DESTROY(self);
+ return nil;
+}
+
+ llvalSet = YES;
+ negative = NO;
+
+ switch (*type)
+{
+case _C_CHR:
+ {
+ signed char v = *(signed char *)value;
+ llval = (long long)v;
+ break;
+ }
+case _C_UCHR:
+ {
+ unsigned char v = *(unsigned char *)value;
+ llval = (long long)v;
+ break;
+ }
+case _C_SHT:
+ {
+ short v = *(short *)value;
+ llval = (long long)v;
+ break;
+ }
+case _C_USHT:
+ {
+ unsigned short v = *(unsigned short *)value;
+ llval = (long long)v;
+ break;
+ }
+case _C_INT:
+ {
+ int v = *(int *)value;
+ llval = (long long)v;
+ break;
+ }
+case _C_UINT:
+ {
+ unsigned int v = *(unsigned int *)value;
+ llval = (long long)v;
+ break;
+ }
+case _C_LNG:
+ {
+ long v = *(long *)value;
+ llval = (long long)v;
+ break;
+ }
+case _C_ULNG:
+ {
+ unsigned long v = *(unsigned long *)value;
+ llval = (long long)v;
+ break;
+ }
+#ifdef _C_LNGLNG
+case _C_LNGLNG:
+#else
+case 'q':
+#endif
+ {
+ long long v = *(long long *)value;
+ llval = (long long)v;
+ break;
+ }
+#ifdef _C_ULNGLNG
+case _C_ULNGLNG:
+#else
+case 'Q':
+#endif
+default:
+ {
+ llvalSet = NO;
+ break;
+
+ }
+}
+ if (llvalSet)
+{
+ if (llval0)
+ {
+ negative = YES;
+ llval *= -1;
+ }
+ val = llval;
+}
+ else
+{
+ switch (*type)
+ {
+ case _C_FLT:
+ {
+ NSString *s;
+ float v = *(float *)value;
+ if (isnanf(v)) return notANumber;
+ if (isinff(v)) return (v 0.0) ? minNumber : maxNumber;
+ s = [[NSString alloc] initWithFormat: @%g
+ locale: GSPrivateDefaultLocale(), (double)v];
+ self = [self initWithString: s];
+ RELEASE(s);
+ return self;
+ break;
+ }
+ case _C_DBL:
+ {
+ NSString *s;
+ double v = *(double *)value;
+ if (isnan(v)) return notANumber;
+ if (isinf(v)) return (v 0.0) ? minNumber : maxNumber;
+ s = [[NSString alloc] initWithFormat: @%g
+ locale: GSPrivateDefaultLocale(), v];
+ self = [self initWithString: s];
+ RELEASE(s);
+ return self;
+ break;
+ }
+#ifdef _C_ULNGLNG
+ case _C_ULNGLNG:
+#else
+ case 'Q':
+#endif
+ {
+ val = *(unsigned long long *)value;
+ break;
+ }
+ }
+}
+
+ NSDecimalFromComponents(decimal, val,
+ 0, negative);
+ return [self initWithDecimal: decimal];
}
- (id) initWithDecimal: (NSDecimal)decimal
Index: Source/NSDecimal.m
===
--- Source/NSDecimal.m (Revision 24312)
+++ Source/NSDecimal.m (Arbeitskopie)
@@ -26,6 +26,7 @@
$Date$ $Revision$
*/
+#define _GNU_SOURCE
#include math.h
#if !defined(__APPLE__) || !defined(GNU_RUNTIME)
#include ctype.h
@@ -35,6 +36,10 @@
#include Foundation/NSDictionary.h
#include Foundation/NSUserDefaults.h
+#ifndef NAN
+#define NAN 0.0
+#endif
+
/*
This file
Re: Test base library stable branch please
Graham J Lee schrieb:
On 2 Jan 2007, at 10:16, David Ayers wrote:
I'm not sure if I fully agree here. I would have expected
@1.234,57 which of course would have also failed the test. So yes,
the test cases need to honor localisation, yet the formatting does not
produce the expected result.
Let me know if you need me to debug this.
Yes please. It passes on my system (obviously, or I wouldn't have
committed the patch ;-)) and I can't work out how to end up with a
decimal point but no decimal places, given the default format string.
I think the reason the thousands separator and decimal place are
non-localised is a bug in -[NSNumberFormatter init], which I haven't
addressed. Shouldn't be too hard to fix though.
OK, then... I haven't wrapped my mind around the documentation or
implementation of the formatter yet but it seems this is an issue with
NSDecimalNumber and has nothing to do with the formatter.
The issue seems to be in NSDecimalNumber.m :
/**
* Inefficient ... quick hack by converting double value to string,
* then initializing from string.
*/
- (id) initWithBytes: (const void*)value objCType: (const char*)type
{
doubletmp;
NSString *s;
memcpy(tmp, value, sizeof(tmp));
s = [[NSString alloc] initWithFormat: @%g, tmp];
self = [self initWithString: s];
RELEASE(s);
return self;
}
where s = @1234.57
and initWithString: uses
GSPrivateDefaultLocale:
{... NSDecimalSeparator = ,; ... NSThousandsSeparator = ;... }
which was correctly extracted from the locale information.
So ...
s = [[NSString alloc] initWithFormat: @%g, tmp];
... is returning @1234.57.
If I printf(###:%g\n,tmp) I do get
###:1234,57
So let's look at initWithFormat: and it is documented to pass a nil
locale which implies non-localized format, i.e. it is in fact doing the
correct thing. NSDecimalNumber's initWithString: OTOH doesn't mention
how it handles the locale but our implementation uses the default locale
as determined by GSPrivateDefaultLocale().
So my best guess is to improve the hack by calling:
s = [[NSString alloc] initWithFormat: @%g
locale: GSPrivateDefaultLocale(), tmp];
But maybe someone wants do the honors of implemeting a more direct
double-decimal conversion... (I'll might look into it if people think
it's worthwhile).
Cheers,
David
PS:
PASS: +[NSNumberFormatter alloc] returns a NSNumberFormatter
PASS: default format same as Cocoa
PASS: round up for fractional part 0.5
PASS: round down for fractional part 0.5
PASS: numeric and space padding OK
PASS: prefix and suffix used properly
PASS: negativeFormat used for -ve number
PASS: notANumber special case
PASS: format string of length 1
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Test base library stable branch please
Richard Frith-Macdonald schrieb: Could people please make an effort to check out the stable branch (http://svn.gna.org/viewcvs/gnustep/libs/base/branches/base-1_13_0/) of the base library from subversion and check that none of the backported bugfixes is faulty. I would like to make a bugfix release early in January... and we obviously need to do some testing. If anyone knows of any bugfixes (that's fixes only, not changes/ additions) in trunk which have not been backported and should be, please let me know. I've build: make-1_13_0 base-1_13_0 (from branches as opposed to tags) gui-0_11_0 back-0_11_0 gorm-1_1_0 gdl2 (trunk which I hope to release once the next wave of core releases is out) And these are my test results: 2 COMPILEFAIL COMPILEFAIL: SelfContainedHeaders/GNUstepBase/GSIArray.h.m COMPILEFAIL: SelfTests/compile.m (These are supposed to fail) 516 COMPLETED 1 Connection 12 FAIL PASS: +[NSNumberFormatter alloc] returns a NSNumberFormatter FAIL: default format same as Cocoa FAIL: round up for fractional part 0.5 FAIL: round down for fractional part 0.5 FAIL: numeric and space padding OK FAIL: prefix and suffix used properly FAIL: negativeFormat used for -ve number PASS: notANumber special case FAIL: format string of length 1 COMPLETED: base/NSNumberFormatter/basic.m (I suppose these haven't backported) PASS: NSURL +alloc returns an NSURL PASS: NSURL +fileURLWithPath: returns an NSURL PASS: NSURL +URLWithString: returns an NSURL PASS: Can put a pound sign in a file URL PASS: Scheme of file URL is file PASS: Can load a page from www.w3.org PASS: Status of load is 200 for www.w3.org FAIL: URL with 'this isn't a URL' returns nil PASS: Status of load is 404 for www.w3.org/silly-file-name PASS: Scheme of http://www.w3.org/silly-file-name is http PASS: Host of http://www.w3.org/silly-file-name is www.w3.org PASS: Path of http://www.w3.org/silly-file-name is /silly-file-name COMPLETED: base/NSURL/basic.m FAIL: first item is selected by default COMPLETED: gui/NSPopUpButton/defaultSelection.m PASS: browser initially contains all files PASS: browser is reloaded after -setDelegate: FAIL: browser contains all files after resetting delegate PASS: browser is reloaded after -setDelegate: (2) COMPLETED: gui/NSSavePanel/setDelegate_reload.m And the following tests which ares supposed to fail: FAIL: SelfTests/crash.m FAIL: Dummy failing test. 66 HINWEIS 5668 PASS 1 Server I've also played a bit with GDL2 the palette in Gorm but noticed nothing that seemed to be an issue with -base. Cheers, David PS: I still believe we should adopt a naming convention for branches which includes only major and minor version numbers and use subminor numbers soley for taging releases from the branches. e.g.: .../libs/branches/base-1_11 .../libs/branches/base-1_12 .../libs/branches/base-1_13 .../libs/tags/base-1_11_0 .../libs/tags/base-1_11_1 .../libs/tags/base-1_12_0 .../libs/tags/base-1_13_0 .../libs/tags/base-1_13_1 With the current situations the identifier base-1_13_0 is ambiguous as it is used in both branches and and tags: .../libs/branches/base-1_13_0 .../libs/tags/base-1_13_0 and I'm not sure whether 1.13.1 release will only be tagged or whether another release branch will also be created. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Test base library stable branch please
David Ayers schrieb: Richard Frith-Macdonald schrieb: Could people please make an effort to check out the stable branch (http://svn.gna.org/viewcvs/gnustep/libs/base/branches/base-1_13_0/) of the base library from subversion and check that none of the backported bugfixes is faulty. I would like to make a bugfix release early in January... and we obviously need to do some testing. If anyone knows of any bugfixes (that's fixes only, not changes/ additions) in trunk which have not been backported and should be, please let me know. I've build: make-1_13_0 base-1_13_0 (from branches as opposed to tags) gui-0_11_0 back-0_11_0 gorm-1_1_0 gdl2 (trunk which I hope to release once the next wave of core releases is out) And these are my test results: 2 COMPILEFAIL COMPILEFAIL: SelfContainedHeaders/GNUstepBase/GSIArray.h.m COMPILEFAIL: SelfTests/compile.m (These are supposed to fail) 516 COMPLETED 1 Connection 12 FAIL PASS: +[NSNumberFormatter alloc] returns a NSNumberFormatter FAIL: default format same as Cocoa FAIL: round up for fractional part 0.5 FAIL: round down for fractional part 0.5 FAIL: numeric and space padding OK FAIL: prefix and suffix used properly FAIL: negativeFormat used for -ve number PASS: notANumber special case FAIL: format string of length 1 COMPLETED: base/NSNumberFormatter/basic.m (I suppose these haven't backported) Actually I get these failures on the trunk also... So I'll need to investigate... (possibly associated with my locale settings for decimal points?) base/NSNumberFormatter/basic.m: FAIL: default format same as Cocoa FAIL: round up for fractional part 0.5 FAIL: prefix and suffix used properly FAIL: negativeFormat used for -ve number FAIL: format string of length 1 Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Test base library stable branch please
David Ayers schrieb:
Actually I get these failures on the trunk also... So I'll need to
investigate... (possibly associated with my locale settings for decimal
points?)
Indeed this code looks very suspicious:
// if no format specified, use the same default that Cocoa does
if (nil == useFormat)
{
useFormat = negativeNumber ? @-#,###.## : @#,###.##;
}
as does the preexisting code:
- (id) init
{
ido;
_allowsFloats = YES;
_decimalSeparator = '.';
_thousandSeparator = ',';
...
Shouldn't the format honor the values for NSLocaleDecimalSeparator and
NSLocaleGroupingSeparator somehow obtained via NSUserDefaults (or
NSLocale once we have that class)?
Currently in a de_AT.UTF-8 locale these tests fail:
base/NSNumberFormatter/basic.m:
FAIL: default format same as Cocoa
pass([str isEqual: @1,234.57], default format same as Cocoa);
where str = @1,234.
FAIL: round up for fractional part 0.5
pass([str isEqual: @1,235], round up for fractional part 0.5);
where str = @1,234
FAIL: prefix and suffix used properly
pass([str isEqual: @$1234.56c], prefix and suffix used properly);
where str = @$1234.c
FAIL: negativeFormat used for -ve number
pass([str isEqual: @-$(1234.56)], negativeFormat used for -ve number);
where str = @-$(1234.)
FAIL: format string of length 1
pass([str isEqual: @-1235], format string of length 1);
where str = @-1234
Please let us know if this can be addressed before the next stable
branch of -base (not the upcoming bug fix release which doesn't contain
the new code yet) as these formatters will become more interesting for
GDL2 as EOInterface evolves. If you don't have the time, I might try to
find some.
Cheers,
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem with r24204
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marcus Müller schrieb:
since upgrading to gnustep-base r24204 I have encountered a serious
problem with my app - I get the following backtrace:
#0 -[NSException raise] (self=0x815b568, _cmd=0x2891ad88) at
NSException.m:694
#1 0x2871dbf5 in +[NSException raise:format:arguments:] (self=0x2891ad00,
_cmd=0x2891ad70, name=0x2891ae54, format=0x28964bf4,
argList=0xbfbfe490 ò\034\220(\aÒ\216(4\207\225(ØP~(\bµ\025\b\aÒ
\216(4\207\225(üÚq() at NSException.m:640
#2 0x2871db44 in +[NSException raise:format:] (self=0x2891ad00,
_cmd=0x28964968, name=0x2891ae54, format=0x28964bf4) at
NSException.m:626
#3 0x287e5182 in -[NSObject(GSCategories) subclassResponsibility:] (
self=0x80d9298, _cmd=0x28903280, aSel=0x28934bb8) at
GSCategories.m:1038
#4 0x286c8335 in -[NSMutableArray addObject:] (self=0x80d9298,
_cmd=0x28934bb8, anObject=0x815b508) at NSArray.m:1359
#5 0x2876d353 in _gnu_process_args (argc=5, argv=0x8099440,
env=0x8098400)
at NSProcessInfo.m:413
#6 0x2876d9e8 in +[NSProcessInfo initialize] (self=0x28934a60,
_cmd=0x28953508) at NSProcessInfo.m:823
#7 0x2897bd03 in __objc_install_premature_dtable () from /usr/lib/
libobjc.so.2
#8 0x2897c3cc in objc_msg_lookup () from /usr/lib/libobjc.so.2
#9 0x280ec3ca in -[WOApplication init] (self=0x80be408, _cmd=0x80535e8)
at WOApplication.m:338
#10 0x08049960 in -[Application init] (self=0x80be408, _cmd=0x282197e8)
at Application.m:15
#11 0x28120a27 in WOApplicationMain (_appClassName=0x8053260, argc=5,
argv=0xbfbfe788) at WOApplicationMain.m:40
#12 0x080498e2 in main (argc=5, argv=0xbfbfe788) at itms_main.m:16
I can only suspect that somehow the code for setting up the subclasses
of the NSArray classcluster has been broken to work at such an early
stage. Unfortunately I don't have the time right now to look into this
matter - does somebody else know what's possibly going wrong?
I've just updated and recompiled everything to r24204 (which did break
binary compatibility) and the test suite passes and my GSWeb apps also
work fine for me.
Maybe you just need to recompile due the ABI change. If not, what are
the results of the base test suite?
I'd check with ldd to make sure that you only have one version of -base
linked against your application and any frameworks/libraries you are using.
If that doesn't help, please try to confirm that the array which
_gnu_process_args creates here:
/* Copy the evironment list */
{
NSMutableArray *keys = [NSMutableArray new];
is actually a GSMutableArray. This array should implement addObject:
directly, i.e. it doesn't rely on:
+ (void) initialize
{
if (self == [GSMutableArray class])
{
[self setVersion: 1];
GSObjCAddClassBehavior(self, [GSArray class]);
}
}
for this particular method. But maybe something else has corrupted the
dispatch tables of class. But that's going to hard to determine via E-mail.
Cheers,
David
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFFgn6g1Z7XJZzbH3ARArrMAKCZ7ct6fRfGXMjqjXF9hpNw6/vxHQCfWq69
dwpYwBZ0cEjhB5Zf2s5PEAM=
=pWrX
-END PGP SIGNATURE-
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r24082 - in /tests/testsuite/trunk: ChangeLog base/NSCalendarDate/basic.m base/NSCalendarDate/test00.m base/NSCalendarDate/test01.m base/NSCalendarDate/test02.m base/NSDate/create.m
Richard Frith-Macdonald schrieb: On 13 Nov 2006, at 21:09, David Ayers wrote: --- /tests/testsuite/trunk/base/NSDate/create.m2006/11/13 16:50:30 24081 +++ tests/testsuite/trunk/base/NSDate/create.m2006/11/13 17:07:10 24082 @@ -10,7 +10,7 @@ NSString *val; NSDate *date1,*date2; - val = @2000-10-19; + val = @2000-10-19 00:00:00 +; date1 = [NSDate date]; pass(date1 != nil [date1 isKindOfClass:[NSDate class]], +date works); I'm not sure about this change to the test suite... Does this imply that constructing an NSDate with an ISO date without specifing the time is invalid? I'm afraid that may break some adaptor implementations where the database fields differentiate between dates and timestamps. Yes it does mean that it's invalid ... if you want to create a date from a string without the timestamp then the format should not contain a timestamp part. Such code would not work on MacOS-X (or with the base library with the appropriate bugfix). The method initWithString... is explicitly documented to say that the string must match the format. Well I guess that's a unfortunate result of an evolving API. It implies that the date class of an EOAttribute must be an NSCalendarDate (or subclass thereof) since NSDate does not have the API to specify a format. I'm almost certain (but just haven't found to verify) that OPENSTEP allowed ISO dates without timestamps for NSDate class. But oh well... Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
