Re: Emacs cannot dump on GNUstep
Hi, The previous email is about this problem of Emacs.app not working when dumped under GNUstep. Since I cannot work on this myself at the moment (and failed when I *did* put time into it before), let me provide the background of what I know. What happens is this: emacs loads into memory, then performs a bunch of initialization (mainly reading/interpreting elisp files), then dumps its in-memory executable +data image out to disk. In the future, this becomes the new executable, the idea being that you then are up and running without having to perform the initialization. Something in this causes a failure under GNUstep (trace below). I'm not sure if it's a problem with the emacs dump code or with initialization in the GNUstep runtime, but I think there is some more that can be tried on the emacs side codewise, though it would be best done by someone acquainted with GNUstep memory handling. The thing to look at is the difference between unexmacosx.c and, e.g., unexelf.c. It seems that some special handling for memory allocation may be needed. In unexmacosx, we read in the comments: The Mac OS X implementation of unexec makes use of Darwin's `zone' memory allocator. All calls to malloc, realloc, and free in Emacs are redirected to unexec_malloc, unexec_realloc, and unexec_free in this file. When temacs is run, all memory requests are handled in the zone EmacsZone. The Darwin memory allocator library calls maintain the data structures to manage this zone. Dumping writes its contents to data segments of the executable file. When emacs is run, the loader recreates the contents of the zone in memory. However since the initialization routine of the zone memory allocator is run again, this `zone' can no longer be used as a heap. That is why emacs uses the ordinary malloc system call to allocate memory. Also, when a block of memory needs to be reallocated and the new size is larger than the old one, a new block must be obtained by malloc and the old contents copied to it. It is possible that adding this sort of logic to unexelf will solve the problem. Note there are also some #defines in darwin.h that would need to be replicated in gnu-linux.h or whatever system is being compiled on. Because emacs plays a number of games with malloc on different systems (search for Doug Leah in the code and configure scripts) there may be more to be done than straight copy-paste. If there is still a failure after this is tried, there may be a gnu- apple difference in the runtime or how the foundation library initializes. But we can't be sure about this until unexelf under GNUstep does everything that unexmacosx does. -Adrian ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Fwd: emacs.app does not support -GSFilePath
Hello, Someone was asking me about whether Emacs.app supports the - GSFilePath option which GWorkspace uses to tell applications to open files. I thought that there were already two ways to do this in OpenStep / Cocoa: -NSOpen option, and NSApplication- application:openFIle: method via DO or notifications. Is this correct or is the GNUstep-specific -GSFilePath really needed? thanks, Adrian ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep subversion statistics
On Jan 15, 2007, at 11:20 PM, Andrew Ruder wrote: On Mon, Jan 15, 2007 at 11:42:12AM -0500, Adrian Robert wrote: I was browsing freshmeat.net earlier tonight and came across a package called 'svnstat.' Since I keep local mirrors of all the gnustep stuff (with svk), I generated some statistics of some gnustep stuff. It is pretty neat to look through. Interesting.. any idea how it determines lines of code metrics? Unlike CVS, this info isn't in the SVN logs. I spent a while on the mailing lists asking about adding it, but none of the active developers believed in the value of the metric and I was lazy at the time so... You mean how many lines changed per revision? or ... ? In that case it is just svn diff -r n-1:n svnurl-or-checked-out-file-or-directory | diffstat or did you mean something else?= Thanks, that's what I meant.. ok, so the manual approach. ;-/ I can see why a local copy would be helpful / required for running svnstat then.. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep subversion statistics
On Jan 15, 2007, at 12:09 AM, Andrew Ruder wrote: Hey all, I was browsing freshmeat.net earlier tonight and came across a package called 'svnstat.' Since I keep local mirrors of all the gnustep stuff (with svk), I generated some statistics of some gnustep stuff. It is pretty neat to look through. Interesting.. any idea how it determines lines of code metrics? Unlike CVS, this info isn't in the SVN logs. I spent a while on the mailing lists asking about adding it, but none of the active developers believed in the value of the metric and I was lazy at the time so... ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Plans for change....
On Dec 18, 2006, at 11:46 AM, Hubert Chan wrote: Gregory John Casamento wrote: [...] I, personally, don't see much value in auto-layout, because GNUstep/OPENSTEP provides the user with a way to have a GUI for each locale, so that you can specifically tailor your GUI to each, but to each his own. Well, it's not just about localization. If you change fonts, it may break the layout as well. It's hard to fully cater to Linux/X-Windows everything-configurable mentality using a system designed for use with specified fonts present on every system (NeXTstep, Mac OS X). Giving up this configurability may be best for compatibility with Cocoa apps and that style of development (WYSIWUG from IB/Gorm to user desktop). If a single X backend becomes standard, we could bundle a sans-serif font with it that is ALWAYS used for dialogs, etc., as Lucida Grande on Mac OS (and Ohlfs on NeXT/OpenStep). This would work for Latin text, at least, and we might be able to use Deja Vu or something like that for non-Latin. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: XPM support for NSImage
On Nov 7, 2006, at 5:13 PM, Hubert Chan wrote: Hi everyone, Is there any interest in including my XPM NSImage support into GNUstep GUI? If so, I will sign the copyright form, and rework it as a patch against GNUstep GUI, rather than as a standalone class. If not, I'll probably get it into Etoile. I for one would be very interested to have it in there (but it's not my decision to make). The more supported image formats, the better. It depends on libXpm, which is included in X11, or available from http://koala.ilog.fr/lehors/xpm.html. I'm not using any of the X11-specific functions from that library. This may bother some people, especially those trying to deploy on Windows. There is an alternative you might consider, which is to use code included in GNU Emacs (image.c) for XPM support (originally written for the Mac Carbon port by Yamamoto Mitsuharu). See http:// lists.gnu.org/archive/html/emacs-devel/2004-04/msg00780.html ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Another thought about GNUSTEP_INSTALLATION_DOMAIN
On Oct 13, 2006, at 5:09 AM, Richard Frith-Macdonald wrote: On 13 Oct 2006, at 09:32, Richard Frith-Macdonald wrote: It occurs to me that NSSearchPathForDirectoriesInDomains() has a mask of domains as the second argument. That means that code looking for resources is expected to know which domain it should be finding them in ... rather than just looking in all domains. So there is an inbuilt assumption supported by the API that certain packages are installed in certain domains. We could go through all code and make sure that whenever NSSearchPathForDirectoriesInDomains() is used, its second argument is the mask of all domains ... so that it should work wherever packages are installed. The downsides of that are ... 1. we don't control all the code using that function 2. it may not be a good idea to load some resources from some domains (eg security) However, we could just say 1. it's the programmers fault if they depend on a resource in a particular location, and well written code should cope 2. security issues should be addressed independently anyway But if we do that I think we need to document it very clearly. Searching through the base library I see that it currently expects to find the SSL bundle, the gdomap nameserver executable, the gdnc notifcation server executable and system documentation projects in the System domain. So, as it currently stands, gnustep-base would *mostly* work if installed in a non-System domain, but not entirely. I'm getting a bit confused trying to follow this thread. I thought the original desire was simply to allow GNUstep libs in locations like /usr/lib and resources in /usr/share, etc.. The use of the term GNUSTEP_INSTALLATION_DOMAIN confused the issue by being unclear about whether GNUstep's internal map (System, Local, User domains) or the external situation on Unix installations (/usr, /opt, etc.) was referred to. So please pardon me if the next paragraph is off (hopefully not). IMHO GNUstep is already beyond the point where changes that significantly affect what is seen internally by GNUstep programs should be considered. Base is post-1.0, and there are a lot of applications out there. If you want to tweak where GNUstep resources are installed on the host filesystem, that is one thing. Making internal changes that enhance code compatibility with OS X is worth consideration as well, but suddenly requiring programs to search everywhere for what were formerly system resources, simply to make installation cleaner on one type of deployment platform (that not everyone thinks is the most important in the long run for GNUstep) is a bad thing. It was difficult enough adapting to the round of changes when GNUstep.conf was introduced, and I daresay there is still confusion amongst app developers as to the respective roles of GNUstep.conf and GNUstep.[c]sh. While the benefits of FHS installation are nonzero, the amount of initial disruption and any possible divergence in OS X compatibility should be carefully considered. Also, I suggest that an explicit policy for what goes in System domain for GNUstep be developed, following as closely as possible what OS X does. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
gnustep_base_user_main() question
Hi, I'm getting a linking error that I'm trying to track down: /usr/local/GNUstep/System/Library/Libraries/libgnustep-base.so: undefined reference to `gnustep_base_user_main' I find that gnustep_base_user_main() is *called* in NSProcessInfo.m, and sometimes when running in a debugger I've seen that the main() function in user code is somehow automagically mapped to this name. Since it seems like that is NOT happening in my case, I was wondering, HOW is this supposed to be done? I'm not really an expert on the ins and outs of .o and executable file formats, loading, linking, and running, so a simple explanation would be appreciated. ;) Thanks. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep_base_user_main() question
On Sep 8, 2006, at 11:33 AM, Jeremy Bettis wrote: Adrian Robert wrote: Hi, I'm getting a linking error that I'm trying to track down: /usr/local/GNUstep/System/Library/Libraries/libgnustep-base.so: undefined reference to `gnustep_base_user_main' I find that gnustep_base_user_main() is *called* in NSProcessInfo.m, and sometimes when running in a debugger I've seen that the main() function in user code is somehow automagically mapped to this name. Since it seems like that is NOT happening in my case, I was wondering, HOW is this supposed to be done? I'm not really an expert on the ins and outs of .o and executable file formats, loading, linking, and running, so a simple explanation would be appreciated. ;) It varies by platform. If your platform doesn't have any better support for getting the arguments and env vars, then NSProcessInfo.h #define's main to gnustep_base_user_main. main is declared in NSProcessInfo.m (or nearby) and it calls your real main (gnustep_base_user_main). It's messy and icky, and if your platform has a better way of dealing with it, then it should be implemented. As far as I know there are special cases for Linux (all glibc platforms maybe?), Solaris, Win32 that do not #define main, but use some os specific hacks to get the argument list. Thanks, that explains everything. (I had missed the #define occurs in GSConfig.h..) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Nib compatibility progress
On May 12, 2006, at 12:14 AM, Gregory John Casamento wrote: All, I just wanted to post some screenshots here of progress thusfar on nib compatibility efforts. Here is a gui done in IB, the GNUstep one is running in a live app and the Cocoa one is in IB. Hi Gregory, This is indeed looking pretty good -- aside from some layout spacing issues mainly on the right, almost perfect in fact. Are connections working as well? Also, just out of curiosity, what is that terminal application running in the background on the GNUstep shot? It looks like a GNUstep app, but as far as I recall Terminal.app was not able to display a white background? Anyway, great stuff! Adrian ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: google summer of code
On Apr 19, 2006, at 9:23 AM, Nicolas Roard wrote: On 4/17/06, Nicolas Roard [EMAIL PROTECTED] wrote: On 4/17/06, Adam Fedor [EMAIL PROTECTED] wrote: I'd think it's a nice idea. Is anyone willing to be a mentor, or at least put together a list of potential projects? I started a wiki page: http://mediawiki.gnustep.org/index.php/Summer_Of_Code_2006 If we want to participate (I wouldn't mind participating as a student for instance, and I know others are interested too), we should send google a mail soon I think.. (considering the growing list of organizations..) Since GNU is already on the org list, we just need to provide mentors and project ideas, is that right? This would probably need to be cleared through RMS or whomever is the point-man for the GNU organization's application. The deadline for mentors is May 1. The list of ideas on the wiki looks pretty good, though some are less well-defined. The clearest-cut appear to be: - printing support - finish Cairo [it would be nice if completing unfinished aspects of Xlib and Art backends could be included here] - WebCore - Bindings / KVO I would add: - .nib compatibility 'Windows support' might be able to be refined to some good projects as well. I wish there were some way to put together a general finish GUI project, though most likely that is more a hodge-podge of miscellaneous tasks than something suitable for a student project. Another source of projects is applications: - ProjectCenter (if Serg were willing to mentor) - the PDFKit and viewer - completing / polishing the various image viewer projects - finish Emacs.app (what do people think of this.. is it central enough to GNU/GNUstep)? - refactor Emacs.app code to make emacs editor panel widget ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: SVN access
On Jan 12, 2006, at 10:34 AM, Adam Fedor wrote: I you have developer accounts at savannah.gnu.org, please register at gna.org as well and request access to the GNUstep project (at gna.org) so I can add you to the developer list there. Thanks. I hope to migrate GNUstep to SVN within a few weeks, but I'm not sure of the exact timing. Does anyone else get messages from their browser about a self-signed certificate when accessing gna.org? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: ANN: Emacs.app 9.0-pre1
On Nov 8, 2005, at 10:29 AM, Nicola Pero wrote: Oops, I'm sorry, I meant to NOT cc gnustep-dev on that message, but send a separate one, or look into it myself first. But now that I've sent it... the question I wanted to ask is whether there is some way to recover the old gnustep environment variable settings from a shell script, or is it necessary to drop into Perl or C and parse the conf file? You can source GNUstep.sh :-) ... GNUstep.sh will still be there, and will remain there and be fully supported (and it is integrated in the new config system, so it's reading the config from GNUstep.conf for you!). Hmm, but how do you find GNUstep.sh w/o an env var being set? I guess you need to have at least the GNUSTEP_MAKEFILES var set already as mentioned a couple of weeks ago on the list.. However, I looked at GNUstep.conf on my system and it looks like that is in a form that can just be sourced. So assuming /etc/GNUstep is the location of this file in most cases on unix, this is a partial solution.. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: ANN: Emacs.app 9.0-pre1
On Nov 8, 2005, at 1:54 AM, Sun Yijiang wrote: I can now get temacs and emacs built in src, after some work: 1) setup env variables: export GNUSTEP_SYSTEM_ROOT=/usr/GNUstep/System export GNUSTEP_MAKEFILES=$GNUSTEP_SYSTEM_ROOT/Library/Makefiles export CPATH=$GNUSTEP_SYSTEM_ROOT/Library/Headers:$CPATH export LD_LIBRARY_PATH=/usr/GNUstep/System/Library/Libraries: $LD_LIBRARY_PATH I think this relates to gnustep's recent config change to stop using environment variables. I'll look into it.. 2) modify src/Makefile.in: +#define GNUSTEP #define THIS_IS_MAKEFILE #define NO_SHORTNAMES than configure and build: # ./configure --prefix=xxx --with-ns --without-x # make I think it's better to define `GNUSTEP' in ./configure process. Not sure if this is causing your particular segfault, but make sure you add -DCANNOT_DUMP to C/CPPFLAGS (see nextstep/compile). And GNUSTEP _should_ be being defined if you use the compile script. (But probably in the long run GNUSTEP / COCOA should be defined in the appropriate place in configure.in as you say.) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: ANN: Emacs.app 9.0-pre1
On Nov 8, 2005, at 7:05 AM, Adrian Robert wrote: On Nov 8, 2005, at 1:54 AM, Sun Yijiang wrote: I can now get temacs and emacs built in src, after some work: 1) setup env variables: export GNUSTEP_SYSTEM_ROOT=/usr/GNUstep/System export GNUSTEP_MAKEFILES=$GNUSTEP_SYSTEM_ROOT/Library/Makefiles export CPATH=$GNUSTEP_SYSTEM_ROOT/Library/Headers:$CPATH export LD_LIBRARY_PATH=/usr/GNUstep/System/Library/Libraries: $LD_LIBRARY_PATH I think this relates to gnustep's recent config change to stop using environment variables. I'll look into it.. Oops, I'm sorry, I meant to NOT cc gnustep-dev on that message, but send a separate one, or look into it myself first. But now that I've sent it... the question I wanted to ask is whether there is some way to recover the old gnustep environment variable settings from a shell script, or is it necessary to drop into Perl or C and parse the conf file? thanks. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: ANN: Emacs.app 9.0-pre1
On Nov 8, 2005, at 11:57 AM, Fabien VALLON wrote: On Mar 8 novembre 2005 17:05, Sun Yijiang wrote: Yes, -DCANNOT_DUMP solves the segfault problem, I can now make install : /home/sun/sandbox/emacs-23.0.0_NS-9.0pre1/nextstep/build/Emacs.app/ Resources 2005-11-08 23:56:16.000 Emacs[13820] NSApplication.m:203 Assertion failed in initialize_gnustep_backend. Unable to find backend libgnustep- back.bundle ./Emacs: Uncaught exception NSInternalInconsistencyException, reason: NSApplication.m:203 Assertion failed in initialize_gnustep_backend. Unable to find backend libgnustep-back.bundle It seems there's something wrong with my GNUStep env, maybe the backend part. I'm new to GNUStep, what's that mean? and what should I do? Yes Jeff Teunissen and I had the same problem. After straced it, it looks like that the app seeach the backend in wrong paths. Maybye introduced here : 2005-07-17 * Source/NSApplication.m (gnustep_backend_path, gnustep_backend_framework, gnustep_backend_bundle): New functions. (initialize_gnustep_backend): Support versioning of backend bundle. [Removing emacs-devel cc to avoid spamming them w/gnustep-specific issues.. ;-] You mean you get this with all gnustep apps or just Emacs? Adrian ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSavePanel doc [OpenStep release]
On Nov 7, 2005, at 11:09 AM, Fabien VALLON wrote: In attachment : NSSavePanel doc improvements Hi, I will look in detail later, but are these doc improvements additions to the GSdoc, or internal comments on the implementation, or updates to the documentation of which standards each method is conforming to? (Or more than one of the above?) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: why do we need change?
On Oct 25, 2005, at 7:28 AM, Dennis Leeuw wrote: To get to 1.0 I think a roadmap is needed. Looking at: http://savannah.gnu.org/task/?group_id=99 Maybe someone should define which one of those tasks needs to be completed before GNUstep can be 1.0. And those points should be made more visible on the website, as to get peoples attention. All other stuff should be done in a post 1.0 branch or even not excepted, until after the 1.0 release. But who is going to take the lead to create a list of things to be done before we can claim 1.0. And a bigger hurdle for the GNUstep community how are we going to agree on it. Many of those discussions tend to go no where on the GNUstep lists. I suggest that one person (or a very small group) decides what needs to be done and setup a rough timeframe in which they would like it to be accomplished. Despite having our current bug and task lists, I agree that a clear list of prioritized tasks for 1.0, 1.x, and perhaps 2.0 is warranted. I kind of like that task list as opposed to using the wiki for this, assuming we can easily mark tasks on it by targeted release (as in 1.0, 1.1, 2.0, etc.), and set the coloration of the list display can be set to match that. On the other hand, as of now it looks like this is not so easy, as everything seems to be keyed to dates and/or priorities (which are just semantically-empty numbers). Not sure if this is configurable. Also, there is the question of how to separate out core vs. no-core priorities. Right now there is a hodgepodge of tasks ranging from core library work to GDL2 to Gorm, Jigs, and demo writing. Not that these tasks shouldn't be listed somewhere, but if we can only display colors and/or sort by one characteristic, the utility of the list for aiding the reaching of 1.0 is hindered. So, maybe it's simpler to just use the wiki? In any case, from time to time in going through the code I know I've noticed a few things in GUI and Back (and one or two in Foundation) that need doing. Once we decide on the medium, I'll try to find some time go through the places I remember and list them.. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep moving forward
On Oct 24, 2005, at 5:08 AM, Sašo Kiselkov wrote: Quoting Gregory John Casamento [EMAIL PROTECTED]: Although we have Gorm and ProjectCenter, I believe we do need more to make GNUstep attractive to devs. Some debugging (think MallocDebug) tools and other things might be nice in this regard. Also, a fully working ProjectCenter would be good as well. Hi, Currently I'm working 100% on http://student.fiit.stuba.sk/~kiselkov04/ProjectManager - an new IDE completely from scratch. It currently still lacks many features, but what is done: Why not help out on ProjectCenter? Instead of having two halfway-useful IDE's, maybe we could have one powerful one.. Specific comments below.. - bundle extensible project type Project Center has this. - allows for arbitrary file layout (through grouping files in abstract `categories' (sort-of like directories, but not really on disk)) Project Center could use this. XCode has it, so users that also develop on Apple will grok it (and indeed, would like it). - build error interpretation - errors are grouped in a table, double click on a row and the error file opens, highlighting the error line. XCode (and I think ProjectBuilder) had this. It would be nice to enhance ProjectCenter to have it too. - fully functional code editor (except for colouring... but I'm working on it) + line/character indication and Go To Line... + autoindentation + customizable external command output piping + customizable tab to space conversion You can try writing an editor from scratch, but unless you pump a LOT of time into it you'll end up with something that someone will shift away from once they have some real work to do. Project Center has Emacs integration via gnuclient, and in my opinion this is the most sensible way to go. Add Vim integration or your other favorite editor, improve the richness of the interface between IDE and editor, etc.. I talked to the maintainer of ProjectCenter about this a year and a half ago, and he had some ideas to move forward, but neither of us got the time to do it. If you are still insistent on this, take a look at http://www.nongnu.org/codeeditor/ , or TextEdit here: http://www.nongnu.org/backbone/apps.html . Both would be good starting points. Alternatively, an idea I had was to bundle http://emacs-on-aqua.sf.net into a framework so you could have an emacs pane wherever you needed an editor panel. This would be a bit of work, but a whole lot less than writing your own editor, and the result would be truly excellent. (Also, I think the emacs-20-based emacs-on-aqua is a good base, lighter-weight than the upcoming emacs-23-based port -- http://emacs-app.sf.net.) Comments are welcome, though please still consider the code practically a tech-demo, I would not have released it for another two weeks (currently working on it about two weeks already) if this discussion would not have come up. I strongly encourage you to think about working on Project Center. Much of the grunt work that you'll have to redo is already done, it has a nice clean interface so far, with plenty of scope for extension, and it's design is fundamentally familiar to Apple developers, so more widespread adoption is likely. If you still want to explore making your own IDE for a while, please at least consider integrating some of your code into ProjectCenter at some point. thanks, Adrian ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep bounty
Speaking of financial incentives, what ever happened to the paid icons project that started up last year? Could someone from the UI list who might be listening update us developers on that status? thanks. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: pl2link not found when doing sudo make install
On Aug 24, 2005, at 9:31 AM, Frederico Muñoz wrote: Yes, I'm doing the same, but this problem appeared due to the need of autobuilding Installer using a predifined set of methods that use make sudo make install. I think that the pl2link invocation can indeed by done in make, since all I see it do is creating a .desktop file in the application bundle. There is no need to be root for that. I'll try to change application.make and other relevant files to see if I can move pl2link somewhere else, since I think that sudo make install should work out of the box. Seems like if gnustep-make running under sudo is able to get in touch with the appropriate environment variables to actually install things to the right places (/usr/GNUstep vs. /usr/lib/GNUstep, etc.), it ought to be able to use these to specify full paths to gnustep- specific tool commands like pl2link. (E.g., $GNUSTEP_SYSTEM_ROOT/ Tools/pl2link or something like that..) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/back ChangeLog Source/art/ftfont.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Adrian Robert [EMAIL PROTECTED] 05/08/16 04:02:50 Modified files: core/back : ChangeLog core/back/Source/art: ftfont.m Log message: initialize deltas index in drawString method CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/ChangeLog.diff?tr1=1.384tr2=1.385r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/art/ftfont.m.diff?tr1=1.46tr2=1.47r1=textr2=text
Re: NSJavaVirtualMachine
On Jul 25, 2005, at 3:03 AM, [EMAIL PROTECTED] wrote: Hi, i am new here and start to learn to work with the gnustep. My first question is, is their NSJavaVirtualMachine in gnustep, like in cocoa, to use java classes in the project? I don't believe we have that class. However, do a search for LuceneKit. This is a GNUstep project that incorporates Java code, and so it is accomplishing the same job. (If NSJavaVirtualMachine is an official OS X API, maybe that would be a good route for us to generalize whatever LuceneKit does so other projects can wrap Java libraries more easily..) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSJavaVirtualMachine
On Jul 25, 2005, at 10:07 AM, Adrian Robert wrote: On Jul 25, 2005, at 3:03 AM, [EMAIL PROTECTED] wrote: Hi, i am new here and start to learn to work with the gnustep. My first question is, is their NSJavaVirtualMachine in gnustep, like in cocoa, to use java classes in the project? I don't believe we have that class. However, do a search for LuceneKit. This is a GNUstep project that incorporates Java code, and so it is accomplishing the same job. Scratch that. JIGS (Java interface for GNUstep -- http://www.gnustep.it/jigs/) has an implementation of NSJavaVirtualMachine. I'm not sure whether the API is the same as Apple's (which I've never used and am having difficulty finding documentation on), or whether all of Apple's various NSJavaXXX() functions are implemented. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: isEqual: and hash in NSDate
On Jul 21, 2005, at 3:49 PM, Jeremy Bettis wrote:
I have a problem with the implementations of isEqual: and hash in
NSDate.
Let's say we have two dates:
NSDate *a, *b;
// This is actually a common case if you are doing floating point math
to generate dates and get small rounding errors.
a = [NSDate dateWithTimeIntervalSinceReferenceDate:10.001];
b = [NSDate dateWithTimeIntervalSinceReferenceDate:9.998];
printf(a = %d, b=%d, equal=%d\n, [a hash] , [b hash], [a isEqual:b]);
// this code will print a = 10, b = 9, equal = 1
This breaks the NSDictionary rule that hash of two objects must equal
if they are -isEqual:.
I propose that we change the implementations to this:
- (unsigned) hash
{
return (unsigned)([self timeIntervalSinceReferenceDate]+0.5);
}
- (BOOL) isEqual: (id)other
{
if (other == nil)
return NO;
if ([other isKindOfClass: abstractClass]
(int)(otherTime(self)+0.5) == (int)(otherTime(other)+0.5) )
return YES;
return NO;
}
After my change the program's output changes to:
a = 10, b = 10, equal = 1
I realize that the dates 100.5 and 100.49 are now not -isEqual:, but
you have to draw the line somewhere, and putting it at .000 as the old
code was worse.
This really seems like a hack (not that it's any worse than the current
state :). Couldn't the implementations of -hash and -isEqual be
aligned without this loss of information? E.g. something like
[warning, sloppy first-attempt code here]:
-isEqual:other
return abs(selfVal - other-selfVal) epsilon;
-hash
return selfVal / epsilon;
(or maybe (selfVal + epsilon/2.0) / epsilon)
I think the problem with this is the division in -hash would need to be
carried out at a higher precision than the floating point
representation of selfVal uses. But maybe this could be worked around
or lived with somehow? E.g., if we used 8-byte floating point, epsilon
was 0.001 (1 msec) and we were willing to accept inaccuracy for dates
beyond 10 AD, would it work then? Unfortunately my numerical
computation class was WAY too long ago..
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI/back changes in CVS
On Jul 8, 2005, at 8:17 PM, Fred Kiefer wrote: I just added changes to GUI and back that will in the end allow pattern images for GNUstep and the new MacOSX composite operator that uses an addtional alpha value. I wanted these changes to go into the next release as this will break binary compatibility between GUI and back. I have tested this change with xlib. It would be great, if somebody could test it before the release with art and winlib. Is there an easy way to test it? Is there something in the new test suite that exercises this facility? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSSavePanel.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Adrian Robert [EMAIL PROTECTED] 05/07/10 02:48:02 Modified files: core/gui : ChangeLog core/gui/Source: NSSavePanel.m Log message: In NSSavePanel-ok:, determine user-entered filename before passing it to delegate filter userEnteredFilename. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2548tr2=1.2549r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSSavePanel.m.diff?tr1=1.85tr2=1.86r1=textr2=text
Re: Considering Gorm 1.0.0
On Jul 4, 2005, at 6:03 PM, Gregory John Casamento wrote: Adrian, Wow, definitely a response exceeding all expectations! Glad to hear there was a lot of low-hanging fruit. Just a couple of last comments below: --- Adrian Robert [EMAIL PROTECTED] wrote: - Add the horizontal and vertical divider bars to a palette somewhere. I see these on other gorms, but I haven't found how to make one myself. These lines are just NSBox where the title is removed and the height or width has been reduced to 1 or 2 pixels. I see now. It's not easy to do this by dragging, but the Size inspector works. It still might be worth putting them on a palette (as IB does) at some point, though not needed. - Ability to set up radio buttons. There are radio buttons displayed in the palette, but in IB when you drag you get a set of two or more bound together in an NSMatrix, which allows you to access the selection state in code. In Gorm, dragging gives just a single radio button and no matrix. I was able to copy a matrix from another .gorm file, but I could not figure out how to create one myself. Also, once I got the matrix, I could not change its layout. You need to use Right-Alt, or Shift-Right-Alt on some keyboards, to make this work. Hmm.. So for the radio buttons in the palette, Alt-drag means, in effect, drag entire group whereas plain drag means drag group member? Would it be more intuitive to reverse these, or is this following a convention of some kind? -Adrian ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
gnustep_base_user_main() question
Hi all, I've been trying to compile a gnustep app on NetBSD but keep getting a linker error: /usr/GNUstep/System/Library/Libraries/libgnustep-base.so: undefined reference to `gnustep_base_user_main' From some googling, I found there used to be a header file 'fake-main.h', that did something like #define main gnustep_base_user_main which allowed an internal main() for the base lib to be called and skim off GS-specific arguments from the command line, before passing execution to the original 'main()'. Now this header is gone, but the strategy is still used somehow but only on some platforms. In particular, it seems like Linux does not use it (evidently getting proc info from the system) but NetBSD does. My question: is there any way short of #include NSObject.h in my file with main() to satisfy things on a fake-main-using system? I'm having trouble tracing out what happens when fake-main is enabled in the config, and the references to 'gnustep_base_user_main' in the code are quite limited. Ideally, I would like to just manually put whatever #define is necessary in my main() file because including any Objective-C headers is not an easy option. thanks for any clues.. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep_base_user_main() question
On Jul 5, 2005, at 10:34 PM, Adam Fedor wrote: On Jul 5, 2005, at 9:34 PM, Adrian Robert wrote: Now this header is gone, but the strategy is still used somehow but only on some platforms. In particular, it seems like Linux does not use it (evidently getting proc info from the system) but NetBSD does. My question: is there any way short of #include NSObject.h in my file with main() to satisfy things on a fake-main-using system? I'm having trouble tracing out what happens when fake-main is enabled in the config, and the references to 'gnustep_base_user_main' in the code are quite limited. Ideally, I would like to just manually put whatever #define is necessary in my main() file because including any Objective-C headers is not an easy option. You can read the section 'Reading Command-Line Arguments' in the INSTALL file in gnustep-base OK, yes I should RTFM, or RTFC in this case.. After some more hunting I found a ChangeLog entry saying Remove fake-main.h include - use GSConfig.h, and then found GSConfig.h.in -- which had escaped my initial grep, but had the relevant #define in it. Problem solved, sorry for any bother.. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/gui ChangeLog Headers/AppKit/NSApp...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Adrian Robert [EMAIL PROTECTED] 05/06/06 04:05:05 Modified files: core/gui : ChangeLog core/gui/Headers/AppKit: NSApplication.h NSEvent.h core/gui/Source: GSServicesManager.m NSApplication.m NSFont.m Log message: filled in various gsdoc CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2535tr2=1.2536r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Headers/AppKit/NSApplication.h.diff?tr1=1.5tr2=1.6r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Headers/AppKit/NSEvent.h.diff?tr1=1.3tr2=1.4r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/GSServicesManager.m.diff?tr1=1.59tr2=1.60r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSApplication.m.diff?tr1=1.279tr2=1.280r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSFont.m.diff?tr1=1.82tr2=1.83r1=textr2=text
Re: Building in a separate directory
On May 27, 2005, at 9:34 AM, David Lázaro Saz wrote: On 27/05/2005, at 13:54, Nicola Pero wrote: The make syntax uses spaces to separate filenames in list of targets or requisites, or everywhere really ... it's a basic design decision in the make syntax. Thanks for the explanation. This also explains why Apple developed a completely new build system for Xcode (xcodebuild). I've tried compiling a Hello World/Hello World.c in my usual (separate) build directory and everything worked. BTW, first they moved to JAM, then they internalized JAM's code into Xcode so it's not invoked as a separate process. It's possible that JAM is able to handle spaces, though maybe Apple had to modify it for this. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] gnustep/core/back Headers/xlib/XGGState.h Sourc...
On May 19, 2005, at 7:37 AM, Fred Kiefer wrote: Adrian Robert wrote: CVSROOT: /cvsroot/gnustep Module name: gnustep Branch: Changes by: Adrian Robert [EMAIL PROTECTED] 05/05/12 13:41:58 Modified files: core/back/Headers/xlib: XGGState.h core/back/Source/xlib: XGGState.m GSXftFontInfo.m Log message: cache Xft draw state in XGGState and use this to speed glyph rendering in GSXftFontInfo There seems to be a small problem with these XFT support changes. The auto-configuration has a couple of XFT related setting, the ones of interest here are HAVE_XFT and HAVE_LIBXFT. Now the new code uses the later to flag areas which should only be included if XFT is present. But this seems to be a flag left over from a very old version, the configuration currently sets the first one if XFT is found. At least this is the case for me. At the moment I am not able to compile the xlib backend cleanly because of this. My suggestion is to replace all usage of HAVE_LIBXFT in XGGState.m and XGGState.h with HAVE_XFT. Oops, I had looked at this, but not closely enough I guess. What I saw were a number of HAVE_LIBXXX #defines, including HAVE_LIBXFT, and then also the HAVE_XFT. Because the former was consistent with several others, I thought HAVE_XFT was the odd man out and was added by mistake at some stage. I had been planning to excise it later if no problems arose.. Now looking again I see that HAVE_LIBXFT occurs in 'configure' but not 'configure.ac'.. We should get rid of one and stick with the other. Are there any reasons to prefer XFT or LIBXFT? Currently the LIBXXX pattern is used for Xmu and Xext, while the XXX pattern is used for GLX. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
GUI documentation status 2005/05/18
Hi all, The GNUstep GUI documentation project was launched two weeks ago with the coordinating site: http://penguin.med.cornell.edu/assign/ Since that time, several classes have been claimed or marked complete: Complete2 Claimed 7 This leaves over 100 classes yet to be accounted for, but at least some progress is being made! If you work on and are familiar with any GUI classes, please consider helping by filling out the documentation. It's a chore, but it need only be done once, and many people will benefit from the work. And GNUstep as a whole will be more approachable for new users and developers. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/back ChangeLog Source/xlib/XGGState.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Adrian Robert [EMAIL PROTECTED] 05/05/14 13:53:50 Modified files: core/back : ChangeLog core/back/Source/xlib: XGGState.m Log message: added extra #ifdef to XGGState.m around Xft-specific methods so compilation on non-libxft systems is unaffected CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/ChangeLog.diff?tr1=1.372tr2=1.373r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/xlib/XGGState.m.diff?tr1=1.28tr2=1.29r1=textr2=text
[Gnustep-cvs] gnustep/core/back ChangeLog
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Adrian Robert [EMAIL PROTECTED] 05/05/12 13:43:19 Modified files: core/back : ChangeLog Log message: cache Xft draw state in XGGState and use this to speed glyph rendering in GSXftFontInfo CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/ChangeLog.diff?tr1=1.371tr2=1.372r1=textr2=text
Re: GNUstep Quarterly Report, Mar 05
On May 6, 2005, at 3:00 PM, Alex Perez wrote: Adam Fedor wrote: At the time I sent this, I didn't know how much money we had collected from the FSF. As of March 31 we have about $900 US in funds. If you have any suggestions or comments, let me know. One idea to help with the server farm is to use sourceforge, but we need a project registered here to access it. I was also thinking about buying a computer for someone, with a 'critical' OS that we want to support better... Personally, I think investing in a piece of hardware would be a rather poor use of funds, especially when all we need to do is register a GNUstep project at sourceforge and get a very nice compile/test farm for free. I agree, although I haven't used the sourceforge farm and can't report as to its effectiveness. It WOULD be nice to have someplace to compile and remotely (via X) run GNUstep _apps_, not just the libraries. Unfortunately two important OS's (Windows and OS X) don't work via X, so some kind of VNC solution would be needed, which might not work well over the internet. In general though, this sort of thing seems like more appropriate for GNU / Savannah to provide, rather than one of GNU's projects.. As for uses of the funds, it's still not very much but it would be great if we could use it to pay people to do grunt tasks that no one really wants to work on but would really help the state of the project -- like filling out documentation, working on rarely used / cared-about GUI methods / corner cases that are still worth implementing, etc.. This would work well for someone between jobs, or who usually works as a contractor anyway, but like I say the amount of funds is still a little paltry for this.. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/gui Headers/AppKit/NSFont.h Source...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Adrian Robert [EMAIL PROTECTED] 05/04/30 16:11:22 Modified files: core/gui/Headers/AppKit: NSFont.h core/gui/Source: NSFont.m core/gui : ChangeLog Log message: NSFont cache font for drawing in flipped views in manner analogous to cache of nonflipped screen font for drawing in regular views CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Headers/AppKit/NSFont.h.diff?tr1=1.3tr2=1.4r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSFont.m.diff?tr1=1.80tr2=1.81r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2518tr2=1.2519r1=textr2=text
Re: GUI performance issues with images and scrollers
On 2005-04-29 08:38:30 -0400 Riccardo [EMAIL PROTECTED] wrote: Shortly, I'll discuss my personal experience with very bad GNUstep performance when dealing with images and/or scroll views. I gather this mainly from PRICE, the application I write and maintain which displays images in a scroll view. But the same goes for other applications like preview, image viewer.. but also other applications as I will explain. A simple but unexpectedly useful metric in my experience has been to run a 'top' in one window while putting an app through its paces. I was surprised to discover that most of the CPU during performance bottlenecks was not going to the app, but to X. This led me to investigate the interaction with the X server, and I found in my case that there was too much flushing traffic between the gnustep-maintained pixmap and the X server. During Cocoa and gnustep drawing and image modification for the most commonly used backing-stored window type, there is an update phase, when an app memory pixmap is updated, and a flush phase, when the changes are sent to the window server. In gnustep, this is literally a flush of a rectangular area to the X server's memory; I'm not sure what the mechanics are in Cocoa/Quartz. In any case, in Cocoa, the docs say that a flush occurs but only for the minimal rectangular area surrounding the pixels actually modified. In gnustep, the modified area is not tracked explicitly, and the entire window will be flushed every time unless smaller rects are given in [view lockFocusInRect], which is a gnustep extension. To get gnustep to behave like Cocoa would be a fair amount of work, implementing modified pixel area tracking for all low-level draw operations. A second set of performance-affecting issues that might be affecting large images particularly surround memory management for images. In particular, how much of the image is kept in memory at one time, and where? For example, try comparing xv and eog (eye of gnome) on a large image. The determination of how much of the image to cache in the X server should be made based on the size of the image and available memory constraints. My impression of gnustep is that it does not implement multiple strategies but just caches the whole image in the X server every time. People who know more than I can say more, but I think fixing this would also entail a fair amount of work, though not so much as the modification area tracking... Anyway, in sum I don't think having X in the loop is the problem, it's just the gnustep drawing / image management layer needs to get more sophisticated. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [RFC: Rewriting of the GNUstep User FAQ, specifically re: Frameworks]
On Apr 5, 2005, at 1:52 AM, Sheldon Gill wrote: Alex Perez wrote: Folks, Since people (see http://osnews.com/comment.php?news_id=10182limit=no )are actually reading the GNUstep User FAQ (see http://www.gnustep.org/resources/documentation/User/GNUstep/ userfaq_1.html ), and the information in it regarding Frameworks is IMHO grossly out of date, I'd like to propose that it be revised to reflect the current state of Frameworks and also the fact that our pseudo-frameworks now work under windows, as well as describe what is required for true framework support (eg, linker and compiler support, binary format enhancement to ELF, etc) and perhaps even mention that Matt Rice has done some work towards this goal and to contact him if anyone is interested in it. What do you think? I think it is a good idea but that work on it should be held off for a little while. GNUstep is about to enter an 'unstable' cycle while important changes are made. This is the time when binary-incompatibilities are being introduced. Thus, I believe any current update on the faq will need updating again in the near future. If someone feels like doing it both times thats fine. Otherwise, perhaps a note to the effect: This FAQ is out of date. New FAQ will be issued in ?July? If July is a good approximation of when this might be settled down, something a bit more substantial, such as brief outline of the goals, plans, and reasoning, would be nice. If these are still being worked out, at least a statement like we used to do X, but then we encountered Windows / reevaluated frameworks' usefulness / whatever, and decided to change.. That way people who come to GNUstep at that time (or decide to look into frameworks) will know what to expect and won't need to mail the list asking, What's up with frameworks [on platform X]? Not sure about moving FAQs to the wiki. The editability would be a win, but OTOH it's kind of nice having them right on the main site, quickly accessible and with shared look-and-feel to the rest of gnustep.org. Also, these get delivered with the libraries as part of the on-disk documentation (handy for laptops and other disconnected situations). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: perfomance optimisations
I think we should not introduce a lot more IMPs in GSWeb than we now
have.
There are other areas that should be addressed.
This is a example of a potential thing that could be faster.
If somebody uses cString it is likely that he also uses cStringLength
on the same string.
Both does basically the same. Has somebody an idea how to optimize
here?
Could you give us an idea of the type/magnitude of performance gains
you are wishing for / expecting? Could you post some profiling data
for example? I guess I'm a bit surprised that string-handling kinds of
things are a problem. Java works very well in the server space and
I've never been impressed by the low-level efficiency of its
string-handling (or for that matter the overall architecture of how it
does things.
Here is, for example, the Java 1.3 implementation of String.getBytes():
private byte[] getBytes(CharToByteConverter ctb) {
ctb.reset();
int estLength = ctb.getMaxBytesPerChar() * count;
byte[] result = new byte[estLength];
int length = 0;
try {
length += ctb.convertAny(value, offset, (offset + count),
result, 0, estLength);
length += ctb.flushAny(result, ctb.nextByteIndex(), estLength);
} catch (CharConversionException e) {
throw new InternalError(Converter malfunction: +
ctb.getClass().getName());
}
if (length estLength) {
// A short format was used: Trim the byte array.
byte[] trimResult = new byte[length];
System.arraycopy(result, 0, trimResult, 0, length);
return trimResult;
}
else {
return result;
}
}
Basically the same as the Base method below, except I'm not sure what
that 'append ' is for. (And this starts out interpreted, then gets
just-in-time compiled.)
Anyway, overall Java on the server side is not super-fast compared to
PHP or even Perl, but has won wide acceptance because servlets, JSP,
and JDBC are simple but effective technologies, and also by being
designed for scalability so that more hardware can easily be thrown at
a situation with little developer effort. This was accomplished by a
well-designed application model where session information is
encapsulated and threads are used and reused in lieu of object creation
as much as possible.
On Apr 5, 2005, at 1:07 PM, David Wetzel wrote:
- (const char*) cString
{
NSData*d;
NSMutableData *m;
d = [self dataUsingEncoding: _DefaultStringEncoding
allowLossyConversion: NO];
if (d == nil)
{
[NSException raise: NSCharacterConversionException
format: @unable to convert to cString];
}
m = [d mutableCopy];
[m appendBytes: length: 1];
AUTORELEASE(m);
return (const char*)[m bytes];
}
- (unsigned int) cStringLength
{
NSData*d;
d = [self dataUsingEncoding: _DefaultStringEncoding
allowLossyConversion: NO];
return [d length];
}
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
ANN: Emacs on GNUstep / OS X 8.0-rc2
Hi all, I've released the second rc version of Emacs for GNUstep / OS X at: http://emacs-on-aqua.sf.net/ GNUstep CVS is still required, so I'll hold off announcing these on discuss for now. Release highlights: - now works with Art back-end (yay!) - major rendering improvements, including non-Latin text; caveats: - non-Latin not working yet under xlib, and speed improvement here awaits a patch that is not checked in yet - suitable fonts must be chosen manually (no fontset support yet) - Korean and some other scripts not working - UTF8 files can't be read yet (but most native encodings, Latin-1, GB2312, JIS, etc.) work - numerous small fixes and stability improvements - binary .app.zip available for Linux (let me know how this works) BTW, if anyone is brave enough to try this on Windows (is it time yet?) I'd be curious to hear the results.. enjoy, Adrian ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
GSMime -setDefaultCoding
Hi, [from base ChangeLog] - 2005-03-11 ... * Source/Additions/GSMime.m: * Headers/Additions/GNUstepBase/GSMime.h Added setDefaultEncoding: This is needed in GSWeb if you use utf-8 and faster than using a String as encoding name. ... 2005-03-15 ... * Source/Additions/GSMime.m: Mark ([setDefaultEncoding:]) as deprecated rather than just removing it ... in case someone has started using it. - Could we drop this method completely instead of deprecating? It was only in (non-deprecated) existence for 4 days. Whatever code has been written using it was recently written, and is presumably fresh enough in people's minds for rewriting to not be a problem. On the other hand, leaving it will cause every developer in the future who looks over the documentation or code in this area searching for a way to do something relating to encoding to spend some time and mental effort understanding this method even if it is just to quickly reject it in favor of another. Moreover the base library and documentation will be just that much bigger, with no additional functionality. (Yes, although last week I argued in another thread for saving some deprecated methods, here I'm urging that this one be gotten rid of now -- how's THAT for hypocrisy?! ;) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Rendering of fixed-width fonts
I recently posted about how the Art backend renders the supposedly fixed-width VeraSansMono-Roman in a non-fixed width way. For reference, here is the shot of size 12 showing a regular grid rendering on the bottom: inline: notMono.png The problem is not, apparently Art's; if you run FreeType's own rendering test (I think called 'ftstring' or something like that), the result is the same as the top row above. Digging further, [NSFont -widthOfString] reports that 'm' in size 12 is width of 6.0 while all other characters are 7.0. (Super-simple test program attached.) This information comes from the advancement info in the font. At different sizes, other characters besides 'm' are the odd ones out. So now to the questions. First, I can't find any reference to this on the web. Is everyone rendering this font character-by-character manually? Leaving the question of what's happening in Gnome/Gtk aside, if I render in GNUstep using a call to DPSmoveto() followed by DPSshow() for every character, the problem goes away. It looks like this is what Terminal.app does. Surprisingly, on Art this is actually reasonably fast, but on Xlib performance is unacceptable. This leads to the next question -- is it possible to detect at runtime whether you are running under Art or Xlib? (So as to change rendering strategies.) Is there any more efficient way to render with regular spacing than repeated calls to moveto and show? Sllightly OT, there are no DPS commands on OS X, right? You have to use the Quartz functions, which all start with CG? (The API does not look as clean as DPS, but hopefully it grows on one?) Finally, does anyone have an opinion on whether a fixed-width font should have different advancements like VeraSansMono? Is this a bug in the font? None of the fonts I've tried under Xlib have the problem, and FreeMono under Art lacks the problem. I haven't seen the issue with any fonts on OS X. But the Vera fonts are supposed to be good, and look nice, so why does the monospace one have this problem? testFontWidth.m Description: Binary data thanks, Adrian ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
