| jnthn | sleep time for me; 'night | 00:41 | |
| japhb | timotimo++ # Remote debugging! | 01:16 | |
|
01:18
MasterDuke joined
01:50
MasterDuke joined
02:08
Kaiepi joined
02:13
lizmat joined
02:57
ilbot3 joined,
releasable6 joined
04:13
lizmat_ joined
06:24
brrt joined
07:33
brrt joined
07:39
robertle joined
|
|||
| brrt | \o | 07:55 | |
| jnthn++ timotimo++ remote debugger yay | |||
| .tell MasterDuke the real problem is that some of your CALL nodes contain a size 'int' which isn't a size but a type | 07:56 | ||
| yoleaux | brrt: I'll pass your message to MasterDuke. | ||
|
08:13
domidumont joined
|
|||
| Geth | MoarVM: e9e54c8a47 | (Bart Wiegmans)++ | tools/expr-template-compiler.pl [JIT] Warn for things that should be a size but may not be In MasterDuke++'s set of templates there is a (CALL) node in the existskey template that indicates its size as 'int'. The 'int' keyword is however resered to indicate a *type* in a (CARG) node - what was meant was the int_sz keyword instead. This is confusing but somewhat difficult to clean up entirely. What we can do easily though is warn when an argument that *should* be a size looks like it isn't (not a number, not a macro, and doesn't end with _sz). |
08:22 | |
| brrt | .tell MasterDuke if you can fix that I'll merge the code | 08:23 | |
| yoleaux | brrt: I'll pass your message to MasterDuke. | ||
|
08:54
brrt joined
10:04
brrt joined
|
|||
| jnthn | morning o/ | 10:13 | |
| brrt | morning jnthn | 10:16 | |
| awesome work on the remote debugger | |||
| jnthn | Thanks :-) | 10:29 | |
| timotimo++ for turning my design for it into working code :) | |||
| And sena_kun++ of Cro fame provided an amount of testing too :) | 10:31 | ||
| lizmat_ | good * | 10:35 | |
| lizmat | stackoverflow.com/questions/492455...will-match # perhaps something for samcv ? | 10:36 | |
| dogbert2_ | timotimo++, jnthn++ remote debugging | 10:49 | |
| dogbert2_ will definitely try that out :-) | |||
| brrt | yes, all of you ++ | 11:39 | |
|
12:42
domidumont joined
13:35
AlexDaniel joined
|
|||
| japhb | Ah! That explains why jnthn did the blog entry (I had assumed it was some combination of Edument funding it and letting timotimo focus his energy on the coding). jnthn++ and sena_kun++ too then. :-) | 14:11 | |
| timotimo | aye, without jnthn++ and sena_kun++ it wouldn't have turned out very good ;) jnthn came up with the protocol design and that gave a good set of design decisions right from the start | 14:13 | |
| and of course lots of assistance and guidance from jnthn++ throughout the whole implementation phase and bug spotting and debugging help from sena_kun++ | 14:15 | ||
| gist.github.com/panzi/6856583 - this is a dual-licensed public-domain, BSD, MIT, Apache header file that makes all the endian functions available on different systems. with that maybe the debug branch can be merged | 14:20 | ||
| japhb | From the comments, there are patches to apply and/or forks to follow. Which one(s) do you plan to use, OOC? | 14:29 | |
| timotimo | no clue, i don't have the necessary systems to test stuff on | 14:57 | |
| i'm sure kaiepi has something to say about at least one of the BSDs | |||
|
14:59
rba joined
16:04
brrt joined
16:06
Kaiepi joined
|
|||
| jnthn | timotimo: Where in particular do we need the endian stuff, ooc? For cmp? | 16:09 | |
| timotimo | no, just the handshake :) | 16:10 | |
| we could NIH it, too | 16:11 | ||
| jnthn | Don't we have some endian swapping code for reading bytecode anywya? | 16:15 | |
| timotimo | we should, yeah | 16:33 | |
| oh, it was cmp after all that requires endian.h | 16:37 | ||
| huh, no, i don't see endian.h anywhere | |||
| i was using it without including a header at all? | 16:38 | ||
|
16:39
releasable6 joined
|
|||
| timotimo | moarvm's endian switching code is the other way around :D | 16:41 | |
|
16:48
FROGGS joined
17:05
Kaiepi joined
17:13
robertle joined
17:23
rba joined
17:30
Kaiepi joined
|
|||
| timotimo | we'll have our own fork of cmp soon too | 18:43 | |
| m: say (2486 * 2 + 1138 * 2) / 1024 | 19:14 | ||
| camelia | 7.078125 | ||
| timotimo | out of the 4.2 megabytes that Grammar.moar has, I could save 7 kilobytes by introducing const_i1 and const_i0 | 19:15 | |
| m: say (2486 * 2 + 1138 * 2 + 2290 * 2 + 1473 * 2) / 1024 | 19:16 | ||
| camelia | 14.427734 | ||
| timotimo | 14.4 kilobytes if i add const_i2 and const_i3 | ||
| (i.e. constant values 0 through 3) | |||
| a friend suggests varints for every single piece of data in our bytecode files | 19:26 | ||
| which ... no | |||
| that would have rather a lot of effort involved to get it working at all | 19:28 | ||
| m: say 11754136 / 1024 | 19:34 | ||
| camelia | 11478.648438 | ||
| timotimo | m: say 11754136 / 25972 | 19:35 | |
| camelia | 452.569536 | ||
| timotimo | 452 chars per string, huh? | ||
| i probably read that wrong. | 19:38 | ||
| totally | 19:43 | ||
| potentially the string_heap_read_limit is just the end of the file | |||
|
20:01
domidumont joined,
MasterDuke joined
|
|||
| MasterDuke | brrt, et al.: github.com/MoarVM/MoarVM/pull/816 is good now | 20:02 | |
| yoleaux | 07:56Z <brrt> MasterDuke: the real problem is that some of your CALL nodes contain a size 'int' which isn't a size but a type | ||
| 08:23Z <brrt> MasterDuke: if you can fix that I'll merge the code | |||
|
20:03
Kaypie joined
20:26
Kaypie joined
21:26
dogbert17 joined
|
|||
| dogbert17 | #join #whateverable | 21:26 | |
| AlexDaniel | :) | 21:27 | |
| dogbert17 | a bit of a fail there | 21:29 | |
| japhb | #hash #all #the #words | ||
| Geth | MoarVM/spesh-refactor-iffy: 4 commits pushed by (Bart Wiegmans)++ | 21:32 | |
|
22:14
Kaiepi joined
22:43
Kaiepi joined
22:56
evalable6 joined
23:20
MasterDuke joined
23:24
Kaiepi joined
|
|||
| Geth | MoarVM/master: 5 commits pushed by (Samantha McVey)++, (Jonathan Worthington)++ | 23:26 | |
| jnthn | huh, I merged github.com/MoarVM/MoarVM/pull/817 (the debug server PR) too, but it didn't report it here | 23:27 | |
| timotimo++ anyway :) | |||
| timotimo | yays | 23:31 | |
|
23:32
Zoffix joined
|
|||
| Zoffix | Yeah, there's a bug where it doesn't report huge merges. Though now I get a chance to debug and fix it. | 23:33 | |
| timotimo | cool, ++Zoffix | 23:34 | |
|
23:39
Geth joined
|
|||
| jnthn | Zoffix: I wondered if it was the size of it :) | 23:39 | |
|
23:40
MasterDuke joined
|
|||
| MasterDuke | timotimo++ | 23:42 | |
| Geth | MoarVM/master: 5 commits pushed by (Samantha McVey)++, (Jonathan Worthington)++ | 23:43 | |
| Zoffix | hmm | ||
| (trying to find the webhook event for the merge) | |||
| found it | 23:45 | ||
| jnthn | oh, there's 2 that are marked error | ||
| (In the GitHub webhooks UI) | |||
| And yeah, one was the merge | |||
| timotimo | that means an error came back from the http server? | 23:46 | |
|
23:47
Geth joined
|
|||
| timotimo is waiting for the world's slowest swapoff | 23:48 | ||
| jnthn | The hover of the error said it was "Couldn't connect to server" | 23:50 | |
|
23:52
MasterDuke joined
23:53
Geth joined
|
|||
| Geth | MoarVM/master: 5 commits pushed by (Samantha McVey)++, (Jonathan Worthington)++ | 23:54 | |
| MoarVM/master: 112 commits pushed by (Timo Paulssen)++, (Jonathan Worthington)++ review: github.com/MoarVM/MoarVM/compare/e...f952244753 |
|||
| Zoffix | :/ | ||
| Ah, yeah | |||
| Geth | MoarVM/master: 112 commits pushed by (Timo Paulssen)++, (Jonathan Worthington)++ review: github.com/MoarVM/MoarVM/compare/e...f952244753 |
||
| Zoffix | Yeah. fixed now | ||
| timotimo | i bet the ~2% cpu usage by a couple of moar processes are all the supervisor thread ... | 23:55 | |
|
23:55
Geth joined
23:59
Zoffix left
|
|||