From ryan at web.oakley.com  Mon Dec  2 21:01:44 2002
From: ryan at web.oakley.com (Ryan Erwin)
Date: Wed Aug  4 00:04:55 2004
Subject: OC-PM: Perl Mongers Tomorrow
In-Reply-To: <3DE55D81.4070307@web.oakley.com>
Message-ID: <8DEDAE36-066B-11D7-8DC5-00039357E21C@web.oakley.com>

Just a quick reminder that the Perl Mongers meeting will be Tomorrow 
(tuesday) in Foothill Ranch.  Please see http://oc.pm.org for more 
information.

The topic will be an introduction to Perl and SAX, the Simple API for 
XML.

On Wednesday, November 27, 2002, at 04:04 PM, Kip Hampton wrote:

> Greetings Mongers,
>
> I've been asked to give the Dec. 3 talk on "something related to Perl 
> and XML". My first choice would be to cover the basics of using SAX ( 
> the Simple API for XML) but I wanted to offer an opportunity for the 
> folks that will be attending to have a say in what they'll be seeing.
>
> To that end, if enough folks can agree on another Perl/XML related 
> topic  that they'd rather hear about before this weekend,( preferably 
> a topic I've touched on in my column[1] ) then I'll gladly go in that 
> direction.
>
> Thoughts, comments, suggestions?
>
> -kip
>
> [1] http://xml.com/pub/q/perlxml


From ryan at web.oakley.com  Tue Dec  3 13:01:20 2002
From: ryan at web.oakley.com (Ryan Erwin)
Date: Wed Aug  4 00:04:55 2004
Subject: OC-PM: Perl and XML: Intro to SAX
Message-ID: <9C192C60-06F1-11D7-97A5-00039357E21C@web.oakley.com>

This is your final reminder.
	*  Tonight @ 7:00 PM
	*  Oakley @ Foothill Ranch
	*  Kip Hampton from XML.com
	*  Admission is Free

Kip Hampton's talk will be adapted from his XML.com article 
"High-Performance XML Parsing with SAX".  The discussion will cover 
changes made in SAX2 not available in the article.  
http://xml.com/pub/a/2001/02/14/perlsax.html

On your drive here this evening, please take note of the following 
directions once you reach Glen Ranch Rd.

Take a right on Ellipse.  Follow it around the corner to the left and 
take your first left up the unmarked driveway.  This is the main Oakley 
entrance.  At the stop on the top of the driveway, go straight and park 
in "the circle".

For maps and more, visit http://oc.pm.org

See you tonight!

-R

---
Ryan Erwin
Web Director
Oakley, Inc
949-672-6010


From dgwilson at sonomasystems.net  Thu Dec  5 15:25:44 2002
From: dgwilson at sonomasystems.net (Wilson, Douglas)
Date: Wed Aug  4 00:04:55 2004
Subject: OC-PM: SAX ponderings
Message-ID: <CD2D7A00AED1D211B32800A0C96F903342401E@newport_nt_main>


First let me say thanks again Kip for the presentation last night!
I've now at least a start on what SAX is about...

I was thinking about the theoretical problem Ryan
mentioned last night, and how it might be handled with SAX.
The problem as I recall was, say you have a document like this:
...
<x>
  <a>...</a>
  <b>...</b>
  <c>...</c>
</x>
...

And you want to randomly eliminate one of the children of x (or maybe
you want to randomly pick one to keep and eliminate the rest), and
you don't know in advance how many children x has.

Am I wrong in thinking that after you come across the x start_element
event, you would then have to pass events on to a buffer (lets say you
want to randomly eliminate a child), then when you get to the x end_element
event you'd have to then pass the buffer through a filter which would
eliminate the
unlucky nth child.

Or if you wanted to keep only one child, then you could pass events from
each child to a
separate buffer (in the same way as the Picking a Random Line from a File
Perl Cookbook recipe, deciding whether to create a new buffer, save a
child to it, and throw away the old buffer as you come across each child).

I see a XML::Filter::Sort::BufferMgr module and related modules, would that
be the
way to go? Looking at it, it only handles 5 different events, which may or
may not
be good enough. Or am I completely on the wrong track?
That's entirely possible too :-)

Cheers,
-Doug

From dgwilson at sonomasystems.net  Fri Dec  6 12:29:31 2002
From: dgwilson at sonomasystems.net (Wilson, Douglas)
Date: Wed Aug  4 00:04:55 2004
Subject: OC-PM: MySQL and other DBs
Message-ID: <CD2D7A00AED1D211B32800A0C96F9033424025@newport_nt_main>



Some interesting reads on MySQL vs. other Databases. This
one is slightly outdated (its been in 'to be updated' mode for
awhile now):
http://openacs.org/philosophy/why-not-mysql.html

And this is an interesting thread on the subject. InnoDB sounds like
its worth looking at (as well as PostgreSQL):
http://openacs.org/forums/message-view?message_id=20355

Though MySQL is still probably the perfect solution for something
like what Oakley is doing, i.e., creating a database index to their XML
product catalog, it looks like its still not the answer to all database
problems.

-Doug

From dgwilson at sonomasystems.net  Fri Dec  6 12:57:54 2002
From: dgwilson at sonomasystems.net (Wilson, Douglas)
Date: Wed Aug  4 00:04:55 2004
Subject: OC-PM: MySQL and other DBs
Message-ID: <CD2D7A00AED1D211B32800A0C96F9033424028@newport_nt_main>


I'm still playing catch up to finding out where MySQL is at lately.
Looks like they do (or are about to) support alot more features (partly
by using InnoDB as at least part of the backend :-)

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=ZDx59.195%2
4796.9559%40read2.inet.fi



On Friday, December 06, 2002 10:30 AM, Wilson, Douglas
[SMTP:dgwilson@sonomasystems.net] wrote:
> 
> 
> Some interesting reads on MySQL vs. other Databases. This
> one is slightly outdated (its been in 'to be updated' mode for
> awhile now):
> http://openacs.org/philosophy/why-not-mysql.html
> 
> And this is an interesting thread on the subject. InnoDB sounds like
> its worth looking at (as well as PostgreSQL):
> http://openacs.org/forums/message-view?message_id=20355
> 
> Though MySQL is still probably the perfect solution for something
> like what Oakley is doing, i.e., creating a database index to their XML
> product catalog, it looks like its still not the answer to all database
> problems.
> 
> -Doug

From bill at daze.net  Fri Dec  6 13:16:33 2002
From: bill at daze.net (bill@daze.net)
Date: Wed Aug  4 00:04:55 2004
Subject: OC-PM: Perl/TK
Message-ID: <20021206111138.G9446-100000@droid.daze.net>

Unfortunately, I was unable to attend this week's meeting.  Sounds like I
missed a good one.

I've been thinking about Perl/TK recently and possibly using it as an
alternative to a web based UI for some of our in-house applications.  Are
any of you using Perl/TK and would anyone be interested in presenting an
overview at a future meeting?


From dgwilson at sonomasystems.net  Fri Dec  6 13:44:01 2002
From: dgwilson at sonomasystems.net (Wilson, Douglas)
Date: Wed Aug  4 00:04:55 2004
Subject: OC-PM: Perl/TK
Message-ID: <CD2D7A00AED1D211B32800A0C96F9033424029@newport_nt_main>



On Friday, December 06, 2002 11:17 AM, bill@daze.net [SMTP:bill@daze.net]
wrote:
> 
> I've been thinking about Perl/TK recently and possibly using it as an
> alternative to a web based UI for some of our in-house applications.  Are
> any of you using Perl/TK and would anyone be interested in presenting an
> overview at a future meeting?

There was some discussion of perl GUI's last night, though it seemed like
noone had extensive experience with them (so don't expect a presentation
any time soon :-). For what its worth Tk is probably
the most stable but the consensus was that it would be the least favorable
to work with (from the few opinions that existed).
Here's an interesting FAQ on perl GUI modules and toolkits:
http://www.perlmonks.org/index.pl?node_id=108708

-Doug

From kip at web.oakley.com  Mon Dec  9 20:23:03 2002
From: kip at web.oakley.com (Kip Hampton)
Date: Wed Aug  4 00:04:55 2004
Subject: OC-PM: SAX ponderings
References: <CD2D7A00AED1D211B32800A0C96F903342401E@newport_nt_main>
Message-ID: <3DF55007.8020802@web.oakley.com>

Wilson, Douglas wrote:
> First let me say thanks again Kip for the presentation last night!
> I've now at least a start on what SAX is about...

Thanks.

> 
> I was thinking about the theoretical problem Ryan
> mentioned last night, and how it might be handled with SAX.
> The problem as I recall was, say you have a document like this:
> ...
> <x>
>   <a>...</a>
>   <b>...</b>
>   <c>...</c>
> </x>
> ...
> 
> And you want to randomly eliminate one of the children of x (or maybe
> you want to randomly pick one to keep and eliminate the rest), and
> you don't know in advance how many children x has.
> 
> Am I wrong in thinking that after you come across the x start_element
> event, you would then have to pass events on to a buffer (lets say you
> want to randomly eliminate a child), then when you get to the x end_element
> event you'd have to then pass the buffer through a filter which would
> eliminate the
> unlucky nth child.

Almost...

You're right in that you'd need to buffer the events between the calls 
to start_element() and end_element() for the 'x' element, but a filter 
is not really needed.

Consider the following (untested):

package Ryans::RandomChildFilter;
use XML::SAX::Base;
use vars qw( @ISA $e_count );
@ISA = qw( XML::SAX::Base );

$e_count = 0;

#init in start_doc
sub start_document {
     my $self = shift;

     $self->{in_buffer}     = undef;
     $self->{event_buffer}  = [];

     $self->SUPER::start_document( @_ );
}

sub start_element {
     my $self = shift;
     my $e = shift;

     if ( defined( $self->{in_buffer} ) ) {
         push @{$self->{event_buffer}->[$e_count]},
              ['start_element', $e];
     }
     else {
         $self->SUPER::start_element( $e );
     }
}

sub characters {
     my $self = shift;
     my $chars = shift;

     if ( defined( $self->{in_buffer} ) ) {
         push @{$self->{event_buffer}->[$e_count]},
              ['characters', $chars];
     }
     else {
         $self->SUPER::characters( $chars );
     }
}

sub end_element {
     my $self = shift;
     my $e = shift;

     if ( defined( $self->{in_buffer} ) ) {

         if ( $e->{LocalName} eq 'x' ) {

             # pick a random element from the stack
             my @buffer = @{$self->{event_buffer}};
             my $selected_index = int rand($#buffer);

             # forward the element's events from the buffer
             foreach my $event ( @{$buffer[$selected_index]} ) {
                 my ( $method, $data ) = @{$event};
                 $self->SUPER::$method( $data );
             }

             # reset
             $self->{event_buffer} = [];
             $self->{in_buffer} = undef;
             $e_count = 0;
         }
         else {
             push @{$self->{event_buffer}->[$e_count]},
                  ['end_element', $e];
             $e_count++;
         }
     }
     else {
         $self->SUPER::start_element( $e );
     }
}

1;

Obvously, there may be cleaner ways to skin the same cat, but, does this 
help at all ?

-kip


From michael at web.oakley.com  Tue Dec 31 17:37:29 2002
From: michael at web.oakley.com (Michael Wood)
Date: Wed Aug  4 00:04:55 2004
Subject: OC-PM: Next week's OC-PM meeting..
Message-ID: <004a01c2b125$9584a640$162b14ac@web.oit.ooweb.oakley.com>

Greetings Fellow Perl Mongers,

Just a heads up about next weeks monger meeting scheduled, as always, on the first Tuesday of each month.  It so happens that this will be our first meeting of the new year, landing on January 7th @ 7pm.

The topics covered will revolve around XML and Perl, while detailing the usage of a Perl Module called XML::EasySLice (which is destined for CPAN in the near future).

Ryan Erwin and Mark McDonald will be speaking.

Time permitting, we would also like to go over how tied scalars, autoloaded methods and lvalues can be used together.

Check out http://oc.pm.org for details...

Hope to see you there!

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pm.org/archives/oc-pm/attachments/20021231/5afede64/attachment.htm