[OT] joining list, test message, delete with impunity :)
Hello all. I'm here mostly as a lurker to keep up with the evolving structure of p6, but will try to contribute something useful when I can. Good to be aboard. Paul __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: Multiple Inheritance eq Interfaces [was: Re: Object spec]
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 5:02 AM +1300 3/6/03, Sam Vilain wrote:
> > *{$_} = \&{"Class::$_"} foreach (qw(method method2 method3));
> > Gives you everything that inheriting a class does, apart from the
> > ->isa() relationship. And potential unwanted namespace pollution.
>
> It's probably time to note that, when I started the discussion, it
> was on perl6-internals, and all I was interested in was nailing down
> needed semantics. What you've started talking about is perl 6
> *language* syntax and such. I'm not sure Larry's ready to start that
> yet.
That explains why it was starting to feel a little "drifty".
Next topic? :)
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
Re: Object spec
--- Sam Vilain <[EMAIL PROTECTED]> wrote: > What I'm saying is that it should be possible to `filter' which > methods you inherit via @ISA. Ideally there would be some standard > way for a module to describe groups of methods for other classes to > import a la Exporter's %EXPORT_TAGS. > The result would allow both Multiple Inheritance *and* Interfaces. Are you speaking in terms of limitation, or requirement? It would be nice to have a syntax solution. I've seen p5 interfaces with stubs that die so that you have to override them in a subclass. It works, but seems a little kludgy. And I'm coming in late on this. Are you saying you want Exporter/%EXPORT_TAGS functionality built into the language and into all objects? Wouldn't that jack up the overhead? Is that what you mean by "associations", below? It seems like a pretty generic word. > In my experience classes only have *is a* relationships with one > other class. The other classes they inherit are *can behave like a* > relationships. MI should be frowned upon where Interfaces will not > do IMHO. But that is a flamewar topic :-). lol -- probably. :) But did you say that right? "MI should be frowned upon where Interfaces will not do"? Or are you using interfaces as a form of MI? I tend to think of them (inaccurately, I suppose) as "not really inheriting", but just defining requirements. Java pollution, probably. ;o] But I think it is generally frowned upon, while not being officially _bad_. We musn't dictate style. I prefer delegation, and making better ways available discourages the effectively deprecated methodology, but sometimes one needs to use what one knows and get the job done. As much as I dislike it, I have to admit that there are times to apply the adage "if a jobs worth doing, it's worth doing poorly." Then again, there are folk who will argue that MI isn't doing it poorly. For some problems, it might be the most elegant solution, even if interfaces won't handle the situation. An interface really *isn't* a true inheritance, after all -- so there must be a reason there's a difference. :o} > Associations are grouping two classes together. Or more, in the > general case, but this is not required as three way associations > can be broken down into an `association class' with three or more > two way associations. Sounds like MI. > It is a simple concept. You use them all the time, whether you call > them associations or not. When I first started recognising them after > I started to learn UML, programming felt like cooking with Garlic for > the first time. LOL!! (My ex and I once made 40-garlic Chicken Felice. Our classrooms *reeked* the next day, and the students were dying, but it took me all day to figure out why they were SO miserable, and I couldn't smell anything at all!! :) > Leave them out to carry on with the status quo of a myriad of subtly > different, non-interchangable approaches to associating classes. TMTOWTDI? Still, though your point is valid if I understand it, it will always be possible to create "non-interchangable approaches", and we don't want to dictate methods if we can help it. I think I need an exampleunfortunately I'm at work and haven't the time to properly peruse the one you offered. Thus I must apologize, and wait for more input. Paul __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: Object spec [OT?]
--- [EMAIL PROTECTED] wrote:
> > Are you speaking in terms of limitation, or requirement?
> > It would be nice to have a syntax solution. I've seen p5 interfaces
> > with stubs that die so that you have to override them in a
> > subclass. It works, but seems a little kludgy.
>
> Back in 1988 programming Objective-C under NeXTSTEP you could have a
> class that does these things (based on methods inherited from
> Object):
> - iJustCantSeemToGetAnythingDone {
> [self notImplemented:_cmd]; // TODO: We'd better write this soon!
> }
> - imFeelingAbstract {
> [self subclassResponsibility:_cmd];
> }
> - bogus {
> [self error:"Bogon flux exceeds limit %d\n", BOGON_LIMIT];
> }
As in the p5 equivs (???):
sub iJustCantSeemToGetAnythingDone {
shift->notImplemented(@_); # better write this soon!
}
sub imFeelingAbstract {
shift->{subclassResponsibility}->(@_);
}
sub bogus {
dir sprintf "Bogon flux exceeds limit %d\n", BOGON_LIMIT;
}
or am I completely off base?
(never done Objective-C under NeXTSTEP).
I think I may have missed the point.
Sorry, feeling dense. :)
> Also, there was a doesNotRecognize: method that was called by the
> runtime system when method lookup failed. I presume you could
override
> it to do nasty things, but I never did that myself.
AUTOLOAD()? Oh, I *have* done nasty things with that, that I don't even
like to talk about
Mostly, though, I just use it to fake up quick templated accessors.
If I know there are forty fields on an object that are all going to
look exactly alike, I'll stick a build-on-the-fly routine in AUTOLOAD
so that if one gets called it has a legitimate accessor the next time.
That way I only have to write one reasonably abstracted routine, rather
than the forty cut-paste-edit versions I've seen folk actually do in
this shop
"Hey, it was quick and easy"
Ugh.
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
Re: Multiple Inheritance eq Interfaces [was: Re: Object spec]
> > And I'm coming in late on this. Are you saying you want
> > Exporter/%EXPORT_TAGS functionality built into the language and
> > into all objects? Wouldn't that jack up the overhead?
>
> No. All I'm saying is that this sort of construct:
>
>*{$_} = \&{"Class::$_"} foreach (qw(method method2 method3));
>
> Gives you everything that inheriting a class does, apart from the
> ->isa() relationship. And potential unwanted namespace pollution.
Isn't that potential namespace pollution anyway?
You should obviously pay attention to what you're importing
Even now, you can explicitly
use Class ();
to import nothing, right?
> I'm thinking along the lines of;
>
> use base MyActualObjectSuperClass;
> use base XML::Sablotron::DOM => [ "Core" ];
>
> So your class ->isa("MyActualObjectSuperClass"), but ->can() all of
> the Core DOM methods, which could perhaps be tested for as
> ->mimics("XML::Sablotron::DOM", "Core"), but also as
> ->isa("XML::Sablotron::DOM") for compatibility.
Ok, forgive me. I see what you're saying, but I'm lost as to why.
As I said before, I'm feeling really dense today.
> > We musn't dictate style.
>
> No, but we should emanate good style. And I consider opening two
> class' namespaces into the same stash to be very bad style.
True enough.
("emanate"? maybe "promote".)
> Whenever I've seen Multiple Inheritance used, it has been because the
> two classes inherited are not similar; and you're just doing it to
> save yourself the hassle of splitting it into a ``servant class''
(ie,
> referring to another object & forwarding methods to it). To
> re-iterate my point, an interface is a `more correct' representation
> of this relationship. So let's make the semantics of it easy so that
> people can avoid it more easily...
I don't know if I can 100% agree with your assumptions, but I do agree
with your suggestion. :) As I said before, I prefer delegation anyway.
> Brent says that `attribute slots in a Parrot object are private to
> the object', so if you really do inherit from two classes, it should
> be the case that one class cannot access the other class' attributes.
Makes sense.
> But - if the child class accesses an attribute which is defined in
> both classes, which does it get? I think that case (MI two classes
> with clashing symbols) should be a hard run-time error.
Ah. P5 does a [EMAIL PROTECTED] search, right?
But that might not be what you want, particularly if you say
@ISA = qw / X Y /;
and you want X's foo() method but Y's bar(). If both have a foo() *and*
a bar(), you couldn't disambiguate with the order of @ISA anymore. It's
probably a rare case, but it will happen. You're right -- no clean
solution comes easily to mind. All that pops up atthe moment is
hardcoding hackery, in fact, but as I said, I'm dense today, lol
> If attributes are declared explicitly, then this enables this test.
> In Perl 5, the approach taken with MI namespace clashes is to cross
> one's fingers ;).
lol, yeah I guess so.
So how would you write code in your proposed solution to solve the
above example case?
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
Re: Object spec
--- Andy Wardley <[EMAIL PROTECTED]> wrote: > Associations *are* fundamental things, but I don't think they are > part of an object. They describe relationships between objects and > should exist independantly and orthogonal to them. Agreed. Is there any reason that shouldb't be done with something like use Associasions; associate( $foo => $bar, @opts ); # opts defining association type I see no real desperate need for that to be an integrally linguistic mechanism, tho perhaps I'm being dense again. Seems to me a module could do all that was needed, in p5 and/or p6. > Dave Whipp wrote: > > An association is a mechanism that permits one object to navgigate > > to another. If the association is bidirectional, then it is possible > > to also navigate from the target back to the source. Each direction > > of navigation should be given a unique identifer. Easy enough for a module to keep and internal doubly-linked list of objects that describe the relationships of things it has been told to attend. > There are many different kinds of morphisms: epimorphisms (one-to-), > monomorphisms (-to-one), isomorphisms (one-to-one), polymorphisms > (-to-many) and so on. In category theory, morphisms are dual, > so that for each relationship represented by an arrow between two > objects, there is a reciprocal relationship travelling back down the > arrow in the opposite direction. So the relation object for any given registered object could have subtrees that identify all these. It seems simple. Am I missing something? > If you want to make it an ordered set, then you need to add another > morphism, 'before' (and its dual morphism 'after') which tells you > which of any two elements in a set is ordered before the other. Sensible, and still reasonably easy to implement > I think it is better to assume that there is no such thing as an > inconsistent morphism. If the shoe doesn't fit, then don't wear it! > Find another shoe or go barefoot. :-) hmm... maybe not. Inheritance is an assosiation of sorts, isn't it? (please don't let that open another can of worms, lol...) But the child object knows it's parent, and can inherit methods and atributes, while the parent can know nothing about it's child in standard OOP structure. That's an inconsistent assosiation, isn't it? I only mention it because, though I can't really think of a good example of when it would be needed, I'd hate to say you can't *have* one, just because Easier to code and maintain for flexibility from the start. :) > Associations are no more part of an object than an electric > current is part of an electron. The field is defined by the > interaction between fundamental particles but is not an inherent > part of the particles themselves (wave/particle duality and other > quantum mechanical chicanery aside). But I *LIKE* quantum mechanical chicanery! >:O} Still, I concur. The object shouldn't need to know or care who else "owns" it. My coffee cup doesn't. But if the program needs to identify whose coffee cup it is, there should be a way. The Cup object shouldn't be required to have an owner attribute dictated by a theoretical Association system in the language. Many applications, most, I'd say, won't need it, and I'd rather skip the overhead. If I need it, I'll pull in the necessary module and set up the relationships as required. Now it *would* be nice if the Association module could help shortcut that and provide some syntactic sweetener, but for that I don't even mind if it's Aspartame. ;o] > If instead we borrow the conceptual model from category theory and > provide a mechanism for defining elements and relations *separately*, > then it should be possible to build all kinds of fancy information > spaces with any number of different inter-element relationships > defined. I must admit I like this idea -- it's *feels* elegant, but I have no idea off the top of my head how you would *use* it. Can you give me an implementation example, in theoretical code? > Anyway, the gist of this long rambling post is that In My Humble > Opinion, if Perl 6 is to provide the ability to define associations > between objects, then it should do so as part of a larger category > mechanism rather than as an extension to the class/object mechanism. Maybe. I'm almost convinced, but I need to see more concrete examples. __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: Statement modifiers
> I made a mistake in my original post, they definitely need to be > left-associative. Your example should obviously be interpreted as: > > (.method given $x) given $y; # calls $x.method ok. > I think this is similar to how I mentioned that a duplicate 'for' is > pointless. Just because pointless modifier combinations exist > doesn't mean multiple modifiers in general are a problem. Agreed. But is it worth putting them in if they would make a problem so easily, and it can be so easily handled with blocks? > since 'if' has a lower precedence than '=', this is: > ($x = $y) if $z; > or equivalently > $z and ($x = $y) duh. ok. > > print if $x if $y; # ?? > > > >Are you saying "test $y, and if it's true, test $x, and if it's true > >then print"? > > Yes ok, but wouldn't it be clearer to say print if $y and $x; # ? > It means the left side is not always evaluated; that's > short-circuiting and has nothing to do with precedence. > Notice how in perl 5 the 'or' operator is in the lowest > precedence class, but certainly short-circuits (think "foo or die") But that's easier on the brain, becausewe read left-to-right, and it short-circuits left-to-right. "z() if $x if $y" doesn't. > > print "$x,$y\n" for $x -> @x for $y -> @y; # is that approximate? > > Syntax error. The -> operator doesn't make sense without a block. > See http://www.perl.com/pub/a/2002/10/30/topic.html But if() currently takes a block unless it's postfix. I was just extrapolating, though as I said, I'd hate to try and write the parser. > > print for @x for @y; # @y's topic masked > >would probably make no sense unless ... > > Note that I actually *said* it makes no sense. I have to admit that > if the conditionals (if, unless, when) would be operators, I'd have > trouble to think of a situation where multiple modifiers are useful > at all; which I why I said making the conditionals infix-operators > would probably suffice. I was just agreeing there. :) > Then again, I just thought up (perl 5 style): > >print for split while <>; > > but I have to admit I can probably live without the ability to write > something like that ;-) Dittobut I have *wanted* to do something vaguely like that on *several* occasions! More often it is conditionals, though. I'll leave it to better minds, and use whatever they give me. ;o] __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
A6 page 6 formatting problem
Just in case anyone cares, page 6 is requiring that I scroll horizontally. I'll live, but if it can be easily fixed, that's a Good Thing. :) Haven't read the rest yet -- still working on it. Paul --- Damian Conway <[EMAIL PROTECTED]> wrote: > Like the fully-laden Australian swallow that heralds the first > Apocalypse of > springtime, I'm back. > > I hope you're all off reading: > > http://www.perl.com/pub/a/2003/03/07/apocalypse6.html > > Special thanks to Simon for getting it on-line as quickly as he did. > > I'll do my best to answer questions about it and respond to other > comments, > but I still only have the tuits to read specifically A6-related > messages. So > it would help me enormously if people could include something > matching the > pattern: > >m:wi/A[pocalypse ]?6/ > > in the subject line of any message they'd like me to read and respond > to. > > In other words, I'll be reading this list again, eagerly gathering > grist for > the forthcoming exegetical mill, but in self defence I'll be > pre-filtering > only for A6-related subjects. > > Thanks, > > Damian > __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: Statement modifiers
--- Matthijs van Duin <[EMAIL PROTECTED]> wrote:
> Now the real subject.. has the issue of multiple statement modifiers
> already been settled? I saw some mention it wasn't going to be
> supported, but also mentions of how it would be useful; I can think
> of such a situation myself:
>
> .method when MyClass given $obj;
> as alternative to:
> $obj.method if $obj.isa(MyClass);
I think this is an unusually clear case, and even then has problems.
The real nightmare tends to show up when you duplicate a modifier.
What does
.method given $x given $y; # which object's .method is called?
mean? It gets worse below
> except without duplicating $obj, which may be worthwhile if it's a
> longer expression. If multiple modifiers are really a no-no, then
> I think at least the conditionals (if, unless, when) could be made
> lowest-precedence right-associative infix operators, and leave the
> status of "statement modifier" for loops and topicalizers.
lowest? why lowest? Careful with that If you make it a lowest
precedence operator,
$x = $y if $z; # = is higher precedence
Does it get assigned if $z is undefined?
> This would mean that the above would be valid, and also things like:
> .. if .. if .. for ..;
I may be missing something, but
print if $x if $y; # ??
Are you saying "test $y, and if it's true, test $x, and if it's true
then print"? I suppose that might workbut that still makes it high
priority, doesn't it?
> But that multiple nested loops would be illegal using modifiers and
> would require a real block. (which makes some sense, since it's hard
> to think of a construction where multiple loop-modifiers would be
> useful: if you have ... for @a for @b then you'd be unable to
> use the @b-element since $_ would be the loop var of the inner loop)
Maybe not in p6.
print "$x,$y\n" for $x -> @x for $y -> @y; # is that approximate?
Ok, this is hurting my head, and I think I might hurt someone who left
me to maintain it, but I could see how it could be useful, and I think
I see how it could be parsed It would be like
for $y -> @y {
for $x -> @x {
print "$x,$y\n";
}
}
My question is that, though TMTOWTDI is a Good Thing, and in general
dictating style is a Bad Thing, is this much flexibility a Good Thing
or a Bad Thing? And more importantly, will the people writing the
parser become homicidal if it is decided this should be implemented?
Still,
print for @x for @y; # @y's topic masked
would probably make no sense unless it's a rather twisted form of
recursion, and for that I'd recommend writing a function rather than
setting up reference loops
> I also think this gives a nice symmetry of various operators that
> only differ in L2R/R2L and precedence (plus the ability to overload
> ofcourse):
>
> $x and $y $y if $x
> $x or $y$y unless $x
> $x . $y $y <~ $x
> $x ( $y ) $y ~> $x
I have no idea what you mean by this.
Paul
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
Re: This week's Perl 6 Summary [OT]
--- Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Piers Cawley wrote: > > Coroutines end and DFG > > Nobody explained what DFG stands for. > > It's a commonly used TLA standing for Data Flow Graph, which > accompanies the CFG (Control Flow Graph). Both are necessary > for register allocation. > leo So what's a TLA? :) btw, great work Leo...in general! ;o] __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com
Re: A6: Signature zones and such
--- Brent Dax <[EMAIL PROTECTED]> wrote:
> method x ($me: $req, ?$opt, +$namedop, *%named, [EMAIL PROTECTED]) { ... }
>
> Yikes. And I thought we were trying to get *away* from line noise?
>
> Seriously, can't we use something rather prettier, like this?
>
> method x($me: $req, $opt is optional, $namedop is named,
> *%named, [EMAIL PROTECTED]) { ... }
I think the sigils are a good thing (note no caps), but that explicit
attributes like "is optional" and "is named" would be a Good Thing.
Accordingly, if the compiler could accept either and do the Right
Thing, that would be rather sweet. :)
__
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
Re: A6: Signature zones and such
> The problem is that if you have multiple optional or named
> parameters, things start getting uncomfortably prolix, and default
> values end up a long way from their owners:
>
> multi substr(Str $str, $from is optional = $CALLER::_,
> $len is optional = Inf, $new is optional) {...}
>
> vs:
>
> multi substr(Str $str, ?$from = $CALLER::_, ?$len = Inf, ?$new)
> {...}
What kind of wrench-in-the-works would this cause?
multi substr(Str $str, ($from = $CALLER::_) is optional,
($len = Inf) is optional, $new is optional) {...}
__
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
macro operators in A6 -- sweet.
So now putting C-style comments in p6 should be about as easy as
macro circumfix:/*...*/ () is parsed(/.*?/) { "" }
That's so easy I might even *use* it, lol
Not that I've ever really felt the need with # and =doc/=cut.
But just to make sure I'm getting it:
macro circumfix:... () is parsed(/.*?/) {
"\n# much ranting deleted here . . . .\n"
}
will actually work? :)
__
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
Re: A6: Signature zones and such
> I don't know that that means we couldn't have an C > spelling, though. And C (or something easier to spell) > for the * case. If we have C and C, I think > it would be appropriate to have names for the other linenoise as well. I'd say "please". > (Percentage of me that really cares: 20%. But I suspect others > might.) Percentage of me that really cares: ~65% Degree of concern in that portion : ~72% Importance of that portion as opposed to the 35% that couldn't find any interest: 10 to 1. Effective concern level: roughly 50/50 :) But I'd still say "please". __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com
A6 Type Inference
I apologize for not including a previous message thread -- I
fumble-fingered myself out of all the relevant ones
Still, I'd just like to cast my tiny vote regarding inferences.
I'd like to be able to write classes that can take advantage of
screaming speed, and types contribute.
I'd like to be able to tell my main script that it is required to pass
exact types, so that it gets those advantages. (I'd like something like
"use strict;" without specifying "strict what" to default to "strict
everything".)
I'd still like to be able to use my module in quick one-off's without
having it break and die if I just pass it whatever default variable I
can manage not to declare.
Wouldn't I be able to do that by writing my module with something like
multi foo (Int $i){...}
multi foo (Scalar $s) {...}
???
Yes, I realize most people don't want to write seven versions of every
sub; but most of the time, my module is either going to be generic
enough that I'm not really as interested in the screaming end of speed,
or specific enough that I don't expect to use it for many one-off's, or
worth a little extra code.
Still, as a best-case, I'd like for the strict()-ness of my main
program to drive the determinance. If it's a slopjob quickie, I don't
*CARE* about greatspeed. Just DWIM and gimme what I want. If I want
fast code it's worth being careful, so I'll use strict and expect it to
gripe and expire if I didn't do something quite right.
So, my vote is, do the run-time checking if not strict; restrict me to
compile-time compliance under the strict pragma.
To be honest, I'd also kinda like to see a coerce-it-if-you-can
behavior, but I'd rather have that as a pragma as well. If it's worth
all the extra work to find an appropriate coersion, it's worth a few
extra keystrokes. but I could live without all that quite happily.
Am I off base?
__
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
Re: A6: macro invocants
> The sugar I'm using here is to go from
>
>$db.do_sql("select * from Foo");
> to
>$db.select * from Foo;
Since we're fishing, call it a circumfix operator, something like
sql...execute.
Like this:
$db.sql select * from Foo;
execute;
__
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
Re: A6: Strict signature checking - was: Complex Parameter Types
> I don't see a problem. Scalar == Int|Num|Str|Ref, so
> Scalar.isa("Int").
Scalar.isa("Int") && Int.isa("Scalar")
__
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
Re: is static?
> > Doesn't C give you this? > > Not really. A variable declared with can be accessed from > anywhere in the program, just by redeclaring it or calling it with > the "package::" syntax.A variable declared with can be > accessed outside its scope only if the user returns a reference > to it. A static variable should be like a variable except > that it is only initialized once and is not destroyed when it goes > out of scope. Better to make it a my() with an accessor, and have everything use the accessor... but it *does* slow things down. __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com
survey page? [OT, was Re: is static?]
Merely for the one small thing I might possibly contribute Would it be useful to have a convenient place to do polls? I suspect there already is one somewhere, but I'm unaware of it. I don't want to undermine the authority of the core planning team, but thought they might like to have a simple way to survey for things that are more preference than major issue. I think all in all the correspondence on these issues has been pretty positive. I've seen a couple of people think about flames, and instead respond like adults. (It makes me happy. :) I was just wondering if it would be helpful if I set up a web page where the team could give me some alternatives to post, and folk could submit their preferences. I suspect that there are already plenty of ways to do that, and that my offer is weak, lol Personally, I prefer just hashing it out in the list. But it was a thought. Paul __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com
Re: is static?
> $a ??= $b :: $c; Are you serious? That's completely unnecessary, but so is $a ||= 1; I *LIKE* it!!! =o) __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com
Re: is static?
> sub foo() {
> env $s ??= 0;
> $s ++ ;
> }
Although I still prefer calling it a trait on the data, I must admit
that I like "env"...perhaps even better than "is retained".
Well, maybe not. But it's a cool thought that it's the "environment".
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
Re: A6 Request: Change .req to .arity
--- Steffen Mueller <[EMAIL PROTECTED]> wrote: > Damian Conway wrote: > > Larry wrote: > > > >> On the other hand, I could see an argument that said anyone who > >> doesn't know what .arity means shouldn't be writing routines that > >> depend on it... > > > That was more or less my line of thought. > > Now, I think I'll dare claim my English is not exactly bad for a 21 > year-old non-native speaker. Being a physics and CS student, I do > also have mathematical background, but it still took me a few seconds > to figure out "arity" *in this context*. Maybe that's because I can't > think of an exact German equivalent either; maybe it's because I don't > think a function's arity is quite the same as it's *minimum* number of > parameters? I mean, it makes sense in a functional language... but > you don't have functions with a variable number of arguments there. (Your English sounds pretty darned good to me. :) > To cut this short: I think req or reqargs or somesuch would be > better. Why choose the method names that sound more like computer > science for the very sake of that? FWIW, I'm a CS professional with an appalling lack of mathematical background (though I scored above the math average for Engineers on my GRE, and didn't miss any of the logic questions). I'd never *heard* of "arity", but tend to use esoteric language attributes rather often (which is not a boast -- it's a rather bad habit, but there it is). Anyway, I like writing functions and methods that DWIM, but sometimes WIM takes some doing. I'd rather have a name that means something to me, too though to be honest, "arity" would mean something to me, if someone would just explain it, lol Paul __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com
Re: Funding the design team
--- Miko O'Sullivan <[EMAIL PROTECTED]> wrote: > On Thu, 20 Mar 2003, David Storrs wrote: > > Folks, give us your address (or a PO box, or something), where we > > can send checks. The checks won't be tax deductible, but are we > > really doing this for the tax deduction? > > ... or a PayPal account. I've got $1.36 in my account ready to send > to the development team. Sorry, the Electronic Frontier Foundation > got the other $5 that was in that account this morning. This I can do. Gimme a paypal target. :) __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com
list manners question
Hi all. I note that quite often I find myself wanting to express agreement or disagreement with some point made on the list, but without anything of value to add other than a vote on the matter. When this happens I usually ~try~ to bite my metaphorical tongue and just file the information away while deleting the message, at least until I can contribute meaningfully. I wonder at times, however, if a simple vote of yea or nay might actually count for something here. I know Larry and the design team are lurking even when not interjecting, and I trust and admire their collective judgement on these matters, and know that they will consider all arguments, but that they will also consider opinions when there is no overriding and conclusive reason to decide a matter one way or the other. (Though I am damned *glad* that Larry is more interested in what's good for me than in what I *think* is good for me, lol) I was just wondering if the occasional "me, too" was appropriate if I feel strongly about something, but have nothing to actually *add* that hasn't already been said. I really hate to spam a productive list. Any input or comments welcome, though you may feel free to email me off-list if it's more appropriate. ;o] Paul __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com
Re: A6: argument initializations via //=, ||=, ::=
> > sub myprint(+$file is IO:File is rw ::= IO:STDOUT, [EMAIL PROTECTED]) {...}
> As a side note... that sig will not do the behavior you've described.
> You instead want this:
> > sub myprint([EMAIL PROTECTED], +$file is IO:File is rw ::= IO:STDOUT) {...}
> The named parameter +$file has to go behind the positional [EMAIL PROTECTED] in
> the signature, but still goes _before_ [EMAIL PROTECTED] in the actual call.
*sigh*
I haven't been the sharpest tool in the shed today, and I know that the
usual cases will be simpler, and that I'll get used to it with use
until it makes sense and comes naturally.
But in the meantime, I kinda hafta agree.
It's burning my brain.
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
Re: A6: argument initializations via //=, ||=, ::=
--- Damian Conway <[EMAIL PROTECTED]> wrote: > However I still think we're probably multiplying entities > unnecessarily. A beautiful if somewhat understated reference to Occam's Razor. While the synoptic synthesis of the writing of William of Occam is often translated into English as "One should not multiply entities needlessly", it's more colloquially stated as "the simplest answer is usually best". So why am I multiplying words? :) Ok. I agree with Damian (which is usually a safe thing to say anyway, lol...) __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com
Re: A6: argument initializations via //=, ||=, ::=
> sub foo($x ~= "foo") {...} # Append "foo" to whatever $x given
Oops. :)
That should be
> sub foo($x .= "foo") {...} # Append "foo" to whatever $x given
> sub foo($x ~= "foo") {...} # smart-test $x against "foo"
I assume the second would provide a boolean response.
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
Re: P6ML? [OT]
--- Austin Hastings <[EMAIL PROTECTED]> wrote: > --- Dan Sugalski <[EMAIL PROTECTED]> wrote: > > At 10:44 AM -0800 3/25/03, Michael Lazzaro wrote: > > >So, is anyone working on a P6ML, and/or is there any > > >discussion/agreement of what it would entail? > > > > I, for one, think it's a great idea, and the thought of altering > > perl 6's grammar to make it a functional language is sheer genius, > > making the concepts behind ML more accessible to folks used to > > procedural languages. Darned good idea--I say start right away! > > |==[*]| >Sarcasmeter? lol -- I think my BS-o-meter just redlined, too But just to make sure I'm not completely clueless on this one, would someone give me a clue as to exactly what P6ML is supposed to mean, and whether or not the original post was intended as humor? No insult intended (at least not from me, lol), but ML as in "Markup Language"? Or maybe as in the ML programming language (you know, the one used in recursion examples), and it was a question of whether it was being ported to parrot __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com
Re: A6: argument initializations via //=, ||=, ::= [OT]
(Note forwarded to the list as penance for my silliness. :)
> > > sub foo($x .= "foo") {...} # Append "foo" to whatever $x given
> > > sub foo($x ~= "foo") {...} # smart-test $x against "foo"
>
> Well, last time I looked (granted, it could've changed numerous times
> since then) ~ was the string concatenator and ~~ was the smart
> match op, so those should be:
>
> sub foo($x ~= "foo") {...}# Append "foo" to whatever $x given
> sub foo($x ~~= "foo") {...} # smart-test $x against "foo"
lol -- flashbacks. Was off on both!
I'm obviously behind the curve on ~ and ~~ ... but .= is P5, so TOTALLY
wrong. Sorry!
So _ isn't going to be the string catenation operator any more?
Ok, I need an op reference, lol
Is there a page up anywhere that summarizes the latest
prognostications?
Thanks for straightening me out. ;o]
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
Re: P6ML? [OT]
> >> |==[*]| > >> Sarcasmeter? > > > >lol -- I think my BS-o-meter just redlined, too > > Heh. Sorry 'bout that. Bring it to OSCON and I'll get it fixed. :) lol -- when/where is that? (Seems all I do here is ask dumb questions). *sigh* > I think the original was an XML in perl 6 proposal of some sort. XML > makes me twitch, though. Ick. That was kinda what I got. Leave it for a module. > A (or is that an?) ML compiler for parrot'd be really cool, though. Anything in Parrot is likely to be pretty cool. :) __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com
Re: A6: argument initializations via //=, ||=, ::= [OT]
--- Jonathan Scott Duff <[EMAIL PROTECTED]> wrote: > On Tue, Mar 25, 2003 at 12:19:30PM -0800, Paul wrote: > > Is there a page up anywhere that summarizes the latest > > prognostications? > > Mike Lazzaro had compiled the state-of-the-ops for perl6, but I don't > know if it's anywhere other than in the archives for this list. Just > go to google groups and search for "Perl Operator List". In case anyone else needs it: http://archive.develooper.com/[EMAIL PROTECTED]/msg12130.html Thanks again. __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com
Re: list manners question
> > Any input or comments welcome, though you may feel free to email me > > off-list if it's more appropriate. ;o] > > Well, this is a comment, but it's slightly off topic. I would usually > mail off list (I don't mean to score points or irritate people), but > it fits part of my view of your subject line: > > Subject: Re: list manners question > > In your headers I see > > In-Reply-To: <[EMAIL PROTECTED]> > > Please could people be careful to really start a new message (cut and > paste the list address into a new message) rather than simply hitting > reply, then clearing the subject and body totally, as threading mail > readers (and list archivers on the web) spot the in-reply-to headers > and think that it's all part of the same thread. Good point! Those of us who use simpler systems (I actually slog through the web-based Yahoo! mail) often forget or don't even *realize* what kind of silent skeletons ride in the closets of forwards and replies. I'm sure we'll try to be more careful (I know I will), but please be patient with folk like me when we get bogged down in such things. :) And FWIW, I consider this to be a very appropriate response -- an aside, perhaps, but hey, the reason I asked the question was because I care what helps and hinders other folk working on the list! ;o] Paul __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com
Re: Conditional Cs?
--- Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 31, 2003 at 12:12:54PM -0800, Michael Lazzaro wrote:
> > Don't those return C, as opposed to the value of C<$_>?
> > I.E. wouldn't it be:
> >
> > $_ and return $_ given big_calculation();
> > -or-
> > given big_calculation() {
> > return $_ when true;
> > }
>
> Personally I'd just use
>
> return big_calculation();
I started to suggest this myself, then realized that you might not want
it to return at all if the value is false. Maybe you're looking for the
first nonzero return in a set on inputs:
my $y;
for my $x (@data) {
return $y if $y = big_calc($x);
}
Otherwise, I'd *definitely* just
return big_calc();
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
Re: A6: Named vs. Variadic Parameters
--- David Storrs <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 19, 2003 at 12:19:20PM -0800, Michael Lazzaro wrote:
> > I think newbies are going to unquestionably try and put the
> > parameters in the same order as they expect to see the eventual
> > arguments, and be durn confused it doesn't work -- I know I would.
> [...]
> > Dunno. I'm just one datapoint, but I strongly see the difference
> > between (1) and (2) as being a *huge* newbie trap.
>
> Well, I guess I'm another datapoint then.
*sigh* Count me in on that one.
I *love* this sort of thing, but I *really* don't believe the average
guy is going to take the same masochistic pleasure from it as I do.
> Although I don't consider myself a wizard by any means, I've been
> programming Perl for a long time and I'm very comfortable with it.
> I've read A6 a couple of times and been following the discussions on
> the list. And, despite all those advantages, I _still_ don't really
> grok the proposed signature stuff (it gets a little clearer every
> time I read it, but it's still awfully muddy). I hadn't even
> recognized the trap that we are discussing until this thread came up.
> I think people just coming to Perl are going to be extremely baffled
> and frustrated by the signature syntax and semantics. This is going
> to promote one of two reactions: they will leave and go to
> Python/Ruby/whatever, or they will never use signatures.
Ditto, though I realize that most people aren't going to *need* sigs
for most things Perl subs will just be perl subs, and folk will
only use sigs when they need what only sigs can give them. If they need
the speed and precision, they'll use an explicit signature to specify
what's required, though most of the time I think a lot of people will
still just say
sub foo { print @_ } # copied straight from A6, p.1
I think Larry's accomodating everybody, here.
Those of us who want to play with the tinkertoys will probably enjoy
the whole box, even the little widgets that take us a while to
identify. Those who just need blocks can ignore all the little
sockety-holes and connecting rods, and just stack the blocks. Those who
*need* the widgets but don't *want* to use them are a minority, even if
they be among the power users professionally.
The hard part is accomodating both ends.
> I'm still waiting for the Exegesis...I recognize that the Apocalpsi
> are hard simply because they are definitive and must cover every edge
> case. Possibly, with some day-to-day examples and down-to-earth
> tutorial materials available, all of this will become simple; that
> has happened for me before with prior Apocalpsi.
> However, even if it ends up being clarified by the Exegesis, the
> signature syntax/semantics ARE complex. In order to justify that
> complexity, they need to provide a tremendous advantage; I'm simply
> not sure that the advantages they provide are worth the complexity.
> In order to make it worthwhile (IMO), it would need to be very easy
> to use, which would imply at least the following:
>
> 1) There are both long and short forms of the zone markers.
>E.g: sub foo($x, $y, ?$z, *a);or
> sub foo(pos($x, $y), opt($z), slurp(@a));
>
> (I'm pretty sure this is already planned.)
Good! I think this is a great idea. Looks funny to me, but MUCH
clearer!
Could they then be reordered?
> 2) Once the params and their nature have been determined, it should
>be possible to use the function with the arguments in the same
>order as the declaration:
>E.g.: sub bar(pos($a, $b), slurp(@x), named($key));
> bar($a, $b, 1,2,3, key => 'jack');
>
>I understand what I'm asking here...the slurpy array must somehow
>know to "stop", which is somewhat opposed to the idea of
>"slurping". I would be perfectly happy if it were a compile-time
>error to declare the slurpy array anywhere other than last, and to
>declare positional arguments anywhere other than first.
I'm *still* fuzzy on this.
Personally, I'd just be more likely to avoid mixing types.
I'd have positionals and then optional scalars and/or slurpies,
or named pairs with optional named pairs and/or slurpy *hashes*,
but probably wouldn't mix types otherwise if I could avoid it
But I still want to *understand* how it works, and be *able* to use all
the toys! (Damian, PLEASE find some way to magically make this all
crystal clear in the synopsis. ;o)
> I guess what I'd really like is to see the concept of 'zones' taken
> to its logical extreme; specify the order in which the zones must
> appear, and then have a marker that denotes the transition, as
> opposed to labelling every parameter.
> Therefore (violating the rule about the colon for a moment):
>
> sub foobar(
> $x, $y, $z, # required positionals go here
>o: $a, $b, $c, # optional positionals go here
>n: $d, $e, $f, # named go here
>h: %h, # slurpy hash here
>
Re: == vs. eq
--- Austin Hastings <[EMAIL PROTECTED]> wrote:
> --- Paul <[EMAIL PROTECTED]> wrote:
> > --- Austin Hastings <[EMAIL PROTECTED]> wrote:
> > > Likewise, I could argue that it be called C<=:\> (the
> > > "disgruntled muppet" operator?) since that reflects the
> > > "equals, under reference" symbology. But that's yucky.
> >
> > Shouldn't that be ==:/ (maybe the "severely startled muppet"
> > operator? lol...) A single = would be assignment, but I have
> > no idea how adverbial modification would affect that. Exactly
> > what *would* adverbial assignment be? Would
> > $a =:\ $b
> > be like
> > $a = \$b
Still no input here. Was it a stupid question? :)
> > > sub budgetwise(Int $a, Int $b) {
> > > -1_000_000 <= $a - $b <= 1_000_000; }
> > > my Int $log_rolling, Int $pork_barrel;
> > > $log_rolling = random() * 1.0E9;
> > > $pork_barrel = random() * 1.0E9;
> > > if ($log_rolling eq:budgetwise $pork_barrel)
> > > print "They cost the same, give or take a million dollars.";
> >
> > Is that saying to make budgetwise the comparison operator at the
> > same precedence as eq?
>
> Actually, what I think I'm saying in this case is "replace the do()
> behavior of infix:eq with this sub."
Okay, that clicked. I'm here now.
> Which has kind of startling effects, because then you can also say
> things like this:
>
> sub uniquely(@dest is rw, @src) {
> my $last = @src[0] ~ "1";
> for @src -> $s {
> @dest.push($last = $s) unless $s == $last;
> }
> }
> my @a = <>; # Read all lines from a file.
> my @b =:uniquely @a;# Eat the duplicates
(Apologies: code above reformatted purely in the interest of readable
space, and not considered an improvement. >:O)
Ok, so you replace ='s do{} with uniquely(). The example won't work to
assign to a scalar, right? I think I'm following you, and I like where
you're going.
"My God, it's full of stars"
> > Wouldn't that be much like saying
> >
> > my sub infix:um(Int$a,Int $b)is equiv(&infix:eq){#c.f.A6p.11
> > -1_000_000 <= $a - $b <= 1_000_000; }
> > if ($log_rolling um $pork_barrel) # etc
>
> Looks right to me, modulo type-casting behavior -- I think yours does
> typechecking and blows up if the types are misaligned enough, while
> mine finds the right infix:= operator, and replaces the actual
> mechanics. (Frankly, I'm not sure what the right behavior of mine is.
> It may be better to think of it as "temporizing" the infix:= operator
> for one expression only. More thought required.)
Good territory to expore.
> > So how does one get a ref in P6 that won't dereference itself???
>
> No idea. I thought that the auto-da-fe^Wautodereference behavior was
> intended to make "loose references" impossible -- that is, you have
> to treat a reference object as an object, always. (Which just means
> more backslashes, I guess.)
>
> > Then we could say
> > my sub infix:embodies ($a,$b) is equiv(&infix:eq) {
> > $a.ref eq $b.ref # unless eq deref's even here.
> > }
> > if ($x embodies $y) {
> > print "X and Y refer to the same entity\n";
> > }
>
> Maybe you just have to say C<\$a eq \$b> ?
Makes sense to me. Then the right spelling of the above would be
my sub infix:embodies ($a,$b) is equiv(&infix:eq) { \$a eq \$b }
The only reason I didn't put that to begin with was because of a
discussion I saw about arrays deref'ing themselves. Let's try again
with a little more complexity:
my sub infix:embodies(Ref $a is ref,$b is ref)is equiv(&infix:eq){
$a eq $b
}
Could it be this simple? (Granted, for some definition of "simple")
If I read this right, it means $a is a referencing alias of the first
argument, $b the second. Could we then say
if (@x embodies @y) { foople() }
and have it DWIM? Would that mean (in P5-speak) $a->[0] *IS* @x[0] ???
Because if so, then that's exactly what Larry was talking about. The
"cruft" has been sucked back up into the signature where the coder had
to work out the details *once*, and then the code of the operator is
deafeningly simple, as is it use.
__
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
Re: == vs. eq
Error correction:
--- Paul <[EMAIL PROTECTED]> wrote:
> > > no idea how adverbial modification would affect that. Exactly
> > > what *would* adverbial assignment be? Would
> > > $a =:\ $b
> > > be like
> > > $a = \$b
Thatv should have been: would
$a =:\ $b
be like
\$a = \$b
???
And does that mean that the do{} block of the \ operator replaces the
do{} of the = op? That wouldn't work.
But the resulting muppet really *IS* cute! ;~}
__
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
Re: Conditional Cs?
> I'm looking for a Perl6 way to say that oft-repeated, oft-chained
> two-line snippet up there without declaring the temporary variable.
> Using C or C, maybe?
I think you're going to have to have some holding space, but $_ should
do it and still avoid the predeclaration. My P6 syntax is still weak,
though. Maybe
given big_calc() { return $_ if $_ }
__
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://platinum.yahoo.com
Re: == vs. eq
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote: > Note if we are truly strict about C<==> always meaning "compare > numerically", I imagine that the line: > > [EMAIL PROTECTED] == [EMAIL PROTECTED]; > > would in fact be identical to _this_ line: > > @a.length == @b.length;# or whatever it's called Whoa!! I read [EMAIL PROTECTED] == [EMAIL PROTECTED]; as "does the [EMAIL PROTECTED] compare numerically as equal to the [EMAIL PROTECTED]", which is definitely NOT the same as @a.length == @b.length;# or whatever it's called which I read as "does @a have the same number of elements as @b?" Am I *that* far out of touch on P6 language? I thought that more of the language was going to be similar than different! __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://platinum.yahoo.com
Re: == vs. eq
--- Austin Hastings <[EMAIL PROTECTED]> wrote:
> Likewise, I could argue that it be called C<=:\> (the "disgruntled
> muppet" operator?) since that reflects the "equals, under reference"
> symbology. But that's yucky.
Shouldn't that be ==:/ (maybe the "severely startled muppet" operator?
lol...) A single = would be assignment, but I have no idea how
adverbial modification would affect that. Exactly what *would*
adverbial assignment be? Would
$a =:\ $b
be like
$a = \$b;
> sub budgetwise(Int $a, Int $b){-1_000_000 <= $a - $b <= 1_000_000;}
> my Int $log_rolling, Int $pork_barrel;
> $log_rolling = random() * 1.0E9;
> $pork_barrel = random() * 1.0E9;
> if ($log_rolling eq:budgetwise $pork_barrel)
> print "They cost the same, give or take a million dollars.";
Is that saying to make budgetwise the comparison operator at the same
precedence as eq?
Wouldn't that be much like saying
my sub infix:um (Int $a, Int $b) is equiv(&infix:eq) { # c.f.A6 p.11
-1_000_000 <= $a - $b <= 1_000_000; }
if ($log_rolling um $pork_barrel) # etc
So how does one get a ref in P6 that won't dereference itself???
The we could say
my sub infix:embodies ($a,$b) is equiv(&infix:eq) {
$a.ref eq $b.ref # unless eq deref's even here.
}
if ($x embodies $y) {
print "X and Y refer to the same entity\n";
}
__
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
Re: Short-circuiting user-defined operators
--- Austin Hastings <[EMAIL PROTECTED]> wrote:
> Dave Whipp wrote:
> > Joe Gottman wrote:
Getting deep -- sorry. :)
> > > Alternatively, there might be a new parameter type that indicates
> > > that the parameter is not evaluated immediately:
> > >
> > > sub infix:!! ($lsh, $rhs is deferred) {...}
If the standard is pass-by-ref it wouldn't trip any side effects unless
you did so in your code, right? So is this necessary?
Next author
> > A nice concept! So nice, in fact, that it would be a shame to limit
> > it to function args. I could see myself writing:
> >
> >my $a is lazy := expensive_fn1(...);
> >my $b is lazy := expensive_fn2(...);
> >print rand ?? $a :: $b;
I could certainly see some sweet uses for this. Any input from the
design team on whether this is a pipe dream or not?
> > I'm not sure quite how the syntax would work (should I be binding
> > or assigning?);
I'd say binding was right. $a is an implicit call to expensive_fn1(),
right? But that just looks like a tie to me. Maybe I misread it.
> > but there are definitely cases where this ability is
> > useful. Given this capability, defered evaluation of function args
> > would be trivial.
> > Another, very different, situation where laziness is good is to
> > abstract fork/join situations:
> >
> >my $a is lazy_thread := expensive_fn1(...);
> >my $b is lazy_thread := expensive_fn2(...);
> >print $a + $b;
> >
> > In this scenario, each expensive evaluation would be launched as a
> > separate thread. When the resulting value is later used, then the
> > thread would be joined, blocking if the thread is not complete.
So in this case you're saying to thread and execute the functions *now*
so that $a and $b can be coprocessing? That's different from the above
example. Sounds like a designer's nightmare, but a beautiful concept if
the language could take advantage of implicit threading that easily.
Next author
> This is very worth pursuing.
> I can see two ways to handle "implicit threading" -- at the object
> level, or at the sub level.
>
> Object Threading:
> -
> my Int $a is threaded = expensive_fn1(...);
> ...
> print $a; # Implicitly joins $a.thread()
>
> Sub Threading:
> --
> sub expensive_fn1(...) is threaded {...}
> my Int $a = expensive_fn1();
> ...
> print $a;
>
> The sub threading version seems, at first blush, easier to implement
> -- since if the variable requires a thread, then things like :=
> binding, and expression evaluation, get more complex.
Agreed, though I'd say (in fact I did, abover :) that := binding would
probably be necessary for that sort of per-object threadingwhich
kind of makes it equivelent to the per-sub threading. If the sub is
threaded and you bind it to an object, then that's a compile-time bind,
right? pre-spawning the thread, maybe? Then when the runtime call
occurs the thread receives the relevant arg values and starts
proceccing them immediately, etc. Still sounds like an elaborate tie()
to me, but a beautiful way to do it.
> Also, of course, it seems easier for developers to grok the concept
> of what's in parallel and what's not when using the Sub Threading
> approach.
Agreed, though anyone using threading this way should obviously be VERY
careful about it threads are not something to do accidentally. I
might even say that such ability should only be available upon explicit
pragmatic request
use threads :implicit; # maybe?
use implicit :threads; # better?
or is that a horrifically inappropriate use of Larry's colon? :)
> But what to do about matrix arithmetic and other simple threadable
> tasks?
>
> sub m_add(@a, @b) {
> my @result;
> my $i, $j;
> @result = @a;
> for @result -> $i {:is threaded # Thread this block?
> for @result[$i]; @b -> $j; $b {
> $j += $b;
> }
> }
> }
isn't $i an element alias rather than an index there?
Basically, I just failed to parse all that. Sorry -- internal P6 parser
still incomplete.
> Conversely, I have absolutely no idea what to do about threading on a
> per-data-object basis:
>
> sub m_add(@a is threaded, @b) {
> ... What can the compiler figure out about threading @a?
> }
I'd say this is unlikely to work, but again, I haven't exactly thought
it all through very thoroughly.
> This is one of those cases where the really smart guys who used to
> spend time recoding the fortran compilers for Vaxen might be able to
> clue us in on the "cool tricks for vector processing", but how
> generalizable will it all be? (And, of course, is the internal
> representation amenable to this?)
> None of this addresses the issue of "explicit" threading -- cases
> where the user wants to create and control her own threads.
Or how they would interact. If you're doing implicit threading in a
program using explicit threading, things could get REALLY tang-toungled
__
Do you Yahoo!?
Yahoo! Tax Center - File on
Re: Patterns and junctions
--- "Adam D. Lopresto" <[EMAIL PROTECTED]> wrote:
> I propose that since the empty pattern is no longer legal (and
> about time), we use "|" in patterns to indicate alternation without
> preference, and "||" to indicate "try the first, then the second,
> etc".
Hmm
A neat idea, but can you elaborate on when it would matter?
> So
> "cat dog fox" ~~ /( fox | dog | cat )/;
> might match any of the three, and in fact is quite likely to match
> cat (since scanning the string could be a very long process), but
> "cat dog fox" ~~ /( fox || dog || cat )/;
> would be guaranteed to first try fox, then if that fails backtrack
> and try dog, and if that fails backtract to try cat. The choice of
> symbols parallels the junction and short-circuiting or operators,
> and in most cases when an alternation is specified, the programmer
> has no preference among the alternatives (indeed, in most cases only
> would could match anyway), so it seems silly to force the engine to
> prefer the first one.
I thought the requirement to prefer the first was largely an
optimization, so that it could bail when it had a match without
continuing to search. ("Wouldn't you know, it was in the *last* place I
looked for it!")
Are you proposing a more DFA-ish behavior, maybe?
Some programs actually embad a DFA for a quick "does it match?" as
*well* as an NFA for pulling out backreferences once the DFA finds a
hit, but I doubt anybody is planning to embed a pre-matching DFA in
Perl (if so, somebody please tell me now).
> I'm imagining that in the first example, the implementation would
> probably build an FSA and process each letter as it comes, while the
> second would rely on backtracking.
Sounds like DFA/NFA to me
> What think you all?
Dunno. Would swell the footprint some, but might have some merit.
DFA's are generally faster, I believe, but P5's NFA is optimized to a
beautiful degree. Might be possible just by tuning the engine some
more, but then the codebase is still swelling
Dan? Parrot's pure NFA, right?
__
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
Re: == vs. eq
--- mlazzaro <[EMAIL PROTECTED]> wrote: > Austin Hastings wrote: > > It has been pointed out once already that we already talked about > > this, and I for one am in favor of the general version of it. > > The original discussion posited an "adverbial comparison", viz: > > C<$a eq:ref $b>. Which, looking at your proposal, is very close to > > C<$a =:= $b>, because I'm reading that as "equals, under > > assignment". > > What was decided about the adverbial ops -- did we ever get a > confirmation or rejection on that proposal, or did it die in the > ether? I'd still like to know as well. I must've missed it. > I like the idea lots (though I still would argue that > identity-compare =:= is important enough conceptually to be > a separate case.) I *disagree* with that, though only in principle. I don't want the code to require a lot of special cases. That was one of P5's problems. Larry&co are doing a beautiful job of designing a system by which the language is systematically and semantically consistent. Admittedly, I'm not doing any of the under-the-hood design, but for the sake of those who are as well as my own, I'd rather see the smallest possible number of "seperate case" situations. __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com
Re: Short-circuiting user-defined operators
--- Austin Hastings <[EMAIL PROTECTED]> wrote:
> --- Paul <[EMAIL PROTECTED]> wrote:
> > > But what to do about matrix arithmetic and other simple
> > > threadable tasks?
> > > sub m_add(@a, @b) { my @result; my $i, $j; @result = @a;
> > > for @result -> $i {:is threaded # Thread this block?
> > > for @result[$i]; @b -> $j; $b {
> > > $j += $b;
> > > } } }
> >
> > isn't $i an element alias rather than an index there?
>
> Yeah, but I'm assuming a 2d matrix. @result[$i] is another array.
Ah. I should have seen that. (BTW, I personally find it slightly
amusing and certainly useful to reformat code to minimize space when
it's a quote of a quote of a quote, but still offer apologies for the
resulting mishmash.)
> > Basically, I just failed to parse all that. Sorry -- internal P6
> > parser still incomplete.
>
> No, just bad writing on my part. Sorry.
I disagree. Once I know what it's doing, it looks fine. :)
> > > Conversely, I have absolutely no idea what to do about threading
> > > on a per-data-object basis:
> > >
> > > sub m_add(@a is threaded, @b) {
> > > ... What can the compiler figure out about threading @a?
> > > }
> >
> > I'd say this is unlikely to work, but again, I haven't exactly
> > thought it all through very thoroughly.
>
> I'm pretty sure it *could* work. Likewise, I'm sure we could live
> without this for the first release, if we but grab the namespace we
> think we'll need in advance. That's why this stuff should all be
> hints to the interpreter -- what the box is actually capable of is
> not something we can know.
ah -- and if it isn't feasable, the compiler just ignores those hints,
builds it the old-fashioned way, and goes on about it's business. If
the hardware and the OS provide sufficient support, on the other hand,
the compiler might take advantage of them when the code suggests it.
Ok, I could see that.
> Certainly it's trivial to "thread" basic vector processing:
> 1. Get max# of useful threads (#cpu's - 1)?
> 2. Every computation of a threaded vector member gets allocated to
>a new thread, round-robin.
> 3. Any read of a threaded vector member forces a join on the
>allocated thread before proceeding.
>
> This isn't optimal, but it would work. But knowing how much benefit
> you're going to see will be part of the equation, too. So you want
> the runtime to balance the startup/shutdown cost versus the execution
> cost, if possible. Also, you want to favor threading when a blocking
> operation might occur in the threadable code. That kind of stuff.
More nightmares for the designers. :)
Maybe that's P8? :)
> > > This is one of those cases where the really smart guys who used
> > > to spend time recoding the fortran compilers for Vaxen might be
> > > able clue us in on the "cool tricks for vector processing", but
> > > how generalizable will it all be? (And, of course, is the
> > > internal representation amenable to this?)
> > > None of this addresses the issue of "explicit" threading -- cases
> > > where the user wants to create and control her own threads.
> >
> > Or how they would interact. If you're doing implicit threading in a
> > program using explicit threading, things could get REALLY
> > tang-toungled
>
> Implicit threading must be transparent to the coder, or it's not
> implicit, icit?
lol -- but I don't necessarily *totally* agree. I make explicit use of
implicit behavior a little too much of the time, depending on what you
mean. I think the common term for it is "cryptocontext". :)
Still, your point is valid. "Implicit" threading (or anything else) is
something done quietly, like implicit dereferencing of arrays. I was
just thinking that if the user is using explicit threads, he might do
things that implicitly interfere with or receive interferance from
implicit threads but then, I can't exactly come up with an example,
so the point is probably entirely moot.
> So if I have two explicit threads:
>
> my ViewControlTask = new Task(...);
> my ViewControlThread = new Thread(priority => 1,
> task => ViewControlTask);
> my ComputationTask = new Task(...);
> my ComputationThread = new Thread(priority => 19,
> task => ComputationTask);
>
> Anything which happens *implicitly* in the ComputationTask must be
> invisible to the coder. So the task will automatically be split and
> automatically be joined (or not) based o
Re: How shall threads work in P6? [OT :o]
--- Larry Wall <[EMAIL PROTECTED]> wrote: > For anything other than existential issues, I believe that > most arguments about the future containing the words "either", > "or", "both", or "neither" are likely to be wrong. In > particular, human psychology is rarely about the extremes > of binary logic. As creatures we are more interested in > balance than in certainty, all the while proclaiming our > certainty that we've achieved the correct balance. > In short, I think both the pthreads and ithreads models are wrong > to some extent. > Larry And this is why I believe it's best to have a philosopher guiding the design, as long as he's been properly indoctrinated into the issues surrounding the relevant mechanics. ;o] __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com
Re: is static? -- Question
--- arcadi shehter <[EMAIL PROTECTED]> wrote: > Larry Wall writes: > > > > Er, how would LEAVE detect that this was the *last* time you're > > ever going to call this routine? > > > > On the other hand, if we renamed FIRST and LAST to ENTER and > > LEAVE, then FIRST would become available to mean "my very first > > time"... > > and LAST will mean "just before the GC wipe closure out" ?? Wouldn't that be DESTROY? (Obviously not unless it's an object, but) __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com
Re: Patterns and junctions
--- Luke Palmer <[EMAIL PROTECTED]> wrote: [extremely large *SNIP*] > Maybe the "|"/"||" distinction isn't needed, and we just need a > declarator on rules that says they are side-effect-free, and can thus > be optimized. [snip] > I like this solution better than making a new operator. In Perl > tradition, it puts the optimization burdon on the compiler, not the > programmer. Agreed. Minimize the need for new grammar in the language, including operators, but provide a way that code can DWIM the same result. "If you build it, they will come". __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com
RE: RFC 264 (v1) Provide a standard module to simplify the creation of source filters
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Provide a standard module to simplify the creation of source filters
>
> =head1 VERSION
>
> Maintainer: Damian Conway <[EMAIL PROTECTED]>
> Date: 20 September 2000
> Mailing List: [EMAIL PROTECTED]
> Number: 264
> Version: 1
> Status: Developing
>
> =head1 ABSTRACT
>
> This RFC proposes that the interface to Perl's source filtering facilities
> be made much easier to use.
>
> =head1 DESCRIPTION
>
> Source filtering is an immensely powerful feature of recent
> versions of Perl.
> It allows one to extend the language itself (e.g. the Switch module), to
> simplify the language (e.g. Language::Pythonesque), or to
> completely recast the
> language (e.g. Lingua::Romana::Perligata). Effectively, it allows
> one to use
> the full power of Perl as its own, recursively applied, macro language.
>
> The Filter::Util::Call module (by Paul Marquess) provides a usable Perl
> interface to source filtering, but it is not nearly as simple as
> it could be.
>
> To use the module it is necessary to do the following:
>
> =over 4
>
> =item 1.
>
> Download, build, and install the Filter::Util::Call module.
>
> =item 2.
>
> Set up a module that does a C.
>
> =item 3.
>
> Within that module, create an C subroutine.
>
> =item 4.
>
> Within the C subroutine do a call to C, passing
> it either a subroutine reference.
>
> =item 5.
>
> Within the subroutine reference, call C or
> C
> to "prime" $_ with source code data from the source file that will
> C your module. Check the status value returned to see if any
> source code was actually read in.
>
> =item 6.
>
> Process the contents of $_ to change the source code in the
> desired manner.
>
> =item 7.
>
> Return the status value.
>
> =item 8.
>
> If the act of unimporting your module (via a C) should cause source
> code filtering to cease, create an C subroutine, and
> have it call
> C. Make sure that the call to C or
> C in step 5 will not accidentally read past the
> C. Effectively this limits source code filters to line-by-line
> operation, unless the C subroutine does some fancy
> pre-pre-parsing of the source code it's filtering.
>
> =back
>
> For example, here is a minimal source code filter in a module named
> BANG.pm. It simply converts every occurrence of the sequence
> C
> to the sequence C in any piece of code following a
> C statement (until the next C statement, if any):
>
> package BANG;
>
> use Filter::Util::Call ;
>
> sub import {
> filter_add( sub {
> my $caller = caller;
> my ($status, $no_seen, $data);
> while ($status = filter_read()) {
> if (/^\s*no\s+$caller\s*;\s*$/) {
> $no_seen=1;
> last;
> }
> $data .= $_;
> $_ = "";
> }
> $_ = $data;
> s/BANG\s+BANG/die 'BANG' if \$BANG/g
> unless $status < 0;
> $_ .= "no $class;\n" if $no_seen;
> return 1;
> })
> }
>
> sub unimport {
> filter_del();
> }
>
> 1 ;
>
> Given this level of complexity, it's perhaps not surprising that source
> code filtering is not commonly used.
Whilst I don't have any problems with you module, I think you are
overstating the complexity of the existing situation. This should be all
that is needed to create your filter.
package BANG;
use Filter::Util::Call ;
sub import
{
filter_add( sub {
my ($status);
s/BANG\s+/die 'BANG' if \$BANG/g
if ($status = filter_read()) > 0 ;
$status ;
})
}
sub unimport
{
filter_del() ;
}
1 ;
> This RFC proposes that a new standard module -- Filter.pm -- be
> provide to vastly simplify the task of source code filtering,
> at least in common cases.
Can I suggest you feed data a line at a time rather than the series of lines
as you do right now. That makes it work like the existing filters.
I'm not sure Filter is the best name for this. How about Filter::Transform
or Filter::Simple?
Paul
__
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Re: RFC on Coexistance and simulaneous use of multiple module version s?
On Wed, Feb 14, 2001 at 10:58:57PM -0500, Steve Simmons wrote: > > > Note that it may not be possible to satisfy conflicting requests. If > > > module C and module C demand two different versions of the same > > > module C, the compiler should halt and state the module conflicts. > > > > Pardon me for sniping at a great RFC, but I already promised the CPAN > > workers that I'd make that last statement false. There's no reason in > > principle why two modules shouldn't be allowed to have their own view > > of reality. Just because you write Foo::bar in your module doesn't mean > > that Perl can't know which version of Foo:: you mean. Has anyone considered the problems associated with XS code, or whatever its replacement is? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: RFC on Coexistance and simulaneous use of multiple module version s?
On Thu, Feb 15, 2001 at 10:43:38AM -0300, Branden wrote: > Paul Johnson wrote: > > > > Has anyone considered the problems associated with XS code, or whatever > > its replacement is? > > > > The big problem about having more than one version of a module loaded at the > same time is with namespaces... Permit me to be more specific. Foo.pm version 1.1 uses libFoo.so.1.1 Foo.pm version 1.2 uses libFoo.so.1.2 -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: RFC on Coexistance and simulaneous use of multiple module version s?
On Thu, Feb 15, 2001 at 02:47:55PM -0500, Steve Simmons wrote: > Paul Johnson wrote: > > > Has anyone considered the problems associated with XS code, or whatever > > its replacement is? > > Pardon my ignorance, but what's XS code? perldoc perlxs perldoc perlxstut I don't think any proposal of this nature would be conplete without a consideration of these aspects. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
RE: Warnings, strict, and CPAN
From: Edward Peschko [mailto:[EMAIL PROTECTED]] ... > I'm beginning to think there should be an extra flag that turns > *on* warnings > even if 'no warnings' is explicitly stated. This is the 'enable > me to help you > out' flag. That way, it would be a lot easier for me as a module > consumer help > find bugs in things that the module writer himself doesn't have a > grip over. >From perllexwarn: -W If the -W flag is used on the command line, it will enable all warnings throughout the program regardless of whether warnings were disabled locally using no warnings or $^W =0. This includes all files that get included via use, require or do. Think of it as the Perl equivalent of the ``lint'' command. Paul _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
RE: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] ... > > The basic usefulness of warnings is not in question. This is about > the *perception* of their utility. Warnings are only useful if the > user heeds them. The question is, will having them on by default make > the user more or less likely to respond? > > There was also eariler discussion that this might encourage people to > cover up large sections of lousy code with a C thus > further burying potential errors and actually worsening the situation. > Some ideas were kicked around to have a way to globally override C warnings>... This is what the -W command-line flag does. > but it seems like we're right back to having to remember > -w again. Paul _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: Distributive -> and indirect slices (fwd)
On Mon, Mar 26, 2001 at 10:02:40AM -0600, David M. Lloyd wrote: > $obj->method; # Clearly void context. Unless it's not. For example as the last statement in a subroutine. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: pitching names for the attribute for a function with no memor y or side effects
On Sat, Mar 31, 2001 at 02:01:39PM -0600, Frank Tobin wrote: > John BEPPU, at 12:50 -0700 on Sat, 31 Mar 2001, wrote: > > > I like pure too, but I'm afraid the nuance of it will be > > completely lost on non-Functional programmers. > > not to worry... If anything, it might educate them. I > didn't really grok functional programming before I got > to experiment w/ some functional idioms in a perl context. > I also like "pure" for its great potential in perl poetry. ;-) > > "not to worry"??? I don't think this attitude is useful for deciding how > to name thing. You don't decide things merely on the idea of "how things > should be"; you have to grasp what the average programmers is going to > think of it. Without commenting on main theme of this thread, although I have plenty of opinions on that too, and not wanting to open too many cans of worms, may I simply mention that I hope we are not trying to cater too much to the average programmer? There are already plenty of languages that will do that. Perl has always been an expert friendly language. That doesn't mean that beginning or average programmers cannot use it, but rather that by using it, by reading the documentation and code from expert programmers, they may be able to improve and become better programmers. I think that is a fine stand for a computer language. > Just because one programming paradigm happens to name it "pure" doesn't > mean that name should be carried over to other paradigms. In a > functional-programming context, sure, "pure" might be a good name. But in > a non-functional context, the name has little meaning with regards to the > concept of "nosideeffects". By using a correct term, although it may be unknown to the average programmer, the programmer is presented with an oportunity to learn, and may even be exposed to a completely new programming paradigm. And, by the way, it is already possible to do reasonable functional programming in Perl, and it looks as though Perl6 will provide even more support. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Larry's Apocalypse 1
On Fri, Apr 06, 2001 at 10:01:47AM +0100, Graham Barr wrote:
> unless (defined wantarray) {
> # Self Test
> }
>
> This works because whenever a file is use'd, require'd etc. it is
> evaluated in a scalar context. The main file is in a void context.
Although Gisle's recent patch changes this for "do" at least.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Larry's Apocalypse 1
On Sat, Apr 14, 2001 at 12:11:12PM -0400, John Porter wrote: > Dan Sugalski wrote: > > I personally would rather that perl 6 handle perl 6 code only, and leave > > the compilation and interpretation of perl 5 code to perl 5. > > FWIW, I agree 100% with Dan. I'm curious to see how mutt will handle this thread when it gets off the right hand side of the screen, so would it be possible to have another couple of rounds of this? For those who aren't quite sure of the rules, post one of these messages at the appropriate time: - Larry said perl6 will parse perl5 code by default. - I don't want to have to put "module" in my one liners. - Let's have a switch -6. - What's wrong with -M6? - Just use the shebang line. - Can't perl determine whether it's perl5 or perl6? - perl6 should parse perl6 by default. Improvisation and embellishment is allowed, but don't get too far off the beaten track or people won't be sure which message they should post next and then the thread will die. [ :-) for those who like such things ] -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Dot can DWIM without whitespace
On Wed, Apr 25, 2001 at 03:33:52PM -0700, Edward Peschko wrote: > I think its really time to have a vote on this Aaargh. I don't. Wouldn't you rather wait and see what Larry is planning with all this? I doubt the proposed changes are gratuitous, and I think he's got a pretty good track record with these sorts of things. Anyway, what do you think this is? Some kind of democracy? :) -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Between-Opcode Callbacks
On Mon, Jul 09, 2001 at 04:30:08PM -0400, Dan Sugalski wrote: > At 03:30 PM 7/9/2001 -0400, Uri Guttman wrote: > >definitely insert special opcodes only when asked for by a compiler > >option. stuff like profiling, tracing, fine grained single step (op > >code) debugging should be supported with special op code insertion upon > >user request. > > Nah, most of that doesn't need special support. We can piggyback on the > event pending flag. It'll be a UV, so there's no reason not to save a bit > for "debug". The event handler will never clear that, so we're fine. > > >but some special tasks still would want special op codes to be > >inserted. it would be simpler than piggy backing on only the ones you > >mentioned above. think about stuff like 'safe' or profiling or op code > >level debugging. > > Profiling and opcode debugging are covered in other ways (and the fanciest > is to have a special op running loop, which wouldn't be a bad idea). Well, that's what we have in Perl5, and it works fine until you have two modules both wanting to install their own runops function (not that that has necessarily happened yet). I can also see similar sorts of problems with more than one module wanting to manipulate the "debug bit". I'm sure that can be worked around though. > Special ops to mark statement starts and such are probably going to happen > (so we have reasonable line numbers for error messages and such) now that I > think about it. Granted they get stripped out in some cases, but that's OK. > > It's also going to be very easy to override or supplement opcode functions, > and we're really going to be guaranteed some (end of statement and end of > block) are going to be there since we need cleanup, so it makes sense to > have them check for things that need to be done on a statement or block > boundary.. > > >there may just be a single special op code (called trap?), which is only > >one byte (no args) and which breaks into a handler which can check > >various flags and do stuff. very reminiscent of the trap op code of many > >cpu's. > > Sure, we can do that too. I think something like that will be necessary. And ultimately it's going to be possible to directly manipulate the optree, even while a program is running, right? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Between-Opcode Callbacks
On Sat, Jul 07, 2001 at 09:58:54PM -0400, Uri Guttman wrote: > >>>>> "PJ" == Paul Johnson <[EMAIL PROTECTED]> writes: > > PJ> Some method of attaching a callback function to arbitrary opcodes would > PJ> be very useful. > > how would you propose those callbacks be attached without op codes to do > the callback? :) Well I was specifying requirements rather than proposing solutions, but with this being the internals list I suppose I should have been thinking more about the implementation. I'm not aware of any firm decisions having been made in this area though. > PJ> For example, in a code coverage tool a callback would be desirable > PJ> not only at the exit (or entry) of a block, or more accurately a > PJ> linear code sequence, but also at various points throughout a > PJ> conditional, so that it is possible to determine not only the > PJ> truth value of the conditional, but also why. As a trivial > PJ> example, in $x = $y || $z, was $y true, was it $z, or were they > PJ> both false? > > i think that is best done with inserting special op codes when enabled > by a profiling or debug flag. Done by what? Adding opcodes at all conceivable positions could be unnecessarily expensive for most applications, and you're bound to miss something that someone wants. I would imagine this is best done on a case by case basis, but maybe you were thinking that way too. How is this going to work? Imagine I have a C function or Perl sub I want to call at the end of a block. Would I insert an opcode to call my sub, or would there be room to tack a number of pointers onto the existing block end opcode? Or something else? "No one knows yet" is fine as an answer (provided it's correct). > what dan is trying to do (and i am supporting) is keeping the dispatch > loop as small as possible. it is easier and faster to insert and > dispatch special op codes than to check more flags. I have plenty of sympathy with this view. I just want to ensure there is sufficient power and flexibility to do all sorts of exciting things. But everything I've heard so far seems to show that everyone else is after that too. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Between-Opcode Callbacks
On Sat, Jul 07, 2001 at 02:49:48PM -0500, Jarkko Hietaniemi wrote: > On Sat, Jul 07, 2001 at 03:35:04PM -0400, Dan Sugalski wrote: > > At 02:23 PM 7/7/2001 -0500, Jarkko Hietaniemi wrote: > > >On Sat, Jul 07, 2001 at 03:07:52PM -0400, Dan Sugalski wrote: > > > > At 01:00 PM 7/7/2001 -0500, Jarkko Hietaniemi wrote: > > > > >Would it make sense / be useful to have also distinct "between > > > > >statements" callbacks? > > > > > > > > Yup. For the debugger if nothing else, and it's a good place to put > > > cleanup > > > > code, so... I expect we'll have an "end of statement" opcode > > > > > >Maybe just a bit for that on an(y) opcode? > > > > Well, I'd figured we'd have: > > > > *) A 'pending event' bit that would be checked per-opcode. > > *) An 'end-of-statement' opcode that the compiler would put in at the end > > of each statement > > *) An 'end of block' opcode that the compiler would put in at the end of > > each block > > > > The 'end of' opcodes would be able to have extra functions stacked on them > > so we could do arbitrary things after the end of every statement or block. > > (As well as on an individual block or statement boundary) > > Well, either way (separate end-of opcodes or bits) is fine, depends on > how 'atomic' you want to keep the opcodes and what kind of metadata > they carry, if any. Some method of attaching a callback function to arbitrary opcodes would be very useful. For example, in a code coverage tool a callback would be desirable not only at the exit (or entry) of a block, or more accurately a linear code sequence, but also at various points throughout a conditional, so that it is possible to determine not only the truth value of the conditional, but also why. As a trivial example, in $x = $y || $z, was $y true, was it $z, or were they both false? Verilog, a Hardware Description Language, is an example of a language in which this is possible, using the VPI. > For symmetry a begin-of-block opcode can be imagined, also, but I have > hard time thinking what would setup the code to run in there unless we > allow for time travel :-) See above? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Between-Opcode Callbacks
On Mon, Jul 09, 2001 at 11:46:30PM -0500, Jarkko Hietaniemi wrote: > > > XML > is > much > too > verbose And it should be neither written nor read by people ;-) > . > > -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: nice2haveit
On Mon, Jul 16, 2001 at 03:37:41PM -0500, David L. Nicol wrote: > Uri Guttman wrote: > > > one related point is that this symbol table will be accessible via > > caller() so you could access/install lexical symbols in a parent block > > on the call stack. scary! > > > > uri > > We must demand that the feature come with a way to seal the current > context from manipulation, even possibly a way to block accesses. Doesn't sound very Perlish to me. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: op code bof
On Thu, Jul 19, 2001 at 01:40:50PM -0400, Dan Sugalski wrote: > > Sure, sounds good. I'll see about having the first draft of the "Parrot > Assembly Language Manual and Architecture Handbook" PDD with me too. (All I > need to do now is write it...) The Palmah. Our canon of scripture? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: explicitly declare closures???
On Tue, Aug 21, 2001 at 06:06:06PM +0100, Dave Mitchell wrote:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
> > > {
> > > my $x = "bar";
> > > sub foo {
> > > # $x # <- uncommenting this line changes the outcome
> > > return sub {$x};
> > > }
> > > }
> > > print foo()->();
> >
> > Well, I would expect it to output 'foo' on both occasions, and I'm
> > more than a little surprised to discover that it doesn't. Looks like a
> > bug to me.
>
> Using the notation $outer:x, $foo:x and $anon:x to refer to whatever
> $x might be in the 3 scopes:
>
> With the $x:
>
> foo() is a closure created at compile time.
Actually, foo() is not a closure. A closure is an anonymous subroutine
and foo() clearly has a name.
Now, if you were proposing that named subroutines should behave like
closures in this regard, which is what Piers and probably most others
were expecting, I suspect that you would probably get broad agreement.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: explicitly declare closures???
On Wed, Aug 22, 2001 at 10:34:49AM +0100, Dave Mitchell wrote:
> Paul Johnson <[EMAIL PROTECTED]> wrote:
> > Actually, foo() is not a closure. A closure is an anonymous subroutine
> > and foo() clearly has a name.
>
> Damain's definition of a closure includes named subs:
>
> "In Perl, a closure is just a subroutine that refers to one or more lexical
> variables declared outside the subroutine itself" - OO perl, p 56.
So it does. And he's pretty explicit about it, even giving examples
using named subs. However, the Perl (5) documentation is pretty
explicit that, in a Perl sense anyway, a closure is an anonymous
subroutine. I don't think it says anywhere that a named sub is not a
closure, but it always says that a closure is an anonymous sub.
> > Now, if you were proposing that named subroutines should behave like
> > closures in this regard, which is what Piers and probably most others
> > were expecting, I suspect that you would probably get broad agreement.
Certainly from Damain, it would appear.
> I'm not sure I understand this bit - named subs are really no different from
> anon subs in respect to closures, except that named subs get instantianted
> once - at compile time, and anon subs may get instantiated multiple
> times, thus creating multiple private copies of the outer lexicals.
But "no different, except" means that they are different :-)
Try changing your original example from
sub foo {
to
*foo = sub {
and you'll see that everything works "as expected".
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Perl 6 modules plan
On Sat, Aug 25, 2001 at 09:40:05AM -0400, John Siracusa wrote: > On 8/25/01 5:12 AM, Johan Vromans wrote: > > John Siracusa <[EMAIL PROTECTED]> writes: > >> If you ask any Java programmer which is "correct", myJavaMethod() or > >> My_Java_Method(), I think you'll get a straight answer. > > > > From experience I can assure you this is not the case. There are a > > couple of (independent and mutual inconsistent) style guides on the > > web (e.g. Sun, Netscape). Each have their own followers. > > Er, okay, well scratch that example then :) But my point still stands: I I'd actually scratch the others too. That one was probably the best :-) > think Perl 6 should have some sort of guidelines in this area, even if > they're only a codification of what "the majority" of Perl authors do. Something like perlstyle and perlmodstyle for perl 5 then? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: RFC: Test::JSON
On Mon, Nov 14, 2005 at 01:17:05PM -0800, chromatic wrote: > On Mon, 2005-11-14 at 12:45 -0800, Ovid wrote: > > > Yes, I can see that. I could actually have dropped Test::Differences > > "eq_or_diff" and just used the "is_deeply" function from Test::More, > > but when working with large data structures, there's just no comparison > > between the two. I suppose I could make Test::Differences optional and > > fall back on is_deeply if they don't have T:D installed. > > At some point, people install modules for the convenience of not writing > that code themselves. I think they'll survive if you require modules > for the convenience of not having to write that code yourself, at least > if you don't go crazy with it. Whilst I agree with this and I am quite happy installing testing modules I decided that with Devel::Cover I didn't want to create a dependency on Test::Differences so I took the approach of using it if it is availabile. In a reasonably complicated test module it took about 9 extra lines of code to optionally use Test::Differences. It is true that there is no comparison in the quality of the test output. The only downside is that it is another configuration on which I need to test before making a release. Oh, and Test::JSON works well for me. Thanks! -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Compiling Devel::Cover stats across scripts
On Wed, Nov 16, 2005 at 05:46:34PM -0500, David Golden wrote: > Before I flounder around to figure this out, I hope that a quick message to > the list can offer some guidance. > > I've got a bunch of test files for a distribution that run a script that > comes with the distribution. I'd like to test my coverage against that > script. I figure that I can just pass "-MDevel::Cover" to the execution of > the script if that's also in the HARNESS_PERL_SWITCHES. > > If my test file calls the script 20 times testing 20 different execution > paths, do all the runs get aggregated into cover_db? Or do I need to > create separate cover_db_$$ dirs for each of the 20 runs, then use cover at > the end to merge them together? I would hope things should work just as you are expecting, that is all twenty runs should be merged to give combined coverage for the script and any modules used. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: handling undef better
On Mon, Dec 19, 2005 at 12:13:04PM +0100, Michele Dondi wrote:
> my $x;
> $x->{foo}[42][2005]{bar}='quux';
>
> Would you like to have to explicitly and verbosely declare the shape of
> the structure held in $x instead?
I would like the option to have to, or to be able to do that, and maybe
to declare which hash keys or array elements are valid.
Do we have that already?
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: How to best have statements execute only during dev/testing?
On Tue, Jan 10, 2006 at 08:11:43AM -0800, Matisse Enzer wrote:
> I'd like to create a class that provides a bunch of assertion
> methods, like Carp::Assert, etc. I want to have an object oriented
> interface, so in some code I'm developing I would have:
>
>
> use Devel::Assert;
> my $tester = Devel::Assert->new( on_fail => carp ); # or on_fail
> => cluck, etc.
>
> my $data_structure = blah_blah();
> $tester->save($data_structure); # Saves a clone of the data in a
> unique slot
> #
> # do stuff with $data_structure
> #
> $tester->has_changed($data_structure);
>
> The trick I want is that if my code is running in a production
> environment (perhaps determined at compile-time) then I want my
> Devel::Assert stuff to basically disappear. So the question is, what
> is the lowest-impact way to do that?
>
> One easy, but probably not best way is to like this:
>
> sub has_changed {
> return if is_production();
> # do actual stuff
>}
>
> I'll note here that Carp::Assert handles this issue by having you
> make all the test calls conditional:
>
>ASSERT( $a == $b) if DEBUG;
This isn't an answer to your question, but in general production is the
environment in which your code will be exposed to the data and
conditions which have had the least testing, and to which you will have
the least access and freedom to change things. This is precisely the
environment in which I like to have checks to discover problems as early
as possible and to provide the most information about them.
Should you have considered this found that the checks are just too
expensive, for example, one possibility which is slightly better than
the one you proposed might be to to replace all the methods in
Devel::Assert with empty subs. This will mean that you will still have
the overhead of a method call, which is (un)reasonably expensive in
Perl, so to eliminate the call completely you are left with a solution
such as the one you noted, where the call is conditional on some
constant which can be set to false allowing the optimiser to remove the
whole thing from the op tree.
I suppose you could consider a source filter, but I couldn't recommend
that.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: [svn:perl6-synopsis] r7784 - doc/trunk/design/syn
--- [EMAIL PROTECTED] wrote: > . . . > -Such an "eigenmethod" is delegated to C<.meta> just as method like > . . . > +Such an I is always delegated to C<.meta> just as changing "eigenmethod" to I should also change "an" to "a": +Such a I is always delegated to C<.meta> just as ^ Small thing, but someone will mention it eventually anyway. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [selenium-dev] Selenium RC driver
On Thu, Apr 06, 2006 at 11:06:00PM -0700, Dan Fabulich wrote: > Good points there... Here's my two cents (and a bit). > > 0) Not explicitly highlighted, Selenium Core generates an XML file > with a full description of its API; this is enough information to > generate copious javadoc, ndoc, rdoc, pydoc, or POD perldoc. We should > use it for something perl-ish, one way or another. Agreed. > 1) It's worth noting that the other drivers (java, c#, python, ruby) > *do* have build code. For python/ruby, there's just enough build code > to run XSLT to generate code, run some tests, and generate doc, but > the c# code requires running it through csc and the java code is > compiled by Maven. A makefile would therefore not be out of place. > > 2) As clever as the AUTOLOAD code is, it can be very opaque to end > users. Since the AUTOLOAD code has no explicit definition of "click" > (for example), users can't grep through the code for its > implementation, and they have to consult the Selenium website for > reference documentation. While we could use the Core XML to merely > generate POD documentation, at that point we're really 90% of the way > towards generating all of the Perl code, which I would probably > prefer. I'm not particularly concerned about this one way or another. Provided the documentation is there people can look at the source or not as they please. No doubt some poeple would prefer the minimal AUTOLOAD code and others the more explicit longhand. Since it is machine generated we are keeping DRY whichever way we go. > 3) It's never been clear to me what to do with code that is partly > Perl and partly something else. CPAN is full of pure Perl (or Perl + > C) projects, but Selenium will always be a multi-lingual project (for > the browser-side JavaScript alone, if not also the Java server). What > do people normally do with that kind of project? I don't see a problem with that sort of thing going on CPAN, at least not from that point of view, but I do wonder if it is worthwhile given that it will exist as part of Selenium itself. I suppose the advantage would be that it would be possible to use standard perl installation mantras to install Selenium. > 4) I'm happy to volunteer to maintain a *thin* Perl driver that does > not include its own back-end code. Such a driver should be no longer > and no more complex than the Python, Ruby, Java or C# drivers, and > can/should include automatically generated code/doc. If the project is > bigger than that, though, someone else will need to do it. What is the state of this at the moment? I need it now, otherwise I'll be using the Ruby driver ;-) I have some time to work on it at the moment, but I might not have in a few days. Luke mentioned he had the basics of something, and you have volunteered here. Is there something I can assist with? As far as strategy is concerned, I think this is the right way to go. I don't see any point in rewriting the Java code if it is doing everything necessary (I discovered I needed a fairly recent (or possibly just not ancient) version of java to get it to work), and being consistent with the other languages seems to provide many benefits. I'm on freenode #selenium if anyone wants to discuss this there. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: [selenium-dev] Perl Selenium RC driver
On Mon, Apr 10, 2006 at 10:26:14AM -0700, Dan Fabulich wrote: > Paul Johnson wrote: > > Re: CPAN... > >I don't see a problem with that sort of thing going on CPAN, at least > >not from that point of view, but I do wonder if it is worthwhile given > >that it will exist as part of Selenium itself. I suppose the advantage > >would be that it would be possible to use standard perl installation > >mantras to install Selenium. > > I'd think it'd be worth putting up on CPAN in some form, I think, if it > could be done cleanly, for that reason alone. > > But the idea of CPAN is that you should be able to just go to CPAN and > -install your module and then, after a short wait, you should be ready to > begin using it. When the module has dependencies on other non-Perl non-C > code, that presumably means you're going to have to install another > interpreter as well. > > I could certainly imagine a CPAN module that would automatically install > Java (Alien::Java?), but that seems Really Weird to me, perhaps especially > because Java isn't Free-as-in-Speech software. I'd sooner imagine someone > writing an Alien::Python CPAN module or an Alien::Ruby module! I don't think it is a big problem to say "you need to have selenium installed to use this module - here's what to do". Or maybe "would you like me to install it for you?" > >What is the state of this at the moment? I need it now, otherwise I'll > >be using the Ruby driver ;-) > > Well, if you need it Now (tm) then you *should* use the Ruby driver. :-) OK. How about Real Soon Now? ;) > >I have some time to work on it at the moment, but I might not have in a > >few days. Luke mentioned he had the basics of something, and you have > >volunteered here. Is there something I can assist with? > > Not really. Writing an RC-compatible thin Perl driver is a matter of a > day; I've done it, and it sounds like Luke's got one, and some other folks > have also written one. I think the only thing to do now is decide what to > do with all this code we've written. Is your code checked in? I had a discussion with Luke on IRC and we threw a few ideas around, but I wasn't aware that either you or anyone else had any code written, and I don't think Luke was either. It might be an idea for you, Luke and anyone else with any code to get together somehow and see how to push this forward, either in this thread or on IRC. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: A shorter long dot
On Mon, May 01, 2006 at 01:15:58PM +0100, Smylers wrote: > Jonathan Lang writes: > > > Larry Wall wrote: > > > > > I don't see much downside to \. as a long dot. > Folks want to be able to line stuff up, and to split statements over > multiple lines. This is now possible. You know, I'm still wondering who these folks are. Seriously. Maybe you all write your code differently to me, but looking through a load of my OO code I had trouble finding three method calls in a row to any methods on any objects, let alone six calls to the same method name on different objects. If I saw code like $xyzzy.foo(); $fooz\.foo(); $foo\ .foo(); $fa\ .foo(); $and_a_long_one_I_still_want_to_align\ .foo(); $etc\ .foo(); I'd probably take that as a pretty strong clue that I should really have written $_.foo for @things_to_foo; or something. I like lining up my code as much as the next programmer, and probably a lot more, but I just don't see the need for this syntax which seems ugly, confusing and unnecessary. But then again, as I said, I really don't see the problem that is being solved. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Proposed kwalitee metric: consistent_newlines
On Wed, May 03, 2006 at 11:36:53AM +0200, A. Pagaltzis wrote: > Am I missing something, or won’t all of these will cause problems > with Module::Signature? The thing is that it doesn’t matter how > perl sees the file; what matters is how Module::Signature sees > the file, and to my knowledge, the latter does not attempt to > parse the file in any fashion, so neither should the > corresponding Kwalitee metric. I'm probably missing something too since I know litle to nothing about Module::Signature, but it seems to me that if Module::Signature has a problem with certain (valid) files then maybe it is Module::Signature that needs to be fixed rather than mandating (as much as kwalitee can) than everything else should conform to its understanding of the world. Now I know other people probably have different views on this, since I also dislike adding /* NOTREACHED */ to shut up lint, writing if ((a = b)) to shut up gcc, and even adding # uncoverable to keep Devel::Cover quiet ;-) [ No, that last one doesn't work yet. ] -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: A shorter long dot
On Thu, May 04, 2006 at 01:56:44PM +0300, Markus Laire wrote:
> On 5/1/06, Paul Johnson <[EMAIL PROTECTED]> wrote:
>
> >But then again, as I said, I really don't see the problem that is being
> >solved.
>
> This "long-dot" can be used for many things, not just method calls.
Thanks for taking the time to explain this. The long dot here does seem to be
solving more important problems. Now I'm not as up to date with Perl 6 syntax
as I once was, nor as much as I probably should be to be part of this thread,
but ...
> IMHO This example from S03 is a lot better:
>
>
> Whitespace is no longer allowed before the opening bracket of an array
> or hash accessor. That is:
>
>%monsters{'cookie'} = Monster.new; # Valid Perl 6
>%people {'john'} = Person.new; # Not valid Perl 6
What does "Not valid Perl 6" mean? A syntax error? Is it not possible
to make it valid and to mean what would be meant without the whitespace?
Thinking about it a bit, I suppose the problem would be how to parse
something like
if $person eq %people {'john'} { ... }
which would be valid whichever way you parsed it, right?
> One of the several useful side-effects of this restriction is that
> parentheses are no longer required around the condition of control
> constructs:
>
>if $value eq $target {
>print "Bullseye!";
>}
>while 0 < $i { $i++ }
>
> It is, however, still possible to align accessors by explicitly using
> the long dot syntax:
>
> %monsters.{'cookie'} = Monster.new;
> %people\ .{'john'} = Person.new;
> %cats\ .{'fluffy'} = Cat.new;
>
I'm probably not seeing what the rest of the "several useful
side-effects" are, and I'm probably far too conservative, but given the
choice between the following I know which one I would choose.
if ($value eq $target) {
$monsters{cookie} = Monster->new;
$people {john } = Person ->new;
$cats{fluffy} = Cat->new;
}
if $value eq $target {
%monsters.{'cookie'} = Monster.new;
%people\ .{'john' } = Person\.new;
%cats\ .{'fluffy'} = Cat\ .new;
}
if $value eq $target {
%monsters. = Monster.new;
%people\ . = Person\.new;
%cats\ . = Cat\ .new;
}
However, I'm really not looking to drive perl6-language round in circles, so if
there is some document somewhere explaining the rest of the several useful
side-effects I'd love a pointer to it (I couldn't find anything appropriate).
Otherwise I'll hope that, as has happened a number of times before, someone
will decide that this is too ugly to live and will create something nicer.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: RFC: Community education page
On Thu, May 04, 2006 at 03:59:47PM +0100, [EMAIL PROTECTED] wrote:
> but also people on the semi-inside, trying to remember things like
> "I'm sure there's a reason other then C<< if condition_without_parens
> {block} >> that we can't have C<< %foo {'bar'} >> DTRT, but I can't
> remember it", which certianly happens to me fairly often.
Well, I'd obviously quite like that ;-)
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: (Existing) Perl 6 Wiki: (http://perl.net.au/wiki/Perl_6).
G'day Conrad and P6ers, My apology for this being a very brief note. I'm on an interstate training assignment until the end of the week, and I'm scrounging net access where I can. Conrad Schneiker wrote: [snip] > Their posted policies, FAQ, and (http://perl.net.au/wiki/PerlNet:About), > seem to be very favorably inclined to serving the purposes of recent Perl 6 > Wiki proposals made on comp.perl6.lang and comp.perl6.users. (I've cc'd > their contact on this note.) As one of the PerlNet admins, I'd be delighted if PerlNet was used to assist in any Perl 6 development, discussions, or other activities. PerlNet exists to provide support for the Perl community, and if there's anything I can do to make it more suitable to help the Perl 6 effort, then I'd be very happy to do my best to make it happen. All the very best, Paul -- Paul Fenwick <[EMAIL PROTECTED]> | http://perltraining.com.au/ Director of Training | Ph: +61 3 9354 6001 Perl Training Australia| Fax: +61 3 9354 2681
Re: packages vs. classes
--- Stevan Little <[EMAIL PROTECTED]> wrote: > On 5/23/06, Sam Vilain <[EMAIL PROTECTED]> wrote: > > People can diverge completely with completely incompatible > > metaclasses that don't .do those roles, the only side effect > > of which being that people who write code for the standard > > Perl 6 metamodel will be incompatible, and maybe some ways > > of setting up the class won't work without another layer of > > trickery. I *think* that's what you're getting at. Of course, > > it shouldn't be prohibited just because it smells. > > I am not sure I like this, incompatible metaclass issues are really > really tricky and hard to debug (aka - smells *really* bad). And the > system needed to support them really can bloat the metamodel > internals in a nasty way. There are several papers out there on the > subject, none of which IMO provide a satisfactory solution. The > problem then becomes compounded by introducing the Python and Ruby > metamodels into the fray. Having a single compatability level made > out of roles is not that much of a restriction really, and keeps > much of the system interals clean and orderly. It also makes it > much easier for use to add new metamodels from other languages by > just by writing a layer to map to the core metamodel roles. I'd say a more standard system is much better, so long as we leave a standard set of hooks by which someone can insert a nonstandard setup. A small API isn't a huge bloat, and is worth it, though I agree that a full system might actually be counterproductive. And by all that I've seen lately, the whole language is pretty malleable that way; those who really want the nonstandard model can take the small overhead hit of whatever internal shenanigans they need to implement, and just about anything like that can be stuffed into a module now, can't it? So the upshot is, a standardized metamodel seems like the way to go to me And Congrats again, gramps. May your new little one be as loved as the language you've also labored so much to guide to maturity. >;o] Paul "on est aisément dupé par ce qu'on aime" -- Molière (one is easily fooled by that which one loves) "Increase in wisdom can be measured accurately by the corresponding decrease in anger." -- Friedrich Nietzsche "There are trivial truths and there are great Truths. The opposite of a trival truth is obviously false. The opposite of a great Truth is also true." -- Neils Bohr "Real friends are those whom, when you must inconvenience them, are bothered less by it than you are." -- me. =o) Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a thumb. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [perl #39217] [TODO] legal - eliminate "All Rights Reserved."
On Fri, May 26, 2006 at 01:57:40PM -0700, Allison Randal wrote: > >>Copyright notices should have the form: > >> > >> Copyright , The Perl Foundation. > > Whoops, typo, that's: > >Copyright (C) , The Perl Foundation. Are you sure? As I understand things, the symbol (C), that is the letter C in parentheses, has no legal bearing whatsoever. In general the word "Copyright" is sufficient for international copyright concerns, but if you want to add something else it should be the symbol ©, that is the letter C in a circle. Of course, I'm not a lawyer, but this is what they learned me at college. Though this was at about the same time as countries such as Mauritius, Liberia and the USA were becoming party to the Berne Convention, so maybe that changed things for the USA. I don't think this is the case though. Indeed, http://www.copyright.gov/circs/circ03.html only talks about: The symbol © (the letter C in a circle), or the word “Copyright,” or the abbreviation “Copr.” I wouldn't have said anything, but your correction seems to indicate that the (C) is important. Is my information outdated? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Introductions; P6 wiki
G'day Everyone, I'm very glad to have finally subscribed to the P6 users list after a couple of weeks of travel and intermittent network access, and so I apologise that this message may not be properly threaded. This is both a note of introduction and a few words on the recent discussion about the P6 wiki ideas. For those of you whom I have not yet had the pleasure of meeting, I run Perl Training Australia ( http://perltraining.com.au/ ), am the secretary of Melbourne Perl Mongers, and speak whenever I get the chance at many of the Australian conferences and user-groups. I'm regularly asked about Perl 6, and I often show it off to enthusiastic students during lunch breaks. I'm also one of the admins of PerlNet ( http://perl.net.au/ ), which brings us nicely to the talk of P6 wikis. I love the idea of the P6 wiki being written in P6, I think it's a fantastic idea. However I'm also aware that there are no P6 wiki implementations yet, and it will probably take some time to get one running. So can we have our cake and eat it too? I believe the answer is yes. I can't see any problems with using an existing wiki, be it Feather, or PerlNet, or any other wiki, with the intention to migrate the content to a P6-in-P6 wiki when such becomes available. The main thing to be careful of is ensuring that people are aware of the migration plans, and that there are no license problems. The last thing we want are social or legal barriers to migrating content. I do agree with Jured's sentiments that requiring the P6 wiki to support the kitchen sink will make migration more difficult, and so that simplicity in mark-up for any interim wiki is a good thing. In the meantime, if anyone does want to use perl.net.au for any P6 (or Perl in general), you should feel very encouraged to do so, even if it's with the intention of migrating that content in the future. Cheerio, Paul -- Paul Fenwick <[EMAIL PROTECTED]> | http://perltraining.com.au/ Director of Training | Ph: +61 3 9354 6001 Perl Training Australia| Fax: +61 3 9354 2681
P6U FAQ on PerlNet (was Re: $1,000 prize for Perl 6 Wiki written in Perl 6)
G'day Conrad, Amir, and P6U, Conrad Schneiker wrote: > I certainly agree. However, someone has to take the initiative to actually > start using (http://perl.net.au/wiki/Perl_6), and to post links back here > for others to follow up on. Will that person be you? :-) I'm all for using > that wiki to compile important Perl 6 content now, so that there will be > plenty of good material on hand for the (Perl 6)**2 Wiki. Working on that now. ;) > I'm long on enthusiasm, but very low on tuits at the moment (hence the > prize), but if someone ports the contents of > (www.athenalab.com/Perl_6_Users_FAQ.htm) to the above wiki, I'll replace the > above page with a "Perl 6 Users FAQ has become absorbed by a much better > Perl 6 wiki" link. Done! See http://perl.net.au/wiki/Perl_6_Users_FAQ . It's still a little rough at the moment, I'm working on fixing the remaining bits of poor mark-up, and improving inter and intra-document linkage. However don't let that stop you (or any P6U members) from adjusting the FAQ as required. Am I correct that the P6U FAQ can also be multi-licensed under the CC-Attribution-ShareAlike license, as well as the prevailing P6/Pugs license? Cheerio, Paul -- Paul Fenwick <[EMAIL PROTECTED]> | http://perltraining.com.au/ Director of Training | Ph: +61 3 9354 6001 Perl Training Australia| Fax: +61 3 9354 2681
Re: question about using "cover -ignore" and "cover -ignore_re"
On Mon, May 29, 2006 at 12:44:38PM -0700, Scott Wang wrote: > Hi, > > I was running Devel::Cover to gather code coverage > information for my ".pm" module files and I try to > "cover -ignore" or "cover -ignore_re" to screen out > coverage data for my test script ".pt" files and only > display coverage data for my ".pm" modules. But, > command does not prevent the > data for ".pt" files from being displayed on HTML > page. Ang thoughts and suggestion on how I should run > "cover -ignore" or "cover -ignore_re" to sreen out > data for my ".pt" tests. Yeah, um, er, cover -ignore doesn't really work all that well. I mean it sort of works and sort of doesn't depending on the report. It should really be fixed. Or, maybe, they should really be fixed. But in this case, I wouldn't expect it to work as you are expecting. says ignore any files called ".pt". I suspect you don't have any. says ignore any files matching /.pt/, which might be closer to what you want, and I would expect that to have some effect at least. But in general it is much better to ignore modules whilst gathering coverage. This has the added bonuses of making the whole thing quicker, using less space, and mostly working. So something like perl -MDevel::Cover=+ignore,\\.pt$ ... might be what you are really looking for. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Info from Devel::Cover
On Thu, May 11, 2006 at 11:57:44AM +1000, Kirrily Robert wrote:
> I've got a guy at work who wants to take coverage reports and bung
> them in a database so he can track historical coverage data. As I
> see it, he needs to somehow parse the stuff in cover_db/ but neither
> he nor I understand what's in there. Do any modules already exist
> for this? I believe the thing that generates the coverage reports
> currently is C code or something? So isn't there anything CPANish to
> do this?
We discussed this question on IRC, but it was 4am for me and I was not long
back from a reasonably long day at work so, although I think the advice I gave
was sound, it may be worth expanding on it here. This message was almost
finished when my router crashed, and when I got home I forgot to finish it, so
apologies for the delay.
First, there's no need to delve into C to access the coverage data. The
required API is in Devel::Cover::DB. The documentation in there is
somewhat sparse, but covers the basics.
The easiest thing to do is probably to look at one of the existing
reports and copy it. I would suggest the textual report as being the
simplest to follow. That is found in Devel::Cover::Report::Text.
With respect to the infrastructure required, I would suggest making your
code a report and using the "cover" program to call it. If you make
your code Devel::Cover::Report::Filldb for example, and put it somewhere
where perl can find it, then calling "cover -report filldb" will call
your report.
For example, here is the report subroutine fro the text report.
sub report
{
my ($pkg, $db, $options) = @_;
print_runs($db, $options);
for my $file (@{$options->{file}})
{
print_file ($db, $file, $options);
print_branches ($db, $file, $options) if $options->{show}{branch};
print_conditions ($db, $file, $options) if $options->{show}{condition};
print_subroutines($db, $file, $options) if $options->{show}{subroutine};
}
}
>From here you should be able to access any information you need.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: More - Re: question about using "cover -ignore" and "cover -ignore_re"
On Mon, May 29, 2006 at 03:31:19PM -0700, Scott Wang wrote: > "-MDevel::Cover=+ignore,\\.pt$ ..." really helps! > > If I want to use Devel::Cover module in my code and > not from commandline, say I would like to use "use > Devel::Cover;" in code, what I should add after "use > Devel::Cover" to make it works as > "-MDevel::Cover=+ignore,\\.pt$ ...". I think that "use Devel::Cover qw( +ignore .pt$ );" should do that. See -M in perldoc perlrun. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Synchronized / Thread syntax in Perl 6
How about one of these?
==
class Baz {
has $.a is restricted;
has $.b is controlled;
has $.c is unique;
has $.d is shared;
has $.e is queued;
has $.f is token;
...
}
--- John Drago <[EMAIL PROTECTED]> wrote:
> I asked this via the Google Groups interface a few weeks ago, but I'm
> not sure if it made it here.
> I am asking again in case the question never made it onto the list.
>
> Has the syntax for synchronized/threaded @things been worked out?
> For example:
>
> class Foo is synchronized {
> ...
> }
>
> our method Bar is synchronized {
> ...
> }
>
> class Baz {
> has $.Bux is synchronized;
> }
>
> ...or is there some new, less Java-esque way to express "only one
> thread may access this thing at a time"?
>
>
>
>
> John Drago | VP Software Engineering
> [EMAIL PROTECTED]
> www.precissystems.com
>
>
>
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
RE: Synchronized / Thread syntax in Perl 6
--- John Drago <[EMAIL PROTECTED]> wrote:
> James Mastros wrote:
> > I don't like the name synchronized -- it implies that multiple
> > things are happening at the same time, as in synchronized swiming,
> > which is exactly the opposite of what should be implied.
> > "Serialized" would be a nice name, except it implies serializing
> > to a serial format, like disk. "Locked" is the best name I can
> > think of, and it frankly isn't that good -- it's so vauge as to
> > be able to mean almost anything.
> > . . .
>
> Agreed - maybe "is serial" instead, which suggests "is parallel"
> would be its implicit counterpart.
You mean "is parallel" as a synonym for "is async"? I actually like it
better, but that's just me.
> If we have a situation that looks like this:
>
> our method TakesForever ( int $num is serial ) is async {
> # Do something that takes a long time...then:
> $num++;
> # $num has not been changed by anything else that might
> # have access to $num.
> }
>
> my $age = 27;
> TakesForever( $age );
> $age += 20; # Fails somehow, because &TakesForever is working on $num
Hmm
Is "fails somehow" the default?
I was thinking the better default would be more like standard
threading.
If $age has been passed to an asynchronous closure, it should be marked
as locked, and other threads trying to access it would have to get a
lock first. Yes, lots of overhead but that way if the default is
WAIT (which seems the smart default to me), the thread waits until
TakesForever() releases the resource.
if we declare
our method TakesForever ( int $num is serial ) is async but NOWAIT {
...
}
or
my $age = 27 but NOWAIT;
or
TakesForever( $age but NOWAIT );
(or whatever) then I'd say it should just fail. I mean, isn't that kind
of the idea, to have that sort of flexibility?
> Maybe a better example is needed - this one is pretty contrived.
I dunno. It gets a point across.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
RE: Synchronized / Thread syntax in Perl 6
--- John Drago <[EMAIL PROTECTED]> wrote:
> > You mean "is parallel" as a synonym for "is async"?
>
> I think "is parallel" denotes something as usable by multiple threads
> simultaneously, "in parallel".
> "is serial" would denote that only one thread can use the $thing at a
> time, exclusively.
Are you saying both are asynchronous, but one specifies that a resource
should be locked rather than duplicated?
> . . .
> > If $age has been passed to an asynchronous closure, it should be
> > marked as locked, and other threads trying to access it would have
> > to get a lock first. Yes, lots of overhead but that way if the
> > default is WAIT (which seems the smart default to me), the thread
> > waits until TakesForever() releases the resource.
In that light, responding to my own comment, you could infer that you
should lock anything passed by reference, and not worry about it if
passed by value unless you said "$age is locked" or "is serial" or
whatever, yes?
> > if we declare
> >
> > our method TakesForever ( int $num is serial ) is async but NOWAIT
> {
> >...
> > }
> >
> > or
> >
> > my $age = 27 but NOWAIT;
> >
> > or
> >
> > TakesForever( $age but NOWAIT );
> >
> > (or whatever) then I'd say it should just fail. I mean, isn't that
> kind
> > of the idea, to have that sort of flexibility?
> >
>
> Perhaps some more syntax-play is in order here.
lol -- yeah. :)
> One thing about threading with Perl5 is that it is easy to write a
> simple threaded program that is entirely opaque - unless you
> wrote the program yourself.
>
> The program below gets a list of coderefs and executes each one, then
> returns the result.
> #
> (Using the threads.pm way...)
> package QueueRunner;
>
> use strict;
> use threads;
> use threads::shared;
>
> sub process_job_queue
> {
> my ($s, @jobs_in) = @_;
> my @results : shared = ();
> my @workers = ();
>
> push @workers, async { push( @results, $_->() ) } foreach @jobs_in;
> $_->join foreach @workers;
> return @results;
> }# end process_job_queue()
>
> # Elsewhere...
> package main;
>
> my @answer = QueueRunner->process_job_queue( \&job1, \&job2, \&job3
> );
>
> #
> And my attempt at the same, using Perl6:
> #
>
> class QueueRunner {
> our sub process_job_queue( Code @jobs_in ) returns List of Any {
> my Any @results is parallel;
> my Thread @workers = ();
>
> for @jobs_in {
> @workers.push( async { &_() } );
> }
> for @workers {
> @results.push( $_.join() );
> }
>
> return @results;
> }# end process_job_queue()
> }# end QueueRunner
>
> # Elsewhere...
> my @answer = QueueRunner.process_job_queue( @jobs );
>
> #
>
> I made absolutely no progress here. It seems to me that it's no more
> obvious what's going on here than in the Perl5 version. Any
> comments?
>
> Regards,
> John Drago
Hm. If we're using *implicit* threads (which I thought was the point),
how about
class QueueRunner {
our sub process_queue(Code @jobs_in) {
my @ans is serial;
@ans.push map { async { &_() } } @jobs_in;
@ans;
}
}# end QueueRunner
# Elsewhere...
my @answer = QueueRunner.process_job_queue( @jobs );
The point is that the call to async() is supposed to handle the thread
management for you, isn't it?
Though if that works, you could squish this example even more, to
class QueueRunner {
our sub process_queue(Code @jobs_in) {
map { async { &_() } } @jobs_in;
}
}# end QueueRunner
# Elsewhere...
my @answer = QueueRunner.process_job_queue( @jobs );
and the issues of serialization are hidden in the map() call. For all
that
my @answer = map { async { &_() } } @jobs;
though that gets away from the point.
Someone smack me if I'm drifting too far here?
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
RE: Synchronized / Thread syntax in Perl 6
--- John Drago <[EMAIL PROTECTED]> wrote:
. . .
> > class QueueRunner {
> >our sub process_queue(Code @jobs_in) {
> > my @ans is serial;
> > @ans.push map { async { &_() } } @jobs_in;
> > @ans;
> >}
> > }
> > my @answer = QueueRunner.process_job_queue( @jobs );
>
> Actually I think you did it just right.
> I think that horse is dead now.
LOL!! I'm flattered. =o)
> So, what about "serial" classes and methods?:
>
> # Does marking this class "is serial" mean it's forced to be a
> singleton?
Hmm I wouldn't think so. You should still be able to spawn object
instances, but I'd say it scopes the lock to the whole class, so that
everything in that container is locked any time anything in the class
in accessed. It's a cheap way to make all shared resources queue up
nicely, if you just want a quick and dirty script instead of something
well streamlined. Kind of like locking at the DB or table level instead
of just the row, but there are times when that's what you need.
. . .
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Synchronized / Thread syntax in Perl 6
--- Ashley Winters <[EMAIL PROTECTED]> wrote:
> On 6/2/06, Paul Hodges <[EMAIL PROTECTED]> wrote:
> >
> > my @answer = map { async { &_() } } @jobs;
>
> That still seems too explicit. I thought we had hyperoperators to
> implictly parallelize for us:
>
> my @answer = @jobs.»();
>
> Which would run them in parallel automatically, if possible.
Snazzy bit of syntactic shenanigans, that...and slick, if we're in that
mode, but just to clarify, I *will* still be able to know whether or
not something's going to thread? Or will it matter?
Seems to me there will be times when I WANT a purely single-threaded
system, even if I'm using hyperops -- in fact, especially if I'm using
hyperops. Maybe we need a pragma to be able to step in and out as
needed?
{ no threads;
print @_.»();
}
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Synchronized / Thread syntax in Perl 6
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 03, 2006 at 03:51:45PM -0700, Paul Hodges wrote:
> : { no threads;
> :print @_.»();
> : }
>
> It seems a bit odd to use a construct for its syntactic sugar value
> but take away its semantics...
>
> If you just need ordering, this (or something like it) should
> serialize it:
>
>print $_.() for @_;
>
> Larry
LOL -- and "d'oh".
Apologies, not enough sleep.
I stand corrupted. :o]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Devel::Cover and HTML::Mason
On Sat, Jun 03, 2006 at 10:18:46PM -0500, jason gessner wrote:
> Hi All.
>
> Has anyone successfully used Devel::Cover under mod_perl to do
> coverage for a mason application?
>
> My preliminary experiments were mixed. I used D::C from my .pl
> handler file and ran apache with -X, but saw inconsistent results
> when i did a couple tests.
>
> During the first test, it showed some of the files i had accessed,
> but showed no code executed for them. On the second test (second
> test being the same thing, but after restarting apache again and
> deleting the coverage db), i only saw code referenced by my handler.
>
> Google searches have turned up nada so far.
>
> Has anyone done this before i figure out how to do it?
Devel::Cover should work under mod_perl. I have used it successfully
with the Template Toolkit, but I am not a Mason user and I don't recall
any previous reports of success or otherwise with Mason.
I suggest using Devel::Cover from your mod_perl startup script (see the
docs). You might like to check that $ENV{MOD_PERL} is being set. IIRC
it should be set to 1 under mp1 and 2 under mp2.
When Mason works with Perl code, does it manage __LINE__ and __FILE__
correctly? If so, then Devel::Cover should report coverage at the
correct place. You can probably assume this is OK if error messages
from your template point you to the code correctly.
If you still have problems you might need to come back with a bit more
information.
Good luck.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Error Message "Magic number checking on storable file..." when running "cover" to merge data
On Mon, Jun 05, 2006 at 08:13:38PM -0700, Scott Wang wrote: > Hi All, > > I got below error message from running "cover" to > merge my coverage data, any clue? The "Magic number > checking on storable file ..." message also shows up > in my test log, I am wondering if this means that my > coverage database has corrupted somehow. > > = > Reading database from ... > Magic number checking on storable file failed at > ../../lib/Storable.pm (autosplit into > ../../lib/auto/Storable/_retrieve.al) line 331, at > Devel/Cover/DB/Structure.pm line 269 > = I think so. Perhaps nothing was written to the database at all? $ perl -MStorable -e 'retrieve "/dev/null"' Magic number checking on storable file failed at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/_retrieve.al) line 331, at -e line 1 -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Question - (1) Devel:;Cover and B::Deparse issue (2) "cover" and its momory consuming issue
On Sat, Jun 03, 2006 at 08:29:09PM -0700, Scott Wang wrote: > Thanks!...Scott Does this mean everything is working OK for you? "Deep recursion on subroutine" is just a warning, though Devel::Cover seems to tickle it through B::Deparse fairly regularly. I'll try to do something about that one way or another. B::Deparse is used to display the code used in branches and conditions, and also as a handy tool for walking through a complete optree doing stuff at each op. With respect to "cover" using a lot of memory, yes, I'm afraid that could happen with large databases. The reason is that the database is read into a perl data structure. (The "database" is really little more than a Storable dump of a Devel::Cover::DB object.) I'm afraid that the pragmatic approach its probably to throw RAM at the hardware. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Question - (1) Devel:;Cover and B::Deparse issue (2) "cover" and its momory consuming issue
On Sat, Jun 10, 2006 at 07:54:28PM -0700, Scott Wang wrote: > Hi Paul, > > Thanks a lot for your reply! > > After I turned off warning in all my product scripts > and test scripts which I was running Devel::Cover on, > 90% warning messages related B::Deparse deep recursion > have gone, and only a few were left in logs. So, from > your email, seems like, in order to completely remove > those B::Deparse deep recursion warnings from my test > log, I should also add "no warnings" in Devel::Cover > code to customize this model and disable warning in > it, please advice if my understanding and approach is > right or not. If this works then that's fine. You can probably be a bit more specific with 'no warnings "recursion"', but as I say, it is only a warning. I should sort it out in the Devel::Cover code itself at some point. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Couldn't understand the following message from Devel::Cover ...
On Fri, Jun 16, 2006 at 12:43:11PM +0530, Rajanikanth Dandamudi wrote:
> Hi All,
>
> Can some one help me understand why I am getting the following message
> on the following perl program :
>
> perl program
>
> #!/usr/local/bin/perl
>
> %hsh = (
> ABC => -abc,
> DEF => -def,
>);
>
> for $key (keys %hsh){
> print "Key = $key Value = $hsh{$key}\n";
> }
> =
>
> command used : perl -MDevel::Cover
>
> output:
> ===
> Devel::Cover 0.55: Collecting coverage data for branch, condition,
> statement, subroutine and time.
> Pod coverage is unvailable. Please install Pod::Coverage from CPAN.
> Selecting packages matching:
> Ignoring packages matching:
> /Devel/Cover[./]
> Ignoring packages in:
> .
> /proj/dite/WorkArea/Raja/perl/lib
> /proj/dite/WorkArea/Raja/perl/lib/5.8.8
> /proj/dite/WorkArea/Raja/perl/lib/5.8.8/i686-linux
> /proj/dite/WorkArea/Raja/perl/lib/site_perl
> /proj/dite/WorkArea/Raja/perl/lib/site_perl/5.8.8
> /proj/dite/WorkArea/Raja/perl/lib/site_perl/5.8.8/i686-linux
> Key = ABC Value = -abc
> Key = DEF Value = -def
> Devel::Cover: Can't find file "../../lib/Storable.pm": ignored.
> Devel::Cover: Writing coverage database to
> /sp/dftm/Activities/MemoryBIST/pbist/flow/data/cover_db/runs/1150441786.22790.00593
> --- -- -- -- -- --
> --
> File stmt bran condsub time
> total
> --- -- -- -- -- --
> --
> ...6905/LearnPerl/Hash_Example_2.pl 100.0n/an/an/a 100.0
> 100.0
> Total100.0n/an/an/a 100.0
> 100.0
> --- -- -- -- -- --
> --
> =
>
> I couldn't understand what the following message means :
>
> Devel::Cover: Can't find file "../../lib/Storable.pm": ignored.
>
> Even though this is being ignored here, this is causing problems down
> the line. Can you help me on what this means and how to overcome this ?
What it means is that when Devel::Cover went to examine all the data it
had collected and map it back to reality, it went looking for the source
code to Storable. When perl first loaded Storable it was found in the
relative directory "../../lib/Storable.pm". What that was relative to,
we don't really know. Perl doesn't store that information.
Devel::Cover tries very hard to find that information (I won't go into
the details, but it is messy), but doesn't always succeed. In
particular, this warning is fairly common, and I haven't been able to
track it down, though I suspect it has something to do with Storable
being used by Devel::Cover itself and so it is loaded before
Devel::Cover's hacks get a chance to kick in.
What this means in practice is that you won't get a coverage report for
Storable. But it's pretty unlikely you wanted one anyway, so this
shouldn't be a great problem. So I am interested in what problems this
causes down the line. To stop the warning I suggest the following
options:
1. Fix Devel::Cover. Go on, please. You know you want to ;-)
2. Hack the source to disable the warning.
3. Filter the output.
4. Pretend you didn't see it.
Most people take the fourth option since it really shouldn't cause any
further problems.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Error Message "Magic number checking on storable file..." when running "cover" to merge data
On Sat, Jun 10, 2006 at 08:14:09PM -0700, Scott Wang wrote: > Hi Paul, > > You are right, I found a 0 size file under the > "cover_db/structure" folder. After I removed that 0 > size file, my "cover" worked fine to merge all the > data and generated HTML file. > > The 0 size file, I think, is because some test was > killed for timeout because of the slow-down of the > test process since we instrumented all test and > product scripts with Devel::Cover. When the test > process was killed and terminated abnormal, I think, > Devel::Cover was still trying to grab the test process > to generate data, so there was no any data actually > got generated because the test processes had been > killed. Is this a reasonable explaination to the 0 > size data file? It sounds plausible, but there could be any number of reasons. Perhaps the file system filled up, or you have some rogue process running around truncating Devel::Cover databases. But the test process being killed probably has something to do with it. The files in the structure directory contain information about the structure of files. That is, the statements, branches and conditions in the file, and other similar data. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Can foo("123") dispatch to foo(Int) (was: Mutil Method Questions)
so back to foo("bar"). What's the default behavior? String doesn't Num,
does it? though is does convert if the value is good
Does that mean foo("123") should or should not dispatch to foo(Int)?
Or even foo(Num), for that matter Oy, I could see some headaches
around setting these rules in mind, lol What's the DWIMmiest
behavior hear?
I assume foo(1) would dispatch to foo(Int) rather than foo(Num), as the
most restrictive fit, and I could see how that could blow up in my
face. Is there some basic compile time warning (and a way to tell it
"shut up, I know what I'm doing") that says "hey, these are
suspiciously close signatures, are you sure this is what you wanted?"
Is the difference that foo("123") can be easily converted to foo(123)
without data loss, whereas foo("bar") to foo(0) cannot?
--- Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 23, 2006 at 09:11:44PM +0300, Markus Laire wrote:
> > And what about other types?
> > e.g. if String can't ever be "best candidate" for Int,
> > then does that mean that neither can Int ever be "best candidate"
> > for Num, because they are different types?
>
> Well, I think Num and Int *aren't* different types because as far as
> duck typing goes, Num does Int. I wouldn't expect that String does
> Int though (at least not without some help :).
>
> The way I see it, the types specified in the signature are like
> constraints. When you say
>
> sub foo (Num) { ... }
>
> the signature says that "only an item that can perform the Num role
> may fit in this slot". When perl tries to match Capture to Signature,
> it checks the type of each argument in the Capture against the
> "does list" for each parameter in the Signature. If the argument
> type appears in the "does list" of the Signature, then it's a match
> and all is well. Otherwise it's an error. Since "Num does Int",
> a call such as C succeeds.
>
> At least that's my vague interpretation of this aspect of perl6 at
> this moment. :-)
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Using Rules Today
> In any case, I was wondering if someone could provide me with an example of
> a mathematical expression parser (and evaluator).
> To properly compare to the others, it would need to handle the following
> operators
>
> +, - (left associative)
> *, /, % (left associative)
> ^ (right associative)
>
> handle parens 12 - (3 + 4)
>
> handle two functions sqrt() and abs() both of which must include the
> parens.
>
> If someone has time to do this for me, I would be appreciative. It might
> also serve as example documentation or cookbook ideas.
>
> I am specifically interested in examples that can be run in Perl 5 today
> without needing Pugs or Parrot.
It isn't specifically a parser designed for general language parsing, but
CGI::Ex::Template does have a mathematical expression parser. The parser is
located near the end of the parse_expr method. The output of the parse_expr
is an opcode data structure that can be played out through the play_expr
method.
The basic functionality is that a chain of operators is tokenized into a
single array. The apply_precedence method is then used to split the array
into the optree based upon the precedence and associativity of the operators.
The following is a sampling of the resulting "optrees" for the given
expressions (taken from the perldoc):
1 + 2 => [ \ [ '+', 1, 2 ], 0]
a + b => [ \ [ '+', ['a', 0], ['b', 0] ], 0 ]
a * (b + c) => [ \ [ '*', ['a', 0], [ \ ['+', ['b', 0], ['c', 0]], 0 ]],
0 ]
(a + b) => [ \ [ '+', ['a', 0], ['b', 0] ]], 0 ]
(a + b) * c => [ \ [ '*', [ \ [ '+', ['a', 0], ['b', 0] ], 0 ], ['c',
0] ], 0 ]
perl -e 'use CGI::Ex::Template; $s=CGI::Ex::Template::dump_parse("3 * 4 ** 2 +
5"); $s =~ s/\s+/ /g; print "$s\n"'
$VAR1 = [ \[ '+', [ \[ '*', '3', [ \[ '**', '4', '2' ], 0 ] ], 0 ], '5' ],
0 ];
I apologize that the expression parsing isn't a little more abstracted for
you, but the result should be usable. Also, the parse_expr is designed for
also parsing variable names in the TT2 language, so the first portion of the
method applies variable names. The entire thing could be cut down
considerably if all you want to parse is math (no variables).
Paul Seamons
Re: Any Clue about Devel::Cover Error Message "Corrupted storable file (binary v2.7) at ../../lib/Storable.pm"
On Fri, Jul 07, 2006 at 10:26:13AM -0700, Scott Wang wrote: > Hi Paul, > > Even, currently, there is no any zero size data file > in structure folder in my regression code coverage run > (lots of suites), I still got lots of messages like > below: > --- > Corrupted storable file (binary v2.7) at > ../../lib/Storable.pm (autosplit into > ../../lib/auto/Storable/_retrieve.al) line 331, at > //Devel/Cover/DB/Structure.pm line 269 > END failed--call queue aborted. > - > Seems some data files got corrupted somehow. > > The process killing (kill parent process before > killing child process and make chid process be > terminated abnormally) is one possibility, I also > noticed that useing system or other folk method to > execute command could also cause this problem. > > Any clue about above issue "Corrupted storable file > (binary v2.7) at ..." and does anybody also experience > this issue and know how to deal with it? > > Also, does anybody have similar experience on killing > process and folking process cause "Magic number ..." > issue and "orrupted storable file ..." issue? In lieu of discussing either licences or alligators, let me try to answer this. Killing the process sounds like the most likely cause of this problem. If you manage to kill the process while it is writing out a storable file the file will very probably be corrupted. How are you killing the process? Are you sending it SIGKILL (9) for example? Maybe you could send it something a little nicer which might allow to process to clean up. Devel::Cover does its work in the very last END block. You really need to let it run to completion. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
