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

Updates to MOI v0.9 #144

Merged
merged 22 commits into from
Aug 18, 2019
Merged

Updates to MOI v0.9 #144

merged 22 commits into from
Aug 18, 2019

Conversation

blegat
Copy link
Member

@blegat blegat commented May 25, 2019

Also drop Julia v0.6, Julia v0.7 and transition from REQUIRE to Project.toml.

Copy link
Collaborator

@kalmarek kalmarek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In c_wrapper.jl:59 there is if VERSION >= v"0.7-"... left, please remove it as well;

The macro compat_gc_preserve could be removed and replaced by Base.GC.@preserve

Project.toml Show resolved Hide resolved
src/SCS.jl Show resolved Hide resolved
src/types.jl Outdated Show resolved Hide resolved
src/types.jl Outdated Show resolved Hide resolved
src/types.jl Show resolved Hide resolved
src/SCS.jl Outdated Show resolved Hide resolved
src/types.jl Outdated
status::Symbol
ret_val::Int

function Solution(x::Array{Float64, 1}, y::Array{Float64, 1}, s::Array{Float64, 1}, ret_val::Int)
function Solution(x::Array{Float64, 1}, y::Array{Float64, 1}, s::Array{Float64, 1}, info::SCSInfo, ret_val::Int)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please update status_map (above) according to https://github.com/cvxgrp/scs/blob/d3d1d4c49b0aede0ec491fe06c99aef5cfe598c7/include/glbopts.h#L18 (or similar in MOI_wrapper.jl)

I once opened a pull with this, but this was in pre-MOI times, so we left it for later, maybe now is the time;
maybe it's a good idea to share the definition with MOI?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The status should be one of the MPB statuses. For custom status described by SCS, this should be raw_status(info).
We should remove this from the struct since it is tied to MPB

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah no I see, we don't handle outside [-4, 1]. Let's leave it for a separate since I moved it to MPB_wrapper

if haskey(status_map, ret_val)
return new(x, y, s, status_map[ret_val], ret_val)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

its better to use get(status_map, ret_val, :UnknownError) here

return String(chars)
s = collect(info.status)
len = findfirst(iszero, s) - 1
# There is no method String(::Vector{Cchar}) so we convert to `UInt8`.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you could String(reinterpret(UInt8, s)[1:len]) as well

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we use the fact that UInt8 has the same binary representation of Cchar, we might as well store it as UInt8 in the struct

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, this is why my intial suggestion was to go with Cuchar; but this is a matter of naming/taste, so it can stay as it is now

(but this convert via array comprehension makes me wince :))

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes but I would rather have the code not depend on equivalence of bit representation just to have raw_status be slightly faster. What's wrong with array comprehension :-P ? How would you write it?

Copy link
Collaborator

@kalmarek kalmarek May 27, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not feeling strongly about it; that bike-shedding was intended as a joke ;-).
I'd probably go for reinterpret(UInt8, s[1:len]) if we really do care about this one allocation (we don't:).
Edit: hmmm or maybe we do: s = rand(Cchar, 10); UInt8[s[i] for i in 1:5] results in ERROR: InexactError ... ??
Edit: sure, but scs should not put negative chars in status...

@kalmarek
Copy link
Collaborator

@blegat after suggested changes in c_wrapper.jl this looks good to me.

@kalmarek
Copy link
Collaborator

kalmarek commented Jul 8, 2019

scs-2.1.1 has been tagged today (https://github.com/cvxgrp/scs/releases/tag/2.1.1) and I have a branch with gpu solver working from julia. It would be nice to have these in before v0.6 (or we will have 0.7 immediately after) @blegat could you postpone the version bump?

@blegat
Copy link
Member Author

blegat commented Jul 9, 2019

Not sure sure what you suggest, do you want to merge your branch before and tag v0.6 ?
The version bump is for dropping Julia v0.6 and v0.7 so if you merge your branch, drop Julia v0.6 and 0.7 and then tag v0.6 then this PR can just be v0.6.1

@kalmarek
Copy link
Collaborator

kalmarek commented Jul 9, 2019

I thought You're about to merge this soon;

scs-2.1.0 breaks binary compatibility and we have to modify SCSSettings struct accordingly (kalmarek@2c3c4c0), so that alone would be a reason to bump to v0.6;

gpu-solver is a more extensive one: kalmarek@5855610

but if you don't object, I'd prepare pulls and merge these before

@blegat
Copy link
Member Author

blegat commented Jul 9, 2019

but if you don't object, I'd prepare pulls and merge these before

Yes, this PR might be merged in a few days but you should have time to do it before. Just make sure to drop Julia v0.6 and v0.7.

@kalmarek kalmarek mentioned this pull request Jul 11, 2019
.travis.yml Show resolved Hide resolved
.travis.yml Outdated Show resolved Hide resolved
after_success:
- julia -e 'cd(Pkg.dir("SCS")); Pkg.add("Coverage"); using Coverage; Coveralls.submit(Coveralls.process_folder())'
- julia -e 'import Pkg; Pkg.add("Coverage"); using Coverage; Coveralls.submit(process_folder())'
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that a simple - coveralls: true should do, according to docs:
https://docs.travis-ci.com/user/languages/julia/#coverage

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It worked on MOI and JuMP but it gives a weird error here:
https://travis-ci.org/JuliaOpt/SCS.jl/jobs/571513843#L936-L978
Maybe it works with codecov but not with coveralls

appveyor.yml Show resolved Hide resolved
blegat and others added 4 commits August 13, 2019 21:04
We can still see the outcome, but GitHub does not consider it a failed test.
I think this makes sense, since Julia 1.2 is not released yet?
@blegat blegat merged commit c6facfd into master Aug 18, 2019
@odow odow deleted the bl/moiv0.9 branch October 8, 2020 01:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants