github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:19 Kaypie joined, p6bannerbot sets mode: +v Kaypie 02:05 lucasb left 03:40 leont left 05:55 Kaypie left 05:57 Kaiepi left, Kaiepi joined 05:58 p6bannerbot sets mode: +v Kaiepi 06:04 Kaypie joined 06:05 p6bannerbot sets mode: +v Kaypie 06:08 Kaypie left, lizmat left
Geth MoarVM: 05384f2150 | (Petr Rockai)++ | src/io/filewatchers.c
Add a cancel handler for filewatch tasks

Without this, MVM_OP_watchfile is bound to leak a file descriptor and/or other resources (depending on the platform). Stopping the libuv fs_event in the cancel op allows rakudo to nqp::cancel the task and thus prevent the leak.		 08:31
MoarVM: 1d9a71c7cd | niner++ (committed using GitHub Web editor) | src/io/filewatchers.c
Merge pull request #1014 from mornfall/master

Add a cancel handler for filewatch tasks
MoarVM: 1c3b0c936a | (Stefan Seifert)++ | lib/MAST/Nodes.nqp
Fix label id clash in bytecode compiler

It was possible that a label got created that got the exact same objectid as a previously existing label that has since been freed by the GC. To avoid this, keep a list of all added labels in the frame alongside the lookup hash for labels.		 08:47
08:47 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci MoarVM build passed. niner 'Merge pull request #1014 from mornfall/master 08:47
travis-ci.org/MoarVM/MoarVM/builds/465547314 github.com/MoarVM/MoarVM/compare/d...9a71c7cdf3
08:47 travis-ci left
nine No Geht? 09:08
09:23 domidumont joined, p6bannerbot sets mode: +v domidumont 09:33 domidumont left 09:34 domidumont joined 09:35 p6bannerbot sets mode: +v domidumont 09:36 domidumont left 09:41 domidumont joined, p6bannerbot sets mode: +v domidumont 09:57 mornfall joined 09:58 p6bannerbot sets mode: +v mornfall 09:59 dalek left 10:01 Geth left
nine Oh boy...fixing the writeuint flags issue is even harder cause of nqp's stage0 10:24
10:28 lizmat joined, p6bannerbot sets mode: +v lizmat 10:35 lucasb joined, p6bannerbot sets mode: +v lucasb 11:49 robertle joined 11:50 p6bannerbot sets mode: +v robertle
nine That's solveable at least. I can have an in-between version in MoarVM that treats flag values where BINARY_ENDIAN_LITTLE (1) is set as the new kind and where it's missing as the old one. All current users are missing that flag despite wanting it. 11:56
12:30 leont joined, p6bannerbot sets mode: +v leont 13:02 brrt joined 13:03 p6bannerbot sets mode: +v brrt
brrt ohai #moarvm 13:04
I have a fix for the dynasm bug in which we'd misencode some SSE instructions with variable registers 13:05
jnthn brrt: Sounds good :) 13:09
That unblocks float stuff on template JIT, maybe?
brrt a bit
I need to do a bunch more work for the linear scan allocator
but it definitely helps :-) 13:10
jnthn ah, I see
brrt hmm, actually, now that I think about it, it was necessary 13:13
because the rex byte can also be inserted if we have a rex-requiring secondary operand 13:18
13:38 brrt left 14:06 brrt joined 14:07 p6bannerbot sets mode: +v brrt
brrt the register allocator is kind of a hard bit of code... 14:19
mornfall (says so in the docs too) 14:49
brrt hehe 14:53
yeah
I wrote that
So I hope that you take that with some grains of salt
I'll be honest, I am a huge C fan, but I'm not entirely convinced that C is the right language for this job 15:02
timotimo looking forward to your article titled "C considered harmful" 15:11
brrt but I like C.... 15:13
And I'll be more likely to say 'foolishness considered harmful but necessary'
.... no, what I find harmful, is the following set of ideas: 15:15
- 'you should $safe-language always because CVE'
- 'you should use $dynamic-language always because machines are cheap' 15:16
- 'you should use C++ always because fast'
mornfall well, it's hard to write plumbing for $dynamic-language in $dynamic-language
15:17 Kaiepi left
brrt that's mostly because a bunch of the plumbing for $dynamic-language has been written in something like C 15:17
15:17 Kaiepi joined
brrt and doesn't provide much of the necessary access to the underlying systme 15:18
and there's no reason why that should be so, except conventions
15:18 p6bannerbot sets mode: +v Kaiepi
mornfall well, bootstrapping is hard, so there's that 15:20
brrt safety is hard, I think 15:21
mornfall of course, especially if you also want speed
timotimo pypy writes most of its plumbing in rpython, which is ... semi-dynamic? 15:22
brrt hmmm
timotimo but it's also a to-C compiler
mornfall isn't rpython kinda like nqp? 15:23
brrt I think rpython isn't really dynamic, it's type-inferred
timotimo yeah, it's full-program type-inferred
brrt HN comment I read argued that 'python scales better to large codebases than perl (5)', which annoyed me
because I'm fairly sure that isn't true 15:24
mornfall probably debatable
depends on who your programmers are
brrt perl5 has the advantage in that the import protocol is very hackable
timotimo i guess you can't really say "Python is better at X than *" because Python is not a single thing?
neither is Perl 5, of course 15:25
mornfall dunno, python is very hackable overall (which is what makes it slow... and making use of its flexibility makes it even slower)
timotimo except if you're using pypy in which case it's still pretty dramatically fast
mornfall it is? i wouldn't know 15:26
timotimo pypy is just frighteningly good in general 15:27
mornfall pypy doesn't seem to be terribly popular
timotimo yeah, i don't really know why that is
have you ever done 3d printing?
mornfall most python folks hate it because it defaults to python 2
and of course they want to move on 15:28
timotimo there's this piece of software called "cura" which turns 3d models into slices and paths for the printer head
and it's highly encouraged to run that with pypy, AFAIK
oh, maybe it's not cura but skeinforge that is written in pypy 15:31
er 15:32
meant to be used with pypy*
brrt counterargument: anything that you'd write in python, and need pypy for speed, why wouldn't you write that in, say, java or C#, and have the same speed at minor inconvenience 15:33
especially C#. I've come to the conclusion it is a substantially better system... 15:34
writing in C++ would be a major inconvenience, as would writing in rust, imho
mornfall one thing from C++ that i miss everywhere else is value semantics 15:35
'everything is a reference' kinda gets on my nerves
timotimo you could write it in microsoft's managed C++! 15:37
it's C++, but it's actually C#! 15:38
a friend asked me to look over a friend-of-their's C++ code which I think they were learning at university or something and I was like "this isn't like any c++ i've ever seen"
mornfall C++ has changed a lot in the last 5 or so years 15:40
brrt go has value semantics, C has value semantics (more honestly than C++ imho)
C++ references are... one of the less-good design decisions 15:41
and I agree, value semantics are very important
(C# has value types as well, I think?)
mornfall you mean unboxed stuff in C#? perhaps
timotimo mornfall: yeah, but it's still very very different from c++ :)
mornfall but you are probably not supposed to use that 15:42
java has some unboxed types too, perhaps even unboxed arrays? or used to have... it was very ugly
i didn't know about go, not having used it like ever 15:43
timotimo yeah, unboxed arrays do exist i believe
brrt C# has structs
go is awesome in all its limitations
mornfall i imagine erlang might have values
brrt and C# structs are value-typed
mornfall but i don't actually know either :)
brrt java only has reference-objects. It's a major weakness
as in, it doesn't hurt until suddenly it does 15:44
But go doesn't have 'hidden' reference types. If something is a reference, that's really quite obvious
mornfall but it seems that the whole OO world pretty much follows java and python in that objects are always references 15:45
brrt yes, mostly because that's easier for the implementation :-)
timotimo mornfall: have you ever seen something like "generic<typename T> [Serializable] public ref struct blah { ... };" in C++?
brrt go even gives you internal references
mornfall timotimo: certainly not, that's not C++ :-)
timotimo i've told you 15:46
or maybe your "C++ has changed a lot in the last 5 or so years" wasn't a reply to me
mornfall it was, but i was banking on the person in question cranking out some serious C++17 or perhaps 2a :-) 15:47
didn't know MS has created a frankenparser for half-C++-half-C# hybrid 15:48
brrt I'm wondering if I can, maybe should, implement the 'free register set' as a bitmap 15:49
I know how to implement all the relevant bits (ha ha) as a bitmap
and it has nice properties...
15:49 lizmat left
timotimo the C# parts are really mild, though. i think it's mostly "this struct shall get a GC header" and "this is a reference to a GC-managed object" and a "gcnew" in addition to "new" 15:52
15:58 lizmat joined, p6bannerbot sets mode: +v lizmat
brrt whenever you want to manage a set of a small number of integers, I'm not sure we can really do better than a bitmap generally... 16:05
16:29 brrt left 17:06 dalek joined, p6lert left, p6lert joined, Geth joined, p6bannerbot sets mode: +v dalek, p6bannerbot sets mode: +v p6lert 17:07 p6bannerbot sets mode: +v Geth 17:10 Geth_ joined, dalek left, d4l3k_ joined, p6lert left, Geth left, p6lert_ joined 17:11 p6bannerbot sets mode: +v Geth_, p6bannerbot sets mode: +v d4l3k_, p6bannerbot sets mode: +v p6lert_, d4l3k_ is now known as dalek, Geth_ left, Geth joined 17:12 p6lert_ left, p6lert joined, SourceBaby joined, p6bannerbot sets mode: +v Geth, p6bannerbot sets mode: +v p6lert 17:13 p6bannerbot sets mode: +v SourceBaby 18:02 zakharyas joined 18:03 p6bannerbot sets mode: +v zakharyas 19:52 domidumont left
nine Darn....I've let my computer compile MoarVM for a couple of hours in a mips VM, just to have it fail with a linker error: ./libmoar.so: undefined reference to `dcCallbackThunkEntry' 19:54
samcv nine, if you are trying to use big endian, an arm vm is faster as i remember 19:56
nine samcv: thanks, will try that then :) 19:57
samcv yeah. it's like 8x faster 19:58
maybe more!
i think you have to go back a debian version though 19:59
or not. maybe i misremember. maybe i'm thinking about mips
ooh. nine i'm thinking about powerpc 20:02
robertle note that most arm are little-endian, so I guess support within BE arm VMs is going to be a bit patchy as well 20:03
samcv robertle, yeah my memory was incorrect. it was the powerpc emulation that was 20x faster than mips
mips was... more than painful.
robertle s390x is a good one to hack BE stuff on as well ;)
samcv uh last release was jessie on powerpc. so that's what my memory was correct about 20:04
had to go back a debian release and it was ppc 32bit (ppc 64 on debian is little endian mode)
robertle I think it's better to use ffi on mips (regarding dcCallbackThunkEntry) 20:06
nine, do you have something concrete you want to try, or just general debugging?
nine robertle: nah, need to implement endian swapping. So probably a couple edit/test cycles involved 20:55
OTOH I could just make pmurias++ happy and write a couple of nqp tests for writeuint including endian swapping. If swapping works on a little endian machine, it's probably going to do that on big endian, too. So there's less that can go wrong. 20:57
lizmat nine: are those new nqp::ops documented?
nine lizmat: kinda: gist.github.com/jnthn/1e865a06d213...2908858a57 21:00
lizmat nine: ok, will take that and document after I've done the P6W 21:01
mornfall well you can get actual mips computers too you know :-) new, reasonably low-power, probably not much slower than a typical arm?
nine ++lizmat 21:09
21:34 robertle left 21:35 zakharyas left 21:40 AlexDaniel joined, p6bannerbot sets mode: +v AlexDaniel

Powered by Cro and the Raku® Programming Language.

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

Thank you!