Permalink
Browse files

Merge conflict resolution on IO.pm: take new encoding change

  • Loading branch information...
2 parents 4eb1b6e + 16db643 commit a2da68c60dc6e51d37c1ebaf8050a6b774bb483e @ajscogo ajscogo committed Jul 2, 2012
View
@@ -8,19 +8,23 @@
library installed (<http://site.icu-project.org/>). Rakudo can run
without ICU, but some Unicode-related features do not work properly.
+ To get readline support (command history and editing), you'll also
+ need the "libreadline-dev" library.
+
As an example, on Debian GNU/Linux or Ubuntu Linux, the necessary
components for building Rakudo can be installed via the command
- aptitude install build-essential libicu-dev git-core
+ aptitude install make gcc libicu-dev libreadline-dev git-core
(Perl is installed by default already). To enable parallel testing you
also need the CPAN module Test::Harness in version 3.16 or newer; you
can control the number of parallel jobs with the "TEST_JOBS" environment
variable.
Building and invoking Rakudo
- Because Rakudo is under rapid development, we generally recommend
- downloading Rakudo directly from github and building from there:
+ If you're wanting the bleeding-edge version of the Rakudo Perl 6
+ compiler, we recommend downloading Rakudo directly from Github
+ and building it from there.
$ git clone git://github.com/rakudo/rakudo.git
@@ -78,7 +82,7 @@
satify a minimum specified by the Rakudo being built -- Configure.pl
and "make" will verify this for you. Released versions of Rakudo
always build against the latest release of Parrot; checkouts of
- the HEAD revision from github often require a version of Parrot
+ Rakudo's HEAD revision from Github often require a version of Parrot
that is newer than the most recent Parrot monthly release.
Once built, Rakudo's "make install" target will install Rakudo and its
View
3 README
@@ -1,7 +1,7 @@
Rakudo Perl 6
This is Rakudo Perl, a Perl 6 compiler for the Parrot virtual machine.
- Rakudo Perl is Copyright (C) 2008-2011, The Perl Foundation. Rakudo Perl
+ Rakudo Perl is Copyright (C) 2008-2012, The Perl Foundation. Rakudo Perl
is distributed under the terms of the Artistic License 2.0. For more
details, see the full text of the license in the file LICENSE.
@@ -18,6 +18,7 @@ Rakudo Perl 6
See the INSTALL.txt file for detailed prerequisites and build and
installation instructions. The short version is
+ $ # recommended: install libicu-dev and libreadline-dev packages
$ perl Configure.pl --gen-parrot --gen-nqp
$ make
$ make spectest # optional
View
@@ -1,5 +1,11 @@
New in 2012.07
+ Deprecated SAFE.setting in favor of RESTRICTED.setting
++ Ranges can now interpolate in argument lists
++ The built-in meta-objects (such as Metamodel::ClassHOW) now inherit from Any
++ &open now supports :enc/:encoding
++ Exception.fail
++ Changed &dir to return IO::File and IO::Dir objects, not strings
++ anonymous subset types with subset :: where ...;
New in 2012.06
+ Rakudo is now compiled with the same regex engine as user-space regexes use
View
@@ -93,13 +93,13 @@ release name, etc.
=item *
-Verify that the Parrot trunk head is able to build Rakudo
+Verify that the Parrot master branch is able to build Rakudo
and run the spectest suite. Also check the smolder reports
at L<http://smolder.parrot.org/app/projects/smoke_reports/5>.
=item *
-If Parrot's trunk exhibits any problems building or running
+If Parrot's master branch exhibits any problems building or running
Rakudo (that require changes to Parrot to fix), immediately
report them to the Parrot development team so they can be
fixed prior to Parrot's release.
@@ -113,25 +113,33 @@ that has a large impact on users is worth addressing either
as a fix or as prominent documentation (the README and/or
the release announcement).
-=back
+=item *
-=item 2.
+Create a draft release announcement in docs/announce/YYYY.MM .
+You can often use the previous release's file as a starting point,
+updating the release number, version information, name, etc. as
+appropriate.
-Once Parrot issues its monthly release, tag NQP for release
-according to the year and month of the release:
+ $ git add docs/announce/YYYY.MM
+ $ git commit docs
- $ git clone https://github.com/perl6/nqp.git
- $ cd nqp
+=item *
-Follow the steps in NQP's F<docs/release_guide.pod>.
+If it's a month relatively early in the calendar year,
+double-check that the copyright date in the README file includes
+the current year. (It's not necessary to update copyright dates
+in other files, unless you know that a given file has been modified
+in a year not reflected by the file's copyright notice.)
-=item 3.
+=back
+
+=item 2.
The short period following the Parrot release until the
Rakudo release is generally intended for fixing bugs,
updating documentation, and so on.
-=item 4.
+=item 3.
Update Rakudo's leap-second tables:
@@ -147,22 +155,22 @@ will be unchanged.
B<Note>: this program requires the perl module L<Time::y2038> be installed.
-=item 5.
+=item 4.
As the actual release date nears, review the git log history
to see if any additional items need to be added to the ChangeLog.
This can be conveniently done with "git log --since=yyyy-mm-dd --reverse".
$ git commit docs/ChangeLog
-=item 6.
+=item 5.
-When it's time to cut the release, create a new release announcement
-in docs/announce/YYYY.MM. It's often a good idea to use the
-previous month's file as a starting point for this. Highlight areas
-in which the new release is significant. If possible, also give
-some small details about the choice of release name. (If the
-details are a bit lengthy, this can often best be done as a separate
+When it's time to cut the release, finalize the new release
+announcement in docs/announce/YYYY.MM. (If one hasn't already
+been created, see step 1 above.) Highlight areas in which the
+new release is significant. If possible, also give some small
+details about the choice of release name. (If the details
+are a bit lengthy, this can often best be done as a separate
section at the bottom of the announcement.)
Include a list of contributors since the last release in the announcement.
@@ -185,7 +193,33 @@ you find any steps that are missing.
$ git commit docs/release_guide.pod
-=item 8.
+=item 8.
+
+Create an NQP release with the same C<YYYY.MM> version number
+as Rakudo. Follow NQP's C<docs/release_guide.pod> file to do that.
+
+=item 9.
+
+Go back to the Rakudo repository, and update the NQP dependency:
+
+ $ echo YYYY.MM > tools/build/NQP_REVISION
+ $ git commit -m '[release] bump NQP revision' tools/build/NQP_REVISION
+
+=item 10.
+
+Enter the new version into the F<VERSION> file, and commit the changes:
+
+ $ echo YYYY.MM > VERSION
+ $ git commit -m '[release] bump VERSION' VERSION
+
+=item 11.
+
+Make sure any locally modified files have been pushed back to github.
+
+ $ git status
+ $ git push
+
+=item 12.
Make sure everything compiles and runs from a known clean state:
@@ -209,51 +243,7 @@ Often this means fixing a bug, fudging a test, or (temporarily?)
commenting out a test file in t/spectest.data . Use your best
judgment or ask others if uncertain what to do here.
-=item 9.
-
-=over 4
-
-=item *
-
-B<Note>: these steps overlap with the steps in NQP's release guide.
-
-Go to the NQP repository, tag it and push the tags
-
- $ git tag -a -m"tag release YYYY.MM" YYYY.MM # e.g., 2010.02
-
-Check the NQP revision
-
- $ git describe # should come out as YYYY.MM
- # if not, contact your local git vendor or #perl6
-
-If you got the same version back as you entered, proceed with
-
- $ git push --tags
-
-=item *
-
-Go back to the Rakudo repository, and update the NQP dependency:
-
- $ echo YYYY.MM > tools/build/NQP_REVISION
- $ git commit -m '[release] bump NQP revision' tools/build/NQP_REVISION
-
-=item *
-
-Enter the new version into the F<VERSION> file, and commit the changes:
-
- $ echo YYYY.MM > VERSION
- $ git commit -m '[release] bump VERSION' VERSION
-
-=back
-
-=item 10.
-
-Make sure any locally modified files have been pushed back to github.
-
- $ git status
- $ git push
-
-=item 11.
+=item 13.
Create a tarball by entering C<make release VERSION=YYYY.MM>,
where YYYY.MM is the month for which the release is being made.
@@ -262,38 +252,38 @@ This will create a tarball file named C<rakudo-YYYY.MM.tar.gz>.
B<Caution>: this step removes any untracked files in F<t/spec>.
So please make a backup if you have any important data in there.
-=item 12.
+=item 14.
Unpack the tar file into another area, and test that it
builds and runs properly using the same process in step 8.
If there are any problems, fix them and go back to step 8.
-=item 13.
+=item 15.
Tag the release by its release month ("YYYY.MM") and its code name.
$ git tag -a -m"tag release #nn" YYYY.MM # e.g., 2010.02
$ git tag -a -m"tag release #nn" CODENAME # e.g., "Bratislava"
$ git push --tags
-=item 14.
+=item 16.
Upload the release tarball to github's download area at
L<http://github.com/rakudo/rakudo/downloads>.
-=item 15.
+=item 17.
To avoid public confusion with Rakudo Star releases, we now publish
compiler release announcements ONLY to perl6-compiler@perl.org.
(We may restart widespread announcements of compiler releases
once they are known, or we may begin publishing a single
announcement for both.)
-=item 16.
+=item 18.
Update the Wikipedia entry at L<http://en.wikipedia.org/wiki/Rakudo>.
-=item 17.
+=item 19.
You're done! Celebrate with the appropriate amount of fun.
View
@@ -1,53 +0,0 @@
-This file contains various notes and observations Pm makes as
-he reviews code. Many of these can become RT tickets -- this is
-just a lighter-weight mechanism for keeping track of things to be
-reviewed/done.
-
-Active notes
-
-Pm-1: In src/core/Array.pm, the exists() method has a line like:
-
- [?&] map { self[$^a] !~~ Proxy }, @indices;
-
-There doesn't seem to be a strong reason for using C<map> and [?&]
-here... more efficient would seem to be to use a slice directly,
-as in:
-
- none(self[@indices]) ~~ Proxy
-
-Also, I'm fairly certain the test for Proxy won't stand, because
-we'd like .exists() to also work on Lists. In fact, any sort of
-type-based test is likely wrong -- we'll probably have to resort
-to some PIR-based testing here, since only PIR will really know if
-an element is present in the List/Array.
-
-
-Pm-2: The subroutines in src/core/metaops.pm (e.g,. &reducewith)
-all end up being visible in the core setting. Should they be?
-(I'm thinking they're actually internal helper subs, and as such
-should not be part of the core setting, much less global subs
-as they are now.)
-
-
-Pm-3: Is there any strong reason why Junction.new has C<:any>,
-C<:all>, C<:one>, etc. flags instead of just using C<< :type<any> >>?
-
-
-Pm-4: Why does Rakudo have "EnumMap is Cool" ? Why is it that
-all Iterables are considered Cool?
-
-
-Pm-5: Can someone point to the specification or explain the logic
-behind Parcel.ACCEPTS?
-
-
-------
-
-Resolved notes:
-
-None yet.
-
-
-
-
-
Oops, something went wrong.

0 comments on commit a2da68c

Please sign in to comment.