Time for a new release ? about libtommath HOT 42 CLOSED

can you please try out https://github.com/libtom/libtommath/releases/tag/v1.1.0-rc1

from libtommath.

Thanks. This new version is now in Debian/unstable.

All the best

from libtommath.

FreeBSD's port has been updated, too.

from libtommath.

Is there a fixed date we should aim for a new release at latest?

Something like Debian Code freeze...

from libtommath.

Freeze for next Debian release will begin in January.

Since libtommath is a library used by many packages, it would be great to have a release at least one month before the freeze, like end of November.

All the best

from libtommath.

Winter is coming, Debian's freeze as well...

Could you prepare a new release soonish, so I have some time to package libtommath before Debian freezes ?

All the best

from libtommath.

@sjaeckel any news about a new libtommath release before Debian freeze ?

All the best

from libtommath.

we're on the way, c.f. https://github.com/libtom/libtommath/milestone/2

from libtommath.

Now there's #143 :-/
I really don't want to release a 1.0.2 but I understand your point that you need a new release... let's see how #143 goes... we still have a bit more than a week left before the first freeze level...

from libtommath.

and we've https://github.com/libtom/libtommath/releases/tag/v1.1.0-rc2

from libtommath.

moarvm fails to compile with rc1:

gcc -c -Werror=declaration-after-statement -Werror=pointer-arith -O3 -DNDEBUG -g3  -D_REENTRANT -D_FILE_OFFSET_BITS=64 -DHAVE_LIBFFI -fPIC -DDEBUG_HELPERS -g -O2 -fdebug-prefix-map=/home/domi/debian-dev/build-area/moarvm-2018.12+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DMVM_TRACING=0 -DMVM_CGOTO=1 -DMVM_RDTSCP=1 -DMVM_BUILD_SHARED -fPIC -I/usr/local/include -I3rdparty/sha1 -I3rdparty/tinymt -I3rdparty/dynasm -I3rdparty/cmp -I3rdparty -Isrc -o src/math/bigintops.o src/math/bigintops.c
src/math/bigintops.c:64:17: error: conflicting types for ‘mp_get_double’
 static MVMnum64 mp_get_double(mp_int *a, int shift) {
                 ^~~~~~~~~~~~~
In file included from src/6model/reprs/P6bigint.h:1,
                 from src/6model/reprs.h:21,
                 from src/moar.h:128,
                 from src/math/bigintops.c:1:
/usr/include/tommath.h:217:8: note: previous declaration of ‘mp_get_double’ was here
 double mp_get_double(const mp_int *a);
        ^~~~~~~~~~~~~

Looks like there's a naming collision between moarvm and libtommath...

from libtommath.

I've logged a bug in moarvm tracker: MoarVM/MoarVM#1032

from libtommath.

I took the liberty and asked them to rename (same thread: MoarVM/MoarVM#1032) although I don't feel very lucky.
(is it me or is it Github with the problems?)

from libtommath.

I've patched moarvm with your suggestion.

Next issue is:

src/math/bigintops.c: In function ‘MVM_bigint_rand’:
src/math/bigintops.c:1166:13: error: ‘MP_GEN_RANDOM_MAX’ undeclared (first use in this function); did you mean ‘UV_ERRNO_MAX’?
         if (MP_GEN_RANDOM_MAX >= abs(smallint_max)) {
             ^~~~~~~~~~~~~~~~~
             UV_ERRNO_MAX

from libtommath.

I've patched moarvm with your suggestion.

Ah, thanks, one problem less aaaand a new one. *sigh*

MP_GEN_RANDOM_MAX is defined in bn_mp_rand.c as 0xffffffffu for the BSD flavours offering the arc4random() function. I would propose to define it in a place where MoarVM's bigintops.c can find it, e.g.:

#ifndef MP_GEN_RANDOM_MAX
#   define MP_GEN_RANDOM_MAX 0xffffffffu
#endif 

There is also the function MP_GEN_RANDOM() in the following line (1167) in bigintops.c. Is that autogenerated (couldn't find something in MoarVM with a simpel grep and it is not in LibTomMath) or will it become another source of "fun"?

from libtommath.

Probably more fun:

src/math/bigintops.c:1167:35: warning: implicit declaration of function ‘MP_GEN_RANDOM’; did you mean ‘UV_FS_O_RANDOM’? [-Wimplicit-function-declaration]
             mp_digit result_int = MP_GEN_RANDOM();
                                   ^~~~~~~~~~~~~
                                   UV_FS_O_RANDOM

from libtommath.

MP_GEN_RANDOM_MAX

and

MP_GEN_RANDOM()

was the way mp_rand() was implemented before #105

IMO this entire use_small_arithmetic branch has to be re-written in a similar style as mp_rand() is now done ...or one could simply call mp_rand() instead?!? ...

from libtommath.

uh ... This is way over my head.. I'm just packaging this stuff for Debian... :-/

from libtommath.

uh ... This is way over my head.. I'm just packaging this stuff for Debian... :-/

That's also way over my head as I've absolutely no clue about the internals of MoarVM so I guess this has to be evaluated on their side :-/

... I could offer to make the s_gen_random() function public API as mp_rand_digit() if that helps!?

from libtommath.

@sjaeckel Some observations:

• They want MP_GEN_RANDOM() tor return an mp_digit
• They ignore the returns of the mp_*() functions, at least where I looked in bigintops.c
• The different values of MP_GEN_RANDOM_MAX were meant to reflect the possible different values of RAND_MAX but the use of rand() has been dropped in LibTomMath.
• If MP_GEN_RANDOM_MAX is 0 (zero) they will use mp_rand() automatically.

The simplest but also most brutal temporary workaround would be to define MP_GEN_RANDOM_MAX to be zero and-to sooth the compiler-MP_GEN_RANDOM() as nothing.

Or we are nicer and define MP_GEN_RANDOM_MAX = 0xffffffffu and a little macro/function to make MP_GEN_RANDOM() return a mp_digit filled with random bits.

from libtommath.

Sorry, MP_GEN_RANDOM_MAX = MP_MASK would be correct. For the "being nicer" part, that is.

from libtommath.

I have successfully built moarvm and Perl6/rakudo with:

• libtommath rc1 patched with 1c8c534 and 20f2b26
• moarvm 2018.12 patched with MoarVM/MoarVM@eccbc85#r31964401 and a quick fix for this compilation error

All the best

from libtommath.

I just fixed the compilation error @dod38fr mentioned in moarvm's master branch

from libtommath.

Debian freeze has begun. Updating libtommath for next Debian stable is still possible provided the new version of libtommath is backward compatible.

When do you plan to create a new release ?

All the best

from libtommath.

can you please try out https://github.com/libtom/libtommath/releases/tag/v1.1.0-rc3

from libtommath.

To go a bit more into detail:

Updating libtommath for next Debian stable is still possible provided the new version of libtommath is backward compatible.

as of https://abi-laboratory.pro/index.php?view=compat_report&l=libtommath&v1=1.0.1&v2=current&obj=23f8c&kind=abi this is the case

thx a lot again to @lvc btw. :-)

When do you plan to create a new release ?

as soon as I got your OK

probably @antonio-rojas @dfandrich and @deadpoint want to have a look as well?

from libtommath.

sorry, I forgot to mention @gahr :-)

from libtommath.

Thanks. Not sure if something's wrong at my side, but the new tarball still produces a shared library versioned 1.0.1. Can you confirm that?

from libtommath.

...again this libtool version thing... right! thanks for pointing it out

what would be the correct new version? I'd say "VERSION_SO=2:0:1" right? or am I getting it wrong again...?

from libtommath.

mh.. I'm not an expert on shared libraries versioning, but I think the result should be that the DT_SONAME field reads libtommath.so.2, right?

from libtommath.

So, I think this should be just VERSION_SO=2.

Edit: oh, I see the API has been changed in a backwards compatible way, so yeah, 2:0:1 should be it.

from libtommath.

and there's https://github.com/libtom/libtommath/releases/tag/v1.1.0-rc4

from libtommath.

Bummer, I've just uploaded rc3 to Debian/experimental :o)

from libtommath.

There's a missing .PHONY: mtest in makefile.shared. Not that this requires a new RC :)

from libtommath.

Bummer ...

Sorry :-\

When will you be able to upload the rc4?

from libtommath.

and there's https://github.com/libtom/libtommath/releases/tag/v1.1.0-rc5 with the latest linting of @fperrad included

from libtommath.

All good on FreeBSD.

from libtommath.

All good for Tcl 8.7 as well (which will incorporate libtommath 1.1.x). I tested rc4. Thanks!

from libtommath.

ah, @mkj could be interested as well?

from libtommath.

https://www.libtom.net/news/LTM_1.1.0/

resp.

https://github.com/libtom/libtommath/releases/tag/v1.1.0

from libtommath.

FreeBSD's port has been updated, too.

@gahr I've just had a look and I've spotted that ltm is still listed as PD/WTFPL instead of the Unlicense

from libtommath.

@sjaeckel addressed, thanks.

from libtommath.