Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-toolchain, 2016-01-24

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
07:07 hankache joined #perl6-toolchain
07:28 domidumont joined #perl6-toolchain
07:33 domidumont joined #perl6-toolchain
09:08 kmel joined #perl6-toolchain
09:11 kmel joined #perl6-toolchain
09:16 hankache joined #perl6-toolchain
10:13 leont joined #perl6-toolchain
10:17 hankache joined #perl6-toolchain
12:25 nine ugexe: I'm now reading through https://gist.github.com/ugexe/1026b2730abe6d2a126c after beeing afk for a week. It's certainly a fascinating read. I have a bit of a hard time powering up again, so don't be surprised if feedback is slow in coming.
12:36 masak nine++ ugexe++
12:46 nine ugexe: I do wonder why S22 speculates about a general "content" method using dispatch based on the arguments instead of specialized methods dispatched on method name like .bin, .resource and so on. The general version would only make sense for providing an open interface where new keys could easily be added to the META data.
12:53 nine ugexe: I think what I don't like about "content" is that it really makes Distribution just an interface for a nested hash data structure while the fact that it's usually derived from some JSON file should be hidden. While "content" makes it trivial to extend the META file format and access those new keys from tools it makes it actually harder to add specialized behavior for keys (like resources/libraries)
12:55 nine ugexe: if we find the need to provide new special treatment in the future (as we likely will), we can do this with roles providing those accessor methods and tools can check the presence of these roles. How would a tool check if the .content method provides the special handling?
12:56 nine ugexe: resourcs/libraries is actually a good first example, as you've correctly pointed out that the special handling should be done by the repo's install method instead of by every installation manager.
13:05 nine ugexe: I love the idea of using Distribution as the single interface between installer and the .install method. We could even go a step further and instead of paths mandate IO::Handle to read data from. That way the github distribution wouldn't need to create those temp files. Same would be true for a tool accessing installed distributions. A repo is free to store a dist in an SQL database, as long as it can provide an IO::Handle interface to the stored
13:07 FROGGS joined #perl6-toolchain
13:08 jdv79 nine: why are the 2 mutually exclusive?
13:09 nine jdv79: you mean .content + .resources/.whatever?
13:11 jdv79 yeah.  actually i'm not sure it matters that much now that i think about it.
13:23 hankache joined #perl6-toolchain
13:24 jdv79 though, instead of an attr containing a hash i think meta would be better as a real obj/class.
13:52 FROGGS_ joined #perl6-toolchain
15:11 nine From the backlog: I really want to avoid us doing a readdir for every precomp file we load. It also seems to be clear that we cannot overwrite or delete files as they may be in use elsewhere. Luckily we already have lookup tables: the dist files record the mapping between module and precomp id.
15:12 nine So if there's already a precomp file with the same name, we can use a different id for the new file.
15:14 nine Incidentally, I think I just stumbled over the (hopefully) last missing invalidation problem: CompUnit::Repository::Installation::id uses the id of all installed dists so a repo ahead in the change can use the changing id as a signal to invalidate all precomp files. But the dist ids don't change on a --force install, so reverse dependencies in repos ahead in the chain won't be recompiled.
15:15 nine This stuff is really _hard_ to get right. Who'd have thought?
15:17 nine At the same time, we really should aim for a Linux distribution's package manager to be able to install module packages by just dropping files. Which for me is a killer argument against any centralized mapping files or counters or other shared state.
16:50 ugexe nine: using an IO::Handle was my idea too, but i was hoping for an interface that also worked on IO::Socket
16:54 nine Oh I kind of assumed that IO::Handle would cover sockets, too.
16:56 ugexe to do that you use `IO` so it would have to be .read
17:00 nine Oh and as we're pondering having different Distribution implementations, we'll need to think about $*REPO.uninstall($dist) and where the $dist will come from and which kind of Distribution it will be.
17:01 ugexe after its installed i dont think the type of dist is relevant anymore
17:03 nine I don't think it will be either. At least as long as it's used as an id mostly by uninstall.
17:03 ugexe once CU.install touches the dist it could be considered a CompUnit(s). so you would be uninstalling a CompUnit, and since all modules have to be CompUnits they can all be installed with a CompUnit specific method
17:06 nine Uninstalling a single module out of a dist?
17:06 ugexe post-uninstall scripts in hooks/ may help with needing an actual Distribution object too
17:06 ugexe i mean uninstalling a module (or distribution of them)
17:08 nine I'm not sure if we're on the same terminology here? A distribution contains 0 or more modules which when loaded become CompUnits. Installation and uninstallation work in terms of distributions.
17:09 ugexe the reason for .content accepting arbitrary keys is because resources was specced to accept arbitrary nodes/leafs
17:09 ugexe so a package manager could for instance use a node to store reverse dependencies so it knows how to orphan packages for instance
17:10 nine Oh, and this is also where we could store the bit about if a dist was installed as dependency or directly!
17:10 nine Which is exactly what you just said...
17:11 ugexe heh
17:11 nine Maybe we do want both: the general access mechanism and the specialized methods in easily detectable roles
17:15 ugexe either way. any specialized methods should be able to do the same things through general access methods (just abstracting the call to .meta to gets keys, the logic to figure out which key to pick, and calling .content to get it)
17:17 ugexe when ive done this with roles I would also add a `.files` method to the required interface. so ::FileSystem would do $iopath.dir, ::Git would do run(`git`, `ls-files`, cwd($path-dir)), ::Tar would do `tar --list -f $path-dir`
17:18 ugexe that helps get rid of special handling of bin files (which are not listed in a Distribution anywhere)
17:19 ugexe (presumably because installing bin/ scripts could be an optional thing)
17:22 ugexe also re: resource node/leafs; they can be used for hooks as well. "resources" : { "libraries" : { "libblah" : build-time } },
17:23 ugexe but instead of build-time it might be something telling to automatically do the VM platform-name thing (or tell it *not* to)
17:26 ugexe or maybe "resource" : { "some-folder" : { "libblah" : library } } # so libraries can go in any folder under resources
17:47 ugexe in the former example it probably makes things like Distribution -> .deb/.rpm/makefile a lot easier
17:54 ugexe on the bright side its under key "resource" in s22, but currently everyone uses "resources"
18:34 lizmat joined #perl6-toolchain
19:10 hankache joined #perl6-toolchain
19:21 domidumont joined #perl6-toolchain
20:04 domidumont joined #perl6-toolchain
20:40 jdv79 wait.  what?  resources is just an additional filestore, right?  since when is it used as an ad hoc datastore?
20:41 jdv79 use another key for that i'm guessing
22:26 ugexe s22 has always had it as such
22:27 ugexe otherwise, as it currently is, its not really any different from bin/ (which is not declared in the meta)
22:27 ugexe well, other than access to %?RESOURCE
22:37 ugexe i also think it would be neat if you could just store arbitrary config data in there too

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary