[32718] in Perl-Users-Digest
Perl-Users Digest, Issue: 3982 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jul 6 03:09:35 2013
Date: Sat, 6 Jul 2013 00:09:06 -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 Sat, 6 Jul 2013 Volume: 11 Number: 3982
Today's topics:
Re: [XS] .h constants -> Perl subs (like POSIX' "errno_ <oneingray@gmail.com>
Re: [XS] .h constants -> Perl subs (like POSIX' "errno_ <rweikusat@mssgmbh.com>
Re: [XS] .h constants -> Perl subs (like POSIX' "errno_ <derykus@gmail.com>
[XS] DESTROY: free or flush? "related" objects? <oneingray@gmail.com>
Re: [XS] DESTROY: free or flush? "related" objects? <rweikusat@mssgmbh.com>
Re: [XS] DESTROY: free or flush? "related" objects? <oneingray@gmail.com>
Re: [XS] DESTROY: free or flush? "related" objects? <ben@morrow.me.uk>
clobbering of $@ in DESTROY? <oneingray@gmail.com>
Excessive beancounting is bad for you health! <rweikusat@mssgmbh.com>
Re: having trouble with hash of arrays... <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Re: having trouble with hash of arrays... <rvtol+usenet@xs4all.nl>
Re: having trouble with hash of arrays... <rvtol+usenet@xs4all.nl>
Re: having trouble with hash of arrays... gravitalsun@gmail.com
Re: having trouble with hash of arrays... gravitalsun@gmail.com
Re: having trouble with hash of arrays... <jwkrahn@example.com>
Re: I'd like to try Perl... <jblack@nospam.com>
Re: I'd like to try Perl... <jblack@nospam.com>
speed of subroutine calls in perl <rweikusat@mssgmbh.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 05 Jul 2013 16:18:33 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: [XS] .h constants -> Perl subs (like POSIX' "errno_h")?
Message-Id: <87vc4p0yli.fsf@violet.siamics.net>
>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>> Ivan Shmakov <oneingray@gmail.com> writes:
>> Is there an easy way to make a bunch of C constants (as in: #define)
>> available as Perl subroutines (just like, e. g., POSIX does for the
>> errno.h constants)?
> In case of a new module, this is part of what h2xs does.
It seems to do more than that: it prepares a complete template
for a new module. Which is certainly nice and worth looking at,
but I already have started working on that module, thus it isn't
all that helpful.
Besides, the data gathered by h2xs(1) ends up in the respective
WriteConstants () invocation in Makefile.PL. Which then does
the thing, as I was able to figure out.
> I'm also using C::Scan::Constants when more 'dynamic'(ically
> changing) headers are involved.
ACK, thanks for the pointer.
(To note is that the C::Scan::Constants documentation also
points to WriteConstants ().)
--
FSF associate member #7257
------------------------------
Date: Fri, 05 Jul 2013 20:31:41 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: [XS] .h constants -> Perl subs (like POSIX' "errno_h")?
Message-Id: <87r4fcn6qq.fsf@sapphire.mobileactivedefense.com>
Ivan Shmakov <oneingray@gmail.com> writes:
>>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>>> Ivan Shmakov <oneingray@gmail.com> writes:
> >> Is there an easy way to make a bunch of C constants (as in: #define)
> >> available as Perl subroutines
[...]
> > I'm also using C::Scan::Constants when more 'dynamic'(ically
> > changing) headers are involved.
>
> ACK, thanks for the pointer.
>
> (To note is that the C::Scan::Constants documentation also
> points to WriteConstants ().)
The more interesting part is that it provides a reasonably working
(the version I'm using required manual fixups because it can't cope
with #defines which don't include an expansion, eg, guard macros)
'easy to use' way to extract 'constant information' from a bunch of C
header files. Eg, I have a Perl (extension) module capable of parsing
a (set of) racoon config file(s) based on a shared library containing
the actual racoon parser code (based on a thorough reorganization of
the racoon source code) and I'm using a script looking like this:
---------------
use C::Scan::Constants;
my @hdrs = qw(/usr/local/include/racoon/ipsecdoi_id.h
/usr/local/include/racoon/ipsec_doi.h
/usr/local/include/racoon/handler.h
/usr/local/include/racoon/isakmp.h
/usr/local/include/racoon/oakley.h
/usr/local/include/racoon/remoteconf.h);
my @cs = extract_constants_from(@hdrs);
write_constants_module('MECS::Racoonconf', @cs);
---------------
to add the IPsec-related constants I need to that (supposed to be
executed manually whenever 'something changed').
------------------------------
Date: Fri, 05 Jul 2013 23:49:53 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: [XS] .h constants -> Perl subs (like POSIX' "errno_h")?
Message-Id: <kr8emm$p50$1@speranza.aioe.org>
On 7/2/2013 11:05 PM, Ivan Shmakov wrote:
> Is there an easy way to make a bunch of C constants (as in:
> #define) available as Perl subroutines (just like, e. g., POSIX
> does for the errno.h constants)?
>
> I've looked at POSIX.xs, POSIX.pm [1, 2], but don't seem to get
> it. (Somehow, there do not seem to be any references to, say,
> ENOENT, other than that in the export list.)
>
> Surely, I can follow the example at SQLite.xs [3]:
>
> static int
> OK()
> CODE:
> RETVAL = SQLITE_OK;
> OUTPUT:
> RETVAL
>
> But that seems overly repetitive and error-prone. (Given that I
> need to handle some 156 such constants, anyway.)
>
> TIA.
>
> [1] http://cpansearch.perl.org/src/RJBS/perl-5.18.0/ext/POSIX/POSIX.xs
> [2] http://cpansearch.perl.org/src/RJBS/perl-5.18.0/ext/POSIX/lib/POSIX.pm
> [3] http://cpansearch.perl.org/src/ISHIGAKI/DBD-SQLite-1.39/SQLite.xs
>
Could you just transform 'em to perl constants, eg,
BEGIN {
my %const = map {chomp; (split)[1,2]; }
qx{ grep '^#define' /path/to/*.h };
my $code;
while ( my($k,$v) = each %const ) {
$code .= "$k => $v,";
}
eval "use constant {$code}";
die $@ if $@;
}
--
Charles DeRykus
------------------------------
Date: Fri, 05 Jul 2013 20:17:15 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: [XS] DESTROY: free or flush? "related" objects?
Message-Id: <87r4fc2244.fsf@violet.siamics.net>
BTW, is it common for the DESTROY method to flush any pending
writes associated with the object being destroyed?
The library I'm interested in offers two destructors for one of
its objects: one is "free", which simply deallocates the
object's memory, and the other is "close", which flushes the
pending writes first. It certainly feels more sensible to call
"close" in Perl's DESTROY method, but what do I do if it fails?
AIUI, calling die () in DESTROY is of little use.
The other issue is that given a library's object of type A,
I can request an object of type B (an iterator, in this case) to
be created. Obviously, as this latter object references the
former, I now have some refcounting trickery to do.
Alas, the library doesn't provide a way to retrieve the "parent"
object. Which makes me wonder, will it be sensible to represent
the B type as a (blessed) Perl reference to a list, holding the
pointers to both the "child" and "parent" objects? (The parent
object itself is represented as a reference to its pointer.)
Do I understand it correctly that I get refcounting for granted
in this case?
--
FSF associate member #7257
------------------------------
Date: Fri, 05 Jul 2013 21:43:45 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: [XS] DESTROY: free or flush? "related" objects?
Message-Id: <87mwq0n3em.fsf@sapphire.mobileactivedefense.com>
Ivan Shmakov <oneingray@gmail.com> writes:
> BTW, is it common for the DESTROY method to flush any pending
> writes associated with the object being destroyed?
>
> The library I'm interested in offers two destructors for one of
> its objects: one is "free", which simply deallocates the
> object's memory, and the other is "close", which flushes the
> pending writes first. It certainly feels more sensible to call
> "close" in Perl's DESTROY method, but what do I do if it
> fails? AIUI, calling die () in DESTROY is of little use.
AFAIK, the only effect is that it possibly clobbers another exception,
cf
----------
package A;
sub new
{
return bless([], 'A');
}
sub DESTROY
{
die("In a destructor, no one hears you scream!");
}
package main;
eval {
my $a = A->new();
$a = undef;
print("I will survive!\n");
};
eval {
my $a = A->new();
die("After death I rot");
};
print("$@", "\n");
----------
My suggestion would be to call close and print a diagnostic
if it fails. That's consistent with the way 'other objects' work
(specifically, file handles) and better than calling the other:
There's a (usually good) chance that this will work as intended while
just freeing the object is equivalent to a close which always fails.
> The other issue is that given a library's object of type A,
> I can request an object of type B (an iterator, in this case) to
> be created. Obviously, as this latter object references the
> former, I now have some refcounting trickery to do.
>
> Alas, the library doesn't provide a way to retrieve the "parent"
> object. Which makes me wonder, will it be sensible to represent
> the B type as a (blessed) Perl reference to a list, holding the
> pointers to both the "child" and "parent" objects
Instead of a pointer to the parent object, I'd use a reference to the
corresponding Perl object. This would imply that the parent won't be
destroyed while an iterator referring to it still exists. Another
option would be to make that a weak reference. In this case, the
'parent member' of the iterator object would be cleared when the
parent object goes away which could be used for 'automatic iterator
invalidation'.
------------------------------
Date: Fri, 05 Jul 2013 21:04:36 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: [XS] DESTROY: free or flush? "related" objects?
Message-Id: <87mwq01zx7.fsf@violet.siamics.net>
>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>> Ivan Shmakov <oneingray@gmail.com> writes:
[...]
> My suggestion would be to call close and print a diagnostic if it
> fails.
How do I print the diagnostic, then? (I'm considering
implementing ->DESTROY () in the .xs code.)
> That's consistent with the way 'other objects' work (specifically,
> file handles) and better than calling the other: there's a (usually
> good) chance that this will work as intended while just freeing the
> object is equivalent to a close which always fails.
Sounds sensible; thanks.
>> The other issue is that given a library's object of type A, I can
>> request an object of type B (an iterator, in this case) to be
>> created. Obviously, as this latter object references the former, I
>> now have some refcounting trickery to do.
>> Alas, the library doesn't provide a way to retrieve the "parent"
>> object. Which makes me wonder, will it be sensible to represent the
>> B type as a (blessed) Perl reference to a list, holding the pointers
>> to both the "child" and "parent" objects
> Instead of a pointer to the parent object, I'd use a reference to the
> corresponding Perl object. This would imply that the parent won't be
> destroyed while an iterator referring to it still exists.
Indeed, that's what I've meant.
> Another option would be to make that a weak reference. In this case,
> the 'parent member' of the iterator object would be cleared when the
> parent object goes away which could be used for 'automatic iterator
> invalidation'.
This will require appropriate guards on all the XS methods
(which doesn't seem to be all that reasonable), and I'm not
entirely sure if freeing the parent before the child has, and
will have, well-defined semantics according to the library's
specification.
--
FSF associate member #7257
------------------------------
Date: Sat, 6 Jul 2013 00:18:00 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: [XS] DESTROY: free or flush? "related" objects?
Message-Id: <8q0kaa-2b61.ln1@anubis.morrow.me.uk>
Quoth Ivan Shmakov <oneingray@gmail.com>:
> >>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> >>>>> Ivan Shmakov <oneingray@gmail.com> writes:
>
> > My suggestion would be to call close and print a diagnostic if it
> > fails.
>
> How do I print the diagnostic, then? (I'm considering
> implementing ->DESTROY () in the .xs code.)
Perl_warn, unless you want to offer some more sophisticated form of
diagnostic catching. Note that calling Perl_warn(aTHX_ ...) explicitly
is (on some platforms) considerably cheaper than using the plain
warn(...) form.
> > That's consistent with the way 'other objects' work (specifically,
> > file handles) and better than calling the other: there's a (usually
> > good) chance that this will work as intended while just freeing the
> > object is equivalent to a close which always fails.
>
> Sounds sensible; thanks.
I would say it's always worth doing any cleanup you can which will not
do any harm if it fails. If flushing might leave whatever its flushing
to in an inconsistent state if it fails, it would be better not to call
it from DESTROY and instead provide an explicit ->sync method of some
sort.
> >> The other issue is that given a library's object of type A, I can
> >> request an object of type B (an iterator, in this case) to be
> >> created. Obviously, as this latter object references the former, I
> >> now have some refcounting trickery to do.
>
> >> Alas, the library doesn't provide a way to retrieve the "parent"
> >> object. Which makes me wonder, will it be sensible to represent the
> >> B type as a (blessed) Perl reference to a list, holding the pointers
> >> to both the "child" and "parent" objects
> >
> > Instead of a pointer to the parent object, I'd use a reference to the
> > corresponding Perl object. This would imply that the parent won't be
> > destroyed while an iterator referring to it still exists.
>
> Indeed, that's what I've meant.
If you're manipulating these objects from C, you don't need to use a
Perl array, nor a full Perl reference to the parent object. Just create
a little structure with an iterator* and a SV* in it, then store that
structure in the PV slot of the object (that is, not the reference, the
SV that reference points to).
Put the iterator pointer in the iterator member, SvREFCNT_inc the parent
object (again, the object itself, not the reference pointing to it), and
put a pointer to it in the SV*. Then, in the iterator's DESTROY method,
free the iterator and SvREFCNT_dec the parent object (and let perl
handle cleaning up the structure, since it was the 'string value' of the
object).
Ben
------------------------------
Date: Sat, 06 Jul 2013 06:31:05 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: clobbering of $@ in DESTROY?
Message-Id: <87ip0o19p2.fsf_-_@violet.siamics.net>
>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>> Ivan Shmakov <oneingray@gmail.com> writes:
[...]
>> It certainly feels more sensible to call "close" in Perl's DESTROY
>> method, but what do I do if it fails? AIUI, calling die () in
>> DESTROY is of little use.
... Unless "use warnings" is in effect, as it seems to turn such
die () invocations into warn ().
> AFAIK, the only effect is that it possibly clobbers another
> exception, cf
I wonder if it still is the case in the newer Perl versions?
For instance, when run with $ perl -w, the code gives:
--cut--
(in cleanup) In a destructor, no one hears you scream! at - line 10.
(in cleanup) In a destructor, no one hears you scream! at - line 10.
I will survive!
After death I rot at - line 25.
--cut--
Or could that be specific to the Debian Perl package?
$ dpkg -s -- perl
Package: perl
...
Architecture: amd64
Version: 5.14.2-14
...
$
> package A;
> sub new
> {
> return bless([], 'A');
> }
BTW, do I understand it correctly that in order to allow for
proper subclassing, it should generally be $_[0] // 'A' instead?
[...]
> package main;
FWIW, I've tweaked this part of the code as follows.
use warnings;
eval {
my $a = A->new ();
$a = undef;
die ("I will survive!");
};
print STDERR ($@);
eval {
my $a = A->new ();
die ("Should clobber this?");
};
print STDERR ($@);
And the code now results in:
--cut--
(in cleanup) In a destructor, no one hears you scream! at - line 10.
I will survive! at - line 21.
(in cleanup) In a destructor, no one hears you scream! at - line 10.
Should clobber this? at - line 29.
--cut--
--
FSF associate member #7257
------------------------------
Date: Thu, 04 Jul 2013 14:31:10 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Excessive beancounting is bad for you health!
Message-Id: <877gh6310h.fsf@sapphire.mobileactivedefense.com>
Judgeing from SCM changelogs, I've been doing nothing but Java
programming for about one month. Yesterday, I finished this particular
task and thus got back to working on Perl-code. This was the
first day since 2013/05/30 where I didn't feel completely exhausted
and depressive after a days worth of work but as if I had been
spending my day in enjoyably productive way in order to get one step
closer to solving a particular, complex problem.
------------------------------
Date: Thu, 4 Jul 2013 21:45:08 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Subject: Re: having trouble with hash of arrays...
Message-Id: <kr4frn$lm3$1@news.ntua.gr>
# this is what you want
use strict;
use warnings;
my %hash;
while (<DATA>)
{
my ($pid, $pname) = $_ =~/^(.*?),(.*?)\s*$/;
if (exists $hash{$pid})
{
unless ( $pname ~~ @{$hash{$pid}->{'names'}} )
{
push @{$hash{$pid}->{'names'}} , $pname
}
}
else
{
$hash{$pid}->{'value'} = $pname;
$hash{$pid}->{'names'} = [ $pname ]
}
}
use Data::Dumper; print Dumper \%hash;
__DATA__
foo,foo name
foo,fooname
foo,fo oname
foo,fooname
goo,gooname
goo,goo name
goo,gooname
------------------------------
Date: Fri, 05 Jul 2013 10:03:30 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: having trouble with hash of arrays...
Message-Id: <51d67dd3$0$15994$e4fe514c@news2.news.xs4all.nl>
On 04/07/2013 20:45, George Mpouras wrote:
> while (<DATA>) {
> my ($pid, $pname) = /^(.*?),(.*?)\s*$/;
Be aware that the '(.*?)\s*$' at the end just means '(.*)'.
What meaning where you looking for?
Maybe this: '(.*\S)\s*$'.
(but then the last field can't be empty).
--
Ruud
------------------------------
Date: Fri, 05 Jul 2013 10:05:53 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: having trouble with hash of arrays...
Message-Id: <51d67e61$0$15994$e4fe514c@news2.news.xs4all.nl>
Ignore this, I sent it by accident.
On 05/07/2013 10:03, Dr.Ruud wrote:
> On 04/07/2013 20:45, George Mpouras wrote:
>
>> while (<DATA>) {
>> my ($pid, $pname) = /^(.*?),(.*?)\s*$/;
>
> Be aware that the '(.*?)\s*$' at the end just means '(.*)'.
>
>
>
>
> What meaning where you looking for?
>
> Maybe this: '(.*\S)\s*$'.
> (but then the last field can't be empty).
>
I was testing and found out I was wrong, and need more coffee:
perl -wle '
$_ = "x,y \n";
my ($pid, $pname) = /^(.*?),(.*?)\s*$/;
print "<$pid>,<$pname>";
'
<x>,<y>
--
Ruud
------------------------------
Date: Fri, 5 Jul 2013 05:31:17 -0700 (PDT)
From: gravitalsun@gmail.com
Subject: Re: having trouble with hash of arrays...
Message-Id: <d8db8117-137e-4cb8-91ff-e85eeb09351d@googlegroups.com>
On Friday, July 5, 2013 11:03:30 AM UTC+3, Dr.Ruud wrote:
> On 04/07/2013 20:45, George Mpouras wrote:
>
>
>
> > while (<DATA>) {
>
> > my ($pid, $pname) = /^(.*?),(.*?)\s*$/;
>
>
>
> Be aware that the '(.*?)\s*$' at the end just means '(.*)'.
>
>
>
>
>
>
>
>
>
> What meaning where you looking for?
>
>
>
> Maybe this: '(.*\S)\s*$'.
>
> (but then the last field can't be empty).
>
>
>
> --
>
> Ruud
you are not correct, the (.*?)\s*$/ is not equal to '(.*)'.
It is not greedy and you do not catch any \n \r \v at $2
So this way you can avoid the function
chomp $_;
The .* you mention is catching also the new lines.
------------------------------
Date: Fri, 5 Jul 2013 05:32:09 -0700 (PDT)
From: gravitalsun@gmail.com
Subject: Re: having trouble with hash of arrays...
Message-Id: <03338aa7-fcd1-4349-9232-f8e445a5cdd2@googlegroups.com>
hey , sorry , I did not see your previous message.
------------------------------
Date: Fri, 05 Jul 2013 23:23:18 -0700
From: "John W. Krahn" <jwkrahn@example.com>
Subject: Re: having trouble with hash of arrays...
Message-Id: <rJOBt.97$9q7.67@fx09.iad>
gravitalsun@gmail.com wrote:
> On Friday, July 5, 2013 11:03:30 AM UTC+3, Dr.Ruud wrote:
>> On 04/07/2013 20:45, George Mpouras wrote:
>>>
>>> while (<DATA>) {
>>> my ($pid, $pname) = /^(.*?),(.*?)\s*$/;
>>
>> Be aware that the '(.*?)\s*$' at the end just means '(.*)'.
>>
>> What meaning where you looking for?
>>
>> Maybe this: '(.*\S)\s*$'.
>> (but then the last field can't be empty).
>
> you are not correct, the (.*?)\s*$/ is not equal to '(.*)'.
> It is not greedy and you do not catch any \n \r \v at $2
> So this way you can avoid the function
> chomp $_;
> The .* you mention is catching also the new lines.
No. The . character class does not match a newline (unless the regular
expression uses the /s option.)
John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein
------------------------------
Date: Thu, 4 Jul 2013 22:10:12 -0500
From: John Black <jblack@nospam.com>
Subject: Re: I'd like to try Perl...
Message-Id: <MPG.2c3ff4f837083128989781@news.eternal-september.org>
In article <kr02ei$bv7$1@reader2.panix.com>, dkcombs@panix.com says...
>
> In article <MPG.2c057fe1b0af9e4b989779@news.eternal-september.org>,
> John Black <jblack@nospam.com> wrote:
> >In article <d9ac9117-18c9-4114-ad7a-612c23ba1dd5@dk8g2000vbb.googlegroups.com>,
> >marc.girod@gmail.com says...
> >> Note also the Cygwin option...
> >
> >Yeah, spend a few minutes checking out the cygwin environment. I started with Strawberry
> >Perl and ended up removing it and installing cygwin. You get perl and tons more if you want.
> >You choose what you want installed or not installed but what you end up with is an
> >environment and set of tools that looks like and includes most of what you get with Unix. In
> >fact, when I'm in a cygwin terminal, I can pretty much behave as if its a unix window and
> >everything seems to work as I expect.
> >
> >John Black
>
> Sorry, I use cygwin (via *shell* in emacs), but I don't know
> what this "cygwin terminal" is. I probably would benefit
> from it!
We may be talking different languages but I will try to help. I don't know what "use cygwin
via shell in emacs" even means. I don't use emacs so that is perhaps why. But I've
installed cygwin and as part of that I got something (icon on my desktop) called Cygwin
Terminal. When I start one (and I can open as many as I want), I get a terminal running
bash. It runs bash by default but I think there is a way to run different shells. Like I
said, when I am in one of these terminals, its just like I'm running unix or linux.
> Any comments or help on it? Thanks!
>
>
> ---
>
>
> One problem I have is getting the *cygwin* shell stuff to work:
> (this is from some time ago, so I might have forgotten
> a bit of what I did):
>
> I (thought I) found that if I wanted to use pipes, variables,
> etc within a cygwin shell (sh, tcsh (I believe), etc), then
> I was required to use that horrible windows "cmd" black-and-white
> window, which was really, really gross.
Nope. You are right, that windows cmd window is crap. Thankfully I don't have to use it
since I have the cygwin terminal.
> One problem I had was that I could not prepare IN EMACS a command
> to execute there, and paste that command into that
> horrible cmd window. Could only type it in there by hand,
> character by character.
The cygwin terminal works just as many other unix terminal programs. Select a bunch of text
with the mouse. (and yes, you can select more than what fits on one screen Ben). Then
middle mouse button to paste. Easy.
> Likewise, I think I recall, it was difficult or impossible
> to "copy" text from within that window (for pasting elsewhere);
> copying and pasting simply didn't work in cmd windows.
Copy paste in a cmd window is a pain, yes. Fortunately, we don't need cmd windows.
> Question: have you found a way to run cygwin shells, etc,
> other than within a cmd window?
yes. see above.
> Question: have you found a way TO do copy, paste, etc
> with a cmd window?
yes, see above.
> And, generally, how do people run the cygwin shells?
> In what environment?
I wish I knew what I did that you didn't do? How long has it been since you installed it?
When you install, make sure you have everything in the package called "Base".
> Question: how do they get the full features of one
> of those shells to work, within emacs? Within, say,
> *shell* or *eshell*?
This I can't help with since I don't use emacs. I use Zues or vi.
John Black
------------------------------
Date: Thu, 4 Jul 2013 22:12:40 -0500
From: John Black <jblack@nospam.com>
Subject: Re: I'd like to try Perl...
Message-Id: <MPG.2c3ff5a328b17888989782@news.eternal-september.org>
In article <n4cdaa-jjs1.ln1@anubis.morrow.me.uk>, ben@morrow.me.uk says...
>
> This is completely OT, but...
>
> Quoth dkcombs@panix.com (David Combs):
> >
> > Sorry, I use cygwin (via *shell* in emacs), but I don't know
> > what this "cygwin terminal" is. I probably would benefit
> > from it!
>
> I believe it's just a cmd window running a Cygwin shell.
>
> > One problem I have is getting the *cygwin* shell stuff to work:
> > (this is from some time ago, so I might have forgotten
> > a bit of what I did):
> >
> > I (thought I) found that if I wanted to use pipes, variables,
> > etc within a cygwin shell (sh, tcsh (I believe), etc), then
> > I was required to use that horrible windows "cmd" black-and-white
> > window, which was really, really gross.
>
> This is expected on Windows. Because Windows doesn't have ptys, and
> makes some distinction between 'console' and 'gui' applications, and for
> other reasons I can't remember, it's never worth using any sort of
> terminal emulator other than cmd.exe. They just never work properly.
>
> (And cmd isn't *that* bad, at least if you make the font a bit bigger.
> It's not what I'd call pleasant, but it's not unusable.)
>
> > One problem I had was that I could not prepare IN EMACS a command
> > to execute there, and paste that command into that
> > horrible cmd window. Could only type it in there by hand,
> > character by character.
> >
> > Likewise, I think I recall, it was difficult or impossible
> > to "copy" text from within that window (for pasting elsewhere);
> > copying and pasting simply didn't work in cmd windows.
>
> Copy and paste in cmd.exe are found on the right-click menu on the icon
> in the top-left of the window. (Yes, this is weird.) Copying is a
> two-step process: first choose right-click/Edit/Mark, then select the
> text you want to copy, then right-click/Edit/Copy. IIRC you can't copy
> more than one (visible) screenful at a time.
Ug. Cygwin now comes with a cygwin terminal. You don't need cmd which sucks for copy paste
and everything else.
> > And, generally, how do people run the cygwin shells?
> > In what environment?
>
> I stay as far away from Cygwin as possible. IME it has all the bugs of
> Windows plus a whole lot more of its own.
I really like it. How long since you've tried it?
> > Question: how do they get the full features of one
> > of those shells to work, within emacs? Within, say,
> > *shell* or *eshell*?
>
> They don't. It can't be done on Windows, since there aren't any ptys.
Its been done. cygwin has it.
John Black
------------------------------
Date: Fri, 05 Jul 2013 18:57:41 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: speed of subroutine calls in perl
Message-Id: <87vc4onb3e.fsf@sapphire.mobileactivedefense.com>
I recently read the 'Lambda: The ultimate GOTO' paper published by
Steele/ Sussman in 1977[*]. While I mostly consider this 'an
entertaining rant', the idea that The Absolutely Dreadful Function
Call Overhead[tm] is rather an urban legend people keep telling each
other seemed plausible to me. Of course, just as in any other
language, it is well-known that "subroutine [...] calls are horribly
slow" in perl[**]. Because I wanted to know what precisely 'horribly
slow' means, I wrote the following small test program:
------------
use Benchmark;
sub perl_dummy
{
return 1;
}
timethese(-1,
{
perl_dummy => sub { perl_dummy(); },
empty => sub { return 1; }});
------------
The results I got from that (averaging four runs and substracting the
average 'empty' speed from the average 'perl_dummy' speed) was that a
pure subroutine call alone takes about 1.36E-7 seconds for perl 5.10.1
running on a 3.2Ghz Core i3 computer. When using 1,2,3 as argument
list for perl_dummy, the time needed to call it (calculated in the
same way) was about 1.74E-7s. In line with the thesis from the paper,
I think that people are rather 'horrified' by function calls because
they are function calls (... and everyone knows that ...) than by the
prospect of runing some code which needs less than 0.0000002 to
execute.
[*]
http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-443.pdf
[**]
http://c2.com/cgi/wiki?WhyHatePerl
------------------------------
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 3982
***************************************
