Date: Sat, 20 Mar 2004 00:04:08 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 319 ************************************************** Friday 19 March 2004 Number 319 ************************************************** Subjects for today 1 Re: Python & /dev/null : Steve Wendt" 2 Re: Make error : T.Sikora" 3 Re: Python & /dev/null : Sebastian Wittmeier" 4 Re: GCC 3.2.2 Beta 4 compiling gnuplot (CVS) : Knut Stange Osmundsen 5 Re: Python & /dev/null : Knut Stange Osmundsen 6 Sorry for a dumb question : Dave Webster 7 RPM : Bart van Leeuwen" 8 Re: Sorry for a dumb question : John Poltorak 9 Re: RPM : Dave and Natalie" 10 Re: Sorry for a dumb question : Dave and Natalie" 11 Re: Sorry for a dumb question : Andreas Buening 12 Re: Make error : Andreas Buening 13 Re: Python & /dev/null : Dave and Natalie" 14 Re: Make error : John Poltorak 15 [wxOS2] Stefan, question on your build environment : Dave Webster 16 Re: Make 3.81beta1 (was: Make 3.80) : Andreas Buening 17 Re: Python & /dev/null : John Poltorak 18 Re: RPM : Bart van Leeuwen" 19 Re: RPM : John Poltorak 20 Recursive delete with rm : John Poltorak 21 Re: RPM : John Poltorak 22 Re: Recursive delete with rm : Sebastian Wittmeier" 23 Re: Recursive delete with rm : don 24 Re: Python & /dev/null : Sebastian Wittmeier" 25 .pod files : John Poltorak 26 Re: Recursive delete with rm : John Poltorak 27 Re: RPM : Adrian Gschwend" 28 Re: Python & /dev/null : John Poltorak 29 Re: .pod files : Henry Sobotka 30 Re: .pod files : Thomas Dickey 31 Fluxbox and unresolved symbols : Dave and Natalie" 32 Re: Fluxbox and unresolved symbols : Henry Sobotka 33 Re: Python & /dev/null : Stefan Neis 34 Re: Make error : Stefan Neis 35 Re: Python & /dev/null : Stefan Neis 36 Re: Python & /dev/null : Andrew MacIntyre 37 Re: RPM : Stefan Neis 38 Re: Recursive delete with rm : Stefan Neis 39 Re: Recursive delete with rm : Stefan Neis 40 Re: Python & /dev/null : Steve Wendt" 41 Re: Python & /dev/null : Steve Wendt" 42 Re: Fluxbox and unresolved symbols : Dave and Natalie" 43 Re: RPM : Adrian Gschwend" 44 Re: RPM : John Poltorak 45 checking for pnmcut... missing : John Poltorak 46 Perl 5.8.3 : John Poltorak 47 Re: RPM : Stefan Neis **= Email 1 ==========================** Date: Thu, 18 Mar 2004 04:55:38 -0800 (PST) From: "Steve Wendt" Subject: Re: Python & /dev/null On Thu, 18 Mar 2004 12:12:01 +0000, John Poltorak wrote: >> >Figure out where 'nul:' comes from and replace it with 'nul' probably. > >After some fiddling it looks as though it would work if devnull was >defined as 'dev/null' but no such file exists on OS/2... If you don't like my previous suggestion, you could use \dev\nul instead. ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.) **= Email 2 ==========================** Date: Thu, 18 Mar 2004 08:08:04 -0500 From: "T.Sikora" Subject: Re: Make error John Poltorak wrote: > On Wed, Mar 17, 2004 at 10:33:14PM +0100, Andreas Buening wrote: > >>John Poltorak wrote: >> >>>I've recently being trying to build the latest version of Zope, which is a >>>Python based web application server - and pretty neat it is too. >>> >>>I did find, after much trial and error, that I could build it, but only by >>>using different versions of Make for different stages. A successful build >>>was achieved using v3.79.1 initially, followed by v3.76.1 when running >>>'make install'. >> >>Strange. What error messages did you get? > > > Using Make 3.76.1 it failed very early:- > > Zope-2.7.0 > ./configure --with-python=/usr/bin/python --ignore-largefile > > Using Python interpreter at /usr/bin/python > > Configuring Zope installation > > - Zope top-level binary directory will be /opt/Zope-2.7. > - Makefile written. > > Next, run make. > > make > "U:\USR\BIN\PYTHON.EXE" "U:/unixos2/workdir/Zope-2.7.0/setup.py" \ > build > --build-base="U:/unixos2/workdir/Zope-2.7.0/build-base/python-2.3" > --build-lib="U:/unixos2/workdir/Zope-2.7.0/build-base/python-2.3/build-lib" > --build-scripts="U:/unixos2/workdir/Zope-2.7.0/build-base/python-2.3/build-scripts" > --build-temp="U:/unixos2/workdir/Zope-2.7.0/build-base/python-2.3/build-temp" > make: U:USRBINPYTHON.EXE: Command not found > Configure writes the make file wrong. Just go in and change the path for python. -- T.Sikora tsikora at ntplx dot net **= Email 3 ==========================** Date: Thu, 18 Mar 2004 15:04:59 +0100 (CET) From: "Sebastian Wittmeier" Subject: Re: Python & /dev/null On Thu, 18 Mar 2004 04:55:38 -0800 (PST), Steve Wendt wrote: >If you don't like my previous suggestion, you could use \dev\nul instead. So os.path.exists('/dev/null') returns false, and os.path.exists('\dev\null') returns true? Should os.path.exists() accept both slashes, or should Zope look up the directory separators of the local system? Sebastian **= Email 4 ==========================** Date: Thu, 18 Mar 2004 15:22:34 +0100 From: Knut Stange Osmundsen Subject: Re: GCC 3.2.2 Beta 4 compiling gnuplot (CVS) Franz Bakan wrote: > On Wed, 17 Mar 2004 16:29:08 +0100, Knut Stange Osmundsen wrote: > > >>>1. PATH_MAX and MAXPATHLEN #defines are not found. >>> >>>After adding these defines manually I get gnuplot.exe compiled. >> >>MAXPATHLEN is defined in at least three headers. >>PATH_MAX is defined in sys/syslimits.h which may depending of the mode >>be included by limits.h. > > > Yes, seems that sys/syslimits.h gets not included because > __POSIX_VISIBLE is not defined. Not even as '0' The __POSIX_VISIBLE sort of implies that what inside a #if __POSIX_VISIBLE becomes invisible if that define is 0 or undefined. Assuming you're including limits.h, you apparently not requesting posix compatible headers when buildling. (See comment at line 300 in sys/cdefs.h for details on that.) [snip] > The problem now is that gnuplot.exe refuses to spwawn gnupmdrv.exe > > I get: > > G N U P L O T > Version 3.8k patchlevel 2 > ... > Terminal type set to 'pm' > gnuplot> plot x > plot x > Cannot spawn gnupmdrv.exe ! > > Source (pm.trm) is: > ... > spawnmode = P_SESSION | P_DEFAULT; P_SESSION is not implmeneted in LIBC yet, contributions are welcomed. Kind Regards, knut **= Email 5 ==========================** Date: Thu, 18 Mar 2004 15:31:13 +0100 From: Knut Stange Osmundsen Subject: Re: Python & /dev/null John Poltorak wrote: > On Thu, Mar 18, 2004 at 12:59:53PM +0100, Sebastian Wittmeier wrote: > >>On Thu, 18 Mar 2004 02:58:22 -0800 (PST), Steve Wendt wrote: >> >> >>>On Thu, 18 Mar 2004 10:39:19 +0000, John Poltorak wrote: >>> >>> >>>>When running a Python program on OS/2 which attempts to write to >>>>/dev/null, it stops with an IOError - No such file: 'nul:'. >>>> >>>>What can I do about it? >>> >>>Figure out where 'nul:' comes from and replace it with 'nul' probably. >> >>Shouldn't the replacement logic be in the file API? > > > The actual code causing the problem is from Zope:- > > > if not self.cfg.debug_mode: > # prevent startup messages from going to stderr if we're not > # in debug mode > if os.path.exists('/dev/null'): # unix > devnull = '/dev/null' > else: # win32 > devnull = 'nul:' > self.startup_handler = StartupHandler(open(devnull, 'w')) EMX and LIBC only does mapping from /dev/null to nul in open(). Guess this might indicate that doing for some more apis like stat, lstat, access, would make sense. I'll keep it in mind for a later LIBC... :-) Kind Regards, knut **= Email 6 ==========================** Date: Thu, 18 Mar 2004 08:50:18 -0600 From: Dave Webster Subject: Sorry for a dumb question But is there a UnixOS2 service that allows one to connect to remote Xwindows sessions on Linux ala cygwin's xwin -query ? **= Email 7 ==========================** Date: Thu, 18 Mar 2004 16:03:55 +0100 From: "Bart van Leeuwen" Subject: RPM Hi all, is there anyone out there who tried to compile RPM recently ? and if not is there a voulenteer willing to do so ? With Regards Bart van Leeuwen **= Email 8 ==========================** Date: Thu, 18 Mar 2004 15:29:24 +0000 From: John Poltorak Subject: Re: Sorry for a dumb question On Thu, Mar 18, 2004 at 08:50:18AM -0600, Dave Webster wrote: > But is there a UnixOS2 service that allows one to connect to remote Xwindows > sessions on Linux ala cygwin's xwin -query ? I'm no expert on these things, but I thought you connected to a remote system by setting the DISPLAY variable appropriately before running startx... -- John **= Email 9 ==========================** Date: Thu, 18 Mar 2004 08:00:54 -0800 From: "Dave and Natalie" Subject: Re: RPM On Thu, 18 Mar 2004 16:03:55 +0100, Bart van Leeuwen wrote: > >is there anyone out there who tried to compile RPM recently ? >and if not is there a voulenteer willing to do so ? Look at http://www2s.biglobe.ne.jp/~vtgf3mpr/index-e.htm for one port Dave **= Email 10 ==========================** Date: Thu, 18 Mar 2004 07:59:05 -0800 From: "Dave and Natalie" Subject: Re: Sorry for a dumb question On Thu, 18 Mar 2004 08:50:18 -0600, Dave Webster wrote: >But is there a UnixOS2 service that allows one to connect to remote Xwindows >sessions on Linux ala cygwin's xwin -query ? Don't see a xwin.exe in /usr/X11R6/bin. You might want to ask on the XFree86 list. I know there are ways to connect with XDM running on Linux, etc and also IIRC rsh allows remote execution of a command. Me, I connect to my sons Linux box by telnetting into it and opening an xterm, eg xterm -display -192.168.0.1:0 (my box). Have to set up xhosts.0 to allow outside connections or use the xhost command. Dave **= Email 11 ==========================** Date: Thu, 18 Mar 2004 17:01:53 +0100 From: Andreas Buening Subject: Re: Sorry for a dumb question John Poltorak wrote: > > On Thu, Mar 18, 2004 at 08:50:18AM -0600, Dave Webster wrote: > > But is there a UnixOS2 service that allows one to connect to remote Xwindows > > sessions on Linux ala cygwin's xwin -query ? > > I'm no expert on these things, but I thought you connected to a remote > system by setting the DISPLAY variable appropriately before running > startx... I'm not sure about this. xstart -query hostname or similar should work but I haven't done this for a long time. Bye, Andreas **= Email 12 ==========================** Date: Thu, 18 Mar 2004 17:07:43 +0100 From: Andreas Buening Subject: Re: Make error John Poltorak wrote: > > On Thu, Mar 18, 2004 at 10:08:31AM +0100, Andreas Buening wrote: [snip] > > SHELL = /bin/sh > > > > should do the job. > > Unusually, this does not get set in the Makefile, so I set it up in the > environment beforehand but it doesn't seem to make any difference. The environment variable $SHELL is ignored to avoid problems for people who use SHELL=/bin/csh or similar in their working environment. ;-) If you don't want to add SHELL=/bin/sh to the Makefile (which should be done sooner or later), you can set MAKESHELL instead. Bye, Andreas **= Email 13 ==========================** Date: Thu, 18 Mar 2004 07:57:04 -0800 From: "Dave and Natalie" Subject: Re: Python & /dev/null On Thu, 18 Mar 2004 15:04:59 +0100 (CET), Sebastian Wittmeier wrote: >On Thu, 18 Mar 2004 04:55:38 -0800 (PST), Steve Wendt wrote: > >>If you don't like my previous suggestion, you could use \dev\nul instead. > >So >os.path.exists('/dev/null') returns false, and >os.path.exists('\dev\null') returns true? > >Should os.path.exists() accept both slashes, or should Zope look up the >directory separators of the local system? According to Alexs porting faq *The null device is called /dev/null under Unix. The __open() system call translates the filenames /dev/null and /dev/tty (lowercase, with slashes) to nul and con, respectively. However system ("whatever >/dev/null"); won't work as the standard OS/2 interpreter (cmd.exe) doesn't recognize "/dev/null" (see system()) Dave **= Email 14 ==========================** Date: Thu, 18 Mar 2004 16:29:57 +0000 From: John Poltorak Subject: Re: Make error On Thu, Mar 18, 2004 at 05:07:43PM +0100, Andreas Buening wrote: > John Poltorak wrote: > The environment variable $SHELL is ignored to avoid problems for people > who use SHELL=/bin/csh or similar in their working environment. ;-) > > If you don't want to add SHELL=/bin/sh to the Makefile (which should > be done sooner or later), you can set MAKESHELL instead. Thanks for that. Setting MAKESHELL does work, but SHELL didn't. > Bye, > Andreas -- John **= Email 15 ==========================** Date: Thu, 18 Mar 2004 10:31:37 -0600 From: Dave Webster Subject: [wxOS2] Stefan, question on your build environment Trying get past this ./bk-deps bug I am having. Basically it blows up my command interpreter. Do you compile wxWidgets (notice I am now calling it by it's new name) completely inside your Unix on OS/2 environment. In other words where do you put your CVS sources? /usr/src/wxWindows or something? My problem may be that my UnixOS2 is actually set up on my "D:" drive but my wx sources are downloaded to a network drive, "H:". So I go to H:\WX25\wxWindows\build\pm and execute bash (or ash or whatever) and then .../../configure ..... then make. make blows up the cmd.exe unless I remove the .bk-deps stuff from the CXX build line. Bk-deps gets all dorked on it's paths, expecting all Unix-like paths I am guessing? I assume I could "mount" H:\WX25\wxWindows to /usr/src/wxWindows or something? **= Email 16 ==========================** Date: Thu, 18 Mar 2004 16:54:46 +0100 From: Andreas Buening Subject: Re: Make 3.81beta1 (was: Make 3.80) John Poltorak wrote: [snip] > a beta of 3.81 has just come out. Maybe this builds on OS/2... After a tiny configure.in fix, yes. You can try the latest binary on http://unix.os2site.com/sw/pub/binary/make/make-3.81beta-bin-test.zip Sources with extra patches will be released soon. :-) The following bugs should have been fixed: - make runs out of file handles - in cmd-mode upper case builtin commands like 'DEL' don't work - unexpected SYS1041 in some cases in cmd mode - Code for command line handling of cmd rewritten. I think especially the last point is interesting for those of you who often use cmd in Makefiles. I don't know whether the new cmd handling code is better than the old one since I don't use complicated cmd command lines in Makefiles. ;-) Bye, Andreas **= Email 17 ==========================** Date: Thu, 18 Mar 2004 17:18:10 +0000 From: John Poltorak Subject: Re: Python & /dev/null On Thu, Mar 18, 2004 at 03:31:13PM +0100, Knut Stange Osmundsen wrote: > John Poltorak wrote: > > > > The actual code causing the problem is from Zope:- > > > > > > if not self.cfg.debug_mode: > > # prevent startup messages from going to stderr if we're not > > # in debug mode > > if os.path.exists('/dev/null'): # unix > > devnull = '/dev/null' > > else: # win32 > > devnull = 'nul:' > > self.startup_handler = StartupHandler(open(devnull, 'w')) > > EMX and LIBC only does mapping from /dev/null to nul in open(). Guess > this might indicate that doing for some more apis like stat, lstat, > access, would make sense. I'll keep it in mind for a later LIBC... :-) Can some translate what this code is actually doing? Is "os.path.exists('/dev/null')" basically a stat() What should I change this code to:- ? # in debug mode if os.path.exists('/dev/null'): # unix devnull = '/dev/null' else: # win32 devnull = 'nul:' As far as OS/2 is concerned, 'devnull' should be getting set to '/dev/null' to work correctly later in the code. Should I just remove the other three lines? > Kind Regards, > knut -- John **= Email 18 ==========================** Date: Thu, 18 Mar 2004 18:10:43 +0100 From: "Bart van Leeuwen" Subject: Re: RPM On 18-03-2004 17:00:54 owner-os2-unix wrote: >On Thu, 18 Mar 2004 16:03:55 +0100, Bart van Leeuwen wrote: > >> >>is there anyone out there who tried to compile RPM recently ? >>and if not is there a voulenteer willing to do so ? > >Look at http://www2s.biglobe.ne.jp/~vtgf3mpr/index-e.htm for one port >Dave i've seen that, email doesn't work anymore, the port is outdated and it relies on EMX I would prefer a innotek gcc one... Bart **= Email 19 ==========================** Date: Thu, 18 Mar 2004 18:06:06 +0000 From: John Poltorak Subject: Re: RPM On Thu, Mar 18, 2004 at 04:03:55PM +0100, Bart van Leeuwen wrote: > > Hi all, > > is there anyone out there who tried to compile RPM recently ? > and if not is there a voulenteer willing to do so ? Have you tried? > With Regards > Bart van Leeuwen -- John **= Email 20 ==========================** Date: Thu, 18 Mar 2004 18:49:45 +0000 From: John Poltorak Subject: Recursive delete with rm Should I expect to be able to make a recursive delete using RM of files using a wildcard? I find that rm -r *.c will not recurse into subdirectories. Is this normal? -- John **= Email 21 ==========================** Date: Thu, 18 Mar 2004 19:55:04 +0000 From: John Poltorak Subject: Re: RPM On Thu, Mar 18, 2004 at 06:10:43PM +0100, Bart van Leeuwen wrote: > > On 18-03-2004 17:00:54 owner-os2-unix wrote: > > >On Thu, 18 Mar 2004 16:03:55 +0100, Bart van Leeuwen wrote: > > > >> > >>is there anyone out there who tried to compile RPM recently ? > >>and if not is there a voulenteer willing to do so ? > > > >Look at http://www2s.biglobe.ne.jp/~vtgf3mpr/index-e.htm for one port > >Dave > > i've seen that, email doesn't work anymore, the port is outdated and it > relies on EMX I would prefer a innotek gcc one... I thought everything relied on EMXRT.... Is this the latest source:- ? ftp://ftp.rpm.org/pub/rpm/dist/rpm-4.1.x/rpm-4.1.tar.gz > Bart > > -- John **= Email 22 ==========================** Date: Thu, 18 Mar 2004 21:09:52 +0100 (CET) From: "Sebastian Wittmeier" Subject: Re: Recursive delete with rm On Thu, 18 Mar 2004 18:49:45 +0000, John Poltorak wrote: >I find that rm -r *.c will not recurse into subdirectories. Is this >normal? yes, it's normal. rm -r *.c only deletes c-files in your local directory and directories with the ending .c find . -type f -name \*.c -exec rm {} \; or something similar should work the way you want. Sebastian **= Email 23 ==========================** Date: Thu, 18 Mar 2004 14:18:03 -0600 From: don Subject: Re: Recursive delete with rm That works with the version of rm that I have running on OS/2 and that is what is in the rm man pages under Mandrake Linux. On Thursday 18 March 2004 12:49 pm, John Poltorak wrote: > Should I expect to be able to make a recursive delete using RM of files > using a wildcard? **= Email 24 ==========================** Date: Thu, 18 Mar 2004 21:18:58 +0100 (CET) From: "Sebastian Wittmeier" Subject: Re: Python & /dev/null On Thu, 18 Mar 2004 17:18:10 +0000, John Poltorak wrote: >Is "os.path.exists('/dev/null')" basically a stat() yes >As far as OS/2 is concerned, 'devnull' should be getting set to >'/dev/null' to work correctly later in the code. Should I just remove the >other three lines? breaks the code on win32, but who cares ;-) or wait for the next Innotek libc beta (as Knut indicated) Sebastian **= Email 25 ==========================** Date: Thu, 18 Mar 2004 20:23:59 +0000 From: John Poltorak Subject: .pod files Can anyone tell me what you are supposed to do with .pod format files? I understand they are some sort of Perl document files, but what are you supposed to use to read them? -- John **= Email 26 ==========================** Date: Thu, 18 Mar 2004 20:31:40 +0000 From: John Poltorak Subject: Re: Recursive delete with rm On Thu, Mar 18, 2004 at 02:18:03PM -0600, don wrote: > > That works with the version of rm that I have running on OS/2 and > that is what is in the rm man pages under Mandrake Linux. Which version of rm is this? > On Thursday 18 March 2004 12:49 pm, John Poltorak wrote: > > Should I expect to be able to make a recursive delete using RM of files > > using a wildcard? > > -- John **= Email 27 ==========================** Date: Thu, 18 Mar 2004 21:43:58 +0100 (CET) From: "Adrian Gschwend" Subject: Re: RPM On Thu, 18 Mar 2004 19:55:04 +0000, John Poltorak wrote: >> i've seen that, email doesn't work anymore, the port is outdated and it >> relies on EMX I would prefer a innotek gcc one... > >I thought everything relied on EMXRT.... he talks of a port with Innotek libc as well, not just GCC 3.2 >Is this the latest source:- ? > >ftp://ftp.rpm.org/pub/rpm/dist/rpm-4.1.x/rpm-4.1.tar.gz I would say so yes cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 28 ==========================** Date: Thu, 18 Mar 2004 20:35:37 +0000 From: John Poltorak Subject: Re: Python & /dev/null On Thu, Mar 18, 2004 at 09:18:58PM +0100, Sebastian Wittmeier wrote: > On Thu, 18 Mar 2004 17:18:10 +0000, John Poltorak wrote: > > >Is "os.path.exists('/dev/null')" basically a stat() > > yes > > >As far as OS/2 is concerned, 'devnull' should be getting set to > >'/dev/null' to work correctly later in the code. Should I just remove the > >other three lines? > > breaks the code on win32, but who cares ;-) Well it is simply a patch for OS/2. I'm not proposing to have it incorporated in the original source code. > or wait for the next Innotek libc beta (as Knut indicated) Knut's solution is ideal really because we can have it working on OS/2 without any source code changes in the original. > Sebastian -- John **= Email 29 ==========================** Date: Thu, 18 Mar 2004 15:43:30 -0500 From: Henry Sobotka Subject: Re: .pod files John Poltorak wrote: > > Can anyone tell me what you are supposed to do with .pod format files? > > I understand they are some sort of Perl document files, but what are you > supposed to use to read them? You can feed them to perldoc or convert them with any of the pod2[man|text|html|latex...] scripts. h~ **= Email 30 ==========================** Date: Thu, 18 Mar 2004 15:59:42 -0500 (EST) From: Thomas Dickey Subject: Re: .pod files On Thu, 18 Mar 2004, John Poltorak wrote: > > Can anyone tell me what you are supposed to do with .pod format files? > > I understand they are some sort of Perl document files, but what are you > supposed to use to read them? perl's pod2man or pod2text -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 31 ==========================** Date: Thu, 18 Mar 2004 14:58:26 -0800 From: "Dave and Natalie" Subject: Fluxbox and unresolved symbols Hi, I'm trying to build the latest Fluxbox 0.9.8 (if anyone is interested I have 0.9.0 working) and get this error at the end of the build fluxbox.o: Undefined symbol __ZN4FbTk8ResourceImE13setFromStringEPKc referenced from data segment fluxbox.o: Undefined symbol __ZN4FbTk8ResourceImE9getStringEv referenced from data segment Further investigation finds these functions src/FbTk/resource.hh but they are not included in libfbtk.a These are the public parts of resource.hh class XrmDatabaseHelper; /// Base class for resources, this is only used in ResourceManager class Resource_base:private FbTk::NotCopyable { public: virtual ~Resource_base() { }; /// set from string value virtual void setFromString(char const *strval) = 0; /// set default value virtual void setDefaultValue() = 0; /// get string value virtual std::string getString() = 0; /// get alternative name of this resource inline const std::string& altName() const { return m_altname; } /// get name of this resource inline const std::string& name() const { return m_name; } protected .... class Resource:public Resource_base { public: Resource(ResourceManager &rm, T val, const std::string &name, const std::string &altname): Resource_base(name, altname), m_value(val), m_defaultval(val), m_rm(rm) { m_rm.addResource(*this); // add this to resource handler } virtual ~Resource() { m_rm.removeResource(*this); // remove this from resource handler } inline void setDefaultValue() { m_value = m_defaultval; } /// sets resource from string, specialized, must be implemented void setFromString(const char *strval); inline Resource& operator = (const T& newvalue) { m_value = newvalue; return *this;} /// specialized, must be implemented /// at return string value of resource std::string getString(); inline T& operator*() { return m_value; } inline const T& operator*() const { return m_value; } inline T *operator->() { return &m_value; } inline const T *operator->() const { return &m_value; } private: T m_value, m_defaultval; ResourceManager &m_rm; }; // add the resource and load its value template void ResourceManager::addResource(Resource &r) { m_resourcelist.push_back(&r); m_resourcelist.unique(); // lock ensures that the database is loaded. lock(); if (m_database == 0) { unlock(); return; } XrmValue value; char *value_type; // now, load the value for this resource if (XrmGetResource(**m_database, r.name().c_str(), r.altName().c_str(), &value_type, &value)) r.setFromString(value.addr); } else { std::cerr<<"Failed to read: "< Subject: Re: Fluxbox and unresolved symbols Dave and Natalie wrote: > > /// sets resource from string, specialized, must be implemented > void setFromString(const char *strval); > /// specialized, must be implemented > /// at return string value of resource > std::string getString(); > Does anyone have any idea what needs to be changed so these functions > are exported in libFbTk.a? They have to be implemented? h~ -- Free software, free minds. **= Email 33 ==========================** Date: Fri, 19 Mar 2004 01:05:13 +0100 (CET) From: Stefan Neis Subject: Re: Python & /dev/null On Thu, 18 Mar 2004, Knut Stange Osmundsen wrote: > > if os.path.exists('/dev/null'): # unix > > devnull = '/dev/null' > > else: # win32 > > devnull = 'nul:' > > self.startup_handler = StartupHandler(open(devnull, 'w')) > > EMX and LIBC only does mapping from /dev/null to nul in open(). Guess > this might indicate that doing for some more apis like stat, lstat, > access, would make sense. I'll keep it in mind for a later LIBC... :-) Alternatively/additionally, mapping nul: to nul as well might be another way to make that particular piece of code happy... Regards, Stefan **= Email 34 ==========================** Date: Fri, 19 Mar 2004 01:01:46 +0100 (CET) From: Stefan Neis Subject: Re: Make error On Thu, 18 Mar 2004, T.Sikora wrote: > > "U:\USR\BIN\PYTHON.EXE" "U:/unixos2/workdir/Zope-2.7.0/setup.py" \ (snipp) > Configure writes the make file wrong. Just go in and change the path for > python. Or even try (assuming it can be found via path) python=python.exe path_to_configure/configure .... Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 35 ==========================** Date: Fri, 19 Mar 2004 01:12:17 +0100 (CET) From: Stefan Neis Subject: Re: Python & /dev/null On Thu, 18 Mar 2004, John Poltorak wrote: > What should I change this code to:- ? Maybe this (Note the 'nul' instead of 'nul:'): # in debug mode if os.path.exists('/dev/null'): # unix devnull = '/dev/null' else: # win32 devnull = 'nul' > As far as OS/2 is concerned, 'devnull' should be getting set to > '/dev/null' or 'nul', AFAIK, but _not_ 'nul:' > to work correctly later in the code. That way, it _might_ even continue to work on Win32, unless they really insist on 'nul:', but seeing where they come from, this would seem inconsistent (but then again, it's Microsoft...). Stefan **= Email 36 ==========================** Date: Fri, 19 Mar 2004 08:54:00 +1100 (EST) From: Andrew MacIntyre Subject: Re: Python & /dev/null On Thu, 18 Mar 2004, John Poltorak wrote: > The actual code causing the problem is from Zope:- > > > if not self.cfg.debug_mode: > # prevent startup messages from going to stderr if we're not > # in debug mode > if os.path.exists('/dev/null'): # unix > devnull = '/dev/null' > else: # win32 > devnull = 'nul:' > self.startup_handler = StartupHandler(open(devnull, 'w')) I'm surprised that 'nul:' doesn't work, but I just checked - it has to be 'nul' :-( Try making that code look like: if os.path.exists('/dev/null'): # unix devnull = '/dev/null' elif os.name == 'os2': devnull = 'nul' else: # win32 devnull = 'nul:' self.startup_handler = StartupHandler(open(devnull, 'w')) Regards, Andrew. -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac at bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac at pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia **= Email 37 ==========================** Date: Fri, 19 Mar 2004 01:17:18 +0100 (CET) From: Stefan Neis Subject: Re: RPM On Thu, 18 Mar 2004, Bart van Leeuwen wrote: > i've seen that, email doesn't work anymore, the port is outdated and it > relies on EMX I would prefer a innotek gcc one... Just being curious: Why? Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 38 ==========================** Date: Fri, 19 Mar 2004 01:21:09 +0100 (CET) From: Stefan Neis Subject: Re: Recursive delete with rm On Thu, 18 Mar 2004, John Poltorak wrote: > Should I expect to be able to make a recursive delete using RM of files > using a wildcard? > > > I find that rm -r *.c will not recurse into subdirectories. Is this > normal? Yes, it is. The "normal", unix-like way to do that would be e.g. find . -name '*.c' -exec rm \{} \; If you're calling that command from cmd.exe instead of from a unix-like shell, some less quoting is required: find . -name *.c -exec rm {} ; HTH, Stefan **= Email 39 ==========================** Date: Fri, 19 Mar 2004 01:21:09 +0100 (CET) From: Stefan Neis Subject: Re: Recursive delete with rm On Thu, 18 Mar 2004, John Poltorak wrote: > Should I expect to be able to make a recursive delete using RM of files > using a wildcard? > > > I find that rm -r *.c will not recurse into subdirectories. Is this > normal? Yes, it is. The "normal", unix-like way to do that would be e.g. find . -name '*.c' -exec rm \{} \; If you're calling that command from cmd.exe instead of from a unix-like shell, some less quoting is required: find . -name *.c -exec rm {} ; HTH, Stefan **= Email 40 ==========================** Date: Thu, 18 Mar 2004 20:40:04 -0800 (PST) From: "Steve Wendt" Subject: Re: Python & /dev/null On Thu, 18 Mar 2004 07:57:04 -0800, Dave and Natalie wrote: >>os.path.exists('\dev\null') returns true? >> >won't work as the standard OS/2 interpreter (cmd.exe) doesn't recognize >"/dev/null" (see system()) But it does recognize \dev\nul (NOT \dev\null). ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.) **= Email 41 ==========================** Date: Thu, 18 Mar 2004 20:44:46 -0800 (PST) From: "Steve Wendt" Subject: Re: Python & /dev/null On Fri, 19 Mar 2004 01:12:17 +0100 (CET), Stefan Neis wrote: >Maybe this (Note the 'nul' instead of 'nul:'): Just what I said in the very first response. ;) > else: # win32 > devnull = 'nul' > >That way, it _might_ even continue to work on Win32, unless they really >insist on 'nul:', but seeing where they come from, this would seem >inconsistent (but then again, it's Microsoft...). Yes, 'nul' also works on DOS and Win32. Whoever chose 'nul:' made a bad choice, in my opinion... ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.) **= Email 42 ==========================** Date: Thu, 18 Mar 2004 22:09:02 -0800 From: "Dave and Natalie" Subject: Re: Fluxbox and unresolved symbols On Thu, 18 Mar 2004 18:34:32 -0500, Henry Sobotka wrote: >Dave and Natalie wrote: >> >> /// sets resource from string, specialized, must be implemented >> void setFromString(const char *strval); > >> /// specialized, must be implemented >> /// at return string value of resource >> std::string getString(); > >> Does anyone have any idea what needs to be changed so these functions >> are exported in libFbTk.a? > >They have to be implemented? I guess you're right Its weird, 0.9.0 has just about the same code accepting it is in src and directly linked and this is in src/FbTk and is linked to libFbTk.a. 0.9.0 links fine whereas 0.9.8 gives these unresolved symbols. I just tried building with 3.2.2 and the build finished fine, no unresolved symbols so I'd say its a GCC 3.2.1 bug. Wonder what would be a workaround? PGCC dies with this error Remember.cc: In method `int Remember::parseApp(ifstream &, Application &, string * = 0)': Remember.cc:338: no matching function for call to `istrstream::istrstream ()' E:/EMX/lib/gcc-lib/i386-pc-os2_emx/pgcc-2.95.2/../../../../include/g++-3/strstream.h:89: candidates are: istrstream::istrstream(const char *, int = 0) E:/EMX/lib/gcc-lib/i386-pc-os2_emx/pgcc-2.95.2/../../../../include/g++-3/strstream.h:90: istrstream::istrstream(const istrstream &) Remember.cc:354: no matching function for call to `istrstream::str (string &)' Remember.cc:359: no matching function for call to `istrstream::str (const char *)' Which I guess is due to a nonexisting function. I really don't understand C++ too much Dave **= Email 43 ==========================** Date: Fri, 19 Mar 2004 10:46:10 +0100 (CET) From: "Adrian Gschwend" Subject: Re: RPM On Fri, 19 Mar 2004 01:17:18 +0100 (CET), Stefan Neis wrote: >> i've seen that, email doesn't work anymore, the port is outdated and it >> relies on EMX I would prefer a innotek gcc one... > >Just being curious: Why? Bart and I had some discussions about the future of OS/2 installers. We do have WarpIN but even Ulrich Möller says that WarpIN should basically be rewritten. I did use WarpIN quite a lot for some time but there are some very nasty bugs in it, the XML-like package format is not full XML and WarpIN gives you as good as no help if the syntax in the file is broken. Also we do not have a packet manager that can fetch packages online as we know it from Linux and with Winows-update even from Windows nowadays. So instead of rewriting WarpIN and reinventing the wheel we started to look around. RPM seems to be technically the most advanced packet manager for binary packages, the dependencies seem to work just fine, there are nice packet managers (apt for RPM for example) and you can even sign your packets. Now we think about adding some stuff for registering WPS-classes, changing CONFIG.SYS and other OS/2 specific stuff and go for RPM as a core installer of a OS/2 based product some of you might know :-) That's why we would like to have the latest one. Also I don't think that investing time into anything else than Innotek LIBC is a good idea nowadays. EMX should be replaced. period :-) cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 44 ==========================** Date: Fri, 19 Mar 2004 10:20:23 +0000 From: John Poltorak Subject: Re: RPM On Fri, Mar 19, 2004 at 10:46:10AM +0100, Adrian Gschwend wrote: > So instead of rewriting WarpIN and reinventing the wheel we started to > look around. RPM seems to be technically the most advanced packet > manager for binary packages, the dependencies seem to work just fine, > there are nice packet managers (apt for RPM for example) and you can > even sign your packets. We have discussed package managers before on this list and ISTR that the one used by Slackware was as good as any... What I am looking for is a way of creating packages from the original source. I can build quite a number using UX2BS, but I would like to build packages for distribution as an alternative to installing them, but have no idea how to set about it. I guess I need some target like 'make package'. I wondered how this was handled in the creation of RPMs... > Now we think about adding some stuff for registering WPS-classes, > changing CONFIG.SYS and other OS/2 specific stuff and go for RPM as a > core installer of a OS/2 based product some of you might know :-) > > That's why we would like to have the latest one. Also I don't think > that investing time into anything else than Innotek LIBC is a good idea > nowadays. EMX should be replaced. period :-) EMX is so firmly established that you would be unable to replace it for many years. There are already so many conflicts because of different compilers, headers, libs, dlls etc that a replacement for EMX would be difficult to manage. Also with Innotek's LIBC, I'm not keen on having to change my version every couple of months. > cu > > Adrian > > > -- > Adrian Gschwend > at netlabs.org > > ktk [a t] netlabs.org > ------- > Free Software for OS/2 and eCS > http://www.netlabs.org > -- John **= Email 45 ==========================** Date: Fri, 19 Mar 2004 10:23:10 +0000 From: John Poltorak Subject: checking for pnmcut... missing Whilst building GROFF, configure checks for pnmcut but doesn't find it. Anyone know what it is or where to find it? -- John **= Email 46 ==========================** Date: Fri, 19 Mar 2004 11:01:05 +0000 From: John Poltorak Subject: Perl 5.8.3 In case anyone is relying on Perl 5.8.3 working properly, you may be interested to know that some OS/2 patches were missed out in the distributed source. You can get them from:- http://math.berkeley.edu/~ilya/software/tmp/diff_582_21574_file_find -- John **= Email 47 ==========================** Date: Fri, 19 Mar 2004 13:41:51 +0100 (CET) From: Stefan Neis Subject: Re: RPM On Fri, 19 Mar 2004, John Poltorak wrote: > EMX is so firmly established that you would be unable to replace it for > many years. But it's limitations with respect to C++ support become more and more of a problem, so if we want to compile current C++ code, there's not much be can do but replace it... > difficult to manage. Also with Innotek's LIBC, I'm not keen on having to > change my version every couple of months. Once "all" features are implemented, the change rate should go back to normal. Actually, I even prefer getting a new versions every couple of months over _never_ getting a new feature included (stdint.h and similar stuff). Regards, Stefan