search

brian-team / brian2

Brian is a free, open source simulator for spiking neural networks.
http://briansimulator.org
Other
922 stars 219 forks source link

Progress and notifications #43

Open thesamovar opened 11 years ago

thesamovar commented 11 years ago

It would be nice to have slightly more sophisticated progress reporting and notification when the simulation is complete.

For progress reporting:

For notification, the idea would be to let the user know a long-running simulation has finished which doesn't require them to monitor a console. For example, a pop up notification on the system tray in Windows, or an email.

There might be standard apps that you can use for notification - so perhaps it's not worth adding it to Brian?

mstimberg commented 11 years ago

I think -- similarly to what we talked about for visualisations, analysis, etc. -- we should focus on making the core clear and extensible. In my view: The progress report should have support for subtasks as you say and should be able to call arbitrary reporting functions when something is to report. Of course we should provide the standard text-based report (and maybe something HTMLy for the ipython notebook?) but even the GUI (did anyone ever actually use this...?) is somewhat out of scope IMO. Notification at the end could be handled by the 100% progress notification or with standard tools (e.g. you could simply do python my_script.py; notification_script)

thesamovar commented 11 years ago

A possible idea: what about having a new package brian_extensions which is basically add-ons for Brian that more people can contribute to, and we don't officially support? A bit like the failed neuroscience cookbook? There are some things like this which it seems a shame if everyone is implementing for themselves.

mstimberg commented 11 years ago

A possible idea: what about having a new package brian_extensions which is basically add-ons for Brian that more people can contribute to, and we don't officially support? A bit like the failed neuroscience cookbook? There are some things like this which it seems a shame if everyone is implementing for themselves.

Sounds good to me -- even though for stuff that is Brian-independent (spike train statistics, visualisation), I'd rather make Brian play nicely with external tools and make users contribute to them. It would then be more of a documentation issue, e.g. a wiki (which would make it more similar to the cookbook again :) ) But maybe you are right, being able to call a function from a non-standard standard package is better than copy/pasting it from a website.

thesamovar commented 11 years ago

I really don't know what is the best way of doing it. I feel like having code in a repository is better than using a wiki though. For a start, it allows you to track changes, submit bug reports, etc.

Another name idea for the package: brian_community. And we'd allow many more people commit rights to that repository. Or maybe brian_community for the team name, and several different repositories. Oh, the possibilities!

mstimberg commented 11 years ago

I really don't know what is the best way of doing it. I feel like having code in a repository is better than using a wiki though. For a start, it allows you to track changes, submit bug reports, etc.

Yes, having it in a repository is probably better. It would also have a couple of infrastructure advantages to separate it (including examples) from the main repo -- e.g. an addition to the examples does not trigger the whole testing machinery.

Another name idea for the package: brian_community. And we'd allow many more people commit rights to that repository. Or maybe brian_community for the team name, and several different repositories. Oh, the possibilities!

Well, we don't have to necessarily allow many more people to commit, they could still do pull requests but it wouldn't have to go through a scrutinizing code review. But yes, there are quite a number of possibilities...

thesamovar commented 5 years ago

Two more ideas for this: