<mkoubaa> I think I can look at the porting example. Another way to organize it is a git repo where it starts with a C extension module and every commit changes exactly one thing and has a commit message. But doing automated tests against that sounds painful (not to mention rewriting history when something changes)
<mkoubaa> But it seems a more realistic way to think about code and has easier diffs between commits
mkoubaa has quit [Quit: Leaving]
<fangerer> Good Morning! We will have our dev call in 15 min. Please join: https://oracle.zoom.us/j/339127822?pwd=YkNZbFgvdXZ4Z3NlcWg1N3BlZ3JTUT09
<Hodgestar> As mkoubaa mentoned, puttng the porting example in a git repo with one step per commit seems not quite the right approach. The whole example is part of the current repo state. It's not a history in the version control sense.
Techcable has quit [Remote host closed the connection]
Techcable has joined #hpy
<Hodgestar> I created https://github.com/hpyproject/pillow-hpy for Du Toit and Gianluca. There is an hpy-9.2.0 branch that is a branch off the pillow 9.2.0 commit that can be used as a target for HPy porting PRs.
DuToit has joined #hpy
<DuToit> fangerer: This is the traceback that happens when running selftest.py after installing pillow on graalpython: https://paste.openstack.org/show/815802/
DuToit has quit [Quit: Client closed]
<fangerer> thank you, I'll have a quick look
<fangerer> not sure how this situation came to be; my guess would be that you compiled with `--hpy-abi=universal` but still use legacy API and then want to run this binary with graalpython
<fangerer> if not, I need to debug ...