NativeLibraryConfig.WithLogs() overload to set log level

[swharden]

Adds a NativeLibraryConfig.WithLogs() overload to let the user indicate the log level (with "info" as the default)

[swharden]

Rather than having a bool to enable/disabling logging (with a separate overload), do you think we should add a None member to LLamaLogLevel?

[martindevans]

Right now LLamaLogLevel is a direct translation of an enum inside of llama.cpp, I think it's this one: https://github.com/ggerganov/llama.cpp/blob/c14f72db9c62d71d35eb1c141745c0bd0cb27b49/ggml.h#L510

Adding a new level directly to that is a bit iffy, since we'd be passing a technically invalid value down to llama.cpp. I think the best thing to do would be to observe when None is set and have different behaviour on that path (e.g. pass in a log callback that does nothing).

Another issue is that LLamaLogLevel appears to be wrong! In C# DEBUG = 1 but in C++ DEBUG = 5.

[swharden]

Adding a new level directly to that is a bit iffy

I'm fine keeping it like it is in this PR:

NativeLibraryConfig.Instance.WithLogs(false); // disables logging
NativeLibraryConfig.Instance.WithLogs(true); // enables logging
NativeLibraryConfig.Instance.WithLogs(); // enables logging
NativeLibraryConfig.Instance.WithLogs(LLamaLogLevel.Warning); // enables logging with the given level

Another issue is that LLamaLogLevel appears to be wrong! In C# DEBUG = 1 but in C++ DEBUG = 5

Is that something you want fixed in this PR, or are things good as they are and maybe we can open an issue and loop back to correct that later? The current behavior in this PR is working as expected for the example app.

[martindevans]

Is that something you want fixed in this PR, or are things good as they are and maybe we can open an issue and loop back to correct that later?

LLamaSharp is always using a slightly outdated version of llama.cpp, so it's possible our enum is correct for the current version. For now just open an issue to make sure I pay attention to it next time I update the binaries.

As for the WithLogs calls I think that's fine as is. It's quite clear to me what each indivdual call there does, there's no surprises.

[martindevans]

Everything else looks good, thanks again!