Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
tbrowder_ can't these jerks be prosecuted? 00:22
geekosaur you have to find them. and most of these are from "mules", not directly involved and tracking down how they got infected will be tricky 00:23
and many of them from other countries, and many of those don't have agreements with other countries' law enforcement and often don't have the ability to track them down 00:24
(or the willingness, hello russia)
nine Another fun fact about explicitly-manage: if you apply it to a string constant like explicitly-manage('foo'), then this will apply to all equal string constants. So a later this-function-wont-free-the-string('foo') will in fact leak the C string. 10:01
nine I dare say, even for the case of a native function that expects a string to survive the call yet still requires the user to actually free it, requiring the argument to be marked explicitly-managed seems to be the sane option. 11:01
The fact that the string needs to be kept longer than the function call is still a static property of that function. 11:03
The current explicitly-manage() is not even suitable for that use case, because while the CStr repr does keep a UTF-8 encoded C string around and this is even free()'d on GC, that's not actually the string that gets passed to the native function. 11:19
We still encode a new string for that on every call.
pmurias nine: wouldn't exposing the ability to manually alloc/free something in Perl 6 land solve all the problems with weird memory mangagement schemes? 11:40
timotimo "is memory-managed(alloc => -> $size { Buf.allocate($size) }, free => -> { })"
pmurias the docs for explicitly-manage: docs.perl6.org/routine/explicitly-manage 11:43
don't really explain what it does
nine The actual solution is so simple, it really hurts... 11:47
If the string needs to survive the call but still be free'd by Perl 6 or if you really want the same pointer to be passed to several function calls, just encode it to a blob explicitly and use utf8 as type in the native sub instead of STr 11:48
There's really no need for explicitly-manage()
nine sub SetString(utf8) is native('./02-simple-args') { * }; my $str = 'foo'.encode; SetString($str); CheckString($str); # works just fine 11:50
This also makes it much harder to misuse the sub. Type checks will keep you from passing normal strings and I don't think anyone would erroneously assume SetString($str.encode); CheckString($str.encode); would result in both calls getting the same pointer. 11:53
nine Ok, there's still one use case that's not covered there: take-some-string($str); take-same-string-and-also-free-it($str); 11:56
The issue with native code wanting to take ownership actually does apply to all allocated data types. I guess strings are just the most common case. 11:58
pmurias nine: re take-some-string($str);take-same-string-and-also-free-it($str) doesn't using that require malloc to be accesible on the Perl 6 side? 12:09
nine pmurias: kinda. At least in a wrapped version like explicitly-manage() was supposed to be, i.e. a malloc() + memcpy() 12:11
So, what we need for that is an explicitly-manage($obj --> Pointer). 12:13
Ok, all my thoughts on this distilled into an API documentation: gist.github.com/niner/53c4da135580...05a1d7895b 12:22
AlexDaniel squashable6: status 12:32
squashable6 AlexDaniel, 🍕🍕 SQUASHathon is in progress! The end of the event in ≈23 hours. See github.com/rakudo/rakudo/wiki/Mont...Squash-Day
AlexDaniel, Log and stats: gist.github.com/f7c4ebf443b3daebe6...6917d502b3
[Tux] Rakudo version 2018.06-502-gfa4d39639 - MoarVM version 2018.06-442-g633604d30
csv-ip5xs0.951 - 0.965
csv-ip5xs-207.411 - 8.117
csv-parser23.789 - 25.104
csv-test-xs-200.453 - 0.466
test8.192 - 9.420
test-t2.125 - 2.133
test-t --race0.900 - 0.903
test-t-2036.844 - 37.333
test-t-20 --race11.793 - 12.520
12:44
pmurias nine: in the case when the same string needs to be reused aren't we assumping how memory is stored on the underlying VM? 12:46
nine: what if the storage inside the buffer gets moved around by a GC?
nine pmurias: that....sucks 12:52
I guess there's 2 ways out of that: 12:55
* require the VM to provide stable pointers (e.g. have it promote the objects to gen2 if they're not already there) 12:56
pmurias I'm not sure how Moar works inside, but baking VM details into semantics is double-plus-ungood
nine * require the user to explicitly-manage() such objects and provide a .free() method for those pointers.
pmurias requiring precise GC semantics won't be portable 13:00
nine pmurias: is requiring the VM to provide access to malloc() + memcpy() portable? 13:04
pmurias nine: more so 13:06
nine Btw. reading the NativeCall code for JVM, the whole CStr mess makes a lot more sense. 13:08
Looks like the design has been ported to MoarVM without taking account of the differences. 13:09
I think on the JVM explicilty-manage() does in fact work as intended. 13:12
But again the code assumes certain behavior of the VM's GC.
pmurias where is explicitly-manage implemented in rakudo? 13:16
nine github.com/rakudo/rakudo/blob/mast...l.pm6#L628
pmurias is confused why he couldn't find it with ack ;) 13:17
nine maybe you acked in src/ but not in lib/? 13:18
pmurias re assuming certain behaviors of the VM's GC, even if you make wrong assumptions such things can work most of the times ;) 13:22
using manually free'ed objects sometimes works too 13:24
nine So in the interest of VM portability and maybe performance it'd be best to require the user to explicitly-manage() objects before passing them to a suite of functions that expect the pointers to be stable. 13:27
The downside is that there's nothing forcing the user to do that or alerting her, when she forgot to do that. And things will work almost all the time anyway. 13:28
pmurias we could mark API arguments that are expected to be stable pointers and only accept explicitly-managed objects there 13:33
nine So explicitly-manage() would return a StablePointer or some such instead of just a Pointer. 13:34
And the native sub can require a StablePointer. 13:35
pmurias yep
nine Or probably even better a "Pointer is stable". As that trait can be applied to other types like utf8, too. 13:39
Updated the document: gist.github.com/niner/53c4da135580...05a1d7895b 13:46
nine Btw. this will require surprisingly much coding effort to support such fringe use cases... 13:57
pmurias nine: if it's a fringe use case maybe just offering: a &explicitly-manage($thing-to-malloc-and-memcpy) and &free would be enough 18:14
Geth rakudo: 1937fe29fe | (Nick Logan)++ | docs/release_guide.pod
Revert "Remove chromatic as release manager of 2009.12 release"

This reverts commit 656b0730f9a1ef1bf1c0d99e9c4d1bc59518c256.
19:17
rakudo: 39db408a10 | (Nick Logan)++ | 4 files
Revert "Further remove chromatic's participation in Perl 6"

This reverts commit 607ac1541f73c38517de96300918da6c254f7c5c.
lizmat Nick Logan++ (just beat me to it) 19:19
Geth nqp: ae6ee01ac1 | (Samantha McVey)++ | t/nqp/019-file-ops.t
Fudge test for release see issue #274
19:30
synopsebot NQP#274 [open]: github.com/perl6/nqp/issues/274 t/nqp/19-file-ops.t failure in pre-2016.01
samcv restarting the moarvm travis. if that passes i will release 19:31
samcv build passed. commening release of 2018.08 19:57
MoarVM 2018.08 is now released 20:09
AlexDaniel
lizmat samcv++ 20:33
jnthn samcv++ 20:39
jnthn waves tiredly after a long day of travel :)