github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
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
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
nine No Geht? 09:08
nine Oh boy...fixing the writeuint flags issue is even harder cause of nqp's stage0 10:24
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
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
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
brrt that's mostly because a bunch of the plumbing for $dynamic-language has been written in something like C 15:17
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
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...
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
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
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!