The one and only response to that post suggested using the stub syntax to resolve missing class issues. Sadly, that does not work, because perl6 needs to see the stubbed class in full sometime later in the file.

So, the best option I’ve seen is to include the files containing needed classes and roles into files that need them (through either use or require). This requires knowing what to include (as including everything everywhere ruins the point), and I’ve started to try to grasp what’s going on in the rakudo codebase, specifically src/core, in terms of dependencies.

Here’s what I have so far. It’s right now just one, single script. This single script graphs the inheritance chain of all the classes and roles in src/core (what classes and roles “is” and “does”). You need the modules Term::ANSIColor, Term::ProgressBar, and IO::Capture::Simple (at this time pulled in, but apparently unused, by Term::ProgressBar). You also need ack and graphviz (which is not used in the script, but needed to process the resulting core.dot file).

Wanna see the graph for nom commit bf472b0, the latest as of this writing? Here you go (click to embiggen, clearly):

The arrows point towards what a particular box is inheriting, and the one or two white boxes mean that the class or role doesn’t exist within the src/core files. Yellow denotes classes, red denotes roles. And each box contains the name of the class/role, and the file it was found in and the line number of its definition.

This, however, doesn’t even begin to deal with all the dependencies abound in the src/core files. See all those abandoned colored blocks? Those aren’t inherited by anything in src/core, but they most certainly are utilized (e.g. the Pod::Config block, though not inherited, could easily be utilized as a variable type in the Pod code). I have a lot more work to do before I have a clear picture on how to separate CORE.setting into smaller pieces. (I might even need to utilize STD.pm6 or similar to do all the parsing I’ll eventually be doing!)

Just to finish off, Here are a couple more graphs of the same data. The first graph above was generated with GraphViz’s “dot”. This one (generated by their “twopi” program) I think looks hilarious:

And this picture was generated by GraphViz’s “fdp”. I think this one is the easiest to follow.

Happy viewing!

Note: this list may change depending on what masak does in the last couple days of his blogging month.

• Modify Adventure::Engine to implement game objects as objects
• Grammar/Actions for the game commands.
• NPCs!
• in-program descriptions
• Curses!

Let me explain:

OOP’d Objects

This I’ll most likely be doing first. While masak’s Adventure::Engine this year is great, it doesn’t use objects for the in-game objects. Instead, it uses hashes and lists to keep track of the features of various objects. I personally would like to group information about objects into, well, objects. I will, however, avoid becoming too class-happy like masak’s solution to an adventure game last year (making every game object its own class is just a wee bit class-happy in my opinion).

I’d accomplish this either by taking Adventure::Engine and having a local copy in the repo to modify, or by using augment and/or supercede in my own code, which would be a good opportunity to show off those rarely-used keywords.

The one problem I’d face is that it’s harder to have lists of objects when you’ve gone OOP. It’s (AFAICT) much easier to get a list of all the objects in the game in masak’s current Adventure::Engine. Oh well, I spy some binding will come into play \o/.

Grammar for commands

This is just a small little thing for me. I’ll have a Grammar and Actions turn the input on the commandline into something nicer to handle in the rest of the code.

NPC characters

Even though in any normal IF game I’d write, I’d avoid a story that needs any NPCs, I figured I’d implement NPCs and after August release it as, say, Adventure::Engine::NPC (depending).

Descriptions in Code

This is a non-item almost, I’ll just modify Adventure::Engine to have descriptions in-game.

Curses!

Because I want a status line at the top (like ye olde Infocom), why not (n)curses? If there is no existing Perl 6 module to interface with curses, I’ll write one (NativeCall GO!). I considered writing a module (if there is no existing curses module) that uses a laborious amount of print statements and \e characters, but I’ll try to interface with ncurses first.

Although I don’t know if I can do a month of blogging, I’ll try to fit it all within the month of August.

In NQP there are two directories where I’ll likely focus my attention first: ops/ and pmc/ . ops/ contains the opcode extensions for Parrot (IIUC), while pmc/ contains the custom Parrot PMCs for use in NQP. Both of these folders take advantage of a mechanism in Parrot that allows for a modification of the language of Parrot externally, without modifying Parrot itself or recompiling the entirety of it.

LLVM has no such mechanism. If I wanted to modify the language of LLVM like what ends up happening in Parrot, I’d not only have to modify the actual LLVM codebase, but instructions (opcodes) and types are two of the things that, when added, break LLVM’s bitcode format. Not good. To be fair, I could implement the instructions as intrinsics instead, but that still leaves types, and modifying LLVM from within still seems like a Bad Thing™.

My current theoretical solution is to replace the files in ops/ and pmc/ with hand-coded .ll offering up the same functionality. ops/ is easy enough, I can just implement those opcodes as regular ol’ LLVMIR functions. pmc/ is a bit trickier, because LLVMIR provides no classes or any such thing. But just because OOP isn’t built-in, doesn’t mean I can’t do OOP. I’d either use LLVMIR structures (with normal variables as “attributes” and pointers to functions as “methods”), or just create a mess of LLVMIR that in the end handles like objects, from the outside.

Questions I’ll certainly have to ask on the llvm-dev mailing list, for sure.

I have two last concerns with putting NQP on LLVM. The first is where the actual generation of PIR starts. I have yet to find the spot where PIR instructions are emitted, which makes me think that’s all handled in Parrot, with NQP just sending it a structure representing the NQP code it parsed. If this is the case, then that’d be interesting to port to LLVM. Since it’s best to let LLVM generate LLVMIR for me, I’d likely end up writing a C/++ “middleman” of sorts between the .nqp files of NQP and LLVM, where this C/++ middleman takes what NQP’s final output is and sends it through LLVM’s IR generators.

The final concern is where to begin coding so that it takes the least code before I can test the porting of NQP as it goes. I really wouldn’t feel good about doing the entire port without running tests frequently (or even once).

Questions I’ll certainly have to ask jnthn, for sure.

This sounds like a difficult, but fun, project. I hope it is.

Also, my last C++ program segfaults right at a for loop declaration, for no discernible reason.

So, I decided to take a look at Zavolaj, which allows you to use external libraries, such as GUI toolkits, in Perl 6. I’m feeling excited about using Zavolaj and Perl 6 instead of C++ now, there’s just one roadblock left for me.

Parrot. Rakudo on Parrot is slooow, so slow that the last version of Rakudo I successfully compiled locally is 2011.09-46-g1c2c2d4, the culprit being compiling CORE.setting. I’ve barely tried since that last time (only once or twice more), because I must not have the memory to compile it.

Now I could just continue using C++ and live with it, but that won’t be very enjoyable, at least for a while². So I wish to finally begin porting NQP to LLVM, so that I can ultimately have Rakudo run natively.

How to Port NQP

I see two ways of going about this task. The first is rewriting NQP, that is starting from scratch, and replacing all the PIR generating parts of the current NQP with LLVMIR generating parts.

Rewriting would seem to me to be the first choice, because it avoids the potential complexity of modifying parts of the existing code (bear in mind I haven’t examined NQP’s code deeply enough to know if this is more complex than a rewrite). A rewrite would also allow the option of not writing any of NQP in NQP, as long as the self-compiling part of the original NQP isn’t essential to its operation³.

The one problem is that the features of the NQP language aren’t well-documented. Except for a very helpful wikibooks page, I haven’t found much in the way of such documentation. Which would mean inspecting the original code and asking many, many question on #perl6 to get all the information needed.

Option two is rewriting the PIR generating parts of NQP to generate LLVMIR instead. Hopefuly this code resides in the .nqp files of NQP . After that, we have two choices. The first is that we could compile this LLVMIR-generating NQP to Parrot and update the bootstrap so we get .ll and .bc files instead of .pir and .pbc files, respectively. The other choice is to manually rewrite the .pir and .pbc files and then have a completely LLVM based NQP compiler.

This option could be either as simple as “just modify the nqp files in this directory and you’ll be targeting a new backend!” or as complex as “every single file needs modification. Good luck!”.

I hope to get started on this soon, so that I can use Perl 6 all the time .

1. Of course, I haven’t been coding C++ for long, so this could be just me being a beginner.
2. My general view on C++ is that every time I use C++, I appreciate Perl 6 more.
3. Maybe it’s a bootstrapped compiler because PIR isn’t very enjoyable . I’ll likely find out the reason very soon.

The purpose of this post, as suggested by the title, is for me to formally list what it is I plan to do Perl6-wise over the summer. As usual, I expect the projects I find interesting to change even before 13 June (my last day of school, the afternoon of which will be the start of my summer). Here’s a short list (in no particular order):

Port NQP to LLVM. The reason I’d like to do this is so that Rakudo, when it’s completely moved from PIR to NQP, will be able to compile to native machine code. I’m sure this task will be a lot harder than I could possibly imagine, but it’s worth a shot. I also imagine this idea would be more worked on once Rakudo is fully on NQP.

Get a working frotzlexity. Frotzlexity is my IF (interactive fiction) system for Perl 6. The first thing I plan on implementing is the English parser, just so I have an interface to the rest of the system as it’s coded. (This plan isn’t set in stone, though.)

Make a static website generator. Over the past couple of days I’ve been thinking of preparing a website to put up eventually. Since I can’t really write Perl 6 websites (the way you can with Perl 5), I’d rather go and make a static website. Of course, things like navigation and common design elements are easier when using a generator as opposed to all by hand. I haven’t quite decided if I’d help masak improve on psyde or just go and create my own generator (I’m leaning towards helping with psyde, just because starting up a second identical project doesn’t seem like a good idea to me).

Well, that’s what I’m currently planning on anyway. I can’t wait until I have enough time to work on Perl 6 things once again.

Just one note about Perl 6: I think it’s the best language ever. Recently I’ve toyed a bit with C and C++, and every time I play with one of those languages, I just appreciate Perl 6 more (and eventually wish I didn’t have to be using C/C++ in this situation). I think the community at #perl6 has really helped with my enjoyment of the language. The language and community have taught me a lot about programming in general, such as not using the very first idea for structuring your program (obvious, but a strong impulse if you’re not told this directly), and also how important it is to lay out your program, if for no other reason than unit tests.

Now, I haven’t been involved in Perl 6 (and #perl6) recently, and I’m hoping to change that. I sadly won’t be able to go full-scale into Perl 6 right now (we can thank the institution known as “school” ), but I do want to start getting more involved again before it’s too late.

So, for my third year of Perl6-ing, this is what I have planned:

Perl6 IF

This is my favorite idea. It’s to code an Interactive Fiction game in Perl 6. Then, once the game is made, I would separate the game from the IF world model, and releases the modules as a way of coding IF in Perl 6. Hopefully, if done right, such a setup could even transform your game into formats like ZCode (more detail on this in later posts). I’ll be using masak’s crypt as inspiration, and when I get started you can follow the progress at frotzlexity (on github).

“Native Perl 6″

I’ve had ideas for a while of creating an implementation of Perl 6 that compiles your Perl 6 into native machine code. My current form of the idea is to instead port NQP to LLVM, and then replace all the PIR-dependent bits in Rakudo with equivalent NQP bits (granted, removing all direct ties to Parrot in Rakudo is most likely easier said than done).

However, since my goal is to really have some form of Perl 6 running at a decent speed on my computer (at least when executing a P6 program), jnthn’s new serialization efforts in Rakudo may improve Rakudo enough to run decent on this very old thing of mine, and remove all my interest in this. We’ll see (my interest will be lost when the serialization makes CORE.setting compile in a decent amount of time (read: at all) on my 384MiB RAM machine ).

Modules in Perl 6

Somehow I always come back to modules in Perl 6. Maybe that’s because I’m still not 100% happy with how it all works, in code and (rarely) community. (This dislike is likely caused by my still-incomplete understanding of modules in Perl6 and, heck, Perl6 in general.) My current area of interest is in adding stuff to modules.perl6.org, in particular multiple pages (maybe 10 or so entries per page?), as well as the beginnings of some form of categorization. I can definitely see modules.perl6.org become something like CPAN and would like to start working towards that. Let’s see how the rest of #perl6 feels about this idea first though (as historically my thoughts on modules in Perl 6 haven’t been the greatest).

That’s my basic list of things I’m interested in (at this moment) for this third year of Perl 6 hacking. As always, I’ll have the appropriate amount of fun!

I want to stress that this is an opinion, not a statement of any sort of facts. Feel free to blog your rampant disapprovals of my opinions without fear you’re disapproving of any facts . I also stress this to make sure no one mistakes this as a statement of facts and runs around convinced that Perl 6 isn’t the successor to Perl 5 (that’s my opinion, I just don’t want it portrayed as fact unless the important decision-makers say I’m right).

https://gist.github.com/1201788  enjoy.

The Mu Proof

Don’t use CPAN. This is one point I’ll be fighting for the most. There is a commonly perceived split between Perl 6 and Perl 5, one I don’t personally believe will go away any time soon. I think that since there’s a separate perl6.org site for Perl 6, there should be a separate repository for Perl 6 modules. (Remember, I came to Perl learning Perl 6. I have never been a part of Perl 5 and I have always perceived that P6 is different enough from P5 that the are separate branches that should get confused and mix together (e.g., the same website for P6 and P5 is a no-no to me if clarity is a goal). There’s most likely bias here because of this fact.)

P6SSMPR. Yes, it’s that mouthful of an acronym again . I really want to provide a central place for all Perl 6 code. (The acronym stands for Perl 6 Snippets, Scripts, Modules, and Programs Repository.) modules.perl6.org is already a great site, so perhaps the idea of P6SSMPR can be applied to modules.perl6.org. Soon (within a day or two, hopefully) I will publish a document describing exactly what I mean when I think of P6SSMPR.

Clearly explain the module system. I’m a fan of betterexplained.com (as well as its other projects, including aha.betterexplained.com for sharing your own ideas and instacalc.com), so I really want to make the spec easy to understand. Of course, first I need to finish with explaining the type hierarchy (er, object inheritance chain?). Then, when I get started on explaining the module system (or whatever other part I want to explain), then I’ll merge the type hierarchy project into a more general spec explanation project. (I’ve even thought of a fourth category of pages, the “Tutorials”, to explain the Synopses, like the Exegeses explain the Apoclypses. But that’s another story.)

Anyway, I think it’s high time some of the higher numbered specs and less worked on parts of Perl 6 need to be fleshed out. Since I like the idea of messing with formalizing the module system, I figured I start there. And I figured I’d start by starting a discussion of this (at least one that I’ll be around for, apparently). Any ideas?

tl;dr — The universe has reportedly been turned upside down. Investigations are under way to determine why nobody noticed.

For the past couple days I’ve been taking notes on any mention of types and especially the hierarchy of types in Perl 6. You can see the work so far here. S01 contained no information, while S02 is proving to be quite the ordeal (as seen in this recent commit message). I knew this wasn’t going to be easy.

I state the goals for this project in the README (by the way, yes I do support the use of .pod6 as a valid extension), but to repeat them here, I want to do this for two reasons:

1. To help newcomers to Perl 6 understand the type system (one less confusing aspect of the language to be all alone on)
2. To reveal any potential inconsistencies in the synopses, at least what’s pertinent to types and the type hierarchy.

There it is! Hope you’ll follow the work, and snicker at the occasional witty note/commit message.

(Actually, moritz mentioned that there is no type hierarchy. In that case, is the P6 Standard Objects Inheritance Chain? Or maybe SCOI. No wait, definitely CISO. No,…)

TL;DR: You just missed a valuable cash opportunity in the blog post. Maybe next time.