Hi all, I've opened a pull request to remove the reason GUI here: https://bitbucket.org/yt_analysis/yt/pull-requests/1719 As I mentioned in my e-mail a couple weeks ago about cleaning up the codebase, most of the functionality provided by reason is currently disabled. It could be re-enabled, but someone would need to commit to maintaining it and go through the work of updating the python side of things to work with the current state of yt. If anyone is invested in the reason gui and thinks my pull request is not the way to go, please feel free to comment on the pull request so we can start a discussion about what to do. Thanks for your time, -Nathan
Hi Nathan, This PR makes me really, really sad. The first version of Reason, back in 2007, was a wxPython GUI that basically Britton and I worked on. Then there were a few other iterations, and finally this one, Reason v5 ("Cinco Analysis Generator") was a joint effort (lots of effort from Cameron), written in ExtJS 3. There were two big components -- the python backend, and the javascript frontend. This was the one that got presented at the yt workshop in Chicago. Midway through 2012 I spent a bunch of time refactoring this to work with Ext JS 4 (the current layout of the javascript, along with the current javascript, is largely fully refactored and much of it rewritten from the ExtJS 3 code) and this was more extensible, with pluggable widgets and so on in an easier, more defined way. Of the various components, the Python portion is definitely the part that would need the most work to maintain, and also is probably the one that would be the most unwise to maintain. The ExtJS4 stuff, which is in principle not impossible to maintain, should probably be let go, as much as it pains me. It's a nice framework, and I'm proud of what it is, but it's heavyweight and very project specific. It could be made much more generic ... but first we'd have to maintain it. And I think that while the JS is likely not too hard to maintain in stasis at this point, the Python code would be a pain. Theoretically we could swap out the Python execution backend for Jupyter (basing it on something like the way Thebe operates) but I'm not sure the overall value there for us. That's not to say there isn't a set of lessons we can learn, but this was a big push, and I think maybe in the end larger projects with more resources and expertise should be utilized, rather than going it ourselves on this (thinking here of Jupyter). I'm okay with it going. I guess. -Matt On Mon, Aug 24, 2015 at 3:43 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
Hi all,
I've opened a pull request to remove the reason GUI here:
https://bitbucket.org/yt_analysis/yt/pull-requests/1719
As I mentioned in my e-mail a couple weeks ago about cleaning up the codebase, most of the functionality provided by reason is currently disabled. It could be re-enabled, but someone would need to commit to maintaining it and go through the work of updating the python side of things to work with the current state of yt.
If anyone is invested in the reason gui and thinks my pull request is not the way to go, please feel free to comment on the pull request so we can start a discussion about what to do.
Thanks for your time,
-Nathan
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Matt, I think the main question for the project to answer is whether there is demand for a GUI in the first place. Many of us like yt because it is just a python library, and we like written scripts or interacting through the notebooks. But new users may not be as comfortable with that. Then the question becomes is it worth it to create a GUI for them or to help them gain familiarity with the library through nice tutorial notebooks (of which there is already a good collection). On Tue, Aug 25, 2015 at 10:33 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Nathan,
This PR makes me really, really sad.
The first version of Reason, back in 2007, was a wxPython GUI that basically Britton and I worked on. Then there were a few other iterations, and finally this one, Reason v5 ("Cinco Analysis Generator") was a joint effort (lots of effort from Cameron), written in ExtJS 3. There were two big components -- the python backend, and the javascript frontend. This was the one that got presented at the yt workshop in Chicago. Midway through 2012 I spent a bunch of time refactoring this to work with Ext JS 4 (the current layout of the javascript, along with the current javascript, is largely fully refactored and much of it rewritten from the ExtJS 3 code) and this was more extensible, with pluggable widgets and so on in an easier, more defined way.
Of the various components, the Python portion is definitely the part that would need the most work to maintain, and also is probably the one that would be the most unwise to maintain. The ExtJS4 stuff, which is in principle not impossible to maintain, should probably be let go, as much as it pains me. It's a nice framework, and I'm proud of what it is, but it's heavyweight and very project specific. It could be made much more generic ... but first we'd have to maintain it. And I think that while the JS is likely not too hard to maintain in stasis at this point, the Python code would be a pain. Theoretically we could swap out the Python execution backend for Jupyter (basing it on something like the way Thebe operates) but I'm not sure the overall value there for us.
That's not to say there isn't a set of lessons we can learn, but this was a big push, and I think maybe in the end larger projects with more resources and expertise should be utilized, rather than going it ourselves on this (thinking here of Jupyter). I'm okay with it going. I guess.
-Matt
Hi all,
I've opened a pull request to remove the reason GUI here:
https://bitbucket.org/yt_analysis/yt/pull-requests/1719
As I mentioned in my e-mail a couple weeks ago about cleaning up the codebase, most of the functionality provided by reason is currently disabled. It could be re-enabled, but someone would need to commit to maintaining it and go through the work of updating the python side of
On Mon, Aug 24, 2015 at 3:43 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote: things
to work with the current state of yt.
If anyone is invested in the reason gui and thinks my pull request is not the way to go, please feel free to comment on the pull request so we can start a discussion about what to do.
Thanks for your time,
-Nathan
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale github: http://github.com/zingale
Just going to toss this out as someone who spent a lot of time on Reason -- It might be nice if Reason existed outside of yt, just as another repo within the bitbucket/yt_analysis realm. Could even peg it to a yt that it functions with and if folks are ever interested in bringing it back, it would allow for external development. Just a thought. Sam On Tue, Aug 25, 2015 at 7:33 AM Matthew Turk <matthewturk@gmail.com> wrote:
Hi Nathan,
This PR makes me really, really sad.
The first version of Reason, back in 2007, was a wxPython GUI that basically Britton and I worked on. Then there were a few other iterations, and finally this one, Reason v5 ("Cinco Analysis Generator") was a joint effort (lots of effort from Cameron), written in ExtJS 3. There were two big components -- the python backend, and the javascript frontend. This was the one that got presented at the yt workshop in Chicago. Midway through 2012 I spent a bunch of time refactoring this to work with Ext JS 4 (the current layout of the javascript, along with the current javascript, is largely fully refactored and much of it rewritten from the ExtJS 3 code) and this was more extensible, with pluggable widgets and so on in an easier, more defined way.
Of the various components, the Python portion is definitely the part that would need the most work to maintain, and also is probably the one that would be the most unwise to maintain. The ExtJS4 stuff, which is in principle not impossible to maintain, should probably be let go, as much as it pains me. It's a nice framework, and I'm proud of what it is, but it's heavyweight and very project specific. It could be made much more generic ... but first we'd have to maintain it. And I think that while the JS is likely not too hard to maintain in stasis at this point, the Python code would be a pain. Theoretically we could swap out the Python execution backend for Jupyter (basing it on something like the way Thebe operates) but I'm not sure the overall value there for us.
That's not to say there isn't a set of lessons we can learn, but this was a big push, and I think maybe in the end larger projects with more resources and expertise should be utilized, rather than going it ourselves on this (thinking here of Jupyter). I'm okay with it going. I guess.
-Matt
Hi all,
I've opened a pull request to remove the reason GUI here:
https://bitbucket.org/yt_analysis/yt/pull-requests/1719
As I mentioned in my e-mail a couple weeks ago about cleaning up the codebase, most of the functionality provided by reason is currently disabled. It could be re-enabled, but someone would need to commit to maintaining it and go through the work of updating the python side of
On Mon, Aug 24, 2015 at 3:43 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote: things
to work with the current state of yt.
If anyone is invested in the reason gui and thinks my pull request is not the way to go, please feel free to comment on the pull request so we can start a discussion about what to do.
Thanks for your time,
-Nathan
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I agree with Matt that it makes me sad to remove Reason because we put so much time into it, but I think it makes sense at this point. In response to Michael's point, I think there *is* a need for a GUI in yt, as exploration of datasets is oftentimes the first step towards analysis and exploration can usually be done most easily with some sort of interactive interface. I like the idea of leveraging Jupyter into a sort of google-maps interface for panning, zooming, and changing fields on the fly for one's image. I think that would be extremely helpful for getting a quick feel for a dataset. So I'm in favor of pursuing a GUI in the future, but it seems like Reason is not it. Whether this GUI exists within the yt framework or externally as Sam suggests, is open for discussion. It seems like unless it is really a huge addition to the codebase, I think it would be best to be within the main yt distribution. Cameron On Tue, Aug 25, 2015 at 7:48 AM, Sam Skillman <samskillman@gmail.com> wrote:
Just going to toss this out as someone who spent a lot of time on Reason -- It might be nice if Reason existed outside of yt, just as another repo within the bitbucket/yt_analysis realm. Could even peg it to a yt that it functions with and if folks are ever interested in bringing it back, it would allow for external development. Just a thought.
Sam
On Tue, Aug 25, 2015 at 7:33 AM Matthew Turk <matthewturk@gmail.com> wrote:
Hi Nathan,
This PR makes me really, really sad.
The first version of Reason, back in 2007, was a wxPython GUI that basically Britton and I worked on. Then there were a few other iterations, and finally this one, Reason v5 ("Cinco Analysis Generator") was a joint effort (lots of effort from Cameron), written in ExtJS 3. There were two big components -- the python backend, and the javascript frontend. This was the one that got presented at the yt workshop in Chicago. Midway through 2012 I spent a bunch of time refactoring this to work with Ext JS 4 (the current layout of the javascript, along with the current javascript, is largely fully refactored and much of it rewritten from the ExtJS 3 code) and this was more extensible, with pluggable widgets and so on in an easier, more defined way.
Of the various components, the Python portion is definitely the part that would need the most work to maintain, and also is probably the one that would be the most unwise to maintain. The ExtJS4 stuff, which is in principle not impossible to maintain, should probably be let go, as much as it pains me. It's a nice framework, and I'm proud of what it is, but it's heavyweight and very project specific. It could be made much more generic ... but first we'd have to maintain it. And I think that while the JS is likely not too hard to maintain in stasis at this point, the Python code would be a pain. Theoretically we could swap out the Python execution backend for Jupyter (basing it on something like the way Thebe operates) but I'm not sure the overall value there for us.
That's not to say there isn't a set of lessons we can learn, but this was a big push, and I think maybe in the end larger projects with more resources and expertise should be utilized, rather than going it ourselves on this (thinking here of Jupyter). I'm okay with it going. I guess.
-Matt
Hi all,
I've opened a pull request to remove the reason GUI here:
https://bitbucket.org/yt_analysis/yt/pull-requests/1719
As I mentioned in my e-mail a couple weeks ago about cleaning up the codebase, most of the functionality provided by reason is currently disabled. It could be re-enabled, but someone would need to commit to maintaining it and go through the work of updating the python side of
On Mon, Aug 24, 2015 at 3:43 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote: things
to work with the current state of yt.
If anyone is invested in the reason gui and thinks my pull request is not the way to go, please feel free to comment on the pull request so we can start a discussion about what to do.
Thanks for your time,
-Nathan
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org
On Tue, Aug 25, 2015 at 9:48 AM, Sam Skillman <samskillman@gmail.com> wrote:
Just going to toss this out as someone who spent a lot of time on Reason -- It might be nice if Reason existed outside of yt, just as another repo within the bitbucket/yt_analysis realm. Could even peg it to a yt that it functions with and if folks are ever interested in bringing it back, it would allow for external development. Just a thought.
Thanks for the idea Sam! It would take some work to extract reason and get it to run stand-alone. Also, the version of yt it would be pinned against would have reason living inside it anyway, so I'm not sure how helpful it would be to a future porter to go through the exercise. Regarding Matt's reluctance and Mike's point about whether a GUI is necessary, I'd argue that reason really was going in the right direction, and might even have evolved into something that we would all be using on a day-to-day basis were it not for evolutions in the python ecosystem outside of yt (mostly thinking of jupyter/jupyter notebooks here). Interactive visualization toolkits mixing code and GUIs in the same interface is a really powerful idea. That said, a GUI *needs* to be tested at some level. Whether it be full mock UI testing via something like selenium that simulates browser interactions or by constructing the GUI so GUI events correspond to specific API events that a test suite can programmatically invoke. In either case, we need to find out on a commit-by-commit basis when things break, otherwise bitrot ensues. All this overhead means that the task of getting the GUI working, given that it falls outside most of our development experience, will be high. That's not to say it's not worth doing, just that it would need someone devoting resources to it, and they would need to do the work with an eye towards maintainability and testing.
Sam
On Tue, Aug 25, 2015 at 7:33 AM Matthew Turk <matthewturk@gmail.com> wrote:
Hi Nathan,
This PR makes me really, really sad.
The first version of Reason, back in 2007, was a wxPython GUI that basically Britton and I worked on. Then there were a few other iterations, and finally this one, Reason v5 ("Cinco Analysis Generator") was a joint effort (lots of effort from Cameron), written in ExtJS 3. There were two big components -- the python backend, and the javascript frontend. This was the one that got presented at the yt workshop in Chicago. Midway through 2012 I spent a bunch of time refactoring this to work with Ext JS 4 (the current layout of the javascript, along with the current javascript, is largely fully refactored and much of it rewritten from the ExtJS 3 code) and this was more extensible, with pluggable widgets and so on in an easier, more defined way.
Of the various components, the Python portion is definitely the part that would need the most work to maintain, and also is probably the one that would be the most unwise to maintain. The ExtJS4 stuff, which is in principle not impossible to maintain, should probably be let go, as much as it pains me. It's a nice framework, and I'm proud of what it is, but it's heavyweight and very project specific. It could be made much more generic ... but first we'd have to maintain it. And I think that while the JS is likely not too hard to maintain in stasis at this point, the Python code would be a pain. Theoretically we could swap out the Python execution backend for Jupyter (basing it on something like the way Thebe operates) but I'm not sure the overall value there for us.
That's not to say there isn't a set of lessons we can learn, but this was a big push, and I think maybe in the end larger projects with more resources and expertise should be utilized, rather than going it ourselves on this (thinking here of Jupyter). I'm okay with it going. I guess.
-Matt
Hi all,
I've opened a pull request to remove the reason GUI here:
https://bitbucket.org/yt_analysis/yt/pull-requests/1719
As I mentioned in my e-mail a couple weeks ago about cleaning up the codebase, most of the functionality provided by reason is currently disabled. It could be re-enabled, but someone would need to commit to maintaining it and go through the work of updating the python side of
On Mon, Aug 24, 2015 at 3:43 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote: things
to work with the current state of yt.
If anyone is invested in the reason gui and thinks my pull request is not the way to go, please feel free to comment on the pull request so we can start a discussion about what to do.
Thanks for your time,
-Nathan
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (5)
-
Cameron Hummels -
Matthew Turk -
Michael Zingale -
Nathan Goldbaum -
Sam Skillman