samcv not sure how to include /usr/local/lib in the place the linker looks for the libs 00:05
in our configure files
ugexe github.com/MoarVM/MoarVM/blob/mast...up.pm#L462 ? 00:14
samcv ugexe, that doesn't specify a directory though 00:19
idk i need to include /usr/local/lib somehow which is where it puts libffi.so
ugexe yeah but you can add the name there 00:20
OS_MINGW32 has libdir => '@bindir@', for instance
samcv that just adds -l/usr/local/lib 00:24
which isn't a library it's a directory 00:25
ilmari[m] Yes, but after that -lffi will find /usr/local/lib/libffi.so 00:26
geekosaur don't you want -L there not -l ? 00:27
samcv yes i do geekosaur
that's my point
ugexe there is ldrpath, ldmiscflags, and others 00:31
ldrpath => '-L"/@libdir@"', 00:32
samcv hmm that may not be used in probe.pm 00:33
ugexe yeah probably not
samcv doesn't seem to be responding to CFLAGS env variable either 00:45
LDFLAGS seemed to work 00:46
though it can't find ffi.h
it's in /usr/local/include 00:47
CFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" makes it work 00:48
no clue how to fix it for good though 00:49
make test for rakudo now passes 00:50
MasterDuke would it make sense to use the FSA for a bunch of the string operations? 01:10
a lot of them have what look like short lived allocations 01:11
AlexDaniel samcv: thanks! 01:18
samcv: … what about github.com/perl6/nqp/issues/372 ? :)
samcv wait what did i do AlexDaniel ?
AlexDaniel resolved github.com/MoarVM/MoarVM/issues/693 :) 01:19
samcv ah the appveyor
maybe will try that tomorrow
AlexDaniel samcv: thanks 01:28
samcv will need to be nqp admin to do it though 01:32
01:32 travis-ci joined
travis-ci MoarVM build failed. Jonathan Worthington 'Stash native thread ID after GC unblock 01:32
travis-ci.org/MoarVM/MoarVM/builds/276930928 github.com/MoarVM/MoarVM/compare/e...fedf518854
01:32 travis-ci left
Zoffix samcv: I added you as admin to github.com/perl6/nqp , if that's what you meant 01:35
samcv woot 01:36
yeah i will add it then
01:36 zakharyas joined
Zoffix \o/ 01:38
01:55 ilbot3 joined 04:29 travis-ci joined
travis-ci MoarVM build failed. Jonathan Worthington 'Make native callback thread finding more robust 04:29
travis-ci.org/MoarVM/MoarVM/builds/276934185 github.com/MoarVM/MoarVM/compare/1...59f2ff2ebf
04:29 travis-ci left 04:37 Ven`` joined
Geth MoarVM: 3dea7dff4b | (Samantha McVey)++ | .appveyor.yml
Turn build section of Appveyor build off

Hopefully avoid "Specify which project or solution file to use because the folder contains more than one project or solution file." error.		 04:55
samcv is it just me or have travis builds been slowing down 05:05
like a constant slowing down over since i started working on perl6 a year ago
timotimo i just realized that resuming continuations in other threads will be interesting from the instrumented profiler's perspective 05:53
since it has one full call graph per thread
though conceptually the thread pool that shuffles tasks around between many threads can easily make the distinction between individual threads useless
i'll probably have to come up with a good middle-ground between just merging call graphs from every thread into one big blob of data and having them all separate from each other 05:54
06:08 committable6 joined
samcv interesting 06:14
06:38 travis-ci joined
travis-ci MoarVM build passed. Jonathan Worthington 'Factor out callback thread finding 06:38
travis-ci.org/MoarVM/MoarVM/builds/276940092 github.com/MoarVM/MoarVM/compare/1...b664ea65e9
06:38 travis-ci left 06:40 domidumont joined 06:45 leont joined
timotimo gist.github.com/timo/080a2e733ad4f...6a5ad051a1 - the "summary all" output btw 07:11
07:16 brrt joined 07:19 ilmari[m] joined 07:25 Ven`` joined
nine For those who are disappointed by the mere 7 % speedup of csv-ip5xs.pl by JITing native calls, I did a micro benchmark of AssortedIntArgs from t/04-nativecall/02-simple-args.t 07:29
For this call I see a 2.5x speedup by JIT compiling :)
samcv :) 07:37
nine Speedup scales with number of arguments. A single argument gives ~ 2.2x speedup. So it's a pity that p5_call_method with its 9 arguments is not yet JITed. But also means there's lots to be gained still :) 07:42
07:44 AelxDnaiel joined
brrt good hi! 07:55
ohai nine
very cool work!
08:18 krunen joined 08:22 krunen joined 08:23 krunen joined 08:26 robertle joined 08:33 domidumont joined 08:48 zakharyas joined
jnthn morning o/ 09:00
nwc10 correct! 09:05
nine jnthn: have you seen the numbers I posted earlier? May be worth having a look at IO::Socket::Async::SSL perf after all :)
09:10 travis-ci joined
travis-ci MoarVM build passed. Samantha McVey 'Try and enable and build matrix with Appveyor' 09:10
travis-ci.org/MoarVM/MoarVM/builds/277066715 github.com/MoarVM/MoarVM/compare/e...d6af05db7a
09:10 travis-ci left
jnthn nine: Yeah, that passes a number of args, so :) 09:11
Will be interesting to try it out :)
samcv wow travis is slowww 09:12
jnthn nine: Is it ready for review?
nine jnthn: think so. I do wonder if I should try to squash the commits. There's a lot of back and forth now in that branch. 09:39
jnthn: I'm also a bit unsure about the ops. nativecallinvokejit may want to be renamed to ncinvoke to be closer to the ncinvoke_* variants. Of the latter currently only the ncinvoke_o is really used. The rest may become useful for pushing boxing of results into the HLL code. 09:43
09:48 zakharyas joined
jnthn What happens if we don't have the JI 09:56
T available? 09:57
I'm guessing the ops fall back to non-JIT?
nativeinvoke_o etc may be nice
The c is for call, and having call and invoke in the name is a bit funny :) 09:58
nine If the JIT is disabled, we fall back to good old nativecallinvoke. Same as if we don't support a particular argument type. 10:00
jnthn Alright
10:15 benchable6 joined, unicodable6 joined 10:48 krunen joined 10:55 krunen joined 11:38 timo1 joined 11:53 travis-ci joined
travis-ci MoarVM build passed. Samantha McVey 'Trigger Appveyor build' 11:53
travis-ci.org/MoarVM/MoarVM/builds/277068958 github.com/MoarVM/MoarVM/compare/4...24dcf8fc01
11:53 travis-ci left
Geth MoarVM: 86407034d0 | (Timo Paulssen)++ (committed by Jonathan Worthington) | 3 files
Protect parameterization additions with a mutex

Partially addresses #554		 13:17
nwc10 jnthn++ # bloggage 13:21
(I'm behind, it seems)
jnthn I'm even more behind with bloggage... 13:22
brrt aren't we all :-P 13:26
timotimo i don't have my own blog 13:30
well, i do have, like, a blog, or something
on my website .. which i haven't touched since 2012
Zoffix write on blogs.perl.org :)
timotimo not sure i like the place much
Zoffix write on rakudo.party :) 13:32
timotimo hmm, not sure how to make content that fits well with that page 13:33
less page, more 'site i guess
Geth MoarVM: 3a2990d5e8 | (Jonathan Worthington)++ | src/6model/parametric.c
Complete fix for for parametric type races

Make sure we really do intern the parameterizations, and do a defensive copy so readers are safe. Should fully fix the issues in issue #554.		 13:42
jnthn Apparently there was a race in my typing of that commit message.. 13:46
dogbert17 sometimes test 11 t/spec/S17-supply/supplier-preserving.t fails with the following message: 14:37
# Failed test 'Close called as expected' # at t/spec/S17-supply/supplier-preserving.t line 32 # expected: 'xxxxxxxxxx' (len 10) # got: 'xxxxxxxxx' (len 9)
is this a known failure ?
jnthn Yeah, though I didn't figure out what's going on yet 14:39
dogbert17 it seems to appear more often on a loaded system if that's any clue 14:40
jnthn Pretty much all concurrencly-involving bugs do, alas 14:43
*concurrency
dogbert17 tried to trip both ASAN and valgrind, but alas, no success 14:45
found a very old RT #123461 which might be relevant 14:48
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=123461
jnthn btw, the occasinal connection refused error you mentioned a bit ago in a new test in await-nonblocking.t is fixed in one of my Rakudo branches 14:49
14:49 committable6 joined
dogbert17 jnthn++ 14:49
14:50 releasable6 joined, bloatable6 joined, quotable6 joined, squashable6 joined 14:51 statisfiable6 joined
dogbert17 the send method has changed a bit since Moritz reported that race condition, so perhaps the issue is no longer relevant, github.com/rakudo/rakudo/blob/nom/...nel.pm#L42 14:51
jnthn May still apply, but don't think it's the issue here 14:54
Looking at another issue at the moemnt, so will look at that more later
15:05 timo joined 15:06 geekosaur joined 15:07 brrt joined
ugexe i wonder if libuv update got windows any additional spectest passes. the changelog has a fair bit of windows stuff 15:14
er wrong buffer :)
brrt timotimo: could we use the telemetry logger for getting bytecode sizes? 15:27
15:41 geekosaur joined
timotimo sure thing 15:48
Geth MoarVM/use_attribute_st_in_bind_attribute: 3b4b032984 | (Timo Paulssen)++ | src/6model/reprs/P6opaque.c
use attribute/value st for copy_to, not outer obj st

this caused a segfault when trying to bind a p6bigint to a matching attribute in a p6opaque.		 15:56
timotimo brrt, i don't think i have an api for "just put a bit of data into the datastream", so you'll probably have to start and end an interval around the jitting process and attach the information with the interval_id 15:57
16:03 geekosaur joined
timotimo oh, i got distracted. nw i'm running the spec test. 16:30
Zoffix :) 16:32
timotimo had a few failures, but those were probably from too-old rakudo 16:38
only supplier-preserving fails 16:54
so if someone wants, they can merge this 16:55
Zoffix Can you merge it? :) 16:56
I'll do the bumps and write the tests.
timotimo sure 16:57
Geth MoarVM: 3b4b032984 | (Timo Paulssen)++ | src/6model/reprs/P6opaque.c
use attribute/value st for copy_to, not outer obj st

this caused a segfault when trying to bind a p6bigint to a matching attribute in a p6opaque.
Zoffix timotimo++
timotimo that was a good catch, Zoffix 17:00
17:34 Ven`` joined 17:39 domidumont joined
Geth MoarVM: usev6++ created pull request #695:
Fix FreeBSD build		 18:18
ilmari discovers the .paramet.{ric,erized} union. cute 18:46
Geth MoarVM: 5bdb778446 | (Christian Bartolomäus)++ (committed using GitHub Web editor) | build/Makefile.in
Fix FreeBSD build
 18:52
MoarVM: 3a2eab52f7 | (Jimmy Zhuo)++ (committed using GitHub Web editor) | build/Makefile.in
Merge pull request #695 from usev6/patch-1

Fix FreeBSD build
MoarVM/jit_nativecall: 16 commits pushed by (Stefan Seifert)++
review: github.com/MoarVM/MoarVM/compare/0...91ad7464d3		 18:55
nine jnthn: ops are renamed. Open question is whether we want the twisted commit history or if I should just squash them into 2 commits. Excluding generated code the diff is just: 16 files changed, 329 insertions(+), 25 deletions(-) 18:56
jnthn nine: I guess the 2 squished would be easier to review; otherwise I'll just review the whole diff at once between master and it :) 19:09
nine jnthn: ok, I'll squash. The 2 commits will be implementation of the nativeinvoke_o op and then JITing that call, too. 19:15
jnthn Sounds good :)
19:28 brrt joined
brrt how would that work? 19:28
Geth MoarVM/jit_nativecall: 2d21965361 | (Stefan Seifert)++ | 19 files
Compile code for calling native functions.

MVM_nativecall_build builds a JIT graph manually and compiles it. The result is attached to the MVMNativeCallBody. For now the new nativeinvoke_* ops (mirroring invoke_*) will enter that code. Ideally we will replace the whole frame containing the nativeinvoke by JIT compiled code.
... (14 more lines)		 19:41
MoarVM/jit_nativecall: ecdba29f9f | (Stefan Seifert)++ | 5 files
JIT compile JITed native calls

While we already generated machine code for performing the actual call to the C function, we perform all deconting and unboxing of arguments in high level code. This is so that spesh can optimize this code to what's actually necessary for a given call site.
... (14 more lines)
samcv jnthn, so i'm ready to start working on my final grant report. any tips
like what do i need to put in it. just overview of everything i did? or what
Geth MoarVM/jit_nativecall: af5bcee85f | (Stefan Seifert)++ | 19 files
Compile code for calling native functions.

MVM_nativecall_build builds a JIT graph manually and compiles it. The result is attached to the MVMNativeCallBody. For now the new nativeinvoke_* ops (mirroring invoke_*) will enter that code. Ideally we will replace the whole frame containing the nativeinvoke by JIT compiled code.
... (14 more lines)
MoarVM/jit_nativecall: 1edff49ad8 | (Stefan Seifert)++ | 5 files
JIT compile JITed native calls

While we already generated machine code for performing the actual call to the C function, we perform all deconting and unboxing of arguments in high level code. This is so that spesh can optimize this code to what's actually necessary for a given call site.
... (14 more lines)
nine Sorry for the noise. Just rebased again on the current master
samcv no problem nine 19:45
brrt can i still say i think this work is really cool
nine++
samcv our most important platforms are MacOS, Linux, FreeBSD, and what is most important after that
nine thanks brrt :) 19:46
samcv though alpine probably needs to be considered separate. maybe we can have a build in our matrix do musl builds?
looks like there's a musl-gcc wrapper and maybe we can use that to be able to test musl 19:47
Geth MoarVM: patzim++ created pull request #696:
Probe for gcc -Werror=* support		 19:55
jnthn samcv: I don't tend to make them utterly exhaustive, because then it'd be a terribly boring read. I'd reference all the blog posts you did, which people can look to for details, and then focus the report on the improvements that resulted from the grant. 20:02
brrt samcv: windows?
samcv ok cool
yeah windows
sorry i meant to say that. what about after that 20:03
openbsd?
brrt ehm, are there any other platforms left :-P
jnthn samcv: If it makes sense, making it easy to cross-reference the final report back to the grant application so it's easy to see that the things in the application were completed is also nice :)
brrt not solaris anyway
samcv did we used to support that?
would be nice to have various vm's and test before each release 20:04
maybe a week or so before we release
timotimo still no haiku support in libuv, right? :| 20:05
jnthn IMO, the 3 most important platforms are Linux, OSX, and Windows, because by that point we've covered close to 99% of what people will use. The major BSDs come after that. Beyond that I think more important is not OS, but having testing on some big endian platform. 20:06
samcv what is big endian? 20:08
arm?
jnthn I think arm can be, depending on configuration 20:09
PPC is 20:10
bbiab, gotta do my homework :
:)
timotimo hm, i'll probably have to do something about endianness in the heap profiler output 20:16
currently i just fwrite the things, that's clearly not safe
lizmat timotimo: why? as long as the endianness is available as meta information? 20:24
timotimo then i'll have to change the heap analyzer, yeah
and it'd be helpful to write a piece of data that makes the endianness obvious 20:25
also, i'll never support middle endian :
:P
geekosaur we need to ship timotimo a pdp11? :p 20:26
timotimo there is no space in my home 20:27
moritz %*ENV<HOME> ~~ s/^^/ /; # how to create space in your home :-) 20:29
MasterDuke jnthn: thanks for merging the fsa realloc PR. have you looked at the next one? 20:48
speaking of the fsa... 20:54
jnthn, timotimo, etc: would it make sense to use the FSA for a bunch of the string operations? 20:55
timotimo not sure, could be. we definitely keep the size around anyway
MasterDuke what about for short-lived allocations within a function? 20:57
timotimo within a function, eh? 20:58
can we somehow figure out that it can fit onto the stack instead?
at least the memory blob for the string's contents. not the object itself, because the GC has to manage that 20:59
hm. that seems like a terrible idea, come to think of it.
MasterDuke don't think so for the few functions i looked at. i think join has one or two 21:00
timotimo it could be a good idea to try the FSA here and see what performance characteristics it offers
MasterDuke what's a good way to measure? 21:04
timotimo good question
the whole spec test suite is one way, but i expect it to be at least a bit noisy 21:05
MasterDuke you mean time to run the spectest? 21:06
timotimo yeah 21:07
probably a bad idea, right?
MasterDuke well, i bet it'll be hard to see anything less than 10% 21:11
timotimo yeah :( 21:14
timotimo has a little piece of fannkuch benchmark 21:35
hm, i might be able to get this into benchable 21:36
my (@l,@r); sub ri(@a,@b){@b.unshift(@a.shift) while @a.elems}; for (1..8).permutations { @l=@$_; repeat { @r=@l.splice(0,@l[0]); ri(@r, @l) } while @l[0] != 1 } 21:37
m: my (@l,@r); sub ri(@a,@b){@b.unshift(@a.shift) while @a.elems}; for (1..8).permutations { @l=@$_; repeat { @r=@l.splice(0,@l[0]); ri(@r, @l) } while @l[0] != 1 }
camelia ( no output ) 21:38
timotimo bench: releases my (@l,@r); sub ri(@a,@b){@b.unshift(@a.shift) while @a.elems}; for (1..8).permutations { @l=@$_; repeat { @r=@l.splice(0,@l[0]); ri(@r, @l) } while @l[0] != 1 }
benchable6 timotimo, starting to benchmark the 23 given commits
timotimo, «hit the total time limit of 240 seconds» 21:42
MasterDuke timotimo: maybe try AlexDaniel's trick of just giving it 2015.12,HEAD 21:43
timotimo right 21:45
bench: 2015.12,HEAD my (@l,@r); sub ri(@a,@b){@b.unshift(@a.shift) while @a.elems}; for (1..8).permutations { @l=@$_; repeat { @r=@l.splice(0,@l[0]); ri(@r, @l) } while @l[0] != 1 }
benchable6 timotimo, starting to benchmark the 2 given commits
timotimo, benchmarked the given commits, now zooming in on performance differences 21:46
timotimo, ¦2015.12: «10.0083» ¦HEAD: «3.0507»
timotimo neat. 21:47
that's quite a bit faster
i'd like a bit more detail, though 21:50
how come it didn't give me any zoom points?
bench: 2015.12,2016.12,2017.05,HEAD my (@l,@r); sub ri(@a,@b){@b.unshift(@a.shift) while @a.elems}; for (1..8).permutations { @l=@$_; repeat { @r=@l.splice(0,@l[0]); ri(@r, @l) } while @l[0] != 1 }
benchable6 timotimo, starting to benchmark the 4 given commits
timotimo, benchmarked the given commits, now zooming in on performance differences 21:52
timotimo, gist.github.com/5e00c0007f59595fe1...5572bfb23c 21:54
timotimo LOL
that graph is precious 21:55
geekosaur heh
samcv think i've almost fixed the problem of synthetics changing under concatenation. utf8-c8 synths that is 22:17
\o/ i got it 22:19
jnthn \o/ 22:20
samcv++
samcv so i added an option to the iterator which iterates a single grapheme, and had an option to pass back utf8 c8 synthetics 22:21
also going to have re_nfg do the same thing as well. even though that wasn't causing this specific problem. i could see it occuring there too 22:22
the normalizer seems to leave them alone. though ideally maybe we'd have a fast path for utf8c8 synths? dunno 22:24
jnthn Sounds wise
samcv though it working is much more important atm
nobody wants their utf8c8 strings to become normal ones
and i'll leave MVM_string_compare the way it is. otherwise i guess utfc8 synths would sort in the allocated order rather than a consistent order 22:25
jnthn, and we want .codes to give 1 code per utfc8 synth or no? 22:27
jnthn I don't care much about that. 22:29
If it does that's nice I guess
samcv i just need to change a 0 to a 1 22:30
and it will do that
jnthn oh
Then OK ;)
samcv ok :)
jnthn, need to decide how i want utf8c8 synths to sort in the collation algorithm hm 22:36
maybe something based on their number. and sort it as Unassigned
something to think about
jnthn Indeed; don't have anything useful to suggest really... 23:10
Sleep time o/
japhb Sleep well, jnthn
23:50 AlexDaniel 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!