[perl #17817] [PATCH] Parrot_sprintf-related stuff, part 2
# New Ticket Created by Brent Dax
# Please include the string: [perl #17817]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17817 >
Inspiration struck me as I was working on bug fixes for Parrot_sprintf's
patch yesterday. One of my long-term goals with Parrot_sprintf was to
use it as the engine for a Parrot bytecode-level sprintf opcode, but I
didn't think that would be possible without duplicating the code in two
different files with different versions of the same macros wrapping
accesses to the arglist. Obviously, this is a Bad Thing, so I just let
my mind crunch on it a while.
Until today, when I realized the solution that had been staring me in
the face all along.
The answer was vtables. A specialized vtable wrapping argument accesses
would mean one version of the formatting code, but two different
behaviors! Excited, I set to rewriting Parrot_sprintf--*again*--to use
this idea.
Along the way, %S went the way of %P (you should now use %Ss to insert a
STRING*, but %S will still work), two new opcodes got added, and I
managed to remove several restrictions on strings that I had imposed on
myself by using C strings internally instead of Parrot ones. The result
(I hope) is better, faster, and stronger than the original.
When misc.c reached around a thousand lines, I decided it was becoming
unmanageable, so I split misc.c into three files. Misc.c contains the
public "wrapper" functions around the core formatter, spf_render.c
contains the formatter and some utility functions, and spf_vtable.c
contains the two vtables used to make Parrot_sprintf work.
With all this moving around of code, the patch size became completely
unmanageable--nearly 150 KB--so the attached patch is gzipped (yes,
Windows users, WinZip and WinRAR will handle it). It should be applied
against a freshly checked-out copy of Parrot--it includes all the
semantic and ancillary modifications of yesterday's patch.
All tests pass on Windows and Cygwin.
Share and enjoy,
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/39439/32005/c5bf0d/patch.txt.gz
patch.txt.gz
Description: patch.txt.gz
perl6 regexpisms seen in the wild
Maybe of interest to some, probably of no interest to most, but this is the first time I've noticed the use of a perl6 regexp flag in the wild. Or however "wild" #london.pm on IRC passes for: Trelane: not really - I think I spent longer debugger +WWW::UsePerl::Journal than I meant to /ger/ging/ :2nd So they are useful :-) (and people will come to use them, and presumably perl6, as they discover that it's more powerful than their current chainsaw. We already assume that, but it's reassuring to find anecdotal evidence that backs it up) Nicholas Clark
Re: [perl #17817] [PATCH] Parrot_sprintf-related stuff, part 2
On Wed, 9 Oct 2002, Brent Dax wrote:
[Brent continues to churn out amazing quantities of good stuff]
Overall, it continues to look very good. Unfortunately, the compact-looking
ch=va_arg((va_list)obj->data, char);
gave Sun's compiler indigestion. I had to split it up into the much
more pedestrian
va_list arg;
arg = (va_list) obj->data;
ch = va_arg(arg, char);
I hope that doesn't cause any problems. I also removed two harmless but
extraneous \ from the ends of lines, and added a newline to the end.
With the little patch below, I still get two test failures. The first is
from t/src/sprintf_1.c. I'll look at this when I can (probably tomorrow)
but in the meantime, here's the debugger output:
(dbx) run
Running: sprintf_1
(process id 17453)
Hello, Parrot!
PerlHash[0x100]
PerlHash[0x100]
Hello, Pa!
Hello, Hello, Pa!
signal BUS (invalid address alignment) in getint_va at line 62 in file "spf_vtable.c"
62 return (HUGEINTVAL)(INTVAL)(pmc->vtable->get_integer(interpreter,
pmc));
(dbx) where
=>[1] getint_va(interpreter = 0x172388, size = 6LL, obj = 0xffbef848), line 62 in
"spf_vtable.c"
[2] Parrot_sprintf_format(interpreter = 0x172388, pat = 0x18f558, obj = 0xffbef848),
line 452 in "spf_render.c"
[3] Parrot_vsprintf_s(interpreter = 0x172388, pat = 0x18f558, args = 0xffbef994),
line 41 in "misc.c"
[4] Parrot_vsprintf_c(interpreter = 0x172388, pat = 0xfc554 "%d = %Pd\n", args =
0xffbef994), line 51 in "misc.c"
[5] Parrot_sprintf_c(interpreter = 0x172388, pat = 0xfc554 "%d = %Pd\n", ...), line
103 in "misc.c"
[6] main(argc = 1, argv = 0xffbefa24), line 28 in "try.c"
(dbx)
The second failure is t/op/interp_2. Here's the debugger output on that one:
Again, I'll look into this in the next day or so.
$ ./parrot t/op/interp_2.pbc
ok 1
Segmentation Fault(coredump)
/home/doughera/src/parrot/parrot-andy>dbx parrot core
Reading symbolic information for parrot
core file header read successfully
Reading symbolic information for rtld /usr/lib/ld.so.1
dbx: program is not active
Reading symbolic information for libsocket.so.1
Reading symbolic information for libnsl.so.1
Reading symbolic information for libdl.so.1
Reading symbolic information for libc.so.1
Reading symbolic information for libmp.so.2
Reading symbolic information for libc_psr.so.1
program terminated by signal SEGV (no mapping at the fault address)
Current function is getstring_va
124 return cstr2pstr(cstr);
(dbx) where
[1] strlen(0x0, 0x0, 0x11, 0x7efefeff, 0x81010100, 0x17b8db), at 0xff1b3144
=>[2] getstring_va(interpreter = 0x175fa8, size = 0, obj = 0xffbef5c8), line 124 in
"spf_vtable.c"
[3] Parrot_sprintf_format(interpreter = 0x175fa8, pat = 0x194338, obj = 0xffbef5c8),
line 552 in
"spf_render.c"
[4] Parrot_vsprintf_s(interpreter = 0x175fa8, pat = 0x194338, args = 0xffbef71c),
line 41 in
"misc.c"
[5] Parrot_vsprintf_c(interpreter = 0x175fa8, pat = 0x113d90 "PC=%vu; OP=%Ou (%s)",
args =
0xffbef71c), line 51 in "misc.c"
[6] PIO_eprintf(interpreter = 0x175fa8, s = 0x113d90 "PC=%vu; OP=%Ou (%s)", ...),
line 664 in "io.c"
[7] trace_op_dump(interpreter = 0x175fa8, code_start = 0x194a50, pc = 0x194a90), line
103 in
"trace.c"
[8] trace_op(interpreter = 0x175fa8, code_start = 0x194a50, code_end = 0x194ae8, pc
= 0x194a90),
line 208 in "trace.c"
[9] runops_slow_core(interpreter = 0x175fa8, pc = 0x194a90), line 81 in
"runops_cores.c"
[10] runops_generic(core = 0x8ddc0 = &runops_slow_core(struct Parrot_Interp
*interpreter, opcode_t
*pc), interpreter = 0x175fa8, pc = 0x194a90), line 41 in "interpreter.c"
[11] runops(interpreter = 0x175fa8, code = 0x1949d0, offset = 0), line 374 in
"interpreter.c"
[12] Parrot_runcode(interpreter = 0x175fa8, argc = 1, argv = 0xffbefab0), line 311
in "embed.c"
[13] main(argc = 1, argv = 0xffbefab0), line 50 in "test_main.c"
--- parrot-orig/spf_vtable.cWed Oct 9 09:24:32 2002
+++ parrot-andy/spf_vtable.cWed Oct 9 09:10:19 2002
@@ -34,26 +34,31 @@
/* VARARGS CORE */
static STRING* getchr_va(struct Parrot_Interp *interpreter, INTVAL size, SPRINTF_OBJ
*obj) {
-char ch=va_arg((va_list)obj->data, char);
+char ch;
+va_list arg;
+arg = (va_list) obj->data;
+ch = va_arg(arg, char);
return string_make(interpreter, &ch, 1, NULL, 0, NULL);
}
static HUGEINTVAL getint_va(struct Parrot_Interp *interpreter, INTVAL size,
SPRINTF_OBJ *obj) {
+va_list arg;
+arg = (va_list) obj->data;
switch(size) {
case SIZE_REG:
-return (HUGEINTVAL)(int)va_arg((va_list)obj->data, int);
+return (HUGEINTVAL)(int)va_arg(arg, int);
case SIZE_SHORT: /* "'short int' is promoted to 'int' when passed through
'...'" */
-return (HUGEINTVAL)(short)va_arg((va_list)obj->data, int);
+return (HUGEINTVAL)(short)va_arg(arg, int);
case SIZE_LONG:
-return (HUGEINTVAL)(long)va_arg((va_list)obj->data, long);
+return (HUGEINTVAL)
Re: Fw: perl6 operator precedence table
On Tue, Oct 08, 2002 at 06:07:09PM -0700, Larry Wall wrote:
> There's this basic rule that says you can't have an operator for both binary
> and postfix, since it's expecting an operator in either case, rather than a
> term (which is how we recognize prefix operators). The one exception I can
> think of is that we might allow .. as a postfix operator, but only if followed
> by a right bracket. That would let us say
>
> @a[0..]
>
> rather than
>
> @a[0..Inf]
>
> But that's a special case.
Would that mean that three other special cases of postfix .. might exist?
0..; # useful for return 0..;
(0..) # pass infinite lists as parameters with less typing
{0..} # not sure, but it follows on
Nicholas Clark
Re: RFC: [] as the solitary list constructor
On 2002-10-08 at 17:15:06, Larry Wall wrote: > Seriously, () is just a special token. We could easily have used a > special token like NULLLIST instead. What does INTERCAL use? Well, INTERCAL doesn't have lists per se, but it does have arrays, whose size is set by assignment: the lvalue is the name of the entire array, and the rvalue is the size. So if you wanted an empty array you'd set it up with something like this: PLEASE DO ;1 <- #0 (Hey, you asked.) -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754 -- It is not enough to have great qualities, we should also have the management of them. -- La Rochefoucauld
Re: the getting started guide
Steve Fink wrote: > >Oh, and spell Piers Cawley's name correctly! :-) > > DAMN! I new that would happen. Piers, if your out there listening, forgive me. Erik
RE: [perl #17817] [PATCH] Parrot_sprintf-related stuff, part 2
Andy Dougherty:
# Overall, it continues to look very good. Unfortunately, the
# compact-looking
#
# ch=va_arg((va_list)obj->data, char);
#
# gave Sun's compiler indigestion. I had to split it up into
# the much more pedestrian
#
# va_list arg;
# arg = (va_list) obj->data;
# ch = va_arg(arg, char);
Can you try putting the first code back in, but change the object call
to be like this:
((va_list)(obj->data))
? I'm not sure yet, but this *may* be causing your other problems.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: the getting started guide
On Wednesday, October 9, 2002, at 08:49 AM, Erik Lechak wrote: >> Oh, and spell Piers Cawley's name correctly! :-) >> > > DAMN! I new that would happen. Piers, if your out there listening, > forgive me. Did you misspell it a "Bunch" of times? (Sorry Piers, couldn't resist!) David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
RE: [perl #17817] [PATCH] Parrot_sprintf-related stuff, part 2
On Wed, 9 Oct 2002, Brent Dax wrote: > Andy Dougherty: > # Overall, it continues to look very good. Unfortunately, the > # compact-looking > # > # ch=va_arg((va_list)obj->data, char); > # > # gave Sun's compiler indigestion. I had to split it up into > # the much more pedestrian > # > # va_list arg; > # arg = (va_list) obj->data; > # ch = va_arg(arg, char); > > Can you try putting the first code back in, but change the object call > to be like this: > > ((va_list)(obj->data)) > > ? I'm not sure yet, but this *may* be causing your other problems. Duh, of course, va_list() can have side effects. My fault. Sorry. Alas, your suggestion doesn't compile either, but I'll poke and prod and see what I can do to make it compile. Hmm. Just removing the (va_list) cast makes both Sun's compiler and gcc happy. (That's because va_list is ultimately typedef'd to void * anyway under Solaris, and probably most other Unix systems. I don't know about elsewhere, so this could be tricky.) Offhand, I'd say simply remove the (va_list) casts. If that proves a problem for some platform, I'll poke and prod around a bit and see if I can fix things up. I may end up doing something vaguely like va_list arg; arg = (va_list) obj->data; ch = va_arg(arg, char); obj->data = (void *) arg; everywhere, though just removing the casts is easier if it works :-). -- Andy Dougherty [EMAIL PROTECTED]
Re: perl6 operator precedence table
On Tue, 8 Oct 2002, Larry Wall wrote:
> : but I think the latter is unnatural enough that it deserves parens, so I'd
> : put 'but' above comma (and probably '='), but below just about everything
> : else.
>
> Could perhaps unify with C<..>. Wouldn't hurt for it to be
> non-associative like C<..>.
'Is' and 'but' return their left operand to allow chaining, so don't 'is'
and 'but' need to be left associative so the following will work?
0 but true but string('zero rows affected')
> I'd be more inclined to unify & and | with * and +, since that's
> exactly what they are in Boolean algebra, where 1*1 == 1. I think
> the argument that it breaks C compatibily is weak in this case,
> since almost everyone admits that C is broken in this respect.
Good point.
> Alternately, we take | and & away from bitwise ops and do something
> more useful with them. I have been asked privately by a sight
> impaired person to consider using | as the separator for parallel
> streams rather than the almost invisible ; character, for instance.
> Being a bit sight impaired myself at the moment, I have great empathy...
| and & do one thing different from + and *. They impose integer context
on their operands, rather that just numeric.
How about moving ** down to just above *? There's no precedence from C,
and -$a**2 is a bit counter-intuitive mathematically. I'm not sure
what the intuitive behavior should be for the other unary operators
though.
I can post a revised table if the associativity of 'but' is clarified.
~ John Williams
my $zen = true but false;
Re: perl6 operator precedence table
On Wed, 9 Oct 2002, John Williams wrote:
: On Tue, 8 Oct 2002, Larry Wall wrote:
:
: > : but I think the latter is unnatural enough that it deserves parens, so I'd
: > : put 'but' above comma (and probably '='), but below just about everything
: > : else.
: >
: > Could perhaps unify with C<..>. Wouldn't hurt for it to be
: > non-associative like C<..>.
:
: 'Is' and 'but' return their left operand to allow chaining, so don't 'is'
: and 'but' need to be left associative so the following will work?
:
: 0 but true but string('zero rows affected')
It might be clearer to require the parens there to disambiguate
(0 but true) but string('zero rows affected')
from
0 but (true but string('zero rows affected'))
But you're probably right that people will expect it to just stack more
properties on the leftmost argument.
: > I'd be more inclined to unify & and | with * and +, since that's
: > exactly what they are in Boolean algebra, where 1*1 == 1. I think
: > the argument that it breaks C compatibily is weak in this case,
: > since almost everyone admits that C is broken in this respect.
:
: Good point.
:
: > Alternately, we take | and & away from bitwise ops and do something
: > more useful with them. I have been asked privately by a sight
: > impaired person to consider using | as the separator for parallel
: > streams rather than the almost invisible ; character, for instance.
: > Being a bit sight impaired myself at the moment, I have great empathy...
:
: | and & do one thing different from + and *. They impose integer context
: on their operands, rather that just numeric.
Not if you use them on strings.
: How about moving ** down to just above *? There's no precedence from C,
: and -$a**2 is a bit counter-intuitive mathematically. I'm not sure
: what the intuitive behavior should be for the other unary operators
: though.
Seems to me we once had it that way, and people complained.
: I can post a revised table if the associativity of 'but' is clarified.
I wonder if we can combine .. with but. What if .. could also be
left associative? What would 1 .. 10 .. 10 mean? Maybe:
[1,2,3,4,5,6,7,8,9,10],
[2,3,4,5,6,7,8,9,10],
[3,4,5,6,7,8,9,10],
[4,5,6,7,8,9,10],
[5,6,7,8,9,10],
[6,7,8,9,10],
[7,8,9,10],
[8,9,10],
[9,10],
[10]
Hmm. I guess 1 .. (0 ..) would then mean something like:
[],
[1],
[1,2],
[1,2,3],
[1,2,3,4],
[1,2,3,4,5],
[1,2,3,4,5,6],
[1,2,3,4,5,6,7],
[1,2,3,4,5,6,7,8],
[1,2,3,4,5,6,7,8,9],
[1,2,3,4,5,6,7,8,9,10],
...
That strikes me as potentially useful to someone.
Larry
Re: Fw: perl6 operator precedence table
On Wed, 9 Oct 2002, Nicholas Clark wrote:
: On Tue, Oct 08, 2002 at 06:07:09PM -0700, Larry Wall wrote:
: > There's this basic rule that says you can't have an operator for both binary
: > and postfix, since it's expecting an operator in either case, rather than a
: > term (which is how we recognize prefix operators). The one exception I can
: > think of is that we might allow .. as a postfix operator, but only if followed
: > by a right bracket. That would let us say
: >
: > @a[0..]
: >
: > rather than
: >
: > @a[0..Inf]
: >
: > But that's a special case.
:
: Would that mean that three other special cases of postfix .. might exist?
:
: 0..; # useful for return 0..;
I bet the PDLers want to be able to say: @a[0..; 0..:10; 0..:100]
: (0..) # pass infinite lists as parameters with less typing
: {0..} # not sure, but it follows on
I meant those too when I said "bracket".
If only we had Unicode editors, we could just force everyone to use
the infinity symbol where they mean it. It seems a shame to make a
special case of the .. operator. Maybe we should ... to mean "and so
on forever":
@a[0...; 0...:10; 0...:100]
Except then we couldn't use it to mean what Ruby means by it, which
might be handier in real life. (It means to exclude the endpoint,
so 0...4 is the same as 0..3. But then, that's kind of odd too.)
Larry
Re: Fw: perl6 operator precedence table
In a message dated Wed, 9 Oct 2002, Larry Wall writes: > If only we had Unicode editors, we could just force everyone to use > the infinity symbol where they mean it. It seems a shame to make a > special case of the .. operator. Maybe we should ... to mean "and so > on forever": > > @a[0...; 0...:10; 0...:100] > > Except then we couldn't use it to mean what Ruby means by it, which > might be handier in real life. (It means to exclude the endpoint, > so 0...4 is the same as 0..3. But then, that's kind of odd too.) Oh, but then (0...) would mean "all numbers from zero to infinity, excluding infinity" which would have the same effect in the real world, wouldn't it? :-) Trey
Re: Fw: perl6 operator precedence table
On Wed, Oct 09, 2002 at 10:35:32AM -0700, Larry Wall wrote:
> On Wed, 9 Oct 2002, Nicholas Clark wrote:
> : On Tue, Oct 08, 2002 at 06:07:09PM -0700, Larry Wall wrote:
> : Would that mean that three other special cases of postfix .. might exist?
> :
> : 0..; # useful for return 0..;
>
> I bet the PDLers want to be able to say: @a[0..; 0..:10; 0..:100]
Logically does that mean , also gets in on the special case?
I think it makes sense, as I presume one could pass a couple of infinite lists
to a function that way.
> : (0..) # pass infinite lists as parameters with less typing
> : {0..} # not sure, but it follows on
>
> I meant those too when I said "bracket".
Oops - sorry. I'm so used to American texts that use bracket, brace and
parentheses to mean [] {} () (in that order, IIRC), so I assumed that you
were strictly following that convention.
> If only we had Unicode editors, we could just force everyone to use
> the infinity symbol where they mean it. It seems a shame to make a
> special case of the .. operator. Maybe we should ... to mean "and so
> on forever":
>
> @a[0...; 0...:10; 0...:100]
>
> Except then we couldn't use it to mean what Ruby means by it, which
> might be handier in real life. (It means to exclude the endpoint,
> so 0...4 is the same as 0..3. But then, that's kind of odd too.)
I think it would be clearer with .. Inf, and however many "special cases" make
sense. Presumably ] } ) ; : , are all symbols that can't be unary prefix
operators?
And if ... is exclude the endpoint, there's little difference between
0 .. Inf and 0 ... Inf, so the mathematicians can write 0 ... and be happy,
can't they?
Nicholas Clark
--
Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: Fw: perl6 operator precedence table
On Wednesday, October 9, 2002, at 10:35 AM, Larry Wall wrote: > Except then we couldn't use it to mean what Ruby means by it, which > might be handier in real life. (It means to exclude the endpoint, > so 0...4 is the same as 0..3. But then, that's kind of odd too.) Uh-oh: my life is gonna suck. I've spent days hunting obscure bugs that were caused by a single mistyped character. Now I'll be spending days hunting obscure bugs that were caused by a single *pixel*. :-) :-) :-) MikeL
Re: Fw: perl6 operator precedence table
On Wed, 9 Oct 2002, Brad Hughes wrote: : Larry Wall wrote: : [...] : > Maybe we should ... to mean "and so on forever": : > : > @a[0...; 0...:10; 0...:100] : > : > Except then we couldn't use it to mean what Ruby means by it, which : > might be handier in real life. : : No more yada-yada-yada? Still have yada-yada-yada. That's ... when a term is expected, not when an operator is expected. Just don't write 1,2,3... when you mean 1,2,3,... Or vice versa. Larry
Re: Fw: perl6 operator precedence table
In a message dated Wed, 9 Oct 2002, Michael Lazzaro writes: > > Uh-oh: my life is gonna suck. I've spent days hunting obscure bugs > that were caused by a single mistyped character. Now I'll be spending > days hunting obscure bugs that were caused by a single *pixel*. > I've already been there, my friend. :-) MacOS X's pretty anti-aliased fonts make it impossible to tell the difference between colon and semi-colon at small type sizes. It didn't used to matter, but now it really does. I have a hot key to make my terminal's font bigger whenever I'm reading perl6 mail. :-) Trey
RE: [perl #17817] [PATCH] Parrot_sprintf-related stuff, part 2
On Wed, 9 Oct 2002, Andy Dougherty wrote:
> > # Unfortunately, the compact-looking
> > #
> > # ch=va_arg((va_list)obj->data, char);
> > #
> > # gave Sun's compiler indigestion.
> Hmm. Just removing the (va_list) cast makes both Sun's compiler and
> gcc happy. (That's because va_list is ultimately typedef'd to void *
> anyway under Solaris, and probably most other Unix systems. I don't
> know about elsewhere, so this could be tricky.)
Here's a version that should make even picky compilers without
va_list=void* happy.
If you prefer the version with just removing the (va_list) cast, that's
ok with me. (Just don't throw this out, in case we ever need it!)
However, you probably *do* want the 'float promoted to double'
fix, the (int) casts for the two internal_exception calls, and the
INTVAL2PTR cast near the end.
You'll probably also want the enhanced sprintf tests (or something like
them.) Currently, the only one that fails for me is the %5.3f test, which
gives 0.500 in stdio, but 0.5 from Parrot.
Thanks again for all this work,
diff -r -u parrot-orig/spf_vtable.c parrot-andy/spf_vtable.c
--- parrot-orig/spf_vtable.cWed Oct 9 16:12:13 2002
+++ parrot-andy/spf_vtable.cWed Oct 9 16:15:09 2002
@@ -33,102 +33,164 @@
/* VARARGS CORE */
+/* Sun's WorkShop Compilers 4.2 can't handle the compact expression
+va_arg((va_list) obj->data, type);
+where obj->data is of type (void *). Hence we copy obj->data to
+a local variable and the recopy back to obj->data afterwards.
+A. D. 10/2002.
+*/
+
static STRING* getchr_va(struct Parrot_Interp *interpreter, INTVAL size, SPRINTF_OBJ
*obj) {
-char ch=va_arg((va_list)obj->data, char);
+char ch;
+va_list arg;
+arg = (va_list) obj->data;
+ch=va_arg(arg, char);
+obj->data = arg;
return string_make(interpreter, &ch, 1, NULL, 0, NULL);
}
static HUGEINTVAL getint_va(struct Parrot_Interp *interpreter, INTVAL size,
SPRINTF_OBJ *obj) {
+HUGEINTVAL rtn;
+va_list arg;
+arg = (va_list) obj->data;
switch(size) {
case SIZE_REG:
-return (HUGEINTVAL)(int)va_arg((va_list)obj->data, int);
+rtn = (HUGEINTVAL)(int)va_arg(arg, int);
+ break;
case SIZE_SHORT: /* "'short int' is promoted to 'int' when passed through
'...'" */
-return (HUGEINTVAL)(short)va_arg((va_list)obj->data, int);
+rtn = (HUGEINTVAL)(short)va_arg(arg, int);
+ break;
case SIZE_LONG:
-return (HUGEINTVAL)(long)va_arg((va_list)obj->data, long);
+rtn = (HUGEINTVAL)(long)va_arg(arg, long);
+ break;
case SIZE_HUGE:
-return (HUGEINTVAL)(HUGEINTVAL)va_arg((va_list)obj->data, HUGEINTVAL);
+rtn = (HUGEINTVAL)(HUGEINTVAL)va_arg(arg, HUGEINTVAL);
+ break;
case SIZE_XVAL:
-return (HUGEINTVAL)(INTVAL)va_arg((va_list)obj->data, INTVAL);
+rtn = (HUGEINTVAL)(INTVAL)va_arg(arg, INTVAL);
+ break;
case SIZE_OPCODE:
-return (HUGEINTVAL)(opcode_t)va_arg((va_list)obj->data, opcode_t);
+rtn = (HUGEINTVAL)(opcode_t)va_arg(arg, opcode_t);
+ break;
case SIZE_PMC: {
-PMC *pmc=(PMC*)va_arg((va_list)obj->data, PMC*);
-return (HUGEINTVAL)(INTVAL)(pmc->vtable->get_integer(interpreter, pmc));
+PMC *pmc=(PMC*)va_arg(arg, PMC*);
+rtn = (HUGEINTVAL)(INTVAL)(pmc->vtable->get_integer(interpreter, pmc));
+ break;
}
default:
PANIC("Invalid int type!");
-return 0;
+rtn = 0;
}
+obj->data = (void *) arg;
+return rtn;
}
static UHUGEINTVAL getuint_va(struct Parrot_Interp *interpreter, INTVAL size,
SPRINTF_OBJ *obj) {
+UHUGEINTVAL rtn;
+va_list arg;
+arg = (va_list) obj->data;
switch(size) {
case SIZE_REG:
-return (UHUGEINTVAL)(unsigned int)va_arg((va_list)obj->data, unsigned
int);
+rtn = (UHUGEINTVAL)(unsigned int)va_arg(arg, unsigned int);
+ break;
case SIZE_SHORT: /* short int promoted HLAGHLAGHLAGH. See note above */
-return (UHUGEINTVAL)(unsigned short)va_arg((va_list)obj->data, unsigned
int);
+rtn = (UHUGEINTVAL)(unsigned short)va_arg(arg, unsigned int);
+ break;
case SIZE_LONG:
-return (UHUGEINTVAL)(unsigned long)va_arg((va_list)obj->data, unsigned
long);
+rtn = (UHUGEINTVAL)(unsigned long)va_arg(arg, unsigned long);
+ break;
case SIZE_HUGE:
-return (UHUGEINTVAL)(UHUGEINTVAL)va_arg((va_list)obj->data, UHUGEINTVAL);
\
+rtn = (UHUGEINTVAL)(UHUGEINTVAL)va_arg(arg, UHUGEINTVAL);
+ break;
case SIZE_XVAL:
-return (UHUGEINTVAL)(UINTVAL)va_arg((va_list)obj->data, UINTVAL);
+rtn = (UHUGEINTVAL)(UINTVAL)va_arg(arg,
RE: [perl #17817] [PATCH] Parrot_sprintf-related stuff, part 2
On Wed, 9 Oct 2002, Andy Dougherty wrote:
> diff -r -u parrot-orig/t/src/sprintf.t parrot-andy/t/src/sprintf.t
> + dval = 1.0e6;
> + S = Parrot_sprintf_c(interpreter, "== %g\n", dval);
> + printf("%g %s", dval, string_to_cstring(interpreter, S));
Aargh. I forgot Microsoft's C library is going to render that as 1e+006,
not 1e+06. Rats. What's needed instead is a strcmp() on the Parrot
and stdio values. I'll work up something tomorrow.
--
Andy Dougherty [EMAIL PROTECTED]
Re: Eliminate padding warnings
On Wed, Oct 09, 2002 at 02:14:50AM -0400, Tanton Gibbs wrote:
> There were a number of warnings which read something like
> "structure padded for alignment of member value in debug.h"
>
> This can be trivially fixed by reordering the structure members ( I hope).
> This patch works fine on cygwin, but I would like to see some other
> platforms (especially 64 bit) try it out to see
> 1.) does it compile without those warnings (although, there will be
> structure padding warnings, just not for individual members).
on ARM, lots of these two:
In file included from ../include/parrot/register.h:16,
from ../include/parrot/interpreter.h:42,
from ../include/parrot/parrot.h:160,
from array.c:27:
.../include/parrot/string.h:59: warning: padding struct size to alignment boundary
In file included from ../include/parrot/interpreter.h:51,
from ../include/parrot/parrot.h:160,
from array.c:27:
.../include/parrot/debug.h:55: warning: padding struct size to alignment boundary
/usr/local/bin/perl5.8.0 pmc2c.pl boolean.pmc
string.h:
56 /* Tail added to end of string buffers; used for COW GC */
57 struct Buffer_Tail {
58 unsigned char flags;
59 };
on ARM structures all align on 4 bytes, and so pad to a multiple of 4 bytes
Even that one.
Yep. legal ANSI C.
Likewise
debug.c:
50 typedef struct PDB_condition {
51 void*value;
52 PDB_condition_ptr next;
53 unsigned short type;
54 unsigned char reg;
55 } PDB_condition_t;
In order, the other significant compiler warnings I see are:
perlhash.pmc: In function `Parrot_PerlHash_get_pmc_keyed':
perlhash.pmc:192: warning: passing arg 2 of pointer to function from incompatible
pointer type
191 return entry->val.pmc_val->vtable->get_pmc_keyed(INTERP,
192 entry, nextkey);
No idea
All 4 structs end with char members:
include/parrot/jit.h:36: warning: padding struct size to alignment boundary
include/parrot/jit.h:128: warning: padding struct size to alignment boundary
include/parrot/jit.h:150: warning: padding struct size to alignment boundary
include/parrot/jit.h:205: warning: padding struct size to alignment boundary
resources.c: In function `mem_allocate':
resources.c:147: warning: cast increases required alignment of target type
resources.c: In function `compact_pool':
resources.c:231: warning: cast increases required alignment of target type
resources.c:261: warning: cast increases required alignment of target type
resources.c:288: warning: cast increases required alignment of target type
resources.c:307: warning: cast increases required alignment of target type
147 ((struct Buffer_Tail*)((char *)return_val + size - 1))->flags = 0;
231 (struct Buffer_Tail *)((char *)b->bufstart +b->buflen);
259 struct Buffer_Tail *new_tail =
260 (struct Buffer_Tail *)((char *)cur_spot +
261 b->buflen);
288 b = (Buffer *)((char*)b + object_size);
307 (struct Buffer_Tail *)((char *)cur_spot + b->buflen);
headers.c: In function `add_extra_buffer_header':
headers.c:424: warning: cast increases required alignment of target type
424 ptr = (void**)((char*)headers->bufstart + headers->buflen - sizeof(void*));
dod.c: In function `free_unused_buffers':
dod.c:431: warning: cast increases required alignment of target type
431 b = (Buffer *)((char *)b + object_size);
> 2.) does it pass all tests
Yes. (well, no change - there's one failure I really must find tuits to
investigate, which I put down either to compiler or local hardware bug,
but your patch doesn't change that)
Nicholas Clark
--
Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: Eliminate padding warnings
On Wed, 9 Oct 2002, Nicholas Clark wrote:
> On Wed, Oct 09, 2002 at 02:14:50AM -0400, Tanton Gibbs wrote:
>
> In order, the other significant compiler warnings I see are:
>
> perlhash.pmc: In function `Parrot_PerlHash_get_pmc_keyed':
> perlhash.pmc:192: warning: passing arg 2 of pointer to function from incompatible
>pointer type
>
>191 return entry->val.pmc_val->vtable->get_pmc_keyed(INTERP,
>192 entry, nextkey);
>
> No idea
This one happens because entry is a HASH_ENTRY*, but get_pmc_keyed is
expecting a PMC*. However, by this point in the function, we've already
verified that entry is actually a PMC*, so it should be safe to add a
cast, as in the patch below. This shuts the warning up, and all tests
still pass.
Simon
--- classes/perlhash.pmc.oldWed Oct 9 15:59:29 2002
+++ classes/perlhash.pmcWed Oct 9 15:59:41 2002
@@ -189,7 +189,7 @@ pmclass PerlHash {
if (!nextkey)
return entry->val.pmc_val;
return entry->val.pmc_val->vtable->get_pmc_keyed(INTERP,
- entry, nextkey);
+ (PMC*)entry, nextkey);
}
internal_exception(OUT_OF_BOUNDS,
Re: Eliminate padding warnings
In message <[EMAIL PROTECTED]>
Simon Glover <[EMAIL PROTECTED]> wrote:
> This one happens because entry is a HASH_ENTRY*, but get_pmc_keyed is
> expecting a PMC*. However, by this point in the function, we've already
> verified that entry is actually a PMC*, so it should be safe to add a
> cast, as in the patch below. This shuts the warning up, and all tests
> still pass.
I don't thnik that works. A HASH_ENTRY is not a PMC. I think you
want pass entry->val.pmc if you want the PMC stored in the hash.
> --- classes/perlhash.pmc.old Wed Oct 9 15:59:29 2002
> +++ classes/perlhash.pmc Wed Oct 9 15:59:41 2002
> @@ -189,7 +189,7 @@ pmclass PerlHash {
> if (!nextkey)
> return entry->val.pmc_val;
> return entry->val.pmc_val->vtable->get_pmc_keyed(INTERP,
> - entry, nextkey);
> + (PMC*)entry, nextkey);
>
> }
> internal_exception(OUT_OF_BOUNDS,
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
Re: [perl #17817] [PATCH] Parrot_sprintf-related stuff, part 2
On Wed, Oct 09, 2002 at 04:42:36PM -0400, Andy Dougherty wrote:
> On Wed, 9 Oct 2002, Andy Dougherty wrote:
>
> > diff -r -u parrot-orig/t/src/sprintf.t parrot-andy/t/src/sprintf.t
>
> > + dval = 1.0e6;
> > + S = Parrot_sprintf_c(interpreter, "== %g\n", dval);
> > + printf("%g %s", dval, string_to_cstring(interpreter, S));
>
> Aargh. I forgot Microsoft's C library is going to render that as 1e+006,
> not 1e+06. Rats. What's needed instead is a strcmp() on the Parrot
> and stdio values. I'll work up something tomorrow.
They're not C99 conformant.
(I'm told that they were on the committee, so they missed fixing the standard
to make their code conformant. Now they have to do the opposite)
Then again, fflush(NULL) and a certain other OS is only about to become C89
conformant.
Ho hum. I suspect pigs will fly before any platform becomes totally C99
conformant, so we'll have to work round something from everyone.
Which reminds me, not sure if this is relevant yet, but there's some or other
platform that p5p encountered that can't simply copy whatever it is the opaque
type va_list expands to there.
There's a perl5 Configure symbol need_va_copy which indicates whether a
special macro needs to be used.
(and any platform that can't cope with free(NULL) deserves to crash and burn)
Nicholas Clark
--
Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: Eliminate padding warnings
On Wed, 9 Oct 2002, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Simon Glover <[EMAIL PROTECTED]> wrote:
>
> > This one happens because entry is a HASH_ENTRY*, but get_pmc_keyed is
> > expecting a PMC*. However, by this point in the function, we've already
> > verified that entry is actually a PMC*, so it should be safe to add a
> > cast, as in the patch below. This shuts the warning up, and all tests
> > still pass.
>
> I don't thnik that works. A HASH_ENTRY is not a PMC. I think you
> want pass entry->val.pmc if you want the PMC stored in the hash.
>
I've just had a quick look at hash.h (which I should have done in the
first place) and you're quite right. Second attempt at a correct patch
below.
All tests still pass, but this isn't much comfort, as the fact that the
preceding patch 'worked' suggests that nothing's actually testing this
line of code. I'll see if I can do something to remedy this tomorrow,
unless somebody beats me to it.
Simon
--- classes/perlhash.pmc.oldWed Oct 9 15:59:29 2002
+++ classes/perlhash.pmcWed Oct 9 18:06:08 2002
@@ -189,7 +189,7 @@ pmclass PerlHash {
if (!nextkey)
return entry->val.pmc_val;
return entry->val.pmc_val->vtable->get_pmc_keyed(INTERP,
- entry, nextkey);
+ (PMC*)entry->val.pmc_val, nextkey);
}
internal_exception(OUT_OF_BOUNDS,
Re: Eliminate padding warnings
In message <[EMAIL PROTECTED]> Simon Glover <[EMAIL PROTECTED]> wrote: > I've just had a quick look at hash.h (which I should have done in the > first place) and you're quite right. Second attempt at a correct patch > below. > > All tests still pass, but this isn't much comfort, as the fact that the > preceding patch 'worked' suggests that nothing's actually testing this > line of code. I'll see if I can do something to remedy this tomorrow, > unless somebody beats me to it. That looks better, although you can actually get rid of the cast once you do that as pmc_val has the right type. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
Re: Fw: perl6 operator precedence table
On Tue, Oct 08, 2002 at 06:07:09PM -0700, Larry Wall wrote: > I've always wondered what the ! postfix operator means. The mathematicians > think they know. :-) The Ruby folks think they know. They're method name conventions. >From "Programming Ruby" Methods that act as queries are often named with a trailing '?', such as instance_of?. Methods that are 'dangerous' or modify the receiver, might be named with a trailing '!'. For instance, String provides both a chop and a chop!. The first one returns a modified string; the second modifies the receiver in place. '?' and '!' are the only weird characters allowed as method name suffixes. So... sorted_array = array.sort # return a sorted array array.sort! # sort in place is_sorted = array.sorted? # return true if the array is sorted Interestingly enough, Ruby also supports the ?: operator as Perl does and does not require whitespace between the tokens. $foo=1?42:0; # $foo will have 42 in it. I believe that ? simply binds tighter to method names than the ?: operator. This is fine: print defined? $foo; This is a syntax error: print defined? $foo : 42; /home/schwern/tmp/foo.rb:1: parse error print defined? $foo : 42; ^ -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Cottleston, Cottleston, Cottleston Pie. Why does a chicken, I don't know why. Ask me a riddle and I reply: "Cottleston, Cottleston, Cottleston Pie."
Re: the getting started guide
At 11:28 PM -0400 10/8/02, Erik Lechak wrote: >Well here it is, my first attempt at a "getting started" guide. >It's not ready for public consumption, but I would like to hear some >feedback. The later sections are blank or contain notes in a not >nice format. As time moves on and I learn more, I expect the guide >to fill up. It's taking me a lot longer to get up to speed on >Parrot due to the fact that I am documenting my learning process. I >hope this effort helps others ramp up more rapidly. This looks good, and thanks very much! I'll see about getting some of the internal structures diagrammed better, which is the only place things are a little dodgy, but that's otherwise fine. Now, here's hoping CVS doesn't munch the bitmaps... :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #17803] [PATCH] Various tests
At 7:42 PM -0700 10/8/02, Steve Fink wrote: >Thanks, applied. > >Who came up with the idea of two-argument ne, anyway? That's kind of >bizarre. Definitely bizarre. I think I'd rather not have it, it doesn't make much sense. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[ANNOUNCE] Perl6 OO Cookbook, v0.1
Yes, you heard right. A cookbook describing stuff that hasn't yet been designed, for a language that doesn't yet exist. Having flashbacks to your college years, anyone? The purpose of the Cookbook is to foster discussion on perl6 OO concepts, and to start documenting the decisions that are made, when they are made: sort of a proto-FAQ. For now, the important part is gathering a comprehensive list of the questions to ask, and some vague stabs at the answers. PLEASE read the "About This Document" part FIRST for all the appropriate caveats. In particular: - This document has no official status. It's just a first try at something perl6 OO programmers will desperately need. - While the recipes presented represent generally valid questions, the code samples presented are fictional, and will be edited ASAP as the appropriate decisions have been made from the higher-ups. PLEASE contribute to this document! Email me with suggestions, "yes" or "no" votes on recipe approaches, info on philosophies or best-guess syntax, etc., or discuss them here on perl6-language. Note that making decisions on any one recipe will naturally allow N other recipes to be decided as well, so this is a great way to break a huge subject into smaller, manageable concepts, and sort through the logical consequences of each. The Perl6 OO Cookbook v0.1 can be accessed at: http://cog.cognitivity.com/perl6/ Ignore the corporate logo, this is my company's site. Have fun, and let me know what you think. MikeL
Re: the getting started guide
Robert Spier wrote: >>This version is in html. I almost have the pod version ready. >> >> > >So the html is canonical and you're converting it to pod? I'm >confused. > > I am writing it in my own format. It lets me take notes, write todo lists, autogenerate the table of contents and glossary. Then I run it through some perl that currently spits out html and almost make pod. > > >>Here is my last question. Recently, when I try to login to cvs, I get >>this (see below). It worked in the past. Is it me, or did something >>else happen? >>set CVSROOT=:pserver:[EMAIL PROTECTED]:/cvs/public >>cvs login >>(Logging in to [EMAIL PROTECTED]) >>CVS password: ***I JUST HIT RETURN HERE*** >>cvs [login aborted]: could not open %USERPROFILE%/.cvspass: No such >>file or directory >> >> > >This is you, not the server. > >What does echo %USERPROFILE% at a command prompt show? > >-R > > I figured out the problem, and added a few lines to the getting started guide. I had to adjust the %HOME% variable. I found another problem, I just downloaded the newest version of WinCVS and it tells me that this port does not support pserver: cvs [update aborted]: the :pserver: access method is not supported by this port of CVS Where can I get a reliable port of cvs for Windows? My old executable (v1.11)works fine. Thanks, Erik
Re: the getting started guide
>I'll see about getting some of the internal structures diagrammed >better, which is the only place things are a little dodgy, but that's >otherwise fine. Simon Wistow <[EMAIL PROTECTED]> dropped me an email and reminded me about AutoDia http://droogs.org/autodia/ >Now, here's hoping CVS doesn't munch the bitmaps... :) Right now, the perl.org cvs recognizes the following extensions as binary: *.a *.au *.avi *.AVI *.bmp *.BMP *.cpio *.dll *.DLL *.doc *.DOC *.dot *.DOT *.eps *.exe *.EXE *.gif *.GIF *.gz *.ico *.JAR *.jar *.jpg *.jpg *.JPG *.lib *.LIB *.mov *.mp3 *.MP3 *.mpg *.MPG *.mpp *.MPP *.opt *.pdf *.PDF *.png *.PNG *.ppt *.PPT *.psd *.ps *.PS *.pyc *.pyd *.pys *.so *.swf *.SWF *.tar *.TAR *.tgz *.wav *.WAV *.xl* *.XL* *.xls *.XLS *.zexp *.zip *.ZIP *.Z -R
Re: the getting started guide
>>So the html is canonical and you're converting it to pod? I'm >> confused. >I am writing it in my own format. It lets me take notes, write todo >lists, autogenerate the table of contents and glossary. Then I run it >through some perl that currently spits out html and almost make pod. Whatever floats your boat. >I found another problem, I just downloaded the newest version of >WinCVS and it tells me that this port does not support pserver: >cvs [update aborted]: the :pserver: access method is not supported by >this port of CVS >Where can I get a reliable port of cvs for Windows? My old executable >(v1.11)works fine. This doesn't make any sense. They can't abandon pserver. Try going back to the stable 1.2 version of WinCVS. Are you sure that's the right error message? In the latest 1.3.6 beta, there is no such error message, but there is this one: cvs-1.10/src/client.c:the :server: access method is not supported by this port of CVS"); ( -server- is very different from -pserver-) -R
Warnings on VC++
core_ops.c(19) : warning C4005: 'CONST' : macro redefinition
C:\Program Files\Microsoft Visual Studio
..NET\Vc7\PlatformSDK\Include\WinDef.h(138) : see previous definition of
'CONST'
jit_cpu.c(20) : warning C4005: 'CONST' : macro redefinition
C:\Program Files\Microsoft Visual Studio
..NET\Vc7\PlatformSDK\Include\WinDef.h(138) : see previous definition of
'CONST'
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: the getting started guide
At 10:07 PM -0700 10/9/02, Robert Spier wrote: > >I'll see about getting some of the internal structures diagrammed >>better, which is the only place things are a little dodgy, but that's >>otherwise fine. > >Simon Wistow <[EMAIL PROTECTED]> dropped me an email and reminded >me about AutoDia http://droogs.org/autodia/ Interesting. Another thing to poke into. > >Now, here's hoping CVS doesn't munch the bitmaps... :) > >Right now, the perl.org cvs recognizes the following extensions as >binary: Good. I've not had much dealing with CVS, but I have heard horror stories about it eating binary files. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: [perl #17817] [PATCH] Parrot_sprintf-related stuff, part 2
Andy Dougherty:
# You'll probably also want the enhanced sprintf tests (or
# something like
# them.) Currently, the only one that fails for me is the
# %5.3f test, which gives 0.500 in stdio, but
# 0.5 from Parrot.
I finally tracked down this bug. If you look, there are fifty-three
zeroes. The format in question is %5.3g.
Get the picture?
What was happening was that gen_sprintf_call(), which reconstructs a
format string from the info structure so it can be passed to the native
snprintf, called uint_to_string() once to convert the width to a string,
then again to convert the precedence. Unfortunately, the target given
to uint_to_string() wasn't being cleared by either it or
gen_sprintf_call(), so the sprintf format generated was %5.53g. This is
cleared up in my local copy.
# Thanks again for all this work,
You're quite welcome. :^) And thanks for being a patient and helpful
tester and debugger.
Once I clear up the issue with the Sun compiler, I'll be committing
this. Well, a slightly modified version. Relax, it's nothing
drastic--I just ran it through check_source_standards.pl and
run_indent.pl.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
