rcthomas / resist Goto Github PK

Our makefile only assumes gcc right now, we ought to set it up so that we can replace that in a non ugly way on our various platforms we test with. We don't need to go to cmake yet, but it would be nice to make sure things just work when we do a checkout.

To run the code we need to configure it and provide it with execution setups to evaluate. There is a stub for app configuration with JSON but no implementation as yet. At some point we will want to address this question, but some thoughts are:

• Let's keep whatever parsers we depend on as light-weight/low-footprint things we can just incorporate.
• We should think about more than file-based configuration/setup control; for instance we may send the app actual JSON from another application, so the interface needs to accept JSON and not assume it's always just a file.

Anticipating that this will be an MPI application, we need sane tools for reporting errors, exiting gracefully (or angrily), printing to STDOUT or STDOUT or a file, etc.

We need to start setting up unit tests. They don't have to be written using any fancy unit testing framework, but we should at least have tests to start watching out for regressions in terms of functionality.

Since this will be pure C, we have the great luxury of being able to use GNU indent to do this for us.

We want to be able to compile with or without high-bandwidth memory specializations and experiment with padding. The place to put this is probably in resist-memory.h.

Once these are defined we should carefully replace all the memory management commands in the code with our special versions.

Currently we have

...
ptr = (type*) resist_malloc(size);
assert(ptr);
...

which leads to lots of asserts pasted all over the code base. We can make this more succinct by putting the assert in the allocator itself.

The C standard defers the behavior of #include "..." to the implementation of each compiler. In praxis, most compilers interpret this as "look in $PWD for the requested header file." However, "#include <...>is defined by the standard: the compiler will look in any directories included in-I

This would result in less verbose code.

The Intel compiler does not enable C99 features by default, and as a result, it fails to compile resist-context.c:

cc -O0 -Wall -Werror -c resist-context.c -o resist-context.o
resist-context.c(74): error: type name is not allowed
      for (size_t i = 1; i < ctx->wl_count; i++) {
           ^

resist-context.c(74): error: expected a ";"
      for (size_t i = 1; i < ctx->wl_count; i++) {
                  ^

resist-context.c(74): error: identifier "i" is undefined
      for (size_t i = 1; i < ctx->wl_count; i++) {

We could either require C99 support to compile resist, or remove C99-specific features. I would vote for the latter because it is easy to do and requires fewer compiler flags (i.e., none).

In #31 we addressed asserting that the allocation succeeded. I'm wondering if it would be good to just move the setting of a pointer to NULL after free() is called into resist_free() as well?

We can at least set up build tests and unit tests in CI when ready. However we should note that such tests will not exercise features exploited by compilers that we are particularly interested in because those are not available.

We could set up cron jobs on the Cray machines to test that end of things as well. Something to keep in mind as edge services for CI are being considered here.

We should codify a workflow and release schedule. I would advocate for a few things that will make everybody's life easier, and welcome comments:

• timed releases (as opposed to feature-driven releases)
• pull-only model; @rcthomas should be the only person who has write access to this repository
• every commit should compile and run correctly; "work-in-progress" commits do not belong anywhere in this repository
• compilation with -Wall -Werror (or the equivalent for non-GCC compilers) should succeed on every commit