From casey at geeknest.com Sun Feb 2 20:38:10 2003
From: casey at geeknest.com (casey@geeknest.com)
Date: Mon Aug 2 21:34:56 2004
Subject: [pgh-pm] Pittsburgh Perl Mongers | Meeting | 02.12.2003
Message-ID: <20030203023810.599791CD485@caseywest.com>
*Lightning Talks at Unknown Location*
Come enjoy a series of quick talks given by members of Pittsburgh.pm.
These talks may clash. Subjects do not have to go together. Talks
given will be listed here as they arrive in my inbox.
*Location*
Agnew Moyer Smith Inc
3700 South Water Street
Suite 300
http://amsite.com
02.12.2003
03:00
*Talks*
Perl Command Line Casey West
Introduction to CPAN Testing Adam J. Foxson
Parsing JavaScript David Hand
Test Better with Test::More Casey West
How to Turn Your Girlfriend Into a Perl Hacker Stella Daily
Creating a Template Toolkit Plugin Chris Winters
*Details*
If you would like to give a lightning talk, send email to
casey@geeknest.com and give me the title of your talk. I'll list it
here. Talk order will be determined at the meeting. Talks must be five
to ten minutes long.
--
Casey West
(via automation)
From chris at cwinters.com Mon Feb 3 07:03:35 2003
From: chris at cwinters.com (Chris Winters)
Date: Mon Aug 2 21:34:56 2004
Subject: [pgh-pm] Pittsburgh Perl Mongers | Meeting | 02.12.2003
In-Reply-To: <20030203023810.599791CD485@caseywest.com>
References: <20030203023810.599791CD485@caseywest.com>
Message-ID: <3E3E68A7.3040208@cwinters.com>
casey@geeknest.com wrote:
> *Lightning Talks at Unknown Location*
>
> Come enjoy a series of quick talks given by members of Pittsburgh.pm.
> These talks may clash. Subjects do not have to go together. Talks
> given will be listed here as they arrive in my inbox.
>
> *Location*
>
> Agnew Moyer Smith Inc
> 3700 South Water Street
> Suite 300
> http://amsite.com
> 02.12.2003
> 03:00
^^^^^
That should be 19:00, right?
Chris
--
Chris Winters (chris@cwinters.com)
Building enterprise-capable snack solutions since 1988.
From casey at geeknest.com Mon Feb 3 14:44:44 2003
From: casey at geeknest.com (Casey West)
Date: Mon Aug 2 21:34:56 2004
Subject: [pgh-pm] Pittsburgh Perl Mongers | Meeting | 02.12.2003
In-Reply-To: <3E3E68A7.3040208@cwinters.com>
References: <20030203023810.599791CD485@caseywest.com> <3E3E68A7.3040208@cwinters.com>
Message-ID: <20030203204444.GE12552@geeknest.com>
It was Monday, February 03, 2003 when Chris Winters took the soap box, saying:
: casey@geeknest.com wrote:
: >*Lightning Talks at Unknown Location*
: >
: >Come enjoy a series of quick talks given by members of Pittsburgh.pm.
: >These talks may clash. Subjects do not have to go together. Talks
: >given will be listed here as they arrive in my inbox.
: >
: >*Location*
: >
: > Agnew Moyer Smith Inc
: > 3700 South Water Street
: > Suite 300
: > http://amsite.com
: > 02.12.2003
: > 03:00
: ^^^^^
:
: That should be 19:00, right?
Yes, how the /heck/ did that get in there?!
Thanks.
--
Casey West
From casey at geeknest.com Wed Feb 12 12:50:58 2003
From: casey at geeknest.com (Casey West)
Date: Mon Aug 2 21:34:56 2004
Subject: [pgh-pm] Re: facilities for meeting?
In-Reply-To: <3E4A7264.4000304@cwinters.com>
References: <3E4A7264.4000304@cwinters.com>
Message-ID: <20030212185058.GI1243@geeknest.com>
It was Wednesday, February 12, 2003 when Chris Winters took the soap box, saying:
: Hi Casey,
:
: For my talk tonight I have some static HTML slides to remind my
: addled brain what to say. Should I just post them on my website
: and access them from a computer there? Or bring a disk with the
: slides? Or bring a laptop with the slides on them?
To Chris and all other presenters:
There will be wireless (and wired) internet access at AMS. The
conference room will also have a projector for you to connect to. I
would suggest bringing your laptop, for instance, mine is broken and I
will need to share for my lightning talks. :-)
Also, if you haven't talked to me about giving a talk, and you still
want to, come prepared. I'm sure we'll have time.
See you all tonight!
--
Casey West
From chris at cwinters.com Tue Feb 11 22:08:04 2003
From: chris at cwinters.com (Chris Winters)
Date: Mon Aug 2 21:34:56 2004
Subject: [pgh-pm] repaired slides
Message-ID: <3E49C8A4.5050108@cwinters.com>
If anyone is interested in the two repaired slides with the
outputs of the sample code, you can see them on my website:
http://www.cwinters.com/programming/pghpm-2003-02/
Next time I won't be making changes just before I leave for the
meeting :-)
Chris
--
Chris Winters (chris@cwinters.com)
Building enterprise-capable snack solutions since 1988.
From tom at moertel.com Thu Feb 13 20:08:00 2003
From: tom at moertel.com (Tom Moertel)
Date: Mon Aug 2 21:34:56 2004
Subject: [pgh-pm] Thoughts on that JavaScript problem [resent]
Message-ID: <1045188481.1283.276.camel@honeylocust.moertel.com>
[I am resending this because I hosed up the first attempt by sending
from a different account. Sorry if you see this twice.]
Fellow Perl Folk,
After I got home from last night's meeting, I was thinking about the
original JavaScript problem that was the inspiration for David's JS
parser project. In short, the problem is that we need to locate JS
statements of the form
window.location = << string expr >>
and wrap the string expression -- however long and complicated it may be
-- with a function call that will adjust the URL so that it points to
our rewriting-proxy service:
window.location = adjust_URL( << string expr >> )
The tricky part is that in order to determine the location for the final
parenthesis of the function call, we must parse the string expression
according to JS's baroque grammatical and lexical whims. Nasty.
What other options do we have?
Here's one option. Maybe we can get rid of the nastiness by avoiding
the need to wrap the string in the first place. Let's take a closer
look at adjust_URL. It seems likely that this function must adjust any
URL passed to it by tacking something on to the front in order to
re-target the URL to the proxy service. Further, the function must pass
through the original URL (in some form) for the proxy service to fetch
on our behalf. So, given the original URL
http://original.com/page.html
we want to rewrite it into something like
http://my.proxy.com/do-proxy/http://original.com/page.html
This being the case, adjust_URL must look something like the following:
function adjust_URL(url) {
return "http://my.proxy.com/do-proxy/" + url;
}
Note that the only adjustment we strictly require is to tack something
onto the front of the original URL. With this in mind, let's return to
the original JS statement that we want to adjust:
window.location = << string expr >>
In this statement, it's easy to locate the assignment operator: just
find the equals sign. We also know that the string expression,
regardless of how nasty it is, must immediately follow the assignment
operator. Therefore, at the right-hand side of the (=), we can safely
insert any expression fragment that requires a string expression as its
right-hand side:
window.location = "http://my.proxy.com/do-proxy/"
+ << string expr >>
So, assuming that the original statement was something like
window.location = base + "/page4.html"
our modification will yield
window.location = "http://my.proxy.com/do-proxy/"
+ base + "/page4.html"
which is exactly what we want. Yay! We win, right?
Not quite. The problem is that the assignment operator (=) has loose
binding under precedence rules, and we're substituting the (+) operator,
which binds more tightly. If our original string expression contains an
operator that binds more loosely than (+), precedence will cause our
substitution to break. Consider this original statement:
window.location = page == 1 ? "page2.html" : "page1.html"
Applying our modification will yield
window.location = "http://my.proxy.com/do-proxy/"
+ page == 1 ? "page2.html" : "page1.html"
Which unfortunately parses like so:
window.location = ( (("http://my.proxy.com/do-proxy/" + page) == 1)
? "page2.html" : "page1.html" )
Oops. Not only did we change the meaning of the test in the (?)
operator, we failed to rewrite its result, so we're hosed twice.
But we're not dead yet.
One solution to the precedence problem is to use parentheses to wrap and
protect the original expression. After all, that's what parentheses are
for. Unfortunately, this solution puts us right back where we started:
having to parse the string expression to find out where to put the
closing parenthesis.
Luckily, there is a better way. Instead of using (+) in our
substitution, we can use (+=). This operator has the same precedence as
the original assignment (=), so we don't need to parenthesize the
original expression. The only trick is that (+=) must have a modifiable
reference as its left-hand side. That's doable.
Let's see how it works. Given
window.location = << sting expr >>
we rewrite it as
window.location = MYBASE += << sting expr >>
where MYBASE has been set to "http://myproxy.com/do-proxy" beforehand.
Let's apply this technique to our troublesome example with the (?)
operator and see if it works. Given
window.location = page == 1 ? "page2.html" : "page1.html"
we rewrite it as
window.location = MYBASE += page == 1 ? "page2.html" : "page1.html"
which parses like so:
window.location = ( MYBASE
+= (page == 1 ? "page2.html" : "page1.html") )
This is exactly what we want!
The only new problem we introduce is having to ensure that MYBASE is
initialized correctly, but that's an easy one to solve. We could simply
insert the initialization code into the start of the HTML document's
HEAD element. Since we're already rewriting the HTML as part of our
proxy service, this extra modification is trivial.
And that solves the puzzle. I think.
Can anybody spot a flaw in this approach?
Cheers,
Tom
From davidhand at davidhand.com Thu Feb 13 21:28:43 2003
From: davidhand at davidhand.com (David Hand)
Date: Mon Aug 2 21:34:56 2004
Subject: [pgh-pm] Thoughts on that JavaScript problem [resent]
In-Reply-To: <1045188481.1283.276.camel@honeylocust.moertel.com>
References: <1045188481.1283.276.camel@honeylocust.moertel.com>
Message-ID: <20030214032843.GA16007@birthday.local.>
On Thu, Feb 13, 2003 at 09:08:00PM -0500, Tom Moertel wrote:
> we rewrite it as
>
> window.location = MYBASE += << sting expr >>
>
> where MYBASE has been set to "http://myproxy.com/do-proxy" beforehand.
How interesting! Boy, would that've been nice to have thought of when I
was trying to solve this problem before.
I think your solution does the job exactly. Wow.
'Course, I'm still going to parse JavaScript. I'll need to think of
another reason why anyone cares, though. :-)
--
David "cogent" Hand
From tom at moertel.com Thu Feb 13 17:05:17 2003
From: tom at moertel.com (Tom Moertel)
Date: Mon Aug 2 21:34:56 2004
Subject: [pgh-pm] Thoughts on that JavaScript problem
Message-ID: <1045177519.1284.211.camel@honeylocust.moertel.com>
Fellow Perl Folk,
After I got home from last night's meeting, I was thinking about the
original JavaScript problem that was the inspiration for David's JS
parser project. In short, the problem is that we need to locate JS
statements of the form
window.location = << string expr >>
and wrap the string expression -- however long and complicated it may be
-- with a function call that will adjust the URL so that it points to
our rewriting-proxy service:
window.location = adjust_URL( << string expr >> )
The tricky part is that in order to determine the location for the final
parenthesis of the function call, we must parse the string expression
according to JS's baroque grammatical and lexical whims. Nasty.
What other options do we have?
Here's one option. Maybe we can get rid of the nastiness by avoiding
the need to wrap the string in the first place. Let's take a closer
look at adjust_URL. It seems likely that this function must adjust any
URL passed to it by tacking something on to the front in order to
re-target the URL to the proxy service. Further, the function must pass
through the original URL (in some form) for the proxy service to fetch
on our behalf. So, given the original URL
http://original.com/page.html
we want to rewrite it into something like
http://my.proxy.com/do-proxy/http://original.com/page.html
This being the case, adjust_URL must look something like the following:
function adjust_URL(url) {
return "http://my.proxy.com/do-proxy/" + url;
}
Note that the only adjustment we strictly require is to tack something
onto the front of the original URL. With this in mind, let's return to
the original JS statement that we want to adjust:
window.location = << string expr >>
In this statement, it's easy to locate the assignment operator: just
find the equals sign. We also know that the string expression,
regardless of how nasty it is, must immediately follow the assignment
operator. Therefore, at the right-hand side of the (=), we can safely
insert any expression fragment that requires a string expression as its
right-hand side:
window.location = "http://my.proxy.com/do-proxy/"
+ << string expr >>
So, assuming that the original statement was something like
window.location = base + "/page4.html"
our modification will yield
window.location = "http://my.proxy.com/do-proxy/"
+ base + "/page4.html"
which is exactly what we want. Yay! We win, right?
Not quite. The problem is that the assignment operator (=) has loose
binding under precedence rules, and we're substituting the (+) operator,
which binds more tightly. If our original string expression contains an
operator that binds more loosely than (+), precedence will cause our
substitution to break. Consider this original statement:
window.location = page == 1 ? "page2.html" : "page1.html"
Applying our modification will yield
window.location = "http://my.proxy.com/do-proxy/"
+ page == 1 ? "page2.html" : "page1.html"
Which unfortunately parses like so:
window.location = ( (("http://my.proxy.com/do-proxy/" + page) == 1)
? "page2.html" : "page1.html" )
Oops. Not only did we change the meaning of the test in the (?)
operator, we failed to rewrite its result, so we're hosed twice.
But we're not dead yet.
One solution to the precedence problem is to use parentheses to wrap and
protect the original expression. After all, that's what parentheses are
for. Unfortunately, this solution puts us right back where we started:
having to parse the string expression to find out where to put the
closing parenthesis.
Luckily, there is a better way. Instead of using (+) in our
substitution, we can use (+=). This operator has the same precedence as
the original assignment (=), so we don't need to parenthesize the
original expression. The only trick is that (+=) must have a modifiable
reference as its left-hand side. That's doable.
Let's see how it works. Given
window.location = << sting expr >>
we rewrite it as
window.location = MYBASE += << sting expr >>
where MYBASE has been set to "http://myproxy.com/do-proxy" beforehand.
Let's apply this technique to our troublesome example with the (?)
operator and see if it works. Given
window.location = page == 1 ? "page2.html" : "page1.html"
we rewrite it as
window.location = MYBASE += page == 1 ? "page2.html" : "page1.html"
which parses like so:
window.location = ( MYBASE
+= (page == 1 ? "page2.html" : "page1.html") )
This is exactly what we want!
The only new problem we introduce is having to ensure that MYBASE is
initialized correctly, but that's an easy one to solve. We could simply
insert the initialization code into the start of the HTML document's
HEAD element. Since we're already rewriting the HTML as part of our
proxy service, this extra modification is trivial.
And that solves the puzzle. I think.
Can anybody spot a flaw in this approach?
Cheers,
Tom
From casey at geeknest.com Thu Feb 27 08:01:04 2003
From: casey at geeknest.com (Casey West)
Date: Mon Aug 2 21:34:56 2004
Subject: [pgh-pm] In need of March meeting ideas.
Message-ID: <20030227140104.GE69372@geeknest.com>
March meeting is fast approaching, and my first idea was a tour of
Marconi Campus, but that seems unlikley. March is a social meeting,
I'd like to do something interesting, I just need some ideas. I'll
do the foot work.
Some of my favorite things to do include going to a good, quite coffee
shop and sitting for a few hours, but I don't know if those exist in
Pittsburgh. Other ideas might be a trip to the Science Center. Have
an idea? Please tell me about it.
Casey West
--
If unix is the face of the future I wanna go back to quill pens.
-- Joseph Snipp
From bmj at anklebiter.net Thu Feb 27 08:02:23 2003
From: bmj at anklebiter.net (brian janaszek)
Date: Mon Aug 2 21:34:56 2004
Subject: [pgh-pm] In need of March meeting ideas.
In-Reply-To: <20030227140104.GE69372@geeknest.com>
Message-ID: <180DD45A-4A5C-11D7-9779-003065E4B30E@anklebiter.net>
No good quiet coffee shops? How about the Tazzo d'Oro in Highland Park
(http://www.tazzadoro.net/index.html)? It's a bit off the beaten path
but it is quiet and the coffee is good.
brian
On Thursday, February 27, 2003, at 09:01 AM, Casey West wrote:
> March meeting is fast approaching, and my first idea was a tour of
> Marconi Campus, but that seems unlikley. March is a social meeting,
> I'd like to do something interesting, I just need some ideas. I'll
> do the foot work.
>
> Some of my favorite things to do include going to a good, quite coffee
> shop and sitting for a few hours, but I don't know if those exist in
> Pittsburgh. Other ideas might be a trip to the Science Center. Have
> an idea? Please tell me about it.
>
> Casey West
>
> --
> If unix is the face of the future I wanna go back to quill pens.
> -- Joseph Snipp
>
> _______________________________________________
> pgh-pm mailing list
> pgh-pm@mail.pm.org
> http://mail.pm.org/mailman/listinfo/pgh-pm
>
>