[off topic] an amusing side note
Well, it's the first time *I've* seen it. http://otierney.net/images/perl6.gif I find it difficult to disagree, at the perl6 language level. Here's to hoping something sensible emerges from Parrot, at least. :) F.
Re: [off topic] an amusing side note
On Wed, Nov 24, 2004 at 04:25:14PM -0500, John Siracusa wrote: On 11/24/04 3:42 PM, Felix Gallo wrote: Well, it's the first time *I've* seen it. http://otierney.net/images/perl6.gif I find it difficult to disagree, at the perl6 language level. I don't :) Judging by the Perl 6 RFCs, I think that book cover would be accurate if the community really did design Perl 6 in the absence of Larry. Fortunately, that's not the case. I think Perl 6 is a lot cleaner than Perl 5 in addition to being much more powerful. This would doubtless be a very long discussion :), so I will stop my contribution to the thread with the following notes: 1. I ran the Obfuscated Perl contest for many years, and even I draw the line at purposefully obfuscated language design documentation _release methods_. Sly obfuscated cuteness has gone from 'rife' to 'pathologically endemic', in both design and presentation. IMHO. 2. perl 6 is a lot cleaner than perl 5. It's also much, much larger than an already very large language. I've been programming and evangelizing Perl in organizations small and gigantic since 4.03x, and my eyes just glaze over at all the unnecessarily surfaced complexity bound to make reading other people's programs finally, at last, literally impossible: http://www.ozonehouse.com/mark/blog/code/PeriodicTable.html I'm not going to use perl 6. F.
Re: Privilege implementation
Leo writes: Felix Gallo [EMAIL PROTECTED] wrote: 6. It's a little alarming that if you look for struct ParrotIOData in src/ and include/, you won't find it. I found it, but couldn't figure out why it was there. Leo? Bigger parts of the interpreter like imcc and IO are distinct subsystems and are located in separate subdirectories. Noted, but contrary to expectation. Seems like all source should be under src, and all headers under include. I don't know which editor you are using, but have a look at your editor's documentation for tags or TAGS. In vim locating a structure, function, ... is just one keystroke C ^] away (after make tags). Good point. I'm somewhat surprised that nobody has yet commented on the rest of the post...I must have gotten it right. :) F.
Re: Towards 0.1.1 - timetable
Leo writes: Wed 6.10. 18:00 GMT - feature freeze Sat 9.10. 8:00 GMT - code freeze - no checkins please - Parrot 0.1.1 will go out on Saturday. - nice release name wanted 'fireparrot'
Privilege implementation
(suggested reading: PDD 18) I am starting work on the implementation of privileges. There are a couple of open issues I'd like to bounce before I start typing in earnest. 1. Privs take several forms. Privs can be per-interpreter (no computed goto), per set-of-ops (e.g., deny everything, allow all IO ops), per op (no library load, no goto, no exec), and opcode replacement (when you do a jump, do MY jump()); per-namespace (read/write/create/destroy); and freeform (I declare I have priv shabozz). The last two seem likely to be implemented last. 2. For courtesy and convenience, the priv system will have some way of loading a provided namespace into an interpreter during the creation phase (so that libraries may be loaded without being limited by the priv system or consuming resources). 3. Newly minted or cloned interpreters may or must (respectively) copy privs from an existing interpreter. Thawed interpreters or any other interpreter coming from a semi-untrusted state must reapply their privs as in 4 below. 4. If an interpreter is set up to be secure either explicitly or via inheritance, at the end of the interpreter instantiation, the following actions occur: - per-opset privs fire, which iterate through the below - per-op privs fire, which overlays the existing op trampoline with calls to functions that generate privilege exceptions. Note: this doesn't work if the op trampoline is malleable intrainterpreter, but it's a whole lot less messy and faster than the alternative. Thoughts and guidance encouraged. - opcode replacement is enacted by copying into the op trampoline. 5. struct Interp is looking a little ragged. It's probably faster that way, but there appear to be several different naming conventions fighting it out, as well as different abstraction impedances chittering around each other. We're gonna scare away all those prim Python guys. 6. It's a little alarming that if you look for struct ParrotIOData in src/ and include/, you won't find it. I found it, but couldn't figure out why it was there. Leo? F.
Re: Semantics for regexes
Dan writes: [...] Yes, and some of the initial list already has ops to do those bits, though I fully plan on evil cheating versions for some extra speed. If I recall correctly, someone with the best intentions attempted to write a clear, object-oriented (but still C/C++ based) regex engine to replace the existing highly hairy code. As a result it missed fitting in the cache, and ended up being like two orders of magnitude slower. Not arguing for premature optimization, but anyone thinking about regex might want to look ahead (get it?) to the end game where regex pretty much has to be within .2x of its current speed. F.
Re: Semantics for regexes
Dan writes: I don't think we're going to be able to manage doing our matches in 20% of the time of the current regex engine. That's a bit ambitious, even for me. :) I dunno, there are a number of extant cases of languages that manage to run regexes just as fast as the current regex engine. The fact that they happen to, well, _embed_ the current regex engine may be germane... Although the next regex engine has to deal with the horribly crufty new perl6 syntax, at this point I'm willing to put down $50 that after all the boiling what we get at the bottom of the saucepot looks much like: regex P0, P1, P2 and not much like 2000 lines of pasm, but I've been wrong before and will be again. F.
Re: Semantics for regexes
Dan writes: True enough. Oh, don't get me wrong, I think we can go faster than the perl 5 regex engine. I just don't think we can do in 2 seconds what takes perl 5 10 seconds... :-P Yeah, I meant the other way around. Lacking any kind of formal specification for it, my general thought is that people will generally (but not the biotech or chip design guys) feel OK about parrot if their regexes are only 5x slower. After that people start asking pointed questions. Last time I looked at the perl 5 regex engine (and I'm still recovering, but the medication's helping) it was just a little bytecode engine with massive amounts of Nasty Evil piled on top. I think we can get a nice boost from the JIT or computed goto core, enough so that a single big bytecode interpreter (parrot) will work better than two smaller bytecode interpreters (which is what perl 5 w/the regex engine is, more or less) It'll be interesting to see how much cache coherency plays into the picture. The twitchy, beady-eyed fanged little hairy regex engine does have the benefit of being able to nestle into modern CPU caches, and get 1-5 ns access time rather than 30-120 ns. Probably accounts for its evolutionary hardiness. F.
Re: Last bits of the basic math semantics
Dan writes:
The some multiple being the next largest power of 256 that contains the
value, or the width that the value happens to be stored in at that time?
(Based on previous values assigned to that PMC which may have widened it)
Good question. The size of the bignum, if it's been declared to have
a maximum size, or the maximum size that it's been, though that
doesn't feel particularly right.
$bignum1 = 2^3283 + 1;
$bignum2 = $bignum1 - 2^3283;
# Q1 what's sizeof(bignum2) and how did it get that way?
print $bignum1 1; # shift
# Q2 expected output?
print $bignum1 1; # rotate
# Q3 expected output?
Q1 Given my current understanding, bignum2 should be either int or
a bignum with a 1-byte data field (the principle of 'snapping to
least size' espoused by Dan et al. in the math discussion).
Q2 the decimal representation of the binary number 1{3283 zeroes}10,
though my hazy understanding of bignum is that the in-memory
representation is not necessarily binary, so that would be a
pretty annoying piece of code. Internally a bignum.
Q3 the decimal representation of the binary number 11. Internally
carries the 2^3283 size of $bignum1 in case the owner intends on
rotating it back. Violates the principle of snapping to least
size but follows the principle of least surprise.
F.
Re: Last bits of the basic math semantics
Nicholas writes:
I can't really see how you can rotate a bignum that doesn't have a width
already associated with it.
Maybe that's the answer: unless a bignum has a limit set on it,
rotate is shift ('we're just rotating a really, really large number...')
F.
Re: Numeric semantics for base pmcs
Nick writes: 2 * 3 give a bignum. That feels evil. Except that the way that $a = 2 * 3 will work is that the assignment of the bignum temporary to $a will cause $a to drop it back to an int (for most languages' choice of target PMC) ? Dan, any feeling about RISC vs. CISC? Because to me, this seems like a good place to punt, and provide two, maybe three mults: multbig: returns bignum, relies on PMC smart autounboxing multint: returns int-or-die, no unboxing multsmallest: returns parrot-defined 'smallest type that fits', balancing speed vs. compiler/interpreter autoboxing/ autounboxing hinting Most people in Perl would be happy with multbig, because frankly they don't care that their math takes .1 ms rather than .0001 ms (or whatever). But the set of people that really would rather have superfast math could drop over to multint. And, a notional Perl6 optimizing compiler could use multsmallest when it detects the conditions are right. Another concern besides speed might be sizeof(PMC) for each of the options...some of the genome/nasa guys could get kinda twitchy if bignum is 1k per, etc., etc. F.
Re: Something to ponder
Aaron writes: COME FROM is very different, and (as with much of Intercal) was created specifically to be obtuse. Discussing it as if it's a useful feature tends to creep me out because I get the feeling someone might actually put it in a language I care about. I feel the same way about gethostent, picture formats and blockless 'package'. And AOP, Swing and ATL, for that matter. Que sera etc. Felix
Re: Something to ponder
Dan writes:
sub foo :come_from('+', int, int) {}
One problem with MMD in general, and return specifically, is
'what happens if multiple M match the same D requirements?
i.e.,
sub foo :come_from('+', int, int) { shift; shift builtin::+ shift };
sub bar :come_from('+', int, int) { shift; shift builtin::* shift };
If the answer is 'all get executed', this could be useful for
any languages interested in implementing aspect-oriented programming
as a first class language feature, e.g.
sub debug_log :come_from(:benchmark_me) {
my $function_name = shift;
print STDERR debug: $function_name at . time() . \n;
}
sub notify_with_pager :come_from(:notify_me) {
...
}
sub foo :benchmark_me { ... } # gets benchmarked
sub bar :benchmark_me :notify_with_pager { ... } # benched and notified
sub baz { ... } # not so much with the benchmarking
If the answer is 'the second match is a syntax error'...well,
that spoils the fun, but who said talking about continuations was
supposed to be fun?
F.
Re: Something to ponder
Aaron writes:
Ok, this is starting to look like people speaking seriously about using
Intercal's COME FROM (http://c2.com/cgi/wiki?ComeFrom)... can we just
step back and take a deep breath of AIR please? Seriously, this is
starting to creep me out.
In case anyone reading this is getting confused, here are
some other interesting links:
Aspect Oriented Programming primer: ('come from' for Java)
http://www.onjava.com/pub/a/onjava/2004/01/14/aop.html
The original intercal specification (a must read; this is
the version without the taint of esr):
http://www.muppetlabs.com/~breadbox/intercal/intercal.txt
I don't know why Aspect Oriented Programming would creep you out.
It seems to have a moderately devout following amongst a certain
sect of Java programmers, and certainly there are places where
it's clearly a ... well, I won't say a good idea, but at least
a comprehensible one. Being able to implement AspectJ 'natively'
rather than via a set of C++-like preprocessor hacks is not
necessarily a bad thing. Even the fact that esr already did it
in a joke language is neither here nor there.
Anyway, Parrot could never implement COME FROM for real, because
it doesn't support the notion of STEP:
20 COME FROM 70 STEP 20
Felix
[need input] interpreter permissioning
The summary: request for architectural analysis.
The motivation: there are certain languages, possibly including perl 6,
that will benefit from the ability to flow from one parrot interpreter
to another. For example:
#!//googlestorage/programs/perl7.08032005
use remote qw( :googlecompute-shared :ibmgrid1 compute.delictis.com );
sub remote_num_of_users {
on remote { use local settings; return $hostname, $current_users };
}
my $values = remote_num_of_users;
foreach my $i (keys %{ $values }) {
print join ('\t', ($i, values-{$i}, \n));
}
felix-ipod1 $ ./remote_users.pl
googlecompute1.google.com588345
googlecompute2.google.com249382
googlecompute3.google.com291991
googlecompute4.google.com188126
googlecompute5.google.com328340
googlecompute6.google.com 49392
ibm-compute-public1.grid.ibm.com38289
ibm-compute-public2.grid.ibm.com39482
ibm-compute-public3.grid.ibm.com 6004
ibm-compute-public4.grid.ibm.com 493
compute.delictis.com 2
Trivial enough. However, for security reasons permissioning has
to exist at the bytecode/interpreter level, because you may wish
to assign per-user permissions on the following axes:
cpu time (ulimit style)
clock time (ulimit style)
disk (ulimit style)
memory (ulimit style)
namespace access
PMC (user-level functions, variables (e.g., %ENV, etc.)
individual builtins (looping, 'my', assignment, etc.)
Is anyone aware of any reason why the straightforward approach --
implementing a per-thread 'running restricted' flag, an extra if
branch in the bytecode interpreter code paths, a bytecode to
flip into restricted mode*, and a per-PMC permission 3-bit (rwx)
permission bitmask -- would not be the best solution?
Are there any early concerns or optimizations anyone can envisage?
Thanks --
Felix
Re: [need input] interpreter permissioning
Dan writes: Anyway, there *is* a threefold plan, involving quotas, privileges/capabilities, and restricted embedding environments. If there's a link out there, I must've missed it. Is there one? clock time (ulimit style) This'd be a per-interpreter, per-user quota. Depending on how 'interpreter' is to be, ah, interpreted, that may be too large a grain -- a language may want to have a set-up period during which the rules don't apply, and also a thread (for monitoring purposes, or other) to which the rules apply or don't. e.g., #!//googlestorage/programs/concurrent_basic.08012005 10 ? HELLO WORLD! NOW DOING SETUP 20 USE MODULE IRC::SERVER 30 USE REMOTE ALLOW PUBLIC :LOW-QUOTA TO GOSUB 60 IN PARALLEL 40 GOSUB IRC::SERVER::SETUP counts against perms/quota in this interp? 50 GOTO DO_INTERESTING_STUFF does not return; counts against perms/quota? 60 ARGUMENT X 70 PRINT X TO REMOTES 80 RETURN If by interpreter you mean thread then I'm with you, though. Or if each thread has-a new interpreter, that also is the good stuff. [...] Quotas. [...] Privileges [...] Also privileges. [...] Privs, possibly quotas and the embedding environment for IO and event type things. You've got it covered. So where's the spec? Is anyone aware of any reason why the straightforward approach -- [...] would not be the best solution? Mainly because it's a bit too restrictive. Man, I thought I had a bad case of second systems effect...but you're working on, like, ninth. I genuflect. What I'm planning on is a VMS-style quota, privilege, and identifier system. Pagan heretic -- you shall burn in the purifying flames of RSTS/E! (Or, rather, an extendable privilege system where extra privs can be defined and set/reset) Nothing too fancy, but expressive enough to allow for reasonable control over restricted interpreters. Can you provide a short example of what 'extra privs can be defined and set/reset' means? I haven't touched VMS in about two decades. Felix
Re: Something to ponder
On Tue, Aug 17, 2004 at 04:08:34PM -0400, Dan Sugalski wrote: 1) We're going to have MMD for functions soon 2) Function invocation and return continuation invocation's essentially identical 3) Therefore returning from a sub/method can do MMD return based on the return values Someone probably ought to think about what sort of syntax you might add to a language to take advantage of this... the two-dimensional '+' results-distribution operator, naturally. #!/usr/bin/perl9 $x -\ \ @mylist -+--- $obj.mymmdsub; / %hash --/ F.
