On Wednesday, July 21, William Michels wrote:
> Sorry for my continuing confusion, but I don't see any use-case for an
> "unspace" at the end of a line in the Raku REPL, or the Jupyter
> kernel.
A use case would be for instance, wanting to call a method
on the next line -- so wanting to unspace t
f the line, you can use
two backslashes."
https://github.com/bduggan/p6-jupyter-kernel#usage-notes
Sorry for my continuing confusion, but I don't see any use-case for an
"unspace" at the end of a line in the Raku REPL, or the Jupyter
kernel. Would this be useful for something
On Monday, July 19, William Michels via perl6-users wrote:
> I don't see how the Raku REPL knows how to cycle from taking input at its
> prompt and moving to the read/evaluate step.
This currently happens when the parser throws one of these exceptions:
X::Syntax::Missing
X::Comp::FailGoal
took a quick look at how three other languages (R, Python2.7, Ruby)
handle backslashes in their REPLs. None of the versions below are "the
latest and greatest", but it should give us an idea what (historically)
other languages have done. R balks at backslashes (but can accept
multi-line
On Wed, Jul 14, 2021 at 08:40:07AM -0700, William Michels via perl6-users wrote:
> > \
> {}
> > \\
> {}
> > \\\
> {}
> Curiously, I seem to create an object in my REPL environment when I enter
> either a single-, double-, or triple-backslash. ...
Your backslash destroys the newline so the inpu
Hi, I've recently updated my Rakudo installation, and I wanted to test
multi-line input in the REPL. By mistake I entered a backslash at the REPL
command line:
user@mbook:$ raku
Welcome to 𝐑𝐚𝐤𝐮𝐝𝐨™ v2021.06.
Implementing the 𝐑𝐚𝐤𝐮™ programming language v6.d.
Built on MoarVM version 2021.06.
To exit
# New Ticket Created by MoC
# Please include the string: [perl #68746]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=68746 >
Hi,
building latest Rakudo using latest Parrot fails on Windows XP with an
error, refer to CmdLo
Will Coleda wrote:
> Since both tcl and perl seem to like this style (but I'm sure some
> languages need truly native representations), I'd propose that the OS
> PMC give a way to say which is preferred.
I agree.
As another note, many programs are fine with forward slashes, including
Microsoft's
e
# Please include the string: [perl #39853]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39853 >
Test languages/tcl/t/cmd_pwd.t fails on Win32. Tcl's pwd returns the
path with backslashes, most likely because OS.cwd
ath with backslashes, most likely because OS.cwd does too, but the test
expects forward slashes, as the result is compared with Perl's Cwd::getcwd.
The "other" Tcl returns forward slashes, too.
C:\Tcl\bin>tclsh
% puts [pwd]
C:/Tcl/bin
I'm not sure if this should be changed in l
Larry Wall wrote :
>
> Well, if anything, we're going the other direction, and enriching what
> you can do with a backslash in single quotes slightly. But it ought
> to be pretty easy to define your own hyperquotes. We might also have
> options on quotes like we do on regexen. Then we could te
On Tue, 2002-05-21 at 13:22, Buddha Buck wrote:
> At 01:10 PM 05-21-2002 -0400, Aaron Sherman wrote:
> >The quesiton here is that C<\\'>, which means something different in
> >your recommendation than it means in Perl5, but still does the same
> >thing
>
> And the other question is how to ge
On 05/21/02 Aaron Sherman wrote:
> On Tue, 2002-05-21 at 12:57, Michael G Schwern wrote:
>
> > Here's an easier one: backslash followed by the delimiter is that thing.
> > Everything else is literal.
> >
> > print 'c:\it\'s\easier\to\write\win32\paths\this\way';
> > print q{this is ok {
At 01:10 PM 05-21-2002 -0400, Aaron Sherman wrote:
>On Tue, 2002-05-21 at 12:57, Michael G Schwern wrote:
>
> > Here's an easier one: backslash followed by the delimiter is that thing.
> > Everything else is literal.
> >
> > print 'c:\it\'s\easier\to\write\win32\paths\this\way';
> > print
On Tue, 2002-05-21 at 12:57, Michael G Schwern wrote:
> Here's an easier one: backslash followed by the delimiter is that thing.
> Everything else is literal.
>
> print 'c:\it\'s\easier\to\write\win32\paths\this\way';
> print q{this is ok { and so is \} } C:\this };
I desire you print y
On Tue, May 21, 2002 at 11:03:42AM +0100, Nicholas Clark wrote:
> I believe that the correct rule for single quote context in perl should have
> been that backslash followed by anything is that thing.
That leaves Win32 users stuck in the same rut as now:
print 'c:\\it\'s\\going\\to\\be\\hard
Luke Palmer writes:
: I'm sort of side-tracking from the trend of discussions, but I was just
: thinking that I always found it annoying how you had to double backslashes
: in single-quoted strings. I like the bash's behavior with regard to this
: much better... I mean, the whole i
On 5/20/02 8:04 PM, "Luke Palmer" <[EMAIL PROTECTED]>
claimed:
> 'You think I' _ q{'} _ 'm knit-picking!'
Ugh. If you really don't like back-slashing single quotes, do this:
q{You think I'm knit-picking!};
I would agree that in a q{} context, it is silly that a double-backslash
prints a single
I'm sort of side-tracking from the trend of discussions, but I was just
thinking that I always found it annoying how you had to double backslashes
in single-quoted strings. I like the bash's behavior with regard to this
much better... I mean, the whole idea behind single-quoted
at line 74)
# got: 'can't stat t/op/basic1.pbc, code 2
'
# expected: '42'
# Looks like you failed 1 tests of 2.
...
It looks like the backslashes in the path are being interpreted
incorrectly. I don't think the problem is in Configure; can somebody
look at
20 matches
Mail list logo
