[perl #132349] [REGRESSION] $*IN.getc not blocking on macOS

2017-10-23 Thread Zoffix Znet via RT 
On Mon, 23 Oct 2017 09:28:47 -0700, b...@post.pl wrote:
> > And some C++ stackoverflow post claimed this was a bug in standard
> > library on macos that was fixed in some version already.
> 
> I'll try to get you Sierra (10.12) and High Sierra (10.13) results tomorrow.


Added a test (in a branch) that covers the bug: 
https://github.com/perl6/roast/commit/27833272b4
I also made a MoarVM PR that fixes the bug: 
https://github.com/MoarVM/MoarVM/pull/731

However, I've no idea if that fix is sane and whether it has significant 
performance impact
on MacOS (I was using someone's VM for the fix and couldn't get reliable 
spectest or perf measure done).

[perl #132349] [REGRESSION] $*IN.getc not blocking on macOS

2017-10-23 Thread Zoffix Znet via RT 
On Mon, 23 Oct 2017 09:28:47 -0700, b...@post.pl wrote:
> > And some C++ stackoverflow post claimed this was a bug in standard
> > library on macos that was fixed in some version already.
> 
> I'll try to get you Sierra (10.12) and High Sierra (10.13) results tomorrow.


Added a test (in a branch) that covers the bug: 
https://github.com/perl6/roast/commit/27833272b4
I also made a MoarVM PR that fixes the bug: 
https://github.com/MoarVM/MoarVM/pull/731

However, I've no idea if that fix is sane and whether it has significant 
performance impact
on MacOS (I was using someone's VM for the fix and couldn't get reliable 
spectest or perf measure done).

Re: Perl 6: Protecting Intellectual Property for Commercial Code

2017-10-23 Thread Shlomi Fish 
Hi James,

On Mon, 23 Oct 2017 07:19:34 -0700
James Ellis Osborne III  wrote:

> Is compilation to bytecode still a todo feature?  I managed to get a
> solution supporting compilation, serial-based locking, & license expiration
> delivered in Python last month for the nuclear industry..  Bytecode
> compilation is a hard requirement though if you don't want someone easily
> ripping out the license check & don't want to spend the effort building
> useability features into the serial calls.
> 

Since Python is a symbolic language, it is relatively easy to reconstruct the
original python source code from the *.pyc files. See
http://shlomif-tech.livejournal.com/39732.html (which was linked in one of my
links).


-- 
-
Shlomi Fish   http://www.shlomifish.org/
http://ccmixter.org/files/destinazione_altrove/49997 - “Paint The Sky”

Joel’s Generalisation: If it happens to you, it happens to everybody.
(Or: It’s never only you.)
— Based on http://www.joelonsoftware.com/news/20020402.html

Please reply to list if it's a mailing list post - http://shlom.in/reply .

[perl #132349] [REGRESSION] $*IN.getc not blocking on macOS

2017-10-23 Thread Pawel Pabian via RT 
> And some C++ stackoverflow post claimed this was a bug in standard
> library on macos that was fixed in some version already.

I'll try to get you Sierra (10.12) and High Sierra (10.13) results tomorrow.

[perl #132352] Set operators unfriendly to mutable types

2017-10-23 Thread Sam S. via RT 
On Mon, 23 Oct 2017 05:23:55 -0700, c...@zoffix.com wrote:
> Set operators are a lot less useful with mutable types, like SetHash,
> because
> even when one of the operands is a SetHash, they still return a Set,
> making
> constructs like `∖=` or `∪=` entirely unusable:
> 
> my $days = SetHash.new: Date.today … Date.new: '2014-04-02';
> $days ∖= $days.grep: *.key.day-of-week > 5;
> dd $days.^name; # "Set"
> $days{Date.today}:delete; # Cannot call 'DELETE-KEY' on an immutable
> 'Set'

I don't think setty operators always returning Set, is that different from 
listy operators/methods (Z, grep, map...) always returning Seq.

For example, when you write:

   @foo .= grep: * %% 2;

Then the grep returns a Seq, and and its the assignment to the Array variable 
which makes sure that in the end you'll have the results as an Array. (Still 
the same Array, in fact, just with new contents.)

If you were to use a Scalar variable, you would get essentially the same issue 
as in your quoted Set example:

   $foo .= grep: * %% 2;  # Oops, $foo is now an immutable Seq.

The "solution", IMO, would not be to make your quoted example work (by adding 
further special cases to the return types of the setty operators or otherwise), 
but rather to make the following variation of it work:

my %days is SetHash = Date.today … Date.new: '2014-04-02';

%days ∖= %days.grep: *.key.day-of-week > 5;

%days{Date.today}:delete;

...and then promote %-sigiled SetHash variables as the recommended way to store 
SetHash'es.

It should be possible to make this last example work by implementing `method 
STORE` for type SetHash, right?

(That it currently doesn't, may well be an oversight rather than a design 
choice.)

[perl #132349] [REGRESSION] $*IN.getc not blocking on macOS

2017-10-23 Thread Zoffix Znet via RT 
On Mon, 23 Oct 2017 07:15:56 -0700, coke wrote:
> On Sun, 22 Oct 2017 12:25:07 -0700, b...@post.pl wrote:
> > There is no strace on macOS, I used dtruss (dtrace):
> >
> > $ dtruss -p 1827
> > SYSCALL(args)  = return
> > fstat64(0x0, 0x7FFF5B18B2F0, 0x1)  = 0 0
> > lseek(0x0, 0x0, 0x1)   = 54132 0
> > write(0x1, "Nil\n\0", 0x4) = 4 0
> > thread_selfid(0x0, 0x7F8252ED2090, 0x4)= 24710 0
> >
> >
> >
> 
> This behavior changed on
> https://github.com/rakudo/rakudo/commit/80bbfcdd47bcb27c21352a53a5156a6ecdd41e65
> 
> commit 80bbfcdd47bcb27c21352a53a5156a6ecdd41e65
> Author: Jonathan Worthington 
> Date:   Fri Jul 14 14:24:13 2017 +0200
> 
> Use same slow-path for getc and readchars.
> 
> This will allow fixing the common problem they have near the end of
> the file in one place, as well as giving less code to maintain.
> 
> 
> IRC chat noted the behavior of
> 
> perl6 -e '$*IN.eof.say'
> 
> Is different on OS X and other platforms (True on mac, False
> elsewhere)


More IRC discussion: https://irclog.perlgeek.de/perl6-dev/2017-10-23#i_15341428

Kinda boils down to this snippet saying "STDIN IS: seekable" on Macos, while 
NOT seekable everywhere else:

#include 
#include 
#include 

int main(void) {
int r = lseek(STDIN_FILENO, 0, SEEK_CUR);
printf("STDIN IS: %s\n", (r && r != -1)  ? "seekable" : "NOT seekable");
return 0;
}

And some C++ stackoverflow post claimed this was a bug in standard library on 
macos that was fixed in some version already.

[perl #132349] [REGRESSION] $*IN.getc not blocking on macOS

2017-10-23 Thread Zoffix Znet via RT 
On Mon, 23 Oct 2017 07:15:56 -0700, coke wrote:
> On Sun, 22 Oct 2017 12:25:07 -0700, b...@post.pl wrote:
> > There is no strace on macOS, I used dtruss (dtrace):
> >
> > $ dtruss -p 1827
> > SYSCALL(args)  = return
> > fstat64(0x0, 0x7FFF5B18B2F0, 0x1)  = 0 0
> > lseek(0x0, 0x0, 0x1)   = 54132 0
> > write(0x1, "Nil\n\0", 0x4) = 4 0
> > thread_selfid(0x0, 0x7F8252ED2090, 0x4)= 24710 0
> >
> >
> >
> 
> This behavior changed on
> https://github.com/rakudo/rakudo/commit/80bbfcdd47bcb27c21352a53a5156a6ecdd41e65
> 
> commit 80bbfcdd47bcb27c21352a53a5156a6ecdd41e65
> Author: Jonathan Worthington 
> Date:   Fri Jul 14 14:24:13 2017 +0200
> 
> Use same slow-path for getc and readchars.
> 
> This will allow fixing the common problem they have near the end of
> the file in one place, as well as giving less code to maintain.
> 
> 
> IRC chat noted the behavior of
> 
> perl6 -e '$*IN.eof.say'
> 
> Is different on OS X and other platforms (True on mac, False
> elsewhere)


More IRC discussion: https://irclog.perlgeek.de/perl6-dev/2017-10-23#i_15341428

Kinda boils down to this snippet saying "STDIN IS: seekable" on Macos, while 
NOT seekable everywhere else:

#include 
#include 
#include 

int main(void) {
int r = lseek(STDIN_FILENO, 0, SEEK_CUR);
printf("STDIN IS: %s\n", (r && r != -1)  ? "seekable" : "NOT seekable");
return 0;
}

And some C++ stackoverflow post claimed this was a bug in standard library on 
macos that was fixed in some version already.

[perl #132349] [REGRESSION] $*IN.getc not blocking on macOS

2017-10-23 Thread Will Coleda via RT 
On Sun, 22 Oct 2017 12:25:07 -0700, b...@post.pl wrote:
> There is no strace on macOS, I used dtruss (dtrace):
> 
> $ dtruss -p 1827
> SYSCALL(args)  = return
> fstat64(0x0, 0x7FFF5B18B2F0, 0x1)  = 0 0
> lseek(0x0, 0x0, 0x1)   = 54132 0
> write(0x1, "Nil\n\0", 0x4) = 4 0
> thread_selfid(0x0, 0x7F8252ED2090, 0x4)= 24710 0
> 
> 
> 

This behavior changed on 
https://github.com/rakudo/rakudo/commit/80bbfcdd47bcb27c21352a53a5156a6ecdd41e65

commit 80bbfcdd47bcb27c21352a53a5156a6ecdd41e65
Author: Jonathan Worthington 
Date:   Fri Jul 14 14:24:13 2017 +0200

Use same slow-path for getc and readchars.

This will allow fixing the common problem they have near the end of
the file in one place, as well as giving less code to maintain.


IRC chat noted the behavior of

perl6 -e '$*IN.eof.say' 

Is different on OS X and other platforms (True on mac, False elsewhere)

-- 
Will "Coke" Coleda

[perl #132349] [REGRESSION] $*IN.getc not blocking on macOS

2017-10-23 Thread Will Coleda via RT 
On Sun, 22 Oct 2017 12:25:07 -0700, b...@post.pl wrote:
> There is no strace on macOS, I used dtruss (dtrace):
> 
> $ dtruss -p 1827
> SYSCALL(args)  = return
> fstat64(0x0, 0x7FFF5B18B2F0, 0x1)  = 0 0
> lseek(0x0, 0x0, 0x1)   = 54132 0
> write(0x1, "Nil\n\0", 0x4) = 4 0
> thread_selfid(0x0, 0x7F8252ED2090, 0x4)= 24710 0
> 
> 
> 

This behavior changed on 
https://github.com/rakudo/rakudo/commit/80bbfcdd47bcb27c21352a53a5156a6ecdd41e65

commit 80bbfcdd47bcb27c21352a53a5156a6ecdd41e65
Author: Jonathan Worthington 
Date:   Fri Jul 14 14:24:13 2017 +0200

Use same slow-path for getc and readchars.

This will allow fixing the common problem they have near the end of
the file in one place, as well as giving less code to maintain.


IRC chat noted the behavior of

perl6 -e '$*IN.eof.say' 

Is different on OS X and other platforms (True on mac, False elsewhere)

-- 
Will "Coke" Coleda

[perl #132349] [REGRESSION] $*IN.getc not blocking on macOS

2017-10-23 Thread Aleks-Daniel Jakimenko-Aleksejev via RT 
[Coke]++ bisected it to
https://github.com/rakudo/rakudo/commit/80bbfcdd47bcb27c21352a53a5156a6ecdd41e65

On 2017-10-22 12:25:07, b...@post.pl wrote:
> There is no strace on macOS, I used dtruss (dtrace):
>
> $ dtruss -p 1827
> SYSCALL(args) = return
> fstat64(0x0, 0x7FFF5B18B2F0, 0x1) = 0 0
> lseek(0x0, 0x0, 0x1) = 54132 0
> write(0x1, "Nil\n\0", 0x4) = 4 0
> thread_selfid(0x0, 0x7F8252ED2090, 0x4) = 24710 0
>
>
>

Re: Perl 6: Protecting Intellectual Property for Commercial Code

2017-10-23 Thread Parrot Raiser 
Frankly, if you're worried about this sort of thing, you have too much
faith in "secret sauces", and not enough in understanding situations
thoroughly. Code is trivial, implementation isn't.

Back in the days of dBase II, I was a contractor for one ministry of
the local government. They asked me to write a little system to do a
particular job   (As much an experiment to see if these new "desktop
computers" were useful tools or just cute toys as for the actual
outcome.) It was clearly applicable to other branches, so I made it
appropriately generalisable from the start.

Some of the other ministries contracted me to adapt the
government-owned code for them.  I had a lot less cleaning up to do
where they said "Please install it for us" than when managers had
hijacked the code and tried to implement it as their own creation.

On 10/23/17, Shlomi Fish  wrote:
> Hi Mark,
>
> On Sun, 22 Oct 2017 22:37:31 +
> Mark Devine  wrote:
>
>> Perl 6 Users,
>>
>> [[ Bouncing off Re: who own my code? ]]
>>
>> This is the first of several possible spin-off questions, but here goes…
>>
>> Perl 6 has its public ecosystem, which will drive growth and adoption.
>> Then
>> there’s the commercial side, which would also drive the language from
>> another
>> important angle.  I believe in a balance of public sharing and private
>> enterprise.
>>
>> I am interested in packaging some of my long-term Perl 6
>> projects/scripts/apps/frameworks into some kind of relocatable object
>> form
>> (binary) that cannot be easily altered or trivially reverse engineered.
>> Put
>> another way, I sometimes would prefer not to sell source code to my
>> customers, but rather some form of compiled package that can’t easily be
>> diddled by a SysAdmin.  If I create code for a particular commercial
>> domain
>> over years, then I want to get compensated for it and not have it be
>> diluted
>> with copy-cats one week after I release it.  Certainly some of the
>> generic
>> libraries that I create in the future can be modularized for the Perl 6
>> ecosystem and I’ll push those eventually, but the really specialized
>> domain-specific code that fills a commercial void & that I will commit
>> years
>> to maintaining, I’d like to offer a commercial license, key-protect, sell
>> subscriptions, etc.
>>
>> Again, I’m very interested in contributing to the ecosystem when possible.
>>  I
>> still need to grow past baby/teenager Perl 6, and I’ll get there soon.
>> But
>> after creating something targeted only for customer
>> purchase/subscription,
>> what tools are available in the Perl 6 toolbox?  I saw something for the
>> Java
>> back-end (to .jar), but not much else.
>>
>> Is there a Perl 6 roadmap that might mention compiling Perl 6
>> modules/scripts
>> into something atomic, binary, & relocatable?  Or preferably the
>> capability
>> to compile only specific Perl 6 modules, requiring an existing Perl 6 on
>> the
>> target host?
>>
>
> Please see
> https://github.com/shlomif/Freenode-programming-channel-FAQ/blob/master/FAQ.mdwn#how-do-i-hideobscureencrypt-my-source-code-to-prevent-end-users-from-learning-how-it-works
> .
>
> Regarding "Intellectual Property", see
> https://www.linux.com/news/why-term-intellectual-property-seductive-mirage
> and
> http://ericsink.com/articles/Intellectual_Property.html .
>
> --
> -
> Shlomi Fish   http://www.shlomifish.org/
> Best Introductory Programming Language - http://shlom.in/intro-lang
>
> I’m worser at superlatives.
> And I don’t ever use no double negatives.
> — James at War, “Bad Grammar”:
> http://www.youtube.com/watch?v=Mj6QqCH7g0Q
>
> Please reply to list if it's a mailing list post - http://shlom.in/reply .
>

Re: who own my code?

2017-10-23 Thread Brandon Allbery 
On Mon, Oct 23, 2017 at 1:47 AM, Jan Ingvoldstad  wrote:

> 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.
>

Sometimes, but not always. Remember that the default for answered questions
is reverse by rating, so the topmost answer will be the higest rated one;
you can change the sort order, and occasionally can observe it in an
intermediate state before it re-sorts the (cached?) page. As such it's no
worse than any other crowdsourced site/resource (including pre-Internet
ones like Consumer Reports or the U.S.'s Better Business Bureau).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: who own my code?

2017-10-23 Thread Parrot Raiser 
I agree that this is really not the appropriate forum for this. Type a
question like "if I write the same code for several clients, who owns
it?" into a search engine, and you'll get a plethora of links.

In this case, I would say the fairest thing is to write the sharable
portion once on your own time, then charge all the clients the same
for the core and time-and-materials for the tailoring.

On 10/23/17, Jan Ingvoldstad  wrote:
> 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
>

[perl #132353] [LTA] error with using meta assign ops with bound SetHash

2017-10-23 Thread via RT 
# New Ticket Created by  Zoffix Znet 
# Please include the string:  [perl #132353]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=132353 >


This code produces an LTA error:

my %days := SetHash.new: Date.today … Date.new: '2030-04-02';
%days ∖= %days.grep: *.key.day-of-week > 5;

First, the error reads "Cannot modify an immutable SetHash" which is confusing,
since SetHash is a mutable type.

Second, the error dumps all of the contents of the SetHash, so for this code,
the user has to scroll several pages up just to get to the error itself.

[perl #132352] Set operators unfriendly to mutable types

2017-10-23 Thread via RT 
# New Ticket Created by  Zoffix Znet 
# Please include the string:  [perl #132352]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=132352 >


Set operators are a lot less useful with mutable types, like SetHash, because
even when one of the operands is a SetHash, they still return a Set, making
constructs like `∖=` or `∪=` entirely unusable:

my $days = SetHash.new: Date.today … Date.new: '2014-04-02';
$days ∖= $days.grep: *.key.day-of-week > 5;
dd $days.^name; # "Set"
$days{Date.today}:delete; # Cannot call 'DELETE-KEY' on an immutable 'Set'

[perl #132287] [REGRESSION][CONC] stall/block in async heavy code

2017-10-23 Thread Aleks-Daniel Jakimenko-Aleksejev via RT 
OK, first of all, thank you for the report. The issue is indeed there, and in
my opinion it's a significant problem.

Secondly, ♥ for trying to bisect it manually. Nowadays I only do it with a bot
unless I have to trisect rakudo+nqp+moar.

However, the result of bisection is wrong (as far as I can see), and my guess
is that on some steps you used “git bisect bad” when you should have used “git
bisect skip” (when bisecting automatically you should use exit code 125 in
these situations). It just happens that on some commits you can't really build
rakudo (e.g. some work was split into several commits so some of the
intermediate versions are unbuildable). We should try to avoid these
situations, but it happens. On these commits you don't really know if the bug
is there or not because there is simply no way to test. Similar bug (but not
the same one) was bisected with a bot, and you can take a look at the result:
https://gist.github.com/Whateverable/0f0acba0af518988eb207fd52fae (the
commit you are talking about is listed there as well).

In other words, the problem appeared in better-sched branch, and not exactly in
the commit you mentioned.

Now, talking about the code you've used, it looks a bit weird to me. It seems
that you're doing async access to %c which should probably be protected with a
lock. In any case, I was able to reproduce the issue without most of that code,
by using just qqx. See GH #1202 ( https://github.com/rakudo/rakudo/issues/1202
).

As far as I can see (judging by GH #1202), the issue is much *easier* to
reproduce now with better-sched, but the bug was there for a long time.

So for the 2017.10 release: SNAFU.

On 2017-10-16 18:27:57, jdv79 wrote:
> No, sorry. I meant that I only tested for a couple minutes at each
> commit.
> Commits before the one bisect found never manifested the issue.
>
> On 2017.10.16 10:52 am, jn...@jnthn.net via RT wrote:
> > On Fri, 13 Oct 2017 10:13:36 -0700, jdv79 wrote:
> >> The symptom is that sometimes (90%+ on my box and ungolfed) the
> >> program
> >> seems to stall out on the qqx line. The last thing that is printed
> >> is
> >> "before". But on earlier commits (that actually build) no such
> >> stallage
> >> happened for a couple minutes run time.
> >>
> > So if I follow correctly, the changes in the commit mentioned make an
> > existing problem manifest sooner, rather than introduce the problem?

Re: Perl 6: Protecting Intellectual Property for Commercial Code

2017-10-23 Thread Shlomi Fish 
Hi Mark,

On Sun, 22 Oct 2017 22:37:31 +
Mark Devine  wrote:

> Perl 6 Users,
> 
> [[ Bouncing off Re: who own my code? ]]
> 
> This is the first of several possible spin-off questions, but here goes…
> 
> Perl 6 has its public ecosystem, which will drive growth and adoption.  Then
> there’s the commercial side, which would also drive the language from another
> important angle.  I believe in a balance of public sharing and private
> enterprise.
> 
> I am interested in packaging some of my long-term Perl 6
> projects/scripts/apps/frameworks into some kind of relocatable object form
> (binary) that cannot be easily altered or trivially reverse engineered.  Put
> another way, I sometimes would prefer not to sell source code to my
> customers, but rather some form of compiled package that can’t easily be
> diddled by a SysAdmin.  If I create code for a particular commercial domain
> over years, then I want to get compensated for it and not have it be diluted
> with copy-cats one week after I release it.  Certainly some of the generic
> libraries that I create in the future can be modularized for the Perl 6
> ecosystem and I’ll push those eventually, but the really specialized
> domain-specific code that fills a commercial void & that I will commit years
> to maintaining, I’d like to offer a commercial license, key-protect, sell
> subscriptions, etc.
> 
> Again, I’m very interested in contributing to the ecosystem when possible.  I
> still need to grow past baby/teenager Perl 6, and I’ll get there soon.  But
> after creating something targeted only for customer purchase/subscription,
> what tools are available in the Perl 6 toolbox?  I saw something for the Java
> back-end (to .jar), but not much else.
> 
> Is there a Perl 6 roadmap that might mention compiling Perl 6 modules/scripts
> into something atomic, binary, & relocatable?  Or preferably the capability
> to compile only specific Perl 6 modules, requiring an existing Perl 6 on the
> target host?
> 

Please see
https://github.com/shlomif/Freenode-programming-channel-FAQ/blob/master/FAQ.mdwn#how-do-i-hideobscureencrypt-my-source-code-to-prevent-end-users-from-learning-how-it-works
 .

Regarding "Intellectual Property", see
https://www.linux.com/news/why-term-intellectual-property-seductive-mirage and
http://ericsink.com/articles/Intellectual_Property.html .

-- 
-
Shlomi Fish   http://www.shlomifish.org/
Best Introductory Programming Language - http://shlom.in/intro-lang

I’m worser at superlatives.
And I don’t ever use no double negatives.
— James at War, “Bad Grammar”: http://www.youtube.com/watch?v=Mj6QqCH7g0Q

Please reply to list if it's a mailing list post - http://shlom.in/reply .