Plugin support for SLiM
29 views
Skip to first unread message
Nick O'Brien
Dec 4, 2025, 10:58:40 PM (11 days ago) Dec 4
to slim-discuss
Hi all,
I am working on a C++ extension for SLiM which is quite specific and probably doesn't make sense to include in the base SLiM project (an ODE solver for modelling the evolution of biological networks). However, it would be nice to be able to share this more easily than via a fork...
I think a plugin system might be one way to do this? I believe Qt already has a fairly robust way to load libraries (although I don't know if this would be accessible in non-SLiMgui builds). I'm thinking that SLiM could provide a way to read libraries and link additional functions defined in those libraries to eidos strings at runtime. Even better if it could also access the simulation loop (perhaps with behaviour similar to Eidos callbacks, but in C++ - some virtual functions called during the simulation loop that a plugin library could override, or invoking actions/events that a plugin could subscribe to). I realise this is probably a *big* ask, so no worries if this isn't possible. It would be interesting to know if others are working on C++ extensions to SLiM as well, and if anyone would find something similar helpful or if they have another solution.
Keen to hear your thoughts.
Cheers,
Nick
Ben Haller
Dec 5, 2025, 8:58:33 AM (10 days ago) Dec 5
to slim-d...@googlegroups.com
Hi Nick!
There are no plans to add the ability to load C++ based libraries into SLiM. This would be non-trivial to do in a cross-platform way, I would imagine (I wouldn't even know where to start). Qt is not an option, since it is only used in SLiMgui, not in the `slim` command-line tool. It would certainly be nice to be able to do something like this, but as you say, it's a big ask. Feel free to open an issue on GitHub about it, but it'll get marked "long-term" and "help needed"; since I have no idea how to do such things, it would be unlikely to get addressed by me any time soon. If you were to provide a PR that actually implements such a scheme, in a cross-platform way (Windows, Linux of various varieties, and macOS, at a minimum), that would be interesting but even then I'm not sure I'd want to merge it without a solid long-term commitment from you that you would maintain and support the feature far into the future. Otherwise the feature would just be subject to code rot, and would eventually break and need to be removed. A good philosophy for big projects like SLiM is: don't add anything that you're not prepared to maintain going forward. I'm not prepared to maintain dynamic library linking long-term, since I have zero technical understanding of it, so I'd be hesitant to add it even if someone gave it to me gift-wrapped with a bow on top. :-> And even beyond the dynamic linking aspect of it, it would be non-trivial to add plug-in extensibility to Eidos and SLiM in terms of their own architecture, too.
I might question your assumption that an ODE solver would not be a welcome addition to base SLiM (or presumably, more precisely, Eidos). It might not be a bad idea to open an issue about that, providing a detailed description of what you've done, how you would vend it in SLiM through an Eidos API, how it is useful for your model, and how much C++ code is involved. If you could provide a reasonably compact PR that implements it, and if the Eidos API was clean and documented, and if it didn't rely on any external link dependencies, I could imagine adding such a thing. The evolution of biological networks is certainly an area that it would be interesting for SLiM to support better.
Another possibility is to implement this as a command-line tool that Eidos calls out to using the `system()` function. That facility can be used for all sorts of added functionality. Of course `system()` is somewhat slow and somewhat clunky; but perhaps it would work fine for your purposes.
A third possibility, if the functionality can be implemented in Eidos itself (maybe an ODE solver can?), is to package it up as a user-defined function in a standalone file that can be included in a SLiM model using the `source()` function.
You're certainly free to package it up as a fork – SLiM and Eidos are open-source, after all – but to me that is perhaps the worst possible solution, and I would not be happy to see it. We could get into a discussion of why, but that would be better done off-list. (On slim-community, for example – that's the intended place for such philosophical discussions, since then people can subscribe to discussions that interest them. This list goes out to hundreds of users who probably wouldn't want to receive a long discussion about forks.)
Cheers,
-B.
Benjamin C. Haller
Messer Lab
Cornell University
There are no plans to add the ability to load C++ based libraries into SLiM. This would be non-trivial to do in a cross-platform way, I would imagine (I wouldn't even know where to start). Qt is not an option, since it is only used in SLiMgui, not in the `slim` command-line tool. It would certainly be nice to be able to do something like this, but as you say, it's a big ask. Feel free to open an issue on GitHub about it, but it'll get marked "long-term" and "help needed"; since I have no idea how to do such things, it would be unlikely to get addressed by me any time soon. If you were to provide a PR that actually implements such a scheme, in a cross-platform way (Windows, Linux of various varieties, and macOS, at a minimum), that would be interesting but even then I'm not sure I'd want to merge it without a solid long-term commitment from you that you would maintain and support the feature far into the future. Otherwise the feature would just be subject to code rot, and would eventually break and need to be removed. A good philosophy for big projects like SLiM is: don't add anything that you're not prepared to maintain going forward. I'm not prepared to maintain dynamic library linking long-term, since I have zero technical understanding of it, so I'd be hesitant to add it even if someone gave it to me gift-wrapped with a bow on top. :-> And even beyond the dynamic linking aspect of it, it would be non-trivial to add plug-in extensibility to Eidos and SLiM in terms of their own architecture, too.
I might question your assumption that an ODE solver would not be a welcome addition to base SLiM (or presumably, more precisely, Eidos). It might not be a bad idea to open an issue about that, providing a detailed description of what you've done, how you would vend it in SLiM through an Eidos API, how it is useful for your model, and how much C++ code is involved. If you could provide a reasonably compact PR that implements it, and if the Eidos API was clean and documented, and if it didn't rely on any external link dependencies, I could imagine adding such a thing. The evolution of biological networks is certainly an area that it would be interesting for SLiM to support better.
Another possibility is to implement this as a command-line tool that Eidos calls out to using the `system()` function. That facility can be used for all sorts of added functionality. Of course `system()` is somewhat slow and somewhat clunky; but perhaps it would work fine for your purposes.
A third possibility, if the functionality can be implemented in Eidos itself (maybe an ODE solver can?), is to package it up as a user-defined function in a standalone file that can be included in a SLiM model using the `source()` function.
You're certainly free to package it up as a fork – SLiM and Eidos are open-source, after all – but to me that is perhaps the worst possible solution, and I would not be happy to see it. We could get into a discussion of why, but that would be better done off-list. (On slim-community, for example – that's the intended place for such philosophical discussions, since then people can subscribe to discussions that interest them. This list goes out to hundreds of users who probably wouldn't want to receive a long discussion about forks.)
Cheers,
-B.
Benjamin C. Haller
Messer Lab
Cornell University
--
SLiM forward genetic simulation: http://messerlab.org/slim/
Before posting, please read http://benhaller.com/slim/bugs_and_questions.html
---
You received this message because you are subscribed to the Google Groups "slim-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to slim-discuss...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/slim-discuss/cb82ec16-b07d-44b0-844b-8090ada41a03n%40googlegroups.com.
Nick O'Brien
Dec 5, 2025, 9:05:44 PM (10 days ago) Dec 5
to slim-discuss
Hi Ben,
No worries at all! I figured it was a big ask :) I would be interested in developing and maintaining a plugin system, but only if it was likely to actually be used by others. I'm unsure how many people are rolling their own custom SLiM builds and could benefit from this (if anyone reading is interested, please let me know!)
Happy to make an issue re: the network solver. It would very likely require linking against an external library (the choices I am interested in are Apache licensed). A PR would be a ways off, but I am more than happy to work towards it and we can discuss the idea in the meantime.
In my first attempts at this I used system() to run an ODE solver as you suggested, but it has an extremely large performance cost relative to solving the ODE within SLiM itself (mainly IO related), and as you said, very clunky. For even moderately sized populations it wasn't feasible.
As for implementing a solver in eidos: that might be possible? I think it would still run into problems with larger population sizes. It would certainly be convenient to share though.
I agree re: sharing it as a fork :) Not a big fan of that solution and I would like to avoid it.
Cheers,
Nick
Ben Haller
Dec 6, 2025, 12:11:11 PM (9 days ago) Dec 6
to slim-d...@googlegroups.com
Hi Nick!
As far as I know you're the only person doing a custom build of SLiM to add their own functionality. Of course there may be others whom I'm not aware of!
If your solver code would require an external link dependency, that rules it out for inclusion in SLiM, sorry; avoiding external link dependencies is an important design stake. But the GNU Scientific Library (GSL) has ODE-solving capabilities (https://www.gnu.org/software/gsl/doc/html/ode-initval.html), and its source is included directly into Eidos/SLiM (to avoid the external link dependency), so if your solution could rely only on the GSL then that would work fine, and I'd be happy to add such functionality to Eidos as long as it had a simple Eidos API that didn't clutter things up too much. (Note that the copy of the GSL included in SLiM is not complete; additional GSL code would need to be grafted in to support this, which would probably be a job for me to do.) If doing this based on the GSL sounds viable to you, then please create a new issue about that and we can discuss the path forward there. :->
If that doesn't work, then probably having your own modified copy of SLiM is the best solution for the time being. If this proves to be a common problem for people, then developing some kind of plugin system would be warranted, but so far the demand is not there as far as I know. I've created an issue where people can express interest, or brainstorm other kinds of solutions: https://github.com/MesserLab/SLiM/issues/581. Let's shift any further discussion over to that issue, and leave this slim-discuss thread here.
As far as I know you're the only person doing a custom build of SLiM to add their own functionality. Of course there may be others whom I'm not aware of!
If your solver code would require an external link dependency, that rules it out for inclusion in SLiM, sorry; avoiding external link dependencies is an important design stake. But the GNU Scientific Library (GSL) has ODE-solving capabilities (https://www.gnu.org/software/gsl/doc/html/ode-initval.html), and its source is included directly into Eidos/SLiM (to avoid the external link dependency), so if your solution could rely only on the GSL then that would work fine, and I'd be happy to add such functionality to Eidos as long as it had a simple Eidos API that didn't clutter things up too much. (Note that the copy of the GSL included in SLiM is not complete; additional GSL code would need to be grafted in to support this, which would probably be a job for me to do.) If doing this based on the GSL sounds viable to you, then please create a new issue about that and we can discuss the path forward there. :->
If that doesn't work, then probably having your own modified copy of SLiM is the best solution for the time being. If this proves to be a common problem for people, then developing some kind of plugin system would be warranted, but so far the demand is not there as far as I know. I've created an issue where people can express interest, or brainstorm other kinds of solutions: https://github.com/MesserLab/SLiM/issues/581. Let's shift any further discussion over to that issue, and leave this slim-discuss thread here.
Cheers,
-B.
Benjamin C. Haller
Messer Lab
Cornell University
To view this discussion visit https://groups.google.com/d/msgid/slim-discuss/32f1360a-b41b-4dce-8aa4-98da8f997a15n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages