Perl 6 - the future is here, just unevenly distributed

IRC log for #perl11, 2013-11-07

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

All times shown according to UTC.

Time Nick Message
00:26 mirjam joined #perl11
00:32 rurban1 joined #perl11
00:45 stevan joined #perl11
00:57 mirjam joined #perl11
01:46 mirjam joined #perl11
01:51 rurban1 joined #perl11
03:04 stevan joined #perl11
03:13 mirjam joined #perl11
03:13 mirjam left #perl11
03:20 mirjam joined #perl11
04:09 Will_the_Chill joined #perl11
04:26 mirjam joined #perl11
05:56 mirjam joined #perl11
06:21 mirjam joined #perl11
06:39 rurban1 joined #perl11
06:44 Will_the_Chill bulk88: "Many operations return undef to indicate failure, end of file, system error, uninitialized variable, and other exceptional conditions."
06:44 Will_the_Chill from http://perldoc.perl.org/functions/defined.html
06:45 Will_the_Chill I might need to simulate or re-implement "undef" and "defined"
06:47 Will_the_Chill "pop" returns undef on an empty array, etc.
06:48 Will_the_Chill I can't break pop.
06:49 Will_the_Chill I can, however, ban the use of the "undef" function, and only allow the "defined" function for variables (not subroutines or other magic)
06:50 Will_the_Chill likewise only allow the "exists" function for hash keys (becomes map::count in C++), disallow "exists" for subroutines etc
06:51 Will_the_Chill oops, I mean only allow the "defined" function for variables and builtin function return values, not subroutines or other magic
06:55 bulk88 my point was, in P5 SV, undef and 0 are separate states, but in C/machine integers undef and 0 are both 0, so either undef is eliminated as a concept, (0 and undef have identical meaning, perl subs dont return a "0 but success" state, or 2 ints will be carried around, 1 int is the undef or not flag, the other int is IV value, or steal the top bit of the C int to mean undef or not (also that
06:55 bulk88 means undef is <0,), its complicated)
06:56 bulk88 there is your int * strategy too for undef
06:57 bulk88 C's anwer to the problem is, functions don't return counts, they return error codes, 0 is success, your "count" is a passed unsigned int *
06:58 bulk88 technically the C function could return a return by copy struct, quite a rare construct in C, then you look inside the struct at the undef and IV members
06:59 bulk88 in i386/WIN32, a 2 word (aka 64 bit) return by copy struct is returned in pure registers (eax for low 4, edx for high 4), on WIN64, a returned struct bigger than 8 bytes, becomes a secret struct * parameter as the 1st parameter of the function
06:59 bulk88 same same happens on WIN32 when the return by copy struct is too big
07:00 bulk88 to fit in the register/s allocated for return values
07:00 Will_the_Chill I guess I've never heard of the "return by copy struct"
07:01 Will_the_Chill and yes I totally understand that in P5 undef is not 0/FALSE, and that this does not obviously map to C/C++ machine types.
07:01 Will_the_Chill that's the issue.
07:01 bulk88 https://rt.perl.org/Ticket/Attachment/1265270/663939/0001-perl-115032-fix-multi-eval-of-Perl_custom_op_xop-in-.patch return by copy struct in this patch
07:01 bulk88 I added it
07:02 Will_the_Chill what can I type into google to help me search for this "return by copy struct" concept?
07:02 bulk88 http://pastebin.com/T2EKguET another example
07:03 bulk88 its a hack I once tried as an optimization
07:03 bulk88 http://stackoverflow.com/questions/9653072/return-a-struct-from-a-function-in-c
07:05 bulk88 note the warning, that on many platforms and scenarios, a secret struct * is added the incoming params by the caller
07:05 bulk88 *warning in comments on SO
07:05 Will_the_Chill reading SO now
07:10 Will_the_Chill okay good info, thinking about it
07:11 bulk88 it is an extremely rarely used feature of C, I've never seen it used anywhere, it works uneventfully
07:11 bulk88 I've used it myself as you can guess
07:11 Will_the_Chill the issue is, is it supported by Inline!
07:12 Will_the_Chill and of course it adds some overhead
07:12 bulk88 the point is, if the platform doesn't take a secret struct *, it is more efficient, if it puts a secret struct *, you are no worse than doing it the other way
07:13 Will_the_Chill and if I allowed use of the "undef" function (not value) anywhere, I'd have to allow it everywhere, so then all machine types would have to be wrapped in machine-type-plus-undef-bool structs
07:13 bulk88 which is an explicit struct *
07:13 Will_the_Chill however I think I can disallow the use of the "undef" function, but still allow the use of the "defined" function
07:13 bulk88 I dont have an opinion, usable conciousness is fading due to local wall time
07:14 Will_the_Chill roger that, haha, thanks!  :)
07:15 bulk88 Perl undef is quite handy when I write XS code, since its an alternative to number 0, and empty string, which are "true/success" in some places
07:16 bulk88 the way it sounds what you are doing with rperl, you won't need undef, since error and count will be to separate C vars at all times
07:16 Will_the_Chill yes we can use undef just fine when RPerl compiles to use Perl data types
07:16 Will_the_Chill just more complicated when RPerl compiles to use C/C++ data types (of course)
07:16 bulk88 or error and data will be separate
07:16 Will_the_Chill yes we can keep error/undef separate from data
07:18 Will_the_Chill so I'm back to thinking we ban the use of the "undef" function, and only allow the "defined" function for variables and builtin function/operator return values (like pop)
07:18 Will_the_Chill my sometype $foo = undef;  # RPerl error
07:19 bulk88 undef function on a optimized to machine type will be empty string or 0 always
07:19 bulk88 if sometype is a number, "my sometype $foo = undef;" compiles to "my sometype $foo = 0;"
07:20 Will_the_Chill if (defined pop(@{$my_arrayref})) {print "pop return not undef; } # no RPerl error
07:20 bulk88 in that case defined is checking error var, not data var of pop
07:21 bulk88 but defined on a static type should syntax error
07:21 bulk88 since int type $sv, will always be defined
07:21 Will_the_Chill no we don't want to allow "my numtype $foo = undef;" to compile into "my numtype $foo = 0;" because that changes the meaning of undef.
07:21 Will_the_Chill undef is definitely NOT the value 0.
07:22 Will_the_Chill I'd have to wrap all machine types in the defined-and-value 2-member struct to get the correct behavior
07:22 Will_the_Chill you are correct about using "defined" to check the error var, not the data var of pop
07:23 bulk88 does the code you have in mind already use "numtype"? if it doesn't use numtype, when it is rewritten to use numtype, at that time a human will make sure undef isn't used for signalling
07:24 bulk88 defined on an $sv should be banned, $defined on a function/operator is okay
07:24 bulk88 *defined
07:24 Will_the_Chill numtype is a pseudonym for "int", "float", "double", which all exist in RPerl already
07:25 bulk88 "my numtype $foo = 1; undef($foo); $foo += 0;" and "my numtype $foo = 0;" have the same meaning
07:25 Will_the_Chill I agree with "defined" on function/operator only EXCEPT what about "my int $foo = pop (@{$my_arrayref});  print "empty array" if not(defined $foo);" ???
07:25 Will_the_Chill in other words, what about storing the undef error val returned by a builtin?
07:25 Will_the_Chill storing that undef error value in a variable and then later using "defined" on that variable?
07:26 Will_the_Chill that goes back again to requiring all machine types to be wrapped in the defined-and-value 2-member struct
07:26 bulk88 optimizer/compiler has to see that/trace the flow of the return value of pop and propogate error var's scope to the test
07:26 bulk88 if there are random irrelavent statements inbetween, give up and declare the sub unoptimizable (initially)
07:27 bulk88 *inbetween the error var setter (pop), and error var test (defined)
07:27 Will_the_Chill yes I understand...  hrm
07:27 Will_the_Chill "hrm" is me being internally conflicted
07:27 bulk88 I dont design compilers for a living, I just bitch at compiler designers
07:28 Will_the_Chill I don't want the compiler to have to keep track of that
07:28 Will_the_Chill so I'd either implement the all-vars-are-wrapped-in-structs strategy or the only-allow-defined-on-direct-retvals strategy
07:28 Will_the_Chill HRM
07:28 bulk88 http://en.wikipedia.org/wiki/Liveness_analysis this is why I dont do CS :-D
07:29 bulk88 wrong link
07:29 bulk88 http://en.wikipedia.org/wiki/Data-flow_analysis
07:29 Will_the_Chill yeah I know all about that stuff, I just don't want much of it in RPerl v1.0
07:29 bulk88 " only-allow-defined-on-direct-retvals strategy" id go with that, it is the easiest
07:29 Will_the_Chill it will all be added into future versions  :)
07:30 bulk88 pick the easiest to write regexps of Perl code that can be optimized
07:30 bulk88 dont get adventourus
07:30 bulk88 dont analyse between perl subs
07:30 bulk88 dont auto inline
07:30 Will_the_Chill regexps???
07:30 Will_the_Chill where did your regular expressions comment come from?
07:31 bulk88 regexps=whatever RPerl uses to decide if a sub is optimizable by it or not
07:31 Will_the_Chill oh okay gotcha, the RPerl parser.  :)
07:32 Will_the_Chill the problem with only-allow-defined-on-direct-retvals strategy is "defined pop(@{$my_arrayref})" throws away the return value!
07:32 Will_the_Chill hmm I guess we could use peek instead in this case, but that only works in this case.
07:32 bulk88 "defined($var = pop(" no other construct allowed
07:33 bulk88 next instance of $var has lost undef-ness
07:33 Will_the_Chill yes you're right, that's what I was thinking, allow another special one-liner construct like we did with map/grep lexical-form-only
07:33 bulk88 so defined ($var) errors/not optimizable
07:33 Will_the_Chill I THINK THAT IS THE ANSWER MY FRIEND!  :D
07:34 Will_the_Chill thank you for helping me figure that out.  it may have been the very last item for me to figure out before publishing.  :)
07:44 bulk88 im leaving for tonight
07:44 Will_the_Chill okay, g'night, thanks!  :D
12:45 Will_the_Chill joined #perl11
14:28 rurban1 joined #perl11
14:37 mirjam joined #perl11
14:44 bluescreen joined #perl11
14:49 bluescreen joined #perl11
15:20 rurban1 joined #perl11
15:37 Will_the_Chill bulk88: http://rperl.org/the_low_magic_perl_commandments.html
15:37 Will_the_Chill rurban: you too!
15:38 Will_the_Chill bluescreen: you too!  ;)   http://rperl.org/the_low_magic_perl_commandments.html
15:40 Will_the_Chill bluescreen: this you?  just sent a friend request...  https://www.facebook.com/mariano.wahlmann
15:49 * rurban waking up
15:50 rurban Will_the_Chill: can we have a proper left padding on the page?
15:51 Will_the_Chill rurban: sure, but need more info?
15:51 rurban "use types" is not possible yet. this is just a wishlist item
15:51 Will_the_Chill WRONG!  use types is already implemented in RPerl!  get with the program, man.
15:51 rurban And I basically gave up on it for this season
15:51 rurban Oh, great!
15:51 Will_the_Chill yes super great!
15:52 rurban const_int as type? not as seperate const specifier?
15:52 Will_the_Chill also, now that you are awake, it is almost my bed time, haha!
15:52 Will_the_Chill no separate const specifier for now
15:52 Will_the_Chill if we need to break apart later, that's fine
15:52 Will_the_Chill for now it is together
15:52 Will_the_Chill that's how I've implemented it
15:52 rurban I was reading yves hash explanation and I'm not excited
15:52 Will_the_Chill yves?
15:53 Will_the_Chill what is yves?
15:53 rurban yves orton = demerphq
15:54 rurban http://blog.booking.com/hardening-perls-hash-function.html
15:55 rurban Kent Frederic makes a good point about known member functions/attributes
15:56 Will_the_Chill hashes become C++11 maps
15:56 Will_the_Chill PROBLEM SOLVED
15:56 Will_the_Chill already implemented in RPerl!
15:56 rurban yes
15:56 Will_the_Chill ALREADY DONE
15:57 rurban but for compile-time closed classes, members should not be stored in hashes.
15:57 Will_the_Chill what was your comment about proper left alignment on the web page?
15:57 Will_the_Chill RPerl classes -> C++ classes
15:57 Will_the_Chill blessed hashes go away at compile time
15:57 rurban they should be in a vtable with instant lookup
15:57 Will_the_Chill PROBLEM SOLVED
15:57 Will_the_Chill already implemented in RPerl!
15:57 rurban really? great
15:58 Will_the_Chill super great!
15:58 Will_the_Chill that's why RPerl will win the Perl wars
15:58 Will_the_Chill ;)
15:58 rurban I'll check it out next week. my folks found a lot of new B::C compiler bugs with the core testsuite, so I'm pretty busy
15:59 Will_the_Chill I think I might take over the B::CC namespace with RPerl, since Malcolm Beattie is long gone and after looking at the existing B::CC with you I know it will never get fixed.
15:59 Will_the_Chill of course B::C stays the same.  :)
15:59 Will_the_Chill RPerl _is_ the new B::CC!
16:00 rurban RPerl is pretty strict on the user though. but B::CC is not stable
16:00 bluescreen Will_the_Chill: that's in fact me! good networking skills
16:01 rurban Did you run the shooutout benchmarks already?
16:02 Will_the_Chill rurban: no I will not have the ability to run the shootouts until later this month at the earliest, maybe not until next month
16:03 Will_the_Chill the dang commandments took me longer than I'd anticipated
16:03 rurban I'll wait. You might be even faster than p2
16:03 Will_the_Chill I AM FASTER THAN EVERYBODY PUT TOGETHER!!!
16:03 Will_the_Chill RPerl compiles STRAIGHT INTO C/C++!
16:04 Will_the_Chill When I told chromatic that I wanted "the speed of C" and he mocked me, well, he'll get his!
16:04 rurban goccy probably not. gperl uses llvm optimizations which are hard to beat
16:05 Will_the_Chill WRONG!  Faster than GPerl because I can feed my RPerl-to-C code into LLVM to get LLVM bytecode, then do the same with the Perl 5 guts C code to get LLVM bytecode, then combine the 2 LLVM bytecodes and apply global optimizations.  I WIN AGAIN!
16:05 Will_the_Chill NOBODY WILL EVER BE FASTER THAN ME.
16:05 Will_the_Chill period.  I will bet money.
16:05 Will_the_Chill so anything goccy can get, I will get MORE
16:05 Will_the_Chill because I will cut out all the slow magic AND get LLVM optimizations
16:06 rurban he had the same ideas as you and me :)
16:07 rurban gperl is also some kind of no magic
16:07 rurban But I'm not sure if he has const/:ro already
16:08 Will_the_Chill I will battle everyone for the ultimate speed, failure is not an option!
16:09 Will_the_Chill I mean seriously, who can beat the speed of pure C?  LLVM just makes my C faster.
16:09 rurban yes, but for the sake of expressiveness and dynamicism
16:10 Will_the_Chill dynamicism must be curtailed, expressiveness must be separated from pure sugar
16:14 Will_the_Chill the sharpened sword of RPerl will cut it all away!
16:15 Will_the_Chill the scallions of RPerl will provide a low-calorie onion alternative!
16:15 Will_the_Chill the roadrunner of RPerl will RUN FASTER THAN ANYBODY ELSE!
16:15 Will_the_Chill gperl is a firebird
16:16 Will_the_Chill perlito is a guarana berry
16:16 Will_the_Chill :)
16:55 renormalist joined #perl11
16:56 rurban1 joined #perl11
17:13 mirjam joined #perl11
17:22 Will_the_Chill rurban: what does proper left padding mean for the website?
17:24 rurban1 joined #perl11
17:30 mirjam joined #perl11
18:31 rurban1 joined #perl11
18:38 rurban I want to see the left side of the webpage. send you a pic on fb
19:25 mirjam left #perl11
19:37 mirjam joined #perl11
19:43 rurban1 joined #perl11
19:59 rurban1 joined #perl11
20:40 mirjam joined #perl11
21:21 mirjam joined #perl11
21:32 rurban1 joined #perl11
21:54 rurban1 joined #perl11
21:56 rurban2 joined #perl11
22:58 rurban1 joined #perl11

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