[27793] in Perl-Users-Digest
Perl-Users Digest, Issue: 9157 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Apr 14 18:05:47 2006
Date: Fri, 14 Apr 2006 15:05:04 -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 Fri, 14 Apr 2006 Volume: 10 Number: 9157
Today's topics:
Re: (and, ) just how is perl6 coming along? when maybe <brian.d.foy@gmail.com>
[RDBO] ANNOUNCE: Rose::DB::Object 0.71 released <siracusa@gmail.com>
Re: existence and size of client file <no@thanks.com>
Re: existence and size of client file <noreply@gunnar.cc>
Re: existence and size of client file <hjp-usenet2@hjp.at>
Re: existence and size of client file xhoster@gmail.com
Re: Other XS progamming questions (Anno Siegel)
Re: Other XS progamming questions <nospam-abuse@ilyaz.org>
Perl script as Windows service fails to run <jeffjones@u-spam-u-die.net>
Re: XS progamming question <nospam-abuse@ilyaz.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 14 Apr 2006 13:26:23 -0500
From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: (and, ) just how is perl6 coming along? when maybe tryable, usable, reliable?
Message-Id: <140420061326238565%brian.d.foy@gmail.com>
In article <e1mr7h$jm2$1@reader1.panix.com>, David Combs
<dkcombs@panix.com> wrote:
> In article <bkvr32d2e2fbejs7b2h3e73c5s9qknucdh@4ax.com>,
> Bart Lateur <bart.lateur@pandora.be> wrote:
> PS: any idea, anyone, of when the next edition of the
> O'Reilly perl6 book (nutshell?) coming out?
>
> (Is that what you use to "learn" p6?)
We're starting to translate "Learning Perl" to "Learning Perl 6" (or
whatever we'll call it). When we get started, we'll have some project
similar to what I'm doing with Mastering Perl
(http://www.pair.com/comdog/mastering_perl) so you can see things as we
create them. :)
*** Posted via a free Usenet account from http://www.teranews.com ***
------------------------------
Date: Fri, 14 Apr 2006 19:29:42 GMT
From: "John Siracusa" <siracusa@gmail.com>
Subject: [RDBO] ANNOUNCE: Rose::DB::Object 0.71 released
Message-Id: <IxqEpE.1v7w@zorch.sf-bay.org>
This is an important bug fix release for all RDBO users. There are no
new dependencies, but I also released a minor revision of Rose::DB.
Files sent to CPAN and on SF.net now:
http://sourceforge.net/project/showfiles.php?group_id=147570
Changes listed below.
-John
Rose::DB::Object:
0.71 (04.14.2006) - John Siracusa <siracusa@mindspring.com>
* Correctly clear the "in the database" state flag when a
speculative load fails because the object was not found.
(Reported indirectly by Svilen Ivanov)
* Changed how multi-table queries are formulated for SQLite in
order to make the new DBD::SQLite version (1.12) happy.
* Fixed errors in the epoch column documentation.
* Fixed some internal method-maker bugs.
Rose::DB:
0.672 (04.14.2006) - John Siracusa <siracusa@mindspring.com>
* Translate Postgres's "real" type to the standard "float" type.
(Patch from Lucian Dragus)
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
------------------------------
Date: Fri, 14 Apr 2006 20:07:55 +0200
From: Asterbing <no@thanks.com>
Subject: Re: existence and size of client file
Message-Id: <MPG.1eaa036962e1c96f9897ef@news.tiscali.fr>
In article <20060414135714.617$hO@newsreader.com>, xhoster@gmail.com
says...
> Asterbing <no@thanks.com> wrote:
> > In article <4a9oigFs7lqnU1@individual.net>, noreply@gunnar.cc says...
> > > Asterbing wrote:
> > > > Is there a way to test the existence and size of a client file ? This
> > > > to avoid any unuseful traffic (upload, serveur file test, unlink if
> > > > too big)
> > >
> > > Maybe you want to check the $ENV{CONTENT_LENGTH} variable before
> > > upload.
> > >
> > >
> >
> > Well, but the form will only POST the path to file for uploading, not
> > the length of the file data itself.
>
> If you are correct and the CGI submission only includes a file path and not
> the actual file data, then the file data must be accessed through the some
> other method; other than CGI. So your question has nothing to do with CGI.
> Since you haven't told us what that other method is...
>
> Xho
>
>
Hum, we have to separate CGI script and CGI script which use CGI.pm.
Thus, if I'm reading value POSTed about file field, I just get the
client file path and not a file handle like CGI.pm provide.
Well, then, if I understand your reply, it means I've to use CGI.pm,
consider POSTed form contains file data too, and "content-length" is
usable to define the file length.
Right ?
------------------------------
Date: Fri, 14 Apr 2006 20:54:47 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: existence and size of client file
Message-Id: <4aa9foFs2la3U1@individual.net>
Asterbing wrote:
> In article <4aa1rmFrl4k8U1@individual.net>, noreply@gunnar.cc says...
>>>Well, but the form will only POST the path to file for uploading, not
>>>the length of the file data itself.
>>
>>True, but $ENV{CONTENT_LENGTH} will hold the length of the whole
>>request, and if it exceeds a certain value, it may not be desirable to
>>even parse the request.
>
> OK, but how does this may help me to figure-out if the submitted file is
> too big (say, >100MB) ?
The size of a file to be uploaded is included in the size of the whole
request.
I think the raw data are still transmitted, but what you'd gain this way
is that you wouldn't need to parse the data.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Fri, 14 Apr 2006 21:12:57 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: existence and size of client file
Message-Id: <p7so1e.4ol.ln@teal.hjp.at>
Asterbing wrote:
> Hum, we have to separate CGI script and CGI script which use CGI.pm.
> Thus, if I'm reading value POSTed about file field, I just get the
> client file path and not a file handle like CGI.pm provide.
If you don't use CGI.pm (or an equivalent module), you will have to
parse the request yourself, and you will find that it indeed includes
the whole file, not just the name.
See RFC 1867 for the format.
hp
--
_ | Peter J. Holzer | Löschung von at.usenet.schmankerl?
|_|_) | Sysadmin WSR/LUGA |
| | | hjp@hjp.at | Diskussion derzeit in at.usenet.gruppen
__/ | http://www.hjp.at/ |
------------------------------
Date: 14 Apr 2006 19:50:11 GMT
From: xhoster@gmail.com
Subject: Re: existence and size of client file
Message-Id: <20060414160232.131$fW@newsreader.com>
Asterbing <no@thanks.com> wrote:
> In article <20060414135714.617$hO@newsreader.com>, xhoster@gmail.com
> says...
> > Asterbing <no@thanks.com> wrote:
> > > In article <4a9oigFs7lqnU1@individual.net>, noreply@gunnar.cc says...
> > > > Asterbing wrote:
> > > > > Is there a way to test the existence and size of a client file ?
> > > > > This to avoid any unuseful traffic (upload, serveur file test,
> > > > > unlink if too big)
> > > >
> > > > Maybe you want to check the $ENV{CONTENT_LENGTH} variable before
> > > > upload.
> > > >
> > > >
> > >
> > > Well, but the form will only POST the path to file for uploading, not
> > > the length of the file data itself.
> >
> > If you are correct and the CGI submission only includes a file path and
> > not the actual file data, then the file data must be accessed through
> > the some other method; other than CGI. So your question has nothing to
> > do with CGI. Since you haven't told us what that other method is...
> >
> > Xho
> >
> >
>
> Hum, we have to separate CGI script and CGI script which use CGI.pm.
I don't what that means. You have to separate you CGI scripts that use the
CGI.pm module from those that don't use CGI.pm but rather use some other
(home-grown?) CGI-implementing code? What kind of separation do they need,
and how is that relevant?
> Thus, if I'm reading value POSTed about file field, I just get the
> client file path and not a file handle like CGI.pm provide.
And then what do you do with the client file path once you have it?
>
> Well, then, if I understand your reply, it means I've to use CGI.pm,
No, you do not *have* to. CGI.pm is not magical. You can implement
yourself anything that CGI.pm normally implements for you. I usually don't
think that that is a good idea, but in this is not clear that CGI.pm does
what you need. $CGI::POST_MAX is there to protect your hard-drive, not your
network. If $POST_MAX is exceeded, it stills reads the entire data stream
from the client, it just doesn't save it. That may not be what you want.
(But the server itself may read the entire request anyway, before it passes
it on to the CGI.)
> consider POSTed form contains file data too, and "content-length" is
> usable to define the file length.
If you are posting files with file fields using http and CGI, then
CONTENT_LENGTH should have length, whether you are using CGI.pm module or
not.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 14 Apr 2006 18:17:40 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Other XS progamming questions
Message-Id: <4aa7a4Fsd6g0U1@news.dfncis.de>
Ferry Bolhar <bol@adv.magwien.gv.at> wrote in comp.lang.perl.misc:
> Hi folks,
>
> Because the inital "XS progamming question" thread is very long already,
> and there's a lot of questions therein meanwhile, I decided to start a new
> track with the following ones.
>
> 1) I understand that in object creation, two scalar values are involved:
>
> SV *sv1 = newSViv(7);
> SV *sv2 = newSVrv(sv1,"myclass");
>
> sv1 is a reference to the object in sv2, right?
No, the other way around. The object proper is the (integer) scalar
sv1. sv2 is a reference to sv1, which has been blessed into "myclass".
> And sv2 is just a magical
> SV with its "stash" pointing to pv "class".
No, sv2 itself is just a reference. sv1 is also not strictly magical
(I don't think so), but has type 7 (SVt_PVMG) and the SvSTASH() function
will return the stash it is blessed into.
> But what I can't understand is the actual purpose of sv1. Why I need
> the reference for blessing? Or in other words, why do I need the
> reference when upgrading a SV to SVMG?
The question is based on wrong assumptions.
> Similar in Perl:
>
> $myobj = bless (\$sv1, "class");
>
> OK, $myobj is now an object blessed into "class". So writing
That's shorthand. $myobj is a reference to an object. The object proper
is $sv1. It carries the blessing, not the reference. Since objects in
Perl are exclusively accessed through references, it is common to speak
of $myobj as "the object", but that is a slight misrepresentation.
> $myobj->test(1);
>
> is just another form for
>
> class::test($myobj,1);
No, you're forgetting about inheritance. "class::test" is one and only
one sub, but "$myobj->test(1)" may call a method test in any class "class"
inherits from.
> But what's the purpose of $sv1 here? It is never used again.
That's because Perl supports object access only through references. It is
quite customary to make the underlying object an anonymous data structure,
so that $sv1 as a named variable doesn't exist (or, in the scalar case,
doesn't survive object creation). Its name is, in fact, nowhere needed,
but its existence as an SV is essential.
> To the XS example above, I can made a sv_dump(sv2) to see the
> magical SV. Can I access directly this SV from Perl as well? Or do I have
> always to use a reference? I can't see the concept in this implementation.
It looks like you are again confusing the roles of sv1 and sv2.
> 2) The docs (perlguts) say "If you mortalize a variable twice, the reference
> count will later be decremented twice". Is this correct?
Why would you doubt it?
> I understand that "mortalizing" a SV means to set the "TEMP" bit in its
> flag field...
The temp bit is rather secondary. The main thing is, the SV is entered
to the list of mortals.
> and that FREETMPS checks for SVs with this flag set and if so,
It goes through the list of mortals, up to a point.
> decremens their ref count and if it becomes 0, discards the SVs. But where
> is stored a SV's "mortalization count"?
The SV appears on the list of mortals as many times as it was added to it.
That's the count.
> And what happens if this count goes
> beyond zero?
You get the dreaded "Attempt to free unreferenced..."
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: Fri, 14 Apr 2006 19:02:06 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Other XS progamming questions
Message-Id: <e1orje$2hdu$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
Anno Siegel
<anno4000@lublin.zrz.tu-berlin.de>], who wrote in article <4aa7a4Fsd6g0U1@news.dfncis.de>:
> > SV *sv1 = newSViv(7);
> > SV *sv2 = newSVrv(sv1,"myclass");
> No, sv2 itself is just a reference. sv1 is also not strictly magical
> (I don't think so), but has type 7 (SVt_PVMG) and the SvSTASH() function
> will return the stash it is blessed into.
Right. There is nothing inherently magical about SVt_PVMG. Depending
on complexity of the data which has been stored into a "Perl Value",
perl will use different C structures for storing the data. SVt_PVMG
has enough slots to store the "package name".
"It so happens" that SVt_PVMG has also slots for storing the "magic"
(the underlying mechanism below tie()ing etc); but these slots are not
used by the code above.
> > But what I can't understand is the actual purpose of sv1. Why I need
> > the reference for blessing?
You mean in Perl? AFAIU, Hysterical raisins only. Very confusing
indeed... But saves a couple of keystrokes.
> > I understand that "mortalizing" a SV means to set the "TEMP" bit in its
> > flag field...
> The temp bit is rather secondary.
Actually, IIRC, it is used for one particular optimization only...
> The main thing is, the SV is entered to the list of mortals.
I would say "to the list of postponed actions"... But the
implementation is indeed that *two* lists of postponed actions are
kept - one specially for mortals=temporaries, another for all the
other stuff.
I do not remember offhand why these lists are separate. OK: lifetimes
are different: temporaries are released at the beginning of the next
statement (on this or parent levels in the call tree), while other
postponed actions are performed, essentially, on BLOCK-like boundaries.
> > And what happens if this count goes
> > beyond zero?
> You get the dreaded "Attempt to free unreferenced..."
... which is, essentially, the same as doing SvREFCNT_dec() more times
than 1+SvREFCNT_inc() - and this is exactly what it results in.
Yours,
Ilya
------------------------------
Date: Fri, 14 Apr 2006 20:55:12 GMT
From: Jeffery Jones <jeffjones@u-spam-u-die.net>
Subject: Perl script as Windows service fails to run
Message-Id: <dk2042djgp8j0gn3np0c9ujt3vdpjrladi@4ax.com>
I have set up Perl scripts to run as a service on about 5 other
machines using SRVANY.exe, etc. They have all worked fine in the
past. On a new machine, Windows 2000, SP4, with the latest Perl
version 5.8.8.817, the script apparently never executes. Substituting
a simple script also doesn't execute because nothing is written to the
test file.
- Other executables (such as cmd.exe) run fine as the service, but
they cannot start Perl and the script.
- Substituting wperl.exe also doesn't help.
There are no errors shown from the service manager or in the event
logs when the service is started.
I've tried running the service under the SYSTEM account.
I've tried downgrading to 5.8.7 with no success. (This version
runs scripts as a service on other machines).
Has anyone seen a similar problem, and what was the solution?
------------------------------
Date: Fri, 14 Apr 2006 18:44:54 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: XS progamming question
Message-Id: <e1oqj6$2h6a$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
Ferry Bolhar
<bol@adv.magwien.gv.at>], who wrote in article <1145009743.823891@proxy.dienste.wien.at>:
> Ilya Zakharevich:
> > > mysub();
> > This is a shortcut for
> >
> > *mysub{CODE}->();
Actually, let me try a more Perlish and a "more correct" analogy:
there are two actions: one is performed at compile time, another is
performed at run time. Perl way to write them down is
{ my $globref;
BEGIN {$globref = \*mysub}
*$globref{CODE}->(); }
The only difference is that instead of Perl reference $globref a
private C pointer to a GV is stored in the compile tree.
> OK. Let's see whether I understood:
>
> mysub();
>
> generates the code to access the CODE entry in typeglob *mysub,
> even if this entry is currently - at compile time - yet empty. Later,
> when
>
> sub mysub{...}
>
> is encountered, the sub is compiled, a CV is generated and its address
> is stored in *mysubs CODE entry - this occurs all in the compilation
> phase. So, because both invocations of mysub access the same typeglob's
> CODE entry, the lexical order of the invocations isn't relevant, as long as
> they do not appeart inside BEGINs.
I think this is an excellent summary...
> > Yes. The "content of sub" is compiled in a different package. The
> > second code is equivalent to
> >
> > package foo;
> >
> > $var = 1;
> > sub bar {
> > package main;
> > ...
> > };
> Well, lets say: would it be equivalent if each identifier within "bar" would
> be
> prefixed with "foo"? Or in other words: does "package" has any effect
> at run-time?
As I explained later in the message, IIRC, it HAS a runtime effect.
> > > IIUC 'package' is just a compiler directive (like 'use', 'my' and
> 'our'),
> > > never appearing in an OP tree?
> >
> > There is a notion of "current package" during execution (relevant to,
> > at least, eval"" and caller() [what else?]). So it IS stored in the
> > compile tree.
> But where? Which OP is used for "package"?
I think one which does "cleanup" in the beginning of every statement.
Hope this helps,
Ilya
------------------------------
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 9157
***************************************
