Parrot

The Perl 6 design team met by phone on 16 June 2010. Larry, Allison, Patrick, Will, and chromatic attended. Larry: documented TOP (again), and explained how parsing is initiated and how it actually worksseries operator (...) now picks a monotonic ... [More] function when using single characters as endpointsSTD can now catch duplicates involving protos as well as onlysSTD no longer advises removal of parens on spaceless sub() declarationmostly advised sorear and pmichaudStefan is finishing the boostrap of the STD parseralso working on adding a parallel NFA and DFA engineno, he doesn't want to generate all the states in advanceit works faster lazily Allison: working on chroot environments with something more secure than chrootrelevant to building Parrot packageslooking at some bugs for Will Patrick: Rakudo developers decided not to make extra special effort to make a June release of Rakudo Starthe calendar works against usthe new date for the release is July 29we're I comfortable with hitting that targetwe won't be happy with the results of moving heaven and earth to release in Junethere are lots of advantagesone disadvantage is not having Rakudo Star at YAPC::NAone big advantage is using the supported Parrot 2.6 release as the basisI'll write a post outlining the plan in the next couple of daysotherwise working on lists and interators in Perl 6 and Rakudoafter deciding to make iterators immutable, Larry and I realized that solves many problemseverything works out as plain as day after thatvery happy with that designthe incorrect assumptions of the old model were pervasivereplacing the old pieces is taking a while, which is no surprisethis approach feels right thoughthe new branch does things no previous version could doslices work much better, for examplemetaoperators work properlymap is lazyslurpy arguments in lists are lazy by defaultno weird binding or action at a distance problemsplenty of changes to Associative and Positional rolesthose are now super clean and may be lazymore features work~30 failing tests (not test files, just tests) now, ~500 last nightmost of the current failures are minorwill try to merge the branch before the releasereplacing lots of ugly code with fewer lines of elegant codeJonathan and others have worked on lots of other piecesadding plenty of new featureslooking forward to tomorrow's release c: editing the Rakudo bookmoving the Rakudo release date may let us have a printed book available about the same timedepends on how much there is left to write [Less]

The Perl 6 design team met by phone on 09 June 2010. Larry, Allison, Patrick, and chromatic attended. Larry: not much spec change this weekfigured out a syntax for a regex block to return more than one cursorbased on gather/take in STD hacking ... [More] , continued to assist Stefan O'Rear in getting STD bootstrapped via vivnow that it's bootstrapped, we're refactoring things that make sense nowwe're now starting to move bits of Cursor code from Perl 5 into Perl 6refactoring the grammar for sanity of designstarted upgrading STD to normal Perl 6 syntax where it previously catered to gimme5's limitationsfor example, switched STD's old .<_from> and .<_pos> hash lookups to using .from and .pos accessorsstarted the prep work for moving EXPR out of STD to make it generally available to any grammar wanting operator precedencein STD parsing, made Perl 5 $< detection have a longer token to avoid confusion with match variablesSTD no longer attempts two-terms detection on infix_circumfix_meta_operator STD now parses >>R~<< correctly, or at least dwimmilySTD doesn't complain about P5isms in printf formats like "%{$count}s" STD was parsing /m and /s with the opposite semantics termish now localizes $*MULTINESS in its scope so that inner declarations aren't accidentally multifiedSTD now carps about package Foo; as a Perl 5 construct Allison: talked to Chris Shiflett, a PHP developer, on someone from the PHP community to sit on the Parrot boardwill be in the US for a few weeks Patrick: working on list simplificationhad a couple of breakthrough ideas on Mondayworking on the implementation nowworked out inversion lists for character class matching in regexeswill make them faster, especially with long ranges of character classesfixed a half-dozen tickets in RTfixed Rakudo hash constructorsfixed an intermittent bug with colon-pair signaturestwo possible parses exist in STD, but we removed an unneeded one in Rakudofixed a bug with Parrot's exit opcodeNQP and PAST needed an update not to cheat with PASM constantsI fixed that tooVasily added multisub and multimethod support to NQP, that was a big plusfixed the ** quantifier in regexes to understand surrounding whitespaceregex engine tried to match beyond the end of a string, so I added guards for thatwill work on lists furiously before the next releaseI don't think it'll take longclosures are next, hope to have those in place by the weekend c: released a new version of Pod::PseudoPod::LaTeX to support the various books in progress [Less]

I've added a lot of functionality to PLA in the last few days, including a large boost to the test suite this evening. Since Kakapo doesn't have a release that targets Parrot 2.3.0, I decided to refocus my efforts on Parrot 2.6.0. However, with all ... [More] the changes in Parrot since 2.3.0 came out, the upgrade path was much harder than I anticipated. Luckily I have some superstars like darbelo and NotFound on my side, otherwise I would still be fighting with things.After talking to darbelo I've decided PLA is not going to attempt to track supported releases, at least not for normal development. It's too much of a pain in the ass, and nobody else is doing it. Sure it's best practice, but it's the kind of thing the whole ecosystem really needs to do together. If the HLL compiler is tracking Parrot HEAD because of a desperate need of new features and improved performance, then it doesn't make any sense for libraries not to be keeping up pace.Darbelo made one particularly good point:If we track HEAD the we'll run on 2.6 when it's released. We branch on the release day and do whatever 'release engineering' we need to do on the branch and tag a release when we're done.That's it, in a nutshell: If we track trunk closely enough, we will always be ready with a release following Parrot's release. Spend a few days to prepare the necessary accouterments, then cut a tag and continue on with normal development. Our releases can be tied to Parrot's supported releases, but our ongoing development will target trunk as closely as possible. I don't anticipate that we will want to cut a PLA release every time Parrot does, but if we follow a 4-month schedule and follow supported releases that should be just fine. At least, fine for now.PLA is going to track Parrot trunk and hopefully be prepared to cut a release following Parrot 2.6.0. That gives us about 4 weeks to get all our ducks in a row (and our Kakapos too!). [Less]

In my work on Timers, I've concluded that the scheduler really is the right place for scheduling things (who would have guessed?). How the scheduler *should* work is described in pdd25. How the scheduler actually works is a bit different, and how I want the scheduler to work to implement green threads is a bit different from that... read more

Last night I got back to work on Parrot-Linear-Algebra, my matrix package for Parrot. I'm really starting to get happy with the functionality it provides and am looking to start moving the project to the next level of functionality and usability.I ... [More] hadn't touched it in a while, for a variety of reasons. Austing Hastings has been very busy with other projects and hasn't cut an "official" release of Kakapo that works with the last supported Parrot release, 2.3. I've applied some hotfixes that make Kakapo build and pass tests on 2.3, but that's not quite good enough. When I make a PLA release I don't want "clone the Kakapo repository from Gitorious" in the instructions, because then the instructions get out of date when Kakapo is updated to be incompatible. What I want is to say "Download Kakapo version X from this URL", which will be invariant. Last night I added some prototype new features to the NumMatrix2D PMC, the basic numeric matrix type. I'm going to mirror the majority of those changes to the two other general-purpose types; ComplexMatrix2D and PMCMatrix2D. I added methods to do basic elementary row operations (swap two rows, add a multiple of one row to another, and multiply the contents of a row by a non-zero constant), and used those operations to put together an example program to calculate both the Row Echelon and Reduced Row Echelon forms of a matrix. Those methods, combined with block manipulation methods I added previously and the new GEMM method I added last night as well, create a basis for us to create a comprehensive library of linear algebra routines.But that brings me to my next concern: How to implement the remainder of the fundamental algorithms a linear algebra pack is going to want to provide? Obviously I would love to wrap the LAPACK library up and call the routines it provides directly. LAPACK provides a huge number of routines for doing things like singular value decomposition, QR, LU, and other types of decomposition, solving the eigen probem, solving systems of equations in two variables, etc. In fact, LAPACK provides almost all of the functionality I would want PLA to have in the next few months.The problem, however, is that LAPACK is not nearly as accessible from C code as I would like. In fact, there is no "standard" for C-bindings to the library, and several lame attempts are available that tend to be incompatible with each other. The reference version, and only reliably-available version, of LAPACK is written in FORTRAN. The standard CLAPACK library is just a machine-lead translation of the FORTRAN sourcecode, with a few points in the code needing to be manually tweaked after conversion. It has a few problems, including the fact that every single function parameter (even basic ints and floats) must be passed by reference. The ATLAS library, which PLA currently prefers to provide BLAS bindings, provides some LAPACK C bindings of it's own, but only a very very small subset of all LAPACK functions are provided, and the ones it does have hardly support all the operations PLA is going to want to provide.CLAPACK, being more or less the standard could be made to work, except that it doesn't come as any sort of user-friendly package. There are no CLAPACK packages for Debian (Ubuntu) or RedHat that I have seen, and that raises the barrier to entry significantly, something that I want to avoid.I could use the LAPACK library directly, and twist my code to match the FORTRAN calling conventions and data alignments. That's not unthinkable, though it would require some more work on the part of PLA developers than any other solution.I could skip LAPACK entirely, and instead rely on something like GSL with proper C bindings built-in. GSL does provide several important matrix operations and decompositions, though I would need to do more research into the capabilities of that library.. What I don't want is to lose focus and have this project grow to try and become a general wrapper for all of GSL. I want PLA to stay focused on Linear Algebra only. We could maybe create sister projects to encapsulate more of the GSL functionality and use PLA under the hood to implement the basic data structures, of course.Maybe we will get lucky, and the new NCI system will have support for calling FORTRAN routines from shared libraries. I don't think we can just anticipate this kind of functionality, at least not during the GSoC program. A "nuclear" option, perhaps, would be to not rely on any external library for these things and instead brew up all the basics myself. I'm not against such work per se, but it would be a huge investment in time and the case cannot be made that it's the best use of my limited development time. I did put together a Gauss-Jordan elimination routine last night, it wouldn't be too too much effort to put together a generalized QR decomposition algorithm and a singular-value decomposition algorithm, followed by routines to calculate eigenvalues, eigenvectors, and matrix inverses from those things. If PLA had a larger team of active developers who wanted to participate in this kind of work it would be an easier decision to make, but if it's primarily me and a handful of occasional-contributors, this really isn't a doable task.My plan for PLA in the near future is this: After the 2.6 release I want to push for a stable release of Kakapo, and then using that I want to cut a release of PLA. From that point forward, PLA will target the 2.6 version of Parrot at least until 2.9 and maybe later. The first release of PLA is going to provide three basic matrix types: A 2D matrix of floats, a 2D matrix of complex numbers, and a 2D matrix of PMCs. These three matrix types will have a large base of common functionality and each type will have some additional functionality too, as required by that type. Everything provided will be well-tested (including error cases, which I haven't exercised nearly enough so far) and some example programs will be provided in both PIR and NQP.There are a few projects I am envisioning to start in the future that will rely on PLA, so I really am hoping to create a nice, stable, functional release within the next few months. I'll post more information about any other projects as they arise. [Less]

The Perl 6 design team met by phone on 02 June 2010. Larry, Allison, Patrick, Will, and chromatic attended. Larry: mostly, I supported sorear in bootstrapping STD to use viv instead of gimme5 his stage 2 and stage 3 now output identical Perl 5 ... [More] versions of STDproduces a huge amount of warningsappears to require Perl 5.12 at the momentworking on both of thoseS03 refines hyper dwimminess to be more like APL, with modular semanticsS02 refines Blobs to simply be immutable Bufs, with similar generic characteristicsS02 now describes native blob typesimplemented post-declaration checks for BEGIN and use, since those can't wait for end of fileSTD no longer loses existing bindings when we go to a sublanguageSTD now uses $*GOAL variable only as informative, never as a "stopper"instead, we create a <stopper> rule for $*GOAL if necessarycan check for that only, instead of that or $*GOAL answering lots of questions on how STD and viv work besides that Allison: did a lot of research on graph color algorithms for register usage algorithmswill finish my finals on Monday Will: trying to herd the discussion of dynop librariesa recent branch to close an old ticket broke a lot of assumptionssome bugs have become more visible because of these changeshope to get that cleaned up this week Allison: I liked your suggestion of bringing back the getstderr and related opcodes Will: trying to resurrect Partclstuck on a TT #389 closing issuenot sure how to fix that, the way things are now Patrick: working on the iterator and list designbrainstorming the implementationwill implement somethine one way or another this weekpeople keep implementing workarounds for the current systemthey'll bite us eventuallyMoritz and I worked on making the regex engine returning real Perl 6 objectsthat mostly worksexposes some places where lists don't work exactly rightthe workarounds there made me replan the list and iterator implementationanswered some questions onlineJonathan added a better backtrace algorithm for Rakudoreports Perl 6 source lines instead of PIR linesI'll review his codethink I can borrow it for NQP for all HLLsJonathan reports that it was a lot easier in NQP than PIR c: trying to answer a few Parrot design questionslooking at the continuation of design from Perl 1 - 4 to Perl 5 and Perl 6hope to have coding time soon [Less]

Progress this week was not bad. To recap, here’s what I got done this week: Handle exit/unhandled exceptions.Whenever the exit opcode is found, Parrot will throw a CONTROL_EXIT exception which will propogate up the exception handler stack to the ... [More] first exception handler which can handle it. In most cases, this will be the C exception handler created before entering the runloop in the function runops (see src/call/ops.c), and trigger the interpreter cleanup routines. Exiting in this manner will not allow the instruments to be finalized. So by inserting another C exception handler after this point, such exceptions can be caught and the runloop can exit normally, allowing the instruments to be finalized. As a plus point, since C handlers act as a catchall for exceptions, any unhandled exceptions will also be caught, again, allowing the instruments to be finalized.To this end, I also modified the Parrot_runloop struct (see include/parrot/call.h) and the appropriate routines to have a reference to the thrown exception, allowing the C exception handler to know what was thrown. Cleanup the hook tables on destroyThis was listed as todo in the source, so I did it by first creating a new function to delete a list and then calling that function for each hook list. Update the op callback interface.Previously, on calling the callback, 3 parameters were passed. The parameters were, the current relative PC (Program Counter), a ResizablePMCArray containing the op number and its arguments, and the Instrument object itself. This wasn’t very convenient, as to get the information about the op, one has to get the OpLib instance and then obtain the OpCode instance for the op in question.So I reworked it instead, creating an InstrumentOp dynpmc which conveniently allows looking up most of the information required from it, along with the file, line and namespace the op is in (accuracy of this is subject to the core’s ability to obtain the info). Getting the file, line and namespace wasn’t particularly hard. With the initial guidance from cotto, I managed to trace it all the way to Parrot_Context_get_info (see src/sub.c), which conveniently is already marked PARROT_EXPORT and provides the information I wanted in the form of the Parrot_Context_info struct. Additionally, in the process of fleshing out the InstrumentOp dynpmc, I also removed a todo item with regards to the special ops which have variable arguments (set_args_pc, get_results_pc, get_params_pc, set_returns_pc), which up until then, were simply ignored. Hooks on dynops.This was listed as todo in runtime/parrot/library/Instrument/Probe.nqp previously. In the process of designing tests for the class Instrument::Probe, I got sidetracked into revisiting this todo. Now, upon detection of any dynop libraries, all probes that have pending op hooks are disabled and reenabled, and in the process attaching hooks to the relevant dynop if found. The tests for Probe.nqp and EventLibrary.nqp are still pending, as I’m looking at whether I can improve on the Instrument::Probe and Instrument::Event interface more, namely adding methods to get the current state of the objects. With reference to the previous post, I did not manage to complete the following two tasks: Adding tests for Probe.nqp and EventLibrary.nqp New events (sub call, class events, exception events) I hope to be able to complete these two tasks by Thursday (June 24th). For this week, I would like to complete the following: Add events for GC.This is mostly replacing the entries of interp->gc_sys with appropriate stub methods that will raise an event. Hopefully it shouldn’t take that long (Prays for no crashes, since raising the event will invoke the GC itself, methinks). Dynamically remap dynops (Internally, nothing to do with the dynop_mapping branch).To date, I have not been able to successfully run tracer.nqp on perl6.pbc, at least as far as getting to the REPL prompt. This is mostly due to dynops (I think), since dynops used the perl6.pbc are dependent on the order that the dynop libraries are loaded during the compilation of that PBC. I have somewhat of an idea on how to approach this, but have not probed enough to know more details of it (namely in what order were the dynop libraries loaded, and how to remap the dynops to the op table). Hopefully it will be successful. Prepare to instrument the PMC Vtables. After discussing with cotto, it would be better if I do this first while waiting for the dynop_mapping branch to merge. [Less]

The Perl 6 design team met by phone on 26 May 2010. Larry, Allison, Patrick, Will, and chromatic attended. Larry: :() syntax is now always signaturewe now use foofix:[...] as the general op form instead of foofix:(...) refactored the sematics of ... [More] :nth and :x :nth() now only ever takes a monotonically increasing listS03 now explains how "not-raising" works on != and ne it now basically matches the intuitions of an English speaker via HOP definition of negate metaopSTD sometimes didn't require semi between statementsstatement modifiers are expression terminators but not valid statement terminatorsan unexpected statement modifier word like if could terminate one statement and start anotherfixed up backslashes in character classes to allow \s etc and reject \u etcSTD was accidentally using the same lexpad for different multisCursor now treats :() on name extension as a signature always, never as a categoricalwe shouldn't introduce the stopper for circumfix until we're in the circumfix, or we can't use the same char on both endsplaceholder messages error messages are now much more informative and correctwe now disallow use of placeholder after same variable has been used as a non-placeholder, even for an outer referencerenamed add_macro (which it doesn't) to add_categorical (which it does)participating frequently in discussions on semantics both on irc and p6lworking closely with sorear++ as he brings viv closer to bootstrapping, yay!soon can bootstrap past gimme5 Allison: worked on Pynie this week in my limited spare timeone goal is to generate the parser directly from the Python grammarwrote a small, lightweight PEG parser which generates a match tree from the Python 3 grammarcan generate a lexer directlyright now it creates a parse treelooks similar to the match nodes of NQP-rxdumps out a tree to the PIR parserworking on PaFo elections for next year, but trying to delegate thosewill have more time after June 7 Will: working on Perl 6 advent testsmany more people are doing more work than meliasing with Rakudo folks for any important Parrot bugs before the Rakudo Star releasemy current direction there is "don't break anything" Patrick: sorear added hash flattening to NQPlots of work on closures in PAST and NQPthey properly clonefixes some lexical problemsneed to get that to work in Rakudothat's tougher; Rakudo has to wrap Parrot subswrapper object needs cloning as well, along with its attributeswe'll add a new PAST node type to helpthat node understands contextsessentially a way to add void context optimizations to your ASTthat solves many problems in Rakudo beyond closuresadded a setting into NQP along with its test suitenot automatically loaded, but availablecontains standard hash and array methodsParrot's ops2c project uses thoseother people can update and enhance that setting as necessaryNQP also has the ability to parse type namesNQP doesn't do anything with them yeteventually they'll allow the use of multiscleaning up some NQP bugs regarding lexicals and package storage of subsBruce Keeler enabled variable interpolations in regexesworking on some refactorings to simplify that approachworks in NQP and Rakudo nowthat's a feature we've never had beforeRakudo's REPL now works better, thanks to sorearHLLCompiler now written more in NQP as part of thatNQP now can do eval NQP remembers lexicals in interactive mode nowadding that to Rakudo is more complexworking on thatpleased with the progress on #perl6 c: reviewing long term plans for GC and Loritoshould have more time free soon [Less]

As many of you know, last summer we announced that we would be releasing a "usable release of Rakudo Perl 6" to be called "Rakudo Star" in the second quarter of 2010. We later refined our target release date to be April 2010.Until March of this year ... [More] we were well on track to meet the April 2010 release date, but then I had an family medical emergency that took me away from Perl 6 development. As a result of my situation, the Rakudo and Perl 6 team met online in early March and decided that an April release date would be unrealistic, and we instead focused our efforts on trying to make a June release for Rakudo Star, to keep with our original "second quarter 2010" goal.Ultimately it ended up being twelve weeks before I was able to return to active Perl 6 development (i.e., late May). During my absence the others on the Rakudo and Perl 6 team made incredible progress on Rakudo Perl 6; I think their progress shows that a truly capable (and growing) team of developers has coalesced around Rakudo Perl. Thanks to their efforts, as of late May the compiler had nearly everything we identified as critical for Rakudo Star in the ROADMAP, with only a few key features blocking on my personal participation. We therefore felt we still had a good likelihood of meeting the June 2010 target, and continued to work with that goal in mind.As part of planning this week's Parrot and Rakudo releases, we all met online to solidify our plans for the Rakudo Star release. After much discussion, we decided that although we could likely make some sort of Rakudo Star release in June, there was too much risk that releasing in June would fall well short of our vision of what we want Rakudo Star to be.Therefore, we've decided to to let the release date slip one more month and release Rakudo Star not later than July 29, 2010. We are firmly committed to the July 29 date; whatever we have available then, that's what we release. I know that another delay will be frustrating to many (it is very frustrating to me), and that some will undoubtedly cite this delay as yet more "evidence" that there will never be a release of Perl 6. But given the circumstances, I think we feel that we promote Perl 6 better by moving the release date by a month than we would by releasing something less than our vision. For those who might claim that we should "release early", we are still continuing to make regular monthly compiler releases. The most recent release (#30, "Kiev") comes with a lot of improvements over previous releases, and I truly expect the next release (#31, "Atlanta") to continue the trend. As always, we continue to invite people to try out the compiler releases and to visit the Perl 6 website to see what Perl 6 is already doing today.Finally, on a personal note, my wife and I sincerely appreciate the ongoing support, prayers, and understanding we have received from the Perl community (and especially the Rakudo and Perl 6 teams) during these difficult times. While my wife is still not "out of the woods" yet, things are far better now than they were in the Spring, and we continue to work towards and pray for her full recovery.More details about the Rakudo Star release will be forthcoming over the next couple of weeks.Pm [Less]

Parrot user kthakore sent a very interesting email to the Parrot developers list this week to criticize the current deprecation policy. After taking some time off from development, he returned to find that his extension no longer built on Parrot HEAD ... [More] and he couldn't quite figure out why. There was a deprecation notice for the feature that changed, but the notice was so vaguely worded and so short on explanation that it offered very little help to the beleaguered extension developer.When we're talking about code, there are only a handful of things that we really need to worry about: utility, performance, security, stability and maintainability. Well-written code, for the most part, can satisfy all these requirements. Sometimes trade-offs are made, such as trading a certain amount of maintainability to optimize for performance, but in those cases some well-placed comments can help alleviate or minimize any regressions. Code, while technical and deep, is often pretty easy: we follow rules and policies, make changes, measure results, wash, rinse, repeat.Not so easy are the softer sides of open source software: the people. People come in varieties: core developers, extension developers, testers, documenters, end-users and well-wishers of varying levels of technical competency. Keeping all these groups of people working together nicely and happily can be quite a difficult challenge, and there is likely no way for all groups to be 100% happy 100% of the time. The tradeoffs here are harder to understand, harder to manage, and a misstep can have huge negative consequences for the project.I've long been a detractor of Parrot's current deprecation policy: It's too rigid, too narrow, and doesn't really do anything to help the people who need helping. It also doesn't really take into account Parrot's current stage in the development life cycle. Parrot, as I've mentioned on occasion, has plenty of warts and has suffered many growing pains. It is folly to think that we should be making blanket guarantees about what will or will not be present in various releases, or how quickly we can or cannot make changes.When there's a problem or a bug or a misfeature, people want those things fixed quickly. A good example of this were the PCC refactors a few months ago. Even though those refactors created some backwards-incompatible behavior our users (who the deprecation policy was at least nominally designed to protect) were trying to rush them through. Rakudo developers specifically were blocking on the PCC improvements and having to wait for months and months would have been bad for them. The PCC refactors were high priority and high need.The deprecation of several core ops and their conversion to dynops recently is an example from the other end of the spectrum (and the source of kthatkore's frustration). While we followed the letter of the deprecation policy, these things didn't need to be removed with haste and created a bit of hassle for users who weren't expecting it. I'm not saying they shouldn't have been removed (I'm always a proponent of removing cruft), but it does expose some short-comings of our deprecation policy and process.What we have is a series of conflicting motivations, even for individual groups. Consider:Core Developers: Core developers want to remove bad features, want not to maintain bad features, want to add new good features and want to create the best software for the users. Developers need to work on fun new features, but also need their work to be used and appreciated. Take away either of those pieces, and many volunteer developers will simply walk away. Moving too quickly alienates the users and creates a huge disconnect between what the developers are developing and what the users are actually using. Moving too slowly is boring and developers start to leave for greener pastures.Extension Developers: Want to add new extensions to the Parrot ecosystem for the benefit of users, but have to deal with binary compatibility at the C level which changes much more frequently than the "normal" user-visible interfaces like PIR. Parrot has a lousy extension API right now, so necessary improvements there require extension developers to stay up-to-date with current core development. At the same time, all sorts of other changes break things in new versions, even when necessary features are fixed. Users: For stability, it's good for users not to upgrade. To fix bugs and get new features, it's good t upgrade. Upgrading brings rewards but also hassles:  Core features disappear, new bugs are added, and extensions are broken by binary incompatibilities. Upgrading Parrot means needing to upgrade (or, at least, rebuild) extensions too.It's difficult to tell an extension developer to stick to the supported releases because the extending API is so lousy and incomplete. Having to wait 3 months or more for a necessary change is hard for these small projects, and their developers can quickly lose interest and motivation. Until we reach some basic level of usability, we have to expect that extension developers are going to be tracking Parrot HEAD more or less closely. I think it's a little disingenuous to simultaneously expect fully that developers will be tracking the repository HEAD but also write in our deprecation policy that they should only track the stable releases, and you really need to ask who exactly that policy is designed to protect in this case.We really need to account for different levels of user and different levels of feature. End-users shouldn't be using Parrot directly. Joe Schmoe at home is not and definitely should not be writing his tools in PIR. If he's writing his code in a higher-level language like Rakudo Perl 6, NQP, or Winxed, he's buffered from disruptive changes made to the Parrot core VM. It's the developers of HLL compilers and extensions that need to worry about these kinds of changes.Likewise, we need to differentiate between issues of multiple severities.When a big issue is blocking development in extensions and HLL compilers, it behooves Parrot to ignore the mandatory wait period and to make those fixes post haste. Alternatively, a change which is not necessary and would cause a block or a slow-down for extension developers should be put off for longer and made with more care.What we need, in a nutshell, is a policy that actually does what we claim the current deprecation policy does now: Protect our users from disruptive changes, but also enable forward progress to be made without being forever tied to every bad decision ever made. I suggest these changes to policy and process:Deprecation should be added before a disruptive change is made The deadline for the deprecation shouldn't be blindly tied to the next stable release, but intelligently selected with input from the affected parties. We do have weekly planning meetings where these kinds of things can be decided. If we need to regularly schedule additional meetings with other parties (HLL compiler devs, extension devs, etc) we should do that as well.Deprecations should be well-documented and publicized. Information about the deprecation should include what exactly is changing, how users of those features can work around the changes, and who to contact when/if problems arise.Information about the deprecation should be sent to the users, not just dumped in DEPRECATED.pod where we expect people to be looking regularly. An email list for this purpose was suggested and I like that idea (other ideas were also suggested that I also like). Any way to send the information directly to the user is a good thing. Where possible, both old and new versions should be provided simultaneously for a period of time while users transition. This is most important in the C-level API where function wrappers can easily be provided to translate old calls into new ones.I'm still a big proponent of the idea that the deprecation policy should be opt-in, in the sense that only features that we've put a stamp of approval onto should be covered under the deprecation policy and anything else should not be relied upon. You can use a feature that we haven't approved, but then you're responsible for paying the price when that feature changes or disappears completely. You would also be responsible for sending the core developers feedback about which features you would like to see be added and approved.Having a deprecation policy is a good thing and a necessary part of a mature software project. However, the policy we have currently fails on a number of counts and requires some serious re-thinking if we want to make it better. I sincerely hope, and I know several other people also hope, that we do make it much better in the future. [Less]