Load flint

[fingolfin]

Closes #818

[fingolfin]

@wbhart Does this look OK to you?

[fingolfin]

@benlorenz I guess you can now turn your Polymake.jl branch into a PR there, too?

[wbhart]

@fingolfin It's a shame we need to do this. But given that we have to, it's ok by me.

[fieker]

unless someone cmplains by tomorrow, I shall merge

[fingolfin]

@fieker so are those random crashes resolved, or do they still need to be debugged?

[fieker]

On Tue, Mar 24, 2020 at 11:41:54AM -0700, Max Horn wrote: @fieker so are those random crashes resolved, or do they still need to be debugged?

They are solved and understood. There were pockets of code using :libflint and they loaded a new flint - why, I don't know. Switching them all to libflint (no:) helped

…

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #819 (comment)

[benlorenz]

I think the dlopen statements in lines 234 and 236 should also be removed now.

[fieker]

On Wed, Mar 25, 2020 at 01:39:47AM -0700, Benjamin Lorenz wrote: I think the dlopen statements [in lines 234 and 236](https://github.com/Nemocas/Nemo.jl/pull/819/files#diff-b717d684b368627522b30dc156f9dad4L234-L236) should also be removed now.

They don't hurt as the path is the correct one, but they are nolonger neccessary - in case they ever were.... I think this was just an (misguided) attempt at loading and using the correct gmp and mpfr. Initially it was a question of faith to not use the juilia provided one: it was too old...

…

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #819 (comment)

[thofma]

The welcoming message is screwed up because we missed to adjust version() in src/Nemo.jl.

[fieker]

On Wed, Mar 25, 2020 at 03:25:21AM -0700, thofma wrote: The welcoming message is screwed up because we missed to adjust `version()` in `src/Nemo.jl`.

We need to document our workflows... Can't this be derived from - project.toml - github? The official number, without -dev should be in Project.toml It should be possible to use this to get the corresponding sha and to compare them? And then add dev if they differ? For now: increase version and fix? Or ignore? The goal is to convince Polymake to do the same and then finally register Oscar

…

-- You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub: #819 (comment)

[thofma]

The local Nemo installation is not always a git repository, so there is no sha to get.

We can just ignore it for the moment.

[benlorenz]

The goal is to convince Polymake to do the same and then finally register Oscar

Polymake 0.3.2 with LoadFlint dependency is registered and available for installation via add. Tag will be created by tagbot very soon.

[fieker]

On Wed, Mar 25, 2020 at 03:52:42AM -0700, Benjamin Lorenz wrote: > The goal is to convince Polymake to do the same and then finally register Oscar Polymake 0.3.2 with LoadFlint dependency is registered and available for installation via `add`. Tag will be created by tagbot very soon.

Great!!! then I can play with Oscar again..

…

-- You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub: #819 (comment)

[fieker]

On Wed, Mar 25, 2020 at 03:52:12AM -0700, thofma wrote: The local Nemo installation is not always a git repository, so there is no sha to get.

--- but then its sofficial and not dev? Previous email: its wrong in Nemo...

We can just ignore it for the moment.

Good.

…

-- You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub: #819 (comment)

[thofma]

It is an implementation detail of the package manager. Sounds rather fragile to me, also the version of Nemo is an internal state not depending on whether it is dev'ed or not.

Alternatively we remove the welcome message and the version() altogether.

[fieker]

On Wed, Mar 25, 2020 at 04:11:36AM -0700, thofma wrote: It is an implementation detail of the package manager. Sounds rather fragile to me, also the version of Nemo is an internal state not depending on whether it is dev'ed or not. Alternatively we remove the welcome message and the `version()` altogether.

I think we should have this - consostently across all our packages. For me, I'd put the version at the top of the file, directly after module ... then it is easy to find. Do you know how other projects are dealing with it? Storing the version in different places sounds like an invitation to disaster

…

-- You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub: #819 (comment)

[thofma]

No one else prints a welcoming message so this problem does not arise.

[fieker]

On Wed, Mar 25, 2020 at 04:11:36AM -0700, thofma wrote: It is an implementation detail of the package manager. Sounds rather fragile to me, also the version of Nemo is an internal state not depending on whether it is dev'ed or not. Alternatively we remove the welcome message and the `version()` altogether.

Indeed the versioninfo is totally broken. julia changes Base.LibGit2 in 1.4 does not work, it has to be import LibGit2 (with additions to Project.toml...) Some of the implementation details have changed.

…

-- You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub: #819 (comment)

[fieker]

On Wed, Mar 25, 2020 at 04:16:22AM -0700, thofma wrote: No one else prints a welcoming message so this problem does not arise.

And no-one supports getting version info? Relying completely on Julia? Maybe thasts the way...

…

-- You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub: #819 (comment)

[thofma]

If one wants to know the specific version of a package in the current environment, one just asks for Pkg.status().

We can remove versioninfo() alltogether. It has been broken for a long time.

[rfourquet]

I think there would be a way to automatize initialize the version number (I just tested it but I might be overlooking something). It would require to add the Pkg and UUIDs packages as dependencies. Then we initialize a global constant NEMO_VERSION at compile time using Pkg.dependencies() or Pkg.installed() depending on the julia version (this seems to add about half a second of compilation), which can be shown in __init__. Again I migth misunderstand something, but I can prepare a PR if you like the idea.

[thofma]

What would be the condition to add the dev?

[rfourquet]

What would be the condition to add the dev?

I'm not certain, but I observe that in some cases the version has a "+" appended which could mean "dev'ed", but it doesn't seem reliable, I will try to find out.

[rfourquet]

Ok, so the "+" seems to be appended for packages without a version indicated in the Project.toml file. One solution apparently would be to set the version to "0.16.4+" or "0.16.4-DEV" in Project.toml in a commit after the release, which will be reflected in NEMO_VERSION. But this is still a manual step then.

[thofma]

This would be the a similar step that we have now. At the moment we don't change the Project.toml version to 0.16.4-DEV, since there is no recommended way to do that (see JuliaLang/Pkg.jl#351). Instead we manually change Nemo.version() manually after a step.