MasterDuke but: [dan@alexandria p6]$ p6 -e 'my $a = class :: { has uint64 $.foo is rw }.new; $a.foo = -1; say $a.foo' -1 00:05
timotimo: that first one i did in the new if Mu.BUILDALL: nqp::if(%attrinit.AT-KEY(nqp::p6box_s(nqp::atpos($task,2))) < 0, nqp::die("native unsigned integers can't be negative"), nqp::bindattr_u(self, ... 00:07
wow, that wasn't explained well at all. i added a new plan type in create_BUILDPLAN in src/Perl6/Metamodel/BUILDPLAN.nqp and handle it in BUILDALL in src/core/Mu.pm by copying the case for native int attributes and just call bindattr_u instead of bindattr_i 00:25
but what i just added was the above nqp::if right before the bindattr_u 00:26
00:32 matiaslina joined 00:37 matiasli1a joined 00:52 matiaslina joined 01:53 geekosaur joined 05:22 domidumont joined 05:33 spebern joined 05:35 domidumont joined 05:41 TimToady joined 06:15 domidumont joined 06:29 spebern joined 06:43 domidumont joined 06:46 brrt joined 07:45 zakharyas joined 08:52 dogbert17 joined 08:57 domidumont joined 09:42 domidumont1 joined
brrt good * #moarvm 09:52
10:26 MasterDuke joined
nwc10 good *, brrt 10:43
jnthn o/ all
brrt \o jnthn, nwc10 10:46
so, have we discussed rewriting MoarVM in a memory-safe language
because the current state of computer security is just unacceptable 10:47
jnthn Well, to the degree that we're gradually planning to write more of it in NQP with time... :)
brrt … okay, i'm not serious
:-P
it's 2 days too late for april's fools, 10:48
jnthn :P
"C is dying!" :P
brrt i did seriously start reading the rust documentation. it does not, so far, agree with me
although
it did make me think about my own obsession with pre-computing the maximum bounds 10:49
and part of the nonagreeingness, has to do with the style / tone 11:25
'rust will fail if you put a semicolon after the final expression, cuz statements don't yield values, never used a expression-based-language before, huh sucker' 11:26
anyway, on to business 11:27
Voldenet jnthn: C is dying for 40 years now, but it's very slow and painful death 11:31
brrt in the sense that everybody starts dying at birth, maybe 11:32
Voldenet that's incredibly deep
brrt in any of the useful population dynamics senses of 'dying' (rather: going extinct), not at all
Voldenet in fact, C89 did die, but C's offsprings (C99) are for some reason named C 11:33
jnthn lol, tell that to MSVC :P
(Which stuck with C89, 'cus of course nobody uses C any more, so all efforts should go on C++ support...) 11:34
Voldenet :-)
brrt anyway. I'd been working out a way to 'auto-unconditionalize' a varialbe computation 11:36
in the expr jit
i've been thinking a bit more about it
and i realized that there's been a number of things i've been missing 11:37
the problem is basically this: (if (test …) $foo (derive $foo)) 11:38
if it so happens that the first branch of the if is the first to compute $foo, the tiler will not insert the code to recompute it in the second branch
so in that case we should have the computation of $foo be moved prior to the if
(because it will be used either way) 11:39
this case is pretty simple, but,
we can have very complex chains of short-circuiting ALL and ANY
so the concept that i've been missing is the 'unconditional scope of definition' 11:40
i.e. the full set of code paths that follow a definition 11:41
the second concept is reorderability; as in, is it even safe to reorder this operation? (It may be protected by an ALL) 11:42
jnthn Was gonna say, lifting such things ain't always safe :) 11:54
brrt indeed 11:56
so that makes me wonder if it is worthwhile 11:57
jnthn Well, as a later optimization perhaps :) 11:58
brrt well, the point is to make stuff correct 'automatically' as it where 12:01
it's a correctness issue
currently we can resolve that by 'let-rooting'
i.e. if you have a template: (let (($foo (copy $bar))) (if (test ..) $foo (derive $foo)); then the template inserter will ensure that the (copy $bar) will be ordered prior to the if 12:02
but that doesn't work in a nested way
jnthn What does derive do? 12:04
brrt derive is just some made-up thing, the point is that it often happens that if we have a check of a field, then different uses of the same value in the two branches, is a quite common pattern 12:07
jnthn aha, ok 12:09
brrt however, that uses a global ordering; and that's still pretty rough 12:16
12:32 zakharyas joined
timotimo jnthn: i'd like to bounce an idea off of you that i had last night before falling asleep: what if we log the flattening results of callsites we couldn't intern, and then generate a quick check if the flattening would be the same as we logged and call the function with a static callsite, otherwise call it with the flattening one? 13:03
then we could spesh calls that use flattening, but that tend to have the same nameds and number-of-positionals each time
jnthn Maybe...perhaps another option would be to try and intern the results of common flattenings... 13:05
So we map them to interned callsites in some case
*cases
Then I think the rest would just fall out, maybe
Would need to be hugely careful about concurrency control, though 13:06
timotimo i think we do have a lock on the intern-callsite-operation 13:08
i'm not all too familiar with the argument passing code - neither forwards nor backwards; how do we map the callsite to something common in a way that spesh would understand?
or would it just use that to figure out if there's already a candidate and just dynamically call that?
instead of making it possible to inline it via spesh? 13:09
i think i understand how you meant that
jnthn iirc, we use callsite address as a specialization key 13:10
I'm not sure we'll get the point of being able to inline it especially easily
timotimo not without some logging step, i believe 13:11
jnthn But we could at least manage to call into a specialized form
timotimo right
how would we count "common" flattenings without having a hash that has every single flattening result in it? :) 13:12
i.e. if we for "aaa".."zzz" { mysub(|%($_ => 1)) }, how do we not asplode memory usage there?
i suppose we can easily have a limit of 32 (random-number) callsites we're considering and when we put one more in, we just throw a random one out 13:14
er
a random one that has the lowest score
actually, if we only throw out a random lowest-scored one, we can still be gamed 13:19
but how often does an attacker have control over keys that get flattened into function calls ...
maybe a web framework that puts headers into user functions via flattening rather than just as a hash?! 13:20
nwc10 I think that one needs not to forget "Build something that is fool proof and they will build a better fool." 13:21
in that, if it's possible for some code to hit paths that go pathalogical 13:22
than someone is going to write code that ends up doing that given someone else's crap (or malicious) input
timotimo well, even if we get attacked, it doesn't have a big impact 13:29
just means fewer routines get speshed and jitted
if a function that gets called with flattening arguments calls other functions without flattening in turn, then those can still be speshed and jitted, of course
13:34 brrt joined
Zoffix Voldenet: there is a case where a multi will choke, 'cause we have IntStr type 13:44
m: multi foo (Int) { say "Int" }; multi foo (Str) { say "Str" }; foo <42>
camelia Ambiguous call to 'foo'; these signatures all match:
:(Int $)
:(Str $)
in block <unit> at <tmp> line 1
Zoffix m: multi foo (Int) is default { say "Int" }; multi foo (Str) { say "Str" }; foo <42> # easy to fix tho 13:45
camelia Int
jnthn Zoffix: Wrong chan?
Zoffix jnthn: I'm not in that chan, just spotted while backlogging a bit :)
jnthn Oh :)
timotimo pff, perl6ers! coming to #moarvm all the time, demanding we fix some serious bugs or something! 13:46
Voldenet s/demanding/asking kindly/ ;)
jnthn You'd think we built the VM for Perl 6 or something :P
timotimo so is that what "build it and they will come" means? 13:48
14:02 geekosaur joined 14:04 geekosaur joined 14:17 brrt joined 15:06 brrt joined 15:23 zakharyas joined 15:33 AlexDaniel joined 16:50 domidumont joined 17:34 zakharyas joined 18:41 dalek joined
samcv nice just got quad core cpu in the mail :) 19:07
Moar cores yay
timotimo nice nice
compiling moar benefits immediately from more cores
the rest of moar ... not so much, sadly
samcv yeah 19:08
need to put it in. but just got it in the mail
timotimo right
i hope it comes with some heat-conducting glue
samcv also can run tests faster
glue?
literally glue or do you mean the heat conducting goop 19:09
timotimo the goop
the german name is "wärmeleitpaste", literally "warmth conducting paste" 19:10
but for some reason i was thinking "heißkleber", which is "hot glue" like you'd put into a hot glue pistol
samcv wow this is fascinating www.dropbox.com/sh/p9vga1dc2t02pqw...d.pdf?dl=0 Unicode proposal for chess pieces to allow chess pieces on black backrnound or on white background 19:18
since apparently nobody uses the unicode ones, and uses all these weird fonts with different mappings
seems somewhat compelling after redaing it. and kind of neat
19:32 brrt joined
brrt good *, #moarvm 19:32
i 19:33
i've been doing some more thinking about the issue i was mentioning earlier today
i.e. the automatic correctness-ensuring ordering
part of the problem, if you will, is that the current solution executes any let-statements prior to the expression 19:34
so you can't do nested LET
or you can, but it doesn't make sense; it's not guarded against any IF statements etc 19:35
that's too strong
so what would be better is if we'd automatically translate the LET to a DO (or DOV); that would let the programmer solve the ordering problem, but locally 19:42
a potential optimizer can still do reorderings, but then it's no longer a correctness problem
19:47 agentzh joined 21:35 agentzh joined 21:37 agentzh_ joined 22:17 agentzh joined
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2017/04/03/...-advances/ 22:19
timotimo lizmat: huh, was FCO the one to do the signedness fix? am i confusing that with the work masterduke and me did? 22:21
lizmat argh, right 22:22
no, I'm confused
timotimo i just want masterduke's contributions to not go unmentioned :3 22:23
lizmat updated 22:24
timotimo++
22:38 mtj_ joined
Geth MoarVM: 83715b4d73 | (Timo Paulssen)++ | .appveyor.yml
first attempt at an appveyor config.
 22:42
timotimo jnthn: looks like you'd have to flip the switch on github's side to get the builds to automatically start when we push commits 22:43
'make' is not recognized as an internal or external command, 22:45
gaaaah windows
it's nmake that i'm supposed to use, right?
Geth MoarVM: 28c108bf84 | (Timo Paulssen)++ | .appveyor.yml
windows has nmake rather than make.
 22:46
MoarVM: 53c1220414 | (Timo Paulssen)++ | .appveyor.yml
of course windows can't use multiple processors.
 22:50
samcv yeah msdn.microsoft.com/en-us/library/afyyse50.aspx totally not in this list i think 22:52
timotimo maybe you have to launch two nmake processes at the same time and hope they'll somehow prevent each other from running the same part of the job at the same time 22:53
like, i bet windows devs have developed this elaborate technique for working around the fact that windows' make can't parallelize
"well, you measure exactly how long the first part of the build takes, and after that delay you launch nmake a second time!"
or even better 22:54
samcv LOL
timotimo "you write one makefile with one half of all .c files, and the other with the other half. and then a third to link the final binary."
samcv of course
heh
timotimo "here we've even got this in-house tool that figures out how best to distribute .c files across the two makefiles to make it go as fast as possible!"
samcv brilliant
timotimo it's now cloning nqp 22:55
it's getting exciting
Geth MoarVM: cc03eac5ad | (Timo Paulssen)++ | .appveyor.yml
this is surely the last problem before it all works!
 22:58
timotimo i'll AFK for like 10 minutes, i don't want to look at it while it's trying to do its thing
samcv surely! 22:59
timotimo i almost forgot to press "new build" before going! 23:01
Geth MoarVM: 7209145641 | (Timo Paulssen)++ | .appveyor.yml
tell the harness to not hide output from us
 23:51

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!