Giter Site home page Giter Site logo

star's People

Contributors

antonoks avatar bbkr avatar clarkema avatar coke avatar cxreg avatar donaldh avatar froggs avatar hankache avatar hoelzro avatar jnthn avatar lizmat avatar moritz avatar mouq avatar nl6720 avatar patrickbkr avatar perlpilot avatar pmichaud avatar rehsack avatar ronaldxs avatar shimmerfairy avatar snarkyboojum avatar stmuk avatar szabgab avatar tbrowder avatar timo avatar tisonkun avatar tyil avatar util avatar virtualsue avatar zoffixznet avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

star's Issues

Zavolaj fails modules-test under Windows.

Running modules-test in star 2013.02 (Win XP 32-bit) produces test fails in zavolaj:

Testing modules/zavolaj...
t/01-argless.t ......... ok
t/02-simple-args.t ..... ok
t/03-simple-returns.t .. ok
t/04-pointers.t ........ ok
t/05-arrays.t .......... t/05-arrays.c:64:1: error: unknown type name 'int8_t'
t/05-arrays.c: In function 'ReturnsAByteArray':
t/05-arrays.c:65:5: error: unknown type name 'int8_t'
t/05-arrays.c:65:35: error: 'int8_t' undeclared (first use in this function)
t/05-arrays.c:65:35: note: each undeclared identifier is reported only once for
each function it appears in
t/05-arrays.c: At top level:
t/05-arrays.c:72:31: error: unknown type name 'int8_t'
g++: error: 05-arrays.o: No such file or directory
Cannot locate native library './05-arrays.dll'
  in method postcircumfix:<( )> at c:/rakudo/lib/parrot/4.10.0/languages/perl6/l
ib/NativeCall.pm6:122
  in  at src\gen\BOOTSTRAP.pm:883
  in any  at src\gen\BOOTSTRAP.pm:867
  in block  at t/05-arrays.t:12

t/05-arrays.t .......... Dubious, test returned 1 (wstat 256, 0x100)
Failed 26/26 subtests
t/06-struct.t .......... t/06-struct.c:14:5: error: unknown type name 'int8_t'
g++: error: 06-struct.o: No such file or directory
t/06-struct.t .......... 1/30 Cannot locate native library './06-struct.dll'
  in method postcircumfix:<( )> at c:/rakudo/lib/parrot/4.10.0/languages/perl6/l
ib/NativeCall.pm6:122
  in  at src\gen\BOOTSTRAP.pm:883
  in any  at src\gen\BOOTSTRAP.pm:867
  in block  at t/06-struct.t:115

t/06-struct.t .......... Dubious, test returned 1 (wstat 256, 0x100)
Failed 25/30 subtests
t/07-writebarrier.t .... ok
t/08-callbacks.t ....... ok

Test Summary Report
-------------------
t/05-arrays.t        (Wstat: 256 Tests: 0 Failed: 0)
  Non-zero exit status: 1
  Parse errors: Bad plan.  You planned 26 tests but ran 0.
t/06-struct.t        (Wstat: 256 Tests: 5 Failed: 0)
  Non-zero exit status: 1
  Parse errors: Bad plan.  You planned 30 tests but ran 5.
Files=8, Tests=43, 13 wallclock secs ( 0.03 usr +  0.06 sys =  0.09 CPU)
Result: FAIL

MSI can't be installed on Windows machines without C: drive.

The MSI download exits with an error "Drive C: doesn't exist" immediately after being launched here. This is correct, there is indeed no "C:" drive on this machine (Windows is installed in "W:\Windows") expressly for the purpose of detecting any bugs (usually in my own code) that would hardcode "c:\whatever".

I looked at fixing this myself but I'm not a WiX expert and, moreover, tools/build/star-product.wxs clearly says that hardcoding "C:" is done on purpose -- but I have no idea what this purpose is. Still, I think it would be better to change this.

"make modules-test" doesn't fail when tests fail

The make task should fail if any of the child tests fail. tools/build/modules-test.pl is hardwired to return 0 - it could check the return status of the child "prove" processes and at change the exit code based on that.

DESTDIR support would be awesome

It would be awesome if there were DESTDIR support in the installation
procedure of rakudo-star.

Very long version:

I've been trying to package rakudo-star for pkgsrc[1], a framework for
building third-party software on NetBSD and other UNIX-like systems, (or
for now more specifically, pkgsrc-wip[2]).

[1] www.pkgsrc.org
[2] git://wip.pkgsrc.org/pkgsrc-wip.git

The general way packages in pkgsrc work is that anyone non-root can
build them, since they are installed to a $DESTDIR and later copied to
the final installation $PREFIX. I think other package management systems
use a similar approach.

However, the build process of rakudo-star makes this difficult. I
noticed that it builds something, installs it to its final destination,
and then uses it to build some more things. This is generally not
compatible with installing via a staging directory (since running
programs from the staging directory is not generally guaranteed to work).

So I tried two approaches to get around this. Both failed at some point
with files being searched in other locations than they were. However in
both cases I got the feeling that it was almost working, and somebody
who knows what they were doing could make it work fairly easily.

Approach [A].

I noticed that the --sdkroot option was used in a lot of places quite
similar to $DESTDIR: the pattern of forming path names
${SDKROOT}${PREFIX}/bin/...

So here I tried to use the --sdkroot option to have the software built
and installed into the staging area just before being used.
Approximately like this:

PREFIX=/usr/pkg
export DESTDIR=/for/instance/tmp/something
Configure.pl --prefix=${PREFIX} --backends=moar --gen-moar --sdkroot=${DESTDIR}

I noticed that not all invocations of sub-Configures were receiving a
copy of the --skdroot option, so I tried to add some code for it to
nqp/tools/lib/NQP/Configure.pm to recognize and pass on the --sdkroot
option.

To make moar work, finding moar.so, I also had to add an

export LD_LIBRARY_PATH=${DESTDIR}${PREFIX}/lib

but my attempt eventually stranded as below and I gave up at this point
and tried another approach.

...
/usr/pkg/bin/perl -MExtUtils::Command -e cp 3rdparty/dyncall/dyncall/*.h /home/tmp/wip/rakudo-star/work.x86_64/.destdir/usr/pkg/include/dyncall
/usr/pkg/bin/perl -MExtUtils::Command -e cp 3rdparty/dyncall/dyncallback/*.h /home/tmp/wip/rakudo-star/work.x86_64/.destdir/usr/pkg/include/dyncall
Building NQP ...
/usr/pkg/bin/perl Configure.pl --prefix=/usr/pkg --sdkroot=/home/tmp/wip/rakudo-star/work.x86_64/.destdir --backends=moar --make-install
Found /home/tmp/wip/rakudo-star/work.x86_64/.destdir/usr/pkg/bin/moar version 2016.04, which is new enough.
Cleaning up ...
/usr/pkg/bin/perl -MExtUtils::Command -e mkpath gen/moar/stage1/gen
/usr/pkg/bin/perl tools/build/gen-cat.pl moar src/how/Archetypes.nqp src/how/RoleToRoleApplier.nqp  src/how/NQPConcreteRoleHOW.nqp src/how/RoleToClassApplier.nqp  src/how/NQPCurriedRoleHOW.nqp src/how/NQPParametricRoleHOW.nqp  src/how/NQPClassHOW.nqp src/how/NQPNativeHOW.nqp  src/how/NQPAttribute.nqp src/how/NQPModuleHOW.nqp  src/how/EXPORTHOW.nqp > gen/moar/stage1/nqpmo.nqp
/usr/pkg/bin/moar --libpath=src/vm/moar/stage0 src/vm/moar/stage0/nqp.moarvm --bootstrap --setting=NULL --no-regex-lib --target=mbc  --output=gen/moar/stage1/nqpmo.moarvm gen/moar/stage1/nqpmo.nqp
sh: /usr/pkg/bin/moar: not found
*** Error code 127

Stop.
make: stopped in /home/tmp/wip/rakudo-star/work.x86_64/rakudo-star-2016.04/nqp
Command failed (status 256): make
Command failed (status 256): /usr/pkg/bin/perl Configure.pl --prefix=/usr/pkg --sdkroot=/home/tmp/wip/rakudo-star/work.x86_64/.destdir --backends=moar --make-install
*** Error code 2

Approach [B].

Here I thought I would do a bootstrap process, where I first build a
rakudo to some temporary directory, using its normal procedure, and then
use that one to build and install to $DESTDIR. I thought it should work
since I noticed that $DESTDIR was actually used in many places in
Makefiles etc.

These are the command I used:

SDKROOT=/tmp/sdkroot
mkdir ${SDKROOT:Q}

PREFIX=/usr/pkg
export DESTDIR=/for/instance/tmp/something

# Build for sdkroot
perl Configure.pl --prefix=${SDKROOT:Q} --gen-moar

make rakudo-install

# Configure and build for real
perl Configure.pl --prefix=${PREFIX:Q} --gen-moar --sdkroot=${SDKROOT:Q}

make install

This however went along nicely, until

# Configure and build for real

...

compiling src/instrument/crossthreadwrite.o
compiling src/moar.o
compiling src/platform/posix/mmap.o
compiling src/platform/posix/time.o
compiling src/platform/posix/sys.o
compiling src/jit/emit_posix_x64.o
linking libmoar.so
linking moar
/usr/pkg/bin/perl build/mk-moar-pc.pl pkgconfig/moar.pc
/usr/pkg/bin/perl -MExtUtils::Command -e mkpath /usr/pkg/bin
/usr/pkg/bin/perl -MExtUtils::Command -e cp moar /usr/pkg/bin
/usr/pkg/bin/perl -MExtUtils::Command -e chmod 755 /usr/pkg/bin/moar
Cannot chmod 755 /usr/pkg/bin/moar:No such file or directory at /usr/pkg/lib/perl5/5.22.0/ExtUtils/Command.pm line 280.
*** Error code 2

Stop.
make[2]: stopped in /home/tmp/wip/rakudo-star/work.x86_64/rakudo-star-2016.04/MoarVM
Building NQP ...
/usr/pkg/bin/perl Configure.pl --prefix=/usr/pkg --backends=moar --make-install
Can't exec "/usr/pkg/bin/moar": No such file or directory at tools/lib/NQP/Configure.pm line 450.

===SORRY!===
No suitable MoarVM (moar executable) found using the --prefix
(You can get a MoarVM built automatically with --gen-moar.)

Command failed (status 512): /usr/pkg/bin/perl Configure.pl --prefix=/usr/pkg --backends=moar --make-install
*** Error code 2

It seems that $DESTDIR is not taken into account there in the perl
commands, and that the --sdkroot option is not used when trying to run
/usr/pkg/bin/moar.

At this point, I gave up again, seeing that the build scripts are a bit
too complicated to grok properly in a few hours.

So, after this introduction, this is more or less my question: Do you
developers agree that it is useful to have an easy installation
procedure via a staging directory? And if yes, what can you to realise
this?

Personally, I prefer approach [A] since it is not doing the work twice.
But it may need some tricks to be able to run programs from the staging
directory instead of the installation directory.

I noticed issue #65 is basically asking the same thing, but I've expanded on that by giving the results of some approaches that I tried.

#65
#43
voidlinux/void-packages#3536

module precompilation should be moved to build stage

Right now, modules are precompiled in the install stage. That does not work for packaging systems that use a fake installation directory that is different from the "real" final locations, since the perl6-m and perl6-j scripts will have the "real" paths in them. It also muddles the distinction between "build" and "install" stages.

Precompiling should be done at the end of the build, and the resulting files just copied by the "install" target.

create new makefile target, modules-test-unified

This target should have a single prove invocation that runs all the modules tests, but provides a unified prove harness.

This can be done by first generating a list of all the .t files present in the various module directories, then using a script passed to prove that can, based on the path of the file being tested, appropriately chdir and run the correct perl6 executable for a single test file.

Need a better term than "distribution"?

There's frequently an inadvertent pun that takes place between "distribution" in a CPAN module sense and the way we use it in the sense of Perl 6 compiler+module "distributions". We think of "Rakudo Star" (compiler + modules) as being a "distribution", while people familiar with CPAN think of an uploaded module tarball as being a "distribution".

Perhaps the terms are in fact the same at their toot, but it often feels like it could be a point of confusion for me. And I'm not suggesting we should try to get CPAN to change its terminology... because that's probably unlikely. But I would like to see if we can find a way to avoid confusion if we can.

This ticket is primarily a place to archive proposals and discussion. It can be closed when consensus is reached, or after 6 months if someone feels that discussion isn't heading anywhere.

Don't install perl6/doc web site generation supporting modules.

Really perl6/doc should be refactored upstream but after looking at it I'm not keen on doing that.

The only bits needed in R* are the .pod6 and p6doc scripts. I'm tempted to move the latter into a new repo and add the entire original perl6/doc as a git submodule. An alternative would be to patch the META6.json or use zef to install a different one.

Build and install output far too verbose

The output from building and installing rakudo star is so verbose that, when faced with an error message, it is hard to tell from which build step it comes.

It would be much nicer to have a simple OK/Not OK output, and a pointer to a log file where all the output from that step can be found.

make: *** [configclean] Error 2

Command

perl Configure.pl --backends=moar --gen-moar

on Rakudo Star 2014.04 throws following error at the end:

Creating Makefile ...
Cleaning up ...
make[1]: *** No rule to make target `clean'.  Stop.
make: *** [configclean] Error 2

separate build and install steps

Originally reported here: https://rt.perl.org/rt3/Ticket/Display.html?id=78126

Currently in Rakudo Star, 'make' only builds the compiler, and 'make
install' builds the modules and installs them.

If somebody wants to install into a location that's not writable by the
current user, it is important that the 'make install' step (usually
executed with sudo) doesn't create local files with the current user ID.

So 'make' should build rakudo and the module, and 'make install' should
do no building at all, but just installing.

Cheers,
Moritz

HTTP::Easy::PSGI fails to dispatch request

  1. Run following code
use HTTP::Easy::PSGI;
my $app = sub (%env) { print %env.perl; return [ 204, [ ], [ ] ]; };
my $psgi = HTTP::Easy::PSGI.new( host => "", port => 8080);
$psgi.app( $app );
$psgi.run;
  1. Try to connect to server using, for example, wget

Result:

Wget connects and stops on "awaiting response". When wget is killed dispatch is processed to $app and %env is printed.

Mixing roles into lazy lists fails

When playing around with the evalbot, I discovered these problems:
[22:44] star: (gather {} but role {})[0]
[22:44] star 2013.08: OUTPUT«This type does not support elems␤ in method REIFY at src/gen/CORE.setting:7531␤ in method reify at src/gen/CORE.setting:6757␤ in method gimme at src/gen/CORE.setting:7177␤ in method exists at src/gen/CORE.setting:7165␤ in method at_pos at src/gen/CORE.setting:7…
[22:46] star: ((^Inf) but role {})[0]
[22:46] star 2013.08: OUTPUT«No such method 'BUILD' for invocant of type 'Range+{}'␤ in method reify at src/gen/CORE.setting:6620␤ in method reify at src/gen/CORE.setting:6744␤ in method gimme at src/gen/CORE.setting:7177␤ in method exists at src/gen/CORE.setting:7165␤ in method at_p…

In both cases, I should get '( no output )', as I would if no role were mixed in.

README parrot options

Current README mentions --parrot-config param while Configure.pl --help shows no such thing, only --with-parrot is available.

Build failure (2015.11) on Darwin with nqp-2015.12 and MoarVM-2015.12

When trying to package rakudo-star-2015.11 using pkgsrc, I get a build failure. I used the 2015.12 releases of MoarVM and nqp, from separate tarballs, so that the different configure/build/install cycles are cleanly separated.

The error I get is:

The following step can take a long time, please be patient.
/opt/pkg/bin/moar --libpath="/opt/pkg/share/nqp/lib" perl6.moarvm --setting=NULL --ll-exception --optimize=3 --target=mbc --stagestats --output=CORE.setting.moarvm gen/moar/m-CORE.setting
Stage start      :   0.000
Stage parse      :  61.345
Stage syntaxcheck:   0.000
Stage ast        :   0.000
Stage optimize   :  10.388
Stage mast       : Arg count 3 doesn't equal required operand count 4 for op 'bind_sk'
   at gen/moar/stage2/QAST.nqp:1595  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_mastop:0)
 from gen/moar/stage2/QAST.nqp:1859  (/opt/pkg/share/nqp/lib/QAST.moarvm::0)
 from gen/moar/stage2/QAST.nqp:1798  (/opt/pkg/share/nqp/lib/QAST.moarvm::0)
 from gen/moar/stage2/QAST.nqp:1575  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_op:0)
 from gen/moar/stage2/QAST.nqp:5786  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:0)
 from gen/moar/stage2/QAST.nqp:5129  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:28)
 from gen/moar/stage2/QAST.nqp:5022  (/opt/pkg/share/nqp/lib/QAST.moarvm:as_mast:70)
 from gen/moar/stage2/QAST.nqp:5746  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_all_the_stmts:117)
 from gen/moar/stage2/QAST.nqp:5715  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_with_stmt_temps:0)
 from gen/moar/stage2/QAST.nqp:5704  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:0)
 from gen/moar/stage2/QAST.nqp:5129  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:28)
 from gen/moar/stage2/QAST.nqp:5022  (/opt/pkg/share/nqp/lib/QAST.moarvm:as_mast:70)
 from gen/moar/stage2/QAST.nqp:5726  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_all_the_stmts:0)
 from gen/moar/stage2/QAST.nqp:5701  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:46)
 from gen/moar/stage2/QAST.nqp:5129  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:28)
 from gen/moar/stage2/QAST.nqp:5022  (/opt/pkg/share/nqp/lib/QAST.moarvm:as_mast:70)
 from gen/moar/stage2/QAST.nqp:2190  (/opt/pkg/share/nqp/lib/QAST.moarvm::0)
 from gen/moar/stage2/QAST.nqp:1575  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_op:0)
 from gen/moar/stage2/QAST.nqp:5786  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:0)
 from gen/moar/stage2/QAST.nqp:5129  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:28)
 from gen/moar/stage2/QAST.nqp:5022  (/opt/pkg/share/nqp/lib/QAST.moarvm:as_mast:70)
 from src/vm/moar/Perl6/Ops.nqp:406  (blib/Perl6/Ops.moarvm::0)
 from gen/moar/stage2/QAST.nqp:1575  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_op:0)
 from gen/moar/stage2/QAST.nqp:5786  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:0)
 from gen/moar/stage2/QAST.nqp:5129  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:28)
 from gen/moar/stage2/QAST.nqp:5015  (/opt/pkg/share/nqp/lib/QAST.moarvm:as_mast:34)
 from gen/moar/stage2/QAST.nqp:5752  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_all_the_stmts:157)
 from gen/moar/stage2/QAST.nqp:5715  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_with_stmt_temps:0)
 from gen/moar/stage2/QAST.nqp:5704  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:0)
 from gen/moar/stage2/QAST.nqp:5129  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:28)
 from gen/moar/stage2/QAST.nqp:5018  (/opt/pkg/share/nqp/lib/QAST.moarvm:as_mast:53)
 from gen/moar/stage2/QAST.nqp:5752  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_all_the_stmts:157)
 from gen/moar/stage2/QAST.nqp:5697  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:0)
 from gen/moar/stage2/QAST.nqp:5129  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:28)
 from gen/moar/stage2/QAST.nqp:5010  (/opt/pkg/share/nqp/lib/QAST.moarvm:as_mast:0)
 from src/vm/moar/Perl6/Ops.nqp:671  (blib/Perl6/Ops.moarvm::0)
 from gen/moar/stage2/QAST.nqp:1575  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_op:0)
 from gen/moar/stage2/QAST.nqp:5786  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:0)
 from gen/moar/stage2/QAST.nqp:5129  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:28)
 from gen/moar/stage2/QAST.nqp:5010  (/opt/pkg/share/nqp/lib/QAST.moarvm:as_mast:0)
 from gen/moar/stage2/QAST.nqp:5741  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_all_the_stmts:4294967295)
 from gen/moar/stage2/QAST.nqp:3051  (/opt/pkg/share/nqp/lib/QAST.moarvm::0)
 from gen/moar/stage2/QAST.nqp:1575  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_op:0)
 from gen/moar/stage2/QAST.nqp:5786  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:0)
 from gen/moar/stage2/QAST.nqp:5129  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:28)
 from gen/moar/stage2/QAST.nqp:5022  (/opt/pkg/share/nqp/lib/QAST.moarvm:as_mast:70)
 from gen/moar/stage2/QAST.nqp:5726  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_all_the_stmts:0)
 from gen/moar/stage2/QAST.nqp:5701  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:46)
 from gen/moar/stage2/QAST.nqp:5129  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:28)
 from gen/moar/stage2/QAST.nqp:5022  (/opt/pkg/share/nqp/lib/QAST.moarvm:as_mast:70)
 from gen/moar/stage2/QAST.nqp:5746  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_all_the_stmts:117)
 from gen/moar/stage2/QAST.nqp:5371  (/opt/pkg/share/nqp/lib/QAST.moarvm::0)
 from gen/moar/stage2/QAST.nqp:5353  (/opt/pkg/share/nqp/lib/QAST.moarvm::0)
 from gen/moar/stage2/QAST.nqp:5302  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:0)
 from gen/moar/stage2/QAST.nqp:5129  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:28)
 from gen/moar/stage2/QAST.nqp:5010  (/opt/pkg/share/nqp/lib/QAST.moarvm:as_mast:0)
 from gen/moar/stage2/QAST.nqp:5752  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_all_the_stmts:157)
 from gen/moar/stage2/QAST.nqp:5697  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:0)
 from gen/moar/stage2/QAST.nqp:5129  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:28)
 from gen/moar/stage2/QAST.nqp:5010  (/opt/pkg/share/nqp/lib/QAST.moarvm:as_mast:0)
 from gen/moar/stage2/QAST.nqp:5752  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_all_the_stmts:157)
 from gen/moar/stage2/QAST.nqp:5371  (/opt/pkg/share/nqp/lib/QAST.moarvm::0)
 from gen/moar/stage2/QAST.nqp:5353  (/opt/pkg/share/nqp/lib/QAST.moarvm::0)
 from gen/moar/stage2/QAST.nqp:5302  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:0)
 from gen/moar/stage2/QAST.nqp:5129  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:28)
 from gen/moar/stage2/QAST.nqp:5010  (/opt/pkg/share/nqp/lib/QAST.moarvm:as_mast:0)
 from gen/moar/stage2/QAST.nqp:5752  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_all_the_stmts:157)
 from gen/moar/stage2/QAST.nqp:5697  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:0)
 from gen/moar/stage2/QAST.nqp:5129  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:28)
 from gen/moar/stage2/QAST.nqp:5010  (/opt/pkg/share/nqp/lib/QAST.moarvm:as_mast:0)
 from gen/moar/stage2/QAST.nqp:5752  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_all_the_stmts:157)
 from gen/moar/stage2/QAST.nqp:5715  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_with_stmt_temps:0)
 from gen/moar/stage2/QAST.nqp:5704  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:0)
 from gen/moar/stage2/QAST.nqp:5129  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:28)
 from gen/moar/stage2/QAST.nqp:5018  (/opt/pkg/share/nqp/lib/QAST.moarvm:as_mast:53)
 from gen/moar/stage2/QAST.nqp:5755  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_all_the_stmts:169)
 from gen/moar/stage2/QAST.nqp:5701  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:46)
 from gen/moar/stage2/QAST.nqp:5129  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:28)
 from gen/moar/stage2/QAST.nqp:5018  (/opt/pkg/share/nqp/lib/QAST.moarvm:as_mast:53)
 from gen/moar/stage2/QAST.nqp:5755  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_all_the_stmts:169)
 from gen/moar/stage2/QAST.nqp:5701  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:46)
 from gen/moar/stage2/QAST.nqp:5129  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:28)
 from gen/moar/stage2/QAST.nqp:5022  (/opt/pkg/share/nqp/lib/QAST.moarvm:as_mast:70)
 from gen/moar/stage2/QAST.nqp:5746  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_all_the_stmts:131)
 from gen/moar/stage2/QAST.nqp:5375  (/opt/pkg/share/nqp/lib/QAST.moarvm::70)
 from gen/moar/stage2/QAST.nqp:5354  (/opt/pkg/share/nqp/lib/QAST.moarvm::272)
 from gen/moar/stage2/QAST.nqp:5306  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:69)
 from gen/moar/stage2/QAST.nqp:5129  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:28)
 from gen/moar/stage2/QAST.nqp:5022  (/opt/pkg/share/nqp/lib/QAST.moarvm:as_mast:70)
 from gen/moar/stage2/QAST.nqp:2887  (/opt/pkg/share/nqp/lib/QAST.moarvm::96)
 from gen/moar/stage2/QAST.nqp:1584  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_op:57)
 from gen/moar/stage2/QAST.nqp:5788  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:23)
 from gen/moar/stage2/QAST.nqp:5129  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:28)
 from gen/moar/stage2/QAST.nqp:5022  (/opt/pkg/share/nqp/lib/QAST.moarvm:as_mast:70)
 from gen/moar/stage2/QAST.nqp:5746  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_all_the_stmts:131)
 from gen/moar/stage2/QAST.nqp:5375  (/opt/pkg/share/nqp/lib/QAST.moarvm::70)
 from gen/moar/stage2/QAST.nqp:5354  (/opt/pkg/share/nqp/lib/QAST.moarvm::272)
 from gen/moar/stage2/QAST.nqp:5306  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:69)
 from gen/moar/stage2/QAST.nqp:5129  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:28)
 from gen/moar/stage2/QAST.nqp:5022  (/opt/pkg/share/nqp/lib/QAST.moarvm:as_mast:70)
 from gen/moar/stage2/QAST.nqp:5151  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:100)
 from gen/moar/stage2/QAST.nqp:5129  (/opt/pkg/share/nqp/lib/QAST.moarvm:compile_node:28)
 from gen/moar/stage2/QAST.nqp:5022  (/opt/pkg/share/nqp/lib/QAST.moarvm:as_mast:70)
 from gen/moar/stage2/QAST.nqp:4759  (/opt/pkg/share/nqp/lib/QAST.moarvm:to_mast:46)
 from gen/moar/stage2/QAST.nqp:6513  (/opt/pkg/share/nqp/lib/QAST.moarvm:to_mast:16)
 from gen/moar/stage2/NQPHLL.nqp:205  (/opt/pkg/share/nqp/lib/NQPHLL.moarvm:mast:12)
 from gen/moar/stage2/NQPHLL.nqp:1552  (/opt/pkg/share/nqp/lib/NQPHLL.moarvm:compile:222)
 from gen/moar/stage2/NQPHLL.nqp:1286  (/opt/pkg/share/nqp/lib/NQPHLL.moarvm:eval:62)
 from gen/moar/stage2/NQPHLL.nqp:1506  (/opt/pkg/share/nqp/lib/NQPHLL.moarvm:evalfiles:91)
 from gen/moar/stage2/NQPHLL.nqp:1400  (/opt/pkg/share/nqp/lib/NQPHLL.moarvm:command_eval:214)
 from src/Perl6/Compiler.nqp:65  (blib/Perl6/Compiler.moarvm:command_eval:93)
 from gen/moar/stage2/NQPHLL.nqp:1374  (/opt/pkg/share/nqp/lib/NQPHLL.moarvm:command_line:114)
 from gen/moar/m-main.nqp:37  (perl6.moarvm:MAIN:18)
 from gen/moar/m-main.nqp:33  (perl6.moarvm:<mainline>:189)
 from <unknown>:1  (perl6.moarvm:<main>:8)
 from <unknown>:1  (perl6.moarvm:<entry>:9)
gnumake[1]: *** [CORE.setting.moarvm] Error 1
gnumake: *** [rakudo/perl6-m] Error 2
*** Error code 2

Compilation succeeds with rakudo-2015.12. Perhaps there should be a 2015.12 release of rakudo-star as well?

tools/star/Makefile doesn't work on OS X due to lack of `tar --xform`

make -f tools/star/Makefile

gives following error

tar --xform 's!parrot-[^/]*!parrot!' -xvzf src/parrot-5.5.0.tar.gz
tar: Option --xform is not supported

OS X 10.7.4

$ tar --version
bsdtar 2.8.3 - libarchive 2.8.3

BTW: I know that this tool is only used by person who creates release. If it cannot be made OS-context-free without significant amount of work then this issue can be closed or left as low priority task for some future refactoring.

Rakudo Star: Past Present and Future

Hi

Commenting on blogs.perl.org is broken (blogs-perl-org/blogs.perl.org#322) so I've created ticket to share my thoughts on the subject.

Although I have A LOT of sentiment for Rakudo Star and I appreciate effort put into it by many developers I think it should be discontinued.

At the beginning it was just complete ecosystem bundle (whooping 15 modules :P). It made sense when there were no good module managers like zef/panda and NativeCall was also not included. Nowadays it would be easier to simply bundle zef with Rakudo and focus on monthly compiler releases for various environments (Docker, *.deb, *.rpm, macOS, Windows, etc).

I really, really hate Perl 5 packaging. For example I have 120 MB Docker container and installing Perl with Core modules bloats it by... 48 MB. 2 MB are useless binaries like ptar or zipdetails. 42 MB are useless libraries like PerlIO::via::QuotedPrint or Pod::Perldoc::ToNroff. And the rest are useless manpages to them. It makes no sense in service oriented environments! This is "distribution" approach from previous decade when dial-up modems were still ruling the Earth and it was justified to provide as complete set of modules and documentation as possible to start using language without internet access. And Rakudo Star is going this obsolete way.

Of course YMMV and you may have different experience with Rakudo Star, but for me it is easier to use zef on top of compiler to get environment tailored for my needs than to install R* and waste time on debloating it by removing modules of questionable usefulness and PDFs.

Clarify in the README where the "install" dir is, and that /usr/local won't be touched

New users will expect make install to install to /usr/local by default. In the README, it's not perfectly clear that the "install" directory is actually a subdirectory of the source archive directory.

It should say something like:

"This will build a Perl 6 executable and install selected
Perl 6 modules in the install/ subdirectory, which resides
inside the source archive directory. Running make install
will not install anything into /usr/local. Programs can
then be run directly using a command like:"

2015.06 MSI needed

...particulary because of

  • the now required unit declaration for blockless packages
  • the switch to "kebabed" test function names, eg lives_ok -> lives-ok

URI uses deprecated Mu.bless

Star 2013.10

Passing an object candidate to Mu.bless is deprecated  in method new at /Users/bbkr/Developer/Perl6/rakudo/install/lib/parrot/5.9.0/languages/perl6/lib/IETF/RFC_Grammar.pm:50

Passing an object candidate to Mu.bless is deprecated  in method new at /Users/bbkr/Developer/Perl6/rakudo/install/lib/parrot/5.9.0/languages/perl6/lib/URI.pm:121

I'm reporting it here because https://github.com/colomon/uri/ has issues disabled.

Batch variable %~dp0\%0 expand incorrectly in PowerShell.

Rakudo star uses perl6 "%~dp0\%0" %* to wrap Perl 6 script in batch files. However, PowerShell expand %0 to pathname+filename, while cmd.exe expand %0 to just the filename.
For example, in C:\rakudo\bin\panda.bat this expand to C:\rakudo\bin\C:\rakudo\bin\panda.bat while in cmd.exe this expand to C:\rakudo\bin\\panda.
So panda can work in cmd.exe but a PowerShell will show following error message: Could not open C:\rakudo\bin\C:\rakudo\bin\panda.bat. Failed to open file: no such file or directory
I searched MSDN for a while and find a better special variable %~dpn0 to use, which could correctly expand to C:\rakudo\bin\panda under the 2 command prompt.

"error:imcc:The opcode" in modules installed with panda for Rakudo Start 2012.06

I have errors when i use old script with modules what installed from Panda for Rakudo Start 2012.06
After >panda install Module::Name error fixed.
What is it?
Error message:
===SORRY!===
error:imcc:The opcode 'perl6_type_check_return_value_p' (perl6_type_check_return_value<1>) was not found. Check the type and number of the arguments

Some tests fail due to no network access (in build chroot). Some tests phone home

I'm packing up Rakudo star using your company build system, this builds things in a mock chroot (CentOS) without any network access, which is really quite common in corporate environments.

Some of the tests try to phone home, and die if they can't do that, my monkeypatch to remove the failing tests is currently:

# These tests require the network and will fail in our chroot!
for test in \
    t/basic-auth.t \
    t/custom-headers-and-content.t \
    t/get-binary-camelia.t \
    t/get-chunked-6guts.t \
    t/get-perl6-org.t \
    t/get-unsized.t \
    t/get-w3-latin1-utf8.t \
    t/get-w3-redirect.t \
    t/getstore.t \
    t/socket-sanity.t 
do
    rm -v modules/perl6-lwp-simple/$test
done
rm -v modules/perl6-pod-to-bigpage/t/P.t

Please make tests that require network access non-default and opt-in e.g. via some env variable.

Why opt in? Because even if this succeeds tests shouldn't be phoning home by default, currently e.g. the LWP tests just phone home to some dude's personal server, which has bad privacy implications.

Bailador test failures in Rakudo Star

Rakudo Star 2013.02 fails modules-test in Bailador. This needs to be fixed prior to the 2013.03 release.

Testing modules/Bailador...
t/01-route-existance.t ... ok   
t/02-response-status.t ... ok   
t/03-response-content.t .. 2/7 Not enough positional parameters passed; got 0 but expected 1
  in sub  at t/03-response-content.t:12
  in block  at /zip/perl/rakudo-star-2013.02/install/lib/parrot/4.10.0/languages/perl6/lib/Bailador.pm:84
  in sub dispatch at /zip/perl/rakudo-star-2013.02/install/lib/parrot/4.10.0/languages/perl6/lib/Bailador.pm:80
  in sub dispatch_request at /zip/perl/rakudo-star-2013.02/install/lib/parrot/4.10.0/languages/perl6/lib/Bailador.pm:72
  in sub get-response at /zip/perl/rakudo-star-2013.02/install/lib/parrot/4.10.0/languages/perl6/lib/Bailador/Test.pm:9
  in sub response-content-is at /zip/perl/rakudo-star-2013.02/install/lib/parrot/4.10.0/languages/perl6/lib/Bailador/Test.pm:33
  in block  at t/03-response-content.t:21

t/03-response-content.t .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 3/7 subtests 
t/04-templates.t ......... ok   
t/05-post-content.t ...... ok   

Test Summary Report
-------------------
t/03-response-content.t (Wstat: 256 Tests: 4 Failed: 0)
  Non-zero exit status: 1
  Parse errors: Bad plan.  You planned 7 tests but ran 4.
Files=5, Tests=16,  6 wallclock secs ( 0.05 usr  0.02 sys +  5.02 cusr  0.76 csys =  5.85 CPU)
Result: FAIL

Have a sensible default install directory

./install is not a good choice, even more so if just moving it to wherever breaks everything. Alternatively, change the README so that the first example includes the --prefix option.

$DISTDIR support incomplete

It seems most parts of rakudo-star support a $DISTDIR for staged installs (e.g. rakudo installs fine there), but the modules-install step expects rakudo to be running from the final prefix already, and I found no way to work around this easily.

Would it be possible to generate wrappers which run rakudo from the build directory, and use these to build and install the modules, such that $DISTDIR is only written to with the ready built things?

It would greatly simplify packaging rakudo-star for distributions (I'm updating the packages for Void Linux: https://github.com/voidlinux/void-packages/pull/3536).

Rakudo Star 2012.08: Compilation fails on FreeBSD 8.2

$ perl Configure.pl --gen-parrot --prefix=$HOME/perl6

...

cc -I./include -I./include/pmc -DAPPLLIB_EXP="/usr/local/lib/perl5/5.12.4/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -pipe -fstack-protector -I/usr/local/include -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -DDISABLE_GC_DEBUG=1 -DNDEBUG -DHAS_GETTEXT -I/usr/local/lib/libffi-3.0.9/include -DPIC -fPIC -O2 -pipe -fno-strict-aliasing -falign-functions=16 -funit-at-a-time -maccumulate-outgoing-args -W -Wall -Waggregate-return -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdisabled-optimization -Wdiv-by-zero -Wendif-labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimport -Winit-self -Winline -Winvalid-pch -Werror=missing-braces -Wmissing-declarations -Wmissing-field-initializers -Wno-missing-format-attribute -Wmissing-include-dirs -Wmultichar -Wpacked -Wparentheses -Wpointer-arith -Wpointer-sign -Wreturn-type -Wsequence-point -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default -Wtrigraphs -Werror=undef -Wno-unused -Wunknown-pragmas -Wvariadic-macros -Wwrite-strings -Wc++-compat -Werror=declaration-after-statement -Werror=implicit-function-declaration -Wmissing-prototypes -Werror=nested-externs -Werror=old-style-definition -Werror=strict-prototypes -fvisibility=hidden -Isrc/string/encoding -Isrc/ -o src/string/encoding/shared.o -c src/string/encoding/shared.c
In file included from /usr/local/include/unicode/unorm2.h:33,
from /usr/local/include/unicode/unorm.h:23,
from src/string/encoding/shared.c:31:
/usr/local/include/unicode/uset.h:250: error: function declaration isn't a prototype
gmake: *** [src/string/encoding/shared.o] Error 1
Command failed (status 512): gmake install-dev

Another issue with module precompilation stage

Hi!

(possibly related to #43)

I created package templates for MoarVM, nqp and rakudo-star for Void Linux. I don't know how many people use them (if any), it worked OOB. Starting with 2015.06 module precompilation fails.

I guess it's not a big deal and I can do something about it in the templates (the full build log), but to me the whole system of hard-coding paths in perl6/perl6-m or similar files looks fragile.

JSON::RPC::Client test fails

line https://github.com/bbkr/jsonrpc/blob/master/t/client.t#L195 fails due to new "Nil resets to default value" fetaure

IRC explanation and workaround, TimToady++:

 <bbkr_> r: my $x = Nil; $x.WHAT.say # what is going on here?
 <camelia> rakudo e9e99b: OUTPUT«(Any)␤»
 <TimToady> bbkr_: you're setting $x back to its defualt of Any by assigning Nil to it
 <TimToady> Nil means "there's a missing value here"
 <TimToady> but a typed variable can't hold that; at its most undefined, it can hold only an undefined type object like Any or Int
 <bbkr_> TimToady: thanks for explanation. this new (or newly implemented) feature breaks JSON::RPC in Rakudo star. now I know how to fix it :)
 <TimToady> r: my Complex $c = 1+2i; say $c; $c = Nil; say $c;
 <camelia> rakudo e9e99b: OUTPUT«1+2i␤(Complex)␤»
 <bbkr_> r: my Nil $x = Nil; $x = Nil; $x.WHAT.say
 <camelia> rakudo e9e99b: OUTPUT«Nil␤»
 <TimToady> r: my Mu $x = Nil; say $x
 <camelia> rakudo e9e99b: OUTPUT«(Mu)␤»
 <TimToady> my $x := Nil; say $x
 <TimToady> r: my $x := Nil; say $x
 <camelia> rakudo e9e99b: OUTPUT«Nil␤»
 <TimToady> that works

I'll fix it today.

shebang line replacement breaks on Mac OS

tools/build/bin-install.pl performs a shebang line replacement. Instead of /usr/bin/env the path to the real perl executable is inserted. This should not be done because of http://stackoverflow.com/questions/9988125/shebang-pointing-to-script-also-having-shebang-is-effectively-ignored.

For example, when calling panda the shell will look up the shebang script (perl6), discover that it also has a shebang line, and therefore refuse to use it. Then bash tries to interpret panda on its own. 😄 Keeping the /usr/bin/env fixes the issue as this is a binary file.

If this is done to allow testing the different backends (perl6-p, perl6-m etc.), it could also be done togehter with /usr/bin/env, like #!/usr/bin/env perl6-p.

Please consider fixing this before the next rakudo star release, as homebrew refuses to accept a workaround I included in the updated rakudo-star formula.

make spectest_smolder doesn't post to smolder

Originally posted at https://rt.perl.org/rt3/Ticket/Display.html?id=112682

It tries to get a git version for the smolder server and since it can't 
find one for a basic rakudo star install t/spec it gets into trouble. A 
cleaner fix can be put in when RT 112680 is resolved. Until then I 
include a workaround:

Take the Makefile rule below:

spectest_smolder: rakudo_test_run.tar.gz
./perl6 -e "shell qqx[git log -1 --pretty=format:%H].fmt(qq[curl -F 
architecture=i386 -F platform=linux -F evision=%s -F 
report_file=@rakudo_test_run.tar.gz -F username=parrot-autobot -F 
password=qa_rocks 
http://smolder.parrot.org/app/projects/process_add_report/5])"

And rewrite to something like below which just comments out the line 
and adds a new copy with a revised qqx[ ... ].

spectest_smolder: rakudo_test_run.tar.gz
./perl6 -e "shell q[rakudo-star-2011.04].fmt(qq[curl -F 
architecture=i386 -F platform=linux -F evision=%s -F 
report_file=@rakudo_test_run.tar.gz -F username=parrot-autobot -F 
password=qa_rocks 
http://smolder.parrot.org/app/projects/process_add_report/5])"
spectest_smolder: rakudo_test_run.tar.gz
# ./perl6 -e "shell qqx[git log -1 --pretty=format:%H].fmt(qq[curl 
-F architecture=i386 -F platform=linux -F evision=%s -F 
report_file=@rakudo_test_run.tar.gz -F username=parrot-autobot -F 
password=qa_rocks 
http://smolder.parrot.org/app/projects/process_add_report/5])"

update perl6-File-Tools...

Need to replace perl6-File-Tools with Shell::Command and File::Find

Add a note to the upcoming release notes/Changelog. Try to note how much code is going to have to change as a result.

JSON::RPC dependencies change

I'd like to switch from LWP::Simple to HTTP::UserAgent - much more feature rich (SSL) and does not have to reparse URL on every request (it's constant through whole lifetime of JSON::RPC::Client).

However HTTP::UserAgent is not included in Star distribution.

So either JSON::RPC can be dropped from Star, or HTTP::UserAgent author can agree to include it.

"make install" doesn't return a non-zero exit code on failure

Before running "make install" try to create a failing test:

# file modules/xml-writer/t/fail.t 
modules/xml-writer/t/fail.t: symbolic link to `/bin/false'

The entire "install" will fail really early but the make process returns zero, so any automated build system trying to install rakudo will think that things went just fine.

AFAICT there's no way to see if the install phase failed than to do some hack like this:

make install 2>&1 | tee install.out
grep FAIL install.out >install.fail || :
test -e install.fail && ! test -s install.fail

Rakudo Star fails modules-test in perl6-lwp-simple

The 2013.02 star release fails its tests for perl6-lwp-simple:

Testing modules/perl6-lwp-simple...
t/000-load-module.t ............. ok   
t/basic-auth.t .................. ok   
t/custom-headers-and-content.t .. Cannot call 'match'; none of these signatures match:
:(Cool:D : $target, *%adverbs)

  in method match at src/gen/CORE.setting:2365
  in block  at t/custom-headers-and-content.t:12

t/custom-headers-and-content.t .. Dubious, test returned 1 (wstat 256, 0x100)
No subtests run 
t/get-binary-camelia.t .......... ok   
t/get-chunked-6guts.t ........... ok   
t/get-perl6-org.t ............... ok   
t/get-unsized.t ................. Cannot call 'match'; none of these signatures match:
:(Cool:D : $target, *%adverbs)

  in method match at src/gen/CORE.setting:2365
  in block  at t/get-unsized.t:10

t/get-unsized.t ................. Dubious, test returned 1 (wstat 256, 0x100)
No subtests run 
t/get-w3-latin1-utf8.t .......... ok   
t/get-w3-redirect.t ............. ok   
t/getstore.t .................... ok   
t/parse-url.t ................... ok    
t/socket-sanity.t ............... ok   
t/stringify-headers.t ........... ok   

Test Summary Report
-------------------
t/custom-headers-and-content.t (Wstat: 256 Tests: 0 Failed: 0)
  Non-zero exit status: 1
  Parse errors: No plan found in TAP output
t/get-unsized.t               (Wstat: 256 Tests: 0 Failed: 0)
  Non-zero exit status: 1
  Parse errors: No plan found in TAP output
Files=13, Tests=54, 69 wallclock secs ( 0.11 usr  0.04 sys + 61.63 cusr  2.26 csys = 64.04 CPU)
Result: FAIL

These failures need to be checked and corrected prior to the 2012.03 release.

Pm

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.