| IRC logs at
Set by AlexDaniel on 12 June 2018.
samcv jnthn: if you're around i have a question. trying to fix this bug 04:35
so in Actions.nqp in nqp repo we use MVM_frame_lexical_primspec on something and it doesn't work when it's int8, int16, int32 etc 04:36
so i was thinking the way to resolve was to add cases for these other variables and then add atkey_i32 atkey_i16 etc
here is where it throws in rakudo with intX's 04:38
so i was going to add new things for nqp::lexprimspec to return and then add additional cases to the if else chain below. and add atkey_foo for the additional types 04:39
nine samcv: looks to me like it's just missing case MVM_reg_int8: and friends 06:09
in MVM_frame_lexical_primspec
06:15 domidumont joined 06:20 domidumont left 06:21 domidumont joined
samcv nine: yes but we also need to handle it in right? otherwise it won't do anything with the value 06:26
also i can't do nqp::atkey on the wrong type, that is not allowed
nine Ah, yes. Tricky 06:27
How come this only affects the REPL?
samcv good question 06:28
06:54 robertle joined
samcv nine: i think it must be how it's accessing the values since it's the lexpad that it reads from hmm 07:03
you probably know more about how that work than i do
07:12 AlexDaniel left 07:13 brrt joined 08:05 zakharyas joined
brrt good * 08:06
samcv good * brrt 08:07
08:12 zakharyas left 08:14 zakharyas joined
samcv brrt: any thoughts on what i said ^^ about adding that 08:21
brrt did not yet logback 08:26
oh, hmm 08:27
i'm not 100% convinced we need this 08:28
it's also perfectly alright to have a bunch of truncate-and-extend opcodes
that's how the JVM does it 08:29
and it is comparatively straightforward to elide that in an analysis
samcv brrt: well how to get the key then? 08:31
otherwise atkey will return the wrong type 08:32
08:32 zakharyas left, zakharyas joined
brrt hmm. disregard my comment, that ship has sailed 08:35
08:39 zakharyas left
samcv brrt: so do you think that's an ok idea? 08:40
brrt i honestly am not sure
i don't know enough of that part of the code at all 08:41
samcv ok. i'll wait for jnthn then
08:51 zakharyas joined
jnthn No, we won't have an explosion of atkey sized int types 09:26
They are always exchanged at full width there
I think probably the primspec should return the same for int8 etc. as it does for int 09:27
And then at_key inside of MVMContext should switch on the lexical type and widen things for return 09:28
09:42 brrt left 09:56 domidumont left 10:21 brrt joined 10:23 AlexDaniel joined 10:37 brrt left 10:41 AlexDaniel left, AlexDaniel joined 10:47 robertle left
samcv jnthn: ok 11:13
going to bed now, will do that in the morn. 11:14
11:14 zakharyas left
samcv jnthn: so it's fine for here to get back an int and not a special type? we don't need to retain the type here? 11:17
(in nqp that is) i get what you want done in moarvm
11:44 domidumont joined 12:11 domidumont1 joined 12:14 domidumont left
jnthn samcv: I think probably we can get away with it 12:16
12:29 zakharyas joined 12:54 domidumont joined 12:57 domidumont1 left 13:22 AlexDaniel left 13:29 robertle joined 14:36 MasterDuke left 15:27 robertle left 15:52 robertle joined 16:00 AlexDaniel joined 16:40 domidumont left 17:08 sivoais left
samcv jnthn: that causes issues in everywhere that expects the type to match 17:09
jnthn samcv: Ah. Then maybe we will have to branch over the lot and set :type(...) appropriately 17:10
17:10 sivoais_ joined 17:12 sivoais_ left 17:16 sivoais joined 17:54 zakharyas left
lizmat does this ring a bell with anyone? 17:59
error while loading shared libraries: cannot enable executable stack as shared object requires: Invalid argument
jnthn samcv ^^^
this appears to happen with the Windows Subsystem for Linux in Windows 10 build 16299 18:00
samcv hmm i don't recognize that
geekosaur known in that subsystem, yes 18:08
(hits haskell as well, often caused by libffi and possibly also libdyn)
because they can use trampolines under some circumstances 18:09
however I think the subsystem itself may not permit executable stack, in which case you'd at most change the error message you get 18:10
lizmat geekosaur: so you're saying there is no easy solution ? 18:11
geekosaur I think the solution is to change the flag to say "doesn;t need exec stack" and hope nothing requires a trampoline
(which is true for ghc's use of libffi, and I suspect also true for NativeCall)
libffi and libdyn both have more capabilities than we use
the program will die with a signal if it does try to use a trampoline or etc. 18:12
timotimo If you're using the Windows Subsystem for Linux (aka Bash or Ubuntu on Windows 10), use the repository or package for the installed Linux distribution. You'll need to strip the moarvm library of (unused) kernel functionalities that Windows does not implement yet: 18:14
$ /opt/rakudo-pkg/bin/fix_windows10
from the nxadm/rakudo-pkg readme
lizmat: ^ 18:15
geekosaur which appears to do exactly what I suggested: turn off the "needs executable stack" flag
timotimo yup
huggable: WSL
huggable timotimo, nothing found
timotimo huggable: windows
huggable timotimo, nothing found
timotimo huggable: execstack 18:16
huggable timotimo, nothing found
timotimo hm.
geekosaur it's uin there but some weird name
huggable: bash on windows
huggable geekosaur, sudo execstack -c /usr/lib/
geekosaur also "win10 bash" and a few other variants 18:17
lizmat geekosaur++ timotimo++
timotimo mhm 18:18
geekosaur huggable: executable stack :is: sudo execstack -c /usr/lib/
huggable geekosaur, Added executable stack as sudo execstack -c /usr/lib/
geekosaur since that' what the error message says
and it'll come up on "hardened" linux as well 18:19
(debian's been moving in that direction, for example)
and I recall reading arch's plan for migrating to no executable stack by default as well 18:20
timotimo i kind of sort of thought newer versions of libffi and dyncall can work completely without execstack, but that could be wrong 18:21
geekosaur maybe unreleased nes
some things are rather hard to do without it
but there still remains that nothing can know that we're not using features that require trampolines or equivalents 18:22
timotimo can't we automatically detect the "no executable stack" thing during moar's and ask the user to install "execstack" and re-run, then use execstack in the Makefile? 18:24
geekosaur not easily, I think 18:25
timotimo damn.
if we just build a "hello world" c file and cause the compiler to require an executable stack for running it, won't that do the trick? 18:26
geekosaur I mean, you could try to build and run a program that uses executable stack in some way, but (a) the easiest way to do that requires execstack (b) no "execstack" for non-linux (different OSes may have different ways to do it)
you hve to figure out how to make the compiler require it. you might be able to do it with linking libffi / libdyn, but not during Configure if libdyn is one of the things to be built 18:27
timotimo i wonder if it would make sense to have a step in the installation that does the check and gives a good & helpful error message early 18:32
nine japhb: just released a fixed Inline::Perl5 19:06
Turns out my $foo := bar if $baz; is a bit of a dangerous construct as $foo may end up as a Mu instead of an Any. That's what caused inconsistent bind results later on. 19:07
jnthn About the dyncall and execstack: I believe merging would help. Arguments to merge now: the fix would be in the upcoming release. Argument against merging now: the latest dyncall will be in the upcoming release and we maybe don't feel that's enough integration testing time. :) 20:16
Opinions/risk assessments welcome. :) 20:19
20:58 MasterDuke joined
lizmat jnthn: deven (Deven Corzine) is one of the attendants to my Perl 6 workshop this Sunday 21:02
he seems capable :-) 21:04
this release will not be a Star release, so I would lean on merging before release so that *if* there is unexpected ecosystem fallout
it would only be a compiler release point update (if really necessary) 21:05
my 2c wort :-)
jnthn Oh, I thought this one *was* a star release, thus my being hesitant :)
lizmat nope, the 2018.07 is one 21:08
jnthn If it ain't then let's merge it I guess
Merged: 21:10
lizmat jnthn: Deven mails me: 21:21
Apparently the pull request above does NOT incorporate dyncall 1.0, the issue reporter was just requesting that in the comments.
Any chance you could convince the MoarVM developers to prioritize switching to dyncall 1.0 to fix this issue? :)
22:24 robertle left
jnthn No, it's necesary, but not sufficient; will need to bump the submodule version too 22:51
23:08 brrt joined
japhb Our release date is a convention, which we have been rather loose with if something goes awry in the past. That said, the reason for pushing this release a bit is IIUC that Learning Perl 6 is coming out soon and we want a version that will run on as many environments as possible with the least manual hackery possible. 23:20
So if this helps us run on WSL with no muss no fuss, then it may be inline with Zoffix's proposal as I understand it.
AlexDaniel which proposal? 23:21
brrt the proposal to make Perl6 smoother now that we have a new book coming up 23:22
AlexDaniel and what does that mean? 23:23
brrt it'd be easier at this point for me to find the blog post 23:24
i don't merge in untested stuff just yet, I guess :-) 23:25
AlexDaniel ah, there it is. Thanks for the link 23:27
AlexDaniel somehow missed that 23:28
brrt i've noticed i miss a bunch of Zoffix++'s posts 23:40
that's because they're only partially syndicated to pl6anet 23:41
23:45 Zoffix joined, brrt left
Zoffix japhb: it's not this release though, it's the *next* one 23:45
japhb Zoffix: Oh, never mind me then. 23:46
Fair enough.
I usually miss posts that are only announced on #perl6, because that's the one that I only look for regex highlights, rather than even skimming normally.
MasterDuke speaking of posts on pl6anet. has andrew shitov stopped blogging? 23:51
23:57 Zoffix left