00:13
CrazyPython has joined #pypy
00:45
CrazyPython has quit [Read error: Connection reset by peer]
01:09
CrazyPython has joined #pypy
01:19
CrazyPython has quit [Read error: Connection reset by peer]
01:20
<
jneen >
how would yall go about debugging an AssertionError that only happens in the compiled artifact
01:20
<
jneen >
and doesn't correspond to any python-level `assert` statement, but points somewhere deep in implement.c
01:21
<
jneen >
like, my program passes the typer and behaves correctly under cpython...
01:21
<
jneen >
and i don't use we_are_translated() at all except for guarding debug statements
01:50
CrazyPython has joined #pypy
01:52
tos9 has quit [Quit: Bye]
01:53
tos9 has joined #pypy
01:55
jvesely has quit [Read error: Connection reset by peer]
01:55
jvesely has joined #pypy
01:59
<
ronan >
jneen: what's the error?
02:00
<
ronan >
mattip: yes, I guess it's from the host
02:12
BPL has quit [Quit: Leaving]
02:20
CrazyPython has quit [Read error: Connection reset by peer]
02:43
jcea has quit [Quit: jcea]
02:56
<
jneen >
all i've got is AssertionError and a stack that points to implement.c
02:57
<
jneen >
InstType does in fact have a method called `reindex`, but it contains no asserts
03:09
<
jneen >
my guess is it might have something to do with r_uint? that was the last thing i changed
03:10
<
jneen >
i could probably track it down if i had more in the way of hints, but i'm literally not sure where to look. there is no error under cpython.
04:53
dddddd has quit [Remote host closed the connection]
05:23
_whitelogger has joined #pypy
06:41
_whitelogger has joined #pypy
06:59
<
fijal >
jneen: look into generated source code I'm afraid
07:11
xcm has joined #pypy
07:12
<
cfbolz >
jneen: is your code on github? If you tell me how to reproduce, I'll take a look
07:47
_whitelogger has joined #pypy
09:17
glyph has quit [Quit: End of line.]
09:17
glyph has joined #pypy
10:21
mwhudson has quit [Ping timeout: 256 seconds]
11:03
otisolsen70 has joined #pypy
11:06
<
cfbolz >
jneen: I would suspect it is the "assert out >= 0 # unsigned" in read_int, which is inlined into read_constant
11:06
<
cfbolz >
bit weird indeed that it doesn't happen untranslated
11:48
BPL has joined #pypy
11:53
jacob22_ has joined #pypy
11:56
jacob22 has quit [Ping timeout: 256 seconds]
11:59
<
arigo >
pull requests make draft branches or so, but they are not available in a regular pull any more, right?
12:00
<
arigo >
what if I want to see this branch locally? is there any way short of fully accepting the pull request?
12:03
<
mattip >
hg phase -p
12:04
<
mattip >
hg phase -p -r <branch-name> might work too
12:05
<
arigo >
no, the problem is that the commits are not pulled at all
12:05
<
arigo >
I don't have them locally
12:07
<
mattip >
then I think you must use the evolve extension
12:07
<
mattip >
yeah, they are missing
12:09
<
mattip >
definitely foss.heptapod.net, that is what is uploaded to
www.pypy.org
12:10
<
mattip >
I will delete the github one, sorry
12:11
<
arigo >
wait a sec then
12:12
dddddd has joined #pypy
12:13
<
arigo >
hum, too late?
12:13
<
mattip >
I think I merged it to heptapod a while ago anyway
12:15
<
arigo >
I don't think so
12:16
<
mattip >
hmm. Do you have it locally?
12:16
<
mattip >
grr. Too fast
12:17
<
arigo >
I'll ask the original author
12:20
<
mattip >
but I can't find the commit sha nor a way to download it
12:21
<
arigo >
I managed only to get the diff of that branch (there's a button), but this diff is only killing three files, not changing any README
12:21
<
arigo >
I think there's some issue with the way the branch was created
12:23
<
arigo >
looking in the source of the html page, there's a sha d99f638929150e72cd73db476d7cb654a4bf4b40, which doesn't seem to be present in my local copy
12:26
<
arigo >
that interface looks bogus
12:27
<
mattip >
maybe the heptapod people are around?
12:28
<
arigo >
I guess the main question I have at this point is: is there any way we can pull commits from merge requests locally?
12:38
<
mattip >
which I can see in "hg topics", and can checkout hg up bufferedio-release-buffer
12:39
<
arigo >
my current guess is that "hg pull" used to download all these checkins, but now it no longer does
13:14
jcea has joined #pypy
13:29
<
jneen >
ohhhhh inlining!
13:29
<
jneen >
i hadn't considered inlining
13:30
<
jneen >
on that branch though i was using read_uint, which used an unpack('I'...)
14:00
xcm has quit [Remote host closed the connection]
14:02
xcm has joined #pypy
14:12
<
mattip >
it seems my change to check ferror(fid) in 9c3ef63e594c make ttest_run_file pass in test_eval.py,
14:12
<
mattip >
but is somehow double-freeing since the next test crashes
14:13
<
mattip >
if I comment out the test-closed-fp call to PyRun_File, everything is OK
14:19
lritter has joined #pypy
14:40
jvesely has quit [Remote host closed the connection]
14:40
jvesely has joined #pypy
14:48
<
cfbolz >
jneen: yes, the concrete assert is probably not the right one
14:48
<
cfbolz >
jneen: but inlining is involved ;-)
14:48
<
cfbolz >
I plan to dig a bit more, if I find a few more minutes
14:55
andi- has quit [Remote host closed the connection]
14:56
<
mattip >
arigo: there is a comment on move_real_result_and_call_reacqgil_addr in zarch/callbuilder.py "please fix me for cd7261a5a735 and then remove this"
14:57
<
mattip >
any idea what that fix might entail? Should we wait with 7.3.1 for a fix or not release s390x?
14:59
andi- has joined #pypy
15:02
<
arigo >
mattip: I think at this point we should ignore s390x
15:03
<
arigo >
if someone worries about keeping s390x up-to-date, sure, that's good, but otherwise too bad
15:03
<
mattip >
ok, thanks
15:04
<
arigo >
(I wrote the comment in rgil-track-thread because the s390x needs to be fixed just like all other backends)
15:04
<
mattip >
right, it would require some knowledge and testing to get right, and also access to the platform
15:05
<
arigo >
(see e.g. jit/backend/arm/callbuilder.py, it shows that it's a very small fix, but I can't do it blindly)
15:05
<
cfbolz >
jneen: ok, the problem is that the os.read call returns a string of length 1, not 4
15:06
<
cfbolz >
that triggers an assert in runpack
15:06
<
cfbolz >
(I ran it in the debugger)
15:07
YannickJadoul has joined #pypy
15:16
<
cfbolz >
confused I am
15:28
<
cfbolz >
jneen: ignore me, I am doing stupid stuff
15:35
<
cfbolz >
jneen: I was running testy.mag, not testy.magc, which did silly things of course. my ruby seems not recent enough to run the compiler, can you send me your magc?
16:50
_whitelogger has joined #pypy
17:20
<
YannickJadoul >
Any tentative plan for when 7.3.1 will be released? Trying to see if we should hold off the new cibuildwheel release
17:52
<
cfbolz >
YannickJadoul: question for mattip
17:53
<
jneen >
you have my code lol
17:53
<
jneen >
i backed out of those changes, using signed ints for now
17:54
<
jneen >
give me a sec, i can put it back to how it was
17:54
<
jneen >
but i changed a bunch of other stuff in the meanwhile
17:54
<
jneen >
you can generate the magc file with `./bin/mag -c thing.mag`
17:54
<
jneen >
that'll run the ruby compiler
17:55
<
jneen >
shouldn't need any dependencies, just ruby 2.x
17:56
<
jneen >
...though, the vm should be calling that automatically in the new version i'm about to push (i did the fork/exec thing after all)
17:57
<
jneen >
thank you for your patience with my code which is an awful mess
17:57
<
cfbolz >
jneen: got some Ruby error when I tried that, anyway, out of time for today, will look some more soon :-)
17:57
<
cfbolz >
Anyway, sorry, didn't wanna poke too much, but had a free half hour earlier :-)
17:58
<
jneen >
the Makefile should have some pre-built stuff to run testy.mag
17:59
<
jneen >
make hello-world-dynamic will run it with debugging on (very verbose) in cpython
17:59
<
cfbolz >
Cool, thanks
17:59
<
jneen >
make hello-world will compile it and run it natively
17:59
<
jneen >
you can grep the hello-world-dynamic stuff for GLOBAL if you only want to see the output of the program
17:59
<
cfbolz >
But the assertion error is gone now?
18:00
<
jneen >
i need to majorly clean up my debugging infra once this is a little more stable
18:00
<
jneen >
well, i backed out of the changes - i don't think i ever pushed the changeset that caused it
18:00
<
jneen >
i've reconstructed it and it's back. it's possible i really don't understand how to use r_uint
18:00
<
cfbolz >
OK. If you want to put it on a branch, I could take a look
18:02
<
cfbolz >
(and yes, r_uint is definitely fiddly)
18:03
<
jneen >
i think i'm ok just using signed ints for now - i will need to be pretty careful about what is and isn't signed when i change that
18:24
<
mattip >
YannickJadoul: hopefully this week, unless we hit some snags
18:27
<
YannickJadoul >
mattip: Oh, great, thanks! I'll let the others know! :-)
18:38
<
jneen >
cfbolz: would you mind actually sending me the ruby error you got? i want to avoid "works on my machine" as much as i can ><
18:38
dddddd has quit [Ping timeout: 256 seconds]
18:39
<
cfbolz >
jneen: will do a bit later, once I'm back at my computer
18:40
<
jneen >
ok! as you have time :]
18:59
<
cfbolz >
jneen: I get this error:
19:03
mwhudson has joined #pypy
19:03
mwhudson has quit [Changing host]
19:03
mwhudson has joined #pypy
19:06
mwhudson has quit [Remote host closed the connection]
19:08
<
arigo >
cfbolz: I think it's Ruby 2.6 syntax
19:09
<
cfbolz >
ah, thanks :-)
19:09
<
cfbolz >
arigo: had no clue you knew any ruby :-)
19:09
<
arigo >
it's just what the internet told me, in this case :-) but yes I do a little bit
19:11
<
arigo >
it feels like some weird cross of smalltalk and python, not in a good way imho
19:19
<
jneen >
what ruby version have you got?
19:25
<
mattip >
we should try to make the buildbots greener, but ...
19:27
mwhudson has joined #pypy
19:29
<
mattip >
one possible fix for the runtime mess with windows would be to compile a cpython for testing with the visual2019 compiler
19:30
<
jneen >
ah, i missed that. pushing a fix.
19:37
plan_rich has joined #pypy
19:37
<
cfbolz >
mattip: might make sense
19:39
tsaka__ has quit [Ping timeout: 246 seconds]
19:45
xcm has quit [Ping timeout: 264 seconds]
19:54
xcm has joined #pypy
19:57
<
arigo >
is it the case that the pypy.org org still contains a "source" directory which should be deleted because it's very confusing?
19:58
<
arigo >
and the files /README and /README-DO-NOT-EDIT should be updated or deleted too?
20:01
<
mattip >
arigo: yes please, I never got around to it. The README-DO-NOT-EDIT should become the README (without the last line)
20:01
<
mattip >
and the real documentation is `make help` which prints out usable commands
20:01
<
mattip >
I guess that too could be improved upon
20:02
<
mattip >
there are probably other unneeded files too
20:09
<
cfbolz >
jneen: yay, works now! thank you :-)
20:11
tsaka__ has joined #pypy
20:56
tsaka__ has quit [Ping timeout: 240 seconds]
21:25
tsaka__ has joined #pypy
21:40
YannickJadoul has quit [Quit: Leaving]
21:56
otisolsen70 has quit [Quit: Leaving]
22:17
<
mattip >
ronan: I think ccd9ce4e3a0c is causing test_recursion to fail on py3.6
22:17
<
mattip >
I think somewhere between 768e7e44eb1e and 96194b9e6c63 it began failing
23:05
the_drow[m] has quit [Ping timeout: 246 seconds]
23:18
the_drow[m] has joined #pypy
23:43
tsaka__ has quit [Ping timeout: 252 seconds]
23:54
plan_rich has quit [Ping timeout: 250 seconds]