Patrick R. Michaud writes:
> print will stringify its arguments and write them to $*OUT.
>
> say will invoke .gist on its arguments and write them (along with a
> final newline) to $*OUT.
Hi there. What's the rationale for the difference there?
Under what circumstances are each likely to be use
Oops, typo:
On Thu, Jun 28, 2012 at 11:39:22AM -0500, Patrick R. Michaud wrote:
> To get say to act like "print with a newline", one can do
>
> say [~] ar
That should be
say [~] arg1, arg2, arg3 ...
For the 'a'.WHAT case, this gives
> say [~] 'a'.WHAT
use of uninitialized valu
On Thu, Jun 28, 2012 at 09:41:48PM +0530, Siddhant Saraf wrote:
> (In Rakudo's REPL)
>
> > say 'a'.WHAT;
> Str()
> > print 'a'.WHAT;
> use of uninitialized variable $v of type Str in string context
> True
> >
>
> What is happening here? Is this a bug?
> ( Coz I don't see any $v variable anywhere
> May I also take this opportunity to ask someone to explain to me what
> exactly are the
> differences between say and print?
Might be that "say" calls ".gist" whereas "print" stringifies?
> May I also take this opportunity to ask someone to explain to me what
> exactly are the differences between say and print?
>
I can't help you with the tricky stuff, but the difference between
"say" and "print" is that "say" appends a newline (\n) to the output,
while "print" doesn't.
The \n is
(In Rakudo's REPL)
> say 'a'.WHAT;
Str()
> print 'a'.WHAT;
use of uninitialized variable $v of type Str in string context
True
>
What is happening here? Is this a bug? ( Coz I don't see any $v
variable anywhere.)
What is the "True" indicating?
(in niecza's REPL)
niecza> say 'a'.WHAT;
Str()
niecz
On Thu, Jun 28, 2012 at 6:00 PM, Moritz Lenz wrote:
> FWIW the reason I always use git:// over https:// is that at some point
> cloning from github via https:// would result in strange errors on the
> client side (iirc something about missing objects).
>
> I have no idea if that's fixed, but I hav
FWIW the reason I always use git:// over https:// is that at some point
cloning from github via https:// would result in strange errors on the
client side (iirc something about missing objects).
I have no idea if that's fixed, but I haven't seen a reason to change
back to https either.
Am 28
On Thu, Jun 28, 2012 at 5:15 PM, Tadeusz Sośnierz
wrote:
> On Thursday, June 28, 2012 14:32:58 Gabor Szabo wrote:
>> In panda all the projects, where there is a source URL, are listed with
>> their git:// url except of https://github.com/perlpilot/p6-File-Temp.git
> Where is that?
in projects.jso
On Thursday, June 28, 2012 14:32:58 Gabor Szabo wrote:
> In panda all the projects, where there is a source URL, are listed with
> their git:// url except of https://github.com/perlpilot/p6-File-Temp.git
Where is that?
> I am just wondering why, and if it would not be better if that was
> also usi
In panda all the projects, where there is a source URL, are listed with their
git:// url except of https://github.com/perlpilot/p6-File-Temp.git
I am just wondering why, and if it would not be better if that was
also using git://
Some project have no source URL:
- Druid
- GGE
- HTML::Template
- L
On Thu, Jun 28, 2012 at 12:18 PM, Moritz Lenz wrote:
> Hi,
>
> Am 28.06.2012 11:09, schrieb Gabor Szabo:
>
>> I have all kinds of values in %*ENV but %*ENV is not there
>> while echo $HISTFILE has value.
>>
>> Is this a bug or my misunderstanding?
>
>
> Maybe $HISTFILE is an internal variable in y
Hi,
Am 28.06.2012 11:09, schrieb Gabor Szabo:
I have all kinds of values in %*ENV but %*ENV is not there
while echo $HISTFILE has value.
Is this a bug or my misunderstanding?
Maybe $HISTFILE is an internal variable in your shell, not an
environment variable? Try
export HISTFILE
perl6 -e 's
Hi,
I have all kinds of values in %*ENV but %*ENV is not there
while echo $HISTFILE has value.
Is this a bug or my misunderstanding?
regards
Gabor
14 matches
Mail list logo
