From perl.abe at rjbs.manxome.org  Fri May  2 05:14:42 2008
From: perl.abe at rjbs.manxome.org (Ricardo SIGNES)
Date: Fri, 2 May 2008 08:14:42 -0400
Subject: [ABE.pm] technical meeting, may 7: let's hack
Message-ID: <20080502121442.GA60165@knight.local>


We have the library room for May 7.  I don't think anyone has volunteered to
present, and of my upcoming presentations, you've seen them all -- except for
the one that isn't even started yet.

So, who is interested in getting together and doing some group hacking on
something fun?  If no one else does, I will supply a fun project, a network,
and I will teach everyone how to use... git!  Man, git is so great!

Who's in?  Bring a laptop.

-- 
rjbs

From faber at linuxnj.com  Fri May  2 07:02:03 2008
From: faber at linuxnj.com (Faber J. Fedor)
Date: Fri, 2 May 2008 10:02:03 -0400
Subject: [ABE.pm] technical meeting, may 7: let's hack
In-Reply-To: <20080502121442.GA60165@knight.local>
References: <20080502121442.GA60165@knight.local>
Message-ID: <20080502140203.GA6149@neptune.faber.nom>

On 02/05/08 08:14 -0400, Ricardo SIGNES wrote:
> So, who is interested in getting together and doing some group hacking on
> something fun?  If no one else does, I will supply a fun project, a network,
> and I will teach everyone how to use... git!  Man, git is so great!
> 
> Who's in?  Bring a laptop.

That sounds cool.  Need a switch or anything? I'll have my mini-DVI-VGA
converter.  And some cables.

-- 
 
Regards,
 
Faber Fedor
President
Linux New Jersey, Inc.
908-320-0357
800-706-0701

http://www.linuxnj.com




From perl.abe at rjbs.manxome.org  Fri May  2 07:14:31 2008
From: perl.abe at rjbs.manxome.org (Ricardo SIGNES)
Date: Fri, 2 May 2008 10:14:31 -0400
Subject: [ABE.pm] technical meeting, may 7: let's hack
In-Reply-To: <20080502140203.GA6149@neptune.faber.nom>
References: <20080502121442.GA60165@knight.local>
	<20080502140203.GA6149@neptune.faber.nom>
Message-ID: <20080502141431.GA27231@cancer.codesimply.com>

* "Faber J. Fedor" <faber at linuxnj.com> [2008-05-02T10:02:03]
> On 02/05/08 08:14 -0400, Ricardo SIGNES wrote:
> > So, who is interested in getting together and doing some group hacking on
> > something fun?  If no one else does, I will supply a fun project, a network,
> > and I will teach everyone how to use... git!  Man, git is so great!
> > 
> > Who's in?  Bring a laptop.
> 
> That sounds cool.  Need a switch or anything? I'll have my mini-DVI-VGA
> converter.  And some cables.

If it's convenient to toss in a bag, it can't hurt.  I wish my spare AirPort
was the kind with disk sharing.  I'll set something else up for that, though.

-- 
rjbs

From perl.abe at rjbs.manxome.org  Fri May  2 09:10:45 2008
From: perl.abe at rjbs.manxome.org (Ricardo SIGNES)
Date: Fri, 2 May 2008 12:10:45 -0400
Subject: [ABE.pm] time to register for YAPC!
Message-ID: <20080502161045.GA61453@minion169.office.icgroup.com>


  http://conferences.mongueurs.net/yn2008/

YAPC::NA is in Chicago (again) this year, and will (again) be totally great.
There are a lot of interesting-seeming talks.  Registration is $85 if you
register soon.  In standard conference costs, that's basically equivalent to
$0.

See you there!

-- 
rjbs

From faber at linuxnj.com  Fri May  2 10:18:39 2008
From: faber at linuxnj.com (Faber J. Fedor)
Date: Fri, 2 May 2008 13:18:39 -0400
Subject: [ABE.pm] OT: Beer meetups
Message-ID: <20080502171839.GA6857@neptune.faber.nom>

I don't know how many of you guys are on Meetup.com, but there is a
local (to youn's) beer meetup called the Lehigh Valley Beer Meetup
(http://beer.meetup.com/204/).  I was at the inaugural meetup at the
Allentown Brew Works last month and it was a blast! We got a lot of
half-priced beers and a tour of the place from one of the owners (did
you know there was a really cool, laid-back nightclub in the cellar of
the ABW?)

Unfortunately, this month's meeting about home brewing is this Wednesday
night, but there is another one on the 27th at the Bethlehem Brew Works.

-- 
 
Regards,
 
Faber Fedor
President
Linux New Jersey, Inc.
908-320-0357
800-706-0701

http://www.linuxnj.com




From perl.abe at rjbs.manxome.org  Thu May  8 06:56:49 2008
From: perl.abe at rjbs.manxome.org (Ricardo SIGNES)
Date: Thu, 8 May 2008 09:56:49 -0400
Subject: [ABE.pm] review of last night's hacking
Message-ID: <20080508135649.GA10664@knight.local>


So, I think last night's meeting was good!  Here's a recap for those who could
not attend:

We met at the upstairs room of the library with the intention of doing some
group hacking on a project to be provided by me.  I brought a game I've been
working on for a while.  After I got the shared workstation (a virtual Debian
box running on my laptop, under Parallels) set up properly, we got to work with
our respective editors.  We used git, with a setup like this:

  master repo on my laptop
   |
  my clone on the virt
   |      |    |     |
  faber  tom  walt  paul

I pulled from the other guys regularly, and they pulled from my clone.  In the
future, there's no reason that it couldn't look more like (yow!) this:

  master repo on my laptop
   |
  my clone on the virt
   |      |    |     |
  faber--tom--walt--paul
   | |    |    |    | |
   | +----|----+    | |
   +------|---------+ |
          +-----------+

In other words, everybody can share revisions with everybody else, so that
(say) Tom and Paul could work on one feature together before informing me that
it's ready to be merged to the local master.  (...and don't get me started on
how useful branches are for this!)

Anyway, I'm digressing about git, now.

The game's current interface is an IRC bot, so we spent some time adding
commands to it and fixing its output.  Basically all the work was done on
one IRC.pm file, and I don't think any obnoxious conflicts occurred.

I didn't have our workstation as prepared as I would have liked, so we couldn't
really start work until about 19:00, and we finished up around 20:45 or so.

I think it was a pretty successful, enjoyable venture.  If I am not alone in
thinking that, I think we could do that again.  Next time, we'd have a much
easier time of getting started.  I won't need to install any of the crap I had
to install last night, because I am not going to throw away that workstation
image.  I'll write up my notes on how I set up the networking stuff and see if
I can't make it a little simpler.

Anybody else have thoughts on how it went?

-- 
rjbs

From faber at linuxnj.com  Thu May  8 08:11:52 2008
From: faber at linuxnj.com (Faber J. Fedor)
Date: Thu, 8 May 2008 11:11:52 -0400
Subject: [ABE.pm] review of last night's hacking
In-Reply-To: <20080508135649.GA10664@knight.local>
References: <20080508135649.GA10664@knight.local>
Message-ID: <20080508151152.GC12147@neptune.faber.nom>

On 08/05/08 09:56 -0400, Ricardo SIGNES wrote:
> Anybody else have thoughts on how it went?

I thought it was pretty good, if a bit unstructured, but now that your
VM is properly setup... :-)

I liked learning about git while hacking real code. We should do more
hands-on things like that in the future.

> The game's current interface is an IRC bot, so we spent some time adding
> commands to it and fixing its output.  Basically all the work was done on
> one IRC.pm file, and I don't think any obnoxious conflicts occurred.

True, but I loved the way git handled the conflict between your change
and mine.  That was pretty cool.  I can see why Linus developed git the
way he did.  
 
I'd also like to get a better idea of how the game works in general,
especially with POE and Moose but that's prolly more a lecture than a
hacking.

Can I get the src for your game so I can play with it on my own?  Oh,
and I'm still waiting for the src to your IM assistant.

Finally, the nachos at the Bethlehem Brew Works were meh but the ESB was
good.


-- 
 
Regards,
 
Faber Fedor
President
Linux New Jersey, Inc.
908-320-0357
800-706-0701

http://www.linuxnj.com




From perl.abe at rjbs.manxome.org  Thu May  8 08:25:58 2008
From: perl.abe at rjbs.manxome.org (Ricardo SIGNES)
Date: Thu, 8 May 2008 11:25:58 -0400
Subject: [ABE.pm] review of last night's hacking
In-Reply-To: <20080508151152.GC12147@neptune.faber.nom>
References: <20080508135649.GA10664@knight.local>
	<20080508151152.GC12147@neptune.faber.nom>
Message-ID: <20080508152558.GA11330@knight.local>

* "Faber J. Fedor" <faber at linuxnj.com> [2008-05-08T11:11:52]
> On 08/05/08 09:56 -0400, Ricardo SIGNES wrote:
> > Anybody else have thoughts on how it went?
> 
> I thought it was pretty good, if a bit unstructured, but now that your
> VM is properly setup... :-)

I think it will remain fairly unstructured, but in the future it'll be easier
to say, "here are things to get done, the server is up, GO!"

> I liked learning about git while hacking real code. We should do more
> hands-on things like that in the future.

Excellent.

> > The game's current interface is an IRC bot, so we spent some time adding
> > commands to it and fixing its output.  Basically all the work was done on
> > one IRC.pm file, and I don't think any obnoxious conflicts occurred.
> 
> True, but I loved the way git handled the conflict between your change
> and mine.  That was pretty cool.  I can see why Linus developed git the
> way he did.  

To be fair, Subversion and CVS handle the case you saw in the same way.  The
ability to branch and merge so easily is what made git so useful last night.
Maybe I'll mumble more about how that's cool later.

Basically, the nice thing last night was the ability for each person to work on
his own checkout, making commits that /did not affect anyone else/ and then to
merge those.  In Subversion, those commits would have to go to the central
server.  There are ways around this, but they're annoying, in my experience.

> I'd also like to get a better idea of how the game works in general,
> especially with POE and Moose but that's prolly more a lecture than a
> hacking.

Yeah, maybe I can explain a bit more of it each time.

> Can I get the src for your game so I can play with it on my own?  Oh,
> and I'm still waiting for the src to your IM assistant.

I will try to bring myself to part with the source.  I'm trying to keep it
under wraps.  If you're going to be contributing to it, though, I should try to
give you a clone of the repo. :)

> Finally, the nachos at the Bethlehem Brew Works were meh but the ESB was
> good.

Heh.  I think the nachos would be good as a shared appetizer.  I can see them
being meh for a meal.

-- 
rjbs

From faber at linuxnj.com  Thu May  8 08:55:16 2008
From: faber at linuxnj.com (Faber J. Fedor)
Date: Thu, 8 May 2008 11:55:16 -0400
Subject: [ABE.pm] review of last night's hacking
In-Reply-To: <20080508152558.GA11330@knight.local>
References: <20080508135649.GA10664@knight.local>
	<20080508151152.GC12147@neptune.faber.nom>
	<20080508152558.GA11330@knight.local>
Message-ID: <20080508155516.GB12403@neptune.faber.nom>

On 08/05/08 11:25 -0400, Ricardo SIGNES wrote:
> * "Faber J. Fedor" <faber at linuxnj.com> [2008-05-08T11:11:52]
> ability to branch and merge so easily is what made git so useful last night.
> Maybe I'll mumble more about how that's cool later.
> 
> Basically, the nice thing last night was the ability for each person to work on
> his own checkout, making commits that /did not affect anyone else/ and then to
> merge those.  In Subversion, those commits would have to go to the central
> server.  There are ways around this, but they're annoying, in my experience.

You're going to have to elaborate (not necessarily on the list), because
I didn't see much of a (functional) difference from what we did last
night and what Subversion does.  You pulling the changes in looked like
a pull from the "central repository" from where I was sitting.

> I will try to bring myself to part with the source.  I'm trying to keep it
> under wraps.  If you're going to be contributing to it, though, I should try to
> give you a clone of the repo. :)

Actually, I'm more interested in some of your programming techniques,
like the *_PATTERNS/dispatch table trick.  I want to see what else
you've got hidden in there.


-- 
 
Regards,
 
Faber Fedor
President
Linux New Jersey, Inc.
908-320-0357
800-706-0701

http://www.linuxnj.com




From waltman at pobox.com  Thu May  8 09:04:44 2008
From: waltman at pobox.com (Walt Mankowski)
Date: Thu, 8 May 2008 12:04:44 -0400
Subject: [ABE.pm] review of last night's hacking
In-Reply-To: <20080508152558.GA11330@knight.local>
References: <20080508135649.GA10664@knight.local>
	<20080508151152.GC12147@neptune.faber.nom>
	<20080508152558.GA11330@knight.local>
Message-ID: <20080508160444.GV23250@mawode.com>

On Thu, May 08, 2008 at 11:25:58AM -0400, Ricardo SIGNES wrote:
> > Finally, the nachos at the Bethlehem Brew Works were meh but the ESB was
> > good.
> 
> Heh.  I think the nachos would be good as a shared appetizer.  I can see them
> being meh for a meal.

I quite enjoyed munching on your leftover nachos as dessert.  Thanks
for sharing them. :)  And the brats were really excellent.  I thought
the ESB was just OK.  I'd have liked to have tried the IPA too but not
with an hour drive home. :(

W

From faber at linuxnj.com  Thu May  8 12:17:38 2008
From: faber at linuxnj.com (Faber J. Fedor)
Date: Thu, 8 May 2008 15:17:38 -0400
Subject: [ABE.pm] ABE-PM website?
Message-ID: <20080508191738.GA13161@neptune.faber.nom>


Is this (http://www.perlfoundation.org/abe-pm/index.cgi) the site I
should link to from my blog (http://www.linuxnj.com)?

-- 
 
Regards,
 
Faber Fedor
President
Linux New Jersey, Inc.
908-320-0357
800-706-0701

http://www.linuxnj.com




From perl.abe at rjbs.manxome.org  Thu May  8 13:01:50 2008
From: perl.abe at rjbs.manxome.org (Ricardo SIGNES)
Date: Thu, 8 May 2008 16:01:50 -0400
Subject: [ABE.pm] ABE-PM website?
In-Reply-To: <20080508191738.GA13161@neptune.faber.nom>
References: <20080508191738.GA13161@neptune.faber.nom>
Message-ID: <20080508200150.GA13198@knight.local>

* "Faber J. Fedor" <faber at linuxnj.com> [2008-05-08T15:17:38]
> Is this (http://www.perlfoundation.org/abe-pm/index.cgi) the site I
> should link to from my blog (http://www.linuxnj.com)?

Yes.

-- 
rjbs

From perl.abe at rjbs.manxome.org  Thu May  8 19:35:13 2008
From: perl.abe at rjbs.manxome.org (Ricardo SIGNES)
Date: Thu, 8 May 2008 22:35:13 -0400
Subject: [ABE.pm] review of last night's hacking
In-Reply-To: <20080508155516.GB12403@neptune.faber.nom>
References: <20080508135649.GA10664@knight.local>
	<20080508151152.GC12147@neptune.faber.nom>
	<20080508152558.GA11330@knight.local>
	<20080508155516.GB12403@neptune.faber.nom>
Message-ID: <20080509023513.GA15265@knight.local>

* "Faber J. Fedor" <faber at linuxnj.com> [2008-05-08T11:55:16]
> You're going to have to elaborate (not necessarily on the list), because
> I didn't see much of a (functional) difference from what we did last
> night and what Subversion does.  You pulling the changes in looked like
> a pull from the "central repository" from where I was sitting.

I'm happy to elaborate here.

What we did was very close to Subversion's centralized workflow, because it's
easy for most people to grasp if they've already worked with Subversion.  There
were a few key differences:

  1. when you made a commit, you were committing only to your local repository,
  whereas in Subversion your commit would go to the master immediately

  2. you had no ability to send things to a master at all; in fact, there was
  no central master repository, just the "origin" from which you made your
  clone; instead of sending your changes to it, its owner (me) pulled changes
  from you and you pulled more changes from it

(2) is really a central concept to understanding how git can change your
workflow.  All repositories are peers.  None is the master.  The things that
vary in importance are the repostory maintainers.  If you clone the Linux
repository, you can pull from all of the same Linux developers as Linus, and
you can choose to accept and reject different changes.  Now you've got a
repository of Linux as you'd like to see it.  It can contain all the same code,
but with changes merged differently.  It's the technical peer of the kernel.org
repository -- it's just another peer with someone pulling in changes.

The reason it's not as important is that you don't have the authority to
convince the whole world to install your branch.  If you could convince
everyone, though, they could just start pulling from you instead of Linus and
that's that.  People wouldn't have to do anything drastic to start trusting a
different authority.

This becomes more important when you get into doing what I imagine we'll do
eventually: peer to peer change sharing.  It's less complex than it sounds.

The way we worked:

  1. faber and tfreedman clone rjbs's respository
  2. faber commits changes
  3. faber tells rjbs that he's made changes that are ready for production
  4. rjbs pulls from faber and merges those changes into his repo
  5. rjbs tells tfreeman that new changes are available
  6. tfreedman pulls from rjbs and merges those changes into his repo

That's fine when everyone is working on different things.  If faber and
tfreedman are working on the same feature, though, this could happen

  1. faber and tfreedman clone rjbs's respository
  2. faber commits changes
  3. faber tells tfreedman that he's made changes
  4. tfreedman pulls from faber and merges those changes into his repo
  5. tfreedman commits changes
  6. tfreedman tells faber that he's made changes
  7. faber pulls from tfreedman and merges those changes into his repo
  8. faber tells rjbs that they've made changes that are ready for production
  9. rjbs pulls from faber and merges those changes into his repo

Note that in 8 and 9, it doesn't matter whether rjbs pulls from faber or
tfreedman.  They'd have identical changesets, and the authorship of each
individual commit is preserved.  This is another good reason to commit often:
to allow individual changes to be clearly identifiable after merging.

> Actually, I'm more interested in some of your programming techniques,
> like the *_PATTERNS/dispatch table trick.  I want to see what else
> you've got hidden in there.

I could've sworn I posted about that here.  I guess not, though.

  http://rjbs.manxome.org/rubric/entry/1564

-- 
rjbs

From perl.abe at rjbs.manxome.org  Thu May  8 19:52:06 2008
From: perl.abe at rjbs.manxome.org (Ricardo SIGNES)
Date: Thu, 8 May 2008 22:52:06 -0400
Subject: [ABE.pm] future meeting schedule
Message-ID: <20080509025206.GB15265@knight.local>


Just for review, since the summer is crazy:

  Jun 4th - social meeting, McGrady's; Ted will show up and eat wings
  Jul 2nd - technical meeting; probably more hacking!
  Aug 6th - social meeting
  Sep 3rd - technical meeting

I would not be averse to doing more hacking in general, but I think an
excellent way to enable that would be to find a venue where we could have some
food while working.  At the library, we can have "snacks," but I think we'd
probably all be happy with a couple of pizzas to work from 17:30 (or whenever
you show up) until 21:00 or 22:00, depending on motivation levels.  Also, it
would mean that I'd be more likely to pay more of the tab, having not dropped
$21 on the venue, if we found a place for free or cheap.

I just don't know anyplace suitable off hand.  Bright ideas welcomed!

-- 
rjbs

From faber at linuxnj.com  Fri May  9 06:38:23 2008
From: faber at linuxnj.com (Faber J. Fedor)
Date: Fri, 9 May 2008 09:38:23 -0400
Subject: [ABE.pm] review of last night's hacking
In-Reply-To: <20080509023513.GA15265@knight.local>
References: <20080508135649.GA10664@knight.local>
	<20080508151152.GC12147@neptune.faber.nom>
	<20080508152558.GA11330@knight.local>
	<20080508155516.GB12403@neptune.faber.nom>
	<20080509023513.GA15265@knight.local>
Message-ID: <20080509133823.GA16473@neptune.faber.nom>

On 08/05/08 22:35 -0400, Ricardo SIGNES wrote:
> > Actually, I'm more interested in some of your programming techniques,
> > like the *_PATTERNS/dispatch table trick.  I want to see what else
> > you've got hidden in there.
> 
> I could've sworn I posted about that here.  I guess not, though.
> 
>   http://rjbs.manxome.org/rubric/entry/1564

Not the named capture stuff, this stuff:

    my ($pattern, $method) = @MSG_PATTERNS[ $i, $i + 1 ];
    next unless $msg =~ /\A$pattern\z/;
    my $result = $self->$method({%+});

I never thought to A) put a regex in the first index(?) of an array and
B) I didn't know you could use a variable name as a method call like that.

Where does '{%+}' come from?  Is that the Moose stuff?

-- 
 
Regards,
 
Faber Fedor
President
Linux New Jersey, Inc.
908-320-0357
800-706-0701

http://www.linuxnj.com




From perl.abe at rjbs.manxome.org  Fri May  9 07:18:20 2008
From: perl.abe at rjbs.manxome.org (Ricardo SIGNES)
Date: Fri, 9 May 2008 10:18:20 -0400
Subject: [ABE.pm] review of last night's hacking
In-Reply-To: <20080509133823.GA16473@neptune.faber.nom>
References: <20080508135649.GA10664@knight.local>
	<20080508151152.GC12147@neptune.faber.nom>
	<20080508152558.GA11330@knight.local>
	<20080508155516.GB12403@neptune.faber.nom>
	<20080509023513.GA15265@knight.local>
	<20080509133823.GA16473@neptune.faber.nom>
Message-ID: <20080509141820.GA27820@cancer.codesimply.com>

* "Faber J. Fedor" <faber at linuxnj.com> [2008-05-09T09:38:23]
> On 08/05/08 22:35 -0400, Ricardo SIGNES wrote:
> > > Actually, I'm more interested in some of your programming techniques,
> > > like the *_PATTERNS/dispatch table trick.  I want to see what else
> > > you've got hidden in there.
> > 
> >   http://rjbs.manxome.org/rubric/entry/1564
> 
> Not the named capture stuff, this stuff:
> 
>     my ($pattern, $method) = @MSG_PATTERNS[ $i, $i + 1 ];
>     next unless $msg =~ /\A$pattern\z/;
>     my $result = $self->$method({%+});

That is the named capture stuff.

> I never thought to A) put a regex in the first index(?) of an array and
> B) I didn't know you could use a variable name as a method call like that.

You can put any scalar in any index of an array.  Don't get confused with
hashes, which only use strings as keys.

  @foo = ($object, $object, $object);
  %foo = ($object, $object, $object);

The first one stores an array containing three references to the object.

The second stores the same thing as:

  %foo = ("$object", $object, "$object", undef);

...and raises a warning about an odd number of items being assigned to a hash,
I think.

Using a scalar as a method name is often unknown or overlooked, but it's
incredibly powerful.  It means that objects can be easily used as a dispatch
table without most of the insanity of "using a string as a subroutine name."
(That's because of the difference between function and method dispatch, which
is pretty boring.)

> Where does '{%+}' come from?  Is that the Moose stuff?

You might want to go back and read the entry I linked to, taking it on faith
that it's about this.  Here's an section from it:

  The important points are:

   1. the regex pattern with named captures like: (?<x>-?\d+)
   2. the method call that passes in { %+ }

  See, if the pattern matches, all the named captures end up in the magic
  variable %+. That

You can read about %+ in the "perlvar" perldoc page, as long as you're running
5.10.

-- 
rjbs

From faber at linuxnj.com  Fri May  9 12:41:15 2008
From: faber at linuxnj.com (Faber J. Fedor)
Date: Fri, 9 May 2008 15:41:15 -0400
Subject: [ABE.pm] hashes of hashes and more
Message-ID: <20080509194115.GA22418@neptune.faber.nom>

I want to build a tree like this:

$self->{tree}
     |
     -- node1
     |   |
     |   -- @children[ node3, node4]
     |
     -- node2
         |
         -- @children[node5, node6]

I thought adding node3 as a child of node1 would be

my $var = 'node1'
push( @{ $self->{tree}->{$var}->{'children'} }, 'node3');

put I keep getting 

Can't use string ("node1") as a HASH ref yada yada yada

Suggestions?

-- 
 
Regards,
 
Faber Fedor
President
Linux New Jersey, Inc.
908-320-0357
800-706-0701

http://www.linuxnj.com




From hdp at pobox.com  Fri May  9 12:46:05 2008
From: hdp at pobox.com (Hans Dieter Pearcey)
Date: Fri, 9 May 2008 15:46:05 -0400
Subject: [ABE.pm] hashes of hashes and more
In-Reply-To: <20080509194115.GA22418@neptune.faber.nom>
References: <20080509194115.GA22418@neptune.faber.nom>
Message-ID: <20080509194605.GR31434@vex.pobox.com>

On Fri, May 09, 2008 at 03:41:15PM -0400, Faber J. Fedor wrote:
> I thought adding node3 as a child of node1 would be
> 
> my $var = 'node1'
> push( @{ $self->{tree}->{$var}->{'children'} }, 'node3');
> 
> put I keep getting 
> 
> Can't use string ("node1") as a HASH ref yada yada yada
> 
> Suggestions?

There's nothing wrong with your example.  Show real code.

hdp.

From faber at linuxnj.com  Fri May  9 12:50:17 2008
From: faber at linuxnj.com (Faber J. Fedor)
Date: Fri, 9 May 2008 15:50:17 -0400
Subject: [ABE.pm] Never mind...
Message-ID: <20080509195017.GB22418@neptune.faber.nom>

 I figured it out less than five minutes after posting.


-- 
 
Regards,
 
Faber Fedor
President
Linux New Jersey, Inc.
908-320-0357
800-706-0701

http://www.linuxnj.com




From perl.abe at rjbs.manxome.org  Mon May 12 19:10:00 2008
From: perl.abe at rjbs.manxome.org (Ricardo SIGNES)
Date: Mon, 12 May 2008 22:10:00 -0400
Subject: [ABE.pm] the new autobox.pm is totally awesome
Message-ID: <20080513021000.GA9294@knight.local>


autobox.pm lets you call methods on unblessed references and plain Perl data
types.  Here are some notes:

  http://rjbs.manxome.org/rubric/entry/1623

-- 
rjbs

From perl.abe at rjbs.manxome.org  Sun May 18 19:18:31 2008
From: perl.abe at rjbs.manxome.org (Ricardo SIGNES)
Date: Sun, 18 May 2008 22:18:31 -0400
Subject: [ABE.pm] Dear Leader hacking: the irc-inversion
Message-ID: <20080519021831.GB50766@knight.local>


I've very very tentatively begun work on what I think is one of the most
important non-gameplay-related milestones in Dear Leader: the IRC inversion
project.  Right now, the DL::IRC component joins an existing IRC server (like
the hybrid-ircd running on the abe-pm virtual workstation) and joins a channel
and acts like any other bot.  It just happens to respond to things addressed to
"unit name, ..." and "city name, ..."

This is less than ideal for many, many reasons.

There's no really simple way for it to know what nick has logged in as what IRC
user, or to what nickserv identity one has authenticated.  Or, rather, that's
possibly only by hooking into existing IRC services or ircd stuff.

The addressable things like units and cities aren't really in the channel, so
they can't be tab-completed.

Figuring out who is connected at any given time is slightly less trivial than
it needs to be.

And so on.

For a long time, I've thought the solution was to make the game its own IRC
server.  When a user connects (with a username and password) he will be forced
to join a "lobby" channel where all the players and kibitzers will hang out.
If he's in the game, he will also be able to join (or will be force-joined?) a
channel where only he and his units and cities will appear.  I mean: if you
have a city called Montreal, then there will appear another nick in your
channel called Montreal.  It will be a virtual entity, with no associated
connection, but it will listen for commands and respond accordingly.  Other
virtual, locked channels may be created per faction, so all members of a
faction may speak freely.

There are plenty of benefits here, just to the existing mechanics.  Eventually,
I can imagine a unit that could infiltrate another faction's communications
network, meaning that you could read a transcript of #faction chatter without
showing up there.  The possibilities are vast.

Anyway, this means I'm trying to figure out more about
POE::Component::Server:IRC, which seems like a very cool ircd, but like it
needs some more documentation for futzing around with its concept of channels.

If anyone is interested in digging into this some more, let me know!

-- 
rjbs

From perl.abe at rjbs.manxome.org  Sun May 18 20:22:47 2008
From: perl.abe at rjbs.manxome.org (Ricardo SIGNES)
Date: Sun, 18 May 2008 23:22:47 -0400
Subject: [ABE.pm] metaprogramming is way cool
Message-ID: <20080519032247.GC50766@knight.local>


Remember that technical meeting where I engaged in a length digression about
something that seemed fairly irrelevant?

Wait, I need to be more specific?

At the meeting on May 7th, I went on and on about something that's going on
with a possible new feature for perl (either as a new module or as part of
5.12).  It's overloading for the method invocation operator.

Huh?  Well, it's actually pretty simple.

When you write this:

  $object->method($arg1, $arg2);

This happens (but note that this code is just simplified enough to not work):

  my $class = ref $object;  # we find the name of the class of the object

  while ($class) {          # we start a loop (this will make sense soon)

    my $code = \&{"$class::method"}; # we get the sub "method" in that class
    if (defined &$code) {                     # ...and if exists
      return $code->($object, $arg1, $arg2);  # call it with these args
    }

    $class = shift @{"$class::ISA"}; # otherwise, try on our parent class
  }

  die "no such method!"     # if we didn't return by now, there's no method!

Like I said, this isn't quite right, for a few reasons, but it illustrates the
point.  Here are some of the assumptions built into how method calls work in
Perl:

  * objects are members of a class, and a class is represented by a package
  * @ISA is the way that super/sub-classes are set up
  * the object method X is a sub named X in the class's package
  * ...unless it's a sub named X in a package in that package's @ISA variable
  * the class method X is a sub named X in the class's package (or in @ISA)
  * ...which means that object and class methods share the same namespace
  * ...and that methods are always found by name
  * if no package in ISA defines X, look in UNIVERSAL
  * failing that, call the sub AUTOLOAD, if defined in the class package

This isn't ideal, but it's pretty good for most things that most people need.
Here are a few things that you can't do with it:

You can't...

  * ever have your AUTOLOAD find a method in UNIVERSAL
  * clearly divide object methods from class methods
  * have distinct classes that do not map to packages
  * determine how to find superclasses any other way than @ISA
  * define methods via anything other than AUTOLOAD (which fails as noted
    above) or as named subroutines in packages

These are fairly unusual cases, but they come in handy.  If you want a lot of
similar objects that have different methods available, or different behaviors
for their methods, it might be useful to do "classless" or "prototype-based" OO
the way that JavaScript does.  Separating class from instance methods is just
wonderfully useful in general, but most Perl programmers have learned to live
without it.  Having classes without packages is not wildly useful per se, but
because packages in Perl are difficult to track, inspect, or destroy, replacing
a "package-based" class with something else would provide many benefits.

So, the solution under discussion is to say that when the user writes:

  $object->method($arg1, $arg2);

...that the author of a class may choose to say, "don't do the usual thing
(approximated in the code snippet above).  Instead, do my special thing."
Because the method call looks totally normal, the user doesn't need to know
that behind the scenes it's doing something special.

The idea here is that the user -- the guy using this $object -- knows that
there is a defined way to deal with objects.  You say:

  my $object = Class->new( ... );

and later you say:

  $object->method($arg1, $arg2);

over and over until you're done.  It's the same way he knows to use "my @array"
to make an array and "push @array, $item" to append to it.  It's the language's
contract or protocol for users.  As long as the user sees the same interface,
he can understand what's happening.

For a long time, now, Perl has had the ability to "tie" a variable.  This
basically means you can make a thing called @array that has more behavior than
a normal array.  When you push to it, something more can happen -- but you
still /push/ to it, with "push @array, $item".  As far as the user is
concerned, it's still an array.  He can be blissfully unaware of whatever magic
has been added, and doesn't need to learn some new interface like:

  my $array = Magic::Tracker->new;
  $array->push($item);

Unfortuantely, implementing tied variables is ugly.  Tied variables are looked
down on for many reasons, rightly and wrongly.  One good reason is that they're
hard to extend.  If you say, "this routine expects to be passed a reference to
an array," then you know you expect something that you build with \@array.
That is, something that you can do these things to:

  push @$array, $foo;
  splice @$array, 0, 1, @list;
  unshift @$array
  etc

That list is determined by Perl.  You can't add to it.  If later you are going
to demand something that's an array reference, but has extra methods, you end
up passing in something that has overloaded array dereference logic (as awful
as it sounds) or you have to do something insane like:

  (tied @$array)->method(...)

Fail!

autobox, which I mentioned recently, helps get around this problem.  You can
define a set of needed methods -- push, pop, etc -- and then say that any
object that provides those methods can be passed in.  Users know just what they
have to implement to meet the requirements.  You don't have to worry about the
limited growth potential of tied variables.  With autobox, you can start off
saying, "since I know that I can do everything I need based on an array, I will
treat plain old array references like objects with these methods by using
autobox to say that an array reference has all the methods defined in my
Array::Adapter::ForMyCode class."

So, again, you provide a formal interface (basically a list of required
methods) that your code requires.  Basic users only need to know that they can
pass in an array reference or a MagicList object.  Advanced users have clear
instructions for what kind of object they can build on their own and pass in.

There are two related ideas at work here.  One is the ability to have known
interfaces that can be made to behave in a different way without changing the
interface.  The other is the the ability to use this technique not only for
making two similar classes, but for replacing any part at all of the
programming language with something that looks the same but is implemented
differently.

At another technical meeting, I talked a little about Moose, which steals some
of its ideas from CLOS, the Common Lisp Object System.  They're both made very
powerful by the idea of metaprogramming and a meta-object protocol.  It's a
very simple idea, if you get past the name.

The idea is that if you can define the way that objects, classes, and all those
things are used by programmers, then you can change the way they behave behind
the scenes.  That is, you can let the programmer say:

  standard class Foo {
    method bar(int i): { ... }
    ...
  }

and something like this will happen behind the scenes:

  standard->new_class(
    name    => 'Foo',
    methods => {
      bar => {
        args => [ "int i" ],
        code => sub { ... },
      },
    },
  );

What happens?  Well, it's up to the definition of 'standard' which is just a
class implementing the interface that says "I make classes!"  If you want to
write your own class builder, called "funky" you can.  Then someone else can
write:

  funky class Bar { ... }

They don't need to know anything about how it works.  They know it will make a
class, and they probably know what the end-user documentation says about how
funky classes differ from normal classes.

Perl really lacks any kind of built-in protocol for this kind of thing.  At
best, classes are defined by how objects respond to 'ref' and the methods 'isa'
and 'can' and 'DOES' and how methods are dispatched.  Once method dispatch can
be customized, it will be possible to write any sort of object system (within
some very, very broad limits, anyway) in pure Perl, and it will look just like
normal Perl.  The end user won't need to care.

The question of "code that writes code" has come up a few times, here, but I
think a much more useful and interesting idea is the idea of a "programmable
programming language."  That label is often applied to Lisp, in which basically every part of the language can be extended or altered as needed.

I realize that this is a long, somewhat disjointed and rambling post.  I want
to get across, though, the importance and fundamental value of the ability to
programatically alter the behavior of a programming language's core behavior.
"The Art of the Meta-Object Protocol" says that meta-object programming
transforms a single language into a large area of related and interoperable
languages, each better suited for specific usages.  This is an excellent
summary.

Any serious programmer would be really well served to look into this topic,
either by learning more Lisp, playing with Moose (and its metaclasses, not just
Moose itself) and Class::MOP, or just by thinking about how his next common
problem might be made easier not with more code to combat the problem, but with
mode code to change the language to make the problem vanish.

I'm going to bed now, to dream of lambdas.

-- 
rjbs

From faber at linuxnj.com  Mon May 19 07:52:35 2008
From: faber at linuxnj.com (Faber J. Fedor)
Date: Mon, 19 May 2008 10:52:35 -0400
Subject: [ABE.pm] metaprogramming is way cool
In-Reply-To: <20080519032247.GC50766@knight.local>
References: <20080519032247.GC50766@knight.local>
Message-ID: <20080519145235.GA11196@neptune.faber.nom>

On 18/05/08 23:22 -0400, Ricardo SIGNES wrote:
> Any serious programmer would be really well served to look into this topic,
> either by learning more Lisp, playing with Moose (and its metaclasses, not just
> Moose itself) and Class::MOP, or just by thinking about how his next common
> problem might be made easier not with more code to combat the problem, but with
> mode code to change the language to make the problem vanish.

Sounds good, but do you have a practical, _easily understood_ example that
doesn't require learning a whole new paradigm, complicated program, or
deep module to get the idea across?

-- 
 
Regards,
 
Faber Fedor
President
Linux New Jersey, Inc.
908-320-0357
800-706-0701

http://www.linuxnj.com




From perl.abe at rjbs.manxome.org  Mon May 19 08:38:00 2008
From: perl.abe at rjbs.manxome.org (Ricardo SIGNES)
Date: Mon, 19 May 2008 11:38:00 -0400
Subject: [ABE.pm] metaprogramming is way cool
In-Reply-To: <20080519145235.GA11196@neptune.faber.nom>
References: <20080519032247.GC50766@knight.local>
	<20080519145235.GA11196@neptune.faber.nom>
Message-ID: <20080519153800.GA54687@68-29-125-228.area4.spcsdns.net>

* "Faber J. Fedor" <faber at linuxnj.com> [2008-05-19T10:52:35]
> On 18/05/08 23:22 -0400, Ricardo SIGNES wrote:
> > Any serious programmer would be really well served to look into this topic,
> > either by learning more Lisp, playing with Moose (and its metaclasses, not
> > just Moose itself) and Class::MOP, or just by thinking about how his next
> > common problem might be made easier not with more code to combat the
> > problem, but with mode code to change the language to make the problem
> > vanish.
> 
> Sounds good, but do you have a practical, _easily understood_ example that
> doesn't require learning a whole new paradigm, complicated program, or
> deep module to get the idea across?

The true value of programming the language is hard to convey trivially.  It's a
paradigm shift, so it basically will require, well, shifting your entire
perspective.

I'm not sure what the easiest route into this house of mirrors is.  A good
start is just to have this question forever in the back of your mind: "What if
instead of adding a new feature, I could make this feature act differently?"

This question applies to things other than programming languages!  When you use
your text editor, you can set options to change the way syntax highlighting
works, or indentation, or a number of other features.  For example, in Vim,
'dip' deletes the current paragraph, determined by some incredibly bizarre
options (see :help paragraph).  The idea is that you're saying d (delete) ip
(paragraph you're inside).  If you're writing something where a paragraph can't
be defined by the options, you might write a macro to replace 'dip' by doing
something more complex.  Of course, if you need to do things other than delete
that paragraph, you'll need to write a macro for each one of those.

What if instead you could write some code -- not set an option -- to redefine
what a paragraph is.  Now everything that expects to work on a "paragraph"
still works, but now it does what you want.  (Unfortunately, you can't do this
in Vim.  You can in Emacs, but ... well, then you're using Emacs!)

A lot of this is about saying, "I don't want to keep adding options to my
routine.  I want to change the meaning of the routine when called in some
contexts."

So, the simple way in, beyond the constant consideration of the question, is to
do more subclassing.  Think about lots of flavors of a routine instead of lots
of options to a routine.

And, c'mon.  Learn Lisp.  It'll make you even more popular with the ladies!

-- 
rjbs

From perl.abe at rjbs.manxome.org  Sun May 25 18:08:29 2008
From: perl.abe at rjbs.manxome.org (Ricardo SIGNES)
Date: Sun, 25 May 2008 21:08:29 -0400
Subject: [ABE.pm] the working geek
Message-ID: <20080526010829.GA38441@knight.local>


My friend and fellow Perl geek Andy Lester is working on a book about jobs for
geeks: hiring, working, interviewing, and so on.

He's got a blog for the book: http://theworkinggeek.com/

-- 
rjbs

From perl.abe at rjbs.manxome.org  Sat May 31 11:46:38 2008
From: perl.abe at rjbs.manxome.org (Ricardo SIGNES)
Date: Sat, 31 May 2008 14:46:38 -0400
Subject: [ABE.pm] "php sucks"
Message-ID: <20080531184638.GA33801@knight.local>


I thought this rant was amusing for a few of its special cases, like the string
"false":

  http://maurus.net/resources/programming-languages/php/

-- 
rjbs