Autogenerate headers

[videlec]

As discussed in #28 and revived in Sage trac ticket #24531 we discuss the possibility of (partially or completely) auto generating paridecl.pxd from (one or both of) pari.desc or paridecl.h.

[jdemeyer]

Does #56 solve your problem?

[videlec]

It gets better. Why should we keep such a big paridecl.pxd if almost everything is already inside auto_paridecl.pxd? Making it minimal, we wouldn't have to worry about signature changes in upstream.

[jdemeyer]

almost everything is already inside auto_paridecl.pxd

This statement is simply not true: auto_paridecl.pxd contains only declarations for functions which are accessible from GP. There are a lot more functions in PARI which are not directly exposed to GP. Those are only in paridecl.pxd.

Making it minimal, we wouldn't have to worry about signature changes in upstream.

With #56 we don't have to worry either: the declarations from auto_paridecl.pxd override the ones from paridecl.pxd

[jdemeyer]

@videlec Can you explain better what you have in mind? Are you thinking about a script to remove duplicate declarations...?

[videlec]

One of

• use pari.h header
• manually remove as much as we can from paridecl.pxd. If there is no duplicate with the current auto_paridecl.pxd it should be a small list.

[jdemeyer]

manually

Really? Do you volunteer for that? It's a waste of time for zero gain.

[jdemeyer]

Also, there are two further issues with your proposal:

1. It makes it harder to maintain paridecl.pxd. The manual removal would need to be done every time that we update that file.

2. The contents of auto_paridecl.pxd depend on the PARI version, while paridecl.pxd does not. So if there is a function which appears in paridecl.pxd and it appears in auto_paridecl.pxd only for some PARI versions, what do we do?

[videlec]

1. It makes it harder to maintain paridecl.pxd. The manual removal would need
   to be done every time that we update that file.

2. The contents of auto_paridecl.pxd depend on the PARI version, while
   paridecl.pxd does not. So if there is a function which appears in paridecl.pxd
   and it appears in auto_paridecl.pxd only for some PARI versions, what do we do?

The main point is to make paridecl.pxd lighter now. I never claimed that it needs to be up to date with the PARI/GP headers.

[jdemeyer]

The main point is to make paridecl.pxd lighter now.

But why? That does not fix any problem but it does create new problems. So it's a negative move for me.

[jdemeyer]

I never claimed that it needs to be up to date with the PARI/GP headers.

Ideally, it should be reasonably up-to-date. Now and then, it will need to be updated.

[defeo]

I never claimed that it needs to be up to date with the PARI/GP headers.

Ideally, it should be reasonably up-to-date. Now and then, it will need to be updated.

This seems to be the main point of disagreement. Jeroen wants to keep updating paridecl.pxd manually, a task which would render the cleanup of paridecl.pxd tedious.

Vincent wants to auto-generate paridecl from the C headers. I'm not going to enter in the merit of this proposal (my opinion is that this is reasonable, even without a proper C parser). I just want to give my 2 cents by saying that, as long as we do not autogenerate it, it seems wasteful to do a manual cleanup.

Better to have the largest possible paridecl.pxd, easy to semi-automanually produce and covering as many versions as possible, than to do some tedious work that risks breaking things for some users.

[videlec]

I am not discussing now how auto_paridecl.pxd is generated but what should be the respective role of paridecl.pxd and auto_paridecl.pxd.

Different pari versions have different functions (and possible same functions with different signatures). This is the very reason of the existence of auto_paridecl.pxd. My wish is to minimize paridecl.pxd because after #56 most of the declarations are actually overriden by auto_paridecl.pxd (and you have to read the last line of paridecl.pxd to understand that).

• The current situation is confusing for people using cypari2 as there are conflicting function declarations in paridecl.pxd and auto_paridecl.pxd.
• Having smaller files for the very same result is good.

[defeo]

Different pari versions have different functions (and possible same functions with different signatures). This is the very reason of the existence of auto_paridecl.pxd. My wish is to minimize paridecl.pxd because after #56 most of the declarations are actually overriden by auto_paridecl.pxd (and you have to read the last line of paridecl.pxd to understand that).

Let's document this, then.

The current situation is confusing for people using cypari2 as there are conflicting function declarations in paridecl.pxd and auto_paridecl.pxd.

But that's unavoidable (in principle), if we want to support many different PARI version at once.

Having smaller files for the very same result is good.

Jeroen is saying that maintaining smaller files costs more maintainance work. I can understand that argument, especially given the small number of maintainers. Luca

[videlec]

The current situation is confusing for people using cypari2 as there
are conflicting function declarations in paridecl.pxd and auto_paridecl.pxd.

But that's unavoidable (in principle), if we want to support many
different PARI version at once.

It is avoidable! All functions that depend on PARI versions are in auto_paridecl.pxd which is generated on the fly. We currently have wrong function declarations in paridecl.pxd overriden by auto_paridecl.pxd because of the header inclusion.

[jdemeyer]

All functions that depend on PARI versions are in auto_paridecl.pxd which is generated on the fly.

As I have commented above, this statement is completely false. This is probably the main source of confusion.

[videlec]

All functions that depend on PARI versions are in auto_paridecl.pxd which is generated on the fly.

As I have commented above, this statement is completely false. This is probably the main source of confusion.

You might have misread (at least your reference to the above comment is unrelated). I never claimed that we can rid of paridecl.pxd. Just that (currently) the functions that do change between PARI versions are taken care of in auto_paridecl.pxd.

[defeo]

You might have misread (at least your reference to the above comment is unrelated). I never claimed that we can rid of paridecl.pxd. Just that (currently) the functions that do change between PARI versions are taken care of in auto_paridecl.pxd.

Yeah. "currently". That's the same thing I meant by "in principle". Currently we are supporting a very narrow range of PARI versions, so it is no surprise that all functions that have changed signature are auto-generated. Are we positive that this is not going to change soonish? A non-autogenerated function in `paridecl.pxd` might end up being autogenerated, and even with a different signature, in the next version.

[defeo]

Anyway, speaking of wasting energies: the time this discussion is taking would have been sufficient to cleanup `paridecl.pxd` by hand. If you make a PR doing exactly that, I don't think anyone is going to reject it.

[videlec]

See #58