<Hodgestar> HPy meeting happening!
<antocuni> ouch, my alarm didn't ring
<antocuni> coming
<phlebas> argh, completely forgot about the meeting, i was happily hacking away...
<phlebas> do we have discussion notes?
<phlebas> also, was fangerer there? we actually wanted to discuss something about the HPyContext pointer, if he wasn't there, I'll put it in writing :)
<mattip> yes and yes, and we discussed the context, the conclusion was "seems reasonable, need to try it and benchmark cpython"
<antocuni> fangerer, phlebas: what is the easiest way to download/try a snapshot of graalpython with hpy?
<phlebas> antocuni: https://github.com/graalvm/graalvm-ce-dev-builds/releases and download the latest `graalpython-dev` package for your platform
<antocuni> thanks!
<phlebas> those are the "standalone" packages that don't also ship a full JVM environment
<phlebas> these builds are expected to be a bit slower than the full releases on the jvm, but i guess that's fine
<antocuni> do I just need to untar and run?
<antocuni> I answer myself: yes :)
<phlebas> :)
<antocuni> I need some help from python packaging experts
<antocuni> so now our setup.py specifies packages=['hpy.devel'], include_package_data=True
<antocuni> I would like to also include hpy.debug in the released version
<antocuni> but if do packages=['hpy.devel', 'hpy.debug'], include_package_data=True, I also get hpy/debug/src/*.[ch] in the wheel, which I don't want
<antocuni> similarly, if I do include_package_data=False, hpy/devel/*.[ch] are NOT included
<antocuni> what I would like is:
<antocuni> 1. hpy/devel/*.[ch] should always be included both in sdist and wheel
<antocuni> 2. hpy/debug/*.py should always be included
<antocuni> 3 hpy/debug/src/ should be included only in the sdist
<antocuni> I *think* I need to play with MANIFEST.in but I am no longer sure of what is the correct approach nowadays
<antocuni> I give up for now
<antocuni> it seems to be ridiculously hard to get it right in all possible situations, e.g. building from checkout, building from sdist, installing from wheel, etc.
<antocuni> there are at least MANIFEST.in, include_package_data, package_data, data_files, all of which do slightly different things
<antocuni> I think that the wheel for hpy==0.0.2 will also include unnecessary C files, but too bad
<mattip> antocuni: you can try the pypa/virtualenv discord https://discord.gg/uufxTxAMCX
<antocuni> mattip: thanks for the suggestion
<antocuni> I think that for now including extra files is not too bad, I don't want to spend too much time on it
<mattip> ok
<mattip> maybe someone who doesn't like the package will contribute a fix
<antocuni> finger crossed
<antocuni> I uploaded hpy==0.0.2rc3 to pypi: https://pypi.org/project/hpy/
<antocuni> only the sdist for now
<antocuni> please try to pip install and play with it to check that everything works as expected
* antocuni off for now
<ronan> progress on the ujson segfault: it happens because cpyext, and specifically rawrefcount, isn't initialised
<antocuni> ronan: that's weird though
<antocuni> by looking at the source code, it seems that rawrefcount is initialized by State.build_api, which is NOT_RPYTHON and it's called at objspace creation time
<antocuni> so it should be automatically initialized
<Hodgestar> Minutes of the dev call this morning: https://github.com/hpyproject/hpy/wiki/dev-call-20210708
<Hodgestar> phlebas: ^^^
<Hodgestar> As usual, shout if I left anything out or got anything wrong and I'll fix it.
<antocuni> Hodgestar: "the default ABI will be changed to universal": this is true only for !=CPython
<Hodgestar> antocuni: I am busy writing a comment about that in your PR.
<antocuni> ok:)
<Hodgestar> antocuni: I think I misunderstood the suggestion made in the meeting this morning.
<Hodgestar> I *think* I'm okay with having different defaults, but it does seem a bit odd.
<Hodgestar> I suppose the default makes sense when compiling from source?
<Hodgestar> But what if you are compiling from source and want the universal module? (which is the future)
<Hodgestar> Either way, let me update the meeting notes.
<antocuni> I agree that having different defaults is sub-optimal, but I think it's better than the current status quo
<antocuni> e.g. on pypy, compiling with --hpy-abi=cpython doesn't even work I think (and if it does, it will be super slow)
<antocuni> so on pypy we surely want universal by default
<antocuni> and on CPython, I think we surely want hpy-abi=cpython by default, because this produces the fastest binary
<antocuni> I don't want to risk that people start to tweet that hpy is slow etc.
* antocuni writes that also on the issue
<Hodgestar> Dev call notes updated.
<antocuni> thanks!
* Hodgestar sleeps.
* antocuni too