00:01
bisectable6_ joined
|
|||
samcv | timotimo, that would be nice :) | 00:05 | |
01:29
colomon joined
01:40
colomon joined
01:41
colomon joined
01:52
ilbot3 joined
03:05
pharv_ joined
03:44
stmuk joined
03:46
Util joined
06:15
lizmat joined
06:22
lizmat_ joined
06:38
lizmat joined
08:25
zakharyas joined
|
|||
jnthn | moarning o/ | 09:10 | |
09:12
lizmat joined
|
|||
dogbert17_ | morning, why do I get the impression the everyone is in Amsterdam | 09:17 | |
09:17
zakharyas joined
|
|||
jnthn | I dunno, maybe most of 'em are | 09:18 | |
dogbert17_ | so what's on the agenda today, closures and/or tuning? | 09:19 | |
jnthn | Think I'll make an attempt at the closures thing | 09:21 | |
Though running a little short on time | |||
dogbert17_ | is it a straightforward fix or one requiring a lot of thought and coffee? | 09:23 | |
jnthn | It's not really a fix | ||
It's more trying to remove a limitation of inlining | |||
It's tricky | |||
dogbert17_ | and so can take an unspecified amount of time 1 .. * | 09:24 | |
jnthn | Well, I've got a rough plan that I think might work | ||
First step is to try and teach deopt to find the correct code ref via a register | |||
So uninlining would be able to reconstruct things correctly | 09:25 | ||
Which today doesn't matter | |||
The basic idea is that we add a spesh op that can resolve a lexical relative to the outer of a code-ref held in a register | 09:26 | ||
otoh since an MVMFrame is a collectable, we could extract the outer frame, but maybe still need the coderef for deopt anyway | 09:27 | ||
dogbert17_ was temporarily called away, a disadvantage of $work | 09:51 | ||
any wild theories as to performance increases with this new opt? | 09:52 | ||
09:54
brrt joined
|
|||
Geth | MoarVM: 9f12f0c1a6 | (Jonathan Worthington)++ | 7 files Start storing/using static frame in inline table. In the vast majority of cases, the code ref was only used as a way to get at the static frame, so now just store and access it directly. This prepares the way for starting to store the code ref instead by a reference to the register holding it. |
09:55 | |
brrt | good hi * | ||
jnthn | dogbert17_: Well, inlining can be a notable win | ||
timotimo | yo brrt | 09:56 | |
jnthn | o/ brrt | ||
timotimo | when's the jit talk? | ||
brrt | tomorrow | ||
jnthn | How's Amsterdam? | ||
timotimo | OK! | ||
brrt | i'm not there yet | ||
:-) | |||
jnthn | Oh! | ||
brrt | long story | ||
but i'll be there in 2h :-) | |||
yesterday, it was kind of rainy | |||
.tell nwc10 you should be able to build nqp by now | 09:58 | ||
yoleaux | brrt: I'll pass your message to nwc10. | ||
10:12
lizmat_ joined
10:16
lizmat joined
10:20
brrt joined
|
|||
timotimo | so i was wondering how to implement getting the remote peer from IO::Socket::Async's listen functionality | 10:21 | |
jnthn | timotimo: Just pass it as an extra argument or two to the callback that fires per incoming connection | 10:22 | |
timotimo | that sounds good, that'll get us the feature without a new op | 10:23 | |
jnthn | Right :) | ||
Geth | MoarVM: 30ff9d5147 | (Jonathan Worthington)++ | 5 files Use register holding code ref for deopt purposes. This means that we will deoptimize to the correct closure clone. This also prepares the way for an attempt at inlining of closures. |
10:28 | |
jnthn | Well, seems my preparatory work went without hitches. | ||
nwc10 | it's a trap! :-) | 10:29 | |
yoleaux | 09:58Z <brrt> nwc10: you should be able to build nqp by now | ||
nwc10 | (I'd found that already last night) | ||
10:31
lizmat joined
|
|||
brrt is now taking the express train to amsterdam | 10:34 | ||
timotimo | can't pay attention to talk and code att he satem tim | 10:46 | |
hmmm ... nqp-debug-m ... | 10:49 | ||
10:49
brrt joined
10:55
brrt joined
11:09
markmont joined
|
|||
jnthn | Well, got a patch that works for the NQP build/test under spesh stressing. Explodes during CORE.setting compilation alas | 11:27 | |
Lunch, will investigate after | |||
11:38
markmont joined
11:48
lizmat joined
|
|||
jnthn back | 12:06 | ||
Of course, the CORE.setting build is the worst place to hunt a problem down, so I'll see if it'll built without nodelay/blocking and then see if any tests fail with it | 12:07 | ||
nwc10 | or watch Damian live... | 12:08 | |
jnthn | I get to do that in a couple of weeks :) | ||
nwc10 | he seems to have just blown some folks' minds. | 12:09 | |
12:12
colomon joined
|
|||
jnthn | :) | 12:15 | |
jnthn found a simpler test to investigate | |||
Ah, a rewrite thinko | 12:30 | ||
yay, and with that fixed it built Rakudo with spesh stressing, and passes make test too | 12:35 | ||
Next for spectest with spesh stressing | 12:36 | ||
12:41
lizmat joined
|
|||
jnthn | Just a few busted | 12:47 | |
otoh yesterday there was one busted and it took all afternoon to work out why... | 12:48 | ||
12:48
colomon joined
|
|||
dogbert17_ | jnthn: these ones? S03-junctions/autothreading.t, S05-modifier/ignoremark.t, S05-modifier/samemark.t, S32-io/IO-Socket-INET.t and integration/eval-and-threads.t | 12:50 | |
jnthn | No | ||
dogbert17_ | :( | ||
jnthn | But it turnsout | ||
They are I think the same tests I regressed when I hadn't JITted new ops a couple of days ago | 12:51 | ||
And it turned out it was an issue going way back | |||
So I think I've just stumbled on that again | |||
Time to write some assembly I guess... | |||
dogbert17_ | making brrt unemployed :) | 12:52 | |
jnthn | I'm not *that* good at assembly :P | 12:57 | |
Also the hard part of what brrt++ is doing is figuring out how to generate good assembly, whereas I at the moment just need to write a block of it for the lego JIT | 12:58 | ||
nwc10 | at this time any other JITs that might exist are merely the figments of someone else's imagination/on a branch/wrapped in an SEP field | ||
and IIRC he's on a train so won't notice for a while :-) | 12:59 | ||
jnthn | Ooooh. | 13:02 | |
OK, looks like I've some more fix to fix | 13:04 | ||
*stuff to fix | 13:05 | ||
But with the new ops JITted and a tweak to the inline threshold, we get another bit of movement on the read a million lines benchmark. | |||
dogbert17_ | figuring out what is good assembly must be much harder today than in, let's say, the 6502 days | 13:09 | |
jnthn | Well, my assembly at least passes spesh stressing on NQP build/test and Rakudo build/test | 13:12 | |
dogbert17_ | coool | ||
jnthn | Now for another spectest run to find out what I need to fix. | ||
13:12
lizmat joined
|
|||
geekosaur | arguably it was harder back then, because you had to think more. | 13:20 | |
*especially* on 6502 where, if you wanted really good asm, you had to decide which indexing mode to use (which determined whether/how you used the index registers) | 13:22 | ||
that said, the two worst cases are also in the past. RISC, and VLIW (the late unlamented Itanium) | |||
dogbert17_ | interesting: I was convinced that it had actually become harder, having to think about caches, branch predictors, pipe stalls etc | 13:25 | |
geekosaur | those are issues, yes, but more meta-issues in some sense. | 13:26 | |
and even there, RISC was nastier --- delayed branch slots were supposed to make that easier, but instead made it harder in many cases | 13:27 | ||
by "meta-issues" I mean that to do it right, you have to think about more than just the current asm, you have to think about the program context it is invoked from | 13:28 | ||
13:29
brrt joined
|
|||
dogbert17_ | very educational, fortunately for me, the last time I had to do anything with assembler the cpu of choice was the 68000 | 13:29 | |
geekosaur | so they're more matters of *global* code generation/optimization. which is one reason LTO is becoming a thing; it has a more global viewpoint and can do a better job with that kind of optimization | ||
brrt | .tell nwc10 i've already long since arrived at the conference | 13:30 | |
yoleaux | brrt: I'll pass your message to nwc10. | ||
nwc10 | "I'm here all week" | ||
yoleaux | 13:30Z <brrt> nwc10: i've already long since arrived at the conference | ||
brrt | :-) | 13:31 | |
nwc10 | (but not necessarily awake) | ||
brrt | also, making myself redundant is very much the endgame | ||
dogbert17_ | LTO, is that what gcc is doing? | ||
geekosaur | gcc and clang both support LTO but not by default | ||
brrt | i think msvc dooes it by default | ||
it makes build times really really bad | |||
geekosaur | ("link-time optimization") | ||
brrt | it's also pretty cool optimization | 13:32 | |
dogbert17_ | do we, i.e Perl 6, use it | ||
geekosaur | no, and I don't think it realistically can | ||
brrt | dynamic optimization is in a way similar | 13:33 | |
in that it works on the rprogram in its entirety | |||
but only on the parts that are actually running | |||
that's usually a pretty good tradeoff of resources | |||
jnthn | We can inline across compilation units already, which I guess is one of the things that LTO does with C code | 13:34 | |
afaik, prior to that, inlining was only within a file? | |||
geekosaur | C99 has extern inline functions | 13:35 | |
but it has to be explicitly declared as such (and in a header file so it can be #include-d) | 13:36 | ||
brrt | jnthn, i'm curious why your branch breaks when the JIT can't JIT the right things | 13:37 | |
that's worrisome | |||
13:37
lizmat joined
|
|||
jnthn | brrt: I don't know. | 13:38 | |
brrt: But I traced it back to some time before my recent work | 13:39 | ||
So I think it's one of those spesh bugs that's long existed | 13:40 | ||
brrt | hmmm | ||
and JITting it fixes it? | |||
jnthn | I've found/fixed many of those | ||
brrt | that | ||
jnthn | Yeah | ||
Which is *really* odd | |||
brrt | which is really scary | ||
jnthn | That too | ||
brrt | because to me, it sounds like the JIT might cover up some bits | 13:41 | |
jnthn | First test I tried to bisect with the spesh limit didn't lead anywhere good. Second one has led to something that looks more sensible | 13:50 | |
In common they seem to have exceptions | |||
14:00
zakharyas joined
|
|||
timotimo | oof, so handlers and maybe how inlining treats handlers | 14:11 | |
Geth | MoarVM: 55f850ca41 | (Jonathan Worthington)++ | src/spesh/graph.c Another place needing deleted handler handling. |
14:12 | |
MoarVM: af24ab825a | (Jonathan Worthington)++ | src/spesh/inline.c Can never inline frames declaring state vars. |
|||
14:15
markmont joined
14:17
brrt joined
|
|||
jnthn | ah good, I got a golf | 14:18 | |
Ahhh. | 14:27 | ||
OK, DEPRECATED assumes $bt.next-interesting-index will always return a value, in one case | |||
But because we're inlining more aggressively these days, that doesn't actually happen | |||
Backtraces could really do with inline fixups | 14:28 | ||
14:35
lizmat joined
14:40
brrt joined
|
|||
jnthn | oh man...1 line fix. | 15:07 | |
From a thinko from 2+ years ago | |||
Or so it seems | |||
15:10
brrt joined
|
|||
japhb | Amazing how long those things can lie dormant ... | 15:17 | |
jnthn | Indeed. otoh, we inline quite a lot more than we used to | 15:19 | |
Or, the other way round, we didn't have so many inlining opportunities before. :) | |||
japhb | Heh. | 15:20 | |
Let me know when to do a Rakudo rebuild, and I'll try again with my collection of what seem to be sensitive module installs. | |||
Geth | MoarVM: c8d902a0ed | (Jonathan Worthington)++ | src/spesh/inline.c Correct handler order when inlining. We duplicate the exception handlers in force when inlining. It's true that order matters, and innermost first is searched for. Unfortunately the effort to do the right thing about that was misguided here, since we're copying from a table that's already sorted, so should just leave it in the order it was already in. |
15:29 | |
15:35
zakharyas joined
|
|||
Geth | MoarVM: c663342b48 | (Jonathan Worthington)++ | 9 files Implement inlining of basic lexical lookups. This means that we can now inline closures that look up symbols they close over. It works by introducing a new pair of lookup ops that find the code ref in a register and use it to find the outer. After JIT, this turns out to be as many dereferences as in the non-inlined case. |
15:46 | |
timotimo | whoops | 15:48 | |
jnthn | Oh, maybe one more instruction actually...forgot the initial register access. | ||
timotimo | but inlining will still give us the power to optimize more stuff | ||
jnthn | timotimo: The "as many dereferences as" is a good result | ||
It means that the machinery to make the inlining work doesn't make the lexical lookups more expensive. | 15:49 | ||
timotimo | oh! | ||
yay :) | |||
japhb | "only as many"? | 15:50 | |
jnthn | "only as many" might have been clearer | 15:51 | |
Geth | MoarVM: e50eb617db | (Jonathan Worthington)++ | src/spesh/inline.h Tune the inline size a bit. Based on looking at some benchmarks. The original bytecode size often shrinks notably during the specialization process in Perl 6 code, as the argument prelude gets gutted. We do check the size after, but it will then include any nested inlines, which made us more reluctant to do multi-level inlines. This could likely be tuned further; for now this seems a win. |
15:54 | |
jnthn | With this lot, I measure us slightly beating Perl 5 at the "read a million lines with UTF-8 and add up the chars" benchmark | 15:55 | |
With the bonus that we're counting graphemes, not codepoints. | |||
Something's a tad off with the profiler though | 15:56 | ||
The wallclock times and the spesh log both show that the loop body is 100% inlined | |||
Like, the + operator and .chars call are inlined into the loop body, and the loop body is inlined into the unit frame. | 15:57 | ||
But for some reason that isn't shown | |||
It shows the + and chars, but not the pull-one | 15:58 | ||
uh...I mean the loop body | |||
Oh but...maybe the extra profiling instructions push it over the inline limit? :) | |||
That probably will be it :P | |||
15:59
zakharyas joined
|
|||
jnthn | Anyway, hopefully this will have other similarly positive effects :) | 16:00 | |
Sadder news is that the budget for doing this stuff is about spent, so that'll be the last major new opt for now. There's a little left, while I'll use to see if the named arg alias regression that got RT'd is still a thing and hunt it down. And maybe a little further tuning if time allows. | 16:06 | ||
Really happy to have got to the point of having this kind of inlining though :) | 16:07 | ||
Time to go cook dinner. Yes, it is Indian today :) | 16:12 | ||
timotimo | \o/ | 16:18 | |
16:25
dogbert17 joined
|
|||
Zoffix | \o/ | 16:32 | |
timotimo | since there's not only getpeername but also getsockname i'll be returning two ports and two ips when an async socket is accepted | 16:33 | |
Zoffix | AlexDaniel: maybe you have a recommendation? I think it was you whose system had a ? that looked a lot different than \ twitter.com/kaokun/status/895682264998326273 | 16:35 | |
AlexDaniel | ?\ | 16:36 | |
yeah, silly me expected to look at it in my browser to see how it renders there | |||
Zoffix | Renders like this for me on this box: i.imgur.com/FbmsXq1.png | 16:37 | |
I don't think it's that much of a problem in real code, since \ is an unspace or a Capture, which tend to be in different places than ? | 16:39 | ||
AlexDaniel | Zoffix: my recommendation is really stupid. I'm using bitmap fonts for everything, these typically don't have the whole unicode range, so it falls back to any font that the system has with that glyph. This way, ascii range renders sharp and everything else is noticeably blurry | ||
Zoffix | my @stuff = keys @a ? @b; don't make much sense | ||
*if it were \ | |||
AlexDaniel | Zoffix: it works for me, but I can't see how anybody could benefit from that idea | ||
Zoffix | heh | ||
I'll leave it unanswered then :) | 16:40 | ||
AlexDaniel | example: files.progarm.org/2017-08-10-19395..._scrot.png | ||
it has slightly different angle too, so maybe the right solution would be to ping font authors to make it not look like \ | |||
I think Damian's answer would be to change your vim config to color unicode symbols differently | 16:42 | ||
and the right answer is possibly to change your emacs config to change the background color without affecting syntax highlighting (?) :) | 16:43 | ||
16:55
lizmat joined
|
|||
AlexDaniel | Zoffix: I don't know if it helps but I created this: github.com/perl6/doc/issues/1444 | 17:00 | |
Zoffix | You're chatting using emacs? | 17:01 | |
....all of a sudden the jokes about it being the whole operating system make sense :) | 17:02 | ||
AlexDaniel | yeah, I'm using ERC | 17:03 | |
timotimo | AlercsDaniel | 17:06 | |
Geth | MoarVM/asyncsocket_listen_sockname: 658b53456a | (Timo Paulssen)++ | src/io/asyncsocket.c the listen callback shall also push socket and peer ip & port |
17:11 | |
timotimo | AFK before i see to it that the rakudo portion also works | ||
AlexDaniel | timotimo: while you're at it, you may also like RT #131766 :) | 17:17 | |
synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=131766 | ||
timotimo | oh, hmm | 17:18 | |
that's more api design questions i suppose | |||
but it's correct to put uv_tcp_bind before connect to get a source ip | 17:21 | ||
for some reason i get empty strings here | 17:26 | ||
no matter, gotta run | |||
17:31
lizmat joined
17:51
lizmat joined
|
|||
AlexDaniel | .tell MasterDuke I've created a ticket. Please leave some comments there: RT #131879 | 17:51 | |
yoleaux | AlexDaniel: I'll pass your message to MasterDuke. | ||
synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=131879 | ||
AlexDaniel | FWIW I'm marking RT #131879 as a blocker, but I can easily change my mind. It is a very frustrating bug for whose who use rakudo to run long-running processes, but it could also be that I'm the only person affected. | 17:54 | |
synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=131879 | ||
17:56
lizmat joined
|
|||
AlexDaniel | for example, it only “leaks” with that specific gist, everything else seems to be normal | 18:00 | |
jnthn | AlexDaniel: I'm going to look into a leak tomorrow that may well be the same one, fwiw | 18:08 | |
18:12
AlexDani` joined
|
|||
AlexDani` | jnthn: cool, thanks | 18:14 | |
japhb | jnthn: Is there an active grant request that I can support? | 18:15 | |
Geth | MoarVM/asyncsocket_listen_sockname: b943f8236d | (Timo Paulssen)++ | src/io/asyncsocket.c you use VMString to decode strings, box it in BOOTStr |
18:32 | |
MoarVM/asyncsocket_listen_sockname: fa64450d91 | (Timo Paulssen)++ | src/io/asyncsocket.c return undefined hosts and ports in error cases |
|||
18:52
geekosaur joined
|
|||
timotimo | i wonder if i should do anything like this for the connect side, too? probably interesting to get the local host and port, but maybe not the target? | 18:54 | |
19:23
brrt joined
|
|||
timotimo | though having accessors for all four things would make things consistent | 19:32 | |
just set everything | |||
i've got a moar bump coming up to make rakudo and moarvm agree on the signature of the callbacks for listen and connect | 20:14 | ||
20:50
AlexDaniel joined
21:01
colomon joined
21:17
colomon joined
21:22
lizmat joined
|
|||
samcv | o/ | 21:50 | |
timotimo | o/ | 21:53 | |
nwc10 | o/ | 21:54 | |
oh, hangon, I should go to bed | |||
timotimo | good night nwc10 | ||
samcv: i only saw the first and about ½ of the second talk, but the parts i did watch were good | 21:55 | ||
wow holy crap that last rt bug just now | 21:56 | ||
Geth | MoarVM/asyncsocket_listen_sockname: dd95f89b93 | (Timo Paulssen)++ | src/io/asyncsocket.c also pass socket and peer names for outgoing connections |
22:03 | |
timotimo | (it didn't take me this long to do that, i just had the code uncommitted and unpushed for a while) | 22:04 | |
MasterDuke | anyone have thought/comments on github.com/MoarVM/MoarVM/pull/626 (other than i need to rebase to fix the oplist conflict)? | 22:09 | |
22:12
dogbert17 joined
|
|||
timotimo | i say go ahead and merge it | 22:20 | |
MasterDuke | rebased and force pushed | 22:23 | |
i don't have a commit bit, but maybe one of you fine people who do could merge once travis oks it | 22:24 | ||
22:28
zakharyas joined
|
|||
Geth | MoarVM: 955a9cd1a8 | (Samantha McVey)++ | src/core/interp.c Move indexim_s and eqatim_s to oplist order Move them in interp.c to oplist order. |
22:32 | |
samcv | zhuoming should be happy the ops will be back in correct order | 22:33 | |
wonder if we want to make a script to put them all in order of their numbers? though the compilier may optimize it since it sees goto statements after each | |||
jnthn | japhb: Sorry, was AFK relaxing some. 6guts.wordpress.com/2017/05/12/loo...t-funding/ is the last thing I posted on the topic, and the offer there is still current, at least. | ||
yoleaux | 21:15Z <AlexDaniel> jnthn: FWIW some kind of breakage due to f590863e17 gist.github.com/Whateverable/2a908...7ba3339af2 | ||
AlexDaniel | this is RT #131881 now I believe | 22:34 | |
synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=131881 | ||
jnthn | AlexDaniel: Which repo is f590863e17 a commit in? | ||
AlexDaniel | jnthn: rakudo, can't bisect into moarvm yet | ||
not with a bot at least | |||
22:34
markmont joined
|
|||
AlexDaniel | Geth: ver github.com/rakudo/rakudo/commit/f590863e17 | 22:35 | |
Geth | AlexDaniel, version bump brought in these changes: github.com/perl6/nqp/compare/2017....2-gd40d6dc | ||
jnthn | lol, what, I managed to make a bug such that it makes gnome-terminal-server sigabrt, thus presumably uncovering a bug in that too? :D | ||
geekosaur | yep, unicode decoding fails poorly | 22:37 | |
jnthn | AlexDaniel: Is there a way with the bot to try it with an env var set before spawning? | ||
AlexDaniel | actually, would be great to submit a bug report there as well | ||
jnthn | I'll try and recreate it tomorrow of course | ||
Though the first thing I'll do is check if MVM_SPESH_DISABLE=1 and similar hide it | 22:38 | ||
AlexDaniel | jnthn: not via IRC, no, but I can do it | ||
jnthn | I'm presuming it's one of my clever opts being less than clever... | 22:39 | |
AlexDaniel | jnthn: actually… I think all you need is just run it with MVM_SPESH_DISABLE=1 on head | ||
jnthn | AlexDaniel: Ah, yeah. :) | ||
AlexDaniel | if somebody has an idea on how should the command look like, please comment on github.com/perl6/whateverable/issu...-321693966 | 22:48 | |
“commit: MVM_SPESH_DISABLE=1 HEAD say 42” ? | |||
“commit: HEAD MVM_SPESH_DISABLE=1 say 42” ? | |||
… both? | |||
jnthn: seems to be failing with MVM_SPESH_DISABLE=1 too | 22:51 | ||
jnthn | !! | ||
Oh wow | |||
I wonder what I coulda touched that isn't spesh related... | 22:52 | ||
timotimo | AlexDaniel: i think both are fine, you can tell from the presence of = in there, right? | 22:53 | |
AlexDaniel | timotimo: yeah, I think so. Should I support arbitrary env variables? | 22:54 | |
and how likely is it that someone's code is going to start with foo=smth ? :) | |||
timotimo | hmm | ||
jnthn | I figure so, though be careful people can't shell-inejct them | ||
timotimo | very bad idea, if you don't sandbox | ||
imagine MVM_SPESH_LOG=/home/alexdaniel/.ssh/id_rsa | 22:55 | ||
AlexDaniel | not yet :'( | ||
jnthn | I mean, if you do allow any env vars, make absolutely sure that you parse them and set up a %*ENV | ||
Or similar | |||
timotimo | even without shell injection to the shell vars you can remote trash files on the FS whereever the committable bot has write access | 22:56 | |
jnthn | timotimo: Uh, but if we can do that by sending the spesh log there then a program can write there too already? :) | ||
timotimo | er, i guess | ||
AlexDaniel | I've been trying to find some time to implement sandboxing for a year… this is horrible | ||
jnthn: not really. Well yes, sure, but not as easily, because of RESTRICTED setting | 22:57 | ||
but of course working around it is very trivial | |||
timotimo | aye | ||
AlexDaniel | this is the reason why these bots don't respond to private messages. If somebody wants to destroy my server, please do it on public ?_? ?_? ?_? ?_? | 22:59 | |
.oO( this strategy is working surprisingly well ) |
23:00 | ||
timotimo | ah yes | 23:02 | |
23:23
MasterDuke joined
|
|||
AlexDaniel | what's the right falsy value for dev env vars? 0 or emtpy string? | 23:38 | |
both I guess github.com/MoarVM/MoarVM/blob/b27f...oar.c#L203 | 23:39 | ||
23:42
committable6 joined
|
|||
AlexDaniel | commit: MVM_SPESH_DISABLE=1 HEAD say %*ENV<MVM_SPESH_DISABLE> | 23:42 | |
committable6 | AlexDaniel, ¦HEAD(ec7bc25): «1» | ||
AlexDaniel | commit: MVM_SPESH_DISABLE=1 f590863e17^,f590863e17 use lib ‘data/all-modules/moritz/json/lib/’; use JSON::Tiny; use Test; my @t = '{ "a" : "b\u00E5" }' => { 'a' => 'bå' }, '[ "\u2685" ]' => [ '?' ], qq{"x\c[ZERO WIDTH JOINER]a"} => "x\c[ZERO WIDTH JOINER]a", qq{"\c[ZERO WIDTH JOINER]"} => "\c[ZERO WIDTH JOINER]"; plan (+@t); for @t -> $p { my $got = from-json($p.key); is-deeply $got, $p.value; } | 23:43 | |
committable6 | AlexDaniel, gist.github.com/2f9573fe562b78bcd1...546739f2bb | ||
AlexDaniel | :) | ||
jnthn | Hmmm | 23:46 | |
AlexDaniel++ | |||
timotimo | m: -> Mu \a? { say a }() | 23:54 | |
camelia | ===SORRY!=== Error while compiling <tmp>?Malformed parameter?at <tmp>:1?------> -> Mu \a?? { say a }()? expecting any of:? constraint? | ||
timotimo | m: -> Mu $a? is raw { say a }() | ||
camelia | ===SORRY!=== Error while compiling <tmp>?Undeclared routine:? a used at line 1?? | ||
timotimo | m: -> Mu $a? is raw { say $a }() | ||
camelia | (Mu)? | ||
timotimo | maybe i'll implement passing hosts and ports with this so i don't have to immediately bump moar when moar learns to submit those | 23:55 | |
Zoffix | AlexDaniel++ | ||
timotimo | it could then also skip sending Str, Int, Str, Int in case of errors |