# New Ticket Created by Benjamin Goldberg
# Please include the string: [perl #130685]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=130685 >
When I type the following in the #perl6 irc channel:
m: use experimental :mac
can implement
> it...
No real change, though now you have to declare it experimental.
16:23 < [Coke]> m: use experimental :macros; macro FOO { 'say 1' }; FOO;
16:23 < camelia> rakudo-moar ce5dc0: OUTPUT«===SORRY!===Too few positionals
passed; expected 3 arguments but got 2»
--
Will "Coke" Coleda
# New Ticket Created by Alex Jakimenko
# Please include the string: [perl #125615]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=125615 >
Code:
macro FOO { 'say 1' }; FOO;
Result:
===SORRY!===
Too few positionals passed; exp
This test is actually passing. I unfudged the test with commit
https://github.com/perl6/roast/commit/e4252cd33a
This test is actually passing. I unfudged the test with commit
https://github.com/perl6/roast/commit/dc34eeacfd
# New Ticket Created by Rob Hoelz
# Please include the string: [perl #125099]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=125099 >
Following this example:
macro f() {
'1 + 1'
}
say f();
from http://des
-routines.pod
Log Message:
---
clarify that macros can't be called before they're defined
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #120928]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=120928 >
p: my %h; macro attr($key, $val) { quasi { %h{ {{{$key}}} } =
{{{$val}}} } }; attr("x",
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #118827]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=118827 >
masak: dies in the compiler:
r: say "alive"; macro assign(\a) { sub ($b is rw)
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #115604]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=115604 >
r: our macro foo() { }; foo()
rakudo 64208d: OUTPUT«===SORRY!===Error while co
On Wed, Jun 30, 2010 at 7:33 PM, Jonathan Worthington wrote:
> Aaron Sherman wrote:
>
>> See below for the S06 section I'm referring to.
>>
>> I'm wondering how we should be reading the description of user-defined
>> operators. For example, "sub infix:<(c)>" doesn't describe
>> the precedence leve
Aaron Sherman wrote:
See below for the S06 section I'm referring to.
I'm wondering how we should be reading the description of user-defined
operators. For example, "sub infix:<(c)>" doesn't describe
the precedence level of this new op, so how is it parsed? Is there a
default?
The default is
file 'EVAL_1' line 105914178
Eh? What newline? And line 105914178?
OK, so that's a bug, but the question is, should I expect it to work?
Things get a bit more strange when I try to wrap my head around macros. From
the example:
macro circumfix:«» ($text) is parsed / .*? /
> It looks like those comments in platform_limits.h are out-of-place.
> PARROT_INTVAL_MIN and PARROT_INTVAL_MAX are defined in
> include/parrot/config.h, although the definition may not be as flexible
> as the macros in perl.h that Nicholas mentioned. It might be beneficial
> to i
>> It's great to have INTVAL and UINTVAL, but without MAX_INTVAL it's kind of
>> hard to work with them in some respects. All integral typedefs should
> have
>> min/max macros. Syntax not a big deal, it can be fixed later, just don't
>> break anyth
INTVAL, but without MAX_INTVAL it's
> > kind of
> > > > hard to work with them in some respects. All integral typedefs should
> > > have
> > > > min/max macros. Syntax not a big deal, it can be fixed later, just
> > don't
> > > > break an
On Tue May 06 17:41:43 2008, coke wrote:
> On Fri Aug 03 13:43:42 2007, [EMAIL PROTECTED] wrote:
> > On Friday 03 August 2007 13:29:53 Jerry Gay wrote:
> >
> > > i'm having trouble on x86_64. when running a 32bit parrot, i get
> > > occasional deadlock at the OS level, after Parrot_exit. when runn
On Mon Jul 17 11:59:47 2006, chip wrote:
> It's great to have INTVAL and UINTVAL, but without MAX_INTVAL it's kind of
> hard to work with them in some respects. All integral typedefs should
have
> min/max macros. Syntax not a big deal, it can be fixed later, just don'
On Fri Aug 03 13:43:42 2007, [EMAIL PROTECTED] wrote:
> On Friday 03 August 2007 13:29:53 Jerry Gay wrote:
>
> > i'm having trouble on x86_64. when running a 32bit parrot, i get
> > occasional deadlock at the OS level, after Parrot_exit. when running a
> > 64bit parrot, it segfaults within Parrot_
On Sat Mar 03 09:35:05 2007, particle wrote:
> On 3/3/07, Elizabeth Mattijsen via RT [EMAIL PROTECTED]> wrote:
> > On Tue Feb 27 12:58:18 2007, particle wrote:
> > > it seems over time there have been a few handrolled
> implementations of
> > > namespace impo
lease include the string: [perl #46697]
> ># in the subject line of all future correspondence about this
issue.
> ># http://rt.perl.org/rt3/Ticket/Display.html?id=46697 >
> >
> >In src/pmc/coroutine.pmc there is the todo item:
> >
> >/* XXX put t
Ticket/Display.html?id=46697 >
In src/pmc/coroutine.pmc there is the todo item:
/* XXX put these into exceptions.h */
After this comment there are four macros. These need to be transferred
to exceptions.h and then the header used in this file.
These macros are not used, so I nuked
plementation.
Currently constants are declared as .const in PIR and .constant in PASM.
These two should be merged into one. I don't have a strong preference
but lean toward keeping .constant and deprecating .const (the full word
is generally more readable).
* comments. Lots of it.
* beginni
e .include directive
>
> +3
>
> > * .constant directive works, but I found out IMCC only allows it in PASM
> > mode. If this is desired behaviour, I have to change my implementation.
>
> Currently constants are declared as .const in PIR and .constant in PASM.
> These tw
s.h */
After this comment there are four macros. These need to be transferred
to exceptions.h and then the header used in this file.
iple heredocs, allowing to write:
.sub foo(<<'A', <<'B', <<'C')
hi
A
hi there
B
hi again
C
* A clean implementation of the .include directive
* .constant directive works, but I found out IMCC only allows it in PASM
mode. If this is desired beh
On Friday 03 August 2007 13:29:53 Jerry Gay wrote:
> i'm having trouble on x86_64. when running a 32bit parrot, i get
> occasional deadlock at the OS level, after Parrot_exit. when running a
> 64bit parrot, it segfaults within Parrot_exit, while running the exit
> handlers. if i run with -G, no se
hi, i'm a blockhead. ron reminded me that i'm not following C89, since
node was not defined at the top of a block. duh.
anyway, this doesn't seem to fix the problem. rats. i must misunderstand
the comment, because i find it hard to believe that adding these few
lines of code is enough to address a
ruct/union
src\exit.c(81) : warning C4022: 'mem_sys_free' : pointer mismatch for actual par
ameter 1
src\exit.c(82) : warning C4047: '=' : 'int' differs in levels of indirection fro
m 'handler_node_t *const '
===
huh? something must be funny in these ma
On Sun, 15 Jul 2007 23:48:54 -0500
Andy Lester <[EMAIL PROTECTED]> wrote:
> I want to document all the PARROT_XXX macros that I've been creating
> and applying, but I'm not sure where they'd be best. I don't think
> pdd07_codingstd.pod is right, because it
On Sunday 15 July 2007 21:48:54 Andy Lester wrote:
> I want to document all the PARROT_XXX macros that I've been creating
> and applying, but I'm not sure where they'd be best. I don't think
> pdd07_codingstd.pod is right, because it's not coding standard
I want to document all the PARROT_XXX macros that I've been creating
and applying, but I'm not sure where they'd be best. I don't think
pdd07_codingstd.pod is right, because it's not coding standards
exactly. I want to talk about defensive programming, and why the
The PANIC() macro used to look like this
#define PANIC(message) do_panic(interp, message, __FILE__, __LINE__)
Note how it assumes that we have an "interp" in scope. But what do
we do in src/gc/malloc.c? When we don't have an interp and want to
pass NULL to do_panic?
Of course! We #de
On 3/3/07, Elizabeth Mattijsen via RT <[EMAIL PROTECTED]> wrote:
On Tue Feb 27 12:58:18 2007, particle wrote:
> it seems over time there have been a few handrolled implementations of
> namespace import macros. they are usually named something like
> '.IMPORT' and live in
ort macros. they are usually named something like
'.IMPORT' and live in various pir source, test and example files.
i've added an import sub to F
now, which can be used in place of these various implementations.
~jerry
bj
+# printerr "\n"
+# goto loop
+#endloop:
+# printerr "\n===\n"
+# .return (mob, adverbs :flat :named)
.end
+#
+# Clear all heredoc labels
+#
+.sub clear_heredocs
+ .local pmc labels
+ .local int count, i
+ labels = get_root_global 'heredoc'
+ co
ng. Which got me thinking about more
sophisticated compile time flow control. I imagine that defining
something like a compile time switch switch statement is possible with
the existing macros. Would anyone like to take a shot at defining a
macro to do this? Is it possible to jump to something o
more
sophisticated compile time flow control. I imagine that defining
something like a compile time switch switch statement is possible with
the existing macros. Would anyone like to take a shot at defining a
macro to do this? Is it possible to jump to something outside of a
macros input that is al
On Sun, Aug 20, 2006 at 03:55:56PM -0600, Luke Palmer wrote:
> >The important question here is this one:
> >
> > - when 'uncommented', is it a no-op?
> >
> >Which isn't true for #{}/{}, because {} introduces new lexical
> >scope.
> Why would you care about introducing a new lexical scope? You wou
On 8/20/06, Luke Palmer <[EMAIL PROTECTED]> wrote:
Well, I think you are being too picky.
[snip snarky sarcastic rant]
Hmm, perhaps I'm feeling edgy. Or maybe some of the comments reminded
me of those rediculously long, whiny threads. Anyway, that was
un-called-for.
Luke
On 8/20/06, Andrew Suffield <[EMAIL PROTECTED]> wrote:
On Sun, Aug 20, 2006 at 10:50:31AM -1000, Joshua Hoblitt wrote:
> > #{
> >if $baz {
> >$foo.bar
> >}
> > }
> >
> > To uncomment, remove the # before the {.
>
> This is exactly the type of construct that I had in mind. A coupl
On Sun, Aug 20, 2006 at 10:50:31AM -1000, Joshua Hoblitt wrote:
: On Sat, Aug 19, 2006 at 02:26:28AM +, Luke Palmer wrote:
: > On 8/19/06, Aaron Crane <[EMAIL PROTECTED]> wrote:
: > >You don't actually need a macro in that case:
: > >
: > >if 0 { q<
: > >...
: > >> }
: >
: > Wh
On Sun, Aug 20, 2006 at 10:50:31AM -1000, Joshua Hoblitt wrote:
> > #{
> >if $baz {
> >$foo.bar
> >}
> > }
> >
> > To uncomment, remove the # before the {.
>
> This is exactly the type of construct that I had in mind. A couple of
> questions. Is code inside of a #{}:
>
> - p
On 8/20/06, Joshua Hoblitt <[EMAIL PROTECTED]> wrote:
This is exactly the type of construct that I had in mind. A couple of
questions. Is code inside of a #{}:
- parsed and required to be syntacticly correct?
No. It's a comment. # followed by one or more open bracket characters
creates a
On Sat, Aug 19, 2006 at 02:26:28AM +, Luke Palmer wrote:
> On 8/19/06, Aaron Crane <[EMAIL PROTECTED]> wrote:
> >You don't actually need a macro in that case:
> >
> >if 0 { q<
> >...
> >> }
>
> Which, of course, eliminates the original desire to have a
> code-commenting constru
> "Stuart Cook" schreef:
> > Larry Wall:
>
> >> if 0 {
> >> ...
> >> }
> >
> > The one disadvantage of that approach is that it will break if the
> > "commented-out" code temporarily fails to compile.
>
> How frequent does that happen?
All the time. I often comment out bits of code wh
"Stuart Cook" schreef:
> Larry Wall:
>> if 0 {
>> ...
>> }
>
> The one disadvantage of that approach is that it will break if the
> "commented-out" code temporarily fails to compile.
How frequent does that happen?
And in that case s/if 0/\#/, as Luke mentioned.
And if the compile fai
On Sat, Aug 19, 2006 at 02:26:28AM +, Luke Palmer wrote:
> On 8/19/06, Aaron Crane <[EMAIL PROTECTED]> wrote:
> >You don't actually need a macro in that case:
> >
> >if 0 { q<
> >...
> >> }
>
> Which, of course, eliminates the original desire to have a
> code-commenting constru
On 8/19/06, Aaron Crane <[EMAIL PROTECTED]> wrote:
You don't actually need a macro in that case:
if 0 { q<
...
> }
Which, of course, eliminates the original desire to have a
code-commenting construct where "you just change the 0 to a 1". After
all, we already have #{}. Incide
Stuart Cook writes:
> On 8/19/06, Larry Wall <[EMAIL PROTECTED]> wrote:
> >if 0 {
> >...
> >}
>
> The one disadvantage of that approach is that it will break if the
> "commented-out" code temporarily fails to compile. If that's a
> problem, though, you could always write your own macr
On 8/19/06, Larry Wall <[EMAIL PROTECTED]> wrote:
if 0 {
...
}
The one disadvantage of that approach is that it will break if the
"commented-out" code temporarily fails to compile. If that's a
problem, though, you could always write your own macro.
Stuart Cook
On Fri, Aug 18, 2006 at 11:58:20AM -1000, Joshua Hoblitt wrote:
: It occurred to me that other day that in our "in house" C code we
: somewhat frequently use an idiom that's not easily translated into Perl
: 5. Our rule is that if your commenting out more then 1 or 2 lines of
: code that you wrap
It occurred to me that other day that in our "in house" C code we
somewhat frequently use an idiom that's not easily translated into Perl
5. Our rule is that if your commenting out more then 1 or 2 lines of
code that you wrap it in a CPP if statement. The logic being that
if you haven't deleted t
nd of
hard to work with them in some respects. All integral typedefs should have
min/max macros. Syntax not a big deal, it can be fixed later, just don't
break anything when introducing them.
--
Chip Salzenberg <[EMAIL PROTECTED]>
Wall wrote:
: >Macros are functions or operators that are called by the compiler as
: >soon as their arguments are parsed (if not sooner). The syntactic
: >effect of a macro declaration or importation is always lexically
: >scoped, even if the name of the macro is visible elsewhere.
Hi,
I've read and reread the macro explanation but I'm still not entirely
clear on number of things. The questions and thoughts below are based
on my (mis)understanding.
On 03/02/06 02:05, Larry Wall wrote:
Macros are functions or operators that are called by the compiler as
After a little more cleanup, S06 now reads:
=head2 Macros
Macros are functions or operators that are called by the compiler as
soon as their arguments are parsed (if not sooner). The syntactic
effect of a macro declaration or importation is always lexically
scoped, even if
e would also like a quasiquoting mechanism, so don't have to rely on
: string concatenation, and we don't have to construct parse trees by
: hand. It's sort of a happy medium. But that is as yet unspecced.
S06 now sez:
+=head2 Macros
+Macros are functions or operators that are call
On Sun, Jan 29, 2006 at 20:29:43 +, Herbert Snorrason wrote:
> On 29/01/06, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> > Basically the plan is that when an internal AST language is decided
> > upon, the macros will be able to get either the source code text, or
> >
On 29/01/06, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> Basically the plan is that when an internal AST language is decided
> upon, the macros will be able to get either the source code text, or
> an AST.
Two things. First, if the AST path is taken, doesn't that mean that
the AS
On 1/29/06, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> Aside from that they are normal perl 6 subroutines, that simply get
> invoked during compile time instead of during runtime.
With one extra "feature". By default (my preference) or with a trait,
parameters can get passed in as ASTs instead of
On Sun, Jan 29, 2006 at 18:53:25 +, Herbert Snorrason wrote:
> Perl6 will have macros. Good. Cool. But, sadly, that seems to be close
> to the most specific thing anyone says about the subject. There is
> some further discussion in Apocalypse & Exegesis 6, but nothing in t
Perl6 will have macros. Good. Cool. But, sadly, that seems to be close
to the most specific thing anyone says about the subject. There is
some further discussion in Apocalypse & Exegesis 6, but nothing in the
Synopsis.
Now, considering that macros are a language feature and that the
Synopses
We were struggling with some memory corruption seen mainly in tcl [1]
since quite a time.
I think, I've found it now, thanks to an example Matt has pasted this
morning.
The reason is:
- there is a hard limit of 256 macros
- this was marked with XXX but *not checked*
- each .include
On Mon, Dec 12, 2005 at 11:14:32AM -0800, Chip Salzenberg wrote:
: I still think heredocs were a botch for
: Perl, which is generally not line-oriented.
Hmm, well, the point is not so much whether Perl is line-oriented,
but whether the *data* is line-oriented. The orientation of Perl
is to go the
remove conditionals around existing code.
Forbidding commas as macros are defined is to be expected. The biggest
issue with commas that I've seen is that inside a comment, the commas
are not commented out in regards to parsing the macro. Escaped commas
wouldn't necessarily be a h
On Mon, 2005-12-12 at 10:55 -0800, Chip Salzenberg wrote:
> Forbidding commas in the expanded code is not OK
So why not treat the comma as a delimiter only when either
(1) It is on the same line as the start of the macro call, or
(2) it appears alone on a line.
The same rule can apply for the c
On Mon, Dec 12, 2005 at 02:07:41PM -0500, Will Coleda wrote:
> On Dec 12, 2005, at 1:55 PM, Chip Salzenberg wrote:
> >So I guess we just need a robust multi-line quoting convention (to
> >pass multiple lines of code to macros).
>
> That sounds suspiciously like a HE
So I guess we just need a robust multi-line quoting convention (to
pass multiple lines of code to macros).
That sounds suspiciously like a HEREDOC.
See: http://rt.perl.org/rt3/Ticket/Display.html?id=37600, which was
marked as rejected.
(Musing while typing:) How
about using braces as bal
I guess we just need a robust multi-line quoting convention (to
pass multiple lines of code to macros). (Musing while typing:) How
about using braces as balanced delimeters when an open brace is the
first character:
.IfDebug(1, {
multi,line
stuff,with,comma
On Dec 11, 2005, at 23:45, Joshua Isom wrote:
It could be very beneficial for debugging. My debugger tends to be a
lot of print statements, so something like
.globalconst int DEBUG = 1
.macro IfDebug(level, code)
unless .level >= DEBUG goto .$endif
.code
.local $endif
M, Leopold Toetsch wrote:
On Dec 11, 2005, at 0:53, Joshua Isom wrote:
Since it's not documented at all that I've seen, either for or
against, I'm wondering what's the arguments to macros are supposed to
be. Consider this code.
.sub main :main
.IfElse(TRUE,
On Dec 11, 2005, at 0:53, Joshua Isom wrote:
Since it's not documented at all that I've seen, either for or
against, I'm wondering what's the arguments to macros are supposed to
be. Consider this code.
.sub main :main
.IfElse(TRUE,
print "True\n"
Since it's not documented at all that I've seen, either for or against,
I'm wondering what's the arguments to macros are supposed to be.
Consider this code.
--
.const int TRUE = 1
.const int FALSE = 0
.macro IfElse(conditional, foo, bar)
unless .con
On Mon, Jun 13, 2005 at 05:25:59PM +0200, Ingo Blechschmidt wrote:
: just checking: Are anonymous macros allowed?
I have no problem with macros being first-class objects during
the compile. Though the macro itself may have a problem with your
passing it '3' when it is likely expect
Hi,
just checking: Are anonymous macros allowed?
my $macro = macro ($x) { "100$x" };
say $macro(3); # 1003
Of course, anonymous macros can't be called at compile-time, like normal
macros:
my $macro = rand < 0.5
?? macro ($x) { "100$x" }
:: macro ($x)
William Coleda <[EMAIL PROTECTED]> wrote:
> Ah. That would explain why I had to back in and delete the file that I
> had already deleted - because I deleted the wrong file!
Ok. But:
> Leopold Toetsch wrote:
>> $ perl tools/dev/manicheck.pl
>>
>> doesn't complain at all.
leo
Ah. That would explain why I had to back in and delete the file that I had
already deleted - because I deleted the wrong file!
Fixed.
Leopold Toetsch wrote:
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
--- trunk/MANIFEST (original)
+++ trunk/MANIFEST Tue Apr 19 16:51:10 2005
@@ -50,7 +5
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> --- trunk/MANIFEST(original)
> +++ trunk/MANIFESTTue Apr 19 16:51:10 2005
>@@ -50,7 +50,6 @@
> -classes/boolean.pmc []
I don't understand this change to MANIFEST. classes/boolean.pmc is for
sure used, but
$ p
On Fri, Apr 15, 2005 at 12:45:14PM +1200, Sam Vilain wrote:
: Larry Wall wrote:
: > Well, only if you stick to a standard dialect. As soon as you start
: > defining your own macros, it gets a little trickier.
:
: Interesting, I hadn't considered that.
:
: Having a quick browse thro
Larry Wall wrote:
(B> Well, only if you stick to a standard dialect. As soon as you start
(B> defining your own macros, it gets a little trickier.
(B
(BInteresting, I hadn't considered that.
(B
(BHaving a quick browse through some of the discussions about macros, many
(Bof the m
Gabe Schaffer <[EMAIL PROTECTED]> wrote:
> That's no problem except where a given COND can be either signalled or
> broadcast to.
Such issues need good comments in source code. Does that imply that we
need:
COND_INIT_SIGNAL
COND_INIT_BROADCAST
> GNS
leo
On Sun, 21 Nov 2004 10:09:06 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Gabe Schaffer <[EMAIL PROTECTED]> wrote:
> Currently we have COND only for the task queues. But if we need
> conditions in other places, QUEUE_CONDITION is misleading.
> So the current se
have COND only for the task queues. But if we need
conditions in other places, QUEUE_CONDITION is misleading.
So the current set of macros for existing stuff is ok?
> Also, note that with Win32 conditions you must indicate at creation
> time whether you want to Signal or Broadcast. Emulat
eeded for windows. OTOH a mutex aka critical section is needed
separatly.
So we should probably define these macros to be:
COND_INIT(c, m)
COND_DESTROY(c, m)
see src/tsq.c for usage.
Does win32 require more info to create conditions/mutexes or would these
macros suffice?
Win32 doesn't requir
second step, which isn't
needed for windows. OTOH a mutex aka critical section is needed
separatly.
So we should probably define these macros to be:
COND_INIT(c, m)
COND_DESTROY(c, m)
see src/tsq.c for usage.
Does win32 require more info to create conditions/mutexes or would these
macr
ded for windows. OTOH a mutex aka critical section is needed
> separatly.
>
> So we should probably define these macros to be:
>
> COND_INIT(c, m)
> COND_DESTROY(c, m)
>
> see src/tsq.c for usage.
>
> Does win32 require more info to create conditions/mutexes or wo
COND_INIT macro just passes a
condition location, the mutex is created in a second step, which isn't
needed for windows. OTOH a mutex aka critical section is needed
separatly.
So we should probably define these macros to be:
COND_INIT(c, m)
COND_DESTROY(c, m)
see src/tsq.c for usage.
Doe
William Coleda <[EMAIL PROTECTED]> wrote:
> Though I have to wonder how this will work with inter-language-operability.
bool = istrue(some_pmc)
is exactly that. Your PMC can answer 1 if it's "true" or such. A
lispish PMC might evaluate "t" and "nil"...
> Thanks, Leo.
Welcome,
leo
Danke. Making this a macro was, at least, a step up from the function call I had.
I haven't done anything real with the PMCs yet (just cargo-culted them mostly from
their Perl* counterparts)
Though I have to wonder how this will work with inter-language-operability.
Thanks, Leo.
Leopold Toetsch wr
Will Coleda <[EMAIL PROTECTED]> wrote:
>
> Given a pmc, set a register to indicate whether
> it is true or false from Tcl's POV.
inline op istrue(out INT, in PMC) {
with an approprate get_bool() vtable slot.
leo
Leopold Toetsch wrote:
.macro swapP (A,B)
$P0 = .A
.A = .B
.B = $P0
.endm
(untested)
Seems to work, thanks.
*But* we have an opcode called *exchange* ... It's even JITted on i386.
This was just an example. Thanks.
leo
specifying the TEMP
parameter? For example, something like:
.macro swap (A,B)
.local pmc .TEMP
.local inside macros creates a local *label*.
As the macro arguments could be any kind of register, the macro can't
have the TEMP hidden inside. If you are gonna swap PMCs only, you could
write
gensym, hehe. History repeats ;-)
- Michael
On Thu, 07 Oct 2004 21:49:22 -0400, William Coleda <[EMAIL PROTECTED]> wrote:
> A macro example in the docs shows:
>
> .macro swap (A,B,TEMP) # . marks the directive
> set .TEMP,.A # . marks the special variable.
> set .A,.B
> se
btw, thanks to whoever fixed macros so that they could be defined outside of .sub's.
Very handy.
A macro example in the docs shows:
.macro swap (A,B,TEMP) # . marks the directive
set .TEMP,.A # . marks the special variable.
set .A,.B
set .B,.TEMP
.endm # And . marks the end of the macro.
Is there a way to write this macro without specifying the TEMP paramete
Gordon Henriksen (via RT) wrote:
PMC accessor macros come in a bewildering variety of forms, depend upon
one another, are scattered throughout pobj.h, are generally difficult to
decipher.
[ snip ]
This patch defines yet another set of accessor macros, but these have a
consistent naming
At 08:58 AM 1/9/2004 +0100, Leopold Toetsch wrote:
Melvin Smith <[EMAIL PROTECTED]> wrote:
> This also means .pasm files won't be able to .include these anymore,
> you'd have to use IMC.
Why not just make .const work in both modes?
Because pure PASM doesn't currently use type names.
.const expects
Melvin Smith <[EMAIL PROTECTED]> wrote:
> This also means .pasm files won't be able to .include these anymore,
> you'd have to use IMC.
Why not just make .const work in both modes?
> -Melvin
leo
Since all of the Parrot includes are .pasm and are using the old .constant
directive, which was a macro expansion in the IMCC lexer, and
I've removed macros from IMCC, I have a pending patch to
parrot_include.pl and all of the parrot header files to change it to generate
.imc include files r
1 - 100 of 218 matches
Mail list logo
