github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 09:43
.tell jnthn paste.scsys.co.uk/594542 -- new-disp t/02-rakudo/15-gh_1202.t ASAN excitement
tellable6 nwc10, I'll pass your message to jnthn
nwc10 not sure if that's the existing (other?) known bug - use-after-free doesbn't seem to be in new-disp code 09:44
nine So, new idea: since from a VM point of view, we don't want all that special handling of strings and from a user point of view, we're too used to using plain strings, a good compromise may be to generate coercer types when the user specifies a Str. I.e. sub foo(Str $s) is native becomes sub foo(CStr(Str) $s) 11:52
lizmat that feels like a very nice solution 11:54
and totally doable I would think with RakuAST
nine On the flip side, I'd still make those CStrs visible. I.e. class Foo is repr('CStruct') { has Str $.s; }; will be interpreted as class Foo is repr('CStruct') { has CStr(Str) $.s; } and Foo.new.s will return a CStr object 11:55
lizmat I'm not so sure you will be able to do that currently without some deep magic
nine It's already doable, since we really just take that subroutine declaration as a specification and generate the actual sub code from it.
lizmat not if you adapt the accessor as well ?
nine I think I don't want to adapt the accessor in that way. Having the CStr visible can be quite useful. 11:56
lizmat aka method s(--> Str(Cstr))
nine E.g. getting a string from a native sub and pushing it into another could avoid a costly decode/encode step
And if CStr behaves sufficiently enough like a Str, it won't matter in most cases.
lizmat wouldn't spesh be a able to eliminate that when it gets hot ? 11:57
nine That'd be very difficult
lizmat that sounds familiar :-)
nine Replacing the type with a CStr(Str) coercer type is simple for routines, but not so much for CStruct and CArray. The latter are constructed by the VM and wouldn't know about our CStr type 12:04
nine Huh.... I think the most Raku way of turning Str attributes of CStructs into CStr(Str) attributes would be a custom meta class and a corresponding keyword: struct Foo { has Str $.s } 14:47
Or maybe a method ^add_attribute is enough, similar to method ^parameterize 14:54
No, apparently one cannot just override arbitrary HOW methods that way. But then, custom meta classes are not that hard 15:06
And I'd very much like writing "struct Foo" :)
And it would be backwards compatible
dogbert2 hmm, the program with the indirect leak from yesterday only have four 'definite' leaks, two of them in NativeCall for zero (!) bytes each 15:59
how can a leak be zero bytes? 16:01
fwiw, here's the gist gist.github.com/dogbert17/07c1368b...ab2acb76a9 16:04
nine well, yes and no 16:31
with asan it's not really 0 bytes as asan actually allocates more memory than requested to store some information about where that memory was allocated
dogbert2 i actually switched to valgrind hoping to get more detailed information but perhaps valgrind behaves in the same way as ASEN 16:33
*ASAN
nine malloc may do just the same (adding some book keeping information), or it may return NULL for a zero size 16:33
dogbert2 could it have been an attempt to allocate zero bytes? 16:36
nine As we've recently discussed here: If the size of the space requested is 0, the behavior is implementation-defined: either a null pointer shall be returned, or the behavior shall be as if the size were some non-zero value, except that the behavior is undefined if the returned pointer is used to access an object.
yes
Oh, I actually recognize that one now. I already have a local patch to get rid of this :) 16:39
dogbert2 cool, nine++ 16:43
dogbert2 I believe I sort of found the memory leak from yesterday. It occurs when the code contains the line 'use Linux::Proc::Statm;' 17:21
so, I guess the following code does something strange: github.com/Skarsnik/p6-linux-proc-...c/Statm.pm 17:22

Powered by Cro and the Raku® Programming Language.

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

Thank you!