Re: who own my code?

[Jan Ingvoldstad]

On Sun, Oct 22, 2017 at 10:32 PM, Brandon Allbery  wrote:
> This is still best discussed elsewhere... isn't there a stackexchange for
> this kind of stuff?

Ah, Stack Exchange, the quality site where the _first_ answer is the
most significant.

Anything else is better than asking people to go there for help.


-- 
Jan

Re: Is win 32 being worked on?

[Jan Ingvoldstad]

On Fri, Jul 21, 2017 at 10:50 AM, Todd Chester  wrote:
>
>
> On 07/21/2017 01:07 AM, Mark Carter wrote:
>>
>> I noticed that there is no Windows 32-bit version of rakudo, and it won't
>> even compile on cygwin.
>>
>> Are there plans for fixing this?
>
>
>
> Hi Mark,
>
> I may be wrong, but I do believe what you want is called
> "Rakudo Star".  You can download it from
>
> https://rakudo.perl6.org/downloads/star/

If you visit the link you provided, you will see that the Windows
installer is x86_64, there is no 32-bit version.

-- 
Jan

Re: Any text editors for programming that support the secondary selection clipboard?

[Jan Ingvoldstad]

Hah, I see that my original response only went to ToddAndMargo, how
dull-witted I must have been.

On Wed, Jun 21, 2017 at 10:13 PM, The Sidhekin  wrote:
>
> On Wed, Jun 21, 2017 at 1:35 PM, Luca Ferrari  wrote:
>>
>> > I like Geany, but it does not support the "Secondary Selection"
>> > clipboard.  This clipboard would save me a bunch of time as
>> > I would not lose my cursor hot spot.
>>
>> Emacs
>> 
>
>
>   Out of the box, this will move the cursor ("placing point at the end of
> the yanked text").  Precisely what the OP didn't want.
>
>   But hey, emacs is nothing if not customizable. :)
>
>   Just add to ~/.emacs (and eval the form, or restart emacs) the following
> or something like it (TIMTOWTDI):
>
> (advice-add 'mouse-yank-secondary :around
> #'(lambda (orig-fun &rest args)
> "Preserve point and mark and stuff"
> (save-excursion
>   (apply orig-fun args

There are some other tricks, too, sure:

https://www.emacswiki.org/emacs/SecondarySelection
-- 
Jan

Re: Perl 6 ignores SIGPIPE

[Jan Ingvoldstad]

On Fri, Jun 16, 2017 at 12:13 PM, Elizabeth Mattijsen 
wrote:
>
>
> Failed to write bytes to filehandle: Broken pipe
>   in block  at -e line 1
>
> So it would appear this got fixed by the synchronous IO refactor, and will
> be available in the 2017.06 release, which is scheduled for tomorrow.
>
>
>
This appears to be only a partial fix with an unexpected outcome.

awk, Perl 5, Ruby, etc. do not generate errors for similar use of pipes,
and instead use exit status 0.
-- 
Jan

Re: perl 5?

[Jan Ingvoldstad]

On Thu, Nov 17, 2016 at 8:08 AM, ToddAndMargo  wrote:

> Hi All,
>
> Would you guys tolerate a perl 5 question every so often?
>
>
Perl 5 questions that relate to Perl 6 would probably be on topic.

If what you want is help with Perl 5 for Perl 5's sake, though, I humbly
suggest that using one of the Perl 5 mailing lists, or IRC channels, may be
more useful to you.

See here for more information:

https://lists.perl.org/

http://www.irc.perl.org/channels.html

You may also find one of your local Perl communities helpful, see here for
more info about that:

https://www.perl.org/community.html
-- 
Jan

Re: A practical benchmark shows speed challenges for Perl 6

[Jan Ingvoldstad]

On Fri, Apr 1, 2016 at 2:00 PM, Elizabeth Mattijsen  wrote:

> Sorry if I wasn’t clear: If there is no dynamic var, it will make one:
> either from the environment, or set it to 64K (like it was before).  So no
> programmer action is ever needed if they’re not interested in that type of
> optimization.
>

That was abundantly clear.


> At the moment it is nothing but a balloon that I let go up in the air.
> Question is still out on whether this will continue to live until the next
> release, or that it will be replaced by something more low level, at the VM
> level.
>
> If you put garbage in the environment, it will die trying to coerce that
> to an integer.
>

Sorry for bringing that up, as it evidently confused the issue.

I'll try to explain the problem once again, with feeling ;) – hoping that
I'm being clearer this time.

Before:

The programmer knows that the buffer size is 64K unless the programmer asks
for something different. A typical Perl program reading buffered input does
not need to worry about anything, unless the programmer wants to have
smaller or larger buffers.

In other words: fire and forget.

Currently:

The programmer does not know what the buffer size is, as it can either be
the default, or set by an environment. Every program that was made under
the previous paradigm now needs to be modified to check the environment to
avoid undesired side effects.

Every future program also needs to include code that checks the environment
to avoid undesired side effects.

-- 
Jan

Re: A practical benchmark shows speed challenges for Perl 6

[Jan Ingvoldstad]

On Thu, Mar 31, 2016 at 10:36 AM, Elizabeth Mattijsen 
wrote:

> > The reasoning behind _not_ setting things via environment variables, is
> that this means the programmer now needs to worry what e.g. the webserver
> running the Perl program does, and there are unknown stability (and
> possibly security) implications. This adds bloat to the program.
> >
> > The programmer is better off if they only explicitly need to worry about
> it when they want to change the defaults.
>
> The environment variable is only used if there is no dynamic variable
> found.  So, if a programmer wishes to use a specific buffer size in the
> program, they can.


This is precisely _not_ addressing the issue I raised.

This way, the programmer _needs_ to explicitly check whether the
environment variable is set, and if not, somehow set a sensible default if
the environment variable differs from the default.

That adds quite a bit of unnecessary programming to each Perl program that
deals with buffers.

The status as it was before, was that the programmer didn't need to worry
about the environment for buffer size.

If a malicious environment sets the buffer size to something undesirable,
there may be side effects that are hard to predict, and may have other
implications than merely performance.

I think it is preferable that the decision about that is made by the
programmer rather than the environment.

PS: I'm assuming that $*DEFAULT-READ-ELEMS is clean by the time it reaches
any code, that is that it only contains _valid_ integer values and cannot
lead to overflows or anything, I am not concerned about that.
-- 
Jan

Re: A practical benchmark shows speed challenges for Perl 6

[Jan Ingvoldstad]

On Wed, Mar 30, 2016 at 9:20 PM, Elizabeth Mattijsen  wrote:
>
>
> Thanks for your thoughts!
>
> I’ve implemented $*DEFAULT-READ-ELEMS in
> https://github.com/rakudo/rakudo/commit/5bd1e .
>
> Of course, all of this is provisional, and open for debate and
> bikeshedding.
>
>
Brilliant and brilliantly quick response, Liz!

In the spirit of bikeshedding, my first thought is that the variable name
should have something with BUFFER in it, as that is what it appears to be.
:)

Functionally, it's nice to be able to set it via the environment, but since
the environment may not necessarily be controlled by the programmer, I
consider that to be a short term solution.

A longer term solution would be for a way to set it within the program that
the environment cannot override.

Additionally, there could also be a default, compile-time option for Rakudo.


The reasoning behind _not_ setting things via environment variables, is
that this means the programmer now needs to worry what e.g. the webserver
running the Perl program does, and there are unknown stability (and
possibly security) implications. This adds bloat to the program.

The programmer is better off if they only explicitly need to worry about it
when they want to change the defaults.
-- 
Jan

Re: What are Perl 6's killer advantages over Perl 5?

[Jan Ingvoldstad]

On Wed, Sep 2, 2015 at 3:51 AM, Robert Strahl via perl6-users <
perl6-users@perl.org> wrote:

> I don't understand why some people feel so strongly that one-liners should
> be strict. That would undermine what a one-liner is — a quick way to get
> something done. I use perl5 one-liners very frequently for text processing,
> especially when stringing / piping together shell code. When I need to
> re-use the code, then I put it into a script and make it strict and
> bulletproof in other ways. Declaring variables in the one-liner context
> makes no sense.
>
> Since the two sides of this debate will never see eye-to-eye on this, all
> I can ask is that there be an easy and top-level way to set the default
> strict or not_strict for one-liners. Perhaps a shell variable
> PERL6-ONE-LINERS-STRICT=<0|1>; , or -e -E as mentioned.
>

First, my apologies for not getting involved earlier, this discussion flew
below my radar.

I'm completely in agreement with your arguments, Robert, I don't see the
use for requiring strict for the command line by default.

Strict mode cripples Perl 6's usability for one-off scripts*.

Specifying -Mstrict or -e 'use strict;' is good enough for those cases when
you really need to be strict in one-off scripts.

Specifying -E instead of -e to do the same seems a good way to confuse
people, considering the apparent similarity to the Perl 5 options. There
are only so many context switches a human brain can handle.

* I don't like calling them one-liners, as they can be quite complex before
evolving into file-based scripts.

-- 
Jan

Re: Production Release - was Re: Questions for Survey about Perl

[Jan Ingvoldstad]

On Wed, Jan 5, 2011 at 17:30, Guy Hulbert  wrote:

> Rakudo is not listed here:
> http://shootout.alioth.debian.org/
> Fixing that is something I'd like to help with.
>
> Note that go was listed *before* it was announced.  That tells me that
> the go authors are, in some small way, more serious about their project
> "succeeding" than perl6.
>
> So your suggestion to Gabor is to add the question:

Do you think that NOT listing Rakudo at shootout.alioth.debian.org means
Rakudo is not a serious project?

Or did you have some other point?

(This is the first time I've seen shootout.alioth.debian.org, I won't claim
that it's not a serious shootout just because of that, BTW.)
-- 
Jan

Re: Can't download Rakudo Dec 2010 without git

[Jan Ingvoldstad]

On Tue, Jan 4, 2011 at 09:30, Daniel Carrera  wrote:

> That's rather annoying. Isn't there a way to fix that?
>

Yes, install Rakudo Star instead, that bundles a suitable version of Parrot.
-- 
Jan

Re: Questions for Survey about Perl

[Jan Ingvoldstad]

On Sun, Jan 2, 2011 at 19:02, Guy Hulbert  wrote:

> Many people seem to be proposing questions which ask people's opinions
> of things which are factual and can be answered readily by reading the
> documentation.
>
> For example, your question can be partly answered by looking at the
> rakudo download page.  There were about 3000 downloads of the July
> release (I was one) and since then there have been less than 1000 (not
> me) per month.
>

That tells us that there is a lower download rate, to be sure, and that
might indicate a lower rate uptake.

It does not, however, answer any of the question_s_ I wanted asked, and
which others have wanted asked, not even partially.

There is a difference between simplified statistical aggregates and getting
responses from human beings, which are then analyzed.

The way in which you ask a question can, of course, also introduce a bias in
how the response appears.

If you ask:

"Do you think Perl 6 will ever be production ready?"

you may have introduced a negative bias in the question.

But with careful phrasing - something I've been sloppy with in this thread,
I'm sorry to say - then you can (probably) get the information you want.
-- 
Jan

Re: Questions for Survey about Perl

[Jan Ingvoldstad]

On Sun, Jan 2, 2011 at 18:33, Guy Hulbert  wrote:

> On Sun, 2011-02-01 at 18:25 +0100, Jan Ingvoldstad wrote:
> > At least have the decency to change the e-mail subject when the
> > discussion's
> > subject has changed!
>
> IMO, the subject changed at the second post.  I was just responding to P
> Michaud who is the current principal developer of the s/w being
> discussed.
>
>
You guys stopped discussing the questionnaire a LONG time before PM
answered. There has hardly been a handful of helpful posts.

Getting back on topic, I, for one, would like to know how many people have
heard about Perl 6, and to what extent. I would like to know whether they
use it or not, and to what extent (already covered in some of the
suggestions), and I would like to know whether people like what they see or
not, and to which extent.
-- 
Jan

Re: Questions for Survey about Perl

[Jan Ingvoldstad]

On Sun, Jan 2, 2011 at 18:05, Guy Hulbert  wrote:

> On Sun, 2011-02-01 at 10:27 -0600, Patrick R. Michaud wrote:
> >   - What was the first production release of Linux?
> >   - At what point was each of the above declared a "production
> > release";
> > was it concurrent with the release, or some time afterwards?
>
> Linus declared what his goals for 1.0 were and started a 0.9x series.
>

… and so on.

While this meta discussion is all very nice, I don't really see what it has
to do with the questionnaire.

Gabor didn't ask us to discuss the answers to the questions, he asked us to
come up with more questions that we would like to see answered.

At least have the decency to change the e-mail subject when the discussion's
subject has changed!


-- 
Jan

Re: Perl6 Modules - Documentation

[Jan Ingvoldstad]

On Fri, Jul 30, 2010 at 11:27, Steffen Schwigon  wrote:

> Just an opinion: imho every effort should go towards integrating CPAN
> in any way.
>
> Perl without CPAN feels like Kung-Fu on stack-heel shoe.
>
> Maybe any of those META2.0, cpanminus, CPAN::Packager,
> CPAN::Dpendency, MyCPAN::*, POD6 thingies could be assembled into
> something to integrate Perl6 with CPAN?
>
> And, yes, I consider it valid to have a Perl5 toolchain doing that.
>

There is a problem with that, and that is that we may want to re-use the
same package names that are already in use on CPAN, in order to avoid evil
Klingon naming contortions (good Klingon naming contortions are of course
QaQ).

I also think that it's important packages are cryptographically signed by
their maintainers.
-- 
Jan

Re: very basic type checking

[Jan Ingvoldstad]

On Wed, Jun 23, 2010 at 20:21, Darren Duncan wrote:

> If all invocations of myop use a code literal for the $y argument, then
> this can be checked at compile time, but if the argument is a variable, they
> have to look further out.
>
>
Yup.

For those who don't quite see what this leads to, consider the Halting
Problem for why this looking around, out, in, between, sideways, back, and
forward must have cut-off points.

-- 
Jan

Re: Something wrong with str.reverse

[Jan Ingvoldstad]

On Mon, Jun 21, 2010 at 10:47, Smylers  wrote:

> Larry Wall writes:
>
> > On Fri, Jun 18, 2010 at 11:21:52AM +0200, Jan Ingvoldstad wrote:
> >
> > : On Fri, Jun 18, 2010 at 11:15, Smylers  wrote:
> > :
> > : > For the benefit of Perl 5 programmers used to string reverse it
> > : > would be nice to have a warning if reverse is invoked with exactly
> > : > one string argument (but not with an array which happens to
> > : > contain a string as its only element).
> > :
> > : Perhaps if one uses a "use P5warnings" or something?
> > :
> > : Such warnings can become quite awful as Perl 6 grows and matures.
>
> I was only thinking about that specific warning, not generally warnings
> that might be of use to Perl 5 programmers. And I don't see how warning
> about calling reverse on a scalar would be awful.
>
> It isn't something that makes sense to do (it's a no-op), and it isn't
> just former Perl 5 programmers who might make that mistake; anybody who
> does could be warned about it.
>

And that's my beef, really: adding warnings that are useful because of the
language itself is quite unproblematic, but adding warnings for the sake of
those who move from other languages -- even within the same family -- /can/
become awful. They don't necessarily have to be, but I would advise utmost
caution.

Also, it's important that there is consistency and consecution in warnings.

As pmichaud++ mentions in a followup response, there are several other cases
where warnings are not issued.

A rational consequence of adding a warning for .reverse used on string, is
to add a warning for other cases where it does not make sense (but which may
come as a surprise), and equally for the other cases (see pmichaud's list)
where built-in methods may be invoked by a similar misunderstanding.

Anyway, these are merely my personal opinions, I like to express them from
time to time, but I don't call the shots any more than you do!
-- 
A sextuple-acrostic post by Jan ;)

Re: Something wrong with str.reverse

[Jan Ingvoldstad]

On Fri, Jun 18, 2010 at 11:15, Smylers  wrote:

>
> For the benefit of Perl 5 programmers used to string reverse it would be
> nice to have a warning if reverse is invoked with exactly one string
> argument (but not with an array which happens to contain a string as its
> only element).
>

Perhaps if one uses a "use P5warnings" or something?

Such warnings can become quite awful as Perl 6 grows and matures.
-- 
Jan

Re: Iterate X times

[Jan Ingvoldstad]

On Sun, Sep 13, 2009 at 5:14 PM, Christian Sturm  wrote:

> Hi,
>
> do you know a short and easy way to iterate a block X times?
>

Here's one using the upto operator:

for ^$X {
$s *= $s;
}

-- 
Jan