Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-05-17

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

All times shown according to UTC.

Time Nick Message
02:15 zakharyas joined #moarvm
06:13 domidumont joined #moarvm
06:18 domidumont joined #moarvm
07:57 dalek joined #moarvm
08:50 nwc10 *what* just killed dalek? I can't spot any repositories that updated
08:51 nine nwc10: rakudo
08:52 nwc10 ah OK thanks
09:04 cognominal joined #moarvm
10:14 harrow joined #moarvm
10:50 harrow joined #moarvm
10:58 dalek joined #moarvm
11:16 andrmuel joined #moarvm
11:17 andrmuel hi
11:18 timotimo greetings
12:01 zakharyas joined #moarvm
13:08 hoelzro joined #moarvm
13:14 cognominal joined #moarvm
13:23 njmurphy joined #moarvm
13:39 lizmat joined #moarvm
17:14 mst 18:04 < nine> Got it: http://irclog.perlgeek.de/moarvm/2016-02-27#i_12108919
17:14 mst 18:04 < nine> It's a naming issue...
17:14 mst 18:07 < mst> right, I'm thinking it should be possible to have something along  the lines of 'the thing "use B" imports into my current namespace  as Foo'
17:14 mst jnthn: ^^ wonder how easy that would be, given how much less pain we'd get from precomp with just that
17:15 * mst feels like "one should only need to precomp once per API version" isn't completely insane, and should, at least in theory, be doable for simple cases, but I reserve the right to have been completely stupid here
17:16 jnthn What is an API version in this context?
17:18 nine jnthn: talking about avoiding recompilation of reverse dependencies on compatible changes to modules
17:18 jnthn What's a compatible change?
17:18 nine one where the module's API is unchanged, i.e. no change on the user's side necessary
17:19 nine I.e. just like it is with shared libraries in C.
17:19 jnthn Is this leading down the "make precomp be somehting other than static linking"?
17:19 nine yes :)
17:20 jnthn s/?/road?/
17:20 jnthn I really, really, don't want to go down that road.
17:20 jnthn If somebody says that I don't have to care about precomp ever again, then they're free to try. :)
17:21 jnthn But so far as I can tell, it's fraught enough I just don't want to go there.
17:21 jnthn I always intended precomps as cache
17:22 mst which is fine, but more intelligent cache expiry would still be nice
17:24 mst jnthn: I'm not sure what makes it that fraught
17:24 jnthn mst: The lack of any kind of absolute naming.
17:24 nine If there ever was a possibility to not have to recompile rev-deps, the whole precomp management code is gonna need a redesign. Again.
17:24 geekosaur recompilation of reverse deps is itself fraught
17:24 nine geekosaur: why?
17:25 mst jnthn: I can see that making it hard to do universally. I don't see why that means we can't make simple cases work
17:25 mst jnthn: I mean, like, a thing marked 'is export', and then a caller that does a 'use' of the module containing the thing, that's a stable name, even if it isn't absolute
17:26 jnthn mst: People already find it hard enough to avoid the various things that aren't precomp-safe already. Why do we want a second level of edge cases?
17:26 geekosaur I can see a situation where (a) some revdeps end up thrashing because their deps are changing so much (b) potential for diamond deps, or need to do multiple such recompiles to cover all versions of deps (also see Haskell's so-called "cabal hell")
17:27 geekosaur the kind of tight dependencies that p6 and ghc introduce make things *really* difficult
17:27 nine Why would their deps change so much? That would need someone install/update modules all the time?
17:27 mst jnthn: because it's a cache, and not blowing out caches unnecessarily is a good thing
17:28 geekosaur if they're not changing that much then this isn't a problem. the fact that it's coming up indicates that it *is* a problem
17:28 domidumont joined #moarvm
17:29 mst geekosaur: you're assuming things about the situation that aren't true
17:29 mst I'm thinking about basically vendor packaging and being able to ship precomp files from the build server and not having to re-precomp them every single bloody time
17:29 domidumont joined #moarvm
17:30 geekosaur somehow I thought I was talking about that as well, could you explain what I was mistakenly talking about, then?
17:31 mst you said "the fact it's coming up indicates that it is a problem", and are calling recompilation fraught
17:31 mst I don't understand what you're saying, but it doesn't seem related to what I was talking about
17:35 mst jnthn: also, your "people have enough trouble avoiding" ... what things are people ending up doing that spanners precomp?
17:35 jnthn mst: Monkeying with MOP stuff in module mainlines rather than at BEGIN time is the most common one
17:36 mst right, so, that seems like something one could warn() about
17:36 mst I mean
17:37 mst something like a 'use ICareAboutPrecomp::PleaseWarnMe;'
17:37 nine geekosaur: cabal hell seems unrelated to our discussion
17:37 jnthn Possibly, yes
17:37 mst and that would point out that custom exporters will also fuck things up
17:37 mst as well
17:37 jnthn Custom exporters aren't a problem
17:38 mst they are for the thing I was talking about a few minutes ago
17:38 jnthn Unless you expect them to run at runtime :)
17:38 mst well, some forms of dynamic exporting presumably would be
17:39 mst but, my point is, you're calling it 'edge cases'
17:39 mst I'm thinking 'things you can be warned about'
17:39 jnthn But in general, the custom exporter runs at import time of the using module and the results are serialized into the importer, which works out fine enough.
17:40 jnthn Yes, I suspect we can do better at warning about them. Don't immediately see how to implement it, but possible.
17:40 mst yes, it works out fine enough now under the static linking model
17:40 mst I am talking about a possible future where precompilation is a little bit more resuable
17:40 mst you said 'users find it hard enough', I'm talking about ways of making it easier for them to not screw it up
17:40 mst thereby making the feature I was imagining potentially more useful
17:41 nine I don't think it would change anything in that regard?
17:41 mst what
17:41 mst dude, this conversation is confused enough, specify which 'it', what regard, and what you mean by change, please
17:41 mst because I am way not capable of guessing ;)
17:42 nine I don't think more dynamical linking would change anything with regards to custom exporters.
17:43 mst ah, hrm, I guess even a custom exporter is basically exporting a (moral equivalent of) hash of names to things?
17:43 mst the thing is, if it's always the same names to the same things, you're fine
17:43 nine Yes. And those will be serialized into the caller's serialization context and therefore precomp file
17:44 mst if it generates a new copy of whatever_name each time, THAT will spoon things up
17:44 mst right, and at that point, you're going to have to re-precomp to check they didn't change
17:44 mst whereas if it's purely "I am exporting these names to the outside as alias to these names on the inside"
17:44 mst *that* can be dynlinked
17:45 mst nine: does that make a bit more sense?
17:46 nine A move towards more dynamical linking would get us into the whole "detect when it's safe to use the newer version" game which AFAIK no one has ever won yet.
17:46 jnthn fwiw, I made the "we'll do static linking" design decision about 5 years ago, back when doing the initial 6model design. So the assumption is likely to be baked into places that don't even occur to me right away as a result.
17:47 nine As I mentioned, right now it's "dependency changed -> recompile". Then it would be "dependency changed -> find out if we need to recompile (but how???) -> recompile?
17:47 mst yes, it's not a completely trivial problem, but it is one I've done quite a bit of thinking about in other contexts
17:48 mst and I have completely the wrong skillset to be helpful at making the compiler faster, but I happen to be a suitable sort of insane for trying to figure out how to run it less often
17:50 nine Well the worst possible outcome is always just the gaining of knowledge :)
17:50 mst nine: also, I know how to define a version of that game I *can* win
17:51 mst I'm sure the fully general version is about as tractable as go
17:51 jnthn .oO( and that's why go does static linking :P )
17:53 mst jnthn: and that's why many sysadmins hate go and consider it a weak point of their infrastructure
17:54 mst also go is fucking hilarious, they don't even have API versioning, the answer to "what if I want to deprecate something" is apparently "pick a new namespace"
17:54 mst it's very much optimised for a world where everything's getting rewritten from scratch all the time
17:55 mst perl6 is trying to be a hundred year language; go doesn't seem to care about lasting longer than a teenage boy after a week at church camp
17:58 mst jnthn: part of why I care about this, btw, is that I end up spending a fair chunk of my life trying to find/fix bugs that are N layers deep in modules
17:58 mst if I'm not changing the API, only trying to repro and then fix a weird behaviour
17:58 mst I don't want to have to re-compile all the layers above that I didn't change for every test cycle
17:59 mst I didn't realise quite how much I cared about that until I noticed just how much happier I was running t/foo.t for a Moo project than a Moose one
17:59 mst at which point I realised that, no, although I hadn't realised it would be, this is at least for me a major usability issue
18:00 mst also, presumably one could test this by repatching the object ids or something
18:00 mst rather than expecting anything else to change first
18:00 nine mst: try working on rakudo's JVM backend. A mere minute compile/test cycle will feel like hyper speed then :)
18:01 mst which is, yes, insane, but might make it possible for a sufficiently crazy mere mortal to try and prove the concept
18:01 mst hm
18:01 mst I think I just talked myself into a corner where I don't get to complain any more without trying it
18:01 mst fuck
18:01 nine :)
18:01 mst nine: so, basically, "that would be why I don't use clojure"
18:04 jnthn mst: So, to help me understand... If you're doing this in, say, Perl 5, which doesn't precomp, you're *already* recompliing everything every time on every run anyway. And so it feels like shoving a "no precompilation;" in your top level test script would get you the same thing you're used to for debugging purposes. What am I missing?
18:04 jnthn (Other than, I guess, that you're wanting to solve a more general problem...)
18:05 jnthn (But I'm curious what I'm missing in this use case.)
18:05 mst um. the compilation speed.
18:05 mst I keep ripping Moose out of things in favour of Moo specifically so that 'recompiling every time' isn't ridiculously painful
18:06 jnthn OK, understood.
18:06 mst or should I expect rakudo to be able to compile things at the speed that Moo does, and the current performance is an aberration that will be easy to fix?
18:06 jnthn mst: Well, I expect performance to get a lot better. Though it's more "lots of things to fix" rather than "one easy thing to fix"
18:07 mst right
18:07 mst but given you *do* have a full MOP, I'd imagine that it'll still be Moose-level better at least for the forseeable future
18:07 jnthn *Personally*, I'd still rather be doing those things than trying to make dynamic linking work out with Perl 6 :)
18:08 ilbot3 joined #moarvm
18:08 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
18:08 mst you're a windows user, you're used to installers basically eating your entire machine for half an hour - I'm not ;)
18:10 jnthn ;)
18:10 jnthn Dinner time; I'll bbiab
18:20 nwc10 mst: sideways to the discussion here which I'm afraid I can't usefully add to
18:22 nwc10 "it's very much optimised for a world where everything's getting rewritten from scratch all the time" - without using it directly, I concluded roughly that - as best I can work out it's optimised in many ways for Google's use case of "want to be able to rebuild the entire world in a reasonable time" (IIRC about 45 minutes) and "we control the entire dependency tree upstream and downstream" (which combined mean that you test stuff by building it all, a
18:22 nwc10 (and that probably got truncated)
18:23 nwc10 ... and if you find problems you fix your code, or you fix your deps, or you fix the stuff that depends on you, and any of those 3 is equally easy and viable
18:23 nwc10 ++
18:23 mst right, and also their situation where services usually don't have a lifespan of more than 18mo
18:24 nwc10 aha, missed thinking about that :-)
18:24 nwc10 anyway, this isn't where I find myself, usually.
18:24 mst right, same
18:45 timotimo i just had lovely dinner
18:50 nine dinner++
19:39 Ven joined #moarvm
19:47 pyrimidine joined #moarvm
20:57 Ven joined #moarvm
22:20 ggoebel116 joined #moarvm
23:52 lizmat joined #moarvm

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