use Perl

If this is on the CPAN, please let me know. I can't find it. If not, we probably need it at work

The W3C duration standard, derived from the ISO 8601 duration standard, allows one to specify durations in a format like PnYnMnDTnHnMnS (e.g.: "P1Y2MT2H", a duration of one year, two months and two hours). I can't find a proper parser for it and it turns out to have some tricky bits. Basically, I want to do this:

my $duration = DateTime::Duration::W3C->new_from_w3c("P1Y2MT2H");

Which would be more or less equivalent to:

my $duration = DateTime::Duration->new(
    years  => 1,
    months => 2,
    hours  => 2,
);

The only real difference would be (I think) adding string overloading to allow one to print the duration and have it come out in the proper format.

I can write this and try to handle the special cases I find documented (I'll be damned if I'm going to pay 130 Swiss Francs for the damned ISO 8601 standard), but I'd love to know if it's already out there.

Update: mostly fought with telnet options rather than making the editor not completely minimal, but it's running live. telnet to slowass.net 2003 using the stock 'xterm' and without GNU screen in the way and help me draw races, classes, creatures, objects, and locations. Read below for more and check out my terrible example screen shot. A humanoid should probably be 2/3rds or 3/4 as tall as the top part of the screen. A building or tree as tall as. Swords or whatever should be laying on the floor. Your line data gets saved as you go. I'll peek at it later.

---------

Yeah, I'm still screwing with this.

Back in the Netscape 3 days, I put a shitton of work into making a JavaScript/HTML client. It had a round robin queue of hidden frames with forms in them that got populated and force submitted to send user events back to the server, and the TCP connection server-pushed (remember server push?) JavaScript to animate other players moving around the map and to scroll the map and fill in rows and columns exposed during scroll.

Then I abandoned it for a long time but never forgot about it. Eventually Java came out, and I grabbed Java in a Nutshell as soon as I could and learned Java 1.2. I took my original crayon drawn graphics, http://weehours.net/graphics/ , and made the tile array larger. It was 5x3 before. The hard work of writing the MUD-side tools of crawling the graph based map and building a 3D array representation of it was done even if most of the MUD didn't map out. It could be fixed and made to map out and automatically crawled. Default tiles were assigned to rooms by scanning their descriptions and looking for keywords (trees, path, store, building, etc, etc). I even recruited a friend to help me and let him write piles of pointlessly disorganized Java. But he bailed.

One day, a guy hops on IRC and starts asking questions that sound suspiciously like he's trying to write an RPG style game. Turns out he is. I convince him that doing it from scratch is too much work (most MUDs don't get very far in the wheel reinvention process before they die) and tell him what I've got. We agree to work together. He does some brilliant work in Flash but then starts dabbling with audio/video, which is okay I suppose, then decides he wants to focus on that and get rid of the game. There was a language barrier too and we were having a hard time getting ideas to sync up. The legacy bits of the MUD got in the way, too. And Flash gets really slow when you have too many objects on the screen. I didn't have a machine fast enough to play the half-finished version that didn't have monsters or equipment on the screen yet.

We tried Processing but it wound up having cloned a lot of Flash's problems, with redrawing everything and having busy spinning threads in the background. That was fun but this fizzled.

Meanwhile, I'm back to work on the server side and eventually decide that rather than trying to make everything map out flat, I should just render the map from the perspective of the player. A graph is basically hyperdimensional. An arbitrary number of dimensions may be rendered down to two by throwing away (or folding together with sine and cosine) detail. Part of that process is picking a vantage point. A simple breadth first recursive crawl did the trick. But like rendering 4D down to 2D, things tend to move and shift in very disturbing ways as you move around them. Ahh, well. All part of the fun.

So I've got all of this infrastructure in place. I've paid artists and bribed them with Apple laptops and begged and pleaded for more art with no luck. I used to draw a bit but I'm badly out of practice. I'm having a hell of a time finding the right technology. I shouldn't have abandoned JavaScript. In the ten years or so since I did that version, JavaScript has matured. I've spent time ripping tiles out of NES games but almost everything you see on the screen on the NES is at least 4x4 mini-tiles put together and probably 4x8 or more. Trying to figure out how all of the little pieces fit is a huge task.

Is it silly of me to just go Kingdom of Loathing on this shit and start drawing stick figures?

And man, if I knew about Tektronix terminal emulation in the 90's when there were 80 people on this thing solid... and I introduced graphics then... EverQuest wouldn't have had a chance. Everyone would still be playing AfterHours.

The real bummer is that unless you install an X server on your PC or Mac, this is only usable on Unix and Unix-like systems that ship with the real X xterm.

I implemented a little line-of-sight algorithm that's simpler and faster than raycasting that I'm pretty happy about. I need to draw more art and I need to fill in more graphic data for rooms that don't have a keyword match. The dynamic crawler doesn't look for players, monsters and items yet, and I need to make it do that and send the details down the wire. I think it did before I reworked it to do dynamic crawling from the player's point of view. I know it used to send updates when someone in your field of view moves, but just for players, not for monsters. Even if I implement yet another GUI later, this is a good test of the MUD server side infrastructure.

I have an extremely simple paint program that runs in te Tektronix terminal. I guess I could fix that up a bit and invite people to come draw critters for me. Dunno, what do you people think? Talk to me.

Here's a snapshot of what it looks like right now: http://slowass.net/~scot/tmp/weehourstek.png

-scott

Parrot releases are harder to count because of their prolific release cycle.

Brian Wisti, In Which Brian Whinges About The Perl 5 Release Schedule

This is a trivial nitpick (read the rest of the article! It's very good!), but Parrot releases are very, very easy to count. The same goes for Rakudo releases.

The other day someone asked what Parrot might look like in a hundred years. I laughed and thought, "What would its version number be?" Then I realized that I can predict its version number in 100 years. Parrot 101.6 will be out, with Parrot 101.7 on the way.

For all of the lofty talk about "stability" and "maturity" and "predictability" which results in Perl 5 not getting released, the fact that I can predict the release date and version number of a piece of software one hundred years in the future says something about the stability, maturity, predictability, and reliability of a very different kind of development process.

(Oh, and Alias -- I can crash several so-called stable releases of Perl 5 with a one-liner the same way you crashed Parrot in December 2008 with a short program. If you want to make the argument that the 30 stable monthly releases of Parrot in a row don't actually exist because they had bugs, the two so-called stable releases of Perl 5 from the same time period don't exist either. Ontological debates are easy to lose.)

Jeff Atwood is the best tech blogger in the world, in my opinion. And his most recent post contains my nominee for the quote of the year:

Open source software only comes in one edition: awesome.

The Perl 6 design team met by phone on 27 May 2009. Larry, Allison, Patrick, Jerry, and chromatic attended.

Larry:

• changed the time function to return a Rat
• thinking about the traits that have been bothering Jonathan and others
• have some changes to check into the spec when I'm happy with them
• thinking about the primitives we use to define use
• breaks down into load and import
• thinking of establishing compile-time keywords for both concepts
• intended so that I can import from anything acting like a module -- an inlined role, for example
• otherwise trying to keep up with the flow of IRC

Allison:

• working on the Parrot book
• changed its focus to a small, 100-page PIR book from a monolithic Parrot book
• the intent is to get something out for YAPC and OSCON
• will send out a draft for review
• will merge my changes into the repo later this week

Patrick:

• released Rakudo #17 last week
• was easy again
• 875 more tests since #16, so we pass 68% of the spectest suite
• finished implementing the root_new opcode in Parrot
• cleans up a lot of the PMCProxy issues from moving Rakudo to its own HLL
• gained half of the speed we lost from the migration
• we'll get more back as we update more places that need it
• NQP never expected anything like that
• I have to rework some it and PCT
• haven't quite figured out how to do that
• refactoring use and import in Rakudo
• the current implementation doesn't work
• will hopefully match with what Larry's putting in the spec
• it seems like the logical way to do things
• updated Rakudo's ROADMAP in docs/ROADMAP
• gives us an idea of dependencies and next tasks
• may also help people understand what blocks features they want

Jerry:

• the bonding period has ended for GSoC
• time for students to start coding
• everyone on the Perl 6 and Parrot projects is ready

c:

• fixed some memory leaks in Parrot and Rakudo
• there are still some in Rakudo, but the web examples should be able to live longer
• did more profiling
• think NFG is important for Parrot in the near term
• have some documentation to write
• have been editing the Parrot book

Patrick:

• how's the command line for Rakudo coming?

Jerry:

• I expect to get back to that

Patrick:

• the "parens build captures" decision surprised me
• what's the rationale?
• I really liked "parens mean grouping"
• maybe I haven't reconfigured my worldview yet, but it feels messy

Larry:

• when used in an argument list, it has the same effect as a capture

Patrick:

• it even works when they're used as a term

Larry:

• they still mean that you have to look at what you're binding to and decide
• am I binding this to a scalar or to an array?
• (1, 2, 3) bound to an array...

Patrick:

• I'm going to have to think about that
• the zip operator in slice context....
• is this three or one positional arguments? zip($a,$b,$c)
• how many positional arguments are in this case? zip($a,$b,$c;$d)

Larry:

• one slice
• you wouldn't want to write that

Patrick:

• what in the arg list distinguishes the use of the semicolon versus the comma
• inside of an argument list we have to recognize a variety of syntactic things
• comma, semicolon, colon, array or hash sigil, named parameters
• seems like captures need more information than just positional
• they need to store metadata about positional arguments
• I like the syntactic stuff showing up in the argument list
• but I don't want to handle them in three different ways

Larry:

• I'll have to think about that

Patrick:

• haven't figured out how to deal with slice context either

Larry:

• might say that the presence of a semicolon implies the presence of other parens
• the comma implies...
• that might be more consistent binding for a top-level list

Patrick:

• I half expected that answer
• I can see the semicolon as just a lower precedence grouping operator

Larry:

• otherwise you have a semicolon that's just not there in every other argument list

Patrick:

• assuming that, the other commas form an argument list through the infix semicolon
• an array in there means Capture of Capture of Capture
• we were about to refactor List and Array in Rakudo anyway
• the question is "Do we really have a List type now?"
• Rakudo assumes that

Larry:

• if we can unify args list with List, that's probably healthy

Patrick:

• I'd really like that
• that makes things a lot cleaner
• infix comma and infix semis now just create arglists

Larry:

• or Lists
• if you define List as "something that has out of band metadata"

Patrick:

• any more decisions that you can make about that will help our implementation
• I probably won't get around to that this week

Larry:

• we make syntactic distinctions
• we know that this is an arg list
• we treat pairs as named arguments
• we don't do that if we know it's not an argument list
• it stays positional
• that's the only distinction between an arg list and a List
• purely syntactic

Patrick:

• to summarize
• zip($a, $b, $c) has three positional arguments
• zip($a, $b, $c; $d) has two, the first of which is itself a list/capture

Some times people come to me wanting to learn to program. Often we have this same discussion -- they want to learn PHP "because it's easy", and I want them to learn anything but. Seriously -- Java, JavaScript, Python, Ruby, C#, Haskell, Forth, Objective-C, Pike, Scheme... there are a million good languages to learn and PHP is not one. Oh, but it's easy!

There are two ways of thinking here. Either the world is a large, interesting place full of things you can learn. The stories have plots and twists and surprises that astonish and humble you. You have to grow to take it all in. Smart people play leading roles in the drama.

Or else everything is exactly as you expect it. There are no surprises. You can't get lost. No one is any smarter than you and even though you're a novice, no one really has any experience with what happens when things get complex because they just never do.

The first is the stuff of Hemmingway.

The second is preschool and old lady tour buses. It's for the proud who are afraid of their own weaknesses and risking not only defeat but fear any struggle. It's a cynical attitude that thinks little of the world and other humans. It's the wife who tells you what she wants for every birthday and anniversary. It's lost opportunity, low expectations, and narrow horizons.

Yes, the world is big and scary. Yes, it's full of surprises. Yes, smart people make you feel dumb, and there's a lot there for you to learn, at some pace. Don't pretend like there isn't. It all makes for a great story... a wonderful adventure. Don't fear it.

Logo, the old programming language for "turtle graphics", where you steer and move a line drawing cursor, is an old Lisp dialect but without all of the parenthesis. BASIC on the other hand is pointlessly limited for anything but the underpowered shared computer it was written for at Dartmouth. Would you continue to write BASIC when Logo is just as easy? Do you want your confined space to be that much smaller than necessary? Likewise, learning Ruby is no harder than learning PHP but far, far more rewarding. I'm not dissing Perl here; Perl does have a longer learning curve than most languages.

PHP does not make programming simpler. It just pretends that programming is simpler than it is, just as a tour bus doesn't make Italy more easy to experience, it just lets you pretend that you're experiencing Italy.

-scott

Yesterday I had to write some code that goes through ~700.000 datasets (seperated into 6 tables) and denormalise them (see the yet unwritten Part II). As we're using DBIx::Class, I first used it. Even though I avoided some in/deflators and used columns to only get the stuff I needed, the process took ages (~50 items per second or aprox 4 hours for the whole job). Well, 4 hours might be bearable, but this was only the Swiss dataset. The German one, which we have to tackle soon, is at least 10 times as big, and 40 hours is just a way too long runtime.

So I rewrote the core of the programm using raw DBI calls (I had several flashbacks to the 90's :-) The results were quite astounding, as I was now getting 500 items a second. 10 times faster!

And that was before koki told me to set work_mem to a bigger value. I choose 30MB, and got another speedup to ~900 items per second. Sweet!

Of course, it's completely unfair to compare DBI with DBIx::Class performance wise, because DBIx::Class is so much nicer to work with. But if speed is an issue, dropping back to raw DBI is the way to go.

Realizing quality improvement through test driven development: results and experiences of four industrial teams analyzes the TDD experiences of 4 teams at IBM and Microsoft. Nothing surprising here to those who have already experimented with test-driven development (pre-release defect density decrease of 40%-90% combined with a 15–35% increase in initial development time), but it is good to have some hard numbers on TDD rather than relying solely on anecdotes and hearsay.

If I were a festival promotor (but I'm not) these are the bands I'd like to see, because they did impressive things (more than 1 song) in the last year:

• School of Seven Bells
• Friendly Fires
• Fever Ray
• Juana Molina

and for the dance tent:

• Pogo
• Deadmau5

However, it doesn't look very likely to see them all (or even,, half of them) in a single event.