|
01:48
ilbot3 joined
02:49
mwilson_ joined
04:55
stmuk joined
05:41
domidumont joined
05:47
domidumont joined
06:14
domidumont joined
06:39
domidumont joined
07:19
brrt joined
|
|||
| brrt | hey #moarvm | 07:19 | |
| regarding x32 JIT; that Configure-time check is a bad solution | 07:20 | ||
| nwc10 | good *, brrt | ||
| brrt | good * nwc10 | ||
| (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 | ||
| brrt | true | ||
| nwc10 | (it's like the ASAN output - it's so much better before it goes into a pastebot) | ||
| anyway, what's a better solution, and why? :-) | 07:22 | ||
| 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) | ||
| brrt | in general, the Configure script is all about determining how to make something compile | ||
| the ultimate test is just to compile some things (and we do) | |||
| but not for the JIT | |||
| nwc10 | but can the runtime architecture and ABI vary significantly from configure time? | ||
| brrt | welll…. | 07:24 | |
| nwc10 | although, yes, sigh, fat binaries | ||
| brrt | yeah | ||
| nwc10 | but that's probably not the common one | ||
| brrt | actually, that is the common one | ||
| nwc10 | I guess the useful one is "how recent is this CPU that we're actually running on" | ||
| ah OK. | |||
| Perl 5 fails completely at the "fat binaries" thing | |||
| brrt | the uncommon one is 'I want to crossocmpile something' | ||
| nwc10 | I'm not sure about the *un*common part - that seems to be more common these days as a frustration | 07:25 | |
| but I'm agreeing with you about the relevance :-) | |||
| brrt | crosscompilers tend to be pro users, whereas fatbinary-compilers tend to be…. kids with macbooks :-P | 07:26 | |
| not that we shouldn't have that fixed | |||
| it's just that I've come accross 'perl6 doesn't work' more than once where that was the problem | 07:27 | ||
| 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. | ||
| brrt | partly because apple makes making one the default, I think | ||
| 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 | |
| It just resolutely fails to build a fat binary :-) | |||
| brrt | well, that's something | ||
| nine | Well at least the new check is only as bad as the old checks ;) | 07:31 | |
| brrt | oh certainly | 07:32 | |
| i'm complaining about the old checks ;-) | 07:33 | ||
|
08:45
brrt1 joined
12:13
brrt_shell joined
|
|||
| nebuchadnezzar | We have NativeCall issues on powerpc with the new packages buildd.debian.org/status/fetch.php...1476101411 | 12:18 | |
| nwc10 | that seems to be the only big-endian architecture in buildd.debian.org/status/logs.php?...=2016.09-2 | 12:20 | |
| nebuchadnezzar | ppc64 is waiting moarvm build for that architecture: buildd.debian.org/status/package.p...;suite=sid | 12:24 | |
| nwc10 | was more that I'm curious if it's actually a more general big endian bug | ||
| nebuchadnezzar | powerpc and ppc64 seems to be the only two big endian arch in buildd.debian.org/status/package.php?p=rakudo | 12:25 | |
|
12:35
brrt joined
|
|||
| brrt | hmm, i wonder how i'm going to like irssi | 12:38 | |
| jnthn likes it sufficiently to still be using it after a few years | 12:39 | ||
| arnsholt | Yeah, I'm pretty happy with it too | 12:40 | |
| brrt | well, i'll succumb to peer pressure this case | 12:43 | |
| I kind of liked erc (in emacs) | |||
| which I can also do, of course | |||
| nebuchadnezzar | ERC++ | 12:45 | |
| :-D | |||
|
12:45
zakharyas joined
|
|||
| arnsholt | But then you have to use Emacs! | 12:47 | |
| Yuck! =p | |||
| brrt | i like emacs :-) | 13:08 | |
| 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! | ||
| you're not supposed to take both sides in holy wars :-) | 13:10 | ||
| nebuchadnezzar | nwc10++ | ||
| brrt: my mind correlates config files with TRAMP mode | |||
| to each problem, an emacs mode :-D | |||
| brrt | well, I work on source code using TRAMP mode | 13:13 | |
| is that okay? | |||
| :-P | |||
| nebuchadnezzar | :-/ rakudo tests fail on arm64, powerpc and ppc64 buildd.debian.org/status/package.php?p=rakudo | 15:48 | |
| dalek | arVM: dd3749d | jnthn++ | src/6model/reprs/MVMString.h: Update a comment to reflect current reality. |
16:45 | |
| nwc10 | was about to type `git show` here | ||
| then realised "wrong window" | |||
| jnthn | :) | ||
| nwc10 | I don't *think* that the work coffee has been replaced with decaf | 16:46 | |
| 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 | ||
| 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 | ||
| so a PEBKAC variant | 16:48 | ||
| jnthn | Maybe it will just about get you through the day... :) | ||
| nwc10 | I've also drunk the beer cellar dry | ||
| (the beer cellar never really had much beer in it) | |||
| that is more logistics fail on "just in time" inventory than a "thirst" problem. | |||
| builders are making excellent progress on the new beer cellar | 16:49 | ||
| [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 | |
| gist.github.com/coke/c1ec178d8c85c...c9cf8c6649 | |||
| timotimo | are you refering to tests? or is that documentation? | ||
| [Coke] | docs, | 16:53 | |
| sorry. | |||
| timotimo | OK :) | ||
| i don't actually know about ComSpec and PATHEXT | |||
| [Coke] | First pass I would say just the MVM_ ones. | 16:54 | |
|
16:54
FROGGS joined
|
|||
| FROGGS | o/ | 16:54 | |
| [Coke] | ... and my weird run bug is a SPESH issue? | 16:55 | |
| FROGGS | nebuchadnezzar: do you have a clue what this means? release.debian.org/transitions/htm...ibffi.html | 16:57 | |
| jnthn | [Coke]: Some of them are decidedly developer-facing, so it depends who the docs are for | ||
| [Coke] | docs.perl6.org | ||
| 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." | ||
| [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 | ||
| [Coke] | jnthn: btw, I have a bug that goes away with MVM_SPESH_DISABLE=1. | ||
| jnthn | [Coke]: Urgh. Please report it, in the MoarVM issue queue if you wish | ||
| [Coke] | but it involves perl6-doc and having aspell installed. ;) | ||
| jnthn | Oh o.O | ||
| jnthn hands [Coke] some golf clubs ;) | 16:59 | ||
| [Coke] | yay, I've been trying that :P | ||
| *yah | |||
| ilmari | FROGGS: it means that libffi7 is transitioning to testing, and anything built against libffi6 will have to be rebuilt | ||
| FROGGS | nebuchadnezzar: also, since all are marked as installed, is the next step about uploading nqp? buildd.debian.org/status/package.php?p=moarvm | ||
| [Coke] | jnthn: ok, I'll open docs tickets for those 4. | ||
| FROGGS | ilmari: thanks | ||
| [Coke] | ... ltaer. | ||
| jnthn | [Coke]: fwiw, I think all the MVM_ envvars are documented if you moar --help | ||
| ilmari | FROGGS: correction, to unstable (it's currently only in experimental) | 17:01 | |
| nebuchadnezzar | FROGGS: for the auto-libffi transition, it tracks packages using libffi to see if they are ready for that transition | 17:09 | |
| FROGGS: nqp is already uploaded in version 2016.09-1 tracker.debian.org/pkg/nqp, do we need to forge a rebuild of nqp with the new moarvm? | 17:11 | ||
| 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:12 | ||
| FROGGS | nebuchadnezzar: I *guess* you have to force a rebuild of nqp... but I dunno how that could happen | 17:13 | |
| nebuchadnezzar | FROGGS: but nqp was built on amd64, which did not have any issue | 17:14 | |
| I thought .moarvm was architecture independent | 17:15 | ||
| off for dinner | 17:16 | ||
| jnthn | cygx: .moarvm should be architecture independent, or we can't bootstrap from the stage0... | 17:17 | |
| oops | |||
| nebuchadnezzar: ^^ | |||
| FROGGS | nebuchadnezzar: yes, it is arch independent, but how do we know that the tests pass? | 17:27 | |
|
17:46
domidumont joined
|
|||
| domidumont | Weird, rakudo build on arm64 hangs again. I thought that this problem was fixed | 18:03 | |
| FROGGS | :S | 18:08 | |
| did not happen on my arm64 chroot | |||
| domidumont | see buildd.debian.org/status/fetch.php...1476110077 | 18:13 | |
| timotimo | thanks a lot for the work y'all are doing for debian+rakudo | 18:14 | |
| domidumont | build is done on arm64 HW, not in an emulated chroot. I wonder if that has an impact on the build | 18:15 | |
| timotimo: you're welcome :-) | |||
| FROGGS: I'll check again on my arm64 chroot and then on arm64 HW | 19:32 | ||
| [Coke] | jnthn: whee, have a golf. | 20:19 | |
| jnthn | \o/ | ||
| [Coke] | gist.github.com/coke/9793281172746...06f66dfa0f | 20:20 | |
| dies here after 200 times through the loop (exactly). | |||
| MVM_SPESH_DISABLE, it keeps going. | |||
| the ! in the ok is needed. | |||
| jnthn | [Coke]++ | 20:22 | |
| [Coke] | opening a moarvm ticket... | ||
| jnthn | Thanks. Should have a good tuit supply on Wed :) | 20:24 | |
| [Coke] | github.com/MoarVM/MoarVM/issues/426 | ||
| 2:#define MVM_OSR_THRESHOLD 200 | 20:25 | ||
| jnthn | Yeah, I'll bet MVM_SPESH_OSR_DISABLE=1 also fixes it? | ||
| [Coke] | (that would be more suspicious if it wasn't failing on 250 the last time.) | ||
| jnthn | One of my first checks will be if MVM_SPESH_INLINE_DISABLE also helps | ||
| [Coke] | no! | 20:26 | |
| neither of those help | |||
| jnthn | Hmmm | ||
| Well, that's two things not to blame at least :) | |||
| [Coke] | :) | ||
|
21:34
cygx joined
|
|||
| 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:35 | |
| jnthn | cygx: We also do it for the regex engine | 21:36 | |
| Since it's far cheaper to index into a flat buffer | |||
| The operation will not continue to be in-place though | |||
| Never shoulda been | |||
| 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... | |||
| 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:38 | ||
| (That it's in-place is a source of concurrency bugs. It's about top of my list of stuff to deal with.) | 21:39 | ||
| cygx | I'm thinking about using strands and a new binary storage type for string to implement compatibility encodings instead of synthetics | 21:41 | |
| basically, strings would be able to contain embedded binary substrings | |||
| as we already support strands, it would probably not too much of a change | 21:42 | ||
| *not be | |||
| jnthn | That'll be fragile. | 21:43 | |
| We'd need to then work out how to handle those everywhere | |||
| The point of doing it with synthetics is that you don't have to care except on the boundary | 21:44 | ||
| (e.g. when encoding/decoding) | |||
| Make strings be anything but codepoints or synthetics, and the mess is scattered all over the code. | 21:45 | ||
| So, no. | |||
| Generalizing encoding so they all cope with the synthetics would probably be a better way to go | 21:46 | ||
| (The synthetics that represent unrepresentable things, that is) | |||
| 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:48 | |
| (edge case: trying to decode arbitrary int32 data as UTF-32) | 21:49 | ||
| jnthn | I'd rather have a useless thing be problematic than the added complexity on all the useful things. | 21:52 | |
| Time to get some sleep...'night | 21:55 | ||
| cygx | night o/ | ||