{"action":"created","issue":{"url":"https://api.github.com/repos/open-ephys/plugin-GUI/issues/57","repository_url":"https://api.github.com/repos/open-ephys/plugin-GUI","labels_url":"https://api.github.com/repos/open-ephys/plugin-GUI/issues/57/labels{/name}","comments_url":"https://api.github.com/repos/open-ephys/plugin-GUI/issues/57/comments","events_url":"https://api.github.com/repos/open-ephys/plugin-GUI/issues/57/events","html_url":"https://github.com/open-ephys/plugin-GUI/pull/57","id":160667850,"number":57,"title":"Reviving PSTH as a plugin","user":{"login":"shayo","id":1977614,"avatar_url":"https://avatars.githubusercontent.com/u/1977614?v=3","gravatar_id":"","url":"https://api.github.com/users/shayo","html_url":"https://github.com/shayo","followers_url":"https://api.github.com/users/shayo/followers","following_url":"https://api.github.com/users/shayo/following{/other_user}","gists_url":"https://api.github.com/users/shayo/gists{/gist_id}","starred_url":"https://api.github.com/users/shayo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/shayo/subscriptions","organizations_url":"https://api.github.com/users/shayo/orgs","repos_url":"https://api.github.com/users/shayo/repos","events_url":"https://api.github.com/users/shayo/events{/privacy}","received_events_url":"https://api.github.com/users/shayo/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":7,"created_at":"2016-06-16T13:55:21Z","updated_at":"2016-06-21T00:00:50Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/open-ephys/plugin-GUI/pulls/57","html_url":"https://github.com/open-ephys/plugin-GUI/pull/57","diff_url":"https://github.com/open-ephys/plugin-GUI/pull/57.diff","patch_url":"https://github.com/open-ephys/plugin-GUI/pull/57.patch"},"body":"Hi Aaron,\r\n\r\nI've made some changes to try and revive PSTH. I haven't tested things fully yet (this is work in progress), but I thought I should commit this in the meanwhile to get feedback."},"comment":{"url":"https://api.github.com/repos/open-ephys/plugin-GUI/issues/comments/227304934","html_url":"https://github.com/open-ephys/plugin-GUI/pull/57#issuecomment-227304934","issue_url":"https://api.github.com/repos/open-ephys/plugin-GUI/issues/57","id":227304934,"user":{"login":"aacuevas","id":1830303,"avatar_url":"https://avatars.githubusercontent.com/u/1830303?v=3","gravatar_id":"","url":"https://api.github.com/users/aacuevas","html_url":"https://github.com/aacuevas","followers_url":"https://api.github.com/users/aacuevas/followers","following_url":"https://api.github.com/users/aacuevas/following{/other_user}","gists_url":"https://api.github.com/users/aacuevas/gists{/gist_id}","starred_url":"https://api.github.com/users/aacuevas/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/aacuevas/subscriptions","organizations_url":"https://api.github.com/users/aacuevas/orgs","repos_url":"https://api.github.com/users/aacuevas/repos","events_url":"https://api.github.com/users/aacuevas/events{/privacy}","received_events_url":"https://api.github.com/users/aacuevas/received_events","type":"User","site_admin":false},"created_at":"2016-06-21T00:00:50Z","updated_at":"2016-06-21T00:00:50Z","body":"The issue with 2 is not common code, which I agree with you, it's how things should be done, but with symbol name duplicity: if two different modules have a symbol with the same full name, the Linux linker will refuse to load one of them.\r\nIn case of code from the GUI (Juce code, GenericProcessor methods, etc...) those methods are not built in the plugins at all, but on the Core GUI, who then exports them for plugins to use. So they exist only once in the whole process space.\r\nWhen building plugins, however, StringTS (for example) gets compiled into the NetworkEvents plugin, the SpikeSorter plugin and the PSTH plugin separately, existing three different copies of it. This causes issues in some cases. If there were only one binary source for those methods, or if they were named differently (for example, using namespaces: NetworkEventsPlugin::StringTS::StringTS() is different from PSTHPlugin::StringTS::StringTS() ) there would be no issue.\r\n\r\nSo, first of all, demanding that all the code from a plugin is enclosed in its own namespace is to avoid general symbol conflict (imagine the case where 2 different plugins implement a class with the same name but which behaves completely differently, this would avoid issues with that).\r\n\r\nNow, to solve this for common code, there are three solutions: The bad, the good and the (quick and) ugly :laughing: :\r\n\r\n- The Bad is just copying the same code into each plugin with a different namespace. Bad solution, bug prone, redundant effort... Name your poison, this will have it.\r\n- The Good would be encapsulating common classes into their own libraries (create a StringTS.dll, a ContinuousCircularBuffer.dll, or a dll containing different but related classes). This would enable different plugins to reuse the same code, and it would exist just once in the process space. It's the one that offers most advantages. The only downside is that, well, we have to develop yet another dynamic lib with all the hassle it supposes.\r\n- The (Quick and) Ugly would be to use a namespace tied to a macro in the common files (something like `namespace NAMESPACE_NAME {}`, while defining NAMESPACE_NAME in the project. This way the code will be reused, although it would be compiled multiple times (like it does now), but with no symbol name collision. \r\n\r\nAt least, there are the only ones I can think of right now.\r\n"}}
{"actor":{"display_login":"aacuevas"}}