Re: use of ::?CLASS
HaloO, John M. Dlugosz wrote: I do see that the use in a role is like a generic. But you would use the sigil every time, e.g. method doit (::?CLASS $self: ::?CLASS $other --> ::?CLASS) that is not three separate generics with conflicting names, but the same thing. With generics you can only use the sigil on the first use. You are right and I didn't address this, sorry. Actually the only solution I see is dropping the ::? twigil altogether and specify that CLASS is lexically declared by the compiler. Otherwise we have to make a special case exception out of ::? variables. That is all methods in a role are parametric on ::?CLASS just as all methods in a class are parametric on ::?SELF class B is A; instanciates a new type &doit:(B $self: $a, $b, $c). This nicely But doit is not a type. I think you were talking something like that earlier and I didn't follow. It is an arrow type, like foo: Int --> Int and bar: Int --> Int. These are structurally identical. The fun thing is that the Perl 6 type system is supposed to be nominal. Thus foo and bar are different types. But contradictory to that you can use foo and bar wherever an Int --> Int is expected. I love this self contradiction of Perl ;) Well, and you can't neither use foo nor bar to denote the arrow type. Note that I consider myself a knowledgeable bystander with the knowledgeable being debatable ;) Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
Re: Context and return types question
HaloO, Larry Wall wrote: In general, we're trying to get away from want-based context dependency and instead attempting to encourage lazy semantic constructs such as Captures that can behave with a wide dynamic range when actually bound later. Shouldn't we then change the heading of the respective section from "Advanced Subroutine Features" to "Deprecated Subroutine Features"? For instance, Arrays now behave such that, if you use one in numeric context, you get the number of elements, so unlike in Perl 5, you need not decide at return time whether the array is in item or list context. You just return the array, and it will act much like it does in Perl 5 if you use it in a numeric or boolean context. Since the default return type is Capture, it doesn't matter if you declare the "of" type as Array or not, since the Capture doesn't force either item or list context on the Array either. It should behave much the same in either case, except that if you declare the "of" type as Array, you give the compiler/optimizer/type inferencer more information to work with at compile time. Note that this implies Seq <: Num <: Item <: Seq which is a cycle! Dealing with cycles is not within the reach of type system because these need <: to be transitive. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
Re: Context and return types question
HaloO,
John M. Dlugosz wrote:
How about sub foo (--> Seq^Item) {...}?
Interesting idea, but that doesn't tell the compiler that the return is
keyed to the context. The compiler should know what return type to
expect, if only I could explain it.
Sorry, the type has nothing to do with how the function comes up with
its return value. In that respect you must regard the context as part
of the input of the function that of course influences its output.
I don't see how Seq^Item as a type is any different than Seq|Item. It
can only hold one at a time anyway.
A type is a type. There is nothing that varies or holds a value or some
such. Seq|Item means to me that there are three cases: Seq only, Item
only and both. Seq^Item excludes the latter. That is Seq^Item is the
disjoint union of Seq and Item. Larry's reply essentially means
Item <: Seq that is Seq subsumes Item. But that has problems of its
own---see my reply there.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
Re: Are coroutines still there?
HaloO, Larry Wall wrote: That is, coro and loop tend to violate single-assignment semantics, and single-assignment semantics are easier to map into functional semantics. So if we do allow coro in Perl 6, it'll probably be a second-class citizen like loop and goto and die (and anything else considered harmful but useful). But I don't see much use for it offhand. Does that imply that multiple assignment is second-class, too? And that with a language that provides the concept of eternal equality with ===, or checking of referential identity with =:=. Big surprise that is. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
Re: Context and return types question
HaloO,
John M. Dlugosz wrote:
Great. So the flip side is, what do I return from a function so that it
gives a single value if called simply, but provides optional named
returns that are there if you catch them? As a capture with one
positional and one named argument?
Yeah, just that.
And how do you declare =that= return type ("of" type) to be strongly typed?
I guess with strong you mean as lossless as possible?
I think the type is just :( $: :named$ ) if you want to extract the
invocant with a $ prefix. Otherwise it would be :( $, :named$ ) and you
extract the item positionally with prefix @ or .[]. Note that Captures
are immutable and therefore nicely covariant. Except of course that
containers are captured as containers and can be mutated. But Larry
revealed that single assignment semantics are aspired and mutability
is a historic artifact or so.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
Re: method hiding (or not) in derived classes
HaloO, John M. Dlugosz wrote: Perl 6 has a concept of a "candidate list". The candidate list are those that could handle the call, typically inherited methods and multi variations. "Candidate set" would be a better term. It is a subset of all long names of a multi in a lexical scope. It seems that multi variations, at least with respect to the semicolon parameters, compare the actual type and drop out of the list if any don't match. I'm not sure what you are asking. But if a candidate is applicable it competes with the other candidates for specificity. That is what the semicolons are for. And even if a candidate is voted out it still can vote out others. What about ordinary methods (and ordinary parameters of multis)? Does the candidate list hold every method name that matches, or does it do simpler parameter matching based on number of arguments, required named arguments, etc.? There is hopefully a complete specification what constitutes applicability. There can hardly be differing simpler versions. In other words there is only one subtype relation that is used whenever a binding takes place. If that is the case, then a derived method might not hide a base class method if the parameter list is seriously incompatible. That is a natural and welcome consequence of type based dispatch. Classes are for implementation sharing, not for transitive typing. More interestingly, left-to-right ordering of multiply-inherited base classes will be checked for applicability rather than arbitrarily taking the leftmost. Indeed, I would hope that order of inheritance doesn't matter. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
Re: progress report
"John M. Dlugosz" and I have both replied to "whiteringmoon"'s query, so I don't think anyone else need to. (If he's genuine, we don't want to bombard him with multiple replies, and if not, let's not give out too much spambait.) -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
[perl #53120] Re: [TODO] config/auto/perldoc.pm: Recent change needs discussion
# New Ticket Created by François PERRAD
# Please include the string: [perl #53120]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53120 >
2008/4/20 James E Keenan <[EMAIL PROTECTED]>:
> This morning I noticed that the following change had been made to
> config/auto/perldoc.pm:
>
> $ svn diff -r {2008-04-19} config/auto/perldoc.pm
> Index: config/auto/perldoc.pm
> ===
> --- config/auto/perldoc.pm (revision 27027)
> +++ config/auto/perldoc.pm (working copy)
> @@ -36,7 +36,7 @@
> sub runstep {
> my ( $self, $conf ) = @_;
>
> -my $cmd = $conf->data->get_p5('scriptdirexp') . q{/perldoc};
> +my $cmd = q{perldoc};
> my $tmpfile = q{c99da7c4.tmp};
> my $content = capture_output("$cmd -ud $tmpfile perldoc") || undef;
>
>
> The log message associated with this commit presented its rationale:
>
>
> r27056 | fperrad | 2008-04-20 05:57:41 -0400 (Sun, 20 Apr 2008) | 3 lines
>
> [perldoc]
> - fix with strawberry Perl 5.10.0
>
>
> However, IMO it would have been preferable to present this issue in an RT
> [BUG] ticket first. As it stands, I have no idea as to the particular
> problem which François found with this config step on Strawberry Perl. More
> importantly, the patch essentially undoes this patch which Mark Glines
> committed a month ago:
>
>
>
> r26513 | infinoid | 2008-03-21 16:24:58 -0400 (Fri, 21 Mar 2008) | 9 lines
>
> [config] perldoc check should use $Config{scriptdirexp}, not
> $Config{scriptdir}. The "scriptdir" value from p5 is sometimes interpreted
> in strange ways, but the "scriptdirexp" value is expanded at compile-time,
> so it's guaranteed to be sane.
>
> Grep perl-5.10.0's perldelta.pod for "Relocatable installations" for
> details. This was preventing "perldoc" from being detected properly on a
> local install of perl. wolverian++ for reporting it.
>
>
>
> I don't know the entire history of this config step or of Parrot's
> configuration in general. But I do know that we draw many of our
> configuration settings from the Perl 5 Config module found on the box
> attempting configuration of Parrot. I also know that we have developers who
> have multiple Perls on their machine, hence have multiple 'perldoc's on
> their machine. In the past, at least, it has been important to know which
> 'perldoc' is being referenced.
>
> So, while this fix might be good for Strawberry Perl, there's a good
> chance it will break someone else's Parrot configuration.
>
> François, can you present the problem in this ticket?
premature commit (bad simplification).
sorry, reverted by r27062.
François.
>
> Mark, can you evaluate impact?
>
> Thank you very much.
>
> kid51
>
>
Parrot Bug Summary
Parrot Bug Summary
http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Mon Apr 21 13:00:02 2008 GMT
---
* Numbers
* New Issues
* Overview of Open Issues
* Ticket Status By Version
* Requestors with most open tickets
---
Numbers
Ticket Counts: 55 new + 725 open = 780
Created this week: 35
Closed this week: 32
---
New Issues
New issues that have not been responded to yet
1 - 2 weeks old
52876 Re: [bug] Build failure with G++
52870 [PATCH] README_cygwin.pod update
2 - 3 weeks old
52396 [BUG] Test 1 of t/pmc/io.t sigbus on ppc
3 - 4 weeks old
52204 [BUG]: Parrot build failure on parisc64 GNU/Linux
4 - 5 weeks old
5 - 6 weeks old
51634 [BUG] docs/parrotbyte.pod && docs/pdds/pdd13_bytecode.pod are either
incorrect/unclear
6 - 7 weeks old
7 - 8 weeks old
51350 [PATCH] correction and extension of the pair implementation
51330 [TODO] dynext - dll versioning
51206 [BUG] Tail call into PIR compiler broken?
8 - 9 weeks old
9 - 10 weeks old
50894 [BUG] parrot -O Fails Tests
10 - 11 weeks old
50642 [CAGE] refactor init_class_from_hash & parrot_class_register
11 - 12 weeks old
50500 [PROPOSAL][PAST] add PAST::Var :scope('attribute')
50448 [Memory Leak] IMCC Can Leak Lexer Data on Exception
50360 [RFE] Redesign Parrot NCI callback functionality
12 - 13 weeks old
50090 [TODO] pge - throw useful exception on non-quoted non-word characters
13 - 14 weeks old
49970 [BUG] -O1 and -O2 don't turn on -Ot as per docs
49968 [BUG] 'parrot -O2 oofib.pir' errors out, when -O1 succeeds
49966 [BUG] parrot -v -O2 segfaults, when -v and -O2 separately both work
14 - 15 weeks old
15 - 16 weeks old
49258 [BUG] Parrot::Test with --run-exec assumes "." is in $PATH
16 - 17 weeks old
49177 [TODO] pct - PAST::Val node should throw exception if :value attribute
not set
17 - 18 weeks old
49001 [PROPOSAL][DOCS] Change word "compilation_unit" into something else (like
"sub")
48877 [TODO] Don't generate .constant declarations for vtable method names.
18 - 19 weeks old
48749 [BUG] t/examples/tutorial.t if_unless failure (Win32)
48645 [CAGE] Make PMCs depend on Parrot::Pmc2c::* Modules
48507 [BUG] oo - n_add, n_sub, etc. don't work with objects
48467 [BUG] assignment of objects creates Ref instead of copy
19 - 20 weeks old
48367 [BUG] intlist_get could be dereferencing NULL
48150 [DOCS] pdd23 doesn't document obtaining thrown exception object
20 - 21 weeks old
48034 [BUG] examples/streams/Bytes.pir runtime error
47992 [RFE] 'parrot foo' automatically finds and invokes foo.pbc
47974 [DOCS] What are valid characteristics for 'inspect_str' vtable
47966 [DOCS] pdd23 doesn't list exception;death as a standard exception
47940 [CAGE] mk_native_pbc stale
---
Overview of Open Issues
PlatformSeverity Tag Lang
aix0abandoned 0 5005threads 0 Amber0
All1fatal 2 bounce0 BASIC0
bsdos 0High 0 Bug 84 bc 0
cygwin 2low 1 compiler 0 befunge 0
cygwin_nt 0medium0 configure 3 bf 0
darwin10none 1 core 4 cola 0
dec_osf0Normal2 dailybuild0 forth0
dgux 0unknown 0 docs 3 jako 0
dos0Wishlist 3 duplicate 0 Lisp 0
dynixptx 0 install 2 lolcode 0
freebsd8 library 0 m4 0
generic0 notabug 0 ook 0
gnu0 notok 0 perl61
HPUX 2 ok0 plot 0
irix 0 Patch30 punie0
irix64 0 regex 2 pynie0
Linux 3 sendToCPAN0 python 0
lynxos 0 Todo438 ruby 0
mac0 unknown 0 scheme 0
machten0 utilities 0 tcl 65
macos 0 wontfix 0 urm 0
MacOS X8 Zcode0
mswin320
netbsd 1
next 0
openbsd2
os20
os390 0
other 0
powerux0
qnx0
riscos 0
sco0
Solaris4
sunos 1
svr4 0
svr5 0
sysv 0
unicos 0
unicosmk 0
unix 0
unknown0
uts0
vms
Re: Are coroutines still there?
? Multiple-assignment second-class? I don't see how you get that out of Larry's message... On 4/21/08, TSa <[EMAIL PROTECTED]> wrote: > HaloO, > > Larry Wall wrote: > > That is, coro and loop tend to violate single-assignment semantics, and > > single-assignment semantics are easier to map into functional semantics. > > > > So if we do allow coro in Perl 6, it'll probably be a second-class > > citizen like loop and goto and die (and anything else considered > > harmful but useful). But I don't see much use for it offhand. > > Does that imply that multiple assignment is second-class, too? > And that with a language that provides the concept of eternal > equality with ===, or checking of referential identity with =:=. > Big surprise that is. > > > Regards, TSa. > -- > > "The unavoidable price of reliability is simplicity" >-- C.A.R. Hoare > -- Sent from Gmail for mobile | mobile.google.com Mark J. Reed <[EMAIL PROTECTED]>
Re: Are coroutines still there?
HaloO, Mark J. Reed wrote: ? Multiple-assignment second-class? I don't see how you get that out of Larry's message... Well, he explicitly says that loop is second-class because it uses multi-assignment. Actually he says it "tends to violate single-assignment". But I interpret that sort of intensionally as being worse than an outright violation. That is already the tendency of violation means second-class ;) Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
Re: method hiding (or not) in derived classes
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: "Candidate set" would be a better term. It is a subset of all long names of a multi in a lexical scope. List, not set, because it is ordered. nextsame/nextwith/etc. are described as invoking the next candidate on the list. Therefore, there is a list. What about ordinary methods (and ordinary parameters of multis)? Does the candidate list hold every method name that matches, or does it do simpler parameter matching based on number of arguments, required named arguments, etc.? There is hopefully a complete specification what constitutes applicability. There can hardly be differing simpler versions. In other words there is only one subtype relation that is used whenever a binding takes place. I have no idea what you said. If that is the case, then a derived method might not hide a base class method if the parameter list is seriously incompatible. That is a natural and welcome consequence of type based dispatch. Classes are for implementation sharing, not for transitive typing. I'm talking about non-multi's here. More interestingly, left-to-right ordering of multiply-inherited base classes will be checked for applicability rather than arbitrarily taking the leftmost. Indeed, I would hope that order of inheritance doesn't matter. Sounds more role-like, now that you mention it. Regards, TSa.
Re: use of ::?CLASS
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: You are right and I didn't address this, sorry. Actually the only solution I see is dropping the ::? twigil altogether and specify that CLASS is lexically declared by the compiler. Otherwise we have to make a special case exception out of ::? variables. All twigiled variables. No longer special case: it only applies to non-qualified names with no twigil. But doit is not a type. I think you were talking something like that earlier and I didn't follow. It is an arrow type, like foo: Int --> Int and bar: Int --> Int. These are structurally identical. The fun thing is that the Perl 6 type system is supposed to be nominal. Thus foo and bar are different types. But contradictory to that you can use foo and bar wherever an Int --> Int is expected. I love this self contradiction of Perl ;) Well, and you can't neither use foo nor bar to denote the arrow type. doit =has= a signature. Yes, I expect functions will be typechecked when you try and assign one to a variable that declares a function type. But the function is a value of that type, just like 5 is a value of type Int, not itself a type. --John
Re: Context and return types question
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: I guess with strong you mean as lossless as possible? I think the type is just :( $: :named$ ) if you want to extract the invocant with a $ prefix. Otherwise it would be :( $, :named$ ) and you extract the item positionally with prefix @ or .[]. I don't want to have to "extract" it. I want to be able to say $x = foo and get the single value return from foo, and only dress it up if I want the optional secondary returns my ($x, :$named) = foo; # or something like that Note that Captures are immutable and therefore nicely covariant. Except of course that containers are captured as containers and can be mutated. But Larry revealed that single assignment semantics are aspired and mutability is a historic artifact or so. Regards, TSa. Sorry, you lost me again.
Re: Context and return types question
HaloO, John M. Dlugosz wrote: I don't want to have to "extract" it. I want to be able to say $x = foo I guess that does not collapse the capture that foo returns. So it goes into $x unaltered. If you later use $x as an invocant of a method this extracts the invocant slot from the capture. And $x works as expected. and get the single value return from foo, and only dress it up if I want the optional secondary returns my ($x, :$named) = foo; # or something like that Should work. Sorry, you lost me again. Single-assignment is a feature from constraint programming e.g. in Oz. There you have a single-assignment store. I interpreted Larry's comment on my coro question as making single-assignment semantics first-class and everything else second-class. A capture can contain an array that later on can change its content: @a = 1,2,3; @b = 4,5,6; @c = 7,8,9; $cap = \(@a,@b); $cap[0] = @c; # error $cap[0][] = @c; # ok, @a now 7,8,9 Writing into a container is contra-variant. Reading is co-variant. So a capture has to be invariant. Assume A <: B <: C and regard my A $a; my C $c; my B $ba := $a; # ok for reading from $a my B $bc := $c; # ok for writing into $c Both bindings are type errors. If captures were recursively immutable you could allow bindings ala $ba. Well, or we interpret $a and $b as typed views of whatever value they lead to. This insures that there will never be assignment or binding type errors. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
Re: [perl #53126] [TODO] config/auto/digest.pm: New config step needs rationale, lacks tests
James Keenan (via RT) a écrit : # New Ticket Created by James Keenan # Please include the string: [perl #53126] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=53126 > I noticed that a new step, auto::digest, has been added to the list of Parrot configuration steps. Two issues: 1. The commit message suggests that this is a refactoring of code previously found elsewhere in the configuration system: r27060 | fperrad | 2008-04-20 15:26:38 -0400 (Sun, 20 Apr 2008) | 2 lines [digest]- refactor digest PMC generation (now a config/gen step) However, when I grep config/*/*.pm for 'digest', the only mention I get (other than in config/gen/digest.pm itself) is here: config/auto/crypto.pm:68:$conf->data->set( has_crypto => $has_crypto );# for dynpmc.in & digest.t So I don't see where the code was refactored from, and I don't understand the rationale for the addition of this step. Previously, the generation was done by src/dynpmc/Makefile (generated from config/gen/makefiles/dynpmc.in) and use some perl -pe "s///" from a template src/dynpmc/mdx.pmc. So it was not the standard way, and it was not enought smart : two files SHA256 & SHA512 need different behaviors for OpenSSL 0.9.7 and 0.9.8. 2. When I now configure with 'perl Configure.pl --test', I get this warning, both at the start of configuration and in t/configure/025- options_test.t andn t/configure/049-options_test.t: No tests exist for configure step gen::digest at Configure.pl line 14 ... which means we've added a configuration step class with no corresponding tests. (Until yesterday, configuration would have simply died at this point, but I acknowledged a request to have it just generate a warning instead.) The test file could be as simple as a two-test file, with one test saying use_ok the new step and another saying 'pass'. I prefer the die behavior, because with it, I don't forget to add tests with auto::crypto. Now, I think the name gen::digest is not good. I prefer gen::crypto because : 1) same as auto::crypto 2) libcrypto contains cypher algo (not only digest), so we could add some PMC wrapper (for example : DES, ...) François. Thank you very much. kid51
[perl #53126] [TODO] config/auto/digest.pm: New config step needs rationale, lacks tests
On Mon Apr 21 07:11:23 2008, [EMAIL PROTECTED] wrote: > > Previously, the generation was done by src/dynpmc/Makefile (generated > from config/gen/makefiles/dynpmc.in) and use some perl -pe "s///" from a > template src/dynpmc/mdx.pmc. > So it was not the standard way, and it was not enought smart : > two files SHA256 & SHA512 need different behaviors for OpenSSL 0.9.7 and > 0.9.8. > This is very interesting. I'll study it more when I get home tonight. Thanks for the update! kid51
Re: method hiding (or not) in derived classes
On Sat, Apr 19, 2008 at 08:00:07AM -, John M. Dlugosz wrote: : Perl 6 has a concept of a "candidate list". The candidate list are those that could handle the call, typically inherited methods and multi variations. : : It seems that multi variations, at least with respect to the semicolon parameters, compare the actual type and drop out of the list if any don't match. When you drop those candidates that "can never match" is mostly a matter of optimization, I suspect. : What about ordinary methods (and ordinary parameters of multis)? Does the candidate list hold every method name that matches, or does it do simpler parameter matching based on number of arguments, required named arguments, etc.? For those parameters, it matters only whether they can be bound when the candidate is called. The parameters need not be considered at all when generating the candidate list (but see "optimization" above--though perhaps this view is oversimplified if we have to do tie determination, since ties are supposed to fail before the final call, and we'd have to weed out non-bindable sigs before declaring a tie). : If that is the case, then a derived method might not hide a base class method if the parameter list is seriously incompatible. More interestingly, left-to-right ordering of multiply-inherited base classes will be checked for applicability rather than arbitrarily taking the leftmost. "only" methods use only short name, and methods, like subs, default to "only". And as it is currently specced, the class is dispatched on the short name before any any of its multis, and long names are not considered until the class is dispatched to. The invariant is that single dispatch is always under the control of the invocant's object system, while multiple dispatch never is. In my mind the policy distinction is clarified by considered what happens if a foreign language defines some of the classes. Under single dispatch the language that defined the object gets the dispatch. Under multiple dispatch, all objects are treated as Perl objects with Perl types, and the type system gets to decide which candidate to call. It is important to be able to look at a call and determine which kind of call is being made; this is why we give single dispatch a syntax that is distinct from multiple dispatch. So if you use "multi method" declarations within a class, they appear only to be a single method from outside the class, because that is all the foreign language interface can support. You can only use multi methods within a class if the language supports the concept, and Perl 6 only supports it out the scope of the current class. Basically, multi methods are just treated as multi subs inside a class, except the invocant is predecided and doesn't make any difference to the dispatch within the class. Larry
Re: progress report
On Apr 20, 8:38 pm, [EMAIL PROTECTED] wrote: > "John M. Dlugosz" and I have both replied to "whiteringmoon"'s query, so I > don't think anyone else need to. (If he's genuine, we don't want to > bombard him with multiple replies, and if not, let's not give out too much > spambait.) > > -- > > Email and shopping with the feelgood factor! > 55% of income to good causes.http://www.ippimail.com I honestly had not considered computer languages in my perameters of study. But because it is a common language used by a large number of people, and it's intent of meaning is constant it may be a perfect language. From what I understand about computer languages is this that they are based on a binary language consisting of zero and one and with thoes two numbers all the language that exists, the instructions that the computer will follow so that it can communicate with every other computer. Again thank you both for answering my questions. I'm going to read the information and add it the list of languages. WR
Re: [perl #53112] [PATCH] Fixing C++ build break issue when using GMP
On Mon, Apr 21, 2008 at 12:25 AM, Mark Glines <[EMAIL PROTECTED]> wrote: > (Still debatable whether the rest of that #else clause in parrot.h is > valid, if it's causing issues like this one.) This patch can avoid future problems, by defining and using using specific macros. I searched the source tree, looks like textdomain and bindtextdomein are used only in src/main.c and include/parrot/parrot.h, but I can't test now in a system without gettext. -- Salu2 Index: src/main.c === --- src/main.c (revisión: 27079) +++ src/main.c (copia de trabajo) @@ -44,8 +44,8 @@ /* internationalization setup */ /* setlocale(LC_ALL, ""); */ -bindtextdomain(PACKAGE, LOCALEDIR); -textdomain(PACKAGE); +PARROT_BINDTEXTDOMAIN(PACKAGE, LOCALEDIR); +PARROT_TEXTDOMAIN(PACKAGE); Parrot_set_config_hash(); Index: include/parrot/parrot.h === --- include/parrot/parrot.h (revisión: 27079) +++ include/parrot/parrot.h (copia de trabajo) @@ -251,11 +251,13 @@ # define _(s) gettext(s) # define gettext_noop(s) (s) # define N_(s)gettext_noop(s) +# define PARROT_TEXTDOMAIN(d) textdomain(d) +# define PARROT_BINDTEXTDOMAIN(p, d) bindtextdomain((p), (d)) #else # define _(s) (s) # define N_(s)(s) -# define textdomain(d) -# define bindtextdomain(p, d) +# define PARROT_TEXTDOMAIN(d) +# define PARROT_BINDTEXTDOMAIN(p, d) #endif /* PARROT_HAS_GETTEXT */ #define PACKAGE "parrot"
Re: method hiding (or not) in derived classes
HaloO, John M. Dlugosz wrote: TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: "Candidate set" would be a better term. It is a subset of all long names of a multi in a lexical scope. List, not set, because it is ordered. nextsame/nextwith/etc. are described as invoking the next candidate on the list. Therefore, there is a list. Hmm, the term candidate should be after the applicability check and before specificity check. The latter results in a partially ordered list of targets. If there's more than one most specific target, we have an ambiguity error. As a consequence there might not be a unique next method on the target list and a nextsame might fail. I agree that the synopsis conflate these details into the term "candidate list". But I hope you are more rigorous. What about ordinary methods (and ordinary parameters of multis)? Does the candidate list hold every method name that matches, or does it do simpler parameter matching based on number of arguments, required named arguments, etc.? There is hopefully a complete specification what constitutes applicability. There can hardly be differing simpler versions. In other words there is only one subtype relation that is used whenever a binding takes place. I have no idea what you said. OK, here's my vision of dispatch. First there's a syntactic distinction between MMD and class dispatch. $obj.meth(|$args); meth $obj: |$args; These pull out the candidate set from $obj. Everything else collects the candidate set from a namespace scan. Next, all candidates are checked to allow a binding of $obj and |$args. The ones that fail are dropped. If the candidate set is now empty we have a failure. The remaining set is now sorted into a list of sets by applying the subtype relation in the dispatch relevant parameter positions. If the first element of that list is a set with a single element we have a successful dispatch. Otherwise there's an ambiguity error. The .? avoids the no target error, .+ avoids the ambiguity error and .* never fails. I would leave the order in which sets of targets are called unspecified. If one needs more control the .WALK method can be used. If class dispatch fails because there's no applicable method then a MMD is attempted. I guess the answer to your question concerning hiding a method in a derived class depends on the set of candidates the $obj.HOW comes up with in the first step. If it delivers superclass methods and subclass methods fail the applicability test then the dispatch goes to a superclass method that can handle the dispatch. Would you favor a type error then? If that is the case, then a derived method might not hide a base class method if the parameter list is seriously incompatible. That is a natural and welcome consequence of type based dispatch. Classes are for implementation sharing, not for transitive typing. I'm talking about non-multi's here. Me too. As stated above the candidate set is up to the class that created the object. If this class can prevent the failover to MMD I don't know. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
Re: PCT patch
On Thu, Apr 17, 2008 at 10:10:29PM -0500, Jonathan Scott Duff wrote: > I was annoyed that >parrot perl6.pbc --target=PAST -e 'say "Hello"' > didn't seem to work, so I modified PCT/HLLCompiler so that it does. > > I'm not sure it's entirely correct though as I only tested it for the > limited functionality I was after. > > I've attached the patch though. I'm rejecting the patch for now. The patch refactors all of the output functionality for --target into HLLCompilers 'eval' method, and somehow I think that 'eval' should only be responsible for performing evaluation and not for dumping output. There also seems to be a bug in the patch, at least for some combinations of arguments. After the patch is applied, the 'eval' method reads: $P0 = self.'compile'(code, adverbs :flat :named) $I0 = isa $P0, 'String' if $I0 goto end .local string target target = adverbs['target'] if target != '' goto end ... end: if null $P0 goto real_end unless target goto real_end if target == 'pir' goto target_pir '_dumper'($P0,target) goto real_end target_pir: say $P0 real_end: We can never get to the 'say $P0' line following target_pir. If the command line specified --target=pir, then self.'compile'(...) will return a String object, and we end up bypassing the target = adverbs['target'] line altogether. Simply moving the target = adverbs['target'] line above the test for a String will introduce other problems, as then the PIR from --target=PIR will be displayed regardless of any setting of the --output= option. Overall I think we may need a larger refactor of interactive/evalfiles/eval_line to be able to handle this more cleanly. But keep in mind the processing for each case isn't exactly identical -- handling of exceptions and results can differ among the three. For example, interactive mode traps exceptions, while the others don't. We should also keep in mind that we will likely want a --target=pbc option at some point in the not-too-distant future. Thanks! Pm
Re: Class names are virtual
HaloO,
John M. Dlugosz wrote:
I hope you have a few minutes to look it over.
I started to think it through. There are two quick remarks.
In
module M
{
class C { ... }
class D
{
# lexical region where C refers to M::C
method m1 () { my C $x; my Int $y; ... }
class C { ... }
# lexical region where C refers to D::C
method m2 () { my C $x; ... }
}
}
I would make the use of C in m1 of D an error because otherwise
the scope D is split into two at the point where D::C is defined.
In other words D::C is not the innermost definition everywhere in
D. This is a serious source of subtle errors. If this is what you
want than write M::C in m1. Scopes should be one-dimensional along
the lines of inner versus outer. An additional dimension before
versus after should be used only for error checking. That is in m1
C is parsed provisionally as M::C and this fails when D::C is seen
later.
Second, I don't like the concept of a virtual method that returns
a type. That horribly mixes type level and value level. From the
namespace POV we have M::D::foo and P::E::foo bound to the same
implementation. In both cases C is OUTER::C. The "magic" should
happen when an invocation of foo is created. That is the moment when
the scope of OUTER::C can be bound by 'my C $b' through $x and $y
respectively.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
Another Optimization Target: bsr and stacks
I'm still exploring the Rakudo build progress as a profiling target for likely optimizations. After this weekend's work, I have src/gen_actions.pir generation down to 27,788,055,796 instructions (with an optimized Parrot). A big chunk of that time goes to support bsr_ic: 7,784,136,854 core.ops:Parrot_bsr_ic 7,775,231,886 stacks.c:stack_push 7,763,569,145 stack_common.c:stack_prepare_push 7,754,735,042 stack_common.c:cst_new_stack_chunk (These times include calls from the functions, not their own times.) Why is it expensive? *Every* call to cst_new_stack_chunk() requests a free bufferlike object from the GC. 98% of the inclusive cost of these four functions is in running the GC. Someone who's familiar with the stack code (or wants to be) might be able to find a big optimization here. I won't rule out the possibility that these stack operations should be able to recycle freshly-unused stack chunks, to replenish the free list without doing a full GC run. Then again, I remember someone saying at least some parts of the stack code should go away, and I'm all for that too. -- c
Re: Context and return types question
On Apr 21, 2008, at 9:39 , John M. Dlugosz wrote: TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: I think the type is just :( $: :named$ ) if you want to extract the invocant with a $ prefix. Otherwise it would be :( $, :named $ ) and you extract the item positionally with prefix @ or .[]. I don't want to have to "extract" it. I want to be able to say $x = foo and get the single value return from foo, and only dress it up if I want the optional secondary returns my ($x, :$named) = foo; # or something like that That looks to me like a form of positional extraction. (Of course, my hit rate on p6 stuff has been remarkably low of late...) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: Another Optimization Target: bsr and stacks
On Mon, Apr 21, 2008 at 10:19:08AM -0700, chromatic wrote: > I'm still exploring the Rakudo build progress as a profiling target for > likely > optimizations. After this weekend's work, I have src/gen_actions.pir > generation down to 27,788,055,796 instructions (with an optimized Parrot). A > big chunk of that time goes to support bsr_ic: > > 7,784,136,854 core.ops:Parrot_bsr_ic > 7,775,231,886 stacks.c:stack_push > 7,763,569,145 stack_common.c:stack_prepare_push > 7,754,735,042 stack_common.c:cst_new_stack_chunk > > Why is it expensive? *Every* call to cst_new_stack_chunk() requests a free > bufferlike object from the GC. 98% of the inclusive cost of these four > functions is in running the GC. > > Someone who's familiar with the stack code (or wants to be) might be able to > find a big optimization here. To me, the scary part of src/stacks.c is at the beginning: The stack is stored as a linked list of chunks (C), where each chunk has room for one entry. Eek! For something like bsr_ic, which is really just pushing a return address (i.e., opcode_t *) onto a stack, we're allocating a new GC-able object for every bsr invocation, and freeing it on ret. Since PGE uses bsr/ret for its backtracking, that's a lot of allocations. In fact, this seems to be the case for everything using the "generic stack", which AFAICT is the &interp->dynamic_env structure. So, everything that gets pushed onto this stack (exceptions, continuations, coroutines, bsr/ret calls) ends up with a separate gc-able structure (Stack_Chunk) to hold the stack entry. So, switching PGE from bsr/ret to another control structure doesn't give us a win here. I think we'd get a BIG win if we changed the dynamic_env stack to have an approach similar to ResizableIntegerArray, where we allocate arrays of Stack_Chunk entries and manage them that way, instead of a separate allocation per element in the stack. In looking at the stacks.c code I think I could manage this if nobody else is interested in playing with it. > Then again, I remember someone saying at least some parts of the stack code > should go away, and I'm all for that too. The parts of the stack code we've discussed eliminating is actually the user_stack, used for push/pop/saveall/restoreall opcodes. The bsr/ret opcodes don't use this particular stack. However, I think that if we eliminate the user_stack, we in fact simplify stacks.c by a tremendous amount and could get even a bigger win (including eliminating some unions and other C nastiness). I think it's a big enough win for PGE and Rakudo that I'll be very happy to work on both of these items in a branch -- i.e., eliminating the user stack ops and converting the remaining dynamic_env structure to be something far more suitable for GC. I think the performance gain we'll see will be, well, substantial. Pm
[PROPOSAL] Add tutorial language Squaak to examples in repository
hi, Currently, the pct tutorial language is "out there", mostly on the parrotblog entries, and I uploaded a .zip onto the wiki. However, updating it is now a pain, because I have to recreate a .zip and replace it on the wiki. What do people think about adding it in the examples directory? At first I was somewhat hesitant to do so, as I rather not see grow the parrot repository too big... (it's already big), but... it would be quite helpful to store squaak somewhere, so it doesn't get lost. comments welcome, kjs PS: On a sidenote, besides a job, I have limited internet access, which doesn't allow me to connect to irc in the evening :-(
Re: [PROPOSAL] Add tutorial language Squaak to examples in repository
On Mon, Apr 21, 2008 at 08:34:49PM +0100, Klaas-Jan Stol wrote: > hi, > > Currently, the pct tutorial language is "out there", mostly on the > parrotblog entries, and I uploaded a .zip onto the wiki. > > However, updating it is now a pain, because I have to recreate a .zip > and replace it on the wiki. > What do people think about adding it in the examples directory? At > first I was somewhat hesitant to do so, as I rather not see grow the > parrot repository too big... (it's already big), but... it would be > quite helpful to store squaak somewhere, so it doesn't get lost. I think it could go either in examples/ or in languages/ . Either way, having it in the repo somewhere is probably the best place for it at the moment. Pm
Re: Another Optimization Target: bsr and stacks
On Mon, Apr 21, 2008 at 8:25 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > On Mon, Apr 21, 2008 at 10:19:08AM -0700, chromatic wrote: > > I'm still exploring the Rakudo build progress as a profiling target for > likely > > optimizations. After this weekend's work, I have src/gen_actions.pir > > generation down to 27,788,055,796 instructions (with an optimized Parrot). > A > > big chunk of that time goes to support bsr_ic: > > > > 7,784,136,854 core.ops:Parrot_bsr_ic > > 7,775,231,886 stacks.c:stack_push > > 7,763,569,145 stack_common.c:stack_prepare_push > > 7,754,735,042 stack_common.c:cst_new_stack_chunk > > > > > Why is it expensive? *Every* call to cst_new_stack_chunk() requests a free > > bufferlike object from the GC. 98% of the inclusive cost of these four > > functions is in running the GC. > > > > Someone who's familiar with the stack code (or wants to be) might be able > to > > find a big optimization here. > > To me, the scary part of src/stacks.c is at the beginning: > > The stack is stored as a linked list of chunks (C), > where each chunk has room for one entry. > > Eek! For something like bsr_ic, which is really just pushing a > return address (i.e., opcode_t *) onto a stack, we're allocating a > new GC-able object for every bsr invocation, and freeing it on ret. > Since PGE uses bsr/ret for its backtracking, that's a lot of allocations. > > In fact, this seems to be the case for everything using the > "generic stack", which AFAICT is the &interp->dynamic_env structure. > So, everything that gets pushed onto this stack (exceptions, > continuations, coroutines, bsr/ret calls) ends up with a separate > gc-able structure (Stack_Chunk) to hold the stack entry. > So, switching PGE from bsr/ret to another control structure doesn't > give us a win here. > > I think we'd get a BIG win if we changed the dynamic_env stack to > have an approach similar to ResizableIntegerArray, where we allocate > arrays of Stack_Chunk entries and manage them that way, instead of > a separate allocation per element in the stack. what about actually using a ResizableIntegerArray for this purpose? (or PMC, if Integer is not suitable for storing addresses) Or is this a really dumb idea? kjs
Re: Another Optimization Target: bsr and stacks
On Monday 21 April 2008 12:25:53 Patrick R. Michaud wrote: > To me, the scary part of src/stacks.c is at the beginning: > > The stack is stored as a linked list of chunks (C), > where each chunk has room for one entry. > > Eek! For something like bsr_ic, which is really just pushing a > return address (i.e., opcode_t *) onto a stack, we're allocating a > new GC-able object for every bsr invocation, and freeing it on ret. > Since PGE uses bsr/ret for its backtracking, that's a lot of allocations. > > In fact, this seems to be the case for everything using the > "generic stack", which AFAICT is the &interp->dynamic_env structure. > So, everything that gets pushed onto this stack (exceptions, > continuations, coroutines, bsr/ret calls) ends up with a separate > gc-able structure (Stack_Chunk) to hold the stack entry. > So, switching PGE from bsr/ret to another control structure doesn't > give us a win here. > > I think we'd get a BIG win if we changed the dynamic_env stack to > have an approach similar to ResizableIntegerArray, where we allocate > arrays of Stack_Chunk entries and manage them that way, instead of > a separate allocation per element in the stack. That sounds reasonable. For now, I've taken a hint from the paper on how all garbage collectors are hybrids and added a reference count to Stack_Chunk_t elements in stack_push and a stack_pop. If the reference count is zero at the end of the latter, it's safe to recycle the Stack_Chunk_t back to its free list immediately. r27081 produces an 11.73% improvement in the benchmark. The Perl 6 tests run in 12 seconds for me now, with an optimized Parrot. -- c
Re: Another Optimization Target: bsr and stacks
On Mon, Apr 21, 2008 at 08:48:10PM +0100, Klaas-Jan Stol wrote: > On Mon, Apr 21, 2008 at 8:25 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > > I think we'd get a BIG win if we changed the dynamic_env stack to > > have an approach similar to ResizableIntegerArray, where we allocate > > arrays of Stack_Chunk entries and manage them that way, instead of > > a separate allocation per element in the stack. > > what about actually using a ResizableIntegerArray for this purpose? > (or PMC, if Integer is not suitable for storing addresses) > Or is this a really dumb idea? I looked at this possibility, and while it can work, the values that need to be stored are actually pointers, not integers. We could do some casting there, but I think it'd be a slight step sideways, when we can do much better (in an area that needs to be as good as we can make it). ResizablePMCArray is probably even farther afield, since the things being stored aren't at all PMCs. But truthfully I'm thinking I can eliminate much of the existing stack_* code altogether. At the moment the stack_* functions are trying to manage a stack that contains integers, floats, strings, pmcs, and addresses. I'm thinking that if we eliminate the user_stack ops, then we just need a stack of addresses, which means we can rip out a metric ton of existing code. Pm
[perl #52838] [CORE] Remove the saveall and restoreall ops
I've applied the patch from RT#52838 which updates the documentation. I'm now working on eliminating the restoreall/saveall opcodes themselves from Parrot, as well as working on the related user stack ops in RT#52842. Pm
Re: [PROPOSAL] Add tutorial language Squaak to examples in repository
On Mon, Apr 21, 2008 at 8:41 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > On Mon, Apr 21, 2008 at 08:34:49PM +0100, Klaas-Jan Stol wrote: > > hi, > > > > Currently, the pct tutorial language is "out there", mostly on the > > parrotblog entries, and I uploaded a .zip onto the wiki. > > > > However, updating it is now a pain, because I have to recreate a .zip > > and replace it on the wiki. > > What do people think about adding it in the examples directory? At > > first I was somewhat hesitant to do so, as I rather not see grow the > > parrot repository too big... (it's already big), but... it would be > > quite helpful to store squaak somewhere, so it doesn't get lost. > > I think it could go either in examples/ or in languages/ . Either way, > having it in the repo somewhere is probably the best place for it at > the moment. it's added in languages/ ../../parrot squaak.pbc examples/life.sq, and enjoy :-) kjs
Re: Another Optimization Target: bsr and stacks
On Mon, Apr 21, 2008 at 02:25:53PM -0500, Patrick R. Michaud wrote: > > The parts of the stack code we've discussed eliminating is actually > the user_stack, used for push/pop/saveall/restoreall opcodes. I inadvertently wrote push/pop here where I really meant save/restore. The push/pop opcodes work on PMCs, not the user stack. Pm
[svn:parrot-pdd] r27082 - in trunk: docs/pdds/draft editor languages/BASIC/compiler
Author: pmichaud Date: Mon Apr 21 13:08:48 2008 New Revision: 27082 Modified: trunk/docs/pdds/draft/pdd06_pasm.pod Changes in other areas also in this revision: Modified: trunk/editor/kate_syntax.pl trunk/languages/BASIC/compiler/compile.pl Log: [core]: * Updates for the restoreall/saveall opcodes (RT#52838) * Original patch courtesy James Keenan kid51++ * Patch modified to remove reference to restoreall/saveall in kate_syntax.pl, and to eliminate restoretop/savetop from pdd06 (these opcodes are already gone from Parrot). Modified: trunk/docs/pdds/draft/pdd06_pasm.pod == --- trunk/docs/pdds/draft/pdd06_pasm.pod(original) +++ trunk/docs/pdds/draft/pdd06_pasm.podMon Apr 21 13:08:48 2008 @@ -507,24 +507,6 @@ Restore register X from the generic stack by popping off the topmost entry. The type of this entry must match the register type. -=item saveall - -Save all of the current set of registers onto the appropriate frame stacks. -Equivalent to performing a separate push for each register type. - -=item restoreall - -Restore all of the registers from the appropriate frame stacks. Equivalent to -performing a separate pop for each register type. - -=item savetop - -As L but only acts on registers 16-31. - -=item restoretop - -As L but only affects registers 16-31. - =item set_warp string Sets a named marker for the stacks for later use.
Re: Another Optimization Target: bsr and stacks
From: "Patrick R. Michaud" <[EMAIL PROTECTED]> Date: Mon, 21 Apr 2008 14:25:53 -0500 . . . this seems to be the case for everything using the "generic stack", which AFAICT is the &interp->dynamic_env structure. Your point is correct, except that you are talking about the "dynamic environment stack" (which used to be called the "control stack"). The "generic stack" is the "user_stack" slot of Parrot_Context, which is implemented the same way, and therefore suffers from the same speed issues. (Just for the record.) -- Bob
Re: Another Optimization Target: bsr and stacks
On Mon, Apr 21, 2008 at 04:31:17PM -0400, Bob Rogers wrote: >From: "Patrick R. Michaud" <[EMAIL PROTECTED]> >Date: Mon, 21 Apr 2008 14:55:21 -0500 > >> On Mon, Apr 21, 2008 at 8:25 PM, Patrick R. Michaud <[EMAIL PROTECTED]> > wrote: >> > I think we'd get a BIG win if we changed the dynamic_env stack to >> > have an approach similar to ResizableIntegerArray, where we allocate >> > arrays of Stack_Chunk entries and manage them that way, instead of >> > a separate allocation per element in the stack. > > That would make the implementation of the continuation classes > unnecessarily difficult. These classes need to be able to point to > individual dynamic_env entries in order to restore the dynamic > environment precisely. Using arrays opens the possibility of > overwriting slots, which would destroy dynamic state that some > continuation may depend upon. (And if slots are *not* overwritten, then > you probably lose the benefit of the optimization.) Thanks for this very useful note. I'll keep it in mind as we go. > Don't forget the other dynamic_env uses for error handling, actions, and > marks. A lot of simplification would indeed be possible, but even then > it would not be "just a stack of addresses." Hadn't forgotten them -- just still learning about the problem. >There is another solution that ought to speed up "bsr" dramatically: > Give the "bsr" return addresses their own stack. I thought of this also, but given that they share a stack currently I figured the smaller delta would be to keep it that way. If it looks like having a separate stack for bsr/ret is workable then I'll go at it that way. But the first step is eliminating the user stack, and I've started on that now in the 'stacks' branch of the svn repo. Pm
Re: Another Optimization Target: bsr and stacks
On Mon, Apr 21, 2008 at 04:38:52PM -0400, Bob Rogers wrote: >From: "Patrick R. Michaud" <[EMAIL PROTECTED]> >Date: Mon, 21 Apr 2008 14:25:53 -0500 > >. . . this seems to be the case for everything using the >"generic stack", which AFAICT is the &interp->dynamic_env structure. > > Your point is correct, except that you are talking about the "dynamic > environment stack" (which used to be called the "control stack"). The > "generic stack" is the "user_stack" slot of Parrot_Context, which is > implemented the same way, and therefore suffers from the same speed > issues. (Just for the record.) Thanks again. I was misreading from comments in stack_push, which say that it pushes things onto the "generic stack" when in reality it seems to use whatever stack is passed into it. Pm
Re: Another Optimization Target: bsr and stacks
On Monday 21 April 2008 13:44:44 Patrick R. Michaud wrote: > On Mon, Apr 21, 2008 at 04:38:52PM -0400, Bob Rogers wrote: > Thanks again. I was misreading from comments in stack_push, which > say that it pushes things onto the "generic stack" when in reality > it seems to use whatever stack is passed into it. To be fair, it's not even a stack. It's a graph that's usually acyclical. If it were a stack, I wouldn't have had to add the refcounting to see when we can free chunks. -- c
Re: Another Optimization Target: bsr and stacks
From: "Patrick R. Michaud" <[EMAIL PROTECTED]> Date: Mon, 21 Apr 2008 14:55:21 -0500 > On Mon, Apr 21, 2008 at 8:25 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > > I think we'd get a BIG win if we changed the dynamic_env stack to > > have an approach similar to ResizableIntegerArray, where we allocate > > arrays of Stack_Chunk entries and manage them that way, instead of > > a separate allocation per element in the stack. That would make the implementation of the continuation classes unnecessarily difficult. These classes need to be able to point to individual dynamic_env entries in order to restore the dynamic environment precisely. Using arrays opens the possibility of overwriting slots, which would destroy dynamic state that some continuation may depend upon. (And if slots are *not* overwritten, then you probably lose the benefit of the optimization.) On Mon, Apr 21, 2008 at 08:48:10PM +0100, Klaas-Jan Stol wrote: > what about actually using a ResizableIntegerArray for this purpose? > (or PMC, if Integer is not suitable for storing addresses) > Or is this a really dumb idea? I looked at this possibility, and while it can work, the values that need to be stored are actually pointers, not integers. We could do some casting there, but I think it'd be a slight step sideways, when we can do much better (in an area that needs to be as good as we can make it). ResizablePMCArray is probably even farther afield, since the things being stored aren't at all PMCs. Not all of them, anyway. But truthfully I'm thinking I can eliminate much of the existing stack_* code altogether. At the moment the stack_* functions are trying to manage a stack that contains integers, floats, strings, pmcs, and addresses. I'm thinking that if we eliminate the user_stack ops, then we just need a stack of addresses, which means we can rip out a metric ton of existing code. Pm Don't forget the other dynamic_env uses for error handling, actions, and marks. A lot of simplification would indeed be possible, but even then it would not be "just a stack of addresses." There is another solution that ought to speed up "bsr" dramatically: Give the "bsr" return addresses their own stack. Currently, it is only possible to "ret" to an address in the same context, so we could add a stack to the Parrot_Context structure, and the first "bsr" in a given context could create a dedicated array to use as a stack. The addresses all point into bytecode, so this would not need to be visible to the GC. The dynamic_env stack can continue to operate as it does now, with (as Patrick points out) much simplification in the underlying support code. Most dynamic_env operations are relatively infrequent, so performance tuning is not critical there. The fly in the ointment is that continuations also need to capture the TOS of the to_context. That's comparatively easy, but has the same slot-overwriting issue as an arraylike dynamic_env would. We could finesse this by saying that "Continuations do not restore bsr/ret state," but that may be unpalatable. On the other hand, the speedup may be worth it. (FWIW, this idea had been mooted before, though I forget when. But it was not pursued because it wasn't believed to be of much benefit.) -- Bob Rogers http://rgrjr.dyndns.org/
Re: Another Optimization Target: bsr and stacks
Am Montag, 21. April 2008 22:49 schrieb chromatic: > On Monday 21 April 2008 13:44:44 Patrick R. Michaud wrote: > > On Mon, Apr 21, 2008 at 04:38:52PM -0400, Bob Rogers wrote: > > > > Thanks again. I was misreading from comments in stack_push, which > > say that it pushes things onto the "generic stack" when in reality > > it seems to use whatever stack is passed into it. > > To be fair, it's not even a stack. It's a graph that's usually acyclical. > If it were a stack, I wouldn't have had to add the refcounting to see when > we can free chunks. As there seems to still exist old (stack) cruft in the code base, it's probably ok to just denote it with a line of code reference, making the culprit easily grepable. > -- c leo
[perl #53156] [BUG] Segmentation violation in parrot
# New Ticket Created by "Clark Cooper" # Please include the string: [perl #53156] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=53156 > Using Parrot 0.6.1 on Fedora Core 5, linux 2.6.15-1.2054_FC5 The program, classinfo.pir : # .const string Indent=' ' .const int MaxDepth = 6 .sub main :main .param pmc argv .local int argc argc = argv if argc >= 2 goto ok die "Need to provide a classname" ok: .local string classname classname = argv[1] $P0 = get_class classname $I0 = defined $P0 if $I0 goto valid die "Invalid classname" valid: $P1 = inspect $P0 $I0 = 0 display_container($P1, $I0) .end .sub display_container .param pmc box .param int level .local pmc iter .local pmc entry iter = new 'Iterator', box mloop: unless iter goto endloop entry = shift iter $S0 = entry indent(level) print $S0 print ': ' $P1 = box[$S0] $S1 = typeof $P1 say $S1 $I1 = isa $P1, 'Hash' $I2 = isa $P1, 'Array' if $I1 goto delve if $I2 goto delve goto mloop delve: $I3 = level inc $I3 if $I3 > MaxDepth goto mloop display_container($P1, $I3) goto mloop endloop: .return() .end .sub indent .param int lev loop:if lev <= 0 goto finis print Indent dec lev goto loop finis: .return() .end ## [EMAIL PROTECTED] work]$ parrot -G classinfo.pir Class name: String namespace: NameSpace Segmentation fault [EMAIL PROTECTED] work]$ gdb ../parrot/parrot GNU gdb Red Hat Linux (6.3.0.0-1.122rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r classinfo.pir Class Starting program: /home/ccc/Parrot/parrot-0.6.1/parrot classinfo.pir Class Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0x293000 [Thread debugging using libthread_db enabled] [New Thread -1208149824 (LWP 5015)] name: String namespace: NameSpace Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208149824 (LWP 5015)] 0x00552b57 in Parrot_Key_get_string (interp=0x875d008, pmc=0x893ed68) at ./src/pmc/key.c:160 160 Parrot_Key_get_string(PARROT_INTERP, PMC *pmc) (gdb) bt 6 #0 0x00552b57 in Parrot_Key_get_string (interp=0x875d008, pmc=0x893ed68) at ./src/pmc/key.c:160 #1 0x0040d816 in key_string (interp=0x875d008, key=0x893ed68) at src/key.c:402 #2 0x00552b81 in Parrot_Key_get_string (interp=0x875d008, pmc=0x893ed68) at ./src/pmc/key.pmc:148 #3 0x0040d816 in key_string (interp=0x875d008, key=0x893ed68) at src/key.c:402 #4 0x00552b81 in Parrot_Key_get_string (interp=0x875d008, pmc=0x893ed68) at ./src/pmc/key.pmc:148 #5 0x0040d816 in key_string (interp=0x875d008, key=0x893ed68) at src/key.c:402 (More stack frames follow...) -- Clark Cooper
Re: Another Optimization Target: bsr and stacks
From: "Patrick R. Michaud" <[EMAIL PROTECTED]> Date: Mon, 21 Apr 2008 15:42:27 -0500 On Mon, Apr 21, 2008 at 04:31:17PM -0400, Bob Rogers wrote: >There is another solution that ought to speed up "bsr" dramatically: > Give the "bsr" return addresses their own stack. I thought of this also, but given that they share a stack currently I figured the smaller delta would be to keep it that way. If it looks like having a separate stack for bsr/ret is workable then I'll go at it that way. Fair enough. FWIW, I'm now working on a simple hack that should show how much speedup we can expect. But the first step is eliminating the user stack, and I've started on that now in the 'stacks' branch of the svn repo. Pm Excellent; thanks. -- Bob
[svn:parrot-pdd] r27092 - trunk/docs/pdds/draft
Author: pmichaud Date: Mon Apr 21 15:58:26 2008 New Revision: 27092 Modified: trunk/docs/pdds/draft/pdd06_pasm.pod Log: [docs]: * PDD06: Remove documentation of some opcodes that have been absent for a long time. Modified: trunk/docs/pdds/draft/pdd06_pasm.pod == --- trunk/docs/pdds/draft/pdd06_pasm.pod(original) +++ trunk/docs/pdds/draft/pdd06_pasm.podMon Apr 21 15:58:26 2008 @@ -403,80 +403,6 @@ =over 4 -=item pushp - -Push the current set of PMC registers onto the register frame stack, and start -a new set (which will all initially be NULL). Register frames hold only 16 -registers, so we need to push two frames onto the stack. The first frame -holds the contents of registers 0-15; the second holds the contents of -registers 16-31. - -=item popp - -Restore all of the PMC registers from the most recently Ced PMC -register frames. Since the register frames hold only 16 registers, we pop two -frames. We use the first frame to restore registers 16-31, and the second -frame to restore registers 0-15. Hence, C followed by C restores -all of the PMC registers to their original state. - -=item poptopp - -Pop a single PMC register frame off the PMC register frame stack and use it to -restore the values of registers 16-31. Registers 0-15 retain their old values. - -=item popbottomp - -Pop a single PMC register frame off the PMC register frame stack and use it to -restore the values of registers 0-15. Registers 16-31 retain their old values. - -=item pushi - -The same as L, for the integer register set. - -=item popi - -The same as L, for the integer register set. - -=item poptopi - -The same as L, for the integer register set. - -=item popbottomi - -The same as L, for the integer register set. - -=item pushs - -The same as L, for the string register set. - -=item pops - -The same as L, for the string register set. - -=item poptops - -The same as L, for the string register set. - -=item popbottoms - -The same as L, for the string register set. - -=item pushn - -The same as L, for the floating-point register set. - -=item popn - -The same as L, for the floating-point register set. - -=item poptopn - -The same as L, for the floating-point register set. - -=item popbottomn - -The same as L, for the floating-point register set. - =item clearp Clean out the current set of PMC registers, setting them to NULL @@ -507,10 +433,6 @@ Restore register X from the generic stack by popping off the topmost entry. The type of this entry must match the register type. -=item set_warp string - -Sets a named marker for the stacks for later use. - =item entrytype Ix, iy Put the type of generic stack entry Y into integer register X @@ -529,20 +451,6 @@ the stack may be a tree when looked at from the bottom up, you don't have access to any other branches when looking this way). -=item warp [string] - -Reset the current register stacks to the state they were in when the warp was -set. Resets only the frame pointers, doesn't guarantee the contents of the -registers. Be I careful modifying the frame pointers by, for example, -pushing register frames. - -If a name is passed, warp back to the named point. - -=item unwarp - -Reset the current register stacks to the state they were in before the last -warp. - =back =head2 Names, pads, and globals @@ -631,18 +539,11 @@ =over 4 -=item make_object Px, ty - -Make the variable in PMC x an object of type ty. The type can be a string, in -which case we treat it as a package name. - =item find_method Px, Py, tz Find the method Z for object Y, and return a PMC for it in X. -=item call_method Px, ty - -=item find_attribute Px, sy +=item callmethod Px, ty =item set_attribute Px, ty, tz
Re: [perl #53156] [BUG] Segmentation violation in parrot
On Monday 21 April 2008 10:26:21 Clark Cooper wrote: > Using Parrot 0.6.1 on Fedora Core 5, linux 2.6.15-1.2054_FC5 > > The program, classinfo.pir : > # > .const string Indent=' ' > .const int MaxDepth = 6 > > .sub main :main >.param pmc argv >.local int argc >argc = argv >if argc >= 2 goto ok > >die "Need to provide a classname" > ok: >.local string classname >classname = argv[1] >$P0 = get_class classname >$I0 = defined $P0 >if $I0 goto valid > >die "Invalid classname" > > valid: >$P1 = inspect $P0 >$I0 = 0 >display_container($P1, $I0) > .end > > .sub display_container >.param pmc box >.param int level >.local pmc iter >.local pmc entry With "string" instead of "pmc" for the register type, this code works. This makes me wonder what NameSpaces does for get_string_keyed versus get_pmc_keyed. > (gdb) r classinfo.pir Class > Starting program: /home/ccc/Parrot/parrot-0.6.1/parrot classinfo.pir Class > Reading symbols from shared object read from target memory...done. > Loaded system supplied DSO at 0x293000 > [Thread debugging using libthread_db enabled] > [New Thread -1208149824 (LWP 5015)] > name: String > namespace: NameSpace > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1208149824 (LWP 5015)] > 0x00552b57 in Parrot_Key_get_string (interp=0x875d008, pmc=0x893ed68) >at ./src/pmc/key.c:160 > 160 Parrot_Key_get_string(PARROT_INTERP, PMC *pmc) > (gdb) bt 6 > #0 0x00552b57 in Parrot_Key_get_string (interp=0x875d008, pmc=0x893ed68) >at ./src/pmc/key.c:160 > #1 0x0040d816 in key_string (interp=0x875d008, key=0x893ed68) at > src/key.c:402 #2 0x00552b81 in Parrot_Key_get_string (interp=0x875d008, > pmc=0x893ed68) at ./src/pmc/key.pmc:148 > #3 0x0040d816 in key_string (interp=0x875d008, key=0x893ed68) at > src/key.c:402 #4 0x00552b81 in Parrot_Key_get_string (interp=0x875d008, > pmc=0x893ed68) at ./src/pmc/key.pmc:148 > #5 0x0040d816 in key_string (interp=0x875d008, key=0x893ed68) at > src/key.c:402 (More stack frames follow...) That shouldn't happen, but it doesn't surprise me. -- c
Re: [perl #53142] [TODO] Cage-cleaner's request: PDD for configuration; Create RTs for new or heavily modified config steps
On Sun, 2008-04-20 at 19:01 -0700, James Keenan wrote: > auto::gettext (r26100 | particle | 2008-02-27) > auto::crypto (r26359 | fperrad | 2008-03-14) > auto::glibc (r26946 | particle | 2008-04-12) > auto::opengl (r27022 | infinoid | 2008-04-18) > gen::opengl (r27022 | infinoid | 2008-04-18) > gen::digest (r27060 | fperrad | 2008-04-20) > > AFAICT, in none of these cases was there any advance notice that new > steps were going to be added to the process. I just did 'svn up', > and there they were! I would have expected RT [TODO] tickets to have > been created for these additions, and I practiced that myself when I > did extensive refactoring to, or renaming of, any previously existing > config step. Two of these are from me (auto::opengl and gen::opengl). I had attempted to discuss OpenGL bindings on p-p and in IRC multiple times in the past; in each case the discussion either veered off into technical details or was Warnocked. No, I didn't create an RT [TODO] ticket, because I didn't know that was required. However, it seems redundant with both A) previous discussions, and B) discussion that occured on the RT [NEW] ticket I did open for my feature patch. > I would have been okay with that if I had a good idea as to the > direction in which Parrot configuration was evolving or if these > additions were in fulfillment of a previously documented plan -- but > I didn't and they weren't. As a non-core contributor, my impression is that there is no top-down plan. Parrot's development appears very much guided by dynamic tension between the real bottom-up work, docs ranging from prescriptive to descriptive to imaginative, and a *desire* to have a top-down plan. Personally, I think this dynamic tension is healthy, and trying to limit one facet in deference to the others seems counterproductive. > So, while I'm not disputing the merits of > any one of these new configuration step classes (I like the spinning > triangle you get with the opengl steps!) Thank you! > I am at a loss to answer questions such as these: > > * Is new configuration step X::X *necessary* for the functioning of > the Parrot virtual machine? For at least the OpenGL steps, and likely some of the others, the answer is clearly no. But see the next question. > * If new step X::X is not necessary for Parrot, what makes it > *desirable*? For me personally, a vast attraction of Parrot as a VM is the ability to provide common libraries for common functions that can be used across many languages. Commonly this is discussed in terms of "Python can use CPAN", but I don't see any reason why we shouldn't take this as an opportunity to merge some of the best stuff from each different language's modules and make something better from the fusion, and include it out of the box. Thus I'm in favor of including what I see as basic cross-language bindings for a number of cross-platform libraries -- crypto, database, 2D graphics, 3D graphics, email, common network protocols, compression, and so on. But let me take the opposing view for the moment that we *don't* want to include such libraries for Parrot 1.0. Parrot is finally reaching the point where creating such libraries is not only possible, but reasonable without worrying that all of the code will have to be rewritten multiple times before we get to 1.0. It seems inevitable that people will scratch their own itches and start to develop such libraries -- this is borne out by the very existence of the config steps you mention. These libraries need some forum for being tested on different platforms, bugs worked through, and so on. In addition, there is still enough churn in PIR and Parrot itself that it is desirable to make sure that global design changes are propagated to these libraries as well. Right now there is no good place for this other than the Parrot codebase itself. Even if we decide to split out libraries from the Parrot core for the Parrot 1.0 release, I'd argue that for now we need to continue to incubate the nascent libraries inside Parrot until a truly viable replacement can be created. > Why should it be included at the cost of increased > complexity in configuration, build and testing? I don't think that argues for not including features/libraries/what have you. That argues for making config/build/test clean, easy, and fast. > These lead to even bigger questions: > > * Why do we have all these configuration steps in the first place? > Which ones are necessary for Parrot? And which ones are there simply > because someone with a commit bit wanted that feature? As I mentioned above, probably most of these are not *necessary*. However, I think at least some of those with commit bits believe they are a good idea -- I don't have a commitbit, so multiple commit holders helped me with getting this accepted and working cross-platform. > And, of course, there's the cage-cleaner's perspective: Very few of > these new config steps have app
[perl #53142] [TODO] Cage-cleaner's request: PDD for configuration; Create RTs for new or heavily modified config steps
On Mon Apr 21 16:21:18 2008, geoff wrote: > > Two of these are from me (auto::opengl and gen::opengl). I had > attempted to discuss OpenGL bindings on p-p and in IRC multiple times in > the past; in each case the discussion either veered off into technical > details or was Warnocked. > > No, I didn't create an RT [TODO] ticket, because I didn't know that was > required. However, it seems redundant with both A) previous > discussions, and B) discussion that occured on the RT [NEW] ticket I did > open for my feature patch. > I see that I was wrong; you did indeed create an RT for discussion of this in RT 52988. And in fact I read that ticket. I apologize for the error. And it really doesn't matter whether it's called [TODO] or [NEW]. kid51
Re: [perl #53142] [TODO] Cage-cleaner's request: PDD for configuration; Create RTs for new or heavily modified config steps
On Sun, 20 Apr 2008 19:01:44 -0700 James Keenan (via RT) <[EMAIL PROTECTED]> wrote: Hi! As one of the guilty parties, I'm not sure whether I get a vote, but... > * Is new configuration step X::X *necessary* for the functioning > of the Parrot virtual machine? Frankly, probably nothing but the basic "does the compiler exist, and is it sane" type of tests meet that qualification. > * If new step X::X is not necessary for Parrot, what makes it > *desirable*? Why should it be included at the cost of increased > complexity in configuration, build and testing? When I checked in Opengl, it did seem like something that wasn't absolutely necessary. But I have to admit, I checked it in for other reasons. My reasoning was as follows: 1. It seemed more relevant than some stuff that's already in parrot. (I have more machines with OpenGL installed than have postgresql, for example.) 2. The author (Geoff) was responsive, willing and able to fix issues as they arose. Thus, if someone had a problem, we also had someone motivated to fix it. (Your process of silently writing tests, while very helpful and appreciated, negated this effect somewhat.) 3. We didn't have a release pending, thus we are not in feature freeze. > I would like to propose both short-term and long-term remedies. > > Short-term: If you are proposing a new configuration step, or doing > a significant overhaul of any existing step, please post an RT with > the code and with a [TODO] tag several days ahead of time. This > will give people a chance to run it on different OSes right away, > without compromising trunk. And if I get advance notice of any new > config step, I pledge to work with you to develop tests for that step. > > Long-term: We need a Parrot design document on configuration. Such > a document should cover what configuration is, why we have decided > to include the configuration steps already there, what we need and > what we don't need. Such a document should distinguish between what > we need between now and 1.0 OTOH and post-1.0 OTO. And we also need a document defining what steps an implementer should follow when adding or modifying configuration steps. You are right, the process for OpenGL was a bit rocky, but in my defense, "I didn't know any better". Actually, I don't really know much at all about the config system, or the testing thereof. docs/configuration.pod doesn't seem to mention tests at all. Maybe if it did, then the next time someone like me comes along and breaks everything, then you'll have something to whack them over the head with. All this feature detection stuff is very interdependent, and when a new feature comes along without sufficient testing, there is a chance that it will get in everyone else's way. So in the short term, where each such feature incurs some maintenance overhead and breakage affects people working on unrelated things, you are making a very valid point. In the longer term, I am hoping that we end up with a sort of "CPAN for Parrot". Specifically, for all of: Parrot applications, Parrot language modules, and Parrot library-wrapper plugins, like opengl. (And gettext. And readline. And sdl. And postgresql. And bigint.) And they can all do whatever system detection they need, and they can all depend on each other as needed. But the core of that strategy is, if these things have their own detection/generation process which isn't always run for everybody, they don't get in the way of people who don't care about them. So I guess my idea of the the status quo is, "until we can split our thousands of obscure features into separate packages, we sorta just have to live with them". But maybe we could have a happy medium: suppose you only get opengl when you specify --enable-opengl on the command line? Or it could be generated from "make opengl" or by running "make" in a special directory or some such? This kind of mechanism might not be good in the long term, but in the short term, it should prevent people from stomping on each other so much. Another note, slightly off-topic: does OpenGL actually need a configuration/detection step at all? I notice neither SDL or PostgreSQL seem to have one. Maybe they're detecting everything at runtime, or maybe their generated stuff runs from make instead of from configure? On the other hand, the config system is modularized into nice neat little steps, which makes them terribly easy to write and maintain, so it seems a shame not to use them. :) Mark
[perl #53142] [TODO] Cage-cleaner's request: PDD for configuration; Create RTs for new or heavily modified config steps
On Mon Apr 21 16:21:18 2008, geoff wrote: > > As a non-core contributor, my impression is that there is no top-down > plan. Parrot's development appears very much guided by dynamic tension > between the real bottom-up work, docs ranging from prescriptive to > descriptive to imaginative, and a *desire* to have a top-down plan. > Personally, I think this dynamic tension is healthy, and trying to limit > one facet in deference to the others seems counterproductive. > I'm mostly in agreement. It just seems to me that the configuration ought to be settling down as we near 1.0. > [snip] But see the next question. > > > * If new step X::X is not necessary for Parrot, what makes it > > *desirable*? > > [snip] > Thus I'm in favor of including what I see as basic cross-language > bindings for a number of cross-platform libraries -- crypto, database, > 2D graphics, 3D graphics, email, common network protocols, compression, > and so on. > > But let me take the opposing view for the moment that we *don't* want to > include such libraries for Parrot 1.0. Parrot is finally reaching the > point where creating such libraries is not only possible, but reasonable > without worrying that all of the code will have to be rewritten multiple > times before we get to 1.0. It seems inevitable that people will > scratch their own itches and start to develop such libraries -- this is > borne out by the very existence of the config steps you mention. > > These libraries need some forum for being tested on different platforms, > bugs worked through, and so on. In addition, there is still enough > churn in PIR and Parrot itself that it is desirable to make sure that > global design changes are propagated to these libraries as well. Right > now there is no good place for this other than the Parrot codebase > itself. Even if we decide to split out libraries from the Parrot core > for the Parrot 1.0 release, I'd argue that for now we need to continue > to incubate the nascent libraries inside Parrot until a truly viable > replacement can be created. > Very good points -- on both sides of the issue! > > > Short-term: If you are proposing a new configuration step, or doing > > a significant overhaul of any existing step, please post an RT with > > the code and with a [TODO] tag several days ahead of time. This will > > give people a chance to run it on different OSes right away, without > > compromising trunk. And if I get advance notice of any new config > > step, I pledge to work with you to develop tests for that step. > > Why is RT[TODO] better than RT[NEW], which according to submissions.pod > is the proper way to submit a new feature? (And the way that I > submitted my patch, once I learned about that.) > As mentioned in another post, what I'm really hoping for is an RT like the one you submitted -- regardless of tag. > > Long-term: We need a Parrot design document on configuration. Such > > a document should cover what configuration is, why we have decided to > > include the configuration steps already there, what we need and what > > we don't need. Such a document should distinguish between what we > > need between now and 1.0 OTOH and post-1.0 OTO. > > This would be a very good idea. I was stumbling through with cargo > culting and guesstimation. I would rather have just been able to read a > good doc. > Thank you very much. This multiplies by 3 or 4 the amount of discussion we've had on list about these issues.
[perl #53126] [TODO] config/auto/digest.pm: New config step needs rationale, lacks tests
On Mon Apr 21 07:11:23 2008, [EMAIL PROTECTED] wrote:
>
> I prefer the die behavior, because with it, I don't forget to add tests
> with auto::crypto.
>
So I'm not alone, after all ;-)
> Now, I think the name gen::digest is not good.
> I prefer gen::crypto because :
> 1) same as auto::crypto
> 2) libcrypto contains cypher algo (not only digest), so we could add
> some PMC wrapper (for example : DES, ...)
>
The patch attached renames gen::digest to gen::crypto and makes
associated changes.
I had one problem pulling the patch. For some reason,
config/gen/digest.pm was showing up in Subversion as a "binary" type. I
couldn't figure out how to fix that, so if we decide to change the
file's name and apply this patch, we may have to do a separate 'svn rm
config/gen/digest.pm' to get everything in place.
But that should be no impediment to reviewing the patch.
Thank you very much.
kid51
Index: lib/Parrot/Configure/Step/List.pm
===
--- lib/Parrot/Configure/Step/List.pm (.../trunk) (revision 27092)
+++ lib/Parrot/Configure/Step/List.pm (.../branches/gencrypto)
(revision 27100)
@@ -69,7 +69,7 @@
auto::icu
gen::config_h
gen::core_pmcs
-gen::digest
+gen::crypto
gen::parrot_include
gen::opengl
gen::languages
Index: MANIFEST
===
--- MANIFEST(.../trunk) (revision 27092)
+++ MANIFEST(.../branches/gencrypto)(revision 27100)
@@ -1,7 +1,7 @@
# ex: set ro:
# $Id$
#
-# generated by tools\dev\mk_manifest_and_skip.pl Mon Apr 21 20:09:14 2008 UT
+# generated by tools/dev/mk_manifest_and_skip.pl Mon Apr 21 23:13:41 2008 UT
#
# See tools/dev/install_files.pl for documentation on the
# format of this file.
@@ -299,8 +299,8 @@
config/gen/config_pm/config_lib.in []
config/gen/config_pm/myconfig.in[]
config/gen/core_pmcs.pm []
-config/gen/digest.pm[]
-config/gen/digest/digest_pmc.in []
+config/gen/crypto.pm[]
+config/gen/crypto/digest_pmc.in []
config/gen/languages.pm []
config/gen/makefiles.pm []
config/gen/makefiles/CFLAGS.in []
@@ -3526,6 +3526,7 @@
t/steps/gen_config_h-01.t []
t/steps/gen_config_pm-01.t []
t/steps/gen_core_pmcs-01.t []
+t/steps/gen_crypto-01.t []
t/steps/gen_languages-01.t []
t/steps/gen_makefiles-01.t []
t/steps/gen_opengl-01.t []
Index: MANIFEST.SKIP
===
--- MANIFEST.SKIP (.../trunk) (revision 27092)
+++ MANIFEST.SKIP (.../branches/gencrypto)(revision 27100)
@@ -1,6 +1,6 @@
# ex: set ro:
# $Id$
-# generated by tools/dev/mk_manifest_and_skip.pl Sat Apr 19 12:18:20 2008 UT
+# generated by tools/dev/mk_manifest_and_skip.pl Mon Apr 21 23:13:41 2008 UT
#
# This file should contain a transcript of the svn:ignore properties
# of the directories in the Parrot subversion repository. (Needed for
@@ -1183,6 +1183,9 @@
^languages/scheme/t/syn/.*\.pir/
^languages/scheme/t/syn/.*\.scheme$
^languages/scheme/t/syn/.*\.scheme/
+# generated from svn:ignore of 'languages/squaak/'
+^languages/squaak/Makefile$
+^languages/squaak/Makefile/
# generated from svn:ignore of 'languages/tcl/'
^languages/tcl/.*\.pdb$
^languages/tcl/.*\.pdb/
Index: t/steps/gen_crypto-01.t
===
--- t/steps/gen_crypto-01.t (.../trunk) (revision 0)
+++ t/steps/gen_crypto-01.t (.../branches/gencrypto)(revision 27100)
@@ -0,0 +1,50 @@
+#! perl
+# Copyright (C) 2007-2008, The Perl Foundation.
+# $Id$
+# gen_crypto-01.t
+
+use strict;
+use warnings;
+use Test::More tests => 2;
+use Carp;
+use lib qw( lib );
+use_ok('config::gen::crypto');
+
+=for hints_for_testing This is just a stub so that Configure.pl will run.
+
+=cut
+
+pass("Completed all tests in $0");
+
+### DOCUMENTATION ###
+
+=head1 NAME
+
+ gen_crypto-01.t - test config::gen::crypto
+
+=head1 SYNOPSIS
+
+% prove t/steps/gen_crypto-01.t
+
+=head1 DESCRIPTION
+
+The files in this directory test functionality used by F.
+
+The tests in this file test config::gen::crypto.
+
+=head1 AUTHOR
+
+James E Keenan
+
+=head1 SEE ALSO
+
+config::gen::crypto, F.
+
+=cut
+
+# Local Variables:
+# mode: cperl
+# cperl-indent-level: 4
+# fill-column: 100
+# End:
+# vim: expandtab shiftwidth=4:
Property changes on: t
Re: [perl #53126] [TODO] config/auto/digest.pm: New config step needs rationale, lacks tests
On Sun, 2008-04-20 at 19:28 -0700, James Keenan via RT wrote: > As to the question of whether people know how to write tests: I think > there is empirical evidence that people know how to write tests for the > configuration steps. For example, when François earlier submitted > config/auto/crypto.pm, it came with a very nice set of test files right > from the start. In the past I have worked with people around this and I > pledge to continue to do so in the future. I disagree. Yes, there is empirical evidence that SOME people understand how to do this. I didn't, and couldn't figure out what to do in a time frame that wouldn't discourage me from doing the actual work: coding the configure steps themselves, which I already found unclear and difficult. I am strongly in favor of testing, but before we expect new contributors to create their own config tests, documentation must exist about how to do so properly. And we can't lose sight of the fact that the tests are not the product, and in fact there is only one true test of the configure steps: do they result in a functioning build of Parrot? Any other type of config test in some sense boils down to stupidity checks. For example, can we quickly detect that a change broke something obvious without having to run the entire Parrot test suite across all platforms? My experience so far has been that jumping through all the hurdles necessary to contribute to Parrot is difficult and time consuming. It has taken me *months* of part time effort to get to the stage that I could meaningfully contribute, and get my work accepted. I'm sure that there are others who will not put in that effort, and I personally think that's a bad thing. chromatic often points out that it's hard to get high velocity on a project in which everyone is working gratis or nearly so. I agree. But that's not the only thing reducing Parrot's velocity. It's a REALLY complex beast, and the barrier to entry is relatively high, both in terms of how much must be understood before work can commence, and in terms of essentially artificial barriers such as standards, processes, and required "check off" items like config tests. Note that I am *NOT* saying that standards and processes are a bad thing in general -- far from it -- merely that we need to be aware of the fact that they are definitely barriers to new contributors and may slow the work of existing contributors. Thus, each new hurdle must be balanced against the value that comes of it. chromatic had these things to say earlier: > I suspect that people aren't adding test files for configuration > steps because: > > 1) they don't know how > 2) the existing tests for configuration steps are big blobs of messy, >duplicated code >From my personal experience, right on both counts. > I'm all for getting as much value out of our tests as possible (I > could write another book about it), but I keep thinking we're heading > down the wrong path with our configuration tests. Our configuration > system ought to be getting easier to understand, to maintain, and > modify. Is it? Not so far as I've seen. I basically got my new configure steps working by reverse engineering. Then when I got the error for no config tests for the new steps, I looked at the existing config tests, thought "You have GOT to be kidding me; it will take eons to do this properly, and I don't even know what I want to test *for*", copied and pasted stubs to silence the error, and went on with my day. After my code was accepted and committed, kid51 began to write tests for my configure steps, but he ran across the very problem I had decided to avoid. Because I did not know in advance the proper way to write cross-platform config *steps* for OpenGL, I could not write proper *tests*. As various of us continued to modify the OpenGL config steps to work on more platforms, some of kid51's tests were invalidated. To me, this was a perfect example of tests getting in the way, rather than helping. Effort was wasted attempting to write tests for an amorphous blob. As the production release of Parrot nears, having copious tests for details of the config process will no doubt help us maintain quality during the final stages. For now, however, I think the requirement to have 100% coverage of config tests should be deemphasized somewhat. -'f
[perl #53142] [TODO] Cage-cleaner's request: PDD for configuration; Create RTs for new or heavily modified config steps
On Mon Apr 21 17:02:58 2008, [EMAIL PROTECTED] wrote: [snip] > > > * Is new configuration step X::X *necessary* for the functioning > > of the Parrot virtual machine? > > Frankly, probably nothing but the basic "does the compiler exist, and is > it sane" type of tests meet that qualification. > If we do write a PDD for configuration, we should probably identify the config steps that do this and distinguish them from the library-locators. > > [snip] > > And we also need a document defining what steps an implementer should > follow when adding or modifying configuration steps. ... docs/configuration.pod doesn't > seem to mention tests at all. Once everyone has had her/his say, on this issue, we can remedy that. > > All this feature detection stuff is very interdependent, and when a > new feature comes along without sufficient testing, there is a chance > that it will get in everyone else's way. So in the short term, where > each such feature incurs some maintenance overhead and breakage affects > people working on unrelated things, you are making a very valid point. > > In the longer term, I am hoping that we end up with a sort of "CPAN for > Parrot". Specifically, for all of: Parrot applications, Parrot language > modules, and Parrot library-wrapper plugins, like opengl. (And gettext. > And readline. And sdl. And postgresql. And bigint.) And they can > all do whatever system detection they need, and they can all depend on > each other as needed. > > But the core of that strategy is, if these things have their own > detection/generation process which isn't always run for everybody, they > don't get in the way of people who don't care about them. > > So I guess my idea of the the status quo is, "until we can split our > thousands of obscure features into separate packages, we sorta just > have to live with them". But maybe we could have a happy medium: > suppose you only get opengl when you specify --enable-opengl on the > command line? Or it could be generated from "make opengl" or by > running "make" in a special directory or some such? This kind of > mechanism might not be good in the long term, but in the short term, it > should prevent people from stomping on each other so much. > Very good points. > Another note, slightly off-topic: does OpenGL actually need a > configuration/detection step at all? I notice neither SDL or > PostgreSQL seem to have one. Maybe they're detecting everything at > runtime, or maybe their generated stuff runs from make instead of from > configure? As purl would say, I haven't the foggiest how they work in Parrot. On the other hand, the config system is modularized into > nice neat little steps, which makes them terribly easy to write and > maintain, so it seems a shame not to use them. :) > particle suggested on #parrot the weekend before last that the config system should be completely pluggable, which means that, among other things, config step classes should be able to call other config step classes from inside them. That would mean that our config system would have to be even more modularized than it is today. Thanks for taking the time to provide this feedback. kid51
Re: [perl #53142] [TODO] Cage-cleaner's request: PDD for configuration; Create RTs for new or heavily modified config steps
On Mon, 2008-04-21 at 17:06 -0700, James Keenan via RT wrote: > I'm mostly in agreement. It just seems to me that the configuration > ought to be settling down as we near 1.0. Absolutely. However, as of 0.6.1 we are at the stage where outsiders like myself can finally meaningfully contribute -- we should expect a few more monthly releases with significant churn before we get close enough to 1.0 to worry that we have not fully stabilized. Heck, we've got some months before some of the core PDDs are up for implementation, so I expect that we are at least a season or two from having to worry that our churn is too high. (Not that we shouldn't expect high quality even now -- we should just expect a lot of change in the coming months, purely from where Parrot is in its development cycle.) > As mentioned in another post, what I'm really hoping for is an RT like > the one you submitted -- regardless of tag. Ah, OK, fair enough. > Thank you very much. This multiplies by 3 or 4 the amount of discussion > we've had on list about these issues. You're welcome, and thank you very much for listening! -'f
Re: Parrot at YAPC::NA::2008 in Chicago June 16-18
Bob Rogers wrote: I don't expect to be able to co-lead (since, for one thing, that would require putting in significant time in advance), but I would be willing to help TA such a thing. I suspect it would be valuable to have a number of TAs with diverse areas of trouble-shooting expertise, since (for example) I would be pretty useless if someone was having build problems on Windows. On the basis of doing two of these buildfests in the past month, I would say that TAs are what we *most* need. Except for the first 5 and last 10 minutes of the session, all the Parrot team members present will be moving around the room coaching people on how to configure and build Parrot, then build Rakudo ... or any other language that, as of YAPC time, we can build on top of Parrot. This is not intended to be an "expert standing in front of the room, lecturing for 75 minutes, then taking questions" type of presentation. So I look forward to seeing you there and working with you. Jim Keenan
YAPC::NA::2008 status updates needed
1. If you have had a Parrot- or Rakudo-oriented presentation accepted at YAPC::NA::2008 in Chicago, please add your name and presentation's name to: http://www.perlfoundation.org/parrot/index.cgi?yapc_na_2008 2. The Parrot/Rakudo buildfest workshop has been accepted. If you are able to be present during this session and help coach people to get to Hello World either in Perl 6 on Parrot -- or in any other language on Parrot -- then please add your name to the "Parrot and Rakudo Buildfest" section of the page cited above. Thank you very much. kid51
Re: [perl #53142] [TODO] Cage-cleaner's request: PDD for configuration; Create RTs for new or heavily modified config steps
On Mon, 2008-04-21 at 17:02 -0700, Mark Glines wrote: > 1. It seemed more relevant than some stuff that's already in > parrot. (I have more machines with OpenGL installed than have > postgresql, for example.) Ditto, but of course, I'm biased. :-) > 2. The author (Geoff) was responsive, willing and able to fix issues as > they arose. Thus, if someone had a problem, we also had someone > motivated to fix it. Very much so. I figured if I wasn't responsive, my patch had no hope. > 3. We didn't have a release pending, thus we are not in feature freeze. As I mentioned in another message, this timing was intentional on my part. > And we also need a document defining what steps an implementer should > follow when adding or modifying configuration steps. You are right, the > process for OpenGL was a bit rocky, but in my defense, "I didn't know > any better". Actually, I don't really know much at all about the > config system, or the testing thereof. Ditto that. And for someone who is also trying to learn the ins and outs of Parrot itself, this was a significant part of the challenge to creating an acceptable patch. I finally had to say "I expect breakage, so best to choose my timing well, tell people I expect failures, and respond to bug reports as fast as possible." > docs/configuration.pod doesn't > seem to mention tests at all. Maybe if it did, then the next time > someone like me comes along and breaks everything, then you'll have > something to whack them over the head with. This seems a bit harsh. It's been some years since I followed Linux kernel development, but as I recall there used to be a 1-2 week period after each point release when new and possibly risky stuff was allowed to go in, knowing that there would be time to deal with the issues before the next freeze. Since we have fixed monthly release cycles, I propose the same for Parrot -- the week following each release, the barriers to entry for risky patches should be lowered somewhat. At the very least, this would allow new contributors like myself (or existing contributors working on unfamiliar parts of Parrot) to have a chance to get in-progress work accepted, knowing there will be time to fix problems, without always facing too many hurdles to acceptance. > So I guess my idea of the the status quo is, "until we can split our > thousands of obscure features into separate packages, we sorta just > have to live with them". But maybe we could have a happy medium: > suppose you only get opengl when you specify --enable-opengl on the > command line? Or it could be generated from "make opengl" or by > running "make" in a special directory or some such? This kind of > mechanism might not be good in the long term, but in the short term, it > should prevent people from stomping on each other so much. Actually, I would reverse these. In the long term, a scheme including --enable-foo flags seems reasonable (we already have --disable-foo, and the OpenGL steps respect --disable-opengl). In the short term, I think it's a bad idea, for the same reason that I think optimized parrots should be built by default. Anything that is not built by default risks not getting tested sufficiently now (when there is ample time to fix problems) before we get close to Parrot 1.0 (at which time if we discover a large problem, we are stuck with some hard decisions). > Another note, slightly off-topic: does OpenGL actually need a > configuration/detection step at all? I notice neither SDL or > PostgreSQL seem to have one. Maybe they're detecting everything at > runtime, or maybe their generated stuff runs from make instead of from > configure? I don't know this for a fact, but I believe that both of these predate the modern configuration/detection system, are not really integrated in the sense that everything Just Works after "perl Configure.pl; make", and don't have to address issues like different vendors providing incompatible headers. (In my case, different GLUT vendors disagreed about what the different GLUT API versions meant, which makes API versioning ... suboptimal.) > On the other hand, the config system is modularized into > nice neat little steps, which makes them terribly easy to write and > maintain, so it seems a shame not to use them. :) Well, I wouldn't call them "terribly easy to write", but I do think the basic config design makes a lot of sense, and legacy components (like the aforementioned SDL and PostgreSQL) should probably be updated to use this system. For what it's worth, though the process was difficult, I am happy with the results of using the official config system for my OpenGL code. -'f
Re: [perl #53142] [TODO] Cage-cleaner's request: PDD for configuration; Create RTs for new or heavily modified config steps
On Monday 21 April 2008 17:02:27 Mark Glines wrote: > Another note, slightly off-topic: does OpenGL actually need a > configuration/detection step at all? I notice neither SDL or > PostgreSQL seem to have one. Maybe they're detecting everything at > runtime, or maybe their generated stuff runs from make instead of from > configure? On the other hand, the config system is modularized into > nice neat little steps, which makes them terribly easy to write and > maintain, so it seems a shame not to use them. :) PostgreSQL and SDL use NCI to link against existing shared libraries. As I understand the OpenGL code (and the crypto code), they actually build C code, which is a little more involved. -- c
Re: [perl #52842] [CORE] Remove stack.ops and user_stack
On Sat, Apr 12, 2008 at 08:26:34PM -0700, Bob Rogers wrote: >The ops in src/ops/stack.ops are holdovers from the bad old days of > limited registers. In modern times, it is more versatile (and probably > faster) to create an array and use it as an explicit stack via push and > pop operations. I've conducted a review of the codebase to see where stack ops are being used. For reference, the deprecated stack opcodes are entrytype, depth, lookback, save, savec, restore, and rotate_up. (The "saveall" and "restoreall" opcodes are being handled by another ticket.) Other than t/op/stacks.t (which will go away when this issue is resolved), the following files or subsystems seem to use one or more of the deprecated opcodes: languages/BASIC languages/befunge examples/pasm/stack.pasm examples/pasm/nanoforth.pasm examples/pasm/xml_parser.pasm examples/benchmarks/primes2.pasm examples/benchmarks/primes2_i.pasm Here's my vote for the disposition of each of these: 1. languages/BASIC has the save/restore opcodes in it, but it also seems to have some opcodes such as pushp and popp that have been gone for over two years. That said, the various *.bas sample files all seem to compile and not use any of save/restore/pushp/popp, so I'm thinking we can leave BASIC alone even after removing the stack ops. 2. languages/befunge uses save/restore in a few macros in its *.pasm files. It looks like it might be a good candidate for converting things into PIR functions... but if we want to leave it as PASM then there will be a fair bit of macro conversion to be done. 3. examples/pasm/stack.pasm should simply disappear, since we will no longer have any stack ops to demonstrate. :-) 4. The remaining examples/* files are all in PASM, and somewhat ancient PASM at that. (I guess all PASM source is pretty old, though.) Do we really need to keep these examples around-- are they likely to be useful to anyone? If no, I say we should just get rid of them. If we still need the PASM examples, then it's probably better to just rewrite these entirely than to try to fix up what is already there. Comments welcomed. Pm
Re: Class names are virtual
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: Second, I don't like the concept of a virtual method that returns a type. That horribly mixes type level and value level. From the They are mixed! Perl treats types as first-class objects. For functions, types don't need to be treated specially from other arguments as in C++. OUTER::C is lexical. But it sounds like the explanation you are giving is the same.
Re: Context and return types question
Brandon S. Allbery KF8NH allbery-at-ece.cmu.edu |Perl 6| wrote: my ($x, :$named) = foo; # or something like that That looks to me like a form of positional extraction. (Of course, my hit rate on p6 stuff has been remarkably low of late...) It's not just positional, but allows for named arguments too. It is exactly like calling a function: named arguments match to parameters with those names, then any left over are positional.
Re: Another Optimization Target: bsr and stacks
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 18:54:19 -0400
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 15:42:27 -0500
. . . If it looks like having a separate stack for bsr/ret is
workable then I'll go at it that way.
Fair enough. FWIW, I'm now working on a simple hack that should show
how much speedup we can expect.
The hack is attached; it isn't headerized, has some coding standards
failures, and leaks memory, so it's incomplete. Disappointingly, it
produces an overall speedup of less than 4% in building gen_actions.pir
in r27087 (which has chromatic's ref-counting speedup).
And it fails t/pmc/continuation.t test 4 ("continuations preserve
bsr/ret state"), as expected. I don't think a 4% speedup is worth it,
so I'm giving up on it. Maybe somebody else will find a way to improve
it.
A warning, though: Do "make clean" after applying the patch, or the
new "parrot" will consume all memory. I suspect there is some code that
uses Parrot_Context that doesn't have the right dependencies, so is not
recompiled when interpreter.h is changed.
-- Bob
Re: Another Optimization Target: bsr and stacks
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 18:54:19 -0400
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 15:42:27 -0500
. . . If it looks like having a separate stack for bsr/ret is
workable then I'll go at it that way.
Fair enough. FWIW, I'm now working on a simple hack that should show
how much speedup we can expect.
The hack is attached; it isn't headerized, has some coding standards
failures, and leaks memory, so it's incomplete. Disappointingly, it
produces an overall speedup of less than 4% in building gen_actions.pir
in r27087 (which has chromatic's ref-counting speedup).
And it fails t/pmc/continuation.t test 4 ("continuations preserve
bsr/ret state"), as expected. I don't think a 4% speedup is worth it,
so I'm giving up on it. Maybe somebody else will find a way to improve
it.
A warning, though: Do "make clean" after applying the patch, or the
new "parrot" will consume all memory. I suspect there is some code that
uses Parrot_Context that doesn't have the right dependencies, so is not
recompiled when interpreter.h is changed.
-- Bob
[P.S. Oops.]
*** Give bsr/ret a stack of their own ***
* include/parrot/interpreter.h:
+ Add bsr_stack, bsr_allocated, and bsr_stack_size members to
Parrot_Context.
* src/gc/register.c:
+ (init_context): Initialize bsr_stack.
* src/stacks.c:
+ (Parrot_bsr_stack_push, Parrot_bsr_stack_pop): New. (Probably
need a better permanent home for them.)
* src/ops/core.ops:
+ (bsr, ret, jsr): Use Parrot_bsr_stack_push/Parrot_bsr_stack_pop.
Diffs between last version checked in and current workfile(s):
Index: include/parrot/interpreter.h
===
--- include/parrot/interpreter.h(revision 27087)
+++ include/parrot/interpreter.h(working copy)
@@ -218,6 +218,10 @@
struct Stack_Chunk *user_stack; /* Base of the scratch stack */
PMC *lex_pad; /* LexPad PMC */
struct Parrot_Context *outer_ctx; /* outer context, if a closure */
+opcode_t **bsr_stack; /* pointer to bsr/ret addresses, lazily
allocated
+ by Parrot_bsr_stack_push. */
+UINTVAL bsr_allocated; /* allocated bsr_stack size */
+UINTVAL bsr_stack_size;/* used bsr_stack size */
UINTVAL warns; /* Keeps track of what warnings
* have been activated */
UINTVAL errors;/* fatals that can be turned off */
Index: src/gc/register.c
===
--- src/gc/register.c (revision 27087)
+++ src/gc/register.c (working copy)
@@ -297,6 +297,9 @@
ctx->current_cont = NULL;
ctx->current_object = NULL; /* RT#46181 who clears it? */
ctx->current_HLL = 0;
+/* We don't need to initialize bsr_allocated or bsr_stack_size, because
they
+ won't be examined if bsr_stack is NULL. */
+ctx->bsr_stack = NULL;
if (old) {
/* some items should better be COW copied */
Index: src/stacks.c
===
--- src/stacks.c(revision 27087)
+++ src/stacks.c(working copy)
@@ -484,6 +484,49 @@
height, dynamic_env, dynamic_env->name);
}
+/*** bsr/ret stack support ***/
+
+PARROT_API
+void
+Parrot_bsr_stack_push(PARROT_INTERP, ARGIN(opcode_t *return_addr))
+{
+parrot_context_t *context = CONTEXT(interp);
+
+if (! context->bsr_stack) {
+/* Need a new stack. */
+UINTVAL size = 100;
+/* fprintf(stderr, "[first alloc for %p]\n", context); */
+context->bsr_allocated = size;
+context->bsr_stack_size = 0;
+context->bsr_stack = (opcode_t
**)mem_sys_allocate(size*sizeof(opcode_t *));
+}
+else if (context->bsr_stack_size >= context->bsr_allocated) {
+/* Need a bigger stack. */
+UINTVAL size = 2*context->bsr_allocated;
+/* fprintf(stderr, "[realloc for %p (currently %p), from %d to %d]\n",
+context, context->bsr_stack,
+(int)context->bsr_allocated, (int)size); */
+if (size > 100)
+real_exception(interp, NULL, 1, "Too many 'bsr' calls\n");
+context->bsr_stack = (opcode_t
**)mem_sys_realloc(context->bsr_stack, size*sizeof(opcode_t *));
+context->bsr_allocated = size;
+}
+
+/* Push it. */
+context->bsr_stack[context->bsr_stack_size++] = return_addr;
+}
+
+PARROT_API
+opcode_t *
+Parrot_bsr_stack_pop(PARROT_INTERP)
+{
+parrot_context_t *context = CONTEXT(interp);
+
+if (! context->bsr_stack || context->bsr_stack_size == 0)
+real_exception(interp, NULL, 1, "'ret' without 'bsr'\n");
+return context->bsr_stack[--context->bsr_stack_size];
+}
+
/*
=back
Index: src/ops/core.ops
=
Re: [perl #52842] [CORE] Remove stack.ops and user_stack
From: "Patrick R. Michaud via RT" <[EMAIL PROTECTED]> Date: Mon, 21 Apr 2008 18:00:31 -0700 On Sat, Apr 12, 2008 at 08:26:34PM -0700, Bob Rogers wrote: >The ops in src/ops/stack.ops are holdovers from the bad old days of > limited registers. In modern times, it is more versatile (and probably > faster) to create an array and use it as an explicit stack via push and > pop operations. I've conducted a review of the codebase to see where stack ops are being used . . . Comments welcomed. Pm This all agrees with what I found. Old PASM examples are counterproductive; they teach obsolete techniques, and we should be steering beginners towards PIR in any case. So I'd say just get rid of them. -- Bob
Re: Another Optimization Target: bsr and stacks
On Monday 21 April 2008 19:17:34 Bob Rogers wrote:
> The hack is attached; it isn't headerized, has some coding standards
> failures, and leaks memory, so it's incomplete. Disappointingly, it
> produces an overall speedup of less than 4% in building gen_actions.pir
> in r27087 (which has chromatic's ref-counting speedup).
>
>And it fails t/pmc/continuation.t test 4 ("continuations preserve
> bsr/ret state"), as expected. I don't think a 4% speedup is worth it,
> so I'm giving up on it. Maybe somebody else will find a way to improve
> it.
I'm not sure this approach will work overall. Despite the word "stack", it's
a linked list -- and it has to be a linked list, because the call chain of
continuations isn't a stack. Most things will work with an array, but once
in a while you'll get a continuation that wants to go somewhere else than its
caller when invoked, and you branch the stack then. If there's a single
array for all of these, you'll overwrite at least one destination every time
you get to that depth again.
-- c
Re: [perl #52840] [CAGE] Recode PIR and PASM tests that use stack.ops
I found the results of an experiment (done in r26933) where I used
the attached patch to disable all stack ops, and then did "make test".
(I had misplaced it, which is why I didn't post it earlier; sorry about
that.) Here are the failing tests:
Failed Test Stat Wstat Total Fail Failed List of Failed
t/doc/pod.t 1 256 11 100.00% 1
t/examples/pasm.t2 512 52 40.00% 3-4
t/examples/pir.t 1 256191 5.26% 10
t/op/jit.t 1 256621 1.61% 55
t/op/stacks.t 20 512023 20 86.96% 1-20
t/op/trans.t20 512022 20 90.91% 1-20
t/pmc/array.t2 512132 15.38% 8-9
t/pmc/bigint.t 1 256441 2.27% 3
t/pmc/complex.t 4 1024534 7.55% 12-13 25-26
t/pmc/fixedbooleanarray.t2 512112 18.18% 7-8
t/pmc/fixedfloatarray.t 3 768113 27.27% 7-9
t/pmc/fixedintegerarray.t2 512152 13.33% 9-10
t/pmc/fixedpmcarray.t2 512152 13.33% 8-9
t/pmc/fixedstringarray.t 2 512132 15.38% 7-8
t/pmc/float.t 16 409642 16 38.10% 1-5 13-22 26
t/pmc/resizablebooleanarray.t2 512202 10.00% 6-7
t/pmc/resizablefloatarray.t 7 1792197 36.84% 8-14
t/pmc/resizableintegerarray.t2 512152 13.33% 6-7
t/pmc/resizablepmcarray.t2 512392 5.13% 11-12
t/pmc/sarray.t 3 768303 10.00% 13 17 23
t/pmc/string.t 1 256471 2.13% 3
(1 subtest UNEXPECTEDLY SUCCEEDED), 24 tests and 576 subtests skipped.
Failed 21/569 test scripts, 96.31% okay. 96/11165 subtests failed, 99.14%
okay.
So these tests will need to be updated.
-- Bob
* src/ops/stack.ops:
+ Make all stack ops throw exceptions.
Diffs between last version checked in and current workfile(s):
Index: src/ops/stack.ops
===
--- src/ops/stack.ops (revision 26786)
+++ src/ops/stack.ops (working copy)
@@ -37,7 +37,10 @@
=cut
+/* ' */
+
inline op saveall() :base_core {
+ real_exception(interp, NULL, 1, "Stack op 'saveall' used.\n");
Parrot_push_regs(interp);
/* these 2 opcodes change the register base pointer
* restart NEXT() reloads cached base pointers, and works with
@@ -49,6 +52,7 @@
}
inline op restoreall() :base_core {
+ real_exception(interp, NULL, 1, "Stack op 'restoreall' used.\n");
Parrot_pop_regs(interp);
restart NEXT();
}
@@ -80,6 +84,7 @@
Stack_Entry_t * const entry =
stack_entry(interp, CONTEXT(interp)->user_stack, $2);
+ real_exception(interp, NULL, 1, "Stack op 'entrytype' used.\n");
if (!entry) {
real_exception(interp, NULL, 99, "Stack Depth wrong");
}
@@ -96,6 +101,7 @@
=cut
inline op depth(out INT) :base_core {
+ real_exception(interp, NULL, 1, "Stack op 'depth' used.\n");
$1 = stack_height(interp, CONTEXT(interp)->user_stack);
goto NEXT();
}
@@ -120,6 +126,8 @@
op lookback(out INT, in INT) :base_core {
Stack_Entry_t * const entry =
stack_entry(interp, CONTEXT(interp)->user_stack, $2);
+
+ real_exception(interp, NULL, 1, "Stack op 'lookback' used.\n");
if (!entry) {
real_exception(interp, NULL, 99, "Stack depth wrong");
}
@@ -134,6 +142,8 @@
op lookback(out STR, in INT) :base_core {
Stack_Entry_t * const entry =
stack_entry(interp, CONTEXT(interp)->user_stack, $2);
+
+ real_exception(interp, NULL, 1, "Stack op 'lookback' used.\n");
if (!entry) {
real_exception(interp, NULL, 99, "Stack depth wrong");
}
@@ -148,6 +158,8 @@
op lookback(out NUM, in INT) :base_core {
Stack_Entry_t * const entry =
stack_entry(interp, CONTEXT(interp)->user_stack, $2);
+
+ real_exception(interp, NULL, 1, "Stack op 'lookback' used.\n");
if (!entry) {
real_exception(interp, NULL, 99, "Stack depth wrong");
}
@@ -162,6 +174,8 @@
op lookback(out PMC, in INT) :base_core {
Stack_Entry_t * const entry =
stack_entry(interp, CONTEXT(interp)->user_stack, $2);
+
+ real_exception(interp, NULL, 1, "Stack op 'lookback' used.\n");
if (!entry)
real_exception(interp, NULL, 99, "Stack depth wrong");
if (entry->entry_type != STACK_ENTRY_PMC) {
@@ -187,6 +201,7 @@
=cut
inline op save(in INT) :base_core {
+ real_exception(interp, NULL, 1, "Stack op 'save' used.\n");
INTVAL i = $1;
stack_push(interp,
&CONTEXT(interp)->user_stack, &i,
@@ -195,18 +210,21 @@
}
inline op save(in NUM) :base_core {
+ real_exception(interp, NULL, 1, "Stack op 'save' use
Re: [perl #52840] [CAGE] Recode PIR and PASM tests that use stack.ops
On Mon, Apr 21, 2008 at 11:04:13PM -0400, Bob Rogers wrote: Content-Description: message body text > t/op/jit.t 1 256621 1.61% 55 This one requires removing saveall and restoreall handling from imcc (done in the stacks branch). > t/op/stacks.t 20 512023 20 86.96% 1-20 This just tests the stack ops themselves, and will be removed. > t/op/trans.t20 512022 20 90.91% 1-20 > t/pmc/array.t2 512132 15.38% 8-9 > t/pmc/bigint.t 1 256441 2.27% 3 > t/pmc/complex.t 4 1024534 7.55% 12-13 25-26 > t/pmc/fixedbooleanarray.t2 512112 18.18% 7-8 > t/pmc/fixedfloatarray.t 3 768113 27.27% 7-9 > t/pmc/fixedintegerarray.t2 512152 13.33% 9-10 > t/pmc/fixedpmcarray.t2 512152 13.33% 8-9 > t/pmc/fixedstringarray.t 2 512132 15.38% 7-8 > t/pmc/float.t 16 409642 16 38.10% 1-5 13-22 26 > t/pmc/resizablebooleanarray.t2 512202 10.00% 6-7 > t/pmc/resizablefloatarray.t 7 1792197 36.84% 8-14 > t/pmc/resizableintegerarray.t2 512152 13.33% 6-7 > t/pmc/resizablepmcarray.t2 512392 5.13% 11-12 > t/pmc/sarray.t 3 768303 10.00% 13 17 23 > t/pmc/string.t 1 256471 2.13% 3 Done in trunk as of r27090. Pm
[perl #52840] [CAGE] Recode PIR and PASM tests that use stack.ops
As of r27105 these have all been recoded to avoid the stack.ops . The only exception is t/op/stacks.t, which can be removed when we remove the stack.ops in RT#52842 . Closing ticket, and thanks! Pm
[perl #52838] [CORE] Remove the saveall and restoreall ops
Done as of r27113. Pm
[perl #53168] Headerizer breaks on src/exec_dep.c
# New Ticket Created by Bob Rogers # Please include the string: [perl #53168] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=53168 > Here's what I get when I attempt "make headerizer" in r27087: . . . adv_named_set has no POD do_loadlib has no POD can't find HEADERIZER HFILE directive in 'src/exec_dep.c' at tools/build/headerizer.pl line 448. make: *** [headerizer] Error 255 [EMAIL PROTECTED]> It looks like 'src/exec_dep.c' is a generated file that should be excluded . . . somehow. -- Bob Rogers http://rgrjr.dyndns.org/
[perl #53170] Parrot crash during build of r27101 (PPC, OS X 10.5)
# New Ticket Created by "Seneca Cunningham" # Please include the string: [perl #53170] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=53170 > parrot crashes while generating src/Grammar_gen.pir. The last build attempted (on a different copy of the source tree) worked and was done right after the commits to get OpenGL working on OS X happened. This happens with both "make -j2" and a plain "make". ../../parrot -o TGE/Tree.pbc --output-pbc TGE/Tree.pir ../../parrot -o ../../runtime/parrot/library/TGE.pbc --output-pbc TGE.pir make -C compilers/nqp ../../parrot /opt/src/perl6/build-20080421-b/runtime/parrot/library/PGE/Perl6Grammar.pir \ --output=src/Grammar_gen.pir src/Grammar.pg make[1]: *** [nqp.pbc] Bus error make: *** [compilers.dummy] Error 2 herodotus:build-20080421-b seneca$ (gdb) r /opt/src/perl6/build-20080421/runtime/parrot/library/PGE/Perl6Grammar.pir --output=/opt/src/perl6/build-20080421/compilers/nqp/src/Grammar_gen.pir /opt/src/perl6/build-20080421/compilers/nqp/src/Grammar.pgStarting program: /opt/src/perl6/build-20080421/parrot /opt/src/perl6/build-20080421/runtime/parrot/library/PGE/Perl6Grammar.pir --output=/opt/src/perl6/build-20080421/compilers/nqp/src/Grammar_gen.pir /opt/src/perl6/build-20080421/compilers/nqp/src/Grammar.pg [...] Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x0019 0x0069092c in pobject_lives (interp=0x1709de0, obj=0x11) at src/gc/dod.c:190 190 if (PObj_is_live_or_free_TESTALL(obj)) (gdb) bt #0 0x0069092c in pobject_lives (interp=0x1709de0, obj=0x11) at src/gc/dod.c:190 #1 0x006e09dc in mark_stack (interp=0x1709de0, chunk=0x11) at src/stacks.c:66 #2 0x00850340 in Parrot_Continuation_mark (interp=0x1709de0, pmc=0x248f3e0) at continuation.pmc:89 #3 0x00690fac in Parrot_dod_trace_children (interp=0x1709de0, how_many=4294962039) at src/gc/dod.c:440 #4 0x00690d4c in trace_active_PMCs (interp=0x1709de0, trace_stack=1) at src/gc/dod.c:373 #5 0x00691f90 in Parrot_dod_ms_run (interp=0x1709de0, flags=1) at src/gc/dod.c:1130 #6 0x006920c0 in Parrot_do_dod_run (interp=0x1709de0, flags=1) at src/gc/dod.c:1179 #7 0x00694b78 in more_traceable_objects (interp=0x1709de0, pool=0x170a100) at src/gc/smallobject.c:144 #8 0x00694c80 in gc_ms_get_free_object (interp=0x1709de0, pool=0x170a100) at src/gc/smallobject.c:195 #9 0x00698928 in get_free_buffer (interp=0x1709de0, pool=0x170a100) at src/headers.c:106 #10 0x00699240 in new_string_header (interp=0x1709de0, flags=0) at src/headers.c:428 #11 0x005f7410 in string_make_direct (interp=0x1709de0, buffer=0x0, len=9, encoding=0x170a240, charset=0x170a3d0, flags=0) at src/string.c:713 #12 0x005f6c94 in string_concat (interp=0x1709de0, a=0x2252000, b=0x180ae30, Uflags=0) at src/string.c:468 #13 0x005f6f34 in string_append (interp=0x1709de0, a=0x2252000, b=0x180ae30) at src/string.c:531 #14 0x008e33c4 in get_attrib_index_keyed (interp=0x1709de0, self=0x21140e0, key=0x211b0e0, name=0x180ae30) at object.pmc:80 #15 0x008ef7e8 in Parrot_Object_set_attr_keyed (interp=0x1709de0, pmc=0x2497bc0, key=0x211b0e0, name=0x180ae30, value=0x2497b80) at object.pmc:284 #16 0x008b8c44 in initialize_parents (interp=0x1709de0, object=0x2497bc0, all_parents=0x22422c0) at class.pmc:332 #17 0x008bb1a8 in Parrot_Class_instantiate (interp=0x1709de0, pmc=0x21140e0, init=0x1838e80) at class.pmc:1118 #18 0x00621a50 in Parrot_new_p_s (cur_opcode=0x20c336c, interp=0x1709de0) at pmc.ops:93 #19 0x006dc684 in runops_slow_core (interp=0x1709de0, pc=0x20c336c) at src/runops_cores.c:219 #20 0x006a33d4 in runops_int (interp=0x1709de0, offset=3) at src/interpreter.c:916 #21 0x006a408c in runops (interp=0x1709de0, offs=3) at src/inter_run.c:104 #22 0x006a43ac in runops_args (interp=0x1709de0, sub=0x209f860, obj=0x1838e80, meth_unused=0x0, sig=0x97214c "vP", ap=0xb2c4 "\002$?") at src/inter_run.c:230 #23 0x006a4550 in Parrot_runops_fromc_args (interp=0x1709de0, sub=0x209f860, sig=0x97214c "vP") at src/inter_run.c:299 #24 0x00683d54 in Parrot_runcode (interp=0x1709de0, argc=3, argv=0xb484) at src/embed.c:941 #25 0x00947608 in imcc_run_pbc (interp=0x1709de0, obj_file=0, output_file=0x0, argc=3, argv=0xb484) at compilers/imcc/main.c:781 #26 0x0094809c in imcc_run (interp=0x1709de0, sourcefile=0xb571 "/opt/src/perl6/build-20080421/runtime/parrot/library/PGE/Perl6Grammar.pir", argc=3, argv=0xb484) at compilers/imcc/main.c:1069 #27 0x20f8 in main (argc=3, argv=0xb484) at src/main.c:61 (gdb) Crash reporter: Process: parrot [6002] Path:../../parrot Identifier: parrot Version: ??? (???) Code Type: PPC (Native) Parent Process: make [6001] Date/Time: 2008-04-21 21:37:44.790 -0400 OS Version: Mac OS X 10.5.2 (9C31) Report Version: 6 Exception Type: EXC_BAD_ACCES
Notes on removing stack.ops, further steps
Tonight I resolved RT#52838 and RT#52840, eliminating the saveall/restoreall opcodes, the register stack, and fixing up tests and other items to avoid save/restore/etc. opcodes. I've also created a "userstack" branch where I've got the details for removing the rest of stack.ops . I've already implemented and tested it (it's pretty straightforward), but since DEPRECATED.pod says that these opcodes are to be removed "post 0.7.0" it's too early to commit these changes to trunk. One of the interesting features of removing stack.ops is that we no longer need the STACK_ENTRY_INT, STACK_ENTRY_FLOAT, or STACK_ENTRY_STRING types in src/stacks.c, as those were being used only by the save/restore opcodes. Should we see about removing these entry types from the code, or should we leave them there in case we come up with a need for them in the future? More soon, comments welcome. Pm
Re: [perl #53170] Parrot crash during build of r27101 (PPC, OS X 10.5)
On Monday 21 April 2008 20:22:51 Seneca Cunningham wrote: > parrot crashes while generating src/Grammar_gen.pir. The last build > attempted (on a different copy of the source tree) worked and was done > right after the commits to get OpenGL working on OS X happened. This > happens with both "make -j2" and a plain "make". > > ../../parrot -o TGE/Tree.pbc --output-pbc TGE/Tree.pir > ../../parrot -o ../../runtime/parrot/library/TGE.pbc --output-pbc TGE.pir > make -C compilers/nqp > ../../parrot > /opt/src/perl6/build-20080421-b/runtime/parrot/library/PGE/Perl6Grammar.pir > \ > --output=src/Grammar_gen.pir src/Grammar.pg > make[1]: *** [nqp.pbc] Bus error > make: *** [compilers.dummy] Error 2 > herodotus:build-20080421-b seneca$ > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_PROTECTION_FAILURE at address: 0x0019 > 0x0069092c in pobject_lives (interp=0x1709de0, obj=0x11) at > src/gc/dod.c:190 190 if (PObj_is_live_or_free_TESTALL(obj)) > (gdb) bt > #0 0x0069092c in pobject_lives (interp=0x1709de0, obj=0x11) at > src/gc/dod.c:190 #1 0x006e09dc in mark_stack (interp=0x1709de0, > chunk=0x11) at src/stacks.c:66 #2 0x00850340 in Parrot_Continuation_mark > (interp=0x1709de0, > pmc=0x248f3e0) at continuation.pmc:89 chunk should never be 0x11. Does this patch fix things for you? If not, you might set a watchpoint on cc->dynamic_state to see when it gets set to 0x11, as that'll show where we have a pointer go awry. (I fear that it may be one of the PMC_int_val( xxx )++ or -- bits in stack_push or stack_pop.) -- c === src/pmc/continuation.pmc == --- src/pmc/continuation.pmc (revision 27098) +++ src/pmc/continuation.pmc (local) @@ -111,6 +111,10 @@ #endif if (cc->from_ctx) Parrot_free_context(interp, cc->from_ctx, 0); + +if (cc->dynamic_state) +PMC_int_val((PObj *)cc->dynamic_state)--; + mem_sys_free(cc); PMC_struct_val(SELF) = NULL; } @@ -136,6 +140,8 @@ PMC_struct_val(ret) = cc; PMC_pmc_val(ret) = PMC_pmc_val(SELF); +PMC_int_val((PObj *)cc->dynamic_state)++; + return ret; } @@ -174,6 +180,8 @@ cc->dynamic_state = INTERP->dynamic_env; cc->runloop_id= INTERP->current_runloop_id; +PMC_int_val((PObj *)cc->dynamic_state)++; + if (pos && (*pos == PARROT_OP_get_results_pc)) cc->current_results = pos; else
2 questions on S12
Question 1:
What is meant by:
has $attribute # lexical alias for $!attribute.
Here is more concrete example. There is none in S12.
class C {
has $a;
method foo ()
{
my $y = $a; # is the correct?
}
In that scope, is $a really a shortcut for $self!a ?
If so, is that really a good idea?
If not, please clarify.
Question 2:
Here is summary of what is said in S12 concerning these declarators, used
inside a class:
my $.var class attribute, plus generates accessor, not inheritable. (The
variable itself or the accessor is not inheritable?)
my $!var class attribute, no accessor, not inheritable. How is this
different from a normal lexical variable? Role composition can show
differences?
our $.var class attribute, accessor, inheritable.
our $!var class attribute, no accessor, inheritable.
my $var lexically scoped variable
our $attribute class attributes.
What do you mean by "inheritable"? Does the form our $!var make sense or is
that an oxymoron? How is my $var with no metaclass involvement different in
functionality from my $.var ? Likewise for 'our' with and without a twigil. 6
ways to define class attributes -- TIMTOYTDI for sure.
I can take the issue to think through the details and write it up. But, what
central point is it trying to embody? Here is a first cut:
* my and our *always* work in the usual way for the declared symbol. Don't
worry about funny twigil names or the fact that it's inside a class.
* the . twigil makes an accessor in the class itself for that value.
*? so, the ! twigil doesn't seem to accomplish anything in this situation
