MALOC modernization

[sobolevnrm]

It's no longer needed and takes extra effort to maintain.

[sobolevnrm]

The most likely modernization route here is just to delete the library.

[ashermancinelli]

This issue is being developed in branch remove-maloc-dev

[ashermancinelli]

@sobolevnrm In the branch mentioned above, I've removed maloc as a dependency. I haven't changed too much, just copied five header/source pairs into another subdirectory of src. Would you like to iteratively replace the remnants of maloc as well or are we content with this solution?

CC @intendo

[sobolevnrm]

I don't think we need to rewrite MALOC. If native functionality is available to replace MALOC functionality, then that's all we need.

[ashermancinelli]

So would you like to leave a few components of maloc in the repo like in remove-maloc-dev branch? If we go the native functionality route, we'd probably want to refactor pieces of apbs source into C++. Biggest MALOC component used is Vio/socket stuff I think, we could replace all that with std::string. APBS/MALOC sources seem compile-able in C++ already anyways, but you know better than I if it would be too invasive to convert to c++.

[sobolevnrm]

I think it's best to replace whatever we can with native functionality and then see what's left?

…

On Sat, Oct 10, 2020 at 10:00 AM Asher Mancinelli ***@***.***> wrote: So would you like to leave a few components of maloc in the repo like in remove-maloc-dev branch? If we go the native functionality route, we'd probably want to refactor pieces of apbs source into C++. Biggest MALOC component used is Vio/socket stuff I think, we could replace all that with std::string. APBS/MALOC sources seem compile-able in C++ already anyways. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOX7WFFQJXAAQWGRVEHB33SKCHJZANCNFSM4OQBZVXQ> .