00:45 tadzik joined
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:33
timotimo cool, i'd like to see that dif 01:34
diff
ShimmerFairy timotimo: did you see the PR itself? Or do you want that gist I mentioned? :)
timotimo i saw the PR, i think 01:35
what gist did you mention?
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
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:39
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
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)
timotimo right
MSVC </3
ShimmerFairy So I figured // wasn't actually an issue. (Though I'll convert them to multi-line comments for style reasons, if desired)
timotimo: I did read that MSVC 2013 supports mixed declarations (and a couple other C99 things), so maybe there's hope? :)
timotimo wow, how long until that comes out? 01:46
ShimmerFairy Not sure, I thought the '2013' meant it was already out O_o 01:47
timotimo who knows :)
ShimmerFairy timotimo: here's a source :) msdn.microsoft.com/en-us/library/h...20%29.aspx 01:53
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:55
timotimo mhh. fortunately, hoelzro also recently made the unicode db parsable by newer MSVC 01:56
ShimmerFairy oh, I wasn't aware there was forward-compatible(?) issues concerning MSVC. 01:57
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
(though I wouldn't hold off the actual change if I can put it in the P5 version, of course ā˜ŗ)
timotimo the newer MSVC failed to parse the unicode_db.c (or what it's called) file because it was too complex 02:03
also, hoelzro put in a binary search for block membership or something along those lines
ShimmerFairy Ah, wonder what it tripped up on specifically (there's a git log for that, I'm sure). 02:04
timotimo too deeply nested struct perhaps? 02:05
it's way late over here, i'll soon go looking for some sleeps
ShimmerFairy > A large number of if/else chains breaks the VS 2015 compiler.
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:07
TEttinger ShimmerFairy: yeah I hit that error with VS 2015 02:15
2013 worked fine
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:16
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
but I don't know if that also applies to C/C++
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
not great
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:19
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:21
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.
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) 02:24
03:47 lizmat joined
hoelzro TEttinger: did you end up getting MoarVM to complete on VS2015? 04:42
TEttinger since 2013 worked I didn't try 2015 again 04:43
it was a compiler stack overflow error in that same unicode file
hoelzro we managed to fix that 04:45
but after I got MoarVM, I wasn't able to build NQP, and I was wondering if others had seen that 04:46
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:47
hoelzro ShimmerFairy: IIRC, unicode.c is updated as part of the Moar build process 04:48
I think that it's the result of concatenating unicode_db.c and some other file, I forget which
ShimmerFairy Huh. Weird that it has a git history then 04:50
hoelzro yeah, I felt the same =/ 04:52
I think it may have been committed by mistake?
07:06 brrt joined 07:16 rurban_ joined
brrt \o 07:22
timotimo: ehm.... why not emit a repr id check? 07:23
oh by the way, i was *wrong* about the tiler i an important way 07:25
it does require a separate selection step, implemented in preorder traversal
which requires a separate table 07:26
luckily, not very conceptually difficult
hmm, weird 09:29
09:45 FROGGS_ joined
dalek arVM/even-moar-jit: 5af12ba | brrt++ | src/jit/ (6 files):
Comments and cleanup
 09:50
arVM/even-moar-jit: 80c4400 | brrt++ | / (2 files):
Split optimum rule table from tiler state table

Optimum rules for child nodes depend on rule nr for parent and cannot be derived from rulesets alone, because different rules in rulesets may refer to different terminals (and as such need to pick different child rules to implement). Thus, the child rules need to be 'pushed down' into the tree.
This commit fixes only tiler table generation, not yet tile rule propagation.		 10:07
brrt lunch &
10:32 dalek joined
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:14
the function call to die, that i 11:16
is*
alternatively invent a deopt point
ShimmerFairy I vaguely recall spesh or something having the ability to back out of optimizing, or something. 11:17
dalek arVM/optimize: d3c7dfa | (Jimmy Zhuo)++ | / (5 files):
add MVM_unicode_cname_to_property_value_code and use it, which avoids some string encoding and decoding at startup
 11:36
JimmyZ jnthn: ^^ any object to merge it into master?
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
JimmyZ ShimmerFairy: I saw your pull request and I found the addtional encoding/decoding :P 11:43
timotimo ShimmerFairy: yeah, i could add a "guard for correct repr id" op and that'd allow us to deopt properly 11:44
dalek arVM: d3c7dfa | (Jimmy Zhuo)++ | / (5 files):
add MVM_unicode_cname_to_property_value_code and use it, which avoids some string encoding and decoding at startup
 11:45
timotimo jnthn: do you think it'd make sense to add repr id to the logging, guarding and deopting mechanism?
jnthn timotimo: Only if it's going to save us a lot 11:46
timotimo unlikely
jnthn Or unless it can be done with very few changes
timotimo i'd introduce a fact and a guard op
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:47
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
timotimo: Because many repr ops (like those into arrays) depend on REPR_data (e.g. for array elem size)
timotimo: Which is part of the type
timotimo ah
fair enough
JimmyZ if nobody object it ,I could merge it 11:52
ShimmerFairy: ^^ :) 11:53
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 :)
JimmyZ ShimmerFairy: the comment of bigintops.c about Unicode 6.0.0, should a bit move down? 11:57
ShimmerFairy oh huh, I guess I did move the comment down in one of the files, to be inside the conditional it matters in 11:59
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:00
(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)
ShimmerFairy sure, I have a test file for the stuff I'm trying to implement 12:02
jnthn: github.com/perl6/roast/blob/master.../numbers.t and design.perl6.org/S15.html#Numbers 12:03
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:04
jnthn ShimmerFairy: Yes, agree it's the right place to fix it 12:05
Oh, after fastpath the speed drop is negligible 12:06
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.
jnthn ShimmerFairy: I did 12:08
JimmyZ so I can merge it. and I didn't see anything slowdown
jnthn github.com/ShimmerFairy/MoarVM/com...6f2eedR366 would look nicer if you didn't indent things to match the opening arg
(Which we don't do anywhere else in MoarVM because the result is, well, this. :))
Just one extra level of indent beyond what the loop body would have is enough 12:09
Or even better
Stick the thing in the condition in a static function
With a nice name
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.
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.)
(And if you don't trust it there's MVM_STATIC_INLINE to force it to happen)
Anyway, those small details aside the patch looks good to me. 12:11
(And I don't mind the PR getting merged and then a later clean-up PR coming if that's easier)
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 arVM: ce890e6 | paultcochrane++ | src/6model/reprs/MVMArray.c:
Fully initialise `spec` before setting and returning it

The structure `spec` was only partially set by the code in get_elem_storage_spec() and thus parts of it could be used uninitialised. 39abc80 | ShimmerFairy++ | src/math/bigintops.c: Add Unicode support to MVM_bigint_radix
This means taking any Nd character and any alphabet with letters that have a true Hex_Digit property. Nd characters are guaranteed to be in c852917 | (Jimmy Zhuo)++ | src/ (3 files): some small cleanup
12:13 dalek joined
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:13
er, the branch names weren't supposed to flip around in the <- one :) 12:14
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:16
jnthn There we go
12:17 dalek joined
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:17
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 :)
ShimmerFairy
.oO("Oh no, what if I end up sending a branch to the server?!" "You just sent a pointer. Congratulations.")
arVM: 63c89a0 | (Jimmy Zhuo)++ | src/ (2 files):
Merge branch 'master' of github.com/MoarVM/MoarVM
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
travis-ci MoarVM build failed. Jimmy Zhuo 'Merge pull request #213 from paultcochrane/pr/smoke-me/init-uninit-vars 12:23
travis-ci.org/MoarVM/MoarVM/builds/75723762 github.com/MoarVM/MoarVM/compare/d...4bfef078f9
12:23 travis-ci left
jnthn JimmyZ: Umm... ^^ looks unhappy 12:25
timotimo yeah, undeclared names inside unicode.c 12:31
12:33 travis-ci joined
travis-ci MoarVM build failed. Jonathan Worthington 'Merge pull request #233 from ShimmerFairy/uninum 12:33
travis-ci.org/MoarVM/MoarVM/builds/75724004 github.com/MoarVM/MoarVM/compare/e...1cafd9f737
12:33 travis-ci left
JimmyZ travis-ci is slow .... 12:33
timotimo :| 12:34
ShimmerFairy oh, it's a result of the ptc merge, not my commit, it seems (since my PR tested just fine before merging) 12:36
dalek arVM: 4ae29a6 | (Bob Kuo)++ | / (10 files):
Fix a few items found by warnings

   * Make some casts explicit
   * Fixup printf formats
dd5f168 | (Francois Perrad)++ | src/gc/collect.c: remove hard tab		 12:37
12:38 dalek joined
ShimmerFairy is it just me, or does dalek have a low tolerance for flooding in here? 12:38
12:46 travis-ci joined
travis-ci MoarVM build passed. Jimmy Zhuo 'Merge branch 'master' of github.com/MoarVM/MoarVM' 12:46
travis-ci.org/MoarVM/MoarVM/builds/75724188 github.com/MoarVM/MoarVM/compare/c...c89a002114
12:46 travis-ci left
arVM: 7691658 | (Francois Perrad)++ | src/ (4 files):
fix indentation

change MVM_unicode_name_to_property_value_code to MVM_unicode_cname_to_property_value_code
12:50 dalek joined 12:58 travis-ci joined
travis-ci MoarVM build passed. Jimmy Zhuo 'Merge branch 'fix_warnings' of github.com/bubaflub/MoarVM into bubaflub-fix_warnings 12:58
travis-ci.org/MoarVM/MoarVM/builds/75725110 github.com/MoarVM/MoarVM/compare/6...0e22d8419e
12:58 travis-ci left
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ā¤Ā»
timotimo JimmyZ: you want div instead of /, no? 13:13
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ā¤ā¤Ā»
timotimo oh, hold on
i thought you were using / for the abort condition
13:53 Peter_R joined 14:14 dalek joined 14:41 dalek joined 15:07 brrt joined 15:10 TEttinger joined 15:14 zakharyas joined
brrt let it be noted that 'shrink the tiler tables' is on the todo list 15:29
but not very high 15:31
:-) not like 'make the damn thing work, already'
timotimo i can imagine you're a bit annoyed by more and more requirements apparently stepping out into the light 15:52
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:01
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
brrt well, it's more like 'hey, you didn't think of that, now did you?' for me, timotimo
yes
i think that's a good way to put it
arnsholt Which is basically a transducer problem. Have you encountered them before? 16:03
brrt i have not
for what it's worth, my theorethical difficulties are mostly over, and i was planning to blag about it :-)
arnsholt Good to hear! The theory is usually the hardest bit, IME =) 16:04
Anyways, transducers are a bit niche, but the string-to-string case is a classical technique in my field (computational linguistics)
brrt yeah, without theory you can just get stuck, unfortunately 16:05
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?
arnsholt It's the formalisation of regex search-replace
Yeah, I think you can see translation as related
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:07
arVM/even-moar-jit: 74576ee | brrt++ | / (4 files):
Add preorder tile downpropagation step
 16:24
brrt dinner &
18:14 zakharyas joined 20:26 camelia joined 22:06 TEttinger joined 22:52 Peter_R joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!