github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:59 lucasb left 01:27 ggoebel__ left 01:41 MasterDuke left 01:46 ggoebel__ joined 03:58 coverable6 left, nativecallable6 left, committable6 left, statisfiable6 left, greppable6 left, benchable6 left, unicodable6 left, quotable6 left, squashable6 left, releasable6 left, shareable6 left, bisectable6 left, linkable6 left, bloatable6 left, evalable6 left, tellable6 left, sourceable6 left, notable6 left, evalable6 joined, benchable6 joined, statisfiable6 joined, shareable6 joined, coverable6 joined, notable6 joined 03:59 bloatable6 joined, quotable6 joined, tellable6 joined, linkable6 joined 04:00 releasable6 joined, greppable6 joined, committable6 joined, nativecallable6 joined, squashable6 joined, unicodable6 joined, bisectable6 joined 04:01 sourceable6 joined 05:01 quotable6 left, notable6 left, releasable6 left, greppable6 left, evalable6 left, bloatable6 left, linkable6 left, shareable6 left, unicodable6 left, statisfiable6 left, squashable6 left, benchable6 left, sourceable6 left, tellable6 left, committable6 left, coverable6 left, nativecallable6 left, bisectable6 left, evalable6 joined, bisectable6 joined, benchable6 joined, linkable6 joined, greppable6 joined, notable6 joined 05:02 committable6 joined, squashable6 joined, bloatable6 joined, coverable6 joined, unicodable6 joined, nativecallable6 joined, quotable6 joined 05:03 releasable6 joined, sourceable6 joined, tellable6 joined, shareable6 joined 05:04 statisfiable6 joined 09:37 MasterDuke joined
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
12:40 MasterDuke left 13:42 leont joined 13:53 ggoebel__ left 14:05 MasterDuke joined 14:27 patrickb joined
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
16:33 MasterDuke left
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
16:33 MasterDuke joined
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
16:54 [Coke] left 17:05 domidumont joined
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
18:40 zakharyas joined 19:13 domidumont left 20:48 MasterDuke left 20:56 Ven_de_Thiel joined 21:01 MasterDuke joined 21:13 ilogger2 joined 21:25 Ven_de_Thiel left 21:57 leont left 21:59 patrickb left 22:01 zakharyas left

Powered by Cro and the Raku® Programming Language.

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

Thank you!