Perl 6 - the future is here, just unevenly distributed

IRC log for #perl11, 2016-07-31

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

All times shown according to UTC.

Time Nick Message
04:59 willthechill bulk88: hi!  :-)
05:01 willthechill kentnl: I bet if we worked together then we could figure out a way to do run-time includes in C++
05:01 willthechill and have it serve the purposes of your project
05:02 willthechill although I still think it would be alot easier to try something a bit easier first.  :-)
05:02 willthechill alot easier, or a bit easier, that is the question, haha!  :-P  well easier, either way!
05:03 willthechill bulk88: are we failing on anything at all any more?
05:03 kentnl I don't know enough about internals in C++, but I do know "Dynamic Loading" is a thing that works ( .so plugins ), and that the reason it works is ld. basically duct-tapes exported symbols together, so its just a matter of compiling the various dependencies in the right way so that the symbols are visible.
05:03 willthechill bulk88: or are we now actually passing all tests everywhere?
05:04 willthechill kentnl: yes we could do something like that if we actually compiled all the subdependencies into C++ as well
05:04 kentnl and then as long as a given .so has a function that returns a list of strings ( ie: Mangled _Perl_Internal_Pacakge_Name__symbols ) you could "fake" at least they key-part of symbol tables.
05:05 willthechill *nods*
05:05 willthechill right
05:05 willthechill so I think that is further down the road, because we don't have any idea what kind of Perl code is in the subdependencies, so it will be a while before we can actually compile all of them as well
05:06 willthechill meanwhile we can do it a different way
05:06 willthechill calling from C++ back into Perl
05:06 willthechill and then doing a runtime eval from Perl-space
05:06 willthechill and then passing symbol table stuff back from Perl to C++
05:06 willthechill that does not require C++ "Dynamic Loading"
05:07 willthechill and we are already fully compatible with perl.h
05:07 kentnl the joy there will be eventually doing foreign-function calls natively.
05:07 willthechill yes you are 100% correct
05:07 willthechill you are smart.  :-)
05:07 kentnl this is where I'm basically seeing RPerl in a few years: Being able to be used in the sorts of binary tasks all the "cool" kids are trying to use Go for.
05:08 kentnl and then with a bit of luck, you can foreign-function call a system pumpkin-perl in a few places.
05:08 willthechill yes correct
05:09 willthechill the 'eval' operator is already parsable by the RPerl grammar
05:09 willthechill https://github.com/wbraswell/rperl/blob/master/lib/RPerl/Grammar.eyp#L79-L80
05:09 willthechill all we have to do is implement it
05:09 willthechill in the manner I just described
05:10 willthechill and we have a new doc that helps explain how to implement RPerl operators
05:10 willthechill https://github.com/wbraswell/rperl/blob/master/docs/devs_getting_started.txt
05:10 * kentnl is more thinking of the problem where only pumpkin perl can really work with existing XS modules, so you'd be dynaloading that perl library for its symbols the XS needs.
05:10 willthechill yes I want to go through perl.h and friends to handle XS
05:10 willthechill I don't want to try to talk directly to XS on our own
05:10 willthechill but we need to have full XS compatibility
05:11 willthechill so we just use the existing Pumpkin Perl 5 code to provide XS compatibility
05:11 willthechill in the end they can truly say that "only Perl 5 was compatible with Perl 5" because anyone who wants to work with CPAN must support XS, and only Perl 5 core can properly and 100% fully support XS
05:11 willthechill and all of us who want to have 100% full XS support must go through Pumpkin to get it
05:12 willthechill so ActivePerl and cperl and RPerl are all "real" Perl as soon as we have XS support, ha!  ;-P
05:12 willthechill I'm being a LITTLE facetious but not really
05:13 kentnl RPerl can do one thing at a "systems" level you can't do with cperl/pumpkin/active perl. Like, I've considered making using cperl/stableperl a thing end users can do on Gentoo, but its a lot of work to pull of correctly, and there's lots of giant black and yellow stripes around replacing system perl with something non-system Perl.
05:14 kentnl RPerl doesn't "compete" for "The perl implementation" conceptually, so we can get in on that much faster.
05:14 willthechill true
05:14 willthechill although once we have a fully-functional eval operator, then we will basically have the ability to do "Inline::Perl" inside of RPerl
05:15 willthechill ha!
05:15 willthechill as in "don't compile this code, use Perl to run it interpreted and fully dynamically instead of compiling into C++"
05:39 ribasushi <willthechill> in the end they can truly say that "only Perl 5 was compatible with Perl 5" because anyone who wants to work with CPAN must support XS, and only Perl 5 core can properly and 100% fully support XS
05:39 ribasushi willthechill: ^^ this is objectively incorrect
05:39 ribasushi there has been a lot of groundwork to have usable CPAN without any compiler/XS
05:39 ribasushi truly few rough edges remain (most solvable, just enotime)
05:40 ribasushi willthechill: but e.g. Moo, IO::Async and iirc Plack are all xs-free
05:41 willthechill ribasushi: good point, but anything less than 100% support of CPAN does not fit with my argument
05:41 ribasushi nod, I just wanted to counter the "CPAN without XS is useless" mantra ;)
05:43 willthechill oh yes I know, both of my CPAN releases (MathPerl, PhysicsPerl) do not include hand-coded XS
05:44 willthechill I am not in support of creating hand-coded XS
05:45 willthechill but we DO need XS for both 100% CPAN support and also for Inline::CPP
06:18 bulk88 ribasushi what is ur definition of xs-ofree? you mean not a single XS SO in the proc?
06:19 ribasushi bulk88: of course not, don't be silly
06:19 ribasushi xsfree == no need to get stuff off CPAN that needs a compiler
06:20 ribasushi yes, there are some things that come with perl that can't be done "without an .so", e.g. weaken()
06:20 ribasushi but these are few and far between and something like rperl can simply provide them natively and be done with it
06:20 ribasushi ( depends how the memory/lifecycle model of rperl works anyway )
06:20 bulk88 thats semantics, if u say libffi is part of "Kcore" then u never need a C compiler
06:21 bulk88 u will still have c headaches with ffi:: and friends
06:22 ribasushi bulk88: I won't have time to indulge your "devils advocate" hypothetical today, sorry, got to go
06:22 * kentnl isn't sure how libffi eliminates "there are dists built on XS on CPAN which need a compiler to work"
06:23 willthechill LOL devil's advocate  :-P
06:23 willthechill you guys are funny
06:24 willthechill bulk88: what do we need to do to get appveyor unfrozen?
07:06 willthechill joined #perl11
09:24 travis-ci perl11/cperl#1365 (smoke/gh126-mderef_u - a792ee8 : Reini Urban): The build passed. https://travis-ci.org/perl11/cperl/builds/148641280
11:47 travis-ci RPerl build passed. Will Braswell says 'Learning RPerl, If Control Structure, Part 3; User Input; While Control Structure, Part 1'
11:47 travis-ci https://travis-ci.org/wbraswell/rperl/builds/148654294 https://github.com/wbraswell/rperl/compare/ee4da1cc1bb3...07694c39336e
12:26 willthechill yay
12:28 travis-ci perl11/cperl#1366 (master - a792ee8 : Reini Urban): The build passed. https://travis-ci.org/perl11/cperl/builds/148657513
13:48 travis-ci perl11/cperl#1367 (maint-5.24c - 60407aa : Reini Urban): The build passed. https://travis-ci.org/perl11/cperl/builds/148666965
16:05 mako joined #perl11
17:13 willthechill joined #perl11
19:41 willthechill joined #perl11
19:48 mako left #perl11
22:08 willthechill bulk88: are we still failing on any tests?

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