On Sun, Apr 08, 2012 at 09:46:18AM -0700, Allison Randal wrote:
On 04/08/2012 09:29 AM, Alessandro Ghedini wrote:
If we go down the split to different libraries path, those libraries
should
depend on parrotapi-* too so that not only Parrot isn't updated but the
libraries aren't too.
What if we did something like bundling? Practically speaking, for at
least the foreseeable future, Rakudo requires Parrot and the primary
user of Parrot is Rakudo. Offering two separate packages for such a
closely-knit pair almost seems like a waste (it won't always be, but
let's be honest about
On Sat, Apr 07, 2012 at 07:12:19PM -0700, Allison Randal wrote:
Patrick and I just chatted on the phone, here's a summary of the working
scenario we reached:
- Rakudo will deliver a Rakudo release for each supported (stable)
Parrot release, a few days after the Parrot release.
- Debian
On Thu Apr 05 14:56:03 2012, pmichaud wrote:
On Thu, Apr 05, 2012 at 01:46:53PM -0700, Carl Mäsak wrote:
moritz r: say ~(1, 2, 6 ... *)[10]
p6eval rakudo 4373f0: OUTPUT«»
moritz eeks
moritz no, that particular thing isn't in RT
* masak submits rakudobug
For the moment, I'm going to
On Sat, Apr 07, 2012 at 09:08:21PM -0400, Andrew Whitworth wrote:
What if we did something like bundling?
Isn't this what Rakudo Star does? AFAICT the Star distribution is nothing more
than a bundle of rakudo + nqp + parrot + some Perl 6 modules, which may be nice
from a end user POV, but it's
Okay, instead of just complaining about this, I want to do something
about it. The Rakudo packages are so fragile on Debian, that they need
special constraints to make sure the Parrot packages are held back until
the Rakudo packages are updated.
So, why is Rakudo so dependent on one specific
# New Ticket Created by Carl Mäsak
# Please include the string: [perl #112362]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=112362
moritz masak: I think there's also an unsubmitted rakudobug in
today's
# New Ticket Created by Carl Mäsak
# Please include the string: [perl #112364]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=112364
pmichaud niecza: class ABC { our sub xyz() { 'xyz' } }; say ABC.WHO.WHAT
Now fixed in 2c9f46f. Needs spectests to close ticket.
Thanks,
Pm
On Sun, Apr 08, 2012 at 08:42:21PM +0200, Moritz Lenz wrote:
On 04/08/2012 06:53 PM, Alessandro Ghedini wrote:
On Sun, Apr 08, 2012 at 11:09:30AM -0500, Patrick R. Michaud wrote:
On Sun, Apr 08, 2012 at 03:23:26PM +0200, Alessandro Ghedini wrote:
On Sat, Apr 07, 2012 at 09:08:21PM -0400,
On 04/09/2012 09:10 PM, Alessandro Ghedini wrote:
On Sun, Apr 08, 2012 at 08:42:21PM +0200, Moritz Lenz wrote:
On 04/08/2012 06:53 PM, Alessandro Ghedini wrote:
On Sun, Apr 08, 2012 at 11:09:30AM -0500, Patrick R. Michaud wrote:
On Sun, Apr 08, 2012 at 03:23:26PM +0200, Alessandro Ghedini
On Fri, Apr 06, 2012 at 03:53:11AM -0700, Nicholas Clark via RT wrote:
On Thu Apr 05 14:56:03 2012, pmichaud wrote:
On Thu, Apr 05, 2012 at 01:46:53PM -0700, Carl Mäsak wrote:
moritz r: say ~(1, 2, 6 ... *)[10]
For the moment, I'm going to argue Rakudo's behavior here as
correct, or
On Mon, Apr 09, 2012 at 03:16:52PM -0500, Patrick R. Michaud wrote:
Anyway, I think we'll be more productive to move the
constant-folding and compile-time detection issues to a
separate thread and/or ticket; for this ticket I'd prefer
to stick to the case where the sequence is being deduced
13 matches
Mail list logo
