[32437] in Perl-Users-Digest
Perl-Users Digest, Issue: 3704 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu May 31 21:09:22 2012
Date: Thu, 31 May 2012 18:09:08 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 31 May 2012 Volume: 11 Number: 3704
Today's topics:
Re: coding question rvaedex23@gmail.com
Re: coding question <nospam.gravitalsun.antispam@hotmail.com.nospam>
Re: Help with install from CPAN <dave@invalid.invalid>
Re: Help with install from CPAN <ben@morrow.me.uk>
Re: Help with install from CPAN <dave@invalid.invalid>
Re: Help with install from CPAN <dave@invalid.invalid>
Re: Help with install from CPAN <dave@invalid.invalid>
Re: Help with install from CPAN <ben@morrow.me.uk>
Re: Help with install from CPAN <dave@invalid.invalid>
Re: Help with install from CPAN <dave@invalid.invalid>
Re: Help with install from CPAN (Seymour J.)
Re: Help with install from CPAN <ben@morrow.me.uk>
Re: Help with install from CPAN <steve53@nomail.earthlink.net>
my $variables <nospam.gravitalsun@hotmail.com.nospam>
Re: my $variables <peter@makholm.net>
Re: my $variables <nospam.gravitalsun@hotmail.com.nospam>
Re: my $variables <peter@makholm.net>
Re: Quick and dirty article filter (Seymour J.)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 30 May 2012 06:24:36 -0700 (PDT)
From: rvaedex23@gmail.com
Subject: Re: coding question
Message-Id: <c6944dca-92f3-489b-b315-7aa7db978a40@googlegroups.com>
On Friday, May 25, 2012 4:08:18 PM UTC-4, rvae...@gmail.com wrote:
> I am not very familiar with perl. Although, I do have shell scripting experience.
> I thought this would be easier to do this in perl.
>
> I have a file that doesn't have a field delimiter between the columns and I want to add a colon between each column. I can identify the columns by hard coding the range:
> such as "col1 to col 10" "col11 to col24" etc...
>
> I am stuck. Any advise would help. Thanks.
Thanks, I was able to accomplish this using gawk.
------------------------------
Date: Wed, 30 May 2012 20:17:20 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@hotmail.com.nospam>
Subject: Re: coding question
Message-Id: <jq5kn0$r3p$1@news.ntua.gr>
!!!
------------------------------
Date: Wed, 30 May 2012 08:11:22 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Help with install from CPAN
Message-Id: <fV45K0OBJxbE-pn2-lNRj5lB1xRyP@localhost>
On Tue, 29 May 2012 22:49:17 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
<snip>
> So it is a genuine failure, it just didn't get as far as printing the
> header for t/taint.t. What's happening here is that UseQx doesn't
> implement the logic to detect and run tests that use taint mode; so much
> for trying to patch a complex system with a quick hack or two.
>
> At this point I don't think this approach is viable: if we keep going
> round we'll end up reimplementing the whole of TAP::* before it works
> reliably. What we need to do is work out what is causing vanilla
> TAP::Harness to fail, and how to fix it; unfortunately, without my
> fingers on your keyboard I'm not sure how best to do that.
>
> Maybe the first thing to do is run the tests for TAP::* and see what
> fails? Make sure HARNESS_SUBCLASS is *unset*, then
>
> cpan> look Test::Harness
> $ perl Makefile.PL
> $ make
>
> and then go through t/*.t and t/compat/*.t and run each one through
>
> perl -Mblib t/x.t | grep -E '^not ok'
>
> to see what fails. Unfortunately the following tests can't be run like
> that
>
> t/aggregator.t
> t/bailout.t
> t/base.t
> t/callbacks.t
> t/errors.t
> t/nested.t
> t/object.t
> t/premature-bailout.t
> t/results.t
> t/streams.t
> t/yamlish-output.t
> t/compat/version.t
>
> because they use -T on the #! line; I can't see any simple way to run
> them individually without falling foul of taint checks.
Can you not also put -T on the invocation? Or does that defeat the
object of the test?
>
> > Seen that PANIC several times. Should we take this to PM? dave at
> > deezee dot org
>
> I don't see any reason to: this is entirely on-topic for clpmisc, and
> there is at least a chance someone else will spot something we don't. Of
> course, if you'd rather, feel free; my email is valid, though I can't
> promise I'll stick with this until it's solved.
Point. Just thought we were generating a lot of traffic for an obscure
port :-)
Whan I said I have seen that PANIC before that was *before* your hack
went in if that makes any difference.
--
Regards
Dave Saville
------------------------------
Date: Wed, 30 May 2012 12:48:51 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Help with install from CPAN
Message-Id: <32eh99-5o91.ln1@anubis.morrow.me.uk>
Quoth "Dave Saville" <dave@invalid.invalid>:
> On Tue, 29 May 2012 14:22:27 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
> > Quoth "Dave Saville" <dave@invalid.invalid>:
> > >
> > > t/xs.t ......................... skipped: No compiler found
> > <snip>
> > >
> > > Any idea why I am getting the "no compiler found" message?
> > > Config_Heavy seems to know there is one.
> >
> > Config_Heavy always thinks there is one; apparently ExtUtils::CBuilder
> > doesn't agree. What does this give you?
> >[T:\tmp]try.pl
> Tempdir is [T:/tmp/yrfcyhiavq]
> gcc -Iu:/perl5/lib/5.14.2/os2/CORE -Zdll -c -DDOSISH -DOS2=2 -DEMBED
> -I. -I/usr/local/include -O2 -fomit-frame-pointer -falign-loops=2
> -falign-jumps=2 -falign-functions=2 -s -o T:/tmp/yrfcyhiavq/lib.o
> T:/tmp/yrfcyhiavq/lib.c
> emximp -o T:/tmp/yrfcyhiavq/lib.a T:/tmp/yrfcyhiavq/lib.def
> gcc -Zdll -Zomf -o T:/tmp/yrfcyhiavq/compilFH.dll
> T:/tmp/yrfcyhiavq/lib.o u:/per
> l5/lib/5.14.2/os2/CORE/libperl.a
> u:/perl5/lib/5.14.2/os2/CORE/libperl_override.a
> T:/tmp/yrfcyhiavq/lib.def
> weakld: error: Unresolved symbol (UNDEF EXPORT) 'boot_compilet'.
>
> weakld: info: The symbol is referenced by:
> T:/tmp/yrfcyhiavq/lib.def
> Ignoring
> unresolved externals reported from weak prelinker.
> Error! E2028: boot_compilet is an
> undefined reference
> Error! E2044: exported symbol boot_compilet not found
> error building T:/tmp/yrfcyhiavq/compilFH.dll from
> T:/tmp/yrfcyhiavq/lib.o u:/perl5/lib/5.14.2/os2/CORE/libperl.a at
> /perl5/lib/5.14.2/ExtUtils/CBuilder/Base.pm line 310.
Well, that's not good. Have you succeeded in building any XS extensions
at all? What about MakeMaker-based ones: List::Util would be a good one
to try? If you've got gcc, have you got a nm, so you can see whether
lib.o exports that symbol?
I don't really know what those utilities are supposed to do (presumably
emximp builds a DLL import library? If that's necessary then why is it
not part of the link?) but it looks to me as though your development
environment is either rather broken or not compatible with your perl
install. If you're sure you've installed it all right you might want to
talk to Paul Smedley, who will presumably know how this is all supposed
to work (for instance, why does the DLL link libperl.a? That's not usual
on Unix platforms. And what's that rather suspicious-looking
libperl_override.a?).
Ben
------------------------------
Date: Wed, 30 May 2012 12:27:00 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Help with install from CPAN
Message-Id: <fV45K0OBJxbE-pn2-5Zyktpjfrb8M@localhost>
On Wed, 30 May 2012 11:48:51 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
<snip>
> Well, that's not good. Have you succeeded in building any XS extensions
> at all? What about MakeMaker-based ones: List::Util would be a good one
> to try? If you've got gcc, have you got a nm, so you can see whether
> lib.o exports that symbol?
>
> I don't really know what those utilities are supposed to do (presumably
> emximp builds a DLL import library? If that's necessary then why is it
> not part of the link?) but it looks to me as though your development
> environment is either rather broken or not compatible with your perl
> install. If you're sure you've installed it all right you might want to
> talk to Paul Smedley, who will presumably know how this is all supposed
> to work (for instance, why does the DLL link libperl.a? That's not usual
> on Unix platforms. And what's that rather suspicious-looking
> libperl_override.a?).
[T:\tmp\ehMrMfzEos]ls
lib.a lib.c lib.def lib.o
[T:\tmp\ehMrMfzEos]nm lib.o
00000000 T _boot_compilet
List::Utils
Oh dear, we have fallen into another hephalump trap to do I suspect
with the port. Like the truncation of @INC paths when using
PERRLIB_PREFIX and the replacement is longer than the original.
In file included from ListUtil.xs:7:
u:/perl5/lib/5.14.2/os2/CORE/perl.h:2577:27: os2ish.h: No such file or
directory
At first I thought it was telling porkies as an ls CORE shows
os2ish.h. But a closer look shows the entry to in fact be a soft link
to os2/os2ish.h which indeed does not exist. Wonder when that changed?
5.8.2 has the actual file in CORE. I think you are right and it's time
to rattle Paul again :-)
--
Regards
Dave Saville
------------------------------
Date: Thu, 31 May 2012 11:48:05 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Help with install from CPAN
Message-Id: <fV45K0OBJxbE-pn2-DJBysh03IUSL@localhost>
Hi Ben
I think we have found the cause of the compilet fails. From my friend
Steven Levine:
===============================
It's the default calling convention. Our gcc defaults
to the cdecl calling convention. So objdump reports
>objdump.exe --syms e:\tmp\wrOFA39OLc\lib.o
e:\tmp\wrOFA39OLc\lib.o: file format a.out-emx
SYMBOL TABLE:
00000000 g .text 0000 00 05 _boot_compilet
There are a couple of ways to fix the code. One is the specify a
calling
convention
int _System boot_compilet() { return 1; }
Another is to change the .def exports to
EXPORTS
_boot_compilet
=============================
I assume that there is something amiss in either Config.pm or
Config_Heavy.pl - but at the moment I have no idea what to look for. I
also asssume that this is something the configure stage of the port
ought to have picked up on.
--
Regards
Dave Saville
------------------------------
Date: Thu, 31 May 2012 15:11:57 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Help with install from CPAN
Message-Id: <fV45K0OBJxbE-pn2-SBBzKdyyy9Pv@localhost>
Hi Ben
I am informed that it is possible that Windows also uses the _ prefix
- So how is it handled there? I don't think perl does ifdefs so it
must be handled in the makefiles - yes?
--
Regards
Dave Saville
------------------------------
Date: Thu, 31 May 2012 16:08:45 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Help with install from CPAN
Message-Id: <t4ek99-9jc.ln1@anubis.morrow.me.uk>
Quoth "Dave Saville" <dave@invalid.invalid>:
>
> It's the default calling convention. Our gcc defaults
> to the cdecl calling convention.
I should think so too :). (Other calling conventions are generally
better, but don't support varargs, so are useless for C programs.)
> So objdump reports
>
> >objdump.exe --syms e:\tmp\wrOFA39OLc\lib.o
>
> e:\tmp\wrOFA39OLc\lib.o: file format a.out-emx
>
> SYMBOL TABLE:
> 00000000 g .text 0000 00 05 _boot_compilet
Is the underscore prefix usual on OS/2? Was it usual when using real
EMX, since I get the impression the last time anyone who knew much about
perl looked at all this that was state-of-the-art?
I ask because if you look at the source for ExtUtils::Mksymlists (the
module which writes the .def file), you will see that the Win32 section
makes allowances for symbols with an underscore prefix, but the OS/2
section does not.
> There are a couple of ways to fix the code. One is the specify a
> calling
> convention
>
> int _System boot_compilet() { return 1; }
>
> Another is to change the .def exports to
>
> EXPORTS
> _boot_compilet
I don't believe either of those options will work. DynaLoader assumes it
can pass a function name, with no underscore, to DosQueryProcAddr, and
get a C-convention function address. If _System changes the calling
convention, that will obviously lead to segfaults; and unless
DosQueryProcAddr silently prepends an underscore, changing the export
list will just mean DynaLoader can't find the symbol.
There is code in EU::Mksymlists to handle bcc on Win32, which apparently
prepends underscores; it builds a .def file which maps the underscore-
prefixed symbol in the object file to a non-prefixed symbol in the DLL.
If your build system has changed to require this then presumably the
OS/2 code could be patched to do the same thing, but that feels like
moving backwards to me...
Presumably you have prebuilt DLLs with your perl install, which
presumably load properly? (Can you use List::Util?) If you find
os2/auto/List/Util/Util.dll under your @INC and print out the dynamic
symbol table (nm -D on my system; there may be a specialised tool on
yours), does the symbol boot_List__Util have an initial underscore or
not? Is there any way you can see its intended calling convention (I
suspect there isn't)?
[I haven't forgotten about your test results xthread, I'm just not
entirely sure what to do with them yet...]
Ben
------------------------------
Date: Thu, 31 May 2012 15:52:53 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Help with install from CPAN
Message-Id: <fV45K0OBJxbE-pn2-tWo9mKlkKLYd@localhost>
On Thu, 31 May 2012 15:08:45 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
<snip>
> Is the underscore prefix usual on OS/2? Was it usual when using real
> EMX, since I get the impression the last time anyone who knew much about
> perl looked at all this that was state-of-the-art?
EMX did not use the underscore prefix. Most OS/2 developers have
switched to gcc which does.
>
> I ask because if you look at the source for ExtUtils::Mksymlists (the
> module which writes the .def file), you will see that the Win32 section
> makes allowances for symbols with an underscore prefix, but the OS/2
> section does not.
Ha Ha
>
> > There are a couple of ways to fix the code. One is the specify a
> > calling
> > convention
> >
> > int _System boot_compilet() { return 1; }
> >
> > Another is to change the .def exports to
> >
> > EXPORTS
> > _boot_compilet
>
> I don't believe either of those options will work. DynaLoader assumes it
> can pass a function name, with no underscore, to DosQueryProcAddr, and
> get a C-convention function address. If _System changes the calling
> convention, that will obviously lead to segfaults; and unless
> DosQueryProcAddr silently prepends an underscore, changing the export
> list will just mean DynaLoader can't find the symbol.
>
> There is code in EU::Mksymlists to handle bcc on Win32, which apparently
> prepends underscores; it builds a .def file which maps the underscore-
> prefixed symbol in the object file to a non-prefixed symbol in the DLL.
> If your build system has changed to require this then presumably the
> OS/2 code could be patched to do the same thing, but that feels like
> moving backwards to me...
>
After a quick look are we not going to still have the same problem
with Dynaloader?
> Presumably you have prebuilt DLLs with your perl install, which
> presumably load properly? (Can you use List::Util?) If you find
> os2/auto/List/Util/Util.dll under your @INC and print out the dynamic
> symbol table (nm -D on my system; there may be a specialised tool on
> yours), does the symbol boot_List__Util have an initial underscore or
> not? Is there any way you can see its intended calling convention (I
> suspect there isn't)?
>
All the prebuilt dll's have _'s - At least all the ones I looked at
have :-)
> [I haven't forgotten about your test results xthread, I'm just not
> entirely sure what to do with them yet...]
No problem.
--
Regards
Dave Saville
------------------------------
Date: Thu, 31 May 2012 17:39:46 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Help with install from CPAN
Message-Id: <fV45K0OBJxbE-pn2-HosiTbudhd78@localhost>
On Tue, 29 May 2012 14:22:27 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
<snip>
> Config_Heavy always thinks there is one; apparently ExtUtils::CBuilder
> doesn't agree. What does this give you?
>
> #!usr/bin/perl
>
> use ExtUtils::CBuilder;
> use File::Temp;
>
> my $B = ExtUtils::CBuilder->new;
> my $T = File::Temp::tempdir;
>
> print "Tempdir is [$T]\n";
>
> {
> my $c = "$T/lib.c";
> open my $C, ">", $c;
> print $C "int boot_compilet() { return 1; }\n";
> close $C;
>
> my $o = $B->compile(source => $c);
> my @l = $B->link(objects => $o, module_name => "compilet");
> }
> {
> my $c = "$T/exe.c";
> open $C, ">", $c;
> print $C "int main() { return 0; }\n";
> close $C;
>
> my $o = $B->compile(source => $c);
> my $e = $B->link_executable(objects => $o);
> print "$e\n";
> my $x = system $e;
> print "Exe returned [$x]\n";
> }
>
> (It will leave a tempdir you will need to clean up by hand.)
>
Exe returned [0]
I inserted
foreach (@{$data->{FUNCLIST}}) { $_ = '_'.$_; }
after
print $def "EXPORTS\n ";
in _write_os2 in Mksymlists.pm
Which then generates a lib.def that gcc builds the dll correctly with.
--
Regards
Dave Saville
------------------------------
Date: Thu, 31 May 2012 15:00:57 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Help with install from CPAN
Message-Id: <4fc7bfe9$43$fuzhry+tra$mr2ice@news.patriot.net>
In <t4ek99-9jc.ln1@anubis.morrow.me.uk>, on 05/31/2012
at 04:08 PM, Ben Morrow <ben@morrow.me.uk> said:
>Is the underscore prefix usual on OS/2?
It is these days. See <
https://rt.cpan.org/Ticket/Display.html?id=75278>
>There is code in EU::Mksymlists to handle bcc on Win32, which
>apparently prepends underscores; it builds a .def file which maps
>the underscore-prefixed symbol in the object file to a
>non-prefixed symbol in the DLL. If your build system has changed
>to require this then presumably the OS/2 code could be patched to
>do the same thing, but that feels like moving backwards to me...
See the patch in the above ticket. I haven't checked to see whether it
has been picked up.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Thu, 31 May 2012 22:17:48 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Help with install from CPAN
Message-Id: <so3l99-3me.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <t4ek99-9jc.ln1@anubis.morrow.me.uk>, on 05/31/2012
> at 04:08 PM, Ben Morrow <ben@morrow.me.uk> said:
>
> >Is the underscore prefix usual on OS/2?
>
> It is these days. See <
> https://rt.cpan.org/Ticket/Display.html?id=75278>
>
> >There is code in EU::Mksymlists to handle bcc on Win32, which
> >apparently prepends underscores; it builds a .def file which maps
> >the underscore-prefixed symbol in the object file to a
> >non-prefixed symbol in the DLL. If your build system has changed
> >to require this then presumably the OS/2 code could be patched to
> >do the same thing, but that feels like moving backwards to me...
>
> See the patch in the above ticket. I haven't checked to see whether it
> has been picked up.
No, it hasn't, neither in the latest release nor in git. The patch looks
like the right solution, though, if gcc is going to insist on extra
underscores; though I'm not entirely sure about using version.pm for
anyth^Wparsing non-Perl version numbers.
Dave: since you say your existing dlls have prefixed symbols, Paul
Smedley must have patched DynaLoader to look for them, or he must have
applied Shmuel's patch and in fact both boot_List__Util and
_boot_List__Util are present (pointing to the same address). In either
case, applying the patch and reinstalling ExtUtils::MakeMaker should
solve this bit of the problem...
If it works, and you felt like poking Schwern to get the patch applied
in git, that might not be a bad thing. If Paul's distribution is
effectively the standard distribution for OS/2, I feel strongly that the
less different it is from the real standard distribution the better.
Ben
------------------------------
Date: Thu, 31 May 2012 17:53:18 -0500
From: "Steven Levine" <steve53@nomail.earthlink.net>
Subject: Re: Help with install from CPAN
Message-Id: <11p86vVJT4Oe-pn2-SIDSE38d2IGP@slamain.slainc.com>
On Thu, 31 May 2012 15:08:45 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
Hi guys,
Since I am getting quoted here, I figure I might as well join in.
I may have some bad news. Against my better nature, I installed a
copy of the OS/2 5.14.2 in a location that avoids the @INC issues.
Ben's try.pl script works perfectly here run with either perl 5.10 or
5.14.2 and compiling with either gcc 3.3.5 or gcc 4.4.6.
>try.pl
Tempdir is [E:/TMP/6IAM96Rcd_]
gcc -I/perl5/lib/5.14.2/os2/CORE -Zdll -c -DDOSISH -DOS2=2 -DEMBED -I.
-I/usr/local/include -O2 -fomit-frame-pointer -falign-loops=2
-falign-jumps=2 -falign-functions=2 -s -o E:/TMP/6IAM96Rcd_/lib.o
E:/TMP/6IAM96Rcd_/lib.c
emximp -o E:/TMP/6IAM96Rcd_/lib.a E:/TMP/6IAM96Rcd_/lib.def
gcc -Zdll -Zomf -o E:/TMP/6IAM96Rcd_/compilFH.dll
E:/TMP/6IAM96Rcd_/lib.o /perl5/lib/5.14.2/os2/CORE/libperl.a
/perl5/lib/5.14.2/os2/CORE/libperl_override.a
E:/TMP/6IAM96Rcd_/lib.def
gcc -I/perl5/lib/5.14.2/os2/CORE -Zdll -c -DDOSISH -DOS2=2 -DEMBED -I.
-I/usr/local/include -O2 -fomit-frame-pointer -falign-loops=2
-falign-jumps=2 -falign-functions=2 -s -o E:/TMP/6IAM96Rcd_/exe.o
E:/TMP/6IAM96Rcd_/exe.c
gcc -Zomf -Zhigh-mem -Zstack 32000 -o E:/TMP/6IAM96Rcd_/exe.exe
E:/TMP/6IAM96Rcd_/exe.o /perl5/lib/5.14.2/os2/CORE/libperl_override.a
E:/TMP/6IAM96Rcd_/exe.exe
Exe returned [0]
The generated .def file has a leading underscore that matches what the
compiler generates
LIBRARY 'compilFH' INITINSTANCE TERMINSTANCE
DESCRIPTION '@#Distribution compilet:0.0#@ Perl (v5.14.2 pl) module
compilet (Perl-config: -Dprefix=/perl5)'
CODE LOADONCALL
DATA LOADONCALL NONSHARED MULTIPLE
EXPORTS
_boot_compilet
Given this, I have to suspect something specfic on Dave's setup.
> > So objdump reports
> >
> > >objdump.exe --syms e:\tmp\wrOFA39OLc\lib.o
> >
> > e:\tmp\wrOFA39OLc\lib.o: file format a.out-emx
> >
> > SYMBOL TABLE:
> > 00000000 g .text 0000 00 05 _boot_compilet
>
> Is the underscore prefix usual on OS/2? Was it usual when using real
> EMX,
Yes. I checked against the antique emx gcc 2.8.1.
> I ask because if you look at the source for ExtUtils::Mksymlists (the
> module which writes the .def file), you will see that the Win32 section
> makes allowances for symbols with an underscore prefix, but the OS/2
> section does not.
Hmm. What about the code at line 120 of _write_os2()?
> I don't believe either of those options will work. DynaLoader assumes it
> can pass a function name, with no underscore, to DosQueryProcAddr, and
> get a C-convention function address. If _System changes the calling
> convention, that will obviously lead to segfaults; and unless
_System and _cdecl are similar enough that segfaults are unlikely.
> DosQueryProcAddr silently prepends an underscore, changing the export
That does not happen.
Steven
--
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
------------------------------
Date: Thu, 31 May 2012 10:54:14 +0300
From: "George Mpouras" <nospam.gravitalsun@hotmail.com.nospam>
Subject: my $variables
Message-Id: <jq781n$ask$1@news.ntua.gr>
is there any way to catch the "my" variable names like the "our" variables ?
my $var_001 = 'hello';
our $var_002 = 'world';
foreach (grep /var/, keys %{__PACKAGE__.::}) {print "$_
",${__PACKAGE__.::}{$_},"\n"}
------------------------------
Date: Thu, 31 May 2012 10:10:54 +0200
From: Peter Makholm <peter@makholm.net>
Subject: Re: my $variables
Message-Id: <87y5o8wz1t.fsf@vps1.hacking.dk>
"George Mpouras" <nospam.gravitalsun@hotmail.com.nospam> writes:
> is there any way to catch the "my" variable names like the "our" variables ?
Yes, with the peek_my function from PadWalker.
PadWalker has some interesting use cases, but if you need it in you
daily development then you are either hacking perl internals or doing
something wrong.
//Makholm
------------------------------
Date: Thu, 31 May 2012 14:21:27 +0300
From: "George Mpouras" <nospam.gravitalsun@hotmail.com.nospam>
Subject: Re: my $variables
Message-Id: <jq7k6b$2jjd$1@news.ntua.gr>
PadWalker does not help, you have to know the variable name. I want all the
my ... to decide what to do after I know their names. There is product that
inside their C code they have warp Perl
------------------------------
Date: Thu, 31 May 2012 14:11:57 +0200
From: Peter Makholm <peter@makholm.net>
Subject: Re: my $variables
Message-Id: <87mx4ownw2.fsf@vps1.hacking.dk>
"George Mpouras" <nospam.gravitalsun@hotmail.com.nospam> writes:
> PadWalker does not help, you have to know the variable name. I want all the
> my ... to decide what to do after I know their names.
I have no idea what you are looking for if it isn't just
keys %{ my_peek(0) };
//Makholm
------------------------------
Date: Tue, 29 May 2012 19:17:46 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Quick and dirty article filter
Message-Id: <4fc5591a$31$fuzhry+tra$mr2ice@news.patriot.net>
In <jq2tnm$tf4$1@speranza.aioe.org>, on 05/29/2012
at 04:32 PM, Chris Nehren <apeiron@pobox.com> said:
>The code uses Email::Simple to stick its fingers in its ears and
>pretend that encodings other than US ASCII do not exist. For
>Usenet, this is still mostly okay (at least for the parts of it I
>read, i.e. the Big 8
I see plenty of articles in big 8 news groups with MIME header fields
specifying something other than charset=us-ascii.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3704
***************************************
