You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Maintaining a separate repo creates all kinds of tracking problems. This code should be included in the MATLAB viewer or in the folder for the liblsl repo. @chkothe@cboulay
There are some problems with including it in the liblsl repo.
What about the other language bindings? Python, Rust, C-Sharp, Java, etc.?
The liblsl repo is in the sccn org so it's harder to grant permissions to someone who wants to admin one of the bindings (being separate has worked out well for XDF which has community support beyond just me).
Putting them in the same repo implies compatibility that isn't implied by being in separate repos.
Continued compatibility between all the language bindings and the core library would be great, but is somewhat impossible. What if someone submits a PR to fix something in liblsl C++ code but this person has no knowledge of Java, or they don't have a Matlab license? Do we merge the PR then let the language binding in the same repo desync with liblsl? Do we reject the PR until they fix all the language bindings too, even if that means they have to buy a Matlab license?
I have no objection to merging liblsl-Matlab and App-MatlabViewer, but I would move the latter into here instead of vice versa. liblsl-Matlab is higher priority. This would be similar to pylsl which has a viewer as an example.
Activity
cboulay commentedon Feb 18, 2025
There are some problems with including it in the liblsl repo.
Continued compatibility between all the language bindings and the core library would be great, but is somewhat impossible. What if someone submits a PR to fix something in liblsl C++ code but this person has no knowledge of Java, or they don't have a Matlab license? Do we merge the PR then let the language binding in the same repo desync with liblsl? Do we reject the PR until they fix all the language bindings too, even if that means they have to buy a Matlab license?
I have no objection to merging liblsl-Matlab and App-MatlabViewer, but I would move the latter into here instead of vice versa. liblsl-Matlab is higher priority. This would be similar to
pylslwhich has a viewer as an example.