-
Notifications
You must be signed in to change notification settings - Fork 18
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
Upgrade to .NET 8.0? #27
Comments
The wrapper I made is not completely finished, but I'd be happy to have anyone pick it up. 90% of it is done but there are some design things that should be rethought. I use it whenever I need LSL in C# and I have never seen any bugs, but there is a glaring memory management issue I have yet to solve in the List<List> variant of pull_chunk. That said, it would be trivial to upgrade to .NET 8. |
Have you tried your wrapper with Unity? Just a couple quotes from other PRs/issues about the importance of a C# wrapper working for both Unity and .NET. What are some of the "design things that should be rethought"? |
Hi, guys! If anyone is interested, I recently wrote a C# wrapper for liblsl and published it on NuGet. It's not perfect yet(and may have bugs), but it's getting close to my goal. I also plan to merge some of the issues I've already resolved into this repository. |
Is there an appetite to upgrade to .NET 8.0?
I was thinking something along the lines of what @dmedine did?
I've seen issues and PRs across the LSL wrappers mentioning legacy support for older versions of that language (e.g. Python) but would that need to be done for the C# wrapper, especially as it hasn't got a NuGet package yet?
If legacy support was not needed then this would be a good opportunity for a fresh start and for the wrapper to meet the general naming conventions as well as splitting the classes across multiple files for better delineation. Perhaps a new repository called LSL.Net like mentioned here.
The text was updated successfully, but these errors were encountered: