Bob Rogers <[EMAIL PROTECTED]> wrote:
>The attached patch is supposed to do two things:
>1. Makes it possible to say ".flatten foo" as part of a
> .pcc_begin_return/.pcc_end_return sequence. Remarkably, this part of
> the patch is only a one-line change; the internals for call & return a
conf/init/hints/msys.pl
Configure::Data->set(
ld => '$(PERL) /bin/perlld',
dynclasses/build.pl
our $LD = qq[$(PERL) /bin/perlld];
test.pl
our $LD = qq[$(PERL) /bin/perlld]; print "'$LD'\n";
our $LD = qw[$(PERL) /bin/perlld]; print "'$LD'\n";
test.pl output:
'0PERL) /bin/perlld'
'$
François PERRAD wrote:
(So with MinGw, the generation of Makefile needs /, and the execution
needs \)
Yes I can confirm this.
MSYS build:
$ perl -Ilib t/pmc/sys.t
1..1
not ok 1 - spawnw, _config
# Failed test (t/pmc/sys.t at line 26)
# got: '. Command not found
# 1
# '
# expected
At 12:02 PM +0100 3/15/05, François PERRAD wrote:
When I analyse the failure of t/pmc/sys.t with MinGW32,
I see that this script generates a command depending of the OS
on MSWin32, cmd = ".\parrot temp.imc"
on *nix, cmd = "./parrot temp.imc"
(So with MinGw, the generation of Makefil
At 11:07 AM +0100 3/15/05, Leopold Toetsch wrote:
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
t/pmc/namespace.t
Please have a look at the supported syntax constructs. Are these
sufficient for HLL writers?
Some more thoughts WRT namespaces.
We can define a namespace, where a function or method i
At 5:19 PM +0100 3/19/05, Leopold Toetsch wrote:
1) builtin methods are living in a class namespace e.g.
Float."cos"
ParrotIO."open" # unimplemented
I'm way out of the loop and may have been dealt with in prior mail,
but are we doing real method calls for cos() and suchlike things?
That seem
At 8:10 AM +0100 3/16/05, Leopold Toetsch wrote:
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Syntax proposal:
.sub foo @MULTI
.invocant Integer a
.invocant Float b
.param pmc c
...
Alternate syntax:
.sub foo multi(Integ
As everyone's more than aware, I've not been around much at all the
past few months. Real Life, alas, managed to get a good hold on me
and doesn't look to be letting go any time soon. This isn't at all
good for Parrot development -- a designer who's absent is definitely
a Bad Thing, and it's re
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> As such, I'd like to say a big thanks to Chip Salzenburg who's agreed
> to take the hat. The perl folks on the list will recognize Chip as
> the perl 5.004 pumpking and the guy who took the first shot at "Perl:
> The Next Generation" (aka Topaz). Chip's a d
On Mon, 2005-03-21 at 15:39 -0500, Dan Sugalski wrote:
> And, to forestall some of the wave of questions and off-list
> grumbling: The FAQ!
Q: Is there any way to talk you into continuing to design, or at least
describing, the long-awaited security model?
A: (Chip is a fine choice.)
-- c
At 12:50 PM -0800 3/21/05, chromatic wrote:
On Mon, 2005-03-21 at 15:39 -0500, Dan Sugalski wrote:
And, to forestall some of the wave of questions and off-list
grumbling: The FAQ!
Q: Is there any way to talk you into continuing to design, or at least
describing, the long-awaited security model?
A
On Mon, Mar 21, 2005 at 03:39:57PM -0500, Dan Sugalski wrote:
> As such, I'd like to say a big thanks to Chip Salzenburg who's agreed
> to take the hat. The perl folks on the list will recognize Chip as
> the perl 5.004 pumpking and the guy who took the first shot at "Perl:
> The Next Generation
According to Dan Sugalski:
> As such, I'd like to say a big thanks to Chip Salzenburg who's agreed
> to take the hat.
I thank you for your kind words, and for giving me the opportunity
again to work long hours and explain difficult and arbitrary design
decisions to enthusiastic contributors. :-)
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Mon, 21 Mar 2005 10:10:31 +0100
Bob Rogers <[EMAIL PROTECTED]> wrote:
> . . .
>Unfortunately, though this patch works as intended, it also has a
> number of bizarre side-effects . . .
> It's remotely conceivable that there'
14 matches
Mail list logo
