[perl #128453] [BUG] t\spec\S10-packages\precompilation.rakudo.moar fails on Windows

[Stefan Seifert via RT]

Can you please re-test? Similar failures were reportedly fixed by commit 
43debec892f0bdaf0c474d09c5805d1015fcae6d but I have no Windows system to test 
on.

[perl #131764] Passing stdin to Proc::Async mostly does not work ($proc.print: …; $proc.close-stdin)

[Stefan Seifert via RT]

$proc.print is asynchronous while $proc.close-stdin is not. In some cases $proc 
simply does not get the input because we closed its stdin before printing 
anything.

If .close-stdin is meant to by synchronous, this needs a doc patch. Otherwise 
we'd probably need to await any outstanding write promises before performing 
the actual nqp::closefh.

[perl #131831] Possible precomp issue: crash with `is a directory, cannot do '.open' on a directory` pointing to a sha1 hash of a dir

[Stefan Seifert via RT]

The .e there is absolutely correct as depending on the repository format 
version $lookup may be a file or directory. We switched to a directory with 
version 1. So the .f will fail on a current repo version which explains the 
failure in install-core-dist.pl

The real question is not why $lookup ends up being a directory (that's the 
normal case) but why we don't detect that we are dealing with a version 2 repo.

The PKGBUILD script posted on https://github.com/ugexe/zef/issues/190 gives the 
answer to that:

  rm -f "$pkgdir/usr/share/perl6/vendor/version"

Of course, by deleting that file, you rob rakudo of a vital piece of 
information. Without that it runs on the wrong assumption that it's dealing 
with a version 0 repository and that $lookup must be a file.

There's really nothing we could or should do here. As much as I'd like us to 
throw a more useful error message here, that's simply not possible without 
slowing down all normal uses. And trying to make rakudo resilient against 
random files missing sounds like an uphill battle.

Please just remove the offending lines from the script. This, too looks highly 
suspicious:
msg2 'Removing redundant precomp file dependencies...'
  _precomp=($(pacman -Qqg perl6 | grep -v zef | pacman -Qql - | grep -E 
'dist|precomp' || true))
  for _pc in "${_precomp[@]}"; do
[[ -f "$pkgdir/$_pc" ]] && rm -f "$pkgdir/$_pc"
  done

Considering that the spec file for openSUSE does not delete anything, I suggest 
starting with an absolute minimum of a build script. The install-dist.pl call 
may be quite sufficient. openSUSE does have quite strict packaging guidelines, 
too.
https://build.opensuse.org/package/view_file/devel:languages:perl6/perl6-Inline-Perl5/perl6-Inline-Perl5.spec?expand=1

[perl #131898] Issue Installing DBIish

[Stefan Seifert via RT]

Fixed in commit 9a0afcbcec8416c1d56bdced68a3f993e7be9d3c
Author: Stefan Seifert 
Date:   Wed Aug 16 20:27:11 2017 +0200

RT 131898: Fix native closures failing on the second run

On the first call of a native sub we create a new subroutine body and 
replace
the original (stored in the routine's $!do attribute). We also set the
invocation spec so the body will be called instead of the CALL-ME method. 
This
invocation spec is shared between an original routine and it's clones. If 
the
routine is a clousre, the body won't be shared as only a clone of the 
routine
will be actually visible in the lexical scope. So until someone comes up 
with
a better idea, we won't create an optimized version for a closure anymore.

[perl #131378] 2017.05-133-g094e77a fails to gmake install on Windows10

[Stefan Seifert via RT]

I bet, there's a file handle left open somewhere. This error is about 
CompUnit::Repository::Staging which is precompiled _three times_ in that 
script. Once when loading the module, the second time when installing the CORE 
dist and the third time to fix the source path of the installed Staging module.

It fails on the second precompilation. Though what's odd is, that the first one 
should write a precomp file to lib/.precomp, not to install/share/perl6/precomp.

Can you please re-run with RAKUDO_MODULE_DEBUG=1?

[perl #131003] [SEVERE][SEGV] Heap corruption when using Gumbo

[Stefan Seifert via RT]

I patched Gumbo to no longer create an XML tree but just a bunch of hashes, yet 
the error remains. So it's clearly not the XML module causing the issue but 
some NativeCall Gumbo thing. Gumbo makes heavy use of structs and nested 
structs. I guess the latter could be worth having a look as that's something 
that probably hasn't seen much use yet.