From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Thu, 17 Jul 2003 14:08:38 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 151 ************************************************** Wednesday 16 July 2003 Number 151 ************************************************** Subjects for today 1 Re: [EMX] Re: libc : Andreas Buening 2 Re: [EMX] Re: libc : Stefan Neis 3 Ghostscript/GsView : Stefan Neis 4 Re: Ghostscript/GsView : Sebastian Wittmeier (ShadoW)" 5 Re: [EMX] Re: libc : Andreas Buening **= Email 1 ==========================** Date: Thu, 17 Jul 2003 06:26:37 +0200 From: Andreas Buening Subject: Re: [EMX] Re: libc Adrian Gschwend wrote: > > On Wed, 16 Jul 2003 00:08:32 +0200, Andreas Buening wrote: [snip] > Should I create an empty repository or should I take some codebase as > initial repository? The second option means less work for the person > who would checkin the initial source otherwise. > > If someone can point me to this "current" OS/2 source I will set up the > repository tomorrow. If I remember correctly I've installed the sources that are part of gcc 2.8.1 from hobbes (gccsrc*.zip but I'm not sure) plus some update from the emx fixes (the last one, i.e. 0.9f?). The question is how we want to organize the code. Do we want just the libc code (emx/src/lib and emx/src/os2 (?)) or also the tools and the docs? After thinking about this it seems reasonable for me to separate the libc and its docs from the tools (we could name the package emxlibc or emxlib or emxlibs or emxdll). Something like emx/src/lib -> lib emx/src/os2 -> os2 emx/src/include/defs.h -> lib/defs.h emx/include -> include (Have I missed anything important?) The docs can be handled later. I've just looked at some of the Makefile. At least the hardcoded paths have to be changed. Opinions? [snip] Bye, Andreas **= Email 2 ==========================** Date: Thu, 17 Jul 2003 15:38:02 +0200 (CEST) From: Stefan Neis Subject: Re: [EMX] Re: libc On Wed, 16 Jul 2003, Ilya Zakharevich wrote: > I see that some kind of mmap()ing is included. Given no support from > the swapper logic, I doubt it "works as designed". Likewise for > shm*(). Well, no problems have been reported with that code. So either nobody is using it, or it works better than you do expect - at least in the particular cases where it is being used... > Likewise for dlopen(). I know that I'm using dlopen/sym/close a lot myself and I don't see, why it shouldn't work. ;-) If you're alluding to RTLD_LAZY not being supported, then let me state that it's unsupported under *BSD as well, so I maintain the "works as designed" claim at least for that function. (well, FreeBSD actually might support it, but OpenBSD currently does not - nor do a number of BSD clones, AFAIK). > I expect that you must know all this as well. What is the point then > in stating things otherwise? Underline a need for testing. Unless functions like shm* are actually available you'll never get feedback on the quality of the implementation and missing features. I prefer to start with the fiction that everything just should work and if an application doesn't compile/run as intended, one can still start fixing bugs in libc or adding work-arounds for things that just _are_ different. That _can_/will admittedly be fruestrating if you're recompiling something that already was successfully ported to OS/2 (or updating to a newer version), as I've seen on the example of Perl myself (Posix/2's poll is apparently slightly buggy when it comes to handling stdin/out), but I do believe that it's easier in the long run ... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 3 ==========================** Date: Thu, 17 Jul 2003 17:51:33 +0200 (CEST) From: Stefan Neis Subject: Ghostscript/GsView Hi, Last year, there was a heated debate about GSView when its author said, he would not make an OS/2 port of the program. Some people pointed out that using platform dependent toolkits for an application that should be available on as many platforms as possible, would be rather nonsensical, so why not use e.g. wxWindows. Well, it seems even more people have been thinking along those lines than we though at that time. Anybody interested in contributing can now have a look at http://wxghostscript.sourceforge.net/ Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 4 ==========================** Date: Thu, 17 Jul 2003 18:36:59 +0200 (CEST) From: "Sebastian Wittmeier (ShadoW)" Subject: Re: Ghostscript/GsView On Thu, 17 Jul 2003 17:51:33 +0200 (CEST), Stefan Neis wrote: >Last year, there was a heated debate about GSView when its author said, >he would not make an OS/2 port of the program. The situation could have changed now. With Everblue we should have support for all major toolkits available on Linux. The old ghostview program nearly worked (except the easy to implement XChangeProperty function). http://groups.yahoo.com/group/everblue-dev/files/Screenshots -> file ghostview.png >Some people pointed out that using platform dependent toolkits for an >application that should be available on as many platforms as possible, >would be rather nonsensical, so why not use e.g. wxWindows. >Well, it seems even more people have been thinking along those lines >than we though at that time. yeah, one more :-) >Anybody interested in contributing can now have a look at > http://wxghostscript.sourceforge.net/ But interesting pointer nevertheless. We should keep an eye on it. Sebastian **= Email 5 ==========================** Date: Thu, 17 Jul 2003 22:49:59 +0200 From: Andreas Buening Subject: Re: [EMX] Re: libc Ilya Zakharevich wrote: > > On Thu, Jul 17, 2003 at 06:26:37AM +0200, Andreas Buening wrote: [snip] > > The docs can be handled later. I've just looked at some of the Makefile. > > At least the hardcoded paths have to be changed. Opinions? > > The principal lesson of software development is that if nobody > *forces* docs and source to be syncronized, they won't be. :-( It is > crucial to have docs as close to the source as possible. [With > `literate programming' as the extreme point.] > > So please: no "docs later" approach. Sure. I meant it's not necessary to create a doc subdirectory before Adrian goes on holiday. It would make sense to support manpages than just .inf files so we would need a fundamental change in the current doc directory (there seems to be just source for .inf files). What is the optimal input file format if we want manpages, .inf and .html files? Bye, Andreas