Open brendonw1 opened 5 years ago
I'm in favor of this. It existed only for backwards compatibility, but I don't think any current users are actually using it.
👍
On Mar 3, 2019, at 8:29 PM, David Tingley notifications@github.com wrote:
I'm in favor of this. It existed only for backwards compatibility, but I don't think any current users are actually using it.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
Could we use this opportunity to completely remove redundancy? Have everything pipe into SpikeGroups? (The only time this would be issue is if AnatGrps and SpkGrps conflict)
I'm fine with this but that's a lot of work no? Could break lots of ppl's code. I think you'd have to have buy in from users before doing this
On Mon, Mar 4, 2019 at 12:25 PM Dan Levenstein notifications@github.com wrote:
Could we use this opportunity to completely remove redundancy? Have everything pipe into SpikeGroups? (The only time this would be issue is if AnatGrps and SpkGrps conflict)
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/buzsakilab/buzcode/issues/305#issuecomment-469339952, or mute the thread https://github.com/notifications/unsubscribe-auth/ADXrTb6rmHTQx3IOqPjRtmE_M41jHic7ks5vTVcigaJpZM4ba8fG .
I'm trying to make some code that relates to sessionInfo. In there we have SpikeGroups, SpkGrps, AnatGrps, ElecGp. This is for back-compatability. However I think we can eliminate ElecGp: I searched in buzcode and found no uses of ElecGp outside of things that are reading xmls (ie nothing that actually uses it).
This would just be one small step and might prevent some future error where someone decides to use this old form of data - for no good reason. I also don't know what SPECIFICALLY ElecGp might signify different from the others
Think we should eliminate? If not of course it's fine, but I would