Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-10-10

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:49 mwilson_ joined #moarvm
04:55 stmuk joined #moarvm
05:41 domidumont joined #moarvm
05:47 domidumont joined #moarvm
06:14 domidumont joined #moarvm
06:39 domidumont joined #moarvm
07:19 brrt joined #moarvm
07:19 brrt hey #moarvm
07:20 brrt regarding x32 JIT; that Configure-time check is a bad solution
07:20 nwc10 good *, brrt
07:20 brrt good * nwc10
07:21 brrt (i was going to use a rather more colorful phrase regarding the Configure-time check)
07:21 nwc10 the logging is only black-and-white, so it wouldn't reproduce well
07:21 brrt true
07:21 nwc10 (it's like the ASAN output - it's so much better before it goes into a pastebot)
07:22 nwc10 anyway, what's a better solution, and why? :-)
07:23 brrt the JIT only needs to know the runtime architecture and ABI, right
07:23 nwc10 (I admit that I'm not actually going to implement this, even if you take the time to explain to *me* what would work better, but I'm hoping that someone else reading the logs will be less of a slacker than I am)
07:23 brrt in general, the Configure script is all about determining how to make something compile
07:23 brrt the ultimate test is just to compile some things (and we do)
07:23 brrt but not for the JIT
07:23 nwc10 but can the runtime architecture and ABI vary significantly from configure time?
07:24 brrt welll….
07:24 nwc10 although, yes, sigh, fat binaries
07:24 brrt yeah
07:24 nwc10 but that's probably not the common one
07:24 brrt actually, that is the common one
07:24 nwc10 I guess the useful one is "how recent is this CPU that we're actually running on"
07:24 nwc10 ah OK.
07:24 nwc10 Perl 5 fails completely at the "fat binaries" thing
07:24 brrt the uncommon one is 'I want to crossocmpile something'
07:25 nwc10 I'm not sure about the *un*common part - that seems to be more common these days as a frustration
07:25 nwc10 but I'm agreeing with you about the relevance :-)
07:26 brrt crosscompilers tend to be pro users, whereas fatbinary-compilers tend to be…. kids with macbooks :-P
07:26 brrt not that we shouldn't have that fixed
07:27 brrt it's just that I've come accross 'perl6 doesn't work' more than once where that was the problem
07:28 brrt as in, people who want to start the cross-compilation process tend to know about the compilation process in the first place. fat-binary people tend to have no idea they produced a fat binary
07:28 nwc10 ah OK. Curious.
07:28 brrt partly because apple makes making one the default, I think
07:29 nwc10 I've not been paying huge attention recently, but I'm not aware of Perl 5 builds screwing up because of fat binaries.
07:29 nwc10 It just resolutely fails to build a fat binary :-)
07:29 brrt well, that's something
07:31 nine Well at least the new check is only as bad as the old checks ;)
07:32 brrt oh certainly
07:33 brrt i'm complaining about the old checks ;-)
08:45 brrt1 joined #moarvm
12:13 brrt_shell joined #moarvm
12:18 nebuchadnezzar We have NativeCall issues on powerpc with the new packages https://buildd.debian.org/status/fetch.php?pkg=rakudo&arch=powerpc&ver=2016.09-2&stamp=1476101411
12:20 nwc10 that seems to be the only big-endian architecture in https://buildd.debian.org/status/logs.php?pkg=rakudo&ver=2016.09-2
12:24 nebuchadnezzar ppc64 is waiting moarvm build for that architecture: https://buildd.debian.org/status/package.php?p=moarvm&suite=sid
12:24 nwc10 was more that I'm curious if it's actually a more general big endian bug
12:25 nebuchadnezzar powerpc and ppc64 seems to be the only two big endian arch in https://buildd.debian.org/status/package.php?p=rakudo
12:35 brrt joined #moarvm
12:38 brrt hmm, i wonder how i'm going to like irssi
12:39 * jnthn likes it sufficiently to still be using it after a few years
12:40 arnsholt Yeah, I'm pretty happy with it too
12:43 brrt well, i'll succumb to peer pressure this case
12:43 brrt I kind of liked erc (in emacs)
12:43 brrt which I can also do, of course
12:45 nebuchadnezzar ERC++
12:45 nebuchadnezzar :-D
12:45 zakharyas joined #moarvm
12:47 arnsholt But then you have to use Emacs!
12:47 arnsholt Yuck! =p
13:08 brrt i like emacs :-)
13:09 brrt i also like vim, yes, but somehow my mind correlates vim with config files, and emacs with source code, and I can't break that association
13:09 nwc10 bigamy!
13:10 nwc10 you're not supposed to take both sides in holy wars :-)
13:10 nebuchadnezzar nwc10++
13:10 nebuchadnezzar brrt: my mind correlates config files with TRAMP mode
13:10 nebuchadnezzar to each problem, an emacs mode :-D
13:13 brrt well, I work on source code using TRAMP mode
13:13 brrt is that okay?
13:13 brrt :-P
15:48 nebuchadnezzar :-/ rakudo tests fail on arm64, powerpc and ppc64 https://buildd.debian.org/status/package.php?p=rakudo
16:45 dalek MoarVM: dd3749d | jnthn++ | src/6model/reprs/MVMString.h:
16:45 dalek MoarVM: Update a comment to reflect current reality.
16:45 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/dd3749d146
16:45 nwc10 was about to type `git show` here
16:45 nwc10 then realised "wrong window"
16:45 jnthn :)
16:46 nwc10 I don't *think* that the work coffee has been replaced with decaf
16:47 nwc10 but I did noticed that the liquid flowed out rather too quickly in the last cup that I made, which the folks who understand this stuff have told me is a sign of not enough coffee grounds in the thing
16:47 jnthn uh-oh
16:47 nwc10 possible problem was that the grinder really needed refilling but I chanced it on the assumption that I could get enough out without doing so
16:48 nwc10 so a PEBKAC variant
16:48 jnthn Maybe it will just about get you through the day... :)
16:48 nwc10 I've also drunk the beer cellar dry
16:48 nwc10 (the beer cellar never really had much beer in it)
16:48 nwc10 that is more logistics fail on "just in time" inventory than a "thirst" problem.
16:49 nwc10 builders are making excellent progress on the new beer cellar
16:52 [Coke] want to add moarvm's env vars to rakudo's 00-running in a special section that indicates they are vm specific. any of the ones on this list that we should NOT advertise?:
16:52 [Coke] https://gist.github.com/coke/c1ec178d8c85ce59212151c9cf8c6649
16:52 timotimo are you refering to tests? or is that documentation?
16:53 [Coke] docs,
16:53 [Coke] sorry.
16:53 timotimo OK :)
16:53 timotimo i don't actually know about ComSpec and PATHEXT
16:54 [Coke] First pass I would say just the MVM_ ones.
16:54 FROGGS joined #moarvm
16:54 FROGGS o/
16:55 [Coke] ... and my weird run bug is a SPESH issue?
16:57 FROGGS nebuchadnezzar: do you have a clue what this means? https://release.debian.org/transitions/html/auto-libffi.html
16:57 jnthn [Coke]: Some of them are decidedly developer-facing, so it depends who the docs are for
16:57 [Coke] docs.perl6.org
16:57 FROGGS "This package [moarvm] will soon be part of the auto-libffi transition. You might want to ensure that your package is ready for it. You can probably find supplementary information in the debian-release archives or in the corresponding release.debian.org bug."
16:58 [Coke] we could put them on a moarvm site and link to it, that's fine.
16:58 jnthn [Coke]: MVM_JIT_DISABLE, MVM_SPESH_DISABLE, MVM_SPESH_INLINE_DISABLE, and MVM_SPESH_OSR_DISABLE are useful for disabling specific optimizations
16:58 [Coke] jnthn: btw, I have a bug that goes away with MVM_SPESH_DISABLE=1.
16:58 jnthn [Coke]: Urgh. Please report it, in the MoarVM issue queue if you wish
16:58 [Coke] but it involves perl6-doc and having aspell installed. ;)
16:58 jnthn Oh o.O
16:59 * jnthn hands [Coke] some golf clubs ;)
16:59 [Coke] yay, I've been trying that :P
16:59 [Coke] *yah
16:59 ilmari FROGGS: it means that libffi7 is transitioning to testing, and anything built against libffi6 will have to be rebuilt
16:59 FROGGS nebuchadnezzar: also, since all are marked as installed, is the next step about uploading nqp? https://buildd.debian.org/status/package.php?p=moarvm
16:59 [Coke] jnthn: ok, I'll open docs tickets for those 4.
16:59 FROGGS ilmari: thanks
16:59 [Coke] ... ltaer.
16:59 jnthn [Coke]: fwiw, I think all the MVM_ envvars are documented if you moar --help
17:01 ilmari FROGGS: correction, to unstable (it's currently only in experimental)
17:09 nebuchadnezzar FROGGS: for the auto-libffi transition, it tracks packages using libffi to see if they are ready for that transition
17:11 nebuchadnezzar FROGGS: nqp is already uploaded in version 2016.09-1 https://tracker.debian.org/pkg/nqp, do we need to forge a rebuild of nqp with the new moarvm?
17:12 nebuchadnezzar FROGGS: when we want a new rakudo, we prepare packages for moarvm, nqp and rakudo, the build system take care of build dependencies to do things in the right order, but as nqp is arch=all only one build is necessary
17:13 FROGGS nebuchadnezzar: I *guess* you have to force a rebuild of nqp... but I dunno how that could happen
17:14 nebuchadnezzar FROGGS: but nqp was built on amd64, which did not have any issue
17:15 nebuchadnezzar I thought .moarvm was architecture independent
17:16 nebuchadnezzar off for dinner
17:17 jnthn cygx: .moarvm should be architecture independent, or we can't bootstrap from the stage0...
17:17 jnthn oops
17:17 jnthn nebuchadnezzar: ^^
17:27 FROGGS nebuchadnezzar: yes, it is arch independent, but how do we know that the tests pass?
17:46 domidumont joined #moarvm
18:03 domidumont Weird, rakudo build on arm64 hangs again. I thought that this problem was fixed
18:08 FROGGS :S
18:08 FROGGS did not happen on my arm64 chroot
18:13 domidumont see https://buildd.debian.org/status/fetch.php?pkg=rakudo&arch=arm64&ver=2016.09-2&stamp=1476110077
18:14 timotimo thanks a lot for the work y'all are doing for debian+rakudo
18:15 domidumont build is done on arm64 HW, not in an emulated chroot. I wonder if that has an impact on the build
18:15 domidumont timotimo: you're welcome :-)
19:32 domidumont FROGGS: I'll check again on my arm64 chroot and then on arm64 HW
20:19 [Coke] jnthn: whee, have a golf.
20:19 jnthn \o/
20:20 [Coke] https://gist.github.com/coke/97932811727466d5156bb306f66dfa0f
20:20 [Coke] dies here after 200 times through the loop (exactly).
20:20 [Coke] MVM_SPESH_DISABLE, it keeps going.
20:20 [Coke] the ! in the ok is needed.
20:22 jnthn [Coke]++
20:22 [Coke] opening a moarvm ticket...
20:24 jnthn Thanks. Should have a good tuit supply on Wed :)
20:24 [Coke] https://github.com/MoarVM/MoarVM/issues/426
20:25 [Coke] 2:#define MVM_OSR_THRESHOLD 200
20:25 jnthn Yeah, I'll bet MVM_SPESH_OSR_DISABLE=1 also fixes it?
20:25 [Coke] (that would be more suspicious if it wasn't failing on 250 the last time.)
20:25 jnthn One of my first checks will be if MVM_SPESH_INLINE_DISABLE also helps
20:26 [Coke] no!
20:26 [Coke] neither of those help
20:26 jnthn Hmmm
20:26 jnthn Well, that's two things not to blame at least :)
20:26 [Coke] :)
21:34 cygx joined #moarvm
21:35 cygx jnthn: is hashing the only reason for the existence of MVM_string_flatten() or do we rely enywhere else on the ability to generate flat NFG strings?
21:36 jnthn cygx: We also do it for the regex engine
21:36 jnthn Since it's far cheaper to index into a flat buffer
21:36 jnthn The operation will not continue to be in-place though
21:36 jnthn Never shoulda been
21:37 jnthn And for hashes, it was done that way for expedience
21:37 * jnthn figured "ah, let's use an off-the-shelf hash library to save time" and learned that some things you just write by yourself...
21:38 jnthn So the only use we'll end up with longer term is for the regex engine to have a known-flat buffer to work against
21:39 jnthn (That it's in-place is a source of concurrency bugs. It's about top of my list of stuff to deal with.)
21:41 cygx I'm thinking about using strands and a new binary storage type for string to implement compatibility encodings instead of synthetics
21:41 cygx basically, strings would be able to contain embedded binary substrings
21:42 cygx as we already support strands, it would probably not too much of a change
21:42 cygx *not be
21:43 jnthn That'll be fragile.
21:43 jnthn We'd need to then work out how to handle those everywhere
21:44 jnthn The point of doing it with synthetics is that you don't have to care except on the boundary
21:44 jnthn (e.g. when encoding/decoding)
21:45 jnthn Make strings be anything but codepoints or synthetics, and the mess is scattered all over the code.
21:45 jnthn So, no.
21:46 jnthn Generalizing encoding so they all cope with the synthetics would probably be a better way to go
21:46 jnthn (The synthetics that represent unrepresentable things, that is)
21:48 cygx the issue I see with that is that we will probably have to flatten invalid code unit sequences into a single synthetic instead of generating a new one for each unit
21:49 cygx (edge case: trying to decode arbitrary int32 data as UTF-32)
21:52 jnthn I'd rather have a useless thing be problematic than the added complexity on all the useful things.
21:55 jnthn Time to get some sleep...'night
21:55 cygx night o/

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary