Re: Naming debate- what's the location for it?

[vijayvithal jahagirdar]

Marketing is not only about branding. It is also about finding Evangelists.
Perl's traditional base was in

   - Web Development,
   - Text Processing,
   - Bio-Informatics and
   - As a general glue language among the sys admin and EDA community.

How many of these sectors are moving away or have moved away from Perl?
What is the game plan for bringing them back?

   - How many courses are there today on Coursera or Other MOOCS which use
   Perl to teach one of the above?
   - If I wanted to learn something new today, rather than plod through 300
   pages of a book I would signup for a course and spend the time in watching
   the course material and doing the assignments.
   - When I wanted to learn DataScience, courses using R and Python were
   readily available. Even though I had been using Perl for 20 years, I did
   not even know where to start in the Perl ecosystem!

I believe along with re branding we also need powerful narratives about how
Modern Perl and P6 are better than their competitors in the selected
domains.

Regards

Vijay

On Sat, Feb 17, 2018 at 3:26 AM, Darren Duncan 
wrote:

> If we assume the use of NQP is part of the project's identity, then yes
> that makes sense.  Historically that wasn't the case, eg the earlier Rakudo
> were written to Parrot PIR directly, and there's the possibility this could
> change again, though I see that as unlikely.  Not a bad idea. -- Darren
> Duncan
>
> On 2018-02-16 3:07 AM, Lloyd Fournier wrote:
>
>> I'm about to publish some blog posts with using Perl 6  to demonstrate
>> some cryptographic primitives. I was thinking about calling it "rakudo" to
>> at least intrigue people and make them google it. Couldn't we call the
>> language rakudo and the implementation nqp-rakudo? (ie a rakudo
>> implementation in nqp)
>>
>> LL
>>
>>
>> On Thu, Feb 15, 2018 at 5:02 AM Patrick R. Michaud wrote:
>>
>> On Wed, Feb 14, 2018 at 05:55:54PM +, raiph mellor wrote:
>>  > (Perl) Rakudo
>>  > ===
>>  >
>>  > If jnthn and pmichaud and larry can warm to this idea, then:
>>  > [...]
>>  > The 'Perl' could be dropped from Rakudo specific propaganda,
>>  > calling the language just Rakudo instead, to reinforce that it
>> refers
>>  > to 6e and beyond. But the Perl could be retained in any material
>>  > covering both Raptor and Rakudo as a reunified tech / community.
>>
>> FWIW, I am VERY MUCH AGAINST the idea of naming a language after its
>> implementation.  I've seen the confusion it causes in other
>> environments and
>> we ought not repeat that mistake here, especially since we don't have
>> to.
>>
>> Whatever things end up being called, don't confuse the
>> implementation(s)
>> with the language definition.
>>
>> Pm
>>
>>


-- 
https://www.facebook.com/vijayvithal.jahagirdar
https://twitter.com/jahagirdar_vs
http://democracies-janitor.blogspot.in/

Re: A proposal for Perl's branding - let's free all the butterflies

[Nigel Hamilton]

> Here is a suggestion for Perl's branding:
>>
>> http://nigelhamilton.com/perl-branding-proposal.html
>>
>
> I like your proposal.
>
>

:-)


> But its details would need fleshing out more, particularly at the end,
> where it says this:
>
> Perl $new_runtime_name_for_perl5_goes_here (tm)
> Perl $new-runtime-name-for-perl6-goes-here (tm)
>
>
This was just to highlight the need for different $runtime names to avoid
collisions on the command-line.

You make a good point about the language $dialect name - this may or may
not be the same as the $runtime name.

The proposal has been updated now:

http://nigelhamilton.com/perl-branding-proposal.html

Re: A proposal for Perl's branding - let's free all the butterflies

[Darren Duncan]

On 2018-02-16 11:15 AM, Nigel Hamilton wrote:

Here is a suggestion for Perl's branding:

http://nigelhamilton.com/perl-branding-proposal.html


I like your proposal.

But its details would need fleshing out more, particularly at the end, where it 
says this:


Perl $new_runtime_name_for_perl5_goes_here (tm)
Perl $new-runtime-name-for-perl6-goes-here (tm)

That implies that the only things being branded this way are runtimes, and not 
the languages themselves, which I thought was meant to be under that umbrella.


So for example:

Perl $new_language_name_for_perl5_goes_here (tm)
Perl $new-language-name-for-perl6-goes-here (tm)

-- Darren Duncan

Re: Naming debate- what's the location for it?

[Darren Duncan]

If we assume the use of NQP is part of the project's identity, then yes that 
makes sense.  Historically that wasn't the case, eg the earlier Rakudo were 
written to Parrot PIR directly, and there's the possibility this could change 
again, though I see that as unlikely.  Not a bad idea. -- Darren Duncan


On 2018-02-16 3:07 AM, Lloyd Fournier wrote:
I'm about to publish some blog posts with using Perl 6  to demonstrate some 
cryptographic primitives. I was thinking about calling it "rakudo" to at least 
intrigue people and make them google it. Couldn't we call the language rakudo 
and the implementation nqp-rakudo? (ie a rakudo implementation in nqp)


LL


On Thu, Feb 15, 2018 at 5:02 AM Patrick R. Michaud wrote:

On Wed, Feb 14, 2018 at 05:55:54PM +, raiph mellor wrote:
 > (Perl) Rakudo
 > ===
 >
 > If jnthn and pmichaud and larry can warm to this idea, then:
 > [...]
 > The 'Perl' could be dropped from Rakudo specific propaganda,
 > calling the language just Rakudo instead, to reinforce that it refers
 > to 6e and beyond. But the Perl could be retained in any material
 > covering both Raptor and Rakudo as a reunified tech / community.

FWIW, I am VERY MUCH AGAINST the idea of naming a language after its
implementation.  I've seen the confusion it causes in other environments and
we ought not repeat that mistake here, especially since we don't have to.

Whatever things end up being called, don't confuse the implementation(s)
with the language definition.

Pm

A proposal for Perl's branding - let's free all the butterflies

[Nigel Hamilton]

Here is a suggestion for Perl's branding:

http://nigelhamilton.com/perl-branding-proposal.html

[perl #132874] writing to utf16 handle gives write_fhb error

[Zoffix Znet via RT]

On Fri, 16 Feb 2018 00:56:27 -0800, comdog wrote:
> This little program:
> 
> my $fh = open 'test.txt', :w, :enc('utf16');
> put "filehandle is using {$fh.encoding}";
> $fh.put: 'Some text';
> 
> Gives this error:
> 
> filehandle is using utf16
> write_fhb requires a native array of uint8 or int8
> 
> 
> This is Rakudo Star version 2018.01 built on MoarVM version 2018.01
> implementing Perl 6.c


Looks like MoarVM doesn't fully support utf-16 yet (the exception is from 
MVM_io_read_bytes that just throws unless it's handed a 8-bit buf)

Slightly golfed version:

$ ./perl6 -e '"t.t".IO.open(:w :bin).write: utf16.new: 1, 2, 3'
write_fhb requires a native array of uint8 or int8
  in block  at -e line 1

$ ./perl6 -e '"t.t".IO.open(:w :bin).write: utf32.new: 1, 2, 3'
write_fhb requires a native array of uint8 or int8
  in block  at -e line 1

$ ./perl6 -e '"t.t".IO.open(:w :bin).write: buf32.new: 1, 2, 3'
write_fhb requires a native array of uint8 or int8
  in block  at -e line 1

Dies on read too, but with a more useful message:

$ ./perl6 -e '"LICENSE".IO.open(:enc).slurp.say'
Streaming decode NYI for encoding 4
  in block  at -e line 1

Works fine on JVM backend.

[perl #132874] writing to utf16 handle gives write_fhb error

[Zoffix Znet via RT]

On Fri, 16 Feb 2018 00:56:27 -0800, comdog wrote:
> This little program:
> 
> my $fh = open 'test.txt', :w, :enc('utf16');
> put "filehandle is using {$fh.encoding}";
> $fh.put: 'Some text';
> 
> Gives this error:
> 
> filehandle is using utf16
> write_fhb requires a native array of uint8 or int8
> 
> 
> This is Rakudo Star version 2018.01 built on MoarVM version 2018.01
> implementing Perl 6.c


Looks like MoarVM doesn't fully support utf-16 yet (the exception is from 
MVM_io_read_bytes that just throws unless it's handed a 8-bit buf)

Slightly golfed version:

$ ./perl6 -e '"t.t".IO.open(:w :bin).write: utf16.new: 1, 2, 3'
write_fhb requires a native array of uint8 or int8
  in block  at -e line 1

$ ./perl6 -e '"t.t".IO.open(:w :bin).write: utf32.new: 1, 2, 3'
write_fhb requires a native array of uint8 or int8
  in block  at -e line 1

$ ./perl6 -e '"t.t".IO.open(:w :bin).write: buf32.new: 1, 2, 3'
write_fhb requires a native array of uint8 or int8
  in block  at -e line 1

Dies on read too, but with a more useful message:

$ ./perl6 -e '"LICENSE".IO.open(:enc).slurp.say'
Streaming decode NYI for encoding 4
  in block  at -e line 1

Works fine on JVM backend.

[perl #130020] [RFC][@LARRY] Create a set of conventions to minimize impact internal changes to user's code

[Aleks-Daniel Jakimenko-Aleksejev via RT]

On 2018-02-16 09:01:57, c...@zoffix.com wrote:
> On Fri, 16 Feb 2018 05:52:09 -0800, elizabeth wrote:
> > I propose we change all onlies in the core to multis after the release
> > and see how this breaks things / makes things slower.
>
> +1. Let's try.

Yeah, sounds good. +1

[perl #130020] [RFC][@LARRY] Create a set of conventions to minimize impact internal changes to user's code

[Zoffix Znet via RT]

On Fri, 16 Feb 2018 05:52:09 -0800, elizabeth wrote:
> I propose we change all onlies in the core to multis after the release
> and see how this breaks things / makes things slower.

+1. Let's try.

[perl #130020] [RFC][@LARRY] Create a set of conventions to minimize impact internal changes to user's code

[Zoffix Znet via RT]

On Fri, 16 Feb 2018 05:52:09 -0800, elizabeth wrote:
> I propose we change all onlies in the core to multis after the release
> and see how this breaks things / makes things slower.

+1. Let's try.

Re: [perl #130020] [RFC][@LARRY] Create a set of conventions to minimize impact internal changes to user's code

[Elizabeth Mattijsen via RT]

I propose we change all onlies in the core to multis after the release and see 
how this breaks things / makes things slower.

> On 16 Feb 2018, at 14:17, Zoffix Znet via RT  
> wrote:
> 
> Spotted another case where there's impact: whether or not a routine is a 
> multi can have large impact on user's code. For example here: 
> https://stackoverflow.com/questions/48819031/where-did-my-perl-6-operator-go-after-i-defined-a-more-specific-multi/48827522
> 
> As part of conventions, we'd need to also figure out what we'll declare as 
> multies and what as onlies.

Re: [perl #130020] [RFC][@LARRY] Create a set of conventions to minimize impact internal changes to user's code

[Elizabeth Mattijsen]

I propose we change all onlies in the core to multis after the release and see 
how this breaks things / makes things slower.

> On 16 Feb 2018, at 14:17, Zoffix Znet via RT  
> wrote:
> 
> Spotted another case where there's impact: whether or not a routine is a 
> multi can have large impact on user's code. For example here: 
> https://stackoverflow.com/questions/48819031/where-did-my-perl-6-operator-go-after-i-defined-a-more-specific-multi/48827522
> 
> As part of conventions, we'd need to also figure out what we'll declare as 
> multies and what as onlies.

[perl #130020] [RFC][@LARRY] Create a set of conventions to minimize impact internal changes to user's code

[Zoffix Znet via RT]

Spotted another case where there's impact: whether or not a routine is a multi 
can have large impact on user's code. For example here: 
https://stackoverflow.com/questions/48819031/where-did-my-perl-6-operator-go-after-i-defined-a-more-specific-multi/48827522

As part of conventions, we'd need to also figure out what we'll declare as 
multies and what as onlies.

[perl #130020] [RFC][@LARRY] Create a set of conventions to minimize impact internal changes to user's code

[Zoffix Znet via RT]

Spotted another case where there's impact: whether or not a routine is a multi 
can have large impact on user's code. For example here: 
https://stackoverflow.com/questions/48819031/where-did-my-perl-6-operator-go-after-i-defined-a-more-specific-multi/48827522

As part of conventions, we'd need to also figure out what we'll declare as 
multies and what as onlies.

Re: Naming debate- what's the location for it?

[Lloyd Fournier]

I'm about to publish some blog posts with using Perl 6  to demonstrate some
cryptographic primitives. I was thinking about calling it "rakudo" to at
least intrigue people and make them google it. Couldn't we call the
language rakudo and the implementation nqp-rakudo? (ie a rakudo
implementation in nqp)

LL


On Thu, Feb 15, 2018 at 5:02 AM Patrick R. Michaud 
wrote:

> On Wed, Feb 14, 2018 at 05:55:54PM +, raiph mellor wrote:
> > (Perl) Rakudo
> > ===
> >
> > If jnthn and pmichaud and larry can warm to this idea, then:
> > [...]
> > The 'Perl' could be dropped from Rakudo specific propaganda,
> > calling the language just Rakudo instead, to reinforce that it refers
> > to 6e and beyond. But the Perl could be retained in any material
> > covering both Raptor and Rakudo as a reunified tech / community.
>
> FWIW, I am VERY MUCH AGAINST the idea of naming a language after its
> implementation.  I've seen the confusion it causes in other environments
> and we ought not repeat that mistake here, especially since we don't have
> to.
>
> Whatever things end up being called, don't confuse the implementation(s)
> with the language definition.
>
> Pm
>

[perl #132874] writing to utf16 handle gives write_fhb error

[brian d foy]

# New Ticket Created by  "brian d foy" 
# Please include the string:  [perl #132874]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=132874 >


This little program:

my $fh = open 'test.txt', :w, :enc('utf16');
put "filehandle is using {$fh.encoding}";
$fh.put: 'Some text';

Gives this error:

filehandle is using utf16
write_fhb requires a native array of uint8 or int8


This is Rakudo Star version 2018.01 built on MoarVM version 2018.01
implementing Perl 6.c