I apologize if there was any tone to my post, the only place I
intended there to be any was when I pointed out the
--no-check-certificates flag. Please understand Perl 6 is the second
or third language I have found that does not secure its ecosystem. The
number of non-language projects which
Quoting R0b0t1 :
Are there any releases signed by the developers? The official releases
located at https://rakudo.perl6.org/downloads/star/ do not seem to
have signatures available.
There's Rakudo the compiler and Rakudo Star distribution
which is the compiler + docs + some
On 27 July 2017 at 09:13, R0b0t1 wrote:
> Are there any releases signed by the developers? The official releases
> located at https://rakudo.perl6.org/downloads/star/ do not seem to
> have signatures available.
Can you be more specific about the technologies you suggest and the
The details of how to use the star GitHub repository are in
tools/star/release_guide.pod .
You're entirely welcome to create a bundling that has a better build system
than what Rakudo Star uses -- indeed, Rakudo Star has always been intended to
be just one of many possible bundlings of Rakudo
Hi Robot,
Understanding your points, correlating them to past decisions, calling
up what the decisions actually were and their reasons, finding out which
of these reasons were good and which were bad - that's already a pretty
taxing task.
Now if you start out with a dismissive attitude such
Are there any releases signed by the developers? The official releases
located at https://rakudo.perl6.org/downloads/star/ do not seem to
have signatures available.
As a stopgap measure I attempted to clone
https://github.com/rakudo/star and run Configure.pl. I felt it strange
that it warned me
It’s really in the dispatch within Cool. Note the difference between:
for ^1 { 1.match(/1/) }
and:
for ^1 { "1".match(/1/) }
I’m afraid this is really uncovering a basic dispatch caching issue.
I have tried a few things, but I’m afraid this is really an issue inside
It’s really in the dispatch within Cool. Note the difference between:
for ^1 { 1.match(/1/) }
and:
for ^1 { "1".match(/1/) }
I’m afraid this is really uncovering a basic dispatch caching issue.
I have tried a few things, but I’m afraid this is really an issue inside
Oh! You're totally right!
Then, it's not as bad as it looks.
In fact, this commit actually *improved* the case when it has to match Str-s
(more than 2x speedup).
So perhaps the slowdown is not so critical. After all, how often do people
match thousands of Ints…
On 2017-07-26 23:55:21,
Looking at the profile of
(^1).grep({!/1/}).elems.say
the first 5 entries (responsible for 70% of CPU in that example) have nothing
to do with matching, but everything with trying to find the right dispatchee.
And it looks like this is basically caused by:
$_ = 1; /1/
Because $_
10 matches
Mail list logo