[27105] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 8984 Volume: 10

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Feb 22 18:05:57 2006

Date: Wed, 22 Feb 2006 15:05:05 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)

Perl-Users Digest           Wed, 22 Feb 2006     Volume: 10 Number: 8984

Today's topics:
    Re: Implementing a "pull" (?) interface in perl <nomail@sorry.com>
    Re: Questions about globs (was: XS variable creation) <nospam-abuse@ilyaz.org>
    Re: savely change permission and group on files <daleif@imf.au.dk>
    Re: savely change permission and group on files <abigail@abigail.nl>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Wed, 22 Feb 2006 14:51:32 -0800
From: Arvin Portlock <nomail@sorry.com>
Subject: Re: Implementing a "pull" (?) interface in perl
Message-Id: <dtiptm$1isu$1@agate.berkeley.edu>

xhoster@gmail.com wrote:

> Arvin Portlock  wrote:
>
> >I'm writing a module to parse an XML file of records. It
> >will be used by a variety of different applications, e.g.,
> >loading into a relational database, etc. I'll be using
> >a SAX based approach, ExpatXS, as the XML files can be
> >very large.
>
> Something like?:
>
> $parser->init($foo);
> my $alldata=$parser->get_all();
> foreach my $i (@$alldata) {
>   process($i);
> };

Heh, yes. That's exactly what I'm used to doing.

> Was it slow only because you exhausted memory and were swapping?
> Or was it just slow in providing feedback/progress messages?

For some few very large files it was swapping.

> >Is there some way to design this, module plus application,
> >so that as a record is read the application can process it
> >immediately?
>
> The easiest way is to have the application block until a new record is
> ready. That is just what readline aka <> does:
>
> $parser->init($foo);
> while (defined (my $i=$parser->get_one()) {
>   process($i);
> };

I don't understand. You are describing exactly how I want the
interface to act but not saying how you are doing it, i.e.,
how exactly get_one() works. But yes, that's what I'm aiming for.
Put another way:

my $parse = new FetchRecords ($xmlfile);
my $record = $parse->next_record;
while ($record) {
    ## Process record
    $parse->next_record;
}

Right now I'm doing this:

my $records = getRecords($xmlfile);
foreach my $record (@$records) {
    ## Process record
}

Where getRecords() is defined in my module.

> my $sub= sub { process($_[0]) };
> $parser->init($foo);
> $parser->put_all_through_callback($sub);

Okay, I'm thinking that the module stores up the record
information in a global variable, then when a specific
tag is read it would call something defined in main::,
not a callback in this instance cause I haven't figured
out the mechanics of that:

package FetchRecords;
my $current_record = {};
 ...
sub end_element {
    my ($self, $e) = @_;
    ## Triggered when </record> is encountered
    if ($e->{LocalName} eq 'record') {
       &main::processRecord($current_record);
       undef $current_record;
    }
}

So the calling application would be forced to always
implement a processRecord() subroutine. Not exactly the
way I imagine doing it with my $parse->next_record example
but it's all I can think of.

> The callback method is more flexible, but it isn't clear to me that you
> need that flexibility.  If not, I'd go with the simpler (or at least more
> familiar) readline like method.

I don't really know what the readline like method means.

>
>
> Xho
>



------------------------------

Date: Wed, 22 Feb 2006 22:10:42 +0000 (UTC)
From:  Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Questions about globs (was: XS variable creation)
Message-Id: <dtinh2$1hsl$1@agate.berkeley.edu>

[A complimentary Cc of this posting was sent to
Ferry Bolhar
<bol@adv.magwien.gv.at>], who wrote in article <1140627466.946633@proxy.dienste.wien.at>:
> Hi,
> 
> Ilya Zakharevich wrote:
> 
> > sub Perl_wrapper (args) {
> >   *MyModule::Values::This = XS_Workhorse(args);
> > }
> >
> > Make XS_Workhorse() return a reference to the created value.
> >
> >   RETVAL = newRV_noinc(RETVAL);        /* sp? */
> 
> This brings some questions about globs in my mind, so I changed
> the title of the thread. And before someone ask: Yes, I have read
> perlsub, perlref, perlxs, perlxstut, perlguts and perlapi, among others.
> They describe more or less clearfully what someone can do with a
> glob, but they do not describe what globs actually _are_ and how
> they are represented interally.

My advice: better do not think about this at all.  Globs are just
horrible inheritance from the Perl4 time.  Knowing more about them
will not help you any more; current perl has much better ways to
address the problems for which globs were originally intended.

IMO, the maximum one may need to know about globs is

 *name = \&subroutine; 
 $value = *name{SCALAR};	# Or whatever is the syntax

and

  $anonFH = \ do { local *FH; *FH};

Do not ever access globs from XS code.  Do not ever work with "bare
globs", only with references (except the last expression, where bare
glob inside "do" was required with some versions of Perl) - otherwise
there are some special cases that wait to catch you.

> I know about globs that they are data structures used in conjuction
> with symbol table hashes ('stashes'). So, when executing
> 
> 'print $a';
> 
> to obtain the SV of 'a', perl looks in the '%main::' stash for the value
> of key 'a', which is a gv. Then it looks into the gv at offset xgv_gp
> to find the gp. Finally, it looks into the gp at offset gp_sv to locate
> the address of 'a's sv. Right?

Keep in mind that most of these calculations are done at compile time;
the optree contains a pointer to the glob, and lookups starts from
there.  There are 2 indirections in going from the glob to the
variable; one to cover

  local *a;

another to cover

  local $a;

Hope this helps,
Ilya


------------------------------

Date: Wed, 22 Feb 2006 20:52:23 +0100
From: Lars Madsen <daleif@imf.au.dk>
Subject: Re: savely change permission and group on files
Message-Id: <43fcc0dc$0$12399$ba624c82@nntp02.dk.telia.net>

Aaron Baugher wrote:
> Lars Madsen <daleif@imf.au.dk> writes:
> 
>> Solution: Put the necessary people in a special group and make sure
>> that the files are writable for that group. That's fine, but people
>> tend to forget setting permissions or changing groups, so I'd like
>> to have a cron job that goes through all files in a specific
>> directory and set the group and permissions on all files in this
>> directory-tree.
> 
> Not really a perl problem:
> 
> #!/bin/sh
> if cd /wherever; then
>   chgrp -R ourgroup .
>   chmod -R g+rw .
> fi
> 

yes that's true, but real life is of cource not as simple as the case I 
described.

One problem with this is that it allows users to create directories in 
/whatever (creating them in subdirectories are fine) which we don't want.

I'll find some compromise

/daleif






------------------------------

Date: 22 Feb 2006 22:23:17 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: savely change permission and group on files
Message-Id: <slrndvpp2l.h1.abigail@alexandra.abigail.nl>

Lars Madsen (daleif@imf.au.dk) wrote on MMMMDLVIII September MCMXCIII in
<URL:news:43fc54b1$0$12109$ba624c82@nntp02.dk.telia.net>:
&&  Hi,
&&  
&&  I have a small problem here. We have a special directory on our file 
&&  system (Linux) where a lot of people are writing to (mostly HTML pages, 
&&  no we do not have a CMS, this low tech is fine for now).
&&  
&&  Now we also have some secretaries who can help edit these files. The 
&&  problems is of course permissions, secretary B need to be able to edit 
&&  the files owned by user A.
&&  
&&  Solution: Put the necessary people in a special group and make sure that 
&&  the files are writable for that group. That's fine, but people tend to 
&&  forget setting permissions or changing groups, so I'd like to have a 
&&  cron job that goes through all files in a specific directory and set the 
&&  group and permissions on all files in this directory-tree.
&&  
&&  That's easy to do, well sort of. The problem is of course that this cron 
&&  job has to run as root (or similar) and then we are vulnerable to user 
&&  input, as in file names such as 'file.html;rm -rf /'

Huh? I don't get it. Why would you be vulnerable if you're doing something
simple as changing the permissions of files?



Abigail
-- 
:$:=~s:$":Just$&another$&:;$:=~s:
:Perl$"Hacker$&:;chop$:;print$:#:


------------------------------

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 8984
***************************************


home help back first fref pref prev next nref lref last post