Re: Optional binding
On Mon, Mar 07, 2005 at 03:03:08AM +0200, Yuval Kogman wrote:
: On Sun, Mar 06, 2005 at 02:13:09 -0700, Luke Palmer wrote:
: What is output:
:
: sub foo($x, ?$y, [EMAIL PROTECTED]) {
: say x = $x; y = $y; z = @z[];
: }
:
: my @a = (1,2,3);
: foo($x, @a);
:
: And is
:
: $a == foo $x;
:
: The same?
Nope, that's part of why we came up with pipes in the first place,
You example (assuming you meant @a there) is equivalent to
foo($x, undef, @a);
or
foo $x == @a;
or
foo $x, z = [EMAIL PROTECTED]
Larry
Re: Method call parsing
On Sun, Mar 06, 2005 at 03:15:23PM -0700, Luke Palmer wrote:
: But this allows the syntax '$x.foo $y', that is, an argument to a method
: call without parentheses. This isn't a big deal, and could even be
: construed as a feature, if it weren't for:
:
: for %hash.keys { ... }
:
: Which is misparsed.
Which is why recent versions of A12/S12 outlaw arguments to methods
without parens. Method calls cannot be parsed with the same rules as
functions and list operators, unfortunately. The original A12 tried
to make that work, at the expense of arcane lookahead rules, but it
just got too bizarre. Those braces above *have* to know that they're
where an operator is expected. Since we can omit method parens on
argumentless method calls and on method calls that have only adverbs,
requiring parens only on methods with extra arguments is a fair price
to pay for dropping parens off of the conditional expression, I think.
[A reminder that implementation followups can certainly go here, but
philosophical followups should probably be rerouted to p6l. A certain
amount of leakage is necessary, of course, and I don't mind answering
short design clarifications here, as long as they don't clutter the
list with the sorts of idle speculations that are more typical on p6l.]
Larry
Re: array interpolation implemented; a question
On Sun, Mar 06, 2005 at 12:30:43PM -0500, Garrett Rooney wrote: : Autrijus Tang wrote: : On Sat, Mar 05, 2005 at 02:39:06PM -0700, Luke Palmer wrote: : : Garrett Rooney writes: : : Garrett Rooney wrote: : : : Assuming the spec is correct, here's a patch to add some more tests to : t/op/string_interpolation.t. : : Of course, those should have been todo_is tests... Here's the right : patch. : : Thanks, applied. : : : Thanks, implemented as such (r579). : : With that change however, these three lines are now the same: : : my @x = @a; : my @x = @a[]; : my @x[] = @a; : : Is that correct? : : I believe so, since @x[] is an array slice that encludes the entire : contents of the array. Yes, it's taken as a 0-dimensional slice, rather than a 1-dimensional slice with 0 selected elements. Larry
Re: testing non-modules
Yitzchak Scott-Thoennes [EMAIL PROTECTED] writes:
main() unless caller;
I use this (and teach it in my trainings) as an easy way to insert
some basic verification tests in modules. At the end of the module:
unless ( caller ) {
package main;
... insert test code ...
}
-- Johan
Re: Current MSWin32 (WinXP, VC++ 7.1) Test Results
Ron Blaschke [EMAIL PROTECTED] wrote: Here are the current test results on my WinXP, VC++ 7.1 box. [ dynclasses failing ] Ron PS: Should I keep posting them from time to time, or are they of no interest to anyone? Yes please / no. It shows current state and can serve as a reminder to do something against it ;) leo
Tinderbox
It would be very useful if tinderboxen could be revived. Thanks, leo
Re: [RELEASE] Parrot 0.1.2 Phoenix Released!
Alberto Manuel Brandao Simoes [EMAIL PROTECTED] wrote: Ok, this might be useless, but maybe you like to know: All tests successful, 1 test and 64 subtests skipped. Good news and feedback is never useless. Thanks, leo
Re: Current MSWin32 (WinXP, VC++ 7.1) Test Results
Leopold Toetsch wrote: Ron Blaschke [EMAIL PROTECTED] wrote: Here are the current test results on my WinXP, VC++ 7.1 box. [ dynclasses failing ] PS: Should I keep posting them from time to time, or are they of no interest to anyone? Yes please / no. It shows current state and can serve as a reminder to do something against it ;) Will do. BTW, I'm starting to work on the broken dynclasses (missing export symbols), now that release 0.1.2 is out. Ron
Re: CPAN modules coverage (was: Test::Output 0.05)
Selon Michael G Schwern [EMAIL PROTECTED]: On Sun, Mar 06, 2005 at 09:54:44PM +0100, S?bastien Aperghis-Tramoni wrote: Instead of running the code on one server, where it's a problem, why not running on machines where all prereq modules are already installed, i.e. on machines where one *wants* to install the module ? Let's add an option to CPANPLUS so that it run Devel::Cover on any module that it has to install and include the coverage information in the test report. Not a bad idea. Issues I can think of... * Devel::Cover is very slow, I don't know if you'd want it on all the time like test reporting. Right, this is slow, but for someone that want to know if the module is well tested, this information may help to gauge the quality (or the kwalitee) of this module. And for cpansmokers, I'd say speed has no importance. If the speed really is an issue, it can be solved by running the test suite with Devel::Cover in another CPANPLUS process. * As mentioned, Devel::Cover is not perfect and often screws up test results, threading particularly is a problem, so that it will give false negatives. This is a common problem, one example is Test::More. An interesting question would be: from all the CPAN Testers reports, how many perl are built with thread support enabled? I know mine is because it's the default perl included with the Mandrake distribution, but RGS annouced that the next one won't have thread support, because of the troubles it creates. The next interesting question is: how many modules use/need threads? If I believe CPANTS, not much. sqlite SELECT dist.id, dist.dist, dist.author, prereq.requires FROM dist, prereq WHERE prereq.requires like '%hread%' AND prereq.requires not like '%ail%' AND dist.id=prereq.distid; returns 17 results, 16 of which are in the Thread::* namespace (and are released by Elizabeth Mattijsen). The only one left is SNMP::Server. I never dealed with thread problems, but from reading the Perl documentation, I always had the feeling that Perl thread support has never been considered very stable. This is to say: ok, maybe Devel::Cover don't deal very well with threads, but if there's so few modules on the CPAN that use threads, maybe it can be considered as a low priority issue. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
1) objects - (was: Proposed vtable changes WRT method lookup)
Below is mainly a repost of the old proposal.
Two additions:
7) all object opcodes should go through the vtable. From there the
implementation can either call into Parrot's default (src/objects.c) or
do whatever the class system needs.
8) attribute access
We currently have:
8.1) via classoffset and index
The index serves as a cache located in the bytecode. But there is no
means to invalidate that chache, if the class (or one of the base
classes) changed the layout. I don't know if a class can change under
the code, but given that we support highly dynamic languages it's not
unlikely that this can happen.
8.2) by fully qualified classname
The classoffset opcode needs the class name of the object, where the
attribute is located. The named access needs a fully qualified attribute
name with the class name inside.
That's probably ok for Perl6 as attributes are only visible in the class
defining them (IIRC) but it doesn't work for Python. This seems to cause
a problem for HLL interoperbility.
I think, we should do:
- toss the indexed attribute access
- allow unqualified attribute names:
attr = getattribute obj, attr_name
would (in the default implementation) return the first matching
attribute in the objects MRO. A full qualified name
class_name\0attr_name could still be used, if needed.
Performance considerations:
A class system can implement the (new) vtable:
ptrdiff_t get_attribute_offset(...)
which returns the offset of the attribute location relative to the
object. This offset can be cached in the PIC, which gives instant access
to the attribute from the opcode run loop.
Comments?
leo
Proposed vtable changes WRT method lookup
1) rename vtable-data to vtable-class
All current usage of the 'void *data' vtable element is as the object's
class. So it should read PMC *class.
2) add vtable-mro - an array-ish PMC of classes
'PMC *mro' is a list of class PMCs - the method resolution order.
mro[0] := this class
mro[1] := first parent
...
This replaces the current classsearch_array PCD_ALL_PARENT for real
objects. Additionally plain PMCs can place their parent classes here
so that the distinction of PMCs vs objects vanishes, when it comes to
method lookup.
3) add vtable-methods - an hash PMC of method_name = sub_PMC
mappings
Currently the methods of a class are stored inside Parrot globals in a
namespace \x0$class_name. I think the proper place for method
storage should be inside the class itself.
This has some nasty implications though. When reading a packfile with
a Sub PMC inside a namespace this class might not exist yet. So
probably a bare class with just the method hash is pre-created.
4) add vtable-dispatch
This vtable method does the full method lookup and returns the
callable subroutine object, if any. It's basically what the current
VTABLE_find_method is doing.
PMC* dispatch(STRING* meth_name) {}
Find a method for invocant Cself and arguments set according to
pdd03 to handle the given method. Return a Sub PMC or NULL.
The default implementation calls Cfind_method repeatedly for classes
in Cmro until a proper method is found. It's likely that it also has
to look into lexicals for local overrides.
5) change vtable-find_method
It get's one additional argument CINTVAL mmd_nr as described in the
subject MMD and VTABLE_find_method. The difference to that proposal
and to the current implementation is, that Cfind_method just
returns, if *that very* object (probably via its class) can do the
method or not. The search inside parents is handled by
Cvtable-dispatch.
So we'll have:
PMC* find_method(STRING* meth_name, INTVAL mmd_nr) {}
return a Sub PMC or NULL, if the object Cself can handle the given
method, where Cself is the Cmmd_nr-th argument in the call.
6) remove vtable-can
This is redundant, AFAIK. If Cdispatch (or currently Cfind_method)
returns != NULL then Ccan is true else it's false.
Comments welcome,
leo
Re: [RELEASE] Parrot 0.1.2 Phoenix Released!
Hi Richard, [EMAIL PROTECTED] wrote: Leo, you (or someone) might want to: s/Poicephalus/Phoenix/ on parrotcode.org etc. Yep, thanks. It's being worked on. Greetinx to Germany, leo
Proposed steps towards the next release 0.2 and beyond.
Below inline/attached is a proposal for Parrot core changes. I'll post a
more detailed proposal for 1) objects in a minute.
leo
Proposed steps towards the next release 0.2 and beyond.
These are numbered just for reference but are else in no particular
order. A lot can be done in parallel. A lot needs more refinement and
discussion. And *some* should be approved by Dan.
Not all will be finished for 0.2 but I hope a lot.
As this is a pretty long list I'll start distinct threads with more
details and a rationale. Follow up's should go there.
1) objects
1.1) split Cdispatch from Cfind_method
- find_method ... check if the class can do the method
- dispatch... do the full method lookup, possibly MMD
1.2) new Cmro array
- array of classes in canonical method resolution order
2) vtables
2.1) all implemented vtable and MMD slots in one class become
NCI methods.
2.2) the vtable entries get split into roles
struct _vtable {
init, destroy, hash, mark, class,
... // common, main part
Vtbl_scalar*as_scalar; // abs, not, int, num, ...
Vtbl_... *as_native_scalar// get_integer, set_integer_native, ...
Vtbl_array *as_array; // get_pmc_keyed, push, pop, ...
Vtbl_... *as_native_array // get_integer_keyed, ...
Vtbl_hash *as_hash;// exists_keyed, ...
...*as_native_hash; // get_integer_keyed_str, ...
*as_iterator;// get_next, ...
*as_object; // get_attribute, ...
...
};
3) function and method signatures
3.1) *the object is passed to methods as the first argument*
3.2) *change to calling conventions needed*
multi sub foo(int $a, float $b) {...}
multi sub foo(float $a, int $b) {...}
set I5, x
set N5, y
invokecc foo # now what?
3.3) *need per scope register frames* for timely destruction
4) more vtables
4.1) new vtable methods that return a new destination PMC
add dest, l, r# use existing dest PMC
n_add dest, l, r # create new dest PMC
4.1.1) implement a language pragma in assembler, e.g.:
.HL_language Python
4.1.2) create table of canonical types per language mapping
Integer - PyInt - TclInt - Perl6Int - ...
4.2) separate inplace operations from infix operations
dest += r= dest.__i_add(r)
4.3) misc new vtables:
- coerce, hash, get_numeric, ...
- new PMC variants of exisiting vtables
5) fix MMD and vtable operator inheritance
5.1) implement MMD dispatcher
5.2) Parrot infix operator equivalence:
You are in a maze of twisty little passages, all alike.:
add d, l, r
d = add l, r
d = l + r
d = l.__add(r)
d = __add(l, r)
are all the same.
And probably:
.use n_operators
...
d = l + r = d = l.__n_add(r)
5.3) use dynamic dispatch for prefix/postfix too
For PMC operands, these are all the same:
abs d, a
d = abs a
d = a.__abs()
d = __abs(a)
6.) create list of builtins
All function-like PMC-related opcodes become methods in some namespace
6.1) create appropriate namespaces, e.g.
sin x, y= x = Math.__sin(y) # PMC
sin N0, N1 # native float variant remains
getstdin Px = Px = IO.__getstdin()
sweep 1 = GC.__sweep(1)
split a, d, s = a = String.__split(d, s) # if d isa String
= a = d.__split(s) # generally
The translation is done by the assembler according to the list of builtins
so that the current syntax remains valid.
7) *new PMC layout*
7.1) *PMCs become variable sized*
7.2) *the STRING* type becomes an alias for the String PMC*
7.3) *a Buffer becomes kind of a CharArray PMC* - if we still need a Buffer
8) simplify Hash PMC
8.1) get rid of movable Hash buffers
8.2) get rid of indirection through BucketIndex
9) redo iterators
9.1) iterator vtables
- get_iter vtable (is ok)
- iter_next vtable - replaces current next_xx_keyed/shift sequence
9.2) an iterable implements Cget_iter
an interator can Citer_next
9.3) fix slice, range, xrange, ... iterators
10) Last but not least
10.1) continue work on unicode, strings, building installation, GC,
libraries, threads, events, ...
10.2) new things like the Version PMC, async IO, and what not.
Re: [perl #34351] [PATCH] garbage characters in a comment
On Sun, Mar 06, 2005 at 03:18:05PM +0200, Jarkko Hietaniemi wrote: Leopold Toetsch via RT wrote: Jarkko Hietaniemi [EMAIL PROTECTED] wrote: Extra 0xA0 characters (Latin-1 no-break-spaces?) in the comments of a header file. Non-fatal but probably not intended, either. Patch attached. $ file noa0.pat.gz noa0.pat.gz: data Please resend, thanks leo Curious. Reattached. Indeed curious. The first version was the gzip file, but utf8 encoded. Nicholas Clark
Re: Proposed steps towards the next release 0.2 and beyond.
On Mon, 2005-03-07 at 11:01 +0100, Leopold Toetsch wrote: 4.1.1) implement a language pragma in assembler, e.g.: .HL_language Python A pragma like that seems to split high-level languages into two groups: those that are specially known to parrot, and those that are not. I'd like it to be possible for ANY scripting language to be compiled to IMC or PASM, and for that compiled code to be runnable directly (if it uses only built-in PMC classes), or with the addition of dynamically-loaded classes (if the built-in PMC classes are not suitable). 4.1.2) create table of canonical types per language mapping Integer - PyInt - TclInt - Perl6Int - ... Why not use a pragma to list the canonical types, instead of a .HL_language pragma. In the language I'm implementing, there are distinct PMCs for Integer, Character, Boolean, Bits and Enumeration - but I don't want lose interoperability with other languages that use one integer type for all of these. Within my language, each of the above types is implemented with its own PMC, but each of these PMCs uses the same internal layout as .Integer. Therefore, it would be fine for them all to be treated at an integer within inter-language calls. But there needs to be a way for my IMC to tell parrot about this. Here's an example of how it could be done for a language that uses one PMC for all integer-like types: .Language_name ruby # just a String; used for messages etc .Language_mapping Integer - RubyInt .Language_mapping Character - RubyInt .Language_mapping Boolean - RubyInt .Language_mapping Bits- RubyInt .Language_mapping Enumeration - RubyInt .Language_mapping String - RubyString ...etc and here's how it might look for a language that has a greater degree of abstraction: .Language_name Bird .Language_mapping Integer - BirdInteger .Language_mapping Character - BirdCharacter .Language_mapping Boolean - BirdBoolean .Language_mapping Bits- BirdBits .Language_mapping Enumeration - BirdEnum .Language_mapping String - BirdString ...etc This would enable parrot to know that when a BirdBoolean is passed to a ruby method, BirdBoolean has a Boolean interface which ruby can treat as a RubyInt. If the ruby method wants to return a character, perhaps parrot could provide an abstract version of the new opcode, so that ruby can create a new abstract Character. Parrot would then consult the canonical types, and would create a BirdCharacter if the calling language was Bird, but would create a PyInt if the calling language was Python. I hope this makes some sense, and that you can see some merit in it. Proposed steps towards the next release 0.2 and beyond. I'd be very pleased to see working support in 0.2 for setfile/setline/setcolumn so that when my IMC code fails due to (e.g.) a divide by zero error, the parrot runtime can report the source location in my high-level code rather than the source location in my IMC. Regards, Roger -- Roger Browne [EMAIL PROTECTED]
Re: [perl #34356] Module to query parrot-config
I will try it out to see if it works for me. Now I know how to get the data but how can I include this into a Makfile. If this were Perl-code I could use MakeMaker but this way I need to do it somehow different. By the way - in which file did you find this example. Adrian Am Montag, 7. Mrz 2005 01:03 schrieb Will Coleda via RT: Here's the sample from the perldoc: .sub _some # store the config data into $P0 $P0 = _config() # Retrieve and print a key $P1 = $P0[cc] print Your C compiler is print $P1 print \n .end .include library/config.imc Which, when run on my OS X box, gives: oolong:~/research/parrot coke$ ./parrot foo.imc Your C compiler is cc How's that? Adrian Lambeck wrote: This might be it - how do I access the data ? Am Sonntag, 6. Mrz 2005 20:13 schrieb Will Coleda via RT: Whoops, had already cd'd... it's actually in 'runtime/parrot/library/config.imc' Is this what you're looking for? William Coleda wrote: Already exists. perldoc parrot/library/config.imc Regards. Lambeck (via RT) wrote: # New Ticket Created by Lambeck # Please include the string: [perl #34356] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34356 It would be nice to have a module that returns the installed parrot config. Other applications (hopefully a lot) that configure depending on parrot might need this. I mean something like App::Info::HTTPD::Apache (http://search.cpan.org/~dwheeler/App-Info-0.44/). I am not into App::Info so I can not decide what is neccessary to make it return parrot specific values ... Adrian Lambeck -- --- Adrian Lambeck Basics EDV Feldnerstr. 11 21075 Hamburg Germany Tel. 040/788 901 76 E-Mail: [EMAIL PROTECTED]
Comma in (sub) traits?
Hello all,
while writing some experimental code with Pugs, I realised that it is a
bit hard for me to parse the following type of declaration:
sub greeting (Str $person) returns Str is export {
Hello, $person
}
Specifically, the 'is export' trait is too buried. Reformatting it like
this helps:
sub greeting (Str $person)
returns Str is export {
Hello, $person
}
But I really do not like the vertical alignment of the traits and the
body of the sub. So we're back to the first situation. We could also put
the 'returns' on the first line, after the signature (and strictly
speaking it at least can be a part of the signature), and the traits on
successive lines after that, but the alignment problems kicks in again.
There are other ways to format the declaration, like indenting the
traits line:
sub greeting (Str $person) returns Str
is export {
Hello, $person
}
This looks distinctly odd to me, although I think it works better than
the aligned version. Moving the traits line to column 0 is even weirder.
I think it is clear that I do not want to put the { on its own line. :)
The problem can be alleviated a bit by giving each trait a more
separable visual identity:
sub greeting (Str $person) returns Str, is export {
Hello, $person
}
The above works better for me than either of the previous examples. So
my question is: can this be legal Perl 6 code (and will it DWIM)? There
are ways to format this I didn't think of, I'm sure, so I'd like to know
too what the recommended style is. (perl6doc perlstyle...)
This same problem (well, it is a problem to me) applies to other places
where traits are used as well, but I'm specifically asking in the
context of named subroutine declarations, since parsing the comma seems
at least possible there. The visual distinction in a regular 'my'
declaration brought by the comma might also look too much like a list.
(It probably is a list.)
Sorry if this has been discussed before, or even in the design
documents. I'm also sorry if this is too rambling for the list. It's not
that important, just a thought.
Cheers,
wolverian
signature.asc
Description: Digital signature
Re: [RELEASE] Parrot 0.1.2 Phoenix Released!
Leo, you (or someone) might want to: s/Poicephalus/Phoenix/ on parrotcode.org etc. When you get a spare minute ;-) -- Ciao Richard Foley Ciao - shorter than aufwiedersehen http://www.oreilly.com/catalog/perldebugpr/ -Original Message- Date: Sun, 6 Mar 2005 16:57:38 +0100 Subject: [RELEASE] Parrot 0.1.2 Phoenix Released! From: Leopold Toetsch [EMAIL PROTECTED] To: Perl 6 Internals perl6-internals@perl.org On behalf of the Parrot team I'm proud to announce the release of Parrot 0.1.2. What is Parrot? Parrot is a virtual machine aimed at running Perl6 and other dynamic languages. Parrot 0.1.2 contains a lot of new stuff: - New string handling code. Strings now have charset and encoding - Parts of a generational garbage collector - Better Python support, separated into dynclasses - Parrot Grammar Engine - Improved test coverage and documentation - and a lot more After some pause you can grab it from http://www.cpan.org/authors/id/L/LT/LTOETSCH/parrot-0.1.2.tar.gz. As parrot is still in steady development we recommend that you just get the latest and best from CVS by following the directions at http://dev.perl.org/cvs/. Turn your web browser towards http://www.parrotcode.org/ for more information about Parrot, get involved, and: Have fun! leo
[pugs] misleading compiler message
The following program:
-
my @first_set = qw(1 1 1 1 1 1 1 1 1 1 1 1 1 1);
my @new_set = qw(1 2 1 1 1 1 1 1 1);
if (any(@first_set) != any(@new_set)) {
a fluctuation in the readings has been detected . say;
}
Yields this error message:
-
[EMAIL PROTECTED]:~/perl/talks/p6-junctions$ pugs any-any.p6
unexpected {
expecting term postfix, operator, postfix conditional, ternary conditional, ;
or end of input
NonTerm any-any.p6 (line 4, column 39)
Abutting the period to the string yields a running program:
my @first_set = qw(1 1 1 1 1 1 1 1 1 1 1 1 1 1);
my @new_set = qw(1 2 1 1 1 1 1 1 1);
if (any(@first_set) != any(@new_set)) {
a fluctuation in the readings has been detected.say;
}
The error message had me staring at the line above the ... . say
because it said there was a problem with the open bracket.
--
Carter's Compass: I know I'm on the right track when,
by deleting something, I'm adding functionality.
Re: what namespace for (future|new) module ?
Le dimanche 6 mars 2005, à 21 heures 31, Michael G Schwern écrivait : On Sun, Mar 06, 2005 at 10:01:19PM +0100, C?dric Bouvier wrote: I have something almost working right now. I'd like to upload it to CPAN (after I have at least improved the documentation kindly written by Module::Starter, that is) but I'd like your enlightened opinion on what name it should bear. I'm thinking of Test::Distributed::* but I wouldn't want people being fooled into thinking that it is designed to run under Test::Harness, which it isn't at the moment... Right, so I'd keep it out of the Test:: realm and put it into WWW:: instead. Why not WWW::Grinder? Because the module has nothing to do with WWW per se. It is possible to use it to simulate a load on a web server, but you can use it for anything in fact. Maybe this list is not the right place to ask after all. I'll try and come up with a better idea though. Thanks -- C é d r i c B o u v i e r
.HL_language pragma (was: Proposed steps towards the next release 0.2 and beyond.)
Roger Browne [EMAIL PROTECTED] wrote: On Mon, 2005-03-07 at 11:01 +0100, Leopold Toetsch wrote: 4.1.1) implement a language pragma in assembler, e.g.: .HL_language Python A pragma like that seems to split high-level languages into two groups: those that are specially known to parrot, and those that are not. Not really. The rational for the .HL_language is twofold: - all modules and therefore all subroutines in it should have the HLL name attached to it. - the vtable and MMD methods that return new PMCs should return a PMC that is consistent with the types of that language. If no specific type is registered, Parrot's default or standard types like Integer, Float, or String are used. Why not use a pragma to list the canonical types, instead of a .HL_language pragma. This is of course part of the plan :) The .HL_language or .Language_name pragma specifies the mapping to use for the rest of the source file. And the mappings should be dynamically extendable as ... .Language_mapping Integer - RubyInt .. it's shown here, yes. I'd be very pleased to see working support in 0.2 for setfile/setline/setcolumn so that when my IMC code fails due to (e.g.) a divide by zero error, the parrot runtime can report the source location in my high-level code rather than the source location in my IMC. Yep. Good point. It was discussed some time ago and went off into the multi-dimensionality of the code location ;) But yes. Code is ever becoming more complex and debugging is already a pain. The lexer already knows about setfile and setline as well as C-like #line directives. The information is discarded but should go into similar metadata like PIR-line information is already using. Regards, Roger leo
Re: [perl #34356] Module to query parrot-config
Adrian Lambeck [EMAIL PROTECTED] wrote: [ please don't top post ] I will try it out to see if it works for me. Now I know how to get the data but how can I include this into a Makfile. If this were Perl-code I could use MakeMaker but this way I need to do it somehow different. There's a TODO item in the bug tracker, which describes an extension to parrot-config.imc. $ ./parrot parrot-config.imc libs -lnsl -ldl -lm -lposix -lcrypt -lutil -lpthread -lrt -lgmp It should eventually understand shortcuts like --compile or --link or some such. For now you can include something like: foo$(EXE) : foo.c $(PARROT) # or better the lib `$(PARROT) parrot-config.imc link` \ `$(PARROT) parrot-config.imc libs` \ ... in the Makefile. By the way - in which file did you find this example. You are citing it: Am Sonntag, 6. März 2005 20:13 schrieb Will Coleda via RT: it's actually in 'runtime/parrot/library/config.imc' $ perldoc -F runtime/parrot/library/config.imc leo
Re: Tinderbox
On Mon, Mar 07, 2005 at 09:54:36AM +0100, Leopold Toetsch wrote: It would be very useful if tinderboxen could be revived. Thanks, leo Do we need a separate tinderbox, or do you think it might be helpful to integrate parrot somehow into the current perl smoke reporting process? There is already a good infrastucture there to support this kind of testing. Steve Peters [EMAIL PROTECTED]
Re: dynclasses OS X test failures - a Perl task
On Sat, 5 Mar 2005, Leopold Toetsch wrote: Andy Dougherty wrote: make: *** No rule to make target `blib/include/unicode/ucnv.h', needed by `src/string_primitives.o'. Stop. This was fixed by Bernhard yesterday. Thanks. I must have missed his fix by just a few hours. I'll check today that the dynaclasses/py* are working for me. -- Andy Dougherty [EMAIL PROTECTED]
Re: Comma in (sub) traits?
wolverian wrote:
There are other ways to format the declaration, like indenting the
traits line:
Yes, I like:
sub greeting( Str $person )
returns Str
is export
{
Hello, $person
}
With the sub-line as some kind of intro and the block as the terminator.
A longer signature would be aligned after the opening paren---and along
the zone markers.
Regards,
--
TSa (Thomas Sandlaß)
Re: .HL_language pragma (was: Proposed steps towards the next release 0.2 and beyond.)
At 07:50 AM 3/7/2005, Leopold Toetsch wrote: Roger Browne [EMAIL PROTECTED] wrote: On Mon, 2005-03-07 at 11:01 +0100, Leopold Toetsch wrote: 4.1.1) implement a language pragma in assembler, e.g.: .HL_language Python Sounds good to me except that I would prefer you remove the HL_ and just call it .language to be consistent with other directives. Incidentally this is what .NET uses as well except its implementation uses GUID instead of a string, and it also allows the compiler vendor and source document type to be included in the directive. Dan and I talked about this a couple of years ago on IRC. Originally I wanted to stay away from GUIDs as I think they are overkill, and had considered allowing ASCII: .language Perl6 .language Perl6:ThePerlFoundation But..., this requires this section in the bytecode to be variable sized, so there might be some merit to using GUIDs, especially for vendors. I think to keep PIR convenient for hackers I want to accept both strings and 32 bit integers for each. If a string, it must be already registered in IMCC and we can probably reserve the first 1024 for pre-registering but IMCC still would be able to accept integers. In any case, it needs to be fixed width in the bytecode header. We need to revisit the bytecode format. Last time through, I put an Opcode type at some offset, per Dan's request. We store a magic number for that. I'm pretty sure we can use this field to identify the language using whatever is provided in the .language pragma, but I can't speak for Dan. I think he might have had different plans for opcode type. -Melvin
Re: Devel::Cover-age of qx() jobs
On Sun, Mar 06, 2005 at 06:40:20PM -0700, Jim Cromie wrote: Ive written some tests that verify writing to STDOUT, etc, which were easy to do as `$X ... ` jobs. but these dont get covered by default, so my coverage results are not what they should be. snip Is there an easy way to do what Im trying ? Use do() as discussed here: http://www.nntp.perl.org/group/perl.qa/3724 Though I'm not sure why adding -MDevel::Cover didn't work.
Re: Test::More - question about eq_* functions
On Sun, Mar 06, 2005 at 09:19:05PM -0800, Ofer Nave wrote: Doesn't is_deeply do everything eq_array and eq_hash does and more? It looks like is_deeply has the same exact interface and purpose, except that it accepts both arrayrefs and hashrefs. So why would you need eq_array and eq_hash? I know I'm missing something here. Maybe I should take a break. Here's a clue: they were written first. is_deeply() does do everything they do. They're all but deprecated, I just have to remember to deemphesize them in the docs. Additionally, they're not testing functions and have no diagnostics. They just return true or false.
Re: Optional binding
On Sun, Mar 06, 2005 at 11:58:43PM -0800, Larry Wall wrote:
On Sun, Mar 06, 2005 at 02:13:09AM -0700, Luke Palmer wrote:
: What is output:
:
: sub foo($x, ?$y, [EMAIL PROTECTED]) {
: say x = $x; y = $y; z = @z[];
: }
:
: my @a = (1,2,3);
: foo($x, @a);
I think it should say something like:
Use of undefined value at foo line 2
x = ; y = 1 2 3; z =
Optional parameters are greedy, and @a means [EMAIL PROTECTED] in a scalar
context.
Larry
Urk. I, for one, will definitely find this surprising. I would have
expected:
x = whatever; $y = 1; z = 2 3
But I suppose it's all a question of learning to love the Brave New
World in which arrays are actually objects (sort of).
--Dks
--
[EMAIL PROTECTED]
Re: testing non-modules
On Sun, Mar 06, 2005 at 10:42:53PM -0800, Ofer Nave wrote: t/Parallel-SimpleUndefined subroutine main::prun called at snip Lastly, how come use_ok( 'Parallel::Simple' ) didn't bitch at me? Because you already have an older version installed which does not have a function called prun()? Should that be prune()?
Re: Return a varying number of values in IMCC?
Bob Rogers [EMAIL PROTECTED] wrote: I don't see a way to do this at present. What I would like is an equivalent to .flatten_arg for a PCC return, e.g.: .pcc_begin_return .flatten_arg array_of_results .pcc_end_return Of course, .flatten_arg sounds a bit odd in this context, so calling it just .flatten might be better. (In which case it might be good to support .flatten as a synonym for .flatten_arg in a PCC call.) Is this on the right track? Makes sense, yes. How many return values or arguments are flattened usually? leo
Re: .HL_language pragma
MrJoltCola [EMAIL PROTECTED] wrote: At 07:50 AM 3/7/2005, Leopold Toetsch wrote: .HL_language Python Sounds good to me except that I would prefer you remove the HL_ and just call it .language to be consistent with other directives. I don't care much about the actual keyword - as long as we find a reasonable compromise ;) Anyway, the HL_ prefix should make sure that it's not mixed up with any kind of string's language declaration. But as strings don't have a language setting anymore .language would be fine too. Incidentally this is what .NET uses as well except its implementation uses GUID instead of a string, and it also allows the compiler vendor and source document type to be included in the directive. I don't like GUIDs. I prefer text. Dan and I talked about this a couple of years ago on IRC. Originally I wanted to stay away from GUIDs as I think they are overkill, and had considered allowing ASCII: Yep. .language Perl6 .language Perl6:ThePerlFoundation But..., this requires this section in the bytecode to be variable sized, No. All that kind of information should either go into PBCs metadata or stored as PMC constants: .const .Version $P0 = vendor=tpf,author=mel,version=0.815 or whatever. It's up to the Version PMC to parse the passed in string and freeze it appropriately. The constant PMC syntax is used already for subroutines. We'd need just to switch to freeze/thaw for PMC constants. WRT .language: that should be just a plain string. In any case, it needs to be fixed width in the bytecode header. Not really. Metadata are in separate sections or .language becomes a string constant. We need to revisit the bytecode format. Last time through, I put an Opcode type at some offset, per Dan's request. You mean Copcodetype in the PBC header? That's still unused. But there is: #define OPCODE_TYPE_PERL 0x5045524c #define OPCODE_TYPE_PYTHON 0x5045524b #define OPCODE_TYPE_JAVA 4871757 #define OPCODE_TYPE_MSNET 2e4e4554 which defines 4-byte char constants denoting the language, somehow. We store a magic number for that. I'm pretty sure we can use this field to identify the language using whatever is provided in the .language pragma, but I can't speak for Dan. I think he might have had different plans for opcode type. Well, it seems to be that. But we want and additional type mapping for Parrot standard types. So that doesn't fit there anyway. -Melvin leo
Re: [RELEASE] Parrot 0.1.2 Phoenix Released!
On Sun, Mar 06, 2005 at 04:57:38PM +0100, Leopold Toetsch wrote: On behalf of the Parrot team I'm proud to announce the release of Parrot 0.1.2. First: Congratulations to everyone for this release! Second: What will it take before Parrot moves to a 0.2 (0.3, 0.4...) release? --Dks
Re: Comma in (sub) traits?
On Mon, Mar 07, 2005 at 03:43:19PM +0100, Aldo Calpini wrote:
don't know if it helps, but I guess that you can also write it like
this, if you prefer:
sub greeting(Str $person) {
returns Str;
is export;
Hello, $person;
}
(this guess is based on something I recall having read in A12 about
classes; if my guess is wrong, I'll be happy to stand corrected :-).
On reflection, I see why that probably works. I also pray that I
never have to maintain code that uses it, because it seems very
misleading. .
--Dks
--
[EMAIL PROTECTED]
Re: Optional binding
David Storrs wrote:
Urk. I, for one, will definitely find this surprising. I would have
expected:
x = whatever; $y = 1; z = 2 3
to obtain what you have expected, you need to explicitly treat the array
as a list of values with the unary splat:
foo($x, [EMAIL PROTECTED]);
But I suppose it's all a question of learning to love the Brave New
World in which arrays are actually objects (sort of).
more to the point, arrays are automagically referenced in scalar context:
@a = @b; # same as perl5
$a = @b; # means $a = [EMAIL PROTECTED] in perl5
$a = [EMAIL PROTECTED]; # means $a = @b in perl5 (more or less)
another thing that may surprise you (it still surprises me, somehow):
sub bar($x, $y, $z) { ... }
# ^ note x is scalar here!
my @coords = (1.0, 3.0, 5.0);
bar(@coords); # wrong
# x = [EMAIL PROTECTED], y = undef, z = undef
bar([EMAIL PROTECTED]); # ok
but then, you could define:
multi sub bar($x, $y, $z) { ... }
multi sub bar(@coords is shape(3)) {
my($x, $y, $z) = @coords;
return bar($x, $y, $z);
}
bar(@coords); # ok now
cheers,
Aldo
Re: Comma in (sub) traits?
On Mon, Mar 07, 2005 at 12:55:49PM +0200, wolverian wrote:
: Hello all,
:
: while writing some experimental code with Pugs, I realised that it is a
: bit hard for me to parse the following type of declaration:
:
: sub greeting (Str $person) returns Str is export {
: Hello, $person
: }
:
: Specifically, the 'is export' trait is too buried.
Here are some alternatives you don't seem to have considered:
sub greeting (Str $person) is export returns Str {
Hello, $person;
}
sub greeting (Str $person) is export
returns Str {
Hello, $person;
}
sub greeting (Str $person)
is export
returns Str {
Hello, $person;
}
sub greeting (Str $person)
returns Str
is export {
Hello, $person;
}
my Str sub greeting (Str $person) is export {
Hello, $person;
}
my Str
sub greeting (Str $person) is export {
Hello, $person;
}
: Reformatting it like this helps:
:
: sub greeting (Str $person)
: returns Str is export {
: Hello, $person
: }
:
: But I really do not like the vertical alignment of the traits and the
: body of the sub. So we're back to the first situation. We could also put
: the 'returns' on the first line, after the signature (and strictly
: speaking it at least can be a part of the signature), and the traits on
: successive lines after that, but the alignment problems kicks in again.
:
: There are other ways to format the declaration, like indenting the
: traits line:
:
: sub greeting (Str $person) returns Str
: is export {
: Hello, $person
: }
:
: This looks distinctly odd to me, although I think it works better than
: the aligned version. Moving the traits line to column 0 is even weirder.
:
: I think it is clear that I do not want to put the { on its own line. :)
That's how I started out in C, and then eventually mutated to a form
in which I put the { on its own line only if I had multiple lines in
the signature. In that case I decided the consistency was overrated.
I basically do the same with any bracketing construct now--if the front
stuff rates more than one line, then I pull the brack out front on its
own line, and not otherwise. It seems the least insane approach to me,
but I realize the inconsistency will bug some people more than others.
Anyway, this policy works for me, and for more than just sigs--it makes
it possible to split up the parameters when they are long and
complex, so I can happily write anything from
sub Foo foo (Bar $bar) is export {
...
}
to
method foo ( $self:
$odd returns Int where { $_ % 1 },
$even return Int where { not $_ % 1 },
Block ?permutator,
[EMAIL PROTECTED]
)
returns Footype
is good
is bad
is ugly
{
...
}
or maybe
method foo ( $self:
$odd returns Int where { $_ % 1 },
$even return Int where { not $_ % 1 },
Block ?permutator,
[EMAIL PROTECTED] )
returns Footype
is good
is bad
is ugly
{
...
}
Well, that's not exactly pretty, but I figure that if you've blown
that many lines on the signature, another line for the opening curly
isn't that much, and makes it visually easy to find where the code
actually starts. Anyway, I think it's more important to have a style
that can mutute from horizontal to vertical form than it is to have
a consistent style.
: The problem can be alleviated a bit by giving each trait a more
: separable visual identity:
:
: sub greeting (Str $person) returns Str, is export {
: Hello, $person
: }
:
: The above works better for me than either of the previous examples. So
: my question is: can this be legal Perl 6 code (and will it DWIM)? There
: are ways to format this I didn't think of, I'm sure, so I'd like to know
: too what the recommended style is. (perl6doc perlstyle...)
:
: This same problem (well, it is a problem to me) applies to other places
: where traits are used as well, but I'm specifically asking in the
: context of named subroutine declarations, since parsing the comma seems
: at least possible there. The visual distinction in a regular 'my'
: declaration brought by the comma might also look too much like a list.
: (It probably is a list.)
Yes, that's the basic problem with comma, and the declaration of traits
on my and sub is one thing I *would* like to keep consistent. I'm
not consistent about consistency, you see, except when I am...
And I try to believe six foolish consistencies before breakfast each day. :-)
Larry
Re: Comma in (sub) traits?
On Mon, Mar 07, 2005 at 08:27:10AM -0800, David Storrs wrote:
: On Mon, Mar 07, 2005 at 03:43:19PM +0100, Aldo Calpini wrote:
:
: don't know if it helps, but I guess that you can also write it like
: this, if you prefer:
:
: sub greeting(Str $person) {
: returns Str;
: is export;
: Hello, $person;
: }
:
: (this guess is based on something I recall having read in A12 about
: classes; if my guess is wrong, I'll be happy to stand corrected :-).
:
: On reflection, I see why that probably works. I also pray that I
: never have to maintain code that uses it, because it seems very
: misleading. .
Yes, and it wouldn't work at all if you ever wanted to autoload anything.
If we ever get to where we're autoloading class bodies, they'd have the
same problem with embedded declarations. The compiler can't work with
information that isn't there.
Larry
Re: what namespace for (future|new) module ?
I think I will call it Run::Distributed after all. -- C d r i c B o u v i e r Le dimanche 6 mars 2005, 22 heures 01, Cdric Bouvier crivait : Hello there. I once had to organize the stress testing of a web based application. The client wanted to know whether the server would handle a given number of concurrent sessions and how long would the users have to wait in front of their stalled browser if such a situation ever happened. The app was hosted on a big server, and I only had an aging laptop to bombard it with requests. My machine would have been lying panting on the floor before the server even noticed something was happening. So I figured I would run the tests concurrently from several aging laptops at once, but I didn't want to run between each test machines to try and hit 'return' on all of them within an acceptable timeframe. So I tried to find some software that would help me manage these test scripts running on different machines. I could only find The Grinder in the free software realm, but that means Java, and scripting the tests in Python. I could not find anything in Perl. And I find The Grinder not flexible enough to my taste. I started off writing a Perl Module to achieve this. It runs a server on one machine, and a number of clients on several other machines. The server beats the rythm, telling the client when to start their tests, or when to wait for the other test machines to complete theirs. The server gathers the results at the end of the test session for later reporting. I have something almost working right now. I'd like to upload it to CPAN (after I have at least improved the documentation kindly written by Module::Starter, that is) but I'd like your enlightened opinion on what name it should bear. I'm thinking of Test::Distributed::* but I wouldn't want people being fooled into thinking that it is designed to run under Test::Harness, which it isn't at the moment... Any comments, suggestions, or questions ?
Re: what namespace for (future|new) module ?
Cdric Bouvier wrote: I think I will call it Run::Distributed after all. theres also module-authors@perl.org that discusses name-space choices regularly.
Re: Comma in (sub) traits?
Larry Wall wrote:
Yes, and it wouldn't work at all if you ever wanted to autoload anything.
If we ever get to where we're autoloading class bodies, they'd have the
same problem with embedded declarations. The compiler can't work with
information that isn't there.
This is something that is blurry to me: how does one separate declaration
and implementation. It is clear that a declaration has got a {...} block
and an implementation doesn't. But does that mean that there are package
files that function like header files in C++ or like interface files in
Ada and Modula?
Or does that work more like Cecil signature declarations which can be
spread out as needed and actually express a callers expectations which
can be matched with the implementation side?
MfG
--
TSa (Thomas Sandlaß)
Re: Optional binding
On Mon, Mar 07, 2005 at 05:36:08PM +0100, Aldo Calpini wrote:
: but then, you could define:
:
: multi sub bar($x, $y, $z) { ... }
: multi sub bar(@coords is shape(3)) {
: my($x, $y, $z) = @coords;
: return bar($x, $y, $z);
: }
:
: bar(@coords); # ok now
Or, assuming you might want to generalize to N dimensions someday, just
sub bar ([EMAIL PROTECTED]) {...}
and deal with it as in Perl 5 as a variadic list. I suppose one could say
sub bar ([EMAIL PROTECTED] is shape(3)) {...}
and get checking on the argument count.
Larry
Re: CPAN modules coverage (was: Test::Output 0.05)
On Mon, Mar 07, 2005 at 11:45:52AM +0100, S?bastien Aperghis-Tramoni wrote: * As mentioned, Devel::Cover is not perfect and often screws up test results, threading particularly is a problem, so that it will give false negatives. This is a common problem, one example is Test::More. An interesting question would be: from all the CPAN Testers reports, how many perl are built with thread support enabled? Well, for one, anyone using OS X or ActiveState. Those are the ones I know for sure. Probably Fedora. I'd hazard to guess that many pre-built Perls these days have ithreads enabled. The next interesting question is: how many modules use/need threads? If I believe CPANTS, not much. sqlite SELECT dist.id, dist.dist, dist.author, prereq.requires FROM dist, prereq WHERE prereq.requires like '%hread%' AND prereq.requires not like '%ail%' AND dist.id=prereq.distid; returns 17 results, 16 of which are in the Thread::* namespace (and are released by Elizabeth Mattijsen). The only one left is SNMP::Server. Test::More does not declare its optional dependency on threads. It will simply use them if available. I can't speak for anyone else but I wouldn't be surprised if other modules did what Test::More does: not use threads itself but test to make sure it works with threads on. I never dealed with thread problems, but from reading the Perl documentation, I always had the feeling that Perl thread support has never been considered very stable. Yes, but its at least usable now. This is to say: ok, maybe Devel::Cover don't deal very well with threads, but if there's so few modules on the CPAN that use threads, maybe it can be considered as a low priority issue. Devel::Cover still has problems with other constructs, though its gotten better as of late. Perhaps a compromise is for the coverage runs to only be reported back as coverage and not test results?
Re: CPAN modules coverage
On Mon, Mar 07, 2005 at 07:45:39AM -0700, Jim Cromie wrote: Theres another issue: coverage can depend upon presense of other modules, ex Test::Warnings, being installed on testers boxes, those tests would be skipped otherwise, and perceived coverage would suffer. That's ok. The overall coverage report can show the union of all reports for that version of the module. This will produce more accurate coverage reports since it will allow the results from multiple platforms to be combined. For example, if you do a coverage analysis of MakeMaker or Module::Build on Unix all the non-Unix code will appear to be uncovered. But if you combine the results from several different machines you'll get all the code.
Re: [RELEASE] Parrot 0.1.2 Phoenix Released!
David Storrs [EMAIL PROTECTED] wrote: First: Congratulations to everyone for this release! Thank you. Second: What will it take before Parrot moves to a 0.2 (0.3, 0.4...) release? See subject: Proposed steps towards the next release 0.2 and beyond. It also depends on the progress we make. I want to have 3 - 4 releases per year. --Dks leo
Re: How are types related to classes and roles?
HaloO,
another self-reply :)
I've added a little hack that classifies strings
into these areas 0 to 3 to illustrate my idea of
a type lattice on which composes the background
of the Perl 6 Type System. Pattern matching and
type systems are related but the question for
Perl 6 is: how exactly?
The topmost type Any has a very nice mnemonic: it's
the any-junction of all types that have no direct
supertype---their lub. Likewise there could be a None
that is the none-junction of all types that have no
subtype---their glb.
This means the Any actually depends on the loaded
program. If it only uses e.g. the unrelated types
A, B and C then Any is A|B|C. Likewise for programs
that implicitly handle strings and do numerics one
gets Any = Str|Num.
BTW, are Num and Int distinct or is there a
relation: Int is/does Num?
Regards,
--
TSa (Thomas Sandlaß)
#! /usr/bin/perl
$s = @ARGV[0];
if ($s =~ /(^aa.*$)|(^.*bb$)/) # perl6: $s ~~ m:overlap/(^aa.*$)|(^.*bb$)/
{
print success: $1 $2\n;
}
else
{
print match: $1 $2\n;
}
if ($s =~ /^aa.*$/ || $s =~ /^.*bb$/ || $s =~ /^.*aa.*bb.*$/) { print : A|B\n; }
if ($s !~ /^aa.*$/ $s !~ /^.*bb$/ $s !~ /^.*aa.*bb.*$/) { print : none(A,B)\n; }
if (($s =~ /^aa.*$/ $s !~ /^.*bb$/) ||
($s !~ /^aa.*$/ $s =~ /^.*bb$/) ) { print : A^B\n; }
if ($s =~ /^aa.*$/){ print : A\n;}
if ( $s =~ /^.*bb$/) { print :B\n; }
if ($s =~ /^aa.*$/ $s =~ /^.*bb$/) { print : AB\n; }
print ===\n;
if ($s =~ /(aa.*)/) { print aa = $1\n; }
if ($s =~ /(.*bb)/) { print bb = $1\n; }
if ($s =~ /aa.*/ || $s =~ /.*bb/) { print : A|B\n; }
if ($s !~ /aa.*/ $s !~ /.*bb/) { print : none(A,B)\n; }
if (($s =~ /aa.*/ $s !~ /.*bb/) ||
($s !~ /aa.*/ $s =~ /.*bb/) ) { print : A^B\n; }
if ($s =~ /aa.*/) { print : A\n;}
if ( $s =~ /.*bb/) { print :B\n; }
if ($s =~ /aa.*/ $s =~ /.*bb/) { print : AB\n; }
Re: Comma in (sub) traits?
Larry Wall skribis 2005-03-07 8:40 (-0800):
method foo ($self: $odd returns Int where { $_ % 1 }, $even
return Int where { not $_ % 1 }, Block ?permutator, [EMAIL PROTECTED])
returns Footype is good is bad is ugly { ... }
That someone took the time to bring this up pleases me. I'm very strict
when it comes to indenting and what I find most readable and thus
prefer. Of course, everyone should have their own style and there's no
shame in having something that some consider ugly. Still, for my own
code, I wish to keep things the way they are.
I indent in two situations. The first is continuation of a statement,
when things don't fit in 80 characters. I try to do this after an infix
operator, or before it if the infix operator is or/and/xor/||/$$/-. The
only thing changing there is the addition of ^^, // and err. And of
course that - is now spelled ..
The second place where I allow myself to indent is within nested
brackets, or sometimes some other circumfix delimiter. If an { belongs
to a certain control statement, it should not have its own line. If any
newline is in the delimiters, even the first and last elements in them
should be on their own lines.
Indentation is always 4 columns. Never 8, never 2. The only exception is
vertical alignment. Outdents exist only to naturally end indentation.
Subs are a problem in Perl 6, because their declaration can be very long
and easily span multiple lines.
With my current rules, I'd end up with
method foo (
$self:
$odd returns Int where ...,
$even returns Int where ...,
Block ?permutator,
[EMAIL PROTECTED]
) returns Footype is good is bad is ugly {
...
}
The { is not really on the same line as method, but at least it's not
on its own.
But it is indeed hard to parse a list of things that have no well
visible separator. I could break my one-space-max rule:
method foo (
$self:
$odd returns Int where ...,
$even returns Int where ...,
Block ?permutator,
[EMAIL PROTECTED]
) returns Footype is good is bad is ugly {
...
}
But that feels like there really are commas, but they were made
invisible. I could also break my continued-lines-are-indented rule:
method foo (
$self:
$odd returns Int where ...,
$even returns Int where ...,
Block ?permutator,
[EMAIL PROTECTED]
)
returns Footype
is good
is bad
is ugly {
...
}
But then, the other way around is prettier:
method foo
returns Footype
is good
is bad
is ugly (
$self:
$odd returns Int where ...,
$even returns Int where ...,
Block ?permutator,
[EMAIL PROTECTED]
) {
...
}
Not that I like ) {, but I'm used to seeing it from Perl 5's if. This
makes method foo look much less important than it is. But with
indentation, the block is no longer clearly visible:
method foo
returns Footype
is good
is bad
is ugly (
$self:
$odd returns Int where ...,
$even returns Int where ...,
Block ?permutator,
[EMAIL PROTECTED]
) {
...
}
Or { needs to go on its own line, which really disturbs me if the { is
not the beginning of a term. And this style is wrong because either ()
or {} need to not line up.
The thing missing is indeed the comma. Looking for other places where
comma is missing, I thought of qw, or its new variant. Isn't the
following a neat solution for the problem we're faced with?
method foo (
$self:
$odd returns Int where ...,
$even returns Int where ...,
Block ?permutator,
[EMAIL PROTECTED]
) returns Footype, is good bad ugly {
...
}
Okay, I cheated by still adding a comma. How about allowing this then:
method foo (
$self:
$odd returns Int where ...,
$even returns Int where ...,
Block ?permutator,
[EMAIL PROTECTED]
) :returnsFootype :isgood bad ugly {
...
}
I'm not sure what to think of my own suggestion. I find this neat and
ugly at the same time. Ugly, because now something that used to be
barewordish/keywordish now feels like strings, beatiful because it solves
a problem, neat because it's syntax that exists elsewhere too.
I think allowing comma or finding another character that can replace it
is the best option, but I think we're low on ASCII characters. Backticks
can be beatiful, but not for this :)
Hm, infix +? If I understand things correctly, it's invalid in the
current design anyway. It communicates that things all belong together,
but it looks really weird:
method foo + returns Footype + is good + is bad + is ugly
And it really screams for allowing different order:
is good + returns Footype + method foo + is bad + is ugly
So that is probably not a good idea. Infix has
Re: Comma in (sub) traits?
On Mon, Mar 07, 2005 at 05:53:23PM +0100, Thomas Sandlaß wrote:
: Larry Wall wrote:
: Yes, and it wouldn't work at all if you ever wanted to autoload anything.
: If we ever get to where we're autoloading class bodies, they'd have the
: same problem with embedded declarations. The compiler can't work with
: information that isn't there.
:
: This is something that is blurry to me: how does one separate declaration
: and implementation. It is clear that a declaration has got a {...} block
: and an implementation doesn't. But does that mean that there are package
: files that function like header files in C++ or like interface files in
: Ada and Modula?
In theory, yes, though I would hope more like Ada than C++. #include
is a rotten way to do business. The idea of Perl's use is that you're
essentially calling a subroutine in the package that gives you as much
of the definition as you need. The fact that it might define a whole bunch
of other stuff at the same time is immaterial to you. As in happens,
it might have already been declared by a previous use, as well as later
in a lazy fashion. It's really the import function that is managing the
interface though. The import mechanism might be different in Perl 6, but
the underlying idea that you execute real Perl code to define things
is certainly going to carry over from Perl 5.
: Or does that work more like Cecil signature declarations which can be
: spread out as needed and actually express a callers expectations which
: can be matched with the implementation side?
I am not familiar with Cecil, but in Perl 6 caller expectations
are primarily expressed through the actual types you feed to MMD.
If the compiler can figure out more based on your own declarations,
that's fine, but the bias is definitely toward late binding.
I suppose if a user defines an normal inner sub that redispatches to
an outer set of multi subs, it functions a bit like a user-defined
expectation. We don't currently have a way of directly mapping a set
of inner multis to a set of outer multies without going through an
interposed non-multi.
We also give a bit of user-defined interface control in letting the user
tell the module which version it wants to act like. In the degenerate
case, that means it just picks the right file, but we should recognize
that the version we specify in a use is maybe an interface version, and
multiple interfaces could be served up by a single back-end implementation.
That approach might help with resource collisions between different versions
of the same module.
Beyond that, we provide the user with aliasing and delegation and
wrappers, at least on a sub/method level. But given that all code
that executes is a sub on some level, there can probably hooks to
wrap classes and modules too, if ordinary inheritance, composition,
and delegation aren't up to the task. But at some point you just
give up and call it cheating, er, I mean, AOP. :-)
Basically, once you realize the compiler is not longer doing the
compilation, but just helping the program compile itself by running
odd bits of code here and there, the door is open to turn Perl into
any other language you like. The only question is what discipline
the culture will enforce around the complete mayhem that is possible.
It is at this point that I am placing my trust in the Perl community.
(But then, my definition of community is somewhat Darwinian...)
Larry
Re: what namespace for (future|new) module ?
Cdric Bouvier wrote: I think I will call it Run::Distributed after all. http://search.cpan.org/search?query=%5Erun%3A%3Amode=module Looks like there's no Run::* namespace yet, and you usually need a pretty good justification to start a new namespace. If your module is just a generic way to run code or commands on remote hosts, than may I suggest the Parallel::* namespace? It already has Parallel::ForkControl, Parallel::ForkManager, and Parallel::Jobs, and I'm days away from my publishing my new module, Parallel::Simple (http://ofernave.com/pm/). None of these handle remote execution, but I was planning on tackling that issue with my next module anyway, and I was going to call it Parallel::something-or-other, toio. -ofer
Re: CPAN modules coverage
Michael G Schwern wrote:
On Mon, Mar 07, 2005 at 07:45:39AM -0700, Jim Cromie wrote:
Theres another issue: coverage can depend upon presense of other modules,
ex Test::Warnings, being installed on testers boxes, those tests would
be skipped otherwise,
and perceived coverage would suffer.
That's ok. The overall coverage report can show the union of all reports
for
that version of the module. This will produce more accurate coverage reports
since it will allow the results from multiple platforms to be combined.
For example, if you do a coverage analysis of MakeMaker or Module::Build
on Unix all the non-Unix code will appear to be uncovered. But if you
combine the results from several different machines you'll get all the
code.
are MM or MB analyses posted anywhere for general perusal ?
That'd be cool, but how does this merge/combining magically happen ?
More specifically, Ive found it to *not* be happening when I spawn off
an `$^X -MDevel::Cover -e $testcode` job, as you've noted in another thread.
OTOH, it does seem to merge repeated runs of 'make testcover', as I see the
ran-this-line counts in the coverage report go up after each run.
so, wrt merging coverage results, I looked inside cover_db/cover.12,
a storable file w multiple runs, one for each t/*.t file, each with a
unique key:
$ mst -d cover_db/cover.12 |egrep -e 'run|111'
'runs' = {
'1110216257.25137.60188' = {
'run' = 't/pp-dump.t',
'1110216248.25129.46205' = {
'run' = 't/labels.t',
'1110216234.25117.50538' = {
'run' = 't/basic.t',
'1110216267.25145.50509' = {
'run' = 't/warns.t',
'1110216241.25123.18273' = {
'run' = 't/honorLocals.t',
'1110216253.25133.53184' = {
'run' = 't/new.t',
'1110216255.25135.61883' = {
'run' = 't/pod.t',
'1110216260.25139.29174' = {
'run' = 't/speed.t',
'1110216229.25107.07159' = {
'run' = 't/alias.t',
'1110216250.25131.38534' = {
'run' = 't/multiarg.t',
'1110216243.25125.33249' = {
'run' = 't/indent-terse.t',
'1110216239.25121.64393' = {
'run' = 't/emulate.t',
'1110216226.25105.54436' = {
'run' = 't/01_use.t',
'1110216262.25141.01103' = {
'run' = 't/twoObjects.t',
'1110216265.25143.07361' = {
'run' = 't/useoptions.t',
'1110216231.25109.28610' = {
'run' = 't/autoprint.t',
'1110216246.25127.34447' = {
'run' = 't/initobj.t',
'1110216236.25119.49831' = {
4111,
'run' = 't/chains.t',
the file doubles in size when I rerun `make testcover`.
It would be easy enough to lump them together,
though by itself, this wouldnt help identify platforms
where a module is undertested.
anyway, we need site-space and cpu-time somewhere to merge
the data.
Re: CPAN modules coverage
On Mon, Mar 07, 2005 at 11:24:42AM -0700, Jim Cromie wrote:
Michael G Schwern wrote:
That's ok. The overall coverage report can show the union of all
reports for that version of the module.
That'd be cool, but how does this merge/combining magically happen ?
To do it properly it would need to be on a machine somewhere which would
accept uploaded coverage databases from anyone who wanted to submit one.
I discussed cover.perl.org or something with Andy and Robrt on irc a
while back, but I've not made progress on the sw side.
More specifically, Ive found it to *not* be happening when I spawn off
an `$^X -MDevel::Cover -e $testcode` job, as you've noted in another thread.
OTOH, it does seem to merge repeated runs of 'make testcover', as I see the
ran-this-line counts in the coverage report go up after each run.
Provided you can get each run using the same database things should
just work. If your pwd moves around you might need to specify a full
path to the db.
export PERL5OPT=-MDevel::Cover=-db,/path/to/cover_db
or something similar might help.
so, wrt merging coverage results, I looked inside cover_db/cover.12,
a storable file w multiple runs, one for each t/*.t file, each with a
unique key:
$ mst -d cover_db/cover.12 |egrep -e 'run|111'
'runs' = {
'1110216257.25137.60188' = {
'run' = 't/pp-dump.t',
'1110216248.25129.46205' = {
'run' = 't/labels.t',
'1110216234.25117.50538' = {
'run' = 't/basic.t',
'1110216267.25145.50509' = {
'run' = 't/warns.t',
'1110216241.25123.18273' = {
'run' = 't/honorLocals.t',
'1110216253.25133.53184' = {
'run' = 't/new.t',
'1110216255.25135.61883' = {
'run' = 't/pod.t',
'1110216260.25139.29174' = {
'run' = 't/speed.t',
'1110216229.25107.07159' = {
'run' = 't/alias.t',
'1110216250.25131.38534' = {
'run' = 't/multiarg.t',
'1110216243.25125.33249' = {
'run' = 't/indent-terse.t',
'1110216239.25121.64393' = {
'run' = 't/emulate.t',
'1110216226.25105.54436' = {
'run' = 't/01_use.t',
'1110216262.25141.01103' = {
'run' = 't/twoObjects.t',
'1110216265.25143.07361' = {
'run' = 't/useoptions.t',
'1110216231.25109.28610' = {
'run' = 't/autoprint.t',
'1110216246.25127.34447' = {
'run' = 't/initobj.t',
'1110216236.25119.49831' = {
4111,
'run' = 't/chains.t',
the file doubles in size when I rerun `make testcover`.
It would be easy enough to lump them together,
though by itself, this wouldnt help identify platforms
where a module is undertested.
The runs should be lumped together automatically when you run cover.
There are also options to cover to merge separate coverage databases.
anyway, we need site-space and cpu-time somewhere to merge
the data.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: CPAN modules coverage
On Mon, Mar 07, 2005 at 11:24:42AM -0700, Jim Cromie wrote: are MM or MB analyses posted anywhere for general perusal ? Nope. You're free to run it yourself though. :) Its likely to be pretty appauling because of all the multi-platform code and that XS code is untested. That'd be cool, but how does this merge/combining magically happen ? -merge which is the default. Though I'm not sure if you can receive two completely separate test runs and combine them at the moment. In that case you just say the magic words: Hey, Paul! ;) It would be easy enough to lump them together, though by itself, this wouldnt help identify platforms where a module is undertested. It wouldn't?
Re: testing Pugs with Perl 6 modules
Okay, a quick update on my situation ... 1. I completed the committer registration with the Pugs repository. 1.1 No problems per se, but the new member agreement was written in Chinese so I couldn't read it (the Google translate tool wasn't much help); so I just clicked through it. 2. Downloaded and installed the Colloquay IRC client for the first time, and it works great; I was able to get into IRC and chatted there from 5-12pm or so last night (GMT -8). 2.1 Thanks for both of the IRC client suggestions. 3. Downloaded and installed svn for the first time, with no problems. 4. Downloaded and installed GHC for the first time, no problems. 5. Created a local working folder for Pugs and fetched the latest version using svn, for the first time, no problems. 6. Detected problems in and fixed and committed the MAKEFILE and MAKEFILE.SKIP files; committed r486 and r488. 6.1 Apparently make manifest is your friend; saves on manual updates. 6.1.1 You still update the .SKIP manually, the above respects it. 7. The standard make procedures result in all tests passed though afterwards I got an error about v6.0.0 expected, this is only v5.8.1. 8. Had an IRC chat on names for Perl 6 modules; I'll post something about this to the email list in a little while, following what came out of that (suggesting the creation of a FAQ-type or standards committee recommendation type document). Finally, I expect to add+commit the first Locale::KeyedText for Perl 6 in a few days. -- Darren Duncan
Re: CPAN modules coverage
Michael G Schwern wrote: On Mon, Mar 07, 2005 at 11:24:42AM -0700, Jim Cromie wrote: are MM or MB analyses posted anywhere for general perusal ? Nope. You're free to run it yourself though. :) Its likely to be pretty appauling because of all the multi-platform code and that XS code is untested. I'll just take your word for it. :-) That'd be cool, but how does this merge/combining magically happen ? -merge which is the default. Though I'm not sure if you can receive two completely separate test runs and combine them at the moment. In that case you just say the magic words: Hey, Paul! ;) his ears must have been buzzing.. It would be easy enough to lump them together, though by itself, this wouldnt help identify platforms where a module is undertested. It wouldn't? I guess it depends on what 'lumped' means. I suppose the useful thing would be to have the individual reports available too, so yes it would help.
Re: what namespace for (future|new) module ?
Le lundi 7 mars 2005, à 08 heures 05, Michael G Schwern écrivait : On Mon, Mar 07, 2005 at 01:33:43PM +0100, C?dric Bouvier wrote: Maybe this list is not the right place to ask after all. module-authors@perl.org maybe? Thank you Jim and Michael for the hint. I will post there. My apologies for what I now understand is off topic. -- C é d r i c B o u v i e r
Re: CPAN modules coverage
On Mon, Mar 07, 2005 at 12:54:00PM -0700, Jim Cromie wrote:
Nope. You're free to run it yourself though. :)
Its likely to be pretty appauling because of all the multi-platform code
and that XS code is untested.
I'll just take your word for it. :-)
Well, I ran it myself and it is pretty horrifying. About half the statements
are covered. Even MM_Unix is only at 63%.
http://makemaker.org/tmp/cover_db/
Though I'd be interested to know how MM_MacOS with 0% in everything comes out
with a 33% total.
Additionally, Devel::Cover caused a test failure in hints.t.
I guess it depends on what 'lumped' means.
I suppose the useful thing would be to have the individual reports
available too,
so yes it would help.
You take the union of all the reports. So let's say you had code like this:
1 if( $Is_Windows ) {
2 ...do this...
3 }
4 else {
5 ...do that...
6 }
Alice runs Windows which covers line 2 and half the conditional. Bill runs
Unix which covers line 5 and the other half of the conditional. Combine
their two runs and you have statements 2 and 5 plus the entire conditional:
full coverage.
Adding linear interpolation to an array
I was trying to work out how to get non-integer indexes working for an
array -- initially using linear interpolation, though perhaps later it
would be generalized. Can anyone comment on whether this simple role
would work as I expect. Does defining the invocant as Num @self is
constant constrain the application of the role to read-only uses of
indices? Does the explicit indexing by an int typed value ensure that
it'll be non-recursive under MMD?
role LinearInterpolation
{
multi method Num postcircumfix:«[]» (
Num @self is constant : Num $real_index)
{
int $integer_index = int $real_index;
Num $first_value = @self[$integer_index];
return $first_value if $integer_index == $real_index;
Num $second_value = @self[$integer_index+1];
Num $delta = $second_value - $first_value;
Num $weight = $real_index - $integer_index;
return $first_value + $delta * $weight;
}
}
my @test does LinearInterpolation;
@test[0] = 1;
@test[1] = 3;
assert @test[0] == 1;
assert @test[0.5] == 2;
assert @test[1] == 3;
If I later decare a sub as
sub foo ( @in does LinearInterpolation ) { ... }
Would I be able to pass a normal (non-interpolating) array to this sub,
and then access it using non-integer indices (i.e. is the data in the
array independent of the interface through wich it is accessed).
Dave.
Re: Optional binding
Larry Wall wrote:
Or, assuming you might want to generalize to N dimensions someday, just
sub bar ([EMAIL PROTECTED]) {...}
and deal with it as in Perl 5 as a variadic list. I suppose one could say
sub bar ([EMAIL PROTECTED] is shape(3)) {...}
and get checking on the argument count.
if I understand correctly, without using multi subs:
sub bar(@coords is shape(3)) { ... }
bar(@xyz); # ok
bar( [$x, $y, $z] ); # ok
bar($x, $y, $z); # compile-time error
while:
sub bar([EMAIL PROTECTED] is shape(3)) { ... }
bar(@xyz); # ok
bar( [$x, $y, $z] ); # ok
bar($x, $y, $z); # ok
bar == $x, $y, $z; # still ok
am I right?
cheers,
Aldo
[Parrot 0.1.2] examples/assembly/ncurses_life.imc error
Hello, if I try the ncurses_life.imc demo I get the error Null PMC access in invoke(). This is the debug output: [EMAIL PROTECTED]:~/tmp/parrot/examples/assembly parrot -d ncurses_life.imc *** Parrot VM: Setting stack top. *** *** Parrot VM: Slow core *** *** Parrot VM: Setting up ARGV array in P5. Current argc: 1 *** 0: ncurses_life.imc Null PMC access in invoke() *** Parrot VM: Dumping GC info *** Total memory allocated = 417792 DOD runs = 1 Lazy DOD runs = 0 Collect runs = 0 Collect memory = 0 Active PMCs = 703 Extended PMCs = 270 Timely DOD PMCs = 0 Total PMCs = 5720 Active buffers = 370 Total buffers = 7053 Header allocations since last collect = 24 Memory allocations since last collect = 3 I'm sure it has problems with the ncurses NCI. How can I solve the problem? Other examples run without problems - but I haven't tested all :-) Thank you, good bye, Uwe
Re: Adding linear interpolation to an array
Dave Whipp wrote:
Does defining the invocant as Num @self is constant constrain the application
of the role to read-only uses of indices?
I don't think you need is constant. arguments are readonly by default,
unless you give them the is rw trait. I guess that is constant means
that you can specify the index only using a literal, not a variable, eg:
@test[1]; # ok, 1 is a costant
my $idx = 1;
@test[$idx]; # nok, $idx is not a constant
but I may be wrong.
Does the explicit indexing by an int typed value ensure that
it'll be non-recursive under MMD?
you mean Num typed value? if so, I guess using an explicitly
non-integer index would make it win under MMD. on the other hand, your
method could even not be called at all with an integer index.
If I later decare a sub as
sub foo ( @in does LinearInterpolation ) { ... }
Would I be able to pass a normal (non-interpolating) array to this sub,
and then access it using non-integer indices (i.e. is the data in the
array independent of the interface through wich it is accessed).
I don't think so. I'm afraid you have to do something like:
sub foo (@in) {
my @_in = @in;
if(! @in.does(LinearInterpolation) ) {
@_in does LinearInterpolation;
}
# go ahead using @_in
...
}
cheers,
Aldo
Re: Adding linear interpolation to an array
Aldo Calpini wrote:
I don't think you need is constant. arguments are readonly by default,
unless you give them the is rw trait. I guess that is constant means
that you can specify the index only using a literal, not a variable, eg:
@test[1]; # ok, 1 is a costant
my $idx = 1;
@test[$idx]; # nok, $idx is not a constant
What I was trying to do is to prevent using fractional indices in lvalue
context. I.e. my role wouldn't be considered for @x[0.5] = 2.
but I may be wrong.
Does the explicit indexing by an int typed value ensure that it'll
be non-recursive under MMD?
you mean Num typed value? if so, I guess using an explicitly
non-integer index would make it win under MMD. on the other hand, your
method could even not be called at all with an integer index.
That's what I'm hoping. Because my code does integer indexing, and I
wouldn't want it to call itself. I guess could be explicit:
$value = @self.Array::postcircumfix«[]»($index);
If I later decare a sub as
sub foo ( @in does LinearInterpolation ) { ... }
Would I be able to pass a normal (non-interpolating) array to this
sub, and then access it using non-integer indices (i.e. is the data in
the array independent of the interface through wich it is accessed).
I don't think so. I'm afraid you have to do something like:
sub foo (@in) {
my @_in = @in;
if(! @in.does(LinearInterpolation) ) {
@_in does LinearInterpolation;
}
# go ahead using @_in
...
}
I don't see why I need the conditional there. If I'm going to copy the
array, I might as well declare up front the that darget does
LinearInterpolation:
sub foo (Num @raw_in)
{
my Num @in does LinearInterpolation = @raw_in;
...
}
Or perhaps even
sub foo (Num @in is copy does LinearInterpolation)
{
...
}
Dave.
Re: Optional binding
On Mon, Mar 07, 2005 at 05:36:08PM +0100, Aldo Calpini wrote:
David Storrs wrote:
Urk. I, for one, will definitely find this surprising. I would have
expected:
x = whatever; $y = 1; z = 2 3
to obtain what you have expected, you need to explicitly treat the array
as a list of values with the unary splat:
foo($x, [EMAIL PROTECTED]);
But I suppose it's all a question of learning to love the Brave New
World in which arrays are actually objects (sort of).
more to the point, arrays are automagically referenced in scalar context:
@a = @b; # same as perl5
$a = @b; # means $a = [EMAIL PROTECTED] in perl5
$a = [EMAIL PROTECTED]; # means $a = @b in perl5 (more or less)
Yes, I know. That's what I meant by ...arrays are objects...(sort
of). They are objects in the sense that they are sort of references
and sort of not and that they have behavior built into them
(e.g. C.length). They won't actually have a class (I don't
think...type Array is not the same as a hypothetical class Array,
right?), but otherwise they quack awfully much like an object.
another thing that may surprise you (it still surprises me, somehow):
sub bar($x, $y, $z) { ... }
# ^ note x is scalar here!
my @coords = (1.0, 3.0, 5.0);
bar(@coords); # wrong
# x = [EMAIL PROTECTED], y = undef, z = undef
bar([EMAIL PROTECTED]); # ok
Yep, I am pretty sure that's going to trip me up endlessly for the
first 6 months or so.
To be perfectly honest, there are steadily more things I don't like
about the way Perl 6 is going, especially when it comes to signatures.
They are excessively verbose, they lead to (what I think is, and what
I suspect most Perl 5 programmers will think is) weird behavior like
that described above, and the type system feels like a straitjacket.
I know all these features are optional, but they WILL be used, which
means I have to know them so that I can maintain other people's code.
Essentially, it feels like we're turning our beautiful language into
something that has all the fun of Java but without Sun's marketing
budget.
But, every time I find myself thinking these things I take a deep
breath, put my faith in Larry, and assume that it will work out--I
really do have an amazing degree of faith in his ability to pull off
miracles. Hopefully, after I have a chance to play with the
production version of P6 for a while, all of these things that
currently seem like effluent will start to see like useful tools.
Fingers crossed,
--Dks
--
[EMAIL PROTECTED]
Re: CPAN modules coverage
On Mon, Mar 07, 2005 at 07:59:40PM +0100, Paul Johnson wrote: To do it properly it would need to be on a machine somewhere which would accept uploaded coverage databases from anyone who wanted to submit one. I discussed cover.perl.org or something with Andy and Robrt on irc a while back, but I've not made progress on the sw side. Because your free time is already filled up with working on Devel::Cover itself? This sounds like the sort of project that anyone who felt particularly keen about could try experimenting with at home, to see if they can get it to work. Having a demonstrable experiment is a very good first step to convincing others to help you with it, and having something that is mostly finished is a good way to get someone else to host a fully working version. Actions speak louder than words. Nicholas Clark
Re: dynclasses OS X test failures - a Perl task
On Mon, 7 Mar 2005, Andy Dougherty wrote: On Sat, 5 Mar 2005, Leopold Toetsch wrote: Andy Dougherty wrote: make: *** No rule to make target `blib/include/unicode/ucnv.h', needed by `src/string_primitives.o'. Stop. This was fixed by Bernhard yesterday. Thanks. I must have missed his fix by just a few hours. I'll check today that the dynaclasses/py* are working for me. Yup, they are. Great. The only remaining failure now is under op/trans. I've posted a patch for that separately. -- Andy Dougherty [EMAIL PROTECTED]
[perl #34366] [PATCH] Sun's compiler needs -xlibmieee for atan2
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #34366]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34366
t/op/trans.t tests the atan2() function for some exceptional cases
involving negative 0.0. By default, Sun's compiler doesn't handle those
cases, but with the -xlibmieee flag, it does.
This patch adds code to config/auto/hints/solaris.pl to set the flag if
you're using the Sun compiler. This also uncovered a problem with the
config/auto/gcc.pl script where it wasn't setting gccversion in some
cases. This had the side effect that Configure 'triggers' based on
gccversion would only get called if gccversion was defined. This patch
also patches gcc.pl to work around that problem.
diff -r -u parrot-current/config/auto/gcc.pl parrot-andy/config/auto/gcc.pl
--- parrot-current/config/auto/gcc.pl Sun Nov 14 19:00:11 2004
+++ parrot-andy/config/auto/gcc.pl Mon Mar 7 15:52:04 2005
@@ -35,14 +35,22 @@
my($gccversion, $warns, $ccwarn);
$ccwarn=Configure::Data-get('ccwarn');
+ # Set gccversion to undef. This will also trigger any hints-file
+ # callbacks that depend on knowing whether or not we're using gcc.
+
+ # This key should always exist unless the program couldn't be run,
+ # which should have been caught by the 'die' above.
unless (exists $gnuc{__GNUC__}) {
+Configure::Data-set(gccversion = undef);
return;
}
+
my $major = $gnuc{__GNUC__};
my $minor = $gnuc{__GNUC_MINOR__};
unless (defined $major) {
print (no) if $_[1];
$Configure::Step::result = 'no';
+Configure::Data-set(gccversion = undef);
return;
}
if ($major =~ tr/0-9//c) {
diff -r -u parrot-current/config/init/hints/solaris.pl
parrot-andy/config/init/hints/solaris.pl
--- parrot-current/config/init/hints/solaris.pl Wed Feb 2 11:00:06 2005
+++ parrot-andy/config/init/hints/solaris.plMon Mar 7 15:52:22 2005
@@ -6,12 +6,13 @@
$libs .= ' -lpthread';
}
if ( $libs !~ /-lrt\b/ ) {
-$libs .= ' -lrt';
+$libs .= ' -lrt'; # Needed for sched_yield.
}
Configure::Data-set(
libs = $libs,
);
+
my $link = Configure::Data-get('link');
# Going to assume Sun's compiler
# In which case we need to link with the C++ compiler (CC) rather than the
@@ -20,14 +21,39 @@
Configure::Data-set('link', $link);
# if it turns out we're using gcc, then we need to make sure we're linking
-# with g++, not gcc. We can't make this decision until later, because the
-# gcc test hasn't been run yet.
-my $solaris_cb = sub {
+# with g++, not gcc. We can't make this decision until the gccversion test
+# has been run.
+my $solaris_link_cb = sub {
my ($key, $gccversion) = @_;
if ($gccversion) {
Configure::Data-set('link', 'g++');
-Configure::Data-deltrigger(gccversion, solaris_hints);
+Configure::Data-deltrigger(gccversion, solaris_link);
}
};
+Configure::Data-settrigger(gccversion, solaris_link, $solaris_link_cb);
-Configure::Data-settrigger(gccversion, solaris_hints, $solaris_cb);
+
+# Parrot usually aims for IEEE-754 compliance.
+# For Solaris 8/Sun Workshop Pro 4, both
+#atan2( 0.0, -0.0) and atan2(-0.0, -0.0)
+# return 0, when they should return +PI and -PI respectively.
+# For Sun's compilers, fix this with the -xlibmieee flag.
+# I don't know of an equivalent flag for gcc.
+# (Alternatively, and more generally, perhahs we should run an
+# ieee-conformance test and then call back into a hints-file trigger
+# to set platform-specific flags.
+# A. Dougherty 7 March 2005
+# We don't know which compiler we're using till after the gccversion test.
+my $solaris_ieee_cb = sub {
+my ($key, $gccversion) = @_;
+if ($gccversion) {
+ # Don't know how to do this for gcc.
+}
+else {
+ my $linkflags = Configure::Data-get('linkflags');
+ Configure::Data-add(' ', 'linkflags', '-xlibmieee')
+ unless $linkflags =~ /-xlibmieee/;
+}
+Configure::Data-deltrigger(gccversion, solaris_ieee);
+};
+Configure::Data-settrigger(gccversion, solaris_ieee, $solaris_ieee_cb);
--
Andy Dougherty [EMAIL PROTECTED]
Re: [Parrot 0.1.2] examples/assembly/ncurses_life.imc error
On Mon, 2005-03-07 at 20:43 +0100, Uwe Voelker wrote: if I try the ncurses_life.imc demo I get the error Null PMC access in invoke(). I'm sure it has problems with the ncurses NCI. How can I solve the problem? Apply this patch, then let me know if it fixes it for you so that I can check it in. For what it's worth, I turned on tracing, found the file and the line with the problem, then removed it. It might be better to port the demo to use the ncurses.imc file, as it looks more recent, but this is the quickest patch I have. -- c Index: runtime/parrot/library/ncurses.pasm === RCS file: /cvs/public/parrot/runtime/parrot/library/ncurses.pasm,v retrieving revision 1.1 diff -u -u -r1.1 ncurses.pasm --- runtime/parrot/library/ncurses.pasm 25 May 2004 18:06:26 - 1.1 +++ runtime/parrot/library/ncurses.pasm 7 Mar 2005 23:00:05 - @@ -650,4 +650,3 @@ dlfunc P2, P1, 'has_key', 'ii' store_global 'ncurses::has_key', P2 restoreall -invoke P1
Re: CPAN modules coverage
On Mon, Mar 07, 2005 at 10:33:11PM +, Nicholas Clark wrote: On Mon, Mar 07, 2005 at 07:59:40PM +0100, Paul Johnson wrote: To do it properly it would need to be on a machine somewhere which would accept uploaded coverage databases from anyone who wanted to submit one. I discussed cover.perl.org or something with Andy and Robrt on irc a while back, but I've not made progress on the sw side. Because your free time is already filled up with working on Devel::Cover itself? Yes. Free time has been pretty scarce recently and hacking time has to compete with a plethora of other stuff. This sounds like the sort of project that anyone who felt particularly keen about could try experimenting with at home, to see if they can get it to work. Having a demonstrable experiment is a very good first step to convincing others to help you with it, and having something that is mostly finished is a good way to get someone else to host a fully working version. Actions speak louder than words. Absolutely. Anyone who would like to is quite welcome to work on this. I don't even think it's too much work. The Devel::Cover side of things is all in place and available in the distribution. What is missing is some way of transfering the coverage datbase from one machine to another. Merging the databases and producing the consolidated web page should already work. I had wanted to store more information about the environments in which the coverage was obtained, and to display that in the report, but that it not essential for a first cut. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
[Pugs] Bugs
Autrijus and Co.
I have found another weird bug. It apprears to be a problem with the
way the return statement handles Array refs and Hash refs in scalar
context. I have some tests in t/op/sub_return_values.t which test the
array ref problem. I will try and flesh out the hash-ref tests in the
same file later tonight. But anyway here is a description of the bug.
The following code:
pugs -e 'sub foo { return [ 1, 2, 3 ] }; my $test = foo(); say
$test; say ref($test);'
will print out:
3
Int
While all of the following code:
pugs -e 'sub foo { [ 1, 2, 3 ] }; my $test = foo(); say $test; say
ref($test);'
pugs -e 'sub foo { return ( 1, 2, 3 ) }; my @test = foo(); say
@test; say ref(@test);'
pugs -e 'sub foo { return [ 1, 2, 3 ] }; my @test = foo(); say
@test; say ref(@test);'
will print out:
123
List
I also suspect that the same bug is causing this code:
pugs -e 'sub foo { my %h = (one,1,two,2,three,3); return \%h;
}; my $test = foo(); say $test; say ref($test);'
to print out:
two2
Pair
because all of these (note the lack of return statement):
pugs -e 'sub foo { my %h = (one,1,two,2,three,3); \%h; }; my
$test = foo(); say $test; say ref($test);'
pugs -e 'sub foo { my %h = (one,1,two,2,three,3); %h; }; my
$test = foo(); say $test; say ref($test);'
will print out:
one 1
three 3
two 2
Hash
Then there is this code:
pugs -e 'sub foo { my %h = (one,1,two,2,three,3); return %h; };
my %test = foo(); say %test; say ref(%test);'
which won't even compile. The error is spits out is:
Fail: cannot cast into [VPair]: VSub (Sub {isMulti = False, subName =
foo, subType = SubRoutine, subPad = [], subAssoc = pre, subParams
= [Param {isInvocant = False, isSlurpy = True, isOptional = False,
isNamed = True, isLValue = False, paramName = @_, paramContext =
List, paramDefault = Val VUndef}], subReturns = Any, subFun =
Statements [(Syn sym [Sym (Symbol {symScope = SMy, symName = %h,
symExp = Syn mval [Var %h,Syn , [Syn , [Syn , [Syn , [Syn
, [Syn cxt [Val (VStr Str),App infix:~ [Val (VStr one),Val
(VStr )] []],Val (VInt 1)],Syn cxt [Val (VStr Str),App infix:~
[Val (VStr two),Val (VStr )] []]],Val (VInt 2)],Syn cxt [Val
(VStr Str),App infix:~ [Val (VStr three),Val (VStr )] []]],Val
(VInt 3)]]})],- (line 1, column 11)),(App return [Var %h] [],-
(line 1, column 48))]})
I suspect this to might be a symptom of the above bug, but I cannot
tell for sure.
Anyway, Hope this helps out some.
- Steve
Re: Optional binding
On Mon, Mar 07, 2005 at 10:29:58PM +0100, Aldo Calpini wrote:
: Larry Wall wrote:
: Or, assuming you might want to generalize to N dimensions someday, just
:
: sub bar ([EMAIL PROTECTED]) {...}
:
: and deal with it as in Perl 5 as a variadic list. I suppose one could say
:
: sub bar ([EMAIL PROTECTED] is shape(3)) {...}
:
: and get checking on the argument count.
:
: if I understand correctly, without using multi subs:
:
: sub bar(@coords is shape(3)) { ... }
:
: bar(@xyz); # ok
: bar( [$x, $y, $z] ); # ok
: bar($x, $y, $z); # compile-time error
Yes.
: while:
:
: sub bar([EMAIL PROTECTED] is shape(3)) { ... }
:
: bar(@xyz); # ok
: bar( [$x, $y, $z] ); # ok
: bar($x, $y, $z); # ok
: bar == $x, $y, $z; # still ok
:
: am I right?
The second one might fail, I think. The declaration says that @coords
as a whole has shape(3), not each individual element. On the other
hand, if you interpret the shape size as a maximum and not an exact match,
then you could end up with a value of [[$x,$y$z],undef,undef], though
of course, that would fail if you had declared it to be an array of int.
In fact, we really haven't specified what happens when you say
my Int @a is shape(3) := [1,2];
my Int @b is shape(3) := [1,2,3,4];
A strict interpretation requires both to be errors, but I can warp my
brain around to thinking either or both is okay. The first is kinda
okay because @a[2] can represent undef, and the array as a whole
successfully holds the whole value. The second is kinda okay
because the @b presents a view into a portion of the bound value,
and there aren't any parts of it that map onto nothingness.
But I also have this nagging feeling that the user wouldn't have
specified shape(3) unless they actually meant it. The question is
what they meant. It could be argued that shape(3) is just a storage
directive saying that we'll emulate the more general array semantics
with 3 elements. But I suspect that in the typical case, they really
do want a 3-element vector, nothing more, nothing less.
Our notation doesn't differentiate those intents, however. Let's
assume the strict intent, and if a different strategy is intended with
looser binding semantics, we can always use a different trait name.
I think a strict interpretation of shape gives a lot more information
to the optimizer.
Larry
Re: Optional binding
On Mon, Mar 07, 2005 at 02:20:47PM -0800, David Storrs wrote:
: Yes, I know. That's what I meant by ...arrays are objects...(sort
: of). They are objects in the sense that they are sort of references
: and sort of not and that they have behavior built into them
: (e.g. C.length). They won't actually have a class (I don't
: think...type Array is not the same as a hypothetical class Array,
: right?), but otherwise they quack awfully much like an object.
No, they're real objects. (Though it's .elems rather than .length, since
we've banished the l word from our vocabulary.)
: another thing that may surprise you (it still surprises me, somehow):
:
: sub bar($x, $y, $z) { ... }
:# ^ note x is scalar here!
:
: my @coords = (1.0, 3.0, 5.0);
: bar(@coords); # wrong
:# x = [EMAIL PROTECTED], y = undef, z = undef
:
: bar([EMAIL PROTECTED]); # ok
:
:
: Yep, I am pretty sure that's going to trip me up endlessly for the
: first 6 months or so.
:
:
: To be perfectly honest, there are steadily more things I don't like
: about the way Perl 6 is going, especially when it comes to signatures.
: They are excessively verbose, they lead to (what I think is, and what
: I suspect most Perl 5 programmers will think is) weird behavior like
: that described above, and the type system feels like a straitjacket.
: I know all these features are optional, but they WILL be used, which
: means I have to know them so that I can maintain other people's code.
: Essentially, it feels like we're turning our beautiful language into
: something that has all the fun of Java but without Sun's marketing
: budget.
:
:
: But, every time I find myself thinking these things I take a deep
: breath, put my faith in Larry, and assume that it will work out--I
: really do have an amazing degree of faith in his ability to pull off
: miracles. Hopefully, after I have a chance to play with the
: production version of P6 for a while, all of these things that
: currently seem like effluent will start to see like useful tools.
And I have put my faith in the Perl community, and assume it will work
out, because I have an amazing degree of faith in the ability of the
community to recognize the real effluent and avoid it. :-)
: Fingers crossed,
Niy ygsy ,sjra uy s ;py gsefre yp ytor///
:seet
Re: Optional binding
On Mon, Mar 07, 2005 at 04:58:29PM -0800, Larry Wall wrote:
In fact, we really haven't specified what happens when you say
my Int @a is shape(3) := [1,2];
my Int @b is shape(3) := [1,2,3,4];
[...]
But I also have this nagging feeling that the user wouldn't have
specified shape(3) unless they actually meant it. But I suspect
that in the typical case, they really do want a 3-element vector,
nothing more, nothing less.
I agree that this is undoubtedly what they meant. I wonder though, if
there is then any way to explicitly leave off an element. Can I do
this:
sub foo( Int @a is shape(3) ) { ... }
foo(1, 2, undef);
--Dks
--
[EMAIL PROTECTED]
Re: Optional binding
On Mon, Mar 07, 2005 at 05:15:14PM -0800, Larry Wall wrote: On Mon, Mar 07, 2005 at 02:20:47PM -0800, David Storrs wrote: : Yes, I know. That's what I meant by ...arrays are objects...(sort No, they're real objects. (Though it's .elems rather than .length, since we've banished the l word from our vocabulary.) Ah, ok. I've got to scrape up the tuits to go back and reread the AEs. Actually, I guess they would have to be...can you apply a role to a bare type? my int does SelectOutputFile; # I would expect this to fail my Int does SelectOutputFile; # I would expect this to work : But, every time I find myself thinking these things I take a deep : breath, put my faith in Larry, and assume that it will work out--I : really do have an amazing degree of faith in his ability to pull off : miracles. Hopefully, after I have a chance to play with the : production version of P6 for a while, all of these things that : currently seem like effluent will start to see like useful tools. And I have put my faith in the Perl community, and assume it will work out, because I have an amazing degree of faith in the ability of the community to recognize the real effluent and avoid it. :-) I think I've just been very, very gently poked. : For the record--just because I personally dislike these things doesn't make them bad, or even bad for the language. I didn't even say that they WERE effluent, just that right now they seem that way to me personally...and I'm trying to get past it. As I said, I'm confident it will all work out well in the end. : Fingers crossed, Niy ygsy ,sjra uy s ;py gsefre yp ytor/// :seet At first I thought I had annoyed you enough that you were attempting to summon an Elder God through my terminal. Then I realized that it works out to: But that makes it a lot harder to type... Larry Owie...stop making my head hurt! : --Dks -- [EMAIL PROTECTED]
Analysis of operator ?? ::
Hello, this mail is an analysis of implementing operator ternary
operator ?? :: in pugs.
Welcome for suggestions.
I. ?? :: in pugs
The implementation of ?? :: in pugs is buggy. Below are two perl
6 expressions
which pugs can NOT parse.
1. '(1 ?? 2 :: 3)' should return 2. t/03operator.t line 26.
2. '$t = 1 ?? true :: false' should makes $t = true.
t/syntax//decl_vs_assign_prec line 8.
Pugs failed to parse the first one, and in second one, $t is assigned
to 1 and the
whale expression returns true.
The first error is because in Parser.hs, rulePostTernary is only
in ruleExpression
which is a top level rule and makes ?? :: works on the same level as post if
condition. And in the parenthesis, parseOp is used instead of ruleExpression,
which failed to parse ??.
The second one is kind of extension problem of the first one.
Since the level
of ?? :: is too high, assignment expression takes place first.
II. Implementations in other compilers.
I referenced several open source compilers implemented trenary operators.
Including gcc-4.0, gcc-4.1, g++-3.3, g++-4.1 and perl-5.9.1
gcc-4.0: yacc (bison) grammar
gcc-4.1: hand-written recursion-descent parser in C
g++-3.3: yacc (bison) grammar
g++-4.1: hand-written recursion-descent parser in C
perl-5.9.1: yacc (bison) grammar
IIa. gcc-4.0 g++-3.3, yacc grammar
These are almost the same. First of all, specify the priority:
%right code '?' ':'
Then the expression grammar is given:
expr: expr_no_commas | expr ',' expr_no_commas ;
expr_no_commas:
cast_expr
| ... // binary operations
| expr_no_commas '?' expr ':' expr_no_commas
;
IIb. gcc-4.1, C code
Here is a draft of parser, omitting AST building code and
unneccesary parameters.
c_parser_expression ()
{
c_parser_expr_no_commas ();
while (c_parser_next_token_is (CPP_COMMA))
{
c_parser_consume_token (); // consume ','
c_parser_expr_no_commas ()
}
}
c_parser_expr_no_commas ()
{
c_parser_conditional_expression ();
}
c_parser_conditional_expression ()
{
c_parser_binary_expression ();
if (c_parser_next_token_is_not (CPP_QUERY))
return;
c_parser_consume_token (); // consume '?'
c_parser_expression ();
c_parser_require (CPP_COLON);
c_parser_conditional_expression ();
}
c_parser_binary_expression ()
{
/* parse expression
binary-expression:
simple-cast-expression
| binary-expression token binary-expression
*/
}
IIc. g++-4.1, C code
cp_parser_expression ()
{
cp_parser_assignment_expression ();
}
cp_parser_assignment_expression ()
{
cp_parser_binary_expression ();
if (cp_lexer_next_token_is (CPP_QUERY))
cp_parser_question_colon_clause ()
}
cp_parser_question_colon_clause ()
{
cp_lexer_consume_token (); // Consume '?'
cp_parser_expression ();
cp_parser_require (CPP_COLON);
cp_parser_assignment_expression ();
}
cp_parser_binary_expression ()
{
// works similiar to c_parser_binary_expression
}
IId. perl-5.9.1, yacc grammar.
Since there are loose logical operators in perl 5, too, should be helpful.
%left ival OROP DOROP
%left ANDOP
%right '?' ':'
...
expr: expr ANDOP expr
| expr OROP expr
| expr DOROP expr
| argexpr %prec PREC_LOW
;
argexpr: argexpr ','
| argexpr ',' term
| term %prec PREC_LOW
term: termbinop
| termunop
| ...
| term '?' term ':' term
III. Solutions.
In Parser.hs, ternOps is defined but does not generate any thing. I don't
know if it's because Parsec doesn't support suching gramma or not.
If Parsec really lack such support, I have two suggestions:
1. Hack Parsec and make it work, but I don't know the difficulty.
2. Learn from the two hand-written parser, add another level
of parser.
I've tried to write an extremely little parser in the second way
as in attachment.
Somehow dirty, but maybe acceptable.
Shu-Chun Weng
module Parser where
import Rule
import Rule.Expr
{-
usage:
Parser run expr 10mul1-1??3::4
40
Parser run expr (1add1-2)??56::78
78
-}
binExpr :: Parser Integer
binExpr = buildExpressionParser binTable binFactor ? binary expression
binTable = [[op * (*) AssocLeft, op / (div) AssocLeft]
,[op + (+) AssocLeft, op - (-) AssocLeft]]
where
op s f assoc = Infix (do{ string s; return f}) assoc
binFactor = do{ char '('
; x - expr
; char ')'
; return x
}
| number
? simple expression
expr :: Parser Integer
expr = buildExpressionParser looseTable looseFactor ? loose expression
looseTable = [[op mul (*) AssocLeft]
, [op add (+) AssocLeft]
]
where
op s f assoc = Infix (do{ string s; return f}) assoc
looseFactor =
try(do{ char '('; x - expr; char ')'; eof; return x })
|
do{
a - binExpr;
do{
try(string ??);
b - expr;
string ::;
c - expr;
if a == 0 then return c
Re: Optional binding
On Mon, Mar 07, 2005 at 05:56:12PM -0800, David Storrs wrote: : On Mon, Mar 07, 2005 at 05:15:14PM -0800, Larry Wall wrote: : On Mon, Mar 07, 2005 at 02:20:47PM -0800, David Storrs wrote: : : Yes, I know. That's what I meant by ...arrays are objects...(sort : : No, they're real objects. (Though it's .elems rather than .length, since : we've banished the l word from our vocabulary.) : : Ah, ok. I've got to scrape up the tuits to go back and reread the : AEs. Bear in mind the As have [Update] sections but the Exegeses do not. The Ss should be relatively up-to-date though. : Actually, I guess they would have to be...can you apply a role to a : bare type? : : my int does SelectOutputFile; # I would expect this to fail : my Int does SelectOutputFile; # I would expect this to work The latter always works. The former can probably be made to work in the case of roles that only add methods and don't change the storage representation, since the vtable is associated with the class and not the object. :seet, er, I mean, Larry
Perl 6 Summary for 2005-02-22 though 2005-03-07
Perl 6 Summary for 2005-02-22 though 2005-03-07 All~ Welcome to yet another fortnight summary. Once again brought to you by chocolate chips. This does have the distinction of being the first summary written on a mac. So if I break into random swear words, just bear with me. Off list development In more related news, It has been pointed out to me that development goes on off list on places like IRC. I briefly contemplated, quitting my job and tracking such things full time, but then I decided that it would be better if I just accepted brief submissions for the summary. Thus I will be adding a fourth section to the summaries based on contributions. If you would like to make a contribution, email me with a brief summary. Please include the name by which you would like to be attributed (sadly the process I use is likely to mangle any unicode characters). Please make all links full, I will shorten them. Thanks Perl 6 Language not() It turns out that not() (with no arguments) made perl 5 core dump for a while, and it took us five years to figure that out. In perl 6 it will be a list op and calling it with no arguments will return a null list or an undef depending on context. http://xrl.us/fdb9 junctions and threading I had hoped that last week the concerns about threading would have been addressed. I was mistaken. A new crop of concerns surfaced and died down fairly quickly (as the chief proponent, Damien, was away). http://xrl.us/fdca serializing to various languages Somehow the discussion of junctions morphed into a discussion of sets, which morphed back into junctions, which morphed into a discussion of serialization to different languages. Interesting stuff, but I wouldn't hold me breath for it... http://xrl.us/fdcb Performance Analysis and Benchmarks Adam Preble posted an offer to develop some benchmarks for perl 6. Unfortunately, I think he posted it to google groups. Also, he probably should have posted it to p6c or p6i as the language folk tend to wave their hands and say magic occurs but correctness is preserved when it comes to optimization. http://xrl.us/fdcc send + more = junctions Autrijus posted an example using junctions, instead of parents, to solve the classic SEND MORE + = MONEY problem. Markus Laire asked for a clarification, and Rod Adams pointed out that he felt that it would not work as the interdependence of the es was not captured. This does lead to the question of how one should right prolog like code (including unification and backtracking) in Perl 6. No answers were offered. http://xrl.us/fdcd Pairs as lvalues Ingo Blechschmidt wondered what the behavior of pairs as lvalues would be. The answer is that you would get an error for attempting to modify a constant. http://xrl.us/fdce Perl 6 Roberto Bisotto wanted to know where he could download perl 6 to start playing with it. We embarrassedly told him that a full implementation was not yet available, but pugs was gaining ground quickly. http://xrl.us/fdcf hash keys Autrijus wanted to know if hash keys were still just strings or if they could be more. The answer is that by default they would be strings, but they could be declared as having a different shape . This led to a discussion of hashing techniques such as the .bits, .canonicalize, or .hash methods. http://xrl.us/fdcg Dynamically scoped dynamic scopes Dave Whipp wanted to make dynamically scoped dynamic scopes. My head hurt, but apparently Larry's didn't as he replied piece of cake, the syntax [and implementation] are left as an exercise to for the would be module author. http://xrl.us/fdch Parameters to rules Rod Adams asked how he could specify arguments to rules so they could be more function like. Larry explained that there were several syntaxes each of which would coerce its arguments in slightly different ways. He then mused that perhaps there were too many, I agree there are too many. http://xrl.us/fdci compile time signature checking Ahbijit Mahabal wondered how type checking would work for cases where it was not easy to determine the types at compile time. The answer: checking will be defered to runtime. In the end it seems that Perl 6 will blur the line between runtime and compile time heavily. Perhaps it will provide nifty support for staged programming, meta-perl6 here we come... http://xrl.us/fdcj %*CONFIG and %?CONFIG Brian Ingerson asked about the CONFIG hash and what sort of secondary sigil it would have. Larry explained that $?CONFIG held to config for the machine compiling the program and $*CONFIG held the config for the machine running the program. Then he made some noice about parsing,
Re: Optional binding
On Mon, Mar 07, 2005 at 05:37:53PM -0800, David Storrs wrote:
: On Mon, Mar 07, 2005 at 04:58:29PM -0800, Larry Wall wrote:
:
: In fact, we really haven't specified what happens when you say
:
: my Int @a is shape(3) := [1,2];
: my Int @b is shape(3) := [1,2,3,4];
:
: [...]
: But I also have this nagging feeling that the user wouldn't have
: specified shape(3) unless they actually meant it. But I suspect
: that in the typical case, they really do want a 3-element vector,
: nothing more, nothing less.
:
: I agree that this is undoubtedly what they meant. I wonder though, if
: there is then any way to explicitly leave off an element. Can I do
: this:
:
: sub foo( Int @a is shape(3) ) { ... }
: foo(1, 2, undef);
That's illegal unless you either * the @a or [] the list. By itself an
@a declaration is always looking to bind a single parameter. Arguably,
1,2,undef could be interpreted as a single parameter, forcing the
scalar comma to auto-enreference a [1,2,undef] as it does when you say
$foo = (1,2,undef);
but then we lose argument count checking on any sig ending in an
array, and the meaning of comma subtly changes without warning at
a place other than the expected scalar/variadic boundary. So we
require splats to make that clear. I'd also note that
foo((1,2,undef))
would work in this case because parens in scalar context make all the args
into one arg. (In list context they would flatten, as they do in Perl 5.)
However, it's a lot clearer to say
foo([1,2,undef])
if that's what you mean.
Larry
Re: Optional binding
On Mon, Mar 07, 2005 at 07:50:47PM -0800, Larry Wall wrote:
On Mon, Mar 07, 2005 at 05:37:53PM -0800, David Storrs wrote:
: On Mon, Mar 07, 2005 at 04:58:29PM -0800, Larry Wall wrote:
: Is
: there is then any way to explicitly leave off an element. Can I do
: this:
:
: sub foo( Int @a is shape(3) ) { ... }
: foo(1, 2, undef);
That's illegal unless you either * the @a or [] the list.
Argh. My bad, I meant to * the @a. Ok, rewrite; is THIS legal?:
sub foo( Int [EMAIL PROTECTED] is shape(3) ) { ... }
foo(1, 2, undef);
The sense I'm trying to convey is:
Here is my sub. It takes three ints.
Here is me calling the sub. I am giving you only two ints and
explicitly telling you [by explicitly passing undef] that I meant
to do that so just take it and be quiet.
To put it another way...in perl5, a sub that was prototyped to take
three scalar args will throw an error when you pass only two but will
accept it if you pass two plus an explicit undef. On the other hand,
if it was prototyped to take an array there is no way to tell the
difference between an explicitly-passed undef and a too-short arg
list. How will P6 handle these two scenarios?
--Dks
finding the name of $SUB ?
Is there a way to find the name of ?SUB ? It would be useful for error-logging and -reporting. --Dks
Re: finding the name of $SUB ?
On Mon, Mar 07, 2005 at 09:49:04PM -0800, David Storrs wrote: : Is there a way to find the name of ?SUB ? It would be useful for : error-logging and -reporting. $?SUBNAME, I think, unless ?SUB just stringifies to that. I guess it's a good question whether foo should stringify to foo or foo or something else including the signature. In which case, ?SUB might stringify to a lot of info, and $?SUBNAME would more reliably be just the short name. Maybe we also need a way to get the long name explicitly. Larry
Re: finding the name of $SUB ?
LW == Larry Wall [EMAIL PROTECTED] writes: LW On Mon, Mar 07, 2005 at 09:49:04PM -0800, David Storrs wrote: LW : Is there a way to find the name of ?SUB ? It would be useful for LW : error-logging and -reporting. LW $?SUBNAME, I think, unless ?SUB just stringifies to that. I guess LW it's a good question whether foo should stringify to foo or LW foo or something else including the signature. In which case, LW ?SUB might stringify to a lot of info, and $?SUBNAME would more LW reliably be just the short name. Maybe we also need a way to get LW the long name explicitly. why not leave it as $?SUB but it is an object and you use the .name method? this way you won't clutter the namespace and you can add more methods like .signature, .returns, etc. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: finding the name of $SUB ?
On Tue, Mar 08, 2005 at 01:55:07AM -0500, Uri Guttman wrote: : why not leave it as $?SUB but it is an object and you use the .name : method? Uh, yeah. Obviously, 11 pm is still to early in the day for me... : this way you won't clutter the namespace and you can add more : methods like .signature, .returns, etc. In which case $?SUB and ?SUB are probably just different names for the same object, or we just go with ?SUB, and assume people will be able to figure out from the lack of parens that ?SUB.name is not calling the subroutine. Or I suppose we could go with straight $?SUB. Or both. Or one. Or the other. Or both. Or... Larry
Re: Optional binding
On Mon, Mar 07, 2005 at 08:58:44PM -0800, David Storrs wrote:
: Ok, rewrite; is THIS legal?:
:
: sub foo( Int [EMAIL PROTECTED] is shape(3) ) { ... }
: foo(1, 2, undef);
Yes, since Int can represent undef.
: The sense I'm trying to convey is:
:
: Here is my sub. It takes three ints.
:
: Here is me calling the sub. I am giving you only two ints and
: explicitly telling you [by explicitly passing undef] that I meant
: to do that so just take it and be quiet.
:
: To put it another way...in perl5, a sub that was prototyped to take
: three scalar args will throw an error when you pass only two but will
: accept it if you pass two plus an explicit undef. On the other hand,
: if it was prototyped to take an array there is no way to tell the
: difference between an explicitly-passed undef and a too-short arg
: list. How will P6 handle these two scenarios?
Could use exists, maybe. Though for an array with shape(3)
it's possible that exists(@a[2]) is always true regardless of the
bound value. On the other hand, binding an array that is too short
is going to be a type mismatch, so you probably can't get into the
situation of a shaped array being too short to begin with. It'll
either fail immediately in the case of a normal sub, or it'll
go off looking for something else to MMD to that doesn't violate
any type constraints, and fail if it doesn't fine one.
Larry
Re: finding the name of $SUB ?
LW == Larry Wall [EMAIL PROTECTED] writes: LW On Tue, Mar 08, 2005 at 01:55:07AM -0500, Uri Guttman wrote: LW : why not leave it as $?SUB but it is an object and you use the .name LW : method? LW Uh, yeah. Obviously, 11 pm is still to early in the day for me... ^^ or too late? :) (i wouldn't normally spellcheck you but you are usually very accurate and this must mean something) and 2am is bedtime for me now. LW : this way you won't clutter the namespace and you can add more LW : methods like .signature, .returns, etc. LW In which case $?SUB and ?SUB are probably just different names for LW the same object, or we just go with ?SUB, and assume people will be LW able to figure out from the lack of parens that ?SUB.name is not LW calling the subroutine. Or I suppose we could go with straight $?SUB. LW Or both. Or one. Or the other. Or both. Or... burble! i know how you feel. now slowly back away from the keyboard and say nighty night to us all. we need a refreshed larry and not one who pulls all nighters like some college kid (or damian :). uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
committed first Perl 6 port of a non-core CPAN module
I have just committed the first Perl 6 port of Locale::KeyedText within the Pugs distro, as was the recommended course of action in contrast to releasing to CPAN. This is the very first normal and non-core CPAN module to be translated to Perl 6, afaik. This module is identical to its Perl 5 counterpart except for the Perl code translation (and a copyright change); the POD is the same except that all the code samples were ported. It is located under /modules, which is where non-core stuff goes now. You are all free to go have a look. I have not tried to execute the code, since Pugs is known to not support some of the features it uses, such as classes/methods and simple rules. However, this module can be used for integration tests once Pugs is sufficiently updated. My port has some known bugs in it. Some bits I hadn't figured out the Perl 6 equivalent of, so they are still in Perl 5. I will research and fix the bugs over time. Or anyone else with Pugs commit privileges is free to do so. Have a good day. -- Darren Duncan P.S. The test suite for the Perl 5 version was not translated; this will be done later around when Pugs supports the necessary features to execute it.
