-
Notifications
You must be signed in to change notification settings - Fork 33
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
Comments
Here are the notes from today's meeting, to outline the steps: -1) make an update-1.0 branch based on my cxx_wrap
=====
=====
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.) |
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. |
Sure. The current status is that everything from -1 to 8 (including) is done. Precompilation is also already working. |
@steenpass does this mean you commented out everything? What exactly is working then? |
No, I didn't have to comment anything out to make |
|
The current status is that |
@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! |
@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. |
@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. |
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 :) |
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. |
This issue should be fixed with #62. |
pass flag to p_Reduce
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.
The text was updated successfully, but these errors were encountered: