From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Mon, 10 Feb 2003 04:53:13 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 40 ************************************************** Sunday 09 February 2003 Number 40 ************************************************** Subjects for today 1 Re: CVS v 1.12.0.1 : Stefan Neis 2 CVS v 1.12.0.1 : Andrew Belov" 3 Re: Linking and forking and flags, ayup. : Andrew MacIntyre 4 Re: CVS v 1.12.0.1 : John Poltorak 5 Re: perl help : Dave Saville" 6 Re: CVS v 1.12.0.1 : Andrew Belov" 7 Re: CVS v 1.12.0.1 : Andrew Belov" 8 Re: fetchmail 6.2.1 patch : John Poltorak 9 Re: Linking and forking and flags, ayup. : Andrew MacIntyre **= Email 1 ==========================** Date: Mon, 10 Feb 2003 00:57:51 +0100 (CET) From: Stefan Neis Subject: Re: CVS v 1.12.0.1 On Mon, 10 Feb 2003, Andrew Belov wrote: > only the binaries built with "-O1" survive > the sanity test, while GCC v 3.2.1-20021208 in Slackware yields a much faster and > smaller "-O2" optimized executable. Any idea on "standard" gcc-2.8.1? It should procude reliable results even with -O2 and even it the optimizer does not play quite as many tricks as in gcc-3, it should still easily beat an compile with "-O1". Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 2 ==========================** Date: Mon, 10 Feb 2003 02:16:13 +0300 (MSK) From: "Andrew Belov" Subject: CVS v 1.12.0.1 I'm uploading an "EMX-new" port of CVS v 1.12.0.1 (actually, todays CVS-current snapshot). It hasn't been tested beyond the standard "sanity check" script, so hidden bugs may be there - considering that the sanity script only checks several specific cases of the past history, they most likely are. Get it at ftp://ftp.os2ports.com/incoming/cvs11201.zip. Bug-reports are welcome on the RSH/SSH interfaces, as these have always been a "grey area" of the EMX-new port. And we still need a newer GCC - with 3.0.3, only the binaries built with "-O1" survive the sanity test, while GCC v 3.2.1-20021208 in Slackware yields a much faster and smaller "-O2" optimized executable. **= Email 3 ==========================** Date: Mon, 10 Feb 2003 08:27:56 +1000 (est) From: Andrew MacIntyre Subject: Re: Linking and forking and flags, ayup. On Sun, 9 Feb 2003, Jeff Robinson wrote: > While the executable I end up with requires: > Loading DLL 'emx' --> F:\EMX\DLL\EMX.DLL. > Loading DLL 'EMXLIBCM' --> F:\EMX\DLL\EMXLIBCM.DLL. > Loading DLL 'doscalls' --> loaded. > Loading DLL 'quecalls' --> E:\OS2\DLL\QUECALLS.DLL. > Loading DLL 'sesmgr' --> E:\OS2\DLL\SESMGR.DLL. > Loading DLL 'pmshapi' --> E:\OS2\DLL\PMSHAPI.DLL. > Loading DLL 'pmwin' --> E:\OS2\DLL\PMWIN.DLL. > Loading DLL 'gcc303m' --> F:\EMX\DLL\GCC303M.DLL. ^^^^^^^ This is a pet peeve of mine - if you must link to the DLL version of this library (the gcc helper library), please distribute it in the binary archive so that users don't have to D/L the gcc archive to get it. > Loading DLL 'viocalls' --> E:\OS2\DLL\VIOCALLS.DLL. > Any hints on what approach I need to get over this hurdle? As Henry said, try without the multithreading. fork() seems to work Ok in Python, but it definitely is sensitive to availability of memory (and/or address space). The description of the process in the EMX docs makes depressing reading. AndyZ also posted on this issue IIRC. -- 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 4 ==========================** Date: Mon, 10 Feb 2003 08:55:23 +0000 From: John Poltorak Subject: Re: CVS v 1.12.0.1 On Mon, Feb 10, 2003 at 11:32:13AM +0300, Andrew Belov wrote: > On Mon, 10 Feb 2003 00:57:51 +0100 (CET), Stefan Neis wrote: > > >On Mon, 10 Feb 2003, Andrew Belov wrote: > > > >> only the binaries built with "-O1" survive > >> the sanity test, while GCC v 3.2.1-20021208 in Slackware yields a much > faster and > >> smaller "-O2" optimized executable. > > > >Any idea on "standard" gcc-2.8.1? It should procude reliable results even > >with -O2 and even it the optimizer does not play quite as many tricks as > >in gcc-3, it should still easily beat an compile with "-O1". > > Previously I've found "-O2 -fno-expensive-optimizations" pretty much reliable, > so CVS seems to be the only exception so far. That said, it's not worth going > back to 2.8.1/2.7.2.3 when the most of performance-sensitive apps (e.g. ARJ) > are already compiled here with 3.0.3. Will it actually build with 2.8.1? And should I be able to build it straight from the original source? -- John **= Email 5 ==========================** Date: Mon, 10 Feb 2003 10:56:17 +0000 (GMT) From: "Dave Saville" Subject: Re: perl help On Sun, 09 Feb 2003 14:27:18 -0500, Henry Sobotka wrote: >Dave Saville wrote: >> >> exec is no good I don't want to loose control. In any case its not >> wether system forks that is the problem its some damn parsing going >> on somewhere that fails when it sees *any* kind of bracket in the >> command string. Run sans brackets and perl will try and run the >> command - with, and it never gets off the ground. > >Here > >my $sec = 49; >my at sysargs = ("f program", "set(#sunrise=$sec)"); >my $rc = system at sysargs; >print $rc; > >gives me -1 (obviously); and changing "f program" to "echo" produces: > >set(#sunrise=49) >0 > Thanks a bunch Henry - I was going up the wall - This used to work and still does on Solaris. I had to hack your line as you swapped "f program," for echo when it should have been just the f, the "program," bit was crucial. (It is a program we wrote ages ago to mimic on *nix an operator interface called "Stop Modify Processing" from MVS. The modify command "f" - don't ask :-) - takes a comma separated list of parameters, the first is the program to send the rest of the arguments to. Basically it lets the operator control running processes without the process having to wait on a console reply. The program justs registers with a pseudo system service - Think of it like a clipboard viewer. Naturally I ported the lot to OS/2 :-) ) The following works on both versions of perl I have installed. Wonder what changed? - it did work before - honest :-) system "f", "program,", "set(#sunrise=$sec)"; And in case anyone wonders the significance of "sunrise" above. Some of you may know that I control my house with OS/2 - Designed and wrote all the code. As Maplin ceased production of a "dusk" sensor about the time I wrote the code I needed some way to know if it was dark - for lighting logic. I decided that sunrise and sunset times were good enough - then tried to find out the calculation. A quick bit of lateral thinking suggested that there would be a perl module for this - and there was. One look at the math - ouch in spades - not rewriting *that* in REXX ;-). So my "cron" program runs the perl script that needs to talk to the house control. QED -- Regards Dave Saville **= Email 6 ==========================** Date: Mon, 10 Feb 2003 11:32:13 +0300 (MSK) From: "Andrew Belov" Subject: Re: CVS v 1.12.0.1 On Mon, 10 Feb 2003 00:57:51 +0100 (CET), Stefan Neis wrote: >On Mon, 10 Feb 2003, Andrew Belov wrote: > >> only the binaries built with "-O1" survive >> the sanity test, while GCC v 3.2.1-20021208 in Slackware yields a much faster and >> smaller "-O2" optimized executable. > >Any idea on "standard" gcc-2.8.1? It should procude reliable results even >with -O2 and even it the optimizer does not play quite as many tricks as >in gcc-3, it should still easily beat an compile with "-O1". Previously I've found "-O2 -fno-expensive-optimizations" pretty much reliable, so CVS seems to be the only exception so far. That said, it's not worth going back to 2.8.1/2.7.2.3 when the most of performance-sensitive apps (e.g. ARJ) are already compiled here with 3.0.3. By the way, we'd probably have to package CVS with GCC303S.DLL it requires. For those wishing to try out the current release, having this DLL is prerequisite. It will be prepackaged in the final 1.12 release. **= Email 7 ==========================** Date: Mon, 10 Feb 2003 14:20:44 +0300 (MSK) From: "Andrew Belov" Subject: Re: CVS v 1.12.0.1 On Mon, 10 Feb 2003 08:55:23 +0000, John Poltorak wrote: >> Previously I've found "-O2 -fno-expensive-optimizations" pretty much reliable, >> so CVS seems to be the only exception so far. That said, it's not worth going >> back to 2.8.1/2.7.2.3 when the most of performance-sensitive apps (e.g. ARJ) >> are already compiled here with 3.0.3. > >Will it actually build with 2.8.1? Version 1.11 did. >And should I be able to build it straight from the original source? No, the library in EMX subdirectory is quite outdated - implementations of several routines are missing. Must be quite a simple "cut+paste" job to get them back but there is the EMX-NEW patch already. **= Email 8 ==========================** Date: Mon, 10 Feb 2003 21:39:24 +0000 From: John Poltorak Subject: Re: fetchmail 6.2.1 patch On Mon, Feb 03, 2003 at 04:39:50PM +0100, Yuri Dario wrote: > Hi, > > this weekend I changed mail handling on my server, so I had to update my fetchmail installation. > By the way I moved code from 5.9.5 to last 6.2.1, and fixed a couple of things in daemon mode. > > I have zipped a binary together with patches as > > http://os2power.dnsalias.com/yuri/software/fetchmail621b1.zip (185kb) What do you need to do to rebuild it? Is it just a matter of adding the patch and then running configure and make? > Bye, > > Yuri Dario > > /* > * member of TeamOS/2 - Italy > * http://www.quasarbbs.net/yuri > * http://www.teamos2.it > * http://www.opera.com/os2/ > */ -- John **= Email 9 ==========================** Date: Mon, 10 Feb 2003 22:50:41 +1000 (est) From: Andrew MacIntyre Subject: Re: Linking and forking and flags, ayup. On Sun, 9 Feb 2003, Jeff Robinson wrote: > Henry Sobotka wrote: > > >Jeff Robinson wrote: > > > > > >>Once I compiled bash as being single-threaded, the need for gcc303m > >>disappeared (as well as the obvious need for emxlibcm), so that solves > >>that nicely. Now just the generation of the diffs, and then I'll see > >>what kind've mess I can really make! > >> > >> > > > >Are you sure it doesn't need gcc303s.dll? Which you can avoid by linking > >with -lgcc. > > > >h~ > > > > > Yup, I checked it out and with chkdll32 (even using -l) and it doesn't > list any more "non-core" libraries other than EMX itself. > > This also brings my list back in line with exactly what the port I was > working against had, leaving me with that warm and fuzzy feeling. Like > toasted mold. If you want to try the multithread version again without the emxlibcm.dll (and by inference, the gcc303m.dll), use -Zmt instead of -Zmtd. -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac at bullseye.apana.org.au | Snail: PO Box 370 andymac at pcug.org.au | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia