Thanks for taking the time to look into this! I can't reproduce it with
that snippet, even if I make the file nonempty. But I can reproduce it with
the following two snippets. (I could not reproduce when I populated the
input file in the same script that does the await loop.)
perl6 -e '"$*TMPDIR/R
Oh, and when the list of filenames is the simpler `"$*TMPDIR/RT132447.test"
xx 100`, the problem also appears, but it seemed to take many more
iterations to crash. That could be just chance, though.
On Sat, Nov 18, 2017 at 4:01 PM Dan Zwell wrote:
> Thanks for taking the time to look into this!
Oh, and when the list of filenames is the simpler `"$*TMPDIR/RT132447.test"
xx 100`, the problem also appears, but it seemed to take many more
iterations to crash. That could be just chance, though.
On Sat, Nov 18, 2017 at 4:01 PM Dan Zwell wrote:
> Thanks for taking the time to look into this!
Thanks for taking the time to look into this! I can't reproduce it with
that snippet, even if I make the file nonempty. But I can reproduce it with
the following two snippets. (I could not reproduce when I populated the
input file in the same script that does the await loop.)
perl6 -e '"$*TMPDIR/R
On Fri, 17 Nov 2017 09:26:10 -0800, d...@zwell.net wrote:
> After more careful checking, I found the bug fix did make it into the
> October release. A bisect showed it was fixed it in
> commit 6af44f8d38a02bbd0d68cfd014165d6e33e4d89a.
> [...]
> Slurping on the file handle you described still produc
On Fri, 17 Nov 2017 09:26:10 -0800, d...@zwell.net wrote:
> After more careful checking, I found the bug fix did make it into the
> October release. A bisect showed it was fixed it in
> commit 6af44f8d38a02bbd0d68cfd014165d6e33e4d89a.
> [...]
> Slurping on the file handle you described still produc
After more careful checking, I found the bug fix did make it into the
October release. A bisect showed it was fixed it in
commit 6af44f8d38a02bbd0d68cfd014165d6e33e4d89a. So, in the prior commit,
the --version 2017.09-490-g3f595acfb built on MoarVM version 2017.10, and
the exception (with --ll-exce
After more careful checking, I found the bug fix did make it into the
October release. A bisect showed it was fixed it in
commit 6af44f8d38a02bbd0d68cfd014165d6e33e4d89a. So, in the prior commit,
the --version 2017.09-490-g3f595acfb built on MoarVM version 2017.10, and
the exception (with --ll-exce
Marked as ｢testneeded｣ to make sure we have tests for it.
If there are tests already, then it should be linked and the ticket can be
closed.
On 2017-11-15 14:43:51, d...@zwell.net wrote:
> It seems this has already been resolved on the master branch. After
> making
> a new build, I cannot reprodu
# New Ticket Created by Dan Zwell
# Please include the string: [perl #132447]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132447 >
The exception is:
Cannot assign to an immutable value in method slurp at
SETTING::src/core/
Hi,
Having trouble reproducing this on Linux on 2017.10-177-g77048b6 in a dir with
33k files that have one line of text each.
- Can you inlcude the exact version (perl6 -v) to go with the --ll-exception
stack trace so we can examine the referenced core code? I tried following the
line numbers
Hi,
Having trouble reproducing this on Linux on 2017.10-177-g77048b6 in a dir with
33k files that have one line of text each.
- Can you inlcude the exact version (perl6 -v) to go with the --ll-exception
stack trace so we can examine the referenced core code? I tried following the
line numbers
12 matches
Mail list logo
