Re: make sysinstall/Makefile.preamble/GNUSTEP_INSTALLATION_DOMAIN
On 15 Dec 2008, at 11:00, David Chisnall wrote: I still don't fully understand the rationale for moving system packages out of System. That would be because system packages haven't been moved out of System there's no plan to ever move them. What's happened is a change to avoid people (GNUstep newbies in particular) accidentally overwriting system packages with their non- system locally built versions. Packagers should continue to provide their packages to install in the appropriate place for their system ... eg. I'd expect the core GNUstep stuff to be installed in the System domain on an Etilie-live CD. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: make sysinstall/Makefile.preamble/GNUSTEP_INSTALLATION_DOMAIN
On 15 Dec 2008, at 13:07, Fred Kiefer wrote: Richard's other ideas would be workable, but every GNUstep developer will need that, why not support it directly. Er ... I don't. I can just do 'make install' and everything works fine for me ... I really don't think you can say 'every GNUstep developer will need that' ... you could just as easily say 'No GNUstep developer will need that' In fact what we really need is someone installing everything into the System domain, someone installing everything into the Local domain, and someone installing everything into the User domain and some people working with combinations... so we are sure that everything works properly irrespective of where it's installed. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: make sysinstall/Makefile.preamble/GNUSTEP_INSTALLATION_DOMAIN
On 18 Dec 2008, at 19:58, Nicola Pero wrote: Let me know if there is any agreement on other pieces of software to include. Maybe we should include everything that is in the GNUstep subversion repository ? I was hoping for a smaller list, but at least that would provide an objective way to decide. I'm not in favor of this really for any packages ... I'd like not to have support for this cluttering anything. Admittedly the clutter is really trivial, but I see no benefit to it. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: GNUstep release [Was: New Slackware + GNUstep]
On 18 Dec 2008, at 05:36, Adam Fedor wrote: I have plenty of time now. I'll start working on releases soon, although Richard will probably be doing the base release. OK, so we are doing a new base stable release at version 1.18.0 I committed that version number bump to the stable branch so we can test it and add any tweaks needed. Do we have a definite date for the formal release? Presumably we want to do a new unstable release using the same code at 1.19.0, skipping the 1.17.0 in order to get back to the situation people seem to expect, where the latest unstable release is the odd minor version number after the latest stable release? If so, this could be done by little more than a change to the version number on trunk. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: make sysinstall/Makefile.preamble/GNUSTEP_INSTALLATION_DOMAIN
On 19 Dec 2008, at 10:18, Nicola Pero wrote: Let me know if there is any agreement on other pieces of software to include. Maybe we should include everything that is in the GNUstep subversion repository ? I was hoping for a smaller list, but at least that would provide an objective way to decide. I'm not in favor of this really for any packages ... I'd like not to have support for this cluttering anything. Admittedly the clutter is really trivial, but I see no benefit to it. Sorry ... too short. What I suggest is: 1. Unwind any changes to any packages to do with this ... intrusive changes to packages merely to support a installation location makes little sense. 2. Produce a different mechanism if you really want a mechanism for this at all. For instance, you could have a file listing the projects you want to install in the system domain, and gnustep-make could consult that file to decide where to install each project ... eg. if it's got to install a project X, it ooks up X in it's config file, and if it should you in domain Y then it sets GNUSTEP_INSTALLATION_DOMAIN to Y before proceeding. This would avoid the issue of having to decide which projects are 'core' (which is not something the developer/maintainer of the project should be doing). Yes ... I'm kind of unconvinced myself - even if the changes do implement exactly what was requested (ie, a backwards- compatibility mode where 'core' packages get installed into System in the same way as before). I'm kind of accepting that I don't really understand why people really need such a backwards-compatibility mode but we're providing it as a temporary measure while our hardcore developers digest the change and hopefully find more logical ways of building/ organizing their local installations. ;-) I like the idea of having a list of 'core' packages that each developer can set up and maintain ... but then well they could as well just set up and maintain a build script then, and we wouldn't even be having this discussion ;-) Yes, well that's my preferred option ... I only suggest the alternative as a solution for people who don't like the idea of doing it themselves. A script is much more handy in that it also builds things for you. I can't believe people are really rebuilding everything often and typing './configure; make; make install' manually for all the projects each time - including waiting for each command to complete before typing the next one (I hate that). ;-) I mean it's trivial to write such a script ... cd core/base ./configure make make install GNUSTEP_INSTALLATION_DOMAIN=SYSTEM cd .. cd core/gui ./configure make make install GNUSTEP_INSTALLATION_DOMAIN=SYSTEM cd .. ... etc ... I suppose the 'make install' having to be done as root might create a mild complication, but not something that would really deter a serious scripter. Shall we concentrate our work on providing template build scripts then ? I saw that Gregory made improvements to the core/compile-all script - maybe that's the way to go. I suspect that the single build script solution is not what people want ... I guess they want to (for example) just build/install one project at a time. They can't be bothered to type 'make install GNUSTEP_INSTALLATION_DOMAIN=SYSTEM' and can't be bothered to set up an alias to do that for them. Fundamentally we are wasting hours in discussing this because it's in the nature of human beings to be habit-ridden and therefore basically opposed to changing what they do in any respect whatsoever. I admit to feeling the same about it until I 'bought in' to the idea of making the build/install process as 'safe' for newbies as possible, and accepted that a tiny change in my operating practices was worthwhile to help popularise GNUstep. For people who have no interest in popularising the project, this can't be convincing and they will basically want everything to continue behaving exactly as it has before. So, you have to consider how much effort it's worth making to address the issues of a tiny minority. Of those issues, I only recall two that made any objective sense (ie some rationale beyond the 'i have to change my habit' one). Fred wanted to keep things in the SYSTEM domain for testing purposes ... to make sure core stuff continues to work when installed there. David wanted to be able to delete LOCAL to get rid of local stuff without effecting the system. In both of these cases an alias ought to work pretty well, and if you forget to use the alias and accidentally install in LOCAL when you wanted system, well you can just delete the LOCAL domain and do it again. To me, the downside of this just doesn't justify adding complexity to make and the core packages, but if this is what you want to avoid then a record (within the make system) of where you want to install each project seems the only way to go. The make system
Re: make sysinstall/Makefile.preamble/GNUSTEP_INSTALLATION_DOMAIN
On 19 Dec 2008, at 13:30, Wolfgang Lux wrote: I'm sorry, to me this still looks too complicated. Instead of having a centralized package database somewhere, just check for an optional configuration file (e.g., installation_domain) that is present in the package's directory. I think the downside of that is that it's easily accidentally deleted so the information is lost if you check out a new copy etc (you would also need a copy of the file in each subdirectory in the package that you might build from). I still think forgetting ALL this stuff is the best option... I can't really believe that the total amount of time/energy involved in people occasionally forgetting to install where they meant to install or writing their own scripts is likely to ever exceed the amount of time/ energy already spent on considering this. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
GNUstep-Base New stable release now available
1 Announcement ** ftp.gnustep.org pub/daily-snapshots The GNUstep Base Library, version 1.18.0, is now available. 1.1 What is the GNUstep Base Library? = The GNUstep Base Library is a library of general-purpose, non-graphical Objective C objects. For example, it includes classes for strings, object collections, byte streams, typed coders, invocations, notifications, notification dispatchers, moments in time, network ports, remote object messaging support (distributed objects), and event loops. It provides functionality that aims to implement the non-graphical portion of the OpenStep standard (the Foundation library). There is more information available at the GNUstep homepage at `http://www.gnustep.org'. ftp.gnustep.org pub/daily-snapshots 1.2 Noteworthy changes in version `1.18.0' == * Improved lookup of versioned library resources and improved location of resources based on the location of the executable under ms-windows. * Connection keepalive for ms-windows so that daemons can shut down automatically when all clients have disconnected. * Keyed archiving improvements for various classes. * Exception and thread handling improvments. * Portability improvments and MacOS-X compatibility improvements. 1.3 Where can you get it? How can you compile it? == The gnustep-base-1.18.0.tar.gz distribution file has been placed at `ftp://ftp.gnustep.org/pub/gnustep/core'. Please log bug reports on the GNUstep project page `http://savannah.gnu.org/bugs/?group=gnustep' or send bug reports to bug-gnus...@gnu.org. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
New Unstable release of GNUstep-base available.
1 Announcement ** ftp.gnustep.org pub/daily-snapshots The GNUstep Base Library, version 1.19.0, is now available. 1.1 What is the GNUstep Base Library? = The GNUstep Base Library is a library of general-purpose, non-graphical Objective C objects. For example, it includes classes for strings, object collections, byte streams, typed coders, invocations, notifications, notification dispatchers, moments in time, network ports, remote object messaging support (distributed objects), and event loops. It provides functionality that aims to implement the non-graphical portion of the OpenStep standard (the Foundation library). There is more information available at the GNUstep homepage at `http://www.gnustep.org'. ftp.gnustep.org pub/daily-snapshots 1.2 Noteworthy changes in version `1.19.0' == * Support for native objective-c exceptions * Connection keepalive for ms-windows * Path utilities fix for ms-windows * Changes to build on 64bit ms-windows * Support for @synchronize 1.3 Where can you get it? How can you compile it? == The gnustep-base-1.19.0.tar.gz distribution file has been placed at `ftp://ftp.gnustep.org/pub/gnustep/core'. Please log bug reports on the GNUstep project page `http://savannah.gnu.org/bugs/?group=gnustep' or send bug reports to bug-gnus...@gnu.org. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: How work NSHelpPanel?
On 27 Dec 2008, at 00:20, German Arias wrote: Hi, I want make a help panel to my app, but I don't know how work this. In Mac dev center there isn't information about this class. In docs.sun.com there is information, but don't work. I do this: I create a new folder with the name English.lproj and, inside, another folder with the name Help. Then I create two files (in Help folder) with the names TableOfContents.rtf and Index.rtfd. Add a new method call showHelpPanel in AppController.m and connect this with the Help option in the menu. This method send the message [NSHelpPanel sharedHelpPanel] , don't work. Then, I delete the folder English.lproj, and add a simple file with the name help.rft. Now, in Project Center, in Project Inspector a add this file in the field Help file. But, when I run my app, I get the error 2008-12-26 18:12:19.372 Test2[5361] File NSView.m: 523. In [NSTextView -initWithFrame:] given negative width any suggestion? First create your help document as an rtfd or rtf using something like Ink.app. If you are using the current copy of ProjectBuilder from svn, you open the project inspector, change from 'build attributes' to 'project attributes', and set the help file in that inspector. If you are building your app manually, you can either rename your help file to have the same name as your application, or you ca add an entry in your Info-gunustep.plist to specify the name of your help file with the key 'GSHelpContentsFile'. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: How work NSHelpPanel?
On 28 Dec 2008, at 05:30, German Arias wrote: :-( No, I get the same error 2008-12-26 18:12:19.372 Test2[5361] File NSView.m: 523. In [NSTextView -initWithFrame:] given negative width It's a very generic (ie could be from any view) error, so I suppose it could denote any one of a load of different issues which may not be directly related to NSHelpPanel at all. You could try using Thematic.app, as I know that the help works fine in that using current code from svn. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: How work NSHelpPanel?
On 29 Dec 2008, at 06:12, German Arias wrote: Hi, after install Thematic.app Info -- Help... Then, Ink.app run and load the help file. There isn't any Help Panel. That's normal behavior ... the application should launch the 'best' application to display the help page, and fall back to displaying within a panel only of no application exists to display it. The MacOS- X documentation actually says that it launches the HelpViewer application to display the help, but we have no such application in GNUstep, so we used the normal display mechanism. Maybe we should allow a user default to customise this behavior. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: How work NSHelpPanel?
On 29 Dec 2008, at 06:56, Richard Frith-Macdonald wrote: On 29 Dec 2008, at 06:12, German Arias wrote: Hi, after install Thematic.app Info -- Help... Then, Ink.app run and load the help file. There isn't any Help Panel. That's normal behavior ... the application should launch the 'best' application to display the help page, and fall back to displaying within a panel only of no application exists to display it. The MacOS-X documentation actually says that it launches the HelpViewer application to display the help, but we have no such application in GNUstep, so we used the normal display mechanism. Maybe we should allow a user default to customise this behavior. I added a new user default (called GSHelpViewer) to control the help viewer application. I also changed the default case to look for Viewer applications only, rather than any application able to open the help file ... though I'm not sure if that's the correct thing to do (maybe we'll want to change that back) as it's not clear whether we should be able to open the help in an editor. Perhaps we want people to be bale to edit/improve the help files of applications? ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: BASE RELEASE 1.19.0 corrupted
On 1 Jan 2009, at 21:43, Riccardo Mottola wrote: Hi all, it seems to me that the unstable release 1.19.0 of base is corrupted on our main FTP and unavailable on the mirrors. Could someone check? Adam? Yes you are right ... it's size zero. I'm making a new copy and putting it up now. Don't know how a zero length file got there, but I suppose most likely my original ftp upload went wrong in some way, though I didn't notice any error messages. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: GNUstep developer meeting in January
On 3 Jan 2009, at 16:48, Lars Sonchocky-Helldorf wrote: rant What actually is the point in this? I think this will effectively distracting possible attendees from FOSDEM because it is so close by (timewise) The points for FOSDEM are (IMHO): - it is located more centrally in Europe (means easier or equally difficult to reach) - we have some public visibility (which means sending the signal: GNUstep is alive and well) besides the meeting opportunity (there we also can have nice development and debugging sessions, it's just up to us). - we got a developers room for free there where we can meet (no need to *rent* a room) I really don't understand why everybody in our community (are we still one?) tries to cook his own soup (as a german saying goes) by splitting up our forces (I guess nobody will have the time and the money to attend every of those proposed meetings). I feel a little bit sabotaged … /rant … but maybe there's no interest in FOSDEM at all and I should cancel the event so that FOSDEM can give the room to some other project before it's to late for them. I hope FOSDEM will have plenty of people attending. I guess the other meeting might appeal to different people, but I'd like to be at both, and as you say ... only have the time to get to one of them (it basically takes me at least a day to get anywhere from where I live), so I'll (obviously) be at FOSDEM. In the developer room I'd like to discuss at least the following: Theming Web Services Garbage collection MacOS-X compatibility And hopefully we *can* get some coding done ... I thought we didn't have a stand this year, so we avoid the problem of having to man a stand and can spend more time discussing/developing. Actually, that would seem to suggest that there's less point having another meeting. Or maybe people don't feel good with me organizing the event and somebody else wants to take over. If so please drop me a mail and I will hand everything over. It's great that you've organised it ... thanks very much. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: GNUstep developer meeting in January
On 3 Jan 2009, at 23:23, Riccardo Mottola wrote: Hi, Richard, your presence would have been great at OrobienStep too. It is one single Ryanair flight from London, but I understand that it is an effort for you and if you need to choose, possibly Fosdem is better. A single flight from london, but six or seven hours to get to the airport in london first. I really live in a bad place for international travel links. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: libobjc issue
On 4 Jan 2009, at 00:06, Fred Kiefer wrote: Andreas Höschler wrote: fatal: libobjc.so.2: open failed: No such file or directory I searched for libobjc on both machines. On machine A I get find /usr/local/lib -name libobjc* /usr/local/lib/libobjc.so.2.0.0 /usr/local/lib/libobjc.la /usr/local/lib/libobjc.so /usr/local/lib/amd64/libobjc.so.2.0.0 /usr/local/lib/amd64/libobjc.so /usr/local/lib/amd64/libobjc.a /usr/local/lib/amd64/libobjc.so.2 /usr/local/lib/amd64/libobjc.la /usr/local/lib/libobjc.so.2 /usr/local/lib/libobjc.a On machine B I get find /usr/local/lib -name libobjc* /usr/local/lib/libobjc.la /usr/local/lib/libobjc.a OK, what am I missing? I guess libobjc is part of the gcc build!? But why does machine A has it in libobjc.so.2.0.0 form and machine B not? I have rebuilt gcc on machine B multiple times, but no avail. Any idea what went wrong? You seem to have libobjc only build statically on machine B, you will need a dynamically version of that library for GNUstep (at least in the standard setup). Just rebuild this library and things should be fine. (There is an updated version of the code in the GNUstep repository, but the one delivered with gcc might do) I think the key observation is that only static libraries are built. This almost certainly means that you used different options for 'configure' with gcc on the two different machines. You need to do a configure with '--enable-shared' to get the shared library built.\ ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: GNUstep and Theming...
On 4 Jan 2009, at 22:55, Gregory John Casamento wrote: Hi all.. I'd like to re-prioritize one of the points I mentioned in the previous email. I think that theming should be much higher priority than I stated previously. I think it should be one of our top priorities at this point. Yes. It seems that theming is one of the central reasons that users shy away from GNUstep. Actually, while I would have agreed with this a couple of years ago, I see no evidence that this is really the case. Yes there are always a few vociferous people who complain about the way things look, but the actual interest in the theming code/ application, since it was added in 2006, has been about zero. I'm still hoping that if we actually had a few well designed themes to show, it might change things though. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: ./configure --with-installation-domain
On 6 Jan 2009, at 01:32, Yen-Ju Chen wrote: Hi, I just install a clean FreeBSD 7.1 and try to install GNUstep from svn. After gnustep-make, I did 'configure' on gnustep-base and it tells me to use 'configure --with-installation-domain'. I know there are changes in gnustep-make recently, but I assume that for a newbie, 'configure' should automatically install gnustep-base into SYSTEM domain. No, the whole point of the changes is so that a newbie gets stuff installed where they expect, so we've altered things to install in the local domain by default when building from source, like every other free software package out there. Binary packages coming from your system provider should install into the system domain. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: ./configure --with-installation-domain
On 7 Jan 2009, at 11:14, David Ayers wrote: Am Dienstag, den 06.01.2009, 17:55 + schrieb Nicola Pero: On 6 Jan 2009, at 17:50, Pete French wrote: No, the whole point of the changes is so that a newbie gets stuff installed where they expect, so we've altered things to install in the local domain by default when building from source, like every other free software package out there. Where exactly is the 'Local' domain in this case ? I hit a pproblem yesterday where I configured with domainb system - whcih worked fine, but tthen when I tried to build it toold me the domaisn didnt match and re-ran configure/. I never managed toget it compiking properly and ended up copying over and older tree. Slightly bewildered by it to be honest... Good point. I suppose ./configure --with-installation-domain=xxx should also add GNUSTEP_INSTALLATION_DOMAIN = xxx to the GNUmakefiles. To which GNUmakefiles? How should a packager a) configure [make,base,gui,back] b) install [make,base,gui,back,gorm,project center] so that the system packages end up in System yet the user installed packages end up in Local? Isn't that the scenario these changes are aimed at? I haven't reviewed Nicola's latest changes to see what they do, but in the current release it's very simple... A packager does: export GNUSTEP_INSTALLATION_DOMAIN=SYSTEM configure make install Users do: configure make install ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: our Devroom - what do we want to do there - call for papers
On 6 Jan 2009, at 00:57, Lars Sonchocky-Helldorf wrote: Am 03.01.2009 um 19:12 schrieb h...@computer.org: Some thoughts (without priorities): 1. How to install and run GNUstep on Windows 2. The new Cairo Backend (Cairo - Fred) 3. Applications, Applications, Applications (GAP - Riccardo) 4. How can I contribute to GNUstep? 5. Is there a nice Desktop? (Etoile - Quentin) 5. What do I get from GNUstep what I don't from GTK, Qt, Cocoa, Android, etc.? 6. (non-)Compatibility to Macintosh and iPhone 7. What and how can I do with (Scalable) OpenGroupWare? (Helge) Nikolaus Nikolaus, thank you very much for your proposals. I would like to add some personal favorites I'd like to see at FOSDEM: - Some updates about what is going on with Étoilé - I read the blog on http://etoileos.com/news/ from time to time and David's runtime stuff, the Smalltalk Integration, Quentin's CoreObject stuff and all the other things interest me very much. Étoilé guys, are you listening? Maybe you can update the talks of your last hackathon a little bit and (re)present those on FOSDEM this year. - a talk/discussion about the future of theming in GNUstep - wouldn't FOSDEM be a great opportunity to come closer to a solution? - an ObjC primer for starters - what is ObjC, how is it related to C, C++, Java and so on. I guess the iPhone and its app store has created new interest in ObjC - last years recap for GNUstep. GNUstep has developed big time in the last year. What are the most important news and changes? please feel free to propose additional topics and post them to the list - or even better enter a talk you're going to give here: http://wiki.gnustep.org/index.php/FOSDEM_2009 If you ain't got an account for the wiki - don't hesitate: send your talk to me and I'll enter it. You said that the deadline for our schedule for presentations was 10th Jan. Looking at the wiki we have a daunting 14 slots, and none of them filled in yet. We ought to fill *something* in. Maybe we can repeat the schedule on the two days. Let's say I volunteer to do talks on Theming and Web Services ... there is certainly enough to talk about on those two topics and fill a couple of slots on each day. Is there anything else people would like me to lead a discussion about (I'd rather do that than formal talks) to fill up a few more slots? What about any other volunteers? ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Can't mix native exceptions and ObjC++
On 9 Jan 2009, at 22:08, Larry Campbell wrote: Had another go at this, with gnustep-make 2.0.8 and both gnustep- base 1.18.0 and 1.19.0, with the same result. So sad. I was tempted by the comment: 1.2 Noteworthy changes in version `1.19.0' == * Support for native objective-c exceptions This is with gcc 4.1.2. Has anyone else ever tried this successfully? Did you have to use a different version of gcc? I use native objc exceptions with gcc-4.4.0. However, if you want the uncaught exception handler to work, you need to have patched the runtime. - lc On Dec 26, 2007, at 7:22 PM, Larry Campbell wrote: Before I spend a lot of time figuring out how to fix this, I thought I'd ping the list to see if anyone else has run into this. I just tried turning on native Objective-C exceptions (--enable- native-objc-exceptions to gnustep-base/configure). Everything seems to build OK, but if there are any Objective-C++ modules that use exceptions in my link, the link fails with: undefined reference to `typeinfo for NSException*' As long as there's no Objective-C++ (.mm) in the link, I'm fine. This happens with both (gnustep-make 1.13.0 + gnustep-base 1.13.1) and (gnustep-make 2.0.2 + gnustep-base 1.14.1). I tried renaming NSException.m to NSException.mm (and fixing the type errors the stricter compile revealed); no joy. Has anyone already run into this (and, hopefully, fixed it)? I don't use C++, so I haven't run into this ... it's possible that there is an incompatibility between the exception support in the C++ and Objective-C runtime libraries provided by gcc. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Question about NSMenuView
On 16 Jan 2009, at 13:20, Matt Rice wrote: i'll just go back to refraining from interfering aka contributing, because I only do this because it is a) fun and b) if I find it useful maybe others will arguing over stuff just makes it no fun, and when I lose said argument, nobody can find it useful because nobody can find it.. now if this were just a few things, but most of the stuff I do for gnustep ends up rejected by their maintainers, if my view of gnustep and that of its maintainers don't align there is no point in my contributing this little patch since i'm still stuck maintaining a ton of other patches so no, I don't really care if the remaining stuff goes in personally, at this point it benefits me none, i've already got my patch... and taking one off of the queue isn't going to make any noticable impact to it OTOH I do hope people find it useful maybe if you guys went distributed version control I would bother Well, why is it that your view and that of the maintainers doesn't align? It could be that your aim is just to produce something that works for you ... in which case there's always going to be a problem, but if you are interested in code that matches the MacOS-X behavior and doesn't break behaviors for other people, there should be no difficulty convincing maintainers. Of course, maintainers tend to be a bit conservative (trying to ensure that changes don't break things, except perhaps if they are changes to improve MacOS-X compatibility and the things they break can be fixed to use the MacOS-X behavior), so they need to be able to understand patches, which means that they need small and/or simple patches. Remember, they may not be as clever as you (and are almost certainly less familiar with the patched code than you), and probably don't have the spare time to sort out complex patches. Is it really so dreadful/dispiriting to be asked to break patches down into smaller, readily digestible versions? ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Impelmenting NSWindows95InterfaceStyle
On 19 Jan 2009, at 06:54, h...@computer.org wrote: On 19 Jan., 04:57, Germán Arias ger...@xelalug.org wrote: Hi, after inspect the source of NSMenu.m and others files. I think that I can try to implement the option NSWindows95InterfaceStyle. I have one idea to do that, and I want know what do you think about this. Well, I think that the most easy and elegant way to implement this is make a new window with the horizontal menu and with a standard toolbar. In others words, don't put the menu in an app's window. Instead this, make a new window (main window) to set the horizontal menu. For example, if an app is like this _ |Menu | | | | | | | |___| |_| | | | | | | | | | App's window | | | | | | | | | |___| After set NSWindows95InterfaceStyle, the app's look will by like this __ |_Main window_| | -- Menu -- | |_| | - a standard | | toolbar -- | |_| || || || || || | App's window | || || || || || To my this is an elegant solution, because make an horizontal menu and, at the same time, conserve a distinctive look. In other hand, there are many apps that implements that look, familiar to many people. Of course, the programmer will by able to set his own toolbar in the main menu. What do you think about this idea? I don't use mswindows very much, but it does not appear to be the sort of behavior you would expect from a windows application. I would expect use of NSWindows95InterfaceStyle to produce a menu in each windows and remove the main menu: ie. _ |Menu | | | | | | | |___| |_| | | - | | |---| | | | | | | | | | App's window | | Another window | | | | | | | - | | | | |___| would become || | -- Menu -- | --- || |--| || | -- Menu -- | || | | | App's window | | Another window | || | | || || || || I had suggested before (maybe my mail got lost) to implement - [NSWindow setMenu:] so that it simply adds a horizontal menu between the menu title and the window's toolbar. This would allow to add window menus to any application and interface style. And to have different menus for each window The only critical aspects I see are * you can't define the menu in Interface Builder * GORM may need an extension * or the application must set up the menu programmatically * the standard Application Menu still appears I guess I should have commented. Yes, to
Re: Impelmenting NSWindows95InterfaceStyle
On 19 Jan 2009, at 19:12, Germán Arias wrote:
El lun, 19-01-2009 a las 13:46 +0100, Fred Kiefer escribió:
Sounds like the right condition to decide whether to add a menu. But
what should we do in the case, when there isn't a main window? Take
for
example the GSTest application that doesn't display a window on
startup.
Should we only have the context menu of the icon window?
For that reason I propose a new window. A new window without a resize
bar, because its width is determined to the menu (of course the
programmer needs by careful with his menu), and without a close button
in the title bar, because for that is the option Quit in the menu. And
in the toolbar some standard icons like: Open, Save, Info Panel, Help,
Go to app's website, ...
We already have something like that ... it's called the main menu.
It's fine having our main menu in a window of its own, but that's not
mswindows style.
In other hand, with the main menu inside an app's window. I see many
problems. First, as Fred say, if there isn't a main window, which
window?.
Windows apps have menus in multiple windows ... so that's not an issue
(the menu is not supposed to be just in the main window). If there
are no windows we can adopt one of at least two policies ...
1. the app simply terminates.
2. we create a standalone menu (like current menus).
Second, if the user change the window's width, sometimes the
option Quit will by outside the window, that is unacceptable, unless
we
change the position of the option Quit inside the menu.
The normal solution to that is to disallow shrinking of the windowto
be smaller than the menu, but another is to allow scrolling of the
menu inside the window so that you can get to everything. I don't
know what mswindows does, but obviously for mswindows style menus we
should do the same thing.
And the hidden
options needs by accesible in a control that show a vertical menu (not
an horizontal menu). And third, the window need call [NSApp terminate:
self] when the user do a click in its close button.
IIRC there is already an option to have the app terminate when the
last window is closed.
We need an flexible menu and easy change with
NSNextStepInterfaceStyle,
NSMacintoshInterfaceStyle and NSWindows95InterfaceStyle. Now I
propose a
new solution. As said Nikolaus, he proposed a [window setMenu:], then
why not implement this method together my idea?. This solution work on
this way:
When you set NSWindow95InterfaceStyle, GNUstep check if there is a
main
window, if this exist set the menu in that window (with [window
setMenu:]). Call the method setMinSize, with a value that prevent
hidden
options (the programmer need careful in this), and perform a
connection
to window with (for example) AppController, with sometime like this
- (void) windowWillClose: (NSNotification *)aNotification;
{
if( (style == NSWindows95InterfaceStyle]) (thereIsMainWindow) )
{
[NSApp terminate: self] ;
}
}
If there isn't a main window then, GNUstep make a new window as I said
before.
And I don't see problem if the user want set his own menus in other
windows (of course not the main window).
What do you think about this new idea?
The main problem is that it's not much like the way mswindows
behaves ... we want to implement an NSWindow95InterfaceStyle for our
main menu which makes our apps behave like mswindows apps. An
application programmer may well want (and be allowed) to control
things (eg preventing the main window from appearing in certain
windows and terminating the app when they want to) but the default
behavior of the application should be like mswindows, with the main
menu displayed inside every eligible window and the app being
terminated if there is no eligible widow.
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Changes in trunk
My latest commit to the base library in svn trunk hides some private internals of the memory management system, and this unfortunately means that code built with an older version will fail to link with an 'undefined reference' error. The solution is to rebuild all your code where any source file includes/imports NSZone.h Sorry for any inconvenience. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Impelmenting NSWindows95InterfaceStyle
On 19 Jan 2009, at 23:10, David Chisnall wrote: On 19 Jan 2009, at 20:52, Richard Frith-Macdonald wrote: The normal solution to that is to disallow shrinking of the windowto be smaller than the menu, but another is to allow scrolling of the menu inside the window so that you can get to everything. I don't know what mswindows does, but obviously for mswindows style menus we should do the same thing. As I recall, MS Windows simple makes the menu items to the right inaccessible by default. IE4 (I think, might have been Office 97) implemented a modified form where shrinking the window beyond the menu width adds an extra menu item with an arrow character on it which has all of the hidden menus as submenus of it. This is probably the best behaviour to copy since GNUstep apps won't always be designed to have windows as wide as their horizontal menu. That sounds like a good approach to me. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: NSOperation status
On 19 Jan 2009, at 07:51, Sebastian Nowicki wrote: In the release notes for v1.16.0 [1] it is mentioned that NSOperation is on the to-do list. I'm wondering what the status of that is. As far as I can tell there's no support for it whatsoever. This is unfortunate as I would like to use this instead of NSThread for my cross-platform framework (Cocoa GNUstep). I'm not sure whether to just use NSOperation and wait for it to be supported in GNUstep or use NSThread and switch later. [1] http://www.gnustep.org/resources/documentation/Developer/Base/ReleaseNotes/ReleaseNotes.html Being on the to-do list really means we'd like someone to volunteer to do it ... it would be great if you could contribute an implementation. I'm pretty certain nobody else has volunteered yet. Looking at the class documentation, it seems like a fairly substantial task, but not hugely difficult. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: NS_VALUERETURN
On 20 Jan 2009, at 17:40, David Chisnall wrote: Hi Everyone, Looking at the documentation here: http://www.gnustep.org/resources/documentation/Developer/Base/ProgrammingManual/manual_6.html It says exactly the opposite of the Cocoa documentation. On Cocoa, NS_VALUERETURN and NS_VOIDRETURN should be called between NS_DURING and NS_HANDLER, while this says they should be used between NS_HANDLER and NS_ENDHANDLER. Which is wrong? The documentation or the GNUstep implementation? The manual ... I'll change it. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: First doubts about GNUstep
On 20 Jan 2009, at 20:04, Giuseppe Luigi Punzi Ruiz wrote: Secondly, I would like to know what type of persistence use the average developer, because GDL2, seems abandoned? I don't think it's abandoned. The project I will start will need access to relational databases (interbase? postgres? mysql?) to share with other instances of the aplication, and with an alternative web frontend, there are other alternatives? SQLClient works very well for postgres and should be good enough for most purpose with mysql and easily ported for use with other databases. It can even work via a jdbc layer! ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Thematic don't work
On 24 Jan 2009, at 06:14, Germán Arias wrote: Hi, after update Thematic.app, this don't work. I run Thematic, then select Theme- New and get the error GSTheme(instance) does not recognize setName: I'm not sure what update you are talking about, but you need to keep thematic and the gui library both up to dat as thematic always depends on the latest changes in gui. Current svn works fine for me, so I suggest you make sure you are using current code from svn throughout. Other question, why there isn't a page about Thematic.app on the wiki, and Software Index? Dunno Or its status is beta? Certainly ... we don't have theming methods in the gui for a lot of controls yet, so there's no way the theming API can be regarded as stable. Mostly there are going to have to be additional methods rather than changes to existing methods, but until we can get enough people contributing code the progress will be quite slow and the api will therefore have to remain unstable for quite some time. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Thematic don't work
On 3 Feb 2009, at 08:28, Giuseppe Luigi Punzi wrote: I have the same issues on Windows builded with latest gui if this info can help. Cheers. Richard Frith-Macdonald escribió: On 24 Jan 2009, at 06:14, Germán Arias wrote: Hi, after update Thematic.app, this don't work. I run Thematic, then select Theme- New and get the error GSTheme(instance) does not recognize setName: I'm not sure what update you are talking about, but you need to keep thematic and the gui library both up to dat as thematic always depends on the latest changes in gui. Current svn works fine for me, so I suggest you make sure you are using current code from svn throughout. The same advice applies ... if you are getting that error, it means that your copy of Thematic is linked with an old version of the gui library and is trying to call the method -setName: on an old version of the GSTheme class which did not have it. The simplest solution is to make absolutely sure you have removed all versions of the gui library from your machine, then build a new version and rebuild/relink all your code using the up to date library. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Back from FOSDEM
I just got back from FOSDEM this afternoon. The weekend was tiring, but a lot of fun and quite productive. I might write something more detailed about it tomorrow, but now I'd like to thank everyone who attended, and most particularly to thank Lars Sonchocky-Helldorf who provided the impetus to get everything going and really organised us all, even doing an extra last-minute presentation on Sunday afternoon to fill the last empty slot on our schedule. Also thanks, to David Chisnall who was not able to get there, but did a surprisingly effective presentation over video link. Next year we must organise amplifier and speakers as the sound output of a laptop is not really sufficient (though we did have an astonishingly quiet room as everyone listened to 'pragmatic smalltalk'). ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: differences between gnustep and libFoundation while porting ogo
On 12 Feb 2009, at 07:16, Sebastian Reitenbach wrote:
class: NSException
name:NSGenericException
reason: subclass WOHTTPURLHandle(class) should override
cachedHandleForURL:
info:
So I took a look what GSHTTPURLHandler is doing, and for now I added
the
following to WOHTTPURLHandle class in SOPE:
+ (NSURLHandle*) cachedHandleForURL: (NSURL*)newUrl
{
NSURLHandle *obj = nil;
return obj;
}
that made the problem disappear. As helge always says, it works for
him on
libFoundation and on Cocoa, the difference seems to be in GNUstep ???
I wrote a testcase for this, and confirmed that the GNUstep behavior
(raising an exception here) is the same on GNUstep and MacOS-X.
So I would guess that any problem lies somewhere else in the code.
Perhaps GNUstep is attempting to use a cached URL where libFoundation
isn't attempting caching?
Getting that out of the way, made me run into the next exception:
Application Server caught exception:
snip
So it seems, on libFoundation I can initialize a NSString with a
nil string,
but not on GNUstep. I also have no idea which one is the right one.
Thanks ... I just wrote a test for this on MacOS-X (and added it to
the GNUstep base regression testsuite). The GNUstep behavior is the
same as the MacOS-X behavior ... to raise an exception. I don't see
how the code section calling -initWithString: with a nil argument
could possibly work on MacOS-X.
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: an error from the expression: CLS_ISCLASS((Class)receiver) File: sendmsg.c Line 321
On 13 Feb 2009, at 07:19, Fred Kiefer wrote: I don't understand this error message either. It comes from the Objective-C runtime library ... where it's checking that the receiver is a valid class and not just some random bit of memory. To make any real sense of it we need a stacktrace to see how the runtime is being called ... most likely with an uninitialised variable. But you already should get some warnings during compilation. sharedApplicatiion is clearly misspelled and you should get this told by the compiler. Best you fix you compiler warnings and then report back with a bit more information. Yes ... always best to fix compile/link errors before looking at runtime errors. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: an error from the expression: CLS_ISCLASS((Class)receiver) File: sendmsg.c Line 321
On 13 Feb 2009, at 12:31, David Chisnall wrote: On 13 Feb 2009, at 08:30, Truls Becken wrote: The other point I'd like to make is that importing AppKit/AppKit.h in AppController.h would simplify things a bit. I guess it's debatable whether this is better than declaring/importing only what is strictly needed in the header and then import AppKit in the implementation file, like you do now, but generally I think it's simpler to just import AppKit in the controller header and be done with it. This would replace the 5 classes you currently declare/import - a list which would surely grow as you develop you application. The rationale for not #importing AppKit.h is that it is huge. The preprocessed header is over 700KB (just under 36,000 lines), which means that the compiler has to build a parse tree that is likely to be several MBs before it even gets to your program. This is worked around on OS X by using prefix headers. These are preprocessed and pre-parsed headers that are used automatically in place of Cocoa.h (which, with GCC, has around a 30MB parse tree). This is one of the main reasons why OS X programs use Cocoa.h rather than AppKit.h and Foundation.h - you are only allowed one precompiled header per program. I don't know if GNUstep make has support for precompiling Cocoa.h. If not, it might be worth adding, since it can reduce the memory usage and processing time of a big build. I know GNUstep-make supports precompiled headers, but I don't think it does Cocoa.h It's not clear to me where Cocoa.h would be found/provided in the GNUstep packages. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: easiest way to start messing with gnustep again?
On 15 Feb 2009, at 05:59, dan wrote: The thing i remember having the most trouble with GNUstep was setting up all those daemons and i hope that by doing something in a vm i can make the process a little easier. You don't have to (and as far as I can recall have never had to) start daemons. They get started automatically, so while it used to be recommended to start them manually (and is necessary if you want to use special options) it's really not an issue normally. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: no text shown in menus and windows
On 17 Feb 2009, at 10:57, David Ayers wrote: Am Dienstag, den 17.02.2009, 09:50 +0100 schrieb Sebastian Reitenbach: I just installed gnustep-startup-0.22.0 on opensuse 11.0, i386, further I installed Gorm, Renaissance and GDL2 from svn. When I startup Gorm or DBModeler, then in the menus and windows there is no text shown. Everything seems to work fine, but I have to guess where to click (: I see a lot of the following messages scrolling in the console: It sounds like a -back or font issue. I guess you have the same issue with Ink? http://wiki.gnustep.org/index.php/Ink Cheers, David PS: Is ink in a public version control repository? I thought it was part of GAP but that doesn't seem to be the case. Ink is in the GNUstep svn repository iirc it's in the gui examples in the 'tests' area. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Presentations' / Talks' Slides (was Re: FOSDEM 2009 impressions summary)
On 17 Feb 2009, at 15:45, Adam Fedor wrote: On Feb 14, 2009, at 7:35 PM, Lars Sonchocky-Helldorf wrote: P.S.: Last time I tried there was no media upload (whatever, images, PDFs, SVGs) possible in the wiki. Who is in charge of changing that? You should be able to upload files via the 'Upload file' link in the navigation bar: http://wiki.gnustep.org/index.php/Special:Upload Unfortunately this doesn't work. It just says 'Warning .odp is not a recommended image file format.' and, as far as I can tell, aborts any upload. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Need help understanding subclassing issue
On 20 Feb 2009, at 13:10, David Chisnall wrote: My advice with regard to documentation is to stick to using the Apple docs and if you find something that doesn't work on GNUstep either implement it and send a patch, or file a bug report. Sounds good to me ... though I would say read both sets of documentation. The Apple documents are usually more informative, but sometimes the GNUstep ones tell you more. The Apple ones should normally be regarded as definitive, so I'd like to know about any contradictions or places where GNUstep docs are misleading. In a few cases the Apple documentation is wrong and the GNUstep documentation may tell you that what we implement is the actual behavior of MacOS-X rather than the Apple documented behavior. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: is handling of UncaughtException broken on my system?
On 20 Feb 2009, at 21:22, sylvain wrote:
Hi,
the program below does not work as I would have expected on my system.
#include Foundation/Foundation.h
void MyEHandler(NSException* exception)
{
NSLog(@exception: %...@\n,exception);
}
int
main(int argc, const char *argv[])
{
id pool = [[NSAutoreleasePool alloc] init];
NSSetUncaughtExceptionHandler(MyEHandler);
/* compare function address, is ok */
NSLog(@MyEHandler: %p\n,MyEHandler);
NSLog(@MyEHandler: %p\n,NSGetUncaughtExceptionHandler());
[NSException raise:@crash format:@no reason];
[pool release];
return 0;
}
$ ./obj/brokenexception
2009-02-20 22:11:14.668 brokenexception[15643] MyEHandler: 0x8048804
2009-02-20 22:11:14.984 brokenexception[15643] MyEHandler: 0x8048804
Abandon
I have installed GNUStep on Ubuntu. Package version: 7.2
Is it a problem with me, the Ubuntu build or upstream?
The output on my system (svn trunk) is
2009-02-20 23:13:36.743 generictests[12218,986ade8] MyEHandler:
0x80487d4
2009-02-20 23:13:36.762 generictests[12218,986ade8] MyEHandler:
0x80487d4
2009-02-20 23:13:36.777 generictests[12218,986ade8] exception:
NSException: 0x98f9060 NAME:crash REASON:no reason INFO:(nil)
obj/generictests: Uncaught exception crash, reason: no reason
Aborted
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: FOSDEM Aftermath - the Hotel / Notes from preparing and giving my talk
On 21 Feb 2009, at 08:59, Sebastian Reitenbach wrote: Hi, - while I am on it: I find the right click behaviour of GNUstep (show the main menu under the mouse, like OPENSTEP) quite dated. Mac OS X / Cocoa has a context based menu on right click nowadays (like every other platform). Maybe we can make that configurable too (to cater both OPENSTEP heads who like the old behaviour and everybody else who expects a context menu): how about a default named GSSecondaryClickBehaviour? I'd also prefer context sensitive menus on right click than the whole bunch of main menu. That would make understanding an application from an not so experienced user quite more easy. Especially true for more complex apps like e.g. Gorm, where therer is a plethora of menu entries, but only some apply to the point where I right clicked. GNUstep has always had context menus... they were available in NeXTstep. That being said, they are used so infrequently that they may be buggy for all I know. The thing about context menus is that they are controlled by the application (of course), so they only exist if application programmers want them to. I think context menus are rarely useful, and it's generally better to try and deign a good on-screen interface rather than depend on pop-up menus and tool tips (though both have their place occasionally). ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: NSTimer
On 27 Feb 2009, at 01:58, Scott Christley wrote: Hello, I'm using the latest code from SVN. My program is using a repeated NSTimer much like this sample code, and it no longer seems to be working. Not sure how long ago it stopped working, I haven't used my code in many months. The run loop is returning immediately instead of firing off the message, anybody know what the problem is? You need to have some input source in the run loop (a timer doesn't count) or it will return immediately, as specified in the Apple docs. There used to be a bug where the loop would block forever rather than return immediately, and I guess your code was depending on that. The behavior on MacOS when I tested it was strange and inconsistent ... sometime the loop returned immediately as documented, sometimes it blocked. My suspicion is that MacOS-X has an undocumented feature of sometimes putting input sources in the run loop Anyway, the way to do what you want is to use one of the mthods to run the loop in conjunction with limitDateForMode: and [NSThread- sleepUntilDate:] ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: NSTimer
On 27 Feb 2009, at 11:15, David Chisnall wrote: The behavior on MacOS when I tested it was strange and inconsistent ... sometime the loop returned immediately as documented, sometimes it blocked. My suspicion is that MacOS-X has an undocumented feature of sometimes putting input sources in the run loop This is not undocumented. The NSRunloop documentation clearly states: Manually removing all known input sources and timers from the run loop is not a guarantee that the run loop will exit. Mac OS X can install and remove additional input sources as needed to process requests targeted at the receiver’s thread. I meant undocumented in the sense that it does not specify the conditions under which it can occur. For instance, I had a test program which did *nothing* other than create an autorelease pool and run the runloop in the main thread ... but it still blocked. Doing the same thing in a second thread, the loop terminated immediately. Perhaps the main runloop will always block in practice under OSX, but I would not rely on it. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: gdnc
On 11 Mar 2009, at 07:39, Truls Becken wrote: Justin Lolofie wrote: I understand that gdnc must be running or it is started automatically. In my case, it fails to start up automatically. When I triy to start it up myself, I get this message: failed to contact gdomap on myhostname(10.0.2.123) - Connection refused Did you start gdomap first? gdnc is per user and needs to start once per boot gpbs is per user and needs to start after X11, for instance from .xinitrc gdomap is a system service and should be started from the bootscripts Like you mentioned, the first two are started automatically for the user if not already running. 1. All three are start automatically when needed ... unless GNUstep is improperly installed. 2. gdnc does not require gdomap (except in the case where you are manually running special copies of gdnc to support notifications between different users/machines) So if gdnc is trying to use gdomap, either GNUstep is oddly configured/ installed, or a really, really old version is being used. In either case it makes sense to completely remove the existing installation, get an up to date copy, and configure/build/install in the standard manner. If using a packaged version of GNUstep, it's possible that the packager misconfigured it (or deliberately configured it to use tcp/ip based distributed notifications) ... in which case the thing to do is contact the package provider and ask them what to do (perhaps they documented their changes). There could also possibly be some security setting in your OS that either denies gdomap to listen to its port, or connections to be made from mysystem. Also, I recommend adding mysystem to the 127.0.0.1 localhost line in /etc/hosts, and not have it on a line with the actual address (if that is the case now). Good advice for possible installation problems with gdomap, but this should not effect gdnc as it normally uses unix domain sockets. gdnc does need to be able to write to the temporary directory (normally /tmp), but a permission problem there would be very strange. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: GNUmakefile
On 13 Mar 2009, at 14:14, Justin Lolofie wrote: So, I've written my first very simple command line tool with objc/ gnustep. Below is my GNUmakefile which works fine. Now I'd like to start using plausible database which is an objc sqlite wrapper. It contains 8 .h and 8 .m files. I'm trying to figure out what to add to my GNUmakefile to compile/link those files correctly. I see that there is a ADDITIONAL_INCLUDE_DIRS which I can use to find the plausible db header files, but I'm not sure how to tell it where the .m file are and how to build them. I dont think they go in bwatch_OBJC_FILES do they? Thanks for any help. Use bwatch_TOOL_LIBS to add libraries you want to link with ... that's what I do to link the SQLClient library (also wraps sqlite along with postgres and other database) with my tools. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Troubles with GNUstep Make
On 17 Mar 2009, at 19:45, Torli Birnbauer wrote:
I have recently installed GNUstep binaries with Synaptic Package
Manager on my Ubuntu system, and subsequently started to study the
Base Programming Manual, where I came across the following:
Now create the makefile, again using your favourite text editor, and
save it in the same project directory with the filename GNUmakefile.
include $(GNUSTEP_MAKEFILES)/common.make
TOOL_NAME = LogTest
LogTest_OBJC_FILES = source.m
include $(GNUSTEP_MAKEFILES)/tool.make
If you look at the makefile above you will notice the two lines that
tell the make utility to build a tool with the filename LogTest from
the Objective-C source file source.m. You could copy and modify this
makefile for later projects you may have: just change the tool name
and list the new source files.
The trouble is that changing the line {{ TOOL_NAME = LogTest }} to
something else, make does not work. I get the following:
$ make
This is gnustep-make 2.0.2. Type 'make print-gnustep-make-help' for
help.
Making all for tool WriteStr2File...
Linking tool WriteStr2File ...
/usr/lib/gcc/i486-linux-gnu/4.2.4/../../../../lib/crt1.o: In
function `_start':
(.text+0x18): undefined reference to `main'
collect2: ld returned 1 exit status
make[1]: *** [obj/WriteStr2File] Error 1
make: *** [WriteStr2File.all.tool.variables] Error 2
i...@kosi:~/work/prgming/obj-c/projs/bp02/wr2file
$
It looks as if certain names like {{ LogTest, simple, ...}} were pre-
compiled into GNUstep make. Is this a known undocumented problem, or
will building GNUstep Make from source solve this problem?
Neither ... there's no evidence of any problem with gnustep-make
there. What it looks like is that there is a problem with your source
code. The makefile is trying to link the tool WriteStr2File and has
found that the source code (whatever that is in your case) does not
contain the required 'main()' function.
You can do 'make messages=yes' to get more information about exactly
what it's doing.
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Troubles with GNUstep Make
On 17 Mar 2009, at 20:32, Torli Birnbauer wrote:
On Tue, 2009-03-17 at 19:59 +, Richard Frith-Macdonald wrote:
On 17 Mar 2009, at 19:45, Torli Birnbauer wrote:
I have recently installed GNUstep binaries with Synaptic Package
Manager on my Ubuntu system, and subsequently started to study the
Base Programming Manual, where I came across the following:
Now create the makefile, again using your favourite text editor,
and
save it in the same project directory with the filename
GNUmakefile.
include $(GNUSTEP_MAKEFILES)/common.make
TOOL_NAME = LogTest
LogTest_OBJC_FILES = source.m
include $(GNUSTEP_MAKEFILES)/tool.make
If you look at the makefile above you will notice the two lines
that
tell the make utility to build a tool with the filename LogTest
from
the Objective-C source file source.m. You could copy and modify
this
makefile for later projects you may have: just change the tool name
and list the new source files.
The trouble is that changing the line {{ TOOL_NAME = LogTest }} to
something else, make does not work.
It looks as if certain names like {{ LogTest, simple, ...}} were
pre-
compiled into GNUstep make. Is this a known undocumented problem,
or
will building GNUstep Make from source solve this problem?
Neither ... there's no evidence of any problem with gnustep-make
there. What it looks like is that there is a problem with your
source
code. The makefile is trying to link the tool WriteStr2File and has
found that the source code (whatever that is in your case) does not
contain the required 'main()' function.
You can do 'make messages=yes' to get more information about exactly
what it's doing.
Richard, this is a very interesting hypothesis you've brought up. I
Know to you it must look credible, but it is a total hogwash to me!
If I change the setting of {{ TOOL_NAME }} variable from
{{ TOOL_NAME = WriteStr2File }} back to {{ TOOL_NAME = LogTest }} or
to {{ TOOL_NAME = simple }}, as can be found in the Make Utility
documentation on page http://www.gnustep.org/developers/documentation.html
under the subtitle 1.2 Structure of a Makefile the compilation
and linking finishes flawlessly.
All that shows is that you have got a main() in the source files for
LogTest and no main() in the source files for WriteStr2File
Most likely that means you changed 'TOOL_NAME = LogTest' to 'TOOL_NAME
= WriteStr2File' but forgot to change 'LogTest_OBJC_FILES = source.m'
to 'WriteStr2File_OBJC_FILES = source.m'
In that case you are telling it to build the tool 'WriteStr2File', but
telling it that the source files list (WriteStr2File_OBJC_FILES) is
empty.
If there are no source files, then of course main() is not found in
any of the source files, so you get the linker error saying that.
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: GNUstep introduces a serious security problem
On 18 Mar 2009, at 07:34, Tim Kack wrote:
Yes, this seems to that is the case here - I read through some GNU
docs as well (not that I do not trust your research Richard!).
But since this might be confusing since GNUstep is supposed to be
cross platform.
On Windows you get:
'$ ./obj/testFilePerms.exe
2009-03-18 08:31:38.361 testFilePerms[5984] File NSData.m: 1050. In
[NSDataMallo
c -writeToFile:atomically:] Rename ('C:/tmp/
permissionstestFile.txta04820' to 'C
:/tmp/permissionstestFile.txt') failed - The operation completed
successfully.
It's a windows-specific bug that behavior there differs, now fixed in
svn trunk.
2009-03-18 08:31:38.361 testFilePerms[5984] Failure'
I suggest that we add a line to the documentation that says:
Depending on which operating system you are using, any existing
file might be overwritten regardless of file protection mask.
Logically you would need to place such a warning in the tens (possibly
hundreds) of places where something similar can occur. This seems a
bit pointless when what you are actually saying is that the method
will work as documented subject to normal restrictions placed on it by
the operating system. People familiar with POSIX file permissions will
expect this behavior anyway if they read the documentation and see
that it says the 'atomically' flag means a temporary file will be
renamed to replace any existing file.
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: GNUStep and Cocoa Distributed Objects compatibility
On 22 Mar 2009, at 10:23, Piotr Isajew wrote: Hello I would like to use Distributed Objects to communicate through the network between Objective C GNU Step application (let's say running on Linux) and it's Mac OS X counterpart). Does anybody have any experience using DO in such configuration? Is GNUStep's DO implementation compatible with Cocoa's one? No, the two implementations are not binary compatible, and making them compatible would be quite a big job (though it's certainly not impossible ... as we have a binary compatible implementation of keyed coding for NIBs already, and Nikolaus Schaler has written a binary compatible version of NSSocketPort for mySTEP which GNUstep could use ... so a project to implement binary compatible DO would need to re-implement NSConnection and NSPortCoder to use those). Currently, for IPC between GNUstep and Cocoa I'd recommend using XMLRPC. The GNUstep webservices library provides (as a tiny part of its functionality) an XMLRPC coder and invocation methods, and this library can be built/used either with gnustep-make (for gnustep) or with xcode (for cocoa). ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: NSZoneMallocAtomic disappeared from NSZone.h in -trunk
On 24 Mar 2009, at 06:30, Sebastian Reitenbach wrote: sope doesn't compile anymore with gnustep-base trunk. When I take a look at the code in sope, how it is using NSZoneMallocAtomic there I see, it is using NSZoneMallocAtomic everywhere but for NeXT_Foundation_LIBRARY I guess, it may also be available on Mac OS X, but I've no possibility to check that out, at least googling NSZoneMallocAtomic only finds references to gnustep and libFoundation. I'm writing here, because of my research now, I'm not perfectly sure whether it was removed intentionally or accidently. The atomic malloc zone is a libFoundation/GNUstep specific extension. It is not, and has never been in Cocoa. It was removed intentionally ... I had no idea any code outside GNUstep core used it, as the old GC code never worked fully for me, but I received no bug reports from anyone else! Presumably the sope code would simply work if you replaced it with the default malloc zone. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: stringByDeletingLastPathComponent
On 29 Mar 2009, at 04:06, Omniscient wrote: On Mar 28, 11:40 pm, Markus Hitter m...@jump-ing.de wrote: Am 27.03.2009 um 23:10 schrieb oren: [@//host/share stringByDeletingLastPathComponent] produces @ and looks like a bug the doc said @//host/share should produces @/host/share removing ^/ ? looks like a typo there. FYI, Mac OS X 10.4 produces @/host which is what I'd expect. These extensions to NSString are meant to handle paths, not URLs. Simplifying // to / is correct. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitterhttp://www.jump-ing.de/ the whole doc is like this. @//host/share/file produces @//host/share/ @//host/share/ produces @/host/share/ @//host/share produces @/host/share I fixed that in svn. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: defaults read executed inside msys not finding .GNUstepDefaults
On 2 Jun 2009, at 15:38, Paul Terres wrote: GNUstep is not returning the user home directory correctly inside the msys shell. eg) Running defaults read from the ms command prompt it finds the .GNUstepDefaults file at C:\Documents and Settings\username \GNUstep\Defaults. However running defaults read from a msys shell it tries to read .GNUstepDefaults at M:\USERS/home/username which does not exist. I think it should look for .GNUstepDefaults either at /c/Documents and Settings/username/GNUstep/Defaults or /home/username/GNUstep/Defaults. Is there a work around for this problem? Most likely this is an error in your msys shell setup ... it's probably telling (via environment variables) the GNUstep application that your home directory (the HOMEPATH environment variable) is 'USERS/ home/username' and your drive (the HOMEDRIVE environment variable ) is 'M'. So to fix things, you just set the correct environment variable values (though perhaps simply unsetting the variables would be sufficient, if the fallback USERPROFILE environment variable is correctly set). Better still, you can find out where the incorrect values are being set in the environment (in .profile perhaps?) and fix that. Basically, this is all about environment variables, and nothing to do with GNUstep ... except that it's perhaps time GNUstep changed to use USERPROFILE in preference to HOMEPATH. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Issue with NSLanguages in startup 0.23.0
On 2 Jun 2009, at 19:15, Germán Arias wrote:
If I write into a shell
defaults write NSGlobalDomain NSLanguages (Spanish)
this is write in .GNUstep.conf file, but after the definition of
NSGlobalDomain. In other words, there are two NSGlobalDomain
definition.
The first with my keys configuration, location, and the second
only
with the language. Of course when I run an app this run then in
english.
I need write manually the language in the first NSGlobalDomain
definition and erase the second. With this all work fine. But why? On
Windows work fine.
I think you need to provide step by step instructions to tell us how
to reproduce the problem you are seeing, and explain in some more
detail.
The reason I say this is that I clearly don't understand what you
mean, and my interpretation of your words makes no sense:
You say 'this is write in .GNUstep.conf file' ... but GNUstep only
reads from GNUstep.conf, it doesn't write to it.
You say 'there are two NSGlobalDomain definition' ... but the defaults
are stored as an NSDictionary written to file ('GNUstep/
Defaults/.GNUstepDefaults' in the current implementation, though this
is likely to change), and it's impossible to have two values stored
with the same ('NSGlobalDomain') key in the dictionary.
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Finding and Loading Bundles
On 16 Jun 2009, at 23:49, Stefan Bidigaray wrote:
I'll try to be to the point... I'm need to be able to find some
bundles that conform to a particular protocol so that I can load
them and maybe use them. I've been reading the Apple docs and I
already know how to search the bundle directories and use -
conformWithProtocol:. What I'm having a hard time grasping is, how
do I find out if the bundle I'm looking at actually meets my
criterias before loading it? Is this even possible? Since NSBundle
doesn't support unloading (at least according to Apple) I don't want
to load every single bundle in the system just to then find out they
are just going to take up space. I've read the Apple Plug-in docs
and NSBundle Programming Guide, but I still don't know how to do
what I'm trying to.
I'm not at all sure you can.
It's true to say that you can't unload bundle code ... the gnu runtime
doesn't support it, and while I think I read somewhere that Apple's
new 64bit runtime would support it, the standard one definitely didn't
last time I looked.
As far as I'm aware, there's no convention for storing the protocols
supported by a bundle's principal class in its info.plist, so I don't
see how you can check what a bundle does without loading the code.
I think the normal way that an application determines which bundles to
load is by using its own directory/filename conventions, so you just
search the bundle directories for bundles with the correct names or
bundles in subdirectories with the correct names.
FYI: this is for the NSSound reimplementation effort... I'm trying
to support multiple plug-ins.
Well, as NSSound is a gui class, presumably bundles for it should
count as gui library resources. In GNUstep we do have a standard
location for gui library resources, and the GNUstep extension [NSBundle
+bundleForLibrary:version:] returns the bundle for that location. The
problem is, that only returns the bundle in the first domain found
(assumed to be the one associated with the library being used), and I
guess with plugins you would want to allow bundles to be provided by
something other than the standard gui library.
So, I think you are going to have to define your own conventions for
this.
I would suggest using
NSSerarchPathForDirectoriesInDomains(NSLibraryDirectory,
NSAllDomainsMask,YES) to get a list of library directories, then look
for specific naming patterns in those library directories.
eg.
Assuming your bundles are those with an 'nssound' extension located in
the 'Bundles' subdirectory ...
{
NSString *path;
NSArray *paths;
NSBundle *bundle;
NSEnumerator *enumerator;
NSMutableArray *all;
/* Gather up the paths */
paths = NSSearchPathForDirectoriesInDomains(NSLibraryDirectory,
NSAllDomainsMask, YES);
enumerator = [paths objectEnumerator];
all = [NSMutable array arrayWithCapacity: 10];
while ((path = [enumerator nextObject]) != nil)
{
bundle = [self bundleWithPath: path];
paths = [bundle pathsForResourcesOfType: @nssound
inDirectory: @Bundles];
[all addObjectsFromArray: paths];
}
return all;
}
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Comparing @encode() output
On 18 Jun 2009, at 01:53, Stefan Bidigaray wrote: Pretty straight forward quesiton, how do I compare the output of @encode? Instead of using bits per sample in the NSSound plug-in implementation I decided to use encoding since int and float both have the same number of bits. The only way I figured this would work would be to use @encode()... I went poking around in the Apple docs and can see it outputs a (const char *), but I noticed in NSPortCoder.m and NSArchiver.m compare using a switch(*type). So is the return value of @encode a string or int? I guess another question would also be if I should be using @encode to find the data type? @encode() returns a C-string I can't remember for sure where the contents of the string are documented (probably the ObjC language book, snce @encode() is part of the language), but for most data types the string contains a single character identifying the type. On the second question I don't see how you can use @encode() to find the type of something ... it's done at compile time, and if the compiler knows the type of a thing, then presumably you should too. What @encode() does for you is provide a string describing a type, which can then be passed to other parts of your program at runtime, to tell them what type you are using. Personally, if I was passing that information around at runtime, I'd probably do it more explicitly in the API. eg. - processSamples: (void*)data bitsPerSample: (unsigned)bits numberOfSamples: (unsigned)samples floatingPoint: (BOOL)floatOrInt; rather than - processSamples: (void*)data type: (const char *)encodedType numberOfSamples: (unsigned)samples; Apart from the greater clarity of putting the information explicitly in the API, the contents of the string produced by @encode() are processor dependent, so using it makes things trickier if you ever want to allow distributed objects to offload processing to another machine (I know thats unlikely, but it costs nothing to design with it in mind). ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Comparing @encode() output
On 18 Jun 2009, at 12:23, Stefan Bidigaray wrote: Thanks Richard. I'll use an approach close to what you mentioned there. Since I'll be doing something like that I might go a step further and also try to support other data types (like uLaw and aLaw audio). Do you think it would be a good idea to define some enum values to be passed? Yes, sounds great to enumerate the supported types of data rather than just having a boolean. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Comparing @encode() output
On 18 Jun 2009, at 15:00, Stefan Bidigaray wrote:
Just one more question... how sensible is it to use those OSTypes to
do it? I've seen them all over the Apple docs, but gcc spits out a
bunch of warnings.
Something like:
enum
{
GSSoundUChar = 'UCHR'
GSSoundSChar = 'CHAR'
GSSoundShort = 'SHRT'
}
The only point I see to using the compiler extension to initialize a 4
byte integer with letter is if you want the resulting integer to be
readily readable when viewed as a string ... pretty rare, and unlikely
to be an issue in this case. Probably better to stick to a simple
enumeration where the compiler will give you small integer values.
I wouldn't use names like GSSoundShort which are ambiguous (maybe a
future processor will have a 32bit short). I'd have thought something
like GSSound8BitPCM, GSSound16BitPCM, GSSound32BitPCM ...
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Problems with NSSocketPort and DO on WINDOWS
On 19 Jun 2009, at 16:03, Samantha Rahn wrote: All, I have been having a variety of trouble with DO on Windows when communicating across hosts. I suspect that inter-host DO on windows might currently be broken ... it's an awful long time since I tried it, and if nobody is actively using it, it could have bit-rotted at some point. You might try a simple test with an old release, just to check if this is the case. It was certainly fine a few years ago before we moved to using host- local connections by default. In order to diagnose the problem, I have simplified my code to avoid the name server and simply use DO with sockets (NSSocketPort). Using socket ports directly is trickier than using NSConnection, so perhaps not a great idea. I'm away this weekend, so I can't look at this stuff for a while. If you find this is actually a bug in base, please file a report at https://savannah.gnu.org/bugs/?group=gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: GNUmakefile and autogsdoc
On 31 Jul 2009, at 17:03, Martin Kalbfuß wrote: Hi Community, I'm new to gnustep. I try to set up a GNUmakefile. But I'm not sure how to organize the source distribution for my library. My current distribution directory structure consists only of one directory. No sub projects or something. All files are in this directory. It looks like: sdlwrap | +-- rect.h +-- rect.m +-- error.h +-- error.m +-- timer.h +-- timer.m +-- helpers.h +-- helpers-m +-- GNUmake My current GNUmakefile is include $(GNUSTEP_MAKEFILES)/common.make [code] LIBRARY_NAME = sdlwrap DOCUMENT_NAME = sdlwrap sdlwrap_OBJC_FILES = error.m \ helpers.m \ rect.m \ timer.m sdlwrap_HEADER_FILES = error.h \ helpers.h \ rect.h \ timer.h sdlwrap_HEADER_INSTALL_DIR = sdlwrap sdlwrap_AGSDOC_FILES = error.h \ helpers.h \ rect.h \ timer.h sdlwrap_AGSDOC_FLAGS = -MakeFrames YES include $(GNUSTEP_MAKEFILES)/documentation.make include $(GNUSTEP_MAKEFILES)/library.make As you can see from the Makefile, I create some documentation from the headers with autogsdoc. But the problem is, that I have to name the documentation sdlwrap like the library to get a correct install directory for the documentation and a correct title for the documentation. But when I do this the created documentation is stored in a subdirectory called sdlwrap which is confusing. Better would be doc or documentation. I can add the -DocumentationDirectory option to AGSDOC_FLAGS, but then make clean doesn't work for the documentation. What's the right way to go? Is there a variable to set the output directory? I don't think gnustep-make supports that ... it expects to find the documentation in the normal location when it's cleaning. If you want to use -DocumentationDirectory to specify an alternative location to autogsdoc, then you also need to tell the makefile to remove that alternative location when it cleans. You can use the 'after-clean:' target in gnustep make to add commands to be executed after cleaning. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: My name isn't accepted by autogsdoc
On 2 Aug 2009, at 23:06, Martin Kalbfuß wrote: As you can see m?y name has a non-ASCII letter at the end. autogsdoc doesn't translate it correctly to the html page. The last letter is lost. Is there a possibility to get this working? The current code should be producing utf-8 output (which is correct up to a point) ... your web server/browser combination might be expecting latin1 rather than utf-8 I think it counts as a bug ... for best portability/reliability we should really output ascii with #NNN; excape sequences for unicode characters which aren't ascii. I have attempted a fix to that in svn trunk. Please let me know if it works. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Problems with GNUMail or GSDecorationView?
On 19 Aug 2009, at 09:38, Tim Kack wrote: Note, at this point _delegate will be 0xdeadface because the EditWindowController has been deallocated and therefore respondsToSelector will crash. Now, my question is - is this a GNUMail bug (i.e. the NSToolbar should have been deallocated earlier) or is it a problem with the GSWindowDecorationView removeToolbarView? Perhaps there should be a check if the delegate still is valid before calling setFrame? I'm not really familiar with the code concerned, but from your description it sounds like the bug is in EditWindowController If EditWindowController has set itsself as the delegate for a window, it should also have removed itsself as the delegate at the start of its -dealloc method. It's a firm rule that an object must remove itsself as a delegate of any other object before it deallocates itsself. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: General question about GNUStep
On 25 Aug 2009, at 17:17, Nicolas Roard wrote: On Tue, Aug 25, 2009 at 4:49 PM, David Chisnallthera...@sucs.org wrote: I'm not sure why this follows. Just because you can't use DO doesn't mean you can't use GNUstep on the server. By the way, in theory it ought to be possible to port GNUstep's NSPortCoder to Cocoa and use this for serialising messages to be sent across sockets. This would let Cocoa apps talk to GNUstep ones via DO. David In my experience, the simplest (one-liner!) and robustest solution was indeed to send plist-serialised data over the wire -- both platforms (GNUstep and OSX) support fast serialization/deserialisation to plist, and as an added benefit this is easier to debug as the data is sent in clear, and in a notably more efficient way than XML do :) you can find some infos on the architecture I used in http://xdev.org/thesis/phd-thesis-nicolas-roard.pdf Note that writing a plist reader in java or C++ is quite simple. Another possibility is to use XML-RPC, which has implementation everywhere. But this is quite verbose (even if it's far from the abomination that SOAP is). I agree that using the NSPropertyListSerialization class gets you the most efficient way of serialising/deserializing objects in a manner portable between GNUsterp and Apple. It's quite easy to serialize objects, put the result in the body of an HTTP POST request, and have the other end send back serialized objects in the body of the HTTP response. You can be even more efficient with your own protocol rather than HTTP, but HTTP support is so readily available that it's convenience probably outweighs any overheads for most applications. I also agree that XML-RPC is another good option. Within the GNUstep base library we have XML-RPC support, but I also wrote an XML-RPC implementation in the WebServices library, and that one builds and runs on OSX with the Apple Foundation, so it should build on the iPhone. It's less efficient than using NSPropertyListSerialization, but arguably a little clearer to code (and easier to inspect the data going over the wire for debug purposes than binary plists). The WebServices library also supports web services using SOAP, but again I agree ... IMO you should *never* use WebServices/SOAP voluntarily (ie unless you absolutely have to in order to connect to some other system which is already using it). ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: GNUmakfiles - sources must be in project's root?
On 26 Aug 2009, at 10:31, Juergen Lorenz Simon wrote: Hi, I'm trying to shoehorn GNUstep onto an existing project. During the creation of the GNUstep makefile (originally I had the luxury of cmake), I found I could not add sources like this: foo_OBJC_FILES = src/App/main.mm \ src/App/Protocol.mm \ ... The result in calling make -f GNUmakefile is: This is gnustep-make 2.2.0. Type 'make print-gnustep-make-help' for help. Making all for objc_program foo... make[2]: *** No rule to make target `obj/src/App/main.mm', needed by `obj/foo'. Stop. The question is: how do I add sourcefiles, which are organized in several subdirectories, to the GNUmakefile without having to create subprojects or reorganize the project layout? I perused the GNUstep module and application sources, I can't seem to find example. I think the short answer is you don't ... that's what subprojects are for. There's probably a way to do it, but part of what makes gnustep-make so simple and easy to use is conforming to the well defined and consistent patterns it uses. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: framework
On 27 Aug 2009, at 14:41, David Chisnall wrote: On 27 Aug 2009, at 11:24, Michael Thaler wrote: Objective C is not in the list but I doubt that Objective C would be much faster then Java if you actually use Objective C and not just a plain C subset. And Scala also runs on the JVM and is also quite fast and it is a very nice, modern language which is not clumsy at all. If you can find an older version of that page, Objective-C used to be there with an average score of 1.6 (about the same as Java now) for speed, and much lower memory usage than Java. The implementations all used pure message passing - no C functions, no IMP caching. While ObjC may be faster than Java on the benchmarks as well, my original comment was based on real-world usage where ... 1. The language flexibility lets you focus on, and rework the overall design, optimising details *late* 2. In ObjC it's trivially easy to drop back to plain C in critical sections, so you can perform additional optimisation ... which (in my experience) means that for large, complex applications ObjC works out faster than C++ despite the fact that C++ is much faster in specific benchmarks. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Objective-C 2.0
On 2 Sep 2009, at 12:17, Michael Thaler wrote: Hi, I am currently learning Objective-C on the Mac (using that book:-)) and I was wondering if Objective-C 2.0 is available on Linux and if it can be used for gnustep development. If it is available is it ok to use it for gnustep? If it is not available, are there any plans to support it? It's not available. There are people working on different bits of it, but no concerted plan. I think especially having a garbage collector would be quite interesting. Personally I think having a GC would be a sustantial advantage of gnustep over, e.g. Qt. GNUstep has GC support in the make package and base library, but nowhere else. It's not quite the same as Apple's implementation, but shares most of the same API. I have to say that GC has to be considered at best beta-test quality and getting it working four you would probably take some effort. If it is partly available, which features can (should) be used? Are blocks available (which seem to be a propertery Apple extension to C-like languages)? I would avoid most of the new features. Largely the gcc compiler doesn't support them (though David Chisnall is working on adding support for a lot to Clang). Often the new features are arguably bad. You should be able to use fast enumeration (the API is there in gnustep-base, even of the lack of compiler support means that you won't actually get the promised performance benefit). You should be able to use GC with some work. I'd avoid using properties ... even if/when we do get support for properties, I'd argue that they do more harm to code clarity/design than can be compensated for by their advantages. Is it possible to write applications that can be compiled on both the Mac using Cocoa and Linux using gnustep? Sure ... very easy ... just develop on GNUstep and then build from the GNUstep source on the Mac. Doing it the other way round is the harder way as it's much easier to find yourself writing non-portable code on the Mac, but if you stick strictly to the Cocoa APis (the older ones) you would probably be OK. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Please test new NSLock implementation!
On 2 Sep 2009, at 14:12, David Chisnall wrote: Hi Everyone, I've just committed a new version of all of the NSLock family of classes to GNUstep-base, and a slightly reworked NSThread. Bugs in this code have the potential to break any multithreaded applications, so please test them on your favourite platform, with your favourite applications. And on platforms you hate with apps you can't stand, for that matter. As a result of this change, GNUstep now depends directly on POSIX threads. If you are building on Windows, you will need to download the pthread-win32 package from here: http://sourceware.org/pthreads-win32/ Any clues on getting this working in mswindows? Grabbing the latest executable from a sourceforge mirror, I put the headers in mingw/include and the libraries in mingw/lib ... That was sufficient for the headers to be found, but I got tis .. Linking library libgnustep-base ... obj/NSLock.m.o: In function `i_NSLock__init': C:/GNUstep/home/richard/devmodules/core/base/Source/NSLock.m:165: undefined reference to `_imp__pthread_mutexattr_init' C:/GNUstep/home/richard/devmodules/core/base/Source/NSLock.m:165: undefined reference to `_imp__pthread_mutexattr_settype' C:/GNUstep/home/richard/devmodules/core/base/Source/NSLock.m:165: undefined reference to `_imp__pthread_mutex_init' and lots more similar messages. I'm guessing that gnustep-make needs updating to find the thread library and add it? Do you know what the link arguments should be? Another thing ...do we need to build/use a different version of the objc runtime too? Presumably the runtime needs to be built with the same thread library as the rest of the system. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Please test new NSLock implementation!
On 4 Sep 2009, at 08:29, Wolfgang Lux wrote:
Fred Kiefer wrote:
The old version used objc_mutex_t, which was a void*. A mutex is
typically either one or two words, depending on the implementation.
Using malloc for this is very wasteful, both in terms of speed,
cache
usage, and memory footprint. The objc_mutex_alloc() function was
doing
malloc(sizeof(pthread_mutex_t)); on some platforms (e.g. FreeBSD)
pthread_mutex_t is a pointer to some other structure, so we were
tying
up three cache lines for a two word data structure. This is far
from
ideal.
Not sure if I getting this correctly but on my 64-bit Linux system I
have # define __SIZEOF_PTHREAD_MUTEX_T 40 and 24 for a 32-bit system.
We are rather talking about 12 to 20 words here not one or two.
Indeed your are getting this correct. Using the test program
#include pthread.h
int main()
{
pthread_mutex_t mutex;
printf(sizeof(mutex) = %d\n, sizeof(mutex));
return 0;
}
I've collected the size of a pthread mutex on a few x86 platforms:
OS X 10.5 (x86): 44
Solaris 10 (x86): 24
NetBSD 5.0 (x86): 28
OpenBSD 4.5 (x86): 4
FreeBSD 7.2 (x86): 4
OpenSUSE 11.1 (x86): 24
So it looks like David is attempting to optimize code for his platform
while making things worse for everybody else :-(.
Fred was IMO completely correct to point out that putting pthread.h
and types declared in it in NSLock.h exposes internal workings ... and
we have a policy of not doing that as a general principle. However,
I think it's an unjustified jump to saying this is making things worse
for everyone else ... you need to look at the practical effects of the
change. ... se below.
What do others think, is it worthwhile to hide these implementation
details via another indirection or not? I am still in favour of
using an
opaque data type here. On systems like FreeBSD where
pthread_mutex_t is
itself a pointer we could use that directly and on other systems we
have
one additional malloc and free call per mutex. And where the
structure
fits into your one or two words we could even put the value into the
ivar directly.
I absolutely agree with you here. The interface should not expose
any of
the implementation details unless there is a really pressing need to
do
so. I understand David's reasoning that the approach with an opaque
pointer may lead to additional cache misses on FreeBSD (and apparently
OpenBSD as well), but without hard figures -- i.e., benchmarks for
real
world programs making intensive use of NSLocks that show a substantial
performance improvement -- I consider this kind of coding premature
optimization which should be avoided.
OK ... I agree with this principle, but look at why ...
1. we don't want to expose internal workings because we don't want
developers to start to depend on those internals in such a way that
it's hard for us to change things later without breaking existing
applications.
2. we don't want to expose internal workings because changes to them
may break API and mean that apps need to be recompiled.
Issue 1 is real, but we can't quantify how important it is as it's a
amatter of perceptions rather than a true technical issue. Luckily
it's quite easily largely fixable, simply by removing pthread.h form
the header and replacing the types from pthread.h with opaque dummy
types of the same size, so that there is no temptation for developers
to use them directly. So I did that, though really, I'm not sure that
was worth the bother, since the ivars concerned were already clearly
marked as private. I guess it's just good to do it to avoid having
the extra symbols polluting developers namespaces.
Issue 2 is a technical problem ... if someone subclasses one of the
lock classes, their compiled code is obviously dependent on the size
of the superclass and if that size changes (eg due to using a
different pthread implementation) then the size of the superclass
would change even though the version of the base library is
unchanged. So potentially an app linked with one copy of the base
library would fail to run properly with another copy of the library
even though it was the same version!
That sounds really bad, until you think about the chances of it
actually happening ... you would have to have two versions of the
pthread library, with different sized pthread_mutext_t types available
on the same system. You would have to have apps which are subclassing
NSLock or NSRecursiveLock or NSCondition. You would have to have
built those apps with a base library built using one version of the
pthread library, and then you would have to be running with a base
library built with the other version of the pthread library. In
reality, I don't expect that would ever happen (unless perhaps, a
developer is playing with thread library development themselves ... in
which case they are unlikely to have any trouble spotting/resolving
the issue on their own).
Balanced
Re: User's GNUstep directory
On 18 Sep 2009, at 16:03, Philippe Roussel wrote: Hi all, Currently I'm using the hardcoded path @~/GNUstep/Library/ SimpleAgenda to save the local calendars users create in SimpleAgenda (if I create a local agenda called 'private', it will be saved in the file ~/GNUstep/Library/SimpleAgenda/private). I am wondering if : - it's a good place to save user data - if there's a better way (not harcoded) to get this directory, something like [NSApp libraryPath] ? Any hint ? Something like ... path = [[NSSearchPathForDirectoriesInDomains(NSLibraryDirectory, NSUserDomainMask, YES) lastObject] stringByAppendingPathComponent: @SimpleAgenda]; or probably better ... path = [[NSSearchPathForDirectoriesInDomains(NSApplicationSupportDirectory, NSUserDomainMask, YES) lastObject] stringByAppendingPathComponent: @SimpleAgenda]; ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: question for gdb users...
On 24 Sep 2009, at 04:40, Matt Rice wrote: there is some discussion here about removing the convenience mechanism that allows you to go break foo where foo then turns into -[class foo] this causes lots of issues which are fairly hard to fix in gdb, which is why the whole 'break main' with recent gdb causes issues. because of [NSThread main]. if you guys opposed to it please let me know and I will relay it into the gdb thread, I for one wasn't even aware of this feature until it started causing problems http://sourceware.org/ml/gdb-patches/2009-09/msg00734.html here is the thread. I use this feature tens of times a day, perhaps more ... it's actually almost the only way I set breakpoints (though I occasionally set breakpoints at particular lines or in C functions). Now, it's not obvious, from a quick read of the thread, why there is a specific problem with objc ... though it seems to imply that objc is a special case and this feature is fine in C++ and desired in pascal and ada. I don't mind using the 'break [class method]' syntax where I know that the implementation of the method is in one particular class, but *usually* I don't know which class I want to break in (because I'm not aware of all the libraries/subclasses that might be involved). If the underlying problem is one of confusion between objc methods and C functions (the example of the confusion between the main() function and the [NSThread-main] method suggests that this may be the case) then perhaps it could be resolved using a modification of the square brackets syntax ... at present we have: +[class method] a factory method of a specific class -[class method] in instance method in a particular class [class method] either a factory method or an instance method, with an option to choose if both exist and could add: +[method] a factory method of any class -[method] in instance method in any class [method] either a factory method or an instance method, So 'break [method] would be like the current 'break method' syntax but 'method' would be treated *only* as an ObjC method name, never as a function or method in another language. If this would help resolve the issue, it would satisfy me. Simply losing the ability to set a breakpoint in any class would not. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: question for gdb users...
On 24 Sep 2009, at 08:50, Matt Rice wrote: On Thu, Sep 24, 2009 at 12:16 AM, Richard Frith-Macdonald rich...@tiptree.demon.co.uk wrote: On 24 Sep 2009, at 04:40, Matt Rice wrote: snip The specific problem is that gdb resets breakpoints upon shared library load, in case symbols were overriden by c-linkage behaviour the 'canonical' version of 'main' is 'main', where the canonical version of '-[NSThread main]' when gdb resets the breakpoint on shared library load to check for a new address for 'main'. it will respond with more than one address, because main is ambiguous, so its unable to tell which of the symbols you actually want a breakpoint on. now imagine if the function was named init :) This sounds like an issue with the way gdb stores its breakpoints ... shouldn't it be storing more information so that it can disambiguate? I guess probably understanding this requires a fairly detailed knowledge of the symbol representation used in the libraries and in gdb ... which I lack. However, it's clear that at time point gdb is able to examine the binaries to get enough information to offer me a selection of places to break when I type 'break init' ... so there is sufficient information somewhere. Now, for instance, if I type 'break init' I am presented with a numbered list of all the implementations of -init, and can type in a the number of an item to set a breakpoint in (for instance -[NSString init]. I would have expected gdb to record the fact that a breakpoint had been set in the NSString implementation of init rather than any other implementation, and be able to use that to determine which implementation in a newly loaded shared library should be used. I can also type in '1' to set a breakpoint in *all* implementations of init ... in which case, why would we care if there are multiple addresses in a newly loaded library .. we want all of them anyway. Anyway ... perhaps it's not that straightforward, and perhaps even if it *is* that straightforward conceptually it's still a lot of work to implement changes., so I'm not trying to second-guess the basic objection. snip +[method] a factory method of any class -[method] in instance method in any class [method] either a factory method or an instance method, these are good ideas, I was thinking +method/-method and was kind of perplexed on what to do for both, [method] might work, i was also thinking ?method, which has no real objc relation, but might be familiar to those using the shell? The '?method' syntax would not have occurred to me. I just thought that keeping on using square brackets would be familiar in objc. Another possibility might be 'wildcarding' the class name rathe than simply omitting it eg. [* method] or [? method] but I think I prefer the simple omission of the class name. So 'break [method] would be like the current 'break method' syntax but 'method' would be treated *only* as an ObjC method name, never as a function or method in another language. If this would help resolve the issue, it would satisfy me. Simply losing the ability to set a breakpoint in any class would not. you could still do this with the rbreak command, by using 'rbreak .*methodname.* so even if we remove the function and we don't reintroduce an alternative syntax this is still possible. I don't really consider rbreak a viable alternative as it's too clumsy for routine use ... 1. you have to remember that it's using a regular expression, and put in correct limitations to avoid getting far too many matches (try 'rbreak class' for instance). 2. it doesn't present you with a list of possible matches and ask you to select the one you want ... instead it tries to set breakpoints in all the matching methods and gives you a load of yes/no questions about methods in classes not yet loaded. So yes, it's *possible* to use it, but it's not a good substitute for 'break methodname' ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Problems building gnustep-back on fedora 8
On 30 Sep 2009, at 19:13, Pablo Giménez wrote: Yep I have all the core packages compiled and installed, tomorrow I will try to install the extra libs The problem was that the locale must be an utf, I had en_GB in the LANG environmetn variable, when I have changed it to en.GB.utf8 it works. My guess is that GNUstep needs an unicode environment to work properly. I think you are right. I have committed a fix to gnustep-base (the file GHSLocale.m) in svn trunk, which I hope will correct the problem. Please could you give it a try and let me know if it cures the bug for you. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Building some extra libs (renaissance, gnustep-guile,
On 1 Oct 2009, at 11:54, Pablo Giménez wrote: Hi After been able to build the core packages now I face the extra libs. Well I have tried to build some of them, I have to admit whithout luck, here are my problems: - Renaissance 0.8.0: I checked in svn ... the author made a 0.9.0 release 18 months ago, but didn't update the website, and since then there are several improvements/fixes in svn. You should use the version from svn (which does work with the more recent versions of GNUstep). - gnustep-guile 1.1.4: This is an old library, and you need an old version of GNUstep (and old version of Guile) to build and run it. - StepTalk: Also old ... you might want to port this to the more recent releases though? - SQLClient 1.3.0 I can't configure the package I am trying with the next configure statement: ./configure --disable-jdbc-bundle --with-additional-include=-I/usr/ include Just running ./configure should be sufficient, though the options you used should do no harm. but it can't find the includes for mysql, postgres ans sqlite. I have checked and all of them are in the /usr/iclude as usual. Then you need to look at output/log file from the configure script ... it should record why the headers don't work. The usual reasons for headers not being found are: 1. development packages for the databases not installed on the system (obviously the packages need to be installed) or 2. headers not in /urs/include (perhaps in a subdirectory or in another header directory ... in which case you need to use --with- additional-include= to specify the correct directories. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Building some extra libs (renaissance, gnustep-guile,
On 2 Oct 2009, at 11:34, Pablo Giménez wrote: - SQLClient 1.3.0 I can't configure the package I am trying with the next configure statement: ./configure --disable-jdbc-bundle --with-additional-include=-I/usr/ include Just running ./configure should be sufficient, though the options you used should do no harm. This is still driving me nuts, the configure is still claiming about my mysql header files. I have check and I have there in the usual path: /usr/include/mysql/ But I got this error in config.log: configure:3196: result: no configure:3200: checking mysql/mysql.h presence configure:3210: -I/usr/include/ conftest.c ./configure: line 3211: -I/usr/include/: No such file or directory configure:3216: $? = 127 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME | #define PACKAGE_TARNAME | #define PACKAGE_VERSION | #define PACKAGE_STRING | #define PACKAGE_BUGREPORT | /* end confdefs.h. */ | #include mysql/mysql.h configure:3236: result: no configure:3271: checking for mysql/mysql.h configure:3278: result: no configure:3386: checking if Sqllite support was manually disabled configure:3401: result: no: build if possible configure:3418: checking sqlite3.h usability configure:3430: -c -I/usr/include/ conftest.c 5 ./configure: line 3431: -c: command not found configure:3436: $? = 127 configure: failed program was: How is possible that the configure says I don't have a /usr/inclide folder when is obvius is there? That's very strange, but I confirmed the behavior on my system. Based on a lot of trial and error, it seems that --disable-jdbc-bundle triggers some autoconf bug such that subsequent tests fail. To get things to build, I suggest you just run ./configure I have put a workaround in configure.ac in svn trunk (adding an extra call to AC_CHECK_HEADERS before the test to see if jdbc is disabled seems to avoid the problem. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Changes I've been thinking of...
On 7 Oct 2009, at 20:24, Gregory Casamento wrote: Guys, There are a number of things which need to change on the project: We need to: 1) improve our website. It's been the same for years and doesn't reflect our progress. I've been dissatisfied with it too. Not the basic appearance, which is generally a pleasantly clean/simple design, but more in function ... a. If we can figure out what key areas of interest there are, we can link to them from the home page in a manner which makes it easy for people to find them. For instance, I recently noticed there was no link to the windows installer from the home page, so I added one. b. Some inspiring news ought to be frequently updated on the front page. c. links should be kept up to date ... old code which is no longer supported should be flagged as such or moved away from more current downloads. d. the navigation links on the right should be highlighted in some way ... we read from left to right, and it's easy to fail to notice those links. Look at http://www.apache.org/ for a clearer presentation with a broadly similar layout. 3. we should have a site search field on the home page! The lack of a search facility is really annoying when someone is looking for something specific 2) improve GNUstep's default theme as well as theming in general. While I know some people will respond negatively to changing the default theme from a NeXT-like look to something more modern, Then why did you say it? ... that's rather foolhardy. I believe it's one way for us to spark interest in the project is to update it's look. That's not a reason to change the default theme. It's a reason to try to develop at least one good alternative theme. You should not be proposing a change which will provoke argument when the alternative would achieve the same in a relatively non-contentious way/ If/when a genuinely better theme can be produced, people will WANT to adopt it as the default. The objective should be to develop a good theme (or multiple good themes). The current look should always be available, but not necessarily the default. 3) Improve our ability to market ourselves in general. Can't argue with that. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Changes I've been thinking of...
On 7 Oct 2009, at 22:28, Stef Bidi wrote: The second, which is a little deeper, is that there's no way to globally define defaults. If I'm out there creating a GNUstep package (and I mostly do for Slackware, I just need to get on it for 13.0) there's not way for me to set a default, preferred theme-- which is what the GUI toolkits above allow you to do--there is just no way for me to do that. Actually, you can define global defaults in the GobalDefaults.plist file, which lives in the same directory as the GNUstep configuration file (and you can also put simple string values directly in GNUstep.conf using GNUSTEP_EXTRA if you don't want the overhead of loading GlobalDefaults.plist). See http://www.gnustep.org/resources/documentation/Developer/Base/Reference/index.html and the NSUserDefaults documentation. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Changes I've been thinking of...
On 7 Oct 2009, at 23:37, Riccardo Mottola wrote: Richard, could you add the ability to change the theme icon in Thematic? It's already there ... just click on it, and an open panel will come up for you to select the new icon image. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Changes I've been thinking of...
On 7 Oct 2009, at 23:00, David Chisnall wrote: On 7 Oct 2009, at 22:38, Matt Rice wrote: On Wed, Oct 7, 2009 at 2:28 PM, Stef Bidi stefanb...@gmail.com wrote: snip 13.0) there's not way for me to set a default, preferred theme--which is what the GUI toolkits above allow you to do--there is just no way for me to do that. I know it's been brought up a few times in the past, and if I remember correctly it's because of the way NSUserDefaults is setup, so (again, in my opinion) that's where the problem lies. I believe you are mistaken, NSUserDefaults handles global settings fine, you just need to add the default to the NSGlobalDomain, Unless I have missed something, NSGlobalDomain is a per-user thing. Yes. There is no sensible way of setting a default value for a user default globally. GlobalDefaults.plist does that. Apps can do this via the standard APIs, but there is no way for packagers to provide a default value for a default. GlobalDefaults.plist does that. For example, we can put Camaelon and Nesedah in a package, but there is no way to make it the default theme for any users who have not selected a theme as part of the package installation. GlobalDefaults.plist does that. This question has been asked on the list before and no one replied with a way, so I assume it is still impossible. Maybe nobody bothered to answer, or they did and you missed it. It would be nice to have a standard directory for plists which are merged together to provide the default user default values. I looked at doing this a while ago, but it required implementing whiteout in the per-user defaults (so you could delete a default that exists in this directory). The per-user defaults override the global ones ... what we don't have is a mechanism for having global defaults which can't be overridden but I'm not sure we want to do that (it seems to be against the spirit of free software). ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Changes I've been thinking of...
On 8 Oct 2009, at 10:32, David Chisnall wrote: On 8 Oct 2009, at 07:29, Richard Frith-Macdonald wrote: GlobalDefaults.plist does that. Two questions then: - Is this actually documented anywhere? I see a vague reference to it in NSUserDefaults, but packagers are absolutely not going to read API docs (and should not be expected to. With the documentation for GNUstep.conf in the main base library documentation (I put a link in an earlier email). I think you have to be realistic ... a packager *does* have to read some documentation in order to package a big system like GNUstep properly. It would undoubtedly be good to have some packager-specific documentation, but obviously the target readership is a very small group - How does this allow a packager to install and remove defaults as part of package installation / uninstallation? Presumably you can use plmerge to install them (again, is this documented anywhere?), but how do you uninstall them? This is a text property list ... a packager would manage it in exactly the same way as any other text file they install/uninstall with their packaging system. Probably something as simple as 'rm -rf /etc/GNUstep' when you are removing GNUstep from your system. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Changes I've been thinking of...
On 8 Oct 2009, at 12:00, David Chisnall wrote: On 8 Oct 2009, at 11:50, Richard Frith-Macdonald wrote: - How does this allow a packager to install and remove defaults as part of package installation / uninstallation? Presumably you can use plmerge to install them (again, is this documented anywhere?), but how do you uninstall them? This is a text property list ... a packager would manage it in exactly the same way as any other text file they install/uninstall with their packaging system. Probably something as simple as 'rm -rf /etc/GNUstep' when you are removing GNUstep from your system. You misunderstand the question. Here's a concrete example: Camaelon, EtoileBehavior and EtoileMenu all provide appkit user bundles. They are each installed as separate packages. A person creating a package for them wants to make them default for every user. This requires: 1) When the package is installed, each needs to be added to the NSGlobalDomain GSUserAppKitBundles array. 2) When the package is uninstalled, each needs to be removed from the array. Step 1 can, I believe, be accomplished with plmerge. How would you go about doing step 2? You are right, I did misunderstand ... I understood the term 'packager' to refer to the person/people responsible for providing GNUstep with a distribution ... ie for a set of packages which are all intended to work together as part of an entire system (such as Ubuntu) and where the 'packager' would reasonably be expected to set policy for all users of the system. I think what you are suggesting is probably (usually at least) undesirable ... a person providing a single package of their own piece of software should probably *not* be setting policy for the system and therefore should not be setting global defaults. However, for the scenario you are suggesting the answer is still pretty much the same ... the packager could do it the same way as with most other software ... edit the file using standard unix tools such as sed and awk. Of course, we could provide specific utilities like plmerge, but 'standard' unix techniques of marking sections of the file with comments and removing/inserting stuff between those comments would work just fine. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Changes I've been thinking of...
On 8 Oct 2009, at 12:46, David Chisnall wrote: On 8 Oct 2009, at 12:22, Richard Frith-Macdonald wrote: You are right, I did misunderstand ... I understood the term 'packager' to refer to the person/people responsible for providing GNUstep with a distribution ... ie for a set of packages which are all intended to work together as part of an entire system (such as Ubuntu) and where the 'packager' would reasonably be expected to set policy for all users of the system. On most systems I've looked at, the same person is responsible for maintaining the core GNUstep packages and a number of application / bundle packages. Yes ... that's what I was thinking of. I think what you are suggesting is probably (usually at least) undesirable ... a person providing a single package of their own piece of software should probably *not* be setting policy for the system and therefore should not be setting global defaults. Not at all. If a person installs a theme, for example, or something like WildMenus then it is generally understood that they will want to use it. If this person is installing it systemwide, then it is generally understood that they will want to use it for all users. If you install any systemwide GNUstep bundle then the package should enable it by default for all users. I am not talking about someone installing a bundle in their home directory after compiling from source, I am talking about someone installing a package. Someone wanting to install a GNUstep-based environment will typically just select a metapackage in their package manager and install everything (GNUstep core, bundles, frameworks, and apps) in one blob; they should not then be expected to configure things by hand, and they especially should not be expected to configure things by hand per user. OK ... we just have different perceptions here then. In those circumstances I expect a package to be *available* to all users, but NOT to be automatically forced on them. Certainly *I* don't want to have something like that imposed on *ME* just because someone else installs a package globally. That's what I mean about 'policy' ... I don't mind policy being set by the person who managed the distribution (I wouldn't be using the distribution if I didn't think its managers policy was a good one), but I would hate to have it set just because someone else sharing the system with me decides to install a package and make it available to me. We can probably agree to differ on this ...it's not really very relevant. However, for the scenario you are suggesting the answer is still pretty much the same ... the packager could do it the same way as with most other software ... edit the file using standard unix tools such as sed and awk. Of course, we could provide specific utilities like plmerge, but 'standard' unix techniques of marking sections of the file with comments and removing/inserting stuff between those comments would work just fine. Adding an entry to a dictionary that may or may not already exist in a plist file is... nontrivial with sed / awk. You will note that other software these days generally does not modify files like this. Instead, they provide a configuration directory. A good example is Apache, where various modules are generally installed as separate packages. In the bad old days, things worked exactly as you describe. Packages modified the configuration file, and if you were lucky installing or removing a module package would not trash your httpd.conf (although good luck if you ever tried to upgrade a module package). Now, each module installs a separate configuration file. Well I really don't see your problem ... It *is* trivially easy for someone familiar with unix tools (awk in particular) to add entries to a property list using those tools, especially if you (as the package manager) control what's in there anyway. If you don't happen to like doing it that way (I tend to agree with you there, but I gave the sed/awk example as the method most frequently used historically), you can use the mechanism in the example you gave yourself (from apache) and just build the plist by merging plists from the installed packages (in which case you handle uninstall by uninstalling your package and rebuilding the global defaults plist from the remaining installed packages with plmerge). Either way, my point remains the same ... it's up to the packaging systems used by the distribution how they do things, the task is much the same as with any other software, not a GNUstep specific issue, and it's really not our concern how packagers for different distributions do things. If you are putting together a package for Debian, you ask the Debian maintainers how they want things done rather than asking the developers. We can certainly give advice, but it's not our job to dictate
Re: Changes I've been thinking of...
On 8 Oct 2009, at 16:45, Nicola Pero wrote: It would undoubtedly be good to have some packager-specific documentation, but obviously the target readership is a very small group We *do* have packager documentation, in core/make/README.Packaging Yes, but I was meaning on the website ... Maybe it would be enough to copy that file onto the website and link to it? Feel free to add a short section about what was discussed here. :-) OK. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Changes I've been thinking of...
On 8 Oct 2009, at 17:29, Matt Rice wrote: On Thu, Oct 8, 2009 at 5:30 AM, Richard Frith-Macdonald rich...@tiptree.demon.co.uk wrote: OK ... we just have different perceptions here then. In those circumstances I expect a package to be *available* to all users, but NOT to be automatically forced on them. Certainly *I* don't want to have something like that imposed on *ME* just because someone else installs a package globally. there is no enforcing here, people could easily set defaults write NSGlobalDomain GSAppKitUserBundles '()' to get no theme bundles, I do this e.g. for using themes in every application except Gorm It just pushes the burden of setting defaults onto those that don't want to follow the global installation instead of those that do, I am completely fine with installing defaults system wide (as long as the system domain doesn't override the global domain) Perhaps 'forced' was too strong a word, but the basic issue for me is that I don't want other people changing the way my applications behave. Having them make a behavior change which I couldn't set back would be intolerable. Having them make a change which I then need to figure out how to revert, is annoying/undesirable. The second case is what we are talking about here. If behavior of the system just suddenly changes because a package someone installed has changed a global default, It's going to take me time and effort to figure out what happened and how to reverse it So, IMO global defaults should be used very sparingly, and should be used by the managers of distributions, not by people making individual app/library/bundle packages (except where the defaults only effect those specific packages of course). The very last thing you want is for every theme developer to set a global default to make their theme the one everyone uses... that decision should belong to the person who supplies the distribution, not the individual theme packages. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Changes I've been thinking of...
On 9 Oct 2009, at 13:03, Felix Holmgren wrote: While I sympathize with David who prefers (or is used) to some other coding style, the GNUstep project needs a consistent coding style and the GNU coding standard are as good a choice as any. Since GNUstep is a GNU project, it's a natural choice. Given that part of the aim of GNUstep is to track Cocoa, might it not make sense to use the Apple coding guidelines for everything that's written in Objective-C? http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html Those guidelines ARE pretty much consistently used in GNUstep. The coding style issues we are probably talking about here are those to do with the use of: indentation brackets white-space Generally, whenever someone comes along and complains about the style used, they have their own 'good reasons' why their style is preferred/ justified. Certainly, when I started working on the GNUstep project, my style was very different from the GNU style, and I could have provided reasons why my style was better :-) None of those arguments carry any weight whatsoever ... because there are always plenty of people with other preferred styles and their own reasons for using them. We use the GNU style almost solely because of the value of consistency (the fact that we are a GNU project probably explains why it was originally chosen) ... once you are used to it, you can work on any part of the code without finding the style hard to read. While there are a few 'religious' people who are convinced that everyone else should adopt their style, almost everyone accepts that a consistent standard is useful and that any attempt to change the style, once adopted, would be severely counterproductive. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Themes [Was: Changes I've been thinking of...]
On 12 Oct 2009, at 06:10, Germán Arias wrote: El dom, 11-10-2009 a las 13:34 +0200, Fred Kiefer escribió: Germán Arias schrieb: 3) Themes: Well, there are currently people working on it. Are you sure about that? Riccardo has build at least one theme. I have heard that Greg was building a Windows theme and also worked on porting Camaelon to GSTheme, but never seen any of it. Are there more themes (based on GSTheme) out there? What is there state, what problems are people facing and why are there so few contributions to extent the theme support in GNUstep? Well maybe I should be more precise There are people working to implement GSTheme. But even with the current state, I believe that much can be achieved with the colors (there are bugs but a few). For example, I thought about a tool that could be very useful for packagers. This tool gets the name of the user's theme and provides a similar theme for GNUstep. Sounds nice, copying the color schemes might go a long way towards making things fit in. Or just provide a lot of themes and enable to SystemPreferences establish a global theme. Also sounds good. Easy to just list the installed theme names and set one of them as the GSTheme value in NSGlobalDomain. A bit more work if you want to be able to 'preview' a theme before setting it as a default, but still not too hard, and a really quite useful. The code in GSThemePanel.m which lets you select the theme for your running application could be used as a starting point. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Changes I've been thinking of...
On 12 Oct 2009, at 23:21, Riccardo Mottola wrote: Hi, Germán Arias wrote: El lun, 12-10-2009 a las 19:33 +0200, Michael Thaler escribió: But so far my experiences weren't that great. I tried to create a project with project center. No icons are shown at all, so Project Center is not useable. Well with stable release (startup 0.23.0) ProjectCenter and Gorm are usable. I have many projects made with these. But you are using GNUstep from SVN, and of course there are bugs. They do work also from svn trunk I'm using them right now. NSX11HandleWindowDecoration = YES. But today I tested this with 0.23.0 startup, and does not work. Maybe it's a bug or my memory fails. it is GS* If you run systempreferences, you will find both the preference for letting X11 or GNUstep handle the windowmaker (the cited one) and also GSSuppressAppIcon which inhibits the cretion of the small application icons. You need then another tracker, on windows the taskbar works fine, the same goes for mwm. IN the long term you might want to extend GSUseWMTaskBar for your windowmanager perhaps? GNUstep has quite a lot of defaults for adjusting behavior (and we are not averse to adding more to control interaction with other non- gnustep software) such as how manus are drawn and whether app icons are shown. It seems to me that a lot of issues people have are with the fact that there are no native packages with themes/defaults set up to integrate GNUstep with the native look. Perhaps people who like a a particular look could record what they found out about how to achieve it so that people can see and download it from the website or wiki. You could have a screenshot (so people can see what it looks like), and a file containing the defaults settings to reproduce the appearance (and a theme bundle for the more ambitious works). People could then download the file and/or bundle, and could install for themselves. Really, it would be nice if people who like a particular look could provide that look for other people to enjoy. Going back to Greg's idea of improving the website ... it would be good to provide a repository for people to provide this sort of thing for view and download. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Window manager interaction
On 15 Oct 2009, at 21:34, Philippe Roussel wrote: Hi all, When using GNUstep applications under a Gnome desktop and it's Metacity window manager, I often 'lose' those applications : if I minimize a windows, it appears in the task bar as expected but if I hide the application there's nothing left in the task bar. The only solution seems to launch the application again to get it back. I'm running with GSAppOwnsMiniwindow set to NO and GSSuppressAppIcon set to YES as I don't want AppIcons to appear on the desktop. Is it the intended behavior ? Did I miss something ? The documentation says: GSSuppressAppIcon A boolean value, NO by default. Specifies wether the application icon window should not be displayed. Set to YES for background server applications. I think the expectation is that, if you have set GSSuppressAppIcon to YES, it's because your app is not intended to appear on-screen (I think that's what 'background server' means), or that your window manager will be handling activation of the app some other way. The other default (GSAppOwnsMiniwindow) is the one which is supposed to control whether miniwindows are controlled by the application or by the window manager, and if that's set to 'NO' then (as I understand it) the miniwindows should not appear on the desktop. I'm not sure how well this works though. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Debug info in debian/ubuntu gnustep-examples
On 21 Oct 2009, at 19:39, Fred Kiefer wrote: Eduardo Osorio Armenta schrieb: Hello GNUstep community I'm new to this list; First of all great environment/framework/ tools, KUDOS to all DEVs. I'm becoming a fan/user of WindowMaker/GNUstep in ubuntu 9.04 I hope you get me a little help/direction/url trying to get the debug symbols when compiling the examples from gnustep-examples source in ubuntu package after downloading the source of this package i compiled fine with make and run with openapp ApplicationName.app but trying to debug with gdb, it states that no debug info was know for every program so i research in gnustep wiki for a HowTo cook and found that the command make messages=yes That prints verbose output while bulding ... it doesn't build for debugging. What you want is ' make debug=yes produces this info, but this didn't worked for gnustep-examples programs only for a simple HelloWorld program (using Foundation NSLog, etc) As far as I know all GNUstep components get compiled with debug information enabled. Yes, but unless you do 'make debug=yes' they are also compiled with optimisation ... which makes it difficult to interpret the output of gdb reliably as the optimiser will change the exact control flow in the program (so the line displayed in gdb can jump about unpredictably) and will remove many variables (so gdb can't examine them). So for any code you intend to debug using gdb, you should build with 'make debug=yes' which turns off optimisation. The simplest way to start debuging a GNUstep application is via debugapp ApplicationName.app or openapp --debug ApplicationName.app which is what I prefer. Hope this helps Fred ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: GNUstep dev environment
On 8 Nov 2009, at 21:19, HalypH wrote: Hi all, I'm newbie in GNUstep (and in Objective-C). What is the best dev environment for GNUstep? I'm using text editor (Vim) and console build, plus 'insight' as gdb front-end. But it doesn't like fast development environment for me. I use vim in a terminal window for editing and I use gdb from the command line too. That's fast for me (I don't really like IDEs), though you can use an IDE such as ProjectCenter.app if that's your preference. I guess you would say that I'm a 'power user' (ie someone familiar with the tools), so a command line environment will probably always provide more control and flexibility than a gui environment IDE can. If you want to use GNUstep for GUI development, then I'd recommend using Gorm.app (to design/implement your gui). If you want to design/build themes, then you should use Thematic.app If you want to write server applications, then you don't need any special tools. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: GNUstep FOSDEM devroom request proposal
On 17 Nov 2009, at 01:16, Lars Sonchocky-Helldorf wrote: Hi, I am going to make the following request for a devroom at FOSDEM on thursday or friday. If you have any additional input or are member of a GNUstep related project which wants to join in please let me know. One point I'd like to add... While we would much prefer people to be physically present, we had some success last year with teleconferencing. If members of any project would like to participate by presenting a talk via skype or a similar teleconferencing system, I will commit to buying and bringing a sound system so that people beyond the first few rows can hear. Please let us know if this is the case either today or tomorrow, so that Lars can amend the request for a devroom accordingly. See http://mediawiki.gnustep.org/index.php/FOSDEM_2010 for links to general information. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: gnustep-base package tried to download dtd from the internet
On 22 Nov 2009, at 20:49, Jochen Schmitt wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, I'm the maintainer of the gnustep-base package in the Fedora distribution. Unfortunately, I have the following issue. When I try to make a make -C Documentation install the package tried to download the DTDs from the internet. This is not allowed in a build environment. So I now search a solution why I can refer to the DTDs without to install the DTDs to the final destination directory. It may be nice, if anyone can give me a hint. You need to install gnustep-base before you build the documentation, because the documentation is built using gnustep-base. However, you can install wherever you like ... if your build environment doesn't permit installation to the final destination, you can first install to an alternative location and use the GNUSTEP_CONFIG_FILE environment variable to point to a custom copy of the normal GNUstep.conf file (overriding the one provided by gnustep-make) which describes the location you actually installed to. Alternatively you could just copy the DTDs to a subdirectory named 'DTDs' and hack GNUstep.conf to point to the parent directory as the LIBRARY directory. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Launched applications
On 29 Nov 2009, at 01:33, Germán Arias wrote: Hi Richard Is there a way to get the apps launched?. I need this on GSTaskBar to remove the icons of apps killed. NSWorkspace have the method +launchedApplications, but this info isn't up to date. Then GSTaskBar can't work appropriately. Is there a way to get these through GNUstep?. Or I need use an external tool (like ps)? Greetings. The +launched Applications method should do a pretty good job. It's the way to get a list of launched applications via GNUstep. For your purposes (removing apps from a list) it should be up to date ... I don't know of a better way to get the information. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Arguments of +connectionWithRegisteredName:host:
On 1 Dec 2009, at 02:20, Germán Arias wrote:
Look this
http://www.gnustep.it/nicola/Tutorials/DistributedObjects/node7.html
In fact, this question born from this example. I discussed this with
Nicola, and he suggested talk this here.
The example dates from before the time Apple changed the API to use host-local
connections by default.
I don't think the documentation is wrong so much as a little unclear ...
If it is an asterisk ('*') then the nameserver checks all hosts on the local
subnet (unless the nameserver is one that only manages local ports)
That phrase 'unless the nameserver is one that only manages local ports' could
be interpreted more than one way.
So I added a line to explicitly state that the host name should be omitted if
the nameserver does not support remote hosts.
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: What is needed to run a tool like a daemon?
On 3 Dec 2009, at 06:35, Germán Arias wrote:
As you know I'm working on GSTaskBar. Until now I run GSTB from a
terminal. But when I try start this tool in my .profile file (where I
start gbps and gdnc) I can not start my session. The error occurs
because GSTB can't register with the name GSTaskBar.
I know of three reasons for failure to register a name:
1. the name is already registered to another connection.
2. the temporary files used for name registration have had their ownership or
access permissions changed so that your process can't access them.
3. the app is using inter-host connections, and the nameserver (gdomap) is not
running and can't be auto-started for some reason (eg access permissions).
4. the app is using inter-host connections, and gdomap has the name registered
to another process (A) which died without unregistering, and another process
(B) is running which happens to have the same process ID that A had (in this
case gdomap can't tell that the name is no longer in use by A, because it will
check the running process IDs and think that A is still running because it sees
a process with the ID its expecting).
I guess 3 and 4 should not be the case (your code sample shows you have not
chosen to use inter-host connections). Reason 2 would seem almost impossible
to happen without you knowing you had reprotected the files.
I need to delete
the file /tmp/.X0-lock and type: startx. This start my session. After
this, the process GSTB is running and work fine. Then, why I get this
error?
That sounds like you have some X issue, then ... nothing to do with registering
the name.
Basically I have something like
NSAutoreleasePool *pool;
GSTaskBar *gsbar;
NSConnection *conn;
pool = [NSAutoreleasePool new];
gsbar = [GSTaskBar new];
conn = [NSConnection defaultConnection];
[conn setRootObject: gsbar];
if (![conn registerName: @GSTaskBar])
{
NSLog (@Could not register us as GSTaskBar);
exit (1);
}
You can run with -GNU-Debug=NSMessagePort to get some debug output about
registering the name for the port.
If that's not helpful,probably you should try adding a load of NSLog statements
to your code (and in the libraries) to try to see what's going on.
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: What is needed to run a tool like a daemon?
On 3 Dec 2009, at 07:34, Saso Kiselkov wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
And what's stopping you from simply forking into the background? Like
with the following:
if (daemon (0, 0) == -1)
{
NSLog (@Error daemonizing: %s, strerror (errno));
exit (EXIT_FAILURE);
}
I don't think that addresses the issue of registering a name.
Perhaps more importantly though, the code above has the problem of 'daemon()'
being severely unportable.
In GNUstep you should use NSTask to portably create a subprocess.
The gdnc tool (base/Tools/gdnc.m) provides an example of a process which makes
itsself be a daemon in a portable manner.
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: What is needed to run a tool like a daemon?
On 3 Dec 2009, at 08:04, Saso Kiselkov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sure it's unportable, which is why I always include a custom implementation of daemon() with my code which works on most *nixes :-). Using NSTask works on ms-windows as well. Of course, you can implement your own daemon using NSTask. After reading the message though I realize I misunderstood it. What's most likely screwing up is that the process doesn't de-register from the name server. Maybe a simple atexit() or signal() handler would do the trick. That shouldn't really matter ... the nameserver code is designed to handle the case where something kills a process and prevents it from deregistering its name. German: you do try this as a test whether the name is being unregistered: Unfortunately testing that is not useful ... what needs to be determined is why the name can't be registered. Normally the directory to look at is /tmp/GNUstepXXX/NSMessagePort where XXX is your user ID There is a subdirectory 'names' containing files for registered names ... the name of each file is a base64 encoded port name. The content of each file is the port identifier. There is a subdirectory 'ports' containing named pipes for each port. The port names are of the port pid.sequence where pid is a process id and sequence is a sequence number for when a process uses multiple ports. For registration to fail, the name file must point to a port file which has a process listening on it (ie the port must still be in use). ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Newbie on docsetutil
On 19 Dec 2009, at 08:48, va...@telecom.ece.ntua.gr va...@telecom.ece.ntua.gr wrote: Hi, I downloaded cocoa.vim and I ws browsing through the scripts (I am not expert). I noticed that it could be modified to contain the gnustep keywords, but the most intriguing part was the fact that it mentions a tool docsetutil for documentation. I searched a bit and I found that it is Apple only (maybe I am mistken). Is there much a functionality for gnustep? what documentation tool is used? Does it have the features of docsetutil? can it be used in the similar manner? I am personally interested to improve the cocoa.vim for GNUStep,. Am I duplicating work? I don';t know docsetutil, so I can't really answer most of your query, but gnustep uses autogsdoc which extracts information from source files, generates xml documentation, handles indexing and cross references, and produces html docmentation from the intermediate xml. The autogsdoc tool (and it's documentation) is included with the gnustep-base library. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: GNUstep build problem
On 8 Jan 2010, at 11:25, Andreas Höschler wrote: Hi all, since all my attempts to get GNUstep to work with my gcc 4.2.3 I am considering to retry from scratch even with another gcc version. Can anyone recommend a gcc version that is known to cause the least problems with the latest GNUstep tree? I think it's about a year since I last built on sol10 (so we certainly aren't talking about the latest GNUstep code here), but the compiler I have on the system is as follows: Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: ../configure --with-as=/usr/sfw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,objc --prefix=/home/cls/GNUstep/usr/local --with-pic Thread model: posix gcc version 4.1.1 ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: FOSDEM and beyond (next stable release of base)
On 9 Feb 2010, at 22:51, Riccardo Mottola wrote: In this release, move to compatibility with the Apple objc runtime as much as possible. What does this mean? are we going to require libobjc2 ?? I meant that we should use the libobjc2 API as our 'standard' going forward so that, rather than having wrapper functions to convert all runtime functions and data structures to our own version, we use the libobjc2 API directly where possible, and use wrappers to convert other runtime APIs to the libobjc2 version. This would make it possible to port future Cocoa code to GNUstep with less effort. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: FOSDEM and beyond (next stable release of base)
On 14 Feb 2010, at 15:14, ici...@mail.cg.tuwien.ac.at wrote: Hi! Today's trunk does not build anymore on my machine. I noticed Richard merged his reorg branch into trunk. I get a lot of Warning: objc/runtime.h: No such file or directory. Configure is checking for objc/objc.h and objc/runtime.h, and correctly determines that the latter one is not there. I am using gcc 4.2.4 with the GCC runtime. Do I have to switch to David's libobjc2 runtime? Sorry, I forgot that *all* the machines I am testing on have the new runtime installed. Just applied a couple of fixes which should cause the runtime stuff to continue to work with the old runtime. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Help Files
On 17 Feb 2010, at 09:35, J. Jordan wrote: Where do Help files (bundles) belong? I assume in xxx.app/Resources but I cannot find that in writing anywhere (and I did look for it). I am not refering to man pages or info pages, I am refering to xxx.help as used by HelpViewer.app thanks, I'm not familiar with HelpViewer.app, but I do know how standard application help works (though IIRC ProjectCenter.app helps you set up help files and puts them in the right place for you, so you generally don't need to know). Help files normally have a .rtf or .rtfd extension (not '.help') and are stored in the Resources subdirectory. The built-in help viewer handles rtf help files, and no external app is needed in that case. Your application's AppNameInfo.plist file (where 'AppName' is the name of your application) usually has an entry of the form: GSHelpContentsFile = AppNameHelp.rtf; Which tells the system what the default help file for the application is called (AppNameHelp.rtf could be any file name you choose). ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
