[18098] in Perl-Users-Digest
Perl-Users Digest, Issue: 258 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Feb 9 18:06:18 2001
Date: Fri, 9 Feb 2001 15:05:24 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <981759923-v10-i258@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Fri, 9 Feb 2001 Volume: 10 Number: 258
Today's topics:
A Question on OLE and EXCEL- help please dog222@my-deja.com
Best Way To Split & Initialize redinger@maine.rr.com
Re: Big Numbers <iltzu@sci.invalid>
Re: Can perl define vars dynamically? michael.cambray@wellpoint.com
Re: Can perl define vars dynamically? (John Joseph Trammell)
Re: Can perl define vars dynamically? <sariq@texas.net>
Re: Can perl define vars dynamically? <joe+usenet@sunstarsys.com>
Re: CFP: Yet Another Perl Conference 2001 <terrence.brannon@oracle.com>
Re: Converting nested hashes to objects <svadakke@cochin.qualcomm.com>
Re: Converting nested hashes to objects <sumus@aut.dk>
DBD install on solaris 7 ether_nut@my-deja.com
Re: Devel DProf and " dprofpp " <mothra@nowhereatall.com>
Re: Devel DProf and " dprofpp " <godzilla@stomp.stomp.tokyo>
Re: Devel DProf and " dprofpp " <mjcarman@home.com>
Re: Devel DProf and " dprofpp " <godzilla@stomp.stomp.tokyo>
Re: dialog with spawned process? big_amko@my-deja.com
Re: Food for guru's: read/modify/write works under Linu <frankvw@euronet.nl>
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 09 Feb 2001 19:34:57 GMT
From: dog222@my-deja.com
Subject: A Question on OLE and EXCEL- help please
Message-Id: <961gp1$g3k$1@nnrp1.deja.com>
Hello all Perl stud and studettes out there.
I have been learning Perl using the Coriollis"PERL Core Language Little
Black Book" and all of their scripts have been correct so far and now
it seems one of them is not working on my computer (I have NT). I am
using ActivePerl to run a simple OLE program to use EXCEL but I keep
getting and error.
What follows is the simple script and afterwords I post the error.
Can anyone tell me what is wrong with this script?
I thank you in advance!!!!
use OLE;
$operand1 = '2';
$operand2 = '2';
$excelobject = CreateObject OLE 'Excel.Sheet';
$excelobject->Cells(1,1)->{value}=$operand1;
$excelobject->Cells(2,1)->{value}=$operand2;
$excelobject->Cells(3,1)->{formula}='=R1C1 + R2C1';
$sum = $excelobject->Cells(3,1)->{Value};
$excelobject->Quit();
print "According to Microsoft Excel, ","$operand1 + $operand2
=$sum.\n";
ERROR MESSAGE!!!!!!
"Cant use and undefined value as a hash reference at line 5."
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: Fri, 09 Feb 2001 21:06:04 GMT
From: redinger@maine.rr.com
Subject: Best Way To Split & Initialize
Message-Id: <961m3k$l8g$1@nnrp1.deja.com>
I'm wondering if there are any shortcuts that people use to split and
initialize a list of values from a file at the same time?
An example follows. My concern is, if one of the fields in the input
file is empty, split will return undef. I'm wondering if there's a
shortcut to changing that to '' without going through each field:
$fld1 ||= ''; $fld2 ||= '', etc.
This question is posed because there are alot more fields than just 4 in
my actual program. :)
My reference example (This code isn't actually meant to be runnable,
just a representation of an idea. Please excuse any errors):
#!/usr/bin/perl -w
use strict;
open FILE, "my_file";
while (<FILE>) {
my ($fld1, $fld2, $fld3, $fld4) = split /\|/;
# currently, I just do this, since copy & paste make it easy
# I'm just wondering if there's a "better" way?
foreach ($fld1, $fld2, $fld3, $fld4) {
$_ = '' unless defined;
}
}
close FILE;
Thanks!
Christopher
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: 9 Feb 2001 14:57:46 GMT
From: Ilmari Karonen <iltzu@sci.invalid>
Subject: Re: Big Numbers
Message-Id: <981730388.10819@itz.pp.sci.fi>
In article <3A816AB6.E80C3BA7@yoyo.pl>, Slasia wrote:
># It is good for 31, for 32 i isn`t
>my $sPowElem = 31;
>
>$sNumber = 2**$sPowElem;
>print "2**$sPowElem = $sNumber\n";
>
>$sResult |= $sNumber;
>print "Result = $sResult\n";
I think you should use a bit vector instead:
vec(my $vector, 32, 1) = 1;
Type "perldoc -f vec" for more information.
--
Ilmari Karonen - http://www.sci.fi/~iltzu/
"Of course, the service life of the car to which such an engine is attached
will be measured in seconds..." -- John Schilling in rec.arts.sf.science
Please ignore Godzilla and its pseudonyms - do not feed the troll.
------------------------------
Date: Fri, 09 Feb 2001 19:34:55 GMT
From: michael.cambray@wellpoint.com
Subject: Re: Can perl define vars dynamically?
Message-Id: <961gov$g3i$1@nnrp1.deja.com>
Thank you for all responses, however my explanation pointed everyone
in the wrong direction. I am actually creating a subroutine or module
to return values to the caller. With our Firstwave (SAGE) software we
can make an assignment as shown below:
{sepf{i}} = array{i}
Thus if the value of i is 1, sepf1 is assigned the value of array[i].
if the value of i is 3, sepf3 is assigned the value of array[i].
Below, in perl, I can print $sepf[$i] while in the loop, but it does not
recognize $sepf1 as a valid variable, so I can't return it.
$sepf[$i] = $sep_array[$i];
So it sounds like perl can't define or assign a variable "on the fly".
Correct?
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: Fri, 09 Feb 2001 20:54:18 GMT
From: trammell@bayazid.hypersloth.net (John Joseph Trammell)
Subject: Re: Can perl define vars dynamically?
Message-Id: <slrn988k6g.9ak.trammell@bayazid.hypersloth.net>
On Fri, 09 Feb 2001 19:34:55 GMT, michael.cambray@wellpoint.com
<michael.cambray@wellpoint.com> wrote:
[snip]
> Below, in perl, I can print $sepf[$i] while in the loop, but it does not
> recognize $sepf1 as a valid variable, so I can't return it.
Why not just return $sepf[$i], or @sepf then? I think most people
would agree that when you start naming variables $foo1, $foo2, ...
you're begging for an array anyhoo.
> So it sounds like perl can't define or assign a variable "on the fly".
> Correct?
Not correct -- it can be done. It's just bad practice. Read up
on 'eval' if you really still want to do this.
------------------------------
Date: Fri, 09 Feb 2001 20:54:34 GMT
From: "Tom Briles" <sariq@texas.net>
Subject: Re: Can perl define vars dynamically?
Message-Id: <eOYg6.180843$Df2.12150276@news3.aus1.giganews.com>
<michael.cambray@wellpoint.com> wrote in message
news:961gov$g3i$1@nnrp1.deja.com...
>
> Below, in perl, I can print $sepf[$i] while in the loop, but it does not
> recognize $sepf1 as a valid variable, so I can't return it.
>
> $sepf[$i] = $sep_array[$i];
>
> So it sounds like perl can't define or assign a variable "on the fly".
> Correct?
If I understand your question, no.
I believe that this series of articles is appropriate:
http://perl.plover.com/varvarname.html
- Tom
------------------------------
Date: 09 Feb 2001 16:10:28 -0500
From: Joe Schaefer <joe+usenet@sunstarsys.com>
Subject: Re: Can perl define vars dynamically?
Message-Id: <m3y9vfo94r.fsf@mumonkan.sunstarsys.com>
michael.cambray@wellpoint.com writes:
> Thank you for all responses, however my explanation pointed everyone
> in the wrong direction. I am actually creating a subroutine or module
> to return values to the caller. With our Firstwave (SAGE) software we
> can make an assignment as shown below:
>
> {sepf{i}} = array{i}
>
> Thus if the value of i is 1, sepf1 is assigned the value of array[i].
> if the value of i is 3, sepf3 is assigned the value of array[i].
>
> Below, in perl, I can print $sepf[$i] while in the loop, but it does not
> recognize $sepf1 as a valid variable, so I can't return it.
>
> $sepf[$i] = $sep_array[$i];
>
> So it sounds like perl can't define or assign a variable "on the fly".
> Correct?
No, not correct. Perl can do that- but to do so requires disabling
referential strictures (I'm being purposely obtuse here), which is
in general a very bad idea in perl. Hashes, thought of as portable
namespaces, are great little replacements for this functionality.
What's so bad about using
$sepf[1] or $sepf{one}
instead of
$sepf1 or $sepf_one
in your code anyway?
There's a nice series of articles by mjd that discuss this issue
far better than I ever could. Here's a link to the first one,
but be sure to read all three:
http://http://perl.plover.com/varvarname.html
HTH
--
Joe Schaefer "It is unbecoming for young men to utter maxims."
-- Aristotle
------------------------------
Date: Fri, 09 Feb 2001 13:24:32 -0800
From: Terrence Monroe Brannon <terrence.brannon@oracle.com>
Subject: Re: CFP: Yet Another Perl Conference 2001
Message-Id: <3A846010.FDA9E4BE@oracle.com>
You have posted spam for your conference in a technical newsgroup.
Long-standing usenet tradition... [[ blah blah blah s/David Adler's rant on job
postings/conference post/g ]]]
Rich Lafferty wrote:
> [Une version française suit / A French version follows.]
>
> *** Third North American YAPC: First Call for Participation ***
>
> Yet Another Society
> calls for your participation in
>
> YAPC 2001
> the Third North American
> Yet Another Perl Conference
>
> http://yapc.org/America/
>
> McGill University,
> Montreal, Quebec
>
> Wednesday through Friday
> June 13-15, 2001
>
> YAPC is a place for people to meet and talk about Perl -- where
> people who've done interesting things, people who are working
> on the language itself, people who are using it daily,
> and people who are looking to learn about it are all within
> arm's reach. Some of the great authors and coders in the field
> will be on hand to discuss their work, as well as the nature
> and direction of Perl itself.
>
> Please join us for three days of listening and talking about
> Perl in Montreal.
>
> ** Conference registration will be available by Feb. 1, 2001 at
>
> http://na-register.yapc.org/
>
> Dorm rooms will be available at the University (rates TBA); the dorm
> request information will be on the website and registration
> form.
>
> Registration Cost: CAD$125 (about USD$85)
>
> ** We are looking for sponsors. Please contact Kevin Lenzo
> (lenzo@yapc.org) for information about how you can help
> support the Yet Another society and YAPC. Much of the
> necessary funding for YAPC comes from the generous donations
> of our sponsors.
>
> ** Submitted papers: Submission Deadline: May 1, 2001
>
> All topics are welcome. Here is a short list of subjects that
> might be presented:
>
> XML, CGI/Web, Interprocess Communication, GUIs (GTk, Tk),
> Natural Language Processing, Interactive Perl, Agents,
> Perl as Glue, Object-Oriented Perl, Scientific Applications,
> Guts, Internals, JAPHs, Perl Poetry, System Administration,
> DBI/DBD, Non-UNIX Perl, Security, Peer-to-Peer Communication,
> Your Favourite Topic.
>
> Please submit your abstracts to <na-author@yapc.org>. Authors
> are requested to limit their abstracts to one or two paragraphs
> for Lightning Talks, and to 300 words for other talks.
>
> This year we will accept a number of types of talks:
>
> * Lightning: 5 minutes
>
> The lightning talks were instigated by Mark-Jason Dominus
> last year in Pittsburgh, and were replicated with great
> success at the European YAPC in London.
>
> Participants speak for no more than five minutes, with the use
> of conventional transparencies. Any use of data projector,
> etc, is discouraged, but allowed as long as the five minute
> time limit is maintained (set-up will be done as the clock
> ticks). The talk ends at the five-minute mark, regardless of
> whether or not the speaker has finished.
>
> Any topic is allowed, and some have been fantastically
> humourous. Lightning talks are an excellent forum for
> first-time speakers.
>
> * Standard: 20 minutes
>
> A 'standard' talk is the preferred format. This is enough
> time to start a topic, introduce it with some pithy slides,
> and open up to later conversation.
>
> * Long and Extra-Long: 45 minutes, 90 minutes
>
> Long talks are reserved for experienced speakers covering
> large topics. If you have an in-depth topic you would like
> to present in some detail, perhaps with considerable
> discussion, a Long or Extra-Long talk may be the format of
> choice.
>
> * Tutorial: 3 hours + break (possibly in two sets)
>
> Half-day (or possibly full-day) tutorials.
>
> ** Please submit your abstracts to <na-author@yapc.org>! **
>
> Thank you; we hope you will participate. If you have any questions,
> please mail <na-help@yapc.org>.
>
> ---
>
> Yet Another Society is a non-profit organization for the
> advancement of collaborative efforts in computer and information
> sciences. YAS promotes symposia, teaching, and group projects.
> See http://yetanother.org for more information.
>
> *** Third North American YAPC: First Call for Participation ***
>
> ---------------------------------------------------------------------------
>
> ***
> Troisième YAPC Amérique du Nord: Premier appel à la participation
> ***
>
> Yet Another Society
> vous invite à participer à
>
> YAPC 2001
> La troisième
> Yet Another Perl Conference
> en Amérique du Nord
>
> http://yapc.org/America/
>
> Université McGill,
> Montréal, Québec
>
> Du mercredi au vendredi
> 13 au 15 juin, 2001
>
> YAPC est un endroit où se rencontrer et parler de Perl; où sont réunis
> des gens qui ont fait des choses intéressantes, qui travaillent sur le
> langage lui-même, qui utilisent ce langage tous les jours et qui
> veulent en apprendre plus. Quelques uns des meilleurs auteurs et
> codeurs dans le domaine seront présents pour discuter de leur travail,
> ainsi que de la nature et de l'avenir du langage Perl lui-même.
>
> Joignez-vous donc à nous à Montréal pendant trois jours pour parler et
> entendre parler de Perl.
>
> ** Inscrivez-vous à la conférence dès le 1er février:
>
> http://na-register.yapc.org/
>
> Des résidences étudiantes pour les participants seront disponibles
> sur le campus de l'université (les tarifs seront annoncés plus
> tard); le formulaire d'inscription donnera toutes les informations
> nécessaires à ce sujet.
>
> Frais d'inscription à la conférence: 125$CDN (environ 85$US).
>
> ** Nous sommes à la recherche de commanditaires. Veuillez contacter
> Kevin Lenzo (lenzo@yapc.org) pour savoir comment vous pouvez
> encourager la Yet Another Society et YAPC. Une grande partie des
> fonds nécessaires à YAPC proviennent en effet des généreuses
> contributions de nos commanditaires.
>
> ** Date de tombée pour la soumission des communications: 1er mai 2001
>
> Tous les sujets sont bienvenus. Voici une liste non-exhaustive de
> sujets possibles:
>
> XML, CGI/web, communication inter-processus, GUIs (Gtk, Tk),
> traitement du langage naturel, Perl interactif, agents, Perl
> comme langage-"colle", Perl orienté-objet, applications
> scientifiques, entrailles, JAPHs, poésie Perl, administration de
> systèmes, DBI/DBD, Perl non-Unix, sécurité, communication
> 'peer-to-peer', ...
>
> Veuillez soumettre les résumés de vos communiations à
> <na-author@yapc.org>. Les auteurs sont priés de limiter leurs
> résumés à un ou deux paragraphes pour les communications éclair, et
> à 300 mots pour les autres communications.
>
> Cette année, nous acceptons plusieurs sortes de communications:
>
> * Communications éclair: 5 minutes
>
> Les communications éclair ont été introduites l'été dernier à
> Pittsburgh par Mark-Jason Dominus et ont été reprises avec
> beaucoup de succès au YAPC européen à Londres.
>
> Les participants disposent d'un maximum de cinq minutes pour
> présenter leur communication, habituellement à l'aide d'un
> rétroprojecteur. Tout autre mécanisme de présentation est
> déconseillé, mais permis dans la mesure où la limite de temps
> est respectée (l'installation se fait pendant que le temps
> s'écoule). La communication se termine au bout de cinq minutes,
> que le présentateur ait terminé ou non.
>
> Tout sujet est accepté, ce qui a donné lieu dans le passé à
> quelques communications hautement humoristiques. Les
> communications éclair constituent un excellent forum pour des
> gens qui en sont à leurs premières présentations.
>
> * Standard: 20 minutes
>
> La communication standard constitue le format préféré. Il y a
> suffisamment de temps pour introduire le sujet, présenter
> quelques transparents bien choisis et permettre la discussion.
>
> * Longue et extra-longue: 45 minutes, 90 minutes
>
> Ces communications sont réservées aux présentateurs
> expérimentés et elles couvrent des sujets plus vastes. Si vous
> désirez présenter un sujet et le discuter en détail, ce format
> pourrait s'avérer le plus approprié.
>
> * Tutoriel: 3 heures + une pause
>
> Tutoriels d'une demi-journée et possiblement d'une journée
> complète.
>
> ** Veuillez soumettre vos résumés à <na-author@yapc.org> **
>
> Nous vous remercions et nous espérons que vous participerez en grand
> nombre. Si vous avez des questions, communiquez avec
> <na-help@yapc.org>.
>
> ---
>
> Yet Another Society est une société à but non-lucratif vouée à
> l'avancement d'efforts colaboratifs en informatique et en sciences de
> l'information. YAS promouvoit des symposiums, de l'enseignement et
> des projets de groupe. Pour plus d'informations, voir
> http://yetanother.org/.
>
> ***
> Troisième YAPC Amérique du Nord: Premier appel à la participation
> ***
------------------------------
Date: Fri, 9 Feb 2001 11:45:42 -0800
From: sameer <svadakke@cochin.qualcomm.com>
Subject: Re: Converting nested hashes to objects
Message-Id: <Pine.GSO.4.31.0102091123190.12973-100000@cochin.qualcomm.com>
On 9 Feb 2001, 00:49, Jakob Schmidt wrote:
: svadakke@cochin.qualcomm.com writes:
:
: > Hello,
: >
: > I'm trying to come up with a maintainable OO solution for a problem and
: > would appreciate some insights.
: >
: > I've a config. file looking like this:
: >
: > {
: > 'valid' => [ 'a', 'b' ],
: > 'a' => {
: > 'valid' => [ 'c', 'd' ],
: > 'c' => {
: > 'valid' => [ 'e', 'f' ],
: > 'e' => 'testing e',
: > 'f' => 'testing f'
: > },
: > 'd' => 'testing d',
: > }
: > 'b' => 'testing b',
: > }
: >
: > During traversals and
: > retrievals from the object, each nested hash is 'blessed' into MyConfig,
: > in order to access methods.
Thanks for the critique, Jakob!
: By altering your file format you could skip the "reblessing". Here's a
One problem is that the config files are maintained by folks who don't
do blessings. If it becomes absolutely necessary, I can make the
changes, but I'm not sure yet.
Another is that each nested hash is to be accessed similarly, and preferably,
client code should not have to say '$cfg->{a}->{c}', which, to me, seems to
remove encapsulation. Rather, something like:
foreach my $valid_key ($cfg->get_valid()) {
$valid_key->do_something();
}
and use some kind of a tree traversal to go through the nested hashes.
The Perl/Tk part is additional complexity if, as is done now, a widget's
textvariable is tied to a key in a nested hash.
: > Another solution is to create a hierarchy of classes, one that is a
: > 'composite' class, and one that is a 'leaf' class. Via inheritance,
: > re-blessing is not needed to access methods.
:
: Maybe I don't understand you correctly - is this a solution that you've
: tried? It sounds to me like you're confusing classes and instances.
: Inheritance won't bless anything for you.
What I meant was that after 'do'ing the config file, the nested hashes are
split up into 2 types of classes, one that contains other classes, called
Composite, and one that does not contain other classes, called Leaf.
Leaf inherits from Composite, which in turn, inherits from the config class.
This is supposed to let you write client code that treats both types of
objects in the same way.
Thanks again for the comments.
Regards
Sameer
------------------------------
Date: 09 Feb 2001 23:12:13 +0100
From: Jakob Schmidt <sumus@aut.dk>
Subject: Re: Converting nested hashes to objects
Message-Id: <pugrzete.fsf@macforce.sumus.dk>
sameer <svadakke@cochin.qualcomm.com> writes:
> On 9 Feb 2001, 00:49, Jakob Schmidt wrote:
>
> : svadakke@cochin.qualcomm.com writes:
> :
> : > Hello,
> : >
> : > I'm trying to come up with a maintainable OO solution for a problem and
> : > would appreciate some insights.
> : >
> : > I've a config. file looking like this:
> : >
> : > {
> : > 'valid' => [ 'a', 'b' ],
> : > 'a' => {
> : > 'valid' => [ 'c', 'd' ],
> : > 'c' => {
> : > 'valid' => [ 'e', 'f' ],
> : > 'e' => 'testing e',
> : > 'f' => 'testing f'
> : > },
> : > 'd' => 'testing d',
> : > }
> : > 'b' => 'testing b',
> : > }
> : [...]
> : By altering your file format you could skip the "reblessing". Here's a
>
> One problem is that the config files are maintained by folks who don't
> do blessings.
Not exactly clergymen, huh? :-)
> If it becomes absolutely necessary, I can make the
> changes, but I'm not sure yet.
Functionally it makes no difference whether you bless the refs after do'ing
or by litteral blessing in what's to be do'ed (do'ne :-).
> Another is that each nested hash is to be accessed similarly, and preferably,
> client code should not have to say '$cfg->{a}->{c}', which, to me, seems to
> remove encapsulation. Rather, something like:
>
> foreach my $valid_key ($cfg->get_valid()) {
> $valid_key->do_something();
> }
>
> and use some kind of a tree traversal to go through the nested hashes.
This should be doable if blessings are "litteral" as mine just as well
as if they're post-do "re-blessings".
> The Perl/Tk part is additional complexity if, as is done now, a widget's
> textvariable is tied to a key in a nested hash.
Arrrrrgh ;-)
> : > Another solution is to create a hierarchy of classes, one that is a
> : > 'composite' class, and one that is a 'leaf' class. Via inheritance,
> : > re-blessing is not needed to access methods.
> :
> : Maybe I don't understand you correctly [...]
>
> What I meant was that after 'do'ing the config file, the nested hashes are
> split up into 2 types of classes, one that contains other classes, called
> Composite, and one that does not contain other classes, called Leaf.
> Leaf inherits from Composite, which in turn, inherits from the config class.
> This is supposed to let you write client code that treats both types of
> objects in the same way.
If you plan to use a recursive traversal scheme this is definately the
way to go. I thought you meant that you could skip the blessings if
you did this which of course you can't - on the contrary you have to
test ref() or something before blessing to pick the right class.
Do you know the Gang of Four Composite Pattern?
They put an abstract generalization above the Leaf and Composite classes.
Thus avoiding the problem you have with the OO principle of substitution
by having Leaf inherit from Composite (it should do "at least" what Composite
does - and it actually does less (though in your concrete case this may not
be a problem)).
But hey! that's is off-topic...
> Thanks again for the comments.
You're ever so welcome.
--
Jakob Schmidt
http://aut.dk/orqwood
etc.
------------------------------
Date: Fri, 09 Feb 2001 22:48:11 GMT
From: ether_nut@my-deja.com
Subject: DBD install on solaris 7
Message-Id: <961s39$qo0$1@nnrp1.deja.com>
We have oracle 7.3.4 running on solaris 7. The DBI installed fine,
now we're stuck on the DBD. Does anyone know why this error is
happening with first Oracle.so and of course the rest of thes tests?
We are using DBD 1.06, perl 5.005.
# make test
PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib
-I/usr/local/lib/perl5/5.00502/sun4-solaris
-I/usr/local/lib/perl5/5.00502 -e 'use Test::Harnet
t/base..............dubious
Test returned status 0 (wstat 132, 0x84)
test program seems to have generated a core
t/general...........install_driver(Oracle) failed: Can't load
'blib/arch/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: ld.so.1:
/usr/bin/perl: f.
at (eval 1) line 2
Perhaps a required shared library or dll isn't installed where expected
at t/general.t line 20
dubious
Test returned status 0 (wstat 138, 0x8a)
test program seems to have generated a core
t/long..............Can't load 'blib/arch/auto/DBD/Oracle/Oracle.so'
for module DBD::Oracle: ld.so.1: /usr/bin/perl: fatal: relocation
error: file bl.
at t/long.t line 4
BEGIN failed--compilation aborted at t/long.t line 4.
dubious
Test returned status 0 (wstat 139, 0x8b)
test program seems to have generated a core
t/plsql.............Can't load 'blib/arch/auto/DBD/Oracle/Oracle.so'
for module DBD::Oracle: ld.so.1: /usr/bin/perl: fatal: relocation
error: file bl.
at t/plsql.t line 17
BEGIN failed--compilation aborted at t/plsql.t line 17.
dubious
Test returned status 0 (wstat 132, 0x84)
test program seems to have generated a core
t/reauth............dubious
Test returned status 0 (wstat 138, 0x8a)
test program seems to have generated a core
FAILED--5 test scripts could be run, alas--no output ever seen
*** Error code 2
make: Fatal error: Command failed for target `test_dynamic'
#
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: Fri, 09 Feb 2001 11:20:06 -0800
From: mothra <mothra@nowhereatall.com>
Subject: Re: Devel DProf and " dprofpp "
Message-Id: <3A8442E6.C7103161@nowhereatall.com>
"Godzilla!" wrote:
[snipped]
>
> Well, interesting. This is not the syntax exemplified
> by this one piece of documentation I found for dprofpp
> nor the syntax hinted by Perl documentation. Your
> switches and script reference are the same.
>
> I will have to install ActiveState again, then try
> running dprofpp from a DOS command line rather than
> running it as a command inside a script, as noted
I have just tried this using
system("dprofpp -u -p d:\scripts\dbitest.pl");
and
$testing =`dprofpp -u -p d:\scripts\dbitest.pl`;
inside another script and it did work.
> by this documentation I found after a week of intense
> searching. Devel DProf works fine as a script command,
> as documented, under my Apache server. This dprofpp
> script command line call fails to compile if
> documentation syntax is used.
Running dprofpp under apache? Hmm
I can't think of a reason for doing that but OH well. I
did try to run the script under Apache and it did not work.
the error was:
Failed: perl -d:DProf d:scriptsdbitest.pl: at C:\perl\bin\dprofpp.bat
line 775.
> There is a Main Package problem with Perl trying to
> interpret dprofpp as a subroutine call when this syntax
> in documentation is used.
[snipped]
> I will try running dprofpp within a DOS box, contrary to
> Perl documentation, and discover if I can enjoy this success
> you have enjoyed.
>
> Kinda figures only Mothra is brave enough to engage me in
> meaningful dialog. I take it you are not a member in good
> standing in this Good Ol' Boys Club, comp.lang.perl.misc.
> I suspect moth balls helps to protect you against abuse
> from the regulars here. Fortunately, I have none.
Been here only a few months ( about 3) and I have found the
regulars here to be very helpful. However, I have noticed
that c.l.p.m is less tolerant of mistakes people make in
the netedqite department. But all in all it is a very good
newsgroup.
> (great subtle pun Kira!)
>
> Thank you for this infomation. I will give this a try.
>
> Godzilla!
Mothra
------------------------------
Date: Fri, 09 Feb 2001 12:36:56 -0800
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: Devel DProf and " dprofpp "
Message-Id: <3A8454E8.68B6E3B0@stomp.stomp.tokyo>
mothra wrote:
> Godzilla! wrote:
> [snipped]
(more snippage)
> > I will have to install ActiveState again, then try
> > running dprofpp from a DOS command line rather than
> > running it as a command inside a script, as noted
> I have just tried this using
> system("dprofpp -u -p d:\scripts\dbitest.pl");
> and
> $testing =`dprofpp -u -p d:\scripts\dbitest.pl`;
> inside another script and it did work.
This might just work under Apache. I've enjoyed
success using 'system' syntax under different
circumstances. I have copied your style and
will certainly try this. Thank you.
As a trained scientist and science teacher,
my methodology is 'one experiment' at a time
with strict unchanging controls. In Plain
English, 'one step at a time' methods. For
Perl, I give documented syntax a good try,
test it exhaustively with controlled changes,
before making a decision Perl docs are in
error. This seems a good time to dismiss
Perl docs on this topic as completely in
error and move to experimental syntax
such as you have provided.
> Running dprofpp under apache? Hmm
> I can't think of a reason for doing that but OH well. I
> did try to run the script under Apache and it did not work.
> the error was:
> Failed: perl -d:DProf d:scriptsdbitest.pl: at C:\perl\bin\dprofpp.bat
> line 775.
I have a hunch system syntax will work in a script.
Yes, under Apache. There many good reasons for this and,
it is clear running scripts under a web server is quite
superior to running scripts via ActiveState / DOS.
A very noticable problem with Perl / DOS, a problem
often posted here, is an inability to scroll back
through data printed to a DOS console; it flashes by.
Halting this flash effect, requires adding extra switches
or adding extra coding within a script.
Adding to this frustration, using Perl / DOS requires
typing in your commands and parameters for each run
and retest. Use of Apache eliminates this. A script
can be tested as a cgi. Changes to a script can be
made with a concurrently opened program editor. Just
a matter of saving those changes and reloading your
web browser page to test. This is quick and easy.
Best of all, your data results are printed to your
browser console affording an ability to scroll back
and an ability to save your results to a file, both
with significant ease.
A spin-off benefit is use of Apache's error log;
lots of good info there. Along with easy error
log access, Apache's access log also provides
invaluable clues on program performance and
problems which are subtle in nature. This access
log does provide some relative time factors for
loading and does provide information on hyperlink
problems, such as a bad print of a hyperlink,
doubled slashes or, a missing slash, often being
culprits for failed script generated links.
Using a browser console, obviously, affords you an
ability to examine both an html output and your
document source as well. Plaintext is also quite
nice for many applications. Same scroll ability
exists along with an ability to copy and paste
for note taking, for result comparisons.
Another superior feature of a browser console over
a command line screen is you can compare several
scripts at once, variations on a method, by simply
clicking bookmarks to run comparative test scripts.
A quick notion of speed and overall appearance is
instantly afforded with no more effort than a
simple mouse click.
For this poorly documented dprofpp, I simply must
have a browser console. I am trying to run an
analysis of one of my chat scripts, a script
which is three-thousand-five-hundred lines plus
long and contains dozens of subroutines and
highly imaginative outputs. A Devel DProf tmon.out
file is equal to several 'notebook' pages, with no
'form action' input included. I know when I add
simulated form action input, those pages will
increase in numbers, significantly. This large
amount of data output requires a need to scroll
through this data, something which is not possible
with a command line screen. This ability to scroll,
this ability to examine data results some 'distance'
from each other, is very important; changes to one
subroutine effects changes in a 'distant' subroutine
output. Use of a DOS console renders this ability to
quickly compare distanced results, impossible, at
least impossible in sense of reasonable effort.
Thank you for your postings and information. I am
quite sure I can adapt your methods to my needs.
You would think by now I would have learned to
never rely on Perl documentation for useful
information, for most but not all needs.
This dialog, your help, well exemplifies a willing
cooperative effort sorely lacking in this newsgroup.
Godzilla!
------------------------------
Date: Fri, 09 Feb 2001 14:29:24 -0600
From: Michael Carman <mjcarman@home.com>
Subject: Re: Devel DProf and " dprofpp "
Message-Id: <3A845324.D037D04D@home.com>
"Godzilla!" wrote:
>
> Kinda figures only Mothra is brave enough to engage me in
> meaningful dialog.
Given your posting history, it's more likely that most of the 'regulars'
have killfiled you and that the few who haven't aren't inclined to help.
That said, it is refreshing to see you engaging in an on-topic dialog
and even being (relatively) polite about it.
-mjc
------------------------------
Date: Fri, 09 Feb 2001 13:24:45 -0800
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: Devel DProf and " dprofpp "
Message-Id: <3A84601D.5F8D546E@stomp.stomp.tokyo>
Michael Carman wrote:
> Godzilla! wrote:
> > Kinda figures only Mothra is brave enough to engage me in
> > meaningful dialog.
> Given your posting history, it's more likely that most of the 'regulars'
> have killfiled you and that the few who haven't aren't inclined to help.
> That said, it is refreshing to see you engaging in an on-topic dialog
> and even being (relatively) polite about it.
Buzz off, Bozo.
Godzilla!
------------------------------
Date: Fri, 09 Feb 2001 22:03:18 GMT
From: big_amko@my-deja.com
Subject: Re: dialog with spawned process?
Message-Id: <961pev$oeg$1@nnrp1.deja.com>
In article <3A83C3E6.B0DBB630@free.fr>,
Jerome Abela <Jerome.Abela@free.fr> wrote:
> big_amko@my-deja.com a écrit :
> > system("my_black_box.exe");
> > we get on the stdout something like:
> > >"Are you happy? [Y/N]"
> > from the "black box".
> >
> > How I can pass my input (i.e. "Y") from within calling perl script
in
> > order to succesfuly exit from the "black box"?
>
> open(BOX, "|my_black_box.exe")
> select(BOX);
> $|=1;
> print "Y";
>
> Jerome.
>
Thanks Jerome, this helped. So in other words you suggested to
open "input pipe" to the process and push the input through it.
Now, I am trying to capture the output from the same "Black Box"
process in order to parse it for some error or warning messages or some
other keywords from there, so that I can either proceed further and
just log the information or react properly if error or warning got
encountered.
If I try with "output type of pipe" for instance:
open(OUTPIPE, "my_black_box.exe|")
This would lunch again my_black_box.exe which is obviously what I don't
want!
I know that I can for instance redirect STDOUT and STDERR both to the
file, capture evrything there and then do parsing of the information
from that file, but this doesn't seem to be optimal!!
Any suggestions for this situation?
thanx
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: Fri, 09 Feb 2001 20:12:49 +0100
From: Frank van Wensveen <frankvw@euronet.nl>
Subject: Re: Food for guru's: read/modify/write works under Linux, not under Solaris. Please help!
Message-Id: <j4g88t42fejeu1hssnkpdmovmffu3pc5q7@4ax.com>
On Fri, 09 Feb 2001 15:33:23 GMT, Bart Lateur <bart.lateur@skynet.be>
wrote:
[Read/modify/seek/write]
> >works fine under Linux, but under Solaris 2.7 the file is corrupted
> You likely have a buffering problem.
Apparently so, but what's causing it? I'd expect (call me naive) Perl
to work identically under all Unix flavors, *if* my code is bona fide.
> In your place, I'd attempt to do a seek(FILE, 0, 1) after writing, and
> before continuing reading.
Hm. That's an idea. Although I'm not sure that that will flush
buffers.
I also intend to try autoflushing the file handle, although I'm not
sure how that will impact performance.
Thanks!
Regards,
Frank
============================================
Email: frankvw@euronet.nl
Homepage: http://www.vanwensveen.nl
ICQ #: 13800170
============================================
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
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: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
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 258
**************************************
