On 6/26/05, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> > For 3, it looks like B::Deparse does't handle the data at all so even
> > if the deparsed subs are identical they may behave totally
> > differently.
>
> This will simply have to be a caveat. Fortunately, if B::Deparse ever gets
> this
Michael G Schwern wrote:
I just went to go patch in the code ref stuff to is_deeply() and found that
I had unfinished changes to the diagnostic output. Remember, it was about
including the description in the failure diagnostics. So instead of this:
/Users/schwern/tmp/test...NOK 1
On Mon, Jun 27, 2005 at 11:08:40AM +0200, David Landgren wrote:
> I ranted a while back about s/got/received/
Yeah, that's a different issue.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Reality is that which, when you stop believing in it, doesn't go away.
On 6/27/05, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 27, 2005 at 01:41:30AM +0100, Fergal Daly wrote:
> > I'm not sure there is a right way to deparse closures (in general).
> > For example if a variable is shared between 2 closures then it only
> > makes sense to deparse both of
Being a Perl 5 user myself, I believe that it would be the best idea to
write the final Perl 6 compiler targetting Parrot ideally in Perl 6 or
at least some other higher-high level language such as Haskell. The
reason behind this is this would allow the compiler to be maintained by
Perl 6 develo
On Mon, Jun 27, 2005 at 11:20:07AM +0100, Fergal Daly wrote:
> > I'm perfectly happy to punt this problem over to B::Deparse and let them
> > figure it out. As it stands B::Deparse is the best we can do with code
> > refs. What's the alternative?
>
> I'd argue that currently the best you can do
On Mon, Jun 27, 2005 at 11:34:58PM +0100, Fergal Daly wrote:
> Forgetting philosphical arguments about what's the right thing to do,
> I think the strongest point against this is that there may be people
> out there who expect the current behaviour
The current behavior is to vomit all over the use
On Tue, Jun 28, 2005 at 12:21:48AM +0100, Fergal Daly wrote:
> That's only 2 months old (according to CPAN) before that it would have
> just failed or passed (failed in this case). Is it in bleadperl? I'd
> be amazed if no one anywhere was using is_deeply with coderefs.
It was undefined, accidenta
Hi
Autrijus' journal mentions quasiquoting (Perl 5).
I was wondering how that would work. Many languages use unusual
syntax for quasiquoting and code splicing but Perl 6 is already
nibbling into unicode.
Does that mean macros will be grafting and pruning the AST that
comes back from a quote/r
On Tue, Jun 28, 2005 at 09:49:58AM +1000, Brad Bowman wrote:
> Autrijus' journal mentions quasiquoting (Perl 5).
Yes... quasiquoting in Perl 5 is currently crudely emulated
by feeding things to PPI::Tokenizer and PPI::Transform. :-)
> I was wondering how that would work. Many languages use unusu
"Millsa Erlas" <[EMAIL PROTECTED]> wrote:
A self-hosting Perl 6 will require of course an implementation of Perl 6
in another language. Pugs seems to be quite far ahead in this respect,
quite a bit has already been accomplished with Pugs so it would seem to
me to be most efficient and quick to tu
So are you suggesting that Ponie be written in Perl 6 or Perl 5? If you
want to remain consistent with the self hosting approach and maximize
the Perl 5 userbase, the Ponie compiler Perl should be written in Perl
5, and thus self hosted as well via itself on Parrot. If this were the
case, work on
On 27 Jun 2005, at 15:47, [EMAIL PROTECTED] wrote:
So are you suggesting that Ponie be written in Perl 6 or Perl 5?
If you
Ponie is being written in C. As it stands, it's a refactoring of the
current perl code base to
use Parrot internals. When all the intended changes have finished,
i
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Monday 27 June 2005 00:37, Michael G Schwern wrote:
> On Sun, Jun 26, 2005 at 12:57:05PM +0100, Fergal Daly wrote:
> > 1 the refs came from \&somefunc
> > 2 the refs come from evaling strings of code
> > 3 the refs are closures and therefore have some d
On Mon, Jun 27, 2005 at 09:25:02AM +0100, Steve Hay wrote:
> Has the timer output confused other things besides Test-Smoke that you
> know of? If not then perhaps leave the timer output on by default and
> have a switch to turn it off?
I believe some of Module::Build's tests got confused.
Mayb
On Mon, Jun 27, 2005 at 09:25:02AM +0100, Steve Hay ([EMAIL PROTECTED]) wrote:
> Aww - I was beginning to like the timer output now the Abe graciously
> fixed Test-Smoke to understand it.
Set HARNESS_TIMER in your environment.
xoxo,
Andy
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com
Andy Lester wrote:
>I've just uploaded Test::Harness 2.51_02. It turns off the timer by
>default, and adds a --timer switch to prove. Please try it out and see
>if all is well because I'm going to make it 2.52 tomorrow.
>
Aww - I was beginning to like the timer output now the Abe graciously
fi
On Mon, Jun 27, 2005 at 05:11:10PM -0400, Andy Dougherty wrote:
> Well, I think there are already way too many pointer casts and related
> games in the source. Perhaps more to the point, not all casts are going
> to work.
Well, there is that. :-)
In this case, as I understand it, we're lookin
{ This is a partial reply; what with YAPC I didn't finish, but a new
version of the patch from Leo will give me time to catch up }
I've reviewed the patch. I appreciate what you're doing with it, but
there are some issues that will have to be addressed.
1. "union Parrot_Context" is not porta
On Mon, 27 Jun 2005, Chip Salzenberg wrote:
> 1. "union Parrot_Context" is not portable C.
>
> The C standard requires that all structure pointers be bitwise
> compatible - same size, layout, etc.[*] It doesn't require that of
> other pointers -- specifically char* in this case. So the union:
>
A scale on which I hope we cannot be scored:
http://www.stsc.hill.af.mil/crosstalk/1996/11/xt96d11h.asp
--
Chip Salzenberg <[EMAIL PROTECTED]>
21 matches
Mail list logo
