On Wed, 28 Dec 2016 08:30:34 -0800, c...@zoffix.com wrote:
> $ ./perl6 -e $'class C { method foo { say 10 } }; foo C.new:\n'
> ===SORRY!=== Error while compiling -e
> Undeclared routine:
> foo used at line 1
>
> $ ./perl6 -v
> This is Rakudo version 2016.12-122-gd35efb6 built on MoarVM version
I'm shocked to see \r\n→\n translation being defended without any reasoning.
Why are we doing it at all?
“\r\n => \n transformation is done consistently” consistently what? And why?
Even .IO.lines splitting on \r\n is wrong because it cuts \r that may be part
of the data (which is fine in the midd
Am 28.09.2017 um 15:44 schrieb brian d foy (via RT):
> And, that's not bake any other geopolitical oppositions into the
> language either. The Texas metaphor was a joke about that an American
> stereotype and you shouldn't go further with it.
Given that even good-natured humor occasionally gets mi
Am 28.09.2017 um 15:44 schrieb brian d foy (via RT):
And, that's not bake any other geopolitical oppositions into the
language either. The Texas metaphor was a joke about that an American
stereotype and you shouldn't go further with it.
Given that even good-natured humor occasionally gets misun
Possibly the right thing here is for perl 6 to reserve the name for
implementations, and otherwise leave it unspecced.
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb...@sinenomine.net
unix, openafs, kerber
Possibly the right thing here is for perl 6 to reserve the name for
implementations, and otherwise leave it unspecced.
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb...@sinenomine.net
unix, openafs, kerber
On Thu, 28 Sep 2017 06:44:12 -0700, comdog wrote:
> And, that's not bake any other geopolitical oppositions into the
> language either. The Texas metaphor was a joke about that an American
> stereotype and you shouldn't go further with it.
>
> https://rt.perl.org/Public/Bug/Display.html?id=132176
On Thu, 28 Sep 2017 06:44:12 -0700, comdog wrote:
> And, that's not bake any other geopolitical oppositions into the
> language either. The Texas metaphor was a joke about that an American
> stereotype and you shouldn't go further with it.
>
> https://rt.perl.org/Public/Bug/Display.html?id=132176
s:g/Mexico/Fancy Unicode/;
per RT#132179: https://rt.perl.org/Ticket/Display.html?id=132179#ticket-history
s:g/Mexico/Fancy Unicode/;
per RT#132179: https://rt.perl.org/Ticket/Display.html?id=132179#ticket-history
Would it be fair to describe that as "rendering unto the system
software that which belongs to the system, and unto the user that
which properly belongs to the application"?
(Which, in my opinion, is a principle neglected far too often by
programmers who've been taught to write OSs, but have to so
Would it be fair to describe that as "rendering unto the system
software that which belongs to the system, and unto the user that
which properly belongs to the application"?
(Which, in my opinion, is a principle neglected far too often by
programmers who've been taught to write OSs, but have to so
# New Ticket Created by "brian d foy"
# Please include the string: [perl #132179]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132179 >
And, that's not bake any other geopolitical oppositions into the
language either. The Te
That makes sense. Thanks for the thorough explanation.
Brian
On Fri, 22 Sep 2017 16:40:35 -0700, b...@abrij.org wrote:
>
> We've had a native 'str' type for a while, and still have one even
> though NativeCall decided to go with Str and 'is encoded'.
>
It's not native in the sense of same sense that NativeCall uses the word.
> Currently it seems to just b
On Fri, 22 Sep 2017 16:40:35 -0700, b...@abrij.org wrote:
>
> We've had a native 'str' type for a while, and still have one even
> though NativeCall decided to go with Str and 'is encoded'.
>
It's not native in the sense of same sense that NativeCall uses the word.
> Currently it seems to just b
On Tue, 26 Sep 2017 12:33:21 -0700, bdug...@matatu.org wrote:
> When I export a function that does a fork() and then
> a react + whenever + IO::Socket::Async.listen in the
> child process, the process only seems to be listening
> on the socket the second time I run the code, i.e. only
> after .prec
On Tue, 26 Sep 2017 12:33:21 -0700, bdug...@matatu.org wrote:
> When I export a function that does a fork() and then
> a react + whenever + IO::Socket::Async.listen in the
> child process, the process only seems to be listening
> on the socket the second time I run the code, i.e. only
> after .prec
# New Ticket Created by Zoffix Znet
# Please include the string: [perl #132176]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132176 >
During a recent update[^1] the static optimizer was taught to convert the
Mexico ≥, ≤, an
19 matches
Mail list logo
