Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update to Julia 1.0 #60

Closed
steenpass opened this issue Oct 26, 2018 · 13 comments
Closed

update to Julia 1.0 #60

steenpass opened this issue Oct 26, 2018 · 13 comments

Comments

@steenpass
Copy link
Contributor

We are currently updating Singular.jl to make it ready for use with Julia 1.0.
The development is being done in the branch 'update-1.0' in my repository, on top of the current rewrite for CxxWrap, see:
https://github.com/steenpass/Singular.jl/tree/update-1.0
We will announce the progress we are making as comments to this issue.

@wbhart
Copy link
Contributor

wbhart commented Oct 26, 2018

Here are the notes from today's meeting, to outline the steps:

-1) make an update-1.0 branch based on my cxx_wrap

  1. Open a ticket on Oscar Singular.jl (mention where development is happening)

  2. Put Julia 0.7 on your machine

  3. using Pkg

  4. ] dev https://github.com/wbhart/Singular.jl (press backspace to get out of Pkg mode)

  5. cd ~/.julia/dev/Singular

  6. git checkout update-1.0

  7. edit .git/config
    add a line in the origin remote
    pushurl = https://github.com/youraccount/Singular.jl

  8. ] build Singular (and fix all the problems in Singular/deps/build.jl)

=====

  1. Comment out everything until Singular starts (everything except Singular.jl)

=====

  1. Rewrite docstring format (Markdown) : look in AbstractAlgebra or Nemo

  2. Rewrite types

immutable type

=> struct


type

=> mutable struct


function check_parent{T <: Nemo.RingElem}(a::spoly{T}, b::spoly{T})

=>

function check_parent(a::spoly{T}, b::spoly{T}) where T <: Nemo.RingElem


Void => Nothing


Many functions have been moved out of Base


Strings -> Look at Nemo for examples of how to fix these


Merge latest patches from master into cxx_wrap


Get precompilation working for us with CxxWrap (should now work with Julia-1.0, according to the developers)

(@thofma probably knows the answer to a lot of porting questions, as he already ported AbstractAlgebra, Nemo and Hecke over to Julia-1.0.)

@wbhart
Copy link
Contributor

wbhart commented Oct 29, 2018

Guys, I forgot to add something very important at our meeting the other day:

I promised the people in Aachen that we would focus on getting n_Q, spoly and sideal, up to and including std, working first. Can you please make these three the absolute priority, as they will be needed before anything else.

@steenpass
Copy link
Contributor Author

Sure. The current status is that everything from -1 to 8 (including) is done. Precompilation is also already working.

@sebasguts
Copy link
Contributor

@steenpass does this mean you commented out everything? What exactly is working then?

@steenpass
Copy link
Contributor Author

No, I didn't have to comment anything out to make build Singular and using Singular work. I still get a lot of warnings when running using Singular for the first time, though. Not quite sure what is actually working.

@steenpass
Copy link
Contributor Author

  1. is solved. 👍

@steenpass
Copy link
Contributor Author

The current status is that build Singular and using Singular work in Julia 1.0. All tests pass, but at the end of the test suite, a segfault occurs somewhere below jl_gc_run_all_finalizers.

@fingolfin
Copy link
Member

@wbhart just pointed out to me that work on this was being done -- I only looked for commits on this repo, though, thus I never saw this issue. Anyway, now read through it, and it seems you folks are making great progress. Thank you very much for your efforts on this!

@wbhart
Copy link
Contributor

wbhart commented Nov 9, 2018

@fingolfin I think this sort of thing is unavoidable. Whilst we could have made commits in a branch of this repo, it isn't really good practice to push commits to the official repo. And making PR's to a branch of the official repo is just going to slow the work down. So I think the practice of doing such work in one's own repo, then making a PR when it is ready, is the best way to do the work, albeit with a ticket on the main repo to keep track of the progress.

@wbhart
Copy link
Contributor

wbhart commented Nov 9, 2018

@fingolfin Probably a better strategy would have been to post updates to oscar-dev, or at least one post pointing to this ticket.

On the other hand, too much communication is not helpful either. I am currently getting hundreds of emails for discussions on tickets on the Gap work you and Sebastian and Thomas are doing. I don't have time to read all that, so I'm thinking of unsubscribing from updates on that repo. So it cuts both ways.

Of course I still need to see any questions you direct at me. Maybe GitHub has an option that only notifies me of such posts.

@fingolfin
Copy link
Member

Let me clarify: none of my remarks above were a complaint. To the contrary, I felt need to justify why I hadn't noticed your work (which resulted in me writing in the GAP status report that we are waiting for it, but w/o a pointer to this work).

As to which workflow you use, again, no need to justify that to me either, there are many, many ways to do these things, and what is best depends on the kind of work being done, the people involved and other factors. Just to mention: for @sebasguts and me, it was/is actually quite beneficial to work with PRs against the main repo -- but of course we are doing incremental work, and want CI & code coverage reports on every change, plus reviews; while if you are converting a code base, that is probably less useful.

I also don't subscribe to this and other repos, precisely for the same reason you are contemplating to unsubscribe from GAPJulia (you probably should). IMHO, wading through heaps of GitHub notifications is one fo the top unsolved problems for using GitHub. The best compromise I found so far is to use the "Not watching" setting, and hoping that people will @-notify me if my input is requested (these will indeed still get through; you are also notified if an issue is assigned to you, or a PR review is requested). That said, I really wish they had a mode where you got an email for every new issue and PR, but then no status updates, unless you subscribed to that issue. I actually suggested that to them years ago, and I am sure many others did as well; but obviously nothing happened. But hey, they've been doing a lot of nice "anti-papercut" updates this past year, so there is still some hope :)

@wbhart
Copy link
Contributor

wbhart commented Nov 9, 2018

It should be possible to subscribe to the main repository. The traffic shouldn't be high. Of course, if you aren't working on Singular.jl, then no need. We will @fingolfin you.

@steenpass
Copy link
Contributor Author

This issue should be fixed with #62.

fingolfin pushed a commit to fingolfin/Singular.jl that referenced this issue Jun 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants