[32422] in Perl-Users-Digest
Perl-Users Digest, Issue: 3689 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun May 13 16:09:27 2012
Date: Sun, 13 May 2012 13: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 Sun, 13 May 2012 Volume: 11 Number: 3689
Today's topics:
hash <nospam.gravitalsun.antispam@hotmail.com.nospam>
Re: hash <jurgenex@hotmail.com>
Re: hash <kst-u@mib.org>
Re: hash <jurgenex@hotmail.com>
Re: hash <nospam.gravitalsun.antispam@hotmail.com.nospam>
Re: hash <hjp-usenet2@hjp.at>
Re: hash <jurgenex@hotmail.com>
Re: hash <hjp-usenet2@hjp.at>
Re: hash <rweikusat@mssgmbh.com>
Re: hash <rweikusat@mssgmbh.com>
Re: hash <ben@morrow.me.uk>
Re: Taint mode help <rweikusat@mssgmbh.com>
Re: Taint mode help <ben@morrow.me.uk>
Re: Taint mode help <hjp-usenet2@hjp.at>
Re: Taint mode help <dave@invalid.invalid>
Windows control in PERL <hacker@ace158.com>
Re: Windows control in PERL <ben@morrow.me.uk>
Re: WWW::Mechanize and 3rd party APIs (Google) (Randal L. Schwartz)
Re: WWW::Mechanize and 3rd party APIs (Google) <JimSGibson@gmail.org>
Re: WWW::Mechanize and 3rd party APIs (Google) <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 13 May 2012 01:41:00 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@hotmail.com.nospam>
Subject: hash
Message-Id: <jomotv$2q9c$1@news.ntua.gr>
The clever equal $a ~~ @array is a lot of slower than exists $hash{$a}
Also hashing algorythm is much slower than binary search, so wouldn't be
better if we store key,values to btree structures instead of hashes ?
------------------------------
Date: Sat, 12 May 2012 15:58:28 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: hash
Message-Id: <akqtq754d40nm661i36nars1culq1kadna@4ax.com>
"George Mpouras" <nospam.gravitalsun.antispam@hotmail.com.nospam> wrote:
[...]
>Also hashing algorythm is much slower than binary search,
???
hash access is typically O(1) while binary search is O(log n). Why do
you think hashing is slower than binary search?
>so wouldn't be
>better if we store key,values to btree structures instead of hashes ?
Is this a question about the internal implementation of Perl hashes deep
down in the guts of the abstract Perl machine?
jue
------------------------------
Date: Sat, 12 May 2012 19:07:25 -0700
From: Keith Thompson <kst-u@mib.org>
Subject: Re: hash
Message-Id: <ln8vgwn89u.fsf@nuthaus.mib.org>
Jürgen Exner <jurgenex@hotmail.com> writes:
> "George Mpouras" <nospam.gravitalsun.antispam@hotmail.com.nospam> wrote:
> [...]
>>Also hashing algorythm is much slower than binary search,
>
> ???
>
> hash access is typically O(1) while binary search is O(log n). Why do
> you think hashing is slower than binary search?
Hashing itself is not really an algorithm; it's a data structure.
Some particular thing you do with hashing may well be slower than binary
search, but without knowing what what the OP is doing it's difficult to
speculate.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
Date: Sat, 12 May 2012 20:10:57 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: hash
Message-Id: <qe9uq7l5k48kntoeon37fe95v2jhnk66bb@4ax.com>
Keith Thompson <kst-u@mib.org> wrote:
>Jürgen Exner <jurgenex@hotmail.com> writes:
>> "George Mpouras" <nospam.gravitalsun.antispam@hotmail.com.nospam> wrote:
>> [...]
>>>Also hashing algorythm is much slower than binary search,
>>
>> ???
>>
>> hash access is typically O(1) while binary search is O(log n). Why do
>> you think hashing is slower than binary search?
>
>Hashing itself is not really an algorithm; it's a data structure.
True
>Some particular thing you do with hashing may well be slower than binary
>search,
Absolutely. That's why I said "typically". Of course, if you got a
degenerated hash then access might be as bad as a linear search.
>but without knowing what what the OP is doing it's difficult to
>speculate.
ACK
jue
------------------------------
Date: Sun, 13 May 2012 13:48:06 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@hotmail.com.nospam>
Subject: Re: hash
Message-Id: <joo3h6$1l6k$1@news.ntua.gr>
>> hash access is typically O(1) while binary search is O(log n). Why do
>> you think hashing is slower than binary search?
>
>Hashing itself is not really an algorithm; it's a data structure.
True
hash is a data structure and there is a an internal logic of how to retrieve
values. If there is a big number of keys then hash may have conflict keys;
these conflicts are stored as lists where its retrieval is slow (n).
Retrieving btree values is much faster O(log n). There is no particular
problem, I have a conversation with my colleague discussing this and maybe
there is a need for a module to do it easy.
------------------------------
Date: Sun, 13 May 2012 12:49:17 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: hash
Message-Id: <slrnjqv4dd.5fp.hjp-usenet2@hrunkner.hjp.at>
On 2012-05-13 03:10, Jürgen Exner <jurgenex@hotmail.com> wrote:
> Keith Thompson <kst-u@mib.org> wrote:
>>Jürgen Exner <jurgenex@hotmail.com> writes:
>>> "George Mpouras" <nospam.gravitalsun.antispam@hotmail.com.nospam> wrote:
>>> [...]
>>>>Also hashing algorythm is much slower than binary search,
>>>
>>> ???
>>>
>>> hash access is typically O(1) while binary search is O(log n). Why do
>>> you think hashing is slower than binary search?
Big-O notation only tells you how an algorithm scales with increasing n.
It doesn't tell you how it performs for any particular n (especially not
for a small n).
>>Hashing itself is not really an algorithm; it's a data structure.
>
> True
<nitpick>
The data structure is called a "hash table". There is also the "hash
function". Both are frequently abbreviated as "hash". "Hashing" may
refer to computing a hash function or to filling a hash table. In
both cases it is an algorithm.
</nitpick>
>>Some particular thing you do with hashing may well be slower than binary
>>search,
>
> Absolutely. That's why I said "typically". Of course, if you got a
> degenerated hash then access might be as bad as a linear search.
A degenerated hash is not necessary.
A successful lookup of an element in a hash consists of the following
steps:
1) compute the hash of the lookup key (cost: c1 * length(lookup_key))
2) compute the location of element in the hash (cost: negligible)
3) compare the lookup key to the element key
(cost c2 * length(lookup_key) if successfull, almost zero if
unsuccessfull, because two strings with the same hash collision are
unlikely to have a common prefix).
4) If unsuccessfull, compute the location of the next element (this may
be a simple pointer lookup or involve the computation of a new hash)
and continue at 3.
If the hash is properly constructed, step 4 is very rare, so the access
time is
c1 * length(lookup_key) + c2 * length(lookup_key)
For a binary tree, you have to descend d levels, and do a string
comparison at every level, so the cost is
c2 * length(common_prefix(lookup_key, node1_key)) +
c2 * length(common_prefix(lookup_key, node2_key)) +
...
c2 * length(lookup_key)
(the common prefix is likely to get longer as we descend down the tree)
Note that the last term is the same, so we can eliminate it.
It follows that the hash access is faster than the binary tree[1] access
if the computation of the hash is faster than the (d-1) partial string
compares. This depends on the length of lookup_key, the distribution of
the keys in the dictionary, the hash algorithm, the depth of the tree,
how much of your data is already in the CPU cache, etc.
In short, it is impossible to say that a hash is faster than a binary
tree or vice versa. You have to benchmark particular implementations for
particular data.
There are some general observations, though:
The tree gets slower with increasing depth while the hash is quite
insensitive to the number of elements, so the hash has an advantage
for a large number of elements.
For a hash lookup you have to compute a hash of the entire key up front,
while for the tree you only have to compare the common prefix (+1 byte),
so the tree has an advantage if the keys are long (and don't have a
common prefix).
The hash is likely to be more cache friendly because you need to
look only at two contiguous memory locations while in the tree you need
to look at (d+1) memory locations.
>>but without knowing what what the OP is doing it's difficult to
>>speculate.
>
> ACK
Also ACK.
hp
[1] George also wrote "btree", which is not a binary tree. For a btree
it gets even more complicated, but btrees are normally used for disk
data structures, not in memory, although some in-memory data structures
(e.g. Judy arrays) use similar techniques to exploit caching.
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Sun, 13 May 2012 05:01:09 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: hash
Message-Id: <i18vq7ttq6j3vnfjq4g7s45pqe8df9mi5m@4ax.com>
"George Mpouras" <nospam.gravitalsun.antispam@hotmail.com.nospam> wrote:
>
>
>>> hash access is typically O(1) while binary search is O(log n). Why do
>>> you think hashing is slower than binary search?
>>
>>Hashing itself is not really an algorithm; it's a data structure.
>
>True
>
>hash is a data structure and there is a an internal logic of how to retrieve
>values. If there is a big number of keys then hash may have conflict keys;
That has nothing to do with the number keys but only with how the keys
are distributed across the buckets. Degenerated hashes where all the
keys point into the same bucket can happen with any number of keys. But
the probability is very small, therefore on average hashes are
significantly faster than trees.
>these conflicts are stored as lists where its retrieval is slow (n).
If they are stored as simple lists, then yes. But there are other ways
how buckets can be organized. If Perl uses a simple list or a more
complex structure I do not know.
If Perl uses simple lists then I presume that the problem of hash key
conflicts is not very relevant.
>Retrieving btree values is much faster O(log n).
Unfortunately for trees O(log n) it is for all cases, including best
case and typical case, while hashes are O(1) for both, best as well as
typical case.
jue
------------------------------
Date: Sun, 13 May 2012 15:30:00 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: hash
Message-Id: <slrnjqvdqq.rfn.hjp-usenet2@hrunkner.hjp.at>
On 2012-05-13 12:01, Jürgen Exner <jurgenex@hotmail.com> wrote:
> "George Mpouras" <nospam.gravitalsun.antispam@hotmail.com.nospam> wrote:
>>>> hash access is typically O(1) while binary search is O(log n). Why do
>>>> you think hashing is slower than binary search?
>>>
>>>Hashing itself is not really an algorithm; it's a data structure.
>>
>>True
>>
>>hash is a data structure and there is a an internal logic of how to retrieve
>>values. If there is a big number of keys then hash may have conflict keys;
>
> That has nothing to do with the number keys but only with how the keys
> are distributed across the buckets. Degenerated hashes where all the
> keys point into the same bucket can happen with any number of keys.
That's the worst case.
> But the probability is very small, therefore on average hashes are
> significantly faster than trees.
The average case depends on the load factor.
>>these conflicts are stored as lists where its retrieval is slow (n).
>
> If they are stored as simple lists, then yes. But there are other ways
> how buckets can be organized. If Perl uses a simple list or a more
> complex structure I do not know. If Perl uses simple lists then I
> presume that the problem of hash key conflicts is not very relevant.
Perl uses simple lists - see PerlGuts Illustrated[1]. This is not a
problem. Since perl keeps the load factor (the ratio between number of
elements and slots) below 1 and it can change the seed of the hash
function if a hash degenerates, the lists are always very short -
certainly shorter than the depth of a binary tree with the same number
of elements.
hp
[1] http://cpansearch.perl.org/src/RURBAN/illguts-0.42/index-14.html
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Sun, 13 May 2012 19:00:21 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: hash
Message-Id: <87k40gyn9m.fsf@sapphire.mobileactivedefense.com>
Keith Thompson <kst-u@mib.org> writes:
> Jürgen Exner <jurgenex@hotmail.com> writes:
>> "George Mpouras" <nospam.gravitalsun.antispam@hotmail.com.nospam> wrote:
>> [...]
>>>Also hashing algorythm is much slower than binary search,
>>
>> ???
>>
>> hash access is typically O(1) while binary search is O(log n). Why do
>> you think hashing is slower than binary search?
>
> Hashing itself is not really an algorithm; it's a data structure.
Hashing is an algorithm and not a data structure: Usually, it refers
to 'calculate a "hash value"' (relatively small integer) from some
(significantly) larger 'input data value'. Usually, this hash value is
then used as index into a vector of pointers to locate 'a list' on
which some kind of data item associated with this 'input data value'
(key) should either exist or needs to be put on.
------------------------------
Date: Sun, 13 May 2012 19:11:39 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: hash
Message-Id: <87fwb4ymqs.fsf@sapphire.mobileactivedefense.com>
"George Mpouras" <nospam.gravitalsun.antispam@hotmail.com.nospam>
writes:
[...]
> hash is a data structure and there is a an internal logic of how to
> retrieve values. If there is a big number of keys then hash may have
> conflict keys; these conflicts are stored as lists where its retrieval
> is slow (n). Retrieving btree values is much faster O(log n).
This doesn't exactly make sense: Let's assume I'm storing 1024
key-value pairs in a hash table and what I end up with are 128 lists of
length 8. Ignoring the overhead for calculating the hash values, this
means that I can locate each of these 1024 pairs with doing at most 8
key comparisons. If the same 1024 key-value pairs where organized as
some kind of balanced binary search tree, that would be log2(1024) =
10 key comparisons. Since '128 pointers' isn't exactly a lot of data
nowadays, it should be possible to double the size of the table and
thus end up with 256 list of length 4 and so on.
NB: This is a theoretical consideration and 'in practice' things
aren't that simple. But it should be sufficient to show that 'searcing
on a linked list is slow while ...' doesn't hold water.
------------------------------
Date: Sun, 13 May 2012 20:00:39 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: hash
Message-Id: <nvc589-gim1.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Keith Thompson <kst-u@mib.org> writes:
> > Jürgen Exner <jurgenex@hotmail.com> writes:
> >> "George Mpouras" <nospam.gravitalsun.antispam@hotmail.com.nospam> wrote:
> >> [...]
> >>>Also hashing algorythm is much slower than binary search,
> >>
> >> hash access is typically O(1) while binary search is O(log n). Why do
> >> you think hashing is slower than binary search?
> >
> > Hashing itself is not really an algorithm; it's a data structure.
>
> Hashing is an algorithm and not a data structure: Usually, it refers
> to 'calculate a "hash value"' (relatively small integer) from some
> (significantly) larger 'input data value'. Usually, this hash value is
> then used as index into a vector of pointers to locate 'a list' on
> which some kind of data item associated with this 'input data value'
> (key) should either exist or needs to be put on.
I don't know about 'usually'. One of the more common uses of hash
algorithms is in message digests and digital signatures and such.
I think perhaps Keith meant to say 'A hash *table* is not an algorithm,
it's a data structure', which is entirely true.
Ben
------------------------------
Date: Fri, 11 May 2012 15:25:14 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Taint mode help
Message-Id: <87likykd6d.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
[...]
> (I'm not actually certain there isn't some way, on some system, of
> arranging for readdir to return something which chdir will
> misinterpret.
If the directory is writeable by someone interested in devising
mischief, what readdir returns as the name of a directory and
possibly, what a following stat configirmed as such, may well be a
symlink to a completely different part of the filesystem by the time
chdir interprets it.
------------------------------
Date: Fri, 11 May 2012 22:36:08 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Taint mode help
Message-Id: <8bd089-b8g.ln1@anubis.morrow.me.uk>
Quoth "Dave Saville" <dave@invalid.invalid>:
> On Thu, 10 May 2012 20:56:32 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
> > Quoth "Dave Saville" <dave@invalid.invalid>:
> > > One of my cgi scripts is throwing:
> > >
> > > Insecure dependency in chdir while running with -t switch at
> > > d:/usr/lib/perl/lib/5.8.2/File/Find.pm line 814., referer:
> > > *cgi-bin/upload.pl
> >
> > -t and not -T? That's a bad idea for a CGI script. So is using 5.8.2,
> > which is 9 years old now and entirely unsupported.
>
> -t Ooops a forgotton switch. Well spotted thanks.
Heh. These things happen... :)
> 5.8.2 happens to be the latest that actually
> works on my platform and if it ain't broke...... The latest port has a
> heap of problems that are yet to be resolved. :-(
What platform are you on? If you're interested in getting a more recent
perl to build I'd be happy to try and walk you through it.
Ben
------------------------------
Date: Sat, 12 May 2012 10:51:41 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Taint mode help
Message-Id: <slrnjqs94t.e3r.hjp-usenet2@hrunkner.hjp.at>
On 2012-05-10 22:15, Ben Morrow <ben@morrow.me.uk> wrote:
> (I'm not actually certain there isn't some way, on some system, of
> arranging for readdir to return something which chdir will misinterpret.
> ISTR, for instance, that it's possible for a misconfigured Samba server
> to return directory names with / in,
On a system where / isn't the directory separator (like MacOS <= 9 or
VMS)? Does Samba run on these systems? It may be be possible to get samba
to return filenames with "\" in it verbatim, though.
There was also a similar problem with the original Sun NFS server: The
NFS protocol avoided the problem of different path separators by never
sending a path over the network - you only send components. So if a Unix
client wants to create a file "/foo/bar/baz", it doesn't send a request
«create file "/foo/bar/baz"» - instead it aquires the directory handle
of "/foo/bar" and then sends a request «create file $dirhandle, "baz"».
Now what happened when a client sent a request «create file $dirhandle,
"ba/zoom"» (which could happen with non-Unix NFS clients)? The NFS
server was part of the kernel, and it called all the low-level file
handling functions directly - functions which were written on the
assumption that a path component could never contain a / because all the
system calls treat / as a separator. So the NFS server could create a
directory entry with an embedded /. Readdir of course returned the / in
the entry, but there was no way to access the file from SunOS, since all
the system calls (open, unlink, ...) interpreted the / as a separator.
(I don't remember whether it was still accessible by NFS).
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Sat, 12 May 2012 10:57:42 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Taint mode help
Message-Id: <fV45K0OBJxbE-pn2-4yg05oBtBKS3@localhost>
On Fri, 11 May 2012 21:36:08 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
<snip>
> What platform are you on? If you're interested in getting a more recent
> perl to build I'd be happy to try and walk you through it.
>
>
OS/2 :-) There have been working later ports but I never got around to
updating. What I had works and to me changing the version of perl is
not a trivial matter if you have a lot of installed modules. I also
don't have access to the required patches although I could get them I
think.
At the moment I am really in a hole because I need a couple of modules
that need compiling and unless you have the *exact* same
setup/environment as the porter (binary distro) then nothing compiles.
OS/2 although it has lots of unixy features the one thing they did not
copy was the file system so it suffers from DOS drive letters to add
to the fun :-( Amongst other things the current port can't get the
path substitution correct. ie if it was built to say x:/perl5 and you
want it in y:/usr/lib/perl or even y:/perl5 by means of the
PERLLIB_PREFIX environmental than it screws the path up and then can't
find anything. Another problem, which may be related, is that if it
tries to compile something it can't find *.h files that are clearly on
the drive. But there is only one guy porting and I have to wait until
he gets around to looking at it. I have looked at building it myself
before but there are *so* many other libraries etc. it expects to find
that I gave up.
Thanks for the offer though.
--
Regards
Dave Saville
------------------------------
Date: Sun, 13 May 2012 04:09:23 +0200
From: Hacker <hacker@ace158.com>
Subject: Windows control in PERL
Message-Id: <2012051304092327396-hacker@ace158com>
I want to create a windows control library for PERL like the Screen
module, but I am old fasioned and I do not like Objects, especially
not in PERL. Not that I can not program in an object oriented
language, I had Object Oriented languages in college and am well
versed in the discipline - I just think that there are languages,
like Beta, where it is good form to program Object Oriented, and
then there are others, like C and PERL, where it is not.
So I am old fashioned.
What we need is to be able to lock the screen at a certain size, with
the border being simple, so that there is no resize widget, for
instance 100x50, and then we will need cls(), up, down, left and right.
And at(), and then I would be rock and roll. Up and down, etc, could
be constants that you could print.
The reason for this would be to bring the good old hackboard back to
the xwindows computer. There is a lot of old Qbasic software out there
and a lot of big business men loving it, and they have no where to
go and no means of porting their equipment if there is no BASIC like
alternative.
I do not know if you care for that and you probably freak a full circle
when I mention BASIC, but the fact of the matter is that the industry
needs a hackboard with simple screen control, something everybody
understands. Then they will explode in an orgnate of storage facility
systems and adress book and so on.
So...
Is there anyone who would like to help me with this. If you imply that
I could just do it like it is done in the Screen module, you are not
doing me a favor. I am not that good a PERL hacker. The Screen module
builds on Term and Term builds on Cap, and frankly, I do not know what
is going on. Also if I did, I would not be here asking you now. And
lastly, is it not just basicly pissing on me, I would relent that.
Now, if you DO know what is going on in Screen, maybe you can help me
get terminal.lib up and running.
Just this.
--
Nobody dies in WarZone!
------------------------------
Date: Sun, 13 May 2012 16:05:27 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Windows control in PERL
Message-Id: <n6v489-99k1.ln1@anubis.morrow.me.uk>
Quoth Hacker <hacker@ace158.com>:
>
> Is there anyone who would like to help me with this. If you imply that
> I could just do it like it is done in the Screen module, you are not
> doing me a favor. I am not that good a PERL hacker. The Screen module
> builds on Term and Term builds on Cap, and frankly, I do not know what
> is going on. Also if I did, I would not be here asking you now. And
> lastly, is it not just basicly pissing on me, I would relent that.
>
> Now, if you DO know what is going on in Screen, maybe you can help me
> get terminal.lib up and running.
Terminal control works by printing special escape sequences to the
terminal. Termcap is a database of which escape sequences you need for
which terminal, so in principle you can't avoid using it. In practice,
pretty much all terminals support the ANSI escape sequences now, so you
could just hardcode those. I believe that's what the Term::ANSIScreen
module does.
Ben
------------------------------
Date: Fri, 11 May 2012 09:50:20 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: WWW::Mechanize and 3rd party APIs (Google)
Message-Id: <86pqaay84z.fsf@red.stonehenge.com>
>>>>> "Justin" == Justin C <justin.1203@purestblue.com> writes:
Justin> Before anyone goes off the deep end about the fact that we're
Justin> looking to make money by marketing to those businesses,
This is even worse.
YOU'RE A SPAMMER, through and through.
If you were ethical, you'd simply set up a web site, and let *them* come
to *you* of their own will.
Damn idiots crapping all over the internet.
{sigh}
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
------------------------------
Date: Fri, 11 May 2012 14:15:10 -0700
From: Jim Gibson <JimSGibson@gmail.org>
Subject: Re: WWW::Mechanize and 3rd party APIs (Google)
Message-Id: <JimSGibson-BCB5CB.14151011052012@news.individual.net>
In article <86pqaay84z.fsf@red.stonehenge.com>,
merlyn@stonehenge.com (Randal L. Schwartz) wrote:
> >>>>> "Justin" == Justin C <justin.1203@purestblue.com> writes:
>
> Justin> Before anyone goes off the deep end about the fact that we're
> Justin> looking to make money by marketing to those businesses,
>
> This is even worse.
>
> YOU'RE A SPAMMER, through and through.
>
> If you were ethical, you'd simply set up a web site, and let *them* come
> to *you* of their own will.
Since when is fetching and saving data from a publicly-available website
unethical? After all, Google and all other search engines do it for
their own commercial purposes.
------------------------------
Date: Fri, 11 May 2012 22:56:06 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: WWW::Mechanize and 3rd party APIs (Google)
Message-Id: <mge089-vcg.ln1@anubis.morrow.me.uk>
Quoth Jim Gibson <JimSGibson@gmail.org>:
> In article <86pqaay84z.fsf@red.stonehenge.com>,
> merlyn@stonehenge.com (Randal L. Schwartz) wrote:
> > >>>>> "Justin" == Justin C <justin.1203@purestblue.com> writes:
> >
> > Justin> Before anyone goes off the deep end about the fact that we're
> > Justin> looking to make money by marketing to those businesses,
> >
> > This is even worse.
> >
> > YOU'RE A SPAMMER, through and through.
> >
> > If you were ethical, you'd simply set up a web site, and let *them* come
> > to *you* of their own will.
>
> Since when is fetching and saving data from a publicly-available website
> unethical? After all, Google and all other search engines do it for
> their own commercial purposes.
If you're doing so in order to automatically email them, regardless of
the content of those emails, then Randal is right: that's spamming.
(Traditional spambots, such as don't appear to exist much any more, did
nothing more than go through publically-available websites looking for
email addresses. There were no *copyright* issues with that, which is
what we were originally discussing, but there were and are serious
data-protection and privacy issues.)
If you're doing so in order to have a real human contact them, through
channels normally used for that sort of communication, after properly
considering whether the recipient would consider the communication
appropriate, that's much more of a grey area. It is still sufficiently
grey that you need to look *very* carefully at what you are doing,
starting with trying to honestly picture how you would react in their
place.
It's certainly not something *I* would want to be doing--it's a good
deal too close to the line--but then, I'm not trying to run a business.
Ben
------------------------------
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 3689
***************************************
