Perl 6 - the future is here, just unevenly distributed

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

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

All times shown according to UTC.

Time Nick Message
01:38 flussence joined #perl6-toolchain
02:48 ilbot3 joined #perl6-toolchain
02:48 Topic for #perl6-toolchain is now Discussion area for the Perl 6 toolchain | https://github.com/perl6/toolchain-bikeshed
03:32 hoelzro joined #perl6-toolchain
05:16 TimToady joined #perl6-toolchain
05:23 b2gills joined #perl6-toolchain
05:36 Zoffix joined #perl6-toolchain
07:21 FROGGS joined #perl6-toolchain
07:54 nine Maybe we should only use the $HOME repo if it actually contains anything.
07:55 nine Without the <home> repo, we _can_ use the precomp files from <site>.
07:56 nine Precomp files for distro packages can be created by a post-install script and will be store in <site>'s precomp store, so the <vendor> path only contains files managed by the package manager.
07:57 nine We don't need the <perl> repository at all. It only contains the CORE distro. We can just as well install that into <site>, or if rakudo is compiled for a distro package into <vendor>.
07:58 nine With these changes, a non-developer user of Perl 6 will gain all benefits of distro-packages and system wide installation of modules.
08:00 nine Developers (e.g. people using -Ilib or installing modules into <home>) will still have to wait for recompilation of installed modules but of course only on first load after installation of a module.
08:38 moritz joined #perl6-toolchain
08:39 moritz IRC logs work now
08:39 moritz http://irclog.perlgeek.de/perl6-toolchain/today
08:45 FROGGS moritz++
08:54 nine excellent!
10:40 masak moritz++
10:45 FROGGS joined #perl6-toolchain
11:26 leont joined #perl6-toolchain
12:04 llfourn it seems that if you do perl6 -Ilib1 -Ilib2 that it will precomp lib2s stuff into to lib1's .precomp
12:04 llfourn is this a bug or is that intended?
12:06 leont That sounds like a but!
12:06 leont bug
12:06 llfourn I think this also only started happening recently
12:06 llfourn like yesterday
12:07 llfourn ill see if I can figure out when then if not RT
12:09 nine llfourn: that's intended
12:09 nine and has been so since curli was merged
12:10 leont What's the rationale?
12:10 llfourn nine: ah k thanks. Maybe this is the first time I've tried two -Is together :)
12:10 leont lib2 may use lib1, so can't be used without it?
12:10 nine We always use the top of the chain's ($*REPO itself) precomp repository. Because when you use lib "lib", lib/ may contain a newer version of a dependency of a module you load. Using the head of the chain's precomp store forces it to re-compile the module and resolve all dependencies again.
12:12 llfourn I think I understand. So the first -I becomes the head.
12:12 nine That's the reason for the $HOME repo preventing uns from using precomp files generated during installation which I described this morning.
12:13 nine The reasoning was also written down by jnthn and can be found in docs/module_management.md
12:14 llfourn I will study this further. Cheers.
12:14 nine Another one of my random thoughts: maybe we want to ship with a very basic installer script that can do the equivalent of "panda install ." (without dependency installation though). This could simplify panda's bootstrap and testing of installation issues.
12:15 llfourn panda install . # ?
12:15 leont That does sound useful
12:15 leont And would probably make sysadmins happy too
12:16 nine Would presumably also be used by module packagers.
12:16 nine unpack source tree, move there, call intall-package.pl6 and package the installed files
12:17 nine "intall-package.pl6" so it's a somewhat unique name ;)
12:17 * leont doesn't see the point of adding .pl6 to the end in this kind of situation
12:18 leont install-perl6-package or some such looks better to my eyes
12:18 nine Yeah, "intall-package" should be unique enough ;)
12:21 nine An issue with this is that all Build.pm files directly use Panda's modules. But maybe this would be a good chance to define a module manager independent interface that panda can use, too.
12:22 leont Yeah, Build.pm must die
12:23 leont I am planning to port my next generation p5 build tool to p6
12:23 leont The really short summary would be "a build graph like make, but without using shell as its foundation"
12:26 leont And with an internal state that can be serialized to JSON and back without data loss
12:26 leont (eat that Makefile!)
12:28 patrickz joined #perl6-toolchain
12:33 nine sooo....how would that be invoked?
12:39 leont That is the tricky bit…
12:40 leont Does p6 have an equivalent of «do $filename»?
12:41 nine EVALFILE
12:41 leont rightfull all-caps :-)
12:42 nine But for some odd reason you don't need to use MONKEY-SEE-NO-EVAL; to use it
13:27 leont Actually, a DSL should be easy enough, and not needing EVALFILE is probably better in the long run
13:29 * leont goes implementing/porting
16:53 mst nine: well, also, ~ may be on a disposable file system or not writeable at all, is where precomp in system packages seems to really matter to me
16:53 mst moritz: ta
17:41 llfourn joined #perl6-toolchain
17:50 TimToady I'll restate my thesis here, in case anyone wants to discuss it
17:50 TimToady the basic problem is that devs want to underspecify identity by using location as a proxy, and then kick up a fuss when we need to establish actual identity in a location-independent fashion
17:51 TimToady and most of our implementation decisions depend crucially on identity
17:52 TimToady that is all :)
17:52 mst yes. that's pretty much always the tension with installers.
17:54 TimToady was just thinking that if local::lib cheats on identity, it's likely to get caught cheating
17:56 mst the CUR format currently always stores identity
17:56 mst local::lib for rakudo would, to my mind, basically be an easy way to get the equivalent of -Ifoo except having it add a ::Installation rather than a simple tree CUR to the front
17:57 mst and then you'd install into there as normal
17:57 mst that seems to me like it'd work fine, with no reason to want to cheat
17:57 mst (I may, of course, be missing something)
17:59 TimToady okay, it's just when people get too old to think, they just worry instead :)
18:01 mst that's fine. you can worry about the architectural correctness, I'll worry about the practical applicativity, and hopefully everybody else will do the thinking and save us having to pretend to :D
18:01 TimToady sounds like a plan :D
18:02 mst plus, y'know, in general I'd rather say "yes, I've already thought of that" a dozen times than miss one
18:02 mst around about time eight might make me actually write some stuff up in any case ;)
18:03 TimToady I call that the Volleyball Principle: better too many people going for the ball than too few.
18:15 nine mst: you _can_ already do -Iinst#foo
18:16 mst nine: aha, whee
18:16 mst I'd forgotten about how that got parsed
19:01 ugexe seems :ver<> doesnt work inside an EVAL (use XXX:ver<123>), and require seems to ignore it
19:56 Kassandry joined #perl6-toolchain
20:23 hankache joined #perl6-toolchain
20:59 llfourn joined #perl6-toolchain
21:02 nine m: use MONKEY-SEE-NO-EVAL; EVAL "use Test:ver(v6.b);"
21:02 camelia rakudo-moar 2d91f0: ( no output )
21:02 nine This does actually fail locally?
21:06 [Coke] fails for me in a recent but not 100% current installed perl6.
21:06 [Coke] (likes like 2015.12 actual)
21:06 [Coke] *looks
21:09 ugexe maybe i misunderstood. i didnt think the v would be neccesary inside :ver
21:10 TimToady parens there, not <>
21:10 TimToady so it's just an expression inside, which needs v
21:10 ugexe ah. yes it fails for me locally
22:00 llfourn joined #perl6-toolchain
22:05 patrickz ugexe: Is your precomp-failure-list still worth to be thrown in?
22:08 ugexe patrickz: no, theyve been fixed or are covered already
22:11 ugexe i think the last point, hooks, was getting talked about earlier today (re Build.pm)
22:15 ugexe which for those who arent aware, most Build.pm files are written in a way where they have to have panda installed, and out of those most people dont declare their build dependencies because they usually test their install with panda so they dont realize its missing
22:16 ugexe https://gist.github.com/ugexe/afcbbf0c76220c150546 is a hack to workaround this (that also works with panda)
22:16 patrickz So just about time to make zef prominent enough so that people start to care.
22:16 ugexe i have to redo the CLI/output, but yea. it does work again
22:17 * patrickz searches through perl6.org for mentions of panda that should read "panda/zef (in alphabetical order)"
23:00 patrickz ugexe: Do you think it's ok for zef to get more attention? If yes I'd do a PR on the website to put zef next to panda in most places.
23:02 nine patrickz: I'd say yes if it works. Otherwise we should fix it up first (and maybe get rid of the panda dependency of so many modules)
23:05 patrickz Ok. I'll hold back then. There are some glitches. On first glance it seems panda is not much better though.
23:08 patrickz Both report the precomp filenames as installed files. Which is worthless information wise. Zef reports a precomp file as its own script name in `zef --help`
23:08 patrickz `zef install 007` does nothing
23:14 patrickz No pressure to fix stuff from my side. I'm only testing and don't depend on any fixes. There has been enough pressure on the devs the last few days.
23:18 TimToady thank you for not losing perspective!

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