[28084] in Perl-Users-Digest
Perl-Users Digest, Issue: 9448 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jul 11 14:05:54 2006
Date: Tue, 11 Jul 2006 11:05: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 Tue, 11 Jul 2006 Volume: 10 Number: 9448
Today's topics:
Re: Get <tzz@lifelogs.com>
Re: global variables in a web service (David Combs)
Re: global variables in a web service <tadmc@augustmail.com>
Problem when embedding 2 Perl interpreters in C++ <riteshkapoor@gmail.com>
Re: Problem when embedding 2 Perl interpreters in C++ <riteshkapoor@gmail.com>
Re: Problem with Multi- threaded Server <tzz@lifelogs.com>
Re: processing large numbers/values/figures xhoster@gmail.com
Results in multiple pages. Takes too much time premgrps@gmail.com
Re: smarter zipcode search algorithm <premgrps@gmail.com>
Re: This works fine, but it is kinda complicated <caesar@miskatonic.edu>
Translate code or compile a win DLL <venom.zero.zero@gmail.com>
Re: Translate code or compile a win DLL <sherm@Sherm-Pendleys-Computer.local>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 11 Jul 2006 10:59:33 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Get
Message-Id: <g69zmfgw5ka.fsf@CN1374059D0130.kendall.corp.akamai.com>
On 10 Jul 2006, sherm@sherm-pendleys-computer.local wrote:
> "M" <no@spam.co.name> writes:
>
>> I have this:
>>
>> @content = split(/\n/, get "http://my.domain.com/acc/ip.cgi");
>>
>> Which pulls data from cgi script once every few minutes. Is there an easy
>> way to convert to pulling data from a local file in the same directory?
>
> By "easy", do you mean that you want to continue using LWP, while giving
> users the option to work with both remote and local files?
>
> If so, you could supply a file:// URI, like this:
>
> @content = split(/\n/, get "file:///path/to/the/file.txt");
>
> Note that this isn't as efficient as open()ing the file and reading it dir-
> ectly. You'd only want to do it this way if you want to allow the user to
> supply any one of a variety of URI schemes supported by LWP.
An even more general approach would be to break out the HTTP/file
handling, e.g.
@content = <>; # read from STDIN
and then run your program with the right input:
curl 'http://my.domain.com/acc/ip.cgi' | yourprogram.pl
yourprogram.pl < ./local_file.txt
This is more modular, but it's harder to do complicated HTTP
interactions. And, obviously, if your program already reads from
STDIN it won't be too happy.
Ted
------------------------------
Date: Tue, 11 Jul 2006 13:05:49 +0000 (UTC)
From: dkcombs@panix.com (David Combs)
Subject: Re: global variables in a web service
Message-Id: <e907nc$h99$1@reader2.panix.com>
In article <1151562549.712938.240560@d56g2000cwd.googlegroups.com>,
Brian McCauley <nobull67@gmail.com> wrote:
>
...
>
>My perfered solution is to use package variables and dynamic scoping.
"Dynamic scoping" -- nice terminology.
Why? Because (I assume) lots of computer-sci books on
general language implementation (and explanation) use it;
it is (or was) something pretty much everyone who in
cs courses studied languages like lisp and its relatives
and children.
Larry, of course, has chosen the seemingly opposite-meaning
term "local" for the concept in perl.
Sure would be nice if for p6 he'd switch to the more-generally
(across cs) terminology: people coming to perl from other
(interpretive) languages would know instantly what
it meant.
Unfortunately, those same people, seeing "local",
*also* think they understand *that*!
David
------------------------------
Date: Tue, 11 Jul 2006 10:41:53 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: global variables in a web service
Message-Id: <slrneb7hm1.91d.tadmc@magna.augustmail.com>
David Combs <dkcombs@panix.com> wrote:
> "Dynamic scoping" -- nice terminology.
> Larry, of course, has chosen the seemingly opposite-meaning
> term "local" for the concept in perl.
The biggest cause of the local() confusion is that "local" is short
for something, and most folks fillin the wrong something.
local() makes a "local value", not a "local variable".
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 11 Jul 2006 07:19:15 -0700
From: "ritesh" <riteshkapoor@gmail.com>
Subject: Problem when embedding 2 Perl interpreters in C++
Message-Id: <1152627555.392708.303710@m73g2000cwd.googlegroups.com>
Hi,
I'm facing a problem when embedding two perl interpreters in my C++
code.
My code has 2 threads - the GUI and the Core thread. The core thread
initializes a Perl interpreter and all works fine here. Both the
threads communicate via Events.
In a particular scenario the GUI thread, invokes a function which
further invokes a perl subroutine using the "perl_call_argv" call.
Since the GUI thread dosen't have a perl interpreter running on it
there are 2 options I have -
1. Use the PERL_SET_CONTEXT macro within the function that the GUI
thread calls, and then invoke the perl subroutine using the
"perl_call_argv" call. -- This works fine.
However I'm not sure if two threads should be sharing the same perl
interpreter. The Core thread might also make some calls to
"perl_call_argv" while the GUI thread is working. Would the
interpreter be intelligent enough to handle 2 threads? I found a
negative answer to this question at this link -
modperlbookDOTorg/html/ch24_03DOThtml
The text explicity states --> "This of course requires that each Perl
interpreter instance is accessed
by only one thread at any given time."
2. In second scenario, I create a new perl interpreter within the
function the GUI thread calls. Creation and destruction of the
interpreter happens within this function, since the interpreter is not
required by the GUI thread after the function returns. Here is the
function -
void function_for_gui_thread(char * perlFnToCall)
{
PL_perl_destruct_level = 1; /* keep setting this value to 1
before construction and destruction of the interperator for gui thread
*/
PerlInterpreter * guiPerlInterp = 0; /* this is the interp i
create within the function for GUI thread */
perlInterp = perl_alloc();
PERL_SET_CONTEXT(guiPerlInterp);
perl_construct(guiPerlInterp);
PL_perl_destruct_level = 1;
perl_run(guiPerlInterp);
char ** perl_args = (char**)sgMalloc(2*sizeof(char*));
perl_args[0] = "";
perl_args[1] = 0;
perl_call_argv(perlFnToCall, G_DISCARD, perl_args); /* for
simplicity I've added the perlFnToCall variable in the function
parameters, however it is determined in this function at runtime */
sgFree(perl_args);
PL_perl_destruct_level = 1;
perl_destruct(guiPerlInterp);
PL_perl_destruct_level = 1;
perl_free(guiPerlInterp);
PERL_SET_CONTEXT(corePerlInterpreter); /* corePerlInterpreter
is the interp initialized by the core thread */
}
Note that I set the context of the interpretor to the new guiPerlInterp
before I start using it. When exiting the function I set the context
back to corePerlInterpreter.
First question that comes to my mind is - Do I really need to set the
context back to corePerlInterpreter for the GUI thread, since it
dosen't need a perl interpreter after this function call?
Second when I run the program, the perl subroutine is invoked (i've
verified this using print commands), then within the perl subroutine
certain subroutines are invoked which use Perl XS routines. When the
control reaches the first such subroutine I get an error like this -
Usage : getReport(reportName)
and the program exits. The "getReport(reportName)" is the XS function
that the perl function invokes.
------------------------------------
Could you please help me out with this. The program works fine when I
use the first scenario. However I would like to use the second
scenario.
Thanks,
ritesh
------------------------------
Date: 11 Jul 2006 07:23:56 -0700
From: "ritesh" <riteshkapoor@gmail.com>
Subject: Re: Problem when embedding 2 Perl interpreters in C++
Message-Id: <1152627836.824878.5500@35g2000cwc.googlegroups.com>
One point that I missed out -
Right now I'm not sure if the perl I have on my system is compiled
using the options -
-Dusethreads -Duseithreads
Could this be the reason that the second scenario is giving these
"Usage : ..." errors?
Thanks,
ritesh
------------------------------
Date: Tue, 11 Jul 2006 10:54:52 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Problem with Multi- threaded Server
Message-Id: <g694pxoxkcj.fsf@CN1374059D0130.kendall.corp.akamai.com>
On 10 Jul 2006, xhoster@gmail.com wrote:
Ted Zlatanov <tzz@lifelogs.com> wrote: > On 30 Jun 2006,
xhoster@gmail.com wrote: >
>>> Or just fork instead of threads. Ask your boss "How much are you
>>> willing to spend to accomplish your stupid and arbitrary requirements?"
>>
>> I don't think that's a good question.
>
> I don't think it is universally, but in this case it seems like it.
OK, let me rephrase. The way you stated it, that's a terrible
question :) Most people wouldn't ask that from anyone in a business
environment, let alone their boss.
Also I wasn't looking to discuss the particulars of Perl threads and
why they may sometimes be better; my list was just suggestions. The
point was that threads are not *always* a bad idea, and when you don't
know the full story (which I'm sure you don't, unless you work with
the OP) it's more helpful to offer gentle suggestions than to be
forceful.
>> Here's a list of places where threads are usually better than
>> fork():
>>
>> - limited memory
>
> How does that work out in threads favor over fork? Perl's threads
> suck at memory, and on most systems forks use COW, which makes
> static structures quite compact.
Do some benchmarks if you like. I'm well-aware that fork() is better
in many ways, but I doubt you'll get better memory performance with
it. If you find otherwise, I'm all ears.
>> - threads need to collaborate, especially with semaphores and timing
>
> Sure, but I don't see any indication that that is the case here.
I am not talking about the threaded web server the OP wanted. These
are places where threads are *usually* better than fork(), and
my point was that you can't *always* say threads are worse or better
than forking.
>> - performance
>
> I'm unconvinced that Perl's threads have anything special to offer in that
> regard. Sure, if you have well-implemented code using threads vs. poorly
> implemented code using forks you might see a big difference. But that can
> go the other way around, too.
It depends on the task, but I'll say that if you look for performance
(especially where lots of data is shared, RO or RW), you should at
least consider threads. With GUI interaction you usually want a
separate UI thread to get good performance.
>> - lots of separate threads are expected
>
> I don't see a benefit of Perl's threads over forks in this respect, either.
Do some benchmarks if you like. I'm sure it takes fewer forks than
threads to run out of resources, all other things being equal.
Ted
------------------------------
Date: 11 Jul 2006 16:31:53 GMT
From: xhoster@gmail.com
Subject: Re: processing large numbers/values/figures
Message-Id: <20060711123536.640$qT@newsreader.com>
Lukas Ruf <ruf@rawip.org> wrote:
> > xhoster@gmail.com [10 Jul 2006 20:21:24 GMT]:
> >
> > Lukas Ruf <ruf@rawip.org> wrote:
> > > Dear all,
> > >
> > > for a large number of files, I must accumulate numbers found
> > > therein. For this accumulation, I have been running into
> > > number-overruns.
> >
> > I don't get overruns until 10**307. Are you sure it is an overrun
> > rather than just a loss of precision?
> >
>
> my problem is, after a certain value, it turns to -1.
No, it just prints as -1.
> printf("%15d should be in the range up to 2**34\n",
> $hsh{$key});
>
> Any hint what goes wrong?
You have a floating point number which is holding something which happens
to be an integer which doesn't fit into a 32bit integer. Your %d field is
coercing it into a 32 bit integer for formatting purposes, which does
overflow. Print with a floating point format, not an integet format.
printf "%20.f", 2**50;
1125899906842624
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 11 Jul 2006 10:10:19 -0700
From: premgrps@gmail.com
Subject: Results in multiple pages. Takes too much time
Message-Id: <1152637819.119324.309430@35g2000cwc.googlegroups.com>
Hi,
I have a table of a million records and wrote a CGI-PERL script to
display the results based on the user input. The results might be
anywhere from 100 to 1000 per query and presently I am displaying them
as 25 results per page.
Problem: Each query is taking about 20-30 seconds.
My solution: I have tried to optimize the table and also index the
table. I have actually converted a MS access database to SQL database,
so it wasn't previously indexed. Both optimization and indexing doesn't
give any good results. I always get a timeout. ie. it takes longer
after indexing and optimizing.
1. I was wondering if someone has a creative solution for this. ie.
reduce the time from 20-30 seconds to atleast 10 seconds.
2. I have links of pages of results beneath the first page result. When
each of these links are clicked it takes 20-30 seconds again. Is there
a way I can reduce the time taken for the subsequent pages are reduced?
I cannot use the LIMIT option in mysql, since I have a where clause
which has to search through the whole table. I tried using views and
using limits, but it takes as much time.
Please let me know.
Thanks.
------------------------------
Date: 11 Jul 2006 10:24:23 -0700
From: "PGPS" <premgrps@gmail.com>
Subject: Re: smarter zipcode search algorithm
Message-Id: <1152638663.340734.148100@m73g2000cwd.googlegroups.com>
Thanks for all your answers. I finally got the problem figured out
myself with a subquery. I'm new to databases though.
Thanks.
xhoster@gmail.com wrote:
> premgrps@gmail.com wrote:
> > Hi,
> > I have a database with two tables
> > a) A table of 2 million records with city, zip and associated
> > information (say XYZ) and
> > b) zipcode latitude, longitude table having >40,000 records/zip codes
>
> 40,001 and 10**89 are both greater than 40,000. I assuming you mean ~40,
> 000 rather than >40,000, otherwise it is meaningless.
>
> Is that ~40,000 records where each record is a zipcode?
> Or is it ~40,000 records per zip code?
>
>
> > PROBLEM:
> > I need to find the the XYZs within the the range of a certain zipcode.
> > This zipcode and radial range in miles is entered by the user (web
> > interface).
>
> Are you assuming zip codes to be points?
>
>
> > The brute force way is to calculate the distance between the user
> > zipcode and all the zipcodes in the database. Once the zipcode_range
> > subroutine gives back the zipcodes within a certain radius, I need to
> > find all the XYZs from the table #1.
>
> OK. You could probably even build a table giving the distances between
> every pair of zip codes, or at least every pair within 300 miles or so
> of each other.
>
> > Another approach is to find the zipcodes with a square region (min/max
> > of the user zipcode latitude/longitude position).
>
> Yep, that is another approach. You could construct a square around the
> circle, use a data structure to get everything in the square, then brute
> force just those things in the square to see if they are also within the
> circle. (neglecting the curvature of the earth.)
>
> > Both the approaches are consuming too much time. Especially if the
> > radial distance starts increasing.
>
> Starts increasing? You make it sound like an organic creature. Isn't it
> a simple number provided by the end user?
>
> Anyway, what is taking a long time? Getting a list of zip codes within
> X miles of the reference zip code? Turning that list into a list of all
> the qualifying XYZ?
>
> >
> > My questions:
> > 1. Is there any other smart way to do the above task.
>
> We only have the vaguest idea of how you are doing it now. You can't make
> tuning decisions based on vague notions.
>
> > 2. I am working on a 2.4ghz/512MB RAM machine. Any suggestions how to
> > increase the performance. Right now each select command to the
> > 2Million record table takes about a minute.
>
> What database system are you using? What query are you issuing to it?
> What indices exist? What does this have to do with Perl?
>
> If you are using Perl as your database system, have you looked at Tree::R?
>
> Xho
>
> --
> -------------------- http://NewsReader.Com/ --------------------
> Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 11 Jul 2006 14:55:25 -0000
From: Don Salad <caesar@miskatonic.edu>
Subject: Re: This works fine, but it is kinda complicated
Message-Id: <BC0MB80138909.4134837963@anonymous.poster>
"Perry Malen" <p...@nospamformethankyou.com> wrote:
> No, we don't. I took issue not with *why* you tried to check the url-ness,
> but with how. Your regexp:
>
> > /\[url]([a-zA-Z]+:\/\/[0-9a-zA-Z._\-\/\?\&\+]+)/
>
> says, in so many words: Following the [url] tag, match one or more
> characters a-z (case insensitive) followed by a colon followed by two
> slashes followed by one or more 'url-legal' characters. That's it. According
> to this regexp, 'mydog://hasfleas' is a valid url. Obviously, your good
> intentions are not well served by this particular pattern. You should either
> fix the regexp or just drop it altogether and trust that whatever follows
> the [url] tag is, in fact, a url.
You could have a host named 'hasfleas' on your local network, and some
customized 'mydog' protocol.
'mydog://hasfleas' *is* a syntactically valid URL. It just doesn't
work in most cases.
Thanks,
Don
------------------------------
Date: 11 Jul 2006 10:43:40 -0700
From: "VeNoM00" <venom.zero.zero@gmail.com>
Subject: Translate code or compile a win DLL
Message-Id: <1152639820.618954.198950@75g2000cwc.googlegroups.com>
Hi, i don't know perl but i need to use a script written in perl in the
application i'm developping.
Can i build it as DLL that exposes some functions so that i can use it?
Orelse :D can somebody translate this code for me in C/C++/VB/C# or
simply explain me what does it do?
http://cpan.uwinnipeg.ca/htdocs/WWW-Google-PageRank/WWW/Google/PageRank.pm.html
Thanks
------------------------------
Date: Tue, 11 Jul 2006 13:57:15 -0400
From: Sherm Pendley <sherm@Sherm-Pendleys-Computer.local>
Subject: Re: Translate code or compile a win DLL
Message-Id: <m2zmfggh38.fsf@Sherm-Pendleys-Computer.local>
"VeNoM00" <venom.zero.zero@gmail.com> writes:
> Hi, i don't know perl but i need to use a script written in perl in the
> application i'm developping.
>
> Can i build it as DLL that exposes some functions so that i can use it?
No, not that I'm aware of.
> Orelse :D can somebody translate this code for me in C/C++/VB/C# or
> simply explain me what does it do?
The synopsis is pretty clear - it's a Perl module for querying Google's
PageRank. A Perl module is generally not a complete script, btw, it's
similar in nature to a library in one of your target languages.
Google PageRank is not an obscure or new service... Surely there must be
similar libraries in your target language(s) already???
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
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:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#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 V10 Issue 9448
***************************************
