XHashTable

[Ralf Hemmecke]

I just came across the problem that api.spad does not compile anymore,
because of the introduction of Hashable.

I will try to provide a patch, but only later today.

There seems also to be a problem with XHashTable. XHashTable can export
Hashable when also the Entry type has Hashable. At a quick glance it
seems that XHashTable has lost hashUpdate! (although it was never used).

I rather tend not to change XHashTable before the release and it is a
bit questionable whether I should add a conditional export of Hashable.
Opinions?

But api.spad must be fixed before the release. Sorry that I have not
seen this earlier.

Ralf

[Waldek Hebisch]

On Mon, Jun 26, 2023 at 01:39:42PM +0200, Ralf Hemmecke wrote:
> I just came across the problem that api.spad does not compile anymore,
> because of the introduction of Hashable.
>
> I will try to provide a patch, but only later today.
>
> There seems also to be a problem with XHashTable. XHashTable can export
> Hashable when also the Entry type has Hashable. At a quick glance it seems
> that XHashTable has lost hashUpdate! (although it was never used).

I hope that no domain lost _working_ hashUpdate!. Before introduction
of Hashable _everything_ of SetCategory claimed to have hashUpdate!,
but only limited number of domains implemented it. It is possible that
some domains got default implementation of hashUpdate! that would
fail at runtime because it called unimplemented functions.

> I rather tend not to change XHashTable before the release and it is a bit
> questionable whether I should add a conditional export of Hashable.
> Opinions?

Well, if you implement hashUpdate! you should add appropriate export...

> But api.spad must be fixed before the release. Sorry that I have not seen
> this earlier.

There is some delay. Basically, resonably safe patches and fixes can go
in up to June 30.

--
Waldek Hebisch

[Ralf Hemmecke]

On 26.06.23 15:02, Waldek Hebisch wrote:
> On Mon, Jun 26, 2023 at 01:39:42PM +0200, Ralf Hemmecke wrote:
>> I just came across the problem that api.spad does not compile anymore,
>> because of the introduction of Hashable.
>>
>> I will try to provide a patch, but only later today.

This patch only is only essential to build the data for
fricas.github.io/api.

https://github.com/fricas/fricas/pull/130

Unfortunately, the sphinx build ends with ... (see below).
I must investigate further. So the pull request must wait until I
figured out the problem.

But I am pretty sure that is rather a problem with the ++ docstrings of
some file being not correctly handled by my automatic translation from
++ docstring to .rst format.

Ralf

/dev/shm/hemmecke/fricas/b/src/doc/tmp/sphinx/source/api/SymmetricGroupCombinatoricFunctions.rst:20:
WARNING: Inline emphasis start-string without end-string.

Exception occurred:
File
"/home/hemmecke/HDD/hemmecke/software/virtualenv/sphinx/lib/python3.10/site-packages/sphinx/ext/extlinks.py",
line 103, in role
title = caption % part
TypeError: not all arguments converted during string formatting
The full traceback has been saved in
/dev/shm/hemmecke/fricas/b/build/x86_64-linux-gnu/sphinx-err-37rczw9d.log,
if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error
message can be provided next time.
A bug report can be filed in the tracker at
<https://github.com/sphinx-doc/sphinx/issues>. Thanks!
make[1]: *** [Makefile:20: html] Error 2
make[1]: Leaving directory '/dev/shm/hemmecke/fricas/b/src/doc/tmp/sphinx'
make: *** [Makefile:967: stamp-html] Error 2