Re: Fwd: emacs.app does not support -GSFilePath
On 2007-01-25 03:06:09 +0200 Adrian Robert <[EMAIL PROTECTED]> wrote:
Hello,
Someone was asking me about whether Emacs.app supports the "- GSFilePath"
option which GWorkspace uses to tell applications to open files. I thought
that there were already two ways to do this in OpenStep / Cocoa: "-NSOpen"
option, and NSApplication- application:openFIle: method via DO or
notifications. Is this correct or is the GNUstep-specific -GSFilePath
really needed?
thanks,
Adrian
If the application is running GWorkspace uses -application:openFIle:, if not it
launches it with -GSFilePath and the path of the file to open as arguments.
In NSWorkspace.m I read:
* If the Info-gnustep.plist of an application says that it
* can open files with a particular extension, then when NSWorkspace
* is asked to open such a file it will attempt to send an
* -application:openFile: message to the application (which must be
* handled by the applications delegate). If the application is not
* running, NSWorkspace will instead attempt to launch the application
* passing the filename to open after a '-GSFilePath' flag
* in the command line arguments. For a GNUstep application, the
* application will recognize this and invoke the -application:openFile:
* method passing it the file name.
*
and, in NSApplication.m, we find:
/*
*Now check to see if we were launched with arguments asking to
*open a file. We permit some variations on the default name.
*/
if ((filePath = [defs stringForKey: @"GSFilePath"]) != nil
|| (filePath = [defs stringForKey: @"NSOpen"]) != nil)
{
[_listener application: self openFile: filePath];
}
...
That is, NSApplication treats "GSFilePath" and "NSOpen" as the same thing and,
if Emacs.app implements -application:openFIle: in its delegate, this is the method that will be
called.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
GNUstep Testfarm Results
Test results for GNUstep as of Thu Jan 25 06:34:18 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-netbsdelf3.1 Thu Jan 25 03:55:21 CET 2007 Fail Compile powerpc-apple-darwin8.8.0 Thu Jan 25 00:24:44 MST 2007 Success Compile sparc-sun-solaris2.7 Thu Jan 25 01:30:34 EST 2007 Success Compile x86_64-unknown-linux-gnu Thu Jan 25 04:09:17 GMT 2007 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Fwd: emacs.app does not support -GSFilePath
Adrian Robert schrieb: > Someone was asking me about whether Emacs.app supports the "-GSFilePath" > option which GWorkspace uses to tell applications to open files. I > thought that there were already two ways to do this in OpenStep / Cocoa: > "-NSOpen" option, and NSApplication-application:openFIle: method via DO > or notifications. Is this correct or is the GNUstep-specific > -GSFilePath really needed? > Not sure, if I did understand your question. The code in [NSApplication finishLaunching] supports NSOpen and GSFilePath, so if an application inherits from this class it should just work with both parameters. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
On 2007-01-24 22:05:26 -0800 Nicola Pero <[EMAIL PROTECTED]> wrote: but my main problem with GNUstep.sh isn't actually technical at all, its the very first thing potential developers are going to see, so will be the first impression, and imho gives the impression of being strange because it is uncommon for a build system to depend on environment variables to function. I looked at your patch and I understand what you're trying to do ... it's good stuff and it's good to have this discussion, but let me first insist in claryfying something ... ;-) The build system does not depend on GNUstep.sh at all. We spent years working on removing that dependency, and it's no longer there! :-) It's not advertised much yet, but it will be clearly advertised in the release note of the forthcoming gnustep-make release. GNUstep.sh is obsolete in the default setup. You only need to set GNUSTEP_MAKEFILES and everything will work (assuming you have your tools in your path, and libs in your linker paths). This is all already implemented on trunk! :-) Yes, but you still need to do something before running make, which is what this patch is mostly about. You only need to set GNUSTEP_MAKEFILES. This is already on trunk! Once that's clear, we can discuss the patch ;-) I see two good ideas in the patch ... 1. I guess you are suggesting to put a makefile somewhere in the make search path and change all makefiles to include it so that you can compile without even setting GNUSTEP_MAKEFILES. I like the idea of not having to set any variable to compile, but I also see a couple of obvious cons -- it would be more difficult to switch between different gnustep-make installations (at the moment, you can easily switch by just changing GNUSTEP_MAKEFILES!), Not really, the patch allows you to switch installations by setting PKG_CONFIG_PATH and specifying --with-pkgconfig-path to configure to tell it where to put gnustep.pc. The difference being instead of always having to configure it, configuration is made to be something only people who need that behaviour have to do. and we need to ask everyone on the planet to change their GNUmakefiles, and in a way that will likely make them stop working unless you use a recent gnustep-make - they won't like it. So we need to think a lot and make sure we make the right choice before we do it. Eg, if you have to modify your make include path to make this work, then you may as well ask people to set GNUSTEP_MAKEFILES. ;-) Well i still don't find this argument very compelling, for some undeterminable amount of time we need to source GNUstep.sh or set GNUSTEP_MAKEFILES to compile old software, of course it isn't forwards compatible so new software wouldn't compile on older installations 2. you're suggesting to have a script that can help ./configure scripts examine the filesystem for GNUstep softtware. That sounds good, but having the script return GNUSTEP_SYSTEM_ROOT, GNUSTEP_LOCAL_ROOT etc seems the wrong thing to do -- these are the variables that make it difficult to switch to Linux FHS and we are trying to move away from them! In fact, we have already moved away from them. As shell variables, they are obsolete and should not be used! Yeah, the stuff stored inside gnustep.pc is by no means required to contain SYSTEM_ROOT/LOCAL_ROOT etc If these things change (as indeed it seems they have) so should the gnustep.pc, it was mainly intended as a demonstration to show how i was imagining this working anyhow yeah if e,g, $GNUSTEP_SYSTEM_ROOT/Library/Libraries is no longer reliable this will need to change Finally, your gnustep.pc seems a duplicate of /etc/GNUstep.conf! ;-) yeah it is, its a duplicate of a home-brew method, to use a relatively standard method though GNUstep.conf is available only to GNUstep, only GNUstep knows where it exists because its path is configurable. I assume you can set GNUSTEP_CONFIG_FILE (or something) to tell GNUstep where to find it, but this doesn't help in finding the deafult which is used if GNUSTEP_CONFIG_FILE (or something) doesn't exist. If the information in it is only attainable by GNUstep and no longer available in environment variables (or reliable if we can no longer $GNUSTEP_XX_ROOT/Library/Libraries for AC_CHECK_LIB) then i wouldn't consider it a complete solution anyhow If i understood correctly, i thought GNUstep.conf was initially always hard coded to /etc/GNUstep.conf and was intended to make stuff like GNUstep variables available to shell scripts and what not, then /path/to/GNUstep.conf became configurable at some point and it lost this purpose, and the purpose then was limited to configuration of GNUstep variables at runtime -- replacing the environment variables... but maybe I was wrong with that assumption ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/
Re: emacs.app does not support -GSFilePath
On Jan 25, 2007, at 6:27 AM, Enrico Sersale wrote: On 2007-01-25 03:06:09 +0200 Adrian Robert <[EMAIL PROTECTED]> wrote: Hello, Someone was asking me about whether Emacs.app supports the "- GSFilePath" option which GWorkspace uses to tell applications to open files. I thought that there were already two ways to do this in OpenStep / Cocoa: "-NSOpen" option, and NSApplication- application:openFIle: method via DO or notifications. Is this correct or is the GNUstep-specific -GSFilePath really needed? thanks, Adrian That is, NSApplication treats "GSFilePath" and "NSOpen" as the same thing and, if Emacs.app implements -application:openFIle: in its delegate, this is the method that will be called. OK, thanks for this info, I will make sure -GSFilePath makes it through emacs' own argument screener. Does GSFilePath have any different semantics than NSOpen? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Thanks for your suggestions You seem to think that the current solution lacks: 1. a way to compile without setting GNUSTEP_MAKEFILES 2. a way to get the GNUstep bundle/libs/tools search paths for use in configure scripts etc. I agree we can do better to address those. Solutions that came to mind as natural ones would be to -- 1. have a (trivial) makefile fragment that locates gnustep-make and you can include in your project to make it bootstrap without having to rely on GNUSTEP_MAKEFILES being set (I suppose we should also consider just putting it into your make include path). 2. have a (trivial) shell script that can output the list of GNUstep bundle/libs/tools search paths. We install this as a system tool, so under Linux FHS it will automatically be in your PATH and you can just invoke it whenever you need (similar to the all the config files of other software that you mention). Maybe for 2. we could take the standard OpenStep search methods (for bundles etc.) and have shell script equivalents for them. That would seem like a reasonable way of designing our shell 'API' to get the filesystem locations, in a way that would work with Linux FHS as well. I was now feeling like jumping in and implementing all that, but it will likely be a few iterations and discussions before we get something good and stable, and if we're trying to make a release in the next few weeks, it's not the right time to add new stuff. 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 ? ;-) Thanks ___ 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: gnustep-make experiment
On 2007-01-25 06:48:50 -0800 Nicola Pero <[EMAIL PROTECTED]> wrote: Thanks for your suggestions You seem to think that the current solution lacks: 1. a way to compile without setting GNUSTEP_MAKEFILES 2. a way to get the GNUstep bundle/libs/tools search paths for use in configure scripts etc. I agree we can do better to address those. Solutions that came to mind as natural ones would be to -- 1. have a (trivial) makefile fragment that locates gnustep-make and you can include in your project to make it bootstrap without having to rely on GNUSTEP_MAKEFILES being set (I suppose we should also consider just putting it into your make include path). true, this could be something similar to what i put in gnustep.make GNUSTEP_MAKEFILES ?= $(shell pkg-config --variable makefiles gnustep) include $(GNUSTEP_MAKEFILES)/common.make this should actually work with older installations of gnustep. the whole make bootstrap path thing that is admittedly just a hack but "include gnustep.make" was easier to remember than adding the above, shell snippet if adding some new line to makefiles is acceptable i'd be completely fine with that. maybe thats not what you meant though, its another idea anyhow... I was now feeling like jumping in and implementing all that, but it will likely be a few iterations and discussions before we get something good and stable, and if we're trying to make a release in the next few weeks, it's not the right time to add new stuff. I most definately agree on this 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 ? ;-) Sure, thanks for hearing me out :D ___ 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
On Jan 26, 2007, at 24:04, David Ayers wrote: 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. Thats a good point. The last gstep-make release already gave us a major headache. Well, if the next one is explicitly marked as unstable it would be probably OK ;-) Thanks, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
> 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. That's a good point to discuss, on the other hand sooner or later we need to ship the changes so they start getting widespread. I believe we have enough changes to ship a new release! The main changes in the new gnustep-make are: * libraries have now the same name no matter if you compile them with debug, porofile, static or what. _d, _p, _dp etc. are gone. * applications have now the same name no matter if you compile them with debug or what. Gorm.debug is gone. Now it's only Gorm.app. * all object files are now put in ./obj. shared_obj, shared_debug_obj, etc. are gone. Those may require projects that contain custom makefile code to be updated! The other main change is that using GNUSTEP_SYSTEM_ROOT, GNUSTEP_LOCAL_ROOT, etc. in makefiles is now discouraged (because it won't work with Linux FHS). This has no effect though, for now you can happily use them. Also, the new release will work without sourcing GNUstep.sh, in which case you can't really use the GNUSTEP_SYSTEM_ROOT, etc. shell variables any more. They are effectively obsolete. Finally, the new gnustep-make supports GNUSTEP_INSTALLATION_DOMAIN and it's strongly recommended that this is used instead of GNUSTEP_INSTALLATION_DIR (GNUSTEP_INSTALLATION_DIR won't work with Linux FHS). You don't need to change it now, but over time we hope everyone will switch to GNUSTEP_INSTALLATION_DOMAIN I suppose maybe you (and Helge) are right, we could wait a few more months and finish off all changes, then we ship a gnustep-make 2.0.0 so there is a single major upgrade. ;-) It actually makes quite some sense, I'm tempted to do that now. :-) Comments welcome Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
