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

Request for a new release #394

Closed
FabienPean opened this issue Feb 3, 2023 · 35 comments · Fixed by #413
Closed

Request for a new release #394

FabienPean opened this issue Feb 3, 2023 · 35 comments · Fixed by #413

Comments

@FabienPean
Copy link
Contributor

Hi there, to finalize the merge of microsoft/vcpkg#29248, it would be better to have a new release so that the vcpkg port can follow readily the versioning scheme of the repo. Is it something possible ? Otherwise I would need to backport as patch all the recent work to make it work on windows too. Feasible but cumbersome (and anyway temporary)

@fghoussen
Copy link
Collaborator

Is it something possible ?

Yes! @sylvestre: what do you say?

@sylvestre
Copy link
Contributor

sure, do you want to do it @fghoussen ? :)

@fghoussen
Copy link
Collaborator

sure, do you want to do it @fghoussen ? :)

OK, I'll try to have a look by the week-end

@fghoussen
Copy link
Collaborator

fghoussen commented Feb 11, 2023

@sylvestre: release tag pushed on opencollab/master
@FabienPean: when ready, you can detail how to build/run on windows here https://github.com/opencollab/arpack-ng#windows-support

@sylvestre
Copy link
Contributor

@fghoussen seems that we have some changes in this release that we should probably fix

usr/include/arpack-ng/ when it was installed in usr/include/arpack/ before
same for the cmake
it will break a bunch of program for no good reason.

@fghoussen
Copy link
Collaborator

fghoussen commented Feb 11, 2023

usr/include/arpack-ng/ when it was installed in usr/include/arpack/ before. same for the cmake

Install directory had to be changed to allow for compatibility with mingw64 and installing different flavors in the same install root directory #358 #330.

@sylvestre
Copy link
Contributor

Honestly, i don't think mingw64 should be the cause of significant changes...

I think we need to revert these changes asap and publish a new release.

@sylvestre
Copy link
Contributor

the different flavors should be done behind an option as it isn't a common case compared to the rest

@fghoussen
Copy link
Collaborator

Let's see if #398 is enough to fix this

@fghoussen
Copy link
Collaborator

@sylvestre: did you release 3.9.1?

@sylvestre
Copy link
Contributor

nope, I thought you were going to :)

Should I ?

@fghoussen
Copy link
Collaborator

Should I ?

Yes! :)

@szhorvat
Copy link
Contributor

Are you aware of any new issues with 3.9.0? I am currently trying to debug the following: igraph/igraph#2311

@fghoussen
Copy link
Collaborator

Are you aware of any new issues with 3.9.0? I am currently trying to debug the following: igraph/igraph#2311

Do you reproduce the same issue with arpack-3.8.0 or lower? Using same version of compiler /sanitizers ?

The only issue (which should not be an issue to me) I could think of would be #80 / JuliaLinearAlgebra/Arpack.jl#138. Not sure however, it's connected to your issue.

In 3.9.0, the only known issue was #398 (fix merged in master)

@fghoussen
Copy link
Collaborator

fghoussen commented Feb 15, 2023

Are you aware of any new issues with 3.9.0? I am currently trying to debug the following: igraph/igraph#2311

According to your stack (using sanitizers), I guess you use "your" hand-made eigen solve: did you try using https://github.com/opencollab/arpack-ng#eigen-support or https://github.com/opencollab/arpack-ng#iso_c_binding-support?

@fghoussen
Copy link
Collaborator

Are you aware of any new issues with 3.9.0? I am currently trying to debug the following: igraph/igraph#2311

This kind of thing (https://github.com/igraph/igraph/blob/d6796015974f66bcf0e3711593c64c55ff81fdef/src/linalg/arpack.c#L1065) always hide evil you don"t want to deal with thanks to ISO_C_BINDING

@szhorvat
Copy link
Contributor

szhorvat commented Feb 15, 2023

I'm not sure if using ISO_C_BINDING is feasible for us, as igraph also bundles an older f2c'd version of ARPACK. This is important for our target audience, who are typically researchers inexperienced with programming.

However, I finally managed to reproduce the issue completely independently of igraph, using only Octave. The problem is present only with 3.9.0, but not with 3.8.0. Could you please take another look, @fghoussen ? Note that I amended some of the earlier comments I made: igraph/igraph#2311

@fghoussen
Copy link
Collaborator

Does octave uses ICB? If igraph and octave does not use ICB, there is yet a possibility that both suffer from bad-ugly-old way to link from F77 to C using ugly tricks (link to "underscored" function symbols): then, compilers can not check anything but pass data blindly basically as (void*)... This is risky and hell to debug.

not sure if using ISO_C_BINDING is feasible for us, as igraph also bundles an older f2c'd version of ARPACK.

Using ICB should be seamless:

  • Compile arpack-ng with ICB: you'll get both ICB and regular fortran symbols
  • Add #include "arpack.h" in your C code
  • Replace all [sdcz][ae]upd call by [sdcz][ae]upd_c: *_c are ICB compliant functions (with same arguments than original fortran functions)

@sylvestre
Copy link
Contributor

@fghoussen is it time to take 3.9.1 ? thanks

@fghoussen
Copy link
Collaborator

Sure! Go for it :)

@szhorvat
Copy link
Contributor

It would be nice to reach a conclusion for #401. I hope that a minimal example written in C using ICB (coming soon) will be sufficient for you to continue investigating.

@fghoussen
Copy link
Collaborator

fghoussen commented Feb 28, 2023

It would be nice to reach a conclusion for #401

To me, as the #401 case works with arpackmm (you can try it), it sounds like the problem is in igraph (misuse?)

@szhorvat
Copy link
Contributor

It feels like we are not talking to each other, but in parallel.

You have not tested the specific scenario I described, always ignoring critical details.

You have claimed misuse several times, without pointing out any specific instance of misuse.

As I said, a minimal example in C is incoming. I hope that we can use that as a baseline.

@fghoussen
Copy link
Collaborator

@fghoussen is it time to take 3.9.1 ? thanks

@sylvestre: 3.9.1 does not show up here https://github.com/opencollab/arpack-ng/tags so we can't make a release entry here https://github.com/opencollab/arpack-ng/releases. #428 Is this normal?

@sylvestre
Copy link
Contributor

i don't think we tagged it, just push or create the tag :)

@fghoussen
Copy link
Collaborator

just push or create the tag

Uuuh... Do you have/remind SHA1 of 3.9.1?... I don't!...

@sylvestre
Copy link
Contributor

just recreate it, we never released 3.9.1 afaik

@szhorvat
Copy link
Contributor

szhorvat commented Sep 7, 2023

Can we have a 3.9.1 soon please? I'd like to have the fixes to the issue that affected igraph. There can always be a 3.9.2 that includes the improvements for which there are open PRs at the moment.

@sylvestre
Copy link
Contributor

@fghoussen would you like me to do it if you don't have time ?

@fghoussen
Copy link
Collaborator

@fghoussen would you like me to do it if you don't have time ?

Sure. Currently between 2 confs/sites, not back home before again another week. Can't help before returning.

@szhorvat
Copy link
Contributor

Can we have this issue re-opened to make sure it won't get forgotten?

@sylvestre sylvestre reopened this Sep 25, 2023
@szhorvat
Copy link
Contributor

Any update on a new release?

@fghoussen
Copy link
Collaborator

Can't handle that at the time. @sylvestre: can you?

@sylvestre
Copy link
Contributor

done, sorry it took forever

@sylvestre
Copy link
Contributor

Note that we would be happy to have more help with arpack, review PR, preparing releases, answering to bug reports, etc

I have 0 usage of it. I continue maintaining it because a lot of software rely on it.

So, if you are a company / university relying on it, don't hesitate to contribute / help

cc @SciTonio ;)

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

Successfully merging a pull request may close this issue.

4 participants