Announce: Mac OS X Installer for release 2016.01
Thanks to Steve Mynott a Mac OS X installer is now available. This installer has the ".dmg" file extension and is available from http://rakudo.org/downloads/star/.
Announce: Windows MSI Installers for release 2016.01
The Windows MSI installers are now available, coming again in two versions. One installer targets x86 (32bit) platforms, and the other installer targets x86_64 (64bit) platforms (probably Windows 7 or better). Only the version for x86_64 comes with JIT enabled. The two MSIs are available from http://rakudo.org/downloads/star/.
Announce: Rakudo Star Release 2016.01
# Announce: Rakudo Star Release 2016.01
## A useful and usable production distribution of Perl 6
On behalf of the Rakudo and Perl 6 development teams, I'm happy to announce
the January 2016 release of "Rakudo Star", a useful and usable production
distribution of Perl 6. The tarball for the January 2016 release is
available
from http://rakudo.org/downloads/star/.
This is the first post-Christmas (production) release of Rakudo Star and
implements Perl v6.c. It comes with support for the MoarVM backend (all
module
tests pass on supported platforms).
Please note that this release of Rakudo Star is not fully functional
with the
JVM backend from the Rakudo compiler. Please use the MoarVM backend only.
In the Perl 6 world, we make a distinction between the language ("Perl
6") and
specific implementations of the language such as "Rakudo Perl". This Star
release includes release 2016.01.1
of the Rakudo Perl 6 compiler , version
2016.01 of MoarVM .
See http://perl6.org/ for links to much more information about
Perl 6, including documentation, example code, tutorials, reference
materials, specification documents, and other supporting resources.
Perl 6 tutorials are available under the "docs" directory in
the release tarball.
The development team thanks all of the contributors and sponsors for
making Rakudo
Re: Backwards compatibility and release 1.0
Am 15.10.2015 um 10:47 schrieb Smylers: > Moritz Lenz writes: > >> On 10/13/2015 10:52 AM, Richard Hainsworth wrote: >> >>> Following on the :D not :D thread, something odd stuck out. >>> >>> On 10/13/2015 03:17 PM, Moritz Lenz wrote: We have 390+ modules, and hand-waving away all trouble of maintaining them seems a bit lofty. >>> Surely, the idea of keeping the release number below 1.0 is to warn >>> early adopter developers that code is subject to change and thus in >>> need of maintenance? >> ... a large percentage of the module updates are done by group of >> maybe five to a dozen volunteers. ... 5 people updating 70% of 390 >> modules. Modules they are usually not all that familiar with, and >> usually don't have direct access. So they need to go through the pull >> request dance, waiting for reaction from the maintainer. In short, it >> sucks. > Thanks for the explanation, Moritz. That does make sense. > > I'm still a _little_ uneasy because that sounds a bit like the > explanation of why Makefiles have to use tab characters: > > I just did something simple with the pattern newline-tab. It worked, > it stayed. And then a few weeks later I had a user population of about > a dozen, most of them friends, and I didn't want to screw up my > embedded base. The rest, sadly, is history. > > — Stuart Feldman http://stackoverflow.com/a/1765566/1366011 > > Though the important difference is that invisible whitespace characters > that some editors don't even let you type are particularly > beginner-hostile, whereas allowing undef arguments where they don't make > sense (and hence where callers don't generally try supplying undef) is > something that many Perl 5 programs have been doing for years with no > widespread harm. > > Cheers > > Smylers Btw, In my opinion the current model about :D etc is very correct. I don't see any need to change the defaults as how type objects or their definedness is implementet. Changing for example the params to mean Int:D by default when one writes Int is something you have to explain a lot. And in fact it is a lie. There are some basic rules about Perl 6 like TIMTOWTDI and DRY, but there is also a rule about "All is fair if you predeclare". But if I don't predeclare that I mean Int:D by writing Int, then the compiler is not allowed to change the meaning of what I wrote. That said, if there was a change that justifies breaking a lot of stuff, I'm for it. But here it is certainly not the case. -- Tobias
Re: To :D or not to :D
> * Patrick R. Michaud (pmich...@pobox.com) [151013 01:05]: >> On Tue, Oct 13, 2015 at 12:32:01AM +0200, Mark Overmeer wrote: >>> Yes, that what I started realizing when I saw all the pain Perl6 goes to >>> ignore the existence of a real "undef" in the language. (I follow Perl6 >>> from a short distance since its start, read all original designs, but >>> this penny did not drop before, sorry) >> Actually, it's the other way around. Perl 6 is not trying to ignore >> the existence of an "undef", it's recognizing that there are in fact >> many different kinds of undef. It's the languages that think there's >> only one "real undef" that are confused. :) > Yes, I like the typed undef... as real undef. Let's call it "Car:undef" > when it fits in a Car typed variable which is not used yet. Easy to > understand for Perl5 people. Why do we need to add an adverb on a type to talk about the type? If you want to pass a class around for example, do you alsway want to but an ":undef" on it? Then somebody would ask: "What do I get when I dont put said :undef on it?" - And the answer might be "Well, you get basically the same." Also please keep in mind that Perl 6 does not have to be seen from a Perl 5 perspective. There are more valid views. >>> my Car $a; my Car $b; Now I have two different types. >> Not really, you have two variables, both of which have been >> initialized to the same (undefined) Car object. It's not >> much different than >> >>my Int $a; my Int $b; $a = $b = 1; >> >> where $a and $b end up being variables that contain the same >> Int object. > This is a different view on the syntax layer: implementor vs programmer. > As programmer, knowing of optimizations of this kind adds to the > confusion, not to the understanding. As long as >my Int $a; my Int $b; $a = $b = 1; $b = 2; $a.say, $b.say > produces 1\n2\n, I'm fine with any implementation. I don't want to know > how it is done internally. No, rot really. You stated that you have two dirrenent types there, but it really is the very same type. It is just so that two variables containing it. >> I think Self would be the (pardon the pun) prototypical example, and >> it's also a common feature of JavaScript. As to whether there is >> precedence in other "successful" programming languages > I use it in JavaScript. I reread a few tutorials about OO/prototype > in Javascript yesterday. They smoothly speak about adding methods to > objects etc. They speak about types and objects in a very natural way. > They don't speak about undef objects to contain types, which are used > as object factory. I have not found the need for :U there. I've also not used :U in Perl 6 yet. There might be scenarios where you want to accept, say, class definitions only but these cases are rare I'd say. More often you call a construction on a type, or smartmatch a value agains a type. And this really happens regularly in idomatic Perl 6 code. >> Perl 6 still has classes and instances, but Perl 6 also adds the >> ability to represent undefined instances of a type (or, rephrased, >> to have typed "undefs"). Perl 6 then binds the commonly-used >> identifier (e.g., C) to an undefined instance rather than the >> class object that defines the instances. Once you accept that model, >> it seems to work out very well in practice. > Trying to reformulate this without spoilers of internal details: > > Perl6 has classes, instances, and prototypes. Commonly used > types, like Int, are prototypes based on classes. Therefore, > they can easily absorb features via Roles and Mixins. > > Note about the internals: we are not keeping a separate > administration of type features, but keep that inside the > instantiated objects. As all prototype-based languages do. > > Acceptable? > >> If Research refers instead to the class definition, then the >> method namespaces for instances and classes begin to clash, and >> we have to introduce all sorts of disambiguation for that. > Yes, disambiguation either via a keyword (class method/instance method) > or via the invocant (being a type :T or instance... multi methods to > the rescue) > > For me, prototypes in JavaScript work well, because all graphical > elements on the screen are slightly different in behavior. I am a bit > afraid to get into swamps when programs are large, where it is already > hard to keep track on all the cleanly organized classes. > > So... my hessitation seems to be limited to the explanation and name > of the flag :U, which tell me that a type is an undef. Type defining > features are loaded into a base object which does not carry a value: yes. > Via specialization you get objects which carry a value. > > Maybe this comes back to the distiction between implicit and explicit > undefinedness.
Re: Does Perl 6 use $a and $b in sorting?
sort accepts something callable with an arity of 2.
Subroutines, blocks and pointies will do:
say sort { $^a cmp $^b }, 5, 3, 2, 6, 4
OUTPUT«(2 3 4 5 6)»
say sort { $^left cmp $^right }, 5, 3, 2, 6, 4
OUTPUT«(2 3 4 5 6)»
say sort -> $a, $b { $a cmp $b }, 5, 3, 2, 6, 4
OUTPUT«(2 3 4 5 6)»
sub foo($a, $b) { $a cmp $b }; say sort , 5, 3, 2, 6, 4
OUTPUT«(2 3 4 5 6)»
The { $^a cmp $^b } form also creates a anonymous sub that has two
parameters, $^a and $^b.
The funny thing about these params is that their position in the
implicit signature is obtained by the
alphabetical order of the parameter names.
So, there are no $a and $b special variables, it is just the common way
of naming them.
Am 26.09.2015 um 18:00 schrieb Parrot Raiser:
> Because of the the special significance of $a and $b in Perl 5's sort
> comparison, I always avoid using the names in examples, lest it set a
> booby-trap for later.
>
> I've noticed "a" and "b' being used in some P6 examples. Are they no
> longer significant, or are they just a poor choice of identifier?
Announce: Windows MSI Installers for release 2015.06
The Windows MSI installers are now available, coming again in two versions. One installer targets x86 (32bit) platforms, and the other installer targets x86_64 (64bit) platforms (probably Windows 7 or better). Only the version for x86_64 comes with JIT enabled. The two MSIs are available from http://rakudo.org/downloads/star/.
Announce: Rakudo Star Release 2015.06
# A useful, usable, early adopter distribution of Perl 6 On behalf of the Rakudo and Perl 6 development teams, I'm happy to announce the June 2015 release of Rakudo Star, a useful and usable distribution of Perl 6. The tarball for the June 2015 release is available from http://rakudo.org/downloads/star/. This Rakudo Star release comes with support for the MoarVM backend (all module tests pass on supported platforms). In the Perl 6 world, we make a distinction between the language (Perl 6) and specific implementations of the language such as Rakudo Perl. This Star release includes [release 2015.06] of the [Rakudo Perl 6 compiler], version 2015.06 of [MoarVM], plus various modules, documentation, and other resources collected from the Perl 6 community. Other Rakudo Perl 6 Comiler changes included in this release: https://github.com/rakudo/rakudo/blob/nom/docs/announce/2015.04.md https://github.com/rakudo/rakudo/blob/nom/docs/announce/2015.05.md https://github.com/rakudo/rakudo/blob/nom/docs/announce/2015.06.md [Rakudo Perl 6 compiler]: http://github.com/rakudo/rakudo [MoarVM]: http://moarvm.org/ Some of the new compiler features added to this release include: * 0 (0 as a string) is now True, no special-casing anymore * an Int() coercion type in a multi now creates two candidates: Any and Int * native arrays * starts-with/substr-eq/ends-with for comparing strings inside other strings * where constraints on variable and attribute declarations * 'is rw' parameters implemented for native subs (they get passed as a pointer) * use Foo:from\Perl5\ and EVAL $code, :lang\perl5\ are now supported as long as Inline::Perl5 is installed. Allows passing most of S01 spec tests. * NFG, NFC, NFD, Uni * unit declaration needed for blockless packages * Various API changes for the Great List Refactor, such as... + 'for' loops not longer flatten; use 'for flat' for that + .map no longer flattens, map as a listop does. Use .flatmap to get the old behavior + Likewise other methods that used to flatten their invocant no longer do: all, any, one, none, unique, squish, min, max, minmax, classify, and categorize + Nil no longer iterates like the empty List. Use () or Empty instead. * .pick($n)/roll($n) now always return lists, even when $n == 1 * The is cached trait no longer works on methods, throws a NYI instead * Method .map should be used instead of .for * The REPL is strict by default now, that leaves only '-e' lines to be lax * Implement new @*INC handling (about 30% faster startup time) (bare startup time is now below 100 ms on some machines) * Implemented CUnions which map to the union C type definition for NativeCall * Implemented HAS declarator for attributes to mark it embedded into the CStruct or CUnion * Lexical pragma 'use trace' now outputs statements on STDERR There are some key features of Perl 6 that Rakudo Star does not yet handle appropriately, although they will appear in upcoming releases. Some of the not-quite-there features include: * advanced macros * non-blocking I/O (in progress) * much of Synopsis 9 and 11 There is an online resource at http://perl6.org/compilers/features that lists the known implemented and missing features of Rakudo's backends and other Perl 6 implementations. In many places we've tried to make Rakudo smart enough to inform the programmer that a given feature isn't implemented, but there are many that we've missed. Bug reports about missing and broken features are welcomed at rakudo...@perl.org. See http://perl6.org/ for links to much more information about Perl 6, including documentation, example code, tutorials, reference materials, specification documents, and other supporting resources. A draft of a Perl 6 book is available as docs/UsingPerl6-draft.pdf in the release tarball. The development team thanks all of the contributors and sponsors for making Rakudo Star possible. If you would like to contribute, see http://rakudo.org/how-to-help, ask on the perl6-compi...@perl.org mailing list, or join us on IRC #perl6 on freenode.
Re: versioning - how to request different 'ver' per 'auth'?
Hi, that is a very interesting use case, and IMO a very valid one.
Currently the semantics are, to also explain the correct syntax of the
pair that follows a 'use NAME':
:authBar and :ver1.2 etc are of type Pair. Wenn the compiler hits a
use statement, it smartmatches
the distribution's auth/name/ver against the value of the corresponding
Pair.
That means these Pairs are valid:
:authBar # match literally
:auth(/\w+/) # regex match
:auth($author) # okay if $author is known at compile time
:auth(*.chars == 6) # oaky, whatevercode
:auth({ $_.starts-with('Bla') }) # okay, closure
:auth(- $auth { $auth ~~ /Bla/ }) # okay, something callable with arity
== 1
:auth({ $^auth ~~ /Bla/ }) # okay, something callable with arity == 1
etc
That also means we cannot match different version patterns for different
:auth patterns, because we only
pass one value to the Pair's value to smartmatch against. What I can
imagine though is that if the matcher
is callable, and has an arity of 2, we pass the CompUnit as the first
and the $auth as the second argument.
That needs consensus in #perl6 though.
Cheers, Tobias
Am 11.06.2015 um 05:26 schrieb Darren Duncan:
So I have a question about versioning, either/especially about
compilation units, but also Perl 6 itself.
For context I refer to http://design.perl6.org/S11.html#Versioning .
With regard to use statements and specifying 'auth' or 'ver' to
restrict between versions, it seems to me that the spec defines them
interacting in a cross-product fashion.
For example, given this possibly incorrect syntax:
use Dog:authcpan:TPF cpan:JRANDOM:ver(4-6, 10-15);
... that would be satisfied by any of TPF versions 4-6,10-15 or
JRANDOM versions 4-6,10-15.
However, what I want is to restrict the 'ver' differently depending on
the 'auth', treating them more as the hierarchy they are, assuming
that different authorities may go off and use different versioning
schemes.
The question I have is how to 'or' the following into a single 'use
Dog' that isn't any less restrictive:
use Dog:authcpan:TPF:ver(v1.2.1..v1.2.3);
use Dog:authcpan:JRANDOM:ver(v14.3..v16.2);
That is, the cross-product answer is not restrictive enough.
I don't know if this hypothetical use case has been discussed before,
but if not, I hope that the Perl 6 specification has or can gain a
clean way to say how its done.
Thank you.
-- Darren Duncan
Announce: Rakudo Star Release 2014.09
## A useful, usable, early adopter distribution of Perl 6 On behalf of the Rakudo and Perl 6 development teams, I'm happy to announce the September 2014 release of Rakudo Star, a useful and usable distribution of Perl 6. The tarball for the September 2014 release is available from http://rakudo.org/downloads/star/. Windows .MSI versions of Rakudo star for the MoarVM and Parrot backend are also avaiable in the downloads area. This Rakudo Star release comes with support for the MoarVM backend (all module tests pass on supported platforms) along with experimental support for the JVM backend (some module tests fail). Two shipped modules are known to fail on Parrot (JSON::RPC and p6doc). In the Perl 6 world, we make a distinction between the language (Perl 6) and specific implementations of the language such as Rakudo Perl. This Star release includes [release 2014.09] of the [Rakudo Perl 6 compiler], version 6.7.0 of the [Parrot Virtual Machine], version 2014.09 of [MoarVM], plus various modules, documentation, and other resources collected from the Perl 6 community. [release 2014.09]: https://github.com/rakudo/rakudo/blob/nom/docs/announce/2014.09.md [Rakudo Perl 6 compiler]: http://github.com/rakudo/rakudo [Parrot Virtual Machine]: http://parrot.org [MoarVM]: http://moarvm.org/ Some of the new features added to this release include: * panda (the module installer client) does work on windows again * panda knows about all modules, that are shipped with this release * ./perl6 --profile for MoarVM * Workaround OS X make bug for MoarVM * support for submethod DESTROY (MoarVM only) * optimizations to Str.words, Str.lines, IO.lines, chomp, and return * added experimental support for Proc::Async, MoarVM only for now * Reduced memory size of CORE.setting, improved startup time * startup (on Moar) 15% faster than p5 w/ Moose There are some key features of Perl 6 that Rakudo Star does not yet handle appropriately, although they will appear in upcoming releases. Some of the not-quite-there features include: * advanced macros * threads and concurrency (in progress for the JVM and MoarVM backend) * Unicode strings at levels other than codepoints * interactive readline that understands Unicode * non-blocking I/O * much of Synopsis 9 and 11 There is an online resource at http://perl6.org/compilers/features that lists the known implemented and missing features of Rakudo and other Perl 6 implementations. In many places we've tried to make Rakudo smart enough to inform the programmer that a given feature isn't implemented, but there are many that we've missed. Bug reports about missing and broken features are welcomed at rakudo...@perl.org. See http://perl6.org/ for links to much more information about Perl 6, including documentation, example code, tutorials, reference materials, specification documents, and other supporting resources. A draft of a Perl 6 book is available as docs/UsingPerl6-draft.pdf in the release tarball. The development team thanks all of the contributors and sponsors for making Rakudo Star possible. If you would like to contribute, see http://rakudo.org/how-to-help, ask on the perl6-compi...@perl.org mailing list, or join us on IRC \#perl6 on freenode.
