Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-toolchain, 2016-09-21

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

All times shown according to UTC.

Time Nick Message
01:48 ilbot3 joined #perl6-toolchain
01:48 Topic for #perl6-toolchain is now Fire is step THREE! | https://github.com/perl6/toolchain-bikeshed | Channel logs: http://irclog.perlgeek.de/perl6-toolchain/today | useful prior art: https://metacpan.org/pod/CPAN::Meta::Spec
05:22 zengargoyle joined #perl6-toolchain
05:23 zengargoyle is this the place for when rakudobrew / zef does something weird?
05:24 domidumont joined #perl6-toolchain
05:29 domidumont joined #perl6-toolchain
05:50 domidumont joined #perl6-toolchain
07:11 nine zengargoyle: here or #perl6
07:48 zengargoyle https://gist.github.com/zengargoyle/d967d59f54e7978357027aa09f2a9d16
07:49 zengargoyle use rakudo to build moar-blead, success, then tries to re-something zef which builds and tests and then fails to install since it's already installed before.  then rakudobrew barfs.
07:51 nine zengargoyle: why are you using rakudobrew?
07:51 zengargoyle could probably be fixed with a nuke and start from scratch...  but it seems the old redo panda and reinstall modules automagic isn't quite working zef-wise.
07:51 zengargoyle nine: is rakudobrew deprecated or something?
07:52 nine zengargoyle: rakudobrew is a tool for core developers who may have a reason to install and use multiple versions of rakudo with separate module repositories. It is not a tool aimed at end users.
07:52 nine It is also not a tool that's really maintained.
07:52 nine There is no reason at all to reinstall any modules when upgrading rakudo.
07:53 zengargoyle so is nuke and start from scratch the goto method...  i am indending to work on core-ish stuff.  i did before but have been away for many months.
07:54 nine I work quite a bite on the core, too but have never really felt a need for rakudobrew
07:54 zengargoyle just expected it to sorta mostly work (actually epected it to re-install everything like it did once before)
07:55 zengargoyle i never got to the point of doing nqp/moar/rakudo all by my lonesome. :)
07:55 nine As I said, you don't have to re-install anything just because you upgraded
07:55 nine zengargoyle: just try it. It's a one liner :)
07:56 nine git clone gitgithub.com:rakudo/rakudo.git && cd rakudo && perl Configure.pl --gen-moar --make-install
07:57 zengargoyle nods.  just sorta like the *brew type of things to keep multiple versions to easily switch between to keep some scripts working and some breakable.
08:01 zengargoyle a rakudobrew that does provide the easy switch between blead and latest-stable and older versions would be a nice thing eventually.
08:02 zengargoyle it also might just be the zef part.  i haven't tried panda this time around, don't know if it has the same weirdness.
08:03 nine Well we would rather just be really backwards compatible, so users don't have to switch between rakudo versions
08:04 zengargoyle :)
08:07 zengargoyle i also find that zef will fail to install Task::Star, it will install all the dependent modules but fail the actual Test::Star part.  but will say nothing to do if you try to install Task::Star again.  probaby more a zef issue with bundle type modules.
08:32 zengargoyle hrm, if modules are now backwards compatable enough, maybe rakudobrew should just not try to do the panda/zef re-install, re-install all current modules thing.  or maybe have smarts to know if it should re-install panda/zef/modules for some reason or another.
09:00 lizmat joined #perl6-toolchain
09:06 nine Well, rakudobrew is hardly maintained. But if you want to step up, please just do :)
09:54 domidumont joined #perl6-toolchain
10:00 domidumont1 joined #perl6-toolchain
10:14 domidumont joined #perl6-toolchain
10:33 TimToady joined #perl6-toolchain
10:42 tadzik joined #perl6-toolchain
11:41 domidumont joined #perl6-toolchain
14:34 ugexe zengargoyle: why does the test fail (run with `-v` to get test output)? Task::Star installs on my end so I cant reproduce
14:39 ugexe `ZEF_PLUGIN_DEBUG=1 perl6 -Ilib bin/zef --debug install Task::Star > zef_output.txt 2>&1` If you give me the output from this i'll be able to figure it out. I think the test adapter it chooses for your system doesn't like a missing `t/` directory
15:26 stmuk ugexe: BTW zef fails to install for me on OpenBSD at the moment
15:27 stmuk panda even core dumps on that platform which I'm trying to golf
15:28 ugexe does zef give any hint at the error?
15:30 mst Error: no zef for you
15:33 stmuk nope its core dumping too ... there are reports of panda breakage on FreeBSD as well so maybe its *BSD specific
15:37 ugexe do they reach the actual installation stage, or do they dump before testing?
15:39 stmuk I've only looked at panda in detail and its the use of --prefix=inst#foo in a module bootstrap (using the uninstalled panda) which is to blame
15:40 stmuk I also have a gdb backtrace on moar.core
15:42 stmuk its the actual installation phase, building and testing are fine
15:43 ugexe ah. so its in CompUnit::Repository::Installation (or the PrecompilationRepository)
15:43 ugexe probably a lock or permissions issue
15:44 stmuk yes maybe this line (from panda)
15:46 stmuk https://github.com/tadzik/panda/blob/master/lib/Panda/Installer.pm#L39
15:52 ugexe hmmm i would suspect #L61
16:00 ugexe stmuk: maybe `RAKUDO_MODULE_DEBUG=1` will give additional clues
16:06 stmuk it doesn't show anything at the install point before the coredump .. I think it's L39 from putting dies in
16:09 ugexe weird. does `perl6 -e 'say CompUnit::RepositoryRegistry.repository-for-spec("inst#foo", :next-repo($*REPO))'` crash?
16:10 stmuk not when I tried it yesterday
16:13 * stmuk tries again for luck
16:13 stmuk nope
16:13 ugexe heh, i was hoping it would because that would make more sense (to me anyway)
16:14 ugexe when you said `--prefix=inst#foo` do you mean you passed this to panda or that you build rakudo with it?
16:14 stmuk FreeBSD behaves in the same way .. my guess is there some assumption about file system behaviour which doesn't hold with ufs/ffs
16:14 stmuk passed to panda
16:24 domidumont joined #perl6-toolchain
16:47 ugexe i'll try to reproduce locally tonight
16:50 ugexe zengargoyle: the issue with task::star tests reporting a failure should be fixed. one of the non-default/backup test adapters indeed did not play nice with a missing `t/`
16:55 ugexe i'm assuming you're on osx
18:17 edehont joined #perl6-toolchain
20:45 zengargoyle ugexe: looks like it might have been my using `zef --serial install Task::Star` (which fails at the end) under the assumption that zef installs all or none and '--serial' would at least install modules that didn't fail tests.
20:50 zengargoyle without '--serial' it doesn't fail at the end.  and i'm on Debian so it probably wouldn't have failed in the first place w/o the '--serial' flag.
21:00 hoelzro joined #perl6-toolchain
21:05 zengargoyle with '--serial' it ends with '===> Install [OK] for Task::Star' then an error message: '!!!> Install failures: Task::Star, <looks like all modules>'.
21:06 zengargoyle i probably just mis-grokked the purpose of '--serial' :/
21:45 camelia joined #perl6-toolchain
21:48 ugexe zengargoyle: you understand correctly. your clarification pointed me in the right direction and its fixed now (everything was being installed correctly, it was just reporting wrong at the end)
21:49 ugexe --serial ended up needing to flatten its array of candidates before passing it to the reporter
22:08 zengargoyle yay :)

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