00:00 vendethiel joined 02:21 vendethiel joined 06:52 lizmat joined 06:56 FROGGS joined 07:01 Ven joined 07:06 zakharyas joined 08:06 FROGGS joined 08:11 colomon joined
masak question: does moar implement its own hashes nowadays? 08:34
I know it used to use uthash
no, looks like we're still on uthash 08:36
FROGGS a modified uthash
masak oh, ok.
FROGGS masak: read 6guts.wordpress.com/2015/05/15/las...any-fixes/
masak so what was it that changed exactly, wrt ordering?
oki. thanks. 08:37
pardon me for saying this. sometimes as I read the MoarVM C source code, it has a very OO feel to it. :) 09:39
even though it's just regular non-OO C.
I wonder what causes that. 09:40
partly, I think, it's that the MVM_* prefixes feel like namespacing, by convention binding some functions to some structs. 09:44
FROGGS ohh, there is OO stuff
like you call methods on a REPR, given a certain object 09:45
masak right, exactly.
though that example cheats a little bit, since anything MOP-related is bound to look like OO because... it is :P
but I mean that the rest does, too. 09:46
to be specific, it looks more OO-y than what little C code I've written in my life.
09:58 colomon joined 10:15 brrt joined 10:52 lizmat joined 11:08 Ven joined 11:34 vendethiel joined 12:08 vendethiel joined 12:30 kjs_ joined 12:34 kjs_ left 12:44 Ven joined, brrt joined
dalek arVM: fc28f88 | timotimo++ | src/ (3 files):
jit throw[cat]{dyn,lex,lexotic}

currently hangs execution.		 12:45
12:46 dalek joined
brrt shouldn't dalek say something about a merge 13:04
it is a merge 13:05
arnsholt It usually does, but I think it has to infer that it's a merge from the data it receives 13:08
In this case, it sent too many messages to the server in too little time and was killed by the server
Not uncommon when you push several commits at once 13:09
brrt the thing is, it doesn't *have* to infer that, as a merge commit always has more than one parent 13:15
FROGGS brrt: it just checks if there are more than N commits, and then prints a single line mentioning a heuristic branch merge 13:26
brrt can we change the implementation of dalek? 13:29
FROGGS I think so... lemme check 13:32
brrt: github.com/perl6/infrastructure-do....pod#dalek 13:36
if (@{ $blob->{commits} } > 15) { 13:38
common::put(\@tgt, "Heuristic branch merge: pushed " . @{ $blob->{commits} } . " commits to $project by " . $blob->{pusher}{name});
so yes, we can change that
brrt yay 13:50
brrt kind of likes the perl5 style 'this ref is an array in scalar context' syntactic magic in that line 13:51
but i have to go now
bbiab
FROGGS brrt: but there is not a clean flag in the json blurb that highlights merge commits 13:52
masak waitwait -- so, all this time dalek has been unable to tell when something's a merge simply because its author didn't know Git? 14:51
PerlJam ... and no one itched enough to scratch by looking at dalek source closely. 15:23
brrt++ though 15:24
17:12 vendethiel joined 17:35 FROGGS joined 17:48 vendethiel joined 18:44 lizmat joined 19:06 vendethiel joined 19:15 Peter_R joined
jnthn evening, #moarvm 19:37
timotimo welcome back, Mister Jnthn!
(english doesn't really have a miss/misses equivalent for men, so ...)
jnthn: i was the one who told you to post the patch you had so far for the concurrency stability fixes, but i ended up not looking at that patch at all ;( 19:39
japhb jnthn! Good to see you again. How was (and where were) the festivities? 19:42
jnthn japhb: They were in Kherson, and they were really great. :) 19:44
timotimo: Well, maybe I'll get to that tomorrow amongst new apartment stuffs :)
19:45 zakharyas joined
japhb Southern Ukraine? Is that where the newly-minted spouse is from? 19:45
Also, congrats again! 19:46
Where are you moving to?
jnthn japhb: Indeed
japhb: Prague
japhb Still going to work for Edument?
jnthn Yes, though a new branch of it in .cz (and, yes, we'll be hiring :P)
japhb Are you the first employee there? :-) 19:48
jnthn Yes :)
timotimo pretty neat 19:49
jnthn Yes :)
timotimo i would be interested in becoming an edument employee if i had teaching skills 19:50
jnthn timotimo: We don't *just* do teaching, we build stuff too 19:51
timotimo ah 19:52
hmm
so there's even positions where traveling a lot wouldn't be necessary?
anyway, BBIAB 19:53
jnthn timotimo: Yes, there's already a couple of folks who have such an arrangement. 19:55
FROGGS hi jnthn 19:56
jnthn git pulls nqp and hopes he won't have to pull stage0 updates over Edge... 19:57
o/ FROGGS
*phew*, didn't
interp.c
src\core\interp.c(4768) : error C2036: 'void *' : unknown size
src\core\interp.c(4775) : error C2036: 'void *' : unknown size
oops?
Whozdunnit? :)
FROGGS jnthn: github.com/MoarVM/MoarVM/commit/bf...79bf57af14 19:59
jnthn ugh, github + edge = slow 20:00
uh, yes, it actually does pointer arith on a void pointer. D'oh. 20:01
I...didn't know that compiled *anywhere*
20:01 brrt joined
jnthn Does anyone know the semantics it actually compiles with somewhere? :P 20:01
brrt \o jnthn 20:03
jnthn I'm guessing char *
From the code
brrt congratulations are in order i suppose :-)
jnthn o/ brrt
:) 20:04
brrt thinks gcc treats void* as char* 20:05
and wonders what other ways there'd be to do it 20:06
jnthn
.oO( "latin corn gas out" would be out of order... )
brrt but .cz, very nice
so yes, char* is correct 20:07
jnthn Goodness, bigintops.c is very upset too
brrt yes. timotimo spent some time trying to get &next to inline and concluded (or theorized) that it didn't happen because different equal P6int objects were logged as unequal 20:08
because they didn't enter the int cache
and so forced them into the int cache with arithmetic ops
jnthn mp_int *tmp[2] = { NULL, NULL }; \ 20:10
I think that's the line that upsets it
20:10 vendethiel joined
japhb jnthn: Did you ever post somewhere the Evject module from the last section of your objects intersect concurrency talk? 20:12
brrt thinks msvc is being maybe a bit too picky
by the way, haven't they (MS) open-sourced that yet?
jnthn oh, I misread... 20:13
It was an easy fix when I looked at the correct macro :) 20:14
japhb: Um...I'm not sure I did
japhb Er ... can you? :-D
brrt oh, i have another question. where... could one implement e.g. isatty
because in src/io/io.c we work on MVMOSHandles which are fully abstract 20:15
and there doesn't seem to be an easy way to get a file handle that fore sure has either a regular fd integer or an uv_file_t 20:16
jnthn japhb: Not in a very orderly way, but gist.github.com/jnthn/da27ded3fbf06df7c54a
timotimo damn, on my machine i didn't get big chunks of errors 20:17
jnthn brrt: It'd probably need to be behind the abstraction
brrt on your machine you don't have msvc :-P
timotimo i shall fix that tonight
well, it's still not supposed to be upset :(
brrt then it'd go in MVMIOSyncReadable i presume?
hardly the one-liner i'd expected 20:18
dalek arVM: 97f62b8 | FROGGS++ | src/6model/reprs/C (2 files):
allow str type in attrs in CStruct and CUnion
brrt (the fix for adding isatty i mean)
japhb jnthn: OK, thank you. :-)
FROGGS the patch will fix this: 20:19
m: use NativeCall; class Foo is repr<CStruct> { has str $.bar is rw }; my $foo = Foo.new(bar => "bar"); say $foo; $foo.bar = "baz"; say $foo
camelia rakudo-moar c2a57e: OUTPUTĀ«CStruct: invalid native binding to object attributeā¤ in block <unit> at /tmp/g_73EDiX6z:1ā¤ā¤Ā»
dalek arVM: 6211ce4 | jnthn++ | src/ (2 files):
Fix build on MSVC.
FROGGS jnthn: still builds on linux fwiw
jnthn brrt: Hm, that doesn't feel quite like it fits... 20:20
brrt: But there sn't a better hook to hang it off at the moment, I don't think
brrt doesn't know, either 20:39
eof hangs on MVMSyncReadable, and isatty is similar....
actually, hang on, that's wrong
isatty should hang on MVMIOSyncWritable if anything 20:40
hmm 20:41
no, it is actually independent
jnthn Yeah, that was my conclusion too...
brrt (stdin and stdout can both be tty-ish)
jnthn Also there are things you cna do with something that *is* a tty 20:43
brrt aye, which is why you want to know it in the first place 20:44
python, fwiw, implements isatty using a function in the os module
jnthn I wonder if we should just expose underlying file hands somehow
(descriptors I mean) 20:45
And punt such things to module space
brrt that's ok with me too, but MVMOSHandle's can be anything
timotimo well, there's ioctls and such that you may want to call on given file handles
even more so for sockets
jnthn Sure, but an os_handle function on the IO vtable could cut it
brrt yes. or we could do the parrotty thing and get the fd as a getint reprop :-P 20:46
jnthn no, we couldn't :P 20:47
We're meant to make different mistakes :)
In a few years, of course, non of the IO stuff should be written in C, but all written in NQP and using well-optimized native calling into C code on all the platforms that matter. :) 20:48
*none
But we're not ready for that yet. :)
brrt i suppose not :-)
timotimo when we have nativecall optimized to emit extremely tight calls at the jit level (and possibly at spesh'd or even interp'd level, too, if that's at all feasible), game dev with perl6 will be much more doable 20:49
but GLR is the tighter bottleneck at the moment, i think 20:50
jnthn *nod*
timotimo otherwise you'd be grabbing the $!storage out of your Arrays and use nqp::iter 20:51
brrt i don't think i've quite followed the whole GLR discussion 20:53
timotimo can you imagine that the send-more-money-subs benchmark has list iteration methods at the top of all the listings?
whether it be exclusive time spent or scalars or MVMCode objects allocated 20:54
there's a whole whooping lot of overhead to iterating over a non-lazy non-iterator-backed list at the moment
all for the benefit of supporting lazy/infinite or iterator-backed lists properly
and until Parcel gets done away with in some way, we have quite a lot of "coercion" calls to things like .list, .flat, ... all over the place 20:55
brrt hmmyes
is GLR part of jnthn's work, too? 20:56
FROGGS more like pmichaud++'s work atm me thinks
and TimToady++ did some (more visible) cleanup already
timotimo that's right; though TimToady ... yeah
brrt right, ok 20:59
i suppose that will cause some fallout too
FROGGS probably, yes 21:04
timotimo likely
FROGGS parenthesis need to be added or removed here an there and binding can be omitted in other places I hope 21:05
jnthn GLR ain't supposed to be part of my work.. 21:06
FROGGS gnight
jnthn 'night FROGGS
brrt goodnight 21:11
in that case it's best to keep it out :-)
22:02 vendethiel 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!