Perl 6 - the future is here, just unevenly distributed

IRC log for #perl11, 2016-06-08

| Channels | #perl11 index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
03:28 sten joined #perl11
04:44 sten1 joined #perl11
06:04 rurban joined #perl11
06:12 rurban_ joined #perl11
06:14 ribasushi rurban: morning
06:14 ribasushi I think you misunderstood what I said in the ticket
06:15 ribasushi 1. skip with no arguments is now legal  2. you are soon going to ship new T::M anyway => therefore sending people patches to add no-longer-required-parameters isn't right
06:30 rurban @bulk88: thanks. So I'll wait with 5.24 a bit
06:31 rurban @ribasushi: skip without args is now legal? Who decided that? In Test2?
06:31 ribasushi rurban: look carefully at the last blob at https://github.com/perl11/cperl/issues/153#issuecomment-224393237
06:32 ribasushi skip; <-- legal
06:33 rurban I see. I haven't yet tested 1.302026. I encountered some single skip() and changed all these. Looks like I have to change the skip signature.
06:33 rurban "skip with no reason"
06:33 rurban => "skip for no reason"
06:34 ribasushi skip WITH reason WITHOUT count seems valid too
06:34 ribasushi skip "foo";
06:34 rurban personally I think skip without a reason is sloppy
06:34 rurban skip without count is even more sloppy
06:35 rurban the typechecker will have no problem with that, but users usually have.
06:35 ribasushi if I use done_testing - I never use a count myself - I hardcode a 1, and if I see something >1 I actively change it to 1
06:35 ribasushi in any case - this is a question of style, and is kinda offtopic ;)
06:36 ribasushi but the signature is effectively wrong :/
06:36 rurban I'll do a cpan grep
06:37 rurban No, on this case with so many wrong skip's, mixed up the args, I choose to be strict.
06:37 rurban Even core modules had the args mixed up, count first.
06:38 ribasushi mixed up args is semi-ok
06:38 ribasushi i.e. checking for this and fixing it is warranted
06:39 ribasushi but asking people to add arguments when the mainline does not require them - that will only create animosity and not much else
06:39 rurban https://github.com/Perl-Toolchain-Gang/Module-Build/pull/68
06:40 ribasushi rurban: actually I would reject this change too
06:40 ribasushi if ( returning int in scalar ) * ( literal int ) does not pass the INT check - things aren't right
06:43 ribasushi if the language subset requires explicit casting in this instance - it is on the language subset to figure out a way forward without adding extra ops into the mainstream codebase (the way forward may be a *) relaxed signature or *) maintaining a distropref effectively forever *) something else )
06:44 ribasushi let's not lose sight of reality ;)
06:45 ribasushi "2*@cases return :Number" <--- why is this actually, this can't be right, it can't return anything *but* :Int
06:47 ribasushi sigh
06:47 ribasushi "perl users often use scalar(@array) where they should use int(@array)" <--- can you explain to me (personally) why?
06:47 rurban A count and an array length can never be Scalar and neither Numeric, they can only be Int.
06:47 ribasushi why can't the language do that itself, given pretty much everything is static
06:48 ribasushi YES - an array length can only be int
06:48 ribasushi yet here https://github.com/Perl-Toolchain-Gang/Module-Build/pull/68#discussion_r62708654
06:48 ribasushi you yourself say
06:48 rurban counts and lengths are forbidden to overflow, and should not be intified at runtime neither, better do this at compile-time.
06:48 ribasushi "2*@cases return :Number"
06:49 rurban yes, unfortunately add is allowed to overflow
06:49 rurban Even with const Int + Int
06:49 ribasushi right I see - so essentially the result has to be typed Numeric in order to receive "whatever comes"
06:50 rurban I had to change this recently. in 5.22 they returned Int (via u_add)
06:50 ribasushi rurban: then you really need to relax the signature and accept numeric
06:50 rurban either type the result, or use int() explcitly
06:50 ribasushi if we leave aside p5p etc
06:50 rurban for skip?
06:50 ribasushi take software I maintain for mainstream perl
06:50 rurban skip is a special case with too many tradtional errors
06:51 ribasushi I will *not* go through the codebase to add extra int()s where I use plain array-in-context
06:51 rurban it's nonsense to do those type checks at run-time, and they caught no problem. Module::Build was wrong from the very beginning
06:51 ribasushi even if I understand why cperl needs them underneath, the burden is just too great to find them all, and if one doesn't find them all - it's a futile busy-work
06:52 rurban well, then you'll have to use the CPAN version of Test::More
06:52 rurban types are there to find errors in user code, and execute the code faster
06:52 rurban esp. in big sloppy codebases
06:53 ribasushi I understand that, and I even agree
06:53 ribasushi I am just saying that requiring mainstream perl code to start int()ing their ( @foo + 1 ) is... something that can not possibly end well
06:54 rurban If some maintainer doesn't like to change that, it cannot be used with cperl without distroprefs patch. some people want to stay in the postmodern days, but cperl is a "modern perl", not in the chromatic sense. in the modern sense.
06:54 ribasushi also... why can't there be > 2**32 skips in a count?
06:55 rurban because the range op doesn't take more
06:56 rurban flip only acts on the SvIV and ignore any overflowed SvNV
06:56 rurban die "Range iterator outside integer range"
06:57 rurban pp_flop in pp_ctl.c
06:57 ribasushi rurban: everything you say is correct from a CS point of view
06:57 rurban count also needs to be an UInt, cannot be negative
06:57 ribasushi but from a usability point of view making changes like this in such low-level (testing!) code is a massive usability problem
06:57 ribasushi I wish I could explain this better
06:58 rurban Yes, I understand that. On other sigs I was looser, but with skip I chose the stricter version on purpose.
06:58 rurban bad code needs to be fixed
07:00 rurban And the strict Str $why check is also problematic for normal variables. But adding a "$var" is not that big of a deal, and makes a clear difference to the Int $count arg.
07:00 ribasushi there is "bad code" and there is "bad code"
07:00 rurban skip $why, 1 => skip "$why", 1
07:00 rurban So I'm very happy with those changes
07:01 ribasushi having test counts overflow is hardly an attack vector - at most a runaway test will fail at runtime after several hours
07:01 ribasushi <ribasushi> let's not lose sight of reality ;)
07:01 rurban And even more with skip "$why", scalar(@skips) => skip "$why", int(@skips)
07:02 rurban it's not a security issue, I know
07:02 rurban the new code is more readable and more correct. anybody who has no idea about int() vs scalar() needs to read up on it.
07:03 rurban and why a "$why" is now needed. otherwise they can just ignore it, as #toolchain does
07:04 ribasushi *I* will ignore it as well, and 99.9% of other users too
07:04 rurban I'm providing my own toolchain anyway, as I don't expect them to cooperate in modernizing perl
07:04 ribasushi because my tests are a carefully maintained "time machine"
07:04 ribasushi it shows me what my code was back in the day
07:04 ribasushi so that the new lib/ will continue to work transparently
07:05 ribasushi going through t/ and changing various $foo to "$foo" is something I consider unacceptable
07:05 ribasushi not because your work is not great
07:05 ribasushi but because there are conflicting concerns and they win
07:05 rurban cperl code will deviate anyway later, that's why I have the 'c' suffix. cperl modernized perl cannot be executed on perl5 anyway. they have no proper sigs, no classes, no methods, no roles.
07:06 rurban so cperl users need to maintain their own modernized modules anyway
07:06 ribasushi which in a sense is perl6 all over again: "hey it's a similar language, but no, you need to write yourself a new CPAN from scratch"
07:07 ribasushi what's the endgame?
07:07 rurban It is called "modernized" for a reason. A "v0.1c" module cannot be executed by perl5
07:07 ribasushi I understand that (modern code won't run on main interp.), and would not expect anything else
07:08 rurban To be compatible. for perl5 it would trivial to add support for it. I needed 4 lines for typed sigs. But they refused, so I had to make a start somewhen. waiting for years brought nothing
07:08 ribasushi but I am not a user - I am a library provider: I would like your userbase to be able to benefit from my offerings too
07:08 rurban well, my changes are not breaking backcompat and produce better perl5 code
07:08 ribasushi and you make the requirements too strict for no reason other than "purity"
07:08 ribasushi so people like me, who genuinely want to help, are turned away
07:09 ribasushi that's what it boils down to
07:09 rurban skip() is a special case, because the tradional skip usage is mostly wrong, and went undetected.
07:09 rurban somewhen someone needs to start fixing his code
07:10 ribasushi to what benefit?
07:10 rurban less run-time code, clearer intent what the args really are.
07:10 rurban this one is a string, and this is the count
07:11 ribasushi you would catch the "reversed args" by simply slapping a "Num" requirement for the second optionbal argument
07:11 rurban both as scalars needs a /d regex at run-time
07:11 ribasushi which will be a welcome fix for *anyone* on CPAN: "hey you mixed up these"
07:11 rurban Num is still not Numeric. 2*@arr returns :Numeric
07:11 rurban and Numeric is wrong, as counts can only hold Int, and will lead to run-time errors
07:11 ribasushi but with this you lumped together: you need to cast all your num-likes now
07:12 ribasushi runtime errors IN TESTS! => who cares?
07:12 rurban Nope, only if you enforce types.
07:12 rurban I do care in this case
07:12 ribasushi nod, there isn't much I can add
07:12 rurban e.g. a -1 will lead to timeouts and lots of memory
07:13 ribasushi in a test?
07:13 ribasushi <ribasushi> <ribasushi> let's not lose sight of reality ;)
07:13 rurban yes. a timed out test will not make your QA and sysadmins happy, and neither the devs
07:14 rurban I also had to add lots of types to skip(), and found them better in all cases.
07:15 rurban same issue with bigint/bigfloat. types are critical there.
07:15 ribasushi well - while I am still semi-active on CPAN I will continue smoking your branches as you gradually update distroprefs, and report runtime (non-type) issues that I encounter
07:16 ribasushi but you are making the wrong tradeoff and this saddens me, as your excellent work is likely to not see wide adoption because of it
07:16 rurban summary: scalar(@array) is bad code, int(@array) is better. An array length can never be a NV.
07:17 rurban well, I have a different opinion. i think the tradeoff makes the code better, found lots of bugs, and produces better run-time code.
07:17 rurban and is more readable.
07:18 rurban With functions with switched args I will continue using strict type checks, such as with skip().
07:18 rurban esp. since the fixes make the code better and more readable. no need to argue there.
07:26 rurban but there should be a pragma to make this type warnings non-fatal. there's a new unused no warnings "types";
08:01 rurban and `use types` will need an option to add run-time checks, add compile-time promotions or be more or less fatal.
08:03 willthechill rurban: is this going to cause failures in the currently-existing test suites of other people's CPAN distributions?
08:16 rurban yes it does
08:16 rurban i had quite some skip() patches in my distroprefs
08:17 willthechill well I don't think you can claim to be compatible with Perl 5 if you cause other people's Perl 5 code to break
08:18 rurban Net-SSLeay-1.72, IO-Socket-SSL-2.027, Module::Build
08:18 rurban But I cause less trouble than a typical perl5 major update
08:18 rurban And I provide the patches
08:19 willthechill there is no way you can patch everybody's code on CPAN
08:29 vytas joined #perl11
08:34 rurban yes, only some major CPAN modules
08:34 rurban I only test about 3000
08:35 rurban when people are still using bad code it needs to be broken, and announced at compile-time. not at run-time when possible
08:36 willthechill so you will personally patch 3000 CPAN modules?
08:37 rurban I do provide distroprefs for all our used CPAN modules for many years, because CPAN authors traditionally do not care
08:38 rurban first got commit Aug 1, 2012 https://github.com/rurban/distroprefs/commits/master?page=4
08:38 rurban but I do this for a much longer time
08:38 rurban at least since v5.14
08:39 rurban andy koenig does it for decades already
08:40 willthechill so then why does ribasushi disagree?
08:42 rurban because he doesn't like to improve his tests
08:42 rurban he wants them to be written old-style ("timemachine")
08:43 rurban I cannot help him there. This will be the typical discussion with every type opponent
08:46 rurban Added now a FAQ at http://perl11.org/cperl/STATUS.html for 5.24
08:50 willthechill so is ribasushi's code one of the 3000 CPAN distributions which you have personally patched?
09:06 rurban no, I didn't patch DBIx::Class yet, we don't use it
09:07 rurban And I patched only about 10-20 (I have 211 patches, many of them very old), I just test 3000.
09:08 rurban @bulk88: MSVC10 is now green again. Let's see what MSVC12 says. I skipped a fork test there. https://ci.appveyor.com/project/rurban/cperl/build/5.24.0.1244
09:09 willthechill oh wow I thought everybody uses DBIC
09:12 travis-ci perl11/cperl#1105 (smoke/relprep5.24.0 - d906e40 : Reini Urban): The build passed. https://travis-ci.org/perl11/cperl/builds/136075646
09:13 rurban But the patch there is trivial, and self-explaining
09:14 rurban Whow, Test-Simple-1.001014-1.302022.diff is 1MB! Quite a lot of work
09:15 rurban There are many more patches for -Dfortify_inc needed, then for type strictness. And this is a security issue
09:16 willthechill well ribasushi is no fool, if he disagrees then there must be a valid reason
09:17 rurban yes, but I do not argue. I explained it very well, and he wants to stay behind he will stay behind. I don't care much
09:17 rurban many authors are very uncooperative. they will not win
09:18 rurban the toolchain gang is much worse
09:18 willthechill yes but everything uses DBIC
09:18 willthechill if the patch is so easy and trivial for YOU, then you should do it to help ribasushi understand
09:19 willthechill show him how 1 line of code will help him be compatible with cperl
09:20 dolmen joined #perl11
09:24 dolmen rurban: I agree with ribasushi about 2*@array
09:25 dolmen 2*@array not being compiled as an Int expression breaks my expectation
09:26 dolmen same for: @array-1
09:28 dolmen s/compiled/type infered/
09:28 ribasushi dolmen: then you are not agreeing with me
09:28 ribasushi 2*@array going Numeric is correct as explained by rurban above
09:29 ribasushi since operations can not know what the result will be at compile time
09:29 ribasushi the *mechanics* of the type system rurban is writing are correct
09:29 ribasushi the problem is strictly that he applied it to preexisting code, instead of having a strictly opt-in for new code
09:30 ribasushi revolutions do not work
09:31 ribasushi rurban: do not mistake my disagreement with your plan of action as "uncooperative"
09:32 ribasushi I want your work to succeed, and I could *potentially* use types when available in a very small set of cases myself
09:32 ribasushi but this "we will drag the world towards a glorious updated future" - ether already tried that and you know how that worked
09:32 rurban I agree with the opt-in. But I made an excemption for skip, also because I cannot opt-in yet. I have no pragma's yet in place for less stricter typechecking.
09:33 ribasushi rurban: then please don't black-paint me with "uncooperative", "wants to stay behind" etc - it's not cool.
09:33 rurban The idea is to be not intrusive, as in javascript (also a horrible language with many type quirks)
09:33 rurban but you are
09:34 dolmen so I don't understand why @array in a scalar context is type infered as Numeric instead of Int
09:34 ribasushi sigh, I got other stuff to do, enjoy your day &
09:34 ribasushi dolmen: @array alone isn't, @array * something is
09:34 rurban the changes are minimal and are better. so you are uncooperative and you will stay behind in the end. perl5 is already dead as you already experienced with the choice of sawyer.
09:35 dolmen so there is no special case for < Int * Int-constant > ?
09:35 rurban arithmethic ops overflow and promite to NV, hence Numeric.
09:35 rurban Initially I had compile-time not-overflowing u_* arith ops, but I cannot hold them.
09:36 rurban u_ for UInt
09:36 rurban < Int * Int-constant > may overflow to Num
09:37 rurban there are several core tests t/op/pack, t/op/inc which do that
09:37 rurban just to compute IV_MAX and UV_MAX
09:38 rurban such overflow will lead to run-time errors with 0..$count e.g. but the typechecker cannot lead out overflows
09:39 rurban with parametric types and a bit more knowledge about arrays it would be possible. but this is a future version (and probably costly)
09:39 rurban same for hashes and strings
09:41 rurban I haven't even started to type all the string ops. These need to be permissive.
09:41 dolmen but does < @array * 2 > could really overflow in practice? That would imply an array of size UV_MAX, but is it really possible to have such a big array in practice? Isn't there already some internals limits that would make such an array impossible to build?
09:42 rurban with cperl the max array, hash and string size is now IV_MAX, not UV_MAX. perl5 permits UV. cperl does it for safety to detect overlarge aggregates earlier and keep the system stable.
09:42 dolmen I'm implying that < @array > is a subset of UInt
09:43 rurban 20 * (IV_MAX-1) will overflow, yes
09:43 rurban in practice it's a problem, it will start swapping
09:44 rurban and if you need such big arrays in practice (i needed them in 1996, but had to switch to lisp), one needs to use either Tie::CArray or natively typed arrays. which are 4x smaller and much faster.
09:45 rurban Int/Uint is only factor 2. The other constant factor could be much bigger than 2. This can only be caught at run-time.
09:46 rurban native types help a lot in other cases also. assignment is much easier, the stack and pads are suddenly primitive, no refs.
09:47 rurban that's why v8 is so much faster
10:48 vytas joined #perl11
10:56 rurban Test2 breaks much more modules than cperl btw. And he has no patches for them. https://api.metacpan.org/source/EXODIST/Test-Simple-1.302026/META.yml
10:57 ribasushi rurban: you are preaching to the choir: http://blogs.perl.org/users/chad_exodist_granum/2016/04/test2testbuilder-update-from-the-qah.html#comment-1702584
11:07 vytas joined #perl11
11:12 travis-ci perl11/cperl#1106 (smoke/relprep5.24.0 - c787fcb : Reini Urban): The build passed. https://travis-ci.org/perl11/cperl/builds/136101106
11:57 rurban Did they re-did the old benchmarks? The first versions where 2x slower, which caused the anger.
12:02 rurban and that he broke Test::Builder, and didnt come up with a Test::Builder2 as expected
12:03 rurban well, he pushed it already to CPAN, so those old test modules are already broken by now.
12:45 rurban joined #perl11
12:52 travis-ci perl11/cperl#1107 (smoke/relprep5.24.0 - 91e031b : Reini Urban): The build was broken. https://travis-ci.org/perl11/cperl/builds/136128748
12:54 rurban1 joined #perl11
14:51 travis-ci perl11/cperl#1108 (smoke/relprep5.24.0 - 0293dae : Reini Urban): The build was fixed. https://travis-ci.org/perl11/cperl/builds/136153469
15:25 rurban joined #perl11
15:28 rurban_ joined #perl11
15:40 rurban Actually DBIx::Class is in my list of tested modules. Just saw it. But Text::CSV_XS fails in one test, which is a bigger problem.
15:52 rurban I've pushed cperl-5.24.0-RC1
16:48 travis-ci perl11/cperl#1109 (master - 0293dae : Reini Urban): The build passed. https://travis-ci.org/perl11/cperl/builds/136188728
21:01 rurban joined #perl11
21:02 rurban_ joined #perl11
22:37 rurban1 joined #perl11
23:32 travis-ci perl11/cperl#1110 (master - d0781dd : Reini Urban): The build was broken. https://travis-ci.org/perl11/cperl/builds/136291854
23:41 rurban joined #perl11
23:50 rurban1 joined #perl11
23:53 bulk88 "[05:08] <rurban> @bulk88: MSVC10 is now green again. Let's see what MSVC12 says. I skipped a fork test there. https://ci.appveyor.com/project/rurban/cperl/build/5.24.0.1244"
23:54 travis-ci MathPerl build passed. Will Braswell says 'Math Branches, Update & Reorganize'
23:54 travis-ci https://travis-ci.org/wbraswell/mathperl/builds/136301196 https://github.com/wbraswell/mathperl/compare/a24d9a0d74d0...26dd15c5afe6
23:54 bulk88 ../cpan/Test-Simple/t/subtest/fork.t is a SEGV because there is a bioizzare type croak dureing the cloen code execution
23:54 bulk88 there is no cxstack yet at the point of the clone, so it SEGVs tryiong to die/dispatch the croack

| Channels | #perl11 index | Today | | Search | Google Search | Plain-Text | summary