06:56 <mattip> making the HPy_Tuple_Pack macro work on C++ is not trivial

06:57 <mattip> using "(HPy[]){ __VA_ARGS__ }" as an argument creates a temporary variable, which is a hard error

07:18 <fangerer> mattip: would an inline helper function in `inline_helpers.h` work?

07:20 <mattip> I will try

07:20 <fangerer> We will have our monthly HPy call in 40 mins. Please join https://oracle.zoom.us/j/339127822?pwd=YkNZbFgvdXZ4Z3NlcWg1N3BlZ3JTUT09

08:01 <mattip> an inline helper function seems to work

08:06 <fangerer> antocuni: please review https://github.com/hpyproject/hpy/pull/313 and https://github.com/hpyproject/hpy/pull/314

09:19 <Hodgestar> Sorry I wasn't able to actually talk on the call & missed the start. :/

09:19 <Hodgestar> I will read the minutes when they come out.

10:43 <fangerer> here are the minutes: https://github.com/hpyproject/hpy/wiki/dev-call-20220505

11:04 <cfbolz> fangerer, phlebas: if I want to read the hpy implementation in graalpython where would I start?

11:05 <cfbolz> Ah, just saw the link in the minutes

11:37 <Hodgestar> fangerer: The minutes appear to have a missing bit. The sentence "So, the proper solution is to use HPy_GetItem and have a way t" just stops at the "t".

11:45 <Hodgestar> fangerer: And thank you for the minutes -- they filled in the bits of the call that I missed.

12:39 <fangerer> ah, yes. Sorry, I was in a hurry.

14:28 <antocuni> fangerer, steve_s: I reviewed #313 and I'll try to review #314 tomorrow

14:29 <antocuni> hopefully eventually I will catch up with all the open issues and PRs, but until then if there is some PR which you want me to review, the best strategy is to ping me here

14:29 <antocuni> the hpy emails goes to their own folder and I don't always see them :)

14:30 <steve_s> 👍 thanks for the review

14:57 <fangerer> antocuni: thanks; I think #313 and #314 are the most important ones right now

14:57 <antocuni> 👍

14:57 <fangerer> Hodgestar: btw. I've fixed the imcomplete sentence

15:13 <mattip> all the static functions like DebugHandle_repr_trampoline, DebugHandle_repr_impl are being exported from universal.so

15:13 <mattip> this is problematic for c++ since the symbols are mangled, and then the import fails

15:14 <antocuni> maybe they should be declared as extern "C" ?

15:14 <steve_s> they would have to be declared as such in the header file that the C++ code that call them uses

15:14 <steve_s> but they are not in any header file?

15:15 <steve_s> who calls them?

15:15 <mattip> the import fails in "from hpy.universal import _debug"

15:15 <steve_s> yeah, that's because it's compiled with C++, but as I commented on the issue I don't think we want that.

15:16 <antocuni> I'm confused

15:16 <mattip> me too

15:16 <antocuni> those functions are compiled when you build hpy._universal, which is compiled with C

15:16 <antocuni> so, what has C++ to do with it?

15:16 <mattip> I am building with c++ as well

15:16 <antocuni> I'm not sure it's a good idea

15:16 <steve_s> yes and I don't think we need that

15:17 <steve_s> C++ extensions are going to use only the header files that's what needs to be C++ compatible

15:17 <antocuni> do we want to support extensions written in C++? Yes

15:17 <antocuni> do we want hpy itself to be written in C++? Probably not

15:17 <mattip> apparently building with c++ is indeed not a good idea. I will try to get CI to use c++ only when testing

15:19 <steve_s> yes, that would be good, but I am afraid that even the tests will not (always) be in some C/C++ intersection. I've created https://github.com/hpyproject/hpy/issues/319 for this. I think we'll have to either manually mark tests as "also C++ compatible" or even "C++ only", or have a separate test suite for C++

15:20 <steve_s> btw. CPython has this issue too and Victor is afaik adding a separate test suite for testing with C++

15:20 <antocuni> yes, I tend to agree with steve_s, although I admit I don't have much knowledge of the problem

15:23 <steve_s> another issue is that right now we compile some of the runtime C files with the extension, e.g., argparse.c, if the extension uses C++ compiler disguised as CC then those are probably going to be compiled by the C++ compiler. This will be solved if we distribute static archive with our runtime prebuilt by C, which will be statically linked with the extension.

15:25 <antocuni> yes, this is what we discussed today during the call, isn't it?

15:25 <mattip> IMO 99% of the code should just work with both c/c++ compilers, this is the expectation of many developers

15:25 <mattip> only tests that probe internals should be c specific

15:26 <steve_s> yes, not disputing that. Using HPy API from C++ should absolutely work, but I think that for that HPy itself doesn't have to be in C++

15:29 <steve_s> (or be both C and C++ compatible)

15:30 <steve_s> e.g. CPython cannot be built with C++ compiler I would believe

15:32 <mattip> +1, I moved the build to gcc, and am only running "python -m pytest" with c++

15:33 <mattip> let's see what fails once the CI is up and running properly

15:34 <steve_s> I am curious if it works. I think that would be best path forward for testing C++ compatibility

15:59 <antocuni> cfbolz, arigato, fijal, mattip, ronan: this commit contains a tentative implementation of HPyField_Load and Store: https://foss.heptapod.net/pypy/pypy/-/commit/09943367b00495c820d6bd6e0ba32a8d8a35455a

15:59 <antocuni> does it look correct? In particular, the casts between gcref and signed and back

16:00 <antocuni> a simple test which does HPyField_Store and then HPyField_Load works, so there is a non-zero chance that it's correct :)

16:01 <antocuni> but I wanted to double check because it's delicate; I've seen that jit/backend/llsupport/llmodel.py does the same thing to cast between ints and gcrefs

16:01 <antocuni> also, I haven't written the custom tracer yet, so if the GC kicks in and moves the objects, everything horribly crashes of course

16:03 <antocuni> this is the test: https://foss.heptapod.net/pypy/pypy/-/blob/09943367b00495c820d6bd6e0ba32a8d8a35455a/extra_tests/hpy_tests/_vendored/test_hpyfield.py#L165-188

16:07 <cfbolz> antocuni: it looks reasonable. These functions should be runnable too btw

16:07 <antocuni> in tests you mean?

16:07 <cfbolz> Yes

16:07 <antocuni> they don't

16:08 <antocuni> AttributeError: '_GcRef' object has no attribute '_obj'

16:08 <cfbolz> Hmmm

16:08 <antocuni> maybe you need some more complex casting to make it working

16:08 <cfbolz> What does micronumpy do?

16:08 <antocuni> like casting into ptr and/or llmemory.Address or something like that

16:09 <antocuni> I'm always confused by all the different ways that we have to represent pointers 😅

16:10 <cfbolz> Yes

16:10 <cfbolz> A big cleanup would be good but we'll

16:10 <cfbolz> well

16:10 <antocuni> I can't find the relevent code in micronumpy

16:11 <antocuni> I suppose there should be a "setitem" for arrays whose dtype is "object", but I don't find it

16:16 <antocuni> ah, maybe I found it

16:16 <antocuni> I think it's micronumpy/types.py:ObjectType._write

16:17 <antocuni> micronumpy also puts an ll_writebarrier, I wonder whether I should too

16:18 <antocuni> but apart from that, it seems it's doing the same thing as me, which is reassuring

16:19 <antocuni> cfbolz: it also contains a we_are_translated() check, so another hint that the cast doesn't work in tests

16:24 <cfbolz> antocuni: writebarrier: yes, that sounds plausible

16:25 <antocuni> I suppose that I need to put the writebarrier on the object for which I register the custom GC tracer

16:25 <antocuni> so W_HPyObject in this case

16:26 <cfbolz> antocuni: yes

16:26 <antocuni> cool, I'm glad I'm going somewhere :)