Perl 6 - the future is here, just unevenly distributed

IRC log for #inline, 2014-12-29

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

All times shown according to UTC.

Time Nick Message
01:06 ingy sivoais: thanks
01:08 ingy mst: the point of Alt is to install over the original, not coexist with it
01:09 ingy ether: Alt modules are not loaded
01:09 ingy the Alt:: module is just a handle for installation
01:10 mst ingy: then it can't be released to cpan
01:10 ingy of something meant to replace the original
01:10 mst or it can't actually install without an env var set
01:10 mst or something
01:10 mst otherwise you're just creating problems
01:11 mst if it gets indexed, at all, under any name, it needs to play nice
01:11 mst if it won't, don't cpan it
01:11 ingy the solution is (likely) that smokers don't install Alts
01:11 mst no
01:11 mst that's like "the smokers are at fault because I'm monkeypatching everything"
01:11 ingy only the Alt:: gets indexed
01:11 mst if you think that's sane, you wanted ruby, not perl
01:11 mst not sufficient
01:11 mst the Alt:: needs to protect its users from destroying existing installations
01:12 mst or it can't go into the cpan index at all
01:12 ingy no way
01:12 mst yes way
01:12 ingy ok sorry we disagree
01:12 ingy read the Alt doc
01:12 mst I have
01:12 mst don't mohawk me
01:13 ingy wtf does that mean
01:13 mst "solve this by convincing ingy not to" was andreas' response
01:13 mst if you'd rather ignore me and shit everywhere, I can always support patching pause to disallow it
01:13 mst me, I'd rather have the "not throwing a tantrum" solution
01:14 ingy you are going ballistic on me for no reason
01:14 mst but it's up to you, "sorry we disagree" isn't sufficient
01:14 ingy and I'm not in the mood
01:14 ingy you know I'll work on it with you
01:14 ingy as I always have
01:14 mst I'm not in the mood for you breaking shit because "progress"
01:14 mst and claiming "sorry we disagree" is an acceptable answer
01:14 mst so, yeah, you're mohawking me
01:15 ingy I'm out for now.
01:31 ingy ether: problem solved by deleting that module. mst made love and came up with a future possible solution. testing now. sorry for any troubles.
01:32 ingy *mst and ingy made love
01:32 ingy again…
01:32 ingy bbiab
01:54 GitHub144 [acme-math-xs-pm] ingydotnet pushed 1 new commit to xs: http://git.io/_F3WkA
01:54 GitHub144 acme-math-xs-pm/xs 652e785 Ingy döt Net: xs-0.0.20
01:55 GitHub140 [acme-math-xs-pm] ingydotnet tagged xs-0.0.20 at xs: http://git.io/F2rGTg
01:57 travis-ci ingydotnet/acme-math-xs-pm#133 (xs-0.0.20 - 652e785 : Ingy döt Net): The build passed.
01:57 travis-ci Change view : https://github.com/ingydotnet/acme-math-xs-pm/compare/xs-0.0.20
01:57 travis-ci Build details : http://travis-ci.org/ingydotnet/acme-math-xs-pm/builds/45317809
02:00 ether ingy: I understand that Alt modules are not loaded. I didn't say report on loaded modules, I said report on installed modules
02:01 ether and if there isn't an Alt::Foo::Bar actually installed into @INC, that's a problem, because then we can never ask "did the alternate Foo::Bar get installed?"
02:01 ether and I also understand that it overwrites, not coexists
02:01 ether it's this very fact that is causing issues
02:01 ether because htf is something else supposed to know if it's using the alternate Foo::Bar or the real one?
02:01 ether the toolchain has to know, for reporting
02:02 ether you can't stop "the smokers" from installing things, because the smokers are everyone
02:02 * ether sends cpantesters reports, and I'm not a smoker
02:03 ether mst is absolutely right here - you cannot index part of an Alt dist, because that lets alt modules get installed from a distance, without consent
02:03 ether installing an alt version has to be a consensual act on the part of the user
02:03 ether don't sneak it into their install without them knowing
02:04 mst the thing here is the tension between allowing a user to do "requires 'Alt::...';"
02:04 mst and people ending up with that that didn't expect it
02:05 ether +1 on making love :)
02:05 mst ingy: cpantesters aside, what bothers me here is users with multiple projects sharing a single local::lib
02:09 GitHub38 [acme-math-xs-pm] ingydotnet pushed 1 new commit to eumm: http://git.io/hR42Nw
02:09 GitHub38 acme-math-xs-pm/eumm fb5c2f0 Ingy döt Net: eumm-0.0.15
02:09 GitHub45 [acme-math-xs-pm] ingydotnet tagged eumm-0.0.15 at eumm: http://git.io/zkiGpw
02:12 travis-ci ingydotnet/acme-math-xs-pm#135 (eumm-0.0.15 - fb5c2f0 : Ingy döt Net): The build passed.
02:12 travis-ci Change view : https://github.com/ingydotnet/acme-math-xs-pm/compare/eumm-0.0.15
02:12 travis-ci Build details : http://travis-ci.org/ingydotnet/acme-math-xs-pm/builds/45318394
02:14 ingy I think there is still misunderstanding of Alt goals and actions. but let's concentrate on solutions for now.
02:14 ingy I'll reexplain more clearly the Alt vision and best practices once the dust is settled
02:15 ingy and we can have better discussions
04:08 ingy ether: I'm not entirely sure how a non-consensual situation would play out, outside the smoker scenario
04:09 ingy maybe let me know what you thought is and we can discuss it
04:09 ingy we can do it on #toolchain too
04:10 ingy just wanted to respond to you here
04:10 mst ingy: multiple projects, shared local::lib / site_perl / wjatever
04:10 mst 'sudo make installdeps'
04:12 ingy I don't follow. be more specific?
04:12 ingy the deps can never find the alternate versions
04:12 ingy or can they?
04:12 ingy I don't see how
04:18 ingy if the alternates that are depped on are not indexed, what installers could possibly find them?
04:19 ingy I'm talking about people who never installed an alt already, getting messed up by something that deps on something else and picking up an Alt
04:19 ingy which is what I think ether meant.
04:20 ingy we can talk about otehr threat models separately
05:39 ether ingy: the bit in your doc I object to is: "It is important to use the no_index directive on the modules you are providing an alternates for. "
05:39 ether that's not enough. *the entire distribution* should be no_index.
05:39 ether otherwise, something I use indirectly could add a dep on Alt::Foo::Bar and now I have a different Foo::Bar than I expected
05:40 ether that's the lack of consent I referred to
05:40 ether and that's how we end up with weird smoker reports - something at some point earlier installed the Alt version, and now other things have no idea that they're using the wrong thing, and I get failing cpantesters reports with a stack trace in Moo for a random module I wrote that uses Moose
05:41 ether I'd have no idea how to interpret those reports if I wasn't clued in to what was going on
05:41 ether i.e. with my ear to irc 24/7
06:06 ingy ether: I see your point, the theoretical one, that something you dep on could dep on an Alt.
06:06 ingy that's not what happened with Moo though
06:08 ether no, apparently not
06:08 ether what would help there is the smoker report including all Alt::* modules that it can find in @INC (not %INC)
06:10 ingy true. also now I suggest that alted modules use their Alt::
06:11 ingy one really simple rule to add would be to uninstall All-Foo-Bar after smoking it
06:11 ingy I'm also thinking of making Alt.pm be a base class for Alt:: that can do smart things
06:12 ingy like honor a ENV var
06:12 ingy can you even install dists with no indexed modules?
06:27 ether sure, by installing the tarball directly
06:27 ether and some clients know how to find unindexed dists, or specific versions, or even look in backpan
06:28 ether the Alt:: module is still indexed under the current process, I thought
06:28 mohawk do you think this discussion is better had on #toolchain?
06:28 mohawk for wider visibility
06:29 mohawk mst, you can make as many snide remarks about people having "tantrums" as you like, but it doesn't make it true
06:29 ingy mohawk: talk to mst privately
06:29 mohawk responding publically to a public remark
06:30 mohawk don't "mohawk" me
06:30 ingy yeah but more gasoline is not needed
06:30 ingy ether: yeah it is
06:31 ingy I found at least one module that deps on an Alt
06:31 ingy https://metacpan.org/requires/distribution/Alt-Crypt-RSA-BigInt?sort=[[2,1]]
06:32 ingy I'm going to make some PRs for Alt
06:32 ingy once we figure out what's best
06:33 ingy goodnight &
06:38 mohawk ingy, yeah, you're right
16:42 Fractal Hi all. At first I thought Inline::Module would let you create dists with no dependency on Inline at all, but it looks like that's just because it's bundling Inline::* in inc/?
16:42 Fractal wouldn't it be preferable to just bite the bullet and mark such dists as having build-time deps on Inline::whatever?
16:47 ingy Fractal: maybe. There's still work planned to do more author side.
16:47 ingy Fractal: what's your issue with the inc?
16:47 Fractal mostly just seemed odd/space-inefficient to me, no real problem
16:48 Fractal Also, I had an idea for how to make the FILTERS stuff more compatible with Inline::Module
16:48 Fractal Inline::Filters::Ragel <--- just uploaded that but I realised you'll need it at build time
16:49 Fractal sorry i mean run-time
16:49 Fractal if you could do FILTERS => [ [ 'ragel' => '-G2' ] ] and Inline would assume Inline::Filters::ragel or something
16:52 Fractal and only actually require it if it's in the build phase
16:52 ingy The inc solution is working. So now we are at a point where we can keep improving on it.
16:52 ingy I imagine it will keep getting better.
16:53 ingy mohawk had the idea to just dist .xs files
16:53 ingy but I'd like to evolve towards that so that nothing gets left behind
16:53 Fractal that is ideal IMO
16:54 ingy I'd like to see more Inline-based modules released first
16:55 ingy I'm not convinced that it would work in more complicated cases
16:55 ingy anyway we have time. the current system works well.
16:56 Fractal well.. in my case i want to avoid bundling my build toolchain in inc/.. it's embarrassing :)
16:56 Fractal i'll let you know how it goes to make it a build-time dep
16:56 Fractal should work fine i'd think
16:57 ingy well inc does have an advantage of always working, regardless of how deps change
16:57 Fractal any thought on the FILTERS stuff? i noticed it's a bit inconsistent between ISLMs..
16:57 Fractal FILTERS vs filters
16:58 ingy we made keywords be case insensitive
16:58 ingy and changed docs to lowercase
16:58 Fractal ahhh ok makes sense
16:58 ingy but we don't control ilsms
16:58 ingy so maybe send PRs
16:58 Fractal seems to me filtering logic would ideally be centralised in Inline itself
16:58 ingy I don't even recall what filtering is
16:59 ingy what is it?
16:59 Fractal it's described in the docs as a "source filter" applied before compilation
16:59 Fractal like stripping POD etc
16:59 * ingy takes a read
16:59 Fractal but i wanna use it with ragel which is kind of like a source filter too: https://metacpan.org/pod/Inline::Filters::Ragel
17:06 ingy So the problem is using Inline::Filters from a I:M module?
17:06 ingy can't you just dep on Inline::Filters::Ragel?
17:08 Fractal well first issue is that i don't want to "use Inline::Filters::Ragel" at run-time so i have to do something like FILTERS => [ sub { require Inline::Filters::Ragel; ... } ]
17:08 Fractal which is a bit ugly but that's ok
17:08 Fractal main issue is that i don't want people to have to have ragel installed just to build my module
17:08 Fractal ideally i'd run it at dist time and ship just the generated .xs files
17:09 ingy ragel looks interesting, though I can't dredge up much info on it
17:10 Fractal it's a really cool program.. it's mostly described in the "user's guide" PDF: http://www.colm.net/files/ragel/ragel-guide-6.9.pdf
17:11 Fractal the alternative is i make a Alien::Ragel type thing but i'd prefer to just ship the generated code
17:30 ingy Fractal: do you have a module that uses Ragel and Inline::Module?
17:30 Fractal i'm working on something but haven't uploaded it yet
17:30 ingy I might suggest getting it working and released first then filing the issues needed to make things more efficient
17:31 Fractal ok cool.. but you'd be open to a mode where it ships just the .xs?
17:31 Fractal may try hacking that up see how far i get
17:31 ingy I'm open to getting there
17:32 ingy and you are welcome to be on the Inline team
17:32 Fractal thanks.. i'm quite excited about Inline::Module actually
17:32 Fractal makes so much sense to do it that way
17:33 ingy thanks. it's really just a new open door. the start of something new, not the destination.
17:35 ingy bbiaw
17:36 Fractal actually i forgot.. i do have a dist that needs ragel: https://metacpan.org/source/FRACTAL/Qstruct-0.100/libqstruct/parser.rl
17:37 Fractal but it just assumes you have ragel.. probably explains why it has so many cpantester failures :)
17:38 Fractal but ya lemme try to get an I::M + ragel one out
17:46 sivoais Fractal: looked around your github. That Thrust binding looks really neat! <https://github.com/hoytech/Thrust>
18:08 Fractal thanks :)
18:09 Fractal ya.. having some trouble with windows support
18:24 davido_ I do like the notion of moving toward distributing the XS in the future, but it still presents challenges for Inline::CPP based distributions.
18:26 davido_ Distributing C++-based XS is sort of tricky (as mohawk knows), and Inline::CPP kind of helps to sweep that under the carpet.
18:29 Fractal also for ones like Inline::Java I think you'll need the bridging logic at run-time anyway
18:29 Fractal would be nice to have an optional mode you could enable for Inline::C ones at least though
18:31 davido_ I don't think the C++ issues are insurmountable, but they'll probably never be as rock solid as the C solutions.
18:32 davido_ There's so much fiddling; newer BSD's use clang++, older, g++, and so on.
18:32 davido_ with C, we just use whichever compiler compiled Perl.
18:32 Fractal ahh ya that makes sense
18:33 davido_ So sure, we can ship C++-based XS, but then we sort of lose control over how it gets compiled, and that shifts more work to EUMM and possibly the end user.
18:33 davido_ Whereas Inline::CPP already configures itself (using ExtUtils::CppGuess) to deal with various platforms.
18:36 davido_ But ultimately it still could be the way forward.
18:39 Fractal i think in theory Inline/Inline::Module could support all phases (run-time, build-time, dist-time) simultaneously so module authors can decide as appropriate
18:40 ingy back
18:40 Fractal develop in run-time mode, distribute in build-time mode, switch over to dist-time mode if you're doing wacky things with ragel like me :)
18:40 davido_ hey ingy
18:40 davido_ back from 3 days in vegas.
18:48 ingy :D
18:50 ingy so I thought of a way to do pure XS as an option
18:50 davido_ :)
18:50 davido_ just what we were discussing :)
18:51 ingy just add a param (pure_xs => 1)
18:51 ingy then we can keep it experimental
18:51 davido_ add where, in Makefile.PL => postamble => inline?
18:51 ingy yes
18:51 davido_ I'd like to see how that works out for Alt::M::P::FS
18:52 ingy you need more than just XS though
18:52 davido_ I think we end up still with eucg
18:52 davido_ yeah, you need the .h files, for one thing.
18:52 ingy yes
18:52 davido_ and in the case of c++, you need a plan for how to compiler.
18:52 davido_ compile
18:52 ingy the way to do it is create a subdir with a Makefile.PL in it
18:53 davido_ hm.
18:53 davido_ never thought of that.
18:53 ingy let's not worry about c++ for now :)
18:53 davido_ :)
18:53 ingy we can still bundle *some* things
18:54 ingy bundling in inc/ is not a bad thing, honestly
18:54 ingy it's been used en masse for over a decade
18:54 ingy all Module::Install modules do it
18:54 davido_ yeah.
18:55 davido_ is just freezes a dist to a specific toolchain. why is that bad?
18:55 ingy and it ensures that you don't have API mismatches
18:55 ingy it's actually good
18:55 ingy for non-stable stuff
18:55 davido_ exactly.
18:55 Fractal it's bad if a bug is discovered in the version you froze.. you have to go re-release all modules that bundled it
18:55 ingy like TestML
18:56 ingy Fractal: that's actually good
18:56 ingy because you have control
18:57 Fractal well there are good and bad aspects to it
18:57 ingy anyway, it's a tool that has a place
18:57 Fractal same as static vs dynamic linking
18:57 ingy yeah
18:58 davido_ well, it's one thing to bundle a Digest::SHA, and then lock people in to a potential hashing bug.  It's another to bundle some aspects of the toolchain.
18:59 Fractal fair enough.. but re-releasing dists just to fix bugs in bundled deps is counter-productive IMO
19:08 mst Fractal: it's a trade-off.
19:08 Fractal yes
19:08 mst 'counter-productive' is just picking one side of the trade-off and then pretending it's always right
19:09 mst using inc/ is a time-honoured approach
19:09 mst sometimes it's the best possible answer
19:09 mst sometimes it's a terrible idea
19:10 Fractal 14:00 < Fractal> same as static vs dynamic linking
19:11 Fractal obviously there are arguments pro and con
19:11 Fractal you have the unix model where everything is dynamically linked and sometimes your whole system breaks catastrophically
19:11 Fractal and you have the windows model where everything is static and ppl are exploiting bugs that were supposedly patched a decade ago :)
20:34 GitHub71 [Devel-GlobalDestruction-XS] ingydotnet pushed 2 new commits to alt-inline: http://git.io/orwaKQ
20:34 GitHub71 Devel-GlobalDestruction-XS/alt-inline 327af9b Ingy döt Net: Regenerated stub
20:34 GitHub71 Devel-GlobalDestruction-XS/alt-inline c77356b Ingy döt Net: This commit should make this module safe to smoke...
23:15 GitHub181 [acme-math-xs-pm] ingydotnet pushed 1 new commit to eumm: http://git.io/f7BgYw
23:15 GitHub181 acme-math-xs-pm/eumm 991e29a Ingy döt Net: Update to latest Alt best practices.
23:20 travis-ci ingydotnet/acme-math-xs-pm#137 (eumm-0.0.16 - 991e29a : Ingy döt Net): The build passed.
23:20 travis-ci Change view : https://github.com/ingydotnet/acme-math-xs-pm/compare/eumm-0.0.16
23:20 travis-ci Build details : http://travis-ci.org/ingydotnet/acme-math-xs-pm/builds/45402862

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