Re: Concerns about {...code...}
On Thu, Dec 20, 2007 at 11:35:44AM -0600, Jonathan Scott Duff wrote:
On Thu, Dec 20, 2007 at 11:23:05AM -0600, Jonathan Scott Duff wrote:
Adriano answered #1 I think: $yaml = Q:!c{ $key: 42 };
Er, I just looked over the spec again and realized that Q does
absolutely no interpolation, so it would be more like this:
$yaml = Q:qq:!c{ $key: 42 };
or perhaps
$yaml = qq:!c{ $key: 42 };
To me they look like abominations. Is there any pressing need to have code
interpolate, other than for simple convenience?
--
You may not work around any technical limitations in the software
-- Windows Vista license
Re: Year ranges in copyright information in source files
On Wed, Aug 29, 2007 at 02:44:13PM +0200, Paul Cochrane wrote: I've recently added a test to the coding standards tests which checks for a copyright statement, and that the copyright date is up to date. After a discussion on #parrot, Coke made the observation that maybe the most recent date shouldn't be the same as the current year because the file might not have been updated for a couple of years. So, the question I'd like to post to the list is: how do we define the year range in the copyright statement in source files? Should it be Cstart-year-Ccurrent-year or Cstart-year-Cyear-last-updated? The perl 5 practice is to list every year in which there were modifications to the file. Apparently year ranges are a bit dodgy, legally speaking. Including the current year is just wrong. -- Foul and greedy Dwarf - you have eaten the last candle. -- Hordes of the Things, BBC Radio.
Re: Remember: Outlaw to declare a lexical twice in the same scope
On Sat, Jan 27, 2007 at 10:23:03AM +0100, Carl Mäsak wrote:
my $foo;
# ...later in the same scope...
my $foo; # illegal Perl5, legal Perl6
No, that's perfectly legal in perl5; it just generates a warning:
use warnings;
my $x = 1;
my $f1 = sub { $x };
my $x = 2;
my $f2 = sub { $x };
printf f1=%d f2=%d x=%d\n, $f1-(), $f2-(), $x;
which gives
$ perl588 /tmp/p
my variable $x masks earlier declaration in same scope at /tmp/p line 6.
f1=1 f2=2 x=2
--
But Pity stayed his hand. It's a pity I've run out of bullets,
he thought. -- Bored of the Rings
Re: List assignment question
On Wed, Nov 15, 2006 at 11:17:57PM +, Nicholas Clark wrote: I thought that allowing undef in my ($a, undef, $b) came in around 5.004ish, but I can't find it in perldelta, and I don't have a version compiled to test with (or any quick way to compile them, given that pretty much only AIX is so stable that early perls compile unmodified. Probably someone will tell me that VMS is also good enough, for 5.002 or later) $ perl-5322 -we'my ($x,undef,$y) = 1..3' Can't declare undef operator in my at -e line 1, near ) = Execution of -e aborted due to compilation errors. $ perl545 -we'my ($x,undef,$y) = 1..3' $ -- There's something wrong with our bloody ships today, Chatfield. -- Admiral Beatty at the Battle of Jutland, 31st May 1916.
Re: pdd20 and :outer
On Tue, Nov 22, 2005 at 09:32:37AM -0800, Chip Salzenberg wrote:
On Tue, Nov 22, 2005 at 03:28:02PM +0100, Leopold Toetsch wrote:
sub do_add3 {
my $a = $_[0];
sub add3 {
$a + 3;
}
add3();
}
What Perl 5 does with that case is just a plain old bug, or more
precisely, a consequence of how Perl 5 implements capturing a lexical
environment. It's just bad. Don't even try supporting it.
As the current owner of the perl5 closure code, (and as someone who
hasn't been following this thread :-( ), I'm interested to know what the
p6 semantics of this are. The p5 semantics seem to me to be logical and
consistent, if not particularly useful in this case: ie subs capture their
outside lexical scope at the time they are created. So at compile time,
add3() captures the first instance of do_add3()'s $a and hangs onto it for
dear life.
In p6, will $a remain shared between the two subs? In which case, at what
point is $a considered to have gone out of, or come into scope, from the
perspective of creating and destroying instances of lexicals variables?
Dave
--
Monto Blanco... scorchio!
Re: Some bison 2.1 experiments on the darwin powerbook ...
On Sun, Nov 13, 2005 at 11:58:39AM -1000, Joshua Hoblitt wrote: I started a thread about this a couple of weeks ago. I really think that bison 1.75c should be the minimum requirement. Note also that bison 1.24 has licencing issues, in that the generated output files are GPLed. -- Art is anything that has a label (especially if the label is untitled 1)
Re: use fatal err fail
On Tue, Oct 18, 2005 at 11:06:22AM +0100, Nicholas Clark wrote: Likewise. A certain reputable OS vendor's NFS implementation went multithreaded, with the result that close() was now where the over quota error was reported, rather than the individual writes. Said reputable OS vendor's own C compilers weren't checking close(), so they were caught out by this too. If it's the vendor I'm thinking of, their compress(1) command didn't check for close() errors either. The net result of this was that when my NFS users went over quota, then tried to make space by compressing some files, they ended up with lots of zero-sized foo.Z files with the original foo deleted. They were not happy bunnies. -- Technology is dominated by two types of people: those who understand what they do not manage, and those who manage what they do not understand.
Re: $value but lexically ...
On Fri, Oct 07, 2005 at 03:46:02PM -0600, Luke Palmer wrote:
Uh no. Okay, when I said that they don't close, I guess I meant
they don't close like anonymous routines do. It works precisely like
Perl 5's:
sub foo {
my $foo = 5;
sub bar {
return $foo;
}
return \bar;
}
I don't think I've ever seen that used in Perl 5. Closing over that
$foo doesn't mean anything.
Well strictly speaking it means that bar() captures the first instance of
foo()'s $foo, which isn't often very useful.
--
The Enterprise successfully ferries an alien VIP from one place to another
without serious incident.
-- Things That Never Happen in Star Trek #7
Re: [perl #16622] [PATCH PDD07] Document struct naming conventions
On Mon, Sep 19, 2005 at 11:18:17PM -1000, Joshua Hoblitt wrote: On Tue, Sep 20, 2005 at 12:33:38AM -0700, Brent 'Dax' Royal-Gordon wrote: I submitted the patch below my sig way back in August 2002, in ticket 16622. It documented the then-current naming conventions for structures. Is it still accurate and/or a good idea? Should it (or an up-to-date version of it) be committed? Yet another year has rolled by. Do you still want this change to be considered? Certainly. Note that the naming conventions are now being followed by Interp and friends. Dave Mitchell [EMAIL PROTECTED] is listed as the maintainer for that PDD. Perhaps he can comment on the proposal? I'm not currently involved with perl6/parrot (too busy with perl5), so as far as I'm converned, my ownership of that PDD has lapsed. -- Do not dabble in paradox, Edward, it puts you in danger of fortuitous wit. -- Lady Croom - Arcadia
Re: How much do we close over?
On Sun, Jun 12, 2005 at 11:26:49PM +0100, Piers Cawley wrote:
Chip and I have been having a discussion. I want to write:
sub foo { my $x = 1; return sub { eval $^codestring } }
say foo()($x);
I claim that that should print 1. Chip claims it should throw a warning
about because of timely destruction. My claim is that a closure should
close over the entire lexical stack, and not simply those things it uses
statically. Chip claims the opposite, arguing that timely destruction
implies that this is absolutely the right thing to do. It's also
quicker.
I'm with Chip on this one. In fact, year ago I specifically fixed
bleedperl so that it gives this runtime warning:
$ perl592 -we 'sub f { my $x; sub { eval q($x)} } f()-()'
Variable $x is not available at (eval 1) line 2.
But dammit, I'm doing runtime evaluation of code strings, I don't care about
quicker.
You may be using slow evals, but other fast code may not be. Should the
closure in
sub foo { my $x = 1; return sub { 1 } }
also capture the current instance of $x? You are basically condeming any
code that creates any closure, however simple, to basically hang on to
just about any data that has ever existed, in the vague hope that maybe,
just maybe, some day some code may use an eval and make use of that data.
If it's not the default can it please be mandated that there be some way of
doing:
sub foo { my $x = 1; return sub is lexically_greedy {eval $^codestring} }
in other words, some way of declaring that a subroutine wants to hang onto
every lexical it can see in its lexical stack, not matter what static analysis
may say.
I have no opinion on that.
--
This is a great day for France!
-- Nixon at Charles De Gaulle's funeral
Re: How much do we close over?
On Sun, Jun 12, 2005 at 06:22:22PM -0500, Rod Adams wrote:
Well, you could always do something like:
sub foo { my $x = 1; return sub {my $x := $OUTER::x; eval $^codestring} }
In perl5, that would just be
sub foo { my $x = 1; return sub { $x ; eval $_[0]} }
--
You live and learn (although usually you just live).
Re: BEGIN and lexical variables inside subroutines
On Thu, May 12, 2005 at 09:06:48PM +0100, Benjamin Smith wrote:
sub foo { my $x; BEGIN { $x = 3 }; say $x }
foo; foo; foo;
Currently in perl5 and pugs this prints 3\n\n\n.
Should BEGIN blocks be able to modify values in lexical variables that
don't really exist yet? (People can use state after all to get a
variable which does exist early enough for them to modify.)
Is there some kind of prototype pad (and lexicals) available inside
the BEGIN block, rather than a full runtime pad?
In perl5, the first instance of a lexical exists from the moment of
compilation through till first exit from the enclosing scope during
exection. If this wasn't the case then lots of closure-related stuff
wouldn't work, eg
{
my $count = 0;
sub inc { $count++ }
sub dec { $count-- }
}
...
--
print+qq$}$$/$s$,[EMAIL PROTECTED],$:$.$q$^$,[EMAIL
PROTECTED];$.$q$mif+map{m,^\d{0\,},,${$::{$'}}=chr($+=$||1)}q10m22,42}6:[EMAIL
PROTECTED];^2dg3q/s=~m*\d\*.*g
Re: parrot and refcounting semantics
On Thu, Apr 28, 2005 at 05:57:10PM +0200, Robin Redeker wrote: Just because refcounting is error-prone it doesn't mean that a garbage collector is better (and less error-prone). I'm one of the maintainers of the perl5 core. perl5 is very mature, with relatively few new features being added, and much emphasis on fixing existing bugs. A quick look at my last 60 patches shows that about 1/3 of them were related to ref count and memory leak bugs. Ref counting is near impossible to get 100% right. One of the advantages of GC over RC is that you are automating the process, and once the automation has the bugs wrinkled out of it, the whole rest of your code reaps the advantages. With RC, every single line of code in the core (and extensions) has to be carefully thought about to make sure there aren't leaks or premature frees, and every single change risks introducing new errors. (On the other hand, I *enjoy* hunting down refcnt bugs, so Down With GC !! :-) -- That he said that that that that is is is debatable, is debatable.
Re: Scope exit and timely destruction
On Fri, Jan 14, 2005 at 02:40:43PM -0700, Luke Palmer wrote: What I'd most like is to convince Larry to waive the timely destruction requirement. However, that doesn't really solve the problem for other languages that need timely destruction. Are there any? Perl 5 springs to mind !!! -- The crew of the Enterprise encounter an alien life form which is suprisingly neither humanoid nor made from pure energy. -- Things That Never Happen in Star Trek #22
Re: Why lexical pads
On Fri, Sep 24, 2004 at 09:30:22AM -0700, Steve Fink wrote:
But I agree that it is doing a name lookup in the string eval case.
Although if you try it, you get puzzling results:
perl -le 'sub x {my $foo = 1; return sub { eval q($foo++) } };$x=x();print
$x-(), $x-(), $x-()'
prints 012 again. Which confused me, because Perl *can* do named lookups
of lexicals. The problem, apparently, is that it's doing the lookup but
not finding it.
With bleedperl, you'd get
$ ./perl -wle 'sub x {my $foo = 1; return sub { eval q($foo++) } };$x=x();print
$x-(), $x-(), $x-()'
Variable $foo is not available at (eval 1) line 1.
Variable $foo is not available at (eval 2) line 1.
Variable $foo is not available at (eval 3) line 1.
000
$
--
Now is the discount of our winter tent
-- sign seen outside camping shop
Re: push @bar, .splice;
On Sat, Jul 17, 2004 at 06:53:28PM +0200, Juerd wrote:
If an array element knows that it is an array element, this can be
useful:
for @foo { push @bar, .splice if EXPR }
What happens if the element is an element of more than one array?
--
A power surge on the Bridge is rapidly and correctly diagnosed as a faulty
capacitor by the highly-trained and competent engineering staff.
-- Things That Never Happen in Star Trek #9
Re: P6C: Parser Weirdness
On Thu, May 13, 2004 at 12:22:09PM -0700, Larry Wall wrote: No, you still have the four basic actions. Subparsing is all hidden in the lexer. Hence why the lexer in Perl 5 is 8000 lines long ;-) -- Wesley Crusher gets beaten up by his classmates for being a smarmy git, and consequently has a go at making some friends of his own age for a change. -- Things That Never Happen in Star Trek #18
Re: File stat info
On Thu, Apr 29, 2004 at 08:36:11AM +0300, Jarkko Hietaniemi wrote: But for things like -r file open(FH, file) they are of rather dubious value. Well, I have some scripts that check at the start whether all the things they going to need are readable/executable/whatever, so that they can (mostly) bomb out right at the start rather than failing halfway through and leaving a mess. -- This email is confidential, and now that you have read it you are legally obliged to shoot yourself. Or shoot a lawyer, if you prefer. If you have received this email in error, place it in its original wrapping and return for a full refund. By opening this email, you accept that Elvis lives.
Re: backticks
If hypothetically we *are* going to have a simplfied constant-index hash
access syntax, is there any reason why we can't use a single quote (')
rather than backtick ('), akin to the Perl4-ish package separator,
ie %foo'bar rather than %foo`bar?
On the grounds that personally I hate the backtick :-)
--
That he said that that that that is is is debatable, is debatable.
Re: Magic blocks (was: Compile-time undefined sub detection)
On Sat, Mar 06, 2004 at 06:39:44PM -0800, Larry Wall wrote:
my @x will begin {...} # at BEGIN time
my @x will check {...} # at CHECK time (redefined to unit check)
my @x will init {...} # at INIT time
my @x will end {...}# at END time
Sorry, perhaps I wasn't paying close enough attention, but suddenly we've
leaped from oddly named subs that get called at interesting times, to
array variables with oddly-named properties (or attributes, or whatever).
Je ne comprend pas :-(.
Dave.
--
A walk of a thousand miles begins with a single step...
then continues for another 1,999,999 or so.
Whither Apocalypse 7?
Did I miss something? Was there ever an apocalyse 7? Also, why aren't the apocalyses and excegises announced on any of the p6 lists (like, er, perl6-announce for example)? Yours grumpily, Dave. -- My get-up-and-go just got up and went.
Re: Semantics of vector operations
On Wed, Jan 21, 2004 at 04:01:43PM -0500, Austin Hastings wrote: Perhaps the right way to vectorize the arguments is to delimit them with vectorization markers? @a + $b or @a + @$b even! -- Justice is when you get what you deserve. Law is when you get what you pay for.
Re: Optimization brainstorm: variable clusters
On Fri, Jan 16, 2004 at 09:27:57AM -0500, Dan Sugalski wrote:
With perl, for example, it's distinctly possible that this:
our $foo; # It's a global
$foo = 12;
if ($foo 10) {
print $foo;
}
will require fetching $foo's PMC out of the global namespace three
times, once for each usage. I don't know offhand if this is how perl
5 works (I think it might be)
In Perl5, a pointer to the GV is cached in the GVSV op (or in the case of
threaded builds, in the pad (with an index into the pad stored in the op
(is that enough levels of parenthesis for you?))). So if the stashes were
tied, you'd be stuffed. There was a recent thread on p5p as to whether
tieing of stashes should be disallowed.
--
The perl5 internals are a complete mess. It's like Jenga - to get the
perl5 tower taller and do something new you select a block somewhere in
the middle, with trepidation pull it out slowly, and then carefully
balance it somewhere new, hoping the whole edifice won't collapse as a
result.
- Nicholas Clark.
Re: Optimization brainstorm: variable clusters
On Sat, Jan 17, 2004 at 04:58:25PM +, Simon Cozens wrote: [EMAIL PROTECTED] (Dave Mitchell) writes: The perl5 internals are a complete mess. It's like Jenga - to get the perl5 tower taller and do something new you select a block somewhere in the middle, with trepidation pull it out slowly, and then carefully balance it somewhere new, hoping the whole edifice won't collapse as a result. - Nicholas Clark. I thought I'd seen that before: http://www.oreillynet.com/pub/wlg/555 Oooh, plagiarism! Sue sue sue! I'll update the attribution for future .sigs. -- Any [programming] language that doesn't occasionally surprise the novice will pay for it by continually surprising the expert. -- Larry Wall
Re: Thread Question and Suggestion -- Matt
On Sat, Jan 03, 2004 at 08:24:06PM -0500, Matt Fowles wrote: All~ I have a naive question: Why must each thread have its own interpreter? I understand that this suggestion will likely be disregarded because of the answer to the above question. But here goes anyway... Why not have the threads that share everything share interpreters. We can have these threads be within the a single interpreter thus eliminating the need for complicated GC locking and resource sharing complexity. Because all of these threads will be one kernel level thread Why on earth would they be all one kernel-level thread? -- Monto Blanco... scorchio!
Re: Threads Design. A Win32 perspective.
On Sat, Jan 03, 2004 at 08:05:13PM +0100, Elizabeth Mattijsen wrote: At 18:20 + 1/3/04, Nigel Sandever wrote: Sharing data between the threads/interpreters is implemented by tieing the two copies of the variables to be shared and each time a STORE is performed in one thread, the same STORE has too be performed on the copy of that var held on every other threads dataspace. Hmmm is that true? My impression was (and that's the way I've implemented it in Thread::Tie) is that each STORE actually stores the value in a hidden background thread, and each FETCH obtains the current value from the background thread. I don't think each STORE is actually cascading through all of the threads. Not until they try to fetch the shared value, anyway. Sharing consists of the real SV living in a shared interpreter, with each individual thread having a lightweight proxy SV that causes the appropriate real SV to be accessed/updated by a mixture or magic and/or tied-ish access. A particular access by one thread does not involve any of the other threads or their proxies. With ithreads, there can be no shared references, so no shared objects and no shared compound data structures Actually, you can bless a reference to a shared variable, but you can't share a blessed object (the sharing will let you lose the content of the object). I think shared compound data structures _are_ possible, but very tricky to get right (because the CLONE sub is called as a package method, rather than as an object method: see Thread::Bless for an attempt at getting around this). Nested shared structures work just fine, and there's no need to mess with CLONE for plain data. And the reaction from those wh have tried to make use of ithreads under p5 are all too aware that replicating them for Parrot would be . [phrase deleted as too emotionally charged:)] It's the implementation of ithreads in p5 that sucks, not the concept itself. The use of COW makes new thread creation cheap, and the use of lock PMCs interposed on the real PMCs makes shareing easy. Dave. -- O Unicef Clearasil! Gibberish and Drivel! - Bored of the Rings
Re: Threads. Design. Go for it
On Thu, Jan 01, 2004 at 11:21:57AM -0800, Jeff Clites wrote: As far as what level needs to implement them, I'd say that parrot has to do enough to make it possible for an HLL to expose ithreads-style threading. Due to the cross-language nature of parrot, practically speaking this probably means that the semantic needs to exist at the parrot level. (For instance, an ithread created in Perl code could load a parrot bytecode library implemented in Python; calling into code inside this library shouldn't allow access to unshared data from other ithreads.) The other big thing about ithreads is that the 'not shared by default' model implies that each time a new thread is created by a request from the HLL, the whole current interpreter state must be copied (or some COW scheme interposed0) so that when the new thread makes changes to a pre-existing variable, that change isn't seen by any of the ancestor threads. That implies some support from parrot. -- O Unicef Clearasil! Gibberish and Drivel! - Bored of the Rings
Re: threads and shared interpreter data structures
On Tue, Dec 23, 2003 at 11:07:53AM +0100, Elizabeth Mattijsen wrote:
At 10:37 +0100 12/23/03, Leopold Toetsch wrote:
2) the Perl5ish declaration
my $var : shared;
is basically:
$P0 = new SharedPerlUndef;
OTOH:
share($var);
may need to morph $var into a shared reference, with an additional
indirection and memory overhead.
(I don't know, what Perl5 does with an already used $var, that is
turned into a shared var later - or even at runtime).
$ perl5.8.2-threaded -Mthreads -Mthreads::shared -MO=Deparse -e 'my
$a : shared = 1'
use attributes ();
('attributes'-import('main', \$a, 'shared'), my $a) = 1;
$ perl5.8.2-threaded -Mthreads -Mthreads::shared=share -MO=Deparse -e
'my $a = 1; share( $a )'
my $a = 1;
share $a;
Both the share() function as well as the :shared attribute, operate
at runtime in Perl5. This is especially awkward for the :shared
attribute.
Sharing of lexical vars has to be done at run-time, since each time the
scope is entered, you need to create a new instance of the variable.
--
Do not dabble in paradox, Edward, it puts you in danger of fortuitous
wit. -- Lady Croom - Arcadia
Re: The Block Returns
On Thu, Oct 16, 2003 at 01:46:30AM +0100, Simon Cozens wrote: [EMAIL PROTECTED] (Larry Wall) writes: But for the time being I'm tied to an IV pole We got rid of those; they're PMC poles now. Get well soon, Ditto! Dave. -- Little fly, thy summer's play my thoughtless hand has terminated with extreme prejudice. (with apologies to William Blake)
Re: An evil task for the interested
On Thu, Oct 09, 2003 at 11:43:41AM -0400, Dan Sugalski wrote: We've got ordered destruction on the big list 'o things to do, and it looks like we need to get that done sooner rather than later. So, this is a good chance for someone to burn those surplus SAN points and become one with the great gibbering chaos at the center of the universe (no, wait, that's not it) by digging into the DOD system. Not a huge task, we just need to order PMCs before destroying them, to make sure we don't call the destructor for a PMC before we destroy the things that depend on it. A quick run through the PMC pools to build up a dependency chain if there's more than one PMC that needs destruction should do it. I always thought that was a rather hard issue, due to circular dependencies. It's certainly the case that Perl5 is very poor at global destruction of objects. -- SCO - a train crash in slow motion
Re: The Block Returns
On Thu, Oct 02, 2003 at 04:15:06AM -0600, Luke Palmer wrote:
And to clarify:
sub indexof(Selector $which, [EMAIL PROTECTED]) {
for zip(@data, 0...) - $_, $index {
when $which { return $index }
}
}
Which actually creates a closure (well, in theory at least) on line 2
for the for loop, but the return inside of it returns from indexof.
Which is actually very, very nice.
So the question is: What happens when indexof isn't on the call chain,
but that inner closure is?
But how can the inner closure be called if not via indexof?
--
To collect all the latest movies, simply place an unprotected ftp server
on the Internet, and wait for the disk to fill
Re: Timely Destruction: An efficient, complete solution
On Wed, Aug 20, 2003 at 06:40:51PM -0400, Benjamin Goldberg wrote:
Dave Mitchell wrote:
On Sun, Aug 17, 2003 at 05:48:14AM -0600, Luke Palmer wrote:
Here comes that ever-reincarnating thread again, sorry.
This is a proposal for an efficient solution to the timely destruction
problem, which doesn't use refcounting, and fits in to the current
scheme pretty well.
I don't quite follow all the below (probably mainly due to my
infamiliarity with parrot's DOD/GC stuff).
Would it be possible to illuminate it by explaining how the following
Perl5 code (presumably being executed by Ponie/Parrot) would ensure that
the two destructors are called at the places marked:
{
my $ref;
{
my $obj1 = Foo-new(...);
my $obj2 = Foo-new(...);
$ref = $obj1;
} # $obj2-DESTROY called here
# ...
} # $obj1-DESTROY called here
# ...
At each of the two end-of-scope braces, a sweep 0 instruction would be
emmited. This performs Dead Object Detection, which at the first }
detects that $obj2 is dead, and at the second } detects that $obj1 is
unreachable.
Yeah, I understood that bit. It was all the stuff about lists of
high-priority and low-priority objects etc that I got lost in. In
particular how does it detect that $obj2 should be kept alive at the end
of the inner block withoput doing a *full* DoD sweep? Since I presume
that's what the proposal was intended to avoid.
--
There's something wrong with our bloody ships today, Chatfield.
Admiral Beatty at the Battle of Jutland, 31st May 1916.
Re: Timely Destruction: An efficient, complete solution
On Sun, Aug 17, 2003 at 05:48:14AM -0600, Luke Palmer wrote:
Here comes that ever-reincarnating thread again, sorry.
This is a proposal for an efficient solution to the timely destruction
problem, which doesn't use refcounting, and fits in to the current
scheme pretty well.
I don't quite follow all the below (probably mainly due to my
infamiliarity with parrot's DOD/GC stuff).
Would it be possible to illuminate it by explaining how the following
Perl5 code (presumably being executed by Ponie/Parrot) would ensure that
the two destructors are called at the places marked:
{
my $ref;
{
my $obj1 = Foo-new(...);
my $obj2 = Foo-new(...);
$ref = $obj1;
} # $obj2-DESTROY called here
# ...
} # $obj1-DESTROY called here
# ...
It is based on the fact that 90% of the time (or more), all objects
needing timely destruction will be found live. It uses a priority
method to try to find these objects quickly, and ceases if it does.
This behavior is only carried out if the DOD was invoked by Csweep 0.
There is an external list of objects needing timely destruction, which
is not walked by DOD. Each object has a DOD_high_priority_FLAG. Each
time an impatient object is created, its high_priority_FLAG is set.
As everything is walked, if an object with this flag set is encountered,
whichever thing referenced it also gets the flag set[1].
The DOD queue has two segments: high_priority and low_priority.
high_priority is always drained and processed first. When this portion
of the queue is completely drained, the external list of impatient
objects is checked. If every object has been marked live, DOD
terminates (and GC is not allowed to run, because that would result in a
lot of wrongly murdered objects). If there are dead objects in that
list, DOD continues and does a full sweep.
When an impatient object is destructed, it might be good to reset all
high_priority_FLAGs, except for other impatient objects, so there is
nothing being walked at high priority that doesn't deserve it.
That's it. The first few times Csweep 0 is run, it will take just as
long as Csweep 1, but the priorities will propogate down to things in
the root set, and it will begin to speed up. And the algorithmic
complexity never exceeds that of a regular sweep[2].
Luke
[1] This probably has to be done when the object is enqueued, not
dequeued. I don't know whether this impacts performance significantly.
See [2].
[2] Although a single cycle of the algorithm becomes more complex, so it
will slow things down a little when it's not doing any good. But at the
expense of a little templating, these checks could be eliminated when
the sweep wasn't triggered by Csweep 0.
--
print+qq$}$$/$s$,[EMAIL PROTECTED],$:$.$q$^$,[EMAIL
PROTECTED];$.$q$mif+map{m,^\d{0\,},,${$::{$'}}=chr($+=$||1)}q10m22,42}6:[EMAIL
PROTECTED];^2$g3q/s=~m*\d\*.*g
Re: This Week's Summary
On Mon, Aug 11, 2003 at 07:32:00PM -, Rafael Garcia-Suarez wrote: Will I really be forced to reimplement the whole subrecursive frobnizer for tied magic ? Almost certainly, I expect. -- There's something wrong with our bloody ships today, Chatfield. Admiral Beatty at the Battle of Jutland, 31st May 1916.
Re: Cothreads
On Wed, May 28, 2003 at 07:58:37AM -0700, Austin Hastings wrote: On a single-CPU box, the OS level threads could easily be used to support blocking operations feeding back to async I/O, while all real work (execution of opcodes) was done in a single thread. Parrot could elect to implement threading on its own. In fact, if consistency of execution is a design objective, it probably should. And on a multiple CPU box...? -- Never do today what you can put off till tomorrow.
Re: Cothreads
On Tue, May 27, 2003 at 02:05:57PM -0700, Michael Lazzaro wrote: If we could think about threads not in terms of forkyness, but simply in terms of coroutines that can be called in parallel, it should be possible to create an implementation of threading that had to do a whole heck-of-a-lot less duplication of state, etc. Things outside the scope of the thread group would automatically be shared(?), things inside the thread group would not be shared unless explicitly marked as such. Which, if I read it right, is what you proposed too, but with a slightly different syntax. That _might_ make threads a heck of a lot faster upon creation/startup, and a lot less bulky in general. But underneath, these pretty coroutiney/virtual-threads still have to to be implemented in terms of the underlying OS's real threads, so parrot will have to start being really clever applying locks and mutexes all over the place to all those outer bits that are shared etc. So while you may get a cleaner high-level interface to threading behaviour, I don't think you're gonna gain speed and or bulkiness. But I could be wrong. Stranger things have been known :-) -- Blaming Islam for 911 is like blaming Christianity for Oklahoma City.
Re: How shall threads work in P6?
On Tue, Apr 01, 2003 at 08:44:25AM -0500, Dan Sugalski wrote: There isn't any, particularly. We're doing preemptive threads. It isn't up for negotiation. This is one of the few things where I truly don't care what people's opinions on the matter are. Sorry, I haven't been following this too closely - but is it the intention to support the 5.005, or the ithreads model (or both? or neither?). -- To collect all the latest movies, simply place an unprotected ftp server on the Internet, and wait for the disk to fill
Re: Objects, methods, attributes, properties, and other related frobnitzes
On Wed, Feb 19, 2003 at 02:06:55PM +, Peter Haworth wrote:
Shouldn't we be traversing the inheritance tree once, doing these three
steps at each node until one works, rather doing each step once for the
whole tree. MM dispatch probably complicates this, though.
If my derived class has an autoloaded method which overrides the base class'
method, I don't want the base class method to be called, just because parrot
does things in a peculiar order. Well, I know it's the same order that perl5
does things, but it's still peculiar.
I'm no OO expert, but a single traversal sounds right to me too. I am
reminded of various proposals to enhance Perl5's tie interface by allowing
for example, an optional FETCHSLICE method that would be called in
peference to lots of individual FETCHes. This would have caused all sorts
of problems if the FETCHSLICE was later added to a base class, since the
derived class's FETCH method would be ignored in favour of the base
class's new FETCHSLICE method.
--
print+qq$}$$/$s$,$*${$}$g$s$@$.$q$,$:$.$q$^$,$@$*$~$;$.$q$mif+map{m,^\d{0\,},,${$::{$'}}=chr($+=$||1)}q10m22,42}6:17*2~2.3@3;^2$g3q/s=~m*\d\*.*g
Re: Arrays, lists, referencing
On Tue, Feb 18, 2003 at 10:06:29PM -, Smylers wrote: More practically, the length of a list is never interesting: a list by definition must be hardcoded into the program so its length is known at compile time. Indeed it should be known by whoever typed it in! Err, no. Eg in perl 5: $value = (1,2, @ARGV,3,4)[$i] That's a list, and its length is not known at compile time. Dave. -- Nothing ventured, nothing lost.
Re: Shortcut: ?=
On Mon, Feb 03, 2003 at 06:25:09AM -0800, Austin Hastings wrote: The only time this doesn't change type (arguably a bad thing in its own right) is when you're doing boolean ops. And for those, there exist boolean operators. Changing type is a very Perlish thing to do. How 'bout a shortcut for that, something like this: $var ?= 1 : 0; Isn't this the same as C$var = 1; ? No for example, maps to 0. A better example: $var ??= 'succeeded' :: 'failed'; -- You're so sadly neglected, and often ignored. A poor second to Belgium, When going abroad. Monty Python - Finland
Re: Arrays: Default Values
On Fri, Jan 31, 2003 at 05:59:46PM +0100, Leopold Toetsch wrote:
A lvalue param is not strictly reading, but here has to happen something
differently - yes:
IMHO some sort of proxy could be passed here, saying: if you write to
me, this will be at @a[0]. Or auto-vivify the entry.
This is what Perl 5 does at the moment:
$ perl5.8.0 -MDevel::Peek -e 'sub f{Dump($_[0])}; f($a[9])'
SV = PVLV(0x8177118) at 0x8166a74
REFCNT = 1
FLAGS = (GMG,SMG)
IV = 0
NV = 0
PV = 0
MAGIC = 0x816e7e0
MG_VIRTUAL = PL_vtbl_defelem
MG_TYPE = PERL_MAGIC_defelem(y)
TYPE = y
TARGOFF = 9
TARGLEN = 1
TARG = 0x817ad88
SV = PVAV(0x8183bd4) at 0x817ad88
REFCNT = 2
FLAGS = ()
IV = 0
NV = 0
ARRAY = 0x0
FILL = -1
MAX = -1
ARYLEN = 0x0
FLAGS = (REAL)
However, I think this is clumsy and overly complex; since Perl6 allows us
to declare parameters rw or whatever, I think it should always autovivify
unless we know the param is read-only (or in-only, or whatever the correct
terminology is).
--
There's something wrong with our bloody ships today, Chatfield.
Admiral Beatty at the Battle of Jutland, 31st May 1916.
Re: Bytecode metadata
On Sat, Jan 25, 2003 at 05:38:08PM -0800, Sean O'Rourke wrote: The problem's actually _virtual_ memory use/fragmentation, not physical memory or swap. Say you map in 10k small files -- that's 640M virtual memory, just over a fourth of what's available. Now let's say you're also using mmap() in your webserver to send large (10M) files quickly over the network. The small files, if they're long-lived get scattered all over VA-space, so there's a non-trivial chance that the OS won't be able to find a 10MB chunk of free addresses at some point. Yeah, but in pratice, most, if not all the small files will mapped in at startup. It's no different than the situation at the moment on Solaris where XS modules require the .so object to be mmapped in. Weird, I know, but that's why it stuck in my mind. You have to map quite a few files to get this to happen, but it's a real possibility with a 32-bit address space and a long-running process that does many small mmap()s and some large ones. But we'll all be using 64-bit processors by the time parrot's released :-) -- This email is confidential, and now that you have read it you are legally obliged to shoot yourself. Or shoot a lawyer, if you prefer. If you have received this email in error, place it in its original wrapping and return for a full refund. By opening this email, you accept that Elvis lives.
Re: Bytecode metadata
On Sat, Jan 25, 2003 at 06:18:47AM -0800, Sean O'Rourke wrote: On Sat, 25 Jan 2003, Leopold Toetsch wrote: Dan Sugalski wrote: At 5:32 PM + 1/24/03, Dave Mitchell wrote: I just wrote a quick C program that successfully mmap-ed in all 1639 files in my Linux box's /usr/share/man/man1 directory. Linux is not the universe, though. How true. On Solaris, for example, mmap's are aligned on 64k boundaries, which leads to horrible virtual address space consumption when you map lots of small things. If we're mmap()ing things, we want to be sure they're fairly large. Okay, I just ran a program on a a Solaris machines that mmaps in each of 571 man files 20 times (a total of 11420 mmaps). The process size was 181Mb, but the total system swap available only decreased by 1.2Mb (since files mmapped in RO effecctively don't consume swap). I think Solaris and Linux can both cut this. If other OSes can't, then we fallback to reading in the file when necessary. -- Lady Nancy Astor: If you were my husband, I would flavour your coffee with poison. Churchill: Madam - if I were your husband, I would drink it.
Re: Bytecode metadata
On Sat, Jan 25, 2003 at 10:04:37AM -0500, Jason Gloudon wrote: On Thu, Jan 23, 2003 at 08:39:21PM +, Dave Mitchell wrote: This means that a Perl server that relies on a lot of modules, and which forks for each connection (imagine a Perl-based web server), doesn't consume acres of swap space just to have an in-memory image per Perl process, of all the modules. Are you sure the swap space allocation isn't mostly attributable to the poor locality in the Perl process's data structures ? I was using swap space as a loose term to mean virutal memory consumption - ie that resource which necessitates buying more RAM and/or swap disks. The locality wasn't a proplem. -- A walk of a thousand miles begins with a single step... then continues for another 1,999,999 or so.
Re: Bytecode metadata
On Sun, Jan 26, 2003 at 12:40:19AM +, Nicholas Clark wrote:
On Sat, Jan 25, 2003 at 11:43:40PM +, Dave Mitchell wrote:
Okay, I just ran a program on a a Solaris machines that mmaps in each
of 571 man files 20 times (a total of 11420 mmaps). The process size
was 181Mb, but the total system swap available only decreased by 1.2Mb
(since files mmapped in RO effecctively don't consume swap).
11420 simultaneous mmaps in the same process? (just checking that I
understand you)
yep, exactly that. Src code included below.
Maybe I'm paranoid (or even plain wrong) but we (parrot) can handle it
if an mmap fails - we just automatically fall back to plain file loading.
Can dlopen() cope if an mmap fails? Or on a platform which can only
do a limited number of mmaps do we run the danger of exhausting them early
with all our bytecode segments, and then the first time someone attempts
a require POSIX; it fails because the perl6 DynaLoader can't dlopen
POSIX.so? (And by then we've done our could-have-been-plain-loaded
mmaps, so it's too late to adapt)
If there's such a platform, then presumably we don't bother mmap at all
for that platform.
to run: cd to a man directory, then C/tmp/foo *
#include sys/mman.h
#include sys/types.h
#include sys/stat.h
#include unistd.h
#include fcntl.h
#include stdio.h
main(int argc, char *argv[])
{
int i,j;
int fd;
off_t size;
void *p;
struct stat st;
for (j=0; j20; j++) {
for (i=1; iargc; i++) {
fd = open(argv[i], O_RDONLY);
if (fd == -1) {
perror(open); exit(1);
}
if (fstat(fd, st) == -1) {
perror(fstat); exit(1);
}
size = st.st_size;
/* printf(%d %5d %s\n, i, size, argv[i]); */
p = mmap(0, size, PROT_READ, MAP_SHARED, fd, 0);
if (p 0) {
perror(mmap); exit(1);
}
close(fd);
}
printf(done loop %d\n,j);
}
sleep(1000);
}
--
But Sidley Park is already a picture, and a most amiable picture too.
The slopes are green and gentle. The trees are companionably grouped at
intervals that show them to advantage. The rill is a serpentine ribbon
unwound from the lake peaceably contained by meadows on which the right
amount of sheep are tastefully arranged. Lady Croom - Arcadia
Re: Bytecode metadata
On Fri, Jan 24, 2003 at 07:23:04AM +0100, Leopold Toetsch wrote: How many mmap's can $arch have for one program and for all? Could we hit some limits here, if every module loaded gets (and stays) mmap()ed. I just wrote a quick C program that successfully mmap-ed in all 1639 files in my Linux box's /usr/share/man/man1 directory. Note that in Perl5 we already (indirectly) rely on the OS's ability to mmap in the library code for any XS-based modules. -- But Sidley Park is already a picture, and a most amiable picture too. The slopes are green and gentle. The trees are companionably grouped at intervals that show them to advantage. The rill is a serpentine ribbon unwound from the lake peaceably contained by meadows on which the right amount of sheep are tastefully arranged. Lady Croom - Arcadia
Re: Bytecode metadata
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote: My current idea for the in memory format of the bytecode is this: I would strongly urge any file-based byte-code format to arranged in such a way that it (or most of it) can simply be mmap-ed in (RO), analogously to executables. This means that a Perl server that relies on a lot of modules, and which forks for each connection (imagine a Perl-based web server), doesn't consume acres of swap space just to have an in-memory image per Perl process, of all the modules. This is a real problem that's hitting me hard with Perl 5 in my day job. Dave. -- Any [programming] language that doesn't occasionally surprise the novice will pay for it by continually surprising the expert. - Larry Wall
Re: Perl6 Operator List, Damian's take
On Wed, Oct 30, 2002 at 06:51:14AM +1100, Damian Conway wrote: String complement treats the value as a string then bitwise complements every bit of each character. Is that the complement of the codepoint or the individual bytes? (I'm thinking utf8 here). -- Nothing ventured, nothing lost.
Re: vector vs. hyper
On Tue, Oct 29, 2002 at 02:55:57PM -0500, Uri Guttman wrote:
damian's syntax table and his use of the term vectorizing made me wonder
why we call his [op] thing a hyperoperator? the word hyper i assume came
from hyperdimensional. but calling [] the vectorizing (or just vectored)
op variant makes much more sense.
I vote for 'vector' too. I also really like the [] idea.
--
print+qq$}$$/$s$,$*${$}$g$s$$.$q$,$:$.$q$^$,$$*$~$;$.$q$mif+map{m,^\d{0\,},,${$::{$'}}=chr($+=$||1)}q10m22,42}6:17*2~2.33;^2$g3q/s=~m*\d\*.*g
Re: Perl6 Operator List
On Fri, Oct 25, 2002 at 11:27:54AM -0700, Michael Lazzaro wrote: ||!!//- boolean operations = ||= !!= //= and orxor Hmmm, given Larry's comments just now about about similar things not looking similar, I really think | vs ! is a mistake. From a distance, (14 inches in my case), they really do look almost indistinguable. (IMHO) -- Strange women lying in ponds distributing swords is no basis for a system of government. Supreme executive power derives from a mandate from the masses, not from some farcical aquatic ceremony. Dennis - Monty Python and the Holy Grail.
Re: Parrot long-term goals/prospects
On Thu, Sep 05, 2002 at 12:12:52PM +0100, Nicholas Clark wrote: On Thu, Sep 05, 2002 at 07:03:00AM -0400, Dan Sugalski wrote: 4) The *only* tools you will need to build parrot are a C compiler environment and either a make tool or a shell I believe we may be able to get away without a make tool or a shell. It won't be pretty, but I see no reason why we can't automatically generate the default order of building things from source code scratch into a C program, which manually ask the user 1: build this C program from this single self contained C source file 2: run it, with the current directory being the parrot source directory The way I'd do it is to have a make-like utility (possibly written in Perl), that has two modes of action. First it can act as a traditional make, and would be used by developers during the frequent compilation cycles. Second, it has the ability to produce an output script based on the dependency tree, in one of several formats, eg UNIX shell, whatever VMS uses, DOS batch (?!?) etc. This script would be a simple unconditional build everything script, just listing all the comands that the make would have executed anyway. So for example in the UNIX setup it might output a shell script looking like #!/bin/sh . config.sh . policy.sh $CC -$CCFLAGS -o foo.o foo.c $CC -$CCFLAGS -o bar.o bar.c Then the output scripts can be bundled with with the src code, so the initial build can be done without having Perl (or whatever) around. This may also be useful for initial porting to new machines. But I haven't thought this through much, and its probably Not Nearly As Simple As I Think. No doubt Andy or Brent will put me right :-) Dave. -- But Sidley Park is already a picture, and a most amiable picture too. The slopes are green and gentle. The trees are companionably grouped at intervals that show them to advantage. The rill is a serpentine ribbon unwound from the lake peaceably contained by meadows on which the right amount of sheep are tastefully arranged. Lady Croom - Arcadia
Re: DOD etc
On Sun, Aug 25, 2002 at 11:16:35AM -0400, Tanton Gibbs wrote: In this case, it is quite likely that many programs will get that flag set. In which case, we'll need to be doing a DOD run at the end of most blocks I would hope not. The only things which will set this flag are those items needing deterministic destruction, not all items with a destructor. It may be that for some languages these are they same set of objects, but for others those requiring determininstic destruction will be a small subset of those that have destructors and won't appear frequently in programs. we'll just have to wait and see if Perl6 makes this distinction to see if this choice is well founded or not. Well, if understood you correctly, then a single execution of my $fh = IO::File-new(...) anywhere in the program or its libraries would trigger this slow behaviour for the rest of the program. I'd have thought that the above, or its Perl6 moral equivalent, is a fairly common idiom. -- But Sidley Park is already a picture, and a most amiable picture too. The slopes are green and gentle. The trees are companionably grouped at intervals that show them to advantage. The rill is a serpentine ribbon unwound from the lake peaceably contained by meadows on which the right amount of sheep are tastefully arranged. Lady Croom - Arcadia
DOD etc
In this Brave New World of DOD and GCC, what guarantees (if any)
will we be making at the Perl 6 language level for the timely calling of
object destructors at scope exit?
ie the classic
{ my $fh = IO::File-new(...); }
I know there's been lots of discussion on this over the months,
but I'm slighly confused as to what the outcome was.
--
You're so sadly neglected, and often ignored.
A poor second to Belgium, When going abroad.
Monty Python - Finland
Re: DOD etc
On Wed, Aug 21, 2002 at 08:25:10PM +0100, I wrote: In this Brave New World of DOD and GCC, what guarantees (if any) s/GCC/GC/ What with PMC, PDD, COW etc, I have TLA on the brain. :-) -- Nothing ventured, nothing lost.
Re: Lexical variables, scratchpads, closures, ...
On Fri, Aug 02, 2002 at 11:15:09AM -0600, Jonathan Sillito wrote: Could two parallel arrays work? One stores the lexicals (accessed by index) and the other stores the names of the lexicals. Then to access a lexical by name involves a sequential search through the (probably not large) array of names, to get the index, then the index is used to get the lexical from the other array. Or would that make access by name too slow? It's how Perl5 does it (very roughly speaking) -- You're so sadly neglected, and often ignored. A poor second to Belgium, When going abroad. Monty Python - Finland
Re: perl6-language@perl.org
On Thu, Aug 01, 2002 at 06:02:14PM -0400, Miko O'Sullivan wrote:
It would be really groovy if that expression could be split with the
delimiters in place, something like this:
tokens = split _/[?=*-+]/, $sql, keep='all';
and get back an array with these values: ('rank', '=', '?')
But that raises a problem: what if the expression is this (note the spaces):
rank = ?
In that case I would want the = and ? but I wouldn't want the spaces. A
slightly different option could keep just stuff in parens:
tokens = split _/\s*([?=*-+])\s*/, $sql, keep='parens';
But perl5 already does this:
$ perl -le 'print join |, split /\s*([?=*-+])\s*/, rank = ?'
rank|=||?
$
Dave.
--
You live and learn (although usually you just live).
Re: perl6-language@perl.org
On Thu, Aug 01, 2002 at 06:17:11PM -0400, Uri Guttman wrote: do these instead: $bool += 0 ; ($x == $y) + 0 or even $x == $y || 0 -- Never do today what you can put off till tomorrow.
Re: [PATCH] .dev files.
On Wed, Jul 17, 2002 at 01:42:17PM -0700, John Porter wrote: Andy Dougherty wrote: I think the purpose of the .dev files, as laid out in docs/pdds/pdd07_codinstd.pod, is a reasonable one. Here's an edited excerpt: . . . (Thanks, Andy.) Well, given that definition of the purpose, I must persist in my opinion that the proper place for that kind of doco is inside the source file. Some people may think it strange to find a discussion of implementation issues in a source code file, but I don't. As the originator of the '.dev' file idea, my reasons for suggesting a separate file were: a) psychologically speaking, I supect that many people would feel uncomfortable inserting mini-essays in the middle of a source file, and there would thus be a natural tendency to pare them down and leave out stuff b) I didn't want the more general overview-type comments interspersed throughout the file, mixed in with detailed per-function comments c) not being in a src file would make it easier to cut+paste code snippets, examples etc without having to worry about nested /* */, or people confusing it with real code etc. One of the reasons I used numerical accuracy as an example was because in Perl 5, Nick's mini-essay on his stirling work *is* buried somewhere in the middle of the 10,000 line sv.c, and thus probably hasn't been seen by most people. If there was a .dev file, it would (hopefully) become a well-known starting point and thus things in it would more likely be drawn to the attention of the reader earlier. If the .dev file were to be merged into the src file, then I personally would want the entire contents to be inserted at the *start* (or maybe the end) of the file, rather than being intermingled. (Obviously per-function comments should remain next to the functions they comment). If the .dev file remained separate, then I would want it in the same directory as the corresponding .c file, to reduce the energy barrier of having to bother to deal with a second file. Especially if the .c files ever get spread round in a directory hierarchy (horrors like .../../dev/perl6/ops/foo.dev etc) Dave. -- This email is confidential, and now that you have read it you are legally obliged to shoot yourself. Or shoot a lawyer, if you prefer. If you have received this email in error, place it in its original wrapping and return for a full refund. By opening this email, you accept that Elvis lives.
Re: [PATCH] .dev files.
On Wed, Jul 17, 2002 at 11:13:58PM +0100, Nicholas Clark wrote: On Wed, Jul 17, 2002 at 10:38:47PM +0100, Dave Mitchell wrote: One of the reasons I used numerical accuracy as an example was because in Perl 5, Nick's mini-essay on his stirling work *is* buried somewhere in the middle of the 10,000 line sv.c, and thus probably hasn't been seen by most people. If there was a .dev file, it would (hopefully) become a well-known starting point and thus things in it would more likely be drawn to the attention of the reader earlier. Hmm. But you're right too. I want them in both places. Well, more accurately, I think I'd agree that the overview documentation deserves not to be in sv.c, but all the don't do this here or you don't need to worry about that here stay inline. I *think* that means I'd like comments such as this: /* IV not precise. No need to convert from PV, as NV conversion would already have cached IV if it detected that PV-IV would be better than PV-NV-IV flags already correct - don't set public IOK. */ to stay where they are, but the description (and health warning) maybe should come out. Yep, that sounds about right. People would learn from the .dev file about your overall strategy to keep values as 64-bit ints for as long as possible, then could learn about the individual gruesome hacks^w^w cunning manipulations near the individual functions. I guess the distinction should be that in perl5, sv.c does lots of things, and that description needs to stay together with the numeric conversion code. If the numeric conversion code got to live in its own file, then sv_convert.c and sv_convert.dev would make sense, as it ought to be obvious to anyone fundamentally chaining sv_convert.c that they had better look at and correct sv_convert.dev It's just that as is, perl5's sv.dev would have essays on SV allocation strategies, SV copying routines, SV number conversion, SV string conversion, SV setting routines (there are a lot of variants of these), magic, recycling unused SVs, SV string comparison, sv_gets, sprintf and cloning. And that list may not be complete. I had no idea so much was in there. But better for there to be 15 essays than no essays :-) -- Do not dabble in paradox, Edward, it puts you in danger of fortuitous wit. Lady Croom - Arcadia
Re: Parrot contribution
On Sat, Jul 13, 2002 at 03:48:31PM +0100, Nicholas Clark wrote: I was working somewhere where the chief technical architect, a very smart guy, was far too busy doing stuff to write it down, and also didn't view it as a priority as I don't need to write it down, it's all in my head. And once again, I'd like to remind people of the following section in PDD7: =item Developer files For each source file (eg a Ffoo.c Ffoo.h pair), there should be an accompanying developer file called Ffoo.dev. This text file contains documentation on all the implementation decisions associated with the source file. (Note that this is in contrast to PDDs, which describe design decisions). This is the place for mini-essays on how to avoid overflows in unsigned arithmetic, or on the pros and cons of differing hash algorithms, and why the current one was chosen, and how it works. In principle, someone coming to a particular source file for the first time should be able to read the F.dev file and gain an immediate overview of what the source file is for, the algorithms it implements, etc. Currently no particular format or structure is imposed on the developer file, but it should have as a minimum the following sections: =over 4 =item Overview Explain the purpose of the source file. =item Data structures and algorithms Explain how it all works. =item History Record major changes to the file, eg we moved from a linked list to a hash table implementation for storing Foos, as it was found to be much faster. =item Notes Anything that may be of interest to your successors, eg benchmarks of differing hash algorithms, essays on how to do integer arithmetic. =item References Links to pages and books that may contain useful info relevant to the stuff going on in the code - eg the book you stole the hash function from. =back -- But Pity stayed his hand. It's a pity I've run out of bullets, he thought. - Bored of the Rings
Re: vtables and multimethod dispatch
On Thu, Jul 11, 2002 at 08:20:21PM -0700, John Porter wrote: Dave Mitchell wrote: IIRC, all metrics of the form (x^n + y^n)^(1/n), n=1,2,...Inf are strongly equivalent, ie they give rise to the *same* ordering. (In the limit as n - Inf, the metric is max(x,y).) I'm sorry, YDNRC. Consider the distance from the origin to the points (0,6) and (3,4). Under the (x^1+y^1) metric (Manhattan distance), (0,6) is closer. Under the (x^2+y^2) metric (Pythogorean thm), (3,4) is closer. D'oh! Perhaps I should get a job with WorldCom? -- Lady Nancy Astor: If you were my husband, I would flavour your coffee with poison. Churchill: Madam - if I were your husband, I would drink it.
Re: What's MY.line?
On Thu, Jul 11, 2002 at 10:41:20AM -0400, Dan Sugalski wrote: The place where you'll run into problems in where you have multiple variables of the same name at the same level, which you can do in perl 5. can it? can you give an example? -- In England there is a special word which means the last sunshine of the summer. That word is spring.
Re: What's MY.line?
On Wed, Jul 10, 2002 at 11:57:02PM -0400, Chip Salzenberg wrote: According to Dave Mitchell: Based on what I rememeber from the long threads about this, Ouch. I gather, then, that nntp.perl.org does not house complete list archives, or else the discussion was not on p6-language ... ? don't know about nntp, but see for example, http:[EMAIL PROTECTED]/msg08203.html -- You live and learn (although usually you just live).
Re: What's MY.line?
On Thu, Jul 11, 2002 at 02:29:08PM -0400, Dan Sugalski wrote: At 7:18 PM +0100 7/11/02, Dave Mitchell wrote: On Thu, Jul 11, 2002 at 10:41:20AM -0400, Dan Sugalski wrote: The place where you'll run into problems in where you have multiple variables of the same name at the same level, which you can do in perl 5. can it? Yes. can you give an example? [localhost:~] dan% perl my $foo = 12; print $foo; my $foo = ho; print $foo; 12ho[localhost:~] dan% ah, I see what you mean. I hope that'll be a syntax error rather than just a warning in perl6. -- Strange women lying in ponds distributing swords is no basis for a system of government. Supreme executive power derives from a mandate from the masses, not from some farcical aquatic ceremony. Dennis - Monty Python and the Holy Grail.
Re: vtables and multimethod dispatch
On Thu, Jul 11, 2002 at 01:18:51PM -0700, John Porter wrote: Nicholas Clark wrote: I was thinking that the metric (x*x + y*y) would be fast to calculate, as that's all we need for ordering. Point is, it's rather *more* than we need for ordering. x + y will suffice. IIRC, all metrics of the form (x^n + y^n)^(1/n), n=1,2,...Inf are strongly equivalent, ie they give rise to the *same* ordering. (In the limit as n - Inf, the metric is max(x,y).) -- A walk of a thousand miles begins with a single step... then continues for another 1,999,999 or so.
Re: What's MY.line?
On Thu, Jul 11, 2002 at 10:37:27PM +0100, Nicholas Clark wrote:
Is there any specific case where you can't treat
{
my $foo = 12;
print $foo;
my $foo = ho;
print $foo;
}
as
{
my $foo = 12;
print $foo;
{
my $foo = ho;
print $foo;
}
}
Well, it B*gg*rs up %MY::
The currently planned semantics are:
{
my $x;
exists %MY::{'$x'}; # true;
}
and
{
my $x;
{
exists %MY::{'$x'}; # false
}
}
so consider:
{
my $x;
my $dup;
my $dup;
exists %MY::{'$x'}; # true?
}
which invisibly becomes
{
my $x;
my $dup;
{
my $dup;
exists %MY::{'$x'}; # false?
}
}
--
But Sidley Park is already a picture, and a most amiable picture too.
The slopes are green and gentle. The trees are companionably grouped at
intervals that show them to advantage. The rill is a serpentine ribbon
unwound from the lake peaceably contained by meadows on which the right
amount of sheep are tastefully arranged. Lady Croom - Arcadia
Re: What's MY.line?
On Tue, Jul 09, 2002 at 09:50:26PM -0400, Chip Salzenberg wrote:
Based on what I rememeber from the long threads about this,
3. Is C%MY intended to reflect the PAD?
loosely speaking yes.
3a. If so, how can one distinguish among the e.g. many Cmy $foo
variables declared within the current function?
It was decreed that %MY only sees stuff in the inner-most lexical scope
(so the Perl6 version of a pad is 'bigger' than what %MY sees):
{
my $x = 1;
{
exists %MY::{'$x'}; # false
print %MY::{'$x'}; # undef
print $x; # 1
%MY{'$x'} = 2;
print %MY::{'$x'}; # 2
print $x; # 2
{
exists %MY::{'$x'}; # false
print %MY::{'$x'}; # undef
print $x; # 2
}
}
exists %MY::{'$x'}; # true
print %MY::{'$x'}; # 1
print $x; # 1
}
3b. If not, how are lexical adjustments to C%MY unwound? Or are
they? If they're not, I can actually see the idea that could be
part of the base utility of C%MY.
I think the main intent of %MY:: is to allow import() to lexically affect
the caller, ie
sub import {
caller(1).MY{'foo'} = sub { ... };
}
(for some vague handwaving interpretation of caller() and MY)
Dave.
--
My get-up-and-go just got up and went.
Re: Perl 6, The Good Parts Version
On Wed, Jul 03, 2002 at 01:23:24PM -0400, Michael G Schwern wrote: Hopefully the Cabal [2] can debunk that. [snip] [2] Of which there is none. and http://www.perlcabal.com/ doesn't exist, right? ;-) -- I do not resent critisism, even when, for the sake of emphasis, it parts for the time with reality. Winston Churchill, House of Commons, 22nd Jan 1941.
Re: Perl5 humor
On Tue, Jun 25, 2002 at 11:08:53AM +0100, Tim Bunce wrote: On Tue, Jun 25, 2002 at 12:23:34AM +0100, Dave Mitchell wrote: Of course, another approach is to embed the existing Perl5 interpreter within the Perl 6 interpreter; Perl6 subs call glue which calls Perl subs which calls perl5 XS. How would you deal with passing references? (wild hand waving follows) a perl6 reference is substituted with a perl5 scalar that has attached magic that 'does the right thing'. Dave. -- Do not dabble in paradox, Edward, it puts you in danger of fortuitous wit. Lady Croom - Arcadia
Re: Perl5 humor
On Tue, Jun 25, 2002 at 04:45:37PM +0100, Tim Bunce wrote: On Tue, Jun 25, 2002 at 11:35:20AM +0100, Dave Mitchell wrote: On Tue, Jun 25, 2002 at 11:08:53AM +0100, Tim Bunce wrote: On Tue, Jun 25, 2002 at 12:23:34AM +0100, Dave Mitchell wrote: Of course, another approach is to embed the existing Perl5 interpreter within the Perl 6 interpreter; Perl6 subs call glue which calls Perl subs which calls perl5 XS. How would you deal with passing references? (wild hand waving follows) a perl6 reference is substituted with a perl5 scalar that has attached magic that 'does the right thing'. I don't think that'll fly. Quite possibly not. But Larry's reply to one of my postings on p6l led me to belive that was the direction we were going to head in. I may have misunderstood him: From: Larry Wall [EMAIL PROTECTED] To: Dave Mitchell [EMAIL PROTECTED] cc: Simon Cozens [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Tue, 4 Jun 2002 10:06:44 -0700 (PDT) Subject: Re: Half measures all round On Tue, 4 Jun 2002, Dave Mitchell wrote: Having said that, I have real, real doubts that Perl 6 will ever be able to execute Perl 5 code natively. Its not just a case a writing a new parser and some P5-specific ops; P5 has so many special features, boundary conditions and pecularies, that to get P6 to execute P5 is a task equivalent to reimplementing P5 from scratch. I'm wondering if instead, we continue to maintain the P5 src tree, and embed P5 within P6 (embed in the sense of Apache and Mod_perl). Sick and ugly, but maybe more practical than the alternatives. It also means that the P6 src doesn't have to be saddled with knowing (much) about P5. Eventually of course the P5 bit would have to be thrown away. That's exactly what I've been arguing for all along. Grr And that's why I see the package hack and the new :p5 modifier as having the weight of two features, not the weight of an entire re-implementation of Perl 5. It's really not that difficult to run two interpreters in the same process. I already made Perl and Java run together nicely. If anything the impedence mismatch between Perl 5 and Perl 6 will be even less. Scaffolding is supposed to be ugly. You wouldn't believe how ugly the transitional form between Perl 4 and Perl 5 was, when half the opcodes were interpreted by the old stacked interpreter, and half by the new stackless one. Larry -- In England there is a special word which means the last sunshine of the summer. That word is spring.
Re: Perl5 humor
On Mon, Jun 24, 2002 at 05:21:45PM -0400, David J. Goehrig wrote: On Sun, Jun 23, 2002 at 09:50:02PM +0100, Tim Bunce wrote: Much more likely is some kind of wrapper that manages a simple perl5-like run-time environment (stacks, marks, gimme, symboltable etc) plus source-code compatibility support (macros, functions etc) that's just sufficient to keep old XS code happy. That's all I'd ask for, but the scope of that project is truly incredible. Granted that the one could get most of their bang for their buck out of just handling those found in perlguts, but the devil is in the details. Of course, another approach is to embed the existing Perl5 interpreter within the Perl 6 interpreter; Perl6 subs call glue which calls Perl subs which calls perl5 XS. Dave. -- In England there is a special word which means the last sunshine of the summer. That word is spring.
Re: Stacks, stacks, stacks (And frames)
On Tue, Jun 11, 2002 at 11:31:37AM -0400, Dan Sugalski wrote: We'll find out with A6 whether we do coroutines and continuations as part of the core perl. If not, well, python does the first and ruby the second, so it's all good in there. Does anyone feel like giving a 1 paragraph potted summary of what coroutines and continuations are (from a Perl persepective), for the benefit those ignoramousses here (like me, who wasn't taught anything at all useful during a 3 year CS degree course - unless you count Pascal as useful :-) ? Dave. -- Standards (n). Battle insignia or tribal totems.
Re: Half measures all round
On Tue, Jun 04, 2002 at 10:43:02AM +0100, Simon Cozens wrote: (Please CC me on replies) I don't often express many opinions on Perl 6 these days, but I feel I have to warn people about what I see as a potential loss of direction. I'm becoming somewhat disillusioned with Perl 6 these days; sometimes because it's too radical, more often than not because it's not radical enough, and quite often because it's more than a year behind schedule and still slipping. But that last point is by the by; with three people now working full-time on it, I'm sure we can expect it any day now. What's really actually letting me down with it is the half-measures we're applying. We seem to be trying to please everyone, and it's not going to work; indeed, it's going to end up presenting a burden to the implementors. Let's take an example. One of the major points of Perl 6, and one of its major attractions for me, was that we finally put the backwards compatibility ghost to rest. We can do brave, new, exciting things, without worrying about needing to maintain obscure pieces of functionality. Yey! Except that we can't do that any more; we've constrained ourselves to faithfully regressing to Perl 5 when we see a package declaration. Why? Because we're scared. package parses Perl 5 is a sop to people who don't want to program in Perl 6, and we're worried about losing those people. One word: CPAN. (Okay, that was three words.) It will be a long, long time before all the CPAN modules are rewritten in Perl 6. In the meantime, Perl 6 code has to be able to use Perl 5 modules, or it will be crippled, and probably stillborn. Having said that, I have real, real doubts that Perl 6 will ever be able to execute Perl 5 code natively. Its not just a case a writing a new parser and some P5-specific ops; P5 has so many special features, boundary conditions and pecularies, that to get P6 to execute P5 is a task equivalent to reimplementing P5 from scratch. I'm wondering if instead, we continue to maintain the P5 src tree, and embed P5 within P6 (embed in the sense of Apache and Mod_perl). Sick and ugly, but maybe more practical than the alternatives. It also means that the P6 src doesn't have to be saddled with knowing (much) about P5. Eventually of course the P5 bit would have to be thrown away. Dave. -- There's something wrong with our bloody ships today, Chatfield. Admiral Beatty at the Battle of Jutland, 31st May 1916.
Re: GC, exceptions, and stuff
On Wed, May 29, 2002 at 03:23:41PM -0400, Dan Sugalski wrote: At 10:53 AM +0100 5/29/02, Dave Mitchell wrote: On Tue, May 28, 2002 at 07:35:43PM -0700, Hong Zhang wrote: Parrot has to handle signals, such as SIGSEGV. That's the one signal I really hope parrot *doesn't* handle. What, you don't think we should wedge ourselves into the system MMU handlers? :) Well, it would certainly encourage us to write tight opcode dispatch code ;-) -- Never do today what you can put off till tomorrow.
GC and ithreads
Aplogies if this has already been discussed, but I haven't been following p6i too closely of late (the lure of being allowed to mess with 5.7.3 has been too strong :-) Anyway, I presume that the Perl6 theading model will be like Perl 5 ithreads - that is to say, each thread has its own interpreter and private collection of data, apart from where data is explicity shared. In Perl 5 this involves a high cost for each new thread, since each SV etc must be individually cloned - expensive in both CPU and memory. Can we do clever things with the GC and/or COW such that cloning a thread can either be done (mostly) at the GC level, eg a special compacting cycle that leaves us with 2 identical(ish) compacted copies, or even better, some sort of COW so that each cloned PMC etc doesn't use any extra memory until it is modified for the first time ? Just though I'd raise this in the general conciousness while there are various GC/threads threads threading about. I'll now return to my usual activity of feeling guilty for not having updated PDD7 despite enless promises to that effect. Dave. -- Do not dabble in paradox, Edward, it puts you in danger of fortuitous wit. Lady Croom - Arcadia
Re: PATCHES
On Wed, May 22, 2002 at 11:52:36AM -0300, Daniel Grunblatt wrote: And, please: 1 - Try to send the patch as an attachment, sometimes it's too difficult to apply if you don't. 2 - 'diff -u' blinkI S Y O U R F R I E N D/blink :) 'diff -up' is even better if your diff supports it! Dave. -- Never do today what you can put off till tomorrow.
Re: eval {} or carp blah: $@
On Thu, May 02, 2002 at 02:33:42PM -0600, Jim Cromie wrote:
with p5, Ive often written
eval {} or carp $ blah;
You generally Don't Want To Do That.
If the eval succeeds, but the last statement in the eval happens to come
out as false, then it'll still carp:
$a = 0; eval { 1 $a } or carp
$a = 0; eval { 1 / $a } or carp
will both carp
--
My get-up-and-go just got up and went.
Re: Loop controls
In the true sprirt of perverseness, why not make loops into functions that
return the number of iterations taken. Then you can have
loop {
}
or die loop not taken\n;
;-)
--
A walk of a thousand miles begins with a single step...
then continues for another 1,999,999 or so.
Re: Cfor loop variations
On Tue, Apr 16, 2002 at 06:17:24PM -0700, David Wheeler wrote:
In Exegesis 4, Damian writes:
blockquote
It's important to note that writing:
for a; b - $x; $y {...}
# in parallel, iterate a one-at-a-time as $x, and b one-at-a-time as
$y
is not the same as writing:
for a, b - $x, $y {...}
# sequentially iterate a then b, two-at-a-time as $x and $y
/blockquote
Now, I love that the for loop can do both of these things, but the subtlety
of the difference in syntax is likely, IMO, to lead to very difficult-
to-find bugs. It's very easy to miss that I've used a comma when I meant to
use a semicolon, and vice versa. And what's the mnemonic again?
Personally I really hate the use of the semicolon here - it's
counter-intuitive to everything you expect from semicolons in the 'C'
stable of languages (and English too) - ie my brain groups the terms in
for a; b - $x; $y {...}
like
for [@a]; [@b - $x]; [$y] {...}
rather than
for [@a; b] - [$x; $y] {...}
Maybe we should have something like
for a - $x; b - $y {...}
Instead.
This has the advange of being writeable as the following for clarity:
for
a - $x;
b - $y
{
But hey, what do I know - I'm not a linguist or language designer :-)
--
But Pity stayed his hand. It's a pity I've run out of bullets, he
thought. - Bored of the Rings
Re: Roadmap for Parrot
On Wed, Apr 17, 2002 at 04:34:12PM -0400, Simon Glover wrote: On Wed, 17 Apr 2002, Brent Dax wrote: Dan Sugalski: # Okay, here are the milestones. Each is worth a point release. If we # manage to take them in this order, great. :) Rough dependency tree: Arrays Regular expressions (backreference storage) Parser (probably) Lexicals (probably, though could be a hash instead) I thought lexicals were going to live in a symbol table now? In which case, they're definitely going to depend on implementing hashes first. The first does not necessarily imply the second. -- But Pity stayed his hand. It's a pity I've run out of bullets, he thought. - Bored of the Rings
Re: // in Perl 5.8?
On Wed, Apr 17, 2002 at 01:09:43PM -0700, David Wheeler wrote:
Anyone know what the chances are that some enterprising C hacker
can/will/did get the // and //= operator into Perl 5.8? Seems like it
wouldn't be a huge deal to add, and I'd love to have it sooner rather than
later.
I hope you're referring to 5.8.x for some x != 0 ??? :-)
--
print+qq$}$$/$s$,$*${$}$g$s$@$.$q$,$:$.$q$^$,$@$*$~$;$.$q$mif+map{m,^\d{0\,},,${$::{$'}}=chr($+=$||1)}q10m22,42}6:17*2~2.3@3;^2$g3q/s=~m*\d\*.*g
Re: // in Perl 5.8?
On Wed, Apr 17, 2002 at 01:58:05PM -0700, David Wheeler wrote: On 4/17/02 1:51 PM, Dave Mitchell [EMAIL PROTECTED] claimed: I hope you're referring to 5.8.x for some x != 0 ??? :-) Do you know how late in the development process the $coderef-() feature was added to Perl (in whatever release that was)? Ask Randal to talk about it sometime. ;-) But maybe things are more rigorous now, and it should be 5.8.1. Personally, I'd rather see it sooner than later. Given that bleedperl is now in total code freeze barring Jarkko's list of about 8 fix these so I can get RC1 out the door bugs, I think you may have a tough time convincing him -- You're so sadly neglected, and often ignored. A poor second to Belgium, When going abroad. Monty Python - Finland
Re: Roadmap for Parrot
On Wed, Apr 17, 2002 at 04:57:21PM -0400, Dan Sugalski wrote: At 9:48 PM +0100 4/17/02, Dave Mitchell wrote: On Wed, Apr 17, 2002 at 04:34:12PM -0400, Simon Glover wrote: I thought lexicals were going to live in a symbol table now? In which case, they're definitely going to depend on implementing hashes first. The first does not necessarily imply the second. True, but in this case it does. Symbol tables are hashes, as are the lexical scratchpads. (Hashes you can look up by integer index, mind, but hashes nonetheless) I'm not yet convinced that hashes are the best data structure for lexical symtabs, given their heirarchical and dynamic nature. But lets not get into that debate just now :-) -- But Pity stayed his hand. It's a pity I've run out of bullets, he thought. - Bored of the Rings
Re: Unary dot
On Sat, Apr 13, 2002 at 05:07:37PM -0700, Larry Wall wrote: Of course, one of the big reasons we went with $self was the pun: my $self = shift; which we won't have now. Unless we always hide the invocant and force you to say my $self = invocant; or some such mummery. But that seems a bit retro. But now we have endless possibilities for $self.ish $self.less $self.centred $self.obsessed etc. -- But Sidley Park is already a picture, and a most amiable picture too. The slopes are green and gentle. The trees are companionably grouped at intervals that show them to advantage. The rill is a serpentine ribbon unwound from the lake peaceably contained by meadows on which the right amount of sheep are tastefully arranged. Lady Croom - Arcadia
Re: Unary dot
On Wed, Apr 10, 2002 at 05:47:01PM -0500, Allison Randal wrote: I'm in favor of the standardized variable name. It is a restriction, but not an onerous one. I've never used anything but $self, and I'm sure it would be easy to adapt to whatever else was chosen. Are there any statistics availble on current usage of $self vs. $this vs. whatever? It might be easiest to go with what the majority find most comfortable. The top 20 'my $var' declarations in .pm files in the bleedperl distribution: (I was in need of some displacement activity) 1076 $self 181 $x 126 $file 110 $class 109 $name 98 $i 92 $line 82 $r 80 $s 75 $dir 74 $a 71 $fh 70 $key 69 $path 68 $p 68 $y 66 $c 66 $n 63 $text 60 $type and in 48th place: 22 $this Dave. -- Do not dabble in paradox, Edward, it puts you in danger of fortuitous wit. Lady Croom - Arcadia
Re: GC and allocation controls?
On Fri, Mar 15, 2002 at 08:50:47PM +, Nicholas Clark wrote: On Fri, Mar 15, 2002 at 03:42:50PM -0500, Dan Sugalski wrote: On Fri, 15 Mar 2002, Tim Bunce wrote: Might be good to also provide higher level controls that just provide hints to the GC. Somewhat like the use less qw(memory); pragma that never quite happened for perl5, but with more appropriate attribute for GC in perl6. What I'm talking about was more at the level of fine control. When we've run out of PMC headers in our arena, how many do we allocate in the new arena? When we need more memory from the system how big a chunk do we ask for? How many times do we allocate new arenas/memory pools before we trigger off an automatic GC or DOD run? Things like that. Ah. That's not really at the 'use less qw(memory)' level. It's like going from 'use more qw(coffee)' to use coffee origin='Brazil', fairtrade='yes', shots=3, cup='ceramic mug'; and will change when your dealer changes. I think we need both interfaces. The 'use less qw(memory)' interface is high-level and fixed, and is implemented in terms of a lower-level GC interface which may change wildly (but has some sort of versioning). We make sure that the lower-level interface has lots of 'here be dragons' in the docs. Whenever the GC interface changes, we modify less.pm accordingly.
Re: Reformatting code/coding standards
Melvin Smith [EMAIL PROTECTED] wrote: This is my only nitpick with the coding standards. I never cared for the style of putting return type on a separate line above the function declaration header. I like it just as the prototype. I vote for non-enforcement of this one. personally I like the function name on the start of the line - it makes it easier to grep for stuff.
RE: #defined types
Dan Sugalski [EMAIL PROTECTED] wrote: At 8:10 PM -0800 2/23/02, Brent Dax wrote: typedef struct foo_t * FooPtr; typedef struct foo_t FOO; Y'know, thinking about this, I don't like this trick. That should be FOO, and FOO *. We either typedef the struct, or the pointer to a struct. Not both. and my personal vote is the for the former. I feel more comfortable with SV *sv; than SV sv; I like to explicitly know when I'm dealing with a pointer. (just MHO).
Re: PDDs, guys.
Dan Sugalski [EMAIL PROTECTED] wrpote:
Implementation should be capable of being yanked out and replaced
with no notice, and things still work. It is, and should be,
considered ephemeral. It's the least important thing to get right,
since it can be fixed or completely replaced as we need to.
I'd also like to remind people that while documentation for designs +
interfaces go in PDDs, just as importantly PDD7 mandates documentation
for implementations (so poor schmucks trying to understand your code
can have a vague guess at what's going on). And I quote:
---
=item Developer files
For each source file (eg a Ffoo.c Ffoo.h pair), there should be an
accompanying developer file called Ffoo.dev. This text file contains
documentation on all the implementation decisions associated with the
source file. (Note that this is in contrast to PDDs, which describe
design decisions). This is the place for mini-essays on how to avoid
overflows in unsigned arithmetic, or on the pros and cons of differing
hash algorithms, and why the current one was chosen, and how it works.
In principle, someone coming to a particular source file for the first
time should be able to read the F.dev file and gain an immediate
overview of what the source file is for, the algorithms it implements,
etc.
Currently no particular format or structure is imposed on the developer
file, but it should have as a minimum the following sections:
=over 4
=item Overview
Explain the purpose of the source file.
=item Data structures and algorithms
Explain how it all works.
=item History
Record major changes to the file, eg we moved from a linked list to a
hash table implementation for storing Foos, as it was found to be much
faster.
=item Notes
Anything that may be of interest to your successors, eg benchmarks of
differing hash algorithms, essays on how to do integer arithmetic.
=item References
Links to pages and books that may contain useful info relevant to the
stuff going on in the code - eg the book you stole the hash function
from.
-
I'd also like to remind people of the following:
-
=item Top-of-file comments
In addition to the copyright message and optional quote, each source
file must have a short comment at the top explaining the basic purpose
of the file, eg
/* pp_hot.c - like pp.c, this file contains functions that operate
* on the contents of the stack (pp == 'push pop'), but in this
* case, frequently used ('hot') functions have been moved here
* from pp.c to (hopefully) improve CPU cache hit rates.
*/
-
Re: Keys and Indices PDD
Simon Cozens [EMAIL PROTECTED] wrote: Need discussion on whether COUT_OF_BOUNDS is a good exception for this, or whether something else should be used. It's really a compiler screw-up, since code which indexes a non-aggregate shouldn't be generated. Except of course references, where the compiler can't know in advance that the ref doesn't point to an aggregate.
Re: PMCs, setting, and suchlike things
Dan Sugalski [EMAIL PROTECTED] wrote: Right, for typed variables. Most variables (i.e. anything you declared with a plain my $foo or our @bar) are untyped and can change their types as needed. If you did: my $foo; $foo = Dog.new(); $foo = FireHydrant.new(); $foo would first be a Dog, then a FireHydrant. When it changed to a FireHydrant the previous contents would get blown away. Hmmm - how do we distinguish between a plain scalar that is temporarily typed, and a 'proper' permanently-typed scalar? eg in the following my Dog $spot = Dog.new(waggly tail); $spot = Cat.new(); you would expect $spot to always remain a dog no matter what, and will throw a run-time (or compile time) error if it can't think of a way of making itself into a doggish cat. On the other hand, my Dog $spot = Dog.new(waggly tail); my $plain = 1; $plain = $dog; # is $plain temporarily or permanently a dog now? $plain = Cat.new(); # run-time error or is $plain now a cat? Or to put it another way, is the type of a PMC determined purely by it's current vtable pointer, and if so, under what circumstances are we allowed to change the pointer? Do we need a PMC flag saying that our type is fixed? And if so, how do we handle my Dog $dog;# dog has the 'undef' vtable pointer type # but is still a dog $dog = Dog.new(); # dog now has the 'dog' vtable type. And can we indeed conflate the concepts of type as defined by a vtable pointer, and Perl-level type? Will there always be a seaprate vtable for each Perl-level type I'm confused
Re: PMCs, setting, and suchlike things
Alex Gough [EMAIL PROTECTED] wrote:
On Thu, 14 Feb 2002, Dave Mitchell wrote:
$foo would first be a Dog, then a FireHydrant. When it changed to a
FireHydrant the previous contents would get blown away.
Hmmm - how do we distinguish between a plain scalar that is temporarily
typed, and a 'proper' permanently-typed scalar?
eg in the following
my Dog $spot = Dog.new(waggly tail);
$spot = Cat.new();
you would expect $spot to always remain a dog no matter what, and will
throw a run-time (or compile time) error if it can't think of a way of
making itself into a doggish cat.
I think you're thinking at too high a level to make much sense of what
the vtables should be doing. A better example to drive your mind would
be:
tie $foo, 'Baa';
$foo = 12;
In which case the $foo PMC will know that it is somehow tied, and dispatch
control to an appropriate bit of perl code.
Tying is higher-level than I was thinking about. Tying is an easy case:
we have a 'tied' vtable type whose assign method looks loosely like
void tied_assign(PMC *dst, PMC *src) {
call_method(dst, FETCH, src);
}
it's current vtable pointer, and if so, under what circumstances
are we allowed to change the pointer? Do we need a PMC flag saying
that our type is fixed? And if so, how do we handle
PMCs define how a variable behaves in different circumstances. We can
change the pointer in every instance except those where the receiving
PMC does not let us, in general a PMC will be happy to lose its
identity.
But that doesn't answer my questions, which were essentially:
1. is the Perl-level type of a variable (eg my Dog $spot)
implemented at the Parrot level by using the vtable pointer to identify
the type? (ie a vtable per Perl type, user-defined or builtin)
2. If so, how do we distinguish between two PMCs, both of whose
vtable pointers currently point to the 'Dog' vtable, but one of whom has
been delared as type Dog and so should never have it's vatble pointer
updated, and the other which started off as a 'plain' PMC, has temporariky
becomes a Dog by beeing assigned to from a Dog value, but will change
again the next time we assign something to it?
Re: PMCs, setting, and suchlike things
Dan Sugalski [EMAIL PROTECTED] wrote: There's a flag in the flags field to mark the PMC as a permanent type or not. It's insufficient for Type X or child of X things, though. Or to put it another way, is the type of a PMC determined purely by it's current vtable pointer, and if so, under what circumstances are we allowed to change the pointer? The variable's vtable functions are the only things allowed to change that pointer. The circumstances under which they change it are up to the authors of the vtables. For standard types we need to hash some things out for it. And can we indeed conflate the concepts of type as defined by a vtable pointer, and Perl-level type? Will there always be a seaprate vtable for each Perl-level type There will be at least one vtable per perl-level type, yes. Each package and class gets at least one, as do any lower-level user-defined types. All sounds good to me. My outstanding niggle is when a typed variable is undef. I guess we need a generic Perl_Undef_But_Typed vtable type, which behaves mostly like the PerlUndef type, but saves a pointer to its 'real' vtable in self-data or whatever. When it's assigned to, it upgrades itself to its real type, then passes control to it's real type's assign method.
Re: PMCs, setting, and suchlike things
Dan Sugalski [EMAIL PROTECTED] wrote: At 3:53 PM + 2/14/02, Dave Mitchell wrote: My outstanding niggle is when a typed variable is undef. I guess we need a generic Perl_Undef_But_Typed vtable type, which behaves mostly like the PerlUndef type, but saves a pointer to its 'real' vtable in self-data or whatever. When it's assigned to, it upgrades itself to its real type, then passes control to it's real type's assign method. That's a good point. I'll have to think about that a little bit. We could either have an undef flag or something and take definedness entirely out of the hands of the vtables, which would involve a conditional branch for every access of every PMC :-( or use the X or child of X mechnanism to allow for undefs as well. Have you any feel for what this child of X mechanism is?
Re: PMCs, setting, and suchlike things
Dan Sugalski [EMAIL PROTECTED] wrote: #2 is what you get with normal assignment. $foo = $bar, for example. $foo's assign vtable method is called with $bar as a parameter. $foo figures out what it should do--if it's a tied variable of some sort it should perform its assign action. (This includes throwing an exception if the assignment isn't valid) Otherwise it should typecheck the RHS and morph itself into the RHS's type. So in the following: my Complex $c = 3+4i; my $plain = 1.1; $plain = $c; I presume that $plain ends up as type Complex (with value 3+4i)? If so, how does $plain know how to morph itself into the RHS's type?
Re: PMCs, setting, and suchlike things
Dan Sugalski [EMAIL PROTECTED] wrote: So in the following: my Complex $c = 3+4i; my $plain = 1.1; $plain = $c; I presume that $plain ends up as type Complex (with value 3+4i)? Yup. If so, how does $plain know how to morph itself into the RHS's type? The general rule is: If a PMC is not a fixed type, it tosses its contents and becomes whatever's assigned to it. If it is a fixed type, it extracts what it can as best it can from the source and uses that. Thanks. I just want to assert/clarify that the job of becoming whatever's assigned to it is delegated to the src PMC, since $plain won't itself know how to do this?
Re: The Perils of set and PMCs
Are you sitting comfortably?
yes.
It's a pretty simple concept. We need to assign one PMC to another.
We'll have to do it all the time:
$a = $b;
$a and $b are both PMCs, and we need to set the value of one to the
value of the other, so let's write it as
set P1, P2
Excellent. Until, of course, we have to implement it. We'll implement
it by calling some vtable method on P1, that much is obvious. But which
one? Our implementation of the set_p_p op can't know whether or not P1
wants a string, an integer, or a number. Or something entirely different.
Indeed, P1 might not know what it wants unless it knows what P2 has to
offer.
An observation:
In Perl 5 at least, it is (roughly speaking) the src variable that gets
to stomp on the destination variable, rather than the destination variable
being allowed to modify itself. ie
$dst = $src in Perl 5 is implemented (very approximately speaking) as
mg_get(src);
IVX(dst) = IVX(src);// old dst values blown away
NVX(dst) = NVX(src);
PVX(dst) = PVX(src);
mg_set(dst);
Now, sometimes we want the destination to have control over how it is
assigned to (eg if it's tied), but most of the time the destination doesn't
care, and is happy to be blown away and have its guts replaced with
whatever the src wants.
With this back-to-front philosophy,
$dst = $src gets called as
dst-vtable-assign(dst,src);
but most simple dst types implemenent their assign method by just passing
control directly through to the src's clone method:
void dsttype_assign(PMC *dst, PMC* src) {
src-vtable-clone(dst,src,);
}
void srctype_clone(PMC* dst, PMC* dst) {
dst-cache.int = src-cache.int; // supposing src is an int type
}
ie, it's the src that actually gets the chance to stomp over the dst, after
the dst lets it.
[ all C syntax here is vague handwaving rather than precise syntax,
especially when it comes to passing key indices ]
Consider also a lightweight integer array class.
Assigning from it becomes easy:
$dst = @src[5] becomes
dst-vtable-assign(dst,src,5);
void simpletype_assign(PMC *dst, PMC* src, KEYTHINGGY key) {
src-vtable-clone(dst,src,key);
}
void lightweightarray_clone(PMC* dst, PMC* dst, KEYTHINGGY key) {
dst-cache.int = src-cache.ptr[INT(key)];
}
and assigning to it is easy:
@dst[5] = $src becomes
dst-vtable-assign(dst,src,5);
void lightweightarray_assign(PMC *dst, PMC* src, KEYTHINGGY key) {
// NB - we don't pass control to the src
dst-cache.ptr[INT(key)] = dst-vtable-get_integer;
}
I dont know whether that helps. I haventeven begun to address list
assignment, %foo = @bar, %foo{@bar} = %baz{%boz}, etc etc.
I ain't got a clue how that might work, of even whether it is the
responsibility of PMCs to handle this.
Just my 0.02 euros.
Re: Parrot directory structure
Simon Cozens [EMAIL PROTECTED] wrote: Melvin Smith: I agree with your config/ dir suggestion, but I'm not sure about moving everything else down into perl6/parrot subdirectory, Me neither. I don't see much point in it. 1) Will Perl6 and Parrot distributions be separate? Yes. Just to clarify this - so there will be 2 separate tarballs, each with their own set of READMEs, config scripts etc. You install one of them first, then the second install makes use of the just-installed /usr/local/lib/parrot.so or perl6.so for its own build ???
Re: Parrot directory structure
Simon Cozens [EMAIL PROTECTED] wrote: Melvin Smith: I agree with your config/ dir suggestion, but I'm not sure about moving everything else down into perl6/parrot subdirectory, Me neither. I don't see much point in it. I'm trying to nip the following in the bud, which is daunting for someone trying to work out what's what for the first time. ls perl-current/ AUTHORS README.netware epocop.cregcomp.sym ArtisticREADME.os2 ext op.hregexec.c Changes README.os390fakesdio.h opcode.hregexp.h Changes5.000README.plan9fakethr.h opcode.pl regnodes.h Changes5.001README.qnx form.h opnames.h run.c Changes5.002README.solaris global.sym os2 scope.c Changes5.003README.threads globals.c patchlevel.hscope.h Changes5.004README.tru64globvar.sym perl.c sharedsv.c Changes5.005README.uts gv.cperl.h sharedsv.h Changes5.6 README.vmesagv.hperlapi.c sv.c Configure README.vms h2plperlapi.h sv.h Copying README.vos handy.h perlio.ct Cross README.win32hints perlio.htaint.c EXTERN.hTodo.micro hv.cperlio.sym thrdvar.h INSTALL XSUB.h hv.hperliol.h thread.h INTERN.hapollo installhtml perlsdio.h toke.c MANIFESTautodoc.pl installman perlsfio.h uconfig.h Makefile.SH av.cinstallperl perlsh uconfig.sh Makefile.micro av.hintrpvar.h perlvars.h universal.c NetWare beosiperlsys.h perly.c unixish.h Policy_sh.SHbytecode.pl jpl perly.fixer utf8.c Porting cc_runtime.hkeywords.h perly.h utf8.h README cflags.SH keywords.pl perly.y utfebcdic.h README.Y2K config_h.SH lib perly_c.diffutil.c README.aix configpmlocale.cperlyline.plutil.h README.amigaconfigure.com macos plan9 utils README.apollo configure.gnu makeaperl.SHpod utils.lst README.beos cop.h makedef.pl pp.cuts README.bs2000 cv.hmakedepend.SH pp.hvmesa README.ce cygwin makedir.SH pp.sym vms README.cygwin deb.c malloc.cpp_ctl.cvos README.dgux djgpp mg.cpp_hot.cwarnings.h README.dos doio.c mg.hpp_pack.c warnings.pl README.epoc doop.c minimod.pl pp_proto.h win32 README.hpux dosish.hminiperlmain.c pp_sort.c wince README.hurd dump.c mintpp_sys.cwritemain.SH README.machten emacs mpeix proto.h x2p README.macosembed.fnc mv-if-diff qnx xsutils.c README.microembed.h myconfig.SH regcomp.c README.mint embed.plnostdio.h regcomp.h README.mpeixembedvar.h numeric.c regcomp.pl
Re: Parrot directory structure
I've only had one reply to this so far - anyone else want to approve or disapprove? NB - I'm kind of offering to do the patching of paths required if this move goes ahead, but obviously I can't do the moving on the CVS server myself. Dave. - Begin Forwarded Message - Date: Sun, 3 Feb 2002 23:24:16 GMT From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Parrot directory structure Parroteers, I've been thinking about the directory structure of Parrot. Currently, the top-level dir is a bit of mess, with zillions of files of various flavours. It is my contention that apart from a few expected files such as README, MANIFEST, Configure.pl etc, everything else should be in subdirs. I have some provisional suggestions for this below. First however, I want to clarify the packaging of parrot vs perl6, because this will affect the depth of directory hieriarchy needed. I can see 3 main possibilites: 1. Perl 6 and Parrot come as essentially two separate packages, with their own config scripts etc. this suggests two separate tarballs 2. They share config, but are separate otherwise this suggests a single tarball with just config/, perl6/, parrot/ subdirs 3. They are completely intermixed, sharing some src files, pre-processing scripts, etc etc. again, a single tarball, but with lots of top-level subdirs For the moment, I've assumed (1); some of the suggested directory names below may need parrot/ prepending to them if (2) or (3) is the case. Anyway, here's how I suggest files should be moved around to make a more rational directory hierarchy. This will involve quite a bit of hacking of paths in makefiles, scripts etc; but if we're going to do it at all, then the sooner the better. Comments? - original file renamed to - -- # parrot/ holds general src code for parrot *.[ch] parrot/*.[ch] # config/ holds files associated with the configuration process Config_pm.inconfig/Config_pm.in Makefile.in config/Makefile.in Types_pm.in config/Types_pm.in config_h.in config/config_h.in test_c.in config/test_c.in test_gnuc.c config/test_gnuc.c testparrotfuncptr.c config/testparrotfuncptr.c test_parrot_sizes.c config/test_parrot_sizes.c # all per-platform files (README, hints, header.[ch], # are collected together in the single directory OS// README.OS_X OS/macos_x/README hints/cygwin.pl OS/cygwin/hints.pl hints/darwin.pl OS/darwin/hints.pl hints/mswin32.plOS/mswin32/hints.pl hints/os2.plOS/os2/hints.pl hints/vms.plOS/vms/hints.pl platforms/win32.h OS/win32/platform.h platforms/win32.c OS/win32/platform.c platforms/generic.h OS/generic/platform.h platforms/generic.c OS/generic/platform.c # bin/ holds executables for 'end-user' use assemble.pl bin/assemble.pl disassemble.pl bin/disassemble.pl optimizer.plbin/optimizer.pl # ops/ holds *.ops files core.opsops/core.ops io.ops ops/io.ops obscure.ops ops/obscure.ops rx.ops ops/rx.ops # better here ? vtable.tbl classes/vtable.tbl # scripts/ holds scripts used during the build process, eg # to pre-process .c files etc jit2h.plscripts/jit2h.pl make.pl scripts/make.pl make_vtable_ops.pl scripts/make_vtable_ops.pl manicheck.plscripts/manicheck.pl ops2c.plscripts/ops2c.pl ops2pm.pl scripts/ops2pm.pl pmc_pm.pl scripts/pmc_pm.pl vtable_h.pl scripts/vtable_h.pl # for consistency these two should be moved too: classes/genclass.pl scripts/genclass.pl classes/pmc2c.plscripts/pmc2c.pl # tmp/ this should be an intially empty directory; build scripts that ned to create transient files should try to put them here where possible # pdd/ all the PDDs really should come under control of CVS. - End Forwarded Message -
