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 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/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
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/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 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/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 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
>
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
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
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
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
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 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 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 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 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, 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
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, 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
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/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, Andrew Whitworth wrote:
>> > Btw, this also applies to NQP b
On Sun, Apr 08, 2012 at 07:32:55PM +0200, Alessandro Ghedini wrote:
> On Sun, Apr 08, 2012 at 12:15:44PM -0500, Patrick R. Michaud wrote:
> > I'm not quite able to follow here -- could you explain further or give
> > an example? I mean, I understand how changes to NQP can affect
> > Rakudo, but I
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 downstream users (including Rakudo and NQP) must be
> > rebuilt every time
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? AFAICT the Star "distribution" is nothing
> more
> than a bundle of rakudo + nq
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 Sat, Apr 07, 2012 at 03:24:37PM -0700, Allison Randal wrote:
> These are things that Rakudo shouldn't care about. A bug-fix or
> performance enhancement in Parrot is good, but doesn't actually affect
> Rakudo's ability to build or run.
Sometimes it does. See the flurry of difficulties we had l
On 4/7/2012 19:11, Allison Randal wrote:
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 i
28 matches
Mail list logo
