Pugs

On adopting the SQLite (non)license.

Aside from $job, I spent an entire day parsing the freshly announced release of Artistic License 2.0 beta 14, which feels much like Perl 6 -- in that it streamlined and formalized the mechanism, while staying true to the original idea.

As part of this, I engaged in an extremely long discussion with Allison, on her warning in #parrotsketch that inclusion of the Judy LGPL source tree in the Pugs repository will cause a licensing conflict with the Artistic license -- Inclusion of Artistic code under a LGPL project's tree is okay, but the converse is forbidden.

# Update: After some long followup discussions, it turns out it's not forbidden by law (Ruby does it with their regex.c), it's just considered extremely bad style by TPF; according to Allison, claiming the Artistic license applying to a compilation work also covers individual files in it, and it's legally dangerous -- though maybe not instantly criminal -- to have more strictly-licensed subparts in the repository tree, the way Ruby does it.

This has motivated me to move away from Pugs's current license, the now-outdated Artistic License 2.0 beta 5/GPL, as I don't want to restrict people doing anything with my compilation copyright.

All I really want to do is to let other people redistribute Pugs, in part or as a whole, without worrying anything about Pugs's license interferring with their redistribution policy. Conversely, I'd like to make use of third-party libraries without worrying about them disputing my copyright claims.

This is in resonance with the SQLite (non)license, which states:

The author disclaims copyright to this source code.  In place of
a legal notice, here is a blessing:

    May you do good and not evil.
    May you find forgiveness for yourself and forgive others.
    May you share freely, never taking more than you give.

Taking a page from this wonderful checkin from the extremely successful SQLite project, I'd like to begin the process on disclaiming my copyright over Pugs, as well as on my CPAN modules, perhaps registering this fact on the Creative Commons repository at the end of the process.

I'd like to take these steps:

• Move all third-party dependencies to a clearly marked contrib/ subtree.
• Disclaim my own copyright over the parts of the source files that makes up the pugs executable, adding to them per-file copyright-free declarations.
• Clearly mark that each aggregated modules under ext/ are under their own copyright owners and licenses.
• Implement the contributor policy, similar to the CC click-through screens, as part of the OSSF signup process on new commits for committers.

However, if people who have contributed to the src/ tree before feel uncomfortable about this change, that will necessitate a rewrite of those parts, so please voice your concerns.

Note that pretty much the same process needs to happen for Pugs relicense to Artistic 2, so this choice is simply that I think the SQLite non-licensing works better toward the goal of -Ofun. :-)

Chicago Hackathon.

Because Stevan can't make it to Tokyo last month, and I really want to work with Patrick/Chip/Allison in realspace (especially now that things are much smoother compared to last year's Toronto hackathon), I decided to put my boycott-against-entering-states aside, and give a talk at this year's YAPC::NA on Deploying Perl 6.

So far, we already have an amazing roundup of people for the post-conference Perl 6 hackathon (<< TimToady allison chip pmichaud stevan ingy gaal nothingmuch robkinyon obra miyagawa >>). So, if  you are going to YAPC::NA as well and wouldn't mind staying around the dorm for a few days, please sign up on the Wiki page, and we will make sure that you'll have something exciting to hack on. :-)

use v6-pugs;

The breakneck development speed in #perl6 means that this journal entry has been obsoleted ~5 times during its composition, so I'll delay the attempt to summarize what's happening for another day -- that is, after the CPAN release of Pugs::Compiler::Rule - a pure Perl 6 module, compiled to pure Perl 5, usable as a standalone CPAN module to provide Rule support for Perl 5 programs!

Instead, I'll just paste my talk proposal to EuroOSCON:

Title: Deploying Perl 6
Audience: Perl programmers and technical managers
Description:

With the advent of v6.pm, we can write "use v6-pugs;", start coding in Perl 6, and deploy it as part of a Perl 5 application, without any extra dependencies such as Haskell, Parrot, or even C compilers.

This tutorial will discuss typical deployment scenarios, emphasizing on the strength of Perl 6's deployment model:

• Automatic dependency analysis, so upgrading CPAN modules will no longer break programs mysteriously.
• Multiversioning, allowing the use of multiple versions of the same module on the system.
• Module and function interfaces that enables more robust and self-documenting programs.
• Cross-platform bytecode, resulting in faster loading time and cross-compilation opportunity to e.g. client-side JavaScript.

Moreover, we will present recipes for reusing Perl 5 modules in Perl 6 programs and vice versa.

Hackathon.il #1/2: Larry on IRC!

Too much interesting subprojects going on simultaneously,  plus I lost a half-formed journal due to accidental battery draining, so here is just some random sketches. (Also see my preliminary Hackathon-Plan for some starting points.)

11 months ago, I noted that getting Leo on IRC was the wisest course of action I made during Pugs development did till that Day -- now I think it's appropriate to express that sentiment again, as Larry is now on #perl6 and #parrot as TimToady!

In other news, I've been ghost-writing for Larry, committing various Synopses changes that cleared up much of the warnocked ambiguities raised on p6l and #perl6, which were blocking proper code generation to Perl 5 and Parrot:

• "package Foo; our $x; package Bar; $x" no longer leaks across package scopes, because switching packages in the middle of a file is disallowed -- "package Foo { our $x; package Bar { $x } }" is still fine, with the usual explicit lexical scoping semantics.
• Consequently, "sub foo" and "our sub foo" are now completely synonyms.
• "my $x = sub foo { ... }" is now legal, because named declaration forms are now expressions, just like their anonymous counterparts. Therefore the dreaded a/an anonymizer is gone for good -- just use "my $x = my Int sub foo { ... }".
• "my Dog $fido .= new" is fully explained -- $fido is bound to ::Dog in compile time as soon as it's declared. The ::Dog prototype object is both undefined and false (but has an .id and .isa(Dog)), and dispatches .new as any other Dog instance would.
• Consequently, "method meth { self ?? self.instance_method !! self.class_method }" becomes an idiom much like "sub meth { ref($_[0]) ? $_[0]->instance_method : $_[0]->class_method }" in Perl 5.
• Rules now assumes full parser combinator power, by allowing "/(\d+) { return $0.sqrt } /" to match against a number but captures its square root. They also live in the same namespace as methods.
• Consequently, "grammar Foo { method bar {...}; method baz {<bar>} }" is valid.
• use_ok() is now implementable and can import into the compiling lexical scope. It can be written as:
  

  macro use_ok ($module, *@import) {
      require $module :COMPILING<@import>;
      KEEP { return q:code { say "ok" } }
      UNDO { return q:code { say "not ok" } }
  }

• The above works because we cleared up the semantics of return inside KEEP/UNDO, made require capable of importing into lexical scopes, plus the capability of doing quasiquoting via CODE.
• "./pugs -O" can close the packages and disallow runtime introduction of new symbols, which affects GLOBAL as well. This allows early binding for almost everything, though the object code needs to be saved under a different extension, as the linker cannot handle linking of mixed optimised/unoptimised modules.
• "self.foo" now has context-hinted shorthands: "$.foo", "@.foo", "%.foo" etc. This works because "accessors" are dispatched exactly like methods now, so they are made into methods.
• Consequently, "@.foo(1,2,3)" means the same thing as "list self.foo(1,2,3)".

There's more -- much much more, as the sheer productivity of ten lambdamøøse are unstoppable (and nearly unbackloggable) -- but I'll split them into separate journal entries. :-)

Releng for 6.2.11 starts.

I slept for 16+ hours today, and woke up to find gaal had made a first cut at changelogging, and the freshly-returned putter starting to check in the new prelude -- an implementation of builtin functions in Perl 6.

Presently I'm working on the three remaining items blocking 6.2.11:

• Emit.PIR
• Pugs.Embed.Parrot
• Lexical export of multisubs

I'll continue working on release engineering with a full (and less sleepy) day tomorrow, as well as the day after if neccessary.  Stay tuned...

6.2.11 release planning.

I have $job to do on Wednesday throughout Friday, so the release will be postponed to this weekend. Some remaining TODOs before the releast:

• Deal with the fallout of lexical import, in particular the use_ok dilemma.
• Repair PIL1's PIR code generation with new lexpad nodes.
• Make sure that JavaScript and JSPerl5 compilation works out of the box.
• Perhaps the most daunting tasks of all: Changelogging.

As usual, there is no feature freeze window in Pugs development, so just hack on as usual. :-)

Release plans.

December saw a huge amount of Pugs refactoring and new subprojects formed in #perl6.  However, as I neglected journaling and release engineering for a month, many of them were not discussed outside the channel.  In order to remedy this, I'll do away with the old Day #" format, and make subprojects into categories to write about them separately.

The current plan is to push out 6.2.11 on early January following Parrot 0.4.1's release.  0.4.0's introduction of new lexical pads broke our Parrot compilation backend (that is a good thing -- I called for obliteration of the old lexical pads). Now that Leo implemented proper find_name and 1:N register-name mapping support, we can finally ship a version that targets Parrot for real.

6.28.0 should be released once our new PIL runcore is hooked to the parser/compiler subsystems.  The new runcore is equipped with full MetaClass, Roles and Container Type support from the fresh batch of Objects Spec, and is much more efficient than our current parse tree evaluator.

I plan to release it on early February, and make compiling to Perl 5 my main goal during OSDC::Israel.  I'm delighted to see that Larry will be presenting his compiling from Perl 5 work there; I look forward to work out OO and Perl5/6 issues with Larry and a host of lambdacamels in the Pugs Hackathon before the conference.