02:15 zakharyas joined 06:13 domidumont joined 06:18 domidumont joined 07:57 dalek joined
nwc10 *what* just killed dalek? I can't spot any repositories that updated 08:50
nine nwc10: rakudo 08:51
nwc10 ah OK thanks 08:52
09:04 cognominal joined 10:14 harrow joined 10:50 harrow joined 10:58 dalek joined 11:16 andrmuel joined
andrmuel hi 11:17
timotimo greetings 11:18
12:01 zakharyas joined 13:08 hoelzro joined 13:14 cognominal joined 13:23 njmurphy joined 13:39 lizmat joined
mst 18:04 < nine> Got it: irclog.perlgeek.de/moarvm/2016-02-27#i_12108919 17:14
18:04 < nine> It's a naming issue...
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'
jnthn: ^^ wonder how easy that would be, given how much less pain we'd get from precomp with just that
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:15
jnthn What is an API version in this context? 17:16
nine jnthn: talking about avoiding recompilation of reverse dependencies on compatible changes to modules 17:18
jnthn What's a compatible change?
nine one where the module's API is unchanged, i.e. no change on the user's side necessary
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"?
nine yes :)
jnthn s/?/road?/ 17:20
I really, really, don't want to go down that road.
If somebody says that I don't have to care about precomp ever again, then they're free to try. :)
But so far as I can tell, it's fraught enough I just don't want to go there. 17:21
I always intended precomps as cache
mst which is fine, but more intelligent cache expiry would still be nice 17:22
jnthn: I'm not sure what makes it that fraught 17:24
jnthn mst: The lack of any kind of absolute naming.
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.
geekosaur recompilation of reverse deps is itself fraught
nine geekosaur: why?
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
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
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")
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?
mst jnthn: because it's a cache, and not blowing out caches unnecessarily is a good thing
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
17:28 domidumont joined
mst geekosaur: you're assuming things about the situation that aren't true 17:29
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
geekosaur somehow I thought I was talking about that as well, could you explain what I was mistakenly talking about, then? 17:30
mst you said "the fact it's coming up indicates that it is a problem", and are calling recompilation fraught 17:31
I don't understand what you're saying, but it doesn't seem related to what I was talking about
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
mst right, so, that seems like something one could warn() about 17:36
I mean
something like a 'use ICareAboutPrecomp::PleaseWarnMe;' 17:37
nine geekosaur: cabal hell seems unrelated to our discussion
jnthn Possibly, yes
mst and that would point out that custom exporters will also fuck things up
as well
jnthn Custom exporters aren't a problem
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 :)
mst well, some forms of dynamic exporting presumably would be
but, my point is, you're calling it 'edge cases' 17:39
I'm thinking 'things you can be warned about'
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.
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
I am talking about a possible future where precompilation is a little bit more resuable
you said 'users find it hard enough', I'm talking about ways of making it easier for them to not screw it up
thereby making the feature I was imagining potentially more useful
nine I don't think it would change anything in that regard? 17:41
mst what
dude, this conversation is confused enough, specify which 'it', what regard, and what you mean by change, please
because I am way not capable of guessing ;)
nine I don't think more dynamical linking would change anything with regards to custom exporters. 17:42
mst ah, hrm, I guess even a custom exporter is basically exporting a (moral equivalent of) hash of names to things? 17:43
the thing is, if it's always the same names to the same things, you're fine
nine Yes. And those will be serialized into the caller's serialization context and therefore precomp file
mst if it generates a new copy of whatever_name each time, THAT will spoon things up 17:44
right, and at that point, you're going to have to re-precomp to check they didn't change
whereas if it's purely "I am exporting these names to the outside as alias to these names on the inside"
*that* can be dynlinked
nine: does that make a bit more sense? 17:45
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.
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
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:48
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
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 )
mst jnthn: and that's why many sysadmins hate go and consider it a weak point of their infrastructure 17:53
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
it's very much optimised for a world where everything's getting rewritten from scratch all the time
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:55
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
if I'm not changing the API, only trying to repro and then fix a weird behaviour
I don't want to have to re-compile all the layers above that I didn't change for every test cycle
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
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
also, presumably one could test this by repatching the object ids or something 18:00
rather than expecting anything else to change first
nine mst: try working on rakudo's JVM backend. A mere minute compile/test cycle will feel like hyper speed then :)
mst which is, yes, insane, but might make it possible for a sufficiently crazy mere mortal to try and prove the concept 18:01
hm
I think I just talked myself into a corner where I don't get to complain any more without trying it
fuck
nine :)
mst nine: so, basically, "that would be why I don't use clojure"
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
(Other than, I guess, that you're wanting to solve a more general problem...)
(But I'm curious what I'm missing in this use case.) 18:05
mst um. the compilation speed.
I keep ripping Moose out of things in favour of Moo specifically so that 'recompiling every time' isn't ridiculously painful
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?
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"
mst right 18:07
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
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
mst you're a windows user, you're used to installers basically eating your entire machine for half an hour - I'm not ;) 18:08
jnthn ;) 18:10
Dinner time; I'll bbiab
nwc10 mst: sideways to the discussion here which I'm afraid I can't usefully add to 18:20
"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
(and that probably got truncated)
... 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
++
mst right, and also their situation where services usually don't have a lifespan of more than 18mo
nwc10 aha, missed thinking about that :-) 18:24
anyway, this isn't where I find myself, usually.
mst right, same
timotimo i just had lovely dinner 18:45
nine dinner++ 18:50
19:39 Ven joined 19:47 pyrimidine joined 20:57 Ven joined 22:20 ggoebel116 joined 23:52 lizmat joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!