01:02 dalek joined 01:55 ilbot3 joined 03:18 TimToady joined
MasterDuke jnthn, timotimo, anybody else: i've started to experiment with making VMArray use the FSA, but have some thoughts/questions ( gist.github.com/MasterDuke17/9bd82...0210817b32 ). any comments/suggestions/etc are much appreciated 04:15
jnthn, timotimo, anybody else: another question that i asked in #perl6-dev, but probably got lost in the noise: any reason the id created by nqp::objectid couldn't be a string? it's usually used as a string in rakudo, and it causes a bunch of coerce_I_s (or something like that), which means a lot of temporary allocations of mp_ints 04:46
05:22 domidumont joined 05:27 domidumont joined 05:34 brrt joined
brrt good hi 05:39
MasterDuke: that's because it is the integer value of a pointer (if it lives in the second generation memory space; if not, a pointer is provided for it) 05:42
i just realized that there is actually no reason at all to maintain a two-phase JIT compiler structure in the legacy JIT 06:02
we could without loss of effectiveness generate bytecode in a single step 06:05
this would, of course, break nine++s work 06:07
although i know how to fix that
06:21 domidumont joined 06:29 domidumont joined 06:49 brrt joined 07:33 zakharyas joined 08:08 dogbert2 joined 08:33 leont joined
samcv good hi brrt 08:57
brrt good hi samcv 08:59
09:04 Skarsnik joined 09:09 ggoebel joined
jnthn morning o/ 09:11
lizmat jnthn brrt samcv o/ 09:12
nwc10 good *, jnthn
lizmat jnthn: do you remember offhand how to generate the "container_initializer" case in the BUILDALLPLAN logic ? 09:14
jnthn my %h is BagHash probably does it 09:15
lizmat checks
doesn't look like it 09:16
jnthn oh 09:17
has %!h is BagHash of course
lizmat ack
lemme check
yup, that's the one 09:18
samcv jnthn, so i'm gonna push a fix making ignoremark work for Prepend graphemes :)
very shortly
jnthn MasterDuke: That sounds more like we'd be better off trying to make coercion cheaper, but in the long run we'll be better off having them as integers once object hashes and ObjAt finally get the re-working they need 09:19
samcv if we have: Prepend Extend and no base character, should our base be the first codepoint by default?
jnthn samcv: Sounce nice :)
samcv code i currently have would put the base codepoint after the first Prepend character
jnthn samcv: Yeah, that sounds like a reasonable degenerate thing to do
samcv yeah 09:25
and it doesn't do this if it's making a utf8_c8 one 09:26
oh one big issue that i sorta wanna fix is utfc8 strings altering under concatenation when re_nfg gets run :\
jnthn Urgh, yeah, that shouldn't happen
samcv i mean there's nothing to stop it really 09:27
it iterates by codepoint :\
jnthn Ah :/
samcv i mean do we need a setting on the codepoint iterator so that it'll passback synthetics?
i.e. the only negative numbers we get back ARE utf8_c8 graphemes
jnthn Maybe
samcv that seems the simplest way to do it 09:28
jnthn Though it'd want to be turned on explicitly just for these cases
Or even be a slightly different iterator
Probably the latter
It's extra code, but it's worth it given how encoding is a hot path for I/O
samcv well when do we want to iterate by codepoint and destroy utf8_c8?
is there ever places we *want* that?
jnthn Encoding
samcv it'd be simple enough to add an item to the MVMCodepointIter struct 09:30
so we initialize the CI and then do ci->utf8_c8_synths_literal = 1
or pass it along as another option, would be another option
jnthn Yes, I know it's simpler, but it's an extra check on every single codepoint we would encode
samcv ok that's fine with me 09:31
jnthn Those add up
Maybe it's only the "give me a codepoint" function that needs to be different anyway?
And the rest are shared 09:32
Then it's just a different function to call and no state
samcv yeah that's fine
and the MVM_string_grapheme_ci_get_codepoint can be simplified now that it's all one array
but i changed that and it broke some things so i decided to fix the Prepend stuff first then get back to it 09:33
since it works fine now. it just uses the old semantics with base_code but we can eventually remove that from the codepointiter struct and the MVM_string_grapheme_ci_get_codepoint
jnthn Yeah, that'd be a nice simplification :) 09:34
Well, perhaps. otoh when the base char was the first one we were typically on a different codepath anyway
But as soon as it's not, then it's a simplficiation :)
samcv what do you mean 09:36
i mean that can all be removed. getting the first codepoint can be just like the ones afterward
and make the init function simpler too
and when it gets to the next grapheme 09:37
setting it up to pass back cp's
jnthn Yes, agree it can all be removed, just saying that it was less of a difference when the base char was always the first char 09:39
And that the way you're heading is notably cleaner 09:40
now that this isn't ture
samcv ah oh i think i get what yo umean
jnthn Because of prepends
samcv back in my day there were no such thing as prepends! damn kids get off my lawn
geekosaur ą¶ 09:42
Geth MoarVM: Skarsnik++ created pull request #687:
Nativecall code : fix invalid pointer creation		 09:44
10:03 brrt joined 11:30 brrt joined
nine jnthn: regarding those superfluous initializations with NULL. Those look like down right trivial for a compiler to optimize away. Maybe it's not a bad idea to have those in the code as a defense for future refactorings? 11:48
samcv i'm getting a doublefree or corruption 11:54
gist.github.com/56f26d9365ca9a5800...c2f0cc4d71 here's the backtrace
looks like maybe a JIT thing? jnthn thoughts? 11:55
===> Testing: HTTP::Request::Supply:ver('0.1.1'):auth('github:zostay')
*** Error in `/home/samantha/perl6/bin/moar': double free or corruption (fasttop): 0x000000000553ef70 ***
timotimo asan or valgrind should be able to help here 11:56
MasterDuke samcv: does it go away if you MVM_JIT_DISABLE=1 or MVM_SPESH_DISABLE=1?
timotimo: btw, any thoughts on my fsa realloc question? 11:57
samcv gonna check
nine set_size_internal again? That looks suspicious 11:59
11:59 AlexDaniel joined
MasterDuke did anybody see what ugexe was trying in #perl6-dev last night? irclog.perlgeek.de/perl6-dev/2017-...i_15144869 12:00
timotimo your gist looks good, MasterDuke
MasterDuke timotimo: cool, i've never worked with a fixed size allocator before, hoping i wasn't too far off base 12:01
however, what i described seems like it will cause a lot of memcpy's. is that required? or is there a way to grow a bin into the next size without copying? 12:04
timotimo not possible
there's allocation schemes that could conceivably do this, but we're not using any of those 12:05
MasterDuke oh well
samcv not happening anymore 12:07
but it happened like 3 times. and now not
jnthn nine: I can live with them, they just always strike me as superstitious and make me zone in when reviewing. Like, "did the author really understand the control flow here" kinda thing. 12:10
As to memcpy on growth - once we reach a certain size we're not using the FSA any more, and before that point the copies are small 12:14
MasterDuke jnthn: true. did you have a look at what i wrote? 12:16
jnthn Yeah. My feeling is that we should provide a realloc function on the FSA API 12:17
Plus a _safepoint variant of it too
That way we can encapsulate the FSA-related (does it fit the bin? is it overflow so we can just MVM_realloc?) inside of fixedsizealloc.c 12:18
We'd need to pass the old size and the new size
MasterDuke MVM_fixed_size_realloc that uses MVM_fixed_size_free and MVM_fixed_size_realloc_at_safepoint that uses MVM_fixed_size_free_at_safepoint?
jnthn Yeah 12:19
timotimo if we only ever grow the storage we'll never accidentally write outside if we read an out-of-date size value
MasterDuke jnthn: yep, i have a dead simple MVM_fixed_size_realloc that takes old and new sizes and just does MVM_fixed_size_alloc, memcpy, MVM_fixed_size_free 12:20
jnthn MasterDuke: Right. That works. But for the case it's an overflow we can cheat :)
As in, delegate to MVM_realloc
Need to make sure that path does something sensible when MVM_FSA_DEBUG or whatever it's called is turned on also (probably just tweak the size) 12:21
In the longer run...
MasterDuke yep, that's what i was going to work on next, but wanted to make sure i had the various cases thought out correctly
jnthn VMArray should switch to allocating a block of memory that *includes* the ssize and the element storage
And reads it once per operation
And bounds checks against *that*
And uses the fixed point free mechanism
samcv star: use JSON::Fast:ver<0.1..*> 12:22
camelia ===SORRY!===
Could not find JSON::Fast:ver<0.1..*> at line 1 in:
/home/camelia/.perl6
/home/camelia/star-2017.07/share/perl6/site
/home/camelia/star-2017.07/share/perl6/vendor
/home/camelia/star-2017.07/share/perl6
CompUnit::Rā€¦
jnthn That way we can make MVMArray threadsafer
samcv star: use JSON::Fast:ver<0.1+>
camelia ===SORRY!===
Could not find JSON::Fast:ver<0.1+> at line 1 in:
/home/camelia/.perl6
/home/camelia/star-2017.07/share/perl6/site
/home/camelia/star-2017.07/share/perl6/vendor
/home/camelia/star-2017.07/share/perl6
CompUnit::Repā€¦
samcv star: use JSON::Tiny:ver<0.1+>
camelia ===SORRY!===
Could not find JSON::Tiny:ver<0.1+> at line 1 in:
/home/camelia/.perl6
/home/camelia/star-2017.07/share/perl6/site
/home/camelia/star-2017.07/share/perl6/vendor
/home/camelia/star-2017.07/share/perl6
CompUnit::Repā€¦
samcv star: use JSON::Fast
camelia ( no output )
samcv star: use JSON::Fast:ver<0.0.1+> 12:23
camelia ===SORRY!===
Could not find JSON::Fast:ver<0.0.1+> at line 1 in:
/home/camelia/.perl6
/home/camelia/star-2017.07/share/perl6/site
/home/camelia/star-2017.07/share/perl6/vendor
/home/camelia/star-2017.07/share/perl6
CompUnit::Rā€¦
samcv star: use JSON::Fast:ver<0.0.1..*>
camelia ===SORRY!===
Could not find JSON::Fast:ver<0.0.1..*> at line 1 in:
/home/camelia/.perl6
/home/camelia/star-2017.07/share/perl6/site
/home/camelia/star-2017.07/share/perl6/vendor
/home/camelia/star-2017.07/share/perl6
CompUnit:ā€¦
jnthn nine: fwiw, github.com/MoarVM/MoarVM/commit/f9...1351ca6058 seems to be causing Windows build issues 12:24
I might be able to track that down at home some evening this week
If not we should revert it ahead of the monthly release
MasterDuke m: use nqp; my str $a = nqp::objectid(1); say $a 12:28
camelia 45859896
MasterDuke m: use nqp; my Str $a = nqp::objectid(1); say $a
camelia Type check failed in assignment to $a; expected Str but got Int (56132664)
in block <unit> at <tmp> line 1
MasterDuke str is ok? 12:29
lizmat MasterDuke: natives int auto-coerce to native strings in nqp land 12:30
m: my str $a = (my int $ = 42); dd $a 12:31
camelia "42"
MasterDuke i thought pmurias was asking about that recently for rakudo-js and jnthn said it shouldn't be allowed 12:32
12:35 zakharyas joined
jnthn No, that shoudln't happen 12:37
Something is being rather too leninet
Maybe for the same of NQP
*sake of
But still, should really be fixed in Perl 6
MasterDuke heh, guess i shouldn't use that to reduce the number of MMV_bigint_to_str calls because of nqp::objectid then 12:38
jnthn bigint_to_str may be optimizable for the case of sufficiently small values 12:40
Like, those that ain't actually big
samcv ok i got the crash again 12:42
gonna try with MVM_SPESH_DISABLE=1
MVM_SPESH_DISABLE=1 makes it not crash 12:45
nine jnthn: I know, but I have no idea how it could go that wrong :/ I do hope another set of eyes finds the reason. I'd guess it's some misunderstanding about C on my part which is why it's not visible to me. 12:53
jnthn I didn't immediately spot it either.
Will have another look 12:54
nine jnthn: well, does my fix even make sense? :)
12:55 Skarsnik_ joined
jnthn The original patch, or some other follow-up one? 12:56
MasterDuke jnthn: MMV_bigint_to_str has a fast path for the case of actually-small ints, but i don't think it's getting hit in this case
nine jnthn: f9b65a9e37979ab39fd1283a65ad4e1351ca6058
jnthn I wonder if 1UL has to be 1ULL or some such 12:57
That's the first thing I'll probably try 12:58
nine ULL would indeed be the proper suffix for a 64 bit literal 12:59
"To specify a 64-bit integral type, use the LL, or ll suffix." msdn.microsoft.com/en-us/library/c70dax92.aspx
jnthn Sounds like it's that, then
nine Build fails: src/strings/unicode.c:78279:43: error: unknown type name ā€˜sub_nodeā€™ 13:05
MVM_STATIC_INLINE MVMint64 next_node_min (sub_node node) {
samcv: ^^^
Apparently just removing that file fixes it 13:07
Geth MoarVM: d78c3707a4 | (Stefan Seifert)++ | src/6model/reprs/VMArray.c
ULL is the proper suffix for a 64 bit integer literal

  "To specify a 64-bit integral type, use the LL, or ll suffix."
  msdn.microsoft.com/en-us/library/c70dax92.aspx
May fix #686 "Unable to allocate an array of 8 elements" on Windows
  Thanks to jnthn++ for the hint!		 13:15
nine Stupid Github. When I write "Fixes GH #123", it does't do anything. But when I write "May fix #686" the issue gets auto closed. 13:16
samcv nine, the file unicode.c should generate when you run make
anyway i gotta go to bed guys. see you tomorrow
nine Good night!
13:32 brrt joined
brrt so, what was broken? 13:38
nine brrt: where? 13:39
brrt in ehm, the JIT 13:40
13:40 cognominal joined
nine I don't think there was something about the JIT. 13:44
timotimo i had to rm unicode.c for some reason :(
maybe it also has to have a dependency on the generator script or something? 13:45
nine And it wasn't even my fix in set_size_internal that caused breakage. It just exposed a second bug in that line :)
brrt okay, that'sā€¦ good, maybe 13:49
14:09 brrt joined 14:11 Skarsnik_ joined 14:13 Skarsnik__ joined
dogbert17_ jnthn: have you tried running t/spec/S02-lexical-conventions/unicode-whitespace.t with MVM_SPESH_NODELAY=1? I get a lot of failures if I do that. 14:33
jnthn I've run all spectest with that + MVM_SPESH_BLOCKING quite recently. Didn't see anything from that. 14:36
Well, except a couple of cases that are about backtrace lines missing
dogbert17_ the thing which makes this interesting is that the failures vanishes if I add MVM_SPESH_BLOCKING=1 14:38
14:40 domidumont joined 14:52 domidumont joined
ugexe if some perl6 code segfaults does that always mean a fix is appropriate for moarvm? or can the proper fix still apply to nqp or perl6 land? 15:04
15:06 brrt joined
jnthn Unless it's using NativeCall, we'd pretty much always want to fix it in MoarVM 15:13
There's two big known ways to get a SEGV out of MoarVM 15:14
Which are to abuse VMArray and VMHash from multiple threads respectively
timotimo right, NativeCall is simply the opposite of memory-safe
ugexe i see. yeah, this is a VMArray/threads thing 15:21
when i removed the segfaulting code from a loop it turned into nqp errors, so I wasn't sure 15:23
er, removed the loop surrounding segfaulting code
15:26 brrt joined 16:02 Ven`` joined 16:05 brrt joined 16:11 brrt joined 16:24 brrt1 joined 16:25 dogbert17 joined 16:31 nwc10 joined 16:36 domidumont joined 16:58 robertle joined 17:38 ggoebel joined 17:44 zakharyas joined 18:56 ggoebel joined 19:07 AlexDaniel joined 19:20 hoelzro joined 19:21 robertle joined
Geth MoarVM: 22000677e9 | Skarsnik++ (committed using GitHub Web editor) | src/core/nativecall.c
Nativecall code : fix invalid pointer creation

This fix what is probably an extra indirection. If I understand this correctly cptr is the address of a field inside a CStruct, the previous code was assigning to cptr the value of the field. This make efence/valgrind/asan happy (fix an invalid read size of 8 errors message in this function) The uintptr _t cast are to respect www.securecoding.cert.org/confluen...to+pointer
All nativecall tests in rakudo still run fine with this fix		 19:39
MoarVM: 238f67e49c | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/core/nativecall.c
Merge pull request #687 from Skarsnik/patch-2

Nativecall code : fix invalid pointer creation
20:19 solarbunny joined 20:31 JimmyZ joined, leedo joined 20:33 ilmari[m] joined
lizmat jnthn: moarvm.org still doesn't show 2017.08 on the home page ? 20:40
dogbert17 stupid question, will any of the three conditional statements here ever be true given that the offset fields are unsigned? github.com/MoarVM/MoarVM/blob/mast...gen.c#L299 21:17
21:18 ugexe joined
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2017/09/11/...ng-sorted/ 21:18
dogbert17 lizmat++ and I haven't even read it yet :)
21:31 nativecallable6 joined, releasable6 joined, zakharyas joined
jnthn lizmat: oops, though tbh the incentive to fix that is low given it'll last 4 days... 21:41
Release was right as I was prepping for SPW, so...
lizmat++ # pun title of weekly
lizmat yeah, but I'm linking to it from the P6W... so maybe that's an incentive ? :-)
jnthn fwiw, I'm not on perl6-users but the answer to www.nntp.perl.org/group/perl.perl6...g4237.html is that the close ain't required 21:44
Also I can't believe someone had the discipline to write an example with the words "Ring ring" without sticking "bananaphone" in somewhere... 21:45
geekosaur if you're old enough you switch to liza minelli instead >.> 21:47
lizmat jnthn: answered on perl6-users 21:49
jnthn To who? :D 21:50
lizmat the list 21:51
jnthn I was replying to geekosaur :-) 21:56
dogbert17 figured out the answer to his own question
22:17 committable6 joined 22:23 nwc10 joined
timotimo jnthn: any good ideas for an API to tell the heap snapshot profiler to only do major collections? i'm gravitating towards just an env var rather than giving the HLL::Compiler Yet Another Flag starting in --profile 22:35
jnthn timotimo: We could expand existing syntax 22:42
--profile=heap is what we have today
But we could 22:43
--profile=heap;key=value,key2=value2 or some such
timotimo definitely could 22:44
and then just put all of it into the config hash
jnthn Right
timotimo i'm thinking i don't wanna install these as constant strings in the moar instance
just turn them from c string into moar string right then and there :P
oh! i didn't know about profile-stage 23:47
but it doesn't pass the profile type on 23:48
23:59 MasterDuke joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!