|
Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes. Set by lizmat on 24 May 2021. |
|||
|
00:08
reportable6 left
01:03
[Coke]_ joined,
[Coke] left
01:08
reportable6 joined
02:03
squashable6 left
02:17
frost joined
02:52
[Coke] joined
02:53
[Coke]_ left
03:03
frost left
03:06
squashable6 joined
04:32
unicodable6 left,
statisfiable6 left,
greppable6 left,
benchable6 left,
nativecallable6 left,
tellable6 left,
quotable6 left,
shareable6 left,
coverable6 left,
notable6 left,
bisectable6 left,
bloatable6 left,
sourceable6 left,
releasable6 left,
committable6 left,
evalable6 left,
squashable6 left,
linkable6 left,
reportable6 left,
nativecallable6 joined
04:33
reportable6 joined,
committable6 joined
04:34
notable6 joined,
releasable6 joined,
sourceable6 joined,
squashable6 joined,
statisfiable6 joined,
greppable6 joined,
bisectable6 joined,
coverable6 joined
05:38
AlexDaniel left
05:39
nine left,
Techcable left,
statisfiable6 left,
sourceable6 left,
ugexe left,
[Coke] left,
harrow left,
moon-child left,
coverable6 left,
squashable6 left,
notable6 left,
committable6 left,
reportable6 left,
psydroid left,
JRaspass left,
jdv left,
Voldenet left,
mst left,
samcv left,
bartolin_ left,
gfldex left,
jnthnwrthngtn left,
rypervenche left,
Util left,
samebchase left,
lizmat left,
tbrowder left,
leont left,
rba left,
codesections left
05:50
Geth left,
MasterDuke left,
Altai-man left,
nebuchadnezzar left,
leedo left
05:52
Kaiepi left,
vrurg left,
japhb left,
discord-raku-bot left,
kjp left,
timo left,
ilogger2 left,
camelia left
05:53
camelia left,
leedo joined,
nebuchadnezzar joined,
Altai-man joined,
MasterDuke joined,
Geth joined,
[Coke]_ joined,
quotable6 joined,
linkable6 joined,
bloatable6 joined,
unicodable6 joined,
coverable6 joined,
statisfiable6 joined,
squashable6 joined,
sourceable6 joined,
notable6 joined,
committable6 joined,
reportable6 joined,
AlexDaniel joined,
psydroid joined,
ugexe joined,
jnthnwrthngtn joined,
rypervenche joined,
nine joined,
Techcable joined,
mst joined,
samcv joined,
Voldenet joined,
lizmat joined,
Util joined,
harrow joined,
bartolin_ joined,
gfldex joined,
moon-child joined,
leont joined,
rba joined,
codesections joined,
jdv joined,
JRaspass joined,
samebchase joined,
tbrowder joined
05:54
Kaiepi joined,
vrurg joined,
japhb joined,
discord-raku-bot joined,
kjp joined,
timo joined,
ilogger2 joined,
camelia joined
05:55
SmokeMachine joined,
Nicholas joined,
patrickb joined,
TempIRCLogger__ joined,
dogbert17 joined,
RakuIRCLogger joined,
nativecallable6 joined,
releasable6 joined,
greppable6 joined,
bisectable6 joined,
leedo joined,
nebuchadnezzar joined,
Altai-man joined,
MasterDuke joined,
Geth joined,
[Coke]_ joined,
quotable6 joined,
linkable6 joined,
bloatable6 joined,
unicodable6 joined,
coverable6 joined,
statisfiable6 joined,
squashable6 joined,
sourceable6 joined,
notable6 joined,
committable6 joined,
reportable6 joined,
AlexDaniel joined,
psydroid joined,
ugexe joined,
jnthnwrthngtn joined,
rypervenche joined,
nine joined,
Techcable joined,
mst joined,
samcv joined,
Voldenet joined,
lizmat joined,
Util joined,
harrow joined,
bartolin_ joined,
gfldex joined,
moon-child joined,
leont joined,
rba joined,
codesections joined,
jdv joined,
JRaspass joined,
samebchase joined,
tbrowder joined,
camelia joined
06:07
reportable6 left
06:08
reportable6 joined
06:13
linkable6 left
06:33
evalable6 joined,
shareable6 joined
06:34
tellable6 joined,
benchable6 joined
|
|||
| Nicholas | good *able6, * | 06:38 | |
| It was a windy night. No wonder everything flapped a lot | |||
| nine | m: dd class :: { has uint8 $.x; }.new( x => 255 ) | 07:20 | |
| camelia | <anon|1>.new(x => 255) | ||
| nine | m: dd class :: { has uint8 $.x; }.new( x => 255 ).x # but | ||
| camelia | -1 | ||
| nine | m: dd class :: { has uint8 $.x is rw; }.new( x => 255 ).x # oh! | 07:31 | |
| camelia | 255 | ||
|
07:32
squashable6 left
07:33
squashable6 joined
|
|||
| nine | Ah, yes, that's the unfinished business in QASTCompilerMAST | 07:36 | |
|
08:07
frost joined
|
|||
| MasterDuke | today is windsday, but it's not very blustery here | 09:05 | |
|
09:16
frost left
|
|||
| nine | Now this is bizarre: | 09:20 | |
| m: my uint64 $no = 2**64 - 1; say $no | |||
| camelia | -1 | ||
| nine | But: | ||
| m: my uint64 $no = 2**64 - 2; say $no | |||
| camelia | 18446744073709551614 | ||
| nine | So there's the last known uint problem and it's with exactly one value | 09:21 | |
| japhb | That sounds like an off-by-one (or equivalently < instead of <=) in determining bounds | ||
| nine++ for the continuing massive effort, THANK YOU | 09:22 | ||
| nine | Aaah...it's the int cache! I also used it for autobox_uint, but the int cache also contains -1 | 09:44 | |
|
09:44
squashable6 left
|
|||
| MasterDuke | ha, nice find | 09:45 | |
| nine | Total luck... I just wanted to use a value that would stand out more than -1 (which appears in unrelated places as well) in my debug output | 09:47 | |
|
09:51
frost61 joined
10:03
mst left
|
|||
| Geth | MoarVM: a851fcf406 | (Stefan Seifert)++ | src/core/args.c Fix autobox_uint finding negative Ints in the int cache The int cache also contains a boxed -1 which autobox_uint would find for the value 2**64 - 1. Just exclude values with the high bit set from getting looked up at all, in case we add further negative values to the int cache. |
10:03 | |
|
10:05
mst joined
10:09
squashable6 joined
10:13
linkable6 joined
|
|||
| lizmat | nine++ on a roll! | 10:20 | |
| Nicholas | <lizmat>bump?</lizmat> | 10:21 | |
| lizmat | I think nine++ already did | ||
|
10:43
frost61 left
|
|||
| jnthnwrthngtn is feeling positive about nine++'s uint work | 10:52 | ||
| dogbert17 | :) | 10:54 | |
| m: my int8 $x = 2**7 - 1; say $x; say $x++; say $x # is this correct? | 10:55 | ||
| camelia | 127 -129 -128 |
||
| jnthnwrthngtn | dogbert17: I think so, on the basis that calculations are done at full-width, and smaller sizes are only units of storage | 11:00 | |
|
11:01
linkable6 left
|
|||
| jnthnwrthngtn | But wait...uh...how does ++ make it smaller? :) | 11:01 | |
| lizmat | .oO( there is no place for negativity! ) |
||
| jnthnwrthngtn | lizmat: This is not what I want to here while I'm watching today's anti-gen test process :P | 11:02 | |
| *hear | |||
| lizmat | it was only a though! | ||
| -) | |||
| jnthnwrthngtn | Phew, there was at least a little room for negativity :) | 11:05 | |
| lizmat | good! | ||
| maybe an idea to have a GSOC project to port MoarVM to the web with this? leaningtech.com/webvm-server-less-...e-browser/ | 11:20 | ||
| Nicholas | are they single threaded? | 11:31 | |
| lizmat | I have no idea... but I guess you can't run a Debian without being multi-threaded ? | 11:33 | |
| even on a single CPU | 11:34 | ||
|
11:43
sena_kun joined
12:02
linkable6 joined
12:07
reportable6 left
12:12
frost joined
|
|||
| Geth | MoarVM: ef270d7f5e | (Stefan Seifert)++ | 11 files Proper uint support for multidim arrays. Introduce new ops: atposnd_u, atpos2d_u, atpos3d_u, bindposnd_u, bindpos2d_u, bindpos3d_u and multidimref_u and fix deconting unsigned multidimrefs. |
12:14 | |
|
12:30
sena_kun left
12:33
sena_kun joined
12:45
frost left
13:26
[Coke]_ is now known as [Coke]
13:56
discord-raku-bot left
13:57
discord-raku-bot joined
|
|||
| Geth | MoarVM: nwc10++ created pull request #1662: Serialize bigints in base 32, not base 10 |
14:04 | |
| Nicholas | Epic, um, well, epic fail: | 14:05 | |
| All checks have failed | |||
| 1 failing check | |||
| (CodeFactor) | |||
|
14:05
discord-raku-bot left
|
|||
| Nicholas | (now more tests running as I created that PR. I think CodeFactor was on branch push) | 14:05 | |
|
14:05
discord-raku-bot joined
14:24
sena_kun left
14:25
sena_kun joined
|
|||
| MasterDuke | Nicholas: very interesting. so we have a couple places doing semi-custom str-to-int and a couple places doing semi-custom int-to-str. definitely seems like they should be investigated to see how much (if any) of the code can be consolidated | 14:50 | |
| btw, since you're writing an ascii string, can't you assume it's ascii and well-formed when read back and then you don't have to use the iterator and can just read from the MVMString's storage? | 14:52 | ||
| Nicholas | I don't know enough about string serialisation to be confident that it guarantees any particular representation on the way out | 14:55 | |
| (and I didn't go digging) | |||
| (was faster to steal the existing iterator code) | 14:56 | ||
| MasterDuke | i guess that's something that could be figured out during an investigation into consolidating | 14:58 | |
| btw, did my explanation in github.com/MoarVM/MoarVM/pull/1661...r796990689 make sense? | 14:59 | ||
| Nicholas | I spotted that last night when I was tired and so far failed to get back to it (sorry) | ||
| MasterDuke | no particular hurry | ||
|
15:09
reportable6 joined
|
|||
| vrurg | MasterDuke: BTW, the yesterdays SEGV is gone after full removal of the installation directory. No other changes were needed. Some leftovers, I guess, but no idea of what kind as --full-rebuild didn't help. | 15:51 | |
| MasterDuke | huh. well as long as a clean checkout + build is fine i guess that's the most important thing | ||
|
16:03
Kaipi joined
16:06
Kaiepi left
|
|||
| Geth | MoarVM: c00abdf385 | (Daniel Green)++ | src/6model/reprs/P6opaque.c Silence warning about ignoring return value from libtommath function |
16:44 | |
|
17:25
colemanx joined
18:06
reportable6 left
18:24
sena_kun left
|
|||
| lizmat | do we know that EVAL is not threadsafe ? | 18:44 | |
| gist.github.com/lizmat/e94b93e0645...73c834c05e | |||
| ugexe | is the code you are evaling thread safe? | 18:46 | |
| lizmat | Looks like the BlockVarOptimizer class has more of these: %!usages_flat | 18:47 | |
| the code in fact is just doing (try $code.EVAL) on something inside of a :ver( ) | 18:48 | ||
| ugexe | is $code thread safe? | 18:49 | |
| lizmat | it consists of strings like 'v0.0.42+' | ||
| I'd say: yes | 18:50 | ||
| which is run inside of a .hyper | |||
| the string does *not* reference anything outside of it | |||
| ugexe | `use MONKEY-SEE-NO-EVAL; (1..10000).race.map({ EVAL "1" })` works well enough | 18:51 | |
| lizmat | indeed... it's the first time I see this error | ||
| ugexe | but we can see and be quite certain "1" is thread safe | 18:52 | |
| lizmat | but we knew there are still gremlins with EVALling code in parallel, and thats why I made sure I created a gist with the stack trace | ||
| ugexe | can you get one of the strings being evald and plug it into a minimal example like the one above? | 18:54 | |
| lizmat | v0.3.3+ | 18:58 | |
| ugexe | m: use MONKEY-SEE-NO-EVAL; (1..1000000).race.map({ my class Bar:ver(EVAL "v0.3.3+") {} }).eager | 18:59 | |
| camelia | ( no output ) | ||
| ugexe | why can't it be that simple :/ | 19:00 | |
| lizmat | ugexe: it was extracting the string inside a :ver( ) dependency specification | ||
| well, that's it, I haven't been able to reproduce either | |||
| but I felt it was important enough to mention, because of the stack trace and indeed the use of hashes at the given locations | 19:01 | ||
|
19:10
Merfont joined
19:13
Kaipi left
|
|||
| lizmat | I think I found the problem: in QAST::Node | 19:17 | |
| my %uniques; | |||
| method unique($prefix) { | |||
| gen/moar/stage2/QASTNode.nqp:249 | 19:18 | ||
|
19:18
colemanx left
|
|||
| lizmat | feels to me that that hash should be an attribute :-) | 19:18 | |
|
19:19
colemanx joined
|
|||
| lizmat | hmm... looks like QAST::Node.unique is used as a class method | 19:29 | |
| so I guess we need to add a lock ? | |||
| my attempt to fix that race: github.com/Raku/nqp/pull/760 | 19:36 | ||
| comments very welcome | 19:38 | ||
|
20:19
evalable6 left,
linkable6 left
20:36
Altai-man left
20:39
sena_kun joined
|
|||
| lizmat | Nicholas++ # for making thready hash accesses not segfault, but panic | 20:58 | |
|
21:11
camelia left,
mst left,
vrurg left,
japhb left,
kjp left,
timo left,
ilogger2 left,
sena_kun left,
Geth left,
MasterDuke left,
nebuchadnezzar left,
leedo left,
AlexDaniel left,
nine left,
Techcable left,
Merfont left,
squashable6 left,
benchable6 left,
shareable6 left,
bloatable6 left,
unicodable6 left,
statisfiable6 left,
sourceable6 left,
ugexe left,
discord-raku-bot left,
harrow left,
moon-child left,
colemanx left,
coverable6 left,
notable6 left,
committable6 left,
psydroid left,
JRaspass left,
jdv left,
Voldenet left,
samcv left,
bartolin_ left,
gfldex left,
jnthnwrthngtn left,
rypervenche left,
Util left,
samebchase left,
[Coke] left,
quotable6 left,
lizmat left,
tbrowder left,
leont left,
rba left,
codesections left
21:12
RakuIRCLogger left,
TempIRCLogger__ left,
dogbert17 left,
patrickb left,
Nicholas left,
SmokeMachine left,
sena_kun left,
Geth left,
MasterDuke left,
nebuchadnezzar left,
leedo left,
AlexDaniel left,
nine left,
Techcable left,
Merfont left,
squashable6 left,
benchable6 left,
shareable6 left,
bloatable6 left,
unicodable6 left,
statisfiable6 left,
sourceable6 left,
ugexe left,
discord-raku-bot left,
harrow left,
moon-child left,
colemanx left,
coverable6 left,
notable6 left,
committable6 left,
psydroid left,
JRaspass left,
jdv left,
Voldenet left,
samcv left,
bartolin_ left,
gfldex left,
jnthnwrthngtn left,
rypervenche left,
Util left,
samebchase left,
[Coke] left,
quotable6 left,
lizmat left,
tbrowder left,
leont left,
rba left,
codesections left
21:14
gfldex joined,
discord-raku-bot left,
bartolin_ joined,
samcv joined,
ilogger2 joined,
timo joined,
kjp joined,
japhb joined,
vrurg joined,
mst joined,
Techcable joined,
nine joined,
AlexDaniel joined,
codesections joined,
rba joined,
leont joined,
jdv joined,
JRaspass joined,
committable6 joined,
discord-raku-bot joined,
Merfont joined,
squashable6 joined,
benchable6 joined,
shareable6 joined,
bloatable6 joined,
unicodable6 joined,
statisfiable6 joined,
sourceable6 joined,
ugexe joined
21:15
camelia joined,
AlexDaniel left,
jnthnwrthngtn joined,
rypervenche joined,
Util joined,
samebchase joined
21:19
evalable6 joined
|
|||
| jnthnwrthngtn | Wonder how much that .unique locking fix will tank performance... | 21:37 | |
| MasterDuke | i haven't noticed any difference | 21:38 | |
|
22:17
psydroid joined
22:19
MasterDuke left
22:53
AlexDaniel joined
22:58
MasterDuke joined
|
|||
| lizmat | in most cases there won't be any lock cintention, right ? | 23:07 | |
| *contention | |||
| jnthnwrthngtn | No, but it'd still imply an atomic op in userspace | 23:18 | |
| I don't think that's avoidable | |||
| Probably a drop in the ocean | |||
| RakuAST's QAST production approach actually gives us a better peg to hang this off anyway | |||
| So no point spending more time over it than this | 23:19 | ||
| vrurg | jnthnwrthngtn: NQP doesn't have atomics, unfortunately. | 23:34 | |
| jnthnwrthngtn | vrurg: I was talking about what happens inside nqp::lock in the non-contention case | 23:36 | |
| One could arrange for atomics in NQP if they're needed | 23:37 | ||
| (But here they'd not help) | |||
| vrurg | I thought an atomic guard would have less overhead, than a lock. | 23:39 | |
| But, whatever. | |||