dss-extensions/dss_capi

Fix custom_link.sh to work with fpc 3.2.2

beroset opened this issue · 7 comments

beroset commented

As of fpc 3.2.2, external link scripts are no longer named link.res but link{pid}.res where the {pid} is substituted with the process ID of the running instance of fpc. This means that custom_link.sh no longer works because it assumes the old name.

PMeira commented

Switching FPC versions require some extensive testing in all platforms. But, since we probably can drop custom_link.sh issue for the planned v0.13, it's better to just wait for that before upgrading. I doubt dropping it now would cause any issues, but just to be sure, it's better to follow the plan to avoid surprises.

As a side note, I know that FPC 3.2.2 is important due to native mac M1 support, but the number of mac users in general is small, (hence M1 users even smaller).

PMeira commented

@beroset Not sure why you're building the master branch, but I'd suggest sticking to the 0.10.x branch unless you plan to contribute something major (if so, please communicate to keep coordination). For 0.10.x and earlier, there are binaries on the Releases page.

PMeira commented

Closing in favor of #101 and #102, which are more explicit.

beroset commented

You may wish to add instructions for contributors to make it clear how you'd prefer that to be done. See https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors

PMeira commented

Yep, someday. This repo is not the kind that's easy to contribute, the language bindings are more welcoming.
In the current shape, I don't really expect any major contribution without any previous discussion after ~3.5 years of this being public, especially given the current constraints -- e.g. it's a Pascal codebase in 2021 (IIRC my university has dropped teaching Pascal in 2004), and we cannot deviate too much from EPRI's implementation.
There are plans to make it easier to contribute in the future, yet this year I wouldn't expect too much. I'm still in a WFH setup etc.

On this issue itself, I waited three weeks before closing it, and as I mentioned, the other two issues created are more explicit. Most issues here are used for planning, with an occasional bug report.
I'm following some potential issues with FPC 3.2.2 through its bugtracker (which was recently migrated to GitLab: https://gitlab.com/freepascal.org/fpc/source/-/issues/ ). If you're interested, check this thread to see why I'm hesitant to upgrade to 3.2.2 without extensive testing first: https://sourceforge.net/p/electricdss/discussion/861976/thread/7172875585/

beroset commented

I understand entirely and thank you for your efforts with this valuable project! My interest in FPC 3.2 is not for Apple M1 but rather because it can target WebAssembly. Perhaps I'll see about contributing unit testing to the base EPRI project.

PMeira commented

but rather because it can target WebAssembly.

I tried WebAssembly with FPC a while ago but it was very incomplete. Not sure about FPC 3.2.2, but from the roadmap
at https://wiki.freepascal.org/WebAssembly/Roadmap it seems that exceptions might be one of the major features missing.

If there are issues with file handling, the changes from 458f5c7 show that we can wrap everything and expect it to work (see also #96).

Besides that, I imagine linking with KLUSolve(X) might need some work, but C and C++ support for WebAssembly is more complete/mature.

Perhaps I'll see about contributing unit testing to the base EPRI project.

That'd be great. A basic testing suite would catch a lot of minor and some major issues. Right now, I don't think there is anything available publicly from EPRI. I know some other things (e.g. OpenDSS-G, OpenDSS Viewer, OpenDSS-GIS) are closed source, so I imagine they could have something internal. From some messages in the forum, it seems the bug tracker is also internal.