Re: Installation on windows (fwd)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2005-03-16 06:06:11 + Sheldon Gill <[EMAIL PROTECTED]> wrote: I've a range of "problems" regarding GNUstep in respect to the file system, some of which are wishes for better behaviour but some are certainly what I'd categorize as bugs. These "wishes" aren't restricted to the windows environment either. Perhaps starting with reporting individual bugs would make sense ... since they generally only get fixed if people know about them, and a problem broken down into individual parts is much easier to deal with. Some of the ideas discussed have begun to be implemented in stages. I wouldn't call it most and definitely not all. At the path handling on windows, essentially the issues arise because OpenStep -> POSIX -> (emulation) -> Win32 is the current layering and that introduces all sorts of issues as we move from layer to layer. The "impedance mismatch" gets compounded and we add both overhead and complexity in the process. Unicode compounds the issues. Especially as there are Unicode issues with mingw and msys. I'm not sure what exactly has been fixed for the latest release but definitely are there for earlier ones. Internally, the current -core code has some parts working with unicode strings for the file system while other parts don't. I see support for unicode filesystem as a strong wishlist item... it's not part of OpenStep, but I feel we should add it since my guess is that the windows implementation of the the posix functions used in a lot of places does not handle it. After quite some investigation I believe the best way is to go OpenStep -> Win32 as far as possible. This means that all things should be in UTF-16 and left untransformed as far as possible and reasonable. I'm not sure what you mean above ... If you simply mean that we should use win32 api calls directly (eg CreateFile() rather than creat()), then I think that's uncontroversial and is the direction we are moving in for the sake of performance and aesthetics. One thing that bugs me about current code is that, because it was written by a variety of unix people, it uses fopen(), fread() fclose() etc in a lot of places where it should realy be using NSFileHandle/NSFileManager to encapsulate system dependencies. Thats' not to say that the existing code is buggy in any way, just that it's less easily maintainable/portable than it might be. The only transformation which should be done is variable expansion on paths read from the environment/registry so that absolute paths are used internally in their native form. This is the safe, sane and future compatible way to go. Least harm, smallest set of assumptions. Leads to least code and smallest overhead. This does lead to some issues with the path handling NSString methods which need to be considered but they aren't show stoppers. There really just needs to be some consideration and handling of the non-POSIX Win32 case where: "\" is the separator "/" isn't the FS root symlinks don't exist "~" is meaningless I think on this point you are asking to break GNUsteps OpenStep/MacOSX compatibility and ignore the userbase of programmers wishing to write portable code. OpenStep was designed for/from a unix worldview and has an API reflecting this. As such it's my opinion that failing to transform strings (for instance to use '/' as the path separator internally) would break things and would force users (by which I mean people writing applications) to write more code with larger overheads because they would end up writing code to allow for differences in path semantics at the application level rather than the library level. So, while it would indeed be 'safe, sane, future compatible, least code, smallest overheads' internally withing the base library, it would be the exact opposite for users of the library who would have to write more code to make their apps portable between unix/windows, would have to understand the assumptions of both filesystems, and would need to know about new filesystems in future... this is not the sort of programming environment we want to provide. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using the GPG bundle for GNUMail iD8DBQFCN91sE6AJp3nmKIkRAh+bAJ4yll37mcc3e+BTPXLGSnE5NoYzrACg1Jy4 Ux/X3+ID8NdT8IS1af3T9pk= =zm2J -END PGP SIGNATURE- ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Installation on windows (fwd)
Richard Frith-Macdonald wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2005-03-14 19:43:01 + Alex Perez <[EMAIL PROTECTED]> wrote: Nicola Pero wrote: here are currently issues with the path handling which causes certain things to only work inside the msys environment. If you remove it before those issues are fixed, you will introduce more problems. Thanks -- ... there might be some confusion ? ;-) ... we are talking of the msys developer toolkit (ie, additional developer tools), not of msys (the base development environment). Anyway. Which issues ? Which path handling ? :-) Unicode path handling under win32 is basically completely broken. I am not privy to the details, but all I can say for sure is that I believe it manifests itself as a problem when you launch a gpbs or gdnc (which are both true GNUstep tools, unlike gdomap, which AFAIR is a C app) from a path with a space in it, it fails miserably. This should not happen. Windows is riddled with paths with spaces, and they must be properly supported. I understand the inherent limitations of GNU Make and GNUstep-make and spaces, but this is not what I am referring to. GNUstep apps at runtime should have 100% support for being launched in a directory with spaces, as well as opening files up in directories with spaces. The current installer "works around" this problem by installing GNUstep to c:\GNUstep, which is in violation of the Windows FSH, but it's the only solution that currently works without fixing the problem with win32 path handling properly and completely. To the best of my knowledge, the problem with launching apps in paths containing a space was fixed about a month ago, and was due to a bug/feature of the way that windows deals with the arguments when spawning a subprocess ... it had nothing to do with unicode string handling. Certainly, I can run gdnc from directories whose names contain spaces. Also, I have never heard of gnustep having any problem opening files whose names contain spaces. Which is not to say that there can't be problems where application programmers parse strings assuming that spaces are being used as filename separators. Anyway, there are no outstanding unfixed bug reports on the issue of spaces in the base library, and no windows specific bug reports for unicode problems that I can remember at all. Let's fix them if we have any. Sheldon Gill knows probably better than anyone else what needs to be done to resolve this. I suggest you send him an e-mail, since I don't think he's subscribed to this list currently. I've been discussing various aspects of win32 gnustep issues with him privately recently, and he knows far more about it than I'd ever care to know :) You can contact him at [EMAIL PROTECTED] , or if he is lurking on the list reading this, I'd like to encourage him to come out of his hole and speak to this :) *Emerges from hole* Hmm... FYI my involvement has been interrupted by RL and my Wallstreet not booting. Also other unspeakable things on the doze box. By the way, the spaces in paths isn't really the issue we were discussing. It's definitely worth checking with Sheldon in case he knows of any bugs he hasn't bothered to report ... though my impression was that most of his problems were wishes that things would work more 'naturally' in a windows environment rather than bugs as such, and I think most/all of the ideas discussed with him have been applied by Adam recently. Ahhem! ...bothered... ?!! I've a range of "problems" regarding GNUstep in respect to the file system, some of which are wishes for better behaviour but some are certainly what I'd categorize as bugs. These "wishes" aren't restricted to the windows environment either. Some of the ideas discussed have begun to be implemented in stages. I wouldn't call it most and definitely not all. At the path handling on windows, essentially the issues arise because OpenStep -> POSIX -> (emulation) -> Win32 is the current layering and that introduces all sorts of issues as we move from layer to layer. The "impedance mismatch" gets compounded and we add both overhead and complexity in the process. Unicode compounds the issues. Especially as there are Unicode issues with mingw and msys. I'm not sure what exactly has been fixed for the latest release but definitely are there for earlier ones. Internally, the current -core code has some parts working with unicode strings for the file system while other parts don't. After quite some investigation I believe the best way is to go OpenStep -> Win32 as far as possible. This means that all things should be in UTF-16 and left untransformed as far as possible and reasonable. The only transformation which should be done is variable expansion on paths read from the environment/registry so that absolute paths are used internally in their native form. This is the safe, sane and future compatible way to go. Least harm, smallest set of assumptions. Leads to least code and s
Re: Rendering of fixed-width fonts
On Tue, 15 Mar 2005 22:12:02 -0700, Adam Fedor <[EMAIL PROTECTED]> wrote: > > On Mar 15, 2005, at 9:57 PM, Adrian Robert wrote: > > > > Ah. Attached is a patch implementing these functions in back-art. ;-) > > > > It modifies the existing DPSshow implementation to handle DPSxyshow, > > DPSxshow, and DPSyshow. Partial support is there for DPSwidthshow. > > Right now I just patched ftfont-old.m since that's what I'm using > > (freetype-2.1.2), and anyway this patch needs some feedback. > > > > > Well, I may have led you astray. I think we were trying to make these > functions obsolete. Although, I'm not sure why now. If you find they > make a big speed improvement, I suppose we could reconsider Hmmm, I didn't know any attempt to make DPS functions obsolete so I keep using them a lot :( BTW, it seems PSops still working on OSX last time I tried them on jaguar, but they are buggy and I have no idea about panther. -- __ Banlu Kemiyatorn / /\ \ Free Software Yogi | / \ | -_-~-_-~-_-~-_-~-_-~-_-~-_-~-_ | /\ | QSTORAD, Qing Shan Tian Xia \/ \/ 136 Nivesana 7, Jangwattana 14 QingShanLaksi, Bangkok, Thailand 10210 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] gnustep/core/base ChangeLog Headers/Foundation/...
Richard Frith-Macdonald wrote:
> On 2005-03-15 08:26:46 + Stefan Urbanek <[EMAIL PROTECTED]>
wrote:
>
>> Hi,
>>
>> In GSFindNamedFile you use:
>>
>> file_name = [NSString stringWithFormat: @"[EMAIL PROTECTED]@", aName,
>> anExtension];
>>
>> should not that be rather:
>>
>> file_name = [aName stringByAppendingPathExtension:anExtension];
>
>
> Yes. Thanks.
> I'm still finding oddities in this patch ... and tidying up when I notice
> them.
Actually, no it shouldn't be. At least, not from my design view.
There was a reason I did (A) rather than (B):
GSFindNamedFile is supposed to be called like this:
located_app = GSFindNamedFile( NSStandardApplicationsPaths(),
"MySpecialApp",
"app");
or
icon_for_file = GSFindNamedFile( icon_places,
"TextFile",
"png");
For this sort of use stringByAppendingPathExtension goes through various
steps and calls before hitting stringWithFormat as above so (A) is
faster and incurs less overhead.
The benefit of using (B) means
icon_for_file = GSFindNamedFile( icon_places,
"TextFile/",
"png");
will still find "TextFile.png" where as for (A) it would fail trying to
find ".png" in the "TextFile" sub-directory of each place in the search
paths.
From an API conceptual point of view aName should really be the name of
the file and not a path spec. The pathing is handled already by the
array of places. If you wanted to search in the "TextFile" sub-directory
you'd add it to each element of the path array, *not* the name.
Regards,
Sheldon
{who sometimes has method behind his madness}
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rendering of fixed-width fonts
On Mar 15, 2005, at 9:57 PM, Adrian Robert wrote: Ah. Attached is a patch implementing these functions in back-art. ;-) It modifies the existing DPSshow implementation to handle DPSxyshow, DPSxshow, and DPSyshow. Partial support is there for DPSwidthshow. Right now I just patched ftfont-old.m since that's what I'm using (freetype-2.1.2), and anyway this patch needs some feedback. Well, I may have led you astray. I think we were trying to make these functions obsolete. Although, I'm not sure why now. If you find they make a big speed improvement, I suppose we could reconsider ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rendering of fixed-width fonts
On 2005-03-15 12:38:44 -0500 Adam Fedor <[EMAIL PROTECTED]> wrote:
On Mar 15, 2005, at 7:33 AM, Adrian Robert wrote:
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.)
In a way, yes. You can check for the backend contexts, like this:
if (GSClassFromName("ARTContext") != nil)
Thanks.
Is there any more efficient way to render with regular spacing than
repeated calls to moveto and show?
Try DPSxyshow and variants.
Ah. Attached is a patch implementing these functions in back-art. ;-)
It modifies the existing DPSshow implementation to handle DPSxyshow,
DPSxshow, and DPSyshow. Partial support is there for DPSwidthshow.
Right now I just patched ftfont-old.m since that's what I'm using
(freetype-2.1.2), and anyway this patch needs some feedback.
For one thing, I don't check the 'size' argument when deltas are
provided. I don't know where people are finding DPS documentation
that goes into this sort of detail, but the postscript docs I read
said an error is generated if 'size' isn't the same as the text
length. Should I check and throw an exception?
For another, I'm not sure when the y advancement should be used. I
guess even the Japanese are mostly writing horizontally now, at
least on computers? ;-)
Index: Source/art/ARTContext.m
===
RCS file: /cvsroot/gnustep/gnustep/core/back/Source/art/ARTContext.m,v
retrieving revision 1.27
diff -a -u -r1.27 ARTContext.m
--- Source/art/ARTContext.m 20 Jan 2005 21:35:23 - 1.27
+++ Source/art/ARTContext.m 16 Mar 2005 04:07:00 -
@@ -235,6 +235,7 @@
: (wi->has_alpha? wi->alpha + clip_x0 + clip_y0 * wi->sx : NULL) : wi->sx
color: fill_color[0]:fill_color[1]:fill_color[2]:fill_color[3]
transform: ctm
+deltas: NULL : 0 : 0
drawinfo: &DI];
UPDATE_UNBUFFERED
}
@@ -262,9 +263,11 @@
drawString: s
at: x:y
to: clip_x0:clip_y0:clip_x1:clip_y1 : CLIP_DATA : wi->bytes_per_line
+ : (wi->has_alpha? wi->alpha + clip_x0 + clip_y0 * wi->sx : NULL) : wi->sx
color: fill_color[0]:fill_color[1]:fill_color[2]:fill_color[3]
transform: ctm
-deltas: numarray : size : 1];
+deltas: numarray : size : 1
+drawinfo: &DI];
UPDATE_UNBUFFERED
}
@@ -286,9 +289,11 @@
drawString: s
at: x:y
to: clip_x0:clip_y0:clip_x1:clip_y1 : CLIP_DATA : wi->bytes_per_line
+ : (wi->has_alpha? wi->alpha + clip_x0 + clip_y0 * wi->sx : NULL) : wi->sx
color: fill_color[0]:fill_color[1]:fill_color[2]:fill_color[3]
transform: ctm
-deltas: numarray : size : 3];
+deltas: numarray : size : 3
+drawinfo: &DI];
UPDATE_UNBUFFERED
}
@@ -310,9 +315,11 @@
drawString: s
at: x:y
to: clip_x0:clip_y0:clip_x1:clip_y1 : CLIP_DATA : wi->bytes_per_line
+ : (wi->has_alpha? wi->alpha + clip_x0 + clip_y0 * wi->sx : NULL) : wi->sx
color: fill_color[0]:fill_color[1]:fill_color[2]:fill_color[3]
transform: ctm
-deltas: numarray : size : 2];
+deltas: numarray : size : 2
+drawinfo: &DI];
UPDATE_UNBUFFERED
}
Index: Source/art/ftfont.h
===
RCS file: /cvsroot/gnustep/gnustep/core/back/Source/art/ftfont.h,v
retrieving revision 1.6
diff -a -u -r1.6 ftfont.h
--- Source/art/ftfont.h 29 Feb 2004 20:45:05 - 1.6
+++ Source/art/ftfont.h 16 Mar 2005 04:08:31 -
@@ -34,6 +34,7 @@
color: (unsigned char)r : (unsigned char)g : (unsigned char)b
: (unsigned char)alpha
transform: (NSAffineTransform *)transform
+ deltas: (const float *)delta_data : (int)delta_size : (int)delta_flags
drawinfo: (struct draw_info_s *)di;
-(void) drawGlyphs: (const NSGlyph *)glyphs : (int)length
@@ -55,14 +56,6 @@
transform: (NSAffineTransform *)transform
drawinfo: (struct draw_info_s *)di;
-/* TODO: see if this is really necessary */
--(void) drawString: (const char *)s
- at: (int)x:(int)y
- to: (int)x0:(int)y0:(int)x1:(int)y1:(unsigned char *)buf:(int)bpl
- color:(unsigned char)r:(unsigned char)g:(unsigned char)b:(unsigned char)alpha
- transform: (NSAffineTransform *)transform
- deltas: (const float *)delta_data : (int)delta_size : (int)delta_flags;
-
-(void) outlineString: (const char *)s
at: (float)x : (float)y
gstate: (void *)func_param;
Index: Source/art/ftfont-old.m
===
RCS file: /cvsroot/gnustep/gnustep/core/back/Source/art/ftfont-old.m,v
retrieving revision 1.1
diff -a -u -r1.1 ftfont-old.m
--- Source/art/ftfont-old.m 11 Jan 2005 15:02:29 - 1.1
+++ Source/art/ftfont-old.m 16 Mar 2005 04:08:32 -
@@ -874,17 +874,12 @@
/* TODO: the current point probably needs updating after drawing is done */
--(void) drawString: (const char *)s
- at: (int)x:(int)y
- to: (int)x0:(int)y0:(int)x1:(int)y1:(unsigned char *)buf:(int)bpl
- color:(unsigned char)r:(unsigned char)g:(unsigned char
Re: Rendering of fixed-width fonts
On Mar 15, 2005, at 5:53 PM, Fred Kiefer wrote: Adrian Robert wrote: 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. Which version of xlib is that slow? The standard one or the one using AA fonts? For the later I still have a patch lying around that should speed it up a lot, but I never had reason to dig in that. AA. If you send the patch my way I'll test it and fiddle with it if need be. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rendering of fixed-width fonts
Adrian Robert wrote: 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. Which version of xlib is that slow? The standard one or the one using AA fonts? For the later I still have a patch lying around that should speed it up a lot, but I never had reason to dig in that. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rendering of fixed-width fonts
On Mar 15, 2005, at 7:33 AM, Adrian Robert wrote:
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.)
In a way, yes. You can check for the backend contexts, like this:
if (GSClassFromName("ARTContext") != nil)
...
Is there any more efficient way to render with regular spacing than
repeated calls to moveto and show?
Try DPSxyshow and variants.
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?)
Yes.
___
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: <> 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
Re: [Gnustep-cvs] gnustep/core/base ChangeLog Headers/Foundation/...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2005-03-15 08:26:46 + Stefan Urbanek <[EMAIL PROTECTED]> wrote: Hi, In GSFindNamedFile you use: file_name = [NSString stringWithFormat: @"[EMAIL PROTECTED]@", aName, anExtension]; should not that be rather: file_name = [aName stringByAppendingPathExtension:anExtension]; Yes. Thanks. I'm still finding oddities in this patch ... and tidying up when I notice them. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using the GPG bundle for GNUMail iD8DBQFCNq6+E6AJp3nmKIkRAv9qAJ9rmg31jIOJ15Cfq2GSxrYT8XvOrgCgukde cHR8fjqgYLHt9H0ovUyRhj8= =RzqY -END PGP SIGNATURE- ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] gnustep/core/base ChangeLog Headers/Foundation/...
Hi, In GSFindNamedFile you use: file_name = [NSString stringWithFormat: @"[EMAIL PROTECTED]@", aName, anExtension]; should not that be rather: file_name = [aName stringByAppendingPathExtension:anExtension]; ? Stefan Citát Richard Frith-Macdonald <[EMAIL PROTECTED]>: > CVSROOT: /cvsroot/gnustep > Module name: gnustep > Branch: > Changes by: Richard Frith-Macdonald <[EMAIL PROTECTED]> 05/03/15 > 08:11:04 > > Modified files: > core/base : ChangeLog > core/base/Headers/Foundation: NSPathUtilities.h > core/base/Source: DocMakefile GNUmakefile NSPathUtilities.m > core/base/Source/Additions: GNUmakefile > Added files: > core/base/Headers/Additions/GNUstepBase: GSFunctions.h > core/base/Source/Additions: GSFunctions.m > > Log message: > Add new files to separate extension functions from main base library. > > CVSWeb URLs: > http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/ChangeLog.diff?tr1=1.2480&tr2=1.2481&r1=text&r2=text > http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Headers/Additions/GNUstepBase/GSFunctions.h?rev=1.1 > http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Headers/Foundation/NSPathUtilities.h.diff?tr1=1.4&tr2=1.5&r1=text&r2=text > http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Source/DocMakefile.diff?tr1=1.27&tr2=1.28&r1=text&r2=text > http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Source/GNUmakefile.diff?tr1=1.151&tr2=1.152&r1=text&r2=text > http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Source/NSPathUtilities.m.diff?tr1=1.3&tr2=1.4&r1=text&r2=text > http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Source/Additions/GSFunctions.m?rev=1.1 > http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Source/Additions/GNUmakefile.diff?tr1=1.12&tr2=1.13&r1=text&r2=text > > > > Stefan Urbanek -- http://stefan.agentfarms.net First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
