Re: A thought for later -- POD tables
On Sat, Aug 21, 2004 at 12:03:10AM -0600, Luke Palmer wrote: : I've already had my epiphany about POD, though, so I'll spare doing it : again. In short, there are two things that I see about POD that need to : change: : : =over : : =item 1) : : C<=directive> lines shouldn't have to be in their own paragraph, in : order to condense lists and make them more readable from POD source. Yes, I plan to bless that one, though I don't think I've said it publicly. : =item 2) : : (The one that has been made clear several times) When an =end foo closes : a =begin foo that opened the POD section, the =end should close the POD : section. Likewise a bare =for in the middle of Perl code should revert to Perl code at the end. : No tables. Keep the number of things that I can distract myself with : when I should be writing documentation down to a clean 565. I don't : need 566. However. It's possible to make really clean pod tables by processing verbatim lines as tab-separated values. We did the tables in Camel 3 that way, though it took a special preprocessor/postprocessor that understood C<=begin table> and C<=end table>, and also understood that lines consisting of all fields are special, and that consecutive verbatim paragraphs are part of the same table. The main trick is to split not on /\t/ but on /\t+/. That way you can use multiple tabs to keep your columns aligned. The main downside is sometimes your tables get too wide for 80 columns. A secondary downside is that people's formatting gets off when they quote your table in email. I think our table processor also allowed a bit of font modification, which verbatim paragraphs don't normally allow. That was a necessary luxury in our case. But you can make some rather pretty POD tables that actually have enough information to keep the columns straight. Larry Larry
Re: A thought for later -- POD tables
Aaron Sherman writes: > Larry Wall wrote: > > > $_ $xType of Match ImpliedMatching Code > > == = == > > Any Code<$> scalar sub truth match if $x($_) > > > This bit of POD made me think about POD's lack of tabular formatting, What? I see a table. What lack? It looks an awful lot more like a table to me than: > <> H< C<$_> | C<$x> | Type of Match Implied | Matching Code > > T< Any | CodeC<< <$> >> | scalar sub truth | match if C<$x($_)> > does. There are many great things about POD, and this is one of them. Okay, so I want a table in my docs. I don't want to read perlpod to figure out how to write a table. I just write my table and it works as long as I indent. Sure, it won't be as pretty when it gets turned into HTML or LaTeX, but the point is, that it's readable when it gets there in any case. The point of documentation isn't to be pretty, it's to be descriptive. Another great thing about POD is that it doesn't let you be pretty unless you're a brilliant ASCII artist. And then you can focus on your content rather than your look. Excuse me, you I focus on your content rather than your look. I've already had my epiphany about POD, though, so I'll spare doing it again. In short, there are two things that I see about POD that need to change: =over =item 1) C<=directive> lines shouldn't have to be in their own paragraph, in order to condense lists and make them more readable from POD source. =item 2) (The one that has been made clear several times) When an =end foo closes a =begin foo that opened the POD section, the =end should close the POD section. =back No tables. Keep the number of things that I can distract myself with when I should be writing documentation down to a clean 565. I don't need 566. Luke
Re: incremental garbage collection 1/2
Andrà Pang writes: > On 21/08/2004, at 5:48 AM, Leopold Toetsch wrote: > > >3) The copying collector isn't integrated yet. But that should be easy. > >After finishing sweep and if there is some possible wastage in the > >memory pools, these get compacted. > > I thought Parrot wasn't using copying collectors, since you're exposing > PMC addresses to C? It does. Headers don't get copied, but buffers do, which is a pretty elegant way to make a copying collector since you can keep the headers in fixed-size object pools. You will get in trouble if you try to copy a header into a buffer somewhere and use that. But you deserve to get in trouble for being naughty. Luke
A thought for later -- POD tables
Larry Wall wrote: $_ $xType of Match ImpliedMatching Code == = == Any Code<$> scalar sub truth match if $x($_) This bit of POD made me think about POD's lack of tabular formatting, a common idiom in technical documentation. I know POD is still in the wings, as it were, but I wanted to say this before I forget The danger, of course, is that tables are a convinient way to wedge a layout system into a markup system, and given that one of POD's most elegant features is that it is just a simple markup system that has managed to avoid the temptations of layout, I would be loathe to see that change. Still, tables are useful, so here's a simple way to get the kind of table we see above, without the HTMLish trap of pseudo-layout: Because one of the features of POD is that documentation tends to be readable in markup form, an C<=>-introduced markup seems like it would not work well. Instead, we use C<< H<...> >> (headings) and C<< T<...> >> (table body) like so: <> H< C<$_> | C<$x> | Type of Match Implied | Matching Code > T< Any | CodeC<< <$> >> | scalar sub truth | match if C<$x($_)> > And so on... A few rules are applied: Tables cannot be nested (this isn't a layout tool) A table must exist entirely within one paragraph C<< H<..> >> may occur anywhere, but some back-ends may only function correctly if it only appears once at the beginning A literal C<|> must be escaped, as E Any text outside of C<< H<...> >> and C<< T<...> >>, but within the same paragraph is moved outside of the table and used as "caption" for the table, as in: C<< TFigure 1.T >> which would render in text something like: a b c x y z Figure 1. and as HTML something like: abc xyz Figure 1. With some additional hooks, I would imagine, for style-sheet management of table presentation.
Re: Synopsis 2 draft 1 -- each and every
On 8/20/04 5:30 PM, Austin Hastings wrote: > How about "scalar"? The fact that one person, one time, came up with a > need to invoke it doesn't mean we have to race it up the huffman tree. > P6 is winning the DWIM race most of the time contextually. Maybe [#] as > a macro, if you like. Yeah, that's my feeling too. I was going to suggest "sc", but I don't think having to writ out "scalar" is too much of a hardship. I think the drive for a single-char version is driven more by symmetry than expected usage frequency. (I also think S is ugly and _ looks like a typo in many situations) -John
Re: incremental garbage collection 1/2
On 21/08/2004, at 5:48 AM, Leopold Toetsch wrote: 3) The copying collector isn't integrated yet. But that should be easy. After finishing sweep and if there is some possible wastage in the memory pools, these get compacted. I thought Parrot wasn't using copying collectors, since you're exposing PMC addresses to C? -- % Andre Pang : trust.in.love.to.save
Re: adverbs
On Fri, Aug 20, 2004 at 06:12:06PM -0600, Luke Palmer wrote:
: Larry Wall writes:
: > On Fri, Aug 20, 2004 at 04:15:43PM -0600, John Williams wrote:
: > :
: > :say .meth :foo;# say( .meth( foo=>1 ) )
: >
: > That one works.
:
: But that's because :foo is an adverb to .meth, not because .meth is
: taking an argument 'foo' => 1, right?
Correct.
: > Likewise
: >
: > sqrt($x):both
: >
: > could return both the positive and negative root. In this case it's
: > ambiguous whether
: >
: > sqrt $x, :both
: >
: > should treat sqrt as a named unary or a list operator. I don't know
: > offhand which way to bias that, or whether the parser should just
: > throw up its hands in disgust. Or just throw up...
:
: Well, in this case, I'd be tempted to look at which one's more likely to
: blow up sooner when you do it wrong. If we have:
:
: my $root = sqrt $x, :both;
:
: And it assumes sqrt is unary, then you get the equivalent of:
:
: my $root = [ sqrt($x), 'both' => 1 ];
:
: If you have the extremely unlikely:
:
: my $list = sqrt $x, :foo;
:
: Then you get a "sqrt doesn't know what :foo means". That combined with
: the fact that you'll much more rarely see a function call followed by a
: pair, I like that better. On the other hand:
:
: my @check = splice @nums, 0, sqrt $max, :something
:
: :something looks an awful lot more like an argument to splice than to
: sqrt. But again, sqrt will probably blow up immediately, and you can
: fix it. So making it a list op looks far advantageous. That's also an
: argument against using the slurpy hash whenever you can manage.
Agreed. It's not likely to be a big problem either way unless we go
nuts on trying to give consistent modifier names to different sorts
of operators. In particular we should probably try to avoid giving
adverbial arguments to things like assignment and comma.
: > : Do I have my whitespace rules right below?
: > :
: > :say foo :bar; # say( foo( bar=>1 ) ) assuming foo is listy
: > :say .foo :bar; # say( .foo( bar=>1 ) )
: > :say foo: bar; # foo.say(bar)
: >
: > Yes, but works only if "foo" is predeclared as a class.
:
: Or function name.
Righto. Actually, it always assumes listop for an unrecognized bareword,
so we have to make sure it never eats the colon that indicates indirect
object.
: > :say foo:bar ; # ?? say foo :bar ??
: >
: > Yes, like the label colon, the invocant-terminating colon requires
: > whitespace after it if it would be confused with a longer term starting
: > with colon. And /^\:\w+/ is always a named pair of some sort. Otherwise
: > we couldn't string together :foo:bar:baz:utf($ate).
:
: This nice effect is a result of the fact that Perl will use a tokenizer
: at this level. :bar will get tokenized before : will, so that's how
: it's interpreted.
Or at least, the parser functions as a tokener at this level.
: > : Larry also shows this example:
: > :
: > : > @a.sort:quick:{ +$_ } # both adverbs apply to .sort
: > :
: > : Would that work for the functional form too?
: > :
: > : sort :quick :{ +$_ } @a;
: >
: > Not unless you put a comma after the closing curly. Otherwise it's
: > expecting an operator.
:
: Very nice. I was worried about that one, too, where list operators with
: their first argument a closure would require options between the closure
: and the list, which feels wrong (to me). That's assuming that you can
: declare:
:
: sub sort(*&code, +$quick, [EMAIL PROTECTED]) {...}
:
: Perhaps if there's only one &something argument, it automatically
: becomes *&something as to aid usability?
Maybe...have to think about the pragmatic ramifications of that.
Larry
Re: adverbs
Larry Wall writes:
> On Fri, Aug 20, 2004 at 04:15:43PM -0600, John Williams wrote:
> :
> :say .meth :foo;# say( .meth( foo=>1 ) )
>
> That one works.
But that's because :foo is an adverb to .meth, not because .meth is
taking an argument 'foo' => 1, right?
> Likewise
>
> sqrt($x):both
>
> could return both the positive and negative root. In this case it's
> ambiguous whether
>
> sqrt $x, :both
>
> should treat sqrt as a named unary or a list operator. I don't know
> offhand which way to bias that, or whether the parser should just
> throw up its hands in disgust. Or just throw up...
Well, in this case, I'd be tempted to look at which one's more likely to
blow up sooner when you do it wrong. If we have:
my $root = sqrt $x, :both;
And it assumes sqrt is unary, then you get the equivalent of:
my $root = [ sqrt($x), 'both' => 1 ];
If you have the extremely unlikely:
my $list = sqrt $x, :foo;
Then you get a "sqrt doesn't know what :foo means". That combined with
the fact that you'll much more rarely see a function call followed by a
pair, I like that better. On the other hand:
my @check = splice @nums, 0, sqrt $max, :something
:something looks an awful lot more like an argument to splice than to
sqrt. But again, sqrt will probably blow up immediately, and you can
fix it. So making it a list op looks far advantageous. That's also an
argument against using the slurpy hash whenever you can manage.
> : Do I have my whitespace rules right below?
> :
> :say foo :bar; # say( foo( bar=>1 ) ) assuming foo is listy
> :say .foo :bar; # say( .foo( bar=>1 ) )
> :say foo: bar; # foo.say(bar)
>
> Yes, but works only if "foo" is predeclared as a class.
Or function name.
> :say foo:bar ; # ?? say foo :bar ??
>
> Yes, like the label colon, the invocant-terminating colon requires
> whitespace after it if it would be confused with a longer term starting
> with colon. And /^\:\w+/ is always a named pair of some sort. Otherwise
> we couldn't string together :foo:bar:baz:utf($ate).
This nice effect is a result of the fact that Perl will use a tokenizer
at this level. :bar will get tokenized before : will, so that's how
it's interpreted.
> : Larry also shows this example:
> :
> : > @a.sort:quick:{ +$_ } # both adverbs apply to .sort
> :
> : Would that work for the functional form too?
> :
> : sort :quick :{ +$_ } @a;
>
> Not unless you put a comma after the closing curly. Otherwise it's
> expecting an operator.
Very nice. I was worried about that one, too, where list operators with
their first argument a closure would require options between the closure
and the list, which feels wrong (to me). That's assuming that you can
declare:
sub sort(*&code, +$quick, [EMAIL PROTECTED]) {...}
Perhaps if there's only one &something argument, it automatically
becomes *&something as to aid usability?
Luke
Re: adverbs
On Fri, Aug 20, 2004 at 04:18:55PM -0700, Larry Wall wrote: : Only a sig of () makes it *not* look for an argument as a list operator. That's overstated. Only a sig of () or ($x) or (?$x) suppresses list operator-ness on ordinary function names. Larry
Re: adverbs
On Fri, Aug 20, 2004 at 04:15:43PM -0600, John Williams wrote:
: Adverbs are confusing me mightily lately.
:
: It may be that Larry's A12 revision just needs a few examples
: *with* parenthesis to straighten me out.
:
: Here are some semi-coherent attempts to sort it out
: in my mind. Please correct me where I have made mistakes.
:
: What is the rule(s) for when :foo is an adverb, and when :foo
: is just a pair constructor?
:
: So far I think that :foo is an adverb where an operator
: is expected, but :for is a pair constructor where a term
: is expected.
:
: Why is this difference important?
:
: Perhaps because an adverb goes looking for something to
: apply itself to.
Yes.
: How does it decide what to apply itself to?
:
: >4) Adverbs apply to the previous unparenthesized prefix, infix,
: >or postfix operator, bypassing simple terms and other "pill"
: >operators such as circumfix or postcircumfix.
:
: But what about the rules for "additional arguments as adverbs"?
:
: >1d) Additional [function] arguments may occur as adverbs *only* if
: >there are explicit parens.
:
: >2d) Given 2c, additional [method] arguments may occur as adverbs
: >whether or not there is an argument "pill":
:
: I assume rule 1d only applies to arglist parenthesis,
: and not grouping parenthesis?
Yes.
: The legal syntaxes below all mean the same thing, right?
:
:func(1,2,3,:foo); # ok
:func 1,2,3,:foo ; # ok
Those two are the same.
:func(1,2,3):foo ; # ok
That one is a little different. Adverbs are always bound as named
arguments. Pair arguments are bound as named arguments only if they
come between The Positional Arguments and The List. So this example
is the same only if the function is declared with three positional
arguments:
func(:foo, 1,2,3) (+$foo, [EMAIL PROTECTED])
func(1, :foo, 2,3) ($a, +$foo, [EMAIL PROTECTED])
func(1,2, :foo, 3) ($a, $b, +$foo, [EMAIL PROTECTED])
func(1,2,3, :foo) ($a, $b, $c, +$foo, [EMAIL PROTECTED])
Which is why it's good to use <== to be explicit about where your
list starts in these cases.
:func(1,2,3 :foo); # ok (explicit parens)
That one is illegal because the comma between 2 and 3 doesn't take a
:foo adverb. Rule 1d should probably read something like: "...only
if there are explicit parens before it."
Basically, the parens have to be there to direct the gaze of the adverb
at the function name.
:func 1,2,3 :foo ; # ILLEGAL (according to A12 revision)
Illegal for the same reason--the rules apply it to the comma.
: And for 2d, these are the same:
:
:.meth(1,2,3):foo ;
:.meth(1,2,3 :foo);
The second one is illegal for the same reason.
: Does rule 1d or rule 4 does apply inside this parenthesized arglist?
:
:func( eeney, meeny, miney :moe );
:
: Does :moe apply to func (rule 1d) or miney (rule 4)?
It can never apply to func. It can only apply to comma or miney.
: Does it depend on the declaration of miney?
Yes.
:sub miney {...} # simple term: moe applies to func
No, that's not a simple term, but a list operator. So you get miney(:moe)
instead of infix:,(miney, :moe). If you want a bare term you need to say
sub miney () {...}
:sub miney(*%adv) {...} # does a slurpy hash make a function a list operator?
Only a sig of () makes it *not* look for an argument as a list operator.
:sub miney($+moe) {...} # I'll take that moe
You can have it. :-)
(But only if you reverse the $ and the +.)
:sub miney($+curly) {...} # Arg OK, but not that one!
Correct (except for the reversed $ and + again).
: Is this correct according to 2d, assuming func and meth are 0-ary:
:
:say func :foo; # say( func, foo=>1 )
This one's illegal. Gotta have a comma to expect a term.
:say .meth :foo;# say( .meth( foo=>1 ) )
That one works.
: but if func is 2-or-more-ary, then:
:
:say func :foo; # say( func( foo=>1 ) )
Yes.
: A unary function cannot take an adverb, because it has no slurpy hash.
Don't need a slurpy hash for adverbs. Only a matching named parameter.
Unary just means there's exactly one non-optional positional parameter,
so this is a unary operator:
sub prefix:-($x, +$with_prejudice) { negate($x, $with_prejudice) }
and can be called with any of:
-$foo
-$foo:with_prejudice
-$foo:with_prejudice(0)
Likewise
sqrt($x):both
could return both the positive and negative root. In this case it's
ambiguous whether
sqrt $x, :both
should treat sqrt as a named unary or a list operator. I don't know
offhand which way to bias that, or whether the parser should just
throw up its hands in disgust. Or just throw up...
: Is a function with a slurpy hash automatically a list operator,
: even if it has 0 or 1 positional arguments?
Yes. Functions are strongly biased towards being list operators.
Which probably means that we should bias the sqrt example to a list
operator on the basis of the named argument. (But
adverbs
Adverbs are confusing me mightily lately.
It may be that Larry's A12 revision just needs a few examples
*with* parenthesis to straighten me out.
Here are some semi-coherent attempts to sort it out
in my mind. Please correct me where I have made mistakes.
What is the rule(s) for when :foo is an adverb, and when :foo
is just a pair constructor?
So far I think that :foo is an adverb where an operator
is expected, but :for is a pair constructor where a term
is expected.
Why is this difference important?
Perhaps because an adverb goes looking for something to
apply itself to.
How does it decide what to apply itself to?
>4) Adverbs apply to the previous unparenthesized prefix, infix,
>or postfix operator, bypassing simple terms and other "pill"
>operators such as circumfix or postcircumfix.
But what about the rules for "additional arguments as adverbs"?
>1d) Additional [function] arguments may occur as adverbs *only* if
>there are explicit parens.
>2d) Given 2c, additional [method] arguments may occur as adverbs
>whether or not there is an argument "pill":
I assume rule 1d only applies to arglist parenthesis,
and not grouping parenthesis?
The legal syntaxes below all mean the same thing, right?
func(1,2,3,:foo); # ok
func 1,2,3,:foo ; # ok
func(1,2,3):foo ; # ok
func(1,2,3 :foo); # ok (explicit parens)
func 1,2,3 :foo ; # ILLEGAL (according to A12 revision)
And for 2d, these are the same:
.meth(1,2,3):foo ;
.meth(1,2,3 :foo);
Does rule 1d or rule 4 does apply inside this parenthesized arglist?
func( eeney, meeny, miney :moe );
Does :moe apply to func (rule 1d) or miney (rule 4)?
Does it depend on the declaration of miney?
sub miney {...} # simple term: moe applies to func
sub miney(*%adv) {...} # does a slurpy hash make a function a list operator?
sub miney($+moe) {...} # I'll take that moe
sub miney($+curly) {...} # Arg OK, but not that one!
Is this correct according to 2d, assuming func and meth are 0-ary:
say func :foo; # say( func, foo=>1 )
say .meth :foo;# say( .meth( foo=>1 ) )
but if func is 2-or-more-ary, then:
say func :foo; # say( func( foo=>1 ) )
A unary function cannot take an adverb, because it has no slurpy hash.
Is a function with a slurpy hash automatically a list operator,
even if it has 0 or 1 positional arguments?
Do I have my whitespace rules right below?
say foo :bar; # say( foo( bar=>1 ) ) assuming foo is listy
say .foo :bar; # say( .foo( bar=>1 ) )
say foo: bar; # foo.say(bar)
say foo:bar ; # ?? say foo :bar ??
Adverbs are still passed to the function as "just a pair",
so they have to come after positional parameters.
But that's kinda ugly in some cases. Are there ways to get
around it?
If I know the names of the positional parameters, I can put the
adverb (aka pair constructor) first, and pass all the parameters
in via names.
sub foo( $bar, $baz, %*advs) {...}
foo :expletive bar=>3, baz=>42;
If I think my function would look better with the :adverb
next to the function, and still have positional parameters,
I can just declare foo with no named positional parameters,
and any parameters after the adverb will go in the slurpy array.
Larry also shows this example:
> @a.sort:quick:{ +$_ } # both adverbs apply to .sort
Would that work for the functional form too?
sort :quick :{ +$_ } @a;
Does adverbial block find its way into the block parameter,
which was actually declared as an optional positional parameter
(of type Criteria)?
~ John Williams
Re: Synopsis 2 draft 1 -- each and every
Austin Hastings writes:
> Larry Wall wrote:
> >Hmm. Gotta decided if S$foo.bar() is too ugly to live though...
> >
>
> It is.
Agreed.
> >I still kinda like underscore.
> >
> How about "scalar"? The fact that one person, one time, came up with a
> need to invoke it doesn't mean we have to race it up the huffman tree.
> P6 is winning the DWIM race most of the time contextually. Maybe [#] as
> a macro, if you like.
I personally have no problem with "scalar", now that the majority of the
cases where it was necessary can now be replaced with ~, +, or ?. It
can't, of course, when you're dealing with objects generically, and
that's when you use "scalar".
But ever since Larry decided to make "{ }" interpolate, getting rid of
$() on account of adding ~, +, and ?, I've wanted it back so it can go
back in strings. But I'm sure that this is just another one of his
decisions that I'm going to hate for a little while, and then finally
understand and like much better. It worked that way for %hashÂkeyÂ.
Luke
Re: Synopsis 2 draft 1 -- each and every
chromatic wrote: On Fri, 2004-08-20 at 14:26, Austin Hastings wrote: Dan Hursh wrote: generalimpose scalarimpose list ----- D$foo.eat$foo.bite$foo.gobble N$foo.look$foo.peek$foo.peruse hmm, I don't like eat in this case D$foo.take$foo.grab$foo.horde s/horde/hoard/ If I'd written that, I'd claim that as deliberate. Though it does leave a problem with "grab" as a singular noun, Why? Horde is a noun, hoard is a verb like all the other entries in the table. (Some have dual use, like hoard does, as nouns, but...) =Austin
Re: Synopsis 2 draft 1 -- each and every
Chromatic wrote: On Fri, 2004-08-20 at 14:26, Austin Hastings wrote: Dan Hursh wrote: generalimpose scalarimpose list ----- D$foo.eat$foo.bite$foo.gobble N$foo.look$foo.peek$foo.peruse hmm, I don't like eat in this case D$foo.take$foo.grab$foo.horde s/horde/hoard/ If I'd written that, I'd claim that as deliberate. Though it does leave a problem with "grab" as a singular noun, It kinda looked wrong, but, well... 6 of one, a dozen of the other It's all the same to spell check... send it!
Re: [perl #31197] literal.t
Dan Sugalski wrote: Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: At 3:10 PM -0700 8/16/04, Danny Werner (via RT) wrote: Examples from the 2th aoudad book (page 127) did not turn out as expected. Being completely new to this, I did not know where to put the testcode. And now the test's in. Thanks! You guys are great. I tried to fix it myself but my c skills are abominable. (BNF and regex somewhat better, but those appeared to be not enough for the code generation). And fails with: print -0x2a Another one the lexer doesn't cope with. Is it reasonable to allow that? I missed that one. Let's not allow negative hex/oct/binary numbers. Heh. That is my feeling too. A was amazed when I read the examples in the book (p127), that's why I gave it a try. An OCT 0[oO][0-7]+ for octals, if only for symmetry (octal is in the format specifiers), would seem fitting, though. I guess you'll have to make some notes about this for the next edition of the book anyway. No - next edition will be two books: One about Perl6, one about Parrot :-) Those get treated as unsigned, though if they spill over into the sign bit you end up with a negative number. Well, another one of these: "We need exact PDDs for, well, all". BTW my request WRT integer PMCs isn't really fully answered. That's what PDD 17's for. It ought to be filled in better, I agree. Thank you both for your prompt response.
Re: Synopsis 2 draft 1 -- each and every
Larry Wall wrote: On Fri, Aug 20, 2004 at 12:52:56PM -0700, Larry Wall wrote: : Unfortunately, the only obvious one, 's', is taken. I remind myself that 'S' is equally obvious, and not taken. Like _, it suffers from spacing issues, but could be the ASCII backup for the § character. (As Y is likely to be the ASCII backup for ¥. Maybe Y is the nylon zipper operator.) Hmm. Gotta decided if S$foo.bar() is too ugly to live though... It is. I still kinda like underscore. How about "scalar"? The fact that one person, one time, came up with a need to invoke it doesn't mean we have to race it up the huffman tree. P6 is winning the DWIM race most of the time contextually. Maybe [#] as a macro, if you like. =Austin
Re: Synopsis 2 draft 1 -- each and every
On Fri, 2004-08-20 at 14:26, Austin Hastings wrote: > Dan Hursh wrote: > > generalimpose scalarimpose list > > ----- > > D$foo.eat$foo.bite$foo.gobble > > N$foo.look$foo.peek$foo.peruse > > > > hmm, I don't like eat in this case > > > > D$foo.take$foo.grab$foo.horde > > > s/horde/hoard/ If I'd written that, I'd claim that as deliberate. Though it does leave a problem with "grab" as a singular noun, -- c
Re: Synopsis 2 draft 1 -- each and every
Dan Hursh wrote:
Peter Behroozi wrote:
I'm not particular to any of the verbs used yet, but maybe that's
because I don't think of the <> as a general iterator, but more of a
gobbler-type creature (and formerly a globber, too). Could we try:
for $foo.fetch { ... } #or
for $foo.grab { ... } #or
for $foo.eat { ... }
And to replace $/ we could have something like:
for $foo.fetch :upto(",") { ... } #or
for $foo.fetch :until(",") { ... }
generalimpose scalarimpose list
-----
D$foo.eat$foo.bite$foo.gobble
N$foo.look$foo.peek$foo.peruse
hmm, I don't like eat in this case
D$foo.take$foo.grab$foo.horde
s/horde/hoard/
That assumes folks think of grab as being singular and take as being
open ended. That, and I don't want take to colide with gather{take}.
Oh well.
Dan
Re: Benchmark Stuff
Well, after I had something that made comparing differences easier, I reverted back CVS. While I noticed a speed difference, it was very minor which means the significant speed bump is likely related to something non-parrot related. I am going to rebuild the latest/greatest gcc on Monday to see if I can't get back to what I was seeing before. Either way - I think it is a good thing to keep track of our performance impact when making changes - perhaps I will get more motivated and make the code a bit more robust and use parrotbench instead of my homegrown stuff. Cheers Joshua Gatcomb a.k.a. Limbic~Region --- Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Joshua Gatcomb <[EMAIL PROTECTED]> wrote: > > > I recently noticed that the benchmarks in > > examples/benchmarks was running significantly > slower. > > That might very likely be related to current patches > WRT garbage > collection. I've turned off ARENA_DOD_FLAGS, which > was on since quite a > time. Turning that off can cause a lot slower DOD > sweeps for simple > stuff like integers. > > I'm not aware of other recent changes though, that > might have influenced > performance. But I didn't look at it for quite a > time. > > leo > ___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush
Re: Synopsis 2 draft 1 -- each and every
Peter Behroozi wrote:
I'm not particular to any of the verbs used yet, but maybe that's
because I don't think of the <> as a general iterator, but more of a
gobbler-type creature (and formerly a globber, too). Could we try:
for $foo.fetch { ... } #or
for $foo.grab { ... } #or
for $foo.eat { ... }
And to replace $/ we could have something like:
for $foo.fetch :upto(",") { ... } #or
for $foo.fetch :until(",") { ... }
general impose scalar impose list
--- --
D $foo.eat$foo.bite $foo.gobble
N $foo.look $foo.peek $foo.peruse
hmm, I don't like eat in this case
D $foo.take $foo.grab $foo.horde
That assumes folks think of grab as being singular and take as being
open ended. That, and I don't want take to colide with gather{take}.
Oh well.
Dan
Re: "<->" as "->" with automatic "is rw"
On Fri, 20 Aug 2004 13:49:46 -0700, Larry Wall <[EMAIL PROTECTED]> wrote: > Yes, a typo. Though it's not actually clear yet whether you have to > write zips args with semicolons, which is why I partially switched > to ¥ in midthink. Just checking. I wondered if you'd introduced a new feature midthink (and I'd missed it). -- matt
Re: "<->" as "->" with automatic "is rw"
On Fri, Aug 20, 2004 at 04:46:33PM -0400, Matt Diephouse wrote:
: On Fri, 20 Aug 2004 13:31:12 -0700, Larry Wall <[EMAIL PROTECTED]> wrote:
: > It's vaguely possible I could be persuaded on the basis that
: >
: > for zip @a ¥ @b <-> { ($^a,$^b) = ($^b,$^a) }
:
: Shouldn't that be:
:
: for zip @a, @b <-> { ... }
: --or--
: for @a ¥ @b <-> { ... }
:
: ?
Yes, a typo. Though it's not actually clear yet whether you have to
write zips args with semicolons, which is why I partially switched
to ¥ in midthink.
Larry
Re: Synopsis 4 draft 1
On Fri, Aug 20, 2004 at 12:39:35AM -0700, Brent 'Dax' Royal-Gordon wrote: : Larry, you're a genius. Yeah, well, that and 150 cents'll get me a cup of coffee... Larry
Re: "<->" as "->" with automatic "is rw"
On Fri, 20 Aug 2004 13:31:12 -0700, Larry Wall <[EMAIL PROTECTED]> wrote:
> It's vaguely possible I could be persuaded on the basis that
>
> for zip @a ¥ @b <-> { ($^a,$^b) = ($^b,$^a) }
Shouldn't that be:
for zip @a, @b <-> { ... }
--or--
for @a ¥ @b <-> { ... }
?
--
matt
Re: GC/DOD API
Dan Sugalski wrote:
As part of the DOD/GC rework, we need to have a clean, well-documented
API for the garbage collector. Things were clean, though not documented,
for the original DOD and things have gotten significantly messier since.
First is of course one of the goals of these changes. Second "clean" but
undocumented interfaces are useless :)
Part of the point of the GC/DOD rework is to allow alternate GC
implementations (which is why things like write barrier macros are going
in) but this can't be done without knowing what's going on, so...
1)
$ perldoc -F src/gc_ims.c | wc -l# [1] [2]
594
$ wc -l < src/gc_ims.c
882
Please dont't tell me something about "not knowing what's going on" - sorry.
2) I just can't document a not-yet existent API, when I don't know
beforehand, how it should look like.
Did you know, that some of the {get,add}_free_object stuff spread in
headers.c and smallobjctes.c is part of the garbage collector subsystem
API? And of course more of that ... That *will* be documented RSN.
I think getting the API designed and documented *first* is in order,
Well, the API was undefined. Having now two garbage collectors for
objects in place allows easily to define the minimal API for GC
subsystems. Implementing it did clearly expose the shortcomes of the
existing approach.
And: a lot of the API is in place in that file already. And it was there
at the very beginning. Documented.
before any actual work's done on the engine. Otherwise we're going to
end up with a mess, I'll end up reverting to prior CVS versions, and
there'll be mass grumbling. And we just don't want that. :)
Dan, in private mail I said, that the API documentation will be the
outcome of this implementation. Actually I've already started with
writing the docs: by tossing unneeded (and misleading) implementation
details from pdd09_gc :)
leo
[1] wc -l is line count for pure/poor Windows users ;)
[2] omitting that wc stuff helps reading the docs - SCNR
Re: "<->" as "->" with automatic "is rw"
On Fri, Aug 20, 2004 at 10:07:02PM +0200, Juerd wrote:
: I'm proposing
:
: for zip(@foos, @bars, @xyzzies) <-> $foo, $bar, $xyzzy { ... }
: for %quux.kv <-> $key, $value { ... }
That'd probably work on the keys only if the hash was declared to have
object keys. At least in Perl 5, the key is always a copy.
: to mean
:
: for zip(@foos, @bars, @xyzzies) -> $foo is rw, $bar is rw, $xyzzy is rw { ... }
: for %quux.kv -> $key is rw, $value is rw { ... }
:
: Comments, anyone?
It's really sick, and cute, and I love it. Unfortunately I'm not sure
it passes the "Are there already too many ways to declare a sub?" test...
It's vaguely possible I could be persuaded on the basis that
for zip @a ¥ @b <-> { ($^a,$^b) = ($^b,$^a) }
could be made to work. But I'm still dubious. And arguably -> {...}
means the same as sub () {...}, implying there are no arguments.
Larry
Re: [perl #31197] literal.t
At 9:36 PM +0200 8/20/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: At 3:10 PM -0700 8/16/04, Danny Werner (via RT) wrote: Examples from the 2th aoudad book (page 127) did not turn out as expected. Being completely new to this, I did not know where to put the testcode. And now the test's in. Thanks! And fails with: print -0x2a Another one the lexer doesn't cope with. Is it reasonable to allow that? I missed that one. Let's not allow negative hex/oct/binary numbers. Those get treated as unsigned, though if they spill over into the sign bit you end up with a negative number. Well, another one of these: "We need exact PDDs for, well, all". BTW my request WRT integer PMCs isn't really fully answered. That's what PDD 17's for. It ought to be filled in better, I agree. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Synopsis 2 draft 1 -- each and every
On Fri, Aug 20, 2004 at 12:52:56PM -0700, Larry Wall wrote: : Unfortunately, the only obvious one, 's', is taken. I remind myself that 'S' is equally obvious, and not taken. Like _, it suffers from spacing issues, but could be the ASCII backup for the § character. (As Y is likely to be the ASCII backup for ¥. Maybe Y is the nylon zipper operator.) Hmm. Gotta decided if S$foo.bar() is too ugly to live though... I still kinda like underscore. Larry
"<->" as "->" with automatic "is rw"
I like that arguments will be readonly by default. But when I look at my
current code, I see that I would be typing " is rw" quite a lot, which in
my opinion is too long for a thing that occurs very often.
Every such situation in my code is a foreach loop. A thing that in Perl
6 will mostly be used with the pointy sub declaration syntax.
If I'm not mistaken, <-> is still available. It communicates
"bidirectional" and that is more or less the same as read/write access.
I'm proposing
for zip(@foos, @bars, @xyzzies) <-> $foo, $bar, $xyzzy { ... }
for %quux.kv <-> $key, $value { ... }
to mean
for zip(@foos, @bars, @xyzzies) -> $foo is rw, $bar is rw, $xyzzy is rw { ... }
for %quux.kv -> $key is rw, $value is rw { ... }
Comments, anyone?
Juerd
Re: Synopsis 2 draft 1 -- each and every
On Thu, Aug 19, 2004 at 08:12:37PM -0500, Peter Behroozi wrote:
: And to replace $/ we could have something like:
:
: for $foo.fetch :upto(",") { ... } #or
: for $foo.fetch :until(",") { ... }
I suppose in <>-ese, that could be one of:
for $foo.< :upto(",") > { ... } #or
for $foo.< :until(",") > { ... }
That sort of thing lets you do context-sensitive chunking, which is
a plus. But I think in the usual case people will be setting the
chompish bits on the handle at open time. The option there might
be :chomp(","), so maybe the override should be the same:
for $foo.< :chomp(",") > { ... }
which kind of gets you back to your eating metaphor. (In either
case, the delimiter is removed from the input string, but available
as $_.chomped or some such.)
Larry
Re: incremental garbage collection 1/2
At 9:48 PM +0200 8/20/04, Leopold Toetsch wrote: 0) Parrot's nomenclature DOD vs GC is a bit misleading. The "DOD" subsystem is the stop-the-world mark & sweep collector that recycles object headers. The "GC" is the copying collector for variable sized string and other buffer memory. The incremental mark & sweep collector (src/gc_ims.c) is an alternative for the DOD thingy and reuses some code in src/dod.c. Nah, this is actually correct. The DOD does, in fact, look for dead objects (if you consider PMC and buffer headers objects. The GC, on the other hand, collects up garbage memory, making the assumption that all the objects marked live are, in fact, live. Separate phases, separate purposes. This works on the presumption that our mutable strings chew up memory more than objects in the normal running of things, which seems bourne out by the programs that look like 'normal' code. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Synopsis 2 draft 1 -- each and every
On Fri, Aug 20, 2004 at 10:49:17AM -0600, Luke Palmer wrote:
:
: method postcircumfix:<> ($self: *%opt) returns List {
: scalar $self.<*%opt>, $self.<*%opt> # [1]
: }
:
: [1] Look, Larry, I had to use C! Maybe we _do_ need to revive
: $()!
It's not clear to me that $() would have made this more readable...
I think if we ever come up with a single-character unary scalar
operator, it should be something other than '$'. I just don't like
the look of '$($', nor the fact that the inner $ is doing something
quite different from the outside one.
Maybe we could resurrect the '_' operator to mean scalar() at the
symbolic unary precedence level. Underline looks sufficiently
different from $. Your example would then be:
method postcircumfix:<> ($self: *%opt) returns List {
_$self.<*%opt>, $self.<*%opt> # [1]
}
Then I suppose binary _ would be defined as:
$a _ $b
is the same as
_($a, $b)
which is the same as
[$a, $b]
Not clear what $a _ $b _ $c would mean though...
Hmm. There's another possibility. We just got through explaining how
the => binary operator imposes scalar on its right side. There's no
corresponding unary operator. So we could make one:
method postcircumfix:<> ($self: *%opt) returns List {
=>$self.<*%opt>, $self.<*%opt> # [1]
}
then the definition of binary => is already obvious. On the other
hand, unary =>$x probably ought to mean $_ => $x or some such (where
"some such" includes "nothing at all"). And I'd prefer to keep all
the symbolic unaries single chars. So I lean towards _.
But something is tickling the back of my mind as a different proposed
meaning for bare _ as a token, and I can't remember what. Placeholders
for anonymous unification, a la Prolog, maybe. Whatever it is, it
could probably coexist with _ as a unary, much like we're thinking
of making unary * coexist with a splat slice in a multidimensional
subscript.
Since _ would primarily be used as a unary, it wouldn't suffer as
much from ambiguity as when it was proposed for string concat, where
$a_$b would be a syntax error. It would be a problem for functions
calls, however:
push @x, _ myfunc();
But really, that's no more characters than:
push @x, =>myfunc();
I don't see any other single-character candidates. It's probably
time to do an exhaustive check again. First of all, none of the
alphabetic ones are any better than underscore, except possibly
for mnemonic value. Unfortunately, the only obvious one, 's', is
taken. That leaves punctuation. Here's what my keyboard offers
in ASCII:
say `myfunc(); # taken
say ~myfunc(); # taken
say !myfunc(); # taken
say @myfunc(); # taken
say #myfunc(); # taken
say $myfunc(); # taken
say %myfunc(); # taken
say ^myfunc(); # possible, but easily confused with +^
say &myfunc(); # taken
say *myfunc(); # taken
say (myfunc(); # taken
say )myfunc(); # pragmatically impossible (breaks bracket matching)
say -myfunc(); # taken
say _myfunc(); # indentifer character in C culture
say +myfunc(); # taken
say =myfunc(); # visually and semantically confusing
say [myfunc(); # taken
say ]myfunc(); # pragmatically impossible (breaks bracket matching)
say {myfunc(); # taken (and then taken some more)
say }myfunc(); # pragmatically impossible (breaks bracket matching)
say \myfunc(); # taken
say |myfunc(); # visually and semantically confusing
say ;myfunc(); # too important as expression stopper: loop ;; {...}
say :myfunc(); # taken
say 'myfunc(); # taken
say "myfunc(); # taken
say ,myfunc(); # visually and semantically confusing
say myfunc(); # visually and semantically confusing
say /myfunc(); # taken
say ?myfunc(); # taken
If we're willing to take the Latin-1 hit, then we also have these
punctuational possibilities:
¡ 00A1INVERTED EXCLAMATION MARK
¢ 00A2CENT SIGN
£ 00A3POUND SIGN
¤ 00A4CURRENCY SIGN
¥ 00A5YEN SIGN
¦ 00A6BROKEN BAR
§ 00A7SECTION SIGN
¨ 00A8DIAERESIS
© 00A9COPYRIGHT SIGN
ª 00AAFEMININE ORDINAL INDICATOR
« 00ABLEFT-POINTING DOUBLE ANGLE QUOTATION MARK
¬ 00ACNOT SIGN
00ADSOFT HYPHEN
® 00AEREGISTERED SIGN
¯ 00AFMACRON
° 00B0DEGREE SIGN
± 00B1PLUS-MINUS SIGN
² 00B2SUPERSCRIPT TWO
³ 00B3SUPERSCRIPT THREE
´ 00B4ACUTE ACCEN
Re: incremental garbage collection 2/2
Matt Fowles <[EMAIL PROTECTED]> wrote: > Leo~ > On Fri, 20 Aug 2004 16:26:33 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote: >> And yes, I'm really thinking of inserting these A* nodes. Freezing an >> object does need it. DOD of course not really. > How is space going to be made for these? DOD probably does not want > to allocate the dummy spaces to refer back to previous elements (since > it might be called in low memory situations), but without them the > subtree assertion might not hold. Good question. 1) I'm thinking of allocating these place holders in aggregates only, or better in "old" aggregates. 2) While it of course takes up resources, it doesn't impose a problem for low memory situation. The incremental collector isn't triggered by low memory (which actually isn't low memory at all - resource shortage, empty free list is the trigger in our old DOD system). Incremental DOD is triggered by allocations. For A allocations k.A work is done in the collector. The throttle factor k defines the memory usage vs speed behavior of the collector. With low k values memory usage can go up significantly, with high k values space wastage is minimal but it takes much more time to just do more cleanup. 3) So while that extra placeholder of course is a valuable resource it would save a lot of time to help preserving the object graph or at least to rebuild big chunks of the graph quickly as needed by the generational GC scheme and by object freezing. > Thus your subtree assertion would only be true with dummies in place. Yep. That's true. > But we cannot tell how many dummies an object graph would generate > ahead of time. No, we can't. But we can gather statistics during a DOD run. And we can reuse these numbers in the next DOD run, when visiting the same aggregate again. It doesn't make sense to do that for a small tuple of course, But scanning an array with 100.000 items could be vastly improved with some meta-information for that aggregate. Basically a bit "old_generation" and a word "skip N words to skip my graph" would suffice. > ... In fact, the root could be a dummy after every single > other object if they all referenced it. Thus I don't know how we > could get around allocating dummies dynamically... I'd rather not consider all of the root set for constructing the full object graph in the first place. I'm thinking of something like this: - mark the long-lived part of the root set (globals, interpreter internals, deeply buried lexicals ...) - trace children of that partial root set - immediately before sweep: stop-the-world now - mark volatile root set (Parrot registers, top lexicals, C stack) - reorder graph by hanging in already scanned old generation - sweep, then start over While that scheme doesn't really guarantee real time (i.e fixed bounded) operation, it ought to be soft real time. The fast moving part of the root set get scanned last. All intermediate temporaries aren't even looked at. The write barrier assures that the already scanned graphs (the old generation) isn't changed, or better, if it got changed, it gets rescheduled for a re-scan or updated immediately to reflect that change. So allocating these dummy placeholders would be done basically in the old generation only. The probably high count of multiple references in the volatile root set is ignored for garbage collection. For freezing the whole interpreter it would need consideration though. Summary: - the old generation graph is always uptodate - on massive changes to such an old object it's taken out of old - the young generation's graph is created last and dynamically That's what is crawling around in my head since quite a time. I dunno if it's really doable. But I think it could work. > Matt leo
incremental garbage collection 1/2
[ Oops that one got the wrong address, resent ] Original Message To: perl6-internals-subscribe ... Some remarks 0) Parrot's nomenclature DOD vs GC is a bit misleading. The "DOD" subsystem is the stop-the-world mark & sweep collector that recycles object headers. The "GC" is the copying collector for variable sized string and other buffer memory. The incremental mark & sweep collector (src/gc_ims.c) is an alternative for the DOD thingy and reuses some code in src/dod.c. We need to go incremental because arbitrary long pauses during stop-the-world are not convenient for interactive programs. BTW a refcount scheme can also suffer from long pauses. Albeit refcounting is very incremental during normal operation, it can pause arbitrary long, if decrementing one refcount causes the cleanup of an huge amount of other objects (like in C< @huge_array = undef >) 1) The incremental garbage collector is functional, it passes all tests 2) Its totally untuned but should run with reasonable incremental timing and memory requirement. And its probably[1] not faster then stop-the-world, it just does its work in small steps but still has to do all the work. 3) The copying collector isn't integrated yet. But that should be easy. After finishing sweep and if there is some possible wastage in the memory pools, these get compacted. Please give it a try. C has two defines to turn one on and one off. leo [1] cache coherency for incremental could be better.
Re: [perl #31197] literal.t
Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 3:10 PM -0700 8/16/04, Danny Werner (via RT) wrote: >>Examples from the 2th aoudad book (page 127) did not >>turn out as expected. Being completely new to this, >>I did not know where to put the testcode. > And now the test's in. Thanks! And fails with: print -0x2a Another one the lexer doesn't cope with. Is it reasonable to allow that? My gut feeling towards hex, oct, and bin notation is: the digits are unsigned. But, as we don't have unsigned numbers at all (or almost), they are converted to the signed integer these bits are reflecting. 0x => -1 which of course is wrong on a 64-bit machine. Or we are taking it as signed and create a BigInt constant, if it doesn't fit. Then above notation would make some sense. Well, another one of these: "We need exact PDDs for, well, all". BTW my request WRT integer PMCs isn't really fully answered. We really ought to nail down that stuff step by step. And, while IIRC the test was from an P6PE example, it's of course not carved in stone, that the Parrot PASM/PIR lexer does follow totally Perl6 literal syntax. We should use a common reasonable compromise of major languages we want to support. leo
Re: Benchmark Stuff
Joshua Gatcomb <[EMAIL PROTECTED]> wrote: > I recently noticed that the benchmarks in > examples/benchmarks was running significantly slower. That might very likely be related to current patches WRT garbage collection. I've turned off ARENA_DOD_FLAGS, which was on since quite a time. Turning that off can cause a lot slower DOD sweeps for simple stuff like integers. I'm not aware of other recent changes though, that might have influenced performance. But I didn't look at it for quite a time. leo
Re: Benchmark Stuff
Joshua Gatcomb wrote: I recently noticed that the benchmarks in examples/benchmarks was running significantly slower. I update Cygwin and Parrot daily - so there have been a lot of changes to account for. I idly asked on IRC if anyone was regularly tracking benchmark performance because I was feeling lazy. Dan said not that he was aware of but if I was willing to whip something up in Perl he would be more than happy to do so on a regular basis. Well, I can't get Pg working on Cygwin anymore (should have regression tests everytime I update) so after messing with it for an hour I decided to use SQLite. I also couldn't get File::Basename to work correctly so I gave up and rolled my own regex. Since at this point it was no longer portable I just threw caution to the wind and coded it *nix centric. It assumes the parrot executable is in your $PATH env It assumes it is being run from examples/benchmark It is also a very quick hack because I was on my lunch break. Take a look at tools/dev/parrotbench.pl It already does most of the things you want, you just have to parse it's output and feed it to your database. Enjoy Joshua Gatcomb a.k.a. Limbic~Region Cheers, Sebastian ___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush
GC/DOD API
As part of the DOD/GC rework, we need to have a clean, well-documented API for the garbage collector. Things were clean, though not documented, for the original DOD and things have gotten significantly messier since. Part of the point of the GC/DOD rework is to allow alternate GC implementations (which is why things like write barrier macros are going in) but this can't be done without knowing what's going on, so... I think getting the API designed and documented *first* is in order, before any actual work's done on the engine. Otherwise we're going to end up with a mess, I'll end up reverting to prior CVS versions, and there'll be mass grumbling. And we just don't want that. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Test::MockObject nits?
> The docs may be misleading, especially as there's code in > Test::MockObject that really should live in something like > Test::MockModule or Test::MockPackage, neither of which exist yet. > > The important point is that you always have to work with the object > returned from Test::MockObject::Extends->new(), as it's the only one > with the special instancey behavior. ok, now I see where you're going :) living with the object limitation is fine, as that handles most of the general cases - I can still use fake_new() so that the calling class constructs a mock object of my choosing. however, I might suggest that there be some generic fake_constructor($name) method or something - if I want to subvert, say, DBI behind the scenes I would want to override connect() for the class instead of new(). also, if you fancy making fake_new() return $self, mock() and unmock() in Extends also don't return $self, which makes them different from the MockObject versions. anyway, thanks for taking the time to discuss things a bit :) --Geoff
Re: Test::MockObject nits?
On Fri, 2004-08-20 at 11:24, Geoffrey Young wrote: > Test::MockObject is clearly object/instance based. > Test::MockObject::Extends is documented to mock either an object or the > class as a whole. if that's not the case that is fine (I guess ;), but then > I'm very confused what value passing a class name to new() adds - the docs > claim that it is for mocking class methods, doesn't it? The docs may be misleading, especially as there's code in Test::MockObject that really should live in something like Test::MockModule or Test::MockPackage, neither of which exist yet. The important point is that you always have to work with the object returned from Test::MockObject::Extends->new(), as it's the only one with the special instancey behavior. If you want to override globally a class method to return T::MO::E objects, you're mostly on your own. It might be *useful* to do that with T::MO::E somehow, but I'd rather make the mistake of not blurring the mock object/mock package thing in T::MO::E, having done the opposite in T::MO. -- c
Re: Test::MockObject nits?
> It's your understanding. You're not mocking the class as a whole. > You're mocking an instance. If it helps, think of prototype-based > programming, where you don't inherit from classes, you inherit from > other objects and selectively override or add methods on the new > objects. hmm, ok, I'll accept that I'm out of whack here :) but I'm still a bit confused. Test::MockObject is clearly object/instance based. Test::MockObject::Extends is documented to mock either an object or the class as a whole. if that's not the case that is fine (I guess ;), but then I'm very confused what value passing a class name to new() adds - the docs claim that it is for mocking class methods, doesn't it? --Geoff
Re: Test::MockObject nits?
On Fri, 2004-08-20 at 11:03, Geoffrey Young wrote:
> hmph, I'm actually having a difficult time getting ::Extends to do what I
> would think it would do. consider
>
> use Test::MockObject::Extends;
> my $mock = Test::MockObject::Extends->new('IO::File');
> $mock->mock('open', sub { print "mocked open\n" });
>
> IO::File->open;
>
> which yields an IO::File::open() error - I would have expected my own
> subroutine to be called instead. some poking around shows me that if you
> call fake_new() then $class->new->method() works ok, but class methods
> themselves are not overridden, including new(), which is a handy thing to be
> able to override :)
>
> anyway, is something wrong with the code or my understanding of what
> Test::MockObject::Extends is capable of?
It's your understanding. You're not mocking the class as a whole.
You're mocking an instance. If it helps, think of prototype-based
programming, where you don't inherit from classes, you inherit from
other objects and selectively override or add methods on the new
objects.
If you've never used Self or any advanced JavaScript, ignore that
metaphor. :)
-- c
Re: Test::MockObject nits?
> my $mock = Test::MockObject->new('IO::Socket::INET');
>
> $mock->fake_new('IO::Socket::INET')
>->set_false('connected')
>->mock('error', sub { 'localerror' });
>
> the goal being that when my class calls IO::Socket::INET->new($args) that it
> fails, returning my error string.
>
> well, it works great (thanks!)
hmph, I'm actually having a difficult time getting ::Extends to do what I
would think it would do. consider
use Test::MockObject::Extends;
my $mock = Test::MockObject::Extends->new('IO::File');
$mock->mock('open', sub { print "mocked open\n" });
IO::File->open;
which yields an IO::File::open() error - I would have expected my own
subroutine to be called instead. some poking around shows me that if you
call fake_new() then $class->new->method() works ok, but class methods
themselves are not overridden, including new(), which is a handy thing to be
able to override :)
anyway, is something wrong with the code or my understanding of what
Test::MockObject::Extends is capable of?
--Geoff
Re: incremental garbage collection 2/2
Leo~ On Fri, 20 Aug 2004 16:26:33 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > And yes, I'm really thinking of inserting these A* nodes. Freezing an > object does need it. DOD of course not really. How is space going to be made for these? DOD probably does not want to allocate the dummy spaces to refer back to previous elements (since it might be called in low memory situations), but without them the subtree assertion might not hold. Consider A refs B, C; B refs D; C refs D The DFS would be A > B > D > C (without dummies) A > B > D > C > D* (with dummies) But the freeze tree for C would be C > D Thus your subtree assertion would only be true with dummies in place. But we cannot tell how many dummies an object graph would generate ahead of time. In fact, the root could be a dummy after every single other object if they all referenced it. Thus I don't know how we could get around allocating dummies dynamically... Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -???
Benchmark Stuff
I recently noticed that the benchmarks in examples/benchmarks was running significantly slower. I update Cygwin and Parrot daily - so there have been a lot of changes to account for. I idly asked on IRC if anyone was regularly tracking benchmark performance because I was feeling lazy. Dan said not that he was aware of but if I was willing to whip something up in Perl he would be more than happy to do so on a regular basis. Well, I can't get Pg working on Cygwin anymore (should have regression tests everytime I update) so after messing with it for an hour I decided to use SQLite. I also couldn't get File::Basename to work correctly so I gave up and rolled my own regex. Since at this point it was no longer portable I just threw caution to the wind and coded it *nix centric. It assumes the parrot executable is in your $PATH env It assumes it is being run from examples/benchmark It is also a very quick hack because I was on my lunch break. Enjoy Joshua Gatcomb a.k.a. Limbic~Region ___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush benchmark Description: benchmark
Re: [perl #31197] literal.t
At 3:10 PM -0700 8/16/04, Danny Werner (via RT) wrote: Examples from the 2th aoudad book (page 127) did not turn out as expected. Being completely new to this, I did not know where to put the testcode. And now the test's in. Thanks! -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Synopsis 4 draft 1 -- const block params and placeholders
On Fri, Aug 20, 2004 at 09:04:48AM -0700, Dave Whipp wrote:
: > Parameters are by default constant within the block. You can
: > declare a parameter read/write by including the "C" trait.
: > If you rely on C<$_> as the implicit parameter to a block, then
: > then C<$_> is considered read/write by default. That is,
: > the construct:
: >
: > for @foo {...}
: >
: > is actually short for:
: >
: > for @foo -> $_ is rw {...}
: >
: > so you can modify the current list element in that case. However,
: > any time you specify the arguments, they default to read only.
:
: OK, so explicit params are const, and implicit $_ is rw.
There's an implicit C<[EMAIL PROTECTED] is rw> on C too, implying that @_[0]
etc.
are rw.
: There's another type of implicit arg: placeholders. is $^a "const", or "rw",
: by default? is there any way to control it?
My first inclination is to say that they're "constant" (not "const").
My second inclination is to say that it could depend on how you
use them. My third inclination is to go back to my first inclination.
Placeholders have to be a very lightweight mechanism. If you want to do
anything fancy at all, you have to use some other mechanism.
: Is $_ always rw, or only rw when there are no args. I.e.
It's only rw when it's declared rw. (And when there are no args,
the default declaration is C<$_ is rw>.)
: for @a -> $a {
: $a ++; # error: $a is const
"constant". There ain't no such thing as "const" in Perl.
: $_++;# increments $a, because $_ is implicitly bound to the same elem
: as $a?
Nope, error. $_ is rw only if $a is rw.
: $^a++; # Can we mix placeholders with explicit args? Is this also bound
: to $a's element?
Nope, error. Can't do anything fancy with $^a, including trying to
mix and match with real argument declarations. As a consequence, it's
impossible even to forward declare a placeholder function. If you find
yourself wanting to do that, you should be using some other mechanism.
Larry
Re: Synopsis 2 draft 1 -- each and every
David Green writes:
> Then I thought that maybe "for" doesn't need to work lazily (except that
> the conveniently just-posted Synopsis 4 confirms that it is supposed to
> be lazy). Or maybe "for" is only "as lazy as is reasonable", meaning if
> it knows how (e.g. if you're using an array or filehandle, which have
> known ways to meander through lazily), or if you write a really fancy
> iterator for your object that can handle laziness.
The implementation of C will be very simple. Something like:
sub for ([EMAIL PROTECTED], *&code) {
code(*splice @args: 0, &code.arity) while @args;
}
So all the laziness goes into the array implementation. But you don't
even need to write your iterator fancily. If you just write your scalar
version of postcircumfix:<>, Perl will do the rest. The list version
isn't all that complicated either. Something like:
method postcircumfix:<> ($self: *%opt) returns List {
scalar $self.<*%opt>, $self.<*%opt> # [1]
}
If I write it functionally like that, Perl will still do all the rest.
Laziness is built right in the language. And that's one of the biggest
semantic differences from Perl 5.
Luke
[1] Look, Larry, I had to use C! Maybe we _do_ need to revive
$()!
Test::MockObject nits?
hi chromatic :)
given being pointed toward Test::MockObject::Extends last time I decided to
rework my tests to use it instead of a dozen local overrides. I immediately
ran into a little snag.
I want to override IO::Socket::INET so that a class calling it's constructor
will use my mocked object. so I tried this:
my $mock = Test::MockObject->new('IO::Socket::INET');
$mock->fake_new('IO::Socket::INET')
->set_false('connected')
->mock('error', sub { 'localerror' });
the goal being that when my class calls IO::Socket::INET->new($args) that it
fails, returning my error string.
well, it works great (thanks!)... except fake_new() doesn't return $self
like all the other methods seem to do, so I can't really chain the calls
together like I would have expected to be able to do. patch attached :)
also, I was a little confused by this note in the
Test::MockObject::fake_new() docs:
"Note: see Test::MockObject::Extends for a better alternative to this method."
if the goal of Extends.pm is to fake an entire class, then wouldn't that
include the class constructor? at first I got the impression that I was
doing something wrong, but then I figured it was just a chicken-and-egg
thing since I started with Extends. or maybe I am doing something wrong (or
at least something non-idiomatic...)
--Geoff
--- lib/Test/MockObject.pm Thu Mar 25 23:04:57 2004
+++ lib/Test/MockObject.pm.geoff Fri Aug 20 12:29:45 2004
@@ -269,6 +269,7 @@
{
my ($self, $class) = @_;
$self->fake_module( $class, new => sub { $self } );
+ $self;
}
{
--- lib/Test/MockObject/Extends.pm Thu Mar 25 22:58:56 2004
+++ lib/Test/MockObject/Extends.pm.geoff Fri Aug 20 12:28:42 2004
@@ -118,7 +118,7 @@
use Test::MockObject::Extends;
my $object = Some::Class->new();
- my $mock_object = Test::MockObject::Extends( $object );
+ my $mock_object = Test::MockObject::Extends->new( $object );
$mock->set_true( 'parent_method' );
Re: Synopsis 4 draft 1
On Fri, Aug 20, 2004 at 09:18:06AM -0500, Jonathan Scott Duff wrote:
: Whither REDO {...} ? Or do we just manufacture that ourselves with
: NEXT?
Hmm, well, you can view C as just a C in disguise,
or as a C that suppresses the "while" check. But I think it's
seldom enough used that it doesn't rate the mindspace of a REDO.
Very few blocks would have multiple Cs, and that's the only
reason you might want a REDO block. In contrast, many blocks have
multiple explicit Cs, as well as the implicit "next" of falling
out the bottom of the loop.
Larry
Re: Synopsis 4 draft 1
Aaron Sherman writes:
> Larry Wall wrote:
> > leave :from(Loop) :labelÂLINEÂ <== 1,2,3;
> > [...]
> > leave <== :foo:bar:baz(1) if $leaving;
>
> I know it's probably just me, but This section seems to suddenly rely on
> a lot more knowledge of the current state of Perl 6 syntax than I have.
> Can someone walk me through these two examples?
Sure.
leave :from(Loop) :labelÂLINEÂ <== 1,2,3;
Is the same as:
leave('from' => Loop, 'label' => 'LINE', 1, 2, 3);
#+$from +$label[EMAIL PROTECTED]
The :foo(Bar) syntax is just another way to write 'foo' => Bar. That
actually goes for any :foo[bar] for any bracketing construct []. See
Exegesis 7 for the first of the explanations of those.
I haven't seen :foo:bar:baz(x) before, but I'd assume that it's the same
as :foo :bar :baz(x), which means 'foo' => 1, 'bar' => 1, 'baz' => x .
> What's a C<:from(Loop)>, for example, and how is C<:foo:bar:baz(1)>
> (what looks like a set of properties to me) related to pairing? Wouldn't
> that be:
>
> leave <== 'a'=>'x', 'b'=>'y', 'c'=>'z' if $leaving
That would also work. They're semantically equivalent.
Luke
Re: Return with no expression
On Fri, Aug 20, 2004 at 09:21:02AM +0100, Matthew Walton wrote: : It would be nice if rand behaved a bit more sanely in Perl 6. I can : understand the reasoning for making rand 0 produce between 0 and 1, but : that doesn't mean I have to like it. What makes you think there was any "reasoning" involved? As far as I can recall, it was entirely due to random factors. :-) I suspect there's an argument that [0,0) ought to be considered undef (which would conveniently numerify to 0 with an optional warning). Larry
Re: incremental garbage collection 2/2
Matt Fowles <[EMAIL PROTECTED]> wrote: > Leo~ > Nice summary of the issues, but I have a few nits to pick Thanks. I'll only look at DFS. It more cache-friendly. > Thus I don't think that BFS works. Now lets consider DFS of both sets. > A refs C,B; B refs D, E; C refs E; D refs G; E refs A Ah, some referential loops, that ought to come :) > DFS using root of A for (a): > A > C > E > B > D > G Well, freezing that yields: A > C > E > A* > B > D > G > DFS for freezing B for (b): > B > D > G > E > A > C And B > D > G > E > A > C > E* > B* The nodes with an asterix are of course denoting duplicates. When you now follow the chain beginning at A: A > C > (E* := E) > A* > (B* := B) > D > G the first one is contained in the second one. If a duplicate is detected it's just noted, but not followed further. > It has occurred to me that you might mean the implicit graph of all > objects rather than the explicit linked list of objects that (a) and > (b) create. It ought to be the explicit graph, at least for non-self-referential structures, which I consider being the normal case. For self-referential ones the question is possibly: can we use the graphs (by reordering like above) or is it just cheaper to rebuild. And yes, I'm really thinking of inserting these A* nodes. Freezing an object does need it. DOD of course not really. > Hope that made sense, Yep, a lot. > Matt leo
Re: [perl #31197] literal.t
Dan Sugalski wrote: print 0X2A Fixed. leo
Re: [perl #31197] literal.t
Dan Sugalski <[EMAIL PROTECTED]> wrote: >> print 0x2A >> print "\n" >> print 0X2A > > on this line. > Leo, any reason to be case sensitive on this stuff you can think of? Nah. Not really. The lexer evolves, as it did with float parsing. And all untested stuff doesn't work ;) leo
Re: [perl #31138] [TODO] Configure - dependencies fix
Dan~ Sounds good. I will start on that, but don't hold your breath as it may take a little while. I will try to keep abreast of current CVS. Matt On Fri, 20 Aug 2004 10:37:14 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 10:12 AM -0400 8/20/04, Matt Fowles wrote: > >Dan~ > > > >Just a few small questions about scons to clarify... > > > >On Fri, 20 Aug 2004 09:16:24 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote: > >> Whatever we use is fine as long as: > >> > >> a) We can edit the dependency file without having to know the > >> language the tool's written in > > > >I believe that scons will be able to automatically determine > >dependencies for most of what we do and what little we don't can be > >specified with little enough syntax that actual knowledge of the > >syntax is irrelevant. > > Heh. I think you may underestimate the amount of preprocessing we do. > :) Still, good enough. > > > > b) the tool can be convinced to scan the entire tree at startup and > >> build a rebuild script that doesn't need the tool itself > > > >it can be told to output what commands it would issue (to stdout) but > >not issue them. This output could be captured into a shell script of > >some such. > > Is it clever enough to do cross-platform stuff? That is, can I run it > on OS X and have it spit out a DOS batch file? (Not that this is a > showstopper or anything, but it'd be really useful for cross-platform > stuff and maintenance of the distribution) > > > > c) It's a language we can guarantee we've got available (which means > >> either C or a language that compiles to parrot bytecode) > > > >It is entirely in Python, thus while we do not yet have it compiling > >down to Parrot, conceptually it could... > > > >I realize that none of those were questions, so here is the question. > >Given those answers to your requirements, would such a build system > >likely be accepted or would I be wasting effort? > > Given that it sounds like it meets the criteria, I think it'd be > fine. The only hitch I could see is if it uses C modules for python, > which'd make generating pure bytecode for it tough. We could look at > fixing that, though. (It'd be interesting if scons could be > completely handled by the bytecode translator. A useful test) > > > -- > Dan > > --it's like this--- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even >teddy bears get drunk > -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -???
Re: Synopsis 4 draft 1 -- const block params and placeholders
> Parameters are by default constant within the block. You can
> declare a parameter read/write by including the "C" trait.
> If you rely on C<$_> as the implicit parameter to a block, then
> then C<$_> is considered read/write by default. That is,
> the construct:
>
> for @foo {...}
>
> is actually short for:
>
> for @foo -> $_ is rw {...}
>
> so you can modify the current list element in that case. However,
> any time you specify the arguments, they default to read only.
OK, so explicit params are const, and implicit $_ is rw.
There's another type of implicit arg: placeholders. is $^a "const", or "rw",
by default? is there any way to control it?
Is $_ always rw, or only rw when there are no args. I.e.
for @a -> $a {
$a ++; # error: $a is const
$_++;# increments $a, because $_ is implicitly bound to the same elem
as $a?
$^a++; # Can we mix placeholders with explicit args? Is this also bound
to $a's element?
}
Dave.
Re: [perl #31138] [TODO] Configure - dependencies fix
At 10:12 AM -0400 8/20/04, Matt Fowles wrote: Dan~ Just a few small questions about scons to clarify... On Fri, 20 Aug 2004 09:16:24 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote: Whatever we use is fine as long as: a) We can edit the dependency file without having to know the language the tool's written in I believe that scons will be able to automatically determine dependencies for most of what we do and what little we don't can be specified with little enough syntax that actual knowledge of the syntax is irrelevant. Heh. I think you may underestimate the amount of preprocessing we do. :) Still, good enough. > b) the tool can be convinced to scan the entire tree at startup and build a rebuild script that doesn't need the tool itself it can be told to output what commands it would issue (to stdout) but not issue them. This output could be captured into a shell script of some such. Is it clever enough to do cross-platform stuff? That is, can I run it on OS X and have it spit out a DOS batch file? (Not that this is a showstopper or anything, but it'd be really useful for cross-platform stuff and maintenance of the distribution) > c) It's a language we can guarantee we've got available (which means either C or a language that compiles to parrot bytecode) It is entirely in Python, thus while we do not yet have it compiling down to Parrot, conceptually it could... I realize that none of those were questions, so here is the question. Given those answers to your requirements, would such a build system likely be accepted or would I be wasting effort? Given that it sounds like it meets the criteria, I think it'd be fine. The only hitch I could see is if it uses C modules for python, which'd make generating pure bytecode for it tough. We could look at fixing that, though. (It'd be interesting if scons could be completely handled by the bytecode translator. A useful test) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Synopsis 4 draft 1
On Thu, Aug 19, 2004 at 07:45:37PM -0700, Larry Wall wrote:
> BEGIN {...}*at compile time, ASAP
> CHECK {...}*at compile time, ALAP
>INIT {...}*at run time, ASAP
> END {...} at run time, ALAP
> FIRST {...}*at first block entry time
> ENTER {...}*at every block entry time
> LEAVE {...} at every block exit time
>KEEP {...} at every successful block exit
>UNDO {...} at every unsuccessful block exit
>NEXT {...} at loop continuation time
Whither REDO {...} ? Or do we just manufacture that ourselves with
NEXT?
>LAST {...} at loop termination time
> PRE {...} assert precondition at every block entry
>POST {...} assert postcondition at every block exit
> CATCH {...} catch exceptions
> CONTROL {...} catch control exceptions
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Parrot experiences log
On Fri, 20 Aug 2004 14:56:25 +0100, Simon Wistow <[EMAIL PROTECTED]> wrote: > Interesting - I wrote Python::Serialise::Marshal in May last year to > snarf Mailman config files and I didn't realise it was so close to > Python bytecode. Mailman config files ARE python bytecode -- they're just python code that's been stored after compilation. > is it worth looking at combining the two or am I misinterpreting your > post? >From the looks of things, Python::Bytecode has the functionality you need, but not vice versa. The interfaces are a bit different, but they were designed for different purposes. -- matt
Character set and encoding translations
Since I need this, and need to get it done reasonably soon, I'm spec'ing out the syntax of the charset and encoding files. Since there's been no more complaint or discussion, I'm taking the encoding and charset APIs proposed as acceptable, with the caveat that my docs suck and are going to be patched up as discussed. (This'd be a good time to revisit them and comment :) I've added a charset/ directory back in. Charsets'll go in there. (I think Unicode and ASCII will be the first two that get done) I'm going to preprocess the charset and encoding files the same way we preprocess the pmc files. I'm looking at .charset and .encoding as the suffixes, with the same sort of "First it's C, then we get to the keyword, then it's processed" scheme building up the charset and encoding vtables. I'm also going to add in charset.h and encoding.h headers to define the charset and encoding vtables. At some point I'll finally get to teaching string.c how to use the new stuff rather than diving directly into ICU, and then we'll see where we go from there. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #31138] [TODO] Configure - dependencies fix
Dan~ Just a few small questions about scons to clarify... On Fri, 20 Aug 2004 09:16:24 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote: > Whatever we use is fine as long as: > > a) We can edit the dependency file without having to know the > language the tool's written in I believe that scons will be able to automatically determine dependencies for most of what we do and what little we don't can be specified with little enough syntax that actual knowledge of the syntax is irrelevant. > b) the tool can be convinced to scan the entire tree at startup and > build a rebuild script that doesn't need the tool itself it can be told to output what commands it would issue (to stdout) but not issue them. This output could be captured into a shell script of some such. > c) It's a language we can guarantee we've got available (which means > either C or a language that compiles to parrot bytecode) It is entirely in Python, thus while we do not yet have it compiling down to Parrot, conceptually it could... I realize that none of those were questions, so here is the question. Given those answers to your requirements, would such a build system likely be accepted or would I be wasting effort? Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -???
Re: [perl #31229] [PATCH] Missed pod nit in build_tools/c2str.pl
At 4:16 PM -0700 8/18/04, Will Coleda (via RT) wrote: # New Ticket Created by Will Coleda # Please include the string: [perl #31229] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=31229 > Index: build_tools/c2str.pl Applied, thanks. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot experiences log
On Fri, Aug 20, 2004 at 08:38:21AM -0400, Matt Diephouse said:
> That's me. I don't think I ever announced this to the list though. Any
> newbie lurkers can check it out: http://matt.diephouse.com/parrot
"The rest of the bytecode is made up of objects. Objects are preceeded
by a char denoting their type. 'c', for instance, denotes a code object,
'(' a tuple, 's' a string, and so forth (you can look at the
Python::Bytecode source or at Python/marshal.c in the python source for
more types).
Interesting - I wrote Python::Serialise::Marshal in May last year to
snarf Mailman config files and I didn't realise it was so close to
Python bytecode.
is it worth looking at combining the two or am I misinterpreting your
post?
Re: [perl #31209] nci_test.o needs compiling with position independant code
At 4:03 PM +0200 8/17/04, Bernhard Schmalhofer wrote: currently I'm looking into 'libtool' for turning 'libsyck.a' into a shared library. This brings me to the idea, wether it would it be an option to use 'libtool' for library building stuff within parrot. 'libtool' from the commandline seems to have unexpectedly little cruftiness. However I don't know about Win32 support. Or support for other unices, or non-unix systems. :( This'll have to be done manually, unfortunately. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #31197] literal.t
At 3:10 PM -0700 8/16/04, Danny Werner (via RT) wrote: # New Ticket Created by Danny Werner # Please include the string: [perl #31197] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=31197 > Hi bugtracker, Examples from the 2th aoudad book (page 127) did not turn out as expected. Being completely new to this, I did not know where to put the testcode. It'll go in as t/op/literal.t. Oddly, parrot currently doesn't like this. Throws an error: use Parrot::Test tests => 1; output_is(<<'CODE', <<'OUTPUT', "integer literals"); print 0x2A print "\n" print 0X2A on this line. Leo, any reason to be case sensitive on this stuff you can think of? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[PATCH] Re: [perl #31128] Infinite loop in key_string
At 10:10 AM -0700 8/17/04, Steve Fink wrote: Still, I won't commit this patch directly, because I have only recently delved into the latest incarnation of the keyed code, and it scares me. Well, I will. :) It's in, with the test. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #31138] [TODO] Configure - dependencies fix
At 8:29 AM -0700 8/18/04, Dave Whipp wrote: "Leopold Toetsch" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Rather not. Python is AFAIK not as portable as Perl. But there is a Perl based make somewhere, the named just escaped my mind. We use Makepp (http://makepp.sourceforge.net/) here. Written in Perl, its particular strength is how it avoids recursive make (and thus lets us get the dependencies right). Whatever we use is fine as long as: a) We can edit the dependency file without having to know the language the tool's written in b) the tool can be convinced to scan the entire tree at startup and build a rebuild script that doesn't need the tool itself c) It's a language we can guarantee we've got available (which means either C or a language that compiles to parrot bytecode) I'd prefer the tool to be in a language I'm comfortable with, but if the tool works and is stable I'm easy here. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: incremental garbage collection 2/2
Leo~ Nice summary of the issues, but I have a few nits to pick On Fri, 20 Aug 2004 10:29:28 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > a) The mark phase of the garbage collection creates the graph of *all* > life (reachable) objects[1]. > b) Freezing a PMC creates the graph of reachables from that PMC on (e.g. > all array items, and subitems if an item is another array...) > c) The graph of objects created during b) is a subgraph of a), *if* both > schemes either use depth-first or breadth-first. I think that (c) may not be correct. As a breadth first search of (a) would interject random stuff into the tree that (b) would not. Consider: A refs B,C; B refs D, E; C refs F; D refs G BFS using root of A for (a): A > B > C > D > E > F > G Where as a BFS for Freezing B for (b): B > D > E > G Also consider: : A refs B,C; B refs D, E; C refs F; D refs G; E refs A BFS using root of A for (a): A > B > C > D > E > F > G Where as a BFS for Freezing B for (b): B > D > E > G > A > C > F Thus I don't think that BFS works. Now lets consider DFS of both sets. A refs C,B; B refs D, E; C refs E; D refs G; E refs A DFS using root of A for (a): A > C > E > B > D > G DFS for freezing B for (b): B > D > G > E > A > C It has occurred to me that you might mean the implicit graph of all objects rather than the explicit linked list of objects that (a) and (b) create. I believe that the graph of objects reachable from a node is a subgraph of the complete graph of object; however, I do not believe that the spanning trees of each created by DFS and BFS are subgraphs of eachother. Hope that made sense, Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -???
Re: Updates to modules-related pod
Randal L. Schwartz wrote: Rafael writes: BTW, isn't the habit to post to c.l.p.announce a bit deprecated now ? Not at all. More people should do it. Don't remove it. Either that, or entertain a proposal to cancel the group. Which of these are still alive and kicking? perl.64bit perl.advocacy perl.agents perl.ai perl.beginners perl.beginners.cgi perl.books.workers perl.bootstrap perl.bugmongers perl.combust.users perl.committers.parrot perl.copenhagen perl.cpan.cluster perl.cpan.discuss perl.cpan.interface perl.cpan.metadata perl.cpan.mirrors perl.cpan.stats perl.cpan.testers perl.cpan.workers perl.crypto perl.cvs.mod_parrot perl.cvs.p5ee perl.cvs.parrot perl.cvs.pdp perl.cvs.perlfaq perl.cvs.qpsmtpd perl.daily-build perl.daily-build.reports perl.daily.news perl.datetime perl.dbd.oracle.changes perl.dbdi.dev perl.dbi.announce perl.dbi.changes perl.dbi.dev perl.dbi.oracle-oci perl.dbi.users perl.debugger perl.dist perl.documentation perl.finance.bank perl.foundation.newsletter perl.fwp perl.golf perl.gov perl.i18n perl.inline perl.ithreads perl.javascript perl.jobs perl.jobs.discuss perl.jpl perl.ldap perl.libnet perl.libwww perl.loop perl.mac.toolbox perl.macosx perl.macperl perl.macperl.announce perl.macperl.anyperl perl.macperl.forum perl.macperl.modules perl.macperl.porters perl.macperl.scribes perl.macperl.toolbox perl.macperl.webcgi perl.makemaker perl.midi perl.module-authors perl.modules perl.mvs perl.nordic.workshop perl.ok perl.p5ee perl.packrats perl.par perl.perl1.porters perl.perl4lib perl.perl5.build perl.perl5.changes perl.perl5.changes.mac perl.perl5.porters perl.perl5.summary perl.perl6.announce perl.perl6.announce.rfc perl.perl6.build perl.perl6.documentation perl.perl6.internals perl.perl6.internals.api.embed perl.perl6.internals.api.parser perl.perl6.internals.bignum perl.perl6.internals.unicode perl.perl6.language perl.perl6.language.data perl.perl6.language.datetime perl.perl6.language.errors perl.perl6.language.flow perl.perl6.language.io perl.perl6.language.mlc perl.perl6.language.objects perl.perl6.language.regex perl.perl6.language.strict perl.perl6.language.subs perl.perl6.licenses perl.perl6.meta perl.perl6.porters perl.perl6.source.control perl.perl6.stdlib perl.perlfaq.workers perl.perlpoint perl.pod-people perl.poe perl.ponie.changes perl.ponie.dev perl.ppt perl.qa perl.qa.cvs perl.qa.metrics perl.qpsmtpd perl.recdescent perl.release-announce perl.riscos perl.rtos perl.scripts perl.sdk perl.sdl.devel perl.test perl.tips perl.tpf.discuss perl.trainers perl.unicode perl.vmsperl perl.xs
Re: Parrot experiences log
On Fri, 20 Aug 2004 00:05:10 -0700, Steve Fink <[EMAIL PROTECTED]> wrote: > I know someone else was blogging his initial experiences > slogging through the Parrot source -- that's where I got the idea, > though I'm not exactly a newbie around here so I'll be assuming a bit > more familiarity with things. (Though I'm pretty out of touch right > now, so maybe not...) That's me. I don't think I ever announced this to the list though. Any newbie lurkers can check it out: http://matt.diephouse.com/parrot It's a little slow coming, as it takes a while to write articles, but it may be useful to some people. And there are RSS/Atom/RDF feeds for those who are interested. -- matt
Re: Synopsis 2 draft 1 -- each and every
On 8/19/04, [EMAIL PROTECTED] (Larry Wall) wrote: >It's hard to come up with an English word that means "next" in scalar >context but "all" in list context. I never know whether to name my arrays singular or plural, either. =) But couldn't there be Two Ways To Do It? One "singular" name and one "plural" that do exactly the same thing -- use whichever one sounds better in any given context. >So I lean toward punctuation, and since <> is historical, I like ><$IN> and $IN.<> for that. [...] Arguably .keys, .values, .pairs, >and .kv should all autoiterate in scalar context, which should >replace .each entirely. @array should respond to .pairs and .kv, >pretending the implicit array indexes are hash keys. Which reminds me that an object can have multiple iterators, that do different things. (Though there might always be a "default" iterator -- the one that "for" would use.) So that's another reason not to mandate iterator names at all; <> could still be the socially conventional name for iterators (or maybe it would only be used by filehandles, depending on what else we might use <> for). >It looks like most of the problem is that we're not consistent in >how to destructively read something in a context sensitive manner. >And I don't really like .read anyway. Without necessarily >deprecating .shift or .splice, how about a table that looks like >this: [.pull's and .value's] I like the idea of being able to distinguish destructive from non-d. behaviour when I need to. But a lot of the time I don't care -- I wouldn't want to have to specify whether I'm pulling or value-ing in every "for" loop. So we'd still need something like <> (that presumably defaults to the least destructive iterator available). - David "does like 'pull' as a good generic name" Green
Re: Synopsis 2 draft 1 -- each and every
On 8/19/04, [EMAIL PROTECTED] (Luke Palmer) wrote: >David Green writes: > > Hang on -- should we be saying "for each $foo" or "for $foo.each" > > anyway? We don't say "for @foo.each"; the iteration is implicit. So > > I'm thinking it should be "for $foo" or "while next $foo". > >Well, C gives you a one-iteration loop. Oops, I meant $foo to be some iterable object... but yes, that conflicts with referring to the object itself (such as a plain scalar... although I guess anything without an explicit iterator method could simply "iterate" by returning itself once). But I was confusing myself there anyway. I was thinking that "for" would somehow have to call the iterator implicitly because if the iterating method just returned the next value in scalar context and all values in list context, then "for $object" would pull everything (all the $object-s flattened) instead of pulling each subsequent $object one at a time (i.e. lazily). Then I thought that maybe "for" doesn't need to work lazily (except that the conveniently just-posted Synopsis 4 confirms that it is supposed to be lazy). Or maybe "for" is only "as lazy as is reasonable", meaning if it knows how (e.g. if you're using an array or filehandle, which have known ways to meander through lazily), or if you write a really fancy iterator for your object that can handle laziness. If your iterator (in list context) just returns everything at once, then "for" will effectively flatten the list because there's nothing else it can do. (If you need one-at-a-time behaviour, use a while loop!) Hm... but it still seems it would be good if "for" could know what the iterator method is for any given object, so that it could call the (single) iterator one at a time and get through any sequence as lazily as possible. >Which implies that iterators can behave as arrays. Then you get to >weird questions like what: >$foo[-1] >Does. Iterate to the end and return that? The array abstraction >doesn't work well for iterators, so perhaps that's not the best way to >go. Yeah... my instinct would be that if you want that much array-like behaviour, then tie your object to or inherit it from an Array. >I'm personally a fan of "every" as well as renaming Ruby's "each" to >something else. I was also warming up to "sequel", but it's kind of long to type. OK, using "next" is a problem because of things like: $foo='LINE'; next $foo; but what if labels had to be stored in special "label objects" instead of plain strings? Well, that could still cause problems if you ever wanted to iterate over some label names, I guess. (Don't ask me why you'd want to do that...) Anyway, now that everything's a closure, isn't labelling a block a lot like naming the block/closure/sub? (Probably not... =P) Hm -- you can also label a statement on its own... I forgot about that because I don't think I've ever actually seen Perl code that does that. (You can't 'next' to a statement anyway, only to a labelled block.) - David "starting to confuse myself again" Green
Re: Synopsis 4 draft 1
Larry Wall wrote: =head1 Title Synopsis 4: a Summary of Apocalypse 4 A little light reading is always good in the morning ;-) To return a value from a pointy sub or bare closure, you either just mention the value last that you want to return, or you can use C. A C by default exits from the innermost block. But you may change the behavior of C with selector adverbs: leave :from(Loop) :label«LINE» <== 1,2,3; The innermost block matching the selection criteria will be exited. The return value, if any, must be passed as a list. To return pairs as part of the value, you can use a pipe: leave <== :foo:bar:baz(1) if $leaving; I know it's probably just me, but This section seems to suddenly rely on a lot more knowledge of the current state of Perl 6 syntax than I have. Can someone walk me through these two examples? What's a C<:from(Loop)>, for example, and how is C<:foo:bar:baz(1)> (what looks like a set of properties to me) related to pairing? Wouldn't that be: leave <== 'a'=>'x', 'b'=>'y', 'c'=>'z' if $leaving ? Thanks
incremental garbage collection 2/2
3) Incremental collection interfers badly with freeze & thaw, at least
if freeze uses the next_for_GC pointer to keep track of duplicates.
OTOH both freezing and creating the graph of live objects during DOD are
basically the same. The problem currently is that chaining objects
together is done independently and on demand, with the complication that
incremental's chain creation is done in the "background".
Well, here is an idea:
Prelims:
a) The mark phase of the garbage collection creates the graph of *all*
life (reachable) objects[1].
b) Freezing a PMC creates the graph of reachables from that PMC on (e.g.
all array items, and subitems if an item is another array...)
c) The graph of objects created during b) is a subgraph of a), *if* both
schemes either use depth-first or breadth-first.
Thus the basic idea now is: we just keep that graph (that hangs off the
next_for_GC pointer). Freezing then just means: walk that graph and spit
out tokens (object ids and other stuff like values) and be done with it.
A serializable continuation is the same as freezing the interpreter[2]
i.e. take the full object chain created in a) and freeze it. Easy.
The problem is of course the mutator: that is the user program that
permanently changes the graph of objects.
A small side-step: generational GC.
- A refcount GC system is doing work proportional O(w+d), w being the
normal mutator work and d are dead objects.
- A marking scheme has O(live) or O(live+dead). With sweep the latter is
true.
To reduce GC overhead, we have to skip some objects. E.g. at program
start you create some big arrays (or hashes) and these objects are more
or less unchanged. Mark has to go through these objects item per item on
every single DOD run. That's really time consuming.
The idea of generational GC is now: put such objects into an old
generation and just skip this generation. So the overall work can
decrease by a huge amount. This is based on the "weak generational
hypothesis", which asserts that most objects die early.
When we keep the chain of objects for freezing, we can as well set a bit
in the aggregate header ("old_generation") and skip the whole chain of
objects that belongs to that aggregate during marking.
Back to the mutator:
Incremental GC needs write barriers[3]. Whenever a white object is
stored into a black[4] one, the write barrier notifies the garbage
collector to update its object graph. The collector can either rescan
the aggregate or mark the new (white) object.
Generational GC needs a write barrier too, to track inter-generational
store operations. That's basically the same as above, when we just have
two generations as most of these schemes have.
I think it should be doable to keep the graph of objects accurate most
of the time. Instead of rebuilding the graph in each DOD cycle, we
should be able to reuse the graph of the old generation and rebuild
parts of the graph only after changes triggered by the write barrier.
Comments welcome,
leo
[1] buffer headers may be different or not
[2] modulo some bits of meta tokens ("I'm a stack frame ...")
[3] I don't consider read barriers, doable but too expensive.
[4] WRT object colors: perldoc -F src/gc_ims.c and:
[5] Real-Time Non-Copying Garbage Collection, Paul R. Wilson and Mark S.
Johnstone
Re: Synopsis 4 draft 1
Larry Wall <[EMAIL PROTECTED]> wrote:
> Final blocks on statement-level constructs always imply semicolon
> precedence afterwards regardless of the position of the closing curly.
> Statement-level constructs are distinguished in the grammar by being
> declared in the statement syntactic group:
>
> macro statement:if ($expr, &ifblock) {...}
> macro statement:while ($expr, &whileblock) {...}
> macro statement:BEGIN (&beginblock) {...}
And he answers another "but how do we..." question with a simultaneous
[unific|simplific|generaliz]ation. Larry, you're a genius.
--
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
There is no cabal.
Re: Synopsis 2 draft 1 -- each and every
On Thu, 2004-08-19 at 12:17 -0400, Matt Diephouse wrote:
> At this point, you may as well use C<.records> (think C<$/> -- record
> separator):
>
>for $foo.records { ... }
>
> Then it'd be a small step to allow:
>
>for $foo.records :sep"," { ... }
> --or--
>for $foo.records(",") { ... }
>
I'm not particular to any of the verbs used yet, but maybe that's
because I don't think of the <> as a general iterator, but more of a
gobbler-type creature (and formerly a globber, too). Could we try:
for $foo.fetch { ... } #or
for $foo.grab { ... } #or
for $foo.eat { ... }
And to replace $/ we could have something like:
for $foo.fetch :upto(",") { ... } #or
for $foo.fetch :until(",") { ... }
P.
Re: Updates to modules-related pod
> "Rafael" == Rafael Garcia-Suarez <[EMAIL PROTECTED]> writes: Rafael> BTW, isn't the habit to post to c.l.p.announce a bit deprecated now ? Not at all. More people should do it. Don't remove it. Either that, or entertain a proposal to cancel the group. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Return with no expression
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19 Aug 2004, at 18:04, Luke Palmer wrote: The one in Perl 5 that stands out most was the cause for the only patch I ever sent to p5p: the rand function. "rand $x" will give you a uniformly distributed random number in [0, $x) for any $x EXCEPT 0. If you say "rand 0", it gives you a random number between 0 and 1, which was supposed to be What I Meant. That led to code like this (Perl6ized as usual): my $num = $param == 0 ?? 0 : rand $param; my $num = $param == 0 ?? 0 :: rand $param; surely? Repeating the test that it did itself, just to get consistent behavior. We must be careful not to repeat mistakes like this in the design of Perl 6 [1]. It would be nice if rand behaved a bit more sanely in Perl 6. I can understand the reasoning for making rand 0 produce between 0 and 1, but that doesn't mean I have to like it. If that behaviour is required, then rand undef; would behave as expected (call with no parameters to get [0, 1), with one param to get [0, $param) ), but really if you want a random number between 0 and 1 why aren't you calling rand 1? Feels like a Cism. Ick. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBJbRx0UvYjCBpIlARAjV2AJ0TSuchOHcVMqg3HUPLJ6G5zhnRYwCfQ/26 C6DCRHq0BjxqX4eH5vUeWwk= =ctmb -END PGP SIGNATURE-
Parrot experiences log
As I prepared to dive into a big area of parrot that I'm completely unfamiliar with, I decided to log my travels in hopes of helping out the next poor soul who happens along a similar path. For now, the focus is on converting my toy languages/regex compiler into more of a real Perl6-style rule compiler callable directly by Parrot. I know someone else was blogging his initial experiences slogging through the Parrot source -- that's where I got the idea, though I'm not exactly a newbie around here so I'll be assuming a bit more familiarity with things. (Though I'm pretty out of touch right now, so maybe not...) Oh, right, the url: http://0xdeadbeef.net/wiki/FinkBlog At least for now. That's my server, and my DSL line is flaky, but I wanted to do the minimal amount of setup, and I'm familiar with this particular wiki syntax. And I expect to get bored of writing stuff up before reaching the point at which moving would be worthwhile. Yes, I'm aware of the wiki at http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/WebHome but I couldn't find an appropriate place to put this there. Also, I wanted something I can get to while off-line, and something I can molest more easily to make writing the log easier. I've modified my wiki a fair amount, and have gotten dependent on some of the shortcuts.
