|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
| samcv | jnthn: if you're around i have a question. trying to fix this bug rt.perl.org/Public/Bug/Display.html?id=127933 | 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 github.com/perl6/nqp/blob/master/s...ns.nqp#L58 | 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 github.com/perl6/nqp/blob/master/s...ns.nqp#L58 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 github.com/perl6/nqp/blob/master/s...ns.nqp#L63 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: libmoar.so: 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 | |||
| linux.die.net/man/8/execstack | 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: ^ | |||
| github.com/nxadm/rakudo-pkg/blob/m..._windows10 | 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 | ||
| iirc | |||
| huggable: bash on windows | |||
| huggable | geekosaur, sudo execstack -c /usr/lib/libmoar.so | ||
| 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/libmoar.so | ||
| huggable | geekosaur, Added executable stack as sudo execstack -c /usr/lib/libmoar.so | ||
| 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 Configure.pl 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 github.com/MoarVM/dyncall/pull/5 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: github.com/MoarVM/dyncall/pull/5 | 21:10 | ||
| bbiab | |||
| 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 | |
| perl6.party/post/A-Call-To-Action-...Experience | |||
| 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
|
|||