Re: Safe Mode for Parrot -- Need a volunteer
Gregor N. Purdy <[EMAIL PROTECTED]> wrote: > ..., but I didn't want to make > 2 * N new .c files to get paranoid versions of the N core .c > files now. One safe core, built separately with its own Ops files ought to be enough, IMHO. > I thought about prederef a bit right before submitting this, and > I think the prederef code path is a great place to do the checks. Yep. > In fact, I'm wondering if the prederef process shouldn't just do > the paranoid checks always, since the point of its process is to > make one slightly slower pass through things so that subsequent > passes can get a speed boost. Maybe it won't be too much of a hit > to leave PARANOID as a built-in part of it always. I'd do simple checks always as register range ckecks. But more complicated ones like decomposing keys and checking key register numbers or constant table entries could be done only if the paranoid flag bit of the prederef function is turned on. >> While its seems legitimate to check P and S registers for >> NULL, its suboptimal to generally disallow NULL registers. NULL PRegs >> are in use e.g. for C and if the code allows execution of dlfunc >> (probably not but ...) a NULL value for the dl-handle is valid. > Only 'in' S and P registers are being checked for NULLness. > I looked at dlfunc, and I think the right code is being > generated for PARANOID. Maybe you could post a code snippet > to point out where it is wrong... e.g. from src/parrot/languages/imcc/t/syn/pcc.t .sym pmc NULL null NULL dlfunc FABS, NULL, "fabs", "dd" Passing a NULL handle to dlfunc aka dlsym gets you functions of the main program. >> And finally composite keys may have registers too. > I have to admit I don't know much about the way the keyed stuff > works. It appeared in Parrot after my big push of effort. I've > been wanting to integrate it into Jako as a way of learning how > it works, but alas my supply of tuits has been very low for > some time. jit.c:263 ff has an example of getting registers out of keys. > Regards, > -- Gregor leo
Re: LF needed at end of pasm files?
Jeff Clites <[EMAIL PROTECTED]> wrote: > I'd imagine this indicates a behavior change in imcc at some point. Or no one ran these tests since assemble.pl was used :) > It's easy enough to add the LFs, but it might be better to not require > the final line end character. The parsing pod says that statements are terminated by newlines. A missing newline at the end of the file is a clear sign of a b0rken text editor. Newlines added. > JEff Thanks for reporting, leo
[perl #24115] [PATCH] update of strings.pod
# New Ticket Created by Michael Scott # Please include the string: [perl #24115] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=24115 > I've made the changes necessary to bring strings.pod up-to-date. Here's the patch: -- attachment 1 -- url: http://rt.perl.org/rt2/attach/65641/48987/0c8b75/strings_pod.patch -- attachment 3 -- url: http://rt.perl.org/rt2/attach/65641/48989/e735b0/strings.pod strings_pod.patch Description: strings_pod.patch Here's the file: strings.pod Description: strings.pod Mike
Re: [perl #24115] [PATCH] update of strings.pod
Michael Scott <[EMAIL PROTECTED]> wrote: > I've made the changes necessary to bring strings.pod up-to-date. Applied, thanks. leo
Re: [CVS ci] pcre pattern match example
At 5:33 PM +0200 10/2/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
On Thu, 2 Oct 2003, Leopold Toetsch wrote:
$ parrot examples/assembly/pcre.imc "abcdef12" 'bc(.)([a-z]+)'
abcdef12 =~ /bc(.)([a-z]+)/
Given that, for perl 5 code, we're going to have perl 5's real regex
engine, and for perl 6 in perl 5 compatibility mode PCRE is inadequate, I
don't think there's much point in PCRE as a long-term solution for
anything. Like it or not, we're going to have to reimplement perl 5's
regex compiler so it emits parrot bytecode.
I dunno yet, how unusable PCRE is for perl5 compat, but pcre 4.4 has
utf8 support, and even kind of ?{code} syntax called "callout".
The biggest issue is embedded code--it's perfectly acceptable for a
perl regex to have executable blocks in it. Not all that used at the
moment, in part because the docs for it are really bad, but it is in
there.
I don't see PCRE as a long term solution but it would be a nice to have
in the meantime and it could be useful to boot the real regex machine,
be it perl5 or perl6 rules.
Fair enough, but I don't want to ship the PCRE sources, nor require
them for parrot to build, so there's something of a problem there,
unfortunately. When Arthur gets Ponie going we can just use perl's
regex engine, and we could write a perl regex compiler in pasm/pir,
but that's a bit of an undertaking.
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
More fun with argument passing
Ok, I'm back to argument passing. I'm starting a new thread because
I'm lazy and I have to scroll back too far in my mailer to see the old
arg passing thread. :-) And yes, most of this message should also be
on -languages.
Could somebody tell me where I go wrong:
If you have a prototype
sub f ($a, $b, $c) { ... }
then you should pass $a in P5, $b in P6, etc. So the code will look
like:
.param $a
.param $b
.param $c
If you declare a sub without a prototype, it should default to ([EMAIL PROTECTED]).
A slurpy array parameter puts its corresponding arguments in a list
context, which is the same as a flattening context. This is stated in
E6 and S6, though not in A6 as I read it (but it doesn't disagree
either.)
Let's add a prototype-less sub for use in discussion:
sub g { ... }
Is there any way to create a prototype that, when called with any
number of array variables, would pass all of the arrays as objects?
So, for example, f(@x, @y, @z) would do the right thing for exactly
three arrays, but couldn't handle f(@x,@y,@z,@w). g(@x, @y, @z) seems
to flatten all of them together. I'm sure something like
g([EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED]) would work, but what if I
want to do the call without
backslashes?
The calls f(1, 2, 3) and g(1, 2, 3) should both generate
.arg 1
.arg 2
.arg 3
...except instead of constant ints, you'd probably need PMCs.
Splatted array params are aliases to the actual args. So
sub h ([EMAIL PROTECTED]) { @params[1] = 'tuna!'; }
h($x, $y, $z);
should set $y to 'tuna!'.
Would h(@x) set @x[1] to 'tuna!'? If so, then does
h(@x, $y)
change $y's value depending on the number of elements in @x? It seems
that @params is either a magical array where lookups trigger a runtime
computation of where that index would be found in the original
argument list, or it is an array of references to either variables or
pairs, and all of those references are built at runtime
immediately when the call is made. (Which rather defeats the default
laziness of arrays.) Actually, "proxies" might be a more accurate
term. You should be able to pass @params into another function just
like any other array, or do
$gloof = (rand(100) < 30) ? @params : @normal_array;
Or maybe h(@x) does NOT set @x[1] to 'tuna!'?
Ok, the whole aliasing thing was something of a tangent. Back to f()
and h(), which are really f($,$,$) and h(*@).
I can use names to pass required arguments, but all positional args
must precede all named args. So then is this legal:
f(1, 2, b => 1.5)
or must all of the positional args referred to by named parameters
follow those passed positionally? (There are two orders -- argument
order and parameter order. In which of those two must all positionals
precede the named params?)
In
sub j($a, ?$b, *%c) { ... }
can I actually pass %c after the rest of the params? If I call it with
j(1, $blue => 'red')
then does that compile down to
.param 1
.param named_arg_table
? How is the callee supposed to know whether the 2nd param is $b or
%c? What if $blue happened to be "b"?
If I do it the other way around,
.param named_arg_table
.param 1
then at least I can always assume the named args are passed first, and
use the arg count to directly determine whether $b was passed or not.
But then all Perl6 subroutines would have to take a named arg table as
their first argument, by convention, and cross-language calls would
need to be aware of this -- even when calling unprototyped. ("Oh,
yeah, if you're calling a Perl6 routine you have to pass an empty
hashtable as the first param.")
I have a first cut at Perl6 parameter passing. It doesn't do runtime
context, the named params are in there but I assume they don't work,
and it reflects my earlier misconception that a [EMAIL PROTECTED] array should
NOT flatten its arguments. Or, in other words, I compile
sub g { ... }
g(10,20,30)
down to
$P0[0] = 10
$P0[1] = 20
$P0[2] = 30
.arg (empty hash)
.arg $P0
and
sub f ($a, $b, $c) { ... }
f(10,20,30)
down to
.arg (empty hash)
.arg 10
.arg 20
.arg 30
which means that if you call f($a,$b,$c) without its prototype, then
it compiles to the former code which results in $a getting 3 (the
length of the @_ array), while $b and $c get bad values that seg fault
parrot.
I'm hesitating to manually pull all of the [EMAIL PROTECTED] elements out of
P5..P15 + P3[0..] until someone makes me a little more confident that
it's the right thing to do. And even then, perhaps it should be
handled by some kind of .flattened_param declaration. But neither
would handle the magical aliasing I talked about above, if that is
required. And it's also slowing down the callee in what could easily
be a common case.
The patch for this is mixed in with some other stuff I've been working
on, but the relevant part is more or less
Addcontext.pm | 137 +-
Builtins.pm | 411 ++--
Context.pm |
Re: [CVS ci] pcre pattern match example
Dan Sugalski <[EMAIL PROTECTED]> wrote: > Fair enough, but I don't want to ship the PCRE sources, nor require > them for parrot to build, so there's something of a problem there, > unfortunately. So I'll make a lib ouf of it. Where do you prefer it to go: * runtime/parrot/lib/ * library/ leo
Re: [CVS ci] pcre pattern match example
At 7:19 PM +0200 10/5/03, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: Fair enough, but I don't want to ship the PCRE sources, nor require them for parrot to build, so there's something of a problem there, unfortunately. So I'll make a lib ouf of it. Where do you prefer it to go: * runtime/parrot/lib/ * library/ Put it in runtime, which is where I think we should be sticking all this stuff, at least until we have a good scheme worked out for where it should go. (We need a versioned library system at some point) While I've no problem with a PCRE library, I want to emphasize that I do *not* want PCRE to be required for any part of parrot's building or configuration, any more than the ncurses stuff should be. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: More fun with argument passing
Steve Fink writes:
> Ok, I'm back to argument passing. I'm starting a new thread because
> I'm lazy and I have to scroll back too far in my mailer to see the old
> arg passing thread. :-) And yes, most of this message should also be
> on -languages.
Which it now is. Although, there are some internals issues, too, so I
wonder how we can do this. How about, when someone responds to either
an -internals- or a -language-specific question, he directs it only to
the appropriate list.
> Could somebody tell me where I go wrong:
>
> If you have a prototype
> sub f ($a, $b, $c) { ... }
> then you should pass $a in P5, $b in P6, etc. So the code will look
> like:
> .param $a
> .param $b
> .param $c
>
> If you declare a sub without a prototype, it should default to ([EMAIL PROTECTED]).
Yep.
> A slurpy array parameter puts its corresponding arguments in a list
> context, which is the same as a flattening context. This is stated in
> E6 and S6, though not in A6 as I read it (but it doesn't disagree
> either.)
>
> Let's add a prototype-less sub for use in discussion:
> sub g { ... }
>
> Is there any way to create a prototype that, when called with any
> number of array variables, would pass all of the arrays as objects?
> So, for example, f(@x, @y, @z) would do the right thing for exactly
> three arrays, but couldn't handle f(@x,@y,@z,@w). g(@x, @y, @z) seems
> to flatten all of them together. I'm sure something like
> g([EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED]) would work, but what if I
> want to do the call without
> backslashes?
This was described in A6. It goes:
sub g([EMAIL PROTECTED] is context(Scalar)) {...}
> The calls f(1, 2, 3) and g(1, 2, 3) should both generate
> .arg 1
> .arg 2
> .arg 3
> ...except instead of constant ints, you'd probably need PMCs.
But constant ones :-)
> Splatted array params are aliases to the actual args. So
>
> sub h ([EMAIL PROTECTED]) { @params[1] = 'tuna!'; }
> h($x, $y, $z);
>
> should set $y to 'tuna!'.
No, it should give an error. Parameters are declared constant by
default. You'd have to:
sub h ([EMAIL PROTECTED] is rw) { @params[1] = 'tuna!' }
How to make the distinction between a constant array and an array of
constants is still unclear to me.
> Would h(@x) set @x[1] to 'tuna!'? If so, then does
>
> h(@x, $y)
>
> change $y's value depending on the number of elements in @x?
Ouch. Yeah, I guess so. I don't expect to see C<[EMAIL PROTECTED] is rw> a
whole lot, but that is a bit of a pickle to implement.
> It seems that @params is either a magical array where lookups trigger
> a runtime computation of where that index would be found in the
> original argument list, or it is an array of references to either
> variables or pairs, and all of those references are
> built at runtime immediately when the call is made. (Which rather
> defeats the default laziness of arrays.) Actually, "proxies" might be
> a more accurate term. You should be able to pass @params into another
> function just like any other array, or do
>
> $gloof = (rand(100) < 30) ? @params : @normal_array;
>
> Or maybe h(@x) does NOT set @x[1] to 'tuna!'?
>
> Ok, the whole aliasing thing was something of a tangent. Back to f()
> and h(), which are really f($,$,$) and h(*@).
>
> I can use names to pass required arguments, but all positional args
> must precede all named args. So then is this legal:
>
> f(1, 2, b => 1.5)
>
> or must all of the positional args referred to by named parameters
> follow those passed positionally? (There are two orders -- argument
> order and parameter order. In which of those two must all positionals
> precede the named params?)
Both. (In parameter order, named-only must come after positionals) So
f(1, 2, b => 1.5) was correct.
> In
>
> sub j($a, ?$b, *%c) { ... }
>
> can I actually pass %c after the rest of the params? If I call it with
>
> j(1, $blue => 'red')
>
> then does that compile down to
>
> .param 1
> .param named_arg_table
>
> ? How is the callee supposed to know whether the 2nd param is $b or
> %c? What if $blue happened to be "b"?
If $blue was 'b', then j would get $b to be 'red'. Run-time positionals
are another one of those things I don't expect to see all that often
(but that might be a different story in my code >:-).
The real problem arises in:
j(1, 2, $blue => 'red')
If $blue happens to be 'b'. I think the behavior then would be $b gets
2, and %h gets { b => 'red' }. In particular, I think it's wrong to
croak with an error here.
> If I do it the other way around,
>
> .param named_arg_table
> .param 1
>
> then at least I can always assume the named args are passed first, and
> use the arg count to directly determine whether $b was passed or not.
> But then all Perl6 subroutines would have to take a named arg table as
> their first argument, by convention, and cross-language calls would
> need to be aware of this -- even when calling unprototyped. ("Oh,
> yeah, if yo
Re: More fun with argument passing
On Oct-05, Luke Palmer wrote:
> Steve Fink writes:
> > Ok, I'm back to argument passing. I'm starting a new thread because
> > I'm lazy and I have to scroll back too far in my mailer to see the old
> > arg passing thread. :-) And yes, most of this message should also be
> > on -languages.
>
> Which it now is. Although, there are some internals issues, too, so I
> wonder how we can do this. How about, when someone responds to either
> an -internals- or a -language-specific question, he directs it only to
> the appropriate list.
And I guess cross-post one last time when moving a piece from one list
to another?
> > I can use names to pass required arguments, but all positional args
> > must precede all named args. So then is this legal:
> >
> > f(1, 2, b => 1.5)
> >
> > or must all of the positional args referred to by named parameters
> > follow those passed positionally? (There are two orders -- argument
> > order and parameter order. In which of those two must all positionals
> > precede the named params?)
>
> Both. (In parameter order, named-only must come after positionals) So
> f(1, 2, b => 1.5) was correct.
Huh? In argument order, clearly all the positionals precede the named.
But if 2 is bound to $c, then they are out of parameter order. Or does
that not bind 2 to $c? Are both 2 and 1.5 bound to $b (and resolved as
below)?
> > In
> >
> > sub j($a, ?$b, *%c) { ... }
> >
> > can I actually pass %c after the rest of the params? If I call it with
> >
> > j(1, $blue => 'red')
> >
> > then does that compile down to
> >
> > .param 1
> > .param named_arg_table
> >
> > ? How is the callee supposed to know whether the 2nd param is $b or
> > %c? What if $blue happened to be "b"?
>
> If $blue was 'b', then j would get $b to be 'red'. Run-time positionals
> are another one of those things I don't expect to see all that often
> (but that might be a different story in my code >:-).
Sorry, that was an implementation question, not a language question.
>From the language-level, clearly the effect you want is for 1 to be
bound to $a and 'red' to be bound to either $b or %c{$blue}, depending
on whether $blue eq "b". The question is in what order the parameters
should be passed. Both work, but both cause problems.
> The real problem arises in:
>
> j(1, 2, $blue => 'red')
>
> If $blue happens to be 'b'. I think the behavior then would be $b gets
> 2, and %h gets { b => 'red' }. In particular, I think it's wrong to
> croak with an error here.
Larry had some discussion of this:
However, it is erroneous to simultaneously bind a parameter both by
position and by name. Perl may (but is not required to) give you a
warning or error about this. If the problem is ignored, the
positional parameter takes precedence, since the name collision might
have come in by accident as a result of passing extra arguments
intended for a different routine. Problems like this can arise when
passing optional arguments to all the base classes of the current
class, for instance. It's not yet clear how fail-soft we should be
here.
Oh, and in discussing this, I'm wondering about one bit of vocabulary:
do you bind an argument to a parameter, a parameter to an argument, or
do you bind an argument and parameter together? E6 binds arguments to
parameters. What if you are binding multiple arguments to a single
parameter, as is the case with slurpy params?
It doesn't matter, really, but in my documentation and discussion I'd
like to be consistent, just because this stuff is already a ways
beyond my mental capacity and anything that simplifies things is
greatly appreciated!
