Re: Installation on windows (fwd)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2005-03-17 00:51:30 + Sheldon Gill <[EMAIL PROTECTED]> wrote: > My take on that goes a little differently. It recognises that file > system calls on the underlying OS probably require a CString. Exactly > what type of CString can differ. On some platforms you'll need to > convert to a specific codepage. On others it'd be preferred UTF-8. > Having one call to convert makes it easy. I didn't realize that ... I've always assumed that the default character encoding (the one you get when you use -cString) would be the same as the character encoding used by the filesystem. That does allow for a different interpretation of the intention of the filesystemRepresentation methods, rather than that they are there to convert path semantics. > I'm interested, though. Under what use cases which don't involve archiving > paths and moving them between platforms? I can't think of an internal > breakage while remaining on the one platform. I tend to think cross platform, and while nothing springs to mind for 'good' code on a single platform, I bet there are plenty of cases where code assumes '/' as path separators in handling paths using methods other than the specific path manipulation methods (one could call that poor code). > As I noted before, I think that differences in path semantics would force you > to code at the application level when the situation dictates. > > Basically when path semantics are sufficiently between the platforms it is > going to be an issue. I have the view that trying to do it at the library > level will ultimately be more problematic. > > The reason is the implication and impact of the semantic differences is > difficult to foresee and the best response will probably vary from > application to application. Having an emulation layer in the library would > simply make it more complex and annoying to handle these cases. I don't think I agree on this point ... but I don't strongly disagree either, and I don't see how we can be sure which scheme will be harder for the app programmer to deal with except by polling the experience of a lot of developers who have produced applications running on both unix and windows ... experience which does not exist. My gut feel is that standardising on unix/posix path semantics keeps things simpler for the programmer, but if we tell them to stick to using the standard path manipulation methods it should not be necessary for them to know anything other than the implicit OpenStep path semantics defined by the NSString API (except where importing/exporting paths ... perhaps Davids suggestion of additional methods to explicity import/export windows/posix paths would help here). > I think we can handle the general case cleanly now without needing > "internal/external" transformation. > >>> If you consider my example above the current CVS solution adds code and >>> semantic complexity at the application level. Precisely what you are >>> advocating shouldn't happen. >> >> >> Not really ... >> >> 1. You are picking a special (though not unusual) case and you have to >> consider what the overall behavior is. >> 2. GNUstep is providing a helper method to make it easier, rather than >> leaving the app write to code their own. > > How is this helper method making it easier? Wooly thinking on my part ... I was starting from the assumption that given an NSString from the outside workd, you would need to convert to a C-string, then use the filesystemRepresentation method to convert from that C-string back to an NSString containing the proper internel representation of the string ... and the helper method makes that simpler ... but of course your whole point is avoiding any conversion at all. >> OPENSTEP/MacOS-x say you should use >> - -stringWithFileSystemRepresentation:length: and >> - -fileSystemRepresentationWithPath: when importing/exporting strings which >> are expected to be paths. > > I don't read it that way. I read those functions as a convenient way to move > from an NSString to an 8-bit encoding suitable for handing to OS file system > calls. Its an important difference. There is a need for it to be this way, > rather than just CString because many platforms required encoding to a > specific code page. > > In particular, I point to Win95 which was a supported OpenStep platform. > Many *nix systems were also tied to a specific 8-bit encoding. > > I also point to the telling line from Apple's Foundation documentation: > > Raises an NSCharacterConversionException if the receiver can’t be > represented in the file system’s encoding. > > Its about encoding, not internal/external transformation. I read it as pointing out that a unicode NSString for instance may contain characters which the filesystem doesn't support ... not as implying there was no transformation. If a transformation is not performed, this method seems pointless ... unless you know that
Re: Installation on windows (fwd)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2005-03-16 18:50:50 + Alex Perez <[EMAIL PROTECTED]> wrote: Richard Frith-Macdonald wrote: 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. Wrong Wrong Wrong Wrong Wrong Wrong Wrong or at least not all of the time. Systemic problems require systemic solutioins. The does not simply apply to programming, either. Yep ... inflammatory :-) Of course systemic problems require systemic solutions ... but that in no way invalidates the point. To quote Einstein 'Everything should be as simple as possible, but no simpler'. If you see a systemic problem as a mass of bugs rather than a single bug with a lot of symptoms, that's a basic error in your viewpoint. Now, as a great example of a systemic problem being fixed, lets look at the state of the gui some years ago. It was full of glitches in the drawing, and we identified the view coordinate transformation code as being incorrect ... of course, in order to make things more or less work, the rest of the code by then contained hacks to compensate for the underlying bug. When you considered all those hacks too ... the total number of things to fix looked huge and unmanagable. One person quit the project in part over the argument about what to do ... he wanted to continue hacking the code fix individual symptoms ...but, having isolated the root cause of our problems in the coordinate transformations, we went ahead and fixed the main coordinate transformation code. This broke all those other hacks and made the gui completely unusable for a few weeks, but the code quickly recovered and went on to be a really usable library where before we had been essentially stuck for a couple of years! This is a perfect example of isolating an individual bug in such a way that everyone could understand the issue, where trying to fix that bug AND all the existing code which depended on it in one go just couldn't happen. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using the GPG bundle for GNUMail iD8DBQFCOULBE6AJp3nmKIkRAvJLAJ9ajzAnGN8AZ1kM9sPgTjh7uK8jngCgwPTy 3lneg6rYUK2JgHfi62nRJVU= =WQrl -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-16 19:38:44 + Jeremy Bettis <[EMAIL PROTECTED]> wrote:
However, -lastPathComponent would return 'test.txt' for the first
string and
'Temp\test.txt' for the second string as these are assumed to be posix
paths.
Perhaps OPENSTEP did the same thing?
I can tell you from experience what OPENSTEP did.Methods like
writeToFile: didn't touch the filename at all. Remember windows
doesn't care which way the slashes go, so fopen("c:\\temp\\text.txt",
"r") is EXACTLY the same as fopen("c:/temp/text.txt", "r") is EXACTLY
the same as fopen("c:\\temp/text.txt", "r"). And lastPathComponent
would return the part of the string after either / or \.
So [@"c:/temp\\text.txt" lastPathComponent] returned @"text.txt" and
[@"c:\\temp/text.txt" lastPathComponent] returned @"text.txt" also.
And I wish gnustep worked the same way.
Oops ... I got it wrong ... GNUstep *will* do that on mingw. It always
uses
'/' for building paths,
but will accept '\\' when parsing them on mingw.
I'm not at all sure that is *good* behavior though ... why do you 'wish
gnustep worked the same way' ?
Given that it apparently does work the same way, I guess your desire is
theoretical rather than practical as you can't have had any problems
with it
not doing that.
Hmm, actually OPENSTEP for NT is based on some cygwin variant (at least
that's what the tool chain indicates), so this behavior actually is not
really surprising.
I'm not suggesting that we should forcibly break this, but I do wish the
paths provided by the GNUstep library are always in the POSIX format
(I'm not aware of the current behavior) making it the "preferred" format.
OTOH, I can understand that for an stand alone application to be
"integrated naturally" into the windows environment, where users are
used to seeing and typing paths with \, this may be very annoying. So
possibly the "preferred format" should in some way be customizable.
The add-on I'm hinting at is a standardized utility to deal with paths
coming from other sources like user input, environment variables or
paths coming via DO from other systems, so they can be easily converted
to POSIX format when doing extensive path manipulations. The point is
to be able to reliably compare (and sort) paths.
Cheers,
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Installation on windows (fwd)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2005-03-17 01:08:20 + Sheldon Gill <[EMAIL PROTECTED]> wrote: While my feeling is that the two approaches are fairly evenly balanced (leaving aside distributed systems, and the fact that we have one system already working in the libraries, and consideration for the existing application codebase), I'd like to hear what other people think about the general prionciple. So would I. Hence I've been quiet for a bit. Speak up, people. Yes ... I've found David's and Jeremy's contributions useful in understanding the old OPENSTEP behavior and seeing other people might like. Obviously, the current code works fine (possibly excepting a few places where old non-unicode api's are used to talk to winodws and we would rather have unicode), conforms to the letter of the documentation, and the basic principle is consistent and easily understood. On the other hand, it's not quite the way OPENSTEP worked, nor is it necessarily the *best* implementation. David's vote for internal posix semantics notwithstanding, I think I'm overall convinced of the strength of your argument that the library would be better using native filesystem semantics. I don't believe it would be hard to make that change, as it looks quite easy to do in a number of small stages where the code continues to work at each stage (though we may expose 'bugs' where gui/back/application code manipulates paths assuming they are in posix format rather than using the path manipulation methods). I'm not sure how many other people agree that the change is desirable though. One thing I am sure of though ... if we do make this change we should document it extensively since I'm pretty sure it would be a divergence from the natural/expected behavior of most users/developers ... who: a. come from a unix world b. have read the examples in the GNUstep and Applke documentation ... all of which show posix style strings. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using the GPG bundle for GNUMail iD8DBQFCOUs9E6AJp3nmKIkRAixIAKDUnSSw5IMgOyLkuzQtKVkTZilK7gCfWdPg 4OEk+oeUEalG/2Ekl0v3YNQ= =7wbw -END PGP SIGNATURE- ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Installation on windows (fwd)
Speak up, people. We have a GNUstep app that run on both windows/mingw and unix. Path handling have been a pain all the way. We had to patch the GNUstep library to get a correct behavior (this was a few years ago. With current versions of GNUstep, we don't have to patch anymore). We did not send bug reports/patches mostly because we never clearly understood how it was supposed to work. We had directories containing backslashes on unix, inability to properly run installed across multiple drives and/or over UNC path on windows, you name it, we ran into it :-) (Add to that, the brain damaged concept of msys rewriting path in arguments/environment and the need to fork some native utilities with proper path, and you'll get some fun ahead) We settled on using only / separated strings, and required the user to specify those this way (also because of the added fun of specifying a windows path in a property list file). This solved all (almost) of our path problems, but we basically put the burden of conversion onto the user. This is not a problem in our case, but will not be acceptable for the general public. By far, the most important thing here is a clear definition of how it is *supposed* to work under windows. In particular how a GNUstep developer/user should expect its path string to be in various cases: * A binary launched from a msys shell that takes a path. * A binary launched from a CMD.exe, that takes a path * A windows service, with a path * What kind of path an open dialog returns * How a hard-coded path in the code should look. * Is NSLog( @"%@", aPath ) the proper way to print a path ? * How do I store a path in a property list file ? * What should be done with a path retreived with Windows API * Where does / points to ? Is it different if I change drive with some Win32 API ? * Is /c/ supported ? * Does ~ exists, and if yes, where it points to ? * What should be done before calling fopen with a 'path string' * What should be done before calling a windows API etc, etc. On the broader problem, there are, I think only two ways to deal with path in GNUstep: * We keep everything as '/' internally (as I think it is done today). We put the burden on the developer to translate all the path to that format. It may be very difficult, because 1) such problem don't occur in unix, so code ported from there will ignore the problem 2) sometimes, it is hard to know that something is a path (argument to some command-line software). * We keep everything 'native' internally. We render multi-platform software harder to write, and will have code with hard-coded '/' failing, which is strange, because even the C Library uses '/' under windows. All current code that uses '/' (or have stored such path in some configuration files) will suddently fail. My 2 cents, --fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
Citát Adam Fedor <[EMAIL PROTECTED]>: > > On Mar 16, 2005, at 3:03 AM, Stefan Urbanek wrote: > > > Hi, > > > > What are the plans for the next GNUstep -bas and -gui releases? > > > > Is it possible to make minor releases more often and to publish > > plans/todos for > > next major and minor releases? > > > > Moreover, can people who make releases describe the whole process on > > the new > > wiki so others delegated developers can make the releases when > > official release > > manager can not? > > > I've put the instructions here: http://mediawiki.gnustep.org/index.php/GNUstep_release_procedure Wehre one can find the scripts you are mentioning there? > My plan so far: > > binary compatible releases (by the end of March) > base 1.10.2 (based on CVS from Feb 22 2005) > gui 0.9.5 > back 0.9.5 > Can this be more often? Last minor gui release dates to september or october last year. Most of GNUstep based projects requre "fresh GNUstep CVS checkout". That requirement should be totaly removed. > Actually, I'm ahead of things so I could make these releases even > sooner if there is general interest. > See argument above. > binary incompatible release (a few weeks or month later): > base 1.11.0 > gui 0.10.0 > back 0.10.0 > > Really, the hard part is not 'making' the release. That's quite easy > and almost fun. The part I really want help with is having people who > know each library well to act as library managers - make up a list of > release criteria and tell me when a good time to make a release is. > GNUstep is to big and too much work for me to do this all by myself. > What about explicitly assigning and publishing a core developer(s) to each GNUstep package? The package development leader should: - publish TODO list and goals for the package - publish plans for the next release (can be discussed with others) - approve releases The last one means, that the package development leader do not have to do the release if he does not have time. He just approves that anyone else can make the release. Releases can do even novice GNUstep users if they have instructions and approval. If nothing else, they can at least learn the sctructure of the GNUstep by this. In addition, ca we make releases even there were no significant changes in the library, only small bugfices? Those releases can keep GNUstep users attentive and they will at least have the impression, that something is happening. "Hey, we care about you, here is a new releases with fixes of the problem you were having, you do not need to use that hack anymore.". Problem is, that we all are living too much in the CVS GNUstep world and see constant changes. Outside world does not see the changes. Here is the Roadmap page: http://mediawiki.gnustep.org/index.php/Roadmap Perhaps we should have "Roadmap - package_name" pages if the first one will be too long. Thoughts? 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
Re: [GDL2] NSAutoreleasePool/EOFault
Manuel Guesdon wrote: >| I agree with Richard, that this is all a bit worry some. But by design >| those two optimization simply don't work to well together. I think we >| could implement the EOFault class method instanceMethodForSelector: to >| accommodate the NSAutoreleasePool optimization, at least temporarily to >| unbreak GDL2. I agree. Please commit you fix for now. >| Maybe add an NSWarnLog saying. @"Returning an EOFault >| instance implementation pointer for selector:". OK for a one time warning. Fine, but I think the GSOnceFLog/GSOnceMLog macros are not part of -baseadd yet. >| I'm still a bit unsure on how to deal with the methodForSelector: class >| method. But that's just because it looks like the issue seems unsolvable. Yes, it's not a simple probleme and I'm too not sure that there's a perfect solution. Another idea is to have a list of class to exclude in a as simple (fast) as we can structure (like a c array) to store small number of class to exclude from optimization but it will be non sttandard and slower. The problem is, that you can't always identify the class. If you have an unfaulted custom class you don't know whether it will ever be faulted. And whether you want the fault's implementation or the objects implementation depends on the context. For NSAutoreleasePool's release we're just lucky. Another one could be to not use the EOFault class directly but an EOFault derived dynamically created class for each kind of EOFault possible class so the class returned by GSObjCClass will 'know' what it is and could handle messages better (i.e. its release method can call EOFault -release if object is really a fault of real class -release if object is not a fault) but it introduce a kind of proxy which will be slower... You mean verifying in the -release implementation of EOFault that the receiver is still a fault... and if not actually sending [self release]... And a custom object's release implementation (well actually our (GDL2's) -release implementation of NSObject) would have to check whether we are actually a fault currently, and if so, send [self release]... hmmm maybe it could work as long as no one overrides release. But it it quite a hack and it would be applicable to retain and a few other methods also. I'll spend some more time thinking about it. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: More Windows stuff ... example gui apps work for me now
> > OK ... I did more Windows stuff ... I managed to build gnustep-base with > > all the additional libs (even if I didn't do any change to get this ... > > maybe because I'm installing different libs ?). I also got the gui > > working ... and generally libraries and bundles. I finally compiled some > > gui apps -- they work for me! > > > > I was pretty impressed with the gui apps :-) > > > > Hi Nicola, > > if you enable the new building system for Cygwin as well, I could give > it a try. No need for you to install a new Cygwin system just for that. I did install Cygwin, and I tried this out, and it didn't work. At a first glance, the GCC/linker/etc shipped by default with Cygwin are not new enough to have the new features (auto-export / auto-import etc) we're using ? Anyway ... if you want to try it out, just open target.make, and copy the mingw config over in the cygwin config too. I might look again at that ... ... if you have any ideas, obviously let me know! :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re[2]: [GDL2] NSAutoreleasePool/EOFault
On Thu, 17 Mar 2005 14:56:06 +0100 David Ayers <[EMAIL PROTECTED]> wrote: >| Manuel Guesdon wrote: >| >| > >| I agree with Richard, that this is all a bit worry some. But by >design >| > >| those two optimization simply don't work to well together. I think we >| > >| could implement the EOFault class method instanceMethodForSelector: to >| > >| accommodate the NSAutoreleasePool optimization, at least temporarily >to >| > >| unbreak GDL2. >| > >| > I agree. >| >| Please commit you fix for now. Done. >| > >| I'm still a bit unsure on how to deal with the methodForSelector: >class >| > >| method. But that's just because it looks like the issue seems >unsolvable. >| > >| > Yes, it's not a simple probleme and I'm too not sure that there's a >perfect >| > solution. >| > >| > Another idea is to have a list of class to exclude in a as simple (fast) >as we >| > can structure (like a c array) to store small number of class to exclude >| > from optimization but it will be non sttandard and slower. >| >| The problem is, that you can't always identify the class. If you have >| an unfaulted custom class you don't know whether it will ever be >| faulted. And whether you want the fault's implementation or the objects >| implementation depends on the context. For NSAutoreleasePool's release >| we're just lucky. I was thinking about EOFault, not classes which can be faulted, as this is the class we get when we do a GSObjCClass(anObject). >| > Another one could be to not use the EOFault class directly but an EOFault >| > derived dynamically created class for each kind of EOFault possible >| > class so the class returned by GSObjCClass will 'know' what it is and >| > could handle messages better (i.e. its release method can call EOFault >-release >| > if object is really a fault of real class -release if object is not a >fault) but it >| > introduce a kind of proxy which will be slower... >| >| You mean verifying in the -release implementation of EOFault that the >| receiver is still a fault... and if not actually sending [self >| release]... And a custom object's release implementation (well actually >| our (GDL2's) -release implementation of NSObject) would have to check >| whether we are actually a fault currently, and if so, send [self >| release]... Yes, something like that. >| hmmm maybe it could work as long as no one overrides >| release. But it it quite a hack and it would be applicable to retain >| and a few other methods also. I'll spend some more time thinking about it. We could also provide some macros to call at the beginning of methods to do the job but anyway, no perfect solution. Manuel ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
On Mar 17, 2005, at 6:50 AM, Stefan Urbanek wrote: Citát Adam Fedor <[EMAIL PROTECTED]>: Really, the hard part is not 'making' the release. That's quite easy and almost fun. The part I really want help with is having people who know each library well to act as library managers - make up a list of release criteria and tell me when a good time to make a release is. GNUstep is to big and too much work for me to do this all by myself. What about explicitly assigning and publishing a core developer(s) to each GNUstep package? The package development leader should: - publish TODO list and goals for the package - publish plans for the next release (can be discussed with others) - approve releases It's probably not necessary to burden "core developers" with these tasks if others are willing to help out. There are some people who do a lot of coding in base and gui and tend to give advice on patches and the like. If any of them want to serve as release manager for base, gui, or back then that's great. But it if not, that's great too, as long as they can coordinate with someone else who handles the mechanics of managing bug reports, doing stabilization branches, etc.. In this model, the release manager gets advice on technical issues and good time points for releases from the technical folks, who go on concentrating on coding and reviewing patches. Communications are important -- this would only work if there were specific designated people the release manager could contact with questions and who are committed to helping them with decisions. If this could be set up, then it might also be possible to consider some kind of regularized release schedule, which might help people delivering apps, packaging for distributions, etc.. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Installation on windows (fwd)
- Original Message - From: "Richard Frith-Macdonald" <[EMAIL PROTECTED]> To: "Jeremy Bettis" <[EMAIL PROTECTED]> Cc: Sent: Wednesday, March 16, 2005 2:49 PM Subject: Re: Installation on windows (fwd) [...] Oops ... I got it wrong ... GNUstep *will* do that on mingw. It always uses '/' for building paths, but will accept '\\' when parsing them on mingw. I'm not at all sure that is *good* behavior though ... why do you 'wish gnustep worked the same way' ? Given that it apparently does work the same way, I guess your desire is theoretical rather than practical as you can't have had any problems with it not doing that. I have had a handful of problems with path handling, but you are correct, my expressed desire is theoretical rather than pratical. Primarially because I am willing to make my own changes to gnustep to accomplish my goals. (patches always available at deadbeef.com) And while I hope that I can eventually merge to an official release of gnustep, that is not my biggest concern. There was a strange bug somewhere, I forget where exactly, where some method was doing something funky with colons, and destroying paths that started with c:\. I believe that minimal path munging is good, because I think that my concept of "user" is different than yours. My point of view is that the standard user is a rank windows newbie just trying to use a windows application which happens to depend on gnustep. Your point of view is that the standard user is a unix developer who is porting their gnustep code to windows or something like that. Clearly I am not inside your head, so this is a guess on my part. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] gnustep/core/base/Source NSPathUtilities.m
On Mar 17, 2005, at 8:07 AM, Richard Frith-Macdonald wrote: Modified files: core/base/Source: NSPathUtilities.m Log message: Don't log config problems repeatedly .. once is enough. I haven't tried this, but will it work? I thought we were using fprintf to avoid recursion problems with NSLog when basic things like the user defaults were being setup. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [GDL2] NSAutoreleasePool/EOFault
Manuel Guesdon wrote: On Thu, 17 Mar 2005 14:56:06 +0100 David Ayers <[EMAIL PROTECTED]> wrote: | | Please commit you fix for now. Done. Thanks! | > >| I'm still a bit unsure on how to deal with the methodForSelector: class | > >| method. But that's just because it looks like the issue seems unsolvable. | > | > Yes, it's not a simple probleme and I'm too not sure that there's a perfect | > solution. | > | > Another idea is to have a list of class to exclude in a as simple (fast) as we | > can structure (like a c array) to store small number of class to exclude | > from optimization but it will be non sttandard and slower. | | The problem is, that you can't always identify the class. If you have | an unfaulted custom class you don't know whether it will ever be | faulted. And whether you want the fault's implementation or the objects | implementation depends on the context. For NSAutoreleasePool's release | we're just lucky. I was thinking about EOFault, not classes which can be faulted, as this is the class we get when we do a GSObjCClass(anObject). But we don't need to exclude EOFault since it's using GSObjCClass and it as Richard said, if it ever were actually need to call class the optimization would become moot and it would send -release anyway. So I don't think we have to do anything here for now. | > Another one could be to not use the EOFault class directly but an EOFault | > derived dynamically created class for each kind of EOFault possible | > class so the class returned by GSObjCClass will 'know' what it is and | > could handle messages better (i.e. its release method can call EOFault -release | > if object is really a fault of real class -release if object is not a fault) but it | > introduce a kind of proxy which will be slower... | | You mean verifying in the -release implementation of EOFault that the | receiver is still a fault... and if not actually sending [self | release]... And a custom object's release implementation (well actually | our (GDL2's) -release implementation of NSObject) would have to check | whether we are actually a fault currently, and if so, send [self | release]... Yes, something like that. | hmmm maybe it could work as long as no one overrides | release. But it it quite a hack and it would be applicable to retain | and a few other methods also. I'll spend some more time thinking about it. We could also provide some macros to call at the beginning of methods to do the job but anyway, no perfect solution. Hmm. I don't really like the idea yet. I think we should really try to avoid IMP caching where it doesn't have a clear measurable benefit and then think about the consequences everywhere we actually do need IMP caching and deal with them as they come up. Punishing everyone else with extra tests and harder debugging doesn't seem like the right direction to me. But I've not made up my mind yet on whether this may be worth it anyway. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rendering of fixed-width fonts
On Mar 16, 2005, at 4:45 PM, Fred Kiefer wrote: Adrian Robert wrote: On 2005-03-15 12:38:44 -0500 Adam Fedor <[EMAIL PROTECTED]> wrote: On Mar 15, 2005, at 7:33 AM, Adrian Robert wrote: 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. Not sure if this patch is really needed. I remember moving the implementation of these methods up to the GSC level. So removing the current art implementation should give the full behaviour. Perhaps not optimized for speed, but as we want to get rid of them anyway, it should do. OK, I see in GSGState.m the DPSxyshow family is implemented, yet plain DPSshow is left to the subclass. Accordingly, in Art, DPSshow gets its own implementation. It seems like there are merits both to consolidating backend code as much as possible in GSC and in allowing individual backends to handle things in a way more optimal for their nature. But wherever this decision ends up for DPSshow for a particular backend, DPSxshow etc. should be in the same place, since their implementations are so similar (only difference is advancements between glyphs, which is a very small fraction of the code). Or is the split relating to the desire to deprecate [xy|x|y|width]show? I still can't find any reference on the web as to why, whether searching for DPS or just regular postscript. These operators continue to be actively supported in recent Ghostscript, for instance. Since they are useful at least for dealing sanely with monospaced fonts that are not monospaced, such as VeraSansMono-Roman, and the implementations are all there (assuming some form of this patch can be accepted), could we just undeprecate them? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Installation on windows (fwd)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2005-03-17 15:52:53 + Jeremy Bettis <[EMAIL PROTECTED]> wrote: I have had a handful of problems with path handling, but you are correct, my expressed desire is theoretical rather than pratical. Primarially because I am willing to make my own changes to gnustep to accomplish my goals. (patches always available at deadbeef.com) And while I hope that I can eventually merge to an official release of gnustep, that is not my biggest concern. There was a strange bug somewhere, I forget where exactly, where some method was doing something funky with colons, and destroying paths that started with c:\. I don't believe anything should mess with c:\ except when importing/exporting a path. Current behavior is essentially that all paths are held internally as posix/unix paths nad must be converted to/from windows format when they are imported/exported. I believe that minimal path munging is good, because I think that my concept of "user" is different than yours. My point of view is that the standard user is a rank windows newbie just trying to use a windows application which happens to depend on gnustep. Your point of view is that the standard user is a unix developer who is porting their gnustep code to windows or something like that. Clearly I am not inside your head, so this is a guess on my part. Yep ... you guess absolutely right about my viewpoint ... but I hope I'm open to other viewpoints too (you just might need to work a bit to make things clear to me). So far the comments on this seem fairly evenly divided ... David and Frederic for posix internal format as at present, Sheldon and you (at least I think that's your position) would like paths to be held in native (windows) format internally. I beleive I'm fairly neutral ... I started off with a definite preference for the existing code, but after reading Sheldon's arguments I'm more inclined towards the storage of paths in native format. One thing is really clear though ... we need to decide on a rule, stick to it, and document it MUCH better. If we want to stay with the current behavior of expecting paths to be held in posix format internally, we should remove the current code which accepts a backslash as a path separator on windows, and be rigorous about using only posix style paths. If we want to use native format internally, we need to change the base library to work that way. In either case, we probably ought to have helper methods to convert between posix and windows style paths, as it is always going to be necessary for the application to do that sort of thing occasionally (though we should minimise it). We should probably explicitly document policy/behavior for all the cases Frederic mentioned. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using the GPG bundle for GNUMail iD8DBQFCObTPE6AJp3nmKIkRAuIvAJ9vI99oYWCykDa0xcYHupSznfcnjgCeN2Ke 7i6aMjB2Z0s2r3hikKM7Vls= =irfO -END PGP SIGNATURE- ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rendering of fixed-width fonts
On Mar 17, 2005, at 9:27 AM, Adrian Robert wrote: Since they are useful at least for dealing sanely with monospaced fonts that are not monospaced, such as VeraSansMono-Roman, and the implementations are all there (assuming some form of this patch can be accepted), could we just undeprecate them? Sure. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
On Mar 17, 2005, at 8:13 AM, Adrian Robert wrote: It's probably not necessary to burden "core developers" with these tasks if others are willing to help out. There are some people who do a lot of coding in base and gui and tend to give advice on patches and the like. If any of them want to serve as release manager for base, gui, or back then that's great. But it if not, that's great too, as long as they can coordinate with someone else who handles the mechanics of managing bug reports, doing stabilization branches, etc.. In this model, the release manager gets advice on technical issues and good time points for releases from the technical folks, who go on concentrating on coding and reviewing patches. Communications are important -- this would only work if there were specific designated people the release manager could contact with questions and who are committed to helping them with decisions. If this could be set up, then it might also be possible to consider some kind of regularized release schedule, which might help people delivering apps, packaging for distributions, etc.. Sounds like a good idea. We could use someone who is only moderately familiar with the libraries to collect suggestions and draw up a release plan ___ 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: On Mar 16, 2005, at 5:12 AM, Banlu Kemiyatorn wrote: On Tue, 15 Mar 2005 23:57:45 -0500, Adrian Robert <[EMAIL PROTECTED]> wrote: 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? ;-) How very gaijin of you. How very gwailo of you. I have seen a *lot* of japanese text in the field of publishing that use vertical layout. Well, my confusion was this: since, at least in Chinese and Japanese, the same font can be used for either horizontal or vertical layout (correct me if I'm wrong here), and presumably has both x and y advancements set nonzero, how should a PS command like moveshow(txt) know to advance the point vertically or horizontally per character? The current implementation in Art just assumes horizontal. It seems like some type of layout preference info would need to be passed from a higher level. Welcome to the wonderful world of complex script layout. Truth is, it needs to be much more complicated than just "preference info". If Chinese & Japanese are confusing you, just wait til you hit Farsi! Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rendering of fixed-width fonts
Sheldon Gill wrote: Adrian Robert wrote: On Mar 16, 2005, at 5:12 AM, Banlu Kemiyatorn wrote: On Tue, 15 Mar 2005 23:57:45 -0500, Adrian Robert <[EMAIL PROTECTED]> wrote: 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? ;-) How very gaijin of you. How very gwailo of you. I have seen a *lot* of japanese text in the field of publishing that use vertical layout. Well, my confusion was this: since, at least in Chinese and Japanese, the same font can be used for either horizontal or vertical layout (correct me if I'm wrong here), and presumably has both x and y advancements set nonzero, how should a PS command like moveshow(txt) know to advance the point vertically or horizontally per character? The current implementation in Art just assumes horizontal. It seems like some type of layout preference info would need to be passed from a higher level. Welcome to the wonderful world of complex script layout. Truth is, it needs to be much more complicated than just "preference info". If Chinese & Japanese are confusing you, just wait til you hit Farsi! or Arabic, or Hebrew :) RTL scripts in general are a PITA to implement/support :) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
