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 a
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 th
On Sun, 2012-08-04 at 15:23 +0200, Alessandro Ghedini wrote:
> 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 + par
On Sun, Apr 08, 2012 at 08:08:28PM +0200, Alessandro Ghedini wrote:
> This way we avoid that Parrot-based compilers don't break in the period of
> time
I really meant "This way we avoid the Parrot-based compilers *break*..." -.-"
Cheers
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'
On Sun, Apr 08, 2012 at 12:15:44PM -0500, Patrick R. Michaud wrote:
> On Sun, Apr 08, 2012 at 06:53:49PM +0200, Alessandro Ghedini wrote:
> > On Sun, Apr 08, 2012 at 11:09:30AM -0500, Patrick R. Michaud wrote:
> > > Unfortunately, aiui Parrot's current implementation requires that
> > > all of its
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.
>
> - D
On Thu Apr 05 14:56:03 2012, pmichaud wrote:
> On Thu, Apr 05, 2012 at 01:46:53PM -0700, Carl Mäsak wrote:
> > r: say ~(1, 2, 6 ... *)[10]
> > rakudo 4373f0: OUTPUT«»
> > eeks
> > no, that particular thing isn't in RT
> > * masak submits rakudobug
>
> For the moment, I'm going to argue Rakudo
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
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, Andrew Whitworth wrote:
> > > What if we did something like bundling?
> >
> > Isn't this what Rakudo Star does? AF
On Sun, Apr 08, 2012 at 08:27:26AM -0700, Allison Randal wrote:
> On 04/08/2012 07:13 AM, Alessandro Ghedini wrote:
> >> - Debian will package each supported release of Parrot.
> >
> > Isn't this what's already happening? I mean, we already package stable
> > Parrot
> > releases and therefore we
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 month
# New Ticket Created by spider-mario
# Please include the string: [perl #112344]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=112344 >
With Rakudo 2012.03-53-g119fe3b (commit
119fe3b5b85fe680aa1a7ea29042a5714e63a402
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 will package each supported release of Parrot.
Debian packages for Raku
That solution is fine by me. The real source of the problem is on the
Parrot side, and our extremely fragile versioning system for bytecode.
This is something that we need to address to help fix the problem in
the long term.
Exactly how we fix it is a matter for discussion, of course.
--Andrew Wh
On Sun, Apr 08, 2012 at 10:13:37AM -0700, Allison Randal wrote:
> On 04/08/2012 10:01 AM, Alessandro Ghedini wrote:
> >
> > The parrotapi-* thing would avoid an update of the parrot package, but
> > there's
> > nothing that would avoid an update of, say, libdata-dumper-parrot, and it
> > would
>
On 04/08/2012 10:01 AM, Alessandro Ghedini wrote:
>
> The parrotapi-* thing would avoid an update of the parrot package, but there's
> nothing that would avoid an update of, say, libdata-dumper-parrot, and it
> would
> leave the system with an older version of parrot and a newer version of the
>
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. Or alternatively parrot should strictly depend on them.
Makes sense
On 04/07/2012 12:34 PM, Jonathan Worthington wrote:
> Easiest way to analyze it is just git log on
> build/tools/PARROT_REVISION. Here I've done a very rough categorization
> of the last 20 entries (which takes us back to October).
>
> Some of them are to take advantage of Parrot feature additions
On 04/08/2012 11:08 AM, Alessandro Ghedini wrote:
> I think I don't understand... NQP and Rakudo *do* ship compiled bytecode, and
> would of course need to be rebuilt when a new Parrot release is uploaded. The
> whole point of parrotapi-* is to make sure that Parrot and its libraries are
> not upda
On 04/08/2012 07:13 AM, Alessandro Ghedini wrote:
>> - Debian will package each supported release of Parrot.
>
> Isn't this what's already happening? I mean, we already package stable Parrot
> releases and therefore we can only package Rakudo releases that run on such
> Parrot versions.
Just bein
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #112362]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=112362 >
masak: I think there's also an unsubmitted rakudobug in
today's backlog, kind of
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #112364]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=112364 >
niecza: class ABC { our sub xyz() { 'xyz' } }; say ABC.WHO.WHAT
niecza v15-6-
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
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 G
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:
> > > r: say ~(1, 2, 6 ... *)[10]
> >
> > For the moment, I'm going to argue Rakudo's behavior here as
> > "correc
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
27 matches
Mail list logo
