MasterDuke does anybody here know how to compile a moarvm with debugging (to use with valgrind) using rakudobrew? 01:23
dalek kudo/nom: 25caab2 | hoelzro++ | src/core/REPL.pm:
REPL: Offer all completions if we can't find a last identifier

Fixes RT #125520		 01:51
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=125520
dalek ast: fdfb717 | hoelzro++ | S32-exceptions/misc.t:
Write test for RT #129290
 02:42
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129290
dalek rakudo/nom: 8a70c92 | hoelzro++ | src/Perl6/Grammar.nqp:
rakudo/nom: Fixates borg and mystery at block start
rakudo/nom:
rakudo/nom: Fixes RT #129290.
rakudo/nom:
rakudo/nom: The way this used to work was complete blocks would set $*BORG<block>,
rakudo/nom: which missing_block would use to provide error information. The problem
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129290
dalek rakudo/nom: with this is if you start parsing a block (let's call it A), and create
rakudo/nom: a complete block (named B) within A. If there is no closing brace to
rakudo/nom: terminate A, missing_block will be called, but the block context set
rakudo/nom: up for B will be used to explain the error because it was the last
rakudo/nom: block to successfully parse.
travis-ci Rakudo build failed. Rob Hoelz 'REPL: Offer all completions if we can't find a last identifier 03:03
travis-ci.org/rakudo/rakudo/builds/160602351 github.com/rakudo/rakudo/compare/a...caab2fe810
buggable [travis build above] ā˜  Did not recognize some failures. Check results manually
travis-ci Rakudo build errored. Rob Hoelz 'Fixates borg and mystery at block start 03:45
travis-ci.org/rakudo/rakudo/builds/160606683 github.com/rakudo/rakudo/compare/2...70c921e98e
buggable [travis build above] ā˜  Did not recognize some failures. Check results manually 03:46
travis-ci Rakudo build errored. Rob Hoelz 'Fixates borg and mystery at block start 04:16
travis-ci.org/rakudo/rakudo/builds/160606683 github.com/rakudo/rakudo/compare/2...70c921e98e
buggable [travis build above] āœ“ All failures are due to timeout (1), missing build log (0), or GitHub connectivity (0)
lizmat Files=1138, Tests=52914, 232 wallclock secs (12.96 usr 3.94 sys + 1416.67 cusr 135.54 csys = 1569.11 CPU) 06:33
dalek ast: 48fc682 | lizmat++ | S10-packages/precompilation.t:
Need a little rest to pass on OSX
 06:45
lizmat commute& 06:46
dalek ast: 2f870af | usev6++ | S0 (3 files):
Fudge some tests for JVM
 06:47
[Tux] This is Rakudo version 2016.08.1-214-g8a70c92 built on MoarVM version 2016.08-47-g2eedba8 08:20
csv-ip5xs 9.552
test 15.926
test-t 6.947
csv-parser 17.397
Zoffix MasterDuke, cd nqp/MoarVM; perl Configure.pl --debug=3 --optimize=1; make; make install; cd ../../ 08:24
I think there should also be some sort of --full-clean-up or something to tell it to clean stuff up and not leave it up to the OS; otherwise valgrind will think stuff's leaking 08:25
but maybe --debug=3 handles that I dunno 08:26
nine Zoffix: like moar's --full-cleanup try to free all memory and exit cleanly 08:29
dalek kudo/nom: fd5ef86 | (Zoffix Znet)++ | docs/ChangeLog:
Log all changes to date

Logs 25caab2		 09:02
travis-ci Rakudo build failed. Zoffix Znet 'Log all changes to date 09:57
travis-ci.org/rakudo/rakudo/builds/160635744 github.com/rakudo/rakudo/compare/8...5ef86931a2
buggable [travis build above] ā˜  Did not recognize some failures. Check results manually
Zoffix union native call test again 10:00
nine Looks like there's a lot of performance improvements waiting to happen in Inline::Perl5. Right now, passing data form Perl 5 to Perl 6 must be incredibly expensive the way it is implemented. Also rather simple to improve. 10:18
I would just love to have better benchmarks of real world systems to play with.
Sometimes good old Perl is much line noise indeed: $$self->$at_key($key) 10:34
Zoffix :) 10:36
nine But I'm glad, I discovered the way to call methods with hypenated names like AT-KEY from Perl 5 code :)
MasterDuke Zoffix: rakudobrew build moar --configure-opts='--moar-option="--debug"' seemed to have helped 11:15
Zoffix m: ('a'ā€¦'z').map({ā€"$_ \{ ā€}).join.map({"$_'šŸ˜‚'{.flip.trans: '{' => '}'}"}).say 12:27
camelia rakudo-moar fd5ef8: OUTPUTĀ«("a { "b { "c { "d { "e { "f { "g { "h { "i { "j { "k { "l { "m { "n { "o { "p { "q { "r { "s { "t { "u { "v { "w { "x { "y { "z { 'šŸ˜‚' } z" } y" } x" } w" } v" } u" } t" } s" } r" } q" } p" } o" } n" } m" } l" } k" } j" } i" } h" } g" } f" } e" } d" } cā€¦Ā»
Zoffix m: ('a'ā€¦'z').map({ā€"$_ \{ ā€}).join.map({"$_'šŸ˜‚'{.flip.trans: '{' => '}'}"}).EVAL.say
camelia rakudo-moar fd5ef8: OUTPUTĀ«a b c d e f g h i j k l m n o p q r s t u v w x y z šŸ˜‚ z y x w v u t s r q p o n m l k j i h g f e d c b aā¤Ā»
Zoffix ^_^
Also, I think there's a bug: 12:28
m: say ('a'ā€¦'c').map({ā€"$_ \{ ā€}).join.map({($_, .flip.trans('{' => '}'))})[0]
camelia rakudo-moar fd5ef8: OUTPUTĀ«("a { "b { "c { } c" } b" } a")ā¤Ā»
Zoffix Why is the resultant string joined? My map is returning two elements
*supposed to return
timotimo because when you say it, it just puts a space in between?
Zoffix timotimo, I have [0] at the end
timotimo ah 12:29
Zoffix m: say ('a'ā€¦'c').map({ā€"$_ \{ ā€}).join.map({($_, .flip.trans('{' => '}'))}).elems
camelia rakudo-moar fd5ef8: OUTPUTĀ«1ā¤Ā»
timotimo ah, you're not slipping it properly, i bet
m: (^10).map({$_, $_ * 2}).perl.say
camelia rakudo-moar fd5ef8: OUTPUTĀ«((0, 0), (1, 2), (2, 4), (3, 6), (4, 8), (5, 10), (6, 12), (7, 14), (8, 16), (9, 18)).Seqā¤Ā»
timotimo you see?
Zoffix Ah
timotimo++
MasterDuke timotimo: you've done some of the MoarVM IO stuff, does this look like a simple fix? RT #129291 12:31
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129291
timotimo that looks strange 12:32
dogbert17 o/ Zoffix, only one spectest still failing on my 32 bit Linux vm. jnthn and timotimo took care of the rest
Zoffix cool
timotimo opaque_get_real_data is about objects with mixins 12:33
i did anything? o_O
dogbert17 timotimo: some GC and failure trickry
the last subtest in t/spec/S32-num/power.rakudo.moar is the only one left 12:34
timotimo ah, that
MasterDuke timotimo: line 37 of syncpipe.c: MVM_free(data->process->data);
timotimo well, that was just a simple warning
it meant almost nothing :)
dogbert17 timotimo: true, but it was annoying :) 12:35
on my system the following throws: say 1.0000001 ** (10 ** 9) 12:36
Zoffix buggable, test
Hm. Buggable seems to be slowly leaking. 12:37
1232M RES 12:38
nine Wrapping P5 hashes instead of copying: 15s -> 7s. Wrapping P6 hashes instead of copying: 7s -> 17s :( 12:53
mst how odd 13:00
nine Of course, that's just the first try with all the tieing done in Perl 5 code
Note only that but all access to the P6 hash goes through the very generic call_method which cannot help performance. 13:13
Still, it's hard to say with code spread between Perl 6, C and Perl 5 and no tool understanding that :/
timotimo with the p5 hash repr that could become a whole lot faster 13:14
however, you'll have to create the hash on the perl6 side as a perl5 hash from the start
but: 13:15
if you transfer it over from the perl6 hash into the perl5 hash via a perl5 hash repr, it'll be without NativeCall overhead 13:16
and you can write some very tight code to do the transfer
moritz any more comments on github.com/rakudo/rakudo/pull/719 ? 13:32
if not, I'll merge it 13:33
Zoffix moritz, I rather we did not name it .args 13:44
nine timotimo: what would be a good place to look into reprs? 13:46
Zoffix Maybe make it a private method and tell it to trusts that exception
timotimo there might be some doc about reprs in the nqp repo? don't know about that. other than that, just the 6model/reprs/ folder in moarvm 13:47
there's a header file in 6model, maybe it's 6model.h, that has a bunch of comments for all the functions you can install for a repr
the ReprOps
nine If I go that way, I'm gonna need to provide the repr implementaion for all backends, aren't I? 13:52
timotimo oh, hmm
if you don't do it on JVM, declaring a class with "is repr('P5Hash')" will throw
another thing that we'll havee to think about is memory ownership 13:55
we don't really have proper memory ownership for CStruct and CArray, it feels like
arnsholt Yeah, NativeCall has no way to control ownership of bits of memory 14:29
timotimo well, "control" might not be the right word 14:30
mst maybe we can ... borrow ... from rust
arnsholt Signal ownership, perhaps? 14:31
Oh, and boo mst =p
But good pun, still =D
nine Looks like Dancer2 just really likes to write the same values into the %tokens hash again and again 14:38
Zoffix Oh. MoarVM was already released 14:40
timotimo yup :)
now we can put all our crazy experimental stuff into moarvm!
Zoffix \o/ 14:41
nine And I lost the speedup of wrapping the P5 hash because originally that's actually a P6 hash. So my 3 write accesses into that are now really fast, but the 80 accesses by Dancer2 are slow
hoelzro o/ #perl6-dev
tadzik ooh, work on wrapping Dancer2 efficiently? :3 14:42
nine Well, I'll be at www.perl.dance/ next week, so I thought I could add a little Dancer 2 example ;) 14:45
Can an AT-KEY on a defined hash throw any exceptions? 14:50
timotimo hm. what if there's a Failure stored in the hash. it might get thrown when something along the path sinks it? 14:55
nine The thought of Failures interacting with Perl 5 code is disturbing. 14:56
dalek p/rt-126900: f0540d5 | hoelzro++ | src/vm/moar/QAST/QASTOperationsMAST.nqp:
Verify we still have a block when climbing lexical stack

Fixes RT #126900
Resolving lexicals in an outer block runs out of blocks if we try to resolve a natively-typed (ex. my int) lexical from within a Perl 6 EVAL
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126900
kudo/nom: a02ac71 | MasterDuke17++ | tools/build/create-moar-runner.pl:
Add '--full-cleanup' to moar in perl-valgrind-m

Gives more accurate memory leak information.		 14:57
kudo/nom: 3583e26 | (Zoffix Znet)++ | tools/build/create-moar-runner.pl:
Merge pull request #881 from MasterDuke17/add_--full-cleanup_to_perl-valgrind-m

Add '--full-cleanup' to moar in perl-valgrind-m
hoelzro I took a stab at fixing rt.perl.org/Ticket/Display.html?id=126900 last night; I managed to produce a fix in NQP-land, but I would like someone to sanity check it
would anyone mind having a look at nqp/rt-126900?
it adds some additional checking to a while loop when climbing the lexical frames 14:58
when looking up a lexical that has a native type (like my int) in an EVAL
the thing that makes me hesitate is if I did my int $i = 1; do { $i = 2 }, the lookup would succeed 14:59
whereas my change is making it bail out for my int $i = 1; EVAL '$i = 2'
ah, I see; it's used by NQP to determine if a native assignment can be done or not 15:13
nine Yes! Providing specialized callbacks for Hash access instead of going over the generic call_method is much faster indeed :) 15:15
mst \o/ 15:16
nine This also indicates that it may pay off to have special call_method_single_arg and call_method_no_args variants 15:26
timotimo quite probably 15:29
nativecall in general could probably benefit from a few special roles that are differentiated in that way
travis-ci Rakudo build passed. Zoffix Znet 'Merge pull request #881 from MasterDuke17/add_--full-cleanup_to_perl-valgrind-m 16:02
travis-ci.org/rakudo/rakudo/builds/160672079 github.com/rakudo/rakudo/compare/f...83e265d3e3
Zoffix shoo 16:03
nine Ok, down to 11s on my benchmark (progression is 15 -> 7 -> 17 -> 13 -> 11) 16:16
TimToady wonders if that sequence is in the oeis... 16:18
timotimo .o( oh, eis! ) 16:26
Zoffix oh god, what have I done 16:32
Oh. nm. Wrong box :P
mst hah 16:34
nine Wow. Removing the indirection of going via Perl 5 functions for FETCH/STORE and replacing them with a single line of C code saves.... nothing. Not measurable. 16:37
Apparently creating shallow copies of hashes ($new = { %$old, ... }) is quite common in Dancer2's code. I wonder if there's a way to speed that up. Right now, perl calls FIRSTKEY, then NEXTKEY until that returns undef and then for each of the keys a FETCH. 16:46
No wonder we do ~ 500 NativeCalls for rendering a trivial page. 16:47
mst that's quite common in perl5 code in general tbh 16:49
nine Yep. And I don't see anything wrong with it. I just don't know how to improve performance there. 16:53
dalek kudo/nom: 4549642 | hoelzro++ | src/Perl6/Grammar.nqp:
Add LEFT DOUBLE PARENTHESIS to valid comment openers

It would be really nice if we could drop opener or define it in terms of $brackets from nqp/src/HLL/Grammar.nqp		 17:07
japhb nine: What do the fast Perl 5 data structure serializer modules do? I would think a similar technique could be used. 17:35
arnsholt nine: 500 NativeCalls. I'm afraid to even contemplate how slow that is >.< 18:00
travis-ci Rakudo build failed. Rob Hoelz 'Add LEFT DOUBLE PARENTHESIS to valid comment openers 18:03
travis-ci.org/rakudo/rakudo/builds/160692088 github.com/rakudo/rakudo/compare/3...4964263b3b
Zoffix just a t/04-nativecall/13-union.t 18:05
mst nine: make the tied thing cache a perl5 side copy on FIRSTKEY and blow the cache if mutated? 18:09
Zoffix NeuralAnomaly, hey 18:24
NeuralAnomaly Zoffix, yo
Zoffix NeuralAnomaly, it's time
NeuralAnomaly Zoffix, Oh boy! Really?! We're doing a realeaseā€½ā€½ YEY!
Zoffix Yup.
NeuralAnomaly, cut the release
NeuralAnomaly Zoffix, Will do! If you're feeling particularly naughty, you can watch me at perl6.fail/release/progress or go look at some cats www.lolcats.com/
Zoffix, ā™„ā™„ā™„ā™„ā™„ā™„ Prep done
dalek p: e8c5e73 | (Zoffix Znet)++ | tools/build/MOAR_REVISION:
bump MoarVM version to 2016.09
p: a984cfc | (Zoffix Znet)++ | VERSION:
bump VERSION to 2016.09
nine Zoffix++ # not only automating the release, but making it fun :) 18:25
Zoffix :)
BAHAHA 18:26
Fucking google
I was running a "preemptive" instance all day long (one that might get killed at any time, but it's much cheaper). I then turned it off, went to turn off preemptibility, but there's no switch. You have to create a whole new VM. So I thought, screw it, started it again..... And well, google killed it shortly after :) 18:28
And I notice they do it that way frequently :)
MasterDuke Zoffix++ google--
geekosaur you get what you pay for 18:29
Zoffix geekosaur, I don't mind, but having a switch to pay more would be more helpful :) 18:30
an easy switch
NeuralAnomaly, steps
NeuralAnomaly Zoffix, all pre nqp r post pre-r6 pre-blank-slate nqp-clone nqp-bump-vers nqp-build nqp-tar nqp-tar-build nqp-tag nqp-tar-sign nqp-tar-copy r-clone r-prep-ann r-bump-vers r-build r-p5 r-stress r-stress-v6c r-tar r-tar-build r-tar-p5 r-tar-stress r-tag r-tar-sign r-tar-copy post-scp
Zoffix NeuralAnomaly, run nqp-build nqp-tar nqp-tar-build nqp-tag nqp-tar-sign nqp-tar-copy r-clone r-prep-ann r-bump-vers r-build r-p5 r-stress r-stress-v6c r-tar r-tar-build r-tar-p5 r-tar-stress r-tag r-tar-sign r-tar-copy post-scp 18:31
NeuralAnomaly Zoffix, ā˜ ā˜ ā˜ ā˜ ā˜ ā˜  NQP: build and test
Zoffix, ā˜ ā˜ ā˜ ā˜ ā˜ ā˜ ā˜ ā˜ ā˜ ā˜  ABNORMAL EXIT!
Zoffix lol
Ah, right
NeuralAnomaly, run pre-blank-slate nqp-clone nqp-build nqp-tar nqp-tar-build nqp-tag nqp-tar-sign nqp-tar-copy r-clone r-prep-ann r-bump-vers r-build r-p5 r-stress r-stress-v6c r-tar r-tar-build r-tar-p5 r-tar-stress r-tag r-tar-sign r-tar-copy post-scp 18:32
NeuralAnomaly Zoffix, ā™„ā™„ā™„ā™„ā™„ā™„ Prep done
Zoffix Off to a rocky start, but not a problem :) 18:34
AlexDaniel Zoffix++ # pretty cool bot 18:41
NeuralAnomaly Zoffix, ā™„ā™„ā™„ā™„ā™„ā™„ nqp tests OK
Zoffix AlexDaniel, my favourite part is this: subset BotAdmin of IRC::Client::Message where .host eq conf<bot-admins>.any; multi method irc-to-me (BotAdmin $e where /:i ^ 'run' $<steps>=.+ $/ ) { ... } 18:42
<3 subsets
AlexDaniel .tell jnthn It looks like half of my segmentation faults will go away if #129291 is fixed. Perhaps you can take a look? That would be great. 18:45
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129291
yoleaux2 AlexDaniel: I'll pass your message to jnthn.
NeuralAnomaly Zoffix, ā™„ā™„ā™„ā™„ā™„ā™„ nqp release tarball tests OK 18:50
Zoffix, ā™„ā™„ā™„ā™„ā™„ā™„ nqp release DONE 18:51
dalek kudo/nom: e46da6b | (Zoffix Znet)++ | docs/announce/2016.09.md:
Generate release announcement for 2016.09
kudo/nom: 257083d | (Zoffix Znet)++ | tools/build/NQP_REVISION:
[release] bump NQP revision
kudo/nom: 4b32fca | (Zoffix Znet)++ | VERSION:
[release] bump VERSION to 2016.09
Zoffix Well, the bot got the NQP tag right. So it did better than me already :P 18:52
stmuk does the bot get credit in release_guide.pod? :) 18:56
"pay no attention to the man behind the curtain" :P
Zoffix stmuk++
NeuralAnomaly Zoffix, ā™„ā™„ā™„ā™„ā™„ā™„ Rakudo stresstest (master) OK 18:58
Zoffix, ā™„ā™„ā™„ā™„ā™„ā™„ Rakudo stresstest (6.c-errata) OK 19:00
Zoffix, ā™„ā™„ā™„ā™„ā™„ā™„ Rakudo release DONE 19:08
Zoffix, ā™„ā™„ā™„ā™„ā™„ā™„ Post: upload tarballs to rakudo.org
Zoffix, šŸŽŗšŸŽŗšŸŽŗšŸ“ÆšŸ“ÆšŸ“ÆšŸ“ÆšŸ“ÆšŸ“ÆšŸŒˆšŸŒˆšŸŒˆšŸ“¦šŸ“¦šŸ“¦
Zoffix, The release of **Rakudo #103 2016.09** has now been completed
Zoffix, šŸŽŗšŸŽŗšŸŽŗšŸ“ÆšŸ“ÆšŸ“ÆšŸ“ÆšŸ“ÆšŸ“ÆšŸŒˆšŸŒˆšŸŒˆšŸ“¦šŸ“¦šŸ“¦
NeuralAnomaly celebrates with an appropriate amount of fun
Zoffix NeuralAnomaly, thanks for doing the release! 19:09
NeuralAnomaly Zoffix, any time, buddy!
Zoffix New blog post: "Perl6.Fail, Release Robots, and Other Goodies": perl6.party/post/Perl6-Fail-Release...er-Goodies 19:11
dalek kudo/nom: f111f07 | (Zoffix Znet)++ | docs/release_guide.pod:
2016.09 is now in the past
 19:16
stmuk dual credit :) 19:22
dalek kudo/nom: c4fd9f5 | moritz++ | src/core/ (2 files):
Include command in X::Proc::Unsuccessful output.

Closes #719. rudis++ for the original patch that this one is based on.		 19:32
jnthn Zoffix++ # so much awesome
yoleaux2 16 Sep 2016 19:50Z <japhb> jnthn: When you get a few cycles, could you sketch out how you would want async SSL/TLS to even work with your new NQP async streaming APIs, so one of us could do the grunt work?
18:45Z <AlexDaniel> jnthn: It looks like half of my segmentation faults will go away if #129291 is fixed. Perhaps you can take a look? That would be great.
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129291
jnthn Heh, two different people have now asked me to look at that bug today. :P Will throw some tuits at it next week :) 19:33
Zoffix moritz++
travis-ci Rakudo build passed. Zoffix Znet '[release] bump VERSION to 2016.09' 19:47
travis-ci.org/rakudo/rakudo/builds/160707645 github.com/rakudo/rakudo/compare/4...32fcab2192
Rakudo build passed. Zoffix Znet '2016.09 is now in the past' 20:27
travis-ci.org/rakudo/rakudo/builds/160711689 github.com/rakudo/rakudo/compare/4...11f0735ead
Rakudo build passed. Moritz Lenz 'Include command in X::Proc::Unsuccessful output. 21:03
travis-ci.org/rakudo/rakudo/builds/160714025 github.com/rakudo/rakudo/compare/f...fd9f515d49
moritz that only took 1.5h :-) 21:04
Zoffix :)
japhb Zoffix++ # Release bot of great puissance 21:26
Zoffix bruh, we get it stuff passes now... go away.
Oh, oops.
My scroll was up and I saw the highlight, but the scroll was a travis saying stuff passed :) 21:27
Zoffix looks up puissance
mst it means you're a kitty 21:28
Zoffix "a competition in showjumping that tests a horse's ability to jump a limited number of large obstacles"
heh
geekosaur from French, "powerful"
jnthn japhb: oops, I forgot to respond to your .tell... In short: I'd love help, but I suspect the only way I'll get to the point of having a suggestion of a sensible way to do it is to actually get so far as having a basic example working. :S 21:31
japhb: I could more than happily hand off the rest of it once I get to that point though. 21:32
japhb jnthn: Hmmm, yeah, I can see that
Fair enough
jnthn My gut feeling from what I've seen so far is that we can feed the incoming packets into a BIO or whatever they're called
I'd really like us to do the cooridnation of it Perl 6 side. 21:33
I'm most of the way through untangling string decoding and async sockets; I'd rather not make another fragile tangle.
japhb Yeah, agreed.
jnthn Seems like any string decoding is downstream of the SSL bit though. 21:34
japhb Yeah. And if it was just a simple streaming layer, then I would say "Wheee, layered decoders!", but SSL has a state machine that is rather different from e.g. a codepoint compositor 21:35
jnthn For sure, it needs to be able to do back and forth on the underlying socket 21:36
Before it's ready to send your stuff or tell you what's incoming
japhb right
MasterDuke jnthn: i don't want to be a bother (so feel free to punt), but re my ticket about run+:in+:out, do you suspect there's an easy/straightforward fix? i've been playing around with it, but don't see how to prevent the one thread from reaching into the other 21:41
jnthn MasterDuke: Didn't look it that closely yet, and don't have any magical intuition on this one, sorry. 21:45
(I didn't write that chunk of the code in the first place, so step one will be for me to understand it. :)) 21:46
MasterDuke no worries
jnthn The valgrind output is suggestive that we do a mis-timed free and that ends up causing all manner of downstream problems 21:47
I think most of the output is noise
Arising from an undefined value propagating through the system
MasterDuke yeah. if i comment out the free the segfault goes away, but valgrind still complains about reading across threads 21:48
jnthn So probably only the invalid free itself and maybe the thing right after it are significant.
arnsholt scrollbacks regarding SSL 22:02
japhb: So, if you wrap OpenSSL I think you could more or less get away with layered decoders 22:03
timotimo arnsholt: oh, you're going to lay the wisdom upon us for how to get IO::Socket::SSL::Async to work? :) 22:04
arnsholt I'm less familiar with the async side of the API, sadly
I started out with the blocking API, knowing that async is full of additional horrors
The main complication, AFAICT, is that a read can fail because the socket wants a write and conversely a write can fail because you have to read 22:05
(Yes, really)
Because of the underlying protocol sometimes requiring additional data exchanges
But the OpenSSL API, IO-wise at least, itself is basically just reading and writing bytes 22:06
japhb arnsholt: Yeah, it appears from the ecosystem that we already have the sync interface more or less. It's the async that has me worried. And if as jnthn suggests we want to do the protocol coordination in Perl 6, that's a lot of layers to punch the asynchrony through 22:07
arnsholt Yah
And the OpenSSL C API is kind of horrifying 22:08
japhb Especially handshake, changing cyphers, etc.
timotimo well, now that encoding/decoding is going to move more and more into our user space, building an async thing on top of IO::Socket::SSL can be done well, i expect?
japhb timotimo: connect has a full handshake. Connecting (from a client or a listen port) can block for a long time. 22:09
timotimo OK, so we might have to spawn a full thread for it to work?
japhb And don't we currently have the problem that the sync IO layer is plumbed through libuv, so we can't just go threadshifting that pain?
timotimo oh 22:10
that's a thing, yes
but if we spawn a full thread to handle a single ssl connection, we'll have everything happen in that thread anyway?
japhb Like if we pushed a client connect into another thread, we couldn't use the socket in the original thread once it connected
But that's not really an async API, that's a threaded connection API
timotimo well, it'll just give the user a supply for receiving data and probably move data-to-be-sent via a channel 22:11
japhb In other words, yeah, we could probably hack something together, but it'd be a damaged API, and probably not terribly safe to boot.
timotimo the thread is just an implementation detail
japhb timotimo: Threads are only an implementation detail up until the abstraction leaks 22:12
.oO( I hate it when a shuffled playlist ends up with a horribly jarring transition )
 22:13
timotimo :) 22:17
i don't know how other projects handle many SSL sockets
maybe there's a select-like function provided by openssl where we can multiplex multiple sockets over a single worker thread? 22:20
japhb FWIW I have a use case for different security protocols than classic TCP SSL/TLS, so whatever design we end up with shouldn't bake that assumption in
timotimo: Good question.
jnthn I'd really hope we can implemnet it in a way that isn't thread-tied... 22:24
As arnsholt said though, I get the impression that the BIO interface lets you "just" treat it as shoving stuff into buffers when it arrives over the network, and writing stuff out from the buffers OpenSSL gives you back. 22:25
Async isn't *that* much scarier. Instead of blocking on a recv, you get a callback when the recv happens. And writing is about the same. 22:26
And provided you do it in a supply block you've got concurrency control "for free" 22:27
Zoffix m: multi sub infix:<==> (Int $a, Str $b) { $a == $b } 22:30
camelia rakudo-moar c4fd9f: OUTPUTĀ«(timeout)Ā» 22:31
Zoffix m: multi sub infix:<==> (Int $a, Str $b) { say "but not this"; $a == $b }
camelia ( no output )
Zoffix Any hints on where to start looking for a fix for stuff like thiat?
Hm, --optimize=0 avoid it. I'm guessing I want github.com/rakudo/rakudo/blob/nom/...imizer.nqp 22:32
jnthn That may fall under "you got what you deserved"... :/ 22:34
== is marked "is pure" or so, meaning we constant fold it. To constant fold it, we run it at compile time. The halting problem says hi... 22:35
dalek kudo/nom: 8fb9ec9 | timotimo++ | lib/NativeCall.pm6:
prevent Native routines from being setup concurrently

i use one global lock instead of a per-routine lock
  because this setup method won't run often, and usually
only during the initial phases of an individual workload.
Zoffix m: multi sub infix:<==> (Int $a, Int $b) { $a == $b } 22:36
camelia ( no output )
Zoffix How come this doesn't get the same issue?
jnthn oh wait, wtf
timotimo hah
jnthn That isn't even constant folding
timotimo inlining perhaps?
japhb I was gonna say
timotimo the "say" might prevent inlining in one case 22:37
jnthn is sleep deprived :)
Or :( perhaps...
timotimo hm, no, inlining wouldn't do this recursively ad infinitum
jnthn Indeed. No, I don't know what it is, but the optimizer is the place to look
It *may* be compile-time multi resolution gone wild
Zoffix Int,Int doesn't have the issue because it's ambiguous with Int:D, Int:D defined in core 22:49
I'm just gonna close that ticket. The sub can't be used anyway, so there's no point in trying to make it compile, I think. 22:51
jnthn I'd say we should track down/fix the hang though 22:56
It's not very nice behavior
And it might end up being a bug that could affect something else that's more legitimate
Zoffix Alright. I'll track down where it happens. 22:59
dalek kudo/nom: 31c4c6f | (Zoffix Znet)++ | src/Perl6/Compiler.nqp:
Fix typo in comment and remove trailing whitespace
 23:13
jnthn sleep & 23:19
travis-ci Rakudo build failed. Timo Paulssen 'prevent Native routines from being setup concurrently 23:26
travis-ci.org/rakudo/rakudo/builds/160739076 github.com/rakudo/rakudo/compare/c...b9ec91766e
Zoffix t/04-nativecall/13-union.t 23:27

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!