A new Perl 6 major mode for emacs! (In Progress)

I’ve finally gotten fed up with cperl-mode, because it has now decided to throw lisp errors upon typing things like : or }, anything that would make use of its electric feature (which I couldn’t find how to turn off fast enough), so now I decided to take an earnest effort in creating my own perl6 major mode.


Right now this mode highlights "" and '' strings (because emacs provides string and comment highlighting for you; I have yet to set up comments), as well as sigilled variables with identifier names and also $_, $!, and $/. There’s also an indentation code that works well, but the rules that govern it will certainly need refinement over time as more specialized rules are discovered 🙂 .

If you use emacs, I invite you to try it out. The easiest way to use it is to open it in emacs, type M-x eval-buffer, and then open a Perl 6 file and type M-x p6-mode . The only part that will likely be bug-report-worthy* is going to be when the indentation code doesn’t work right. Issues with highlighting are not worthwhile to report until there’s quite a bit of highlighting support 🙂 .

I hope that in the coming weeks/months this will turn into a fully-functional Perl 6 major mode. It will also, after full Standard Perl 6 support is done, be extensible due to the highly malleable nature of Perl 6 parsing. (see the repo’s README for more on this)

Have the appropriate amount of fun!

*Lisp errors that throw you into a debugger and turn all of your modelines from saying (Fundamental) to [(Fundamental)] are of course another problem to report. If that happens, follow these steps (or else that [(Fundamental)] thing, called recursive edit mode, will possibly never go away until you restart emacs):

  1. Select the entire error (with your mouse or C-x h)
  2. Copy it (M-w)
  3. Exit the debugger (q)
  4. Paste in another buffer before you lose the error, *scratch* is a good choice (C-x b *scratch* C-y)
  5. Report the issue to https://github.com/lue/p6mode/issues, preferably with the error message you just copy-pasted 🙂 .
Posted in Progress Happened | Tagged , , , , | Leave a comment

The Rakudo Codebase: Visualized! (Partially)

Yesterday I stumbled upon this old perl6-compiler mailing list message which inspired me to actually try to split up the compilation of CORE.setting into smaller, saner pieces. I’ve started work on this already (so far having just modified the Makefile).

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!

Posted in Progress Happened, Research Department | Tagged , , , | Leave a comment

Making an IF game in August

After masak is done with his July of blogging and separates Adventure::Engine from his game, I’ll be taking it and during the month of August crafting a game with it, adding various improvements to the engine. Here’s a list of the general things I’ve planned so far.

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.


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.

Posted in Uncategorized | Leave a comment

NQP on LLVM: How to Port

I’ve since realized that writing a version of NQP on LLVM from scratch would be either quite a lot of work or, by taking as many of the .nqp files as I can from the exisiting NQP for a self-compiling compiler, essentialy the same as a porting of NQP. So, I’ve instead tried poking around in the NQP codebase to see where I’d be spending a lot of time doing such a port.

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.

Posted in Think Tank | Tagged , , , , | 3 Comments

Thoughts on starting NQP on LLVM

Lately I’ve been getting into certain project ideas (which I’ll specify later if they ever become anything) that would require a GUI of some kind. Although I’ve had some success learning SFML, I’m not too much a fan of C and C++. Not because they’re bad languages, but I feel I’m spending more time making sure I’ve specified types and type casts correctly and things like that instead of actually coding1.

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 while2. 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 operation3.

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.

Posted in Think Tank | Tagged , , , , , | 2 Comments

RD* Phasers Set to PRE

Well, I hope the PRE phaser fires before the START phaser, or else this post’s title will look silly.

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.

Posted in Think Tank | Tagged , , , , , , | Leave a comment

Two Years of Perl 6!

6 Feb 2010 marks the two year anniversary of my involvement in Perl 6. It’s the first day I started conversing on #perl6, and I joined the channel two days earlier. (Today also, coincidentally, is the same day I made a belated anniversary post last year.) It’s been a wonderful ride since the start, and it still isn’t over with yet.

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!

Posted in Uncategorized | Tagged , , , , , | Leave a comment