lease:
Paweł Murias, Elizabeth Mattijsen, Aleks-Daniel Jakimenko-Aleksejev,
Stefan Seifert, Jonathan Worthington, Ben Davies, Petr Rockai, Nick Logan,
Samantha McVey, Timo Paulssen, Momo
If you would like to contribute or find out more information, visit
<https://perl6.org>, <https://raku
ted to this release:
Elizabeth Mattijsen, Jonathan Worthington, cfa, Paweł Murias,
Will "Coke" Coleda, Aleks-Daniel Jakimenko-Aleksejev, Stefan Seifert,
Timo Paulssen, Nick Logan, Richard Hainsworth, Daniel Green,
Juan Julián Merelo Guervós, Tom Browder, Elena Merelo, Antonio, Altai-man,
I
ease are outlined below:
New in 2019.03.1:
+ Fixes:
+ Fixed issues with `$*KERNEL` on Windows [190a7148][2f9d69c2]
The following people contributed to this release:
Nick Logan, Aleks-Daniel Jakimenko-Aleksejev
If you would like to contribute or find out more information, visit
<https:
ulssen,
Jonathan Worthington, Will "Coke" Coleda, Paweł Murias,
Juan Julián Merelo Guervós, Daniel Green, Ben Davies, Christian Bartolomäus,
Altai-man, Nick Logan, Stefan Seifert, Aleks-Daniel Jakimenko-Aleksejev,
Tobias Boege, Antonio, cfa, Samantha McVey, lukasvalle, Clifton Wood,
Elen
Fixed issues when installing into `/usr` [f41db044]
+ Fixed unnecessary use of `git` in release tarballs
[540926bf][e18b4f3b]
+ Fixed intermittent failures in one of the performance tests [bd29d3f6]
The following people contributed to this release:
Patrick Böker, Aleks-Daniel Jakimenko-Aleksej
mizer interfering with some native subs [d662912e]
+ Fixed leaking an open file handle when re-precompiling [2dd570de]
The following people contributed to this release:
Vadim Belman, JJ Merelo, Aleks-Daniel Jakimenko-Aleksejev, Timo Paulssen,
Patrick Böker, Stefan Seifert, Daniel Green, Elizabe
, Brandon Allbery wrote:
>
> On Mon, May 8, 2017 at 2:52 PM, Aleks-Daniel Jakimenko-Aleksejev via RT <
> perl6-bugs-follo...@perl.org> wrote:
>
>> Usually I'm against all perl5 error messages
>
>
> This is a Pythonism (and C and other such languages). Older Perl
> If your main interest is security then
> you might be better off with a project like OpenBSD and helping update
> their Rakudo ports
Uh… this sounds like we are not welcoming contributions, which is not the
case. As clearly pointed out in this thread, there are things that can be
improved (even
methods on Pair [30584dac]
The following people contributed to this release:
Elizabeth Mattijsen, Jonathan Worthington, Zoffix Znet, Samantha McVey,
Will "Coke" Coleda, Pawel Murias, Aleks-Daniel Jakimenko-Aleksejev,
Stefan Seifert, Jan-Olof Hendig, David Warring, Nick Logan, Larry Wall
cbce6721][8a215876]
[9b42484a][a4ce97ca]
The following people contributed to this release:
Elizabeth Mattijsen, Aleks-Daniel Jakimenko-Aleksejev, Pawel Murias,
Will "Coke" Coleda, Samantha McVey, Jonathan Worthington, Moritz Lenz,
Steve Mynott, Wenzel P. P. Peppmeyer, Nick L
This is just a test.
Writing a comment by email.
Your comment makes no sense because almost all of that time is spent on the
compilation. Have you tried --stagestats like suggested above?
On Wed, Oct 11, 2017 at 7:43 PM, Parrot Raiser <1parr...@gmail.com> wrote:
> Round trips to the OS, like repeated "says", have been slow relative
> to interna
Oh. I guess this has to be rejected then.
On Fri, Oct 13, 2017 at 2:46 PM, Elizabeth Mattijsen wrote:
>
> > On 13 Oct 2017, at 07:37, Aleks-Daniel Jakimenko-Aleksejev (via RT) <
> perl6-bugs-follo...@perl.org> wrote:
> >
> > # New Ticket Created by Aleks-Daniel Ja
[371befe8][4d0ead24][92f239b5][7fa707db][d76af6aa][e513b857]
[f80a8461][fcbd8adb][21788c89][e2f8a57d][b58bd8fb][0dd6af71]
[f946bd35][cef3bf3e][92e51c3d][5144216f][ebd6440c]
The following people contributed to this release:
Zoffix Znet, Elizabeth Mattijsen, Pawel Murias, Jonath
Chen, Pawel Murias, Zoffix Znet,
Aleks-Daniel Jakimenko-Aleksejev, Christian Bartolomäus, Will "Coke" Coleda,
Jan-Olof Hendig, Samantha McVey, Daniel Green, Tom Browder, Jeremy Studer,
Jonathan Worthington, Stefan Seifert, Moritz Lenz, Nick Logan,
Jarkko Haapalainen, W4anD0eR96, Patrick Seba
esolved issues [20d67a3d][831dab14]
[1b0be0f6][062c27f3][1101fea1][fed56be2][47552282][ced4af66]
[d4ad6fa9][eaf609ed][04eb1da6]
The following people contributed to this release:
Zoffix Znet, Elizabeth Mattijsen, Pawel Murias, Alex Chen, Tom Browder,
Christian Bartolomäus, Luca Ferrari, Ale
roduced ValueObjAt, the .WHICH for value types [202459ce][4790587f]
+ Introduced Proc!set-status [7a4743be]
The following people contributed to this release:
Zoffix Znet, Luca Ferrari, Elizabeth Mattijsen, Tom Browder,
Christian Bartolomäus, Aleks-Daniel Jakimenko-Aleksejev,
Jonathan Worthin
ople contributed to this release:
Zoffix Znet, JJ Merelo, Pawel Murias, Aleks-Daniel Jakimenko-Aleksejev,
Stefan Seifert, Luca Ferrari, Will "Coke" Coleda, Tom Browder,
Samantha McVey, Elizabeth Mattijsen, Christian Bartolomäus, Jeremy Studer,
Curt Tilmes, Jan-Olof Hendig, Timo Paulssen, Its
following people contributed to this release:
Zoffix Znet, Aleks-Daniel Jakimenko-Aleksejev
If you would like to contribute or find out more information, visit
<http://perl6.org>, <http://rakudo.org/how-to-help>, ask on the
mailing list, or ask on IRC #perl6 on freenode.
Additionally, we inv
st a front for Str.substr-rw [038837f8]
+ Moved substr/substr-rw catcher methods from Any to Cool [aad79f8a]
+ Remote debug support on MoarVM [ffeff74e][e32bda21]
The following people contributed to this release:
Zoffix Znet, Elizabeth Mattijsen, JJ Merelo, Will "Coke" Coleda,
P
5]
The following people contributed to this release:
Zoffix Znet, Elizabeth Mattijsen, Pawel Murias, Will "Coke" Coleda,
Luca Ferrari, Aleks-Daniel Jakimenko-Aleksejev, cfa,
陈梓立, Christian Bartolomäus, Stefan Seifert, Jonathan Worthington,
Samantha McVey, Jeremy Studer, Juan Julián
ease are outlined below:
New in 2018.04.1:
+ Fixes:
+ Fixed hang in parsing of nums with huge exponents [4e38bc1f]
+ Fixed denormals and precision issues in num parser [cc93bc9a]
The following people contributed to this release:
Zoffix Znet, Aleks-Daniel Jakimenko-Aleksejev
If
Julián Merelo Guervós, Elizabeth Mattijsen, Zoffix Znet,
Will "Coke" Coleda, Aleks-Daniel Jakimenko-Aleksejev, Luca Ferrari,
Christian Bartolomäus, 陈梓立, Samantha McVey, Stefan Seifert,
Brian S. Julin, Ben Davies, Elena Merelo, Jeremy Studer, Paweł Murias,
Daniel Green, Itsuki Toyota, Fritz
+ Various NQP ↔ Perl 6 fixes [e4ecf5e5][23af3491][7bc6e46f][cbb5ee5f]
The following people contributed to this release:
Elizabeth Mattijsen, Will "Coke" Coleda, Jonathan Worthington,
Aleks-Daniel Jakimenko-Aleksejev, Zoffix Znet, Jeremy Studer,
Rafael Schipiura, 陈梓立, Tom Browder,
[0249afc2]
+ Turned p6reprname into a desugar [07cfbeb2]
The following people contributed to this release:
Zoffix Znet, Jonathan Worthington, Elizabeth Mattijsen,
Tom Browder, Jeremy Studer, Samantha McVey, Daniel Green,
Aleks-Daniel Jakimenko-Aleksejev, Will "Coke" Coleda, Paweł Mu
settypes extop [de4e8225]
+ Standardized use of proto's on `.STORE` methods [ed9b48de]
+ Removed EmptySeq [a4db33e7]
The following people contributed to this release:
Zoffix Znet, Elizabeth Mattijsen, Paweł Murias, Bart Wiegmans,
Samantha McVey, Stefan Seifert, Jeremy Studer, Timo P
ijsen, Paweł Murias, JJ Merelo, Tom Browder,
Bart Wiegmans, Jonathan Worthington, Will "Coke" Coleda,
Aleks-Daniel Jakimenko-Aleksejev, Samantha McVey, thebooort,
Juan Julián Merelo Guervós, Ben Davies, Fernando Correa de Oliveira,
Timo Paulssen, Daniel Green, MorayJ, Valentin Anger,
threadl
5a][8e858c8d][00eb7b85]
[0fa6988c][bf3575cc][18ded174]
The following people contributed to this release:
Stefan Seifert, Elizabeth Mattijsen, Zoffix Znet,
Aleks-Daniel Jakimenko-Aleksejev, Paweł Murias, Timo Paulssen, Nick Logan,
Tom Browder, Rob Hoelz, Jonathan Worthington, Joelle Maslak, D
Thanks! Indeed! I should have tried understanding the issue and golfing it
down myself.
So the snippet can be golfed down to:
say +126.chr
The bug is still there, please don't close. In fact, the title is very
precise.
“126.chr” is still “126.chr”. It is less than awesome to whine about some
sym
By the way, same LTA error is shown for Rat, Complex and possibly some
other types.
On Tue, Dec 22, 2015 at 5:04 PM, perl6 via RT
wrote:
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "Inf in Int, LTA error me
It should also be noted that ZERO WIDTH JOINER is used for other purposes
too:
https://books.google.ee/books?id=wn5sXG8bEAcC&lpg=PA287&ots=J1bym1VbXE&dq=unicode%20%22ZERO%20WIDTH%20JOINER&pg=PA287#v=onepage&q=unicode%20%22ZERO%20WIDTH%20JOINER&f=false
But I'm not sure if it should affect the chara
This is not closable at all. Now it segfaults.
Code:
say chr
Result:
Segmentation fault
Code:
say chr
Result:
chr codepoint cannot be negative
in block at /tmp/jicTmB4rt5 line 1
Code:
say chr 999
Result:
Cannot unbox 90 bit wide bigint into n
You can do it without % 1, sure. It is there to make it easier to see the
drift with your eyes, but you can see it without it.
> The occasional extra .01 seconds is expected, as we sleep for 'at least'
.1 seconds and can't be super exact.
Sure, but there is no ｢sleep｣ in Supply.interval(1) exampl
I'm slightly confused by this ticket… isn't it resolved now? Nowadays you get
an error message like this:
Unable to parse expression in single quotes; couldn't find final "'"
(corresponding starter was at line 2)
So while it blows up at the end of the file, it still mentions where the quote
start
Usually this happens when you have an unclosed string somewhere earlier in your
code.
That is:
say "foo; ← oops! Forgot the closing "
# $a ← we think that this is a comment, but actually it's part of the string
above!
On 2019-01-23 01:27:08, warren.mu...@gmail.com wrote:
> Hello:
>
> I ran into
Ticket moved to https://github.com/rakudo/rakudo/issues/2697
On 2015-09-25 14:06:27, duff wrote:
> On Sat Jul 25 12:03:18 2015, moritz wrote:
> > This script here:
> >
> > # BEGIN SCRIPT
> > my grammar PgTokenizer {
> > token double_quote_normal { <-[\\"]>+ }
> > token double_quote_escape { [\\ .
Closing, explanation here: https://github.com/rakudo/rakudo/issues/2708
On 2017-05-12 07:52:34, c...@zoffix.com wrote:
> https://irclog.perlgeek.de/perl6-dev/2017-05-12#i_14572067
>
> 14:49 m: my @a = 1..12; for ('a' x 100 ~ " -- Jan-12-2017")
> xx 100 { when /'-- ' |@a '-' \d**2 '-' \d**4 / { } }
Moved to https://github.com/rakudo/rakudo/issues/2725
On 2016-12-29 14:43:03, alex.jakime...@gmail.com wrote:
> Of course, same thing with “next” and “last” (is there anything else?)
>
> On 2016-12-29 09:13:24, alex.jakime...@gmail.com wrote:
> > Code:
> > say 42; redo
> >
> >
> > Result (2015.12,
OK, so that's not an issue in Rakudo then. Closed.
On 2019-03-05 11:16:41, sortiz wrote:
> The problem is the PEM_write_bio_RSAPrivateKey signature used in the
> NativeCall declaration, it missed five arguments.
>
> From the manual:
>
> int PEM_write_bio_RSAPrivateKey(BIO *bp, RSA *x, const EVP_CI
This is actually a regression. The code makes sense (more or less), I can't see
why would it error out like this.
Bisectable points to (2017-01-31)
https://github.com/rakudo/rakudo/commit/9ed4449db57cab39a115c5347387d5978bd56057
On 2017-04-24 15:52:55, grond...@yahoo.fr wrote:
> $ uname -a
> Linu
This is probably my favorite bug of the year :)
Thank you very much for your report.
There was a discussion about it today:
https://irclog.perlgeek.de/perl6-dev/2017-05-03#i_14521988
On 2017-05-02 10:42:33, shreya...@yahoo.com wrote:
>
> # create an array of 5 elements, remove 2, add a fifth one
Thank you for your report!
However, doc bugs are reported on github. I have moved your ticket there:
https://github.com/perl6/doc/issues/1299
On 2017-05-07 20:49:39, ben-goldb...@hotmail.com wrote:
> On https://docs.perl6.org/language/rb-nutshell, it says:
>
>
> * No space allowed before the open
I agree with you, but we can do better.
Usually I'm against all perl5 error messages, but I believe that this case is
different. I am sure that this is what most people attempt to do at some point.
I also know for sure that this is what I did a couple of times when I was
starting with Perl 6. I al
FWIW the problem is still there and is reproducible with the provided snippet
(just in case somebody is wondering if the issue went away by itself after
these months).
On 2017-04-04 06:46:20, scoli...@gmail.com wrote:
> Le Wed, 15 Mar 2017 17:12:00 -0700, alex.jakime...@gmail.com a écrit :
> > I a
Bisectable failed in the provided log, here is the right result:
AlexDaniel, Bisecting by output (old=2015.12 new=95b4e5d) because
on both starting points the exit code is 0
AlexDaniel, bisect log:
https://gist.github.com/1b6f1bdabefa1cb13338451abceea153
AlexDaniel, (2017-05-25)
https://github
But we already have ..., !!! and ???. Isn't it what you want?
m: sub foo() { … }; foo
rakudo-moar 608e88: OUTPUT: «Stub code executed in sub foo at
line 1 in block at line 1Actually thrown at: in block
at line 1»
m: sub foo() { !!! }; foo
rakudo-moar 608e88: OUTPUT: «Stub code exec
Well,
say IntStr ~~ Str # True
In other words, IntStr *is* a Str.
What I find interesting, however, is this difference:
sub s (Str() :$str) {say $str.WHAT}; s(:str<1>) # IntStr
sub s (Str :$str) {say $str.Str.WHAT}; s(:str<1>) # Str
I would have expected the same output in both cases.
On 2017
“The only people I see complaining about it are those who just type it up
randomly to see what it'd do”
We had a bunch of segfaults and overflows that could only be caused by people
throwing random stuff into the compiler. And yes, very often we had to go
through this “wait, but normal people will
See also this discussion:
https://irclog.perlgeek.de/perl6-dev/2017-06-07#i_14699799
In other words, if you fix this, please also fix the dead code issue in
“default {}”.
On 2017-06-07 09:35:49, alex.jakime...@gmail.com wrote:
> Code:
> say byte.Range
>
> Result:
> -Inf^..^Inf
>
An important line from bisectable output was omitted :)
samcv, The result looks a bit unrealistic, doesn't it? Most
probably the output is different on every commit (e.g. ｢bisect: say rand｣)
We can try this:
c: releases say ('a' x 1).IO.open
AlexDaniel,
https://gist.github.com/0727db8b69
This was discussed in
https://github.com/rakudo/rakudo/pull/1032#issuecomment-284217342
In theory, this ticket should apply for other ops as well.
Note that I said that I will change the way unicode ops are implemented, but I
didn't have much time since then. Hoping to get to it at some point.
O
I think this is related: https://github.com/perl6/doc/issues/1400
On 2017-07-01 12:25:39, pe...@mscha.org wrote:
> This is OK:
>
> > say [X] ((1,2,3), (4,5,6));
> ((1 4) (1 5) (1 6) (2 4) (2 5) (2 6) (3 4) (3 5) (3 6))
> > say [X*] ((1,2,3), (4,5,6));
> (4 5 6 8 10 12 12 15 18)
>
> ... but this is
I'd agree that it is a bug, yes. Well, the reason why it happens might be
justified, but this is probably one of the fattest traps I've seen so far. I
really think we should come up with a way to eliminate this trap somehow. Not
sure how, but there must be a way and I really recommend anybody readi
I don't really want to start another ticket for what I'm about to suggest,
therefore I'll reopen this one.
Not so long ago I filed this ticket:
https://rt.perl.org/Ticket/Display.html?id=131640
The underlying issue is exactly the same. And it has actually happened during
whateverable development,
Case in point: https://stackoverflow.com/questions/44835476
On 2016-08-29 19:28:10, alex.jakime...@gmail.com wrote:
> First of all, take a look at this:
> https://docs.perl6.org/language/traps#String_Ranges/Sequences
>
> The question is: why do we keep this trap?
>
> We all know that the idea of
Hm. Wouldn't that make behavior of Lists and Arrays different?
On 2017-07-04 05:29:20, comdog wrote:
> Accessing a List element beyond the end of the List returns Nil,
> although accessing an element before the beginning returns an out of
> bounds failure. I think there's two things that can be be
The fix for this ticket also fixed
https://rt.perl.org/Public/Bug/Display.html?id=130366
However, we couldn't find any tests… are there any? If they, perhaps they also
cover 130366.
On 2017-05-01 14:31:19, elizabeth wrote:
> Fixed for the .values case with c1bd844e2752799af8e and
> 0e0ac2fb8c51a8
This was resolved together with
https://rt.perl.org/Ticket/Display.html?id=131241
Tests needed, maybe. See other ticket for info on this.
On 2016-12-17 01:42:04, elizabeth wrote:
> $ 6 'my $b = .BagHash; $_-- for $b.values; dd $b'
> BagHash $b = ("a"=>0,"c"=>0,"b"=>1,"e"=>0,"f"=>0,"d"=>0).BagHash
Since when are we rejecting tickets like that? :)
The title says “Strange error”. Current error message is:
===SORRY!===
redo without loop construct
Two things:
1) No line number
2) Even if the line number was there, we don't want the behavior of this to be
changing like crazy. See output on all
That's pretty good. But issues are not closed without tests, unless there's a
good reason not to add a test. No reason was mentioned, therefore reopening
this with “testneeded” tag.
On 2017-07-09 15:49:46, jan-olof.hen...@bredband.net wrote:
> On Wed, 19 Oct 2016 05:57:04 -0700, jn...@jnthn.net wr
On 2017-07-12 22:49:43, ug...@cpan.org wrote:
> This only applies if you call .stdout or .stderr *and* never close them.
Hm, isn't it fixed now? Similarly to https://github.com/perl6/doc/issues/1304 ?
On 2017-07-13 08:18:20, alex.jakime...@gmail.com wrote:
> On 2017-07-12 22:49:43, ug...@cpan.org wrote:
> > This only applies if you call .stdout or .stderr *and* never close
> > them.
>
> Hm, isn't it fixed now? Similarly to
> https://github.com/perl6/doc/issues/1304 ?
Ah, no, it's not. It's a co
I don't think this ticket needs so much discussion… It's basically about
implementing the damn thing properly (and coming up with a way to do it along
the way).
On 2017-07-16 21:17:22, alex.jakime...@gmail.com wrote:
> See this:
>
https://github.com/rakudo/rakudo/blob/6c76ed0abe352316eb58283fa6ce6
I think the purpose of the ticket was stated clearly in the first message.
Feel free to change the comment in the source code to “This is a hack but
there's no point to improve it” and close the ticket.
To me it felt like the intention was to improve this part later, but no TODO
comment was left,
Alright, it seems that rakudo is not entirely incorrect here. See this
discussion: https://irclog.perlgeek.de/perl6-dev/2017-07-18#i_14885863
TL;DR, one should use something like this:
whenever $proc.print(“one\ntwo\nthree\nfour”) { $proc.close-stdin }
So it seems that it's not a bug, but a trap
Is there any code snippet to reproduce it?
The backtrace mentions mongo-perl6-driver…
On 2017-07-22 02:38:03, mt1...@gmail.com wrote:
> Test code erred in perl6 version 2017.07-31-g895bdc8 built on MoarVM
> version 2017.07.
>
> Regards,
> Marcel
>
>
> The crash dump;
>
>
> *** Error in `/home/mar
A test was added in
https://github.com/perl6/roast/commit/84e5309567a5f3ee0d1d7450e08225119b08f3af
dogbert17++
On 2017-07-21 12:46:12, jan-olof.hen...@bredband.net wrote:
> On Sat, 14 Nov 2015 14:06:52 -0800, grond...@yahoo.fr wrote:
> > $ perl6 --version
> > This is perl6 version 2015.10-294-gcc1
Eh. The effort required to implement the feature is much less than having
discussions *like this*. I'll try to be quick.
“there's large possibility of introducing some unwanted ambiguity somewhere”
A good thing to keep in mind indeed.
I don't really like these discussions before actual PRs, but
sub foo($bar!) { say $bar }; foo(42)
On 2017-07-22 11:19:41, alex.jakime...@gmail.com wrote:
> Eh. The effort required to implement the feature is much less than
> having
> discussions *like this*. I'll try to be quick.
>
> “there's large possibility of introducing some unwanted ambiguity
> somewh
igint into native integer
>
> $ 6 'my @a[999]'
> Illegal dimension in shape: 999. All dimensions must
> be integers bigger than 0
>
> etc etc etc.
>
> > On 7 Dec 2016, at 01:37, Aleks-Daniel Jakimenko-Aleksejev (via RT)
> > w
I bisected it to
https://github.com/rakudo/rakudo/commit/40a953f5d9f5c661d8cf9b043643002d348a2000
On earlier rakudo versions it seems to be working fine. I haven't seen it crash
once on anything earlier, but it is *very* slow on rakudos that old, so it's
hard to tell.
nqp changes:
https://github
Perhaps also worth noting that this applies to other holes as well, e.g. those
created by extending an array:
my @a = 42; @a[5] = 49; say |@a # 42(Mu)(Mu)(Mu)(Mu)49
In fact, this the actual problem the user had.
On 2017-07-22 18:52:03, c...@zoffix.com wrote:
> On Sat, 22 Jul 2017 18:48:38 -0700,
t;
> On Sun, Jul 23, 2017 at 6:05 AM Aleks-Daniel Jakimenko-Aleksejev via
> RT <
> perl6-bugs-follo...@perl.org> wrote:
>
> > sub foo($bar!) { say $bar }; foo(42)
> >
> > On 2017-07-22 11:19:41, alex.jakime...@gmail.com wrote:
> > > Eh. The e
it's asking the compiler about something.
> >
> > ‘:foo’ sets foo to True. ‘:!foo’ sets it to False. ‘:?foo’ looks like
> > it's
> > trying to ask something a question, but I'm not sure about what.
> >
> > On Sun, Jul 23, 2017 at 12:41 PM Aleks-Dan
For those reading this on RT, here's the previous comment in a readable way:
I wouldn't be so eager to judge the proposal based on the original post.
Sometimes I submit tickets fast, and sometimes ideas are not conveyed as
clearly as I assumed.
“How are those things related?”
These were the examp
estion. The ? prefix asks an
> expression whether it's True or False. When used as a sigil like
> $?FILE
> it's asking the compiler about something.
>
> ‘:foo’ sets foo to True. ‘:!foo’ sets it to False. ‘:?foo’ looks like
> it's
> trying to ask something a question, b
For those who don't agree that there is a connection between ? and !… Actually,
there are some other places where ?↔! connection is implied. In fact, I will
probably never list all of them.
In regexes:
* always succeeds, always fails (and no question implied)
* tests for truthy and falsey valu
Another interesting thing is that if this is implemented, then it will make it
possible to use ? in other places where is used. For example, it
will allow %h:?exists . It seems that it will also affect character classes
(e.g. <:?Ll>). Some of these totally make sense, some not so much. But we
alre
".gist" is probably the wrong answer in this case.
my @got = ‘one’, ‘two three’; say @got # OUTPUT: [one two three]
↑ Not very useful
On 2017-07-25 12:52:25, alex.jakime...@gmail.com wrote:
> Sometimes it is useful to test the input against regexes. Let's try:
>
> Code:
> use Test;
> cmp-ok ‘foo
cally caused by:
>
> $_ = 1; /1/
>
> Because $_ contains an Int, this becomes a very slow path. Compare
> this with:
>
> (^1)>>.Str.grep({!/1/}).elems.say
>
> which is 3x faster, even when using a sub-optimal hyper.
>
> Investigating further...
>
> >
FWIW, still happens after all changes during this month.
On 2017-07-22 16:21:30, alex.jakime...@gmail.com wrote:
> I bisected it to
>
https://github.com/rakudo/rakudo/commit/40a953f5d9f5c661d8cf9b043643002d348a2000
>
> On earlier rakudo versions it seems to be working fine. I haven't seen
> it cra
Not sure if this info is relevant now, but the hang was introduced in
(2016-02-18)
https://github.com/rakudo/rakudo/commit/9983c2c8434ed81c532a5706996f284283b48d0a
On 2017-08-05 06:33:14, c...@zoffix.com wrote:
> Since Seq is not a Positional type, *binding* it to a `@` variable is
> typecheck err
There's a little problem with it. You see, right now this works:
exit "1"
So we simply cannot force it to do something else with Strs because that can
break existing (perfectly valid) code. We can go through a long deprecation
cycle but it's not worth it (IMO).
But it may be possible to catch X:
IRC discussion: https://irclog.perlgeek.de/perl6/2017-08-09#i_14989886
Turns out that .hyper/.race never worked reliably anyway, so this ticket is
less important than it looks.
Maybe we should have a meta ticket that tracks all .hyper/.race issues. Another
option would be to just close them all,
It was bisected to
https://github.com/rakudo/rakudo/commit/f590863e1736c75207c9ce0335ea646e3529060e
Example (before and after):
https://gist.github.com/Whateverable/2a9088ddcff37fd6f748b77ba3339af2
On 2017-08-10 14:54:24, jdv79 wrote:
> I updated to:
>
>
> [jdv@localhost ~]$ perl6 -v
> This is Ra
Great analysis!
The first issue seems to be already mentioned in RT #126112 (and I vaguely
recall one more ticket, but I'm failing to find it now).
This ticket seems to be getting a bit unmanageable, please file smaller tickets
for every issue you discover.
On 2017-08-10 21:36:34, b...@abrij.or
There was some progress on this. jnthn++
I guess the most promising commit regarding this issue is
https://github.com/MoarVM/MoarVM/commit/0d2e5f8cc0264eb495ea4f20f3a0c90d05d55710
, but there's at least one other commit that could've improved the situation (
https://github.com/rakudo/rakudo/commit
I think things would go faster with this one if it was golfed down.
Given the previous warnings saying “Use of uninitialized value $key of type Any
in string context.”, the issue is quite possibly in Uzu itself (or maybe even
Mustache). The ticket is of course valid because the error should not co
No bug with MVM_SPESH_DISABLE=1.
On 2017-08-07 19:48:36, ddgr...@gmail.com wrote:
> [22:44] m: sub foo(:color(:$colour)) { $colour + 1 }; my
> $s;
> for ^100 { $s += foo(:color($_)) }; say $s; say now - INIT now
> [22:44] <+camelia> rakudo-moar a91ad2: OUTPUT: «Unexpected named
> argument
> '
OK, this is still not resolved, but it got noticeably better.
The issue is reproducible with the snippet provided in the original report.
On 2017-08-11 10:01:42, alex.jakime...@gmail.com wrote:
> There was some progress on this. jnthn++
>
> I guess the most promising commit regarding this issue is
Bisected:
bisect: old=HEAD~300
https://gist.githubusercontent.com/AlexDaniel/1e2c456f006687ea7100a35b2931af41/raw/9aad30ec83728b43b5d1d134a4c0701354e2c8c5/nativehelpers-test.p6
AlexDaniel, Successfully fetched the code from the provided URL.
AlexDaniel, Bisecting by exit code (old=HEAD~300 new=
Note that the tests on 92bd7e4^ and 92bd7e4 are not very related to this
particular issue.
To put simply: it went from 58628 to 138220 because of changes related to this
commit (or maybe one or two commits before it):
https://github.com/rakudo/rakudo/commit/9658dd98c9dd8ecbefc606a08357e59718e328c2
TL;DR it went from 59820 to 215976 after this commit:
https://github.com/rakudo/rakudo/commit/92bd7e4f54a92fa660f99b4d056d33a08fb98bd2
Bisect log:
https://gist.github.com/678ce88a13272eab454a22568f3bddc7
On 2017-08-16 14:24:48, scoli...@gmail.com wrote:
> Similar to https://rt.perl.org/m/ticket/s
Also, it's not any different on HEAD:
committable6test: 9658dd98c9dd8ec^^,9658dd98c9dd8ec,HEAD say
"/proc/$*PID/statm".IO.lines[0].split(/\s/)[5] * 4096 / 1024
AlexDaniel, ¦9658dd98c9dd8ec^^: «58628» ¦9658dd9: «138220»
¦HEAD(3e70d44): «136436»
On 2017-08-16 14:27:37, alex.jakime...@gmail.com wr
https://irclog.perlgeek.de/perl6-dev/2017-08-17#i_15032963
On 2017-08-16 14:30:42, alex.jakime...@gmail.com wrote:
> TL;DR it went from 59820 to 215976 after this commit:
>
https://github.com/rakudo/rakudo/commit/92bd7e4f54a92fa660f99b4d056d33a08fb98bd2
>
> Bisect log:
> https://gist.github.com/67
This could've been a LHF, except for these tests:
https://github.com/perl6/roast/blob/4bfd6d2374cb4ea1b8fa057a5f294b988e4dec44/S32-exceptions/misc.t#L180-L185
¯\_(ツ)_/¯
But yes, I think it should say “slurpy” everywhere.
On 2017-08-18 07:10:52, comdog wrote:
> Consider this program which I don't
Another way to do it is to support custom nl (similarly to how we do
｢$*IN.nl-in = 0.chr｣ now). Split may be an overkill.
On 2017-08-18 08:40:32, c...@zoffix.com wrote:
> On Fri, 18 Aug 2017 08:35:18 -0700, alex.jakime...@gmail.com wrote:
> > Most command line tools support zero-separated input an
It was fixed in this commit:
https://github.com/MoarVM/MoarVM/commit/5363a0742d9ea7183200a747c2d7531e82bc5c71
samcv++
Tests needed.
On 2017-08-18 12:48:20, alex.jakime...@gmail.com wrote:
> The issue happens in Email::Simple (one of its tests is now failing,
> but it was ok in 2017.07).
>
> Here'
The change was moved to v6.d in this commit:
https://github.com/rakudo/rakudo/commit/d2278b471cb0bd691dc7a1235fbcb9318ff5d61f
On 2017-08-17 08:50:48, alex.jakime...@gmail.com wrote:
> See this commit:
>
https://github.com/rakudo/rakudo/commit/9501edae4f73a970e3270e3b0336a7b3045d3329
>
> These roas
I had to revert one of the nqp commits related to .parse:
https://github.com/perl6/nqp/commit/d4d77b66c46c57de800b147df61fe486b4486acd
Here's a ticket for the module that was affected by the change:
https://github.com/p6-css/CSS-Module-p6/issues/10
Most certainly we want this change back ASAP, bu
1 - 100 of 467 matches
Mail list logo
