Rakudo Perl 6 development release #28 (Moscow)
On behalf of the Rakudo development team, I'm pleased to announce the March 2010 development release of Rakudo Perl #28 Moscow. Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine (see http://www.parrot.org). The tarball for the April 2010 release is available from http://github.com/rakudo/rakudo/downloads . Rakudo Perl follows a monthly release cycle, with each release named after a Perl Mongers group. The April 2010 release is code named Moscow in recognition of Москва.пм and their invitation of Jonathan Worthington, one of our core develepors, to speak at the Russian Internet Technologies 2010 [1] conference. Some of the specific changes and improvements occuring with this release include: * Expressions that begin with a variable and end with a circumfix now properly interpolate into double-quoted strings, like @array.sort() or %hashkey. * Item assignment now has tighter precdence than list assignment, so both 'my @a = 1, 2, 3' and '$a = 1, $b = 2' magically work. * Most of the DateTime built-in type has been backported from the alpha branch, and is now accompanied by a Date type for date-only calculations. * Many obsolete uses of Perl 5 constructs are now caught and give helpful error messages. * As always, many additional small features and bug fixes make working with Rakudo more pleasant. * Rakudo now passes 30,931 spectests. We estimate that there are about 39,000 tests in the test suite, so Rakudo passes about 79% of all tests. For a more detailed list of changes see docs/ChangeLog. The development team thanks all of our contributors and sponsors for making Rakudo Perl possible. If you would like to contribute, see http://rakudo.org/how-to-help , ask on the perl6-compi...@perl.org mailing list, or ask on IRC #perl6 on freenode. The next release of Rakudo (#29) is scheduled for May 20, 2010. A list of the other planned release dates and code names for 2010 is available in the docs/release_guide.pod file. In general, Rakudo development releases are scheduled to occur two days after each Parrot monthly release. Parrot releases the third Tuesday of each month. Have fun!
Re: Rakudo Perl 6 development release #28 (Moscow)
Moscow.pm also reminds that today (22 Apr) is the birthday of Lenin :-) March 2010 development release of Rakudo Perl #28 Moscow. -- Andrew Shitov __ a...@shitov.ru | http://shitov.ru
Re: Proposal for a new Temporal time-measurement paradigm
On Wed, 21 Apr 2010, Mark J. Reed wrote: I recommend not to open this up for 6.0.0 core. Calendar conversion is easy to do in a module, and the Date class has an absolute day count, which is really all you need everything for an intermediate representation. It wouldn't be hard to port Calendrica, for instance. What he said. Perl is all about good Huffman coding. The _vast_ majority people who need to do stuff with dates and datetimes will be dealing with the modern Gregorian calendar. Therefore, having a correct and simple to use implementation of some minimal Gregorian calendar objects in core makes a lot of sense. For folks who need to get fancier, the day count on the Date class will allow simple conversion between calendars, which they can find on CPAN6, along with modules that do more with the Gregorian calendar. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: Proposal for a new Temporal time-measurement paradigm
Minor nit: On Apr 21, 2010, at 04:57 , Richard Hainsworth wrote: If a calendar system, eg., Chinese, Muslim and Jewish, defines days in the same way, eg., starting at midnight and incorporating leap seconds, for a time-zone, then the naming of the days is done by The Jewish, Muslim, and Baha`i (and, technically at least, Christian) religious calendars use sunset as the start of the day. Only Western Christianity and Baha`i use the Gregorian corrections; Orthodox Christianity and the other aforementioned calendars are Julian. (Actually, the Baha`i calendar seems unclear on this; everything I can find suggests that it's still an open issue for them, but for the moment at least it's tied to the Gregorian calendar.) The Jewish calendar doesn't recognize leap seconds; all time measurements are variable, with the day and night separately divided into 12 sha`ot composed of 60 dakot whose lengths vary as the length of the day/night changes throughout the year. Sunrise and sunset are usually defined as when the leading (resp. trailing) edge of the solar disk crosses the horizon. (Some communities use a variation where sunrise is considered to be first light and sunset the end of twilight; *usually* these are taken as the sun being 16° below the eastern horizon and 7.5° below the western. However, there's a lot of variation between communities, and very little of this is fixed; one opinion sets the start of night as 1 1/4 sha`ot *before* sunset!) Islam has some other sticking points in this area: some communities define the start of a new month based on local time, while others base it on observations at Mecca, with the result that the calendar can vary by a day even in the same location. (This got some discussion in the context of Iraqi sectarian violence a few years back.) Additionally, while Jews use a fixed calculation of when the new moon occurs, Muslims still base the start of the month on direct observation of the new moon, so the calendar can again be off by a day. All of which suggests that it may not actually be possible to come up with a mechanism suitable for representing all of these calendars. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part
Re: Proposal for a new Temporal time-measurement paradigm
Why do I find myself thinking of roles and classes here? IMHO, we should have a role that represents abstractly a moment in time. This role should, in and of itself, not be tied to any particular calendar; its purpose is so that one can write functions that make reference to instances in time without locking oneself into a particular labeling scheme. We should also have a series of classes that compose that role, each class representing a different calendar scheme. For perl 6.0.0, only one such class need be defined: the one representing the Gregorian calendar. Later on, modules can be written to provide additional classes representing other calendar schemes. Fine in theory; in practice, the big question is: how much can we get the role to do, within the no calendar preference constraint? And a corollary to this: can we get it to do enough to be worthwhile? -- Jonathan Dataweaver Lang
