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  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-us...@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: Language design

[Jan Ingvoldstad]

On Tue, Jul 14, 2015 at 12:04 AM, Michael Zedeler mich...@zedeler.dk
wrote:

 So far, almost every other language has behaved this way, and it has
 worked. I can see that Rats do solve a problem, but if you'd claim that it
 is very severe then I'd disagree. This is a minor nuisance that I'd only
 pay a small price to fix.


People who use your lovely example – spreadsheets – tend to disagree.

There was a LOT of noise about how Excel handled numbers in a very
surprising manner, every time a new problem came up.

There are a gazillion articles about how to avoid it, and people who deal
with spreadsheets spend inordinate amounts of time to get around it.

Or they take the performance hit for asking for the precision of numbers
as displayed.

For more information, please see here:

https://support.microsoft.com/en-us/kb/78113

The minor nuisance is not so minor out there in the real world, where
people use actual applications where they _expect_ WYSIWYG numbers.

Now, what Rats solve for us programmers, is that it makes it easier for us
to avoid these pitfalls, and thereby makes it easier for us to cater for
our users.
-- 
Jan

Re: Licensing: Perl 6 specification and test suite

[Jan Ingvoldstad]

On Tue, Nov 5, 2013 at 3:09 PM, Kalinni Gorzkis
musicdenotat...@gmail.comwrote:

 Can I distribute and modify the Perl 6 specification documents and test
 suite under which conditions? If not, I propose that they should be
 distributed under the Artistic License 2.0.


That is an excellent question.

I've checked the git sources, and from what I can see, the examples
repository is under AL 2.0, as is STD.pm, but the synopses are not.

I'm unsure as to whether this is an artifact of how things got added to the
git repository or not, perhaps someone else can clarify.
-- 
Jan

Re: Licensing: Perl 6 specification and test suite

[Jan Ingvoldstad]

On Tue, Nov 5, 2013 at 3:36 PM, Moritz Lenz mor...@faui2k3.org wrote:

 I have no idea if the AL2 is well suited for sets of documents, as the
 specification is. I'll leave that decision to Larry.


To anyone in doubt: please note that I'm not Larry, I'm not an authority,
I'm just opinionated. :)

Considering that the specification is sortof actually a language
specification, I think there should at least be some terms regarding how
this should apply.

Forking the documentation, or creating derivative works, shouldn't be a
problem, as long as it doesn't change the specification in itself, and
thereby create confusion regarding what the Perl 6 specification is.

Technically speaking, there shouldn't be a problem with pulling the Git
repository, making changes, and proposing that these changes should be
merged with the central Git repository for the specification – that is,
after all, an approximation of how the specification is changed and
developed by the community.
-- 
Jan

Re: Underscores v Hyphens (Was: [perl6/specs] a7cfe0: [S32] backtraces overhaul)

[Jan Ingvoldstad]

On Wed, Aug 24, 2011 at 11:19, Smylers smyl...@stripey.com wrote:


 Could we have underscores and hyphens mean the same thing? That is, Perl
 6 always interprets illo-figut and illo_figut as being the same
 identifier (both for its own identifiers and those minted in programs),
 with programmers able to use either separator on a whim?

 That would seem to be the most human-friendly approach.


I'm not so sure about the human-friendliness, but it certainly would be more
obfuscation-friendly and less editor- and search-friendly.

-- 
Jan

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

[Jan Ingvoldstad]

On Wed, Jan 5, 2011 at 17:30, Guy Hulbert gwhulb...@eol.ca 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 dcarr...@gmail.com 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 18:05, Guy Hulbert gwhulb...@eol.ca 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!

/curmudgeon
-- 
Jan

Re: Questions for Survey about Perl

[Jan Ingvoldstad]

On Sun, Jan 2, 2011 at 18:33, Guy Hulbert gwhulb...@eol.ca 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 19:02, Guy Hulbert gwhulb...@eol.ca 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: [perl6/specs] 761178: remove some some duplicate words words

[Jan Ingvoldstad]

On Wed, Sep 8, 2010 at 07:41, Jason Switzer jswit...@gmail.com wrote:


 I'm surprised anyone actually ever read the diff part of the message. I
 would prefer to never see that feature again. This has a link to the
 commit,
 which has a much better diff viewer than plaintext email (hello? 1997
 called, they want their change notices back).


In some respects, I want 1997 back, since people learned how to work
efficiently rather than not. ;)

I both like and can read the contextual diffs just fine.


 It links to the actual change
 and even highlights the changes.


Yes, it's all very nice, and nothing that needs to go away. Having it both
ways can't hurt.


 Now I'll actually take a moment to sift
 through the changes. I vote to never see those diff emails ever again. In
 fact, if the diffs are brought back, I'll just subscribe to the commit feed
 and skip the email notice all together.

 That seems like a reasonable solution for you, then.
-- 
Jan

Re: rakudo star performance

[Jan Ingvoldstad]

On Fri, Jul 30, 2010 at 23:31, Ben Bowers nanobow...@gmail.com wrote:

 I've compiled and run rakudo star on a couple of pieces of code that i
 wrote.
 One generates random strings with pick.  the other builds a couple of
 hashes and checks to find commonality between them.
 Compared with Rakudo Moscow (April release), both pieces of code run
 about 50% slower with Rakudo Star.


Could you post the code in question, so that the Smart Guys (that does not
include me, I'm afraid) can have a poke at it?


 For reference, similar functioning code in perl5.8 is at least an
 order of magnitude (or more) faster than either of my perl6 testcases.

 I also noticed that my binary size is much smaller for perl5 than
 perl6: (linux x86_64)
 perl5.8.8 : 1.5MB
 rakudo moscow : 20MB
 rakudo star : 27MB


 The point this is that i'm not sure if i'm compling it properly.
 Possibly the amount of debug is set to the max level?
 Is there anything i can do to optimize the compile for increased
 performance?


Chromatic tried to say something about optimization in his response to a
performance comparison:

http://www.modernperlbooks.com/mt/2010/07/an-accurate-comparison-of-perl-5-and-rakudo-star.html


-- 
Jan

Re: Perl6 Modules - Documentation

[Jan Ingvoldstad]

On Fri, Jul 30, 2010 at 11:27, Steffen Schwigon s...@renormalist.net 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: [perl #76626] [PATCH] Generate plaintext README from README.pod

[Jan Ingvoldstad]

On Wed, Jul 28, 2010 at 19:09, Will Coleda w...@coleda.com wrote:

 On Wed, Jul 28, 2010 at 12:48 PM, Patrick R. Michaud pmich...@pobox.com
 wrote:

  I said a bit more about it as well:  I think we should just eliminate
  the pod from the README file altogether, and leave it as plain text.


Ah, well, since that was what I wanted to achieve, I have nothing but
positive feelings regarding that.

I had just (mis?)understood it as a desirable feature to have a POD version.

Done in fe29cde77e63c798bc7cf2a8c764d9ed012f2d27


Impressively quick.

I didn't want to press the issue at this time, since I think it's a minor
thing compared to all the other things being done to get Rakudo * going. :)
-- 
Jan

Re: [perl #76626] [PATCH] Generate plaintext README from README.pod

[Jan Ingvoldstad]

On Sat, 24 Jul 2010 10:29:42 -0700, Moritz Lenz via RT 
perl6-bugs-follo...@perl.org said:

 Thank you for your patch.
 I know I promised to apply it, but pmichaud++, our pumpking, spoke out
 against it, indicating that having now file named README in a newly
 checked out repository was not desirable. So with regret I have to
 reject your patch.

Thanks for the feedback.

I'll take the discussion on #perl6.  :)

-- 
In the beginning was the Bit, and the Bit was Zero.  Then Someone
said, Let there be One, and there was One.  And Someone blessed them,
and Someone said unto them, Be fruitful, and multiply, and replenish
the Word and subdue it: and have dominion over every thing that is.

Radix (base) conversion

[Jan Ingvoldstad]

Hi.

I was fiddling about with a small example of how nice radix adverbials are
for conversion:

my $x = 6*9;
say :13($x);

rakudo: 69

($x = 54 in base 10, but 54 in base 13 is 69 in base 10.)

Strangely enough, I cannot find a way — in the spec — of both treating a
number as something in base 13 as well as displaying it in base 13.

sprintf() has formats for binary, octal and hexadecimal, but there appears
no way to use an arbitrary base.

As a clarification, see this example form bc(1):

obase=13
print What do you get when you multiply six by nine? ; 6*9
What do you get when you multiply six by nine? 42
obase=10


Am I missing something?


It is also somewhat confusing that while $x stores the result of the
multiplication of 6*9, the adverbial radix conversion treats the variable as
a literal and no longer a value.
-- 
Jan

Re: very basic type checking

[Jan Ingvoldstad]

On Wed, Jun 23, 2010 at 20:21, Darren Duncan dar...@darrenduncan.netwrote:

 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 smyl...@stripey.com 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 smyl...@stripey.com 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 smyl...@stripey.com 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: Proposal for a new Temporal time-measurement paradigm

[Jan Ingvoldstad]

On Sun, Apr 25, 2010 at 00:46, Darren Duncan dar...@darrenduncan.netwrote:

 All details specific to any calendar, including Gregorian, including
 concepts like seconds or hours or days, should be left out of the core and
 be provided by separate modules.  Said modules can be self-contained, just
 say using Perl's ordinary numeric and string types for internal
 representation, and Perl's single core now() routine they can use to
 determine the current datetime, and the module can introspect its result or
 calendar() and figure out how to map that to the internal representation or
 API it wants to use, as well as figure out the proper way to invoke sleep().


I think you're taking minimalism at least two steps too far; your bikeshed
has become too small to contain a bike.

A standard library can and should provide reasonable functionality.

We _know_ that the North-Western civilizations' common understanding of time
(calendars and time-of-day), as defined in various standards, are
fundamental to how we handle a lot of programming problems.

I don't see any good reason not to provide the basic functionality needed,
and especially not when it's already there.
-- 
Jan

Re: Proposal for a new Temporal time-measurement paradigm

[Jan Ingvoldstad]

On Sun, Apr 25, 2010 at 02:31, Doug McNutt dougl...@macnauchtan.com wrote:

 Agree on a format for storing fractional atomic seconds. There are
 proposals for two word integers with one of them being micro or nano seconds
 and the other seconds.  I prefer IEEE floating point with atomic seconds as
 the unit of measure.  That's a bit like MS Excel where days are used for the
 unit. The Excel scheme is not as clean because it assumes 86400 seconds in a
 day and it's a day off between what it thinks was Feb 29, 1900 and its epoch
 at the start of 1900.


The Excel scheme is nowhere as clean as you think it is, because there is no
_single_ Excel scheme. There are two epochs, one is the buggy 1900 epoch,
the other is the 1904 epoch. In addition, there's an extended date format,
which doesn't handle the Julian - Gregorian transition very well.

You'd be hard pressed to find a worse example of how to handle dates than
Excel.
-- 
Jan

Re: Gripes about Pod6 (S26)

[Jan Ingvoldstad]

On Fri, Feb 12, 2010 at 14:57, Carl Mäsak cma...@gmail.com wrote:

 Again, thanks for your efforts so far. The discussions over the years
 have shown at least me what an ungrateful task it is to be redesigning
 Pod for Perl 6.


Yep, thanks, Damian!

Fortunately, doing _whatever_ for Perl 6 seems to be mostly a grateful task,
AFAICT.
-- 
Jan

Re: One-pass parsing and forward type references

[Jan Ingvoldstad]

On Mon, Feb 1, 2010 at 17:46, Patrick R. Michaud pmich...@pobox.com wrote:

 There's a third way:

class B { ... }# introduce B as a class name without definition
 class A { sub foo { B::bar } }

class B { sub bar { A::foo } }

 The first line is a literal ... in the body of the class -- it
 indicates that we're only declaring the name as being a type,
 and that something else will fill in the details later.


It seems to me that this doesn't really solve the problems that will occur
when people start making packages independently of eachother.

Of course it can be solved by submitting patches to the other developer's
code, but it seems inelegant.
-- 
Jan

Re: String to Regex

[Jan Ingvoldstad]

On Sun, Jan 3, 2010 at 8:30 PM, Moritz Lenz mor...@faui2k3.org wrote:


 But since $input can contain closures, arbitrary code can be executed.
 I'd like to propose a way to compile a string to a regex which doesn't
 allow code execution.


So would I.

I would also like it to be the default behaviour, since this is a place
foot on Bouncing Betty thing. :)



 my $rx = Regex.new(:string('abc|d'), :safe);


I think this is too complicated for something which is likely to be the most
frequent use of regex strings.

It would be better to enforce the more complicated syntax for the less
frequent cases.

(All IMO, of course.)
-- 
Jan

Re: r28523 - docs/Perl6/Spec/S32-setting-library

[Jan Ingvoldstad]

On Thu, Oct 1, 2009 at 10:15 PM, Moritz Lenz mor...@faui2k3.org wrote:


 What's the 0th root of a number, then?
 It would be a number $y for which $y ** 0 == $x, which can only be
 fulfilled for $x == 1. So in the general cases the answer to the
 question root($x, 0) is nonsense, which is best mapped to NaN.


That doesn't make sense. The answer is 1, not NaN.

Think about it for a while: mathematically speaking, we would expect the 0th
root of a number to be 1.

By enforcing NaN for a list of roots, math code suddenly has to include a
set of extraneous tests in order to coerce the result to a list of ones. And
that _is_ nonsensical.
-- 
Jan

Re: r28523 - docs/Perl6/Spec/S32-setting-library

[Jan Ingvoldstad]

On Thu, Oct 1, 2009 at 11:03 PM, Minimiscience minimiscie...@gmail.comwrote:

 On Oct 1, 2009, at 4:43 PM, Jan Ingvoldstad wrote:

 On Thu, Oct 1, 2009 at 10:15 PM, Moritz Lenz mor...@faui2k3.org wrote:

 What's the 0th root of a number, then?
 It would be a number $y for which $y ** 0 == $x, which can only be
 fulfilled for $x == 1. So in the general cases the answer to the
 question root($x, 0) is nonsense, which is best mapped to NaN.


 That doesn't make sense. The answer is 1, not NaN.

 Think about it for a while: mathematically speaking, we would expect the
 0th
 root of a number to be 1.


 I think you're confusing root with power.  Any number raised to the
 zeroth power is one (except, arguably, zero itself), but, given a number
 $num, its zeroth root is a number $base such that $base ** 0 == $num, which,
 as stated above, only makes sense when $num == 1.


You're of course right, that was an amazing brainfart.

I blame society.
-- 
Jan

Re: Iterate X times

[Jan Ingvoldstad]

On Sun, Sep 13, 2009 at 5:14 PM, Christian Sturm ree...@reezer.org 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

Re: Custom object constructors

[Jan Ingvoldstad]

On Thu, Aug 20, 2009 at 10:44 PM, Kevan Benson kben...@a-1networks.comwrote:


 That said, I submit that it's a very confusing part of the language as
 defined currently, and I haven't seen a very thorough explanation of the
 purpose of each method in the chain the instantiates a new object.  S12
 touches upon them slightly, but not in enough detail that I was able to work
 out where I should be adding code to appropriately make alternate
 constructors.


Now that you apparently understand it, do you have a suggestion on how S12
might be phrased differently?

I must admit that I don't quite grasp the concepts here yet, so an alternate
wording might help others as well.

Thanks for bringing the question up.
-- 
Jan

Re: [perl #64566] @a[1..*] adds trailing undef value

[Jan Ingvoldstad]

On Wed, Aug 19, 2009 at 1:54 PM, Moritz Lenz via RT 
perl6-bugs-follo...@perl.org wrote:


 Since the discussion came up on #perl6 if this is really the expected
 behaviour, S09 says:

 As the end-point of a range, a lone whatever means to the maximum
 specified index (if fixed indices were defined):

say @calendar[5..*];  # Same as:  say @calendar[5..11]
say @calendar{Jun..*};# Same as:  say @calendar{Jun..Dec}

 or to the largest allocated index (if there are no fixed indices):

say @data[1..*];  # Same as:  say @results[1..5]


 It doesn't mention how the postcifcumfix:[ ] is supposed to introspect
 those to find out if the WhateverCode object constructed by 1..* needs
 to receive self.elems or self.elems-1 as an argument.

 Which is why I CC: p6l to get some ideas or clarification, and if we
 want to maintain this DWIMmy but not very consistent behaviour.


I like it the way S09 says it.

But there is a problem with sparse arrays, isn't there?

S32/Containers (S32-array) says this about elems:


  our Int method elems (@array: ) is export

 Returns the length of the array counted in elements. (Sparse array types
 should return the actual number of elements, not the distance between the
 maximum and minimum elements.)


For arrays, it appears that using end is more relevant:



  our Any method end (@array: ) is export


 Returns the final subscript of the first dimension; for a one-dimensional
 array this simply the index of the final element. For fixed dimensions this
 is the declared maximum subscript. For non-fixed dimensions (undeclared or
 explicitly declared with *), the index of the actual last element is used.


Does that seem usable to y'all?
-- 
Jan

Re: r28017 - in docs/Perl6/Spec: . S32-setting-library

[Jan Ingvoldstad]

On Tue, Aug 18, 2009 at 10:01 AM, Nicholas Clarkn...@ccl4.org wrote:
 On Tue, Aug 18, 2009 at 09:24:08AM +0200, pugs-comm...@feather.perl6.nl wrote:

 +=head3 Default constraints
 +
 +The default p{} only allows / as separator and does not allow path 
 elements
 +to contain
 +characters that won't work on modern Windows and Unix like \ / ? % * : |  
  ,
 +etc. The reason for this is that portable paths are the default. If
 +platform/filesystem specific behavior is really needed it should be shown in
 +the code by applying different sets of constraints (see below).

 Perl 5 runs on (at least) VMS and VOS too. So, if Perl 6 is to adopt a policy
 of enforced portable filenames by default, it should (at least) also exclude
 - as the first character, and forbid more than one . in a filename.

And, as I mentioned in an earlier post during the discussion, the
restrictions for Windows are numerous:

http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx

Enforcing truly portable filenames is unrealistic, I think, but
having a POSIX-checking default is a good thing.
-- 
Jan

Re: r28017 - in docs/Perl6/Spec: . S32-setting-library

[Jan Ingvoldstad]

On Tue, Aug 18, 2009 at 10:58 AM, Nicholas Clarkn...@ccl4.org wrote:
 Oh gosh yes. I forgot. AUX.TXT
 And all the the other CP/M device file names, with our without extensions...


 [And of course, IIRC, DOS filenames can't be more than 64 characters. Which
 means that your code thinks that it knows what it's doing by stripping of
 the drive letter and allowing 62 in the rest of the pathname. Except that
 I remember university servers with drives UX: and UY:, which always made me
 wonder if there was a buffer overflow waiting to happen...]

Yes, lovely, isn't it?

 What does POSIX enforce? ASCII NUL terminated, multiple adjacent / characters
 fold to 1, except at the start, where // is special, but /// etc aren't?
 And anything else goes?

POSIX doesn't enforce much. I used our friendly do-no-evil empire, and
found this:

http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html#standards

And particularly from «2.2. Standards permit the exclusion of bad filenames»:

«I then examined the Portable Filename Character Set, defined in 3.276
(“Portable Filename Character Set”); this turns out to be just A-Z,
a-z, 0-9, period, underscore, and hyphen (aka the dash
character). So it’s perfectly okay for a POSIX system to reject a
non-portable filename due to it having “odd” characters or a leading
hyphen.»
-- 
Jan

Re: r28017 - in docs/Perl6/Spec: . S32-setting-library

[Jan Ingvoldstad]

On Tue, Aug 18, 2009 at 11:04 AM, David Greendavid.gr...@telus.net wrote:
 On 2009-Aug-18, at 2:29 am, Carlin Bingham wrote:

 chdir provides functionality that would be quite convoluted to mimic
 through manually setting $*CWD, such as changing to a relative
 directory.

 Maybe setting $*CWD just calls chdir() under the hood?  Same implementation,
 brand new shiny Perl-style interface!

It may seem cool, but I don't like secondary effects like that. They
break the principle of least surprise.
-- 
Jan

Re: S26 - The Next Generation

[Jan Ingvoldstad]

On Tue, Aug 18, 2009 at 3:47 AM, David Greendavid.gr...@telus.net wrote:
 On 2009-Aug-17, at 12:27 pm, Moritz Lenz wrote:

 However it seems we have to pay a price: each act of rendering a Pod
 file actually means executing the program that's being documented (at
 least the BEGIN blocks and other stuff that happens at compile time),
 with all the security risks implied. So we'll need a *very* good
 sandbox. Is that worth it?

 Yes.

Why is it worth it?

In general, executable documentation is a bad thing. It's been shown
to be a bad thing many times over.

If we absolutely must have some sort of executable documentation, then
if I could, I would insist that it wouldn't be a feature complete
language. That is: absolutely no IO in the language, no way of
executing code that's foreign to the doc, and so on.
-- 
Jan

Re: r28017 - in docs/Perl6/Spec: . S32-setting-library

[Jan Ingvoldstad]

On Tue, Aug 18, 2009 at 12:54 PM, Troels Liebe Bentsent...@rapanden.dk wrote:

 My idea with portable by default was only portability for modern Unix and
 modern Windows. So DOS and VMS limitations would not apply. The problem of
 enforcing truly portable filenames is that the files names get too
 restrictive and for most applications targeting 98% of systems out there would
 be enough.

That's a decent enough point, but it may be unwise to ignore legacy
systems that where Perl 5 is in common use, unless we want to shed
that userbase. (Mark this down as a I don't know, and I don't have a
stake in it, but…)

 With modern Unix/Windows I'm thinking about systems that support and use UCS2
 or UTF8 and where . or other common characters does not have special meaning
 for the filesystem.

We also need to keep in mind the Unicode problems between certain
unixy platforms (i.e. MacOS X vs. most if not all the rest).

If I recall correctly, the internal Unicode format chosen for Perl 6
is incompatible with MacOS X, because MacOS X implemented Unicode
support at a time when the standard as we know it today wasn't
finalized.

This has bearing on filenames, and MacOS X isn't a small enough
platform that it can simply be ignored, either.

 Besides that, a simple check on Unix for what the locale is set to might also 
 be
 nice, so we don't write UTF8 files on a filesystem where the rest for the 
 files
 are in Latin1.

The locale doesn't say what format the filenames are on the
filesystem, though, merely the current user's language preferences may
be.

That can't really be trusted, at least not for filename comparison
purposes. But I agree that it's sensible to default to the locale's
settings regarding character encoding.
-- 
Jan

Re: $*CWD and chdir()

[Jan Ingvoldstad]

On Tue, Aug 18, 2009 at 1:02 PM, David Greendavid.gr...@telus.net wrote:
 On 2009-Aug-18, at 3:12 am, Jan Ingvoldstad wrote:

 It may seem cool, but I don't like secondary effects like that. They break
 the principle of least surprise.

 It doesn't seem that surprising to me, especially after seeing the docs the
 first time.  Are there environments where you can set a variable like $*CWD
 and it doesn't do something like chdir?

Yes, and that's normal and expected behaviour.

viking...@shell:~$ uname -a
Linux shell 2.4.37.5 #1 Sun Aug 16 12:47:03 CEST 2009 i686 unknown
unknown GNU/Linux
viking...@shell:~$ bash --version
GNU bash, version 2.05b.0(1)-release (i486-slackware-linux-gnu)
Copyright (C) 2002 Free Software Foundation, Inc.
viking...@shell:~$ mkdir test
viking...@shell:~$ touch test/testfile
viking...@shell:~$ cd test
viking...@shell:~/test$ ls
testfile
viking...@shell:~/test$ pwd
/home/1/v/vikingmud/test
viking...@shell:~/test$ echo $PWD
/home/1/v/vikingmud/test
viking...@shell:~/test$ PWD=foo/notreallyadirectory
viking...@shell:foo/notreallyadirectory$ ls
testfile
viking...@shell:foo/notreallyadirectory$ pwd
/home/1/v/vikingmud/test
viking...@shell:foo/notreallyadirectory$ echo $PWD
foo/notreallyadirectory


j...@krakas ~ uname -a
Darwin krakas.ELIDED 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15
16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
j...@krakas ~ bash --version
GNU bash, version 3.2.17(1)-release (i386-apple-darwin9.0)
Copyright (C) 2005 Free Software Foundation, Inc.
j...@krakas ~ mkdir test
j...@krakas ~ touch test/testfile
j...@krakas ~ cd test
j...@krakas ~/test ls
testfile
j...@krakas ~/test pwd
/Users/jani/test
j...@krakas ~/test echo $PWD
/Users/jani/test
j...@krakas ~/test PWD=foo/notreallyadirectory
j...@krakas foo/notreallyadirectory ls
testfile
j...@krakas foo/notreallyadirectory pwd
/Users/jani/test
j...@krakas foo/notreallyadirectory echo $PWD
foo/notreallyadirectory

-- 
Jan

Re: $*CWD and chdir()

[Jan Ingvoldstad]

On Tue, Aug 18, 2009 at 2:33 PM, David Green david.gr...@telus.net wrote:


 Huh.  Thank you, I did not know that.  It makes sense (in that I
 understand what's going on now that I see it, and indeed it seems almost
 obvious), but I certainly couldn't call it expected because I didn't.  And
 I can guarantee I'm not the only one; in fact, I have no qualms about
 classifying that as a bug.


You think it's a bug that PWD=/etc doesn't change your working directory
to /etc in bash?

Please tell me you're joking.

The environment variables are generally just descriptive variables. If you
mess with them, they may no longer have bearing on reality. That is also
expected behaviour; if you shoot yourself in the foot, you may get hurt.

It can also be said to be expected behaviour because that's the way it has
been behaving for maybe as long as environment variables have been in
existence in Unix systems.

Here's another example of something that, if I understand you correctly, you
find as unexpected behaviour:

j...@krakas ~ USER=root
j...@krakas ~ echo $USER
root
# Am i root now?
j...@krakas ~ whoami
jani
# I'm not root.

While there have been programs assuming that %ENV{USER} indicates who the
current user is, and adjusting their behaviour based on that, such behaviour
has generally been classified as a security vulnerability, and rightly so.
-- 
Jan

Re: Filename literals

[Jan Ingvoldstad]

On Tue, Aug 18, 2009 at 3:20 PM, Carl Mäsak cma...@gmail.com wrote:


  Let's make a solid ground to stand on; something so stable that it
 works uphill and underwater. People with expertise and tuits will
 write the facilitating modules.

 PerlJam To quote Kernighan and Pike:  Simplicity. Clarity. Generality.
 moritz_ I agree.
 Matt-W magic can always be added with module goodness


I agree with this principle.

The discussion has been (and probably still will be) fruitful anyway, if
only in illuminating the challenges with multi-platform and multi-filesystem
support, some of the things we need to consider for that and how.
-- 
Jan

Re: $*CWD and chdir()

[Jan Ingvoldstad]

On Tue, Aug 18, 2009 at 3:52 PM, Mark J. Reed markjr...@gmail.com wrote:

 On Tue, Aug 18, 2009 at 9:26 AM, Jan Ingvoldstadfrett...@gmail.com
 wrote:
  You think it's a bug that PWD=/etc doesn't change your working
 directory
  to /etc in bash?
 
  Please tell me you're joking.

 It's not that unreasonable.


I disagree, and I think I've explained why, and perhaps we won't get much
further.

But see below.


 But USER isn't even a shell-maintained variable.  It's set by login();
 the shell just inherits it.  A better example would be UID - which is
 readonly.


I'm not sure what you mean by a shell-maintained variable.

As for $UID being read-only, that's a bashism. There's nothing inherent
about $UID that makes it read-only.

In a POSIX shell, you get this:

$ ksh --version
  version sh (ATT Research) 1993-12-28 s+
$ echo $UID $USER
501 jani
$ USER=root
$ UID=1000
$ echo $UID $USER
1000 root

csh is no different:

j...@krakas ~ csh
[krakas:~] root% echo $USER
root
[krakas:~] root% set USER=foo
[krakas:~] root% echo $USER
foo
[krakas:~] root% echo $UID
501
[krakas:~] root% set UID=1000
[krakas:~] root% echo $UID
1000

bash in POSIX mode agrees:

j...@krakas ~ bash --posix
j...@krakas ~ echo $UID
501
j...@krakas ~ UID=1000
j...@krakas ~ echo $UID
1000

Even Perl 5 lets me change it:

j...@krakas ~ perl --version|grep v5
This is perl, v5.8.9 built for darwin-2level
j...@krakas ~ perl -e 'print $ENV{UID}\n; $ENV{UID}=1000; print
$ENV{UID}\n;'
501
1000

-- 
Jan

Re: Filename literals

[Jan Ingvoldstad]

I'll just butt in here and say that while the URI format is nice for
alternate schemes, it is not nice for accessing files.

The general case in most programming languages is to assume that a
non-URI file name is local, specifying
file://wherever/whatever/filename is unnecessary additional syntax.

Also, perhaps only URLs should be permitted; they do after all specify
a location.

I'm unsure whether this should be part of a central specification to
Perl 6 or part of a module.


I think I like Hinrik's original proposal.


Oh, and regarding file names in Windows, this document should be a
pretty definitive guide:

http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx
-- 
Jan