Bob Rogers <[EMAIL PROTECTED]> wrote:
> What if one wants the first and third arguments to be the invocants?
> Then the first syntax gives
>.sub foo @MULTI
> .invocant Integer a
> .param pmc b
> .invocant String c
That should better be
>.sub foo @MULTI
François" PERRAD <[EMAIL PROTECTED]> wrote:
> -win32-mingw
> +win32-mingw-gcc3.2.3 YYY - - YY/7 20050307
Just 7 failing can't be quite right, when all tests are failing that
used dynamic loading.
leo
Rod Adams <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>>the method call in PIR can be written as:
>>
>> d = x."cos"() # normal method call
>> d = Float."cos"(x) # class method, argument shifted down
>> d = P6Num."cos"(x) # same
>> d = cos x # PIR opcode s
William Coleda <[EMAIL PROTECTED]> wrote:
> If only the first character is the return value, how does one deal
> with subroutines that return multiple values?
Well, you can't access multiple return values from within the C
function, where you are calling the PIR code. OTOH, if the PIR code did
r
Hi,
I have been adding a PIR implementation and three 'Hello World' tests to
'languages/parrot_compiler'.
Code is taken from STDIN, compiled by a builtin compiler, and the resulting
Eval PMC
is invoked. This works as expected for PASM and PIR.
For PAST, Parrot abstract syntax tree as simple text,
Will Coleda <[EMAIL PROTECTED]> wrote:
> Attached is a patch that allows "(cd languages/tcl && make test)" to work
> again. Looks like an unguarded access in MRO. Didn't self apply so Leo could
> poke at it, in case the tcl pmcs are exploiting a hole in pmc2c2.pl.
The C is defined as an abstract
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 is stored:
.namespace ["Foo"]
.sub bar
Michal Jurosz <[EMAIL PROTECTED]> wrote:
> TortoiseCVS patch file attached.
> SKIP: {
[ ... ]
> -}
Please always test your patches.
Thanks, applied.
leo
> # --- Some other ideas: ---
> $ perl -e "print $^O"
> msys
> --- config\init\hints.pl
> sub runstep {
> + my $O = lc($^O);
> + $O = 'mswin32' if $O =~ /^(msys|mingw)/;
> - my $hints = "config/init/hints/" . lc($^O) . ".pl";
> + my $hints = "config/init/hints/" . $O . ".pl";
This would make M
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 Makefile needs /, and the execution needs \)
The bug can
François PERRAD wrote:
When I follow the instructions what I've published in parrot/README.win32,
the builded perl program gives :
$ perl -e "print $^O"
MSWin32
For me, mingw is not a platform (MSWin32 and cygwin are a platform),
just the GCC compiler under MSWin32.
$mingw
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> Hi,
> ./parrot languages/parrot_compiler/parrot_compiler.pbc --language=PAST <
> languages/parrot_compiler/t/basic/hello_3.code
> Calling 'parrot_compiler.pbc' seems to print the generated PASM code
Yes. When you run the .imc version of the pro
François PERRAD <[EMAIL PROTECTED]> wrote:
> For me, mingw is not a platform (MSWin32 and cygwin are a platform), just
> the GCC compiler under MSWin32.
> $mingw = ($^O eq 'MSWin32' and $Config{cc} eq 'gcc')
> So, the case $is_mingw in config/init/hints/mswin32.pl is the good way to
> ha
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #34441]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=34441 >
Hi,
there are a lot of potentially confusing targets in the main Makefile.
In
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #34442]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=34442 >
This was mentioned by Leo in Ticket 34934 and 30230:
> Oh well, while at it, t
Switching tclobject seems to work fine here. I suspect you might have something
else going on.
Committed the change to tclobject, removed my local hack to src/pmc.c, passes
100% now.
Regards.
Leopold Toetsch wrote:
Will Coleda <[EMAIL PROTECTED]> wrote:
Attached is a patch that allows "(cd langu
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Tue, 15 Mar 2005 08:52:38 +0100
Bob Rogers <[EMAIL PROTECTED]> wrote:
> What if one wants the first and third arguments to be the invocants?
> Then the first syntax gives
>.sub foo @MULTI
> .invocant Integer a
Bernhard Schmalhofer (via RT) wrote:
there are a lot of potentially confusing targets in the main Makefile.
In order to simply the Makefile, I propose to remove the 'imcc' targets.
Does anybody care for these targets?
I don't
test_imcc: Run the test suite only for IMCC tests.
tes
Bernhard Schmalhofer (via RT) wrote:
This was mentioned by Leo in Ticket 34934 and 30230:
Oh well, while at it, the *BooleanArray should just use one bit per item
not an INTVAL.
I'll tackle that. First I'll propable take a look at Bit::Vector in Perl5,
as there are propably a lot of interesting m
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(Integer, Float)
> .param pmc a
>
Bob Rogers <[EMAIL PROTECTED]> wrote:
>From: Leopold Toetsch <[EMAIL PROTECTED]>
>.sub foo multi(Integer, pmc: String)
> .param pmc a
> .param pmc b
> .param pmc c
>- try to dispatch on the first two types in the first place
>- if there is a tie,
William Coleda <[EMAIL PROTECTED]> wrote:
> Switching tclobject seems to work fine here. I suspect you might have
> something else going on.
I don't have any diffs WRT CVS. Strange.
leo
22 matches
Mail list logo