Re: objc native exceptions
Hi, 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. Thanks, Graham. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
On 10 Apr 2008, at 18:51, Hubert Chathi wrote: If you have a GNUstep program that is licensed under the terms of the GPLv2 *only*, you should do one of the following (in no particular order): - change the license to GPLv2 or later - change the license to GPLv3 (or later) - change the license to something completely different that the LGPLv3 is compatible with (e.g. MIT, 3-clause BSD) - add an exception that allows linking with the GNUstep libraries or LGPL'ed libraries (e.g. see for example http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface or http://price.sourceforge.net/exception.html Presumably, distributing binaries linked against earlier, pre-LGPLv3 GNUstep libraries is acceptable too (whether or not anyone likes the idea); I guess the licence change wasn't propagated back through the SCM history to retroactively apply to earlier revisions of GNUstep. Thanks, Graham. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Short report from FOSDEM
On 26 Feb 2008, at 07:56, Graham J Lee wrote: On 25 Feb 2008, at 23:44, Nicolas Roard wrote: Also, I have to remind people that there is a gnustep/etoile coding party organized over easter at Swansea University in Wales (UK), and people are more than welcome ! URL? :-) At risk of replying to myself: http://gnustep.blogspot.com/2008/02/toil-spring-hackathon.html Graham. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Short report from FOSDEM
On 25 Feb 2008, at 23:44, Nicolas Roard wrote: Also, I have to remind people that there is a gnustep/etoile coding party organized over easter at Swansea University in Wales (UK), and people are more than welcome ! URL? :-) Graham. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling from Mac OS X
On 21 Aug 2007, at 06:36, Gregory John Casamento wrote: All, Just wondering if anyone has any thoughts on how to approach this. Vague thoughts, but nothing concrete / guaranteed to work. It seems to me [and I'm discussing UNIX+ELF-like targets, as I really have no clue about Windows] that actually all you have to do is provide a cross-compiling toolchain and set the appropriate GNUSTEP_TARGET_* variables such that it uses aforementioned cross-compiler. If that doesn't already work on Mac OS X, then it's for some reason that reading the Makefiles doesn't make obvious. Basically, I'd like to implement it so that the Cocotron guys have no advantage over GNUstep. But we have t-shirts and other swag, does that count for nothing? :-) Would anyone like to take this on? Seems like it could be interesting, sadly I lack a non-Mac box at the moment which makes it rather hard to do (and still need to sort out updating my copyright assignment). Cheers, Graham. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problems compiling NSAnimation.m
On 9 May 2007, at 17:53, Xavier Glattard wrote:
Riccardo multix at ngi.it writes:
#define _NSANIMATION_LOCK \
BOOL __gs_isLocked = NO; \
if (_isThreaded) \
{ \
__gs_isLocked = YES;\
NSDebugFLLog( at NSAnimationLock,\
at % at LOCK % at ,self,[NSThread
currentThread]);\
[_isAnimatingLock lock];\
}
it causes a hidden c99-ism everywhere. If the definition of
I wrote this stuff, so i guess i could help ;-)
I dont know if this can be avoided :
This is coming from a position of not having been tested nor even
thought through properly, but how about:
#define _NSANIMATION_LOCK \
{ BOOL __gs_isLocked = NO; \
//... \
}
? That should remove the C99-esque behaviour - I don't _think_ it
makes the macro any less usable than it already was but as I say, I
haven't studied its use much.
Graham.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problems compiling NSAnimation.m
On 10 May 2007, at 12:35, Nicola Pero wrote: Is there a flag we can pass to ask GCC to refuse c99-isms ? There must be one. -std=c89 or -std=gnu89 depending on whether we want to permit GNU C extensions. Cheers, Graham. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problems compiling NSAnimation.m
On 10 May 2007, at 13:44, Nicola Pero wrote: Sorry, forgot to put the mailing list in Cc: Thanks Is there a flag we can pass to ask GCC to refuse c99-isms ? There must be one. -std=c89 or -std=gnu89 depending on whether we want to permit GNU C extensions. Nicola answered: Actually, they seem to work -- the problem is that -std=gnu89 is already the standard, but was changed in GCC 3.0 to allow declarations of variables in the middle of code (which are, in this context, a 'GNU extension' borrowed from c99). I think what we want is -Wdeclaration-after-statement The problems are: * not sure if that flag is available with GCC 2.95 -- need to check what happens if you use it with GCC 2.95 * it generates a warning, not an error Anyway, I'll add that flag to the core libs. Thanks How about -Werror? That might encourage people to clean up any existing mess too ;-). OTOH it might be a scary amount of mess... Cheers, Graham. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problems compiling NSAnimation.m
On 10 May 2007, at 15:28, Xavier Glattard wrote: Richard Frith-Macdonald richard at tiptree.demon.co.uk writes: On 10 May 2007, at 14:57, Xavier Glattard wrote: Richard Frith-Macdonald richard at tiptree.demon.co.uk writes: I fixed this to make __gs_isLocked an ivar rather than declaring it locally (which was pretty suboptimal). I also fixed a bug in the unlock macro (it was setting the lag to the wrong value), and added assertions to check that the macro is not misused. Bad. If __gs_locked is needed (and as i said i think it is not : i made an error) then it must be declared in all methods. If __gs_isLocked is an ivar, its value can be changed in another method then the [unlock] will never be called. Sure, but similarly if it's a local variable its value can be incorrectly changed within a method or function where it is declared. If it is then you made an other programming error... ;-) Its name is prefixed by an underscore (and by 'gs'!) so it shouldn't be used by anyone. Moreover an ivar is more easier to be incorrectly changed... in an other method or even in a child class! That's one of the reasons I suggested wrapping the whole macro in braces - the BOOL then becomes a local variable to the macro - reduces the chance of accidentally changing it by restricting the scope to only where it's used. Cheers, Graham. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Test base library stable branch please
On 25 Jan 2007, at 22:49, David Ayers wrote: Graham J Lee schrieb: 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. Ah, OK. I'm happy to write a few more tests for [NG]SDecimalNumber. If you could send me some examples of things you found broken which are fixed by your patch or by Richard's fixes, I'll incorporate those to avoid dupliacting them myself ;-) [...] 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. OK, I tend to run tests on both Cocoa and GS to look for differences, so I'll check into that anyway. Again, any example you already have cooked up for this would be welcome ;-) Cheers, Graham. P.S. I think we definitely could do with NSLocale for formatting and so forth. I think I could implement this for POSIX-esque systems so will give it a go; having no clue HTF Windows i18n works I will avoid offering a cross-platform solution though ;-). But, having never implemented a GS class from scratch before, especially one which isn't part of the OpenStep specification: any copyright/left pitfalls? Any API-matching @interface of a Cocoa class is obviously going to look remarkably similar to an Apple header file, is using their API documentation and writing my own header file from scratch appropriate? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Test base library stable branch please
On 2 Jan 2007, at 09:38, [EMAIL PROTECTED] wrote:
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)?
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 :-)
Cheers,
Graham.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Test base library stable branch please
On 2 Jan 2007, at 10:16, David Ayers wrote: [EMAIL PROTECTED] schrieb: David Ayers schrieb: 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. It's the tests which are broken in this case, as they compare the result of the formatting to a non-localised string (i.e. they work fine on my system in C locale, but would break in other locales). I don't know when I'll have time to fix the tests so do look at it if you want, otherwise I'll try to fix it sometime soon. 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. Cheers, Graham. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
