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