From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Tue, 5 Nov 2002 04:40:39 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 363 ************************************************** Monday 04 November 2002 Number 363 ************************************************** Subjects for today 1 Re: gettext 0.11.5 : Franz Bakan" 2 Re: buildin perl 5.8: signals : Dave Saville" 3 Re: New OpenSSH for OS/2 : Steve Wendt 4 New OpenSSH for OS/2 : John Poltorak 5 Re: FTP access, was Some news : Stefan Neis 6 Re: buildin perl 5.8: signals : Yuri Dario" 7 Re: buildin perl 5.8: signals : John Poltorak 8 Perl 5.7 / Perl 5.8 and fork() : edgue at web.de 9 Re: buildin perl 5.8: signals : Yuri Dario" 10 Re: buildin perl 5.8: signals : Csaba" 11 Re: gettext 0.11.5 : Andreas Buening 12 Re: gettext 0.11.5 : Sebastian Wittmeier (ShadoW)" **= Email 1 ==========================** Date: Tue, 05 Nov 2002 01:18:25 +0100 (CET) From: "Franz Bakan" Subject: Re: gettext 0.11.5 On Wed, 30 Oct 2002 01:05:08 +0100, Andreas Buening wrote: ... >So, I've just uploaded the next trial (0.11.5 release 2). ;-) the older make-version now works too, but grep (GNU grep) 2.4 still ends with SIGSEGV It also works here for compiling SANE-CVS In one case I got the following warning: msgcat: warning: Input files contain messages in different encodings, ISO-8859-15 and ISO-8859-1 among others. Converting the output to UTF-8. To select a different output encoding, use the --to-code option I assume that older intl.dll's cant deal with UTF-8. So there is a backward-compatibility-problem. Is there a ENV-Variable (instead of the --to-code option) for msgcat that forces converting to a different format? Or if not perhaps this would be useful to implement in a next version of gettext for OS/2 to avoid manual changes in makefiles. >Compatibility: Some binary versions of intl.dll have been compiled >by hand using "export by ordinal". Well, A.Z. allready automated this additional 'exporting by ordinal'. This seemed to work here when I compiled 0.11.2 Perhaps this automatation-tool can be reused for building later versions. >At least that's the current status. ;-) So there is hope that this changes? Regards Franz **= Email 2 ==========================** Date: Tue, 05 Nov 2002 09:17:51 +0000 (GMT) From: "Dave Saville" Subject: Re: buildin perl 5.8: signals On Mon, 04 Nov 2002 17:32:38 +0100 (CET), Yuri Dario wrote: >Hi, > >I'm sorry, maybe this argument has been already discussed, but I'm new to this list. > >Actually I got Perl 5.8 to compile using EMX fix 0.9d: I can't use the 5.7.x binaries on Hobbes >because they are compiled with pentiumII optimization, so they can't run on an AMD K6 >processor (pentium class). > >So I managed to rebuild the recent source code: after fixing some problems in my emx >enviroment, I got all code built. > >The test suite works fine on all test but those based on signal handling: near 98% of tests were >successfull. > >e.g. running "perl test.pl io/pipe.t" is failing with a "Process terminated by SIGPIPE"; similar >errors with alarm signal or the other signals. > >Can you suggest what could be broken? I can attach my config.sh if required. > Possibly nothing. I get that message a lot . I run moneydance for several finance accounts. Because the encryption in MD is real s l o w I tar up the account files and then pump them through pgp. Starting MD does the reverse. The Rexx command line for that is 'pgp -f < data.pgp | tar -xf -' This always throws the "Process terminated by SIGPIPE" error, but always works correctly. I think it is something to do with OS/2's handling of pipes. I always ignore it now. HTH -- Regards Dave Saville **= Email 3 ==========================** Date: Tue, 5 Nov 2002 13:55:37 -0800 (PST) From: Steve Wendt Subject: Re: New OpenSSH for OS/2 On Tue, 5 Nov 2002, John Poltorak wrote: > http://www.os2bbs.com/os2news > This is an excellent place for news, so remember to check it out every > week. Or every other week, when I have been lazy. ;) **= Email 4 ==========================** Date: Tue, 5 Nov 2002 13:57:43 +0000 From: John Poltorak Subject: New OpenSSH for OS/2 There's a new OpenSSH for OS/2 (v3.4 p1.6) which has been released recently. You can get further details via:- http://www.os2bbs.com/os2news This is an excellent place for news, so remember to check it out every week. If anyone has used this latest version, would you recomend updating to it? -- John **= Email 5 ==========================** Date: Tue, 5 Nov 2002 14:22:31 +0100 (CET) From: Stefan Neis Subject: Re: FTP access, was Some news On Fri, 1 Nov 2002, Andreas Buening wrote: > Just a note: There was a tight opinion poll: One vote for > the one level flat structure and one vote for a two level > structure. ;-) If you insist on getting more opinions, then let me say that I'm more interested in the content than in the directory structure - I don't really care either way as long as I can find the software I'm looking for. ;-) > Btw. we could use a different file name extension for > UnixOS/2 packages (e.g. .ux2 or .pkg) so that the file is > obviously not a simple .zip file but contains some installation > info for a package installer (the file format would still be .zip). > Then people could associate this extension with the UnixOS/2 > package installer (and double click on it). Being a command line fan, that's not really an issue for me. Again, I'm more interested in the file content than in the file name. So feel free to decide whichever way you like. If somebody has an urge to change it, a simple "ren *.whatever *.whatever_else" should take care of it, or if you insist on using a linux-like shell, it's something along the lines of "for file in *.whatever; do mv $file `basename $file whatever`.whatever_else" Regards, Stefan **= Email 6 ==========================** Date: Tue, 05 Nov 2002 14:34:21 +0100 (CET) From: "Yuri Dario" Subject: Re: buildin perl 5.8: signals Hi Dave, >'pgp -f < data.pgp | tar -xf -' >This always throws the "Process terminated by SIGPIPE" error, but >always works correctly. I think it is something to do with OS/2's not in this case: perl is failing also the tests related to other signals. Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.quasarbbs.net/yuri * http://www.teamos2.it * http://www.opera.com/os2/ */ **= Email 7 ==========================** Date: Tue, 5 Nov 2002 15:44:40 +0000 From: John Poltorak Subject: Re: buildin perl 5.8: signals On Mon, Nov 04, 2002 at 11:53:15PM +0100, Yuri Dario wrote: > Hi John, > > >Can you post the summary you get when running > >./perl harness in the directory ./t > > here: > 62 tests and 535 subtests skipped. > Failed 19/726 test scripts, 97.38% okay. 180/68636 subtests failed, 99.74% okay. This is what I got some months ago when a number of us were trying to come up with the best build using a standard build script:- Failed 7/726 test scripts, 99.04% okay. 11/68650 subtests failed, 99.98% okay. Failed Test Stat Wstat Total Fail Failed List of Failed ------------------------------------------------------------------------------- ../lib/ExtUtils/t/Mkbootstrap.t 1 256 18 1 5.56% 8 ../lib/ExtUtils/t/Packlist.t 1 256 34 1 2.94% 17 ../lib/ExtUtils/t/basic.t 1 256 17 1 5.88% 14 lib/os2_process.t 2 512 227 2 0.88% 174 209 lib/os2_process_kid.t 227 2 0.88% 174 209 lib/rx_cmprt.t 255 65280 18 3 16.67% 16-18 op/stat.t 73 1 1.37% 44 64 tests and 561 subtests skipped. Some people achieved better results than this although I don't think that every single fail was resolved by anyone. > > Bye, > > Yuri Dario > > /* > * member of TeamOS/2 - Italy > * http://www.quasarbbs.net/yuri > * http://www.teamos2.it > * http://www.opera.com/os2/ > */ -- John **= Email 8 ==========================** Date: Tue, 05 Nov 2002 17:17:55 +0100 From: edgue at web.de Subject: Perl 5.7 / Perl 5.8 and fork() Hi folks, is there anybody who has really worked with fork() and newer Perls? I did some testing today; in a rather complicated environment; and I saw really strange things happen. So - anybody out there with some deeper understanding of the perl/fork() stuff and experience with the various builts that exist at the moment? regards, edwin **= Email 9 ==========================** Date: Tue, 05 Nov 2002 18:10:46 +0100 (CET) From: "Yuri Dario" Subject: Re: buildin perl 5.8: signals Hi John, >This is what I got some months ago when a number of us were trying to come >up with the best build using a standard build script:- >Failed 7/726 test scripts, 99.04% okay. 11/68650 subtests failed, 99.98% I discovered my problem: the configure script fails on testing the available signals, so my config.sh lists only two signals. Could you send me your config.sh? I will extract sig_* tokens. probably something is going wrong with awk or similar. Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.quasarbbs.net/yuri * http://www.teamos2.it * http://www.opera.com/os2/ */ **= Email 10 ==========================** Date: Tue, 5 Nov 2002 19:51:39 -0000 From: "Csaba" Subject: Re: buildin perl 5.8: signals On 5 Nov 2002, at 15:44, John Poltorak wrote: [snip failed Perl tests] > lib/rx_cmprt.t 255 65280 18 3 16.67% 16-18 That one needs OREXX to work. -- Ceci n'est pas un .signature **= Email 11 ==========================** Date: Tue, 05 Nov 2002 22:22:42 +0100 From: Andreas Buening Subject: Re: gettext 0.11.5 Franz Bakan wrote: > > On Wed, 30 Oct 2002 01:05:08 +0100, Andreas Buening wrote: > > ... > >So, I've just uploaded the next trial (0.11.5 release 2). ;-) > > the older make-version now works too, but > grep (GNU grep) 2.4 > still ends with SIGSEGV This is expected. :-( > It also works here for compiling SANE-CVS > > In one case I got the following warning: > msgcat: warning: Input files contain messages in different encodings, > ISO-8859-15 and ISO-8859-1 among others. > Converting the output to UTF-8. > To select a different output encoding, use the --to-code option > > I assume that older intl.dll's cant deal with UTF-8. That's possible. > So there is a backward-compatibility-problem. > Is there a ENV-Variable (instead of the --to-code option) for > msgcat that forces converting to a different format? > Or if not perhaps this would be useful to implement in > a next version of gettext for OS/2 to avoid manual > changes in makefiles. > > >Compatibility: Some binary versions of intl.dll have been compiled > >by hand using "export by ordinal". > > Well, A.Z. allready automated this additional 'exporting by ordinal'. > This seemed to work here when I compiled 0.11.2 > Perhaps this automatation-tool can be reused for building later > versions. The problem is how do you want to build this into libtool? Or, to ask this question in another way: Which algorithm could generate a module definition file with "export by ordinal" for every (arbitrary) library in a binary compatible way so that everytime (!) the same function gets the same ordinal number in every version of this library? Even an alphabetical order fails if any (meaningless, internal) is introduced/removed for a specific release. I bet it's impossible. Of course, you can build an intl.dll by hand using an hand written module definition file. The idea is that all current projects are forced to relink their binaries without "export by ordinal" so that they can be used with every intl.dll. > >At least that's the current status. ;-) > > So there is hope that this changes? Not really. :-( Bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 12 ==========================** Date: Tue, 05 Nov 2002 22:48:14 +0100 (CET) From: "Sebastian Wittmeier (ShadoW)" Subject: Re: gettext 0.11.5 On Tue, 05 Nov 2002 22:22:42 +0100, Andreas Buening wrote: >The problem is how do you want to build this into libtool? >Or, to ask this question in another way: Which algorithm >could generate a module definition file with "export by ordinal" >for every (arbitrary) library in a binary compatible way so that >everytime (!) the same function gets the same ordinal number in >every version of this library? Even an alphabetical order fails >if any (meaningless, internal) is introduced/removed for a specific >release. I bet it's impossible. Have you looked at the way Perl ('s build system) handles that problem? It keeps a list of function-ordinal relations, and the last used ordinal. Make rebuilds the module definition file. That solution isn't perfect either. When a package gets branched, and new functions are introduced in both branches. But what solutions are for those cases? A central database? Ordinal numbers calculated with the function name's hash code? Sebastian