jnthn Rest time for me also & 00:06
00:20 lizmat joined 01:37 cognominal joined 02:03 FROGGS_ joined 05:09 lue joined 07:25 FROGGS_ joined 08:32 odc joined
timotimo aaw. i don't really feel well rested 08:37
jnthn timotimo: Aww. :( Sorry to hear that.
timotimo at least most of my headache seems to be gon 08:40
gone
jnthn: should i remuse work on the jnthn_bigint_opt branch or do you still have something you're about to commit? 08:41
jnthn timotimo: I've nothing to commit 09:55
timotimo got a hint what i should tackle first? 09:56
i suppose i should try tackling the tests in the order they fail in
i'm guessing a fail would cause the whole test to abort?
jnthn Right
I'd just work through 60-bigint.t 09:57
That's what I did so far.
And once that is happy, see what Rakudo thinks.
timotimo hehe. 10:01
10:48 crab2313 joined
timotimo jnthn: i'm mildly sad that you decided to ditch the "little big int" name 10:53
because it has a very nice ring to it
hoelzro morning Moar folk 10:54
masak moarning, hoelzro
timotimo hob roelz!
jnthn timotimo: "You think it's cute today" :P 10:55
hoelzro heh 10:56
FROGGS_: for the openpipe stuff, what's left to do?
FROGGS_ hoelzro: a proper design for IO::Pipe 10:58
hoelzro ah ha
FROGGS_ but qx{} does already work on linux and windows
hoelzro thanks for stepping in and completing things
jnthn Also I guess when we have said proper design it needs doing over all backends too 11:02
timotimo that is probably going to be less hard once it actually exists 11:03
jnthn aye
It's probably coming towards the time when I will give IO its needed refactoring too
timotimo jnthn: should i be expecting fails in t/nqp/60-bigint.t? 11:04
ah, yes
i forgot to "make install" in moarvm
that's certainly clever :P
hoelzro jnthn, FROGGS_: that being the case, could it hurt to merge it into master? 11:06
jnthn timotimo: Yes, on the branch first 8 pass then it erupts
timotimo yup. 11:09
after confirming that a bigint is big, should i directly access its ->u.bigint? 11:10
jnthn Yes. 11:11
timotimo good 11:12
jnthn The answer will never change.
timotimo is hackety-hacking on div
jnthn In this model, everything is immutable.
Which is how it needs to be.
timotimo the division test passes 11:23
now for some bit shifting 11:24
FROGGS_ hoelzro: I'd like to get a review before merging it 11:26
hoelzro FROGGS_: alright
I just added a commit on my repo (github.com/hoelzro/MoarVM) for the wip-openpipe branch
and I filed a PR for nqp for an openpipe test for Moar 11:27
timotimo jnthn: what's your suggestion for implementing a "where is the most significant bit" operation?
or maybe i should ask the question that caused this question to arise:
i'd like to see for the left shift if the resulting number will still be in range or if it will overflow 11:28
ideally before doing the computation
jnthn timotimo: Oh... Well, if you're shifting left >= 31 bits, it obviously will 11:29
timotimo: Otherwise, do it in a 64-bit integer and then call store_int64_result to have it do the right thing.
timotimo oh!
that seems easy :) 11:30
jnthn Yeah, I think many of the cases you can now build out of the building blocks I added. :)
timotimo you're most helpful! :)
FROGGS_ hoelzro: there is no PR 11:31
hoelzro FROGGS_: github.com/perl6/nqp/pull/156
FROGGS_ nqp?
hoelzro yeah 11:32
I added a Moar test for NQP
FROGGS_ ahh
hoelzro I'll point you to the moar commit I made
timotimo 2 more passing tests with my shift implementation
FROGGS_ github.com/MoarVM/MoarVM/pull/75
timotimo shr will be a bit easier :)
hoelzro github.com/hoelzro/MoarVM/commit/a...10aeeefd7c
dalek arVM/wip-openpipe: a9c8032 | (Rob Hoelz)++ | src/io/fileops.c:
Don't freak out if we close a pipe twice

This may or may not be a good idea; I'm just following the standard set by the JVM implementation
arVM/wip-openpipe: 6483a7a | (Tobias Leich)++ | src/io/fileops.c:
Merge pull request #75 from hoelzro/wip-openpipe

Don't freak out if we close a pipe twice
hoelzro thanks 11:33
timotimo are moarvm commit bits also covered by the need for a perl cla?
FROGGS_ hoelzro: I won't apply the nqp PR yet, but after the wip-openpipe landed, alright?
jnthn No
hoelzro FROGGS_: sounds good 11:34
FROGGS_ timotimo: you need to send a beer to jnthn in order to get a commit bit :o)
timotimo heh heh :)
hoelzro FROGGS_: is that the secret? =P
does MoarVM have the same CLA policy that rakudo does?
FROGGS_ no, no CLA
jnthn No CLA, just as NQP 11:35
Moar commit bits are given out to people I'm comfortable giving them to :)
FROGGS_ *g*
puuh
good that I got mine :o)
jnthn hoelzro: Do you not have a Moar commit bit?
hoelzro jnthn: no 11:36
but I've just started looking at it
I intend to work on it tomorrow at the Perl hackathon in AMS
well, the focus is Perl 6
but if it involves Moar, that's cool with me =)
FROGGS_ Moar's focus is Perl 6, that is its slogan :o) 11:38
timotimo jnthn: what's the reasoning behind using malloc + mp_init for the result object in the BINARY_OP_SIMPLE?
FROGGS_ brb
timotimo rather than using force_bigint which can do the allocation for us, too? 11:39
or rather, the result object is likely to already be allocated for us from the interp.c code
jnthn timotimo: force_bigint is for use on *existing* values, not on the result one we're constructing. 11:41
timotimo: if it does have to force, it creates a temporary
timotimo: Which we clean up later
timotimo: But we don't want to clean it up if it's going to form the result in some cases.
timotimo oh
yeah, that does make sense 11:42
timotimo revises his code
jnthn Feel free to improve the comments I left on those functions.
hoelzro if I were to install a Perl 6 module into a MoarVM rakudo tree, what would it install? A .moarvm file? 11:49
hoelzro is trying to figure out the analogue to .pir
jnthn .moarvm 11:50
hoelzro alright 11:51
timotimo it seems like we have two implementations of bitwise negation
hoelzro and what if a rakudo install has multiple backends? Should a module installer (like ufo) install a .pir, .jar, and .moarvm file?
timotimo one based on the MVM_BIGINT_UNARY_OP macro, one plainly called MVM_bigint_not
but since the code of the latter is, in comparison, incredibly tight, i'm just going to remove the former 11:52
jnthn Do they do the same thing? 11:54
We hve a not_i and a bitnot_i iirc
timotimo oh, so the neg one is supposed to be -foo rather than ~foo? 11:55
that makes sense.
20 passing tests
jnthn oh...neg is negativ,e I think.
timotimo yes, it is 11:57
now pow_I
i think i'll just go with "force bigints for all parameters" for now 11:58
jnthn aye, if you use store_bigint_result it'll downgrade the result if it can.
timotimo i saw that :D 11:59
jnthn Cool. Seems you're successfully figuring out my I-was-tired code :) 12:00
nwc10 Why does Rakudo end up creating a lot of P6BigInts? (which I assume is the reason why all this work is a win) 12:01
timotimo every Int is a bigint 12:02
only int is non-bigint 12:03
but we end up using Int every time the user writes a number in the code and we can't say for sure that a native int would be fine as well
next up is expmod 12:05
jnthn Right. Perl 6's default integer type has big integer semantics by default 12:08
So the easy implementation was to just use mp_int for all of them.
timotimo up to 34 passing tests already
jnthn Now we're more at the phase of wanting to worry about performance over get stuff in...
timotimo i shall push, so that you can tell me if i've forked up somewhere :) 12:09
jnthn ...it's worth tackling this.
dalek arVM/jnthn_bigint_opt: 1baad4f | (Timo Paulssen)++ | src/math/bigintops.c:
teach bigint_div about smallint.
arVM/jnthn_bigint_opt: e128df2 | (Timo Paulssen)++ | src/math/bigintops.c:
implement smallint support for left-shift

remove some stray backslashes
timotimo there we go :)
sorry, dalek :( 12:10
12:10 dalek joined
timotimo jnthn: any specific random number generator i should be using for rand_I? 12:16
dalek arVM/jnthn_bigint_opt: d041af9 | (Timo Paulssen)++ | src/math/bigintops.c:
div_num can handle two smallint values now.

may be worth it to specialize for "only a is big" and
  "only b is big" later on?		 12:20
arVM/jnthn_bigint_opt: 9e74f8b | (Timo Paulssen)++ | src/math/bigintops.c:
bigint_rand without smallint support
timotimo er ... why do we pass an integer argument to the primality test? 12:21
is that for giving it more or less accuracy?
only gcd, lcm and bool_I left 12:25
dalek arVM/jnthn_bigint_opt: ced68ba | (Timo Paulssen)++ | src/math/bigintops.c:
bigint_is_prime should at one point work with smallint, too.

but for now, we just want to pass.
timotimo passes all bigint tests 12:27
dalek arVM/jnthn_bigint_opt: c62e15e | (Timo Paulssen)++ | src/math/bigintops.c:
gcd and lcm should really get proper smallint impls.

they are used very heavily every time we have Rat objects.		 12:28
timotimo tries to compile a rakudo
Incomplete smallint handling! 12:29
something not covered by the test cases!
radix_I apparently. huh.
well, that'll be easy enough. 12:30
tonum_I seems to be missing tests in bigint.t, too 12:33
dalek arVM/jnthn_bigint_opt: 541f51a | (Timo Paulssen)++ | src/math/bigintops.c:
teach radix about smallint/bigint bodies.
 12:35
timotimo we get to the optimizer now
arVM/jnthn_bigint_opt: dd9b245 | (Timo Paulssen)++ | src/math/bigintops.c:
implement a smallint path for bigint_to_num
timotimo rakudo compiled completely \o/ 12:42
dalek arVM/jnthn_bigint_opt: 08398c9 | (Timo Paulssen)++ | src/math/bigintops.c:
bigint_mod with smallint support
arVM/jnthn_bigint_opt: 2079191 | (Timo Paulssen)++ | src/math/bigintops.c:
bigint_is_big with smallint support
timotimo jnthn: how do you feel about serializing smallbigints as 32bit integers? 12:46
220 wallclock secs - pretty decent for 4 parallel test jobs 12:47
hm. the smallbigint run seems to have taken significantly longer (though i was listening to music during the smallbigint run, but not the master run) 12:53
and there are some more failing tests
jnthn timotimo: When we're done, we should have no calls left to get_bigint. 12:54
timotimo: +1 on the serializing thing. Store a flag saying what's coming, and then the thing
timotimo are we currently doing unnecessary extra work if we call one of the bigint_ ops from interp.c and pass an object to the result slot? 12:56
nwc10 does this mean that on the JVM, everything Rakudo creates is a JVM bigint, and a similar win would be possible?
timotimo 0.21user 0.01system 0:00.23elapsed 98%CPU (0avgtext+0avgdata 92892maxresident)k 12:57
that's master 12:58
0.21user 0.00system 0:00.22elapsed 98%CPU (0avgtext+0avgdata 92540maxresident)k
that's our smallbigint branch
i wonder if this difference is actually meaningful and caused by our smallbigints?
(that's for -e "say 1"
so not a very valuable benchmark by any stretch of the imagination)
jnthn Yeah. Doing a my @a = ^10000; is probably more informative. 13:00
timotimo heh. will try.
jnthn No, we need to allocate a result object, still. Int is still boxed. 13:01
But note I changed initialize to never allocate an mp_int any more.
timotimo does the creation cause an mp_init?
ah, perfect!
=time ./perl6-m -e 'my @a = (^50_000).list' 13:02
0.28user 0.03system 0:00.32elapsed 99%CPU (0avgtext+0avgdata 104196maxresident)k
=time ./perl6-m -e 'my @a = (^50_000).list'
0.31user 0.05system 0:00.36elapsed 99%CPU (0avgtext+0avgdata 122288maxresident)k
feel free to guess which one is which
jnthn I'm rather hoping the second one is with master :) 13:03
timotimo *ding* *ding* *ding*
you are correct!
one hundred million kilodollars!
\o/
timotimo throws confetti
jnthn That's a small performance win, but a big memory one.
timotimo 18 megabytes difference, that's pretty decent 13:04
jnthn Yes. Hope this will have some good consequences out in real world code.
timotimo me, too
with 200_000 numbers it goes to 201544maxresident -> 139164maxresident 13:06
and 0:00.78elapsed -> 0:00.60elapsed
the additional spectest failures are not as nice, though 13:07
maybe sprintf needs to learn about smallbigint, too, for example 13:09
jnthn Well, do you hvae anywhere that get_bigint is still called? 13:10
timotimo oh hold on
it's partially just re-ordering inside the results m) 13:11
-t/spec/S03-operators/arith.t (Wstat: 0 Tests: 145 Failed: 5)
- Failed tests: 6-7, 14-15, 145
+t/spec/S03-operators/arith.t (Wstat: 0 Tests: 145 Failed: 7)
+ Failed tests: 2-3, 6-7, 14-15, 145
Parse errors: Bad plan. You planned 144 tests but ran 145.
+t/spec/S03-operators/numeric-shift.t (Wstat: 0 Tests: 36 Failed: 12)
+ Failed tests: 4, 6, 10, 12, 16, 18, 22, 24, 28, 30, 34
+ 36
+t/spec/S03-operators/overflow.t (Wstat: 0 Tests: 98 Failed: 1)
+ Failed test: 46
er, the overflow is not legit
+t/spec/integration/lazy-bentley-generator.t (Wstat: 0 Tests: 1 Failed: 1) 13:12
+ Failed test: 1
this one is legit
jnthn Thie numeric-shitf onel ooks legit too
wow, great typing!
timotimo %) 13:13
not ok 22 - got expected value for shl -15 by -3 13:14
# got: '2305843009213693952'
# expected: '-2'
that seems pretty far off the value we wanted
jnthn yes :)
Probably some fail with handling shifting signs
timotimo github.com/MoarVM/MoarVM/blob/jnth...ops.c#L509 - you probably know more about C and shifting than me 13:15
oh 13:16
shift left by negative numbers
of course
i don't handle that properly at all
er ... i think i need a force_bigint there 13:18
and an mp_init 13:19
13:19 FROGGS joined
timotimo but that doesn't fix the test failures 13:20
dalek arVM/jnthn_bigint_opt: ad0b98e | (Timo Paulssen)++ | src/math/bigintops.c:
fix some mess-ups in bigint_shl
 13:21
jnthn The spectests to triage aside, this has gotten us quite a long way with the small big ints stuff... :) 13:22
timotimo yes, i'm glad you got me started with some high quality code
timotimo has an implementation for flagged (and backwards-compatible) bigint/smallint serialization/deserialization 13:31
jnthn yay 13:33
timotimo and i could build a rakudo with it 13:36
of course i neglected to measure the sizes of the serialized files
and i'm guessing there's hardly any P6bigint in the nqp bootstrap
jnthn No, there's none in NQP 13:38
timotimo probably not too many in the core setting .moarvm file?
9187399 ā† that's the size with smallerized serialization 13:39
jnthn Some, though.
I mean, the setting has its share of Int constants.
But in the grand scheme of things I suspect it's fairly few
Especially as it is smart enough to re-use constants.
timotimo i wonder if we should keep one level of serialization *writing* backwards compatibility? 13:41
so that we can easily switch back and forth between versions while developing 13:42
and not having to rebuild nqp and rakudo
jnthn timotimo: I generally prefer to
timotimo 9189363 ā† without smallerized bigints 13:45
so ... 2 kilobytes?
jnthn Yeah...
timotimo ah well. it'll kick in if we have an array constant of, say, the first 1000 prime numbers
jnthn Small win is small.
right.
dalek arVM/jnthn_bigint_opt: 7949341 | (Timo Paulssen)++ | src/6model/ (2 files):
serialize smallints smaller, put a flag in front
 13:46
timotimo i think you misread my point about writing backwards compatibility 13:48
i know we have multiple levels of reading backwards compatibility
but i see no way to tell the serializer to write the format of an older version
jnthn Oh 13:50
No, there's no way to do that.
And I don't think we need one.
Not at the moment, anyway.
timotimo fair enough.
sigh, i feel myself unmotivated to go fix the test fallout right now 13:53
i suppose it's time to take a nice walk in the only somewhat nice weather outside
jnthn Here the weather mings. 13:59
timotimo i don't know what that means :\
jnthn timotimo: "it's disgusting" 14:03
timotimo aaw
it's very windy outside, it seems
jnthn wind and rain here 14:04
timotimo i shall use the time i'm away from the computer to run some benchmarks 14:09
sadly, perl6-bench has no way for me to tell it to "build this rakudo with moarvm=master and this rakudo with moarvm=jnthn_bigint_opt" :(
japhb_, japhb__: ^ 14:10
14:34 jnap joined 14:49 ggoebel1115 joined 15:06 benabik joined
japhb__ *cough* Implementation welcome! *cough* 16:37
japhb__ is about 5 levels deep in Perl 6 yak shaving and is trying to avoid further distraction.
I will say that I'm *really* wanting A) working sockets everywhere, and B) a solid binding for a security library (e.g. openssl) 16:38
jnthn japhb__: They already work on JVM, afaik? It's Moar that's missing 'em? 16:39
japhb__ About the only way to do anything not strictly local here is to shell out to something else that has the proper capabilities, because you can't sneeze without encryption.
jnthn: Yeah, so all my work is JVM-specific right now, which makes for eye-rolling startup time. :-/ 16:40
jnthn japhb__: Well, there's Parrot :P 16:41
japhb__ ruminates for a bit on the concept of encrypted sneezes.
jnthn I suspect Moar will have sockets by the Feb compiler release, anyways.
But you still need the concurrent stuff I guess
japhb__ jnthn: Yeah, right now I use r-m for one-liners and no-network scripts, r-p for REPL, and r-j for net or concurrent scripts. 16:42
jnthn japhb__: Not r-m for REPL 'cus not proper readline yet?
japhb__ jnthn: Yup.
jnthn k
Need to figure out readline spewing...
japhb__ I tend to need readline to get into flow thinking.
jnthn It did work on Windows. 16:43
I wonder if you managed to link it against normal readline rathr than linenoise it works out.
japhb__ has access to MacOS and Linux right now.
(And doesn't know didly about MacOS builds -- I just use the Mac as a nice piece of hardware for SSH'ing to a Linux box) 16:44
japhb__ chuckles ... the person in front of me on the bus is reading a romance novel on her phone. In really big print. 16:46
timotimo: EMESSAGEDOESNTMATCHCOMMIT: irclog.perlgeek.de/moarvm/2014-02-07#i_8246872 16:47
Not that it's worth trying to fix that now .... 16:48
jnthn japhb__: I hope it's not 50 shades of grey... :P 16:49
japhb__ Whatever it is, the writing is AWFUL. I glance forward when I'm thinking and my brain captures half a sentence and wants to run away screaming. 16:52
timotimo japhb__: it *does* match the commit, but only indirectly 16:53
gcd and lcm are the only users of that particular macro 16:54
MVM_BIGINT_BINARY_OP(gcd)
MVM_BIGINT_BINARY_OP(lcm)
japhb__: do you have an idea how multi-versioned targets should be handled? like, just a few pointers?
japhb__ timotimo: Hmmm, lemme think 16:56
japhb__ checks something 16:57
timotimo maybe the compilers file should have a section "parameters": {"moarvm": "master", "nqp": "master"} or something
and if you specify the empty string, it won't pass a --gen-moar (for example) and the configure script will use NQP_REVISION and/or MOAR_REVISION 16:58
japhb__ Hmmm, that's not a bad idea 16:59
timotimo i'm not 100% sure if we can --gen-moar=foo --gen-nqp=bar from rakudo's own Configure.pl
if we could, that should work
it would then have a name like "rakudo-moar/master//7fpebcak" for example 17:00
or *maybe* it should fill out these slots by looking at the actual *_REVISIOON used
i think that makes more sense, but would have to be a bit magical; maybe there should be a list of "theis subdirectory is the checkout for this part, this other subdirectory is the checkout for that part" 17:02
and it would grab the names from those
japhb__ So we need to be able to pass things through to the build steps, and I don't want to special-case how configure works
dang, early boss stop, bbiab
timotimo heh.
i have an idea for that 17:04
japhb__ Corned beef hash FTW 17:08
timotimo japhb__: gist.github.com/timo/301073744c9555c79064
japhb__ Interesting, where are you getting those variable values? 17:09
japhb__ wonders if it isn't easier to have a 'configure_flags' key in compilers.pl (or passed through from the command line) 17:10
(command line of 'bench build' I mean) 17:11
Actually no, because compilers.pl is ... Perl 5. 17:12
.oO( use v5)
timotimo also because compilers.pl isn't responsible for building the components
japhb__ I'm not sure what this pancake flavor is, but it's not coconut. 17:13
timotimo i would think the variable values would be "positional" and it would split the part after the first / either at a , or at another / and get the values that way
so if you have parameters: <nqp mvm> and you ask perl6-bench to extract&build rakudo-moarvm/f00b42, you'd get a rakudo-moarvm with an nqp at f00b42 17:14
japhb__ component/rev:var1=val1,var2=val2?
timotimo nah, i don't like that
but / is also not such a good idea
it should map to subfolders of the component without more depth, IMO 17:15
but using something that can be part of a git branch/tag name would be problematic, too
japhb__ What punctuation can be used in a branch/tag name? I know . and /, what else?
timotimo - and _
you can use / in branch names!?
jnthn yes :)
japhb__ I don't even think of - and _ as punctuation these days, heh 17:16
timotimo :)
clearly we should use ā€¦
since the commits are usually abbreviated anyway
well, brackets might be an option 17:17
japhb__ Curlies? Already used for brace expansion. I tend to say things like rakudo/2014.{01,02}
Don't want visual confusion.
Why is : not useful?
timotimo git-check-ref-format is enlightening 17:18
not curlies
japhb__ Hah, Rule 4: I was right. ;-) 17:19
timotimo :)
japhb__ Square braces might work, though.
timotimo : would be acceptable, but i'd really rather not have the variable name in there along with the value
japhb__ If you really think : fails the visual distinctiveness test.
timotimo: What if you only want to override one?
timotimo use ::
japhb__ What if we start building a lot of flexibility into the build procedures, and most of the time, you want most of the defaults? 17:20
timotimo the default ought to be the empty string. using :: is the natural consequence, at least to me
i don't think we should have that many parameters
japhb__ Which reminds me, the defaults need to be stored in components.json.
japhb__ is thinking farther down the road, not just the immediate problem.
timotimo the defaults would always be the empty string; the build steps list would be in charge of figuring out the rest
japhb__ (If I'm going to play designer instead of coder, I have to.) 17:21
timotimo :)
also, if we think about things like versions mostly, the "default" would be specified by what's in our check-out
japhb__ I think empty string is a default default, not a default.
timotimo which is problematic, because we'd like to name our directory after the version and parameters
japhb__ Do you really want to code the ability to parse NQP_VERSION as part of components.json? 17:22
timotimo and if we only figure out what the NQP_REVISION was after we made our clone, we have to go out, mv, go back in
not parse NQP_REVISION
japhb__ Damn, I need to run for a meeting.
I'll backlog.
timotimo it'd be something like "defaults": {"nqp": [ "cat tools/build/NQP_REVISION" ] }
i'd love to see statistics about collective start-up time for each backend ... "the jvm wasted 40 minutes of this benchmark run just for starting up" 17:31
jnthn Beer time, at last &
japhb_ timotimo, Well, we do measure startup and compile times ... 19:17
.oO( Beer time? Why yes, I believe it is! )
 19:18
FROGGS k, I have P6 tuits now... but what to do? 19:40
nwc10 1) review your qx{} change?
2) get Panda working on MoarVM 19:41
3) profit!
or
0) give up for the evening and drink beer
FROGGS 1) I think somebody else should do it, because I won't see my thinkos
2) yeah, good point
0) no, I don't even have beer :o)
ohh 19:42
4) NDEBUG?
nwc10 I thought that jnthn had doen NDEBUG
FROGGS ahh, k
had no time to backlog :/
nwc10 just read the commits :-) 19:44
FROGGS yeah
dalek Heuristic branch merge: pushed 19 commits to MoarVM/wip-openpipe by FROGGS 19:46
19:49 jnap joined
timotimo FROGGS: there's LHF tests for bigint operations in t/nqp/60-bigint.t if you like something very easy 19:57
FROGGS timotimo: yeah, perhaps
timotimo and shift left/right misbehaves a lot in the same branch
(jnthn_bigint_opt)
FROGGS video.fosdem.org/2014/K3201/Saturday/ 20:03
timotimo oooh awesome! 20:09
thank you very much :)
FROGGS now I know what I will do when $kids are sleeping :o) 20:10
20:10 dalek joined
timotimo wowza 20:14
no post-processing on the sound of the video whatsoever :(
FROGGS :o( 20:15
timotimo at 2:50 minutes in, the buzzing starts to subside
here's the buzzing again ;_; 20:16
it seems like quite a bit more than half of the time the sound is okayd 20:20
i wonder why nqp-moarvm is a tiny bit slower than parrot at the while_array_set benchmark 20:47
microbenchmark*
it amuses me greatly, that moarvm is not only much faster than parrot at "loop_empty_native", but the jvm only catches up at the very, very end of the benchmark run 20:48
oh dang! 20:49
i didn't even build the code gen for locallifetime yet!
FROGGS :o) 20:51
timotimo FROGGS: if you want to, you can try it yourself ;)
FROGGS bah 20:52
:P
lee__ timotimo: are your benchmarks online somewhere?
lee__ is curious
FROGGS I don't think that this would work out when I am not even able to port the labels ops :o)
lee__: maybe this? feather.perl6.nl/~raiph/25jan2014-b...kudos.html 20:54
timotimo lee__: one second.
huh, where did i put my benchmarks the other times ... 20:55
ah
lee__ FROGGS' link looks interesting, and pretty recent 20:56
20:56 colomon joined
timotimo t.h8.lv/p6bench/2014-02-07-regular.html 20:56
lee__ awesome 20:58
thanks
timotimo yw
there is way more non-buzzed audio than buzzed audio in the talk 21:02
i'm happy about that
the buzzing has returned! :( 21:05
somebody invited the microphone over to a pillow fight or something 21:06
the pillows are furious 21:07
dalek arVM/wip-openpipe: 3cdc2a0 | (Tobias Leich)++ | src/io/procops.c:
initialize and set exit codes
 21:19
21:28 jnap joined
FROGGS that is pretty much the first thing panda does: 22:13
panda$ PERL6LIB=ext/File__Find/lib:ext/Shell__Command/lib:ext/JSON__Tiny/lib:lib perl6-m bin/panda install File::Find /home/froggs/dev/panda
Could not download module metadata: Could not find symbol '&INET'
so, we'd need that now
timotimo yeah ... not going to happen that soon :(
FROGGS hmmm, why? 22:15
timotimo we don't have any sockets and i don't think i feel up to it
FROGGS are we supposed to do that after IO refactor?
timotimo jnthn would have to say 22:21
i *think* it'd make sense, but what do i know :)
FROGGS on the other hand he would have patterns for things that somehow do their job... 22:22
we'll see :o)
timotimo hm, i guess 22:23
22:27 benabik joined 22:50 benabik joined
jnthn evening o/ 23:40
timotimo evening jnthn
i think i'm going to bed now, though
jnthn :) 23:42
jnthn had a long decommute
An IPA, a curry, a lambic and an imperial stout. Hard life. :)
ooh, a new perl6-bench set... :) 23:43
timotimo i got sidetracked into yak shaving after doing that set 23:46
i want to do a comparison against a rakudo-moar with the smallint changes
that'd either require a hack or parameterised builds for perl6-bench's components ...
(and it would also require the smallint operations to all work :P) 23:47
jnthn Also that :) 23:52
dalek arVM/jnthn_bigint_opt: 90256a9 | (Timo Paulssen)++ | src/math/bigintops.c:
negative right-shift could be trouble for smallint.
timotimo (this commit also doesn't fix it at all)
gnite o/
jnthn 'night 23:53

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!