|
Discussion area for the Perl 6 toolchain | github.com/perl6/toolchain-bikeshed Set by moderator on 7 January 2016. |
|||
|
01:38
flussence joined
02:48
ilbot3 joined
|
|||
| moderator | Discussion area for the Perl 6 toolchain | github.com/perl6/toolchain-bikeshed | ||
|
03:32
hoelzro joined
05:16
TimToady joined
05:23
b2gills joined
05:36
Zoffix joined
07:21
FROGGS joined
|
|||
| nine | Maybe we should only use the $HOME repo if it actually contains anything. | 07:54 | |
| Without the <home> repo, we _can_ use the precomp files from <site>. | 07:55 | ||
| 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:56 | ||
| 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:57 | ||
| With these changes, a non-developer user of Perl 6 will gain all benefits of distro-packages and system wide installation of modules. | 07:58 | ||
| 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:00 | ||
|
08:38
moritz joined
|
|||
| moritz | IRC logs work now | 08:39 | |
| irclog.perlgeek.de/perl6-toolchain/today | |||
| FROGGS | moritz++ | 08:45 | |
| nine | excellent! | 08:54 | |
| masak | moritz++ | 10:40 | |
|
10:45
FROGGS joined
11:26
leont joined
|
|||
| llfourn | it seems that if you do perl6 -Ilib1 -Ilib2 that it will precomp lib2s stuff into to lib1's .precomp | 12:04 | |
| is this a bug or is that intended? | |||
| leont | That sounds like a but! | 12:06 | |
| bug | |||
| llfourn | I think this also only started happening recently | ||
| like yesterday | |||
| ill see if I can figure out when then if not RT | 12:07 | ||
| nine | llfourn: that's intended | 12:09 | |
| and has been so since curli was merged | |||
| leont | What's the rationale? | 12:10 | |
| llfourn | nine: ah k thanks. Maybe this is the first time I've tried two -Is together :) | ||
| leont | lib2 may use lib1, so can't be used without it? | ||
| 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. | ||
| 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. | ||
| The reasoning was also written down by jnthn and can be found in docs/module_management.md | 12:13 | ||
| 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. | ||
| llfourn | panda install . # ? | 12:15 | |
| leont | That does sound useful | ||
| And would probably make sysadmins happy too | |||
| nine | Would presumably also be used by module packagers. | 12:16 | |
| unpack source tree, move there, call intall-package.pl6 and package the installed files | |||
| "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 | |||
| install-perl6-package or some such looks better to my eyes | 12:18 | ||
| nine | Yeah, "intall-package" should be unique enough ;) | ||
| 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:21 | ||
| leont | Yeah, Build.pm must die | 12:22 | |
| I am planning to port my next generation p5 build tool to p6 | 12:23 | ||
| The really short summary would be "a build graph like make, but without using shell as its foundation" | |||
| And with an internal state that can be serialized to JSON and back without data loss | 12:26 | ||
| (eat that Makefile!) | |||
|
12:28
patrickz joined
|
|||
| nine | sooo....how would that be invoked? | 12:33 | |
| leont | That is the tricky bit… | 12:39 | |
| Does p6 have an equivalent of «do $filename»? | 12:40 | ||
| nine | EVALFILE | 12:41 | |
| leont | rightfull all-caps :-) | ||
| nine | But for some odd reason you don't need to use MONKEY-SEE-NO-EVAL; to use it | 12:42 | |
| leont | Actually, a DSL should be easy enough, and not needing EVALFILE is probably better in the long run | 13:27 | |
| leont goes implementing/porting | 13:29 | ||
| 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 | |
| moritz: ta | |||
|
17:41
llfourn joined
|
|||
| TimToady | I'll restate my thesis here, in case anyone wants to discuss it | 17:50 | |
| 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 | |||
| and most of our implementation decisions depend crucially on identity | 17:51 | ||
| that is all :) | 17:52 | ||
| mst | yes. that's pretty much always the tension with installers. | ||
| TimToady | was just thinking that if local::lib cheats on identity, it's likely to get caught cheating | 17:54 | |
| mst | the CUR format currently always stores identity | 17:56 | |
| 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 | |||
| and then you'd install into there as normal | 17:57 | ||
| that seems to me like it'd work fine, with no reason to want to cheat | |||
| (I may, of course, be missing something) | |||
| TimToady | okay, it's just when people get too old to think, they just worry instead :) | 17:59 | |
| 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 | ||
| 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 | |
| around about time eight might make me actually write some stuff up in any case ;) | |||
| TimToady | I call that the Volleyball Principle: better too many people going for the ball than too few. | 18:03 | |
| nine | mst: you _can_ already do -Iinst#foo | 18:15 | |
| mst | nine: aha, whee | 18:16 | |
| I'd forgotten about how that got parsed | |||
| ugexe | seems :ver<> doesnt work inside an EVAL (use XXX:ver<123>), and require seems to ignore it | 19:01 | |
|
19:56
Kassandry joined
20:23
hankache joined
20:59
llfourn joined
|
|||
| nine | m: use MONKEY-SEE-NO-EVAL; EVAL "use Test:ver(v6.b);" | 21:02 | |
| camelia | ( no output ) | ||
| nine | This does actually fail locally? | ||
| [Coke] | fails for me in a recent but not 100% current installed perl6. | 21:06 | |
| (likes like 2015.12 actual) | |||
| *looks | |||
| ugexe | maybe i misunderstood. i didnt think the v would be neccesary inside :ver | 21:09 | |
| TimToady | parens there, not <> | 21:10 | |
| so it's just an expression inside, which needs v | |||
| ugexe | ah. yes it fails for me locally | ||
|
22:00
llfourn joined
|
|||
| patrickz | ugexe: Is your precomp-failure-list still worth to be thrown in? | 22:05 | |
| ugexe | patrickz: no, theyve been fixed or are covered already | 22:08 | |
| i think the last point, hooks, was getting talked about earlier today (re Build.pm) | 22:11 | ||
| 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:15 | ||
| 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. | ||
| ugexe | i have to redo the CLI/output, but yea. it does work again | ||
| patrickz searches through perl6.org for mentions of panda that should read "panda/zef (in alphabetical order)" | 22:17 | ||
| 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:00 | ||
| 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:02 | |
| patrickz | Ok. I'll hold back then. There are some glitches. On first glance it seems panda is not much better though. | 23:05 | |
| 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 | ||
| `zef install 007` does nothing | |||
| 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:14 | ||
| TimToady | thank you for not losing perspective! | 23:18 | |