Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-08-15

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:45 tadzik joined #moarvm
01:33 ShimmerFairy japhb++ for suggesting a benchmark. I did one and got to fix the slight speed decrease that resulted in my branch :)    (the time ~only~ went up .2s for the nqp benchmark, but I brought it down to basically nothing anyway)
01:34 timotimo cool, i'd like to see that dif
01:34 timotimo diff
01:34 ShimmerFairy timotimo: did you see the PR itself? Or do you want that gist I mentioned? :)
01:35 timotimo i saw the PR, i think
01:35 timotimo what gist did you mention?
01:36 ShimmerFairy I put a new comment on the PR, with a table of timing averages (the gist was just an offer for the whole file I kept track of times in, for more detail)
01:36 timotimo ah, ok
01:39 ShimmerFairy I wish I knew more about statistics; I can guess the new +0.005s difference is statistically insignificant, but I'm not sure if P6's +0.073s is statistically insignificant too :)
01:41 timotimo there are pretty long lines in that diff :S
01:41 ShimmerFairy timotimo: yeah, that's why I split the conditional into a gcNd variable in the first place :)  The indentation is what emacs' c++-mode does by default, I'm not sure what MVM prefers here
01:45 timotimo (and the // comments are discouraged in the moarvm codebase; though i think we have some of those in other places in the codebase and it at least doesn't break jnthn's build)
01:45 ShimmerFairy timotimo: I tried -std=c90 on the MVM code and it broke on the first .o file, // comments being among the issues (if not _the_ issue)
01:45 timotimo right
01:45 timotimo MSVC </3
01:45 ShimmerFairy So I figured // wasn't actually an issue. (Though I'll convert them to multi-line comments for style reasons, if desired)
01:45 ShimmerFairy timotimo: I did read that MSVC 2013 supports mixed declarations (and a couple other C99 things), so maybe there's hope? :)
01:46 timotimo wow, how long until that comes out?
01:47 ShimmerFairy Not sure, I thought the '2013' meant it was already out O_o
01:47 timotimo who knows :)
01:53 ShimmerFairy timotimo: here's a source :)  https://msdn.microsoft.com/en-us/library/hh409293%28v=vs.120%29.aspx
01:55 ShimmerFairy Might be worth pointing out to jnthn, the only issue I can foresee is the requirement for a relatively recent MSVC. (I quickly found a download page for MSVC 2013)
01:56 timotimo mhh. fortunately, hoelzro also recently made the unicode db parsable by newer MSVC
01:57 ShimmerFairy oh, I wasn't aware there was forward-compatible(?) issues concerning MSVC.
02:01 ShimmerFairy that reminds me: if I at some point need to change something in ucd2c.pl, there's no guarantee I won't end up wasting my time on a P6 version of the script I can more easily understand :P
02:01 ShimmerFairy (though I wouldn't hold off the actual change if I can put it in the P5 version, of course ☺)
02:03 timotimo the newer MSVC failed to parse the unicode_db.c (or what it's called) file because it was too complex
02:03 timotimo also, hoelzro put in a binary search for block membership or something along those lines
02:04 ShimmerFairy Ah, wonder what it tripped up on specifically (there's a git log for that, I'm sure).
02:05 timotimo too deeply nested struct perhaps?
02:05 timotimo it's way late over here, i'll soon go looking for some sleeps
02:05 ShimmerFairy > A large number of if/else chains breaks the VS 2015 compiler.
02:07 ShimmerFairy timotimo: have a good rest :) I'm curious if strings/unicode.c is outdated, since it seems similar to unicode_db.c, but I can ask others about it later.
02:15 TEttinger ShimmerFairy: yeah I hit that error with VS 2015
02:15 TEttinger 2013 worked fine
02:16 ShimmerFairy Interesting, I wonder how they broke if/else chains (I imagine they broke large chains while improving something else, and didn't have a test case for something you'd normally not write)
02:17 TEttinger 2015 uses a new compiler I think, different codebase (Roslyn allows the compiler to be used more at runtime, which is very handy for an IDE)
02:17 TEttinger but I don't know if that also applies to C/C++
02:18 ShimmerFairy Looking at the diff to see the if/else chain, my mind says "write a lambda to abstract this and then loop through all the possible sets of arguments you'd pass to the lambda", but that's a very C++11 way of thinking :P
02:18 TEttinger 2015 has decent C++11 support actually I think
02:18 TEttinger not great
02:19 ShimmerFairy the unicode_blocks[] array that was added is pretty much the array I'd set up for the arguments I'd send to a lambda :)
02:21 ShimmerFairy TEttinger: I tend to like using the latest and greatest features. I'd be making use of C++14 if portage would unmask gcc 4.9 or higher :)
02:22 TEttinger you're in the channel for a brand new VM for an as-yet-not-finally-released version of an incredibly feature-heavy language, I would imagine you're not the only onme who likes latest and greatest :)
02:22 ShimmerFairy I'd be interested in seeing how C would do lambdas, if it ever felt the need to.
02:24 ShimmerFairy TEttinger: it's a good thing MVM isn't my project though; I would've started using C11/C14 and said "get a better compiler" to those without :P (well, I wouldn't be a jerk about it, but undoubtedly if I learned C for my own uses I'd go for the newest versions)
03:47 lizmat joined #moarvm
04:42 hoelzro TEttinger: did you end up getting MoarVM to complete on VS2015?
04:43 TEttinger since 2013 worked I didn't try 2015 again
04:43 TEttinger it was a compiler stack overflow error in that same unicode file
04:45 hoelzro we managed to fix that
04:46 hoelzro but after I got MoarVM, I wasn't able to build NQP, and I was wondering if others had seen that
04:47 ShimmerFairy hoelzro: do you know if unicode.c is outdated, perchance? Hasn't been touched since 2012 according to git log, and at a glance it's supposed to do the same thing as unicode_db.c
04:48 hoelzro ShimmerFairy: IIRC, unicode.c is updated as part of the Moar build process
04:48 hoelzro I think that it's the result of concatenating unicode_db.c and some other file, I forget which
04:50 ShimmerFairy Huh. Weird that it has a git history then
04:52 hoelzro yeah, I felt the same =/
04:52 hoelzro I think it may have been committed by mistake?
07:06 brrt joined #moarvm
07:16 rurban_ joined #moarvm
07:22 brrt \o
07:23 brrt timotimo: ehm.... why not emit a repr id check?
07:25 brrt oh by the way, i was *wrong* about the tiler i an important way
07:25 brrt it does require a separate selection step, implemented in preorder traversal
07:26 brrt which requires a separate table
07:26 brrt luckily, not very conceptually difficult
09:29 brrt hmm, weird
09:45 FROGGS_ joined #moarvm
09:50 dalek MoarVM/even-moar-jit: 5af12ba | brrt++ | src/jit/ (6 files):
09:50 dalek MoarVM/even-moar-jit: Comments and cleanup
09:50 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/5af12ba391
10:07 dalek MoarVM/even-moar-jit: 80c4400 | brrt++ | / (2 files):
10:07 dalek MoarVM/even-moar-jit: Split optimum rule table from tiler state table
10:07 dalek MoarVM/even-moar-jit:
10:07 dalek MoarVM/even-moar-jit: Optimum rules for child nodes depend on rule nr for parent and
10:07 dalek MoarVM/even-moar-jit: cannot be derived from rulesets alone, because different rules
10:07 dalek MoarVM/even-moar-jit: in rulesets may refer to different terminals (and as such need
10:07 dalek MoarVM/even-moar-jit: to pick different child rules to implement). Thus, the child rules
10:07 dalek MoarVM/even-moar-jit: need to be 'pushed down' into the tree.
10:07 dalek MoarVM/even-moar-jit:
10:07 dalek MoarVM/even-moar-jit: This commit fixes only tiler table generation, not yet tile rule
10:07 dalek MoarVM/even-moar-jit: propagation.
10:07 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/80c44007ad
10:07 * brrt lunch &
10:32 dalek joined #moarvm
11:14 timotimo brrt, i could probably emit a repr id check, but then i'd have to put a function call in the middle of a conditional :|
11:16 timotimo the function call to die, that i
11:16 timotimo is*
11:16 timotimo alternatively invent a deopt point
11:17 ShimmerFairy I vaguely recall spesh or something having the ability to back out of optimizing, or something.
11:36 dalek MoarVM/optimize: d3c7dfa | (Jimmy Zhuo)++ | / (5 files):
11:36 dalek MoarVM/optimize: add MVM_unicode_cname_to_property_value_code and use it, which avoids some string encoding and decoding at startup
11:36 dalek MoarVM/optimize: review: https://github.com/MoarVM/MoarVM/commit/d3c7dfaf2a
11:36 JimmyZ jnthn: ^^ any object to merge it into master?
11:41 ShimmerFairy JimmyZ: the _cname_ function looks interesting to me; I have a pull request whose code can probably lighten up if I used a c-string instead of generating an MVM-specific string type :)
11:41 jnthn JimmyZ: Looks OK to me at a first glance
11:43 JimmyZ ShimmerFairy: I saw your pull request and I found the addtional encoding/decoding :P
11:44 timotimo ShimmerFairy: yeah, i could add a "guard for correct repr id" op and that'd allow us to deopt properly
11:45 dalek MoarVM: d3c7dfa | (Jimmy Zhuo)++ | / (5 files):
11:45 dalek MoarVM: add MVM_unicode_cname_to_property_value_code and use it, which avoids some string encoding and decoding at startup
11:45 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d3c7dfaf2a
11:45 timotimo jnthn: do you think it'd make sense to add repr id to the logging, guarding and deopting mechanism?
11:46 jnthn timotimo: Only if it's going to save us a lot
11:46 timotimo unlikely
11:46 jnthn Or unless it can be done with very few changes
11:46 timotimo i'd introduce a fact and a guard op
11:47 ShimmerFairy JimmyZ: cool :) I don't know if I should merge master into my branch so I can use cname and thus set things up for a second merge, or if it'd be better to let that be corrected after the pull request has been merged.
11:48 timotimo it might help us devirtualize reprops if the type keeps changing, but the repr is constant
11:48 jnthn timotimo: We have to be real careful there though
11:48 jnthn timotimo: Because many repr ops (like those into arrays) depend on REPR_data (e.g. for array elem size)
11:48 jnthn timotimo: Which is part of the type
11:48 timotimo ah
11:48 timotimo fair enough
11:52 JimmyZ if nobody object it ,I could merge it
11:53 JimmyZ ShimmerFairy: ^^ :)
11:54 JimmyZ or I just merge it, nd if someone don't like it, and then revert it.
11:54 ShimmerFairy Once it gets merged, I can work on finalizing the changes I made to nqp and rakudo as well :)
11:57 JimmyZ ShimmerFairy: the comment of bigintops.c about Unicode 6.0.0, should a bit move down?
11:59 ShimmerFairy oh huh, I guess I did move the comment down in one of the files, to be inside the conditional it matters in
12:00 ShimmerFairy Yes, it would make more sense inside the conditional where it matters, but it would also make for a really large conditional for just one line of code :)
12:01 ShimmerFairy (I don't mind if my comments are cut down though, I have a habit of being quite descriptive in my comments.)
12:01 jnthn ShimmerFairy: Can you point at the bit of Perl 6 design that these changes are intended to handle (I'm sure it's there, just want to have something to compare code against)
12:02 ShimmerFairy sure, I have a test file for the stuff I'm trying to implement
12:03 ShimmerFairy jnthn: https://github.com/perl6/roast/blob/master/S15-literals/numbers.t  and  http://design.perl6.org/S15.html#Numbers
12:04 ShimmerFairy the MoarVM changes are because I pretty quickly found that radix_I led down to the VM, and I figured changes there would be easier than changing how nqp and Perl6 interacted with nqp::radix[_I]
12:05 jnthn ShimmerFairy: Yes, agree it's the right place to fix it
12:06 jnthn Oh, after fastpath the speed drop is negligible
12:07 jnthn And yeah, if it can be further reduced that's great
12:07 ShimmerFairy jnthn: I did commit the speed improvement to the uninum branch, if you didn't spot it.
12:08 jnthn ShimmerFairy: I did
12:08 JimmyZ so I can merge it. and I didn't see anything slowdown
12:08 jnthn https://github.com/ShimmerFairy/MoarVM/commit/813bbd93cdbcd66118088437d526f98b684bef58#diff-a6d53c5ba49dcd1d4a11424f416f2eedR366 would look nicer if you didn't indent things to match the opening arg
12:08 jnthn (Which we don't do anywhere else in MoarVM because the result is, well, this. :))
12:09 jnthn Just one extra level of indent beyond what the loop body would have is enough
12:09 jnthn Or even better
12:09 jnthn Stick the thing in the condition in a static function
12:09 jnthn With a nice name
12:09 ShimmerFairy jnthn: yes, I would agree (that's what c-mode does by default for whatever reason). Since I wasn't sure how to indent myself, I figured keeping it as my tab key did, to be safe.
12:10 ShimmerFairy I actually usually would prefer an indentation close to the opening paren, but in this case I'm definitely not much of a fan for it :)
12:10 jnthn (C compilers are really quite good these days at making inlining decisions.)
12:10 jnthn (And if you don't trust it there's MVM_STATIC_INLINE to force it to happen)
12:11 jnthn Anyway, those small details aside the patch looks good to me.
12:11 jnthn (And I don't mind the PR getting merged and then a later clean-up PR coming if that's easier)
12:12 ShimmerFairy I think a static function would be nice. In this case, it seems like a nice analogy to the "inner sub" idea in P6 (or my personal usage of lambdas in C++11, incidentally based on P6's inner subs ☺)
12:12 dalek MoarVM: ce890e6 | paultcochrane++ | src/6model/reprs/MVMArray.c:
12:12 dalek MoarVM: Fully initialise `spec` before setting and returning it
12:12 dalek MoarVM:
12:12 dalek MoarVM: The structure `spec` was only partially set by the code in
12:12 dalek MoarVM: get_elem_storage_spec() and thus parts of it could be used uninitialised.
12:13 dalek joined #moarvm
12:13 ShimmerFairy jnthn: I'm just now getting used to being comfortable with merges (since usually I would just wait to commit and/or rebase things instead), so I'm not sure if a master->uninum merge and then a uninum<-master merge in order for me to do the switch to _cname_ is considered ugly or not.
12:14 ShimmerFairy er, the branch names weren't supposed to flip around in the <- one :)
12:16 jnthn ShimmerFairy: I think if I hit "merge pull request" we'll just get the 3 commits and a merge commit, which is fine
12:17 dalek MoarVM: 39abc80 | ShimmerFairy++ | src/math/bigintops.c:
12:17 dalek MoarVM: Add Unicode support to MVM_bigint_radix
12:17 dalek MoarVM:
12:17 dalek MoarVM: This means taking any Nd character and any alphabet with letters that
12:17 dalek MoarVM: have a true Hex_Digit property. Nd characters are guaranteed to be in
12:17 jnthn There we go
12:17 dalek joined #moarvm
12:17 ShimmerFairy jnthn: yeah, my understanding of "branches are just pointers" led me to infer that I won't be causing big amounts of extra data to go around for the sake of branches :)
12:18 jnthn ShimmerFairy: Yeah, git has a really nice branching model :)
12:18 * jnthn did a lot of git teaching for a couple of years, so got to know it quite well :)
12:18 ShimmerFairy .oO("Oh no, what if I end up sending a branch to the server?!"   "You just sent a pointer. Congratulations.")
12:20 dalek MoarVM: c852917 | (Jimmy Zhuo)++ | src/ (3 files):
12:20 dalek MoarVM: some small cleanup
12:20 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c852917a12
12:20 dalek MoarVM: 63c89a0 | (Jimmy Zhuo)++ | src/ (2 files):
12:20 dalek MoarVM: Merge branch 'master' of https://github.com/MoarVM/MoarVM
12:20 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/63c89a0021
12:20 ShimmerFairy It feels weird at first when you learn that those branches you see and visualize are actually just markers on a collection of commits that are otherwise only organized by their parents, but it does work out quite nicely I find.
12:23 travis-ci joined #moarvm
12:23 travis-ci MoarVM build failed. Jimmy Zhuo 'Merge pull request #213 from paultcochrane/pr/smoke-me/init-uninit-vars
12:23 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/75723762 https://github.com/MoarVM/MoarVM/compare/d3c7dfaf2aa7...e24bfef078f9
12:23 travis-ci left #moarvm
12:25 jnthn JimmyZ: Umm... ^^ looks unhappy
12:31 timotimo yeah, undeclared names inside unicode.c
12:33 travis-ci joined #moarvm
12:33 travis-ci MoarVM build failed. Jonathan Worthington 'Merge pull request #233 from ShimmerFairy/uninum
12:33 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/75724004 https://github.com/MoarVM/MoarVM/compare/e24bfef078f9...cf1cafd9f737
12:33 travis-ci left #moarvm
12:33 JimmyZ travis-ci is slow ....
12:34 timotimo :|
12:36 ShimmerFairy oh, it's a result of the ptc merge, not my commit, it seems (since my PR tested just fine before merging)
12:37 dalek MoarVM: 4ae29a6 | (Bob Kuo)++ | / (10 files):
12:37 dalek MoarVM: Fix a few items found by warnings
12:37 dalek MoarVM:
12:37 dalek MoarVM:   * Make some casts explicit
12:37 dalek MoarVM:   * Fixup printf formats
12:38 dalek joined #moarvm
12:38 ShimmerFairy is it just me, or does dalek have a low tolerance for flooding in here?
12:46 travis-ci joined #moarvm
12:46 travis-ci MoarVM build passed. Jimmy Zhuo 'Merge branch 'master' of https://github.com/MoarVM/MoarVM'
12:46 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/75724188 https://github.com/MoarVM/MoarVM/compare/cf1cafd9f737...63c89a002114
12:46 travis-ci left #moarvm
12:49 dalek MoarVM: dd5f168 | (Francois Perrad)++ | src/gc/collect.c:
12:49 dalek MoarVM: remove hard tab
12:49 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/dd5f168c0d
12:49 dalek MoarVM: 7691658 | (Francois Perrad)++ | src/ (4 files):
12:49 dalek MoarVM: fix indentation
12:50 dalek joined #moarvm
12:58 travis-ci joined #moarvm
12:58 travis-ci MoarVM build passed. Jimmy Zhuo 'Merge branch 'fix_warnings' of https://github.com/bubaflub/MoarVM into bubaflub-fix_warnings
12:58 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/75725110 https://github.com/MoarVM/MoarVM/compare/63c89a002114...240e22d8419e
12:58 travis-ci left #moarvm
13:04 JimmyZ m: m: my \SCALE = 3; my \FANOUT = 2; sub divide-and-conquer($n, $depth) { say "$depth: $n" if 0; $depth <= 0 ?? $n !! [+] await do for ^FANOUT { start { divide-and-conquer($n / FANOUT, $depth - 1) } } }; say divide-and-conquer(1.0, SCALE);
13:04 camelia rakudo-moar ab73b0: OUTPUT«Memory allocation failed; could not allocate 656 bytes␤»
13:13 timotimo JimmyZ: you want div instead of /, no?
13:14 JimmyZ m: m: my \SCALE = 3; my \FANOUT = 2; sub divide-and-conquer($n, $depth) { say "$depth: $n" if 0; $depth <= 0 ?? $n !! [+] await do for ^FANOUT { start { divide-and-conquer($n div FANOUT, $depth - 1) } } }; say divide-and-conquer(1.0, SCALE);
13:14 camelia rakudo-moar ab73b0: OUTPUT«Cannot call infix:<div>(Rat, Int); none of these signatures match:␤    (Int:D \a, Int:D \b)␤    (int $a, int $b --> int)␤  in sub divide-and-conquer at /tmp/XPknKSEM4k:1␤  in block <unit> at /tmp/XPknKSEM4k:1␤␤»
13:14 timotimo oh, hold on
13:14 timotimo i thought you were using / for the abort condition
13:53 Peter_R joined #moarvm
14:14 dalek joined #moarvm
14:41 dalek joined #moarvm
15:07 brrt joined #moarvm
15:10 TEttinger joined #moarvm
15:14 zakharyas joined #moarvm
15:29 brrt let it be noted that 'shrink the tiler tables' is on the todo list
15:31 brrt but not very high
15:31 brrt :-) not like 'make the damn thing work, already'
15:52 timotimo i can imagine you're a bit annoyed by more and more requirements apparently stepping out into the light
16:01 arnsholt brrt: My brain threw up more words after our discussion the other day. Formally, I think the problem you're working on is a kind of tree-to-string transducer
16:02 brrt oh, really? the tiler in general, you mean?
16:02 arnsholt Yeah, I think so. The input is a tree (our actually a DAG, IIRC?) and the output is a string
16:02 brrt well, it's more like 'hey, you didn't think of that, now did you?' for me, timotimo
16:02 brrt yes
16:02 brrt i think that's a good way to put it
16:03 arnsholt Which is basically a transducer problem. Have you encountered them before?
16:03 brrt i have not
16:03 brrt for what it's worth, my theorethical difficulties are mostly over, and i was planning to blag about it :-)
16:04 arnsholt Good to hear! The theory is usually the hardest bit, IME =)
16:04 arnsholt Anyways, transducers are a bit niche, but the string-to-string case is a classical technique in my field (computational linguistics)
16:05 brrt yeah, without theory you can just get stuck, unfortunately
16:06 arnsholt For regular languages, you process them with a variant of FSAs (called finite state transducers) where each arc (or each node, the formulations are equivalent) also *outputs* a symbol when traversed
16:06 brrt is that like syntax directed translation?
16:06 arnsholt It's the formalisation of regex search-replace
16:06 arnsholt Yeah, I think you can see translation as related
16:07 arnsholt So where an FSA defines a language (which is a set), the FST defines a relation (a subset of the cross product of the input and output languages)
16:10 dalek MoarVM: 5716fae | (Jimmy Zhuo)++ | src/ (2 files):
16:10 dalek MoarVM: change MVM_unicode_name_to_property_value_code to MVM_unicode_cname_to_property_value_code
16:10 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5716faee8e
16:24 dalek MoarVM/even-moar-jit: 74576ee | brrt++ | / (4 files):
16:24 dalek MoarVM/even-moar-jit: Add preorder tile downpropagation step
16:24 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/74576eea1c
16:24 * brrt dinner &
18:14 zakharyas joined #moarvm
20:26 camelia joined #moarvm
22:06 TEttinger joined #moarvm
22:52 Peter_R joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary