DC-Baltimore Perl Workshop 2014 - Call For Speakers

(As posted on dcbpw.org)

Attention Speakers! You are invited to submit talks for the 2014 DC-Baltimore Perl Workshop, which will be held on Saturday May 3, 2014, in Silver Spring, MD.

As in previous years, by default talks are 20-25 minutes, which we've found is a sweet spot for most topics. We get a great variety -- enough to get a dose of newness and not overwhelm. We also welcome proposals for more tutorial-style talks of around 50 minutes. We'll take the talks and build out a two-track sche…

DC-Baltimore Perl Workshop 2013 -- Next Week!

The 2nd Annual DC-Baltimore Perl Workshop is almost upon us! In case you haven't heard about it, we'll be having the Workshop in Baltimore this Saturday April 20, and have extra trainings on Sunday April 21.

We have room for more attendees -- even day-of registration is ok, in case you wake up Saturday morning and think to yourself "hey! I could be hanging out with awesome perl nerds right now! WHAT AM I THINKING?! Also where did I leave my hat?"


We have a great schedule of talks

DC-Baltimore Perl Workshop 2013 - Presenters Wanted!


On April 20, 2013 we'll be having another DC-Baltimore Perl Workshop! Like last year, this will be a 1-day, 2-track conference celebrating all things Perl! The venue is very close to the train station in Baltimore, so it should be pretty easy to get to.

Now is your chance to submit a talk -- we're looking for either something you think is fun or interesting or useful for our main track, and tutorials for our second track. If you're looking to get some experience giving a tech talk this is a great way to do it... and for the tutorials …

DC.pm September Meeting - Foundations of AJAX

At tomorrow's DC.pm meeting I'll be giving a talk similar to one I gave a long time ago at Phoenix.pm - a behind-the-scenes look at AJAX, targeting beginners. We'll discuss the history and cultural norms (aka Best Practices), as well as diving briefly into what is really going on (watching HTTP dumps). All wrapped up by "ok, now go use JQuery", though I suppose I shouldn't reveal the punchline.

Oh, and of course with Live Coding and using perl for the server-side bit :)

Come one come all!

DC.pm August 2011 Meeting - Devel::Peek

Last Tuesday was our monthly DC Perl Mongers meeting.

We dove right in, talking about how perl caches various values for a variable to be used in different contexts. So, for example, let's say you start off with a number, but then use it in string context, perl will cache both the string and the number. This can be shown using Devel::Peek like this:

main:001:0> use Devel::Peek
main:002:0> my $x = "34"
main:003:0> Dump($x)
SV = PV(0xb22d558) at 0xb237290
  REFCNT = 2
  PV = 0xb249458 "34"\0
  CUR = 2
  LEN = 4

I often use Devel::REPL at meetings so that we can interactively explore things as a group, which is what I'm doing here.

The first time we dump $x, you can see it has a "PV" which holds the string "34". But after we use it in a number context, adding 17 to it, you can see that the dump shows both the original string version, and a new "IV" containing the integer version:

main:004:0> $x + 17
main:005:0> Dump($x)
SV = PVIV(0xa0fe6b8) at 0xb237290
  REFCNT = 2
  IV = 34
  PV = 0xb249458 "34"\0
  CUR = 2
  LEN = 4

So this, as far as I know, is mainly an efficiency hack that perl does, the theory being that if you used it once in string context or number context or whatever, maybe you'll do it again.

Very quickly the question came up as to what happens when you change $x, and how does perl know what cached values to trust. Well that's where the 'FLAGS' part of the SV dump comes in. It shows which of the cached values are OK to use. So when we increment $x numerically:

main:006:0> $x++
main:007:0> Dump($x)
SV = PVIV(0xa0fe6b8) at 0xb237290
  REFCNT = 2
  IV = 35
  PV = 0xb249458 "34"\0
  CUR = 2
  LEN = 4

The flags have been trimmed down. I don't remember what all the flags mean, but you can look at perlguts or other docs for that :) . Notice that the string version of the original "34" is still there! Perl doesn't waste time erasing it. Instead, if string context is used again a new cached value will overwrite the existing one.

Well that was surely a good start to the meeting :)

(Cross-posted from thelackthereof.org)