[32753] in Perl-Users-Digest
Perl-Users Digest, Issue: 4017 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Aug 20 16:09:40 2013
Date: Tue, 20 Aug 2013 13:09:03 -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 Tue, 20 Aug 2013 Volume: 11 Number: 4017
Today's topics:
Re: can some please help me , can we use perl for testi (Jens Thoms Toerring)
Re: openssl compatible key and IV calculation <rweikusat@mobileactivedefense.com>
Re: openssl compatible key and IV calculation <jimsgibson@gmail.com>
processing strings char-by-char <rweikusat@mobileactivedefense.com>
Re: processing strings char-by-char <derykus@gmail.com>
Re: processing strings char-by-char <rweikusat@mobileactivedefense.com>
Re: processing strings char-by-char <jwkrahn@example.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 18 Aug 2013 01:27:55 GMT
From: jt@toerring.de (Jens Thoms Toerring)
Subject: Re: can some please help me , can we use perl for testing java applications.
Message-Id: <b7am8pFf4biU1@mid.uni-berlin.de>
Suresh Macharla <suri.71@gmail.com> wrote:
> I my company there are 2 divisions one is for .net and other one is for
> java. coming to java they will develop both client applications and server
> end services/ middle ware services. So in this case how can i use perl in
> testing both client as well as server side modules.
To be honest, I have no better idea of what kind of tests you
want to do. I'm sure that Perl is quite well-suited for doing
tests (whatever they are), but so are many other languages.
I start to get a feeling that this question is one like "are
japanese saws better for cutting wood than others"? Japanese
saws cut the wood when you pull while saws in many other
countries cut when you push. Which is better? The answer is "it
depends". If the people that do the sawing are used to japanese
saws they rather likely will be more efficient with a saw that
cuts on the pull stroke. People used to other saws will probably
be much happier with a "normal" (i.e. non-japanese) saw.
So if in your company there's a lot of expertise in Java and
.net languages then I would expect that they'll be more effec-
tive using those languages also for testing than with a lan-
guage they may never have used.
What I want to say is that there's nothing wrong about Perl, but
claiming that Perl is the perfect tool for all tasks imaginable,
just because it's Perl, would be preposterous. There are a lot
of very useful modules for Perl that can help you with testing
all kinds of things, but that doesn't mean other languages do
not have their own merits and modules that are well-suited for
the tasks at hand.
As long as you don't explain what exactly you want to do it
looks like you're asking for the perfect tool before you have
figuring out what the problem are that you have to solve (and
even then you still have to consider if there's anyone able to
use that "perfect" tool).
So, again: exactly what kind of tests are you talking about?
What are those "client and server side modules" and what do
you want to test?
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
------------------------------
Date: Sat, 17 Aug 2013 15:08:32 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <87d2pcpfz3.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> Ben Morrow <ben@morrow.me.uk> writes:
[MD5 hash]
>> Suppose you know (or guess) the input is an English phrase. Does
>> this make some parts of the output space more likely than others? If it
>> does you've just weakened your key, by making it less random.
>
> If this was so, someone had inadvertently invented an algorithm
> capable of understanding English. This algorithm might be a bad 'key
> generation algorithm' but it probably a great, commercial opportunity.
>
> Joking aside, a lossy compression function (like MD5 or any other hash
> function) always causes 'loss of information' which implies 'loss of
> entropy' if there was more in the input than can remain in the 16
> output bytes.
For 'fairness of discussion': My best attempt to make sense of Ben's
statement is that this refers to what Bob Jenkins (google for 'hash
functions and block ciphers', read the 'Dr Dobbs article) called 'a
funnel in a hash function': One property of a good hash function (in
sense that its output is uniformly distributed) would be
that each output bit depends on all input bits. A hash function is
said to have a funnel when certain input bits or groups of input bits
only affect certain output bits (or groups of output bits). A trivial
example of such a bad hash function would be
sub hash {
my $r;
$r ^= ord($1) while $_[0] =~ /\G(.)/g;
return $r;
}
This takes a string as input and returns 1 byte of output, funnelling
all bits whose offset (counting from the start of the string) is an
integral mutiple of 8 into bit 0 of the output and so forth which
implies that all permutations of some set 'input characters' hash to the
same value. This 'gratuitious loss of information' could be called
'making the input less random'.
But assuming this was meant, that would question the quality of MD5 as
general hash functions, not one of its 'cryptographically interesting
properties'. I admit that I didn't (and won't) try to analyze the MD5
function in this respect but I'm willing to trust the guy who invented
it in this respect unless there's specific information to the
contrary (also, the article I mentioned above uses MD4 as one example
of a hash function and states that it was funnel-free).
Aside: The while-loop above is one way to process some string
character-by-character. Another would be
for (split(//, $string)) {
}
Are there more?
------------------------------
Date: Mon, 19 Aug 2013 17:28:50 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <190820131728502505%jimsgibson@gmail.com>
In article <87d2pcpfz3.fsf@sapphire.mobileactivedefense.com>, Rainer
Weikusat <rweikusat@mobileactivedefense.com> wrote:
> Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
>
> sub hash {
> my $r;
> $r ^= ord($1) while $_[0] =~ /\G(.)/g;
> return $r;
> }
>
>
> Aside: The while-loop above is one way to process some string
> character-by-character. Another would be
>
> for (split(//, $string)) {
> }
>
> Are there more?
for my $i ( 0..(length($string)-1) ) {
my $c = substr($string,$i,1);
...
}
--
Jim Gibson
------------------------------
Date: Sun, 18 Aug 2013 20:10:31 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: processing strings char-by-char
Message-Id: <871u5qx1aw.fsf@sapphire.mobileactivedefense.com>
So far, I came up with three obvious ways to do that:
$r ^= ord($1) while $string =~ /\G(.)/g;
This extracts successive characters from the string with a 'moving
regex match'.
$r ^= ord($_) for split(//, $string);
This splits the string into a list of characters and loops over that.
$r ^= ord(substr($string, $_, 1)) for 0 .. length($string) - 1;
This loops over the 'character positions' in $string and uses substr
to extract the corresponding characters.
When benchmarking these three, the one I like best (the regex match)
comes out slowest. The 'split string, loop over list' method is about
twice as fast as the regex and the most clumsy one (IMHO), substr,
runs at about 1.5 times the speed of the split loop.
-----------------
use Benchmark;
my $string = 'A' x 100;
timethese(-3,
{
while => sub {
my $r;
$r ^= ord($1) while $string =~ /\G(.)/g;
},
for => sub {
my $r;
$r ^= ord($_) for split(//, $string);
},
substr => sub {
my $r;
$r ^= ord(substr($string, $_, 1)) for 0 .. length($string) - 1;
}});
------------------------------
Date: Sun, 18 Aug 2013 14:58:00 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: processing strings char-by-char
Message-Id: <kurg2g$a1u$1@speranza.aioe.org>
On 8/18/2013 12:10 PM, Rainer Weikusat wrote:
> So far, I came up with three obvious ways to do that:
>
> $r ^= ord($1) while $string =~ /\G(.)/g;
>
> This extracts successive characters from the string with a 'moving
> regex match'.
>
> $r ^= ord($_) for split(//, $string);
>
> This splits the string into a list of characters and loops over that.
>
> $r ^= ord(substr($string, $_, 1)) for 0 .. length($string) - 1;
>
> This loops over the 'character positions' in $string and uses substr
> to extract the corresponding characters.
>
> When benchmarking these three, the one I like best (the regex match)
> comes out slowest. The 'split string, loop over list' method is about
> twice as fast as the regex and the most clumsy one (IMHO), substr,
> runs at about 1.5 times the speed of the split loop.
>
> -----------------
> use Benchmark;
>
> my $string = 'A' x 100;
>
> timethese(-3,
> {
> while => sub {
> my $r;
> $r ^= ord($1) while $string =~ /\G(.)/g;
> },
>
> for => sub {
> my $r;
> $r ^= ord($_) for split(//, $string);
> },
>
> substr => sub {
> my $r;
> $r ^= ord(substr($string, $_, 1)) for 0 .. length($string) - 1;
> }});
>
Not fast... "aber an der unterseite vom Fass"...
my $r;
$r ^= unpack "x${_}a",$string for 0..length($string)-1;
--
Charles DeRykus
------------------------------
Date: Mon, 19 Aug 2013 12:52:50 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: processing strings char-by-char
Message-Id: <87zjsdlwx9.fsf@sapphire.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
[...]
>> $r ^= ord($1) while $string =~ /\G(.)/g;
[...]
>> $r ^= ord($_) for split(//, $string);
[...]
>> $r ^= ord(substr($string, $_, 1)) for 0 .. length($string) - 1;
[...]
> $r ^= unpack "x${_}a",$string for 0..length($string)-1;
I had the idea that something should be possible here with 'pack' for
some weird reason but didn't think of unpack. Another midfield method
(slower than split, faster than the slower ones)
$r ^= ord($_) for unpack('(a)*', $string);
------------------------------
Date: Mon, 19 Aug 2013 19:57:18 -0700
From: "John W. Krahn" <jwkrahn@example.com>
Subject: Re: processing strings char-by-char
Message-Id: <jWAQt.126237$po1.11162@fx15.iad>
Rainer Weikusat wrote:
> Charles DeRykus<derykus@gmail.com> writes:
>
> [...]
>
>>> $r ^= ord($1) while $string =~ /\G(.)/g;
>
> [...]
>
>>> $r ^= ord($_) for split(//, $string);
>
> [...]
>
>
>>> $r ^= ord(substr($string, $_, 1)) for 0 .. length($string) - 1;
>
> [...]
>
>> $r ^= unpack "x${_}a",$string for 0..length($string)-1;
>
> I had the idea that something should be possible here with 'pack' for
> some weird reason but didn't think of unpack. Another midfield method
> (slower than split, faster than the slower ones)
>
> $r ^= ord($_) for unpack('(a)*', $string);
$r ^= ord($_) for $string =~ /./g;
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: 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 4017
***************************************
