> 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
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]>
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
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 Mon, 22 Nov 2004 10:01:42 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> 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
> nee
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
> Parrot's locks will all have wait/signal/broadcast capabilities. We
> should go rename the macros and rejig the code. This may have to wait
Really? I'm not sure I understand what broadcast does on a lock. Are
you talking about something like P5's condpair? If so, why not j
On Fri, 19 Nov 2004 15:35:44 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Gabe Schaffer wrote:
> > Win32 doesn't require anything else, but I don't think I like this
> > idea. If you do COND_INIT(c, m) and Win32 ignores the 'm', what
> > happens when some code goes to LOCK(m)? It would work
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
As planned, macros have been removed from IMCC.
The downside is that this just revealed scads of instances
where people were using macro expansion in the tests,
especially the .constant directive.
One particular problem is runtime/parrot/include/*.pasm
These will need to be changed to .imc files
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> When a macro contains a '.sub' call, and that macro is used twice, then I get
> a 'memory error'.
Confirmed. The segfault is in expand_pcc_sub_call(), the "sub" SymReg is
NULL on the second expansion.
> How can I tell 'parrot' to dump a core file?
acro_used_twice.imc
Speicherzugriffsfehler
Could sombody test the attached script on another machine?
I'm working here on a Linux laptop:
Two answers here.
1) We probably have a bug in macro expansion
2) Dan has declared that macros are coming out of IMCC. (Mainly because I
told him
I don't
Bernhard Schmalhofer wrote:
Hi,
Could sombody test the attached script on another machine?
I'm working here on a Linux laptop:
I am geting a seg fault. Its fine when the second call is commented out.
I am not sure if any of the following is any use to you.
The follwoing PASM was part generated f
Hi,
I have been playing around with 'libpcre' for Parrot m4.
For some reason I couldn't compile two regular expressions in the same
PIR script.
I created a sample C program and that worked like it should.
It looks like the error has nothing to do with 'libpcre'. So I boiled down
my code to a sma
At 06:06 PM 12/11/2003 -0500, Dan Sugalski wrote:
Folks,
As IMCC's in some flux and likely to get gutted and reworked, the question
of macros has come up. (They cause some grammar issues) So, to make life
easier:
Parrot's built-in PIR and PASM parsing modules do *not* need to
Folks,
As IMCC's in some flux and likely to get gutted and reworked, the
question of macros has come up. (They cause some grammar issues) So,
to make life easier:
Parrot's built-in PIR and PASM parsing modules do *not* need to do
macros. (Though they do need to do .const thin
On Oct 16, 2003, at 7:21 AM, Dan Sugalski wrote:
On Thu, 16 Oct 2003, Leopold Toetsch wrote:
Juergen Boemmels <[EMAIL PROTECTED]> wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
The IMCC_INFO does not need to be part of the interpreter.
I don't like to have global state variables around. I do
Melvin Smith <[EMAIL PROTECTED]> wrote:
> I don't like the idea of IMCC becoming so tightly coupled with the
> interpreter. I still wish to be able to build it standalone. Hopefully
> we can keep this in mind going forward.
IMCC_INFO is a macro, easily changable. But building it standalone would
At 10:21 AM 10/16/2003 -0400, Dan Sugalski wrote:
On Thu, 16 Oct 2003, Leopold Toetsch wrote:
> Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> > Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
> > The IMCC_INFO does not need to be part of the interpreter.
>
> I don't like to have global state variabl
On Thu, 16 Oct 2003, Leopold Toetsch wrote:
> Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> > Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
> > The IMCC_INFO does not need to be part of the interpreter.
>
> I don't like to have global state variables around. I don't know yet,
> what happens if 2 i
Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
> The IMCC_INFO does not need to be part of the interpreter.
I don't like to have global state variables around. I don't know yet,
what happens if 2 interpreter threads both do eval()...
>> It will be repla
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> JüRgen" "BöMmels <[EMAIL PROTECTED]> wrote:
>
> > There are still some things to do:
> > - a global hash is still not totally right. It should be moved to the
> > interpreter structure
>
> As D
JüRgen" "BöMmels <[EMAIL PROTECTED]> wrote:
> There are still some things to do:
> - a global hash is still not totally right. It should be moved to the
> interpreter structure
As Dan already outlined, macros should have some limited scope, probably
per file. So cur
On Wed, 15 Oct 2003, Jürgen Bömmels wrote:
> There are still some things to do:
> - a global hash is still not totally right. It should be moved to the
> interpreter structure
Nope. The macro hash should be per-compilation-unit, not global in any
way. It should go away when compilation is done.
the macro_table as a static preallocated array of fixed
size and used a linear search for lookup. Now I have took the time and
transformed it to use a HASH.
The macros are now stored in a global HASH named macro_hash. They are
indexed by their name. So the lookup of a macro is a simple hash_
e macro def above shows that
> parrot doesn't like this arrangement.
Dunno, what your symbol C is. It ought to be a
subroutine PMC. Its not a label.
Please have a look at library/{pcre.imc,libpcre.imc}
where macros and PCC subs are working together, very similar to your
example.
>
I have a PCC sub:
.pcc_sub _char_is_white_space prototyped
.param int c # Character to test (as an integer representing its ASCII
code)
Leopold Toetsch wrote:
Direct access to vtable may only be used .ops files,
s/\.ops/in .ops and .pmc/
Sorry,
leo
Benjamin Goldberg wrote:
Maybe someone should write a script like this:
Then run it on all the code, except that which actually defines the
VTABLE_ macros.
Direct access to vtable may only be used .ops files, where a similar
substitions is done by ops2c.pl. Changing the opsfiles needs adaption
tually defines the
VTABLE_ macros.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
out names like INT_REG were being used both as C macros,
_and_ as .jit syntax. It seemed worth disambiguating these two.
The annoyingly long REGISTER_INT was the best I came up with.
(2) The macros are argument-less. REGISTER_INT vs REG_INT(n).
So the normal usage looks like REGISTER_IN
On Wed, 2003-05-28 at 11:13, Clinton A. Pierce wrote:
> >
> >Is there is reason not to s/\.constant/.const/g for consistency's sake?
>
> And actually, on further consideration, .const isn't what I want
> either.
Which doesn't invalidate my question. :-)
--
Bryan C. Warnock
bwarnock@(gtemail
Clinton A. Pierce <[EMAIL PROTECTED]> wrote:
> And actually, on further consideration, .const isn't what I want
> either.
You are looking vor .sym/.local:
.local PerlHash BASICARR
.sub _main
BASICARR = new PerlHash
.arg "value"
.arg "x"
call _DIMENSION
.ar
At 11:13 AM 5/28/2003 -0400, Clinton A. Pierce wrote:
# These are vastly simplified, but give you the idea
And of course, by "vastly simplified" I meant "completely wrong" because
the sample shown won't work because of the saveall and restoreall before
and after the array creation in _DIMENSION.
At 05:45 PM 5/27/2003 -0400, you wrote:
On Tue, 2003-05-27 at 08:01, Clinton A. Pierce wrote:
> At 11:57 PM 5/26/2003 -0400, Will Coleda wrote:
> >Perhaps "macros only work in assembler mode" is the issue?
> >
> >http://www.mail-archive.com/[EMAIL PROTECTED]/msg14
Bryan C. Warnock <[EMAIL PROTECTED]> wrote:
> Is there is reason not to s/\.constant/.const/g for consistency's sake?
The difference is, that PASM did define an untyped variant:
.constant FOO 42
PIR Syntax is:
.const int FOO = 42
I'm ok with tossing the PASM variant, its barely used (only
On Tue, 2003-05-27 at 08:01, Clinton A. Pierce wrote:
> At 11:57 PM 5/26/2003 -0400, Will Coleda wrote:
> >Perhaps "macros only work in assembler mode" is the issue?
> >
> >http://www.mail-archive.com/[EMAIL PROTECTED]/msg14107.html
> >
> >Regards.
>
Dan Sugalski wrote:
While I'm all for the macros (yeah, I know, debugger stepping issues and
all) I'd rather this be:
VTABLE_getprop(...
Done.
Attached is the new variant.
leo
--- parrot/lib/Parrot/Vtable.pm Fri Jun 21 21:00:02 2002
+++ parrot-leo/lib/Parrot/Vtable.pm Mon Ma
On Sunday, March 23, 2003, at 07:15 PM, Leopold Toetsch wrote:
Dan Sugalski wrote:
While I'm all for the macros (yeah, I know, debugger stepping issues
and all)
I don't get that. What debugger issues? I changed some vtable calls in
the iterator code and didn't see any dif
Dan Sugalski wrote:
While I'm all for the macros (yeah, I know, debugger stepping issues and
all)
I don't get that. What debugger issues? I changed some vtable calls in
the iterator code and didn't see any differences during debugging. The
macros just rearange the or
) SELF->data, key);
}
While I'm all for the macros (yeah, I know, debugger stepping issues
and all) I'd rather this be:
VTABLE_getprop(...
rather than
VTABLE_1(getprop,...
because the latter form doesn't give us much of a boost when put
getprop behind a layer of
Jason Gloudon wrote:
On Sun, Mar 23, 2003 at 03:54:21PM +0100, Leopold Toetsch wrote:
Not really, but I don't see, how this set of macros would influence
debugging negatively.
You can't step through the expanded code for a macro in the debugger.
There is no expanded code, its jus
Leopold Toetsch wrote:
This is a first step in hiding vtable functions - not only: Using these
macros also provides more readable source files:
While just talking about vtable functions:
- we currently have 259
- 140 of these are some _keyed variants only get/set_{type}_keyed and
defined
On Sun, Mar 23, 2003 at 03:54:21PM +0100, Leopold Toetsch wrote:
> Not really, but I don't see, how this set of macros would influence
> debugging negatively.
You can't step through the expanded code for a macro in the debugger.
--
Jason
Nicholas Clark wrote:
On Sun, Mar 23, 2003 at 11:11:54AM +0100, Leopold Toetsch wrote:
This is a first step in hiding vtable functions - not only: Using these
macros also provides more readable source files:
return VTABLE_1(getprop, (PMC*) SELF->data, key);
..., and
make it easy to cha
On Sun, Mar 23, 2003 at 11:11:54AM +0100, Leopold Toetsch wrote:
> This is a first step in hiding vtable functions - not only: Using these
> macros also provides more readable source files:
>
> instead of:
>
>PMC* getprop (STRING* key) {
> return ((PMC *)SELF-&g
This is a first step in hiding vtable functions - not only: Using these
macros also provides more readable source files:
instead of:
PMC* getprop (STRING* key) {
return ((PMC *)SELF->data)->vtable->getprop(INTERP,
(PMC *)SELF->data, key);
}
this now
Jürgen Bömmels (via RT) wrote:
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #21277]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=21277 >
Hello,
Here is an extension to my first macro suppor
t;*>[ISNP]{DIGIT}{DIGIT}? {
valp->s = str_dup(yytext);
return REG;
}
@@ -182,6 +181,37 @@
return read_macro(valp, interp);
}
+".macro" {
+fataly (EX_SOFTWARE, "", line, "Macros only allowed in assembly mode");
+}
+
+".cons
1 - 100 of 149 matches
Mail list logo
