Re: CPANDB - was: Module::Dependency 1.84

[Adam Kennedy]

Tels wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Moin,

On Wednesday 12 July 2006 03:13, David Golden wrote:

Tels wrote:

My idea was to build _only_ the database, and do it right, simple and
easy to use and then get everyone else to just use the DB instead of
fiddling with their own. (simple by having the database being superior
to every other hack thats in existance now :-)

I even got so far as to do a mockup v0.02 - but then went back to
playing Guildwars.

Is this a project that would be of general interest?

At YAPC::NA, Adam Kennedy mention that he wanted to try to make some
headway on CPAN::Index, which sounds very similar in intent.  While it's
not released, you can see the formative project at his public repository:

http://tinyurl.com/g888h

Perhaps you can join forces with him and help push some collective
project towards a release.


Quoted:


B provides object-oriented access to the CPAN index,
using a collection of relatively common modules, and automates
entire process of fetching and accessing the index.


Uhm, no the DB should maybe be able to have a front-end that fills it from 
the CPAN index, but you should also be able to build a DB from a local 
file, if you so wish.


Well of course, and that's what it does.

If has a database structure with a DBIx::Class layer to the schema for a 
CPAN index, and it handily comes by default with modules to download the 
main CPAN index and stream it into the database.


If we wanted to add a different mechanism to populate the same database, 
that would be just fine. In fact, part of what I want is to create an 
equivalent of CPAN::Inject, to be able to build out a custom "modified 
CPAN" that also includes commercial modules.



The index is stored in a L database file, with an object
model implemented around it using L. To update the index,
the L class implements the logic to flush and reset
the database, fetch the index files, parse them, and repopulate the
database.


The DB backend shouldn't matter at all, it should be transparent and be 
switchable without any noticable change at the front.


Yep, right with you. Hence DBIx::Class.

Plus, I planned to
use YAML because it creates a _much_ less heavy overhead and dependency 
chain. Using SQLite or similiar is what really creates the problems with 
CPANTS - you cant just access the raw database without the front-end.


Erm, I'm not sure I get you here. The main problem with all the things 
that loads the index currently is that they tend to consume 50-100 meg 
of ram, and that's just the active index. Add in extra stuff and you're 
up into stupid amounts of ram quite quickly.


WithYAML, at least you could get at the data by other means. Of course for 
performance reasons it might not be good, but since premature optimization 
is the root of all evil, I'd say use YAML now, change when nec.


It's already necesary, based on the memory load. That's not to say you 
have to use SQLite to DISTRIBUTE or publish the data, just that when you 
access and manipulate it computationally, you do it via SQLite.


This method has worked spectacularly well in the JSAN code, which 
implements something very similar to what I'm heading towards. To do 
dependencies and so on, it just links an Algorithm::Dependency object 
into the DBIx::Class code, and there you have your full range of 
graph-math things, like dep chains (up and downstream) weights, etc.


Otherwise, the projects seem similiar in scope, except that I focus on the 
DB and let things like "download stuff" be done outside.


Whether that works out, uh I don't know. In any event I have quite a few 
ideas I'd like to try out and this proves to be fun to me. I hope it 
doesn't end upI have to implement other people ideas - thats too much work 
like :D


Have a look at just the database parts, which I've finished already from 
memory.


The bit that isn't finished is the complete "grab your CPAN.pm config 
and stream down all the files and populate the database".


Adam K

[perl #39810] [PATCH] regression tests for P6Regex syntax errors

[via RT]

# New Ticket Created by  Chris Dolan 
# Please include the string:  [perl #39810]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=39810 >


This patch adds a new syntax_errors.t file with some known broken  
regexps.  This is intended to exercise the  PGE::P6Regex error  
catching code.  This patch includes one TODO test for an unhandled  
P6Regexp error described in [perl #39809].  The patch also includes a  
new p6rule_throws() method in Parrot::Test::PGE

% diffstat pge_syntax_errors.patch
lib/Parrot/Test/PGE.pm  |   50 +++ 
+
t/compilers/pge/p6regex/syntax_errors.t |   44 +++ 
+
2 files changed, 94 insertions(+)

Chris



pge_syntax_errors.patch
Description: Binary data

Re: [perl #39715] [TODO] #39715 IMCC errors should throw Parrot exceptions

[Vishal Soni]

> >
> > PARROT_API void *Parrot_compile_file(Parrot_Interp interpreter,char
> > *fullname, String **error);
> 
> I like this interface, except for the return value from Parrot_compile_file.  
> Are there other options, such as returning a Sub PMC?

Chip and I have had a chat about other possible API's which could be
added in future. Some e.g.

1. To throw Parrot exceptions instead of the String **error.
2. Possibly using Compiler PMC. (not sure on that yet)

Your suggestion is good and I will keep in mind. 

These two functions are just a start for defining Compile API's.
Programming languages should not talk directly to IMCC or any other low
level compiler like IMCC and PASM. 

Thanks for your suggestion.
Vishal

Re: [perl #39715] [TODO] #39715 IMCC errors should throw Parrot exceptions

[chromatic]

On Wednesday 12 July 2006 22:02, Vishal Soni via RT wrote:

> This patch also introduces a Parrot API for the calling programs to
> compile the code. Currently pugs uses immc_compile() call into IMCC.
> Ideally Pugs should not be communicating with IMCC but with Parrot. This
> new API will try to hide IMCC/PASM compile details from programming
> languages
>
> PARROT_API PMC *Parrot_compile_string(Parrot_Interp interpreter, STRING
> *type, char *code, STRING **error);
>
> PARROT_API void *Parrot_compile_file(Parrot_Interp interpreter,char
> *fullname, String **error);

I like this interface, except for the return value from Parrot_compile_file.  
Are there other options, such as returning a Sub PMC?

-- c

Re: [perl #39809] PGE crash on parrot;PGE::Exp::Quant;reduce

[Chris Dolan]

On Jul 12, 2006, at 10:53 PM, Patrick R. Michaud wrote:


On Wed, Jul 12, 2006 at 08:04:01PM -0700, Chris Dolan wrote:

As simple token containing ":i" causes PGE to crash with an attempted
method call on Undef.

Steps to reproduce:
   1) Create a grammar file called "foo.pg" that has one line:
  token foo { :i a }


As I read S05, a modifier has to occur at the *very* beginning
of a regex (or group) in order to work.  In other words, no whitespace
before modifiers in a regex (because whitespace may have some
other meta-syntactic meaning with :sigspace).  Thus

token foo {:i a }

works, while

token foo { :i a }

is an error, since the ':' acts as a cut operator that doesn't
have anything to cut.

But I admit that since we've gone to regex/token/rule, then perhaps
leading whitespace prior to a modifier should be ignored.  That
probably needs a ruling from p6l or @Larry.

Pm


Ahh, that makes sense.  So it's possibly just an uncaught syntax  
error, and definitely a syntax error under :sigspace.  I propose that  
P6Regex.pir gets something like:

  parse_error(mob, pos, "Too late for modifier")
but I have not yet figured out where it belongs in P6Regex.pir.

On a related note, I don't see any regression tests for syntactically  
incorrect regexps.  I'm good at writing invalid regexps :-) so if  
someone starts a stub .t file for syntax errors, I'd be happy to  
populate it with TODO tests like the above.


Chris
--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Re: [perl #39809] PGE crash on parrot;PGE::Exp::Quant;reduce

[Patrick R. Michaud]

On Wed, Jul 12, 2006 at 08:04:01PM -0700, Chris Dolan wrote:
> As simple token containing ":i" causes PGE to crash with an attempted
> method call on Undef.
> 
> Steps to reproduce:
>1) Create a grammar file called "foo.pg" that has one line:
>   token foo { :i a }

As I read S05, a modifier has to occur at the *very* beginning
of a regex (or group) in order to work.  In other words, no whitespace
before modifiers in a regex (because whitespace may have some
other meta-syntactic meaning with :sigspace).  Thus

token foo {:i a }

works, while

token foo { :i a }

is an error, since the ':' acts as a cut operator that doesn't
have anything to cut.

But I admit that since we've gone to regex/token/rule, then perhaps
leading whitespace prior to a modifier should be ignored.  That
probably needs a ruling from p6l or @Larry.

Pm

[perl #39809] PGE crash on parrot;PGE::Exp::Quant;reduce

[via RT]

# New Ticket Created by  Chris Dolan 
# Please include the string:  [perl #39809]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=39809 >


---
osname= darwin
osvers= 8.0
arch=   darwin-thread-multi-2level
cc= cc
---
Flags:
 category=core
 severity=medium
 ack=no
---
As simple token containing ":i" causes PGE to crash with an attempted
method call on Undef.

Steps to reproduce:
   1) Create a grammar file called "foo.pg" that has one line:
  token foo { :i a }
   2) Run this command:
  ./parrot compilers/pge/pgc.pir --output=foo.pir foo.pg

Actual results:
set_integer_keyed() not implemented in class 'Undef'
current instr.: 'parrot;PGE::Exp::Quant;reduce' pc 4333  
(compilers/pge/PGE/Exp.pir:396)
called from Sub 'parrot;PGE::Exp::Concat;reduce' pc 4098  
(compilers/pge/PGE/Exp.pir:316)
called from Sub 'parrot;PGE::Exp;root_pir' pc 3609 (compilers/pge/ 
PGE/Exp.pir:69)
called from Sub 'parrot;PGE::P6Regex;compile_p6regex' pc 6244  
(compilers/pge/PGE/P6Regex.pir:123)
called from Sub 'parrot;PGE::P6Grammar;regex_stmt' pc 622  
(compilers/pge/pgc.pir:336)
called from Sub 'parrot;PGE::P6Grammar;compile_p6grammar' pc 345  
(compilers/pge/pgc.pir:225)
called from Sub 'parrot;PGE::P6Grammar;main' pc 135 (compilers/ 
pge/pgc.pir:111)

Expected results:
   Either a successful compile or a more understandable syntax error

Reproducibility:
   Reproduced on G5 Mac OS X 10.4.7, parrot r13176
   Reproduced on x86 FreeBSD 5.4, parrot r13181
   Reproduced on x86 Linux 7.x, parrot r13181

---
Summary of my parrot 0.4.5 (r13176) configuration:
   configdate='Thu Jul  6 00:20:50 2006'
   Platform:
 osname=darwin, archname=darwin-thread-multi-2level
 jitcapable=1, jitarchname=ppc-darwin,
 jitosname=DARWIN, jitcpuarch=ppc
 execcapable=1
 perl=perl
   Compiler:
 cc='cc', ccflags='-g -pipe -fno-common -no-cpp-precomp  -I/usr/ 
local/include
-pipe -fno-common -Wno-long-double  -I/sw/include -I/sw/include',
   Linker and Libraries:
 ld='c++', ldflags='-L/usr/local/lib -flat_namespace  -L/sw/lib - 
L/sw/lib',
 cc_ldflags='',
 libs='-lm -lgmp -lreadline'
   Dynamic Linking:
 share_ext='.dylib', ld_share_flags='-dynamiclib -undefined  
suppress',
 load_ext='.bundle', ld_load_flags='-bundle -undefined suppress'
   Types:
 iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
 ptrsize=4, ptr_alignment=1 byteorder=4321,
 nv=double, numvalsize=8, doublesize=8

---
Environment:
 DYLD_LIBRARY_PATHHOMELANGLANGUAGELC_ALL 
LD_LIBRARY_PATH   LOGDIRPATHPERL5LIB 
PERL5_CPANPLUS_CONFIGSHELL

[perl #39808] [PATCH] Allows execution of a single configure step such as rebuilding language makefiles

[via RT]

# New Ticket Created by  Kevin Tew 
# Please include the string:  [perl #39808]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=39808 >


example:

perl Configure --step=gen::languages


 Configure.pl |   12 +++
 lib/Parrot/Configure.pm  |  135 
+++
 lib/Parrot/Configure/Data.pm |   20 ++
 3 files changed, 116 insertions(+), 51 deletions(-)

Index: lib/Parrot/Configure/Data.pm
===
--- lib/Parrot/Configure/Data.pm(revision 13269)
+++ lib/Parrot/Configure/Data.pm(working copy)
@@ -171,6 +171,26 @@
 return keys %{$self->{c}};
 }
 
+=item C
+
+Slurps in Parrot::Config data from previous configure.
+
+Accepts no arguments.
+
+=cut
+
+sub slurp()
+{
+  my $self = shift;
+  
+  my $res = eval {
+use Parrot::Config;
+\%PConfig
+  };
+
+  $self->{c} = $res;
+}
+
 =item C
 
 Provides a L serialized string of the objects key/value pairs
Index: lib/Parrot/Configure.pm
===
--- lib/Parrot/Configure.pm (revision 13269)
+++ lib/Parrot/Configure.pm (working copy)
@@ -197,74 +197,111 @@
 
 my $n = 0; # step number
 foreach my $task ($self->steps) {
-my $step_name   = $task->step;
-my @step_params = @{$task->params};
-
 $n++;
+$self->_runstep($task, $verbose_step, $ask, $n);
+}
+return $self;
+}
 
-eval "use $step_name;";
-die $@ if $@;
+=item * C
 
-my $step = $step_name->new;
+The invoking
+L object is passed as the first argument to each steps
+C method followed by any parameters that were registered for that
+step.
 
-# XXX This works. but is probably not a good design.
-# Using $step->description() would be nicer   
-my $description = $step->description();
-$description = "" unless defined $description;
+Accepts no arguments and returns a L object.
 
-# set per step verbosity
-if (defined $verbose_step) {
+=cut
 
-# by step number
-if ($verbose_step =~ /^\d+$/ && $n == $verbose_step) {
-$self->options->set(verbose => 2);
-}
 
-# by description
-elsif ($description =~ /$verbose_step/) {
-$self->options->set(verbose => 2);
-}
+sub runstep
+{
+my $self = shift;
+my $taskname = shift;
+
+my ($verbose, $verbose_step, $ask) =
+$self->options->get(qw(verbose verbose-step ask));
+
+for my $task ($self->steps()) {
+if ( $task->{"Parrot::Configure::Task::step"} eq $taskname ) {
+print "$taskname\n";
+$self->_runstep($task, $verbose, $verbose_step, $ask, 1);
 }
+}
+}
 
-# XXX cc_build uses this verbose setting, why?
-$self->data->set(verbose => $verbose) if $n > 2;
+sub _runstep
+{
+my $self = shift;
+my $task = shift;
 
-print "\n", $description, '...';
-print "\n" if $verbose && $verbose == 2;
+my ($verbose, $verbose_step, $ask, $n) = @_;
 
-my $ret; # step return value
-eval {
-if (@step_params) {
-$ret = $step->runstep($self, @step_params);
-} else {
-$ret = $step->runstep($self);
-}
-};
-if ($@) {
-carp "\nstep $step_name died during execution: [EMAIL PROTECTED]";
-return;
+my $step_name   = $task->step;
+my @step_params = @{$task->params};
+
+
+eval "use $step_name;";
+die $@ if $@;
+
+my $step = $step_name->new;
+
+# XXX This works. but is probably not a good design.
+# Using $step->description() would be nicer   
+my $description = $step->description();
+$description = "" unless defined $description;
+
+# set per step verbosity
+if (defined $verbose_step) {
+
+# by step number
+if ($verbose_step =~ /^\d+$/ && $n == $verbose_step) {
+$self->options->set(verbose => 2);
 }
 
-# did the step return itself?
-eval { $ret->can('result'); };
-# if not, report the result and return
-if ($@) {
-my $result = $step->result || 'no result returned';
-carp "\nstep $step_name failed: " . $result;
-return;
+# by description
+elsif ($description =~ /$verbose_step/) {
+$self->options->set(verbose => 2);
 }
+}
 
-my $result = $step->result || 'done';
+# XXX cc_build uses this verbose setting, why?
+$self->data->set(verbose => $verbose) if $n > 2;
 
-print "..." if $verbose && $verbose == 2;
-print "." x (71 - length($description) - length($result));
-print "$result." unless $step =~ m{^inter/} && $ask;
+print "\n", $description, '...';
+print "\n" if $verbose && $verbose 

Re: Another quick one: .as

[Larry Wall]

On Wed, Jul 12, 2006 at 12:51:57PM -0400, Aaron Sherman wrote:
: I would assume that all classes automatically define:
: 
:  multi submethod *infix: ($self: $?CLASS) { $self }

Hmm, "as" is really only intended for explicit type mutation (which
can work either by role mixin or by new object construction).  It's
not intended to give Perl a different "view" of an unmutated object.

: so that derived classes can automatically:
: 
:  $obj.as

Nit: that's illegal syntax.  Or rather, it's legal, but you're saying

$obj.as.{'ancestor'}

which is an attempt to do a hash subscript on whatever .as returns.
Only () and : cause arguments to be passed to .as.  So you have to
write one of

$obj.as(Foo)# or .(Foo), \.(Foo), etc.
$obj.as: Foo

(Note that those work because Foo is predeclared, presumably.)

: Without actually changing their implementation details (only the type
: that Perl currently thinks it's dealing with polymorphically).

Perl doesn't keep track of that in general except by marking a container
at compile time with the expected type.  But an object is always just
itself, unless you go through some kind of proxy or container.

: In fact, I would expect that this bit of behind-the-curtain magic is how
: the MCP arranges for polymorphism when you:
: 
:  sub foo(Object $x) {...}
:  my A $y;
:  foo($y);

If you ask for the type of $x within foo(), it will tell you A, not Object.
(The type of variable($x) is Object, however.)

The behind-the-curtain polymorphic magic you're thinking of is really
handled within the various dispatchers, which call various methods
as if they were subroutines rather than methods.  That's how the
"lying" happens, generally.

Larry

Re: ===, =:=, ~~, eq and == revisited (blame ajs!)

[Aaron Sherman]

Yuval Kogman wrote:

On Wed, Jul 12, 2006 at 17:58:03 -0400, Aaron Sherman wrote:

  

Then ~~ is wrong in that respect, and I think we should be talking about
that, not about making === into "~~, but without invoking code when it
shouldn't."



But it should! It's the smart match! If the rhs matches the code ref
(the code ref gets it as an argument it's a match!

That's why ~~ isn't a comparison operator, but a smart match
operator - it DWIMs *very* deeply


DWIM generally means "don't shoot me in the head for trying this", and 
it can be strongly argued that C is almost certain to shoot 
you in the head a couple of times in your P6 career if we don't fix it.


Now, I'm all for every single case that Larry put in the table for Smart 
Matching in S03... EXCEPT FOR RUNTIME DISPATCH! There are only two cases 
of runtime dispatch in there that you could possibly invoke: Array/Array 
and Any/Any. Fix those two, and I think ~~ DWIMs safely and just as 
powerfully (perhaps much more so).


My suggestion (falling back to a much simpler and less dynamic =~= for 
runtime dispatch) is one way to fix them, and I think that if we DO fix 
them in that manner, then no one's expectations will be violated (unless 
you expected C<@a1 ~~ @a2> to be shorthand for a function vector, 
dot-product-like, parallel dispatch, in which case I'm going to make the 
suggestion that you quietly retire from public life and find a nice 
place in the mountains. ;-)


Really, all of the magic on ~~ isn't intended for such runtime traversal 
of containers. it's intended for the immediate semantic value of the 
compile-time typed match, most notably in the case of given which has 
more connotations to hang semantic meaning off of in English. To invoke 
those special rules when recursively evaluating the "sameness" of 
containers doesn't even make sense if you stop and consider why you 
would do such a comparison. Why is C<$a ~~ $b> going to invoke code when 
I know nothing about $a and $b at compile time? Is that useful other 
than in defining an alias for ~~?

"_group" in library name (was Re: r13272 - in trunk: compilers/imcc docs/imcc src)

[Chip Salzenberg]

On Wed, Jul 12, 2006 at 05:29:08PM -0700, [EMAIL PROTECTED] wrote:
> * Apply heuristics that tells
> .loadlib 'perl6_group'  # HLL dynamic PMCs
>   and
> .loadlib 'dynlexpad'# non-HLL dynamic PMCs
>   apart, by locating the '_group" substring inside the library name. 

Urque, that's really not OK even in the short term.  Could you alter it to
use an adverb:

.loadlib 'perl6_group' :hll

please?

PS: yes, I am planning to standardize on lower case for pir directives
PPS: yes, I am planning to let the upper-case ".HLL" work for a -long- time  :-)
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

[svn:perl6-synopsis] r10156 - doc/trunk/design/syn

[larry]

Author: larry
Date: Wed Jul 12 18:05:24 2006
New Revision: 10156

Modified:
   doc/trunk/design/syn/S02.pod
   doc/trunk/design/syn/S03.pod

Log:
Clarifications from Smylers++ and ajs++.


Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podWed Jul 12 18:05:24 2006
@@ -12,9 +12,9 @@
 
   Maintainer: Larry Wall <[EMAIL PROTECTED]>
   Date: 10 Aug 2004
-  Last Modified: 10 July 2006
+  Last Modified: 12 July 2006
   Number: 2
-  Version: 49
+  Version: 50
 
 This document summarizes Apocalypse 2, which covers small-scale
 lexical items and typological issues.  (These Synopses also contain
@@ -1215,7 +1215,7 @@
 way, but with any radix it's not clear whether the exponentiator should
 be 10 or the radix, and this makes it explicit:
 
-0b1.1e10illegal, could be read as any of:
+0b1.1e10ILLEGAL, could be read as any of:
 
 :2<1.1> * 2 ** 10   1536
 :2<1.1> * 10 ** 10  15,000,000,000
@@ -1747,15 +1747,15 @@
 or a method call in dot form.  (It is also allowed on a label when a
 statement is expected.) So for any undeclared identifier "C":
 
-foo.bar# foo().bar -- illegal postfix, must use foo().bar
+foo.bar# ILLEGAL   -- postfix must use foo().bar
 foo .bar   # foo($_.bar)   -- no postfix starts with whitespace
-foo\ .bar  # foo().bar -- illegal long dot, use foo()\ .bar
-foo++  # foo()++   -- illegal postfix, must use foo()++
+foo\ .bar  # ILLEGAL   -- long dot must use foo()\ .bar
+foo++  # ILLEGAL   -- postfix must use foo()++
 foo 1,2,3  # foo(1,2,3)-- args always expected after listop
 foo + 1# foo(+1)   -- term always expected after listop
 foo;   # foo();-- no postfix, but no args either
 foo:   #   label   -- must be label at statement boundary.
-   -- illegal otherwise
+   -- ILLEGAL otherwise
 foo: bar:  #   two labels in a row, okay
 .foo:  # $_.foo: 1 -- must be "dot" method with : args
 .foo(1)# $_.foo(1) -- must be "dot" method with () args
@@ -1768,13 +1768,13 @@
 foo $bar: 1# $bar.foo(1)   -- indirect object even if 
declared sub
-- $bar considered one token
 foo (bar()):   # bar().foo(1)  -- even if foo declared sub
-foo bar(): # illegal   -- bar() is two tokens.
+foo bar(): # ILLEGAL   -- bar() is two tokens.
 foo .bar:  # foo(.bar:)-- colon chooses .bar to listopify
 foo bar baz: 1 # foo(baz.bar(1)) -- colon controls "bar", not foo.
 foo (bar baz): 1   # bar(baz()).foo(1) -- colon controls "foo"
-$foo $bar  # illegal   -- two terms in a row
-$foo $bar: # illegal   -- use $bar.$foo for indirection
-(foo bar) baz: 1   # illegal   -- use $baz.$(foo bar) for indirection
+$foo $bar  # ILLEGAL   -- two terms in a row
+$foo $bar: # ILLEGAL   -- use $bar.$foo for indirection
+(foo bar) baz: 1   # ILLEGAL   -- use $baz.$(foo bar) for indirection
 
 The indirect object colon only ever dominates a simple term, where
 "simple" includes classes and variables and parenthesized expressions,

Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podWed Jul 12 18:05:24 2006
@@ -12,9 +12,9 @@
 
   Maintainer: Larry Wall <[EMAIL PROTECTED]>
   Date: 8 Mar 2004
-  Last Modified: 10 Jul 2006
+  Last Modified: 12 Jul 2006
   Number: 3
-  Version: 45
+  Version: 46
 
 =head1 Changes to existing operators
 
@@ -249,18 +249,18 @@
 say foo ($bar+1),$baz  say(foo($bar+1, $baz));
 say foo .($bar+1),$baz say(foo($_.($bar+1), $baz));
 
-say foo[$bar+1],$baz   illegal, need foo()[]
-say foo.[$bar+1],$baz  illegal, need foo().[]
+say foo[$bar+1],$baz   ILLEGAL, need foo()[]
+say foo.[$bar+1],$baz  ILLEGAL, need foo().[]
 say foo [$bar+1],$baz  say(foo([$bar+1], $baz));
 say foo .[$bar+1],$baz say(foo($_.[$bar+1], $baz));
 
-say foo{$bar+1},$baz   illegal, need foo(){}
-say foo.{$bar+1},$baz  illegal, need foo().{}
+say foo{$bar+1},$baz   ILLEGAL, need foo(){}
+say foo.{$bar+1},$baz  ILLEGAL, need foo().{}
 say foo {$bar+1},$baz  say(foo({$bar+1}, $baz));
 say foo .{$bar+1},$baz say(foo($_.{$bar+1}, $baz));
 

Re: [TODO] Implement .loadlib pragma in IMCC

[Allison Randal]

chromatic wrote:

On Wednesday 12 July 2006 16:11, Allison Randal wrote:


load_bytecode is good for runtime loading of PASM/PIR/PBC.


Except for the misleading name.


Oh, you mean the fact that much of the time it's not loading bytecode at 
all? It has crossed my mind, but the irritation hasn't been great enough 
to make it worth changing the name of an existing opcode that didn't 
otherwise need changing.


I wonder if there could be a variant that evaluates the code with the 
appropriate compiler, too:


load_{something} 'file', 'compiler_name'
load_{something} 'file',  compiler_pmc


Hmmm... a compile-and-runtime version of that could potentially compile 
the source to bytecode at compile-time, and then load the bytecode at 
runtime.


Not urgent, but there is long-term potential there.

Allison

Re: [svn:parrot] r13270 - trunk/languages/perl6

[Allison Randal]

[EMAIL PROTECTED] wrote:

Modified: trunk/languages/perl6/perl6.pir
==
--- trunk/languages/perl6/perl6.pir (original)
+++ trunk/languages/perl6/perl6.pir Wed Jul 12 17:05:26 2006
@@ -24,9 +24,7 @@
 
 .namespace [ 'Perl6' ]
 
-.sub '__loadlib' :immediate

-$P1 = loadlib 'perl6_group'
-.end
+.loadlib 'perl6_group'
 
 .sub '__onload' :load

 $P1 = loadlib 'perl6_group'


If Leo's comment about .loadlib being compile-and-runtime is already 
implemented, then you should be able to eliminate that runtime call to 
the loadlib opcode too.


Allison

Re: [TODO] Implement .loadlib pragma in IMCC

[chromatic]

On Wednesday 12 July 2006 16:11, Allison Randal wrote:

> load_bytecode is good for runtime loading of PASM/PIR/PBC.

Except for the misleading name.

I wonder if there could be a variant that evaluates the code with the 
appropriate compiler, too:

load_{something} 'file', 'compiler_name'
load_{something} 'file',  compiler_pmc

-- c

Re: [TODO] Implement .loadlib pragma in IMCC

[Allison Randal]

Leopold Toetsch wrote:


This means, we'd have:

  .include "file.pasm/.pir"  ... load macros or constants (no code)

>

  load_bytecode "file.pbc"   ... load a "module"

  $P0 = loadlib "file"   ... load a shared lib (pmc or ops) 
  .loadlib "file"... same during compilation 


The 5 parameters are runtime vs. compile-time, C library vs. 
.pasm/.pir/.pbc, and "inline a file".


The .include directive doesn't actually load a library, it just inlines 
a file. (The reason it respects .HLL directives and such is not because 
it's incredibly smart, but because it's incredibly stupid. If you have 
.namespace directive in the inlined file, it will apply that namespace 
to any code in the original file that follows the .include directive.) I 
like .inline better than .include for this, but I also don't see any 
urgent need to change the name of the directive.


I like .loadlib (for C libraries) as long as it's both compile and run 
time. That's the most common case of all, and so deserves the best 
syntax. And, the loadlib opcode is a clear parallel for the runtime 
variant. For the extremely rare case when you want to load a C library 
at compile-time but not at runtime, you can still use the loadlib opcode 
inside a :immediate sub.


load_bytecode is good for runtime loading of PASM/PIR/PBC. A logical but 
unexplored option is compile-time loading of PASM/PIR/PBC. Some things 
that are currently being done with .include could be better expressed by 
a compile-and-run-time .load_bytecode directive.


Allison

Re: ===, =:=, ~~, eq and == revisited (blame ajs!)

[Yuval Kogman]

On Wed, Jul 12, 2006 at 16:16:13 -0400, Aaron Sherman wrote:

> The other way to think about === would be that it tells you if its LHS
> *could* be constant-folded onto its RHS (if it were constant for long
> enough)

What is the benefit here?

> Because of the word "deep". Deep implies arbitrary work, which isn't
> really what you want in such a low-level operator. However, using these
> operator, one could easily build whatever you like.

The number of times i *sigh*ed at having to reinvent deep operators
in a clunky way in Perl 5 is really not in line with Perlishness and
DWIM.

Also ~~ is deep in exactly the same way.

Perl is also not low level.

I could build it, and I have, but I don't want to.

It can short circuit and be faster when the structure is definitely
not the same (totally different early on) or definitely the same
(refaddr is equal, etc).

Should I go on?

> I'd avoid saying "memory", here. Some implementations of Perl 6 might
> not know what memory looks like (on a sufficiently abstract VM).

"Slot"

-- 
  Yuval Kogman <[EMAIL PROTECTED]>
http://nothingmuch.woobling.org  0xEBD27418



pgpAR436ytaZh.pgp
Description: PGP signature

Re: ===, =:=, ~~, eq and == revisited (blame ajs!)

[Yuval Kogman]

On Wed, Jul 12, 2006 at 17:58:03 -0400, Aaron Sherman wrote:

> Then ~~ is wrong in that respect, and I think we should be talking about
> that, not about making === into "~~, but without invoking code when it
> shouldn't."

But it should! It's the smart match! If the rhs matches the code ref
(the code ref gets it as an argument it's a match!

That's why ~~ isn't a comparison operator, but a smart match
operator - it DWIMs *very* deeply.

-- 
  Yuval Kogman <[EMAIL PROTECTED]>
http://nothingmuch.woobling.org  0xEBD27418



pgpKGobq7eHqB.pgp
Description: PGP signature

Re: ===, =:=, ~~, eq and == revisited (blame ajs!)

[Yuval Kogman]

On Wed, Jul 12, 2006 at 16:16:13 -0400, Aaron Sherman wrote:

> Isn't that ~~?
> 
> Per S03:
> 
> Array   Array arrays are comparablematch if $_ »~~« $x
> 
> ~~ is really the all-purpose, bake-your-bread, clean-your-floors,
> wax-your-cat operator that you're looking for.

Not at all, because:

( [ 1, 2 ], 3 ) ~~ ( { 1 }, { 1 } )

It's matching, not equality.

> which is true. Ain't recursive hyperoperators grand?

It isn't a hyperoperator, it's just recursive ;-)

> > 2. is .id *always* a low level type representation of the object's value? 
> > It's
> > specced that low level typed items have the same ID when they have the same
> > value. What about complex types?
> 
> It cannot be for complex types or even strings... well, at least it
> I not be I we care about performance

That's orthogonal. .id is used for hash keys. If you're keying y
hubble images then they must be unique for some keyspace, and that's
where .id makes a mapping.

> =:= looks in the "symbol table" (caveat dragons) to see if LHS
> refers to the same variable as the RHS. Does this dereference?
> Probably not, but I'm not sure, based on S03.

Then it's a purely lexical opeation, and it doesn't even work for 

my $x := $array[3];

$x =:= $array[3];

but i'll pretend you didn't say that ;-)

-- 
  Yuval Kogman <[EMAIL PROTECTED]>
http://nothingmuch.woobling.org  0xEBD27418



pgpkrsvQqGF99.pgp
Description: PGP signature

Re: ===, =:=, ~~, eq and == revisited (blame ajs!)

[Aaron Sherman]

On Wed, 2006-07-12 at 15:32 -0500, Jonathan Scott Duff wrote:
> On Wed, Jul 12, 2006 at 04:16:13PM -0400, Aaron Sherman wrote:
> > On Wed, 2006-07-12 at 19:25 +0300, Yuval Kogman wrote:
> > > 4. will we have a deep (possibly optimized[1]) equality operator, that
> > > *will* return true for @foo = ( [ 1, 2 ], 3 ); @bar = ( [ 1, 2 ], 3 ); 
> > > op(@foo, @bar)?
> > > Is it going to be easy to make the newbies use that when they mean "it's 
> > > the
> > > same", like they currently expect == and eq to work on "simple" values?
> > 
> > Isn't that ~~?

[...] # hmm, what kind of reduction IS that? ;)

> > ~~ is really the all-purpose, bake-your-bread, clean-your-floors,
> > wax-your-cat operator that you're looking for.
> 
> Granted, ~~ will return true in that case.  I think the main problem
> is Yuval wants a guarantee that it will return true if and only if
> the things on either side have the same deep structure and values.
> 
> Currently, ~~ will also return true for structures where this does
> not hold.  For example:
> 
> @a = ( [ 1, 2] , 3 );
> @b = ( sub { return 1 }, sub { return 1 } );
> @a ~~ @b;   # true

Then ~~ is wrong in that respect, and I think we should be talking about
that, not about making === into "~~, but without invoking code when it
shouldn't."

> Why is that true?  By the rules of hyper-operation, it turns into
> this:
> 
> [1,2] ~~ sub { return 1 }
> 3 ~~ sub { return 1 }
> 
> which is true if these return true values:
> 
> sub { return 1 }->([1,2])
> sub { return 1 }->(3)

OK, so this always bothered me, I just wasn't sure why. Now I know, and
I think I agree with Yuval quite a bit more. ~~ should never imply
running it's data arguments as code *when dispatched at runtime*. It's:

  * likely to cause security problems when I accidentally compare a
safe, internal structure that (probably unknown to me) contains
code against an unsafe, external structure that I got from a
user.
  * potentially a destructive comparison.
  * potentially not hyper-parallelization friendly
  * probably bad in other ways I could think of, given time.

Let me boil that down to a simple assertion: comparison via ~~ which
will have to perform run-time dispatch should never I to have
side-effects (dynamic language, caveat, caveat...)

So, I do agree that we need a new operator, but I disagree about how it
should be used. I'd suggest:

C<=~=>

This is similar to C<~~> for arguments that are simple value types such
as C or C.

For objects which do not have a C<=~=> operation, C<===> is invoked.

By default, the only objects which will define a C<=~=> operation will
be containers, which will look like:

our Bool multi submethod infix:<=~=> ($a: Container $b) {
[&&] $a >>=~=<< $b;
}

which works for Hashes too, since a Pair is a container, so we'll just
recursively hyperoperate through each of the hash's .kv Pairs, comparing
them, though it might have to sort the Pairs by keys in order to assure
it's comparing apples to apples.

That's it. Just three types of behavior, unlike ~~s massive table of
behavior.

Then, in the table for C<~~>:

$_  $xType of Match ImpliedMatching Code
==  = ==
...
Array   Array arrays are comparablematch if $_ »=~=« $x
...
Any Any   run-time dispatchmatch if infix:<=~=>($_, $x)

The first change is to Array/Array, and this is to minimize surprises
when comparing containers. There might be a special case for containers
that have typed buckets, but I'm not even going to touch that right now.
The second change is to Any/Any, and that's purely a matter of putting
the control in the hands of the caller, not whoever constructed the
caller's data. Anything else is a debugging nightmare.

In general, I would expect that no one would use =~= directly (hence the
ugly, name that's longer than ~~), it's just an implementation detail of
run-time dispatch on ~~

Thoughts?

-- 
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback

Re: Easy Str === Str question: what is a reference type

[David Green]

On 7/12/06, Aaron Sherman wrote:

There's a problem here, from my point of view. I'll take it one
assumption at a time:

  * $whatever.as.id ~~ $whateverelse.as.id is true
if and only if $whatever := $whateverelse at some point in the
past, either explicitly, or through some sort of folding.
  * Str is a boxed type, and thus is a "reference type"
  * Thus, Str should be compared by .id and not by value, according
to the above.
So, IMHO, either there's a mistake in S03; Str is a special case WRT
===; or I misunderstand "reference type" (which S03 never defines).


Well, Str is "special" insofar as it surely won't rely on the default 
.id comparison; as I see it, that's something objects get for free, 
because it makes sense in a lot of common situations (e.g. a typical 
Person class would consider each instance to represent a different 
person).



  * Str might be compared by .id, but .id for Str is based on the
contents of its underlying storage... this worries me because it
means that Strs with radically different "meanings" would be ===
because their encoding is different.


Even though S03 doesn't say so, I'm sure that Str's .id will return 
some sort of value that includes not only the contents but anything 
else relevant, like the encoding.


As for array-refs, I don't know why they couldn't (or shouldn't) be 
=== if they contain the same values.  That seems the least surprising 
way to go.



A couple of other questions about S03:
Any reference type may pretend to be a value type by defining a .id 
method which returns a built-in value, i.e. an immutable object or a 
native value, as specified in S06.


Why does it have to be a built-in value (other than for performance)? 
It might be useful to return a "value" of some other type, which 
would in turn be checked for its .id's.  Or does the problem lie in 
not being able to guarantee that we'd ever actually reach real 
built-in values?


Because Perl 6 uses a false .id to signify a non-instantiated 
prototype, all instances should arrange to return a .id that 
boolifies to true.


Does that mean all non-instances are equivalent?  I can see that two 
non-existent Dog's might be considered the same thing, but not a 
non-existent Dog and a non-existent Cat.

Or will $uninstantiated.id return something unique C?


-David

Re: Creating a New Object (was Re: [TODO] Implement .loadlib pragma in IMCC)

[Chip Salzenberg]

On Wed, Jul 12, 2006 at 12:15:07PM -0700, Chip Salzenberg wrote:
> >- If another HLL wants to create a Perl6Str, how does it do it?
> >- If another HLL wants to create a subclass of Perl6Str...?

I just realized that I misinterpreted these questions.  I thought that the
first question was asking how some random HLL can create its own class that
also has the name 'Perl6Str' -- i.e. a name collision question -- and that
the second question was adding on by asking how the new name-collided class
could coexist with (for example, derive from) the original.

I'll be happy to answer the actual questions precisely, but I need to know
more:

Frst: Is this about now or the eventual future?  Do you want the answer for
when the full name of Perl6Str is ['parrot';'Perl6Str'], as I think it is
today, or ['perl6';'Perl6Str'], as it should be eventually?

Second: Does the derived class have to be named ['myhll','Perl6Str'], or can
it have a new basename like ['myhll','MyPerl6Str']?


> AFAIK there is no answer for this at present.
> 
> (1) POSSIBLE KLUDGE
> 
> In the very short term we could introduce a simple hack that would allow
> the user to specify the root namespace for the creation of the new class,
> defaulting to the HLL root:
> 
> .HLL "evillang"
> .sub foo
> $P0 = get_hll_namespace# ['evillang']
> $P1 = newclass ['Perl6Str'], $P0   # Not a Perl 6 string, but an 
> incredible simulation
> ...
> 
> (2) ELEGANT DIRECTION FOR THE FUTURE
> 
> [to be determined]
> 
> Seriously: Allison's busy (as am I) with nailing namespaces to the wall, so
> I wouldn't ask her to decide this.  I do have ... not so much an idea, but
> an approach, which I'll suggest when the time comes:
> 
> At present, newclass creates a class object and a namespace, both of which
> have the same name.  That must change once we stop depending on typed
> namespaces.  Assuming a single namespace object can represent a single class
> in future -- which is good for class manipulation and introspection -- I
> think we'd want to stop having 'newclass' futz with namespaces at all,
> leaving it up to the user to give it a name ...  if any.  Yes, Virginia,
> there are anonymous classes.  :-)
> 
> So it might look like:
> 
> .HLL "evillang"
> .sub foo
> $P0 = newclass
> ...
> set_hll_global ['Perl6Str'], $P0   # Not a Perl 6 string, but an 
> incredible simulation
> ...
> 
> -- 
> Chip Salzenberg <[EMAIL PROTECTED]>
> 

-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [TODO] Implement .loadlib pragma in IMCC

[Allison Randal]

Patrick R. Michaud wrote:


IIUC, the loadlib opcode (and the new .loadlib directive) are used
strictly for dynamic libraries...

.include is currently compile-time only, and only works with .pir/.pasm

...

Yes, the suggestion is an extreme reuse of existing syntax. Something 
that's good to avoid on general design principles.


Allison

Re: [TODO] Implement .loadlib pragma in IMCC

[Allison Randal]

Will Coleda wrote:


I would prefer .include to maintain its current meaning. Not everything 
you .include is a complete PIR program.


I think the most common case at the moment is stitching together .pir 
files generated by PGE/TGE. Which is useful.


Allison

Re: ===, =:=, ~~, eq and == revisited (blame ajs!)

[Jonathan Scott Duff]

On Wed, Jul 12, 2006 at 04:16:13PM -0400, Aaron Sherman wrote:
> On Wed, 2006-07-12 at 19:25 +0300, Yuval Kogman wrote:
> > 4. will we have a deep (possibly optimized[1]) equality operator, that
> > *will* return true for @foo = ( [ 1, 2 ], 3 ); @bar = ( [ 1, 2 ], 3 ); 
> > op(@foo, @bar)?
> > Is it going to be easy to make the newbies use that when they mean "it's the
> > same", like they currently expect == and eq to work on "simple" values?
> 
> Isn't that ~~?
> 
> Per S03:
> 
> Array   Array arrays are comparablematch if $_ »~~« $x
> 
> ~~ is really the all-purpose, bake-your-bread, clean-your-floors,
> wax-your-cat operator that you're looking for.

Granted, ~~ will return true in that case.  I think the main problem
is Yuval wants a guarantee that it will return true if and only if
the things on either side have the same deep structure and values.

Currently, ~~ will also return true for structures where this does
not hold.  For example:

@a = ( [ 1, 2] , 3 );
@b = ( sub { return 1 }, sub { return 1 } );
@a ~~ @b;   # true

Why is that true?  By the rules of hyper-operation, it turns into
this:

[1,2] ~~ sub { return 1 }
3 ~~ sub { return 1 }

which is true if these return true values:

sub { return 1 }->([1,2])
sub { return 1 }->(3)

Which they do.

So, smart-match fails as a "deep equality" operator precisely
because it's so smart.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: ===, =:=, ~~, eq and == revisited (blame ajs!)

[Aaron Sherman]

On Wed, 2006-07-12 at 19:25 +0300, Yuval Kogman wrote:
> Over at #perl6 we had a short discussion on =:=, ===, and ~~, mostly raised by
> ajs's discussion on Str items and ===.

*wave*

> 1. what is .id on references? Is it related to the memory slot, like refaddr()
> in Perl 5?

That's something I'm not sure of, so I'll let it go, other than to say
that that question should probably avoid the word "memory", see below.

4. will we have a deep (possibly optimized[1]) equality operator, that
*will*

Now, let me handle this one out of order, since I think it's really key:

> return true for @foo = ( [ 1, 2 ], 3 ); @bar = ( [ 1, 2 ], 3 ); op(@foo, 
> @bar)?
> Is it going to be easy to make the newbies use that when they mean "it's the
> same", like they currently expect == and eq to work on "simple" values?

Isn't that ~~?

Per S03:

Array   Array arrays are comparablematch if $_ »~~« $x

~~ is really the all-purpose, bake-your-bread, clean-your-floors,
wax-your-cat operator that you're looking for.

It sounds like pugs is wrong here WRT the spec, since:

( [ 1, 2 ], 3 ) ~~ ( [ 1, 2 ], 3 )

is the same as:

[1,2]~~[1,2] && 3 ~~ 3

which is the same as:

(1~~1 && 2~~2) && 3~~3

which is true. Ain't recursive hyperoperators grand? Of course, I'm
assuming that a comparison hyperoperator in boolean context returns the
[&&] reduction of all of the values... that's an interesting assumption,
isn't it? But, it seems to be the assumption made by S03 under Smart
Matching, so I say it's true. ;)

> 2. is .id *always* a low level type representation of the object's value? It's
> specced that low level typed items have the same ID when they have the same
> value. What about complex types?

It cannot be for complex types or even strings... well, at least it
I not be I we care about performance.

That is, if C<$anything.id> needs to read every byte of $anything, then
an anything that happened to be a Buf containing the 3GB in-memory raw
image from the Hubble is going to really make C<.id> unhappy. I would
hope that C<.id> is an efficient enough operation that === should not
look like a performance bottleneck in my code

> 3. Are these descriptions of the operators correct?
> 
>   ~~ matches the left side to a description on the right side

>   =:= makes sure the objects are actually the same single object (if $x 
> =:= $y
>   and you change $x. then $y. was also changed... is
>   this .id on refs?) Is =:= really eq .id? or more like
>   variable($x).id eq variable($y).id?

>   === makes sure that the values are equivalent ( @foo = ( 1, 2, 3 ); 
> @bar = ( 1,
>   2, 3); @foo === @bar currently works like that, but @foo = ( [ 1, 2 ], 
> 3 );
>   @bar = ( [ 1, 2 ], 3 ); @foo === @bar does not (in pugs). This is not 
> useful
>   because we already have this return false with =:=).


Let me counter-propose a slightly different way of saying that:

~~ as above. I think we all agree on this.

=:= looks in the "symbol table" (caveat dragons) to see if LHS
refers to the same variable as the RHS. Does this dereference?
Probably not, but I'm not sure, based on S03.

=== Compares types and .id values. An implementation of this, as
I interpreted S03, and with some assumptions made, and with some
extra bits filling in the cracks where S03 didn't quite specify
an implementation:

  * A .id method may return C, C or C. ===
returns false for two objects which are not the same
type (with the same traits), and thus the comparison
must always be between identical .id return types.
  * As a special case, however, all "undefined" values (not
objects which have the undefined trait, but true undefs
with no other functionality) are === to each other.
  * Objects are always compared according to their
underlying type, not the polymorphic role which they are
serving at the moment.
  * num, Num and all like values return their num
representation as a .id.
  * int, Int and all like values return their int
representation as a .id.
  * Bool, bool and bit all have a bit representation for .id
  * All other code, objects, references, structures, complex
numbers, etc. are compared strictly on the basis of an
arbitrary C which Perl will generate to represent
their storage, and can be overridden by replacing the
default .id method.

The other way to think about === would be that it tells you if its LHS
*could* be constant-folded onto its RHS (if it were constant for long
enough), where =:= tells you if that has already been done. Only ~~ has
some sort of "deep" semantics, and I think the documentation warns users
s

Re: [TODO] Implement .loadlib pragma in IMCC

[Leopold Toetsch]

On Wed, Jul 12, 2006 at 03:51:53PM -0400, Bob Rogers wrote:

> So the type is bound to a number in the .pbc?  Isn't this dangerous for
> types that are not built in?  Couldn't this number mean something
> different if libraries happen to get loaded in a different order?

The declaration order of PMC libs is recorded in the HLL_info
structure. When the .pbc is loaded, PMCs are initialized in that
very same order, so that type numbers *should* match in the .pbc
again.

>   -- Bob Rogers

leo

Re: [TODO] Implement .loadlib pragma in IMCC

[Patrick R. Michaud]

On Wed, Jul 12, 2006 at 03:51:53PM -0400, Bob Rogers wrote:
>From: Leopold Toetsch <[EMAIL PROTECTED]>
>Date: Wed, 12 Jul 2006 21:15:44 +0200
> 
>On Wed, Jul 12, 2006 at 01:27:24PM -0500, Patrick R. Michaud wrote:
>> The perl6 compiler has a custom string type, currently called 
>> "Perl6Str".  What's the canonically correct mechanism for creating 
>> an object of that type?
>> 
>> $P0 = new 'Perl6Str'
>> $P0 = new .Perl6Str
>> $P0 = new [ 'Perl6Str' ]
> 
>2) only works, *if* the lib, which defines that type is already
>   loaded (via :immediate/loadlib or .loadlib), because it's
>   translated to new_p_ic, i.e. the type name is converted to
>   a type number at compile time, which speeds up run time
>   object creation.
> 
> So the type is bound to a number in the .pbc?  Isn't this dangerous for
> types that are not built in?  Couldn't this number mean something
> different if libraries happen to get loaded in a different order?

IIUC, the type is bound to a number in the .pbc only for the second 
form (.Perl6Str).  And yes, it is dangerous for the non-built-in types, 
which is why I think the note in DEPRECATED.pod is likewise dangerous:

=item Class name IDs
... will require a dot in front
  $P0 = new Integer   => $P0 = new .Integer

AFAICT, the only safe form for the non-builtin types is to use
a string, a key, or the separate find_type lookup...which is what
prompted my original question in this thread about which form 
is canonically (and operationally) correct.

Pm

Re: [TODO] Implement .loadlib pragma in IMCC

[Leopold Toetsch]

On Wed, Jul 12, 2006 at 12:18:51PM -0700, Allison Randal wrote:
> Leopold Toetsch wrote:
> > 
> > Well, there was already one very legitimate usage of compile time
> > loadlib, which is now using C<.loadlib> for that:
> 
> We certainly need both compile-time and runtime loading of libraries. 
> So, it's just a question of which syntax to use for which case.
> 
> chromatic suggests .include for "load this library at compile and run 
> time". The .include directive is currently being used to mean "inline 
> the entire source code for this file here". But, I've always thought of 
> that as a hack we put in before we had library loading working. Any 
> thoughts?

C<.include> and C are really very different. It's like #include
and dlopen(3) in the C language. But I can see, what is leading to this
argument: loading arbitrary bytecode within .include, which should better
be done with C.

This means, we'd have:

  .include "file.pasm/.pir"  ... load macros or constants (no code)

  load_bytecode "file.pbc"   ... load a "module"

  $P0 = loadlib "file"   ... load a shared lib (pmc or ops) 
  .loadlib "file"... same during compilation 

> That would leave us the consistency of the loadlib opcode and the 
> .loadlib directive both meaning "load this library at runtime".

Not really.

> Allison

leo

Re: [TODO] Implement .loadlib pragma in IMCC

[Bob Rogers]

   From: Leopold Toetsch <[EMAIL PROTECTED]>
   Date: Wed, 12 Jul 2006 21:15:44 +0200

   On Wed, Jul 12, 2006 at 01:27:24PM -0500, Patrick R. Michaud wrote:
   > The perl6 compiler has a custom string type, currently called 
   > "Perl6Str".  What's the canonically correct mechanism for creating 
   > an object of that type?
   > 
   > $P0 = new 'Perl6Str'
   > $P0 = new .Perl6Str
   > $P0 = new [ 'Perl6Str' ]
   > 
   > At different stages of Parrot development I've seen different 
   > answers to this question, so it'd be helpful to know what's "correct".

   Correct are all three, but . . .

   2) only works, *if* the lib, which defines that type is already
  loaded (via :immediate/loadlib or .loadlib), because it's
  translated to new_p_ic, i.e. the type name is converted to
  a type number at compile time, which speeds up run time
  object creation.

So the type is bound to a number in the .pbc?  Isn't this dangerous for
types that are not built in?  Couldn't this number mean something
different if libraries happen to get loaded in a different order?

-- Bob Rogers
   http://rgrjr.dyndns.org/

Re: Creating a New Object (was Re: [TODO] Implement .loadlib pragma in IMCC)

[Leopold Toetsch]

On Wed, Jul 12, 2006 at 01:55:39PM -0500, Patrick R. Michaud wrote:
> On Wed, Jul 12, 2006 at 11:36:56AM -0700, chromatic wrote:
> > On Wednesday 12 July 2006 11:27, Patrick R. Michaud wrote:
> > >
> > > $P0 = new 'Perl6Str'
> > 
> > I tend to use:
> > 
> > .local int str_type
> > str_type = find_type [ 'Perl6Str' ]
> > 
> > .local pmc p6str
> > p6str= new str_type

That's a rather complicated :-) way of expressing the one-liner above.

> Along similar lines...
> 
>- If another HLL wants to create a Perl6Str, how does it do it?

  loadlib 'perl6'   # or load_bytecode or whatever
  $P0 = new 'Perl6Str'

>- If another HLL wants to create a subclass of Perl6Str...?

  loadlib 'perl6'   # or load_bytecode or whatever
  clas = subclass 'Perl6Str', 'MyStr'

> Pm

leo

[perl #39796] [TODO] Implement .loadlib pragma in IMCC

[via RT]

# New Ticket Created by  Autrijus Tang 
# Please include the string:  [perl #39796]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=39796 >


Allison and Chip expressed their go-ahead with a .loadlib pragma, to  
replace this current use:

 .sub foo :immediate
 $I0 = loadlib "XXX"
 .end

With this:

 .loadlib "XXX"

This might be done as part of vsoni's IMCC refactoring, or as a lexer  
action that loads the
library as soon as this directive is seen.

In any case, this will let dependency checkers have a much easier  
time to figure out what
dynamic libraries a .pir file is loading, without actually have to  
invoke Parrot themselves.

Audrey



PGP.sig
Description: PGP signature

Re: [TODO] Implement .loadlib pragma in IMCC

[Patrick R. Michaud]

On Wed, Jul 12, 2006 at 12:18:51PM -0700, Allison Randal wrote:
> Leopold Toetsch wrote:
> >
> >Well, there was already one very legitimate usage of compile time
> >loadlib, which is now using C<.loadlib> for that:
> 
> We certainly need both compile-time and runtime loading of libraries. 
> So, it's just a question of which syntax to use for which case.
> 
> chromatic suggests .include for "load this library at compile and run 
> time". The .include directive is currently being used to mean "inline 
> the entire source code for this file here". But, I've always thought of 
> that as a hack we put in before we had library loading working. Any 
> thoughts?

I think I'm confused by or totally misunderstanding the proposal.  
I think we have two very different sorts of "library" at play here:  
dynamic libraries (with a .so extension on my system), and libraries
of parrot code (with .pir, .pbc, and .pasm extensions).

IIUC, the loadlib opcode (and the new .loadlib directive) are used
strictly for dynamic libraries -- on my system those are files with .so
extensions.  loadlib and .loadlib aren't used for .pbc files...  
that's the domain of the load_bytecode opcode.  load_bytecode can
be used for loading .pbc/.pir files at runtime, at load-time via :load,
or at compile-time with :immediate.

.include is currently compile-time only, and only works with .pir/.pasm
files (i.e., one cannot "include" a .pbc).  In addition, any 
.included source honors the current .HLL and 
.namespace settings, which isn't true for files (.pir/.pbc) that are 
obtained via load_bytecode opcode.

So, if the proposal is that ".include" means load a .pbc/.pir library 
whenever the including file is compiled or loaded in a manner analogous
to load_bytecode, then I'm still wanting a way to get source files 
that are compile-only and honor any .namespace directives.

But as I said, I think I must be misunderstanding what is being said,
so feel free to re-explain or correct my misunderstanding.

Pm

Re: [TODO] Implement .loadlib pragma in IMCC

[Will Coleda]

On Jul 12, 2006, at 3:18 PM, Allison Randal wrote:


Leopold Toetsch wrote:

Well, there was already one very legitimate usage of compile time
loadlib, which is now using C<.loadlib> for that:


We certainly need both compile-time and runtime loading of  
libraries. So, it's just a question of which syntax to use for  
which case.


chromatic suggests .include for "load this library at compile and  
run time". The .include directive is currently being used to mean  
"inline the entire source code for this file here". But, I've  
always thought of that as a hack we put in before we had library  
loading working. Any thoughts?




I would prefer .include to maintain its current meaning. Not  
everything you .include is a complete PIR program.


That would leave us the consistency of the loadlib opcode and  
the .loadlib directive both meaning "load this library at runtime".




How does this relate to leo's previous statement that .loadlib now  
does both compile & runtime loads?



Allison



--
Will "Coke" Coleda
[EMAIL PROTECTED]

Re: Creating a New Object (was Re: [TODO] Implement .loadlib pragma in IMCC)

[Chip Salzenberg]

On Wed, Jul 12, 2006 at 01:55:39PM -0500, Patrick R. Michaud wrote:
> On Wed, Jul 12, 2006 at 11:36:56AM -0700, chromatic wrote:
> > On Wednesday 12 July 2006 11:27, Patrick R. Michaud wrote:
> > > The perl6 compiler has a custom string type, currently called
> > > "Perl6Str".  What's the canonically correct mechanism for creating
> > > an object of that type?
> > >
> > > $P0 = new 'Perl6Str'
> > > $P0 = new .Perl6Str
> > > $P0 = new [ 'Perl6Str' ]
> > 
> > I tend to use:
> > 
> > .local int str_type
> > str_type = find_type [ 'Perl6Str' ]
> > 
> > .local pmc p6str
> > p6str= new str_type
> 
> Along similar lines...
> 
>- If another HLL wants to create a Perl6Str, how does it do it?
>- If another HLL wants to create a subclass of Perl6Str...?

AFAIK there is no answer for this at present.

(1) POSSIBLE KLUDGE

In the very short term we could introduce a simple hack that would allow
the user to specify the root namespace for the creation of the new class,
defaulting to the HLL root:

.HLL "evillang"
.sub foo
$P0 = get_hll_namespace# ['evillang']
$P1 = newclass ['Perl6Str'], $P0   # Not a Perl 6 string, but an 
incredible simulation
...

(2) ELEGANT DIRECTION FOR THE FUTURE

[to be determined]

Seriously: Allison's busy (as am I) with nailing namespaces to the wall, so
I wouldn't ask her to decide this.  I do have ... not so much an idea, but
an approach, which I'll suggest when the time comes:

At present, newclass creates a class object and a namespace, both of which
have the same name.  That must change once we stop depending on typed
namespaces.  Assuming a single namespace object can represent a single class
in future -- which is good for class manipulation and introspection -- I
think we'd want to stop having 'newclass' futz with namespaces at all,
leaving it up to the user to give it a name ...  if any.  Yes, Virginia,
there are anonymous classes.  :-)

So it might look like:

.HLL "evillang"
.sub foo
$P0 = newclass
...
set_hll_global ['Perl6Str'], $P0   # Not a Perl 6 string, but an 
incredible simulation
...

-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [TODO] Implement .loadlib pragma in IMCC

[Allison Randal]

Leopold Toetsch wrote:


Well, there was already one very legitimate usage of compile time
loadlib, which is now using C<.loadlib> for that:


We certainly need both compile-time and runtime loading of libraries. 
So, it's just a question of which syntax to use for which case.


chromatic suggests .include for "load this library at compile and run 
time". The .include directive is currently being used to mean "inline 
the entire source code for this file here". But, I've always thought of 
that as a hack we put in before we had library loading working. Any 
thoughts?


That would leave us the consistency of the loadlib opcode and the 
.loadlib directive both meaning "load this library at runtime".


Allison

Re: [TODO] Implement .loadlib pragma in IMCC

[Leopold Toetsch]

On Wed, Jul 12, 2006 at 01:27:24PM -0500, Patrick R. Michaud wrote:
> The perl6 compiler has a custom string type, currently called 
> "Perl6Str".  What's the canonically correct mechanism for creating 
> an object of that type?
> 
> $P0 = new 'Perl6Str'
> $P0 = new .Perl6Str
> $P0 = new [ 'Perl6Str' ]
> 
> At different stages of Parrot development I've seen different 
> answers to this question, so it'd be helpful to know what's "correct".

Correct are all three, but:

1) and 3) are totally the same
   (bracketed syntax just containing a single string constant just
yields that string concstant as a result)
   thusly, 3) is containing some syntax overkill :-) 

1) works always, but defers the type lookup to runtime. It's a
   more efficient version of:
   
   $I0 = find_type 'Perl6Str'
   $P0 = new $I0
   
   ..., which takes one more opcode dispatch

2) only works, *if* the lib, which defines that type is already
   loaded (via :immediate/loadlib or .loadlib), because it's
   translated to new_p_ic, i.e. the type name is converted to
   a type number at compile time, which speeds up run time
   object creation.

A remark WRT:

  $P0 = new Integer # bare word 'Integer'

this currently works with a lexer hack (and special code for 'new' IIRC)
but it's deprecated in favour of the much more explicit C<.Integer>, 
which is indicating some macroish replacement.
  
> Pm

leo

Re: CPANDB - was: Module::Dependency 1.84

[Tim Bunce]

On Wed, Jul 12, 2006 at 03:03:14AM +0200, Tels wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Moin Tim,
> 
> On Tuesday 11 July 2006 18:34, Tim Bunce wrote:
> > I needed some code to trawl through a directory tree parsing perl
> > modules and scripts to determine their dependencies.
> >
> > The closest existing CPAN code was Module::Dependency but it fell short
> > of what I needed. The original author (P Kent) has passed over
> > maintenance to me. My latest release is:
> >
> >   file: $CPAN/authors/id/T/TI/TIMB/Module-Dependency-1.84.tar.gz
> >   size: 52161 bytes
> >md5: 90a83b2aee39f5d25060ebdb6cc3105d
> 
> Thats sort of cool, although I havent looked at it yet :-D
> 
> My real-grand-plan was always to have a CPANDB module that does exactly the 
> following:
> 
> maintains a database with:
> 
> * every CPAN author with all details (ID, email, name)
> * every package with all details (author id, version, name etc etc)

> This database could then be used by all the following modules:
> 
>   Module::Dependency
>   Graph::Dependency
>   CPANPLUS
>   CPANTS
>   CPAN
>   Module::Author
> 
> and a few others I forgot. Basically by every module out there that 
> re-invents the wheel over and over again just to be able to query stuff 
> about CPAN modules. (some of them do really horrible stuff like accessing 
> search.cpan.org - I know I wrote one of them :D

A key point about those modules (other than Module::Dependency) is that they
don't work for private modules (the so called "Dark CPAN") nor for scripts.

Module::Dependency handles both (details changed to protect the guilty):

$ pmd_dump.pl adnetwork/www/cron/cv.pl
adnetwork/www/cron/cv.pl depended_upon_by: 
adnetwork/www/cron/cv.pl depends_on: strict File::Basename lib Env wConfig 
vConfig Churl::Log Churl::MyDBI Churl::Util

$ pmd_dump.pl Churl::MyDBI 
Churl::MyDBI depended_upon_by: www/cron/cv.pl www/cron/pub_login.pl
Churl::MyDBI depends_on: Exporter strict warnings Carp DBIx::DWIW 
File::Basename Sys::Syslog vars
Churl::MyDBI filename: clcyt/Churl/lib/Churl/MyDBI.pm


> And up until today it is still not possible to get easily the answer "what 
> modules do I need install for Foo::Bar 1.23 when using Perl 5.8.x".

Or what module may be affected if I upgrade Foo::Bar.

> My idea was to build _only_ the database, and do it right, simple and easy 
> to use and then get everyone else to just use the DB instead of fiddling 
> with their own. (simple by having the database being superior to every 
> other hack thats in existance now :-)
> 
> I even got so far as to do a mockup v0.02 - but then went back to playing 
> Guildwars.
> 
> Is this a project that would be of general interest?

Yes! But widen your horizon, and schema, beyond just CPAN.
I'd be interested in helping out and, if it works out, perhaps migrate
Module::Dependency to use it.

Tim.

Re: Creating a New Object (was Re: [TODO] Implement .loadlib pragma in IMCC)

[Patrick R. Michaud]

On Wed, Jul 12, 2006 at 11:36:56AM -0700, chromatic wrote:
> On Wednesday 12 July 2006 11:27, Patrick R. Michaud wrote:
> > The perl6 compiler has a custom string type, currently called
> > "Perl6Str".  What's the canonically correct mechanism for creating
> > an object of that type?
> >
> > $P0 = new 'Perl6Str'
> > $P0 = new .Perl6Str
> > $P0 = new [ 'Perl6Str' ]
> 
> I tend to use:
> 
>   .local int str_type
>   str_type = find_type [ 'Perl6Str' ]
> 
>   .local pmc p6str
>   p6str= new str_type


Along similar lines...

   - If another HLL wants to create a Perl6Str, how does it do it?
   - If another HLL wants to create a subclass of Perl6Str...?

Pm

Re: [TODO] Implement .loadlib pragma in IMCC

[jerry gay]

On 7/12/06, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:

The perl6 compiler has a custom string type, currently called
"Perl6Str".  What's the canonically correct mechanism for creating
an object of that type?

$P0 = new 'Perl6Str'
$P0 = new .Perl6Str
$P0 = new [ 'Perl6Str' ]

At different stages of Parrot development I've seen different
answers to this question, so it'd be helpful to know what's "correct".

(Also, if the answer is somehow different for Parrot's "built-in"
types, such as Undef or Integer, I'd like to know that.)


according to DEPRECATED.pod (not the best place for notes about
possible changes (predicted deprecation?)):

 =item Class name IDs

 ... will require a dot in front

   $P0 = new Integer   => $P0 = new .Integer

according to P6&PE, 2nd edition, PMC variables section (p.188):

 Unlike PASM, PIR doesn't use a dot in front of the class name.
 P0 = new PerlString # same as new P0, .PerlString

i have no point/counterpoint for the bracketed syntax.
hope that provides some history, context, clarification, or confusion.
~jerry

Creating a New Object (was Re: [TODO] Implement .loadlib pragma in IMCC)

[chromatic]

On Wednesday 12 July 2006 11:27, Patrick R. Michaud wrote:

> The perl6 compiler has a custom string type, currently called
> "Perl6Str".  What's the canonically correct mechanism for creating
> an object of that type?
>
> $P0 = new 'Perl6Str'
> $P0 = new .Perl6Str
> $P0 = new [ 'Perl6Str' ]
>
> At different stages of Parrot development I've seen different
> answers to this question, so it'd be helpful to know what's "correct".

I tend to use:

.local int str_type
str_type = find_type [ 'Perl6Str' ]

.local pmc p6str
p6str= new str_type

-- c

[perl #39801] [PATCH] adding examples\shootout\spectralnorm.pir

[via RT]

# New Ticket Created by  Michal Jurosz 
# Please include the string:  [perl #39801]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=39801 >


Implement spectralnorm shootout benchmark (
http://shootout.alioth.debian.org/sandbox/benchmark.php?test=all&lang=parrot
).

-- 
S pozdravem Michal Jurosz

Index: examples/shootout/spectralnorm.pir
===
--- examples/shootout/spectralnorm.pir  (revision 0)
+++ examples/shootout/spectralnorm.pir  (revision 0)
@@ -0,0 +1,161 @@
+#!./parrot -j
+#
+# spectralnorm.pir N (N = 100 for shootout)
+# by Michal Jurosz
+
+.sub eval_A
+   .param int i
+   .param int j
+
+   # return 1.0/((i+j)*(i+j+1)/2+i+1);
+   $N0 = i + j
+   $N1 = $N0 + 1
+   $N0 *= $N1
+   $N0 /= 2
+   $N0 += i
+   $N0 += 1
+   $N0 = 1 / $N0
+   .return ($N0)
+.end
+
+
+.sub eval_A_times_u
+   .param int N
+   .param pmc u
+   .param pmc Au
+
+   .local int i, j
+
+   i = 0
+beginfor_i:
+   unless i < N goto endfor_i
+   Au[i] = 0
+   j = 0
+   beginfor_j:
+   unless j < N goto endfor_j
+   # Au[i]+=eval_A(i,j)*u[j]
+   $N0 = eval_A(i,j)
+   $N1 = u[j]
+   $N0 *= $N1
+   $N1 = Au[i]
+   $N0 += $N1
+   Au[i] = $N0
+
+   inc j
+   goto beginfor_j
+   endfor_j:
+
+   inc i
+   goto beginfor_i
+endfor_i:
+.end
+
+
+.sub eval_At_times_u
+   .param int N
+   .param pmc u
+   .param pmc Au
+
+   .local int i, j
+
+   i = 0
+beginfor_i:
+   unless i < N goto endfor_i
+   Au[i] = 0
+   j = 0
+   beginfor_j:
+   unless j < N goto endfor_j
+   # Au[i]+=eval_A(j,i)*u[j]
+   $N0 = eval_A(j,i)
+   $N1 = u[j]
+   $N0 *= $N1
+   $N1 = Au[i]
+   $N0 += $N1
+   Au[i] = $N0
+
+   inc j
+   goto beginfor_j
+   endfor_j:
+
+   inc i
+   goto beginfor_i
+endfor_i:
+.end   
+
+
+.sub eval_AtA_times_u
+   .param int N
+   .param pmc u
+   .param pmc AtAu
+
+   .local pmc v
+   v = new .FixedFloatArray
+   v = N
+
+   eval_A_times_u(N,u,v)
+   eval_At_times_u(N,v,AtAu)
+.end
+
+
+.sub main :main
+   .param pmc argv
+   $S0 = argv[1]
+   .local int N
+   N = $S0
+
+   .local pmc u, v
+   u = new .FixedFloatArray
+   u = N
+   v = new .FixedFloatArray
+   v = N
+
+   .local int i
+
+   i = 0
+beginfor_init:
+   unless i < N goto endfor_init
+   u[i] = 1
+   inc i
+   goto beginfor_init
+endfor_init:
+
+
+   i = 0
+beginfor_eval:
+   unless i < 10 goto endfor_eval
+   eval_AtA_times_u(N,u,v)
+   eval_AtA_times_u(N,v,u)
+   inc i
+   goto beginfor_eval
+endfor_eval:
+
+   .local float vBv, vv
+   vBv = 0.0
+   vv = 0.0
+
+   i = 0
+beginfor_calc:
+   unless i < N goto endfor_calc
+   # vBv+=u[i]*v[i]; vv+=v[i]*v[i];
+   $N0 = u[i]
+   $N1 = v[i]
+   $N0 *= $N1
+   vBv += $N0
+   $N0 = $N1
+   $N0 *= $N0
+   vv += $N0
+   inc i
+   goto beginfor_calc
+endfor_calc:
+   
+   # print "%0.9f" % (sqrt(vBv/vv))
+   $N0 = vBv / vv
+   $N0 = sqrt $N0
+   .local pmc spf
+   spf = new .FixedFloatArray
+   spf = 1
+   spf[0] = $N0
+   $S0 = sprintf "%.9f\n", spf
+   print $S0
+   exit 0
+.end

Re: [TODO] Implement .loadlib pragma in IMCC

[Leopold Toetsch]

On Wed, Jul 12, 2006 at 10:25:43AM -0700, Allison Randal wrote:
> It occurs to me, after thinking about it overnight, that the .loadlib 
> directive shouldn't operate at :immediate time, but at :init time, 
> because it's more common to want a library to load when you run the code 
> than to load only when you compile the code.

Well, there was already one very legitimate usage of compile time
loadlib, which is now using C<.loadlib> for that:

  .loadlib "opcode_lib"

The library is needed immediately in the compiler to be able to
proceed parsing (e.g. to check the amount and types of freshly loaded
opcodes). There was a crude hack that accomplished this, which is now
removed, because it's cleanly covered by C<.loadlib>.

See also t/dynoplibs/*.t

Another usage of compile time C<.loadlib> could be:

  .loadlib "my_pmcs"
  ...
 $P0 = new .MyInt

I.e. some custom PMC loading, w/o defining a HLL language.

There might be other cases, where :init time is early enough, though.

> Allison

leo

Re: [TODO] Implement .loadlib pragma in IMCC

[Patrick R. Michaud]

On Wed, Jul 12, 2006 at 10:25:43AM -0700, Allison Randal wrote:
> It occurs to me, after thinking about it overnight, that the .loadlib 
> directive shouldn't operate at :immediate time, but at :init time, 
> because it's more common to want a library to load when you run the code 
> than to load only when you compile the code.

This might not seem totally related (but it is somewhat related)...

The perl6 compiler has a custom string type, currently called 
"Perl6Str".  What's the canonically correct mechanism for creating 
an object of that type?

$P0 = new 'Perl6Str'
$P0 = new .Perl6Str
$P0 = new [ 'Perl6Str' ]

At different stages of Parrot development I've seen different 
answers to this question, so it'd be helpful to know what's "correct".

(Also, if the answer is somehow different for Parrot's "built-in" 
types, such as Undef or Integer, I'd like to know that.)

Pm

[perl #39799] [PATCH] pmclass brace indentation

[via RT]

# New Ticket Created by  willie 
# Please include the string:  [perl #39799]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=39799 >


fixes the indentation of the pmclass's closing brace and the last 
method's closing brace in src/pmc/array.pmc. no other pmc file in the 
same directory needs a similar adjustment.
Index: src/pmc/array.pmc
===
--- src/pmc/array.pmc   (revision 13260)
+++ src/pmc/array.pmc   (working copy)
@@ -1263,8 +1263,8 @@
 SUPER(info);
 if (info->extra_flags == EXTRA_IS_NULL)
 DYNSELF.set_integer_native(io->vtable->shift_integer(INTERP, io));
-}
 }
+}

 /*

Re: [svn:perl6-synopsis] r10077 - doc/trunk/design/syn

[Larry Wall]

On Wed, Jul 12, 2006 at 08:40:53AM -0400, Aaron Sherman wrote:
: Smylers wrote:
: >[EMAIL PROTECTED] commits:
: >
: >  
: >>New Revision: 10077
: >>Modified: doc/trunk/design/syn/S02.pod
: 
>>==
: >> 
: >>-foo.bar# foo().bar -- postfix prevents args
: >>+foo.bar# foo().bar -- illegal postfix, must use 
: >>foo().bar
: >> foo .bar   # foo($_.bar)   -- no postfix starts with 
: >> whitespace
: >>
: >
: >I don't think it makes much sense to start the comments with an
: >alternate form for the expressions now denoted as illegal -- "here's
: >some other syntax which this used to be the same as but it no longer is"
: >probably only confuses the casual reader.
: >  
: 
: On a side note, does that apply only to expressions that start with an 
: identifier, or does that mean that:
: 
:$socket.accept.getlines
: 
: will have to be:
: 
:$socket.accept().getlines
: 
: ?

No, this is only list operators, not methods.  So

$socket.accept.getlines

is fine, but

foo.accept.getlines

is not, unless foo is predeclared 0-ary.

But I am tempted to extend it to keywords like "else" and "sub" as
well, because any foo{} confusion is going to train people not to
think about ...{} as a subscript when they should think about it
whenever there's a lack of whitespace.  It would be nice if :foo{}
were the only exception to that.

For similar reasons, I'm also tempted to say that if() is always a
function call, because it looks like one.

Larry

Re: TAP diagnostic syntax proposal

[Fergal Daly]

If only we had some kind of standard language for marking things up
that was extensible... and wasn't met with universal disapproval,


F

On 12/07/06, Jonathan Rockway <[EMAIL PROTECTED]> wrote:


> Did you guys consider the problem of newlines in content?
>

This is a good question.  Implementing your own file format means you
have a big-bag-o-quoting problems.  How do you print a verbatim
newline?  What about a verbatim single quote?  What about Unicode?  What
about a new line then "not ok - ++$counter"? :)

http://cr.yp.to/qmail/guarantee.html says:
>
> When another programmer wants to talk to a user interface, he has to
> /quote/: convert his structured data into an unstructured sequence of
> commands that the parser will, he hopes, convert back into the
> original structured data.
>
> This situation is a recipe for disaster. The parser often has bugs: it
> fails to handle some inputs according to the documented interface. The
> quoter often has bugs: it produces outputs that do not have the right
> meaning. Only on rare joyous occasions does it happen that the parser
> and the quoter both misinterpret the interface in the same way.
>

Things to think about :)

Regards,
Jonathan Rockway

Re: [TODO] Implement .loadlib pragma in IMCC

[Allison Randal]

It occurs to me, after thinking about it overnight, that the .loadlib 
directive shouldn't operate at :immediate time, but at :init time, 
because it's more common to want a library to load when you run the code 
than to load only when you compile the code.


Which leaves us with :immediate for the rare cases when you really want 
to load a library at compile time.


Allison

Re: CPANDB - was: Module::Dependency 1.84

[Tels]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Moin,

On Wednesday 12 July 2006 03:13, David Golden wrote:
> Tels wrote:
> > My idea was to build _only_ the database, and do it right, simple and
> > easy to use and then get everyone else to just use the DB instead of
> > fiddling with their own. (simple by having the database being superior
> > to every other hack thats in existance now :-)
> >
> > I even got so far as to do a mockup v0.02 - but then went back to
> > playing Guildwars.
> >
> > Is this a project that would be of general interest?
>
> At YAPC::NA, Adam Kennedy mention that he wanted to try to make some
> headway on CPAN::Index, which sounds very similar in intent.  While it's
> not released, you can see the formative project at his public repository:
>
> http://tinyurl.com/g888h
>
> Perhaps you can join forces with him and help push some collective
> project towards a release.

Quoted:

>B provides object-oriented access to the CPAN index,
>using a collection of relatively common modules, and automates
>entire process of fetching and accessing the index.

Uhm, no the DB should maybe be able to have a front-end that fills it from 
the CPAN index, but you should also be able to build a DB from a local 
file, if you so wish.

>The index is stored in a L database file, with an object
>model implemented around it using L. To update the index,
>the L class implements the logic to flush and reset
>the database, fetch the index files, parse them, and repopulate the
>database.

The DB backend shouldn't matter at all, it should be transparent and be 
switchable without any noticable change at the front. Plus, I planned to 
use YAML because it creates a _much_ less heavy overhead and dependency 
chain. Using SQLite or similiar is what really creates the problems with 
CPANTS - you cant just access the raw database without the front-end. 
WithYAML, at least you could get at the data by other means. Of course for 
performance reasons it might not be good, but since premature optimization 
is the root of all evil, I'd say use YAML now, change when nec.

Otherwise, the projects seem similiar in scope, except that I focus on the 
DB and let things like "download stuff" be done outside.

Whether that works out, uh I don't know. In any event I have quite a few 
ideas I'd like to try out and this proves to be fun to me. I hope it 
doesn't end upI have to implement other people ideas - thats too much work 
like :D

Best wishes,

Tels

- -- 
 Signed on Wed Jul 12 18:54:01 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "When it's done in 2001." - 2000 Christmas card about Duke Nukem Forever
 (http://tinyurl.com/6m8nh)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBRLUqL3cLPEOTuEwVAQK3DAf/VEIV3fCdHTMinHZqL9N3JTxAHBIVZSlw
4grWxod0u3/8DiAhHkSjNu4y0XjE2WV1LrI6JWFD+4/qoElUhvMFydLYXP8cG31X
CnXGuAFvq6TVKXCQbHWWucSlcHrILc648i5sCkmi+OTJYUP1AP0/IWdyEbgevWp3
7daHed1UvCetKYyWwTNwgxerTwHAyziFd8kCR2pWzsXUve3zcHhEudm+KF6q6mOI
K069eG99V0R5Ix5nisYAdJdei1+TQ8SSXmNZ30VKju8YFTRKcWQNMmWcdxqErydB
19E5C8HDpXAiafUizpmvG8/tChioFjOS+bbsV/AInid6BcQDBDXONg==
=2qra
-END PGP SIGNATURE-

Re: ===, =:=, ~~, eq and == revisited (blame ajs!)

[Yuval Kogman]

Jedai and I went through some of pugs current implementations. Here's a list of
what we expect the operators to return and what they currently do.

This does not exactly agree with S03 right now, but is our opinion.

Force into a type before comparing values:

42 == 42 - true, same numeric value

"42" == 42 - true, same numeric value

"42" == "42" - true, same numeric value

" 42 " == "42.0" - true, same numeric value

" 42 " eq "42.0" - false, different string value

4 eq "4" - true, same string value

Well typed value comparison:

42 === 42 - true, the same type

"42" === 42 - false, not the same type

"42" === "42" - true, the same type

" 42 " === "42.0" - false, different value in "natural" type (string 
values)

(1, 2, 3) === (1, 2, 3) - true, same value

([1, 2 ], 3 ) === ([1, 2 ], 3) - true, same value - BROKEN (actually 
false,
since refs are not the same). S03 thinks this is actually OK.

[1, 2, 3] === [1, 2, 3] - true, same value, (S03 says that this is 
actually
broken, because references should not be the same (we disagree))

my @foo = (1, 2, 3); my @bar = @foo; @foo === @bar - true, same value.

my @foo = ([1, 2], 3); my @bar = @foo; @bar === @foo - true, same value 
-
BROKEN (S03 actually agrees with us here, since the ref is the same in 
this
case)

Slot/container equality (this is actually up to debate, but this is what we
would expect if it was refaddr($x) == refaddr($y)):

[ 1, 2, 3 ] =:= [ 1, 2, 3 ] - false, different containers - BROKEN
(actually true)

my $foo = [ 1, 2, 3 ]; $foo =:= $foo - true, same container

my $foo = [ 1, 2, 3 ]; my $bar := $foo; $bar =:= $foo - true, same 
container

my $foo = [ 1, 2, 3 ]; my $bar = $foo; $bar =:= $foo - true, ref to same
container, or false since different container, unsure - currently true

my @foo = (1, 2, 3); my @bar = @foo; @foo =:= @bar - false, container
should be different - BROKEN (actually true)

my @foo = (1, 2, 3); my @bar = @foo; @bar[1] = "moose"; @foo =:= @bar -
false, container should be different. This actually works like we 
expected,
appearantly pugs does some sort of COW

Under := slot semantics the first test should be false, the second should be
true, the third should be true, the fourth should be false, the fifth should be
false, and the sixth should be false.


-- 
  Yuval Kogman <[EMAIL PROTECTED]>
http://nothingmuch.woobling.org  0xEBD27418



pgpGSy7OFZEBd.pgp
Description: PGP signature

Another quick one: .as

[Aaron Sherman]

I would assume that all classes automatically define:

 multi submethod *infix: ($self: $?CLASS) { $self }

so that derived classes can automatically:

 $obj.as

Without actually changing their implementation details (only the type
that Perl currently thinks it's dealing with polymorphically).

In fact, I would expect that this bit of behind-the-curtain magic is how
the MCP arranges for polymorphism when you:

 sub foo(Object $x) {...}
 my A $y;
 foo($y);

Is all of that fair?

-- 
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback

Re: TAP diagnostic syntax proposal

[A. Pagaltzis]

* Jonathan Rockway <[EMAIL PROTECTED]> [2006-07-12 17:50]:
> Things to think about :)

This is the time in our program where we stop to consider what it
means that DJB, who wrote that advice/rant, also wrote an RFC2822
parser.

Regards,
-- 
Aristotle Pagaltzis // 

Re: ===, =:=, ~~, eq and == revisited (blame ajs!)

[Yuval Kogman]

If we do have deep value equality checks, then "default" == and eq
are probably:

sub &infix:<==> ( $x, $y ) {
+$x === +$y;
}

sub &infix: ( $x, $y ) {
~$x === ~$y;
}

So that the compare-as-sometype behavior is retained from perl 5
without introducing new complexity to the objects being compared as
strings/numbers.

-- 
  Yuval Kogman <[EMAIL PROTECTED]>
http://nothingmuch.woobling.org  0xEBD27418



pgpNhYctTCtP5.pgp
Description: PGP signature

Re: fetching module version from the command line

[David Wheeler]

On Jul 12, 2006, at 03:41, Gabor Szabo wrote:


perl -MModule -e'print $Module::VERSION'


I have this alias set up:

  function pv () { perl -M$1 -le "print $1->VERSION"; }

I think that calling ->VERSION is more correct.

Best,

David

===, =:=, ~~, eq and == revisited (blame ajs!)

[Yuval Kogman]

Over at #perl6 we had a short discussion on =:=, ===, and ~~, mostly raised by
ajs's discussion on Str items and ===.

After a brief discussion we managed to formulate several questions that we feel
are slightly to totally unresolved.

1. what is .id on references? Is it related to the memory slot, like refaddr()
in Perl 5?

2. is .id *always* a low level type representation of the object's value? It's
specced that low level typed items have the same ID when they have the same
value. What about complex types?

3. Are these descriptions of the operators correct?

~~ matches the left side to a description on the right side

=:= makes sure the objects are actually the same single object (if $x 
=:= $y
and you change $x. then $y. was also changed... is
this .id on refs?) Is =:= really eq .id? or more like
variable($x).id eq variable($y).id?

=== makes sure that the values are equivalent ( @foo = ( 1, 2, 3 ); 
@bar = ( 1,
2, 3); @foo === @bar currently works like that, but @foo = ( [ 1, 2 ], 
3 );
@bar = ( [ 1, 2 ], 3 ); @foo === @bar does not (in pugs). This is not 
useful
because we already have this return false with =:=).

If they are not correct, why is there an overlap between =:=? Why is it hard to
deeply compare values in 2006 without using e.g. Data::Compare?

4. will we have a deep (possibly optimized[1]) equality operator, that *will*
return true for @foo = ( [ 1, 2 ], 3 ); @bar = ( [ 1, 2 ], 3 ); op(@foo, @bar)?
Is it going to be easy to make the newbies use that when they mean "it's the
same", like they currently expect == and eq to work on "simple" values?

5. is there room for a new opperator?

=::= makes sure the memory slot  is the same (might be different
for simple values). refaddr($x) == refaddr($y) in Perl 5

=:= makes sure that .ids are the same, and is useful if the .id
method is meaningful for an object. A bit like Test::More::is(
$x, $y ) but without the diagnosis in Perl 5, or abusing eq if
the object doesn't overload stringification.

=== makes sure the values are the same even if they are
copies/clones/whatever. Data::Compare in Perl 5. A bit like what
people overload == for in Perl 5 right now (which confuses
"numerical" equality with "true" equality, so we want to phase
that out).

~~ makes sure the value on the right side describes the value on
the left side. Reminiscient of Test::Deep::cmp_deeply, with all
the various matching magic.

Thanks,

[1] It could, of course, be just =:= && === inside, and it could optimize
arrays to check length first, and it could cache checksums and it could do
whatever - please don't bring this up as a performance issue, it is one of
correctness and ergonomics that must be resolved first.

-- 
  Yuval Kogman <[EMAIL PROTECTED]>
http://nothingmuch.woobling.org  0xEBD27418



pgpVx2Q88D1JG.pgp
Description: PGP signature

Easy Str === Str question: what is a reference type

[Aaron Sherman]

S03 says:

Binary === tests type and value correspondence: for two value
types, tests whether they are the same value (eg. 1 === 1); for
two reference types, checks whether they have the same identity
value. For reference types that do not define an identity, the
reference itself is used (eg. it is not true that [1,2] ===
[1,2], but it is true that @a === @a).

There's a problem here, from my point of view. I'll take it one
assumption at a time:

  * $whatever.as.id ~~ $whateverelse.as.id is true
if and only if $whatever := $whateverelse at some point in the
past, either explicitly, or through some sort of folding.
  * Str is a boxed type, and thus is a "reference type"
  * Thus, Str should be compared by .id and not by value, according
to the above.

So, IMHO, either there's a mistake in S03; Str is a special case WRT
===; or I misunderstand "reference type" (which S03 never defines).

Clarification please?

Two things were mentioned on IRC about this:

  * Str might be compared by .id, but .id for Str is based on the
contents of its underlying storage... this worries me because it
means that Strs with radically different "meanings" would be ===
because their encoding is different.
  * A reference type might only mean containers (though S03 seems to
imply that objects are included to me).

Thanks, and sorry for all the lame questions! I'm just trying to make
sure that the docs I write aren't utterly, worthlessly wrong. :-/

-- 
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback

Re: TAP diagnostic syntax proposal

[Jonathan Rockway]

Did you guys consider the problem of newlines in content?
  


This is a good question.  Implementing your own file format means you 
have a big-bag-o-quoting problems.  How do you print a verbatim 
newline?  What about a verbatim single quote?  What about Unicode?  What 
about a new line then "not ok - ++$counter"? :)


http://cr.yp.to/qmail/guarantee.html says:


When another programmer wants to talk to a user interface, he has to 
/quote/: convert his structured data into an unstructured sequence of 
commands that the parser will, he hopes, convert back into the 
original structured data.


This situation is a recipe for disaster. The parser often has bugs: it 
fails to handle some inputs according to the documented interface. The 
quoter often has bugs: it produces outputs that do not have the right 
meaning. Only on rare joyous occasions does it happen that the parser 
and the quoter both misinterpret the interface in the same way.




Things to think about :)

Regards,
Jonathan Rockway

Re: [TODO] Implement .loadlib pragma in IMCC

[Leopold Toetsch]

On Wed, Jul 12, 2006 at 12:14:21AM -0400, Audrey Tang wrote:
> Allison and Chip expressed their go-ahead with a .loadlib pragma, to  
> replace this current use:
> 
> .sub foo :immediate
>  $I0 = loadlib "XXX"
> .end
> 
> With this:
> 
> .loadlib "XXX"

Done, r13262.

Actually loading libs matching /ops/ *was* already performed at
compile time. This hack is now removed too.

Thanks for the proposal,
leo

Re: Ruby on Parrot

[Patrick R. Michaud]

On Tue, Jul 11, 2006 at 02:41:19PM -0600, Kevin Tew wrote:
> It parses my simple puts.rb example, but parse time is really slow..  2 
> minutes.
> I'm sure I've made some dumb grammar mistakes that is slowing it down.

Well, the first thing to note is that subrule calls can be comparatively
slow, so I think you might get a huge improvement by eliminating
the  subrule from 

token ws {[|<[\t]>]*}

resulting in

token ws { <[ \t]>* }

(Also,  is a capturing subrule, so that means a separate Match 
object is being created and stored for every space encountered
in the source program.  In such cases  might be better.)

Along a similar vein, I think that a rule such as

rule statement {

  |  [|]
  | 
  | [ | | |] 
  |  
  | \{  \}
  | \{  \}
  |
  |
}

may be quite a bit slower than the more direct

rule statement {
  alias  
  |alias  [|]
  |undef 
  | [if|unless|while|until] 
  | rescue 
  |begin \{  \}
  |end \{  \}
  |
  |
}

but I haven't tested this at all to know if the difference
in speed is significant.  I do know that the regex engine will
have more optimization possibilities with the second form than
with the first.  (If one stylistically prefers the keyword tokens 
not appear as "barewords" in the rule, then <'alias'>, <'undef'>,
etc. work equally well for constant literals.)

It's also probably worthwhile to avoid backtracking and re-parsing 
complex subrules such as  above.  In the above, a plain
 w/o if/unless/while/until/rescue ends up being parsed
three separate times before the rule succeeds.  Better might be:

rule statement {
  |alias  
  |alias  [|]
  |undef 
  |begin \{  \}
  |end \{  \}
  | [ [if|unless|while|until] 
| rescue  
]?
  |
}

(In fact, looking at the grammar I'm not sure that 
is really needed, since  already covers that.  But I'm
not a Ruby expert.)

Anyway, let me know if any of the above suggestions make sense
or provide any form of improvement in parsing speed.

Thanks!

Pm

> Patrick R. Michaud wrote:
> >On Fri, Jul 07, 2006 at 10:07:57AM -0600, Kevin Tew wrote:
> >  
> >>I based the initial PGE grammar for PRuby off of  
> >>svn://rubyforge.org/var/svn/rubygrammar/grammars/antlr-v3/trunk/ruby.g 
> >>which is in complete.
> >>I'm looking for a BNF style description of the Ruby grammar.  Otherwise 
> >>I will have to dig into :pserver:[EMAIL PROTECTED]:/src/parse.y.
> >>
> >
> >I'll be glad to provide any help that I can in building a PGE
> >version of the grammar -- just let me know where I can help.
> >
> >Pm
> >  

Re: TAP diagnostic syntax proposal

[Ian Langworth]

On 7/11/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:


Fair enough a "Layer 1" TAP parser might not care, but why not make it
as equally easy to implement a "Layer 2" parser as well.


Bingo.

--
Ian Langworth

[perl #39802] [PATCH] [CAGE] turning up the warnings levels in gcc as much as we can

[via RT]

# New Ticket Created by  Kevin Tew 
# Please include the string:  [perl #39802]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=39802 >


turning up the warnings levels in gcc as much as we can

=item C<--cage>

[CAGE] compile includes many additional warnings


 Configure.pl   |5 +++
 config/auto/gcc.pm |   87 
+
 2 files changed, 87 insertions(+), 5 deletions(-)

Kevin
Index: Configure.pl
===
--- Configure.pl(revision 13258)
+++ Configure.pl(working copy)
@@ -52,6 +52,10 @@
 
 Sets the location where parrot will be installed.
 
+=item C<--cage>
+
+[CAGE] compile includes many additional warnings
+
 =item C<--ask>
 
 This turns on the user prompts.
@@ -284,6 +288,7 @@
--verbose-step=regex Set verbose for step matching description
--nomanicheckDon't check the MANIFEST
--prefix Set the installation prefix
+   --cage   [CAGE] compile includes many additional warnings
 
--askHave Configure ask for commonly-changed info
 
Index: config/auto/gcc.pm
===
--- config/auto/gcc.pm  (revision 13258)
+++ config/auto/gcc.pm  (working copy)
@@ -127,18 +127,95 @@
 # us -Wpadded may prove interesting, or even noisy.
 # -Wunreachable-code might be useful in a non debugging version
 );
+my @cage_opt_and_vers = (
+0 =>
+" -std=c89 -Wall -Wextra -Wundef -Wbad-function-cast 
-Wmissing-declarations -Wredundant-decls -Wnested-externs -Wlong-long"
+. " -Wfloat-equal -Wpadded -Wunreachable-code"
+
+#. "-fsyntax-only "
+#. "-pedantic -pedantic-errors "
+#. " -w "
+#. " -Werror "
+. " -Wextra -Wall -Waggregate-return -Wcast-align  -Wcast-qual  
-Wchar-subscripts "
+. " -Wcomment -Wconversion  -Wno-deprecated-declarations 
-Wdisabled-optimization  -Wno-div-by-zero  -Wno-endif-labels "
+. " -Werror-implicit-function-declaration -Wfatal-errors  
-Wfloat-equal -Wformat  -Wformat=2 -Wno-format-extra-args -Wformat-nonliteral "
+. " -Wformat-security  -Wformat-y2k -Wimplicit  
-Wimplicit-function-declaration  -Wimplicit-int -Wimport  -Wno-import  
-Winit-self "
+. " -Winline -Winvalid-pch -Wlarger-than-4096 -Wlong-long -Wmain  
-Wmissing-braces  -Wmissing-field-initializers "
+. " -Wmissing-format-attribute  -Wmissing-include-dirs 
-Wmissing-noreturn -Wno-multichar  -Wnonnull  -Wpacked "
+. " -Wpadded -Wparentheses  -Wpointer-arith  -Wredundant-decls 
-Wreturn-type  -Wsequence-point  -Wshadow -Wsign-compare "
+. " -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch  
-Wswitch-default -Wswitch-enum -Wsystem-headers  -Wtrigraphs  -Wundef "
+
+#. " -Wuninitialized "
+# requires -O
+. " -Wunknown-pragmas  -Wunreachable-code -Wunused  
-Wunused-function  -Wunused-label  -Wunused-parameter -Wunused-value "
+. " -Wunused-variable  -Wwrite-strings -Wvariadic-macros "
+#."-Wmost (APPLE ONLY)" 
+
+#C-only Warning Options
+. " -Wbad-function-cast  -Wmissing-declarations 
-Wmissing-prototypes -Wnested-externs  -Wold-style-definition 
-Wstrict-prototypes "
+#. " -Wtraditional "
+. " -Wdeclaration-after-statement -Wno-discard-qual 
-Wno-pointer-sign ",
+
+#"-Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wshadow 
-Wpointer-arith -Wcast-qual -Wwrite-strings -Waggregate-return -Winline -W 
-Wno-unused",
+# others; ones we might like marked with ?
+# ? -Wundef for undefined idenfiers in #if
+# ? -Wbad-function-cast
+#   Warn whenever a function call is cast to a non-matching type
+# ? -Wmissing-declarations
+#   Warn if a global function is defined without a previous
+#   declaration -Wmissing-noreturn
+# ? -Wredundant-decls
+#Warn if anything is declared more than once in the same scope,
+# ? -Wnested-externs
+#Warn if an `extern' declaration is encountered within an
+#function.  -Wlong-long
+# Ha. this is the default! with -pedantic.
+# -Wno-long-long for the nicest bit of C99
+#
+# -Wcast-align is now removed: it gives too many false positives
+#e.g. when accessing registers - this is all aligned
+ 
+2.7  => "",
+2.8  => "",
+#2.8  => "-Wsign-compare",
+2.95 => "",
+
+# 2.95 does align functions per default -malign-functions=4
+#  where the argument is used as a power of 2
+ 

Re: TAP diagnostic syntax proposal

[David Landgren]

Jonathan T. Rockway wrote:
I agree that "got" is generally a good word to avoid in formal writing, 
but in a testing protocol I think that it's an acceptable abbreviation 


No! Do not accept inferior substitutes, strive for perfection.

for "the actual result".  Especially since "received" doesn't quite 
convey the right meaning here.  Maybe "expected data" and "actual data" 


Expected and actual has a long tradition in scientific endeavour, and is 
what I put forward last year, the last time this subject came up.


(or "expected" and "actually") are better?  Or maybe "got" is fine; HTTP 
still works even though "Referer" is misspelled.


So we should use Recieved? :)

Has got/expected ever caused any confusion to anyone (including 
non-speakers of English)?  If so, why?


Yes me, and I am a native speaker (well, Australian... so... whatever...)

I ranted about this on -qa some time back, and Schwern said that it was 
too late to do anything about it now. But this new format allows me to 
roll out my rant again!


My confusion regarding "got" is that I never know whether it's what I 
got initially, and then I want to see what the test brings back, or 
whether I have something, and it's what I got back from the test. On a 
number of occasions I have stared at a failing test, wondering why when 
I run it manually or stick in printf statements I appear to be getting 
the right thing. Or the wrong thing, whatever. It gets me confused.


Compounded by the fact that, as others point out elsewhere in this 
thread, the order of appearance is backwards.


A primary school teacher taught me that "got" was a word of the weak, 
that can nearly always be replaced by something better. This is the only 
lesson that still stands out vivdly for me from that time.


Here, let me dig up that rant:

  http://www.mail-archive.com/perl-qa@perl.org/msg03999.html

Thanks,
David
--
Much of the propaganda that passes for news in our own society is given 
to immobilising and pacifying people and diverting them from the idea 
that they can confront power. -- John Pilger

Re: fetching module version from the command line

[H.Merijn Brand]

On 12 Jul 2006 11:52:07 -, Rafael Garcia-Suarez
<[EMAIL PROTECTED]> wrote:

> "Gabor Szabo" wrote in perl.qa :
> > While checking if the versions of all the modules are as
> > required in our installation I am using the following one liner to
> > fetch the version numbers.
> >
> > perl -MModule -e'print $Module::VERSION'
> 
> You should probably use -mModule to avoid calling Module::import().
> (also, in some pathological cases, one can imagine that
> UNIVERSAL::VERSION() has been overidden)
> 
> Side note:
> Abe Timmerman has a module, V, useful to get versions
> of installed modules:
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-03/msg01038.html

I never use -m. I should :)

# perl -mV -le'print V::get_version("DBI")'
1.51

-- 
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.9.x  on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.0, AIX 4.3 & 5.2, and Cygwin.   http://qa.perl.org
http://mirrors.develooper.com/hpux/   http://www.test-smoke.org
   http://www.goldmark.org/jeff/stupid-disclaimers/

Re: [perl #39777] Macro array considered lame

[Chip Salzenberg]

On Mon, Jul 10, 2006 at 12:09:08AM -0500, Vishal Soni wrote:
> -#define N_MACROS 4096
> +#define N_MACROS 8192

Thanks, applied.  But we can all see where this is going.

Will no one rid me of this troublesome fixed-size array for macros?
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [svn:perl6-synopsis] r10077 - doc/trunk/design/syn

[Aaron Sherman]

Smylers wrote:

[EMAIL PROTECTED] commits:

  

New Revision: 10077
Modified: doc/trunk/design/syn/S02.pod
==
 
-foo.bar		# foo().bar	-- postfix prevents args

+foo.bar# foo().bar -- illegal postfix, must use foo().bar
 foo .bar   # foo($_.bar)   -- no postfix starts with whitespace



I don't think it makes much sense to start the comments with an
alternate form for the expressions now denoted as illegal -- "here's
some other syntax which this used to be the same as but it no longer is"
probably only confuses the casual reader.
  


On a side note, does that apply only to expressions that start with an 
identifier, or does that mean that:


   $socket.accept.getlines

will have to be:

   $socket.accept().getlines

?

Re: fetching module version from the command line

[Rafael Garcia-Suarez]

"Gabor Szabo" wrote in perl.qa :
> While checking if the versions of all the modules are as
> required in our installation I am using the following one liner to
> fetch the version numbers.
>
> perl -MModule -e'print $Module::VERSION'

You should probably use -mModule to avoid calling Module::import().
(also, in some pathological cases, one can imagine that
UNIVERSAL::VERSION() has been overidden)

Side note:
Abe Timmerman has a module, V, useful to get versions
of installed modules:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-03/msg01038.html

Re: fetching module version from the command line

[H.Merijn Brand]

On Wed, 12 Jul 2006 13:41:16 +0300, "Gabor Szabo" <[EMAIL PROTECTED]> wrote:

> While checking if the versions of all the modules are as
> required in our installation I am using the following one liner to
> fetch the version numbers.
> 
> perl -MModule -e'print $Module::VERSION'

Not really reliable :) But the more reliable ways take some post-processing

pc09:/home/merijn 108 > perl -le'require V;print V::get_version("DBI")'
1.51
pc09:/home/merijn 109 > perl -MExtUtils::Installed -le'print 
ExtUtils::Installed->new->version("DBI")'
1.51
pc09:/home/merijn 110 > perl -MV=DBI
DBI
/pro/lib/perl5/site_perl/5.8.7/i686-linux-64int/DBI.pm: 1.51
pc09:/home/merijn 111 > perl -le'require V;print V::get_version("DBI")' 
1.51
pc09:/home/merijn 112 > perl -MDBI=99
DBI version 99 required--this is only version 1.51 at 
/pro/lib/perl5/5.8.7/Exporter/Heavy.pm line 121.
BEGIN failed--compilation aborted.
Exit 9
pc09:/home/merijn 113 >

V is not (yet) on CPAN: http://www.test-smoke.org/otherperl.html

> Some of the modules print extra error messages and some print
> only error messages.
> I have sent e-mail to the respective module authors reporting this
> issue but I wonder if it would this a good practice in the genric case.
> 
> Is there a Test module that test just the above?
> Is the a CPANST score one can get if all the modules in a distro
> provide the correct version information and if they don't print anything
> else to STDOUT or STDERR.


-- 
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.9.x  on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.0, AIX 4.3 & 5.2, and Cygwin.   http://qa.perl.org
http://mirrors.develooper.com/hpux/   http://www.test-smoke.org
   http://www.goldmark.org/jeff/stupid-disclaimers/

Re: fetching module version from the command line

[Adriano Ferreira]

On 7/12/06, Gabor Szabo <[EMAIL PROTECTED]> wrote:

While checking if the versions of all the modules are as
required in our installation I am using the following one liner to
fetch the version numbers.



perl -MModule -e'print $Module::VERSION'


This one-liner doesn't work all the time in modules with deep magic
(filters and modules which do strange/heavy things in BEGIN blocks,
POD-only modules and the like). A (text-based) alternative is the
ExtUtils::MakeMaker approach, which goes as follows:

perl -MExtUtils::MakeMaker -e 'print MM->parse_version(shift)'
/usr/lib/perl5/site_perl/5.8/Module.pm

Unfortunately, it depends on knowing where the .pm file is. But that
can be arranged.


Some of the modules print extra error messages and some print
only error messages.
I have sent e-mail to the respective module authors reporting this
issue but I wonder if it would this a good practice in the genric case.


I think that having version numbers is a good practice. Although to
demand they may be retrieved with "perl -MModule -e 'print
$Module::VERSION'" may be too much - don't forget that it means the
module should compile and certain modules may demand a bunch of
environment settings to do it (the right libraries, some bit of
configuration, etc.)


Is there a Test module that test just the above?
Is the a CPANST score one can get if all the modules in a distro
provide the correct version information and if they don't print anything
else to STDOUT or STDERR.


I think a test to check version numbers are provided is enough.
Another issue is that use_ok() (or some variant) works too (in a
silent fashion). As a matter of fact, the absence of version numbers
is very common for modules which are not the ones that provide the
version number for a CPAN distribution - you may see this at many
places: core modules and many others. For example, trying the YAML::*
modules installed in a Cygwin machine with which_pm (from Module-Which
distribution) gives me (module name, version, location):

$ which_pm YAML:: --p5p
YAML::Syck   0.45   at ${installsitearch}/
YAML::Loader::Syck   undef  at ${installsitearch}/
YAML::Dumper::Syck   undef  at ${installsitearch}/
YAML::Transfer   undef  at ${installsitelib}/
YAML::Family undef  at ${installsitelib}/
YAML::Node   undef  at ${installsitelib}/
YAML::Marshall   undef  at ${installsitelib}/
YAML::Tagundef  at ${installsitelib}/
YAML::Base   undef  at ${installsitelib}/
YAML::Types  undef  at ${installsitelib}/
YAML::Loader undef  at ${installsitelib}/
YAML::Error  undef  at ${installsitelib}/
YAML::Dumper undef  at ${installsitelib}/
YAML::Tiny   0.05   at ${installsitelib}/
YAML::Loader::Base   undef  at ${installsitelib}/
YAML::Dumper::Base   undef  at ${installsitelib}/

from Config:
   installsitearch: /usr/lib/perl5/site_perl/5.8/cygwin
   installsitelib: /usr/lib/perl5/site_perl/5.8

Adriano.

fetching module version from the command line

[Gabor Szabo]

While checking if the versions of all the modules are as
required in our installation I am using the following one liner to
fetch the version numbers.

perl -MModule -e'print $Module::VERSION'

Some of the modules print extra error messages and some print
only error messages.
I have sent e-mail to the respective module authors reporting this
issue but I wonder if it would this a good practice in the genric case.

Is there a Test module that test just the above?
Is the a CPANST score one can get if all the modules in a distro
provide the correct version information and if they don't print anything
else to STDOUT or STDERR.

Gabor

Re: TAP Namespace Nonproliferation Treaty

[Smylers]

Ian Langworth writes:

> Ovid: TAP::Parser::Pedantic
> 
> Schwern: TAP::Parser::Heuristic

That's the best idea: nobody claiming that his particular parser is
_the_ TAP::Parser (or even _the_ TAPx::Parser), but giving them parallel
names with adjectives that hint at ways in which they differ.  Even if
the hints are obscure it's better than just having arbitrary different
names.

At least, nobody claim that namespace _yet_.  A few years down the line
we might've collectively learnt enough that we bless one particular
parser as canonical, or perhaps we'll make TAP::Parser be a front end
multiplexer for picking which parser to load.

> I've always feared /^[A-Z]+x::/ namespaces because I never understood
> them.

They make sense in some circumstances, where there is a well defined
project or system which itself is spread across several modules, and
other folk wish to contribute modules which are not part of that system
but are extensions to it.

But ... I don't think that applies here; it isn't that there's a "core"
Tap system and a clear distinction between that and extensions to it,
and I think it would just get confusing trying to remember which are
TAP:: and which are TAPx:: modules.

Smylers

Re: TAP diagnostic syntax proposal

[A. Pagaltzis]

* Adam Kennedy <[EMAIL PROTECTED]> [2006-07-12 06:10]:
> Fair enough a "Layer 1" TAP parser might not care, but why not
> make it as equally easy to implement a "Layer 2" parser as
> well.

+1

Did you guys consider the problem of newlines in content?

Regards,
-- 
Aristotle Pagaltzis // 

Re: [svn:perl6-synopsis] r10077 - doc/trunk/design/syn

[Smylers]

[EMAIL PROTECTED] commits:

> New Revision: 10077
> Modified: doc/trunk/design/syn/S02.pod
> ==
>  
> -foo.bar  # foo().bar -- postfix prevents args
> +foo.bar  # foo().bar -- illegal postfix, must use foo().bar
>  foo .bar # foo($_.bar)   -- no postfix starts with whitespace

I don't think it makes much sense to start the comments with an
alternate form for the expressions now denoted as illegal -- "here's
some other syntax which this used to be the same as but it no longer is"
probably only confuses the casual reader.

Smylers