Jeff Horwitz wrote:
On Mon, 14 Mar 2005, William Coleda wrote:
How does one call a PIR-defined sub from C?
use the Parrot_call_sub_* API.
Ah, thank you, much better.
Now, given the perldoc for src/extend.c,
"void* Parrot_call_sub(Parrot_INTERP interpreter, Parrot_PMC sub, const
cha
On Mon, 2005-03-14 at 22:38 -0500, Bob Rogers 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
> ...
>
> But it's no
On Mon, 14 Mar 2005, William Coleda wrote:
> How does one call a PIR-defined sub from C?
use the Parrot_call_sub_* API.
> My current best guess is, to invoke the PIR sub "Tcl::Joe":
>
> PMC *invokeme;
> STRING *Tcl,*joe;
> Tcl = string_from_const_cstring(INTERP, "Tcl", 3);
>
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Mon, 14 Mar 2005 14:02:30 +0100
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Syntax proposal:
>.sub foo @MULTI
> .invocant Integer a
> .invocant Float b
> .param pmc c
> ...
Alternate syntax:
How does one call a PIR-defined sub from C?
My current best guess is, to invoke the PIR sub "Tcl::Joe":
PMC *invokeme;
STRING *Tcl,*joe;
Tcl = string_from_const_cstring(INTERP, "Tcl", 3);
joe = string_from_const_cstring(INTERP, "joe", 3);
invokeme = Parrot_find_global(INTER
Dave Whipp via RT wrote:
> Matt Diephouse wrote:
>
>>There's no real point in having a plan if you don't follow it,
>
>
> That sounds a bit naive. The benefit of a plan is primarily in the act
> of making it (it forces you to think about what you want to do). The
> secondary benefit comes when
Matt Diephouse wrote:
There's no real point in having a plan if you don't follow it,
That sounds a bit naive. The benefit of a plan is primarily in the act
of making it (it forces you to think about what you want to do). The
secondary benefit comes when you track how actual progress deviates from
Will Coleda <[EMAIL PROTECTED]> wrote:
> Can I say again that I think it's cheating that python has tests directly in
> t/ , so leo notices breakage there sooner? =-)
Feel free to cheat and append tcl tests to "make test".
> Attached is a patch that allows "(cd languages/tcl && make test)" to wo
The archives have tons of articels regarding namespaces, mostly HLL
policies and such, but little about Parrot semantics.
I've started a new test file t/pmc/namespace.t that summarizes some of
the current possibilities of namespace manipulation with Parrot.
Please have a look at the supported s
On Mon, 2005-03-14 at 14:02 +0100, Leopold Toetsch 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,
# New Ticket Created by Will Coleda
# Please include the string: [perl #34430]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=34430 >
Can I say again that I think it's cheating that python has tests directly in
t/ , so le
"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
.param pmc b
.param pmc c
I
Leopold Toetsch wrote:
> The test could include C< 0? >.
>> +$err_msg =~ s/\r//g;
Could you please provide one patch for items like above, thanks.
TortoiseCVS patch file attached.
S pozdravem Michal Jurosz
Index: imcc/t/imcpasm/opt1.t
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
.param pmc b
.param pmc c
I'm now more inclined towa
Rod Adams <[EMAIL PROTECTED]> wrote:
> While that's a nice feature to have in general, I feel better about
> going ahead and predefining that the builtins are already members of
> Num, Str, Array, Hash for the shear performance and documentation values
> of it.
That's exactly the plan, when it co
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch via RT írta:
>>Strange anyway. Folks reported that MinGW builds Parrot 0.1.2 ok.
> What can I say? Not for me. Not for me. Maybe they did not report their
> extra efforts to make it work?
Yeah, seems so. Can MinGW users please come u
Matt Diephouse <[EMAIL PROTECTED]> wrote:
> I've marked this ticket as such in RT, but I'd like to suggest that
> these TODO items become *requirements* for releases, and not "desired
> goals". There's no real point in having a plan if you don't follow it,
> and this could provide some direction (
17 matches
Mail list logo
