github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
00:13
Kaiepi left
00:16
Kaiepi joined
|
|||
Geth | MoarVM/new-disp: 79406a2525 | (Timo Paulssen)++ | 2 files also dump some of the ProgramResultValue opcodes |
03:02 | |
MoarVM/new-disp: 70908c87ee | (Timo Paulssen)++ | src/disp/program.c hypothesize how outcomes to code compile could go |
|||
timotimo | couldn't sleep so spent a few minutes writing incomplete / wrong code that may nevertheless have a salvageable line or two, otherwise you can just forcepush the previous commit over it | 03:03 | |
maybe force-push over it even if there are a few lines that are salvageable, lol | 03:09 | ||
06:44
Kaiepi left
06:48
Kaiepi joined
06:52
domidumont joined
07:57
zakharyas joined
|
|||
Geth | MoarVM: MasterDuke17++ created pull request #1296: Remove redundant if when reading bytecode |
08:39 | |
08:50
sena_kun joined
|
|||
Geth | MoarVM: 17969cfb5e | (Daniel Green)++ | src/core/bytecode.c Remove redundant if when reading bytecode We're already inside the body of an if that checked the exact same variable. |
09:00 | |
MoarVM: 6c30ffed8d | niner++ (committed using GitHub Web editor) | src/core/bytecode.c Merge pull request #1296 from MasterDuke17/remove_redundant_if_when_reading_bytecode Remove redundant if when reading bytecode |
|||
09:25
raku-bridge left
09:26
raku-bridge joined,
raku-bridge left,
raku-bridge joined
09:44
Geth left,
Geth joined
09:45
raku-bridge left
09:47
raku-bridge joined
|
|||
jnthn | timotimo: Thanks, will look over what you did and continue on :) | 10:17 | |
timotimo: That's actually far more correct than I might have imagined from your description here. Thanks! | 10:20 | ||
nine | Yeah, timotimo++ rarely appreciats the awesomeness of his work | 10:25 | |
10:27
Altai-man_ joined
|
|||
jnthn | OK, goal today is to finish complting, and get us running, dispatch programs. | 10:27 | |
Then next week I'll probably switch focus to RakuAST for a little bit. :) | 10:28 | ||
10:30
sena_kun left
|
|||
Geth | MoarVM/new-disp: 2f6736b291 | (Jonathan Worthington)++ | src/disp/program.c Complete dispatch programs for value outcomes |
11:04 | |
jnthn | Lunch, then the rather trickier invoke-y ones | 11:05 | |
MasterDuke | nine: thanks for the merge | ||
if anyone needs some light entertainment to while away their friday afternoon, i have a couple open PRs that could use a look: github.com/MoarVM/MoarVM/pull/1291, github.com/MoarVM/MoarVM/pull/1292, github.com/MoarVM/MoarVM/pull/1281, github.com/MoarVM/MoarVM/pull/689, and github.com/MoarVM/MoarVM/pull/1277 | 11:07 | ||
11:19
zakharyas left
|
|||
Geth | MoarVM/new-disp: 3aaca8ed6e | (Jonathan Worthington)++ | 2 files Fill out ops and dumping of them some more Add a simple temp to temp op, and union parts for args-related ops. |
12:20 | |
12:28
sena_kun joined
12:30
Altai-man_ left
13:07
konvertex joined
|
|||
Geth | MoarVM/new-disp: e83afcc605 | (Jonathan Worthington)++ | src/disp/program.c Compile invoke result and use of args tail That is, the case where the eventual result capture used in the invoke is a tail of the initial capture (which should be the most common case). |
13:34 | |
jnthn | Hmmm | 13:45 | |
The other case is not quite so easy :) | 13:46 | ||
Or at lesat, it could be now, but the easy thing now means we might be in a lot of bother once the attribute read thing is added. | 13:47 | ||
('cus those might need more temporaries to be added.) | |||
Guess I'll do a 2-pass process. | 13:50 | ||
nwc10 | jnthn: NQP happy still | 14:01 | |
14:11
zakharyas joined
14:21
lucasb joined
14:27
Altai-man_ joined
14:29
sena_kun left
|
|||
Geth | MoarVM/new-disp: f45a513ee6 | (Jonathan Worthington)++ | 2 files Compile the case when we need a new args buffer And I believe this - at least for the features currently available - gets us compiling dispatch programs correctly. |
14:57 | |
jnthn | The number of opportunities to make off by 1s in this stuff is immense... | ||
All the dispatch programs it compiles look sensible, though. | 15:00 | ||
Not optimal in some cases, but sensible. | 15:01 | ||
timotimo | very glad to hear you could use my code | 15:21 | |
MasterDuke | the default ubuntu version for travis is xenial (16.04), but they do have bionic (18.04) available. would it make sense to upgrade our config to that? it might have a version of libzstd new enough to work with the new heap snapshot code | 15:28 | |
also, we have `perl: 5.10` in our .travis.yml, but the travis logs show it isn't available, so it just warns and proceeds to use 5.22 | 15:30 | ||
do we really want 5.10? or can that be removed? | |||
timotimo | isn't that what centos has? | 15:32 | |
MasterDuke | dunno, but why would it matter, we don't use centos with travis anyway | 15:33 | |
timotimo | i think centos is a high-value target? | 15:34 | |
MasterDuke | fyi, changing to bionic/18.04 does get moarvm building with `-lzstd` travis-ci.org/github/MoarVM/MoarVM.../692611826 | 15:35 | |
re perl 5.10, i'm not proposing any change in the actual moarvm build requirements, just the travis config. i.e., either remove the current failing attempt to use 5.10, or correct it | 15:36 | ||
Geth | MoarVM: MasterDuke17++ created pull request #1297: Remove Perl 5.10 directive from Travi config |
16:11 | |
MasterDuke | could github.com/StanfordPL/stoke be used to optimize the bits of assembly we have? | 16:20 | |
16:28
sena_kun joined
16:30
Altai-man_ left
|
|||
Geth | MoarVM/new-disp: 6792174da9 | (Jonathan Worthington)++ | 7 files Transition inline cache and run dispatch programs This is just enough to get the current set of tests to pass, including those that depend on the fixation of constants implied by the dispatch program (which thus failed up until now). It only handles callsites that are monomorphic; if the dispatch programs fails because the site is polymorphic, then for now we just panic about this case being NYI. There are some missing bits still, however no tests yet trigger them. |
16:50 | |
16:53
domidumont left
|
|||
jnthn | Finally! | 16:54 | |
sena_kun | jnthn, congrats! Some checkboxes down? | 16:57 | |
jnthn | Just updated the gist. In theory guards too, but I cuoldn't write any tests for them until now, and I don't want to tick that off until I wrote tests and saw them pass. | ||
Also, it really needs the polymorphic bit in place yet | 16:58 | ||
Then I can start looking at the spesh plugin transition. | |||
timotimo | will the polymorphic stuff be based on first a table based on interned callsites, then having branches in the dispatch program? | 17:04 | |
jnthn | Well, unless the callsite is a flattening one, the callsite is a constant. | 17:14 | |
At a given PIC location | |||
I think the first cut of it will run a sequence of dispatch programs. | |||
17:15
sena_kun left
17:16
sena_kun joined
|
|||
timotimo | ah, right | 17:17 | |
17:17
zakharyas left
|
|||
timotimo | ok, so literally run from the start of each until one succeeds or all have failed, and not yet eliminating duplicated checks at the start | 17:18 | |
jnthn | For now, yes | 17:20 | |
home time & | |||
17:31
patrickb joined
|
|||
timotimo | and if all things have failed, run the whole dispatcher code, and if there's still hope a recording can be made as well | 17:32 | |
18:27
Altai-man_ joined
18:30
sena_kun left
18:37
patrickb left
18:39
patrickb joined
18:54
patrickb left
|
|||
nwc10 | the 5.10 isn't accuate any longer. There's something already used in the build system that needs newer than 5.12, IIRC | 18:57 | |
timotimo | oh no | 19:01 | |
nine | The oldest still supported CentOS version is 6 which ships perl-5.10.1. But its only supported till November this year. The next version comes with 5.16.3 | 19:02 | |
19:31
Altai-man_ left
|
|||
Geth | MoarVM: 1573872141 | (Patrick Böker)++ | src/io/dirops.c Fix closing a dir never read from on Windows Dir handles are initialized on first use on Windows. This means we must check for uninitialized handles on close in case we want to close a handle that has never been read and thus never been initialized. |
19:43 | |
19:45
patrickb joined
20:27
patrickb left
|
|||
nwc10 | I forget - is MoarVM allowed to use C99 deeclarations in the function body? | 20:40 | |
nine | yes | 20:41 | |
nwc10 | cool -thanks | ||
jnthn | However, it wasn't all that long ago since we started to allow that, so if you're seeing a ton of code that that doesn't take advantage of it, that's why. | 20:49 | |
nwc10 | ah OK thanks | ||
jnthn | The stuff I'm doing in new-disp enjoys the new freedom, at least :) | ||
nwc10 | I forget what Perl 5 decided that it could "slack off" on. But the one that is really annoying is that named struct initialisers aren't legal C++ until some thing like "this year" | 20:50 | |
which means that you can't use the syntax in headers that are expected to be usable by C++ compilers generating extensions. | |||
and oh my, the number of bugs in bool | 20:51 | ||
(eg casting a pointer into a bool was buggy on the vendor compiler from one of HPUX or AIX about 10 years after C99 was ratified) | |||
jnthn | I don't think I've ever really expected MoarVM to cater to said C++ use case, tbh. | 20:58 | |
nwc10 | Perl 5 needs to. I goofed one of the 5.8.x releases because the headers were not conformant C++ | ||
jnthn | But embedding is probably also a much less common approach now than it once was. | 20:59 | |
nwc10 | then again, the entire userbase goofed, as they didn't spot this from the release candidates | ||
"Release Candidate" really means "Blame Transfer Protocol" | |||
jnthn | :) | ||
22:08
foo222 joined,
foo222 left
22:09
raiph joined
|