Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-02-24

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

All times shown according to UTC.

Time Nick Message
00:09 pyrimidine joined #moarvm
01:04 geekosaur joined #moarvm
01:25 pyrimidine joined #moarvm
02:05 pyrimidine joined #moarvm
02:07 stmuk joined #moarvm
02:25 stmuk joined #moarvm
02:48 ilbot3 joined #moarvm
02:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:14 pyrimidine joined #moarvm
03:24 IOninja .tell dogbert17 I'm told you like hunting SEGVs: https://irclog.perlgeek.de/perl6/2017-02-24#i_14155509
03:24 yoleaux2 IOninja: I'll pass your message to dogbert17.
03:37 MasterDuke_ joined #moarvm
06:16 pyrimidine joined #moarvm
06:25 ggoebel joined #moarvm
07:52 stmuk joined #moarvm
07:55 nwc10 good *, #moarvm
08:13 pyrimidine joined #moarvm
08:56 zakharyas joined #moarvm
09:14 pyrimidine joined #moarvm
09:17 samcv good * :)
10:02 jnthn morning o/
10:02 yoleaux2 23 Feb 2017 21:08Z <IOninja> jnthn: Num.Rat coerser takes optional epsilon, Int.Rat and Rat.Rat take an optional arg they ignore, and Complex.Rat and Str.Rat don't take any args. Does it make more sense to make all .Rats take an optional arg and ignore it in cases or just have it for types that can make use of it? I'm leaning towards the latter, and removing dummy params
10:16 pyrimidine joined #moarvm
10:18 dogbert11 silent around here
10:21 jnthn My brain cycles are tied up with a fun but somewhat tricky yak shave at work... :)
10:25 dogbert11 oh no :) if you get tired of it I have a juicy IOninja SEGV that might be interesting
10:35 dogbert11 the SEGV gist is here: https://gist.github.com/dogbert17/9aadb12cb065a0e5761f1ddab001eb1b
11:09 dogbert11 updated the gist, it now contains gdb, valgrind and ASAN output
11:13 timotimo dogbert11: do you still have a gdb running where that happened?
11:23 jnthn Oh noes, seems that we don't support function pointers in CStructs yet?
11:24 arnsholt Hmm
11:24 jnthn I need to pass a struct of callbacks, fwiw.
11:24 arnsholt I guess we might only support passing them to functions?
11:24 jnthn Yeah, that's what it looks like
11:25 jnthn We also support casting returned function pointers into Perl 6 callables
11:26 jnthn It's funny, if C had an identity function I could easily call then I could just pass my code, and get back a pointer that I can stick into the struct :P
11:27 jnthn I can't think of anything in standard library that I can abuse as an identity function though :P
11:29 timotimo yeah
11:29 timotimo pretty annoying
11:29 timotimo can totally put one into moarvm :)
11:29 timotimo that'll make sure it's available "everywhere"
11:29 timotimo (except on jvm)
11:32 arnsholt Or we could, y'know, fix NativeCall =p
11:33 jnthn Or that :)
11:33 arnsholt I've been wanting to draft a revised NativeCall API, incidentally
11:33 jnthn *nod*
11:33 jnthn Something we can better JIT would be good :)
11:33 arnsholt And something more coherent
11:33 jnthn Aye
11:33 arnsholt It's sprouted a few too many hacks, IMO
11:35 jnthn That also
11:36 * jnthn wonders what the most expedient thing he can do Right Now is
11:36 jnthn (I can always switch to a better thing later)
11:37 arnsholt Horrrible, horrible hack, but you could make the struct of OpaquePointer, and get pointers to the functions with dlsym and dlopen(NULL)?
11:37 arnsholt Except you're wanting to populate it with callbacks to *Perl 6* functions >.<
11:38 arnsholt What about memcpy?
11:38 jnthn Right
11:38 jnthn I pondered that but...memcpy expects to receive a pointer
11:39 jnthn A really horrid back is printf("%P", ...) :P
11:39 jnthn *hack
11:39 arnsholt Right, so you'd have to pass a CArray[OpaquePointer]
11:40 jnthn Yeah, but what I'd be trying to pass is a Perl 6 function
11:40 jnthn Which I want to get the callbackized pointer to
11:41 jnthn The only place we support callback *generation* today is when we pass them as an argument
11:41 arnsholt Won't "my CArray[OpaquePointer] $arr; $arr[0] = OpaquePointer; memcpy($arr, &cb, 8); $arr[0]" work?
11:42 arnsholt Oh, not
11:42 arnsholt You're right, yeah
11:42 arnsholt Bah!
11:42 arnsholt This was really annoying!
11:44 arnsholt jnthn: signal(2)
11:44 arnsholt }:)
11:45 arnsholt It'll return the previous signal handler, so set the signal handler to be your callback, then set it back to the original value and save the final return value in your struct
11:46 jnthn ouch :)
11:46 jnthn But yeah, nice one :)
11:46 dogbert11 timotimo: yes
11:49 dogbert11 what would you like me to do?
11:49 timotimo can we get a bt full?
11:50 dogbert11 coming up
11:50 timotimo dont know how to print all locals in a frame youre in
11:51 dogbert11 gist updated, refresh
12:00 jnthn Hm, there may be an alterantive API that lets me side-step the whole thing
12:12 timotimo how in the heck does desc become 0x1
12:12 timotimo wrong kind of object perhaps?
12:13 timotimo but it has to match the rakudo container spec
12:13 timotimo can you print the STABLE(check)?
12:13 timotimo well, may have to STABLE(check)[0]
12:17 timotimo i'm grabbing the code myself now,too
12:17 pyrimidine joined #moarvm
12:20 timotimo HTML-Entity is failing its tests, did you see that, too?
12:23 timotimo huh. it installed HTTP::Tinyish, then it tries to install & test HTTP::Server::Tiny and it fails to find HTTP::Tinyish?
12:32 timotimo i wonder what causes the descriptor to become damaged like that
12:37 dogbert11 timotimo had sneaked off for lunch :)
12:38 dogbert11 in order to run mapper.pl you only need JSON::Tiny
12:39 dogbert11 (gdb) p STABLE(check)[0]
12:39 dogbert11 $2 = {header = {sc_forward_u = {forwarder = 0x15a0017, sc = {sc_idx = 23, idx = 346}, sci = 0x15a0017, st = 0x15a0017}, owner = 1, flags = 18, size = 120}, REPR = 0xb68a4440 <this_repr>,
12:39 dogbert11 REPR_data = 0xb5220c00, size = 32, type_check_cache_length = 3, mode_flags = 4, type_check_cache = 0xabb9c0d0, method_cache = 0xa82dac60, type_cache_id = 127232,
12:39 dogbert11 container_spec = 0xb4f1bea0 <rakudo_scalar_spec>, container_data = 0x0, boolification_spec = 0xabb9c0b0, hll_owner = 0xb1405b40, hll_role = 0, invoke = 0xb61033a0 <MVM_6model_invoke_default>,
12:39 dogbert11 invocation_spec = 0xb462b010, WHAT = 0xb3e3edd0, WHO = 0xaaa193c0, HOW = 0xabd2d6a0, paramet = {ric = {parameterizer = 0x0, lookup = 0x0}, erized = {parametric_type = 0x0, parameters = 0x0}},
12:39 dogbert11 HOW_sc = 0xa5654220, HOW_idx = 12624, method_cache_offset = 141235, method_cache_sc = 0x0, debug_name = 0xabb9c070 "Scalar", being_repossessed = 0 '\000'}
12:39 * dogbert11 oops that was a bit on the spammy side
12:58 timotimo i got it into gdb locally, too
13:00 dogbert11 cool, any ideas?
13:00 timotimo i'm not sure where exactly it is in the bytecode
13:00 timotimo doesn't help that our backtraces seem to be pretty bad near the top all the damn time :)
13:12 timotimo it'd be nice if the code was golfed a bit more ...
13:19 pyrimidine joined #moarvm
13:23 arnsholt Awww. MoarVM doesn't work in Linux-on-Windows because of executable stack
13:24 jnthn There's an issue about that; apparently we get it from dyncall, which doese it by accident, so it was being fixed there
13:27 dogbert11 timotimo: we could ask the ninja :)
13:28 IOninja ?
13:28 IOninja ask what... and which ninja
13:29 IOninja I'm surprised HTTP::Tinyish is used anywhere in that codebase :S
13:30 IOninja oh, same author, now less surpised.
13:31 IOninja You don't need it for the script with the SEGV in it tho
13:31 IOninja Only JSON::Tiny
13:32 IOninja And HEAD doesn't segv (I needed to work around it), it's on that commit only...
13:32 IOninja Umm, I think I forgot to commit all the latest changes tho (not important)
13:33 IOninja zef install JSON::Tiny; cd $(mktemp -d); git clone https://github.com/perl6/routine-map .; git checkout ee7fb894bc47f8eed; perl6 mapper.p6
13:33 dogbert11 IOninja: we're trying to golf it a bit
13:34 IOninja And if you change `eager` to `@ =` on this line, the segv goes away: https://github.com/perl6/routine-map/blob/ee7fb894bc47f8eed877f2f9dccc15e2644caf6e/mapper.p6#L53
13:34 dogbert11 and we thought you might be able to help :)
13:34 IOninja OK. Yeah, lemme golf it down
13:40 IOninja m: CORE::.keys.grep(* ne 'IterationEnd').map({CORE::{$_}}).grep({ !.DEFINITE and try .can('say') }).unique.grep({42})
13:40 camelia rakudo-moar d41b68: OUTPUT: «(signal SEGV)»
13:41 IOninja ^ that's what I got so far
13:41 IOninja s: CORE::.keys.grep(* ne "IterationEnd").map({CORE::{$_}}).grep({ !.DEFINITE and try .can("say") }), 'unique', \()
13:42 IOninja ... wonder if it's me lagging or the bots :/
13:42 IOninja oh, no SourceBaby here
13:44 IOninja my spidey senses tell me this is something to do with trying to .unique an Iterable that has all sorts of weird crap in it
13:47 IOninja And my spidey senses pay off:
13:47 IOninja m: (Scalar).unique
13:47 camelia rakudo-moar d41b68: OUTPUT: «(signal SEGV)»
13:48 IOninja dogbert11: how's that for golf :P
13:52 dogbert11 IOninja: I guess it's called hole in one :)
13:57 dogbert11 can we use some cool bot to see if this problem was introduced recently
13:57 dogbert11 bisect: (Scalar).unique
13:58 dogbert11 meh
13:59 IOninja dogbert11: some time in 2015.09: https://gist.github.com/Whateverable/769828254057438050cb84a953f9041b
14:00 dogbert11 an oldie
14:00 IOninja I'm golfin' it more
14:00 dogbert11 is that even possible
14:01 IOninja Sure, unique is just code
14:01 IOninja m: return Scalar
14:01 camelia rakudo-moar d41b68: OUTPUT: «(signal SEGV)»
14:09 IOninja Still golfin'!
14:09 IOninja m: use nqp; nqp::p6recont_ro(Scalar)
14:09 camelia rakudo-moar d41b68: OUTPUT: «(signal SEGV)»
14:11 IOninja well, that's as far as I can take it. The rest is all C code and I don't know C.
14:13 dogbert11 IOninja: I think that will do nicely
14:20 * dogbert11 don't understand what's going on either, will have to learn from the pros
14:21 IOninja first appeared in 2014.05 release
14:21 IOninja no segv in 2014.04, but I dunno if that's 'cause this op didn't exist then maybe
14:33 Geth ¦ MoarVM: niner++ created pull request #541: Yet another attempt at silencing the pthread_yield warnings
14:33 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/541
14:36 IOninja #0  0x00007ffff5d67701 in p6recont_ro () from ./dynext/libperl6_ops_moar.so
14:36 IOninja No symbol table info available.
14:36 IOninja how do I get the symbol table info agvailable?
14:40 dogbert11 are you running gdb?
14:41 IOninja I guess. ./perl6-gdb-m
14:42 dogbert11 if so, in nqp/MoarVM do this 'perl Configure.pl --debug  --prefix=/home/dogbert/repos/rakudo/install/' followed by 'make install'. Note, change the prefix accordingly
14:42 dogbert11 I doubt that your install dir is the same as mine :)
14:42 IOninja Yeah, I did, but this stuff's not in MoarVM this is C code in rakudo
14:44 dogbert11 hmm, that's what I do
14:44 dogbert11 which gives me:
14:44 dogbert11 #0 0xb4a032ce in MVM_is_null /home/dogbert/repos/rakudo/install/include/moar/6model/reprs/MVMNull.h:11
14:44 dogbert11 #1 0xb4a032ce in p6recont_ro /home/dogbert/repos/rakudo/src/vm/moar/ops/perl6_ops.c:268
14:48 IOninja wonder if rakudo needs to be re-parsed and recompiled after just a change in .c code
14:48 IOninja takes ages
14:48 IOninja in src/vm/moar/ops/perl6_ops.c
14:50 dogbert11 don't think so, when I make changes in the MoarVM code I do what I described above. I only rebuild rakudo when I want the latest changes from upstream
14:51 dogbert11 on the other hand, that code isn't in MoarVM
14:51 * dogbert11 shuts up
14:56 MasterDuke_ dogbert11: have you tried running cppcheck (i think that's what you used recently on Moar) on the rakudo c code?
14:58 dogbert11 MasterDuke_: yes, but the version I have at $work (1.61) choked :(
14:58 dogbert11 perhaps you have a newer version ...
14:58 MasterDuke_ i just installed 1.77 here at home
14:59 MasterDuke_ how did you run it? i've never used it before
15:00 dogbert11 cppcheck <path> 2> err.txt
15:01 dogbert11 if you point to a directory the program will do a recursive check
15:02 MasterDuke_ no errors in ./src/vm/moar/ops/container.c or ./src/vm/moar/ops/perl6_ops.c
15:06 dogbert11 try with --enable=warnings
15:08 MasterDuke_ still nothing
15:09 dogbert11 well, perhaps the code is clean :) try it in MoarVM instead
15:11 MasterDuke_ [core/exceptions.c:767]: (error) Uninitialized struct member: lh.handler_out_of_dynamic_scope
15:11 MasterDuke_ [core/hll.c:275]: (error) Uninitialized variable: result
15:11 MasterDuke_ [platform/inttypes.h:6]: (error) #include nested too deeply
15:12 MasterDuke_ same things you found?
15:13 dogbert11 yes, but I haven't checked if they are legit or false positives. it's possible that Moritz have done that though
15:14 dogbert11 the hll.c one looks like a false positive to me
15:14 MasterDuke_ the one in core/hll looks bogus
15:14 dogbert11 agreed
15:14 IOninja Well, using sheer brute force and copious printfs(), I golfed the SEGV further down to `((Rakudo_ContainerDescriptor *)desc)->rw`.... umm... method call? struct field look up?... in p6recont_ro
15:15 IOninja More exactly `if ( ((Rakudo_ContainerDescriptor *)desc)->rw ) { printf("here2.1.3\n"); }` line segfaults
15:17 dogbert11 i.e. line 268
15:18 jnthn Does it do an IS_CONCRETE(desc) somewhere before the dereference?
15:19 MasterDuke_ nope, just `!MVM_is_null(tc, desc)`
15:19 moritz dogbert11: I couldn't substantiate the claim about lh.handler_out_of_dynamic_scope
15:19 IOninja jnthn: !MVM_is_null(tc, desc)
15:19 moritz but I couldn't dismiss it entirely either
15:19 IOninja oh, hm
15:20 MasterDuke_ building right now with an added IS_CONCRETE(desc)
15:20 IOninja My `if ( !MVM_is_null(tc, desc) ) { printf("here2.1.1\n"); }` does print so that means  ((Rakudo_ContainerDescriptor *)desc)->rw never actually runs in that code
15:20 IOninja Or.. not supposed to
15:20 jnthn Worth trying adding the IS_CONCRETE
15:21 * jnthn is tied up writing an async binding to a C library, so not following too closely here :)
15:21 IOninja Oh wait, I misread the conditional, yeah tis supposed to run :)
15:21 IOninja Here's my diff and output: https://gist.github.com/zoffixznet/dba1581bddeb4f6d99e3c2c3b51d96e8
15:21 MasterDuke_ changing `if (!MVM_is_null(tc, desc) && ((Rakudo_ContainerDescriptor *)desc)->rw) {` to `if (!MVM_is_null(tc, desc) && IS_CONCRETE(desc) && ((Rakudo_ContainerDescriptor *)desc)->rw) {` still segfaults
15:21 IOninja MasterDuke_: how did you build it so fast?
15:22 MasterDuke_ it takes about 100s to build
15:22 IOninja oh ok, same here...
15:22 ggoebel joined #moarvm
15:24 MasterDuke_ fwiw, here's a gist of the valgrind output, https://gist.github.com/MasterDuke17/42a433803fd1c160116aef4e236d23d4
15:24 MasterDuke_ though it used to say invalid read of size 8 before i added that IS_CONCRETE(desc)
15:30 IOninja how to run valgrind?
15:30 dogbert11 there is a perl6-valgrind-m you can run
15:30 IOninja Ah, thanks
15:56 dogbert11 it can be a tad slow sometimes (understatement)
16:10 pyrimidine joined #moarvm
16:21 IOninja filed proper ticket for `unique Scalar` SEGV: https://rt.perl.org/Ticket/Display.html?id=130852#txn-1450111
16:31 MasterDuke_ ah, i got it to not segfault. if it just does nothing is that ok?
16:36 MasterDuke_ spectests clean
16:37 MasterDuke_ i'll create a PR so someone can take a look at it
17:27 dogbert17 MasterDuke_++
17:27 yoleaux2 03:24Z <IOninja> dogbert17: I'm told you like hunting SEGVs: https://irclog.perlgeek.de/perl6/2017-02-24#i_14155509
17:32 pyrimidine joined #moarvm
18:07 pyrimidine joined #moarvm
18:09 timotimo wow, i could kick myself for not having the concreteness idea there
18:09 dogbert17 now you have a concrete example :)
18:14 lizmat jnthn: re nqp::list vs IterationBuffer
18:14 MasterDuke i wondered about that `check` variable early on, but tried adding `check && STABLE(check) &&` where i ended up adding `IS_CONCRETE(check) &&` and it made no difference
18:14 lizmat jnthn: historically, before GLR, $!reified was always an nqp::list
18:15 lizmat jnthn: now it can basically either be an nqp::list or an IterationBuffer
18:15 timotimo IterationBuffer is only a minimal step up from nqp::list
18:15 timotimo but it should probably be unified
18:15 lizmat jnthn: do you see any reasons to not make it an IterationBuffer always ?
18:16 lizmat timotimo: thing is, if you pass an nqp::list around as a parameter, it gets upgraded to a List
18:16 lizmat an IterationBuffer does noet
18:16 timotimo that seems annoying :)
18:16 lizmat *not
18:16 zakharyas joined #moarvm
18:16 lizmat well, doing a .sort atm creates at least 2 List objects that get discarded almost immediately
18:16 lizmat which creates nursery pressure
18:17 lizmat unnecessary nursery pressure  :-)
18:17 timotimo they get created because an nqp::list goes through nqp::hllize?
18:17 timotimo (that would be what turns an nqp::list into a List)
18:17 lizmat yeah, think so
18:17 timotimo OK, sounds like a good spot for an IterationBuffer
18:17 lizmat m: use nqp; dd nqp::list'
18:17 camelia rakudo-moar e9b55e: OUTPUT: «===SORRY!=== Error while compiling <tmp>␤Two terms in a row␤at <tmp>:1␤------> use nqp; dd nqp::list⏏'␤    expecting any of:␤        infix␤        infix stopper␤        postfix␤        statement end␤        statement modi…»
18:18 lizmat m: use nqp; dd nqp::list
18:18 camelia rakudo-moar e9b55e: OUTPUT: «()␤»
18:18 lizmat m: use nqp; dd nqp::create(IterationBuffer)
18:18 camelia rakudo-moar e9b55e: OUTPUT: «()␤»
18:18 lizmat wow ?
18:18 lizmat ah, that'd be the IterationBuffer.perl I added some weeks ago  :-)
18:18 timotimo :D
18:20 lizmat m: use nqp; dd nqp::create(IterationBuffer).WHAT
18:20 camelia rakudo-moar e9b55e: OUTPUT: «IterationBuffer␤»
18:20 lizmat m: use nqp; dd nqp::list.WHAT
18:20 camelia rakudo-moar e9b55e: OUTPUT: «()␤»
18:20 lizmat m: use nqp; dd (nqp::list).WHAT
18:20 camelia rakudo-moar e9b55e: OUTPUT: «()␤»
18:20 lizmat hmmm
18:20 lizmat m: use nqp; dd (nqp::list).^name
18:20 camelia rakudo-moar e9b55e: OUTPUT: «"BOOTArray"␤»
18:20 timotimo so that's not enough to hllize it
18:20 timotimo m: use nqp; dd nqp::what(nqp::list)
18:20 camelia rakudo-moar e9b55e: OUTPUT: «()␤»
18:20 timotimo m: use nqp; dd nqp::hllize(nqp::list).^name
18:20 camelia rakudo-moar e9b55e: OUTPUT: «"List"␤»
18:20 lizmat m: use nqp; say nqp::list.perl
18:20 camelia rakudo-moar e9b55e: OUTPUT: «Cannot find method 'perl': no method cache and no .^find_method␤  in block <unit> at <tmp> line 1␤␤»
18:21 lizmat m: use nqp; sub a(\a) { dd a.WHAT }; a nqp::list
18:21 camelia rakudo-moar e9b55e: OUTPUT: «List␤»
18:21 dogbert17 timotimo: do you understand this code? https://github.com/MoarVM/MoarVM/blob/master/src/core/nativecall_dyncall.c#L13
18:22 dogbert17 there are two 'strcmp(cname, "stdcall")' in there, looks a bit strange
18:25 timotimo yeah, that looks kind of wrong
18:26 timotimo clearly one is meant to give you the 64bit one and another the 32bit one
18:26 dogbert17 perhaps it shouldn't be 'stdcall' in one of the cases?
18:27 timotimo i have no clue of different call conventions
18:27 timotimo i'm not sure you can even properly call into 32bit code from a 64bit program
18:27 dogbert17 me neither
18:27 timotimo don't you have to switch the processor into 32bit mode for that to work?
18:28 dogbert17 no clue
18:29 dogbert17 perhaps froggs knows
18:30 timotimo having a headache doesn't help things
18:30 dogbert17 ouch
18:36 pyrimidine joined #moarvm
18:36 jnthn lizmat: IterationBuffer is just as efficient (memory, time) as nqp::list
18:36 lizmat jnthn: yes, I know
18:36 jnthn lizmat: It's just a type based upon the same REPR
18:36 lizmat but IterationBuffer doesn't get HLLized
18:36 jnthn Right
18:36 lizmat and nqp::list does
18:37 lizmat which makes for a lot of List object creation all of the time in the setting
18:37 jnthn I added IterationBuffer so we could have something quite primitive and pass it around
18:37 lizmat just because of passing along an nqp::list that could be an IterationBuffer
18:37 jnthn In Perl 6 space
18:38 jnthn In the original GLR exploration I did, $!reified was always an IterationBuffer
18:38 lizmat but that broke a lot, I guess  :-)
18:38 jnthn Not really
18:39 lizmat so what made you decide not to do that ?
18:39 jnthn Well, it wasn't really a concious decision not to, so much as that in a handful of cases (like nqp::vmargarray or whatever it's called) you just ended up with an nqp::list
18:39 jnthn It doesn't break anything
18:40 jnthn I suspect nowadays, because you can in many cases (like, when no $!todo) get away with nqp::list and IterationBuffer, we've got a profileration of nqp::list in there that could be IterationBuffer instead.
18:41 jnthn I'm find with using IterationBuffer more widely for $!reified, especially if it makes other things easier :)
18:41 jnthn *fine
18:41 jnthn In fact, I'd prefer it that way :)
18:41 lizmat ok, will look at it then  :-)
18:41 jnthn Note that IterationBuffer is still a semi-internals-y type
18:42 jnthn It's there primarily so people writing custom Iterators could receive a lightweight, Perl 6 type to push things into
18:42 jnthn It's fine for us to use it in internals where we wish
18:43 jnthn Just be careful we don't "leak" there out of places that should return List
18:44 jnthn s/there/them/
18:44 jnthn (e.g. where we were previously relying on hllize to make a List)
18:47 lizmat jnthn: yeah, gotcha  :-)
18:51 jnthn https://github.com/jnthn/p6-ssh-libssh # what ate my brane cycles today :)
18:51 IOninja cool :)
18:51 jnthn For anyone curious what my NativeCall questions were about earlier :)
18:53 jnthn Quite nice that we can write basic async bindings to native libraries in Perl 6 without needing any intermediate C stuff
18:54 jnthn Was really hard to find examples of doing libssh non-blocking too
18:54 jnthn And the docs are...interesting :-)
18:57 jnthn Will stick it on modules.perl6.org once I get it far along enough that it's useful for the $dayjob project I need it for.
18:57 jnthn Then will see if I can find free time tuits to fill out the bits that project doesn't need. :-)
18:58 jnthn (I don't need the server parts at all, for example)
18:58 jnthn (But it might be fun to write the binding for that)
18:59 timotimo did you end up getting something to put function pointers into structs?
18:59 jnthn No
18:59 jnthn I found a way to not have to do that
19:00 jnthn I only need to juggle a small number of connections for what I'm doing; the function pointer/struct thing was needed to make it scale better up to dozens/hundreds
19:00 jnthn So it just wasn't worth the yak shave
19:02 jnthn Though I did along the way find a NativeCall bug
19:02 jnthn Got a local MoarVM patch for that but want to write some tests for the NativeCall test suite first
19:12 lizmat joined #moarvm
19:31 [Coke] jnthn: (https://github.com/jnthn/p6-ssh-libssh) don't forget a LICENSE.
19:32 [Coke] (having just gone through a license hunt for $dayjob)
19:35 pyrimidine joined #moarvm
19:57 MasterDuke joined #moarvm
20:13 jnthn [Coke]: I should probably do a check on all my modules for that, since I're likely missed it in a few
20:14 timotimo use perl6-all-modules for that! :D
20:14 [Coke] Danke.
20:16 moritz whenever somebody mentions perl6-all-modules, I have the sudden urge to update it again
20:16 moritz I guess I should really create a cron job for that
20:17 timotimo %)
20:17 timotimo probably
20:17 moritz I'm just uncomfortable leaving my SSH key unprotected for a cron job
20:17 moritz guess I should investigate if I can create an RW ssh key for that one repo
20:18 timotimo yeah, should be able to
20:26 ggoebel joined #moarvm
21:17 pyrimidine joined #moarvm
22:02 sivoais joined #moarvm
22:12 sivoais joined #moarvm

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